> 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/fr/module-1-fondamentaux-de-larchitecture/02-hci-vs-uci.md).

# HCI vs UCI : modèles de déploiement

## Deux façons de déployer VergeOS

VergeOS est unique parmi les plateformes d’infrastructure car il prend en charge **deux modèles de déploiement distincts** à partir de la même installation logicielle :

* **HCI (infrastructure hyperconvergée)** -- Le calcul et le stockage s’exécutent sur chaque nœud. Les ressources évoluent ensemble.
* **UCI (infrastructure ultra convergée)** -- Le calcul et le stockage s’exécutent sur des types de nœuds dédiés et séparés. Les ressources évoluent indépendamment.

La plupart des plateformes concurrentes (VMware vSAN, Nutanix) ne prennent en charge que l’HCI. VergeOS vous offre les deux options -- et vous pouvez même les combiner au sein d’un seul système.

{% hint style="info" %}
**Système vs cluster**

* **Système** — l’ensemble du déploiement VergeOS, composé d’un ou plusieurs clusters gérés comme une seule unité.
* **Cluster** — un groupe de nœuds avec un matériel correspondant, partageant des limites de calcul et de haute disponibilité. Les niveaux de stockage vSAN s’étendent à tous les clusters du système, de sorte que le stockage est partagé à l’échelle du système, même si le calcul et la HA sont définis par cluster.
  {% endhint %}

## HCI : infrastructure hyperconvergée

Dans un déploiement HCI, chaque nœud du cluster contribue **les deux** à la capacité de stockage et aux ressources de calcul. Lorsque vous avez besoin de davantage de l’un ou de l’autre, vous ajoutez un autre nœud -- ce qui ajoute les deux.

### Fonctionnement

Le point de départ le plus courant est un cluster HCI à 2 nœuds. Deux nœuds contrôleurs forment un seul cluster qui gère le stockage (vSAN) et le calcul (charges de travail VM). Les deux nœuds contribuent des disques de niveau 0 et de niveau charge de travail au pool de stockage partagé, et les deux nœuds exécutent des machines virtuelles.

Pour grandir, vous ajoutez **nœuds d'extension** au même cluster. Chaque nœud de mise à l’échelle horizontale rejoint via la détection automatique réseau et apporte immédiatement une capacité supplémentaire de stockage et de calcul.

```mermaid
graph TB
    sous-graphe cluster1["Cluster 1 (HCI)"]
        N1["Nœud 1 — Contrôleur<br/>Stockage + Calcul"]
        N2["Nœud 2 — Contrôleur<br/>Stockage + Calcul"]
        S1["Nœud de mise à l’échelle 3<br/>Stockage + calcul"]
        S2["Nœud de mise à l’échelle 4<br/>Stockage + calcul"]
    end
    sous-graphe fabric["Fabric centrale (L2 partagé)"]
        CF["Fabric centrale 1 + 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    S2 --- CF
    EXT["Réseau externe"] --- N1
    EXT --- N2
    EXT --- S1
    EXT --- S2

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

### Quand choisir l’HCI

| Scénario                                       | Pourquoi HCI fonctionne                                                            |
| ---------------------------------------------- | ---------------------------------------------------------------------------------- |
| **Déploiements de petite taille** (2--8 nœuds) | Complexité minimale, chaque nœud assure deux fonctions                             |
| **Charges de travail équilibrées**             | Lorsque les besoins en stockage et en calcul augmentent à peu près au même rythme  |
| **Sites en périphérie / distants**             | Clusters à 2 nœuds avec HA complète et faible encombrement physique                |
| **Évaluation et tests**                        | Le chemin le plus rapide vers un système VergeOS opérationnel                      |
| **Soucieux du budget**                         | Moins de nœuds au total nécessaires pour les charges de travail petites à moyennes |

### Caractéristiques clés

* **Minimum**: 2 nœuds (paire de contrôleurs)
* **Mise à l’échelle**: Ajoutez des nœuds de mise à l’échelle au même cluster
* **Rôles des nœuds**: Tous les nœuds exécutent le stockage **et** le calcul
* **Nombre de clusters**: 1
* **Simplicité**: Le plus facile à déployer et à gérer

## UCI : infrastructure ultra convergée

UCI est le terme générique pour tout déploiement dans lequel le stockage et le calcul évoluent indépendamment sur **des types de nœuds dédiés**. La forme canonique utilise trois clusters (contrôleur, stockage, calcul) ; une variante hybride populaire fusionne contrôleur + stockage en deux clusters. Dans tous les cas, vous faites évoluer chaque niveau de ressource indépendamment -- ajoutez des nœuds de stockage lorsque vous avez besoin de plus de capacité, ou des nœuds de calcul lorsque vous avez besoin de plus de CPU et de RAM, sans acheter les deux.

### Fonctionnement

Un déploiement UCI commence avec la même paire de contrôleurs à 2 nœuds, mais les contrôleurs gèrent le système sans exécuter de charges de travail de production ni stocker de données utilisateur. Des **nœuds de stockage** dédiés forment un deuxième cluster qui fournit toute la capacité vSAN. Des **nœuds de calcul** dédiés forment un troisième cluster qui exécute toutes les charges de travail VM.

```mermaid
graph TB
    sous-graphe cluster1["Cluster 1 (Contrôleur)"]
        N1["Nœud 1 — Contrôleur"]
        N2["Nœud 2 — Contrôleur"]
    end
    sous-graphe cluster2["Cluster 2 (Stockage)"]
        ST1["Nœud de stockage 1"]
        ST2["Nœud de stockage 2"]
    end
    sous-graphe cluster3["Cluster 3 (Calcul)"]
        C1["Nœud de calcul 1"]
        C2["Nœud de calcul 2"]
    end
    sous-graphe fabric["Fabric centrale (L2 partagé)"]
        CF["Fabric centrale 1 + 2"]
    end
    N1 --- CF
    N2 --- CF
    ST1 --- CF
    ST2 --- CF
    C1 --- CF
    C2 --- CF
    EXT["Réseau externe"] --- 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
