Ola a todos!
Nikita está en contacto, un enxeñeiro de sistemas da empresa SEMrush. Hoxe falareivos de como nos enfrontamos á tarefa de garantir a estabilidade do noso servizo semrush.com en China, e que problemas atopamos durante a súa implementación (dada a localización do noso centro de datos na costa leste dos Estados Unidos).
Esta será unha gran historia, dividida en varios artigos. Vouche contar como pasou todo para nós: desde un servizo completamente non funcional de China, ata indicadores de rendemento do servizo ao nivel da súa versión americana para estadounidenses. Prometo que será interesante e útil. Entón, imos.
Problemas da internet chinesa
Incluso a persoa máis afastada das especificidades da administración da rede xa escoitou falar Gran cortalumes de China. Vaia, soa xenial, non? Pero o que é e como funciona realmente é unha cuestión bastante complicada. Podes atopar moitos artigos en Internet dedicados a isto, pero dende o punto de vista técnico, a estrutura deste cortalumes non se describe en ningures. O que, con todo, non é sorprendente. Admitirei de inmediato que a partir dos resultados dun ano de traballo non poderei dicir exactamente como funciona, pero podo contarvos os meus comentarios e conclusións prácticas. E comezaremos cos rumores sobre este firewall.
Hai moitos rumores sobre este mesmo cortalumes. Imos recoller os principais e máis interesantes deles nunha soa lista:
- Google, Facebook, Twitter e outros servizos similares están bloqueados e non funcionan en China.
- Calquera tráfico que vai FÓRA de China e ENTRADA EN China analízase e limitase mediante a aprendizaxe automática (no caso de tráfico sospeitoso), o que ralentiza moito o tráfico (tráfico) que pasa pola fronteira.
- As axencias de intelixencia chinesas hackearán calquera tráfico cifrado que pase polo seu firewall.
- Os túneles VPN, os túneles IPSEC son inestables, colócanse e están constantemente bloqueados.
- Canto máis sinxelo sexa o cifrado, máis sinxela sexa a frase de acceso utilizada para autenticar/cifrar o tráfico, máis rápido pasará polo firewall chinés.
Isto é o que descubrimos sobre estes rumores:
- Google, Facebook, Twitter e outros servizos similares están realmente bloqueados (o teu KO), pero moitos dominios técnicos de Google, por exemplo, non están prohibidos e funcionan (o mesmo gstatic.com). A conclusión despréndese: non debes cortar temerariamente todos os recursos de Google e outros que parecen estar bloqueados.
- Calquera tráfico que pasa pola fronteira realmente engade un serio atraso ao seu tempo. Mira os dous resultados. Un sitio, unha páxina, simple GET enrolar'om. A primeira medición foi da propia China (a fermosa cidade de Shenzhen). O segundo foi medido desde fóra desde Hong Kong (ten soberanía, e non hai cortalumes entre el e o mundo). A distancia entre as cidades en liña recta é de aproximadamente 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/spreste atención a conexión_tempo. E, en xeral, ves o resultado: o firewall engade 4 segundos extra, o que é monstruosamente longo.
- Os túneles VPN e IPSEC fallan a miúdo. Disto falarei un pouco máis tarde e con máis detalle. Os servidores VPN que usan os usuarios bótanse co paso do tempo (normalmente nun día despois do inicio do uso).
- Hai unha opinión recibida de persoas que viven en China de que canto máis sinxelo é o cifrado do tráfico, máis rápido pasa pola fronteira, porque é fácil entender que non hai nada ilegal. E do mesmo xeito, o tráfico "limpo" recibe máis ancho de banda e velocidade de paso, mentres que o tráfico "sucio", no que non se entende nada, recibe, pola contra, un paso máis lento. Por exemplo, vou usar curl to ifconfig.co a través do protocolo HTTPS e HTTP.
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/sUnha diferenza de 5 segundos para un tempo total de descarga de 13 bytes. Ademais, ao facer unha proba deste tipo varias veces, podes notar que GET en HTTP complétase xeralmente ao mesmo tempo cada vez, mentres que en HTTPS o sitio ás veces responde en 3, 5, 10 e ata 17 segundos. Ás veces ocorren erros SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Entón o que temos:
- Os problemas creados polo firewall chinés descríbense anteriormente.
- Os pings aos recursos externos e aos túneles interiores desaparecen periodicamente.
- A latencia entre dous puntos cambia constantemente e moitas veces é simplemente imprevisible. Ao conectar diferentes cidades/rexións, esperas que, en función da localización xeográfica das rexións, o atraso sexa menor, pero obtén a situación exactamente oposta.
- Internet e as canles de comunicación son rápidas ou lentas. Hai unha lixeira dependencia da hora do día e do día da semana, pero non sempre.
- As solicitudes de DNS ao mundo exterior desde China ás veces superan o tempo de espera permitido.
A imaxe que emerxe é simplemente "excelente".
O centro de datos, como xa dixen, está no leste dos Estados Unidos, e todo o SEMrush está formado por decenas de produtos interconectados, backends, frontends, bases de datos e todo isto en DC e nubes. A nós, como equipo de administradores de sistemas, encargáronnos a tarefa de comezar rapidamente a traballar en China sen esforzo.
Tivemos que responder a unha pregunta importante: é posible saír adiante con poucos gastos e resolver todos os problemas asociados á Internet e ao firewall chinés a nivel de rede/nube/servidor?
Comezamos recibindo .
Licenza ICP
Para poder aloxar o teu servizo en China (China continental) e realizar probas, primeiro debes obter unha licenza ICP para o dominio.
Se o tráfico de usuarios do teu sitio finaliza na China continental e se o teu dominio non ten unha licenza ICP, o teu tráfico bloquearase no ISP/hosting. Curiosamente, a licenza ICP inclúe un provedor específico, xa sexa Cloudflare ou Alibaba Cloud. Polo tanto, se recibiches unha licenza ICP para Cloudflare e aloxaches o teu sitio web con eles, non poderás moverte "sen problemas" a Alibaba Cloud. Terás que engadir outro hospedaxe a esta licenza.
Tras recibir unha licenza ICP para o dominio, puidemos elaborar e implementar ideas e solucións técnicas específicas.
Proba de solucións
Pero antes de crear directamente opcións de posta en escena, xirar os botóns, optimizar o rendemento do sitio e a súa velocidade, cómpre escoller unha ferramenta para probalo para ver cales das nosas accións melloran ou, pola contra, empeoran o rendemento do sitio.
A nosa ferramenta de proba tiña que cumprir dous requisitos principais:
- debería poder realizar probas desde China,
- debe ter probas de navegador.
Así que atopamos ! Teñen unha excelente cobertura de lugares de proba en todo o mundo. En China, tamén se poden realizar probas desde 100500 provincias a través desta ferramenta. Cada un ten varios provedores diferentes + a capacidade de facer espiña dorsal-probas (algo así como unha máquina virtual nun centro de datos) e Última milla-probas (o máis preto posible das condicións do usuario, tamén coñecido como estación de traballo). Este último tipo de probas é máis caro.
Despois de ter celebrado un contrato anual (menos que iso non é posible), comezamos a estudar o instrumento. Francamente, quedamos gratamente sorprendidos pola súa funcionalidade. Podes executar:
- probas de DNS,
- Probas web (probas de navegador, GET/POST simple, emulación de clientes móbiles, etc.),
- Comprobacións transaccionais (por exemplo, inicio de sesión),
- probas de API,
- Ping, traceroute, NTP, etc.
Non podes enumerar todo. E o máis importante, cada proba pódese personalizar bastante ben engadindo unha morea de cabeceiras e outros parámetros. A saída é unha gran cantidade de información que describe completamente a túa proba. Se falamos das cousas máis interesantes para nós (probas de navegador), o resultado inclúe:
- Conectar, esperar, cargar, SSL, hora DNS,
- TTFB, TTLB, documento completo, tempo de renderización, carga DOM,
- Resposta (algo próximo ao Time To First Byte), Resposta da páxina web (algo próximo ao Time To Last Byte),
- Calquera percentil, media, tempo mediano
- Etc.
En consecuencia, todas estas métricas son excelentes para ver os cambios e comprender se as cousas melloraron. Principalmente miramos Resposta, Resposta da páxina web, Mediana, percentiles 75 e 95.
Unha pregunta importante que estivo no aire dende o principio: Podes confiar en Catchpoint?? Esta ferramenta reflicte a velocidade de carga real do sitio en China desde diferentes cidades ou é só un tipo de proba nun baleiro que non ten nada que ver coa experiencia real do usuario?
Este é un gran problema, porque estando en Rusia é case imposible descubrir de forma fiable como funciona un sitio de China. Ao facer un proxy de calcetíns a través dunha máquina virtual, o resultado final é que o sitio se carga nun par de minutos, o que é simplemente inaceptable para as probas, polo que a única opción para a proba manual é o curl e o simple GET desde a consola cun temporizador. . Isto axuda porque esta proba reflicte ben a velocidade da solución de rede e, se tamén hai probas de navegador, é moi boa.
Máis tarde nós mesmos fomos a China e estabamos convencidos de que Podes confiar en Catchpoint, que reflicte con bastante precisión os indicadores de rendemento reais.
Rede Cloudflare China
Como usamos con éxito Cloudflare para o dominio principal semrush.com, decidimos probar inmediatamente a súa función chamada . Esta opción só está habilitada para os sitios Enterprise previa solicitude separada e por unha tarifa adicional. Tamén está dispoñible só para sitios que teñan unha licenza ICP adecuada que enumera a Cloudflare como provedor. Despois de habilitalo, o "CDN chinés" de Cloudflare está dispoñible para o sitio: o tráfico das rexións chinesas aterra no PoP (Points of Presence) CF máis próximo e, a través das súas redes ou redes de provedores/socios, entrégase á orixe. .
O diagrama deste banco de probas preséntase a continuación.
Esta é unha gran opción para nós. Resulta que o segundo dominio tamén será para CF, o que non se suma á cantidade de solucións empregadas na empresa, e tampouco practicamente complica a infraestrutura.
Realizamos probas do navegador e isto é o que pasou:
Os diamantes vermellos son erros das probas. Os ficheiros seguintes son erros de DNS (resolver tempo de espera). Os fallos na parte superior son tempos mortos.
Tempo de actividade: 86.6
Mediana: 18 s
Percentil 75: 29.3 s
Percentil 95: 60 s
Mediana, eliminada despois da carga reCaptcha (Servizo de Google bloqueado en China) diminuíu de 28 a 18 segundos. Pero estes aínda son resultados terribles, tendo en conta que a mesma proba de semrush.com (desde EE. UU.) deu menos de 10 segundos ao 95% dos usuarios (desde EE. UU.) na mesma páxina (estático + dinámico).
Podes entrar en cada proba e mirar Fervenza e outros parámetros máis detallados. Comezamos a investigar as razóns dos erros, e se para os tempos mortos todo está máis ou menos claro: Internet en China "entra e sae", por iso a velocidade de conexión e carga de recursos do estranxeiro é inestable e desigual, entón os erros de DNS sorprendeunos moito . Atopamos iso PoP Cloudflare está realmente situado en China, o enderezo do sitio resolve a unha IP anycast, pero os servidores DNS son americanos, polo que as solicitudes de DNS están obrigadas a cruzar a fronteira, polo que ás veces fallan.
Aclarada esta cuestión con CF, resultou que Non teñen os seus propios servidores DNS en China, e aínda non se sabe cando será.
Polo tanto, decidimos probar só o DNS de Cloudflare e cambiamos o mecanismo operativo de Cloudflare para o noso sitio ao "Só DNS" Este é un modo no que Cloudflare non realiza o tráfico proxy por si mesmo, o que significa que non ofrece protección contra DDoS, CDN e outras funcións, e funciona no modo dun servidor DNS normal.
Este soporte móstrase esquemáticamente na seguinte figura. A cifra ten en conta o coñecemento emerxente de que os servidores DNS de Cloudflare están detrás dun cortalumes.
En Catchpoint realizamos probas GET sinxelas (non probas de navegador), que mostraron moitos fallos. Foron causados polos mesmos erros de DNS.
Comezamos a depurar estes erros usando cavar e descubriu que na primeira solicitude o enderezo está determinado correctamente, e despois de repetir solicitude recibimos cada vez SERVFAIL и non atopado. Por que sucede isto de súpeto?
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)Non hai tales erros ao consultar os servidores de Cloudflare NS directamente:
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.192Isto significa que o problema está do servidor DNS "local" ou do servidor do provedor.
Unha investigación máis adiante revelou que SERVFAIL poñemos a resolución AAAA-rexistros.
Resultou que ao solicitar a Cloudflare AAAA-rexistro que non existe no dominio, respondeu Cloudflare А-unha entrada que é un erro e incumprimento do RFC. Por que o resolvedor local (xxxx) Non me gustou, e el respondeu SERVFAIL. Este comportamento é claramente visible no seguinte rexistro:
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
Enviamos un informe de erro a Cloudflare e solucionalo despois dun tempo. Resultou interesante: polo momento aínda non hai soporte para IPv6 en China, polo que Cloudflare non puido emitir alí o seu enderezo IPv6 en resposta a unha solicitude. AAAA-rexistros. Ao final, todo resolveuse de tal xeito que Cloudflare comezou a responder por China NODATA a tales solicitudes.
Así, os erros de DNS nas probas de Catchpoint diminuíron drasticamente, pero non completamente. Os tempos mortos aínda están aquí:
E comezamos a buscar outra solución.
Na seguinte parte vouvos contar como probamos a nube chinesa Alibaba Cloud, como, coa axuda dun pouco de "maxia" de Nginx, puidemos crear rapidamente solucións PoC (Proof of Concept), como creamos solucións Multi-Cloud, unha das cales finalmente axudou moito a acelerar o traballo do servizo. de China.
Sexa atento!
Próximas partes
Fonte: www.habr.com
