Avec son contrôleur SDN, APIC, Cisco va créer un écosystème logiciel dont il détiendra seuls les clés. Incontournable dans les réseaux et désormais les serveurs, le succès de son entreprise tiendra aux partenariats qu’il saura créer avec les meilleurs éditeurs.
Au contraire de NSX de VMware, qui propose une solution d’Overlay qui masque le hardware, Cisco, le numéro un des réseaux, a choisi une solution plus radicale, ancrée dans le matériel: un contrôleur SDN (Software Defined Network) qui pilote tout le réseau à partir des applicatifs. Ces derniers devront posséder une sorte carte de visite particulière, un profile pour être reconnus et virtualisés. Lancé en fanfare le 6 Novembre 2013, à New York, le contrôleur SDN de Cisco va pour longtemps définir ce que seront les applications virtualisées en réseau, si tous les vendeurs d’applications sont prêts à jouer le jeu.
Les relations vont évoluer avec VMware
Face à la solution d’overlay NSX de VMware, la guerre est bien déclarée comme nous le pressentions début septembre : « NSX amis et ennemis en vue ». La patronne, Soni Jiandani, Senior Vice president de Insieme (la spin off de Cisco prochainement réintégrée) n’hésite pas à traiter le logiciel NSX de Vmware de « fausse génération SDN ». Il ne ferait que multiplier les éléments d’administration, créerait une complexité supplémentaire en terme de trafic et d’administration tout en laissant un risque pour la sécurité, le soft et le hard « loosely coupled » n’étant pas « verrouillé » comme chez Cisco, « off course ».
La solution SDN de Cisco repose en effet sur le contrôleur central APIC qui est le cœur du serveur de Cisco et pilote directement l’infrastructure réseau via les applicatifs.
L’élément très distinctif d’APIC est de gérer les profils d’applications, sorte de carte de visite pour chaque logiciel. Ces profils décrivent toutes les ressources et services nécessaires à leur bon fonctionnement. Pour Cisco, le profile détermine la bande passante, la qualité de service, les volumes de stockage, la puissance de calcul selon les caractéristiques de l’application.
Le contrôleur APIC, qui n’est ni plus ni moins que le serveur en cluster, pilote l’ensemble du réseau avec ces informations comme une sorte de gros routeur central. Pour expliquer le rôle de l’APIC, le blog d’Eric Debray de Cisco France est explicite (http://gblogs.cisco.com/fr-datacenter/2013/11/07/) : « On retrouve ici la même notion du « service profile » utilisé dans les serveurs Cisco UCS qui a démontré son efficacité en termes d’automatisation des opérations. De la même manière que l’UCS manager pousse des services profiles sur des lames physiques (du serveur), l’APIC va pousser des Applications Network profile sur des équipements réseaux. Pour faire simple l’Application Network Profile est une représentation logique de tous les ressources Datacenter utilisées par une application et de leurs interdépendances. Ces profiles sont définis d’après les besoins de communication, de sécurité et de performance d’une application. »
Image ci-dessous : le contenu des profiles
APIC : Un système qui « ne tombe pas »
L’Apic reconfigure le réseau pour fournir les éléments requis par les « profiles ». L’application, en quelque sorte, reconditionne le réseau en fonction des besoins du moment : plus de puissance, plus de stockage, etc. L’intérêt du SDN, souligné par Cisco, est aussi de ne plus avoir à intervenir sur les différents équipements pour provisionner et modifier les réglages. Le système se modifie tout seul selon les besoins. Les « profiles » applicatifs » paraissent inspirés des étiquettes, « les labels » des réseaux MPLS qui conditionnaient déjà les routeurs des réseaux afin de définir des tunnels spécifiques à des protocoles ou déjà des applicatifs faciles à identifier par leurs entêtes. Ce n’est pas étonnant d’ailleurs que les ingénieurs de chez Cisco -Insienne (Mario Mazzola, Prem Jain and Luca Cafiero)
et c’est le cas chez Juniper ( Kireeti Kompella) soient les mêmes que ceux qui avaient déjà imaginé les commutateurs MPLS il à 7 ans ou huit ans. Un autre remarque anecdotique, ces dirigeants sont entourés presque exclusivement d’ingénieurs indiens, désormais californiens, tous dotés de PHD en télécom, extrêmement humbles et ouverts, c’est du moins ce qui était remarquable lors des premières présentations sur le SDN lors du salon Interop en mai dernier. Que ce soit chez Cisco, Juniper mais aussi chez Nec ou Arista, l’administration des commutateurs SDN parait être devenue une sorte de nouvelle cuisine indienne.
Un matériel très intelligent capable de comprendre open flow
Le contrôleur repose sur la version Cisco d’OpenFlow, « one PK » qui associe les API Cisco aux différentes commandes nécessaires pour la configuration du matériel réseau « à la volée ».
Rappelons qu’OpenFlow n’est à la base qu’une suite de jeu de commandes. Il permet l’accès direct et la manipulation des commutateurs et les routeurs, qu’ils soient physiques ou virtuels. Le matériel «paramétrable» doit disposer pour comprendre les signaux de plusieurs chips, des processeurs de flux OpenFlow comme ceux par exemple de Netronome qui répondent aux injonctions des applicatifs. Ces puces embarquent leurs propres jeux de commandes, des tables de conversions, des identifications de jeux de flux, des systèmes de conversion. Chaque processeur de flux étant programmable, on se rend compte que seul le matériel récent disposant de ces puces pourra exploiter les informations des profiles ( ci joint l’un des dernier switch programmables)
(ci-joint un principe de processeur de flux utilisé à la fois par Juniper et Cisco dans leur derniers switch ouvert à Open flow)
. Mais on peut facilement imaginer que depuis plusieurs années Cisco prévoyait cette évolution en réservant des espaces pour des cartes SDN. Mais il y aura certainement une rupture pour le matériel ancien peut être, mais c’est à vérifier, les récents Nexus seuls seront capables de comprendre les messages des profiles. La plate forme matérielle de référence Nexus 9000 est d’ailleurs présentée comme le remplaçant des modèles catalyst 4500 et 6500, c’est à dire l’essentiel du parc des routeurs. En fait le matériel peut toujours être considéré comme une couche de support , une colonne vertébrale selon le nouveau modèle spine and leaf. Il y a d’un coté le cerveau-colonne vertébrale (spine) et de l’autre, les membres intelligents( leaf). L’expression « route at the spine and switch at the leaf », résume bien l’évolution qui en fait a ramené les trois élements habituels des réseaux (cœur , agrégation et accès) à deux, le cœur et l’agrégation étant désormais réunis dans un seul routeur central.
Une réduction attendue des messages entre routeurs et commutateurs
L’argument de Cisco est de dire que les applicatifs vivront avec leurs scripts de leurs profils et qu’ils seront ainsi indépendants. Ainsi les ACL (Access control List) qui filtrent le trafic sur les adresses source et destination, sur le protocole et le numéro de port n’auront plus à être sans cesse modifiés. Ish Limkakeng, vice-président d’Insieme Networks précisait lors du lancement à New York «Les politiques de circulation restent avec l’application indépendamment du lieu où réside celle ci, de sorte que vous n’avez pas le problème habituel des milliers d’ACL que personne n’est capable de suivre. Lorsque vous modifiez le profil d’application, il est mis à jour par l’APIC pour le garder cohérent. »
Les administrateurs créeront les profils d’application en utilisant le modèle de scripts « extensibles » à la sauce Cisco. La plupart des grands éditeurs, Microsoft, SAP, Oracle aurait déjà rendu leurs applications « APIC ready ».
APIC, et c’est un avantage facile à repérer par rapport à VMWare, prend en charge une variété d’hyperviseurs, dont VMWare vSphere, Microsoft Hyper-V et Red Hat KVM, pour appliquer « des politiques de réseaux virtuels » associés à des machines virtuelles. Il pourra mesurer leurs performances grâce à un management « léger » appelé désormais télémétrie.
Cisco a affirmé qu’il soutiendrait les API pour OpenStack, la plate-forme la plus populaire d’orchestration cloud, ainsi qu’un certain nombre de fournisseurs tels que F5 ou Sourcefire. Ces partenaires auront pour objectif de fournir toutes sortes de services pour l’APIC, comme l’équilibrage de charge, la sécurité et pas mal d’autres fonctions.
Dans l’optique « verrouillée » de l’ACI, Cisco a d’ailleurs annoncé son service « ACI sécurité », qui intègre la gestion des services de sécurité dans le contrôleur, et un nouveau pare-feu virtuel appelé le ASav qui ne sera pas facile d’émuler. Parions que cela ne fera que renforcer l’idée naissante que Cisco s’est approprié le SDN en ne laissant ouverte qu’une toute petite porte pour ses concurrents et partenaires. Affaire à suivre, la disponibilité des serveurs APIC n’étant prévue que pour le second trimestre 2014. Ce qui nous rappelle la remarque de Martin Cassado, le créateur du NSX de Vmware « nos concurrents n’arrêtent pas de gesticuler et de faire parler d’eux. Mais en fait, ils n’ont rien à vendre encore ».
puis