Recuperación ante desastres y conmutación por error para Azure Files
Microsoft se esfuerza por garantizar que los servicios de Azure siempre estén disponibles. Sin embargo, es posible que se produzcan interrupciones de servicio no planeadas y debe tener un plan de recuperación ante desastres (DR) para controlar una interrupción del servicio regional. Parte importante de un plan de recuperación ante desastres es preparar la conmutación por error en el punto de conexión secundario ante la eventualidad de que el punto de conexión principal deje de estar disponible. En este artículo se describen los conceptos y procesos implicados en la recuperación ante desastres (DR) y la conmutación por error de la cuenta de almacenamiento.
Importante
Azure File Sync solo admite la conmutación por error de la cuenta de almacenamiento si el servicio de sincronización de almacenamiento también se conmuta por error. Esto se debe a que Azure File Sync requiere que la cuenta de almacenamiento y el servicio de sincronización de almacenamiento estén en la misma región de Azure. Si solo se conmuta por error la cuenta de almacenamiento, se producirá un error en las operaciones de sincronización y nube por niveles hasta que el servicio de sincronización de almacenamiento se conmute por error a la región secundaria. Si quiere conmutar por error una cuenta de almacenamiento que contiene recursos compartidos de archivos de Azure que se usan como puntos de conexión en la nube en Azure File Sync, vea Procedimientos recomendados de recuperación ante desastres de Azure File Sync y recuperación del servidor de Azure File Sync.
Conmutación por error planeada administrada por el cliente (versión preliminar)
La conmutación por error planeada y administrada por el cliente también puede usarse en múltiples escenarios, incluyendo pruebas planeadas de recuperación ante desastres, un enfoque proactivo ante desastres a gran escala o para recuperarse de interrupciones no relacionadas con el almacenamiento.
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.
Métricas y costos de recuperación
Para formular una estrategia de recuperación ante desastres eficaz, una organización debe comprender lo siguiente:
- Cantidad de datos que puede permitirse perder en caso de interrupción (objetivo de punto de recuperación o RPO)
- La rapidez con la que debe poder restaurar las funciones empresariales y los datos (objetivo de tiempo de recuperación o RTO)
El costo de la recuperación ante desastres generalmente aumenta con un RPO o un RTO más bajo o cero. Las empresas que necesitan estar en funcionamiento unos segundos después de un desastre y que no pueden soportar ninguna pérdida de datos pagarán más por recuperación ante desastres, mientras que aquellas con números de RPO/RTO más altos pagarán menos. Azure proporciona soluciones que pueden funcionar con varios requisitos de RPO y RTO.
Elección de la opción de redundancia correcta
Azure Files ofrece diferentes opciones de redundancia para proteger los datos de eventos planeados y no planeados que van desde errores transitorios de hardware, red e interrupciones de energía hasta desastres naturales. Todos los recursos compartidos de archivos de Azure pueden usar almacenamiento con redundancia local (LRS) o con redundancia de zona (ZRS). Para más información, consulte Redundancia de Azure Files.
Azure Files admite la conmutación por error de cuentas para cuentas de almacenamiento estándar configuradas con almacenamiento con redundancia geográfica (GRS) y almacenamiento con redundancia de zona geográfica (GZRS) para protegerse frente a interrupciones regionales. Con la conmutación por error de la cuenta, puede iniciar el proceso de conmutación por error de la cuenta de almacenamiento si el punto de conexión principal deja de estar disponible. La conmutación por error actualiza el punto de conexión secundario para convertirlo en el principal de la cuenta de almacenamiento. Una vez finalizada la conmutación por error, los clientes pueden empezar a escribir en el nuevo punto de conexión principal.
GRS y GZRS siguen presentando un riesgo de pérdida de datos porque los datos se copian en la región secundaria de forma asincrónica, lo que significa que hay un retraso antes de que una escritura en la región primaria se copie en la secundaria. Si se produce una interrupción, se perderán las operaciones de escritura del punto de conexión principal que todavía no se hayan copiado en el punto de conexión secundario. Esto significa que un error que afecte a la región primaria podría provocar la pérdida de datos si no se puede recuperar dicha región. El intervalo entre las escrituras más recientes en la región primaria y la última escritura en la región secundaria es el objetivo de punto de recuperación. Normalmente, Azure Files tiene un RPO de 15 minutos o menos, aunque actualmente no hay ningún Acuerdo de Nivel de Servicio sobre el tiempo que se tarda en replicar los datos en la región secundaria.
Importante
GRS y GZRS no se admiten para los recursos compartidos de archivos premium de Azure. Sin embargo, puede realizar una sincronización entre dos recursos compartidos de archivos de Azure para lograr redundancia geográfica.
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:
- Diseño de aplicaciones resistentes de Azure: información general de los conceptos clave para diseñar aplicaciones altamente disponibles en Azure.
- Lista de comprobación de resistencia: lista de comprobación para verificar que la aplicación implementa los mejores procedimientos recomendados para lograr alta disponibilidad.
- Uso de redundancia geográfica para diseñar aplicaciones de alta disponibilidad: guía de diseño para compilar aplicaciones de forma que se aproveche el almacenamiento con redundancia geográfica para los recursos compartidos de archivos de SMB.
También recomendamos 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.
Como procedimiento recomendado, diseñe la aplicación para comprobar la propiedad 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.
Seguimiento de las interrupciones
Se puede suscribir al panel de Azure Service Health para hacer el seguimiento del estado de Azure Files y otros servicios de Azure.
Descripción del proceso de conmutación por error de una cuenta
La conmutación por error de una cuenta administrada por el cliente le permite conmutar por error toda una cuenta de almacenamiento en la región secundaria si la región principal deja de estar disponible por cualquier motivo. Cuando se fuerza una conmutación por error en la región secundaria, los clientes pueden empezar a escribir datos en el punto de conexión secundario una vez que se completa la conmutación por error. Por lo general, la conmutación por error tarda aproximadamente una hora. Se recomienda suspender la carga de trabajo tanto como sea posible antes de iniciar una conmutación por error de cuenta.
Para más información sobre cómo iniciar una conmutación por error de una cuenta, consulte el artículo sobre la iniciación de la conmutación por error de una cuenta.
Funcionamiento de la conmutación por error de una cuenta
En circunstancias normales, un cliente escribe los datos en una cuenta de almacenamiento en la región primaria y esos datos se copian de forma asincrónica en la región secundaria. En la imagen siguiente se muestra el escenario donde está disponible la región primaria:
Si el punto de conexión principal deja de estar disponible por cualquier motivo, el cliente ya no puede escribir en la cuenta de almacenamiento. En la imagen siguiente muestra el escenario en que la región primaria ha dejado de estar disponible, pero todavía no se ha realizado la recuperación:
El cliente inicia la conmutación por error de la cuenta en el punto de conexión secundario. El proceso de conmutación por error actualiza la entrada DNS que proporciona Azure Storage, de modo tal que el punto de conexión secundario se convierte en el nuevo punto de conexión principal de la cuenta de almacenamiento, tal como se muestra en la imagen siguiente:
El acceso de escritura se restaura para las cuentas con redundancia geográfica una vez que la entrada DNS se actualiza y las solicitudes se dirigen al nuevo punto de conexión principal. Los puntos de conexión de servicio de almacenamiento existentes no cambian después de la conmutación por error. Los identificadores de archivos y las concesiones no se conservan en la conmutación por error, por lo que los clientes deben desmontar y volver a montar los recursos compartidos de archivos.
Importante
Una vez completada la conmutación por error, la cuenta de almacenamiento se configura para que sea con redundancia local en el nuevo punto de conexión o región principal. Para reanudar la replicación en el nuevo punto de conexión secundario, vuelva a configurar la cuenta para la redundancia geográfica.
Tenga en cuenta que la conversión de una cuenta de almacenamiento con redundancia local para usar redundancia geográfica conlleva un costo y un tiempo. Para obtener más información, consulte El tiempo y el costo de la conmutación por error.
Previsión de la pérdida de datos
Precaución
Por lo general, la conmutación por error de una cuenta implica perder algunos datos. Es importante entender las implicaciones que tiene iniciar la conmutación por error de una cuenta.
Como los datos se escriben de forma asincrónica desde la región primaria a la secundaria, si la región primaria deja de estar disponible, es posible que las escrituras más recientes aún no se hayan copiado en la región secundaria.
Al forzar una conmutación por error, todos los datos de la región primaria se pierden a medida que la región secundaria se convierte en la nueva región primaria. La nueva región primaria está configurada para tener redundancia local después de la conmutación por error.
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 perderán de forma permanente.
Comprobación de la propiedad Hora de la última sincronización
La propiedad Last Sync Time (LST) indica la hora más reciente en que se garantiza que los datos de la región primaria se escribieron en la secundaria. Todos los datos escritos antes de la última hora de sincronización están disponibles en la base de datos secundaria, mientras que es posible que los datos escritos después de la última hora de sincronización no se hayan escrito en la base de datos secundaria y que se pierdan. Use esta propiedad si se produce una interrupción para calcular la cantidad de datos perdidos que puede haber al iniciar la conmutación por error de una cuenta.
Para asegurarse de que los recursos compartidos de archivos estén en un estado coherente cuando se produce una conmutación por error, se crea una instantánea del sistema en la región primaria cada 15 minutos y se replica en la región secundaria. Cuando se produce una conmutación por error a la región secundaria, el estado del recurso compartido se basará en la instantánea del sistema más reciente de la región secundaria. Si se produce un error en la región primaria, es probable que la región secundaria esté retrasada en relación con la región primaria, ya que todas las operaciones de escritura en la primaria no se habrían replicado todavía en la secundaria. Debido al retraso geográfico u otros problemas, la instantánea del sistema más reciente de la región secundaria podría ser mayor que 15 minutos.
Todas las operaciones de escritura en la región primaria antes de la LST se han replicado correctamente en la región secundaria, lo que significa que están disponibles para leerse desde la región secundaria. Es posible que las operaciones de escritura en la región primaria, después de la hora de la última sincronización, se hayan replicado o no en la región secundaria, lo que significa que podrían no estar disponibles para las operaciones de lectura.
Puede consultar el valor de la propiedad Hora de la última sincronización mediante Azure PowerShell, la CLI de Azure o la biblioteca cliente. La propiedad Hora de la última sincronización es un valor de fecha y hora GMT. Para obtener más información, consulte Comprobación de la propiedad Hora de la última sincronización de una cuenta de almacenamiento.
Precaución al conmutar por recuperación en la región primaria original
Como se mencionó anteriormente, después de conmutar por error desde la región primaria a la secundaria, la cuenta de almacenamiento se configura con redundancia local en la nueva región primaria. A continuación, puede configurar la cuenta en la nueva región primaria para la redundancia geográfica. Cuando la cuenta se configura para usar la redundancia geográfica después de una conmutación por error, la nueva región primaria empieza de inmediato a copiar los datos en la nueva región secundaria, que antes de la conmutación por error original era la primaria. Sin embargo, puede tardar algún tiempo antes de que los datos existentes en la nueva base de datos principal se copien completamente en la nueva secundaria.
Una vez que la cuenta de almacenamiento se vuelve a configurar para la redundancia geográfica, es posible iniciar una conmutación por recuperación de la nueva región primaria a la nueva región secundaria. En este caso, la región primaria original de antes de la conmutación por error se convierte de nuevo en la región primaria y se configura para redundancia local o redundancia de zona, en función de si la configuración primaria original era GRS o GZRS. Todos los datos de la región primaria posterior a la conmutación por error (la región secundaria original) se pierden durante la conmutación por recuperación. Si la mayoría de los datos de la cuenta de almacenamiento nunca se ha copiado en la nueva región secundaria antes de la conmutación por recuperación, podría ocurrir una pérdida de datos importante.
Para evitar que suceda esto, compruebe el valor de la propiedad Hora de última sincronización antes de la conmutación por recuperación. Compare la hora de última sincronización con las últimas horas en que los datos se escribieron en la nueva región primaria para evaluar la pérdida de datos esperada.
Después de una operación de conmutación por recuperación, puede configurar la nueva región primaria para redundancia geográfica de nuevo. Si la región primaria original se configuró para LRS, puede configurarla para que tenga GRS. Si la región primaria original se configuró para LRS, puede configurarla para que tenga GZRS. Para otras opciones, consulte Cambio de la forma en que se replica una cuenta de almacenamiento.
Iniciación de una conmutación por error de la cuenta
Puede iniciar la conmutación por error de una cuenta desde Azure Portal, PowerShell, la CLI de Azure o la API de proveedor de recursos de Azure Storage. Para más información sobre cómo iniciar una conmutación por error, consulte el artículo sobre la iniciación de la conmutación por error de una cuenta.
Conmutación por error administrada por Microsoft
En casos extremos en los que se pierde una región 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.