Nouvelle version d’OpenStack : pourquoi Newton doit garder un œil sur Neutron
5 min read
La 14e version d’OpenStack met l’accent sur l’orchestration et la gestion des containers ainsi que sur la gestion multi-sites. Une réponse ultime à la flexibilité et à l’agilité qu’apportent les développements et déploiements applicatifs en mode micro-services. Mais Neutron, son projet réseau, reste l’un des plus complexes du projet Open Source et peut freiner son plein potentiel. L’intégration d’ACI à OpenStack permet de résoudre cette complexité afin d’en exploiter les dernières avancées.
4 millions de lignes de code, 13000 emails échangés, 2581 développeurs, 183 entreprises, 78 projets additionnels, à peine 6 mois de gestation. Les chiffres autour de la nouvelle release d’OpenStack atteste de l’ampleur du projet. Lancée le 6 Octobre dernier, cette 14e version baptisée Newton, met l’accent sur :
- L’automatisation et le pilotage plus souple des containers
- L’amélioration des projets Keystone et Cinder en matière de sécurité
- La convergence via son projet d’orchestration Heat
- La haute disponibilité et la résilience pour les projets de stockage(Cinder), de provisionning (Ironic), ou de réseau (Neutron)
- La meilleure gestion des infrastructures multi-sites via le projet Ironic
Responsable du provisioning bare-metal, le projet Ironic bénéficie, dans cette nouvelle release, d’une intégration plus poussée avec :
- Nova – le module compute
- Magnum – l’orchestrateur de containers
- Kuryr – le plugin réseau Docker lui apportant les capacités de mise en réseau de Neutron
Cette évolution vers les containers est en parfaite adéquation avec la tendance actuelle au sein des communautés de développeurs et Devops. Encouragées par les métiers à accélérer les phases de prototypage et de modifications de leurs applications, elles s’orientent aujourd’hui vers des développements et des déploiements sous forme de micro-services. Et les containers constituent la solution ultime à cette adoption massive. Mais si Kuryr se retrouve sous la lumière des projecteurs, le projet de mise en réseau de containers n’est pas pour autant une solution de virtual networking per se. Et même s’il se présente comme une couche unique, il ne doit pas faire oublier la gestion complexe à laquelle est toujours soumise Neutron.
Oui aux containers, mais merci de ne pas toucher au réseau !
Traditionnellement les réseaux n’ont pas été conçus pour répondre aux enjeux d’agilité qu’imposent le passage aux micro-services. Et l’organisation des départements IT en silos ne facilite pas cette transition. En outre, le projet Neutron peut rapidement devenir une pierre d’achoppement. Reposant sur une approche Software-Defined, Neutron facilite la création des réseaux, la connexion des instances, la gestion du trafic et le contrôle de sécurité dans le Cloud OpenStack. Or, si ce module est évidemment crucial, sa configuration et son utilisation sont assez complexes. Et c’est logiquement – mais tristement – celui sur lequel les entreprises continuent de passer le plus de temps : temps de paramétrage, connexion avec avec les ressources matérielles, interruptions de service en cas d’upgrade etc. D’où la méfiance exprimée par certaines équipes réseaux lorsqu’un projet OpenStack frappe à leur porte.
Comparativement, Forrester suggérait même cet été que le projet réseau d’OpenStack était resté un peu à la traîne des projets stockage et compute. Le succès de Neutron serait donc fortement lié au succès d’OpenStack dans son ensemble. Et Neutron ne serait qu’un chantier en construction. Pour preuve, le projet serait l’un des moins documenté et les ressources produites par la communauté seraient souvent dépassées voire limitées aux configurations basiques. Une des raisons pour laquelle la Fondation aurait décidé d’y apporter un regain d’attention.
Face à ce défi, la réponse n’est pas de nier l’évidence, ou d’attendre des jours meilleurs mais de s’équiper dès maintenant d’un outil permettant de gérer cette complexité, aussi bien dans les réseaux physiques que virtuels.
- A Forrester, qui suggère dans cette même étude, de maintenir une architecture réseau la plus simple possible, je serai tenté de les renvoyer à la réalité du terrain. Une réalité dans laquelle le réseau dessert une profusion d’hyperviseurs et d’orchestrateurs au travers d’une multitude de serveurs bare-metal, de machines virtuelles ou de containers, dans un ou plusieurs data-center, sur un ou plusieurs sites, dans un environnement on-premise et dans un cloud privé et/ou hybride.
- Aux entreprises qui opposent les profils des administrateurs réseaux à ceux des développeurs et qui se demandent à qui confier la gestion de leur réseau virtualisé OpenStack, j’aimerai démontrer qu’il s’agit d’un faux débat. Peut-être que les réseaux virtuels nécessitent une compétence différente pour les concevoir, les déployer ou les gérer, mais l’utilisation d’un outil commun et éprouvé simplifierait grandement la tâche.
A l’un comme aux autres, la réponse tient en trois lettres : A. C. I.
Faire le choix d’ACI dans OpenStack
L’Application Centric Infrastructure offre une solution de réseau virtualisé évolutive et distribuée pour l’environnement OpenStack. ACI est une architecture holistique permettant une automatisation centralisée sur la base d’une configuration de politiques applicatives. Ses APIs sont ouvertes “by design” afin de faciliter l’intégration avec n’importe quelle plateforme d’orchestration. Dans le cas d’OpenStack, ces APIs implémentent les “Group Based Policy” de Neutron : le contrôleur ACI (Cisco APIC) va convertir les ressources de ses APIs en un profil applicatif “réseau” avant de le fournir à Neutron.
ACI offre des avantages opérationnels tels que l’accélération des performances matérielles où les tunnels VXLAN sont gérés automatiquement, sans avoir à mobiliser et gaspiller les ressources de traitement CPU. La vision d’ACI en matière d’exploitation et de télémétrie est si précise que les dépannages peuvent s’opérer dans des environnements physiques comme virtuels. ACI intègre la gestion de l’overlay et du réseau physique dans un modèle homogène : l’environnement sous-jacent est intégralement géré, et la couche supérieure est capable de connecter à la fois des serveurs physiques et de multiples hyperviseurs. Enfin, ACI garantit la sécurité des environnements réseaux distribués tant sur la couche virtuelle que sur la couche physique. Cela permet au réseau physique d’être sécurisé à tout niveau, même lorsqu’un hyperviseur est compromis.
Des fonctionnalités à découvrir au Red Hat Forum le 18/10
Au-delà de ces nouveautés, la dernière mouture d’OpenStack continue d’apporter son lot d’améliorations et de corrections de bugs. Red Hat s’est déjà préparé à ces évolutions et c’est ensemble que nous démontrerons l’avance de nos solutions intégrées au prochain Red Hat Forum, ce 18/10 à Paris.
Le partenariat entre Cisco, Red Hat et Intel a abouti à la conception d’un CVD (Cisco Validated Design). Il définit les lignes directrices et les configurations pour simplifier et accélérer le déploiement et l’exploitation d’un environnement Cloud OpenStack. Ces recommandations ont été testées et éprouvées. Reposant sur UCS, notre solution intégrée apporte donc un environnement Cloud fiable, hautement sécurisé, et intégralement supporté. Idéal donc pour construire un cloud privé et pour fournir services et applications.
Dans sa version managée (Metapod), la gestion de l’environnement OpenStack est déléguée au support Cisco. A noter, que depuis sa version 4.0 – Cisco a confié à Red Hat les tests et les correctifs à apporter à OpenStack. A la clé, des équipes Cisco concentrées uniquement sur le développement des nouvelles fonctionnalités réseau, compute et stockage attendues par nos clients.
Ces fonctionnalités et la stratégie OpenStack Cisco seront également présententées au prochain OpenStack Summit du 25 au 28 Octobre à Barcelone.
Authors
