Replicación geográfica de Azure Event Hubs

La característica de replicación geográfica de Event Hubs proporciona la replicación de metadatos (entidades, configuración y propiedades) y datos (carga útil de eventos) para el espacio de nombres, lo que permite la continuidad empresarial y la recuperación ante desastres.

Esta característica 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 diferentes, como se describe aquí.

Garantizar la 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 global de datos

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 a menudo necesitan 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 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. La base de datos secundaria actúa como una región 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 rápida promoción y están preparados para intervenir una vez que se haya completado dicha promoción.

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

• Modelo de replicación primario-secundario: la replicación geográfica se basa en el modelo de replicación primario-secundario, en el que en un momento dado solo hay un espacio de nombres primario que sirve a los productores y 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 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 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. Las regiones secundarias se pueden agregar o quitar a discreción del cliente.
• Coherencia de replicación: hay dos valores de coherencia de replicación, sincrónico y asincrónico.

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 dos configuraciones de coherencia de replicación, sincrónica y asincrónica. Es importante conocer las diferencias entre las dos configuraciones, ya que tienen un impacto en las aplicaciones y la coherencia de los datos.

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

Con la replicación sincrónica, todas las solicitudes se replican en la secundaria, que debe realizar y confirmar la operación antes de realizarlo 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 de coherencia 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. 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. 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 se retrasa o no está disponible, la disponibilidad de la aplicación mejora, además de reducir la latencia.

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 pasas de asincrónico a sincrónico, la secundaria se configurará como sincrónica después de que el retraso llegue a 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.

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 producida 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 la 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 Geo-Replication habilitada.
• Configurar la coherencia de replicación: la replicación sincrónica y asincrónica se establece cuando se configura Geo-Replication, pero también se puede cambiar después.
• Promoción de desencadenador/conmutación por error: todas las promociones se inician por el cliente.
• Quitar una secundaria : 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.

Criterios para desencadenar la promoción

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

• Interrupción regional: si hay una interrupción regional que afecta a la región primaria, debe promover 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 permanecen accesibles y las aplicaciones siguen 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.

Se recomienda probar ocasionalmente 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

Los usuarios pueden supervisar el progreso del trabajo de replicación supervisando la métrica de retraso de replicación en los registros de métricas de la aplicación.

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

• Una vez que se habiliten los registros de métricas de aplicación, 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 de la aplicación, vaya a la sección Supervisión de la página de Event Hubs y seleccione Registros en el menú de la izquierda. Puede usar la siguiente consulta para buscar el retraso de replicación (en segundos) entre los espacios de nombres primario y secundario.

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

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

Publicar 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 sin replicación geográfica y no se requieren cambios 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 consumidoras pueden acceder a datos usando el nombre de host del espacio de nombres con la función de 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.

Administración de puntos de control y desplazamiento

Las aplicaciones que consumen eventos pueden seguir manteniendo la administración de desplazamientos, ya que lo harían con un espacio de nombres no replicado geográficamente. No se necesita ninguna consideración especial para la administración de desplazamientos para espacios de nombres habilitados para la replicación geográfica.

Kafka

El desplazamiento se confirma directamente en Event Hubs y los desplazamientos se replican entre regiones. Por tanto, los consumidores pueden empezar a consumir desde dónde se dejó en la región primaria.

Esta es la lista de clientes de Apache Kafka admitidos:

En el caso de otras bibliotecas, se admiten las que usan las versiones de API siguientes:

SDK de Event Hubs/AMQP

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

La versión más reciente del SDK de Event Hubs ha realizado algunos cambios en la representación del punto de control para admitir conmutaciones por error. Se recomienda usar las versiones más recientes de los SDK, pero también se admiten versiones anteriores de los SDK siguientes.

Consideraciones

Tenga en cuenta las siguientes consideraciones que debe tener en cuenta con esta característica:

• 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 ser probada 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

El uso de la replicación geográfica con Event Hubs dedicado requiere que tenga al menos dos clústeres dedicados en regiones independientes, que se pueden usar para hospedar espacios de nombres distintos de los que se replican geográficamente. Estos clústeres dedicados se facturan por separado en función del número de unidades de capacidad (RU) asignadas a cada uno.

Cuando se habilita la replicación geográfica, el único cargo adicional es el cargo de ancho de banda para 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, la habilitación de la replicación geográfica aprovisiona el mismo número de unidades de procesamiento (RU) en la región secundaria. Por lo tanto, paga por el número de PUs que está usando y el ancho de banda para los datos transferidos entre la región primaria y secundaria.

Por ejemplo, si habilita la replicación geográfica en un espacio de nombres Premium que se ha aprovisionado con 4 PU, se le facturará 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.

El ancho de banda se cobra en función de los datos transferidos entre las regiones primarias y secundarias.

Medidores de precios

Los medidos de precio del cargo de ancho de banda para la transferencia de datos de replicación geográfica se mostrarán con los siguientes detalles:

Puntos de conexión privados

En esta sección se proporcionan consideraciones adicionales al usar Geo-Replication 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 Integración de Azure Event Hubs con Azure Private Link.

Al implementar Geo-Replication para un espacio de nombres de Event Hubs que usa puntos de conexión privados, es importante crear puntos de conexión privados para las regiones primarias y secundarias. Estos puntos de conexión deben configurarse 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. Además, las redes virtuales deben configurarse con el emparejamiento entre regiones, de modo que los clientes puedan comunicarse con cualquiera de los puntos de conexión privados. Por último, el DNS debe administrarse de forma que todos los clientes obtengan la información de DNS, que debe apuntar 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.

La ventaja de este enfoque es que la conmutación por error puede producirse de forma independiente en el nivel 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 de solo espacio de nombres de Event Hubs: de forma similar, si la conmutación por error solo se produce en el nivel de 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.

Al seguir estas instrucciones, puede garantizar mecanismos de conmutación por error sólidos y confiables para los espacios de nombres de Event Hubs mediante 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.