Confiabilidad en Azure Event Hubs

Azure Event Hubs es un servicio en la nube nativo que puede transmitir millones de eventos por segundo con baja latencia, desde cualquier origen a cualquier destino. Use Event Hubs para ingerir y almacenar datos de streaming e integrarlos con aplicaciones cliente creadas para Apache Kafka o aplicaciones que usan los SDK de cliente de Event Hubs.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo Event Hubs es resistente a una variedad de posibles interrupciones y problemas, y cómo puede configurarlo para que sea resistente a otros usuarios, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones de región. También se describen las opciones de copia de seguridad y recuperación, y se resalta cierta información clave sobre el contrato de nivel de servicio (SLA) de Azure Event Hubs.

Recomendaciones de implementación de producción

Para obtener información sobre cómo implementar Event Hubs para admitir los requisitos de confiabilidad de la solución y comprender cómo afecta la confiabilidad a otros aspectos de la arquitectura, consulte Procedimientos recomendados de arquitectura para Event Hubs en Azure Well-Architected Framework.

Introducción a la arquitectura de confiabilidad

En esta sección se describen aspectos importantes sobre cómo funciona Event Hubs desde una perspectiva de confiabilidad. Presenta la arquitectura lógica, que incluye recursos y características que se implementan y usan. También se explica la arquitectura física, que proporciona detalles sobre cómo el servicio administra las operaciones internamente.

Arquitectura lógica

Un espacio de nombres de Event Hubs actúa como contenedor de administración para uno o varios centros de eventos. Configure el servicio, como asignar capacidad de streaming, configurar la seguridad de red y habilitar la resistencia geográfica y la recuperación ante desastres geográficas, en el nivel de espacio de nombres.

Dentro de un espacio de nombres, puede organizar eventos en un centro de eventos. El ecosistema de Apache® Kafka hace referencia a este tipo de entidad como tema. El centro de eventos o tema es un registro distribuido de solo adición de tus eventos.

Cada centro de eventos contiene una o varias particiones, que son registros de eventos secuenciales. Un centro de eventos puede usar varias particiones para realizar el procesamiento paralelo y el escalado horizontal. Event Hubs solo garantiza la ordenación dentro de una sola partición. La creación de particiones desempeña un papel clave en el diseño de confiabilidad de la aplicación. Al diseñar la aplicación, realice un equilibrio entre maximizar la disponibilidad y la coherencia. Para maximizar el tiempo de actividad de la mayoría de las aplicaciones, evite direccionar particiones directamente desde las aplicaciones cliente. Para más información, consulte Disponibilidad y coherencia en Event Hubs.

Los consumidores que leen desde el centro de eventos pueden leer sus eventos secuencialmente manteniendo su propio punto de control, que identifica el último evento que reciben.

Para más información sobre las particiones y otros conceptos fundamentales de Event Hubs, consulte Características y terminología en Event Hubs.

Arquitectura física

En la arquitectura física, un espacio de nombres de Event Hubs se ejecuta dentro de un clúster. Un clúster proporciona los recursos de proceso y almacenamiento subyacentes. La mayoría de los espacios de nombres se ejecutan en clústeres compartidos por otros clientes de Azure. Cuando se usa el nivel Premium, el espacio de nombres se asigna a recursos dedicados dentro de un clúster compartido. Cuando usas el nivel Dedicado, un clúster se asigna exclusivamente a tus espacios de nombres. Para más información sobre los clústeres dedicados, consulte Introducción al nivel dedicado de Event Hubs. Independientemente del tipo de clúster y del nivel, Microsoft administra los clústeres y sus máquinas virtuales y almacenamiento subyacentes.

Para lograr redundancia, cada clúster tiene varias réplicas que procesan solicitudes de lectura y escritura. Para optimizar la alta disponibilidad y el rendimiento, todos los datos se almacenan en tres réplicas de almacenamiento. Para escalar los recursos de proceso del espacio de nombres, implemente unidades de rendimiento (TUs), unidades de procesamiento (PUs) o unidades de capacidad (CUs), en función del nivel. Para más información, consulte Escalado con Event Hubs.

