5 La maturité d’OpenStack pour l’entreprise a beaucoup retenu l’attention lors du sommet OpenStack de Vancouver, plus tôt cet été, ce qui est particulièrement intéressant car cela montre qu’OpenStack a atteint un certain niveau de maturité. Mais cela signifie-t-il que les DSI disposent des outils nécessaires pour exploiter OpenStack et maintenir une installation ? Les applications d’entreprise existantes peuvent-elles migrer vers le cloud privé ? Une différence notable entre une application cloud et une application métier d’entreprise traditionnelle, c’est que la première est conçue en tenant compte de la nature dynamique du cloud. Elle suit les ressources ajoutées et retirées, et n’essaiera pas d’interagir avec un service qui n’existe plus. À l’inverse, dans une application métier classique, la configuration est souvent statique et dépend de services hautement disponibles (HA) immuables. La fiabilité de l’infrastructure cloud sous-jacente est donc la pierre angulaire des configurations HA. La haute disponibilité dans le cloud Au sommet, on entendait qu’il est tout à fait possible d’exploiter un cloud OpenStack résilient, mais que ce n’est pas simple. Il n’existe pas de moyen simple de configurer OpenStack en haute disponibilité. De nombreuses décisions sont à prendre pour mettre en place un tel système, à commencer par le matériel, puis en remontant la pile jusqu’à la configuration d’OpenStack lui-même. La haute disponibilité dans OpenStack (en anglais) a en réalité deux volets : d’un côté, l’espace des tenants avec le réseau, le stockage, le calcul, etc. ; de l’autre, le plan de contrôle d’OpenStack par lequel toutes les ressources cloud sont pilotées. Beaucoup de choses ont évolué dans ce domaine au cours des dernières versions, et une grande partie des fonctionnalités nécessaires à une configuration hautement disponible des deux côtés est arrivée. L’un des ajouts les plus importants concerne selon moi le réseau, avec l’amélioration du service de routage virtuel. Dans les anciennes versions, il était difficile de faire face à la panne d’un nœud réseau Neutron, qui entraînait l’indisponibilité des routeurs virtuels qu’il contrôlait. Les machines virtuelles desservies se retrouvaient alors isolées : c’était un point de défaillance unique jusqu’à la version Juno, qui a résolu le problème grâce à VRRP. Dans une configuration HA, deux nœuds réseau sont généralement associés pour fournir le service de routage virtuel. L’un sert de maître et synchronise l’état de ses sessions TCP avec l’autre, qui fait office de secours. En cas de panne du maître, le nœud de secours prend le relais du service de routage virtuel. Côté nœuds de calcul, la migration à chaud des instances est possible, ce qui facilite la maintenance avec un minimum d’interruption. Encore faut-il bien dimensionner les ressources des nœuds de calcul, sans quoi l’évacuation de la majorité des machines prendrait trop de temps. D’un point de vue opérationnel, c’est indispensable pour maintenir l’OS sous-jacent à jour. Mais les outils d’exploitation sont encore loin d’être à la hauteur de nos attentes. La mise à niveau n’a rien de simple : il ne s’agit pas seulement de tenir OpenStack à jour, mais aussi l’OS sous-jacent, avec les correctifs de sécurité urgents comme avec les mises à jour planifiées. Le plus difficile, c’est le plan de contrôle. C’est un processus complexe qui exige en pratique une conception HA pour limiter l’indisponibilité des API de service. Une mise à niveau implique d’interrompre le service mis à jour, et une coupure survient dans une configuration non HA. En l’état, l’outillage autour de ces tâches n’est pas bon. Il n’y a pas de simple bouton « mettre à niveau », et il faut maîtriser de nombreux outils pour mener une mise à niveau. Sans approche DevOps s’appuyant sur une couche de gestion de configuration, c’est pratiquement impossible. Plusieurs sessions du sommet ont abordé les problématiques de mise à niveau. Toutes celles auxquelles j’ai assisté ont souligné l’importance de la planification (y compris un plan de retour arrière en cas de problème) et de l’automatisation. Il y a clairement des lacunes dans ce domaine, mais vu l’attention et les échanges qu’il a suscités au sommet, je pense que nous verrons de nettes améliorations dans les prochaines versions. Côté matériel, le choix des composants est important et peut causer des problèmes s’il est mal fait. Cela ne veut pas dire qu’il faut remplacer tous les serveurs pour exécuter OpenStack : il fonctionne en gros partout où Linux fonctionne, mais il est toujours judicieux de vérifier que les modules du noyau sont matures pour tous les composants du serveur. Bien sûr, certains composants comptent plus que d’autres. Le choix de la carte réseau peut avoir un fort impact en production, bien plus que celui du processeur. Les constructeurs ont commencé à publier des architectures de référence pour OpenStack, avec des configurations matérielles testées. Si vous partez de zéro, cela peut être un excellent point de départ. Abaisser la barrière Manila est un projet qui rend OpenStack encore plus attrayant pour l’entreprise. De nombreuses sessions portaient sur ce système de fichiers partagé, et on nous a aussi interrogés sur la prise en charge de Manila sur notre stand lors du sommet. Manila permet aux applications exécutées dans OpenStack de s’appuyer sur un service cloud pour obtenir des partages de fichiers. Auparavant, ces besoins devaient être gérés par des nœuds de calcul exportant des partages, obligeant le développeur ou les ingénieurs d’exploitation à gérer la maintenance et les scénarios de panne du serveur de partage. Manila supprime ces contraintes et fournit un service de partage de fichiers de premier plan dans OpenStack, tout comme Cinder pour les périphériques bloc. Cela facilite aussi la montée en charge d’une application qui dépend non seulement d’un stockage objet ou d’une base de données, mais aussi de fichiers : il suffit de lancer davantage d’instances et de monter le système de fichiers partagé exposé par Manila. C’est peut-être encore plus intéressant pour les applications existantes qui n’utilisent pas du tout de stockage objet, et cela pourrait faire la différence lors du passage au cloud. Manila n’étant pas encore prêt à être publié, la documentation manque et de nombreux blueprints importants sont encore en cours. Le plus notable est l’absence d’automatisation du montage, l’un des sujets des sessions de conception du sommet. Il existe de nombreuses façons d’aborder ce problème et, avec la prolifération des conteneurs dans l’écosystème OpenStack, il n’y a pas qu’une seule « bonne » façon de faire. La « méthode conteneur » consistera très probablement à monter le partage sur l’hôte, puis à le monter en bind avant le pivot vers le système de fichiers du conteneur. C’est très différent du lancement d’une VM, qui devra découvrir et monter elle-même le partage au démarrage. Plusieurs techniques ont été évoquées, dont l’introduction d’un agent qui découvre et monte les partages au démarrage. Autre point intéressant abordé au sommet de conception : les groupes de cohérence ont-ils du sens pour Manila ? Un cas d’usage évident pour les applications cloud est difficile à trouver. Le cas classique, c’est une base de données qui répartit ses données sur plusieurs volumes et dont il faut créer une sauvegarde cohérente. C’est probablement une fonctionnalité plus utile aux applications d’entreprise, qui pourrait les aider à passer au cloud. Avec des services cloud de plus haut niveau comme Manila, la barrière à la migration des applications d’entreprise vers le cloud s’abaisse. Moins de VM sont à provisionner pour les services annexes, ce qui permet aux équipes IT de passer moins de temps à surveiller des VM dédiées. Sessions intéressantes sur la haute disponibilité et la maturité pour l’entreprise https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/lessons-learned-on-upgrades-the-importance-of-ha-and-automation https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/real-world-experiences-with-upgrading-openstack-at-time-warner-cable https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/dell-and-red-hat-taking-openstack-to-the-enterprise Conférences sur Manila https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/manila-an-update-on-openstack-and-039s-shared-file-services-program https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/manila-101-and-38-use-cases
