Data Center et Cloud

ACI Application Centric Infrastructure: La révolution est en marche…

Eric Debray
7 November 2013

Il y aura sans doute un avant et un après l’annonce d’Application Centric Infrastructure (ACI) ce 6 novembre 2013…. Une annonce majeure à en juger par la présence des patrons des grands acteurs de l’informatique tels que Microsoft, IBM, Citrix, Redhat, SAP, EMC, NetApp, F5, VCE, Symantec etc….sur scène avec John Chambers après la présentation d’ACI par Soni Jiandani Senior Vice president de Insieme. (voir les blogs de nos partenaires à la fin de ce billet)

(lire le communiqué de presse)

Une annonce qui s’est déroulée également avec la participation d’une entreprise française en la personne d’Octave Klaba CEO de OVH qui a précisé en anglais dans le texte : ““We believe innovation is key to keeping a competitive edge. ACI’s features and functionalities will help us to offer a unique value proposition to our data centre customers worldwide.It will be a major component in our continued drive to offer the best quality products and services at the best prices– before any of our competitors can.”

Avec ACI l’ approche ” Software Defined” devient une réalité tangible avec des produits capables de répondre aux exigences d’une production informatique.

Avec le Cloud, la mobilité, les applications bigdata les infrastructures des datacenters vont être soumises à des exigences et des contraintes de plus en plus fortes.

Le temps de déploiement d’une application doit être de plus en plus court et on doit prendre en compte une diversité de types d’applications : applications multi-tiers, applications virtualisées dans des environnements multi-hyperviseurs, nouvelles applications bare- metal basées sur Hadoop et SAP HANA etc..

Ces profonds changements se sont accompagnés d’une complexité des modèles opérationnels qui ne permet plus de répondre de manière adaptée aux demandes de l’entreprise

Dans ce contexte l’infrastructure doit être à l’écoute de l’application et supporter le déploiement ou la suppression d’une application dynamiquement.

ACI : Agilité, simplification, rapidité pour des applications distribuées en environnements physiques ou virtuels

L’ACI est conçue pour apporter une gestion automatisée et centralisée, des politiques programmables et des modèles dynamiques « workload-anywhere ». Pour atteindre ces objectifs il fallait pouvoir combiner de manière parfaitement intégrée des éléments matériels, des systèmes de contrôle basés sur des politiques et du logiciel.

Quels sont les éléments clé de l’ ACI :

L’ ACI ,conçue sur une architecture appelée « spine-leaf » , repose principalement sur 3 composants majeurs qui vont jouer un rôle pour définir des politiques de réseau et assurer la commutation de paquets.

Le contrôleur APIC : Application Policy Infrastructure Controller
Commutateur spine
Commutateur leaf.

Le controleur APIC : Programmabilité et gestion centralisée

Le contrôleur APIC est un contrôleur centralisé clusterisé qui optimise les performances, supporte tous types d’applications ou qu’elles soient et unifie les opérations pour des environnements physiques ou virtuels. Ceci est réalisé grâce au modèle objet de l’ACI.

Ce contrôleur est responsable des tâches qui vont couvrir l’activation de la fabric et la gestion des microcodes des commutateurs aussi bien que la configuration des politiques réseaux et leur instanciation. Le contrôleur administre et opère une fabric ACI multi-tenants

Le contrôleur APIC est totalement indépendant du “data path”. Cela signifie que la fabric proprement dite (l’ensemble des commutateurs) peut continuer à assurer la commutation du trafic quand bien même la commutation avec le contrôleur APIC serait perdue.

Le contrôleur APIC est fourni sous forme d’une appliance . En règle générale on disposera de 3 ou plus d’appliances pour garantir la performance et la disponibilité

Programmable et ouvert

Le contrôleur APIC est l’élément clé de la programmabilité de l’infrastructure. Il propose une API « nord » XML et JSON et fournit à la fois des interfaces en commandes lignes (CLI) et un GUI qui utilisent ces APIs pour gérer la fabric.

Le système dispose également d’une API « sud » en logiciel libre qui donne la possibilité à des sociétés tierces, proposant des services réseaux, de mettre en œuvre avec le contrôleur APIC des politiques de contrôle d’ équipements qu’ils ont conçus.

Le controleur APIC se veut délibérement ouvert à un très large écosystème .

Une définition logique des applications avec l'”Application Network Profile”

Avec le contrôleur APIC les applications sont définies logiquement en utilisant des composants qui sont applications centriques plutôt que réseaux centriques. La définition complète d’une application dans le contrôleur APIC est appelé « application Network profile ». 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 et de simplification des opérations. De la même manière que l’UCS manager pousse des services profiles sur des lames physiques, l’APIC va pousser des Apllications Netwirk 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.

Une fois définis ces Applications Services Profiles sont utilisés par le contrôleur APIC pour appliquer la topologie logique et la définition des politiques dans un réseau dit « stateless » ( sans caractéristique avant que le profile ne soit appliqué). Cette approche est à l’opposé des architectures traditionnelles dans lesquelles les VLANs, subnets et firewall dictent le lieu et la manière d’exécuter une application.

L’architecture « Spine et leaf » : une scalabilité linéaire , une latence faible et constante

La fabric est base sur une architecture “ leaf et spine” dont les liens connectent chaque « leaf » à chaque « spine ». Ce design permet une scalbilité linéaire et un multipathing robuste dans la fabric qui sont optimisé pour le trafic « est-ouest » requis par les applications. Dans ce type d’architecture, la scalabilité est limitée uniquement par la disponibilité des ports sur le « spine ». La bande passante s’accroit linéairement en ajoutant des commutateurs « spine ». Chaque commutateur « spine » ajouté crée un nouveau network path qui est utilisé pour équilibrer le trafic dans la fabric.

La fabric ACI est pensée pour une commutation à faible latence consistante que des liens hauts débits (40Gps et prévu pour le 100Gbps dans le futur.

Les commutateurs pour construire cette architecture « Spine et leaf » sont les nouveaux Nexus 9000 mentionnés dans l’annonce utilisant le système d’exploitation NX-OS comme l’ensemble des commutateurs Nexus.

Autres avantages d’ACI

Ne pouvant pas être exhaustif je voudrais souligner néanmoins quelques points qui me semblent particulièrement intéressants:

Prise en compte intuitive des Services IP Cisco et Non CIsco (F5, Citrix, …) comme composants intégrés d’une application N-Tiers.
Télémétrie avancée : vue exhaustive de l’état de santé de l’application sur l’infrastructure réseau (Health Scores).
Language de programmation object agnostic : tous types de serveurs physiques et/ou virtualisés (vmware, microsoft, ovs).
Intégration native avec tous les types de réseaux overlay (VXLAN NGVRE, 802.1Q, …). ACI pensée pour le Cloud (privé ou public). L’APIC fournit une interface de programmabilité ouverte qui permet l’interface avec un orchestrateur (OpenStack, UCS Director, etc …)

ACI : la première étape de ONE Platform

Tout cela n’est qu’un début puisque que Rob Lloyd, President Developpement et ventes Cisco, suite à la présentation de Soni Jiandani, a introduit l’évolution de ONE plate-forme avec ACI pour le DataCenter et les mêmes principes par la suite pour le WAN et l’accès….