Partekatu bidez

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, incluida la durabilidad del mensaje, garantías de entrega al menos una vez y colas de mensajes fallidos para controlar el procesamiento de mensajes erróneos.

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 diferentes posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de región. También 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 obtener información sobre cómo estas áreas influyen entre sí y contribuyen a una solución confiable de Azure Service Bus, consulte Procedimientos recomendados de arquitectura para Service Bus.

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 que tienen 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 tópicos en varios agentes de mensajes y almacenes de mensajería. Un espacio de nombres puede usar varias particiones para controlar 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, habilite la creación de particiones en el espacio de nombres. Para los espacios de nombres de nivel Básico y Estándar, configure particiones en la entidad y opcionalmente cuando envíe 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. Cada almacén de mensajería tiene tres copias: una copia principal y dos copias 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, Service Bus promueve una copia secundaria a principal sin tiempo de inactividad para los clientes.

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 (RU) que cada una tiene 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 obtener más información, consulte Actualización automática de las unidades de mensajería de un espacio de nombres de 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 para que siga funcionando dentro de los niveles de servicio garantizados y normalmente sin interrupciones perceptibles cuando se produzcan 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 Service Bus incluye lógica de reintento automático con retroceso exponencial para las operaciones que producen errores debido a condiciones transitorias, como tiempos de espera de red o 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 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 una conmutación automática por error sin su intervención. 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. Sigue funcionando sin pérdida de datos ni interrupción en las aplicaciones de mensajería, incluso si una zona de disponibilidad completa deja de estar disponible.

Diagrama que muestra un espacio de nombres de Service Bus con redundancia de zona.

Requisitos

  • Compatibilidad con regiones: Puede implementar espacios de nombres de Service Bus con redundancia de zona en regiones de Azure que admiten 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 requisito ha cambiado y la zoneRedundant propiedad está en desuso. Esta propiedad puede aparecer como false incluso cuando está habilitada la redundancia de zona. Todos los espacios de nombres en regiones que tienen zonas de disponibilidad son redundantes a nivel de 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 al implementarlos 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 el servicio las considere 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 de emergencia a zonas saludables. 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 del 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. A continuación, la zona recuperada acepta nuevas conexiones y procesa mensajes junto con las demás zonas. Los datos que se replican 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 o 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 Geo-Replication para la mayoría de las aplicaciones que deben permanecer resistentes a las interrupciones de regiones y tener baja tolerancia a 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 Recuperación ante Desastres Geográficos para aplicaciones que controlan su propia replicación de datos o no necesitan replicación de datos.

En la tabla siguiente se resumen las diferencias clave entre las dos características:

Capacidad Geo-Replication Recuperación ante desastres geográfica
Qué se replica Metadatos y datos (mensajes; estados de mensaje; cambios de propiedad) Solo metadatos (entidades, configuración, propiedades)
Pérdida de datos durante la conmutación por error Sin pérdida de datos con promoción planeada; posible pérdida de datos con promoción forzada Los mensajes no se replican; debe recuperarse manualmente del espacio de nombres principal anterior.
Comportamiento de conmutación por error Cambia el secundario a primario; el antiguo primario se convierte en secundario Conmutación por error única; El emparejamiento se interrumpe después de la conmutación por error
Funcionalidad de conmutación por recuperación Sí, puede volver a promocionarse a la principal original. No, debe configurar un nuevo emparejamiento
Modos de replicación Sincrónico o asincrónico No aplicable (solo metadatos)

Para la mayoría de los escenarios de recuperación ante desastres, Geo-Replication es la opción recomendada, ya que proporciona protección de datos completa. Considere la recuperación ante desastres geográficos solo cuando necesite específicamente la replicación únicamente de metadatos.

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 inicia automáticamente la conmutación por error ni la promoción, incluso si la región principal deja de funcionar.

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 Soluciones personalizadas de varias regiones para lograr resistencia.

Geo-Replication

