Confiabilidad en Azure Notification Hubs

Azure Notification Hubs le ayuda a administrar las notificaciones push en varios sistemas de notificaciones de plataforma (PNS), como apple Push Notification Service (APN), Firebase Cloud Messaging (FCM) y Windows Push Notification Service (WNS).

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para apoyar la resiliencia y la 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 hacer que Notification Hubs sea resistente a varias posibles interrupciones y problemas, incluidos errores transitorios, errores de zona de disponibilidad, errores de toda la región y mantenimiento del servicio. También se describen las opciones de copia de seguridad y restauración y la información clave sobre el acuerdo de nivel de servicio (SLA) de Notification Hubs.

Recomendaciones de implementación de producción

Para cargas de trabajo de producción, siga estas recomendaciones:

Introducción a la arquitectura de confiabilidad

Azure Notification Hubs se organiza en torno a espacios de nombres y centros de notificaciones. Un espacio de nombres es un límite administrativo que contiene uno o varios hubs. Los concentradores representan puntos de conexión para una aplicación. Los dispositivos se registran con esos puntos de conexión mediante registros o instalaciones, lo que permite al servicio enviar notificaciones push a los dispositivos. Para obtener más información, consulte Administración de registros.

Notification Hubs envía notificaciones push a sistemas de notificaciones de plataforma (PNS), como Apple Push Notification Service (APN) y Firebase Cloud Messaging (FCM). La entrega de notificaciones de un extremo a otro depende de la disponibilidad de Notification Hubs y del comportamiento de los proveedores de PNS de nivel inferior.

Para planear la confiabilidad, es importante distinguir entre los siguientes tipos de datos que Administra Notification Hubs:

• Metadatos: Espacio de nombres y configuración del hub, incluida la información de conexión y la configuración de recuperación ante desastres.
• Datos de registro: Registros de dispositivos e instalaciones que asignan usuarios y dispositivos a etiquetas y plantillas.

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 más información, vea Recomendaciones para gestionar errores temporales.

Notification Hubs controla automáticamente los errores transitorios que se producen al conectarse a un PNS. Sin embargo, usted es responsable de gestionar los fallos transitorios cuando sus servicios o los dispositivos de sus usuarios interactúan con Notification Hubs. Los errores transitorios pueden producirse durante las operaciones de registro, las operaciones de envío de notificaciones y las operaciones de administración. Siga estas instrucciones:

• Registros e instalaciones: Las aplicaciones de los dispositivos deben reintentar las operaciones de registro e instalación que producen errores debido a errores transitorios. los SDK proporcionados por Microsoft controlan los reintentos automáticamente. Si no puede usar los SDK proporcionados, implemente una lógica de reintento con retroceso exponencial y jitter, y asegúrese de que las operaciones de registro sean idempotentes siempre que sea posible.

  La creación o actualización de una instalación es idempotente, por lo que puede reintentar la operación de forma segura. Cuando sea posible, use instalaciones en lugar de registros.

• Operaciones de envío y administración de notificaciones: Use un SDK proporcionado por Microsoft para enviar notificaciones push y realizar operaciones de administración. Estos SDK reintentan automáticamente cuando se producen errores transitorios.

  Si no puede usar los SDK proporcionados, implemente la lógica de reintento con retroceso exponencial y vibración, y haga que las operaciones de envío de notificaciones sean idempotentes siempre que sea posible.

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 una zona falla, los servicios pueden transferirse a una de las zonas restantes.

En regiones que admiten zonas de disponibilidad, los espacios de nombres de Notification Hubs admiten una configuración con redundancia de zona . Notification Hubs habilita automáticamente la redundancia de zona para todos los espacios de nombres de algunas regiones. Cuando se habilita la redundancia de zona, Microsoft replica tanto los metadatos como los datos de registro en todas las zonas de disponibilidad de la región.

Requirements

• Compatibilidad con regiones:

  Notification Hubs habilita automáticamente la redundancia de zona para todos los espacios de nombres de las siguientes regiones. No se puede deshabilitar la redundancia de zona en estas regiones:

  Europe	Oriente Medio	Africa	Asia Pacífico
  Centro de Francia	Qatar Central	Norte de Sudáfrica	Norte de China 3
  Norte de Italia			Centro de Corea del Sur
  Este de Noruega
  Centro de Polonia
  Centro de Suecia
  Norte de Suiza

  En otras regiones que admiten Notification Hubs y tienen zonas de disponibilidad, la redundancia de zona es opcional. Solo puedes habilitarlo al crear un espacio de nombres.

• Compatibilidad con niveles: Puede usar zonas de disponibilidad con todos los niveles de Notification Hubs.

