> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/de/modul-1-architekturgrundlagen/lab.md). # Labor: Die Architektur erkunden ## 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** ```bash 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) ```hcl # 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: ```mermaid graph TB subgraph "Cluster 1 (HCI)" N1["Knoten 1 — Controller
Speicher + Compute"] N2["Knoten 2 — Controller
Speicher + Compute"] N3["Knoten 3 — Scale-out
Speicher + Compute"] N4["Knoten 4 — Scale-out
Speicher + Compute"] end CF["Core Fabric (zwei Switches)"] EXT["Externes Netzwerk"] N1 --- CF N2 --- CF N3 --- CF N4 --- CF N1 --- EXT N2 --- EXT N3 --- EXT N4 --- EXT ``` 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. {% tabs %} {% tab title="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 {% endtab %} {% tab title="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 {% endtab %} {% tab title="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 {% endtab %} {% tab title="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 {% endtab %} {% endtabs %} ### 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**](/learn-the-platform/de/modul-2-dimensionierung-and-design/02-sizing-design.md) um zu lernen, wie Kundenanforderungen in konkrete Hardwarekonfigurationen und Bereitstellungspläne übersetzt werden. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/learn-the-platform/de/modul-1-architekturgrundlagen/lab.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.