Planeamiento y conmutación por error de recuperación ante desastres de Azure Storage

  • Artículo

Microsoft se esfuerza por garantizar que los servicios de Azure siempre estén disponibles. Sin embargo, es posible que se produzcan interrupciones en el servicio. Entre los componentes clave de un buen plan de recuperación ante desastres, se incluyen estrategias para lo siguiente:

Este artículo se centra en la conmutación por error para las cuentas de almacenamiento con redundancia global (GRS, GZRS y RA-GZRS) y en cómo diseñar las aplicaciones para que tengan alta disponibilidad si hay una interrupción y una conmutación por error posterior.

Elección de la opción de redundancia correcta

Azure Storage mantiene varias copias de la cuenta de almacenamiento para garantizar su durabilidad y alta disponibilidad. La opción de redundancia que elija para la cuenta depende del grado de resistencia que necesite para las aplicaciones.

Con el almacenamiento con redundancia local (LRS), se almacenan y replican automáticamente tres copias de la cuenta de almacenamiento en un único centro de datos. Con el almacenamiento con redundancia de zona (ZRS), se almacena y replica una copia en cada una de las tres zonas de disponibilidad independientes dentro de la misma región. Para más información sobre las zonas de disponibilidad, consulte Zonas de disponibilidad de Azure.

La recuperación de una sola copia de una cuenta de almacenamiento se produce automáticamente con LRS y ZRS.

Almacenamiento con redundancia global y conmutación por error

Con el almacenamiento con redundancia global (GRS, GZRS y RA-GZRS), Azure copia los datos de forma asincrónica en una región geográfica secundaria que se encuentre al menos a cientos de kilómetros de distancia. Esto le permite recuperar los datos si hay una interrupción en la región primaria. Una característica que distingue al almacenamiento con redundancia global con respecto a LRS y ZRS es la capacidad de conmutar por error en la región secundaria si hay una interrupción en la región primaria. El proceso de conmutación por error actualiza las entradas DNS de los puntos de conexión de servicio de la cuenta de almacenamiento de forma que los puntos de conexión de la región secundaria se conviertan en los nuevos puntos de conexión principales de la cuenta de almacenamiento. Una vez finalizada la conmutación por error, los clientes pueden empezar a escribir en los nuevos puntos de conexión principales.

Las configuraciones de redundancia RA-GRS y RA-GZRS proporcionan almacenamiento con redundancia geográfica con la ventaja adicional del acceso de lectura al punto de conexión secundario si hay una interrupción en la región primaria. Si se produce una interrupción en el punto de conexión principal, las aplicaciones configuradas para acceso de lectura en la región secundaria y diseñadas para la alta disponibilidad pueden seguir leyendo desde el punto de conexión secundario. Microsoft recomienda RA-GZRS para obtener la máxima disponibilidad y durabilidad de las cuentas de almacenamiento.

Para más información sobre la redundancia, consulte Redundancia de Azure Storage.

Planeamiento de la conmutación por error de la cuenta de almacenamiento

Las cuentas de Azure Storage admiten dos tipos de conmutación por error:

1 La conmutación por error administrada por Microsoft no se puede iniciar para cuentas de almacenamiento, suscripciones o inquilinos individuales. Para obtener más información, consulte Conmutación por error administrada por Microsoft.
2 El plan de recuperación ante desastres se debe basar en la conmutación por error administrada por el cliente. No confíe en la conmutación por error administrada por Microsoft, que solo se utilizaría en circunstancias extremas.

Cada tipo de conmutación por error tiene un conjunto único de casos de uso, las expectativas correspondientes para la pérdida de datos y la compatibilidad con cuentas con un espacio de nombres jerárquico habilitado (Azure Data Lake Storage Gen2). En esta tabla, se resumen los aspectos de cada tipo de conmutación por error:

Tipo Ámbito de la conmutación por error Caso de uso Pérdida de datos esperada Compatibilidad con HNS
Administrada por el cliente Cuenta de almacenamiento Los puntos de conexión de servicio de almacenamiento de la región primaria dejan de estar disponibles, pero la región secundaria está disponible.

