> 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/plan-and-deploy/de/implementierungsleitfaden/sizing.md).

# Node-Dimensionierung

Basis-Hardwareprofile für VergeOS-Knoten. Verwenden Sie diese Empfehlungen, um Standard-Production-, Small/Edge- und Backup-Bereitstellungen zu planen. Wenden Sie sich für Performance- oder groß angelegte Designs an den Vertrieb oder einen Partner.

Verwenden Sie diesen Leitfaden, um die Hardware für eine VergeOS-Bereitstellung zu planen.

Die folgenden Profile sind **empfohlene Basiswerte**, keine harten Mindestwerte. Beginnen Sie mit dem Profil, das zu Ihrer Bereitstellung passt. Passen Sie es dann an Workload-Dichte, Snapshot-Zeitplan und Aufbewahrung, Wartungsfenster und Wachstum an.

{% hint style="info" %}
**Ressourcen der Workloads**

Die Werte in diesem Leitfaden decken den Betrieb des VergeOS-Systems ab. Reservieren Sie zusätzlichen CPU-, RAM- und Speicherplatz für virtuelle Maschinen, Anwendungen, Spitzenlast und Wachstum.
{% endhint %}

## Auswahl des Bereitstellungsmodells

Verwenden Sie diese Tabelle, um das richtige Profil zur Dimensionierung von Knoten auszuwählen. Diese Modelle sind als grobe Orientierung und nicht als starre Vorgaben gedacht. Wählen Sie das Modell, das zu Ihrer Umgebung passt, und passen Sie es dann an Ihre spezifischen Anforderungen an.

