Replicación geográfica de Azure Service Bus

La característica Replicación geográfica de Service Bus es una de las opciones para aislar las aplicaciones de Azure Service Bus frente a interrupciones y desastres, lo que proporciona replicación de metadatos (entidades, configuración, propiedades) y datos (datos de mensajes y cambios de estado o propiedad de mensaje). Puede habilitar Geo-Replication en espacios de nombres nuevos y existentes.

La característica Geo-Replication replica continuamente los metadatos y los datos de un espacio de nombres de una región primaria a una o varias regiones secundarias. Se replica:

  • Colas, temas, suscripciones y filtros.
  • Datos que residen en las entidades.
  • Todos los cambios de estado y los cambios de propiedad aplicados a los mensajes dentro de un espacio de nombres.
  • Configuración del espacio de nombres.

Esta característica le permite promover cualquier región secundaria a primaria, en cualquier momento. La promoción de un punto secundario vuelve a establecer el espacio de nombres en la región secundaria seleccionada y cambia los roles entre la región primaria y la secundaria.

Diagrama que muestra Geo-Replication con una región primaria (Este de EE. UU.) que se replica en una región secundaria (Este de EE. UU. 2), con clientes conectados al principal.

Nota:

  • Esta característica está disponible para el nivel Premium de Azure Service Bus.
  • Actualmente solo se admite una sola región secundaria.

Importante

  • Esta característica no se puede usar en combinación con la característica de recuperación de Azure Service Bus Geo-Disaster.
  • Las siguientes características aún no están disponibles. El equipo del producto está trabajando continuamente para incorporar más características y actualizará esta lista con el estado más reciente.
  • Cuando realiza una conmutación por error, el temporizador de las entidades que tienen habilitada la eliminación automática tras inactividad se restablece y vuelve a iniciarse.
  • Al habilitar la integración de Event Grid en un espacio de nombres que usa replicación geográfica, tenga en cuenta lo siguiente:
    • Event Grid se replica en la ubicación emparejada geográficamente, no en la región secundaria configurada para la replicación geográfica.
    • La promoción de una región secundaria para Service Bus no inicia una conmutación por error de Event Grid. Por lo tanto, después de la promoción, Service Bus ahora se está ejecutando en la nueva región primaria, pero Event Grid se sigue ejecutando en la región primaria inicial.
    • Si quita la región primaria inicial de la configuración de Geo-Replication, esta acción interrumpe la integración de Event Grid.

Comparación con la recuperación ante desastres geográficos

Azure Service Bus ofrece dos características para la resistencia geográfica: Geo-Replication y Geo-Disaster Recovery. La diferencia clave es que Geo-Replication replica tanto los metadatos como los datos (mensajes, estados de mensaje, cambios de propiedad), mientras que Geo-Disaster Recovery replica solo los metadatos. Para la mayoría de los escenarios de recuperación ante desastres, Geo-Replication es la opción recomendada. Para obtener una comparación detallada, consulte Confiabilidad en Azure Service Bus: resistencia a errores de toda la región.

Escenarios

Puede usar la característica Geo-Replication para implementar diferentes escenarios, como se describe en este artículo. Para obtener instrucciones sobre cuándo desencadenar una promoción, consulte Escenarios recomendados para desencadenar la promoción.

Recuperación ante desastres

Las regiones primarias y secundarias sincronizan continuamente los datos y los metadatos. Si la región primaria experimenta una degradación del servicio, puede promover una región secundaria como principal. Esta promoción mantiene las cargas de trabajo en funcionamiento sin interrupciones en la región recién promocionada. Esta promoción puede ser necesaria debido a la degradación de Service Bus u otros servicios dentro de la carga de trabajo, especialmente si tiene como objetivo ejecutar los distintos componentes juntos. Según la gravedad y los servicios afectados, la promoción se puede planear o forzar. En caso de promoción planificada, el proceso replica los mensajes en tránsito antes de finalizar la promoción. La promoción forzada ejecuta inmediatamente la promoción.

