Replicación geográfica (versión preliminar pública)

Hay dos características que proporcionan recuperación ante desastres geográfica en Azure Event Hubs.

• Recuperación ante desastres geográfica (DR de metadatos), que proporciona replicación de solo metadatos.
• Replicación geográfica (versión preliminar pública), que proporciona replicación de los metadatos y los datos.

Estas características no deben confundirse con Availability Zones. Ambas características de recuperación geográfica proporcionan resistencia entre regiones de Azure como Este de EE. UU. y Oeste de EE. UU. La compatibilidad con la zona de disponibilidad proporciona resistencia dentro de una región geográfica específica, como Este de EE. UU. Para más información sobre las zonas de disponibilidad, consulte Soporte de zonas de disponibilidad de Event Hubs.

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

Recuperación ante desastres de metadatos frente a Replicación geográfica de metadatos y datos

La característica DR de metadatos replica la información de configuración de un espacio de nombres de un espacio de nombres primario a un espacio de nombres secundario. Admite una conmutación por error única en la región secundaria. Durante la conmutación por error iniciada por el cliente, el nombre de alias del espacio de nombres se redirecciona al espacio de nombres secundario y después se rompe el emparejamiento. No se replican más datos que la información de configuración ni se replican las asignaciones de permisos.

La nueva característica de replicación geográfica replica la información de configuración y todos los datos de un espacio de nombres primario a uno, o más espacios de nombres secundarios. Cuando se realiza una conmutación por error, el secundario seleccionado pasa a ser el primario y el primario anterior se convierte en secundario. Los usuarios pueden realizar una conmutación por error volviendo al primario original cuando lo deseen.

El resto de este artículo se centra en las características de la replicación geográfica. Para más detalles sobre la característica DR de metadatos, lea Recuperación ante desastres geográfica para metadatos de Event Hubs.

Replicación geográfica

La versión preliminar pública de la característica de replicación geográfica es compatible con los espacios de nombres en los clústeres dedicados de escalado de autoservicio de Event Hubs. Esta característica se puede usar con espacios de nombres nuevos o ya existentes en clústeres de autoservicio dedicados. Las siguientes características no se admiten con la replicación geográfica:

• Claves administradas por el cliente (CMK)
• Identidad administrada para la captura
• Características de red virtual (puntos de conexión de servicio o puntos de conexión privados)
• Compatibilidad con mensajes grandes (ahora en versión preliminar pública)
• Transacciones de Kafka (ahora en versión preliminar pública)

Algunos de los aspectos clave de la versión preliminar pública de replicación de datos geográfica 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 dominio completo (FQDN) estable del espacio de nombres: el FQDN no tiene por qué cambiar cuando se realiza la promoción.
• Coherencia de replicación: hay dos valores de coherencia de replicación, sincrónico y asincrónico.
• Promoción administrada por el usuario de un secundario a ser el nuevo primario.

El cambio de un secundario a ser un nuevo primario se realiza de dos maneras:

• Planeada: una promoción de secundaria a primaria en la que el tráfico no se procesa hasta que la nueva primaria se pone al día con todos los datos de la anterior instancia primaria.
• Forzada: como una conmutación por error en la que la secundaria se convierte en primaria lo más rápido posible. La característica de replicación geográfica replica todos los datos y metadatos de la región primaria a las regiones secundarias seleccionadas. El FQDN del espacio de nombres siempre apunta a la región primaria.

Cuando inicia la promoción de una secundaria, el FQDN apunta a la región seleccionada para ser la nueva primaria. La antigua primaria se convierte entonces en secundaria. Puede promover su secundaria para que sea la nueva primaria por razones distintas a una conmutación por error. Esas razones pueden incluir actualizaciones de aplicaciones, pruebas de conmutación por error o cualquier otra cosa. En esas situaciones, es habitual volver a cambiar cuando se completan esas actividades.

Las regiones secundarias se agregan o quitan a discreción del cliente. Hay algunas limitaciones actuales que merece la pena tener en cuenta:

• No hay capacidad para admitir vistas de solo lectura en regiones secundarias.
• No hay ninguna funcionalidad de promoción o conmutación por error automática. Todas las promociones son iniciadas por el cliente.
• Las regiones secundarias deben ser diferentes de la región primaria. No puede seleccionar otro clúster dedicado en la misma región.
• Solo se admite una base de datos secundaria para la versión preliminar pública.

Coherencia de la 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 habilitada, todos los mensajes se confirman en la primaria y después se envían a la secundaria. Los usuarios pueden configurar una cantidad aceptable de tiempo de retraso que tiene la secundaria para ponerse al día. Cuando el retraso de una secundaria activa es superior a la configuración del retraso del usuario, la región primaria limita las solicitudes de publicación entrantes.

Replicación sincrónica

Cuando se habilita la replicación sincrónica, los eventos publicados se replican en la secundaria, que debe confirmar el mensaje antes de que se confirme en la primaria. Con la replicación sincrónica, su aplicación publica al ritmo que tarda en publicar, replicar, reconocer y confirmar. También significa que la aplicación está vinculada a la disponibilidad de ambas regiones. Si la región secundaria deja de funcionar, los mensajes no se pueden reconocer ni confirmar.

Comparación de coherencia de replicación

Con la replicación sincrónica:

• La latencia es mayor debido a la confirmación distribuida.
• La disponibilidad está vinculada a la disponibilidad de dos regiones. Si una región deja de funcionar, el espacio de nombres no está disponible.
• Los datos recibidos siempre residen en al menos dos regiones (solo dos regiones admitidas en la versión preliminar pública inicial).

La replicación sincrónica proporciona la mayor garantía de que los datos son seguros. Si tiene replicación sincrónica, cuando se confirma, se confirma en todas las regiones configuradas para la replicación geográfica. Sin embargo, cuando la replicación sincrónica está habilitada, la disponibilidad de la aplicación se puede reducir debido a la disponibilidad de ambas regiones.

La habilitación de la replicación asincrónica no afecta mucho a la latencia y la disponibilidad del servicio no se ve afectada por la pérdida de una región secundaria. La replicación asincrónica no tiene la garantía absoluta de que todas las regiones tengan los datos antes de confirmarlos, como lo hace la replicación sincrónica. También puede establecer la cantidad de tiempo que la base de datos secundaria puede estar sin sincronización antes de que se limite el tráfico entrante. La configuración puede ser de 5 minutos a 1 440 minutos, que es un día. Si desea usar regiones con una gran distancia entre ellas, es probable que la replicación asincrónica sea la mejor opción para usted.

La configuración de coherencia de la replicación puede cambiar después de la configuración de replicación geográfica. Puede pasar de sincrónica a asincrónica, o de asincrónica a sincrónica. Si pasa de sincrónica a asincrónica, su latencia y la disponibilidad de la aplicación mejoran. Si pasa de asincrónica a sincrónica, su secundaria se configura como sincrónica una vez que el desfase llega 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 generales para tener habilitada la replicación sincrónica están vinculadas a la importancia de los datos, necesidades empresariales específicas o motivos de cumplimiento. Si su objetivo principal es la disponibilidad de la aplicación más que la seguridad de los datos, es probable que la coherencia asincrónica sea la mejor opción.

Selección de región secundaria

Para habilitar la característica de replicación geográfica, es necesario usar una región primaria y otra secundaria en las que esté habilitada esta característica. También debe tener un clúster de Event Hubs ya existente en las regiones primarias y secundarias.

La característica de replicación geográfica depende de poder replicar eventos publicados de la región principal a la secundaria. Si la región secundaria está en otro continente, 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 y confiabilidad, es mejor que las regiones secundarias estén al menos en el mismo continente siempre que sea posible. Para comprender mejor la latencia inducida por la distancia geográfica, puede obtener más información en Estadísticas de latencia de ida y vuelta de la red de Azure | Microsoft Learn.

Administración de replicación geográfica

La característica de replicación geográfica permite configurar una región secundaria a la que replicar la configuración y los datos. Puede:

• Configurar la replicación geográfica: las regiones secundarias pueden configurarse en cualquier espacio de nombres existente en un clúster dedicado de autoservicio en una región con el conjunto de características de replicación geográfica habilitado. También se puede configurar durante la creación del espacio de nombres en los mismos clústeres dedicados. Para seleccionar una región secundaria, debe tener un clúster dedicado disponible en esa región secundaria y la región secundaria también debe tener habilitada la característica de replicación geográfica para esa región.
• 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. Con la coherencia asincrónica, puede configurar la cantidad de tiempo que se permite que se retrase una región secundaria.
• Desencadenar la promoción/conmutación por error: todas las promociones o conmutaciones por error son iniciadas por el cliente. Durante la promoción puede elegir que sea Forzada desde el principio, o incluso cambiar de opinión una vez iniciada la promoción y hacerla forzada.
• Quitar una secundaria: si en cualquier momento desea quitar el emparejamiento geográfico entre regiones primarias y secundarias, puede hacerlo y se eliminarán los datos de la región secundaria.

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

Las aplicaciones de publicación de eventos pueden publicar datos en espacios de nombres replicados geográficamente a través de FQDN de espacio de nombres estables del espacio de nombres replicado geográficamente. El enfoque de publicación de eventos es el mismo que el caso de recuperación ante desastres no geográficos y no se requieren cambios en las aplicaciones cliente.

Es posible que la publicación de eventos no esté disponible durante las siguientes circunstancias:

• Durante el período de gracia de conmutación por error, 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 que consumen eventos pueden usar datos usando el FQDN estable de un espacio de nombres con replicación geográfica. Las operaciones de consumo no son compatibles, desde que se inicia la conmutación hasta su finalización.

Administración de puntos de control y desplazamiento

Las aplicaciones que consumen eventos pueden seguir administrando los desplazamientos como lo harían con un único espacio de nombres.

Kafka

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

SDK de Event Hubs/AMQP

Los clientes que usan el SDK de Event Hubs deben actualizar a la versión de abril de 2024 del SDK. La versión más reciente del SDK de Event Hubs admite la conmutación por error con una actualización del punto de control. 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.

Precios

Los clústeres dedicados de Event Hubs tienen un precio independientemente de la replicación geográfica. El uso de la replicación geográfica con Event Hubs dedicado requiere que tenga al menos dos clústeres dedicados en regiones independientes. Los clústeres dedicados que se usan como instancias secundarias para la replicación geográfica se pueden usar para otras cargas de trabajo. Hay un cargo por la replicación geográfica en función del ancho de banda publicado * el número de regiones secundarias. En la versión preliminar pública no se cobra la tasa de replicación geográfica.

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.