Déployez OpenStack avec OpenNext Private Cloud !

Il est communément admis que déployer et opérer OpenStack à l’échelle de plusieurs dizaines voire centaines de serveurs est une expérience difficile réservée à quelques spécialistes. La complexité de mise en oeuvre et le manque d’expertise OpenStack sur le marché sont des problèmes qui sont souvent remontés par les opérateurs comme des freins à l’adoption. Pour de nombreux décideurs , il y a souvent un sentiment de Fears, Uncertainties and Doubts (FUD) lorsqu’il s’agit de choisir OpenStack comme solution de cloud privé.

Nous pensons que cette situation est regrettable à l’heure où de nombreux acteurs économiques tentent de réduire leur facture vis-à-vis de solutions de virtualisation commerciales onéreuses. En dépit du fait que certaines premières expériences ont pu être chaotiques, il est indéniable qu’OpenStack a acquis au fil du temps un niveau de maturité et de stabilité remarquable qui peut être comparé aux solutions commerciales pour un coût d’acquisition nettement inférieur.

Pourquoi proposer une solution alternative ?

Chez OpenNext [OpenNext est une division d’ingénierie du groupe Metanext spécialiste des technologies cloud issues du logiciel libre, ndlr], nous avons voulu nous attaquer à ce problème. Notre ambition était de pouvoir proposer à nos clients une solution OpenStack fiable sans vendor lock-in qui soit facile à déployer et maintenir à l’échelle de plusieurs dizaines voire centaines de serveurs. C’est la raison pour laquelle nous avons décidé de créer la solution OpenNext Private Cloud.

Pour OpenNext Private Cloud, nous avons délibérément choisi de ne pas partir sur une distribution OpenStack commerciale particulière pour trois raisons principales :

• Tout d’abord, nous savons par expérience que nous avons assez peu de visibilité sur la roadmap des distributions commerciales. Certaines distributions OpenStack ont tout simplement disparues pratiquement du jour au lendemain ou bien subies de telles transformations (par exemple suite à une fusion ou une acquisition ) qu’il n’a plus été possible de monter en version la base installée sans l’apport massif de services professionnels à un coût prohibitif.
• Les distributions OpenStack sont fortement liées aux distributions Linux qui les véhiculent. En fait, elles se confondent. Autrement dit, il n’est pas possible d’installer un OpenStack Red Hat sur Ubuntu ou OpenSuse. Logique me direz vous… Sans doute, mais cela pose tout de même un sérieux inconvénient. Le problème est qu’une installation OpenStack n’est pas faite que de packages. Elle est aussi faite de choix de composants d’infrastructure, de services supportés (ou pas), de SDN supporté(s) (ou pas), de stockage externe supporté (ou pas), et surtout d’outils d’orchestration et de configuration qui servent au déploiement et à la mise à jour des services. Au final, si vous avez fait le choix d’OpenStack, vous êtes contraint de vous lier à une distribution Linux et de son outillage, et de son offre de support associée, pour aussi longtemps que nécessaire bien que OpenStack soit normalement indépendant des distributions Linux.
• Le code OpenStack vient d’une communauté de milliers de développeurs de par le monde qui contribuent à l’amélioration des services existants et à la création de nouveaux services. Ce code, avant d’être validé dans les dépôts officiels de la Fondation OpenStack, subit des centaines de milliers de tests fonctionnels et de non régression qui sont exécutés automatiquement plusieurs fois par jour. Ce processus connu sous le nom de gating du projet Infra garanti un code de qualité à la source (upstream). L’apport en stabilité des distributions commerciales via la création de patches ponctuels, par exemple, reste marginal et n’a pas vocation à rester dans les dépôts dits downstream sous peine d’obsolescence rapide.

En conséquence, nous avons choisi de baser la solution OpenNext Private Cloud sur un projet communautaire sans vendor lock-in qui soit multi-distributions. Il existe quatre projets de déploiement OpenStack officiels:

• Le projet Kolla qui permet d’automatiser le déploiement OpenStack dans des containers Docker
• Le projet OpenStack-Ansible (OSA) permet d’automatiser le déploiement OpenStack sur des machines physiques, virtuelles ou des containers LXC
• Le projet TripleO qui permet de déployer OpenStack avec OpenStack avec son concept de undercloud et overcloud [L’undercloud est l’OpenStack minimal qui permet d’installer l’OpenStack final aussi appelé l’overcloud, ndlr].
• Le projet Puppet-OpenStack qui permet de déployer OpenStack avec Puppet

Notre choix s’est porté sur le projet OpenStack-Ansible et ceci pour de nombreuses raisons que nous n’allons pas détailler ici car cela dépasserait la portée de cette article mais en substance…

