Administración de reconexión de dispositivos para crear aplicaciones resistentes

Artículo
04/13/2024

En este artículo, se proporcionan instrucciones de alto nivel para ayudarle a diseñar aplicaciones resistentes mediante la adición de una estrategia de reconexión de dispositivos. Explica por qué los dispositivos se desconectan y deben volver a conectarse. Además, describe estrategias específicas que los desarrolladores pueden usar para volver a conectar dispositivos que se han desconectado.

¿Qué provoca las desconexiones?

A continuación se muestran los motivos más comunes por los que los dispositivos se desconectan de IoT Hub:

Certificado X.509 o token SAS caducado. El token SAS del dispositivo o el certificado de autenticación X.509 han caducado.
Interrupción de la red. Se ha interrumpido la conexión del dispositivo a la red.
Interrupción del servicio. El servicio Azure IoT Hub experimenta errores o no está disponible temporalmente.
Reconfiguración del servicio. Después de volver a configurar los valores del servicio IoT Hub, es posible que los dispositivos requieran reaprovisionamiento o reconexión.

Por qué necesita una estrategia de reconexión

Es importante tener una estrategia para volver a conectar los dispositivos, como se describe en las secciones siguientes. Sin una estrategia de reconexión, podría observar un efecto negativo en el rendimiento, la disponibilidad y el costo de la solución.

Los intentos de reconexión masiva podrían provocar un DDoS

Un gran número de intentos de conexión por segundo puede provocar una condición similar a un ataque por denegación de servicio distribuido (DDoS). Este escenario es relevante para grandes flotas de dispositivos, con consecuencias muy onerosas. El problema puede extenderse más allá del inquilino propietario de la flota y afectar a toda la unidad de escalado. Un DDoS podría suponer un gran aumento de costos para los recursos de Azure IoT Hub, debido a la necesidad de escalar horizontalmente. Un DDoS también podría afectar al rendimiento de la solución debido a la falta de recursos. En el peor de los casos, un DDoS puede provocar una interrupción del servicio.

El error o la reconfiguración del centro podría desconectar muchos dispositivos

Después de que un centro de IoT experimente un error o tras volver a configurar los valores del servicio en un centro de IoT, es posible que los dispositivos se desconecten. Para una conmutación por error adecuada, los dispositivos desconectados requieren reaprovisionamiento. Para obtener más información sobre las opciones de conmutación por error, consulte Alta disponibilidad y recuperación ante desastres de IoT Hub.

El reaprovisionamiento de muchos dispositivos podría aumentar los costos

Después de que los dispositivos se desconecten de IoT Hub, la solución óptima es volver a conectar el dispositivo, en lugar de volver a aprovisionarlo. Si usa IoT Hub con DPS, DPS tiene un costo por aprovisionamiento. Si se vuelven a aprovisionar muchos dispositivos en DPS, aumenta el costo de la solución de IoT. Para más información sobre los costos de aprovisionamiento de DPS, consulte Precios de IoT Hub DPS.

Diseño para lograr resistencia

A menudo, los dispositivos IoT se basan en conexiones de red no continuas o inestables, como GSM o las conexiones por satélite. Los errores suceden cuando los dispositivos interactúan con los servicios basados en la nube debido a la disponibilidad intermitente del servicio y los errores transitorios o de nivel de infraestructura. Una aplicación que se ejecuta en un dispositivo debe administrar los mecanismos de conexión y reconexión, así como la lógica de reintentos para enviar o recibir mensajes. Además, los requisitos de la estrategia de reintento dependen en gran medida del escenario, el contexto y las capacidades de IoT del dispositivo.

El objetivo de los SDK de los dispositivos Azure IoT Hub es simplificar la conexión y la comunicación de la nube a los dispositivos y de los dispositivos a la nube. Estos SDK proporcionan una manera sólida de conectarse a Azure IoT Hub y un conjunto completo de opciones para enviar y recibir mensajes. Los desarrolladores también pueden modificar la implementación existente para personalizar mejor la estrategia de reintento adecuada para un escenario determinado.

Las características pertinentes del SDK que admiten la conectividad y la mensajería de confianza están disponibles en los SDK de dispositivo de IoT Hub. Para obtener más información, consulte la documentación de la API o el SDK específico:

En las secciones siguientes se describen las características del SDK que admiten la conectividad.

Conexión y reintento

En esta sección se proporciona información general de los patrones de reconexión y reintento disponibles al administrar las conexiones. Además detalla la guía de implementación para usar una directiva de reintentos diferente en la aplicación del dispositivo y enumera las API relevantes de los SDK del dispositivo.

Patrones de error

Los errores de conexión pueden producirse en muchos niveles:

Errores de red: un socket desconectado y errores de resolución de nombres.
Errores a nivel de protocolo para el transporte de HTTP, AMQP y MQTT: vínculos desasociados o sesiones expiradas.
Errores a nivel de aplicación que se generan a partir de errores locales: credenciales no válidas o un comportamiento de servicio, como exceder una cuota o una limitación.

