Hej alle!
Nikita er i kontakt - en systemingeniør fra virksomheden SEMrush. I dag vil jeg fortælle dig om, hvordan vi stod over for opgaven med at sikre stabiliteten af vores semrush.com-tjeneste i Kina, og hvilke problemer vi stødte på under implementeringen (i betragtning af placeringen af vores datacenter på østkysten af USA).
Dette bliver en stor historie, opdelt i flere artikler. Jeg vil fortælle dig, hvordan det hele skete for os: fra en fuldstændig ikke-funktionel tjeneste fra Kina til præstationsindikatorer for tjenesten på niveau med dens amerikanske version for amerikanere. Jeg lover, at det bliver interessant og nyttigt. Så lad os gå.
Problemer med det kinesiske internet
Selv den person, der er længst væk fra netværksadministrationens detaljer, har hørt om Kinas store firewall. Wow, det lyder fedt, ikke? Men hvad det er, og hvordan det rent faktisk fungerer, er et ret kompliceret spørgsmål. Du kan finde mange artikler på internettet om dette, men fra et teknisk synspunkt er strukturen af denne firewall ikke beskrevet nogen steder. Hvilket dog ikke er overraskende. Jeg indrømmer med det samme, at baseret på resultaterne af et års arbejde, vil jeg ikke kunne sige præcis, hvordan det fungerer, men jeg kan fortælle dig om mine kommentarer og praktiske konklusioner. Og vi starter med rygter om denne firewall.
Der er mange rygter om netop denne firewall. Lad os samle de vigtigste og mest interessante af dem på en liste:
- Google, Facebook, Twitter og andre lignende tjenester er blokeret og virker ikke i Kina.
- Enhver trafik, der går UD for Kina og IND i Kina, analyseres og begrænses ved hjælp af maskinlæring (i tilfælde af mistænkelig trafik), hvilket i høj grad bremser den (trafik), der passerer gennem grænsen.
- Kinesiske efterretningstjenester vil hacke enhver krypteret trafik, der passerer gennem deres firewall.
- VPN-tunneler, IPSEC-tunneler er ustabile, styrter ned og er konstant blokeret.
- Jo enklere krypteringen er, jo enklere adgangssætningen bruges til at autentificere/kryptere trafik, jo hurtigere går den gennem den kinesiske firewall.
Her er, hvad vi fandt ud af om disse rygter:
- Google, Facebook, Twitter og andre lignende tjenester er ganske vist blokeret (din KO), men mange tekniske Google-domæner er for eksempel ikke forbudt og fungerer (det samme gstatic.com). Konklusionen følger af dette: du bør ikke hensynsløst skære alle Google og andre ressourcer ud, der ser ud til at være blokeret.
- Enhver trafik, der passerer grænsen, tilføjer virkelig alvorlig forsinkelse til sin tid. Se på de to resultater. Ét websted, én side, simpel GET krølle'om. Den første måling var fra selve Kina (den smukke by Shenzhen). Den anden blev målt udefra fra Hong Kong (den har suverænitet, og der er ingen firewall mellem den og verden). Afstanden mellem byerne i en lige linje er cirka 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/sVær opmærksom på time_connect. Og generelt ser du resultatet: Firewallen tilføjer 4 ekstra sekunder, hvilket er monstrøst langt.
- VPN- og IPSEC-tunneler fejler ofte. Jeg vil tale om dette lidt senere og mere detaljeret. VPN-servere, der bruges af brugere, blokeres over tid (normalt inden for en dag efter start af brug).
- Der er modtaget en udtalelse fra folk, der bor i Kina, at jo enklere kryptering af trafikken er, jo hurtigere passerer den gennem grænsen, fordi det er let at forstå, at der ikke er noget ulovligt ved det. Og på samme måde får ”ren” trafik mere båndbredde og passagehastighed, mens ”beskidt” trafik, hvor intet kan forstås, tværtimod får en langsommere passage. For eksempel vil jeg bruge curl til ifconfig.co via HTTPS og HTTP-protokol.
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/sEn forskel på 5 sekunder for en samlet downloadtid på 13 bytes. Når du laver en sådan test flere gange, kan du desuden bemærke, at GET på HTTP udføres generelt på samme tid hver gang, mens webstedet på HTTPS nogle gange reagerer på 3, 5, 10 og endda 17 sekunder. Nogle gange opstår der SSL-fejl:
Unknown SSL protocol error in connection to ifconfig.co:443.
Så hvad har vi:
- Problemerne skabt af den kinesiske firewall er beskrevet ovenfor.
- Pings til eksterne ressourcer og inde i tunneler forsvinder med jævne mellemrum.
- Latency mellem to punkter ændrer sig konstant, og ofte er den simpelthen uforudsigelig. Ved sammenkobling af forskellige byer/regioner forventer man, ud fra regionernes geografiske placering, at forsinkelsen bliver mindre, men man får præcis den modsatte situation.
- Internettet og kommunikationskanalerne er enten hurtige eller langsomme. Der er en lille afhængighed af tidspunktet på dagen og ugedagen, men ikke altid.
- DNS-anmodninger til omverdenen fra Kina overskrider nogle gange den tilladte timeout.
Det billede, der tegner sig, er simpelthen "fremragende".
Datacentret, som jeg allerede sagde, er i det østlige USA, og hele SEMrush består af snesevis af sammenkoblede produkter, backends, frontends, databaser og alt dette i DC og skyer. Som et team af systemadministratorer fik vi til opgave hurtigt at begynde at arbejde i Kina med en lille indsats.
Vi skulle svare på et vigtigt spørgsmål: er det muligt at klare sig med små omkostninger og løse alle de problemer, der er forbundet med det kinesiske internet og firewall på netværk/sky/server-niveau?
Vi startede med at modtage .
ICP-licens
For at være i stand til at hoste din tjeneste i Kina (fastlandet Kina) og udføre tests, skal du først opnå en ICP-licens til domænet.
Hvis dit websteds brugertrafik er afsluttet inden for det kinesiske fastland, og hvis dit domæne ikke har en ICP-licens, vil din trafik blive blokeret på ISP/hosting-siden. Interessant nok inkluderer ICP-licensen en specifik udbyder, det være sig Cloudflare eller Alibaba Cloud. Derfor, hvis du modtog en ICP-licens til Cloudflare og hostede dit websted hos dem, vil du ikke være i stand til "sømtløst" at flytte til Alibaba Cloud. Du skal tilføje en anden hosting til denne licens.
Efter at have modtaget en ICP-licens til domænet, var vi i stand til at komme med og implementere specifikke tekniske ideer og løsninger.
Test af løsninger
Men før du direkte opretter iscenesættelsesmuligheder, drejer på knapperne, optimerer webstedets ydeevne og dets hastighed, skal du vælge et værktøj til at teste det for at se, hvilke af vores handlinger der forbedrer eller tværtimod forværrer webstedets ydeevne.
Vores testværktøj skulle opfylde to hovedkrav:
- det burde kunne køre test fra Kina,
- den skal have browsertests.
Så vi fandt ! De har fremragende dækning af teststeder rundt om i verden. I Kina kan der også køres test fra 100500 provinser gennem dette værktøj. Hver har flere forskellige udbydere + evnen til at gøre Backbone-tests (noget som en virtuel maskine i et datacenter) og Lastmile-tests (så tæt som muligt på brugerforholdene, også kaldet arbejdsstation). Sidstnævnte type test er dyrere.
Efter at have indgået en årlig kontrakt (mindre end det er ikke muligt), begyndte vi at studere instrumentet. Helt ærligt blev vi glædeligt overrasket over dens funktionalitet. Du kan køre:
- DNS test,
- Webtests (browsertest, simpel GET/POST, mobil klientemulering osv.),
- Transaktionskontrol (f.eks. login),
- API test,
- Ping, traceroute, NTP osv.
Du kan ikke liste alt. Og vigtigst af alt, hver test kan tilpasses ganske godt ved at tilføje en masse overskrifter og andre parametre. Outputtet er en enorm mængde information, der fuldt ud beskriver din test. Hvis vi taler om de mest interessante ting for os (browsertest), inkluderer resultatet:
- Tilslut, Vent, Indlæs, SSL, DNS-tid,
- TTFB, TTLB, dokument færdig, gengivelsestid, DOM-indlæsning,
- Respons (noget tæt på Time To First Byte), Webpage Response (noget tæt på Time To Last Byte),
- Enhver percentil, gennemsnit, mediantid
- Etc.
Derfor er alle disse målinger gode til at se ændringer og forstå, om tingene er blevet bedre. Vi kiggede primært på Respons, websiderespons, median, 75 og 95 procent.
Et vigtigt spørgsmål, der lå i luften lige fra begyndelsen: Kan du stole på Catchpoint?? Afspejler dette værktøj den reelle sideindlæsningshastighed i Kina fra forskellige byer, eller er det bare en form for test i et vakuum, der ikke har noget at gøre med ægte brugeroplevelse?
Dette er et stort problem, for at være i Rusland er det næsten umuligt pålideligt at finde ud af, hvordan et websted fra Kina fungerer. Ved at lave en socks-proxy gennem en virtuel maskine, er slutresultatet, at siden indlæses inden for et par minutter, hvilket simpelthen er uacceptabelt for test, så den eneste mulighed for manuel test er krøllet og enkelt GET fra konsollen med en timer . Dette hjælper, fordi denne test godt afspejler hastigheden på netværksløsningen, og hvis der også er browsertest, så er det meget godt.
Senere tog vi selv til Kina og var overbeviste om det Du kan stole på Catchpoint, det afspejler reelle præstationsindikatorer.
Cloudflare Kina netværk
Da vi med succes bruger Cloudflare til hoveddomænet semrush.com, besluttede vi os for straks at prøve deres funktion kaldet . Denne mulighed er kun aktiveret for Enterprise-websteder efter separat anmodning og mod et ekstra gebyr. Den er også kun tilgængelig for websteder, der har en passende ICP-licens, der angiver Cloudflare som udbyder. Efter at have aktiveret det, bliver det "kinesiske CDN" fra Cloudflare tilgængeligt for webstedet - trafik fra kinesiske regioner lander på den nærmeste PoP (Points of Presence) CF, og derefter via dens netværk eller netværk af udbydere/partnere, bliver den leveret til oprindelsen .
Diagrammet af denne testbænk er præsenteret nedenfor.
Dette er en god mulighed for os. Det viser sig, at det andet domæne også vil være for CF, hvilket ikke øger antallet af løsninger, der bruges i virksomheden, og praktisk talt ikke komplicerer infrastrukturen.
Vi kørte browsertest, og dette er, hvad der skete:
Røde diamanter er testfejl. Filerne nedenfor er DNS-fejl (løs timeout). Fejlene i toppen er timeouts.
Oppetid: 86.6
Median: 18 sek
75 Percentil: 29.3s
95 Percentil: 60s
Median, efter læsning blev fjernet reCAPTCHA (Google-tjeneste blokeret i Kina) faldt fra 28 til 18 sekunder. Men det er stadig forfærdelige resultater i betragtning af, at den samme test for semrush.com (fra USA) gav mindre end 10 sekunder for 95 % af brugerne (fra USA) på samme side (statisk + dynamisk).
Du kan gå ind i hver test og se Vandfald og andre mere detaljerede parametre. Vi begyndte at undersøge årsagerne til fejlene, og hvis for timeouts alt er mere eller mindre klart: Internettet i Kina "bevæger sig ind og ud", på grund af dette er forbindelseshastigheden og indlæsning af ressourcer fra udlandet ustabil og ujævn, så overraskede DNS-fejlene os meget. Det fandt vi Po Cloudflare er faktisk placeret i Kina, webstedsadressen løses til en anycast IP, men DNS-serverne er amerikanske, hvorfor DNS-anmodninger er tvunget til at gå over grænsen, så nogle gange mislykkes de.
Efter at have afklaret dette spørgsmål med CF, viste det sig at De har ikke deres egne DNS-servere i Kina, og hvornår det bliver er endnu uvist.
Derfor besluttede vi kun at teste Cloudflare DNS og ændrede Cloudflares betjeningsmekanisme for vores websted til "Kun DNS" Dette er en tilstand, hvor Cloudflare ikke proxy-trafik gennem sig selv, hvilket betyder, at den ikke giver DDoS-beskyttelse, CDN og andre funktioner og fungerer i tilstanden som en almindelig DNS-server.
Dette stativ er vist skematisk i den følgende figur. Figuren tager højde for den nye viden om, at Cloudflares DNS-servere er bag en firewall.
Hos Catchpoint kørte vi simple GET-tests (ikke browsertest), som viste en masse fejl. De var forårsaget af de samme DNS-fejl.
Vi begyndte at fejlfinde disse fejl vha grave og fandt ud af, at ved den første anmodning er adressen bestemt korrekt, og ved gentagen anmodning modtager vi hver gang SERVFAIL и ikke fundet. Hvorfor sker det lige pludselig?
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)Der er ingen sådanne fejl, når du forespørger Cloudflare NS-servere direkte:
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.192Det betyder, at problemet er på siden af den "lokale" DNS-server eller udbyderens server.
Det viste yderligere undersøgelser SERVFAIL vi er fast besluttede AAAA-optegnelser.
Det viste sig, at når man anmodede fra Cloudflare AAAA-record, der ikke findes i domænet, svarede Cloudflare А-en indtastning, der er en fejl og manglende overensstemmelse med RFC. Hvorfor gør den lokale resolver (xxxx) Jeg kunne ikke lide det, og han svarede SERVFAIL. Denne adfærd er tydeligt synlig i loggen nedenfor:
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 sendte en fejlrapport til Cloudflare, og de rettede den efter nogen tid. Det viste sig at være interessant: i øjeblikket er der stadig ingen IPv6-understøttelse i Kina, så Cloudflare kunne ikke udstede sin IPv6-adresse der som svar på en anmodning AAAA-optegnelser. Til sidst blev alt løst på en sådan måde, at Cloudflare begyndte at svare for Kina INGEN DATA til sådanne anmodninger.
DNS-fejl i Catchpoint-tests faldt således kraftigt, men ikke helt. Timeouts er her stadig:
Og vi begyndte at lede efter en anden løsning.
I den næste del vil jeg fortælle dig, hvordan vi testede den kinesiske sky Alibaba Cloud, hvordan vi ved hjælp af en lille "magi" fra Nginx hurtigt var i stand til at skabe PoC (Proof of Concept) løsninger, hvordan vi skabte Multi-Cloud løsninger, hvoraf en i sidste ende i høj grad var med til at fremskynde arbejdet med tjenesten fra Kina.
Bliv hængende!
Næste dele
Kilde: www.habr.com
