For the complete documentation index, see llms.txt. This page is also available as Markdown.

Referenzarchitekturen

Drei VergeOS-Bereitstellungsmodelle -- HCI, HCI + dediziertes Compute und UCI -- mit Entscheidungsrahmen, Topologiediagrammen und Leitlinien für Edge- und CSP-Szenarien.

VergeOS unterstützt drei Bereitstellungsarchitekturen mit derselben Softwareinstallation. Die Wahl der richtigen hängt von der Knotenzahl, dem Wachstumsmuster und den Anforderungen an die Spezialisierung der Workloads ab. Diese Seite führt durch jedes Modell, bietet einen Entscheidungsrahmen und behandelt zwei häufige praxisnahe Szenarien: Edge-Bereitstellungen und Multi-Tenant-Umgebungen von Cloud Service Providern (CSP).

Entscheidungsbaum für Architekturen

Verwenden Sie den folgenden Rahmen, um Ihre Empfehlung zu leiten. Die untenstehenden Knotenzahl-Bereiche sind grobe Faustregeln: HCI eignet sich für kleinere Bereitstellungen (typischerweise 2--12 Knoten), und UCI wird angewendet, wenn sich Wachstum von Rechenleistung und Speicher auseinanderentwickelt oder spezielle Hardware benötigt wird.

Kurze Faustregeln:

  1. Beginnen Sie mit HCI es sei denn, Sie haben einen konkreten Grund, es nicht zu tun.

  2. Ziehen Sie HCI + Compute in Betracht wenn der Bedarf an Rechenleistung schneller wächst als der Speicherbedarf (6--10 Knoten).

  3. Wählen Sie UCI für Umgebungen mit 10+ Knoten, spezialisierter Hardware oder maximaler Isolation der Leistung.

  4. Sie können sich weiterentwickeln von HCI zu HCI + Compute zu UCI, während die Umgebung wächst -- dieselbe VergeOS-Installation unterstützt alle drei.


Modell 1: HCI (Hyperkonvergente Infrastruktur)

Knotenbereich: 2--6 Knoten | Cluster: 1

In einer HCI-Bereitstellung trägt jeder Knoten sowohl Rechenleistung und Speicher. Die beiden Controller-Knoten tragen Tier-0- (vSAN-Metadaten) und Tier-1- (Workload-) Speicher und führen VMs aus. Scale-out-Knoten erweitern denselben Cluster um Tier-1-Speicher und Rechenkapazität.

Vorteile

  • Betriebliche Einfachheit -- ein einzelner Cluster, eine einzige Hardware-Spezifikation, einheitliche Verwaltung.

  • Vorhersehbare Skalierung -- jeder Knoten erweitert Speicher und Rechenleistung proportional.

  • Niedrigster Einstiegspunkt -- ein 2-Knoten-Cluster ist die kleinste mögliche VergeOS-Bereitstellung.

  • Eine einzige Hardwarespezifikation vereinfacht Beschaffung und Ersatzteillager.

Einschränkungen

  • Rechenleistung kann nicht unabhängig vom Speicher skaliert werden (und umgekehrt).

  • Begrenzte Hardwarespezialisierung -- alle Knoten haben dieselbe Rolle.

  • Empfohlene Höchstzahl von etwa 6 Knoten, bevor ein zweiter Cluster in Betracht gezogen wird.

  • Mögliche Ressourcen-Konkurrenz auf Controller-Knoten, die sowohl Metadatenoperationen als auch VM-Workloads ausführen.

Ideale Anwendungsfälle

Szenario
Warum HCI funktioniert

Kleine/mittelgroße Bereitstellungen (2--6 Knoten)

Minimale Komplexität, jeder Knoten übernimmt zwei Aufgaben

Ausgewogene Workloads

Speicher und Rechenleistung wachsen ungefähr mit derselben Rate

Edge-/Remote-Standorte

2-Knoten-Cluster mit vollständiger HA und kleinem Footprint

Evaluation und Tests

Schnellster Weg zu einem funktionsfähigen VergeOS-System


Modell 2: HCI + Dedizierte Rechenleistung (Hybride 2-Cluster-UCI)

Knotenbereich: 6--10 Knoten | Cluster: 2

Dies ist die hybride 2-Cluster-Variante von UCI: Controller- und Speicherrollen bleiben in einem HCI-Cluster zusammengeführt, während die Rechenleistung in einen eigenen Cluster ausgelagert wird. Der HCI-Cluster (Cluster 1) stellt den gesamten Speicher über seine Controller und optionalen Scale-out-Knoten bereit. Der Rechencluster (Cluster 2) führt VM-Workloads aus, ohne selbst Festplatten beizusteuern.

