Las fallas son inevitables a largo plazo...
Probando de vuelta que no hay nada infalible, Hotmail, Outlook.com y SkyDrive salieron de servicio por unas horas el 12 marzo afectando a algunos usuarios.
"Heat Spike Caused Microsoft’s SkyDrive and Email Outage"
http://slashdot.org/topic/datacenter/heat-spike-caused-microsofts-skydrive-and-email-outage/
Los tiempos de tener únicamente alta disponibilidad y redundancias se acabaron
En algun momento, la visión de la arquitectura de soluciones informáticas complejas va a ir adoptando estándares y prácticas más realistas que llevar al límite tecnologico la alta disponibilidad y la redundancia. Ello implicando un costo considerablemente alto en esos límites, muchas veces sin retornar realmente beneficios prácticos en igual medida.
Por ej: Clustering masivo, múltiples datacenters, arquitecturas de hardware redundantes (múltiples equipos de networking, múltiples equipos de storage, virtualización redundante, etc. etc.).
No es que todo lo anterior no sea recomendable de implementar (u obligatorio/mandatorio en muchos casos!), sino que como solución efectiva y concreta a muchos eventos de fallas de sistemas, las mencionadas medidas - en mi experiencia - no sirven más que para tolerar niveles muy bajos de falla.
Y cuando ocurren fallas grandes en sistemas complejos (produciendo típicamente efectos cascada, dañando sistemas periféricos/secundarios, muy poco relacionados inclusive, con el punto de falla original), la altísima disponibilidad y múltiples niveles de redundancia no llegan a aportar el estado "normal y funcionando" en el sistema, que supuestamente debería haber resultado del adecuado manejo realizado por los múltiples sistemas altamente disponibles y redundantes. De hecho muchos subsistemas altamente disponibles y redundante siguen disponibles y funcionales en esos eventos, pero el sistema en sí, la unión y funcionamiento coordinado de diferentes partes con un objetivo, está fuera de servicio.
Por ende, elevar masivamente la inversión solamente en sistemas altamente disponibles y redundantes no va a poder aportar realmente y en la práctica la disponibilidad contínua de sistemas críticos complejos durante fallas graves.
Estas ideas igualmente no son nuevas, y son grandemente conocidas por muchos proveedores de sistemas públicos comerciales que basan su modelo de negocio en que esos sistemas estén siempre disponibles para sus clientes.
Por ejemplo: Hotmail, Gmail, Yahoo, Amazon (sus diferentes productos de cloud), Microsoft (sus diferentes productos de cloud), etc.
Justamente en el artículo mencionado al comienzo, un datacenter donde Microsoft tiene localizados muchos de sus servers para Hotmail, Outlook.com y SkyDrive tuvieron que ser - muy probablemente - apagados masiva e imprevistamente. Sin embargo, la mayoría de los usuarios a nivel mundial no notó problema alguno en los servicios.
"How Complex Systems Fail: A WebOps Perspective"
http://www.kitchensoap.com/2009/11/12/how-complex-systems-fail-a-webops-perspective/
"How Complex Systems Fail"
http://www.ctlab.org/documents/How%20Complex%20Systems%20Fail.pdf
Fallar constantemente, la nueva visión en el diseño de arquitecturas altamente resilientes
La visión práctica en el diseño de arquitecturas altamente resilientes, capaces de tolerar fallos graves y seguir prestando los servicios que se espera de ellas, desde 2010 en adelante se enfoca en crear sistemas capaces de recuperarse automática o semiautomáticamente, sin dejar de prestar los servicios que se supone debe proveer.
Esto se logra aplicando las diferentes tecnologías, disciplinas y experiencias aprendidas a lo largo de los años: altos niveles de disponibilidad (razonablemente planteados para evitar despilfarro gratuito), altos niveles de redundancia en hardware y software (razonablemente....etc.), sólidos sistemas de backup, monitoreo, políticas de Disaster Recovery, etc. etc.
El nuevo y a veces inesperado componente en el diseño de arquitecturas muy resilientes es el testing proactivo de todos los componentes anteriores.
Algo así como la - prehistórica - práctica de que cuando se configuraba dos servers en cluster para probar que iba a funcionar (en serio), se tiraba del cable de power de uno de los nodos para apagarlo y ver cómo reaccionaba el cluster (es decir, el otro nodo). Hoy en día esa práctica está reemplazada por la - mucho más razonable - de apagar/bajar las interfaces de red de un nodo, o a lo sumo, retirar los cables de red de los puertos físicos del server.
El testing de componentes de la arquitectura es similar, pero llevado a una potencia enésima. Se busca apagar/bajar - pseudo-aleatoriamente o aleatoriamente - uno o varios componentes en un sistema complejo. Luego de eso, se observa (examina, documenta, etc.), cómo se comporta el sistema durante esa eventualidad.
Se busca lograr una "arquitectura Rambo" (junto con sus correspondientes sistemas de soporte), capaz de resistir cualquier evento y poder tener éxito (seguir funcionando como se espera), a pesar de cualquier fallo que ocurra.
Después de eso, solamente, se entiende acerca de muchas interacciones inesperadas entre los diferentes componentes del sistema. Y luego se puede re-plantear, re-planificar las medidas de control necesarias para minimizar el fallo, y perseguir efectivamente la posibilidad de que el sistema siga funcionando.
La filosofía de diseño se resume en esta hipótesis (claramente demostrada según muchas opiniones de peso en Internet):
"La mejor manera de evitar fallas es fallar constantemente"
y
"Todo pasa por una razón, excepto por todas esas cosas que pasan completamente al azar."
Links:
"Highly Available Architecture at Netflix"
http://www.slideshare.net/AmazonWebServices/arc203-netflixha
"Working with the Chaos Monkey"
http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html
"5 Lessons We’ve Learned Using AWS"
http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html
"Web Operations"
http://en.wikipedia.org/wiki/Web_operations
Bibliografía
* Web Operations, 2010, OReilly
No hay comentarios:
Publicar un comentario