> 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/03-customer-scoping.md).
# Cadrage client
Un déploiement VergeOS bien cadré commence bien avant que le premier nœud ne soit installé en baie. Cette page fournit une méthodologie structurée pour recueillir les besoins du client, traduire les charges de travail en estimations de ressources VergeOS, planifier les configurations des nœuds locataire et sélectionner la bonne topologie de déploiement. À la fin de ce processus, vous devriez disposer d’un ensemble complet de livrables documentaires que tout ingénieur VergeOS peut utiliser pour réaliser l’installation.
## Liste de contrôle de collecte des besoins
Chaque mission de cadrage doit commencer par la collecte des informations suivantes auprès du client. Utilisez cette liste comme guide de conversation lors des réunions de découverte.
### Inventaire des charges de travail actuelles
| Point de données | Pourquoi c’est important |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| **Nombre total de VM** | Établit l’échelle du déploiement et influence le choix de l’architecture |
| **Cœurs CPU par VM** | Détermine la taille du cluster de calcul et identifie les cas extrêmes gourmands en CPU |
| **Allocation de RAM par VM** | La RAM est généralement la ressource limitante ; elle détermine le nombre de nœuds |
| **Stockage par VM (alloué et utilisé)** | Distingue la capacité en provisionnement fin de la consommation réelle |
| **Exigences en IOPS / latence du stockage** | Identifie les charges de travail qui exigent du NVMe par rapport à celles qui tolèrent du SSD SAS/SATA |
| **Besoins en GPU ou en matériel spécialisé** | Détermine si les clusters de calcul ont besoin de périphériques en passthrough |
| **Mélange de systèmes d’exploitation** | Windows, Linux, BSD — influence la planification des pilotes et des intégrations |
### Prévisions de croissance
* **Prévisions à 6 mois, 12 mois et 24 mois** pour le nombre de VM, le CPU, la RAM et le stockage.
* **Modèle de croissance :** Le calcul croît-il plus vite que le stockage, ou de façon proportionnelle ? Cela influence directement la décision HCI vs. HCI + Calcul vs. UCI.
* **Modèles saisonniers ou en pics** — les charges de travail avec des périodes de pointe peuvent nécessiter une marge que les métriques en régime stable ne révèlent pas.
### Exigences de performance
* **Objectifs d’IOPS** par niveau de charge de travail (base de données, application, services de fichiers).
* **Exigences de latence** — sous la milliseconde pour les bases de données contre usage général pour les serveurs de fichiers.
* **Débit** — bande passante séquentielle en lecture/écriture pour les charges de sauvegarde, de médias ou d’analytique.
### Exigences de disponibilité et de reprise après sinistre
* **RPO (objectif de point de reprise) :** Quelle quantité de perte de données est acceptable ? Cela détermine la fréquence des instantanés et le calendrier de synchronisation entre sites.
* **RTO (objectif de temps de reprise) :** À quelle vitesse les services doivent-ils être restaurés ? Cela influence le fait que les locataires aient besoin d’une haute disponibilité multi-nœuds ou d’un seul nœud avec basculement automatique.
* **Attentes N+1 :** Le cluster peut-il survivre à la défaillance complète d’un nœud avec toutes les charges de travail en cours d’exécution ? Cela est directement lié à la [décision de réservation de RAM](#ram-reservation-decision) abordée plus loin sur cette page.
* **Exigences du site de reprise après sinistre :** Le client a-t-il besoin d’une réplication de synchronisation de site vers un emplacement secondaire ?
### Topologie réseau et contraintes
* **Infrastructure de commutation existante :** Marque, modèle, fonctionnalités (MLAG, LACP, BGP).
* **NIC disponibles par nœud :** 2 contre 4+ déterminent le modèle de conception réseau.
* **Exigences VLAN :** Combien de réseaux isolés sont nécessaires ? Les locataires sont-ils sur des VLAN partagés ou dédiés ?
* **Contraintes physiques :** Tout le matériel est-il dans une seule baie ? Plusieurs baies ? Plusieurs sites ?
* **Latence du cœur de fabric :** Tous les nœuds doivent être sur la même infrastructure de commutation, sans aucun saut de commutateur.
### Budget et calendrier
* **Budget matériel :** Influence le choix du fournisseur de serveurs et le nombre de nœuds.
* **Modèle de licence :** Basé sur les nœuds — affecte la stratégie d’optimisation des coûts.
* **Calendrier d’installation :** Déploiement standard ou progressif.
***
## Traduction des charges de travail en ressources
Une fois l’inventaire des charges de travail du client obtenu, traduisez-le en besoins de ressources VergeOS. VergeOS a considérablement **moins de surcharge** que les plateformes traditionnelles — il n’y a pas de VM contrôleur (CVM), pas d’appliance vCenter et pas de plan de gestion séparé consommant des ressources.
### Étape 1 : agréger les totaux des charges de travail
Additionnez les besoins des charges de travail du client :
```
Cœurs vCPU totaux = Σ (cœurs par VM)
RAM totale (Go) = Σ (RAM par VM)
Stockage total (To) = Σ (stockage alloué par VM)
```
### Étape 2 : ajouter la surcharge système VergeOS
La surcharge VergeOS est minimale, mais doit être prise en compte :
| Ressource | Surcharge |
| ---------------------------------- | ------------------------------------------------------------------------- |
| **RAM par nœud vSAN** | 16 Go pour VergeOS + 1 Go par 1 To de stockage brut sur ce nœud (minimum) |
| **RAM par nœud vSAN (recommandé)** | 16 Go + 1,5 Go par 1 To de stockage brut |
| **CPU par nœud de stockage** | 1 cœur par disque (recommandé) |
| **Stockage de niveau 0** | 5–10 Go par 1 To de capacité utilisable (nœuds contrôleurs uniquement) |
| **Nœuds de calcul uniquement** | Seulement 16 Go pour VergeOS ; aucune surcharge de stockage |
{% hint style="success" %}
**RAM du nœud locataire : aucune surcharge supplémentaire au niveau de l’hôte**
Lorsque vous allouez de la RAM à un nœud locataire, cette **quantité totale** est ce que l’hôte réserve — vous ne **n’** ajoutez pas de surcharge séparée au niveau de l’hôte pour le locataire. En revanche, à l’intérieur du locataire, sa propre instance VergeOS imbriquée consomme la surcharge standard (16 Go + 1 Go par 1 To de stockage) à partir de cette allocation avant que les VM invitées du locataire ne reçoivent de la mémoire.
Il existe donc deux niveaux distincts : sur l’ **hôte** , dimensionnez le nœud locataire = la RAM que vous souhaitez lui attribuer. À l’intérieur du **locataire** , planifiez ses charges invitées par rapport à (RAM allouée − 16 Go − 1 Go/To).
{% endhint %}
### Étape 3 : tenir compte de la marge de haute disponibilité
Si le client exige une disponibilité N+1 (le cluster peut survivre à la défaillance d’un nœud avec toutes les VM en cours d’exécution), vous devez vous assurer que les **nœuds restants** disposent d’assez de CPU et de RAM agrégés pour absorber les charges de travail du nœud défaillant.
**Règle empirique :** Pour un cluster de N nœuds, chaque nœud doit être provisionné pour utiliser au plus `(N-1)/N` de ses ressources totales. Par exemple, dans un cluster de 4 nœuds, visez une utilisation de 75 % par nœud.
### Étape 4 : calculer le nombre de nœuds
Divisez les besoins totaux en ressources (y compris la surcharge et la marge de haute disponibilité) par la capacité par nœud afin de déterminer le nombre minimal de nœuds. Arrondissez toujours au supérieur et validez le résultat par rapport aux architectures de référence. Les plages de nombre de nœuds ci-dessous sont des règles empiriques grossières — HCI convient aux petits déploiements (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 :
* **2–6 nœuds → HCI**
* **6–10 nœuds → HCI + Calcul dédié**
* **10+ nœuds → UCI**
```mermaid
flowchart TD
A["Agrégat des charges de travail
CPU + RAM + Stockage"] --> B["Ajouter la surcharge VergeOS
16 Go + 1 Go/To par nœud"]
B --> C["Appliquer la marge de haute disponibilité
(N-1)/N cible d’utilisation"]
C --> D["Diviser par la capacité par nœud"]
D --> E{"Nombre de nœuds ?"}
E -->|"2-6"| HCI["Recommander HCI"]
E -->|"6-10"| HCC["Recommander HCI + Calcul"]
E -->|"10+"| UCI["Recommander UCI"]
style HCI fill:#d1fae5,stroke:#059669
style HCC fill:#fef3c7,stroke:#d97706
style UCI fill:#e0e7ff,stroke:#4f46e5
```
***
## Planification des nœuds locataire
Pour les déploiements multi-locataires (CSP, MSP ou isolation interne par département), chaque locataire s’exécute à l’intérieur d’un centre de données virtuel (VDC) soutenu par un ou plusieurs **nœuds locataire**. Les nœuds locataire sont des machines virtuelles qui agissent comme les nœuds de calcul de l’instance VergeOS imbriquée du locataire ; le stockage est provisionné à partir des quotas de niveau de stockage de l’hôte et la mise en réseau via les réseaux virtuels du locataire.
### Locataires à nœud unique ou à plusieurs nœuds
**Les locataires à nœud unique** sont le point de départ par défaut et le plus recommandé :
* Ils offrent une redondance via le basculement automatique — si l’hôte physique tombe en panne, le nœud locataire redémarre automatiquement sur un autre hôte.
* Plus simples à gérer et à dimensionner correctement.
* Peuvent être mis à l’échelle verticalement (ajout de cœurs/RAM) sans interruption.
* Des nœuds supplémentaires peuvent être ajoutés plus tard, sans perturbation, au fur et à mesure de la croissance du locataire.
**Les locataires à plusieurs nœuds** sont nécessaires lorsque :
1. **Les besoins en ressources dépassent les maximums du cluster** — les `RAM maximale par machine` et `cœurs maximum par machine` des paramètres du cluster limitent la taille d’un seul nœud locataire.
2. **Applications en cluster** nécessitent des charges de travail sur différents hôtes physiques (par exemple, base de données principale/réplique sur des nœuds distincts pour la haute disponibilité).
3. **Capacités matérielles mixtes** — le locataire a besoin à la fois de calcul standard et de nœuds équipés de GPU, qui résident sur différents clusters physiques.
4. **Exigences réglementaires** imposant une séparation matérielle entre les types de charges de travail.
### Stratégie de dimensionnement
Les locataires VergeOS prennent en charge **la mise à l’échelle sans interruption** — vous pouvez ajouter des ressources aux nœuds existants ou ajouter des nœuds entièrement nouveaux sans interrompre les charges de travail en cours d’exécution. L’approche recommandée :
1. **Provisionner pour les besoins actuels ou à court terme** — ne pas surallouer pour une croissance future spéculative.
2. **Croître de manière organique** — augmenter les ressources des nœuds locataire à mesure que la demande se matérialise.
3. **Exploiter au maximum les nœuds existants avant d’en ajouter de nouveaux** — il est plus efficace de faire passer un nœud de 32 Go à 64 Go que d’ajouter un deuxième nœud de 32 Go, sauf si la haute disponibilité de l’application exige une séparation physique.
### Exemples de configurations
### Petit nœud unique
**Scénario :** 3 VM, aucune exigence particulière, le cluster autorise un maximum de 64 Go / 16 cœurs.
**Configuration :** 1 nœud locataire — 16 Go de RAM, 8 cœurs.
**Chemin de montée en charge :** Ajouter de la RAM/des cœurs au nœud existant (jusqu’à 64 Go / 16 cœurs), puis ajouter un deuxième nœud si nécessaire.
### HA de taille moyenne
**Scénario :** Ferme web avec 4 serveurs web + 2 serveurs de base de données nécessitant une séparation physique des hôtes.
**Configuration :** 2 nœuds locataire — 64 Go de RAM, 12 cœurs chacun. Les groupes HA imposent l’anti-affinité afin que les instances web/base de données s’exécutent sur des hôtes physiques différents.
**Chemin de montée en charge :** Augmenter les ressources des nœuds ou ajouter un troisième nœud pour une meilleure répartition des charges.
### Charge de travail mixte avec GPU
**Scénario :** VM standard + rendu vidéo accéléré par GPU sur différents clusters matériels.
**Configuration :** 4 nœuds locataire — 2 sur le cluster Standard (64 Go chacun), 1 sur le cluster vGPU (64 Go), 1 sur le cluster Haute performance (48 Go).
**Chemin de montée en charge :** Faites évoluer chaque nœud indépendamment en fonction des capacités de son cluster et de la demande des charges de travail.
### Réparti en entreprise
**Scénario :** Plateforme d’analytique distribuée nécessitant 3 serveurs d’applications sur des hôtes physiques distincts + des nœuds de traitement des données.
**Configuration :** 4 nœuds locataire — 3 × 64 Go / 12 cœurs (application + base de données par nœud avec anti-affinité du groupe HA) + 1 × 32 Go / 8 cœurs (traitement des données).
**Chemin de montée en charge :** Ajoutez des ressources aux nœuds existants ou ajoutez des nœuds pour une séparation physique supplémentaire.
***
## Cadre de décision pour le choix de la topologie
Une fois les besoins en charges de travail recueillis et la traduction des ressources effectuée, utilisez les critères suivants pour formuler votre recommandation d’architecture :
| Critères de décision | HCI | HCI + Calcul | UCI |
| ------------------------------ | --------------------------------- | -------------------------------------------- | ------------------------------------------------------ |
| **Nombre de nœuds** | 2–6 | 6–10 | 10+ |
| **Modèle de croissance** | Proportionnel (calcul ≈ stockage) | Calcul > stockage | L’un ou l’autre (entièrement indépendant) |
| **Spécialisation** | Aucun besoin | Quelques-uns (GPU dans le cluster de calcul) | Complète (GPU, grande mémoire, stockage dense) |
| **Tolérance à la complexité** | Personnel informatique réduit | Modérée | Équipe d’infrastructure dédiée |
| **Budget** | Le plus rentable | Modérée | Le plus élevé (mais le plus efficace à grande échelle) |
| **Isolement des performances** | Contention acceptable | Calcul isolé des E/S de stockage | Maximum — chaque rôle sur un matériel dédié |
### Liste de contrôle de décision
1. **Le nombre de nœuds est-il inférieur à 6 ?** → Commencez avec HCI sauf s’il existe une raison précise de séparer le calcul.
2. **Le calcul croît-il plus vite que le stockage ?** → HCI + Calcul permet d’ajouter des nœuds de calcul uniquement peu coûteux.
3. **Y a-t-il des besoins en GPU, en grande mémoire ou en autre matériel spécialisé ?** → UCI permet des clusters de calcul dédiés par type de matériel.
4. **Le client doit-il faire évoluer le stockage indépendamment ?** → UCI est le seul modèle avec un cluster de stockage dédié.
5. **La simplicité opérationnelle est-elle la priorité absolue ?** → HCI a la plus faible surcharge de gestion.
6. **L’environnement peut-il évoluer au fil du temps ?** → Toujours. VergeOS prend en charge la transition de HCI → HCI + Calcul → UCI en ajoutant des clusters à un système existant.
***
## Décision de réservation de RAM
Lors de l’installation, l’ingénieur doit décider de la préférence en matière de réservation de RAM. Il s’agit d’un compromis entre **la mémoire utilisable** et **l’application de la haute disponibilité N+1**:
| Option | Comportement | Idéal pour |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Plus de mémoire utilisable** | Le système permet aux VM d’utiliser une plus grande partie de la RAM disponible, réduisant la réserve automatique pour la marge de basculement | Environnements où la maximisation de la densité de charge de travail par nœud est plus importante qu’une capacité de basculement N+1 garantie |
| **Application plus stricte du N+1 HA** | Le système réserve davantage de RAM pour garantir qu’en cas de panne d’un nœud, les nœuds restants disposent d’une capacité garantie pour absorber toutes les charges déplacées | Environnements de production avec des SLA de disponibilité stricts où le basculement garanti n’est pas négociable |
{% hint style="warning" %}
Cette décision doit être prise **avant** le jour de l’installation. Discutez du compromis avec le client pendant le cadrage et documentez la préférence choisie dans le plan d’installation.
{% endhint %}
***
## Livrables documentaires
Une mission de cadrage complète doit produire le package documentaire suivant, prêt pour l’ingénieur d’installation :
### 1. Documentation de conception réseau
* **Schéma de conception de couche 2** — commutateurs physiques, VLAN, affectations de ports, configuration MLAG/stacking.
* **Schéma de conception de couche 3** — sous-réseaux, passerelles, routage (BGP/OSPF le cas échéant), serveurs DNS.
* **Carte des câbles A-B** — chaque câble de chaque nœud vers chaque commutateur, étiqueté avec les identifiants de port.
* **Configuration du cœur de fabric** — VLAN dédiés pour le cœur 1 et le cœur 2, confirmation MTU 9216+, vérification de l’absence de saut de commutateur.
### 2. Élévation de baie
* Emplacement physique de chaque nœud, commutateur, PDU et gestion des câbles.
* Affectation des circuits d’alimentation et cartographie de la redondance.
### 3. Plan d’allocation IP
| Réseau | Adresse | Objectif |
| ----------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Gestion/UI | `10.x.x.2/24` | Interface web et API VergeOS |
| Passerelle | `10.x.x.1` | Passerelle par défaut pour le trafic externe |
| Fabric du cœur 1 | VLAN 900 | VLAN d’accès non tagué créé sur le commutateur ; adresses IP des nœuds attribuées automatiquement par VergeOS. Trafic de stockage et de contrôle inter-nœuds |
| Fabric du cœur 2 | VLAN 901 | VLAN d’accès non tagué créé sur le commutateur ; adresses IP des nœuds attribuées automatiquement par VergeOS. Trafic redondant inter-nœuds |
| IPMI | `192.168.x.0/24` | Gestion hors bande |
| Réseaux locataire | Allocation par locataire | Sous-réseaux spécifiques au client |
### 4. Nomenclature matérielle
* Modèle de serveur, CPU, RAM, configuration disque par nœud.
* Types et vitesses des NIC.
* Modèles de commutateurs et nombre de ports.
* Spécifications NVMe de niveau 0 (DWPD, capacité par To de stockage utilisable).
### 5. Plan d’installation
* Architecture de référence choisie (HCI, HCI + Calcul ou UCI).
* Affectations des niveaux de disque par nœud.
* Préférence de réservation de RAM (mémoire utilisable vs. application du N+1).
* Décision de chiffrement (chiffrement au repos oui/non, plan de stockage des clés).
* Configuration du serveur NTP.
* Plan des identifiants d’administration (référence du coffre-fort de mots de passe).
***
{% hint style="info" %}
**Vous venez de VMware ou de Nutanix ?**
Le cadrage VergeOS est un seul passage de dimensionnement : surcharge système fixe de 16 Go par nœud plus 1 Go par To de stockage brut. Il n’y a pas de CVM, pas d’appliance de gestion séparée et pas d’exercice de licence par fonctionnalité — calcul, stockage, réseau et multi-location sont dimensionnés ensemble comme une seule plateforme.
{% endhint %}
***
## Résumé
| Phase | Résultat |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Collecte des besoins** | Liste de contrôle complétée avec inventaire des charges de travail, prévisions de croissance, objectifs de performance et contraintes réseau |
| **Traduction des ressources** | CPU, RAM et stockage totaux avec surcharge VergeOS et marge de haute disponibilité appliquées |
| **Planification des locataires** | Décisions nœud unique vs. multi-nœuds par locataire avec exemples de configurations |
| **Sélection de la topologie** | Recommandation HCI, HCI + Calcul ou UCI avec justification |
| **Réservation de RAM** | Préférence documentée — mémoire utilisable vs. application du N+1 |
| **Package documentaire** | Schémas réseau, élévation de baie, plan IP, nomenclature matérielle et plan d’installation |
## Étapes suivantes
* [**Exigences matérielles**](/learn-the-platform/fr/module-2-dimensionnement-et-conception/01-hardware-requirements.md) — Vérifiez les spécifications de votre nœud par rapport aux exigences minimales et recommandées.
* [**Architectures de référence**](/learn-the-platform/fr/module-2-dimensionnement-et-conception/02-reference-architectures.md) — Consultez les diagrammes topologiques détaillés de l’architecture que vous avez sélectionnée.
* [**Module 3 : Installation**](/learn-the-platform/fr/module-3-installation/03-installation.md) — Passez à la préparation et à l’exécution de l’installation.
---
# 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/03-customer-scoping.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.