Compartir a través de

Confiabilidad en Azure Blob Storage

Azure Blob Storage es una solución de almacenamiento de objetos para la nube desde Microsoft. Se diseñó para almacenar grandes cantidades de datos no estructurados, como texto, datos binarios, documentos, archivos multimedia y copias de seguridad de aplicaciones. Como servicio básico de Azure Storage, Blob Storage proporciona varias características de confiabilidad para asegurarse de que los datos permanezcan disponibles y duren durante eventos planeados y no planeados.

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 Blob Storage 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 Blob Storage.

Nota:

Blob Storage forma parte de la plataforma Azure Storage. Algunas de las capacidades de Blob Storage son comunes en muchos servicios de Azure Storage. En este artículo, se usa Azure Storage para hacer referencia a estas características.

Recomendaciones de implementación de producción

Para obtener información sobre cómo implementar Blob Storage 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 Blob Storage en el marco de arquitectura recomendada de Azure.

Introducción a la arquitectura de confiabilidad

Azure Storage proporciona varias opciones de redundancia para ayudarle a proteger los datos frente a distintos tipos de errores. Cada opción proporciona un nivel específico de redundancia de datos, por lo que es posible elegir el nivel que mejor se adapte a los requisitos de la aplicación.

El almacenamiento local redundante (LRS) replica los datos de sus cuentas de almacenamiento en una o varias zonas de disponibilidad de Azure ubicadas en la región principal que usted elija. Aunque no existe la opción de elegir su zona de disponibilidad preferida, Azure puede mover o ampliar las cuentas LRS entre zonas para mejorar el equilibrio de carga. No hay garantía de que sus datos se distribuyan entre las distintas zonas. Para obtener más información sobre las zonas de disponibilidad, consulte ¿Qué son las zonas de disponibilidad?.

Diagrama que muestra cómo se replican los datos en las zonas de disponibilidad mediante LRS.

El almacenamiento redundante por zonas (ZRS), el almacenamiento redundante geográfico (GRS) y el almacenamiento redundante geográfico por zonas (GZRS) proporcionan protecciones adicionales. Este artículo describe estas opciones con detalle.

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 tus aplicaciones puedan controlar fallos transitorios, normalmente volviendo a intentar las 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 Blob Storage, implemente las siguientes recomendaciones:

  • Utilice las bibliotecas cliente de Azure Storage, que incluyen directivas de reintento integradas con retroceso exponencial y fluctuación. Los SDK de .NET, Java, Python y JavaScript controlan automáticamente los reintentos en caso de fallos transitorios. Para obtener más información sobre las opciones de configuración de reintentos, consulte Implementación de directivas de reintentos con .NET.

  • Configure los valores de tiempo de espera adecuados para sus operaciones con blobs en función del tamaño de los blobs y las condiciones de la red. Los blobs más grandes requieren tiempos de espera más largos, pero las operaciones más pequeñas pueden usar valores más cortos para detectar errores rápidamente.

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.

Blob Storage 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 del almacenamiento con redundancia local (LRS), ZRS garantiza que Azure replique de forma sincrónica los datos del blob en varias zonas de disponibilidad. ZRS garantiza que sus datos sigan estando accesibles incluso si se produce un corte en una zona.

La redundancia de zona se habilita en el nivel de la cuenta de almacenamiento y se aplica a todos los contenedores de blobs dentro de esa cuenta. No se pueden establecer distintos niveles de redundancia para contenedores individuales. La configuración de redundancia se aplica a toda la cuenta de almacenamiento. Cuando una zona de disponibilidad experimente una interrupción, Azure Storage enrutará automáticamente las solicitudes a zonas correctas sin necesidad de intervención de usted o de la aplicación.

Diagrama que muestra cómo se replican los datos en la región principal con almacenamiento redundante por zonas (ZRS).

Requisitos

  • Tipos de cuenta de almacenamiento: La redundancia de zona está disponible tanto para los tipos de cuentas de almacenamiento v2 de uso general estándar como para las cuentas de almacenamiento Blob en bloques Premium. Los blobs en bloques, los blobs en anexos y los blobs en páginas admiten configuraciones con redundancia de zona, pero el tipo de cuenta de almacenamiento que se use determinará qué funcionalidades estarán disponibles. Para obtener más información, consulte Tipos de cuentas de almacenamiento compatibles.

Costos

Cuando habilita el almacenamiento redundante por zonas (ZRS), se le cobra una tarifa diferente a la del almacenamiento redundante local (LRS) debido a la replicación adicional y los gastos generales de almacenamiento.

Para más información, consulte Precios de Blob Storage.

Configurar soporte de zonas de disponibilidad

  • Crear una cuenta de Blob Storage con redundancia de zona. Para crear una cuenta de almacenamiento con ZRS, consulte Creación de cuentas de almacenamiento y seleccione ZRS, almacenamiento con redundancia de zona geográfica (GZRS) o almacenamiento con redundancia geográfica con acceso de lectura (RA-GZRS) como opción de redundancia durante la creación de la cuenta.

  • Cambiar el tipo de replicación. Para obtener información sobre cómo cambiar una cuenta de almacenamiento existente a almacenamiento redundante por zonas (ZRS) y sobre las opciones y requisitos de configuración, consulte Cambiar la forma en que se replica una cuenta de almacenamiento.

  • Desactivar la redundancia de zona. Convierta las cuentas ZRS de nuevo a una configuración no zonal, como el almacenamiento local redundante (LRS), utilizando el 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é se puede esperar cuando se configura una cuenta de almacenamiento de blobs para la redundancia de zona y todas las zonas de disponibilidad están operativas.

  • Enrutamiento del tráfico entre zonas: Azure Storage con almacenamiento redundante por zonas (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é puede ocurrir cuando se configura una cuenta de almacenamiento de blobs para ZRS y se produce una interrupción en la zona de disponibilidad.

  • Detección y respuesta: Microsoft detecta automáticamente los fallos de zona e inicia los procesos de recuperación. No se requiere ninguna acción del cliente para las cuentas de almacenamiento con redundancia de zona (ZRS). Si una zona deja de estar disponible, Azure lleva a cabo actualizaciones de red como el repunto del sistema de nombres de dominio (DNS).

  • Solicitudes activas: Las solicitudes en curso pueden perderse durante el proceso de recuperación y deben volver a intentarse. 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 en buen estado. Cuando diseñe aplicaciones para ZRS, siga las prácticas para el manejo de fallos transitorios, incluyendo la implementación de directivas de reintento con retroceso exponencial.

  • Reenrutamiento del tráfico: si una zona de disponibilidad se quedase sin conexión, Azure iniciará los cambios de red, como la reconfiguración del punto de conexión del sistema de nombres de dominio (DNS). Estas actualizaciones garantizan que el tráfico se redireccione a las zonas de disponibilidad correctas restantes. El servicio mantiene toda la funcionalidad mediante las zonas supervivientes y no requiere intervención del cliente.

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 sincronizando todas las operaciones que se hayan producido durante el periodo de interrupción del servicio.

Prueba de fallos de zona

Cuando utiliza almacenamiento redundante por zonas (ZRS), Azure Storage administra 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 almacenamiento con redundancia geográfica (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 replican mediante almacenamiento local redundante (LRS). Este enfoque proporciona protección contra fallos de hardware dentro de la región secundaria.

Almacenamiento con redundancia geográfica

Tipos de conmutación por error

Azure Storage admite tres tipos de conmutación por error para diferentes escenarios.

  • Conmutación por error no planificada administrada por el cliente: usted es responsable de iniciar la recuperación si se produce un fallo de almacenamiento en toda la región en su 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 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.

  • Tipos de cuenta de almacenamiento: El almacenamiento con redundancia geográfica (GRS) y la conmutación por error y la conmutación por recuperación iniciadas por el cliente están disponibles en todas las regiones emparejadas de Azure que admiten cuentas de Azure Storage de uso general v2.

Consideraciones

Al implementar Blob Storage en varias regiones, tenga en cuenta los siguientes factores clave:

  • Latencia de replicación asíncrona: la replicación de datos a la región secundaria es asíncrona, lo que significa que hay 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. Este retraso puede provocar una posible pérdida de datos si se produce 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). Puede esperar que el retraso en la replicación sea inferior a 15 minutos, pero este tiempo es una estimación y no está garantizado.

    Puede consultar la propiedad Última hora de sincronización para saber cuántos datos se podrían perder si su cuenta de almacenamiento sufre una conmutación por error no planificada.

  • Acceso a la región secundaria: con las configuraciones de almacenamiento con redundancia geográfica (GRS) y almacenamiento con redundancia geográfica (GZRS), no se puede acceder a la región secundaria para realizar lecturas hasta que se produce una conmutación por error.

    las configuraciones de almacenamiento con redundancia geográfica de acceso de lectura (RA-GRS) y almacenamiento con redundancia de zona geográfica de acceso de lectura (RA-GZRS) proporcionan acceso de lectura a la región secundaria durante el funcionamiento normal, pero debido a la latencia de la replicación asíncrona, es posible que devuelvan datos ligeramente desactualizados.

  • Limitaciones de las características: algunas características de Azure Storage no son compatibles o tienen limitaciones cuando se utiliza almacenamiento con redundancia geográfica (GRS) o conmutación por error administrada por el cliente. Compruebe la compatibilidad de las característica antes de implementar la redundancia geográfica.

Costos

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 más información, consulte Precios de Blob Storage.

Configuración de la compatibilidad con varias regiones

  • Cree una nueva cuenta de almacenamiento con redundancia geográfica (GRS). Para crear una cuenta GRS, consulte Crear 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 existente. Para convertir una cuenta de almacenamiento existente en almacenamiento con redundancia geográfica (GRS), consulte Cambio de cómo se replica una cuenta de almacenamiento.

    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 última hora de sincronización con la última hora en que se escribieron los datos en la nueva región principal.

  • Deshabilitar la redundancia geográfica. Convierta las cuentas GRS de nuevo a configuraciones de una sola región, como el almacenamiento redundante local (LRS) o el almacenamiento redundante por zonas (ZRS), utilizando el 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 Storage utiliza un enfoque activo-pasivo en el que todas las operaciones de escritura y la mayoría de las operaciones de lectura se dirigen a la región principal.

    En las configuraciones de almacenamiento con redundancia geográfica de acceso de lectura (RA-GRS) y almacenamiento con redundancia de zona geográfica de acceso de lectura (RA-GZRS), las aplicaciones pueden leer opcionalmente desde la región secundaria accediendo al punto de conexión secundario. Este enfoque requiere una configuración explícita de la aplicación y no es automático. Además, debido al retraso de replicación asincrónica, los datos de la región secundaria podrían estar ligeramente obsoletos.

  • Replicación de datos entre regiones: las operaciones de escritura se confirman primero en la región principal utilizando los siguientes tipos de redundancia configurados:

    • Almacenamiento local redundante (LRS) para almacenamiento con redundancia geográfica (GRS) y RA-GRS
    • Almacenamiento redundante por zonas (ZRS) para almacenamiento con redundancia de zonas geográficas (GZRS) y RA-GZRS

    Tras completarse con éxito en la región principal, los datos se replican de forma asíncrona 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. Puede supervisar 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.

    • 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. Puede consultar 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ía 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 utiliza el nivel de almacenamiento redundante local (LRS). Si necesita 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.

    • 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ía 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.

    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 recuperación tras una falla 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 planificada): después de una conmutación por error no planificada, la cuenta de almacenamiento se configura con almacenamiento localmente redundante (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 sigue estando replicada geográficamente. Puede iniciar 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 inicia 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 depende 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

Puede simular fallos regionales para probar sus procedimientos de recuperación ante desastres.

  • Pruebas de conmutación por error planificadas: en el caso de las cuentas de almacenamiento con redundancia geográfica (GRS), puede realizar operaciones de conmutación por error planificadas 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 planificada no implica pérdida de datos, pero sí conlleva tiempo de inactividad tanto durante la conmutación por error como durante la conmutación por recuperación.

  • Pruebas de puntos de conexión secundarios: para las configuraciones de almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) y almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS), compruebe periódicamente las operaciones de lectura en el punto de conexión secundario para asegurarse de que su aplicación puede leer correctamente los datos de la región secundaria.

Soluciones personalizadas de varias regiones para la resistencia

Las funcionalidades de conmutación por error entre regiones de Azure Storage pueden 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.

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.

Puede implementar Azure Storage en varias regiones utilizando 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. Cuando implementa varias cuentas de almacenamiento en diferentes regiones, debe 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.

La replicación de objetos proporciona una opción adicional para la replicación de datos entre regiones que proporciona copia asincrónica de blobs en bloques entre cuentas de almacenamiento. A diferencia de las opciones de GRS integradas que usan regiones emparejadas fijas, la replicación de objetos permite replicar datos entre cuentas de almacenamiento en cualquier región de Azure, incluyendo las regiones no emparejadas. Este enfoque le ofrece un control total sobre las regiones de origen y destino, las directivas de replicación y los contenedores y prefijos de blobs específicos que se van a replicar.

Configure la replicación de objetos para replicar todos los blobs de un contenedor o subconjuntos específicos en función de prefijos y etiquetas de blobs. La replicación es asincrónica y se produce en segundo plano. Puede configurar varias directivas de replicación e incluso encadenar la replicación entre varias cuentas de almacenamiento para crear topologías multirregionales sofisticadas.

La replicación de objetos no es compatible con todas las cuentas de almacenamiento. Por ejemplo, no funciona con cuentas de almacenamiento que usen espacios de nombres jerárquicos (también conocidos como cuentas de Azure Data Lake Storage Gen2).

Para obtener más información, consulte Replicación de objetos para blobs en bloques y Configuración de la replicación de objetos.

Copia de seguridad y recuperación

Blob Storage proporciona varios mecanismos de protección de datos que complementan la redundancia para estrategias de copia de seguridad completas. La redundancia integrada del servicio protege frente a errores de infraestructura, mientras que las funcionalidades de copia de seguridad adicionales protegen contra actividades malintencionadas, daños y eliminación accidentales.

La restauración a un momento dado (PITR) permite restaurar los datos de blobs en bloques a un estado anterior dentro de un período de retención configurado de hasta 365 días. Microsoft administra completamente esta característica. También proporciona funcionalidades de recuperación pormenorizadas en el nivel de contenedor o blob. Los datos PITR se almacenan en la misma región que la cuenta de origen y son accesibles incluso durante interrupciones regionales si se usan configuraciones con redundancia geográfica.

El control de versiones de blobs mantiene automáticamente las versiones anteriores de blobs cuando se modifiquen o eliminen. Cada versión se almacena como un objeto independiente y se puede acceder a ella de forma independiente. Las versiones se almacenan en la misma región que el blob actual y siguen la misma configuración de redundancia que la cuenta de almacenamiento.

La eliminación temporal proporciona una red de seguridad para los blobs y contenedores eliminados accidentalmente, ya que conserva los datos eliminados durante un período configurable. Los datos eliminados temporalmente permanecen en la misma cuenta de almacenamiento y región, lo que hace que estén disponibles inmediatamente para la recuperación. En el caso de las cuentas con redundancia geográfica, los datos eliminados de forma temporal también se replican en la región secundaria.

Las instantáneas de blobs crean copias de solo lectura y a un momento dado de blobs que se pueden usar para escenarios de copia de seguridad y recuperación. Las instantáneas se almacenan en la misma cuenta de almacenamiento y siguen la misma configuración de redundancia y replicación geográfica que el blob base.

En el caso de los requisitos de copia de seguridad entre regiones, considere la posibilidad de usar Azure Backup para blobs, que proporciona administración centralizada de copias de seguridad y almacena datos de copia de seguridad en regiones diferentes de los datos de origen. Este servicio proporciona opciones de copia de seguridad operativas y de almacén que tienen directivas de retención configurables, así como funcionalidades de restauración. Para más información, consulte Introducción a Backup para blobs.

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

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 SLA de disponibilidad al que tiene derecho depende del nivel de almacenamiento y del tipo de replicación que utilice. Para obtener más información, consulte Acuerdos de nivel de servicio (SLA) para servicios en línea.

Contenido relacionado

  • Last updated on