Je me souviens encore de ma première entrée dans une salle serveur « sérieuse » au milieu des années 2000. Ce qui m’a frappé, ce n’était pas tant le bruit assourdissant de la climatisation, mais la densité physique de l’infrastructure.

À cette époque, pour faire tourner quelques centaines de machines virtuelles, il ne fallait pas juste « un cluster ». Il fallait des rangées entières. Des serveurs lames gourmands en énergie, des switchs Fibre Channel monstrueux avec leurs câbles oranges caractéristiques, et surtout, trônant au centre de la pièce comme un totem sacré : la Baie de Stockage. Des armoires entières remplies de disques mécaniques 10k tours/minute, pesant le poids d’une petite voiture et consommant autant de ‘U’ (unités de rack) que possible.

C’est ce qu’on appelle l’architecture 3-Tiers. Si aujourd’hui l’Hyperconvergence (HCI) et le Cloud public semblent être la norme, il est crucial de comprendre que le 3-Tiers a été la colonne vertébrale de l’informatique d’entreprise pendant près de 20 ans. Comprendre cette architecture, c’est comprendre d’où l’on vient, et pourquoi nous avons cherché à en changer.

Dans cet article, le premier d’une série qui va présenter l’évolution des infrastructures de virtualisation 3-tiers vers les infrastructures hyperconvergées Nutanix, nous allons disséquer factuellement ce standard : son fonctionnement, pourquoi il a dominé le marché, et les limites techniques qui ont fini par le rendre obsolète pour les workloads modernes.

Genèse : Pourquoi avons-nous construit ainsi ?

Pour comprendre le 3-Tiers, il faut revenir à l’ère pré-virtualisation. Un serveur physique hébergeait une seule application (Windows + SQL, par exemple). C’était le modèle « Silo ». Inefficace, coûteux, et cauchemardesque à gérer.

La virtualisation (VMware en tête) est arrivée avec une promesse : consolider plusieurs serveurs virtuels sur un seul serveur physique. Mais pour que cette magie opère, il y avait une condition technique absolue : la mobilité.

Pour qu’une VM puisse passer d’un serveur physique A à un serveur physique B sans interruption de service (le fameux vMotion), les deux serveurs devaient voir exactement les mêmes données, au même moment.

C’est là que l’architecture s’est scindée en trois couches distinctes :

1. On a retiré les disques des serveurs (qui ne font plus que du calcul).
2. On a centralisé toutes les données dans un stockage partagé externe (la Baie).
3. On a relié le tout par un réseau dédié ultra-rapide (le SAN).

C’était une révolution : le serveur devenait « jetable » ou du moins interchangeable, car il ne possédait plus la donnée. Mais cette centralisation a créé un point unique de complexité et de performance : le stockage partagé. C’est le cœur du réacteur, mais aussi son talon d’Achille.

L’Anatomie du 3-Tiers : Décorticage des couches

Si l’on devait dessiner cette architecture, elle ressemblerait à un gâteau à trois étages, où chaque étage parle une langue différente.

1. La couche Compute (Calcul)

Tout en haut, nous avons les serveurs physiques (Hosts). Ils exécutent l’hyperviseur (ESXi, Hyper-V, KVM). Leur rôle est purement mathématique : fournir du CPU et de la RAM aux machines virtuelles.

Ces serveurs sont « Stateless ». Ils ne stockent rien de persistant. Si un serveur brûle, ce n’est pas grave : on redémarre les VMs sur le voisin (HA).

Cette logique a été poussée à l’extrême avec le « Boot from SAN ». On a même fini par retirer les petits disques locaux (SD cards ou SATA DOM) qui contenaient l’OS de l’hyperviseur pour que le serveur soit une coquille vide totale, chargeant son propre système d’exploitation depuis la baie de stockage distante. Une prouesse technique, mais un cauchemar en cas de perte de connectivité SAN.

2. La couche Network (SAN)

Au milieu se trouve le réseau de stockage (Storage Area Network). C’est l’autoroute qui transporte les données entre les serveurs et la baie. Historiquement, cela ne passait pas par le réseau Ethernet classique (trop instable à l’époque), mais par un protocole dédié : le Fibre Channel (FC).

C’est un réseau déterministe et sans perte. Contrairement à l’Ethernet qui fait du « best effort », le FC garantit que les paquets arrivent dans l’ordre.

Si vous avez administré du SAN, vous connaissez la douleur du Zoning. Il fallait configurer manuellement sur les switchs quel port (WWN) avait le droit de parler à quel autre port. Une erreur d’un chiffre dans une adresse hexadécimale de 16 caractères, et votre cluster de production s’arrêtait net. C’était une tâche si complexe qu’elle nécessitait souvent une équipe dédiée (« L’équipe SAN »).

3. La couche Storage (Stockage)

