Halló allir!
Nikita er í sambandi - kerfisfræðingur frá fyrirtækinu SEMrush. Í dag mun ég segja þér frá því hvernig við stóðum frammi fyrir því verkefni að tryggja stöðugleika semrush.com þjónustu okkar í Kína og hvaða vandamál við lentum í við innleiðingu hennar (miðað við staðsetningu gagnaversins okkar á austurströnd Bandaríkjanna).
Þetta verður stór saga sem skiptist í nokkrar greinar. Ég skal segja þér hvernig þetta gerðist allt fyrir okkur: frá algjörlega óvirkri þjónustu frá Kína, til frammistöðuvísa þjónustunnar á stigi bandarískrar útgáfu hennar fyrir Bandaríkjamenn. Ég lofa að það verður áhugavert og gagnlegt. Svo, við skulum fara.
Vandamál kínverska internetsins
Jafnvel sá sem er lengst frá sérstöðu netstjórnunar hefur heyrt um Frábær eldveggur Kína. Vá, hljómar flott, ekki satt? En hvað það er og hvernig það virkar í raun og veru er frekar flókin spurning. Þú getur fundið margar greinar á netinu um þetta, en frá tæknilegu sjónarhorni er uppbyggingu þessa eldveggs hvergi lýst. Sem kemur þó ekki á óvart. Ég skal viðurkenna strax að miðað við árangur árs vinnu, get ég ekki sagt nákvæmlega hvernig það virkar, en ég get sagt þér frá athugasemdum mínum og hagnýtum niðurstöðum. Og við byrjum á sögusögnum um þennan eldvegg.
Það eru margar sögusagnir um einmitt þennan eldvegg. Við skulum safna helstu og áhugaverðustu þeirra í einn lista:
- Google, Facebook, Twitter og aðrar svipaðar þjónustur eru lokaðar og virka ekki í Kína.
- Öll umferð sem fer UTAN Kína og INN í Kína er flokkuð og takmörkuð með því að nota vélanám (ef um er að ræða grunsamlega umferð), sem hægir mjög á henni (umferð) sem fer í gegnum landamærin.
- Kínverskar njósnastofnanir munu hakka alla dulkóðaða umferð sem fer í gegnum eldvegg þeirra.
- VPN göng, IPSEC göng eru óstöðug, hrun og eru stöðugt læst.
- Því einfaldari sem dulkóðunin er, því einfaldari sem aðgangssetningin er notuð til að auðkenna/dulkóða umferð, því hraðar fer hún í gegnum kínverska eldvegginn.
Hér er það sem við komumst að um þessar sögusagnir:
- Google, Facebook, Twitter og önnur sambærileg þjónusta er örugglega læst (KO þitt), en mörg tæknileg Google lén, til dæmis, eru ekki bönnuð og virka (sama gstatic.com). Niðurstaðan leiðir af þessu: þú ættir ekki kæruleysislega að skera út öll Google og önnur úrræði sem virðast vera læst.
- Öll umferð sem fer framhjá landamærunum bætir í raun alvarlegri töf við tímann. Skoðaðu niðurstöðurnar tvær. Ein síða, ein síða, einfalt FÁ Curl'om. Fyrsta mælingin var frá Kína sjálfu (hinu fallegu borginni Shenzhen). Sá síðari var mældur að utan frá Hong Kong (það hefur fullveldi og það er enginn eldveggur á milli þess og heimsins). Fjarlægðin milli borganna í beinni línu er um það bil 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/sAthugið að tíma_tenging. Og almennt séð sérðu niðurstöðuna: eldveggurinn bætir við 4 aukasekúndum, sem er óskaplega langt.
- VPN og IPSEC göng bila oft. Ég mun ræða þetta aðeins síðar og nánar. VPN netþjónar sem notendur nota eru lokaðir með tímanum (venjulega innan dags eftir upphaf notkunar).
- Það er álit sem borist hefur frá fólki sem býr í Kína að því einfaldari sem dulkóðun umferðar er því hraðar fari hún í gegnum landamærin, því auðvelt sé að skilja að það sé ekkert ólöglegt við það. Og á sama hátt fær „hrein“ umferð meiri bandbreidd og umferðarhraða á meðan „óhrein“ umferð, sem ekkert er hægt að skilja í, fær þvert á móti hægari ferð. Til dæmis mun ég nota krulla til að ifconfig.co í gegnum HTTPS og HTTP samskiptareglur.
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/s5 sekúndur munur fyrir heildar niðurhalstíma upp á 13 bæti. Þar að auki, þegar þú gerir slíkt próf nokkrum sinnum, geturðu tekið eftir því að GET á HTTP er lokið á yfirleitt sama tíma í hvert skipti, á meðan á HTTPS svarar vefsíðan stundum á 3, 5, 10 og jafnvel 17 sekúndum. Stundum gerast SSL villur:
Unknown SSL protocol error in connection to ifconfig.co:443.
Svo hvað höfum við:
- Vandamálunum sem kínverski eldveggurinn skapaði er lýst hér að ofan.
- Pings til ytri auðlinda og inni í göngum hverfa reglulega.
- Seinkun milli tveggja punkta er stöðugt að breytast og oft er hún einfaldlega ófyrirsjáanleg. Þegar mismunandi borgir/svæði eru tengdar saman reiknarðu með því að miðað við landfræðilega staðsetningu svæðanna verði seinkunin minni en þú færð nákvæmlega þveröfuga stöðu.
- Netið og samskiptaleiðir eru ýmist hraðar eða hægar. Það er svolítið háð tíma dags og vikudegi, en ekki alltaf.
- DNS beiðnir til umheimsins frá Kína fara stundum yfir leyfilegan tímamörk.
Myndin sem birtist er einfaldlega „frábær“.
Gagnaverið, eins og ég sagði þegar, er í austurhluta Bandaríkjanna og allt SEMrush samanstendur af tugum samtengdra vara, bakenda, framenda, gagnagrunna og allt þetta í DC og skýjum. Við, sem teymi kerfisstjóra, fengum það verkefni að byrja fljótt að vinna í Kína með lítilli fyrirhöfn.
Við þurftum að svara mikilvægri spurningu: Er hægt að komast af með litlum tilkostnaði og leysa öll vandamál sem tengjast kínverska internetinu og eldveggnum á net-/skýja-/miðlarastigi?
Við byrjuðum á því að taka á móti .
ICP leyfi
Til þess að geta hýst þjónustu þína innan Kína (meginland Kína) og framkvæmt próf verður þú fyrst að fá ICP leyfi fyrir lénið.
Ef notendaumferð vefsvæðis þíns er hætt innan meginlands Kína, og ef lénið þitt er ekki með ICP leyfi, verður umferð þín lokuð á ISP/hýsingarhliðinni. Athyglisvert er að ICP leyfið inniheldur tiltekinn veitanda, hvort sem það er Cloudflare eða Alibaba Cloud. Þess vegna, ef þú fékkst ICP leyfi fyrir Cloudflare og hýstir vefsíðuna þína hjá þeim, muntu ekki geta „óaðfinnanlega“ flutt yfir í Alibaba Cloud. Þú þarft að bæta annarri hýsingu við þetta leyfi.
Eftir að hafa fengið ICP leyfi fyrir lénið gátum við komið með og útfært sérstakar tæknilegar hugmyndir og lausnir.
Prófunarlausnir
En áður en þú býrð beint til sviðsetningarvalkosti, snýrð hnúðunum, fínstillir afköst síðunnar og hraða hennar, þarftu að velja tól til að prófa það til að sjá hvaða aðgerðir okkar bæta eða þvert á móti versna frammistöðu síðunnar.
Prófunartæki okkar þurfti að uppfylla tvær meginkröfur:
- það ætti að geta keyrt próf frá Kína,
- það verður að hafa vafrapróf.
Svo fundum við ! Þeir hafa frábæra umfjöllun um prófunarstaði um allan heim. Í Kína er einnig hægt að keyra prófanir frá 100500 héruðum í gegnum þetta tól. Hver hefur nokkra mismunandi veitendur + getu til að gera Burðarás-próf (eitthvað eins og sýndarvél í gagnaveri) og Lastmile-próf (eins nálægt notendaaðstæðum og mögulegt er, svokallað vinnustöð). Síðarnefnda tegund prófa er dýrari.
Eftir að hafa gert árssamning (minna en það er ekki hægt), fórum við að rannsaka tækið. Í hreinskilni sagt kom virkni þess skemmtilega á óvart. Þú getur keyrt:
- DNS próf,
- Vefpróf (vafrapróf, einföld GET/POST, eftirlíking farsímabiðlara osfrv.),
- Viðskiptaathuganir (til dæmis innskráning),
- API próf,
- Ping, traceroute, NTP osfrv.
Þú getur ekki skráð allt. Og síðast en ekki síst er hægt að aðlaga hvert próf nokkuð vel með því að bæta við fullt af hausum og öðrum breytum. Úttakið er mikið magn upplýsinga sem lýsir prófinu þínu að fullu. Ef við tölum um áhugaverðustu hlutina fyrir okkur (vafrapróf), þá inniheldur niðurstaðan:
- Tengjast, bíða, hlaða, SSL, DNS tími,
- TTFB, TTLB, skjali lokið, flutningstími, DOM hleðsla,
- Svar (eitthvað nálægt Time To First Byte), Webpage Response (eitthvað nálægt Time To Last Byte),
- Hvaða hundraðshluti sem er, meðaltal, miðgildi tíma
- O.fl.
Í samræmi við það eru allar þessar mælingar frábærar til að sjá breytingar og skilja hvort hlutirnir hafi batnað. Við skoðuðum aðallega Svar, vefsíðusvörun, miðgildi, 75 og 95 prósentur.
Mikilvæg spurning sem lá í loftinu frá upphafi: Geturðu treyst Catchpoint?? Endurspeglar þetta tól raunverulegan hleðsluhraða vefsvæðisins í Kína frá mismunandi borgum, eða er þetta bara einhvers konar próf í lofttæmi sem hefur ekkert með raunverulega notendaupplifun að gera?
Þetta er mikið vandamál, því að vera í Rússlandi er næstum ómögulegt að komast að áreiðanlega hvernig síða frá Kína virkar. Með því að gera sokka-proxy í gegnum sýndarvél er lokaniðurstaðan sú að síða hleðst innan nokkurra mínútna, sem er einfaldlega óviðunandi fyrir próf, þannig að eini möguleikinn fyrir handvirka prófun er krullað og einfalt GET frá stjórnborðinu með tímamæli . Þetta hjálpar vegna þess að þetta próf endurspeglar vel hraða netlausnarinnar og ef það eru líka vafrapróf þá er það mjög gott.
Seinna fórum við sjálf til Kína og vorum sannfærð um það Þú getur treyst Catchpoint; það endurspeglar alveg nákvæmlega raunverulegan árangursvísa.
Cloudflare China Network
Þar sem við notum Cloudflare með góðum árangri fyrir aðallénið semrush.com, ákváðum við að prófa strax eiginleika þeirra sem kallast . Þessi valkostur er aðeins virkur fyrir Enterprise síður sé þess óskað og gegn aukagjaldi. Það er líka aðeins í boði fyrir síður sem hafa viðeigandi ICP leyfi sem skráir Cloudflare sem veitanda. Eftir að það hefur verið virkjað verður „kínverska CDN“ frá Cloudflare tiltækt fyrir síðuna - umferð frá kínverskum svæðum lendir á næsta PoP (Points of Presence) CF, og síðan í gegnum net þess eða net veitenda/samstarfsaðila er hún send til upprunans. .
Skýringarmynd þessa prófunarbekks er sýnd hér að neðan.
Þetta er frábær kostur fyrir okkur. Það kemur í ljós að annað lénið verður einnig fyrir CF, sem bætir ekki við fjölda lausna sem notaðar eru í fyrirtækinu og flækir líka nánast ekki innviðina.
Við keyrðum vafrapróf og þetta er það sem gerðist:
Rauðir demantar eru prófbilun. Skrárnar hér að neðan eru DNS villur (leystu út tímamörk). Mistökin á toppnum eru tímamörk.
Spenntur: 86.6
Miðgildi: 18 sek
75 prósentuhlutfall: 29.3s
95 prósentuhlutfall: 60s
Miðgildi, eftir að hleðsla var fjarlægð reCAPTCHA (Google þjónusta lokað í Kína) minnkaði úr 28 í 18 sekúndur. En þetta eru samt hræðilegar niðurstöður, miðað við að sama próf fyrir semrush.com (frá Bandaríkjunum) gaf minna en 10 sekúndur fyrir 95% notenda (frá Bandaríkjunum) á sömu síðu (static + dynamic).
Þú getur farið í hvert próf og skoðað Foss og aðrar ítarlegri breytur. Við byrjuðum að rannsaka ástæður villanna og ef allt er meira eða minna ljóst fyrir tímamörk: Internetið í Kína „hreyfast inn og út“, vegna þessa er tengingarhraði og hleðsla auðlinda frá útlöndum óstöðug og ójafn, þá komu DNS villurnar okkur mjög á óvart. Við fundum það PoP Cloudflare eru í raun og veru staðsett í Kína, heimilisfang vefsvæðisins breytist í eitt anycast IP, en DNS netþjónarnir eru amerískir, þess vegna neyðast DNS beiðnir til að fara yfir landamærin, svo stundum mistakast þær.
Eftir að hafa skýrt þessa spurningu með CF, kom í ljós að Þeir eru ekki með sína eigin DNS netþjóna í Kína, og hvenær það verður er enn óvíst.
Þess vegna ákváðum við að prófa aðeins Cloudflare DNS og breyttum Cloudflare stýrikerfi fyrir síðuna okkar í "Aðeins DNS" Þetta er háttur þegar Cloudflare sendir ekki proxy-umferð í gegnum sjálft sig, sem þýðir að það veitir ekki DDoS vernd, CDN og aðra eiginleika, og starfar í stillingu venjulegs DNS netþjóns.
Þessi standur er sýndur á skýringarmynd á eftirfarandi mynd. Myndin tekur mið af þeirri vitneskju sem hefur komið fram um að DNS netþjónar Cloudflare séu á bak við eldvegg.
Hjá Catchpoint keyrðum við einföld GET próf (ekki vafrapróf), sem sýndu mikið af bilunum. Þau voru af völdum sömu DNS villanna.
Við byrjuðum að kemba þessar villur með því að nota grafa og komist að því að við fyrstu beiðni er heimilisfangið rétt ákvarðað og við endurtekna beiðni fáum við í hvert skipti SERVFAIL и ekki fundið. Af hverju gerist þetta allt í einu?
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)Það eru engar slíkar villur þegar spurt er beint um Cloudflare NS netþjóna:
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.192Þetta þýðir að vandamálið er hliðina á „staðbundnum“ DNS netþjóni eða netþjóni þjónustuveitunnar.
Frekari rannsókn leiddi í ljós það SERVFAIL við tökum á okkur ákvörðun AAAA-skrár.
Það kom í ljós að þegar óskað var eftir Cloudflare AAAA-skrá sem er ekki til á léninu, svaraði Cloudflare А-færsla sem er villa og ósamræmi við RFC. Hvers vegna leysir staðbundinn (xxxx) Mér líkaði það ekki og hann svaraði SERVFAIL. Þessi hegðun er greinilega sýnileg í skránni hér að neðan:
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
Við sendum villuskýrslu til Cloudflare og þeir lagfærðu hana eftir nokkurn tíma. Það reyndist áhugavert: í augnablikinu er enn enginn IPv6 stuðningur í Kína, svo Cloudflare gat ekki gefið út IPv6 vistfangið sitt þar sem svar við beiðni AAAA-skrár. Á endanum var allt leyst á þann hátt að Cloudflare fór að svara fyrir Kína ENGIN GÖGN við slíkum beiðnum.
Þannig fækkaði DNS villum í Catchpoint prófum verulega, en ekki alveg. Tímamörk eru enn hér:
Og við byrjuðum að leita að annarri lausn.
Í næsta hluta mun ég segja þér hvernig við prófuðum kínverska skýið Fjarvistarsönnun Cloud, hvernig, með hjálp smá „töfra“ Nginx, tókst okkur fljótt að búa til PoC (Proof of Concept) lausnir, hvernig við bjuggum til Multi-Cloud lausnir, ein þeirra hjálpaði að lokum að hraða vinnu þjónustunnar frá Kína.
Haltu áfram!
Næstu hlutar
Heimild: www.habr.com
