Version actuelle datée du 25 juin 2021 à 13:24

Sommaire

1 Présentation générale
- 1.1 Objectifs
- 1.2 Description
2 Préparation du projet
- 2.1 Choix techniques : matériel et logiciel
- 2.2 Liste des tâches à effectuer
3 Réalisation du Projet
4 Documents Rendus

Présentation générale

Nom du projet : Installation d'un orchestrateur de machines virtuelles
Stagiaire : Souleymane SOW
Encadrant : Xavier REDON
Durée : 6 semaines (17 Mai - 25 Juin 2021)

Objectifs

On aura à installer une infrastructure permettant à des utilisateurs de gérer un ensemble de machines virtuelles.

Description

Plusieurs composants sont nécessaires dans cet infrastructure :

un système de fichiers distribué ;
un système de virtualisation ;
l'orchestrateur des machines virtuelles;

Pour le système de fichiers on va regarder du coté de CEPH. Pour l'orchestrateur ProxMox semble incontournable. Le système de virtualisation peut être kvm ou Xen. Le démonstrateur aura à utiliser des disques sur au moins deux serveurs physiques et permettre de faire tourner des machines virtuelles sur au moins deux serveurs physiques. Les mécanismes de haute disponibilité et de migrations serons mis en place.

Préparation du projet

Choix techniques : matériel et logiciel

Logiciels:
- CEPH: Solution libre de stockage distribué (software-defined storage)
- Proxmox: Solution de virtualisation libre basée sur l'hyperviseur Linux KVM, et offrant aussi une solution de containers avec LXC
- KVM/Xen: Logiciel libre de virtualisation

Matériel:
- Serveur DELL PowerEdge R520
- Serveur DELL PowerEdge 2950

Liste des tâches à effectuer

Réalisation du Projet

Semaine 1

Mise en route du serveur Dell PowerEdge R520

Du à un probléme du capteur thermique, le serveur faisait beaucoup de bruit car les ventilateurs tournaient à fond dés qu'il est en service. Donc on a du trouver une solution afin de pallier à ce probléme. Afin de réduire le bruit c'est à dire réduire la ventilation dans le serveur, on a rajouté des résistances de 47 Ohms et de puissance d'1/2 W sur l'alimentation des ventilateurs. Aprés cela on a pu constater que la ventilation a été considérablement réduite donc on devait faire des tests afin de savoir si la ventilation était convenable pour refroidir assez le systéme en marche. Aprés avoir installé un nouveau Os (Devuan 3) sur notre serveur, on a effectué les configurations réseaux afin de permettre à notre serveur d'avoir accés au réseau de l'école et à Internet. On a installé lm-sensors qui est un logiciel libre pour les systèmes GNU/Linux fournissant des outils pour gérer la température, la tension, la vitesse des ventilateurs et l'humidité.Ensuite on a installé Stress permettant de charger à fond nos CPU afin de nous permettre de tester si la ventilation est suffisante. Aprés avoir stresser les CPU pendant 10 minutes, avec la commande sensors on a pu constater que la température augmentait jusqu'à atteindre une limite d'environ 53°C loin des 97°C de seuil critique.

"Modified Fans of PowerEdge R520"

Un second test a été effectué pour valider les modifications apportées en stressant les cpu pour une durée plus longue avec la commande: sudo stress --cpu 8 --timeout 7200.L'option --cpu 8 permet de générer 8 workers tournant sur la fonction sqrt (). L'option --timeout 7200 permet de spécifier la durée du stress, ici 7200 secondes soit 2 heures. Ensuite, on a mis en place un script shell permettant de monitorer la température de nos CPU chaque 10 minutes:

      #!/bin/bash
      stress --quiet --cpu  8 --timeout 7200 &
      echo "Processus de stress des CPU lancé"
      let "i=1";
      let "b=12";
      while (($i < $b)) ;
      do
         sensors
         sleep 600
         let "i=i+1"
      done

On observe que durant les deux heures, la température est monté jusqu'à atteindre un niveau de stabilité de 55°C au bout de 30 minutes. Ensuite elle tournait autour de ce seuil jusqu'à la fin du test. On peut affirmer ainsi que la solution mise en place afin de résoudre le probléme de ventilation du serveur PowerEdge R520 a été efficace car assurant un bon refroidissement des CPU mais aussi une grande réduction du bruit lors de sa mise en marche.

Installation de Devuan 3.0 sur nos serveurs

Sur chaque serveur, une distribution de Devuan y a été installé.

Sur notre R520, on dispose ainsi d'un disque de 1 To partitionné comme suit: 100 Go pour l'OS, 2 partitions de 250Go et une de 300Go. Pour la configuration réseau, elle dispose de l'addresse IP @:172.26.145.223.

Sur la PowerEdge 2950, on dispose de 2 disques de 300 Go et une de 70Go, l'OS a été installé sur ce dernier ayant ainsi deux disques disponible. Pour la configuration réseau, elle a comme adresse IP @172.26.145.224.

Semaine 2