Cost

La redundancia de zona conlleva un cargo adicional además del precio del plan. Para más información, consulte Precios de Notification Hubs.

Configurar soporte de zonas de disponibilidad

• Cree un nuevo espacio de nombres con redundancia de zona: El proceso para crear un nuevo espacio de nombres con redundancia de zona depende de la región que use:

  • En las regiones en las que Notification Hubs habilita automáticamente la redundancia de zona, no es necesario configurarla.

    Importante

    En estas regiones, Notification Hubs siempre crea espacios de nombres con redundancia de zona habilitada, incluso si una implementación basada en código, como un archivo Bicep o una plantilla de Azure Resource Manager, indica que la redundancia de zona está deshabilitada.

    Si no desea un espacio de nombres con redundancia de zona, créelo en una región que admita redundancia de zona opcional.

  • En las regiones en las que la redundancia de zona es opcional, solo puede habilitarla cuando se crea un espacio de nombres. Para obtener información sobre cómo configurar un nuevo espacio de nombres con redundancia de zona, consulte Creación de un centro de notificaciones de Azure en el portal de Azure.

• Haga que una zona de espacio de nombres existente sea redundante: Notification Hubs no admite la migración local de un espacio de nombres existente a la compatibilidad con la zona de disponibilidad. Debe implementar un nuevo espacio de nombres y mover los registros a ese espacio de nombres. Siga las instrucciones de Mover recursos entre regiones de Azure, que también se aplican si implementa el nuevo espacio de nombres en la misma región.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar al configurar un espacio de nombres de Notification Hubs con redundancia de zona, cuando todas las zonas están operativas.

• Operación entre zonas: Notification Hubs distribuye y atiende automáticamente las solicitudes mediante el uso de la infraestructura en cualquier zona de la región.

• Replicación de datos entre zonas: Tanto los datos de registro como los metadatos se replican sincrónicamente en todas las zonas de la región especificada.

Comportamiento durante un fallo de zona

En esta sección se describe qué cabe esperar al configurar un espacio de nombres de Notification Hubs con redundancia de zona, si se produce una interrupción en una de las zonas.

• Detección y respuesta: Microsoft detecta fallos de zona y gestiona la conmutación por error dentro de la región. No es necesario iniciar la conmutación por error.

• 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 en curso: Las operaciones de administración en curso, los registros de dispositivos y las nuevas solicitudes de envío de notificaciones podrían producir errores durante una conmutación por error. Las aplicaciones deben reintentar las operaciones con errores siguiendo las instrucciones de control de errores transitorios.

• Pérdida de datos esperada: No se espera la pérdida de datos durante una interrupción de una sola zona porque Notification Hubs replica de forma sincrónica el espacio de nombres y la configuración del centro y los datos de registro en todas las zonas de disponibilidad.

  Esta replicación no es una copia de seguridad. En el modelo de responsabilidad compartida, es responsable de realizar copias de seguridad de los datos de registro e instalación. Para obtener más información, consulte Copia de seguridad y restauración.

• Tiempo de inactividad esperado: Una breve interrupción del servicio es posible mientras Microsoft redirecciona el tráfico. Siga las instrucciones de control de errores transitorios para preparar las aplicaciones para estas interrupciones.

• Redistribución: El servicio redirige automáticamente las solicitudes a zonas correctas.

Recuperación de zona

Cuando se recupera la zona afectada, no es necesario realizar ninguna acción. Microsoft restaura y vuelve a equilibrar la infraestructura de Notification Hubs para usar la zona recuperada.

Prueba de fallos de zona

No se puede iniciar directamente una conmutación por error de una zona de Notification Hubs. Para probar el comportamiento de la carga de trabajo, ejecute pruebas de resiliencia para reintentos, idempotencia y errores de dependencia en entornos no productivos. También puede usar Azure Chaos Studio para probar los componentes de la aplicación circundantes.

Resistencia a errores en toda la región

Notification Hubs proporciona recuperación ante desastres de metadatos mediante la replicación de metadatos del espacio de nombres entre regiones, pero no replica los datos de registro de dispositivos. Esta funcionalidad requiere intervención manual durante una interrupción de la región e implica cierto tiempo de inactividad para el centro de notificaciones.

Si necesita reducir el tiempo de inactividad y la intervención manual durante la conmutación por error, considere la posibilidad de usar una solución de varias regiones personalizada.

recuperación geográfica ante desastres de metadatos administrados por Microsoft

