Hello everyone!
Nikita is yn kontakt - in systeem yngenieur fan it bedriuw SEMrush. Hjoed sil ik jo fertelle hoe't wy de taak hawwe om de stabiliteit fan ús semrush.com-tsjinst yn Sina te garandearjen, en hokker problemen wy tsjinkamen tidens de ymplemintaasje dêrfan (jûn de lokaasje fan ús datasintrum oan 'e eastkust fan' e Feriene Steaten).
Dit sil in grut ferhaal wêze, ferdield yn ferskate artikels. Ik sil jo fertelle hoe't it allegear barde foar ús: fan in folslein net-funksjonele tsjinst út Sina, oant prestaasje-yndikatoaren fan 'e tsjinst op it nivo fan syn Amerikaanske ferzje foar Amerikanen. Ik beloof dat it ynteressant en nuttich sil wêze. Dus, litte wy gean.
Problemen fan it Sineeske ynternet
Sels de fierste persoan fan 'e spesifikaasjes fan netwurkadministraasje hat oer heard Grutte Firewall fan Sina. Wow, klinkt cool, krekt? Mar wat it is en hoe't it eins wurket is in nochal yngewikkelde fraach. Jo kinne fine in protte artikels op it ynternet wijd oan dit, mar út in technysk eachpunt, de struktuer fan dizze firewall wurdt net beskreaun oeral. Wat lykwols net ferrassend is. Ik sil daliks tajaan dat ik op basis fan de resultaten fan in jier wurk net krekt sizze kin hoe't it wurket, mar ik kin jo fertelle oer myn opmerkings en praktyske konklúzjes. En wy sille begjinne mei geroften oer dizze firewall.
D'r binne in protte geroften oer dizze heul firewall. Litte wy de wichtichste en meast nijsgjirrige fan har sammelje yn ien list:
- Google, Facebook, Twitter en oare ferlykbere tsjinsten binne blokkearre en wurkje net yn Sina.
- Elk ferkear dat Bûten Sina en YN Sina giet, wurdt parseard en beheind mei it brûken fan masine-learen (yn it gefal fan fertocht ferkear), wat it (ferkear) troch de grins gâns fertraget.
- Sineeske yntelliginsje-ynstânsjes sille elk fersifere ferkear hackje dat troch har firewall giet.
- VPN-tunnels, IPSEC-tunnels binne ynstabyl, crashje en wurde konstant blokkearre.
- De ienfâldiger de fersifering, de ienfâldiger de passfrase dy't brûkt wurdt om ferkear te ferifiearjen/fersiferjen, hoe flugger it troch de Sineeske brânmuorre giet.
Hjir is wat wy fûnen oer dizze geroften:
- Google, Facebook, Twitter en oare ferlykbere tsjinsten binne yndie blokkearre (jo KO), mar in protte technyske Google-domeinen, bygelyks, binne net ferbean en wurkje (itselde gstatic.com). De konklúzje folget hjirút: jo moatte net roekeloos alle Google en oare boarnen útknipe dy't blokkeare lykje te wêzen.
- Elk ferkear dat de grins passeart, foeget echt serieuze fertraging ta oan syn tiid. Sjoch nei de twa resultaten. Ien side, ien side, ienfâldich GET curl'om. De earste mjitting wie út Sina sels (de prachtige stêd Shenzhen). De twadde waard mjitten fan bûten út Hong Kong (it hat soevereiniteit, en d'r is gjin brânmuorre tusken har en de wrâld). De ôfstân tusken de stêden yn in rjochte line is likernôch 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/sSoarch omtinken tiid_ferbine. En yn 't algemien sjogge jo it resultaat: de brânmuorre foeget 4 ekstra sekonden ta, wat monsterlik lang is.
- VPN- en IPSEC-tunnels mislearje faak. Ik sil hjir in bytsje letter en yn mear detail oer prate. VPN-tsjinners dy't brûkt wurde troch brûkers wurde oer de tiid blokkearre (meastentiids binnen in dei nei it begjin fan gebrûk).
- Der is in miening ûntfongen fan minsken dy't yn Sina wenje dat de ienfâldiger de fersifering fan ferkear, hoe flugger it troch de grins giet, om't it maklik te begripen is dat der neat yllegaal oan is. En op deselde wize krijt "skjin" ferkear mear bânbreedte en trochgongssnelheid, wylst "smoarch" ferkear, dêr't neat yn ferstean kin, krekt oarsom in stadiger passaazje krijt. Ik sil bygelyks krul brûke om ifconfig.co fia HTTPS en 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/sIn ferskil fan 5 sekonden foar in totale downloadtiid fan 13 bytes. Boppedat kinne jo by it dwaan fan sa'n test ferskate kearen fernimme dat GET op HTTP elke kear yn algemien deselde tiid foltôge wurdt, wylst op HTTPS de side soms yn 3, 5, 10 en sels 17 sekonden reagearret. Soms barre SSL-flaters:
Unknown SSL protocol error in connection to ifconfig.co:443.
Dus wat wy hawwe:
- De problemen makke troch de Sineeske firewall binne hjirboppe beskreaun.
- Pings nei eksterne boarnen en binnen tunnels ferdwine periodyk.
- Wachttiid tusken twa punten feroaret konstant, en faaks is it gewoan ûnfoarspelber. By it ferbinen fan ferskate stêden/regio's ferwachtsje jo dat op basis fan de geografyske lokaasje fan de regio's de fertraging minder is, mar jo krije krekt de tsjinoerstelde situaasje.
- It ynternet en kommunikaasjekanalen binne fluch of stadich. Der is in lichte ôfhinklikens fan 'e tiid fan' e dei en dei fan 'e wike, mar net altyd.
- DNS-oanfragen nei de bûtenwrâld út Sina binne soms de tastiene time-out.
De ôfbylding dy't ûntstiet is gewoan "poerbêst."
It datasintrum, lykas ik al sei, is yn 'e eastlike Feriene Steaten, en de hiele SEMrush bestiet út tsientallen mei-inoar ferbûn produkten, backends, frontends, databases, en dit alles yn' e DC en wolken. Wy, as in team fan systeembehearders, krigen de taak om fluch te begjinnen mei it wurk yn Sina mei in bytsje muoite.
Wy moasten in wichtige fraach beäntwurdzje: is it mooglik om mei in bytsje kosten te kommen en alle problemen op te lossen dy't ferbûn binne mei it Sineeske ynternet en firewall op it netwurk / wolk / tsjinner nivo?
Wy begûnen mei it ûntfangen .
ICP lisinsje
Om jo tsjinst binnen Sina (Fêstelân Sina) te hostjen en tests út te fieren, moatte jo earst in ICP-lisinsje krije foar it domein.
As it brûkersferkear fan jo side wurdt beëinige binnen it fêstelân fan Sina, en as jo domein gjin ICP-lisinsje hat, sil jo ferkear blokkearre wurde oan 'e ISP / hostingkant. Nijsgjirrich is dat de ICP-lisinsje in spesifike provider omfettet, itsij Cloudflare as Alibaba Cloud. Dêrom, as jo in ICP-lisinsje foar Cloudflare hawwe krigen en jo webside mei har hoste, sille jo net "naadloos" kinne ferpleatse nei Alibaba Cloud. Jo moatte in oare hosting tafoegje oan dizze lisinsje.
Nei't wy in ICP-lisinsje krigen hawwe foar it domein, koene wy spesifike technyske ideeën en oplossingen betinke en útfiere.
Testing oplossings
Mar foardat jo direkt staging-opsjes oanmeitsje, de knoppen draaie, de prestaasjes fan 'e side en har snelheid optimalisearje, moatte jo in ark kieze om it te testen om te sjen hokker fan ús aksjes de prestaasjes fan' e side ferbetterje of, krekt oarsom, fergrieme.
Us testynstrumint moast oan twa haadeasken foldwaan:
- it soe tests út Sina moatte kinne útfiere,
- it moat browsertests hawwe.
Sa fûnen wy ! Se hawwe poerbêste dekking fan testlokaasjes rûn de wrâld. Yn Sina kinne tests ek útfierd wurde út 100500 provinsjes fia dit ark. Elk hat ferskate ferskillende oanbieders + de mooglikheid om te dwaan Rêchbonke-tests (wat as in firtuele masine yn in datasintrum) en Lastmile-tests (sa ticht mooglik by brûkersbetingsten, aka wurkstasjon). It lêste type tests is djoerder.
Nei it ôfsluten fan in jierkontrakt (minder dan dat is net mooglik), begûnen wy it ynstrumint te studearjen. Earlik sein, wy wiene noflik ferrast troch syn funksjonaliteit. Jo kinne rinne:
- DNS tests,
- Webtests (browsertests, ienfâldige GET/POST, emulaasje fan mobile kliïnten, ensfh.),
- Transaksjekontrôles (bygelyks oanmelde),
- API tests,
- Ping, traceroute, NTP, ensfh.
Jo kinne net alles opskriuwe. En it wichtichste kin elke test frij goed wurde oanpast troch in boskje kopteksten en oare parameters ta te foegjen. De útfier is in enoarme hoemannichte ynformaasje dy't jo test folslein beskriuwt. As wy prate oer de meast nijsgjirrige dingen foar ús (browsertests), omfettet it resultaat:
- Ferbine, wachtsje, laden, SSL, DNS-tiid,
- TTFB, TTLB, Dokumint foltôge, Rendertiid, DOM-laden,
- Response (iets tichtby Time To First Byte), Webpage Response (iets tichtby Time To Last Byte),
- Elke percentiel, gemiddelde, mediaan tiid
- ensfh.
Dêrnjonken binne al dizze metriken geweldig om feroaringen te sjen en te begripen oft dingen better binne wurden. Wy seagen benammen nei Response, Webside Response, Median, 75 en 95 Persintilen.
In wichtige fraach dy't fan it begjin ôf yn 'e loft siet: Kinne jo Catchpoint fertrouwe?? Werspegelet dit ark de echte side-laadsnelheid yn Sina út ferskate stêden, of is it gewoan in soarte fan test yn in fakuüm dat neat te krijen hat mei echte brûkersûnderfining?
Dit is in grut probleem, om't yn Ruslân is it hast ûnmooglik om betrouber út te finen hoe't in side út Sina wurket. Troch in socks-proxy te dwaan fia in firtuele masine, is it einresultaat dat de side binnen in pear minuten laadt, wat gewoan net akseptabel is foar testen, dus de ienige opsje foar hânmjittich testen is krul en ienfâldich GET fan 'e konsole mei in timer . Dit helpt om't dizze test de snelheid fan 'e netwurkoplossing goed wjerspegelet, en as d'r ek browsertests binne, dan is it heul goed.
Letter binne wy sels nei Sina gien en wiene der fan oertsjûge Jo kinne Catchpoint fertrouwe; it wjerspegelet frij sekuer echte prestaasje-yndikatoaren.
Cloudflare China Network
Om't wy Cloudflare mei súkses brûke foar it haaddomein semrush.com, hawwe wy besletten om fuortendaliks har funksje neamd te besykjen . Dizze opsje is allinich ynskeakele foar Enterprise-siden op apart oanfraach en foar in ekstra fergoeding. It is ek allinich beskikber foar siden dy't in passende ICP-lisinsje hawwe dy't Cloudflare as de provider listet. Nei it ynskeakeljen wurdt de "Sineeske CDN" fan Cloudflare beskikber foar de side - ferkear út Sineeske regio's lânt by de tichtstbye PoP (Points of Presence) CF, en dan fia syn netwurken as de netwurken fan providers / partners wurdt it levere oan 'e oarsprong .
It diagram fan dizze testbank wurdt hjirûnder presintearre.
Dit is in geweldige opsje foar ús. It docht bliken dat it twadde domein ek foar CF sil wêze, wat net taheakket oan it oantal oplossingen brûkt yn it bedriuw, en ek de ynfrastruktuer praktysk net komplisearret.
Wy hawwe browsertests útfierd en dit is wat barde:
Reade diamanten binne testmislukkingen. De bestannen hjirûnder binne DNS-flaters (time-out oplosse). De flaters oan de top binne timeouts.
Uptime: 86.6
Mediaan: 18 s
75 Persintyl: 29.3s
95 Persintyl: 60s
Mediaan, nei it laden fuorthelle reCaptcha (Google-tsjinst blokkearre yn Sina) fermindere fan 28 nei 18 sekonden. Mar dit binne noch altyd skriklike resultaten, yn betinken nommen dat deselde test foar semrush.com (út de FS) joech minder as 10 sekonden foar 95% fan brûkers (út de FS) op deselde side (statysk + dynamysk).
Jo kinne yn elke test gean en sjen Wetterfal en oare mear detaillearre parameters. Wy begûnen te ûndersiikjen fan 'e redenen foar de flaters, en as foar timeouts alles min of mear dúdlik is: it ynternet yn Sina "beweecht yn en út", fanwegen dit is de snelheid fan ferbining en laden fan boarnen út it bûtenlân ynstabyl en unjildich, doe fernuveren de DNS-flaters ús tige. Dat fûnen wy PoP Cloudflare lizze eins yn Sina, it sideadres wurdt oplost nei ien anycast IP, mar de DNS-tsjinners binne Amerikaansk, en dêrom wurde DNS-oanfragen twongen om oer de grins te gean, dus soms mislearje se.
Nei it ophelderjen fan dizze fraach mei CF, die bliken dat Se hawwe gjin eigen DNS-tsjinners yn Sina, en wannear't it sil wêze is noch ûnbekend.
Dêrom besleaten wy allinich Cloudflare DNS te testen en feroare it Cloudflare-bestjoeringsmeganisme foar ús side nei de "Allinnich DNS" Dit is in modus as Cloudflare gjin proxyferkear troch himsels docht, wat betsjut dat it gjin DDoS-beskerming, CDN en oare funksjes leveret, en wurket yn 'e modus fan in gewoane DNS-tsjinner.
Dizze stand wurdt skematysk werjûn yn 'e folgjende figuer. De figuer hâldt rekken mei de opkommende kennis dat Cloudflare's DNS-tsjinners efter in firewall sitte.
By Catchpoint rûnen wy ienfâldige GET-tests (net browsertests), dy't in protte mislearrings lieten. Se waarden feroarsake troch deselde DNS flaters.
Wy begûnen dizze flaters te debuggen mei dolle en fûn dat op it earste fersyk it adres goed is bepaald, en op werhelle fersyk krije wy elke kear SERVFAIL и net fûn. Wêrom bart dit ynienen?
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)D'r binne gjin sokke flaters as jo direkt opfreegje op Cloudflare NS-tsjinners:
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.192Dit betsjut dat it probleem oan 'e kant is fan' e "lokale" DNS-tsjinner as de tsjinner fan 'e provider.
Neier ûndersyk die bliken dat SERVFAIL wy komme op resolúsje AAAA- records.
It die bliken dat by it oanfreegjen fan Cloudflare AAAA-record dat net bestiet yn it domein, antwurde Cloudflare А-in yngong dat is in flater en net-neilibjen fan de RFC. Wêrom docht de lokale resolver (xxxx) Ik mocht it net leuk, en hy antwurde SERVFAIL. Dit gedrach is dúdlik sichtber yn it log hjirûnder:
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
Wy hawwe in brekrapport yntsjinne by Cloudflare, en se hawwe it nei in skoft repareare. It blykte nijsgjirrich te wêzen: op it stuit is d'r op it stuit noch gjin IPv6-stipe yn Sina, dus koe Cloudflare syn IPv6-adres dêr net útjaan as antwurd op in fersyk AAAA- records. Uteinlik waard alles sa oplost dat Cloudflare begon te ferantwurdzjen foar Sina GJIN GEGEVENS oan sokke fersiken.
Sa binne DNS-flaters yn Catchpoint-tests sterk ôfnommen, mar net folslein. Timeouts binne noch hjir:
En wy begûnen te sykjen nei in oare oplossing.
Yn it folgjende diel sil ik jo fertelle hoe't wy de Sineeske wolk testen Alibaba Cloud, hoe, mei help fan in bytsje "magy" fan Nginx, wy koenen fluch meitsje PoC (Proof of Concept) oplossings, hoe't wy makke Multi-Cloud oplossings, wêrfan ien úteinlik sterk holp it wurk fan de tsjinst flugger út Sina.
Bliuw op 'e hichte!
Folgjende dielen
Boarne: www.habr.com
