{"id":84108,"date":"2020-06-05T07:42:44","date_gmt":"2020-06-05T05:42:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra"},"modified":"2020-06-05T07:42:44","modified_gmt":"2020-06-05T05:42:44","slug":"tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","title":{"rendered":"\u00bfDeber\u00edamos \"apagar\" los servidores si el test de humo del centro de datos \"enciende\" una alerta?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00bfQu\u00e9 sentir\u00edas si en un hermoso d\u00eda de verano el centro de datos con tu equipo se viera as\u00ed?<\/p>\n

\"\u00bfDeber\u00edamos
\n
\n\u00a1Hola a todos! Me llamo Dmitry Samsonov, trabajo como administrador de sistemas senior en \u201cOdnoklassniki<\/a><\/noindex>\u201d. En la foto se muestra uno de los cuatro centros de datos donde se encuentra el equipo que da soporte a nuestro proyecto. Detr\u00e1s de estas paredes hay alrededor de 4,000 unidades de hardware: servidores, sistemas de almacenamiento de datos, equipos de red, etc. \u2014 casi \u2153 de todo nuestro equipo.
\nLa mayor\u00eda de los servidores son Linux. Tambi\u00e9n hay varias docenas de servidores en Windows (MS SQL) \u2014 nuestro legado, del que nos hemos estado deshaciendo lentamente durante muchos a\u00f1os.
\nAs\u00ed que, 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.
\n<\/a><\/noindex><\/p>\n

Negaci\u00f3n<\/h4>\n

\n14:45. Los peque\u00f1os incidentes de humo en los centros de datos ocurren m\u00e1s a menudo de lo que parece. Los indicadores dentro de los salones estaban dentro de lo normal, as\u00ed que nuestra primera reacci\u00f3n fue relativamente tranquila: se impuso una prohibici\u00f3n de trabajos en producci\u00f3n, lo que significa que no se har\u00edan cambios en las configuraciones, despliegues de nuevas versiones, etc., excepto los trabajos relacionados con la reparaci\u00f3n de algo.<\/p>\n

Ira<\/h4>\n

\n\u00bfAlguna vez has intentado preguntarle a los bomberos d\u00f3nde exactamente en el techo ocurri\u00f3 el incendio, o tratar de subir a un techo en llamas para evaluar la situaci\u00f3n? \u00bfQu\u00e9 nivel de confianza tendr\u00edas en la informaci\u00f3n obtenida a trav\u00e9s de cinco personas?<\/p>\n

14:50. Se recibi\u00f3 informaci\u00f3n de que el fuego se estaba acercando al sistema de refrigeraci\u00f3n<\/b>. Pero, \u00bfllegar\u00e1? El administrador de sistemas de guardia est\u00e1 sacando el tr\u00e1fico externo de los frentes de este centro de datos.<\/p>\n

En este momento, los frentes de todos nuestros servicios est\u00e1n duplicados en tres centros de datos, se utiliza balanceo a nivel de DNS, lo que permite eliminar las direcciones de un centro de datos del DNS, blindando as\u00ed a los usuarios de posibles problemas de acceso a los servicios. En caso de que ya hayan ocurrido problemas en el centro de datos, autom\u00e1ticamente saldr\u00e1 de la rotaci\u00f3n. Puedes leer m\u00e1s sobre esto aqu\u00ed: Balanceo de carga y tolerancia a fallos en \u2018VKontakte\u2019.<\/a><\/noindex><\/p><\/blockquote>\n

\nEl incendio a\u00fan no nos ha afectado de ninguna manera: ni los usuarios ni el equipo han sufrido da\u00f1os. \u00bfEs esto un accidente? La primera secci\u00f3n del documento \u201cPlan de acci\u00f3n en caso de emergencia\u201d define el t\u00e9rmino \u201cAccidente\u201d, y la secci\u00f3n termina as\u00ed:
\n\u00abSi hay dudas, si es un accidente o no, \u00a1entonces es un accidente!<\/u>\u00bb<\/b><\/p>\n

14:53. Se designa al coordinador de emergencia.<\/p>\n

El coordinador es la persona que controla la comunicaci\u00f3n entre todos los participantes, eval\u00faa la magnitud de la emergencia, utiliza el \u00abPlan de acci\u00f3n en caso de emergencia\u00bb, convoca al personal necesario, supervisa la finalizaci\u00f3n de las reparaciones y, lo m\u00e1s importante, delega cualquier tarea. En otras palabras, es la persona que gestiona todo el proceso de resoluci\u00f3n de la emergencia.<\/p><\/blockquote>\n

<\/p>\n

Subasta<\/h4>\n

\n15:01. Comenzamos a desconectar los servidores que no est\u00e1n relacionados con la producci\u00f3n.
\n15:03. Apagamos correctamente todos los servicios reservados.
\nEsto incluye no solo los frontales (a los que los usuarios ya no acceden en este momento) y sus servicios auxiliares (l\u00f3gica de negocio, cach\u00e9s, etc.), sino tambi\u00e9n diversas bases de datos con un factor de replicaci\u00f3n de 2 o m\u00e1s (Cassandra<\/a><\/noindex>, almacenamiento de datos binarios<\/a><\/noindex>, almacenamiento en fr\u00edo<\/a><\/noindex>, NewSQL<\/a><\/noindex> y otros).
\n15:06. Se recibi\u00f3 informaci\u00f3n de que un incendio amenaza una de las salas del centro de datos.<\/b> En esta sala no tenemos equipos, pero el hecho de que el fuego pueda propagarse desde el techo hacia las salas cambia dr\u00e1sticamente la situaci\u00f3n.
\n(M\u00e1s tarde se descubri\u00f3 que no hab\u00eda una amenaza f\u00edsica para la sala, ya que est\u00e1 herm\u00e9ticamente aislada del techo. La amenaza era solo para el sistema de refrigeraci\u00f3n de esta sala.)
\n15:07. Se permite la ejecuci\u00f3n de comandos en los servidores en modo acelerado sin verificaciones adicionales (sin nuestra calculadora favorita<\/a><\/noindex>).
\n15:08. La temperatura en las salas est\u00e1 dentro de la norma.
\n15:12. Se ha registrado un aumento de temperatura en las salas.<\/b>
\n15:13. M\u00e1s de la mitad de los servidores en el centro de datos est\u00e1n apagados. Continuamos.
\n15:16. Se toma la decisi\u00f3n de apagar todo el equipo.
\n15:21. Comenzamos a desconectar la alimentaci\u00f3n en servidores sin estado sin un apagado correcto de la aplicaci\u00f3n y del sistema operativo.
\n15:23. Se designa un grupo responsable para MS SQL (son pocos, la dependencia de los servicios de ellos no es grande, pero el procedimiento para restaurar la funcionalidad lleva m\u00e1s tiempo y es m\u00e1s complicado que, por ejemplo, con Cassandra).<\/p>\n

Depresi\u00f3n<\/h4>\n

\n15:25. Se recibi\u00f3 informaci\u00f3n de que se apag\u00f3 la alimentaci\u00f3n en cuatro salas de 16 (n\u00fameros 6, 7, 8, 9).<\/b> En las salas 7 y 8 se encuentra nuestro equipo. No tenemos informaci\u00f3n sobre otras dos de nuestras salas (n\u00fameros 1 y 3).
\nGeneralmente, en casos de incendios, la alimentaci\u00f3n el\u00e9ctrica se apaga de inmediato, pero en este caso, gracias al trabajo coordinado de los bomberos y al personal t\u00e9cnico del centro de datos, no se apag\u00f3 en todos lados y no de inmediato, sino seg\u00fan fue necesario.
\n(Se descubri\u00f3 m\u00e1s tarde que la alimentaci\u00f3n en las salas 8 y 9 no se hab\u00eda apagado.)
\n15:28. Comenzamos a desplegar las bases MS SQL desde copias de seguridad en otros centros de datos.
\n\u00bfCu\u00e1nto tiempo tomar\u00e1 esto? \u00bfSer\u00e1 suficiente el ancho de banda de la red en todo el recorrido?
\n15:37. Se ha registrado la desconexi\u00f3n de algunos tramos de la red.<\/b>
\nLa gesti\u00f3n y la red de producci\u00f3n est\u00e1n f\u00edsicamente aisladas entre s\u00ed. Si la red de producci\u00f3n est\u00e1 disponible, puede acceder al servidor, detener la aplicaci\u00f3n y apagar el sistema operativo. Si no est\u00e1 disponible, puede acceder a trav\u00e9s de IPMI, detener la aplicaci\u00f3n y apagar el sistema operativo. Si ninguna de las redes est\u00e1 disponible, no puede hacer nada. \"\u00a1Gracias, capit\u00e1n!\", podr\u00eda pensar.
\n\"Y en general, hay demasiada confusi\u00f3n\", podr\u00eda pensar tambi\u00e9n.
\nLa cuesti\u00f3n es que los servidores generan una gran cantidad de calor incluso sin un incendio. M\u00e1s precisamente, cuando hay refrigeraci\u00f3n, generan calor, y cuando no la hay, crean un infierno que, en el mejor de los casos, derretir\u00e1 parte del equipo y apagar\u00e1 otra parte, y en el peor de los casos... provocar\u00e1 un incendio dentro de la sala, que pr\u00e1cticamente destruir\u00e1 todo.<\/p>\n

\"\u00bfDeber\u00edamos
\n
\n15:39. Registramos problemas con la base conf.<\/p>\n

La base conf es el backend para el servicio del mismo nombre, que es utilizado por todas las aplicaciones de producci\u00f3n para cambiar la configuraci\u00f3n de manera operativa. Sin esta base, no podemos gestionar el funcionamiento del portal, pero el portal puede seguir funcionando.<\/p><\/blockquote>\n

\n15:41. Los sensores de temperatura en el equipo de red Core registran lecturas cercanas a los l\u00edmites permitidos. Es una caja que ocupa un rack entero y asegura el funcionamiento de todas las redes dentro del centro de datos.<\/p>\n

\"\u00bfDeber\u00edamos
\n
\n15:42. El rastreador de problemas y la wiki no est\u00e1n disponibles, pasamos a standby.
\nEsto no es producci\u00f3n, pero durante un accidente, la disponibilidad de cualquier base de conocimiento puede ser cr\u00edtica.
\n15:50. Uno de los sistemas de monitoreo se apag\u00f3.
\nHay varios, y son responsables de diferentes aspectos del funcionamiento de los servicios. Algunos de ellos est\u00e1n configurados para funcionar de manera aut\u00f3noma dentro de cada centro de datos (es decir, monitorean solo su centro de datos), otros constan de componentes distribuidos que manejan de manera transparente la p\u00e9rdida de cualquier centro de datos.
\nEn este caso dej\u00f3 de funcionar el sistema de detecci\u00f3n de anomal\u00edas en los indicadores de la l\u00f3gica empresarial<\/a><\/noindex>, que opera en modo master-standby. Cambiamos a standby.<\/p>\n

Aceptaci\u00f3n<\/h4>\n

\n15:51. A trav\u00e9s de IPMI se apagaron todos los servidores sin una correcta finalizaci\u00f3n del trabajo, excepto MS SQL.
\n\u00bfEst\u00e1s listo para la gesti\u00f3n masiva de servidores a trav\u00e9s de IPMI si es necesario?<\/p>\n

Ese momento cuando el rescate del equipamiento en el centro de datos ha finalizado. Todo lo que se pod\u00eda hacer, se ha hecho. Algunos colegas pueden descansar.<\/i>
\n16:13. Se ha recibido informaci\u00f3n de que los tubos de refrigerante de los aires acondicionados en el techo se han roto, lo que retrasar\u00e1 el inicio del centro de datos despu\u00e9s de extinguida la incendio.<\/b>
\n16:19. Seg\u00fan la informaci\u00f3n proporcionada por el personal t\u00e9cnico del centro de datos, se ha detenido el aumento de temperatura en las salas.
\n17:10. Se ha restaurado el funcionamiento de la base conf. Ahora podemos cambiar la configuraci\u00f3n de las aplicaciones.
\n\u00bfPor qu\u00e9 es esto tan importante, si todo es tolerante a fallos y funciona incluso sin un centro de datos?
\nEn primer lugar, no todo es tolerante a fallos. Hay diversos servicios secundarios que a\u00fan no sobreviven lo suficientemente bien a la falla de un centro de datos, y hay bases en modo maestro-esclavo. La capacidad de gestionar configuraciones permite hacer todo lo necesario para minimizar el impacto de las consecuencias de un fallo en los usuarios, incluso en condiciones dif\u00edciles.
\nEn segundo lugar, se ha vuelto claro que en las pr\u00f3ximas horas el funcionamiento del centro de datos no se restablecer\u00e1 por completo, por lo que era necesario tomar medidas para que la larga indisponibilidad de las r\u00e9plicas no condujera a problemas adicionales como el desbordamiento de discos en los centros de datos restantes.
\n17:29. \u00a1Es hora de pizza! Tenemos personas trabajando, no robots.<\/p>\n

\"\u00bfDeber\u00edamos
\n<\/p>\n

Rehabilitaci\u00f3n<\/h4>\n

\n18:02. La temperatura en las salas 8 (la nuestra), 9, 10 y 11 se ha estabilizado. En una de las que permanecen desconectadas (la 7), se encuentra nuestro equipo y la temperatura sigue aumentando.
\n18:31. Se ha dado la aprobaci\u00f3n para el encendido del equipo en las salas 1 y 3 \u2014 estas salas no fueron afectadas por el incendio.<\/p>\n

En este momento se est\u00e1n iniciando los servidores en las salas 1, 3 y 8, comenzando por los m\u00e1s cr\u00edticos. Se est\u00e1 verificando el correcto funcionamiento de todos los servicios iniciados. A\u00fan hay problemas con la sala 7.<\/i><\/p>\n

18:44. El personal t\u00e9cnico del centro de datos descubri\u00f3 que en la sala 7 (donde s\u00f3lo est\u00e1 nuestro equipo) muchos servidores no est\u00e1n apagados. Seg\u00fan nuestros datos, hay 26 servidores encendidos. Tras una segunda verificaci\u00f3n, encontramos 58 servidores.
\n20:18. El personal t\u00e9cnico del centro de datos est\u00e1 ventilando el aire en la sala sin aires acondicionados a trav\u00e9s de conductos m\u00f3viles colocados por los pasillos.
\n23:08. Se envi\u00f3 a casa al primer administrador. Alguien debe dormir por la noche para continuar con los trabajos ma\u00f1ana. Luego, enviamos a casa a m\u00e1s administradores y desarrolladores.
\n02:56. Hemos lanzado todo lo que se pod\u00eda activar. Hacemos una gran verificaci\u00f3n de todos los servicios con pruebas autom\u00e1ticas.<\/p>\n

\"\u00bfDeber\u00edamos
\n
\n03:02. El aire acondicionado en la \u00faltima sala, la s\u00e9ptima, ha sido restaurado.
\n03:36. Hemos a\u00f1adido los frontales en el centro de datos a la rotaci\u00f3n en DNS. A partir de este momento, comenzar\u00e1 a llegar tr\u00e1fico de usuarios.
\nEstamos despidiendo a la mayor parte del equipo de administradores. Pero dejamos a algunas personas.<\/p>\n

Peque\u00f1o FAQ:
\nP: \u00bfQu\u00e9 sucedi\u00f3 entre las 18:31 y las 02:56?
\nR: Siguiendo el \u2018Plan de Acci\u00f3n en Caso de Emergencia\u2019, activamos todos los servicios, comenzando por los m\u00e1s importantes. Mientras tanto, el coordinador en el chat asigna un servicio a un administrador libre, quien verifica si el sistema operativo y la aplicaci\u00f3n se han iniciado, si hay errores y si los par\u00e1metros est\u00e1n normales. Despu\u00e9s de completar el lanzamiento, informa en el chat que est\u00e1 libre y recibe un nuevo servicio del coordinador.
\nEl proceso se retrasa a\u00fan m\u00e1s por un hardware que ha fallado. Incluso si la detenci\u00f3n del sistema operativo y el apagado de los servidores se realizaron correctamente, algunos servidores no regresan debido a discos, memoria o chasis que han fallado repentinamente. Al perder la alimentaci\u00f3n, el porcentaje de fallas aumenta.
\nP: \u00bfPor qu\u00e9 no se puede simplemente iniciar todo de una vez y luego reparar lo que surja en el monitoreo?
\nR: Todo debe hacerse gradualmente, porque hay dependencias entre los servicios. Y se debe verificar todo de inmediato, sin esperar el monitoreo, porque es mejor abordar los problemas de inmediato y no esperar a que se agraven.<\/p><\/blockquote>\n

\n7:40. El \u00faltimo administrador (coordinador) se fue a dormir. Los trabajos del primer d\u00eda han finalizado.
\n8:09. Los primeros desarrolladores, ingenieros en los centros de datos y administradores (incluido el nuevo coordinador) han comenzado las labores de restauraci\u00f3n.
\n09:37. Hemos comenzado a levantar la sala N\u00ba 7 (la \u00faltima).
\nParalelamente, continuamos restaurando lo que no se complet\u00f3 en otras salas: reemplazo de discos\/memoria\/servidores, reparaci\u00f3n de todo lo que \u2018est\u00e1 fallando\u2019 en el monitoreo, conmutaci\u00f3n inversa de roles en los esquemas de master-standby y otras peque\u00f1as cosas, de las cuales, sin embargo, hay bastante.
\n17:08. Permitimos todas las operaciones rutinarias con producci\u00f3n.
\n21:45. Los trabajos del segundo d\u00eda han finalizado.
\n09:45. Hoy es viernes. En el monitoreo a\u00fan hay bastantes problemas menores. Ya se acercan el fin de semana, todos quieren descansar. Seguimos reparando masivamente todo lo que se puede. Las tareas administrativas que se pod\u00edan posponer han sido pospuestas. Hay un nuevo coordinador.
\n15:40. De repente se reinici\u00f3 la mitad del stack de equipos de red en OTRO centro de datos. Sacamos de la rotaci\u00f3n los frontes para minimizar riesgos. No hubo impacto para los usuarios. M\u00e1s tarde se descubri\u00f3 que fue un chasis defectuoso. El coordinador est\u00e1 trabajando en reparar dos fallas a la vez.
\n17:17. El funcionamiento de la red en otro centro de datos ha sido restaurado, todo ha sido verificado. El centro de datos ha sido incorporado de nuevo a la rotaci\u00f3n.
\n18:29. El trabajo del tercer d\u00eda y, en general, la recuperaci\u00f3n tras la falla han sido completados.<\/p>\n

P\u00f3scrito<\/h4>\n

\n04.04.2013, en el d\u00eda del error 404,<\/a><\/noindex>\u00abVKontakte\u00bb sufri\u00f3 la mayor ca\u00edda,<\/a><\/noindex> durante tres d\u00edas el portal estuvo totalmente o parcialmente inaccesible. A lo largo de este tiempo, m\u00e1s de 100 personas de diferentes ciudades y compa\u00f1\u00edas (\u00a1muchas gracias de nuevo!), trabajaron de forma remota y directamente en los centros de datos, arreglando miles de servidores de manera manual y autom\u00e1tica.
\nHemos tomado lecciones. Para que esto no vuelva a suceder, hemos realizado y seguimos realizando trabajos extensos.<\/p>\n

\u00bfCu\u00e1les son las principales diferencias entre la falla actual y la 404?<\/p>\n