Los clústeres abarcan varias máquinas físicas y bastidores, lo que reduce el riesgo de errores catastróficos que afectan al espacio de nombres. En las regiones que tienen zonas de disponibilidad, los clústeres se extienden entre centros de datos físicos independientes. Para obtener más información, consulte Resilience to availability zone failures (Resistencia a errores de zona de disponibilidad).

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Event Hubs implementa mecanismos transparentes de detección de errores y conmutación por error para que el servicio siga funcionando dentro de los niveles de servicio garantizados, normalmente sin interrupciones perceptibles cuando se produzcan errores.

Al diseñar aplicaciones cliente para trabajar con Event Hubs, siga estas instrucciones:

• Utilice políticas de reintento integradas. Los SDK de Event Hubs y Apache Kafka reintentan automáticamente las operaciones para errores que se pueden reintentar, como tiempos de espera en la red, respuestas de limitación, o cuando el servidor está ocupado. Para evitar sobrecargar innecesariamente el servicio, implementan el retroceso exponencial de forma predeterminada.

• Configure los valores de tiempo de espera adecuados en función de los requisitos de la aplicación. El tiempo de espera predeterminado suele ser de 60 segundos, pero puede ajustarlo en función de su escenario.

• Implemente puntos de control en el procesador de eventos para realizar un seguimiento del progreso y habilitar la recuperación desde la última posición procesada después de errores transitorios.

• Use el procesamiento por lotes para las operaciones de envío para mejorar el rendimiento y reducir el impacto de los problemas de red transitorios en mensajes individuales.

• Use los SDK de Apache Kafka si trabaja con el protocolo Kafka. Los SDK de Kafka también implementan directivas de reintento y otros procedimientos recomendados que ayudan a controlar errores transitorios.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.

Event Hubs admite implementaciones con redundancia de zona en todos los niveles de servicio. Al crear un espacio de nombres de Event Hubs en una región admitida, la redundancia de zona se habilita automáticamente sin costo adicional. Pero con el nivel Dedicado, las zonas de disponibilidad solo son compatibles con un mínimo de tres CUs. El modelo de implementación con redundancia de zona se aplica a todas las características de Event Hubs, incluida la compatibilidad con el protocolo Capture, Schema Registry y Kafka.

Event Hubs replica de forma transparente los datos de configuración, metadatos y eventos en tres zonas de disponibilidad de la región. La redundancia de zona proporciona conmutación automática por error sin requerir intervención de su parte. Todos los componentes de Event Hubs, incluidos el proceso, las redes y el almacenamiento, se replican entre zonas. Event Hubs tiene suficientes reservas de capacidad para controlar instantáneamente la pérdida completa de una zona. Incluso si una zona de disponibilidad completa deja de estar disponible, Event Hubs sigue funcionando sin pérdida de datos ni interrupción en las aplicaciones de streaming.

Soporte para regiones

Los espacios de nombres de Event Hubs con redundancia de zona se pueden implementar en cualquier región de Azure que admita zonas de disponibilidad.

Requisitos

• Los niveles Estándar y Premium admiten zonas de disponibilidad sin ninguna configuración adicional necesaria.

• En el nivel dedicado, las zonas de disponibilidad requieren un mínimo de tres CUs.

Cost

La redundancia de zona en Event Hubs no agrega ningún costo adicional.

Configurar soporte de zonas de disponibilidad

Los espacios de nombres de Event Hubs admiten automáticamente la redundancia de zona cuando se implementan en regiones admitidas. No es necesario realizar ninguna otra configuración.

Comportamiento cuando todas las zonas están en buen estado

Cuando los espacios de nombres de Event Hubs usan redundancia de zona y todas las zonas de disponibilidad funcionan normalmente, espere el siguiente comportamiento:

• Enrutamiento de tráfico entre zonas: Event Hubs funciona en un modelo activo-activo donde la infraestructura de tres zonas de disponibilidad procesa simultáneamente eventos entrantes.

• Replicación de datos entre zonas: Event Hubs usa la replicación sincrónica entre zonas de disponibilidad. Cuando un productor de eventos envía un evento, Event Hubs lo escribe en réplicas en varias zonas antes de confirmar al cliente que la operación de escritura se ha completado. Este enfoque garantiza una pérdida de datos cero, incluso si una zona completa deja de estar disponible. El enfoque de replicación sincrónica proporciona garantías de coherencia sólidas al tiempo que mantiene una baja latencia a través de protocolos de replicación optimizados.

