Cluster & Knotentypen
Erfahren Sie, wie VergeOS physische Server in Cluster organisiert, verstehen Sie die verschiedenen Knotentypen (Controller, Scale-out, nur Speicher, nur Compute) und wie Systeme skalieren.
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:
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:
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
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
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:
Wichtige Regeln für das Beitreten von Knoten:
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
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
Speichercluster müssen existieren bevor Speicherknoten beitreten können — erstellen Sie den Cluster zuerst in der VergeOS-Benutzeroberfläche
Rechencluster müssen existieren bevor Rechenknoten beitreten können — dieselbe Voraussetzung
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:
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
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.
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:
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
Wichtige Erkenntnisse
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 →
Zuletzt aktualisiert
War das hilfreich?