Hi!
La Nikita torna a estar amb tu, una enginyera de sistemes de l'empresa SEMrush. I amb aquest article continuo la història sobre com vam trobar una solució alternativa Tallafocs xinès pel nostre servei semrush.com.
В Jo vaig dir:
- quins problemes sorgeixen després de prendre la decisió "Hem de fer que el nostre servei funcioni a la Xina"
- Quins problemes té Internet xinesa?
- per què necessiteu una llicència ICP?
- com i per què vam decidir provar els nostres bancs de proves amb Catchpoint
- quin va ser el resultat de la nostra primera solució basada en Cloudflare China Network
- Com hem trobat un error a Cloudflare DNS
Aquesta part és la més interessant, al meu entendre, perquè se centra en implementacions tècniques específiques de la posada en escena. I començarem, o més aviat continuarem Alibaba Cloud.
Alibaba Cloud
Alibaba Cloud és un proveïdor de núvol força gran, que té tots els serveis que li permeten anomenar-se honestament un proveïdor de núvol. És bo que tinguin l'oportunitat de registrar-se per a usuaris estrangers, i que la major part del lloc estigui traduït a l'anglès (per a la Xina això és un luxe). En aquest núvol, podeu treballar amb moltes regions del món, la Xina continental, així com l'Àsia oceànica (Hong Kong, Taiwan, etc.).
IPsec
Vam començar amb la geografia. Com que el nostre lloc de prova es trobava a Google Cloud, havíem d'"enllaçar" Alibaba Cloud amb GCP, de manera que vam obrir una llista d'ubicacions en què Google està present. En aquell moment encara no tenien el seu propi centre de dades a Hong Kong.
La regió més propera va resultar ser Àsia-Orient 1 (Taiwan). Ali va resultar ser la regió de la Xina continental més propera a Taiwan cn-shenzhen (Shenzhen).
Amb terraform va descriure i plantejar tota la infraestructura a GCP i Ali. Un túnel de 100 Mbit/s entre els núvols va pujar gairebé a l'instant. Al costat de Shenzhen i Taiwan, es van plantejar màquines virtuals de proxy. A Shenzhen, el trànsit d'usuaris s'acaba, s'envia a través d'un túnel cap a Taiwan, i des d'allà va directament a la IP externa del nostre servei a nosaltres-est (Costa Est dels EUA). Feu ping entre màquines virtuals mitjançant un túnel 24ms, que no està tan malament.
Al mateix temps, vam col·locar una zona de prova Alibaba Cloud DNS. Després de delegar la zona a NS Ali, el temps de resolució va disminuir de 470 ms a 50 ms. Abans d'això, la zona també estava a Cloudlfare.
Paral·lel al túnel a Àsia-Orient 1 va aixecar un altre túnel des de Shenzhen directament a us-est4. Allà van crear més màquines virtuals proxy i van començar a provar ambdues solucions, encaminant el trànsit de prova mitjançant Cookies o DNS. El banc de proves es descriu esquemàticament a la figura següent:
La latència dels túnels va resultar ser la següent:
Ali cn-shenzhen <—> GCP asia-east1 — 24 ms
Ali cn-shenzhen <—> GCP us-east4 — 200 ms
Les proves del navegador Catchpoint van reportar una millora excel·lent.
Compareu els resultats de les proves de dues solucions:
decisió
Uptime
mitjana
75 percentil
95 percentil
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
Es tracta de dades d'una solució que utilitza un túnel IPSEC via Àsia-Orient 1. A través de us-east4 els resultats van ser pitjors, i hi va haver més errors, així que no donaré els resultats.
A partir dels resultats d'aquesta prova de dos túnels, un dels quals acaba a la regió més propera a la Xina i l'altre a la destinació final, va quedar clar que és important "sorgir" de sota el tallafoc xinès tan aviat com sigui. possible, i després utilitzar xarxes ràpides (proveïdors de CDN, proveïdors de núvol, etc.). No cal que intenteu passar pel tallafoc i arribar al vostre destí d'un sol cop. Aquesta no és la manera més ràpida.
En general, els resultats no són dolents, però, semrush.com té una mitjana de 8.8 s i 75 percentil 9.4 s (a la mateixa prova).
I abans de continuar, m'agradaria fer una breu digressió lírica.
Digressió lírica
Després que l'usuari entri al lloc www.semrushchina.cn, que es resol mitjançant servidors DNS xinesos "ràpids", la sol·licitud HTTP passa per la nostra solució ràpida. La resposta es retorna pel mateix camí, però el domini s'especifica a tots els scripts JS, pàgines HTML i altres elements de la pàgina web semrush.com per als recursos addicionals que s'han de carregar quan es representa la pàgina. És a dir, el client resol el registre A "principal". www.semrushchina.cn i entra al túnel ràpid, rep ràpidament una resposta: una pàgina HTML que diu:
- descarregar tal i tal js de sso.semrush.com,
- Obteniu els fitxers CSS de cdn.semrush.com,
- i també feu algunes fotos de dab.semrush.com
- i així successivament.
El navegador comença a anar a Internet "extern" per a aquests recursos, passant cada vegada per un tallafoc que consumeix temps de resposta.
Però la prova anterior mostra els resultats quan no hi ha recursos a la pàgina semrush.comnomés semrushchina.cn, i *.semrushchina.cn resol l'adreça de la màquina virtual a Shenzhen per després entrar al túnel.
Només d'aquesta manera, augmentant al màxim tot el trànsit possible a través de la vostra solució per passar ràpidament el tallafoc xinès, podreu obtenir velocitats acceptables i indicadors de disponibilitat del lloc web, així com resultats honestos de les proves de la solució.
Ho vam fer sense una sola edició de codi al costat del producte de l'equip.
Subfiltre
La solució va néixer gairebé immediatament després que va aparèixer aquest problema. Necessitàvem PoC (Prova de concepte) que les nostres solucions de penetració del tallafoc funcionen realment bé. Per fer-ho, heu d'embolicar tot el trànsit del lloc en aquesta solució tant com sigui possible. I vam aplicar en nginx.
Subfiltre és un mòdul bastant senzill a nginx que us permet canviar una línia del cos de la resposta a una altra línia. Així que hem canviat totes les ocurrències semrush.com en semrushchina.cn en totes les respostes.
I... no va funcionar perquè vam rebre contingut comprimit dels backends, de manera que el subfiltre no va trobar la línia requerida. Vaig haver d'afegir un altre servidor local a nginx, que va descomprimir la resposta i la va passar al següent servidor local, que ja estava ocupat substituint la cadena, comprimint-la i enviant-la al següent servidor intermediari de la cadena.
Com a resultat, on rebria el client .semrush.com, va rebre .semrushchina.cn i va seguir amb obediència la nostra decisió.
No obstant això, no n'hi ha prou amb canviar simplement el domini d'una manera, perquè els backend encara esperen semrush.com en les peticions posteriors del client. En conseqüència, al mateix servidor on es fa la substitució unidireccional, utilitzant una expressió regular simple obtenim el subdomini de la sol·licitud, i després fem proxy_pass amb variable $ host, exposat a $subdomain.semrush.com. Pot semblar confús, però funciona. I funciona bé. Per a dominis individuals que requereixen una lògica diferent, només cal que creeu els vostres propis blocs de servidor i feu una configuració independent. A continuació es mostren les configuracions nginx escurçades per a la claredat i la demostració d'aquest esquema.
La configuració següent processa totes les sol·licituds de la Xina a .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;
}
}Aquesta configuració es dirigeix a localhost al port 83, i la configuració següent està esperant allà:
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;
}
}Repeteixo, aquestes són configuracions retallades.
Així. Pot semblar complicat, però és en paraules. De fet, tot és més senzill que els naps al vapor :)
Final de la digressió
Durant un temps vam estar contents perquè no es va confirmar el mite de la caiguda de túnels IPSEC. Però aleshores els túnels van començar a caure. Diverses vegades al dia durant uns minuts. Una mica, però això no ens va bé. Com que els dos túnels es van acabar al costat d'Ali al mateix encaminador, vam decidir que potser es tractava d'un problema regional i que havíem d'elevar la regió de seguretat.
El van recollir. Els túnels van començar a fallar en diferents moments, però la migració per error ens va funcionar bé a nivell amunt a nginx. Però aleshores els túnels van començar a caure més o menys al mateix temps 🙂 I van començar de nou el 502 i el 504. El temps de funcionament va començar a deteriorar-se, així que vam començar a treballar en l'opció amb Alibaba CEN (Cloud Enterprise Network).
CEN
CEN - aquesta és la connectivitat de dues VPC de diferents regions dins d'Alibaba Cloud, és a dir, podeu connectar xarxes privades de qualsevol regió del núvol entre si. I el més important: aquest canal té un canal bastant estricte SLA. És molt estable tant en velocitat com en temps de funcionament. Però mai és tan senzill:
- és MOLT difícil d'obtenir si no sou ciutadans xinesos o una entitat legal,
- Heu de pagar per cada megabit de capacitat del canal.
Tenir l'oportunitat de connectar Xina continental и A l'estranger, vam crear un CEN entre dues regions d'Ali: cn-shenzhen и us-est-1 (punt més proper a nosaltres-est4). En Ali us-est-1 va plantejar una altra màquina virtual perquè n'hi hagi una més salt.
Va resultar així:
Els resultats de la prova del navegador són els següents:
decisió
Uptime
mitjana
75 percentil
95 percentil
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
CEN
99.75
16s
21s
27s
El rendiment és lleugerament millor que IPSEC. Però mitjançant IPSEC es pot descarregar potencialment a una velocitat de 100 Mbit/s, i mitjançant CEN només a una velocitat de 5 Mbit/s i més.
Sembla un híbrid, oi? Combina la velocitat IPSEC i l'estabilitat CEN.
Això és el que vam fer, permetent el trànsit tant per IPSEC com per CEN en cas de fallada del túnel IPSEC. El temps de funcionament ha augmentat molt, però la velocitat de càrrega del lloc encara deixa molt a desitjar. Després vaig dibuixar tots els circuits que ja havíem utilitzat i provat, i vaig decidir intentar afegir una mica més de GCP a aquest circuit, és a dir gorra.
gorra
gorra - És (o Google Cloud Load Balancer). Té un avantatge important per a nosaltres: en el context d'un CDN que té IP anycast, que us permet dirigir el trànsit al centre de dades més proper al client, de manera que el trànsit entri ràpidament a la xarxa ràpida de Google i menys passa per Internet "normal".
Sense pensar-s'ho dues vegades, vam plantejar HTTP/HTTPS LB Hem instal·lat les nostres màquines virtuals amb subfiltre a GCP i com a backend.
Hi havia diversos esquemes:
- Utilitzeu Xarxa de la Xina Cloudflare, però aquesta vegada Origin hauria d'especificar global IP GLB.
- Rescindir els clients a cn-shenzhen, i des d'allà envia el trànsit directament a gorra.
- Anar directament de la Xina a gorra.
- Rescindir els clients a cn-shenzhen, des d'aquí proxy a Àsia-Orient 1 mitjançant IPSEC (en us-est4 via CEN), a partir d'aquí aneu a GLB (calmadament, hi haurà una imatge i una explicació a continuació)
Hem provat totes aquestes opcions i algunes més híbrides:
- Cloudflare + GLB
Aquest esquema no ens agradava a causa del temps d'activitat i dels errors de DNS. Però la prova es va dur a terme abans que l'error es solucionés al costat de CF, potser ara és millor (no obstant això, això no exclou els temps d'espera HTTP).
- Ali + GLB
Aquest esquema tampoc ens va adequar pel que fa al temps d'activitat, ja que GLB sovint es va quedar fora de l'aigua amunt a causa de la impossibilitat de connectar-se en un temps o temps d'espera acceptable, perquè per a un servidor dins de la Xina, l'adreça GLB roman fora i, per tant, darrere del Tallafocs xinès. La màgia no va passar.
- Només GLB
Una opció semblant a l'anterior, només que no utilitzava servidors a la mateixa Xina: el trànsit anava directament a GLB (es van canviar els registres DNS). En conseqüència, els resultats no van ser satisfactoris, ja que els clients xinesos corrents que utilitzen els serveis dels proveïdors d'Internet normals tenen una situació molt pitjor amb passar el tallafoc que Ali Cloud.
- Shenzhen -> (CEN/IPSEC) -> Proxy -> GLB
Aquí vam decidir utilitzar la millor de totes les solucions:
- estabilitat i SLA garantit per CEN
- alta velocitat d'IPSEC
- La xarxa "ràpida" de Google i el seu anycast.
L'esquema sembla una cosa així: el trànsit d'usuaris s'acaba en una màquina virtual ch-shenzhen. S'hi configuren els fluxos amunt de Nginx, alguns dels quals apunten a servidors IP privats situats a l'altre extrem del túnel IPSEC, i alguns amunt apunten a adreces privades de servidors a l'altre costat del CEN. IPSEC configurat a la regió Àsia-Orient 1 a GCP (era la regió més propera a la Xina en el moment en què es va crear la solució. Ara GCP també té presència a Hong Kong). CEN - a la regió us-est1 a Ali Cloud.
Després es va dirigir el trànsit des dels dos extrems anycast IP GLB, és a dir, fins al punt de presència més proper de Google, i va passar per les seves xarxes fins a la regió us-est4 a GCP, en què hi havia màquines virtuals de substitució (amb subfiltre a nginx).
Aquesta solució híbrida, com esperàvem, aprofitava els beneficis de cada tecnologia. En general, el trànsit passa per un IPSEC ràpid, però si comencen els problemes, expulsem aquests servidors de manera ràpida i durant uns minuts i enviem trànsit només a través del CEN fins que el túnel s'estabilitzi.
Amb la implementació de la quarta solució de la llista anterior, vam aconseguir el que volíem i el que el negoci ens exigia en aquell moment.
Resultats de la prova del navegador per a la nova solució en comparació amb les anteriors:
decisió
Uptime
mitjana
75 percentil
95 percentil
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
Tot està bé en la solució que vam implementar, però no hi ha cap CDN que pugui accelerar el trànsit a nivell regional i fins i tot de ciutat. En teoria, això hauria d'accelerar el lloc per als usuaris finals utilitzant els canals de comunicació ràpids del proveïdor de CDN. I ho hem pensat tot el temps. I ara, ha arribat el moment de la següent iteració del projecte: cercar i provar proveïdors de CDN a la Xina.
I us parlaré d'això a la propera part final :)
Font: www.habr.com