Labor: Architektur erkunden

Praktische Erkundung von VergeOS-Bereitstellungstopologien mit dem Terraform-Playground. Verfolgen Sie Infrastructure-as-Code-Muster, vergleichen Sie Szenarien und entwerfen Sie eine Topologie für einen Kundenanwendungsfall.

Lab-Übersicht

In diesem Lab erkunden Sie das VergeOS Terraform Playground — ein Open-Source-Projekt, das virtuelle VergeOS-Systeme mit Terraform bereitstellt. Durch das Lesen des Codes und der Dokumentation vertiefen Sie die in diesem Modul behandelten Architekturkonzepte: Core-Fabric-Netzwerk, vSAN-Speicherstufen, Cluster-Organisation und HCI- vs. UCI-Topologien.

Was Sie tun werden

• Teil 1 — Lesen Sie die Architekturdokumentation und den Terraform-Code des Playgrounds, um zu erkennen, wie VergeOS-Konzepte auf Infrastructure as Code abgebildet werden
• Teil 2 — Empfehlen und skizzieren Sie anhand eines Kundenszenarios eine Bereitstellungstopologie
• Teil 3 — Vergleichen Sie die vier Beispiel-Bereitstellungskonfigurationen und analysieren Sie ihre Unterschiede

Voraussetzungen

• Ein GitHub-Konto (zum Klonen des Repositories)
• Git auf Ihrer Workstation installiert
• Ein Texteditor oder eine IDE (VS Code empfohlen)
• Es ist kein Zugriff auf ein VergeOS-System erforderlich — dieses Lab ist eine Lese- und Designübung

Geschätzte Zeit

30 Minuten

---

Teil 1: Die Architektur erkunden

In diesem Abschnitt klonen Sie das Terraform-Playground-Repository und verfolgen, wie VergeOS-Architekturkonzepte in Infrastructure as Code dargestellt werden.

1. Das Repository klonen

   git clone https://github.com/verge-io/vergeos-terraform-playground.git
   cd vergeos-terraform-playground

2. Die Architekturdokumentation lesen

   Öffnen Sie docs/architecture.md und das gesamte Dokument lesen. Achten Sie beim Lesen auf die Antworten auf diese Fragen:

   • Was sind die vier Bereitstellungsszenarien die vom Playground unterstützt werden?
   • Was ist eine Installations-Seed-Datei und wie ermöglicht sie eine unbeaufsichtigte Installation?
   • Was ist die Mindest-Bereitstellung größe?

   Hinweis: Die vier Szenarien sind in docs/deployment-scenarios.md mit Topologie-Diagrammen aufgeführt. Die Mindestbereitstellung besteht aus zwei Controller-Knoten, die einen einzelnen HCI-Cluster bilden.

3. Die Diagramme der Bereitstellungsszenarien untersuchen

   Öffnen Sie docs/deployment-scenarios.md und die Mermaid-Topologie-Diagramme für jedes Szenario studieren. Notieren Sie für jedes:

   • Wie viele Knoten sind beteiligt
   • Wie viele werden Cluster erstellt Welche
   • Knotentypen erscheinen (Controller, Scale-out, Storage, Compute) erscheinen (Controller, Scale-out, Storage, Compute)
   • Wie alle Knoten mit dem Core Fabric und externen Netzwerk
4. Das Core Fabric in Terraform nachverfolgen

   Öffnen Sie main.tf (das Root-Modul) und die beiden Core-Fabric-Netzwerkressourcen finden. Beantworten Sie diese Fragen:

   • Wie heißen die Ressourcen? (core_fabric_1 und core_fabric_2)
   • Was MTU ist konfiguriert? (9142 — Jumbo-Frames für die vSAN-Replikation)
   • Ist DHCP in diesen Netzwerken aktiviert? (Nein — dhcp_enabled = false)
   • Was ipaddress_type ist gesetzt? (none — das sind Layer-2-Transporte)

   # Sie sollten in main.tf Ressourcen wie diese finden:
   resource "vergeio_network" "core_fabric_1" {
     name           = "${var.system_name}-core-fabric-1"
     enabled        = true
     dhcp_enabled   = false
     on_power_loss  = "power_on"
     mtu            = 9142
     ipaddress_type = "none"
   }

5. Untersuchen, wie sich Knoten 1 von Knoten 2 unterscheidet

   Öffnen Sie modules/controllers/main.tf und vergleichen Sie verge_node_1 und verge_node_2. Wichtige Unterschiede, die Sie erkennen sollten:

   • Cloud-Init-Vorlage — Knoten 1 verwendet user-data-node1.yaml (erstellt ein neues System mit YC_VSAN_NEW=1). Knoten 2 verwendet user-data-node2.yaml (tritt dem bestehenden System mit YC_VSAN_NEW=0).
   • API-Einrichtung nach der Installation — Das Cloud-Init von Knoten 1 enthält ein Skript, das Update-Quellen konfiguriert, SSH aktiviert und optional Speicher-/Compute-Cluster über die VergeOS-API erstellt. Knoten 2 hat kein Skript für die Zeit nach der Installation.
   • Abhängigkeitskette — Knoten 2 hat eine depends_on -Referenz auf Knoten 1, wodurch sichergestellt wird, dass das System vollständig initialisiert ist, bevor der zweite Controller versucht, beizutreten.

   Beide Knoten teilen sich dieselbe VM-Struktur: Linux-OS-Familie, aktivierte verschachtelte Virtualisierung, drei virtio-NICs (extern, Core Fabric 1, Core Fabric 2), CD-ROM mit dem VergeOS-ISO und eine Cloud-Init-NoCloud-Datenquelle.
6. Verständnisfragen beantworten

   Notieren Sie Ihre Antworten auf die folgenden Fragen (oder besprechen Sie sie mit Ihrem Schulungspartner):

   #	Frage	Erwartete Antwort
   1	Warum verwendet das Core Fabric zwei separate Switches?	Redundanz — wenn ein Switch oder Pfad ausfällt, hält der andere die Konnektivität zwischen den Knoten aufrecht
   2	Warum ist DHCP im Core-Fabric-Netzwerk deaktiviert?	Das Core Fabric verwendet statische IP-Adressierung; der VergeOS-Installer konfiguriert die Adressen über die Installations-Seed-Datei
   3	Warum muss Knoten 2 warten, bis Knoten 1 abgeschlossen ist, bevor er startet?	Knoten 1 erstellt das VergeOS-System; Knoten 2 benötigt ein bestehendes System, dem er beitreten kann
   4	Welche Verkehrstypen laufen über das Core Fabric?	vSAN-Replikation, Cluster-Koordination, VM-Live-Migration, Kommunikation der Steuerungsebene
   5	Warum ist quantity_tier_1_disks für Controller auf 0 gesetzt, wenn Speicherknoten aktiviert sind?	Im UCI-Modus stellen dedizierte Speicherknoten die gesamte Tier-1-Kapazität bereit; Controller benötigen nur Tier-0 für Metadaten

---

Teil 2: Design-Übung

Wenden Sie nun an, was Sie gelernt haben. Gegeben ein Kundenszenario, empfehlen Sie eine Bereitstellungstopologie und begründen Sie Ihre Entscheidung.

Kundenszenario

Midwest Manufacturing Co. migriert von einer VMware-vSphere-Umgebung mit 3 ESXi-Hosts. Derzeit betreiben sie 50 VMs (Mix aus Windows und Linux), verfügen über etwa 10 TB nutzbaren Speicher und erwarten in den nächsten 2 Jahren moderates Wachstum. Sie haben ein kleines IT-Team (2 Personen) und möchten die betriebliche Komplexität minimieren. Das Budget ist begrenzt.