Los SDK de dispositivo detectan errores en los tres niveles. Sin embargo, los SDK de dispositivo no detectan ni controlan los errores relacionados con el sistema operativo ni los errores de hardware. El SDK se basa en la guía para controlar errores transitorios del Centro de arquitectura de Azure.

Patrones de reintentos

Los pasos siguientes describen el proceso de reintento cuando se detectan errores de conexión:

El SDK detecta el error y el error asociado en la red, el protocolo o la aplicación.
El SDK usa el filtro de error para determinar el tipo de error y decidir si es necesario un reintento.
Si el SDK identifica un error irrecuperable, operaciones como la conexión, el envío y la recepción se detienen. El SDK notifica al usuario. Un error de autenticación y un error de punto de conexión incorrecta son ejemplos de errores irrecuperables.
Si el SDK identifica un error recuperable, vuelve a intentar el proceso según la directiva de reintentos especificada hasta que transcurra el tiempo de espera definido. El SDK usa la directiva de reintento de Retroceso exponencial con vibración de forma predeterminada.
Cuando el tiempo de espera definido expira, el SDK deja de tratar de conectarse o de enviar el contenido. Notifica al usuario.
El SDK permite que el usuario adjunte una devolución de llamada para recibir los cambios de estado de la conexión.

Los SDK suelen proporcionar tres directivas de reintento:

Retroceso exponencial con vibración: esta directiva de reintentos predeterminada tiende a ser agresiva al principio y se ralentiza poco a poco hasta que se alcanza un retraso máximo. El diseño se basa en la guía de reintentos de Azure Architecture Center.
Reintento personalizado: para algunos idiomas del SDK, puede diseñar una directiva de reintentos personalizada que sea más adecuada para su escenario y luego agregarla en RetryPolicy. El reintento personalizado no está disponible en el SDK de C y no se admite actualmente en el SDK de Python. El SDK de Python se vuelve a conectar según sea necesario.
Sin reintentos: puede establecer la directiva de reintentos en "sin reintentos" para deshabilitar la lógica de reintentos. El SDK intenta conectarse una vez y envía un mensaje una vez, suponiendo que se establece la conexión. Esta directiva se usa normalmente en escenarios con problemas de ancho de banda o de costos. Si elige esta opción, tenga en cuenta que los mensajes que no se envíen se perderán y no se podrán recuperar.

API de directiva de reintentos

SDK	Método SetRetryPolicy	Implementaciones de directivas	Guía de implementación
C	IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy	Consulte: IOTHUB_CLIENT_RETRY_POLICY	Implementación de C
Java	SetRetryPolicy	Valor predeterminado: ExponentialBackoffWithJitter class Personalizado: implemente la interfaz RetryPolicy Sin reintento:clase NoRetry	Implementación de Java
.NET	DeviceClient.SetRetryPolicy	Valor predeterminado: ExponentialBackoff class Personalizado: implemente la interfaz IRetryPolicy Sin reintento:clase NoRetry	Implementación de C#
Nodo	setRetryPolicy	Valor predeterminado: ExponentialBackoffWithJitter class Personalizado: implemente la interfaz RetryPolicy Sin reintento:clase NoRetry	Implementación de Node
Python	No se admite actualmente.	No se admite actualmente.	Reintentos de conexión integrados: Las conexiones eliminadas se reintentan con un intervalo fijo de 10 segundos de forma predeterminada. Esta funcionalidad se puede deshabilitar, si lo desea, y se puede configurar el intervalo.

Flujo de reconexión del centro

Si usa IoT Hub solo sin DPS, use la siguiente estrategia de reconexión.

Cuando un dispositivo no se puede conectar a IoT Hub o se desconecta de IoT Hub:

Use una función de retraso de retroceso exponencial con vibración.
Vuelva a conectarse a IoT Hub.

En el diagrama siguiente, se resume el flujo de reconexión:

Diagrama del flujo de reconexión de dispositivos para IoT Hub.

Flujo de reconexión de centro con DPS

Si usa IoT Hub con DPS, use la siguiente estrategia de reconexión.

Cuando un dispositivo no se puede conectar a IoT Hub o se desconecta de IoT Hub, vuelva a conectarse en función de los casos siguientes:

Escenario de reconexión	Estrategia de reconexión
Para los errores que permiten reintentos de conexión (código de respuesta HTTP 500)	Use una función de retraso de retroceso exponencial con vibración. Vuelva a conectarse a IoT Hub.
Para los errores que indican que es posible un reintento, pero la reconexión ha producido un error 10 veces consecutivas	Vuelva a aprovisionar el dispositivo en DPS.
Para los errores que no permiten reintentos de conexión (respuestas HTTP 401 - No autorizado, 403 - Prohibido, o 404 - No encontrado)	Vuelva a aprovisionar el dispositivo en DPS.