Migración de regiones

Es posible que quiera migrar las cargas de trabajo de Service Bus para que se ejecuten en otra región. Por ejemplo, cuando Azure agrega una nueva región que está geográficamente más cerca de la ubicación, los usuarios u otros servicios. Como alternativa, es posible que desee migrar cuando se cambien las regiones donde se ejecutan la mayoría de sus cargas de trabajo. La característica Replicación geográfica también proporciona una buena solución en estos casos. En este caso, configurará Geo-Replication en el espacio de nombres existente con la nueva región deseada como región secundaria y esperará a que se complete la sincronización. Cuando finalice la sincronización, inicie una promoción planeada, que replica los mensajes en curso. Cuando finalice la promoción, puede quitar opcionalmente la región antigua, que ahora es la región secundaria y seguir ejecutando las cargas de trabajo en la región deseada.

Mantenimiento planeado

Durante las actividades de mantenimiento planeado en la región primaria, puede promover la región secundaria para mantener la alta disponibilidad de las aplicaciones críticas. Este enfoque le permite realizar mantenimiento sin afectar a las cargas de trabajo.

Conceptos básicos

La característica Replicación geográfica implementa metadatos y replicación de datos en un modelo de replicación principal-secundaria. En un momento dado, hay una única región primaria que sirve a los productores y consumidores. Las regiones secundarias pueden estar en uno de los dos estados:

  • Secundario activo: región secundaria que forma parte de la configuración de replicación y se replica activamente. Los secundarios activos forman parte del cuórum para la replicación sincrónica. Para obtener más información, consulte el estado Listo en Administración.
  • Secundario inactivo: región secundaria que se está configurando o resincronizando después de una promoción. Los secundarios inactivos no forman parte del cuórum y no afectan a las confirmaciones en modo sincrónico. Para obtener más información, consulte el estado InBuild en Administración.

Las regiones secundarias actúan como regiones de espera activa, lo que significa que no se puede interactuar con estas regiones secundarias. Sin embargo, se ejecutan en la misma configuración que la región primaria, lo que permite una promoción rápida. Sus cargas de trabajo pueden continuar ejecutándose inmediatamente después de la promoción.

Algunos de los aspectos clave de la característica de Geo-Replication son:

  • Los servicios de Service Bus llevan a cabo la replicación completamente gestionada de metadatos, datos de mensajes, y los cambios de estado y propiedades de los mensajes, asegurando la consistencia de replicación configurada en el espacio de nombres, entre distintas regiones.
  • Nombre de host de un único espacio de nombres. Una vez configurado correctamente un espacio de nombres habilitado para georreplicación, use el nombre de host del espacio de nombres en su aplicación cliente. El nombre de host se comporta independiente de las regiones primarias y secundarias configuradas, y siempre apunta a la región primaria.
  • Al iniciar una promoción, el nombre de host apunta a la región seleccionada para que sea la nueva región primaria. La región primaria anterior se convierte en una región secundaria.
  • No es posible leer ni escribir en las regiones secundarias.
  • No se requieren cambios en los SDK del plano de datos ni en las aplicaciones cliente para usar la replicación geográfica.
  • Modos de replicación sincrónicos y asincrónicos, que se describen más aquí.
  • Promoción administrada por el cliente de la región primaria a secundaria, lo que proporciona plena propiedad y visibilidad para la resolución de interrupciones. Las métricas de retardo de replicación están disponibles, que puede usar para supervisar el estado de replicación y automatizar la promoción.
  • Puede agregar o quitar regiones secundarias.
  • Cuando el retardo de replicación alcanza el máximo configurado, se ralentizan las solicitudes del publicador.

Modos de replicación

Hay dos modos de replicación: sincrónicos y asincrónicos. Es importante comprender las diferencias entre los dos modos.

Replicación asincrónica

