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 |
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. Die All-Flash-Speicher wird durch lokale 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 die Deduplizierung und Komprimierung aktivieren. im vSAN-Datenspeicher in VMware Engine. 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-Relay/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
- 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:
- Container-Netzwerk und -Sicherheit nur mit Tanzu Kubernetes Grid (TKG)
- VMware Cloud Director-Dienst
- VMware Aria-Automatisierung
- VMware Aria-Vorgänge für Logs
- 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 im oder vor August erstellt haben 30. 2022 kann der Zugriff auf Funktionen für diese Anwendungsfälle durch den Cloud Customer Care
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 |
|---|---|---|---|---|
| Ebene-3-Multicast | Layer-3-Multicast-Routing mit Multi-Hop | 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 Aria verwendet, um geschäftsbasierte Firewallrichtlinien innerhalb von NSX-T | Ü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. | Bei Bereitstellungen von Sicherheitsanbietern VMware Engine empfiehlt ein weitergeleitetes Modell über Diensteinfügung, um diese Routine zu gewährleisten Dienst-Upgrades wirken sich nicht auf die Netzwerkverfügbarkeit aus. | Cloud Customer Care kontaktieren | Nicht unterstützt |
Aktualisierungen und Upgrades
In diesem Abschnitt werden Überlegungen zu Updates und Upgrades sowie deren Lebenszyklus erläutert. für Softwarekomponenten.
HCX
VMware Engine übernimmt die Erstinstallation, Konfiguration und Überwachung von HCX in privaten Clouds. Danach sind Sie für Verwaltung des Lebenszyklus von HCX-Cloud- und Dienst-Appliances wie HCX-IX Interconnect aus.
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. Bis Das Enddatum des Supports für eine Produktveröffentlichung finden Sie in der VMware-Produktlebenszyklus-Matrix.
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. Diese Intervalle können alle ein bis zwei Monate stattfinden, aber mit der Zeit wird sie voraussichtlich sinken. 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 erweitern, indem Sie mehr Knoten. Alternativ können Sie externen Speicher verwenden, wenn Sie den Speicher zu skalieren. 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.
Wenden Sie sich an den Google-Support oder Ihren Vertriebsmitarbeiter, um weitere Informationen externe Speichergeräte verwenden.
Nächste Schritte
- Weitere Informationen Wartung und Updates der privaten Cloud.