Du réseau trois tiers au leaf-spine
Comprendre pourquoi les data centers modernes ont abandonné l'architecture trois tiers au profit du leaf-spine.
À retenir
- Le leaf-spine répond au trafic est-ouest dominant des data centers modernes, contrairement au trois tiers.
- Chaque leaf est relié à tous les spines : la latence entre serveurs est constante et prévisible.
- L'oversubscription doit être choisie dès la conception, en accord avec les besoins applicatifs.
- ECMP répartit les flux sur tous les chemins équivalents tout en préservant l'ordre des paquets d'un même flux.
Les limites de l'architecture trois tiers
Le réseau de campus classique en trois tiers (accès / distribution / cœur) a été conçu pour des flux essentiellement nord-sud (client vers serveur). Dans un data center moderne, la majorité du trafic est est-ouest (serveur à serveur, réplication de stockage, microservices) : cette architecture devient alors un goulet d'étranglement, chaque flux traversant potentiellement le cœur du réseau même pour joindre un serveur voisin dans la même rangée.
Le principe leaf-spine
L'architecture leaf-spine (dite « Clos ») repose sur deux étages :
- Leaf : switch d'accès connecté directement aux serveurs, jamais interconnecté à un autre leaf.
- Spine : switch de cœur qui interconnecte tous les leaf, sans connexion directe aux serveurs.
Chaque leaf est relié à tous les spines, ce qui garantit que deux serveurs quelconques du fabric sont toujours séparés par le même nombre de sauts (deux sauts : leaf → spine → leaf), quelle que soit leur position physique.
Point clé
dans un fabric leaf-spine correctement dimensionné, la latence est prévisible et constante entre n'importe quelle paire de serveurs, contrairement au trois tiers où la distance varie selon la position dans la hiérarchie.
Oversubscription : le ratio à surveiller
L'oversubscription mesure le rapport entre la bande passante côté serveurs (downlinks) et la bande passante disponible vers les spines (uplinks) sur un leaf.
| Ratio | Signification | Usage typique |
|---|---|---|
| 1:1 | Aucune contention, bande passante totale garantie | Stockage haute performance, HPC |
| 3:1 | Contention modérée acceptée | Environnements virtualisés courants |
| 6:1 et plus | Forte contention | Charges peu sensibles à la latence |
Attention
un ratio d'oversubscription choisi trop agressivement au moment du design ne peut généralement pas être corrigé sans ajouter des uplinks physiques ou des spines supplémentaires — c'est un choix à valider avec les équipes applicatives dès la conception, pas après la mise en production.
ECMP : répartir la charge sur tous les chemins
Puisque chaque leaf dispose de plusieurs chemins équivalents vers chaque autre leaf (un par spine), le fabric utilise ECMP (Equal-Cost Multi-Path) pour répartir les flux sur l'ensemble des liens disponibles plutôt que de n'en utiliser qu'un seul.
show ip route 10.10.0.0/24
show ip bgp summary
La répartition ECMP se fait généralement par hachage sur un tuple (IP source, IP destination, ports), garantissant qu'un même flux (une session TCP) emprunte toujours le même chemin — évitant ainsi le réordonnancement de paquets — tout en répartissant des flux différents sur des chemins différents.
Sur le terrain
un fabric qui semble sous-utilisé en bande passante globale peut en réalité souffrir d'un déséquilibre ECMP si un petit nombre de flux « éléphants » (gros transferts continus) saturent systématiquement le même chemin haché ; c'est un point à vérifier avant de conclure à un manque de capacité.
Astuce
documentez le ratio d'oversubscription cible dès le cahier des charges du fabric — c'est une donnée que les équipes réseau oublient souvent de communiquer aux équipes applicatives, qui la découvrent alors au moment d'un incident de performance.