Romolo Tavani - stock.adobe.com

Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

Aprenda de las lecciones posteriores a la falla de Microsoft Azure

Hechos y consideraciones dadas a conocer tras el análisis de la falla de energía de los centros de datos de Azure en Estados Unidos.

Microsoft arrojó más luz sobre la gran falla de Azure que en general confirma lo que todos sabían: una tormenta cerca de la región centro sur de Azure en los Estados Unidos desconectó los sistemas de enfriamiento y apagó los sistemas, que tardaron días en recuperarse debido a problemas con la arquitectura de la plataforma en la nube.

Pero los informes también arrojan luz sobre el alcance del daño de los sistemas, las dependencias de infraestructura que paralizaron los sistemas y los planes para aumentar la capacidad de recuperación para los clientes.

Lo que sabemos ahora

La tormenta dañó el hardware. Múltiples sobretensiones y caídas de tensión en la fuente de alimentación de la red eléctrica hicieron que parte del centro de datos se transfiriera al generador de energía y desconectó el sistema de refrigeración, a pesar de la existencia de protectores de sobrevoltaje, de acuerdo con el análisis general de causa raíz (RCA) de Microsoft. Un amortiguador térmico en el sistema de enfriamiento finalmente se agotó y las temperaturas aumentaron rápidamente, lo que provocó el cierre automático de los sistemas.

Pero ese cierre no fue lo suficientemente pronto. "Se dañó una cantidad significativa de servidores de almacenamiento, así como una pequeña cantidad de dispositivos de red y unidades de potencia", según la compañía.

Microsoft ahora buscará diseños de hardware de almacenamiento más resilientes para el medio ambiente y tratará de mejorar su software para ayudar a automatizar y acelerar los esfuerzos de recuperación.

Microsoft quiere más redundancia de zona. A principios de este año, Microsoft introdujo las Zonas de disponibilidad de Azure, definidas como uno o más centros de datos físicos en una región con energía, refrigeración y redes independientes. AWS y Google ya ofrecen ampliamente estas zonas, y Azure proporciona almacenamiento redundante de zona en algunas regiones, pero no en el centro sur de los EE. UU.

Para Visual Studio Team Services (VSTS), esta fue la peor interrupción en sus siete años de historia, según la autopsia del equipo, escrita por Buck Hodges, director de ingeniería de VSTS. Diez regiones, incluida ésta afectada, alojan globalmente clientes de VSTS, y muchos de ellos no tienen zonas de disponibilidad. En el futuro, Microsoft permitirá a VSTS usar zonas de disponibilidad y moverse a cualquier región que las soporte, aunque el servicio no se moverá fuera de las regiones geográficas donde los clientes tienen requisitos de soberanía de datos específicos.

Las dependencias de servicio lastiman a todos. Varias dependencias de infraestructura y sistemas de Azure dañaron los servicios fuera de la región y ralentizaron los esfuerzos de recuperación:

  • La región centro sur de Azure es el sitio principal para Azure Service Manager (ASM), que los clientes suelen utilizar para los tipos de recursos clásicos. ASM no admite fallas automáticas, por lo que las solicitudes ASM en todas partes experimentaron latencias y fallas más altas.
  • El tráfico de autenticación de Azure Active Directory se enrutó automáticamente a otras regiones, lo que desencadenó mecanismos de aceleración y creó latencia y tiempos de espera para clientes en otras regiones.
  • Muchas regiones Azure dependen de los servicios en VSTS, lo que provocó ralentizaciones e inaccesibilidad para varios servicios relacionados.
  • Las dependencias en Azure Active Directory y los servicios de plataforma afectaron a Application Insights, según el análisis post-mortem del grupo.

Microsoft revisará estas dependencias de ASM y determinará cómo migrar los servicios a las API de Azure Resource Manager.

¿Es hora de reconsiderar las opciones de replicación? El equipo de VSTS explicó las opciones de conmutación por error: esperar la recuperación o acceder a los datos desde una copia de respaldo de solo lectura. La última opción causaría latencia y pérdida de datos, pero los usuarios de servicios como Git, Team Foundation Version Control y Build no podrían registrar, guardar o implementar el código.

La replicación síncrona evita idealmente la pérdida de datos en conmutación por error, pero en la práctica es difícil de hacer. Todos los servicios involucrados deben estar listos para enviar datos y responder en cualquier momento, y eso no es posible, dijo la compañía.

¿Lecciones aprendidas? Microsoft dijo que volverá a examinar la replicación asíncrona y explorará la geo-replicación activa para Azure SQL y Azure Storage para escribir datos de manera asíncrona en regiones primarias y secundarias, y mantener una copia lista para failover.

El equipo de VSTS también explorará cómo dejar que los clientes elijan un método de recuperación en función de si priorizan una recuperación y productividad más rápidas frente a la pérdida potencial de datos. El sistema indicará si la copia secundaria está actualizada y se reconciliará manualmente una vez que el centro de datos principal vuelva a funcionar.

Este artículo se actualizó por última vez en septiembre 2018

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close