ProHoster > Blogs > Administrācija > Kā mēs izlauzāmies cauri Lielajam Ķīnas ugunsmūrim (3. daļa)

Kā mēs izlauzāmies cauri Lielajam Ķīnas ugunsmūrim (3. daļa)

Hi!
Visiem labajiem stāstiem pienāk beigas. Un mÅ«su stāsts par to, kā mēs radÄ«jām risinājumu, lai ātri pārvarētu Ķīnas ugunsmÅ«ri, nav izņēmums. Tāpēc es steidzos dalÄ«ties ar jums pēdējā, beigu daļa par Å”o tēmu.

IepriekŔējā daļā mēs runājām par daudziem testu stendiem, kurus mēs izdomājām un kādus rezultātus tie deva. Un mēs izlēmām, ko bÅ«tu jauki pievienot CDN! viskozitātei mÅ«su shēmā.

Es jums pastāstÄ«Å”u, kā mēs pārbaudÄ«jām Alibaba Cloud CDN, Tencent Cloud CDN un Akamai, un ar ko mēs nonācām. Un, protams, apkoposim.

Kā mēs izlauzāmies cauri Lielajam Ķīnas ugunsmūrim (3. daļa)

Alibaba Cloud CDN

Mēs esam mitināti pakalpojumā Alibaba Cloud un no tiem izmantojam IPSEC un CEN. Būtu loģiski vispirms izmēģināt viņu risinājumus.

Alibaba Cloud ir divu veidu produkti, kas mums var bÅ«t piemēroti: CDN Šø DCDN. Pirmā iespēja ir klasisks CDN noteiktam domēnam (apakÅ”domēnam). Otrā iespēja nozÄ«mē Dinamiskais marÅ”ruts CDN (es to saucu par dinamisku CDN), to var iespējot pilnas vietnes režīmā (aizstājējzÄ«mju domēniem), tas arÄ« saglabā statisko saturu keÅ”atmiņā un paātrina dinamisko saturu, tas ir, lapas dinamika tiks ielādēta arÄ« caur pakalpojumu sniedzēja ātri tÄ«kli. Tas mums ir svarÄ«gi, jo pamatā mÅ«su vietne ir dinamiska, tajā tiek izmantoti daudzi apakÅ”domēni, un ērtāk ir vienreiz iestatÄ«t CDN ā€œzvaigznÄ«teiā€ - *.semrushchina.cn.

Mēs jau bijām redzējuÅ”i Å”o produktu mÅ«su Ķīnas projekta agrākajos posmos, taču tad tas vēl nedarbojās, un izstrādātāji solÄ«ja, ka produkts drÄ«zumā kļūs pieejams visiem klientiem. Un viņŔ to darÄ«ja.

DCDN varat:

  • konfigurējiet SSL pārtraukÅ”anu ar savu sertifikātu,
  • ļauj paātrināt dinamisku saturu,
  • elastÄ«gi konfigurēt statisko failu keÅ”atmiņu,
  • iztÄ«rÄ«t keÅ”atmiņu,
  • pārsÅ«tÄ«t tÄ«mekļa ligzdas,
  • iespējot saspieÅ”anu un pat HTML Beautifier.

Kopumā viss ir tāpat kā ar pieauguÅ”ajiem un lieliem CDN pakalpojumu sniedzējiem.

Kad ir norādÄ«ts Origin (vieta, kur nonāks CDN malas serveri), atliek tikai izveidot zvaigznÄ«tei CNAME, atsaucoties all.semrushchina.cn.w.kunluncan.com (Å”is CNAME tika saņemts Alibaba Cloud konsolē), un CDN darbosies.

Pamatojoties uz testa rezultātiem, Å”is CDN mums ļoti palÄ«dzēja. Statistika ir parādÄ«ta zemāk.

Å Ä·Ä«dums
Uptime
Median
75 procentile
95 procentile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

Ali CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s

Tie ir ļoti labi rezultāti, it Ä«paÅ”i, ja salÄ«dzina tos ar tiem skaitļiem, kas bija sākumā. Taču mēs zinājām, ka mÅ«su vietnes www.semrush.com amerikāņu versijas pārlÅ«kprogrammas tests no ASV tiek izpildÄ«ts vidēji 8.3 s (ļoti aptuvena vērtÄ«ba). Ir ko uzlabot. Turklāt bija arÄ« CDN pakalpojumu sniedzēji, kurus bija interesanti pārbaudÄ«t.

Tāpēc mēs vienmērīgi pārietam uz citu gigantu Ķīnas tirgū - Tencent.

Tencent mākonis

