Padrão de configuração de carga de trabalho de borda
A grande variedade de sistemas e dispositivos na área de produção pode dificultar a configuração da carga de trabalho. Este artigo fornece abordagens para solucioná-la.
Contexto e problema
As empresas fabris, como parte de sua jornada de transformação digital, concentram-se cada vez mais na criação de soluções de software que podem ser reutilizadas como funcionalidades compartilhadas. Devido à variedade de dispositivos e sistemas nas áreas de produção, as cargas de trabalho modulares são configuradas para dar suporte a 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 borda. 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 a expansão das soluções de borda.
Solução
Há algumas características comuns de 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 localização de borda:
- As diversas camadas podem ser atualizadas por pessoas diferentes.
- Independentemente de como as configurações são atualizadas, elas precisam ser rastreadas e auditadas cuidadosamente.
- 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
Considere os seguintes pontos ao decidir como implementar esse padrão:
- Permitir edições quando a borda não está conectada à nuvem aumenta bastante a complexidade do gerenciamento de configuração. É possível replicar as alterações na nuvem, mas há desafios com:
- A autenticação de usuário, pois ela se baseia em um serviço de nuvem como o Microsoft Entra ID.
- A resolução de conflitos após a reconexão, se as cargas de trabalho receberem configurações inesperadas que exigem intervenção manual.
- O ambiente de borda poderá ter restrições relacionadas à rede se a topologia estiver em conformidade com os requisitos da ISA-95. Você pode superar essas restrições selecionando uma tecnologia que oferece 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 manipuladas separadamente. Para oferecer recursos de histórico e de reversão, você precisa armazenar configurações passadas 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 à medida que você trata outros eventos de ciclo de vida da implantação na solução de observabilidade, para que os painéis de observabilidade possam ajudar a correlacionar os erros do sistema às alterações de configuração. Para obter mais informações sobre observabilidade, confira Guia de monitoramento de nuvem: observabilidade.
- Entenda as funções que os armazenamentos de nuvem e de borda desempenham na continuidade dos negócios. Se o armazenamento de dados em nuvem for a única fonte de verdade, as cargas de trabalho de borda serão capazes de restaurar os estados pretendidos usando processos automatizados.
- Para resiliência, o armazenamento de dados de borda deve agir como um cache offline. Isso tem precedência sobre as considerações de latência.
Quando usar esse padrão
Use esse padrão quando:
- Há um requisito para configurar cargas de trabalho fora do ciclo de versão de software.
- Pessoas diferentes precisam ser capazes de ler e atualizar configurações.
- As configurações precisarão estar disponíveis mesmo se não houver conexão com a nuvem.
Exemplo de cargas de trabalho:
- Soluções que se conectam a ativos na área de produção para ingestão de dados – OPC Publisher, por exemplo – e comando e controle
- Cargas de trabalho de machine learning para manutenção preditiva
- Cargas de trabalho de machine learning que fazem inspeções em tempo real para 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 externa ou em um provedor de configuração interna.
Variação do controlador de configuração externa
Essa variação tem um controlador de configuração externa à carga de trabalho. A função do componente do controlador de configuração de nuvem é enviar por push as edições do armazenamento de dados de 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 os módulos gêmeos. O módulo gêmeo 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 com o agrupamento de conteúdos maiores em métodos diretos.
Os benefícios dessa variação são:
- A própria carga de trabalho não precisa estar ciente do sistema de configuração. Essa funcionalidade será um requisito se o código-fonte da carga de trabalho não for editável, por exemplo, ao usar um módulo do Marketplace do Azure IoT Edge.
- É possível alterar a configuração de várias cargas de trabalho ao mesmo tempo, coordenando as alterações por meio do controlador de configuração de 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 por push a configuração para a carga de trabalho.
Variação do provedor de configuração interna
Na variação do provedor de configuração interna, a carga de trabalho extrai as configurações de um provedor de configuração. Para obter um exemplo de implementação, confira 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 executado em ambientes distintos possa ter configurações diferentes. Uma forma 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, esse requisito é comum para manter as configurações entre as atualizações de software. Se a versão for uma parte do identificador, a versão antiga da configuração deverá ser migrada com uma implementação adicional.
Os benefícios dessa variação são:
- Com exceção dos armazenamentos de dados, a solução não exige componentes, reduzindo a complexidade.
- A lógica de migração de versões antigas incompatíveis pode ser tratada na 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 agindo como o controlador de configuração de nuvem. A funcionalidade do módulo gêmeo do Hub IoT do Azure propaga as alterações de configuração e as informações sobre a configuração aplicada no momento usando o módulo gêmeo desejado e as propriedades relatadas. O serviço de gerenciamento de configuração atua como a origem das configurações. Ele também pode ser uma interface do 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 o histórico de configuração.
Depois que um dispositivo de borda indica por meio das 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 no qual o dispositivo reside. Em seguida, a configuração é transmitida pelo Hub IoT para o dispositivo de borda. O módulo de borda deve aplicar a configuração e o relatório por meio do módulo gêmeo e do estado de configuração. Em seguida, o serviço de estado de configuração ouve os eventos de alteração gêmeos e, ao detectar 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 externa ou o provedor de configuração interna. Em qualquer implementação, a configuração é transmitida nas propriedades desejadas do módulo gêmeo ou, caso as configurações grandes precisem ser transmitidas, as propriedades desejadas do módulo gêmeo contêm uma URL do Armazenamento de Blobs do Azure ou de outro serviço que pode ser usado para recuperar a configuração. Em seguida, o módulo sinaliza as propriedades relatadas do módulo gêmeo se a nova configuração foi aplicada com sucesso e qual configuração está aplicada atualmente.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Heather Camm | Gerente de Programa Sênior
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- Azure IoT Edge
- O que é o Azure IoT Edge?
- Hub IoT do Azure
- Conceitos de Hub IoT do Azure
- Azure Cosmos DB
- Bem-vindo(a) ao Azure Cosmos DB
- Armazenamento de Blobs do Azure
- Introdução ao Armazenamento de Blobs do Azure