Kundenscoping
Methodik zur Anforderungserfassung, Übersetzung von Workloads in Ressourcen, Planung von Mandantenknoten, Rahmenwerk zur Topologieauswahl und Dokumentationsartefakte für VergeOS-Bereitstellungen.
Eine gut abgegrenzte VergeOS-Bereitstellung beginnt lange bevor der erste Knoten im Rack montiert ist. Diese Seite bietet eine strukturierte Methodik zum Erfassen der Kundenanforderungen, zur Übersetzung von Workloads in VergeOS-Ressourcenschätzungen, zur Planung von Tenant-Knoten-Konfigurationen und zur Auswahl der passenden Bereitstellungstopologie. Am Ende dieses Prozesses sollten Sie einen vollständigen Satz an Dokumentationsartefakten haben, den jeder VergeOS-Engineer für die Durchführung der Installation verwenden kann.
Checkliste zur Anforderungserfassung
Jede Scoping-Begleitung sollte damit beginnen, die folgenden Informationen vom Kunden zu erfassen. Verwenden Sie diese Checkliste als Gesprächsleitfaden während der Entdeckungsgespräche.
Aktuelles Workload-Inventar
Gesamtanzahl der VMs
Legt den Umfang der Bereitstellung fest und beeinflusst die Auswahl der Architektur
CPU-Kerne pro VM
Treibt die Dimensionierung des Compute-Clusters voran und identifiziert CPU-intensive Ausreißer
RAM-Zuweisung pro VM
RAM ist in der Regel die begrenzende Ressource; bestimmt die Anzahl der Knoten
Speicher pro VM (bereitgestellt und genutzt)
Unterscheidet zwischen thin-provisionierter Kapazität und tatsächlichem Verbrauch
Storage-IOPS- / Latenzanforderungen
Identifiziert Workloads, die NVMe erfordern, gegenüber solchen, die SAS/SATA-SSD tolerieren
Anforderungen an GPU oder spezialisierte Hardware
Bestimmt, ob Compute-Cluster Passthrough-Geräte benötigen
Betriebssystem-Mix
Windows, Linux, BSD — wirkt sich auf die Treiber- und Integrationsplanung aus
Wachstumsprognosen
6-Monats-, 12-Monats- und 24-Monats-Prognosen für VM-Anzahl, CPU, RAM und Speicher.
Wachstumsmuster: Wächst der Compute-Bereich schneller als der Speicher oder proportional? Dies beeinflusst direkt die Entscheidung zwischen HCI, HCI + Compute und UCI.
Saisonale oder Burst-Muster — Workloads mit Spitzenzeiten benötigen möglicherweise mehr Spielraum, als stabile Kennzahlen erkennen lassen.
Leistungsanforderungen
IOPS-Ziele pro Workload-Stufe (Datenbank, Anwendung, Dateidienste).
Latenzanforderungen — unter einer Millisekunde für Datenbanken gegenüber allgemein für Dateiserver.
Durchsatz — sequenzielle Lese-/Schreibbandbreite für Backup-, Medien- oder Analyse-Workloads.
Verfügbarkeits- und DR-Anforderungen
RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel? Bestimmt die Snapshot-Frequenz und den Zeitplan für die Site-Synchronisation.
RTO (Recovery Time Objective): Wie schnell müssen Dienste wiederhergestellt werden? Beeinflusst, ob Tenants Multi-Node-HA oder Single-Node mit automatischem Failover benötigen.
N+1-Erwartungen: Kann der Cluster einen vollständigen Knotenausfall überstehen, während alle Workloads weiterlaufen? Dies hängt direkt mit der Entscheidung zur RAM-Reservierung zusammen, die weiter unten auf dieser Seite behandelt wird.
Anforderungen an den DR-Standort: Benötigt der Kunde Site-Sync-Replikation an einen sekundären Standort?
Netzwerktopologie und Einschränkungen
Vorhandene Switching-Infrastruktur: Marke, Modell, Funktionen (MLAG, LACP, BGP).
Verfügbare NICs pro Knoten: 2 vs. 4+ bestimmt das Modell des Netzwerkdesigns.
VLAN-Anforderungen: Wie viele isolierte Netzwerke werden benötigt? Befinden sich Tenants auf gemeinsamen oder dedizierten VLANs?
Physische Einschränkungen: Befindet sich die gesamte Hardware in einem einzigen Rack? In mehreren Racks? An mehreren Standorten?
Latenz des Core-Fabrics: Alle Knoten müssen sich im selben Switching-Fabric mit null Switch-Hops befinden.
Budget und Zeitplan
Hardware-Budget: Beeinflusst die Auswahl des Serverherstellers und die Anzahl der Knoten.
Lizenzmodell: Knotenbasiert — beeinflusst die Strategie zur Kostenoptimierung.
Installationszeitplan: Standard- vs. gestaffelter Rollout.
Übersetzung von Workloads in Ressourcen
Sobald Sie das Workload-Inventar des Kunden haben, übersetzen Sie es in VergeOS-Ressourcenanforderungen. VergeOS hat deutlich weniger Overhead als traditionelle Plattformen — es gibt keine Controller-VM (CVM), kein vCenter-Appliance und keine separate Management-Ebene, die Ressourcen verbraucht.
Schritt 1: Workload-Gesamtsummen bilden
Summieren Sie die Workload-Anforderungen des Kunden:
Schritt 2: VergeOS-System-Overhead hinzufügen
Der Overhead von VergeOS ist minimal, muss aber berücksichtigt werden:
RAM pro vSAN-Knoten
16 GB für VergeOS + 1 GB pro 1 TB Rohspeicher auf diesem Knoten (Minimum)
RAM pro vSAN-Knoten (empfohlen)
16 GB + 1,5 GB pro 1 TB Rohspeicher
CPU pro Speicherknoten
1 Kern pro Festplatte (empfohlen)
Tier-0-Speicher
5–10 GB pro 1 TB nutzbarer Kapazität (nur Controller-Knoten)
Nur-Compute-Knoten
Nur 16 GB für VergeOS; kein Speicher-Overhead
RAM des Tenant-Knotens: kein zusätzlicher Overhead auf Host-Ebene
Wenn Sie einem Tenant-Knoten RAM zuweisen, ist dieser gesamte Betrag das, was der Host reserviert — Sie nicht fügen für den Tenant keinen separaten Host-Layer-Overhead hinzu. Innerhalb des Tenants verbraucht jedoch dessen eigene verschachtelte VergeOS-Instanz den Standard-Overhead (16 GB + 1 GB pro 1 TB Speicher) aus dieser Zuweisung, bevor die Gast-VMs des Tenants Speicher erhalten.
Es gibt also zwei separate Ebenen: auf der host, konfigurieren Sie den Tenant-Knoten = den RAM, den der Tenant haben soll. Innerhalb des Tenant, planen Sie seine Gast-Workloads gegen (zugewiesener RAM − 16 GB − 1 GB/TB).
Schritt 3: HA-Spielraum berücksichtigen
Wenn der Kunde N+1-Verfügbarkeit verlangt (der Cluster kann einen Knotenausfall überstehen, während alle VMs weiterlaufen), müssen Sie sicherstellen, dass die verbleibenden Knoten über genügend aggregierte CPU und RAM verfügen, um die Workloads des ausgefallenen Knotens aufzunehmen.
Faustregel: Für einen Cluster mit N Knoten sollte jeder Knoten so dimensioniert werden, dass er nicht mehr als (N-1)/N seiner gesamten Ressourcen nutzt. In einem Cluster mit 4 Knoten zielen Sie beispielsweise auf 75 % Auslastung pro Knoten.
Schritt 4: Knotenanzahl berechnen
Teilen Sie die gesamten Ressourcenanforderungen (einschließlich Overhead und HA-Spielraum) durch die Kapazität pro Knoten, um die Mindestanzahl der Knoten zu bestimmen. Runden Sie immer auf und validieren Sie das Ergebnis anhand der Referenzarchitekturen. Die folgenden Knotenanzahl-Bereiche sind grobe Faustregeln — HCI passt zu kleineren Bereitstellungen (typischerweise 2--12 Knoten), und UCI wird verwendet, wenn sich Compute- und Speicherwachstum auseinanderentwickeln oder spezialisierte Hardware benötigt wird:
2–6 Knoten → HCI
6–10 Knoten → HCI + Dedizierter Compute
10+ Knoten → UCI
Planung von Tenant-Knoten
Bei Multi-Tenant-Bereitstellungen (CSP, MSP oder interne Abteilungsisolierung) läuft jeder Tenant in einem Virtual Data Center (VDC), das von einem oder mehreren Mandantenknoten. Tenant-Knoten sind virtuelle Maschinen, die als Compute-Knoten der verschachtelten VergeOS-Instanz des Tenants fungieren; Speicher wird aus den Kontingenten der Host-Speicherebene bereitgestellt und das Networking über die virtuellen Netzwerke des Tenants.
Single-Node- vs. Multi-Node-Tenants
Single-Node-Tenants sind der Standard und der bevorzugte Ausgangspunkt:
Bieten Redundanz durch automatisches Failover — wenn der physische Host ausfällt, startet der Tenant-Knoten automatisch auf einem anderen Host neu.
Einfacher zu verwalten und passend zu dimensionieren.
Kann vertikal skaliert werden (Kerne/RAM hinzufügen), ohne Unterbrechung.
Zusätzliche Knoten können später ohne Unterbrechung hinzugefügt werden, wenn der Tenant wächst.
Multi-Node-Tenants werden benötigt, wenn:
Die Ressourcenanforderungen die Cluster-Maximalwerte überschreiten — die
Maximaler RAM pro MaschineundMaximale Kerne pro MaschineCluster-Einstellungen begrenzen die Größe eines einzelnen Tenant-Knotens.Verteilte Anwendungen Workloads auf verschiedenen physischen Hosts erforderlich sind (z. B. primäre/replizierte Datenbank auf separaten Knoten für HA).
Gemischte Hardwarefähigkeiten — der Tenant sowohl Standard-Compute- als auch GPU-ausgestattete Knoten benötigt, die auf unterschiedlichen physischen Clustern laufen.
Regulatorische Anforderungen schreiben eine Hardware-Trennung zwischen Workload-Typen vor.
Strategie zur bedarfsgerechten Dimensionierung
VergeOS-Mandanten unterstützen unterbrechungsfreie Skalierung — Sie können Ressourcen zu vorhandenen Knoten hinzufügen oder vollständig neue Knoten hinzufügen, ohne laufende Workloads zu unterbrechen. Der empfohlene Ansatz:
Für den aktuellen oder kurzfristigen Bedarf dimensionieren — nicht spekulativ für zukünftiges Wachstum überdimensionieren.
Organisch skalieren — die Ressourcen der Tenant-Knoten erhöhen, sobald der Bedarf entsteht.
Vorhandene Knoten maximal ausnutzen, bevor neue hinzugefügt werden — es ist effizienter, einen Knoten von 32 GB auf 64 GB zu erweitern, als einen zweiten 32-GB-Knoten hinzuzufügen, sofern die Anwendungs-HA keine physische Trennung erfordert.
Beispielkonfigurationen
Klein, Single-Node
Szenario: 3 VMs, keine besonderen Anforderungen, Cluster erlaubt max. 64 GB / 16 Kerne.
Konfiguration: 1 Tenant-Knoten — 16 GB RAM, 8 Kerne.
Skalierungsweg: RAM/Kerne zum vorhandenen Knoten hinzufügen (bis zu 64 GB / 16 Kerne), dann bei Bedarf einen zweiten Knoten hinzufügen.
Mittelgroßes HA
Szenario: Webfarm mit 4 Webservern + 2 Datenbankservern, die eine physische Host-Trennung erfordern.
Konfiguration: 2 Tenant-Knoten — jeweils 64 GB RAM, 12 Kerne. HA-Gruppen erzwingen Anti-Affinität, sodass Web-/Datenbankinstanzen auf verschiedenen physischen Hosts laufen.
Skalierungsweg: Knotenressourcen erhöhen oder einen dritten Knoten für weitere Workload-Verteilung hinzufügen.
Gemischter Workload mit GPU
Szenario: Standard-VMs + GPU-beschleunigtes Video-Rendering auf unterschiedlichen Hardware-Clustern.
Konfiguration: 4 Tenant-Knoten — 2 im Standard-Cluster (je 64 GB), 1 im vGPU-Cluster (64 GB), 1 im High-Performance-Cluster (48 GB).
Skalierungsweg: Jeden Knoten unabhängig anhand der Fähigkeiten seines Clusters und der Workload-Nachfrage skalieren.
Unternehmensweit verteilt
Szenario: Verteilte Analyseplattform, die 3 Anwendungsserver auf separaten physischen Hosts + Datenverarbeitungsknoten erfordert.
Konfiguration: 4 Tenant-Knoten — 3 × 64 GB / 12 Kerne (Anwendung + Datenbank pro Knoten mit HA-Group-Anti-Affinität) + 1 × 32 GB / 8 Kerne (Datenverarbeitung).
Skalierungsweg: Ressourcen zu vorhandenen Knoten hinzufügen oder Knoten für weitere physische Trennung hinzufügen.
Entscheidungsrahmen für die Topologieauswahl
Wenn die Workload-Anforderungen erfasst und die Ressourcenumrechnung abgeschlossen sind, verwenden Sie die folgenden Kriterien, um Ihre Architektur-Empfehlung abzugeben:
Knotenanzahl
2–6
6–10
10+
Wachstumsmuster
Proportional (Compute ≈ Speicher)
Compute > Speicher
Beides (vollständig unabhängig)
Spezialisierung
Nicht erforderlich
Einige (GPU im Compute-Cluster)
Vollständig (GPU, viel Speicher, speicherdichte Workloads)
Toleranz gegenüber Komplexität
Wenige IT-Mitarbeiter
Mäßig
Dediziertes Infrastrukturteam
Budget
Am kosteneffizientesten
Mäßig
Am höchsten (aber in großem Maßstab am effizientesten)
Leistungsisolierung
Akzeptable Konkurrenz um Ressourcen
Compute vom Storage-I/O isoliert
Maximal — jede Rolle auf dedizierter Hardware
Entscheidungs-Checkliste
Liegt die Knotenanzahl unter 6? → Beginnen Sie mit HCI, sofern es keinen besonderen Grund gibt, Compute zu trennen.
Wächst der Compute-Bereich schneller als der Speicher? → HCI + Compute ermöglicht das Hinzufügen günstiger Compute-only-Knoten.
Gibt es GPU-, High-Memory- oder andere spezialisierte Hardwareanforderungen? → UCI ermöglicht dedizierte Compute-Cluster pro Hardwaretyp.
Muss der Kunde den Speicher unabhängig skalieren? → UCI ist das einzige Modell mit einem dedizierten Speicher-Cluster.
Hat operative Einfachheit oberste Priorität? → HCI hat den geringsten Verwaltungs-Overhead.
Kann sich die Umgebung im Laufe der Zeit weiterentwickeln? → Immer. VergeOS unterstützt den Übergang von HCI → HCI + Compute → UCI durch Hinzufügen von Clustern zu einem bestehenden System.
Entscheidung zur RAM-Reservierung
Während der Installation muss der Engineer die Präferenz für die RAM-Reservierung festlegen. Dies ist ein Kompromiss zwischen nutzbarem Speicher und N+1-HA-Durchsetzung:
Mehr nutzbarer Speicher
Das System ermöglicht es VMs, mehr des verfügbaren RAM zu nutzen, wodurch die automatische Reservierung für Failover-Spielraum reduziert wird
Umgebungen, in denen die Maximierung der Workload-Dichte pro Knoten wichtiger ist als garantierte N+1-Failover-Kapazität
Mehr N+1-HA-Durchsetzung
Das System reserviert mehr RAM, um sicherzustellen, dass bei einem Knotenausfall die verbleibenden Knoten garantierte Kapazität haben, alle verdrängten Workloads aufzunehmen
Produktionsumgebungen mit strikten Verfügbarkeits-SLAs, in denen garantiertes Failover nicht verhandelbar ist
Diese Entscheidung sollte vor dem am Installationstag getroffen werden. Besprechen Sie den Kompromiss während des Scopings mit dem Kunden und dokumentieren Sie die gewählte Präferenz im Installationsplan.
Dokumentationslieferobjekte
Eine vollständige Scoping-Begleitung sollte das folgende Dokumentationspaket hervorbringen, bereit für den Installationsingenieur:
1. Netzwerkdesign-Dokumentation
Layer-2-Designzeichnung — physische Switches, VLANs, Portzuweisungen, MLAG-/Stacking-Konfiguration.
Layer-3-Designzeichnung — Subnetze, Gateways, Routing (BGP/OSPF, falls zutreffend), DNS-Server.
A-B-Kabelplan — jedes Kabel von jedem Knoten zu jedem Switch, beschriftet mit Port-Identifikatoren.
Core-Fabric-Konfiguration — dedizierte VLANs für Core 1 und Core 2, Bestätigung von MTU 9216+, Verifizierung von null Switch-Hops.
2. Rack-Höhendarstellung
Physische Platzierung jedes Knotens, Switches, PDUs und des Kabelmanagements.
Zuweisung der Stromkreise und Redundanzzuordnung.
3. IP-Zuweisungsplan
Verwaltung/UI
10.x.x.2/24
VergeOS-Weboberfläche und API
Gateway
10.x.x.1
Standard-Gateway für externen Datenverkehr
Core Fabric 1
VLAN 900
Nicht getaggtes Access-VLAN, auf dem Switch erstellt; Knoten-IP-Adressen werden von VergeOS automatisch zugewiesen. Speicher- und Steuerverkehr zwischen den Knoten
Core Fabric 2
VLAN 901
Nicht getaggtes Access-VLAN, auf dem Switch erstellt; Knoten-IP-Adressen werden von VergeOS automatisch zugewiesen. Redundanter Verkehr zwischen den Knoten
IPMI
192.168.x.0/24
Out-of-Band-Verwaltung
Tenant-Netzwerke
Zuweisung pro Tenant
Kundenspezifische Subnetze
4. Stückliste der Hardware
Servermodell, CPU, RAM, Festplattenkonfiguration pro Knoten.
NIC-Typen und Geschwindigkeiten.
Switch-Modelle und Portanzahlen.
Tier-0-NVMe-Spezifikationen (DWPD, Kapazität pro TB nutzbaren Speichers).
5. Installationsplan
Gewählte Referenzarchitektur (HCI, HCI + Compute oder UCI).
Zuordnung der Festplattentier pro Knoten.
Präferenz für die RAM-Reservierung (nutzbarer Speicher vs. N+1-Durchsetzung).
Entscheidung zur Verschlüsselung (Verschlüsselung im Ruhezustand ja/nein, Schlüsselverwaltungsplan).
NTP-Serverkonfiguration.
Plan für Admin-Zugangsdaten (Verweis auf das Passwort-Repository).
Zusammenfassung
Anforderungserfassung
Abgeschlossene Checkliste mit Workload-Inventar, Wachstumsprognosen, Leistungszielen und Netzwerkeinschränkungen
Ressourcenübersetzung
Gesamte CPU, RAM und Speicher mit angewendetem VergeOS-Overhead und HA-Spielraum
Tenant-Planung
Entscheidungen zu Single-Node vs. Multi-Node pro Tenant mit Beispielkonfigurationen
Topologieauswahl
HCI-, HCI + Compute- oder UCI-Empfehlung mit Begründung
RAM-Reservierung
Dokumentierte Präferenz — nutzbarer Speicher vs. N+1-Durchsetzung
Dokumentationspaket
Netzwerkzeichnungen, Rack-Höhendarstellung, IP-Plan, BOM und Installationsplan
Nächste Schritte
Hardwareanforderungen — Überprüfen Sie Ihre Knotenspezifikationen anhand der Mindest- und empfohlenen Anforderungen.
Referenzarchitekturen — Prüfen Sie die detaillierten Topologiediagramme für Ihre gewählte Architektur.
Modul 3: Installation — Fahren Sie mit der Vorbereitung und Durchführung der Installation fort.
Zuletzt aktualisiert
War das hilfreich?