L'un des métiers d'Intrinsec, la vente d'énergie informatique via nos offres Infogérance On Demand IODE, s'appuie sur le concept du "Private Cloud HQ". C'est à dire que vous disposez d'un ensemble de serveur, peu importe vraiment où ils sont dans l'infrastructure, le modèle, la marque, les spécifications technique, etc..., qui répondent à vos besoins métiers. Et ils y répondent sans interruption de service, à coup sûr.
Quand on parle de Cloud Computing, on parle immédiatement après du transport des informations, et encore juste après du transport sécurisé de ces informations. Notre état d'esprit et notre réponse à ce sujet est claire : les processus métiers d'une entreprise, le coeur de son business, les informations qui constituent ses ressources les plus précieuses, méritent un traitement adéquat, écartant tous risques.
De facto, on se doit de réfléchir à une infrastructure de communication qui soit à la fois mutualisée, redondante, étanche entre les clients, segmentée, et capable d'accueillir un nombre sans cesse croissant de nouveaux clients sans déperdition de qualité.
Ce que nous avons actuellement : un réseau très flexible et redondé, permettant de déplacer à la volée la production de Nanterre à Lyon et ce très rapidement. (En faits : 15 minutes pour déplacer la production d'un client en mode "hébergement d'infrastructure Web" de Nanterre à Lyon, 10 serveurs et un cluster Firewall.)
L'infrastructure actuelle, basée sur 802.1q, présente des limitations évidentes : manque de vlans, chevauchement du plan de numérotation des vlans avec ceux de nos plus grands clients, transport à l'intérieur de l'infrastructure des adresses MAC des postes utilisateurs finaux dans les tables de commutations des coeurs, et augmentation sensible du nombre de broadcast par seconde sur le réseau, à cause de ces même postes utilisateurs finaux, qui sont en nombre.
L'objectif est de garder la flexibilité du L2, tout en optimisant le fonctionnement de la collecte des sites clients, et en réduisant le transport de Broadcast sur l'infrastructure.
Fort heureusement, des technologies sommes toutes récentes nous permettent de palier aux limitations de 802.1q, et à l'explosion des tables de commutation. Pour limiter le nombre de broadcast par seconde sur l'infrastructure, il n'y a pas de miracle, il faut faire rustique : remonter en niveau 3 et router les paquets ! Il n'est pas envisageable d'utiliser des technologies comme Stormcontrol, qui engendrerai plus d'effets de bord pervers pour un résultat au final mitigé.
Prenons les technologies que nous étudions dans ce projet dans l'ordre :
1°) QinQ ou encore "Provider Tag", ou encore "Vlan Tunneling", ou encore IEEE 802.1ad
Le principe est simple : il s'agit d'architecturer le réseau autour d'un principe customer / provider, et d'attribuer à chaque customer un VLAN ID. Cet ID est unique pour le client, et va segmenter le trafique sur l'ensemble de l'infra. Le client est libre d'utiliser sur sa propre infrastructure privée virtuelle les vlans qui lui conviennent.
Dans les faits, il faut considérer la trame Ethernet standard. En 802.1q, on rajoute un tag vlan à la trame pour la différencier. Et bien c'est le même principe en QinQ, sauf que la trame est déjà taggée. On sur-tag celle-ci. Elle se retrouvera donc avec deux tags : un tag provider, et un tag spécifique au client.
De facto, on se retrouve avec 4096 clients possibles sur l'infrastructure, ceux-ci disposant eux même de 4096 vlans pour construire leur réseau.
Nous sommes, du coup, capables d'intégrer de façon transparente un client à l'infrastructure réseau L2 mutualisée, en assurant la capacité de production de tous ses vlans sur les châssis Blade Center System H IBM et en garantissant l'étanchéité du trafique entre les différents clients.
Cette technologie et les fonctionnalités de modification des tags software (Vlan Mapping) ont fait l'objet d'un proof of concept qui a porté ses fruits.
L'infrastructure d'accès client et de coeur de réseau sera full Cisco.
2°) Mac-In-Mac ou encore Provider Backbone Bridge ou encore 802.1ah
La technologie PBB (Provider Backbone Bridge) consiste, sur le même principe que QinQ, à réencapsuler la trame initialement transmise par le client. Mais au lieu de s'intéresser au VLAN ID, on va s'intéresser aux adresses MAC source et destination.
Lors qu'une machine, relié en L2 à l'infrastructure Intrinsec, émet une trame, celle-ci comporte une MAC source, et une MAC destination, chacune unique. Et il y a autant de MAC que d'équipement sur l'infrastructure réseau du client. Vu d'Intrinsec, il y a autant de MAC que d'équipement réseau sur l'ensemble des infrastructures réseau de l'ensemble des clients d'Intrinsec, ce qui commence à faire un nombre important d'adresse !
Un petit rappel sur le fonctionnement d'un commutateur : un commutateur (switch) maintient une table de commutation, une sorte de "table de routage" en plus simple, étant donné qu'elle n'a que deux informations : l'adresse MAC, et le port sur lequel le switch voit l'adresse MAC. C'est ce qui fait l'intelligence du commutateur et sa capacité à commuter le trafique uniquement sur les ports qui en ont besoin.
Les commutateurs de coeur de réseau d'Intrinsec ont donc de ce fait une table de commutation contenant l'ensemble des adresses MAC des équipements des clients, et d'Intrinsec, communiquant en niveau 2, afin de pouvoir relier le trafique sur les bons ports.
Le but de PBB est de remplacer les adresses MAC des équipements terminaux par ceux des switchs de l'infrastructure de coeur de réseau, en faisant une sorte de "NAT" d'adresse MAC.
Dans les faits, le switch "réceptionnant" le réseau client transmettra sur le backbone Intrinsec des trames avec sa propre adresse MAC, à destination d'une adresse MAC pré-configurée comme étant sa destination pour le client donné, créant ainsi un "tunnel de MAC". La commutation de la trame se fait alors avec des adresses des équipements du Backbone, et non plus celles du client final, réduisant ainsi fortement la taille de la table de commutation des coeurs.
Nous sommes à l'étape de maquette sur cette technologie. Nous l'exploiterons sur du matériel Cisco.
3°) Limitation des broadcast par la segmentation L3 et le routage
L'équipe Infrastructure d'Intrinsec a toujours apprécié les solutions simples et rustiques. C'est celles qui fonctionnent le mieux et donnent les résultats les plus convaincants pour nos clients.
De fait, pour limiter les broadcast sur l'infrastructure, il faut tout simplement les éliminer à la source ; nous mettons donc en place une infrastructure de routage LAN d'une capacité de plusieurs gigabits par secondes, afin d'assurer une qualité de service optimale sur les flux de données qui seront routées.
La technologie de routage multi-client n'a cependant pas encore été retenue, nous faisons toujours des recherches sur ce sujet, et nous maquettons les infrastructures possibles. Mais deux fondeurs sont en lisse : Cisco et Juniper.
Commentaires récents