Knoten und VCF mit Terraform und Toolkit bereitstellen

In diesem Dokument wird erläutert, wie Sie mit der Terraform-Automatisierung Bare-Metal-ESXi-Knoten, Layer-2-Broadcast-Netzwerke, Cloud DNS und regionale interne Load Balancer (ILBs) für die VMware-Lösung in Google Cloud mit VMware Cloud Foundation (VCF) bereitstellen.

Die Automatisierung stellt die folgende Infrastruktur bereit:

  • Dedizierte Bare-Metal-ESXi-Hypervisoren (z3-highmem-192-highlssd-metal oder z3-highmem-192-metal).
  • Multi-VLAN-Layer-2-Broadcast-Netzwerke mit Jumbo Frames (MTU 8896).
  • Private verwaltete Cloud DNS-Zonen und Richtlinien für die Weiterleitung eingehender Abfragen.
  • Regionale ILBs mit Gratuitous ARP / Router Advertisement (GARP_RA) Fast IP Move-Hochverfügbarkeit.
  • Zonale Netzwerk-Endpunktgruppen (NEGs) für Verwaltungs- und NSX-Datenpfadschnittstellen.

Hinweis

Bevor Sie die Terraform-Automatisierung ausführen, installieren Sie die erforderlichen Tools, aktivieren Sie die erforderlichen APIs, setzen Sie Layer-2-Subnetzwerke auf die Zulassungsliste und prüfen Sie die folgenden Anforderungen für Ihr Google Cloud -Projekt:

  1. Prüfen Sie, ob Ihr Projekt in der Zielregion und -zone über ein ausreichendes Kontingent für Bare-Metal-Knoten verfügt. Informationen zu den erforderlichen Kontingenten und eine Anleitung zum Aufrufen oder Anfordern von Kontingenterhöhungen finden Sie unter Kontingente und Limits.
  2. Prüfen Sie, ob Sie die erforderlichen IAM-Berechtigungen (Identity and Access Management) haben, einschließlich Compute Admin (roles/compute.admin) und, wenn Sie Cloud DNS verwenden, DNS Administrator (roles/dns.admin).
  3. Planen Sie Ihre DNS-Infrastruktur (Domain Name System) so, dass sie Forward- und Reverse-Lookups für alle geplanten ESXi-Knotenhostnamen und VCF-Appliance-Endpunkte unterstützt.
  4. Knotenhostnamen: Geben Sie während der Bereitstellung den voll qualifizierten Domainnamen (FQDN) jedes Knotens an. Dadurch wird sichergestellt, dass ESXi Zertifikate mit Hostnamen generiert.
  5. Trusted Image-Richtlinie: Wenn Ihre Organisation die Organisationsrichtlinie constraints/compute.trustedImageProjects nicht erzwingt, ist keine Aktion erforderlich. Wenn Ihre Organisation diese Richtlinie erzwingt, lassen Sie projects/smve-prod-public-images zu, damit Compute Engine Bare-Metal-Bootlaufwerke erstellen kann. Weitere Informationen finden Sie unter Einschränkungen für den Image-Zugriff festlegen.

  6. VPC Service Controls: Wenn sich Ihr Zielprojekt nicht in einem Dienstperimeter befindet, ist keine Aktion erforderlich. Wenn sich Ihr Projekt in einem Dienstperimeter befindet, fügen Sie eine Regel für ausgehenden Traffic hinzu, die compute.googleapis.com-Vorgänge für das smve-prod-public-images-Projekt (projects/999037279871) zulässt:

    - egressFrom:
    identityType: ANY_IDENTITY
  egressTo:
    operations:
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/999037279871

    Weitere Informationen finden Sie in der Referenz zu Regeln für ausgehenden Traffic.

Terraform installieren

Sie müssen die Terraform-Befehlszeile in der Version 1.3.0 oder höher installieren. Wählen Sie zum Installieren von Terraform den Tab für Ihr Betriebssystem aus:

Debian oder Ubuntu

Führen Sie die folgenden Befehle aus, um Terraform unter Debian oder Ubuntu zu installieren:

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common curl
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com '"$(lsb_release -cs)"' main' | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt-get update && sudo apt-get install -y terraform

RHEL oder CentOS

Führen Sie die folgenden Befehle aus, um Terraform unter RHEL oder CentOS zu installieren:

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo yum -y install terraform

Generisches Linux

Führen Sie die folgenden Befehle aus, um Terraform durch direktes Herunterladen der Binärdatei zu installieren:

