Pourquoi le 3-Tiers ne tient plus pour la PME
Le modèle 3-Tiers sépare trois couches physiques distinctes. Des serveurs (la couche compute) hébergent les machines virtuelles. Une baie SAN ou NAS (la couche stockage) porte les volumes. Des switches Fibre Channel ou iSCSI (la couche réseau de stockage) relient les deux. Ce modèle est né dans le datacenter pour répondre à une logique industrielle : spécialisation des équipes, mutualisation massive du stockage, redondance de bout en bout.
Le problème n'est pas technique, il est organisationnel. Une infrastructure 3-Tiers en production suppose en théorie trois rôles distincts.
- Un administrateur stockage qui maîtrise les LUN, le zoning Fibre Channel, le tiering, les snapshots sous-jacents.
- Un administrateur réseau qui gère les deux fabrics (Ethernet et SAN) et leurs politiques de QoS.
- Un administrateur virtualisation qui opère l'hyperviseur, la console centrale et les licences.
En PME, ces trois rôles tombent sur une seule personne, souvent à temps partagé avec d'autres fonctions SI. Résultat observé sur le terrain : un ticket de support ouvert chez l'intégrateur à chaque incident non trivial, un maintien en condition opérationnelle (MCO) tributaire d'un prestataire externe, des mises à jour reportées, une documentation partielle, une maîtrise réelle limitée.
Comment fonctionne vraiment le stockage distribué HCI
La promesse marketing (« le SAN disparaît ») cache une mécanique précise qu'il faut comprendre avant de dimensionner. Le stockage HCI repose sur trois principes partagés par toutes les plateformes (Nutanix, vSAN, Scale, Ceph, etc.), même si les implémentations diffèrent.
Principe 1 : agrégation logique des disques locaux
Les SSD et NVMe de chaque nœud forment un pool logique unique, perçu par l'hyperviseur comme un datastore cohérent. L'administrateur provisionne des disques virtuels sans avoir à se préoccuper de l'hôte physique qui héberge réellement les blocs. La couche logicielle de stockage abstrait entièrement la localisation physique.
Principe 2 : réplication des blocs entre nœuds
Chaque écriture est répliquée sur un ou plusieurs nœuds voisins avant d'être acquittée auprès de la VM. Ce mécanisme garantit que la perte d'un nœud complet (panne matérielle, mise à jour) n'entraîne pas de perte de données. Le nombre de copies maintenues s'appelle le facteur de réplication (RF). Les plateformes proposent typiquement RF 2 (deux copies de chaque bloc) ou RF 3 (trois copies, pour tolérer la perte simultanée de deux nœuds).
Principe 3 : tolérance aux pannes (FTT)
Le paramètre FTT (Failures To Tolerate) indique combien de pannes simultanées de nœuds le cluster tolère sans interruption de service ni perte de donnée. Un cluster FTT 1 encaisse la panne d'un nœud. Un cluster FTT 2 tolère la panne de deux nœuds, ce qui exige RF 3 au minimum et au moins cinq nœuds. Le choix du FTT détermine directement la capacité utile : plus il est élevé, plus la part de capacité brute consommée par la redondance est importante.
La règle pratique à retenir : la capacité utile est toujours très inférieure à la capacité brute installée. Illustration avec un cluster de 4 nœuds équipés de 10 To brut chacun, soit 40 To brut au total. Avec RF 2 (réplication double), la capacité utile chute à 20 To. Avec RF 3, elle descend à environ 13 To. Les fonctions de déduplication et de compression peuvent ensuite récupérer 30 à 60 % selon la nature des données, sans jamais compenser entièrement le coût de la redondance.
Les cinq principes de sizing d'un cluster HCI
Un cluster sous-dimensionné souffre de contention IO, un cluster sur-dimensionné coûte inutilement cher. Cinq principes structurent un sizing tenable.
- Trois nœuds au minimum pour la haute disponibilité. Un cluster à 2 nœuds n'est pas une HCI à proprement parler, car il perd le quorum dès qu'un nœud tombe. Certaines plateformes proposent des configurations à 2 nœuds avec témoin externe, acceptables sur un site d'edge mais pas sur un site principal.
- Un réseau de stockage dédié, 10 ou 25 Gbps redondant. Le trafic de réplication entre nœuds est intensif. Les switches doivent être empilés ou en MLAG, chaque nœud raccordé en double lien, et le réseau de stockage logiquement séparé du trafic utilisateur.
- SSD ou NVMe en capacité primaire. Les disques mécaniques (HDD) restent acceptables comme palier secondaire sur certaines plateformes, mais la capacité chaude doit être en flash. La latence applicative en dépend directement.
- Dimensionnement en N+1 minimum. La capacité cible doit continuer à tenir même avec un nœud en panne. Un cluster à 3 nœuds dimensionné sans marge ne supporte pas une maintenance (un nœud arrêté représente 33 % de capacité perdue).
- Marge de croissance sur 24 mois. Prévoir 30 à 50 % de capacité libre à la mise en service pour absorber croissance et imprévus sans devoir ajouter un nœud dans l'urgence.
Quand le 3-Tiers reste pertinent
Le HCI n'est pas une réponse universelle. Trois contextes justifient encore le maintien ou le choix d'une architecture 3-Tiers.
Charges de travail à IOPS extrêmes sur VM unique
Une base de données OLTP soutenant plus de 100 000 IOPS sur une seule VM, ou un entrepôt de données à latence sub-milliseconde, exposent les limites de la réplication réseau. Une baie AFA (all-flash array) dédiée en Fibre Channel 32 Gbps ou NVMe over Fabrics reste structurellement plus performante sur ce profil.
Clusters de grande taille sur plateformes simplifiées
Au-delà de 8 nœuds, les plateformes HCI grand public (Scale, Proxmox avec ZFS) atteignent leurs limites de conception. Les plateformes de classe entreprise (Nutanix, vSAN, Ceph) tiennent, mais au prix d'une complexité opérationnelle qui finit par rapprocher du 3-Tiers. Le bénéfice organisationnel s'érode.
Investissements SAN récents à amortir
Une baie SAN installée il y a deux ans avec un contrat de maintenance courant jusqu'en 2029 ne se met pas au rebut. Le 3-Tiers peut être maintenu jusqu'à la fin de l'amortissement, avec un plan de sortie cadré (renouvellement des serveurs en HCI à la fin de vie de la baie).
Certifications éditeur bloquantes
Certains éditeurs métier (ERP industriel, logiciel médical, applications de salle de marché) n'ont certifié que les hyperviseurs historiques (vSphere, Hyper-V) sur architecture 3-Tiers traditionnelle. Avant toute bascule HCI, interroger les éditeurs concernés sur leur matrice de support reste une étape non négociable.
Pièges d'architecture à éviter
Sous-dimensionner le réseau de stockage
Des switches 1 Gbps sont à proscrire pour une HCI. Minimum 10 Gbps, idéalement 25 Gbps avec lien inter-switch (MLAG, stack ou équivalent).
Démarrer à deux nœuds sans témoin
Pas de haute disponibilité sans témoin externe. Sur un site principal, trois nœuds au minimum. La configuration à deux nœuds avec témoin reste acceptable uniquement en edge ou sur site secondaire.
Oublier le facteur de réplication dans le calcul de capacité
RF 2 divise la capacité utile par 2, RF 3 par 3. À intégrer dès le premier chiffrage, avant toute validation commerciale.
Dimensionner sans marge N+1
Un cluster à 3 nœuds occupé à 95 % ne supporte pas une maintenance. Penser N+1 dès la mise en service.
Mélanger les générations de nœuds sans précaution
Ajouter un nœud nettement plus puissant déséquilibre la réplication. Certaines plateformes exigent l’homogénéité, d’autres la tolèrent avec contraintes.
Négliger le palier de capacité
Le tout-NVMe haute capacité coûte cher. Un palier SSD combiné à un palier HDD capacitif reste acceptable selon la plateforme, mais à calibrer précisément.
Ignorer la stratégie de sauvegarde
Une HCI ne remplace pas la sauvegarde. Prévoir une solution compatible (Veeam, Vinchin, Nakivo) sur infrastructure séparée, avec copie immuable.
Sous-estimer le trafic inter-sites en stretched cluster
Un cluster étendu entre deux sites exige une latence inter-sites faible (< 5 ms) et une bande passante importante. Fibre dédiée indispensable.
Ce qu'il faut retenir
L'hyperconvergence n'est pas une technologie isolée. C'est un choix d'architecture qui aligne la complexité opérationnelle sur la taille réelle de l'équipe SI. Fusionner compute et stockage dans des nœuds banalisés supprime un étage de compétence, au prix d'une dépendance forte au réseau IP et de règles de sizing strictes à respecter.
Trois paramètres structurent tout dimensionnement : le facteur de réplication (RF), la tolérance aux pannes (FTT) et la capacité utile après redondance, déduplication, compression. Un chiffrage sérieux pose ces trois variables ensemble, jamais séparément.
Le 3-Tiers n'est pas mort. Il reste pertinent pour les charges de travail à IOPS extrêmes, les clusters de grande taille sur plateformes simplifiées et les bases installées SAN récentes à amortir. Pour le cas le plus courant (20 à 150 VM, équipe réduite, cycle de renouvellement sur 5 ans), le HCI s'est imposé comme le choix par défaut.
Pour choisir concrètement une plateforme HCI (Nutanix, vSAN, Scale, Proxmox), comparer les coûts et planifier une migration V2V, voir l'article complémentaire VMware post-Broadcom, l'arbre de décision pour un DSI.