Ha recibido un aviso de Azure en el que Microsoft le aconseja realizar una operación de conmutación por error de las cuentas de almacenamiento potencialmente afectadas por una interrupción.		 Sí Sí (en versión preliminar)
Administrado por Microsoft Toda la región o unidad de escalado La región primaria deja de estar disponible por completo debido a un desastre significativo, pero la región secundaria está disponible. Sí Sí

Conmutación por error administrada por el cliente

Si los puntos de conexión de datos de los servicios de almacenamiento de la cuenta de almacenamiento dejan de estar disponibles en la región primaria, puede conmutar por error a la región secundaria. Una vez completada la conmutación por error, la región secundaria se convierte en la nueva primaria y los usuarios pueden continuar con el acceso a los datos en la nueva región primaria.

Para comprender completamente el impacto que tendría la conmutación por error de la cuenta administrada por el cliente en los usuarios y las aplicaciones, resulta útil saber lo que sucede durante cada paso del proceso de conmutación por error y conmutación por recuperación. Para obtener más información sobre cómo funciona el proceso, consulte Funcionamiento de la conmutación por error de la cuenta de almacenamiento administrada por el cliente.

Conmutación por error administrada por Microsoft

En circunstancias extremas en las que la región primaria original se considera irrecuperable dentro de un período razonable de tiempo debido a un desastre importante, Microsoft puede iniciar una conmutación por error regional. En este caso, no se requieren acciones por su parte. No tendrá acceso de escritura a la cuenta de almacenamiento hasta que se complete la conmutación por error administrada por Microsoft. Las aplicaciones pueden leer de la región secundaria si la cuenta de almacenamiento está configurada para RA-GRS o RA-GZRS.

Importante

El plan de recuperación ante desastres se debe basar en la conmutación por error administrada por el cliente. No confíe en la conmutación por error administrada por Microsoft, que solo se utilizaría en circunstancias extremas. Se iniciaría una conmutación por error administrada por Microsoft para una unidad física completa, como una región o una unidad de escalado. No se puede iniciar para cuentas de almacenamiento, suscripciones o inquilinos individuales. Para poder conmutar por error de forma selectiva las cuentas de almacenamiento individuales, use la conmutación por error de la cuenta administrada por el cliente.

Anticipación de la pérdida de datos y de las incoherencias

Precaución

La conmutación por error de la cuenta de almacenamiento suele implicar cierta pérdida de datos y posibles incoherencias de archivos y datos. En el plan de recuperación ante desastres, es importante tener en cuenta el impacto que tendría una conmutación por error de la cuenta en los datos antes de iniciar una.

Como los datos se escriben de manera asincrónica desde la región primaria a la secundaria, siempre se produce un retraso antes de que una escritura en la región primaria se copie en la secundaria. Si la región primaria deja de estar disponible, puede que las escrituras más recientes todavía no se hayan copiado en la secundaria.

Cuando se produce una conmutación por error, todos los datos de la región primaria se pierden, ya que la región secundaria se convierte en la nueva primaria. Todos los datos ya copiados en la región secundaria se conservan cuando se produce la conmutación por error. Sin embargo, los datos escritos en la región primaria que no se hayan copiado en la región secundaria se pierden de forma permanente.

La nueva región primaria está configurada para tener redundancia local (LRS) después de la conmutación por error.

También puede experimentar incoherencias de archivos o datos si las cuentas de almacenamiento tienen una o varias de las siguientes opciones habilitadas:

Hora de la última sincronización

La propiedad Last Sync Time indica la hora más reciente en que se garantiza que los datos de la región primaria se escribieron en la secundaria. Para las cuentas que tienen un espacio de nombres jerárquico, la misma propiedad Hora de última sincronización también se aplica a los metadatos administrados por el espacio de nombres jerárquico, incluidas las ACL. Todos los datos y metadatos escritos antes de la hora de la última sincronización están disponibles en la región secundaria, mientras que es posible que los datos y metadatos escritos después de la hora de la última sincronización no se hayan escrito en la secundaria y pueden haberse perdido. Use esta propiedad si hay una interrupción para calcular la cantidad de datos perdidos que puede haber al iniciar una conmutación por error de la cuenta.