Wichtige Designprinzipien

Cluster 1 -- HCI (Kombiniert)

  • Enthält immer die Knoten 1 und 2 mit Tier-0-Speicher (Controller). - Kann zusätzliche HCI-Scale-out-Knoten für mehr Speicher und Rechenleistung enthalten. - Ein Cluster-Level-Schalter steuert, ob dieser Cluster auch VM-Workloads ausführt. - Alle Speicherebenen befinden sich in diesem Cluster.

Cluster 2 -- Nur Rechenleistung

  • Reine Rechenleistung -- maximale für VMs verfügbare CPU- und RAM-Kapazität. - Skaliert unabhängig je nach Rechenleistungsbedarf. - Unterstützt flexible, auf den Workload optimierte Hardware (GPU-Knoten, Knoten mit hohem Speicher). - Speicher-I/O von Rechenknoten läuft über die Kern-Fabric zu Cluster 1.

Vorteile

  • Unabhängige Skalierung der Rechenleistung ohne Kauf unerwünschten Speichers.

  • Erhält die betriebliche Einfachheit von HCI für die Speicherebene.

  • Kosteneffizient -- skalieren Sie nur die Ressourcenschicht, die wächst.

  • Klarer Wachstumspfad zur kanonischen 3-Cluster-UCI, falls sich die Anforderungen weiterentwickeln.

Einschränkungen

  • Speicher-I/O von Rechenknoten überquert das Netzwerk (ausreichende Kern-Fabric-Bandbreite ist entscheidend).

  • Komplexer als reines HCI (zwei Cluster statt eines zu verwalten).

  • Erfordert eine Entscheidung, ob der HCI-Cluster auch Workloads ausführen soll.

Ideale Anwendungsfälle

Szenario
Warum HCI + Compute funktioniert

Bereitstellungen mit 6--10 Knoten

Genau der richtige Bereich für das Zwei-Cluster-Modell

Wachstum der Rechenleistung übertrifft das des Speichers

CPU/RAM hinzufügen, ohne Festplatten zu erweitern

GPU- oder spezialisierte Rechenleistung

Dedizierter Rechencluster mit Passthrough-Hardware

Kostenoptimierung

Nur das skalieren, was Sie benötigen


Modell 3: UCI (Ultra Converged Infrastructure) -- kanonisches 3-Cluster-Modell

Knotenbereich: 10+ Knoten | Cluster: 3+

Das kanonische 3-Cluster-UCI trennt Controller, Speicher und Rechenleistung vollständig in dedizierte Cluster. Jede Ressourcenschicht ist unabhängig skalierbar und nutzt für ihre Rolle optimierte Hardware. (UCI ist ein Sammelbegriff für jede Bereitstellung mit unabhängiger Skalierung; Modell 2 oben ist die hybride 2-Cluster-Variante.)

Clusterspezialisierung

Cluster
Rolle
Optimiert für

Cluster 1 -- Controller

Tier-0-Metadaten, Clusterverwaltung

Hoher Speicher (z. B. 768 GB in der Data-Science-RA), hochbelastbare NVMe für Tier 0

Cluster 2 -- Speicher

Gesamter Workload-Speicher (Tier 1+)

Maximale Laufwerksdichte, NVMe oder SAS/SATA-SSD

Cluster 3+ -- Rechenleistung

VM-Workloads, spezialisierte Hardware

Standard-, GPU-, High-Memory- oder benutzerdefinierte Knotentypen

Vorteile

  • Maximale Leistung -- keine Ressourcen-Konkurrenz zwischen Speicher und Rechenleistung.

  • Vollständig unabhängige Skalierung -- Speicher ohne Rechenleistung hinzufügen (oder umgekehrt).

  • Hardwarespezialisierung -- Hardware passend zur Rolle dimensionieren (NVMe-dicht für Speicher, mit GPU für Rechenleistung).

  • Workload-Isolierung -- verschiedene Rechencluster für unterschiedliche Workload-Typen.

  • Optimal für große und Multi-Tenant-Umgebungen.

Einschränkungen

  • Höchste betriebliche Komplexität unter allen drei Architekturen.

  • Mindestens 6 Knoten (abgeleitet aus dem Minimum von 2 Knoten pro Cluster × 3 Clustern: 2 Controller + 2 Speicher + 2 Rechenknoten).

  • Komplexere Kapazitätsplanung über drei Clustertypen hinweg.

  • Höhere Anforderungen an die Kern-Fabric-Bandbreite zwischen den Clustern.

  • Für die Erstbereitstellung werden professionelle Services empfohlen.

