Compartir a través de

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 ocasionalmente interrupciones no previstas en el servicio. Entre los componentes clave de un buen plan de recuperación ante desastres, se incluyen estrategias para lo siguiente:

En este artículo se describen las opciones disponibles para las cuentas de almacenamiento con redundancia geográfica y se proporcionan recomendaciones para desarrollar aplicaciones con alta disponibilidad y probar el plan de recuperación ante desastres.

Elección de la opción de redundancia correcta

Azure Storage mantiene varias copias de la cuenta de almacenamiento para garantizar que se cumplen los objetivos de disponibilidad y durabilidad, incluso en caso de errores. La forma en que se replican los datos proporciona distintos niveles de protección. Cada opción ofrece sus propias ventajas, por lo que la opción que elija dependerá del grado de resistencia que requieran las aplicaciones.

Con el almacenamiento con redundancia local (LRS), la opción de redundancia de menor costo, se almacenan y replican automáticamente tres copias de la cuenta de almacenamiento en un único centro de datos. Aunque LRS protege los datos frente a errores del bastidor del servidor y las unidades, no tiene en cuenta desastres como incendios o inundaciones dentro de un centro de datos. En caso de desastres, todas las réplicas de una cuenta de almacenamiento configuradas para usar LRS podrían perderse o no recuperarse.

En comparación, el almacenamiento con redundancia de zona (ZRS), retiene una copia de una cuenta de almacenamiento y la replica 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.

Almacenamiento y conmutación por error con redundancia geográfica

El almacenamiento con redundancia geográfica (GRS), el almacenamiento con redundancia de zona geográfica (GZRS) y el almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS) son ejemplos de opciones de almacenamiento con redundancia geográfica. Cuando se configura para usar el almacenamiento con redundancia geográfica (GRS, GZRS y RA-GZRS), Azure copia los datos de forma asincrónica en una región geográfica secundaria. Estas regiones se encuentran cientos o incluso miles de millas de distancia. Este nivel de redundancia le permite recuperar los datos si hay una interrupción en toda la región primaria.

A diferencia de LRS y ZRS, el almacenamiento con redundancia geográfica también proporciona compatibilidad con una conmutación por error no planeada a una región secundaria si hay una interrupción en la región primaria. Durante el proceso de conmutación por error, las entradas DNS (Sistema de nombres de dominio) para los puntos de conexión de servicio de la cuenta de almacenamiento se actualizan automáticamente de modo que los puntos de conexión de la región secundaria se conviertan en los nuevos puntos de conexión principales. Una vez completada la conmutación por error no planeada, los clientes pueden empezar a escribir en los nuevos puntos de conexión principales.

El almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) y el almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS) también ofrecen almacenamiento con redundancia geográfica con la ventaja adicional del acceso de lectura al punto de conexión secundario. Estas opciones son idóneas y están diseñadas para obtener alta disponibilidad en aplicaciones críticas para la empresa. Si el punto de conexión principal experimenta una interrupción, las aplicaciones configuradas para el acceso de lectura a la región secundaria pueden seguir funcionando. 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 en Azure Storage, consulte Redundancia de Azure Storage.

Planear la conmutación por error

Las cuentas de Azure Storage admiten tres 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 más información, consulte Conmutación por error administrada por Microsoft.
2 Usar opciones de conmutación por error administradas por el cliente para desarrollar, probar e implementar los planes de recuperación ante desastres. 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). 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 Espacio de nombres jerárquico (HNS) admitido
Conmutación por error planeada administrada por el cliente (versión preliminar) Cuenta de almacenamiento Los puntos de conexión del servicio de almacenamiento para las regiones primarias y secundarias están disponibles y desea realizar pruebas de recuperación ante desastres.

Los puntos de conexión de servicio de almacenamiento de la región primaria están disponibles, pero otro servicio impide que las cargas de trabajo funcionen correctamente.

Para prepararse proactivamente para desastres a gran escala, como un huracán, que podría afectar a una región.		 No Sí
(En versión preliminar)
Conmutación por error administrada por el cliente (no planeada) 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 La región primaria deja de estar disponible debido a un desastre significativo, pero la región secundaria está disponible. Sí Sí

En la tabla siguiente se compara el estado de redundancia de una cuenta de almacenamiento después de cada tipo de conmutación por error:

Resultado de la conmutación por error en... Conmutación por error planeada administrada por el cliente (versión preliminar) Conmutación por error administrada por el cliente (no planeada)
...la región secundaria La región secundaria se convierte en la nueva principal La región secundaria se convierte en la nueva principal
...la región primaria original La región primaria original se convierte en la nueva secundaria Se elimina la copia de los datos de la región primaria original
...la configuración de la redundancia de la cuenta La cuenta de almacenamiento se convierte en GRS La cuenta de almacenamiento se convierte en LRS
...la configuración de la redundancia geográfica Se conserva la redundancia geográfica Se pierde la redundancia geográfica

