Partilhar via

Padrão de configuração da carga de trabalho periférica

A grande variedade de sistemas e dispositivos no chão de produção pode tornar a configuração da carga de trabalho um problema difícil. Este artigo fornece abordagens para resolvê-lo.

Contexto e problema

As empresas de manufatura, como parte de sua jornada de transformação digital, se concentram cada vez mais na construção de soluções de software que podem ser reutilizadas como recursos compartilhados. Devido à grande variedade de dispositivos e sistemas disponíveis na fábrica, as cargas de trabalho modulares estão configuradas para suportar diferentes protocolos, drivers e formatos de dados. Às vezes, até várias instâncias de uma carga de trabalho são executadas com configurações diferentes no mesmo local de edge. Para algumas cargas de trabalho, as configurações são atualizadas mais de uma vez por dia. Portanto, a gestão de configuração é cada vez mais importante para a escalabilidade das soluções de borda.

Solução

Há algumas características comuns do gerenciamento de configuração para cargas de trabalho de borda:

  • Existem vários pontos de configuração que podem ser agrupados em camadas distintas, como fonte de software, pipeline de CI/CD, locatário de nuvem e ponto de presença: Diagrama das camadas que caracterizam as configurações de carga de trabalho: fonte de software, pipelines C I / C D, locatário de nuvem e ponto de presença.
  • As várias camadas podem ser atualizadas por diferentes pessoas.
  • Não importa como as configurações são atualizadas, elas precisam ser cuidadosamente rastreadas e auditadas.
  • Para a continuidade dos negócios, é necessário que as configurações possam ser acessadas offline na periferia.
  • Também é necessário que haja uma visão global das configurações disponíveis na nuvem.

Questões e considerações

Considere os seguintes pontos ao decidir como implementar esse padrão:

  • Permitir edições quando a borda não está conectada à nuvem aumenta significativamente a complexidade do gerenciamento de configuração. É possível replicar alterações para a nuvem, mas há desafios com:
    • Autenticação do usuário, porque depende de um serviço de nuvem como o Microsoft Entra ID.
    • Resolução de conflitos após a reconexão, se as cargas de trabalho receberem configurações inesperadas que exijam intervenção manual.
  • O ambiente de borda pode ter restrições relacionadas à rede se a topologia estiver em conformidade com os requisitos do ISA-95. Você pode superar essas restrições selecionando uma tecnologia que ofereça conectividade entre camadas, como hierarquias de dispositivo no Azure IoT Edge.
  • Se a configuração em tempo de execução for dissociada das versões de software, as alterações de configuração precisarão ser tratadas separadamente. Para oferecer recursos de histórico e reversão, você precisa armazenar configurações anteriores em um armazenamento de dados na nuvem.
  • Uma falha numa configuração, como um componente de conectividade configurado para um ponto final inexistente, pode interromper a operação. Portanto, é importante tratar as alterações de configuração como você trata outros eventos do ciclo de vida da implantação na solução de observabilidade, para que os painéis de observabilidade possam ajudar a correlacionar erros do sistema às alterações de configuração. Para obter mais informações sobre observabilidade, consulte Guia de monitoramento de nuvem: observabilidade.
  • Entenda as funções que a nuvem e os armazenamentos de dados de borda desempenham na continuidade dos negócios. Se o armazenamento de dados na nuvem for a única fonte de verdade, as cargas de trabalho de borda deverão ser capazes de restaurar os estados pretendidos usando processos automatizados.
  • Para garantir a resiliência, o armazenamento de dados na borda deve atuar como um cache offline. Isso tem precedência sobre as considerações de latência.

Quando usar este padrão

Utilize este padrão quando:

  • Há um requisito para configurar cargas de trabalho fora do ciclo de lançamento do software.
  • Pessoas diferentes precisam ser capazes de ler e atualizar configurações.
  • As configurações precisam estar disponíveis mesmo que não haja conexão com a nuvem.

Exemplos de cargas de trabalho:

  • Soluções que se conectam a ativos no chão de fábrica para ingestão de dados — OPC Publisher, por exemplo — e comando e controle
  • Cargas de trabalho de aprendizado de máquina para manutenção preditiva
  • Cargas de trabalho de aprendizado de máquina que inspecionam em tempo real a qualidade na linha de fabricação

Exemplos

A solução para configurar cargas de trabalho de borda durante o tempo de execução pode ser baseada em um controlador de configuração externo ou em um provedor de configuração interno.

Variação do controlador de configuração externa

Diagrama da arquitetura para a variação do controlador de configuração externo.

Essa variação tem um controlador de configuração externo à carga de trabalho. A função do componente do controlador de configuração de nuvem é enviar edições do armazenamento de dados em nuvem para a carga de trabalho por meio do controlador de configuração de borda. A borda também contém um armazenamento de dados para que o sistema funcione mesmo quando desconectado da nuvem.

Com o IoT Edge, o controlador de configuração periférica pode ser implementado como um módulo, e as configurações podem ser aplicadas com gémeos de módulo. O módulo gémeo tem um limite de tamanho; se a configuração exceder o limite, a solução pode ser estendida com Azure Blob Storage ou dividindo cargas úteis maiores sobre métodos diretos.

Os benefícios desta variação são:

  • A carga de trabalho em si não precisa estar ciente do sistema de configuração. Esta funcionalidade é um requisito se o código-fonte da carga de trabalho não for editável, como quando se usa um módulo do Azure IoT Edge Marketplace.
  • É possível alterar a configuração de várias cargas de trabalho ao mesmo tempo, coordenando as alterações através do controlador de configuração na nuvem.
  • A validação adicional pode ser implementada como parte do pipeline de push — por exemplo, para validar a existência de pontos de extremidade na borda antes de enviar a configuração para a carga de trabalho.

Variação do provedor de configuração interna

Diagrama da arquitetura para a variação do provedor de configuração interna.

Na variação do provedor de configuração interno, a carga de trabalho extrai configurações de um provedor de configuração. Para obter um exemplo de implementação, consulte Implementar um provedor de configuração personalizado no .NET. Esse exemplo usa C#, mas outras linguagens podem ser usadas.

Nessa variação, as cargas de trabalho têm identificadores exclusivos para que o mesmo código-fonte em execução em ambientes diferentes possa ter configurações diferentes. Uma maneira de construir um identificador é concatenar a relação hierárquica da carga de trabalho com um agrupamento de nível superior, como um locatário. Para o IoT Edge, pode ser uma combinação de grupo de recursos do Azure, nome do hub IoT, nome do dispositivo IoT Edge e identificador do módulo. Estes valores juntos formam um identificador único que funciona como chave nos datastores.

Embora a versão do módulo possa ser adicionada ao identificador exclusivo, é um requisito comum persistir as configurações nas atualizações de software. Se a versão fizer parte do identificador, a versão antiga da configuração deverá ser migrada para a frente com uma implementação adicional.

Os benefícios desta variação são:

  • Além dos armazenamentos de dados, a solução não requer componentes, reduzindo a complexidade.
  • A lógica de migração de versões antigas incompatíveis pode ser tratada dentro da implementação da carga de trabalho.

Soluções baseadas em IoT Edge

Diagrama da arquitetura para a variação baseada em I o T Edge.

O componente de nuvem da implementação de referência do IoT Edge consiste em um hub IoT atuando como o controlador de configuração de nuvem. A funcionalidade de gêmeo de módulo do Hub IoT do Azure propaga alterações de configuração e informações sobre a configuração atualmente aplicada através das propriedades desejadas e relatadas desse gêmeo de módulo. O serviço de gerenciamento de configuração atua como a origem das configurações. Ele também pode ser uma interface de usuário para gerenciar configurações, um sistema de compilação e outras ferramentas usadas para criar configurações de carga de trabalho.

Um banco de dados do Azure Cosmos DB armazena todas as configurações. Ele pode interagir com vários hubs IoT e fornece histórico de configuração.

Depois que um dispositivo de borda indica por meio de propriedades relatadas que uma configuração foi aplicada, o serviço de estado de configuração anota o evento na instância do banco de dados.

Quando uma nova configuração é criada no serviço de gerenciamento de configuração, ela é armazenada no Azure Cosmos DB e as propriedades desejadas do módulo de borda são alteradas no hub IoT onde o dispositivo reside. A configuração é então transmitida pelo Hub IoT para o dispositivo de borda. Espera-se que o módulo de borda aplique a configuração e informe através do módulo twin o estado da configuração. Em seguida, o serviço de estado de configuração escuta eventos de alteração gêmea e, ao detetar que um módulo relata uma alteração de estado de configuração, registra a alteração correspondente no banco de dados do Azure Cosmos DB.

O componente de borda pode usar o controlador de configuração externo ou o provedor de configuração interno. Em ambos os cenários, o controlador transmite a configuração no módulo twin das propriedades desejadas. Para configurações grandes, as propriedades do módulo gémeo desejadas contêm uma URL para Azure Blob Storage ou outro serviço para recuperar a configuração. Em seguida, o módulo sinaliza nas propriedades relatadas do gêmeo do módulo se a nova configuração foi aplicada com êxito e qual configuração está atualmente aplicada.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

  • Last updated on