Planejamento de implantação para Operações do Azure IoT

Muitas configurações de Operações do Azure IoT são corrigidas no momento da implantação e só podem ser alteradas reimplantando. Antes de implantar, planeje a topologia do cluster, a cardinalidade do agente, o perfil de memória e as configurações opcionais do agente de que você precisa. Este artigo resume as decisões que você deve tomar.

Entender a arquitetura

Operações do Azure IoT é um conjunto de serviços modulares e nativos do Kubernetes implantados em um cluster habilitado para Azure Arc. Os componentes principais incluem:

Dois termos são usados em toda a documentação:

• Implantação – a instância, as extensões do Arc, os locais personalizados e todos os recursos configuráveis (ativos, dispositivos, fluxos de dados).
• Instância — o recurso pai que agrupa os serviços.

Escolha sua topologia de cluster

Antes de implantar, decida se você precisa de um cluster de nó único ou de vários nós. Essa decisão determina os requisitos de hardware e as configurações de cardinalidade do agente.

Entenda a cardinalidade do broker

Cardinalidade é o número de réplicas de front-end, trabalhos de front-end, partições de back-end e trabalhos de back-end na implantação do agente. A cardinalidade controla como o agente é escalado horizontalmente e quão resiliente ele é a falhas de pod ou nó.

O agente MQTT tem uma arquitetura de duas camadas: os pods de front-end lidam com conexões de cliente e processamento de protocolo, enquanto os pods de back-end lidam com o armazenamento e a entrega de mensagens. Entender como cada camada é dimensionada é importante para o planejamento de capacidade.

Frontend

Os pods de front-end aceitam conexões de cliente MQTT e encaminham mensagens para o back-end. Os pods de front-end não armazenam mensagens por conta própria. Há duas configurações principais para a camada de front-end:

• Réplicas: o número de pods de front-end a serem implantados. Adicionar mais réplicas de front-end aumenta o número de conexões simultâneas de clientes que o agente pode suportar e fornece alta disponibilidade caso um dos pods de front-end falhe.
• Trabalhadores: o número de trabalhadores lógicos por pod de front-end. Adicionar mais trabalhadores permite que o pod de front-end use mais núcleos de CPU. Cada worker pode consumir até um núcleo de CPU.

Cadeia de back-end

Os pods de back-end fazem o armazenamento e a entrega de mensagens. Há três configurações principais para a camada de back-end:

• Partições: o número de partições a serem implantadas. Partições são a unidade de dimensionamento horizontal para taxa de transferência de mensagem. Por meio de um processo chamado fragmentação, cada partição manipula uma parte das mensagens, fragmentada por tópico e sessão. Os pods de front-end distribuem o tráfego de mensagens entre as partições. Adicionar mais partições aumenta a taxa de transferência total de mensagens que o agente pode manipular.
• Fator de redundância: o número de pods de back-end a serem implantados 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.
• Trabalhadores: o número de trabalhadores por pod de backend. Trabalhadores são a unidade de dimensionamento vertical em uma partição — adicionar mais trabalhadores permite que o pod de back-end use mais núcleos de CPU no mesmo nó. Cada trabalho pode consumir até dois núcleos de CPU, portanto, tenha cuidado ao aumentar o número de trabalhadores por réplica para não exceder o número de núcleos de CPU no cluster.

Estimativa de taxa de transferência

O desempenho de uma partição específica depende fortemente das características da CPU do nó em que está em execução. Como regra geral, espere cerca de 5.000 a 6.000 mensagens QoS 1 por segundo por partição com cargas de 8 KB em uma CPU de 2 GHz (~4 GHz turbo). O desempenho do mundo real depende de muitos fatores, portanto, use esse número apenas como ponto de partida para o planejamento da capacidade.

Para obter dados de parâmetro de comparação detalhados, consulte o benchmarking de desempenho do MQTT Broker.

Recomendações de nó único

