Infrastructure – Références

Camptocamp fait confiance à OpenStack pour sa plateforme interne d’hébergement

L’automatisation de l’allocation de ressources informatiques est le socle indispensable permettant de généraliser les principes de développement, d’intégration et de déploiement continus.

Internal Case Study

L’entreprise

Au travers de ses trois départements (Geospatial, Business, Infrastructure) le groupe Camptocamp est intrinsèquement organisé autour des méthodologies DevOps. Cette approche a pour objectif principal d’aligner nos collaborateurs (ingénieurs spécialisés, analystes métiers, intégrateurs, testeurs) sur des objectifs et des valeurs communes, travailler ensemble pour produire la valeur de l’entreprise et donner satisfaction à nos clients. Favoriser l’agilité et organiser nos équipes autour de processus automatisés et transversaux est au centre de nos préoccupations.

L’automatisation de services et processus IT ne peut se faire sans une infrastructure flexible et des interfaces programmables (APIs) permettant de créer et supprimer instantanément des ressources à la demande (puissance de calcul, stockage, gestion des utilisateurs et des accès). Cette capacité à obtenir des ressources en libre-service est fondamentale pour une entreprise comme la nôtre qui doit pouvoir très rapidement saisir des opportunités en développant rapidement de nouveaux projets, en mettant à disposition des prototypes au travers d’Internet, et en testant continuellement les évolutions proposées (ceci sans dépendre exclusivement de prestataires externes, en garantissant la localisation et la confidentialité des données traitées, et sans devoir faire de concession sur les aspects liés à la sécurité).

Challenges

Adoption d’OpenStack, historique

Précurseur dans l’utilisation de solutions de Cloud Computing, Camptocamp a, dès 2007, utilisé concrètement les services Amazon AWS pour le déploiement de plusieurs projets en production. Cette expérience a profondément fait évoluer nos attentes en terme d’allocation de ressources. Nous passions d’un mode manuel, généralement lent et statique, à un mode automatisé, quasiment instantané et dynamique. Gérer des ressources d’infrastructure (Infrastructure-as-Code) d’une manière programmatique permet d’utiliser des méthodologies de développement éprouvées comme le fait de conserver un historique des changements ou encore mettre en place des processus de revue de code en amont des changements. Une véritable révolution.

L’utilisation de solutions de cloud computing publiques (comme p.ex. Amazon AWS) pose un certain nombre de problèmes liés à la localisation des données et la juridiction des entreprises qui fournissent ces prestations. De nombreuses entreprises sont particulièrement sensibles à ces questions et excluent de facto l’utilisation de ces services ou restreignent leur choix à des solutions proposées par des entreprises localisées dans un certain pays. Au niveau Suisse et vu la taille du marché, les solutions sont rares et souvent très limitées, à des années lumières de ce qui est proposé par le leader de ce domaine, Amazon AWS.

A partir de ce constat et découvrant l’émergence du projet open source OpenStack, nous avons décidé dès 2012 de remplacer notre infrastructure virtualisée interne (basée à l’époque sur OpenVZ) par une infrastructure en libre-service basée sur OpenStack. Trois objectifs principaux conduisaient notre démarche : disposer d’un private-cloud à-la Amazon AWS sur le territoire Suisse pour nos besoins d’hébergement internes, monter en compétence et contribuer au développement de cette solution open source très prometteuse initiée par Rackspace et la NASA.

Cette première expérience en 2012 n’a pas été de tout repos car le projet OpenStack englobe de très nombreux aspects gérant finalement l’ensemble des composants d’une infrastructure (réseau, stockage, calcul, identité, etc.) ; c’était une complexité importante sollicitant de très nombreux domaines de compétence et en particulier par rapport aux aspects réseaux dématérialisés autour du principe du software-defined networking (SDN).

