En informatique d’entreprise actuellement, la grosse tendance c’est le cloud. Peut-importe que l’on balance toutes nos données sur des serveurs partagés avec le concurrent, peut importe que le Patriot Act permette aux États-Unis de fouiller toute info stockée sur le cloud d’un prestataire ricain (qui sont actuellement quasiment les seuls fournisseurs sérieux sur le marché), on balance tout sur le réseau, ce qui permet de dégager une bonne partie de la bande de geeks nauséabonds qui effrayaient les secrétaires, faisaient des blagues incompréhensibles, et parfois – parfois – géraient le parc informatique.
On s’accorde à dire que le cloud, dans sa version théorique, c’est la promesse d’un Eden rose et pur, où l’on n’aurait plus besoin de brosser le poil de nos serveur-poneys avant de les envoyer paître dans les vertes prairies de l’Internet. Soit. Mais fort heureusement pour un bon nombre de professionnels (et pour toute personne de bon goût), ce monde n’existe pas, du moins pas si on ne lui ajoute cette délectable touche de vice qui nous anime tous et nous rend plus ou moins dangereux pour la viabilité d’un concept selon nos compétences. Sortons de cette métaphore animalière avant de sombrer dans la zoophilie, et contentons-nous de dire qu’il y a tellement de raisons de vouloir trouer du cloud (économique, politique, idéologique, for teh lulz, etc.) qu’on peut raisonnablement se demander si celui-ci ne présente pas, au niveau de maturité qui est le sien, un risque inconsidéré.

Mais je ne vais pas vous spoiler la réponse, aujourd’hui je veux parler d’OpenStack, un outil (ou plutôt un gros paquets d’outils) qui permet en gros de créer et contrôler une ou des infrastructure(s) virtualisée(s) sur une grappe de serveurs. Le terme dans le milieu est IaaS, pour « Infrastructure as a Service ». Contrairement à un outil PaaS (« Platform as a Service »), un IaaS n’a pas vocation à contrôler ce qui se passe dans les machines virtuelles.
[ Nota Bene : part 1 parce qu’une part 2 pourrait bien suivre, plus orienté pratique (et c’est surtout cette part 2 qui donnera in fine la conclusion à la question ultime : « Ist OpenStack über kool oder nicht ? »). Voir la fin de l’article pour plus de détails.]

OpenStack – Fiche rapide :

Version : 5e version Essex (avril 2012),  prochaine version Folsom le 27 septembre
Première release : octobre 2010
Licence : Apache 2.0 (open-source quoi)
Langage principal : Python
Gestion : interface Web (et aussi des API pour à-peu-près tous les modules)
Hyperviseurs : surtout QEMU-KVM et Xen, mais aussi LXC, ESX et ESXi
Installation : paquets pour Ubuntu, Debian, RedHat, SUSE, Fedora
Contributeurs : Rackspace, NASA, Cisco, Dell, Intel, HP, IBM, Microsoft, Red Hat, SUSE, VMware, … (oui, ça fait un peu penser à la liste d’acteurs de The Expendable)

Composantes :

Nova

Module de gestion des volumes (~partitions qui servent de support aux machines virtuelles) et des machines virtuelles elles-même. Nova gérait aussi, de façon minimaliste, quelques éléments de réseau (notamment l’IP), avant la sortie du module Quatum.
Nova est le core nécessaire (mais non suffisant) d’OpenStack. Il est composé de plusieurs démons, gérant entre autre les hyperviseurs, les volumes et quelques paramètres réseaux, d’un scheduler pour contrôler/répartir la charge sur les équipements physiques et bien sûr d’une API pour contrôler tout ce petit monde (compatible avec l’API EC2 d’Amazon).

Glance

Glance est responsable de la gestion d’images d’OpenStack (machines virtuelles, appliances). Comprendre qu’il n’y a a priori pas de lien vital entre la partie logicielle d’un ordinateur (le système d’exploitation + les logiciels + les données) et sa partie matérielle (qu’elle soit réelle ou virtuelle). L’image d’une machine virtuelle peut donc être baladée plus ou moins comme on l’entend, pour de multiples raisons : migration sur un autre volume, sur un autre hyperviseur, copie de la machine, snapshot, backup, etc.

Swift

3e core historique (avec Glance et Nova) d’OpenStack, Swift est en gros la base de données du projet… et un peu plus : elle fait aussi des tâches de réplications et d’archivage, peut limiter l’emplacement des données dans des « zones », contrôle et assure l’intégrité de la base.

Horizon

Un produit de cette dimension à beau être génial, il ne trouvera jamais ses utilisateurs sans GUI digne de ce nom. Cette GUI, c’est Horizon. Développée avec le framework Django (encore du Python !), Horizon est accessible à travers un navigateur web.

Elle est divisée en 2 parties.
Horizon System Dashboard permet de gérer toute une plate-forme OpenStack, depuis la grappe de serveurs physiques (oui d’accord, rien n’empêche qu’ils soient virtuels mais bon…) qui sert de support à la plate-forme, jusqu’aux différents clouds hébergés (chacun contenu dans un projet) en passant par les instances de machines virtuelles, la gestion des quotas (tel projet doit se contenter de 20Go et 10 vcpus, etc.), des utilisateurs, …
Horizon Project Dashboard, qui a un peu moins une vision super-admin, mais plutôt utilisateur. Le contrôle des instances est moindre, on ne peut plus importer d’images ni construire de flavors, (le supports virtuels sur lesquels les images bootent), par contre on a la main sur les volumes, et 2-3 autres petites choses.

Keystone

Le module d’authentification centralisé d’OpenStack, qui permet de se balader dans les autres modules sans devoir s’identifier tous les quatre matins.