Comportamiento durante un fallo de zona

Cuando los espacios de nombres de Event Hubs utilizan redundancia de zona y ocurre una interrupción en una zona de disponibilidad, se debe esperar el siguiente comportamiento:

• Detección y respuesta: Event Hubs es responsable de detectar automáticamente un error en una zona de disponibilidad. No es necesario iniciar una conmutación por error de zona.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Durante un error de zona, Event Hubs podría quitar las solicitudes activas. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

• Pérdida de datos esperada: No se produce ninguna pérdida de datos durante un error de zona porque Event Hubs replica de forma sincrónica eventos entre zonas antes de la confirmación.

• Tiempo de inactividad esperado: Un error de zona puede provocar unos segundos de tiempo de inactividad. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

• Reenrutamiento del tráfico: Event Hubs detecta la pérdida de la zona y redirige automáticamente las nuevas solicitudes a otra réplica en una de las zonas de disponibilidad correctas.

  Los SDK de cliente de Event Hubs normalmente controlan la administración de conexiones y la lógica de reintento de forma transparente.

Recuperación de zona

Cuando se recupera una zona de disponibilidad, Event Hubs reintegra automáticamente la zona a la topología activa del servicio. La zona recuperada comienza a aceptar nuevas conexiones y procesar eventos junto con las demás zonas. Los datos que se han replicado en zonas supervivientes durante la interrupción permanecen intactos y la replicación sincrónica normal se reanuda en todas las zonas. No es necesario tomar medidas para la recuperación y la reintegración de zonas.

Prueba de fallos de zona

Dado que IoT Hub administra completamente el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para los errores de zona, no es necesario validar los procesos de error de zona de disponibilidad ni proporcionar ninguna entrada adicional.

Resistencia a errores en toda la región

Event Hubs proporciona dos tipos de compatibilidad con varias regiones:

• La replicación geográfica (niveles Premium y Dedicado) proporciona replicación activa-activa de metadatos y datos de eventos entre una región primaria y una o varias regiones secundarias. Use la replicación geográfica para la mayoría de las aplicaciones que necesitan permanecer resistentes a las interrupciones de la región y tener una tolerancia baja para la pérdida de datos de eventos.

• La recuperación ante desastres geográfica de metadatos (nivel Estándar y superior) proporciona la replicación activa-pasiva de la configuración y los metadatos entre una región primaria y secundaria, pero no replica los datos de eventos. Use la recuperación ante desastres geográficas para las aplicaciones que pueden tolerar la pérdida de datos de eventos durante un escenario de desastre y que necesite reanudar rápidamente las operaciones en otra región.

Tanto la replicación geográfica como la recuperación geográfica de desastres de metadatos requieren que usted inicie manualmente la conmutación por error o la promoción de una región secundaria para que se convierta en la nueva región primaria. Microsoft no realiza automáticamente la conmutación por error ni la promoción, incluso si la región primaria está inactiva.

Replicación geográfica

Los niveles Premium y Dedicado admiten la replicación geográfica. Esta característica replica ambos metadatos (como entidades, configuración y propiedades) y datos (como cargas de eventos) para el espacio de nombres. Tú configuras el enfoque de replicación para la configuración del espacio de nombres y los datos de eventos. Esta característica garantiza que los eventos permanecen disponibles en otra región y le permite cambiar a la región secundaria cuando sea necesario. También replica los metadatos y los datos del Registro de esquemas.

Use la replicación geográfica para escenarios que requieran resistencia a interrupciones de regiones y que tengan una tolerancia baja para la pérdida de datos de eventos.

El espacio de nombres se extiende esencialmente entre regiones. Una región actúa como principal y las demás regiones sirven como secundarias. La suscripción de Azure muestra un único espacio de nombres, independientemente de cuántas regiones secundarias configure para la replicación geográfica.

