Anthos-Cluster auf VMware ist jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Speicherrichtlinie konfigurieren

In diesem Dokument wird gezeigt, wie Sie eine VM-Speicherrichtlinie für einen GKE on VMware-Cluster konfigurieren.

Überblick

In vSphere lässt sich mit Storage Policy Based Management (SPBM) der Speicher an die Anwendungsanforderungen virtueller Maschinen anpassen. Es bietet ein Speicherrichtlinien-Framework, das als zentrales, einheitliches Steuerfeld für eine breite Palette von Datendiensten und Speicherlösungen dient.

In einem Anthos-Cluster auf VMware können Sie Speicherrichtlinien als Alternative zur Angabe von Datenspeichern angeben. Sie definieren Speicherrichtlinien basierend auf Ihren Anwendungsanforderungen. Anschließend wählt vSphere die Datenspeicher automatisch aus und verwaltet sie. Dies kann den Aufwand und Wartungsaufwand reduzieren, die mit dem Speicher verbunden sind.

Übernahme

Sie können eine Speicherrichtlinie für einen Nutzercluster, einen Knotenpool in einem Nutzercluster oder eine Reihe von Knoten der Steuerungsebene in einem Nutzercluster angeben. Sie können auch eine Speicherrichtlinie für einen Administratorcluster angeben, sofern der Administratorcluster eine Steuerungsebene mit Hochverfügbarkeit und keine Windows-Knotenpools hat.

Wenn Sie eine Speicherrichtlinie für einen Nutzercluster angeben, wird die Richtlinie von den Knotenpools im Nutzercluster übernommen. Wenn Sie eine Speicherrichtlinie für einen einzelnen Knotenpool angeben, wird diese Richtlinie anstelle der Speicherrichtlinie auf Clusterebene verwendet. Wenn Sie einen Datenspeicher für einen einzelnen Knotenpool angeben, wird ebenfalls dieser Datenspeicher anstelle der Speicherrichtlinie auf Clusterebene verwendet.

In einem Nutzercluster, für den die Controlplane V2 aktiviert ist, wird die Speicherrichtlinie auf Clusterebene von den Knoten der Steuerungsebene übernommen. Wenn Sie eine Speicherrichtlinie oder einen Datenspeicher für die Knoten der Steuerungsebene angeben, wird diese Speicherrichtlinie oder dieser Datenspeicher anstelle der Speicherrichtlinie auf Clusterebene verwendet.

Speicherrichtlinien auf Datenspeicher anwenden

Sie können eine Speicherrichtlinie auf einen einzelnen Datenspeicher oder auf mehrere Datenspeicher anwenden. Wenn Sie eine Speicherrichtlinie auf mehrere Datenspeicher anwenden, können die Speicherressourcen für einen Administratorcluster, Nutzercluster oder Knotenpool auf die Datenspeicher verteilt werden.

Beispiel: Speicherrichtlinie und Nutzercluster erstellen

Dieser Abschnitt enthält ein Beispiel zum Erstellen einer Speicherrichtlinie und eines Nutzerclusters. Dieses Beispiel veranschaulicht, dass eine Speicherrichtlinie auf zwei Datenspeicher angewendet werden kann.

Tags auf Datenspeicher anwenden

Damit Sie die Schritte in diesem Beispiel ausführen können, muss Ihre vSphere-Umgebung mindestens zwei Datenspeicher haben.

Der vSphere-Cluster, der die Knoten für Ihren Nutzercluster hostet, muss Zugriff auf die Datenspeicher haben, die Sie für diese Übung verwenden möchten. Das wird durch eine Preflight-Prüfung bestätigt.

Das vCenter-Konto, das Sie zum Anwenden von Tags verwenden, muss auf dem vCenter-Server Root die folgenden vSphere-Tagging-Berechtigungen haben:

vSphere Tagging.Create vSphere Tag
vSphere-Tagging.vSphere-Tag-Kategorie erstellen
vSphere-Tagging.Assign oder Unassign vSphere Tag

Weisen Sie im vSphere-Client jedem Datenspeicher, den Sie für diese Übung verwenden möchten, dasselbe Tag zu. Eine Anleitung dazu finden Sie unter Datenspeichern Tags zuweisen.

Weitere Informationen finden Sie unter vSphere-Tags und -Attribute.

Speicherrichtlinie erstellen

Erstellen Sie im vSphere-Client eine VM-Speicherrichtlinie für die Tag-basierte Platzierung. Geben Sie in der Speicherrichtlinie das Tag an, das Sie auf die ausgewählten Datenspeicher angewendet haben. Eine Anleitung dazu finden Sie unter VM-Speicherrichtlinie für Tag-basierte Platzierung erstellen.

Weitere Informationen finden Sie unter VM-Speicherrichtlinie.

Wenn Sie einen vSAN-Datenspeicher verwenden, lesen Sie die Informationen unter vSAN-Speicherrichtlinie.

