> 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-1-architekturgrundlagen/02-hci-vs-uci.md).

# HCI vs. UCI: Bereitstellungsmodelle

## Zwei Wege, VergeOS bereitzustellen

VergeOS ist unter Infrastrukturplattformen einzigartig, weil es unterstützt **zwei unterschiedliche Bereitstellungsmodelle** aus derselben Software-Installation:

* **HCI (hyperkonvergierte Infrastruktur)** -- Rechenleistung und Speicher laufen auf jedem Knoten. Ressourcen skalieren gemeinsam.
* **UCI (ultrakonvergierte Infrastruktur)** -- Rechenleistung und Speicher laufen auf dedizierten, separaten Knotentypen. Ressourcen skalieren unabhängig.

Die meisten konkurrierenden Plattformen (VMware vSAN, Nutanix) unterstützen nur HCI. VergeOS bietet Ihnen beide Optionen -- und Sie können sie sogar innerhalb eines einzigen Systems kombinieren.

{% hint style="info" %}
**System vs. Cluster**

* **System** — die gesamte VergeOS-Bereitstellung, bestehend aus einem oder mehreren Clustern, die als eine Einheit verwaltet werden.
* **Cluster** — eine Gruppe von Knoten mit passender Hardware, die Rechenleistung und Hochverfügbarkeitsgrenzen gemeinsam nutzen. vSAN-Speicherebenen erstrecken sich über alle Cluster im System, sodass der Speicher systemweit gemeinsam genutzt wird, auch wenn Rechenleistung und HA pro Cluster abgegrenzt sind.
  {% endhint %}

## HCI: hyperkonvergierte Infrastruktur

In einer HCI-Bereitstellung trägt jeder Knoten im Cluster **sowohl** Speicherkapazität und Rechenressourcen bei. Wenn Sie von einem davon mehr benötigen, fügen Sie einen weiteren Knoten hinzu -- wodurch beides erweitert wird.

### Funktionsweise

Der häufigste Ausgangspunkt ist ein 2-Knoten-HCI-Cluster. Zwei Controller-Knoten bilden einen einzigen Cluster, der Speicher (vSAN) und Rechenleistung (VM-Workloads) verwaltet. Beide Knoten tragen Tier-0- und Workload-Tier-Datenträger zum gemeinsamen Speicherpool bei, und beide Knoten führen virtuelle Maschinen aus.

Zum Wachsen fügen Sie **Scale-out-Knoten** demselben Cluster hinzu. Jeder Scale-out-Knoten tritt per Netzwerkerkennung automatisch bei und stellt sofort zusätzliche Speicher- und Rechenkapazität bereit.

```mermaid
graph TB
    subgraph cluster1["Cluster 1 (HCI)"]
        N1["Knoten 1 — Controller<br/>Speicher + Compute"]
        N2["Knoten 2 — Controller<br/>Speicher + Compute"]
        S1["Scale-out-Knoten 3<br/>Speicher + Rechenleistung"]
        S2["Scale-out-Knoten 4<br/>Speicher + Rechenleistung"]
    end
    subgraph fabric["Core Fabric (gemeinsames L2)"]
        CF["Core Fabric 1 + 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    S2 --- CF
    EXT["Externes Netzwerk"] --- N1
    EXT --- N2
    EXT --- S1
    EXT --- S2

    style cluster1 fill:#e8f5e9,stroke:#2e7d32
    style fabric fill:#f0f4ff,stroke:#336
```

### Wann HCI wählen

| Szenario                                  | Warum HCI funktioniert                                                                |
| ----------------------------------------- | ------------------------------------------------------------------------------------- |
| **Kleine Bereitstellungen** (2--8 Knoten) | Minimale Komplexität, jeder Knoten übernimmt zwei Aufgaben                            |
| **Ausgewogene Workloads**                 | Wenn Speicher- und Rechenanforderungen ungefähr gleich schnell wachsen                |
| **Edge-/Remote-Standorte**                | 2-Knoten-Cluster mit vollständiger Hochverfügbarkeit und kleinem physischem Footprint |
| **Evaluation und Tests**                  | Schnellster Weg zu einem funktionsfähigen VergeOS-System                              |
| **Budgetbewusst**                         | Für kleine bis mittlere Workloads werden insgesamt weniger Knoten benötigt            |