export TERRAFORM_VERSION='1.9.5'
curl -fsSLO 'https://releases.hashicorp.com/terraform/'"${TERRAFORM_VERSION}"'/terraform_'"${TERRAFORM_VERSION}"'_linux_amd64.zip'
unzip 'terraform_'"${TERRAFORM_VERSION}"'_linux_amd64.zip'
sudo mv terraform /usr/local/bin/
rm 'terraform_'"${TERRAFORM_VERSION}"'_linux_amd64.zip'

Google Cloud -APIs aktivieren

Aktivieren Sie die folgenden erforderlichen APIs in Ihrem Google Cloud -Zielprojekt:

Dienstendpunkt Zweck
compute.googleapis.com Bare-Metal-Instanzen, VPC-Netzwerke (Virtual Private Cloud), Layer-2-Subnetze, Firewalls, NEGs, regionale ILBs und statische IP-Reservierungen.
dns.googleapis.com Private verwaltete Forward- und Reverse-DNS-Zonen, Richtlinien für die eingehende Weiterleitung und DNS-Eintragssätze.

Führen Sie den folgenden Befehl aus, um die erforderlichen APIs mithilfe der gcloud-CLI zu aktivieren:

gcloud services enable \
    compute.googleapis.com \
    dns.googleapis.com \
    --project='PROJECT_ID'

Ersetzen Sie PROJECT_ID durch die ID Ihres Zielprojekts in Google Cloud .

Regionales Kontingent prüfen

Bevor Sie Bare-Metal-Knoten bereitstellen oder einen Cluster erstellen, prüfen Sie, ob Ihr Projekt über ein ausreichendes regionales und globales Compute Engine-Kontingent verfügt. Fügen Sie die Ressourcen aller vorhandenen Cluster in der Region den folgenden inkrementellen Werten hinzu, bevor Sie sie mit Ihrem Projektkontingent vergleichen:

Kontingent Erforderliche Ressourcen pro Bare-Metal-Knoten Erforderliche Ressourcen für einen Cluster mit 3 Knoten
compute.googleapis.com/cpus_per_vm_family für Z3 192 vCPUs 3 × 192 = 576 vCPUs
compute.googleapis.com/local_ssd_total_storage_per_vm_family für Z3 72 TB 3 × 72 TB = 216 TB
compute.googleapis.com/hyperdisk_balanced_total_storage 128 GB 3 × 128 GB = 384 GB
compute.googleapis.com/resource_policies 0, wenn Knoten zu einem vorhandenen Cluster hinzugefügt werden 1 Richtlinie für verteilte Platzierung pro Cluster
compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha 0, wenn Knoten oder Cluster ohne neue Appliances hinzugefügt werden 1 pro neuer VCF-Verwaltungs-Appliance-VIP oder NSX Edge-Endpunkt

Eine vollständige Liste der erforderlichen Kontingente und eine Anleitung zum Aufrufen oder Anfordern von Kontingenterhöhungen finden Sie unter Kontingente und Limits.

VLAN-basiertes Layer-2-Subnetzwerk auf die Zulassungsliste setzen

Für die VMware-Lösung muss für die Subnetze Ihres VPC-Netzwerks (Virtual Private Cloud) das Attribut Subnetzmaske auflösen auf Primären Bereich nur mit Lernen übertragen festgelegt sein, um VLAN-basiertes Netzwerk zu unterstützen. Öffnen Sie im Google Cloud Console-Supportcenter ein Support-Ticket mit den folgenden Informationen:

  • Produkt: Google Cloud VMware Engine
  • Priorität: P2
  • Kategorie: Network Connectivity
  • Auswirkungen auf das Geschäft: Allgemeine technische Frage
  • Geben Sie weitere Details an: Allowlist L2 network connectivity for my project, zusammen mit Ihrer Projekt-ID, Projektnummer und der Zielregion und -zone für Ihre Bereitstellung.

Weitere Informationen zur Unterstützung von VLAN-basierten Netzwerken finden Sie unter Layer-2-Emulation: ARP-Broadcasting und benutzerdefiniertes MAC-Learning.

Organisationsrichtlinie und VPC Service Controls konfigurieren

