NFS-Volume als von Filestore gehosteter vSphere-Datenspeicher verwenden

Sie können zonale, regionale und Enterprise-Tier-Filestore-Instanzen als externe Datenspeicher für VMware ESXi-Hosts in der Google Cloud VMware Engine verwenden.

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:

Warum externe Datenspeicher für die VMware Engine?

VMware Engine vSAN bietet Hochleistungsspeicher für VMs, die in VMware Engine ausgeführt werden. Der VMware Engine-Dienst verwendet Hardwareknoten mit lokalen NVMe-SSDs (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 ganzen Knoten mit Compute- und Netzwerkfunktionen kaufen – Ressourcen, die Sie möglicherweise nicht benötigen. Diese Einschränkung der vSAN-basierten Hyperkonvergenten Infrastruktur (HCI) erfordert, den Speicher unabhängig von anderen Ressourcen zu skalieren.

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.
  • Der Support für Crash-konsistente Snapshots ist nur für Filestore-Instanzen der Enterprise-Stufe verfügbar.
  • Sicherungssupport 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 über eine direkte Peering-Verbindung mit der VMware Engine verbunden sind. 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 über den Zugriff auf private Dienste verbunden. Netzwerkgebühren, die durch den Speicherzugriff innerhalb einer Region entstehen, fallen nicht an.

Hinweise

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 Ersterstellung keine CIDR-Zuweisung. Stattdessen müssen Sie über die VMware Engine Console oder API einen nicht überlappenden CIDR-Bereich und ein Präfix für Dienstsubnetze 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 die CIDR-Anforderungen ändern. Die Änderung des CIDR-Adressbereichs eines vorhandenen Dienst-Subnetzes kann jedoch zu Netzwerkverfügbarkeitsstörungen für VMs führen, die mit diesem Dienst-Subnetz verbunden sind.

Fügen Sie die reservierten CIDR-Zuweisungen für die Dienstsubnetze, die Sie im VMware Engine-Portal definiert haben, der Liste der importierten Clients in der VPC-Peering-Verbindung Ihres Netzwerks hinzu.

Andernfalls wird in vmkernel.log der folgende 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

Informationen zum Erstellen und Verwalten einer Filestore-Instanz mit der Google Cloud Console 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.

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 und verfügbar ist, können Sie mit der vCenter-Konsole VMs für den externen Datenspeicher bereitstellen, Messwerte und Protokolle zu Google I/O-Vorgängen auf dem externen Datenspeicher aufrufen.

Wenn Sie an dieser Funktion interessiert sind, wenden Sie sich an Ihr Account-Management-Team oder den Google Cloud-Support.

Nächste Schritte