El nivel Premium admite la replicación geográfica. Esta característica replica metadatos, como entidades, configuración y propiedades, para el espacio de nombres. También replica datos, como los mensajes de las colas y los temas, junto con las propiedades y el estado del mensaje. 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 permite cambiar a la región secundaria cuando sea necesario.

Use Geo-Replication 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.

Diagrama que muestra un espacio de nombres de Service Bus configurado para la replicación geográfica.

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.

Nota:

Service Bus Geo-Replication usa el término promoción porque representa mejor el proceso de promoción de una región secundaria a una región primaria (y, posteriormente, degradación de una región primaria a una región secundaria). El término conmutación por error también se emplea para describir este proceso general.

En esta sección se resumen aspectos importantes de la replicación geográfica. Revise la documentación completa para obtener información sobre 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 secundaria. No es necesario usar regiones emparejadas de Azure, por lo que seleccione 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áficos de Metadatos: No se puede configurar un espacio de nombres para usar tanto la Geo-Replicación como la Recuperación ante Desastres Geográficos.

Consideraciones

  • Limitaciones de características: Al habilitar la replicación geográfica, se aplican 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 obtener más información, consulte Puntos de conexión privados.

Cost

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

Configuración de la compatibilidad con varias regiones

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-Replication 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, pero por lo demás permanece en modo de espera.

  • Replicación de datos entre regiones: El comportamiento de replicación de datos entre la región principal y secundaria depende de si el emparejamiento de replicación usa 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 se deben confirmar en la región primaria y secundaria. Pero 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.

    • Asincrónico: El servicio escribe mensajes en la región primaria y, a continuación, 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. También puede tolerar la pérdida de la región secundaria, a la vez que permite operaciones de escritura en la región primaria. Pero si se produce una interrupción en la región primaria, es posible que los datos que no se repliquen en la región secundaria no estén disponibles o se pierdan.

      Al configurar la replicación asincrónica, se establece el tiempo de retraso máximo aceptable para 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ónica aumenta más allá del máximo que especifique, la región primaria comienza a limitar las peticiones entrantes para que la replicación sea capaz de alcanzar el nivel esperado. Para evitar esta situación, seleccione regiones secundarias que no estén demasiado distantes geográficamente y asegúrese de que la capacidad sea suficiente para el rendimiento.

      Algunos tipos de metadatos se replican de forma sincrónica incluso cuando se 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 que se deben tener en cuenta al decidir si se debe realizar una 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 entre 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 tráfico nuevo. Este enfoque evita la pérdida de datos, pero produce tiempo de inactividad.

    Durante una interrupción en la región primaria, generalmente se necesita realizar una promoción forzada. Si la región primaria está disponible y desencadena una promoción por otro motivo, puede elegir una promoción planeada en su lugar.

  • 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 Geo-Replication.

  • Pérdida de datos esperada: La cantidad de pérdida de datos depende de si realiza una promoción planeada o forzada y si el modo de replicación es sincrónico o asincrónico:

    • Promoción planeada: No se espera ninguna pérdida de datos. Pero durante una interrupción de la región, es posible que no sea posible una promoción planeada 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 no se replican. 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 admite operaciones de escritura durante el proceso completo 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 la replicación de datos se complete e inicie 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 admite operaciones de escritura durante el proceso completo 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 si sus servidores DNS respetan el período de vida (TTL) de los registros DNS del espacio de nombres.

Recuperación de regiones

Una vez que la región primaria original se haya recuperado, si desea devolver el espacio de nombres a esa región, siga el mismo proceso de promoción regional.

Si ha realizado una promoción forzada durante la interrupción de la región, no puede 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 del espacio de nombres, y 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, cuando los mensajes contienen imágenes grandes que posteriormente se convierten en miniaturas, la pérdida de algunos mensajes de una región con errores puede ser aceptable si puede reanudar rápidamente el procesamiento de mensajes nuevos en otra región y reconstruir los mensajes perdidos más adelante.