### Wichtige Merkmale

* **Minimum**: 2 Knoten (Controller-Paar)
* **Skalierung**: Fügen Sie Scale-out-Knoten demselben Cluster hinzu
* **Knotenrollen**: Alle Knoten führen Speicher aus **und** Rechenleistung
* **Clusteranzahl**: 1
* **Einfachheit**: Am einfachsten bereitzustellen und zu verwalten

## UCI: ultrakonvergierte Infrastruktur

UCI ist der Oberbegriff für jede Bereitstellung, bei der Speicher und Rechenleistung unabhängig auf **dedizierten Knotentypen**. Die kanonische Form nutzt drei Cluster (Controller, Speicher, Rechenleistung); eine beliebte Hybridvariante fasst Controller + Speicher in zwei Cluster zusammen. In beiden Fällen skalieren Sie jede Ressourcenschicht unabhängig -- fügen Sie Speicherknoten hinzu, wenn Sie mehr Kapazität benötigen, oder Rechenknoten, wenn Sie mehr CPU und RAM brauchen, ohne beides kaufen zu müssen.

### Funktionsweise

Eine UCI-Bereitstellung beginnt mit demselben 2-Knoten-Controller-Paar, aber die Controller verwalten das System, ohne Produktions-Workloads auszuführen oder Benutzerdaten zu speichern. Dedizierte **Speicherknoten** bilden einen zweiten Cluster, der die gesamte vSAN-Kapazität bereitstellt. Dedizierte **Rechenknoten** bilden einen dritten Cluster, der alle VM-Workloads ausführt.

```mermaid
graph TB
    subgraph cluster1["Cluster 1 (Controller)"]
        N1["Knoten 1 — Controller"]
        N2["Knoten 2 — Controller"]
    end
    subgraph cluster2["Cluster 2 (Speicher)"]
        ST1["Speicherknoten 1"]
        ST2["Speicherknoten 2"]
    end
    subgraph cluster3["Cluster 3 (Rechenleistung)"]
        C1["Rechenknoten 1"]
        C2["Rechenknoten 2"]
    end
    subgraph fabric["Core Fabric (gemeinsames L2)"]
        CF["Core Fabric 1 + 2"]
    end
    N1 --- CF
    N2 --- CF
    ST1 --- CF
    ST2 --- CF
    C1 --- CF
    C2 --- CF
    EXT["Externes Netzwerk"] --- N1
    EXT --- N2
    EXT --- ST1
    EXT --- ST2
    EXT --- C1
    EXT --- C2

    style cluster1 fill:#f0f4ff,stroke:#336
    style cluster2 fill:#fff3e0,stroke:#e65100
    style cluster3 fill:#e8f5e9,stroke:#2e7d32
    style fabric fill:#fce4ec,stroke:#c62828
```

### Wann UCI wählen

| Szenario                                | Warum UCI funktioniert                                                                |
| --------------------------------------- | ------------------------------------------------------------------------------------- |
| **Große Umgebungen** (10+ Knoten)       | Unabhängige Skalierung vermeidet Überprovisionierung                                  |
| **Speicherintensive Workloads**         | Fügen Sie Speicherkapazität hinzu, ohne nicht benötigte Rechenleistung zu kaufen      |
| **Rechenintensive Workloads**           | Fügen Sie GPU- oder High-CPU-Knoten hinzu, ohne nicht benötigten Speicher zu kaufen   |
| **KI / HPC / GPU-Cluster**              | Dedizierter Rechencluster mit GPU-Passthrough, getrennt vom Speicher                  |
| **Cloud Service Provider**              | Optimieren Sie die Hardwareausgaben pro Ressourcenschicht über viele Mandanten hinweg |
| **Planbares, ungleichmäßiges Wachstum** | Speicher- und Rechenanforderungen wachsen mit unterschiedlichen Raten                 |

