> 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/05-clusters-nodes.md). # Clusters et types de nœuds ## Qu’est-ce qu’un cluster ? Un **cluster** dans VergeOS est un regroupement logique de nœuds ayant les mêmes caractéristiques matérielles, formant un pool de ressources présenté comme des actifs utilisables dans l’interface utilisateur VergeOS. Les clusters permettent une gestion efficace, la mise à l’échelle et une haute disponibilité pour les charges de travail virtualisées. Chaque système VergeOS commence avec au moins un cluster — les deux nœuds contrôleurs initiaux forment le premier cluster lors de l’installation. À partir de là, vous pouvez ajouter des nœuds au cluster existant ou créer des clusters supplémentaires avec différents rôles et profils matériels. ### Pourquoi les clusters sont importants Les clusters servent à plusieurs fins : * **Isolation du calcul** — le CPU, la mémoire et les charges de travail des VM sont liés à un cluster spécifique. Les VM s’exécutent uniquement sur les nœuds de leur cluster attribué (avec un basculement facultatif vers un autre cluster). * **Pool de stockage partagé** — les niveaux vSAN s’étendent à travers les clusters pour former un seul pool de stockage logique. Un disque de stockage sur le Cluster 1 et un disque de stockage sur le Cluster 2 peuvent tous deux contribuer au même niveau. Les nœuds de calcul uniquement accèdent à ce stockage partagé via la fabrique centrale. * **Optimisation matérielle** — différents clusters peuvent avoir différents profils matériels : nœuds à grande mémoire pour les bases de données, nœuds équipés de GPU pour le rendu, nœuds à forte densité NVMe pour les charges de travail intensives en stockage * **Mise à l’échelle indépendante** — ajoutez de la capacité de calcul à un cluster sans affecter les autres ; le stockage s’étend à l’ensemble du système ## Types de clusters VergeOS prend en charge trois types de clusters distincts qui peuvent être combinés dans un seul système : | Type de cluster | Fournit | Participation à vSAN | Cas d’utilisation typique | | ----------------------- | ------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------- | | **Combiné (HCI)** | Calcul + stockage | Oui — les nœuds fournissent des disques de stockage aux niveaux vSAN | Charges de travail généralistes, déploiements petits à moyens | | **Stockage uniquement** | Stockage uniquement | Oui — les nœuds fournissent uniquement du stockage | Extension de stockage dédiée dans les architectures UCI | | **Calcul uniquement** | Calcul uniquement | Non — démarrage uniquement ou démarrage PXE | Charges de calcul intensives (ML, rendu, analyse des données) | **Exemples de déploiement courants :** ```mermaid graph TB subgraph hci["HCI (cluster unique)"] N1["Contrôleur 1
Calcul + stockage"] N2["Contrôleur 2
Calcul + stockage"] N3["Scale-out
Calcul + stockage"] end subgraph hybrid["Hybride (2 clusters)"] H1["Contrôleur 1
Stockage + gestion"] H2["Contrôleur 2
Stockage + gestion"] HC1["Nœud de calcul 1"] HC2["Nœud de calcul 2"] end subgraph uci["UCI (3 clusters)"] U1["Contrôleur 1
Gestion"] U2["Contrôleur 2
Gestion"] US1["Nœud de stockage 1"] US2["Nœud de stockage 2"] UC1["Nœud de calcul 1"] UC2["Nœud de calcul 2"] end style N1 fill:#e3f2fd,stroke:#1565c0 style N2 fill:#e3f2fd,stroke:#1565c0 style N3 fill:#e3f2fd,stroke:#1565c0 style H1 fill:#e3f2fd,stroke:#1565c0 style H2 fill:#e3f2fd,stroke:#1565c0 style HC1 fill:#fff3e0,stroke:#e65100 style HC2 fill:#fff3e0,stroke:#e65100 style U1 fill:#e3f2fd,stroke:#1565c0 style U2 fill:#e3f2fd,stroke:#1565c0 style US1 fill:#e8f5e9,stroke:#2e7d32 style US2 fill:#e8f5e9,stroke:#2e7d32 style UC1 fill:#fff3e0,stroke:#e65100 style UC2 fill:#fff3e0,stroke:#e65100 ``` ## Types de nœuds Chaque serveur physique dans un système VergeOS est un **nœud**. Les nœuds diffèrent par la manière dont ils rejoignent le système, le rôle qu’ils jouent et le cluster auquel ils appartiennent. VergeOS définit quatre types de nœuds : ### Nœuds contrôleurs Chaque système VergeOS commence avec au moins deux **nœuds contrôleurs**. Un troisième nœud contrôleur est requis pour la redondance N+2. Ils sont spéciaux parce que : * **Nœud 1** crée un tout nouveau système VergeOS. Il initialise le vSAN, crée le premier cluster et exécute la configuration post-installation (configuration réseau, création de cluster pour d’autres types de nœuds, etc.) * **Nœud 2** rejoint le système créé par le Nœud 1 en tant que deuxième contrôleur, fournissant une redondance pour toutes les fonctions de gestion du système (N+1) * **Nœud 3 (facultatif)** — un troisième nœud contrôleur peut être ajouté pour une redondance N+2, permettant au système de tolérer deux pannes de nœud simultanées Les nœuds contrôleurs appartiennent toujours au **Cluster 1**. Dans une topologie HCI, ils fournissent à la fois le calcul et le stockage. Dans une topologie hybride, ils fournissent généralement **uniquement le stockage et la gestion** — aucune VM de production — tandis qu’un cluster de calcul séparé gère toutes les charges de travail. Dans une topologie UCI complète, ils gèrent le système mais délèguent le stockage et le calcul à des clusters dédiés. Le premier cluster doit inclure au moins deux nœuds avec du **stockage de niveau 0** (disques de métadonnées) — c’est une exigence impérative, car le niveau 0 contient l’index du système de fichiers vSAN et doit être redondant. ### Nœuds de scale-out Les nœuds de scale-out étendent un cluster HCI existant en ajoutant davantage de capacité de calcul et de stockage. Caractéristiques principales : * **Matériel identique** à celui des nœuds contrôleurs du cluster qu’ils rejoignent (même génération de CPU, disposition de stockage similaire, configuration NIC correspondante) * Installez via USB et sélectionnez le type de nœud Scale-Out. L’installateur détecte automatiquement la fabrique centrale, puis l’opérateur s’authentifie avec des identifiants administrateur. Si plusieurs clusters existent, l’opérateur sélectionne également le cluster cible et un nœud de référence pour comparer le matériel * Les disques rejoignent automatiquement les niveaux vSAN existants * Fournissent à la fois du calcul (exécuter des VM) et du stockage (participation à vSAN) Les nœuds de scale-out sont la manière la plus simple de faire croître un déploiement HCI — ajoutez un nœud et la capacité de calcul et de stockage du cluster augmente proportionnellement. ### Nœuds de stockage uniquement Les nœuds de stockage uniquement sont dédiés exclusivement à l’extension de la capacité vSAN. Ils : * Fournissent des disques aux niveaux vSAN mais ne **pas** exécutent des charges de travail VM * Appartiennent à un **cluster de stockage uniquement** (par ex., Cluster 2) * Nécessitent de créer le cluster de stockage dans l’interface VergeOS avant d’ajouter le premier nœud de stockage * Sont utilisés dans les architectures UCI où le stockage et le calcul évoluent indépendamment ### Nœuds de calcul uniquement Les nœuds de calcul uniquement fournissent de la puissance de traitement sans participer au stockage vSAN. Ils : * Exécutent des charges de travail VM mais n’ont **aucun stockage vSAN local** (disque de démarrage uniquement ou démarrage PXE) * Appartiennent à un **cluster de calcul uniquement** (par ex., Cluster 3) * Nécessitent de créer le cluster de calcul dans l’interface VergeOS avant d’ajouter le premier nœud de calcul * Accèdent au stockage via la fabrique centrale depuis les nœuds des clusters HCI ou de stockage uniquement Les nœuds de calcul uniquement sont idéaux pour les charges de travail qui nécessitent une forte densité CPU/RAM/GPU sans croissance proportionnelle du stockage — apprentissage automatique, rendu, analyse de données ou VDI. ### Résumé des types de nœuds | Type de nœud | Rôle | Cluster | vSAN | Exécute des VM | Méthode d’intégration | | ----------------------- | ---------------------------------------- | ---------- | --------------------------------------------- | ---------------------- | ---------------------------------------------- | | **Contrôleur (Nœud 1)** | Crée un nouveau système | Cluster 1 | Oui (niveau 0 + niveaux de charge de travail) | Oui (HCI) ou Non (UCI) | Création d’un nouveau système | | **Contrôleur (Nœud 2)** | Rejoint en tant que contrôleur redondant | Cluster 1 | Oui (niveau 0 + niveaux de charge de travail) | Oui (HCI) ou Non (UCI) | Rejoint le Cluster 1 | | **Scale-out** | Ajoute de la capacité HCI | Cluster 1 | Oui (niveaux de charge de travail) | Oui | Détection automatique sur la fabrique centrale | | **Stockage uniquement** | Extension de stockage dédiée | Cluster 2+ | Oui (niveaux de charge de travail) | Non | Rejoint le cluster de stockage désigné | | **Calcul uniquement** | Extension de calcul dédiée | Cluster 2+ | Non (démarrage uniquement / PXE) | Oui | Rejoint le cluster de calcul désigné | {% hint style="info" %} **Vous venez de VMware ou de Nutanix ?** Aucune des deux plateformes n’a de concept natif de membres de stockage uniquement ou de calcul uniquement au sein d’un même cluster. VergeOS en a un, et il vous permet de typer les clusters pour une mise à l’échelle indépendante. Les clusters VMware et Nutanix sont uniformes ; les clusters VergeOS peuvent être HCI, stockage uniquement ou calcul uniquement, et un système peut combiner plusieurs clusters typés. {% endhint %} | Rôle de nœud VergeOS | Analogue le plus proche dans VMware vSphere | Analogue le plus proche dans Nutanix | | -------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Contrôleur | Hôte ESXi + services vCenter (pas d’appliance séparée) | Premier nœud dans un cluster ; les contrôleurs VergeOS s’exécutent sur du bare metal, pas dans un CVM | | Scale-out | Hôte ESXi supplémentaire rejoignant un cluster vSAN | Nœud supplémentaire rejoignant un cluster Nutanix | | Stockage uniquement | Aucun équivalent natif (le témoin vSAN est le plus proche) | Aucun équivalent — chaque nœud Nutanix exécute un CVM et participe au calcul | | Calcul uniquement | Hôte ESXi sans vSAN local, montant un stockage externe (ici, vSAN via la fabrique centrale) | Aucun équivalent direct | ## Comment les nœuds rejoignent un système Le processus de jonction des nœuds suit une séquence stricte pour éviter les conditions de concurrence : ```mermaid flowchart TD A["Nœud 1 (Contrôleur)
Crée un nouveau système VergeOS
Initialise vSAN, crée le Cluster 1"] --> B["Nœud 2 (Contrôleur)
Rejoint le Cluster 1
Établit la paire HA"] B --> C{"Nœuds supplémentaires ?"} C -->|"Scale-out"| D["Nœuds de scale-out
Détection automatique du système sur la fabrique centrale
Rejoignent le Cluster 1 séquentiellement"] C -->|"Stockage uniquement"| E["Créer un cluster de stockage
(Cluster 2 dans l’interface)"] C -->|"Calcul uniquement"| F["Créer un cluster de calcul
(Cluster 2 ou 3 dans l’interface)"] E --> G["Nœuds de stockage
Rejoignent le cluster de stockage séquentiellement"] F --> H["Nœuds de calcul
Rejoignent le cluster de calcul séquentiellement"] G --> F style A fill:#e3f2fd,stroke:#1565c0 style B fill:#e3f2fd,stroke:#1565c0 style D fill:#e3f2fd,stroke:#1565c0 style G fill:#e8f5e9,stroke:#2e7d32 style H fill:#fff3e0,stroke:#e65100 ``` Règles clés pour la jonction des nœuds : 1. **Le Nœud 1 doit terminer l’installation** avant que le Nœud 2 puisse rejoindre — le Nœud 2 a besoin d’un système existant auquel se connecter 2. **Les nœuds rejoignent séquentiellement** au sein d’un cluster — Nœud 3 après Nœud 2, Nœud 4 après Nœud 3, etc. — pour éviter les conditions de concurrence lors des changements d’appartenance au cluster 3. **Les clusters de stockage doivent exister** avant que les nœuds de stockage puissent rejoindre — créez d’abord le cluster dans l’interface VergeOS 4. **Les clusters de calcul doivent exister** avant que les nœuds de calcul puissent rejoindre — même prérequis 5. **Si vous déployez à la fois des clusters de stockage et de calcul**, les nœuds de stockage doivent être ajoutés en premier afin que les nœuds de calcul puissent accéder immédiatement au stockage vSAN ## Numérotation et nommage des clusters Les clusters sont numérotés à partir de 1, mais le **nom est libre** — vous pouvez appeler un cluster comme vous le souhaitez et le renommer à tout moment dans l’interface VergeOS. Les noms ci-dessous ne sont que des conventions courantes, pas des valeurs obligatoires : | Numéro du cluster | Rôle par défaut | Nom typique | | ----------------- | -------------------------------------------------------------- | ------------------------------------ | | Cluster 1 | HCI (contrôleurs + scale-out facultatif) | "HCI", "Par défaut" ou "Contrôleurs" | | Cluster 2 | Stockage uniquement (si UCI) ou calcul uniquement (si hybride) | "Stockage" ou "Calcul" | | Cluster 3 | Calcul uniquement (dans une UCI complète avec 3 clusters) | "Calcul" | Dans un déploiement UCI complet avec 3 clusters : * **Cluster 1**: Contrôleurs (gestion du système, métadonnées de niveau 0) * **Cluster 2**: Nœuds de stockage (tout le stockage des charges de travail vSAN) * **Cluster 3**: Nœuds de calcul (exécution de toutes les VM) ## Exigences minimales et haute disponibilité | Exigence | Détail | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Nombre minimal de nœuds par système** | 2 (une paire de contrôleurs) | | **Nombre minimal de nœuds par cluster** | 2 (pour la redondance pendant la maintenance ou en cas de panne) | | **Nœuds contrôleurs** | Minimum 2 par système (N+1 par défaut) ; 3 requis pour une redondance N+2 — doivent disposer d’un stockage de niveau 0 pour les métadonnées vSAN | | **Comportement HA** | Si un nœud tombe en panne, ses charges de travail migrent vers le ou les nœuds survivants du même cluster | | **Mode de maintenance** | Les nœuds peuvent être placés en mode de maintenance ; les charges de travail sont migrées à chaud vers d’autres nœuds du cluster avant le début de la maintenance | ## Mise à l’échelle Les systèmes VergeOS passent d’un cluster HCI minimal à 2 nœuds à des déploiements multi-clusters. Tous les nœuds doivent partager la **même fabrique de commutation** avec **zéro saut de commutateur** entre eux (objectif de latence inférieur à 0,05 ms). Un seul rack est la manière la plus simple de respecter cette exigence. Les déploiements multi-racks sont possibles, mais chaque fabrique centrale doit toujours se terminer sur un seul commutateur — faites revenir des câbles plus longs vers la même paire de commutateurs de fabrique plutôt que d’étendre la fabrique sur plusieurs commutateurs (MLAG/stacking est destiné au réseau externe, pas à la fabrique centrale). La stratégie de mise à l’échelle dépend de votre architecture : ### Mise à l’échelle HCI (simple) Ajoutez des nœuds de scale-out au Cluster 1. Chaque nœud ajoute proportionnellement du calcul et du stockage. ```mermaid graph LR subgraph "Début : HCI à 2 nœuds" A1["Nœud 1"] --- A2["Nœud 2"] end subgraph "Croissance : HCI à 4 nœuds" B1["Nœud 1"] --- B2["Nœud 2"] B3["Nœud 3"] --- B4["Nœud 4"] B1 --- B3 B2 --- B4 end subgraph "Mise à l’échelle : HCI à 8 nœuds et plus" C1["Nœuds 1-2
(Contrôleurs)"] C2["Nœuds 3-8
(Scale-out)"] end ``` **Idéal pour**: croissance équilibrée où les besoins en calcul et en stockage augmentent ensemble. ### Mise à l’échelle UCI (indépendante) Ajoutez des nœuds à des clusters spécifiques selon la ressource qui constitue le goulot d’étranglement : * **Besoin de plus de stockage ?** Ajoutez des nœuds au cluster de stockage * **Besoin de plus de calcul ?** Ajoutez des nœuds au cluster de calcul * **Besoin de plus des deux ?** Ajoutez indépendamment aux deux clusters **Idéal pour**: charges de travail aux besoins en ressources déséquilibrés (par ex., stockage important avec peu de calcul, ou calcul à forte densité GPU avec un stockage modeste). ### Bonnes pratiques pour la mise à l’échelle * **Cohérence matérielle au sein des clusters** — utilisez les mêmes spécifications matérielles pour tous les nœuds d’un cluster. Mélanger du matériel différent au sein d’un cluster peut entraîner des problèmes de performance et de fiabilité. * **Prévoyez une redondance N+1** — dimensionnez chaque cluster de sorte qu’en cas de perte d’un nœud, la capacité restante soit encore suffisante pour toutes les charges de travail * **Surveillez avant de mettre à l’échelle** — utilisez les métriques du tableau de bord VergeOS (utilisation CPU, utilisation RAM, capacité vSAN) pour identifier la ressource à étendre * **Mettez à l’échelle sans interruption** — de nouveaux nœuds peuvent être ajoutés à un système en cours d’exécution sans interrompre les charges de travail existantes ## Exemples de topologies de déploiement Topologies courantes correspondant à des modèles de déploiement réels : | Topologie | Nœuds | Clusters | Quand l’utiliser | | -------------------------- | --------------------------------------------- | ---------------------------------------- | -------------------------------------------------------------------------- | | **HCI à 2 nœuds** | 2 contrôleurs | 1 (HCI) | Petits sites, edge, PoC, évaluation de base | | **HCI + Scale-out** | 2 contrôleurs + N scale-out | 1 (HCI) | Déploiements HCI en croissance nécessitant une mise à l’échelle équilibrée | | **Hybride (2 clusters)** | 2 contrôleurs + N calcul | 2 (Stockage + Calcul) | Charges de travail à forte intensité de calcul avec un stockage modeste | | **UCI (3 clusters)** | 2 contrôleurs + N stockage + M calcul | 3 (Contrôleur + Stockage + Calcul) | Mise à l’échelle indépendante du calcul et du stockage | | **UCI + GPU (4 clusters)** | 2 contrôleurs + N stockage + M calcul + G GPU | 4 (Contrôleur + Stockage + Calcul + GPU) | IA/ML, rendu, ou VDI avec des nœuds GPU dédiés | ```mermaid graph TB subgraph "HCI à 2 nœuds" direction LR H1["Contrôleur 1
HCI"] --- H2["Contrôleur 2
HCI"] end subgraph "HCI + Scale-out" direction LR S1["Contrôleur 1"] --- S2["Contrôleur 2"] S3["Scale-out 1"] --- S4["Scale-out 2"] end subgraph "Hybride (2 clusters)" direction LR subgraph "Cluster 1 (Stockage)" Y1["Contrôleur 1"] Y2["Contrôleur 2"] end subgraph "Cluster 2 (Calcul)" Y3["Calcul 1"] Y4["Calcul 2"] end end subgraph "UCI + GPU (4 clusters)" direction LR subgraph "Cluster 1 (Ctrl)" U1["Ctrl 1"] U2["Ctrl 2"] end subgraph "Cluster 2 (Stockage)" U3["Stockage 1"] U4["Stockage 2"] end subgraph "Cluster 3 (Calcul)" U5["Calcul 1"] U6["Calcul 2"] end subgraph "Cluster 4 (GPU)" G1["Nœud GPU 1"] G2["Nœud GPU 2"] end end ``` ## Points clés | Concept | Résumé | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Cluster** | Groupement logique de nœuds ayant le même matériel, formant un pool de ressources | | **Trois types de clusters** | HCI (calcul + stockage), stockage seul, calcul seul — combinables au sein d’un même système | | **Quatre types de nœuds** | Contrôleur, montée en charge, stockage seul, calcul seul — chacun avec un rôle et une méthode d’intégration spécifiques | | **Minimum 2 nœuds** | Par cluster pour la redondance ; les contrôleurs nécessitent un stockage de niveau 0 | | **Intégration séquentielle** | Les nœuds rejoignent le cluster un par un afin d’éviter les conditions de concurrence | | **Cohérence matérielle** | Tous les nœuds d’un cluster doivent avoir des spécifications matérielles identiques | | **Mise à l’échelle indépendante** | L’architecture UCI permet d’ajouter indépendamment des capacités de calcul ou de stockage | | **Mise à l’échelle** | Les systèmes passent d’un HCI à 2 nœuds à des déploiements multi-clusters au sein d’un seul plan de commutation | ## Étapes suivantes Vous comprenez maintenant comment VergeOS organise les nœuds en clusters et comment différents types de nœuds remplissent différents rôles. Dans le laboratoire pratique, vous explorerez ces concepts à l’aide du playground Terraform : [**Lab : exploration de l’architecture →**](/learn-the-platform/fr/module-1-fondamentaux-de-larchitecture/lab.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/05-clusters-nodes.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.