OpenStack est un ensemble de logiciels open source permettant de déployer des infrastructures de cloud computing (infrastructure en tant que service IaaS). La technologie possède une architecture modulaire composée de plusieurs projets corrélés (Nova, Swift, Glance…) qui permettent de contrôler les différentes ressources des machines virtuelles telles que la puissance de calcul, le stockage ou encore le réseau inhérents au centre de données sollicité.
Le projet est porté par la Fondation OpenStack, une organisation non-commerciale qui a pour but de promouvoir le projet OpenStack ainsi que de protéger et d’aider les développeurs et toute la communauté OpenStack et la NASA.
Historiquement, Rackspace contribuait à la partie stockage d’OpenStack tandis que la partie calcul était développée par la NASA. A l’heure actuelle la fondation en charge du projet, nommé OpenStack Consortium, intègre plus de 150 entreprises, dont Canonical, Dell et Cisco.
OpenStack est composé d’une série de logiciels et de projets au code source libre qui sont maintenus par la communauté incluant: Nova, Swift, Glance, Horizon, Neutron… etc. La figure ci dessous donne une visibilité plus ou moins complète sur ces derniers.
Ses logiciels sont regroupés dans des couches selon les fonctionnalités dont ils disposent. Chaque couche colorée en rouge représente un type d’infrastructure. Les couches colorées en bleu représentent des services à un aspect plus logique (plus abstrait).
Dans ce qui suit une liste descriptive de certains modules regroupés par couche :
Traitements et calculs
Nova
Gère le cycle de vie d’instances de compute dans un environnement OpenStack. Les responsabilités incluent la génération dynamique, la planification et la mise hors service de machines virtuelles à la demande.
Configuration réseau
Neutron
Permet Network-Connectivity-as-a-Service pour d’autres services d’OpenStack, comme Compute d’Openstack. Fournit une API pour que les utilisateurs puissent définir les réseaux et les pièces jointes dedans. Possède une architecture enfichable compatible pour la plupart des ju fournisseurs connus de réseaux et de technologies.
Stockage
Swift
Stocke et récupère arbitrairement des objets data non structurés via une API RESTful basée sur HTTP. Le service est hautement tolérant aux pannes avec sa réplication de données et son architecture de type scale-out. Son implémentation diffère des serveurs de fichiers avec répertoires montables. Dans ce cas, le service écrit les objets et les fichiers vers plusieurs disques, en s’assurant que les données soient répliquées à travers le cluster de serveurs.
Cinder
Fournit un stockage de blocs persistants aux instances en cours d’exécution. Son architecture de pilote enfichable facilite la création et la gestion des périphériques de stockage en blocs.
Services partagés
Keystone
Fournit un service d’authentification et d’autorisation pour les autres services d’OpenStack. Donne un catalogue de points de terminaison pour tous les services d’OpenStack.
Glance
Stocke et récupère des images de disques de machines virtuelles. Compute d’Openstack en fait usage lors de la mise en service d’instances.
Ceilometer
Ce module permet d’avoir une télémétrie puisqu’il surveille et mesure le cloud OpenStack à des fins de facturation, d’analyse comparative, d’évolutivité et de statistique.
Interface utilisateur
Horizon
Fournit un portail de self-service basé web qui sert aux interactions avec les services sous-jacents d’OpenStack, comme le lancement d’une instance, le distribution d’adresses IP ou la configuration des contrôles d’accès.
Services de haut niveau
Trove
Fourni une fonctionnalité Database-as-a-Service, évolutive et fiable pour les moteurs de bases de données relationnels et non-relationnels.
Heat
Orchestre de nombreuses applications de cloud composées en utilisant soit le format de template natif HOT ou le format CloudFormation d’AWS, à travers soit une API REST native OpenStack ou soit par une API de Requête compatible avec CloudFormation. Pour plus de détails, vous pourrez lire notre article dédié au module en cliquant ici.
Par ailleurs, il n’est pas nécessaire d’installer OpenStack avec la totalités de ces modules, ou des modules qu’il peut proposer. Puisqu’on peut choisir de prendre uniquement les modules nécessaires aux besoins. L’indépendance de ses modules, et sa conception par composants permet d’avoir autant d’architectures que de solutions (ou applications) cloud à mettre en œuvre. Un exemple d’architecture (d’un vue choix de modules) est présenté par la figure suivante :
Aspect architectural d’OpenStack
Comme dit plus haut, la modularité d’OpenStack lui permet d’être installé selon le besoin sous de diverses architectures. Mais pour cette partie nous allons voir ça sous un angle infrastructural (si je puis dire) puisque nous nous intéresserons pas sur le choix des modules à installer mais plutôt sur la façon dont ils sont disposés et celle avec laquelle ils communiquent. En effet, il est possible d’installer les modules nécessaires (qui sont essentiellement des services) sur un seul et même nœud, ou alors de les disperser sur plusieurs nœuds.
La figure ci-dessous montre une architecture à plusieurs noeuds, où on a deux noeuds essentiels ; le noeud de contrôle et le noeud de calcul, puis d’autres noeuds secondaires pour le stockage.
En premier lieu, le nœud contrôleur qui est primordial quand on veut déployer une infrastructure (ou une solution) en mode distribué sur un réseau, puisque c’est le nœud qui s’occupe de la synchronisation des autres nœud – opérants la (ou les) solution(s) métier – en terme de temps (synchronisation des horloges).
En second lieu, le nœud de calcul permet la virtualisation de machines en images utilisables et partageables sur le réseau.
Ensuite, les nœuds de stockage qui sont chargé d’héberger les bases de données (et autres types de contenu) qui seront par la suite exploitées par les applications à mettre en place.
Enfin, et comme évoqué précédemment il est tout à fait possible, pour des cas d’utilisation simples, d’installer ces composants-là sur un seul et même nœud.
Enfin, et comme évoqué précédemment il est tout à fait possible, pour des cas d’utilisation simples, d’installer ces composants-là sur un seul et même nœud.
Vue réseau
Il ne suffit pas seulement d’installer les composants dont on a besoin sur des noeuds différent, il faut les faire communiquer à l’aide d’une configuration réseau. La figure ci-dessous montre l’architecture montrée dans la figure précédente sous une vue réseau i.e. où les nœuds sont connectés entre eux avec une configuration en NAT.
Saif Al-Qazweny, Khalil Hamani, Abdelhaq Ouattari