Nutzercluster erstellen

In dieser Übung erstellen Sie einen Nutzercluster mit einer Steuerungsebene mit Hochverfügbarkeit. Daher gibt es drei Knoten der Steuerungsebene. Zusätzlich zu den Knoten der Steuerungsebene gibt es sechs Worker-Knoten, drei in einem Knotenpool und drei in einem zweiten Knotenpool. Alle Knoten verwenden statische IP-Adressen.

Folgen Sie zuerst der Anleitung unter Nutzercluster erstellen (ControlPlane V2).

Beim Ausfüllen der Konfigurationsdatei des Nutzerclusters:

Legen Sie den Wert von vCenter.storagePolicyName auf den Namen einer vorhandenen Speicherrichtlinie fest. Legen Sie für vCenter.datastore keinen Wert fest.
Geben Sie zwei Knotenpools an. Geben Sie für den ersten Knotenpool weder einen Datenspeicher noch eine Speicherrichtlinie an. Legen Sie für den zweiten Knotenpool den Wert von vsphere.datastore auf den Namen eines vorhandenen Datenspeichers fest.

Beispiel für eine Clusterkonfigurationsdatei

Hier sehen Sie ein Beispiel für eine IP-Blockdatei und einen Teil einer Konfigurationsdatei für einen Nutzercluster.

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
    - ip: 172.16.21.3
    - ip: 172.16.21.4
    - ip: 172.16.21.5
    - ip: 172.16.21.6
    - ip: 172.16.21.7
    - ip: 172.16.21.8

user-cluster-yaml

apiVersion: v1
kind: UserCluster
...
vCenter:
  storagePolicyName: "my-storage-policy"
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.9"
      hostname: "cp-vm-1"
    - ip: "172.16.21.10"
      hostname: "cp-vm-2"
    - ip: "172.16.21.11"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
    - "172.16.21.30-172.16.21.39"
...
enableControlplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
- name: "worker-pool-2"
  vSphere:
    datastore: "my-np2-datastore"
...

Dies sind die wichtigsten Punkte, die im vorherigen Beispiel zu verstehen sind:

Die statischen IP-Adressen für die Worker-Knoten werden in einer IP-Blockdatei angegeben. Die IP-Blockdatei hat sieben Adressen, obwohl nur sechs Worker-Knoten vorhanden sind. Die zusätzliche IP-Adresse wird während des Clusterupgrades, der Aktualisierung und der automatischen Reparatur des Clusters benötigt.
Die statischen IP-Adressen für die drei Knoten der Steuerungsebene werden im Abschnitt network.controlPlaneIPBlock der Konfigurationsdatei des Nutzerclusters angegeben. In diesem Block wird keine zusätzliche IP-Adresse benötigt.
Das Feld masterNode.replicas ist auf 3 gesetzt, sodass drei Knoten der Steuerungsebene vorhanden sind. Unter masterNode ist für vsphere.datastore oder vsphere.storagePolicyName nichts angegeben. Daher verwenden die Knoten der Steuerungsebene die in vCenter.storagePolicyName angegebene Speicherrichtlinie.
Die Konfigurationsdatei des Nutzerclusters enthält einen Wert für vCenter.storagePolicy, aber keinen Wert für vCenter.datastore. Die angegebene Speicherrichtlinie wird von Knoten in jedem Pool verwendet, der keine eigene Speicherrichtlinie oder einen eigenen Datenspeicher angibt.
Unter node-pool-1 ist für vsphere.datastore oder vsphere.storagePolicyName nichts angegeben. Die Knoten in node-pool-1 verwenden also die in vCenter.storagePolicyName angegebene Speicherrichtlinie.
Unter node-pool-2 ist der Wert von vsphere.datastore my-np2-datastore. Daher nutzen die Knoten in node-pool-2 diesen einen Datenspeicher und nutzen keine Speicherrichtlinie.

Fahren Sie mit der Erstellung des Nutzerclusters wie unter Nutzercluster erstellen (Controlplane V2) beschrieben fort.

Nutzercluster in einem vom Administratorcluster getrennten Rechenzentrum erstellen

Ein Nutzercluster kann sich in einem vom Administratorcluster getrennten Rechenzentrum befinden. Die beiden Rechenzentren können dieselbe Instanz von vCenter Server oder unterschiedliche Instanzen von vCenter Server verwenden.

In diesem Abschnitt finden Sie ein Beispiel für das Erstellen eines Nutzerclusters, der eine separate Instanz von vCenter Server aus dem Administratorcluster verwendet. Da die Nutzer- und Administratorcluster separate Instanzen von vCenter Server verwenden, befinden sie sich ebenfalls in separaten Rechenzentren.

Folgen Sie zuerst der Anleitung unter Nutzercluster erstellen (ControlPlane V2).