En la siguiente tabla se resume la configuración de la redundancia resultante en cada fase del proceso de conmutación por error y conmutación por recuperación en cada tipo de conmutación por error:

Original
configuración		 Después de
failover		 Después de volver a habilitar
redundancia geográfica		 Después de
conmutación por recuperación		 Después de volver a habilitar
redundancia geográfica
Conmutación por error planeada administrada por el cliente
GRS GRS N/D 1 GRS N/D 1
GZRS GRS N/D 1 GZRS N/D 1
Conmutación por error administrada por el cliente (no planeada)
GRS LRS GRS LRS GRS
GZRS LRS GRS ZRS GZRS

1 redundancia geográfica se conserva durante una conmutación por error planeada y no es necesario volver a configurar manualmente.

Conmutación por error planeada administrada por el cliente (versión preliminar)

La conmutación por error planeada se puede usar en varios escenarios, incluidas las pruebas de recuperación ante desastres planeadas, un enfoque proactivo para desastres a gran escala o para recuperarse de interrupciones relacionadas con la no interrupción.

Durante el proceso de conmutación por error planeada, se intercambian las regiones principal y secundaria. La región primaria original se degrada y se convierte en la nueva región secundaria. Al mismo tiempo, se promueve la región secundaria original y se convierte en la nueva principal. Una vez completada la conmutación por error, los usuarios pueden continuar con el acceso a los datos de la nueva región principal y los administradores pueden validar su plan de recuperación ante desastres. La cuenta de almacenamiento debe estar disponible en ambas regiones, principal y secundaria, para poder iniciar una conmutación por error planeada.

No se espera la pérdida de datos durante el proceso de conmutación por error y conmutación por recuperación planeados siempre que las regiones primarias y secundarias estén disponibles en todo el proceso. Para obtener más información, vea la sección Anticipación de la pérdida de datos e incoherencias.

Para comprender el efecto de este tipo de conmutación por error en los usuarios y las aplicaciones, resulta útil saber lo que sucede durante cada paso de los procesos de conmutación por error y conmutación por recuperación planeados. Para obtener más información sobre cómo funciona este proceso, vea Funcionamiento de la conmutación por error administrada por el cliente (planeada).

Importante

La conmutación por error planeada administrada por el cliente se encuentra actualmente en VERSIÓN PRELIMINAR y está limitada a las regiones siguientes:

  • Centro de Francia
  • Sur de Francia
  • India central
  • India occidental
  • Este de Asia
  • Sudeste de Asia

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.

Importante

Después de una conmutación por error planificada, es posible que el valor de la última fecha de sincronización (LST) de una cuenta de almacenamiento aparezca obsoleto o se notifique como NULL cuando los datos de Azure Files estén presentes.

Las instantáneas del sistema se crean periódicamente en la región secundaria de una cuenta de almacenamiento para mantener la coherencia de los puntos de recuperación utilizados durante la conmutación por error y la conmutación por recuperación. El inicio de la conmutación por error planeada administrada por el cliente hace que la región primaria original se convierta en la nueva secundaria. En algunos casos, no hay instantáneas del sistema disponibles en la nueva región secundaria tras la finalización de la conmutación por error planeada, lo que provoca que el valor global de LST de la cuenta parezca obsoleto o se muestre como Null.

Dado que las actividades del usuario, como crear, modificar o eliminar objetos, pueden desencadenar la creación de instantáneas, cualquier cuenta en la que se produzcan estas actividades después de la conmutación por error planeada no requerirá atención adicional. Sin embargo, las cuentas que no tengan instantáneas ni actividad de usuario pueden seguir mostrando un valor de Null LST hasta que se active la creación de instantáneas del sistema.

Si es necesario, realice una de las siguientes actividades para cada recurso compartido dentro de una cuenta de almacenamiento para desencadenar la creación de instantáneas. Tras la finalización, la cuenta debe mostrar un valor LST válido en un plazo de 30 minutos.

  • Monta el recurso compartido y luego abre cualquier archivo para leerlo.
  • Carga un archivo de prueba o de ejemplo en el recurso compartido.

Conmutación por error administrada por el cliente (no planeada)

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 iniciar una conmutación por error no planeada en la región secundaria. Una vez completada la conmutación por error, la región secundaria se convierte en la nueva principal y los usuarios pueden continuar para acceder a los datos allí.

