Le logiciel ne sera pas sacrifié par Cisco

Dossier par Ethan Banks, adaptation Didier Barathon, 944 mots

Cisco  a toujours placé le matériel au centre de ses offres,  le découplage si cher au SDN n'y changera rien. Le matériel réseau doit toujours être provisionné, surveillé, optimisé et mis à jour.

Le logiciel ne sera pas sacrifié par Cisco

Une différence majeure entre ACI et NSX c'est que Cisco met l'accent sur le matériel en plus de le faire sur le logiciel. Le logiciel en lui-même ne sera pas sacrifié selon Cisco. Franck d'Agostino, directeur senior chez Insieme (racheté par Cisco), prévient : « nous allons offrir une plate-forme qui soit pertinente pour l'application, qu'elle soit physique ou virtuelle, avec Linux et tout l'héritage ». Franck d'Agostino ajoute : « la bataille n'est pas sur vSwitch ou sur un commutateur physique. Elle est de savoir comment vous faites l'activation de services et comme il est simple de mettre les choses en route et de vérifier tout cela juste après le premier jour ».

Certains experts se moquent d'ACI, qui passe pour « le réseau défini par le matériel ». Mais, même pour ceux qui souhaitent minimiser l'importance du matériel en le banalisant, le fait demeure que ce matériel réseau doit être provisionné, surveillé et optimisé et mis à jour pour faire face aux besoins du réseau.

Aucun découplage ne peut changer ce fait. Cisco, conformément à son modèle d'affaires, a toujours placé le matériel au centre, avec une importance continue, au milieu de sa proposition de valeur ACI. « Nous savons que dans le fabric, sur une base paquet par paquet, c'est sur un tel niveau de détail que nous pouvons commencer à réaliser une ingénierie  de trafic différente », souligne Franck d'Agostino.

Avec l'intégration d'APIC pour contrôler le hard et le soft, Cisco prévoit de livrer avec ACI une infrastructure de réseau dirigée par sa stratégie. Elle vient en partie de l'utilisation de End point groups, EPG. L'idée est de créer des EPG qui seront une collection de serveurs, de services, de virtualisation ou de caractéristiques réseau décrivant une application et pas seulement des adresses IP et les numéros de ports seront utilisés dans ce sens.
Une fois l'EPG défini, ACI applique sa stratégie de gestion du trafic circulant entre les EPG. Selon Joe Onisick, ingénieur chez Insieme, « Nous regroupons ensemble les points d'extrémité pour appliquer notre stratégie, et utilisons EPG en tant que point d'instance... nous instançons notre politique entre les groupes sur la base d'un graph de connectivité que nous tirons dans le profil réseau de l'application ».

La clé pour comprendre Cisco

Ce point sur la stratégie et EPG peut sembler un peu détaillé, mais il soulève un sujet important, qui est en fait la clé pour comprendre la philosophie de Cisco autour d'ACI. Les applications ne sont pas simplement des éléments de la charge utile de données amorphes collées dans un paquet IP et transmis à travers le réseau de type fabric. Elles peuvent en effet être décrites de manière plus nuancée.

Cisco utilise des EPG nuancés comme un moyen non seulement d'identification des applications riches, mais aussi d'abstraction. Il y a réellement un pouvoir dans ce concept, car il permet aux opérateurs de réseau, ou aux développeurs d'applications, d'affiner le trafic à un degré qui serait prag-matiquement impossible si cela devait se faire à la main.
Le traitement de trafic dans le modèle ACI comprend également une séparation sécurisée. Franck d'Agostino le souligne ainsi : « chacun des conteneurs est complètement isolé  sur la base de notre stratégie et en fonction de leur ID sur le segment. Et si c'est orienté VXLAN, que ce soit orienté VLAN ou orienté NVGRE, pour nous ce n'est pas grave. Nous l'apportons, nous l'isolons sur une architec-ture ou sur un système  logique basé sur la définition de notre stratégie. Nous pouvons garder un isolement complet et strict avec une visibilité complète sur les charges de travail et la consommation d'une ressource qui est définie pour tout locataire ou toute application qui exécute de telles res-sources ».

Un éco-système de partenaires

Comme VMware, Cisco a fait beaucoup d'efforts pour construire un éco-système de partenaires, bien que Cisco souligne qu'APIC est une plate-forme ouverte, ce qui implique que les partenaires n'auront pas de relations exclusives. BMC, Citrix, Embrane, F5, Microsoft, NetApp, PupppetLabs, Red Hat, Splunk et plusieurs autres sont déjà répertoriés comme pouvant travailler avec Cisco sur l'intégration d'une variété d'applications dans ACI.
Cisco est parfois critiqué pour le coût élevé de ses solutions et s'est fait fort de maintenir les coûts d'acquisition d'ACI très bas. Les investissements pour les Nexus 9000 sont tout à fait raisonnables. Ils sont considérés par Cisco comme une solution pour la migration des bons vieux Catalyst 6500.

En parallèle des Nexus 9000 qui offrent une haute densité 40G Ethernet, Cisco a mis en place un «  LC teminated optic 40 GbE » BiDi (bidirectionnel) qui permet du 40 GbE  fonctionnant sur une seule paire de fibre multimode OM3 de qualité. Comme la plupart des optiques de 40 GbE exigent 12brins de fibre, la stratégie BiDi donne  aux clients une voie de migration de 10 GbE à 40 GbE.

Les clients qui ont investi dans la gamme Nexus 7000 seront heureux de savoir que le soutien d'ACI est prévu au plus tard au 1er juillet prochain. L'inconvénient évident d'ACI est qu'il nécessite un matériel réseau compatible. Bien qu'ACI soit l'une des approches architecturales  les plus complètes encore définies par le SDN, et si ACI gagne une notoriété importante, la mise en oeuvre sera lente car ACI dépend du bon matériel pour fonctionner.

La plupart des matériels réseaux dispose de un à cinq ans de vie, de sorte que même avec des coûts d'acquisition raisonnables, de nombreuses organisations déprécient encore l'achat de matériels récents et vont trouver ACI difficile à vendre. Le Nexus 7000 qui promet l'intégration avec ACI a du chemin à faire pour y arriver, si Cisco veut réaliser l'intégration avec succès.

Sommaire du dossier