Saluton ĉiuj!
Nikita estas en kontakto - sisteminĝeniero de la firmao SEMrush. Hodiaŭ mi rakontos al vi pri kiel ni alfrontis la taskon certigi la stabilecon de nia semrush.com-servo en Ĉinio, kaj kiajn problemojn ni renkontis dum ĝia efektivigo (konsiderante la lokon de nia datumcentro sur la orienta marbordo de Usono).
Ĉi tio estos granda rakonto, dividita en plurajn artikolojn. Mi rakontos al vi kiel ĉio okazis por ni: de tute nefunkcia servo el Ĉinio, ĝis agado-indikiloj de la servo je la nivelo de ĝia usona versio por usonanoj. Mi promesas, ke ĝi estos interesa kaj utila. Do, ni iru.
Problemoj de la ĉina Interreto
Eĉ la plej malproksima persono de la specifaĵoj de retadministrado aŭdis pri Granda Fajromuro de Ĉinio. Ho, sonas mojosa, ĉu ne? Sed kio ĝi estas kaj kiel ĝi efektive funkcias estas sufiĉe komplika demando. Vi povas trovi multajn artikolojn en la Interreto dediĉitaj al tio, sed de teknika vidpunkto, la strukturo de ĉi tiu fajroŝirmilo ne estas priskribita ie ajn. Kio, tamen, ne estas surpriza. Mi tuj konfesos, ke surbaze de la rezultoj de unujara laboro, mi ne povos precize diri kiel ĝi funkcias, sed mi povas rakonti al vi pri miaj komentoj kaj praktikaj konkludoj. Kaj ni komencos per onidiroj pri ĉi tiu fajroŝirmilo.
Estas multaj onidiroj pri ĉi tiu sama fajroŝirmilo. Ni kolektu la ĉefajn kaj plej interesajn el ili en unu liston:
- Guglo, Facebook, Twitter kaj aliaj similaj servoj estas blokitaj kaj ne funkcias en Ĉinio.
- Ajna trafiko iranta EKSTER de Ĉinio kaj ENTO de Ĉinio estas analizita kaj limigita uzante maŝinlernadon (kaze de suspektinda trafiko), kiu tre malrapidigas ĝin (trafiko) trapasanta la limon.
- Ĉinaj spionaj agentejoj hakos ajnan ĉifritan trafikon pasantan tra sia fajroŝirmilo.
- VPN-tuneloj, IPSEC-tuneloj estas malstabilaj, kraŝas kaj estas konstante blokitaj.
- Ju pli simpla estas ĉifrado, des pli simpla estas la pasvorto uzata por aŭtentikigi/ĉifri trafikon, des pli rapide ĝi trairas la ĉinan fajroŝirmilon.
Jen kion ni eksciis pri ĉi tiuj onidiroj:
- Guglo, Facebook, Twitter kaj aliaj similaj servoj ja estas blokitaj (via KO), sed multaj teknikaj Google-domajnoj, ekzemple, ne estas malpermesitaj kaj funkcias (la sama gstatic.com). La konkludo sekvas el tio: vi ne malprudente eltranĉu ĉiujn Guglon kaj aliajn rimedojn, kiuj ŝajnas esti blokitaj.
- Ĉiu trafiko preterpasanta la limon vere aldonas gravan prokraston al sia tempo. Rigardu la du rezultojn. Unu retejo, unu paĝo, simpla GET buklo'om. La unua mezurado estis el Ĉinio mem (la bela urbo Shenzhen). La dua estis mezurita de ekstere de Honkongo (ĝi havas suverenecon, kaj ne ekzistas fajroŝirmilo inter ĝi kaj la mondo). La distanco inter la urboj en rekta linio estas proksimume 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/satentu tempo_konekti. Kaj ĝenerale, vi vidas la rezulton: la fajroŝirmilo aldonas 4 kromajn sekundojn, kio estas monstre longa.
- VPN kaj IPSEC-tuneloj ofte malsukcesas. Mi parolos pri tio iom poste kaj pli detale. VPN-serviloj, kiuj estas uzataj de uzantoj, estas blokitaj laŭlonge de la tempo (kutime ene de tago post la komenco de uzo).
- Estas opinio ricevita de homoj loĝantaj en Ĉinio, ke ju pli simpla estas ĉifrado de trafiko, des pli rapide ĝi trapasas la landlimon, ĉar estas facile kompreni, ke estas nenio kontraŭleĝa pri tio. Kaj same, "pura" trafiko ricevas pli da bendolarĝo kaj rapideco de trairejo, dum "malpura" trafiko, en kiu nenio povas esti komprenebla, ricevas, male, pli malrapidan trairejon. Ekzemple mi uzos buklon al ifconfig.co per HTTPS kaj HTTP-protokolo.
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/sDiferenco de 5 sekundoj por totala elŝuta tempo de 13 bajtoj. Krome, farante tian provon plurfoje, vi povas rimarki, ke GET sur HTTP estas finita ĝenerale en la sama tempo ĉiufoje, dum ĉe HTTPS la retejo foje respondas en 3, 5, 10 kaj eĉ 17 sekundoj. Foje okazas SSL-eraroj:
Unknown SSL protocol error in connection to ifconfig.co:443.
Do kion ni havas:
- La problemoj kreitaj de la ĉina fajroŝirmilo estas priskribitaj supre.
- Pingoj al eksteraj rimedoj kaj enaj tuneloj periode malaperas.
- Latenteco inter du punktoj konstante ŝanĝiĝas, kaj ofte ĝi estas simple neantaŭvidebla. Konektante malsamajn urbojn/regionojn, vi atendas ke, surbaze de la geografia loko de la regionoj, la prokrasto estos malpli, sed vi ricevas ĝuste la kontraŭan situacion.
- Interreto kaj komunikaj kanaloj estas aŭ rapidaj aŭ malrapidaj. Estas iometa dependeco de la horo de la tago kaj tago de la semajno, sed ne ĉiam.
- DNS-petoj al la ekstera mondo de Ĉinio foje superas la permesitan tempodaŭron.
La bildo kiu aperas estas simple "bonega".
La datumcentro, kiel mi jam diris, estas en la orienta Usono, kaj la tuta SEMrush konsistas el dekoj da interkonektitaj produktoj, backends, frontends, datumbazoj, kaj ĉio ĉi en la DC kaj nuboj. Ni, kiel teamo de sistemadministrantoj, ricevis la taskon rapide eklabori en Ĉinio kun malmulte da peno.
Ni devis respondi gravan demandon: ĉu eblas elteni per malmulte da elspezo kaj solvi ĉiujn problemojn asociitajn kun la ĉina Interreto kaj fajroŝirmilo je la reto/nubo/servilo?
Ni komencis per ricevado .
ICP-licenco
Por povi gastigi vian servon en Ĉinio (Kontinenta Ĉinio) kaj fari testojn, vi unue devas akiri ICP-licencon por la domajno.
Se la uzanttrafiko de via retejo finiĝas ene de Kontinenta Ĉinio, kaj se via domajno ne havas ICP-licencon, via trafiko estos blokita ĉe la ISP/gastigado. Kurioze, la ICP-licenco inkluzivas specifan provizanton, ĉu ĝi Cloudflare aŭ Alibaba Cloud. Tial, se vi ricevis ICP-licencon por Cloudflare kaj gastigis vian retejon kun ili, vi ne povos "perfekte" moviĝi al Alibaba Cloud. Vi devos aldoni alian gastigadon al ĉi tiu permesilo.
Ricevinte ICP-licencon por la domajno, ni povis elpensi kaj efektivigi specifajn teknikajn ideojn kaj solvojn.
Testado de solvoj
Sed antaŭ ol vi rekte kreas aranĝajn opciojn, turnu la butonojn, optimumigu la agadon de la retejo kaj ĝian rapidecon, vi devas elekti ilon por provi ĝin por vidi, kiuj el niaj agoj plibonigas aŭ, male, plimalbonigas la rendimenton de la retejo.
Nia testa ilo devis plenumi du ĉefajn postulojn:
- ĝi devus povi fari testojn el Ĉinio,
- ĝi devas havi retumiltestojn.
Do ni trovis ! Ili havas bonegan priraportadon de testaj lokoj tra la mondo. En Ĉinio, testoj ankaŭ povas esti faritaj de 100500 XNUMX provincoj per ĉi tiu ilo. Ĉiu havas plurajn malsamajn provizantojn + la kapablon fari spinon-testoj (io kiel virtuala maŝino en datumcentro) kaj Lasta mejlo-testoj (kiel eble plej proksime al uzantkondiĉoj, alinome laborstacio). Ĉi-lasta speco de provoj estas pli multekosta.
Fininte jaran kontrakton (malpli ol tio ne eblas), ni komencis studi la instrumenton. Sincere, ni estis agrable surprizitaj de ĝia funkcieco. Vi povas kuri:
- DNS-testoj,
- Retaj testoj (retumilotestoj, simpla GET/POST, poŝtelefona kliento-emulado ktp.),
- Transakciaj ĉekoj (ekzemple, ensaluto),
- API-testoj,
- Ping, traceroute, NTP, ktp.
Vi ne povas listigi ĉion. Kaj plej grave, ĉiu testo povas esti personecigita sufiĉe bone aldonante amason da kaplinioj kaj aliaj parametroj. La eligo estas grandega kvanto da informoj, kiuj plene priskribas vian teston. Se ni parolas pri la plej interesaj aferoj por ni (testoj de retumilo), la rezulto inkluzivas:
- Konekti, Atendu, Ŝarĝi, SSL, DNS-tempo,
- TTFB, TTLB, Dokumento kompleta, Rendu tempo, DOM-ŝarĝo,
- Respondo (io proksima al Time To First Byte), Retpaĝa Respondo (io proksima al Time To Last Byte),
- Ajna percentilo, Meza, Meza tempo
- Kaj tiel plu.
Sekve, ĉiuj ĉi tiuj metrikoj estas bonegaj por vidi ŝanĝojn kaj kompreni ĉu aferoj pliboniĝis. Ni ĉefe rigardis Respondo, Retpaĝa Respondo, Mediano, 75 kaj 95 Procentoj.
Grava demando, kiu estis en la aero de la komenco mem: Ĉu vi povas fidi Catchpoint?? Ĉu ĉi tiu ilo reflektas la realan ŝarĝan rapidecon en Ĉinio de malsamaj urboj, aŭ ĉu ĝi estas nur ia provo en vakuo, kiu havas nenion komunan kun reala sperto de uzanto?
Ĉi tio estas granda problemo, ĉar estante en Rusio estas preskaŭ neeble fidinde ekscii kiel funkcias retejo el Ĉinio. Farante ŝtrumpetojn-proxy per virtuala maŝino, la fina rezulto estas, ke la retejo ŝarĝas ene de kelkaj minutoj, kio estas simple neakceptebla por testoj, do la sola opcio por manlibrotestado estas buklo kaj simpla GET de la konzolo per tempigilo. . Ĉi tio helpas ĉar ĉi tiu testo bone reflektas la rapidecon de la reto-solvo, kaj se ankaŭ estas retumilatestoj, tiam ĝi estas tre bona.
Poste ni mem iris al Ĉinio kaj konvinkiĝis pri tio Vi povas fidi Catchpoint; ĝi sufiĉe precize reflektas realajn rendimentajn indikilojn.
Cloudflare Ĉina Reto
Ĉar ni sukcese uzas Cloudflare por la ĉefa domajno semrush.com, ni decidis tuj provi ilian funkcion nomatan . Ĉi tiu opcio estas ebligita nur por Entreprenaj retejoj laŭ aparta peto kaj kontraŭ kroma kotizo. Ĝi ankaŭ haveblas nur al retejoj, kiuj havas taŭgan ICP-licencon, kiu listigas Cloudflare kiel la provizanton. Ebligante ĝin, la "Ĉina CDN" de Cloudflare fariĝas disponebla por la retejo - trafiko de ĉinaj regionoj alteriĝas ĉe la plej proksima PoP (Points of Presence) CF, kaj poste tra ĝiaj retoj aŭ la retoj de provizantoj/partneroj ĝi estas liverita al origino. .
La diagramo de ĉi tiu testbenko estas prezentita sube.
Ĉi tio estas bonega eblo por ni. Rezultas, ke la dua domajno ankaŭ estos por CF, kio ne aldonas al la nombro da solvoj uzataj en la kompanio, kaj ankaŭ praktike ne malfaciligas la infrastrukturon.
Ni faris testojn de retumilo kaj jen kio okazis:
Ruĝaj diamantoj estas testfiaskoj. La ĉi-subaj dosieroj estas DNS-eraroj (solvu tempon). La malsukcesoj ĉe la supro estas paŭzoj.
Aktivtempo: 86.6
Mediano: 18s
75 Procento: 29.3s
95 Procento: 60s
Mediano, post ŝarĝo estis forigita reCaptcha (Servo de Google blokita en Ĉinio) malpliiĝis de 28 al 18 sekundoj. Sed ĉi tiuj ankoraŭ estas teruraj rezultoj, konsiderante ke la sama provo por semrush.com (el Usono) donis malpli ol 10 sekundojn por 95% de uzantoj (el Usono) en la sama paĝo (senmova + dinamika).
Vi povas eniri ĉiun teston kaj rigardi akvofalo kaj aliaj pli detalaj parametroj. Ni komencis esplori la kialojn de la eraroj, kaj se por tempoforpasoj ĉio estas pli-malpli klara: Interreto en Ĉinio "moviĝas kaj eliras", pro tio la rapideco de konekto kaj ŝarĝo de rimedoj el eksterlando estas malstabila kaj malebena, tiam la DNS-eraroj tre surprizis nin. Ni trovis tion PoP Cloudflare efektive situas en Ĉinio, la retejo-adreso solvas al unu anycast IP, sed la DNS-serviloj estas usonaj, tial DNS-petoj estas devigitaj iri trans la limon, do foje ili malsukcesas.
Klariginte ĉi tiun demandon kun CF, tio rezultis Ili ne havas siajn proprajn DNS-servilojn en Ĉinio, kaj kiam ĝi estos estas ankoraŭ nekonata.
Tial ni decidis testi nur Cloudflare DNS kaj ŝanĝis la operacian mekanismon de Cloudflare por nia retejo al la "DNS nur" Ĉi tio estas reĝimo, kiam Cloudflare ne prokuras tra si mem, kio signifas, ke ĝi ne provizas DDoS-protekton, CDN kaj aliajn funkciojn, kaj funkcias en la reĝimo de regula DNS-servilo.
Ĉi tiu stando estas montrita skeme en la sekva figuro. La figuro konsideras la emerĝantan scion, ke la DNS-serviloj de Cloudflare estas malantaŭ fajroŝirmilo.
Ĉe Catchpoint ni kuris simplajn GET-testojn (ne retumeblajn testojn), kiuj montris multajn fiaskojn. Ili estis kaŭzitaj de la samaj DNS-eraroj.
Ni komencis sencimigi ĉi tiujn erarojn uzante fosi kaj trovis, ke je la unua peto la adreso estas ĝuste difinita, kaj laŭ ripeta peto ni ricevas ĉiun fojon SERVFAIL и ne trovita. Kial ĉi tio okazas subite?
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)Ne ekzistas tiaj eraroj dum pridemandado de Cloudflare NS-serviloj rekte:
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Ĉi tio signifas, ke la problemo estas flanke de la "loka" DNS-servilo aŭ la servilo de la provizanto.
Plia esploro montris tion SERVFAIL ni konsentas AAAA-rekordoj.
Rezultis, ke petante de Cloudflare AAAA-registro kiu ne ekzistas en la domajno, respondis Cloudflare А-an enskribo kiu estas eraro kaj nekonformeco kun la RFC. Kial la loka solvanto (xxxx) Mi ne ŝatis ĝin, kaj li respondis SERVFAIL. Ĉi tiu konduto estas klare videbla en la suba protokolo:
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
Ni sendis cimraporton al Cloudflare, kaj ili riparis ĝin post iom da tempo. Ĝi montriĝis interesa: nuntempe ankoraŭ ne ekzistas IPv6-subteno en Ĉinio, do Cloudflare ne povis doni sian IPv6-adreson tie responde al peto. AAAA-rekordoj. Fine ĉio estis solvita tiel, ke Cloudflare komencis respondi por Ĉinio NODATA al tiaj petoj.
Tiel, DNS-eraroj en Catchpoint-testoj malpliiĝis akre, sed ne tute. Tempoj ankoraŭ estas ĉi tie:
Kaj ni komencis serĉi alian solvon.
En la sekva parto mi rakontos al vi kiel ni provis la ĉinan nubon Alibaba Nubo, kiel, kun la helpo de iom da "magio" de Nginx, ni povis rapide krei solvojn PoC (Pruvo de Koncepto), kiel ni kreis Multi-Cloud-solvojn, unu el kiuj finfine multe helpis akceli la laboron de la servo. el Ĉinio.
Restu agordita!
Sekvaj partoj
fonto: www.habr.com
