Filestore als Speicher für Google Cloud VMware Engine-Datenspeicher
Sie können Filestore-Instanzen der hohen Skalierungs- und Enterprise-Stufe als externe Datenspeicher für VMware ESXi-Hosts in Google Cloud VMware Engine verwenden. Dazu können Sie Ihre Filestore-Instanzen in Regionen erstellen, in denen sowohl VMware Engine als auch Filestore verfügbar sind, und sie dann als externe Datenspeicher auf Ihren vorhandenen VMware ESXi-Hosts in VMware Engine bereitstellen.
VMware Engine bietet derzeit die folgenden vSphere-Speicheroptionen:
- VMware vSAN: Dies gilt auch für den Speicher, der für jeden VMware Engine-Knoten bereitgestellt wird.
- Externer NFS-Speicher. Dazu gehören die folgenden Optionen:
- Filestore-Instanzen der hohen oder Enterprise-Stufe, die als vSphere-Datenspeicher verwendet werden.
- Instanzen des NetApp Cloud Volume-Dienstes, die als vSphere-Datenspeicher verwendet werden.
Warum externe Datenspeicher für die VMware Engine?
VMware Engine vSAN bietet virtuellen Hochleistungsspeicher für VMs, die in der VMware Engine ausgeführt werden. Der VMware Engine-Dienst verwendet Hardwareknoten mit lokalen NVMeSSDs (Solid State Drives), die von vSAN verwaltet werden, um eine virtuelle Infrastruktur für VMware-VMs bereitzustellen. Wenn Sie nur die Speicherressourcen in Ihrem Cluster skalieren möchten, müssen Sie einen kompletten Knoten zusammen mit Rechen- und Netzwerkfunktionen erwerben, also Ressourcen, die Sie möglicherweise nicht benötigen. Diese Einschränkung der vSAN-basierten hyperkonvergenten Infrastruktur (HCI) erzeugt einen Bedarf an der Skalierung des Speichers unabhängig von anderen Ressourcen.
Mit externen NFS-Datenspeichern können Sie den Speicher unabhängig von Rechenressourcen skalieren und dabei die VMware Engine für alle Ihre VMware-Arbeitslasten verwenden.
Hochskalierte Instanzen und Instanzen der Enterprise-Stufe sind für die Verwendung mit VMware Engine-Datenspeichern von VMware zertifiziert und in allen VMware Engine-Regionen verfügbar.
Featurebeschränkungen
Es gelten folgende Einschränkungen:
- Nur für Filestore-Instanzen mit hoher Skalierung und Enterprise-Stufe verfügbar. Instanzen der Basic SSD- und Basic HDD-Stufe werden nicht unterstützt.
- Absturzkonsistente Snapshot-Unterstützung ist nur in Instanzen der Filestore Enterprise-Stufe verfügbar.
- Sicherungssupport ist sowohl für die hohe als auch die Enterprise-Stufe verfügbar.
- Copy Offload (VAAI) ist nicht verfügbar.
Protokollunterstützung
Das NFSv3-Protokoll wird unterstützt.
Netzwerk
Filestore- und VMware Engine-Dienste sind über privaten Dienstzugriff (PSA) verbunden. Für den Speicherzugriff innerhalb einer Region fallen keine Netzwerkgebühren an.
Hinweise
In diesem Dokument wird davon ausgegangen, dass Folgendes gegeben ist:
- Für das Google Cloud VMware Engine-Dienstnetzwerk wurde ein CIDR vom Typ
/26
festgelegt, das für externen NFS-Speicher verwendet werden soll.
Dienst-Subnetze
Wenn Sie eine private Cloud erstellen, erstellt die VMware Engine zusätzliche Dienst-Subnetze (z. B. service-1
, service-2
, service-3
). Dienst-Subnetze sind auf Appliance- oder Dienstbereitstellungsszenarien ausgerichtet, z. B. Speicher, Sicherung und Notfallwiederherstellung oder Media-Streaming. Sie bieten einen hohen linearen Durchsatz und eine Paketverarbeitung für selbst umfangreiche private Clouds. Die VM-Kommunikation über ein Dienst-Subnetz läuft vom VMware ESXi-Host direkt in die Google Cloud-Netzwerkinfrastruktur, was eine Hochgeschwindigkeitskommunikation ermöglicht.
NSX-T-Gateway- und verteilte Firewallregeln gelten für kein Dienstsubnetz.
Dienst-Subnetze konfigurieren
Dienst-Subnetze haben bei der ersten Erstellung keine CIDR-Zuweisung. Stattdessen müssen Sie mithilfe der VMware Engine-Konsole oder API einen nicht überlappenden CIDR-Bereich und ein Präfix für Dienst-Subnetze angeben.
Die erste verwendbare Adresse wird die Gateway-Adresse. Bearbeiten Sie eines der Dienst-Subnetze, um einen CIDR-Bereich und ein Präfix zuzuweisen.
Dienst-Subnetze können aktualisiert werden, wenn sich die CIDR-Anforderungen ändern. Die Änderung eines vorhandenen Dienst-Subnetz-CIDR kann jedoch dazu führen, dass die Netzwerkverfügbarkeit für VMs beeinträchtigt wird, die an dieses Dienst-Subnetz angehängt sind.
Sie sollten die reservierten CIDR-Zuweisungen für die Dienst-Subnetze, die Sie im VMware Engine-Portal definiert haben, der Liste der importierten Clients in der VPC-Peering-Verbindung Ihres Netzwerks hinzufügen.
Andernfalls wird der folgende Fehler oder ein ähnlicher Fehler in vmkernel.log
zurückgegeben:
2022-09-23T04:58:14.266Z cpu23:2103354 opID=be2a0887)NFS: 161: Command: (mount)
Server: (10.245.17.21) IP: (10.245.17.21) Path: (/vol-g-shared-vmware-002) Label:
(NFS) Options: (None)
...
2022-09-23T04:58:14.270Z cpu23:2103354 opID=be2a0887)NFS: 194: NFS mount
10.245.17.21:/vol-g-shared-vmware-002 failed: The mount request was denied by the
NFS server. Check that the export exists and that the client is permitted to
mount it.
Filestore-Instanzen erstellen und verwalten
Informationen zur Verwendung der Google Cloud Console zum Erstellen und Verwalten einer Filestore-Instanz finden Sie unter Instanz erstellen.
Informationen zum Importieren der reservierten CIDR-Zuweisungen, die Sie für Ihre Dienst-Subnetze erstellt haben, finden Sie unter Peering-Verbindung aktualisieren.
Nachdem der NFS-Datenspeicher auf allen Hosts in einem bestimmten Cluster bereitgestellt wurde und verfügbar wird, können Sie mit der vCenter-Konsole VMs für den externen Datenspeicher bereitstellen sowie Messwerte und Logs im Zusammenhang mit Google-E/A-Vorgängen anzeigen, die für den externen Datenspeicher ausgeführt wurden.
Wenn Sie an dieser Funktion interessiert sind, wenden Sie sich an Ihr Account-Management-Team oder den Google Cloud-Support.
Nächste Schritte
- Mehr über Filestore erfahren
- Vergleich der relativen Vorteile von Block-, Datei- und Objektspeicher
- Speicheroptionen für Hochleistungs-Computing-Arbeitslasten (High Performance Computing, HPC) in Google Cloud