Agente MQTT local interno do Azure IoT Operations
Importante
Esta página inclui instruções para gerenciar componentes do Azure IoT Operations usando manifestos de implantação do Kubernetes, que está em visualização. Esse recurso é fornecido com várias limitações e não deve ser usado para cargas de trabalho de produção.
Veja Termos de Utilização Complementares da Pré-visualizações do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão na versão beta, na pré-visualização ou que ainda não foram lançadas para disponibilidade geral.
O Azure IoT Operations apresenta um agente MQTT de nível empresarial e compatível com padrões. O broker MQTT é escalável, altamente disponível e nativo do Kubernetes. Ele fornece o plano de mensagens para operações de IoT, permite comunicação bidirecional de borda/nuvem e alimenta aplicativos orientados a eventos na borda.
Conformidade com MQTT
O MQTT surgiu como a linguagem comum usada entre os protocolos no espaço IoT. O design simples do MQTT permite que um único corretor atenda dezenas de milhares de clientes simultaneamente, com criação e gerenciamento de tópicos leves de publicação-assinatura. Muitos dispositivos IoT suportam MQTT nativamente pronto para uso. Os gateways de tradução downstream racionalizam a cauda longa dos protocolos IoT em MQTT.
O broker MQTT sustenta a camada de mensagens em IoT Operations e suporta MQTT v3.1.1 e MQTT v5. Para obter mais informações sobre os recursos MQTT suportados, consulte Suporte a recursos MQTT no broker MQTT.
Arquitetura
O broker MQTT tem duas camadas principais:
- Camada de front-end sem estado
- Camada de back-end com monitoração de estado e fragmentada
A camada de front-end lida com conexões e solicitações de clientes e as encaminha para o back-end. A camada de back-end particiona dados por chaves diferentes, como um ID de cliente para sessões de cliente e um nome de tópico para mensagens de tópico. Ele usa replicação em cadeia para replicar dados dentro de 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 impede que as falhas se propaguem para o resto 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 frontend e um pod backend em uma partição estiver em execução.
- Escalonamento elástico: dimensionamento 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 broker MQTT é composto por vários recursos personalizados do Kubernetes que definem diferentes aspetos do comportamento e da funcionalidade do broker:
- O principal recurso é o 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 conexões MQTT de entrada no tipo de serviço especificado (
NodePort,LoadBalancer, ouClusterIP). 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 broker.
A relação entre Broker e BrokerListener é um-para-muitos. A relação entre BrokerListener e BrokerAuthentication/BrokerAuthorization é muitos-para-muitos. O diagrama de relacionamento de entidade para esses recursos é:
Por padrão, as Operações IoT implantam um Broker padrão, um BrokerListener padrão e um BrokerAuthentication padrão. Todos esses recursos são nomeados padrão. Juntos, esses recursos fornecem uma configuração básica do broker MQTT necessária para que as operações de IoT funcionem. A configuração padrão é:
Importante
Para evitar interrupções não intencionais com a comunicação entre componentes internos do IoT Operations, recomendamos que você não modifique nenhuma configuração padrão.
Para personalizar a implantação do broker MQTT, adicione novos recursos como BrokerListeners, BrokerAuthentication e BrokerAuthorization ao Broker padrão.
O recurso do 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 Broker, consulte Personalizar o Broker padrão.
Em uma implantação completa, você pode ter vários BrokerListeners, cada um com várias portas, e cada porta pode ter diferentes recursos BrokerAuthentication e BrokerAuthorization associados a ela.
Por exemplo, a partir da configuração padrão, você adiciona:
- Um LoadBalancer BrokerListener chamado example-lb-listener, com as duas portas 1883 e 8883.
- Um NodePort BrokerListener 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 terá a seguinte aparência:
Dessa forma, você mantém a configuração padrão intacta e adiciona novos recursos para personalizar a implantação do broker MQTT de acordo com suas necessidades.
Recurso Broker padrão
Cada implantação de Operações IoT pode ter apenas um Broker e deve ser nomeada padrão. O recurso Broker padrão é necessário para que as operações IoT funcionem. É imutável e não pode ser modificado após a implantação.
Atenção
Não exclua o recurso padrão do Broker. Isso interrompe a comunicação entre os componentes internos das Operações IoT e a implantação para de funcionar.
Personalizar o Broker padrão
A personalização do recurso padrão do Broker não é necessária para a maioria das configurações. As configurações que exigem personalização incluem:
- Cardinalidade: Determina a capacidade do broker de lidar com mais conexões e mensagens e aumenta a alta disponibilidade se houver falhas de pod ou node.
- Perfil de memória: define o uso máximo de memória do broker e como lidar com o uso de memória à medida que o broker aumenta a escala.
- Buffer de mensagens com backup de 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 da mensagem e configurações de keep-alive.
- Criptografia de tráfego interno: Configuração para criptografar o tráfego interno entre os pods frontend e backend do broker.
Você pode personalizar o agente padrão somente durante o tempo de implantação inicial, usando a CLI do Azure ou o portal do Azure. Uma nova implantação será necessária se você precisar de definições de configuração diferentes do Broker.
Para personalizar o Broker padrão durante a implantação:
Ao seguir o guia para implantar operações IoT, na seção Configuração , procure em Configuração do agente MQTT. Aqui, você pode personalizar as configurações de cardinalidade e perfil de memória. Para definir outras configurações, incluindo buffer de mensagens com backup de disco e opções avançadas de cliente MQTT, use a CLI do Azure.
Exibir configurações padrão do Broker
Para exibir as configurações do Broker padrão:
- No portal do Azure, vá para sua instância de Operações IoT.
- Em Componentes, selecione MQTT Broker.
- Em Detalhes do broker, selecione Visualização JSON.