ProHoster > Blogi > Haldamine > Kuidas me Hiina suurest tulemüürist läbi murdsime (2. osa)

Kuidas me Hiina suurest tulemüürist läbi murdsime (2. osa)

Tere!

Nikita on taas teiega, ettevõtte süsteemiinsener SEMrush. Ja selle artikliga jätkan lugu sellest, kuidas me leidsime lahenduse Hiina tulemüür meie teenuse semrush.com jaoks.

В eelmine osa Ma ütlesin:

  • millised probleemid tekivad pärast otsuse tegemist "Peame oma teeninduse Hiinas tööle panema"
  • Millised probleemid on Hiina Internetil?
  • miks on vaja ICP litsentsi?
  • kuidas ja miks otsustasime Catchpointiga testida
  • mis oli meie esimese Cloudflare China Networkil põhineva lahenduse tulemus
  • Kuidas me Cloudflare DNS-is vea leidsime

See osa on minu arvates kõige huvitavam, kuna keskendub konkreetsetele lavastuse tehnilistele teostustele. Ja me alustame või pigem jätkame sellega Alibaba pilv.

Alibaba pilv

Alibaba pilv on üsna suur pilvepakkuja, millel on kõik teenused, mis võimaldavad end ausalt pilveteenuse pakkujaks nimetada. On hea, et neil on võimalus registreeruda väliskasutajatele ja suurem osa saidist on tõlgitud inglise keelde (Hiina jaoks on see luksus). Selles pilves saate töötada paljude maailma piirkondadega, Mandri-Hiinaga, aga ka ookeanilise Aasiaga (Hongkong, Taiwan jne).

IPSEC

Alustasime geograafiaga. Kuna meie testsait asus Google Cloudis, pidime Alibaba Cloudi GCP-ga linkima, nii et avasime loendi asukohtadest, kus Google asub. Sel hetkel ei olnud neil Hongkongis veel oma andmekeskust.
Lähimaks piirkonnaks osutus Aasia-ida1 (Taiwan). Ali osutus Mandri-Hiina Taiwanile lähimaks piirkonnaks cn-Shenzhen (Shenzhen).

Koos terra vorm kirjeldas ja tõstis kogu infrastruktuuri GCP-s ja Ali-s. 100 Mbit/s tunnel pilvede vahel tõusis peaaegu hetkega üles. Shenzheni ja Taiwani poolel tõsteti puhverserveri virtuaalmasinaid. Shenzhenis lõpetatakse kasutajaliiklus, suunatakse tunneli kaudu Taiwani ja sealt otse meie teenuse välisele IP-le. meie-ida (USA idarannik). Ping virtuaalmasinate vahel tunneli kaudu 24ms, mis polegi nii hull.

Samal ajal paigutasime sisse katseala Alibaba pilve DNS. Pärast tsooni delegeerimist NS Alile vähenes eraldusaeg 470 ms-lt kuni 50 ms. Enne seda oli tsoon ka Cloudlfare'is.

Paralleelselt tunneliga Aasia-ida1 tõstis Shenzhenist otse teise tunneli us-ida4. Seal lõid nad rohkem puhverserveri virtuaalmasinaid ja hakkasid mõlemat lahendust testima, suunates testliiklust küpsiste või DNS-i abil. Katsestendi on skemaatiliselt kirjeldatud järgmisel joonisel:

Tunnelite latentsus osutus järgmiseks:
Ali cn-shenzhen <—> GCP asia-east1 — 24 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms

Catchpointi brauseri testid näitasid suurepärast paranemist.

Võrrelge kahe lahenduse testitulemusi:

otsus
Töö kestvus
Mediaan
75 protsentiil
95 protsentiil

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Need on andmed lahendusest, mis kasutab IPSEC-tunneli kaudu Aasia-ida1. Meie-east4 kaudu olid tulemused kehvemad ja vigu oli rohkem, seega ma tulemusi ei avalda.

Kahe tunneli katse tulemuste põhjal, millest üks lõppeb Hiinale lähimas piirkonnas ja teine ​​lõppsihtkohas, sai selgeks, et oluline on Hiina tulemüüri alt "välja tulla" nii kiiresti kui võimalik. võimalik ja seejärel kasutada kiireid võrke (CDN-i pakkujad, pilveteenuse pakkujad jne). Pole vaja üritada tulemüürist läbi pääseda ja ühe hoobiga sihtkohta jõuda. See pole kõige kiirem viis.

Üldiselt pole tulemused halvad, kuid semrush.com-i mediaan on 8.8 s ja 75 protsentiili 9.4 s (samal testil).
Ja enne edasiminekut tahaksin teha väikese lüürilise kõrvalepõike.

Lüüriline kõrvalepõige

Pärast kasutaja sisenemist saidile www.semrushchina.cn, mis lahendatakse "kiirete" Hiina DNS-serverite kaudu, läbib HTTP päring meie kiire lahenduse. Vastus tagastatakse sama teed pidi, kuid domeen on määratud kõigis JS-i skriptides, HTML-lehtedel ja muudes veebilehe elementides semrush.com lisaressursside jaoks, mis tuleb lehe renderdamisel laadida. See tähendab, et klient lahendab "peamise" A-kirje www.semrushchina.cn ja läheb kiirtunnelisse, saab kiiresti vastuse – HTML-lehe, mis ütleb:

  • laadige alla sellised ja sellised js-id saidilt sso.semrush.com,
  • Hankige CSS-failid saidilt cdn.semrush.com,
  • ja tee ka mõned pildid saidilt dab.semrush.com
  • ja nii edasi.

Brauser hakkab nende ressursside jaoks kasutama "välist" Internetti, läbides iga kord tulemüüri, mis kulutab reageerimisaega.

Aga eelmine test näitab tulemusi siis, kui lehel ressursse pole semrush.comainult semrushchina.cn, ja *.semrushchina.cn lahendab tunnelisse pääsemiseks Shenzhenis asuva virtuaalmasina aadressi.

Ainult nii, surudes oma lahenduse Hiina tulemüüri kiireks läbimiseks maksimaalselt läbi kogu võimaliku liikluse, saate vastuvõetavad kiirused ja veebisaidi saadavuse näitajad ning lahendustestide ausad tulemused.
Tegime seda ilma ühegi koodimuudatuseta meeskonna toote poolel.

Alamfilter

Lahendus sündis peaaegu kohe pärast selle probleemi ilmnemist. Meil oli vaja PoC (Proof of Concept), et meie tulemüüri läbipääsulahendused töötavad tõesti hästi. Selleks peate kogu saidi liikluse sellesse lahendusse nii palju kui võimalik pakkima. Ja kandideerisime alamfilter nginxis.

Alamfilter on nginxis üsna lihtne moodul, mis võimaldab muuta vastuse kehas ühe rea teise rea vastu. Nii et muutsime kõiki juhtumeid semrush.com edasi semrushchina.cn kõigis vastustes.

Ja... see ei töötanud, kuna saime taustaprogrammidest kokkusurutud sisu, nii et alamfilter ei leidnud vajalikku rida. Pidin nginxisse lisama veel ühe kohaliku serveri, mis pakkis vastuse lahti ja edastas selle järgmisele kohalikule serverile, mis oli juba hõivatud stringi väljavahetamisega, tihendamisega ja ahela järgmisele puhverserverile saatmisega.

Selle tulemusena, kust klient saaks .semrush.com, sai ta .semrushchina.cn ja astus kuulekalt läbi meie otsuse.

Siiski ei piisa ainult domeeni ühesuunalisest muutmisest, sest taustaprogrammid ootavad endiselt semrush.com-i kliendi järgmistes päringutes. Sellest lähtuvalt saame samas serveris, kus ühesuunaline asendamine toimub, lihtsa regulaaravaldise abil päringust alamdomeeni ja seejärel teeme puhverserveri_pääs muutujaga $ host, eksponeeritud aastal $subdomain.semrush.com. See võib tunduda segane, kuid see töötab. Ja see toimib hästi. Üksikute domeenide jaoks, mis nõuavad erinevat loogikat, looge lihtsalt oma serveriplokid ja tehke eraldi konfiguratsioon. Allpool on selle skeemi selguse ja tutvustamise huvides lühendatud nginxi konfiguratsioonid.

Järgmine konfiguratsioon töötleb kõiki Hiinast saadetud päringuid .semrushchina.cn: 

    listen 80;

    server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;

    sub_filter '.semrush.com' '.semrushchina.cn';
    sub_filter_last_modified on;
    sub_filter_once off;
    sub_filter_types *;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $subdomain.semrush.com;
        proxy_set_header X-Accept-Encoding $http_accept_encoding;
    }
}

See konfiguratsioon puhverserveriga localhost porti 83 ja seal ootab järgmine konfiguratsioon:

    listen 127.0.0.1:8083;

    server_name *.semrush.com;

    location / {
        resolver 8.8.8.8 ipv6=off;
        gunzip on;
        proxy_pass https://$host;
        proxy_set_header Accept-Encoding gzip;
    }
}

Kordan, need on kärbitud konfiguratsioonid.

Nagu see. See võib tunduda keeruline, kuid see on sõnades. Tegelikult on kõik lihtsam kui aurutatud kaalikas :)

Kõrvalepõikemise lõpp

Mõnda aega olime õnnelikud, sest müüt kukkuvate IPSEC tunnelite kohta ei leidnud kinnitust. Siis aga hakkasid tunnelid langema. Mitu korda päevas mõne minuti jooksul. Natuke, aga see meile ei sobinud. Kuna mõlemad tunnelid lõppesid samal ruuteril Ali poolel, siis otsustasime, et võib-olla on see piirkondlik probleem ja meil on vaja varupiirkonda tõsta.

Nad korjasid selle üles. Tunnelid hakkasid erinevatel aegadel üles ütlema, kuid tõrkeotsing toimis meie jaoks hästi nginxi ülesvoolu tasemel. Aga siis hakkasid tunnelid langema umbes samal ajal 🙂 Ja uuesti hakkasid 502 ja 504. Tööaeg hakkas halvenema, nii et hakkasime varianti kallal töötama Alibaba CEN (Cloud Enterprise Network).

CEN

CEN - see on Alibaba Cloudi erinevatest piirkondadest pärit kahe VPC ühenduvus, see tähendab, et saate ühendada üksteisega pilve mis tahes piirkondade privaatvõrke. Ja mis kõige tähtsam: sellel kanalil on üsna ranged SLA. See on väga stabiilne nii kiiruse kui ka tööaja poolest. Kuid see pole kunagi nii lihtne:

  • seda on VÄGA raske hankida, kui te pole Hiina kodanik ega juriidiline isik,
  • Peate maksma iga kanali ribalaiuse megabiti eest.

Võimalus ühendada Mandri-Hiina и Välismaal, lõime CEN-i kahe Ali piirkonna vahel: cn-Shenzhen и us-ida-1 (meile lähim punkt-ida4). Ali us-ida-1 tõstis veel ühe virtuaalmasina, et oleks veel üks hüpe.

See osutus järgmiselt:

Brauseri testi tulemused on allpool:

otsus
Töö kestvus
Mediaan
75 protsentiil
95 protsentiil

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Jõudlus on veidi parem kui IPSEC. Kuid IPSEC-i kaudu saate potentsiaalselt alla laadida kiirusega 100 Mbit / s ja CEN-i kaudu ainult kiirusega 5 Mbit / s ja rohkem.

Kõlab nagu hübriid, eks? Ühendage IPSEC-i kiirus ja CEN-i stabiilsus.

Seda me tegime, võimaldades IPSEC-tunneli rikke korral liiklust nii IPSEC-i kui ka CEN-i kaudu. Tööaeg on muutunud palju pikemaks, kuid saidi laadimiskiirus jätab siiski soovida. Seejärel joonistasin kõik ahelad, mida olime juba kasutanud ja testinud ning otsustasin proovida lisada sellele skeemile veel veidi GCP-d, nimelt kork.

kork

kork - Kas Globaalne koormuse tasakaalustaja (või Google Cloud Load Balancer). Sellel on meie jaoks oluline eelis: CDN-i kontekstis on see olemas anycast IP, mis võimaldab suunata liiklust kliendile lähimasse andmekeskusesse, nii et liiklus jõuaks kiiresti Google'i kiiresse võrku ja vähem liiguks "tavalise" Interneti kaudu.

Kaks korda mõtlemata tõstsime HTTP/HTTPS LB Paigaldasime oma virtuaalsed masinad koos alamfiltriga GCP-sse ja taustaprogrammina.

