Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A ampla gama 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 criação de soluções de software que podem ser reutilizados como recursos compartilhados. Devido à ampla gama de dispositivos e sistemas no chão de fábrica, as cargas de trabalho modulares são configuradas para dar suporte a 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 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 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 localização de borda:
- As várias camadas podem ser atualizadas por pessoas diferentes.
- Independentemente de como as configurações são atualizadas, elas precisam ser controladas e auditadas com cuidado.
- 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 exibiçã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 estiver conectada à nuvem aumenta significativamente a complexidade do gerenciamento de configuração. É possível replicar alterações na nuvem, mas há desafios com:
- Autenticação do usuário, pois 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 exigem intervenção manual.
- O ambiente de borda poderá 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 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 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 à medida que você trata outros eventos de ciclo de vida de 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 a observabilidade, consulte o guia de monitoramento de nuvem: Observabilidade.
- Entenda as funções que os armazenamentos de dados de nuvem e de borda desempenham na continuidade dos negócios. Se o armazenamento de dados de 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 agir como um cache offline. Isso tem precedência sobre 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 lançamento de software.
- Pessoas diferentes precisam ser capazes de ler e atualizar as configurações.
- As configurações precisam estar disponíveis mesmo que não haja nenhuma conexão com a nuvem.
Cargas de trabalho de exemplo:
- 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 machine learning para manutenção preditiva
- Cargas de trabalho de machine learning 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 externo
Essa variação tem um controlador de configuração externo à carga de trabalho. A função do componente controlador de configuração na nuvem é transferir edições do banco de dados na 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 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 agrupando cargas 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, como quando você 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 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 interna do provedor de configuração
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, consulte Implementar um provedor de configuração personalizado no .NET. Esse exemplo usa C#, mas outros idiomas podem ser usados.
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 do IoT Edge e identificador de 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 configurações entre 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:
- 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 na implementação da carga de trabalho.
Soluções baseadas no 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 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 atualmente aplicada 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 do usuário para gerenciar configurações, um sistema de build 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 observa 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 em que o dispositivo reside. Em seguida, a configuração é transmitida por meio do Hub IoT para o dispositivo de borda. Espera-se que o módulo de borda aplique a configuração e informe o estado da configuração por meio do módulo gêmeo. 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 externo ou o provedor de configuração interno. Em ambos os cenários, o controlador transmite a configuração nas propriedades desejadas do módulo gêmeo. Para configurações grandes, as propriedades desejadas do módulo gêmeo contêm uma URL para o Armazenamento de Blobs do Azure ou outro serviço para recuperar a configuração. Em seguida, o módulo sinaliza nas propriedades relatadas do módulo gêmeo se a nova configuração foi aplicada com sucesso e qual configuração está aplicada no momento.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Heather Camm | Gerenciador de Programas Sênior
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- do Azure IoT Edge
- O que é o Azure IoT Edge?
- Hub IoT do Azure
- Conceitos de IoT e 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