L’architecture LEAF & SPINE

Cet article fera partie d’une série d’articles sur l’architecture LEAF & SPINE. On commencera par une définition de l’architecture, ses avantages du point de vue physique et on parlera dans les articles suivants sur les différents protocoles qui fonctionnent en tandem avec une telle architecture.

Tout d’abord, commençant par la question : Pourquoi dois-je remplacer mon architecture 3 tiers traditionnelle ? ou d’une façon pure technique : c’est quoi le problème que j’essaie de résoudre ?

Pour répondre : on va faire une petite comparaison que j’appellerai « 10 years challenge » entre les applications de dix avant et les applications aujourd’hui.

La plupart des applications d’il y a dix, quinze ans étaient de type Client/Serveur dont le client était à l’extérieur du DC.Par conséquent la morphologie du trafic était de type Nord/Sud dont le nord représente le client et le SUD représente l’application dans le DC.

Aujourd’hui et surtout avec l’arrivée des nouvelles technologies émergentes comme l’hyper-convegé et le Big Data, ses solutions qu’ont complétement changé notre manière d’interagir avec les données, on a constaté la naissance d’un nouveau type de trafic qui reste principalement à l’intérieur du DC circulant entre les différents serveurs pour nourrir des applications différentes. Ce type de trafic est de type Est/Ouest.

D’autre part et pour répondre au besoin initial relatif au trafic Nord/Sud, on a tous installé des switchs bloquant (de quoi je parle ? ça va être plus clair en continuant la lecture) dans nos DC parce que :

• La bande passante était trop chère et donc avoir des switchs non bloquants n’était pas rentable pour les constructeurs donc ils ne proposaient que des switchs bloquants.
• Ces switchs fonctionnent parfaitement avec la morphologie du trafic Nord/SUD car la bande passante du client était toujours inférieure à celle du serveur.

Le besoin aujourd’hui a complétement changé et l’architecture 3 tiers ne répond plus aux exigences. Sans oublier bien évidement l’évolution du domaine du switching en termes de capacité de traitement et bande passante et l’arrivé des switchs qui supportent des interfaces 1/10/25/40/100/400G à des prix abordables.

La définition de l’architecture LEAF & SPINE

L’architecture LEAF & SPINE ou Clos Fabric n’est pas nouvelle car elle a été conçue par Charles CLOS en 1952 pour répondre à une contrainte purement financière relative au coût trop élevé des commutateurs électromécanique qui assurent les communications téléphoniques à l’époque.

Le principe est simple, au lieu d’investir et augmenter la capacité du switch pour supporter plus de lien (mode Scale-UP), On augmente horizontalement le nombre des switchs (Scale Out).

En projetant ce principe sur une architecture DC, on aura quelque chose qui ressemble à ça :

et qui pourra être aperçue comme suit :

Les switchs LEAF(L) représentent les switchs TOR et les SPINES(S) sont les switchs de distribution.

Pas de lien inter-LEAF ou Inter-SPINE !!!

Les avantages de l’architecture LEAF & SPINE :

• Une architecture scalable qui offre un plan de capacité très important (< 100000 serveurs)
• Une architecture flexible et résiliente qui permet :
  • D’augmenter la bande passante montante par le rajout des switchs SPINE
  • D’augmenter la densité des ports en ajoutant des switchs LEAF
• Prédictible dans le sens ou chaque serveur doit passer par trois équipements (LEAF > SPINE > LEAF) pour communiquer avec n’importe quel serveur dans la fabrique.

Une architecture Bloquante vs non bloquante

On entend souvent parler dans les présentations des constructeurs ou dans les spécifications techniques des switchs le mot bloquant ou non bloquant, qu’est-ce que ça veut dire ?

On appelle un switch « bloquant » lorsque la somme de la bande passante de ses ports d’accès est supérieure à celle des interfaces Uplinks. Chaque switch bloquant possède un taux de sursouscription qui n’est que le résultat de la bande passante des interfaces d’accès / la bande passante des interfaces Uplinks

Exemple d’un switch bloquant : un switch qui supporte 48 x 10G port d’accès et 4 x 40G ports Uplinks,la bande passante globale des interfaces d’accès égale 480Gbps et celle des interfaces Uplinks égale 160Gbps donc ceci est un switch bloquant avec un taux de souscription de 480:160 ou 3:1

