<\/a><\/noindex>Al lanzar el servicio, entend\u00edamos que lo m\u00e1s importante era garantizar la resiliencia, la fiabilidad y la disponibilidad constante del servicio, porque si tienes un sitio web normal, una tienda, por ejemplo, y se cae durante una hora, solo te perjudicas t\u00fa, pierdes pedidos, pierdes clientes, pero para tu cliente eso no es muy cr\u00edtico. Claro, se molesta un poco, pero se va y compra en otro sitio. Pero si se trata de una aplicaci\u00f3n en la que se basa todo el trabajo dentro de la empresa, las comunicaciones, las decisiones, lo m\u00e1s clave es ganar la confianza de los usuarios, es decir, no decepcionarlos y no caer. Porque todo el trabajo puede detenerse si algo interno no funciona.<\/p>\n
Bitrix24 como SaaS<\/h4>\n \nEl primer prototipo lo construimos un a\u00f1o antes del lanzamiento p\u00fablico, en 2011. Lo armamos en aproximadamente una semana, lo revisamos y lo manipulamos; incluso estaba funcionando. Es decir, se pod\u00eda acceder a un formulario, introducir el nombre del portal y se generaba un nuevo portal con una base de usuarios. Lo observamos, evaluamos el producto en general, lo desechamos y continuamos refin\u00e1ndolo durante todo un a\u00f1o. Porque ten\u00edamos una gran tarea: no quer\u00edamos tener dos bases de c\u00f3digo diferentes, no quer\u00edamos mantener un producto en caja por separado y soluciones en la nube, quer\u00edamos hacer todo esto dentro de un solo c\u00f3digo. <\/p>\n
Formulamos los requerimientos: esta capacidad de ser desplegados en diferentes ubicaciones, soportar replicaci\u00f3n, idealmente ubicarse en diferentes centros de datos distribuidos geogr\u00e1ficamente. Separar la l\u00f3gica del producto y el almacenamiento de datos. Ser capaz de escalar din\u00e1micamente seg\u00fan la carga, y en general, sacar la gesti\u00f3n de archivos est\u00e1ticos. A partir de estas consideraciones, se formaron, en realidad, los requerimientos del producto que estuvimos refinando durante un a\u00f1o. Durante este tiempo, en la plataforma que result\u00f3 ser \u00fanica \u2014para soluciones en caja, para nuestro propio servicio\u2014 implementamos el soporte para las cosas que necesit\u00e1bamos. Soporte de replicaci\u00f3n MySQL a nivel de producto: es decir, el desarrollador que escribe el c\u00f3digo no se preocupa de c\u00f3mo se distribuir\u00e1n sus consultas, usa nuestra API, y nosotros sabemos c\u00f3mo distribuir correctamente las consultas de escritura y lectura entre maestros y esclavos. <\/p>\n
Implementamos soporte a nivel de producto para varios almacenamiento de objetos en la nube: Google Storage, Amazon S3, adem\u00e1s del soporte para OpenStack Swift. Por lo tanto, esto fue conveniente tanto para nosotros como para el servicio, y para los desarrolladores que trabajan con la soluci\u00f3n en caja: si utilizan simplemente nuestra API para trabajar, no se preocupan de d\u00f3nde se guardar\u00e1 el archivo al final, si localmente en el sistema de archivos o si ir\u00e1 a un almacenamiento de objetos.<\/p>\n
Al final, decidimos que har\u00edamos la reserva a nivel de todo el centro de datos. En 2012, comenzamos completamente en Amazon AWS porque ya ten\u00edamos experiencia trabajando con esta plataforma: nuestro propio sitio estaba alojado all\u00ed. Nos atra\u00eda que en cada regi\u00f3n de Amazon hay varias zonas de disponibilidad - en su terminolog\u00eda, varios centros de datos que son m\u00e1s o menos independientes entre s\u00ed y nos permiten hacer reservas a nivel de todo un centro de datos: si uno falla, las bases se replican master-master, los servidores de aplicaciones web est\u00e1n reservados y la est\u00e1tica est\u00e1 almacenada en el almacenamiento de objetos S3. La carga se equilibra - en ese momento con el ELB de Amazon, pero poco despu\u00e9s llegamos a nuestros propios equilibradores de carga porque necesit\u00e1bamos una l\u00f3gica m\u00e1s compleja. <\/p>\n
Lo que quer\u00edamos, lo obtuvimos...<\/h4>\n \nTodas las cosas b\u00e1sicas que quer\u00edamos garantizar - la redundancia de los propios servidores, las aplicaciones web y las bases de datos - funcionaron bien. El escenario m\u00e1s sencillo: si alguna de nuestras aplicaciones web falla, es simple: se apagan del equilibrio de carga. <\/p>\n
Trabajamos en todo el mundo, los picos de carga de los clientes son absolutamente diferentes y, en realidad, debemos tener la capacidad de realizar ciertos trabajos de servicio con cualquier componente de nuestro sistema en cualquier momento, sin que los clientes se percaten. Por lo tanto, tenemos la posibilidad de desconectar la base de datos, redistribuyendo la carga en un segundo centro de datos. <\/p>\n
\u00bfC\u00f3mo funciona todo esto? \u2014 Redirigimos el tr\u00e1fico a un centro de datos operativo; si hay una falla en el centro de datos, se hace completamente, si son trabajos planificados en una base, desviamos parte del tr\u00e1fico que atiende a esos clientes a un segundo centro de datos, y se suspende la replicaci\u00f3n. Si necesitamos nuevas m\u00e1quinas para aplicaciones web debido al aumento de carga en el segundo centro de datos, se inician autom\u00e1ticamente. Terminamos los trabajos, se restablece la replicaci\u00f3n y devolvemos toda la carga original. Si necesitamos hacer un trabajo espejo en el segundo DC, como instalar actualizaciones del sistema o cambiar configuraciones en la segunda base de datos, repetimos todo lo mismo, simplemente en la otra direcci\u00f3n. Y si hay una falla, hacemos todo de manera simple: en el sistema de monitoreo utilizamos el mecanismo de event-handlers. Si se activan varias comprobaciones y el estado cambia a cr\u00edtico, se activa este handler, un procesador que puede ejecutar cierta l\u00f3gica. Para cada base, tenemos especificado qu\u00e9 servidor es su failover y a d\u00f3nde redirigir el tr\u00e1fico en caso de que quede inoperante. Hist\u00f3ricamente, usamos nagios o alguna de sus bifurcaciones. En principio, casi cualquier sistema de monitoreo tiene mecanismos similares; algo m\u00e1s complejo a\u00fan no lo usamos, pero quiz\u00e1s lo hagamos en el futuro. Actualmente, el monitoreo se activa ante la inaccesibilidad y tiene la capacidad de redirigir algo.<\/p>\n
\u00bfHemos reservado todo?<\/h4>\n \nTenemos muchos clientes de EE. UU., muchos clientes de Europa, y muchos clientes m\u00e1s cerca de Oriente: Jap\u00f3n, Singapur, y as\u00ed sucesivamente. Naturalmente, una gran parte de nuestros clientes est\u00e1n en Rusia. Esto significa que nuestra operaci\u00f3n no se limita a una sola regi\u00f3n. Los usuarios quieren un tiempo de respuesta r\u00e1pido, hay requisitos para cumplir con diversas leyes locales, y dentro de cada regi\u00f3n reservamos dos centros de datos, adem\u00e1s de algunos servicios adicionales que, una vez m\u00e1s, es conveniente ubicar dentro de una misma regi\u00f3n para los clientes que operan en ella. Los manejadores REST y los servidores de autorizaci\u00f3n son menos cr\u00edticos para la operaci\u00f3n del cliente en general; se pueden cambiar con una peque\u00f1a demora aceptable, pero no queremos reinventar la rueda en cuanto a c\u00f3mo monitorearlos y qu\u00e9 hacer con ellos. Por lo tanto, tratamos de aprovechar al m\u00e1ximo las soluciones ya existentes en lugar de desarrollar nuestra propia competencia en productos adicionales. Y en algunos casos, simplemente utilizamos el cambio a nivel de DNS, determinando la disponibilidad del servicio por medio del mismo DNS. En Amazon existe el servicio Route 53, pero no es solo un DNS donde se pueden agregar registros y ya est\u00e1: es mucho m\u00e1s flexible y conveniente. A trav\u00e9s de \u00e9l, se pueden construir servicios geo-distribuidos con geolocalizaciones, cuando a trav\u00e9s de \u00e9l se determina de d\u00f3nde vino el cliente y se le proporcionan ciertos registros; se pueden construir arquitecturas de failover. Los mismos health checks se configuran dentro de Route 53, donde se especifica el endpoint que se monitorea, las m\u00e9tricas y los protocolos seg\u00fan los cuales se determina la \"vitalidad\" del servicio: TCP, HTTP, HTTPS; se establece la frecuencia de las verificaciones que determinan si el servicio est\u00e1 activo o no. Y en el DNS mismo se especifica cu\u00e1l ser\u00e1 el primario, cu\u00e1l ser\u00e1 el secundario, y ad\u00f3nde cambiar si se activa el health check dentro de Route 53. Todo esto se puede hacer con otras herramientas, pero lo conveniente es que una vez configurado, luego no tenemos que pensar en c\u00f3mo se realizan las verificaciones y c\u00f3mo se lleva a cabo el cambio: todo funciona autom\u00e1ticamente.<\/p>\n
La primera \"pero\"<\/b>: \u00bfY c\u00f3mo y con qu\u00e9 respaldar el propio Route 53? No vaya a ser que algo le pase. Afortunadamente, nunca hemos tenido ese problema, pero de nuevo, tengo que contarles por qu\u00e9 pensamos que realmente es necesario hacer un respaldo. Aqu\u00ed nos estamos anticipando. Varias veces al d\u00eda hacemos una descarga completa de todas las zonas que tenemos en Route 53. La API de Amazon permite entregarlas sin problema en formato JSON, y tenemos varios servidores de respaldo donde las convertimos, las exportamos en forma de configuraciones y tenemos, grosso modo, una configuraci\u00f3n de respaldo. En caso de cualquier eventualidad, podemos desplegarla r\u00e1pidamente de forma manual, sin perder los datos de configuraci\u00f3n DNS.<\/p>\n
El segundo 'pero'<\/b>: \u00bfqu\u00e9 en esta imagen a\u00fan no est\u00e1 reservado? \u00a1El balanceador! La distribuci\u00f3n de clientes por regiones se realiza de manera muy simple. Tenemos los dominios bitrix24.ru, bitrix24.com, .de, ahora hay unos 13 diferentes que funcionan en diversas zonas. Hemos llegado a la siguiente conclusi\u00f3n: en cada regi\u00f3n hay sus propios balanceadores. Es m\u00e1s f\u00e1cil distribuir seg\u00fan las regiones, dependiendo de d\u00f3nde hay m\u00e1s carga en la red. Si hay un fallo en alg\u00fan balanceador, simplemente se saca de operaci\u00f3n y se elimina del DNS. Si hay alg\u00fan problema en el grupo de balanceadores, se reservan en otras ubicaciones y el cambio entre ellos se realiza con Route 53, porque gracias a un TTL corto, el cambio se lleva a cabo en un m\u00e1ximo de 2, 3, 5 minutos. <\/p>\n
El tercer 'pero'<\/b>: \u00bfqu\u00e9 m\u00e1s no est\u00e1 reservado? S3, correcto. Al almacenar archivos que tenemos de los usuarios en S3, cre\u00edamos sinceramente que era a prueba de balas y que no hab\u00eda necesidad de hacer reservas. Pero la historia muestra que las cosas suceden de otra manera. En general, Amazon describe S3 como un servicio fundamental, porque Amazon utiliza S3 para almacenar im\u00e1genes de m\u00e1quinas, configuraciones, im\u00e1genes AMI, instant\u00e1neas... Y si S3 falla, como sucedi\u00f3 una vez en estos 7 a\u00f1os que hemos estado usando bitrix24, arrastra con ello un mont\u00f3n de cosas: la indisponibilidad de la creaci\u00f3n de m\u00e1quinas virtuales, fallos en el funcionamiento de la API, etc. <\/p>\n
Y S3 puede fallar, como sucedi\u00f3 una vez. Por eso llegamos al siguiente esquema: hace unos a\u00f1os no hab\u00eda grandes almacenes p\u00fablicos de objetos en Rusia, y consideramos la opci\u00f3n de hacer algo propio... Afortunadamente, no comenzamos a hacerlo, porque nos habr\u00edamos enredado en una experticia que no poseemos, y seguramente habr\u00edamos cometido errores. Ahora hay almacenes compatibles con S3 de Mail.ru, Yandex y otros proveedores. Al final, llegamos a la conclusi\u00f3n de que quer\u00edamos, en primer lugar, reservaci\u00f3n, y en segundo lugar, la posibilidad de trabajar con copias locales. Para la regi\u00f3n rusa en particular, utilizamos el servicio Mail.ru Hotbox, que es compatible con S3 a trav\u00e9s de API. No necesitamos hacer grandes modificaciones en el c\u00f3digo dentro de la aplicaci\u00f3n, y hemos creado el siguiente mecanismo: en S3 hay disparadores que se activan al crear\/eliminar objetos, y Amazon tiene un servicio llamado Lambda, que es un c\u00f3digo que se ejecuta sin servidor y que se ejecutar\u00e1 precisamente cuando se activen esos disparadores.<\/p>\n
A nivel de c\u00f3digo, configuramos dos almacenamiento para cada cliente: uno es el primario y el otro es de respaldo. Si todo va bien, trabajamos con el almacenamiento m\u00e1s cercano a nosotros: es decir, nuestros clientes que est\u00e1n en Amazon utilizan S3, mientras que aquellos que operan en Rusia utilizan Hotbox. Si se activa un interruptor, debemos conectarnos a un failover, y cambiamos a los clientes a otro almacenamiento. Este interruptor puede activarse de manera independiente por regiones y podemos alternar entre ellos. En la pr\u00e1ctica, a\u00fan no lo hemos utilizado, pero hemos previsto este mecanismo y creemos que en alg\u00fan momento necesitaremos y ser\u00e1 \u00fatil este cambio. Ya ha sucedido una vez. <\/p>\n
Oh, parece que Amazon se ha escapado\u2026<\/h4>\n \nEste abril marca el aniversario del inicio de las bloqueos de Telegram en Rusia. El proveedor m\u00e1s afectado por esto fue Amazon. Y, lamentablemente, las empresas rusas que operaban a nivel mundial fueron las m\u00e1s perjudicadas. <\/p>\n
Si la empresa es global y Rusia representa solo un peque\u00f1o segmento, del 3 al 5%, de alguna manera, se puede sacrificar. <\/p>\n
Si se trata de una empresa puramente rusa, estoy seguro de que debe establecerse localmente; simplemente ser\u00e1 m\u00e1s conveniente y c\u00f3modo para los usuarios, y habr\u00e1 menos riesgos. <\/p>\n
Y si se trata de una empresa que opera a nivel global, y tiene aproximadamente la misma cantidad de clientes en Rusia que en otras partes del mundo? La conectividad de los segmentos es importante, y de alguna manera deben trabajar juntos. <\/p>\n
Tambi\u00e9n, a finales de marzo de 2018, Roskomnadzor envi\u00f3 una carta a los mayores operadores, indicando que planeaban bloquear varios millones de IP de Amazon para bloquear... el mensajero Zello. Gracias a esos proveedores, la carta fue filtrada con \u00e9xito a todos, y surgi\u00f3 la comprensi\u00f3n de que la conectividad con Amazon podr\u00eda colapsar. Era viernes, y llegamos en p\u00e1nico a nuestros colegas de servers.ru, diciendo: 'Amigos, necesitamos varios servidores que no est\u00e9n en Rusia, no en Amazon, sino, por ejemplo, en alg\u00fan lugar de \u00c1msterdam', para tener la oportunidad de establecer all\u00ed, de alguna manera, nuestros propios. vpn<\/a> y proxy para algunos endpoints, sobre los cuales no podemos influir en absoluto, como los endpoints del mismo S3; no se puede intentar levantar un nuevo servicio y obtener otra IP, necesitamos acceder a ellos de todos modos. En unos d\u00edas configuramos estos servidores, los levantamos y, en general, para el momento en que empezaron las bloqueos, ya est\u00e1bamos preparados. Es curioso que el RKNN, al ver el revuelo y la p\u00e1nico levantada, dijo: 'No, ahora mismo no vamos a bloquear nada'. (Pero eso fue justo hasta el momento en que comenzaron a bloquear Telegram.) Al configurar las posibilidades de esquivar la restricci\u00f3n y entender que no se implement\u00f3 el bloqueo, sin embargo, decidimos no deshacer todo esto. As\u00ed, por si acaso. <\/p>\n
\u00bfY c\u00f3mo se reserva\u2026 a un proveedor entero?<\/h4>\n \nActualmente no tenemos un plan en caso de un fallo total de Amazon. Sin embargo, tenemos un plan similar para Rusia. Nos alojamos en Rusia con un proveedor que elegimos para tener varias ubicaciones. Hace un a\u00f1o, nos enfrentamos a un problema: a pesar de que son dos centros de datos, ya a nivel de configuraci\u00f3n de red del proveedor pueden surgir problemas que afecten a ambos centros de datos. Y podemos experimentar falta de disponibilidad en ambas ubicaciones. Por supuesto, eso sucedi\u00f3. Al final, revisamos la arquitectura interna. No cambi\u00f3 mucho, pero ahora tenemos dos ubicaciones en Rusia, que no est\u00e1n bajo un mismo proveedor, sino en dos diferentes. Si uno falla, podemos cambiar al otro.<\/p>\n
Hipot\u00e9ticamente, para Amazon estamos considerando la posibilidad de hacer una reserva a nivel de otro proveedor; quiz\u00e1s Google, quiz\u00e1s alguien m\u00e1s... Pero hasta ahora hemos observado en la pr\u00e1ctica que si Amazon tiene fallos a nivel de una zona de disponibilidad, los fallos a nivel de toda una regi\u00f3n son bastante raros. As\u00ed que te\u00f3ricamente tenemos la idea de que podr\u00edamos hacer una reserva de \"Amazon - no Amazon\", pero en la pr\u00e1ctica eso a\u00fan no se ha realizado. <\/p>\n
Unas palabras sobre la automatizaci\u00f3n<\/h4>\n \n\u00bfSiempre se necesita automatizaci\u00f3n? Aqu\u00ed es apropiado recordar el efecto Dunning-Kruger. En el eje 'X', nuestras conocimientos y experiencia que vamos adquiriendo, y en el eje 'Y' \u2014 la confianza en nuestras acciones. Primero no sabemos nada y no estamos seguros en absoluto. Luego sabemos un poco y nos volvemos megaconfiados \u2014 este es el denominado 'pico de tonter\u00eda', bien ilustrado por la imagen 'estupidez y valent\u00eda'. Despu\u00e9s ya hemos aprendido un poco y estamos listos para entrar en acci\u00f3n. Luego pisamos algunos graves errores, caemos en el valle de la desesperaci\u00f3n, donde parece que sabemos algo, pero en realidad no sabemos mucho. Luego, a medida que adquirimos experiencia, nos volvemos m\u00e1s seguros.<\/p>\n
Conclusi\u00f3n<\/h4>\n \nEn 7 a\u00f1os hemos pasado de vivir en p\u00e1nico cuando algo fallaba, a entender que no hay problemas, solo tareas que hay que resolver. Cuando construyes un servicio, m\u00edralo desde una perspectiva general, eval\u00faa todos los riesgos que pueden surgir. Si los identificas de inmediato, prev\u00e9 el respaldo y la posibilidad de construir una infraestructura tolerante a fallos, porque cualquier punto que pueda fallar y causar un mal funcionamiento del servicio, lo har\u00e1 sin duda. Y aunque creas que algunos elementos de la infraestructura no fallar\u00e1n, como el mismo s3, ten en cuenta que pueden hacerlo. Y al menos en teor\u00eda, ten una idea de lo que har\u00e1s con ellos si algo sucede. Ten un plan para gestionar los riesgos. Cuando consideres si hacer todo autom\u00e1ticamente o manualmente, eval\u00faa los riesgos: \u00bfqu\u00e9 pasar\u00e1 si la automatizaci\u00f3n comienza a cambiar todo? \u00bfNo resultar\u00e1 eso en un panorama a\u00fan peor en comparaci\u00f3n con una aver\u00eda? Tal vez en algunos casos sea necesario encontrar un compromiso razonable entre la automatizaci\u00f3n y la reacci\u00f3n del ingeniero de guardia, quien evaluar\u00e1 la situaci\u00f3n real y decidir\u00e1 si necesita cambiar algo de inmediato o 's\u00ed, pero no ahora'.<\/p>\n
Un compromiso razonable entre el perfeccionismo y las verdaderas fuerzas, tiempo y dinero que puedes gastar en el esquema que tendr\u00e1s al final.<\/p>\n
Este texto es una versi\u00f3n ampliada y enriquecida del informe de Alexander Demidov en la conferencia Uptime d\u00eda 4<\/a><\/noindex>.<\/i> habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"\u00abBitrix24\u00bb:](\"\/wp-content\/uploads\/2019\/06\/973fa076fc654237aa869d0ecb0dae9a.jpeg\")