Ideale Anwendungsfälle

Szenario
Warum UCI funktioniert

Unternehmensbereitstellungen mit 10+ Knoten

Unabhängige Skalierung vermeidet Überprovisionierung

KI-/HPC-/GPU-Workloads

Dedizierte GPU-Rechencluster, getrennt vom Speicher

Cloud Service Provider

Hardwareausgaben pro Ressourcenschicht über alle Tenants hinweg optimieren

Speicherlastiges oder rechenlastiges Wachstum

Nur das skalieren, was wächst


Architekturvergleich

Aspekt
HCI
HCI + Compute (Hybride 2-Cluster-UCI)
UCI (kanonisches 3-Cluster-Modell)

Mindestanzahl Knoten

2

4 (2 HCI + 2 Rechenleistung)

6 (2+2+2)

Clusteranzahl

1

2

3+

Leistung

Gut

Besser

Optimal

Hardwareflexibilität

Niedrig

Mittel

Maximal

Unabhängige Skalierung

Nein

Teilweise (nur Rechenleistung)

Vollständig

Spezialisierung

Keine

Nur Rechenleistung

Vollständig (Controller, Speicher, Rechenleistung)

Komplexität

Niedrig

Mittel

Hoch

Ressourceneffizienz

Variabel

Gut

Maximal

Beste Passung

Klein, ausgewogen

Mittlere Größe, rechenlastig

Groß, spezialisiert


Szenarien für Edge-Bereitstellungen

Edge-Cluster sind kompakte VergeOS-Bereitstellungen mit 2 Knoten, die für entfernte Standorte oder Niederlassungen konzipiert sind. Sie verwenden hardware mit niedrigem Stromverbrauch und kleinem Formfaktor und sind direkt verbunden (für die Kern-Fabric sind keine Switches erforderlich).

Typische Edge-Konfiguration

  • 2 Knoten direkt über zwei NICs verbunden (Kern-Fabric).

  • Hardware mit kleinem Formfaktor (Intel NUC, SFF-1L-PCs oder ähnlich).

  • 2 TB NVMe für Workloads + 4 TB SSD für Massenspeicher pro Knoten.

  • Vollständige HA und Redundanz trotz minimalem Footprint.

Edge-Verwaltungsmodelle

VergeOS unterstützt drei Edge-Verwaltungsszenarien mit zunehmender Komplexität:

  1. Standalone mit zentraler Verwaltung -- 2-Knoten-Cluster an jedem Standort, zentral verwaltet über das Sites Dashboard. Catalog-Repositories verteilen VM-Vorlagen vom Verwaltungscluster an alle Edge-Standorte.

  2. Zentrale Sicherung und DR -- wie oben, plus ein zentrales System im primären Rechenzentrum bietet Site Sync Replikation, ioGuardian Reparaturserver und zentralen Snapshot-Speicher für alle Niederlassungen.

  3. Mehrstufig mit Archiv -- fügt am DR-Standort einen zweiten Archivcluster für die Langzeitaufbewahrung mit hochkapazitiven HDDs hinzu und bietet damit eine vollständige 3-2-1-Backup-Strategie.

Wann Edge empfohlen werden sollte

  • Platz- oder Strombeschränkungen an entfernten Standorten.

  • Anwendungen, die Daten zentral speichern, aber lokale Rechenleistung benötigen.

  • Organisationen, die 5--100+ verteilte Standorte verwalten.

  • Kostensensible Bereitstellungen für Zweigstellen.


CSP-/Multi-Tenant-Szenarien

Cloud Service Provider nutzen die Multi-Tenancy von VergeOS, um IaaS aus gemeinsam genutzter Infrastruktur bereitzustellen. Jeder Tenant arbeitet als isoliertes Virtuelles Rechenzentrum (VDC) mit eigener Benutzeroberfläche, eigenen Netzwerken, eigenem Speicher und eigenen Zugriffskontrollen.

Typische CSP-Konfiguration

  • 6-Knoten-HCI-Cluster in primären Rechenzentren (Server mit hoher Dichte, 768 GB+ RAM pro Knoten).

  • Site Sync zwischen Rechenzentren für DR.

  • ioGuardian Reparaturserver für automatisches Blockabrufen von entfernten Standorten.

  • Globale Inline-Deduplizierung reduziert den Speicherverbrauch über replizierte Snapshots hinweg.

  • Tenant-Rezepte automatisieren die Bereitstellung kompletter Kundenumgebungen (Tenant, Netzwerke, Firewall-Regeln, VMs, Speicher).

Wachstumspfad für CSPs