Como procedimiento recomendado, diseñe la aplicación para que pueda usar la hora de la última sincronización para evaluar la pérdida de datos esperada. Por ejemplo, si registra todas las operaciones de escritura, puede comparar la hora de las últimas operaciones de escritura con la hora de la última sincronización para determinar las escrituras que no se sincronizaron en la región secundaria.

Para obtener más información sobre cómo comprobar la propiedad Hora de la última actualización, consulte Comprobación de la propiedad Hora de la última sincronización de una cuenta de almacenamiento.

Coherencia de archivos para Azure Data Lake Storage Gen2

La replicación de cuentas de almacenamiento con un espacio de nombres jerárquico habilitado (Azure Data Lake Storage Gen2) se produce en el nivel de archivo. Esto significa que si se produce una interrupción en la región primaria, es posible que solo algunos de los archivos de un contenedor o directorio se hayan replicado correctamente en la región secundaria. No se garantiza la coherencia de todos los archivos de un contenedor o directorio después de una conmutación por error de una cuenta de almacenamiento.

Incoherencias de la fuente de cambios y los datos de blobs

La conmutación por error de la cuenta de almacenamiento con redundancia geográfica con la fuente de cambios habilitada puede provocar incoherencias entre los registros de la fuente de cambios y los datos o metadatos de los blobs. Estas incoherencias pueden deberse a la naturaleza asincrónica de ambas actualizaciones a los registros de cambios y a la replicación de datos de blobs desde la región primaria a la secundaria. La única situación en la que no se esperarían incoherencias se produce cuando todos los registros de registro actuales se han vaciado correctamente en los archivos de registro y todos los datos de almacenamiento se han replicado correctamente desde la región primaria a la secundaria.

Para obtener información sobre cómo funciona la fuente de cambios, consulte Funcionamiento de la fuente de cambios.

Tenga en cuenta que otras características de la cuenta de almacenamiento requieren que la fuente de cambios esté habilitada, como la copia de seguridad operativa de Azure Blob Storage, la replicación de objetos y la restauración a un momento dado para blobs en bloques.

Incoherencias de la restauración a un momento dado

La conmutación por error administrada por el cliente es compatible con cuentas de almacenamiento de nivel estándar v2 de uso general que incluyen blobs en bloques. No obstante, al realizar una conmutación por error administrada por el cliente en una cuenta de almacenamiento, se restablece el punto de restauración más temprano posible la cuenta. Los datos para la restauración a un momento dado de los blobs en bloques solo son coherentes con el tiempo de finalización de la conmutación por error. Como resultado, solo puede restaurar blobs en bloques a un momento dado no anterior a la hora de finalización de la conmutación por error. Puede comprobar el tiempo de finalización de la conmutación por error en la pestaña redundancia de la cuenta de almacenamiento en Azure Portal.

Por ejemplo, supongamos que ha establecido el período de retención en 30 días. Si han transcurrido más de 30 días desde la conmutación por error, puede restaurar a cualquier punto dentro de esos 30 días. Sin embargo, si hubieran transcurrido menos de 30 días desde la conmutación por error, no podrá restaurar a un punto anterior a la conmutación por error, independientemente del período de retención. Por ejemplo, si han pasado 10 días desde la conmutación por error, el punto de restauración más temprano posible es 10 días en el pasado, no 30.

Tiempo y costo de la conmutación por error

El tiempo que tarda la conmutación por error en completarse después de iniciarse puede variar, aunque normalmente tarda menos de una hora.

Una conmutación por error administrada por el cliente pierde su redundancia geográfica después de una conmutación por error (y conmutación por recuperación). La cuenta de almacenamiento se convierte automáticamente en almacenamiento con redundancia local (LRS) en la nueva región primaria durante una conmutación por error y se elimina la cuenta de almacenamiento de la región primaria original.