En cualquier momento, puede promover una región secundaria a una región primaria. Al promover una región secundaria, Event Hubs redirige el nombre de dominio completo (FQDN) del espacio de nombres a la región secundaria seleccionada y degrada la región primaria anterior a una región secundaria. Decide si desea realizar una promoción planeada, lo que significa que espera a que se complete la replicación de datos o una promoción forzada, lo que podría provocar la pérdida de datos.

En esta sección se resumen aspectos importantes de la replicación geográfica. Revise la documentación completa para comprender exactamente cómo funciona. Para más información, consulte Replicación geográfica de Event Hubs.

Soporte para regiones

Puede elegir cualquier región de Azure que admita Event Hubs como región primaria o regiones secundarias. No es necesario usar regiones emparejadas de Azure, por lo que puede elegir regiones secundarias en función de los requisitos de latencia, cumplimiento o residencia de datos.

Requisitos

Para habilitar la replicación geográfica, el espacio de nombres debe usar el nivel Premium o Dedicado.

Consideraciones

Al habilitar la replicación geográfica, tenga en cuenta los siguientes factores:

• Formato de punto de comprobación: El formato de los puntos de control cambia. Para más información, consulte Replicación geográfica: Consumo de datos.

• Puntos de conexión privados: Si usa puntos de conexión privados para conectarse al espacio de nombres, también debe configurar las redes en las regiones primarias y secundarias. Para obtener más información, consulte Puntos de conexión privados.

Cost

Para comprender cómo funcionan los precios para la replicación geográfica, consulte Precios.

Configuración de la compatibilidad con varias regiones

• Habilite la replicación geográfica en un espacio de nombres nuevo o existente. Para configurar la replicación activa-activa para un espacio de nombres recién creado, consulte Habilitación de la replicación geográfica en un nuevo espacio de nombres. Para configurar la replicación activa-activa en un espacio de nombres existente, consulte Habilitación de la replicación geográfica en un espacio de nombres existente.

• Cambie el enfoque de replicación. Para cambiar entre modos de replicación sincrónicos y asincrónicos, consulte Cambiar modo de replicación.

• Deshabilitar la replicación geográfica. Para deshabilitar la replicación geográfica en una región secundaria, consulte Eliminación de una región secundaria.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando se configura un espacio de nombres de Event Hubs para la replicación geográfica y la región primaria está operativa.

• Enrutamiento del tráfico entre regiones: Las aplicaciones cliente se conectan a través del FQDN de su espacio de nombres, y su tráfico se dirige a la región primaria.

  Solo la región primaria procesa activamente los eventos de los clientes durante las operaciones normales. La región secundaria recibe eventos replicados, pero de lo contrario permanece pasiva en modo de espera.

• Replicación de datos entre regiones: El comportamiento de replicación de datos entre las regiones principal y secundaria depende de si configura el emparejamiento de replicación para usar la replicación sincrónica o asincrónica.

  • Síncrono: Los eventos se replican en la región secundaria antes de que se complete la operación de escritura.

    Este modo proporciona la mayor seguridad de que los datos del evento están seguros, ya que deben confirmarse tanto en la región primaria como en la secundaria. Sin embargo, la replicación sincrónica aumenta considerablemente la latencia de escritura para los eventos entrantes. También requiere que la región secundaria esté disponible para aceptar la operación de escritura, por lo que una interrupción en cualquier región secundaria hace que se produzca un error en la operación de escritura.

    • Asíncrono: Los eventos se escriben en la región primaria y, a continuación, se completa la operación de escritura. Poco tiempo después, replica los eventos en la región secundaria.

    Este modo proporciona un mayor rendimiento de escritura que la replicación sincrónica porque no hay ninguna latencia de replicación entre regiones durante las operaciones de escritura. Además, el modo de replicación asincrónica puede tolerar la pérdida de una región secundaria, a la vez que permite operaciones de escritura en la región primaria. Sin embargo, si la región primaria tiene una interrupción, es posible que los datos que aún no se hayan replicado en la región secundaria no estén disponibles o se pierdan.

    Al configurar la replicación asincrónica, establezca el retardo máximo aceptable que puede tener la replicación. En cualquier momento, puede comprobar el retraso de replicación actual mediante métricas de Azure Monitor.

    Si el retraso de replicación asincrónico aumenta más allá del máximo especificado, la región primaria comienza a limitar las solicitudes entrantes para que la replicación pueda alcanzar el nivel deseado. Para evitar esta situación, es importante seleccionar regiones secundarias que no estén demasiado distantes geográficamente y asegurarse de que la capacidad sea suficiente para el rendimiento.

    Para obtener más información, consulte Modos de replicación.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando se configura un espacio de nombres de Event Hubs para la replicación geográfica y se produce una interrupción en la región principal o secundaria.