Entre 2012 et 2016, nous avons quotidiennement administré un cluster OpenStack composé d’environ 30 serveurs hardware (Intel x86) pour une capacité maximale allouable d’environ 300 serveurs virtuels. L’ensemble de notre ancienne infrastructure virtualisée a totalement été migrée sur ce nouveau cluster et, depuis ce jour, nous n’avons pas cessé de suivre ce projet et participer à différents événements (OpenStack Summit ou Meetup) en lien avec la communauté de ce projet open source.

Nous avions démarré en 2012 avec la version Grizzli d’OpenStack, pour ensuite effectuer deux migrations successives, respectivement de Grizzli à Havana et ensuite de Havana à Icehouse. A cette époque, le processus de migration était relativement complexe et nous a posé de très nombreux problèmes, notamment à cause des changements importants au niveau de la couche réseau. Ce processus de mise à jour c’est heureusement amélioré au fil des versions.

2016, nouveau cluster

Durant l’année 2016, nous avons effectué différentes missions de consulting pour plusieurs de nos client autour de la solution OpenStack. Au delà du fait de choisir OpenStack, plusieurs de nos clients s’interrogeaient, tout comme nous d’ailleurs, sur le choix de l’installeur.  Nous souhaitions à cette époque ré-installer complètement notre cluster OpenStack afin de profiter des évolutions majeures du projet, effectuer d’importants changements en terme de hardware et topologie réseau mais également faire table rase de nos déploiements passés.

A l’image de Linux et ses outils qui sont proposés au travers de différentes distributions (Red Hat, Debian, Ubuntu, etc.), la complexité de déploiement d’OpenStack est également un enjeu capital et différentes entreprises et solutions proposent de simplifier ce processus, un enjeu d’installation mais également de maintenance afin d’assurer les aspects opérationnels et simplifier les processus de migration vers les nouvelles versions.

Début 2016, principalement deux solutions se livrent une lutte acharnée dans ce domaine : Mirantis avec sa solution de déploiement OpenStack nommée “Fuel” et Red Hat fournissant une solution basée sur le projet OpenStack TripleO incubé pour Red Hat au travers du projet RDO. A noté qu’au delà de leur rivalité, Red Hat et Mirantis sont deux entreprises qui contribuent très activement au projet OpenStack.

Au final et pour nos propres besoins, notre choix s’est clairement porté sur RDO (ou la version entreprise Red Hat OpenStack Platform) car même si le processus d’installation semblait à cette époque moins abouti en terme de fonctionnalités que la solution proposée par Mirantis, le projet de base était 100% open source et les efforts faits par Red Hat étaient pour nous un vrai gage de pérennité de la solution. Nous sommes partenaire Red Hat depuis de nombreuses années et connaissons la valeur des solutions fournies par cette entreprise.

Solution

Voici les différents composants de notre cluster OpenStack qui sont explicités dans la suite du document.

  1. la dashboard Horizon qui permet de gérer l’ensemble des services au travers d’une interface Web intuitive et très complète
  2. en lieu et place de comptes locaux, nous avons connecté l’ensemble des services OpenStack sur notre système existant de gestion des identités et des accès (Identity Management) qui est basé sur le projet open source FreeIPA, un projet distribué sous sa version payante sous le nom de Red Hat Identity Management
  3. pour la partie réseau, nous utilisons Neutron avec Open vSwitch et avons également activé le service LBaaS v2 (Load-Balancing-as-a-Service). La gestion du réseau des différents tenants est assurée par des VXLAN (virtual extensible LAN) également fournis par le service Neutron
  4. les volumes de stockage réseau sont fournis au travers d’un cluster Ceph totalement intégré au déploiement OpenStack TripleO. Ces volumes sont des espaces de stockage additionnels qui doivent être attachés aux instances
  5. les instances elles-mêmes sont gérées par le service Nova qui est configuré avec le mécanisme de hosts aggregates afin de pouvoir fournir différentes générations d’instances. Dans notre cas, nous proposons deux générations d’instances, celles instanciées sur notre ancienne génération de serveurs (disque à plateau) et celles créées sur la nouvelle génération de serveurs qui possède du stockage SSD (solid-state drive)
  6. le service Glance s’appuie sur Ceph pour stocker les images des différentes distributions proposées pour l’installation de nouveaux serveurs virtuels
  7. l’object storage (équivalent de Amazon AWS S3) est également fourni par notre cluster Ceph interfacé via le service Swift
  8. nous n’utilisons pas le service Telemetry mais lui avons préféré une solution basée sur les logiciels CollectD et Prometheus, des outils que nous maîtrisons et utilisons déjà dans d’autres contextes
  9. pour l’orchestration du cluster OpenStack, il s’agit d’une combinaison d’outils (Mistral, Heat, Ansible, Puppet) qui permet d’automatiser l’ensemble des tâches d’administration. Le création des ressources dans le cluster proprement dite est totalement automatisée avec le logiciel Terraform

