Architectures de référence
Trois modèles de déploiement VergeOS — HCI, HCI + calcul dédié et UCI — avec un cadre de décision, des schémas de topologie et des recommandations pour les scénarios edge et CSP.
VergeOS prend en charge trois architectures de déploiement à partir de la même installation logicielle. Le choix de la bonne architecture dépend du nombre de nœuds, du rythme de croissance et des exigences de spécialisation des charges de travail. Cette page présente chaque modèle, fournit un cadre de décision et couvre deux scénarios réels courants : les déploiements en périphérie et les environnements multi-locataires des fournisseurs de services cloud (CSP).
Arbre de décision d'architecture
Utilisez le cadre suivant pour guider votre recommandation. Les plages de nombre de nœuds ci-dessous sont des règles empiriques approximatives : HCI convient aux déploiements plus petits (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.
Règles rapides à retenir :
Commencez par HCI sauf raison spécifique de ne pas le faire.
Envisagez HCI + Calcul lorsque la demande en calcul dépasse la croissance du stockage (6--10 nœuds).
Choisissez UCI pour les environnements de 10 nœuds et plus, le matériel spécialisé ou l'isolation maximale des performances.
Vous pouvez évoluer de HCI à HCI + Calcul à UCI à mesure que l'environnement grandit -- la même installation VergeOS prend en charge les trois.
Modèle 1 : HCI (infrastructure hyperconvergée)
Plage de nœuds : 2--6 nœuds | Clusters : 1
Dans un déploiement HCI, chaque nœud contribue à la fois au calcul et au stockage. Les deux nœuds contrôleurs assurent le stockage de niveau 0 (métadonnées vSAN) et de niveau 1 (charge de travail) et exécutent des VM. Les nœuds d'extension ajoutent de la capacité de stockage de niveau 1 et de calcul au même cluster.
Avantages
Simplicité opérationnelle -- un seul cluster, une seule spécification matérielle, une gestion unifiée.
Mise à l'échelle prévisible -- chaque nœud ajoute proportionnellement du stockage et du calcul.
Point d'entrée le plus bas -- un cluster de 2 nœuds est le plus petit déploiement VergeOS possible.
Une seule spécification matérielle simplifie les achats et l'inventaire des pièces de rechange.
Limites
Impossible de faire évoluer le calcul indépendamment du stockage (ou inversement).
Spécialisation matérielle limitée -- tous les nœuds partagent le même rôle.
Maximum recommandé d'environ 6 nœuds avant d'envisager un second cluster.
Risque potentiel de contention des ressources sur les nœuds contrôleurs exécutant à la fois les opérations de métadonnées et les charges de travail des VM.
Cas d'utilisation idéaux
Déploiements petits/moyens (2--6 nœuds)
Complexité minimale, chaque nœud assure deux fonctions
Charges de travail équilibrées
Le stockage et le calcul croissent à peu près au même rythme
Sites en périphérie / distants
Clusters à 2 nœuds avec haute disponibilité complète et faible empreinte
Évaluation et tests
Le chemin le plus rapide vers un système VergeOS opérationnel
Modèle 2 : HCI + calcul dédié (UCI hybride à 2 clusters)
Plage de nœuds : 6--10 nœuds | Clusters : 2
Il s'agit de la variante UCI hybride à 2 clusters : les rôles de contrôleur et de stockage restent fusionnés dans un cluster HCI, tandis que le calcul est séparé dans son propre cluster. Le cluster HCI (cluster 1) fournit tout le stockage via ses contrôleurs et ses nœuds d'extension optionnels. Le cluster de calcul (cluster 2) exécute les charges de travail VM sans fournir de disques.
Principes de conception clés
Cluster 1 -- HCI (combiné)
Inclut toujours les nœuds 1 et 2 avec le stockage de niveau 0 (contrôleurs). - Peut inclure des nœuds HCI d'extension supplémentaires pour davantage de stockage et de calcul. - Un commutateur au niveau du cluster contrôle si ce cluster exécute également des charges de travail VM. - Tous les niveaux de stockage existent dans ce cluster.
Cluster 2 -- Calcul uniquement
Calcul pur -- maximum de CPU et de RAM disponibles pour les VM. - Évolue indépendamment en fonction de la demande de calcul. - Prend en charge un matériel flexible, optimisé pour la charge de travail (nœuds GPU, nœuds à haute mémoire). - Les E/S de stockage des nœuds de calcul transitent par le core fabric vers le cluster 1.
Avantages
Mise à l'échelle indépendante du calcul sans acheter de stockage inutile.
Conserve la simplicité opérationnelle HCI pour la couche de stockage.
Rentable -- ne faire évoluer que la couche de ressources qui croît.
Chemin de croissance clair vers l'UCI canonique à 3 clusters si les besoins évoluent davantage.
Limites
Les E/S de stockage des nœuds de calcul traversent le réseau (une bande passante adéquate du core fabric est essentielle).
Plus complexe qu'une HCI pure (deux clusters à gérer au lieu d'un).
Nécessite de décider si le cluster HCI doit également exécuter des charges de travail.
Cas d'utilisation idéaux
Déploiements de 6--10 nœuds
Point idéal pour le modèle à deux clusters
La croissance du calcul dépasse celle du stockage
Ajouter du CPU/de la RAM sans étendre les disques
GPU ou calcul spécialisé
Cluster de calcul dédié avec matériel en passthrough
Optimisation des coûts
Ne faire évoluer que ce dont vous avez besoin
Modèle 3 : UCI (infrastructure ultra-convergée) -- Canonical 3-Cluster
Plage de nœuds : 10+ nœuds | Clusters : 3+
L'UCI canonique à 3 clusters sépare complètement les contrôleurs, le stockage et le calcul dans des clusters dédiés. Chaque niveau de ressource évolue indépendamment et utilise un matériel optimisé pour son rôle. (UCI est un terme générique pour tout déploiement à mise à l'échelle indépendante ; le modèle 2 ci-dessus en est la variante hybride à 2 clusters.)
Spécialisation des clusters
Cluster 1 -- Contrôleurs
Métadonnées de niveau 0, gestion du cluster
Mémoire élevée (p. ex. 768 Go dans le RA Data-Science), NVMe à haute endurance pour le niveau 0
Cluster 2 -- Stockage
Tout le stockage des charges de travail (niveau 1+)
Densité de disques maximale, NVMe ou SSD SAS/SATA
Clusters 3+ -- Calcul
Charges de travail VM, matériel spécialisé
Types de nœuds standard, GPU, haute mémoire ou personnalisés
Avantages
Performances maximales -- aucune contention des ressources entre stockage et calcul.
Mise à l'échelle indépendante complète -- ajouter du stockage sans calcul (ou inversement).
Spécialisation matérielle -- dimensionner le matériel selon le rôle (NVMe denses pour le stockage, GPU pour le calcul).
Isolation des charges de travail -- différents clusters de calcul pour différents types de charges de travail.
Optimal pour les environnements à grande échelle et multi-locataires.
Limites
La complexité opérationnelle la plus élevée des trois architectures.
Minimum 6 nœuds (dérivé du minimum de 2 nœuds par cluster × 3 clusters : 2 contrôleurs + 2 stockage + 2 calcul).
Planification des capacités plus complexe sur trois types de clusters.
Exigences de bande passante plus élevées du core fabric entre les clusters.
Des services professionnels sont recommandés pour le déploiement initial.
Cas d'utilisation idéaux
Déploiements d'entreprise de 10 nœuds et plus
La mise à l'échelle indépendante évite le surdimensionnement
Charges de travail IA / HPC / GPU
Clusters de calcul GPU dédiés, séparés du stockage
Fournisseurs de services cloud
Optimiser les dépenses matérielles par niveau de ressource entre les locataires
Croissance axée stockage ou calcul
Ne faire évoluer que ce qui croît
Comparaison des architectures
Nombre minimum de nœuds
2
4 (2 HCI + 2 calcul)
6 (2+2+2)
Nombre de clusters
1
2
3+
Performance
Bon
Meilleur
Optimal
Flexibilité matérielle
Faible
Moyenne
Maximale
Mise à l'échelle indépendante
Non
Partielle (calcul uniquement)
Complète
Spécialisation
Aucune
Calcul uniquement
Complète (contrôleur, stockage, calcul)
Complexité
Faible
Moyenne
Élevée
Efficacité des ressources
Variable
Bon
Maximale
Meilleure adéquation
Petits, équilibrés
Taille moyenne, axés calcul
Grands, spécialisés
Scénarios de déploiement Edge
Les clusters Edge sont des déploiements VergeOS compacts à 2 nœuds conçus pour des sites distants ou des succursales. Ils utilisent du matériel à faible consommation, au format compact, et sont directement connectés (aucun commutateur requis pour le core fabric).
Configuration Edge typique
2 nœuds directement connectés via deux NIC (core fabric).
Matériel au format compact (Intel NUC, PC SFF 1L ou similaire).
2 To de NVMe pour les charges de travail + 4 To de SSD pour le stockage de masse par nœud.
HA complète et redondance malgré une empreinte minimale.
Modèles de gestion Edge
VergeOS prend en charge trois scénarios de gestion Edge de sophistication croissante :
Autonome avec gestion centralisée -- des clusters à 2 nœuds sur chaque site, gérés de manière centralisée via le Sites tableau de bord. Les dépôts de catalogue distribuent les recettes de VM du cluster de gestion à tous les sites Edge.
Sauvegarde et reprise après sinistre centralisées -- idem, avec en plus un système central dans le centre de données principal qui fournit Site Sync la réplication, ioGuardian des serveurs de réparation et un stockage centralisé des instantanés pour tous les bureaux distants.
Multi-niveaux avec archive -- ajoute un cluster d'archivage secondaire sur un site de reprise après sinistre pour la rétention à long terme à l'aide de disques durs haute capacité, offrant une stratégie de sauvegarde complète 3-2-1.
Quand recommander Edge
Contraintes d'espace ou d'alimentation sur les sites distants.
Applications qui stockent les données de manière centralisée mais ont besoin de calcul local.
Organisations gérant 5--100+ sites distribués.
Déploiements de succursales sensibles aux coûts.
Scénarios CSP / multi-locataires
Les fournisseurs de services cloud exploitent la multi-location de VergeOS pour fournir de l'IaaS à partir d'une infrastructure partagée. Chaque locataire fonctionne comme un centre de données virtuel isolé (VDC) avec sa propre interface, ses réseaux, son stockage et ses contrôles d'accès.
Configuration CSP typique
Clusters HCI à 6 nœuds dans les centres de données principaux (serveurs haute densité, 768 Go+ de RAM par nœud).
Site Sync entre les centres de données pour la reprise après sinistre.
ioGuardian serveurs de réparation pour la récupération automatique des blocs depuis les sites distants.
Déduplication globale en ligne réduit la consommation de stockage sur l'ensemble des instantanés répliqués.
Recettes de locataire automatisent le provisionnement d'environnements client complets (locataire, réseaux, règles de pare-feu, VM, stockage).
Parcours de croissance CSP
Phase 1
2 sites principaux avec reprise après sinistre via Site Sync
6 par site
Phase 2
Ajouter des clusters Edge à 2 nœuds dans de nouvelles régions
2 par région
Phase 3
Déployer les sites Edge en ajoutant des clusters (illustratif)
varie selon le site
Phase 4
Ajouter des clusters de stockage dédiés pour les locataires à forte consommation de stockage et les niveaux d'archive
2+ nœuds de stockage par site
Fonctionnalités clés de VergeOS pour les CSP
Multi-location avec isolation complète entre les environnements client.
Gestion en libre-service via l'interface web et l'API pour les administrateurs locataires.
Dépôts de catalogue pour la gestion centralisée des recettes de VM.
Authentification OpenID intégration avec les fournisseurs d'identité existants.
Recettes de locataire pour une intégration client automatisée et reproductible.
Aperçu des modèles de conception réseau
L'architecture de déploiement que vous choisissez influe sur la conception de votre réseau. VergeOS prend en charge plusieurs topologies réseau, détaillées dans Module 4 : Réseautique. Voici un bref aperçu pour orienter votre décision d'architecture :
L2 statique + cœur dédié
4
2 L2 dédiés
L2 agrégés (LACP)
Environnements de production, migrations VMware
L3 dynamique + cœur dédié
4
2 L2 dédiés
annoncé via BGP / OSPF / EIGRP
Grande échelle, segmentation avancée
L3 statique + cœur dédié
4
2 L2 dédiés
L3 agrégés (routes statiques)
Grande échelle, commutation de couche 3
L2 statique (2 NIC)
2
2 partagées (balisées VLAN)
Partagé avec le cœur (balisé VLAN)
Edge, preuve de concept, petits déploiements
Exigences clés communes à tous les modèles :
Les réseaux du core fabric doivent être sur des segments Layer 2 dédiés (isolés les uns des autres).
Trames jumbo (MTU 9216+) sur tous les ports du commutateur du cœur de réseau.
Aucun saut de commutateur entre les nœuds du cœur de réseau — tous les nœuds doivent se connecter au même tissu de commutation.
STP désactivé sur les ports du cœur de réseau.
Résumé
HCI
Chaque nœud fait tout. Simple, rentable à petite échelle. Commencez ici.
HCI + Calcul
UCI hybride à 2 clusters : contrôleur+stockage fusionnés, mise à l’échelle du calcul indépendante.
UCI
Architecture canonique à 3 clusters : contrôleur, stockage et calcul dédiés. Flexibilité maximale.
Edge
Clusters à connexion directe à 2 nœuds pour les sites distants, gérés de manière centralisée.
CSP
Déploiements HCI multitenants avec reprise après sinistre Site Sync et automatisation des recettes locataires.
Évolution
La même installation VergeOS prend en charge les trois modèles — évoluer de HCI vers UCI au fil du temps.
Étapes suivantes
Cadrage client -- Apprenez la méthodologie de collecte des exigences afin de traduire les besoins du client en une recommandation d’architecture précise.
Réseau -- Approfondissez les modèles de conception réseau mentionnés ci-dessus.
Mis à jour
Ce contenu vous a-t-il été utile ?