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.
Esta referência fornece o consumo de recursos de linha de base medido para implantações do Operações do Azure IoT em estado ocioso (sem cargas de trabalho ativas). Use esses perfis para validar que o hardware atende aos requisitos mínimos e estabelecer linhas de base de monitoramento de recursos.
Visão geral
Operações do Azure IoT implanta vários componentes em vários namespaces do Kubernetes. O volume total de recursos depende de dois fatores: o perfil de memória do agente MQTT (que controla a alocação de memória por pod) e a cardinalidade do agente (número de réplicas de front-end, partições de back-end e fator de redundância, que controla quantos pods são implantados). Maior cardinalidade significa mais pods e um perfil de memória mais alto significa que cada pod usa mais memória.
Três configurações foram medidas em clusters de nó único em ociosidade (sem ativos conectados, sem fluxos de dados ativos, tráfego quase zero). São números de linha de base, não máximos. As cargas de trabalho de produção aumentam significativamente o consumo:
| Configuration | Perfil de Memória | Cardinalidade | Memória de pico do nó | Operações do Azure IoT Namespace Peak RSS | RSS de pico total do pod | Contagem de Pods |
|---|---|---|---|---|---|---|
| Config A | Pequeno | 1 front-end 1 partição fator de redundância 2 |
~4.979 MiB | ~1.298 MiB | ~5.409 MiB | 55 |
| Config B | Baixo | 2 front-ends 2 partições fator de redundância 2 |
~5.130 MiB | ~1.559 MiB | ~5.695 MiB | 58 |
| Config C | Medium | 2 front-ends 2 partições fator de redundância 2 |
~6.088 MiB | ~2.407 MiB | ~6.564 MiB | 58 |
Note
A diferença entre a Configuração A e a Configuração B se deve tanto à maior cardinalidade (mais pods do broker) quanto a um perfil de memória diferente. A diferença entre a Configuração B e a Configuração C se deve exclusivamente ao perfil de memória (mesma cardinalidade, mesmo número de pods). Consulte exemplos de implantação de produção para cenários com carga.
Detalhamento do namespace
A tabela a seguir mostra o pico de memória RSS por namespace em todas as três configurações em ociosidade:
| Namespace | Configuração A, Minúscula (MiB) | Configuração B, Baixa (MiB) | Configuração C, Média (MiB) | Descrição |
|---|---|---|---|---|
| azure-iot-operations | 1,298 | 1,559 | 2,407 | serviços principais dos Operações do Azure IoT (broker, fluxos de dados, conectores, observabilidade) |
| azure-arc | 1,964 | 1,985 | 1,990 | Agentes e controladores do Azure Arc |
| cert-manager | 1,351 | 1,357 | 1,362 | Gerenciamento de certificados |
| gatekeeper-system | 338 | 338 | 350 | Aplicação de políticas |
| azure-extensions-usage-system | 279 | 277 | 278 | Operador de cobrança |
| arc-workload-identity | 90 | 90 | 91 | Webhooks de identidade de carga de trabalho |
| azure-secret-store | 87 | 88 | 87 | Controlador de sincronização de segredos |
| Total | ~5.409 | ~5.695 | ~6.564 |
Note
- Azure Arc, cert-manager, gatekeeper e outros namespaces de infraestrutura consomem ~3,8-4,1 GB, independentemente da configuração do agente. Essa sobrecarga é o custo fixo da execução de um cluster habilitado para Arc com Operações do Azure IoT.
-
Somente o
azure-iot-operationsnamespace é dimensionado com as opções de perfil de memória e cardinalidade, de ~1,3 GB (cardinalidade minúscula e mínima) para ~2,4 GB (cardinalidade média e superior). - Planeje pelo menos 6 GB de memória dedicados à infraestrutura do Operações do Azure IoT em estado ocioso, antes de considerar qualquer carga de trabalho.
Consumo de recursos do pod do Agente MQTT
O broker MQTT é o maior componente variável. As diferenças de memória entre as configurações decorrem tanto do perfil de memória (alocação por pod) quanto da cardinalidade (número de pods). A tabela a seguir mostra o RSS ocioso de cada pod. Esses números crescem com o tráfego:
| Pod | Configuração A, Minúscula (MiB) | Configuração B, Baixa (MiB) | Configuração C, Média (MiB) | Observações |
|---|---|---|---|---|
| aio-broker-frontend-0 | 29 | 33 | 169 | A memória por pod varia de acordo com o perfil |
| aio-broker-frontend-1 | N/A | 33 | 169 | Não presente na Config A (uma réplica de frontend) |
| aio-broker-backend-1-0 | 41 | 66 | 211 | A memória por pod varia de acordo com o perfil |
| aio-broker-backend-1-1 | 41 | 65 | 210 | Réplica do fator de redundância |
| aio-broker-backend-2-0 | N/A | 66 | 212 | Não está presente na Configuração A (uma partição) |
| aio-broker-backend-2-1 | N/A | 65 | 211 | Não está presente na Configuração A (uma partição) |
| aio-broker-health-manager-0 | 41 | 41 | 42 | Constante em todos os perfis |
| aio-broker-operator-0 | 60 | 60 | 56 | Constante em todos os perfis |
| aio-broker-diagnostics-probe-0 | 24 | 43 | 43 | |
| aio-broker-diagnostics-service-0 | 49 | 66 | 66 | |
| aio-broker-authentication-0 | 24 | 24 | 24 | Constante em todos os perfis |
| aio-broker-webhook-0 | 33 | 35 | 32 | Constante em todos os perfis |
Configuração do broker para cada perfil testado
| Setting | Configuração A (Minúscula) | Configuração B (Baixa) | Configuração C (Média) |
|---|---|---|---|
| Réplicas de front-end | 1 | 2 | 2 |
| Partições de back-end | 1 | 2 | 2 |
| Fator de redundância do backend | 2 | 2 | 2 |
| Total de pods do agente | 10 | 13 | 13 |
| Memória ociosa de front-end por pod | ~29 MiB | ~33 MiB | ~169 MiB |
| Memória de back-end ociosa por pod | ~41 MiB | ~66 MiB | ~211 MiB |
| Tamanho máximo da mensagem | 4 MB | 16 MB | 64 MB |
Consumo de outros componentes do Operações do Azure IoT
Esses componentes têm uso consistente de recursos ociosos, independentemente do perfil de memória ou cardinalidade:
| Componente | RSS máximo (MiB) | CPU de pico (núcleos) | Observações |
|---|---|---|---|
| adr-schema-registry (x2) | ~52 cada | 0,002 | Pods do registro de esquema |
| aio-akri-operator-0 | ~39 | 0.001 | Descoberta de dispositivos Akri |
| aio-akri-adr-service-0 | ~30 | 0.001 | Serviço ADR (Registro de Dispositivo) do Akri Azure |
| aio-dataflow-dev-0 | ~67 | 0,002 | Tempo de execução do fluxo de dados |
| aio-dataflow-operator-0 | ~56 | 0.001 | Operador de fluxo de dados |
| aio-operator | ~114 | 0.003 | Operador do Operações do Azure IoT |
| aio-observability (x2) | ~125 cada | 0.005 | Coletores OpenTelemetry |
| aio-observability-operator | ~106 | 0.003 | Operador de observabilidade |
| aio-observability-cluster-metrics-agent | ~114 | 0.004 | Agente de métricas |
| aio-wasm-graph-controller-0 | ~30 | 0.001 | Controlador de grafo WASM (WebAssembly) |
Consumo da CPU
O consumo de CPU é mínimo em ociosidade em todas as configurações testadas:
| Configuration | Pico de uso da CPU do namespace do Operações do Azure IoT | Pico total de CPU do cluster | % de nós |
|---|---|---|---|
| Config A (Pequena) | 0,025 núcleos | 0,099 núcleos | 1,3% |
| Configuração B (Baixa) | 0,044 núcleos | 0,104 núcleos | 1,3% |
| Config C (Média) | 0,048 núcleos | 0,093 núcleos | 1,2% |
O uso da CPU é insignificante em ociosidade. Em carga de produção, espere um consumo de CPU consideravelmente maior proporcional à taxa de transferência de mensagens e ao número de trabalhadores de front-end/back-end configurados.
Diretrizes de dimensionamento de hardware
Com base nessas medições de linha de base em estado ocioso, as seguintes recomendações mínimas de hardware aplicam-se a implantações em nó único. Os requisitos reais são mais altos no tráfego de produção:
| Perfil de Memória | RAM mínima (com folga) | RAM recomendada | Caso de uso |
|---|---|---|---|
| Pequena | 8 GB | 8 a 10 GB | Tráfego baixo, apenas pacotes pequenos |
| Baixo | 10 GB | 12 a 16 GB | Memória limitada, pacotes pequenos |
| Medium | 12 GB | 16 a 32 GB | Tamanhos moderados de tráfego e mensagem |
| High | 16 GB | Mais de 32 GB | Alta taxa de transferência, mensagens grandes |
Importante
Essas recomendações levam em conta os ~4 GB de sobrecarga fixa de infraestrutura (Azure Arc, cert-manager, gatekeeper), além do consumo variável de recursos do componente Operações do Azure IoT. As cargas de trabalho de produção exigem margem adicional para o armazenamento em buffer de mensagens MQTT, o processamento do fluxo de dados e a atividade do conector OPC UA.