Tout en bas, la Baie de Stockage (Storage Array). C’est un ordinateur géant spécialisé dans l’écriture et la lecture de blocs de données. Elle contient des contrôleurs (les cerveaux) et des tiroirs de disques (la capacité).

La baie agrège des dizaines voire des centaines de disques physiques pour créer de gros volumes virtuels (LUNs) qu’elle présente aux serveurs. Elle assure la protection des données via du RAID matériel.

Toute l’intelligence réside dans deux contrôleurs (souvent en mode Actif/Passif ou Actif/Actif asymétrique). C’est un goulot d’étranglement architectural : peu importe que vous ayez 500 disques SSD ultra-rapides derrière, si vos deux contrôleurs saturent en CPU ou en cache, toute l’infrastructure ralentit. C’est ce qu’on appelle le « Front-end bottleneck ».

Les Forces : Pourquoi ce modèle a dominé le monde

Il est facile de critiquer le 3-Tiers avec nos yeux de 2024, mais il faut reconnaître qu’il a apporté une stabilité incroyable.

1. Robustesse et Maturité : C’est du matériel conçu pour ne jamais faillir. Les baies de stockage ont des composants redondants partout (alimentations, ventilateurs, contrôleurs, chemins d’accès). On parle de « Five Nines » (99,999% de disponibilité).
2. Isolation des fautes : Si un serveur plante, le stockage continue de vivre. Si un disque casse, le RAID matériel le reconstruit sans que le serveur ne s’en aperçoive (ou presque).
3. Indépendance du Scale-Up : C’était l’argument roi. Vous manquez de place mais vos CPU dorment ? Vous achetez juste un tiroir de disques supplémentaire. Vous manquez de puissance mais avez plein de place ? Vous rajoutez un serveur. On pouvait dimensionner chaque étage indépendamment.

Les Faiblesses : Le revers de la médaille

Malgré sa robustesse, le modèle 3-Tiers a commencé à montrer de sérieux signes de fatigue face à la virtualisation moderne. Pour nous, administrateurs, cela s’est traduit par des nuits écourtées et quelques cheveux blancs prématurés.

La complexité opérationnelle

Le plus grand ennemi du 3-tiers n’est pas la panne, c’est la mise à jour. Imaginez devoir mettre à jour la version de votre hyperviseur (ESXi). Vous ne pouvez pas simplement cliquer sur « Update ». Vous devez consulter la HCL (Hardware Compatibility List). Est-ce que le nouveau driver de ma carte HBA est compatible avec le firmware de mon switch Fibre Channel, lui-même compatible avec la version de l’OS de ma baie de stockage ? C’est un château de cartes. J’ai vu des infrastructures entières devenir instables simplement parce qu’un firmware de carte réseau avait 3 mois de retard sur celui préconisé par le constructeur de la baie.

Le goulot d’étranglement

C’est un phénomène fascinant et destructeur. Imaginez 50 VMs sur un hôte.

• La VM 1 écrit un gros fichier séquentiel.
• La VM 2 fait une lecture de base de données.
• La VM 3 boot.

Au niveau de la VM, les opérations sont propres. Mais quand toutes ces opérations arrivent en même temps dans l’entonnoir du contrôleur de stockage, elles sont mélangées. Ce qui était une belle écriture séquentielle devient une bouillie d’écritures aléatoires (Random I/O). Les contrôleurs de baies traditionnelles, conçus à l’origine pour des serveurs physiques uniques, s’effondrent souvent sous ce type de charge, créant une latence perceptible par l’utilisateur final.

Le coût caché

Enfin, le 3-Tiers coûte cher. Très cher.

• Licences & Support : Vous payez le support du serveur, le support des switchs SAN, et le support de la baie (souvent indexé au volume de données !).
• Empreinte au sol : Comme évoqué en introduction, ces équipements consomment énormément d’espace et d’électricité.
• Expertise humaine : Il faut souvent une équipe pour le compute, une équipe pour le réseau, et une équipe pour le stockage. Les temps de résolution d’incidents explosent (« C’est pas le réseau, c’est le stockage ! » – « Non, c’est l’hyperviseur ! », vous voyez ce que je veux dire j’en suis certain…).

Conclusion : Une fondation nécessaire

L’architecture 3-Tiers n’est pas morte. Elle reste pertinente pour des besoins très spécifiques, comme des bases de données monolithiques massives qui nécessitent des garanties de performance physique dédiées.

Cependant, sa complexité de gestion et son incapacité à évoluer linéairement ont pavé la voie à une nouvelle approche. Nous avons commencé à nous poser la question interdite : « Et si, au lieu de spécialiser le matériel, on utilisait des serveurs standards et qu’on gérait tout par logiciel ? »

C’est cette réflexion qui a donné naissance au Software-Defined Storage (SDS) et à l’Hyperconvergence (HCI). Mais ça, c’est un sujet pour notre prochain article.