> 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/01-hardware-requirements.md). # Hardwareanforderungen ## Überblick Die Dimensionierung einer VergeOS-Bereitstellung beginnt mit dem Verständnis der Hardwareanforderungen für jede Knotenrolle. Da VergeOS ein vollständiges Infrastruktur-Betriebssystem ist -- und keine Sammlung separater Produkte -- ist sein Basis-Overhead bemerkenswert gering. Es gibt keine VM für eine Management-Appliance, keine Controller-VM pro Knoten und keine separate Speicher-Software, die versorgt werden muss. Die folgenden Spezifikationen decken ab, was VergeOS selbst benötigt; die Kapazität für Ihre Workloads kommt zusätzlich oben drauf. {% hint style="info" %} **Kommen Sie von VMware oder Nutanix?** VergeOS hat keine VM für eine Management-Appliance und keine Speicher-VM pro Knoten (keine CVM), sodass das 16-GB-Mindestspeicherlimit den gesamten Footprint der Management-Ebene pro Knoten darstellt. Der vSAN-RAM (1 GB pro 1 TB Speicher) kommt zusätzlich hinzu und wird entsprechend der Festplattenkapazität dimensioniert, die jeder Knoten beiträgt. {% endhint %} ## Allgemeine Anforderungen (alle Knotentypen) Jeder Knoten in einem VergeOS-Cluster -- unabhängig von seiner Rolle -- muss diese Basisanforderungen erfüllen: | Komponente | Mindest-Spezifikation | | ------------------------- | ----------------------------------------------------------------------------------------------------------- | | **CPU** | AMD oder Intel x86-64 mit Unterstützung für Hardware-Virtualisierung (VT-x / AMD-V) | | **RAM** | 16 GB für VergeOS reserviert (zusätzlicher RAM für Workloads) | | **Remote-Verwaltung** | IPMI, iDRAC, iLO oder eine gleichwertige Out-of-Band-Verwaltung | | **Festplattencontroller** | NVMe direkt angeschlossen (bevorzugt) oder HBA-/RAID-Controller im JBOD-/IT-Modus -- **kein Hardware-RAID** | | **Externes NIC** | 1 x 1 GbE (Intel, NVIDIA Mellanox oder Broadcom) | | **Core-Fabric-NIC** | 1 x 10 GbE (Intel, NVIDIA Mellanox oder Broadcom) | {% hint style="warning" %} **Kein Hardware-RAID** VergeOS verwaltet die Datenredundanz über das integrierte vSAN (VergeFS). Hardware-RAID-Controller müssen in **JBOD- oder IT-Modus** versetzt werden, damit VergeOS einzelne Festplatten erkennen und verwalten kann. Die Verwendung von RAID-Arrays verbirgt Informationen zum Festplattenzustand und verhindert, dass VergeOS seinen eigenen Datenschutz ausführt. {% endhint %} ### Checkliste für BIOS-Einstellungen Überprüfen Sie vor der Installation diese BIOS-Einstellungen auf jedem Knoten: * **Boot-Modus:** UEFI (erforderlich, wenn alle Laufwerke NVMe sind) * **Hardwaregestützte Virtualisierung:** Aktiviert (VT-x / AMD-V) * **Hyper-Threading / SMT:** Aktiviert * **Alle Prozessorkerne:** Aktiviert * **Systemuhren:** Auf allen Knoten synchronisiert (innerhalb von Sekunden) * **Secure Boot:** Deaktiviert ## Controller-Knoten (Knoten 1 und Knoten 2) Die ersten beiden Knoten in jedem VergeOS-System sind die **Controller-Knoten**. Sie hosten die vSAN-Metadaten (Tier 0), verwalten die Cluster-Orchestrierung und dienen als Management-Ebene des Systems. Jede VergeOS-Installation benötigt mindestens zwei Controller-Knoten: Zwei Controller bieten N+1-Redundanz (der Standard). Das gleichzeitige Überleben des Ausfalls von zwei Controllern -- N+2 (RF3, drei Kopien jedes Datenblocks) -- erfordert drei Controller-Knoten, und fünf werden für N+2 empfohlen, um einen Witness bereitzustellen und Split-Brain-Szenarien zu vermeiden. ### Mindest-Spezifikationen | Komponente | Spezifikation | Hinweise | | -------------------- | -------------------------------------------------- | --------------------------------------------------------------- | | **CPU** | 1 x 2,7 GHz+ | Eine höhere Taktfrequenz verbessert Metadaten-Operationen | | **RAM** | 16 GB + 1 GB pro 1 TB Speicher | Das Verhältnis von 1 GB/TB gilt für den vSAN-Metadaten-Overhead | | **Tier-0-Speicher** | 1 x Enterprise-NVMe-SSD (3 DWPD oder gleichwertig) | Speichert die vSAN-Hash-Map und den Dateisystemindex | | **Tier-0-Kapazität** | 5 GB pro 1 TB nutzbarer Kapazität | Dedizierter Metadatenspeicher | ### Empfohlene Spezifikationen | Komponente | Spezifikation | Hinweise | | -------------------- | -------------------------------------------------- | -------------------------------------------------------- | | **CPU** | 1 x 3,0 GHz+ | Verbessert die Leistung von Metadaten und Orchestrierung | | **Tier-0-Speicher** | 2 x Enterprise-NVMe-SSD (3 DWPD oder gleichwertig) | Redundante Metadatenkonfiguration | | **Tier-0-Kapazität** | 10 GB pro 1 TB nutzbarer Kapazität | Zusätzlicher Spielraum für Metadatenwachstum | {% hint style="success" %} **Tier 0 ist nur für Metadaten** Tier 0 speichert die vSAN-Hash-Map und den Dateisystemindex -- es ist **nicht** eine Datenebene für Workloads. Sie liegt aus Leistungsgründen auf schnellem NVMe: Die Dedup-Hash-Map und der Dateisystemindex auf medien mit geringer Latenz zu halten, sorgt für schnelle Suchvorgänge im gesamten Speicherpool. Tier 0 ist schreibintensiv, daher benötigen die Laufwerke eine hohe Lebensdauer -- **3 DWPD oder gleichwertig**. Die Lebensdauer skaliert mit der Kapazität (DWPD × Kapazität = Writes/Tag), daher ist ein größeres Laufwerk mit niedrigerem DWPD gleichwertig: Ein 1-TB-Laufwerk mit 3 DWPD und ein 3-TB-Laufwerk mit 1 DWPD verkraften beide 3 TB Schreibvorgänge pro Tag. Das größere Laufwerk mit niedrigerem DWPD ist oft die bessere Wahl -- typischerweise günstiger und besser verfügbar, mit zusätzlichem Kapazitätsspielraum als Bonus. {% endhint %} ## Speicherknoten Speicherknoten nehmen am vSAN teil und stellen Festplattenkapazität für den gemeinsamen Speicherpool bereit. In einer HCI-Bereitstellung führen Speicherknoten auch Workloads aus. In einer UCI-Bereitstellung können sie ausschließlich für den Speicher reserviert sein. ### Mindest-Spezifikationen | Komponente | Spezifikation | Hinweise | | -------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CPU** | 2,7 GHz+ | Verarbeitet vSAN-I/O | | **RAM** | 16 GB + 1 GB pro 1 TB Rohspeicher | Pro Knoten; skaliert mit der Festplattenkapazität | | **Primärspeicher** | 1 x Enterprise-NVMe- oder SAS/SATA-SSD pro Knoten | Für Workload-I/O (primäre Speicherebene) | | **Kapazitäts-/Archiv-Ebene (Tier 4+)** | Enterprise-HDDs (optional) | Für Snapshots, Archive oder dateibasierte Dienste. VergeOS betreibt kein automatisches Tiering (keine automatische Datenverschiebung), aber ein Administrator kann die bevorzugte Ebene eines Volumes oder einer Datei ändern, wodurch eine nicht störende Hintergrundmigration ausgelöst wird | | **Redundanz** | Mindestens 2 Knoten mit übereinstimmender Festplattenkonfiguration | Erforderlich für vSAN-Datenredundanz | ### Empfohlene Spezifikationen | Komponente | Spezifikation | Hinweise | | ------------------ | ------------------------------------------------------------------ | ---------------------------------------------------------------- | | **CPU** | 3,0 GHz+, 1 Kern pro Festplatte | Ein dedizierter Kern pro Festplatte verbessert den I/O-Durchsatz | | **RAM** | 1,5 GB pro 1 TB Speicher pro Knoten | Bessere Leistung unter hoher Last | | **Primärspeicher** | 2+ NVMe- oder SAS/SATA-SSDs pro Knoten | Mehr Spindeln = mehr IOPS | | **Redundanz** | Mindestens 2 Knoten mit übereinstimmender Festplattenkonfiguration | Erforderlich für vSAN-Datenredundanz | ### Beispiel für RAM-Dimensionierung Zur Veranschaulichung der RAM-Berechnung für einen Speicherknoten: ``` VergeOS-Basisanforderung: 16 GB Speicher-Overhead (8 TB roh x 1 GB): 8 GB Workload-VMs (Beispiel): 96 GB ───────────────────────────────────────── Gesamter RAM pro Knoten: 120 GB ``` Beim empfohlenen Verhältnis von 1,5 GB/TB läge der Speicher-Overhead bei 12 GB statt 8 GB, womit sich insgesamt 124 GB ergeben würden. {% hint style="info" %} **Das Ziel für den maximalen RAM-Anteil (standardmäßig 80 %) berücksichtigen** VergeOS zielt darauf ab, unter normalen Bedingungen nicht mehr als **80 % des physischen RAM** pro Knoten zu verwenden (die `Ziel-Max-RAM %-` Cluster-Einstellung), sodass ein Puffer bleibt, auf den Failover und Live-Migration zugreifen können. Dimensionieren Sie den physischen RAM so, dass der Overhead **plus** Workloads innerhalb dieser 80 % bleiben. Im obigen Beispiel sollten etwa 120 GB normale Auslastung auf einem Knoten mit mindestens etwa 150 GB physischem RAM (120 ÷ 0,80) landen, um innerhalb des Ziels zu bleiben. {% endhint %} ## Nur-Rechen-Knoten Compute-only-Knoten führen Workloads aus, nehmen aber **nicht** nicht am vSAN teil. Sie haben keine lokalen Speicheranforderungen außer einem Boot-Gerät (oder können per PXE booten). Damit sind sie ideal, um CPU und RAM unabhängig vom Speicher in UCI- und HCI+-Compute-Architekturen zu skalieren. | Komponente | Spezifikation | | ------------ | ----------------------------------------------------------------------- | | **CPU** | Dimensioniert für Workload-Anforderungen | | **RAM** | Dimensioniert für Workload-Anforderungen (mindestens 16 GB für VergeOS) | | **Speicher** | Nur Boot-Gerät (oder PXE-Boot) -- keine vSAN-Festplatten | | **Netzwerk** | Die gleichen allgemeinen NIC-Anforderungen wie für alle Knoten | Compute-only-Knoten sind am einfachsten zu dimensionieren: Bestimmen Sie den gesamten CPU- und RAM-Bedarf Ihrer Workloads, teilen Sie ihn durch die Kapazität pro Knoten und runden Sie auf, um N+1-Verfügbarkeit zu gewährleisten. ## Empfehlungen für das Networking Die minimale Netzwerkkonfiguration (1 GbE extern + 1 x 10 GbE Core) eignet sich für kleine Bereitstellungen oder Proof-of-Concepts. Für Produktionsumgebungen befolgen Sie diese Empfehlungen: ### Core-Fabric-NICs **2 x 25/40/100 GbE** (Intel, NVIDIA Mellanox oder Broadcom). Zwei NICs bieten Redundanz für die Core Fabric -- das Hochgeschwindigkeits-Mesh, das vSAN-Replikation, VM-Migration und Inter-Node-Traffic transportiert. Jumbo Frames sind in der Core Fabric erforderlich: VergeOS setzt die Node-NICs auf etwa 9192, und die angeschlossenen Switch-Ports müssen auf ≥9216 konfiguriert werden, damit diese Frames ohne Fragmentierung durchgehen. ### Externe NICs **2 x 10/25/40/100 GbE** (Intel, NVIDIA Mellanox oder Broadcom). Zwei externe NICs unterstützen Bonding für Redundanz und Bandbreite zum Upstream-Netzwerk. Darüber laufen der Zugriff auf die Verwaltungsoberfläche und der externe Verkehr der Mandanten. ### Unterstützte NIC-Hersteller VergeOS unterstützt Netzwerkadapter von drei Herstellern: * **Intel** -- Breite Kompatibilität über verschiedene Serien hinweg * **NVIDIA Mellanox** -- Hochleistungs-ConnectX-Serie * **Broadcom** -- NICs für den Enterprise-Einsatz {% hint style="warning" %} Netzwerkadapter für Endverbraucher oder No-Name-Adapter werden nicht unterstützt. Die Verwendung nicht unterstützter NICs kann zu Treiberkompatibilitätsproblemen, schlechter Leistung oder Systeminstabilität führen. {% endhint %} ## Maximal unterstützte Spezifikationen Die folgende Tabelle zeigt die maximal unterstützten Hardwarespezifikationen ab VergeOS-Version 4.12: | Ressource | Maximum | Hinweise | | --------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------- | | **Knoten pro System** | 200 | Über alle Cluster hinweg | | **Einzelne physische Festplattengröße** | 64 TB | Pro physischem Laufwerk | | **RAM pro Host** | 5 TB | vSAN-Knoten benötigen 1 GB RAM pro 1 TB Speicher | | **vDisk-Größe** | 256 TB | Pro virtuellem Datenträger | | **Festplatten pro VM** | 2,000 | Erfordert Virtio-SCSI-Schnittstelle | | **Cluster pro System** | 100 | Mischung aus Compute-, Speicher- und HCI-Clustern | | **Speicher-Ebenen pro System** | 5 | 5 Workload-Ebenen (Tier 1 Hochleistung bis Tier 5 Archiv); Tier-0-Metadaten sind separat und nur für das System | | **vSAN-Fehlerdomänen pro System** | 2 | Bietet Datenredundanz | Diese Grenzen sind für Bereitstellungen in extrem großem Maßstab ausgelegt. Die meisten Produktionsumgebungen bleiben weit innerhalb dieser Grenzen. ## Warnungen und Hinweise zum Speicher ### Laufwerke für Endverbraucher {% hint style="danger" %} **Laufwerke für Endverbraucher nicht unterstützt** VergeOS **nicht** unterstützt offiziell keine Laufwerke für Endverbraucher. In Produktionsumgebungen und bei Backups produktiver Daten sollten nur Speichergeräte in Enterprise-Qualität verwendet werden. Laufwerke für Endverbraucher können in Test-, Entwicklungs- oder Proof-of-Concept-Umgebungen akzeptabel sein, in denen Datenverlust tolerierbar ist. Einige Geräte für Endverbraucher funktionieren aufgrund von Firmware-Einschränkungen, nicht standardmäßiger Befehlsimplementierungen oder Kompatibilitätsproblemen mit VergeOS möglicherweise nicht ordnungsgemäß. {% endhint %} ### Hinweise zu großen HDDs HDDs größer als **8 TB** werden außerhalb archivspezifischer Umgebungen nicht empfohlen. Das Problem ist die **Wiederherstellungszeit**. vSAN baut nicht automatisch wieder auf, wenn ein Laufwerk ausfällt -- ein Bediener startet eine Reparatur, die die verlorenen Daten auf ein Hot-Spare- oder Ersatzlaufwerk zurückschreibt. Bei einem Laufwerk mit 8 TB+ kann dieser Wiederaufbau viele Stunden -- oft Tage -- dauern, währenddessen: * **Die Systemleistung ist beeinträchtigt** da Wiederaufbau-I/O mit produktiven Workloads konkurriert * **Das Verfügbarkeitsrisiko steigt** weil ein zweiter Laufwerksausfall während des Wiederaufbaus zu Datenverlust führen könnte * **Das Wiederaufbau-Fenster wächst** proportional zur Laufwerksgröße Für primäre Workload-Ebenen sollten kleinere, schnellere SSDs bevorzugt werden. Große HDDs sollten für Aufbewahrung von Snapshots, Archivspeicher oder dateibasierte Dienstebenen reserviert werden, bei denen die Wiederherstellungszeit ein akzeptabler Kompromiss ist. ### Fibre-Channel-LUNs als Speicher VergeOS vSAN kann auch **Fibre-Channel-(FC)-LUNs** als Speichergeräte innerhalb seiner Ebenen nutzen, was hilfreich ist, um bestehende SAN-Investitionen zu integrieren. VergeOS behandelt jede FC-LUN wie eine lokale physische Festplatte, sodass native Redundanz und Deduplizierung weiterhin gelten. Wichtige Anforderungen: * Bereitstellen **eindeutige LUNs pro Knoten** — dieselbe LUN niemals über mehrere Knoten hinweg gemeinsam nutzen * FC-HBAs in mindestens zwei Knoten; ein redundantes FC-Fabric wird empfohlen * **RAID und Auto-Tiering auf dem SAN deaktivieren** — VergeOS übernimmt die Redundanz nativ * Behalten Sie **Tier-0-Metadaten auf direkt angeschlossenem NVMe** — externer Speicher wird für Tier 0 nicht empfohlen Verge.io empfiehlt weiterhin direkt angeschlossene Festplatten für beste Leistung und Einfachheit; verwenden Sie FC-LUNs vor allem dann, wenn Sie eine bestehende SAN-Infrastruktur oder spezifische Compliance-Anforderungen haben. Siehe [Verwendung von Fibre-Channel-Speicher mit vSAN](/run-the-platform/de/speicher/fibre-channel.md) für Einrichtungsdetails. ## Dedizierte vs. geteilte Controller-Knoten Für Produktionsumgebungen empfiehlt VergeOS **dedizierte Controller-Knoten** -- Knoten, die nur die vSAN-Metadaten (Tier 0) und die Systemverwaltung übernehmen, ohne Gast-Workloads auszuführen oder zu den Workload-Speicherebenen beizutragen. ```mermaid graph LR subgraph shared["Geteilte Controller (klein / PoC)"] N1S["Knoten 1
Controller + Speicher + Compute"] N2S["Knoten 2
Controller + Speicher + Compute"] end subgraph dedicated["Dedizierte Controller (Produktion)"] N1D["Knoten 1
Nur Controller
(Tier-0-Metadaten)"] N2D["Knoten 2
Nur Controller
(Tier-0-Metadaten)"] N3["Knoten 3+
Speicher + Compute"] N4["Knoten 4+
Speicher + Compute"] end style shared fill:#fef3c7,stroke:#d97706 style dedicated fill:#d1fae5,stroke:#059669 ``` | Ansatz | Wann verwenden | Abwägung | | ------------------------- | ------------------------------- | ----------------------------------------------------------------------------- | | **Geteilte Controller** | 2-Knoten-Cluster, PoC, Dev/Test | Weniger Knoten, aber Metadaten-I/O konkurriert mit Workloads | | **Dedizierte Controller** | Produktion, 4+ Knoten | Zusätzliche Knoten, aber Metadaten-Operationen sind isoliert und vorhersehbar | ## Schnellreferenz für die Dimensionierung Verwenden Sie diese Schnellreferenzkarte, wenn Sie eine neue Bereitstellung planen: | Frage | Empfehlung | | --------------------------------------- | -------------------------------------------------------------------------- | | Wie viel RAM pro Speicherknoten? | 16 GB Basis + 1 GB pro 1 TB roh (Minimum) oder 1,5 GB pro 1 TB (empfohlen) | | Wie viele Tier-0-Laufwerke? | 1 pro Controller (Minimum), 2 pro Controller (empfohlen) | | Wie groß sollte Tier 0 sein? | 5 GB pro 1 TB nutzbar (Minimum), 10 GB pro 1 TB nutzbar (empfohlen) | | Welcher DWPD-Wert für Tier 0? | 3 DWPD oder gleichwertig (Enterprise-NVMe) | | Wie viele Kerne pro Speicherfestplatte? | 1 Kern pro Festplatte (empfohlen) | | Mindestanzahl an Knoten für vSAN? | 2 Knoten mit übereinstimmender Festplattenkonfiguration | | Maximale Knoten pro System? | 200 | | NIC-Geschwindigkeit der Core Fabric? | Mindestens 10 GbE; 25/100 GbE empfohlen | ## Nächste Schritte Jetzt, da Sie die Hardwareanforderungen für jede Knotenrolle verstanden haben, fahren Sie fort mit: * [**Referenzarchitekturen**](/learn-the-platform/de/modul-2-dimensionierung-and-design/02-reference-architectures.md) -- Sehen Sie, wie diese Anforderungen auf reale Bereitstellungs-Topologien (HCI, HCI+Compute, UCI) abgebildet werden * [**Kunden-Scoping**](/learn-the-platform/de/modul-2-dimensionierung-and-design/03-customer-scoping.md) -- Lernen Sie die Methodik, um Kunden-Workloads in Hardwarespezifikationen zu übersetzen --- # 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/01-hardware-requirements.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.