• Les choix d’architecture sont solides et éprouvés grâce l’expérience de terrain des ingénieurs de Rackspace qui sont à l’origine du projet.
• OpenStack-Ansible supporte les distributions communautaires Ubuntu, CentOS et OpenSuse.
• OpenStack-Ansible est le moins disruptif en terme de complexité de mise en oeuvre et d’apprentissage. Un bon administrateur Linux peut s’y retrouver facilement ce qui n’est pas forcément le cas des autres projets.
• Tous les services OpenStack qualifiés de suffisamment stables sont disponibles
• Conçu dès l’origine pour faciliter les montées de versions et les mises à jours grâce à l’encapsulation des services d’infrastructure et OpenStack dans des containers.
• Architecture HA sans single-point-of-failure (SPOF).
• Supporte Ceph pour le stockage des images et des volumes.
• OpenStack-Ansible est facile à étendre et à customiser avec de nouvelles fonctionnalités comme le monitoring.
• La communauté est diverse et très réactive pour aider à résoudre les problèmes.
• L’orchestration et la configuration du déploiement se fait avec Ansible que nous préférons à Puppet.
• Il existe plusieurs références de déploiement en production à grande échelle.

La Solution OpenNext Private Cloud, qu’est-ce que c’est ?

La solution OpenNext Private Cloud est basée, nous l’avons dit, sur OpenStack-Ansible. Cependant, OpenStack-Ansible seul ne résout pas tous les problèmes auxquels on doit faire face lorsqu’il s’agit de partir de machines nues pour aboutir à un déploiement OpenStack fonctionnel et maintenable sur un grand nombre de serveurs. La solution OpenNext Private Cloud complète efficacement OpenStack-Ansible dans trois domaines distincts qui ne sont pas adressés par OpenStack-Ansible.

• ONPC [OpenNext Private Cloud, ndlr] Provisioning pour le déploiement  des serveurs
• ONPC Monitoring pour la supervision  de l’environnement OpenStack et Ceph afin de pouvoir détecter, et lorsque cela est possible, anticiper les pannes et anomalies.
• ONPC Logging pour la gestion et la visualisation centralisée des logs afin d’identifier la cause et de diagnostiquer les pannes

Ces trois projets sont disponibles sur GitHub sous licence open-source Apache V2.

OpenStack-Ansible ne fournit pas d’outillage pour le déploiement des serveurs et la configuration du système d’exploitation. Cette phase est particulièrement délicate en ce qui concerne la configuration des interfaces réseau, des bridges, etc. C’est également le cas pour la configuration et le dimensionnement des volumes logiques qui vont recevoir les systèmes de fichiers pour le stockage des containers LXC, le stockage des instances, le stockage des logs et des bases de données comme MariaDB, InfluxDB et Elasticsearch qui sont utilisés pour OpenStack, le monitoring et le logging. Un déploiement réussi d’OpenStack avec OpenStack-Ansible dépend entièrement de cette phase initiale de déploiement  des serveurs et de la validation de sa configuration réseau. Ces opérations sont réalisées via Ironic qui est installé en mode autonome avec Bifrost. A noter que l’automatisation complète des phases de déploiement des serveurs fait appel à un agent et des templates jinja spécifiques au projet ONPC Provisioning. Sans cet agent, l’enchaînement des phases de déploiement (au nombre de dix) ne serait pas entièrement automatisé. Le fonctionnement du projet ONPC Provisioning est complexe et pourra faire l’objet d’un article dédié à ce sujet.

Une autre lacune d’OpenStack-Ansible est qu’il ne fournit pas de monitoring intégré de l’environnement OpenStack. Sans monitoring efficace, il n’est pas possible de maintenir un environnement OpenStack en condition opérationnelle. Le projet ONPC Monitoring a pu hériter de l’expérience acquise en la matière dans le projet StackLight développé chez Mirantis pour Mirantis OpenStack entre 2015 et 2016. L’implémentation de ONPC Monitoring repose en grande partie sur la mise en oeuvre de Collectd et de modules python dédiés et de la Stack TICK de InfluxData.

Enfin, la gestion centralisée et la visualisation des logs repose sur l’intégration de Fluentd pour la collecte des logs OpenStack, Elasticsearch pour l’indexation et le stockage des logs et Kibana pour la visualisation.

En conclusion …

Grâce à OpenNext Private Cloud, il est possible de déployer OpenStack et Ceph entièrement automatiquement (à partir de machines nues) grâce à l’utilisation de playbooks Ansible pour aboutir à un cloud entièrement fonctionnel et supervisé en seulement quelques heures. A la fin du processus, l’utilisateur sera ravi de constater que son déploiement a réussi et que son cloud OpenStack est prêt à l’emploi lorsque le statut de tous les services est au vert comme montré ci-dessous.