### Wichtige Merkmale

* **Minimum**: 6 Knoten (2 Controller + 2 Speicherknoten + 2 Rechenknoten)
* **Skalierung**: Fügen Sie Knoten einzelnen Clustern unabhängig hinzu
* **Knotenrollen**: Jeder Knoten hat eine einzelne Rolle (Controller, Speicher oder Rechenleistung)
* **Clusteranzahl**: 3 in der kanonischen Form (Controller, Speicher, Rechenleistung); 2 in der Hybridvariante
* **Flexibilität**: Hardware je Rolle passend dimensionieren (NVMe-dicht für Speicher, mit GPU für Rechenleistung)

## Hybrides UCI: Die Zwei-Cluster-Variante

VergeOS unterstützt auch ein **hybrides UCI** Modell — eine Zwei-Cluster-UCI-Variante, die die Controller- und Speicherrollen in einem Cluster zusammenfasst. Controller-Knoten stellen vSAN-Speicher UND Systemverwaltung bereit; sie führen keine Produktions-VM-Workloads aus. Ein separater Cluster dedizierter Rechenknoten übernimmt die gesamte VM-Ausführung.

Dies ist ein beliebtes Bereitstellungsmodell, weil es die Controller-/Speicherebene schlank und dediziert hält, während die Rechenleistung über ihren eigenen Cluster unabhängig skaliert. Die Controller stellen den Rechenknoten über die Core Fabric vSAN-Speicher bereit.

{% hint style="success" %}
**Controller-Knoten müssen keine VMs ausführen**

In einer hybriden Bereitstellung dienen Controller-Knoten häufig nur als Speicher- und Verwaltungsknoten — auf ihnen laufen keine Produktions-VMs. Das reduziert Ressourcenkonflikte auf den Controllern und vereinfacht die Kapazitätsplanung: Speicher skaliert durch Hinzufügen von Knoten zum Controller-Cluster, Rechenleistung skaliert durch Hinzufügen von Knoten zum Rechencluster.
{% endhint %}

```mermaid
graph TB
    subgraph cluster1["Cluster 1 (Controller — Nur Speicher)"]
        N1["Knoten 1 — Controller<br/>Speicher + Verwaltung"]
        N2["Knoten 2 — Controller<br/>Speicher + Verwaltung"]
    end
    subgraph cluster2["Cluster 2 (Nur Rechenleistung)"]
        C1["Rechenknoten 1"]
        C2["Rechenknoten 2"]
    end
    subgraph fabric["Core Fabric (gemeinsames L2)"]
        CF["Core Fabric 1 + 2"]
    end
    N1 --- CF
    N2 --- CF
    C1 --- CF
    C2 --- CF
    EXT["Externes Netzwerk"] --- N1
    EXT --- N2
    EXT --- C1
    EXT --- C2

    style cluster1 fill:#e8f5e9,stroke:#2e7d32
    style cluster2 fill:#fff3e0,stroke:#e65100
    style fabric fill:#f0f4ff,stroke:#336
```

Alternativ können die Controller **auch** bei Bedarf zusätzlich zu Speicher auch VMs ausführen — das ist in kleineren Umgebungen nützlich, in denen zwei Knoten ausschließlich für Speicher zu reservieren verschwenderisch wirkt. Das Hybridmodell ist flexibel: Controller können je nach Anforderung nur Speicher oder Speicher + Rechenleistung bereitstellen.

## HCI- vs. UCI-Vergleich