Tencent tikai izstrādā savu mākoni ā€“ to var redzēt no neliela produktu skaita. Izmantojot to, mēs vēlējāmies pārbaudÄ«t ne tikai viņu CDN, bet arÄ« visu tÄ«kla infrastruktÅ«ru:

  • vai viņiem ir kaut kas lÄ«dzÄ«gs CEN?
  • Kā viņiem darbojas IPSEC? Vai tas ir ātri, kāds ir darbÄ«bas laiks?
  • vai viņiem ir Anycast?

Kā mēs izlauzāmies cauri Lielajam Ķīnas ugunsmūrim (3. daļa)

Apskatīsim Ŕos jautājumus atseviŔķi.

Analogais CEN

Tencent ir produkts Cloud Connect tÄ«kls (CCN), ļaujot savienot VPC no dažādiem reÄ£ioniem, tostarp reÄ£ioniem Ķīnā un ārpus tās. Produktam tagad ir iekŔējā beta versija, un jums ir jāizveido biļete, kurā tiek lÅ«gts izveidot savienojumu ar to. No atbalsta mēs uzzinājām, ka globālie konti (mēs nerunājam par Ķīnas pilsoņiem vai juridiskām personām) nevar piedalÄ«ties beta testÄ“Å”anas programmā un kopumā savienot Ķīnas reÄ£ionu ar reÄ£ionu ārpusē. 1:0 Ali Cloud labā

IPSEC

Tencentas dienvidu reÄ£ions ir Guandžou. Mēs samontējām tuneli un savienojām to ar Honkongas reÄ£ionu GCP (tad Å”is reÄ£ions jau bija pieejams). Tajā paŔā laikā tika pacelts arÄ« otrs tunelis Ali Cloud no Å eņdžeņas uz Honkongu. IzrādÄ«jās, ka caur Tencent tÄ«klu latentums uz Honkongu parasti ir labāks (10 ms) nekā no Å enženas uz Honkongu lÄ«dz Ali (120 ms - kas?). Bet tas nekādā veidā nepaātrināja vietnes darbu, kuras mērÄ·is bija strādāt caur Tencent un Å”o tuneli, kas pats par sevi bija pārsteidzoÅ”s fakts un vēlreiz pierādÄ«ja sekojoÅ”o: latentums - Ķīnai tas nav rādÄ«tājs, kas patieŔām ir vērts. pievērÅ”ot uzmanÄ«bu, izstrādājot risinājumu Ķīnas ugunsmÅ«ra ŔķērsoÅ”anai.

Anycast interneta paātrinājums

Vēl viens produkts, kas ļauj strādāt, izmantojot Anycast IP, ir AAI. Bet tas nav pieejams arÄ« globālajiem kontiem, tāpēc es jums par to nestāstÄ«Å”u, taču var bÅ«t noderÄ«gi zināt, ka Ŕāds produkts pastāv.

Bet CDN tests parādīja diezgan interesantus rezultātus. Tencent CDN nevar iespējot visā vietnē, tikai noteiktos domēnos. Mēs izveidojām domēnus un nosūtījām uz tiem trafiku:

Kā mēs izlauzāmies cauri Lielajam Ķīnas ugunsmūrim (3. daļa)

IzrādÄ«jās, ka Å”im CDN ir Ŕāda funkcija: Pārrobežu satiksmes optimizācija. Å ai funkcijai ir jāsamazina izmaksas, kad satiksme Ŕķērso Ķīnas ugunsmÅ«ri. Kā izcelÅ”anās Tika norādÄ«ta Google GLB (GLB anycast) IP adrese. Tādējādi mēs vēlējāmies vienkārÅ”ot projekta arhitektÅ«ru.

Rezultāti bija ļoti labi ā€“ Ali Cloud CDN lÄ«menÄ« un vietām pat labāki. Tas ir pārsteidzoÅ”i, jo, ja testi bÅ«s veiksmÄ«gi, var pamest ievērojamu daļu infrastruktÅ«ras, tuneļus, CEN, virtuālās maŔīnas utt.

Mēs ilgi nepriecājāmies, jo atklājās problēma: interneta pakalpojumu sniedzēja China Mobile testi Catchpoint neizdevās. No jebkuras vietas mēs saņēmām taimautu, izmantojot Tencent's CDN. Sarakste ar tehnisko atbalstu ne pie kā nenoveda. Mēs mēģinājām atrisināt Å”o problēmu apmēram dienu, bet nekas nedarbojās.

