Confiabilidad en Azure IoT Hub

En este artículo se describe el soporte de confiabilidad en Azure IoT Hub. La resistencia intrarregional se aborda a través de zonas de disponibilidad y implementaciones multi-regionales.

La confiabilidad es una responsabilidad compartida entre usted y Microsoft. Puede usar esta guía para determinar qué opciones de confiabilidad cumplen sus objetivos empresariales específicos y objetivos de tiempo de actividad.

Al evaluar las opciones de confiabilidad, también debe evaluar las compensaciones entre los siguientes elementos:

• Nivel de resistencia que necesita
• La complejidad de implementación y mantenimiento
• Costo de implementar diferentes opciones

Para obtener más información, consulte Ventajas y desventajas de confiabilidad.

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

IoT Hub proporciona una garantía de tiempo de actividad razonablemente alta, pero los errores transitorios pueden producirse en cualquier plataforma informática distribuida. Para controlar los errores transitorios, cree los patrones de reintento adecuados en los componentes que interactúan con las aplicaciones en la nube.

Soporte para zonas de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de cada región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

IoT Hub admite dos tipos distintos de compatibilidad con zonas de disponibilidad:

• Redundancia de zona para los datos, que replica automáticamente los datos entre varias zonas de disponibilidad para los componentes de almacenamiento subyacentes que almacenan el registro de identidad del dispositivo y los mensajes del dispositivo a la nube.

• Redundancia de zona para cómputo, que proporciona resiliencia en los componentes responsables de administrar los dispositivos y el enrutamiento de mensajes.

Soporte para regiones

El tipo de soporte de zona de disponibilidad para IoT Hub depende de la región en la que se despliegue.

Región	Redundancia de zona para datos	Redundancia de zona para procesos
Este de Australia
Sur de Brasil
Centro de Canadá
Centro de la India
Centro de EE. UU.
Este de EE. UU.
Centro de Francia
Centro-oeste de Alemania
Japón Oriental
Centro de Corea del Sur
Norte de Europa
Este de Noruega
Centro de Qatar
Centro-sur de EE. UU.
Sudeste Asiático
Sur de Reino Unido
Oeste de Europa
Oeste de EE. UU. 2
Oeste de EE. UU. 3

Los centros de IoT que cree en regiones que no están en esta lista no son resistentes a las interrupciones de zona.

Costos

No hay ningún costo adicional para la redundancia de zona con IoT Hub.

Configurar soporte de zonas de disponibilidad

Los recursos de IoT Hub admiten automáticamente la redundancia de zona cuando se implementan en regiones admitidas. No es necesario realizar ninguna otra configuración.

Operaciones normales

En esta sección se describe qué esperar cuando los recursos de IoT Hub están configurados para la redundancia de zona y todas las zonas de disponibilidad están operativas.

• Replicación de datos entre zonas: Cuando el centro de IoT se implementa en una región que admite la redundancia de zona para los datos, los cambios en los datos se replican entre zonas de disponibilidad automáticamente. La replicación se produce sincrónicamente.

• Enrutamiento de tráfico entre zonas: Cuando el centro de IoT se implementa en una región que admite redundancia de zona para componentes de proceso, las solicitudes se enrutan a una instancia principal del servicio en una de las zonas de disponibilidad. Azure selecciona automáticamente la instancia activa y la zona.

Experiencia de reducción de zona

En esta sección se describen las expectativas cuando los recursos de IoT Hub están configurados para la redundancia de zona y hay una interrupción en la zona de disponibilidad de recursos.

• Detección y respuesta: El servicio IoT Hub es responsable de detectar un error en una zona de disponibilidad. No es necesario hacer nada para iniciar una conmutación por error de la zona.

• Solicitudes activas: Durante un fallo de zona, las solicitudes activas podrían ser eliminadas. Los clientes y dispositivos deben tener una lógica de reintento suficiente implementada para controlar los errores transitorios.

