ProHoster > Blog > Administrim > Si e thyenim Shenjën e Madhe Kinase (pjesa 2)

Si e thyenim Shenjën e Madhe Kinase (pjesa 2)

đŸ„‡Si tĂ« arrish nĂ« qiell dhe tĂ« bĂ«hesh pilot | ProHoster

Kjo Ă«shtĂ« pĂ«rsĂ«ri Nikita – inxhinier sistemi nga kompania SЕMrush. Me kĂ«tĂ« artikull vazhdoj historinĂ« rreth mĂ«nyrĂ«s si po mendonim pĂ«r njĂ« zgjidhje pĂ«r tĂ« anashkaluar Firewall-in Kinez pĂ«r shĂ«rbimin tonĂ« semrush.com.

Në pjesën e kaluar Unë tregova:

  • cilat probleme shfaqen pas vendimit "Na nevojitet qĂ« shĂ«rbimi ynĂ« tĂ« funksionojĂ« nĂ« KinĂ«"
  • cilat probleme ka interneti kinez
  • pse Ă«shtĂ« e nevojshme licenca ICP
  • si dhe pse vendosĂ«m tĂ« testonim stendat tona tĂ« provimit me Catchpoint
  • çfarĂ« rezultate na dha versioni ynĂ« i parĂ« i zgjidhjes, i bazuar nĂ« Rrjetin e Cloudflare nĂ« KinĂ«
  • si e gjetĂ«m njĂ« gabim nĂ« DNS-in e Cloudflare

Kjo pjesë është më interesante, sipas mendimit tim, sepse është përqendruar në zbatime teknike specifike të fazave. Dhe ne do të fillojmë, ose më saktë vazhdojmë, me Alibaba Cloud.

Alibaba Cloud

Alibaba Cloud — njĂ« ofrues relativisht i madh i shĂ«rbimeve cloud, i cili ka tĂ« gjitha shĂ«rbimet qĂ« i lejojnĂ« atij tĂ« quhet me tĂ« drejtĂ« ofrues cloud. ËshtĂ« mirĂ« qĂ« ata kanĂ« mundĂ«sinĂ« pĂ«r t'u regjistruar pĂ«rdoruesve tĂ« huaj, dhe qĂ« njĂ« pjesĂ« e madhe e faqes Ă«shtĂ« pĂ«rkthyer nĂ« anglisht (pĂ«r KinĂ«n kjo Ă«shtĂ« njĂ« luks). NĂ« kĂ«tĂ« cloud mund tĂ« punoni me shumĂ« rajone tĂ« botĂ«s, kontinenti i KinĂ«s, si dhe Azi e Oqeanit (Hong Kong, Tajvan, etj.).

IPSEC

Filluam me gjeografinë. Duke qenë se faqja testuese ndodhej në Google Cloud, na nevojitej "të lidhim" Alibaba Cloud me GCP, prandaj hapëm listën e lokacioneve ku është Google. Në atë moment nuk kishin ende datacenter të vetin në Hong Kong.
Rajoni më i afërt u tregua asia-east1 (Tajvan). Në Ali, rajoni më i afërt i Kinës kontinentale me Tajvanin ishte cn-shenzhen (Shenzhen).

Me ndihmën e terraform përshkruam dhe ngritëm të gjithë infrastrukturën në GCP dhe Ali. Tuneli 100 mbit/s midis cloud-eve u ngrit praktikisht menjëherë. Nga ana e Shenzhenit dhe Tajvanit ngritëm makinat virtuale proksy. Në Shenzhen, trafiku i përdoruesve përfundohet, proksyohet përmes tunelit në Tajvan, dhe nga aty dërgohet direkt në IP-në tonë të jashtme në us-east (Kohë Lindore e SHBA). Ping-u midis makinave virtuale përmes tunelit 24ms, gjë që nuk është kaq keq.

Kohësisht ne vendosëm një zonë testuese në Alibaba Cloud DNS. Pas delegimit të zonës në NS Ali, koha e rezolvit u ul nga 470 ms në 50 ms. Para kësaj, zona ishte gjithashtu në Cloudflare.

Paralelisht me tunelin deri në asia-east1 ngritëm një tunel tjetër nga Shenzhen direkt në us-east4. At that point, they created additional proxy virtual machines and began measuring both solutions, routing test traffic using Cookies or DNS. The test setup is schematically described in the following figure:

The latency for the tunnels was as follows:
Ali cn-shenzhen GCP asia-east1 — 24ms
Ali cn-shenzhen GCP us-east4 — 200ms

Browser tests from Catchpoint reported a significant improvement in performance metrics.

Compare the test results for the two solutions:

Zgjidhja
Uptime
Median
75 Percentile
95 Percentile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

These are the data from the solution using an IPSEC tunnel through asia-east1. Through us-east4, the results were worse, and there were also more errors, so I will not present those results.

Based on the results of this test of two tunnels, one terminating as close as possible to China and the other at the final destination, it became clear that it is important to 'break out' from under the Chinese firewall as quickly as possible, and then utilize fast networks (CDN providers, cloud providers, etc.). One should not try to pass through the firewall all at once to reach the final destination. This is not the fastest way.

Overall, the results are decent; however, semrush.com has a median of 8.8s, and the 75th percentile is 9.4s (in the same test).
And before moving on, I would like to make a small philosophical digression.

Një hapje lirikë

After the user accesses the site www.semrushchina.cn, which resolves through 'fast' Chinese DNS servers, the HTTP request goes through our fast solution. The response is returned via the same path, but in all JS scripts, HTML pages, and other elements of the web page, the domain semrush.com is specified for additional resources that should be loaded during page rendering. This means that the client resolves the 'main' A record www.semrushchina.cn and goes into the fast tunnel, quickly getting the response — the HTML page, which states:

  • download such js from sso.semrush.com,
  • fetch CSS files from cdn.semrush.com,
  • and also take images from dab.semrush.com.
  • dhe kĂ«shtu me radhĂ«.

The browser starts going out to the 'external' internet for these resources, going through the time-consuming firewall each time.

But in the previous test, the results were presented when there were no resources on the page, semrush.comonly semrushchina.cn, while *.semrushchina.cn resolves to the address of a virtual machine in Shenzhen, to then enter the tunnel.

Vetëm kështu, duke e maksimizuar të gjithë trafikun përmes zgjidhjes sonë për kalimin e shpejtë të firewall-it kinez, mund të arrijmë shbrillje të pranueshme dhe norma disponueshmërie të faqes, si dhe rezultate të ndershme të testeve të zgjidhjeve.
E kemi bërë këtë pa asnjë ndryshim në kodin e produkteve të ekipit.

Subfilter

Zgjidhja lindi pothuajse menjĂ«herĂ« pas shfaqjes sĂ« kĂ«tij problemi. Na duhej PoC (ProvĂ« e Konceptit), qĂ« zgjidhjet tona pĂ«r kalimin e firewall-it naprawdę punojnĂ« mirĂ«. PĂ«r kĂ«tĂ«, duhet tĂ« orientojmĂ« sa mĂ« shumĂ« trafik nga faqja nĂ« kĂ«tĂ« zgjidhje. Dhe ne zbatuam subfilter nĂ« nginx.

Subfilter — Ă«shtĂ« njĂ« modul mjaft i thjeshtĂ« nĂ« nginx, qĂ« lejon ndĂ«rrimin e njĂ« rreshti nĂ« trupin e pĂ«rgjigjes me njĂ« tjetĂ«r rresht. KĂ«shtu, ne ndĂ«rruam tĂ« gjitha rastet semrush.com nĂ« semrushchina.cn nĂ« tĂ« gjitha pĂ«rgjigjet.

Dhe
 nuk funksionoi, sepse nga backend-et merrnim përmbajtje të tkurrur, përkatësisht subfilter nuk gjeti rreshtin e duhur. Duhej të shtonim një server lokal tjetër në nginx, që shtrydhte përgjigjen dhe ia kalonte serverit tjetër lokal, i cili merrej me ndërrimin e rreshtit, tkurrjen dhe kthimin e saj ndaj serverit tjetër në zinxhir.

Si rezultat, aty ku klienti do të merrte .semrush.com, ai merrte .semrushchina.cn dhe shkonte në mënyrë bindëse përmes zgjidhjes sonë.

Megjithatë, nuk mjafton thjesht të ndryshoni domenin në një drejtim, sepse backend-et gjithashtu presin semrush.com në kërkesat e mëtejshme nga klienti. Kështu, në të njëjtin server ku bëhet ndërrimi në një drejtim, me ndihmën e një shprehjeje të thjeshtë të rregullt, ne nxjerrim subdomenin nga kërkesa, dhe më pas bëjmë proxy_pass me variablën $host, e cila është caktuar në $subdomain.semrush.com. Mund të duket e ngatërruar, por kjo funksionon. Dhe funksionon mirë. Për domenet e veçanta, që kërkojnë logjikë të ndryshme, thjesht krijohen blloqe serveri të veta dhe bëhet një konfigurim i veçantë. Më poshtë janë paraqitur konfigurime të përshkurtuara të nginx për përmirësim dhe demonstruar këtë skemë.