1. HCI oder UCI wählen

   Welches Bereitstellungsmodell empfehlen Sie auf Grundlage des Kundenprofils? Berücksichtigen Sie:

   • Teamgröße — Ein IT-Team mit 2 Personen bevorzugt Einfachheit
   • Wachstumsmuster — „Moderates Wachstum“ deutet auf eine ausgewogene Skalierung von Compute und Storage hin
   • Budget — HCI erfordert weniger Gesamtknoten als UCI für dieselbe Kapazität
   • Aktuelle Umgebung — 3 ESXi-Hosts lassen sich gut auf einen kleinen HCI-Cluster abbilden

   Empfohlene Antwort: HCI ist die bessere Wahl. Das kleine Team profitiert von der einfacheren Architektur (ein einziger Clustertyp), die ausgewogene Skalierung passt zu ihrem moderaten Wachstum, weniger Knoten senken die Kosten, und HCI ähnelt stark ihrem bestehenden VMware-Cluster-Modell.

2. Knotenzahl und Layout bestimmen

   Skizzieren oder beschreiben Sie Ihre vorgeschlagene Topologie:

   • Wie viele Controller-Knoten?(Mindestens 2 für HA)
   • Brauchen Sie Scale-out-Knoten?(Bedenken Sie: 50 VMs auf 2 Knoten könnten knapp werden; 2 Scale-out-Knoten schaffen Spielraum)
   • Wie viele werden Cluster erstellt?(1 für HCI)
   • Wie steht es um die Speicherkapazität?(10 TB nutzbar bedeuten etwa 20 TB Rohkapazität mit Replikation über die Knoten)

   Ein vernünftiges Design:
3. Auf ein Playground-Beispiel abbilden

   Welche Terraform-Playground-Beispieldatei entspricht Ihrem Design am ehesten?

   Antwort: examples/4-node-hci.tfvars — 2 Controller + 2 Scale-out-Knoten in einem einzigen HCI-Cluster. Dies entspricht dem empfohlenen 4-Knoten-HCI-Design für ausgewogene Compute- und Storage-Skalierung.

---

Teil 3: Topologievergleich

Vergleichen Sie alle vier Beispiel- .tfvars dateien aus dem examples/ Verzeichnis. Füllen Sie die Vergleichstabelle unten aus.

Anweisungen

Öffnen Sie jede Datei und ermitteln Sie die Konfigurationswerte. Verwenden Sie die Tabelle, um Ihre Ergebnisse festzuhalten.

2-node-hci.tfvars

Datei: examples/2-node-hci.tfvars

• Szenario: 2-Knoten-HCI (einzelner Cluster)
• Gesamtknoten: 2
• Cluster: 1
• Knotentypen: 2 Controller (Speicher + Compute)
• Umschaltvariablen: Keine (alle Standardwerte)
• Tier-1-Datenträger auf den Controllern: Ja (je 2 × 1000 GB)
• Am besten geeignet für: Grundlegende Tests, Evaluierung, kleinstmögliche Bereitstellung

4-node-hci.tfvars

Datei: examples/4-node-hci.tfvars

• Szenario: HCI + Scale-out (einzelner Cluster)
• Gesamtknoten: 4
• Cluster: 1
• Knotentypen: 2 Controller + 2 Scale-out-Knoten
• Umschaltvariablen: create_scale_out_nodes = true
• Tier-1-Datenträger auf den Controllern: Ja (je 2 × 1000 GB)
• Am besten geeignet für: Größere HCI-Cluster, Testen des Scale-out-Verhaltens, ausgewogenes Wachstum

4-node-hybrid.tfvars

Datei: examples/4-node-hybrid-hci-2-cluster.tfvars

• Szenario: Hybrid-HCI (2 Cluster)
• Gesamtknoten: 4
• Cluster: 2
• Knotentypen: 2 Controller (Speicher + Compute) + 2 nur Compute
• Umschaltvariablen: create_compute_nodes = true
• Tier-1-Datenträger auf den Controllern: Ja (Controller stellen den gesamten Speicher bereit)
• Am besten geeignet für: Compute-Skalierung vom Speicher trennen, zusätzliche Compute-Spitzenkapazität hinzufügen

6-node-uci.tfvars

Datei: examples/6-node-uci-3-cluster.tfvars

