INTRODUCTION À LA CONFIGURATION D'OPENSTACK SUR PLANETHOSTER

Deuxième partie : Installation d'OpenStack : Préparation des nœuds

Jean-Philippe Méthot

Dans la première partie de cette série de tutoriels, nous avons établi différents critères à prendre en compte avant de débuter l'installation d'Openstack. Cette fois-ci, nous couvrirons les différents éléments à configurer et installer sur les différents serveurs avant d'installer les packages Openstack. La configuration physique sera de trois nœuds, un contrôleur et deux computes, reliés à un cluster de stockage CEPH. Les deux nœuds compute posséderont trois interfaces réseau alors que le contrôleur en possédera quatre. Nous utiliserons deux switchs (ou vlan, c'est à votre discrétion) pour les réseaux locaux de stockage et de communication interne, alors que nous brancherons deux ports du contrôleur et un port par compute directement sur le routeur, pour le réseau d'administration et le réseau sortant d'Openstack.

Un espace de discussion vous est proposé sur le forum. N'hésitez pas à apporter votre avis.

Commentez

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

- Auteur : Jean-Philippe Méthot

- Parution : 15 avril 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 PlanetHoster. 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. Configuration réseau

- II. Autres configurations à faire dans CentOS

- III. Composantes non Openstack à installer et configurer

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

I - Configuration réseau

Nous avons présentement quatre réseaux d'identifiés : un réseau d'administration routable vers l'internet, un réseau local de stockage, un réseau local de communication pour les machines virtuelles et un réseau sortant. Notre réseau d'administration est notre point d'accès vers chacun des nœuds ainsi que leur API. C'est aussi le point d'accès de chaque nœud vers l'internet et leur lien d'intercommunication principal. La majorité des communications entre les différents services se font sur ce réseau. C'est aussi par cette interface que nous procéderons à l'installation des packages, ainsi que toute tâche nécessitant un accès SSH ou HTTP aux serveurs. Si ce réseau tombe, les nœuds deviendront inaccessibles, mais les machines virtuelles continueront d'être joignables.

Le réseau de stockage doit relier tous nos nœuds avec le cluster CEPH. C'est par là que nos machines virtuelles vont se connecter à leurs disques virtuels. C'est aussi par ce réseau que le contrôleur va envoyer ces commandes à CEPH pour qu'il puisse créer les disques virtuels. La vitesse de ce réseau est directement liée à la vitesse de stockage des VM. Plus son débit est haut, plus le stockage sera rapide, jusqu'à ce qu'on atteigne la vitesse maximale offerte par le CEPH. Si ce réseau cesse de fonctionner, plus aucune machine virtuelle ne pourra écrire sur son disque.

Le réseau local de communication des machines virtuelles est crucial afin de permettre à celles-ci de communiquer entre elles. Il s'agit d'un lien entre le contrôleur et les différents nœuds compute où le trafic est encapsulé dans des paquets GRE ou Vxlan. Cela permet aux VM qui sont sur des nœuds computes différents, mais dans le même réseau virtuel, de communiquer entre elles. Ceci dit, la majorité du trafic utilisant ce lien sera dirigé vers le contrôleur. Effectivement, ce réseau doit aussi relier les instances au nœud contrôleur, puisque dans notre infrastructure réseau, le contrôleur se veut la passerelle de chaque réseau virtuel vers l'internet. Ainsi, si ce réseau cesse de fonctionner, tout trafic menant vers les machines virtuelles cessera.

Le réseau externe, ou sortant, est le lien entre les machines virtuelles et l'Internet. Il relie le contrôleur au routeur et est dédié aux machines virtuelles. Tout le trafic encapsulé circulant dans le réseau local et dirigé vers l'externe, désencapsulé sur le serveur et envoyé vers sa destination finale. Il est ici important d'avoir un bon débit sur ce lien puisque toutes les connexions vers toutes les machines virtuelles, provenant de et allant vers l'externe, passeront par ce lien.

Je suggère fortement d'utiliser des sous-réseaux IP séparés pour chacun de ces réseaux. Il serait aussi préférable que chaque port ait une configuration réseau statique afin de s'assurer que les IP ne changent jamais. Une fois les configurations des ports faites, nous pourrons passer à l'étape suivante : configurer les autres paramètres du système d'exploitation.

