Conceptos sobre el reaprovisionamiento de dispositivos de IoT Hub
Durante el ciclo de vida de una solución de IoT, es habitual mover los dispositivos entre centros de IoT. Las razones de este movimiento pueden incluir los siguientes escenarios:
Geolocalización o geolatencia: puesto que un dispositivo se mueve entre ubicaciones, la latencia de red se mejora mediante la migración del dispositivo a un centro de IoT más cercano.
Servicios multiinquilino: un dispositivo puede usarse dentro de la misma solución de IoT y reasignarse a un cliente nuevo o al sitio de un cliente. Este nuevo cliente se puede atender mediante un centro de IoT diferente.
Cambio de la solución: un dispositivo se podría mover a una solución de IoT nueva o actualizada. Esta reasignación puede requerir que el dispositivo se comunique con un nuevo centro de IoT que esté conectado a otros componentes back-end.
Cuarentena: es similar a un cambio de la solución. Un dispositivo que no funciona correctamente, que está en peligro o no actualizado se puede reasignar a un centro de IoT para actualizarse y volver a estar en condiciones. Una vez que el dispositivo está funcionando correctamente, se vuelve a migrar a su centro principal.
La compatibilidad del reaprovisionamiento en el Device Provisioning Service soluciona estas necesidades. Los dispositivos se pueden reasignar automáticamente a nuevos centros de IoT basados en la directiva de reaprovisionamiento configurada en la entrada de inscripción del dispositivo.
Datos sobre el estado del dispositivo
Los datos sobre el estado del dispositivo están formados por las funcionalidades del dispositivo y el dispositivo gemelo. Estos datos se almacenan en la instancia de Device Provisioning Service y el centro de IoT al cual está asignado un dispositivo.
Cuando un dispositivo se aprovisiona inicialmente con una instancia de Device Provisioning Service, se llevan a cabo los pasos siguientes:
El dispositivo envía una solicitud de aprovisionamiento a una instancia de Device Provisioning Service. La instancia de servicio autentica la identidad del dispositivo en función de una entrada de inscripción y crea la configuración inicial de los datos de estado del dispositivo. La instancia de servicio asigna el dispositivo a un centro de IoT en función de la configuración de inscripción y devuelve esa asignación del centro de IoT al dispositivo.
La instancia de servicio de aprovisionamiento proporciona una copia de los datos sobre el estado inicial del dispositivo al centro de IoT asignado. El dispositivo se conecta al centro de IoT asignado y comienza a realizar las operaciones.
Con el tiempo, las operaciones del dispositivo y las operaciones de back-end pueden actualizar los datos sobre el estado del dispositivo en el centro de IoT. La información sobre el estado inicial del dispositivo almacenada en la instancia de Device Provisioning Service permanece sin cambios. Estos datos sobre el estado del dispositivo sin modificar conforman la configuración inicial.
En función del escenario, a medida que un dispositivo se mueve entre centros de IoT, también puede ser necesario migrar el estado del dispositivo actualizado en el anterior centro de IoT al nuevo centro de IoT. Esta migración está respaldada por las directivas de reaprovisionamiento de Device Provisioning Service.
Volver a aprovisionar directivas
Según el escenario, un dispositivo podría enviar una solicitud a una instancia de servicio de aprovisionamiento al reiniciarse. También admite un método para desencadenar manualmente el aprovisionamiento a petición. La directiva de reaprovisionamiento en una entrada de inscripción determina la forma en la que la instancia de Device Provisioning Service administra estas solicitudes de aprovisionamiento. La directiva también determina si se deben migrar los datos de estado del dispositivo durante el reaprovisionamiento. Las mismas directivas están disponibles para las inscripciones individuales y los grupos de inscripción:
Volver a aprovisionar y migrar datos: esta directiva es el valor predeterminado para las nuevas entradas de inscripción. Esta directiva toma medidas cuando los dispositivos asociados a la entrada de inscripción envían una nueva solicitud (1). Según la configuración de la entrada de inscripción, el dispositivo se puede reasignar a otro centro de IoT. Si el dispositivo cambia a los centros de IoT, se quitará el registro de dispositivos con el centro de IoT inicial. La información sobre el estado actualizado del dispositivo se migrará de este centro de IoT inicial al nuevo centro de IoT (2). Durante la migración, el estado del dispositivo será Assigning (Asignando).
Volver a aprovisionar y restablecer a la configuración inicial: esta directiva realiza acciones cuando los dispositivos asociados a la entrada de inscripción envían una nueva solicitud de aprovisionamiento (1). Según la configuración de la entrada de inscripción, el dispositivo se puede reasignar a otro centro de IoT. Si el dispositivo cambia a los centros de IoT, se quitará el registro de dispositivos con el centro de IoT inicial. Los datos de configuración inicial que recibió la instancia del servicio de aprovisionamiento al aprovisionar el dispositivo se proporcionan para el nuevo centro de IoT (2). Durante la migración, el estado del dispositivo será Assigning (Asignando).
Esta directiva se utiliza a menudo para llevar a cabo un restablecimiento de fábrica sin cambiar los centros de IoT.
Nunca reaprovisionar: el dispositivo nunca se reasigna a un centro diferente. Esta directiva se proporciona para administrar la compatibilidad con versiones anteriores.
Nota:
DPS siempre llamará al webhook de asignación personalizada sin importar la directiva de reaprovisionamiento en caso de que haya nuevos ReturnData para el dispositivo. Si la directiva de reaprovisionamiento se establece en nunca volver a aprovisionar, se llamará al webhook, pero el dispositivo no cambiará su centro asignado.
Al diseñar la solución y definir una lógica de reaprovisionamiento, hay algunas cosas que se deben tener en cuenta. Por ejemplo:
- Frecuencia con la que espera que se reinicien los dispositivos
- Las cuotas y límites de DPS
- Tiempo de implementación esperado para la flota (lanzamiento por fases frente a todos a la vez)
- Capacidad de reintento implementada en el código de cliente, como se describe en la Orientación general sobre reintentos en el Centro de arquitectura de Azure
Sugerencia
Se recomienda no aprovisionar en cada reinicio del dispositivo, ya que esto podría provocar algunos problemas al volver a aprovisionar varios miles o millones de dispositivos a la vez. En su lugar, debe intentar usar la API Device Registration Status Lookup e intentar conectarse con esa información a IoT Hub. Si se produce un error, intente volver a aprovisionar, ya que la información de IoT Hub podría haber cambiado. Tenga en cuenta que la consulta del estado de registro contará como un nuevo registro de dispositivos, por lo que debe tener en cuenta el límite de registro de dispositivos. Considere también la posibilidad de implementar una lógica de reintento adecuada, como un retroceso exponencial con selección aleatoria, como se describe en la Orientación general sobre reintentos. En algunos casos, en función de las funcionalidades del dispositivo, es posible guardar la información de IoT Hub directamente en el dispositivo para conectarse directamente a IoT Hub después de que se produjese el aprovisionamiento por primera vez mediante DPS. Si decide hacerlo, asegúrese de implementar un mecanismo de reserva en caso de que se produzcan errores específicos del centro, por ejemplo, tenga en cuenta los siguientes escenarios:
- Vuelva a intentar la operación del centro si el código de resultado es 429 (demasiadas solicitudes) o un error en el rango 5xx. No lo intente de nuevo para cualquier otro error.
- En el caso de los errores 429, inténtelo de nuevo después de la hora indicada en el encabezado Retry-After.
- En el caso de los errores 5xx, use el retroceso exponencial, con el primer reintento al menos 5 segundos después de la respuesta.
- Si hay errores distintos de 429 y 5xx, vuelva a registrarse a través de DPS
- Lo ideal es que también admita un método para desencadenar manualmente el aprovisionamiento a petición.
También se recomienda tener en cuenta los límites de servicio al planear actividades, como insertar actualizaciones en la flota. Por ejemplo, la actualización de la flota a la vez podría hacer que todos los dispositivos se vuelvan a registrar a través de DPS (que podría estar fácilmente por encima del límite de cuota de registro): para estos escenarios, considere la posibilidad de planear actualizaciones de dispositivos en fases en lugar de actualizar toda la flota al mismo tiempo.
Administración de la compatibilidad con versiones anteriores
Antes de septiembre de 2018, las asignaciones de dispositivos a centros de IoT tenían un comportamiento complicado. Cuando un dispositivo retrocedía mediante el proceso de aprovisionamiento, solo se podía asignar al mismo centro de IoT.
Para las soluciones que dependen de este comportamiento, el servicio de aprovisionamiento incluye la compatibilidad con versiones anteriores. Este comportamiento se mantiene actualmente para los dispositivos según los criterios siguientes:
Los dispositivos se conectan con una versión de API anterior a la disponibilidad de la compatibilidad nativa con el reaprovisionamiento en Device Provisioning Service. Consulte la siguiente tabla de API.
La entrada de inscripción para los dispositivos no tiene ninguna directiva de reaprovisionamiento establecida.
Esta compatibilidad garantiza que los dispositivos que hayan implementado previamente experimenten el mismo comportamiento presente durante las pruebas iniciales. Para conservar el comportamiento anterior, no guarde ninguna directiva de reaprovisionamiento en estas inscripciones. Si se establece una directiva de reaprovisionamiento, la directiva de reaprovisionamiento tiene prioridad sobre el comportamiento. Al permitir que la directiva de reaprovisionamiento tenga prioridad, los clientes pueden actualizar el comportamiento del dispositivo sin tener que restablecer la imagen inicial del dispositivo.
En el siguiente gráfico de flujo se muestran los casos en los que existe el comportamiento:
En la tabla siguiente se muestran las versiones de API anteriores a la disponibilidad de la compatibilidad nativa con el reaprovisionamiento en Device Provisioning Service:
| REST API | C SDK | SDK de Python | SDK de Node | SDK de Java | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 y versiones anteriores | 1.2.8 y versiones anteriores | 1.4.2 y versiones anteriores | 1.7.3 o versiones anteriores | 1.13.0 o versiones anteriores | 1.1.0 o versiones anteriores |
Nota:
Es probable que estos valores y vínculos cambien. Solo se trata de un intento para determinar en qué punto un cliente puede determinar las versiones y cuáles son las versiones esperadas.