Au niveau réseau, voici ce qui a été mis en place :

Quelques détails par rapport au schéma ci-dessus :

  • chaque tenant à son propre sous-réseau privé et son propre routeur virtuel, ces tenants sont totalement isolés les uns des autres et ils disposent de leur propre quota de ressources
  • nous disposons d’un seul pool d’adresses IP publiques qui sont partagées entre les différents tenants. Une instance qui doit être exposée directement sur Internet doit s’allouer une IP du pool.  Pour l’accès aux instances disposant uniquement d’une adresse privée, nous avons mis en place des bastions SSH pour l’accès direct

Tous ces services sont naturellement exposés et utilisables en libre-service via des APIs, la gestion des ressources peut se faire via l’interface Web, en ligne de commande ou encore via Terraform. Le monitoring proprement dit est effectué au travers des indicateurs de performances ou de disponibilité remontés par CollectD et Prometheus, l’alerting via l’Alertmanager de Prometheus. Pour le “troubleshooting”, nous nous appuyons sur les différentes logs produites par les différents services OpenStack et consolidées dans notre cluster ELK existant.

Résultats

La mise en place de ce nouveau cluster OpenStack nous a permis de mesurer les nombreuses évolutions des différents services intégrés dans ce projet et également les améliorations significatives en terme de mise à jour. A notre sens, c’est incontestablement la solution open source la plus aboutie pour le déploiement d’un cloud privé “on-premises”. Les fonctionnalités fournies sont très proches des services de base des principaux cloud publiques (Amazon AWS et Microsoft Azure) et le développement de la solution est garanti par une très importante et très dynamique communauté de développeurs. De très nombreuses et prestigieuses entreprises soutiennent ce projet par le biais de la fondation OpenStack.

Disposer de notre propre cloud privé nous offre une grande flexibilité pour l’hébergement de nos services ou développements internes. Cela nous permet également de conserver un très haut niveau de compétence par rapport à OpenStack, sans oublier la maîtrise des coûts pour des services aux dimensionnements connus. Au travers de nos différents travaux liés à la mise en place et la gestion de notre propre cluster OpenStack, nous avons également eu l’occasion de contribuer sur différents aspects en lien avec nos besoins, notamment par rapport au système de déploiement TripleO.

Automatiser la création des ressources avec Terraform facilite la mise en place d’architectures de type “hybrid cloud” visant à mélanger ou déplacer des ressources entre cloud privé et cloud public, selon les besoins. Cette flexibilité permet de répartir les différents services d’un projet sur différentes solutions de cloud en fonction de nombreux critères (coûts, localisation, disponibilité de service, directives d’entreprise, capacity planning, etc.).

Nous travaillons actuellement sur le déploiement de notre propre cluster OpenShift sur notre nouveau cluster OpenStack. Disposer de notre propre infrastructure de type IaaS (OpenStack) mais également PaaS (OpenShift) nous permettra de répondre à la majorité de nos besoins internes, qu’ils soient basés sur des déploiements directement au niveau de la couche de virtualisation ou au travers d’une couche d’abstraction supplémentaire basée sur des containers (architecture de microservices).