```

### Quand choisir l’UCI

| Scénario                                        | Pourquoi UCI fonctionne                                                                  |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------- |
| **Environnements de grande taille** (10+ nœuds) | La mise à l'échelle indépendante évite le surdimensionnement                             |
| **Charges de travail gourmandes en stockage**   | Ajoutez de la capacité de stockage sans acheter de calcul dont vous n’avez pas besoin    |
| **Charges de travail gourmandes en calcul**     | Ajoutez des nœuds GPU ou à fort CPU sans acheter de stockage dont vous n’avez pas besoin |
| **Clusters IA / HPC / GPU**                     | Cluster de calcul dédié avec passthrough GPU, séparé du stockage                         |
| **Fournisseurs de services cloud**              | Optimisez les dépenses matérielles par niveau de ressource sur de nombreux locataires    |
| **Croissance prévisible et inégale**            | Les besoins en stockage et en calcul augmentent à des rythmes différents                 |

### Caractéristiques clés

* **Minimum**: 6 nœuds (2 contrôleurs + 2 stockage + 2 calcul)
* **Mise à l’échelle**: Ajoutez des nœuds à des clusters individuels indépendamment
* **Rôles des nœuds**: Chaque nœud a un rôle unique (contrôleur, stockage ou calcul)
* **Nombre de clusters**: 3 dans la forme canonique (contrôleur, stockage, calcul) ; 2 dans la variante hybride
* **Flexibilité**: Dimensionnez le matériel selon chaque rôle (NVMe dense pour le stockage, GPU pour le calcul)

## UCI hybride : la variante à deux clusters

VergeOS prend également en charge un **UCI hybride** modèle — une variante UCI à deux clusters qui fusionne les rôles de contrôleur et de stockage en un seul cluster. Les nœuds contrôleurs fournissent le stockage vSAN ET la gestion du système ; ils n’exécutent pas de charges de travail VM de production. Un cluster séparé de nœuds de calcul dédiés gère toute l’exécution des VM.

C’est un modèle de déploiement populaire car il maintient la couche contrôleur/stockage légère et dédiée, tandis que le calcul évolue indépendamment via son propre cluster. Les contrôleurs fournissent le stockage vSAN aux nœuds de calcul via la fabric centrale.

{% hint style="success" %}
**Les nœuds contrôleurs n’ont pas à exécuter de VM**

Dans un déploiement hybride, les nœuds contrôleurs servent généralement uniquement de nœuds de stockage et de gestion — aucune VM de production n’y est exécutée. Cela réduit la contention des ressources sur les contrôleurs et simplifie la planification de capacité : le stockage évolue en ajoutant des nœuds au cluster contrôleur, le calcul évolue en ajoutant des nœuds au cluster de calcul.
{% endhint %}

```mermaid
graph TB
    sous-graphe cluster1["Cluster 1 (Contrôleur — stockage uniquement)"]
        N1["Nœud 1 — Contrôleur<br/>Stockage + gestion"]
        N2["Nœud 2 — Contrôleur<br/>Stockage + gestion"]
    end
    sous-graphe cluster2["Cluster 2 (Calcul uniquement)"]
        C1["Nœud de calcul 1"]
        C2["Nœud de calcul 2"]
    end
    sous-graphe fabric["Fabric centrale (L2 partagé)"]
        CF["Fabric centrale 1 + 2"]
    end
    N1 --- CF
    N2 --- CF
    C1 --- CF
    C2 --- CF
    EXT["Réseau externe"] --- 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