Notification Hubs admite la recuperación ante desastres de metadatos administrados por Microsoft en una región de Azure secundaria. Si la región primaria tiene una región emparejada, puede seleccionar esa región emparejada. Independientemente del estado de emparejamiento de la región primaria, también puede elegir una región secundaria en una lista de regiones de recuperación flexibles. A continuación, Notification Hubs replica los metadatos del espacio de nombres, como el nombre del espacio de nombres, las cadenas de conexión y otra información crítica.

Microsoft es responsable de declarar un desastre e iniciar la conmutación por error. Cuando esto sucede, Microsoft crea un nuevo espacio de nombres en la región secundaria. Dado que usa los metadatos de la región primaria, las aplicaciones pueden conectarse a ese espacio de nombres usando el nombre del espacio de nombres existente, la cadena de conexión y los nombres del centro de eventos.

Requirements

• Compatibilidad con regiones: En regiones de Azure emparejadas, el espacio de nombres puede usar la región emparejada Azure como región secundaria.

  Si el espacio de nombres está en una región no emparejada o si desea replicar datos en otra región, puede seleccionar una de las siguientes regiones de recuperación flexible como región secundaria:

  Americas	Europe	Africa	Asia Pacífico
  Sur de Brasil	Norte de Europa	Norte de Sudáfrica	Australia East
  Oeste de EE. UU. 2			Sudeste asiático

• Compatibilidad con niveles: Las opciones de recuperación ante desastres de metadatos están disponibles en todos los niveles de Notification Hubs.

Cost

Notification Hubs no cobra ningún cargo adicional para configurar o usar la recuperación ante desastres geográfica de metadatos. Sin embargo, paga por el ancho de banda entre regiones que se usa para replicar metadatos. Para más información sobre los precios, consulte Precios de ancho de banda y Precios de Notification Hubs.

Configuración de la compatibilidad con varias regiones

• Habilite la recuperación ante desastres geográfica de metadatos para un nuevo espacio de nombres: Siga el procedimiento descrito en Creación de un centro de notificaciones de Azure en el portal de Azure. Seleccione la configuración de recuperación ante desastres al crear el espacio de nombres.

• Habilite o deshabilite la recuperación ante desastres geográfica de metadatos para un espacio de nombres existente: Siga el procedimiento descrito en Habilitar la recuperación ante desastres para un espacio de nombres Azure Notification Hubs existente.

• Realice una copia de seguridad de los datos de registro del dispositivo: Consulte Exportación e importación de registros de Azure Notification Hubs de forma masiva.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué cabe esperar al configurar un espacio de nombres de Notification Hubs para la recuperación geográfica ante desastres de metadatos, cuando tanto la región primaria como la secundaria están operativas.

• Operación entre regiones: La región primaria atiende todas las solicitudes. La región secundaria no procesa solicitudes salvo que se produzca una conmutación por error.

• Replicación de datos entre regiones: Los metadatos, como el nombre del espacio de nombres, la configuración del centro de conectividad, las cadenas de conexión y otra información crítica, se replican de forma asincrónica entre regiones. Los datos de registro no se replican. Usted es responsable de exportarlo periódicamente para mantener una copia de seguridad.

Comportamiento durante una falla de región

En esta sección se describe qué puede esperar si configura un espacio de nombres de Notification Hubs para la recuperación geográfica ante desastres de metadatos y se produce una interrupción en la región primaria.

• Detección y respuesta: Microsoft es responsable de detectar el error de la región y decidir si se debe desencadenar la conmutación por error en la región secundaria configurada.

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

• Solicitudes activas: Las solicitudes en curso al espacio de nombres de la región primaria pueden producir un error cuando la región se queda sin conexión. Los clientes deben reintentar las operaciones una vez completada la conmutación por error.

• Pérdida de datos esperada: Se conservan los metadatos. No se realiza una copia de seguridad automática de los datos de registro, pero puede realizar una copia de seguridad. Para obtener más información, consulte Exportación e importación de registros de Azure Notification Hubs de forma masiva. Si no lo hace, los datos de registro no estarán disponibles hasta que se recupere la región primaria.

• Tiempo de inactividad esperado: Microsoft tarda un tiempo en iniciar la conmutación por error de los metadatos y para que esta se complete. Aunque el tiempo puede variar, suele tardar varias horas.

  Cuando se complete la conmutación por error, usted será responsable de restaurar cualquier copia de seguridad de los datos de registro.

• Redistribución: Tras la conmutación por error, las solicitudes se enrutan a un espacio de nombres en la región secundaria que utiliza los datos replicados de la región primaria. Una vez completada la conmutación por error, los clientes se conectan automáticamente al espacio de nombres de la región secundaria.

Recuperación de regiones

