INTRODUCTION À LA CONFIGURATION D'OPENSTACK SUR PLANETHOSTER

Première partie : prérequis pour OpenStack dans l'environnement PlanetHoster

Jean-Philippe Méthot

Depuis un certain temps déjà, Openstack s'est imposé comme plateforme novatrice dans l'implantation du cloud open source. D'ailleurs, d'autres en ont déjà parlé sur ce site. Comme chez PlanetHoster nous avons centré notre infrastructure interne autour d'Openstack, nous vous proposons une série d'articles explorant l'installation d'Openstack. Vous pourrez voir comment procéder à l'installation d'un cloud Openstack étape par étape. Aujourd'hui, nous nous attarderons aux différents choix et options qui s'offrent à vous avant même de commencer l'installation à proprement parler. Il est important d'établir le nombre de serveurs dont nous aurons besoin, le type d'infrastructure réseau que nous utiliserons et quel système de stockage adopter afin de subvenir à nos besoins.

Un espace de discussion vous est proposé sur le forum pour partager votre avis. Commentez

- Titre : INTRODUCTION À LA CONFIGURATION D'OPENSTACK SUR PLANETHOSTER

- Auteur : Jean-Philippe Méthot

- Parution : 5 mars 2018

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2018  Jean-Philippe Méthot. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Nombre de serveurs physiques requis

- II. Configuration réseau requise

- III. Fonctionnement du stockage

- Conclusion

- IV. Note de la rédaction Developpez.com

- V. PlanetHoster

I - Nombre de serveurs physiques requis

Openstack peut être déployé sur un seul serveur dédié (physique). Toutefois, une telle infrastructure n'est recommandée qu'à fin de test. À mon humble avis, le minimum de serveurs à utiliser en production est de deux, voire trois si l'on désire utiliser toutes les fonctionnalités de migration d'Openstack. On peut diviser l'infrastructure en deux types de serveurs : les contrôleurs et les computes. Les contrôleurs hébergent la plupart des services Openstack, les API et les bases de données. Les computes hébergent les services nécessaires au fonctionnement des machines virtuelles ainsi que les VM elles-mêmes.

L'idée derrière une telle séparation des services est d'isoler les services d'Openstack, afin de permettre à celui-ci de fonctionner même si un serveur de compute tombe down. Il devient alors possible de recréer les VM sur un serveur différent en cas de panne, effectuant ainsi une migration d'urgence.

Dans une configuration simple, nous pouvons nous attendre à avoir un seul contrôleur et plusieurs computes. L'un des avantages majeurs du cloud est de pouvoir facilement transférer une instance virtuelle d'un serveur physique à un autre. En ayant plusieurs computes, nous nous assurons d'obtenir cette fonctionnalité. Ceci dit, qu'en est-il de la redondance au niveau des services d'Openstack sur le contrôleur ? Il est possible de rendre la plupart de ces services redondants de manière active-active ou active-passive en configurant un second nœud contrôleur. Toutefois, ce sujet dépasse le cadre de cet article et nous pourrons en traiter dans un tutoriel subséquent.

II - Configuration réseau requise

Maintenant que nous avons une bonne idée du nombre de serveurs provisionner pour construire notre petit cloud privé, qu'en est-il des connexions réseau ? Toute implémentation d'Openstack aura besoin d'au moins deux réseaux : un réseau d'administration et un réseau pour les machines virtuelles. Le réseau d'administration permet aux services de communiquer entre eux. Le réseau des machines virtuelles permet aux VM de communiquer avec l'Internet. Plusieurs nuances peuvent s'appliquer ici, dépendamment du type de réseau choisi. Comme il s'agit d'un choix crucial qui va influencer l'infrastructure du cloud lors de la mise en place des serveurs, je vais ici m'y attarder. On peut séparer les infrastructures réseau en trois grands types : flat, SNAT, DVR et SDN.

Flat est un type d'infrastructure réseau qui a l'avantage d'être simpliste. On y perd cependant plusieurs fonctionnalités réseau d'Openstack, telles que les adresses IP flottantes. Il n'y a pas non plus de possibilité de redondance à l'intérieur d'Openstack avec ce type de réseau, bien que des mécanismes externes peuvent être implémentés. Il requiert de brancher chaque compute directement à la switch ou au routeur menant au réseau externe. Chaque VM provisionnée devra avoir une IP externe fournie par Openstack, ce qui demande l'injection d'une adresse IP dans l'instance par des moyens détournés, comme cloud-init.

SNAT est une autre configuration réseau simple à implémenter. Cette configuration s'appuie sur un service de NATing s'exécutant généralement sur les nœuds de contrôleur ou, dans de plus grands déploiements, sur des nœuds dédiés à cet effet. En ce sens, seuls le ou les nœuds ayant le service de NATing doivent être connectés au routeur assurant la connexion à l'Internet. Les computes n'ont besoin que d'un réseau local vers le serveur ayant le service de NATing. Cette configuration permet l'utilisation d'adresses IP flottantes, c'est-à-dire des adresses IP qui peuvent être assignées et enlevées à n'importe quelles instances n'importe quand. La machine virtuelle ne possède qu'une IP locale et l'adresse IP flottante lui est assignée dans le NAT pour communication avec l'extérieur. À noter qu'une instance ne possédant pas d'IP flottante peut toujours initier des connexions avec l'externe, mais qu'elle ne peut en recevoir tant qu'une IP flottante ne lui sera pas assignée.

Le DVR est une version évoluée du SNAT. Au lieu d'avoir le service de NATing sur un ou plusieurs nœuds spécifiques, séparés des computes, le service est installé sur tous les serveurs. La raison est bien simple : si un lien tombe, les instances ont alors la possibilité d'utiliser n'importe quel lien menant au router en passant par un autre compute. Il s'agit donc d'une solution de redondance. Les adresses IP flottantes sont aussi utilisables, puisqu'on fait encore du NATing à chaque point de sortie vers l'externe. Son grand défaut reste toutefois le besoin que chaque compute ait un port à haute vitesse vers le router, ce qui peut être difficile dans les clouds plus gros. Autre solution potentielle, les SDN (software defined network) sont offerts par différentes entreprises. Chacun offre des avantages et requiert des configurations physiques différentes que nous ne couvrirons pas ici. Ils ont néanmoins l'avantage d'être généralement accompagnés d'un service de support offert par la compagnie. Le désavantage majeur est que, bien que certains soient open source et gratuits, ceux offrant du support sont payants. Parmi les plus populaires, on retrouve OpenDaylight et OVN.

III - Fonctionnement du stockage

Une fois que nous avons une bonne idée de notre infrastructure réseau, nous devons choisir quel type de stockage nous allons utiliser pour nos instances de machine virtuelle. Pour commencer, nous devons décider entre utiliser du stockage dit « éphémère » ou du stockage « persistant ». Comme son nom l'indique, le stockage éphémère est effacé lorsque la VM est détruite. Il est administré par le même service qui gère les machines virtuelles sur les computes. Ce type de stockage se trouve sur les disques des instances ou sur un cluster Ceph, si on décide d'y aller avec Ceph comme solution de stockage. Le stockage persistant est administré par un service que l'on nomme Cinder. Cinder possède une multitude de plug-ins permettant de stocker les données sur plusieurs médias de stockage, incluant NFS, une quantité énorme de modèles de SAN et CEPH. De plus, Cinder peut facilement créer des copies des données des instances et échanger des disques virtuels entre VM. À noter qu'il est aussi tout à fait possible d'utiliser ces deux types de stockage en même temps. Par exemple, on peut provisionner une VM utilisant de l'espace de stockage éphémère pour son disque principal et avoir un deuxième disque en stockage persistant.

Une fois que nous avons décidé quel type de stockage utiliser, nous pouvons choisir quel type de médium physique hébergera nos données. Gardons seulement en tête la considération suivante : stocker en local sur les computes est très simple et prend peu d'effort, mais migrer une instance d'un serveur compute à un autre peut prendre énormément de temps, puisque que tout le contenu de la VM doit être transféré. Il est généralement préférable d'utiliser un médium de stockage accessible par réseau pour tout environnement de production. Des solutions gratuites telles que NFS et CEPH peuvent être utilisées. Divers modèles de SAN sont aussi fonctionnels, vous laissant l'embarras du choix. Il faut toutefois considérer que toute solution de stockage sur le réseau va nécessiter au minimum une connexion de 1 gbps sur le réseau. Je recommande même d'y aller à 10 gbps pour les environnements de production où il y a un grand nombre de VM.

Conclusion

Avec toutes ces informations, vous devriez maintenant avoir une bonne idée de comment planifier votre infrastructure Openstack. L'infrastructure d'exemple sera un cluster Openstack à trois nœuds, un contrôleur et deux computes. L'infrastructure réseau sera le SNAT et le stockage sera hybride éphémère et persistant avec CEPH comme médium de stockage, tout simplement, car ce sont les choix les plus populaires chez les utilisateurs d'Openstack. Ainsi, dans le prochain article, je traiterai des étapes préliminaires à l'installation. Il sera basé sur les observations et explications faites ici.

IV - Note de la rédaction Developpez.com

Developpez.com remercie PlanetHoster pour l'autorisation de publication de ce tutoriel. Nos remerciements également à Guillaume SIGUI pour la mise au gabarit, et Claude Leloup pour la relecture orthographique.

V - PlanetHoster

PlanetHoster offre des services d'accompagnement dans la mise en œuvre d'un cloud privé (private cloud). PlanetHoster peut vous assister pour la planification, l'ingénierie, l'architecture, le choix des équipements et la mise en place d'un cloud privé dans la localisation géographique de votre choix. L'équipe de PlanetHoster a développé une expertise et des ententes exclusives au cours des dix dernières années. À titre d'exemple, il est possible de planifier un budget et de commander le matériel physique auprès de PlanetHoster. Par la suite, l'équipe de PlanetHoster s'occupera de mettre en place l'infrastructure pour vous. Un service de maintenance/infogérance est également offert. Il s'agit d'une solution clé en main disponible dès maintenant. Pour en savoir plus, vous pouvez contacter PlanetHoster.

PlanetHoster propose également des solutions de cloud hybride.