Definir configurações do agente para alta disponibilidade, dimensionamento e uso de memória
O recurso Broker é o principal recurso que define as configurações gerais para o broker MQTT. Ele também determina o número e o tipo de pods que executam a configuração do Broker, como os frontends e os backends. Você também pode usar o recurso Broker para configurar seu perfil de memória. Os mecanismos de autorrecuperação são incorporados ao corretor e, muitas vezes, ele pode se recuperar automaticamente de falhas de componentes. Por exemplo, um nó falha em um cluster Kubernetes configurado para alta disponibilidade.
Você pode dimensionar horizontalmente o broker MQTT adicionando mais réplicas de frontend e partições de back-end. As réplicas de frontend 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, e o fator de redundância de back-end determina o número de cópias de dados para fornecer resiliência contra falhas de nó no cluster.
Para obter uma lista das configurações disponíveis, consulte a referência da API do Broker .
Definir configurações de dimensionamento
Importante
Essa configuração requer a modificação do recurso do Broker e só pode ser configurada no momento da 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 Broker. Para saber mais, consulte Personalizar o corretor padrão.
Para definir as configurações de dimensionamento do agente MQTT, especifique os campos de cardinalidade na especificação do recurso Broker durante a implantação do Azure IoT Operations.
Cardinalidade de implantação automática
Para determinar automaticamente a cardinalidade inicial durante a implantação, omita o campo cardinalidade no recurso Broker.
A cardinalidade automática ainda não é suportada ao implantar as Operações IoT do Azure por meio do portal do Azure. No entanto, você pode especificar manualmente o modo de implantação do cluster como Nó único ou Multinó. Para saber mais, consulte Implementar Operações IOT do Azure.
O operador do broker MQTT implanta automaticamente o número apropriado de pods com base no número de nós disponíveis no momento da implantação. Isso é útil para cenários de não produção em que você não precisa de alta disponibilidade ou escala.
No entanto, isso não é dimensionamento automático. O operador não dimensiona automaticamente o número de pods com base na carga. O operador determina apenas o número inicial de pods a serem implantados com base no hardware do cluster. Como observado anteriormente, a cardinalidade só pode ser definida no momento inicial da implantação, e uma nova implantação é necessária se as configurações de cardinalidade precisarem ser alteradas.
Configurar cardinalidade diretamente
Para definir as configurações de cardinalidade diretamente, especifique cada um dos campos de cardinalidade.
Ao seguir o guia para implantar as Operações do Azure IoT, 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 trabalhadores de back-end.
Compreender a cardinalidade
Cardinalidade significa o número de instâncias de uma entidade específica em um conjunto. No contexto do broker MQTT, cardinalidade refere-se ao número de réplicas de frontend, partições de back-end e trabalhadores de back-end a serem implantados. As configurações de cardinalidade são usadas para dimensionar o broker horizontalmente e melhorar a alta disponibilidade se houver falhas de pod ou node.
O campo cardinalidade é um campo aninhado, com subcampos para frontend e backendChain. Cada um desses subcampos tem suas próprias configurações.
Front-end
O subcampo frontend define as configurações para os pods frontend. 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 frontend fornece alta disponibilidade caso um dos pods de frontend falhe.
Trabalhadores: o número de trabalhadores de front-end lógicos por réplica. Cada trabalhador pode consumir até um núcleo de CPU no máximo.
Cadeia de back-end
O subcampo 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. Através de um processo chamado sharding, cada partição é responsável por uma parte das mensagens, divididas por ID de tópico e ID de sessão. Os pods frontend distribuem o tráfego de mensagens pelas partições. Aumentar o número de partições aumenta o número de mensagens que o broker pode manipular.
Fator de redundância: o número de réplicas de back-end (pods) a serem implantadas por partição. O aumento do 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 a serem implantados por réplica de back-end. Aumentar o número de trabalhadores por réplica de back-end pode aumentar o número de mensagens que o pod de back-end pode manipular. Cada trabalhador pode consumir até dois núcleos de CPU no máximo, 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.
Considerações
Quando você aumenta os valores de cardinalidade, a capacidade do broker de lidar com mais conexões e mensagens geralmente melhora, e aumenta a alta disponibilidade se houver falhas de pod ou node. No entanto, esta situação conduz igualmente 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 recursos de CPU do broker. Aumentar o número de trabalhadores 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 frontend é um gargalo. Aumentar o número de trabalhadores de back-end pode ajudar com a taxa de transferência de mensagens se a 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 defina o número de trabalhadores como 1. Defina o número de partições de back-end para corresponder ao número de nós (3) e os trabalhadores de back-end como 1. Defina o fator de redundância conforme desejado (2 ou 3). Aumente o número de trabalhadores frontend se descobrir que a CPU frontend é um gargalo. Lembre-se de que os trabalhadores de backend e frontend podem competir por recursos de CPU entre si e com outros pods.
Configurar perfil de memória
Importante
Essa configuração requer a modificação do recurso do Broker e só pode ser configurada no momento da 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 Broker. Para saber mais, consulte Personalizar o corretor padrão.
Para definir as configurações de perfil de memória do agente MQTT, especifique os campos de perfil de memória na especificação do recurso Broker durante a implantação do Azure IoT Operations.
Ao seguir o guia para implantar as Operações do Azure IoT, na seção Configuração, procure em Configuração do agente MQTT e localize a configuração do perfil de memória. Aqui, você pode selecionar a partir dos perfis de memória disponíveis a partir de uma lista suspensa.
Existem alguns perfis de memória para escolher, cada um com características de uso de memória diferentes.
Minúsculo
Ao usar este perfil:
- O uso máximo de memória de cada réplica de frontend é de aproximadamente 99 MiB, mas o uso máximo de memória real 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 trabalhadores de back-end, mas o uso máximo de memória real pode ser maior.
Recomendações ao usar este perfil:
- Apenas um frontend deve ser usado.
- Os clientes não devem enviar pacotes grandes. Só deve enviar pacotes com menos de 4 MiB.
Baixo
Ao usar este perfil:
- O uso máximo de memória de cada réplica de frontend é 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 trabalhadores de back-end, mas o uso máximo de memória real pode ser maior.
Recomendações ao usar este perfil:
- Apenas um ou dois frontends devem ser usados.
- Os clientes não devem enviar pacotes grandes. Só deve enviar pacotes com menos de 10 MiB.
Médio
Medium é o perfil padrão.
- O uso máximo de memória de cada réplica de frontend é de aproximadamente 1,9 GiB, mas o uso máximo de memória real 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 trabalhadores 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 frontend é 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 trabalhadores de back-end, mas o uso máximo de memória real pode ser maior.
Cardinalidade e limites de recursos do Kubernetes
Para evitar a falta de recursos no cluster, o broker é configurado por padrão para solicitar limites de recursos da CPU do Kubernetes. Dimensionar o número de réplicas ou trabalhadores aumenta proporcionalmente os recursos de CPU necessários. Um erro de implantação é emitido se não houver recursos de CPU suficientes disponíveis no cluster. Isso ajuda a evitar situações em que a cardinalidade do corretor solicitado não tem recursos suficientes para funcionar de forma ideal. Também ajuda a evitar possíveis contenções de CPU e despejos de pods.
Atualmente, o broker MQTT solicita uma (1.0) unidade de CPU por trabalhador frontend e duas (2.0) unidades de CPU por trabalhador backend. Consulte Unidades de recursos de CPU do Kubernetes para obter mais detalhes.
Por exemplo, a cardinalidade abaixo solicitaria os seguintes recursos de CPU:
- Para frontends: 2 unidades de CPU por pod frontend, totalizando 6 unidades de CPU.
- Para backends: 4 unidades de CPU por pod de back-end (para dois trabalhadores 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 desativar essa configuração, defina o generateResourceLimits.cpu campo como Disabled no recurso Broker.
Não há suporte para alterar o generateResourceLimits campo no portal do Azure. Para desabilitar essa configuração, use a CLI do Azure.
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 do Azure IoT Operations define automaticamente regras de antiafinidade para pods de back-end.
Estas regras são predefinidas e não podem ser modificadas.
Finalidade das regras antiafinidade
As regras de antiafinidade garantem que os pods de back-end da mesma partição não sejam executados no mesmo nó. Isso ajuda a distribuir a carga e fornece resiliência contra falhas de nó. Especificamente, os pods de back-end da mesma partição têm antiafinidade uns com os outros.
Verificando as configurações de antiafinidade
Para verificar as configurações de antiafinidade para 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 mostrará a configuração de antiafinidade, semelhante à seguinte:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: chain-number
operator: In
values:
- "1"
topologyKey: kubernetes.io/hostname
weight: 100
Estas são as únicas regras anti-afinidade definidas para o corretor.