• Detección y respuesta: Usted es responsable de decidir cuándo promover la región secundaria del espacio de nombres para convertirse en la nueva región primaria. Microsoft no toma esta decisión ni inicia el proceso por ti, incluso si hay una interrupción de la región. Para obtener más información sobre cómo promover una región secundaria a la nueva principal, consulte Promover secundaria.

  Al promover una región secundaria, elija si desea realizar una promoción planeada o una promoción forzada. Una promoción planeada espera a que la región secundaria se ponga al día antes de aceptar nuevo tráfico. Este enfoque elimina la pérdida de datos, pero presenta tiempo de inactividad.

  Durante una interrupción en la región principal, típicamente usted necesita realizar una promoción forzada. Si la región primaria está disponible y activa una promoción por otro motivo específico, podría elegir una promoción planeada.

• Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

  Use esa información y otras métricas para decidir cuándo promover una región secundaria a una región primaria.

• Solicitudes activas: El comportamiento depende de si la interrupción de la región se produce en la región primaria o en una región secundaria:

  • Interrupción de la región primaria: Si la región primaria no está disponible, se finalizan todas las solicitudes activas. Las aplicaciones cliente deben reintentar las operaciones una vez completada la promoción.

  • Interrupción de la región secundaria: Una interrupción en la región secundaria puede provocar problemas para las solicitudes activas en las situaciones siguientes:

    • Si usa el modo de replicación sincrónica, la región primaria no puede completar las operaciones de escritura si alguna región secundaria no está disponible.

    • Si usa el modo de replicación asincrónica, el espacio de nombres limita su capacidad y no acepta nuevos eventos después de que el retraso de la replicación alcance el máximo que ha configurado.

    Para seguir usando el espacio de nombres en la región primaria, quite el espacio de nombres secundario de la configuración de replicación geográfica.

• Pérdida de datos esperada: La cantidad de pérdida de datos depende del tipo de promoción que realice (planeado o forzado) y del modo de replicación (sincrónico o asincrónico):

  • Promoción planeada: No se espera ninguna pérdida de datos. Sin embargo, durante una interrupción de la región, es posible que una promoción planeada no sea posible porque requiere que todas las regiones primarias y secundarias estén disponibles.

  • Promoción forzada, replicación sincrónica: No se espera ninguna pérdida de datos.

  • Promoción forzada, replicación asincrónica: Es posible que experimente alguna pérdida de datos para eventos recientes que no se replican en la región secundaria. La cantidad depende del retraso de replicación. Para comprobar el retraso de replicación actual, use las métricas de Azure Monitor.

  Si realiza una promoción forzada, no puede recuperar los datos perdidos, incluso después de que la región primaria esté disponible.

• Tiempo de inactividad esperado: La cantidad de tiempo de inactividad esperado depende de si realiza una promoción planeada o forzada:

  • Promoción planeada: El primer paso de una promoción planeada replica los datos en la región secundaria. Ese proceso suele completarse rápidamente, pero en algunas situaciones, puede tardar hasta la longitud del retraso de replicación. Una vez completada la replicación, el proceso de promoción suele tardar entre 5 y 10 minutos. A veces, los servidores del sistema de nombres de dominio (DNS) pueden tardar más tiempo en actualizar las entradas y replicar completamente sus registros en los clientes.

    La región primaria no acepta operaciones de escritura durante todo el proceso de promoción.

    Es posible que esta opción no sea posible durante una interrupción de la región porque requiere que todas las regiones primarias y secundarias estén disponibles.

  • Promoción forzada: Durante una promoción forzada, Event Hubs no espera a que se complete la replicación de datos e inicia la promoción inmediatamente. El proceso de promoción suele tardar entre 5 y 10 minutos. A veces, las entradas DNS pueden tardar más tiempo en replicarse y actualizarse por completo en todos los clientes.

    La región primaria no acepta operaciones de escritura durante todo el proceso de promoción.

