Viele Unternehmen möchten ihre VMware-Cluster in die Cloud verschieben, um von der Skalierbarkeit, Ausfallsicherheit, Elastizität und höheren Diensten wie Vertex AI Studio und BigQuery zu profitieren. Unternehmen möchten auch die Ausgaben von einem kapitalintensiven Hardwaremodell auf ein flexibleres Betriebskostenmodell verlagern. Um Unternehmen dabei zu unterstützen, schnell eine Betriebsumgebung zu erstellen, die den Best Practices von Google Cloud entspricht, haben wir den Google Cloud VMware Engine-Enterprise-Blueprint entwickelt. Dieser Blueprint bietet einen umfassenden Leitfaden zur Bereitstellung einer unternehmenstauglichen VMware-Umgebung, mit der Sie Ihre VM-Arbeitslasten in die Cloud migrieren können.
VMware Engine ist ein vollständig verwalteter Dienst, mit dem Sie die VMware-Plattform in Google Cloudausführen können. Ihre VMware-Arbeitslasten werden auf dedizierter Google Cloud -Hardware ausgeführt, die vollständig in die Google Cloud-Dienste eingebunden 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-zu-End-Trafficfluss ermöglichen.
Der VMware Engine-Enterprise-Blueprint umfasst Folgendes:
- GitHub-Repositories mit dem Terraform-Code und den Hilfsscripts, die für die Bereitstellung der VMware Engine-Plattform erforderlich sind
- Eine Anleitung zu den Architektur-, Netzwerk- und Sicherheitskontrollen, die Sie mit den GitHub-Repositories implementieren (dieses Dokument)
Der 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 erstellen.
Dieses Dokument richtet sich an Cloud-Architekten, Cloud-Plattformadministratoren, VMware Engine-Administratoren und VMware Engine-Entwickler, die mit dem Blueprint VMware-Cluster inGoogle Clouderstellen und bereitstellen können. Der Blueprint konzentriert sich auf das Design und die Bereitstellung einer neuen privaten VMware Engine-Cloud. Es wird davon ausgegangen, dass Sie mit VMware und dem verwalteten Dienst VMware Engine vertraut sind.
Übersicht über den VMware Engine-Enterprise-Blueprint
Der VMware Engine-Enterprise-Blueprint basiert auf einem mehrschichtigen Ansatz, um die VMware Engine-Plattform zu ermöglichen. Das folgende Diagramm zeigt die Interaktion verschiedener 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 grundlegende Ressourcen wie Netzwerk, Identität, Richtlinien, Monitoring und Logging. Mit diesen Ressourcen können Sie Google Cloud schnell einführen und gleichzeitig die Architekturanforderungen Ihrer Organisation erfüllen.
Der VMware Engine-Enterprise-Blueprint bietet 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
- Anwendungsfälle sind Rechenzentrumsmigrationen, die elastische Kapazitätserweiterung von Rechenzentren, die virtuelle Desktop-Infrastruktur (VDI) und Notfallwiederherstellungsszenarien für Rechenzentren.
Die Bereitstellungsautomatisierung mit einer CI/CD-Pipeline bietet Ihnen die Tools, um die Bereitstellung, Konfiguration und Verwaltung der Infrastruktur zu automatisieren. Mit Automatisierung können Sie für konsistente, zuverlässige und überprüfbare Bereitstellungen sorgen, manuelle Fehler minimieren und den gesamten Entwicklungszyklus beschleunigen.
Architektur
Das folgende Diagramm zeigt die Architektur, die mit dem VMware Engine-Enterprise-Blueprint bereitgestellt wird.
Der Blueprint führt Folgendes aus:
- Ein Google Cloud -Projekt namens Standalone VMware Engine Project, 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 VMware Engine Private 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 Oberfläche 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:Netzwerkvirtualisierungs- und Sicherheitssoftware
- VMware HCX: Anwendungsmigration und Arbeitslastausgleich zwischen Rechenzentren und Clouds
VMware Engine-Netzwerkübersicht
Das VMware Engine-Netzwerk ist ein dedikiertes Netzwerk, das die VMware Engine Private Cloud, VPC-Netzwerke und lokale Umgebungen verbindet. Das VMware Engine-Netzwerk bietet folgende Funktionen:
- Private Cloud-Konnektivität: Jede private VMware Engine-Cloud ist mit einem VMware Engine-Netzwerk verbunden, was die Kommunikation zwischen Arbeitslasten innerhalb der privaten Cloud ermöglicht.
- VMware Engine-Netzwerkverbindung: Mit VPC-Netzwerk-Peering können Sie eine Verbindung zwischen VMware Engine-Netzwerken und einer Google-VPC herstellen. Diese Konnektivität ermöglicht die Kommunikation zwischen Arbeitslasten, die in der VMware Engine und in anderen Diensten in Google Cloudausgeführt werden.
- On-Premises-Konnektivität:Wenn Sie eine Hybrid-Cloud-Lösung erstellen möchten, können Sie VMware Engine-Netzwerke mithilfe von Cloud VPN oder Cloud Interconnect auf lokale Rechenzentren ausweiten.
- Netzwerkdienste: In VMware Engine-Netzwerken werden verschiedene Netzwerkdienste verwendet, darunter:
Bei 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 die Behebung von Fehlern bei Komponenten verantwortlich.
Wichtige Architekturentscheidungen
| Entscheidungsbereich | Entscheidungs- | Begründung der Entscheidung |
|---|---|---|
| Stiftung | Sie können den VMware Engine-Enterprise-Blueprint 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 oder zwei private Cluster in zwei Regionen bereitstellen. | Die Konfiguration eines einzelnen privaten Clusters ermöglicht eine vereinfachte Verwaltung und Kostenoptimierung. |
| Der Blueprint stellt einen Ersatzknoten bereit. | Mit einem einzelnen Ersatzknoten können Sie Ausfälle, Wartungsereignisse und Arbeitslastschwankungen bewältigen und gleichzeitig die Kosten minimieren. | |
| Sicherung und Notfallwiederherstellung werden über den Sicherungs- und Notfallwiederherstellungsdienst verwaltet. | Mit Sicherung und Notfallwiederherstellung können Sie einen verwalteten Dienst verwenden und den Verwaltungsaufwand für die Bereitstellung der VMware Engine reduzieren. | |
| Netzwerk | Der Blueprint ermöglicht eine Hybridkonnektivität. | Mit Hybridkonnektivität können Sie Ihre lokale Umgebung mit Ihrer Google Cloud -Umgebung verbinden. |
| In einer privaten Cloud wird ein privater, routbarer und zusammenhängender IP-Bereich verwendet. | Durch einen zusammenhängenden IP-Adressbereich wird die Verwaltung der IP-Adressen vereinfacht. Wenn der IP-Bereich routbar ist, kann die Private Cloud mit Ihren lokalen Ressourcen kommunizieren. | |
| Der Internetzugriff wird über einen Cloud Load Balancing bereitgestellt und durch Google Cloud Armor geschützt. | Google Cloud Armor verbessert die Sicherheit der Arbeitslast, während Cloud Load Balancing die Skalierbarkeit und Hochverfügbarkeit der Arbeitslast ermöglicht. | |
| Im Blueprint ist Cloud DNS aktiviert. | Cloud DNS löst interne und externe Namen auf. |
Plattformidentitäten
Der Blueprint verwendet zwei Nutzergruppen: eine Cloud-Plattform-Entwicklergruppe und eine VMware-Plattform-Entwicklergruppe. Diese Gruppen haben folgende Aufgaben:
- Die Cloud Platform 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 auf dem Blueprint für Unternehmensgrundlagen oder Fabric FAST bereitstellen, wird die Cloud-Plattform-Engineering-Gruppe im Rahmen des ersten Bereitstellungsvorgangs erstellt. Die VMware-Plattform-Engineering-Gruppe wird im Rahmen dieses Blueprints bereitgestellt.
Organisationsstruktur
Der VMware Engine-Enterprise-Blueprint baut auf der vorhandenen Organisationsstruktur des Blueprints für Unternehmensgrundlagen und Fabric FAST auf. 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 VMware Engine-Enterprise-Blueprint bietet Ihnen die folgenden Netzwerkoptionen:
- Ein einzelnes freigegebene VPC-Netzwerk für eine VMware Engine Private Cloud
- Zwei freigegebene VPC-Instanzen für eine private Cloud
Beide Optionen werden in einer einzigen Region bereitgestellt und ermöglichen die Verwaltung von Traffic aus Ihrer lokalen Umgebung.
Das folgende Diagramm zeigt ein einzelnes freigegebene VPC-Netzwerk für eine einzelne Region.
Mit separaten gemeinsam genutzten VPC-Instanzen können Sie Kosten und Netzwerkverkehr in verschiedene Geschäftsbereiche gruppieren und gleichzeitig die logische Trennung in der VMware Engine-Private Cloud beibehalten. Das folgende Diagramm zeigt mehrere freigegebene VPC-Netzwerke in einer einzelnen Region.
Privates Cloud-Netzwerk
In der privaten Cloud wird das Netzwerk von NSX-T verwaltet, das eine Software-definierte Netzwerkschicht mit erweiterten Funktionen wie Mikrosegmentierung, Routing und Load Balancing 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 innerhalb 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. In der folgenden Tabelle wird anhand des Beispiel-CIDR-Bereichs 10.0.0.0/24 der IP-Adressbereich des Blueprints für seine Verwaltungssubnetze dargestellt.
| 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- (Erweiterung) Appliances, um ihre Peers zu erreichen und das Erstellen des HCX-Dienst-Meshes zu ermöglichen | 10.0.0.216/29 |
Die Arbeitslast-VMs befinden sich im NSX-T-Subnetz. NSX-T-Edge-Uplinks bieten eine externe Konnektivität. Die Größe des CIDR-Bereichs Ihrer privaten Cloud definiert die Anzahl der ESXi-Knoten, die im NSX-T-Subnetz unterstützt werden können. ESXi-Knoten verwenden das VSAN-Subnetz für den Speichertransport.
Die folgende Tabelle enthält 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 Speichertraffic zwischen ESXi-Hosts und VSAN-Speicherclustern verantwortlich. | 10.0.0.80/28 |
| Host-Transport in NSX-T | Das VLAN und das 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 Subnetz des Edge-Dienstes weist die VMware Engine keinen CIDR-Bereich oder ‑präfix zu. Daher müssen Sie einen sich nicht überschneidenden CIDR-Bereich und ein Präfix angeben. Die folgende Tabelle enthält die CIDR-Blöcke des Blueprints für die Dienst-Subnetze und das Edge-Dienst-Subnetz.
| Subnetz | Beschreibung | IP-Adressbereich |
|---|---|---|
| Service-N [N=1-5] | Mit Dienstsubnetzen können virtuelle Maschinen den NSX-Transport umgehen und direkt mit der Google Cloud -Netzwerkinfrastruktur kommunizieren, um eine Hochgeschwindigkeitskommunikation zu ermöglichen. |
|
| Edge-Dienst | Erforderlich, wenn optionale Edge-Dienste wie Point-to-Site-VPN, Internetzugriff und externe IP-Adresse aktiviert sind. Die 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 ausgeweitet werden, wird die gesamte Kommunikation innerhalb von VMware Engine und zu externen IP-Adressen standardmäßig (über Layer 3) weitergeleitet. Der Blueprint konfiguriert einen Cloud Router, der mit der lokalen Hybridverbindung (über Cloud VPN oder Cloud Interconnect) verknüpft ist, mit benutzerdefinierten beworbenen Routen für die IP-Adressbereiche der VMware Engine. NSX-Segmentrouten werden auf Tier-0-Ebene zusammengefasst. Der Blueprint ermöglicht DHCP-Dienste über das NSX-T-DHCP-Relay für die DHCP-Dienste, 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 und einzelne private Clouds konfigurieren, können Sie die globale Adressauflösung mit Cloud DNS einrichten.
Standardmäßig können Sie die Verwaltungszone von jedem Ihrer VPC-Netzwerke auflösen, in dem Cloud DNS aktiviert ist.
Wenn mit dem Blueprint eine private Cloud erstellt wird, die mit einem Standardnetzwerk von VMware Engine verknüpft ist, wird eine zugehörige Verwaltungs-DNS-Zone erstellt und automatisch mit den Einträgen der Verwaltungs-Appliances ausgefüllt.
Wenn das Standard-VMware Engine-Netzwerk ein VPC-Netzwerk ist, das mit einem VPC oder einem anderen VMware Engine-Netzwerk verbunden ist, wird im Blueprint automatisch eine Bindung für die Verwaltungs-DNS-Zone erstellt. Diese Zonenbindung sorgt für die Auflösung von Verwaltungs-Appliances von Ihren Google Cloud -VMs in diesem Netzwerk. Das folgende Diagramm zeigt die Cloud DNS-Topologie.
Ausgehender Traffic von VMware Engine ins Internet
Der Blueprint bietet die folgenden drei Optionen für ausgehenden Traffic von der VMware Engine ins Internet:
- Ausgehend über die lokale Umgebung des Kunden
- Ausgehender Traffic über das Internet-Gateway von VMware Engine
- Ausgehend über das verbundene VPC des Kunden mit einer externen IP-Adresse
Das folgende Diagramm zeigt diese Optionen.
Eingehender Traffic vom Internet zu VMware Engine
Der Blueprint bietet die folgenden drei Optionen für Traffic, der vom Internet in die VMware Engine fließt:
- Eingehend über die lokale Umgebung des Kunden
- Eingehend über eine Kunden-VPC mit Cloud Load Balancing und möglicherweise Google Cloud Armor
- Eingehend über VMware Engine mit einer externen IP-Adresse
Das folgende Diagramm zeigt diese Optionen.
Logging
Mit dem Blueprint können Sie die Verwaltungsaktionen der VMware Engine über einen Log-Sink 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 gesetzlichen Bestimmungen nachweisen.
Protokollexporte können auch als Datenaufnahmequellen für SIEM-Systeme (Security Information and Event Management) dienen. Google unterstützt die folgenden Datenaufnahmequellen für VMware Engine:
- Die Hosting- Google Cloud -Organisation, einschließlich Cloud Fabric und Asset-Telemetrie
- VMware-Dienstkomponenten
- In VMware Engine ausgeführte Arbeitslasten
Google SecOps enthält eine integrierte automatisierte Pipeline für die Datenaufnahme, um Organisationsdaten zu erfassen. Außerdem bietet es Weiterleitungssysteme, um Streaming-Telemetriedaten von der VMware Engine und Arbeitslasten in die Google SecOps-Aufnahmepipeline zu schieben. Google SecOps ergänzt die Telemetrie um kontextbezogene Inhalte und macht sie suchbar. Mit Google SecOps können Sie Sicherheitsprobleme erkennen und im Blick behalten, sobald sie auftreten.
Monitoring
Mit dem Blueprint wird ein eigenständiger Agent für Cloud Monitoring installiert, um Messwerte aus Ihrer privaten Cloud an Cloud Monitoring weiterzuleiten. Mit dem Blueprint werden vordefinierte Dashboards eingerichtet, die einen Überblick über Ihre VMware Engine-Ressourcen und die Ressourcenauslastung bieten. VMware vCenter Server bietet Tools, mit denen Sie Ihre Umgebung überwachen und die Ursache von Problemen ermitteln können. Sie können diese Tools im Rahmen Ihrer laufenden Abläufe und als Ergänzung zu anderen Monitoring-Optionen verwenden.
Wie im folgenden Diagramm zu sehen, automatisiert der Blueprint die Bereitstellung des eigenständigen Agents mithilfe einer verwalteten Instanzgruppe, die im VPC des Kunden bereitgestellt wird. Der Agent erfasst Messwerte und Syslog-Logs aus VMware vCenter und leitet sie an Cloud Monitoring und Cloud Logging weiter.
Sicherungen
Der Blueprint verwendet Sicherung und Notfallwiederherstellung, um Ihren VMware-Arbeitslasten Datenschutzdienste zur Verfügung zu stellen. Der Dienst verwendet eine verwaltete Appliance, die in der VPC des Kunden bereitgestellt wird. Die Appliance ist über den privaten Google-Zugriff und WebSockets mit der Google-Steuerungsebene verbunden. Back-ups 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 die Betriebsabläufe
In diesem Abschnitt werden einige 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 haben automatisch eine Größe, die zur Gewährleistung der Ausfallsicherheit mindestens einen freien Knoten bietet. Ein Ersatzknoten ist ein inhärentes Verhalten von vSphere HA. Das bedeutet, dass dieser Knoten im Cluster verfügbar ist und entsprechend in Rechnung gestellt wird.
Sie können dem Cluster weitere Ersatzknoten hinzufügen, um während Wartungsfenstern eine garantierte Kapazität zu erhalten. Dadurch können zusätzliche Verbrauchskosten anfallen. Diese Knoten werden direkt von Ihrer Organisation verwaltet.
Die hinzugefügten Ersatzknoten werden in Ihrem vSphere-Cluster als zusätzliche Knoten angezeigt. Optional können Sie Arbeitslasten auf den Ersatzknoten planen.
Ressourcenlimits für private Clouds beachten
Für private VMware Engine-Clouds gelten Ressourcenlimits für Rechen-, 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 können eine oder mehrere der folgenden Optionen implementieren, um Ihre Kosten zu verwalten:
- Rabatte für zugesicherte Nutzung (CUD)
- Autoscaling
- Limits für die Anzahl der Kerne
- Überbuchung der 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 CUDs erworben haben.
Autoscaling verwenden
Mit VMware Engine können Sie Knoten in einem Cluster basierend auf vordefinierten Grenzwerten und Markierungen automatisch hinzufügen oder entfernen. Diese Richtlinien werden ausgelöst, wenn eine bestimmte Bedingung mindestens 30 Minuten lang erfüllt ist. Beachten Sie Folgendes, wenn Sie eine Autoscaling-Richtlinie auf einen vSphere-Cluster (Standard- oder Stretched-Cluster) anwenden oder aktualisieren:
- Standardmäßig ist Autoscaling deaktiviert. Sie müssen sie für jeden Cluster explizit aktivieren.
- In einem vernetzten Cluster werden die in der Richtlinie angegebenen Knoten pro Zone hinzugefügt oder entfernt. Dies wirkt sich entsprechend auf die Abrechnung aus.
- 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 Werte für die automatische Skalierung werden durch die Kontingente bestimmt, die in IhremGoogle Cloud -Projekt und in der VMware Engine Private Cloud verfügbar sind.
- Das Aktivieren des Autoscalings und das manuelle Hinzufügen oder Entfernen eines Knotens schließen sich nicht aus. Mit der Richtlinie zur Optimierung der Speicherkapazität können Sie beispielsweise einen Knoten manuell entfernen, wenn Sie den VM-Speicherplatz so weit reduzieren können, dass alle VMs im Cluster Platz finden. Das manuelle Entfernen von Knoten ist zwar möglich, wird aber bei der Verwendung von Autoscaling nicht empfohlen.
Anzahl der Kerne begrenzen
Mit VMware Engine können Administratoren die Anzahl der effektiven CPU-Kerne reduzieren, die dem Gastbetriebssystem (der VM, die auf der VMware Engine ausgeführt wird) zur Verfügung gestellt werden. Einige Softwarelizenzvereinbarungen erfordern, dass Sie die Anzahl der freigegebenen Kerne reduzieren.
VMware Engine-Rechenkapazität überbuchen
Eine Überbuchung der Rechenkapazität der VMware Engine ist eine gängige Praxis und verursacht im Gegensatz zu Compute Engine-Knoten für einzelne Mandanten keine zusätzlichen Kosten. Ein höheres Überbuchungsverhältnis kann Ihnen helfen, die Anzahl der effektiv abrechenbaren Knoten in Ihrer Umgebung zu verringern, sich aber auf die Anwendungsleistung auswirken. Wir empfehlen, für die Größe von Enterprise-Arbeitslasten ein Verhältnis von 4:1 zu verwenden und es dann basierend auf Faktoren anzupassen, die für Ihren Anwendungsfall gelten.
Blueprint bereitstellen
Sie können den Blueprint auf dem Blueprint für Unternehmensgrundlagen oder auf Fabric FAST bereitstellen.
Führen Sie die folgenden Schritte aus, um den Blueprint im Blueprint für Unternehmensgrundlagen bereitzustellen:
- Bereitstellen des Blueprints für Unternehmensgrundlagen
- Stellen Sie den VMware Engine-Enterprise-Blueprint bereit. Eine Anleitung finden Sie im Repository für VMware Engine-Enterprise-Blueprints.
Informationen zum Bereitstellen des Blueprints in Fabric FAST finden Sie im Fabric FAST-Repository. In der Google Cloud VMware Engine-Phase wird der VMware Engine-Enterprise-Blueprint bereitgestellt.
Blueprint ohne Blueprint für Unternehmensgrundlagen oder Fabric FAST bereitstellen
Wenn Sie den Blueprint bereitstellen möchten, ohne zuvor 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 zur VMware Engine
- Weitere Informationen zum Migrieren von VMware-VM-Instanzen in Ihre private Cloud
- Best Practices für die Datenverarbeitung
- Best Practices für Netzwerke
- Best Practices für die Sicherheit von VMware Engine
- Best Practices für den Speicher
- Best Practices für die Kostenkalkulation
- Rufen Sie die VMware Engine-Seite von VMware auf.