Cisco fait le pari d'ACI contre les SDN

Il y a dix jours, Cisco a levé le voile sur le premier pan de sa stratégie ACI (Application Centric Infrastructure), dont l’objectif est de fournir une riposte au « software defined networking ». L’annonce est en fait la suite des présentations effectuées par Insieme Networks, une start-up filiale de Cisco, lors de CiscoLive et dont Cisco a récemment acquis l’intégralité du capital.

Comme l’explique Christophe Perrin, le directeur des opérations techniques de la division datacenter de Cisco, « le constat de Cisco est que dans les entreprises, l’élément clé qui supporte le business, ce sont les applications. La capacité de déployer rapidement ces applications et de maintenir leur niveau de performance, tout en gérant les règles de sécurité, est donc essentielle ». Le problème est qu’il y a un fossé entre le monde des infrastructures et celui des applications : il peut ainsi s’écouler plusieurs semaines entre l’arrivée d’une nouvelle application et sa mise à disposition des utilisateurs, notamment du fait du temps requis pour le provisioning des ressources et services réseaux, serveur, stockage, mais aussi pour la mise en place des paramètres de sécurité adéquats.

« Tout l’enjeu d’ACI est de proposer une architecture qui va accélérer la mise à disposition de ces applications dans le datacenter. Une architecture qui se traduit par la mise à disposition de composants matériels et d’un nouveau langage permettant de traduire les besoins en infrastructure des applications », explique Christophe Perrin. Si Cisco continue à travailler sur des modèles de programmabilité du réseau de type SDN, dans lesquels le plan de contrôle est largement déporté dans un élément logiciel (à la Nicira), ACI propose un modèle plus intégré où l’intelligence de gestion des flux reste largement le fait des commutateurs constituant la « fabric » du réseau de datacenter.

Encore faut-il pour cela disposer de commutateurs disposant de l’intelligence adéquate. Sans surprise, c’est là qu’intervient la ligne de commutateurs sur laquelle travaillait Insieme Networks, une ligne que Cisco a pour l’occasion rebaptisée Nexus 9000 et qui s’articule autour d’un châssis à haute densité, le Nexus 9500, et un commutateur de « haut de rack », le Nexus 9300. Ces deux équipements sont conçus pour être appairés au sein d’architectures de type Leaf and Spine (colonne vertébrale et feuille), le 9500 agissant comme le tronc et le 9300 comme la feuille. Comme nous l’a expliqué Franck Bonneau, un ingénieur système du constructeur, les deux commutateurs peuvent aussi être utilisés dans un modèle plus classique d’agrégation couplé avec les fabrics Extender de la série Cisco Nexus 2000.
Les deux nouveaux commutateurs de Cisco sont bâtis autour de composants de commutation standards (en l’occurrence des Trident 2 de Broadcom – comme les derniers switchs d’Arista, HP, Dell, Extreme) et y ajoute des ASIC propriétaires développés par Insieme (ceux-ci sont déjà disponibles sur les "line cards" 10G, mais a priori pas sur la 40G actuelle). Les nouveaux commutateurs sont ainsi capables de fonctionner dans deux modes : un mode standard, s’appuyant sur le chipset Trident et un mode dit ACI, utilisant les capacités uniques du chipset Insieme. Nous reviendrons plus loin sur ce dernier mode. Mais avant cela, faisons un petit tour des caractéristiques de nouveaux venus.

Nexus 9500 : un châssis haut de gamme d’une incroyable densité

Le Nexus 9500 est un commutateur 10/40 Gbit/s qui est conçu pour opérer comme le tronc d’une matrice de commutation de niveau 2/3. Dans sa première mouture à 8 slots (des versions à 4 et 16 slots sont attendues pour 2014), le Nexus 9500 se présente sous la forme d’un châssis 13 U capable d’accueillir jusqu’à 288 ports 40 Gbit/s ou 1 152 ports 10 Gbit/s en utilisant des splitters (une telle configuration paraît toutefois peu réaliste tant elle produirait un micmac insensé de câbles).