Konfigurimi tjetër shqyrton të gjitha kërkesat nga Kina në .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;
    }
}

Ky ësht kjo konfigurim që bën proxy për localhost në portin 83, dhe aty pret konfigurimi tjetër:

    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;
    }
}

Po e përsëris, këto janë konfigurime të prera.

Dikush mendohet se Ă«shtĂ« e komplikuar, por nĂ« fjalĂ« Ă«shtĂ« e thjeshtĂ«. NĂ« praktikĂ« gjithçka Ă«shtĂ« mĂ« e lehtĂ« se njĂ« patate e zier 🙂

Fundi i devijimit lirik

Për një kohë të caktuar ishim të lumtur, sepse miti i tunelieve IPSEC që bien nuk u vërtetua. Por më pas tunelat filluan të bien. Disa herë në ditë për disa minuta. Pak, por kjo nuk na përshtate. Pasi të dy tunelat ishin të terminuar në anën e Ali në një ruter, menduam se ndoshta ishte një problem rajonal dhe duhej të ngrinim regjionin e backup.

E ngritĂ«m. Tunelat filluan tĂ« bien nĂ« kohĂ« tĂ« ndryshme, por qĂ« fuksiononte mjaft mirĂ« failover nĂ« nivelin upstream nĂ« nginx. Por mĂ« pas tunelat filluan tĂ« bien praktikisht nĂ« tĂ« njĂ«jtĂ«n kohĂ« 🙂 Dhe pĂ«rsĂ«ri filluan 502 dhe 504. Uptime u pĂ«rkeqĂ«sua, kĂ«shtu qĂ« filluam tĂ« shqyrtonim mundĂ«sinĂ« me Alibaba CEN (Cloud Enterprise Network).

CEN

CEN — Ă«shtĂ« lidhja e dy VPC nga rajone tĂ« ndryshme brenda Alibaba Cloud, dmth mund tĂ« lidhni rrjete private tĂ« çdo rajoni brenda sĂ« njĂ«jtĂ«s cloud. Dhe ajo qĂ« Ă«shtĂ« mĂ« e rĂ«ndĂ«sishme: ky kanal ka njĂ« SLA. Ai Ă«shtĂ« shumĂ« stabil si pĂ«r shpejtĂ«si ashtu edhe pĂ«r uptime. Por kurrĂ« nuk Ă«shtĂ« gjithçka kaq e lehtĂ«:

  • Ă«shtĂ« SHUMË e vĂ«shtirĂ« tĂ« sigurohet, nĂ«se nuk jeni qytetarĂ« ose persona juridikĂ« kinezĂ«,
  • duhet tĂ« paguani pĂ«r çdo megabit kapaciteti tĂ« kanalit.

Duke siguruar mundësinë për të lidhur Mainland China dhe Overseas, krijuam CEN midis dy rajoneve të Ali: cn-shenzhen dhe us-east-1 (pikës më të afërt ndaj us-east-4). Në Ali us-east-1 ngritëm një virtual tjetër, për të pasur një hop.

KĂ«shtu e kemi:

Rezultatet e testeve të shfletuesit më poshtë:

Zgjidhja
Uptime
Median
75 Percentile
95 Percentile

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Të dhënat janë pak më të mira se IPSEC. Por përmes IPSEC mund të shkarkoni me shpejtësi 100 mbit/s, ndërsa përmes CEN vetëm me shpejtësi 5 mbit/s dhe më shtrenjtë.

E gjitha duket se kërkon një hibrid, apo jo? Të bashkoni shpejtësinë e IPSEC dhe stabilitetin e CEN.

I we did this by routing traffic both through IPSEC and CEN in case the IPSEC tunnel fails. The uptime significantly increased, but the website loading speed still left much to be desired. So I drew all the diagrams we had already used and tested, and decided to try adding a little GCP to this scheme, specifically GLB.

GLB

