Replicación geográfica en Azure Event Hubs

La replicación geográfica de Azure Event Hubs mantiene copias de los metadatos del espacio de nombres (entidades, configuración y propiedades) y datos de eventos en varias regiones de Azure. Si la región primaria experimenta una interrupción, puede promover una región secundaria para mantener las aplicaciones de streaming en ejecución con una pérdida de datos mínima.

En las secciones siguientes se explica cómo funciona la replicación geográfica, se comparan los modos de replicación sincrónicos y asincrónicos y se describe cómo administrar regiones secundarias.

La 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 la región secundaria. Se puede considerar que el espacio de nombres se extiende a más de una región, y una región es la principal y la otra es la secundaria.

En cualquier momento, la región secundaria se puede promover para convertirse en una región primaria. La promoción de un punto secundario vuelve a seleccionar el FQDN del espacio de nombres (nombre de dominio completo) en la región secundaria seleccionada y la región primaria anterior se degrada a una región secundaria.

Escenarios

La replicación geográfica de Event Hubs se puede usar en varios escenarios.

Continuidad empresarial y recuperación ante desastres

La replicación geográfica asegura la recuperación ante desastres y la continuidad empresarial para todos los datos de streaming en el espacio de nombres. Al replicar datos entre regiones, las organizaciones pueden proteger contra la pérdida de datos y asegurarse de que sus aplicaciones permanecen operativas incluso en caso de interrupción regional. Esta característica es fundamental para las aplicaciones críticas que requieren alta disponibilidad y un tiempo de inactividad mínimo.

Distribución de datos global

La replicación geográfica se puede usar para distribuir datos globalmente, lo que permite a las aplicaciones acceder a datos desde la región más cercana. Esto reduce la latencia y mejora el rendimiento de las cargas de trabajo ubicadas en diferentes partes del mundo.

Soberanía y cumplimiento de datos

Las organizaciones que operan en varios países o regiones suelen necesitar cumplir con las leyes de soberanía de datos que requieren que los datos se almacenen dentro de límites geográficos específicos. La replicación geográfica permite que estas organizaciones repliquen datos en regiones que cumplan las normativas locales, lo que garantiza que cumplen los requisitos legales, a la vez que mantienen una plataforma de datos unificada.

Migración y actualizaciones

La replicación geográfica también se puede usar para facilitar la migración de datos, el mantenimiento y las actualizaciones del sistema. Las organizaciones pueden migrar su espacio de nombres de forma proactiva de una región primaria a una secundaria para permitir cualquier mantenimiento y actualización en la región primaria.

Conceptos básicos

La característica de replicación geográfica usa un modelo de replicación principal-secundaria para replicar metadatos y datos. En un momento dado, hay una única región primaria que sirve tanto a productores como a consumidores. La región secundaria actúa como una región en espera activa (hot standby), por lo cual no se puede interactuar con la región secundaria. Sin embargo, se ejecuta en la misma configuración que la región primaria, lo que significa que puede asumir rápidamente su función después de ser promovida.

Algunos de los aspectos clave de la característica de replicación geográfica son:

• Modelo de replicación secundaria principal: la replicación geográfica se basa en un modelo de replicación principal-secundaria, donde en un momento dado solo hay un espacio de nombres principal que sirve a los productores de eventos y a los consumidores de eventos.
• Event Hubs realiza la replicación de byte a byte totalmente administrada de metadatos, datos de eventos y desplazamiento del consumidor entre secundarios con los niveles de coherencia configurados.
• Nombre de host único del espacio de nombres: Una vez que haya configurado correctamente un espacio de nombres habilitado para replicación geográfica, utilice 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.
• 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.
• Puede agregar o quitar regiones secundarias.
• Coherencia de replicación: hay dos opciones de coherencia de replicación disponibles: sincrónicas y asincrónicas.

Estado	Diagrama
Antes de la conmutación por error (promoción de la secundaria)
Después de la conmutación por error (promoción de la secundaria)

Modos de replicación

Hay disponibles dos configuraciones de coherencia de replicación: sincrónicas y asincrónicas. Comprenda las diferencias entre estas dos configuraciones porque afectan a las aplicaciones y a la coherencia de los datos.

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 el retardo máximo aceptable. es decir, el desfase del servicio entre la última acción realizada en la región principal y la secundaria. 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 envía todas las solicitudes a la ubicación secundaria. La ubicación secundaria realiza el compromiso y confirma la operación antes de que la ubicación principal haga su compromiso. Como resultado, la aplicación publica a la velocidad que se requiere para publicar, replicar, reconocer y confirmar. Este proceso significa que la aplicación depende de la disponibilidad de ambas regiones. Si la región secundaria se retrasa o no está disponible, la ubicación principal no reconoce ni confirma los mensajes y ralentiza las solicitudes entrantes.