• Pérdida de datos esperada: Cuando el centro de IoT se implementa en una región que admite redundancia de zona para los datos, un error de zona no debe provocar ninguna pérdida de datos.

• Tiempo de inactividad esperado: Cuando el centro de IoT se implementa en una región que admite redundancia de zona para los componentes de proceso y de datos, un error de zona no debe provocar tiempo de inactividad en los recursos de IoT Hub.

• Reenrutamiento del tráfico: Cuando el centro de IoT se implementa en una región que admite redundancia de zona para los componentes de proceso, IoT Hub detecta la pérdida de la zona. A continuación, las nuevas solicitudes se redirigen automáticamente a una nueva instancia principal del servicio en una de las zonas de disponibilidad correctas.

Conmutación por recuperación

Cuando se recupera la zona de disponibilidad, IoT Hub restaura automáticamente las instancias de la zona de disponibilidad y vuelve a enrutar el tráfico entre las instancias como normal.

Pruebas para detectar fallos en la zona

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

Soporte multirregional

IoT Hub es un servicio de una sola región. Si la región deja de estar disponible, los recursos de IoT Hub tampoco están disponibles.

Sin embargo, si los recursos están en una región emparejada, los datos del centro de IoT se replican en la región emparejada.

El centro de IoT puede conmutar por error a la región emparejada en los escenarios siguientes:

• Conmutación por error iniciada por el cliente: Puede desencadenar la conmutación por error manual en la región emparejada usted mismo, independientemente de si la región está experimentando tiempo de inactividad o no. Puede usar este enfoque para realizar conmutaciones por error planeadas y simulacros.

• Conmutación por error iniciada por Microsoft: Si se pierde una región, Microsoft puede iniciar una conmutación por error de centros de IoT en la región emparejada. Sin embargo, es poco probable que Microsoft inicie la conmutación por error, excepto después de un retraso significativo y de mejor esfuerzo. La conmutación por error de los recursos de IoT Hub puede producirse en un momento diferente a la conmutación por error de otros servicios de Azure. Este proceso es una opción predeterminada y no requiere intervención de usted.

Si los recursos están en una región no emparejada, Microsoft no replica la configuración y los datos entre regiones y no hay ninguna conmutación por error integrada entre regiones. Sin embargo, puede implementar recursos independientes en varias regiones. En este escenario, es responsabilidad suya administrar la replicación, la distribución del tráfico y la conmutación por error.

Si el centro de IoT está en una región no emparejada o si el comportamiento predeterminado de replicación y conmutación por error no satisface sus necesidades, puede usar enfoques alternativos de varias regiones para planear e iniciar conmutaciones por error.

Soporte para regiones

La replicación predeterminada y la conmutación por error solo se admiten en regiones emparejadas.

Requisitos

Las opciones de replicación y conmutación por error de regiones emparejadas están disponibles para todos los niveles de IoT Hub.

Consideraciones

No use la conmutación por error iniciada por el cliente para migrar permanentemente el centro entre las regiones emparejadas de Azure. Por lo general, los dispositivos se encuentran cerca de la región primaria del centro. Si mueve el centro a la región secundaria, la latencia aumenta para las operaciones entre los dispositivos y el centro de IoT en la ubicación secundaria.

Costos

En el caso de los centros emparejados, no hay ningún costo adicional para la conmutación por error o la replicación de datos entre regiones.

Si el centro de IoT está en una región no pareada, consulte enfoques alternativos de varias regiones para obtener posible información de costos.

Configuración de la replicación y preparación de la conmutación por error

De forma predeterminada, la replicación de datos entre regiones se configura automáticamente al crear un centro de IoT en una región emparejada. Este proceso es una opción predeterminada y no requiere intervención de usted. En regiones, excepto el Sur de Brasil y sudeste de Asia (Singapur), los datos del cliente no se almacenan ni procesan fuera de la geografía en la que se implementa la instancia de servicio.

Si el centro de IoT se encuentra en las regiones Sur de Brasil o Sudeste de Asia (Singapur), puede deshabilitar la replicación de datos y no participar en la conmutación por error. Para obtener más información, consulte Deshabilitación de la recuperación ante desastres (DR).

Si el centro de IoT está en una región no emparejada, debe planear su propio enfoque de replicación y conmutación por error entre regiones. Para obtener más información, consulte Enfoques alternativos de varias regiones.

Operaciones normales

En esta sección se describe qué esperar cuando se configura un centro de IoT para la replicación y la conmutación por error entre regiones, y la región primaria está operativa.

• Replicación de datos entre regiones: Los datos se replican automáticamente en la región emparejada. La replicación se produce de forma asincrónica, lo que significa que se espera cierta pérdida de datos si se produce una conmutación por error. No hay replicación de datos entre regiones para centros de IoT en regiones no emparejadas.

• Enrutamiento del tráfico entre regiones: En las operaciones normales, el tráfico solo fluye a la región primaria.

Experiencia a nivel de regiones

En esta sección se proporciona una descripción de qué se puede esperar cuando un centro IoT está configurado para la replicación y la conmutación por error interregional y hay una interrupción en la región primaria.

• Detección y respuesta: La responsabilidad de detectar y responder a una interrupción en la región primaria puede variar.

  • Conmutación por error iniciada por el cliente: es responsable de detectar una pérdida de región y decidir cuándo conmutar por error. Para obtener más información sobre cómo realizar la conmutación por error iniciada por el cliente entre regiones emparejadas, consulte Realización de una conmutación por error manual para un centro de IoT.

    Hay límites sobre la frecuencia con la que puede realizar la conmutación por error o la conmutación por recuperación iniciadas por el cliente:

    • A los usuarios se les permite realizar dos operaciones correctas de conmutación por error y dos operaciones correctas de conmutación por recuperación al día.

    • No se permite realizar operaciones consecutivas de conmutación por error o conmutación por recuperación. Debe esperar una hora entre estas operaciones.

  • Conmutación por error iniciada por Microsoft: Microsoft puede decidir realizar una conmutación por error si se pierde la región primaria. Este proceso puede tardar varias horas después de la pérdida de la región primaria o incluso más tiempo en algunos escenarios. Es posible que la conmutación por error de los recursos de IoT Hub no ocurra al mismo tiempo que la de otros servicios de Azure.

• Solicitudes activas: Es probable que se pierdan todas las solicitudes que la región primaria está procesando durante una conmutación por error. Los clientes deben reintentar solicitudes una vez completada la conmutación por error.

• Pérdida de datos esperada: En el caso de las regiones emparejadas, los datos se replican de forma asincrónica en la región emparejada. Por lo tanto, se anticipa cierta pérdida de datos tras el failover. Este proceso se aplica tanto a las conmutaciones por error administradas por Microsoft como a las administradas por el cliente. En la tabla siguiente se describe el objetivo de punto de recuperación (RPO) o la pérdida de datos esperada, de cada tipo de datos que almacenan los centros de IoT.

  Tipo de dato	RPO
  Registro de identidad	Pérdida de datos de 0 a 5 minutos
  Datos del dispositivo gemelo	Pérdida de datos de 0 a 5 minutos
  Mensajes de nube a dispositivo 1	Pérdida de datos de 0 a 5 minutos
  Trabajos principales 1 y de dispositivo	Pérdida de datos de 0 a 5 minutos
  Mensajes de dispositivo a nube	Todos los mensajes no leídos se pierden
  Mensajes de comentarios de la nube al dispositivo	Todos los mensajes no leídos se pierden

  ¹Los mensajes de la nube al dispositivo y los trabajos principales no se recuperan como parte de la conmutación por error iniciada por el cliente.

