VMware-Komponenten für die private Cloud

Eine private Cloud ist eine isolierte VMware-Stack-Umgebung (ESXi-Hosts, vCenter, vSAN und NSX), die von einem vCenter-Server in einer Verwaltungsdomain verwaltet wird. Google Cloud VMware Engine stellt private Clouds mit folgenden VMware Stack-Komponenten bereit:

  • VMware ESXi: Hypervisor auf dedizierten Knoten
  • VMware vCenter: zentralisierte Verwaltung der privaten vSphere-Cloud-Umgebung
  • VMware vSAN: hyperkonvergierte, softwaredefinierte Speicherplattform
  • VMware NSX-Rechenzentrum:Netzwerkvirtualisierung und Sicherheitssoftware
  • VMware HCX: Anwendungsmigration und Arbeitslastausgleich zwischen Rechenzentren und Clouds

Sie können generierte Anmeldedaten für VMware-Stack-Komponenten von der Detailseite der privaten Cloud abrufen.

Versionen der VMware-Komponenten

Ein VMware-Stack einer privaten Cloud hat die folgenden Softwareversionen:

Komponente Version Lizenzierte Version
ESXi 7.0 Update 3o vSphere Enterprise Plus
vCenter 7.0 Update 3p vCenter Standard
vSAN 7.0 Update 3o Erweiterte und ausgewählte vSAN Enterprise-Features
NSX Data Center 3.2.3.1.hp Wählen Sie die verfügbaren Features aus. Weitere Informationen finden Sie im Abschnitt NSX Data Center.
HCX 4.6.2 Enterprise
1In VMware Engine wird eine Version von HCX bereitgestellt, die von VMware für Google Cloud verfügbar gemacht wird. Aktualisieren Sie HCX nach der Erstellung der privaten Cloud, um die neueste Version von HCX für Ihre Umgebung abzurufen.

ESXi

Beim Erstellen einer privaten Cloud wird VMware ESXi auf bereitgestellten Knoten der Google Cloud VMware Engine installiert. ESXi stellt den Hypervisor für die Bereitstellung von virtuellen Maschinen (VMs) bereit. Knoten bieten eine hyperkonvergente Infrastruktur (Computing und Speicher) und sind Teil des vSphere-Clusters in Ihrer privaten Cloud.

Jeder Knoten hat vier physische Netzwerkschnittstellen, die mit dem zugrunde liegenden Netzwerk verbunden sind. VMware Engine erstellt unter Verwendung dieser physischen Netzwerkschnittstellen als Uplinks einen verteilten vSphere Switch (VDS) auf vCenter. Netzwerkschnittstellen werden für Hochverfügbarkeit im Aktiv-Modus konfiguriert.

vCenter Server Appliance

vCenter Server Appliance (VCSA) stellt die Authentifizierungs-, Verwaltungs- und Orchestrierungsfunktionen für VMware Engine bereit. Wenn Sie Ihre private Cloud erstellen und bereitstellen, stellt VMware Engine eine VCSA mit eingebettetem Platform Services Controller (PSC) im vSphere-Cluster bereit. Jede private Cloud hat eine eigene VCSA. Durch Hinzufügen von Knoten zu einer privaten Cloud werden Knoten zur VCSA hinzugefügt.

vCenter-Einmalanmeldung (SSO)

Der Plattformdienst-Controller in VCSA ist mit einer vCenter-Einmalanmeldung (SSO) verknüpft. Der Domainname lautet gve.local. Verwenden Sie für den Zugriff auf vCenter den Standardnutzer CloudOwner@gve.local, der für Sie erstellt wurde. Sie können Ihre lokalen bzw. Active Directory-Identitätsquellen für vCenter hinzufügen.

vSAN-Speicher

Cluster in privaten Clouds haben einen vollständig konfigurierten All-Flash-vSAN-Speicher. Der All-Flash-Speicher wird von lokalen SSDs bereitgestellt. Mindestens drei Knoten derselben SKU sind erforderlich, um einen vSphere-Cluster mit einem vSAN-Datenspeicher zu erstellen. Jeder Knoten des vSphere-Clusters hat zwei Laufwerksgruppen. Jede Laufwerksgruppe enthält ein Cache-Laufwerk und drei Kapazitätslaufwerke.

