OpenStack : Panorama

Pour la petite histoire

Le projet OpenStack a commencé avec le partenariat de Rackspace et de la NASA. Tous deux avaient besoin de travailler avec des teraoctets de données — l’un pour stocker les données de leur plate-forme Cloud et l’autre pour les traitements d’imagerie satellite. Ils ont alors, chacun de leur coté, développé les premiers modules qui sont à la base d’OpenStack — la partie de gestion des VM (Nova) par la NASA et le stockage (Swift) par Rackspace.

Le projet devient open-source en 2010 avec la première version Austin sortie en octobre de cette même année. La dernière version, Mitaka, sortie en avril 2016, est la 13ème de la série. Openstack est considéré, depuis la version Kilo, comme “enterprise ready” grâce à l’effort communautaire pour y ajouter les fonctionnalités nécessaires telles que la scalabilité, la haute-disponibilité et la métrologie.

L’image ci-dessous présente l’architecture globale d’OpenStack. Je vous présenterai ensuite les principaux modules, qui forment la base de la plate-forme.

Nova – Compute

La partie compute d’OpenStack, Nova, permet de communiquer avec l’hyperviseur pour lancer et gérer les machines virtuelles. Plusieurs types d’hyperviseurs sont actuellement disponible tels que Xen, VMWare (ESX) et Hyper-V. Mais KVM est le mieux supporté par OpenStack. Nova est divisé en composants :

• nova-api : traite les requêtes API venant des clients
• nova-compute : daemon nova qui gère les VMs
• nova-scheduler : coordonne le déploiement des VMs sur les machines physiques
• nova-conductor : interlocuteur entre nova-compute et la base de données

Dans une architecture classique, nova-compute peut être installé sur une ou plusieurs machines physiques. Ces daemons communiquent entre eux via le bus de message RabbitMQ. Toutes les demandes sont traitées par nova-api qui délègue ensuite la tâche à nova-compute. Par exemple, lors d’une demande de création d’instance (VM), nova-api fait une demande auprès de nova-scheduler afin de déterminer la machine hôte sur laquelle lancer l’instance (dépendant de sa taille et des disponibilités des serveurs physiques). La demande est ensuite transmise au nova-compute présent sur le serveur afin de lancer la nouvelle machine virtuelle.

Swift – Object Storage

Swift est la partie de stockage d’objets qui reprend le comportement d’Amazon S3. Il s’agit du deuxième projet mis en open-source lors de la release d’OpenStack en 2010. On peut l’utiliser indépendamment des autres modules d’OpenStack afin de créer un cluster de stockage objet. Swift fournit aux entreprises qui cherchent à stocker des données efficacement  une solution hautement disponible  à moindre coût. Il est divisé en deux parties principales :

• Proxy server
• Storage nodes

Les requêtes venant des clients REST passent par le proxy qui se coordonne ensuite avec les noeuds de stockage appropriés pour traiter la demande. Par exemple, un utilisateur souhaitant stocker une photo fera sa requête par une commande PUT au proxy qui s’occupera d’envoyer l’objet sur le cluster de stockage.

Lors de la sauvegarde d’un objet, Swift en fait 3 copies et tente de les stocker sur trois serveurs distincts. Swift retourne ensuite un code réponse au client qui est alors assuré que ses données sont sauvegardées et répliquées.

Cinder – Block Storage

Le stockage par bloc est à la base de la sauvegarde des machines virtuelles et de leurs données. Par défaut, les VMs utilisent un stockage éphémère (les données stockées sont détruites en même temps que la VM). Cinder, de son côté, permet de créer des volumes persistants de stockage par bloc (block storage).

Les volumes peuvent être attachés à une VM. Le volume est vu comme un n-ième disque dur de la machine. Le volume peut être détaché et attaché à une autre instance en cas de besoin, ce qui est une très bonne solution pour conserver les données  utilisées par une application lorsque son instance est détruite.

Glance – Image service

Glance s’occupe de gérer les images utilisées par les machines virtuelles pour démarrer. Nova communique avec Glance en utilisant son API lorsqu’une instance est déployée. OpenStack supporte plusieurs formats d’images, parmi les plus connus, on retrouve :

• raw : format de base, non structuré, brut
• vhd, vmdk  : reconnu par la plupart des hyperviseurs (VMWare, Virtualbox, Xen, …)
• vdi : reconnu principalement par Virtualbox et QEMU
• iso : format d’archive d’images
• qcow : utilisé par qemu pour du Copy-On-Write

D’autres formats d’images sont supportés, par exemple celui  utilisé par Amazon (AMI Amazon Machine Images). Les images peuvent être stockées sur le système de fichiers, dans Swift ou sous forme de volume Cinder.

Keystone – Auth

