27 SUSE Storage V2 Data Engine #

Antes de habilitar o V2 Data Engine, revise os requisitos upstream do V2. Em particular, cada nó que pode hospedar uma réplica V2 requer:

O Longhorn recomenda usar apenas um Data Engine após a conclusão da migração. Executar ambos os Data Engines cria gerenciadores de instâncias separados e, portanto, consome CPU e memória adicionais.

Prepare os dispositivos de bloco necessários antes de provisionar volumes de aplicativo. Registre cada dispositivo como um disco block em seu nó Longhorn usando a interface do usuário do SUSE Storage, ou atualizando o recurso nodes.longhorn.io correspondente.

Para um novo cluster que não possui volumes V1, use os seguintes valores de Helm:

defaultSettings:
  v1DataEngine: false
  v2DataEngine: true
persistence:
  dataEngine: v2

Para um cluster existente com volumes V1, mantenha ambos os Data Engines habilitados durante a migração:

defaultSettings:
  v1DataEngine: true
  v2DataEngine: true
persistence:
  dataEngine: v2

Aplique os valores com seu fluxo de trabalho normal de implantação ou atualização do Helm. Por exemplo:

helm upgrade --install longhorn oci://dp.apps.rancher.io/charts/suse-storage \
  --version 1.12.1 \
  --namespace longhorn-system \
  --create-namespace \
  --reuse-values \
  --values suse-storage-v2-values.yaml

Em uma instalação existente, confirme se a configuração do Longhorn em execução estava habilitada. Se ela permanecer desabilitada após o upgrade do Helm, habilite-a explicitamente:

kubectl -n longhorn-system patch settings.longhorn.io v2-data-engine \
  --type merge --patch '{"value":"true"}'

Cuidado

Não desabilite o V1 Data Engine enquanto houver volumes V1 no cluster. Ao atualizar uma versão existente, confirme também que --reuse-values não preserva um valor persistence.dataEngine antigo de v1.

Crie um StorageClass V2 dedicado em vez de alterar um StorageClass existente in loco:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-v2
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  dataEngine: "v2"
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fsType: "ext4"

Para tornar o V2 o padrão para PVCs que não especificam storageClassName, mova a anotação padrão para o novo StorageClass:

kubectl annotate storageclass longhorn \
  storageclass.kubernetes.io/is-default-class="false" --overwrite

kubectl annotate storageclass longhorn-v2 \
  storageclass.kubernetes.io/is-default-class="true" --overwrite

Essa alteração afeta apenas volumes recém-provisionados. Ela não altera o Data Engine dos volumes existentes.

Verifique as configurações, StorageClass, discos e volumes:

kubectl -n longhorn-system get settings.longhorn.io \
  v1-data-engine v2-data-engine

kubectl get storageclass longhorn-v2 \
  -o jsonpath='dataEngine={.parameters.dataEngine}{"\n"}'

kubectl -n longhorn-system get nodes.longhorn.io

kubectl -n longhorn-system get volumes.longhorn.io \
  -o custom-columns='NAME:.metadata.name,ENGINE:.spec.dataEngine,STATE:.status.state,ROBUSTNESS:.status.robustness'

O SUSE Storage 1.12.1 não oferece suporte à conversão de um volume existente de V1 para V2 in loco. Planeje uma janela de manutenção e migre cada carga de trabalho para um novo volume V2.

Para um volume de sistema de arquivos que não é gerenciado por um banco de dados ou outro aplicativo que exija uma migração com reconhecimento de consistência, um único pod de manutenção pode montar a origem V1 como somente leitura e o destino V2 como leitura/gravação:

apiVersion: batch/v1
kind: Job
metadata:
  name: copy-v1-to-v2
  namespace: <application-namespace>
spec:
  backoffLimit: 3
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: copy
          image: registry.suse.com/bci/bci-micro:latest
          command:
            - /bin/bash
            - -c
            - |
              set -euo pipefail
              cp -a /source/. /destination/
              sync
          volumeMounts:
            - name: source
              mountPath: /source
              readOnly: true
            - name: destination
              mountPath: /destination
      volumes:
        - name: source
          persistentVolumeClaim:
            claimName: <v1-pvc-name>
        - name: destination
          persistentVolumeClaim:
            claimName: <v2-pvc-name>

Atenção

O Job de cópia é apenas um exemplo genérico de sistema de arquivos. Use backup e restauração nativos do aplicativo ou replicação para bancos de dados, volumes de bloco brutos e aplicativos com seus próprios requisitos de consistência. Verifique a propriedade, as permissões, os atributos estendidos e os dados do aplicativo antes de excluir o PVC de origem.

Após a migração de cada carga de trabalho, confirme se nenhum volume V1 permanece:

kubectl -n longhorn-system get volumes.longhorn.io \
  -o custom-columns='NAME:.metadata.name,ENGINE:.spec.dataEngine,STATE:.status.state'

Você pode então desabilitar o V1 Data Engine nos valores do Helm e atualizar a versão:

defaultSettings:
  v1DataEngine: false
  v2DataEngine: true
persistence:
  dataEngine: v2

Se a configuração de execução permanecer habilitada após o upgrade do Helm, desabilite-a explicitamente:

kubectl -n longhorn-system patch settings.longhorn.io v1-data-engine \
  --type merge --patch '{"value":"false"}'

Execute o comando de inventário de volume novamente e confirme se nenhum volume V1 foi negligenciado antes de remover qualquer armazenamento de nó específico para V1.

Antes de mover uma carga de trabalho para a V2, analise a comparação de recursos entre V1 e V2. As seguintes limitações são especialmente relevantes para o SUSE Storage 1.12.1: