Configurar o comportamento do buffer de mensagens com backup de disco

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.

O recurso de buffer de mensagens com backup de disco é usado para o gerenciamento eficiente de filas de mensagens dentro do broker MQTT distribuído. Os benefícios incluem:

• Gerenciamento eficiente de filas: em um broker MQTT, cada assinante é associado a uma fila de mensagens. A velocidade de processamento de mensagens de um assinante afeta diretamente o tamanho da fila. Se um assinante processar mensagens lentamente ou se desconectar, mas solicitar uma sessão persistente MQTT, a fila pode crescer mais do que a memória disponível.
• Preservação de dados para sessões persistentes: o recurso de buffer de mensagens com backup em disco garante que, quando uma fila exceder a memória disponível, ela seja armazenada em buffer no disco sem problemas. Esse recurso evita a perda de dados e suporta sessões persistentes MQTT, permitindo que os assinantes retomem suas sessões com suas filas de mensagens intactas quando se reconectarem. O disco é usado como armazenamento efêmero e serve como um spillover da memória. Os dados gravados no disco não são duráveis e são perdidos quando o pod é encerrado. Se pelo menos um pod em cada cadeia de back-end permanecer funcional, o corretor como um todo não perderá nenhum dado.
• Lidar com desafios de conectividade: os conectores de nuvem são tratados como assinantes com sessões persistentes que podem enfrentar desafios de conectividade quando não conseguem se comunicar com sistemas externos, como um agente MQTT da Grade de Eventos do Azure devido à desconexão da rede. Nesses cenários, as mensagens (PUBLISHes) se acumulam. O agente MQTT armazena essas mensagens de forma inteligente na memória ou no disco até que a conectividade seja restaurada, o que garante a integridade da mensagem.

Por padrão, o recurso de buffer de mensagens com backup de disco está desabilitado. Nesse caso, as mensagens permanecem na memória e a pressão de retorno é aplicada aos clientes à medida que o pool de leitores ou o pool de rascunhos atinge o limite, conforme definido pelo limite da fila de assinantes.

Configurar o buffer de mensagens apoiado em disco é essencial para manter um sistema de enfileiramento de mensagens robusto e confiável, especialmente em cenários onde a velocidade de processamento de mensagens e a conectividade são críticas.

Nota

O broker MQTT grava dados no disco exatamente como recebidos dos clientes, sem criptografia adicional. Proteger o disco é essencial para proteger os dados que o corretor armazena.

Opções de configuração

Para configurar o buffer de mensagens com backup de disco, edite a diskBackedMessageBuffer seção no recurso Broker. Atualmente, essa configuração é suportada apenas usando o sinalizador quando você implanta o --broker-config-file Azure IoT Operations usando o az iot ops create comando.

Para começar, prepare um arquivo de configuração do Broker seguindo a referência da API DiskBackedMessageBuffer .

Por exemplo, a configuração mais simples envolve apenas especificar o tamanho máximo. Neste caso, um emptyDir volume é montado. O maxSize valor é usado como o limite de tamanho do emptyDir volume. Mas esta opção é a menos preferida devido às limitações do emptyDir volume.

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>"
  }
}

Para obter uma melhor configuração do buffer de mensagens com backup em disco, especifique um volume efêmero ou uma declaração de volume persistente para montar um volume de armazenamento dedicado para o buffer de mensagens. Por exemplo:

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

{
  "persistentVolumeClaimSpec": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

Personalize as opções de buffer de mensagens do broker ajustando as seguintes configurações:

• Configurar o volume: especifique um modelo de declaração de volume para montar um volume de armazenamento dedicado para o buffer de mensagens.
• Selecione uma classe de armazenamento: defina a classe de armazenamento desejada usando a storageClassName propriedade.
• Definir modos de acesso: determine os modos de acesso necessários para o seu volume. Para obter mais informações, consulte Modos de acesso a volume persistente.

Use as seções a seguir para entender os diferentes modos de volume:

• O volume efêmero é a opção preferida.
• O volume persistente é a próxima opção preferida.
• O volume emptyDir é a opção menos preferida.

Os volumes persistentes e efêmeros geralmente são fornecidos pelas mesmas classes de armazenamento. Se ambas as opções estiverem disponíveis, escolha efêmero. Volumes efêmeros requerem Kubernetes 1.23 ou superior.

Gorjeta

Ao especificar um modelo de EVC (Ephemeral Volume Claim) ou PVC (Persistent Volume Claim), você pode usar uma classe de armazenamento de sua escolha, o que aumenta a flexibilidade para alguns cenários de implantação. Por exemplo, os volumes persistentes provisionados usando um modelo PVC aparecem em comandos como kubectl get pv, que é útil para inspecionar o estado do cluster.

Se os nós do Kubernetes não tiverem espaço em disco local suficiente para o buffer de mensagens, use uma classe de armazenamento que forneça armazenamento de rede, como o Armazenamento de Blobs do Azure. É melhor usar um disco local com um valor menor maxSize porque o buffer de mensagens se beneficia do acesso rápido e não requer durabilidade.

Implantar operações de IoT com buffer de mensagens apoiado em disco

Para usar um buffer de mensagens com backup de disco, implante Operações IoT usando o az iot ops create comando com o --broker-config-file sinalizador. Consulte o comando a seguir. (Outros parâmetros são omitidos por uma questão de brevidade.)

az iot ops create ... --broker-config-file <FILE>.json

Essa configuração não pode ser alterada após a implantação. Para alterar a configuração do buffer de mensagens com backup de disco, reimplante a instância de Operações IoT.

Volume efêmero

O volume efêmero é a opção preferida para o buffer de mensagens.

Para volumes efêmeros, siga as recomendações na seção Considerações para provedores de armazenamento.

O valor da ephemeralVolumeClaimSpec propriedade é usado como a ephemeral.volumeClaimTemplate.spec propriedade do volume nas StatefulSet especificações das cadeias de back-end.

Por exemplo, para usar um volume efêmero com capacidade de 1 gigabyte, especifique os seguintes parâmetros no recurso do Broker:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Volume persistente

O volume persistente é a próxima opção preferida para o buffer de mensagens após o volume efêmero.

Para volumes persistentes, siga as recomendações na seção Considerações para provedores de armazenamento.

O valor da persistentVolumeClaimSpec propriedade é usado como a volumeClaimTemplates.spec propriedade das StatefulSet especificações das cadeias de back-end.

Por exemplo, para usar um volume persistente com capacidade de 1 gigabyte, especifique os seguintes parâmetros no recurso do Broker:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

volume emptyDir

Um volume emptyDir é a opção menos preferida após o volume persistente.

Use um emptyDir volume somente quando usar um cluster com cotas de sistema de arquivos. Para obter mais informações, consulte a guia Cota de projeto do sistema de arquivos. Se o recurso não estiver habilitado, o cluster fará uma verificação periódica que não impõe nenhum limite e permite que o nó do host preencha espaço em disco e marque todo o nó do host como não íntegro.

Por exemplo, para usar um emptyDir volume com capacidade de 1 gigabyte, especifique os seguintes parâmetros no recurso do Broker:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

Considerações para provedores de armazenamento

Considere o comportamento do provedor de armazenamento escolhido, por exemplo, quando você usa provedores como rancher.io/local-path. Se o provedor não oferecer suporte a limites, o preenchimento do volume consome espaço em disco do nó. Esse comportamento pode levar o Kubernetes a marcar o nó e todos os pods associados como não íntegros. É crucial entender como seu provedor de armazenamento se comporta nesses cenários.

Desativado

Se você não quiser usar o buffer de mensagens com backup de disco, não inclua a diskBackedMessageBufferSettings propriedade no recurso do Broker. Esse comportamento também é o padrão.

Persistência

É importante entender que o recurso de buffer de mensagens com backup de disco não é sinônimo de persistência. Neste contexto, a persistência refere-se aos dados que sobrevivem nas reinicializações do pod. Esse recurso fornece espaço de armazenamento temporário para que os dados sejam salvos no disco, o que evita estouros de memória e perda de dados durante a reinicialização do pod.