Alta disponibilidad y recuperación ante desastres de IoT Hub
Como primer paso para implementar una solución IoT resistente, los arquitectos, desarrolladores y propietarios de empresas deben definir los objetivos de tiempo de actividad para las soluciones que vayan a crear. Estos objetivos se pueden definir principalmente en función de los objetivos de negocio específicos para cada escenario. En este contexto, en el artículo de orientación técnica sobre la continuidad empresarial de Azure se describe un marco general para ayudar a reflexionar sobre la continuidad empresarial y recuperación ante desastres. El documento Recuperación ante desastres y alta disponibilidad para aplicaciones de Azure proporciona una guía de arquitectura enfocada a estrategias para que las aplicaciones de Azure logren alta disponibilidad y recuperación ante desastres.
En este artículo se describen las características de alta disponibilidad y recuperación ante desastres que ofrece específicamente el servicio IoT Hub. Las amplias áreas tratadas en este artículo son:
- Alta disponibilidad dentro de una región
- Recuperación ante desastres entre regiones
- Lograr alta disponibilidad entre regiones
Según los objetivos de tiempo de actividad que defina para las soluciones de IoT, debe determinar cuál de las opciones que se describen en este artículo se adapta mejor a sus objetivos de negocio. La incorporación de cualquiera de estas alternativas de alta disponibilidad y recuperación ante desastres en la solución de IoT requiere una evaluación cuidadosa de las ventajas y desventajas entre:
- El nivel de resistencia que necesita
- La complejidad de implementación y mantenimiento
- El impacto de COGS
Alta disponibilidad dentro de una región
El servicio IoT Hub proporciona alta disponibilidad dentro de una región mediante la implementación de redundancias en casi todos los niveles del servicio. El Acuerdo de Nivel de Servicio publicado por el servicio IoT Hub se consigue con el uso de estas redundancias. Los desarrolladores de una solución de IoT no deben realizar ningún trabajo adicional para poder beneficiarse de estas características de alta disponibilidad. Aunque IoT Hub ofrece una garantía de tiempo de actividad razonablemente elevada, los errores transitorios todavía se pueden esperar al igual que con cualquier plataforma de informática distribuida. Si acaba de empezar con la migración de sus soluciones a la nube desde una solución local, su enfoque debe cambiar de la optimización de "tiempo medio entre errores" a "tiempo medio para recuperación". En otras palabras, los errores transitorios se deben considerar normales al trabajar con la nube en la combinación. Se deben integrar patrones de reintento apropiadas en los componentes que interactúan con una aplicación en la nube para solucionar errores transitorios.
Zonas de disponibilidad
IoT Hub admite igualmente zonas de disponibilidad de Azure. Una zona de disponibilidad es una oferta de alta disponibilidad que protege las aplicaciones y los datos contra los errores que se producen en los centros de datos. Una región que admite zonas de disponibilidad consta de tres zonas que admiten esa región. Cada zona proporciona uno o varios centros de datos en una ubicación física única con alimentación, refrigeración y redes independientes. Esta configuración proporciona replicación y redundancia dentro de la región.
Las zonas de disponibilidad ofrecen dos ventajas: resistencia de datos e implementaciones más fluidas.
La resistencia de datos proviene de reemplazar los servicios de almacenamiento subyacentes por un almacenamiento compatible con las zonas de disponibilidad. La resistencia de datos es importante para las soluciones de IoT, ya que estas soluciones suelen funcionar en entornos complejos, dinámicos e inciertos en los que los errores o las interrupciones pueden tener consecuencias significativas. Tanto si una solución IoT da soporte a una planta de fabricación, a entornos de venta al por menor o restaurantes, a sistemas sanitarios o a infraestructuras, la disponibilidad y la calidad de los datos son necesarias para recuperarse de los fallos y ofrecer servicios fiables y coherentes.
Las implementaciones más fluidas proceden de reemplazar el hardware del centro de datos subyacente por hardware más reciente que admita zonas de disponibilidad. Estas mejoras en el hardware minimizan el impacto en el cliente de las desconexiones y reconexiones de los dispositivos, así como otros tiempos de inactividad relacionados con la implementación. El equipo de ingeniería de IoT Hub implementa varias actualizaciones en cada centro de IoT cada mes, por motivos de seguridad y para proporcionar mejoras de características. El hardware compatible con zonas de disponibilidad se divide en 15 dominios de actualización para que cada actualización sea más fluida, con un impacto mínimo en los flujos de trabajo. Para más información sobre los dominios de actualización, consulte Conjuntos de disponibilidad.
La compatibilidad de las zonas de disponibilidad con IoT Hub se habilita automáticamente para los recursos de IoT Hub creados en las siguientes regiones de Azure:
| Region | Resistencia de datos | Implementaciones más fluidas |
|---|---|---|
| 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 Catar |
|
|
| Centro-Sur de EE. UU. |
|
|
| Sudeste de Asia |
|
|
| Sur de Reino Unido 2 |
|
|
| Oeste de Europa |
|
|
| Oeste de EE. UU. 2 |
|
|
| Oeste de EE. UU. 3 |
|
|
Recuperación ante desastres entre regiones
Podría haber algunas situaciones excepcionales cuando un centro de datos sufre interrupciones prolongadas debido a errores de alimentación u otros errores que afectan a recursos físicos. Estos eventos son muy poco frecuentes y durante ellos es posible que la funcionalidad de alta disponibilidad dentro de la región que se ha descrito anteriormente no siempre sea útil. IoT Hub ofrece varias soluciones para recuperarse de tales interrupciones prolongadas.
Las opciones de recuperación disponibles para los clientes en tal situación son conmutación por error iniciada por Microsoft y conmutación por error manual. La diferencia principal entre ambas opciones es que Microsoft inicia la primera y el usuario inicia la última. Además, la conmutación por error manual ofrece un objetivo de tiempo de recuperación (RTO) inferior en comparación con la opción de conmutación por error iniciada por Microsoft. En las siguientes secciones se tratan los objetivos de tiempo de recuperación específicos que se ofrecen con cada opción. Si se utiliza alguna de estas opciones para realizar la conmutación por error de una instancia de IoT Hub desde su región primaria, dicha instancia queda totalmente operativa en la región de Azure emparejada geográficamente correspondiente.
Ambas opciones de conmutación por error ofrecen los siguientes objetivos de punto de recuperación (RPO):
| Tipo de datos | Objetivos de punto de recuperación (RPO) |
|---|---|
| Registro de identidad | Pérdida de datos de 0-5 minutos |
| Datos del dispositivo gemelo | Pérdida de datos de 0-5 minutos |
| Mensajes de la nube al dispositivo1 | Pérdida de datos de 0-5 minutos |
| Trabajos de dispositivo y primarios1 | Pérdida de datos de 0-5 minutos |
| Mensajes de dispositivo a nube | Se pierden todos los mensajes no leídos |
| Mensajes de comentarios de nube a dispositivo | Se pierden todos los mensajes no leídos |
1Los mensajes de la nube al dispositivo y los trabajos primarios no se recuperan como parte de la conmutación por error manual.
Una vez completada la operación de conmutación por error para la instancia de IoT Hub, se espera que todas las operaciones de las aplicaciones de dispositivo y back-end sigan funcionando sin necesidad de una intervención manual. Esto significa que los mensajes del dispositivo a la nube deben seguir funcionando y todo el registro del dispositivo está intacto. Los eventos emitidos mediante Event Grid pueden consumirse con las mismas suscripciones configuradas anteriormente, siempre y cuando esas suscripciones de Event Grid sigan estando disponibles. No se requiere manipulación adicional para los puntos de conexión personalizados.
Precaución
- El nombre compatible con Event Hubs y el punto de conexión de los eventos integrados en IoT Hub cambian tras la conmutación por error. Cuando se reciben mensajes de telemetría procedentes del punto de conexión integrado mediante el cliente de Event Hubs o el host del procesador de eventos, debe usar la cadena de conexión de IoT Hub para establecer la conexión. Esto 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 Hub directamente en la aplicación, tendrá que capturar el nuevo punto de conexión compatible con Event Hub después de la conmutación por error para continuar con las operaciones. Para obtener más información, vea Conmutación por error manual y Event Hub, más adelante en este tema.
- Si usa Azure Functions o Azure Stream Analytics para conectar el punto de conexión de eventos integrado, puede que tenga que realizar un reinicio. Esto se debe a que, durante la conmutación por error, los desplazamientos anteriores ya no son válidos.
- Al enrutar al almacenamiento, se recomienda enumerar los blobs o los archivos e iterar sobre ellos para garantizar que se leen todos sin pasar por alto ninguna partición. El intervalo de partición podría cambiar durante una conmutación por error iniciada por Microsoft o una conmutación por error manual. Puede usar la API List Blobs para la lista de blobs o la API List ADLS Gen2 para la lista de archivos. Para obtener más información, vea Azure Storage como punto de conexión de enrutamiento.
Conmutación por error iniciada por Microsoft
La conmutación por error iniciada por Microsoft se realiza en situaciones excepcionales para conmutar por error todos los centros de IoT de una región afectada a la región emparejada geográficamente correspondiente. Este proceso es una opción predeterminada y no requiere ninguna intervención por parte del usuario. Microsoft se reserva el derecho a tomar una determinación sobre cuándo ejecutar esta opción. Este mecanismo no precisa de consentimiento del usuario antes de realizar la conmutación por error del centro del usuario. La conmutación por error iniciada por Microsoft tiene un objetivo de tiempo de recuperación (RTO) de 2 a 26 horas.
El RTO 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. Si ejecuta una solución de IoT menos crítica que pueda soportar un tiempo de inactividad de aproximadamente un día, puede depender de esta opción para satisfacer todos los objetivos de recuperación ante desastres de la solución de IoT. El tiempo total de las operaciones de tiempo de ejecución para conseguir la operatividad total una vez desencadenado este proceso se describe en la sección "Tiempo de recuperación".
Los usuarios que implementen centros de IoT en las regiones de Sur de Brasil y Sudeste de Asia (Singapur) son los únicos que pueden optar por no recibir esta característica. Para obtener más información, consulte Deshabilitar la recuperación ante desastres.
Nota
Azure IoT Hub no almacena ni procesa datos de clientes fuera de la geografía en la que se implementa la instancia de servicio. Para obtener más información, consulte Replicación entre regiones en Azure.
Conmutación por error manual
Si no se cumplen los objetivos de tiempo de actividad del negocio con el RTO que ofrece la conmutación por error iniciada por Microsoft, considere el uso de la conmutación por error manual para desencadenar el proceso de conmutación por error por sí mismo. El RTO con el uso de esta opción podría ser cualquier valor entre 10 minutos y un par de horas. Actualmente, el RTO es una función del número de dispositivos registrados en la instancia de IoT Hub en la que se realiza la conmutar por error. Puede esperar que el RTO de un centro que hospeda aproximadamente 100 000 dispositivos sea aproximadamente de 15 minutos. El tiempo total de las operaciones de tiempo de ejecución para conseguir la operatividad total una vez desencadenado este proceso se describe en la sección "Tiempo de recuperación".
La opción de conmutación por error manual siempre está disponible para su uso con independencia de si la región primaria está experimentando tiempos de inactividad o no. Por lo tanto, esta opción puede emplearse para realizar conmutaciones por error planeadas. Un ejemplo de uso de las conmutaciones por error planeadas consiste en realizar operaciones periódicas de conmutación por error. Sin embargo hay que tener la precaución de que una operación de conmutación por error planeada genera un tiempo de inactividad del centro durante el período definido por el RTO para esta opción, lo que genera también una pérdida de datos, según se define en la tabla del RPO anterior. Puede considerar la posibilidad de configurar una prueba de instancia de IoT Hub para ejecutar la opción de conmutación por error planeada periódicamente para incrementar la confiabilidad en su capacidad de ejecutar las soluciones de un extremo a otro cuando se produce un desastre real.
La conmutación por error manual está disponible sin costo adicional para los centros de IoT creados después del 18 de mayo de 2017.
Para obtener instrucciones paso a paso, consulte Tutorial: Realización de una conmutación por error manual de una instancia de IoT Hub
Conmutación por error manual y Event Hubs
El nombre compatible con Event Hubs y el punto de conexión de los eventos integrados en IoT Hub cambian tras la conmutación por error manual. Esto se debe a que el cliente de Event Hubs no ve los eventos de IoT Hub. Lo mismo sucede con otros clientes basados en la nube, como Functions y Azure Stream Analytics. Para recuperar el punto de conexión y el nombre, puede usar Azure Portal o el SDK de .NET.
Uso del portal
Para obtener más información sobre cómo usar el portal para recuperar el nombre y el punto de conexión compatibles con el centro Event Hub, consulte Leer desde el punto de conexión integrado.
Uso del SDK de .NET
Para usar la cadena de conexión de IoT Hub para volver a capturar el punto de conexión compatible con Event Hubs, use un ejemplo ubicado en https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs. En el ejemplo de código se usa la cadena de conexión para obtener el nuevo punto de conexión de Event Hubs y restablecer la conexión. Debe tener instalado Visual Studio.
Ejecución de simulacros de prueba
No se deben realizar simulacros de prueba los centros de IoT Hub que se usan en los entornos de producción.
No use la conmutación por error manual para migrar IoT Hub a otra región
La conmutación por error manual no debe usarse como un mecanismo para migrar de forma permanente su centro entre las regiones de Azure emparejadas geográficamente. Suponiendo que los dispositivos estaban lo más cerca posible de la región primaria del centro, la latencia de las operaciones que se realizan en el centro de IoT aumentará cuando el centro conmute por error a una región secundaria.
Conmutación por recuperación
Para realizar una conmutación por recuperación a la región primaria antigua, desencadene la acción de conmutación por error por segunda vez. Si se realizó la operación de conmutación por error original para recuperarse de una interrupción prolongada en la región primaria original, se recomienda realizar la conmutación por error del centro a la ubicación original una vez que se ha recuperado esa ubicación de la situación de interrupción.
Importante
- A los usuarios solo 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. Tendrá que esperar una hora entre estas operaciones.
Tiempo de recuperación
Aunque el nombre de dominio completo (y, por tanto, la cadena de conexión) de la instancia de IoT Hub sigue siendo el mismo tras la conmutación por error, la dirección IP subyacente cambia. El tiempo para que las operaciones de tiempo de ejecución ejecutadas en la instancia de IoT Hub estén totalmente operativas tras el proceso de conmutación por error se puede expresar mediante la siguiente función:
Tiempo de recuperación = RTO [10 m - 2 horas de conmutación por error manual | 2 a 26 horas de conmutación por error iniciada por Microsoft] + Retraso de propagación de DNS + Tiempo que emplea la aplicación cliente para actualizar la dirección IP de IoT Hub almacenada en caché.
Importante
Los SDK de IoT no almacenan en caché la dirección IP de IoT Hub. Se recomienda que el código de usuario que interactúa con los SDK no almacenen en caché la dirección IP de IoT Hub.
Deshabilitar la recuperación ante desastres
IoT Hub proporciona conmutación por error iniciada por Microsoft y conmutación por error manual mediante la replicación de datos en la región emparejada para cada centro de IoT. En algunas regiones, puede evitar la replicación de datos fuera de la región deshabilitando la recuperación ante desastres al crear un centro de IoT. Las siguientes regiones admiten esta característica:
- Sur de Brasil; región emparejada, Centro-sur de EE. UU.
- Sudeste Asiático (Singapur); región emparejada, Este de Asia (RAE de Hong Kong).
Para deshabilitar la recuperación ante desastres en las regiones admitidas, asegúrese de que la opción Recuperación ante desastres habilitada no está seleccionada al crear el centro de IoT:
También puede deshabilitar la recuperación ante desastres al crear un centro de IoT mediante una plantilla de ARM.
La capacidad de conmutación por error no estará disponible si deshabilita la recuperación ante desastres para un centro de IoT.
Solo puede deshabilitar la recuperación ante desastres para evitar la replicación de datos fuera de la región emparejada del Sur de Brasil o Sudeste Asiático al crear un centro de IoT. Si desea configurar el centro de IoT existente para deshabilitar la recuperación ante desastres, debe crear un centro de IoT con la recuperación ante desastres deshabilitada y migrar manualmente el centro de IoT existente. Para obtener instrucciones, consulte Cómo migrar un centro de IoT.
Lograr alta disponibilidad entre regiones
Si no se cumplen los objetivos de tiempo de actividad del negocio con el RTO que ofrecen la conmutación por error iniciada por Microsoft o la conmutación por error manual, debe considerar la opción de implementar un mecanismo de conmutación por error automático entre regiones por cada dispositivo. El objetivo de este artículo no es proporcionar una descripción completa de las topologías de implementación de soluciones de IoT. En este artículo se explica el modelo de implementación de conmutación por error regional para la alta disponibilidad y la recuperación ante desastres.
En un modelo de conmutación por error regional, el back-end de la solución se ejecuta principalmente en una ubicación de centro de datos. En otra ubicación de centro de datos se implementan un centro de IoT y un back-end secundarios. Si el centro de IoT de la región primaria sufre una interrupción o se interrumpe la conectividad de red del dispositivo a la región primaria, los dispositivos usan un punto de conexión de servicio secundario. Puede mejorar la disponibilidad de la solución mediante la implementación de un modelo de conmutación por error entre regiones en lugar de permanecer dentro de una única región.
A grandes rasgos, para implementar un modelo de conmutación por error regional con IoT Hub, necesitará seguir estos pasos:
Un centro de IoT secundario y lógica de enrutamiento de dispositivo: si se produce una interrupción del servicio en 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 el proceso de conmutación por error entre regiones. La mejor forma de comunicar el nuevo punto de conexión con los dispositivos, sin perder el control del proceso, es hacer que comprueben periódicamente un servicio de conserje para el punto de conexión activo actual. 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).
Nota
El servicio IoT Hub no es un tipo de punto de conexión admitido en Azure Traffic Manager. Se recomienda integrar el servicio de soporte propuesto con Azure Traffic Manager haciendo que implemente la API de sondeo de estado del punto de conexión.
Replicación del registro de identidad: para que el centro de IoT secundario pueda usarse, debe contener todas las identidades de dispositivo que se pueden conectar a la solución. La solución debe conservar copias de seguridad de replicación geográfica de las identidades de dispositivo y cargarlas en el Centro de IoT secundario antes de cambiar el punto de conexión activo de 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 la Guía para desarrolladores de IoT Hub: Registro de identidades.
Lógica de combinación: cuando la región primaria vuelve a estar disponible, todos los estados y datos que se crearon en el sitio secundario deben volver a migrarse 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, debe usar las operaciones de idempotente. Estas 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 aplicación debe diseñarse para que tolere posibles incoherencias o un estado ligeramente desactualizado. Esta situación se puede producir debido al tiempo adicional que tarda el sistema en repararse según los objetivos de punto de recuperación (RPO).
Elección de la opción correcta de alta disponibilidad/recuperación ante desastres
A continuación le mostramos un resumen de las opciones de alta disponibilidad y recuperación ante desastres presentadas en este artículo, que puede utilizarse como un marco de referencia para elegir la opción correcta para su solución.
| Opción de alta disponibilidad/recuperación ante desastres | RTO | RPO | ¿Requiere intervención manual? | Complejidad de la implementación | Impacto sobre los costos |
|---|---|---|---|---|---|
| Conmutación por error iniciada por Microsoft | 2 - 26 horas | Consulte la tabla de RPO anterior. | No | None | None |
| Conmutación por error manual | 10 m - 2 horas | Consulte la tabla de RPO anterior. | Sí | Muy baja. Solo necesita desencadenar esta operación desde el portal. | None |
| Alta disponibilidad entre regiones | < 1 min | Depende de la frecuencia de replicación de la solución de alta disponibilidad personalizada | No | Alto | > 1 x el costo de 1 centro de IoT |