Hoxe, o servizo Bitrix24 non conta con centos de gigabits de tráfico, nin conta cunha enorme flota de servidores (aínda que, por suposto, hai bastantes existentes). Pero para moitos clientes é a principal ferramenta para traballar na empresa, é unha verdadeira aplicación crítica para o negocio. Polo tanto, non hai forma de caer. E se o accidente ocorreu, pero o servizo "recuperouse" tan rápido que ninguén se decatou de nada? E como é posible implementar a failover sen perder a calidade do traballo e o número de clientes? Alexander Demidov, director de servizos na nube de Bitrix24, falou para o noso blog sobre como evolucionou o sistema de reservas ao longo dos 7 anos de existencia do produto.
"Lanzamos Bitrix24 como SaaS hai 7 anos. A principal dificultade probablemente fose a seguinte: antes de ser lanzado publicamente como SaaS, este produto simplemente existía no formato dunha solución en caixa. Os clientes compráronos, aloxárono nos seus servidores, configuraron un portal corporativo: unha solución xeral para a comunicación dos empregados, o almacenamento de ficheiros, a xestión de tarefas, o CRM, iso é todo. E para 2012, decidimos que queriamos lanzalo como SaaS, administrándoo nós mesmos, garantindo tolerancia a fallos e fiabilidade. Coñecimos experiencia ao longo do camiño, porque ata entón simplemente non a tiñamos: só eramos fabricantes de software, non provedores de servizos.
Ao lanzar o servizo, entendemos que o máis importante é garantir a tolerancia a fallos, a fiabilidade e a dispoñibilidade constante do servizo, porque se tes un sitio web simple e común, unha tenda, por exemplo, e cáeche sobre ti e queda alí parado. unha hora, só sofres ti, perdes pedidos, perdes clientes, pero para o teu propio cliente, isto non é moi crítico para el. Estaba molesto, claro, pero foi e comprouno noutro sitio. E se esta é unha aplicación na que está ligado todo o traballo dentro da empresa, as comunicacións, as decisións, entón o máis importante é gañar a confianza dos usuarios, é dicir, non defraudalos e non caer. Porque todo traballo pode parar se algo dentro non funciona.
Bitrix.24 como SaaS
Montamos o primeiro prototipo un ano antes do lanzamento público, en 2011. Montámolo en aproximadamente unha semana, mirámolo, xirámolo, incluso funcionaba. É dicir, podería entrar no formulario, introducir alí o nome do portal, abriríase un novo portal e crearíase unha base de usuarios. Mirámolo, avaliamos o produto en principio, desbotámolo e seguimos perfeccionándoo durante todo un ano. Porque tiñamos unha gran tarefa: non queriamos facer dúas bases de código diferentes, non queríamos admitir un produto empaquetado separado, solucións na nube separadas; queriamos facelo todo nun só código.
Unha aplicación web típica naquel momento era un servidor no que se executa algún código PHP, unha base de datos mysql, cárganse ficheiros, colócanse documentos e imaxes no cartafol de carga, ben, todo funciona. Por desgraza, é imposible lanzar un servizo web críticamente estable usando isto. Alí, a caché distribuída non é compatible, a replicación de bases de datos non é compatible.
Formulamos os requisitos: esta é a capacidade de estar situado en diferentes localizacións, admitir a replicación e, idealmente, estar situado en diferentes centros de datos distribuídos xeograficamente. Separa a lóxica do produto e, de feito, o almacenamento de datos. Poder escalar dinámicamente segundo a carga e tolerar totalmente a estática. Desas consideracións, de feito, xurdiron os requisitos para o produto, que perfeccionamos ao longo do ano. Durante este tempo, na plataforma, que resultou ser unificada -para solucións en caixa, para o noso propio servizo- fixemos soporte para aquelas cousas que necesitabamos. Soporte para a replicación de mysql a nivel do propio produto: é dicir, o programador que escribe o código non pensa en como se distribuirán as súas solicitudes, usa a nosa API e sabemos como distribuír correctamente as solicitudes de escritura e lectura entre mestres. e escravos.
Fixemos soporte a nivel de produto para varios almacenamentos de obxectos na nube: Google Storage, Amazon s3, ademais de compatibilidade con Open Stack Swift. Polo tanto, isto foi conveniente tanto para nós como servizo como para os desenvolvedores que traballan cunha solución empaquetada: se só usan a nosa API para traballar, non pensan en onde se gardará o ficheiro, localmente no sistema de ficheiros ou no almacenamento de ficheiros obxecto.
Como resultado, decidimos inmediatamente que reservaríamos a nivel de todo o centro de datos. En 2012, lanzamos totalmente en Amazon AWS porque xa tiñamos experiencia con esta plataforma: alí estaba aloxado o noso propio sitio web. Atraeunos o feito de que en cada rexión Amazon ten varias zonas de dispoñibilidade; de feito, (na súa terminoloxía) varios centros de datos que son máis ou menos independentes entre si e que nos permiten reservar a nivel de todo un centro de datos: se falla de súpeto, as bases de datos replícanse master-master, faise unha copia de seguranza dos servidores de aplicacións web e os datos estáticos móvense ao almacenamento de obxectos s3. A carga está equilibrada, naquel momento por Amazon elb, pero un pouco máis tarde chegamos aos nosos propios equilibradores de carga, porque necesitabamos unha lóxica máis complexa.
O que querían é o que conseguiron...
Todas as cousas básicas que queriamos garantir - tolerancia a fallos dos propios servidores, aplicacións web, bases de datos - todo funcionou ben. O escenario máis sinxelo: se unha das nosas aplicacións web falla, todo é sinxelo: non se equilibran.
O equilibrador (naquel momento era o elb de Amazon) marcou as máquinas que estaban fóra de servizo como insalubres e desactivou a distribución de carga nelas. O escalado automático de Amazon funcionou: cando a carga creceu, engadíronse novas máquinas ao grupo de escalado automático, a carga distribuíuse a máquinas novas; todo estaba ben. Cos nosos equilibradores, a lóxica é aproximadamente a mesma: se lle pasa algo ao servidor de aplicacións, quitámoslle solicitudes, botamos estas máquinas, comezamos outras novas e seguimos traballando. O esquema cambiou un pouco ao longo dos anos, pero segue funcionando: é sinxelo, comprensible e non hai dificultades con el.
Traballamos en todo o mundo, os picos de carga dos clientes son completamente diferentes e, dun xeito amigable, deberíamos poder realizar determinados traballos de servizo en calquera dos compoñentes do noso sistema en calquera momento, sen que os clientes o noten. Polo tanto, temos a oportunidade de desactivar a base de datos, redistribuíndo a carga a un segundo centro de datos.
Como funciona todo? — Cambiamos o tráfico a un centro de datos que funcione: se hai un accidente no centro de datos, entón completamente, se este é o noso traballo planificado cunha base de datos, cambiamos parte do tráfico que atende a estes clientes a un segundo centro de datos, suspendendo a súa replicación. Se se necesitan máquinas novas para aplicacións web porque aumentou a carga do segundo centro de datos, iniciaranse automaticamente. Rematamos o traballo, restablece a replicación e devolvemos toda a carga. Se necesitamos reflectir algún traballo no segundo DC, por exemplo, instalar actualizacións do sistema ou cambiar a configuración na segunda base de datos, entón, en xeral, repetimos o mesmo, só na outra dirección. E se isto é un accidente, entón facemos todo trivialmente: usamos o mecanismo de xestión de eventos no sistema de seguimento. Se se activan varias comprobacións e o estado pasa a crítico, entón executamos este controlador, un controlador que pode realizar tal ou aquela lóxica. Para cada base de datos, especificamos que servidor é a conmutación por fallo para ela e onde hai que cambiar o tráfico se non está dispoñible. Historicamente, usamos nagios ou algúns dos seus garfos dunha forma ou outra. En principio, existen mecanismos similares en case calquera sistema de vixilancia, aínda non utilizamos nada máis complexo, pero quizais algún día o fagamos. Agora a supervisión desenvólvese pola falta de dispoñibilidade e ten a capacidade de cambiar algo.
Xa reservamos todo?
Temos moitos clientes dos EUA, moitos clientes de Europa, moitos clientes que están máis preto do Leste: Xapón, Singapur, etc. Por suposto, unha gran parte dos clientes están en Rusia. É dicir, o traballo non está nunha rexión. Os usuarios queren unha resposta rápida, hai requisitos para cumprir con varias leis locais, e dentro de cada rexión reservamos dous centros de datos, ademais de hai algúns servizos adicionais, que, de novo, son convenientes para colocar dentro dunha rexión - para os clientes que están en esta rexión está a traballar. Manexadores REST, servidores de autorización, son menos críticos para o funcionamento do cliente no seu conxunto, podes cambiar a través deles cun pequeno atraso aceptable, pero non queres reinventar a roda sobre como supervisalos e que facer. con eles. Polo tanto, estamos tentando utilizar as solucións existentes ao máximo, en lugar de desenvolver algún tipo de competencia en produtos adicionais. E nalgún lugar usamos trivialmente o cambio a nivel de DNS e determinamos a vivacidade do servizo polo mesmo DNS. Amazon ten un servizo Route 53, pero non é só un DNS no que podes facer entradas e xa está: é moito máis flexible e cómodo. A través del podes construír servizos xeodistribuídos con xeolocalizacións, cando o utilizas para determinar de onde veu o cliente e darlle certos rexistros; coa súa axuda podes construír arquitecturas de failover. As mesmas comprobacións de saúde están configuradas na propia Ruta 53, estableces os puntos finais que se supervisan, estableces métricas, estableces cales protocolos para determinar a "vivencia" do servizo: tcp, http, https; establecer a frecuencia das comprobacións que determinan se o servizo está activo ou non. E no propio DNS especificas o que será o principal, o que será o secundario, onde cambiar se se activa a comprobación de saúde dentro da ruta 53. Todo isto pódese facer con outras ferramentas, pero por que é conveniente? levantar unha vez e despois non pensar niso como facemos comprobacións, como cambiamos: todo funciona por si só.
O primeiro "pero": como e con que reservar a propia ruta 53? Quen sabe, e se lle pasa algo? Afortunadamente, nunca pisamos este rastrillo, pero de novo, terei unha historia por diante de por que pensamos que aínda tiñamos que facer unha reserva. Aquí puxemos pallas para nós con antelación. Varias veces ao día realizamos unha descarga completa de todas as zonas que temos na ruta 53. A API de Amazon permíteche envialas facilmente en JSON, e contamos con varios servidores de copia de seguridade onde a convertemos, subimos en forma de configuracións e temos, grosso modo, unha configuración de backup. Se ocorre algo, podemos implementalo rapidamente manualmente sen perder os datos da configuración de DNS.
Segundo "pero": O que nesta imaxe aínda non foi reservado? O propio equilibrador! A nosa distribución de clientes por rexión faise moi sinxela. Temos os dominios bitrix24.ru, bitrix24.com, .de - agora hai 13 diferentes, que operan en varias zonas. Chegamos ao seguinte: cada rexión ten os seus propios equilibradores. Isto fai que sexa máis cómodo distribuír entre rexións, dependendo de onde estea a carga máxima na rede. Se se trata dun fallo a nivel dun único equilibrador, simplemente quítase fóra do servizo e eliminase do dns. Se hai algún problema cun grupo de equilibradores, faise unha copia de seguranza noutros sitios e o cambio entre eles realízase mediante a mesma ruta53, porque debido ao curto TTL, o cambio prodúcese nun máximo de 2, 3 ou 5 minutos. .
Terceiro "pero": Que aínda non está reservado? S3, correcto. Cando colocamos os ficheiros que almacenamos para os usuarios en s3, cremos sinceramente que era perforante e non había necesidade de reservar nada alí. Pero a historia demostra que as cousas pasan doutro xeito. En xeral, Amazon describe S3 como un servizo fundamental, porque o propio Amazon utiliza S3 para almacenar imaxes da máquina, configuracións, imaxes AMI, instantáneas... E se s3 falla, como pasou unha vez durante estes 7 anos, sempre que levamos usando bitrix24, ségueo como un fan. Hai un montón de cousas que aparecen: incapacidade para iniciar máquinas virtuais, fallo da API, etc.
E S3 pode caer - pasou unha vez. Polo tanto, chegamos ao seguinte esquema: hai uns anos non existían instalacións públicas de almacenamento de obxectos serios en Rusia, e consideramos a opción de facer algo propio... Afortunadamente, non empezamos a facelo, porque imos facelo. profundizamos na experiencia que non temos, e probablemente estropearíamos. Agora Mail.ru ten almacenamento compatible con s3, Yandex teno e outros provedores teñen. Finalmente chegamos á idea de que queriamos ter, en primeiro lugar, unha copia de seguridade e, en segundo lugar, a posibilidade de traballar con copias locais. Para a rexión rusa en concreto, usamos o servizo Mail.ru Hotbox, que é compatible coa API con s3. Non necesitamos grandes modificacións no código dentro da aplicación, e fixemos o seguinte mecanismo: en s3 hai disparadores que desencadean a creación/eliminación de obxectos, Amazon ten un servizo chamado Lambda: este é un lanzamento de código sen servidor. que se executará xusto cando se activan certos disparadores.
Fixémolo moi sinxelo: se o noso disparador se dispara, executamos código que copiará o obxecto no almacenamento de Mail.ru. Para iniciar completamente o traballo con copias locais de datos, tamén necesitamos a sincronización inversa para que os clientes que están no segmento ruso poidan traballar cun almacenamento máis próximo a eles. O correo está a piques de completar os disparadores no seu almacenamento: será posible realizar a sincronización inversa a nivel de infraestrutura, pero polo momento estamos a facer isto a nivel do noso propio código. Se vemos que un cliente publicou un ficheiro, entón a nivel de código colocamos o evento nunha cola, procesámolo e facemos a replicación inversa. Por que é malo: se facemos algún tipo de traballo cos nosos obxectos fóra do noso produto, é dicir, por algún medio externo, non o teremos en conta. Polo tanto, agardamos ata o final, cando aparecen disparadores a nivel de almacenamento, para que, independentemente de onde executemos o código, o obxecto que nos chegou cópiese na outra dirección.
A nivel de código, rexistramos os dous almacenamentos para cada cliente: un considérase principal, o outro considérase backup. Se todo está ben, traballamos co almacenamento que está máis preto de nós: é dicir, os nosos clientes que están en Amazon, traballan con S3, e os que traballan en Rusia, traballan con Hotbox. Se se activa a marca, debería conectarse o failover e cambiaremos os clientes a outro almacenamento. Podemos marcar esta caixa de forma independente por rexión e podemos cambialos de un lado a outro. Aínda non usamos isto na práctica, pero proporcionamos este mecanismo e pensamos que algún día necesitaremos este interruptor e será útil. Isto xa pasou unha vez.
Ah, e Amazon fuxiu...
Este abril cúmprese o aniversario do inicio do bloqueo de Telegram en Rusia. O provedor máis afectado que caeu baixo isto é Amazon. E, por desgraza, as empresas rusas que traballaron para todo o mundo sufriron máis.
Se a empresa é global e Rusia é un segmento moi pequeno para iso, 3-5% - ben, dun xeito ou doutro, pode sacrificalos.
Se esta é unha empresa puramente rusa - estou seguro de que debe ser localizada localmente - ben, simplemente será cómodo para os propios usuarios, cómodo e haberá menos riscos.
E se esta é unha empresa que opera a nivel mundial e ten aproximadamente o mesmo número de clientes de Rusia e de todo o mundo? A conectividade dos segmentos é importante e deben funcionar entre si dun xeito ou doutro.
A finais de marzo de 2018, Roskomnadzor enviou unha carta aos maiores operadores indicando que planeaban bloquear varios millóns de IPs de Amazon para bloquear... o mensaxeiro Zello. Grazas a estes mesmos provedores, filtraron con éxito a carta a todos e entendíase que a conexión con Amazon podía derrubarse. Era venres, corremos en pánico aos nosos colegas de servers.ru, dicindo: "Amigos, necesitamos varios servidores que non estarán en Rusia, nin en Amazon, senón, por exemplo, nalgún lugar de Amsterdam", para para poder instalar, polo menos dalgún xeito, a nosa propia VPN e proxy alí para algúns puntos finais que non podemos influír de ningún xeito, por exemplo, terminales do mesmo s3; non podemos tentar crear un novo servizo e obter unha ip diferente, nós aínda necesitas chegar alí. En tan só uns días, puxemos en marcha estes servidores, puxémolos en funcionamento e, en xeral, preparámonos para o momento en que comezase o bloqueo. É curioso que RKN, mirando o alboroto e o pánico, dixese: "Non, agora non bloquearemos nada". (Pero isto é exactamente ata o momento no que Telegram comezou a ser bloqueado.) Despois de configurar as capacidades de derivación e de darnos conta de que o bloqueo non se introduciu, non comezamos a resolver todo o asunto. Si, por se acaso.
E en 2019 seguimos vivindo en condicións de bloqueo. Mirei onte á noite: preto dun millón de IP seguen bloqueadas. Certo que Amazon estivo case completamente desbloqueado, no seu momento álxido chegou aos 20 millóns de enderezos... En xeral, a realidade é que pode non haber coherencia, boa coherencia. De súpeto. Pode que non exista por razóns técnicas: incendios, escavadoras, todo iso. Ou, como vimos, non totalmente técnicos. Polo tanto, alguén grande e grande, cos seus propios AS, probablemente pode xestionar isto doutros xeitos: a conexión directa e outras cousas xa están no nivel l2. Pero nunha versión sinxela, como a nosa ou aínda máis pequena, podes, por se acaso, ter redundancia a nivel de servidores levantados noutro lugar, configurados previamente vpn, proxy, coa posibilidade de cambiar rapidamente a configuración a eles neses segmentos. que son fundamentais para a súa conectividade. Isto foinos útil máis dunha vez, cando comezou o bloqueo de Amazon; no peor dos casos, só permitimos o tráfico S3 por eles, pero pouco a pouco todo isto foi resolto.
Como reservar... todo un provedor?
Agora mesmo non temos un escenario no caso de que todo o Amazon caia. Temos un escenario similar para Rusia. En Rusia, fomos aloxados por un provedor, de quen escollemos ter varios sitios. E hai un ano enfrontámonos a un problema: aínda que se trata de dous centros de datos, pode haber problemas xa a nivel de configuración de rede do provedor que aínda afectarán a ambos os centros de datos. E é posible que acabemos sen estar dispoñibles en ambos sitios. Por suposto que foi o que pasou. Acabamos reconsiderando a arquitectura do interior. Non cambiou moito, pero para Rusia agora temos dous sitios, que non son do mesmo provedor, senón de dous diferentes. Se un falla, podemos cambiar ao outro.
Hipoteticamente, para Amazon estamos a barallar a posibilidade de reservar a nivel doutro provedor; quizais Google, quizais outra persoa... Pero ata agora observamos na práctica que mentres Amazon ten accidentes a nivel dunha zona de dispoñibilidade, os accidentes a nivel de toda unha rexión son bastante raros. Polo tanto, teoricamente temos a idea de que podemos facer unha reserva "Amazon non é Amazon", pero na práctica aínda non é así.
Algunhas palabras sobre a automatización
A automatización é sempre necesaria? Aquí convén recordar o efecto Dunning-Kruger. No eixe "x" está o noso coñecemento e experiencia que adquirimos, e no eixe "y" está a confianza nas nosas accións. Ao principio non sabemos nada e non estamos nada seguros. Entón sabemos un pouco e volvemos mega-confiados: este é o chamado "pico da estupidez", ben ilustrado pola imaxe "demencia e coraxe". Despois aprendemos un pouco e estamos preparados para ir á batalla. Despois pisamos algúns erros mega-graves e atopámonos nun val de desesperación, cando parece que sabemos algo, pero en realidade non sabemos moito. Entón, a medida que gañamos experiencia, volvemos máis seguros.
A nosa lóxica sobre varios cambios automáticos a certos accidentes está moi ben descrita neste gráfico. Comezamos, non sabíamos como facer nada, case todo o traballo facíase a man. Entón démonos conta de que podíamos conectar a automatización a todo e, como, durmir tranquilos. E, de súpeto, pisamos un mega-rake: desenvólvese un falso positivo e cambiamos o tráfico de un lado a outro cando, en boa forma, non deberíamos ter feito isto. En consecuencia, a replicación rompe ou outra cousa: este é o val mesmo da desesperación. E entón chegamos á comprensión de que hai que abordar todo con prudencia. É dicir, ten sentido confiar na automatización, que prevé a posibilidade de falsas alarmas. Pero! se as consecuencias poden ser devastadoras, entón é mellor deixalo á quenda de servizo, aos enxeñeiros de garda, que se asegurarán e vixiarán que realmente se produza un accidente, e realizarán manualmente as accións necesarias...
Conclusión
Ao longo de 7 anos, pasamos de que cando algo caía, había pánico-pánico, a entender que os problemas non existen, só hai tarefas, hai que -e poden- resolverse. Cando esteas a construír un servizo, mírao desde arriba, valora todos os riscos que poden ocorrer. Se os ves de inmediato, prevé a redundancia con antelación e a posibilidade de construír unha infraestrutura tolerante a fallos, porque calquera punto que poida fallar e levar á inoperabilidade do servizo definitivamente o fará. E aínda que che pareza que algúns elementos da infraestrutura definitivamente non fallarán, como o mesmo s3, aínda ten en conta que poden facelo. E polo menos en teoría, ten unha idea do que farás con eles se ocorre algo. Ter un plan de xestión de riscos. Cando estea a pensar en facelo todo de xeito automático ou manual, avalía os riscos: que pasará se a automatización comeza a cambiar todo, non levará isto a unha situación aínda peor en comparación cun accidente? Quizais nalgún lugar sexa necesario usar un compromiso razoable entre o uso da automatización e a reacción do enxeñeiro de servizo, quen avaliará a imaxe real e entenderá se hai que cambiar algo no lugar ou "si, pero non agora".
Un compromiso razoable entre o perfeccionismo e o esforzo real, o tempo, o diñeiro que pode gastar no esquema que finalmente terá.
Este texto é unha versión actualizada e ampliada do informe de Alexander Demidov na conferencia .
Fonte: www.habr.com