Pourquoi Nicira a abandonné le contrôle matériel OpenFlow
Dans un entretien avec nos collègues américains de SearchNetworking.com, Martin Casado, le fondateur de Nicira, revient sur la stratégie de la firme en matière de virtualisation de réseau et de SDN et explique pourquoi elle a renoncé au support d'OpenFlow pour le pilotage d'équipements réseaux matériels dans le datacenter.
Dans un entretien avec nos collègues américains de SearchNetworking.com, Martin Casado, le fondateur de Nicira, revient sur la stratégie de la firme en matière de virtualisation de réseau et de SDN et explique pourquoi elle a renoncé au support d'OpenFlow pour le pilotage d'équipements réseaux matériels dans le datacenter.
Martin Casado est le co-fondateur de Nicira et concepteur du protocole OpenFlow
Lorsque le fondateur de Nicira, Martin Casado, préparait son doctorat en sciences informatiques à Stanford, il y a cinq ans, il s’est donné pour mission de transformer la façon dont les réseaux sont exploités, afin de pouvoir maintenir le rythme imposé par l’automatisation qu’a apporté la virtualisation au monde des datacenters.
Casado pensait que son invention, le protocole OpenFlow, pourrait résoudre ce problème mais explique désormais qu’il avait tors. Le contrôle d’équipements matériels par OpenFlow – qui est aujourd’hui à la mode chez les équipementiers – n’est pas la réponse. Il a ainsi décidé de choisir une nouvelle approche avec la technologie le la virtualisation de réseau basée sur latechnologie de « l’overlay », et VMware a tellement apprécié cette stratégie que la société a dépensé 1,2 Md$ pour acquérir Nicira.
« Le problème est que nous nous sommes trompés et je pense qu’une large part de l’industrie n’a pas réalisé à quel point nous avions tord », a expliqué Casdo lors d’une session de présentation organisée avec plusieurs journalistes dans les locaux de VMware à Cambridge, près de Boston.
Casado a créé OpenFlow afin de découpler le plan de contrôle du plan de données dans les équipements réseau et transférer le contrôle du réseau à un « cerveau central », le contrôleur. Cette innovation était censée permettre de rendre le réseau programmable afin de transformer l’exploitation des réseaux. « Ma thèse à Stanford était qu’il s’agissait du moyen d’automatiser le réseau » explique-t-il. « Les trois premiers ingénieurs chez Nicira ont donc rédigé ce protocole et nous avons effectué une bonne partie des travaux préliminaires permettant de comprendre les limitations des SDN ».
OpenFlow continue à avoir du sens dans certains cas, notamment pour l’ingénierie du trafic, explique Casado. Le déploiement du protocole au sein du réseau d’interconnexion de DataCenters de Google en est un parfait exemple. Mais pour ce qui est de la virtualisation du réseau de datacenter, OpenFlow n’est pas la bonne voie, ajoute-t-il
Des commutateurs virtuels plutôt que des commutateurs physiques OpenFlow
« Au cours de la première année, nous avons réalisé que quelque chose d’important se passait » indique Casado". La virtualisation des serveurs a transformé la couche d’accès au réseau dans les datacenters. Les commutateurs virtuels embarqués dans les hyperviseurs, notamment le vswitch de VMware, sont devenus la nouvelle bordure du réseau. Et si cette nouvelle bordure réside sur des logiciels dans les serveurs, pourquoi se casser la tête à utiliser Openflow pour contrôler des commutateurs physiques ? Pour Casado, un commutateur virtuel était la solution idéale pour la virtualisation du réseau de datacenter pour deux raisons : "tout d’abord il fonctionne sur une architecture x86 et x86 est très flexible. Nous savons comment le programmer. Ce n’est pas comme s’il fallait ciseler des algorithmes pour un ASIC propriétaire. Si je veux changer la façon de propager le trafic, j’écris juste un nouveau programme.
"Ensuite, [un commutateur virtuel] est proche de la bordure. L’industrie réseau à une tradition sordide consistant à essayer de deviner ce qu’il se passe sur les serveurs. Si vous tournez sur le serveur, vous avez accès à cette richesse sémantique en bordure à laquelle vous n’aviez jusqu’alors pas accès. Quelles adresses sont écoutées ? Quels utiliateurs se connectent à quelle machine ? Le niveau de visibilité dont vous disposez est un rêve pour les professionnels du réseau ».
Ces constats ont amené Casado et son équipe à réévaluer leur approche et à prendre un chemin différent. « Nous avons eu ce moment « aha » indique Casado.
Nicira a ainsi décidé d’utiliser OpenFlow pour la virtualisation du réseau mais a basculé son approche du contrôle matériel au contrôle logiciel afin de piloter les commutateurs virtuels. Pour Casado, il s’agit d’une approche qui se justifiait totalement. Après tout, la propagation de paquets (paquet forwarding) n’est pas le problème dans les réseaux modernes. Les réseaux actuels sont toujours extrêmement bons à déplacer des paquets vers leur destination finale. Ce sont les couches de politiques et les couches opérationnelles au-dessus du réseau qui posent problème et ralentissent l’exploitation. Plus spécifiquement, la mise en œuvre des listes de contrôle d’accès (ACLs), des VLAN, du partitionnement réseau ou de la facturation étaient autrefois des fonctions que les professionnels du réseau pouvaient définir une fois pour toutes et oublier à l’ère des réseaux statiques. Mais lorsque la virtualisation de serveur à permis d’accélérer le provisioning de nouvelles applications et permis la mobilité des VM, les processus manuels sont devenus ingérables.
Casado a alors estimé que ces casse-têtes opérationnels ne devaient pas être réalisés sur les équipements réseau mais pouvaient être déplacés vers les commutateurs virtuels pouvant être contrôlé par des logiciels. C’est ainsi que la plate-forme Nicira Network Virtualization Platform est née, et c’est aussi ainsi que les overlays réseaux sont devenus un sujet chaud dans le monde des SDN.
Le problème avec le contrôle direct des matériels par OpenFlow
Néanmoins de nombreux équipementiers et professionnels des réseaux sont intéressés par la mise en œuvre d’équipements OpenFlow pour virtualiser leurs réseaux de datacenters. Pour Casado, il y a plusieurs raisons pour lesquelles cela ne fonctionnera pas. Le premier obstacle est tout simplement l’écosystème des équipementiers. « Vous demandez aux constructeurs de supporter OpenFlow dans leurs commutateurs, alors qu’ils n’ont guère d’avantages à le faire, car d’une certaine façon vous les privez d’une partie de leur plus-value », explique-t-il. "J’ai rédigé les premiers protocoles OpenFlow en 2007 et depuis certains ont annoncé des équipements, mais il n’y a guère qu’une poignée de commutateurs OpenFlow utiles. Tous ceux qui ont un commutateur OpenFlow utile, ont aussi leur propre contrôleur, et je suis certains qu’ils utilisent leur contrôleur et leurs commutateurs d’une façon telle que les deux sont liés afin de maintenir la dépendance [des utilisateurs]. Et pour ce qui est de créer une communauté active [autour d’OpenFlow], c’est tout simplement trop difficile du fait de la gestion des partenariats business ».
Nombre de constructeurs ont activé OpenFlow sur leurs commutateurs, aussi que veut dire Casado par un commutateur OpenFlow utile ? En fait, la plupart des vendeurs n’ont pas construit de commutateurs avec des tables de forwarding suffisamment grandes pour que cela soit utile dans un datacenter. Dans un commutateur typique à base d’ASIC ? il y a une table d’ACL, une table de niveau 2 et une table de niveau 3. Aucune de ces tables ne peut supporter correctement OpenFlow dans le DataCenter.
"OpenFlow dit que le monde doit être ainsi: vous avez une table avec un système de look-up à 11-tuple, qui est quelque chose de très général et vous devez en supporter un très grande nombre. Pour se conformer à OpenFlow, la plupart des constructeurs vont tout simplement surcharger une de leurs tables existantes, qui sera peut-être capable de supporter 5 000 entrées. Et ils vont tenter de faire entrer au chausse-pied OpenFlow dans cette table. Ces ASIC n’ont tout simplement pas été conçus pour cela. On tente d’adapter OpenFlow à cette situation, mais cela va être très difficile."
Les tables de forwarding Openflow disponibles sur la plupart des commutateurs modernes dont suffisantes pour des travaux de recherche de d’expérimentation, indique Casado. Elles répondent aussi aux besoins d’ingénierie de trafic. "Mais le niveau de flux et de trafic qui caractérisent le datacenter moderne implique que vous devriez utiliser un protocole de niveau 3 ». "Et OpenFlow ne fonctionnera pas pour élaborer la matrice de forwarding pour des commutateurs de datacenter. »
Il y a-t-il une place pour le contrôle d’éléments matériels OpenFlow dans la stratégie de Nicira
Cela signifie-t-il que Nicira et son nouveau propriétaire, VMware, se satisfont de ne contrôler que des éléments logiciels. Pour Casado, il y a trois domaines où sa technologie devra s’interfacer avec des équipements matériels et cela requerra autre chose qu’une implémentation standard d’OpenFlow. Le premier est la gestion de la QoS. La gestion de plus de files d’attentes est une bonne chose. Plus vous en avez dans votre matériel et plus vous pouvez fournir de niveau de QoS aux utilisateurs. Si j’ai huit files, je ne peux fournir que huit niveaux de services. Si j’ai un million de files, je peux garantir un niveau de SLA à chaque tenant. La gestion de la QoS requèrera un modèle plus simple pour l’exploitation Ethernet l’administration et le management, de façon que Nicira et d’autres technologies puissent faire du debugage et de la gestion d’incident sur les workloads physiques et virtuelles.
La technologie de virtualisation réseau devra aussi s’interfacer avec les commutateurs de haut de rack pour les applications historiques qui n’ont pas été virtualisées. "Il faut pouvoir contrôler les commutateurs top of the rack afin d’incorporer ses applications physiques dans les réseaux virtuels et cela requiert une interface de type OpenFlow ».
Enfin, les contrôleurs de virtualisation réseaudoivent s’interfacer avec des équipements réseau (firewall, ADC, etc…) et une interface de type OpenFlow est aussi requise.
"Je pense qu’OpenFlow est une interface de trop bas niveau pour cela » explique Casado. C’est pourquoi nous en proposons une nouvelle, OVSdb-config. C’est l’interface que nous utilisons pour Open vSwitch avec OpenFlow. Cela nous permet de gérer des états de plus haut niveau. C’est le protocole que nous espérons que les utilisateurs vont mettre en œuvre, mais cela n’a pas d’importance ».
Pourquoi ? Simplement parce que pour Casado, n’importe quel protocole fera l’affaire tant qu’il est ouvert, encourage l’innovation et fait le boulot ».
Article en anglais de Shamus McGillicuddy, SearchNetworking.com, adapté par Christophe Bardy, LeMagIT.fr
