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 2c vSphere Enterprise Plus
vCenter 7.0 Update 2d vCenter Standard
vSAN 7.0 Update 2c Erweiterte und ausgewählte vSAN Enterprise-Features
NSX Data Center 3.1.2 Wählen Sie die verfügbaren Features aus. Weitere Informationen finden Sie im Abschnitt NSX Data Center.
HCX 4.2.1 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 ist gve.local. Verwenden Sie für den Zugriff auf vCenter den Standardnutzer CloudOwner@gve.local, der für den Zugriff auf vCenter erstellt wird. Sie können Ihre lokalen bzw. Active Directory-Identitätsquellen für vCenter hinzufügen.

vSAN-Speicher

Private Clouds haben einen vollständig konfigurierten All-Flash-vSAN-Speicher, der dem Cluster lokal zugeordnet ist. 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.

VMware Engine aktiviert standardmäßig die Deduplizierung und Komprimierung im vSAN-Datenspeicher. Jeder Cluster in Ihrer privaten Cloud enthält einen vSAN-Datenspeicher. Wenn die gespeicherten VM-Daten nicht für vSAN-Speicherplatzeffizienz durch Deduplizierung und Komprimierung oder nur durch Komprimierung geeignet sind, können Sie die vSAN-Speicherplatzeffizienz in die gewünschte Konfiguration für den jeweiligen vSAN-Datenspeicher ä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 25 % 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-Relay/DNS-Proxy
  • Routing:
    • Nullrouten
    • Statisches Routing
    • Geräterouting
    • 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
    • Firewallabschnitte
    • Firewall-Logging
    • Zustandsorientierte Layer 2- und Layer 3-Firewallregeln
    • Tag-basierte Regeln
    • Verteiltes Firewall-basiertes IPFIX
  • Firewallrichtlinien, Tags und Gruppen:
    • Objekt-Tagging/Sicherheitstags
    • Netzwerkorientierte 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
    • vRealize Automation
    • vRealize Log Insight
  • 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:
    • Portspiegelung
    • Traceflow
    • Switch-basiertes 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-Features wie zustandsloses 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 vRealize 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

HCX

VMware Engine übernimmt die Erstinstallation, Konfiguration und Überwachung von HCX in privaten Clouds. Sie sind 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.

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 64
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

Aktualisierungen und Upgrades

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.

Nächste Schritte