domingo, 18 de septiembre de 2011
Autorecuperación de caídas de servicios
Administrar bien y administrar mejor
La administración de sistemas puede hacerse de dos maneras: bien o mejor.
Administrar bien implica que las cosas van a funcionar del modo esperado, las tareas típicas se van a realizar y concluir efectivamente. Este es el modo estándar en que debe funcionar la administración.
Administrar mejor consiste en tomar la tecnología existente y hacerla funcionar mejor de lo que usualmente lo haría. Es por lo que se paga un extra, el motivo para contratar administradores más experimentados, el motivo por el que los buenos administradores - y los novatos con buenas perspectivas de mejorar - no dejan de leer y aprender nuevas maneras de hacer mejor las cosas.
Estuve leyendo un artículo en Slashdot, escrito por un sysadmin de Facebook donde cuenta acerca de un software inhouse, encargado de restaurar funcionalidad a servidores automáticamente, que se puso en producción en muchos servers de Facebook.
La entrada de Slashdot es un comentario sobre el artículo original, que básicamente cuenta muy poco del software inhouse, más que nada detalles de diseño. Sí menciona a los Event Handlers de Nagios como origen del actual sistema (no especifica realmente si se sigue usando Nagios, pero no se lo niega tampoco).
Eventos Recurrentes
Luego de pasar "un tiempo" con cierta infraestructura, uno descubre problemas recurrentes que no tienen solución definitiva posible (incluso habiendo sido apropiadamente tratados mediante root cause analysis). Estos problemas a veces son simples de resolver con pocos comandos o secuencias de comandos, con pocas variantes, fácilmente identificables. A veces ocurre el problema, y el sysadmin ya tiene el diagnóstico totalmente hecho en su cabeza, incluídos los comandos y acciones necesarios para remediar el downtime.
Es una circunstancia tan común en administración de sistemas que en Nagios se desarrolló una funcionalidad específica para atender proactivamente este tipo salidas de servicios (outages), los Event Handlers.
Event Handlers de Nagios
Los Event Handlers de Nagios son un ejemplo de administrar "mejor".
Usar bien esta funcionalidad de Nagios es un clásico ejemplo del monitoreo bien hecho: que debería tender a no solo a "Prevenir,Informar,Registrar" sino también a "Resolver". Una "marca registrada" de muy buena administración (y escasos downtimes por causas fáciles y rápidas de resolver).
Típicamente la tercer o cuarta fase de implementación de un sistema de monitoreo consiste en identificar esos puntos de fallo para utilizar características de recuperación automáticas disponibles en el software de monitoreo utilizado (casi siempre hay alguna).
Los Event Handlers son tremendamente capaces de hacerse cargo de recuperaciones automáticas. De hecho, el uso habitual de los Event Handlers es - dadas ciertas circunstancias - correr automáticamente los primeros comandos que correría un sysadmin en las primeras fases del troubleshooting de recuperación, de modo de acelerar la tarea de restauración de los servicios, incluso si los handlers no pudieran recuperar efectivamente la caída.
Implementar los Event Handlers es trivial, lo más difícil en realidad es detectar los patrones de caídas típicos más complejos y/o construir scripting de autodiagnóstico y remediación más efectivos (lo que implementó el sysadmin de Facebook).
Para empezar, al final tienen un par de tutoriales muy buenos.
Es la mejor manera? Sí y no.
Mirando los comentarios de Slashdot veo en una segunda mirada al tema, está bien, el approach de "levantar lo que se cae" o "arreglar EL servidor" parece un poco primitivo al lado de las arquitecturas de redundancia masiva como la de Google, donde no importa si se pierde un servidor o 50 servidores, ya que la infraestructura sigue operando sin registrar downtime alguno.
En la realidad del sysadmin promedio e incluyendo a muy buenas y caras infraestructuras, muchos servicios no están montados con redundancia masiva, inclusive, no sería viable reimplementarlos de ese modo (inviabilidad no técnica casi siempre, pero inviabilidad al fin), lo que hace - todavía al menos - necesario este tipo de mecanismos de autorecuperación muy relevantes.
Links:
Making Facebook Self-Healing
http://it.slashdot.org/story/11/09/18/0246229/Making-Facebook-Self-Healing
Troubleshooting Intermittent Problems
Usar el event handler de Nagios para recuperar servicios
Event Handlers
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario