Confiabilidad en Elastic SAN
En este artículo se describe la compatibilidad con la confiabilidad de Azure Elastic SAN e incluye la resistencia regional con zonas de disponibilidad y recuperación ante desastres, y la continuidad empresarial.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.
Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.
Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.
Azure Elastic SAN admite la implementación de zonas de disponibilidad con almacenamiento con redundancia local (LRS) e implementación regional con almacenamiento con redundancia de zona (ZRS).
Requisitos previos
Las zonas LRS y ZRS para Elastic SAN sólo están disponibles actualmente en un subconjunto de regiones. Para obtener una lista de las regiones, consulte Objetivos de escalado de Elastic SAN.
Creación de un recurso mediante zonas de disponibilidad
Para crear una instancia de Elastic SAN con una zona de disponibilidad habilitada, consulte Implementación de Elastic SAN.
Experiencia a nivel de zona
Al implementar una instancia de Elastic SAN, si selecciona ZRS para la opción de redundancia de SAN, la plataforma admite la conmutación por error zonal sin intervención manual. Una instancia de Elastic SAN que usa ZRS para autorecuperarse y reequilibrarse para aprovechar las zonas correctas automáticamente.
Si ha implementado una instancia de Elastic SAN de LRS, es posible que tenga que implementar una nueva SAN mediante instantáneas exportadas a discos administrados.
Diseño de baja latencia
Las diferencias de latencia entre una instancia de Elastic SAN en LRS y una SAN elástica en ZRS no son especialmente altas. Sin embargo, para las cargas de trabajo sensibles a los picos de latencia, considere la posibilidad de usar una IA de Elastic SAN en LRS, ya que ofrece la latencia más baja.
Migración de zonas de disponibilidad
Para migrar una instancia de Elastic SAN de LR a ZRS, debe tomar una instantánea de los volúmenes de dicha SAN, exportarlos a instantáneas de disco administrado, implementar una SAN elástica en ZRS y, a continuación, crear volúmenes en SAN en ZRS mediante esas instantáneas de disco. Para obtener información sobre cómo usar instantáneas (versión preliminar), consulte Instantáneas de volúmenes de Azure Elastic SAN (versión preliminar).
Recuperación ante desastres y continuidad empresarial
La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.
En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.
Recuperación ante desastres en una región o en varias
Para Azure Elastic SAN, usted es responsable de la experiencia de recuperación ante desastres. Puede tomar instantáneas de los volúmenes y exportarlos a instantáneas de disco administrado. A continuación, puede copiar una instantánea incremental en una nueva región almacenar los datos en una región distinta de la región en la que se encuentra la SAN elástica. Debe exportar a regiones que están geográficamente distantes de la región primaria para reducir la posibilidad de que varias regiones se vean afectadas debido a un desastre.
Detección, notificación y administración de interrupciones
Puede encontrar declaraciones de interrupción en Service Health: Microsoft Azure.
Capacidad y resistencia proactiva de la recuperación ante desastres
Microsoft y sus clientes operan bajo el modelo de responsabilidad compartida. La responsabilidad compartida significa que en el caso de la DR habilitada por el cliente (servicios responsabilidad del cliente), debe abordar la DR para cualquier servicio que implemente y controle. Debe validar previamente que cualquier servicio que implemente funcionará con Elastic SAN. Para asegurarse de que la recuperación sea proactiva, debe siempre implementar previamente regiones secundarias, ya que no hay ninguna garantía de que haya capacidad en el momento del impacto para aquellos que no las hayan asignado previamente.