Quantum

Un jeune module, considéré comme incubated dans la version 5 Essex d’OpenStack, et qui passe en core dans la prochaine version Folsom (27 septembre 2012). Les développeurs considèrent donc qu’il est suffisamment mature pour être installé sur des plates-formes stables.
Quantum est censé reprendre et améliorer le travail de gestion de tous les paramètres réseaux autrefois gérés par Nova. L’ambition est de proposer la possibilité de virtualiser un réseau à partir de la couche 2 du modèle OSI. L’utilisation de VLANs, de bridge linux et autres technologies bien connues semblant peu efficace, Quantum les renforcent en permettant d’utiliser toute un gamme d’outils plus récents : OpenFlow, FabricPath, Qfabric, Openvswitch, Nicira NVP, etc. L’objectif est de laisser le choix de la techno à l’utilisateur, tout en restant capable de :

• gérer les IP des machines virtuelles,
• appliquer des règles iptable sur n’importe quelle interface,
• appliquer des politiques de sécurité globales à un cloud,
• appliquer de la QoS,
• contrôler et gérer le réseau,
• insérer des composants réseaux avancés (firewall, IDS, VPN, …).

Concepts et utilisations :

OpenStack propose globalement 3 niveaux différents :
Tout d’abord les instances, qui sont créées à partir, d’une part d’un flavor (description du support : nombre de vcpus, quantité de RAM, espace disque, etc.) et d’autre part d’une image de machine virtuelle. On a la possibilité de générer des paires de clefs afin d’avoir un accès SSH sur une machine. Des volumes peuvent être rattachés à ces machines virtuelles, ainsi que des IP, qui permettent in fine de regrouper ces machines en réseau (2e niveau).
Sur chaque réseau, on peut exploiter les possibilités de Quantum, autant pour ajouter des composants réseaux que pour régler la QoS ou les politiques de sécurité.
Enfin, plusieurs réseaux peuvent cohabiter dans un projet (3e niveau), qui sert surtout pour la distribution des utilisateurs, qui peuvent ou non accéder à un projet, avec des droits plus ou moins étendus.

Les 3 principaux points forts sont (selon moi) :

1. la scalabilité, c’est à dire la capacité d’OpenStack à adapter automatiquement les caractéristiques des différents objets manipulés, d’un côté aux demandes des utilisateurs (j’ai besoin de pus de place – ce projet ne doit pas consommer plus de 5 vcpus – j’allume 30 machines virtuelles d’un coup) et de l’autre côté aux capacités matérielles de la grappe hôte (je supporte une charge énorme et le serveur voisin se la coule douce);
2. la robustesse affichée, avec partout des mécanismes de backup, de contrôle d’intégrité et de correction;
3. la modularité exemplaire, avec des API partout qui permettent apparemment d’interfacer facilement une application maison avec n’importe quel core. Comme qui dirait au sujet d’OpenStack : « It’s not a cloud computing stack. It’s a framework of standards and APIs so that people can build their own cloud solutions. » (je me rappelle plus le nom de la personne qui dit ça, mais c’est au moins un contributeur important du projet).

Les deux premiers points en font une plate-forme adaptée pour les projets de tailles conséquentes, avec une grappe physique sous-jacente bien étoffée.
On a donc visiblement un bel outil plutôt orienté pour des architectures importantes, qui permet de s’adapter assez facilement à des besoins complexes (ou pas d’ailleurs), quitte à écrire à côté des petites routines.
OpenStack possède évidemment beaucoup d’autres qualités, dont le fait d’être open-source et de pouvoir afficher suffisamment de partenariat pour qu’on soit assuré que le support tiendra bien au moins plusieurs années.

Mais malgré toutes ses qualités, on arrive tout de même à trouver pas mal de cas d’utilisations pour lesquels OpenStack ne semble pas très bien adapté. Je parle surtout de projet de taille réduite ou ayant une durée de vie limitée (qui sont légions), pour lesquels OpenStack n’est pas pratique de par son gigantisme qui devient non seulement inutile, mais en plus lourd à installer / administrer / utiliser.
À noter aussi le départ de Citrix du projet, boîte qui est quand même d’une importance certaine dans le petit monde du cloud. Les raisons données semblent centrées sur le fait que le produit originel de Citrix, CloudStack, ne pouvait s’intégrer à OpenStack; Citrix aurait donc préféré retourner à son produit (qui possède déjà des clients et serait plus mature).

On trouverait donc son utilité plutôt sur de grosses plates-formes de production, avec en amont une installation sérieuse et adaptée au besoin (comprendre longue et pleine de scripts maisons et de tests multiples et variés).

## Pour le test à venir :

Le but est bien évidemment d’installer une plate-forme OpenStack pour la triturer un peu, voir jusqu’à quel point et avec quelle facilité on peut maîtriser le cloud. Voir aussi si la plomberie est bien huilée sous la jupe.
Malheureusement, les restrictions au niveau de mon matériel font que la grappe de serveurs sera vraisemblablement limité à une seule machine. Une distribution adaptée existe (Airframe, mise à disposition par Piston Cloud – rien à voir, mais en passant je suis totalement fan du style de leur site), mais évidemment tout ce qui touche à la scalabilité (provisionnement de ressources à la volée, répartition des machines virtuelles, migration en cas de saturation etc.) restera inutilisé, et c’est malgré tout un gros point d’OpenStack (en tout cas c’est pas mal là-dessus qu’on l’attend, vu ce que sont capables de faire les concurrents, notamment Amazon).
Un test qui ne se fera pas non plus dans l’immédiat, ne serait-ce que pour pouvoir profiter de la version Folsom, qui sort le 27 septembre !