Bonghjornu ognunu!
Nikita hè in cuntattu - un ingegnere di sistema da a cumpagnia SEMrush. Oghje vi dicu cumu avemu affruntatu u compitu di assicurà a stabilità di u nostru serviziu semrush.com in Cina, è chì prublemi avemu scontru durante a so implementazione (datu u locu di u nostru centru di dati nantu à a costa est di i Stati Uniti).
Questa serà una grande storia, divisa in parechji articuli. Vi dicu cumu tuttu hè accadutu per noi: da un serviziu cumpletamente micca funziunale da a Cina, à l'indicatori di rendiment di u serviziu à u livellu di a so versione americana per l'Americani. Promettu chì serà interessante è utile. Allora, andemu.
Prublemi di l'Internet Chinese
Ancu a persona più alluntanata da e specifiche di l'amministrazione di a rete hà intesu parlà Great Firewall di Cina. Wow, sona cool, nò? Ma ciò chì hè è cumu funziona veramente hè una quistione abbastanza complicata. Pudete truvà parechji articuli nantu à Internet dedicati à questu, ma da un puntu di vista tecnicu, u disignu di stu firewall ùn hè micca scrittu in ogni locu. Chì, però, ùn hè micca surprisante. Admettu subitu chì basatu annantu à i risultati di un annu di travagliu, ùn puderaghju micca dì esattamente cumu si travaglia, ma vi possu cuntà i mo cumenti è cunclusioni pratiche. E avemu da principià cù rumuri annantu à questu firewall.
Ci hè parechje rumuri annantu à questu firewall. Raccogliemu i principali è i più interessanti di elli in una lista:
- Google, Facebook, Twitter è altri servizii simili sò bluccati è ùn funzionanu micca in Cina.
- Ogni trafficu fora di a Cina è in Cina hè analizatu è limitatu cù l'apprendimentu di machine (in casu di trafficu suspettu), chì rallenta assai (u trafficu) chì passa per a fruntiera.
- L'agenzii di intelligenza chinesi pirateranu ogni trafficu criptatu chì passa per u so firewall.
- Tunnel VPN, tunnel IPSEC sò instabili, crash è sò constantemente bluccati.
- U più simplice hè a criptografia, u più simplice u passaghju utilizatu per autentificà / criptà u trafficu, u più veloce passa per u firewall cinese.
Eccu ciò chì avemu scupertu nantu à sti rumuri:
- Google, Facebook, Twitter è altri servizii simili sò veramente bluccati (u vostru KO), ma assai duminii tecnichi di Google, per esempiu, ùn sò micca pruibiti è travaglianu (u stessu gstatic.com). A cunclusione seguita da questu: ùn deve micca taglià imprudente tutti i Google è altre risorse chì pareanu esse bluccati.
- Ogni trafficu chì passa a fruntiera aghjusta veramente un ritardu seriu à u so tempu. Fighjate i dui risultati. Un situ, una pagina, simplice GET curl'om. A prima misurazione hè stata da a China stessu (a bella cità di Shenzhen). U sicondu hè statu misuratu da fora da Hong Kong (hà a sovranità, è ùn ci hè micca firewall trà ellu è u mondu). A distanza trà e cità in una linea dritta hè di circa 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sattenti à time_connect. È in generale, vede u risultatu: u firewall aghjunghje 4 seconde extra, chì hè monstrously long.
- I tunnelli VPN è IPSEC fallenu spessu. Parlaraghju di questu un pocu dopu è in più detail. I servitori VPN chì sò utilizati da l'utilizatori sò bluccati cù u tempu (di solitu in un ghjornu dopu l'iniziu di l'usu).
- Ci hè una opinione ricevuta da e persone chì vivenu in Cina chì u più simplice u criptu di u trafficu, u più veloce passa per u cunfini, perchè hè faciule capisce chì ùn ci hè nunda illegale. È in listessa manera, u trafficu "pulitu" riceve più larghezza di banda è velocità di passaghju, mentre chì u trafficu "bruttu", in quale nunda ùn pò esse capitu, riceve, à u cuntrariu, un passaghju più lento. Per esempiu, aghju aduprà curl to ifconfig.co via HTTPS è protocolu HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sUna diferenza di 5 seconde per un tempu di scaricamentu tutale di 13 bytes. Inoltre, quandu facia una tale prova parechje volte, pudete nutà chì GET in HTTP hè cumpletu in generale in u stessu tempu ogni volta, mentre chì in HTTPS u situ risponde à volte in 3, 5, 10 è ancu 17 seconde. A volte l'errore SSL succede:
Unknown SSL protocol error in connection to ifconfig.co:443.
Allora ciò chì avemu:
- I prublemi creati da u firewall cinese sò descritti sopra.
- I ping à e risorse esterne è à l'internu di i tunnel sparisce periodicamente.
- A latenza trà dui punti hè in constantemente cambiante, è spessu hè simplicemente imprevisible. Quandu culligate diverse cità / regioni, aspettate chì, basatu nantu à a situazione geografica di e regioni, u ritardu serà menu, ma avete esattamente a situazione cuntraria.
- L'Internet è i canali di cumunicazione sò veloci o lenti. Ci hè una ligera dependenza di l'ora di u ghjornu è u ghjornu di a settimana, ma micca sempre.
- E dumande DNS à u mondu esternu da a Cina a volte superanu u timeout permessu.
A stampa chì emerge hè simplicemente "eccellente".
U centru di dati, cum'è l'aghju digià dettu, hè in i Stati Uniti orientali, è tuttu u SEMrush hè custituitu da decine di prudutti interconnessi, backends, frontends, databases, è tuttu questu in DC è nuvole. Avemu, cum'è una squadra di amministratori di sistema, ci hè statu datu u compitu di cumincià rapidamente à travaglià in Cina cù pocu sforzu.
Avemu avutu à risponde à una quistione impurtante: hè pussibule di passà cù pocu spesa è risolve tutti i prublemi assuciati cù l'Internet cinese è u firewall à u livellu di a reta / nuvola / servore ?
Avemu principiatu per riceve .
Licenza ICP
Per pudè ospitu u vostru serviziu in Cina (Cina Continentale) è fà e teste, prima deve ottene una licenza ICP per u duminiu.
Se u trafficu di l'utilizatori di u vostru situ hè finitu in Cina continentale, è se u vostru duminiu ùn hà micca una licenza ICP, u vostru trafficu serà bluccatu da u latu ISP / hosting. Curiosamente, a licenza ICP include un fornitore specificu, sia Cloudflare o Alibaba Cloud. Dunque, se avete ricevutu una licenza ICP per Cloudflare è allughjatu u vostru situ web cun elli, ùn sarete micca capaci di trasfurmà "perfettamente" in Alibaba Cloud. Avete bisognu di aghjunghje un altru hosting à sta licenza.
Dopu avè ricivutu una licenza ICP per u duminiu, avemu pussutu vene è implementà idee tecniche è soluzioni specifiche.
Soluzioni di prova
Ma prima di creà direttamente l'opzioni di staging, girate i pomi, ottimisate u funziunamentu di u situ è a so rapidità, avete bisognu di sceglie un strumentu per pruvà per vede quale di e nostre azzioni migliurà o, à u cuntrariu, aggrava u funziunamentu di u situ.
U nostru strumentu di teste duvia risponde à dui esigenze principali:
- duveria esse capace di eseguisce teste da a Cina,
- deve avè testi di navigatore.
Allora avemu trovu ! Hanu una eccellente copertura di i lochi di teste in u mondu. In Cina, i testi ponu ancu esse realizati da 100500 pruvince attraversu stu strumentu. Ognunu hà parechji fornituri diffirenti + a capacità di fà Backbone-tests (qualcosa cum'è una macchina virtuale in un centru di dati) è Lastmile-tests (più vicinu pussibule à e cundizioni di l'utilizatori, aka workstation). L'ultimu tipu di teste hè più caru.
Dopu avè cunclusu un cuntrattu annuale (menu di questu ùn hè micca pussibule), avemu principiatu à studià u strumentu. Francamente, avemu statu piacevule sorpresa da a so funziunalità. Pudete curriri:
- testi DNS,
- Testi Web (testi di u navigatore, GET/POST simplici, emulazione di u cliente mobile, etc.),
- cuntrolli transazzione (per esempiu, login),
- tests API,
- Ping, traceroute, NTP, etc.
Ùn pudete micca listà tuttu. È più importantemente, ogni prova pò esse persunalizatu abbastanza bè aghjunghjendu una mansa di intestazioni è altri parametri. L'output hè una quantità enorme di informazioni chì descrive cumplettamente a vostra prova. Se parlemu di e cose più interessanti per noi (testi di navigatore), u risultatu include:
- Cunnette, aspetta, carica, SSL, tempu DNS,
- TTFB, TTLB, Documentu cumpletu, Tempu di rende, carica DOM,
- Risposta (qualcosa vicinu à Time To First Byte), Webpage Response (qualcosa vicinu à Time To Last Byte),
- Qualchese percentile, Mediu, Tempu medianu
- Etc.
In cunsiquenza, tutte queste metriche sò fantastiche per vede cambiamenti è capisce se e cose sò megliu. Avemu vistu principalmente Risposta, Risposta di a pagina Web, Mediana, 75 è 95 percentili.
Una quistione impurtante chì era in l'aria da u principiu: Pudete fiducia in Catchpoint?? Questu strumentu riflette a velocità di carica di u situ reale in Cina da diverse cità, o hè solu una prova in un vacuum chì ùn hà nunda di fà cù l'esperienza d'utilizatore reale?
Questu hè un grande prublema, perchè esse in Russia hè quasi impussibile di sapè in modu affidabile cumu funziona un situ da a Cina. Fendu un calzini-proxy attraversu una macchina virtuale, u risultatu finali hè chì u situ si carica in un paru di minuti, chì hè simplicemente inaccettabile per i testi, cusì l'unica opzione per a prova manuale hè curl è simplice GET da a cunsola cù un timer. . Questu aiuta perchè sta prova riflette bè a vitezza di a suluzione di a reta, è s'ellu ci sò ancu testi di navigatore, allora hè assai bonu.
In seguitu noi stessi andemu in Cina è eramu cunvinti chì Pudete fidà di Catchpoint; riflette abbastanza precisamente indicatori di rendiment reali.
Cloudflare China Network
Siccomu utilizemu bè Cloudflare per u duminiu principale semrush.com, avemu decisu di pruvà immediatamente a so funzione chjamata . Questa opzione hè attivata solu per i siti Enterprise nantu à dumanda separata è per una tarifa addiziale. Hè ancu dispunibule solu per i siti chì anu una licenza ICP appruvata chì lista Cloudflare cum'è u fornitore. Dopu avè attivatu, u "CDN Cinese" da Cloudflare diventa dispunibule per u situ - u trafficu da e regioni cinesi sbarca à u PoP (Punti di Presenza) CF più vicinu, è dopu attraversu e so rete o e rete di fornituri / partenarii hè mandatu à l'urigine. .
U schema di stu bancu di prova hè presentatu quì sottu.
Questa hè una grande opzione per noi. Ci hè chì u sicondu duminiu serà ancu per CF, chì ùn aghjunghje micca u nùmeru di suluzioni utilizati in a cumpagnia, è ancu praticamente ùn cumplicà micca l'infrastruttura.
Avemu eseguitu teste di navigatore è questu hè ciò chì hè accadutu:
I diamanti rossi sò fallimenti di teste. I schedarii sottu sò errori DNS (risolve u timeout). I fallimenti in cima sò timeouts.
Uptime: 86.6
Mediana: 18s
75 percentile: 29.3 s
95 percentile: 60 s
Mediana, dopu a carica hè stata eliminata reCaptcha (Serviziu Google bluccatu in Cina) hè diminuitu da 28 à 18 seconde. Ma questi sò sempre risultati terribili, cunziddi chì a stessa prova per semrush.com (da i Stati Uniti) hà datu menu di 10 seconde per 95% di l'utilizatori (da i Stati Uniti) in a stessa pagina (static + dinamica).
Pudete andà in ogni prova è vede Cascata è altri parametri più detallati. Avemu cuminciatu à investigà i motivi di l'errore, è se per timeouts tuttu hè più o menu chjaru: l'Internet in Cina "si muove è fora", per quessa, a velocità di cunnessione è a carica di risorse da l'esteru hè inestabile è irregolare. tandu l'errori DNS ci sò assai sorpresi. Avemu trovu chì POV Cloudflare sò in realtà situati in Cina, l'indirizzu di u situ si risolve in una IP anycast, ma i servitori DNS sò americani, per quessa chì e dumande DNS sò furzate à passà à traversu u cunfini, perchè qualchì volta fallenu.
Dopu avè clarificatu sta quistione cù CF, hè risultatu chì Ùn anu micca i so servitori DNS in Cina, è quandu serà hè ancu scunnisciutu.
Dunque, avemu decisu di pruvà solu Cloudflare DNS è cambiatu u mecanismu operativu Cloudflare per u nostru situ à u "DNS solu" Questu hè un modu quandu Cloudflare ùn proxy trafficu per ellu stessu, chì significa chì ùn furnisce micca prutezzione DDoS, CDN è altre funziunalità, è opera in u modu di un servitore DNS regular.
Stu stand hè mostratu schematicamente in a figura seguente. A figura piglia in contu a cunniscenza emergente chì i servitori DNS di Cloudflare sò daretu à un firewall.
In Catchpoint avemu eseguitu teste GET simplici (micca testi di navigatore), chì anu dimustratu assai fallimenti. Sò stati causati da i stessi errori DNS.
Avemu cuminciatu à debugging sti errori usendu dig è truvò chì nantu à a prima dumanda l'indirizzu hè determinatu currettamente, è nantu à a dumanda ripetuta ricevemu ogni volta SERVFAIL и micca trovu. Perchè questu succede di colpu?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)Ùn ci sò micca tali errori quandu si dumandanu direttamente i servitori Cloudflare NS:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192Questu significa chì u prublema hè da u latu di u servitore DNS "lucale" o di u servitore di u fornitore.
Ulteriori investigazioni anu revelatu chì SERVFAIL simu nantu à risolve AAAA- records.
Hè risultatu chì quandu dumandava da Cloudflare AAAA-record chì ùn esiste micca in u duminiu, Cloudflare hà rispostu А-una entrata chì hè un errore è non-cunformità cù u RFC. Perchè u risolve lucale (xxxx) Ùn mi piacia micca, è hà rispostu SERVFAIL. Stu cumpurtamentu hè chjaramente visibile in u logu sottu:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE rcvd: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; ANSWER SECTION:
semrushchina.cn. 300 IN A 220.170.186.192
;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE rcvd: 60
Avemu mandatu un rapportu di bug à Cloudflare, è l'anu riparatu dopu qualchì tempu. Hè risultatu interessante: in u mumentu ùn ci hè ancu un supportu IPv6 in Cina, cusì Cloudflare ùn pudia micca emette u so indirizzu IPv6 in risposta à una dumanda. AAAA- records. À a fine, tuttu hè statu risoltu in tale manera chì Cloudflare hà cuminciatu à risponde per a Cina NODATA à tali richieste.
Cusì, l'errori DNS in i testi di Catchpoint diminuinu drasticamente, ma micca cumpletamente. I timeout sò sempre quì:
È avemu cuminciatu à circà una altra suluzione.
In a prossima parte vi dicu cumu avemu pruvatu a nuvola cinese Alibaba Cloud, Cumu, cù l'aiutu di un pocu "magia" di Nginx, pudemu creà rapidamente suluzioni PoC (Proof of Concept), cumu avemu criatu suluzioni Multi-Cloud, una di quale ultimamente hà assai aiutatu à accelerà u travagliu di u serviziu. da a Cina.
Resta attenti!
Prossime parti
Source: www.habr.com
