Helló!
Ismét itt van Nikita, a rendszermérnök a cégtől SEMrush. Ezzel a cikkel folytatom a történetet arról, hogy hogyan találtunk megoldást a megkerülésére a kínai tűzfalnak a semrush.com szolgáltatásunkhoz.
A elmondtam:
- milyen problémák merülnek fel, amikor a döntés megszületik, hogy "úgy kell megoldanunk, hogy a szolgáltatásunk működjön Kínában"
- milyen problémák vannak a kínai interneten
- miért szükséges az ICP-licenc
- hogyan és miért döntöttünk úgy, hogy teszteljük a tesztelési környezetünket a Catchpoint segítségével
- milyen eredménye volt az első megoldásunknak, ami a Cloudflare China Network-en alapult
- hogyan találtunk hibát a DNS Cloudflare-ben
Ez a rész a legérdekesebb, véleményem szerint, mert a konkrét technikai megvalósításokra összpontosít. És kezdjük, pontosabban folytassuk, Alibaba Cloud.
Alibaba Cloud
Alibaba Cloud — egy meglehetősen nagy felhőszolgáltató, amely minden szolgáltatást kínál, ami lehetővé teszi számára, hogy jogosan nevezze magát felhőszolgáltatónak. Jó, hogy lehetőségük van külföldi felhasználóknak regisztrálni, és hogy az oldal nagy része angolra van lefordítva (ez Kínában egy luxus). Ezen a felhőn keresztül sok régióval lehet dolgozni a világban, a kínai szárazföldön és Óceániai Ázsiában (Hongkong, Tajvan stb.).
IPSEC
A földrajzzal kezdtük. Mivel a tesztoldalunk a Google Cloud-ban volt, össze kellett "kötni" az Alibaba Cloudot a GCP-vel, ezért megnyitottuk a helyszínek listáját, ahol a Google működik. Akkor még nem volt saját adatközpontjuk Hongkongban.
A legközelebbi régió a következő volt asia-east1 (Tajvan). Az Ali számára a legközelebbi régió a szárazföldi Kínához Tajvanhoz a következő volt cn-shenzhen (Shenzhen).
A segítségével terraform leírta és feltette az egész infrastruktúrát a GCP-be és Aliba. A 100 Mbit/s-os alagút a felhők között gyakorlatilag azonnal felállt. Shenzhen és Tajvan oldalán proxy virtuális gépek kerültek felállításra. Shenzhenben a felhasználói forgalom a tunnelen keresztül érkezik Tajvanra, ahonnan közvetlenül a szolgáltatásunk külső IP-címére megy us-east (Egyesült Államok Keleti Part). A ping a virtuális gépek között az alagúton 24 ms, ami nem túl rossz.
Egyidejűleg tesztzónát helyeztünk el Alibaba Cloud DNS. A zóna NS Ali-ra történő delegálása után a feloldási idő 470 ms-ról 50 ms-racsökkent. Előtte a zóna is Cloudflare-en volt.
Párhuzamosan az alagúton keresztül asia-east1 még egy alagutat állítottunk fel Shenzhenből közvetlenül us-east4. Itt további virtualizált proxyk készültek, és elkezdték mérni mindkét megoldást, tesztforgalmat irányítva Cookies vagy DNS segítségével. A tesztkörnyezet vázlatosan a következő ábrán látható:
A tunelés késleltetése a következő lett:
Ali cn-shenzhen GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms
A Catchpoint böngészőtesztek kiváló javulást mutattak az eredményekben.
Hasonlítsa össze a két megoldás tesztjeinek eredményeit:
Megoldás
Uptime
Medián
75. percentilis
95. percentilis
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
Ezek az IPSEC-tunelt használó megoldás adatai: asia-east1. A us-east4 átjárón keresztül a results gyengébbek voltak, és több hiba is előfordult, ezért azokat nem fogom bemutatni.
A teszt összegzése alapján, melyben az egyik túnel Kínához legközelebb eső régióban terminálódik, míg a másik a végső célállomáson, nyilvánvalóvá vált, hogy minél gyorsabban „ki kell bújni” a kínai tűzfal alól, majd a gyors hálózatokat kell használni (CDN-szolgáltatók, felhőszolgáltatók stb.). Nem érdemes egy lépésben átlépni a tűzfalat és a célhelyre kerülni. Ez nem a leggyorsabb mód.
Összességében az eredmények jónak mondhatók, azonban a semrush.com mediánja 8.8s, és a 75. percentilis 9.4s (ugyanazt mérve).
És mielőtt tovább lépnénk, szeretnék egy kis lírai kitérőt tenni.
Lírai kitérő
Miután a felhasználó belép a weboldalra www.semrushchina.cn, amely a „gyors” kínai DNS-szervereken keresztül oldódik fel, a HTTP-kérés a mi gyors megoldásunkon keresztül halad. A válasz ugyanazon az úton tér vissza, de minden JS-szkriptben, HTML-oldalon és egyéb weboldal-elemen meg van adva a semrush.com domain, amely további források betöltésére szolgál az oldal renderelésekor. Tehát az ügyfél feloldja a „fő” A-rekordot www.semrushchina.cn, és belép a gyors alagútba, gyorsan kap válaszként egy HTML-oldalt, amelyben szerepel:
- töltsd le ezt a js-t a sso.semrush.com-tól,
- a CSS fájlokat a cdn.semrush.com-ról hozd el,
- és még képeket is szerezz a dab.semrush.com-ról.
- és így tovább.
A böngésző elkezd az „externál” interneten keresni ezeket a forrásokat, minden alkalommal áthaladva a válaszidőt emésztő tűzfalon.
De az előző tesztben bemutatott eredmények, amikor az oldalon nincsenek források semrush.com, csak semrushchina.cn, míg a *.semrushchina.cn egy virtuális gép címére oldódik fel Shenzhenben, hogy aztán az alagúton keresztül lépjen be.
Csak így, maximálisan terelve minden lehetséges forgalmat a kínai tűzfal gyors áthaladási megoldásunkon, érhetünk el elfogadható sebességeket és elérhetőségi mutatókat, valamint őszinte tesztelési eredményeket.
Ezt kódmódosítás nélkül, a csapatok termékein végeztük.
Subfilter
A megoldás szinte azonnal megszületett, miután előkerült a probléma. Szükségünk volt PoC (Proof of Concept), hogy a tűzfal áthaladási megoldásaink valóban jól működnek. Ehhez maximálisan a weboldal forgalmát kellett ebbe a megoldásba terelnünk. Alkalmaztuk a nginx-ben.
Subfilter — ez egy meglehetősen egyszerű modul a nginx-ben, amely lehetővé teszi, hogy egy sort egy másik sorra cseréljünk a válasz törzsében. Így kicseréltük az összes előfordulást semrush.com Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata semrushchina.cn minden válaszban.
És... ez nem működött, mert a backendekből tömörített tartalmat kaptunk, így a subfilter nem találta a szükséges sort. Hozzá kellett adnunk egy új helyi szervert a nginx-hez, amely dekompresszálta a választ, és továbbította a következő helyi szervernek, amely már a sor cseréjével, a tömörítéssel és az azt követő proxy-szervernek való átadásával foglalkozott.
Végül, ahol az ügyfél kapott <subdomain>.semrush.com, ő kapta meg <subdomain>.semrushchina.cn és engedelmesen átment a megoldásunkon.
Namun, az csupán nem elegendő, hogy az egyik irányban megváltoztassuk a domaint, hiszen a backendek továbbra is a semrush.com-ot várják az ügyféltől érkező további kérésekben. Ennek megfelelően, ugyanazon a szerveren, ahol az egyik irányban történik a csere, egy egyszerű reguláris kifejezés segítségével kinyerjük a domaint a kérésből, majd proxy_pass a változóval $host, beállítva a $subdomain.semrush.com. Bonyolultnak tűnhet, de működik. És jól működik. A különböző logikát igénylő külön doménekhez egyszerűen saját server-blokkokat hozunk létre, és külön konfigurációt készítünk. Az alábbiakban rövidített nginx konfigurációk találhatók a folyamat bemutatására.
A következő konfiguráció kezeli az összes kérdést Kínából a .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;
}
}Ez a konfiguráció a következőre irányít localhost a 83-as portra, ahol a következő konfiguráció várakozik:
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;
}
}Meg kell említenem, hogy ezek vágott konfigurációk.
Körülbelül így néz ki. Lehet, hogy bonyolultnak tűnik, de szavakkal könnyebben megfogalmazható. A valóságban minden egyszerűbb, mint a sült krumpli 🙂
A lírai eltérések vége
Egy ideig boldogok voltunk, mert a csökkenő IPSEC-alagút mítosza nem igazolódott. De később az alagutak kezdeni csökkenni. Néhány alkalommal naponta, néhány percig. Kicsit, de ez minket nem tetszett. Mivel mindkét alagút Ali oldalán egy routeren végződött, úgy döntöttünk, hogy lehet, hogy ez egy regionális probléma, és fel kell emelni a biztonsági régiót.
Feltettük. Az alagutak különböző időpontokban kezdtek csökkenni, de a felügyelet az upstream szinten az nginx-nél jól működött. De később az alagutak körülbelül egyszerre kezdtek csökkenni 🙂 És megint 502 és 504 hibák kezdődtek. Az üzemidő csökkent, ezért elkezdtük kidolgozni a lehetőséget a Alibaba CEN (Cloud Enterprise Network).
CEN
CEN Ez a kapcsolódási lehetőség két VPC számára különböző régiókból az Alibaba Cloud-on belül, vagyis lehetőség van bármely régió privát hálózatainak összekapcsolására a felhőben. És ami a legfontosabb: ennek a csatornának meglehetősen szigorú SLA. Nagyon stabil mind sebesség, mind üzemidő szempontjából. De sosem egyszerű a helyzet:
- nagyon nehéz hozzájutni, ha nem kínai állampolgár vagy jogi személy vagy,
- minden egyes megabites sávszélességet meg kell fizetni.
Miután lehetőséget kaptunk az összekapcsolásra Mainland China és Overseas, létrehoztunk egy CEN-t két Ali régió között: cn-shenzhen és us-east-1 (a legközelebbi pont az us-east4-hez). Az Ali-nál us-east-1 állítottunk be még egy virtuális gépet, hogy legyen még egy hop.
Így alakult:
Az alábbiakban a böngészőtesztek eredményei:
Megoldás
Uptime
Medián
75. percentilis
95. percentilis
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
CEN
99.75
16s
21s
27s
A mutatók kicsit jobbak, mint az IPSEC esetében. De IPSEC-en keresztül potenciálisan 100 Mbit/s sebességgel lehet letölteni, CEN-en keresztül viszont csak 5 Mbit/s sebességgel, és drágább.
Hibrid megoldás jön, ugye? Összekapcsolni az IPSEC sebességét és a CEN stabilitását.
Így jártunk el, forgalmat terelve az IPSEC és a CEN segítségével az IPSEC-tunnel hiba esetén. Az üzemidő sokkal magasabb lett, de a weboldal betöltési sebessége továbbra is kívánnivalót hagyott maga után. Akkor megrajzoltam az összes rendszert, amelyet már használtunk és teszteltünk, és úgy döntöttem, hogy egy kicsit több GCP-t adok hozzá ehhez a rendszerhez, mégpedig GLB.
GLB
GLB — ez (vagy Google Cloud Load Balancer). Fontos előny, hogy a CDN kontextusában rendelkezik anycast IP, amely lehetővé teszi a forgalom irányítását a legközelebbi adatközpont felé, így a forgalom gyorsabban eljut a Google gyors hálózatába, és kevesebbet halad az 'általános' interneten.
Nem sokáig gondolkodtunk, bekapcsoltuk a HTTP/HTTPS LB a GCP-n, és a háttérben a subfilter virtuális gépeinket állítottuk be.
Több rendszer is volt:
- Használja a Cloudflare Kína Hálózat, de ezúttal az Origin-nál a globális IP GLB.
- Klienseket terminálva cn-shenzhen, és onnan azonnal proxizálva a forgalmat GLB.
- Kínából közvetlenül a GLB.
- Klienseket terminálva cn-shenzhen, onnan proxizálva a asia-east1 IPSEC-en (a us-east4 CEN-en keresztül), onnan már a GLB-hez menni (nyugi, lent lesz kép és magyarázat)
Minden lehetőséget teszteltünk és még néhány hibridet is:
- Cloudflare + GLB
Ez a rendszer nem tetszett nekünk az üzemidő és a DNS-hibák miatt. De a tesztet a CF hibájának javítása előtt végeztük, lehet, hogy most már jobb (azonban ez nem zárja ki a HTTP-időkorlátokat).
- Ali + GLB
Ez a rendszer szintén nem tetszett nekünk az üzemidő miatt, mivel a GLB gyakran kiesett az upstream-ből a csatlakozási idő elviselhetetlensége vagy időkorlát miatt, hiszen a Kínán belüli szerver számára a GLB címe a külső marad, így a kínai tűzfal mögött van. Nincs varázslat.
- Csak GLB
Olyan lehetőség, amely hasonló volt az előzőhöz, csak nem használtak szervereket Kínában: a forgalom közvetlenül a GLB-be ment (DNS-bejegyzéseket módosítottunk). Az eredmények nem tetszettek, mivel a normál kínai klienseknél, akik általános internetszolgáltatók szolgáltatásait veszik igénybe, a tűzfalszűrés sokkal rosszabb a Ali Cloudhoz képest.
- Shenzhen -> (CEN/IPSEC) -> Proxy -> GLB
Itt úgy döntöttünk, hogy a legjobbat használjuk minden megoldásból:
- stabilitás és garantált SLA a CEN-től
- magas sebesség az IPSEC-től
- a Google 'gyors' hálózatát és annak anycast-ját.
A rendszer körülbelül így néz ki: a felhasználók forgalma a virtuális gépen terminálódik a ch-shenzhen. Itt be van állítva az nginx upstream, melyek egy része egy IPSEC alagúton keresztül elérhető privát IP szerverekre hivatkozik, míg másik része a CEN másik oldalán található privát szerverek IP címeire. asia-east1 A GCP-ben került beállításra (ez volt a legközelebbi régió Kínához a megoldás létrehozásakor. Jelenleg a GCP-nek Hongkongban is van jelenléte). CEN — a régió us-east1 az Ali Cloudon.
Ezután a forgalom mindkét végpontjáról a anycast IP GLB, azaz a Google legközelebbi jelenlétipontjára irányult, majd a Google hálózatain átjutva a régióba us-east4 a GCP-ben, ahol a virtuális gépek álltak (subfilterrel az nginx-ben).
Ez a hibrid megoldás, ahogy vártuk, lehetővé tette a különböző technológiák előnyeinek kihasználását. Összességében a forgalom gyors IPSEC csatornákon keresztül halad, de ha problémák merülnek fel, gyorsan és néhány percre kizárjuk ezeket a szervereket az upstream-ből, és csak a CEN-en keresztül irányítjuk a forgalmat, amíg az alagút stabilizálódik.
Az előző listából a 4. megoldás bevezetésével elértük, amit szerettünk volna, és amit az üzlet megkövetelt tőlünk abban az időben.
A böngészős tesztek eredményei az új megoldás számára a korábbiakkal összehasonlítva:
Megoldás
Uptime
Medián
75. percentilis
95. percentilis
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
-szolgáltató). Ők figyelik a
A bevezetett megoldásunk jól működik, csak CDNről van szó, amely képes lenne felgyorsítani a forgalmat a régiók és még akár a városok szintjén is. Elméletileg ez fel kellene gyorsítania a weboldal működését a végfelhasználók számára a CDN szolgáltató gyors kapcsolatainak kihasználásával. Erről folyamatosan gondolkodtunk. És most elérkezett a projekt következő iterációjának ideje: CDN szolgáltatók keresése és tesztelése Kínában.
Erről mesélek nektek a következő, befejező részben 🙂
Forrás: habr.com
