Skip to main content
NetApp Backup and Recovery
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Migra l'archivio del catalogo Search and Restore su ONTAP NFS

Collaboratori netapp-mwallis
PDF

Per migliorare le prestazioni di Search and Restore in una distribuzione locale della NetApp Console, migra lo storage dell'indice del catalogo dalla classe di storage predefinita del cluster a una condivisione NFS supportata da ONTAP. L'indice del catalogo supporta Search and Restore e una NFS supportata da ONTAP può offrire miglioramenti delle prestazioni misurabili.

Prima di iniziare

Assicurati di avere a disposizione quanto segue prima di iniziare:

  • Un StorageClass NFS ONTAP configurato nel cluster e capacità sufficiente sul sistema ONTAP.

  • Credenziali di amministratore del cluster con autorizzazioni per ottenere, creare, applicare, eseguire, applicare patch, scalare ed eliminare risorse.

  • Un backup validato dei dati nel PVC di origine (fai un'istantanea o copiali altrove prima della migrazione).

Riduci il numero dei worker

Elenca le distribuzioni dei worker e ridimensionali ciascuna a zero repliche.

  1. Elenca tutte le distribuzioni dei worker del catalogo:

    kubectl get deploy -n cbs -o name | grep '/cloudmanager-cbs-catalog-worker-'

  2. Riduci a zero le repliche di ogni deployment di worker:

    for d in $(kubectl get deploy -n cbs -o name | grep '/cloudmanager-cbs-catalog-worker-'); do
  kubectl scale "$d" --replicas=0 -n cbs
done

  3. Conferma che non siano rimasti pod worker:

    kubectl get pods -n cbs | grep cloudmanager-cbs-catalog-worker- || echo "no worker pods running"
Monta il volume ONTAP sulla distribuzione locale di NetApp Console e copia i dati dal pod

  1. Monta l'esportazione NFS di ONTAP su un punto di montaggio locale nella VM creata quando è stata distribuita l'OVA di distribuzione locale della NetApp Console.

  2. Copia i dati dal pod del coordinatore in esecuzione nel mount ONTAP, senza directory intermedie. Il coordinatore deve essere ancora in esecuzione.

    Nota Copia il contenuto nella root del volume, non in una sottodirectory. Il volume ONTAP è la nuova /opt/netapp/cbs/catalog/shared directory. I dati devono trovarsi nella root del volume così l'app li trova agli stessi percorsi (ad esempio /opt/netapp/cbs/catalog/shared/cbs/<DATASET_NAME>/…​). Il formato del comando tar nei seguenti comandi trasferisce il contenuto della directory (inclusi i file nascosti) nella root del mount, evitando una cartella shared annidata.

  3. Monta l'esportazione NFS di ONTAP in un punto di montaggio locale sulla distribuzione locale di NetApp Console. Usa lo stesso server/percorso che userai in seguito in pv.yaml:

    sudo mkdir -p /mnt/ontap_nfs_vol
sudo mount -t nfs 10.x.x.x:/my_nfs_vol /mnt/ontap_nfs_vol   # ONTAP SVM data LIF IP : junction path

  4. Copia il volume condiviso del pod nella posizione di montaggio ONTAP:

    POD=$(kubectl get pod -n cbs -l app=cloudmanager-cbs-catalog -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n cbs "$POD" -- tar cf - -C /opt/netapp/cbs/catalog/shared . \
  | sudo tar xf - -C /mnt/ontap_nfs_vol

  5. Imposta la proprietà in modo che corrisponda all'identità del pod:

    sudo chown -R 10001:10001 /mnt/ontap_nfs_vol

  6. Verifica che i dati siano stati copiati nella directory principale del volume (dovresti vedere la cartella "cbs" direttamente sotto il punto di montaggio, non una sottocartella "shared/"):

    ls -la /mnt/ontap_nfs_vol

  7. Verifica la copia e poi smontala (il pod la monterà tramite il PVC più tardi):

    sudo umount /mnt/ontap_nfs_vol

  8. Riduci le dimensioni del coordinatore. Ad esempio:

    kubectl scale deployment cloudmanager-cbs-catalog --replicas=0 -n cbs
kubectl rollout status deployment/cloudmanager-cbs-catalog -n cbs
Elimina il vecchio PVC e PV

  1. Acquisisci le informazioni sul PV associato e poi elimina il vecchio PVC e PV:

    PV=$(kubectl get pvc cloudmanager-cbs-catalog-shared-pvc -n cbs -o jsonpath='{.spec.volumeName}')
kubectl delete pvc cloudmanager-cbs-catalog-shared-pvc -n cbs
kubectl delete pv "$PV"
Crea il PV e il PVC statici di ONTAP

  1. Crea i seguenti oggetti YAML PV e PVC:

    pv.yaml

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: ontap-manual-pv
  labels:
    volume: ontap-nfs-share # Used by the PVC selector to find this exact volume
spec:
  capacity:
    storage: 50Gi # Match or remain under the actual ONTAP volume size
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany # Allows multiple Pods to share the NFS mount
  persistentVolumeReclaimPolicy: Retain # Retains ONTAP data if the PVC is deleted
  storageClassName: "" # Leave blank for manual/static provisioning
  nfs:
    server: 10.x.x.x # Replace with your ONTAP SVM data LIF IP address
    path: /my_nfs_vol # Replace with your ONTAP junction path

    pvc.yaml

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloudmanager-cbs-catalog-shared-pvc
  annotations:
    "helm.sh/resource-policy": keep
spec:
  accessModes:
    - ReadWriteMany # Must match the PV's access mode
  resources:
    requests:
      storage: 50Gi # Must be <= the PV capacity (50Gi)
  storageClassName: "" # Explicitly matches the empty StorageClass on the PV
  selector:
    matchLabels:
      volume: ontap-nfs-share # Forces binding to the specific PV above

  2. Applica gli oggetti YAML applicando prima il PV e poi il PVC (il PV deve esistere perché il selettore di etichette del PVC possa associarsi). Poi verifica che la claim del PVC sia associata:

    kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml -n cbs
kubectl get pvc cloudmanager-cbs-catalog-shared-pvc -n cbs   # expect STATUS: Bound

  3. Scala il coordinatore fino a 1 replica:

    kubectl scale deployment cloudmanager-cbs-catalog --replicas=1 -n cbs
kubectl rollout status deployment/cloudmanager-cbs-catalog -n cbs

  4. Se hai ridimensionato manualmente i worker e questi non sono stati eliminati automaticamente, ridimensionali manualmente (potrebbe non essere necessario, perché i worker vengono normalmente forniti automaticamente):

    for d in $(kubectl get deploy -n cbs -o name | grep '/cloudmanager-cbs-catalog-worker-'); do
  kubectl scale "$d" --replicas=1 -n cbs
done

  5. Verifica lo stato del mount e dei dati. Assicurati che i dati siano presenti e di proprietà dell'utente e del gruppo 10001:10001:

    POD=$(kubectl get pod -n cbs -l app=cloudmanager-cbs-catalog -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n cbs "$POD" -- mount | grep /opt/netapp/cbs/catalog/shared
kubectl exec -n cbs "$POD" -- ls -la /opt/netapp/cbs/catalog/shared
Nota

  • Politica di recupero Retain: eliminando il PVC non cancellerai i dati ONTAP; il PV rilasciato dovrà essere ripulito manualmente se decidi di effettuare nuovamente il provisioning.

  • Mantieni Helm sincronizzato: poiché il PVC viene normalmente generato dal chart, un futuro helm upgrade potrebbe provare a ricrearlo o modificarlo. Per mantenere questo PVC ONTAP manuale, punta il chart agli stessi valori (storageClass: "" (corrispondenti a dimensioni/modalità di accesso) oppure escludi il PVC condiviso dalla release.

  • Se esegui manualmente helm uninstall e poi provi a reinstallare, il PV verrà installato con lo stesso nome e causerà un conflitto di nomi.