Mise en place du systéme de fichiers distribué CEPH

Pour faire fonctionner Ceph, nous aurons besoin de :

le serveur d’administration du cluster nommé admin. Il permet d'effectuer les tâches d’administration de l'ensemble du cluster.
le serveur moniteur nommé mon qui permet de suivre l'activité de l'ensemble du cluster.
les serveurs de données nommés osdX qui stockent les objets

"Architecture CEPH à mettre en place "

On ajoute d'abord les différentes machines de l'architecture dans le fichier /etc/hosts:

   172.26.145.224  osd1
   172.26.145.224  osd2
   172.26.145.223  admin
   172.26.145.223  mon

Installation et configuration de CEPH: Pour installer CEPH, nous allons avoir besoin d’un utilisateur dédié. Il va donc falloir créer un utilisateur commun sur nos 2 serveurs de notre cluster:

Création de l’utilisateur ceph:

   useradd -d /home/ceph -m ceph
   passwd ceph (pasglop)
   echo "ceph ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/ceph
   (Donner le droit sudo sans mot de passe pour tous les logiciels de la machine pour l'utilisateur ceph)
   sudo chmod 0440 /etc/sudoers.d/ceph

Mise en place du ssh:

Pour s’installer, CEPH utilise le protocole SSH et nécessite une authentification par paire de clé. On va donc mettre en place une authentification par paire de clé entre notre serveur d’administration (admin) et les autres machines de notre cluster. Sur admin: on bascule sur le user ceph et on crée la paire de clef

   su - ceph
   ssh-keygen
   ssh-copy-id ceph@osd1 (On envoie la clé publique vers les autres machines de notre cluster)

Enfin pour finir la configuration du SSH du serveur d’administration, il faut créer un fichier config dans /home/ceph/.ssh

   Host osd1
   Hostname osd1
   User ceph
   Host osd2
   Hostname osd2
   User ceph
   Host mon
   Hostname mon
   User ceph

Configuration des dépôts:

On va maintenant configurer les dépôts de notre serveur d’administration pour pouvoir installer la dernière version de CEPH. Les opérations suivantes sont réalisées sur le serveur d’administration uniquement en utilisateur ceph. Mise en place des dépôts CEPH:

   wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -
   echo deb https://download.ceph.com/debian-luminous/ jessie main | sudo tee /etc/apt/sources.list.d/ceph.list
   sudo apt update
   sudo apt install ceph-deploy ntp

On installe ntp pour éviter les dérives d’horloge dans les moniteurs ceph.

Création du cluster ceph:

Nous allons maintenant installer Ceph sur chacune des machines pour en faire un cluster puis nous les spécialiserons une à une. Sur la machine d'administration (admin) et en tant qu'utilisateur ceph, il faut créer un dossier nommé test-ceph dans lequel les commandes ceph-deploy seront utilisées (ceph-deploy crée des fichiers localement là où il est exécuté):

   mkdir /home/ceph/test-ceph

Un cluster Ceph ne peut fonctionner sans moniteur, aussi nous devons commencer par indiquer quelle machine aura ce rôle futur. Pour ce faire, la commande suivante commence le déploiement d'un nouveau cluster en ajoutant une machine moniteur dans ce cluster. Elle crée également trois fichiers : un fichier de clefs, un fichier de log et un fichier de configuration.

    ceph-deploy new mon

Nous allons ensuite installer l'ensemble des programmes et librairies nécessaires à Ceph sur l’autre serveur. À la fin, nos 2 serveurs seront tous identiques et leur rôle leur sera attribué par la suite.

    ceph-deploy install admin mon osd1 osd2

Mais nous rencontrons l'erreur suivante lors de l'installation:

      [admin][ERROR ] RuntimeError: command returned non-zero exit status: 100
      [ceph_deploy][ERROR ] RuntimeError: Failed to execute command: env DEBIAN_FRONTEND=noninteractive DEBIAN_PRIORITY=critical apt-get --assume-yes -q --no-install-recommends install ceph ceph-osd ceph-mds ceph-mon radosgw

Mise en place du système de fichiers distribué CEPH (Suite)

Le problème rencontré précédemment lors de l'installation a pu être résolu en installant des paquets manquants : radosgw et gnupg1

Un autre problème lié à l'OS de nos serveurs est survenu lors de la spécification de la machine moniteur avec la commande :

     ceph-deploy mon create mon  ("mon" étant mon moniteur)

En effet Devuan est "systemd-free" donc ne peut exécuter les commandes systemctl or notre commande s’exécute avec. Pour résoudre ce problème, on doit trouver une procédure d'installation de CEPH avec sysv-init disponible sur Devuan.

Semaine 3

On a pas pu trouver une alternative d'installation de Ceph sans Systemd. Lors des recherches de solutions, il s'est trouvé que Proxmox était systemd dépendant donc ne pourrait etre installé sur nos deux serveurs. On a décidé de mettre en place des machines virtuelles et y installer un Debian 10 pour pouvoir mettre en place nos solutions.

Installation machine virtuelle

Installation des paquets requis

Pour vérifier que les microprocesseurs de nos machines permettent la virtualisation avec KVM on tape la commande suivante:

     grep -E 'vmx|svm' /proc/cpuinfo &>/dev/null && echo "La virtualisation est possible sur cette machine." || echo "Le microprocesseur de cette machine ne permet pas d'utiliser la virtualisation avec KVM."

On installer ensuite les paquetages qemu-kvm et libvirt-daemon

     apt-get install qemu-system libvirt-clients libvirt-daemon-system virtinst

QEMU est un logiciel libre de machine virtuelle, pouvant émuler un processeur et, plus généralement, une architecture différente si besoin. Il permet d'exécuter un ou plusieurs systèmes d'exploitation via les hyperviseurs KVM et Xen, ou seulement des binaires, dans l'environnement d'un système d'exploitation déjà installé sur la machine.
libvirt est une bibliothèque, une API, un daemon et des outils en logiciel libre de gestion de la virtualisation. Elle est notamment utilisée par KVM, Xen, VMware ESX, QEMU et d'autres solutions de virtualisation. Elle est notamment utilisée par la couche d'orchestration des hyperviseurs.

Ensuite on utilise la commande adduser pour ajouter notre nom d'utilisateur aux groupes kvm et libvirt:

     adduser pifou kvm & adduser pifou libvirt

Installation de notre VM Proxmox

Avant de lancer l'installation, il nous faut au préalable avoir notre fichier d'installation sur notre machine avant de lancer la commande d'installation suivante:

     virt-install --name proxmox --ram 4096 --disk path=/var/lib/libvirt/images/proxmox.img,size=20 --vcpus 2 --os-type linux --os-variant debian10 --network network=default --graphics none --console pty,target_type=serial --location /var/lib/libvirt/boot/debian-10.9.0-amd64-netinst.iso --extra-args 'console=ttyS0,115200n8 serial'

--name: Nom de la machine
--ram: spécifie la quantité de mémoire qu'utilise la machine virtuelle en mégaoctets
--disk path: montre le chemin d'accès au disque virtuel qui peut être un fichier, une partition ou un volume logique. Dans cet exemple, un fichier nommé proxmox.img dans le répertoire /var/lib/libvirt/images/, avec une taille de 20 gigaoctets
--location: Fichier à utiliser comme CDROM d’installation virtuel
--os-type: Optimise la configuration pour un type de système d'exploitation (Linux/windows)
--os-variant: Optimise davantage la configuration pour une variante de système d'exploitation spécifique(Debian 10/ Ubuntu 20)
--vcpus: Nombre de processeurs virtuels à configurer pour notre vm
--network: Connectez la vm au réseau de la machine hôte

A la fin de l'installation on pourra gérer notre machine avec les commandes suivantes:

Lister les machines virtuelles

     virsh list --all

Puis, pour démarrer, arrêter ou encore redémarrer une machine, nous pourrons utiliser les commandes suivantes :

     virsh start proxmox
     virsh shutdown proxmox
     virsh reboot proxmox

Se connecter à la console de notre VM

     virsh console proxmox

D’autre part, pour forcer l’arrêt de notre VM :

     virsh destroy proxmox

Mise en place de Proxmox

Dans cette partie on va décrire les étapes pour l'installation de Proxmox sur un systéme Debian 10

Ajout d’une entrée dans /etc/hosts pour notre @ip:

Le nom d’hôte de notre machine doit pouvoir être résolu avant de commencer l'installation de Proxmox sur notre Debian

      127.0.0.1       localhost.localdomain localhost
      192.168.122.10   proxmox1.plil.info proxmox1

On teste notre configuration avec la commande hostname --ip-address qui nous renvoie notre adresse IP si tout est ok!

Ajout du répos Proxmox

On ajoute le répos:

       echo "deb http://download.proxmox.com/debian/pve buster pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list

Et sa clé :

       wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

On la rend executable :

       chmod +r /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg

On met à jour nos dépôts:

       sudo apt update && sudo apt full-upgrade

Installation des packages de Proxmox VE

Pour commencer l'installation on lance :

       apt install proxmox-ve postfix open-iscsi

A la fin de l'installation, le système reboot, et démarre automatiquement sur le kernel Proxmox. Pour accéder à la page d'administration de notre Proxmox à partir du navigateur d'une machine de TP de la salle, on va mettre en place un Reverse Proxy au niveau de nos serveurs pour faciliter l'administration. On rappelle que l'interface d'aministration de Proxmox est disponible à l'adresse IP de la machine hote (notre VM) dans le port 8006.

Mise en place d’un Reverse Proxy Apache pour l'accès à l'interface de gestion de Proxmox

Le reverse proxy sera une passerelle permettant aux hôtes appartenant au réseau 172.26.145.0/24 d’accéder au réseau virtuel interne de nos serveurs Cordouan 192.168.122.0/24 et Container 192.168.123.0/24. Il nous faudra spécifier à notre machine d'administration appartenant au réseau 172.26.145.0 la route lui permettant d'accéder au réseau virtuel de nos Vms grace à la commande ip route add.

Installation Apache:

Dans un premier temps il nous faut installer Apache2:

      apt-get install apache2

Activation des modules utilisés:

Pour utiliser Apache en mode proxy inverse, il nous faut activer les 2 modules proxy et proxy_http via la commande a2enmod et les modules ssl pour une connexion sécurisée https

      a2enmod ssl proxy rewrite proxy_connect proxy_http

Le module proxy permet l’implémentation d’un serveur mandataire / passerelle et le module proxy_http apporte le support des requêtes HTTP et HTTPS au module proxy. Pour activer ces services, il est nécessaire de redémarrer apache.

      service apache2 restart

Mise en place du Virtualhost:

La configuration suivante correspond

      vi /etc/apache2/sites-available/proxmox.polytech-lille.fr.conf

      <IfModule mod_ssl.c>
            <VirtualHost *:443>
                 ServerName proxmox.polytech-lille.fr
                 ProxyPreserveHost On
                 ProxyRequests Off
                 ProxyErrorOverride Off
                 ProxyPass        / https://192.168.122.10:8006/
                 ProxyPassReverse    / https://192.168.122.10:8006/===Mise en place d’un Reverse Proxy Apache pour l'accès à l'interface de gestion de Proxmox===
                 SSLEngine on
                 SSLCertificateFile    /etc/ssl/server.crt
                 SSLCertificateKeyFile    /etc/ssl/server.key
                 SSLProxyEngine On
                 SSLProxyCheckPeerCN off
                 SSLProxyCheckPeerName off
                 SSLProxyCheckPeerExpire off
                 SSLProxyVerify none
            </VirtualHost>
       </IfModule>

ServerName permet de spécifier le nom de domaine voulu;ProxyPass et ProxyPassReverse donnent la correspondance entre le path voulu et l’adresse du serveur destinataire et ajustent l’URL dans les en-têtes HTTP. ProxyRequests permet d’activer et de désactiver la fonctionnalité de serveur mandataire. Pour la configuration du SSL, il nous faut créer une certificat SSL.

Création d’un certificat SSL:

Prérequis: Installation du paquet openssl:

       apt-get install openssl

Création de la clef: On se place au niveau du répertoire /etc/ssl/ avant de créer la clef:

       sudo openssl genrsa -out server.key 2048

Cette commande va créer la clé privée avec l'algorithme RSA 2048 bits. Demande de signature du certificat:Ensuite il faut générer un fichier de « demande de signature de certificat », en anglais CSR : Certificate Signing Request

       sudo openssl req -new -key server.key -out server.csr

On répond à un certain nombre de questions. On veille surtout à mettre le nom du serveur tel qu'il est appelé de l'extérieur dans le champ « Common Name » ( ici : "proxmox.polytech-lille.fr"). Pour visualiser le contenu du fichier généré:

       sudo openssl req -text -noout -in server.csr

Signature du certificat:Enfin, on génére le certificat signé au format x509: (certificat autosigné pour 365 jours)

       sudo openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Installation du certificat:

       cp /etc/ssl/server.crt /etc/ssl/certs/
       cp /etc/ssl/server.key /etc/ssl/private/

Maintenant que notre certificat SSL est généré et notre fichier de configuration virtualhost défini ,nous devons l’activer puis recharger Apache

       a2ensite proxmox.polytech-lille.fr.conf
       service apache2 reload

On met aussi en place une masquerade sur nos 2 serveurs pour permettre à nos VMs d'accéder au réseau externe en utilisant l'adresse IP de leur serveur hote sur le réseau 172.26.145.0/24.

       iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.168.122.10/32 (Sur Cordouan)
       iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.168.123.10/32 (Sur Container)

Pour tester si notre configuration fonctionne à partir d'un navigateur de notre machne d'administration, aprés avoir désactivé les proxy pour les réseaux de nos machines proxmox et rajouté le nom de nos hotes dans le fichier /etc/hosts comme suit:

       172.26.145.223 cordouan proxmox.polytech-lille.fr===Mise en place d’un Reverse Proxy Apache pour l'accès à l'interface de gestion de Proxmox===
       172.26.145.224 container proxmox2.polytech-lille.fr

On arrive à accéder aux interfaces d'administration de nos proxmox via les adresses proxmox.polytech-lille.fr et proxmox2.polytech-lille.fr.

"Interface de gestion de Proxmox "

Mise en place de notre cluster Proxmox

On va mettre en place un cluster de 2 noeuds:

Cordouan----> Name: proxmox1
@IP: 172.26.145.223
Container----> Name: proxmox2
@IP: 172.26.145.224

Vu que nos proxmox sont installés sur des machines virtuelles qui n'ont pas accés à l'espace de stockage des serveurs hotes, on doit rajouter de l'espace de stockage sur nos Vms. Pour cela on va utiliser la commande:

Sur Cordouan:
      virsh attach-disk proxmox1 /dev/sda3 vdb 
Sur Container:
      virsh attach-disk proxmox2 /dev/sdb vdb
      virsh attach-disk proxmox2 /dev/sdc vdc

Création du cluster:On va créer le cluster sur Promox1

      pvecm create mycluster

Vérification du statut du cluster:

      pvecm status

"Statut du cluster"

Semaine 4

Adhésion au cluster de proxmox2:On va demander à proxmox2 de rejoindre le cluster mycluster

      pvecm add 172.26.145.223

On peut vérifier sur l'interface d'administration de Proxmox si notre cluster a été crée et que nos noeuds ont été ajouté avec succés

"Notre cluster Proxmox"

Eviter la problématique du Quorum:Très important pour la suite nous allons effectuer une manipulation pour éviter de se retrouver avec un hyperviseur en "lecture seule" dans le cas ou le second noeud viendrait à rencontrer un problème (réseau, matériel ...). Afin de maintenir la synchronisation entre les nœuds, une exigence Proxmox est qu'au moins trois nœuds doivent être ajoutés au cluster. Dans notre architecture cela n'est pas faisable. Dans les configurations à deux nœuds, ce qui se passe, c'est que les deux nœuds doivent toujours être opérationnels pour que toute modification, telle que le démarrage, l'arrêt ou la création de machines virtuelles et de conteneurs, soit effectuée. Afin de résoudre ce problème, nous pouvons utiliser un QDevice externe dont le seul but est de régler les votes pendant les périodes de panne de nœud. Ce QDevice ne sera pas un composant visible du cluster Proxmox et ne pourra pas y exécuter de machine virtuelle ou de conteneur.

On installe le paquet corsync-qdevice sur nos deux noeuds

         apt install corosync-qdevice

Ensuite sur notre machine d'administration qui va jouer le role du Qdevice on installe les paquets suivants:

         apt install corosync-qnetd corosync-qdevice

Enfin à partir d'un noeud, on joint notre Qdevice à notre cluster via la commande (@IP Qdevice:172.26.145.70)

         pvecm qdevice setup 172.26.145.70 -f

Pour vérifier si notre configuration a bien été pris en compte on regarde l'état de notre clustre via la commande pvecm status, on observe bien que le nombre de votes est passé de 2 à 3 et que notre Qdevice a rejoint le cluster.

"Notre cluster Proxmox avec 3 votes grace au Qdevice"

Mise en place d'une solution de stockage distribué avec Proxmox et Ceph

Ceph c'est quoi? Ceph est une plateforme libre de stockage distribuée. Les objectifs principaux de Ceph sont d’être complètement distribué sans point unique de défaillance, extensible jusqu’à l’exaoctet et librement disponible. Les données sont répliquées, permettant au système d’être tolérant aux pannes. Ceph fonctionne sur du matériel non spécialisé. Le système est conçu pour s'auto-réparer et automatiser au maximum ses tâches administratives afin de réduire les coûts d’exploitation.

Pour faire simple, Ceph nous permet d’utiliser les disques de plusieurs hôtes pour réaliser du stockage distribué, permettant par exemple de réaliser des migrations de machines virtuelles à chaud, ou encore d’éviter les pannes étant donné qu’il n’y aura pas de SPOF, c’est-à-dire de « Single Point of Failure », pas de point unique de défaillance. Dans le cas des VMs toujours, si nous les stockons sur notre cluster Ceph, celles-ci seront donc répliquées sur chacun des hôtes.

Installation de Ceph:Alternativement à l'assistant d'installation recommandé de Proxmox VE Ceph disponible dans l'interface Web, nous pouvons utiliser la commande suivante sur chaque nœud de notre cluster :

        pveceph install

Cela configure un référentiel de packages apt dans /etc/apt/sources.list.d/ceph.list et installe le logiciel requis.

Configuration initiale de Ceph:On exécute la commande suivante sur un des noeuds

        pveceph init --network 192.168.122.0/24
        pveceph init --network 192.168.123.0/24

Cela crée une configuration initiale dans /etc/pve/ceph.conf avec un réseau dédié pour Ceph. Ce fichier est automatiquement distribué à tous les nœuds Proxmox VE de notre cluster, à l'aide de pmxcfs. La commande crée également un lien symbolique dans /etc/ceph/ceph.conf, qui pointe vers ce fichier. Ainsi, nous pouvons simplement exécuter les commandes Ceph sans avoir besoin de spécifier un fichier de configuration.

Ceph monitor:Le moniteur Ceph conserve une copie principale de la carte de cluster. Un minimum de trois monitor nodes est recommandé pour garantir la fiabilité. Mais dans notre architecture, on a que 2 noeuds disponibles dans notre cluster.

Création de moniteurs: Sur chaque nœud où l'on souhaite placer un moniteur, on exécute :

        pveceph mon create

Suppression de moniteurs: Pour supprimer un moniteur Ceph, on se connecte d'abord au nœud sur lequel le MON est en cours d'exécution. Ensuite on exécute la commande suivante

        pveceph mon destroy

Ceph manager: Ces nodes gèrent l’état de l’utilisation de la mémoire, de la charge du système et de l’exploitation des nodes.

Création de manager:

        pveceph mgr create

Suppression de manager:

        pveceph mgr destroy

Ceph OSDs:Physiquement, les données sont stockées sur des disques ou SSD formatés avec un système de fichiers comme ext et que Ceph baptise Ceph OSD (Ceph Object Storage Device). À chaque OSD correspond un démon chargé de stocker les données, de les répliquer ou de les redistribuer en cas de défaillance d’un équipement. Chaque démon OSD fournit aussi des informations de monitoring et de santé aux moniteurs Ceph. Un cluster Ceph doit à minima disposer de deux démons OSD (3 sont recommandés) pour démarrer.Il est recommandé d'utiliser un OSD par disque physique.

Création d'OSD: Sur chaque noeud ou on veut créer un OSD on éxécute la commande suivante en spécifiant le disque à utiliser comme OSD(sdb et sdc pour le proxmox2 et vdb pour le proxmox1)

        pveceph osd create /dev/sdb

Suppression d'OSD:

        ceph osd out <ID>
        systemctl stop ceph-osd@<ID>.service

La première commande indique à Ceph de ne pas inclure l'OSD dans la distribution des données. La deuxième commande arrête le service OSD. Jusqu'à ce moment, aucune donnée n'est perdue.

"OSDs de notre cluster Ceph"

Ceph Pool:Un cluster Ceph stocke les données sous forme d’objets stockés dans des partitions logiques baptisées “pools”. À chaque pool Ceph correspond un ensemble de propriétés définissant les règles de réplications (le nombre de copie pour chaque donnée inscrite) ou le nombre de groupes de placement (placement groups) dans le pool. Les pools peuvent être répliqués ou protégés par l’utilisation de code à effacement (erasure coding). Dans un pool répliqué, le système stocke autant de copies que spécifié de chaque donnée (le coût de stockage augmente linéairement avec le nombre de copies spécifié). Par exemple, si l’on a spécifié trois copies et que le cluster dispose de trois nœuds, la triple réplication permet de survivre à deux pannes de nœuds ou à la panne de deux disques. Lorsqu'aucune option n'est donnée, nous définissons une valeur par défaut de 128 PG, une taille de 3 répliques et une taille_min de 2 répliques, pour garantir qu'aucune perte de données ne se produise en cas d'échec d'un OSD.

Création du pool: Sur un des noeuds de notre cluster on tape la commande suivante pour créér notre pool nommé ceph-pool

         pveceph pool create ceph-pool --add_storages

Suppression du pool:

         pveceph pool destroy ceph-pool

PG autoscaler: L'autoscaler PG permet au cluster de prendre en compte la quantité de données (attendues) stockées dans chaque pool et de choisir automatiquement les valeurs pg_num appropriées. Il est disponible depuis Ceph Nautilus.On va l'activer via la commande:

         ceph mgr module enable pg_autoscaler

"Pool de stockage mis en place"

Création des machines virtuelles

Sur le menu de l'interface de gestion d'un des noeuds du cluster Proxmox, on clique sur Create VM. Ensuite on suit les étapes en spécifiant les caractéristiques de notre VM et à choisir le fichier d'installation. On obtient ainsi la configuration suivante:

"Menu aprés la création d'un VM"

On appuie ensuite sur le bouton Start pour démarrer la machine puis sur Console pour accéder à la console d'installation de notre VM.

Semaine 5

On s'est rendu compte que notre architecture avait des limites pour gérer des machines virtuelles. L'installation d'un nouveau systéme sur une VM nous a pris plus d'une heure. Aprés des tests réseau et d'écritures/lectures sur les disques on s'est rendu compte que le souci ne venait pas de là mais plutot du fait d'installer des machines virtuelles sur une machine virtuelle car le noeud principal de notre cluster a été installé sur une machine virtuelle dans Cordouan. Pour résoudre le probléme, on va installer notre noeud directement sur Cordouan et auparavant on va devoir supprimer le cluster déja mis en place afin de pouvoir rajouter les autres noeuds dans le prochain cluster qui sera mis en place.

Démonter notre cluster Proxmox

Tout d'abord, on arrête les services corosync et pve-cluster sur le nœud :

       systemctl stop pve-cluster
       systemctl stop corosync

On redémarre le système de fichiers du cluster en mode local :

       pmxcfs -l

On supprime les fichiers de configuration de corosync :

       rm /etc/pve/corosync.conf
       rm -r /etc/corosync/*

Nous pouvons maintenant redémarrer le système de fichiers en tant que service normal en quittant le mode local :

       killall pmxcfs
       systemctl start pve-cluster

Le nœud est maintenant séparé du cluster. Nous pouvons le supprimer à partir du nœud restant du cluster avec :

       pvecm delnode proxmox2

Nous revenons maintenant au nœud séparé pour supprimer tous les fichiers restants de l'ancien cluster. Cela garantit que le nœud pourra être ajouté à nouveau à un autre cluster sans problème.

       rm /var/lib/corosync/*

Mise en place de la nouvelle architecture

On va mettre en place l'infrastructure décrite sur la figure suivante:

"Nouvelle architecture à mettre en place"

On va installer sur nos deux serveurs directement un systéme Debian qui utilise systemd afin de pouvoir mettre en place un cluster Proxmox optimal. Comme réalisé précedemment, la machine d'administration(Zabeth20) jouera le role du 3eme noeud en tant que Qdevice. Un disue de 1To a pu etre rajouté sur le serveur Cordouan(Proxmox1) pour pouvoir avoir à disposition 3 OSDs qui est le minimum requis pour un cluster Ceph.

Le corosync-qdevice est un démon s'exécutant sur chaque nœud d'un cluster. Il fournit un nombre configuré de votes au sous-système de quorum en fonction de la décision d'un arbitre tiers. Son utilisation principale est de permettre à un cluster de supporter plus de défaillances de nœuds que ne le permettent les règles de quorum standard. Il est recommandé pour les clusters avec un nombre pair de nœuds et fortement recommandé pour les clusters à 2 nœuds comme dans notre cas.

On va ensuite paramétrer le réseau selon l'architecture, sur nos deux serveurs on mettra en place un pont virtuel vmbr0 pour connecter nos machines virtuelles au réseau.

 #Configuration réseau de Proxmox2 pour mettre en place un bridge pour les Vms
 auto eno1
 iface eno1 inet manual
 auto vmbr0
 iface vmbr0 inet static
       address 172.26.145.224/24
       gateway 172.26.145.254
       bridge-ports eno1
       bridge-stp off
       bridge-fd 0

On suit les étapes décrites précédemment afin d'installer les paquets requis, mettre en place le cluster Proxmox et enfin la mise en place du systéme de stockage distribué grace à Ceph. Nous avons à disposition 3 OSDs, donc on peut mettre en place une régle de réplication pour éviter de perdre nos données en cas de disfonctionnement d'un disque.

Aprés avoir fini la mise en place de notre pool de stockage Ceph avec une régle de réplication de 3, c'est à dire si on installe un VM sur l'un des noeuds le stockage de cette VM sera répliquée 3 fois pour assurer une disponibilité de ses données en cas de panne d'un disque ou meme d'un noeud; on commence l'installation de nos machines virtuelles.

Lors de la création d'une machine virtuelle sur le noeud Proxmox2(Container) on a eu un message d'erreur comme quoi la machine ne supportait pas la virtualisation KVM ou qu'il était désactivé au niveau du BIOS. On a du tester si le serveur pouvait faire de la virtualisation en installant le paquet cpu-checker et grace à la commande kvm-ok. On a pu avoir la confirmation que le serveur était compatible à la virtualisation KVM mais qu'il fallait l'activer au niveau du BIOS ce qu'on a fait avant de pouvoir passer à l'installation de la machine virtuelle.

On constate une nette amélioration de l'infrastructure, car la durée totale d'installation d'un systéme sur une machine virtuelle est de 20 minutes environ loin des 110 minutes sur l'architecture précédente. On peut ainsi pouvoir paramétrer nos Vms pour les mettre en utilisation.

"Machines Virtuelles disponibles dans le cluster"

Nos machines virtuelles utiliseront le bridge mis en place sur le noeud ou ils sont installé pour leur accés au réseau. Ensuite dans leur fichier /etc/network/interfaces on configure leur interface ens18 selon l'architecture défini au dessus, ils ont des addresses appartenant au réseau externe et grace au bridge mis en place ils pourront avoir accés à Internet, pouvoir communiquer entre elles et le reste du réseau. Il ne faut pas oublier de redémarrer l'interface avec ifdown et ifup pour que la machine prenne en compte les modifications du fichier de configuration. Ensuite pour tester les configurations on effectue des pings sur l'ensembles des machines du réseau pour voir si on obtient des réponses.

"Test des configurations réseau"

On a pu communiquer avec l'ensemble des machines du cluster et se connecter à Internet aussi.

Installation d'une interface graphique sur une machine virtuelle:

Pour installer une interface graphique sur une machine virtuelle, on a 3 options de paquets: Gnome, KDE et LXDE. On choisit d'installer la version minimale de gnome sans aucune application installée avant de rebooter la machine pour qu'elle puisse lancer l'interface graphique:

          apt-get install gnome-core
          reboot

"Interface graphique installée sur une machine virtuelle"

Migration de machine virtuelle:

En virtualisation, la migration de machines virtuelles consiste à déplacer l'état d'une machine virtuelle, d'un hôte physique à un autre. Il existe plusieurs raisons pour lesquelles il est nécessaire de migrer des systèmes d'exploitation, la plus importante étant l'équilibrage de la charge de travail sur les serveurs physiques. Il est également nécessaire de migrer des machines virtuelles lorsqu'un hôte physique est défectueux ou nécessite une maintenance.

On va essayer de migrer une machine virtuelle (VM5) de notre cluster Proxmox d'un noeud à un autre.

"Migration de VM5 de Proxmox1 à Proxmox2"

Il suffit d'aller dans le menu de gestion de notre VM et cliquer sur l'onglet Migrate on obtient le menu suivant ou on choisit le noeud de destination de notre machine virtuelle:

"Menu de paramétrage de la migration"

On valide ensuite et on attend que la migration se termine. Si tout se passe bien notre machine virtuelle se retrouve dans le noeud de destination.

"VM5 dans le noeud Proxmox2"

Installation de machines virtuelles avec Xen pour comparer les performances:

Xen est un logiciel de (para)virtualisation de type hyperviseur. Il permet donc de faire tourner plusieurs systèmes d'exploitation (OS) sur une même ressource matérielle (PC, Serveur,…). Pour créer une machine virtuelle avec les memes caractéristiques que celles de notre cluster Proxmox, il suffit de lancer la commande suivante:

        xen-create-image --hostname=proxmox --lvm=virtual --dist=buster --boot --memory=4096Mb --fs=ext4 --vcpus=4 --bridge=ima5SC --nameserver="193.48.57.48” --swap=1Gb --size=30G

Le temps d'installation totale du systéme sur la machine virtuelle Xen est de 5 minutes. On constate une grande différence de temps entre nos deux installations qui peut s'expliquer d'une part par le type de stockage distribué Ceph de notre machine virtuelle du cluster Proxmox. Mais cela ne suffirait pour justifier cette différence. On croit plutot que celle viendrait du fait d'avoir choisi de mettre le traffic réseau et le traffic des données de stockage sur le meme réseau car lors de l'installation des paquets de Debian sur la machine virtuelle, le second noeud Proxmox2 de notre cluster devient injoignable dans le réseau momentanément ce qui provoque la perte du corosync et le blocage des données le temps d'indisponibilité du second noeud.

On va essayer de mettre en place une nouvelle architecture en séparant le réseau de transit du corosync et celle du traffic des données de stockage.

Semaine 6

Test de la nouvelle architecture

On va mettre en place l'infrastructure décrite sur la figure suivante. La différence entre cette architecture et la derniere est la séparation du réseau de traffic des données de stockage et celui du traffic du Corosync.

"Séparation du traffic Corosync et celui des données de stockage"

Pour mettre en place cette architecture, il a fallu modifier les paramétres Ceph du cluster dans /etc/pve/ceph.conf et remplacer l'ancien réseau par la nouvelle 192.168.1.0/24. Ce réseau a été paramétré sur les autres interfaces réseaux disponibles au niveau de nos deux serveurs à savoir l'interface eno2 suivant l'architecture choisie.

On va maintenant installer une machine virtuelle pour tester les performances de la nouvelle architecture. On constate que le temps d'installation total d'une nouvelle machine virtuelle est d'environ 12 minutes. Donc on a réussi à améliorer les performances de notre cluster et à trouver la principale cause de l'instabilité du cluster précédent. En effet, depuis la séparation des deux traffics du corosync et des données de stockage, le second noeud n'a jamais été injoignabe ce qui garantit une infrastructure toujours disponible et une meilleure performance sur l'utilisation du stockage distribué.

Néanmoins, Xen propose la meilleure performance en termes de rapidité d'installation et cette différence s'explique particuliérement par le systéme de stockage distribué utilisé dans notre cluster Proxmox. Contrairement au Xen qui stocke les données de la machine virtuelle sur l'espace de stockage local de la machine hote, notre cluster Proxmox stocke quant à lui, l'ensemble des données des machines virtuelles crées dans le pool de stockage Ceph qui est partagé sur 2 noeuds séparés par un réseau et qui sera dupliqué pour garantir la disponibilité des données en cas de panne d'un noeud. En plus de cela, le temps d'écriture et de lecture de ces données dépend fortement du réseau par ou passe le traffic des données de stockage.

Clonage de machines virtuelles

Pour pouvoir déployer plusieurs machines virtuelles facilement et rapidement, on peut réaliser sur Proxmox le clonage de VM. En effet il suffit d'installer une nouvelle machine virtuelle qui va servir de référence, ensuite cette machine sera converti en template via l'interface de gestion du Proxmox et le menu de gestion des VMs avec l'onglet Convert to template. Cette machine sera automatiquement transformé en template ensuite on pourra effectuer des clonages de VM à partir du meme menu de gestion avec l'onglet Clone. On constate que la durée totale pour un clonage de VM ne dépasse pas une minute ce qui est trés loin du temps d'installation d'une nouvelle machine virtuelle.Donc cette solution de clonage de machine virtuelle garantit une grande rapidité pour mettre en place un pool de VMs.

"Clonage d'une machine virtuelle"

Documents Rendus

Media:Rapport_ProjetSouleymaneSow.pdf

Media:presentation_SSow.pdf

IMA3/IMA4 2019/2021 P3+ : Différence entre versions