Supervisor-Komponenten, ‑Anwendungen und ‑Arbeitslasten müssen Daten speichern und abrufen. Einige Anwendungen und Objekte verwenden möglicherweise schnellen flüchtigen Speicher, während für andere persistenter Speicher erforderlich ist.

Grundlegendes zu Speicherrichtlinien

Supervisor verwendet Speicherrichtlinien zur Integration in verfügbaren Speicher in Ihrer vSphere-Umgebung. Die Richtlinien stellen Datenspeicher dar und steuern die Speicherplatzierung von Komponenten und Objekten wie Steuerungsebenen-VMs, flüchtigen vSphere Pod-Festplatten und Container-Images. Möglicherweise benötigen Sie auch Richtlinien für die Speicherplatzierung dauerhafter Volumes und VM-Inhaltsbibliotheken. Falls Sie Tanzu Kubernetes Grid-Cluster verwenden, bestimmen die Speicherrichtlinien auch, wie die Tanzu Kubernetes Grid-Clusterknoten bereitgestellt werden.

Speicherrichtlinien unterstützen alle gemeinsam genutzten Datenspeicher in Ihrer Umgebung, wie etwa VMFS, NFS und vSAN, einschließlich vSAN ESA oder vVols.

Je nach vSphere-Speicherumgebung und den Anforderungen von DevOps können Sie mehrere Speicherrichtlinien für verschiedene Speicherklassen erstellen. Wenn Sie einen Supervisor aktivieren und Namespaces einrichten, können Sie verschiedene Speicherrichtlinien zuweisen, die von verschiedenen Objekten, Komponenten und Arbeitslasten verwendet werden sollen.

Wenn beispielsweise ein vSphere Pod drei Arten von virtuellen Festplatten mountet und Ihre vSphere-Speicherumgebung über drei Klassen von Datenspeichern (Bronze, Silber und Gold) verfügt, können Sie Speicherrichtlinien für alle Datenspeicher erstellen. Sie können den Bronze-Datenspeicher dann für flüchtige virtuelle Festplatten und virtuelle Festplatten mit Container-Images und die Silber- und Gold-Datenspeicher für virtuelle Festplatten mit dauerhaften Volumes verwenden.

Ein vSphere Pod mountet drei Typen virtueller Festplatten: virtuelle Festplatten für dauerhafte Volumes, virtuelle Festplatten des Container-Images und flüchtige virtuelle Festplatten.

Informationen zum Erstellen von Speicherrichtlinien finden Sie in Dokumentation zum Erstellen von SpeicherrichtlinienInstallieren und Konfigurieren der vSphere IaaS-Steuerungsebene.

Allgemeine Informationen zu Speicherrichtlinien finden Sie in Kapitel Speicherrichtlinienbasierte Verwaltung in der vSphere-Speicher-Dokumentation.

Speicherrichtlinien für einen Supervisor

Auf Supervisor-Ebene konfigurieren Sie eine Speicherrichtlinie für Supervisor-Steuerungsebenen-VMs. Wenn Ihre Bereitstellung vSphere-Pods unterstützt, weisen Sie außerdem Speicherrichtlinien zu und geben die Datenspeicherorte für flüchtige Festplatten und Container-Images an. Informationen zum Einstellen des Speichers beim Aktivieren von Supervisor finden Sie in der Dokumentation Installieren und Konfigurieren der vSphere IaaS-Steuerungsebene. Informationen zum Ändern der Speichereinstellungen finden Sie unter Ändern der Speichereinstellungen im Supervisor.

Speicherrichtlinie für Steuerungsebene
Mit dieser Richtlinie wird dafür gesorgt, dass die VMs der Steuerungsebene auf den Datenspeichern platziert werden, die von den Richtlinien dargestellt werden.
Flüchtige virtuelle Festplatten
Eine vSphere Pod erfordert flüchtigen Speicher, um Kubernetes-Objekte wie Protokolle, emptyDir-Volumes und ConfigMaps während der Vorgänge zu speichern. Dieser flüchtige (oder transiente) Speicher steht so lange zur Verfügung, wie der Pod vorhanden ist. Flüchtige Daten werden über Container-Neustarts hinweg beibehalten, aber sobald der Pod das Ende seiner Lebensdauer erreicht, wird die flüchtige virtuelle Festplatte nicht mehr angezeigt.

Jeder Pod verfügt über eine flüchtige virtuelle Festplatte. Als vSphere-Administrator verwenden Sie beim Konfigurieren des Speichers für den Supervisor eine Speicherrichtlinie, um den Speicherort des Datenspeichers für alle flüchtigen virtuellen Festplatten festzulegen.

Virtuelle Festplatten des Container-Images
Container innerhalb der vSphere Pod verwenden Images, die die auszuführende Software enthalten. Der Pod mountet Images, die von ihren Containern als virtuelle Image-Festplatten verwendet werden. Wenn der Pod seinen Lebenszyklus abgeschlossen hat, werden die virtuellen Image-Festplatten vom Pod getrennt.