II - Autres configurations à faire dans CentOS

Certaines configurations doivent être faites sur tous les nœuds avant de continuer. On doit premièrement donner un nom d'hôte à chacun des serveurs.

hostnamectl -set-hostname x.planethoster.com

Ensuite, nous allons vouloir que chaque serveur puisse résoudre les autres serveurs par leur nom d'hôte. Vous pouvez soit configurer un service DNS, soit éditer les fichiers hosts de vos serveurs pour qu'ils aient les bons noms avec les bonnes IP. Sous CentOS7, le fichier d'hosts se trouve dans /etc/.

vi /etc/hosts

Par la suite, vous devrez soit désactiver selinux, soit le mettre en mode permissif. Bien que plusieurs modules d'Openstack puissent fonctionner avec selinux, le désactiver peut éviter bien des problèmes lors des opérations quotidiennes. Aussi, il faut que tous les nœuds compute aient la même configuration selinux, car sinon, les migrations de machines virtuelles entre compute pourraient échouer. Ainsi, si on désactive, il faut désactiver partout ; si on le rend permissif, il faut aussi le rendre permissif partout.

setenforce 0
sed -i 's/enforcing/disabled/g' /etc/selinux/config /etc/selinux/config

Ensuite, nous ajouterons les dépôts de package d'Openstack pour Yum. Ici il s'agit des packages de la révision Pike. À noter qu'Openstack Queen's vient d'être annoncé comme étant stable, donc vous pouvez aussi utiliser ces packages à la place, question d'être à la version la plus récente.

yum install centos-release-openstack-pike

Pour terminer cette étape, nous recommandons de faire une mise à jour des packages du serveur à l'aide de yum.

yum update

III - Composantes non Openstack à installer et configurer

Avant de commencer l'installation des services Openstack, il est capital d'installer et configurer certaines composantes qui seront nécessaires au déploiement des services. Pour stocker les données relatives aux instances et aux services, Openstack a besoin d'une base de données. Nous utiliserons MariaDB, considérant qu'il s'agit du type de base de données recommandé par Red Hat. Elle sera installée uniquement sur le nœud contrôleur. L'installation de MariaDB se fait rapidement sous CentOS, grâce à yum :

yum install mariadb

On exécute ensuite le script qui sécurise MariaDB :

mysql_secure_installation

Je vous suggère d'enlever les utilisateurs anonymes, de désactiver le login en root de l'externe et d'effacer la base de données de test. Cela aidera à assurer la sécurité des bases de données d'Openstack.

Une fois MariaDB installé, vous devrez installer Rabbitmq sur votre nœud contrôleur. Rabbitmq est un service de messagerie interservice qui assure la communication entre les services. À ne pas confondre avec un système de messagerie s'adressant aux humains, comme Skype, Rabbitmq reçoit des messages provenant de certains services et les stocke jusqu'à ce que le service destinataire vienne les consulter. C'est de cette manière et par leurs API que les différentes composantes d'Openstack communiquent entre eux. Il s'agit donc d'une pièce maîtresse dans votre infrastructure.

L'installation de Rabbitmq est encore une fois, relativement simple. Vous n'avez qu'à installer le package par Yum.

yum install rabbitmq-server

De plus, il est important de noter que Rabbitmq ainsi que les services Openstack sont très sensibles aux différences d'heure. Il suffit que les horloges des différents nœuds ne soient désynchronisées que de quelques secondes pour que des messages se perdent entre les services. C'est pour cette raison qu'installer un programme s'assurant de la synchronisation du temps, comme NTP ou chrony, sur tous les nœuds, empêchera plusieurs problèmes liés à la désynchronisation de se produire. S'il n'est pas déjà installé sur vos serveurs, on peut installer ntpd encore une fois, avec l'aide de Yum.

yum install ntpd

Vous pouvez ensuite configurer ntpd comme vous le désirez.

Une fois que tous ces services sont installés, assurez-vous qu'ils seront disponibles au démarrage du serveur.

systemctl enable rabbitmq-server mysql ntpd  (sur le noeud contrôleur)
systemctl enable ntpd (sur les nœuds compute)

Une fois toutes ces installations et configurations terminées, les bases de votre système Openstack sont en place. Le mois prochain, nous verrons comment installer et configurer le premier service d'Openstack que nous mettrons en place : Keystone.

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.