Es tajā brÄ«dÄ« atrados Ķīnā, taču nevarēju atrast publisko Wi-Fi Ŕī pakalpojumu sniedzēja tÄ«klā, lai personÄ«gi pārbaudÄ«tu problēmu. Citādi viss izskatÄ«jās ātri un labi.
Tomēr, tā kā China Mobile ir viens no trim lielākajiem operatoriem, mēs bijām spiesti atgriezt trafiku uz Ali CDN.
Bet kopumā tas bija diezgan interesants risinājums, kas ir pelnÄ«jis ilgāku Ŕīs problēmas pārbaudi un problēmu novērÅ”anu.

Akamai

Pēdējais mÅ«su pārbaudÄ«tais CDN nodroÅ”inātājs bija Akamai. Å is ir milzÄ«gs pakalpojumu sniedzējs, kura tÄ«kls atrodas Ķīnā. Protams, mēs nevarējām tikt tam garām.

Kā mēs izlauzāmies cauri Lielajam Ķīnas ugunsmūrim (3. daļa)

Jau paŔā sākumā vienojāmies ar Akamai par izmēģinājuma periodu, lai varētu pārslēgt domēnu un redzēt, kā tas darbosies viņu tÄ«klā. Visu testu rezultātus es aprakstÄ«Å”u formā ā€œKas man patikaā€ un ā€œKas man nepatikaā€, kā arÄ« norādÄ«Å”u testa rezultātus.

Kas man patika:

  • PuiÅ”i no Akamai bija ļoti izpalÄ«dzÄ«gi visos jautājumos un pavadÄ«ja mÅ«s visos testÄ“Å”anas posmos. Mēs nemitÄ«gi centāmies kaut ko uzlabot savā pusē. Viņi sniedza labus tehniskos padomus.
  • Akamai ir aptuveni par 10ā€“15% lēnāks nekā mÅ«su risinājums, izmantojot Ali Cloud CDN. IespaidÄ«gi ir tas, ka programmā Origin for Akamai mēs norādÄ«jām GLB IP adresi, kas nozÄ«mē, ka trafiks nenotika caur mÅ«su risinājumu (iespējams, mēs varētu pamest daļu infrastruktÅ«ras). Bet tomēr testa rezultāti parādÄ«ja, ka Å”is risinājums ir sliktāks par mÅ«su paÅ”reizējo versiju (salÄ«dzinoÅ”ie rezultāti zemāk).
  • PārbaudÄ«ts gan Origin GLB, gan Origin Ķīnā. Abas iespējas ir aptuveni vienādas.
  • Ir DroÅ”s marÅ”ruts (automātiskā marÅ”rutÄ“Å”anas optimizācija). Varat mitināt testa objektu vietnē Origin, un Akamai Edge serveri mēģinās to uztvert (parastais GET). Å iem pieprasÄ«jumiem tiek mērÄ«ts ātrums un citi rādÄ«tāji, pamatojoties uz kuriem Akamai tÄ«kls optimizē marÅ”rutus, lai mÅ«su vietnes satiksme bÅ«tu ātrāka, un bija skaidrs, ka Ŕīs funkcijas iespējoÅ”ana patieŔām spēcÄ«gi ietekmēja vietnes ātrumu.
  • Konfigurācijas versijas izveide tÄ«mekļa saskarnē ir lieliska. Varat veikt SalÄ«dzināt versijas, apskatÄ«t atŔķir. SkatÄ«t iepriekŔējās versijas.
  • Jaunu versiju vispirms varat izlaist tikai Akamai Staging tÄ«klā ā€” tajā paŔā tÄ«klā, kas tiek ražots, tikai tas neietekmēs reālos lietotājus. Lai veiktu Å”o testu, jums ir jāmānÄ«ja DNS ieraksti vietējā datorā.
  • Ä»oti ātrs lejupielādes ātrums, izmantojot tÄ«klu, lieliem statiskiem failiem un, acÄ«mredzot, visiem citiem failiem. Fails no ā€œaukstāsā€ keÅ”atmiņas tiek izgÅ«ts daudzas reizes ātrāk nekā tas pats fails no Ali CDN ā€œaukstāsā€ keÅ”atmiņas. No ā€œkarstāsā€ keÅ”atmiņas ātrums jau ir tāds pats, plus vai mÄ«nus.

Ali CDN tests:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0   513k      0 --:--:--  0:00:11 --:--:--  526k
time_namelookup:  0.004286
time_connect:  0.030107
time_appconnect:  0.117525
time_pretransfer:  0.117606
time_redirect:  0.000000
time_starttransfer:  0.840348
----------
time_total:  11.208119
----------
size_download:  5895467 Bytes
speed_download:  525999.000B/s