| Aspekt                         | HCI                                         | UCI                                                      |
| ------------------------------ | ------------------------------------------- | -------------------------------------------------------- |
| **Mindestanzahl Knoten**       | 2                                           | 6                                                        |
| **Clusteranzahl**              | 1                                           | 3                                                        |
| **Knotentypen**                | Alle Knoten identisch                       | Controller, Speicher, Rechenleistung                     |
| **Speicher-Skalierung**        | An Rechenleistung gebunden                  | Unabhängig                                               |
| **Compute-Skalierung**         | An Speicher gebunden                        | Unabhängig                                               |
| **Hardware-Einheitlichkeit**   | Alle Knoten haben dieselben Spezifikationen | Knoten je Rolle optimiert                                |
| **Bereitstellungskomplexität** | Geringer                                    | Höher                                                    |
| **Kosten im kleinen Maßstab**  | Geringer (weniger Knoten)                   | Höher (mindestens 6 Knoten)                              |
| **Kosten im großen Maßstab**   | Kann überprovisionieren                     | Optimierte Ausgaben pro Schicht                          |
| **Beste Passung**              | Klein bis mittel, ausgeglichen              | Groß, ungleichmäßiges Wachstum, spezialisierte Workloads |

## Entscheidungsrahmen

Nutzen Sie dieses Flussdiagramm, um Ihre Empfehlung für das Bereitstellungsmodell zu bestimmen:

```mermaid
flowchart TD
    A["Wie viele Knoten<br/>benötigt die Bereitstellung?"] --> B{"Weniger als 6?"}
    B -->|Ja| C["✅ HCI<br/>UCI erfordert mindestens 6 Knoten"]
    B -->|Nein| D{"Wachsen Speicher und Rechenleistung<br/>im gleichen Tempo?"}
    D -->|"Ja — ausgewogenes Wachstum"| E["✅ HCI<br/>Einfacher zu verwalten,<br/>keine verschwendeten Ressourcen"]
    D -->|"Nein — ungleichmäßiges Wachstum"| F{"Spezialisierte Hardware<br/>erforderlich? (GPU, NVMe-dicht)"}
    F -->|Ja| G["✅ UCI<br/>Hardware je Rolle passend dimensionieren"]
    F -->|Nein| H{"Hat Kostenoptimierung<br/>in großem Maßstab Priorität?"}
    H -->|Ja| I["✅ UCI<br/>Überdimensionierung vermeiden"]
    H -->|Nein| J["✅ HCI<br/>Einfacher ist besser"]

    style C fill:#e8f5e9,stroke:#2e7d32
    style E fill:#e8f5e9,stroke:#2e7d32
    style G fill:#fff3e0,stroke:#e65100
    style I fill:#fff3e0,stroke:#e65100
    style J fill:#e8f5e9,stroke:#2e7d32
```

### Schnelle Faustregeln

1. **Beginnen Sie mit HCI** es sei denn, Sie haben einen bestimmten Grund, UCI zu wählen
2. **Erwägen Sie UCI** wenn Sie 10+ Knoten benötigen oder spezielle Hardwareanforderungen haben
3. **Hybrides UCI** (2-Cluster) ist ein guter Zwischenschritt -- beginnen Sie mit HCI und verlagern Sie dann die Rechenleistung auf einen eigenen Cluster
4. Sie können **sich weiterentwickeln** von HCI zu hybridem UCI bis hin zu vollständigem UCI, wenn die Umgebung wächst

## Beispiele für den Terraform-Playground

Der VergeOS Terraform-Playground enthält Beispielkonfigurationen für jedes Bereitstellungsmodell, sodass jede Topologie leicht getestet werden kann:

| Modell                | Beispieldatei                                 | Knoten | Cluster |
| --------------------- | --------------------------------------------- | ------ | ------- |
| **2-Knoten-HCI**      | `examples/2-node-hci.tfvars`                  | 2      | 1       |
| **HCI + Scale-out**   | `examples/4-node-hci.tfvars`                  | 4      | 1       |
| **Hybrides UCI**      | `examples/4-node-hybrid-hci-2-cluster.tfvars` | 4      | 2       |
| **Vollständiges UCI** | `examples/6-node-uci-3-cluster.tfvars`        | 6      | 3       |

Jedes Beispiel ist eine `.tfvars` Datei, die Sie kopieren nach `terraform.tfvars` und mit Ihren Umgebungseinstellungen anpassen. Das Bereitstellungsmodell wird durch boolesche Umschaltvariablen gesteuert:

* **HCI**: Keine Umschalter erforderlich (Standard)
* **HCI + Scale-out**: `create_scale_out_nodes = true`
* **Hybrides UCI**: `create_compute_nodes = true`
* **UCI**: `create_storage_nodes = true` und `create_compute_nodes = true`

{% hint style="info" %}
**VMware Bridge**

Kommen Sie von vSAN? VergeOS unterstützt sowohl HCI- als auch UCI-Bereitstellungen aus derselben Installation -- keine separate Produktstufe oder Lizenzierung für entkoppelten Speicher. Speicherknoten- und Rechenknotentypen sind vollwertige Bereitstellungsoptionen, die alle über dieselbe UI verwaltet werden.
{% endhint %}

{% hint style="info" %}
**Nutanix Bridge**

Kommen Sie von Nutanix? VergeOS führt Speicher als integrierten OS-Dienst aus — es gibt kein pro Knoten zu dimensionierendes, zu patchendes oder zu diagnostizierendes CVM. Speicherknoten- und Rechenknotentypen ermöglichen es Ihnen, Hardware je Rolle innerhalb eines einzigen Systems zuzuweisen.
{% endhint %}

## Ein-Knoten-Bereitstellungen

Obwohl VergeOS für Multi-Knoten-Cluster ausgelegt ist, **Ein-Knoten-Bereitstellungen** haben sinnvolle Anwendungsfälle:

* **Bare-Metal-Ersatz** — Ersetzen Sie einen traditionellen physischen Server durch einen einzelnen VergeOS-Knoten, der mehrere VMs ausführt, und profitieren Sie von den Vorteilen der Virtualisierung (Snapshots, Ressourcenverwaltung, einfache Sicherung), ohne einen zweiten Knoten zu benötigen
* **Edge-Standorte** — Ein einzelner Knoten an einem entfernten Standort, an dem Daten lokal nicht kritisch sind (z. B. Thin-Client-Host, lokaler Cache, Beschilderung) und bei Bedarf von einem zentralen Standort repliziert werden können
* **Entwicklung / Labor** — Ein eigenständiges System für Tests und Entwicklung

Ein-Knoten-Bereitstellungen verfügen dennoch über **Redundanz auf Festplattenebene** — vSAN verwendet 2-Kopie-Mirroring über die Laufwerke innerhalb des Knotens (wodurch etwa 50 % nutzbare Kapazität entstehen) und schützt so vor Ausfällen einzelner Laufwerke. Allerdings gibt es **keine Redundanz auf Knotenebene** — wenn der Knoten selbst ausfällt, sind die Workloads nicht verfügbar, bis er wiederhergestellt ist. Snapshots und Offsite-Replikation werden dringend empfohlen.

## Zusammenfassung

| Konzept             | Wichtigste Erkenntnis                                                                                  |
| ------------------- | ------------------------------------------------------------------------------------------------------ |
| **HCI**             | Jeder Knoten macht alles. Einfach, kostengünstig im kleinen Maßstab.                                   |
| **UCI**             | Dedizierte Rollen pro Knoten. Flexibel, kostenoptimiert im großen Maßstab.                             |
| **Hybrides UCI**    | Controller übernehmen Speicher/Verwaltung; Rechenleistung skaliert separat. Zwei-Cluster-UCI-Variante. |
| **VergeOS-Vorteil** | Dieselbe Plattform unterstützt alle drei Modelle -- keine Produktänderungen erforderlich.              |

## Nächste Schritte

Jetzt, da Sie die HCI- und UCI-Bereitstellungsmodelle verstanden haben, behandelt das nächste Thema die Speicherschicht, die beide antreibt: [**vSAN / VergeFS →**](/learn-the-platform/de/modul-1-architekturgrundlagen/03-vsan-vergefs.md)


---

# 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-1-architekturgrundlagen/02-hci-vs-uci.md?ask=<question>&goal=<endgoal>
```

`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.