Cisco France Blog / Data Center et Cloud / Application Centric Infrastructure : Un an déjà ……

Voici un peu plus d’un an que les premières solutions ACI (Application Centric Infrastructure) ont commencé à être livrées chez les clients. Depuis, 1000 clients ont adopté ACI. L’objectif de Cisco était simple : automatiser le réseau en supprimant le gap entre les demandes des responsables d’applications et les contraintes des responsables réseaux. Une réflexion qui a conduit à définir l’architecture ACI.

Les différents principes de l’ACI. Il ne suffisait pas d’innover sur des architectures existantes, il fallait être capable de redessiner une architecture en tenant compte du bouleversement technologique qui conduit les entreprises à développer de nouveaux usages et de nouveaux services. Dans le contexte de l’entreprise numérique les infrastructures sont non seulement extrêmement sollicitées mais elles doivent pouvoir s’adapter simplement et rapidement à des contextes opérationnels différents. Cisco a donc conçu l’ACI sur les principes suivants.

Virtualisation du réseau. Héberger de multiples « tenants » indépendants sur une même infrastructure tout en garantissant une isolation et une sécurité complètes était un objectif majeur lors de la conception d’ACI. Les tenants peuvent être des entreprises indépendantes, des directions métiers d’une même société ou n’importe quelle entité qui nécessite une isolation et une adresse IP privée. Dans des réseaux classiques la mobilité des workloads est limitée à la couche de niveau 2 ou de niveau 3 (VLAN ou subnet). ACI élimine cette contrainte et permet le placement de n’importe quel workload n’importe où dans l’infrastructure.

Réseau unifié. L’architecture ACI repose sur un réseau unifié indépendant du type de workload (bare metal, machine virtuelle ou containeur). Les workloads se résument à des points IP de terminaison qui doivent se connecter et qui ont besoin de services comme l’équilibrage de charge ou la sécurité. Les services de niveau 4 à 7 sont impératifs pour le déploiement de n’importe quel workload applicatif. Dans ce domaine l’offre est pléthorique et les clients font le choix du fournisseur en fonction de leurs besoins. Cisco en a tenu compte pour ACI et a choisi une approche ouverte permettant d’intégrer les offres du marché en termes de fourniture de services réseaux quel que soit leur format (physique, appliance ou VM).

Architecture centrée sur l’application. Le réseau doit être capable de comprendre ce que l’équipe en charge des applications veut déployer. Pour une application Web par exemple structurée en 3 tiers (Web, App et base de données), chaque tiers aura des besoins différents. Le traffic du tiers web devra être équilibré par des load balancers et les autres tiers devront avoir une isolation et une sécurité renforcées. Le contrôleur de l’ACI (APIC) récupère ces informations sur les besoins de l’application et provisionne les commutateurs physiques, les commutateurs virtuels des différents hyperviseurs utilisés et les services L4-L7 des vendeurs en place. Le contrôleur APIC peut fournir ainsi un déploiement cohérent, le monitoring approprié et la visibilité sur l’ensemble de l’infrastructure.

Evolution prévue par conception. Avec un contrôleur centralisé une panne ou un dysfonctionnement peut avoir de graves conséquences sur les performances, la sécurité et la disponibilité. L’équipe de développement d’ACI en était particulièrement conscient et en a tenu compte pour définir le contrôleur APIC. Le trafic client est commuté par l’infrastructure elle-même tandis que l’APIC s’occupe du contrôle et de l’application des règles (policies). L’APIC est conçue sur des principes de traitement distribué et de data sharding (partitionnement horizontal) qui offre une des meilleures scalabilité de l’industrie. Pour répondre à la demande des clients, Cisco a déjà livré des architectures de 220 leafs avec 5 contrôleurs APIC dans une seule fabrique ACI. En comptant 48 ports par leaf cela représente 9600 ports serveurs. Il n’y a pas de limite d’architecture pour évoluer c’est juste une question de temps de qualification des configurations. Dans la version ACI 1.1(3f) on dispose de la fonction « show usage » qui permet aux administrateurs de voir ce qui seraient impactés préalablement à un changement. On évite ainsi des interruptions dues à des erreurs grossières.

Alignement avec les exigences de la production. Pouvoir configurer des équipements n’est pas suffisant s’ils ne permettent pas de soulager les équipes opérationnelles au quotidien. Aujourd’hui elles doivent faire face à de nombreuses opérations qui prennent du temps du fait du manque d’intégration de bout en bout de l’infrastructure avec les applications et de la difficulté d’identifier et d’isoler des problèmes. Le contrôleur APIC donne la visibilité sur l’ensemble des workloads, services L4-L7 inclus, et permet ainsi de gérer de manière pro-active la fabrique. Cette visibilité native au niveau de l’application et ces capacités de troubleshooting sont de réels atouts dans une production au jour le jour.

Des APIs Northbound unifiés. Tous les aspects du système,  spécifications applicatives ou détails des commutateurs de la fabrique, sont exposés par l’intermédiaire des APIs de l’APIC (northbound RESTful APIs). L’interface graphique (GUI) de l’APIC est lui-même conçu en utilisant ces APIs ouvertes. C’est ce qui permet aux clients et aux partenaires d’intégrer facilement l’ACI dans leur écosystème.

Les nombreuses innovations technologiques et les nouveaux usages soumettent les infrastructures traditionnelles à de nouveaux défis. Le réseau ne devait pas être un frein à ce besoin d’agilité exigée par l’économie numérique. En développant l’architecture ACI, Cisco a voulu accompagner la transformation des entreprises et leur permettre d’atteindre leurs objectifs.

Authors

Eric Debray