Akamai tests:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0  1824k      0 --:--:--  0:00:03 --:--:-- 1825k
time_namelookup:  0.509005
time_connect:  0.528261
time_appconnect:  0.577235
time_pretransfer:  0.577324
time_redirect:  0.000000
time_starttransfer:  1.327013
----------
time_total:  3.154850
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

Mēs pamanÄ«jām, ka situācija iepriekÅ” minētajā piemērā ir atkarÄ«ga no dažādiem faktoriem. Rakstot Å”o punktu, es vēlreiz izpildÄ«ju testu. Rezultāti abām platformām bija aptuveni vienādi. Tas liecina, ka internets Ķīnā, pat lielajiem operatoriem un mākoņpakalpojumu sniedzējiem, laiku pa laikam darbojas atŔķirÄ«gi.

IepriekŔējam punktam pievienoÅ”u lielu plusu Akamai: ja Ali rāda lÄ«dzÄ«gus augstas veiktspējas un ļoti zemas veiktspējas mirkļus (tas attiecas uz Ali CDN, Ali CEN un Ali IPSEC), tad Akamai katru reizi, neatkarÄ«gi no kā es pārbaudu viņu tÄ«klu, viss darbojas stabili.
Akamai ir plaÅ”s pārklājums Ķīnā, un tas darbojas caur daudziem pakalpojumu sniedzējiem.

Kas man nepatika:

  • Man nepatÄ«k tÄ«mekļa saskarne un veids, kā tas darbojas ā€” tas ir tik slikts. Bet bÅ«tÄ«bā pie tā pierod (iespējams).
  • Testa rezultāti ir sliktāki nekā mÅ«su vietnē.
  • Pārbaužu laikā ir vairāk kļūdu nekā mÅ«su vietnē (darbspējas laiks zemāk).
  • Mums Ķīnā nav savu DNS serveru. Tāpēc pārbaudēs ir daudz kļūdu DNS atrisināŔanas noildzes dēļ.
  • Viņi nenorāda savus IP diapazonus -> nav iespējams reÄ£istrēt pareizos set_real_ip_from mÅ«su serveros.

Metrika (aptuveni 3626 palaiÅ”anas reizes; visa metrika, izņemot darbspējas laiku, ms; statistika par vienu laika periodu):

CDN nodroŔinātājs
Median
75%
95%
Atbilde
Tīmekļa lapas atbilde
Uptime
DNS
Meklēt speciālistu
Pagaidiet
Slodze
SSL

AliCDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

Sadalījums pēc procentiles (ms):

Procentils
Akamai
AliCDN

10
7,092
6,942

20
7,775
7,583

30
8,446
8,092

40
9,146
8,596

50
9,783
9,195

60
10,497
9,770

70
11,371
10,383

80
12,670
11,255

90
15,882
13,165

100
91,592
91,596

Secinājums ir Ŕāds: Akamai iespēja ir dzÄ«votspējÄ«ga, taču nenodroÅ”ina tādu paÅ”u stabilitāti un ātrumu kā mÅ«su paÅ”u risinājums kopā ar Ali CDN.

Mazas piezīmes

Daži momenti nebija iekļauti stāstā, bet es arī par tiem gribētu uzrakstīt.

Pekina + Tokija un Honkonga

Kā jau teicu iepriekÅ”, mēs pārbaudÄ«jām IPSEC tuneli uz Honkongu (HK). Bet mēs arÄ« pārbaudÄ«jām CEN uz HK. Tas maksā nedaudz mazāk, un es domāju, kā tas darbosies starp pilsētām ar attālumu ~ 100 km. Interesanti izrādÄ«jās, ka latentums starp Ŕīm pilsētām ir par 100 ms lielāks nekā mÅ«su sākotnējā versijā (uz Taivānu). Ātrums, stabilitāte arÄ« Taivānai bija labāka. Rezultātā mēs atstājām HK kā rezerves IPSEC reÄ£ionu.

Turklāt mēs mēģinājām instalēt Ŕādu instalāciju:

  • klientu izbeigÅ”ana Pekinā,
  • IPSEC un CEN uz Tokiju,
  • Ali CDN kā izcelsme tika norādÄ«ts serveris Pekinā.

Å Ä« shēma nebija tik stabila, lai gan ātruma ziņā tā kopumā nebija zemāka par mÅ«su risinājumu. AttiecÄ«bā uz tuneli esmu redzējis periodiskus kritumus pat CEN, kam vajadzēja bÅ«t stabilam. Tāpēc atgriezāmies pie vecās shēmas un Å”o iestudējumu demontējām.

Tālāk ir sniegta statistika par latentumu starp dažādiem reģioniem dažādiem kanāliem. Varbūt kādam tas interesēs.

