> 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/05-clusters-nodes.md). # Cluster & Knotentypen ## Was ist ein Cluster? Ein **Cluster** In VergeOS ist ein Cluster eine logische Gruppierung von Knoten mit denselben Hardwaremerkmalen, die einen Ressourcenpool bildet, der in der VergeOS-Benutzeroberfläche als nutzbare Ressourcen dargestellt wird. Cluster ermöglichen effiziente Verwaltung, Skalierung und hohe Verfügbarkeit für virtualisierte Workloads. Jedes VergeOS-System beginnt mit mindestens einem Cluster — die anfänglichen zwei Controller-Knoten bilden während der Installation den ersten Cluster. Von dort aus können Sie Knoten zum vorhandenen Cluster hinzufügen oder zusätzliche Cluster mit unterschiedlichen Rollen und Hardwareprofilen erstellen. ### Warum Cluster wichtig sind Cluster dienen mehreren Zwecken: * **Rechenisolierung** — CPU, Arbeitsspeicher und VM-Workloads sind an einen bestimmten Cluster gebunden. VMs laufen nur auf Knoten innerhalb ihres zugewiesenen Clusters (mit optionalem Failover zu einem anderen Cluster). * **Gemeinsamer Speicherpool** — vSAN-Tiers erstrecken sich über Cluster hinweg zu einem einzigen logischen Speicherpool. Ein Speicherdatenträger in Cluster 1 und ein Speicherdatenträger in Cluster 2 können beide zum selben Tier beitragen. Reine Rechenknoten greifen über das Core Fabric auf diesen gemeinsam genutzten Speicher zu. * **Hardware-Optimierung** — Verschiedene Cluster können unterschiedliche Hardwareprofile haben: Knoten mit viel Arbeitsspeicher für Datenbanken, mit GPU ausgestattete Knoten für Rendering, NVMe-dichte Knoten für speicherintensive Workloads * **Unabhängige Skalierung** — Rechenkapazität zu einem Cluster hinzufügen, ohne andere zu beeinflussen; der Speicher skaliert über das gesamte System hinweg ## Clustertypen VergeOS unterstützt drei unterschiedliche Clustertypen, die innerhalb eines einzelnen Systems kombiniert werden können: | Clustertyp | Bietet | vSAN-Beteiligung | Typischer Anwendungsfall | | ---------------------- | ------------------------- | -------------------------------------------------------- | ------------------------------------------------------------ | | **Kombiniert (HCI)** | Rechenleistung + Speicher | Ja — Knoten tragen Speicherdatenträger zu vSAN-Tiers bei | Allgemeine Workloads, kleine bis mittlere Bereitstellungen | | **Nur Speicher** | nur Speicher | Ja — Knoten tragen nur Speicher bei | Dedizierte Speichererweiterung in UCI-Architekturen | | **Nur Rechenleistung** | nur Rechenleistung | Nein — nur Boot-Laufwerk oder PXE-Boot | Workloads mit hoher Rechenlast (ML, Rendering, Datenanalyse) | **Häufige Bereitstellungsbeispiele:** ```mermaid graph TB subgraph hci["HCI (Einzelcluster)"] N1["Controller 1
Rechenleistung + Speicher"] N2["Controller 2
Rechenleistung + Speicher"] N3["Scale-out
Rechenleistung + Speicher"] end subgraph hybrid["Hybrid (2 Cluster)"] H1["Controller 1
Speicher + Verwaltung"] H2["Controller 2
Speicher + Verwaltung"] HC1["Rechenknoten 1"] HC2["Rechenknoten 2"] end subgraph uci["UCI (3 Cluster)"] U1["Controller 1
Verwaltung"] U2["Controller 2
Verwaltung"] US1["Speicherknoten 1"] US2["Speicherknoten 2"] UC1["Rechenknoten 1"] UC2["Rechenknoten 2"] end style N1 fill:#e3f2fd,stroke:#1565c0 style N2 fill:#e3f2fd,stroke:#1565c0 style N3 fill:#e3f2fd,stroke:#1565c0 style H1 fill:#e3f2fd,stroke:#1565c0 style H2 fill:#e3f2fd,stroke:#1565c0 style HC1 fill:#fff3e0,stroke:#e65100 style HC2 fill:#fff3e0,stroke:#e65100 style U1 fill:#e3f2fd,stroke:#1565c0 style U2 fill:#e3f2fd,stroke:#1565c0 style US1 fill:#e8f5e9,stroke:#2e7d32 style US2 fill:#e8f5e9,stroke:#2e7d32 style UC1 fill:#fff3e0,stroke:#e65100 style UC2 fill:#fff3e0,stroke:#e65100 ``` ## Knotentypen Jeder physische Server in einem VergeOS-System ist ein **Knoten**. Knoten unterscheiden sich darin, wie sie dem System beitreten, welche Rolle sie spielen und zu welchem Cluster sie gehören. VergeOS definiert vier Knotentypen: ### Controller-Knoten Jedes VergeOS-System beginnt mit mindestens zwei **Controller-Knoten**. Für N+2-Redundanz ist ein dritter Controller-Knoten erforderlich. Sie sind besonders, weil: * **Knoten 1** ein brandneues VergeOS-System erstellt. Er initialisiert vSAN, erstellt den ersten Cluster und führt die Nachinstallationskonfiguration aus (Netzwerkeinrichtung, Cluster-Erstellung für zusätzliche Knotentypen usw.) * **Knoten 2** tritt dem von Knoten 1 erstellten System als zweiter Controller bei und sorgt für Redundanz aller Verwaltungsfunktionen des Systems (N+1) * **Knoten 3 (optional)** — ein dritter Controller-Knoten kann für N+2-Redundanz hinzugefügt werden, sodass das System zwei gleichzeitige Knotenausfälle verkraften kann Controller-Knoten gehören immer zu **Cluster 1**. In einer HCI-Topologie stellen sie sowohl Rechenleistung als auch Speicher bereit. In einer hybriden Topologie stellen sie häufig **nur Speicher und Verwaltung bereit** — keine Produktions-VMs — während ein separater Rechencluster alle Workloads übernimmt. In einer vollständigen UCI-Topologie verwalten sie das System, delegieren Speicher und Rechenleistung jedoch an dedizierte Cluster. Der erste Cluster muss mindestens zwei Knoten mit **Tier-0-Speicher** (Metadatenlaufwerke) umfassen — dies ist eine zwingende Voraussetzung, da Tier 0 den vSAN-Dateisystemindex enthält und redundant sein muss. ### Scale-out-Knoten Scale-out-Knoten erweitern einen vorhandenen HCI-Cluster durch zusätzliche Rechen- und Speicherkapazität. Wichtige Merkmale: * **Identische Hardware** zu den Controller-Knoten in dem Cluster, dem sie beitreten (gleiche CPU-Generation, ähnliches Speicherlayout, passende NIC-Konfiguration) * Per USB installieren und den Scale-out-Knotentyp auswählen. Das Installationsprogramm erkennt das Core Fabric automatisch, dann authentifiziert sich der Bediener mit Admin-Anmeldedaten. Wenn mehrere Cluster vorhanden sind, wählt der Bediener außerdem den Zielcluster und einen Referenzknoten aus, mit dem die Hardware verglichen wird * Datenträger treten den vorhandenen vSAN-Tiers automatisch bei * Tragen sowohl Rechenleistung (VMs ausführen) als auch Speicher (vSAN-Beteiligung) bei Scale-out-Knoten sind der einfachste Weg, eine HCI-Bereitstellung zu erweitern — einen Knoten hinzufügen, und die Rechen- und Speicherkapazität des Clusters steigt proportional. ### Nur-Speicher-Knoten Nur-Speicher-Knoten sind ausschließlich der Erweiterung der vSAN-Kapazität gewidmet. Sie: * Tragen Datenträger zu vSAN-Tiers bei, führen aber **nicht** VM-Workloads aus * Gehören zu einem **Nur-Speicher-Cluster** (z. B. Cluster 2) * Erfordern das Erstellen des Speicherclusters in der VergeOS-Benutzeroberfläche, bevor der erste Speicherknoten hinzugefügt wird * Werden in UCI-Architekturen verwendet, in denen Speicher und Rechenleistung unabhängig skalieren ### Nur-Rechen-Knoten Nur-Rechen-Knoten stellen Verarbeitungsleistung bereit, ohne an vSAN-Speicher teilzunehmen. Sie: * Führen VM-Workloads aus, haben aber **keinen lokalen vSAN-Speicher** (nur Boot-Laufwerk oder PXE-Boot) * Gehören zu einem **Nur-Rechen-Cluster** (z. B. Cluster 3) * Erfordern das Erstellen des Rechenclusters in der VergeOS-Benutzeroberfläche, bevor der erste Rechenknoten hinzugefügt wird * Greifen über das Core Fabric auf Speicher von Knoten in HCI- oder Nur-Speicher-Clustern zu Nur-Rechen-Knoten sind ideal für Workloads, die eine hohe CPU/RAM/GPU-Dichte ohne proportionalen Speicherzuwachs benötigen — Machine Learning, Rendering, Datenanalyse oder VDI. ### Knotentyp-Zusammenfassung | Knotentyp | Rolle | Cluster | vSAN | Führt VMs aus | Beitrittsmethode | | ------------------------- | ------------------------------------ | ---------- | ------------------------------ | ------------------------ | ------------------------------------------ | | **Controller (Knoten 1)** | Erstellt neues System | Cluster 1 | Ja (Tier 0 + Workload-Tiers) | Ja (HCI) oder Nein (UCI) | Erstellung eines neuen Systems | | **Controller (Knoten 2)** | Tritt als redundanter Controller bei | Cluster 1 | Ja (Tier 0 + Workload-Tiers) | Ja (HCI) oder Nein (UCI) | Tritt Cluster 1 bei | | **Scale-out** | Fügt HCI-Kapazität hinzu | Cluster 1 | Ja (Workload-Tiers) | Ja | Auto-Erkennung im Core Fabric | | **Nur-Speicher** | Dedizierte Speichererweiterung | Cluster 2+ | Ja (Workload-Tiers) | Nein | Tritt dem vorgesehenen Speichercluster bei | | **Nur-Rechenleistung** | Dedizierte Rechenerweiterung | Cluster 2+ | Nein (nur Boot-Laufwerk / PXE) | Ja | Tritt dem vorgesehenen Rechencluster bei | {% hint style="info" %} **Kommen Sie von VMware oder Nutanix?** Keine der beiden Plattformen hat ein natives Konzept von Nur-Speicher- oder Nur-Rechen-Mitgliedern innerhalb eines einzelnen Clusters. VergeOS schon, und es ermöglicht Ihnen, Cluster für unabhängige Skalierung zu typisieren. VMware- und Nutanix-Cluster sind einheitlich; VergeOS-Cluster können HCI, Nur-Speicher oder Nur-Rechen sein, und ein System kann mehrere typisierte Cluster kombinieren. {% endhint %} | VergeOS-Knotenrolle | Nächstliegendes VMware-vSphere-Analogon | Nächstliegendes Nutanix-Analogon | | ------------------- | ------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Controller | ESXi-Host + vCenter-Dienste (kein separates Appliance) | Erster Knoten in einem Cluster; VergeOS-Controller laufen auf Bare Metal, nicht in einer CVM | | Scale-out | Zusätzlicher ESXi-Host, der einem vSAN-Cluster beitritt | Zusätzlicher Knoten, der einem Nutanix-Cluster beitritt | | Nur-Speicher | Kein natives Äquivalent (vSAN-Witness kommt am nächsten) | Kein Äquivalent — jeder Nutanix-Knoten führt eine CVM aus und beteiligt sich am Rechnen | | Nur-Rechenleistung | ESXi-Host ohne lokalen vSAN-Speicher, der externen Speicher einbindet (hier: vSAN über das Core Fabric) | Kein direktes Äquivalent | ## Wie Knoten einem System beitreten Der Beitrittsprozess von Knoten folgt einer strikten Reihenfolge, um Race Conditions zu vermeiden: ```mermaid flowchart TD A["Knoten 1 (Controller)
Erstellt neues VergeOS-System
Initialisiert vSAN, erstellt Cluster 1"] --> B["Knoten 2 (Controller)
Tritt Cluster 1 bei
Stellt HA-Paar her"] B --> C{"Zusätzliche Knoten?"} C -->|"Scale-out"| D["Scale-out-Knoten
Erkennen das System automatisch im Core Fabric
Treten Cluster 1 nacheinander bei"] C -->|"Nur-Speicher"| E["Speichercluster erstellen
(Cluster 2 in der UI)"] C -->|"Nur-Rechenleistung"| F["Rechencluster erstellen
(Cluster 2 oder 3 in der UI)"] E --> G["Speicherknoten
Treten dem Speichercluster nacheinander bei"] F --> H["Rechenknoten
Treten dem Rechencluster nacheinander bei"] G --> F style A fill:#e3f2fd,stroke:#1565c0 style B fill:#e3f2fd,stroke:#1565c0 style D fill:#e3f2fd,stroke:#1565c0 style G fill:#e8f5e9,stroke:#2e7d32 style H fill:#fff3e0,stroke:#e65100 ``` Wichtige Regeln für das Beitreten von Knoten: 1. **Knoten 1 muss die Installation abschließen** bevor Knoten 2 beitreten kann — Knoten 2 benötigt ein vorhandenes System, mit dem er sich verbinden kann 2. **Knoten treten nacheinander bei** innerhalb eines Clusters — Knoten 3 nach Knoten 2, Knoten 4 nach Knoten 3 usw. — um Race Conditions während Änderungen der Cluster-Mitgliedschaft zu vermeiden 3. **Speichercluster müssen existieren** bevor Speicherknoten beitreten können — erstellen Sie den Cluster zuerst in der VergeOS-Benutzeroberfläche 4. **Rechencluster müssen existieren** bevor Rechenknoten beitreten können — dieselbe Voraussetzung 5. **Wenn sowohl Speicher- als auch Rechencluster bereitgestellt werden**, sollten Speicherknoten zuerst hinzugefügt werden, damit Rechenknoten sofort auf vSAN-Speicher zugreifen können ## Cluster-Nummerierung und Benennung Cluster werden beginnend bei 1 nummeriert, aber der **Name ist frei wählbar** — Sie können einen Cluster nennen, wie Sie möchten, und ihn jederzeit in der VergeOS-Benutzeroberfläche umbenennen. Die untenstehenden Namen sind nur gebräuchliche Konventionen, keine erforderlichen Werte: | Clusternummer | Standardrolle | Typischer Name | | ------------- | ----------------------------------------------------------- | ---------------------------------- | | Cluster 1 | HCI (Controller + optional Scale-out) | "HCI", "Default" oder "Controller" | | Cluster 2 | Nur-Speicher (bei UCI) oder Nur-Rechenleistung (bei Hybrid) | "Speicher" oder "Rechenleistung" | | Cluster 3 | Nur-Rechenleistung (in vollständigem UCI mit 3 Clustern) | "Rechenleistung" | In einer vollständigen UCI-Bereitstellung mit 3 Clustern: * **Cluster 1**: Controller (Systemverwaltung, Tier-0-Metadaten) * **Cluster 2**: Speicherknoten (gesamter vSAN-Workload-Speicher) * **Cluster 3**: Rechenknoten (gesamte VM-Ausführung) ## Mindestanforderungen und Hochverfügbarkeit | Anforderung | Details | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Mindestanzahl an Knoten pro System** | 2 (ein Controller-Paar) | | **Mindestanzahl an Knoten pro Cluster** | 2 (für Redundanz bei Wartung oder Ausfall) | | **Controller-Knoten** | Mindestens 2 pro System (standardmäßig N+1); 3 erforderlich für N+2-Redundanz — müssen Tier-0-Speicher für vSAN-Metadaten haben | | **HA-Verhalten** | Fällt ein Knoten aus, werden seine Workloads auf den oder die verbleibenden Knoten im selben Cluster migriert | | **Wartungsmodus** | Knoten können in den Wartungsmodus versetzt werden; Workloads werden vor Beginn der Wartung live auf andere Knoten im Cluster migriert | ## Skalierung VergeOS-Systeme skalieren von einem minimalen 2-Knoten-HCI-Cluster bis hin zu Multi-Cluster-Bereitstellungen. Alle Knoten müssen dasselbe **gleiche Switching-Fabric** mit **null Switch-Hops** zwischen ihnen teilen (Ziel-Latenz unter 0,05 ms). Ein einzelnes Rack ist der einfachste Weg, diese Anforderung zu erfüllen. Multi-Rack-Bereitstellungen sind möglich, aber jedes Core Fabric muss dennoch an einem einzelnen Switch enden — führen Sie längere Kabel zurück zum selben Paar Fabric-Switches, anstatt das Fabric über mehrere Switches zu spannen (MLAG/Stacking ist für das externe Netzwerk gedacht, nicht für das Core Fabric). Die Skalierungsstrategie hängt von Ihrer Architektur ab: ### HCI-Skalierung (einfach) Fügen Sie Cluster 1 Scale-out-Knoten hinzu. Jeder Knoten fügt proportional sowohl Rechenleistung als auch Speicher hinzu. ```mermaid graph LR subgraph "Start: 2-Knoten-HCI" A1["Knoten 1"] --- A2["Knoten 2"] end subgraph "Wachstum: 4-Knoten-HCI" B1["Knoten 1"] --- B2["Knoten 2"] B3["Knoten 3"] --- B4["Knoten 4"] B1 --- B3 B2 --- B4 end subgraph "Skalierung: 8+-Knoten-HCI" C1["Knoten 1-2
(Controller)"] C2["Knoten 3-8
(Scale-out)"] end ``` **Am besten geeignet für**: Ausgewogenes Wachstum, bei dem Rechen- und Speicherbedarf gemeinsam steigen. ### UCI-Skalierung (unabhängig) Fügen Sie je nach Engpass der jeweiligen Ressource Knoten zu bestimmten Clustern hinzu: * **Mehr Speicher nötig?** Knoten zum Speichercluster hinzufügen * **Mehr Rechenleistung nötig?** Knoten zum Rechencluster hinzufügen * **Mehr von beidem nötig?** Zu beiden Clustern unabhängig hinzufügen **Am besten geeignet für**: Workloads mit unausgewogenem Ressourcenbedarf (z. B. speicherintensiv bei geringem Rechenbedarf oder rechenintensiv mit GPUs bei moderatem Speicherbedarf). ### Best Practices für die Skalierung * **Hardwarekonsistenz innerhalb von Clustern** — Verwenden Sie für alle Knoten in einem Cluster dieselben Hardwarespezifikationen. Das Mischen unterschiedlicher Hardware innerhalb eines Clusters kann zu Leistungs- und Zuverlässigkeitsproblemen führen. * **Planen Sie N+1-Redundanz ein** — Dimensionieren Sie jeden Cluster so, dass nach dem Verlust eines Knotens immer noch genügend Kapazität für alle Workloads vorhanden ist * **Vor dem Skalieren überwachen** — Verwenden Sie die Metriken des VergeOS-Dashboards (CPU-Auslastung, RAM-Verbrauch, vSAN-Kapazität), um zu ermitteln, welche Ressource erweitert werden muss * **Ohne Ausfallzeit skalieren** — Neue Knoten können zu einem laufenden System hinzugefügt werden, ohne bestehende Workloads zu unterbrechen ## Beispiele für Bereitstellungs-Topologien Gängige Topologien, die realen Bereitstellungsmustern entsprechen: | Topologie | Knoten | Cluster | Wann verwenden | | ------------------------- | ---------------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------------------- | | **2-Knoten-HCI** | 2 Controller | 1 (HCI) | Kleine Standorte, Edge, PoC, grundlegende Evaluierung | | **HCI + Scale-out** | 2 Controller + N Scale-out | 1 (HCI) | Wachsende HCI-Bereitstellungen mit Bedarf an ausgewogener Skalierung | | **Hybrid (2 Cluster)** | 2 Controller + N Rechenknoten | 2 (Speicher + Rechenleistung) | Rechenintensive Workloads mit moderatem Speicherbedarf | | **UCI (3 Cluster)** | 2 Controller + N Speicher + M Rechenleistung | 3 (Controller + Speicher + Rechenleistung) | Unabhängige Skalierung von Rechenleistung/Speicher | | **UCI + GPU (4 Cluster)** | 2 Controller + N Speicher + M Rechenleistung + G GPU | 4 (Controller + Speicher + Rechenleistung + GPU) | KI/ML, Rendering oder VDI mit dedizierten GPU-Knoten | ```mermaid graph TB subgraph "2-Knoten-HCI" direction LR H1["Controller 1
HCI"] --- H2["Controller 2
HCI"] end subgraph "HCI + Scale-out" direction LR S1["Controller 1"] --- S2["Controller 2"] S3["Scale-out 1"] --- S4["Scale-out 2"] end subgraph "Hybrid (2 Cluster)" direction LR subgraph "Cluster 1 (Speicher)" Y1["Controller 1"] Y2["Controller 2"] end subgraph "Cluster 2 (Rechenleistung)" Y3["Rechenknoten 1"] Y4["Rechenknoten 2"] end end subgraph "UCI + GPU (4 Cluster)" direction LR subgraph "Cluster 1 (Ctrl)" U1["Ctrl 1"] U2["Ctrl 2"] end subgraph "Cluster 2 (Speicher)" U3["Speicher 1"] U4["Speicher 2"] end subgraph "Cluster 3 (Rechnen)" U5["Rechnen 1"] U6["Rechnen 2"] end subgraph "Cluster 4 (GPU)" G1["GPU-Knoten 1"] G2["GPU-Knoten 2"] end end ``` ## Wichtige Erkenntnisse | Konzept | Zusammenfassung | | --------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Cluster** | Logische Gruppierung von Knoten mit derselben Hardware, die einen Ressourcenpool bildet | | **Drei Clustertypen** | HCI (Rechnen + Speicher), nur Speicher, nur Rechnen — innerhalb eines Systems kombinierbar | | **Vier Knotentypen** | Controller, Scale-out, nur Speicher, nur Rechnen — jeweils mit einer spezifischen Rolle und Beitrittsmethode | | **Mindestens 2 Knoten** | Pro Cluster für Redundanz; Controller erfordern Tier-0-Speicher | | **Sequenzielles Beitreten** | Knoten treten nacheinander bei, um Race Conditions zu verhindern | | **Hardware-Konsistenz** | Alle Knoten in einem Cluster sollten übereinstimmende Hardwarespezifikationen haben | | **Unabhängige Skalierung** | Die UCI-Architektur ermöglicht es, Rechen- oder Speicherkapazität unabhängig hinzuzufügen | | **Skalierung** | Systeme skalieren von 2-Knoten-HCI bis zu Multi-Cluster-Bereitstellungen innerhalb einer einzigen Switching-Ebene | ## Nächste Schritte Sie verstehen jetzt, wie VergeOS Knoten in Cluster organisiert und wie verschiedene Knotentypen unterschiedliche Rollen erfüllen. Im praktischen Labor werden Sie diese Konzepte mit dem Terraform-Spielplatz erkunden: [**Labor: Architekturerkundung →**](/learn-the-platform/de/modul-1-architekturgrundlagen/lab.md) --- # 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/05-clusters-nodes.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.