Tutoriel pour apprendre les bases de OpenStack et construire son cloud privé

Le projet OpenStack a commencé avec le partenariat de Rackspace et de la NASA. Tous deux avaient besoin de travailler avec des téraoctets 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 côté, 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 13e 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.

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 disponibles 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 VM ;
• nova-scheduler : coordonne le déploiement des VM 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 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 nœuds 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 trois 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.

Le stockage par bloc est à la base de la sauvegarde des machines virtuelles et de leurs données. Par défaut, les VM 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 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 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.

Il gère toutes les interfaces réseau 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 flottante à la VM afin d'autoriser les communications vers le monde extérieur.

Différentes méthodes peuvent être mises en œuvre 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 VM 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, telles que :

1. Le segment réseau où se trouve la VM ;
2. Le subnet ou plage d'adresses 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 multiple et complexe, au gré des besoins de l'utilisateur du tenant. L'API permet ainsi aux administrateurs d'être plus flexibles lors des personnalisations faites au niveau des configurations.

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).

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.

Enfin, nous avons l'orchestrateur Heat qui permet d'instancier automatiquement les instances, les différentes briques du réseau 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 nommé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, que l'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 complète 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.

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 certain 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é.

Tous nos remerciements à Wescale pour l'autorisation de publication de ce tutoriel.

Nos remerciements également à Winjerome pour la mise au gabarit Developpez.com et Jacques Jean pour la relecture orthographique.