• Réplicas de front-end: definidas como 1.
• Trabalhos de front-end: defina como metade do número de núcleos de CPU por nó.
• Réplicas de back-end (fator de redundância): defina pelo menos 2 para que o agente possa executar atualizações contínuas.

Exemplo: nó único, 4 núcleos de CPU

Recomendações de vários nós

Os valores a seguir são recomendados para um desempenho ideal. Para clusters grandes com tráfego baixo, esses valores podem ser definidos abaixo das recomendações sem causar problemas. Mais considerações, como memória (RAM) e características de desempenho, são discutidas nas seções a seguir. Sempre teste sua configuração com a carga de trabalho esperada para confirmar o desempenho.

• Réplicas de front-end: defina igual ao número de nós no cluster.
• Trabalhos de front-end: defina como metade do número de núcleos de CPU por nó.
• Réplicas de backend (fator de redundância): Defina como 2 para redundância e suporte a atualizações contínuas.
• Partições de backend: Defina como igual ao número de nós do cluster.
• Trabalhadores de back-end: defina como metade do número de núcleos de CPU por nó.

Exemplo: cluster de 3 nós, 8 núcleos de CPU por nó

Exemplo: cluster de 5 nós, 16 núcleos de CPU por nó

Limites de recursos da CPU

Para evitar a falta de recursos no cluster, o broker pode ser configurado para solicitar limites de recursos de CPU do Kubernetes baseando-se nas configurações de cardinalidade. Quando habilitado, o dimensionamento do número de réplicas ou trabalhadores aumenta proporcionalmente os recursos de CPU necessários.

O padrão para a API REST, o Bicep e os modelos do ARM é definido na especificação da API do Broker.

O Agente MQTT solicita recursos de CPU por pod com base no número de trabalhadores configurados:

• Pods de front-end: 1,0 CPU por trabalhador
• Pods de back-end: 2,0 CPU por trabalhador

Use as seguintes fórmulas para calcular os requisitos totais de CPU:

Exemplo: cluster pequeno

Considere um cluster de 2 nós com 4 núcleos de CPU por nó (total de 8 núcleos) com a seguinte cardinalidade:

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

As solicitações do agente:

• CPU de front-end: 2 réplicas × 2 trabalhadores × 1,0 = 4,0 CPU
• CPU de back-end: 1 partição × 2 RF × 1 trabalhador × 2,0 = 4,0 CPU
• CPU total do agente: 8,0 CPU

Essa configuração solicita 8,0 CPUs em um cluster com apenas 8 núcleos, o que não deixa nada para outros componentes do Operações do Azure IoT (200-300m) nem para pods do sistema do Kubernetes. Os pods do agente permanecem em estado Pending com erros Insufficient cpu.

Para resolver isso, adicione mais nós, aumente os núcleos por nó ou reduza a cardinalidade do agente.

Exemplo: implantação maior

A cardinalidade a seguir solicita significativamente mais recursos de CPU:

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

• CPU de front-end: 3 réplicas × 2 trabalhadores × 1,0 = 6,0 CPU
• CPU de back-end: 3 partições × 2 RF × 2 trabalhadores × 2,0 = 24,0 CPU
• CPU total do agente: 30,0 CPU

Um cluster precisa de pelo menos 30 núcleos de CPU disponíveis somente para os pods de agente, além de capacidade adicional para outros componentes do Operações do Azure IoT e pods do sistema do Kubernetes.

Configuração de limite de recursos da CPU

Os limites de recursos da CPU são controlados pelo generateResourceLimits.cpu campo no recurso Broker. Essa configuração só tem suporte usando o --broker-config-file sinalizador quando você implanta Operações do Azure IoT usando o az iot ops create comando. Para obter mais informações, consulte o suporte da CLI do Azure para a configuração avançada do agente MQTT.

Prepare um arquivo de configuração do Broker seguindo a referência da API GenerateResourceLimits . Os exemplos a seguir mostram os dois valores possíveis:

{
  "generateResourceLimits": {
    "cpu": "Enabled"
  }
}

Ou

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

Escolha seu perfil de memória

O perfil de memória controla o tamanho máximo das mensagens MQTT que o broker aceita, o uso de memória ociosa e o uso máximo de memória de cada pod. Decida sobre o perfil de memória correto antes da implantação com base nos tamanhos e na taxa de transferência esperados da mensagem.

Buffer de entrada e retropresão

Cada perfil de memória define um tamanho máximo de buffer de entrada para dados PUBLISH por trabalho de back-end. Quando o buffer atinge 75% da capacidade, o broker ativa mecanismos de backpressure e começa a rejeitar mensagens recebidas. Os pacotes rejeitados recebem uma resposta PUBACK com o código de erro Cota excedida.

A tabela a seguir mostra os tamanhos de buffer de entrada por trabalhador para cada perfil:

Ao escolher um perfil de memória, considere:

• Minúsculo: apenas um front-end deve ser usado. Enviar apenas pacotes menores que 4 MiB.
• Baixo: apenas um ou dois front-ends devem ser usados. Envie apenas pacotes menores que 16 MiB.
• Médio: adequado para a maioria das cargas de trabalho de produção com mensagens de tamanho moderado.
• Alta: use quando precisar lidar com mensagens grandes ou alta taxa de transferência com buffers grandes.

A memória total do agente depende tanto do perfil de memória quanto da cardinalidade (número de réplicas de front-end, partições de back-end e fator de redundância). Mais pods significam mais memória total. Para obter o consumo de recursos de linha de base medido em diferentes configurações, consulte perfis de recurso de linha de base.

Calcular o uso total de memória

Você pode calcular o uso total de memória com esta fórmula:

M_total = (R_fe × M_fe) + (P_be × RF_be × M_be × W_be)

Em que:

Por exemplo, se você escolher o perfil de memória média , o perfil terá um uso de memória de front-end de 1,9 GiB e um uso de memória de back-end de 1,5 GiB. Suponha que a configuração do corretor seja de 2 réplicas front-end, 2 partições back-end e um fator de redundância back-end de 2. O uso total de memória é:

M_total = (2 × 1.9 GiB) + (2 × 2 × 1.5 GiB × 2)
        = 15.8 GiB

Em comparação, o perfil de memória Tiny tem uso de memória no frontend de 99 MiB e no backend de 102 MiB. Com a mesma configuração do broker, o uso total de memória é:

M_total = (2 × 99 MiB) + (2 × 2 × 102 MiB × 2)
        = 198 MiB + 816 MiB
        = 1014 MiB (≈ 1.0 GiB)

Configuração do perfil de memória

Quando você implanta operações de IoT usando o az iot ops create comando, o --broker-mem-profile parâmetro especifica as configurações de perfil de memória.

Por exemplo, o comando a seguir define o perfil de memória como Tiny (outros parâmetros são omitidos para brevidade):

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

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

Configurações opcionais do agente

As configurações do broker a seguir também são definidas durante a implantação e não podem ser alteradas posteriormente. Examine-os se eles se aplicam ao seu cenário:

• Buffer de mensagens armazenado em disco — Armazena mensagens em disco quando as filas dos assinantes excedem a memória disponível. Útil para sessões persistentes e desafios de conectividade.
• Persistência — Escreva dados críticos do broker em disco para preservá-los após reinicializações.
• Diagnósticos — Configure métricas, logs e sondas de autoverificação para o broker MQTT.
• Opções avançadas do MQTT — personalize a expiração da sessão, a expiração da mensagem, os limites de fila do assinante e as configurações de manutenção.
• Criptografia do tráfego interno — Configure a criptografia do tráfego interno entre os pods de frontend e backend do broker (ativada por padrão).

Próximas Etapas 

• Preparar o cluster
• Implantar em um cluster de produção
• Configurar a observabilidade
• Proteja sua implantação