| Bereitstellungsmodell                                                          | Typische Anwendungsfälle                                                       | Wesentliche Merkmale                                                                          | Wann auswählen                                                                                                                     |
| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| [**Standard-Produktivbetrieb**](#standard-production)                          | Gemischte Workloads, mittelgroße Datenbanken, allgemeine Geschäftsanwendungen  | Ausgewogene CPU/RAM, vorhersagbare Leistung, vollständige Redundanz                           | Allzweckbereitstellungen, die eine unkomplizierte Skalierung und vorhersagbare Leistung für Line-of-Business-Anwendungen benötigen |
| [**Backup**](#backup-nodes)                                                    | Archivaufbewahrung, synchronisierte Backups                                    | Speichermedien mit geringerer Haltbarkeit sind akzeptabel, Tier 0 nur auf Controller-Knoten   | Wenn Knoten Backup-Daten und keine Produktiv-Workloads speichern                                                                   |
| [**Klein / Edge**](#small-edge)                                                | Einzelhandel, abgelegene Standorte, Sensoren, leichte Analytik                 | 1–2 Knoten, einfach, geringe Dichte, oft kein dediziertes Tier 0                              | Wenn Einfachheit und geringer Platzbedarf wichtiger sind als Leistung                                                              |
| [**Einzelknoten**](#single-node-systems)                                       | Kleine Standorte, Labore, Testumgebungen                                       | Kein Core Fabric, Metadaten auf der Primärstufe                                               | Wenn Redundanz nicht erforderlich ist                                                                                              |
| [**Leistung / hohe Kapazität / Skalierung**](#performance-high-capacity-scale) | Datenbanken mit hoher IOPS-Zahl, GPU-Analytik, große VDI, Multi-Tenant-Hosting | CPUs mit hoher Grundtaktfrequenz, große RAM-Puffer, Tier 0 mit hoher Haltbarkeit, NVMe-lastig | Wenn Leistung oder Skalierung die primäre Anforderung ist                                                                          |

## So verwenden Sie diesen Leitfaden

1. [Allgemeine Knotenanforderungen anwenden](#generic-node-requirements) — CPU, RAM, NICs, Laufwerkstyp, Haltbarkeit
2. [Ihr Bereitstellungsmodell identifizieren](#deployment-model-selection) — verwenden Sie die obige Tabelle, um Ihr Profil auszuwählen
3. [Tier 0 dimensionieren (Metadaten)](#tier-0-metadata-sizing) — basierend auf der nutzbaren Tier-1- bis Tier-5-Kapazität und der Snapshot-Aufbewahrung
4. [CPU und RAM für Workloads hinzufügen](#ram-for-storage) — VergeOS-Systemanforderungen plus Ressourcen der Gast-Workloads

Die meisten Standard-Produktivsysteme laufen als ein HCI-Cluster. Die Clusteranzahl ist ein kurzer Anhaltspunkt für das Bereitstellungsmodell:

* **1 Cluster:** HCI. Controller-, Speicher- und Compute-Rollen können dieselben Knoten nutzen.
* **2 Cluster:** hybrides UCI/HCI.
* **3 oder mehr Cluster:** vollständiges UCI.

Zu HCI- und UCI-Modellen, Knotentypen und wann Rollen getrennt werden sollten, siehe [HCI vs. UCI: Bereitstellungsmodelle](/learn-the-platform/de/modul-1-architekturgrundlagen/02-hci-vs-uci.md) und [Cluster & Knotentypen](/learn-the-platform/de/modul-1-architekturgrundlagen/05-clusters-nodes.md) in Learn the Platform.

{% hint style="info" %}
**HCI ist der Standard**

Dedizierte Controller-, Speicher-only- oder Compute-only-Knoten sind optionale Designentscheidungen, keine Voraussetzung für jede Bereitstellung.
{% endhint %}

VergeOS-Vertrieb, Support und autorisierte Wiederverkäufer können bei der Workload-Analyse und Hardwareauswahl helfen. Siehe [Kontakt zu Verge.io](https://www.verge.io/contact/).

## Allgemeine Knotenanforderungen

Diese Mindestwerte gelten für alle Knotentypen und Profile:

* AMD- oder Intel-x86\_64-Prozessor mit Hardwarevirtualisierung
* Mindestwert **16 GB RAM** für VergeOS reserviert
* IPMI, iDRAC, iLO oder gleichwertiges Out-of-Band-Management
* HBA- oder RAID-Controller in **JBOD- oder IT-Modus** (kein RAID); NVMe-Direktanbindung bevorzugt
* **1 × 1 GbE** NIC für das externe Netzwerk (Intel, NVIDIA Mellanox oder Broadcom)
* **1 × 10 GbE** NIC für das Core-Fabric-Netzwerk (Intel, NVIDIA Mellanox oder Broadcom; bei Einzelknoten-Bereitstellungen nicht erforderlich)

{% hint style="info" %}
**Referenz für Hardwaretreiber**

VergeOS enthält als Teil der Plattform eine breite Auswahl an Netzwerk- und Speichertreibern. Wenn Sie eine Bereitstellung planen und den Treiberbestand prüfen möchten, siehe:

* [Enthaltene Ethernet-Treiber](/plan-and-deploy/de/implementierungsleitfaden/sizing/nic-driver-list.md)
* [Enthaltene Speichertreiber](/plan-and-deploy/de/implementierungsleitfaden/sizing/storage-driver-list.md)

Wenn Sie die geplante Hardware nicht sehen, wenden Sie sich an **VergeOS-Vertrieb** für Unterstützung.
{% endhint %}

Zum Design von Core-Fabric- und externem Netzwerk siehe [Netzwerkdesign](/plan-and-deploy/de/implementierungsleitfaden/network-design.md).

### Hinweise zu Laufwerken und Haltbarkeit

Lesen Sie diese Hinweise, bevor Sie Laufwerke für ein Profil auswählen.

{% hint style="danger" %}
**Nur Enterprise-Laufwerke (Produktion)**

VergeOS unterstützt in Produktion oder in Backup-von-Produktion-Systemen offiziell keine Laufwerke für Endverbraucher. Verwenden Sie Geräte der Enterprise-Klasse. Laufwerke für Endverbraucher können für Tests, Entwicklung oder Proof of Concept akzeptabel sein, wenn Datenverlust tolerierbar ist. Einige Consumer-Geräte scheitern aufgrund von Firmware-Limits oder nicht standardkonformen Befehlen.
{% endhint %}

{% hint style="warning" %}
**Nur-Boot-Geräte (einschließlich Dell BOSS)**

Boot-orientierte Geräte wie Dell-BOSS-Karten sind nur für **Boot oder OS**gedacht. Weisen Sie sie nicht den Speicherebenen 0–5 zu. Wählen Sie sie für VergeOS als Nur-Boot-Geräte aus. Diese Geräte verfügen nicht über die Schreibhaltbarkeit und den Schreibpuffer, die Tier 0 und die Workload-Ebenen benötigen.
{% endhint %}

* **Tier 0:** Verwenden Sie ausschließlich Enterprise-Medien. Verwenden Sie kein Consumer-NVMe. Zu Anforderungen an Haltbarkeit und Kapazität siehe [Dimensionierung von Tier 0 (Metadaten)](#tier-0-metadata-sizing).
* **Produktiv-Workload-Ebenen (Tier 1–5):** Verwenden Sie ausschließlich Enterprise-Medien. Verwenden Sie kein Consumer-NVMe. Für schreiborientierte oder Allzweck-Medien verwenden Sie mindestens **1 Drive-Write pro Tag (DWPD)**. Sie können lesefokussierte Enterprise-Medien verwenden, wenn diese zum Workload passen.
* HDDs größer als **8 TB** werden außerhalb archivspezifischer Umgebungen nicht empfohlen. Große HDDs verlängern die Wiederherstellungszeit und können Leistung und Verfügbarkeit beeinträchtigen.

### Dimensionierung von Tier 0 (Metadaten)

Tier 0 hält vSAN-Metadaten: die Strukturdaten, die VergeOS verwendet, um nutzbare Daten zu verfolgen. Eine korrekte Dimensionierung von Tier 0 ist für einen stabilen vSAN-Betrieb in jedem Bereitstellungsprofil entscheidend. Der Metadatenbedarf variiert je nach Workload-Verhalten, Snapshot-Strategie und vSAN-Skalierung. Siehe [Speicherebenen in VergeOS vSAN](/run-the-platform/de/speicher/storage-tiers.md).

**Wo Metadaten gespeichert werden:** Die meisten Bereitstellungen speichern Metadaten auf einem dedizierten Tier 0. Kleine/Edge-Systeme [können Metadaten stattdessen auf der Primärstufe speichern](#small-edge). Es gilt dieselbe Dimensionierungsrichtlinie; reservieren Sie die erforderliche Metadatenkapazität innerhalb der Primärstufe.

#### Grundanforderungen an Tier 0

* **Medien:** Enterprise-SSD. Tier 0 muss nicht NVMe sein — Enterprise-SAS-SSD ist akzeptabel, wenn sie die unten genannten Anforderungen an Haltbarkeit und Kapazität erfüllt.
* **Mindesthaltbarkeit:** 1 DWPD
* **Kapazität:** etwa **5 GB nutzbares Tier 0 pro 1 TB nutzbarer Tier-1- bis Tier-5-Kapazität** bei 3 DWPD, oder ein entsprechendes Kapazitäts- und Haltbarkeitsprofil (zum Beispiel 15 GB pro 1 TB bei 1 DWPD)

Beide Seiten dieses Verhältnisses sind **systemweit nutzbare Kapazität**, gemessen nach Redundanz. Kopien von Metadaten — über Controller-Knoten und über lokale Laufwerke innerhalb eines Knotens hinweg — sind Redundanz, keine zusätzliche nutzbare Kapazität: Nutzbares Tier 0 ist rohes Tier 0 geteilt durch die Anzahl der lokalen Kopien. Siehe [Lokale Tier-0-Metadaten-Redundanz des Knotens (D+x)](/run-the-platform/de/speicher/tier0-local-redundancy.md).

Die Gleichwertigkeit tauscht Kapazität gegen Haltbarkeit: Metadaten belegen in beiden Fällen etwa 5 GB pro 1 TB. Bei Medien mit 1 DWPD ist die zusätzliche Kapazität also Puffer für die Haltbarkeit, nicht zusätzlicher Metadatenplatz. Ziehen Sie genügend Kapazität bei 1 DWPD vor, statt 3 DWPD anzustreben, wenn Enterprise-Medien mit 1 DWPD den Bedarf decken.

Diese Basisannahme geht vom Standardprofil [*System-Snapshots* aus](/automate-protect-and-extend/de/sicherung-und-dr/snapshot-profiles.md) oder einem ähnlichen Zeitplan aus. Dieses Profil behält **7 Snapshots** gleichzeitig: 3 stündliche, 3 tägliche (Mitternacht) und 1 täglicher (Mittag). Wenn Sie Ihre eigenen aufbewahrten Snapshots zählen, beziehen Sie VM- und Volume-Snapshot-Profile ebenso ein wie das Systemprofil.

#### Wann die Tier-0-Kapazität erhöht werden sollte

**Erhöhte Snapshot-Aufbewahrung**

Das Verhalten von Snapshots ist ein wesentlicher Treiber des Metadatenwachstums. Jeder aufbewahrte Snapshot kann bis zu etwa **0,5 GB pro 1 TB nutzbarer Tier-1- bis Tier-5-Kapazität** hinzufügen (eine Obergrenze). Die tatsächliche Nutzung hängt vom Snapshot-Delta ab: Schreibintensive Workloads wie starkes SQL oder zufällige Schreibmuster nähern sich der Obergrenze an, während sequenzielle oder wenig veränderliche Workloads weniger Metadaten pro Snapshot nutzen.

Die konservative Basis deckt eine moderate Aufbewahrung über das Standardprofil hinaus ab. Für die meisten Systeme mit einer **niedrigen bis moderaten Änderungsrate**kann die Basis (5 GB/TB) etwa **25–30 Snapshots**aufnehmen. Dies bestätigt die Telemetrie des Bestands: Das 75. Perzentil bei 25 Snapshots liegt bei etwa 4,7 GB/TB, also genau an der Basis. Systeme mit **moderater bis hoher Änderungsrate** (zum Beispiel dichte SQL-Datenbanknutzung, High-Frequency-Trading-Systeme, SPSen) sollten auf etwa **10 GB nutzbares Tier 0 pro 1 TB nutzbarer Tier-1- bis Tier-5-Kapazität** erhöhen, wenn 25–30 Snapshots aufbewahrt werden.

**Tier-0-Dimensionierungsbeispiele**

| Änderungsrate       | Aufbewahrte Snapshots | Tier-0-Dimensionierung | Hinweise                                                                                  |
| ------------------- | --------------------- | ---------------------- | ----------------------------------------------------------------------------------------- |
| Niedrig bis moderat | 7 (Standard)          | 5 GB/TB (Basis)        | Die Basis nimmt die standardmäßigen 7 Snapshots sicher auf                                |
| Niedrig bis moderat | 25–30                 | 5 GB/TB (Basis)        | 25–30 Snapshots können weiterhin aufgenommen werden                                       |
| Moderat bis hoch    | 7 (Standard)          | 5 GB/TB (Basis)        | Die Basis nimmt die standardmäßigen 7 Snapshots sicher auf                                |
| Moderat bis hoch    | 25–30                 | 10 GB/TB               | Höhere Richtlinie für erhöhte Snapshot-Aufbewahrung bei moderater bis hoher Änderungsrate |

Wenn Sie planen, mehr als etwa 25–30 Snapshots aufzubewahren oder Workloads über diese Tabelle hinaus zu betreiben, wenden Sie sich für Unterstützung an den VergeOS-Vertrieb oder einen autorisierten Wiederverkäuferpartner. Siehe [Kontakt zu Verge.io](https://www.verge.io/contact/).

**Geplante vSAN-Kapazitätserweiterung**

Dimensionieren Sie Tier 0 für die gesamte nutzbare vSAN-Kapazität. Wenn Sie eine baldige Skalierung erwarten (Hinzufügen von Speicherknoten oder Erweiterung von Tier 1–5), vergrößern Sie Tier 0 im Voraus, um den späteren Austausch von Metadatengeräten zu vermeiden.

Um Tier 0 nach der Installation hinzuzufügen, siehe [Tier 0 zu einem bestehenden System hinzufügen](/knowledge-base/de/storage-vsan/adding-tier-zero.md).

Die Dimensionierung von Metadaten hängt von mehreren voneinander abhängigen Faktoren ab. VergeOS-Vertrieb und autorisierte Wiederverkäuferpartner können bei der Workload-Bewertung und Tier-0-Planung für neue Bereitstellungen und Erweiterungen helfen. Siehe [Kontakt zu Verge.io](https://www.verge.io/contact/).

### RAM für Speicher

* **Basis:** reservieren Sie auf jedem Knoten **16 GB für VergeOS plus 1 GB RAM pro 1 TB Rohspeicher** auf diesem Knoten. RAM für Gast-Workloads kommt zusätzlich hinzu. Ein Knoten mit 8 TB Rohkapazität reserviert zum Beispiel 24 GB vor dem Gast-RAM.
* **RAM für den Speicherpuffer (Cache)** ist ein separater, zusätzlicher Bedarf. Er ist vor allem in leistungsorientierten Umgebungen wichtig. Betrachten Sie einen einzelnen höheren GB/TB-Wert nicht als Ersatz für beide Anforderungen. Für die Dimensionierung von [Leistungs-](#performance-high-capacity-scale) Bereitstellungsmodell-Knoten und ihren Speicherpuffer wenden Sie sich an einen VergeOS-Partner oder das VergeOS-Vertriebsteam.

### CPU und Speicherdatenträger

Für die Profile Standard-Produktivbetrieb und Backup planen Sie **1 physischen Kern pro Speicherdatenträger** auf jedem Knoten, der vSAN-Laufwerke beiträgt. Zählen Sie Tier-0-Geräte als Speicherdatenträger. Zählen Sie das Boot-Laufwerk nicht mit und zählen Sie Hardware-Threads nicht als zusätzliche Kerne.

## Bereitstellungsprofile

### Standard-Produktivbetrieb

Ausgewogene Allzweckbereitstellungen für gemischte Workloads mit vorhersagbarer Leistung, moderater VM-Dichte, voller Redundanz und unkomplizierter Skalierung.

**Typischerweise geeignet für:** Line-of-Business-Anwendungen, mittelgroße Datenbanken, leichte KI/ML-Workloads.

**Beispielanwendungsfälle:**

* Fertigungsunternehmen, das ERP, SQL, Dateidienste und einen kleinen VDI-Pool betreibt
* Beratungsunternehmen, das Windows-Server-Workloads, SQL-Datenbanken, Dokumentenmanagement und saisonale Anwendungen mit hoher Last betreibt

#### Rollenflexibilität

VergeOS unterstützt ein flexibles Design der Knotenrollen. Die folgenden Anforderungen beschreiben die funktionalen Bedürfnisse der Controller-, Speicher- und Compute-Rollen; diese Rollen können je nach verfügbarer Hardware, Workload-Dichte und Bereitstellungsumfang auf denselben physischen Knoten kombiniert werden. Die meisten Standard-Produktivsysteme verwenden Knoten, die sowohl als Controller als auch als Speicherteilnehmer dienen, und kleinere Umgebungen können Controller-, Speicher- und Compute-Workloads auf denselben Knoten ausführen. Zum Design der Knotenrollen siehe [Cluster & Knotentypen](/learn-the-platform/de/modul-1-architekturgrundlagen/05-clusters-nodes.md).

Die allgemeine NIC-Liste ist ein Mindestwert. Produktionssysteme verwenden zwei Core-Fabric-Netzwerke mit redundanten Verbindungen, typischerweise 4 × 10/25/40/100-GbE-Ports pro Knoten. Siehe [Netzwerkdesign](/plan-and-deploy/de/implementierungsleitfaden/network-design.md).

#### Controller-Rolle (Knoten 1 und 2; plus Knoten 3 in einem N+2-Design)

Knoten, die die Controller-Rolle erfüllen, können je nach Bereitstellungsdesign auch an Speicherung teilnehmen und Workloads ausführen. Zu den Anforderungen für N+1 und N+2 siehe [vSAN-Redundanzstufen verstehen](/run-the-platform/de/speicher/vsan-redundancy-levels.md).

* **Prozessor:** CPU mit 2,7 GHz+ (Grundtakt)
* **RAM:** 16 GB + 1 GB pro 1 TB Rohspeicher pro Knoten, plus RAM für Gast-Workloads (siehe [RAM für Speicher](#ram-for-storage))
* **Tier 0 (Metadatenspeicher):**
  * Enterprise-SSD mit hoher Haltbarkeit (NVMe oder gleichwertig), die 5 GB nutzbares Tier 0 pro 1 TB nutzbarer Tier-1- bis Tier-5-Kapazität bei 3 DWPD oder ein entsprechendes Haltbarkeitsprofil bietet (zum Beispiel 15 GB pro 1 TB bei 1 DWPD)
  * Mindestzulässige Haltbarkeit: 1 DWPD

{% hint style="info" %}
**Kapazitätsaspekte**

* Wenn ein Knoten mehr als ein Tier-0-Laufwerk hat, spiegelt VergeOS Metadaten automatisch über die lokalen Laufwerke hinweg, um die System-Redundanzstufe zu erreichen (zwei Kopien bei N+1, drei bei N+2), bis zur Anzahl der Laufwerke. Die nutzbare Tier-0-Kapazität ist die gesamte rohe Tier-0-Kapazität geteilt durch die Anzahl der lokalen Kopien; Laufwerke über die erforderliche Kopienanzahl hinaus erhöhen die nutzbare Kapazität. Einzelheiten siehe [Lokale Tier-0-Metadaten-Redundanz des Knotens (D+x)](/run-the-platform/de/speicher/tier0-local-redundancy.md).
* Installieren Sie zwei Tier-0-Laufwerke pro Controller-Knoten in einem N+1-System und drei in einem N+2-System, um vollständigen lokalen Schutz zu erhalten.
* Die Metadatkapazität muss für Umgebungen mit hohen Datenänderungsraten und/oder erweiterter Snapshot-Aufbewahrung erhöht werden; siehe [Dimensionierung von Tier 0 (Metadaten)](#tier-0-metadata-sizing).
  {% endhint %}

#### Speicherrolle (vSAN-Teilnehmer)

Knoten, die die Speicherrolle erfüllen, können auch als Controller dienen oder Compute-Workloads ausführen. Verwenden Sie mindestens zwei Knoten mit identischen Laufwerkskonfigurationen (außer [Einzelknotensysteme](#single-node-systems)).

* **Prozessor:** CPU mit 2,7 GHz+ (Grundtakt). Der Grundtakt beeinflusst auch die Speicherleistung auf Knoten, die Compute ausführen.
* **RAM:** 16 GB + 1 GB pro 1 TB Rohspeicher pro Knoten (siehe [RAM für Speicher](#ram-for-storage))
* **CPU:** 1 physischer Kern pro Speicherdatenträger (siehe [CPU und Speicherdatenträger](#cpu-and-storage-disks))
* **Speicher:**
  * Mindestens eine Enterprise-NVMe- oder SATA/SAS-SSD pro Knoten (Primärstufe)
  * Enterprise-HDDs sind für geringe Leistung, Snapshots, Archiv oder Dateidienste akzeptabel (siehe [Hinweise zu Laufwerken und Haltbarkeit](#disk-and-endurance-guidance))

#### Compute-Rolle

Nur-Compute-Knoten sind optional; Compute-Workloads können in kleineren oder konsolidierten Bereitstellungen auf Controller- oder Speicherknoten laufen.

* **Nur-Compute-Knoten:** befolgen die [allgemeinen Knotenanforderungen](#generic-node-requirements) und dimensionieren CPU und RAM für die darauf gehosteten Workloads. Der Grundtakt beeinflusst weiterhin die Latenz der Gastlaufwerke: Ein Nur-Compute-Knoten verarbeitet I/O auch dann, wenn die Laufwerke auf anderen Knoten liegen.
* **Kombinierte Rollen:** Wenn Compute-Workloads auf Knoten laufen, die auch Controller- oder Speicherrollen übernehmen, reservieren Sie ausreichende zusätzliche Ressourcen. Gast-Workloads benötigen ihre eigene CPU- und RAM-Kapazität, getrennt von dem, was VergeOS für Controller-Funktionen, Metadatenverwaltung und vSAN-Teilnahme benötigt. Dimensionieren Sie Knoten mit kombinierten Rollen mit zusätzlichem RAM für den Gast-Speicher und ausreichender CPU-Reserve, damit die Leistung sowohl für Systemdienste als auch für gehostete Workloads vorhersagbar bleibt.

***

### Leistung / hohe Kapazität / Skalierung

Verwenden Sie dieses Profil für Umgebungen mit hoher Dichte, hoher IOPS-Zahl, geringer Latenz, vielen Snapshots, dauerhaften Schreibmustern oder hohem East-West-Verkehr.

Flache GB-pro-TB-Verhältnisse, die für Standard-Produktivbetrieb funktionieren, skalieren in großen Leistungssystemen nicht linear. Snapshot-Zeitplan und -Aufbewahrung bestimmen den Metadatenbedarf. RAM für den Speicherpuffer ist eine separate zusätzliche Anforderung.

{% hint style="warning" %}
**Mit einem Partner oder dem Vertrieb entwerfen**

Wenden Sie sich an einen VergeOS-Partner oder das VergeOS-Vertriebsteam, um Ihre Leistungsumgebung zu entwerfen. Verwenden Sie veröffentlichte [Referenzarchitekturen](/plan-and-deploy/de/referenzarchitekturen/data-science.md) wo sie passen. Betrachten Sie die Verhältnisse für Standard-Produktivbetrieb nicht als lineare Richtwerte für sehr große NVMe-Systeme (zum Beispiel Dutzende Knoten im Petabyte-Bereich).
{% endhint %}

**Beispielanwendungsfälle:**

* Finanzdienstleister mit Transaktionsdatenbanken, großer VDI oder GPU-Analytik
* Regionale MSPs, die Multi-Tenant-Hosting und GPU-beschleunigte Workloads bereitstellen

Wenn ein Partner das System entwirft, gehören zu den typischen Bausteinen CPUs mit höherem Grundtakt, mehr RAM pro TB Rohspeicher plus explizit RAM für den Speicherpuffer, redundantes Tier 0 mit hoher Haltbarkeit, mehrere Enterprise-SSDs oder NVMe-Geräte pro Speicherknoten sowie 25/40/100-GbE-Fabrics. Die genauen Werte hängen von Workload und Größe ab.

Verwandte Seiten:

* [Hochleistungs-Clusterbereitstellungen](/plan-and-deploy/de/referenzarchitekturen/data-science.md)
* [Multi-Tenant-Bereitstellungen](/plan-and-deploy/de/referenzarchitekturen/csp.md)

***

### Klein / Edge

Zwei Knoten oder weniger. Kompakte Bereitstellungen, bei denen Einfachheit und geringer Betriebsaufwand im Vordergrund stehen. Geeignet für kleine Standorte, Einzelhandel, entfernte Einrichtungen und verteilte Edge-Umgebungen. Die Workloads sind moderat und nicht dicht.

**Beispiele:**

* Remote-Monitoring-Stationen, die Sensoren aufnehmen und leichte Analytik ausführen
* Einzelhandelsstandorte, die an eine zentrale oder regionale Niederlassung melden

#### Knotenanforderungen

* **Prozessor:** siehe [allgemeinen Knotenanforderungen](#generic-node-requirements)
* **RAM:** 16 GB + 1 GB pro 1 TB Rohspeicher pro Knoten (siehe [RAM für Speicher](#ram-for-storage))
* **Tier 0:** Planen Sie dennoch Tier 0 ein, wenn das Design dedizierte Metadatengeräte erfordert. Tier 0 muss nicht NVMe sein; Enterprise-SAS- oder NVMe-SSD ist akzeptabel.
* Auf **1–2-Knoten-** Systemen, bei denen die Primärstufe bereits vollständig aus NVMe oder SSD besteht, ist ein **dediziertes** Tier-0-Gerät oft nicht erforderlich. Metadaten liegen dann auf der Primärstufe; es gilt dieselbe Dimensionierungsrichtlinie, also reservieren Sie die erforderliche Metadatenkapazität innerhalb der Primärstufe (siehe [Dimensionierung von Tier 0 (Metadaten)](#tier-0-metadata-sizing)). Bestätigen Sie das Layout im Zweifelsfall mit Vertrieb, Support oder einem autorisierten Wiederverkäufer.
* **Netzwerk:** siehe [allgemeinen Knotenanforderungen](#generic-node-requirements)
* **Clustergröße:** mindestens 2 Knoten, sofern Sie kein [Einzelknotensystem](#single-node-systems)
* **Hinweis:** Nicht geeignet für leistungskritische Workloads

Ein Topologiebeispiel finden Sie unter [Edge-Cluster-Bereitstellungen](/plan-and-deploy/de/referenzarchitekturen/edge.md).

***

### Backup-Knoten

Speicherorientierte Knoten für Backup- oder Archivaufbewahrung.

**Beispiele:**

* Speicherknoten in einem Produktionscluster, die Enterprise-SSDs mit niedrigerem DWPD für Backup-Daten verwenden
* Knoten in einem separaten VergeOS-Backup-Cluster, die synchronisierte Backups empfangen

#### Knotenanforderungen

* **Prozessor:** siehe [allgemeinen Knotenanforderungen](#generic-node-requirements)
* **RAM:** 16 GB + 1 GB pro 1 TB Rohspeicher pro Knoten (siehe [RAM für Speicher](#ram-for-storage))
* **CPU:** 1 physischer Kern pro Speicherdatenträger (siehe [CPU und Speicherdatenträger](#cpu-and-storage-disks))
* **Tier 0:** Dimensionieren Sie Tier 0 auf den Controller-Knoten des Backup-Systems (Knoten 1 und 2). Backup-Systeme in diesem Profil laufen N+1, daher gibt es zwei Controller-Knoten. Fügen Sie nicht für jeden Backup-Speicherknoten dedizierte Tier-0-Geräte hinzu. Tier 0 muss nicht NVMe sein. Verwenden Sie Enterprise-SAS- oder NVMe-SSD; verwenden Sie keine Consumer-Geräte. Mindestzulässige Haltbarkeit: **1 DWPD**. Wenn Sie mehr Snapshots aufbewahren als im Standardprofil vorgesehen, kann dies zusätzlichen Metadatenverbrauch verursachen und eine höhere Tier-0-Kapazität erforderlich machen; siehe [Dimensionierung von Tier 0 (Metadaten)](#tier-0-metadata-sizing).
* **Netzwerk:** siehe [allgemeinen Knotenanforderungen](#generic-node-requirements)
* **Speicher:**
  * Speichermedien der Enterprise-Klasse mit geringerer Leistung und geringerer Haltbarkeit sind akzeptabel
  * HDDs größer als 8 TB können für archivspezifische Layouts verwendet werden; rechnen Sie mit längeren Wiederherstellungszeiten
* **Hinweis:** Nicht geeignet für leistungskritische Workloads

***

### Einzelknotensysteme

Einzelknotensysteme folgen dem **Klein / Edge** obigen Profil, mit einem Unterschied: Ein Einzelknotensystem hat keinen vSAN- oder Fabric-Verkehr von Knoten zu Knoten, daher **ist kein Core-Fabric-Netzwerk erforderlich**.

#### Knotenanforderungen

* **Prozessor:** siehe [allgemeinen Knotenanforderungen](#generic-node-requirements)
* **RAM:** 16 GB + 1 GB pro 1 TB Rohspeicher pro Knoten (siehe [RAM für Speicher](#ram-for-storage))
* **Tier 0:** gleiche Richtlinie wie bei Klein / Edge. Wenn die Primärstufe bereits vollständig aus NVMe oder SSD besteht, ist ein dediziertes Tier-0-Gerät oft nicht erforderlich; Metadaten liegen dann auf der Primärstufe, daher reservieren Sie dort die erforderliche Metadatenkapazität (siehe [Dimensionierung von Tier 0 (Metadaten)](#tier-0-metadata-sizing))
* **Netzwerk:** 1 × 1 GbE NIC für das externe Netzwerk; keine Core-Fabric-NIC erforderlich
* **Hinweis:** Ein einzelner Knoten bietet keine Redundanz auf Knotenebene. Redundanz entsteht durch Kopien über die lokalen Laufwerke des Knotens hinweg — siehe [Lokale Tier-0-Metadaten-Redundanz des Knotens (D+x)](/run-the-platform/de/speicher/tier0-local-redundancy.md). Schützen Sie Workloads mit Snapshots und Offsite-Synchronisation oder Backup.

***

## Skalierungsaspekte

VergeOS-Cluster skalieren horizontal. Fügen Sie Knoten hinzu, um Speicherplatz und Rechenleistung zu erhöhen. Siehe [Grundkonzepte](/plan-and-deploy/de/implementierungsleitfaden/concepts.md) für Knoten- und Clustertypen.

Wenn Sie die Controller-Kapazität planen:

* Dimensionieren Sie **Tier-0-Speicher und RAM** für den gesamten Clusterspeicher und für die Snapshot-Richtlinie.
* Mit zunehmender VM-Dichte benötigen Controller- und HCI-Knoten möglicherweise mehr CPU.

Wenn die Umgebung wächst, prüfen Sie das Hardwareprofil erneut. Ein Design, das für die erste Bereitstellung gepasst hat, kann nach größeren Kapazitäts- oder Workload-Zuwächsen falsch sein.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.verge.io/plan-and-deploy/de/implementierungsleitfaden/sizing.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