• Tiempo de inactividad esperado: El tiempo de inactividad esperado durante la conmutación por error de la región depende del tipo de conmutación por error.

  • Conmutación por error iniciada por el cliente: Se espera aproximadamente de 10 minutos a 2 horas de tiempo de inactividad desde el momento en que se pierde la región hasta cuando el recurso esté operativo en la región emparejada. El número de dispositivos registrados en la instancia de centro de IoT que se conmuta por error afecta al tiempo de recuperación. Puede esperar que el tiempo de recuperación de un centro que hospede aproximadamente 100 000 dispositivos sea de aproximadamente 15 minutos.

  • Conmutación por error iniciada por Microsoft: espere aproximadamente de 2 minutos a 26 horas de tiempo de inactividad desde el momento en que se pierde la región hasta que el recurso esté operativo en la región emparejada.

    El tiempo de recuperación prolongado se debe a que Microsoft debe ejecutar la operación de conmutación por error en nombre de todos los clientes afectados en dicha región. En el caso de los sistemas críticos, debe usar la conmutación por error iniciada por el cliente para reducir el tiempo de inactividad. Sin embargo, si ejecuta una solución de IoT menos crítica que puede mantener un tiempo de inactividad de aproximadamente un día, puede ser posible depender de la opción iniciada por Microsoft para satisfacer los objetivos generales de recuperación ante desastres de la solución de IoT.

  • En ambos tipos de conmutación por error, el nombre de dominio completo de la instancia de IoT Hub sigue siendo el mismo después de la conmutación por error, lo que significa que la cadena de conexión también sigue siendo la misma. Sin embargo, dado que cambia la dirección IP subyacente, los clientes deben esperar a que los registros del sistema de nombres de dominio (DNS) se actualicen antes de acceder al centro de IoT después de la conmutación por error.

    Importante

    Los SDK de IoT Hub no almacenan en caché la dirección IP del centro de IoT. El código de usuario que interconecta con los SDK tampoco debe almacenar en caché la dirección IP del centro de IoT.

    Debido a estos factores, el tiempo que tardan las operaciones de tiempo de ejecución en volverse completamente operativas en su instancia de IoT Hub después del proceso de conmutación por error se puede expresar mediante la siguiente función:

    Tiempo de recuperación = RTO [10 minutos a 2 horas para la conmutación por error iniciada por el cliente o de 2 a 26 horas para la conmutación por error iniciada por Microsoft] + Retraso de propagación de DNS + Tiempo que tarda la aplicación cliente en actualizar cualquier dirección IP de IoT Hub almacenada en caché

• Reenrutamiento del tráfico: Durante el proceso de conmutación por error, IoT Hub actualiza los registros DNS para que apunten a la región emparejada. Todas las solicitudes posteriores se envían a la región emparejada.

  Una vez completada la operación de conmutación por error del centro de IoT, se espera que todas las operaciones del dispositivo y las aplicaciones de back-end sigan funcionando sin necesidad de intervención manual. Esta continuidad garantiza que los mensajes del dispositivo a la nube sigan funcionando y que todo el registro de dispositivos esté intacto. Si emite eventos a través de Azure Event Grid, se pueden consumir a través de las mismas suscripciones que configuró anteriormente, siempre que esas suscripciones de Event Grid sigan estando disponibles. No se requiere ningún control adicional para los puntos de conexión personalizados.

Se requiere una configuración posterior a la conmutación por error

En función de dónde redirija los mensajes del centro de IoT, es posible que tenga que realizar pasos adicionales después de que se complete la conmutación por error.

• Azure Event Hubs: el nombre compatible con Event Hubs y el punto de conexión de los eventos integrados en el centro de IoT cambian tras la conmutación por error. Este cambio se produce porque el cliente de Event Hubs no tiene visibilidad de los eventos de IoT Hub.

  Cuando reciba mensajes de telemetría procedentes del punto de conexión integrado mediante el cliente de Event Hubs o el host del procesador de eventos, use la cadena de conexión del centro de IoT para establecer la conexión. Este enfoque garantiza que las aplicaciones de back-end sigan funcionando sin necesidad de intervención manual después de la conmutación por error.

  Si usa el nombre y el punto de conexión compatibles con Event Hubs directamente en la aplicación, tiene que capturar el nuevo punto de conexión compatible con Event Hubs después de la conmutación por error para continuar con las operaciones. Para recuperar el punto de conexión y el nombre, puede usar Azure Portal o el SDK de .NET:

  • Azure Portal: Para obtener más información sobre cómo usar el portal para recuperar el punto de conexión compatible con Event Hubs y el nombre compatible con Event Hubs, consulte Conexión al punto de conexión integrado.

  • El SDK de .NET: Para usar la cadena de conexión de IoT Hub y obtener el punto de conexión compatible con Event Hubs, utilice el código de ejemplo. En este ejemplo de código se usa la cadena de conexión para obtener el nuevo punto de conexión de Event Hubs y volver a establecer la conexión. Debe tener Visual Studio instalado.

• Azure Functions y Azure Stream Analytics: Si usa Azure Functions o Stream Analytics para conectarse al punto de conexión de eventos integrado, debe actualizar el punto de conexión de Event Hubs al que se conecta la función o el trabajo, siguiendo el mismo proceso descrito en el punto de viñeta anterior. Después, realice una acción de Reiniciar porque los desplazamientos del flujo de eventos se vuelven inválidos después de la conmutación por error.

• Azure Storage: Al enrutar a Azure Storage, enumere primero los blobs o archivos. Luego, itere sobre ellos para asegurarse de que todos los blobs o archivos se leen sin asumir el particionamiento. El intervalo de particiones puede cambiar potencialmente durante una conmutación por error iniciada por Microsoft o una conmutación por error iniciada por el cliente. Puede usar la List Blobs API para enumerar los blobs o usar la List Azure Data Lake Storage API para la lista de archivos. Para más información, consulte Azure Storage como punto de conexión de enrutamiento.

Conmutación por recuperación

Para conmutar por recuperación a la región primaria, puede desencadenar manualmente la acción de conmutación por error una segunda vez. Es importante recordar las restricciones sobre la frecuencia con la que puede conmutar por error.

Si la operación de conmutación por error original se ha realizado para recuperarse de una interrupción extendida en la región principal original, realice la conmutación por recuperación en la región principal después de que la región principal se recupere de la interrupción.

Pruebas de errores de región

Para simular un error durante una interrupción de la región, puede desencadenar una conmutación por error manual del centro de IoT. Sin embargo, dado que la conmutación por error regional provoca tiempo de inactividad y pérdida de datos, solo debe realizar conmutaciones por error de prueba en entornos que no sean de producción. Para obtener más información, consulte Experiencia de reducción de regiones. Considere la posibilidad de configurar una instancia de IoT Hub de prueba para iniciar la opción de conmutación por error planeada periódicamente. Las pruebas periódicas pueden ayudarle a crear confianza en su capacidad de restaurar y operar sus soluciones de un extremo a otro de forma eficaz cuando se produce un desastre real.

Enfoques alternativos de varias regiones

Las funcionalidades de conmutación por error entre regiones de IoT Hub no son adecuadas para los escenarios siguientes:

• El centro de IoT se encuentra en una región no emparejada.

• Los objetivos de tiempo de actividad empresarial no se satisfacen por el tiempo de recuperación o la pérdida de datos que proporciona la opción de conmutación por error integrada.

• Debe conmutar por error a una región que no esté emparejada con la región principal.

Puede diseñar una solución de conmutación por error entre regiones adaptada a cada dispositivo individual. Un tratamiento completo de las topologías de implementación en soluciones de IoT está fuera del ámbito de este artículo, pero puede considerar un modelo de implementación de varias regiones. En este modelo, la instancia principal de IoT Hub y el back-end de la solución se ejecutan principalmente en una región de Azure. Un centro de IoT secundario y un back-end se implementan en otra región de Azure. Si el centro de IoT de la región primaria experimenta una interrupción o se interrumpe la conectividad de red desde el dispositivo a la región primaria, los dispositivos usan un punto de conexión de servicio secundario.

• Tiempo de inactividad esperado: Este enfoque tiene menos de un minuto de tiempo de inactividad, pero puede ser complejo de implementar.

