> 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/lab.md). # Atelier : Explorer l’architecture ## Aperçu du laboratoire Dans ce laboratoire, vous explorerez le **Bac à sable Terraform VergeOS** — un projet open source qui déploie des systèmes VergeOS virtuels à l’aide de Terraform. En lisant le code et la documentation, vous renforcerez les concepts d’architecture abordés dans ce module : réseau core fabric, niveaux de stockage vSAN, organisation des clusters et topologies HCI vs UCI. ### Ce que vous ferez * **Partie 1** — Lisez la documentation d’architecture du bac à sable et le code Terraform pour identifier comment les concepts VergeOS se traduisent en infrastructure as code * **Partie 2** — À partir d’un scénario client, recommandez et schématisez une topologie de déploiement * **Partie 3** — Comparez les quatre configurations de déploiement exemples et analysez leurs différences ### Prérequis * Un compte GitHub (pour cloner le dépôt) * Git installé sur votre poste de travail * Un éditeur de texte ou un IDE (VS Code recommandé) * Aucun accès à un système VergeOS n’est requis — ce laboratoire est un exercice de lecture et de conception ### Temps estimé **30 minutes** *** ## Partie 1 : Explorez l’architecture Dans cette section, vous clonerez le dépôt du bac à sable Terraform et suivrez la façon dont les concepts d’architecture VergeOS sont exprimés en infrastructure as code. 1. **Clonez le dépôt** ```bash git clone https://github.com/verge-io/vergeos-terraform-playground.git cd vergeos-terraform-playground ``` 2. **Lisez la documentation d’architecture** Ouvrez `docs/architecture.md` et lisez l’intégralité du document. En le lisant, identifiez les réponses à ces questions : * Quels sont les **quatre scénarios de déploiement** pris en charge par le bac à sable ? * Qu’est-ce qu’un **fichier de seed d’installation** et comment permet-il une installation sans surveillance ? * Quel est le **déploiement minimal** ? > **Indice :** Les quatre scénarios sont listés dans `docs/deployment-scenarios.md` avec des diagrammes de topologie. Le déploiement minimal est constitué de deux nœuds contrôleurs formant un seul cluster HCI. 3. **Examinez les diagrammes des scénarios de déploiement** Ouvrez `docs/deployment-scenarios.md` et étudiez les diagrammes de topologie Mermaid pour chaque scénario. Pour chacun, notez : * Combien de **nœuds** sont impliqués * Combien de **clusters** sont créés * Quels **types de nœuds** apparaissent (contrôleur, scale-out, stockage, calcul) * Comment tous les nœuds se connectent au **core fabric** et **réseau externe** 4. **Suivez le core fabric dans Terraform** Ouvrez `main.tf` (le module racine) et repérez les deux ressources réseau core fabric. Répondez à ces questions : * Comment s’appellent les ressources ? (`core_fabric_1` et `core_fabric_2`) * Qu’est-ce qui **MTU** est configuré ? (9142 — trames jumbo pour la réplication vSAN) * DHCP est-il activé sur ces réseaux ? (Non — `dhcp_enabled = false`) * Qu’est-ce qui `type d’adresse IP` est défini ? (`aucun` — ce sont des transports de couche 2) ```hcl # Vous devriez trouver des ressources comme celle-ci dans main.tf : resource "vergeio_network" "core_fabric_1" { name = "${var.system_name}-core-fabric-1" enabled = true dhcp_enabled = false on_power_loss = "power_on" mtu = 9142 ipaddress_type = "none" } ``` 5. **Examinez en quoi le nœud 1 diffère du nœud 2** Ouvrez `modules/controllers/main.tf` et comparez `verge_node_1` et `verge_node_2`. Principales différences à identifier : * **Modèle cloud-init** — Le nœud 1 utilise `user-data-node1.yaml` (crée un nouveau système avec `YC_VSAN_NEW=1`). Le nœud 2 utilise `user-data-node2.yaml` (rejoint le système existant avec `YC_VSAN_NEW=0`). * **Configuration de l’API après installation** — Le cloud-init du nœud 1 inclut un script qui configure les sources de mise à jour, active SSH et crée éventuellement des clusters de stockage/de calcul via l’API VergeOS. Le nœud 2 n’a pas de script post-installation. * **Chaîne de dépendances** — Le nœud 2 a une `depends_on` référence au nœud 1, garantissant que le système est entièrement initialisé avant que le deuxième contrôleur n’essaie de rejoindre le cluster. Les deux nœuds partagent la même structure de VM : famille d’OS Linux, virtualisation imbriquée activée, trois cartes NIC virtio (externe, core fabric 1, core fabric 2), CD-ROM avec l’ISO VergeOS et une source de données cloud-init nocloud. 6. **Répondez aux questions de compréhension** Écrivez vos réponses aux questions suivantes (ou discutez-en avec votre binôme de formation) : | # | Question | Réponse attendue | | - | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Pourquoi le core fabric utilise-t-il deux commutateurs distincts ? | Redondance — si un commutateur ou un chemin tombe en panne, l’autre maintient la connectivité entre nœuds | | 2 | Pourquoi DHCP est-il désactivé sur les réseaux core fabric ? | Le core fabric utilise une adressage IP statique ; l’installateur VergeOS configure les adresses via le seed d’installation | | 3 | Pourquoi le nœud 2 doit-il attendre que le nœud 1 soit terminé avant de démarrer ? | Le nœud 1 crée le système VergeOS ; le nœud 2 a besoin d’un système existant à rejoindre | | 4 | Quels types de trafic circulent sur le core fabric ? | Réplication vSAN, coordination du cluster, migration à chaud des VM, communication du plan de contrôle | | 5 | Pourquoi `quantity_tier_1_disks` défini à 0 pour les contrôleurs lorsque des nœuds de stockage sont activés ? | En mode UCI, des nœuds de stockage dédiés fournissent toute la capacité de niveau 1 ; les contrôleurs n’ont besoin que du niveau 0 pour les métadonnées | *** ## Partie 2 : Exercice de conception Appliquez maintenant ce que vous avez appris. À partir d’un scénario client, recommandez une topologie de déploiement et justifiez votre décision. ### Scénario client > **Midwest Manufacturing Co.** migre depuis un environnement VMware vSphere avec 3 hôtes ESXi. Ils exécutent actuellement 50 VM (mélange de Windows et Linux), disposent d’environ 10 To de stockage utilisable et prévoient une croissance modérée au cours des 2 prochaines années. Leur équipe informatique est petite (2 personnes) et ils souhaitent minimiser la complexité opérationnelle. Le budget est contraint. 1. **Choisissez HCI ou UCI** En fonction du profil client, quel modèle de déploiement recommandez-vous ? Tenez compte de : * **Taille de l’équipe** — Une équipe informatique de 2 personnes privilégie la simplicité * **Profil de croissance** — « Croissance modérée » suggère une mise à l’échelle équilibrée du calcul et du stockage * **Budget** — HCI nécessite moins de nœuds au total que UCI pour la même capacité * **Environnement actuel** — 3 hôtes ESXi se traduisent bien par un petit cluster HCI > **Réponse recommandée :** **HCI** convient mieux. La petite équipe bénéficie d’une architecture plus simple (un seul type de cluster), la mise à l’échelle équilibrée correspond à leur croissance modérée, moins de nœuds réduisent les coûts et HCI reflète étroitement leur modèle de cluster VMware existant. 2. **Déterminez le nombre de nœuds et la topologie** Dessinez ou décrivez la topologie proposée : * Combien de **nœuds contrôleurs**? (Minimum 2 pour la HA) * Avez-vous besoin de **nœuds d'extension**? (À considérer : 50 VM sur 2 nœuds peut être serré ; 2 nœuds scale-out offrent de la marge) * Combien de **clusters**? (1 pour HCI) * Qu’en est-il de **capacité de stockage**? (10 To utilisables signifie environ 20 To bruts avec réplication entre les nœuds) Une conception raisonnable : ```mermaid graph TB sous-graphe "Cluster 1 (HCI)" N1["Nœud 1 — Contrôleur
Stockage + Calcul"] N2["Nœud 2 — Contrôleur
Stockage + Calcul"] N3["Nœud 3 — Scale-out
Stockage + Calcul"] N4["Nœud 4 — Scale-out
Stockage + Calcul"] end CF["Core Fabric (deux commutateurs)"] EXT["Réseau externe"] N1 --- CF N2 --- CF N3 --- CF N4 --- CF N1 --- EXT N2 --- EXT N3 --- EXT N4 --- EXT ``` 3. **Faites correspondre à un exemple du playground** Quel fichier d’exemple du playground Terraform correspond le mieux à votre conception ? > **Réponse :** **`examples/4-node-hci.tfvars`** — 2 contrôleurs + 2 nœuds scale-out dans un seul cluster HCI. Cela correspond à la conception HCI à 4 nœuds recommandée pour une mise à l’échelle équilibrée du calcul et du stockage. *** ## Partie 3 : Comparaison des topologies Comparez les quatre exemples `.tfvars` fichiers du `examples/` répertoire. Remplissez le tableau comparatif ci-dessous. ### Instructions Ouvrez chaque fichier et identifiez les valeurs de configuration. Utilisez le tableau pour consigner vos observations. {% tabs %} {% tab title="2-node-hci.tfvars" %} **Fichier :** `examples/2-node-hci.tfvars` * **Scénario :** HCI à 2 nœuds (cluster unique) * **Nombre total de nœuds :** 2 * **Clusters :** 1 * **Types de nœuds :** 2 contrôleurs (stockage + calcul) * **Variables de bascule :** Aucune (toutes les valeurs par défaut) * **Disques de niveau 1 sur les contrôleurs :** Oui (2 × 1000 Go chacun) * **Idéal pour :** Tests de base, évaluation, déploiement le plus petit possible {% endtab %} {% tab title="4-node-hci.tfvars" %} **Fichier :** `examples/4-node-hci.tfvars` * **Scénario :** HCI + scale-out (cluster unique) * **Nombre total de nœuds :** 4 * **Clusters :** 1 * **Types de nœuds :** 2 contrôleurs + 2 nœuds scale-out * **Variables de bascule :** `create_scale_out_nodes = true` * **Disques de niveau 1 sur les contrôleurs :** Oui (2 × 1000 Go chacun) * **Idéal pour :** Clusters HCI plus grands, test du comportement scale-out, croissance équilibrée {% endtab %} {% tab title="4-node-hybrid.tfvars" %} **Fichier :** `examples/4-node-hybrid-hci-2-cluster.tfvars` * **Scénario :** HCI hybride (2 clusters) * **Nombre total de nœuds :** 4 * **Clusters :** 2 * **Types de nœuds :** 2 contrôleurs (stockage + calcul) + 2 nœuds calcul uniquement * **Variables de bascule :** `create_compute_nodes = true` * **Disques de niveau 1 sur les contrôleurs :** Oui (les contrôleurs fournissent tout le stockage) * **Idéal pour :** Séparer la mise à l’échelle du calcul du stockage, ajouter une capacité de pointe pour le calcul {% endtab %} {% tab title="6-node-uci.tfvars" %} **Fichier :** `examples/6-node-uci-3-cluster.tfvars` * **Scénario :** UCI (3 clusters) * **Nombre total de nœuds :** 6 * **Clusters :** 3 * **Types de nœuds :** 2 contrôleurs + 2 stockage uniquement + 2 calcul uniquement * **Variables de bascule :** `create_storage_nodes = true`, `create_compute_nodes = true` * **Disques de niveau 1 sur les contrôleurs :** Non (les nœuds de stockage fournissent toute la capacité de niveau 1) * **Idéal pour :** UCI de type production, mise à l’échelle indépendante du stockage et du calcul, environnements plus grands {% endtab %} {% endtabs %} ### Tableau récapitulatif de comparaison Complétez ce tableau au fur et à mesure de l’examen de chaque fichier : | Attribut | HCI à 2 nœuds | HCI 4 nœuds | Hybride 2 clusters | UCI 3 clusters | | ----------------------------------------------------- | --------------------- | ------------------------- | --------------------------- | ------------------------------------- | | **Nombre total de nœuds** | 2 | 4 | 4 | 6 | | **Clusters** | 1 | 1 | 2 | 3 | | **Nœuds contrôleurs** | 2 | 2 | 2 | 2 | | **Nœuds scale-out** | 0 | 2 | 0 | 0 | | **Nœuds de stockage uniquement** | 0 | 0 | 0 | 2 | | **Nœuds de calcul uniquement** | 0 | 0 | 2 | 2 | | **Les contrôleurs ont-ils des disques de niveau 1 ?** | Oui | Oui | Oui | Non | | **Mise à l’échelle du stockage** | Ajouter des nœuds HCI | Ajouter des nœuds HCI | Ajouter des contrôleurs | Ajouter des nœuds de stockage | | **Mise à l’échelle du calcul** | Ajouter des nœuds HCI | Ajouter des nœuds HCI | Ajouter des nœuds de calcul | Ajouter des nœuds de calcul | | **Complexité** | Faible | Faible | Moyenne | Élevée | | **Cas d’utilisation idéal** | Petit / évaluation | Taille moyenne équilibrée | Pic de calcul | Grand / mise à l’échelle indépendante | ### Questions d’analyse Une fois le tableau rempli, réfléchissez aux questions suivantes : 1. **Pourquoi les contrôleurs du scénario UCI ont-ils zéro disque de niveau 1 ?** > En UCI, des nœuds de stockage dédiés fournissent tout le stockage des charges de travail. Les contrôleurs n’ont besoin que de disques de niveau 0 pour les métadonnées vSAN. Cela est visible dans `main.tf` où `quantity_tier_1_disks` est conditionnellement défini à 0 lorsque `create_storage_nodes = true`. 2. **Quelle est la chaîne de dépendances lorsque les nœuds de stockage et de calcul sont tous deux activés ?** > Contrôleurs → Nœuds de stockage → Nœuds de calcul. Le module de calcul a une `depends_on` référence explicite vers le module de stockage, garantissant que le cluster de stockage existe avant que les nœuds de calcul n’essaient de rejoindre le cluster. Cela reflète le fonctionnement de la création de cluster VergeOS : le stockage doit être disponible avant que les charges de travail de calcul puissent s’exécuter. 3. **Comment modifieriez-vous l’exemple HCI à 4 nœuds pour prendre en charge 6 nœuds HCI ?** > Modifiez `quantity_scale_out_nodes` de `2` vers `4`. Le module Terraform crée des nœuds scale-out supplémentaires de manière séquentielle, chacun rejoignant le même cluster HCI. Aucune variable de bascule supplémentaire n’est nécessaire. *** ## Points clés Après avoir terminé ce laboratoire, vous devriez être capable de : * ✅ Naviguer dans le bac à sable Terraform VergeOS et comprendre sa structure * ✅ Identifier comment les réseaux core fabric, les niveaux de stockage vSAN et les types de nœuds sont exprimés dans Terraform * ✅ Expliquer les différences entre les quatre scénarios de déploiement (HCI à 2 nœuds, HCI à 4 nœuds, hybride 2 clusters, UCI 3 clusters) * ✅ Recommander une topologie VergeOS appropriée pour un scénario client donné * ✅ Suivre la chaîne de dépendances des contrôleurs aux types de nœuds optionnels ## Étapes suivantes Passez à [**Module 2 : Dimensionnement et conception**](/learn-the-platform/fr/module-2-dimensionnement-et-conception/02-sizing-design.md) pour apprendre à traduire les exigences client en configurations matérielles spécifiques et en plans de déploiement. --- # 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/lab.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.