Comparación de coherencia de replicación

Con replicación sincrónica:

• La latencia es mayor debido a las operaciones de confirmación distribuidas.
• La disponibilidad depende de la disponibilidad de dos regiones. Si una región deja de funcionar, el espacio de nombres no está disponible.

Por otro lado, la replicación sincrónica proporciona la mayor garantía de que los datos son seguros. Con la replicación sincrónica, los datos se confirman en todas las regiones configuradas para la 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.

Por lo tanto, no tiene la garantía absoluta de que todas las regiones tengan los datos antes de que se produzca la confirmación, como la replicación sincrónica, y podría producirse una pérdida o duplicación de datos. Sin embargo, dado que ya no se ve afectado inmediatamente cuando una sola región experimenta latencia o no está disponible, la disponibilidad de la aplicación mejora, además de lograr una menor latencia.

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 región secundaria se configura como sincrónica después de que el retraso alcance cero. Si, por cualquier motivo, experimenta un retardo constante, es posible que deba poner en pausa sus editores hasta que el retraso llegue a cero y el modo pueda cambiar 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.

Selección de región secundaria

Para habilitar la característica de replicación geográfica, use las regiones primarias y secundarias donde está habilitada la característica. La característica de 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, esta opción tiene un impacto importante 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, elija regiones secundarias en el mismo continente siempre que sea posible. Para comprender mejor la latencia provocada por la distancia geográfica, consulte las estadísticas de latencia de ida y vuelta de la red de Azure.

Administración de replicación geográfica

La característica de replicación geográfica permite configurar una región secundaria hacia la que replicar metadatos y datos. Por lo tanto, 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 de replicación geográfica.
• Configurar la coherencia de 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 de desencadenador/conmutación por error: todas las promociones se inician por el cliente.
• Quitar una secundaria : si desea quitar una región secundaria, puede hacerlo. Se eliminan los datos de la región secundaria.

Criterios para desencadenar la promoción

Estos son algunos casos en los que se puede desencadenar una promoción de secundaria a principal.

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

• Actividades de mantenimiento: durante las actividades de mantenimiento planeadas en la región primaria, la promoción de la región secundaria puede ayudar a mantener la alta disponibilidad para las aplicaciones críticas.

• Recuperación ante desastres: en caso de desastre que afecte a la región primaria, la promoción de la región secundaria garantiza que los datos sigan siendo accesibles y las aplicaciones sigan funcionando.

• Problemas de rendimiento: si la región primaria experimenta problemas de rendimiento que afectan a la disponibilidad o confiabilidad de Event Hubs, la promoción de la región secundaria puede ayudar a mitigar estos problemas.

En ocasiones, pruebe 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.

Supervisión de la replicación de datos

Puede supervisar el progreso del trabajo de replicación comprobando la métrica de retardo de replicación en los registros de métricas de aplicación.

• Habilite los registros de métricas de aplicación en el espacio de nombres de Event Hubs siguiendo Supervisión de Azure Event Hubs: Azure Event Hubs | Microsoft Learn.

• Una vez habilitados los registros de métricas de aplicaciones, genere y utilice datos del espacio de nombres durante unos minutos antes de que comience a ver los registros.

• Para ver los registros de métricas de aplicación, vaya a la sección Supervisión de la página Event Hubs y seleccione Registros en el menú de la izquierda. Utilice la siguiente consulta para buscar el retraso de replicación (en segundos) entre los espacios de nombres principal y secundario.

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag"
  

• La columna count_d muestra el retraso de replicación en segundos entre la región primaria y la secundaria.

Publicación de datos

Las aplicaciones de publicación pueden enviar datos a espacios de nombres con replicación geográfica a través del nombre de host del espacio de nombres habilitado para la replicación geográfica. El enfoque de publicación es el mismo que el caso de replicación no geográfica. No es necesario realizar ningún cambio en los SDK del plano de datos ni en las aplicaciones cliente.

Es posible que la publicación de eventos 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 eventos publicados en el centro de eventos.
• 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

Las aplicaciones pueden consumir datos utilizando el nombre de host del espacio de nombres de un espacio de nombres con la característica de replicación geográfica habilitada. No se admiten operaciones de los consumidores desde el inicio de la promoción hasta su finalización.

Administración de puntos de control y desfases

Las aplicaciones que consumen eventos pueden mantener la gestión del desfase de la misma manera que lo hacen con un espacio de nombres sin replicación geográfica. Los espacios de nombres con replicación geográfica no requieren ninguna consideración especial en cuanto a la administración de desfases.

Kafka

