24 mai 2013

Un des sujets récurrents quand on parle Datacenter, en dehors de la notion de SDN, concerne les technologies à mettre en œuvre pour construire son infrastructure réseau. Celle – ci doit permettre d’assurer une résilience maximum, de fournir un débit et une latence optimum tout en disposant d’une administration efficace et enfin elle doit être évolutive pour permettre d’absorber les besoins futurs.

Jusqu’à maintenant, ces problématiques étaient adressées par l’utilisation des stacks permettant d’agréger jusqu’à 10 équipements en général. Ainsi, il était possible de double attacher les serveurs sur la stack pour gérer la résilience à l’accès, agréger les liens entre les entités de switching pour la résilience des uplink sans utiliser de Spanning Tree. Seulement, cette solution présentait quelques inconvénients. En effet, ils sont rares les datacenters se contentant de 10 Switchs il fallait donc multiplier les points d’administration. De plus, l’ensemble du routage Intervlan nécessitait de repasser par un point central.

Aujourd’hui de nouveaux usages rendent cette méthode peu efficace compte tenu de l’augmentation des débits, du besoin de réduire au maximum la latence, du développement FCoE…, il est nécessaire de produire des architectures permettant de tenir compte de ces points et ainsi faciliter l’amélioration complet du SI.

Quelles solutions sont disponibles ?

De nouvelles solutions sont donc apparues pour permettre d’apporter des réponses concrètes à ces besoins. Cisco, Juniper et Brocade proposent différentes solutions que l’on peut regrouper en 2 catégories distinctes :

  • Solutions basées sur l’usage de protocoles et d’équipements spécifiques.
  • Solution propriétaire basée sur le matériel d’un éditeur.

Les Solutions Protocolaires.

Cisco propose avec son environnement Nexus la notion de Fabric Ethernet permettant la convergence Ethernet / FCoE. Cette architecture N-Tiers reprend un design assez proche du modèle utilisé présenté au début de cet article avec la notion d’équipement de coeur / Agrégation et une distributionen 10G / 1G. Le problème de base qui se pose est d’assurer l’utilisation optimum des liens ainsi que la redondance.

En effet, l’infrastructure Nexus ne proposant que du niveau 2, il n’est pas possible de segmenter les domaines via une couche de routage. Il faut donc s’appuyer sur des protocoles permettant d’assurer la résilience du lien L2. Le xSTP n’est pas non plus la solution puisque celui – ci ne permet pas de disposer de l’ensemble des liens en mode A/A (et même MSTP/VSTP/… ne permettent pas d’industrialiser et d’optimiser les liens dans un large environnement DC). Cisco se base donc sur le protocole TRILL défini par l’IETF (RFC 5556 / 6325 / 6326 ) pour permettre de former la fabrique entre les différents équipements.

TRILL est aussi la base protocolaire utilisée par Brocade pour permettre de faire fonctionner sa fabrique Ethernet.

Comment fonctionne TRILL ?

Le fonctionnement de ce protocole est assez proche du mécanisme de Spanning Tree et c’est normal compte tenu que la créatrice du STP, Radia Perlman, à plus que largement participé à la rédaction du protocole TRILL.

Ce protocole fonctionne donc directement sur la couche L2 du modèle OSI et se base sur une implémentation d’IS-IS via l’ajout d’un TLD spécique à TRILL. L’avantage d’IS-IS est qu’il s’agit d’un protocole permettant l’échange d’informations en mode link-state sans nécessité une couche IP.

Lorsqu’un switch TRILL (RBridge) recoit un paquet ethernet, il l’encapsule avec un entête spécifique et le transmet au RBridge de sortie.

Trill - Use Case
Via l’échange de ces informations, chaque switch dispose alors de l’ensemble des informations pour joindre chaque point du réseau. Cela permet alors d’utiliser l’ensemble des liens disponibles tout en évitant la création de boucle.

Solution hardware : QFabric

Juniper propose une vision différente en proposant une généralisation du virtual chassis : On sépare dans différents modules matériels les fonctions d’un switch. Ainsi, on retrouve les cartes d’interfaces (node), les fond de pannier (Interconnect) et le plan de controle (Director).

QFabric Scheme
L’ensemble des node étant attachés directement au fond de panier via des liens 40Gbps, les données transitent directement du point d’entrée vers le point de sortie sans s’appuyer sur un protocole de diffusion de l’information. En effet, la table de forwarding est commune à la fabrique et non locale à chaque équipement.

De même, le plan de contrôle étant commun à tous les nodes, le niveau 3 est global. Il n’est donc pas nécessaire de recourrir à un équipement tiers et de forcer le passage de l’ensemble des flux routé sur quelques ports.

En résumé.

Comme nous venons de le voir, les 2 approches actuellement en vogue apportent des réponses assez proches l’une de l’autre. Elles permettent notamment de répondre au besoins grandissant de 10Gbps sur les châssis de blade, de faire transiter du FCoE et de fournir un réseau le plus « à plat » possible pour gérer simplement la virtualisation.

Cependant, quelques différences restent présentent et qu’il faut pouvoir garder en tête au moment de son design :

  • TRILL est un protocole jeune, chaque éditeur implémente donc une version qui lui est propre : Cisco appuie son TRILL sur IS-IS mais Brocade le fait sur FSPF.
  • En terme de latence, le lookup de chaque équipement induit un délai. Il est donc nécessaire d’en tenir compte dans les architectures critiques.
  • Le nombre de point de management peut varier fortement : 1 seul dans une solution QFabric a quelques dizaines dans une solution ou chaque bridge est indépendant.
  • La Solution matériel nécessite des optiques spécifiques et un lourd design pour l’évolutivité.

Cet article a pour vocation de présenter les technologies actuellement en vogue pour la construction de Datacenter. LA solution ultime n’existe pas et chaque solution apporte des réponses à différents besoins. Nous serons donc ravi de pouvoir en discuter avec vous.

Partager :

Auteurs