Cadrage client
Méthodologie de collecte des besoins, traduction des charges de travail en ressources, planification des nœuds locataires, cadre de sélection de topologie et livrables de documentation pour les déploiements VergeOS.
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
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 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 :
Étape 2 : ajouter la surcharge système VergeOS
La surcharge VergeOS est minimale, mais doit être prise en compte :
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
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).
É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
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 :
Les besoins en ressources dépassent les maximums du cluster — les
RAM maximale par machineetcœurs maximum par machinedes paramètres du cluster limitent la taille d’un seul nœud locataire.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é).
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.
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 :
Provisionner pour les besoins actuels ou à court terme — ne pas surallouer pour une croissance future spéculative.
Croître de manière organique — augmenter les ressources des nœuds locataire à mesure que la demande se matérialise.
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 :
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
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.
Le calcul croît-il plus vite que le stockage ? → HCI + Calcul permet d’ajouter des nœuds de calcul uniquement peu coûteux.
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.
Le client doit-il faire évoluer le stockage indépendamment ? → UCI est le seul modèle avec un cluster de stockage dédié.
La simplicité opérationnelle est-elle la priorité absolue ? → HCI a la plus faible surcharge de gestion.
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:
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
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.
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
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).
Résumé
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 — Vérifiez les spécifications de votre nœud par rapport aux exigences minimales et recommandées.
Architectures de référence — Consultez les diagrammes topologiques détaillés de l’architecture que vous avez sélectionnée.
Module 3 : Installation — Passez à la préparation et à l’exécution de l’installation.
Mis à jour
Ce contenu vous a-t-il été utile ?