Confiabilidad en el espacio de nombres de Azure Event Grid y Event Grid
Este artículo contiene información detallada sobre la capacidad de recuperación regional del espacio de nombres de Event Grid y Event Grid con zonas de disponibilidad y recuperación ante desastres y continuidad empresarial entre regiones.
Para obtener información arquitectónica general sobre la fiabilidad de Azure, consulte Fiabilidad de Azure.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.
Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.
Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.
Las definiciones de recursos de Event Grid para temas, temas del sistema, dominios y suscripciones de eventos y datos de eventos se replican automáticamente en tres zonas de disponibilidad. Cuando se produce un error regional en una de las zonas de disponibilidad, los recursos de Event Grid conmutan por error automáticamente a otra zona de disponibilidad sin intervención humana. Actualmente, no es posible controlar (habilitar o deshabilitar) esta característica. Cuando una región existente comienza a admitir zonas de disponibilidad, los recursos de Event Grid existentes se conmutarán por error automáticamente para aprovechar esta característica. No se requiere ninguna acción del cliente.
El espacio de nombres de Azure Event Grid logra una alta disponibilidad dentro de la región mediante zonas de disponibilidad.
Requisitos previos
Para la compatibilidad con zonas de disponibilidad, los recursos de Event Grid deben estar en una región que admita zonas de disponibilidad. Para revisar qué regiones admiten zonas de disponibilidad, consulte la lista de regiones admitidas.
Precios
Dado que Event Grid admite zonas de disponibilidad automáticamente en regiones que admiten zonas de disponibilidad, no hay ningún cambio en el precio.
Creación de un recurso con zonas de disponibilidad habilitadas
Dado que Event Grid admite zonas de disponibilidad automáticamente en regiones que admiten zonas de disponibilidad, no hay ninguna configuración necesaria.
Soporte técnico para la migración a la zona de disponibilidad
Si reubica sus recursos de Event Grid a una región compatible con las zonas de disponibilidad, obtendrá automáticamente compatibilidad con dichas zonas. Para saber cómo reubicar sus recursos en otra región compatible con las zonas de disponibilidad, vea lo siguiente:
- Reubicación de temas del sistema de Azure Event Grid a otra región
- Reubicación de temas personalizados de Azure Event Grid en otra región
- Reubicación de dominios de Azure Event Grid a otra región
Recuperación ante desastres entre regiones y continuidad empresarial
La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.
En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.
La recuperación ante desastres suele implicar la creación de un recurso de copia de seguridad para evitar interrupciones cuando una región deja de funcionar correctamente. Durante este proceso, se necesitarán una región principal y secundaria de recursos de Azure Event Grid en la carga de trabajo.
Hay diferentes maneras de recuperarse de una pérdida grave de la funcionalidad de la aplicación. En esta sección, describimos la lista de comprobación que deberá seguir para preparar a su cliente para recuperarse de un fallo debido a un recurso o región en mal estado.
Event Grid admite la recuperación ante desastres geográfica manual y automática (GeoDR) en el lado servidor. Aún puede implementar la lógica de recuperación ante desastres en el lado del cliente si desea un mayor control sobre el proceso de conmutación por error. Para obtener más información acerca de GeoDR automática, consulte Recuperación de desastres geográfica del lado servidor en Azure Event Grid. Para más información sobre cómo implementar la recuperación ante desastres del lado del cliente, consulteImplementación de la conmutación por error del lado del cliente en Azure Event Grid.
En la tabla siguiente se muestra la compatibilidad con la conmutación por error del lado cliente y la recuperación ante desastres geográfica en Event Grid.
| Recurso de Event Grid | Compatibilidad con la conmutación por error del lado cliente | Compatibilidad con la recuperación ante desastres geográfica (GeoDR) |
|---|---|---|
| Temas personalizados | Compatible | Entre regiones/Regional |
| Temas del sistema | No compatible | Habilitada automáticamente |
| Dominios | Compatible | Entre regiones/Regional |
| Espacios de nombres de los asociados | Compatible | No compatible |
| Espacios de nombres | Compatible | No compatible |
Espacio de nombres de Event Grid
El espacio de nombres de Event Grid no admite la recuperación ante desastres entre regiones. Sin embargo, puede lograr una alta disponibilidad entre regiones a través de la implementación de conmutación por error del lado cliente mediante la creación de espacios de nombres principales y secundarios.
Con una implementación de conmutación por error del lado cliente, puede hacer lo siguiente:
Implemente un proceso personalizado (manual o automatizado) para replicar el espacio de nombres, las identidades de cliente y otra configuración**, incluidos los certificados de CA, los grupos de clientes, los espacios de temas, los enlaces de permisos, el enrutamiento, entre las regiones primarias y secundarias.
Implemente un servicio de conserjería que proporcione a los clientes puntos de conexión principales y secundarios realizando una comprobación de estado en los puntos de conexión. El servicio de conserje puede ser una aplicación web simple que se replica y se mantiene accesible mediante técnicas de redirección de DNS, por ejemplo, con Azure Traffic Manager.
Consiga una solución de recuperación ante desastres activa-activa replicando los metadatos y equilibrando la carga entre los espacios de nombres. Una solución de recuperación ante desastres activa-pasiva se puede lograr replicando los metadatos para mantener el espacio de nombres secundario listo para que cuando el espacio de nombres principal no esté disponible, el tráfico se puede dirigir al espacio de nombres secundario.
Configuración de la recuperación ante desastres
En el caso de las regiones que están emparejadas, Event Grid ofrece una funcionalidad para conmutar por error el tráfico de publicación en la región emparejada para temas personalizados, temas del sistema y dominios. En segundo plano, Event Grid sincroniza automáticamente las definiciones de recursos de temas, temas del sistema, dominios y suscripciones de eventos a la región emparejada. Sin embargo, los datos de eventos no se replican en la región emparejada. En el estado normal, los eventos se almacenan en la región seleccionada para ese recurso. Cuando se produce una interrupción de la región y Microsoft inicia la conmutación por error, los nuevos eventos comienzan a fluir a la región emparejada geográficamente y se enviarán desde allí sin intervención de usted. Los eventos publicados y aceptados en la región original se envían desde allí después de mitigar la interrupción.
Puede elegir entre dos opciones de conmutación por error, la conmutación por error iniciada por Microsoft y la iniciada por el cliente. Para obtener pasos detallados sobre cómo configurar ambas opciones, consulte Configuración de la residencia de datos.
La conmutación por error iniciada por Microsoft la ejecuta Microsoft en situaciones concretas para conmutar por error todos los recursos de Event Grid de una región afectada en la región emparejada geográficamente correspondiente. Microsoft se reserva el derecho de determinar cuándo se ejercerá esta opción. Este mecanismo no precisa de consentimiento del usuario antes de realizar la conmutación por error del tráfico del usuario.
Habilite esta funcionalidad actualizando la configuración de su tema o dominio. Seleccione Cross-Geo (valor predeterminado) para habilitar la conmutación por error iniciada por Microsoft.
La conmutación por error iniciada por el cliente está definida por su plan personalizado de recuperación ante desastres para temas y dominios de Azure Event Grid, y Microsoft no replica ningún tipo de datos a otra región. Aunque esta opción de conmutación por error requiere un poco más de esfuerzo, permite una conmutación por error más rápida y está en control de la elección de regiones secundarias. Si desea implementar la recuperación ante desastres del lado del cliente para los temas de Azure Event Grid, consulte Crear su propia recuperación ante desastres del lado del cliente para los temas de Azure Event Grid.
Estas son algunas razones por las que puede que quiera deshabilitar la característica de conmutación por error iniciada por Microsoft:
- La conmutación por error iniciada por Microsoft se realiza de la mejor manera posible.
- Algunos pares geográficos no cumplen los requisitos de residencia de datos de su organización.
Habilite esta funcionalidad actualizando la configuración de su tema o dominio. Seleccione Regional.
Si usa un región no emparejada, independientemente de la configuración de residencia de datos que seleccione, los metadatos solo se replicarán dentro de la región.
Experiencia de conmutación por error de recuperación ante desastres
La recuperación ante desastres se mide con dos métricas, Objetivo de punto de recuperación (RPO) y Objetivo de tiempo de recuperación (RTO).
La conmutación automática por error de Event Grid tiene diferentes RPO y RTO para los metadatos (temas, dominios y suscripciones a eventos) y los datos (eventos). Si necesita una especificación distinta a las siguientes, siempre puede implementar su propia conmutación por error del lado cliente con las API de estado de temas.
Objetivo de punto de recuperación (RPO)
RPO de metadatos: cero minutos. Para los recursos aplicables, cuando se crea, actualiza o elimina un recurso, la definición del recurso se replica sincrónicamente en el par geográfico. Cuando se produce una conmutación por error, no se pierde ningún metadato.
RPO de datos: cuando se produce una conmutación por error, los nuevos datos se procesan desde la región emparejada. En cuanto se mitiga la interrupción de la región afectada, los eventos no procesados se envían desde allí. Si la recuperación de la región requiere más tiempo que el valor de período de vida establecido en eventos, los datos se podrían quitar. Para mitigar esta pérdida de datos, se recomienda configurar un destino de mensajes fallidos para una suscripción de eventos. Si la región afectada se pierde y no se puede recuperar, habrá cierta pérdida de datos. En el mejor de los casos, el suscriptor se mantiene al día con la tasa de publicación y solo se pierden unos segundos de datos. El peor escenario sería cuando el suscriptor no procesa activamente eventos y con un tiempo máximo de vida de 24 horas, la pérdida de datos puede ser de hasta 24 horas.
Objetivo de tiempo de recuperación (RTO)
RTO de metadatos: la toma de decisiones de conmutación por error se basa en factores como la capacidad disponible en la región emparejada y pueden durar en el intervalo de 60 minutos o más. Una vez iniciada la conmutación por error, en un plazo de 5 minutos, Event Grid comienza a aceptar llamadas de creación, actualización y eliminación para temas y suscripciones.
RTO de datos: igual que la información anterior.
Importante
- En caso de recuperación ante desastres del lado del servidor, si la región emparejada no tiene capacidad extra para asumir el tráfico adicional, Event Grid no puede iniciar la conmutación por error. La recuperación se realiza de la mejor manera posible.
- El uso de esta característica no tiene costo.
- No se admite la recuperación ante desastres geográfica para espacios de nombres de asociados y temas de asociados.