> 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-2-dimensionnement-et-conception/02-reference-architectures.md).

# Architectures de référence

VergeOS prend en charge trois architectures de déploiement à partir de la même installation logicielle. Le choix de la bonne architecture dépend du nombre de nœuds, du rythme de croissance et des exigences de spécialisation des charges de travail. Cette page présente chaque modèle, fournit un cadre de décision et couvre deux scénarios réels courants : les déploiements en périphérie et les environnements multi-locataires des fournisseurs de services cloud (CSP).

## Arbre de décision d'architecture

Utilisez le cadre suivant pour guider votre recommandation. Les plages de nombre de nœuds ci-dessous sont des règles empiriques approximatives : HCI convient aux déploiements plus petits (généralement 2--12 nœuds), et UCI s'applique lorsque la croissance du calcul et du stockage diverge ou qu'un matériel spécialisé est nécessaire.

```mermaid
flowchart TD
    A["Combien de nœuds comptera<br/>le déploiement ?"] --> B{"2 -- 6 nœuds"}
    A --> C{"6 -- 10 nœuds"}
    A --> D{"10+ nœuds"}

    B --> E{"Le calcul et le stockage<br/>croîtront-ils proportionnellement ?"}
    E -->|"Oui"| F["HCI"]
    E -->|"Non -- le calcul croît plus vite"| G["HCI + calcul dédié<br/>(UCI hybride à 2 clusters)"]
    E -->|"Incertain"| H{"Matériel spécialisé<br/>nécessaire ? (GPU, haute mémoire)"}

    C --> H
    D --> I["UCI (Canonical 3-Cluster)"]

    H -->|"Oui"| I
    H -->|"Non"| G
    H -->|"Peut-être à l'avenir"| G

    style F fill:#e8f5e9,stroke:#2e7d32
    style G fill:#fff3e0,stroke:#e65100
    style I fill:#f0f4ff,stroke:#336
```

**Règles rapides à retenir :**

1. **Commencez par HCI** sauf raison spécifique de ne pas le faire.
2. **Envisagez HCI + Calcul** lorsque la demande en calcul dépasse la croissance du stockage (6--10 nœuds).
3. **Choisissez UCI** pour les environnements de 10 nœuds et plus, le matériel spécialisé ou l'isolation maximale des performances.
4. Vous pouvez **évoluer** de HCI à HCI + Calcul à UCI à mesure que l'environnement grandit -- la même installation VergeOS prend en charge les trois.

***

## Modèle 1 : HCI (infrastructure hyperconvergée)

**Plage de nœuds :** 2--6 nœuds | **Clusters :** 1

Dans un déploiement HCI, chaque nœud contribue **à la fois** au calcul et au stockage. Les deux nœuds contrôleurs assurent le stockage de niveau 0 (métadonnées vSAN) et de niveau 1 (charge de travail) et exécutent des VM. Les nœuds d'extension ajoutent de la capacité de stockage de niveau 1 et de calcul au même cluster.