Bare-Metal-ESXi-Instanzen in der VMware-Lösung werden von von Google bereitgestellten ESXi-Images gestartet, die im Projekt smve-prod-public-images mit der Projektnummer 999037279871 gehostet werden. Standardmäßig ist keine zusätzliche Konfiguration erforderlich. Wenden Sie die folgenden Konfigurationen nur an, wenn Ihre Organisation eine Trusted Image-Richtlinie erzwingt oder VPC Service Controls verwendet:

  • Trusted Image-Richtlinie: Wenn Ihre Organisation die Organisationsrichtlinie constraints/compute.trustedImageProjects nicht erzwingt, ist keine Aktion erforderlich. Wenn Ihre Organisation diese Richtlinie erzwingt, lassen Sie projects/smve-prod-public-images zu, damit Compute Engine Bare-Metal-Bootlaufwerke erstellen kann. Weitere Informationen finden Sie unter Einschränkungen für den Image-Zugriff festlegen.

  • VPC Service Controls-Regel für ausgehenden Traffic: Wenn sich Ihr Zielprojekt nicht in einem Dienstperimeter befindet, ist keine Aktion erforderlich. Wenn sich Ihr Projekt in einem Dienstperimeter befindet, fügen Sie eine Regel für ausgehenden Traffic hinzu, die compute.googleapis.com-Vorgänge für das smve-prod-public-images-Projekt (projects/999037279871) zulässt:

    - egressFrom:
    identityType: ANY_IDENTITY
  egressTo:
    operations:
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/999037279871

    Weitere Informationen finden Sie in der Referenz zu Regeln für ausgehenden Traffic.

IAM-Berechtigungen und -Rollen konfigurieren

Die Identität, die Terraform ausführt (ein menschlicher Administrator oder ein automatisiertes CI/CD-Dienstkonto), benötigt die folgenden IAM-Rollen für das Zielprojekt vonGoogle Cloud :

Rolle Rollen-ID Nutzungsumfang
Compute-Administrator roles/compute.admin Bare-Metal-Compute-Instanzen bereitstellen, benutzerdefinierte Bootlaufwerk-Images anhängen, Platzierungsrichtlinien konfigurieren und Multi-NIC-Schnittstellen verwalten. VPC-Netzwerke, Layer-2-Broadcast-Subnetze, statische IP-Reservierungen, regionale ILBs, Backend-Dienste, Weiterleitungsregeln und zonale NEGs verwalten. VPC-Firewallregeln für eingehenden Traffic erstellen und verwalten
DNS-Administrator roles/dns.admin Private Cloud DNS-Weiterleitungs- und Reverse-Zonen, Richtlinien für die Weiterleitung eingehender Abfragen sowie A- und PTR-Ressourceneintragssätze verwalten.
Dienstkontonutzer roles/iam.serviceAccountUser Weisen Sie diese Rolle dem Compute Engine-Standarddienstkonto (PROJECT_NUMBER-compute@) zu, um die Instanzbereitstellung mit dem Bereich cloud-platform zu ermöglichen.

Rollen mit der gcloud CLI zuweisen

Führen Sie die folgenden Befehle aus, um die erforderlichen Rollen auf Projektebene und Dienstkontoberechtigungen zuzuweisen:

# Assign required project-level roles (use 'serviceAccount:SA_EMAIL' if granting to a service account)
for ROLE in \
    roles/compute.admin \
    roles/dns.admin; do
  gcloud projects add-iam-policy-binding 'PROJECT_ID' \
      --member='user:USER_EMAIL' \
      --role=${ROLE}
done
# Grant Service Account User role on the Compute Engine default service account
gcloud iam service-accounts add-iam-policy-binding \
    'PROJECT_NUMBER-compute@' \
    --member='user:USER_EMAIL' \
    --role='roles/iam.serviceAccountUser' \
    --project='PROJECT_ID'

Ersetzen Sie vor dem Ausführen der Befehle Folgendes:

  • PROJECT_ID: Die ID Ihres Zielprojekts in Google Cloud .
  • PROJECT_NUMBER: Die Projektnummer Ihres Zielprojekts in Google Cloud.
  • USER_EMAIL: Die E-Mail-Adresse Ihrer Nutzeridentität.

Terraform-Runner authentifizieren

Wählen Sie je nach Betriebsumgebung eine der folgenden Authentifizierungsstrategien aus:

Mit Identitätsübernahme des Dienstkontos authentifizieren

