> 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-2-dimensionierung-and-design/03-customer-scoping.md).
# Kunden-Scoping
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
| Datenpunkt | Warum das wichtig ist |
| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **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](#ram-reservation-decision) 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:
```
Gesamtzahl der vCPU-Kerne = Σ (Kerne pro VM)
Gesamt-RAM (GB) = Σ (RAM pro VM)
Gesamtspeicher (TB) = Σ (bereitgestellter Speicher pro VM)
```
### Schritt 2: VergeOS-System-Overhead hinzufügen
Der Overhead von VergeOS ist minimal, muss aber berücksichtigt werden:
| Ressource | Overhead |
| ----------------------------------- | ------------------------------------------------------------------------- |
| **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 |
{% hint style="success" %}
**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).
{% endhint %}
### 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**
```mermaid
flowchart TD
A["Gesamt-Workload
CPU + RAM + Speicher"] --> B["VergeOS-Overhead hinzufügen
16 GB + 1 GB/TB pro Knoten"]
B --> C["HA-Spielraum anwenden
(N-1)/N-Auslastungsziel"]
C --> D["Durch Kapazität pro Knoten teilen"]
D --> E{"Anzahl der Knoten?"}
E -->|"2-6"| HCI["HCI empfehlen"]
E -->|"6-10"| HCC["HCI + Compute empfehlen"]
E -->|"10+"| UCI["UCI empfehlen"]
style HCI fill:#d1fae5,stroke:#059669
style HCC fill:#fef3c7,stroke:#d97706
style UCI fill:#e0e7ff,stroke:#4f46e5
```
***
## 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:
1. **Die Ressourcenanforderungen die Cluster-Maximalwerte überschreiten** — die `Maximaler RAM pro Maschine` und `Maximale Kerne pro Maschine` Cluster-Einstellungen begrenzen die Größe eines einzelnen Tenant-Knotens.
2. **Verteilte Anwendungen** Workloads auf verschiedenen physischen Hosts erforderlich sind (z. B. primäre/replizierte Datenbank auf separaten Knoten für HA).
3. **Gemischte Hardwarefähigkeiten** — der Tenant sowohl Standard-Compute- als auch GPU-ausgestattete Knoten benötigt, die auf unterschiedlichen physischen Clustern laufen.
4. **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:
1. **Für den aktuellen oder kurzfristigen Bedarf dimensionieren** — nicht spekulativ für zukünftiges Wachstum überdimensionieren.
2. **Organisch skalieren** — die Ressourcen der Tenant-Knoten erhöhen, sobald der Bedarf entsteht.
3. **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:
| Entscheidungskriterien | HCI | HCI + Compute | UCI |
| ---------------------------------- | ----------------------------------- | -------------------------------- | ---------------------------------------------------------- |
| **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
1. **Liegt die Knotenanzahl unter 6?** → Beginnen Sie mit HCI, sofern es keinen besonderen Grund gibt, Compute zu trennen.
2. **Wächst der Compute-Bereich schneller als der Speicher?** → HCI + Compute ermöglicht das Hinzufügen günstiger Compute-only-Knoten.
3. **Gibt es GPU-, High-Memory- oder andere spezialisierte Hardwareanforderungen?** → UCI ermöglicht dedizierte Compute-Cluster pro Hardwaretyp.
4. **Muss der Kunde den Speicher unabhängig skalieren?** → UCI ist das einzige Modell mit einem dedizierten Speicher-Cluster.
5. **Hat operative Einfachheit oberste Priorität?** → HCI hat den geringsten Verwaltungs-Overhead.
6. **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**:
| Option | Verhalten | Am besten geeignet für |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **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 |
{% hint style="warning" %}
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.
{% endhint %}
***
## 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
| Netzwerk | Adresse | Zweck |
| ---------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 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).
***
{% hint style="info" %}
**Kommen Sie von VMware oder Nutanix?**
VergeOS-Scoping ist ein einziger Dimensionierungslauf: flacher OS-Overhead von 16 GB pro Knoten plus 1 GB pro TB Rohspeicher. Es gibt keine CVM, kein separates Management-Appliance und keine pro Feature Lizenzierungsübung — Compute, Speicher, Netzwerk und Multi-Tenancy werden zusammen als eine Plattform dimensioniert.
{% endhint %}
***
## Zusammenfassung
| Phase | Ausgabe |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **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**](/learn-the-platform/de/modul-2-dimensionierung-and-design/01-hardware-requirements.md) — Überprüfen Sie Ihre Knotenspezifikationen anhand der Mindest- und empfohlenen Anforderungen.
* [**Referenzarchitekturen**](/learn-the-platform/de/modul-2-dimensionierung-and-design/02-reference-architectures.md) — Prüfen Sie die detaillierten Topologiediagramme für Ihre gewählte Architektur.
* [**Modul 3: Installation**](/learn-the-platform/de/modul-3-installation/03-installation.md) — Fahren Sie mit der Vorbereitung und Durchführung der Installation fort.
---
# 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-2-dimensionierung-and-design/03-customer-scoping.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.