Compartir a través de

Patrón de configuración de la carga de trabajo de Edge

La amplia gama de sistemas y dispositivos en el piso de la tienda puede hacer que la configuración de la carga de trabajo sea un problema difícil. En este artículo se proporcionan enfoques para resolverlo.

Contexto y problema

Las empresas de fabricación, como parte de su recorrido de transformación digital, se centran cada vez más en la creación de soluciones de software que se pueden reutilizar como funcionalidades compartidas. Debido a la amplia gama de dispositivos y sistemas en la planta de la tienda, las cargas de trabajo modulares están configuradas para admitir diferentes protocolos, controladores y formatos de datos. A veces incluso se ejecutan varias instancias de una carga de trabajo con configuraciones diferentes en la misma ubicación perimetral. Para algunas cargas de trabajo, las configuraciones se actualizan más de una vez al día. Por lo tanto, la gestión de configuraciones se vuelve cada vez más importante para la expansión de soluciones de borde.

Solución

Hay algunas características comunes de administración de configuración para cargas de trabajo perimetrales:

  • Hay varios puntos de configuración que se pueden agrupar en capas distintas, como el origen de software, la canalización de CI/CD, el inquilino en la nube y la ubicación perimetral: diagrama de las capas que caracterizan las configuraciones de carga de trabajo: origen de software, canalizaciones de C I /C D, inquilino de nube y ubicación perimetral.
  • Las diferentes personas pueden actualizar las distintas capas.
  • Independientemente de cómo se actualicen las configuraciones, se debe realizar un seguimiento cuidadoso y una auditoría.
  • Para la continuidad empresarial, es necesario que se pueda acceder a las configuraciones sin conexión en la periferia.
  • También es necesario que haya una vista global de las configuraciones disponibles en la nube.

Problemas y consideraciones

Tenga en cuenta los siguientes puntos al decidir cómo implementar este patrón:

  • Permitir modificaciones cuando el perímetro no está conectado a la nube aumenta significativamente la complejidad de la administración de la configuración. Es posible replicar los cambios en la nube, pero hay desafíos con los siguientes:
    • La autenticación de usuario, ya que se basa en un servicio en la nube, como el identificador de Microsoft Entra.
    • Resolución de conflictos después de la reconexión, si las cargas de trabajo reciben configuraciones inesperadas que requieren intervención manual.
  • El entorno perimetral puede tener restricciones relacionadas con la red si la topología cumple los requisitos de ISA-95. Para superar estas restricciones, seleccione una tecnología que ofrezca conectividad entre capas, como jerarquías de dispositivos en Azure IoT Edge.
  • Si la configuración en tiempo de ejecución se desacopla de las versiones de software, es necesario controlar los cambios de configuración por separado. Para ofrecer características de historial y reversión, debe almacenar configuraciones anteriores en un almacén de datos en la nube.
  • Un error en una configuración, como un componente de conectividad configurado en un punto de conexión inexistente, puede interrumpir la carga de trabajo. Por lo tanto, es importante tratar los cambios de configuración a medida que trata otros eventos de ciclo de vida de implementación en la solución de observabilidad, de modo que los paneles de observabilidad puedan ayudar a correlacionar los errores del sistema con los cambios de configuración. Para obtener más información sobre la observabilidad, consulte Guía de supervisión en la nube: Observabilidad.
  • Comprenda los roles que desempeñan los almacenes de datos perimetrales y en la nube en la continuidad empresarial. Si el almacén de datos en la nube es el único origen de verdad, las cargas de trabajo perimetrales deben poder restaurar los estados previstos mediante procesos automatizados.
  • Para lograr resistencia, el almacén de datos perimetral debe actuar como una caché sin conexión. Esto tiene prioridad sobre las consideraciones de latencia.

Cuándo usar este patrón

Use este patrón en los siguientes supuestos:

  • Hay un requisito para configurar cargas de trabajo fuera del ciclo de lanzamiento de software.
  • Es necesario que diferentes personas puedan leer y actualizar configuraciones.
  • Las configuraciones deben estar disponibles incluso si no hay ninguna conexión a la nube.

Cargas de trabajo de ejemplo:

  • Soluciones que se conectan a activos en la planta de producción para la ingesta de datos, como OPC Publisher, y comando y control.
  • Cargas de trabajo de aprendizaje automático para el mantenimiento predictivo
  • Cargas de trabajo de aprendizaje automático que inspeccionan en tiempo real la calidad en la línea de fabricación

Ejemplos

La solución para configurar cargas de trabajo perimetrales durante el tiempo de ejecución puede basarse en un controlador de configuración externo o en un proveedor de configuración interno.

Variación del controlador de configuración externo

Diagrama de la arquitectura para la variación del controlador de configuración externo.

