Viele Unternehmen möchten ihre VMware-Cluster in die Cloud migrieren, um die Skalierbarkeit, Resilienz und Elastizität der Cloud sowie die Dienste auf höherer Ebene wie Vertex AI Studio und BigQuery zu nutzen. Unternehmen möchten auch Ausgaben von einem kapitalintensiven Hardwaremodell auf ein flexibleres Betriebsausgabenmodell verlagern. Damit Unternehmen schnell eine Betriebsumgebung erstellen können, die den Google Cloud Best Practices entspricht, haben wir den Google Cloud VMware Engine-Blueprint für Unternehmen erstellt. Dieser Blueprint bietet Ihnen eine umfassende Anleitung zum Bereitstellen einer VMware-Umgebung für Unternehmen, damit Sie Ihre VM-Arbeitslasten in die Cloud migrieren können.
VMware Engine ist ein vollständig verwalteter Dienst, mit dem Sie die VMware-Plattform auf Google Cloudausführen können. Ihre VMware-Arbeitslasten werden auf dedizierter Google Cloud Hardware ausgeführt, die vollständig in Google Cloud-Dienste integriert ist. Google kümmert sich um die Infrastruktur, das Netzwerk und die Verwaltung. Mit dem Blueprint können Sie ein Google Cloud -Projekt bereitstellen, das eine private VMware Engine-Cloud, ein von Google verwaltetes VMware Engine-Netzwerk und die VPC-Netzwerk-Peering-Verbindungen enthält, die einen End-to-End-Trafficfluss ermöglichen.
Der Enterprise-Blueprint für VMware Engine umfasst Folgendes:
- GitHub-Repositories, die den Terraform-Code und die Hilfsskripts enthalten, die für die Bereitstellung der VMware Engine-Plattform erforderlich sind
- Einer Anleitung zu den Architektur-, Netzwerk- und Sicherheitskontrollen, die Sie mit den GitHub-Repositories implementieren (dieses Dokument)
Das Blueprint ist für die Ausführung auf der Grundlage von Basisdiensten wie VPC-Netzwerken konzipiert. Sie können den Blueprint für Unternehmensgrundlagen oder Fabric FAST verwenden, um die Grundlage für diesen Blueprint zu schaffen.
Dieses Dokument richtet sich an Cloud-Architekten, Cloud-Plattformadministratoren, VMware Engine-Administratoren und VMware Engine-Entwickler, die den Blueprint verwenden können, um VMware-Cluster inGoogle Cloudzu erstellen und bereitzustellen. Das Blueprint konzentriert sich auf das Design und die Bereitstellung einer neuen privaten VMware Engine-Cloud und setzt voraus, dass Sie mit VMware und dem verwalteten VMware Engine-Dienst vertraut sind.
Übersicht über den Enterprise-Blueprint für VMware Engine
Das Enterprise-Blueprint für VMware Engine basiert auf einem mehrschichtigen Ansatz, um die VMware Engine-Plattform zu aktivieren. Das folgende Diagramm zeigt die Interaktion der verschiedenen Komponenten dieses Blueprints mit anderen Blueprints und Diensten.
Dieses Diagramm enthält Folgendes:
- Die Google Cloud -Infrastruktur bietet Ihnen Sicherheitsfunktionen wie Verschlüsselung inaktiver Daten und Verschlüsselung während der Übertragung sowie Grundbausteine wie Computing und Speicher.
- Die Unternehmensgrundlage bietet Ihnen eine Basis für Ressourcen wie Netzwerk, Identität, Richtlinien, Monitoring und Logging. Mit diesen Ressourcen können Sie Google Cloud schnell einführen und gleichzeitig die Architekturvorgaben Ihrer Organisation erfüllen.
Der Enterprise-Blueprint für VMware Engine bietet Ihnen Folgendes:
- Ein VMware Engine-Netzwerk
- Private Verbindung zu Google Virtual Private Cloud-Netzwerken, APIs und Diensten
- Eine private VMware Engine-Cloud
- Sicherungsfunktionen
- Cloud Load Balancing
- Google Cloud Armor
- Zu den Anwendungsfällen gehören Migrationen von Rechenzentren, die Erweiterung der elastischen Kapazität von Rechenzentren, VDI (Virtual Desktop Infrastructure) und Notfallwiederherstellungsszenarien für Rechenzentren.
Die Bereitstellungsautomatisierung mit einer CI/CD-Pipeline bietet Ihnen die Tools, mit denen Sie die Bereitstellung, Konfiguration und Verwaltung der Infrastruktur automatisieren können. Mit Automatisierung sorgen Sie für konsistente, zuverlässige und überprüfbare Bereitstellungen und können manuelle Fehler minimieren und den gesamten Entwicklungszyklus beschleunigen.
Architektur
Das folgende Diagramm zeigt die Architektur, die mit dem Enterprise-Blueprint für VMware Engine bereitgestellt wird.
Mit dem Blueprint wird Folgendes bereitgestellt:
- Ein Google Cloud Projekt namens eigenständiges VMware Engine-Projekt, das eine private VMware Engine-Cloud enthält
- Ein von Google verwaltetes Projekt für das VMware Engine-Netzwerk
- Die VPC-Netzwerk-Peering-Verbindungen, damit Traffic von VMware Engine-Anwendungen zu Clients fließen kann
Die private VMware Engine-Cloud besteht aus den folgenden Komponenten:
- Verwaltungstools: VLAN und Subnetz für das Verwaltungsnetzwerk des ESXi-Hosts, DNS-Server, vCenter-Server
- Sicherung:Sicherungsinfrastruktur für Arbeitslast-VMs
- Virtuelle Maschinen:Arbeitslast-VMs
- vCenter Server:zentrale Verwaltung der privaten vSphere-Cloud-Umgebung
- NSX Manager:Bietet eine einzige Schnittstelle zum Konfigurieren, Überwachen und Verwalten von NSX-T-Netzwerk- und Sicherheitsdiensten.
- ESXi-Hosts:Hypervisor auf dedizierten Knoten
- vSAN-Speicher:hyperkonvergierte, softwaredefinierte Speicherplattform
- NSX-T-Overlay-Netzwerk:Netzwerkvirtualisierung und Sicherheitssoftware
- VMware HCX: Anwendungsmigration und Arbeitslastausgleich zwischen Rechenzentren und Clouds
Übersicht über die VMware Engine-Netzwerkfunktionen
Das VMware Engine-Netzwerk ist ein dediziertes Netzwerk, das die VMware Engine Private Cloud, VPC-Netzwerke und lokale Umgebungen verbindet. Das VMware Engine-Netzwerk bietet die folgenden Funktionen:
- Verbindung zur privaten Cloud:Jede private VMware Engine-Cloud ist mit einem VMware Engine-Netzwerk verbunden, sodass die Kommunikation zwischen Arbeitslasten in der privaten Cloud möglich ist.
- VMware Engine-Netzwerkverbindung:Sie können VPC-Netzwerk-Peering verwenden, um eine Verbindung zwischen VMware Engine-Netzwerken und einer Google-VPC herzustellen. Diese Verbindung ermöglicht die Kommunikation zwischen Arbeitslasten, die in VMware Engine ausgeführt werden, und Arbeitslasten, die in anderen Diensten in Google Cloudausgeführt werden.
- Lokale Konnektivität:Wenn Sie eine Hybrid-Cloud-Lösung erstellen möchten, können Sie VMware Engine-Netzwerke mit Cloud VPN oder Cloud Interconnect auf lokale Rechenzentren ausweiten.
- Netzwerkdienste:VMware Engine-Netzwerke verwenden verschiedene Netzwerkdienste, darunter die folgenden:
Mit VMware Engine sind Sie für das Erstellen und Verwalten von Arbeitslast-VMs über die VMware-Anwendungsverwaltungsoberfläche verantwortlich.Google Cloud ist für das Patchen und Aktualisieren der Infrastrukturkomponenten und das Beheben von Fehlern bei Komponenten verantwortlich.
Wichtige Architekturentscheidungen
| Entscheidungsbereich | Entscheidungs- | Begründung der Entscheidung |
|---|---|---|
| Stiftung | Sie können den VMware Engine-Blueprint für Unternehmen auf dem Blueprint für Unternehmensgrundlagen, Fabric FAST oder auf einer Grundlage implementieren, die die definierten Voraussetzungen erfüllt. | Sowohl der Blueprint zur Unternehmensgrundlage als auch Fabric FAST bieten die grundlegenden Funktionen, die Unternehmen bei der Einführung von Google Cloudunterstützen. |
| Compute | Sie können einen einzelnen privaten Cluster in einer bestimmten Region bereitstellen oder zwei private Cluster in zwei Regionen. | Die Konfiguration eines einzelnen privaten Clusters ermöglicht eine vereinfachte Verwaltung und Kostenoptimierung. |
| Mit dem Blueprint wird ein Ersatzknoten bereitgestellt. | Mit einem einzelnen Ersatzknoten haben Sie Kapazität für Ausfälle, Wartungsereignisse und Schwankungen der Arbeitslast und können gleichzeitig die Kosten minimieren. | |
| Sicherung und Notfallwiederherstellung werden über den Backup- und DR-Dienst verwaltet. | Mit Backup and DR können Sie einen verwalteten Dienst nutzen und den Verwaltungsaufwand für ein VMware Engine-Deployment verringern. | |
| Netzwerk | Der Blueprint ermöglicht Hybridkonnektivität. | Mit Hybridkonnektivität können Sie Ihre lokale Umgebung mit Ihrer Google Cloud Umgebung verbinden. |
| In einer privaten Cloud wird ein privater, routingfähiger und zusammenhängender IP-Bereich verwendet. | Ein zusammenhängender IP-Adressbereich erleichtert die Verwaltung von IP-Adressen. Wenn der IP-Bereich routingfähig ist, kann die private Cloud mit Ihren lokalen Ressourcen kommunizieren. | |
| Der Internetzugriff erfolgt über Cloud Load Balancing und ist durch Cloud Armor geschützt. | Cloud Armor verbessert die Sicherheit von Arbeitslasten, während Cloud Load Balancing die Skalierbarkeit und Hochverfügbarkeit von Arbeitslasten ermöglicht. | |
| Der Blueprint aktiviert Cloud DNS. | Cloud DNS löst interne und externe Namen auf. |
Plattformidentitäten
Im Blueprint werden zwei Nutzergruppen verwendet: eine Cloud-Plattform-Entwicklungsgruppe und eine VMware-Plattform-Entwicklungsgruppe. Diese Gruppen haben die folgenden Aufgaben:
- Die Cloud-Plattform-Engineering-Gruppe ist für die Bereitstellung der Grundlage für den VMware Engine-Blueprint und die Bereitstellung des Blueprints verantwortlich.
- Die VMware-Plattform-Engineering-Gruppe ist für die Konfiguration und den Betrieb der VMware-Komponenten verantwortlich, die Teil der privaten Cloud sind.
Wenn Sie den Blueprint für Unternehmensgrundlagen oder Fabric FAST bereitstellen, wird die Cloud-Plattform-Engineering-Gruppe im Rahmen des ersten Bereitstellungsprozesses erstellt. Die VMware-Plattform-Engineering-Gruppe wird als Teil dieses Blueprints bereitgestellt.
Organisationsstruktur
Der VMware Engine-Blueprint für Unternehmen basiert auf der vorhandenen Organisationsstruktur des Blueprints für Unternehmensgrundlagen und Fabric FAST. Es wird ein eigenständiges VMware Engine-Projekt in der Produktions-, Nicht-Produktions- und Entwicklungsumgebung hinzugefügt. Das folgende Diagramm zeigt die Struktur des Blueprints.
Netzwerk
Der Enterprise-Blueprint für VMware Engine bietet die folgenden Netzwerkoptionen:
- Ein einzelnes freigegebene VPC-Netzwerk für eine private VMware Engine-Cloud
- Zwei freigegebene VPC-Instanzen für eine Private Cloud
Beide Optionen werden in einer einzigen Region bereitgestellt und ermöglichen es Ihnen, Traffic aus Ihrer lokalen Umgebung zu verwalten.
Das folgende Diagramm zeigt ein einzelnes freigegebene VPC-Netzwerk für eine einzelne Region.
Mit separaten Shared VPC-Instanzen können Sie Kosten und Netzwerk-Traffic nach Geschäftsbereichen gruppieren und gleichzeitig die logische Trennung in der privaten VMware Engine-Cloud beibehalten. Das folgende Diagramm zeigt mehrere freigegebene VPC-Netzwerke in einer einzelnen Region.
Netzwerk der privaten Cloud
In der privaten Cloud wird das Netzwerk von NSX-T unterstützt, das eine softwaredefinierte Netzwerkschicht mit erweiterten Funktionen wie Mikrosegmentierung, Routing und Lastenausgleich bietet. Mit dem VMware Engine-Blueprint wird ein Netzwerk für Ihren VMware Engine-Dienst erstellt. Dieses Netzwerk ist ein einzelner Layer-3-Adressbereich. Das Routing ist standardmäßig aktiviert, sodass alle privaten Clouds und Subnetze in der Region ohne zusätzliche Konfiguration miteinander kommunizieren können. Wie im folgenden Diagramm dargestellt, werden beim Erstellen einer privaten Cloud mehrere Subnetze erstellt, die aus Verwaltungs-, Dienst-, Arbeitslast- und Edge-Dienst-Subnetzen bestehen.
Wenn Sie Ihre private Cloud konfigurieren, müssen Sie einen CIDR-Bereich auswählen, der sich nicht mit anderen Netzwerken in Ihrer privaten Cloud, Ihrem lokalen Netzwerk, Ihrem privaten Cloud-Verwaltungsnetzwerk oder Subnetz-IP-Adressbereichen in Ihrem VPC-Netzwerk überschneidet. Nachdem Sie einen CIDR-Bereich ausgewählt haben, weist VMware Engine automatisch IP-Adressen für verschiedene Subnetze zu. Anhand des CIDR-Bereichs 10.0.0.0/24 zeigt die folgende Tabelle die IP-Adressbereiche des Blueprints für seine Verwaltungssubnetze.
| Subnetz | Beschreibung | IP-Adressbereich |
|---|---|---|
| Systemverwaltung | VLAN und Subnetz für das Verwaltungsnetzwerk, den DNS-Server und den vCenter-Server der ESXi-Hosts | 10.0.0.0/26 |
| VMotion | VLAN und Subnetz für das vMotion-Netzwerk für ESXi-Hosts | 10.0.0.64/28 |
| HCX-Uplink | Uplink für HCX IX- (Mobilität) und NE-Appliances (Erweiterung), damit sie ihre Peers erreichen und das HCX-Servicenetzwerk erstellt werden kann | 10.0.0.216/29 |
Die Arbeitslast-VMs befinden sich im NSX-T-Subnetz. NST-T-Edge-Uplinks ermöglichen externe Verbindungen. Die Größe des CIDR-Bereichs Ihrer privaten Cloud bestimmt die Anzahl der ESXi-Knoten, die im NST-T-Subnetz unterstützt werden können. ESXi-Knoten verwenden das VSAN-Subnetz für den Speichertransport.
Die folgende Tabelle zeigt die IP-Adressbereiche für das NSX-T-Host-Transport-Subnetz, die NSX-T-Edge-Uplink-Subnetze und die vSAN-Subnetze basierend auf einem CIDR-Bereich von 10.0.0.0/24.
| Subnetz | Beschreibung | IP-Adressbereich |
|---|---|---|
| VSAN | Das VSAN-Subnetz ist für den Speicher-Traffic zwischen ESXI-Hosts und VSAN-Speicherclustern verantwortlich. | 10.0.0.80/28 |
| Host-Transport in NSX-T | Das VLAN und Subnetz für die ESXi-Hostzone, die für die Netzwerkverbindung verantwortlich ist und Firewalling, Routing, Load-Balancing und andere Netzwerkdienste ermöglicht. | 10.0.0.128/27 |
| NSX-T-Edge-Uplink-N [N=1–4] | Über den NSX-T-Edge-Uplink können externe Systeme auf Dienste und Anwendungen zugreifen, die im NSX-T-Netzwerk ausgeführt werden. |
|
Für Dienstsubnetze und das Edge-Dienstsubnetz weist VMware Engine keinen CIDR-Bereich oder kein Präfix zu. Daher müssen Sie einen sich nicht überschneidenden CIDR-Bereich und ein Präfix angeben. In der folgenden Tabelle sind die CIDR-Blöcke des Blueprints für die Dienstsubnetze und das Edge-Dienstsubnetz aufgeführt.
| Subnetz | Beschreibung | IP-Adressbereich |
|---|---|---|
| Service-N [N=1-5] | Über Dienstsubnetze können virtuelle Maschinen den NSX-Transport umgehen und direkt mit dem Google Cloud -Netzwerk kommunizieren, um eine schnelle Kommunikation zu ermöglichen. |
|
| Edge-Dienst | Erforderlich, wenn optionale Edge-Dienste wie Point-to-Site-VPN, Internetzugriff und externe IP-Adresse aktiviert sind. Bereiche werden für jede Region festgelegt. | 10.0.1.0/26 |
Routing
Mit Ausnahme von Netzwerken, die von Ihrem lokalen Netzwerk oder von anderen privaten VMware Engine-Clouds aus erweitert werden, wird die gesamte Kommunikation innerhalb von VMware Engine und zu externen IP-Adressen standardmäßig über Layer 3 weitergeleitet. Das Blueprint konfiguriert einen Cloud Router, der der lokalen Hybridverbindung (über Cloud VPN oder Cloud Interconnect) zugeordnet ist, mit zusammenfassenden benutzerdefinierten beworbenen Routen für die VMware Engine-IP-Adressbereiche. NSX-Segmentrouten werden auf Tier 0-Ebene zusammengefasst. Der Blueprint ermöglicht DHCP-Dienste über das NSX-T DHCP-Relay zu den DHCP-Diensten, die in der privaten VMware Engine-Cloud eingerichtet sind.
DNS-Konfiguration
Mit VMware Engine können Sie eine Cloud DNS-Zone in Ihrem Projekt als einzelnen DNS-Auflösungsendpunkt für alle verbundenen Verwaltungs-Appliances in einem Peering-VPC-Netzwerk verwenden. Das gilt auch dann, wenn Ihre privaten Clouds in verschiedenen Regionen bereitgestellt werden.
Wenn Sie die Adressauflösung für mehrere oder einzelne private Clouds konfigurieren, können Sie die globale Adressauflösung mit Cloud DNS einrichten.
Standardmäßig können Sie die Verwaltungszone aus jedem Ihrer VPC-Netzwerke auflösen, in dem Cloud DNS aktiviert ist.
Wenn durch den Blueprint eine private Cloud erstellt wird, die mit einem Standard-VMware Engine-Netzwerk verknüpft ist, wird eine zugehörige Management-DNS-Zone erstellt und automatisch mit den Einträgen der Management-Appliances gefüllt.
Wenn das VMware Engine-Standardnetzwerk ein VPC-Netzwerk ist, das per Peering mit einem VPC- oder einem anderen VMware Engine-Netzwerk verbunden ist, wird durch den Blueprint automatisch eine DNS-Zonenbindung für die Verwaltung erstellt. Diese Zonenbindung sorgt dafür, dass Management-Appliances von Ihren Google Cloud VMs in diesem Netzwerk aufgelöst werden. Das folgende Diagramm zeigt die Cloud DNS-Topologie.
Ausgehender Traffic von VMware Engine ins Internet
Das Blueprint bietet Ihnen die folgenden drei Optionen für ausgehenden Traffic von VMware Engine zum Internet:
- Ausgehender Traffic über die lokale Umgebung des Kunden
- Ausgehender Traffic über das Internet-Gateway von VMware Engine
- Ausgehender Traffic über die angehängte VPC des Kunden mit einer externen IP-Adresse
Das folgende Diagramm zeigt diese Optionen.
Eingehender Traffic aus dem Internet zu VMware Engine
Das Blueprint bietet Ihnen die folgenden drei Optionen für Traffic aus dem Internet zu VMware Engine:
- Eingehender Traffic über die lokale Umgebung des Kunden
- Eingehender Traffic über eine Kunden-VPC mit Cloud Load Balancing und möglicherweise Cloud Armor
- Eingehender Traffic über VMware Engine mit einer externen IP-Adresse
Das folgende Diagramm zeigt diese Optionen.
Logging
Mit dem Blueprint können Sie die administrativen Aktionen von VMware Engine mithilfe eines Log-Senken an Cloud-Audit-Logs senden. Durch die Analyse der VMware Engine-Audit-Logs können Administratoren verdächtiges Verhalten erkennen, Vorfälle untersuchen und die Einhaltung von behördlichen Anforderungen nachweisen.
Logexporte können auch als Erfassungsquellen für SIEM-Systeme (Security Information and Event Management) dienen. Google unterstützt die folgenden Erfassungsquellen für VMware Engine:
- Die Hosting- Google Cloud Organisation, die Cloud-Fabric und Telemetrie für Assets umfasst
- VMware-Dienstkomponenten
- Arbeitslasten, die in VMware Engine ausgeführt werden
Google SecOps umfasst eine integrierte automatisierte Pipeline für die Logaufnahme zum Erfassen von Organisationsdaten und bietet Weiterleitungssysteme, um Streaming-Telemetrie von VMware Engine und Arbeitslasten in die Google SecOps-Aufnahmepipeline zu übertragen. Google SecOps reichert Telemetriedaten mit Kontextinhalten an und macht sie durchsuchbar. Mit Google SecOps können Sie Sicherheitsprobleme erkennen und verfolgen, während sie sich entwickeln.
Monitoring
Mit dem Blueprint wird ein eigenständiger Agent für Cloud Monitoring installiert, um Messwerte aus Ihrer Private Cloud an Cloud Monitoring weiterzuleiten. Mit dem Blueprint werden vordefinierte Dashboards eingerichtet, die einen Überblick über Ihre VMware Engine-Ressourcen und die Ressourcennutzung bieten. VMware bietet in VMware vCenter Server Tools, mit denen Sie Ihre Umgebung überwachen und die Quelle von Problemen ermitteln können. Sie können diese Tools im Rahmen Ihrer laufenden Abläufe und als Ergänzung zu anderen Überwachungsoptionen verwenden.
Wie im folgenden Diagramm zu sehen ist, wird durch den Blueprint die Bereitstellung des eigenständigen Agents mithilfe einer verwalteten Instanzgruppe automatisiert, die in der VPC des Kunden bereitgestellt wird. Der Agent erfasst Messwerte und Syslog-Logs von VMware vCenter und leitet sie an Cloud Monitoring und Cloud Logging weiter.
Sicherungen
Im Blueprint wird Backup and DR verwendet, um Datenschutzdienste für Ihre VMware-Arbeitslasten bereitzustellen. Der Dienst verwendet eine verwaltete Appliance, die in der VPC des Kunden bereitgestellt wird. Die Appliance ist über privaten Google-Zugriff und WebSockets mit der Google-Steuerungsebene verbunden. Sicherungen werden in Cloud Storage gespeichert. Der Dienst bietet detaillierte Wiederherstellungsoptionen, mit denen Sie einzelne Dateien oder ganze VMs zu einem bestimmten Zeitpunkt wiederherstellen können.
Best Practices für den Betrieb
In diesem Abschnitt werden einige der Best Practices beschrieben, die Sie je nach Umgebung und Anforderungen nach der Bereitstellung des Blueprints implementieren können.
Weitere Ersatzknoten hinzufügen
VMware Engine-Cluster werden automatisch so dimensioniert, dass sie zur Gewährleistung der Ausfallsicherheit mindestens einen freien Knoten bieten. Ein Ersatzknoten ist ein inhärentes Verhalten in vSphere HA. Das bedeutet, dass dieser Knoten im Cluster verfügbar ist und entsprechend abgerechnet wird.
Sie können dem Cluster weitere Ersatzknoten hinzufügen, um die Kapazität während der Wartungsfenster zu garantieren. Diese Entscheidung kann zusätzliche Kosten verursachen und diese Knoten werden direkt von Ihrer Organisation verwaltet.
Die hinzugefügten Ersatzknoten werden als zusätzliche Knoten in Ihrem vSphere-Cluster angezeigt. Optional können Sie Arbeitslasten auf den Ersatzknoten planen.
Ressourcenlimits für private Clouds berücksichtigen
Für private VMware Engine-Clouds gelten Ressourcenlimits für Compute-, Speicher- und Netzwerkkomponenten. Berücksichtigen Sie diese Limits bei der Bereitstellung Ihrer privaten Cloud, damit Ihre Umgebung mit den Anforderungen Ihrer Arbeitslast skaliert werden kann.
Optionen zur Kostenverwaltung implementieren
Sie haben folgende Möglichkeiten, Ihre Kosten zu verwalten:
- Rabatte für zugesicherte Nutzung (CUD)
- Autoscaling
- Beschränkungen der Anzahl der Kerne
- Überbuchung von Rechenkapazität
Rabatte für zugesicherte Nutzung verwenden
Rabatte für zugesicherte Nutzung sind Preisnachlässe für Nutzer, die sich verpflichten, für einen bestimmten Zeitraum ein Minimum an Ressourcen zu nutzen. VMware Engine-CUDs gelten für die aggregierte Nutzung von VMware Engine-Knoten in einer Region. Dadurch ergeben sich niedrige, vorhersehbare Kosten, ohne dass Sie selbst manuell Änderungen oder Aktualisierungen vornehmen müssen. Die Rabatte gelten für die Nutzung von VMware Engine-Knoten in den Regionen, in denen der Dienst verfügbar ist und in denen Sie die Rabatte für zugesicherte Nutzung erworben haben.
Autoscaling verwenden
Mit VMware Engine können Sie Knoten in einem Cluster automatisch hinzufügen oder entfernen lassen, wenn vordefinierte Grenzwerte und Wasserzeichen erreicht werden. Diese Richtlinien werden ausgelöst, wenn eine angegebene Bedingung mindestens 30 Minuten lang anhält. Beachten Sie beim Anwenden oder Aktualisieren einer Autoscaling-Richtlinie auf einen vSphere-Cluster (Standard oder Stretched) Folgendes:
- Standardmäßig ist Autoscaling deaktiviert. Sie müssen sie für jeden Cluster explizit aktivieren.
- In einem gestreckten Cluster wird die Anzahl der Knoten, die Sie in der Richtlinie angeben, pro Zone hinzugefügt oder entfernt, was sich entsprechend auf die Abrechnung auswirkt.
- Da die Rechenleistungs-, Arbeitsspeicher- und Speichernutzung oft voneinander unabhängig sind, verwenden Richtlinien zum Autoscaling, die mehrere Messwerte überwachen, die ODER-Logik für das Hinzufügen von Knoten und die UND-Logik für das Entfernen von Knoten.
- Die maximalen Autoscaling-Werte werden durch die Kontingente bestimmt, die in IhremGoogle Cloud -Projekt und Ihrer VMware Engine Private Cloud verfügbar sind.
- Die Aktivierung von Autoscaling und das manuelle Hinzufügen oder Entfernen eines Knotens schließen sich nicht gegenseitig aus. Mit der Richtlinie zur Optimierung der Speicherkapazität können Sie beispielsweise einen Knoten manuell entfernen, wenn Sie den VM-Festplattenspeicherplatz so weit reduzieren können, dass alle VMs im Cluster Platz finden. Das manuelle Entfernen von Knoten ist zwar möglich, aber keine Best Practice, wenn Autoscaling verwendet wird.
Anzahl der Kerne begrenzen
Mit VMware Engine können Administratoren die Anzahl der effektiven CPU-Kerne reduzieren, die dem Gastbetriebssystem (der VM, die auf VMware Engine ausgeführt wird) zur Verfügung stehen. Bei einigen Softwarelizenzvereinbarungen müssen Sie die Anzahl der bereitgestellten Kerne reduzieren.
VMware Engine-Rechenkapazität überbuchen
Die Überbuchung der Compute-Kapazität von VMware Engine ist eine Standardmethode und führt im Gegensatz zu Compute Engine-Knoten für einzelne Mandanten nicht zu zusätzlichen Gebühren. Ein höheres Überbuchungsverhältnis kann dazu beitragen, die Anzahl der tatsächlich abrechenbaren Knoten in Ihrer Umgebung zu verringern, kann sich aber auf die Anwendungsleistung auswirken. Bei der Dimensionierung von Enterprise-Arbeitslasten empfehlen wir, mit einem Verhältnis von 4:1 zu beginnen und das Verhältnis dann basierend auf Faktoren zu ändern, die für Ihren Anwendungsfall gelten.
Blueprint bereitstellen
Sie können den Blueprint für den Blueprint für Unternehmensgrundlagen oder Fabric FAST bereitstellen.
Führen Sie die folgenden Schritte aus, um den Blueprint im Blueprint für Unternehmensgrundlagen bereitzustellen:
- Blueprint für Unternehmensgrundlagen bereitstellen
- Stellen Sie den VMware Engine-Blueprint für Unternehmen bereit. Eine Anleitung dazu finden Sie im VMware Engine Enterprise Blueprint-Repository.
Informationen zum Bereitstellen des Blueprints in Fabric FAST finden Sie im Fabric FAST-Repository. Mit der Google Cloud VMware Engine-Phase wird der Enterprise-Blueprint für VMware Engine bereitgestellt.
Blueprint ohne Blueprint für Unternehmensgrundlagen oder Fabric FAST bereitstellen
Wenn Sie den Blueprint bereitstellen möchten, ohne zuerst den Blueprint für Unternehmensgrundlagen oder Fabric FAST bereitzustellen, prüfen Sie, ob die folgenden Ressourcen in Ihrer Umgebung vorhanden sind:
- Eine Organisationshierarchie mit den Ordnern
development,nonproductionundproduction - Ein freigegebene VPC-Netzwerk für jeden Ordner
- Ein IP-Adressschema, das die erforderlichen IP-Adressbereiche für Ihre VMware Engine-Private Clouds berücksichtigt
- DNS-Mechanismus für Ihre privaten VMware Engine-Clouds
- Firewallrichtlinien, die auf Ihren Sicherheitsstatus ausgerichtet sind
- Einen Mechanismus für den Zugriff auf Google Cloud APIs über interne IP-Adressen
- Einen Verbindungsmechanismus mit Ihrer lokalen Umgebung
- Zentrales Logging für Sicherheit und Audit
- Organisationsrichtlinien, die Ihrem Sicherheitsstatus entsprechen
- Eine Pipeline, mit der Sie VMware Engine bereitstellen können
Nächste Schritte
- Weitere Informationen zu VMware Engine
- VMware-VM-Instanzen in Ihre Private Cloud migrieren
- Best Practices für Compute
- Best Practices für Netzwerke
- Best Practices für die Sicherheit von VMware Engine
- Best Practices für die Speicherung
- Best Practices für die Kostenberechnung
- Rufen Sie die VMware Engine-Seite von VMware auf.