Christophe Cuenot

L’évolution des architectures réseaux en data center

L’informatique est un monde en perpétuelle évolution, et l’architecture réseau des datacenters n’échappe pas à la règle. Les moteurs de ces évolutions sont nombreux, que ce soient les progrès techniques, ou encore les évolutions des usages et des besoins….

Au cours de cet article, nous allons aborder l’orientation actuelle des architectures en data center. Mais commençons par présenter l’architecture qui était très courante jusqu’à présent.

Les design historique / évolution….

Le trio cœur, distribution et accès

Le design réseau des datacenters repose historiquement sur une organisation à trois grands niveaux.

Le premier, l’accès, assure la connectivité aux serveurs. Ce niveau peut être mis en œuvre de différentes manières. Allant d’une approche très centralisée, avec des solutions, qui regroupent toutes les connexions dans un point unique du data center, impliquant la concentration du câblage dans cette zone, à des alternatives de type top of row et top of rack permettant de rapprocher les commutateurs des serveurs et donc de réduire ces points de concentration du câblage.

Dans les architectures dites top of row, un ou plusieurs commutateurs sont installés pour irriguer une rangée de baies serveurs. Ces derniers sont donc connectés vers ce point de concentration relativement proche.

L’architecture top of rack repose sur la même idée, seulement cette fois-ci, les commutateurs sont mis au plus proche des serveurs, c’est-à-dire directement dans les baies.

Il est à noter que les deux dernières approches coexistent, l’approche centralisée étant en perte de vitesse.

Cette couche d’accès, existe toujours dans les architectures plus récentes, mais son fonctionnement a évolué. Dans les architectures à trois niveaux, elle sert avant tout à offrir une connectivité aux ressources informatiques sans vraiment apporter de traitement.

Le niveau de distribution/agrégation permet l’agrégation des accès. Ce niveau est généralement utilisé pour faire de la commutation et offrir un niveau de résilience avec les commutateurs d’accès.

Sa constitution dépend directement des choix et des besoins. Généralement, ce niveau permet de pallier les pannes via la multiplication des liens d’interconnexion vers les commutateurs d’accès. Selon les technologies utilisées, certains liens d’interconnexions ne sont utilisés qu’en cas de panne. Ce fonctionnement est de plus en plus rare dans les architectures modernes compte tenu de cette sous-utilisation des liens.

Enfin le dernier niveau, le cœur (core), assure le routage. C’est-à-dire le passage d’un réseau à un autre. Des variantes existent, mais c’est souvent sur ce niveau de l’architecture que l’on branche les interconnexions vers d’autres réseaux, les équipements de filtrages….

Ce design est souvent évoqué sous la dénomination Nord / Sud. L’origine de ce terme vient de l’habitude de représentation de ces réseaux. En haut, le nord, l’extérieur (internet, les sites distants…) puis les cœurs (avec quelques équipements de sécurité intermédiaire…), en bas, le sud avec les commutateurs d’accès et les serveurs.[/vc_column_text]

L'évolution des architectures réseaux en data center : Coeur x distribution

Sur le schéma ci-dessus, les liens en rouge représentent des liaisons généralement inactives.

Cette approche qui subsiste encore, ne répond plus aux besoins des applications modernes.

Les technologies comme l’hyper-convergence, la virtualisation, le big data… ont complètement changé notre manière d’interagir avec les données.

Avec l’évolution des usages, le trafic reste principalement à l’intérieur du DC (Data Center) circulant entre les différents serveurs pour nourrir différentes applications. Ce type de trafic est dit de type Est/Ouest. Cette terminologie est rentrée dans les usages, elle est d’ailleurs reprise dans les solutions de SDN, mais constitue le pendant du Nord/Sud que l’on vient d’évoquer.

Une autre contrainte du design 3 tier (Cœur/Distribution/Accès) est son manque de souplesse. Pour augmenter la capacité, il faut augmenter les couches de distribution/agrégation et/ou le cœur. Ce type de changement, dit scale up, nécessite des investissements importants qui peuvent être un frein à une évolution rapide des besoins.

Leaf and spine

Le design que l’on rencontre de plus en plus est de type leaf and spine, feuille et colonne vertébrale dans la langue de Molière. Dit comme cela, cela n’éclaire pas sur le fonctionnement. Concrètement, les commutateurs leaf représentent les commutateurs TOR (Top Off Rack) et les spines sont les commutateurs de distribution. Les commutateurs leaf ne sont pas connectés entre-deux.[/vc_column_text]

L'évolution des architectures réseaux en data center : Design leaf x spine

Exemple de design leaf and spine

La couche cœur (core) disparaît dans cette architecture. La couche spine est constituée de commutateurs assurant également le routage. Dans les architectures Leaf-Spine, les commutateurs de la couche leaf sont connectés à plusieurs, voire tous les équipements de la couche spine.

Les spines assurent le routage comme pouvait le faire la couche cœur du modèle 3 tier, mais ils permettent aussi un échange vers les leafs sans avoir de liens bloqués. Ce qui permet une meilleure utilisation de la bande passante. Les puristes pourront arguer que cela était faisable dans les architectures 3 tier. Oui, c’est effectivement possible, mais ce n’est pas le fonctionnement natif des architectures 3 tier, ce sont des adaptations, des améliorations.

Pour les communications serveur à serveur, dans une architecture à trois niveaux, les échanges vont de l’accès/distribution/cœur/distribution et enfin accès. Alors que la chaine de communication dans le modèle Leaf-Spine est nettement plus court (leaf/spine/leaf). Cela permet une amélioration de la latence car le trafic traverse moins d’équipements.

Un autre élément significatif est la réduction des goulets d’étranglement, dans une architecture 3 tier, un grand nombre d‘échanges transitent par les cœurs, ils constituent donc des points de concentrations. Ce problème est réduit dans une architecture Leaf-Spine.

Comment dimensionner son architecture Leaf-Spine ?

Avant de répondre à cette épineuse question, il est nécessaire d’introduire la notion de sursouscription. C’est un concept relativement simple, mais prenons un exemple, un commutateur de 48 x 1Gbps port d’accès et 2 x 10Gbps pour les interfaces d’uplinks. La bande passante globale des interfaces d’accès est de 48Gbps (48×1) et celle des uplinks de 20Gbps (2×10). Donc le taux de souscription est de 48 : 20 ou 2,4:1.

Dans le cas d’un design idéal, un taux de 1 garantit l’absence de congestion. Dans la pratique, ce taux varie, mais il est souvent égal ou inférieur à 3 : 1

Pour définir une architecture leaf and spine, il convient de connaitre précisément le nombre d’équipements qui seront connectés, cela permet de définir la couche leaf. Celle-ci dépendra également de l’urbanisation du data center (top of row, top of rack…). Une fois la couche leaf définie, la couche spine pourra être dimensionnée en prenant en compte le taux de sursouscription. À noter que ce taux peut aussi être adapté pour quelques parties du réseau comme les espaces de stockages. Bien évidemment, d’autres éléments (les interconnexions, les technologies de SDN, les outils de sécurité…) sont à prendre en compte pour mettre en œuvre un design adapté et évolutif.

L‘un des intérêts de l’architecture Leaf-Spine est notamment la souplesse pour augmenter le débit ou la connectivité en ajoutant simplement des leads ou des spines.

Le design Leaf-Spine constitue, notamment via son maillage, un point de départ pour la mise en place de service de type SDN (Software Define Network) au sein du data center.

Enfin pas si novateur ce design…

L’architecture leaf and spine peut aussi se nommer Clos Fabric. Elle fait référence à Charles Clos, qui en 1952, pour des contraintes financières, a créé ce design pour les commutateurs électromécaniques utilisés dans les communications téléphoniques.

Les architectures réseau en data center ne se résument pas à ces designs, il y a de nombreux autres facteurs à prendre en compte qui dépassent largement le cadre de cet article. Si vous souhaitez plus d’informations ou tout simplement faire évoluer votre infrastructure réseau, n’hésitez pas à nous contacter : contact@idna.fr

Articles associés

L’évolution des architectures réseaux en data center

12 juillet 2021
L’informatique est un monde en perpétuelle évolution, et l’architecture réseau des datacenters n’échappe pas à la règle. Les moteurs de ces évolutions sont nombreux, que ce soient les progrès techniques, ou encore les évolutions des usages et des besoins…. Au cours de cet article, nous allons aborder l’orientation actuelle des architectures en data center. Mais […]

LE ou LA Wifi ? On ne sait pas trop mais c’est déjà la version 6

3 mars 2021
Comme vous l’aurez deviné, on ne va pas discuter ici de l’importance d’utiliser le pronom masculin ou féminin pour l’acronyme wifi, mais bien de cette “version 6” qui chamboule tout – à commencer par sa nomenclature. Les puristes amateurs de l’apprentissage par cœur des références de RFC telles que les classiques 1145 ou 2549 (sacrés pigeons […]
Partager cet article
Derniers articles

Comment agir sur nos Datacenters afin de réduire leur consommation énergétique ?

Réduire la consommation énergétique des centres de données : Les Datacenters ont un grand impact sur l’empreinte carbone et leurs émissions totales de gaz à effet de serre sont en augmentation constante. L’objectif est ici de vous faire découvrir quelles sont les pistes à explorer pour réduire la consommation d’énergie et l’impact environnemental de nos […]

L’évolution des architectures réseaux en data center

L’informatique est un monde en perpétuelle évolution, et l’architecture réseau des datacenters n’échappe pas à la règle. Les moteurs de ces évolutions sont nombreux, que ce soient les progrès techniques, ou encore les évolutions des usages et des besoins…. Au cours de cet article, nous allons aborder l’orientation actuelle des architectures en data center. Mais […]

Les Devops et l’Agilité : les pires ennemis de la Sécurité…ou pas ! (2/2)

Nous l’évoquions dans un précédent article (les devops et l’agilité pires ennemis de la sécurité ou pas 1/2), Devops et agilité ne font pas forcément bon ménage avec la sécurité. Cependant, loin d’être une fatalité, cette opposition permet au métier de la sécurité d’évoluer avec le temps. À l’image de l’essor de l’IT et de […]

L’Analyse d’Impact du Transfert des données personnelles hors UE

L’Analyse d’Impact du Transfert des données personnelles hors UE: Au mois de juillet 2020 et suite au jugement Schrems, La Cour Européenne de Justice a décidé que les Clauses Contractuelles Standards ou Types (CCT) étaient valides et que le Privacy Shield EU – US n’était plus un instrument adéquat pour permettre le transfert de données […]