Compartir a través de

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

  • Artículo

La gran variedad de sistemas y dispositivos 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 puedan reutilizar como funcionalidades compartidas. Debido a la variedad de dispositivos y sistemas de la tienda, las cargas de trabajo modulares están configuradas para admitir diferentes protocolos, controladores y formatos de datos. A veces, incluso varias instancias de una carga de trabajo se ejecutan 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 administración de la configuración es cada vez más importante para el escalado horizontal de las soluciones perimetrales.

Solución

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

  • Hay varios puntos de configuración que se pueden agrupar en distintas capas, como el código fuente del software, la canalización de CI/CD, el inquilino de la nube y la ubicación perimetral: Diagrama de las capas que caracterizan las configuraciones de las cargas de trabajo: código fuente del software, canalizaciones de C I / C D, inquilino de la nube y ubicación perimetral.
  • Distintas personas pueden actualizar las distintas capas.
  • Independientemente de cómo se actualicen las configuraciones, es necesario realizar un seguimiento y una auditoría cuidadosos.
  • Para la continuidad empresarial, es necesario que se pueda acceder a las configuraciones sin conexión en el perímetro.
  • También es necesario que haya una vista global de las configuraciones que están disponibles en la nube.

Problemas y consideraciones

Tenga en cuenta los puntos siguientes 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 respecto a:
    • La autenticación de usuario, ya que se basa en un servicio en la nube, como el identificador de Microsoft Entra.
    • La 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 las jerarquías de dispositivos en Azure IoT Edge.
  • Si la configuración en tiempo de ejecución se desacopla de las versiones de software, los cambios de configuración se deben controlar por separado. Para ofrecer características de historial y reversión, debe almacenar las configuraciones anteriores en un almacén de datos en la nube.
  • Un error en una configuración, como un componente de conectividad configurado para un punto de conexión inexistente, puede interrumpir la carga de trabajo. Por lo tanto, es importante tratar los cambios de configuración igual que se tratan otros eventos del ciclo de vida de implementación en la solución de observabilidad, para que los paneles de observabilidad puedan ayudar a correlacionar los errores del sistema con los cambios de configuración. Para más información sobre la observabilidad, consulte Guía de supervisión de 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 ser capaces de 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 las cargas de trabajo fuera del ciclo de versiones de software.
  • Distintas personas deben poder leer y actualizar las configuraciones.
  • Las configuraciones deben estar disponibles incluso si no hay conexión a la nube.

Cargas de trabajo de ejemplo:

  • Soluciones que se conectan a los recursos de la tienda para la ingesta de datos (por ejemplo, OPC Publisher) y para comando y control
  • Cargas de trabajo de aprendizaje automático para mantenimiento predictivo
  • Cargas de trabajo de aprendizaje automático que inspeccionan en tiempo real la calidad de la línea de fabricación

Ejemplos

La solución para configurar las 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.

Variante del controlador de configuración externo

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

Esta variante tiene un controlador de configuración que es externo a la carga de trabajo. El rol del componente del controlador de configuración en la nube es insertar las ediciones del almacén de datos en la nube en la carga de trabajo mediante el controlador de configuración perimetral. El perímetro también contiene un almacén de datos para que el sistema funcione incluso cuando está desconectado de la nube.

Con IoT Edge, el controlador de configuración perimetral se puede implementar como un 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 mediante la fragmentación de las cargas más grandes en métodos directos.

Las ventajas de esta variante 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 es editable, por ejemplo, cuando se usa un módulo del 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 con el 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.

Variante del proveedor de configuración interno

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

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 variante, las cargas de trabajo tienen identificadores únicos para que el mismo código fuente que se ejecuta 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, por ejemplo, el inquilino. En el caso de 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 juntos forman un identificador único que funciona como una clave en los almacenes de datos.

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

Las ventajas de esta variante 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 IoT 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 cargas 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 mediante las propiedades notificadas que se ha aplicado una configuración, el servicio de estado de configuración anota el evento en la instancia de 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 se cambian las propiedades deseadas del módulo perimetral en el centro de IoT en el que reside el dispositivo. A continuación, IoT Hub transmite la configuración al dispositivo perimetral. Se espera que el módulo perimetral aplique la configuración y que informe sobre el estado de la configuración mediante el módulo gemelo. 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 ambas implementaciones, la configuración se transmite en las propiedades deseadas del módulo gemelo o, en caso de que sea necesario transmitir configuraciones grandes, las propiedades deseadas del módulo gemelo contienen una dirección URL a Azure Blob Storage o a otro servicio que se pueda usar 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 aplicó correctamente y qué configuración se ha aplicado 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