Durch die Identitätsübernahme des Dienstkontos werden langlebige Anmeldedatenschlüssel eliminiert, da kurzlebige OAuth 2.0-Zugriffstokens generiert werden. Ihre persönliche Identität wird authentifiziert, während Terraform als das angegebene Dienstkonto ausgeführt wird.Google Cloud prüft die von Terraform ausgeführten Aktionen anhand des Dienstkontos.

  1. Weisen Sie Ihrer persönlichen Google Cloud -Identität die Rolle „Ersteller von Dienstkonto-Tokens“ (roles/iam.serviceAccountTokenCreator) für das Runner-Dienstkonto zu:

    gcloud iam service-accounts add-iam-policy-binding 'SA_EMAIL' \
   --member='user:USER_EMAIL' \
   --role='roles/iam.serviceAccountTokenCreator' \
   --project='PROJECT_ID'

    Ersetzen Sie vor dem Ausführen des Befehls Folgendes:

    • SA_EMAIL: Die E-Mail-Adresse des Terraform-Runner-Dienstkontos.
    • USER_EMAIL: Die E-Mail-Adresse Ihrer persönlichen Google Cloud-Identität.
    • PROJECT_ID: Die ID Ihres Zielprojekts in Google Cloud .

  2. Authentifizieren Sie Ihre lokale Umgebung:

    gcloud auth application-default login

  3. Legen Sie die Umgebungsvariable GOOGLE_IMPERSONATE_SERVICE_ACCOUNT fest, um die Identitätsübernahme für alle Terraform-Ausführungen zu erzwingen:

    export GOOGLE_IMPERSONATE_SERVICE_ACCOUNT='SA_EMAIL'

Mit Standardanmeldedaten für Anwendungen authentifizieren

Verwenden Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) in Entwicklungs- und Testumgebungen, in denen Ihre Nutzeridentität direkt die erforderlichen Berechtigungen hat.Google Cloud prüft Aktionen anhand Ihrer persönlichen Identität:

gcloud auth application-default login
gcloud config set project 'PROJECT_ID'

Ersetzen Sie PROJECT_ID durch die ID Ihres Zielprojekts in Google Cloud .

Mit einer Dienstkonto-Schlüsseldatei authentifizieren

Verwenden Sie eine Dienstkontoschlüsseldatei in automatisierten CI/CD-Pipelines (z. B. Cloud Build, GitHub Actions oder Jenkins), in denen die interaktive Nutzeranmeldung nicht unterstützt wird und die Authentifizierung auf langlebigen Dienstkonto-Anmeldedatenschlüsseln basiert. Legen Sie die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS auf den Pfad der Schlüsseldatei Ihres Dienstkontos fest:

export GOOGLE_APPLICATION_CREDENTIALS='KEY_FILE'

Ersetzen Sie KEY_FILE durch den Pfad zum JSON-Schlüssel Ihres Dienstkontos.

Modulare Architektur prüfen

Terraform koordiniert die Ressourcenbereitstellung über vier modulare Phasen. Dieses modulare Design erzwingt eine strikte Abhängigkeitsreihenfolge, um sicherzustellen, dass die Netzwerkvoraussetzungen erfüllt sind, bevor Sie Compute-Hosts, Load Balancer und DNS-Einträge bereitstellen:

+-----------------------------------------------------------------------------------+
| STAGE 1: VPC Network Infrastructure, Firewalls & Cloud DNS (modules/vpc)          |
| - Custom VPC Network (MTU 8896 jumbo frames)                                      |
| - VPC Ingress Allow-All Firewall Rule                                             |
| - Dedicated Standard Subnetwork (for DNS inbound resolver)                        |
| - Cloud DNS Private Forward & Reverse Managed Zones                               |
| - Cloud DNS Inbound Forwarding Policy (Dynamic DNS_RESOLVER IP discovery)         |
+-----------------------------------------------------------------------------------+
                                         │
                                         ▼
+-----------------------------------------------------------------------------------+
| STAGE 2: L2 Broadcast Subnetworks & Zonal NEGs (modules/subnets)                  |
| - Primary Management Subnet (Untagged Native VLAN, ARP broadcast learning)        |
| - Storage & Infrastructure Subnets: vSAN (VLAN tagged), vMotion, NSX TEP          |
| - Optional Dynamic Workload Subnets                                               |
| - Zonal Network Endpoint Groups (GCE_VM_IP_DEDICATED_BACKEND) for Mgmt & NSX TEP   |
+-----------------------------------------------------------------------------------+
                                         │
                                         ▼
