Hvernig við brutumst í gegnum eldvegginn mikla í Kína (2. hluti)

РџСЂРІРμы!

Nikita er með þér aftur, kerfisfræðingur frá fyrirtækinu SEMrush. Og með þessari grein held ég áfram sögunni um hvernig við komum að lausninni Kínverskur eldveggur fyrir þjónustu okkar semrush.com.

В fyrri hluta Ég sagði:

• hvaða vandamál koma upp eftir að ákvörðunin er tekin „Við þurfum að láta þjónustu okkar virka í Kína“
• Hvaða vandamál hefur kínverska internetið?
• af hverju þarftu ICP leyfi?
• hvernig og hvers vegna við ákváðum að prófa prófunarbeðin okkar með Catchpoint
• hver var niðurstaðan af fyrstu lausn okkar byggða á Cloudflare China Network
• Hvernig við fundum villu í Cloudflare DNS

Þessi hluti er áhugaverðastur, að mínu mati, vegna þess að hann fjallar um sérstakar tæknilegar útfærslur á sviðsetningu. Og við munum byrja, eða réttara sagt halda áfram, með Fjarvistarsönnun Cloud.

Fjarvistarsönnun Cloud

Fjarvistarsönnun Cloud er nokkuð stór skýjaveita, sem hefur alla þá þjónustu sem gerir henni kleift að kalla sig heiðarlega skýjaveitu. Það er gott að þeir hafi tækifæri til að skrá sig fyrir erlenda notendur og að megnið af síðunni sé þýtt á ensku (fyrir Kína er þetta lúxus). Í þessu skýi geturðu unnið með mörgum svæðum heimsins, meginlandi Kína, sem og úthafs-Asíu (Hong Kong, Taívan osfrv.).

IPSEC

Við byrjuðum á landafræði. Þar sem prófunarsíðan okkar var staðsett á Google Cloud þurftum við að „tengja“ Alibaba Cloud við GCP, svo við opnuðum lista yfir staðsetningar þar sem Google er til staðar. Á því augnabliki voru þeir ekki enn með eigin gagnaver í Hong Kong.
Næsta svæði reyndist vera asía-austur1 (Taívan). Ali reyndist vera næsta svæði meginlands Kína við Taívan cn-Shenzhen (Shenzhen).

Með terraform lýst og hækkað allt innviði í GCP og Ali. 100 Mbit/s göng milli skýjanna fóru upp nánast samstundis. Hjá Shenzhen og Taívan voru sýndarvélar með umboðsþjónustu ræktaðar. Í Shenzhen er notendaumferð stöðvuð, send í gegnum göng til Taívan og þaðan fer hún beint á ytri IP þjónustu okkar í okkur-austur (Austurströnd Bandaríkjanna). Ping á milli sýndarvéla í gegnum göng 24ms, sem er ekki svo slæmt.

Á sama tíma settum við prófunarsvæði í Alibaba Cloud DNS. Eftir að hafa úthlutað svæðinu til NS Ali minnkaði upplausnartími úr 470 ms í 50 MS. Fyrir þetta var svæðið einnig á Cloudlfare.

Samhliða göngunum til asía-austur1 hækkaði önnur göng frá Shenzhen beint til okkur-austur4. Þar bjuggu þeir til fleiri proxy sýndarvélar og byrjuðu að prófa báðar lausnirnar, beina prófumferð með vafrakökum eða DNS. Prófunarbekknum er lýst með skýringarmynd á eftirfarandi mynd:

Töf fyrir jarðgöng reyndist vera sem hér segir:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint vafrapróf greindu frá frábærum framförum.

Bera saman prófunarniðurstöður fyrir tvær lausnir:

ákvörðun
Spenntur
Miðgildi
75 prósentustig
95 prósentustig

Cloudflare
86.6
18s
30s
60s

IPSec
99.79
18s
21s
30s

Þetta eru gögn úr lausn sem notar IPSEC göng um asía-austur1. Í gegnum us-east4 voru niðurstöðurnar verri og það voru fleiri villur, svo ég mun ekki gefa upp niðurstöðurnar.

Byggt á niðurstöðum þessarar prófunar á tveimur göngum, þar af öðru er lokað á næsta svæði við Kína, og hinu á lokaáfangastað, varð ljóst að mikilvægt er að „koma“ undan kínverska eldveggnum eins fljótt og mögulegt, og notaðu síðan hraðvirk net (CDN veitendur, skýjaveitur osfrv.). Það er engin þörf á að reyna að komast í gegnum eldvegginn og komast á áfangastað í einni svipan. Þetta er ekki fljótlegasta leiðin.

Almennt séð eru niðurstöðurnar ekki slæmar, hins vegar hefur semrush.com miðgildið 8.8 sekúndur og 75 prósentuhlutfall 9.4 sekúndur (í sama prófi).
Og áður en lengra er haldið langar mig að gera stuttan ljóðrænan útdrátt.

Ljóðræn tregða

Eftir að notandi fer inn á síðuna www.semrushchina.cn, sem leysir í gegnum „hraða“ kínverska DNS netþjóna, fer HTTP beiðnin í gegnum hröðu lausnina okkar. Svarinu er skilað eftir sömu leið, en lénið er tilgreint í öllum JS skriftum, HTML síðum og öðrum þáttum vefsíðunnar semrush.com fyrir viðbótartilföng sem þarf að hlaða þegar síðan er birt. Það er, viðskiptavinurinn leysir „aðal“ A-skrána www.semrushchina.cn og fer inn í hröðu göngin, fær fljótt svar - HTML síða sem segir:

• hlaðið niður svona og svona js frá sso.semrush.com,
• Fáðu CSS skrárnar frá cdn.semrush.com,
• og taka líka nokkrar myndir af dab.semrush.com
• og svo framvegis.

Vafrinn byrjar að fara á „ytri“ internetið fyrir þessar auðlindir, í hvert skipti sem hann fer í gegnum eldvegg sem eyðir viðbragðstíma.

En fyrra prófið sýnir niðurstöðurnar þegar engin úrræði eru á síðunni semrush.com, aðeins semrushchina.cn, og *.semrushchina.cn snýr að heimilisfangi sýndarvélarinnar í Shenzhen til að komast síðan inn í göngin.

Aðeins þannig, með því að ýta allri mögulegri umferð að hámarki í gegnum lausnina þína til að fara fljótt framhjá kínverska eldveggnum, geturðu fengið ásættanlegan hraða og vísbendingar um aðgengi að vefsíðum, svo og heiðarlegar niðurstöður lausnaprófa.
Við gerðum þetta án einnar kóðabreytingar á vöruhlið liðsins.

Undirsía

Lausnin fæddist nánast strax eftir að þetta vandamál kom upp. Við þurftum PoC (Proof of Concept) að eldveggslausnir okkar virka virkilega vel. Til að gera þetta þarftu að vefja allri umferð á síðuna inn í þessa lausn eins mikið og mögulegt er. Og við sóttum um undirsíu í nginx.

Undirsía er frekar einföld eining í nginx sem gerir þér kleift að breyta einni línu í svarhlutanum í aðra línu. Svo við breyttum öllum atburðum semrush.com á semrushchina.cn í öllum svörum.

Og... það virkaði ekki vegna þess að við fengum þjappað efni frá bakendunum, svo undirsía fann ekki nauðsynlega línu. Ég þurfti að bæta öðrum staðbundnum netþjóni við nginx, sem þjappaði svarið niður og sendi það áfram á næsta staðbundna netþjón, sem var þegar upptekinn við að skipta um strenginn, þjappa honum og senda hann á næsta proxy-þjón í keðjunni.

Þar af leiðandi, hvar myndi viðskiptavinurinn fá .semrush.com, fékk hann .semrushchina.cn og gekk hlýðnislega í gegnum ákvörðun okkar.

Hins vegar er ekki nóg að breyta einfaldlega léninu á einn veg, því bakendarnir búast enn við semrush.com í síðari beiðnum frá viðskiptavininum. Í samræmi við það, á sama netþjóni þar sem einhliða skiptingin er gerð, með því að nota einfalda reglubundna tjáningu fáum við undirlénið úr beiðninni, og þá gerum við proxy_pass með breyt $gestgjafi, sýnd í $subdomain.semrush.com. Það kann að virðast ruglingslegt, en það virkar. Og það virkar vel. Fyrir einstök lén sem krefjast mismunandi rökfræði, búðu einfaldlega til þínar eigin netþjónablokkir og gerðu sérstaka uppsetningu. Hér að neðan eru styttar nginx stillingar til skýrleika og sýnikennslu á þessu kerfi.