Importante

Recuperación ante Desastres Geográficos permite la continuidad de las operaciones que tienen la misma configuración, pero no duplica los datos de los mensajes. Si debe replicar datos de mensajes, considere la posibilidad de usar la replicación geográfica.

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.

Diagrama que muestra dos espacios de nombres de Service Bus configurados para la recuperación ante desastres geográficos de metadatos.

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 realizar una conmutación por error segura, que espera a que se complete la replicación antes de cambiar a la secundaria. Es posible que esta opción no esté disponible durante una interrupción de la región. Después de que se inicie 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 obtener información sobre cómo funciona. Para obtener más información, consulte Service Bus Geo-Disaster Recovery.

Requisitos

  • Compatibilidad con regiones: Puede elegir 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 seleccione regiones secundarias en función de los requisitos de latencia, cumplimiento o residencia de datos.

  • Nivel: Para habilitar los metadatos Geo-Disaster Recovery, ambos espacios de nombres deben usar el nivel Premium.

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

  • Recuperación ante Desastres Geográficos de Metadatos: No se puede configurar un espacio de nombres para usar tanto la Geo-Replicación como la Recuperación ante Desastres Geográficos.

Consideraciones

  • Limitaciones de características: Al habilitar Geo-Disaster Recuperación, se aplican 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 esas entidades.

  • 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 tu espacio de nombres está en el nivel Estándar y lo migras al nivel Premium, necesitas gestionar el alias de una manera 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

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 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 de tráfico entre regiones: Las aplicaciones de cliente se conectan a través del alias de Recuperación ante Desastres Geo para el espacio de nombres, y su tráfico se dirige al espacio de nombres primario 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 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 monitorear la salud de la región e iniciar la conmutación por error manualmente. Microsoft no inicia 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 el 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, como una conmutación por error 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 es necesario reestablecer el emparejamiento de Geo-Disaster Recovery 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. 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 de Geo-Disaster 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 que la región primaria original se recupere, debe reestablecer manualmente el emparejamiento y, opcionalmente, realizar una conmutación por recuperación. Cree un nuevo emparejamiento de recuperación de Geo-Disaster con la región recuperada como secundaria y luego realice otra conmutación por error si desea regresar a la región original. Este proceso implica la posible pérdida de datos de los mensajes enviados al espacio de nombres principal 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 que permanecen en el espacio de nombres principal antes de la conmutación por error son recuperables. 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 la conmutación por error desde el espacio de nombres principal al espacio de nombres secundario y compruebe que las aplicaciones pueden 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. Es posible que estas funcionalidades 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 varios patrones de diseño que proporcionan distintos tipos de compatibilidad con varias regiones en Service Bus. Muchos de estos patrones requieren que implemente varios espacios de nombres y configure la aplicación para usarlos correctamente. Para obtener más información, consulte los siguientes recursos:

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. Durante el traslado, el SDK del cliente se desconecta y, a continuación, se reconecta automáticamente al espacio de nombres. Las actualizaciones normalmente se completan en un plazo de 30 segundos. Es importante que las aplicaciones estén preparadas para las desconexiones de red transitorias que pueden producirse durante períodos de mantenimiento.

Para más información, consulte Eventos de mantenimiento de Azure para Service Bus.

Copias de seguridad y restauración

Service Bus no está diseñado para el almacenamiento de datos a largo plazo. Los datos normalmente se almacenan en un tema o cola durante un breve período de tiempo. Después, se procesa o se conserva en otro sistema de almacenamiento de datos y, a continuación, se elimina. Debido a este diseño, Service Bus mantiene automáticamente réplicas de datos de mensajes, pero no proporciona ninguna funcionalidad de copia de seguridad y restauración para esos datos.

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. El SLA de disponibilidad es mayor cuando el espacio de nombres cumple los siguientes criterios:

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

Contenido relacionado

  • Last updated on