Esta variación tiene un controlador de configuración externo a la carga de trabajo. El rol del componente del controlador de configuración en la nube es insertar modificaciones desde el almacén de datos en la nube a la carga de trabajo a través del controlador de configuración perimetral. El perímetro también contiene un almacén de datos para que el sistema funcione incluso cuando se desconecta de la nube.

Con IoT Edge, el controlador de configuración perimetral se puede implementar como módulo y las configuraciones se pueden aplicar con módulos gemelos. El módulo gemelo tiene un límite de tamaño; si la configuración supera el límite, la solución se puede ampliar con Azure Blob Storage o fragmentando cargas más grandes a través de métodos directos.

Las ventajas de esta variación son:

  • La propia carga de trabajo no tiene que ser consciente del sistema de configuración. Esta funcionalidad es un requisito si el código fuente de la carga de trabajo no se puede editar, como cuando se usa un módulo desde Marketplace de Azure IoT Edge.
  • Es posible cambiar la configuración de varias cargas de trabajo al mismo tiempo mediante la coordinación de los cambios a través del controlador de configuración en la nube.
  • Se puede implementar una validación adicional como parte de la canalización de inserción, por ejemplo, para validar la existencia de los puntos de conexión en el perímetro antes de insertar la configuración en la carga de trabajo.

Variación del proveedor de configuración interna

Diagrama de la arquitectura para la variación del proveedor de configuración interno.

En la variante del proveedor de configuración interno, la carga de trabajo extrae las configuraciones de un proveedor de configuración. Para obtener un ejemplo de implementación, consulte Implementación de un proveedor de configuración personalizado en .NET. En ese ejemplo se usa C#, pero se pueden usar otros lenguajes.

En esta variación, las cargas de trabajo tienen identificadores únicos para que el mismo código fuente que se ejecute en entornos diferentes pueda tener configuraciones diferentes. Una manera de construir un identificador es concatenar la relación jerárquica de la carga de trabajo con una agrupación de nivel superior, como un inquilino. Para IoT Edge, podría ser una combinación del grupo de recursos de Azure, el nombre del centro de IoT, el nombre del dispositivo IoT Edge y el identificador del módulo. Estos valores forman un identificador único que funciona como clave en los almacenes de datos.

Aunque la versión del módulo se puede agregar al identificador único, es un requisito común conservar las configuraciones entre las actualizaciones de software. Si la versión forma parte del identificador, la versión anterior de la configuración debe migrarse hacia delante con una implementación adicional.

Las ventajas de esta variación son:

  • Aparte de los almacenes de datos, la solución no requiere componentes, lo que reduce la complejidad.
  • La lógica de migración de versiones anteriores incompatibles se puede controlar dentro de la implementación de la carga de trabajo.

Soluciones basadas en IoT Edge

Diagrama de la arquitectura de la variación basada en I o T Edge.

El componente en la nube de la implementación de referencia de IoT Edge consta de un centro de IoT que actúa como controlador de configuración en la nube. La funcionalidad del módulo gemelo de Azure IoT Hub propaga los cambios de configuración y la información sobre la configuración aplicada actualmente mediante las propiedades deseadas y notificadas del módulo gemelo. El servicio de administración de configuración actúa como origen de las configuraciones. También puede ser una interfaz de usuario para administrar configuraciones, un sistema de compilación y otras herramientas que se usan para crear configuraciones de carga de trabajo.

Una base de datos de Azure Cosmos DB almacena todas las configuraciones. Puede interactuar con varios centros de IoT y proporciona el historial de configuración.

Después de que un dispositivo perimetral indique a través de las propiedades notificadas que se aplicó una configuración, el servicio de estado de configuración anota el evento en la instancia de la base de datos.

Cuando se crea una nueva configuración en el servicio de administración de configuración, se almacena en Azure Cosmos DB y las propiedades deseadas del módulo perimetral se cambian en el centro de IoT donde reside el dispositivo. Después, IoT Hub transmite la configuración al dispositivo perimetral. Se espera que el módulo perimetral aplique la configuración y informe a través del módulo gemelo el estado de la configuración. A continuación, el servicio de estado de configuración escucha los eventos de cambios en los gemelos y, al detectar que un módulo informa de un cambio de estado de configuración, registra el cambio correspondiente en la base de datos de Azure Cosmos DB.

El componente perimetral puede usar el controlador de configuración externo o el proveedor de configuración interno. En ambos escenarios, el controlador transmite la configuración en las propiedades deseadas del módulo gemelo. Para configuraciones grandes, las propiedades deseadas del módulo gemelo contienen una dirección URL a Azure Blob Storage u otro servicio para recuperar la configuración. A continuación, el módulo indica, en las propiedades notificadas del módulo gemelo, si la nueva configuración se ha aplicado correctamente y qué configuración está aplicada actualmente.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

  • Last updated on