Compartilhar via

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

O recurso Agente é o principal recurso que define as configurações gerais de um Agente MQTT. Ele também determina o número e o tipo de pods que executam a configuração do Agente, como os front-ends e os 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 as alterações de configuração do Agente forem necessárias. 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.

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.

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.

Quando você seguir o painel para implantar a 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 trabalhos de back-end.

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

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 trabalhos 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

O perfil de memória especifica o uso de memória do corretor para ambientes com recursos limitados. Você pode escolher entre perfis de memória predefinidos que têm diferentes características de uso de memória. A definição do perfil de memória é usada para ajustar o uso de memória das réplicas de front-end e back-end. O perfil de memória interage com as configurações de cardinalidade para determinar o uso total de memória do corretor.

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 as alterações de configuração do Agente forem necessárias. Para saber mais, confira Personalizar o Agente padrão.

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.

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.

Captura de tela que mostra onde configurar o perfil de memória no portal do Azure.

Há perfis de memória predefinidos com diferentes características de uso de memória para publicar mensagens. Não há um limite no número de sessões ou assinaturas que o agente pode manipular. O perfil de memória rege apenas o uso de memória para o tráfego PUBLISH.

Pequeno

Use esse perfil quando você tiver recursos de memória limitados e o tráfego de publicação do cliente for baixo.

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.
  • O tamanho máximo da mensagem é de 4 MB.
  • O tamanho máximo do buffer de entrada para dados de PUBLISH é de aproximadamente 16 MiB por trabalhador de back-end. Porém, o tamanho efetivo pode ser menor devido aos mecanismos de compactação inativa, que são ativados quando o buffer atinge 75% da capacidade, resultando em um tamanho de buffer de aproximadamente 12 MiB. Os pacotes rejeitados têm uma resposta PUBACK com um código de erro Cota Excedida.

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

Use esse perfil quando você tiver recursos de memória limitados e os clientes publicarem pacotes pequenos.

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.
  • O tamanho máximo da mensagem é de 16 MB.
  • O tamanho máximo do buffer de entrada para dados PUBLISH é de aproximadamente 64 MiB por trabalhador de back-end. Contudo, o tamanho efetivo pode ser menor devido aos mecanismos de compactação inativa, que são ativados quando o buffer atinge 75% da capacidade, resultando em um tamanho de buffer de aproximadamente 48 MiB. Os pacotes rejeitados têm uma resposta PUBACK com um código de erro Cota Excedida.

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 16 MiB.

Médio

Use esse perfil quando precisar lidar com um número moderado de mensagens de cliente.

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.
  • O tamanho máximo da mensagem é de 64 MB.
  • O tamanho máximo do buffer de entrada para dados PUBLISH é de aproximadamente 576 MiB por trabalhador de back-end. No entanto, o tamanho efetivo pode ser menor devido aos mecanismos de compactação inativa, que são ativados quando o buffer atinge 75% da capacidade, resultando em um tamanho de buffer de aproximadamente 432 MiB. Os pacotes rejeitados têm uma resposta PUBACK com um código de erro Cota Excedida.

Alta

Use esse perfil quando precisar lidar com um grande número de mensagens de cliente.

  • 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.
  • O tamanho máximo da mensagem é de 256 MB.
  • O tamanho máximo do buffer de entrada para dados de PUBLISH é de aproximadamente 2 GiB por trabalhador de back-end. Entretanto, o tamanho efetivo pode ser menor devido aos mecanismos de compactação inativa, que são ativados quando o buffer atinge 75% da capacidade, resultando em um tamanho de buffer de aproximadamente 1,5 GiB. Os pacotes rejeitados têm uma resposta PUBACK com um código de erro Cota Excedida.

Calcular o uso total de memória

A definição de perfil de memória especifica o uso de memória para cada réplica de front-end e back-end e interage com as definições de cardinalidade. Você pode calcular o uso total de memória usando a fórmula:

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

Em que:

Variável Descrição
M_total Uso total de memória
R_fe O número de réplicas de front-end
M_fe O uso de memória de cada réplica de front-end
P_be O número de partições de back-end
RF_be Fator de redundância do backend
M_be O uso de memória de cada réplica de back-end
W_be O número de trabalhos por réplica de back-end

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 GB e uso de memória de back-end de 1,5 GB. 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 é:

2 * 1,9 GB + (2 * 2) * 1,5 GB * 2 = 15,8 GB

Em comparação, o perfil de memória Tiny tem um uso de memória do front-end de 99 MiB e uso de memória do back-end de 102 MiB. Se você assumir a mesma configuração do agente, o uso total de memória será:

2 * 99 MB + (2 * 2) * 102 MB * 2 = 198 MB + 816 MB = 1,014 GB.

Importante

O agente MQTT começa a rejeitar mensagens quando a memória está 75% cheia.

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.

Não há suporte para alterar o campo generateResourceLimits 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 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.

Conteúdo relacionado

  • Last updated on