Recuperación ante desastres geográficos de Azure Event Hubs

La recuperación ante desastres geográfica es una característica de recuperación ante desastres en Azure Event Hubs que replica continuamente la configuración del espacio de nombres (centros de eventos, grupos de consumidores y configuraciones) desde un espacio de nombres principal a un espacio de nombres secundario. Esta funcionalidad le permite iniciar un failover desde el espacio de nombres primario al secundario durante interrupciones regionales.

Nota:

En este artículo se describe la característica de recuperación ante desastres geográfica que replica solo los metadatos. Para obtener información sobre la característica de replicación geográfica, que replica datos y metadatos, consulte Replicación geográfica.

El modelo de clúster de Azure Event Hubs activo con compatibilidad con zona de disponibilidad proporciona resistencia frente a interrupciones de hardware y centro de datos. Sin embargo, si se produce un desastre en el que una región completa y todas las zonas no están disponibles, puede usar la recuperación ante desastres geográfica para recuperar la configuración de la carga de trabajo y la aplicación.

Los conceptos y el flujo de trabajo descritos en este artículo se aplican a escenarios de desastres, no a interrupciones temporales. Para obtener una explicación detallada de la recuperación ante desastres en Microsoft Azure, consulte Disaster recovery for Azure applications. Con la recuperación ante desastres geográfica, puede iniciar una conmutación por error de solo una vez desde la base de datos principal a la secundaria en cualquier momento. El movimiento de conmutación por error apunta el nombre de alias elegido para el espacio de nombres al espacio de nombres secundario. Una vez realizado el movimiento, se elimina el emparejamiento. La conmutación por error es casi instantánea una vez que se ha iniciado.

Importante

  • La característica permite la continuidad instantánea de las operaciones con la misma configuración, pero no replica los datos de eventos. A menos que el desastre haya causado la pérdida de todas las zonas, los datos de eventos que se conservan en el centro de eventos principal son recuperables después de la conmutación por error, y los eventos históricos se pueden obtener desde allí una vez que se restablezca el acceso. Para replicar los datos de eventos y operar los espacios de nombres correspondientes en configuraciones de tipo activo/activo a fin de hacer frente a interrupciones y desastres, no se incline por este conjunto de características de recuperación ante desastres geográfica. En su lugar, siga la guía de replicación.
  • Las asignaciones de control de acceso basado en rol (RBAC) de Microsoft Entra a entidades en el espacio de nombres principal no se replican en el espacio de nombres secundario. Cree asignaciones de roles manualmente en el espacio de nombres secundario para proteger el acceso a estas.

Para configurar el emparejamiento de recuperación ante desastres geográfica e iniciar la conmutación por error, consulte Configuración de recuperación ante desastres geográfica.

Términos y conceptos básicos

La característica de recuperación ante desastres implementa la recuperación ante desastres de metadatos y depende de espacios de nombres de recuperación ante desastres principales y secundarios. La característica de recuperación ante desastres geográfica solo está disponible para los niveles estándar, Premium y dedicado . No es necesario realizar ningún cambio de la cadena de conexión, ya que la conexión se realiza a través de un alias.

Los siguientes términos se utilizan en este artículo:

  • Alias: el nombre para una configuración de recuperación ante desastres que ha configurado. El alias proporciona una sola cadena de conexión estable de nombre de dominio completo (FQDN). Las aplicaciones usan esta cadena de conexión de alias para conectarse a un espacio de nombres.
  • Espacio de nombres principal o secundario: los espacios de nombres que corresponden al alias. El espacio de nombres principal está activo y recibe mensajes (puede ser un espacio de nombres existente o nuevo). El espacio de nombres secundario es pasivo y no recibe mensajes. Los metadatos entre ambos están sincronizados, por lo que ambos pueden aceptar sin problemas mensajes sin ningún cambio de código de la aplicación o cadena de conexión. Para asegurarse de que solo el espacio de nombres activo recibe mensajes, tiene que utilizar el alias.
  • Metadatos: Entidades como event hubs y grupos de consumidores, y sus propiedades del servicio que están asociados al espacio de nombres. Solo las entidades y sus valores se replican automáticamente. No se replican los mensajes ni los eventos.
  • Conmutación por error: El proceso de activación del espacio de nombres secundario.

Pares de espacios de nombres admitidos

Se admiten las siguientes combinaciones de espacios de nombres principales y secundarios:

Nivel de espacio de nombres principal Nivel de espacio de nombres secundario permitido
Estándar Estándar, dedicado
Premium Premium
Dedicado Dedicado

Importante

No se pueden emparejar espacios de nombres que se encuentran en el mismo clúster dedicado. Puede emparejar espacios de nombres que se encuentran en clústeres independientes.

Consideraciones sobre la conmutación por error