IPsec
Ali cn-peijing <ā€”> GCP asia-northeast1 ā€” 193ms
Ali cn-Shenzhen <ā€”> GCP asia-east2 ā€” 91 ms
Ali cn-shenzhen <ā€”> GCP us-east4 ā€” 200 ms

CEN
Ali cn-peijing <ā€”> Ali ap-northeast-1 ā€” 54ms (!)
Ali cn-shenzhen <ā€”> Ali cn-hongkong ā€” 6 ms (!)
Ali cn-shenzhen <ā€”> Ali us-east1 ā€” 216ms

Vispārīga informācija par internetu Ķīnā

Kā papildinājums paŔā sākumā aprakstÄ«tajām problēmām ar internetu raksta pirmajā daļā.

  • Internets Ķīnā ir diezgan ātrs iekŔā.
    • Secinājums izdarÄ«ts, pamatojoties uz publisko Wi-Fi tÄ«klu testÄ“Å”anu dažādās vietās, kur Å”os tÄ«klus izmanto liels skaits cilvēku.
    • Lejupielādes un augÅ”upielādes ātrums serveros Ķīnā bija attiecÄ«gi aptuveni 20 Mbit/s un 5-10 Mbit/s.
    • Ātrums uz serveriem ārpus Ķīnas ir vienkārÅ”i niecÄ«gs, mazāks par 1 Mbit/s.
  • Internets Ķīnā nav ļoti stabils.
    • Dažreiz vietnes var atvērt ātri, dažreiz lēni (vienā un tajā paŔā laikā dažādās dienās), ja konfigurācija nemainās. Mēs to novērojām, izmantojot semrushchina.cn piemēru. To var attiecināt uz Ali CDN, kas arÄ« darbojas Ŕādi un citādi atkarÄ«bā no diennakts laika, zvaigžņu stāvokļa utt.
  • Mobilais internets ir gandrÄ«z visur 4G vai 4G+. NoÄ·er to metro, liftos ā€“ Ä«si sakot, visur.
  • Tas ir mÄ«ts, ka Ä·Ä«nieÅ”u lietotāji uzticas tikai domēniem .cn zonā. Mēs to uzzinājām tieÅ”i no lietotājiem.
    • JÅ«s varat redzēt, kā http://baidu.cn novirzÄ«t uz www.baidu.com (arÄ« kontinentālajā Ķīnā).
  • Daudzi resursi patieŔām ir bloķēti. PrimitÄ«vs: google.com, Facebook, Twitter. Bet daudzi Google resursi darbojas (protams, ne visos Wi-Fi un VPN netiek izmantots (arÄ« marÅ”rutētāja pusē, tas noteikti).
  • Darbojas arÄ« daudzi bloķēto korporāciju ā€œtehniskieā€ domēni. Tas nozÄ«mē, ka nevajadzētu vienmēr neapdomÄ«gi izgriezt visus Google un citus Ŕķietami bloķētos resursus. Jums ir jāmeklē kāds aizliegto domēnu saraksts.
  • Viņiem ir tikai trÄ«s galvenie interneta operatori: China Unicom, China Telecom, China Mobile. Ir vēl mazāki, taču to tirgus daļa ir niecÄ«ga

Bonuss: gala risinājuma diagramma

Kā mēs izlauzāmies cauri Lielajam Ķīnas ugunsmūrim (3. daļa)

Kopsavilkums

Ir pagājis gads kopÅ” projekta sākuma. Mēs sākām ar faktu, ka mÅ«su vietne parasti atteicās normāli strādāt no Ķīnas, un vienkārÅ”i GET curl aizņēma 5.5 sekundes.

Pēc tam ar Å”iem indikatoriem pirmajā risinājumā (Cloudflare):

Å Ä·Ä«dums
Uptime
Median
75 procentile
95 procentile

Cloudflare
86.6
18s
30s
60s

Galu galā mēs sasniedzām Ŕādus rezultātus (statistika par pēdējo mēnesi):

Å Ä·Ä«dums
Uptime
Median
75 procentile
95 procentile

Ali CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s

Kā redzat, 100% darbÄ«bas laiku vēl neesam spējuÅ”i sasniegt, bet kaut ko izdomāsim, un tad par rezultātiem pastāstÄ«sim jaunā rakstā :)

Respekts tiem, kas izlasīja visas trīs daļas līdz galam. Es ceru, ka jums tas viss likās tikpat interesanti kā man, kad es to darīju.

PS IepriekŔējās daļas

1. daļa
2. daļa

Avots: www.habr.com

Pievieno komentāru