Eftirfarandi stilling vinnur úr öllum beiðnum frá Kína til .semrushchina.cn:

    listen 80;

    server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;

    sub_filter '.semrush.com' '.semrushchina.cn';
    sub_filter_last_modified on;
    sub_filter_once off;
    sub_filter_types *;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $subdomain.semrush.com;
        proxy_set_header X-Accept-Encoding $http_accept_encoding;
    }
}

Þessi stillingar umboð til localhost í port 83, og eftirfarandi stillingar bíður þar:

    listen 127.0.0.1:8083;

    server_name *.semrush.com;

    location / {
        resolver 8.8.8.8 ipv6=off;
        gunzip on;
        proxy_pass https://$host;
        proxy_set_header Accept-Encoding gzip;
    }
}

Ég endurtek, þetta eru klipptar stillingar.

Svona. Það kann að virðast flókið, en það er í orðum. Reyndar er allt einfaldara en gufusoðnar rófur :)

Lok fráfarar

Um tíma vorum við ánægð vegna þess að goðsögnin um fallandi IPSEC göng var ekki staðfest. En svo fóru göngin að falla. Nokkrum sinnum á dag í nokkrar mínútur. Smá, en það hentaði okkur ekki. Þar sem báðum göngunum var lokað Ali-megin á sama beini, ákváðum við að þetta væri kannski svæðisbundið vandamál og við þyrftum að hækka varasvæðið.

Þeir tóku það upp. Göngin byrjuðu að bila á mismunandi tímum, en bilunin virkaði vel fyrir okkur á andstreymisstigi í nginx. En svo fóru göngin að falla um svipað leyti :) Og aftur fóru að falla 502 og 504. Spenntur fór að versna svo við fórum að vinna í valkostinum með Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - þetta er tenging tveggja VPC frá mismunandi svæðum innan Alibaba Cloud, það er, þú getur tengt einkanet hvers svæðis innan skýsins við hvert annað. Og síðast en ekki síst: þessi rás hefur nokkuð ströng SLA. Það er mjög stöðugt bæði hvað varðar hraða og spenntur. En það er aldrei svona einfalt:

• það er MJÖG erfitt að fá það ef þú ert ekki kínverskir ríkisborgarar eða lögaðili,
• Þú þarft að borga fyrir hvern megabit af bandbreidd rásarinnar.

Að hafa tækifæri til að tengjast Meginlandi Kína и Overseas, bjuggum við til CEN á milli tveggja Ali-svæða: cn-Shenzhen и okkur-austur-1 (næst við okkur-austur4). Í Ali okkur-austur-1 hækkaði aðra sýndarvél þannig að það er ein í viðbót step.

Þetta varð svona:

Niðurstöður vafraprófunar eru hér að neðan:

ákvörðun
Spenntur
Miðgildi
75 prósentustig
95 prósentustig

Cloudflare
86.6
18s
30s
60s

IPSec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Frammistaðan er aðeins betri en IPSEC. En í gegnum IPSEC geturðu hugsanlega hlaðið niður á 100 Mbit/s hraða og í gegnum CEN aðeins á 5 Mbit/s hraða og meira.

Hljómar eins og blendingur, ekki satt? Sameina IPSEC hraða og CEN stöðugleika.

Þetta er það sem við gerðum, leyfðum umferð í gegnum bæði IPSEC og CEN ef bilun verður í IPSEC göngunum. Spenntur er orðinn miklu meiri, en hleðsluhraði vefsins skilur enn eftir sig. Svo teiknaði ég allar hringrásirnar sem við vorum búnar að nota og prófað og ákvað að prófa að bæta aðeins meira GCP við þessa hringrás, þ.e. hettu.

hettu

hettu - Er Global Load Balancer (eða Google Cloud Load Balancer). Það hefur mikilvægan kost fyrir okkur: í samhengi við CDN hefur það anycast IP, sem gerir þér kleift að beina umferð að gagnaverinu næst viðskiptavininum, þannig að umferð kemst fljótt inn á hraðvirkt net Google og minna fer í gegnum „venjulegt“ internetið.

Án þess að hugsa okkur tvisvar um hækkuðum við HTTP/HTTPS LB Við settum upp sýndarvélarnar okkar með undirsíu í GCP og sem bakenda.

Það voru nokkur kerfi:

• Notaðu Cloudflare China Network, en að þessu sinni ætti Origin að tilgreina alþjóðlegt IP GLB.
• Loka viðskiptavinum kl cn-Shenzhen, og þaðan umboð um umferðina beint til hettu.
• Farðu beint frá Kína til hettu.
• Loka viðskiptavinum kl cn-Shenzhen, þaðan umboð til asía-austur1 í gegnum IPSEC (í okkur-austur4 í gegnum CEN), farðu þaðan til GLB (í rólegheitum, það verður mynd og útskýring hér að neðan)

Við prófuðum alla þessa valkosti og nokkra fleiri blendinga:

• Cloudflare + GLB

Þetta kerfi hentaði okkur ekki vegna spenntur og DNS villna. En prófið var framkvæmt áður en villan var lagfærð á CF hliðinni, kannski er það betra núna (þetta útilokar þó ekki HTTP tímamörk).

• Ali + GLB

Þetta kerfi hentaði okkur heldur ekki hvað varðar spennutíma, þar sem GLB féll oft úr andstreymis vegna þess að ekki var hægt að tengjast á ásættanlegum tíma eða tímamörkum, því fyrir netþjón innan Kína er GLB heimilisfangið áfram fyrir utan, og því á bak við Kínverskur eldveggur. Galdurinn gerðist ekki.

• Aðeins GLB

Valkostur svipaður og sá fyrri, aðeins það notaði ekki netþjóna í Kína sjálfu: umferðin fór beint til GLB (DNS færslunum var breytt). Samkvæmt því voru niðurstöðurnar ekki viðunandi, þar sem venjulegir kínverskir viðskiptavinir sem nota þjónustu venjulegra netveitna hafa mun verri aðstöðu til að fara framhjá eldveggnum en Ali Cloud.

• Shenzhen -> (CEN/IPSEC) -> Umboð -> GLB

Hér ákváðum við að nota bestu lausnirnar:

• stöðugleika og tryggt SLA frá CEN
• háhraða frá IPSEC
• „Hraða“ netkerfi Google og hvaða útsendingu þess er.

Kerfið lítur eitthvað svona út: notendaumferð er hætt á sýndarvél í ch-Shenzhen. Nginx uppstraumar eru stilltir þar, sumir hverjir benda á einka IP netþjóna sem staðsettir eru í hinum enda IPSEC ganganna, og sumir andstreymis benda á einkanetföng netþjóna hinum megin við CEN. IPSEC stillt á svæði asía-austur1 í GCP (var það svæði sem var næst Kína á þeim tíma sem lausnin var búin til. GCP hefur nú einnig viðveru í Hong Kong). CEN - til svæðis okkur-austur1 í Ali Cloud.

Þá var umferð frá báðum endum beint að anycast IP GLB, það er að segja á næsta viðverustað Google, og fór í gegnum net þess til svæðisins okkur-austur4 í GCP, þar sem sýndarvélar voru í staðinn (með undirsíu í nginx).

Þessi blendingslausn, eins og við bjuggumst við, nýtti sér kosti hverrar tækni. Almennt séð fer umferð í gegnum hraðvirkt IPSEC, en ef vandamál koma upp, sleppum við þessum netþjónum fljótt og í nokkrar mínútur og sendum umferð aðeins í gegnum CEN þar til göngin verða stöðug.

Með því að innleiða 4. lausnina af listanum hér að ofan náðum við því sem við vildum og það sem fyrirtækið krafðist af okkur á þeim tímapunkti.

Niðurstöður vafraprófa fyrir nýju lausnina miðað við fyrri:

ákvörðun
Spenntur
Miðgildi
75 prósentustig
95 prósentustig

Cloudflare
86.6
18s
30s
60s

IPSec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

CDN

Allt er gott í lausninni sem við innleiddum, en það er ekkert CDN sem gæti flýtt fyrir umferð á svæðis- og jafnvel borgarstigi. Fræðilega séð ætti þetta að flýta fyrir síðuna fyrir endanotendur með því að nota hraðvirkar samskiptaleiðir CDN veitunnar. Og við hugsuðum um það allan tímann. Og nú er kominn tími á næstu endurtekningu á verkefninu: að leita og prófa CDN veitendur í Kína.

Og ég mun segja þér frá þessu í næsta, síðasta hluta :)

Heimild: www.habr.com