Allwyn Sequeira, VMware : "les x86 et les puces réseau vont dominer le monde des serveurs"

Même si VMware est surtout connu comme un spécialiste de la virtualisation de serveurs, son impact sur l'industrie des réseaux a été profonde. La consolidation des serveurs avec VMware a entraîné une hausse des exigences de bande passante ; le commutateur virtuel distribué embarqué dans l’hyperviseur de l’éditeur a virtualisé la couche d'accès au serveur de la plupart des centres de données et la nature dynamique des machines virtuelles est la source d’une grande partie des innovations qui ont lieu aujourd’hui sur le marché des réseaux.

Au cours de son discours lors du récent Interop Las Vegas, Steve Herrod, le CTO de VMware et vice-président senior de la R & D de l’éditeur, a introduit le concept de « software defined datacenter », un terme qui rappelle celui des réseaux programmables (software defined networks ou SDN), l’un des sujets de discussion les plus chauds du moment dans le monde des réseaux. SearchNetworking.com s'est entretenu récemment avec Allwyn Sequeira, le CTO cloud, réseau et sécurité de VMware pour en savoir plus sur les vues de l’éditeur en matière de SDN et de virtualisation de réseau. Allwyn Sequeira a rejoint VMware lors de l'acquisition par ce dernier de Blue Lane Technologies un fournisseur de solutions d'IPS virtualisé, dont il était le CTO.

Venu de Blue Lane, Allwyn Sequeira est aujourd'hui le CTO cloud, réseau et sécurité de VMware.

VMware a commencé à promouvoir le concept de software defined datacenter. Cela rappelle étrangement le concept de SDN. Pourriez-vous élaborer sur ce sujet ?

Allwyn Sequeira : L'idée est nous avons eu vSphere et que la vie est belle. Maintenant nous avons besoin de virtualiser le reste du centre de données. Alors que nous commencions à faire évoluer notre réflexion en direction du réseau, nous avons vu émerger le mouvement des SDN. La plupart de nos concepts autour de la virtualisation de réseau, et certaines des notions de SDN, s’appliquent à merveille au réseau, au « compute », au stockage et à la sécurité. C'est une évolution naturelle que de s’emparer des concepts du SDN et de les intégrer à un concept plus global qui est le software defined datacenter. Au fil du temps, nous nous attendons à voir de moins en moins d’équipements spécifiques [dans les centres de données] et de plus en plus de systèmes x86 avec des logiciels spécialisés.

L'autre constat est que le concept de la machine virtuelle [VM] en tant que conteneur a bien résisté au temps et est devenu la façon d’abstraire un « workload », que ce soit dans le cas de services comme Amazon ou pour VMware. La VM est devenue une unité de virtualisation des serveurs et de virtualisation du poste de travail. De même, pour ce qui est du centre de données, le centre de données virtuel, devient un nouveau conteneur.

Qu'est-ce que vous voulez dire quand vous parlez de centres de données composées de matériel x86 avec un logiciel spécialisé ? Est-ce la vision du futur des réseaux selon VMware ?

Allwyn Sequeira : Plus largement les systèmes x86 et les puces réseaux commerciales sont clairement la tendance du moment. Mon propos est que les Cisco de ce monde ont passé beaucoup de temps et d'énergie sur le développement d’ASIC, mais un grand nombre de logiciels et de contrôle s’effectue de plus en plus sur la partie x86. La plupart des équipements [de datacenter] vont dans cette direction. Si vous regardez à l’intérieur d’un équipement F5 Networks, c'est surtout x86. Regardez un Cisco ASA, et ses fonctions de pare-feu et d’équilibrage de charge. C'est tout du x86. Nous avons des versions de routeurs Cisco qui embarquent un hyperviseur sur x86 afin de permettre d’accueillir un tas de machines virtuelles. Peu de gens le reconnaissent, mais une part croissante du matériel, même dans le monde Cisco, est basée sur des puces x86 et puces réseau commerciales. Donc, la meilleure façon de reformuler mon propos est de dire, que les x86 et les puces réseau commerciales sur étagère vont dominer le monde des serveurs et du réseau.

Cisco pourrait être en désaccord avec vous. Il continue d'affirmer que les ASIC lui donnent un avantage dans le centre de données.

Allwyn Sequeira : Si j’étais Cisco, c'est ce que je dirais. Et si j’étais Cisco, je regarderai quand même les puces réseaux. Si je basais ma franchise uniquement sur des puces réseaux commerciales le message que j’enverrai est que le jeu dans le monde du réseau se déplace vers le logiciel.