GLB — Ă«shtĂ« Global Load Balancer (or Google Cloud Load Balancer). It has an important advantage for us: in the context of CDN, it has anycast IP, which allows routing traffic to the nearest data center to the client, thereby speeding up access to Google's fast network and reducing the distance traveled on the 'regular' internet.

Without further ado, we set up HTTP/HTTPS LB in GCP and configured our virtual machines with subfilter as the backend.

There were several schemes:

  • PĂ«rdorni Cloudflare China Network, but this time the origin was specified as global IP GLB.
  • Terminate clients in cn-shenzhen, and proxy traffic directly to GLB.
  • Go directly from China to GLB.
  • Terminate clients in cn-shenzhen, from there proxy to asia-east1 through IPSEC (in us-east4 through CEN), from there go to GLB (don't worry, there will be a picture and explanation below)

We tested all these options and several hybrid ones:

  • Cloudflare + GLB

This scheme did not satisfy us due to uptime and DNS errors. However, the test was conducted before fixing the bug on CF's side, perhaps it has improved now (though this does not rule out HTTP timeouts).

  • Ali + GLB

This scheme also did not satisfy us due to uptime, as GLB often dropped from the upstream due to the inability to connect in a reasonable time or due to timeouts, since for the server inside China, the GLB address remains outside, thus behind the Chinese firewall. There was no magic.

  • GLB only

A variant similar to the previous one, only it did not use servers in China itself: the traffic went directly to GLB (DNS records were changed). Accordingly, the results were unsatisfactory, as ordinary Chinese clients using regular internet service providers faced much worse firewall traversal issues compared to Ali Cloud.

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

Here we decided to take the best from all solutions:

  • stability and guaranteed SLA from CEN
  • high speed from IPSEC
  • the 'fast' network of Google and its anycast.

The scheme looks something like this: user traffic is terminated on a virtual machine in ch-shenzhen. Aty janĂ« konfigurimet upstream tĂ« nginx, disa prej tĂ« cilave referohen nĂ« IP privat tĂ« serverĂ«ve qĂ« ndodhen nĂ« anĂ«n tjetĂ«r tĂ« IPSEC-tunelit, ndĂ«rsa disa upstream-e tĂ« tjera referohen nĂ« adresa private tĂ« serverĂ«ve nga ana tjetĂ«r e CEN. IPSEC u konfigurua pĂ«r rajonin asia-east1 nĂ« GCP (ishte rajoni mĂ« i afĂ«rt me KinĂ«n nĂ« momentin e krijimit tĂ« zgjidhjes. Tani GCP po ashtu ka prani nĂ« Hong Kong). CEN — pĂ«r rajonin us-east1 nĂ« Ali Cloud.

Më pas, trafiku nga të dy anët u drejtua në anycast IP GLB, domethënë në pikën më të afërt të pranishme të Google, dhe u dërgua përmes rrjeteve të tij në rajonin us-east4 në GCP, ku ndodheshin serverat virtualë zëvendësues (me subfilter në nginx).

Ky është një zgjidhje hibride, siç e prisnim, e cila e lejoi të përfitojmë nga avantazhet e çdo teknologjie. Në përgjithësi, trafiku kalon përmes IPSEC të shpejtë, por nëse ndodhin probleme, ne shpejt dhe për disa minuta e heqim këtë server nga upstream-et dhe dërgojmë trafikun vetëm përmes CEN, derisa tuneli të stabilizohet.

Duke zbatuar zgjidhjen e katërt nga lista mësipër, ne arritëm atë që dëshironim, dhe atë që biznesi kërkonte nga ne në atë kohë.

Rezultatet e testeve të shfletuesit për zgjidhjen e re në krahasim me ato të mëparshmet:

Zgjidhja
Uptime
Median
75 Percentile
95 Percentile

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

Në zgjidhjen që kemi zbatuar, gjithçka është mirë, vetëm se nuk kemi CDN, e cila mund të accelerojë trafikun në nivelin e rajoneve dhe madje qyteteve. Idealisht, kjo duhet ta shpejtojë punën e faqes për përdoruesit e fundit përmes përdorimit të kanaleve të shpejta të komunikimit nga ofruesi i CDN. Dhe ne gjithmonë e kemi menduar këtë. Dhe tani erdhi koha për iteracionin e ardhshëm të projektit: kërkimi dhe testimi i ofruesve të CDN në Kinë.

Dhe pĂ«r kĂ«tĂ« do t'ju tregoj nĂ« pjesĂ«n tjetĂ«r, pĂ«rfundimtare 🙂

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster