Confiabilidad en Azure Service Bus

Azure Service Bus es un servicio de agente de mensajes empresariales totalmente administrado que proporciona funcionalidades de mensajería asincrónica confiables para desacoplar aplicaciones y servicios. Service Bus admite colas para la comunicación de punto a punto y temas con suscripciones para patrones de mensajería de publicación y suscripción. El servicio proporciona características de confiabilidad integradas, como la durabilidad de los mensajes, garantías de entrega al menos una vez, y colas de mensajes inactivos para gestionar el procesamiento de mensajes fallidos.

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 Service Bus sea resistente a una variedad de posibles interrupciones y problemas, como errores transitorios, interrupciones de zona de disponibilidad y interrupciones en regiones. También se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Service Bus.

Recomendaciones de implementación de producción

Azure Well-Architected Framework proporciona recomendaciones sobre confiabilidad, rendimiento, seguridad, costo y operaciones. Para comprender cómo estas áreas influyen entre sí y contribuyen a una solución confiable de App Service, consulte Procedimientos recomendados de arquitectura para Azure Service Bus en Azure Well-Architected Framework.

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

Un espacio de nombres actúa como contenedor de administración para Service Bus y se puede configurar para usar el nivel Básico, Estándar o Premium. Para configurar el servicio a nivel de espacio de nombres, asigne capacidad, configure la seguridad de red y habilite la replicación geográfica y la recuperación ante desastres geográficos.

Dentro de un espacio de nombres, se implementan colas y temas, que son entidades de mensajería con una semántica diferente. Para más información, consulte Colas, temas y suscripciones de Service Bus.

Puede configurar opcionalmente particiones en el espacio de nombres, las cuales distribuyen colas y temas en varios agentes de mensajes y almacenes de mensajería. Un espacio de nombres puede usar varias particiones para realizar el procesamiento paralelo y el escalado horizontal. Service Bus solo garantiza la ordenación dentro de una sola partición. La creación de particiones desempeña un papel clave en el diseño de confiabilidad de la aplicación. Al diseñar la aplicación, realice un equilibrio entre maximizar la disponibilidad y la coherencia. Para el nivel Premium, habilitas la creación de particiones en el espacio de nombres. En el caso de los espacios de nombres de nivel Básico y Estándar, puede configurar particiones en la entidad y opcionalmente al enviar mensajes.

Puede usar Service Bus y sus enfoques de diseño asincrónicos para aumentar la disponibilidad de las aplicaciones. Para más información, consulte Patrones de mensajería asincrónica y alta disponibilidad.

Arquitectura física

Service Bus proporciona los recursos de proceso y almacenamiento subyacentes. Para cada espacio de nombres, varios agentes de mensajes procesan los mensajes y varios almacenes de mensajería almacenan los mensajes. Hay tres copias del almacén de mensajería: una principal y dos secundarias. Service Bus mantiene las tres copias sincronizadas para las operaciones de datos y administración. Si se produce un error en la copia principal, una de las copias secundarias se promueve a principal sin tiempo de inactividad perceptible.

En el caso de los espacios de nombres que usan el nivel Básico o Estándar, Service Bus proporciona redundancia a través de una infraestructura multiinquilino compartida que replica automáticamente los mensajes entre zonas de disponibilidad donde estén disponibles. El servicio mantiene varios almacenes de mensajería y mantiene todas las copias sincronizadas para las operaciones de administración y datos.

En el caso de los espacios de nombres de nivel Premium, Service Bus proporciona unidades de mensajería dedicadas, cada una con recursos dedicados de CPU y memoria. Los espacios de nombres de nivel Premium se pueden escalar automáticamente en función de las demandas de carga de trabajo. Para más información, consulte Actualización automática de unidades de mensajería de un espacio de nombres de Azure Service Bus.

La infraestructura de Service Bus abarca varias máquinas físicas y bastidores que se distribuyen entre dominios de error, lo que reduce el riesgo de fallos catastróficos que afectan al espacio de nombres. En las regiones que tienen zonas de disponibilidad, la infraestructura se extiende entre centros de datos físicos independientes. El servicio implementa mecanismos transparentes de detección de errores y conmutación por error, de modo que sigue funcionando dentro de los niveles de servicio garantizados y normalmente sin interrupciones perceptibles cuando se producen estos errores.

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.

El SDK de Azure Service Bus incluye lógica de reintento automático con retroceso exponencial para las operaciones que producen errores debido a condiciones transitorias, como los tiempos de espera de red o la falta de disponibilidad temporal del servicio. Cuando las aplicaciones experimentan desconectaciones transitorias de Service Bus, el SDK intenta volver a conectarse automáticamente mediante la directiva de reintento configurada.

Para optimizar el control de errores transitorios en las aplicaciones, use el SDK de Service Bus más reciente, que incluye las características de administración de conexiones y lógica de reintento más actuales. Para más información, consulte Biblioteca cliente de Azure Service Bus para .NET.

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.

Service Bus admite implementaciones con redundancia de zona en todos los niveles de servicio. Al crear un espacio de nombres de Service Bus en una región admitida, la redundancia de zona se habilita automáticamente sin costo adicional. El modelo de implementación con redundancia de zona se aplica a todas las características de Service Bus, incluidas las particiones y las sesiones.

Service Bus replica de forma transparente los datos de configuración, metadatos y mensajes en varias zonas de disponibilidad de la región. La redundancia de zona proporciona conmutación automática por error sin requerir intervención de su parte. Todos los componentes de Service Bus, incluidos los procesos, las redes y el almacenamiento, se replican entre zonas. Service Bus tiene suficientes reservas de capacidad para controlar instantáneamente la pérdida completa de una zona. Incluso si una zona de disponibilidad completa deja de estar disponible, Service Bus sigue funcionando sin pérdida de datos ni interrupción en las aplicaciones de mensajería.

Requisitos

• Compatibilidad con regiones: Espacios de nombres de Service Bus con redundancia en zona se pueden implementar en las regiones de Azure con compatibilidad con zonas de disponibilidad. Service Bus habilita automáticamente la compatibilidad con la zona de disponibilidad al crear un espacio de nombres en una región admitida, sin que se requiera ninguna configuración adicional.

• Niveles: Todos los niveles de Service Bus (Básico, Estándar y Premium) admiten zonas de disponibilidad sin requisitos adicionales.

Consideraciones

Los espacios de nombres de Service Bus incluyen una propiedad zoneRedundant. Anteriormente, esta propiedad era necesaria para habilitar zonas de disponibilidad, pero este comportamiento ha cambiado y la zoneRedundant propiedad está en desuso. Esta propiedad puede seguir apareciendo como false incluso cuando está habilitada la redundancia de zona. Todos los espacios de nombres en las regiones con zonas de disponibilidad son redundantes por zona.

Cost

La redundancia de zona en Service Bus no agrega ningún costo adicional.

Configurar soporte de zonas de disponibilidad

Los espacios de nombres de Service Bus admiten automáticamente la redundancia de zona cuando se implementan en regiones admitidas. No es necesario realizar ninguna otra configuración.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando los espacios de nombres de Service Bus están configurados para la redundancia de zona y todas las zonas de disponibilidad están operativas.

• Enrutamiento de tráfico entre zonas. Service Bus usa un modelo activo-activo en el que los mensajes se distribuyen entre varias zonas de disponibilidad. Las conexiones de cliente se equilibran automáticamente entre zonas y el servicio enruta las operaciones a la infraestructura de mensajería disponible independientemente de la zona.

• Replicación de datos entre zonas. Service Bus usa la replicación sincrónica entre zonas de disponibilidad, incluidos los metadatos y los datos de mensajes. Varias copias del almacén de mensajería deben confirmar las operaciones de escritura antes de que se consideren completadas, lo que garantiza la coherencia de los datos entre zonas durante las operaciones normales.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando los espacios de nombres de Service Bus están configurados para redundancia zonal y ocurre una interrupción en una zona de disponibilidad.

• Detección y respuesta: Microsoft detecta automáticamente errores de zona e inicia la conmutación por error a zonas correctas. No se requiere ninguna acción del cliente para la conmutación por error de nivel de zona.

• 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: durante un error de zona, Service Bus podría quitar las solicitudes activas. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

• Pérdida de datos esperada: no se produce ninguna pérdida de datos durante un error de zona porque Service Bus replica de forma sincrónica mensajes entre zonas antes de la confirmación.

• Tiempo de inactividad esperado: un error de zona puede provocar unos segundos de tiempo de inactividad. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

• Reenrutamiento de tráfico: Service Bus detecta la pérdida de la zona y redirige automáticamente las nuevas solicitudes a otra réplica en una de las zonas de disponibilidad correctas.

  El SDK de Service Bus normalmente controla la administración de conexiones y la lógica de reintento de forma transparente.

Recuperación de zona

Cuando se recupera una zona de disponibilidad, Service Bus reintegra automáticamente la zona en la topología activa del servicio. La zona recuperada comienza a aceptar nuevas conexiones y procesar mensajes junto con las demás zonas. Los datos que se han replicado en zonas supervivientes durante la interrupción permanecen intactos y la replicación sincrónica normal se reanuda en todas las zonas. No es necesario tomar medidas para la recuperación y la reintegración de zonas.

Prueba de fallos de zona

Service Bus administra el enrutamiento del tráfico, la conmutación por error y la recuperación de zona para los fallos de zona, por lo que no es necesario validar los procesos de fallo de zona de disponibilidad ni proporcionar datos adicionales.

Resistencia a errores en toda la región

Service Bus ofrece dos tipos de compatibilidad con varias regiones, y ambos requieren espacios de nombres de nivel Premium.

• La replicación geográfica proporciona replicación activa-pasiva de metadatos y datos de mensajes entre una región primaria y una región secundaria. Use la replicación geográfica para la mayoría de las aplicaciones que necesitan permanecer resilientes ante las interrupciones en una región y toleran mal la pérdida de datos de mensajes.

• Metadata Geo-Disaster Recovery proporciona la replicación activa-pasiva de la configuración y los metadatos entre una región primaria y secundaria, pero no replica los datos del mensaje. Considere usar Geo-Disaster Recovery para aplicaciones que gestionan su propia replicación de datos o que no necesitan replicación de datos.

Tanto la replicación geográfica como la recuperación ante desastres geográfica de metadatos requieren que inicie manualmente la conmutación por error o la promoción de una región secundaria para que se convierta en la nueva región primaria. Microsoft no realiza automáticamente la conmutación por error ni la promoción, incluso si la región primaria está inactiva.

Los espacios de nombres de los niveles Básico y Estándar no incluyen características nativas de varias regiones, pero puede implementar patrones de replicación de nivel de aplicación mediante varios espacios de nombres entre regiones. Para obtener más información, consulte la sección Soluciones personalizadas de varias regiones para la resistencia a continuación.

Geo-Replication

El nivel Premium admite la replicación geográfica. Esta característica replica tanto los metadatos (como las entidades, la configuración y las propiedades) como los datos (como los mensajes en las colas y temas, así como las propiedades y el estado del mensaje) para el espacio de nombres. Configure el enfoque de replicación para la configuración y los datos del espacio de nombres. Esta característica garantiza que los mensajes permanecen disponibles en otra región y le permiten cambiar a la región secundaria cuando sea necesario.

Use la replicación geográfica para escenarios que requieran resistencia durante interrupciones de regiones y que tengan una tolerancia baja a la pérdida de datos de mensajes.

El espacio de nombres se extiende esencialmente entre regiones. Una región actúa como principal y las demás regiones sirven como secundaria. La suscripción de Azure muestra un único espacio de nombres.

En cualquier momento, puede promover la región secundaria a una región primaria. Al promover la región secundaria, Service Bus redirige el nombre de dominio completamente calificado (FQDN) del espacio de nombres a la región secundaria seleccionada y convierte la región primaria anterior en una región secundaria. Decide si desea realizar una promoción planeada, lo que significa que espera a que se complete la replicación de datos o una promoción forzada, lo que podría provocar la pérdida de datos.

En esta sección se resumen aspectos importantes de la replicación geográfica. Revise la documentación completa para comprender exactamente cómo funciona. Para más información, consulte Replicación geográfica de Service Bus.

Requisitos

• Compatibilidad con regiones: Puede elegir cualquier región de Azure que admita Service Bus como región primaria o región secundaria. No es necesario usar regiones emparejadas de Azure, por lo que puede elegir regiones secundarias en función de los requisitos de latencia, cumplimiento o residencia de datos.

• Nivel: Para habilitar la replicación geográfica, el espacio de nombres debe usar el nivel Premium.

• Recuperación ante desastres geográfica de metadatos: no se puede configurar un espacio de nombres para usar tanto la replicación geográfica como la recuperación ante desastres geográfica.

Consideraciones

• Limitaciones de características: Al habilitar la replicación geográfica, hay algunas restricciones. Para más información, consulte Replicación geográfica de Service Bus.

• Puntos de conexión privados: Si usa puntos de conexión privados para conectarse al espacio de nombres, también debe configurar las redes en las regiones primarias y secundarias. Para más información, consulte Puntos de conexión privados en la documentación de Azure Event Hubs.

Cost

Para comprender cómo funcionan los precios para la replicación geográfica, consulte Precios.

Configuración de la compatibilidad con varias regiones

• Habilite Geo-Replication en un nuevo espacio de nombres. Para habilitar Geo-Replication en un espacio de nombres durante la creación, consulte Cambiar el modo de replicación.

• Migración de recuperación ante desastres geográfica de metadatos a replicación geográfica.Puede cambiar del uso de recuperación ante desastres geográfica de metadatos a replicación geográfica.

• Cambie el enfoque de replicación. Para cambiar entre modos de replicación sincrónicos y asincrónicos, consulte Cambiar modo de replicación.

• Deshabilite la replicación geográfica. Para deshabilitar Geo-Replication en una región secundaria, consulte Eliminar región secundaria.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando se configura un espacio de nombres de Service Bus para la replicación geográfica y la región primaria está operativa.

• Enrutamiento del tráfico entre regiones: Las aplicaciones cliente se conectan a través del FQDN de su espacio de nombres, y su tráfico se dirige a la región primaria.

  Solo la región primaria procesa activamente los mensajes de los clientes durante las operaciones normales. La región secundaria recibe mensajes replicados, aunque permanece pasiva en modo de espera.

• Replicación de datos entre regiones: El comportamiento de replicación de datos entre la región primaria y secundaria depende de si configura el emparejamiento de replicación para usar la replicación sincrónica o asincrónica.

  • Síncrono: Los mensajes se replican en la región secundaria antes de que se complete la operación de escritura.

    Este modo proporciona la mayor garantía de que los datos del mensaje son seguros porque deben confirmarse en la región primaria y secundaria. Sin embargo, la replicación sincrónica aumenta considerablemente la latencia de escritura para los mensajes entrantes. También requiere que la región secundaria esté disponible para aceptar la operación de escritura, por lo que una interrupción en la región secundaria hace que se produzca un error en la operación de escritura.

    • Asíncrono: Los mensajes se escriben en la región primaria y, a continuación, se completa la operación de escritura. Poco tiempo después, replica los mensajes en la región secundaria.

    Este modo proporciona un mayor rendimiento de escritura que la replicación sincrónica porque no hay ninguna latencia de replicación entre regiones durante las operaciones de escritura. Además, el modo de replicación asincrónica puede tolerar la pérdida de la región secundaria, a la vez que permite operaciones de escritura en la región primaria. Sin embargo, si la región primaria tiene una interrupción, es posible que los datos que aún no se hayan replicado en la región secundaria no estén disponibles o se pierdan.

    Al configurar la replicación asincrónica, establezca el retardo máximo aceptable que puede tener la replicación. En cualquier momento, puede comprobar el retraso de replicación actual mediante métricas de Azure Monitor.

    Si el retraso de replicación asincrónico aumenta más allá del máximo especificado, la región primaria comienza a limitar las solicitudes entrantes para que la replicación pueda alcanzar el nivel deseado. Para evitar esta situación, es importante seleccionar regiones secundarias que no estén demasiado distantes geográficamente y asegurarse de que la capacidad sea suficiente para el rendimiento.

    Algunos tipos de metadatos se replican de forma sincrónica incluso si selecciona el modo de replicación asincrónica.

    Para obtener más información, consulte Modos de replicación.

Comportamiento durante una interrupción regional

En esta sección se describe qué esperar cuando se configura un espacio de nombres de Service Bus para la replicación geográfica y hay una interrupción en la región principal o secundaria.

• Detección y respuesta: Usted es responsable de decidir cuándo promover la región secundaria del espacio de nombres para convertirse en la nueva región primaria. Microsoft no toma esta decisión ni inicia el proceso por ti, incluso si hay una interrupción de la región. Para conocer los criterios sugeridos que se deben tener en cuenta al decidir si realizar la conmutación por error, consulte Escenarios recomendados para desencadenar la promoción.

  Para obtener más información sobre cómo promover una región secundaria a la nueva principal, consulte Flujo de promoción.

  Al promover una región secundaria, elija si desea realizar una promoción planeada o una promoción forzada. Una promoción planeada espera a que la región secundaria se ponga al día antes de aceptar nuevo tráfico. Este enfoque elimina la pérdida de datos, pero presenta tiempo de inactividad.

  Durante una interrupción en la región principal, típicamente usted necesita realizar una promoción forzada. Si la región primaria está disponible y activa una promoción por otro motivo específico, podría elegir una promoción planeada.

• 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: El comportamiento depende de si la interrupción de la región se produce en la región primaria o en la región secundaria:

  • Interrupción de la región primaria: Si la región primaria no está disponible, se finalizan todas las solicitudes activas. Las aplicaciones cliente deben reintentar las operaciones una vez completada la promoción.

  • Interrupción de la región secundaria: Una interrupción en la región secundaria puede provocar problemas para las solicitudes activas en las situaciones siguientes:

    • Si usa el modo de replicación sincrónica, la región primaria no puede completar las operaciones de escritura si alguna región secundaria no está disponible.

    • Si utiliza el modo de replicación asincrónica, su espacio de nombres limita el flujo y no acepta nuevos mensajes una vez que el retraso de replicación alcanza el máximo que haya configurado.

    Para seguir usando el espacio de nombres en la región primaria, quite el espacio de nombres secundario de la configuración de replicación geográfica.

• Pérdida de datos esperada: La cantidad de pérdida de datos depende del tipo de promoción que realice (planeado o forzado) y del modo de replicación (sincrónico o asincrónico):

  • Promoción planeada: No se espera ninguna pérdida de datos. Sin embargo, durante una interrupción de la región, es posible que una promoción planeada no sea posible porque requiere que todas las regiones primarias y secundarias estén disponibles.

  • Promoción forzada, replicación sincrónica: No se espera ninguna pérdida de datos.

  • Promoción forzada, replicación asincrónica: Es posible que experimente alguna pérdida de datos para los mensajes recientes que no se replican en la región secundaria y para los cambios de estado que aún no se han replicado. La cantidad depende del retraso de replicación. Para comprobar el retraso de replicación actual, use las métricas de Azure Monitor.

  Si realiza una promoción forzada, no puede recuperar los datos perdidos, incluso después de que la región primaria esté disponible.

• Tiempo de inactividad esperado: La cantidad de tiempo de inactividad esperado depende de si realiza una promoción planeada o forzada:

  • Promoción planeada: El primer paso de una promoción planeada replica los datos en la región secundaria. Ese proceso suele completarse rápidamente, pero en algunas situaciones, puede tardar hasta la longitud del retraso de replicación. Una vez completada la replicación, el proceso de promoción suele tardar entre 5 y 10 minutos. A veces, los servidores del sistema de nombres de dominio (DNS) pueden tardar más tiempo en actualizar las entradas y replicar completamente sus registros en los clientes.

    La región primaria no acepta operaciones de escritura durante todo el proceso de promoción.

    Es posible que esta opción no sea posible durante una interrupción de la región porque requiere que todas las regiones primarias y secundarias estén disponibles.

  • Promoción forzada: Durante una promoción forzada, Service Bus no espera a que se complete la replicación de datos y inicia la promoción inmediatamente. El proceso de promoción suele tardar entre 5 y 10 minutos. A veces, las entradas DNS pueden tardar más tiempo en replicarse y actualizarse por completo en todos los clientes.

    La región primaria no acepta operaciones de escritura durante todo el proceso de promoción.

• Reenrutamiento del tráfico: Una vez completada la promoción, el FQDN del espacio de nombres apunta a la nueva región primaria. Pero este redireccionamiento depende de la rapidez con la que se actualizan los registros DNS de los clientes, incluido para que sus servidores DNS respeten el período de vida (TTL) de los registros DNS del espacio de nombres.

Recuperación de regiones

Después de que la región primaria original se recupere, si desea devolver el namespace a su región primaria original, siga el mismo proceso de promoción de la región.

Si realizó una promoción forzada durante la interrupción de la región, no podrá recuperar los datos perdidos, incluso después de que la región primaria esté disponible.

Prueba de fallos de región

Para probar la replicación geográfica, promueva temporalmente la región secundaria a principal y compruebe que las aplicaciones cliente pueden cambiar entre regiones con una interrupción mínima.

Supervise la duración de la promoción y compruebe que los runbooks y la automatización funcionan correctamente. Después de realizar las pruebas, puede revertir a la configuración original.

Comprenda el posible tiempo de inactividad y pérdida de datos que puede experimentar durante y después del proceso de promoción. Pruebe la Geo-Replication en un entorno no de producción que reproduzca la configuración de su espacio de nombres de producción.

Recuperación de metadatos ante desastres geográficos

El nivel Premium admite metadatos Geo-Disaster Recovery. Esta característica mejora la recuperación de escenarios de desastres, incluida la pérdida grave de una región. Geo-Disaster Recovery solo replica la configuración y los metadatos de su espacio de nombres. Sin embargo, no replica los datos del mensaje. Para admitir la recuperación ante desastres, esta característica garantiza que un espacio de nombres de otra región esté preconfigurado y listo para aceptar inmediatamente mensajes de los clientes. La recuperación ante desastres geográfica sirve como una solución de recuperación unidireccional y no admite la conmutación por recuperación en la región primaria anterior.

La recuperación de metadatos Geo-Disaster funciona mejor para las aplicaciones que no necesitan mantener todos los mensajes y pueden tolerar cierta pérdida de datos durante un escenario de desastre. La recuperación de metadatos Geo-Disaster Recovery también puede ser adecuada para aplicaciones que replican los datos por sí mismas o que no necesitan replicación de datos en absoluto. Por ejemplo, si los mensajes representan imágenes de gran tamaño que posteriormente convierte en miniaturas, puede decidir que puede permitirse perder algunos mensajes de una región con errores si puede reanudar rápidamente el procesamiento de nuevos mensajes en otra región y puede reconstruir los mensajes más adelante para ponerse al día.

Al configurar metadatos Geo-Disaster Recovery, se crea un alias al que se conectan las aplicaciones cliente. El alias es un FQDN que dirige todo el tráfico al espacio de nombres principal de forma predeterminada.

Si se produce un error en la región primaria u otro tipo de desastre, puede iniciar manualmente una conmutación por error unidireccional desde la región primaria a la región secundaria en cualquier momento. Puede optar por realizar una conmutación por error segura, que espera a que se completen las replicaciones antes de pasar al sistema secundario, aunque es posible que esta opción no esté disponible durante una interrupción en la región. Una vez que se inicia una conmutación por error, se completa casi al instante. Durante el proceso de conmutación por error, el alias de recuperación ante desastres geográfica se redirige al espacio de nombres secundario.

En esta sección se resumen los aspectos importantes de Geo-Disaster Recovery. Revise la documentación completa para comprender exactamente cómo funciona. Para obtener más información, consulte Service Bus Geo-Disaster Recovery.

Requisitos

• Compatibilidad con regiones: Puede seleccionar cualquier región de Azure que admita Service Bus como espacio de nombres principal o secundario. No es necesario usar regiones emparejadas de Azure, por lo que puede elegir regiones secundarias en función de los requisitos de latencia, cumplimiento o residencia de datos.

• Nivel: Para habilitar la recuperación ante desastres geográfica de metadatos, ambos espacios de nombres deben usar el nivel Premium.

• Particionamiento: No es posible emparejar un espacio de nombres particionado con un espacio de nombres no particionado.

• Recuperación ante desastres geográfica de metadatos: no se puede configurar un espacio de nombres para usar tanto la replicación geográfica como la recuperación ante desastres geográfica.

Consideraciones

• Limitaciones de funciones: Al habilitar Recuperación ante Desastres Geográficos, hay algunas restricciones. Para obtener más información, vea Puntos importantes que se deben tener en cuenta y Consideraciones.

• Asignaciones de roles: las asignaciones de control de acceso basado en roles (RBAC) de Microsoft Entra a entidades en el espacio de nombres principal no se replican en el espacio de nombres secundario. Cree asignaciones de roles manualmente en el espacio de nombres secundario para proteger el acceso a estas.

• Diseño de aplicaciones: La Recuperación ante desastres geográficos requiere consideraciones específicas al diseñar sus aplicaciones cliente. Para más información, consulte Consideraciones.

• Puntos de conexión privados: Si usa puntos de conexión privados para conectarse al espacio de nombres, configure las redes en la región primaria y secundaria. Para obtener más información, consulte Puntos de conexión privados.

• Espacios de nombres migrados de Estándar a Premium: Si su espacio de nombres estaba anteriormente en el nivel Estándar y lo migró al nivel Premium, debe gestionar el alias de forma diferente. Para obtener más información, consulte Service Bus de Standard a Premium.

Cost

Al habilitar la recuperación ante desastres geográfica de metadatos, usted paga por los espacios de nombres principal y secundario.

Configuración de la compatibilidad con varias regiones

• Cree un emparejamiento de recuperación ante desastres geográfica de metadatos. Para configurar la recuperación ante desastres entre los espacios de nombres principal y secundario, consulte Proceso de configuración y conmutación por error.

• Deshabilitar los metadatos de recuperación ante desastres geográficos. Para interrumpir el emparejamiento entre espacios de nombres, consulte Configuración y flujo de conmutación por error.

Planeamiento y administración de capacidad

Cuando planee implementaciones de varias regiones, asegúrese de que ambas regiones tienen capacidad suficiente para controlar la carga completa si se produce un error en una región. La región secundaria permanece pasiva durante las operaciones normales, pero debe controlar inmediatamente el tráfico después de la conmutación por error. Planee cómo escalar la capacidad del espacio de nombres secundario para que pueda recibir tráfico de producción sin demora. Si puede tolerar un tiempo de inactividad adicional durante el proceso de conmutación por error, puede optar por escalar la capacidad del espacio de nombres secundario durante o después de la conmutación por error. Para reducir el tiempo de inactividad, aprovisione la capacidad con antelación en el espacio de nombres secundario para que permanezca lista para recibir la carga de producción.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando se configura un espacio de nombres de Service Bus para Geo-Disaster Recovery y la región primaria está operativa.

• Enrutamiento del tráfico entre regiones: las aplicaciones cliente se conectan a través del alias de recuperación ante desastres geográfica de su espacio de nombres, y su tráfico se enruta al espacio de nombres principal en la región primaria.

  Solo el espacio de nombres principal procesa activamente los mensajes de los clientes durante las operaciones normales. El espacio de nombres secundario permanece pasivo en modo de espera y se produce un error en las solicitudes de acceso a los datos.

• Replicación de datos entre regiones: Solo los metadatos de configuración se replican entre los espacios de nombres. La replicación de la configuración se produce de forma continua y asincrónica.

  Todos los datos del mensaje permanecen solo en el espacio de nombres principal y no se replican en el espacio de nombres secundario.

Comportamiento durante una interrupción regional

En esta sección se describe qué esperar cuando se configura un espacio de nombres de Service Bus para Geo-Disaster Recovery y se produce una interrupción en la región primaria.

• Detección y respuesta: usted es responsable de supervisar el estado de la región e iniciar la conmutación por error manualmente. Microsoft no realiza la conmutación por error ni promueve automáticamente una región secundaria, incluso si la región primaria está inactiva.

  Para obtener más información sobre cómo iniciar la conmutación por error, consulte Flujo de conmutación por error.

  Al iniciar una conmutación por error, elija si desea realizar una conmutación por error segura o una conmutación por error estándar (forzada o manual). Una conmutación por error segura espera a que la replicación se complete en la región secundaria antes de que se inicie la conmutación por error. Este enfoque reduce la pérdida de metadatos, pero presenta tiempo de inactividad. La conmutación por error segura requiere que los espacios de nombres estén en la misma suscripción de Azure.

  Durante una interrupción en la región primaria, normalmente debe realizar una conmutación por error forzada. Si la región primaria está disponible y desencadena una conmutación por error por otro motivo, puede elegir una conmutación por error planeada.

  La conmutación por error es una operación unidireccional, por lo que deberá restablecer el emparejamiento de la recuperación ante desastres geográfica más adelante. Para obtener más información, consulte Recuperación de regiones.

• 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: Las solicitudes activas terminan cuando se inicia la conmutación por error. Las aplicaciones cliente deben reintentar las operaciones una vez completada la conmutación por error.

• Pérdida de datos esperada:

  • Metadatos: Normalmente, la configuración y los metadatos se replican en el espacio de nombres secundario. Pero la replicación de metadatos se produce de forma asincrónica, por lo que es posible que los cambios recientes no se repliquen, especialmente los cambios complejos. Compruebe la configuración del espacio de nombres secundario antes de que los clientes accedan a él.

  • Datos del mensaje: Los datos del mensaje no se replican entre regiones. Si la región primaria deja de funcionar, los mensajes del espacio de nombres principal no estarán disponibles.

    Los mensajes no se pierden permanentemente a menos que un desastre catastrófico cause una pérdida total de la región primaria. Si la región se recupera, puede recuperar mensajes del espacio de nombres principal más adelante.

• Tiempo de inactividad esperado: Normalmente, la conmutación ocurre en un plazo de 5 a 10 minutos. Los clientes pueden tardar más tiempo en replicar y actualizar completamente las entradas DNS.

• Reenrutamiento del tráfico: los clientes que usan el alias de recuperación ante desastres geográfica para conectarse al espacio de nombres se redirigen automáticamente al espacio de nombres secundario después de la conmutación por error. Pero este redireccionamiento depende de los servidores DNS que respetan el TTL de los registros DNS del espacio de nombres y los clientes que reciben esos registros DNS actualizados.

Recuperación de regiones

Una vez recuperada la región primaria original, debe reestablecer manualmente el emparejamiento y, opcionalmente, realizar una conmutación de retorno. Cree un nuevo emparejamiento de recuperación ante desastres geográfica con la región recuperada como secundaria y, a continuación, realice otra conmutación por error si desea volver a la región original. Este proceso implica la posible pérdida de datos de los mensajes enviados al primario temporal.

Si el desastre provoca la pérdida de todas las zonas de la región primaria, los datos podrían ser irrecuperables. En otros escenarios, los datos del mensaje permanecen en el espacio de nombres principal de antes de que se pueda recuperar la conmutación por error. Puede obtener mensajes históricos del espacio de nombres principal anterior después de restaurar el acceso. Usted es responsable de configurar las aplicaciones para recibir y procesar esos mensajes. Microsoft no los restaura automáticamente en tu región secundaria.

Prueba de fallos de región

Para probar los procesos de respuesta y recuperación ante desastres, realice una conmutación por error planeada durante una ventana de mantenimiento. Inicie el cambio de espacio de nombres del principal al secundario y compruebe que las aplicaciones puedan conectarse y procesar mensajes desde el nuevo espacio de nombres principal.

Supervise la duración de la conmutación por error y compruebe que los runbooks y la automatización funcionan correctamente. Después de realizar las pruebas, puede revertir a la configuración original.

Comprenda el posible tiempo de inactividad y la pérdida de datos que puede experimentar durante y después del proceso de conmutación por error. Pruebe la recuperación ante desastres geográfica de metadatos en un entorno de preproducción que refleje la configuración de su espacio de nombres de producción.

Soluciones personalizadas de varias regiones para la resistencia

La Geo-Replicación y la Recuperación ante Desastres mediante Metadata proporcionan resiliencia frente a interrupciones regionales y otros problemas, y son adecuadas para la mayoría de las cargas de trabajo. Sin embargo, es posible que no se adapten a sus necesidades en las situaciones siguientes:

• Tiene requisitos para la replicación personalizada o para mantener varias regiones activas simultáneamente.
• Actualmente usas un nivel de Service Bus que no admite estas características.

Hay una variedad de patrones de diseño para lograr distintos tipos de compatibilidad con varias regiones en Service Bus. Muchos de los patrones requieren la implementación de varios espacios de nombres y la configuración de la aplicación para usar los espacios de nombres correctamente. Para obtener más información, consulte los artículos siguientes:

• Uso de varios espacios de nombres para aislar aplicaciones frente a interrupciones y desastres de Service Bus
• Replicación de mensajes y federación entre regiones.

Resistencia al mantenimiento del servicio

Service Bus realiza un mantenimiento normal. Durante el mantenimiento planeado, los espacios de nombres se mueven a un nodo redundante que contiene las actualizaciones más recientes. A medida que se produce este movimiento, el SDK de clientes se desconecta y vuelve a conectarse automáticamente en el espacio de nombres. Normalmente, las actualizaciones se producen en un plazo de 30 segundos. Es importante que las aplicaciones estén preparadas para las desconexiones de red transitorias que se producen durante los períodos de mantenimiento.

Para más información, consulte Guía sobre eventos de mantenimiento de Azure para Azure Service Bus.

Copias de seguridad y restauración

Service Bus no está diseñado como una ubicación de almacenamiento a largo plazo para los datos. Normalmente, los datos se almacenan en un tema o cola durante un breve período de tiempo y, a continuación, se procesan o conservan en otro sistema de almacenamiento de datos, en cuyo momento se elimina. Debido a este diseño, Service Bus mantiene automáticamente réplicas de datos de mensajes, pero no proporciona funcionalidades de copia de seguridad y restauración para los datos del mensaje.

En escenarios que requieren retención de mensajes a largo plazo, considere la posibilidad de implementar el archivado de nivel de aplicación en Azure Storage u otros servicios de almacenamiento duraderos.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Service Bus proporciona un SLA para todos los espacios de nombres. La disponibilidad del Acuerdo de Nivel de Servicio (SLA) es mayor cuando su espacio de nombres cumple todos los siguientes criterios:

• Usa el nivel Premium.
• Se encuentra en una región con zonas de disponibilidad.
• Usa particionamiento.

Contenido relacionado

• Documentación de Service Bus
• Recuperación ante desastres con localización geográfica de Azure Service Bus
• Replicación geográfica de Azure Service Bus