Sveiki visiem!
Sazinās Ņikita - sistēmas inženieris no uzņēmuma SEMrush. Šodien es jums pastāstīšu par to, kā mēs saskārāmies ar uzdevumu nodrošināt mūsu semrush.com pakalpojuma stabilitāti Ķīnā un ar kādām problēmām saskārāmies tā ieviešanas laikā (ņemot vērā mūsu datu centra atrašanās vietu ASV austrumu krastā).
Šis būs liels stāsts, kas sadalīts vairākos rakstos. Es jums pastāstīšu, kā tas viss notika ar mums: no pilnīgi nefunkcionāla servisa no Ķīnas līdz pakalpojuma veiktspējas rādītājiem tā amerikāņu versijas līmenī. Es apsolu, ka tas būs interesanti un noderīgi. Tātad, ejam.
Ķīnas interneta problēmas
Par to ir dzirdējis pat vistālāk no tīkla administrēšanas specifikas Lielais Ķīnas ugunsmūris. Oho, izklausās forši, vai ne? Bet kas tas ir un kā tas patiesībā darbojas, ir diezgan sarežģīts jautājums. Internetā var atrast daudz tam veltītu rakstu, taču no tehniskā viedokļa šī ugunsmūra struktūra nekur nav aprakstīta. Kas tomēr nepārsteidz. Uzreiz atzīšos, ka pēc gada darba rezultātiem nevarēšu precīzi pateikt, kā tas darbojas, bet varu pastāstīt par saviem komentāriem un praktiskiem secinājumiem. Un mēs sāksim ar baumām par šo ugunsmūri.
Par šo ugunsmūri klīst daudzas baumas. Apkoposim galvenos un interesantākos no tiem vienā sarakstā:
- Google, Facebook, Twitter un citi līdzīgi pakalpojumi ir bloķēti un nedarbojas Ķīnā.
- Jebkura satiksme, kas virzās ĀRPUS Ķīnas un UZ Ķīnu, tiek parsēta un ierobežota, izmantojot mašīnmācīšanos (aizdomīgas satiksmes gadījumā), kas ievērojami palēnina to (satiksmi), kas šķērso robežu.
- Ķīnas izlūkošanas aģentūras uzlauzīs jebkuru šifrēto trafiku, kas iet caur viņu ugunsmūri.
- VPN tuneļi, IPSEC tuneļi ir nestabili, avarē un tiek pastāvīgi bloķēti.
- Jo vienkāršāka ir šifrēšana, jo vienkāršāka ir ieejas frāze, ko izmanto trafika autentificēšanai/šifrēšanai, jo ātrāk tā tiek cauri Ķīnas ugunsmūrim.
Lūk, ko mēs uzzinājām par šīm baumām:
- Google, Facebook, Twitter un citi līdzīgi pakalpojumi patiešām ir bloķēti (jūsu KO), taču daudzi tehniskie Google domēni, piemēram, nav aizliegti un darbojas (tas pats gstatic.com). No tā izriet secinājums: jums nevajadzētu vieglprātīgi izgriezt visus Google un citus resursus, kas šķiet bloķēti.
- Jebkura satiksme, kas šķērso robežu, patiešām ievērojami kavē laiku. Apskatiet divus rezultātus. Viena vietne, viena lapa, vienkārši IEGŪT cirtot'om. Pirmais mērījums bija no pašas Ķīnas (skaisto Šenženas pilsētu). Otrais tika mērīts no Honkongas ārpuses (tai ir suverenitāte, un starp to un pasauli nav ugunsmūra). Attālums starp pilsētām taisnā līnijā ir aptuveni 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/sŅemiet time_connect. Un kopumā jūs redzat rezultātu: ugunsmūris pievieno 4 papildu sekundes, kas ir ārkārtīgi garš.
- VPN un IPSEC tuneļi bieži neizdodas. Par to es runāšu nedaudz vēlāk un sīkāk. VPN serveri, kurus izmanto lietotāji, laika gaitā tiek bloķēti (parasti vienas dienas laikā pēc lietošanas sākuma).
- No Ķīnā dzīvojošajiem saņemts viedoklis, ka, jo vienkāršāka ir trafika šifrēšana, jo ātrāk tā iziet cauri robežai, jo ir viegli saprast, ka nekā nelikumīga tajā nav. Un tādā pašā veidā “tīrā” satiksme saņem lielāku joslas platumu un caurbraukšanas ātrumu, savukārt “netīrā” satiksme, kurā neko nevar saprast, saņem, gluži pretēji, lēnāku caurbraukšanu. Piemēram, es izmantošu curl to ifconfig.co izmantojot HTTPS un HTTP protokolu.
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 sekunžu starpība kopējam lejupielādes laikam 13 baiti. Turklāt, veicot šādu pārbaudi vairākas reizes, jūs varat pamanīt, ka GET on HTTP katru reizi tiek pabeigts kopumā vienā un tajā pašā laikā, savukārt HTTPS vietnē vietne dažreiz reaģē 3, 5, 10 un pat 17 sekundēs. Dažreiz rodas SSL kļūdas:
Unknown SSL protocol error in connection to ifconfig.co:443.
Tātad, kas mums ir:
- Ķīnas ugunsmūra radītās problēmas ir aprakstītas iepriekš.
- Pings uz ārējiem resursiem un iekšējiem tuneļiem periodiski pazūd.
- Latentums starp diviem punktiem pastāvīgi mainās, un bieži vien tas ir vienkārši neparedzams. Savienojot dažādas pilsētas/reģionus, jūs sagaidāt, ka, pamatojoties uz reģionu ģeogrāfisko novietojumu, aizkavēšanās būs mazāka, taču jūs iegūstat tieši pretēju situāciju.
- Internets un saziņas kanāli ir ātri vai lēni. Ir neliela atkarība no diennakts laika un nedēļas dienas, bet ne vienmēr.
- DNS pieprasījumi ārpasaulei no Ķīnas dažkārt pārsniedz atļauto taimautu.
Parādītā aina ir vienkārši "izcila".
Datu centrs, kā jau teicu, atrodas Amerikas Savienoto Valstu austrumos, un viss SEMrush sastāv no desmitiem savstarpēji saistītu produktu, aizmugursistēmu, frontendu, datu bāzu, un tas viss ir pieejams līdzstrāvas tīklā un mākoņos. Mums kā sistēmas administratoru komandai tika dots uzdevums ātri ar nelielu piepūli sākt strādāt Ķīnā.
Bija jāatbild uz svarīgu jautājumu: vai ir iespējams iztikt ar nelieliem izdevumiem un atrisināt visas ar Ķīnas internetu un ugunsmūri saistītās problēmas tīkla/mākoņa/servera līmenī?
Sākām ar saņemšanu .
ICP licence
Lai varētu mitināt savu pakalpojumu Ķīnā (kontinentālā Ķīnā) un veikt testus, vispirms ir jāiegūst ICP licence šim domēnam.
Ja jūsu vietnes lietotāju datplūsma tiek pārtraukta kontinentālajā Ķīnā un jūsu domēnam nav ICP licences, jūsu datplūsma tiks bloķēta ISP/hostinga pusē. Interesanti, ka ICP licence ietver noteiktu pakalpojumu sniedzēju, vai tas būtu Cloudflare vai Alibaba Cloud. Tāpēc, ja saņēmāt ICP licenci pakalpojumam Cloudflare un mitinājāt ar viņiem savu vietni, jūs nevarēsit “nevainojami” pāriet uz Alibaba Cloud. Šai licencei būs jāpievieno vēl viens hostings.
Saņemot ICP licenci domēnam, varējām izdomāt un realizēt konkrētas tehniskas idejas un risinājumus.
Testēšanas risinājumi
Taču, pirms tieši veidojat inscenēšanas opcijas, griežat kloķus, optimizējat vietnes veiktspēju un ātrumu, jums ir jāizvēlas rīks tās pārbaudei, lai redzētu, kura no mūsu darbībām uzlabo vai, gluži pretēji, pasliktina vietnes veiktspēju.
Mūsu testēšanas rīkam bija jāatbilst divām galvenajām prasībām:
- tai vajadzētu būt iespējai veikt testus no Ķīnas,
- tai ir jābūt pārlūkprogrammas testiem.
Tātad mēs atradām ! Viņiem ir lielisks testēšanas vietu pārklājums visā pasaulē. Ķīnā, izmantojot šo rīku, testus var veikt arī 100500 XNUMX provincēs. Katram ir vairāki dažādi pakalpojumu sniedzēji + iespēja to darīt Mugurkauls-testi (kaut kas līdzīgs virtuālajai mašīnai datu centrā) un Lastmile-testi (pēc iespējas tuvāk lietotāja apstākļiem, aka darbstacija). Pēdējā veida pārbaudes ir dārgākas.
Noslēdzot gada līgumu (mazāk par to nav iespējams), sākām pētīt instrumentu. Atklāti sakot, mēs bijām patīkami pārsteigti par tā funkcionalitāti. Jūs varat skriet:
- DNS testi,
- Tīmekļa testi (pārlūkprogrammas testi, vienkārša GET/POST, mobilā klienta emulācija utt.),
- Darījumu pārbaudes (piemēram, pieteikšanās),
- API testi,
- Ping, traceroute, NTP utt.
Nevar visu uzskaitīt. Un pats galvenais, katru testu var diezgan labi pielāgot, pievienojot virkni galvenes un citus parametrus. Rezultāts ir milzīgs informācijas apjoms, kas pilnībā apraksta jūsu pārbaudi. Ja mēs runājam par mums interesantākajām lietām (pārlūkprogrammu testi), rezultāts ietver:
- Savienojuma izveide, gaidīšana, ielāde, SSL, DNS laiks,
- TTFB, TTLB, dokuments pabeigts, renderēšanas laiks, DOM ielāde,
- Response (kaut kas tuvu Time To First Byte), Webpage Response (kaut kas tuvu Time To Last Byte),
- Jebkura procentile, vidējais, vidējais laiks
- utt.
Attiecīgi visi šie rādītāji ir lieliski piemēroti, lai redzētu izmaiņas un saprastu, vai lietas ir uzlabojušās. Mēs galvenokārt skatījāmies Atbilde, tīmekļa lapas atbilde, mediāna, 75 un 95 procentiles.
Svarīgs jautājums, kas bija gaisā jau no paša sākuma: Vai varat uzticēties Catchpoint?? Vai šis rīks atspoguļo reālo vietņu ielādes ātrumu Ķīnā no dažādām pilsētām, vai arī tas ir tikai kāds vakuuma tests, kam nav nekāda sakara ar reālo lietotāja pieredzi?
Tā ir liela problēma, jo, atrodoties Krievijā, ir gandrīz neiespējami droši uzzināt, kā darbojas vietne no Ķīnas. Veicot socks-proxy caur virtuālo mašīnu, galarezultāts ir tāds, ka vietne tiek ielādēta pāris minūšu laikā, kas ir vienkārši nepieņemami testiem, tāpēc vienīgā iespēja manuālai testēšanai ir locīšana un vienkārša GET no konsoles ar taimeri. . Tas palīdz, jo šis tests labi atspoguļo tīkla risinājuma ātrumu, un, ja ir arī pārlūkprogrammas testi, tas ir ļoti labs.
Vēlāk mēs paši devāmies uz Ķīnu un par to pārliecinājāmies Varat uzticēties Catchpoint; tas diezgan precīzi atspoguļo reālos darbības rādītājus.
Cloudflare Ķīnas tīkls
Tā kā mēs veiksmīgi izmantojam Cloudflare galvenajam domēnam semrush.com, mēs nolēmām nekavējoties izmēģināt to funkciju ar nosaukumu . Šī opcija ir iespējota tikai uzņēmuma vietnēm pēc atsevišķa pieprasījuma un par papildu samaksu. Tas ir pieejams arī tikai vietnēm, kurām ir atbilstoša ICP licence, kurā kā nodrošinātājs ir norādīts Cloudflare. Pēc tā iespējošanas vietnei kļūst pieejams “ķīniešu CDN” no Cloudflare — datplūsma no Ķīnas reģioniem nonāk tuvākajā PoP (klātbūtnes punktu) CF, un pēc tam caur tā tīkliem vai pakalpojumu sniedzēju/partneru tīkliem tā tiek piegādāta uz izcelsmi. .
Šī testa stenda diagramma ir parādīta zemāk.
Mums šī ir lieliska iespēja. Izrādās, ka arī otrs domēns būs CF, kas gan nepapildina uzņēmumā izmantoto risinājumu skaitu, kā arī praktiski neapgrūtina infrastruktūru.
Mēs veicām pārlūkprogrammas testus, un notika šādi:
Sarkanie dimanti ir pārbaudes neveiksmes. Tālāk norādītie faili ir DNS kļūdas (atrisināšanas taimauts). Neveiksmes augšpusē ir taimauts.
Darbības laiks: 86.6
Vidējais: 18s
75 procentile: 29.3 s
95 procentile: 60 s
Vidējā, pēc iekraušanas noņemta reCaptcha (Google pakalpojums Ķīnā bloķēts) samazinājās no 28 līdz 18 sekundēm. Bet tie joprojām ir briesmīgi rezultāti, ņemot vērā, ka tas pats semrush.com tests (no ASV) 10% lietotāju (no ASV) tajā pašā lapā (statiskā + dinamiskā) deva mazāk nekā 95 sekundes.
Jūs varat iedziļināties katrā testā un apskatīt Ūdenskritums un citi detalizētāki parametri. Mēs sākām pētīt kļūdu iemeslus, un, ja noildzes gadījumā viss ir vairāk vai mazāk skaidrs: internets Ķīnā “kustas iekšā un ārā”, tāpēc savienojuma ātrums un resursu ielāde no ārvalstīm ir nestabila un nevienmērīga, tad DNS kļūdas mūs ļoti pārsteidza. Mēs to atradām Po Cloudflare faktiski atrodas Ķīnā, vietnes adrese ir viena anycast IP, bet DNS serveri ir amerikāņu, tāpēc DNS pieprasījumi ir spiesti iet pāri robežai, tāpēc dažreiz tie neizdodas.
Noskaidrojot šo jautājumu ar CF, izrādījās, ka Viņiem Ķīnā nav savu DNS serveru, un kad tas būs, vēl nav zināms.
Tāpēc mēs nolēmām pārbaudīt tikai Cloudflare DNS un mainījām mūsu vietnes Cloudflare darbības mehānismu uz “Tikai DNS" Šis ir režīms, kad Cloudflare neveic starpniekservera trafiku caur sevi, kas nozīmē, ka tas nenodrošina DDoS aizsardzību, CDN un citas funkcijas un darbojas parasta DNS servera režīmā.
Šis stends shematiski parādīts nākamajā attēlā. Attēlā ir ņemtas vērā jaunās zināšanas, ka Cloudflare DNS serveri atrodas aiz ugunsmūra.
Catchpoint mēs veicām vienkāršus GET testus (nevis pārlūkprogrammas testus), kas parādīja daudz kļūdu. Tos izraisīja tās pašas DNS kļūdas.
Mēs sākām šo kļūdu atkļūdošanu, izmantojot rakt un konstatēja, ka pēc pirmā pieprasījuma adrese ir noteikta pareizi, un pēc atkārtota pieprasījuma mēs saņemam katru reizi SERVFAIL и nav atrasts. Kāpēc tas notiek pēkšņi?
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)Veicot tiešu vaicājumu Cloudflare NS serveros, šādu kļūdu nav:
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.192Tas nozīmē, ka problēma ir “lokālā” DNS servera vai pakalpojumu sniedzēja servera pusē.
Turpmākā izmeklēšana atklāja, ka SERVFAIL mēs apņemamies AAAA- ieraksti.
Izrādījās, ka, pieprasot no Cloudflare AAAA-ieraksts, kas domēnā neeksistē, atbildēja Cloudflare А-ieraksts, kas ir kļūda un neatbilstība RFC. Kāpēc vietējais atrisinātājs (xxxx) Man tas nepatika, un viņš atbildēja SERVFAIL. Šī uzvedība ir skaidri redzama tālāk esošajā žurnālā:
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
Mēs iesniedzām kļūdu ziņojumu uzņēmumam Cloudflare, un pēc kāda laika viņi to izlaboja. Tas izrādījās interesanti: šobrīd Ķīnā joprojām nav IPv6 atbalsta, tāpēc Cloudflare nevarēja izsniegt savu IPv6 adresi, atbildot uz pieprasījumu. AAAA- ieraksti. Galu galā viss tika atrisināts tā, ka Cloudflare sāka atbildēt par Ķīnu NAV DATU šādiem pieprasījumiem.
Tādējādi DNS kļūdas Catchpoint testos strauji, bet ne pilnībā samazinājās. Noildzes joprojām ir šeit:
Un mēs sākām meklēt citu risinājumu.
Nākamajā daļā es jums pastāstīšu, kā mēs pārbaudījām Ķīnas mākoni Alibaba Cloud, kā ar nelielas Nginx “maģijas” palīdzību varējām ātri izveidot PoC (Proof of Concept) risinājumus, kā radījām Multi-Cloud risinājumus, no kuriem viens galu galā ļoti palīdzēja servisa darbu paātrināt. no Ķīnas.
Sekojiet līdzi!
Nākamās daļas
Avots: www.habr.com