Cuando se usa la replicación asincrónica, la principal confirma todas las solicitudes y, a continuación, envía una confirmación al cliente. La replicación en las regiones secundarias se produce de forma asincrónica. Puede configurar la cantidad máxima aceptable de tiempo de retraso. El tiempo de retardo es el desplazamiento del lado del servicio entre la acción más reciente en las regiones primarias y secundarias. El servicio replica continuamente los datos y los metadatos, lo que garantiza que el retraso permanece lo más pequeño posible. Si el retraso de una base de datos secundaria activa crece más allá del retraso máximo de replicación configurado por el usuario, la principal inicia la limitación de las solicitudes entrantes.

Replicación sincrónica

Cuando se usa la replicación sincrónica, el sistema confirma todas las solicitudes a las ubicaciones principales y secundarias antes de enviar una confirmación al cliente. Por lo tanto, la aplicación se publica a la velocidad necesaria para confirmar los cambios en todas las regiones. Este proceso también significa que la aplicación depende de la disponibilidad de ambas regiones. Si la región secundaria se retrasa o no está disponible, la región principal no acusa recibo ni confirma los mensajes y limita las solicitudes entrantes.

Comparación del modo de replicación

Con replicación sincrónica:

  • La latencia es más larga debido a las operaciones de confirmación distribuidas.
  • La disponibilidad depende de la disponibilidad de dos regiones.

Por otro lado, la replicación sincrónica proporciona la mayor garantía de que los datos son seguros. Si usa la replicación sincrónica, la operación de confirmación se confirma en todas las regiones configuradas para replicación geográfica, lo que proporciona la mejor garantía de datos.

Con replicación asincrónica :

  • La latencia se ve mínimamente afectada.
  • La pérdida de una región secundaria no afecta inmediatamente a la disponibilidad. Sin embargo, la disponibilidad se ve afectada una vez alcanzado el retraso máximo de replicación configurado.

Como tal, no ofrece la garantía absoluta de que todas las regiones dispongan de los datos antes de confirmar la transacción, como sí ocurre con la replicación sincrónica, y pueden producirse pérdidas o duplicaciones de datos cuando se utiliza una promoción forzada. Sin embargo, dado que ya no se ve afectado inmediatamente cuando una sola región se retrasa o no está disponible, la disponibilidad de la aplicación mejora, además de reducir la latencia.

Capacidad Replicación sincrónica Replicación asincrónica
Latencia Más largo debido a las operaciones de confirmación distribuidas Mínimamente afectado
Disponibilidad Depende de la disponibilidad de las regiones secundarias La pérdida de una región secundaria no afecta inmediatamente a la disponibilidad
Coherencia de datos Los datos siempre se confirman en ambas regiones antes de la confirmación Datos confirmados en la base de datos principal solo antes de la confirmación
RPO (objetivo de punto de recuperación) RPO 0, sin pérdida de datos en la promoción RPO dentro de la latencia configurada, posible pérdida de datos en la promoción forzosa

Puede cambiar el modo de replicación después de configurar la replicación geográfica. Puede cambiar de sincrónico a asincrónico o de asincrónico a sincrónico. Si cambia de asincrónico a sincrónico, la base de datos secundaria se configura como sincrónica después de que el retraso alcance cero. Si está ejecutando con un retraso continuo por cualquier motivo, es posible que tenga que pausar los publicadores para que el retraso alcance cero y el modo cambie a síncrono. Las razones para habilitar la replicación sincrónica en lugar de la replicación asincrónica están vinculadas a la importancia de los datos, las necesidades empresariales específicas o los motivos de cumplimiento, en lugar de la disponibilidad de la aplicación.

Nota:

Si una región secundaria se retrasa o deja de estar disponible, la aplicación ya no se puede replicar a esta región e inicia el estrangulamiento una vez alcanzado el límite del retraso de replicación. Para seguir usando el espacio de nombres en la ubicación principal, quite la región secundaria afectada. Si quita todas las regiones secundarias, el espacio de nombres continúa sin la replicación geográfica habilitada. Puede agregar regiones secundarias adicionales en cualquier momento. Las entidades de nivel superior, que son colas y temas, se replican sincrónicamente, independientemente del modo de replicación que configure. Sin embargo, las suscripciones de tema siguen el modo de replicación seleccionado. Por lo tanto, es fundamental tenerlos en cuenta al decidir el modo de replicación adecuado.

Selección de región secundaria

La característica Geo-Replication depende de la replicación de mensajes publicados de la región principal a la secundaria. Si la región secundaria está en otro continente, esta opción afecta al retraso de replicación desde la región primaria a la secundaria. Si usa Geo-Replication para la disponibilidad, elija regiones secundarias que estén al menos en el mismo continente siempre que sea posible. Para obtener más información sobre la latencia causada por la distancia geográfica, consulte Azure estadísticas de latencia de ida y vuelta de red.

Administración de replicación geográfica

La característica Geo-Replication permite configurar una región secundaria para replicar metadatos y datos. Puede realizar las siguientes tareas de administración:

  • Configurar la replicación geográfica. Puede configurar regiones secundarias en cualquier espacio de nombres nuevo o existente de una región habilitando la característica Geo-Replication.
  • Configure la coherencia de la replicación. Establezca la replicación sincrónica y asincrónica al configurar la replicación geográfica. También puede cambiar esta configuración más adelante.
  • Promoción por desencadenador. Todas las promociones se inician por el cliente.
  • Quitar una región secundaria. Puede eliminar una región secundaria. Se eliminan los datos de la región secundaria.

Configuración

Uso del portal de Azure

En la sección siguiente se proporciona información general sobre la configuración de la característica Geo-Replication en un nuevo espacio de nombres a través de Azure Portal.

  1. Cree un nuevo espacio de nombres de nivel Premium.
  2. Active la casilla Habilitar replicación geográfica en la sección Replicación geográfica .
  3. Seleccione Agregar región secundaria y elija una región.
  4. Active la casilla Replicación sincrónica o especifique un valor para el valor replicación asincrónica: retraso máximo de replicación en minutos. Captura de pantalla que muestra la experiencia Crear espacio de nombres con replicación geográfica habilitada.

Uso de una plantilla

Para crear un espacio de nombres con la característica replicación geográfica habilitada, agregue la sección de propiedades geoDataReplication.

@description('Name of the Service Bus namespace')
param serviceBusName string

@description('Primary location for the namespace')
param primaryLocation string

@description('Secondary location for geo-replication')
param secondaryLocation string

@description('Maximum replication lag in seconds for async replication')
param maxReplicationLagInSeconds int

resource serviceBusNamespace 'Microsoft.ServiceBus/namespaces@2025-05-01-preview' = {
  name: serviceBusName
  location: primaryLocation
  sku: {
    name: 'Premium'
    tier: 'Premium'
    capacity: 1
  }
  properties: {
    geoDataReplication: {
      maxReplicationLagDurationInSeconds: maxReplicationLagInSeconds
      locations: [
        {
          locationName: primaryLocation
          roleType: 'Primary'
        }
        {
          locationName: secondaryLocation
          roleType: 'Secondary'
        }
      ]
    }
  }
}

Administración

Después de crear un espacio de nombres con la característica Geo-Replication habilitada, puede administrar la característica desde la hoja Replicación geográfica .

La región secundaria puede estar en uno de los siguientes estados:

Estado Description
InBuild La región secundaria se está configurando y la sincronización inicial está en curso o la región se vuelve a sincronizar después de una promoción forzada. Las regiones secundarias del estado InBuild no forman parte del cuórum.
Listo La región secundaria forma parte de la configuración de replicación y se replica activamente.
Eliminando La región secundaria está siendo eliminada de la configuración de replicación.

