Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describe el soporte para la confiabilidad en Azure Files. Azure Files proporciona recursos compartidos de archivos totalmente administrados en la nube a los que se puede acceder a través de protocolos estándar del bloque de mensajes del servidor (SMB) y del sistema de archivos de red (NFS) estándar del sector.
Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.
En este artículo se describe cómo hacer que Azure Files sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de regiones. También se describe cómo puede usar copias de seguridad para recuperarse de otros tipos de problemas y se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Files.
Nota:
Azure Files forma parte de la plataforma de Azure Storage. Algunas de las funcionalidades de Azure Files son comunes en muchos servicios de Azure Storage. En este artículo, se usa Azure Storage para hacer referencia a estas funcionalidades comunes.
Recomendaciones de implementación de producción
Para obtener información sobre cómo implementar Azure Files para admitir los requisitos de confiabilidad de la solución y cómo afecta la confiabilidad a otros aspectos de la arquitectura, consulte Procedimientos recomendados de arquitectura para Azure Files en Azure Well-Architected Framework.
Introducción a la arquitectura de confiabilidad
El almacenamiento con redundancia local (LRS) replica los datos de las cuentas de almacenamiento en una o varias zonas de disponibilidad de Azure ubicadas en la región primaria de su elección. Aunque no hay ninguna opción para elegir la zona de disponibilidad preferida, Azure puede mover o expandir cuentas LRS entre zonas para mejorar el equilibrio de carga. No hay ninguna garantía de que los datos se distribuirán entre zonas. Para obtener más información sobre las zonas de disponibilidad, consulte ¿Qué son las zonas de disponibilidad?.
El almacenamiento con redundancia de zona (ZRS), el almacenamiento con redundancia geográfica (GRS) y el almacenamiento con redundancia de zona geográfica (GZRS) proporcionan protecciones adicionales. En este artículo se describen estas opciones al detalle.
Azure Files está disponible en dos niveles multimedia:
El nivel Premium usa unidades de estado sólido (SSD) para un alto rendimiento. Este nivel se recomienda para cargas de trabajo que requieren baja latencia.
El nivel Estándar admite unidades de disco duro (HDD). Los recursos compartidos de archivos HDD proporcionan una opción de almacenamiento rentable para recursos compartidos de archivos de uso general.
Para más información, consulte Planeamiento de la implementación de Azure Files: niveles de almacenamiento.
Azure Files implementa redundancia en el nivel de cuenta de almacenamiento y los recursos compartidos de archivos heredan esa configuración de redundancia automáticamente. El servicio admite varios modelos de redundancia que difieren en su enfoque de protección de datos.
Resistencia a errores transitorios
Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.
Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.
Para administrar de forma eficaz los errores transitorios al usar Azure Files, configure los valores de tiempo de espera adecuados para las operaciones de archivo en función del tamaño de archivo y las condiciones de red. Los archivos más grandes requieren tiempos de espera más largos, mientras que las operaciones más pequeñas pueden usar valores más cortos para detectar errores rápidamente.
Para asegurarse de que solo se establecen conexiones seguras en el recurso compartido NFS, se recomienda configurar un punto de conexión privado para la cuenta de almacenamiento. Un punto de conexión privado usa Azure Private Link para asignar una dirección IP estática a la cuenta de almacenamiento desde el espacio de direcciones privadas de la red virtual. Un punto de conexión privado ayuda a evitar interrupciones de conectividad de los cambios dinámicos de direcciones IP. Para obtener más información sobre la seguridad de los recursos compartidos NFS, consulte Recursos compartidos de archivos NFS: seguridad y redes.
Resistencia a errores de zona de disponibilidad
Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.
Azure Files proporciona una sólida compatibilidad con zonas de disponibilidad a través de configuraciones de ZRS que distribuyen automáticamente los datos entre varias zonas de disponibilidad dentro de una región. A diferencia de LRS, ZRS garantiza que Azure replica de forma sincrónica los datos de archivo en varias zonas de disponibilidad. ZRS garantiza que sus datos sigan estando accesibles incluso si se produce un corte en una zona.
Requisitos
ZRS es compatible en:
Recursos compartidos de archivos HDD (estándar) en todas las regiones con zonas de disponibilidad.
Recursos compartidos de archivos SSD (Premium) a través del tipo de cuenta de almacenamiento
FileStorage. Para obtener una lista de las regiones que admiten ZRS para cuentas de recursos compartidos de archivos SSD, consulte Compatibilidad con ZRS para recursos compartidos de archivos SSD.
Cost
Cuando se habilita el almacenamiento con redundancia de zona (ZRS), se cobra una tarifa diferente a la del almacenamiento redundante local (LRS) debido a la replicación adicional y los gastos generales de almacenamiento.
Para obtener información detallada sobre los precios, consulte Precios de Azure Files.
Configurar soporte de zonas de disponibilidad
Crea una compartición de archivos con redundancia de zona. Para crear un nuevo recurso compartido de archivos con ZRS, consulte Creación de un recurso compartido de archivos de Azure y seleccione ZRS o GZRS como opción de redundancia durante la creación de la cuenta.
Cambiar el tipo de replicación. Para convertir una cuenta de almacenamiento existente en ZRS y obtener información sobre las opciones y los requisitos de migración, consulte Cambio de la configuración de redundancia para Azure Files.
Desactivar la redundancia de zona. Vuelva a convertir las cuentas de ZRS en una configuración no zonal, como LRS, a través del mismo proceso de cambio de configuración de redundancia.
Comportamiento cuando todas las zonas están en buen estado
En esta sección se describe qué esperar cuando se configura una cuenta de almacenamiento de archivos para la redundancia de zona y todas las zonas de disponibilidad están operativas.
Enrutamiento del tráfico entre zonas: Azure Storage con almacenamiento con redundancia de zona (ZRS) distribuye automáticamente las solicitudes entre los clústeres de almacenamiento en varias zonas de disponibilidad. La distribución del tráfico es transparente para las aplicaciones y no requiere ninguna configuración del lado cliente.
Replicación de datos entre zonas: todas las operaciones de escritura en ZRS se replican de forma sincrónica en todas las zonas de disponibilidad dentro de la región. Al cargar o modificar datos, la operación no se considera completa hasta que los datos se hayan replicado correctamente en todas las zonas de disponibilidad. Esta replicación sincrónica garantiza una fuerte coherencia y cero pérdida de datos durante los errores de zona.
Comportamiento durante un fallo de zona
En esta sección se describe qué se puede esperar cuando se configura una cuenta de almacenamiento de archivos con redundancia de zonas y ocurre una interrupción en la zona de disponibilidad.
Detección y respuesta: Microsoft detecta automáticamente errores de zona e inicia procesos de recuperación. No se requiere ninguna acción por parte del cliente para las cuentas de almacenamiento con redundancia de zona (ZRS).
Si alguna zona deja de estar disponible, Azure realiza las actualizaciones de la red, como el redireccionamiento del Sistema de nombres de dominio (DNS).
- Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.
Solicitudes activas: Es posible que las solicitudes en curso se descarten durante el proceso de recuperación y se deban reintentar. Las aplicaciones deben implementar lógica de reintento para controlar estas interrupciones temporales.
Pérdida de datos esperada: No se produce ninguna pérdida de datos durante los errores de zona porque los datos se replican sincrónicamente en varias zonas antes de completar las operaciones de escritura.
Tiempo de inactividad previsto: es posible que se produzca un breve periodo de inactividad, normalmente de unos segundos, durante la recuperación automática, ya que el tráfico se redirige a zonas correctas. Cuando diseñe aplicaciones para ZRS, siga las prácticas de manejo de fallos transitorios, incluyendo la implementación de directivas de reintento con retroceso exponencial.
- Reenrutamiento del tráfico: Azure vuelve a enrutar automáticamente el tráfico a las zonas de disponibilidad correctas restantes. El servicio mantiene la funcionalidad completa mediante el uso de las zonas supervivientes sin que se requiera intervención del cliente. No es necesario volver a montar los recursos compartidos de archivos de Azure de los clientes conectados.
Recuperación de zona
Cuando se recupera la zona de disponibilidad con errores, Azure Storage restaura automáticamente las operaciones normales en todas las zonas de disponibilidad. El servicio garantiza automáticamente la coherencia de los datos mediante la sincronización de las operaciones que se produjeron durante el período de interrupción.
Prueba de fallos de zona
El usar el almacenamiento con redundancia de zona (ZRS), Azure Storage administrará automáticamente la replicación, el enrutamiento del tráfico y las respuestas ante caídas de zonas. Dado que esta característica está totalmente administrada, no es necesario iniciar ni validar los procesos de error de zona de disponibilidad.
Resistencia a errores en toda la región
Azure Storage, que incluye Azure Blob Storage, Azure Files, Azure Table Storage y Azure Queue Storage, ofrece una amplia gama de capacidades de redundancia geográfica y conmutación por error para adaptarse a diferentes requisitos.
Importante
El GRS solo funciona dentro de regiones emparejadas de Azure. Si la región de la cuenta de almacenamiento no está emparejada, considere la posibilidad de usar las soluciones personalizadas de varias regiones para lograr resistencia.
Almacenamiento con redundancia geográfica para regiones emparejadas
Azure Storage ofrece varios tipos de GRS en regiones emparejadas. Independientemente del tipo de GRS que utilice, los datos de la región secundaria siempre se replicarán mediante almacenamiento con redundancia local (LRS). Este enfoque proporciona protección contra fallos de hardware dentro de la región secundaria.
GRS proporciona soporte para conmutaciones por error planificadas y no planificadas a la región emparejada de Azure cuando se produce una interrupción en la región principal. GRS replica de forma asincrónica los datos de la región primaria a la región emparejada.
El almacenamiento con redundancia de zona geográfica (GZRS) replica los datos en varias zonas de disponibilidad de la región principal y en la región emparejada.
Importante
Azure Files solo admite redundancia geográfica (GRS o GZRS) para recursos compartidos de archivos estándar (HDD).
Azure Files no admite almacenamiento georeduntante de solo lectura (RA-GRS) ni almacenamiento geozonareduntante de solo lectura (RA-GZRS). Si una cuenta de almacenamiento está configurada para usar RA-GRS o RA-GZRS, los recursos compartidos de archivos estándar (HDD) se configuran y facturan como GRS o GZRS.
Tipos de conmutación por error
Azure Storage admite tres tipos de conmutación por error para distintos escenarios.
Conmutación por error no planeada administrada por el cliente: es responsable de iniciar la recuperación si hubiera un error de almacenamiento en toda la región principal.
Conmutación por error planeada administrada por el cliente: Usted es responsable de iniciar la recuperación si otra parte de su solución sufre un fallo en la región primaria y necesita trasladar toda su solución a la región secundaria. Use una conmutación por error planeada cuando el almacenamiento permanezca operativo en la región primaria, pero debe realizar una conmutación por error de toda la solución a una región secundaria, como para los simulacros de recuperación ante desastres diseñados para garantizar el cumplimiento de los requisitos de auditoría.
Conmutación por error administrada por Microsoft: en circunstancias excepcionales, Microsoft podría iniciar la conmutación por error para todas las cuentas de almacenamiento con redundancia geográfica (GRS) de una región. Sin embargo, la conmutación por error administrada por Microsoft es un último recurso y se espera que solo se realice después de un período prolongado de interrupción. No se debe confiar en el failover administrado por Microsoft.
Las cuentas de GRS pueden utilizar cualquiera de estos tipos de conmutación por error. No es necesario preconfigurar una cuenta de almacenamiento para usar ninguno de los tipos de conmutación por error con antelación.
Requisitos
Compatibilidad con regiones: Las configuraciones con redundancia geográfica de Azure Storage usan regiones emparejadas de Azure para la replicación de regiones secundarias. La región secundaria se determina automáticamente en función de la selección de la región principal y no se puede personalizar. Para obtener una lista completa de las regiones emparejadas de Azure, consulte Lista de regiones de Azure.
Si la región de la cuenta de almacenamiento no está emparejada, considere la posibilidad de usar las soluciones personalizadas de varias regiones para lograr resistencia.
Solo recursos compartidos de archivos estándar: Azure Files solo admite redundancia geográfica (GRS o GZRS) para recursos compartidos de archivos estándar (HDD). Los recursos compartidos de archivos Premium (SSD) deben utilizar LRS o ZRS. Si tiene archivos compartidos premium y quiere replicar los datos a través de regiones para una mayor resiliencia, consulte Soluciones personalizadas de varias regiones para resiliencia.
Solo GRS y GZRS: Azure Files no admite el almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) ni el almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS). Si una cuenta de almacenamiento está configurada para usar RA-GRS o RA-GZRS, los recursos compartidos de archivos estándar (HDD) se configuran y facturan como GRS o GZRS.
Consideraciones
Al implementar Azure Files de varias regiones, tenga en cuenta los siguientes factores importantes:
Latencia de replicación asincrónica: la replicación de datos en la región secundaria es asincrónica, lo que significa que hay un retraso entre cuando los datos se escriben en la región primaria y cuando estarán disponibles en la región secundaria. Este retraso podría provocar una posible pérdida de datos si se produjese un fallo en la región principal antes de que se repliquen los datos recientes. La pérdida de datos se mide mediante el objetivo de punto de recuperación (RPO). Espere que el retraso de replicación sea inferior a 15 minutos, pero este tiempo es una estimación y no se garantiza.
Compruebe la propiedad Última hora de sincronización para saber cuántos datos se podrían perder si su cuenta de almacenamiento sufriese una conmutación por error no planificada.
Hora de la última sincronización: Para Azure Files, la hora de la última sincronización se basa en la instantánea del sistema más reciente de la región secundaria.
El cálculo de la hora de la última sincronización puede producirse un tiempo de espera si hay más de 100 comparticiones de archivos en una cuenta de almacenamiento. Se recomienda implementar 100 o menos recursos compartidos de archivos para cada cuenta de almacenamiento para evitar tiempos de espera.
Acceso a la región secundaria: No se accede a la región secundaria para lectura hasta que se produzca un failover.
Limitaciones de características: Algunas características de Azure Files no se admiten o tienen limitaciones al usar GRS o conmutación por error administrada por el cliente. Estas limitaciones incluyen tipos de recursos compartidos de archivos específicos, niveles de acceso y herramientas y operaciones de administración. Revise la documentación de compatibilidad de características antes de implementar la redundancia geográfica.
Cost
Las configuraciones de cuentas de Azure Storage multirregionales conllevan costes adicionales por la replicación entre regiones y el almacenamiento en la región secundaria. La transferencia de datos entre regiones de Azure se cobra en función de las tarifas estándar de ancho de banda entre regiones.
Para obtener información detallada sobre los precios, consulte Precios de Azure Files.
Configuración de la compatibilidad con varias regiones
- Cree una nueva cuenta de almacenamiento con redundancia geográfica (GRS). Para crear una cuenta de GRS, consulte Creación de una cuenta de almacenamiento y seleccione GRS, almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS), almacenamiento con redundancia de zona geográfica (GZRS) o almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS) durante la creación de la cuenta.
Habilite la redundancia geográfica en una cuenta de almacenamiento de archivos existente. Para convertir una cuenta de almacenamiento de archivos existente en GRS, consulte Cambio de la configuración de redundancia para Azure Files.
Advertencia
Una vez que su cuenta se haya reconfigurado para la redundancia geográfica, es posible que transcurra un tiempo considerable antes de que los datos existentes en la nueva región principal se copien por completo a la nueva región secundaria.
Para evitar una pérdida importante de datos, compruebe el valor de la propiedad Última hora de sincronización antes de iniciar una conmutación por error no planificada. Para evaluar la posible pérdida de datos, compare la hora de la última sincronización con la última vez en la que los datos se escribieron en la nueva región primaria.
Deshabilite la redundancia geográfica. Vuelva a convertir las cuentas de GRS en configuraciones de una sola región (LRS o ZRS) a través del mismo proceso de cambio de configuración de redundancia.
Comportamiento cuando todas las regiones están en buen estado
En esta sección se describe qué esperar cuando una cuenta de almacenamiento está configurada para redundancia geográfica y todas las regiones están operativas.
Enrutamiento del tráfico entre regiones: Azure Files usa un enfoque activo-pasivo en el que todas las operaciones de lectura y escritura se dirigen a la región primaria.
Replicación de datos entre regiones: Las operaciones de escritura se confirman primero en la región primaria mediante el tipo de redundancia configurado (LRS para GRS o ZRS para GZRS). Después de finalizar correctamente en la región primaria, los datos se replican de forma asincrónica en la región secundaria, donde se almacenan mediante LRS.
La naturaleza asíncrona de la replicación entre regiones significa que suele haber un retraso entre el momento en que los datos se escriben en la región principal y el momento en que están disponibles en la región secundaria. Supervise el tiempo de replicación utilizando la propiedad Última hora de sincronización.
Comportamiento durante una falla de región
En esta sección se describe qué esperar cuando una cuenta de almacenamiento está configurada para la redundancia geográfica y hay una interrupción en la región primaria.
Conmutación por error administrada por el cliente (no planificada): utilice una conmutación por error no planificada cuando el almacenamiento en la región principal no esté disponible.
Detección y respuesta: En el caso poco probable de que su cuenta de almacenamiento no esté disponible en la región primaria, puede considerar iniciar un failover no planeado administrado por el cliente. Para tomar esta decisión, tenga en cuenta los siguientes factores:
Si Azure Resource Health muestra problemas al acceder a la cuenta de almacenamiento en su región principal
Si Microsoft le recomienda realizar una conmutación por error a otra región
Advertencia
Una conmutación por error no planeada puede provocar la pérdida de datos. Antes de iniciar una conmutación por error administrada por el cliente, decida si la restauración del servicio justifica el riesgo de pérdida de datos.
Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo:
Puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas.
Puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.
Solicitudes activas: Durante el proceso de conmutación por error, los puntos de conexión de la cuenta de almacenamiento principal y secundaria dejan de estar disponibles temporalmente para lecturas y escrituras. Las solicitudes activas podrían fallar, y las aplicaciones cliente deben intentar nuevamente después de que se complete la conmutación por error.
Pérdida de datos prevista: la pérdida de datos es habitual durante una conmutación por error no planificada debido al retraso en la replicación asíncrona, lo que significa que es posible que las escrituras recientes no se repliquen. Consulte la propiedad Última hora de sincronización para saber cuántos datos se podrían perder durante una conmutación por error no planificada. La pérdida de datos esperada se conoce a menudo como objetivo de punto de recuperación (RPO). Normalmente, puede esperar que el RPO sea inferior a 15 minutos, pero ese tiempo no está garantizado.
Tiempo de inactividad esperado: La cantidad de tiempo de inactividad esperado se conoce a menudo como objetivo de tiempo de recuperación (RTO). La conmutación por error administrada por el cliente se completa normalmente en un plazo de 60 minutos, en función del tamaño y la complejidad de la cuenta.
Reenrutamiento del tráfico: A medida que se completa la conmutación por error, Azure actualiza automáticamente los puntos de conexión de la cuenta de almacenamiento para que no sea necesario volver a configurar las aplicaciones. Si su aplicación mantiene entradas del Sistema de nombres de dominio (DNS) almacenadas en caché, puede que sea necesario borrar la caché para asegurarse de que la aplicación envíe el tráfico a la nueva región principal.
Configuración posterior a la conmutación por error: una vez completada una conmutación por error no planificada, su cuenta de almacenamiento en la región de destino utilizará el nivel de almacenamiento con redundancia local (LRS). Si necesitase volver a replicar geográficamente los datos, deberá volver a habilitar el almacenamiento con redundancia geográfica (GRS) y esperar a que los datos se repliquen en la nueva región secundaria.
Para obtener más información sobre cómo iniciar una conmutación por error administrada por el cliente, consulte Cómo funciona la conmutación por error administrada por el cliente (no planificada) e Iniciar una conmutación por error de una cuenta de almacenamiento.
Conmutación por error administrada por el cliente (planificada): utilice una conmutación por error planificada cuando el almacenamiento siga operativo en la región principal, pero necesite conmutar por error toda su solución a una región secundaria por otro motivo. Por ejemplo, otro servicio de Azure podría estar experimentando un problema y debe cambiar al uso de una región secundaria para toda la solución. O bien, puede usar una conmutación por error planeada para realizar un simulacro de recuperación ante desastres (DR) con fines de cumplimiento y auditoría.
Detección y respuesta: Usted es responsable de decidir conmutar por error. Normalmente, se toma esta decisión cuando es necesario realizar una conmutación por error entre regiones, aunque la cuenta de almacenamiento sea correcta. Por ejemplo, puede desencadenar una conmutación por error cuando se produce una interrupción importante en otro componente de la aplicación que no se puede recuperar en la región principal.
Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo:
Puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas.
Puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.
Solicitudes activas: Durante el proceso de conmutación por error, los puntos de conexión de la cuenta de almacenamiento principal y secundaria dejan de estar disponibles temporalmente para lecturas y escrituras. Las solicitudes activas podrían fallar, y las aplicaciones cliente deben intentar nuevamente después de que se complete la conmutación por error.
Pérdida de datos esperada: No se espera ninguna pérdida de datos porque el proceso de conmutación por error se completa solo después de sincronizar todos los datos, lo que da como resultado un RPO de cero.
Tiempo de inactividad esperado: La conmutación por error normalmente se completa en un plazo de 60 minutos, lo que significa que el Tiempo de recuperación objetivo (RTO) esperado es de 60 minutos, en función del tamaño y la complejidad de la cuenta. Durante el proceso de conmutación por error, los puntos de conexión de la cuenta de almacenamiento principal y secundaria dejan de estar disponibles temporalmente para lecturas y escrituras.
Reenrutamiento del tráfico: A medida que se completa la conmutación por error, Azure actualiza automáticamente los puntos de conexión de la cuenta de almacenamiento para que no sea necesario volver a configurar las aplicaciones. Si su aplicación mantiene entradas DNS almacenadas en caché, puede que sea necesario borrar la caché para asegurarse de que la aplicación envíe tráfico a la nueva región principal.
Configuración posterior a la conmutación por error: Una vez completada una conmutación por error planeada, la cuenta de almacenamiento de la región de destino sigue siendo replicada geográficamente y permanece en el nivel GRS.
Para obtener más información sobre cómo iniciar una conmutación por error administrada por el cliente, consulte Cómo funciona la conmutación por error administrada por el cliente (planificada) e Iniciar una conmutación por error de una cuenta de almacenamiento.
Conmutación por error administrada por Microsoft: En el caso excepcional de un desastre importante en el que Microsoft determina que la región primaria es irrecuperable permanentemente, es posible que se inicie una conmutación automática por error a la región secundaria. Microsoft controla todo el proceso y no se requiere ninguna acción del cliente. El tiempo que transcurre antes de que ocurra un failover depende de la gravedad del desastre y del tiempo necesario para evaluar la situación.
Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo:
Puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas.
Puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.
Importante
Utilice las opciones de conmutación por error administradas por el cliente para desarrollar, probar e implementar tus planes de recuperación ante desastres. No confíe en la conmutación por error administrada por Microsoft, que solo se puede utilizar en circunstancias extremas. Es probable que se haya iniciado una conmutación por error administrada por Microsoft para toda una región. No se puede iniciar para cuentas de almacenamiento individuales, suscripciones o clientes. La conmutación por error puede producirse en momentos diferentes para distintos servicios de Azure. Recomendamos que utilice la conmutación por error administrada por el cliente.
Recuperación de regiones
El proceso de conmutación por recuperación difiere significativamente entre los escenarios de conmutación por error administrados por Microsoft y los administrados por el cliente.
Conmutación por error administrada por el cliente (no planeada): después de una conmutación por error no planeada, la cuenta de almacenamiento se configura con almacenamiento con redundancia local (LRS). Para realizar una conmutación por error, es necesario restablecer la relación de almacenamiento con redundancia geográfica (GRS) y esperar a que se repliquen los datos.
Conmutación por error administrada por el cliente (planificada): después de una conmutación por error planificada, la cuenta de almacenamiento seguirá estando replicada geográficamente. Inicie otra conmutación por error administrada por el cliente para volver a la región principal original. Se aplican las mismas consideraciones de conmutación por error.
Conmutación por error administrada por Microsoft: si Microsoft iniciase una conmutación por error, es probable que se haya producido un desastre importante en la región principal y que esta no se pueda recuperar. Cualquier calendario o plan de recuperación dependerá del alcance del desastre regional y de los esfuerzos de recuperación. Debe supervisar las comunicaciones de Azure Service Health para más información.
Prueba de fallos de región
En el caso de las cuentas de GRS, puede realizar operaciones de conmutación por error planeadas durante las ventanas de mantenimiento para probar el proceso completo de conmutación por error y conmutación por recuperación. La conmutación por error planeada no requiere pérdida de datos, pero requiere tiempo de inactividad durante la conmutación por error y la conmutación por recuperación.
Soluciones personalizadas de varias regiones para la resistencia
Las funcionalidades de conmutación por error entre regiones de Azure Storage podrían no ser adecuadas por los siguientes motivos:
La cuenta de almacenamiento está en una región no emparejada.
Los objetivos de tiempo de actividad empresarial no se satisfacen por el tiempo de recuperación o la pérdida de datos que proporciona las opciones de conmutación por error integradas.
Debe conmutar por error a una región que no esté emparejada con la región principal.
Necesita una configuración activa o activa entre regiones.
- Se usan tipos de recursos compartidos de archivos que no admiten redundancia geográfica.
En esta sección se proporciona información general de alto nivel de algunos enfoques que se deben tener en cuenta. Una introducción completa de las topologías de implementación de varias regiones para Azure Storage está fuera del ámbito de este artículo.
Tenga en cuenta los siguientes enfoques comunes de alto nivel:
Varias cuentas de almacenamiento: Azure Files se puede implementar en varias regiones mediante cuentas de almacenamiento independientes en cada región. Este enfoque ofrece flexibilidad en la selección de regiones, la posibilidad de utilizar regiones no emparejadas y un control más granular sobre el momento de la replicación y la coherencia de los datos. Al implementar varias cuentas de almacenamiento entre regiones, es necesario configurar la replicación de datos entre regiones, implementar directivas de equilibrio de carga y conmutación por error y garantizar la coherencia de los datos entre regiones.
Replicación de nivel de aplicación: Implemente la lógica de replicación personalizada mediante Azure Data Factory o AzCopy para sincronizar datos entre recursos compartidos de archivos en distintas regiones. Este enfoque requiere mecanismos personalizados de desarrollo y resolución de conflictos.
Use Azure File Sync para replicar archivos en un recurso compartido de archivos en otra región de Azure. Puede usar Azure File Sync para sincronizar entre un recurso compartido de archivos de Azure SMB (punto de conexión en la nube), un servidor de archivos de Windows local y un recurso compartido de archivos montado que se ejecuta en una máquina virtual (VM) en otra región de Azure (un punto de conexión de servidor de recuperación ante desastres).
Este enfoque requiere que implemente varios recursos compartidos de archivos y una máquina virtual para coordinar el proceso de sincronización.
Si usa este enfoque para la replicación de archivos de varias regiones:
Deshabilite la nube por niveles para asegurarse de que todos los datos están presentes localmente en el servidor de archivos.
Aprovisione suficiente almacenamiento en la máquina virtual de Azure para almacenar todo el conjunto de datos.
Acceda a los archivos y modifique los archivos en el punto de conexión del servidor, y no en Azure, para asegurarse de que los cambios se replican rápidamente en la región secundaria.
Copias de seguridad y restauración
La copia de seguridad de Azure Files es una integración nativa entre Azure Files y Azure Backup diseñada para proteger los datos frente a ataques accidentales de eliminación, daños y ransomware.
La copia de seguridad de Azure Files crea instantáneas a nivel de compartición almacenadas en la misma cuenta de almacenamiento. Esta funcionalidad permite la recuperación rápida de archivos individuales y de comparticiones de archivos completas. También puede usar directivas de copia de seguridad para proporcionar períodos de retención largos con frecuencia de copia de seguridad personalizable.
Puede crear las instantáneas y almacenarlas de dos maneras diferentes:
Almacenamiento de nivel de recurso compartido: En escenarios de recuperación operativos y a corto plazo, puede crear instantáneas de nivel de recurso compartido y almacenarlas en la misma cuenta de almacenamiento. Las instantáneas a nivel de recurso compartido permiten la recuperación rápida de archivos individuales o de recursos compartidos completos en su ubicación original o en una ubicación alternativa.
Almacenamiento de copia de seguridad archivado: Mediante el almacenamiento de respaldo archivado, puede copiar las instantáneas diarias en un almacén de Azure Recovery Services. Para mejorar la seguridad, este almacén está aislado y separado por aire de la cuenta de almacenamiento principal.
Cuando utilizas una región de Azure emparejada y configuras la bóveda para usar GRS, la bóveda replica los datos en la región emparejada. Esta replicación soporta flujos de trabajo para recuperación entre regiones y recuperación ante desastres.
Acuerdo de nivel de servicio
El acuerdo de nivel de servicio (SLA) para Azure Storage describe la disponibilidad esperada del servicio y las condiciones que se deben cumplir para lograr esa expectativa de disponibilidad. El contrato de nivel de servicio de disponibilidad al que tiene derecho dependerá del nivel de almacenamiento y del tipo de replicación que utilice. Para obtener más información, consulte Contratos de nivel de servicio (SLA) para servicios en línea.