Partilhar via

Configurar o comportamento do buffer de mensagens com backup de disco

  • Artigo

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.

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

  • Gerenciamento eficiente de filas: em um broker MQTT, cada assinante é associado a uma fila de mensagens. A velocidade com que um assinante processa mensagens 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 após a reconexão. 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 sai, mas desde que pelo menos um pod em cada cadeia de back-end permaneça funcional, o corretor como um todo não perde 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 o agente MQTT Event Grid, 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, garantindo 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 armazenados pelo broker.

Opções de configuração

Para configurar o buffer de mensagens com backup de disco, edite a diskBackedMessageBuffer seção no recurso Broker. Atualmente, isso só é suportado usando o --broker-config-file sinalizador quando você implanta as Operações IoT do Azure 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 é a opção menos preferida, dadas as limitações de 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 StorageClass 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:

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. Observe que volumes efêmeros requerem Kubernetes 1.23 ou superior.

Gorjeta

A especificação de um modelo de Declaração de Volume Efémero (EVC) ou de Declaração de Volume Persistente (PVC) permite que você use uma classe de armazenamento de sua escolha, aumentando a flexibilidade para alguns cenários de implantação. Por exemplo, os Volumes Persistentes (PVs) provisionados usando um modelo PVC aparecem em comandos como kubectl get pv, que podem ser úteis 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 Blobs do Azure. No entanto, geralmente é melhor usar o disco local com um valor menor maxSize , pois o buffer de mensagens se beneficia do acesso rápido e não requer durabilidade.

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

Para usar o buffer de mensagens com backup de disco, implante as Operações IoT do Azure usando o az iot ops create comando com o --broker-config-file sinalizador. Consulte o seguinte comando (outros parâmetros omitidos por 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 do Azure IoT Operations.

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 especificações StatefulSet 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 especificações StatefulSet 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"
      ]
    }
  }
}

emptyDir volume

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

Use apenas o volume emptyDir ao usar um cluster com cotas de sistema de arquivos. Para obter mais informações, consulte os detalhes na 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 volume emptyDir com capacidade de 1 gigabyte, especifique os seguintes parâmetros no recurso Broker:

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

Considerações para provedores de armazenamento

Considere o comportamento do provedor de armazenamento escolhido. Por exemplo, ao usar 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ó. Isso pode levar o Kubernetes a marcar o nó e todos os pods associados como insalubres. É 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. Este também é o comportamento 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. No entanto, esse recurso fornece espaço de armazenamento temporário para que os dados sejam salvos no disco, evitando estouros de memória e perda de dados durante a reinicialização do pod.