Avec l’OpenStack Summit, Paris devient pour quelques jours la capitale d’OpenStack. Pour s’y préparer j’avais proposé la semaine dernière quelques rappels à propos d’OpenStack sur ce blog pour ceux qui découvrent OpenStack.
Pour ceux qui sont déjà à un stade plus avancé dans la démarche et qui s’interrogent sur la manière d’intégrer Cisco Application Centric Infrastructure ACI avec OpenStack il existe un document intitulé Cisco APIC Driver for OpenStack: Installation and Operation Guide.
Intégration aisée avec les plateformes d’orchestration comme OpenStack
Application Centric Infrastructure (ACI) est une architecture holistique avec une automatisation centralisée et des profils applicatifs dictés par des politiques. La conception d’ACI permet d’offrir la souplesse du logiciel et la « scalabilité » des performances avec le matériel.
La conception d’ACI repose sur le concept des APIs ouvertes REST (Representational State Transfer) rendant ainsi l’intégration avec n’importe quelle plateforme d’orchestration particulièrement facile.
Dans le cas d’OpenStack ces APIs permettent une intégration par l’intermédiaire de Neutron, une couche d’abstraction du réseau packagée comme un composant du framework OpenStack.
Le principe de Neutron est de supporter un modèle de type « plug-in » grâce à une API Neutron standard. Cette API repose sur des primitives telles que réseaux, ports, routeurs et subnets mais la mise en œuvre de ces ressources est déléguée à des plug-ins spécifiques.
Le contrôleur de l’ACI, le Cisco APIC (Application Policy Infrastructure Controller), supporte l’API Neutron standard et les ressources de cette API. Ces ressources sont converties de manière transparente par l’APIC dans un « Application Network Profile »
Principe de fonctionnement du Plug-in Cisco pour OpenStack
Ce plug-in Cisco pour OpenStack est basé sur le plug-in Neutron multi-vendeurs modulaire de niveau 2 (Modular Layer 2 : ML2).
ML2 donne la possibilité à un administrateur de spécifier un ensemble de drivers pour gérer des portions de réseaux. Les drivers « types » définissent un type particulier d’étiquettes (tagging) ou d’encapsulation et les drivers « mechanism » interagissent avec des équipements spécifiques dans le réseau.
Dans le schéma ci-dessous on voit en particulier l’APIC driver créé par Cisco qui communique en utilisant les APIs REST présentés par APIC.
L’intégration est supportée par la distribution OpenStack Icehouse proposée par de nombreux fournisseurs comprenant Red Hat, Canonical, and Mirantis.
Deux drivers ML2 séparés sont utilisés pour s’intégrer avec les différentes portions du réseau :
- Open virtual switch (open vSwitch, or OVS) driver
- Cisco APIC driver
La figure ci-dessous explique le fonctionnement (plus de détails dans le document que je mentionne en début de billet).
Je profite également de ce billet pour signaler l’existence d’un ACI toolkit.
Authors