Para comprender el efecto de este tipo de conmutación por error 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 no planeados. Para más información sobre cómo funciona el proceso, vea Funcionamiento de la conmutación por error administrada por el cliente (no planeada).

Conmutación por error administrada por Microsoft

Microsoft podría iniciar una conmutación por error regional en circunstancias extremas, como un desastre catastrófico que afecte a toda una región geográfica. Durante estos eventos, no se requieren acciones por su parte. Si la cuenta de almacenamiento está configurada para RA-GRS o RA-GZRS, las aplicaciones pueden leer de la región secundaria durante una conmutación por error administrada por Microsoft. Sin embargo, no tendrá acceso de escritura a la cuenta de almacenamiento hasta que se complete el proceso de conmutación por error.

Importante

Use las opciones de conmutación por error administradas por el cliente para desarrollar, probar e implementar los planes de recuperación ante desastres. 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 un centro de datos. No se puede iniciar para cuentas de almacenamiento, suscripciones o inquilinos individuales. Si necesita la posibilidad de conmutar por error de forma selectiva las cuentas de almacenamiento individuales, use la conmutación por error planeada administrada por el cliente.

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

Precaución

La conmutación por error no planeada administrada por el cliente suele implicar cierta cantidad de pérdida de datos y también puede introducir 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 región secundaria.

Cuando se produce una conmutación por error no planeada, todos los datos de la región primaria se pierden, ya que la región secundaria se convierte en la nueva región 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 existan aún en la región secundaria se perderán 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 Hora de la última sincronización indica la hora más reciente en la que también se escribieron datos de la región primaria en la región secundaria. En el caso de las cuentas que tienen un espacio de nombres jerárquico, la misma propiedad Hora de la última sincronización también se aplica a los metadatos administrados por el espacio de nombres jerárquico, incluidas las listas de control de acceso (ACL). Todos los datos y metadatos escritos antes de la última hora de sincronización están disponibles en la secundaria. Por el contrario, es posible que los datos y metadatos escritos después de dicha hora no se copien en la región secundaria y podrían perderse. Durante una interrupción, use esta propiedad para calcular la cantidad de pérdida de datos que podría incurrir al iniciar una conmutación por error de cuenta.

Como procedimiento recomendado, diseñe la aplicación para que pueda usar la hora de última sincronización para evaluar la pérdida de datos esperada. Por ejemplo, el registro de todas las operaciones de escritura permite comparar las horas de la última operación de escritura con la hora de la última sincronización. Este método le permite determinar qué escrituras aún no están sincronizadas en la región secundaria y están en peligro de perderse.

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

La replicación de cuentas de almacenamiento con un espacio de nombres jerárquico habilitado (Azure Data Lake Storage) se produce en el nivel de archivo. Dado que la replicación se produce en este nivel, una interrupción en la región primaria puede impedir que algunos de los archivos de un contenedor o directorio se repliquen 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 administrada por el cliente (no planeada) de cuentas de almacenamiento con fuente de cambios habilitada podría dar lugar a incoherencias entre los registros de fuente de cambios y los datos de blobs o metadatos. Estas incoherencias pueden deberse a la naturaleza asincrónica de las actualizaciones de los registros de cambios y a la replicación de datos entre la región primaria y la secundaria. Puede evitar incoherencias tomando las siguientes precauciones:

  • Asegúrese de que todos los registros se vacían en los archivos de registro.
  • Asegúrese de que todos los datos de almacenamiento se replican de la región principal a la secundaria.

Para más información sobre la fuente de cambios, consulte Funcionamiento de la fuente de cambios.

Tenga en cuenta que otras características de la cuenta de almacenamiento también requieren que se habilite la fuente de cambios. Estas características incluyen copia de seguridad operativa de Azure Blob Storage, replicación de objetos y 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.

Tiempo y costo de la conmutación por error

El tiempo necesario para que se complete una conmutación por error administrada por el cliente después de iniciarse puede variar, aunque normalmente tarda menos de una hora.

Una conmutación por error administrada por el cliente planeada no pierde su redundancia geográfica después de una conmutación por error y una conmutación por recuperación posterior, pero sí una conmutación por error administrada por el cliente no planeada.

Iniciar una conmutación por error no planeada administrada por el cliente convierte automáticamente la cuenta de almacenamiento en almacenamiento con redundancia local (LRS) dentro de una nueva región primaria y elimina la cuenta de almacenamiento en 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 volver a replicar los datos en la nueva región secundaria supone incurrir en un costo. Además, los blobs archivados deben rehidratarse a un nivel en línea antes de que se pueda volver a configurar la cuenta para la redundancia geográfica. Esta rehidratación también conlleva un cargo adicional. 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. La cantidad de tiempo que tarda la replicación en completarse depende de varios factores. Entre estos factores se incluyen:

  • 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.
  • Número de instantáneas por blob, si procede.
  • 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 planeada administrada por el cliente (versión preliminar) 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 el cliente (no planeada) 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 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 modelo 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.

