Padrão de configuração da carga de trabalho de borda
A grande variedade de sistemas e dispositivos no chão de fábrica 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 à variedade de dispositivos e sistemas no chão de fábrica, as cargas de trabalho modulares são configuradas para suportar diferentes protocolos, drivers e formatos de dados. Às vezes, até mesmo várias instâncias de uma carga de trabalho são executadas com configurações diferentes no mesmo ponto de presença. Para algumas cargas de trabalho, as configurações são atualizadas mais de uma vez por dia. Portanto, o gerenciamento de configuração é cada vez mais importante para o dimensionamento de soluções de borda.
Solução
Há algumas características comuns do gerenciamento de configuração para cargas de trabalho de borda:
- Há 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:
- 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 borda.
- Também é necessário que haja uma visão global das configurações disponíveis na nuvem.
Problemas e considerações
Na altura de decidir como implementar este padrão, considere os seguintes pontos:
- 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 em uma configuração, como um componente de conectividade configurado para um ponto de extremidade inexistente, pode interromper a carga de trabalho. 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 resiliência, o armazenamento de dados de borda deve atuar como um cache offline. Isso tem precedência sobre as considerações de latência.
Quando utilizar 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
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 de borda pode ser implementado como um módulo, e as configurações podem ser aplicadas com gêmeos de módulo. O módulo twin tem um limite de tamanho; se a configuração exceder o limite, a solução poderá ser estendida com o Armazenamento de Blobs do Azure ou fragmentando cargas úteis maiores em 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. Esse recurso é um requisito se o código-fonte da carga de trabalho não for editável, por exemplo, ao usar 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
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. Esses valores juntos formam um identificador exclusivo que funciona como uma chave nos armazenamentos de dados.
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
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 do módulo do Hub IoT do Azure propaga alterações de configuração e informações sobre a configuração aplicada atualmente usando as propriedades desejadas e relatadas do módulo gêmeo. 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 qualquer implementação, a configuração é transmitida nas propriedades desejadas do gêmeo do módulo ou, caso grandes configurações precisem ser transmitidas, as propriedades desejadas do gêmeo do módulo contêm uma URL para o Armazenamento de Blobs do Azure ou para outro serviço que pode ser usado para recuperar a configuração. Em seguida, o módulo sinaliza nas propriedades de gêmeos do módulo se a nova configuração foi aplicada com êxito e qual configuração é aplicada atualmente.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Heather Camm - Brasil | Gerente de Programa Sênior
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- Azure IoT Edge
- What is Azure IoT Edge? (O que é o Hub IoT Edge?)
- Hub IoT do Azure
- Conceitos de IoT e Hub IoT do Azure
- BD do Cosmos para o Azure
- Bem-vindo ao Azure Cosmos DB
- Armazenamento de Blobs do Azure
- Introdução ao armazenamento de blobs do Azure