```mermaid
graph TB
    subgraph cluster1["Cluster 1 -- HCI"]
        N1["Nœud 1 -- Contrôleur<br/>Niveau 0 + Niveau 1<br/>Stockage + Calcul"]
        N2["Nœud 2 -- Contrôleur<br/>Niveau 0 + Niveau 1<br/>Stockage + Calcul"]
        S1["Nœud 3 -- Extension<br/>Niveau 1<br/>Stockage + Calcul"]
        S2["Nœud 4 -- Extension<br/>Niveau 1<br/>Stockage + Calcul"]
    end
    subgraph fabric["Core Fabric"]
        CF["Cœur 1 + Cœur 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    S2 --- CF

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

### Avantages

* **Simplicité opérationnelle** -- un seul cluster, une seule spécification matérielle, une gestion unifiée.
* **Mise à l'échelle prévisible** -- chaque nœud ajoute proportionnellement du stockage et du calcul.
* **Point d'entrée le plus bas** -- un cluster de 2 nœuds est le plus petit déploiement VergeOS possible.
* **Une seule spécification matérielle** simplifie les achats et l'inventaire des pièces de rechange.

### Limites

* Impossible de faire évoluer le calcul indépendamment du stockage (ou inversement).
* Spécialisation matérielle limitée -- tous les nœuds partagent le même rôle.
* Maximum recommandé d'environ 6 nœuds avant d'envisager un second cluster.
* Risque potentiel de contention des ressources sur les nœuds contrôleurs exécutant à la fois les opérations de métadonnées et les charges de travail des VM.

### Cas d'utilisation idéaux

| Scénario                                | Pourquoi HCI fonctionne                                                  |
| --------------------------------------- | ------------------------------------------------------------------------ |
| Déploiements petits/moyens (2--6 nœuds) | Complexité minimale, chaque nœud assure deux fonctions                   |
| Charges de travail équilibrées          | Le stockage et le calcul croissent à peu près au même rythme             |
| Sites en périphérie / distants          | Clusters à 2 nœuds avec haute disponibilité complète et faible empreinte |
| Évaluation et tests                     | Le chemin le plus rapide vers un système VergeOS opérationnel            |

***

## Modèle 2 : HCI + calcul dédié (UCI hybride à 2 clusters)

**Plage de nœuds :** 6--10 nœuds | **Clusters :** 2

Il s'agit de la variante UCI hybride à 2 clusters : les rôles de contrôleur et de stockage restent fusionnés dans un cluster HCI, tandis que le calcul est séparé dans son propre cluster. Le cluster HCI (cluster 1) fournit tout le stockage via ses contrôleurs et ses nœuds d'extension optionnels. Le cluster de calcul (cluster 2) exécute les charges de travail VM sans fournir de disques.

```mermaid
graph TB
    subgraph cluster1["Cluster 1 -- HCI (Stockage + Calcul)"]
        N1["Nœud 1 -- Contrôleur<br/>Niveau 0 + Niveau 1"]
        N2["Nœud 2 -- Contrôleur<br/>Niveau 0 + Niveau 1"]
        S1["Nœud 3 -- HCI<br/>Niveau 1 (optionnel)"]
    end
    subgraph cluster2["Cluster 2 -- Calcul uniquement"]
        C1["Nœud 4 -- Calcul"]
        C2["Nœud 5 -- Calcul"]
        C3["Nœud 6 -- Calcul"]
        C4["Nœud 7+ -- Extension"]
    end
    subgraph fabric["Core Fabric"]
        CF["Cœur 1 + Cœur 2"]
    end
    N1 --- CF
    N2 --- CF
    S1 --- CF
    C1 --- CF
    C2 --- CF
    C3 --- CF
    C4 --- CF

    style cluster1 fill:#fff3e0,stroke:#e65100
    style cluster2 fill:#e3f2fd,stroke:#1565c0
    style fabric fill:#f0f4ff,stroke:#336
```

### Principes de conception clés

### Cluster 1 -- HCI (combiné)

* Inclut toujours les nœuds 1 et 2 avec le stockage de niveau 0 (contrôleurs). - Peut inclure des nœuds HCI d'extension supplémentaires pour davantage de stockage et de calcul. - Un commutateur au niveau du cluster contrôle si ce cluster exécute également des charges de travail VM. - Tous les niveaux de stockage existent dans ce cluster.

### Cluster 2 -- Calcul uniquement

* Calcul pur -- maximum de CPU et de RAM disponibles pour les VM. - Évolue indépendamment en fonction de la demande de calcul. - Prend en charge un matériel flexible, optimisé pour la charge de travail (nœuds GPU, nœuds à haute mémoire). - Les E/S de stockage des nœuds de calcul transitent par le core fabric vers le cluster 1.

### Avantages

* Mise à l'échelle indépendante du calcul sans acheter de stockage inutile.
* Conserve la simplicité opérationnelle HCI pour la couche de stockage.
* Rentable -- ne faire évoluer que la couche de ressources qui croît.
* Chemin de croissance clair vers l'UCI canonique à 3 clusters si les besoins évoluent davantage.

### Limites

* Les E/S de stockage des nœuds de calcul traversent le réseau (une bande passante adéquate du core fabric est essentielle).
* Plus complexe qu'une HCI pure (deux clusters à gérer au lieu d'un).
* Nécessite de décider si le cluster HCI doit également exécuter des charges de travail.

### Cas d'utilisation idéaux

| Scénario                                          | Pourquoi HCI + Calcul fonctionne                     |
| ------------------------------------------------- | ---------------------------------------------------- |
| Déploiements de 6--10 nœuds                       | Point idéal pour le modèle à deux clusters           |
| La croissance du calcul dépasse celle du stockage | Ajouter du CPU/de la RAM sans étendre les disques    |
| GPU ou calcul spécialisé                          | Cluster de calcul dédié avec matériel en passthrough |
| Optimisation des coûts                            | Ne faire évoluer que ce dont vous avez besoin        |

***

## Modèle 3 : UCI (infrastructure ultra-convergée) -- Canonical 3-Cluster

**Plage de nœuds :** 10+ nœuds | **Clusters :** 3+

L'UCI canonique à 3 clusters sépare complètement les contrôleurs, le stockage et le calcul dans des clusters dédiés. Chaque niveau de ressource évolue indépendamment et utilise un matériel optimisé pour son rôle. (UCI est un terme générique pour tout déploiement à mise à l'échelle indépendante ; le modèle 2 ci-dessus en est la variante hybride à 2 clusters.)

```mermaid
graph TB
    subgraph cluster1["Cluster 1 -- Contrôleurs dédiés"]
        N1["Nœud 1 -- Contrôleur<br/>Niveau 0 uniquement | Haute mémoire"]
        N2["Nœud 2 -- Contrôleur<br/>Niveau 0 uniquement | Haute mémoire"]
    end
    subgraph cluster2["Cluster 2 -- Stockage dédié"]
        ST1["Nœud 3 -- Stockage<br/>NVMe dense | Niveau 1"]
        ST2["Nœud 4 -- Stockage<br/>NVMe dense | Niveau 1"]
        ST3["Nœud 5 -- Stockage<br/>NVMe dense | Niveau 1"]
    end
    subgraph cluster3["Clusters 3+ -- Calcul spécialisé"]
        Calcul standard
        Calcul GPU
        Haute mémoire
    end
    subgraph fabric["Core Fabric"]
        CF["Cœur 1 + Cœur 2"]
    end
    N1 --- CF
    N2 --- CF
    ST1 --- CF
    ST2 --- CF
    ST3 --- CF
    C1 --- CF
    C2 --- CF
    C3 --- CF

    style cluster1 fill:#f3e5f5,stroke:#6a1b9a
    style cluster2 fill:#e8f5e9,stroke:#2e7d32
    style cluster3 fill:#e3f2fd,stroke:#1565c0
    style fabric fill:#f0f4ff,stroke:#336