Puede volver a habilitar el almacenamiento con redundancia geográfica (GRS) o el almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) para la cuenta, pero tenga en cuenta que la conversión de LRS a GRS o RA-GRS incurre en un costo adicional. El costo se debe a los cargos de salida de red para volver a replicar los datos en la nueva región secundaria. Además, se deben rehidratar todos los blobs archivados a un nivel en línea antes de que la cuenta se pueda configurar para la redundancia geográfica, lo que incurrirá en un costo. Para obtener más información sobre los precios, consulte:

Después de volver a habilitar GRS para la cuenta de almacenamiento, Microsoft comienza a replicar los datos de la cuenta en la nueva región secundaria. El tiempo de replicación depende de muchos factores, entre otros:

  • El número y el tamaño de los objetos en la cuenta de almacenamiento. La replicación de muchos objetos pequeños puede tardar más tiempo que replicar menos objetos y más grandes.
  • Los recursos disponibles para la replicación en segundo plano, como CPU, memoria, disco y capacidad WAN. El tráfico en directo tiene prioridad sobre la replicación geográfica.
  • Si la cuenta de almacenamiento contiene blobs, el número de instantáneas por blob.
  • Si la cuenta de almacenamiento contiene tablas, la estrategia de creación de particiones de datos. El proceso de replicación no se puede escalar más allá del número de claves de partición que se usan.

Tipos de cuenta de almacenamiento admitidos

Todas las ofertas con redundancia geográfica admiten la conmutación por error administrada por Microsoft. Además, algunos tipos de cuenta admiten la conmutación por error de la cuenta administrada por el cliente, como se muestra en la tabla siguiente:

Tipo de conmutación por error GRS/RA-GRS GZRS/RA-GZRS
Conmutación por error administrada por el cliente Cuentas de uso general v2
cuentas de uso general v1
cuentas heredadas de Blob Storage		 Cuentas de uso general v2.
Conmutación por error administrada por Microsoft Todos los tipos de cuenta Cuentas de uso general v2.

Cuentas de almacenamiento clásicas

Importante

La conmutación por error de la cuenta administrada por el cliente solo se admite para las cuentas de almacenamiento implementadas mediante el modelo de implementación de Azure Resource Manager (ARM). No se admite el modelo de implementación de Azure Service Manager (ASM), también conocido como clásico. Para que las cuentas de almacenamiento clásicas sean aptas para la conmutación por error de la cuenta administrada por el cliente, primero deben migrarse al modelo de ARM. La cuenta de almacenamiento debe ser accesible para realizar la actualización, por lo que la región primaria no puede estar actualmente en un estado de error.

Si se produce un desastre que afecta a la región primaria, Microsoft administrará la conmutación por error de las cuentas de almacenamiento clásicas. Para más información, consulte Conmutación por error administrada por Microsoft.

Azure Data Lake Storage Gen2

Importante

La conmutación por error de la cuenta administrada por el cliente para las cuentas que tienen un espacio de nombres jerárquico (Azure Data Lake Storage Gen2) está actualmente en versión preliminar y solo se admite en las siguientes regiones:

  • (Asia Pacífico) Centro de la India
  • (Asia Pacífico) Sudeste Asiático
  • (Europa) Norte de Europa
  • (Europa) Norte de Suiza
  • (Europa) Oeste de Suiza
  • (Europa) Oeste de Europa
  • (Norteamérica) Centro de Canadá
  • (Norteamérica) Este de EE. UU. 2
  • (Norteamérica) Centro-sur de EE. UU.

Para participar en la versión preliminar, consulte Configuración de características en versión preliminar en la suscripción de Azure y especifique AllowHNSAccountFailover como nombre de la característica.

Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Si hay un desastre importante que afecta a la región primaria, Microsoft administrará la conmutación por error de las cuentas con un espacio de nombres jerárquico. Para más información, consulte Conmutación por error administrada por Microsoft.

Características y servicios no admitidos