• Pérdida de datos esperada: La cantidad de pérdida de datos depende de los almacenes de datos específicos que use y de la forma en que configure la replicación geográfica entre ellos.

• Costar: Este enfoque requiere que aprovisione al menos un centro de IoT adicional, lo que aumenta el costo total.

A grandes rasgos, para implementar un modelo de conmutación por error regional con IoT Hub, necesitará seguir estas medidas:

• Una lógica secundaria de IoT Hub y enrutamiento de dispositivos: Si se interrumpe el servicio de la región primaria, los dispositivos deben empezar a conectarse a la región secundaria. Como se conoce el estado de la mayoría de los servicios implicados, es habitual que los administradores de la solución desencadenen manualmente el proceso de conmutación por error entre regiones. La mejor manera de comunicar el nuevo punto de conexión a los dispositivos mientras mantiene el control sobre el proceso es hacer que comprueben periódicamente un servicio de conserjería para el punto de conexión activo actual. El servicio de conserjería puede ser una aplicación web que se replica y se mantiene accesible mediante técnicas de redirección de DNS, como Azure Traffic Manager.

  Nota:

  Traffic Manager no tiene compatibilidad integrada con IoT Hub. Puede configurar puntos de conexión personalizados de Traffic Manager para cada centro de IoT. Configure el sondeo de estado del punto de conexión de Traffic Manager para usar el punto de conexión del centro de IoT.

• Replicación del Registro de identidad: Para poder usarse, el centro de IoT secundario debe contener todas las identidades de dispositivo que se pueden conectar a la solución. La solución debe mantener copias de seguridad con replicación geográfica de identidades de dispositivo y cargarlas en el centro de IoT secundario antes de cambiar el punto de conexión activo para los dispositivos. La funcionalidad de exportación de identidades de dispositivo de IoT Hub resulta muy útil en este contexto. Para obtener más información, consulte Descripción del registro de identidades en IoT Hub.

• Lógica de combinación: Cuando la región primaria vuelva a estar disponible, todos los datos y el estado creados en la región secundaria se deben volver a migrar a la región primaria. Este estado y estos datos tienen que ver principalmente con las identidades de dispositivo y los metadatos de aplicación, que deben combinarse con el centro de IoT principal y con otros almacenes específicos de la aplicación en la región primaria.

  Para simplificar este paso, use operaciones idempotentes . Las operaciones idempotentes minimizan los efectos secundarios de la posible distribución uniforme de eventos y de los duplicados o la entrega desordenada de eventos. Además, la lógica de la aplicación debe diseñarse para tolerar posibles incoherencias o un estado ligeramente obsoleto. Este escenario puede producirse debido al tiempo adicional que tarda el sistema en recuperarse en función de los RPO.

Copias de seguridad

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para obtener más información, consulte Redundancia, replicación y copia de seguridad.

El servicio IoT Hub habilita las operaciones de exportación masiva, que permiten exportar todo el registro de identidad de un centro de IoT. Estos datos se transfieren a un contenedor de blobs de Azure Storage mediante una firma de acceso compartido. Este método permite crear copias de seguridad confiables de la información del dispositivo en un contenedor de blobs que controle. Para más información, consulte Importación y exportación de identidades de dispositivo de IoT Hub en masa.

También puede exportar la plantilla de Azure Resource Manager (plantilla de ARM) de un IoT Hub existente para crear una copia de seguridad de la configuración del IoT Hub. Para obtener más información, consulte Migrar manualmente un IoT hub utilizando una plantilla ARM.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para IoT Hub describe la disponibilidad esperada del servicio y las condiciones que se deben cumplir para lograr esa expectativa de disponibilidad. Para comprender esas condiciones, es importante revisar los Acuerdos de Nivel de Servicio para los servicios en línea.

Contenido relacionado

• Confiabilidad en Azure
• Escalabilidad, alta disponibilidad y recuperación ante desastres de soluciones de IoT