Lab : explorer l’architecture

Exploration pratique des topologies de déploiement VergeOS à l’aide du terrain d’essai Terraform. Suivre les modèles d’infrastructure as code, comparer les scénarios et concevoir une topologie pour un cas d’usage client.

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.

Clonez le dépôt

git clone https://github.com/verge-io/vergeos-terraform-playground.git
cd vergeos-terraform-playground

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.
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
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)
```
# 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"
}
```
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.
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.

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

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

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

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

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

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

Clusters

Nœuds contrôleurs

Nœuds scale-out

Nœuds de stockage uniquement

Nœuds de calcul uniquement

Les contrôleurs ont-ils des disques de niveau 1 ?

Oui

Non

Mise à l’échelle du stockage

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 de calcul

Complexité

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 :

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.
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.
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 pour apprendre à traduire les exigences client en configurations matérielles spécifiques et en plans de déploiement.

PrécédentClusters et types de nœuds

SuivantAperçu

Mis à jour il y a 2 mois

Ce contenu vous a-t-il été utile ?