Image-Dienst, eine ESXi-Komponente, ist dafür verantwortlich, Container-Images aus der Image-Registrierung abzurufen und sie in virtuelle Festplatten zu transformieren, um sie innerhalb des Pods auszuführen.

Image-Dienst ruft ein Container-Image aus der Image-Registrierung ab und wandelt es in eine virtuelle Image-Festplatte um, die vom vSphere Pod gemountet wird.

ESXi kann Images zwischenspeichern, die für die im Pod ausgeführten Container heruntergeladen werden. Nachfolgende Pods, die dasselbe Image verwenden, rufen dieses aus dem lokalen Cache und nicht aus der externen Container-Registrierung ab.

Persistenter Speicher für Arbeitslasten

Bestimmte Kubernetes-Arbeitslasten, die DevOps in einem Namespace ausführen, benötigen persistenten Speicher, um Daten dauerhaft zu speichern.

Persistenter Speicher kann von vSphere-Pods, Tanzu Kubernetes Grid-Clustern, VMs und anderen Arbeitslasten genutzt werden, die Sie im Namespace ausführen. Um dem DevOps-Team persistenten Speicher zur Verfügung zu stellen, erstellt der vSphere-Administrator Speicherrichtlinien, die verschiedene Speicheranforderungen und Dienstklassen beschreiben. Anschließend weist der Administrator Speicherrichtlinien zu und konfiguriert Speichergrenzwerte auf Namespace-Ebene.

Machen Sie sich mit den wichtigen Kubernetes-Konzepten wie Speicherklassen, persistenten Volumes und der Anforderungen von persistenten Volumes vertraut, um zu verstehen, wie vSphere IaaS control plane mit persistentem Speicher arbeitet. Weitere Informationen dazu finden Sie in der Kubernetes-Dokumentation unter https://kubernetes.io/docs/home/.

Informationen zum persistenten Speicher für Tanzu Kubernetes Grid-Cluster finden Sie unter Speicher für Tanzu Kubernetes Grid-Cluster.

Informationen zur Verwendung von persistentem Speicher finden Sie im Abschnitt zum Verwenden von persistentem Speicher bei Arbeitslasten in der Dokumentation Dienste und Arbeitslasten der vSphere IaaS-Steuerungsebene.

Plant Ihr DevOps-Team die Bereitstellung von Drittanbieterdiensten, die vSAN Direct für ihren Bedarf an persistentem Speicher verwenden? Weitere Informationen dazu finden Sie im Abschnitt zum Aktivieren von statusbehafteten Diensten in vSphere with Tanzu in der Dokumentation Dienste und Arbeitslasten der vSphere IaaS-Steuerungsebene.

Wie ist Supervisor in vSphere-Speicher integriert?

Supervisor verwendet mehrere Komponenten für die Integration in vSphere Storage.

CNS wird als vCenter Server-Komponente und CNS-CSI als Supervisor-Komponente angezeigt. Beide interagieren zum Erstellen dauerhafter Volumes und zur Unterstützung von FCDs.

Cloudnativer Speicher (CNS) in vCenter Server
Die CNS-Komponente befindet sich in vCenter Server. Es handelt sich um eine Erweiterung der vCenter Server-Verwaltung, die die Bereitstellungs- und Lebenszyklusvorgänge für dauerhafte Volumes implementiert.
Bei der Bereitstellung von dauerhaften Volumes interagiert die Komponente mit der First-Class Disks-Funktionalität (erstklassige Festplatten) von vSphere, um virtuelle Festplatten zur Unterstützung der Volumes zu erstellen. Darüber hinaus kommuniziert die CNS-Serverkomponente mit der speicherrichtlinienbasierten Verwaltung, um den Festplatten die erforderliche Befehlseben zu garantieren.
Die CNS-Komponente führt auch Abfragevorgänge aus, mit denen vSphere-Administratoren dauerhafte Volumes und deren unterstützende Speicherobjekte über vCenter Server verwalten und überwachen können.
Erstklassige Festplatte (First Class Disk, FCD)
Wird auch als verbesserte virtuelle Festplatte bezeichnet. Diese Festplatten befinden sich auf Datenspeichern und unterstützen dauerhafte ReadWriteOnce-Volumes.
Beachten Sie bei der Verwendung von FCDs Folgendes:
  • FCDs unterstützen NFS 4.x-Protokolle nicht. Verwenden Sie stattdessen NFS 3.
  • vCenter Server serialisiert keine Vorgänge auf demselben FCD. Dies führt dazu, dass Anwendungen nicht gleichzeitig Vorgänge auf derselben FCD ausführen können. Das gleichzeitige Klonen, Verlagern, Löschen, Abrufen und so weiter über verschiedene Threads führt zu unvorhersehbaren Ergebnissen. Um Probleme zu vermeiden, müssen Anwendungen Vorgänge auf derselben FCD in sequenzieller Reihenfolge ausführen.
  • FCD ist kein verwaltetes Objekt und bietet keine Unterstützung für eine globale Sperre, die mehrere Schreibvorgänge für eine einzelne FCD schützt. Dies führt dazu, dass FCD nicht mehrere vCenter Server-Instanzen unterstützt, die dieselbe FCD verwalten. Wenn Sie mehrere vCenter Server-Instanzen mit FCDs verwenden müssen, sind folgenden Optionen verfügbar:
    • Mehrere vCenter Server-Instanzen können verschiedene Datenspeicher verwalten.
    • Mehrere vCenter Server-Instanzen funktionieren nicht auf derselben FCD.