+-----------------------------------------------------------------------------------+
| STAGE 3: Bare-Metal ESXi Hosts, IP Allocations & Host DNS (modules/hosts)         |
| - Compute Resource Placement Policy (Availability Domain Count: 5-8, default: 6)  |
| - Universal IP Allocator: Static reservations & dynamic allocation for all NICs   |
| - Bare-Metal ESXi Instances (z3-highmem-192-highlssd-metal, 4+ Multi-NICs)        |
| - Automated NEG Endpoint Attachments (in cluster_creation mode)                   |
| - Cloud DNS Forward (A) and Reverse (PTR) Records for all ESXi Hosts              |
+-----------------------------------------------------------------------------------+
                                         │
                                         ▼
+-----------------------------------------------------------------------------------+
| STAGE 4: Regional Internal Load Balancers & Appliances (modules/appliances)       |
| - Regional Backend Services (GARP_RA Fast IP Move HA Policy)                      |
| - Regional Forwarding Rules (L3_DEFAULT / ALL_PORTS / allow_global_access)        |
| - Automated Cloud DNS Forward (A) and Reverse (PTR) Records for Mgmt Appliances   |
+-----------------------------------------------------------------------------------+

Ressourcen für den Verwaltungscluster bereitstellen

Der Verwaltungscluster der Verwaltungsdomain hostet die wichtigsten VCF-Steuerungsebenen-Appliances (SDDC Manager, vCenter Server, NSX-Verwaltungscluster und VMware Aria Suite) und ESXi-Hypervisoren.

Terraform-Arbeitsbereich einrichten

Erstellen Sie ein dediziertes Arbeitsbereichsverzeichnis und klonen Sie das Toolkit-Repository mit Git:

mkdir -p ~/vcf-deployments/mgmt-cluster
cd ~/vcf-deployments/mgmt-cluster
git clone https://github.com/GoogleCloudPlatform/self-managed-vmware-solution-toolkit

Datei mit Variablendefinitionen konfigurieren

Erstellen Sie die Variablendefinitionsdatei (management_cluster.tfvars) mit den Werten für Ihre Zielumgebung. Kopieren Sie die Datei sample_management_cluster.tfvars aus dem Verzeichnis e2e-terraform in Ihre Datei management_cluster.tfvars und folgen Sie der Inline-Anleitung und den Kommentaren, um alle Felder nach Bedarf zu aktualisieren:

cp self-managed-vmware-solution-toolkit/e2e-terraform/sample_management_cluster.tfvars \
    self-managed-vmware-solution-toolkit/e2e-terraform/management_cluster.tfvars

Wenden Sie die Terraform-Konfiguration an:

Wechseln Sie zum Verzeichnis self-managed-vmware-solution-toolkit/e2e-terraform und initialisieren und wenden Sie die Terraform-Konfiguration an:

cd self-managed-vmware-solution-toolkit/e2e-terraform
terraform init
terraform plan -var-file='management_cluster.tfvars' -out=tfplan
terraform apply tfplan

Terraform-Ausgaben prüfen und exportieren

Nachdem Sie terraform apply ausgeführt haben, stellt Terraform strukturierte Ausgaben in vier Kategorien bereit:

  • gcp_resources_self_links: Vollständige selbstverweisende URLs für Ressourcen Google Cloud für VPC-Netzwerke, Subnetze, Instanzen, Platzierungsrichtlinien, NEGs, Backend-Dienste, Weiterleitungsregeln, Firewalls und Cloud DNS-Zonen.
  • neg_attachment_commands:
    • Wenn die Variable deployment_mode auf "cluster_creation" gesetzt ist: Gibt eine Statusmeldung zurück, die angibt, dass Terraform beim Erstellen des Clusters automatisch NEGs anhängt.
    • Wenn die Variable deployment_mode auf "node_addition" gesetzt ist: Stellt die gcloud compute network-endpoint-groups update-Befehle bereit, die erforderlich sind, um neu bereitgestellte ESXi-Hostinstanzen sowohl an Verwaltungs- als auch an NSX-NEGs anzuhängen.
    • Wenn die Variable deployment_mode auf "appliance_addition" gesetzt ist: Gibt eine Statusmeldung zurück, die angibt, dass NEGs an vorhandenen Clusterknoten angehängt bleiben und dass Terraform sie beim Hinzufügen der Appliance nicht ändert.
  • python_scripts_input_config: Strukturierte Parameterkonfigurations-Nutzlast für die nachgelagerten VCF-Installationsskripts zur Automatisierung der Bereitstellung im Toolkit-Verzeichnis python. Sie können diese Ausgabe in das JSON-Format konvertieren, das von den Python-Skripts des Toolkits erwartet wird. Führen Sie dazu das Hilfsskript aus, das im nächsten Abschnitt beschrieben wird.
  • management_domain_deployment_input_config: Strukturierte Eingabe für die Bereitstellung der Verwaltungsdomain, wobei die meisten Felder aus der End-to-End-Bereitstellung vorab ausgefüllt sind. Sie können diese Eingabe bei Bedarf oder nach Aufforderung bearbeiten und mit dem im nächsten Abschnitt beschriebenen Exportskript in eine JSON-Datei für die Bereitstellung der Verwaltungsdomain konvertieren.