Las siguientes características y servicios no son compatibles con la conmutación por error de una cuenta:

  • Azure File Sync no admite la conmutación por error de la cuenta de almacenamiento iniciada por el cliente. No se debe realizar la conmutación por error de las cuentas de almacenamiento que contienen recursos compartidos de archivos de Azure y que se usan como puntos de conexión de nube en Azure File Sync. Si lo hace, la sincronización dejará de funcionar y también podría provocar una pérdida inesperada de datos en el caso de archivos recién organizados en capas. Para más información, consulte Procedimientos recomendados para la recuperación ante desastres con Azure File Sync para más información.
  • No se puede conmutar por error una cuenta de almacenamiento que contiene blobs en bloques Premium. Las cuentas de almacenamiento que admiten los blobs en bloques Premium actualmente no admiten la redundancia geográfica.
  • No se admite la conmutación por error administrada por el cliente de la cuenta de origen o de destino en una directiva de replicación de objetos.
  • Para conmutar por error una cuenta con el Protocolo de transferencia de archivos SSH (SFTP) habilitado, primero debe deshabilitar SFTP para la cuenta. Si desea reanudar el uso de SFTP una vez completada la conmutación por error, simplemente vuelva a habilitarlo.
  • No se admite Network File System (NFS) 3.0 (NFSv3) para la conmutación por error de la cuenta de almacenamiento. No se puede crear una cuenta de almacenamiento configurada para la redundancia global con NFSv3 habilitado.

La conmutación por error no es para la migración de cuentas

No se debe usar la conmutación por error de una cuenta de almacenamiento como parte de la estrategia de migración de datos. La conmutación por error es una solución temporal a una interrupción del servicio. Para obtener información sobre cómo migrar las cuentas de almacenamiento, consulte Introducción a la migración de Azure Storage.

Cuentas de almacenamiento que contienen blobs archivados

Las cuentas de almacenamiento que contienen blobs archivados admiten la conmutación por error de la cuenta. Sin embargo, una vez completada una conmutación por error administrada por el cliente, se deben rehidratar todos los blobs archivados a un nivel en línea antes de que la cuenta se pueda configurar para la redundancia geográfica.

Proveedor de recursos de Storage

Microsoft proporciona dos API REST para trabajar con recursos de Azure Storage. Estas API forman la base de todas las acciones que se pueden realizar en Azure Storage. La API REST de Azure Storage permite trabajar con los datos de una cuenta de almacenamiento, lo que incluye datos de blobs, colas, archivos y tablas. La API REST del proveedor de recursos de Azure Storage permite administrar la cuenta de almacenamiento y los recursos relacionados.

Una vez que se completa la conmutación por error, los clientes pueden volver a leer y escribir los datos de Azure Storage datos en la nueva región primaria. Sin embargo, el proveedor de recursos de Azure Storage no realiza la conmutación por error, por lo que las operaciones de administración de recursos deben seguir teniendo lugar en la región primaria. Si la región primaria no está disponible, no podrá realizar operaciones de administración en la cuenta de almacenamiento.

Dado que el proveedor de recursos de Azure Storage no realiza la conmutación por error, la propiedad Location devolverá la ubicación principal original después de que se complete la conmutación por error.

Azure Virtual Machines

Las máquinas virtuales (VM) de Azure no conmutan por error como parte de la conmutación por error de una cuenta. Si la región primaria deja de estar disponible y se realiza la conmutación por error en la región secundaria, deberá volver a crear cualquier máquina virtual después de la operación. También hay una pérdida potencial de datos asociada a la conmutación por error de la cuenta. Microsoft recomienda la siguiente guía para alta disponibilidad y recuperación ante desastres, que es específica para máquinas virtuales de Azure.

Recuerde que los datos almacenados en un disco temporal se pierden cuando se apaga la máquina virtual.

Discos no administrados de Azure

Como procedimiento recomendado, Microsoft aconseja convertir los discos no administrados en discos administrados. Sin embargo, si necesita conmutar por error una cuenta que contiene discos no administrados conectados a máquinas virtuales de Azure, deberá apagar la máquina virtual antes de iniciar la conmutación por error.