Sie können Deduplizierung und Komprimierung im vSAN-Datenspeicher in VMware Engine aktivieren. Mit diesem Dienst werden die vSAN-Deduplizierung und -Komprimierung standardmäßig aktiviert, wenn ein neuer Cluster erstellt wird. Jeder Cluster in Ihrer privaten Cloud enthält einen vSAN-Datenspeicher. Wenn die gespeicherten virtuellen Maschinendaten nicht für die vSAN-Speicherplatzeffizienz durch Deduplizierung und Komprimierung oder nur durch Komprimierung geeignet sind, können Sie die vSAN-Speicherplatzeffizienz für den einzelnen vSAN-Datenspeicher auf die ausgewählte Konfiguration ändern.

Zusätzlich zu den erweiterten vSAN-Features bietet VMware Engine Zugriff auf die vSAN Enterprise-Datenverschlüsselung für ruhende Daten und Daten bei der Übertragung.

vSAN-Speicherrichtlinien

Eine vSAN-Speicherrichtlinie definiert die Fehlertoleranz (Failures to commit, FTT) und die Methode zur Fehlertoleranz. Sie können neue Speicherrichtlinien erstellen und auf die VMs anwenden. Zum Aufrechterhalten des SLA müssen auf dem vSAN-Datenspeicher immer freie Kapazitäten von 20% vorhanden sein.

In jedem vSphere-Cluster gibt es eine vSAN-Standard-Speicherrichtlinie, die für den vSAN-Datenspeicher gilt. Die Speicherrichtlinie legt fest, wie VM-Speicherobjekte im Datenspeicher bereitgestellt und zugeordnet werden, um ein Dienstniveau zu gewährleisten.

Die folgende Tabelle zeigt die Parameter der Standardspeicherrichtlinien für vSAN.

FTT Fehlertoleranzmethode Anzahl der Knoten im vSphere-Cluster
1 RAID 1 (Spiegelung)
erstellt zwei Kopien
3 und 4 Knoten
2 Raid 1 (Spiegelung)
erstellt drei Kopien
5 bis 32 Knoten

Unterstützte vSAN-Speicherrichtlinien

Die folgende Tabelle enthält die unterstützten vSAN-Speicherrichtlinien und die Mindestanzahl an Knoten, die zum Aktivieren der Richtlinie erforderlich sind:

FTT Fehlertoleranzmethode Mindestanzahl erforderlicher Knoten im vSphere-Cluster
1 RAID 1 (Spiegelung) 3
1 RAID 5 (Löschcodierung) 4
2 RAID 1 (Spiegelung) 5
2 RAID 6 (Löschcodierung) 6
3 RAID 1 (Spiegelung) 7

NSX Data Center

NSX Data Center bietet Netzwerkvirtualisierungen, eine Mikrosegmentierung und Netzwerksicherheitsfunktionen für die private Cloud. Sie können Dienste, die von NSX Data Center unterstützt werden, in Ihrer privaten Cloud mit NSX konfigurieren.

Verfügbare Features

In der folgenden Liste werden die von VMware Engine unterstützten NSX-T-Features nach Kategorie geordnet beschrieben:

  • Switching, DNS, DHCP und IPAM (DDI):
    • Optimiertes ARP-Lernen und Übertragungsunterdrückung
    • Unicast-Replikation
    • Head-End-Replikation
    • SpoofGuard
    • Verwaltung von IP-Adressen
    • IP-Blöcke
    • IP-Subnetze
    • IP-Pools
    • IPv4-DHCP-Server
    • IPv4-DHCP-Relay
    • Statische IPv4-DHCP-Bindungen/feste Adressen
    • IPv4-DNS-Weiterleitung/DNS-Proxy
  • Routing:
    • Nullrouten
    • Statisches Routing
    • Geräte-Routing
    • BGP-Routensteuerungen, die Routenzuordnungen und Präfixlisten nutzen
  • NAT:
    • NAT auf logischen Nord-/Süd- und Ost-/West-Routern
    • Quell-NAT
    • Ziel-NAT
    • N:N-NAT
  • Firewall:
    • Edge Firewall
    • Verteilte Firewall
    • Gängige Firewall-Benutzeroberfläche
    • Firewallbereiche
    • Firewall-Logging
    • Zustandsorientierte Layer 2- und Layer 3-Firewallregeln
    • Tag-basierte Regeln
    • Verteiltes Firewall-basiertes IPFIX
  • Firewallrichtlinien, Tags und Gruppen:
    • Objekt-Tagging/Sicherheits-Tags
    • Netzwerkzentrierte Gruppierung
    • Arbeitslastzentrierte Gruppierung
    • IP-basierte Gruppierung
    • MAC-basierte Gruppierung
  • VPN:
    • Layer 2-VPN
    • Layer-3-VPN (IPv4)
  • Integrationen:
    • Container-Netzwerk und -Sicherheit nur mit Tanzu Kubernetes Grid (TKG)
    • VMware Cloud Director-Dienst
    • VMware Aria Automation
    • VMware Aria-Vorgänge für Protokolle
  • Authentifizierung und Autorisierung:
    • Direct Active Directory-EInbindung mit LDAP
    • Authentifizierung mit OpenLDAP
    • Rollenbasierte Zugriffssteuerung
  • Automatisierung:
    • REST API
    • Java SDK
    • Python SDK
    • Terraform-Anbieter
    • Ansible-Module
    • OpenAPI/Swagger-Spezifikationen und automatisch generierte API-Dokumentation für REST API
  • Prüfung:
    • Port-Mirroring
    • Traceflow
    • Switchbasiertes IPFIX

Featurebeschränkungen

Einige Funktionen des NSX Data Center haben sehr spezifische Anwendungsfälle in Sachen Netzwerke und Sicherheit. Kunden, die ihr Google Cloud-Konto am oder vor dem 30. August 2022 erstellt haben, können vom Cloud Customer Care Zugriff auf Features für diese Anwendungsfälle anfordern.

In der folgenden Tabelle werden diese Features, ihre entsprechenden Anwendungsfälle und mögliche Alternativen beschrieben:

Feature Anwendungsfall Empfohlene Alternative Google Cloud-Kunden bis zum 30. August 2022 Google Cloud-Kunden nach dem 30. August 2022
Layer-3-Multicast Multi-Hop-Layer-3-Multicast-Routing Layer-2-Multicast wird in einem NSX-T-Subnetz unterstützt. Dadurch kann der gesamte Multicast-Traffic an Arbeitslasten im selben NSX-T-Subnetz zugestellt werden. Unterstützt Nicht unterstützt
Dienstqualität (QoS) VoIP- und latenzempfindliche Anwendung bei Netzwerk-Überlauf Nicht erforderlich, da VMware Engine eine nicht überbelastete Netzwerkarchitektur bereitstellt. Darüber hinaus werden alle QoS-Tags, die eine private Cloud verlassen, entfernt, wenn sie die VPC über eine Peering-Verbindung erreichen. Unterstützt Nicht unterstützt
Simple Network Management Protocol (SNMP)-Traps Legacy-Benachrichtigungsprotokoll für die Benachrichtigung von Nutzern über Ereignisse Ereignisse und Alarme können mit modernen Protokollen in NSX-T konfiguriert werden. Unterstützt Nicht unterstützt
NAT-Funktionen wie zustandslose NAT, NAT-Logging und NAT64 Wird für NAT für Mobilfunkanbieter bei größeren Telekommunikationsbereitstellungen verwendet NSX-T unterstützt Quell/Ziel-NAT und N:N NAT auf logischen Nord-/Süd- und Ost-/West-Routern. Unterstützt Nicht unterstützt
Intent-basierte Netzwerk- und Sicherheitsrichtlinien Wird in Verbindung mit VMware Aria verwendet, um unternehmensbasierte Firewallrichtlinien in NSX-T zu erstellen Über NSX-T Gateway und Distributed Firewall-Funktionen können Sicherheitsrichtlinien erstellt und erzwungen werden. Unterstützt Nicht unterstützt
Identitätsbasierte Gruppen mit Active Directory VDI-Bereitstellungen, bei denen der Nutzer sich bei einem bestimmten VDI-Gast angemeldet hat, können erkannt werden und einen benutzerdefinierten Satz von NSX-T-Firewallregeln erhalten Nutzern können mit dedizierten Zuweisungspools bestimmte Workstations zugewiesen werden. Verwenden Sie NSX-T-Tags, um darauf bestimmte Firewallregeln nach Pool anzuwenden. Unterstützt Nicht unterstützt
Regeln für Layer-7-Attribut (App-ID) Wird in NSX-T-Firewallregeln verwendet Mit NSX-T-Dienstgruppen können Sie eine Reihe an Ports und Diensten definieren, um beim Erstellen einer oder mehrerer Firewallregeln eine einfache Referenz zu haben. Unterstützt Nicht unterstützt
Zustandsorientierte Layer 2- und Layer 3-Firewallregeln Wird für Hochgeschwindigkeitsfirewalls für Mobilfunk bei großen Telekommunikationsbereitstellungen verwendet NSX-T unterstützt zustandsorientierte leistungsstarke Layer-2- und Layer-3-Regeln. Unterstützt Nicht unterstützt
Einfügen von NSX-T-Diensten Wird verwendet, um die Bereitstellung von Nord-/Süd- oder Ost-/West-Netzwerkdiensten von Drittanbietern zu automatisieren. Dazu wird NSX-T zum Schutz und zur Prüfung des Traffics verwendet. Für Sicherheitsbereitstellungen von Drittanbietern empfiehlt VMware Engine ein Routing-Modell statt der Einfügung von Diensten, um zu vermeiden, dass sich routinemäßige Dienst-Upgrades auf die Netzwerkverfügbarkeit auswirken. Cloud Customer Care kontaktieren Nicht unterstützt

Lizenzen verwenden

Google Cloud ist ein VMware Cloud-Partner. Sie können einen Rabatt für die nutzungsgebundene Lizenz (Committed Use Discount, CUD) auswählen, der Lizenzen im Rahmen des verwalteten VMware Engine-Dienstes umfasst, oder Sie können Ihre eigenen Lizenzen verwenden.

Aktualisierungen und Upgrades

In diesem Abschnitt werden Aspekte von Updates und Upgrades sowie die Zuständigkeiten für die Lebenszyklusverwaltung von Softwarekomponenten beschrieben.

HCX

VMware Engine übernimmt die Erstinstallation, Konfiguration und Überwachung von HCX in privaten Clouds. Danach sind Sie für die Lebenszyklusverwaltung von HCX Cloud und Service-Appliances wie HCX-IX Interconnect verantwortlich.

VMware stellt Updates für HCX Cloud über seinen HCX-Dienst bereit. Sie können HCX Manager und bereitgestellte HCX-Service-Appliances über die Cloud-Benutzeroberfläche von HCX aktualisieren. Informationen zum Enddatum des Supports für ein Produktveröffentlichung finden Sie in der Matrix des VMware-Produktlebenszyklus.

Andere VMware-Software

Google ist für die Lebenszyklusverwaltung der VMware-Software (ESXi, vCenter, PSC und NSX) in der privaten Cloud verantwortlich.

Zu den Softwareupdates gehören:

  • Patches:von VMware veröffentlichte Sicherheitspatches oder Fehlerkorrekturen
  • Updates: geringfügige Versionsänderung einer VMware-Stack-Komponente
  • Upgrades: Hauptversion einer VMware-Stack-Komponente

Google testet kritische Sicherheitspatches, sobald diese von VMware zur Verfügung gestellt werden. Gemäß dem SLA führt Google den Sicherheitspatch für private Cloud-Umgebungen innerhalb einer Woche ein.

Google bietet vierteljährliche Wartungsupdates für die Softwarekomponenten von VMware. Bei einer neuen Hauptversion der VMware-Software arbeitet Google mit Kunden zusammen, um gemeinsam ein geeignetes Wartungsfenster für das Upgrade festzulegen.

vSphere-Cluster

ESXi-Hosts werden als Cluster konfiguriert, um die Hochverfügbarkeit der privaten Cloud sicherzustellen. Wenn Sie eine private Cloud erstellen, stellt VMware Engine Verwaltungskomponenten von vSphere auf dem ersten Cluster bereit. VMware Engine erstellt einen Ressourcenpool für Verwaltungskomponenten und stellt alle Verwaltungs-VMs in diesem Ressourcenpool bereit.

Der erste Cluster kann nicht gelöscht werden, um die Private Cloud zu verkleinern. Der vSphere-Cluster verwendet vSphere HA, um die Hochverfügbarkeit für VMs zu ermöglichen. Die Fehlertoleranz (FTT) basiert auf der Anzahl der verfügbaren Knoten im Cluster. Die Formel Number of nodes = 2N+1, wobei N der FTT ist, beschreibt die Beziehung zwischen den verfügbaren Knoten in einem Cluster und FTT.

Verwenden Sie für Produktionsarbeitslasten eine private Cloud, die mindestens drei Knoten enthält.

Private Clouds mit einzelnem Knoten

Für Tests und Proofs of Concept mit VMware Engine können Sie eine private Cloud erstellen, die nur einen einzelnen Knoten und Cluster enthält. VMware Engine löscht private Clouds, die nach 60 Tagen nur einen Knoten enthalten, sowie zugehörige Arbeitslast-VMs und Daten.

Sie können die Größe einer privaten Cloud mit einem Knoten auf drei oder mehr Knoten ändern. In diesem Fall initiiert VMware Engine die vSAN-Datenreplikation und versucht nicht mehr, die private Cloud zu löschen. Eine private Cloud muss mindestens 3 Knoten und eine vollständige vSAN-Datenreplikation enthalten, um für die Abdeckung gemäß dem SLA in Frage zu kommen.

Funktionen oder Vorgänge, für die mehr als ein Knoten erforderlich ist, funktionieren nicht mit einer privaten Cloud mit einem einzelnen Knoten. Sie können beispielsweise vSphere Distributed Resource Scheduler (DRS) oder Hochverfügbarkeit (HA) nicht verwenden.

Limits für vSphere-Cluster

In der folgenden Tabelle werden die vSphere-Clusterlimits in privaten Clouds beschrieben, die die SLA-Anforderungen erfüllen:

Ressource Limit
Mindestanzahl der Knoten zum Erstellen einer privaten Cloud (erster Cluster) 3
Mindestanzahl der Knoten zum Erstellen eines Clusters 3
Maximale Anzahl von Knoten pro Cluster 32
Maximale Anzahl von Knoten pro privater Cloud 96
Maximale Anzahl von Clustern pro privater Cloud 21

Unterstützung von Gastbetriebssystemen

Sie können auf einer VM jedes Gastbetriebssystem installieren, das von VMware für die ESXi-Version in Ihrer privaten Cloud unterstützt wird. Eine Liste der unterstützten Gastbetriebssysteme finden Sie im VMware-Kompatibilitätsleitfaden für Gastbetriebssysteme.

VMware-Infrastruktur warten

Gelegentlich ist es erforderlich, Änderungen an der Konfiguration der VMware-Infrastruktur vorzunehmen. Derzeit kann dieses Intervall 1 bis 2 Monate betragen, aber mit der Zeit wird es voraussichtlich länger werden. Diese Art der Wartung kann in der Regel durchgeführt werden, ohne die normale Nutzung der Dienste zu unterbrechen.

Während eines VMware-Wartungsintervalls funktionieren die folgenden Dienste weiter ohne Beeinträchtigung:

  • VMware-Verwaltungsebene und -Anwendungen
  • vCenter-Zugriff
  • Alle Netzwerke und Speicher
  • Gesamter Cloud-Traffic

Externer Speicher

Sie können die Speicherkapazität eines Google Cloud VMware Engine-Clusters durch Hinzufügen weiterer Knoten erweitern. Alternativ können Sie externen Speicher verwenden, wenn Sie nur den Speicherplatz skalieren möchten. Durch die Skalierung des Speichers wird die Speicherkapazität erhöht, ohne dass die Rechenkapazität des Clusters erhöht wird. So können Sie Ihre Ressourcen unabhängig skalieren.

Weitere Informationen zur Verwendung von externem Speicher erhalten Sie vom Google-Support oder Ihrem Vertriebsmitarbeiter.

Nächste Schritte