Hola a todos!
Nikita harremanetan dago - konpainiako sistema ingeniaria SEMrush. Gaur esango dizut nola egin genuen aurre Txinan gure semrush.com zerbitzuaren egonkortasuna bermatzeko zereginari, eta inplementazio garaian zer arazo aurkitu genituen (gure datu-zentroa Estatu Batuetako ekialdeko kostaldean kokatuta dagoen ikusita).
Istorio handia izango da hau, hainbat artikulutan banatuta. Esango dizut nola gertatu zitzaigun guztia: Txinako zerbitzu guztiz ez-funtzionala batetik, zerbitzuaren errendimendu-adierazleetara amerikarrentzat bere bertsio amerikarraren mailan. Interesgarria eta erabilgarria izango dela agintzen dut. Beraz, goazen.
Txinako Interneten arazoak
Sare-administrazioaren berezitasunetatik urrunen dagoenak ere entzun du Txinako suebaki handia. Wow, polita dirudi, ezta? Baina zer den eta nola funtzionatzen duen benetan galdera konplexu samarra da. Interneten horri buruzko artikulu asko aurki ditzakezu, baina ikuspuntu teknikotik, suebaki honen egitura ez da inon azaltzen. Hori, ordea, ez da harritzekoa. Berehala aitortuko dut urtebeteko lanaren emaitzen arabera ezingo dudala esan zehatz-mehatz nola funtzionatzen duen, baina nire iruzkinak eta ondorio praktikoak kontatu ditzaket. Eta suebaki honi buruzko zurrumurruekin hasiko gara.
Suebaki honi buruz zurrumurru asko daude. Bildu ditzagun horietako nagusiak eta interesgarrienak zerrenda batean:
- Google, Facebook, Twitter eta antzeko beste zerbitzu batzuk blokeatuta daude eta ez dute funtzionatzen Txinan.
- Txinatik KANPO eta Txina SARRERA doan trafikoa ikasketa automatikoa erabiliz (trafiko susmagarriaren kasuan) aztertu eta mugatzen da, eta horrek asko moteltzen du mugatik igarotzen den trafikoa (trafikoa).
- Txinako inteligentzia agentziek haien suebakitik igarotzen den trafiko enkriptatua pirateatu egingo dute.
- VPN tunelak, IPSEC tunelak ezegonkorrak dira, huts egiten dute eta etengabe blokeatzen dira.
- Zenbat eta enkriptatzea errazagoa izan, trafikoa autentifikatzeko/zifratzeko erabiltzen den pasaesaldia, orduan eta azkarrago igaroko da txinatar suebakitik.
Hona hemen zurrumurru hauei buruz aurkitu duguna:
- Google, Facebook, Twitter eta antzeko beste zerbitzu batzuk blokeatuta daude (zure KO), baina Google domeinu tekniko asko, adibidez, ez daude debekatuta eta funtzionatzen dute (gstatic.com bera). Hortik ondorioztatzen da ondorioa: ez dituzu arduragabekeriaz moztu behar blokeatuta daudela diruditen Google eta beste baliabide guztiak.
- Mugatik pasatzen den trafiko orok atzerapen larria gehitzen dio bere denborari. Begira bi emaitzak. Gune bat, orri bat, GET sinplea curl'om. Lehen neurketa Txinatik bertatik izan zen (Shenhen hiri ederra). Bigarrena Hong Kongetik kanpotik neurtu zen (burujabetza du, eta ez dago suebakirik haren eta munduaren artean). Lerro zuzen batean hirien arteko distantzia gutxi gorabehera 30-40 km-koa da.
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/sKontuan izan denbora_konektatu. Eta, oro har, emaitza ikusten duzu: suebakiak 4 segundo gehitzen ditu, izugarri luzea dena.
- VPN eta IPSEC tunelek askotan huts egiten dute. Honetaz apur bat geroago eta zehatzago hitz egingo dut. Erabiltzaileek erabiltzen dituzten VPN zerbitzariak denboran zehar blokeatzen dira (normalean erabiltzen hasi eta egun bateko epean).
- Txinan bizi diren pertsonengandik jasotako iritzia da trafikoa zenbat eta enkriptatze errazagoa izan, orduan eta azkarrago igarotzen da mugatik, erraz ulertzen baita legez kanpoko ezer ez dagoela. Eta era berean, trafiko “garbiak” banda zabalera eta pasabide-abiadura gehiago jasotzen du, eta trafiko “zikinak”, ezer ulertu ezin den bitartean, igarobide motelagoa jasotzen du, aitzitik. Adibidez curl erabiliko dut ifconfig.co HTTPS eta HTTP protokoloaren bidez.
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 segundoko aldea 13 byteko deskarga-denbora guztira. Gainera, halako proba bat hainbat aldiz egitean, nabarituko duzu GET HTTP-n oro har aldi berean osatzen dela aldi bakoitzean, HTTPS-en, aldiz, guneak batzuetan 3, 5, 10 eta 17 segundotan erantzuten duela. Batzuetan SSL akatsak gertatzen dira:
Unknown SSL protocol error in connection to ifconfig.co:443.
Beraz, zer daukagu:
- Txinako suebakiak sortutako arazoak goian deskribatzen dira.
- Kanpoko baliabideetarako eta tunel barruko ping-ak aldizka desagertzen dira.
- Bi punturen arteko latentzia etengabe aldatzen ari da, eta askotan ezustekoa da. Hiri/eskualde desberdinak konektatzean, eskualdeen kokapen geografikoaren arabera atzerapena txikiagoa izango dela espero duzu, baina guztiz kontrako egoera lortzen duzu.
- Internet eta komunikazio bideak azkarrak edo motelak dira. Eguneko orduaren eta asteko egunaren menpekotasun apur bat dago, baina ez beti.
- Txinatik kanpoko mundura egindako DNS eskaerak batzuetan baimendutako denbora-muga gainditzen dute.
Agertzen den argazkia "bikaina" besterik ez da.
Datu-zentroa, lehen esan dudan bezala, Estatu Batuetako ekialdean dago, eta SEMrush osoa elkarrekin konektaturiko hamaika produktuz osatuta dago, backend, frontend, datu-base eta hori guztia DC eta hodeietan. Guk, sistema-administratzaile talde gisa, Txinan azkar lanean hasteko ardura eman ziguten, ahalegin gutxirekin.
Galdera garrantzitsu bati erantzun behar genion: posible al da gastu gutxirekin ateratzea eta sare/hodei/zerbitzari mailan Txinako Internet eta suebakiarekin lotutako arazo guztiak konpontzea?
Jasotzen hasi ginen .
ICP lizentzia
Zure zerbitzua Txinan (Txina kontinentala) ostatu eta probak egin ahal izateko, lehenik ICP lizentzia lortu behar duzu domeinurako.
Zure guneko erabiltzaileen trafikoa Txina kontinentalean amaitzen bada, eta zure domeinuak ICP lizentziarik ez badu, zure trafikoa blokeatuko da ISP/ostalari aldean. Interesgarria da ICP lizentziak hornitzaile zehatz bat barne hartzen du, izan Cloudflare edo Alibaba Cloud. Hori dela eta, Cloudflare-rako ICP lizentzia jaso baduzu eta haiekin zure webgunea ostatatuta baduzu, ezin izango zara Alibaba Cloud-era "eragin gabe" mugitu. Lizentzia honi beste hosting bat gehitu beharko diozu.
Domeinurako ICP lizentzia jasota, ideia eta irtenbide tekniko zehatzak asmatu eta ezarri ahal izan genituen.
Irtenbideak probatzea
Baina zuzenean eszenatze-aukerak sortu, botoiak biratu, gunearen errendimendua eta abiadura optimizatu baino lehen, probatzeko tresna bat aukeratu behar duzu, gure ekintzetako zein hobetu edo, aitzitik, gunearen errendimendua okertzen duten ikusteko.
Gure proba tresnak bi baldintza nagusi bete behar zituen:
- Txinatik probak egiteko gai izan beharko luke,
- arakatzailearen probak izan behar ditu.
Beraz, aurkitu dugu ! Mundu osoko proba-kokapenen estaldura bikaina dute. Txinan, tresna honen bidez 100500 probintzietatik ere egin daitezke probak. Bakoitzak hainbat hornitzaile ditu + egiteko gaitasuna Backbone-probak (makina birtual baten antzeko zerbait datu-zentro batean) eta Azken kilometroa-probak (erabiltzaile-baldintzetatik ahalik eta hurbilen, lan-estaziotik). Azken proba mota hau garestiagoa da.
Urteko kontratua eginda (hori baino gutxiago ez da posible), tresna aztertzen hasi ginen. Egia esanda, atsegin handiz harritu gintuen bere funtzionaltasunak. Exekutatu dezakezu:
- DNS probak,
- Web probak (arakatzailearen probak, GET/POST sinpleak, bezero mugikorren emulazioa, etab.),
- Transakzio-txekeak (adibidez, saioa hasteko),
- API probak,
- Ping, traceroute, NTP, etab.
Ezin duzu dena zerrendatu. Eta garrantzitsuena, proba bakoitza nahiko ondo pertsonaliza daiteke goiburu eta beste parametro batzuk gehituz. Irteera zure proba guztiz deskribatzen duen informazio kopuru handia da. Guretzat gauzarik interesgarrienei buruz hitz egiten badugu (nabigatzaileen probak), emaitzak honako hauek dira:
- Konektatu, Itxaron, Kargatu, SSL, DNS denbora,
- TTFB, TTLB, Dokumentua osatuta, Errendatze denbora, DOM karga,
- Erantzuna (Time To First Byte-tik gertu dagoen zerbait), Web-orriaren erantzuna (Time To Last Bytetik gertu dagoen zerbait),
- Edozein pertzentila, batez bestekoa, denbora mediana
- Etab.
Horren arabera, neurri horiek guztiak bikainak dira aldaketak ikusteko eta gauzak hobetu diren ala ez ulertzeko. Batez ere begiratu dugu Erantzuna, Web-orriaren Erantzuna, Mediana, 75 eta 95 pertzentilak.
Hasiera-hasieratik airean egon zen galdera garrantzitsu bat: Fida al dezakezu Catchpoint-ean?? Tresna honek islatzen al du Txinan hiri ezberdinetako guneen benetako karga-abiadura, edo hutsean egindako proba bat besterik ez da, erabiltzailearen esperientzia errealarekin zerikusirik ez duena?
Arazo handia da hau, Errusian egonda ia ezinezkoa baita fidagarritasunez jakitea Txinako gune batek nola funtzionatzen duen. Galtzerdi-proxy bat makina birtual baten bidez eginez, azken emaitza da gunea minutu pare batean kargatzen dela, eta hori probak egiteko onartezina da, beraz, eskuzko probak egiteko aukera bakarra kizkurtzea eta kontsolatik tenporizadore batekin GET erraza da. . Horrek laguntzen du proba honek sareko irtenbidearen abiadura ondo islatzen duelako, eta arakatzailearen probak ere badaude, oso ona da.
Geroxeago gu geu Txinara joan ginen eta hori sinetsita geunden Catchpoint-ean fida zaitezke; nahiko zehaztasunez islatzen ditu benetako errendimendu-adierazleak.
Cloudflare Txinako sarea
Semrush.com domeinu nagusirako Cloudflare arrakastaz erabiltzen dugunez, bere eginbidea berehala probatzea erabaki dugu. . Aukera hau Enpresen guneetarako soilik gaituta dago aparteko eskaeraren bidez eta kuota gehigarri baten truke. Cloudflare hornitzaile gisa zerrendatzen duen ICP lizentzia egokia duten guneentzat ere eskuragarri dago. Gaitu ondoren, Cloudflare-ko "Txinako CDN" gunerako erabilgarri egongo da - Txinako eskualdeetako trafikoa hurbileneko PoP (Presentzia-puntuak) CF-ra iristen da, eta, ondoren, bere sareen edo hornitzaile/bazkideen sareen bidez jatorrira entregatzen da. .
Proba-banku honen diagrama behean aurkezten da.
Aukera bikaina da guretzat. Ematen du bigarren domeinua CFrentzat ere izango dela, eta horrek ez du enpresan erabiltzen diren soluzio kopurua gehitzen, eta, gainera, ia ez du azpiegitura zailtzen.
Arakatzailearen probak egin genituen eta hau da gertatu zena:
Diamante gorriak proba hutsak dira. Beheko fitxategiak DNS akatsak dira (ebatzi denbora-muga). Goiko porrotak denbora-muga dira.
Epea: 86.6
Mediana: 18s
75 ehunekoa: 29.3s
95 ehunekoa: 60s
Mediana, karga kendu ondoren reCaptcha (Txinan Google zerbitzua blokeatuta) 28 segundotik 18ra murriztu da. Baina emaitza ikaragarriak dira oraindik ere, kontuan hartuta semrush.com-en (AEBetakoa) proba berak 10 segundo baino gutxiago eman zituela erabiltzaileen % 95ek (AEBetakoak) orrialde berean (estatikoa + dinamikoa).
Proba bakoitzean sartu eta begiratu dezakezu Waterfall eta beste parametro zehatzago batzuk. Akatsen arrazoiak ikertzen hasi ginen, eta denbora-mugetarako dena argiago edo gutxiago badago: Txinan Internet "barruan eta kanpoan mugitzen da", horregatik atzerriko baliabideen konexioaren eta kargatzeko abiadura ezegonkorra eta irregularra da, orduan DNS akatsek asko harritu gintuzten . Hori aurkitu dugu Po Cloudflare benetan Txinan kokatzen da, gunearen helbidea anycast IP batera ebazten da, baina DNS zerbitzariak amerikarrak dira, horregatik DNS eskaerak muga gainditzera behartuta daude, eta, beraz, batzuetan huts egiten dute.
CF-rekin galdera hori argitu ondoren, horixe atera zen Ez dute DNS zerbitzari propiorik Txinan, eta noiz izango den oraindik ezezaguna da.
Hori dela eta, Cloudflare DNS soilik probatzea erabaki genuen eta gure gunerako Cloudflare mekanismo eragilea ""DNS soilik" Cloudflare-k berez proxy trafikoa egiten ez duen modua da hau, hau da, ez du DDoS babesik, CDN eta bestelako ezaugarririk eskaintzen eta DNS zerbitzari arrunt baten moduan funtzionatzen du.
Stand hau eskematikoki ageri da hurrengo irudian. Kopuruak kontuan hartzen du Cloudflare-ren DNS zerbitzariak suebaki baten atzean daudela azaleratzen ari den ezagutza.
Catchpoint-en GET proba sinpleak egin genituen (ez arakatzaileen probak), hutsegite asko erakusten zituztenak. DNS akats berdinek eragin zituzten.
Errore hauek erabiltzen hasi ginen arazketan dig eta ikusi zuen lehenengo eskaeran helbidea zuzen zehazten dela, eta behin eta berriro eskatuz gero jasotzen dugula SERVFAIL и ez da aurkitu. Zergatik gertatzen da hau bat-batean?
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)Ez dago horrelako errorerik Cloudflare NS zerbitzariak zuzenean kontsultatzean:
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.192Horrek esan nahi du arazoa "tokiko" DNS zerbitzariaren edo hornitzailearen zerbitzariaren aldean dagoela.
Ikerketa gehiagok erakutsi zuen hori SERVFAIL konponbidean jartzen gara AAAA-erregistroak.
Hori gertatu zen Cloudflare-ri eskatzean AAAA-Domeinuan existitzen ez den erregistroa, erantzun zuen Cloudflare-k А- RFC akatsa eta ez-betetzea den sarrera. Zergatik tokiko konpontzaileak (xxxx) Ez zait gustatu, eta erantzun zuen SERVFAIL. Jokabide hau argi ikusten da beheko erregistroan:
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
Akatsen txostena bidali genion Cloudflare-ri, eta denbora pixka bat igaro ondoren konpondu zuten. Interesgarria suertatu zen: momentuz ez dago oraindik IPv6 euskarria Txinan, beraz, Cloudflare-k ezin izan zuen bertan eman bere IPv6 helbidea eskaera bati erantzunez. AAAA-erregistroak. Azkenean, dena konpondu zen, hala nola, Cloudflare Txinaren alde erantzuten hasi zen NODATA horrelako eskaerei.
Horrela, Catchpoint probetan DNS akatsak nabarmen murriztu ziren, baina ez guztiz. Denbora-muga hemen dago oraindik:
Eta beste irtenbide bat bilatzen hasi ginen.
Hurrengo zatian Txinako hodeia nola probatu genuen kontatuko dizuet Alibaba Cloud, nola, Nginx-en "magia" txiki baten laguntzaz, PoC (Kontzeptuaren Froga) soluzioak azkar sortzeko gai izan ginen, nola sortu genituen Multi-Cloud soluzioak, eta horietako batek azken finean asko lagundu zuen zerbitzuaren lana bizkortzen. Txinatik.
Stay tuned!
Hurrengo zatiak
Iturria: www.habr.com