Los discos no administrados se almacenan como blobs en páginas en Azure Storage. Cuando una máquina virtual se ejecuta en Azure, se conceden los discos no administrados que están conectados a la VM. La conmutación por error de una cuenta no puede continuar si hay una concesión sobre un blob. Para realizar la conmutación por error, siga estos pasos:

  1. Antes de empezar, anote los nombres de los discos no administrados, sus números de unidad lógica (LUN) y la máquina virtual a la que están conectados. Si lo hace, será más fácil volver a conectar los discos después de la conmutación por error.
  2. Apague la máquina virtual.
  3. Elimine la máquina virtual, pero conserve los archivos VHD para los discos no administrados. Anote la hora a la que eliminó la máquina virtual.
  4. Espere hasta que se actualice la hora de la última sincronización y sea posterior a la hora en la que eliminó la máquina virtual. Este paso es importante porque si el punto de conexión secundario no se actualiza por completo con los archivos VHD cuando se produce la conmutación por error, es posible que la máquina virtual no funcione correctamente en la nueva región primaria.
  5. Inicie la conmutación por error de la cuenta.
  6. Espere hasta que se complete la conmutación por error de la cuenta y que la región secundaria se haya convertido en la nueva región primaria.
  7. Cree una máquina virtual en la nueva región primaria y vuelva a conectar los discos duros virtuales.
  8. Inicie la nueva máquina virtual.

Recuerde que los datos almacenados en un disco temporal se pierden cuando se apaga la máquina virtual.

Copia de datos como alternativa a la conmutación por error

Si la cuenta de almacenamiento está configurada para el acceso de lectura a la región secundaria, puede diseñar la aplicación para que lea desde el punto de conexión secundario. Si prefiere no realizar la conmutación por error en caso de que se produzca una interrupción en la región primaria, puede usar herramientas como AzCopy, Azure PowerShell para copiar datos de la cuenta de almacenamiento que se encuentra en la región secundaria a otra cuenta de almacenamiento en una región no afectada. Luego puede apuntar sus aplicaciones a esa cuenta de almacenamiento para obtener disponibilidad de lectura y escritura.

Diseño para lograr alta disponibilidad

Es importante diseñar la aplicación para lograr alta disponibilidad desde el principio. Consulte estos recursos de Azure para instrucciones sobre cómo diseñar la aplicación y planificar la recuperación ante desastres:

Tenga en cuenta estos procedimientos recomendados para mantener la alta disponibilidad de los datos de Azure Storage:

  • Discos: use Azure Backup para crear copias de seguridad de los discos de VM que usan las máquinas virtuales de Azure. Considere también la posibilidad de usar Azure Site Recovery para proteger las máquinas virtuales si hay un desastre regional.
  • Blobs en bloques: active la eliminación temporal para proteger contra eliminaciones o sobrescrituras de nivel de objeto o copie los blobs en bloques en otra cuenta de almacenamiento de otra región medianteAzCopy, Azure PowerShell o la biblioteca de movimiento de datos de Azure.
  • Archivos: Use Azure Backup para hacer una copia de seguridad de los recursos compartidos de archivos. Habilite también la eliminación temporal para proteger contra eliminaciones accidentales de recursos compartidos de archivos. Para la redundancia geográfica cuando GRS no está disponible, use AzCopy o Azure PowerShell para copiar los archivos en otra cuenta de almacenamiento de otra región.
  • Tablas: use AzCopy para exportar datos de tabla a otra cuenta de almacenamiento en una región distinta.

Seguimiento de las interrupciones

Los clientes se pueden suscribir al panel de Azure Service Health para hacer el seguimiento del estado de Azure Storage y otros servicios de Azure.

Microsoft también recomienda diseñar la aplicación para prepararse para la posibilidad de errores de escritura. La aplicación debe exponer los errores de escritura de manera de avisarle sobre la posibilidad de que se produzca una interrupción en la región primaria.

Consulte también