Bereitstellungskonfigurationen exportieren

Das Toolkit enthält ein Hilfsskript (scripts/export_deployment_config.py), das Konfigurationsblöcke aus Terraform-Ausgaben extrahiert und in formatierte, schemakonforme JSON-Dateien für nachgelagerte Workflows exportiert:

  • management_domain_deployment_input_config: Eingabe-JSON für die Bereitstellung der VCF-Verwaltungsdomain.
  • python_scripts_input_config: Eingabe-JSON (config.json) für die Python-Automatisierungsskripts des Toolkits (vcf_deployer).

Hilfsskript ausführen

Führen Sie das Hilfsskript im Verzeichnis e2e-terraform aus oder geben Sie die Flags -d oder -i an. Wählen Sie dazu eine der folgenden Optionen aus:

  • Exportieren Sie beide Konfigurationen gleichzeitig:

    python3 ../scripts/export_deployment_config.py --config all --output-dir .

    Mit diesem Befehl werden die folgenden Dateien generiert:

    • management_domain_deployment_input.json
    • python_scripts_input_config.json

  • Exportieren Sie nur die JSON-Eingabe für die Bereitstellung der VCF-Verwaltungsdomain:

    python3 ../scripts/export_deployment_config.py --config mgmt -o management_domain_deployment_input.json

  • Exportieren Sie nur die JSON-Eingabe des Python-Toolkits:

    python3 ../scripts/export_deployment_config.py --config python -o config.json

  • Export aus gespeicherten Terraform-Ausgaben oder weitergeleiteter Standardeingabe (stdin):

    # From stdin pipe:
terraform output -json | python3 ../scripts/export_deployment_config.py --config all --output-dir .

# From a saved JSON file:
terraform output -json > outputs.json
python3 ../scripts/export_deployment_config.py -i outputs.json --config all --output-dir .

Nächste Schritte

  1. Führen Sie das Node Preparation Toolkit aus, um das ursprüngliche ESXi-root-Passwort auf jedem Host zurückzusetzen, die Knoten für die VCF-Bereitstellung vorzubereiten und die VCF-Installations-Appliance mit der python_scripts_input_config-Ausgabe aus der End-to-End-Terraform-Konfiguration bereitzustellen (mit dem Hilfsskript in JSON konvertiert). Eine Anleitung finden Sie unter Knoten vorbereiten und VCF mit dem Toolkit bereitstellen.
  2. Konfigurieren Sie die Verbindung zum regionalen Offline-Depot im VCF-Installationsprogramm, um die erforderlichen Softwarepakete herunterzuladen:
    • Protokoll: HTTPS
    • FQDN (keine IP-Adresse verwenden): offline-depot.REGION.selfmanagedvmwareengine.goog (Ersetzen Sie REGION durch die Google Cloud-Region, in der sich Ihre Bare-Metal-Knoten befinden.)
    • Port: 443
    • Nutzername: vcf-depot-user
    • Passwort: Google1!
  3. Stellen Sie die Verwaltungsdomain bereit, indem Sie die JSON-Datei management_domain_deployment_input_config (exportiert mit dem Hilfsskript) an das VCF-Installationsprogramm übergeben. Achten Sie darauf, dass Sie alle in der Eingabekonfiguration als user_should_input gekennzeichneten Felder durch Ihre Zielwerte ersetzen. Eine Anleitung zum Abschließen des VCF-Bring-up-Workflows finden Sie in der Broadcom-Dokumentation unter Neue VCF-Flotte oder neue VCF-Instanz bereitstellen.
  4. Clusterkapazität durch Hinzufügen von Knoten erweitern (siehe Knotenkapazität mit Terraform verwalten)
  5. Stellen Sie Load Balancer und DNS-Einträge für zusätzliche VCF-Appliances in VCF-Appliances mit Terraform hinzufügen bereit.