Cambiar el modo de replicación

Para cambiar entre modos de replicación o actualizar el retraso máximo de replicación, seleccione el vínculo en Coherencia de replicación. Active la casilla para habilitar o deshabilitar la replicación sincrónica o actualice el valor en el cuadro de texto para cambiar el retraso de replicación máximo asincrónico. Captura de pantalla que muestra cómo actualizar la configuración de la característica replicación geográfica.

Eliminar región secundaria

Para quitar una región secundaria, seleccione Eliminar y siga las instrucciones de la hoja emergente. Mientras la eliminación está en curso, la región muestra el estado de eliminación . Captura de pantalla que muestra cómo eliminar una región secundaria.

Flujo de promoción

Un cliente desencadena manualmente una promoción (ya sea explícitamente a través de un comando o a través de la lógica de negocios propiedad del cliente que desencadena el comando). Azure nunca desencadena una promoción. Este enfoque proporciona a los clientes la plena propiedad y visibilidad de la resolución de interrupciones en la red troncal de Azure.

Existen dos tipos de promoción:

  • Promoción planeada: el servicio espera a alcanzar el retardo de replicación antes de iniciar la promoción. El espacio de nombres se coloca en modo solo lectura durante este tiempo, rechazando nuevos mensajes y operaciones de consumo hasta que se complete la promoción.
  • Promoción forzada: el servicio inicia inmediatamente la promoción sin esperar a que la replicación se sincronice.

Puedes realizar una promoción forzada en cualquier momento después de que se inicie una promoción planeada, poniéndote en control para acelerar la promoción cuando una promoción planeada tarde más de lo deseado. Sin embargo, el cambio a la promoción forzada conlleva los mismos riesgos de pérdida de datos que iniciar directamente una promoción forzada.

Importante

Al usar la promoción Forced, el servicio podría perder cualquier dato o metadato que no se haya replicado. Además, dado que aún no se replican cambios de estado específicos, esta acción también podría dar lugar a que se reciban mensajes duplicados, como cuando no se ha replicado un cambio de estado Completo o aplazado.

Después de una promoción forzada, el antiguo primario (ahora secundario) contiene todavía datos no replicados. Estos datos se pierden cuando la base de datos principal antigua se vuelve a sincronizar como la nueva secundaria.

Advertencia

Después de realizar una promoción forzada, la región primaria antigua podría contener datos no replicados e incoherencias de estado. Para garantizar la integridad de los datos y evitar posibles problemas con la aplicación, el procedimiento recomendado actual consiste en eliminar la región primaria antigua y volver a crearla en lugar de permitirle resincronizar como secundario.

Pasos recomendados después de la promoción forzada:

  1. Complete la promoción forzada para establecer la nueva región primaria.
  2. Elimine la región primaria antigua de la configuración de Geo-Replication.
  3. Agregue una nueva región secundaria para restaurar la redundancia geográfica.

Seguir estos pasos ayuda a garantizar que el espacio de nombres funciona con datos coherentes en todas las regiones.

Una vez iniciada la promoción:

  1. El nombre de host se actualiza para que apunte a la región secundaria, lo que puede tardar varios minutos.

    Nota:

    Puede comprobar la región primaria actual iniciando un comando ping: ping yout-namespace-fully-qualified-name

  2. Los clientes se vuelven a conectar automáticamente a la región secundaria.

  3. Si se usó la promoción forzada, la nueva región secundaria entra en el estado InBuild mientras se resincroniza y, a continuación, cambia a Listo.

Captura de pantalla del portal que muestra el flujo de promoción de la región primaria a la secundaria.

Puede automatizar la promoción con sistemas de supervisión o con soluciones de supervisión personalizadas. Sin embargo, dicha automatización necesita planeamiento y trabajo extra que se encuentran fuera del ámbito de este artículo.

Uso del portal de Azure

En el portal, seleccione el icono Promover y siga las instrucciones del panel emergente para eliminar la región.

