Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Longhorn V2 Data Engine

O Longhorn V2 Data Engine aproveita o poder do Storage Performance Development Kit (SPDK) para reduzir significativamente a latência de E/S enquanto aumenta IOPS e throughput. O resultado é uma solução de armazenamento de alto desempenho capaz de atender a diversas demandas de carga de trabalho.

O Longhorn V2 Data Engine é um Experimental recurso e não deve ser utilizado em um ambiente de produção.

Pré-requisitos

Cada nó com um Longhorn V2 Data Engine ativo requer os seguintes recursos dedicados:

  • 1 núcleo de CPU para uso pelo pod do gerenciador de instâncias Longhorn

  • 2 GiB de RAM (alocada como 1024 × 2 GiB de páginas grandes)

  • Pelo menos um disco NVMe local para armazenamento de dados

Limitações

O Longhorn V2 Data Engine atualmente não suporta as seguintes operações:

  • Criação e uso de imagem de base

  • Criptografia de volume

SSDs e outros discos não NVMe são gerenciados usando o driver SPDK AIO bdev, que não suporta a operação de unmap. Se você estiver usando discos não NVMe, evite realizar o trim no sistema de arquivos, pois isso resulta em erros de E/S e máquinas virtuais pausadas. Por exemplo, ao criar um sistema de arquivos ext4 em uma máquina virtual Linux, use mkfs.ext4 -E nodiscard /dev/vdb (assumindo que /dev/vdb é o caminho do seu dispositivo). Em máquinas virtuais Windows, você pode desativar o trim para NTFS executando o comando fsutil behavior set disabledeletenotify NTFS 1.

Uso

O Longhorn V2 Data Engine está disponível apenas para volumes e imagens recém-criados. Volumes existentes, imagens de máquinas virtuais e volumes raiz de máquinas virtuais continuarão a usar o V1 Data Engine.

  1. Na interface SUSE Virtualization, vá para Configurações → Avançadas.

  2. Defina longhorn-v2-data-engine-enabled como true.

    SUSE Virtualization carrega automaticamente os módulos do kernel necessários pelo Longhorn V2 Data Engine e tenta alocar 1024 × 2 MiB de páginas grandes (por exemplo, 2 GiB de RAM) em todos os nós.

    Alterar esta configuração reinicia automaticamente o RKE2 em todos os nós, mas não afeta as cargas de trabalho de máquinas virtuais em execução.

    Se você encontrar mensagens de erro que incluem a frase "capacidade de hugepages-2Mi insuficiente", aguarde um tempo para que o erro seja resolvido. Se o erro persistir, reinicie os nós afetados.

    Para desativar o Longhorn V2 Data Engine em nós específicos (por exemplo, nós com menos recursos de processamento e memória), vá para a tela Hosts e adicione o seguinte rótulo aos nós-alvo:

    • rótulo: node.longhorn.io/disable-v2-data-engine

    • valor: true

  3. Vá para a tela Hosts e, em seguida, adicione discos extras a cada nó conforme descrito em Gerenciamento de Múltiplos Discos.

    Defina o Provisioner de cada disco extra como Longhorn V2 (CSI).

    SUSE Virtualization define o Driver de Disco Longhorn como auto para que os discos NVMe usem o driver SPDK NVMe bdev, que oferece o melhor desempenho e também suporta operações avançadas, como trim (também conhecido como descarte).

    SSDs e outros discos não-NVMe são gerenciados usando o driver SPDK AIO bdev, que requer um tamanho de disco que seja um múltiplo par de 4096 bytes. Discos não-NVMe que não atendem a esse requisito de tamanho não podem ser adicionados. Além disso, o driver SPDK AIO bdev não suporta a operação de unmap. Se você estiver usando discos não NVMe, evite realizar o trim no sistema de arquivos, pois isso resulta em erros de E/S e máquinas virtuais pausadas.

  4. Vá para Classes de → Armazenamento Avançadas e, em seguida, adicione uma nova StorageClass conforme descrito em Criando uma StorageClass.

    Defina o Provisioner como Longhorn V2 (CSI).

  5. Use a nova StorageClass ao criar o seguinte:

    • Volumes (seja na tela Volumes ou durante a criação de máquinas virtuais)

    • Imagens (na tela Imagens)

      Volumes e imagens criados usando a nova StorageClass são suportados pelo Longhorn V2 Data Engine.

Atualizando de SUSE Virtualization v1.4.x

SUSE Virtualization v1.4.x, que usa SUSE Storage v1.7.x, não consegue migrar máquinas virtuais com volumes V2 anexados. Além disso, o V2 Data Engine não pode ser usado para imagens de máquinas virtuais e volumes de inicialização. Essas limitações não existem na versão SUSE Virtualization v1.5.0 e versões posteriores, que usam a versão SUSE Storage v1.8.1 e posteriores. No entanto, isso se aplica apenas a volumes e imagens que são criados após a atualização do SUSE Virtualization.

Em StorageClasses V2 criadas usando SUSE Virtualization v1.4.x, a opção migratable é definida como false. Como todas as outras propriedades de StorageClass, isso não pode ser alterado uma vez definido. Da mesma forma, volumes V2 criados usando SUSE Virtualization v1.4.x permanecem não migráveis após a atualização. Se você usou o V2 Data Engine na versão SUSE Virtualization v1.4.x e depois atualizar para SUSE Virtualization v1.5, você deve criar uma nova StorageClass V2. A opção migratable é definida como true por padrão, então volumes e imagens criados usando essa nova StorageClass V2 podem ser migrados ao vivo.

  • Se você estiver usando o driver SPDK AIO bdev (especificamente, se os discos foram adicionados usando /dev/sd* caminhos de dispositivo), os volumes V2 criados antes da atualização se tornam inutilizáveis e não podem ser recuperados após a atualização. Para mais informações, veja problema #10461.

  • Se você estiver usando o driver SPDK NVMe bdev (especificamente, se os discos foram adicionados usando /dev/nvme* caminhos de dispositivo), os volumes V2 criados antes da atualização ainda funcionarão. No entanto, esses volumes continuarão a usar o motor SUSE Storage v1.7.x e permanecerão não migráveis. Você pode exportar os dados e criar novos volumes migráveis, se necessário.

  • Todas as máquinas virtuais com volumes V2 anexados devem ser paradas antes de iniciar o upgrade. Volumes V2 ativos farão com que o processo de upgrade trave durante a fase "atualizando os serviços do sistema". Os logs do pod apply-manifests mostrarão mensagens repetidas semelhantes às seguintes:

    instance-manager (aio)(v2) (image=longhornio/longhorn-instance-manager:v1.8.1) state is not running on node harvester-node-0, will retry...

    Parar todas as Máquinas Virtuais que estão usando volumes V2 permitirá que o upgrade prossiga.

Se você estiver usando o driver SPDK NVMe bdev (especificamente, se os discos foram adicionados usando caminhos de dispositivo /dev/nvme*) e volumes V2 não migráveis estão anexados a máquinas virtuais existentes, você pode transitar para volumes migráveis ao vivo realizando os seguintes passos:

  1. Pare as máquinas virtuais.

  2. Exporte cada volume V2 anexado para uma imagem que usa a nova StorageClass V2 (com a opção migratable definida como true).

  3. Uma vez que os volumes são exportados para imagens, edite a máquina virtual e execute as seguintes ações na aba Volumes:

    • Remova os volumes V2 existentes.

    • Adicione as imagens que foram criadas a partir dos volumes exportados.

  4. Inicie as máquinas virtuais.

    Esta etapa pode demorar um pouco, dependendo da quantidade de dados a serem copiados.