27 V2 Data Engine de SUSE Storage #

Antes de habilitar el V2 Data Engine, revisad los requisitos de V2 en sentido ascendente. En particular, cada nodo que pueda alojar una réplica V2 requiere:

Longhorn recomienda utilizar un solo motor de datos una vez completada la migración. Ejecutar ambos motores crea gestores de instancias independientes y, por tanto, consume CPU y memoria adicionales.

Preparad los dispositivos de bloque necesarios antes de aprovisionar volúmenes de aplicación. Registrad cada dispositivo como un disco block en su nodo de Longhorn utilizando la interfaz de usuario de SUSE Storage o actualizando el recurso nodes.longhorn.io correspondiente.

Para un clúster nuevo que no tenga volúmenes V1, utilizad los siguientes valores de Helm:

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

Para un clúster existente con volúmenes V1, mantened ambos motores habilitados durante la migración:

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

Aplicad los valores con vuestro flujo de trabajo habitual de ampliación o actualización de Helm. Por ejemplo:

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

En una instalación existente, confirmad que el ajuste de Longhorn en ejecución estaba habilitado. Si permanece deshabilitado después de la actualización de Helm, habilitadlo explícitamente:

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

Atención

No deshabilitéis el V1 Data Engine mientras queden volúmenes V1 en el clúster. Al actualizar una versión existente, confirmad también que --reuse-values no conserva un valor persistence.dataEngine anterior de v1.

Cread una StorageClass V2 dedicada en lugar de cambiar una StorageClass existente in situ:

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 hacer que V2 sea el valor predeterminado para los PVC que no especifiquen storageClassName, moved la anotación predeterminada a la nueva 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

Este cambio solo afecta a los volúmenes recién aprovisionados. No cambia el motor de datos de los volúmenes existentes.

Verificad los ajustes, la StorageClass, los discos y los volúmenes:

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'

SUSE Storage 1.12.1 no admite la conversión de un volumen existente de V1 a V2 in situ. Planificad una ventana de mantenimiento y migrad cada carga de trabajo a un nuevo volumen V2.

Para un volumen de sistema de archivos que no esté gestionado por una base de datos u otra aplicación que requiera una migración consciente de la consistencia, un único pod de mantenimiento puede montar la fuente V1 en modo de solo lectura y el destino V2 en modo de lectura-escritura:

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>

Aviso

El Job de copia es solo un ejemplo genérico de sistema de archivos. Utilizad la copia de seguridad y restauración nativa de la aplicación o la replicación para bases de datos, volúmenes de bloques sin procesar y aplicaciones con sus propios requisitos de consistencia. Verificad la propiedad, los permisos, los atributos extendidos y los datos de la aplicación antes de eliminar el PVC de origen.

Después de migrar cada carga de trabajo, confirmad que no quedan volúmenes V1:

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

A continuación, podéis desactivar el motor de datos V1 en los valores de Helm y actualizar la versión:

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

Si el ajuste de ejecución permanece habilitado después de la actualización de Helm, desactivadlo explícitamente:

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

Ejecutad de nuevo el comando de inventario de volúmenes y confirmad que no se ha pasado por alto ningún volumen V1 antes de eliminar cualquier almacenamiento de nodo específico de V1.

Antes de mover una carga de trabajo a V2, revisad la comparativa de características de V1 y V2. Las siguientes limitaciones son especialmente relevantes para SUSE Storage 1.12.1: