Diese Seite wurde von der Cloud Translation API übersetzt.

Speichermigration mit speicherrichtlinienbasierter Verwaltung

In diesem Dokument wird gezeigt, wie Sie Laufwerke mit 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 den Knoten der Steuerungsebene von Administratorclustern und Controlplane V2-Nutzerclustern verwendet werden
- Bootlaufwerke (VMDK-Dateien), die von allen Administratorcluster- und Nutzerclusterknoten verwendet werden
- vSphere-Volumes, die im Administratorcluster durch PV/PVCs dargestellt und von den 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 dem vSphere-CSI-Treiber bereitgestellt werden

Voraussetzungen für einen Administratorcluster

Der Administratorcluster muss eine Hochverfügbarkeits-Steuerungsebene haben. Wenn der Administratorcluster eine Steuerungsebene ohne Hochverfügbarkeit hat, migrieren Sie zu Hochverfügbarkeit, bevor Sie fortfahren.
Prüfen Sie, ob der Administratorcluster eine Hochverfügbarkeits-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)

Für den Cluster muss die automatische Knotenreparatur deaktiviert sein. Wenn die automatische Knotenreparatur aktiviert ist, deaktivieren Sie die automatische Knotenreparatur.
Der Cluster muss die Speicherrichtlinienbasierte Verwaltung (SPBM) verwenden. Wenn Ihr Cluster kein SPBM verwendet, erstellen Sie eine Speicherrichtlinie, bevor Sie fortfahren.

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.

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

Wenn Ihr Cluster von einer alten Version von Google Distributed Cloud aktualisiert wurde, enthält er möglicherweise PV/PVCs, die vom integrierten vSphere-Volume-Plug-in bereitgestellt wurden. Diese Art von Volume wird möglicherweise von einem Knoten der Steuerungsebene eines Kubeception-Nutzerclusters oder von einer Arbeitslast verwendet, 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 sich an, welche Bereitsteller sie verwenden:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
```
Wenn die Spalte PROVISIONER in der Ausgabe den Wert kubernetes.io/vsphere-volume hat, verwenden die mit dieser Speicherklasse erstellten PVCs das integrierte vSphere-Volume-Plug-in. StatefulSets, die diese PV/PVCs verwenden, migrieren zum vSphere-CSI-Treiber.

Speichermigration ausführen

Google Distributed Cloud unterstützt zwei Kategorien der Speichermigration:

Storage vMotion für VMs, wodurch VM-Speicher verschoben wird, einschließlich angehängter vSphere-CNS-Volumes, die von auf einem Knoten ausgeführten Pods verwendet werden, sowie von VMDKs, die von diesen an die Knoten angehängten VM-CNS-Volumes verwendet werden
Verschiebung von CNS-Volumes, wodurch angegebene vSphere CNS-Volumes ohne vMotion-Speicher-vMotion für VMs in einen kompatiblen Datenspeicher 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 Administratorworkstation ausführen:

Fügen Sie Ihrer Speicherrichtlinie in Ihrer vSphere-Umgebung Ihre Zieldatenspeicher hinzu.
Migrieren Sie in Ihrer vSphere-Umgebung Cluster-VMs mithilfe des alten Datenspeichers zum neuen Datenspeicher. Eine Anleitung dazu finden Sie unter Virtuelle Maschine zu einer neuen Compute-Ressource und einem neuen Speicher migrieren.

Prüfen Sie auf Ihrer Administratorworkstation, 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 an die VMs angehängten Laufwerke. 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 zum Zieldatenspeicher migriert wurden.

Führen Sie auf Ihrer Administratorworkstation 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 der Anleitung unter Container-Volumes in vSphere migrieren folgen. Dies ist möglicherweise einfacher, wenn Sie nur CNS-Volumes im alten Datenspeicher haben.

Aktualisieren Sie bei Bedarf die Speicherrichtlinien

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