Ce que je pense réellement être leur propos, c'est que l’utilisation de puces réseaux commerciales et de puces x86 n’a rien de mal, mais que lorsque vous atteignez des niveaux de consolidation plus élevés, il y a un besoin de scale out pour servir des racks de serveurs x86 et de commutateurs « top of the rack ». Il faut dans tous les cas amener ce trafic vers le cœur. Et pour y parvenir, il faut encore des puces de commutation très rapides, du type que seuls les Cisco et les Juniper de ce monde produisent. Et ceci est un constat valide.

Tout équipement Cisco à trois composantes essentielles : les ports d’entrées et sorties, le logiciel de traitement et ensuite le « FastPath ». Le Fastpath – qui gère le marquage des paquets et les protocoles - est l'endroit où Cisco s'est toujours distingué de ses pairs. Au cœur même de ses équipements, le fait d’avoir des puces rapides et spécialisées peut avoir du sens. Mais tout ce qui fait l’aptitude à la programmation, la gestion du scale-out et l’adaptabilité proviendra à terme des éléments gérant le plan de contrôle de ces équipements.

La stratégie de mise en réseau VMware inclut un support pour OpenFlow ?

Allwyn Sequeira : Nous faisons partie de l'équipe à l’origine de l’Open Networking Foundation et nous sommes membre fondateur de l’ONRC [Open Networking Research Center] Labs.

Si vous regardez les SDN et OpenFlow, ils prescrivent une certaine façon de faire les choses. Extraire le plan de commande, contrôler le plan de données via le protocole OpenFlow, et disposer d’un système de pilotage centralisé.

Nous y sommes presque aujourd’hui. Si tous les équipements réseau supportaient OpenFlow, nous serions en mesure de manipuler rapidement tous les éléments du réseau via OpenFlow, et la vie serait belle.

La réalité est que moins de 1% des commutateurs d'entreprise actuels supportent OpenFlow. Donc, pour ce qui nous concerne, nous allons passer par une étape intermédiaire. Nous mettrons en œuvre les SDN et les notions d'abstraction Ethernet, d’abstraction de services réseau, tels que les pare-feu, les équilibreurs de charge, etc.

Cela s'inscrit dans la mouvance des SDN, avec un plan de contrôle centralisé. Avec des technologies comme VXLAN, nous créons un overlay du réseau actuel. Et même si nous nous plaçons à un niveau supérieur à celui des SDN, nous délivrons les mêmes services que les SDN. Donnez-moi un réseau, permettez-moi d'ajouter des machines virtuelles à ce réseau, et d’y connecter un pare-feu. Cela préserve les API de haut niveau (northbound APIs). Mais pour ce qui est des API de plus bas niveau, plutôt que de commencer à programmer des agents OpenFlow, nous disposons de VXLAN et de réseaux overlay.

Et lorsque les agents OpenFlow seront disponibles en entreprise, nous pourrons faire correspondre nos réseaux virtuels VXLAN avec ceux d’OpenFlow. VXLAN est une technologie d’encapsulation qui s’étend à l’ensemble du réseau. Si le réseau sous-jacent supporte OpenFlow, on peut cartographier la topologie VXLAN et programmer les VLAN VXLAN sur le réseau sous-jacent. Dans l'intervalle, tous les investissements de nos clients en matière d’API de haut niveau et de virtualisation de réseau, avec VXLAN, sont préservés. Ensuite, nous pouvons continuer à faire évoluer ce réseau et aller plus loin en tirant parti des capacités natives OpenFlow lorsque la technologie disposera d’une part de marché significative en entreprise.

 
C'est la même chose que ce que nous avons fait avec la virtualisation de serveurs. Au tout début, nous étions un peu exclus du groupe. Mais une fois que le taux de virtualisation dépasse 50%, vous commencez à optimiser en fonction du virtuel et construisez des ponts vers le physique. La même chose va se passer dans les réseaux. Nous commençons à optimiser les réseaux pour la virtualisation et les réseaux virtuels VXLAN. Lorsque OpenFlow atteindra un taux de pénétration de 50%, nous optimiserons pour OpenFlow. Je regarde cela comme un continuum plutôt que comme un affrontement entre OpenFlow et VXLAN. Cela nous permettra d'insérer OpenFlow dans une organisation en douceur plutôt qu’en remplaçant tout ce qui est en place. OpenFlow est une façon spécifique de programmer le réseau, mais on n’est pas obligé de ne faire du SDN qu’avec OpenFlow.

Si OpenFlow ou quelque autre protocole de SDN décollent vraiment et que vous êtes vraiment en mesure d’abstraire le réseau directement au niveau de chaque appareil plutôt que de reposer sur une technologie d’overlay, quelle valeur pouvez vous en retirer ?

Allwyn Sequeira : Je pense que ce que nous avons aujourd'hui est assez bon pour la plupart de ce que nous essayons de réaliser avec la virtualisation de réseau. En fin de compte, le problème numéro un que nous essayons de résoudre dans les datacenters d'entreprise est la vitesse, l'agilité de provisioning et l'efficacité. Le but d’un « software defined datacenter » est de virtualiser le reste du centre de données. Le provisioning à la VMware a rendu possible le provisioning de serveurs en moins de deux minutes et pour 300 $, alors que dans le passé, il fallait 10 jours et 10 000 $.

Le reste du problème est qu'il faut toujours cinq jours pour provisionner le reste - VLAN, adresses IP, pare-feu, stockage. Si vous pouvez fournir ces réseaux rapidement, vous avez résolu ce problème. Nous croyons qu’avec VXLAN et les SDN, nous avons résolu ce problème de façon substantielle. Aussi, les clients ne nous demandent pas de supporter OpenFlow. Ils demandent de l'agilité de provisioning et une expérience transparente quand ils mettent en œuvre des éléments de compute, de réseau et de stockage. Dans ce cas particulier, OpenFlow ne vous apporte aucun bénéfice immédiat.

Alors pourquoi même envisager OpenFlow dans le centre de données ? Avec OpenFlow, vous obtenez encore plus de granularité, de visibilité et de contrôle. Avec des overlays, pour l’essentiel, cela fonctionne. La plupart des gens construisent leur fabric réseau avec une certaine marge. Avec OpenFlow vous pouvez être beaucoup plus efficace, comme Google l’a montré avec leur WAN. Vous pouvez programmer chaque flux, vous pouvez mettre en place des applications et dire, «Je veux que cette application emprunte ce chemin spécifique à travers le réseau". Lorsque vous voulez un contrôle beaucoup plus précis sur votre trafic, alors vous pouvez étudier OpenFlow. De même, [avec OpenFlow], vous pouvez finalement obtenir de bien meilleures capacités de diagnostic parce que vous savez ce qui se passe quand une application a un problème avec un serveur. Vous pouvez identifier rapidement ce qui n'allait pas avec le serveur.

Mais la plupart des gens ne sont pas encore prêts pour cela. Aujourd'hui, les utilisateurs veulent surveiller leurs réseaux avec les outils existants. Même si la technologie était 100% prête aujourd'hui, il faut un certain temps aux entreprises pour changer les gens et les processus. Si vous avez 200 docteurs de Stanford, que vous possédez votre propre réseau de fibres, que pouvez construire vos propres serveurs dans votre cour, que vous possédez votre propre trafic que vous développez vos propres applications propriétaires, alors OpenFlow est pour vous maintenant.

Donc, les entreprises n'ont pas besoin d’OpenFlow, et elles vont probablement attendre que quelqu'un le commercialise ?

Allwyn Sequeira : Exactement. Si tout ce que vous faites est de travailler sur vos propres applications propriétaires comme Google, Facebook ou Zynga, c'est un problème. Notre problème est très différent. La raison pour laquelle VMware est si solidement ancré dans les entreprises est que 90% de leurs applications tournent depuis des années et des années. VMware a permis à ces applications d’être mise en conteneur au-dessus de la couche de virtualisation, qui vous permet d’insérer un nouveau serveur sans toucher aux applications. Toutes les nouvelles applications dont nous parlons beaucoup en ce moment comme le Big Data Hadoop, ne sont pas la préoccupation de la plupart des entreprises aujourd'hui. En fait le problème est de faire évoluer les applications qui constituent 95% du patrimoine applicatif des entreprises.

Voyez-vous une concurrence entre VMware, Nicira, Big Switch Networks et NEC (les principaux développeurs de solutions OpenFlow, NDLR) ?

Allwyn Sequeira : La vraie question est : est-ce que Nicira et Big Switch sont une fonctionnalité de VMware ? Nous ne cherchons pas à rivaliser avec eux. C’est à eux de prouver qu’ils peuvent résoudre un problème unique dans un domaine important et qui fait sens. Apporter une solution à la virtualisation de réseau dans le cadre d'une pile VMware ? Nous avons la réponse. En d'autres termes, nous ne croyons pas que nous ayons besoin d'une réponse extérieure pour résoudre un problème de virtualisation dans la pile VMware.

Adapté d'un article en anglais de Shamus McGillicuddy, Searchnetworking.com, par Christophe Bardy, LeMagIT.