Replicación geográfica de Azure Service Bus (versión preliminar)
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).
Nota:
Esta característica está disponible para el nivel Premium de Azure Service Bus.
La característica Replicación geográfica garantiza que los metadatos y los datos de un espacio de nombres se repliquen continuamente desde una región primaria a una o varias regiones secundarias.
- Colas, temas, suscripciones, filtros.
- Datos, que residen en las entidades.
- Todos los cambios de estado y los cambios de propiedad ejecutados en los mensajes de un espacio de nombres.
- Configuración del espacio de nombres.
Nota:
Actualmente solo se admite una base de datos secundaria.
Esta característica permite promover cualquier región secundaria a primaria en cualquier momento. La promoción de un punto secundario vuelve a establecer el nombre del espacio de nombres en la región secundaria seleccionada y cambia los roles entre la región primaria y la secundaria. La promoción es casi instantánea una vez iniciada.
Importante
- Esta característica se encuentra actualmente en versión preliminar pública y, por tanto, no debe usarse en escenarios de producción.
- Las regiones siguientes se admiten actualmente en la versión preliminar pública.
Region | Region | Region |
---|---|---|
Centro de Australia | AlemaniaNorte | NoruegaOeste |
AustraliaCentral2 | GermanyWestCentral | PoloniaCentro |
AustraliaEast | IsraelCentral | SouthAfricaNorth |
AustraliaSoutheast | ItalyNorth | SouthAfricaWest |
BrazilSoutheast | JapanEast | SoutheastAsia |
CanadaCentral | JapanWest | SouthIndia |
Este de Canadá | JioIndiaCentral | SpainCentral |
CentralIndia | JioIndiaWest | SwedenCentral |
CentralUS | KoreaCentral | SuizaNorte |
CentralUSEUAP | KoreaSouth | SuizaOeste |
EastAsia | MexicoCentral | UAECentral |
EastUS2 | NorthCentralUS | UAENorth |
FranceCentral | Norte de Europa | UKSouth |
FranceSouth | NorwayEast | UKWest |
- Esta característica está disponible actualmente en nuevos espacios de nombres. Si un espacio de nombres tenía habilitada esta característica antes, se puede deshabilitar (quitando las regiones secundarias) y volver a habilitarla.
- Actualmente no se admiten las siguientes características. Estamos trabajando continuamente para incorporar más características a la versión preliminar pública y actualizaremos esta lista con el estado más reciente.
- Compatibilidad con mensajes grandes.
- Características de red virtual o avanzadas (puntos de conexión privados, ACL de IP, NSP, puntos de conexión de servicio).
- Identidades (MSI, deshabilitar la autenticación local) y la configuración de cifrado (cifrado de clave administrada por el cliente (CMK) o traiga su propia clave (BYOK).
- Escalabilidad automática.
- Espacios de nombres con particiones.
- Enviar eventos a Event Grid.
- Esta característica no se puede usar en combinación con la característica de recuperación ante desastres geográfica de Azure Service Bus.
Escenarios
La característica de replicación geográfica se puede usar para implementar diferentes escenarios, como se describe aquí.
Recuperación ante desastres
Los datos y los metadatos se sincronizan continuamente entre las regiones primarias y secundarias. Si una región no está disponible o no está disponible, es posible promover una región secundaria como principal. Esta promoción permite el funcionamiento ininterrumpido de las cargas de trabajo en la región recién promocionada. Esta promoción puede ser necesaria por degradación de Service Bus u otros servicios dentro de la carga de trabajo, especialmente si tiene como objetivo ejecutar los distintos componentes juntos. Dependiendo de la gravedad y los servicios afectados, la promoción podría planearse o forzarse. En el caso de los mensajes de promoción planeados en curso se replican antes de finalizar la promoción, mientras que con la promoción forzada se ejecuta inmediatamente.
Migración de regiones
Hay ocasiones en las que desea 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 quiera migrar cuando se cambie la mayoría de las regiones en las que se ejecuta la mayoría de las cargas de trabajo. La característica Replicación geográfica también proporciona una buena solución en estos casos. En este caso, configuraría la replicación geográfica en el espacio de nombres existente con la nueva región deseada como región secundaria y esperaría a que se complete la sincronización. En este momento, iniciaría una promoción planeada, lo que permite replicar los mensajes en curso. Una vez completada la promoción, ahora 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.
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 sola región primaria, que sirve tanto a los productores como a los consumidores. Las secundarias actúan como regiones de espera activa, lo que significa que no es posible 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, lo que significa que las cargas de trabajo pueden continuar ejecutándose inmediatamente después de que se haya completado la promoción. La característica Replicación geográfica está disponible para el nivel Premium.
Algunos de los aspectos clave de la característica de replicación geográfica son:
- Los servicios de Service Bus realizan la replicación totalmente administrada de metadatos, datos de mensajes y cambios de estado de mensaje y propiedades entre regiones que cumplen la coherencia de replicación configurada en el espacio de nombres.
- Nombre de host de espacio de nombres único; Tras una configuración correcta de un espacio de nombres habilitado para replicación geográfica, los usuarios pueden usar 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.
- Cuando un cliente inicia una promoción, el nombre de host apunta a la región seleccionada para que sea la nueva región primaria. La principal anterior se convierte en una región secundaria.
- No es posible leer ni escribir en las regiones secundarias.
- 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 están disponibles, lo que puede ayudar a automatizar la promoción desde el lado del cliente.
- Las regiones secundarias se pueden agregar o quitar a discreción del cliente.
Modos de replicación
Hay dos modos de replicación, sincrónicos y asincrónicos. Es importante conocer las diferencias entre los dos modos.
Replicación asincrónica
Con la replicación asincrónica, todas las solicitudes se confirman en la principal, después de lo cual se envía una confirmación al cliente. La replicación en las regiones secundarias se produce de forma asincrónica. Los usuarios pueden 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. Si el retraso de una base de datos secundaria activa crece más allá de la configuración del usuario, la principal inicia la limitación de las solicitudes entrantes.
Replicación sincrónica
Con la replicación sincrónica, todas las solicitudes se replican en la base de datos secundaria, que debe confirmar y confirmar la operación antes de confirmar en la principal. Por lo tanto, la aplicación se publica a la velocidad que se tarda en publicar, replicar, reconocer y confirmar. Además, también significa que la aplicación está vinculada a la disponibilidad de ambas regiones. Si la región secundaria deja de estar disponible o no está disponible, los mensajes no se reconocerán y confirmarán, y la principal limitará las solicitudes entrantes.
Comparación del modo de replicación
Con replicación sincrónica:
- La latencia es mayor debido a las operaciones de confirmación distribuidas.
- La disponibilidad está vinculada a 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 tiene replicación sincrónica, cuando la confirmamos, 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 afectada mínimamente.
- 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.
Por lo tanto, no tiene la garantía absoluta de que todas las regiones tienen los datos antes de confirmarlos, como lo hace la replicación sincrónica, y se pueden producir pérdidas de datos o duplicación. Sin embargo, dado que ya no se ve afectado inmediatamente cuando una sola región no está disponible o no está disponible, la disponibilidad de la aplicación mejora, además de tener una latencia menor.
Funcionalidad | Replicación sincrónica | Replicación asincrónica |
---|---|---|
Latencia | Más tiempo debido a las operaciones de confirmación distribuidas | Mínimamente afectado |
Disponibilidad | Vinculado a 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 > 0, posible pérdida de datos en la promoción |
El modo de replicación se puede cambiar después de configurar la replicación geográfica. Puede ir de sincrónico a asincrónico o asincrónico a sincrónico. Si va de asincrónico a sincrónico, la base de datos secundaria se configurará como sincrónica después de que el retraso alcance cero. Si se 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 pueda cambiar a sincrónico. Las razones para tener habilitada 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:
En caso de que una región secundaria se alejen o deje de estar disponible, la aplicación ya no podrá replicarse en esta región y comenzará a limitarse una vez alcanzado el retraso de replicación. Para seguir usando el espacio de nombres en la ubicación principal, se puede quitar la región secundaria afectada. Si no se configuran más regiones secundarias, el espacio de nombres continuará sin la replicación geográfica habilitada. Es posible agregar regiones secundarias adicionales en cualquier momento.
Selección de región secundaria
Para habilitar la característica replicación geográfica, debe usar las regiones primarias y secundarias en las que está habilitada la característica. La característica Replicación geográfica depende de poder replicar mensajes publicados desde la región principal a la secundaria. Si la región secundaria está en otro continente, esto tiene un gran impacto en el retraso de replicación desde la región primaria a la secundaria. Si usa la replicación geográfica por motivos de disponibilidad, es mejor que las regiones secundarias estén al menos en el mismo continente siempre que sea posible. Para comprender mejor la latencia provocada por la distancia geográfica, puede obtener más información sobre las estadísticas de latencia de ida y vuelta de red de Azure.
Administración de replicación geográfica
La característica Replicación geográfica permite a los clientes configurar una región secundaria hacia la que replicar metadatos y datos. Por lo tanto, los clientes pueden realizar las siguientes tareas de administración:
- Configurar replicación geográfica; Las regiones secundarias se pueden configurar en cualquier espacio de nombres nuevo o existente de una región con la característica replicación geográfica habilitada.
Nota:
Actualmente, en la versión preliminar pública solo se admiten nuevos espacios de nombres.
- Configurar la coherencia de la replicación; la replicación sincrónica y asincrónica se establece cuando se configura la replicación geográfica, pero también se puede cambiar después.
- Promoción de desencadenador; Todas las promociones se inician por el cliente.
- Quitar un secundario; Si en cualquier momento desea quitar una región secundaria, puede hacerlo después de la cual se eliminan los datos de la región secundaria.
Configurar
Uso de Azure Portal
La siguiente sección es una introducción a la configuración de la característica replicación geográfica en un nuevo espacio de nombres a través de Azure Portal.
Nota:
Esta experiencia puede cambiar durante la versión preliminar pública. Actualizaremos este documento en consecuencia.
- Cree un nuevo espacio de nombres de nivel Premium.
- Active la casillaHabilitar replicación geográfica en la sección Replicación de (versión preliminar).
- Haga clic en el botón Agregar región secundaria y elija una región.
- Active la casilla Replicación sincrónica o especifique un valor para el valor de replicación asincrónica de : Retraso máximo de replicación en segundos.
Usar plantilla de Bicep
Para crear un espacio de nombres con la característica replicación geográfica habilitada, agregue la sección de propiedades geoDataReplication.
param serviceBusName string
param primaryLocation string
param secondaryLocation string
param maxReplicationLagInSeconds int
resource sb 'Microsoft.ServiceBus/namespaces@2023-01-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
Una vez creado un espacio de nombres con la característica Replicación geográfica habilitada, puede administrar la característica desde la hoja Replicación (versión preliminar).
Cambiar el modo de replicación
Para cambiar entre los modos de replicación o actualizar el retraso máximo de replicación, haga clic en el vínculo de Coherencia de replicación, y haga clic en 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.
Eliminar región secundaria
Para quitar una región secundaria, haga clic en el ...puntos suspensivos junto a la región y haga clic en Eliminar. Para eliminar la región, siga las instrucciones de la hoja emergente.
Flujo de promoción
El 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) y nunca por Azure. Esto otorga al cliente una propiedad y visibilidad total para la resolución de interrupciones en la red troncal de Azure. Al elegir Promoción Planeada, el servicio espera a ponerse al día del retraso de replicación antes de iniciar la promoción. Por otro lado, al elegir promoción Forzada, el servicio inicia inmediatamente la promoción. El espacio de nombres se colocará en modo de solo lectura desde el momento en que se solicita una promoción hasta el momento en que se haya completado la promoción. Es posible realizar una promoción forzada en cualquier momento después de iniciar una promoción planeada. Esto pone al usuario en control para acelerar la promoción, cuando una conmutación por error planeada tarda más de lo deseado.
Importante
Al usar promoción Forzada, es posible que se pierdan los datos que no se hayan replicado.
Una vez iniciada la promoción:
El nombre de host se actualiza para que apunte a la región secundaria, lo que puede tardar hasta unos minutos.
Nota:
Puede comprobar la región primaria actual iniciando un comando ping: ping su-namespace-fully-qualified-name
Los clientes se vuelven a conectar automáticamente a la región 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 de Azure Portal
En el portal, haga clic en el icono Promover, y siga las instrucciones de la hoja emergente para eliminar la región.
Uso de la CLI de Azure
Ejecute el comando de la CLI de Azure para iniciar la promoción. La propiedad Force es opcional y el valor predeterminado es false.
az rest --method post --url https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.ServiceBus/namespaces/<namespaceName>/failover?api-version=2023-01-01-preview --body "{'properties': {'PrimaryLocation': '<newPrimaryocation>', 'api-version':'2023-01-01-preview', 'Force':'false'}}"
Supervisión de la replicación de datos
Los usuarios pueden supervisar el progreso del trabajo de replicación mediante la supervisión de la métrica de retraso de replicación en Log Analytics.
- Habilite los registros de métricas en el espacio de nombres de Service Bus como se describe en Monitor Azure Service Bus.
- Una vez habilitados los registros de métricas, debe generar y consumir datos del espacio de nombres durante unos minutos antes de empezar a ver los registros.
- Para ver los registros de métricas, vaya a la sección Supervisión de Service Bus y haga clic en 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"
Publicación de datos
La publicación de aplicaciones puede publicar datos en espacios de nombres replicados geográficamente a través del nombre de host del espacio de nombres habilitado para replicación geográfica. El enfoque de publicación es el mismo que el caso que no es replicación geográfica y no se requieren cambios en los SDK del plano de datos o las aplicaciones cliente. Es posible que la publicación no esté disponible durante las siguientes circunstancias:
- Después de solicitar la promoción de una región secundaria, la región primaria existente rechaza los nuevos mensajes publicados en Service Bus hasta que se haya completado la promoción.
- Cuando el retraso de replicación entre las regiones primarias y secundarias alcanza la duración máxima del retraso de replicación, la carga de trabajo de entrada del publicador se puede limitar.
Las aplicaciones del publicador no pueden acceder directamente a ningún espacio de nombres en las regiones secundarias.
Consumo de datos
El consumo de aplicaciones puede consumir datos mediante el nombre de host del espacio de nombres de un espacio de nombres con la característica replicación geográfica habilitada. Las operaciones de consumidor no se admiten desde el momento en que se inicia la promoción hasta que se completa la promoción.
Consideraciones
Tenga en cuenta y recuerde las siguientes consideraciones para esta versión:
- En la planificación de la promoción, también debe tener 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.
- La promoción de una infraestructura distribuida compleja debe ensayar al menos una vez.
Precios
El nivel Premium de Service Bus tiene un precio por Unidad de mensajería. Con la característica Replicación geográfica, las regiones secundarias se ejecutan en el mismo número de MU que la región primaria y los precios se calculan en el número total de MU de administración. Además, se cobra según el ancho de banda publicado el número de regiones secundarias. Durante la versión preliminar pública anticipada, este cargo se renuncia.
Pasos siguientes
- Vea la referencia de la API de REST de replicación geográfica aquí.
- Ejecute el ejemplo de replicación geográfica en GitHub.
- Vea el ejemplo de replicación geográfica que envía mensajes a un alias.
Para más información sobre la mensajería de Service Bus, consulte los siguientes artículos: