Tere kõigile!
Tere, mina olen Nikita — süsteemiinsener ettevõttest SEMrush. Täna räägin teile sellest, kuidas meie eesmärgiks sai tagada meie teenuse semrush.com usaldusväärne töö Hiinas ning milliste probleemidega me selle käigus kokku puutusime (arvestades meie andmekeskuse asukohta Ameerika Ühendriikide idakaldal).
See saab olema pikk lugu, jagatud mitmeks artikliks. Räägin, kuidas meil kõik toimus: alates täiesti mittefunktsioneerivast teenusest Hiinas kuni teenuse kvaliteedini, mis vastab Ameerika versioonile. Luban, et see on huvitav ja kasulik. Nii et, hakkame pihta.
Hiina interneti probleemid
Isegi kõige kaugem inimene võrguadministreerimise spetsiifikast on vähemalt korra kuulnud Suurest Hiina tulemüst. Oi, kõlab lahedalt, eks? Aga mis see tegelikult on, kuidas see töötab — see on päris keeruline küsimus. Internetis on palju artikleid, mis sellega tegelevad, aga tehnilisest küljest ei ole seda tulemüüris kunagi kirjeldatud. Mis pole muidugi üllatav. Tunnistan ausalt, et aasta jooksul ei suuda ma täpselt öelda, kuidas see töötab, kuid võin jagada oma tähelepanekuid ja praktilisi järeldusi. Alustame kuulujuttudest selle tulemüüri kohta.
Selle tulemüüri ümber on palju kuulujutte. Kogume kokku peamised ja huvitavad neist ühte nimekirja:
- Google, Facebook, Twitter ja muud sarnased teenused on Hiinas blokeeritud ja ei tööta.
- Iga liiklus, mis läbib Hiina piire, analüüsitakse ja piiratakse masinõppe abil (kahtlase liikluse korral), mis aeglustab selle liikumist, mis läbib piiri.
- Hiina julgeolekuasutused murravad läbi kõik krüpteeritud liikluse, mis läheb nende tulemüüri kaudu.
- VPN-tunnelid ja IPSEC-tunnelid on ebastabiilsed, kukuvad kokku ja neid blokeeritakse pidevalt.
- Mida lihtsam on krüpteerimine ja mida lihtsam on autentimiseks / andmete edastamiseks kasutatav parool, seda kiiremini see Hiina tulekahju seina läbib.
Siin on, mida me nende kuulujuttude kohta teada saime:
- Google, Facebook, Twitter ja teised sarnased teenused on tõepoolest blokeeritud (teie KOD), kuid paljud Google'i tehnilised domeenid, näiteks, ei ole blokeeritud ja töötavad (näiteks gstatic.com). Sealt järeldub, et ei tasu ettevaatamatult kõrvaldada kõiki näiliselt blokeeritud Google'i ja muid ressursse.
- Iga liikumine, mis ületab piiri, lisab tõepoolest aega märkimisväärse viivituse. Vaadake kahte tulemust. Üks sait, üks leht, lihtne GET curlEsimene mõõtmine on otse Hiinast (ilus linn Shenzhen). Teine mõõtmine on väljastpoolt Hongkongist (omab suveräänsust ja tema ning ülejäänud maailma vahel ei ole tulle). Linnade vahemaa on otseselt umbes 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/sPange tähele time_connect. Ja kokkuvõttes näete tulemust: tulemüür lisab 4 sekundit juurde, mis on täiesti liiga kaua.
- VPN ja IPSEC- tunnelid tõepoolest sageli kukuvad. Räägin sellest lähemalt hiljem.
- On olemas arvamus inimestelt, kes elavad Hiinas, et mida lihtsam on liikluse krüpteerimine, seda kiiremini see piirist läbi läheb, sest on lihtne mõista, et selles ei ole midagi ebaseaduslikku. Samuti saab "puhta" liiklus suuremat ribalaiust ja kiiruset läbimist, samas kui "must" liiklus, milles ei ole midagi arusaadavat, läbib vastupidi aeglasemalt. ifconfig.co HTTPS ja HTTP protokolli kaudu.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Kogu % Vastuvõetud % Ülekande Keskmine Kiirus Aeg Aeg Aeg Praegune
Laadimist Üleslaadimist Kogu Veedetud Jäänud Kiirus
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/"
% Kogu % Vastuvõetud % Ülekande Keskmine Kiirus Aeg Aeg Aeg Praegune
Laadimist Üleslaadimist Kogu Veedetud Jäänud Kiirus
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/s5 sekundi erinevus 13 baiti laadimisajas. Samas, tehes sellist testi mitu korda, võib märgata, et GET HTTP kaudu lõppeb üldiselt sama ajaga iga kord, samas kui HTTPS-i puhul reageerib sait mõnikord 3, 5, 10 ja isegi 17 sekundi pärast. Mõnikord esinevad SSL-i vead:
Tundmatu SSL-protokolli viga ühenduses ifconfig.co:443.
Nii, mida me nüüd omame:
- Ülaltoodud probleemid, mida tekitab Hiina tulemüür.
- Pingid väliste ressursside ja tunnelite sees aeg-ajalt kaovad.
- Latentsus kahe punkti vahel muutub pidevalt, ja sageli on see lihtsalt ettearvamatu. Erinevaid linnu/regiona ühendades lood, et geograafilise asukoha põhjal on latentsus väiksem, aga saad täpselt vastupidise olukorra.
- Interneti ja sidekanalid töötavad mõnikord kiiresti, mõnikord aeglaselt. Siin on väike sõltuvus ööajast ja nädalapäevast, kuid mitte alati.
- DNS-päringud Hiinast välismaailma mõnikord ületavad lubatud ajautumise.
Pilt joonistub lihtsalt 'suurepärane'.
Andmed keskus, nagu juba ütlesin, on meil Ameerika Ühendriikide idas, ning kogu SEMrush koosneb kümnetest omavahel seotud toodetest, tagatud ja eesliidestest, andmebaasidest, ning kõik see asub DCs ja pilvedes. Meie, süsteemiadministraatorite meeskonnana, seiname ülesanne oli kiiresti alustada töötamist Hiinas minimaalsete pingutustega.
Pidime vastama olulisele küsimusele: kas saame väikeste pingutustega lahendada kõik Hiina interneti ja tulemüüri probleeme võrgu/pilvede/serverite tasandil?
Alustasime .
ICP-litsents
Et olla võimeline paigutama oma teenuseid Hiina (Mandri-Hiina) piires ja korraldama katseid, tuleb esmalt saada ICP-litsents domeeni jaoks.
Kui teie saidi kasutajate liiklus suunatakse Mandri-Hiinas ja teie domeenil ei ole ICP-luba, siis teie liiklus blokeeritakse teenusepakkuja/hotelli poolt. Huvitav, et ICP-luba registreerib konkreetse teenusepakkuja, olgu selleks Cloudflare või Alibaba Cloud. Seetõttu, kui olete saanud ICP-luba Cloudflare'i jaoks ja oma veebisaiti seal majutanud, ei saa te hiljem „sujuvalt“ Alibaba Cloudile üle minna. Selleks tuleb lisada veel üks hostimine selle litsentsi alla.
ICP-luba domeeni jaoks omades saime välja mõelda ja rakendada konkreetseid tehnilisi ideid ja lahendusi.
Lahenduste testimine
Kuid enne, kui hakkame looma stendi variante, reguleerima seadmeid, optimeerima saidi tööd ja kiirus, peab valima testimistööriista, et näha, millised meie tegevused parandavad või vastupidi halvendavad saidi tööd.
Meie testimisriist peab vastama kahele peamisele nõudmisele:
- see peab võimaldama teste käivitada Hiinas,
- ja see peab sisaldama brauseriteste.
Nii leidsime ! Neil on suurepärane katvus testimispunktide osas kogu maailmas. Hiinas saab selle tööriista abil teste käivitada ka 100500 provintsist. Igas on mitu erinevat pakkujat + võimalus teha Backbone-teste (midagi sarnast virtuaalmasinale andmekeskuses) ja Lastmile-teste (maksimaalselt lähedased kasutustingimustele, aka tööjaam). Viimane testitüüp on kallim.
Aastase lepingu sõlmimisega (vähem pole võimalik) alustasime tööriista uurimist. Tunnistan, et olime selle funktsionaalsusest meeldivalt üllatunud. Saame käivitada:
- DNS-testid,
- Veebi testid (brauser, lihtne GET/POST, mobiilse kliendi emulatsioon jne),
- Tehingu kontrollid (näiteks sisselogimine),
- API-testid,
- Ping, traceroute, NTP jne.
Kogu seda ei saa üles lugeda. Ja mis kõige tähtsam, iga testi saab üsna hästi kohandada, lisades hulga päiseid ja muid parameetreid. Tulemuseks on tohutu hulk teavet, mis kirjeldab täielikult teie testi. Kui rääkida meie jaoks kõige huvitavamast (brauseritestidest), siis tulemus sisaldab:
- Connect, Wait, Load, SSL, DNS aeg,
- TTFB, TTLB, Dokumendi täitmine, Renderdamise aeg, DOM laadimine,
- Response (midagi, mis on sarnane Time To First Byte'ile), Webpage Response (midagi, mis on sarnane Time To Last Byte'ile),
- Iga percentile, Average, Median aeg
- Ja nii edasi.
Seega aitavad kõik need mõõdikud suurepäraselt jälgida muutusi ja mõista, kas on paremini läinud. Me uurisime peamiselt Response, Webpage Response, Median, 75. ja 95. percenti.
Oluline küsimus, mis oli õhus alates algusest: kas võib usaldada Catchpoint'i?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
See on suur probleem, kuna Venemaal on praktiliselt võimatu usaldusväärselt teada, kuidas veebisait Hiinast töötab. Socks-proxy kaudu virtuaalmasina kaudu on tulemuseks veebisaidi laadimine paar minutit, mis on testide jaoks lihtsalt vastuvõetamatu, seega ainus käsitsi testimise variant jääb curl ja lihtsad GET käsud konsoolist ajamõõtmiseks. See aitab, sest see test peegeldab hästi võrgu lahenduse töökiirust, ja kui on olemas ka brauseritestid, siis on see suurepärane.
Hiljem käisime ise Hiinas ja veendusime, et Catchpoint'i usaldada saab, see peegeldab üsna täpselt reaalset töökiirus.
Cloudflare Hiina võrk
Kuna peamise domeeni semrush.com puhul kasutame edukalt Cloudflare'i, otsustasime kohe proovida nende funktsiooni nimega . See valik on aktiveeritav ainult Enterprise-saitidele eraldi taotluse ja tasu eest. Samuti on see saadaval ainult saitidele, millel on vastav ICP-luba, kus pakkujana on märgitud Cloudflare. Pärast aktiveerimist on saidile saadaval Cloudflare'i "Hiina CDN" – liiklus Hiina piirkondadest jõuab lähimasse CF PoP-i (Presence Point), edasi toimetatakse see tema võrkudes või partnerite võrgu kaudu origini.
Allpool on esitatud selle testseina skeem.
See on meie jaoks suurepärane lahendus. Tundub, et teine domeen on samuti CF-i all, mis ei suurenda ettevõttes kasutatavate lahenduste arvu ning praktiliselt ei komplitseeri infrastruktuuri.
Käivitame brauseritestid ja siin on tulemused:
Punased diamondid tähistavad testide ebaõnnestumisi. Alumised ebaõnnestumised on DNS vead (resolve timeout). Ülemised ebaõnnestumised on ajaületused.
Tööaeg: 86,6
Mediaan: 18s
75. percentiil: 29,3s
95. percentiil: 60s
Mediaan pärast koormuse eemaldamist reCaptcha (Google'i teenus, mis on Hiinas blokeeritud), langes 28-lt 18 sekundile. Kuid need on ikkagi kohutavad näitajad, kui arvesse võtta, et sama testi jaoks semrush.com (USA-st) andis vähem kui 10 sekundit 95% kasutajatele (USA-st) samal lehel (staatika + dünaamika).
Iga testi saab vaadata ja uurida Waterfall ja muid üksikasjalikumaid parameetreid. Oleme hakanud uurima vigade põhjuseid ja kui ajavahemikest on kõik enam-vähem selge: internet Hiinas “kui töötab siis töötab, kui ei, siis ei tööta”, siis on ressurside kiire laadimine väljastpoolt ebastabiilne ja varieeruv, siis DNS-vead üllatasid meid tõsiselt. Avastasime, et PoP Cloudflare'il on tõepoolest Hiinas, veebisaidi aadress resolvib ühte anycast IP-d, kuid kasutatavad DNS-serverid on Ameerikast, mistõttu peavad DNS-päringud minema piiri läbi, seetõttu neil mõnikord ebaõnnestuvad.
Selgitasime seda küsimust CF-ilt ja selgus, et neil ei ole Hiinas oma DNS-servereid, ja kuna need seal olema hakkavad — ei ole seni teada.
Seetõttu otsustasime testida ainult Cloudflare'i DNS-i ja muutsime Cloudflare'i töömehhanismi meie saidil režiimiks “Ainult DNSSee on selline režiim, kus Cloudflare ei suuna liiklust enda kaudu, mis tähendab, et DDoS-kaitset, CDN-i ja muid funktsioone ei pakuta ning see töötab tavalise DNS-serveri režiimis.
Seda seadet on kujutatud järgmisel joonisel. Joonisel on arvesse võetud uusi teadmisi sellest, et Cloudflare'i DNS-serverid on tulemüürist taga.
Catchpointis käivitasime lihtsad GET-testid (mitte brauseripõhised), mis näitasid palju tõrkeid. Nende põhjuseks olid kõik samad DNS-vead.
Alustasime nende vigade tõrgetega dig ja avastasime, et esimesel päringul määratakse aadress õigesti, kuid igasuguste järgmiste päringute korral saame pidevalt SERVFAIL ja leiutatud. Kust see nüüd tuli?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn on aadress 220.170.186.192
Host semrushchina.cn ei leitud: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn on aadress 220.170.186.192
Host semrushchina.cn ei leitud: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn on aadress 220.170.186.192
Host semrushchina.cn ei leitud: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn on aadress 220.170.186.192
Host semrushchina.cn ei leitud: 2(SERVFAIL)Cloudflare'i NS-serverite otsese pärimise korral selliseid vigu ei esine:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Kasutame domeeni serverit:
Nimi: ray.ns.cloudflare.com.
Aadress: 173.245.59.138#53
Aliasid:
semrushchina.cn omab aadressi 220.170.186.192
semrushchina.cn omab aadressi 220.170.186.192
Kasutame domeeni serverit:
Nimi: ray.ns.cloudflare.com.
Aadress: 173.245.59.138#53
Aliasid:
semrushchina.cn omab aadressi 220.170.186.192
semrushchina.cn omab aadressi 220.170.186.192Seega on probleem "kohalikus" DNS-serveris või teenusepakkuja serveris.
Edasiuurimine näitas, et SERVFAIL saame resolverilt AAAA-kirjeid.
Tundub, et Cloudflare'i päringul AAAA-kirje, mida domeenis ei eksisteeri, Cloudflare vastas A-kirjega, mis on viga ja ei vasta RFC-le. Seetõttu ei meeldinud see kohalikule resolverile (x.x.x.x), ja ta vastas SERVFAIL. Allolevas logis on see käitumine selgelt nähtav:
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
Me saatsime Cloudflare'ile bug-aruande ja nad lahendasid selle mõne aja pärast. Selgus, et Hiinas puudub endiselt IPv6 tugi, seetõttu ei saanut Cloudflare seal oma IPv6 aadressi päringutele vastuseks anda. AAAA-kirjed. Lõpuks lahendati asi nii, et Hiina jaoks hakkas Cloudflare vastama NODATA taolistele päringutele.
Nii, DNS vead Catchpointi testides on järsult vähenenud, kuid mitte täielikult. Ajaülesanded ei ole samuti kadunud:
Ja me hakkasime otsima teist lahendust.
Järgmises osas räägin, kuidas me testisime Hiina pilveteenuseid Alibaba Cloud, kuidas me väikese Nginxi "maagia" abil suutsime kiiresti luua PoC (Proof of Concept) lahendusi ning kuidas me tegime Multi-Cloud lahendusi, millest üks aitas oluliselt kiirendada teenuse toimimist Hiinast.
Jälgige meid!
Järgmised osad
Allikas: habr.com