• Reenrutamiento del tráfico: Una vez completada la promoción, el FQDN del espacio de nombres apunta a la nueva región primaria. Pero este redireccionamiento depende de la rapidez con la que se actualizan los registros DNS de los clientes, incluido para que sus servidores DNS respeten el período de vida (TTL) de los registros DNS del espacio de nombres.

  En algunas situaciones, debe configurar las aplicaciones de consumo para que se comporten de forma coherente después de que se produzca la promoción de la región. Para más información, consulte Replicación geográfica: Consumo de datos.

Recuperación de regiones

Después de que la región primaria original se recupere, si desea devolver el namespace a su región primaria original, siga el mismo proceso de promoción de la región.

Si realizó una promoción forzada durante la interrupción de la región, no podrá recuperar los datos perdidos, incluso después de que la región primaria esté disponible.

Prueba de fallos de región

Para probar la replicación geográfica, promueva temporalmente la región secundaria a principal y compruebe que las aplicaciones cliente pueden cambiar entre regiones con una interrupción mínima.

Supervise la duración de la promoción y compruebe que los runbooks y la automatización funcionan correctamente. Después de realizar las pruebas, puede revertir a la configuración original.

Comprenda el posible tiempo de inactividad y pérdida de datos que puede experimentar durante y después del proceso de promoción. Pruebe la replicación geográfica en un entorno que no sea de producción que refleje la configuración del espacio de nombres de producción.

Recuperación ante desastres geográfica de metadatos

El nivel Estándar y versiones posteriores admiten la recuperación ante desastres geográfica de metadatos. Esta característica mejora la recuperación de escenarios de desastres, incluida la pérdida grave de una región. La recuperación ante desastres geográfica solo replica la configuración y los metadatos del espacio de nombres. Sin embargo, no replica los datos de eventos. Para admitir la recuperación ante desastres, esta característica garantiza que un espacio de nombres de otra región esté preconfigurado y listo para aceptar inmediatamente eventos de los clientes. La recuperación ante desastres geográfica sirve como una solución de recuperación unidireccional y no admite la conmutación por recuperación en la región primaria anterior.

La recuperación ante desastres geográfica de metadatos funciona mejor para las aplicaciones que no necesitan mantener todos los eventos y pueden tolerar cierta pérdida de datos durante un escenario de desastre. Por ejemplo, si sus eventos representan lecturas de sensores que luego usted agrega, podría decidir que puede permitirse perder algunos eventos de una región fallida si puede reanudar rápidamente el procesamiento de nuevos eventos en otra región.

Al configurar la recuperación ante desastres geográfica de metadatos, se crea un alias al que se conectan las aplicaciones cliente. El alias es un FQDN que dirige todo el tráfico al espacio de nombres principal de forma predeterminada.

Si se produce un error en la región primaria u otro tipo de desastre, puede iniciar manualmente una conmutación por error unidireccional desde la región primaria a la región secundaria en cualquier momento. La conmutación por error se completa casi al instante. Durante el proceso de conmutación por error, el alias de recuperación ante desastres geográficos se redirige al espacio de nombres secundario.

En esta sección se resumen aspectos importantes de la recuperación ante desastres geográfica. Revise la documentación completa para comprender exactamente cómo funciona. Para más información, consulte Recuperación ante desastres geográfica de Event Hubs.

Soporte para regiones

Puede seleccionar cualquier región de Azure que admita Event Hubs como espacio de nombres principal o secundario. No es necesario usar regiones emparejadas de Azure, por lo que puede elegir regiones secundarias en función de los requisitos de latencia, cumplimiento o residencia de datos.

Requisitos

• Nivel de espacio de nombres principal: El espacio de nombres principal debe estar en el nivel Estándar o superior para usar la recuperación ante desastres geográfica de metadatos.

• Nivel de espacio de nombres secundario: La recuperación ante desastres geográfica de metadatos admite combinaciones específicas de niveles para los espacios de nombres principal y secundario. Para obtener más información, vea Pares de espacios de nombres admitidos.