```

### Spécialisation des clusters

| Cluster                      | Rôle                                                | Optimisé pour                                                                                   |
| ---------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Cluster 1 -- Contrôleurs** | Métadonnées de niveau 0, gestion du cluster         | Mémoire élevée (p. ex. 768 Go dans le RA Data-Science), NVMe à haute endurance pour le niveau 0 |
| **Cluster 2 -- Stockage**    | Tout le stockage des charges de travail (niveau 1+) | Densité de disques maximale, NVMe ou SSD SAS/SATA                                               |
| **Clusters 3+ -- Calcul**    | Charges de travail VM, matériel spécialisé          | Types de nœuds standard, GPU, haute mémoire ou personnalisés                                    |

### Avantages

* **Performances maximales** -- aucune contention des ressources entre stockage et calcul.
* **Mise à l'échelle indépendante complète** -- ajouter du stockage sans calcul (ou inversement).
* **Spécialisation matérielle** -- dimensionner le matériel selon le rôle (NVMe denses pour le stockage, GPU pour le calcul).
* **Isolation des charges de travail** -- différents clusters de calcul pour différents types de charges de travail.
* **Optimal pour les environnements à grande échelle et multi-locataires.**

### Limites

* La complexité opérationnelle la plus élevée des trois architectures.
* Minimum 6 nœuds (dérivé du minimum de 2 nœuds par cluster × 3 clusters : 2 contrôleurs + 2 stockage + 2 calcul).
* Planification des capacités plus complexe sur trois types de clusters.
* Exigences de bande passante plus élevées du core fabric entre les clusters.
* Des services professionnels sont recommandés pour le déploiement initial.

### Cas d'utilisation idéaux

| Scénario                                      | Pourquoi UCI fonctionne                                                         |
| --------------------------------------------- | ------------------------------------------------------------------------------- |
| Déploiements d'entreprise de 10 nœuds et plus | La mise à l'échelle indépendante évite le surdimensionnement                    |
| Charges de travail IA / HPC / GPU             | Clusters de calcul GPU dédiés, séparés du stockage                              |
| Fournisseurs de services cloud                | Optimiser les dépenses matérielles par niveau de ressource entre les locataires |
| Croissance axée stockage ou calcul            | Ne faire évoluer que ce qui croît                                               |

***

## Comparaison des architectures

| Aspect                            | HCI                | HCI + calcul (UCI hybride à 2 clusters) | UCI (Canonical 3-Cluster)               |
| --------------------------------- | ------------------ | --------------------------------------- | --------------------------------------- |
| **Nombre minimum de nœuds**       | 2                  | 4 (2 HCI + 2 calcul)                    | 6 (2+2+2)                               |
| **Nombre de clusters**            | 1                  | 2                                       | 3+                                      |
| **Performance**                   | Bon                | Meilleur                                | Optimal                                 |
| **Flexibilité matérielle**        | Faible             | Moyenne                                 | Maximale                                |
| **Mise à l'échelle indépendante** | Non                | Partielle (calcul uniquement)           | Complète                                |
| **Spécialisation**                | Aucune             | Calcul uniquement                       | Complète (contrôleur, stockage, calcul) |
| **Complexité**                    | Faible             | Moyenne                                 | Élevée                                  |
| **Efficacité des ressources**     | Variable           | Bon                                     | Maximale                                |
| **Meilleure adéquation**          | Petits, équilibrés | Taille moyenne, axés calcul             | Grands, spécialisés                     |

***

## Scénarios de déploiement Edge

Les clusters Edge sont des déploiements VergeOS compacts à 2 nœuds conçus pour des sites distants ou des succursales. Ils utilisent du matériel à faible consommation, au format compact, et sont directement connectés (aucun commutateur requis pour le core fabric).

### Configuration Edge typique

* **2 nœuds** directement connectés via deux NIC (core fabric).
* Matériel au format compact (Intel NUC, PC SFF 1L ou similaire).
* 2 To de NVMe pour les charges de travail + 4 To de SSD pour le stockage de masse par nœud.
* HA complète et redondance malgré une empreinte minimale.

```mermaid
graph LR
    N1["Nœud 1<br/>Contrôleur + Stockage + Calcul"] <-->|"Core Fabric<br/>(connexion directe)"| N2["Nœud 2<br/>Contrôleur + Stockage + Calcul"]
    N1 --- EXT["Réseau externe<br/>(uplink)"]
    N2 --- EXT

    style N1 fill:#e8f5e9,stroke:#2e7d32
    style N2 fill:#e8f5e9,stroke:#2e7d32