Beim Ausfüllen der Konfigurationsdatei des Nutzerclusters:

Legen Sie den Wert von vCenter.storagePolicyName auf den Namen einer vorhandenen Speicherrichtlinie fest. Legen Sie für vCenter.datastore keinen Wert fest.
Geben Sie unter vCenter Werte für address, datacenter, cluster und resourcePool an.
Geben Sie einen Wert für network.vCenter.networkName an.
Geben Sie zwei Knotenpools an. Geben Sie für den ersten Knotenpool weder einen Datenspeicher noch eine Speicherrichtlinie an. Legen Sie für den zweiten Knotenpool den Wert von vsphere.datastore auf den Namen eines vorhandenen Datenspeichers fest.

Beispiel für eine Clusterkonfigurationsdatei

Hier sehen Sie ein Beispiel für eine IP-Blockdatei und einen Teil einer Konfigurationsdatei für einen Nutzercluster.

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
    - ip: 172.16.21.3
    - ip: 172.16.21.4
    - ip: 172.16.21.5
    - ip: 172.16.21.6
    - ip: 172.16.21.7
    - ip: 172.16.21.8

user-cluster-yaml

apiVersion: v1
kind: UserCluster
...
vCenter:
  address: "my-vcenter-server-2.my-domain.example"
  datacenter: "my-uc-data-center"
  cluster: "my-uc-vsphere-cluster"
  resourcePool: "my-uc-resource-pool"
  storagePolicyName: "my-storage-policy"
network:
  vCenter:
    networkName: "my-uc-network"
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.9"
      hostname: "cp-vm-1"
    - ip: "172.16.21.10"
      hostname: "cp-vm-2"
    - ip: "172.16.21.11"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
    - "172.16.21.30-172.16.21.39"
...
enableControlplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
- name: "worker-pool-2"
  vSphere:
    datastore: "my-np2-datastore"
...

Dies sind die wichtigsten Punkte, die im vorherigen Beispiel zu verstehen sind:

Die Konfigurationsdatei des Nutzerclusters enthält einen Wert für vCenter.storagePolicy, aber keinen Wert für vCenter.datastore. Die angegebene Speicherrichtlinie wird von Knoten in jedem Knotenpool verwendet, der keine eigene Speicherrichtlinie oder einen eigenen Datenspeicher angibt.
Unter vCenter sind Werte für address, datacenter, cluster und resourcePool angegeben. Daher verwendet der Nutzercluster einen anderen vCenter-Server, ein anderes Rechenzentrum, einen anderen vSphere-Cluster und einen anderen Ressourcenpool als vom Administratorcluster.
Für network.vCenter.networkName ist ein Wert angegeben.
Das Feld masterNode.replicas ist auf 3 gesetzt, sodass drei Knoten der Steuerungsebene vorhanden sind. Unter masterNode ist für vsphere.datastore oder vsphere.storagePolicyName nichts angegeben. Daher verwenden die Knoten der Steuerungsebene die in vCenter.storagePolicyName angegebene Speicherrichtlinie.
Unter node-pool-1 ist für vsphere.datastore oder vsphere.storagePolicyName nichts angegeben. Die Knoten in node-pool-1 verwenden also die in vCenter.storagePolicyName angegebene Speicherrichtlinie.
Unter node-pool-2 ist der Wert von vsphere.datastore my-np2-datastore. Daher nutzen die Knoten in node-pool-2 diesen einen Datenspeicher und nutzen keine Speicherrichtlinie.

Fahren Sie mit der Erstellung des Nutzerclusters wie unter Nutzercluster erstellen (Controlplane V2) beschrieben fort.

Speicher-vMotion verwenden

In diesem Abschnitt wird gezeigt, wie Storage vMotion in einem Cluster verwendet wird, der SPBM verwendet. Wenn Sie Storage vMotion in einem Cluster ohne SPBM verwenden möchten, lesen Sie die Informationen unter Tool für die Datenspeichermigration verwenden.

Gehen Sie so vor:

Migrieren Sie alle Cluster-VMs zum Zieldatenspeicher. Eine Anleitung dazu finden Sie unter Virtuelle Maschine zu einer neuen Compute-Ressource und einem neuen Speicher migrieren.

Prüfen Sie, 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: ci-bluecwang-head-xvz2ccv28bf9wdbx-2/ci-bluecwang-head-xvz2ccv28bf9wdbx-2.vmdk
  uuid: 6000C29d-8edb-e742-babc-9c124013ba54
– datastore: pf-ds06
  filepath: anthos/gke-admin-nc4rk/ci-bluecwang-head/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 gkectl diagnose aus, um zu prüfen, ob der Cluster fehlerfrei ist.
Aktualisieren Sie die Speicherrichtlinie, um die alten Datenspeicher auszuschließen. Andernfalls werden neue Volumes und neu erstellte VMs möglicherweise einem alten Datenspeicher zugewiesen.