Speicherrichtlinienbasierte Verwaltung
Die speicherrichtlinienbasierte Verwaltung ist ein vCenter Server-Dienst, der die Bereitstellung von dauerhaften Volumes und deren unterstützenden virtuellen Festplatten gemäß den in einer Speicherrichtlinie beschriebenen Speicheranforderungen unterstützt. Nach der Bereitstellung überwacht der Dienst die Konformität des Volumes mit den Merkmalen der Speicherrichtlinien. Weitere Informationen zur Verwaltung auf der Basis von Speicherrichtlinien finden Sie im Kapitel Speicherrichtlinienbasierte Verwaltung in der Dokumentation zu vSphere-Speicher.
vSphere CNS-CSI
Die vSphere CNS-CSI-Komponente entspricht der CSI-Spezifikation (Container Storage Interface), einem Branchenstandard, durch den eine Schnittstelle für die Containerorchestrierung zur Verfügung gestellt wird, die u. a. von Kubernetes zur Bereitstellung von dauerhaftem Speicher genutzt wird. Der CNS-CSI-Treiber wird im Supervisor ausgeführt und stellt die Verbindung zwischen vSphere-Speicher und der Kubernetes-Umgebung in einem Namespace her. Der vSphere CNS-CSI kommuniziert direkt mit der CNS-Komponente für alle Speicherbereitstellungsanforderungen, die aus dem Namespace stammen.

Von vSphere CNS-CSI unterstützte Funktionalität

Die im Supervisor ausgeführte vSphere CNS-CSI-Komponente unterstützt mehrere vSphere- und Kubernetes-Speicherfunktionen. Hierbei gelten allerdings bestimmte Einschränkungen.

Unterstützte Funktionen vSphere CNS-CSI mit Supervisor
CNS-Unterstützung in vSphere Client Ja
Verbesserte Objektintegrität in vSphere Client Ja (nur vSAN)
Dynamisches dauerhaftes Volume für Blöcke (ReadWriteOnce-Zugriffsmodus) Ja
Dynamisches dauerhaftes Volume für Dateien (ReadWriteMany-Zugriffsmodus) Nein
vSphere-Datenspeicher VMFS, NFS, vSAN (einschließlich vSAN ESA), vVols
Statisches dauerhaftes Volume Ja
Verschlüsselung Nein
Offline-Volume-Erweiterung Ja
Online-Volume-Erweiterung Ja
Volume-Topologie und -Zonen Ja. Volumes können nur von Tanzu Kubernetes Grid-Clustern verbraucht werden.
Mehrere Steuerungsebenen-Instanzen in Kubernetes Ja
WaitForFirstConsumer Nein
VolumeHealth Ja
Storage vMotion mit dauerhaften Volumes Nein

Persistenter Speicher und Supervisor mit vSphere-Zonen

Ein Supervisor mit drei Zonen unterstützt den zonenspezifischen Speicher, bei dem ein Datenspeicher von allen Hosts in einer einzelnen Zone gemeinsam genutzt wird.

Alle Hosts in einer einzelnen Zone nutzen gemeinsam einen Datenspeicher.

Beachten Sie Folgendes bei der Vorbereitung von Speicherressourcen für den Supervisor mit drei Zonen:
  • Der Speicher in allen drei Zonen muss nicht vom gleichen Typ sein. Ein einheitlicher Speicher in allen drei Clustern bietet jedoch eine konsistente Leistung.
  • Verwenden Sie für den Namespace auf dem Supervisor mit drei Zonen eine Speicherrichtlinie, die mit dem freigegebenen Speicher in jedem der Cluster kompatibel ist. Die Speicherrichtlinie muss topologiefähig sein.
  • Entfernen Sie keine Topologieeinschränkungen aus der Speicherrichtlinie, nachdem Sie sie dem Namespace zugewiesen haben.
  • Mounten Sie keine Zonendatenspeicher in anderen Zonen.
  • Folgendes unterstützt ein Supervisor mit drei Zonen nicht:
    • Zonenübergreifende Volumes
    • vSAN File-Volumes (ReadWriteMany-Volumes)
    • Bereitstellung statischer Volumes mithilfe der Volume-Registrierungs-API
    • Arbeitslasten, die die vSAN Data Persistence-Plattform verwenden
    • vSphere Pod
    • vSAN Stretched Cluster
    • VMs mit vGPU und Instanzspeicher

Weitere Informationen finden Sie unter Verwenden von persistentem Speicher auf einem Supervisor mit drei Zonen in der Dokumentation zu Dienste und Arbeitslasten der vSphere IaaS-Steuerungsebene.