Definir configurações do agente para alta disponibilidade, dimensionamento e uso de memória

Artigo
02/20/2025

O recurso Agente é o principal recurso que define as configurações gerais de um Agente MQTT. Também determina o número e o tipo de pods que executam a configuração do Agente, como front-ends e back-ends. Você também pode usar o recurso Agente para configurar seu perfil de memória. Mecanismos de self-healing estão integrados ao agente, permitindo que ele recupere-se automaticamente de falhas de componentes. Um exemplo é a falha de um nó em um cluster do Kubernetes configurado para alta disponibilidade.

Você pode dimensionar horizontalmente o agente MQTT adicionando mais réplicas de front-end e partições de back-end. As réplicas de front-end são responsáveis por aceitar conexões MQTT de clientes e encaminhá-las para as partições de back-end. As partições de back-end são responsáveis por armazenar e entregar mensagens aos clientes. Os pods de front-end distribuem o tráfego de mensagens entre os pods de back-end. O fator de redundância do back-end determina o número de cópias de dados para garantir resiliência contra falhas de nós no cluster.

Para uma lista das configurações disponíveis, confira a Referência de API do Agente.

Definir as configurações de dimensionamento

Importante

Essa configuração requer que você modifique o recurso do Agente. Ele é configurado somente na implantação inicial usando a CLI do Azure ou o portal do Azure. Uma nova implantação será necessária se forem necessárias alterações na configuração do Agente. Para saber mais, confira Personalizar o Agente padrão.

Para definir as configurações de escala do Agente MQTT, especifique os campos de cardinalidade na especificação do recurso Agente durante a implantação das Operações do Azure IoT.

Cardinalidade de implantação automática

Para determinar automaticamente a cardinalidade inicial durante a implantação, omita o campo de cardinalidade no recurso Broker.

Portal
CLI do Azure

Ainda não há suporte para cardinalidade automática ao implantar Operações de IoT por meio do portal do Azure. Você pode especificar manualmente o modo de implantação do cluster como nó único ouvários nós. Para saber mais, consulte Implantar Operações do Azure IoT.

Captura de tela que mostra onde selecionar a configuração de nó único ou vários nós no portal do Azure.

Prepare um arquivo de configuração do Agente no formato JSON, que inclui as propriedades desejadas do recurso microsoft.iotoperations/instances/brokers do Azure Resource Manager. Lembre-se de omitir o cardinality campo. Por exemplo, defina apenas o perfil de memória:

{
  "memoryProfile": "<MEMORY_PROFILE>"
}

Em seguida, implante as Operações de IoT usando o comando az iot ops create com o sinalizador --broker-config-file, como o seguinte comando (os outros parâmetros foram omitidos para brevidade):

az iot ops create ... --broker-config-file <FILE>.json

Para saber mais, consulte o Suporte da CLI do Azure para a configuração avançada do agente MQTT.

O operador do agente MQTT implanta automaticamente o número apropriado de pods com base no número de nós disponíveis no momento da implantação. Essa funcionalidade é útil para cenários de não produção em que você não precisa de alta disponibilidade ou escala.

Não é funcionalidade de escala automática. O operador não dimensiona automaticamente o número de pods com base na carga. O operador determina o número inicial de pods apenas com base no hardware do cluster. Conforme observado anteriormente, a cardinalidade é definida apenas no momento da implantação inicial. Uma nova implantação será necessária se as configurações de cardinalidade precisarem ser alteradas.

Configurar a cardinalidade diretamente

Para definir as configurações de cardinalidade diretamente, especifique cada um dos campos de cardinalidade.

Portal
CLI do Azure

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 especificar o número de réplicas de front-end, partições de back-end e trabalhos de back-end.

Captura de tela mostrando a configuração direta da cardinalidade do agente no portal do Azure.

Ao implantar as Operações de IoT usando o comando az iot ops create, use os parâmetros --broker-frontend-replicas, --broker-frontend-workers, --broker-backend-part, --broker-backend-rf e --broker-backend-workers para especificar as configurações de cardinalidade.

Por exemplo, para especificar uma réplica de front-end, um trabalho de front-end, uma partição de back-end, duas réplicas de back-end por partição e um trabalho de back-end por réplica, consulte o seguinte comando (outros parâmetros foram omitidos para brevidade):

az iot ops create ... --broker-frontend-replicas 1 --broker-frontend-workers 1  --broker-backend-part 1  --broker-backend-workers 1 --broker-backend-rf 2

Como alternativa, use o sinalizador --broker-config-file para especificar um arquivo JSON que inclua as configurações de cardinalidade. Aqui está arquivo JSON de exemplo para as mesmas configurações:

{
  "cardinality": {
    "frontend": {
      "replicas": 1,
      "workers": 1
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

az iot ops create ... --broker-config-file <FILE>.json

Entenda a cardinalidade

Cardinalidade significa o número de instâncias de uma entidade específica em um conjunto. No contexto do agente MQTT, cardinalidade refere-se ao número de réplicas de front-end, partições de back-end e trabalhos de back-end a serem implantados. As configurações de cardinalidade são usadas para dimensionar o agente horizontalmente e melhorar a alta disponibilidade se houver falhas de pod ou nó.

O campo de cardinalidade é um campo aninhado, com subcampos para cadeia front-end e back-end. Cada um desses subcampos tem suas próprias configurações.

Front-end

O subcampo de front-end define as configurações para os pods de front-end. As duas configurações principais são:

Réplicas: o número de réplicas de front-end (pods) a serem implantadas. Aumentar o número de réplicas de front-end fornece alta disponibilidade caso um dos pods de front-end falhe.
Trabalhos: o número de trabalhos de front-end lógicos por réplica. Cada trabalho pode consumir até um núcleo de CPU no máximo.

Cadeia de back-end

O subcampo de cadeia de back-end define as configurações para as partições de back-end. As três configurações principais são:

Partições: o número de partições a serem implantadas. Por meio de um processo chamado fragmentação, cada partição é responsável por uma parte das mensagens, dividida por ID do tópico e ID da sessão. Os pods de front-end distribuem o tráfego de mensagens entre as partições. Aumentar o número de partições aumenta o número de mensagens que o agente pode manipular.
Fator de redundância: o número de réplicas de back-end (pods) a serem implantadas por partição. Aumentar o fator de redundância aumenta o número de cópias de dados para fornecer resiliência contra falhas de nó no cluster.
Trabalhos: o número de trabalhadores a serem implantados por réplica de back-end. Aumentar o número de trabalhos por réplica de back-end pode aumentar o número de mensagens que o pod de back-end pode manipular. Cada trabalho pode consumir até dois núcleos de CPU no máximo, portanto, tenha cuidado ao aumentar o número de trabalhos por réplica para não exceder o número de núcleos de CPU no cluster.

Considerações

Quando você aumenta os valores de cardinalidade, a capacidade do agente de lidar com mais conexões e mensagens geralmente melhora e aumenta a alta disponibilidade se houver falhas de pod ou nó. Esse aumento de capacidade também leva a um maior consumo de recursos. Portanto, ao ajustar os valores de cardinalidade, considere as configurações de perfil de memória e as solicitações de recurso de CPU do agente. Aumentar o número de trabalhos por réplica de front-end pode ajudar a aumentar a utilização do núcleo da CPU se você descobrir que a utilização da CPU de front-end é um gargalo. Aumentar o número de trabalhos de back-end pode ajudar com a taxa de transferência da mensagem se o uso da CPU de back-end for um gargalo.

Por exemplo, se o cluster tiver três nós, cada um com oito núcleos de CPU, defina o número de réplicas de front-end para corresponder ao número de nós (3) e definir o número de trabalhos como 1. Defina o número de partições de back-end para corresponder ao número de nós (3) e defina os trabalhos de back-end como 1. Defina o fator de redundância conforme desejado (2 ou 3). Aumente o número de trabalhadores de front-end se você descobrir que o uso da CPU de front-end é um gargalo. Lembre-se de que os trabalhadores de back-end e front-end podem competir por recursos de CPU entre si e com outros pods.

Configurar o perfil de memória

Importante

Para ajustar as configurações de memória do Agente MQTT, é especifique os campos de perfil de memória no recurso Agente durante a implantação das Operações de IoT.

Portal
CLI do Azure

Quando você usar o guia a seguir para implantar as Operações de IoT, na seção Configuração , veja a Configuração do Agente do MQTT e localize a configuração de Perfil de memória. Aqui, você pode selecionar entre os perfis de memória disponíveis em uma lista de seleção.

Ao implantar as Operações de IoT usando o comando az iot ops create, use o parâmetro --broker-mem-profile para especificar as configurações de perfil de memória.

Por exemplo, para especificar o perfil de memória como Tiny, consulte o seguinte comando (outros parâmetros foram omitidos para brevidade):

az iot ops create ... --broker-mem-profile Tiny

Para saber mais, consulte az iot ops create parâmetros opcionais.

Há alguns perfis de memória para escolher, cada um com diferentes características de uso de memória.

Pequeno

Ao usar este perfil:

O uso máximo de memória de cada réplica de front-end é de aproximadamente 99 MiB, mas o uso máximo real de memória pode ser maior.
O uso máximo de memória de cada réplica de back-end é de aproximadamente 102 MiB multiplicado pelo número de trabalhos de back-end, mas o uso máximo real de memória pode ser maior.

Recomendações ao usar este perfil:

Apenas um front-end deve ser usado.
Os clientes não devem enviar pacotes grandes. Você só deve enviar pacotes menores que 4 MiB.

Baixo

Ao usar este perfil:

O uso máximo de memória de cada réplica de front-end é de aproximadamente 387 MiB, mas o uso máximo real de memória pode ser maior.
O uso máximo de memória de cada réplica de back-end é de aproximadamente 390 MiB multiplicado pelo número de trabalhos de back-end, mas o uso máximo real de memória pode ser maior.

Recomendações ao usar este perfil:

Apenas um ou dois front-ends devem ser usados.
Os clientes não devem enviar pacotes grandes. Você só deve enviar pacotes menores que 10 MiB.

Médio

Médio é o perfil padrão.

O uso máximo de memória de cada réplica de front-end é de aproximadamente 1,9 GiB, mas o uso máximo real de memória pode ser maior.
O uso máximo de memória de cada réplica de back-end é de aproximadamente 1,5 GiB multiplicado pelo número de trabalhos de back-end, mas o uso máximo real de memória pode ser maior.

Alto

O uso máximo de memória de cada réplica de front-end é de aproximadamente 4,9 GiB, mas o uso máximo real de memória pode ser maior.
O uso máximo de memória de cada réplica de back-end é de aproximadamente 5,8 GiB multiplicado pelo número de trabalhos de back-end, mas o uso máximo real de memória pode ser maior.

Limites de recursos de Cardinalidade e Kubernetes

Para evitar a falta de recursos no cluster, o agente é configurado por padrão para solicitar limites de recursos de CPU do Kubernetes. Dimensionar proporcionalmente o número de réplicas ou trabalhadores aumenta proporcionalmente os recursos de CPU necessários. Um erro de implantação será emitido se houver recursos de CPU insuficientes disponíveis no cluster. Essa notificação ajuda a evitar situações em que a cardinalidade do agente solicitada não tem recursos suficientes para ser executada de forma ideal. Ele também ajuda a evitar possíveis remoções de pod e contenção de CPU.

Atualmente, o Agente MQTT solicita uma (1,0) unidade de CPU por trabalho de front-end e duas (2,0) unidades de CPU por trabalho de back-end. Para obter mais informações, confira a página Unidades de recursos de CPU do Kubernetes.

Por exemplo, a cardinalidade a seguir solicitaria os seguintes recursos de CPU:

Para front-ends: 2 unidades de CPU por pod de front-end, totalizando 6 unidades de CPU.
Para back-ends: 4 unidades de CPU por pod de back-end (para dois trabalhos de back-end), vezes 2 (fator de redundância), vezes 3 (número de partições), totalizando 24 unidades de CPU.

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

Para desabilitar essa configuração, defina o campo generateResourceLimits.cpu como Disabled no recurso Broker.

Portal
CLI do Azure

Não há suporte para alterar o campo generateResourceLimits no portal do Azure. Para desabilitar essa configuração, use a CLI do Azure.

Prepare um arquivo de configuração do Agente no formato JSON, que inclui as propriedades desejadas do recurso microsoft.iotoperations/instances/brokersResource Manager e defina o campo generateResourceLimits.cpu como Disabled. Por exemplo:

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

az iot ops create ... --broker-config-file <FILE>.json

Para saber mais, consulte o Suporte da CLI do Azure para a configuração avançada do agente MQTT.

Implantação de vários nós

Para garantir alta disponibilidade e resiliência com implantações de vários nós, o Agente MQTT das Operações de IoT define automaticamente regras anti-afinidade para pods de back-end.

Essas regras são predefinidas e não podem ser modificadas.

Finalidade de regras anti-afinidade

As regras anti-afinidade garantem que os pods de back-end da mesma partição não sejam executados no mesmo nó. Essa funcionalidade ajuda a distribuir a carga e a fornecer resiliência contra falhas de nó. Especificamente, os pods de back-end da mesma partição têm anti-afinidade entre si.

Verificar as configurações de anti-afinidade

Para verificar as configurações de anti-afinidade de um pod de back-end, use o seguinte comando:

kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15

A saída mostra a configuração anti-afinidade, semelhante ao exemplo a seguir:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: chain-number
            operator: In
            values:
            - "1"
        topologyKey: kubernetes.io/hostname
      weight: 100

Essas são as únicas regras anti-afinidade definidas para o agente.

Configurar ouvintes para o agente MQTT

Compartilhar via

Definir configurações do agente para alta disponibilidade, dimensionamento e uso de memória

Definir as configurações de dimensionamento

Cardinalidade de implantação automática

Configurar a cardinalidade diretamente

Entenda a cardinalidade

Front-end

Cadeia de back-end

Considerações

Configurar o perfil de memória

Pequeno

Baixo

Médio

Alto

Limites de recursos de Cardinalidade e Kubernetes

Implantação de vários nós

Finalidade de regras anti-afinidade

Verificar as configurações de anti-afinidade

Comentários

Recursos adicionais

Compartilhar via

Definir configurações do agente para alta disponibilidade, dimensionamento e uso de memória

Definir as configurações de dimensionamento

Cardinalidade de implantação automática

Configurar a cardinalidade diretamente

Entenda a cardinalidade

Front-end

Cadeia de back-end

Considerações

Configurar o perfil de memória

Pequeno

Baixo

Médio

Alto

Limites de recursos de Cardinalidade e Kubernetes

Implantação de vários nós

Finalidade de regras anti-afinidade

Verificar as configurações de anti-afinidade

Conteúdo relacionado

Comentários

Recursos adicionais