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.
Azure Storage Actions es una plataforma totalmente administrada que automatiza las tareas de administración de datos para Azure Blob Storage y Azure Data Lake Storage. Programa tareas de almacenamiento para que se ejecuten en tus cuentas de almacenamiento. Puede configurar tareas para eliminar blobs, establecer etiquetas de blob y cambiar los niveles de acceso en función de la antigüedad de los datos.
Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para apoyar la resiliencia y la 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 Storage Actions sea resistente a errores transitorios, problemas de configuración, errores de zona de disponibilidad, errores en toda la región y mantenimiento del servicio. También se describen las opciones de copia de seguridad y restauración y la información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Storage Actions.
Importante
Cuando tenga en cuenta la confiabilidad de Azure Storage Actions, tenga en cuenta todas las cuentas de almacenamiento que tengan una asignación de tareas de almacenamiento. Microsoft administra la disponibilidad del servicio Acciones de almacenamiento. Es responsable de elegir configuraciones de redundancia de cuentas de almacenamiento que cumplan los requisitos de confiabilidad de la carga de trabajo. Una interrupción de la cuenta de almacenamiento puede impedir que las tareas de almacenamiento asignadas se ejecuten incluso cuando el plano de control de Storage Actions permanece disponible. Para obtener información sobre las características de confiabilidad de las configuraciones de redundancia de la cuenta de almacenamiento, consulte Confiabilidad en Azure Blob Storage.
Recomendaciones de implementación de producción para la confiabilidad
En el caso de las cargas de trabajo de producción, se recomienda que usted:
Configure cada cuenta de almacenamiento de destino con la opción de redundancia que cumpla los requisitos de confiabilidad. Para la mayoría de las cargas de trabajo de producción, use el almacenamiento con redundancia de zona (ZRS) como mínimo. Si necesita resiliencia ante un fallo que afecte a toda la región y su cuenta de almacenamiento se encuentra en una región emparejada, utilice almacenamiento con redundancia de zona geográfica (GZRS). La ejecución de la tarea de almacenamiento hereda las características de confiabilidad de la cuenta de almacenamiento de destino.
Habilite la eliminación temporal de blobs antes de usar tareas de almacenamiento para eliminar blobs. Habilite la eliminación temporal para blobs en cada cuenta de almacenamiento de destino para que pueda recuperar blobs que una tarea de almacenamiento elimina involuntariamente durante el período de retención.
Evite superponer tareas de almacenamiento con otras directivas de administración del ciclo de vida. No configure una tarea de almacenamiento y otra directiva de administración del ciclo de vida para que realicen operaciones conflictivas en los mismos blobs. Por ejemplo, una operación de eliminación de una tarea de almacenamiento puede producir un error si una directiva de administración del ciclo de vida de Blob Storage intenta eliminar el mismo blob.
Valide la configuración de Storage Actions antes de aplicarla. Utilice una vista previa de condiciones para realizar una validación específica mientras redacta las condiciones de la tarea, y utilice una ejecución de prueba para validar la asignación completa antes de habilitarla para que realice operaciones.
Introducción a la arquitectura de confiabilidad
En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.
Arquitectura lógica
Al usar acciones de Azure Storage, se crean uno o varios recursos de tarea de almacenamiento. Cada tarea de almacenamiento contiene condiciones que seleccionan objetos y operaciones que realizar sobre los objetos coincidentes. Para ejecutar una tarea de almacenamiento en una cuenta de almacenamiento, debe crear una asignación de tarea de almacenamiento. La asignación se almacena como parte del recurso de la cuenta de almacenamiento e identifica los objetos de destino, cuándo y con qué frecuencia se ejecuta la tarea y dónde se almacenan los informes de ejecución. Cuando la ejecución de una tarea alcanza el estado Completed, el servicio genera un informe de ejecución en la ubicación especificada en la asignación.
Es responsable de configurar cada asignación y asignar un rol de Azure adecuado a la identidad administrada de la tarea de almacenamiento.
Arquitectura física
Azure Storage Actions tiene dos planos que son relevantes para la confiabilidad:
Plano de control: Las solicitudes fluyen a través de Azure Resource Manager al proveedor de recursos Azure Storage Actions, que se encarga de las operaciones de administración y los flujos de trabajo de aprovisionamiento asincrónico para tareas y asignaciones de almacenamiento.
Plano de datos: Incluye el programador, los trabajadores que evalúan las condiciones de las tareas de almacenamiento y realizan las operaciones configuradas en las cuentas de almacenamiento de destino, y los componentes de generación de informes. Estos componentes se ejecutan en la infraestructura de Azure Storage.
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 más información, vea Recomendaciones para gestionar errores temporales.
Los errores transitorios pueden afectar a las acciones de Azure Storage de dos maneras principales:
Operaciones de administración: Si automatiza la administración de las acciones de almacenamiento, como la implementación o la modificación de tareas de almacenamiento, es responsable de administrar los fallos transitorios en su automatización. Utilice reintentos limitados con un retraso adecuado entre los intentos.
Ejecución de tareas: Cuando una cuenta de almacenamiento de destino limita las operaciones, Azure Storage Actions reduce el ritmo y vuelve a intentarlo después de un retraso. Siempre que la asignación continúe progresando, Storage Actions continúa reintentando durante la vigencia del flujo de trabajo. Si la asignación no avanza al enumerar ni procesar blobs durante cuatro horas, Storage Actions finaliza la ejecución para que se pueda enviar otra asignación.
Azure Storage Actions solo procesa una asignación cada vez para cada cuenta de almacenamiento de destino. Regula automáticamente la ejecución de tareas para que las cargas de trabajo de la aplicación en la cuenta de almacenamiento de destino tengan prioridad. La escala de ejecución depende de la capacidad de transacciones disponible en la cuenta. Cuando hay menos capacidad de transacción disponible, es posible que la ejecución de una tarea se limite y tarde más en completarse. Para más información, consulte Dependencia de la escala de la capacidad de transacción disponible para la cuenta de almacenamiento.
No todos los fallos en la ejecución de tareas son transitorios. Por ejemplo, una tarea podría producir un error porque su identidad administrada carece de los permisos necesarios, el número de solicitudes supera un límite de escalado o la cuenta de almacenamiento de destino bloquea el acceso a la red. Es responsable de supervisar el estado de la tarea, las métricas y los paneles y corregir estos errores. Un informe de ejecución solo se crea para una ejecución que alcanza el Completed estado. Las ejecuciones fallidas u omitidas no generan un informe de ejecución. Compare los tiempos de ejecución reales con la programación de la asignación para identificar las ejecuciones que no se han producido. Para obtener información sobre cómo identificar y resolver errores de tarea, consulte Solución de problemas de tareas de almacenamiento.
Resistencia a problemas de configuración
Las condiciones de tarea de almacenamiento determinan sobre qué objetos opera una tarea, y una condición u operación incorrectas pueden afectar a objetos no deseados. Microsoft ejecuta cada asignación según su configuración. Usted es responsable de validar la asignación antes de permitir que modifique datos, especialmente cuando incluya operaciones destructivas o irreversibles.
Utilice los siguientes métodos de validación:
Vista previa de la condición: Mientras redacta condiciones de tarea, use la característica de vista previa en el portal de Azure o la API REST de acciones de vista previa para evaluar un ejemplo de hasta 5000 blobs. Una vista previa devuelve resultados inmediatos y no genera un informe de ejecución.
Ejecución simulada: Antes de habilitar la asignación para realizar operaciones, cree una ejecución simulada para la validación final. Una ejecución simulada evalúa todos los blobs del ámbito de asignación sin realizar las operaciones configuradas. Se ejecuta de forma asíncrona, como una asignación normal, y genera un informe de ejecución en formato CSV. Revise el informe para comprobar qué blobs coinciden con las condiciones y qué operaciones realizaría la tarea.
La validación reduce el riesgo de operaciones no deseadas, pero no reemplaza la protección de datos. Antes de usar tareas de almacenamiento para eliminar blobs, habilite la eliminación temporal de blobs en cada cuenta de almacenamiento de destino. La eliminación temporal permite recuperar blobs eliminados durante el período de retención configurado.
Revise las asignaciones de tareas de almacenamiento junto con otras directivas de administración de datos que operan en los mismos blobs. No configure tareas ni directivas que se solapen para realizar operaciones conflictivas. Por ejemplo, una operación de eliminación de una tarea de almacenamiento puede producir un error si una directiva de administración del ciclo de vida de Blob Storage intenta eliminar el mismo blob.
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.
El plano de control de acciones de Azure Storage es con redundancia de zona. Microsoft administra automáticamente la distribución en varias zonas de disponibilidad y no selecciona las zonas. Durante un fallo de una zona de disponibilidad, puede seguir administrando tareas y asignaciones de almacenamiento.
La resiliencia de la ejecución de tareas depende de la configuración de redundancia de cada cuenta de almacenamiento de destino porque las tareas funcionan en los datos de esas cuentas. Si la ejecución de tareas debe continuar durante un fallo de zona, configure cada cuenta de destino con una opción de almacenamiento con redundancia de zona (ZRS, GZRS o RA-GZRS).
En el ejemplo siguiente se muestra el plano de control de Storage Actions y una tarea destinada a una cuenta con redundancia de zona en una región de tres zonas. Tanto el plano de control como la cuenta de destino pueden seguir funcionando si una zona deja de estar disponible:
En el diagrama se muestran las zonas de disponibilidad 1, 2 y 3. El plano de control de Storage Actions abarca las tres zonas y contiene una tarea de almacenamiento. La cuenta de almacenamiento de destino usa ZRS y también abarca las tres zonas.
Por el contrario, una cuenta de destino de LRS no tiene redundancia de zona. En el ejemplo siguiente, el plano de control abarca las tres zonas y la cuenta de destino se muestra en la zona de disponibilidad 1 para ilustrar una cuenta que no abarca zonas. Si la zona que hospeda la cuenta de destino deja de estar disponible, el plano de control sigue estando disponible, pero la tarea no se puede ejecutar en la cuenta de destino hasta que esta se recupere:
En el diagrama se muestran las zonas de disponibilidad 1, 2 y 3. El plano de control de Acciones de almacenamiento abarca las tres zonas y contiene una tarea de almacenamiento. La cuenta de almacenamiento de destino usa LRS y solo aparece en la zona de disponibilidad 1 para ilustrar que LRS no proporciona redundancia de zona.
Requirements
Compatibilidad regional: Al configurar una asignación de tareas de almacenamiento, la tarea de almacenamiento y la cuenta de almacenamiento de destino deben estar en la misma región. Para que la ejecución de tareas sea resistente a los errores de zona, elija una región que admita Azure Storage Actions y zonas de disponibilidad.
Configuración de la cuenta de almacenamiento: Configure cada cuenta de destino con una opción de almacenamiento con redundancia de zona. El almacenamiento con redundancia local (LRS), el almacenamiento con redundancia geográfica (GRS) y el almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) no proporcionan redundancia de zona en la región primaria.
Considerations
La redundancia de zonas del plano de control no hace que la ejecución de tareas sea resistente a fallos de zona cuando una cuenta de almacenamiento de destino no está disponible. Evalúe la configuración de redundancia de cada cuenta de destino por separado.
Cost
La redundancia de zona para el plano de control de Storage Actions es automática y no hay ningún cargo adicional de Storage Actions por habilitarla. Se siguen aplicando cargos de uso estándar para las ejecuciones de tareas, los objetos de destino y las operaciones invocadas. Para obtener más información, consulte precios de Azure Storage Actions.
La opción de redundancia que seleccione para cada cuenta de almacenamiento de destino afecta a los cargos de Azure Storage. Para más información, consulte Precios de Blob Storage.
Configurar soporte de zonas de disponibilidad
La redundancia de zona es automática para el plano de control de Storage Actions. No es necesario configurar la redundancia de zonas por separado para las tareas de almacenamiento ni para las asignaciones.
Para que la ejecución de tareas sea resistente a los errores de zona de disponibilidad, seleccione una opción de almacenamiento con redundancia de zona al crear cada cuenta de almacenamiento de destino o cambie la configuración de redundancia de una cuenta existente.
Comportamiento cuando todas las zonas están en buen estado
En esta sección se describe qué esperar cuando el plano de control de Storage Actions está disponible, las cuentas de almacenamiento de destino usan una opción de almacenamiento con redundancia de zona y todas las zonas de disponibilidad están operativas.
Operación entre zonas: Microsoft distribuye la infraestructura del plano de control de acciones de almacenamiento entre zonas de disponibilidad. Las ejecuciones de tareas se realizan en cada cuenta de almacenamiento de destino, y Azure Storage distribuye de forma transparente las solicitudes a través de la infraestructura que hospeda la cuenta.
Replicación de datos entre zonas: Storage Actions no almacena ni replica los datos de blob que procesan las tareas.
Azure Storage replica datos de forma sincrónica en cuentas que usan una opción de almacenamiento con redundancia de zona entre las zonas de disponibilidad de la región primaria. Azure Storage no completa una operación de escritura hasta que replica los datos en las zonas usadas por la cuenta.
Comportamiento durante un fallo de zona
En esta sección se describe qué esperar cuando el plano de control de Storage Actions está disponible, las cuentas de almacenamiento de destino usan una opción de almacenamiento con redundancia de zona y hay una interrupción en una zona de disponibilidad.
Detección y respuesta: Microsoft detecta y responde a errores que afectan al plano de control de Storage Actions.
En el caso de las cuentas de destino que utilizan una opción de almacenamiento con redundancia de zonas, Azure Storage redirige automáticamente la ejecución de tareas y las operaciones de almacenamiento a zonas en buen estado. No es necesario iniciar la conmutación por error.
- Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, 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: Las tareas de almacenamiento destinadas a cuentas con redundancia de zona disponibles siguen progresando. Es posible que fallen las tareas que tienen como destino una cuenta no disponible.
Es posible que todavía se recojan las asignaciones de ejecución única pendientes. Las ejecuciones interrumpidas o con errores podrían requerir que se vuelvan a programar manualmente, dependiendo de dónde se detuvo el procesamiento.
Pérdida de datos esperada: Storage Actions no almacena una copia independiente de los datos del blob. Las expectativas de pérdida de datos dependen de la configuración de redundancia de cada cuenta de destino. Cuando una cuenta usa una opción de almacenamiento con redundancia de zona, Azure Storage replica sincrónicamente sus datos en las zonas de disponibilidad de la región primaria, por lo que no se espera que un error de zona cause pérdida de datos para escrituras completadas correctamente.
Tiempo de inactividad previsto: El plano de control de Storage Actions permanece disponible durante un fallo de zona.
La ejecución de tareas continúa siempre que la cuenta de almacenamiento de destino permanezca accesible. Si la cuenta deja de estar disponible, como una cuenta de almacenamiento LRS en una zona afectada, es posible que se produzca un error en las ejecuciones afectadas.
Redistribución: Microsoft administra la respuesta y la redistribución del plano de control de Storage Actions.
Azure Storage enruta automáticamente las operaciones de las cuentas que usan una opción de almacenamiento con redundancia de zona a zonas en buen estado. No se requiere ninguna acción del cliente.
Recuperación de zona
Cuando se recupera la zona con errores, Microsoft restaura la distribución normal del plano de control. Azure Storage restaura el funcionamiento normal de las cuentas con redundancia de zona. Las asignaciones de tareas programadas continúan según sus programaciones.
Las asignaciones periódicas se reanudan según las programaciones configuradas. Es posible que todavía se recojan las asignaciones pendientes de ejecución única. Compruebe el estado de las ejecuciones afectadas por la interrupción. Dependiendo de dónde se detenga el procesamiento, es posible que tenga que volver a programar las ejecuciones interrumpidas o con errores.
Prueba de fallos de zona
Microsoft administra la distribución de zona, la conmutación por error y la recuperación para el plano de control de Storage Actions y para las cuentas de almacenamiento con redundancia de zona. No es necesario realizar pruebas de fallos de zona de la plataforma. Pruebe los procedimientos operativos comprobando que puede identificar las operaciones de tareas con errores y ejecutarlas de nuevo de forma segura.
Resistencia a errores en toda la región
La capacidad de recuperación de la ejecución de tareas de almacenamiento durante un fallo en toda la región depende de la configuración de redundancia de cada cuenta de almacenamiento de destino. Si una cuenta de destino usa una opción de almacenamiento con redundancia geográfica (GRS, GZRS, RA-GRS y RA-GZRS), la cuenta de almacenamiento puede conmutar por error a su región emparejada y las futuras ejecuciones de tareas de almacenamiento pueden continuar en la nueva región primaria.
Cuentas de almacenamiento de destino con redundancia geográfica
En el caso de una cuenta de almacenamiento con redundancia geográfica, la región que acepta actualmente las operaciones de escritura es la región primaria. Azure Storage replica de forma asincrónica los datos en la región emparejada de la cuenta, que es la región secundaria.
Las tareas de almacenamiento se ejecutan en la cuenta en su región primaria. Después de la conmutación por error de la cuenta, la región secundaria anterior se convierte en la nueva región primaria y las futuras ejecuciones de tareas de almacenamiento se ejecutan automáticamente allí. Azure Storage Actions no requiere una acción de conmutación por error independiente.
Requirements
Compatibilidad con regiones: La cuenta de almacenamiento de destino debe estar en una región de Azure que tenga una región emparejada.
Configuración de la cuenta de almacenamiento: Configure la cuenta de destino para usar una opción de almacenamiento con redundancia geográfica.
Cost
Las configuraciones de almacenamiento con redundancia geográfica incurren en cargos por replicación y almacenamiento en la región secundaria. Para más información, consulte Precios de Blob Storage.
Configuración de la compatibilidad con varias regiones
Seleccione una opción de almacenamiento con redundancia geográfica al crear la cuenta de almacenamiento de destino o cambie la configuración de redundancia de una cuenta existente.
Si crea una asignación de tareas de almacenamiento mientras la cuenta de destino utiliza una opción no georedundante y posteriormente convierte la cuenta a GRS, GZRS, RA-GRS o RA-GZRS, actualice la asignación antes de iniciar la conmutación por error de la cuenta administrada por el cliente. Puede cambiar cualquier propiedad de la asignación. La actualización hace que el plano de control de Storage Actions detecte la nueva configuración con redundancia geográfica de la cuenta.
Comportamiento cuando todas las regiones están en buen estado
En esta sección se describe qué esperar cuando una cuenta de almacenamiento de destino usa una opción de almacenamiento con redundancia geográfica y las regiones primarias y secundarias están operativas.
Operación entre regiones: Durante el funcionamiento normal, la definición de la tarea de almacenamiento, la asignación y la cuenta de almacenamiento de destino se encuentran en la región primaria. La región secundaria no procesa las operaciones de tareas de almacenamiento.
Replicación de datos entre regiones: las acciones de Azure Storage no replican de forma independiente los datos del blob que procesan las tareas.
Azure Storage replica de forma asincrónica los datos de la región primaria a la región secundaria. Dado que la replicación es asincrónica, es posible que los cambios recientes aún no existan en la región secundaria.
Comportamiento durante una falla de región
En esta sección se describe qué esperar cuando la región primaria de una cuenta de almacenamiento de destino que usa una opción de almacenamiento con redundancia geográfica no está disponible.
Detección y respuesta: La conmutación por error de la cuenta de almacenamiento puede ser administrada por el cliente o por Microsoft. La conmutación por error administrada por Microsoft está reservada para circunstancias excepcionales y puede producirse solo después de una interrupción prolongada, por lo que no se base en ella para su plan de recuperación ante desastres. Siga las instrucciones de conmutación por error de Azure Blob Storage para decidir si y cuándo iniciar la conmutación por error administrada por el cliente.
Azure Storage Actions no requiere una acción de conmutación por error independiente. Sin embargo, si creó la asignación mientras la cuenta de destino usaba LRS y posteriormente convirtió la cuenta en GRS o GZRS, actualice la asignación antes de iniciar la conmutación por error de la cuenta administrada por el cliente. Para obtener más información, consulte Configurar la compatibilidad multirregional.
- Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, 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 la conmutación por error de la cuenta de almacenamiento, los puntos de conexión de la cuenta de almacenamiento principal y secundario no están disponibles temporalmente. Es posible que se produzca un error en las ejecuciones de tareas de almacenamiento que están en curso. Después de la conmutación por error, compruebe el estado de las ejecuciones de tareas afectadas y vuelva a ejecutar operaciones erróneas o incompletas según corresponda.
Para una asignación periódica, si la iteración anterior permanece en curso cuando se programa la siguiente iteración, Storage Actions omite la nueva iteración. La siguiente iteración se ejecuta a su hora de activación designada después de que finalice la iteración anterior.
Pérdida de datos esperada: Azure Storage Actions no mantiene una copia independiente de los datos del blob.
Durante una conmutación por error no planeada, los cambios recientes se pueden perder si no se han replicado en la región secundaria. Una tarea que produce un error mientras está en curso también podría haber completado operaciones en solo algunos de sus objetos de destino. Después de la conmutación por error, compruebe el estado de las ejecuciones de tareas afectadas y vuelva a ejecutar operaciones erróneas o incompletas según corresponda. Para más información sobre los puntos de recuperación de la cuenta de almacenamiento y la pérdida de datos, consulte Pérdida de datos esperada durante un error de región de Blob Storage.
Tiempo de inactividad previsto: Antes de la conmutación por error, las tareas de almacenamiento no pueden avanzar mientras la cuenta de almacenamiento de destino no esté disponible.
Durante la conmutación por error, los puntos de conexión de la cuenta de almacenamiento siguen sin estar disponibles, por lo que las ejecuciones de tareas no pueden avanzar y podrían fallar.
Una vez completada la conmutación por error, los componentes del plano de datos de Storage Actions en la nueva región primaria de la cuenta de almacenamiento procesan futuras ejecuciones de asignación de tareas. El recurso de tarea de almacenamiento permanece en su región original, por lo que los informes de la definición de la tarea pueden permanecer afectados mientras esa región no está disponible. La generación de informes de otras secciones del recurso sigue funcionando.
La interrupción total incluye el tiempo para detectar la interrupción, decidir si iniciar la conmutación por error y completar la conmutación por error de la cuenta de almacenamiento.
Si no se produce ninguna conmutación por error, la ejecución de tareas sigue sin estar disponible hasta que se recupere la región primaria original.
Las operaciones de administración permanecen disponibles durante un fallo de una región.
Redistribución: Azure Storage actualiza los puntos de conexión de la cuenta de almacenamiento a medida que se completa la conmutación por error. Las futuras ejecuciones de asignación de tareas se ejecutan automáticamente contra la cuenta en la nueva región primaria. No es necesario volver a configurar la tarea de almacenamiento ni la asignación.
Recuperación de regiones
El proceso de reversión depende del tipo de conmutación por error de la cuenta de almacenamiento. Siga las instrucciones de recuperación de la región de Blob Storage para revertir la cuenta de almacenamiento de destino. Acciones de almacenamiento de Azure no requiere ninguna configuración adicional tras la reversión de la cuenta de almacenamiento.
Prueba de fallos de región
Para probar el proceso de recuperación sin la pérdida de datos asociada a una conmutación por error no planeada, cree asignaciones de tareas de almacenamiento representativas en una cuenta de almacenamiento sin producción que use una opción de almacenamiento con redundancia geográfica e inicie una conmutación por error planeada administrada por el cliente. Revisa cualquier ejecución en curso y comprueba que las ejecuciones programadas para el futuro se realicen en la cuenta de la nueva región principal. Para obtener orientación sobre las pruebas de conmutación por error, consulta Pruebas de fallos de región en Azure Blob Storage.
Soluciones de varias regiones personalizadas para la resistencia
La compatibilidad de conmutación por error de región integrada para las acciones de Azure Storage solo está disponible cuando la cuenta de almacenamiento de destino está en una región emparejada y usa una opción de almacenamiento con redundancia geográfica.
Si la solución de almacenamiento de varias regiones usa cuentas de almacenamiento independientes en cada región en lugar de la conmutación por error de la cuenta de almacenamiento, puede implementar una tarea de almacenamiento en la misma región que cada cuenta de destino y crear una asignación para cada cuenta. Es responsable de replicar datos entre las cuentas, mantener sincronizadas las definiciones de tareas y las asignaciones, y controlar qué asignaciones se ejecutan durante el funcionamiento normal y la conmutación por error. Asegúrate de que las asignaciones en diferentes regiones no realicen operaciones conflictivas sobre los datos replicados.
Copias de seguridad y restauración
Para recuperar la configuración de Azure Storage Actions después de la eliminación accidental, defina las tareas y asignaciones de almacenamiento como infraestructura como código (IaC) y almacene las definiciones en el control de código fuente. Incluya las condiciones de tarea y las operaciones, las programaciones, los ámbitos de la cuenta de almacenamiento de destino, la configuración del contenedor de informes, las identidades administradas y las asignaciones de roles necesarias. Puede implementar una tarea de almacenamiento mediante Bicep y puede definir asignaciones de tareas de almacenamiento en Bicep.
Las tareas y asignaciones de almacenamiento consisten en la configuración y no contienen los datos de los clientes que procesan las tareas. Utilice el enfoque de IaC descrito anteriormente para recuperar esta configuración. Eres responsable de proteger y recuperar los datos de las cuentas de almacenamiento de destino por separado. Para obtener información sobre las opciones de protección de datos de Azure Storage, consulte Información general sobre la protección de datos.
Pruebe el procedimiento de recuperación en un entorno que no sea de producción. Antes de habilitar las asignaciones recreadas, use vistas previas de condiciones y ejecuciones de prueba para comprobar que la tarea tiene como destino los blobs previstos. Para obtener más información, consulte Procedimientos recomendados para usar tareas de almacenamiento.
Resistencia al mantenimiento del servicio
Microsoft aplica periódicamente actualizaciones de servicio y realiza otro mantenimiento. La plataforma Azure controla estas actividades automáticamente, lo que garantiza que el mantenimiento sea transparente y sin problemas. No se prevé ningún tiempo de inactividad durante las operaciones de mantenimiento, a menos que se te haya informado a través de el mantenimiento planificado de Azure Service Health.
Acuerdo de nivel de servicio
Azure Storage Actions no ofrece un acuerdo de nivel de servicio (SLA) de disponibilidad.