Captura de pantalla que muestra el flujo para promover la región secundaria.

Uso de la CLI de Azure

Ejecute el comando CLI de Azure para iniciar la promoción.

az servicebus namespace failover --namespace-name <your-namespace-name> --resource-group <your-resource-group> --primary-location <new-primary-location>

Supervisión de la replicación de datos

Puede supervisar el progreso del trabajo de replicación comprobando las métricas de retardo de replicación. Para obtener una lista completa de las métricas disponibles, consulte Métricas de Service Bus.

Hay disponibles dos métricas de latencia de replicación, ambas indicadas por entidad (la dimensión EntityName):

  • ReplicationLagDuration – el retraso de replicación en segundos, es decir, cuánto se retrasa la región secundaria con respecto a la primaria. Esta métrica es la métrica recomendada para supervisar el objetivo de punto de recuperación (RPO) y para configurar alertas. Cuando el retraso alcanza el máximo configurado, la principal limita las solicitudes entrantes.
  • ReplicationLagCount : el número de operaciones de replicación pendientes por las que la región secundaria está detrás de la principal. Úselo como un indicador relativo del retraso de replicación: un aumento sostenido significa que la secundaria se está quedando atrás. Este valor refleja las operaciones internas de registro de replicación, no un recuento de mensajes no replicados.

Visualización del retraso de replicación en Azure Portal

Para supervisar el retraso de replicación en el portal de Azure:

  1. Vaya al espacio de nombres Service Bus en el portal de Azure.
  2. Seleccione Métricas en la sección Supervisión .
  3. Seleccione la métrica ReplicationLagDuration en la lista desplegable.
  4. El gráfico muestra el retraso de replicación entre las regiones primarias y secundarias en segundos.

También puede configurar alertas en esta métrica para recibir notificaciones cuando el retraso supera un umbral.

Visualización del retraso de replicación en Log Analytics

Para usar Log Analytics para realizar consultas e análisis históricos:

  1. Active los registros de métricas en el espacio de nombres de Service Bus, como se describe en Supervisión de Azure Service Bus.
  2. Después de habilitar los registros de métricas, debe generar y consumir datos del espacio de nombres durante unos minutos antes de empezar a ver los registros.
  3. Para ver los registros de métricas, vaya a la sección Supervisión de Service Bus y seleccione la hoja Registros. Puede usar la consulta siguiente para buscar el retraso de replicación (en segundos) entre las regiones primarias y secundarias.
AzureMetrics
| where TimeGenerated > ago(1h)
| where MetricName == "ReplicationLagDuration"

Consideraciones

Tenga en cuenta las siguientes consideraciones al usar esta característica:

  • En el planeamiento de la promoción, tenga en cuenta el factor de tiempo. Por ejemplo, si pierde conectividad durante más de 15 a 20 minutos, puede decidir iniciar la promoción.
  • Debe ensayar la promoción de una infraestructura distribuida compleja al menos una vez.

Precios

El nivel Premium de Service Bus tiene un precio por Unidad de mensajería. Con la característica de replicación geográfica, cada réplica se ejecuta en el mismo número de MU que se configura en la región principal, y se le cobra por el total de MU en todas las réplicas. Además, hay un cargo basado en los datos replicados en réplicas secundarias. La velocidad de transferencia de datos viene determinada por la zona donde se encuentra la región primaria en el momento de la replicación. Para más información sobre los precios actuales, incluidas las tarifas de transferencia de datos, consulte la página precios de Service Bus.

Puede calcular el costo total de la siguiente manera:
(número de réplicas x MU configuradas en el sistema primario x horas x tarifa por hora por MU) + (GB replicados x tarifa de transferencia de datos por GB)

Por ejemplo, si tiene 2 MU configuradas en el espacio de nombres principal con 10 GB de datos replicados:
(2 réplicas x 2 MU x horas x tarifa por hora) + (10 GB x velocidad de transferencia de datos)