```

### Modèles de gestion Edge

VergeOS prend en charge trois scénarios de gestion Edge de sophistication croissante :

1. **Autonome avec gestion centralisée** -- des clusters à 2 nœuds sur chaque site, gérés de manière centralisée via le **Sites** tableau de bord. Les dépôts de catalogue distribuent les recettes de VM du cluster de gestion à tous les sites Edge.
2. **Sauvegarde et reprise après sinistre centralisées** -- idem, avec en plus un système central dans le centre de données principal qui fournit **Site Sync** la réplication, **ioGuardian** des serveurs de réparation et un stockage centralisé des instantanés pour tous les bureaux distants.
3. **Multi-niveaux avec archive** -- ajoute un cluster d'archivage secondaire sur un site de reprise après sinistre pour la rétention à long terme à l'aide de disques durs haute capacité, offrant une stratégie de sauvegarde complète 3-2-1.

### Quand recommander Edge

* Contraintes d'espace ou d'alimentation sur les sites distants.
* Applications qui stockent les données de manière centralisée mais ont besoin de calcul local.
* Organisations gérant 5--100+ sites distribués.
* Déploiements de succursales sensibles aux coûts.

***

## Scénarios CSP / multi-locataires

Les fournisseurs de services cloud exploitent la multi-location de VergeOS pour fournir de l'IaaS à partir d'une infrastructure partagée. Chaque locataire fonctionne comme un centre de données virtuel isolé (VDC) avec sa propre interface, ses réseaux, son stockage et ses contrôles d'accès.

### Configuration CSP typique

* **Clusters HCI à 6 nœuds** dans les centres de données principaux (serveurs haute densité, 768 Go+ de RAM par nœud).
* **Site Sync** entre les centres de données pour la reprise après sinistre.
* **ioGuardian** serveurs de réparation pour la récupération automatique des blocs depuis les sites distants.
* **Déduplication globale en ligne** réduit la consommation de stockage sur l'ensemble des instantanés répliqués.
* **Recettes de locataire** automatisent le provisionnement d'environnements client complets (locataire, réseaux, règles de pare-feu, VM, stockage).

### Parcours de croissance CSP

| Phase       | Déploiement                                                                                                           | Nœuds                         |
| ----------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
| **Phase 1** | 2 sites principaux avec reprise après sinistre via Site Sync                                                          | 6 par site                    |
| **Phase 2** | Ajouter des clusters Edge à 2 nœuds dans de nouvelles régions                                                         | 2 par région                  |
| **Phase 3** | Déployer les sites Edge en ajoutant des clusters (illustratif)                                                        | varie selon le site           |
| **Phase 4** | Ajouter des clusters de stockage dédiés pour les locataires à forte consommation de stockage et les niveaux d'archive | 2+ nœuds de stockage par site |

### Fonctionnalités clés de VergeOS pour les CSP

* **Multi-location** avec isolation complète entre les environnements client.
* **Gestion en libre-service** via l'interface web et l'API pour les administrateurs locataires.
* **Dépôts de catalogue** pour la gestion centralisée des recettes de VM.
* **Authentification OpenID** intégration avec les fournisseurs d'identité existants.
* **Recettes de locataire** pour une intégration client automatisée et reproductible.

***

## Aperçu des modèles de conception réseau

L'architecture de déploiement que vous choisissez influe sur la conception de votre réseau. VergeOS prend en charge plusieurs topologies réseau, détaillées dans [Module 4 : Réseautique](/learn-the-platform/fr/module-4-reseau/04-networking.md). Voici un bref aperçu pour orienter votre décision d'architecture :

| Modèle                        | NIC par nœud | Core Fabric                 | Réseau externe                     | Idéal pour                                      |
| ----------------------------- | ------------ | --------------------------- | ---------------------------------- | ----------------------------------------------- |
| **L2 statique + cœur dédié**  | 4            | 2 L2 dédiés                 | L2 agrégés (LACP)                  | Environnements de production, migrations VMware |
| **L3 dynamique + cœur dédié** | 4            | 2 L2 dédiés                 | annoncé via BGP / OSPF / EIGRP     | Grande échelle, segmentation avancée            |
| **L3 statique + cœur dédié**  | 4            | 2 L2 dédiés                 | L3 agrégés (routes statiques)      | Grande échelle, commutation de couche 3         |
| **L2 statique (2 NIC)**       | 2            | 2 partagées (balisées VLAN) | Partagé avec le cœur (balisé VLAN) | Edge, preuve de concept, petits déploiements    |

**Exigences clés communes à tous les modèles :**

* Les réseaux du core fabric doivent être sur **des segments Layer 2 dédiés** (isolés les uns des autres).
* Trames jumbo (**MTU 9216+**) sur tous les ports du commutateur du cœur de réseau.
* **Aucun saut de commutateur** entre les nœuds du cœur de réseau — tous les nœuds doivent se connecter au même tissu de commutation.
* STP désactivé sur les ports du cœur de réseau.

***

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

Vous venez de VMware ? VergeOS vous permet de faire évoluer le stockage et le calcul indépendamment au sein d’un seul système — les clusters de calcul uniquement consomment le vSAN partagé via le cœur de réseau, sans SAN/NAS externe ni produit de stockage séparé à licencier.
{% endhint %}

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

Vous venez de Nutanix ? VergeOS crée des clusters de stockage pur et des clusters de calcul pur dans un seul système — le stockage fonctionne comme un service intégré du système d’exploitation, donc aucune CVM ne consomme de RAM/CPU sur quelque type de nœud que ce soit.
{% endhint %}

## Résumé

| Concept          | Point clé                                                                                                      |
| ---------------- | -------------------------------------------------------------------------------------------------------------- |
| **HCI**          | Chaque nœud fait tout. Simple, rentable à petite échelle. Commencez ici.                                       |
| **HCI + Calcul** | UCI hybride à 2 clusters : contrôleur+stockage fusionnés, mise à l’échelle du calcul indépendante.             |
| **UCI**          | Architecture canonique à 3 clusters : contrôleur, stockage et calcul dédiés. Flexibilité maximale.             |
| **Edge**         | Clusters à connexion directe à 2 nœuds pour les sites distants, gérés de manière centralisée.                  |
| **CSP**          | Déploiements HCI multitenants avec reprise après sinistre Site Sync et automatisation des recettes locataires. |
| **Évolution**    | La même installation VergeOS prend en charge les trois modèles — évoluer de HCI vers UCI au fil du temps.      |

## Étapes suivantes

* [**Cadrage client**](/learn-the-platform/fr/module-2-dimensionnement-et-conception/03-customer-scoping.md) -- Apprenez la méthodologie de collecte des exigences afin de traduire les besoins du client en une recommandation d’architecture précise.
* [**Réseau**](/learn-the-platform/fr/module-4-reseau/04-networking.md) -- Approfondissez les modèles de conception réseau mentionnés ci-dessus.


---

# 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-2-dimensionnement-et-conception/02-reference-architectures.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.