```

Sinon, les contrôleurs **peuvent** également exécuter des VM aux côtés du stockage si nécessaire — ce qui est utile dans les environnements plus petits où consacrer deux nœuds uniquement au stockage semble inefficace. Le modèle hybride est flexible : les contrôleurs peuvent fournir uniquement le stockage, ou le stockage + le calcul, selon vos besoins.

## Comparaison HCI vs UCI

| Aspect                           | HCI                                         | UCI                                                        |
| -------------------------------- | ------------------------------------------- | ---------------------------------------------------------- |
| **Nombre minimum de nœuds**      | 2                                           | 6                                                          |
| **Nombre de clusters**           | 1                                           | 3                                                          |
| **Types de nœuds**               | Tous les nœuds identiques                   | Contrôleur, stockage, calcul                               |
| **Mise à l’échelle du stockage** | Lié au calcul                               | Indépendant                                                |
| **Mise à l’échelle du calcul**   | Lié au stockage                             | Indépendant                                                |
| **Uniformité matérielle**        | Tous les nœuds ont les mêmes spécifications | Nœuds optimisés par rôle                                   |
| **Complexité du déploiement**    | Plus faible                                 | Plus élevée                                                |
| **Coût à petite échelle**        | Plus faible (moins de nœuds)                | Plus élevé (minimum 6 nœuds)                               |
| **Coût à grande échelle**        | Peut surprovisionner                        | Dépense optimisée par niveau                               |
| **Meilleure adéquation**         | Petit à moyen, équilibré                    | Grand, croissance inégale, charges de travail spécialisées |

## Cadre de décision

Utilisez cet organigramme pour guider votre recommandation de modèle de déploiement :

```mermaid
flowchart TD
    A["Combien de nœuds<br/>le déploiement nécessitera-t-il ?"] --> B{"Moins de 6 ?"}
    B -->|Oui| C["✅ HCI<br/>UCI nécessite un minimum de 6 nœuds"]
    B -->|Non| D{"Le stockage et le calcul<br/>augmentent-ils au même rythme ?"}
    D -->|"Oui — croissance équilibrée"| E["✅ HCI<br/>Plus simple à gérer,<br/>aucune ressource gaspillée"]
    D -->|"Non — croissance inégale"| F{"Matériel spécialisé<br/>nécessaire ? (GPU, NVMe dense)"}
    F -->|Oui| G["✅ UCI<br/>Dimensionnez le matériel selon chaque rôle"]
    F -->|Non| H{"L’optimisation des coûts<br/>à grande échelle est-elle une priorité ?"}
    H -->|Oui| I["✅ UCI<br/>Évitez la surprovisionnement"]
    H -->|Non| J["✅ HCI<br/>La simplicité vaut mieux"]

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

### Règles rapides à retenir

1. **Commencez par HCI** à moins que vous n’ayez une raison spécifique d’opter pour l’UCI
2. **Envisagez l’UCI** lorsque vous avez besoin de 10 nœuds ou plus, ou des exigences matérielles spécialisées
3. **UCI hybride** (2 clusters) est une bonne étape intermédiaire -- commencez en HCI, puis transférez le calcul vers son propre cluster
4. Vous pouvez **évoluer** de HCI à UCI hybride puis à UCI complet à mesure que l’environnement se développe

