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 de um 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. Um exemplo é se um nó falhar 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 frontend distribuem o tráfego de mensagens pelos pods de back-end. 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 que você modifique o recurso Broker. 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 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 quando você implanta Operações IoT por meio do portal do Azure. 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. Esse recurso é útil para cenários de não produção em que você não precisa de alta disponibilidade ou escala.
Esse recurso não é dimensionamento automático. O operador não dimensiona automaticamente o número de pods com base na carga. O operador determina o número inicial de pods a serem implantados somente com base no hardware do cluster. Como observado anteriormente, a cardinalidade é definida apenas no momento inicial da implantação. Uma nova implantação será 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 operações 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 o frontend e a cadeia de back-end. 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. Este aumento da capacidade conduz também 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 utilização 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 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 defina os trabalhadores de back-end como 1. Defina o fator de redundância como desejado (2 ou 3). Aumente o número de trabalhadores frontend se descobrir que a utilização da 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 que você modifique o recurso Broker. 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 Broker. Para saber mais, consulte Personalizar o corretor padrão.
Para definir as configurações de perfil de memória do broker MQTT, especifique os campos de perfil de memória na especificação do recurso Broker durante a implantação do IoT Operations.
Ao usar o guia a seguir para implantar operações IoT, na seção Configuração , procure em Configuração do agente MQTT e localize a configuração Perfil de memória . Aqui, você pode selecionar entre os perfis de memória disponíveis em uma lista suspensa.
Existem alguns perfis de memória para escolher, cada um com características de uso de memória diferentes.
Minúsculo
Quando você usa 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
Quando você usa este perfil:
- O uso máximo de memória de cada réplica de frontend é de aproximadamente 387 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 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 de memória real 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. Essa notificação ajuda a evitar situações em que a cardinalidade do corretor solicitado não tem recursos suficientes para ser executada de forma otimizada. 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 de front-end e duas (2.0) unidades de CPU por trabalhador de back-end. Para obter mais informações, consulte Unidades de recursos de CPU do Kubernetes.
Por exemplo, a seguinte cardinalidade solicitaria os seguintes recursos da CPU:
- Para frontends: 2 unidades de CPU por pod frontend, totalizando 6 unidades de CPU.
- Para backends: 4 unidades de CPU por pod de backend (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 de operações de IoT define automaticamente regras de antiafinidade para pods de back-end.
Essas 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ó. Esse recurso 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.
Verificar 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 mostra a configuração de antiafinidade, semelhante ao exemplo a seguir:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: chain-number
operator: In
values:
- "1"
topologyKey: kubernetes.io/hostname
weight: 100
Estas regras são as únicas regras anti-afinidade definidas para o corretor.