Le Nexus 9500 (comme d’ailleurs les autres membres de la série Nexus 9000) accepte des interfaces optiques bidirectionnelles développées par Cisco qui permettent aux entreprises de réutiliser le câblage fibre multimode présent dans leurs datacenters. Ces interfaces optiques permettent de déployer du 40 Gbit/s sur des interfaces QSFP+ (l’astuce est que Cisco multiplexe 2 longueurs d’ondes à 20 Gbit/s en mode full duplex). Comme le confirme Franck Bonneau, ces modules optiques supportent les fibres OM4 sur 125m et OM3 sur 100m et plus.

Un autre atout important de la famille 9500 est son refroidissement de l’avant vers l’arrière (front to back) du fait d’une architecture sans MidPlane, qui laisse de ce fait s’écouler l’air de l’avant vers l’arrière du switch. Les caractéristiques du Nexus 9508 devraient lui permettre d’être un concurrent redoutable des derniers commutateurs haut de gamme d’Arista et HP, d’autant que le prix par port semble « raisonnable ». Il faut en effet compter environ 460 000 $ (prix catalogue pour un commutateur configuré avec 8 cartes à 36 ports 40 Gbit/s, soit un peu moins de 400 $ par port 10Gbit/s).

Nexus 9300 : une feuille ou une – petite – épine dorsale

Par défaut, le Nexus 9300 est positionné comme le complément idéal du 9500 en agrégation au sommet de rack. Cisco propose initialement deux modèles dont un commutateur 2U avec 48 ports 10 Gbit/s, le Nexus 9396 PQ et un modèle 3U à 96 ports 10 Gbit/s, le 93128TX. Les deux modèles incluent un emplacement pour un module à 12 ports QSFP+ pour l’upling vers le cœur de réseau. Seuls 8 de ces ports sont disponibles sur le 93128 (soit 96 ports 10 Gbit et 32 supplémentaires avec splitter 10/40 Gbit/s). Il est à noter que le Nexus 9300 peut aussi être utilisé comme un épine dorsale pour un petit réseau de datacenter (et non, Cisco n'a pas appelé cette configuration un mode spline - un hybride de Leaf and spline - comme l'a fait Arista).

Un NX-OS revu et modernisé

Les Nexus 9000 sont motorisés par une nouvelle mouture du système d’exploitation NX-OS s’appuyant sur le noyau Linux v3.4.10, une version bien plus moderne que le noyau Linux v2.6 utilisé jusqu’alors par NX-OS. Cette nouvelle mouture permet aux Nexus 9000 de terminer des tunnels VXLAN (et donc d’assumer le rôle d’un VTEP –VXLAN Tunnel EndPoint) et d’agir comme une passerelle VXLAN pour les serveurs physiques ou pour les hyperviseurs ne supportant pas VXLAN. Selon Cisco, cette nouvelle mouture de NX-OS apporte aussi un niveau élevé de programmabilité via le support de Cisco OnePK (Open Network Environment Platform Kit), de JSON ou d’API de type RestFul. Elle peut aussi accueillir des applications tierces via le mécanisme de conteneur de Linux (LXC).

ACI : To SDN or not to SDN… telle est la question

Dans un premier temps, les commutateurs de la série 9000 seront commercialisés dans un mode traditionnel, sous NX-OS, mais dans le courant du premier semestre 2014, Cisco devrait proposer un nouveau mode de fonctionnement tirant parti de l’ASIC, intégré et développé par Insieme. Dans ce second mode, les commutateurs constituant l’épine dorsale du réseau (ou spine) hébergeront un contrôleur applicatif distribué (ou APIC pour Application Policy Infrastructure controller) à même de piloter l’ensemble des éléments de la « fabric » ainsi que d’autres éléments d’infrastructure afin de délivrer aux applications les ressources physiques et réseaux dont elles ont besoin.
L’architecture ACI s’appuie sur un modèle objet permettant de définir les besoins d’infrastructure de chaque application. Au sommet du modèle ACI est la notion de locataire ou « tenant » qui peut correspondre à un groupe d’utilisateurs, un bureau, une division, un client… La notion de "tenant" peut être utilisée par une entreprise pour segmenter l’infrastructure en fonction de son organisation internet ou par un opérateur cloud pour segmenter son infrastructure entre ses clients.

Ces « tenants » peuvent être ensuite découpés en contextes, correspondant à des instances VRF (Virtual Routing and Forwarding) ou à des classes d’adresses séparées. Chaque « tenant » peut selon Cisco avoir plusieurs contextes selon ses besoins. Chaque contexte utilisant des instances de forwarding différentes, un même jeu d’adresses IP peut être dupliqué dans des contextes séparés.

Au sein de chaque contexte, le modèle objet d’ACI fournit une série d’objets permettant de définir une application. Ce sont des « endpoints », typiquement des serveurs ou des groupes de serveurs ainsi que les règles définissant leurs relations (un endpoint est défini par sa carte réseau, son adresse IP, son nom DNS…). Ces règles vont au-delà des simples listes de contrôle d’accès. Elles peuvent inclure des règles de filtrage, des paramètres de qualité de service, des règles de marquage, des règles de redirection de trafic entre endpoints ou groupe d’endpoints…

Un profil réseau applicatif décrit une collection d’enpoints et d’endpoint groups, leurs connexions ainsi que les règles associées à ces connexions. Il est en quelque sorte une représentation logique d’une application et de ses dépendances réseau et peut être provisionné et déprovisionné à la volée. L’intérêt de ces profils est qu’une fois affecté à un type de trafic applicatif, ils sont entièrement pilotés par la fabrique ACI. Comme l’explique Franck Bonneau, « un des objectifs est de donner de l’agilité aux équipes IT. On cherche à décoréler le workload et son emplacement géographique dans l’infrastructure. On ne veut plus être contraints par des éléments d’infrastructure pour déployer une application  [la fabric ACI peut ainsi provisionner à la volée des services de niveau 4 à 7 comme ceux délivrés par des ADC de type Citrix ou F5, N.D.L.R.] ».

Il est à noter que les ambitions de l’APIC ne se limitent pas au provisioning de ressources réseau. Le modèle ACI permet aussi d’automatiser le provisioning de ressources serveur et stockage (via les profils UCS pour la partie serveur et via une intégration avec les plates-formes de stockage de NetApp et EMC pour le stockage). L’APIC interagit aussi avec les moniteurs de machines virtuelles comme SCVMM de Microsoft [à ce propos, Microsoft était présent en force lors de la présentation d’ACI, un pied de nez supplémentaire au partenaire traditionnel du géant des réseaux, VMware, N.D.L.R.]. Il le fait en partie au moyen d'un nouveau switch virtuel, l'Application Virtual Switch qui semble être une évolution du Nexus 1000V à même de s'intégrer dans un réseau ACI.

Les différents éléments de l’architecture ACI devraient se mettre en place tout au long de l’année 2014. Mais clairement, Cisco entend présenter ACI comme une alternative aux SDN pour les entreprises. Le constructeur fait en fait le pari que les SDN ne perceront pas dans les grands comptes et resteront largement le fait des grands services providers et grands acteurs de l’internet. Un pari intéressant mais dangereux, au vu de l’offensive menée par certains acteurs du logiciel comme VMware mais aussi au vu du dynamisme de l’écosystème SDN. C’est sans doute aussi la raison pour laquelle les Nexus 9000 sont des machines hybrides. Rien n’empêche ainsi le constructeur de proposer ses commutateurs Nexus 9000 dans une configuration traditionnelle, pilotée par un contrôleur SDN tiers ou par OpenDaylight, le contrôleur SDN libre dans lequel Cisco continue à investir massivement. L'ironie d'ailleurs est que vu le retard pris par Insieme dans ses développements, les Cisco Nexus 9000 ne sont pour l'instant utilisables qu'en mode traditionnel...

En savoir plus sur le web

L'architecture ACI détaillées dans des documents techniques chez Cisco