Los consumidores confirman los desfases directamente en Event Hubs y el sistema replica los desfases a través de regiones. Por lo tanto, los consumidores pueden empezar a consumir desde dónde dejaron en la región primaria.

Esta es una lista de clientes de Apache Kafka compatibles:

Para otras bibliotecas, la compatibilidad depende de la versión de la API:

SDK de Event Hubs y AMQP

Para AMQP, los usuarios administran el punto de control mediante un almacén de puntos de control, como Azure Blob Storage o una solución de almacenamiento personalizada. En caso de conmutación por error, la región secundaria debe disponer del almacén de puntos de control para que los clientes puedan recuperar los datos de los puntos de control y evitar la pérdida de mensajes.

La versión más reciente del SDK de Event Hubs incluye cambios en la representación del punto de comprobación para admitir conmutaciones por error. Use las versiones más recientes de los SDK, pero también se admiten versiones anteriores de los siguientes SDK.

Consideraciones

Tenga en cuenta las siguientes consideraciones:

• 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

Los precios varían en función del nivel que elija, pero generalmente tiene dos parámetros:

• Costo de computación para el clúster o espacio de nombres.
• Costo por ancho de banda para los datos replicados entre las regiones primaria y secundaria.

Clústeres dedicados

Al usar la replicación geográfica con clústeres dedicados de Event Hubs, necesita al menos dos clústeres dedicados en regiones independientes. Puede usar estos clústeres para hospedar espacios de nombres distintos de los que se replican geográficamente. Paga por estos clústeres dedicados por separado en función del número de unidades de capacidad (RU) asignadas a cada uno.

Al habilitar la replicación geográfica, el único cargo adicional es el cargo de ancho de banda de los datos replicados de principal a secundario. Este cargo depende de la ubicación de la región primaria.

Espacios de nombres Premium

En el caso de los espacios de nombres Premium, al habilitar la replicación geográfica, obtendrá el mismo número de unidades de procesamiento (RU) en la región secundaria. Paga por el número de PU que usa y el ancho de banda para los datos transferidos entre la región primaria y la secundaria.

Por ejemplo, si habilita la replicación geográfica en un espacio de nombres prémium que aprovisionó con 4 PU, paga por

• 4 PU en la región primaria,
• 4 PUs en la región secundaria
• Cargo de replicación geográfica por GB de datos replicados.

Los cargos de ancho de banda se pagan en función de los datos transferidos entre las regiones primarias y secundarias.

Medidores de precios

Los indicadores de precios para el cargo por ancho de banda de transferencia de datos de replicación geográfica se presentan con los siguientes detalles:

Puntos de conexión privados

En esta sección se proporcionan consideraciones adicionales cuando se use la replicación geográfica con espacios de nombres que usan puntos de conexión privados. Para obtener información general sobre el uso de puntos de conexión privados con Event Hubs, consulte Integrate Azure Event Hubs con Azure Private Link.

Al implementar la replicación geográfica para un espacio de nombres de Event Hubs que usa puntos de conexión privados, cree puntos de conexión privados para las regiones primarias y secundarias. Configure estos puntos de conexión en redes virtuales que hospedan instancias principales y secundarias de la aplicación. Por ejemplo, si tiene dos redes virtuales, VNET-1 y VNET-2, debe crear dos puntos de conexión privados en el espacio de nombres de Event Hubs, mediante subredes de VNET-1 y VNET-2, respectivamente. Configure las redes virtuales con emparejamiento entre regiones para que los clientes puedan comunicarse con cualquiera de los puntos de conexión privados. Por último, administre el DNS para que todos los clientes obtengan la información de DNS que apunta el punto de conexión del espacio de nombres (namespacename.servicebus.windows.net) a la dirección IP del punto de conexión privado en la región primaria actual.

Este enfoque ofrece la ventaja de que la conmutación por error puede realizarse de forma independiente, ya sea en la capa de aplicación o en el espacio de nombres de Event Hubs:

• Conmutación por error de solo aplicación: en este escenario, la aplicación pasa de VNET-1 a VNET-2. Dado que los puntos de conexión privados están configurados en VNET-1 y VNET-2 para los espacios de nombres principal y secundario, la aplicación sigue funcionando sin problemas.
• Conmutación por error solo a nivel del espacio de nombres de Event Hubs: Si la conmutación por error solo se produce a nivel del espacio de nombres de Event Hubs, la aplicación permanece operativa porque los puntos de conexión privados están configurados en ambas redes virtuales.

Si sigue estas directrices, podrá garantizar mecanismos de conmutación por error sólidos y fiables para los espacios de nombres de Event Hubs que utilicen puntos de conexión privados.

Contenido relacionado

Para obtener información sobre cómo usar la característica de replicación geográfica, consulte Uso de la replicación geográfica.