Përshëndetje të gjithëve!
Në linjë është Nikita — inxhinier sistemesh nga kompania SЕMrush. Sot do t'ju flas për atë se si na u paraqit detyra për të siguruar stabilitetin e funksionimit të shërbimit tonë semrush.com në Kinë, dhe me çfarë problemesh u përballëm gjatë realizimit të saj (duke pasur parasysh vendndodhjen e qendrës sonë të të dhënave në bregun lindor të Shteteve të Bashkuara).
Kjo do të jetë një histori e madhe, e ndarë në disa artikuj. Do t'ju tregoj se si gjithçka ndodhi te ne: nga një shërbim që nuk funksiononte në Kinë, deri te treguesit e funksionimit të shërbimit në nivelin e versionit të tij amerikan për amerikanët. Premtoj, do të jetë interesante dhe e dobishme. Pra, le të fillojmë.
Problemet e internetit kinez
Edhe personi më i largët nga specifika e administratës rrjet të paktën një herë ka dëgjuar rreth Murit të Madh kinez të Zjarrit. Uuu, tingëllon fantastike, apo jo? Por çfarë është kjo, si funksionon në të vërtetë — është një pyetje mjaft e komplikuar. Në internet mund të gjeni shumë artikuj të dedikuar për këtë, por nga një pikëpamje teknike, struktura e këtij muri zjarri nuk përshkruhet askund. Çfarë, megjithatë, nuk është e habitshme. Pranoj se në përfundim të një viti pune nuk do të jem në gjendje të them me siguri se si funksionon ai, por do të mund të flas për vërejtjet dhe përfundimet e mia praktike. Dhe do të fillojmë me thashethemet për këtë mur zjarri.
Ka shumë thashetheme rreth këtij muri zjarri. Le të mbledhim më kryesoret dhe më interesante nga ato në një listë:
- Google, Facebook, Twitter dhe shërbime të ngjashme janë të bllokuara dhe nuk funksionojnë në Kinë.
- Çdo trafik që shkon JASHTË Kinës dhe në Kinë analizohen dhe kufizohen me ndihmën e mësimit të makinerive (në rast të trafikut të dyshimtë), gjë që e ngadalëson shumë (trafikun) që kalon nëpër kufi.
- Shërbimet speciale kineze do të thyejnë çdo trafik të enkriptuar që kalon përmes murit të tyre të zjarrit.
- VPN-tunellet, tunellet IPSEC janë të pasigurta, bien dhe bllokohen vazhdimisht.
- Sa më e thjeshtë të jetë enkriptimi, aq më e thjeshtë është fraza kalimtare e përdorur për autentifikimin/enkriptimin e trafikut, aq më shpejt kalon përmes murit të zjarrit kinez.
Këtu është ajo që arritëm të zbulojmë rreth këtyre thashethemeve:
- Google, Facebook, Twitter dhe shërbime të ngjashme janë vërtet të bllokuara (ky është KOT), por shumë dominio teknikë të Google, për shembull, nuk janë të bllokuar dhe funksionojnë (po i njëjti gstatic.com). Nga këtu vijmë në përfundimin se nuk duhet të shkatërrojmë pa mend çdo burim të dukshëm të bllokuar të Google dhe të tjerëve.
- Çdo trafik që kalon kufirin vërtetë i shton një vonesë të konsiderueshme kohës së tij. Shikoni dy rezultatet. Një faqe interneti, një faqe, një GET i thjeshtë curl’om. Matja e parë nga vetë Kina (një qytet i mrekullueshëm, Shenzhen). Matja e dytë jashtë nga Hong-Kongu (ka sovranitet, dhe midis tij dhe botës nuk ka firewall). Distanca ndërmjet qyteteve në një linjë është rreth 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/sKujdesi për time_connect. Dhe në përgjithësi, ju shihni rezultatin: firewall-i shton 4 sekonda të tepërta, që është jashtëzakonisht e gjatë.
- VPN-të dhe tunellet IPSEC vërtet shpesh bien. Për këtë do të flas më vonë dhe më në detaje. Serverët VPN që përdoren nga përdoruesit bllokohen me kalimin e kohës (zakonisht brenda një dite pas fillimit të përdorimit).
- Ka një mendim, marrë nga njerëzit që jetojnë në Kinë, se sa më e thjeshtë të jetë kriptimi i trafikut, aq më shpejt kalon ai kufirin, sepse është e lehtë të kuptosh se nuk ka asgjë të paligjshme brenda tij. Njëlloj, trafiku "i pastër" merr më shumë gjerësi dhe shpejtësi kalimi, ndërsa trafiku "i ndotur", në të cilin nuk ka asgjë të kuptueshme, merr një kalim më të ngadalshëm. Si shembull do të jap curl deri ifconfig.co në protokollet HTTPS dhe HTTP.
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/sNjë ndryshim prej 5 sekondash në kohën totale të ngarkesës për 13 byte. Ndërkohë, duke bërë një test të tillë disa herë, mund të vëreni se GET mbi HTTP përfundon në përgjithësi në të njëjtën kohë çdo herë, ndërsa për HTTPS faqja përgjigjet ndonjëherë për 3, 5, 10 dhe madje 17 sekonda. Ndonjëherë ndodhin gabime SSL:
Gabim i panjohur në protokollin SSL në lidhjen me ifconfig.co:443.
Pra, çfarë kemi:
- Problemet e shkaktuara nga firewall-i kinez, të përshkruara më sipër.
- Ping-et deri te burimet e jashtme dhe brenda tunelëve ndonjëherë bien.
- Latenca midis dy pikave ndryshon vazhdimisht, dhe shpesh është thjesht e paparashikueshme. Duke lidhur qytete/regjione të ndryshme, pritet që, për shkak të vendndodhjes gjeografike të rajoneve, vonesa të jetë më e vogël, por merrni të kundërtën.
- Internet dhe kanalet e komunikimit funksionojnë nganjëherë shpejt, nganjëherë ngadalë. Ka një varësi të vogël nga koha e ditës dhe dita e javës, por jo gjithmonë.
- Kërkesat DNS për në botën e jashtme nga Kina ndonjëherë tejkalojnë kohën maksimale të lejuar.
Pamja paraqitet thjesht “e shkëlqyer”.
Data qendra, siç e thashë, është në lindjen e Shteteve të Bashkuara, dhe e gjithë SEMrush përbëhet nga dhjetra produkte të ndërthurura, backend-e, frontend-e, baza të të dhënave, dhe gjithçka është në DC dhe në re. Para nesh, si ekip administratash sistemi, u vendos një detyrë që me përpjekje të vogla të fillojmë të punojmë shpejt në Kinë.
Na duhej të përgjigjeshim në një pyetje të rëndësishme: a mund të bëhet fjalë për të zgjidhur të gjitha problemet e lidhura me internetin kinez dhe firewall-in, në nivelin e rrjetit/re për serverat?
Filluam me marrjen e .
Licencë ICP
Për të pasur mundësinë të vendosni shërbimin tuaj brenda Kinës (Mainland China) dhe të kryeni teste, së pari duhet të merrni licencën ICP për domajnin.
Nëse trafiku i përdoruesve të faqes suaj ndalon brenda Mainland China, dhe nëse domeni juaj nuk ka një licencë ICP, trafiku juaj do të bllokohet nga ofruesi/hostingu. Është interesante se në licencën ICP përfshihet ofruesi specifik, qoftë Cloudflare apo Alibaba Cloud. Prandaj, nëse keni marrë një licencë ICP për Cloudflare dhe keni hostuar faqen tuaj atje, në vazhdim nuk do të mund të kaloni "pa prishje" në Alibaba Cloud. Do të nevojitet të shtoni një host të ri në këtë licencë.
Pas marrjes së licencës ICP për domenin, arritëm të shpikim dhe zbatojmë ide dhe zgjidhje teknike specifike.
Testimi i zgjidhjeve
Por para se të krijojmë opsione staging, të rregullojmë parametrat, të optimizojmë funksionimin dhe shpejtësinë e faqes, duhet të zgjidhim një mjet për testimin e saj, për të parë se cilat nga veprimet tona përmirësojnë ose, përkundrazi, përkeqësojnë funksionimin e faqes.
Mjeti ynë për testim duhet të përmbushë dy kërkesa kryesore:
- duhet të ketë mundësinë për të kryer teste nga Kina,
- duhet të ketë teste me shfletues.
Kështu gjetëm ! Ata kanë një përfaqësim të shkëlqyer të pikave të testimit në të gjithë botën. Në Kinë, përmes këtij mjeti, mund të kryhen teste edhe nga 100500 provinca. Në secilën disa ofrues të ndryshëm + mundësia për të kryer testet Backbone (diçka si një virtualizim në qendrën e të dhënave) dhetestet Lastmile (sa më afër kushteve të përdoruesve, aka stacionet e punës). Lloji i fundit i testeve ka një kosto më të lartë. Pas nënshkrimit të një kontrate njëvjeçare (më pak nuk lejohet), filluam studimin e mjetit. Të pranoj, ishim me të vërtetë të befasuar nga funksionaliteti i tij. Mund të kryhen:teste DNS,
teste Web (me shfletues, GET/POST të thjeshtë, emulim të klientit mobil, etj.),
- kontrollime transaksionesh (për shembull, login),
- teste API,
- Ping, traceroute, NTP, etj.
- S’ka nevojë të përmenden gjithçka. Dhe më e rëndësishmja, çdo test mund të personalizohet mjaft mirë, duke shtuar një sërë header-a dhe parametrash të tjerë. Rezultati përmban një sasi të madhe informacioni, që përshkruan plotësisht testin tuaj. Kur flasim për atë që na intereson më shumë (testet e shfletuesit), rezultati përfshin:
- Connect, Wait, Load, SSL, kohën e DNS,
TTFB, TTLB, Dokumenti i plotë, Koha e Render-it, Ngarkimi i DOM-it,
- Përgjigja (diçka e ngjashme me Time To First Byte), Përgjigja e Façes Web (diçka e ngjashme me Time To Last Byte),
- Çdo percentile, Mesatarja, Koha Medianë
- Etj.
- Etc.
- Etj.
Prandaj, të gjitha këto metrika ndihmojnë shumë për të parë ndryshimet dhe për të kuptuar nëse situata ka përmirësuar. Ne, kryesisht, shikuam Response, Webpage Response, Median, 75 dhe 95 Percentiles.
Një pyetje e rëndësishme, e cila ka qëndruar në ajër që në fillim: a mund t'i besojmë Catchpoint? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Kjo është një problem i madh, sepse duke qenë në Rusi është pothuajse e pamundur të marrësh informacion të saktë për mënyrën se si funksionon një faqe në internet nga Kina. Duke bërë socks-proxy përmes një makine virtuale, rezultati është ngarkimi i faqes në internet që zgjat disa minuta, që është thjesht e papranueshme për testet, kështu që opsioni i vetëm për testimin manual mbetet curl dhe GET të thjeshta nga konsola me matjen e kohës. Kjo ndihmon, sepse ky test pasqyron mirë shpejtësinë e zgjidhjes rrjetërore, dhe nëse ka gjithashtu teste nga shfletuesit, atëherë është shumë më mirë.
Më vonë ne vetë shkuam në Kinë dhe u siguruam që mund t'i besosh Catchpoint, ai pasqyron mjaft saktë treguesit real të shpejtësisë së punës.
Cloudflare China Network
Duke qenë se për domainin kryesor semrush.com ne me sukses përdorim Cloudflare, vendosëm të provojmë menjëherë funksionin e tyre të quajtur . Kjo opsion aktivizohet vetëm për faqet Enterprise me një kërkesë të veçantë dhe për një tarifë të veçantë. Gjithashtu, kjo është e disponueshme vetëm për faqet që kanë licencën përkatëse ICP, në të cilën si ofrues është i shënuar Cloudflare. Pasi të aktivizohet, faqja bëhet e aksesueshme për “CDN kinez” nga Cloudflare - trafiku nga regionet kineze ulet në PoP (Points of Presence) më të afërt CF, dhe më pas përmes rrjeteve të tij ose të ofruesve / partnerëve dorëzohet deri në origin.
Skema e këtij test standi paraqitet më poshtë.
Për ne është një opsion i shkëlqyer. Prandaj, domeni i dytë do të jetë gjithashtu nën CF, gjë që nuk e shton numrin e zgjidhjeve që përdoren në kompaninë, dhe gjithashtu praktikisht nuk e komplikon infrastrukturën.
Ne kemi nisur testet nga shfletuesit, dhe ja çfarë kemi marrë:
Rombët e kuq janë dështimet e testeve. Dështimet poshtë - gabime DNS (rezolve timeout). Dështimet lart - timeout.
Uptime: 86.6
Median: 18s
75 Percentile: 29.3s
95 Percentile: 60s
Medianca, pas heqjes së ngarkesës reCaptcha (shërbimi i Google, i bllokuar në Kinë), ra nga 28 në 18 sekonda. Por përsëri, këto janë tregues katastrofikë, duke marrë parasysh se një test i tillë për semrush.com (nga SHBA) jepte më pak se 10 sekonda për 95% të përdoruesve (nga SHBA) në të njëjtën faqe (statika + dinamika).
Në çdo test mund të hysh e të shikosh Waterfall dhe parametrat e tjerë më të detajuar. Kemi filluar të hetojmë arsyet e gabimeve, dhe nëse për kohët e pritjes gjithçka është më shumë ose më pak e qartë: interneti në Kinë "pashë flakë, pashë ndarje", për këtë arsye shpejtësia e lidhjes dhe ngarkimit të burimeve nga jashtë është e paqëndrueshme dhe e ndryshueshme, gabimet DNS na befasuan shumë. Ne zbuluam se PoP në Cloudflare me të vërtetë ndodhen në Kinë, adresa e faqes zgjidhet në një IP anycast, por serverët DNS përdoren amerikanë, për shkak të së cilës kërkesat DNS detyrohen të kalojnë nëpër kufij, prandaj ndonjëherë ato dështojnë.
Pasi sqaruam këtë çështje me CF, rezultoi se ata nuk kanë serverë DNS të tyre në Kinë, dhe se kur do të kenë - akoma nuk dihet.
Prandaj vendosëm të testojmë vetëm DNS-në e Cloudflare dhe e ndërrova mekanizmin e funksionimit të Cloudflare për faqen tonë në mënyrën "Vetëm DNS". Ky është një mod espetai ku Cloudflare nuk e transferon trafikun përmes vetes, dhe për këtë arsye, nuk ofron mbrojtje DDoS, CDN dhe karakteristika të tjera, dhe funksionon si një server DNS i zakonshëm.
Ky stend është paraqitur në skemën e mëposhtme. Në skemë janë marrë parasysh njohuritë e fituara për atë se serverët DNS të Cloudflare janë pas një firewall-i.
Në Catchpoint filluam teste të thjeshta GET (jo nëpër shfletues), të cilat treguan shumë dështime. Shkaku i tyre ishin të njëjtat gabime DNS.
Filluam të debatojmë këto gabime me anë të dig dhe zbuluam se në kërkesën e parë adresa përcaktohet saktë, por në kërkesën e përsëritur çdo herë merrim SERVFAIL dhe not found. Si ndodhi kjo?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ka adresë 220.170.186.192
Host semrushchina.cn nuk u gjet: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ka adresë 220.170.186.192
Host semrushchina.cn nuk u gjet: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ka adresë 220.170.186.192
Host semrushchina.cn nuk u gjet: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ka adresë 220.170.186.192
Host semrushchina.cn nuk u gjet: 2(SERVFAIL)Kur i drejtohemi DNS-serverëve të Cloudflare direkt, nuk ka të tilla gabime:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Duke përdorur serverin e domainit:
Emri: ray.ns.cloudflare.com.
Adresa: 173.245.59.138#53
Aledhtë:
semrushchina.cn ka adresë 220.170.186.192
semrushchina.cn ka adresë 220.170.186.192
Duke përdorur serverin e domainit:
Emri: ray.ns.cloudflare.com.
Adresa: 173.245.59.138#53
Aledhtë:
semrushchina.cn ka adresë 220.170.186.192
semrushchina.cn ka adresë 220.170.186.192Pra, problemi është në serverin "lokal" DNS ose tek serveri i ofruesit.
Hulumtimi i mëtejshëm tregoi se SERVFAIL ne marrim në zgjidhje AAAA-shënjat.
Doli se në kërkesën ndaj Cloudflare AAAA-shënimi, që nuk është në domain, Cloudflare iu përgjigj A-me një përgjigje që është një gabim dhe mos-përputhje me RFC. Për këtë arsye, rezolva lokal (x.x.x.x) nuk e kishte përzemër dhe ai iu përgjigj SERVFAIL. Në logun më poshtë, kjo sjellje duket qartazi:
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
;; opsionet globale: +cmd
;; Marrë përgjigje:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flamuj: qr rd ra; KËRKESË: 1, PËRGJIGJE: 0, AUTORITET: 0, SHTESË: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flamuj:; udp: 4096
;; SEKSIUNI I KËRKESËS:
;semrushchina.cn. IN AAAA
;; Koha e kërkimit: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; KUR: Tue Aug 14 23:38:50 CST 2018
;; MADHESIA MESAZHI 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.
;; opsionet globale: +cmd
;; Marrë përgjigje:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flamuj: qr aa rd; KËRKESË: 1, PËRGJIGJE: 1, AUTORITET: 0, SHTESË: 1
;; KËSHILLIM: kërkimi i kthimit kërkohet por nuk është në dispozicon
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flamuj:; udp: 512
;; SEKSIUNI I KËRKESËS:
;semrushchina.cn. IN AAAA
;; SEKSIUNI I PËRGJIGJEVE:
semrushchina.cn. 300 IN A 220.170.186.192
;; Koha e kërkimit: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; KUR: Tue Aug 14 23:43:03 CST 2018
;; MADHESIA MESAZHI rcvd: 60
Ne dërguam një raport për gabime te Cloudflare, dhe ata e korigjuan atë pas një kohe. Doli interesante: në këtë moment në Kinë ende nuk ka mbështetje për IPv6, prandaj Cloudflare nuk mund të jepte adresën e tij IPv6 në përgjigje të kërkesës AAAA-përgjigjeve. Si përfundim, gjithçka u zgjidh në atë mënyrë që për Kinën Cloudflare filloi të përgjigjej NODATA për këto kërkesa.
Kështu, gabimet DNS në testet Catchpoint u ulën ndjeshëm, por jo plotësisht. Koha e skadimit gjithashtu nuk u zhduk:
Dhe filluam të kërkojmë një zgjidhje tjetër.
Në pjesën e ardhshme do të tregoj se si testuam cloud-in kinez Alibaba Cloud, si me ndihmën e një «magjie» të vogël Nginx arrijtëm të krijonim shpejt zgjidhje PoC (Proof of Concept), si krijuam zgjidhje Multi-Cloud, njëra nga të cilat përfundimisht ndihmoi shumë në përshpejtimin e shërbimit nga Kina.
Qëndroni lidhur!
Pjesët e ardhshme
Burimi: habr.com
