Hello!
Nikita kapcsolatban áll – a cég rendszermérnöke SEMrush. Ma arról mesélek, hogyan álltunk szemben a semrush.com szolgáltatásunk stabilitásának biztosításával Kínában, és milyen problémákkal találkoztunk a megvalósítás során (adatközpontunk elhelyezkedése az Egyesült Államok keleti partján).
Ez egy nagy történet lesz, több cikkre osztva. Elmondom, hogyan történt mindez nálunk: egy teljesen nem működő kínai szolgáltatástól kezdve a szolgáltatás amerikai verziójának teljesítménymutatóiig az amerikaiak számára. Ígérem érdekes és hasznos lesz. Akkor gyerünk.
A kínai internet problémái
Még a hálózati adminisztráció sajátosságaitól legtávolabb lévők is hallottak róla Kína nagy tűzfala. Wow, jól hangzik, igaz? De hogy mi ez és hogyan működik valójában, az meglehetősen bonyolult kérdés. Az interneten számos cikket találhat erről, de technikai szempontból ennek a tűzfalnak a felépítése nincs leírva sehol. Ami azonban nem meglepő. Azonnal bevallom, hogy egy éves munka eredménye alapján nem fogom tudni pontosan megmondani, hogyan működik, de elmondhatom észrevételeimet és gyakorlati következtetéseimet. És kezdjük a tűzfallal kapcsolatos pletykákkal.
Nagyon sok pletyka kering erről a tűzfalról. Gyűjtsük össze a legfontosabb és legérdekesebbeket egy listába:
- A Google, a Facebook, a Twitter és más hasonló szolgáltatások le vannak tiltva, és nem működnek Kínában.
- A Kínán KÍVÜL és Kínába érkezett forgalom gépi tanulással elemzésre kerül és korlátozódik (gyanús forgalom esetén), ami nagymértékben lelassítja a határon áthaladó forgalmat.
- A kínai hírszerző ügynökségek feltörnek minden titkosított forgalmat, amely áthalad a tűzfalukon.
- A VPN-alagutak, az IPSEC-alagutak instabilok, összeomlanak és folyamatosan blokkolva vannak.
- Minél egyszerűbb a titkosítás, minél egyszerűbb a forgalom hitelesítésére/titkosítására használt jelszó, annál gyorsabban megy át a kínai tűzfalon.
Íme, amit megtudtunk ezekről a pletykákról:
- A Google, a Facebook, a Twitter és más hasonló szolgáltatások valóban le vannak tiltva (az Ön KO), de például sok technikai Google domain nincs tiltva és működik (ugyanaz a gstatic.com). Ebből következik a következtetés: nem szabad meggondolatlanul kivágni az összes olyan Google-t és más forrást, amely blokkoltnak tűnik.
- Bármilyen, a határon áthaladó forgalom komolyan késlelteti az idejét. Nézd meg a két eredményt. Egy webhely, egy oldal, egyszerű GET becsavar'om. Az első mérés magából Kínából történt (a gyönyörű Shenzhen városa). A másodikat kívülről mérték Hongkongból (szuverenitása van, és nincs tűzfal közte és a világ között). A városok távolsága egyenes vonalban körülbelül 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/sÜgyeljen rá time_connect. És általában az eredmény látható: a tűzfal 4 extra másodpercet ad hozzá, ami szörnyen hosszú.
- A VPN és IPSEC alagutak gyakran meghibásodnak. Erről egy kicsit később és részletesebben fogok beszélni. A felhasználók által használt VPN-kiszolgálók idővel (általában a használat megkezdését követő egy napon belül) blokkolva vannak.
- Kínában élőktől olyan vélemény érkezett, hogy minél egyszerűbb a forgalom titkosítása, annál gyorsabban halad át a határon, mert könnyen érthető, hogy nincs benne semmi illegális. És ugyanígy a „tiszta” forgalom nagyobb sávszélességet és áthaladási sebességet kap, míg a „piszkos” forgalom, amiben semmit sem lehet érteni, éppen ellenkezőleg, lassabb áthaladást kap. Például a curl-t fogom használni ifconfig.com HTTPS és HTTP protokollon keresztül.
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 másodperc különbség 13 bájt teljes letöltési idő esetén. Sőt, egy ilyen teszt többszöri elvégzésekor észreveheti, hogy a HTTP-n a GET általában minden alkalommal ugyanabban az időben fejeződik be, míg HTTPS-en a webhely néha 3, 5, 10, sőt 17 másodpercen belül válaszol. Néha előfordulnak SSL hibák:
Unknown SSL protocol error in connection to ifconfig.co:443.
Tehát mi van nálunk:
- A kínai tűzfal által okozott problémákat fentebb leírtuk.
- A külső erőforrásokra és a belső alagutakra irányuló ping időnként eltűnik.
- Két pont közötti késleltetés folyamatosan változik, és gyakran egyszerűen kiszámíthatatlan. A különböző városok/régiók összekapcsolásakor arra számít, hogy a régiók földrajzi elhelyezkedése alapján kisebb lesz a késés, de pont az ellenkező helyzetet kapja.
- Az internet és a kommunikációs csatornák vagy gyorsak vagy lassúak. Van némi függés a napszaktól és a hét napjától, de nem mindig.
- A Kínából érkező DNS-kérések néha túllépik a megengedett időt.
A megjelenő kép egyszerűen „kiváló”.
Az adatközpont, ahogy már mondtam, az Egyesült Államok keleti részén található, és az egész SEMrush több tucat egymással összekapcsolt termékből, háttérrendszerekből, frontendekből, adatbázisokból áll, és mindez a DC-ben és a felhőkben. Mi, mint rendszergazdák csapata azt a feladatot kaptuk, hogy kis erőfeszítéssel gyorsan kezdjünk el dolgozni Kínában.
Egy fontos kérdésre kellett válaszolnunk: meg lehet-e boldogulni kis ráfordítással és megoldani a kínai internettel és tűzfallal kapcsolatos összes problémát hálózat/felhő/szerver szinten?
A fogadással kezdtük .
ICP licenc
Ahhoz, hogy szolgáltatását Kínában (Kína szárazföldön) tárolhassa, és teszteket végezhessen, először be kell szereznie egy ICP-licencet a domainhez.
Ha webhelyének felhasználói forgalma Kínában megszűnik, és ha domainje nem rendelkezik ICP-licenccel, a forgalom blokkolva lesz az internetszolgáltató/tárhely oldalon. Érdekes módon az ICP licenc egy adott szolgáltatót tartalmaz, legyen az Cloudflare vagy Alibaba Cloud. Ezért, ha kapott egy ICP-licencet a Cloudflare-hez, és azzal tárolta webhelyét, akkor nem fog tudni „zökkenőmentesen” átköltözni az Alibaba Cloudba. Ehhez a licenchez egy másik tárhelyet kell hozzáadnia.
Miután megkaptuk a domain ICP licencét, konkrét műszaki ötleteket, megoldásokat tudtunk kidolgozni és megvalósítani.
Megoldások tesztelése
Mielőtt azonban közvetlenül létrehozna állomásozási lehetőségeket, elforgatná a gombokat, optimalizálná a webhely teljesítményét és sebességét, ki kell választania egy eszközt a teszteléshez, hogy megtudja, melyik tevékenységünk javítja, vagy éppen ellenkezőleg, rontja a webhely teljesítményét.
Teszteszközünknek két fő követelménynek kellett megfelelnie:
- képesnek kell lennie Kínából származó tesztek futtatására,
- böngészőtesztekkel kell rendelkeznie.
Tehát megtaláltuk ! Kiváló lefedettséggel rendelkeznek a tesztelési helyszínekről szerte a világon. Kínában ezen az eszközön keresztül 100500 XNUMX tartományból is futtathatók tesztek. Mindegyiknek több különböző szolgáltatója van + erre a képessége Hátgerinc-tesztek (olyasmi, mint egy virtuális gép egy adatközpontban) és Utolsó mérföld-tesztek (a felhasználói feltételekhez a lehető legközelebb, más néven munkaállomás). Az utóbbi típusú tesztek drágábbak.
Miután megkötöttük az éves szerződést (ennél kevesebb nem lehetséges), elkezdtük a hangszer tanulmányozását. Őszintén szólva kellemesen meglepett minket a funkcionalitása. Futhatsz:
- DNS tesztek,
- Webes tesztek (böngészőtesztek, egyszerű GET/POST, mobil kliens emuláció stb.),
- Tranzakciós ellenőrzések (például bejelentkezés),
- API tesztek,
- Ping, traceroute, NTP stb.
Nem lehet mindent felsorolni. És ami a legfontosabb, minden teszt jól testreszabható fejlécek és egyéb paraméterek hozzáadásával. A kimenet hatalmas mennyiségű információ, amely teljes mértékben leírja a tesztet. Ha a számunkra legérdekesebb dolgokról beszélünk (böngészőtesztek), az eredmény a következőket tartalmazza:
- Csatlakozás, várakozás, betöltés, SSL, DNS idő,
- TTFB, TTLB, dokumentum kész, renderelési idő, DOM betöltés,
- Response (valami közel a Time To First Byte-hoz), Weboldal-válasz (valami közel a Time To Last Byte-hoz),
- Bármely százalékos, átlagos, medián idő
- Stb.
Ennek megfelelően ezek a mutatók kiválóan alkalmasak a változások megfigyelésére és annak megértésére, hogy a dolgok javultak-e. Főleg megnéztük Válasz, Weboldal válasz, Medián, 75 és 95 százalékos.
Egy fontos kérdés, ami a kezdetektől a levegőben volt: Megbízhat a Catchpointban?? Ez az eszköz tükrözi a kínai webhelyek valós betöltési sebességét a különböző városokból, vagy ez csak valamiféle légüres teszt, aminek semmi köze a valós felhasználói élményhez?
Ez nagy probléma, mert Oroszországban szinte lehetetlen megbízhatóan kideríteni, hogyan működik egy kínai webhely. A virtuális gépen keresztül végrehajtott socks-proxy a végeredmény az, hogy az oldal néhány percen belül betöltődik, ami egyszerűen elfogadhatatlan a teszteknél, így a kézi tesztelés egyetlen lehetősége a curl és az egyszerű GET a konzolról időzítővel. . Ez segít, mert ez a teszt jól tükrözi a hálózati megoldás sebességét, és ha vannak böngészőtesztek is, akkor az nagyon jó.
Később mi magunk is elmentünk Kínába, és meg voltunk győződve erről Megbízhat a Catchpointban, elég pontosan tükrözi a valós teljesítménymutatókat.
Cloudflare kínai hálózat
Mivel sikeresen használjuk a Cloudflare-t a semrush.com fő domainhez, úgy döntöttünk, hogy azonnal kipróbáljuk az elnevezésű funkciójukat . Ez az opció külön kérésre és felár ellenében csak vállalati webhelyeken engedélyezett. Ezenkívül csak olyan webhelyek számára érhető el, amelyek rendelkeznek megfelelő ICP-licenccel, amely a Cloudflare-t tartalmazza szolgáltatóként. Engedélyezése után a Cloudflare „kínai CDN” elérhetővé válik az oldal számára - a kínai régiókból érkező forgalom a legközelebbi PoP (Points of Presence) CF-hez érkezik, majd annak hálózatain vagy a szolgáltatók/partnerek hálózatain keresztül eljut az eredeti helyre. .
A próbapad diagramja az alábbiakban látható.
Ez egy nagyszerű lehetőség számunkra. Kiderült, hogy a második domain is a CF-é lesz, ami nem növeli a cégnél alkalmazott megoldások számát, és gyakorlatilag nem is bonyolítja az infrastruktúrát.
Böngészőteszteket futtattunk, és ez történt:
A vörös gyémántok tesztkudarcok. Az alábbi fájlok DNS-hibák (feloldási időtúllépés). A tetején lévő hibák időtúllépések.
Üzemidő: 86.6
Medián: 18s
75 százalékos: 29.3 s
95 százalékos: 60 s
A mediánt a betöltés után eltávolítottuk reCaptcha (Kínában letiltott Google szolgáltatás) 28-ról 18 másodpercre csökkent. De ezek még mindig szörnyű eredmények, tekintve, hogy a semrush.com (USA-ból) ugyanazon tesztje kevesebb mint 10 másodpercet adott a felhasználók 95%-ának (az Egyesült Államokból) ugyanazon az oldalon (statikus + dinamikus).
Bemehet minden tesztbe és megnézheti Vízesés és egyéb részletesebb paraméterek. Elkezdtük vizsgálni a hibák okait, és ha az időtúllépéseknél minden többé-kevésbé egyértelmű: Kínában az internet „ki-be mozog”, emiatt a csatlakozás sebessége és a külföldről érkező erőforrások betöltése instabil és egyenetlen, akkor a DNS-hibák nagyon megleptek minket. Azt találtuk Pop A Cloudflare valójában Kínában található, az oldal címe egy anycast IP-re oldódik fel, de a DNS-kiszolgálók amerikaiak, ezért a DNS-kérések kénytelenek átmenni a határon, így néha meghiúsulnak.
Miután tisztáztuk ezt a kérdést a CF-vel, kiderült, hogy Kínában nincs saját DNS-kiszolgálójuk, és hogy mikor lesz, még nem tudni.
Ezért úgy döntöttünk, hogy csak a Cloudflare DNS-t teszteljük, és webhelyünk Cloudflare működési mechanizmusát a „Csak DNS" Ez egy olyan mód, amikor a Cloudflare nem proxyforgalmat bonyolít magán keresztül, ami azt jelenti, hogy nem biztosít DDoS védelmet, CDN-t és egyéb funkciókat, és egy normál DNS-kiszolgáló módban működik.
Ez az állvány sematikusan látható a következő ábrán. Az ábra figyelembe veszi azt a feltörekvő tudást, hogy a Cloudflare DNS-kiszolgálói tűzfal mögött vannak.
A Catchpointnál egyszerű GET-teszteket futtattunk (nem böngészőteszteket), amelyek sok hibát mutattak ki. Ugyanazok a DNS-hibák okozták.
Elkezdtük ezeknek a hibáknak a hibakeresését a használatával ás és megállapította, hogy az első kérésre a címet helyesen határozták meg, és ismételt kérésre minden alkalommal megkapjuk SZERVFAIL и nem található. Miért történik ez hirtelen?
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)Nincsenek ilyen hibák a Cloudflare NS szerverek közvetlen lekérdezésekor:
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.192Ez azt jelenti, hogy a probléma a „helyi” DNS-kiszolgáló vagy a szolgáltató szerver oldalán van.
A további vizsgálat kimutatta SZERVFAIL elhatározásra jutunk AAAA- rekordok.
Kiderült, hogy a Cloudflare kérésekor AAAA-rekord, amely nem létezik a tartományban – válaszolta a Cloudflare А- olyan bejegyzés, amely hibás és nem felel meg az RFC-nek. Miért a helyi feloldó (xxxx) Nem tetszett, és válaszolt SZERVFAIL. Ez a viselkedés jól látható az alábbi naplóban:
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
Hibajelentést küldtünk a Cloudflare-nek, és egy idő után kijavították. Érdekesnek bizonyult: jelenleg még mindig nincs IPv6-támogatás Kínában, így a Cloudflare kérésre nem tudta ott kiadni az IPv6-címét. AAAA- rekordok. Végül minden úgy megoldódott, hogy a Cloudflare elkezdett felelni Kínáért NINCS ADAT az ilyen kérésekre.
Így a Catchpoint-tesztekben a DNS-hibák meredeken csökkentek, de nem teljesen. Az időkorlátok még mindig itt vannak:
És elkezdtünk más megoldást keresni.
A következő részben elmondom, hogyan teszteltük a kínai felhőt Alibaba Cloud, hogyan tudtunk az Nginx egy kis „varázslatának” segítségével gyorsan elkészíteni a PoC (Proof of Concept) megoldásokat, hogyan hoztuk létre a Multi-Cloud megoldásokat, amelyek közül az egyik végül nagyban segítette a szolgáltatás munkájának felgyorsítását. Kínából.
Maradjon velünk!
Következő részek
Forrás: will.com