En caso de un desastre que afecte 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.

Espacio de nombres jerárquico (HNS)

Importante

La conmutación por error administrada por el cliente (no planeada) para las cuentas que tienen habilitado Azure Data Lake Storage Gen2 está actualmente en VERSIÓN PRELIMINAR y se admite en todas las regiones GRS/GZRS públicas.

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.

Importante

La conmutación por error administrada por el cliente (no planeada) para las cuentas que tienen habilitado el Protocolo de transferencia de archivos SSH (SFTP) está actualmente en PREVIEW 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.

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.

En caso de un desastre importante que afecte a la región principal, Microsoft administrará la conmutación por error para 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 se admiten para la conmutación por error administrada por el cliente:

  • Azure File Sync no admite la conmutación por error de la cuenta administrada por el cliente. Las cuentas de almacenamiento que se usan como puntos de conexión en la nube para Azure File Sync no deben conmutar por error. La conmutación por error interrumpe la sincronización de archivos y podría provocar la pérdida inesperada de datos de los archivos recién 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.
  • 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 geográfica con NFSv3 habilitado.

La tabla siguiente se puede usar para hacer referencia a la compatibilidad con características.

Conmutación por error planeada Conmutación por error no planeada
Almacén de Azure Data Lake Compatible (versión preliminar) Compatible (versión preliminar)
Fuente de cambios No admitidas Compatible
Replicación de objetos No compatible No compatible
SFTP Compatible (versión preliminar) Compatible (versión preliminar)
NFSv3 Esto no se admite Esto no se admite
Acciones de almacenamiento Se admite1 Se admite1
Restauración a un momento dado (PITR) No admitidas Compatible

1 Si inicia una conmutación por error planeada o no planeada por el cliente, las tareas de almacenamiento no pueden funcionar en la cuenta hasta que se conmuta por recuperación a la región primaria original. Más información.

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

Las conmutaciones por error de la cuenta de almacenamiento son una solución temporal que se usa para desarrollar y probar los planes de recuperación ante desastres (DR) o para recuperarse de una interrupción del servicio. La conmutación por error no debe usarse como parte de la estrategia de migración de datos. 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 en 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 completada una conmutación por error, los clientes pueden leer y escribir datos de Azure Storage en la nueva región primaria. Sin embargo, el proveedor de recursos de Azure Storage no conmuta por error, por lo que las operaciones de administración de recursos deben realizarse 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 conmuta por error, la propiedad Ubicación devolverá la ubicación principal original una vez completada 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 de almacenamiento. Las máquinas virtuales que conmutan por error a una región secundaria en respuesta a una interrupción deben volver a crearse una vez completada la conmutación por error. La conmutación por error de la cuenta puede provocar la pérdida de datos almacenados en un disco temporal cuando la máquina virtual se apaga. Microsoft recomienda la siguiente guía para alta disponibilidad y recuperación ante desastres, que es específica para máquinas virtuales de Azure.

Discos no administrados de Azure

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 que se pueda iniciar una conmutación por error en una cuenta que contenga discos no administrados conectados a máquinas virtuales de Azure, los discos deben apagarse. Por este motivo, los procedimientos recomendados de Microsoft incluyen la conversión de todos los discos no administrados en discos administrados.

Para realizar una conmutación por error en una cuenta que contenga discos no administrados, 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 del disco duro virtual (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 asegúrese de que esta sea posterior a la hora en la que eliminó la máquina virtual. Este paso garantiza que el punto de conexión secundario se ha actualizado por completo con los archivos VHD cuando se produce la conmutación por error y que la máquina virtual funciona 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 de conmutación por error

Como se explicó anteriormente, puede mantener la alta disponibilidad mediante la configuración de aplicaciones para usar una cuenta de almacenamiento configurada para el acceso de lectura a una región secundaria. Sin embargo, si prefiere no conmutar por error durante una interrupción dentro de la región primaria, puede copiar manualmente los datos como alternativa. Herramientas como AzCopy y Azure PowerShell permiten copiar datos de la cuenta de almacenamiento de la región afectada a otra cuenta de almacenamiento de una región no afectada. Una vez completada la operación de copia, puede volver a configurar las aplicaciones para que usen la cuenta de almacenamiento de la región no afectada 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 obtener instrucciones cuando diseñe la aplicación y planifique la recuperación ante desastres:

Consulte 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 de 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 de otra región.

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