Al planear la conmutación por error, tenga en cuenta los siguientes puntos:

  • Por diseño, la recuperación ante desastres geográfica de Event Hubs no replica los datos. Por lo tanto, no puede reutilizar el valor de desplazamiento anterior del centro de eventos principal en el centro de eventos secundario. Reinicie el receptor de eventos mediante uno de los métodos siguientes:

    • EventPosition.FromStart(): si desea leer todos los datos del centro de eventos secundario.
    • EventPosition.FromEnd(): si desea leer todos los datos nuevos desde el momento de la conexión al centro de eventos secundario.
    • EventPosition.FromEnqueuedTime(dateTime): si desea leer todos los datos recibidos en el centro de eventos secundario a partir de una fecha y hora determinada.

  • Tenga presente el factor de tiempo en la planificación de la conmutación por error. Por ejemplo, si se pierde la conectividad durante más de 15 a 20 minutos, puede decidir iniciar la conmutación por error.

  • Dado que no se replica ningún dato, las sesiones activas actuales no se replican. Además, la detección de duplicados y los mensajes programados podrían no funcionar. Funcionan las nuevas sesiones, los mensajes programados y los duplicados nuevos.

  • De ensayar la conmutación por error en una compleja infraestructura distribuida al menos una vez.

  • La sincronización de entidades puede tardar algún tiempo, aproximadamente 50-100 entidades por minuto.

  • Algunos aspectos del plano de administración del espacio de nombres secundario se convierten en de solo lectura mientras el emparejamiento de recuperación geográfica está activo.

  • El plano de datos del espacio de nombres secundario es de solo lectura mientras el emparejamiento de recuperación geográfica está activo. El plano de datos del espacio de nombres secundario acepta solicitudes GET para habilitar la validación de controles de acceso y conectividad de cliente.

Puntos de conexión privados

En esta sección se proporcionan aspectos que hay que tener en cuenta cuando se usa la recuperación ante desastres geográfica con espacios de nombres que emplean puntos de conexión privados. Para obtener información sobre el uso de puntos de conexión privados con Event Hubs en general, consulte Configuración de puntos de conexión privados.

Nuevos emparejamientos

Si intenta crear un emparejamiento entre un espacio de nombres principal con un punto de conexión privado y un espacio de nombres secundario sin él, se producirá un error. El emparejamiento solo tendrá éxito si los espacios de nombres principal y secundario tienen puntos de conexión privados. Use las mismas configuraciones en los espacios de nombres principal y secundario y en las redes virtuales donde cree puntos de conexión privados.

Nota:

Al intentar emparejar el espacio de nombres principal con un punto de conexión privado y un espacio de nombres secundario, el proceso de validación solo comprueba si existe un punto de conexión privado en el espacio de nombres secundario. No comprueba si el punto de conexión funciona ahora o funcionará después de la conmutación por error. Es su responsabilidad asegurarse de que el espacio de nombres secundario con el punto de conexión privado funcione según lo esperado después de la conmutación por error.

Para probar que las configuraciones de punto de conexión privado son las mismas en los espacios de nombres principal y secundario, envíe una solicitud de lectura (por ejemplo: Get Event Hub) al espacio de nombres secundario desde fuera de la red virtual y compruebe que recibe un mensaje de error del servicio.

Emparejamientos existentes

Si ya existe un emparejamiento entre el espacio de nombres principal y el secundario, se produce un error en la creación del punto de conexión privado en el espacio de nombres principal. Para resolver el error, cree primero un punto de conexión privado en el espacio de nombres secundario y, a continuación, cree uno para el espacio de nombres principal.

Nota:

Aunque puede acceder al espacio de nombres secundario en modo de solo lectura, puede actualizar las configuraciones del punto de conexión privado.

Al crear una configuración de recuperación ante desastres para los espacios de nombres de la aplicación y Event Hubs, cree puntos de conexión privados para los espacios de nombres de Event Hubs principal y secundario. Estos puntos de conexión privados se conectan a redes virtuales que hospedan instancias principales y secundarias de la aplicación.

Supongamos que tiene dos redes virtuales, VNET-1 y VNET-2, y estos espacios de nombres principales y secundarios: EventHubs-Namespace1-Primary y EventHubs-Namespace2-Secondary. Lleve a cabo los pasos siguientes:

  • En EventHubs-Namespace1-Primary, cree dos puntos de conexión privados que usen subredes de VNET-1 y VNET-2
  • En EventHubs-Namespace2-Secondary, cree dos puntos de conexión privados que usen las mismas subredes de VNET-1 y VNET-2

Puntos de conexión privados y redes virtuales

La ventaja de este enfoque es que la conmutación por error puede producirse en el nivel de aplicación independiente del espacio de nombres de Event Hubs. Considere los casos siguientes:

Conmutación por error solo de la aplicación: En este escenario, la aplicación no existe en VNET-1, pero se mueve a VNET-2. Dado que ambos 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 funciona sin problemas.

Conmutación por error solo del espacio de nombres de Event Hubs: en este escenario, dado que los dos puntos de conexión privados están configurados en ambas redes virtuales para los espacios de nombres primario y secundario, la aplicación funciona.

Nota:

Para obtener instrucciones sobre la recuperación ante desastres con localización geográfica de una red virtual, consulte Virtual Network: continuidad del negocio.

Control de acceso basado en roles (RBAC)

Las asignaciones de control de acceso basado en rol (RBAC) de Microsoft Entra a entidades en el espacio de nombres principal no se replican en el espacio de nombres secundario. Cree asignaciones de roles manualmente en el espacio de nombres secundario para proteger el acceso a estas.

Contenido relacionado

  • Last updated on