¿Qué sentiría si, un buen día de verano, un centro de datos con su equipo se vería así?
Hola a todos! Mi nombre es Dmitry Samsonov, trabajo como administrador líder del sistema en
Odnoklassniki . La foto muestra uno de los cuatro centros de datos donde está instalado el equipo que sirve a nuestro proyecto. Detrás de estos muros hay alrededor de 4 mil unidades de equipos: servidores, sistema de almacenamiento de datos, equipos de red, etc. - Casi ⅓ de todos nuestros equipos.
La mayoría de los servidores son Linux. Hay varias docenas de servidores de Windows (MS SQL), nuestro legado, que hemos rechazado sistemáticamente durante muchos años.
Entonces, el 5 de junio de 2019 a las 14:35 los ingenieros de uno de nuestros centros de datos informaron una alarma de incendio.
Negación
14:45. Los incidentes menores de humo en los centros de datos son más comunes de lo que parecen. Los indicadores dentro de los pasillos eran normales, por lo que nuestra primera reacción fue relativamente tranquila: introdujimos la prohibición de trabajar con la producción, es decir, de cualquier cambio de configuración, lanzamiento de nuevas versiones, etc., excepto para el trabajo relacionado con la reparación de algo.
Ira
¿Alguna vez ha intentado averiguar por los bomberos exactamente dónde en el techo había un incendio, o subirse a un techo en llamas para evaluar la situación? ¿Cuál será el grado de confianza en la información recibida a través de cinco personas?
14:50.
Se ha recibido información de que el fuego se acerca al sistema de enfriamiento . ¿Pero vendrá? El administrador del sistema de servicio muestra el tráfico externo desde los frentes de este centro de datos.
Por el momento, los frentes de todos nuestros servicios están duplicados en tres centros de datos, se utiliza el equilibrio a nivel de DNS, lo que le permite eliminar las direcciones de un centro de datos de DNS, protegiendo así a los usuarios de posibles problemas con el acceso a los servicios. En el caso de que ya se hayan producido problemas en el centro de datos, abandona automáticamente la rotación. Se pueden encontrar más detalles aquí: equilibrio de carga y tolerancia a fallas en Odnoklassniki.
El fuego aún no nos ha afectado de ninguna manera, ni los usuarios ni el equipo se han visto afectados. ¿Es un accidente? La primera sección del documento "Plan de acción para accidentes" define el concepto de "Accidente", y la sección termina de la siguiente manera:
“En caso de duda, un accidente o no, ¡este es un accidente! "14:53. Se nombra un coordinador de accidentes.
Un coordinador es una persona que controla la comunicación entre todos los participantes, estima la escala del accidente, utiliza el "Plan de acción para accidentes", atrae al personal necesario, supervisa la finalización de la reparación y, lo más importante, delega cualquier tarea. En otras palabras, esta es la persona que controla todo el proceso de eliminación del accidente.
Regateo
15:01. Comenzamos a desconectar servidores que no están vinculados a la producción.
15:03. Apague todos los servicios reservados correctamente.
Esto incluye no solo frentes (que en este momento los usuarios ya no inician sesión) y sus servicios auxiliares (lógica de negocios, cachés, etc.), sino también varias bases de datos con factor de replicación 2 o más (
Cassandra ,
almacenamiento de datos binarios ,
almacenamiento en frío ,
NewSQL , etc.).
15:06.
Se ha recibido información de que un incendio amenaza uno de los pasillos del centro de datos. No tenemos equipos en esta sala, pero el hecho de que el fuego pueda extenderse desde el techo a los pasillos cambia en gran medida la imagen de lo que está sucediendo.
(Más tarde resultó que no había una amenaza física para la sala, ya que estaba aislada herméticamente del techo. La amenaza era solo para el sistema de enfriamiento de esta sala).
15:07. Permitimos la ejecución de comandos en servidores en modo acelerado sin controles adicionales (
sin nuestra calculadora favorita ).
15:08. La temperatura en las habitaciones está dentro de los límites normales.
15:12.
Se registró un aumento de la temperatura en los pasillos.15:13. Más de la mitad de los servidores en el centro de datos están apagados. Continuamos
15:16. Se decidió apagar todo el equipo.
3:21 p.m. Comenzamos a apagar los servidores sin estado sin apagar correctamente la aplicación y los sistemas operativos.
15:23. Se destaca a un grupo de responsables de MS SQL (hay pocos de ellos, la dependencia de los servicios de ellos no es muy buena, pero el procedimiento para restaurar la salud lleva más tiempo y es más complicado que, por ejemplo, Cassandra).
Depresión
15:25.
Se recibió información sobre la desconexión de la energía eléctrica en cuatro de las 16 habitaciones (No. 6, 7, 8, 9). En las salas 7 y 8 están nuestros equipos. No hay más información sobre nuestras dos habitaciones (No. 1 y 3).
Por lo general, durante los incendios, la energía se apaga inmediatamente, pero en este caso, gracias al trabajo coordinado de los bomberos y el personal técnico del centro de datos, se apagó no en todas partes y no de inmediato, pero si es necesario.
(Más tarde resultó que el poder en los pasillos 8 y 9 no se apagó).
15:28. Comenzamos a implementar bases de datos MS SQL a partir de copias de seguridad en otros centros de datos.
¿Cuánto tiempo llevará? ¿Hay suficiente ancho de banda de red para toda la ruta?
15:37.
Bloqueado algunas partes de la red.La red de gestión y producción está físicamente aislada entre sí. Si la red de producción está disponible, puede ir al servidor, detener la aplicación y apagar el sistema operativo. Si no está disponible, puede pasar por IPMI, detener la aplicación y apagar el sistema operativo. Si no hay red, no puedes hacer nada. "¡Gracias, cap!" Pensarás.
"De todos modos, hay mucha confusión", también podría pensar.
La cuestión es que los servidores, incluso sin fuego, generan una gran cantidad de calor. Más precisamente, cuando hay enfriamiento, generan calor, y cuando no hay ninguno, crean un infierno infernal, que en el mejor de los casos derretirá parte del equipo y apagará el otro, y en el peor de los casos ... causará un incendio dentro del pasillo, que casi con seguridad destruirá todo.
15:39. Solucionamos problemas con la base de datos conf.
La base de datos conf es el back-end para el servicio del mismo nombre, que utilizan todas las aplicaciones de producción para cambiar rápidamente la configuración. Sin esta base, no podemos controlar el portal, pero el portal en sí puede funcionar.
15:41. Los sensores de temperatura en el equipo de red Core registran lecturas cercanas al máximo permitido. Esta es una caja que ocupa un rack completo y garantiza el funcionamiento de todas las redes dentro del centro de datos.
15:42. El rastreador de problemas y la wiki no están disponibles, cambie al modo de espera.
Esto no es producción, pero en un accidente, la disponibilidad de cualquier base de conocimiento puede ser crítica.
15:50. Uno de los sistemas de monitoreo se ha desconectado.
Hay varios de ellos, y son responsables de varios aspectos del trabajo de los servicios. Algunos de ellos están configurados para funcionar de manera autónoma dentro de cada centro de datos (es decir, solo monitorean su centro de datos), mientras que otros consisten en componentes distribuidos que sobreviven de manera transparente a la pérdida de cualquier centro de datos.
En este caso, el
sistema para detectar anomalías en los indicadores de lógica de negocios que funciona en modo de espera maestro ha dejado de funcionar. Cambiar a modo de espera.
Aceptación
15:51. A través de IPMI, todos los servidores, excepto MS SQL, se apagaron sin un apagado correcto.
¿Está listo para la administración masiva de servidores a través de IPMI si es necesario?
El mismo momento en que se completa el rescate de equipos en el centro de datos en esta etapa. Todo lo que se pudo hacer se ha hecho. Algunos colegas pueden relajarse.
16:13.
Hubo información de que los tubos de freón de los acondicionadores de aire explotaron en el techo, lo que retrasará el lanzamiento del centro de datos después de eliminar el incendio.16:19. Según los datos recibidos del personal técnico del centro de datos, el aumento de temperatura en los pasillos se detuvo.
17:10. Restaurado el trabajo de la base de datos conf. Ahora podemos cambiar la configuración de la aplicación.
¿Por qué es tan importante si todo es tolerante a fallas y funciona incluso sin un centro de datos?
Primero, no todo es tolerante a fallas. Hay varios servicios secundarios que no sobreviven a la falla del centro de datos lo suficientemente bien, y hay bases en el modo de espera maestro. La capacidad de administrar la configuración le permite hacer todo lo necesario para minimizar el impacto de las consecuencias del accidente en los usuarios, incluso en condiciones difíciles.
En segundo lugar, quedó claro que en las próximas horas el centro de datos no se recuperará por completo, por lo que fue necesario tomar medidas para que la falta de disponibilidad a largo plazo de las réplicas no genere problemas adicionales como desbordamientos de disco en los centros de datos restantes.
17:29. Tiempo de pizza! Tenemos gente trabajando, no robots.
Rehabilitación
18:02. En las habitaciones No. 8 (la nuestra), 9, 10 y 11, la temperatura se estabilizó. En uno de los que permanecen desconectados (No. 7), nuestro equipo está ubicado y la temperatura allí continúa aumentando.
18:31. Le dieron luz verde para lanzar equipos en los pasillos n. ° 1 y 3: el fuego no afectó a estos pasillos.
Actualmente, los servidores se están lanzando en los pasillos n. ° 1, 3, 8, comenzando por los más críticos. Comprueba el correcto funcionamiento de todos los servicios en ejecución. Todavía hay problemas con la habitación 7.
18:44. El personal técnico del centro de datos descubrió que en la sala número 7 (donde solo se encuentra nuestro equipo), muchos servidores no están apagados. Según nuestros datos, 26 servidores permanecen allí. Después de volver a verificar, encontramos 58 servidores.
20:18. El personal técnico del centro de datos sopla aire en la habitación sin aire acondicionado a través de conductos móviles colocados a través de los pasillos.
23:08. Dejaron que el primer administrador se fuera a casa. Alguien necesita dormir por la noche para continuar trabajando mañana. A continuación, lanzamos otra parte de los administradores y desarrolladores.
02:56. Lanzamos todo lo que podría lanzarse. Hacemos un gran control de todos los servicios con autotest.
03:02 a.m. Aire acondicionado en el último, séptimo salón restaurado.
03:36. Pusieron los frentes en el centro de datos en rotación en el DNS. A partir de este momento, el tráfico de usuarios comienza a llegar.
Disolvemos la mayor parte del equipo de administradores del hogar. Pero dejamos algunas personas.
Pequeñas preguntas frecuentes:
P: ¿Qué pasó de 18:31 a 02:56?
R: Siguiendo el "Plan de Acción de Accidentes", lanzamos todos los servicios, comenzando por los más importantes. Al mismo tiempo, el coordinador en el chat brinda un servicio a un administrador gratuito, que verifica si el sistema operativo y la aplicación se han iniciado, si hay algún error o si los indicadores son normales. Una vez que se completa el lanzamiento, informa al chat que es gratuito y recibe un nuevo servicio del coordinador.
El proceso es inhibido adicionalmente por el hierro fallido. Incluso si el apagado del sistema operativo y el apagado de los servidores fueron correctos, algunos de los servidores no regresan debido a fallos repentinos en las unidades, la memoria o el chasis. Con una pérdida de potencia, la tasa de falla aumenta.
P: ¿Por qué no puede comenzar todo de una vez y luego reparar lo que sale del monitoreo?
R: Todo debe hacerse gradualmente, porque existen dependencias entre los servicios. Y todo debe verificarse de inmediato, sin esperar el monitoreo, porque es mejor tratar los problemas de inmediato, no esperar a que se agraven.
7:40 a.m. El último administrador (coordinador) se fue a la cama. El trabajo del primer día se completa.
8:09 a.m. Los primeros desarrolladores, ingenieros en los centros de datos y administradores (incluido el nuevo coordinador) comenzaron los trabajos de restauración.
09:37. Comenzamos a subir el pasillo número 7 (el último).
Al mismo tiempo, continuamos restaurando lo que no terminamos en otras habitaciones: reemplazando discos / memoria / servidores, arreglando todo lo que está en llamas en el monitoreo, cambio de rol inverso en circuitos de espera maestra y otras pequeñas cosas, que sin embargo son bastante.
17:08. Permitir todo el trabajo regular con la producción.
21:45. El trabajo del segundo día se completa.
09:45. Hoy es viernes Todavía hay bastantes problemas menores en el monitoreo. Antes del fin de semana, todos quieren relajarse. Continuamos reparando masivamente todo lo que es posible. Las tareas de administración regulares que podrían posponerse se posponen. El coordinador es nuevo.
15:40. De repente, la mitad de la pila Core de equipos de red en el OTRO centro de datos se reinició. Se eliminaron los frentes de la rotación para minimizar los riesgos. No hay ningún efecto para los usuarios. Más tarde resultó que era un mal chasis. El coordinador trabaja arreglando dos choques a la vez.
17:17. La red en otro centro de datos se restaura, todo se verifica. El centro de datos está en rotación.
18:29. Se completa el trabajo del tercer día y, en general, la recuperación del accidente.
Epílogo
04/04/2013,
el día del error 404 , Odnoklassniki
sobrevivió al mayor accidente : durante tres días el portal estuvo total o parcialmente inaccesible. A lo largo de este tiempo, más de 100 personas de diferentes ciudades, de diferentes compañías (¡muchas gracias de nuevo!) Remota y directamente en los centros de datos, repararon de forma manual y automática miles de servidores.
Hemos sacado conclusiones. Para evitar que esto vuelva a suceder, hemos llevado a cabo y continuamos realizando un trabajo extenso hasta nuestros días.
¿Cuáles son las principales diferencias entre el accidente actual y el 404?
- Tenemos un "Plan de acción de emergencia". Una vez por trimestre, realizamos ejercicios: desarrollamos una emergencia, que un grupo de administradores (todos a su vez) debe eliminar utilizando el "Plan de Acción de Emergencia". Los principales administradores de sistemas se turnan para desarrollar el rol de coordinador.
- Trimestralmente en modo de prueba, aísle los centros de datos (todo a su vez) a través de LAN y WAN, lo que le permite identificar cuellos de botella de manera oportuna.
- Menos unidades defectuosas, porque tenemos estándares más estrictos: menos horas de funcionamiento, umbrales más estrictos para SMART,
- BerkeleyDB completamente abandonado: una base de datos antigua e inestable que requería mucho tiempo para recuperarse del reinicio del servidor.
- Reduzca la cantidad de servidores con MS SQL y reduzca la dependencia del resto.
- Tenemos nuestra propia nube, una nube , donde hemos estado migrando activamente todos los servicios durante los últimos dos años. La nube simplifica enormemente todo el ciclo de trabajo con la aplicación y, en caso de accidente, ofrece herramientas únicas como:
- corregir detener todas las aplicaciones con un solo clic;
- migración simple de aplicaciones desde servidores fallidos;
- Clasificación automática (en orden de prioridad de servicios) lanzamiento de un centro de datos completo.
El accidente descrito en este artículo se convirtió en el más grande desde el día 404. Por supuesto, no todo salió bien. Por ejemplo, durante la falta de disponibilidad del quemador del centro de datos en otro centro de datos, un disco se bloqueó en uno de los servidores, es decir, solo una de las tres réplicas en el clúster Cassandra estaba disponible, debido a que el 4.2% de los usuarios de aplicaciones móviles no podían iniciar sesión . Al mismo tiempo, los usuarios ya conectados continuaron trabajando. En total, se identificaron más de 30 problemas según los resultados del accidente, desde errores banales hasta fallas en la arquitectura de servicio.
Pero la principal diferencia entre el accidente actual y el 404 es que, si bien eliminamos las consecuencias del incendio, los usuarios aún correspondían y hacían videollamadas en
Tamtam , jugaban, escuchaban música, se daban regalos, veían videos, programas de televisión y canales de televisión en
OK , y también transmitido a
OK Live .
¿Cómo van tus accidentes?