Keystone est le gestionnaire d’autorisation des utilisateurs OpenStack. Un client authentifié récupère un token d’autorisation basé sur ses droits qui sont enregistrés sur la plate-forme. Ce token lui permet de communiquer avec l’ensemble des modules exécutés par OpenStack.

Keystone permet de gérer l’authentification de manière classique avec une base de données  MySQL, ce qui n’est pas recommandé en terme de sécurité. Une meilleure alternative est de laisser la responsabilité de l’authentification à des outils externes avant que Keystone ne génère son token. Plusieurs intégrations sont disponibles telles que LDAP, Active Directory et Kerberos.

Neutron – Software Defined Network

Il gère toutes les interfaces réseaux qu’utilise OpenStack. Le pré-requis lorsqu’on lance une VM est de créer l’architecture réseau sur laquelle elle sera déployée. Cela consiste donc à définir un réseau et son plan d’adressage (subnet) pour ensuite y attacher un routeur. Celui-ci permet l’association d’une adresse IP flotante à la VM afin d’autoriser les communications vers le monde extérieur.

Différentes méthodes peuvent être mises en oeuvre pour segmenter l’architecture réseau, via l’utilisation de plugins tels que OpenVSwitch et Modular Layer 2 (ml2). Par exemple, dans un réseau en VLAN, chaque projet (tenant) se voit assigner un numéro de vlan. Cela permet alors au commutateur virtuel (OpenVSwitch) de transmettre les données échangées entre les VMs d’un même réseau sans entrer en conflit avec les autres projets ayant le même adressage.

Tout comme les autres modules, Neutron possède également une interface d’API. Très utile pour les administrateurs, elle permet d’avoir une vue abstraite des ressources utilisées, telle que :

1. Le segment réseau où se trouve la VM
2. Le subnet ou plage d’adresse en IPv4 ou IPv6 configurable pour le réseau
3. Le port de connexion entre l’interface réseau (NIC) d’une VM au réseau virtuel

La création des topologies de réseau peut alors être multiples et complex, au gré des besoins de l’utilisateur du tenant.  L’API permet ainsi aux administrateurs d’être plus flexible lors des personnalisations faites au niveau des configurations.

Ceilometer – Métriques

La récupération de métriques de la plate-forme OpenStack est prise en charge par Ceilometer. C’est un service de collecte de métriques pouvant être utilisé pour de la facturation clients (CloudKitty), du suivi de ressources (Gnocchi) et de la remontée d’alertes (Aodh).

Avec Ceilometer, chaque projet envoie ses événements (création, suppression d’instance, …) par le biais du bus de message. Les informations sont collectées par des agents  (agent-notification).

Horizon – Cockpit

Le tableau de bord OpenStack est fourni par Horizon. Il permet d’administrer les différents composants dans un navigateur. Chaque utilisateur authentifié peut déployer une machine virtuelle, ajouter une image, créer un volume etc. D’autres fonctionnalités peuvent encore être ajoutées au tableau de bord pour les nouveaux composants qui continuent d’être développés.

Heat – Orchestrateur

Enfin, nous avons l’orchestrateur Heat qui permet d’instancier automatiquement les instances, les différentes briques du reseau logique, ou tout autre composant cloud disponible sur Openstack. Le projet Heat a été initié au départ afin de reprendre le fonctionnement de CloudFormation, qui permet de créer les ressources liées à AWS. Basé sur le formatage par template, il possède sa propre syntaxe nomée HOT (Heat Orchestration Templates) en YAML. Grâce au composant heat-api-cfn, il supporte également les requêtes du style AWS CloudFormation (format JSON).

Le template HOT permet de définir des collections de ressources, appelées Stack, qu’on souhaite déployer sur un projet. Il permet de définir, par exemple, deux instances tournant sur un réseau privé, connecté à un routeur. Lors du lancement de ce template, la stack complete est déployée sur un tenant automatiquement.

La liste des ressources pouvant être déployées par HOT est longue et une, particulièrement intéressante, permet de lancer des scripts de configuration pour installer des applications directement sur les machines virtuelles.

Conclusion

Vous possédez maintenant une vision globale du fonctionnement de la plate-forme d’infrastructure OpenStack. En fonction de vos ambitions, vous pouvez tirer parti d’OpenStack soit pour des besoins de tests à l’échelle d’une équipe, soit scaler jusqu’à maintenir un fournisseur de Cloud Public. L’investissement en matériel, temps et expertise nécessaire ne sera évidemment pas le même. 🙂

OpenStack est un projet très vaste avec de multiples usages. Selon vos besoins il nécessite des connaissances pointues sur un certains nombre d’aspects du Cloud Computing. Nous reviendrons plus en détail sur des cas plus pratiques dans d’autres articles mais vu l’ampleur de cet écosystème, cet article de préambule était un passage obligé.