Phase
Bereitstellung
Knoten

Phase 1

2 primäre Standorte mit DR über Site Sync

6 pro Standort

Phase 2

2-Knoten-Edge-Cluster in neuen Regionen hinzufügen

2 pro Region

Phase 3

Edge-Standorte durch Hinzufügen von Clustern ausbauen (illustrativ)

variiert je Standort

Phase 4

Dedizierte Speichercluster für speicherlastige Tenants und Archivschichten hinzufügen

2+ Speicherknoten pro Standort

Wichtige VergeOS-Funktionen für CSPs

  • Multi-Tenancy mit vollständiger Isolierung zwischen Kundenumgebungen.

  • Self-Service-Verwaltung über Web-UI und API für Tenant-Administratoren.

  • Catalog-Repositories für zentrale Verwaltung von VM-Vorlagen.

  • OpenID-Authentifizierung Integration mit vorhandenen Identitätsanbietern.

  • Tenant-Rezepte für automatisiertes, wiederholbares Onboarding von Kunden.


Überblick über Netzwerkdesign-Modelle

Die von Ihnen gewählte Bereitstellungsarchitektur beeinflusst Ihr Netzwerkdesign. VergeOS unterstützt mehrere Netzwerktopologien, die in Modul 4: Netzwerkedetailliert behandelt werden. Hier ist ein kurzer Überblick, der Ihre Architekturentscheidung unterstützt:

Modell
NICs pro Knoten
Kern-Fabric
Externes Netzwerk
Am besten geeignet für

L2 statisch + dedizierter Core

4

2 dedizierte L2

Gebündeltes L2 (LACP)

Produktionsumgebungen, VMware-Migrationen

L3 dynamisch + dedizierter Core

4

2 dedizierte L2

per BGP / OSPF / EIGRP angekündigt

Groß angelegte Umgebungen, fortgeschrittene Segmentierung

L3 statisch + dedizierter Core

4

2 dedizierte L2

Gebündeltes L3 (statische Routen)

Groß angelegte Umgebungen, Layer-3-Switching

L2 statisch (2 NICs)

2

2 gemeinsam genutzte (VLAN-getaggt)

Gemeinsam mit dem Core (VLAN-getaggt)

Edge, PoC, kleine Bereitstellungen

Wichtige Anforderungen für alle Modelle:

  • Kern-Fabric-Netzwerke müssen auf dedizierten Layer-2-Segmenten (voneinander isoliert).

  • Jumbo-Frames (MTU 9216+) auf allen Switch-Ports des Core-Fabrics.

  • Keine Switch-Hops zwischen Knoten im Core-Fabric -- alle Knoten müssen mit demselben Switching-Fabric verbunden sein.

  • STP auf Core-Fabric-Ports deaktiviert.


VMware Bridge

Kommen Sie von VMware? VergeOS ermöglicht es Ihnen, Storage und Compute innerhalb eines Systems unabhängig voneinander zu skalieren — reine Compute-Cluster nutzen das gemeinsam genutzte vSAN über das Core-Fabric, ohne externes SAN/NAS und ohne ein separates Storage-Produkt lizenzieren zu müssen.

Nutanix Bridge

Kommen Sie von Nutanix? VergeOS erstellt reine Storage-Cluster und reine Compute-Cluster in einem System — Storage läuft als integrierter OS-Dienst, sodass keine CVM RAM/CPU auf einem beliebigen Knotentyp verbraucht.

Zusammenfassung

Konzept
Wichtigste Erkenntnis

HCI

Jeder Knoten macht alles. Einfach, kosteneffizient im kleinen Maßstab. Hier beginnen.

HCI + Compute

Hybrides 2-Cluster-UCI: Controller+Storage zusammengelegt, unabhängige Compute-Skalierung.

UCI

Kanonisches 3-Cluster: dedizierter Controller, Storage und Compute. Maximale Flexibilität.

Edge

2-Knoten-Direct-Connect-Cluster für entfernte Standorte, zentral verwaltet.

CSP

Mandantenfähige HCI-Bereitstellungen mit Site Sync DR und automatisierter Tenant-Rezeptur.

Evolution

Dieselbe VergeOS-Installation unterstützt alle drei Modelle -- wachsen Sie im Laufe der Zeit von HCI zu UCI.

Nächste Schritte

  • Kunden-Scoping -- Lernen Sie die Methodik zur Anforderungserhebung, um Kundenbedürfnisse in eine konkrete Architekturempfehlung zu übersetzen.

  • Netzwerk -- Vertiefung der oben genannten Netzwerkdesign-Modelle.

Zuletzt aktualisiert

War das hilfreich?