Consideraciones

• Asignaciones de roles: las asignaciones de control de acceso basado en roles (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.

• Registro de Esquema: Los metadatos del Registro de Esquema se replican al usar la recuperación ante desastres geográfica de metadatos, pero los esquemas inscritos en el registro de esquema no se replican.

• Diseño de aplicaciones: La recuperación ante desastres geográfica requiere consideraciones específicas al diseñar las aplicaciones cliente. Para más información, consulte Consideraciones.

• Puntos de conexión privados: Si usa puntos de conexión privados para conectarse al espacio de nombres, configure las redes en la región primaria y secundaria. Para obtener más información, consulte Puntos de conexión privados.

Cost

Al habilitar la recuperación ante desastres geográficos de metadatos, usted paga por los espacios de nombres principal y secundario.

Configuración de la compatibilidad con varias regiones

• Cree un emparejamiento de recuperación ante desastres geográficos para metadatos. Para configurar la recuperación ante desastres entre los espacios de nombres principal y secundario, consulte Proceso de configuración y conmutación por error.

• Deshabilite la recuperación ante desastres geográfica de metadatos. Para interrumpir el emparejamiento entre espacios de nombres, consulte Configuración y flujo de conmutación por error.

Planeamiento y administración de capacidad

Cuando planee implementaciones de varias regiones, asegúrese de que ambas regiones tienen capacidad suficiente para controlar la carga completa si se produce un error en una región. La región secundaria permanece pasiva durante las operaciones normales, pero debe controlar inmediatamente el tráfico después de la conmutación por error. Planee cómo escalar la capacidad del espacio de nombres secundario para que pueda recibir tráfico de producción sin demora. Si puede tolerar un tiempo de inactividad adicional durante el proceso de conmutación por error, puede optar por escalar la capacidad del espacio de nombres secundario durante o después de la conmutación por error. Para reducir el tiempo de inactividad, aprovisione la capacidad con antelación en el espacio de nombres secundario para que permanezca lista para recibir la carga de producción.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar cuando se configura un espacio de nombres de Event Hubs para la recuperación ante desastres geográfica y la región primaria está operativa.

• Enrutamiento del tráfico entre regiones: las aplicaciones cliente se conectan a través del alias de recuperación ante desastres geográfico de su espacio de nombres, y su tráfico se enruta al espacio de nombres principal en la región primaria.

  Solo el espacio de nombres principal procesa activamente eventos de los clientes durante las operaciones normales. El espacio de nombres secundario permanece pasivo en modo de espera y se produce un error en las solicitudes de acceso a los datos.

• Replicación de datos entre regiones: Solo los metadatos de configuración se replican entre los espacios de nombres. La replicación de la configuración se produce de forma continua y asincrónica.

  Todos los datos de eventos permanecen solo en el espacio de nombres principal y no se replican en el espacio de nombres secundario.

Comportamiento durante una falla de región

En esta sección se describe qué esperar cuando se configura un espacio de nombres de Event Hubs para la recuperación ante desastres geográficos y se produce una interrupción en la región principal.

• Detección y respuesta: usted es responsable de monitorear la salud de la región e iniciar la conmutación por error manualmente. Microsoft no realiza la conmutación por error ni promueve automáticamente una región secundaria, incluso si la región primaria está inactiva.

  Para obtener más información sobre cómo iniciar la conmutación por error, consulte Conmutación por error manual.

  La conmutación por error es una operación unidireccional, por lo que deberá restablecer la pareja de recuperación ante desastres geográficos más adelante. Para obtener más información, consulte Recuperación de regiones.

• Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

  Utilice esa información y otras métricas para decidir cuándo realizar la conmutación por error a la región secundaria.

• Solicitudes activas: Las solicitudes activas terminan cuando se inicia la conmutación por error. Las aplicaciones cliente deben reintentar las operaciones una vez completada la conmutación por error.

• Pérdida de datos esperada:

  • Metadatos: Normalmente, la configuración y los metadatos se replican en el espacio de nombres secundario. Pero la replicación de metadatos se produce de forma asincrónica, por lo que es posible que los cambios recientes no se repliquen, especialmente los cambios complejos. Compruebe la configuración del espacio de nombres secundario antes de que los clientes accedan a él.

  • Datos de eventos: Los datos del evento no se replican entre regiones. Si la región primaria deja de funcionar, los eventos del espacio de nombres principal no estarán disponibles.

    Los eventos no se pierden permanentemente a menos que un desastre catastrófico cause una pérdida total de la región primaria. Si la región se recupera, puede recuperar eventos del espacio de nombres principal más adelante.

• Tiempo de inactividad esperado: Normalmente, la conmutación ocurre en un plazo de 5 a 10 minutos. Los clientes pueden tardar más tiempo en replicar y actualizar completamente las entradas DNS.

• Re enrutamiento del tráfico: los clientes que usan el alias de recuperación ante desastres geográfica para conectarse al espacio de nombres se redirigen automáticamente al espacio de nombres secundario después de la conmutación por error. Pero este redireccionamiento depende de los servidores DNS que respetan el TTL de los registros DNS del espacio de nombres y los clientes que reciben esos registros DNS actualizados.

Recuperación de regiones

Una vez recuperada la región primaria original, debe reestablecer manualmente el emparejamiento y, opcionalmente, realizar una conmutación de retorno. Cree un nuevo emparejamiento de recuperación ante desastres geográfica con la región recuperada como secundaria y, a continuación, realice otra conmutación por error si desea volver a la región original. Este proceso implica la posible pérdida de datos de eventos enviados al servidor principal temporal.

Si el desastre provoca la pérdida de todas las zonas de la región primaria, los datos podrían ser irrecuperables. En otros escenarios, los datos del evento permanecen en el espacio de nombres principal de antes de que se pueda recuperar la conmutación por error. Puede obtener eventos históricos del espacio de nombres principal anterior después de restaurar el acceso. Usted es responsable de configurar las aplicaciones para recibir y procesar esos eventos. Microsoft no los restaura automáticamente en tu región secundaria.

Prueba de fallos de región

Para probar los procesos de respuesta y recuperación ante desastres, realice una conmutación por error planeada durante una ventana de mantenimiento. Inicie la conmutación por error desde el espacio de nombres principal al espacio de nombres secundario y compruebe que las aplicaciones pueden conectarse y procesar eventos desde el nuevo espacio de nombres principal.

Supervise la duración de la conmutación por error y compruebe que los runbooks y la automatización funcionan correctamente. Después de realizar las pruebas, puede revertir a la configuración original.

Comprenda el posible tiempo de inactividad y la pérdida de datos que puede experimentar durante y después del proceso de conmutación por error. Pruebe la replicación geográfica en un entorno que no sea de producción que refleje la configuración del espacio de nombres de producción.

Soluciones personalizadas de varias regiones para la resistencia

La replicación geográfica y la recuperación ante desastres geográficos de metadatos proporcionan resiliencia frente a interrupciones regionales y otros problemas, y son compatibles con la mayoría de las cargas de trabajo. Algunos niveles de Event Hubs no admiten estas características, o es posible que necesite la replicación personalizada o necesite mantener varias regiones activas simultáneamente.

Varios patrones de diseño pueden lograr diferentes tipos de compatibilidad con varias regiones en Event Hubs. Muchos de los patrones requieren la implementación de varios espacios de nombres y el uso de servicios como Azure Functions para replicar eventos entre ellos. Para obtener más información, consulte Federación multisitio y de varias regiones.

Copias de seguridad y restauración

Event Hubs no está diseñado como una ubicación de almacenamiento a largo plazo para los datos. Normalmente, los datos se almacenan en un centro de eventos durante un breve período de tiempo y, a continuación, se procesan o se conservan en otro sistema de almacenamiento de datos. Puede configurar el período de retención de datos para su centro de eventos según sus requisitos y el nivel que utiliza su espacio de nombres. Para más información, consulte Retención de eventos.

Si necesita conservar una copia de los eventos, considere la posibilidad de usar Event Hubs Capture, que guarda copias de eventos en una cuenta de Azure Blob Storage.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

El SLA de disponibilidad del namespace es superior cuando se utilizan los niveles Premium o Dedicado.

Contenido relacionado

• Documentación de Event Hubs
• Introducción a la confiabilidad de Azure