A lire sur: http://cloud-experience.fr/vers-une-theorie-evolutionniste-des-reseaux-d%E2%80%99entreprise.html
le 14 mai 2013
le 14 mai 2013 |
D’après vous, à quand remonte la dernière période de glaciation des réseaux dans le datacenter ? Selon les réseaux paléontologues, à environ une bonne dizaine d’années, lorsque le modèle client-serveur régnait en maître sur la planète informatique. A cette époque reculée, une bonne architecture réseau était nécessairement hiérarchique, de préférence bâtie sur un modèle à trois niveaux, conçue pour gérer les flux de trafic client-serveur dits « nord-sud » à l’intérieur et à l’extérieur du datacenter. |
En haut de la pyramide de l’évolution, on trouvait les commutateurs
et routeurs de cœur de réseau, espèce animale pas très agile, mais aux
fortes capacités de commutation et de routage. Juste au-dessous se
trouvaient les commutateurs d’agrégation, une population plus
nombreuse, avec des capacités de commutation moindre que les cœurs de
réseau. Enfin, au bas de l’échelle, la faune des commutateurs d’accès,
directement en relation avec les espèces communicantes comme les
serveurs, les baies de stockage… Et tout cela allait très bien jusqu’à
ce que, au début des années 2000, la météorite de la virtualisation
vienne heurter de plein fouet le datacenter.
SOA, Peer-to-Peer, Vmotion, LiveMigration firent voler en éclat la pertinence de l’approche hiérarchique de l’architecture réseau traditionnelle en posant une question de bon sens. Pourquoi ralentir le flux télécom généré par le déplacement d’une machine virtuelle entre deux serveurs situés côte à côte dans le même rack en faisant transiter ce flux par 3 niveaux de commutation, chacun d’entre eux ajoutant un peu plus de latence ? Le temps des communications nord-sud étant révolu, les communications horizontales (dites est-ouest) devinrent la norme et commença alors à souffler le vent du changement. C’est exactement ce que confirme le philosophe allemand Klaus Meine ; “The future’s in the air / I can feel it everywhere/ Blowing with the wind of change.”
Pire qu’une simple brise, au fur et à mesure que les nuages s’amoncèlent et que le cloud prend véritablement son envol, le vent du changement se transforme aujourd’hui en tempête…
Le Cloud nécessite un bouleversement de la sédimentation des couches réseau
Intelligent design ou théorie de l’évolution des espèces ? Toujours est-il que le bouleversement des conditions d’utilisation du réseau doit désormais se traduire par une adaptation réduisant le nombre de hops, la latence, et optimisée pour le trafic est-ouest qui, si l’on en croit le Gartner, représente entre 75% et 80% du trafic actuel dans un datacenter.
Mais est-ce que « c’était mieux avant » ? « Avant », la périphérie de réseau était préalablement définie comme le point où le serveur était connecté au commutateur, les serveurs étant déployés de manière statique avec un seul système d’exploitation et un ensemble d’interfaces. « Maintenant », avec la virtualisation et l’insertion de vSwitches dans les serveurs, les administrateurs système peuvent aussi contrôler, configurer et gérer la connectivité serveur. De ce fait, les outils de gestion des connexions serveur/réseau doivent évoluer afin d’être plus flexibles et s’adapter à la nature fondamentalement dynamique de l’environnement d’aujourd’hui. En descendant au plus près des serveurs l’intelligence et la capacité de commutation, on peut aisément supprimer la couche intermédiaire des commutateurs d’agrégation. Le trafic entre VM’s reste cantonné entre les tiroirs de commutation des châssis de lames, sans remonter au cœur de réseau. Et pour les serveurs en rack, il suffit d’ajouter un dispositif en Top-of-Rack qu’on chaînera pour assurer les communications horizontales. De trois niveaux hiérarchiques, on passe ainsi à deux, voire un seul !
Au-delà des VM’s, la virtualisation doit également s’appliquer au réseau. Et plutôt que de laisser dormantes des connexions qui ne seront activées uniquement pour assurer un chemin de secours en cas de rupture d’un lien principal, pourquoi ne pas virtualiser les liens et utiliser 100% de leur bande passante en configuration de croisière ? Ce cher vieil algorithme du Spanning Tree Protocol a lui aussi un peu vécu. En poursuivant ce travail de virtualisation, on peut créer des commutateurs logiques qui sont constitués de quelques commutateurs physiques. Le gain ? Adresser les besoins de transfert de données en se dotant d’une couche d’abstraction vis-à-vis des ressources de commutation physiques, sans parler de la simplification opérationnelle que génère une telle solution.
La nécessaire extension du domaine de couche 2 : TRILL / SPB pour fournir un environnement Cloud de production
On le sait, si l’on peut se contenter de commuter (niveau 2) des paquets au lieu de les router (niveau 3), la migration à chaud de VM’s peut alors s’effectuer d’un serveur à l’autre –voire d’un datacenter à l’autre- de manière transparente, sans aucune perturbation pour les applications ou leurs utilisateurs. Ceci nécessite une extension de la couche 2 au sein d’un même datacenter et entre deux datacenters physiquement distants. Dans le premier cas, ce sont les contraintes d’agilité et de déploiement des serveurs qui requièrent la présence d’un même domaine VLAN sur chacun des points d’accès réseau tout en maintenant une interconnexion faible latence entre ces nœuds. L’interconnexion entre deux datacenters est, quant à elle, critique pour les environnements hautement résilients, avec des modèles actif/actif où l’emplacement de la VM est très dynamique.
Pour y arriver, il a bien fallu faire évoluer les normes et les standards d’interconnexion.
A ce jour, deux standards ont émergé : Transparent Interconnect of Lot of Links (TRILL proposé par l’IETF) et le Shortest Path Bridging (SPB proposé par l’IEEE). Tous les deux ont pour objectif de fournir des capacités multi-chemins avec partage de charge sur des liens actifs/actifs, une convergence très rapide en cas de panne, le support d’unicast, de multicast et du broadcast. Si TRILL cible principalement les réseaux d’entreprises , SPB intéresse avant tout les grands datacenters d’opérateurs. Notre ami Darwin poserait certainement la question : l’un de ces deux protocoles l’emportera-t’il ? Pour le moment, la combinaison des technologies TRILL ou SPB et de la technologie de virtualisation IRF (Intelligent Resilient Framework) permet une extensibilité et stabilité sans précédent. De quoi résister aux tempêtes de changement annoncées par le déferlement du cloud sur les réseaux.
En guise de conclusion
Pour que votre datacenter devienne un terrain favorable à l’épanouissement de vos environnements Clouds, pas d’autre choix que de réaligner vos architectures réseau. Horizontalité, débit, faible latence et résilience doivent devenir les nouvelles oasis dans lesquelles vos flux de données trouveront l’énergie nécessaire pour donner performance et qualité de service à vos clouds privés et hybride.
SOA, Peer-to-Peer, Vmotion, LiveMigration firent voler en éclat la pertinence de l’approche hiérarchique de l’architecture réseau traditionnelle en posant une question de bon sens. Pourquoi ralentir le flux télécom généré par le déplacement d’une machine virtuelle entre deux serveurs situés côte à côte dans le même rack en faisant transiter ce flux par 3 niveaux de commutation, chacun d’entre eux ajoutant un peu plus de latence ? Le temps des communications nord-sud étant révolu, les communications horizontales (dites est-ouest) devinrent la norme et commença alors à souffler le vent du changement. C’est exactement ce que confirme le philosophe allemand Klaus Meine ; “The future’s in the air / I can feel it everywhere/ Blowing with the wind of change.”
Pire qu’une simple brise, au fur et à mesure que les nuages s’amoncèlent et que le cloud prend véritablement son envol, le vent du changement se transforme aujourd’hui en tempête…
Le Cloud nécessite un bouleversement de la sédimentation des couches réseau
Intelligent design ou théorie de l’évolution des espèces ? Toujours est-il que le bouleversement des conditions d’utilisation du réseau doit désormais se traduire par une adaptation réduisant le nombre de hops, la latence, et optimisée pour le trafic est-ouest qui, si l’on en croit le Gartner, représente entre 75% et 80% du trafic actuel dans un datacenter.
Mais est-ce que « c’était mieux avant » ? « Avant », la périphérie de réseau était préalablement définie comme le point où le serveur était connecté au commutateur, les serveurs étant déployés de manière statique avec un seul système d’exploitation et un ensemble d’interfaces. « Maintenant », avec la virtualisation et l’insertion de vSwitches dans les serveurs, les administrateurs système peuvent aussi contrôler, configurer et gérer la connectivité serveur. De ce fait, les outils de gestion des connexions serveur/réseau doivent évoluer afin d’être plus flexibles et s’adapter à la nature fondamentalement dynamique de l’environnement d’aujourd’hui. En descendant au plus près des serveurs l’intelligence et la capacité de commutation, on peut aisément supprimer la couche intermédiaire des commutateurs d’agrégation. Le trafic entre VM’s reste cantonné entre les tiroirs de commutation des châssis de lames, sans remonter au cœur de réseau. Et pour les serveurs en rack, il suffit d’ajouter un dispositif en Top-of-Rack qu’on chaînera pour assurer les communications horizontales. De trois niveaux hiérarchiques, on passe ainsi à deux, voire un seul !
Au-delà des VM’s, la virtualisation doit également s’appliquer au réseau. Et plutôt que de laisser dormantes des connexions qui ne seront activées uniquement pour assurer un chemin de secours en cas de rupture d’un lien principal, pourquoi ne pas virtualiser les liens et utiliser 100% de leur bande passante en configuration de croisière ? Ce cher vieil algorithme du Spanning Tree Protocol a lui aussi un peu vécu. En poursuivant ce travail de virtualisation, on peut créer des commutateurs logiques qui sont constitués de quelques commutateurs physiques. Le gain ? Adresser les besoins de transfert de données en se dotant d’une couche d’abstraction vis-à-vis des ressources de commutation physiques, sans parler de la simplification opérationnelle que génère une telle solution.
La nécessaire extension du domaine de couche 2 : TRILL / SPB pour fournir un environnement Cloud de production
On le sait, si l’on peut se contenter de commuter (niveau 2) des paquets au lieu de les router (niveau 3), la migration à chaud de VM’s peut alors s’effectuer d’un serveur à l’autre –voire d’un datacenter à l’autre- de manière transparente, sans aucune perturbation pour les applications ou leurs utilisateurs. Ceci nécessite une extension de la couche 2 au sein d’un même datacenter et entre deux datacenters physiquement distants. Dans le premier cas, ce sont les contraintes d’agilité et de déploiement des serveurs qui requièrent la présence d’un même domaine VLAN sur chacun des points d’accès réseau tout en maintenant une interconnexion faible latence entre ces nœuds. L’interconnexion entre deux datacenters est, quant à elle, critique pour les environnements hautement résilients, avec des modèles actif/actif où l’emplacement de la VM est très dynamique.
Pour y arriver, il a bien fallu faire évoluer les normes et les standards d’interconnexion.
A ce jour, deux standards ont émergé : Transparent Interconnect of Lot of Links (TRILL proposé par l’IETF) et le Shortest Path Bridging (SPB proposé par l’IEEE). Tous les deux ont pour objectif de fournir des capacités multi-chemins avec partage de charge sur des liens actifs/actifs, une convergence très rapide en cas de panne, le support d’unicast, de multicast et du broadcast. Si TRILL cible principalement les réseaux d’entreprises , SPB intéresse avant tout les grands datacenters d’opérateurs. Notre ami Darwin poserait certainement la question : l’un de ces deux protocoles l’emportera-t’il ? Pour le moment, la combinaison des technologies TRILL ou SPB et de la technologie de virtualisation IRF (Intelligent Resilient Framework) permet une extensibilité et stabilité sans précédent. De quoi résister aux tempêtes de changement annoncées par le déferlement du cloud sur les réseaux.
En guise de conclusion
Pour que votre datacenter devienne un terrain favorable à l’épanouissement de vos environnements Clouds, pas d’autre choix que de réaligner vos architectures réseau. Horizontalité, débit, faible latence et résilience doivent devenir les nouvelles oasis dans lesquelles vos flux de données trouveront l’énergie nécessaire pour donner performance et qualité de service à vos clouds privés et hybride.
Aucun commentaire:
Enregistrer un commentaire