• Szenario: UCI (3 Cluster)
• Gesamtknoten: 6
• Cluster: 3
• Knotentypen: 2 Controller + 2 nur Speicher + 2 nur Compute
• Umschaltvariablen: create_storage_nodes = true, create_compute_nodes = true
• Tier-1-Datenträger auf den Controllern: Nein (Speicherknoten stellen die gesamte Tier-1-Kapazität bereit)
• Am besten geeignet für: Produktionsähnliches UCI, unabhängige Skalierung von Speicher und Compute, größere Umgebungen

Zusammenfassungstabelle zum Vergleich

Füllen Sie diese Tabelle aus, während Sie jede Datei durchgehen:

Attribut	2-Knoten-HCI	4-Knoten-HCI	Hybrid 2-Cluster	UCI 3-Cluster
Gesamtknoten	2	4	4	6
Cluster	1	1	2	3
Controller-Knoten	2	2	2	2
Scale-out-Knoten	0	2	0	0
Nur-Speicher-Knoten	0	0	0	2
Nur-Compute-Knoten	0	0	2	2
Haben Controller Tier-1-Datenträger?	Ja	Ja	Ja	Nein
Speicher-Skalierung	HCI-Knoten hinzufügen	HCI-Knoten hinzufügen	Controller hinzufügen	Speicherknoten hinzufügen
Compute-Skalierung	HCI-Knoten hinzufügen	HCI-Knoten hinzufügen	Compute-Knoten hinzufügen	Compute-Knoten hinzufügen
Komplexität	Niedrig	Niedrig	Mittel	Hoch
Idealer Anwendungsfall	Klein / Evaluation	Mittelgroß / ausgewogen	Compute-Lastspitze	Groß / unabhängige Skalierung

Analysefragen

Nachdem Sie die Tabelle ausgefüllt haben, bedenken Sie diese Fragen:

1. Warum haben Controller im UCI-Szenario keine Tier-1-Datenträger?

   Im UCI-Modus stellen dedizierte Speicherknoten den gesamten Workload-Speicher bereit. Controller benötigen nur Tier-0-Datenträger für vSAN-Metadaten. Dies ist sichtbar in main.tf wo quantity_tier_1_disks bedingungsgesteuert auf 0 gesetzt wird, wenn create_storage_nodes = true.

2. Wie sieht die Abhängigkeitskette aus, wenn sowohl Speicher- als auch Compute-Knoten aktiviert sind?

   Controller → Speicherknoten → Compute-Knoten. Das Compute-Modul hat eine explizite depends_on Verknüpfung mit dem Speichermodul, wodurch sichergestellt wird, dass der Speicher-Cluster existiert, bevor Compute-Knoten versuchen, beizutreten. Dies spiegelt wider, wie die Cluster-Erstellung in VergeOS funktioniert: Speicher muss verfügbar sein, bevor Compute-Workloads ausgeführt werden können.

3. Wie würden Sie das 4-Knoten-HCI-Beispiel ändern, um 6 HCI-Knoten zu unterstützen?

   Ändern Sie quantity_scale_out_nodes von 2 in 4. Das Terraform-Modul erstellt zusätzliche Scale-out-Knoten nacheinander, wobei jeder demselben HCI-Cluster beitritt. Zusätzliche Umschaltvariablen sind nicht erforderlich.

---

Wichtige Erkenntnisse

Nach Abschluss dieses Labs sollten Sie in der Lage sein:

• ✅ sich im VergeOS Terraform Playground zurechtzufinden und seine Struktur zu verstehen
• ✅ zu erkennen, wie Core-Fabric-Netzwerke, vSAN-Speicherstufen und Knotentypen in Terraform ausgedrückt werden
• ✅ die Unterschiede zwischen den vier Bereitstellungsszenarien zu erklären (2-Knoten-HCI, 4-Knoten-HCI, Hybrid mit 2 Clustern, UCI mit 3 Clustern)
• ✅ eine geeignete VergeOS-Topologie für ein gegebenes Kundenszenario zu empfehlen
• ✅ die Abhängigkeitskette von Controllern über optionale Knotentypen hinweg nachzuverfolgen

Nächste Schritte

Fahren Sie fort mit Modul 2: Dimensionierung & Design um zu lernen, wie Kundenanforderungen in konkrete Hardwarekonfigurationen und Bereitstellungspläne übersetzt werden.