Aunque puede activar una promoción en cualquier momento, estos son algunos escenarios recomendados en los que es aconsejable promover una instancia secundaria a principal. Para obtener más información sobre cada escenario, consulte Escenarios.

  • Interrupción regional: si hay una interrupción regional que afecta a la región primaria, promueva la región secundaria para garantizar la continuidad empresarial y minimizar el tiempo de inactividad.
  • Degradación del rendimiento: si la región primaria experimenta problemas de rendimiento que afectan a la disponibilidad o confiabilidad del espacio de nombres, la promoción de la región secundaria puede ayudar a mitigar estos problemas.
  • Mantenimiento planeado: durante las actividades de mantenimiento programadas en la región primaria, la promoción de la región secundaria ayuda a mantener la alta disponibilidad.
  • Pruebas de recuperación ante desastres: pruebe periódicamente los mecanismos de conmutación por error para asegurarse de que el plan de continuidad empresarial es eficaz y las aplicaciones pueden cambiar sin problemas a la región secundaria cuando sea necesario.

Migración

Para migrar de recuperación ante desastres geográfica a replicación geográfica, primero interrumpa el emparejamiento en el espacio de nombres principal.

Recorte de pantalla en el que se muestra para hacer clic en el botón Interrumpir emparejamiento en la introducción a la recuperación ante desastres geográficas.

Después de interrumpir el emparejamiento, siga la configuración para habilitar la replicación geográfica.

Puntos de conexión privados

Los clientes que se conectan a un espacio de nombres de Service Bus a través de un punto de conexión privado se conectan automáticamente a la nueva región primaria tras la conmutación por error. El espacio de nombres Service Bus enruta el tráfico a la región principal actual internamente, por lo que los clientes no necesitan saber cuál región es primaria y el endpoint privado sigue funcionando sin cambios. La promoción suele completarse en menos de dos minutos, durante los cuales los clientes pueden detectar errores transitorios y reconectarse. Configura la política de reintentos en consecuencia.

Los endpoints privados son recursos regionales. Para una alta disponibilidad, despliega tu aplicación en múltiples regiones y crea un punto final privado en la red virtual de cada región.

Diagrama que muestra dos redes virtuales, cada una con un punto final privado en el mismo espacio de nombres del Service Bus, y una aplicación que abarca ambos.

DNS

Usa una privatelink.servicebus.windows.net zona DNS privada por región, vinculada solo a la red virtual de esa región. El registro A para el endpoint privado local se añade automáticamente cuando se adjunta un grupo privado de zonas DNS. Cada región resuelve el nombre del espacio de nombres en su punto de conexión local, independientemente de cuál sea la región principal.

Si compartes una única zona DNS privada entre ambas redes virtuales, solo existe un registro A que apunta a aquel endpoint que se asoció por última vez. En ese caso, agrega emparejamiento de redes virtuales entre regiones para que todos los clientes puedan acceder a ese punto de conexión.

Para los clientes locales, resuelva el espacio de nombres al punto de conexión privado de la región más cercana mediante el reenvío condicional o un registro mantenido de forma manual. La promoción no requiere un cambio de DNS local.

Escenarios de conmutación por error

  • Conmutación por error solo de la aplicación. La aplicación se traslada a la otra red virtual. Accede al espacio de nombres a través del extremo privado local.
  • Conmutación por error solo del espacio de nombres. El rol principal de Service Bus se traslada. Los clientes siguen usando la misma cadena de conexión y el mismo punto de conexión local; el tráfico se redirige automáticamente al nuevo primario.
  • Interrupción regional. El punto final privado en la región afectada es inaccesible. Los clientes con un punto de conexión privado en una región correcta siguen funcionando en la región que permanece operativa.

Pasos siguientes

Para más información sobre la mensajería de Service Bus, consulte los siguientes artículos:

  • Last updated on