Agente MQTT local interno das Operações do Azure IoT
Importante
Esta página inclui instruções para gerenciar componentes do serviço Operações do Azure IoT usando manifestos de implantação do Kubernetes, que estão em versão prévia. Esse recurso é fornecido com várias limitações, e não deve ser usado para cargas de trabalho de produção.
Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.
As Operações do Azure IoT apresentam um agente MQTT de nível empresarial e está em conformidade com os padrões. O agente MQTT é escalonável, altamente disponível e nativo do Kubernetes. Ele fornece o plano de mensagens para operações de IoT, habilita a comunicação bidirecional de borda/nuvem e alimenta aplicativos orientados a eventos na borda.
Conformidade do MQTT
O MQTT surgiu como a linguagem comum usada entre protocolos no espaço IoT. O design simples do MQTT permite que um único agente atenda a dezenas de milhares de clientes simultaneamente, com criação e gerenciamento de tópicos de publicação e assinatura leves. Muitos dispositivos IoT oferecem suporte ao MQTT nativamente, sem configuração. Os gateways de tradução downstream racionalizam a longa cauda de protocolos IoT em MQTT.
O Agente MQTT sustenta a camada de mensagens em Operações do IoT e dá suporte ao MQTT v3.1.1 e ao MQTT v5. Para obter mais informações sobre os recursos do MQTT com suporte, confira Suporte a recursos do MQTT no agente MQTT.
Arquitetura
O agente MQTT tem duas camadas principais:
- Camada de front-end sem monitoração de estado
- Camada de back-end com estado e compartilhada
A camada de front-end manipula as conexões e solicitações do cliente e as roteia para o back-end. A camada de back-end particiona dados por diferentes chaves, como um ID de cliente para sessões de cliente e um nome de tópico para mensagens de tópico. Ele usa a replicação de cadeia para replicar dados em cada partição.
Os objetivos da arquitetura são:
- Tolerância a falhas e isolamento: A publicação de mensagens continua se os pods de back-end falharem e evita que as falhas se propaguem para o restante do sistema.
- Recuperação de falhas: recuperação automática de falhas sem intervenção do operador.
- Sem perda de mensagens: Entrega de mensagens se pelo menos um pod de front-end e um pod de back-end em uma partição estiverem em execução.
- Escalabilidade elástica: Escalabilidade horizontal da taxa de transferência de publicação e assinatura para dar suporte a implantações de borda e nuvem.
- Desempenho consistente em escala: limite a sobrecarga de latência de mensagens devido à replicação em cadeia.
- Simplicidade operacional: Dependência mínima de componentes externos para simplificar a manutenção e a complexidade.
Configuração
Para configuração, o agente MQTT é composto por vários recursos personalizados do Kubernetes que definem diferentes aspectos do comportamento e da funcionalidade do agente:
- O recurso principal é Broker, que define as configurações globais, como cardinalidade, perfil de uso de memória e configurações de diagnóstico.
- Um recurso Broker pode ter até três BrokerListeners, cada um dos quais escuta as conexões MQTT recebidas no tipo de serviço especificado (
NodePort,LoadBalancerouClusterIP). Cada recurso BrokerListener pode ter várias portas. - Cada porta dentro de um recurso BrokerListener pode ser associada a um recurso BrokerAuthentication e a um recurso BrokerAuthorization. Essas políticas de autenticação e autorização determinam quais clientes podem se conectar à porta e quais ações eles podem executar no agente.
O relacionamento entre Broker e BrokerListener é um para muitos. O relacionamento entre BrokerListener e BrokerAuthentication/BrokerAuthorization é muitos para muitos. O diagrama de relacionamento de entidades para esses recursos é:
Por padrão, as Operações de IoT implantam um agente padrão, um BrokerListener padrão e uma BrokerAuthentication padrão. Todos esses recursos são nomeados como padrão. Juntos, esses recursos fornecem uma configuração básica de agente MQTT necessária para que as Operações de IoT funcionem. A configuração padrão é:
Importante
Para evitar interrupções não intencionais na comunicação entre os componentes internos das Operações de IoT, recomendamos que você não modifique nenhuma configuração padrão.
Para personalizar a implantação do agente MQTT, adicione novos recursos como BrokerListeners, BrokerAuthentication e BrokerAuthorization ao Agente padrão.
O recurso Broker em si é imutável e não pode ser modificado após a implantação, mas só precisa de personalização em cenários avançados. Para saber mais sobre como personalizar o recurso do Agente, consulte Personalizar o Agente padrão.
Em uma implantação completa, você pode ter vários BrokerListeners, cada um com várias portas, e cada porta pode ter recursos diferentes de BrokerAuthentication e BrokerAuthorization associados a ela.
Por exemplo, a partir da configuração padrão, você adiciona:
- Um BrokerListener LoadBalancer chamado example-lb-listener, com as duas portas 1883 e 8883.
- Um BrokerListener NodePort chamado example-nodeport-listener, com a porta única 1884 (
nodePort31884). - Um recurso BrokerAuthentication chamado example-authn, com um método de autenticação personalizado.
- Um recurso BrokerAuthorization chamado example-authz, com suas configurações de autorização personalizadas.
Em seguida, se você configurar todas as novas portas usando os mesmos recursos BrokerAuthentication e BrokerAuthorization, a configuração será semelhante a:
Dessa forma, você mantém a configuração padrão intacta e adiciona novos recursos para personalizar a implantação do agente MQTT às suas necessidades.
Recurso do Agente Padrão
Cada implantação das Operações de IoT pode ter apenas um Agente, que deve ser nomeado default. O recurso de Agente padrão é necessário para as Operações de IoT funcionarem. Ele é imutável e não pode ser modificado após a implantação.
Cuidado
Não exclua o recurso do Agente padrão. Isso interrompe a comunicação entre os componentes internos das Operações de IoT e a implantação para de funcionar.
Personalizar o Agente padrão
A personalização do recurso do Agente padrão não é necessária para a maioria das configurações. As configurações que exigem personalização incluem:
- Cardinalidade: determina a capacidade do agente de lidar com mais conexões e mensagens e aumenta a alta disponibilidade se houver falhas de pod ou nó.
- Perfil de memória: define o uso máximo de memória do agente e como lidar com o uso de memória à medida que o agente aumenta.
- Buffer de mensagens com suporte em disco: configuração para armazenar mensagens em buffer no disco à medida que a RAM é preenchida.
- Configurações de diagnóstico: configuração para configurações de diagnóstico, como nível de log e ponto de extremidade de métricas.
- Opções avançadas do cliente MQTT: configuração para opções avançadas do cliente MQTT, como expiração da sessão, expiração de mensagem e configurações de keep-alive.
- Criptografia de tráfego interno: configuração para criptografar o tráfego interno entre os pods de front-end e back-end do agente.
Você pode personalizar o agente padrão apenas durante a implantação inicial, usando a CLI do Azure ou o portal do Azure. Uma nova implantação é necessária se você precisar de outras definições da configuração do Agente.
Para personalizar o Agente padrão durante a implantação:
Quando você seguir o painel para implantar a IoT Operations, na seção Configuração, procure em Configuração do agente MQTT. Aqui, você pode personalizar as configurações de perfil de cardinalidade e memória. Para configurar outras configurações, incluindo buffer de mensagens em disco e opções avançadas de cliente MQTT, use a CLI do Azure.
Exibir configurações padrão do Agente
Para exibir as configurações do Agente padrão:
- No portal do Azure, navegue até a instância de Operações de IoT.
- Em Componentes, selecione Agente MQTT.
- Em Detalhes do Agente, selecione Modo de exibição JSON.