Le switch non-bloquant est un switch avec une bande passante des interfaces Uplinks est supérieure ou égale à celle de l’ensemble des interfaces d’accès

Exemple d’un switch non-bloquant : un switch du marché qui supporte 48 x 10/25Gbps ports d’accès et 18 x 40/100Gbps ports Uplinks, cela donne une bande passante de 1200Gbps pour la couche d’accès et 1800Gbps pour les uplinks.Ce switch est non bloquant et son taux de sursouscription égale 1:1.

Remarque : le switch non-bloquant reste bloquant si deux serveurs envoient en pleine capacité du trafic vers un troisième serveur.

L’architecture LEAF & SPINE peut être bloquante à cause des switchs ou à cause de nombre des SPINE utilisés.

Quel taux de sursouscription pour mon architecture LEAF & SPINE ?

La réponse classique est « ça dépend » de ce que vous hébergez comme applications au sein du DC, la morphologie des flux ainsi que le volume des flux.la règle d’or, si vous n’avez aucune idée sur le volume du trafic dans votre DC partez avec une architecture LEAF & SPINE avec un taux de sursouscription de 3:1.

Construisant ensemble notre première architecture

Exercice 1

Le prérequis :

Supposant que j’ai besoin de 1000 ports 10G fibre pour mes serveurs et je tolère un taux de sursouscription de 3:1.

Ma solution :

• Je choisi dans mon exemple les switchs LEAF cisco Nexus 93180YC-FX. Ces switchs supportent 48×10/25Gbps + 8×40/100Gbps
• Le nombre des switch LEAFs : 1000/48 = 20 switchs LEAFs
• Pour avoir un taux de sursouscription de 3:1,j’ai besoin que chaque switch LEAF soit connecter vers 4 SPINES en utilisant des interfaces 40G
• Pour la couche SPINE j’ai besoin d’un switch qui possède au moins 20 ports 40G pour connecter mes 20 LEAFs donc je choisi le Nexus 9332C qui supporte 32×40/100G

Exercice 2

Le prérequis :

Un opérateur cloud a besoin de 80000 ports 10Gbps fibres pour connecter ses serveurs dans une architecture LEAF & SPINE non-bloquante.

Ma solution :

• Je prends le switch Nexus 9272Q qui supporte 72 ports 40Gbps
• J’alloue 36 ports 40G du switch 9272Q pour connecter des serveurs et 36 ports pour connecter les SPINEs 
• J’utilise les câbles pieuvre qui permet de subdiviser chaque ports 40G en 4x10G.le switch 9272Q supporte le cable pieuvre sur 35 interfaces 40G donc il ne me reste que 35 ports 40G pour connecter des serveurs
• Avec la configuration ci-dessus,chaque switch 9272Q pourra fournir 140 ports 10G (35 x 4).
• J’ai 36 ports 40G UPLINKS donc j’ai besoin de 36 SPINEs
• Combien de SPINES ? je devise le nombre des ports souhaités par le nombre des ports fournies par chaque switch LEAF 80000/140 = 571 ports 40G.Mon SPINE doit supporter 571 ports 40G.Le châssis 9516 supporte jusqu’à 576 ports 40/100G.

Pour fournir 80000 ports 10G je connecte 140 LEAFs N9272Q sur 36 SPINEs N9516 L’architecture LEAF & SPINE est capable de fournir des milliers de ports en passant d’une architecture de deux niveaux à une architecture à 3 niveaux(3 stages,5 stages) dont laquelle les SPINEs sont considéré des LEAFS pour des SUPER-SPINEs comme dans le schéma ci-dessous :

Conclusion :

On a vu dans cet article, l’architecture LEAF & SPINE est l’architecture idéale pour le trafic Est/Ouest généré aujourd’hui par nos applications.

On a vu aussi comment ce type d’architecture pourra être adéquate pour des infrastructures de taille moyennes à des infrastructure plus larges. Toutefois et comme mentionné dans le début d’article, j’ai défini l’architecture LEAF & SPINE d’un point de vu physique et dans les prochains articles on va essayer de voir quel type de protocole à mettre en place pour que le réseau DC soit fonctionnel.

J’espère que cet article vous a plu et  si vous avez des questions, n’hésitez pas à laisser un message en commentaire ci-dessous ou nous contacter à l’adresse : contact@mhd-experts.com.