Seal oli mitu skeemi:

  • Kasutage Cloudflare Hiina võrk, kuid seekord peaks Origin määrama globaalse IP GLB.
  • Lõpetage kliendid aadressil cn-Shenzhenja sealt puhverdada liiklus otse kork.
  • Minge otse Hiinast kork.
  • Lõpetage kliendid aadressil cn-Shenzhen, sealt puhverserver Aasia-ida1 IPSEC-i kaudu (in us-ida4 CENi kaudu), sealt GLB-sse (rahulikult, all on pilt ja selgitus)

Testisime kõiki neid valikuid ja veel mitmeid hübriidvariante:

  • Cloudflare + GLB

See skeem ei sobinud meile tööaja ja DNS-i vigade tõttu. Kuid test viidi läbi enne CF-poolse vea parandamist, võib-olla on nüüd parem (see ei välista aga HTTP ajalõppusid).

  • Ali + GLB

See skeem ei sobinud meile ka tööaja osas, kuna GLB langes sageli ülesvoolust välja, kuna vastuvõetava aja jooksul või ajalõpu ei olnud võimalik ühendust luua, kuna Hiinas asuva serveri jaoks jääb GLB aadress väljapoole ja seega ka serverist tahapoole. Hiina tulemüür. Maagiat ei juhtunud.

  • Ainult GLB

Variant, mis sarnaneb eelmisele, ainult et see ei kasutanud Hiinas endas servereid: liiklus läks otse GLB-sse (DNS-kirjeid muudeti). Sellest tulenevalt ei olnud tulemused rahuldavad, kuna tavaliste Interneti-teenuse pakkujate teenuseid kasutavatel Hiina klientidel on tulemüüri läbimisega palju halvem olukord kui Ali Cloudil.

  • Shenzhen -> (CEN/IPSEC) -> Puhverserver -> GLB

Siin otsustasime kasutada kõigist lahendustest parimat:

  • stabiilsus ja CEN-i garanteeritud SLA
  • suur kiirus IPSEC-ilt
  • Google'i "kiire" võrk ja selle anycast.

Skeem näeb välja umbes selline: kasutajaliiklus lõpetatakse virtuaalses masinas Ch-Shenzhen. Seal on konfigureeritud Nginxi ülesvoolud, millest osa osutab IPSEC tunneli teises otsas asuvatele privaatsetele IP-serveritele ja osa ülesvoolud osutavad CEN-i teisel poolel asuvate serverite privaataadressidele. IPSEC on konfigureeritud vastavalt piirkonnale Aasia-ida1 GCP-s (lahenduse loomise ajal oli Hiinale lähim piirkond. GCP on nüüd esindatud ka Hongkongis). CEN – piirkonnale us-ida1 Ali Cloudis.

Seejärel suunati liiklus mõlemast otsast anycast IP GLB, see tähendab Google'i lähima asukohani ja läks selle võrkude kaudu piirkonda us-ida4 GCP-s, milles olid asendusvirtuaalsed masinad (nginxi alamfiltriga).

See hübriidlahendus, nagu me ootasime, kasutas ära iga tehnoloogia eelised. Üldiselt käib liiklus läbi kiire IPSEC-i, aga kui probleemid algavad, viskame need serverid kiiresti ja mõneks minutiks ülesvoolust välja ja saadame liiklust ainult läbi CEN-i, kuni tunnel stabiliseerub.

Rakendades ülaltoodud loendist neljandat lahendust, saavutasime selle, mida tahtsime ja mida ettevõte meilt sel hetkel nõudis.

Uue lahenduse brauseri testi tulemused võrreldes eelmiste lahendustega:

otsus
Töö kestvus
Mediaan
75 protsentiil
95 protsentiil

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

CDN

Meie juurutatud lahenduses on kõik hästi, kuid puudub CDN, mis saaks kiirendada liiklust regionaalsel ja isegi linna tasandil. Teoreetiliselt peaks see saiti lõppkasutajate jaoks kiirendama, kasutades CDN-i pakkuja kiireid sidekanaleid. Ja me mõtlesime sellele kogu aeg. Ja nüüd on kätte jõudnud aeg projekti järgmiseks iteratsiooniks: CDN-i pakkujate otsimine ja testimine Hiinas.

Ja sellest räägin teile järgmises, viimases osas :)

Allikas: www.habr.com

Lisa kommentaar