Speichermigration mit richtlinienbasierter Verwaltung

In diesem Dokument wird gezeigt, wie Sie Laufwerke mithilfe von Storage Policy Based Management (SPBM) von einem vSphere-Datenspeicher zu einem anderen vSphere-Datenspeicher migrieren.

1.29: Allgemein verfügbar
1.28: Vorschau
1.16: Nicht verfügbar

Sie können folgende Speicherarten migrieren:

  • Speicher für Systemkomponenten, die von Google Distributed Cloud verwaltet werden, darunter:

    • Datenlaufwerke (VMDK-Dateien), die von Knoten der Steuerungsebene von Administratorclustern und Steuerungsebenen-V2-Nutzerclustern verwendet werden

    • Bootlaufwerke (VMDK-Dateien), die von allen Administratorcluster- und Nutzerclusterknoten verwendet werden

    • vSphere-Volumes, die durch PV/PVCs im Administratorcluster dargestellt und von Komponenten der Steuerungsebene von kubeception-Nutzerclustern verwendet werden.

  • Speicher für Arbeitslasten, die Sie auf Nutzercluster-Worker-Knoten mit PV/PVCs bereitstellen, die vom integrierten vSphere-Volume-Plug-in oder vom vSphere-CSI-Treiber zur Verfügung gestellt werden

Voraussetzungen für einen Administratorcluster

  1. Der Administratorcluster muss eine Hochverfügbarkeits-Steuerungsebene haben. Wenn Ihr Administratorcluster eine Steuerungsebene ohne Hochverfügbarkeit hat, migrieren Sie zu HA, bevor Sie fortfahren.

  2. Prüfen Sie, ob der Administratorcluster eine HA-Steuerungsebene hat:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
    

    Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Administratorclusters.

    Achten Sie darauf, dass in der Ausgabe drei Knoten der Steuerungsebene angezeigt werden. Beispiel:

    admin-cp-1   Ready    control-plane,master ...
    admin-cp-2   Ready    control-plane,master ...
    admin-cp-3   Ready    control-plane,master ...
    

Voraussetzungen für alle Cluster (Administrator und Nutzer)

  1. Für den Cluster muss die automatische Knotenreparatur deaktiviert sein. Wenn die automatische Knotenreparatur aktiviert ist, deaktivieren Sie die automatische Knotenreparatur.

  2. Der Cluster muss Speicherrichtlinienbasierte Verwaltung (Storage Policy Based Management, SPBM) verwenden. Wenn Ihr Cluster nicht SPBM verwendet, erstellen Sie eine Speicherrichtlinie, bevor Sie fortfahren.

  3. Prüfen Sie, ob der Cluster SPBM verwendet:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \
      -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'
    

    (Nur Nutzercluster) Prüfen Sie, ob die Knotenpools SPBM verwenden:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremnodepools --namespace USER_CLUSTER_NAME-gke-onprem-mgmt \
      -ojson | jq '.items[] | {name: .metadata.name, datastore: .spec.vsphere.datastore, storagePolicyName: .spec.vsphere.storagePolicyName}'
    

    Ersetzen Sie Folgendes:

    • CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Clusters (Administrator oder Nutzer).

    • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters

    • USER_CLUSTER_NAME: der Name des Nutzerclusters

    Wenn in der Ausgabe das Feld datastore leer und das Feld storagePolicyName nicht leer ist, verwendet der Cluster SPBM.

  4. Der Cluster darf nicht das integrierte vSphere-Volume-Plug-in verwenden.

    Wenn Ihr Cluster von einer alten Version von Google Distributed Cloud aktualisiert wurde, kann PV/PVCs enthalten, die vom Integriertes vSphere-Volume-Plug-in bereitgestellt sein könnten. Diese Art von Volume kann von einem Knoten der Steuerungsebene eines kubeception-Nutzerclusters oder einer Arbeitslast verwendet werden, die Sie auf einem Worker-Knoten erstellt haben.

    Liste aller PVCs und ihrer StorageClasses:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces  \
       -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'
    

    Listen Sie alle StorageClasses auf und sehen Sie, welche Bereitsteller sie verwenden:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
    

    Wenn in der Ausgabe die Spalte PROVISIONER den Wert kubernetes.io/vsphere-volume hat, dann verwenden die mit dieser Speicherklasse erstellten PVCs das integrierte vSphere-Volume-Plug-in. Für StatefulSets, die diese PV/PVCs verwenden, migrieren Sie sie zum vSphere-CSI-Treiber.

Speichermigration ausführen

Google Distributed Cloud unterstützt zwei Kategorien der Speichermigration:

  • Storage vMotion für VMs, das den VM-Speicher verschiebt, einschließlich der angehängten vSphere-CNS-Volumes, die von Pods auf einem Knoten verwendet werden, und VMDKs, die von diesen VM-CNS-Volumes verwendet werden, die an die Knoten angehängt sind

  • Verschiebung des CNS-Volumes, wodurch angegebene vSphere CNS-Volumes in ein kompatiblen Datenspeicher ohne vMotion-Speicherung für VMs verschoben werden

Storage vMotion für VMs ausführen

Die Migration umfasst Schritte, die Sie in Ihrer vSphere-Umgebung ausführen, und Befehle, die Sie auf Ihrer Administrator-Workstation ausführen:

  1. Fügen Sie in der vSphere-Umgebung Ihre Zieldatenspeicher zu Ihrer Speicherrichtlinie hinzu.

  2. Migrieren Sie Cluster-VMs in Ihrer vSphere-Umgebung mit dem alten Datenspeicher zum neuen Datenspeicher. Eine Anleitung finden Sie unter Virtuelle Maschine zu einer neuen Compute-Ressource und einem neuen Speicher migrieren.

  3. Prüfen Sie auf Ihrer Administrator-Workstation, ob die VMs erfolgreich zum neuen Datenspeicher migriert wurden.

    Rufen Sie die Maschinenobjekte im Cluster ab:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml

    In der Ausgabe sehen Sie unter status.disks die Laufwerke, die an die VMs angehängt sind. Beispiel:

    status:
    addresses:
    – address: 172.16.20.2
      type: ExternalIP
    disks:
    – bootdisk: true
      datastore: pf-ds06
      filepath: me-xvz2ccv28bf9wdbx-2/me-xvz2ccv28bf9wdbx-2.vmdk
      uuid: 6000C29d-8edb-e742-babc-9c124013ba54
    – datastore: pf-ds06
      filepath: anthos/gke-admin-nc4rk/me/ci-bluecwang-head-2-data.vmdk
      uuid: 6000C29e-cb12-8ffd-1aed-27f0438bb9d9
    

    Prüfen Sie, ob alle Laufwerke aller Maschinen im Cluster in den Zieldatenspeicher migriert wurden.

  4. Führen Sie auf Ihrer Administratorworkstation den Befehl gkectl diagnose aus, um zu prüfen, ob der Cluster fehlerfrei ist.

CNS Relocation APIs zum Verschieben von CNS-Volumes aufrufen

Wenn Sie nur die vom vSphere-CSI-Treiber bereitgestellten CNS-Volumes verschieben möchten, können Sie den Anweisungen in Container-Volumes in vSphere migrieren folgen. Dies ist möglicherweise einfacher, wenn Sie nur CNS-Volumes im alten Datenspeicher haben.

Speicherrichtlinie bei Bedarf aktualisieren

Aktualisieren Sie in Ihrer vSphere-Umgebung die Speicherrichtlinie, um die alten Datastores auszuschließen. Andernfalls werden neue Volumes und neu erstellte VMs möglicherweise einem alten Datenspeicher zugewiesen.