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 die generierten 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.5 | Enterprise |
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 den Standardnutzer CloudOwner@gve.local, um auf vCenter zuzugreifen. Dieser Nutzer wurde für den Zugriff auf vCenter erstellt. 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 gesamte Flash-Speicher wird von lokalen SSDs bereitgestellt. Zum Erstellen eines vSphere-Clusters mit einem vSAN-Datenspeicher sind mindestens drei Knoten derselben SKU erforderlich. Jeder Knoten des vSphere-Clusters hat zwei Laufwerksgruppen. Jede Laufwerksgruppe enthält ein Cache-Laufwerk und drei Kapazitätslaufwerke.
Sie können die VMware-Deduplizierungskomprimierung im vSAN-Datenspeicher in VMware Engine aktivieren.Mit diesem Dienst wird die vSAN-Komprimierung standardmäßig aktiviert, wenn ein neuer Cluster erstellt wird. Jeder Cluster in Ihrer privaten Cloud enthält einen vSAN-Datenspeicher. Wenn die gespeicherten Daten der virtuellen Maschine nicht durch Deduplizierung und Komprimierung für die Effizienz des vSAN-Bereichs geeignet sind, können Sie sie im jeweiligen vSAN-Datenspeicher in die gewünschte 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. Sie müssen 20% freie Kapazität im vSAN-Datenspeicher bereitstellen, um das SLA aufrechtzuerhalten.
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
- IP-Adressverwaltung
- 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/Sicherheits-Tags
- Netzwerkzentrierte Gruppierung
- Arbeitslastzentrierte Gruppierung
- IP-basierte Gruppierung
- MAC-basierte Gruppierung
- VPN:
- Ebene-2-VPN
- Layer-3-VPN (IPv4)
- Integrationen:
- Containernetzwerk und -sicherheit nur mit Tanzu Kubernetes Grid (TKG)
- VMware Cloud Director-Dienst
- VMware Aria Automation
- VMware Aria-Vorgänge für Logs
- Containernetzwerk und -sicherheit nur mit Tanzu Kubernetes Grid (TKG)
- 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 die REST API
- Prüfung:
- Port-Mirroring
- 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 sich an Cloud Customer Care wenden, um Zugriff auf Funktionen für diese Anwendungsfälle anzufordern.
In der folgenden Tabelle werden diese Features, ihre entsprechenden Anwendungsfälle und mögliche Alternativen beschrieben:
| Funktion | Anwendungsfall | Empfohlene Alternative | Google Cloud-Kunden bis zum 30. August 2022 | Google Cloud-Kunden nach dem 30. August 2022 |
|---|---|---|---|---|
| Ebene-3-Multicast | Layer-3-Multicast-Routing mit mehreren Hops | 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 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 geschäftsbasierte 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, die Active Directory verwenden | 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 Bereitstellungen von Sicherheitsanbietern von Drittanbietern empfiehlt VMware Engine ein geroutetes Modell gegenüber der Dienstbereitstellung, um sicherzustellen, dass routinemäßige Dienstupgrades die Netzwerkverfügbarkeit nicht beeinträchtigen. | 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. Das Enddatum des Supports für einen Produktrelease finden Sie in der VMware-Produktlebenszyklusmatrix.
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 | 110 |
| 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 normalerweise 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.
Externer Speicher
Sie können die Speicherkapazität eines Google Cloud VMware Engine-Clusters erweitern, indem Sie weitere Knoten hinzufügen. Alternativ können Sie externen Speicher verwenden, wenn Sie nur den Speicher skalieren möchten. Durch die Speicherskalierung wird die Speicherkapazität erhöht, ohne die Rechenkapazität des Clusters zu erhöhen. So können Sie Ihre Ressource unabhängig skalieren.
Wenden Sie sich an den Google-Support oder Ihren Vertriebsmitarbeiter, um weitere Informationen zur Verwendung von externem Speicher zu erhalten.