Si la región primaria se recupera, podría ser posible volver a conmutar al espacio de nombres primario de la región primaria. El espacio de nombres principal conservaría los datos de registro antes de la interrupción. Este sería un proceso manual y Microsoft se comunicaría con usted para explicar cómo funciona esto.

Una vez que la región primaria se haya recuperado, debes:

• Valide el estado del espacio de nombres y sus datos.
• Determine si se van a sincronizar los cambios de datos de registro recientes desde la región secundaria a la región primaria.

Prueba de fallos de región

No se puede iniciar una conmutación por error geográfica. Sin embargo, debe probar sus propios procedimientos de recuperación ante desastres. Compruebe que se realiza una copia de seguridad de los registros y que puede restaurarlos en un nuevo espacio de nombres.

Soluciones de varias regiones personalizadas para la resistencia

La recuperación geográfica ante desastres de metadatos administrados por Microsoft solo replica metadatos. La característica puede recuperar esos metadatos en un espacio de nombres secundario, pero es responsable de importar registros de dispositivos en ese espacio de nombres para que la aplicación pueda seguir funcionando. Este enfoque requiere intervención manual durante un desastre e implica tiempo de inactividad.

Si sus objetivos de recuperación exigen un tiempo de inactividad menor o menos intervención manual, puede implementar una solución multirregión activa-activa personalizada. Implemente un segundo espacio de nombres de Notification Hubs en otra región de Azure con antelación.

• Conmutación por error: Dado que el segundo espacio de nombres es un recurso operativo, puede implementar lógica para detectar un fallo en una región y cambiar a ese espacio de nombres.

• Sincronización: Para mantener un segundo centro de notificaciones sincronizado con el centro de notificaciones principal, use una de las siguientes opciones:

  • Para las instalaciones: Use un back-end de aplicación que cree y actualice simultáneamente instalaciones en ambos centros de notificaciones. Las instalaciones permiten especificar su propio identificador de dispositivo único, que admite este escenario de replicación. Para obtener más información, consulte el ejemplo redundantehub.

  • Para registros: Use un back-end de aplicación que exporte regularmente los registros desde el centro de notificaciones principal como copia de seguridad y los importe en bloque en el centro de notificaciones secundario. Para obtener más información, consulte Exportación e importación de registros de Azure Notification Hubs de forma masiva.

  Como alternativa, si no tiene un back-end, configure la aplicación para crear instalaciones en ambos centros cuando la aplicación se inicie en los dispositivos de destino. Los dispositivos crean nuevos registros en ambos centros de notificaciones. Finalmente, el centro de notificaciones secundario tiene registrados todos los dispositivos activos.

• Registros e instalaciones expirados: Es posible que el centro de notificaciones secundario haya expirado los registros y las instalaciones. Cuando se envía una notificación push a un identificador expirado, Notification Hubs elimina automáticamente el registro o registro de instalación asociado en el centro de notificaciones, en función de la respuesta recibida del servidor PNS. Puede limpiar los registros expirados de la solución de copia de seguridad que prefiera agregando lógica personalizada que procesa los comentarios de cada envío y quita los registros y las instalaciones expirados.

• Aplicaciones sin abrir: Hay un período de tiempo durante el que los dispositivos con aplicaciones sin abrir no reciben notificaciones.

• Costo: Si usa su propio centro secundario para proteger los datos de registro, ese centro incurre en cargos de servicio normales. Del mismo modo, si implementa cualquier otro recurso de Azure en la región secundaria para respaldar la recuperación, pagará por ellos según las tarifas normales del servicio.

Copias de seguridad y restauración

Notification Hubs no proporciona una única función integrada de copia de seguridad y restauración para todos los datos almacenados en el espacio de nombres. Usted es responsable de combinar los enfoques siguientes:

• Utilice la infraestructura como código (IaC), como Bicep, para definir el espacio de nombres, el concentrador y la configuración de directivas. Almacene esas definiciones en el control de código fuente para que pueda volver a implementar los recursos cuando sea necesario.
• Realice una copia de seguridad de los datos de registro del dispositivo exportando los registros de Azure Notification Hubs de manera masiva.

Resistencia al mantenimiento del servicio

Microsoft aplica periódicamente actualizaciones de servicio y realiza otro mantenimiento. La plataforma Azure controla estas actividades automáticamente, lo que garantiza que el mantenimiento sea transparente y sin problemas. No se espera ningún tiempo de inactividad durante los eventos de mantenimiento a menos que se le haya informado a través del mantenimiento planeado de Azure Service Health.

Acuerdo de nivel de servicio

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

En Notification Hubs, el SLA de disponibilidad se aplica a los espacios de nombres que usan los niveles Básico y Estándar.

Contenido relacionado

• Confiabilidad en Azure