¿Cómo se sentiría si un hermoso día de verano el centro de datos con su equipo tuviera este aspecto?
¡Hola a todos! Mi nombre es Dmitry Samsonov, trabajo como administrador de sistemas líder en "" La foto muestra uno de los cuatro centros de datos donde están instalados los equipos que sirven a nuestro proyecto. Detrás de estos muros se encuentran alrededor de 4 mil equipos: servidores, sistemas de almacenamiento de datos, equipos de red, etc. - casi ⅓ de todo nuestro equipo.
La mayoría de los servidores son Linux. También hay varias docenas de servidores en Windows (MS SQL): nuestra herencia, que hemos estado abandonando 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 sobre 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 cree. Los indicadores dentro de las salas eran normales, por lo que nuestra primera reacción fue relativamente tranquila: introdujeron una prohibición de trabajar con producción, es decir, de cualquier cambio de configuración, de implementar nuevas versiones, etc., excepto para trabajos relacionados con la reparación de algo.
Ira
¿Alguna vez ha intentado averiguar con los bomberos exactamente dónde se produjo el incendio en el tejado o subir usted mismo a un tejado 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 refrigeración.. ¿Pero llegará? El administrador del sistema de turno elimina el tráfico externo de los frentes de este centro de datos.
Actualmente, los frentes de todos nuestros servicios están duplicados en tres centros de datos, se utiliza el equilibrio a nivel DNS, lo que nos permite eliminar las direcciones de un centro de datos del DNS, protegiendo así a los usuarios de posibles problemas con el acceso a los servicios. . Si ya se han producido problemas en el centro de datos, sale de la rotación automáticamente. Puede leer más aquí:
El incendio todavía no nos ha afectado en modo alguno: ni los usuarios ni los equipos han sufrido daños. ¿Es esto un accidente? La primera sección del documento “Plan de Acción en Caso de Accidentes” define el concepto de “Accidente”, y la sección termina así:
«Si hay alguna duda sobre si hubo un accidente o no, ¡entonces es un accidente!»
14:53. Se nombra un coordinador de emergencias.
El coordinador es la persona que controla la comunicación entre todos los participantes, evalúa la magnitud del accidente, utiliza el Plan de Acción de Emergencia, atrae al personal necesario, supervisa la finalización de las reparaciones y, lo más importante, delega cualquier tarea. En otras palabras, esta es la persona que gestiona todo el proceso de respuesta a emergencias.
Trading
15:01. Comenzamos a deshabilitar servidores que no estén relacionados con la producción.
15:03. Apagamos correctamente todos los servicios reservados.
Esto incluye no solo los frentes (a los que en este momento los usuarios ya no acceden) 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 (, , , etc.).
15: 06. Se ha recibido información de que un incendio amenaza una de las salas del centro de datos. No tenemos equipo en esta sala, pero el hecho de que el fuego pueda extenderse desde el techo a los pasillos cambia enormemente la imagen de lo que está sucediendo.
(Más tarde resultó que no había ninguna amenaza física para la sala, ya que estaba herméticamente sellada desde el techo. La amenaza era sólo para el sistema de refrigeración de esta sala).
15:07. Permitimos la ejecución de comandos en servidores en modo acelerado sin comprobaciones adicionales ().
15:08. La temperatura en los pasillos está dentro de los límites normales.
15: 12. Se registró un aumento de temperatura en los pasillos.
15:13. Más de la mitad de los servidores del centro de datos están apagados. Continuemos.
15:16. Se tomó la decisión de apagar todos los equipos.
15:21. Comenzamos a apagar los servidores sin estado sin cerrar correctamente la aplicación y el sistema operativo.
15:23. Se asigna un grupo de personas responsables de MS SQL (hay pocos, la dependencia de los servicios de ellos no es grande, pero el procedimiento para restaurar la funcionalidad lleva más tiempo y es más complicado que, por ejemplo, Cassandra).
Депрессия
15: 25. Se recibió información sobre cortes de electricidad en cuatro de las 16 salas (núms. 6, 7, 8, 9). Nuestro equipamiento está ubicado en los pabellones 7 y 8. No hay información sobre nuestras dos salas (No. 1 y 3).
Por lo general, durante los incendios, la fuente de alimentación se corta inmediatamente, pero en este caso, gracias al trabajo coordinado de los bomberos y el personal técnico del centro de datos, no se cortó en todas partes y no de inmediato, sino según era necesario.
(Más tarde se descubrió que no se cortó la energía en los pasillos 8 y 9).
15:28. Estamos comenzando a implementar bases de datos MS SQL a partir de copias de seguridad en otros centros de datos.
¿Cuánto tiempo tardará? ¿Hay suficiente capacidad de red para toda la ruta?
15: 37. Se registró un corte de algunas partes de la red.
La dirección y la red de producción están físicamente aisladas 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 iniciar sesión a través de IPMI, detener la aplicación y apagar el sistema operativo. Si no existe ninguna de las redes, entonces no puedes hacer nada. “¡Gracias, Cap!”, pensarás.
“Y en general hay mucha agitación”, se podría pensar también.
El caso es que los servidores, incluso sin fuego, generan una gran cantidad de calor. Más precisamente, cuando hay refrigeración, generan calor, y cuando no hay refrigeración, crean un infierno infernal, que, en el mejor de los casos, derretirá parte del equipo y apagará otra parte, y en el peor... provocará una fuego dentro de la sala, que casi garantiza que destruirá todo.
15:39. Solucionamos problemas con la base de datos conf.
La base de datos conf es el backend del 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 funcionamiento del portal, pero el portal en sí sí puede funcionar.
15:41. Los sensores de temperatura en los equipos de la red Core registran lecturas cercanas al máximo permitido. Se trata de una caja que ocupa todo un rack y asegura 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 caso de accidente, la disponibilidad de cualquier base de conocimientos puede ser crítica.
15:50. Uno de los sistemas de vigilancia se ha desconectado.
Hay varios de ellos y son responsables de diferentes aspectos de los servicios. Algunos de ellos están configurados para operar de forma autónoma dentro de cada centro de datos (es decir, solo monitorean su propio centro de datos), otros consisten en componentes distribuidos que sobreviven de manera transparente a la pérdida de cualquier centro de datos.
En este caso dejo de funcionar , que funciona en modo maestro-espera. Cambiado al modo de espera.
Aceptación
15:51. Todos los servidores, excepto MS SQL, se apagaron a través de IPMI sin apagarse correctamente.
¿Está preparado para la gestió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. Se ha hecho todo lo que se podía hacer. Algunos compañeros pueden descansar.
16: 13. Se recibió información de que las tuberías de freón de los acondicionadores de aire estallaron en el techo, lo que retrasará la puesta en marcha del centro de datos una vez eliminado el incendio.
16:19. Según los datos recibidos del personal técnico del centro de datos, el aumento de temperatura en las salas ha cesado.
17:10. La base de datos de configuración ha sido restaurada. Ahora podemos cambiar la configuración de la aplicación.
¿Por qué es esto tan importante si todo es tolerante a fallos y funciona incluso sin un centro de datos?
En primer lugar, no todo es tolerante a fallos. Hay varios servicios secundarios que aún no han sobrevivido lo suficientemente bien a una falla del centro de datos, y hay bases de datos en modo maestro-espera. La capacidad de administrar la configuración le permite hacer todo lo necesario para minimizar el impacto de las consecuencias de un accidente en los usuarios, incluso en condiciones difíciles.
En segundo lugar, quedó claro que el funcionamiento del centro de datos no se restablecería por completo en las próximas horas, por lo que fue necesario tomar medidas para garantizar que la indisponibilidad a largo plazo de las réplicas no provocara problemas adicionales como discos llenos en los centros de datos restantes.
17:29. ¡Hora de pizza! Empleamos personas, no robots.
Rehabilitación
18:02. En los pabellones 8 (el nuestro), 9, 10 y 11 la temperatura se ha estabilizado. Uno de los que permanece fuera de línea (el número 7) alberga nuestros equipos, y allí la temperatura sigue aumentando.
18:31. Dieron el visto bueno para poner en marcha el equipo en las salas 1 y 3, que no sufrieron el incendio.
Actualmente se están lanzando servidores en las salas 1, 3, 8, comenzando por las más críticas. Se comprueba el correcto funcionamiento de todos los servicios en ejecución. Todavía hay problemas con la sala 7.
18:44. El personal técnico del centro de datos descubrió que en la sala número 7 (donde solo se encuentran nuestros equipos) muchos servidores no están apagados. Según nuestros datos, allí permanecen online 26 servidores. Tras una segunda comprobación, encontramos 58 servidores.
20:18. Los técnicos del centro de datos soplan aire a través de una habitación sin aire acondicionado a través de conductos móviles que recorren los pasillos.
23:08. El primer administrador fue enviado a casa. Alguien necesita dormir por la noche para poder seguir trabajando mañana. A continuación, lanzaremos más administradores y desarrolladores.
02:56. Lanzamos todo lo que se podía lanzar. Realizamos muchas comprobaciones de todos los servicios mediante pruebas automáticas.
03:02. Se ha restaurado el aire acondicionado en el último vestíbulo, el séptimo.
03:36. Hemos puesto en rotación los frentes del centro de datos en DNS. A partir de este momento comienza a llegar tráfico de usuarios.
Enviaremos a la mayor parte del equipo administrativo a casa. Pero dejamos atrás a algunas personas.
Pequeñas preguntas frecuentes:
P: ¿Qué pasó entre las 18:31 y las 02:56?
R: Siguiendo el “Plan de Acción ante Desastres”, lanzamos todos los servicios, empezando por los más importantes. En este caso, el coordinador en el chat entrega el servicio a un administrador gratuito, quien verifica si el sistema operativo y la aplicación se han iniciado, si hay errores y si los indicadores son normales. Una vez completado el lanzamiento, informa al chat que está libre y recibe un nuevo servicio del coordinador.
El proceso se ralentiza aún más si el hardware falla. Incluso si la detención del sistema operativo y el apagado de los servidores se realizaron correctamente, algunos servidores no regresan debido a fallas repentinas de los discos, la memoria y el chasis. Cuando se corta la energía, la tasa de fallas aumenta.
P: ¿Por qué no puedes simplemente ejecutar todo a la vez y luego arreglar lo que aparece en el monitoreo?
R: Todo debe hacerse de forma gradual, porque existen dependencias entre servicios. Y todo debe comprobarse de inmediato, sin esperar a que se realice el seguimiento, porque es mejor abordar los problemas de inmediato, sin esperar a que empeoren.
7:40. El último administrador (coordinador) se fue a la cama. Se ha completado el trabajo del primer día.
8:09. Los primeros desarrolladores, ingenieros del centro de datos y administradores (incluido el nuevo coordinador) comenzaron los trabajos de restauración.
09:37. Empezamos a levantar el salón nº 7 (el último).
Al mismo tiempo, continuamos restaurando lo que no se solucionó en otras salas: reemplazando discos/memoria/servidores, arreglando todo lo que "quema" en el monitoreo, volviendo a cambiar roles en los esquemas maestro-reserva y otras pequeñas cosas, de las cuales hay sin embargo bastante.
17:08. Permitimos todo el trabajo regular con producción.
21:45. Se completa el trabajo del segundo día.
09:45. Hoy es viernes. Todavía existen bastantes pequeños problemas en el seguimiento. Se acerca el fin de semana y todo el mundo quiere relajarse. Seguimos reparando masivamente todo lo que podemos. Se pospusieron las tareas administrativas habituales que podrían haberse pospuesto. El coordinador es nuevo.
15:40. De repente, la mitad de la pila de equipos de la red central en OTRO centro de datos se reinició. Se sacaron frentes de rotación para minimizar riesgos. No hay ningún efecto para los usuarios. Más tarde resultó que se trataba de un chasis defectuoso. El coordinador está trabajando para reparar dos accidentes a la vez.
17:17. Se restableció el funcionamiento de la red en otro centro de datos y se comprobó todo. El centro de datos se pone en rotación.
18:29. Se han finalizado los trabajos del tercer día y, en general, la restauración tras el accidente.
Epílogo
04.04.2013, , "Compañeros de clase" —Durante tres días el portal estuvo total o parcialmente indisponible. A lo largo de todo este tiempo, más de 100 personas de diferentes ciudades, de diferentes empresas (¡muchas gracias de nuevo!), de forma remota y directa en centros de datos, de forma manual y automática, repararon miles de servidores.
Hemos sacado conclusiones. Para evitar que esto vuelva a suceder, hemos realizado y seguimos realizando un intenso trabajo hasta el día de hoy.
¿Cuáles son las principales diferencias entre el accidente actual y el 404?
- Disponemos de un “Plan de Acción en Casos de Accidentes”. Una vez por trimestre realizamos ejercicios: representamos una situación de emergencia que un grupo de administradores (todos a su vez) debe eliminar mediante el "Plan de acción de emergencia". Los principales administradores de sistemas se turnan para desempeñar el papel de coordinador.
- Trimestralmente, en modo de prueba, aislamos los centros de datos (todos a su vez) a través de redes LAN y WAN, lo que nos permite identificar rápidamente los cuellos de botella.
- Menos discos rotos porque hemos endurecido las normas: menos horas de funcionamiento, umbrales más estrictos para SMART,
- Abandonamos por completo BerkeleyDB, una base de datos antigua e inestable que requería mucho tiempo para recuperarse después de reiniciar el servidor.
- Redujimos el número de servidores con MS SQL y reducimos la dependencia de los restantes.
- tenemos el nuestro , donde llevamos dos años migrando activamente todos los servicios. La nube simplifica enormemente todo el ciclo de trabajo con la aplicación y, en caso de accidente, proporciona herramientas únicas como:
- parada correcta de todas las aplicaciones con un solo clic;
- fácil migración de aplicaciones desde servidores fallidos;
- Lanzamiento automático clasificado (en orden de prioridad de servicios) de un centro de datos completo.
El accidente descrito en este artículo fue el mayor desde el día 404. Por supuesto, no todo salió bien. Por ejemplo, durante la indisponibilidad de un centro de datos dañado por un incendio en otro centro de datos, un disco en uno de los servidores falló, es decir, solo una de las tres réplicas en el clúster de Cassandra permaneció accesible, razón por la cual el 4,2% de los dispositivos móviles Los usuarios de la aplicación no pudieron iniciar sesión. Al mismo tiempo, los usuarios ya conectados continuaron trabajando. En total, como resultado del accidente, se identificaron más de 30 problemas, desde errores banales hasta deficiencias en la arquitectura del servicio.
Pero la diferencia más importante entre el accidente actual y el 404 es que mientras eliminábamos las consecuencias del incendio, los usuarios seguían enviando mensajes de texto y haciendo videollamadas a , jugaban, escuchaban música, se hacían regalos, veían vídeos, series y canales de televisión en , y también transmitido en .
¿Cómo van tus accidentes?
Fuente: habr.com