NFS-Volume als von Filestore gehosteter vSphere-Datenspeicher verwenden

Sie können Filestore zonal, regional und Enterprise verwenden Stufen von Instanzen als externe Datenspeicher für VMware ESXi in der Google Cloud VMware Engine.

Dazu können Sie Ihre Filestore-Instanzen in Regionen erstellen, in denen sowohl die VMware Engine als auch Filestore verfügbar sind, und sie dann als externe Datenspeicher auf Ihren vorhandenen VMware ESXi-Hosts in der VMware Engine bereitstellen.

VMware Engine bietet die folgenden vSphere-Speicheroptionen:

  • VMware vSAN. Dazu gehört auch der Speicherplatz, der mit jedem VMware Engine-Knoten geliefert wird.
  • Externer NFS-Speicher. Dazu gehören folgende Optionen:

Vorteile externer Datenspeicher für VMware Engine

VMware Engine vSAN bietet Hochleistungsspeicher für VMs, die in VMware Engine ausgeführt werden. Die VMware Engine Dienst verwendet Hardwareknoten mit lokalem NVMe SSD (Solid State Drives), die von vSAN verwaltet werden, um eine virtuelle Infrastruktur für VMware-VMs. Wenn Sie nur die Speicherressourcen skalieren möchten in Ihrem Cluster benötigen, müssen Sie einen ganzen Knoten sowie Rechenleistung und Netzwerkfunktionen – Ressourcen, die Sie möglicherweise nicht benötigen. Diese Einschränkung von vSAN-basierte hyper-konvergente Infrastruktur (HCI) der Bedarf an der Skalierung des Speichers unabhängig von anderen Ressourcen entsteht.

Mit externen NFS-Datenspeichern können Sie den Speicher unabhängig von den Rechenressourcen skalieren und für alle Ihre VMware-Arbeitslasten auf die VMware Engine zurückgreifen.

Instanzen der High Scale- und Enterprise-Ebene sind von VMware für die Verwendung mit VMware Engine-Datenspeichern zertifiziert und in allen VMware Engine-Regionen verfügbar.

Featurebeschränkungen

Es gelten folgende Einschränkungen:

  • Nur für Filestore High Scale- und Enterprise-Instanzen verfügbar. Instanzen der Stufen „Basic SSD“ und „Basic HDD“ werden nicht unterstützt.
  • Absturzkonsistente Snapshot-Unterstützung verfügbar in Nur für Instanzen der Filestore Enterprise-Stufe.
  • Unterstützung für Sicherungen ist sowohl für die High Scale als auch für die Enterprise-Stufe verfügbar.
  • Die Kopier-Auslagerung (VAAI) ist nicht verfügbar.
  • Sie können keine Filestore-Instanzen bereitstellen, die mit direkter Verbindung Peering zur VMware Engine. Weitere Informationen finden Sie unter Anforderungen an die Netzwerkkonfiguration und IP-Ressourcen.

Protokollunterstützung

Das NFSv3-Protokoll wird unterstützt.

Netzwerk

Filestore- und VMware Engine-Dienste sind verbunden über den privaten Dienstzugriff bereitgestellt. Für den Speicherzugriff innerhalb einer Region fallen keine Netzwerkgebühren an.

Hinweis

In diesem Dokument wird davon ausgegangen, dass Folgendes gegeben ist:

  • Sie haben ein /26-CIDR für das Google Cloud VMware Engine-Dienstnetzwerk reserviert, das für externen NFS-Speicher verwendet werden soll.

Dienstsubnetze

Wenn Sie eine private Cloud erstellen, erstellt VMware Engine zusätzliche Dienstsubnetze (z. B. service-1, service-2, service-3). Dienstsubnetze sind für Appliance- oder Dienstbereitstellungsszenarien wie Speicher, Sicherung und Notfallwiederherstellung oder Medienstreaming gedacht. Sie bieten eine hohe Skalierung, einen linearen Durchsatz und eine Paketverarbeitung selbst für die größten privaten Clouds. Die VM-Kommunikation über ein Dienstsubnetz erfolgt vom VMware ESXi-Host direkt in die Google Cloud-Netzwerkinfrastruktur, was eine schnelle Kommunikation ermöglicht.

NSX-T-Gateway- und verteilte Firewallregeln gelten nicht für ein Dienstsubnetz.

Dienstsubnetze konfigurieren

Dienstsubnetze haben bei der anfänglichen Erstellung keine CIDR-Zuweisung. Stattdessen müssen Sie mit 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 zur Gateway-Adresse. Wenn Sie einen CIDR-Bereich und ein Präfix zuweisen möchten, bearbeiten Sie eines der Dienstsubnetze.

Dienstsubnetze können aktualisiert werden, wenn sich CIDR-Anforderungen ändern. Die Änderung eines vorhandenen Dienstsubnetz-CIDR zu einer Unterbrechung der Netzwerkverfügbarkeit bei VMs, die an dieses Dienstsubnetz angehängt sind.

Sie sollten die reservierten CIDR-Zuweisungen für die von Ihnen definierten Dienstsubnetze hinzufügen im VMware Engine-Portal zur Liste der importierte Clients in der VPC-Peering-Verbindung Ihres Netzwerks.

Andernfalls wird in vmkernel.log der folgende Fehler oder ein ähnlicher Fehler 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

Erfahren Sie, wie Sie mit der Google Cloud Console einen Filestore erstellen und verwalten. finden Sie unter Instanz erstellen.

Informationen zum Importieren der reservierten CIDR-Zuweisungen, die Sie für Ihre Dienstsubnetze erstellt haben, finden Sie unter Peering-Verbindung aktualisieren.

Kunden müssen sich an den GCVE-Support wenden, um ihre Filestore-NFS-Datenspeicher bereitzustellen. Nachdem der NFS-Datenspeicher auf allen Hosts in einem bestimmten Cluster bereitgestellt wurde und verfügbar ist, können Sie mit der vCenter-Konsole VMs für den externen Datenspeicher bereitstellen, Messwerte und Logs zu Google I/O-Vorgängen aufrufen, 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