Planeamento de implementação - Buffer de mensagens apoiado em disco

O buffer de mensagens suportado por disco é uma funcionalidade que permite ao broker MQTT transferir as filas de mensagens dos assinantes para o disco quando estas excedem a memória disponível. Antes da implementação, decida se precisa de bufferização de mensagens com suporte em disco para o seu broker MQTT.

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.

A funcionalidade de buffer de mensagens baseado em disco é utilizada para gerir eficientemente as filas de mensagens no broker MQTT distribuído. Os benefícios incluem:

  • Gestão eficiente de filas: Num corretor MQTT, cada assinante está associado a uma fila de mensagens. A velocidade de processamento de mensagens de um assinante afeta diretamente o tamanho da fila. Se um subscritor processar mensagens lentamente ou se se desconectar mas solicitar uma sessão persistente MQTT, a fila pode crescer para além da memória disponível.
  • Preservação de dados para sessões persistentes: A funcionalidade de buffer de mensagens apoiado em disco garante que, quando uma fila excede a memória disponível, é armazenada de forma fluida para o disco. Esta funcionalidade previne a perda de dados e suporta sessões persistentes MQTT, permitindo que os assinantes retomem as suas sessões com as filas de mensagens intactas quando se reconectam. O disco é usado como armazenamento efémero e serve de extensão à memória. Os dados escritos no disco não são duráveis e perdem-se quando o pod sai. Se pelo menos um pod em cada cadeia de backend continuar funcional, o broker como um todo não perde nenhuns dados.
  • Gestão de desafios de conectividade: Os conectores cloud são tratados como assinantes com sessões persistentes que podem enfrentar desafios de conectividade quando não conseguem comunicar com sistemas externos, como um corretor Azure Event Grid MQTT, devido a desconexões de rede. Nesses cenários, as mensagens (PUBLISHes) acumulam-se. O corretor MQTT armazena inteligentemente estas mensagens em buffer para a memória ou disco até que a conectividade seja restabelecida, o que garante a integridade da mensagem.

Por predefinição, a funcionalidade de buffer de mensagens baseado em disco está desativada. Neste caso, as mensagens permanecem na memória e a pressão de retrocesso é aplicada aos clientes à medida que o uso de memória atinge o limite definido pelo limite da fila de assinantes.

Note

O corretor MQTT escreve os dados no disco exatamente como recebidos dos clientes, sem encriptação adicional. Proteger o disco é essencial para proteger os dados que o corretor armazena.

Configurar o buffer de mensagens apoiado em disco

Para configurar o buffer de mensagens apoiado em disco, edite a diskBackedMessageBuffer secção no recurso Broker. Atualmente, esta configuração é suportada apenas usando a flag --broker-config-file quando se implementa Operações IoT do Azure usando o comando az iot ops create. Para mais informações, consulte o suporte da CLI Azure para configuração avançada de corretores MQTT.

Esta definição não pode ser alterada após a implementação. Para alterar a configuração do buffer de mensagens em disco, reimplante a instância IoT Operations.

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

Depois, implemente o IoT Operations com o --broker-config-file flag (outros parâmetros omitidos para brevidade):

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

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 limite de tamanho do emptyDir volume. Mas esta opção é a menos preferida devido às limitações do emptyDir volume.

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

Para obter uma melhor configuração do buffer de mensagens apoiado em disco, especifique uma reivindicação de volume efémero ou de volume persistente para montar um volume de armazenamento dedicado para o seu buffer de mensagens. Por exemplo:

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

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

Adapte as opções de buffer de mensagens do corretor ajustando as seguintes definições:

  • Configure o volume: Especifique um modelo de reclamação de volume para montar um volume de armazenamento dedicado para o seu buffer de mensagens.
  • Selecione uma classe de armazenamento: Defina a classe de armazenamento desejada usando a storageClassName propriedade.
  • Defina modos de acesso: Determine os modos de acesso de que precisa para o seu volume. Para mais informações, veja Modos de acesso a volumes persistentes.

Volume temporário

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

Para volume efémero, siga os conselhos na secção Considerações para fornecedores de armazenamento .

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

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

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

Volume persistente

O volume persistente é a opção preferida seguinte para o teu buffer de mensagens, depois do volume efémero.

Para volume persistente, siga os conselhos na secção Considerações para fornecedores de armazenamento .

O valor da propriedade persistentVolumeClaimSpec é usado como propriedade volumeClaimTemplates.spec das especificações StatefulSet das cadeias de backend.

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

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

volume vazio de Dir

Um volume vazio de Dir é a opção menos preferida após volume persistente.

Utilize um volume emptyDir apenas quando utilizar um cluster com quotas do sistema de ficheiros. Para mais informações, consulte o separador de quota de projetos do sistema de ficheiros. Se a funcionalidade não estiver ativada, o cluster faz varreduras periódicas que não impõem qualquer limite e permitem que o nó anfitrião preencha espaço no disco e marque todo o nó anfitrião como insalubre.

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

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

Considerações para fornecedores de armazenamento

Considere o comportamento do fornecedor de armazenamento escolhido, por exemplo, quando utiliza fornecedores como rancher.io/local-path. Se o fornecedor não suportar limites, preencher o volume consome o espaço em disco do nó. Este comportamento pode levar o Kubernetes a marcar o nó e todos os pods associados como pouco saudáveis. É fundamental compreender como o seu fornecedor de armazenamento se comporta nesses cenários.

Tip

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

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

Disabled

Se não quiser usar o buffer de mensagens apoiado em disco, não inclua essa diskBackedMessageBufferSettings propriedade no seu recurso Broker. Este comportamento é também o padrão.

Buffer de disco vs. persistência

O buffer de mensagens apoiado em disco e a persistência do broker escrevem ambos dados no disco, mas servem propósitos diferentes:

Feature Buffer de mensagens com backup de disco Persistência
Objetivo Descarregar filas de espera de assinantes da memória para disco quando se tornam demasiado grandes Preservar o estado crítico do broker (mensagens retidas, sessões, subscrições) durante os reinícios do pod
Durability Efémero — os dados perdem-se quando a cápsula sai Durável — os dados persistem após reinícios dos pods
Quando utilizar Subscritores lentos, sessões persistentes offline, interrupções de conectividade com a cloud Precisa de mensagens retidas ou estado de sessão para sobreviver aos reinícios do corretor
Âmbito dos dados Mensagens PUBLISH em filas de subscritores Mensagens retidas, metadados da fila de assinantes, dados de armazenamento de estado
Configuração diskBackedMessageBuffer no recurso do Broker Definições de persistência na implementação ou em tempo de execução

Note

O buffer de disco e a persistência podem ser usados em conjunto. A persistência garante que o estado sobrevive aos reinícios, enquanto o buffer do disco previne condições de falta de memória durante o funcionamento normal.

Passos seguintes

  • Last updated on