## Exemples du Playground Terraform

Le Playground Terraform de VergeOS inclut des configurations d’exemple pour chaque modèle de déploiement, ce qui facilite le test de chaque topologie :

| Modèle              | Fichier d’exemple                             | Nœuds | Clusters |
| ------------------- | --------------------------------------------- | ----- | -------- |
| **HCI à 2 nœuds**   | `examples/2-node-hci.tfvars`                  | 2     | 1        |
| **HCI + Scale-out** | `examples/4-node-hci.tfvars`                  | 4     | 1        |
| **UCI hybride**     | `examples/4-node-hybrid-hci-2-cluster.tfvars` | 4     | 2        |
| **UCI complet**     | `examples/6-node-uci-3-cluster.tfvars`        | 6     | 3        |

Chaque exemple est un `.tfvars` fichier que vous copiez vers `terraform.tfvars` et que vous personnalisez avec les paramètres de votre environnement. Le modèle de déploiement est contrôlé par des variables booléennes :

* **HCI**: Aucun interrupteur nécessaire (par défaut)
* **HCI + Scale-out**: `create_scale_out_nodes = true`
* **UCI hybride**: `create_compute_nodes = true`
* **UCI**: `create_storage_nodes = true` et `create_compute_nodes = true`

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

Vous venez de vSAN ? VergeOS prend en charge les déploiements HCI et UCI à partir de la même installation — pas de niveau de produit séparé ni de licence pour le stockage désagrégé. Les types de nœuds de stockage uniquement et de calcul uniquement sont des options de déploiement à part entière, toutes gérées depuis la même interface utilisateur.
{% endhint %}

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

Vous venez de Nutanix ? VergeOS exécute le stockage comme un service OS intégré — il n’existe pas de CVM par nœud à dimensionner, corriger ou dépanner. Les types de nœuds de stockage uniquement et de calcul uniquement vous permettent de consacrer le matériel à chaque rôle au sein d’un seul système.
{% endhint %}

## Déploiements sur un seul nœud

Bien que VergeOS soit conçu pour des clusters multinœuds, **les déploiements sur un seul nœud** ont des cas d’usage valides :

* **Remplacement bare metal** — Remplacez un serveur physique traditionnel par un seul nœud VergeOS exécutant plusieurs VM, en bénéficiant des avantages de la virtualisation (instantanés, gestion des ressources, sauvegarde facile) sans avoir besoin d’un second nœud
* **Sites périphériques** — Un seul nœud dans un emplacement distant où les données ne sont pas critiques localement (par exemple, hôte de client léger, cache local, affichage numérique) et peuvent être répliquées depuis un site central si nécessaire
* **Développement / labo** — Un système autonome pour les tests et le développement

Les déploiements sur un seul nœud disposent tout de même d’une **redondance au niveau du disque** — vSAN utilise une mise en miroir à 2 copies sur les disques du nœud (ce qui donne environ 50 % de capacité utilisable), protégeant contre les pannes de disque individuelles. Cependant, il n’y a **pas de redondance au niveau du nœud** — si le nœud lui-même tombe en panne, les charges de travail sont interrompues jusqu’à sa restauration. Les instantanés et la réplication hors site sont fortement recommandés.

## Résumé

| Concept              | Point clé                                                                                                  |
| -------------------- | ---------------------------------------------------------------------------------------------------------- |
| **HCI**              | Chaque nœud fait tout. Simple, rentable à petite échelle.                                                  |
| **UCI**              | Rôles dédiés par nœud. Flexible, optimisé en coût à grande échelle.                                        |
| **UCI hybride**      | Les contrôleurs gèrent le stockage/la gestion ; le calcul évolue séparément. Variante UCI à deux clusters. |
| **Avantage VergeOS** | La même plateforme prend en charge les trois modèles -- aucune modification de produit n’est nécessaire.   |

## Étapes suivantes

Maintenant que vous comprenez les modèles de déploiement HCI et UCI, le sujet suivant couvre la couche de stockage qui alimente les deux : [**vSAN / VergeFS →**](/learn-the-platform/fr/module-1-fondamentaux-de-larchitecture/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/fr/module-1-fondamentaux-de-larchitecture/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.