Projet Tuteuré VIRT

Projet tuteuré VIRT

LO Alexandre, KEHRLI Loïc, TOMBOIS Thomas, COLIN Joeffrey Tuteur: PASCALE Fabien Année universitaire 2018/2019 Table des matières

1 Remerciement 3

2 Introduction 4 2.1 Sujet de notre soutenance ...... 4 2.2 Organisation ...... 4

3 Architecture 7 3.1 Architecture actuelle ...... 7 3.2 Architecture nale ...... 9 3.3 Virtualisation ...... 11 3.3.1 Principe de la Virtualisation ...... 12 3.3.2 Méthodes de virtualisation ...... 13 3.3.2.1 L'isolation ...... 13 3.3.2.2 Hypervision ...... 13 3.3.3 KVM ...... 13 3.3.3.1 QEMU ...... 14 3.3.4 Haute disponibilité ...... 15 3.3.4.1 Plan de reprise d'activité ...... 15 3.4 Stockage ...... 16 3.4.1 Principe du Stockage ...... 16 3.4.1.1 RAID ...... 16 3.4.1.2 Stockage distribué ...... 16 3.4.2 Diérentes solutions ...... 17 3.4.2.1 GlusterFS ...... 17 3.4.2.2 NFS ...... 18 3.4.2.3 BeeGFS ...... 19 3.4.2.4 Comparatif ...... 20 3.5 Clustering ...... 21 3.5.1 Principe du Clustering ...... 21 3.5.1.1 Quorum ...... 21 3.5.2 Diérentes solutions ...... 21 3.5.2.1 Proxmox VE ...... 21 3.5.2.2 Ganeti ...... 21 3.5.2.3 oVirt ...... 21 3.5.2.4 Comparatif ...... 22 3.6 Réseaux ...... 23

1 3.6.1 Comparatif ...... 23 3.7 Monitoring ...... 24 3.8 Ansible ...... 24

4 Outils utilisés 25 4.1 Planner ...... 25 4.2 VPN ...... 25 4.3 X2GO ...... 25 4.4 Vagrant ...... 25 4.5 Git ...... 26 4.6 LATEX...... 26 4.7 Google Drive ...... 26 4.8 Draw.io ...... 26

5 Problèmes rencontrés 27

6 Conclusion 28

7 Bibliographie 29

8 Annexes 31

2 Chapitre 1

Remerciement

Nous remercions notre tuteur, Fabien Pascale, Responsable HPC Systèmes et Réseaux, mésocentre EXPLOR, pour sa disponibilité, son suivi du projet sur la durée ainsi que pour l'environnement qu'il nous a fourni pour la mise en place du projet. Merci à Monsieur Lucas Nussbaum, Debian Project Leader (DPL), maître de confé- rences à l'Université de Lorraine et chercheur auprès du laboratoire LORIA, pour nous avoir donné l'envie d'aller plus loin dans l'univers du monde libre que ce soit lors de ses cours ou encore lors de conférences (libre sur la place). Un grand merci à Monsieur Philippe Dosch, enseignant et responsable de la licence,qui a su, quand il le fallait, nous écouter et nous donner les indications nous permettant de prendre la bonne direction.

3 Chapitre 2

Introduction

2.1 Sujet de notre soutenance

Un centre de calcul comporte un ensemble de ressources de calcul composé de n÷uds de calcul et un ensemble de machines de service qui sont pour la plupart des machines virtuelles. La mise en maintenance ou la panne d'un hôte de virtualisation constitue un point critique dans le fonctionnement du centre. An de supprimer ce SPOF, il est nécessaire de passer à une solution de cluster ( ici KVM avec les logiciels standards de HA) utilisant un stockage réseau. Diérents types de stockage devront être envisagés : HA-NFS, GlusterFS, BeeGFS via diérents types de réseau OPA, Ethernet. Pour cela on pourra évaluer les solutions et choisir la plus pertinente que ce soit sur le réseau, le stockage et la solution de clustering : Ethernet OPA NFS GlusterFS BeeGFS oVirt Ganeti Proxmox VE À la n du projet nous devrons disposer : De tableaux comparatifs des solutions envisagées, listant les avantages et les in- convénients des diérents stockages, réseaux et solutions de clustering. D'une maquette fonctionnelle proposant pour un type de stockage réseau retenu, ici GlusterFS, une solution de cluster KVM en haute disponibilité.

2.2 Organisation

Au début du projet, nous avons décidé de travailler ensemble sur le sujet an de se répartir les tâches. Nous nous sommes ensuite chacun attelé à nos parties respectives tel que le montre ce diagramme ci-contre.

4 Figure 2.1 Gantt

COLIN KEHRLI LO TOMBOIS Documentation X X X X KVM Installation et X X X X prise en main Virt Manager Documentation X X X GlusterFS Installation X X X X GlusterFS Documentation X X X BeeGFS Test BeeGFS X X Documentation X X X NFS Test NFS X X Documentation X X Proxmox VE Installation X X Proxmox VE Documentation X Ganeti

5 COLIN KEHRLI LO TOMBOIS Établir pré- X X X X requis maté- riels, réseau et logiciel Documentation X sur les sondes et monitoring Création et X X X X tests des maquettes Solution clus- X X X X tering de Prox- mox VE Mise en place X X du stockage GlusterFS Utilisation de X X VPN / x2go Écriture rap- X X X X port nal

6 Chapitre 3

Architecture

3.1 Architecture actuelle

Nous sommes dans un mésocentre de calcul utilisant nombres de ressources. Le centre possède de nombreux serveurs dédiés aux calculs ainsi que de nombreux serveurs de stockage. Le stockage du mésocentre est un RAID 6 composé de 10 disques ainsi que de 2 disques de secours (spare). Les hôtes sont rattachés à la baie de stockage à l'aide d'un direct attached .

Figure 3.1 Infrastructure actuelle

7 Figure 3.2 Schéma de l'infrastructure actuelle

L'architecture qui nous a été donné de modier ne possède pas de solution pouvant relancer une machine tombée sans qu'une personne quelconque ne doive se déplacer jusqu'à la machine pour la relancer manuellement. Le projet tuteuré nous amène à repenser l'infrastructure pour mettre en place une solution de clustering en haute disponibilité.

8 3.2 Architecture nale

Pour pallier la perte de disponibilité de service lorsqu'un serveur tombe ou est en maintenance, nous avons mis en place une architecture permettant d'inclure la haute disponibilité. Nous avons installé un serveur Proxmox sur 3 hôtes diérents, puis nous avons créé un cluster depuis l'interface graphique Proxmox. Nous avons créé un cluster sur pmx02 et pmx03 que nous avons liés entre-eux. La solution initiale ne comprenait pas de solution de clustering, il était donc dicile et long d'intervenir sur chaque n÷ud. Désormais ces derniers seront présents dans un même cluster Proxmox VE, ce qui améliorera l'ergonomie et permettra la mise en place de la haute disponibilité. L'infrastructure de stockage en Direct-Attached limite grandement les possibilités d'expansion de stockage. De plus il se dédie uniquement aux ressources d'un seul ordinateur ne pouvant être managé par le réseau. Lors d'une migration de machine, en cas de maintenance ou bien de panne de celle-ci, l'intervention d'un agent est nécessaire pour lier la nouvelle machine au stockage via le Direct-Attached, cela provoque une perte de temps et une indisponibilité considérable des applications. L'utilisation de GlusterFS permet un paramétrage ainsi qu'une conguration complète à distance du système de stockage. Celle de GlusterFS dupliqué en réplica 3 permet la perte d'un serveur car les données de celui-ci sont répliquées dans les autres serveurs. Les images stockées dans ces serveurs peuvent être utilisées au moment de la panne d'une machine par tous les serveurs de virtualisation et ainsi refaire fonctionner les applications ayant cessé de fonctionner.

Figure 3.3 Maquette initialement prévue

9 Figure 3.4 Schéma de l'infrastructure nale

10 Figure 3.5 Cluster visible sur Proxmox

3.3 Virtualisation

La virtualisation est une technique permettant de faire fonctionner simultanément et séparément plusieurs systèmes d'exploitation ou applications sur une même machine, chacun croyant fonctionner dans sa propre machine physique. L'intérêt immédiat semble faible : pourquoi faire tourner sur un même serveur plusieurs systèmes d'exploitation ? Ceux-ci se partageant les ressources de la machine que ce soit la mémoire les c÷urs processeur les entrées et sorties et le réseau. La première réexion est qu'une machine virtuelle est plus lente qu'un véritable serveur. Si ce n'est pas entièrement dénué de tout fondement, la réalité est bien souvent diérente. Il est souvent constaté qu'un serveur est rarement exploité au maximum de ses capacités, quand il l'est c'est généralement sur de courtes périodes et pour des tâches ponctuelles. Le reste du temps le serveur n'utilise pas toutes ses ressources, ce temps disponible peut être exploité sans pénaliser l'application en cours de fonctionnement. Un serveur fonctionnant à 10 % de ses capacités ne consomme pas beaucoup moins qu'un serveur exploité a 100 % de ses capacités. Si l'entreprise dispose de plusieurs di- zaines de serveurs de ce genre, le coût n'est pas négligeable même si les opérations de virtualisation consomment elles aussi des ressources, le bilan peut nir par pencher en faveur de la création de plusieurs machines virtuelles sur un serveur. Si de nombreux serveurs sont faiblement exploités ou si les pics de charge des applications ne coïncident pas forcement, alors la virtualisation est une solution à envisager.

11 3.3.1 Principe de la Virtualisation De nombreux critères interviennent dans la décision de virtualiser ou non, le principal reste économique. Économie nancière tout d'abord, puisque cela revient moins cher en coût d'achat et en maintenance matérielle. Économie de ressources ensuite par une meilleure répartition des machines virtuelles sur les serveurs an d'optimiser l'ensemble des performances. Et enn économie d'administration car il est plus simple d'installer, déployer et migrer des machines virtuelles, il est notamment possible via divers outils de transformer une machine physique en machine virtuelle et vice-versa, l'environnement matériel est généralement identique pour chaque machine virtuelle. Les intérêts ne sont pas qu'économiques et sont très nombreux : Une machine virtuelle est très utile lors des divers tests d'installation et de para- métrage. Tout peut être cassé, c'est sans importance puisque le système hôte de la machine physique reste intact. Une machine virtuelle peut être déployée facilement, dupliquée à volonté. Pour installer un nouveau serveur il peut sure de dupliquer une enveloppe de machine virtuelle et de modier son paramétrage. Des outils de supervision peuvent surveiller en temps réel l'état de l'ensemble des machines virtuelles d'un hôte donné, voire de plusieurs hôtes. Il y a une facilité de dimensionnement des ressources de la machine virtuelle. Si l'application consomme plus ou moins que prévu, il est possible de ré-allouer très facilement des ressources (temps CPU, mémoire...).

Figure 3.6 Avantage virtualisation

12 3.3.2 Méthodes de virtualisation 3.3.2.1 L'isolation L'isolation consiste à exécuter des applications dans un environnement isolé des autres, appelé contexte ou zone d'isolation. L'application n'est pas dans une véritable machine virtuelle, mais simplement isolée des autres par des possibilités du système d'exploitation. Par exemple chroot sur Unix : il permet de changer de racine Le principe de chroot est simple. Un répertoire Unix contient tout le nécessaire à l'exécution d'un programme, par exemple un serveur web. Ce nécessaire est aussi bien l'application et ses chiers de conguration que les bibliothèques et les commandes qu'elle utilise. Une fois tout en place, la commande chroot est appliquée à ce répertoire qui devient la nouvelle racine. Les processus du serveur ne voient que les données contenues dans cette nouvelle racine et ne peuvent en sortir.

3.3.2.2 Hypervision Un hyperviseur est un logiciel dont le but est de gérer l'architecture à destination des systèmes d'exploitation invités. C'est la méthode la plus performante actuellement, mais à part certaines solutions gratuites comme Xen ou KVM, elles restent chères. Les produits Xen, VMWare ESX ou encore Microsoft Hyper-V sont des hyperviseurs. Par abus de langage, on appelle souvent hyperviseur tout système hôte pouvant contrôler le fonctionnement des systèmes invités. Si un système d'exploitation invité sait qu'il est installé sur un hyperviseur, il peut être optimisé et augmenter les performances. Il s'agit soit d'un noyau particulier, soit de pilotes spéciques.

3.3.3 KVM KVM est un hyperviseur sous Linux. Il ne fonctionne que sur les processeurs avec les extensions Intel-VT ou AMD-V. Le module KVM est intégré dans les noyaux Linux depuis le 2.6.20. KVM permet de faire fonctionner de nombreux systèmes invités : toutes les versions de Windows à partir de Windows 2000 toutes les distributions Linux la plupart des versions de BSD Solaris et openSolaris Minix, Hurd, QNX MSDOS d'autres systèmes divers

13 KVM via QEMU propose un support matériel complet pour les systèmes invités : USB Ethernet PCI hotplug Carte son Virtio (périphérique disque para-virtualisé) Le gros avantage de KVM par rapport à XEN est qu'il ne nécessite pas de noyau particulier pour gérer les machines virtuelles tant pour l'hôte que les invités.

3.3.3.1 QEMU QEMU ou Quick Emulator est le composant principal de la technologie de virtualisation QEMU/KVM. Il fournit l'émulation du processeur ainsi que le hardware de la virtualisation. QEMU fonctionne dans l'espace utilisateur et, sans nécessité du noyau, les drivers peuvent toujours fournir un système d'émulation rapide. QEMU propose 2 modes d'opé- ration : Un système d'émulation complet où QEMU émule l'entièreté d'un système d'ordinateur, incluant le CPU ainsi que les périphériques. Un mode d'émulation utilisateur où QEMU peut lancer un processus qui a été compilé au préalable dans une architecture avec un CPU diérent.

14 3.3.4 Haute disponibilité Rares sont aujourd'hui les entreprises qui peuvent se passer de leur informatique à tel point que dans bien des cas l'inaptitude à faire face à un incident informatique peut leur être fatale. C'est la raison pour laquelle de plus en plus de sociétés, de toutes tailles s'attachent à mettre en place un plan de reprise d'activité ou un plan de continuité d'activité. Quelques chires : selon une étude du cabinet de conseil américain Eagle Rock, 40% des entreprises ayant subi un arrêt de 72 heures de leurs moyens informatiques et télécoms ne survivent pas à ce désastre. Le PCA (Plan de continuité d'activité) décrit l'ensemble des moyens destinés à assurer la continuité d'activité des applications, c'est-à-dire à ga- rantir la disponibilité continue de ces applications. La haute disponibilité permet, lors de sinistres mais aussi lors de maintenances d'avoir un service qui peut repartir dans les 10 minutes sans intervention humaine. Le PRA (Plan de reprise d'activité) quant à lui décrit l'ensemble des moyens et procédures destinés à assurer une reprise rapide et ordonnée de la production après un arrêt inopiné lié par exemple à une défaillance technique, ou énergétique, à une erreur humaine ou à un sinistre naturel. La diérence entre les deux approches tend donc à se limiter à une diérence en matière de temps d'indisponibilité de l'infrastructure et des services en cas de sinistre et de prix. En eet de nombreuses entreprises se limitent à un plan de reprise d'activité pour des question économiques du fait d'une diérence de prix très importante par rapport à un plan de continuité d'activité.

3.3.4.1 Plan de reprise d'activité Le PRA fait partie du PCA. Il dresse la marche à suivre en cas d'incident an de reprendre l'activité le plus vite possible. Lorsqu'une courte panne est envisageable, le PRA est adapté. Il implique de dénir le délai maximal d'interruption admissible et la perte maximale de données tolérable. Il permet notamment de basculer le service informatique de l'entreprise sur un système de relève. Dans notre cas, pour le projet, nous avons eu comme contrainte que le service doit repartir automatiquement sous 10 minutes. Une simple sauvegarde ne fait pas un bon PRA. On peut y prévoir : la présence de sites secours la redondance de données entre data centers les paramètres de redémarrage des applications, des machines virtuelles ou encore des machines physiques automatiquement

15 3.4 Stockage

3.4.1 Principe du Stockage Au sein des entreprises, le stockage a une importance majeure. Il permet de sauve- garder toutes les données numériques dont l'entreprise a besoin. Dans notre projet nous utilisons un stockage réseau an de disposer d'un support de stockage externe accessible par le réseau. C'est un point pouvant se révéler défaillant et devant être sécurisé via diérentes solutions. L'architecture actuelle possède un stockage en RAID 6.

3.4.1.1 RAID Le RAID 6, aussi connu en tant que RAID en double parité, utilise deux parités stripé sur tous les disques, cela permet la défaillance de deux disques avant la perte de données. Le RAID 6 est complexe car il doit calculer deux parités pour chaque block de données du RAID. Les défauts du RAID 6 sont un temps d'écriture très long à cause des calculs de redondance complexes ainsi que le temps de reconstruction en cas de défaillance simultanée de deux disques. Tandis que ses principales qualités sont une sécurité accrue et une vitesse de lecture importante.

Figure 3.7 RAID 6

3.4.1.2 Stockage distribué Un système de stockage distribué (DSS) est un réseau d'ordinateurs où l'information est stockée sur plus d'un n÷ud. Contrairement aux solutions de stockage standard, les systèmes de stockages distribués peuvent fournir de meilleures performances à grande échelle lorsqu'elles sont distribuées sur diérents serveurs. Ces systèmes de stockage distribué ont la possibilité d'augmenter l'espace disque et peuvent avoir un grand nombre de n÷uds contrairement à un système de stockage clas- sique où le stockage est limité par le nombre de slots de disques. Un système distribué peut être performant même avec une très faible utilisation de la puissance de calcul (CPU et RAM). Il est impossible de créer un système de stockage distribué orant de hautes performances sur de longues distances, tout simplement parce que les lois de la physique ne le

16 permettent pas, la synchronisation d'un système réparti sur 3 continents prend trop de temps.

3.4.2 Diérentes solutions 3.4.2.1 GlusterFS GlusterFS est un système de chiers libre distribué en parallèle, qui permet de stocker jusqu'à plusieurs pétaoctets de données. C'est un système de chiers en clusters nécessi- tant deux parties, un serveur et un client. C'est ce système de chier que l'on a installé dans notre stockage réseau.

Figure 3.8 Information volume GlusterFS

La gure ci-dessus montre le volume GlusterFS monté à partir de 6 volumes disques pour créer un volume distribué répliqué en réplica 3. Le serveur de stockage fait tourner le démon glusterfsd et les clients utilisent la commande mount ou GlusterFS client pour monter les systèmes de chiers servis, en utilisant FUSE. GlusterFS reposant sur un modèle serveur-client, les parties serveur sont typique- ment déployées comme des briques de stockage , chaque serveur exécutant un démon glusterfsd qui exporte un système de chier local comme un volume . Le processus client GlusterFS, qui se connecte aux serveurs avec un protocole spécique (implémenté au-dessus de TCP/IP, InniBand ou SDP), regroupe les volumes distants en un unique volume. Quelques fonctionnalités de GlusterFS implémentées : duplication et réplication par chier partage de charge par chier gestion des pannes ordonnancement et cache disque quotas GlusterFS ne dispense pas d'eectuer de la redondance locale Par défaut, les chiers sont simplement distribués entre les diérents serveurs. GlusterFS ne dispense pas d'ef- fectuer de la redondance locale et il vaut donc mieux prévoir un système de backups ou

17 un système RAID an de se protéger contre la perte de données. Il est également possible de congurer GlusterFS pour répliquer et distribuer les chiers au sein du cluster. Il existe plusieurs types de volumes diérents, en passant par les volumes distribués (volume par défaut), répliqués, stripé et dispersé mais ces diérents types peuvent se com- biner de plusieurs façons diérentes dont le distribué-répliqué, stripé-répliqué, distribué- dispersé, distribué-stripé et bien d'autres encore. Dans notre architecture notre volume est en distribué-répliqué (replica 3). Nous avons donc besoin d'un nombre de volumes multiple de 3. Le volume distribué-répliqué répartit les chiers de façon uniforme au travers des dié- rentes briques du volume répliqué. Ce type de volume distribué-répliqué est généralement utilisé dans un environnement ayant un stockage scalable c'est à dire que le stockage a la possibilité d'être augmenté ou diminué en fonction de nos besoins, mais aussi avec une haute abilité critique. Les volumes en distribué-répliqué orent une amélioration sur les performances de lecture dans la plupart des environnements.

Figure 3.9 Schéma stockage réseau

3.4.2.2 NFS NFS est un système de chier en réseau qui permet à des hôtes distants de monter des systèmes de chiers sur un serveur en réseau et de les utiliser comme des systèmes de chiers locaux. Il permet aux utilisateurs de stocker des ressources sur des serveurs centralisés sur le réseau. De nos jours, il existe trois versions de NFS, NFSv2 est la plus ancienne des trois versions. NFSv3, avec davantage de fonctionnalités dont le traitement de chiers de taille variable et possède un meilleur rapport d'erreurs mais n'est pas compatible avec les clients

18 NFSv2. NFSv4 dière des versions précédentes de NFS en autorisant un serveur à déléguer à un client des actions spéciques sur un chier an de permettre une mise en cache plus agressive des données côté client ainsi que la mise en cache de l'état de verrouillage. Toutes les versions de NFS peuvent utiliser le protocole TCP/IP (nécessaire pour NFSv4). Le protocole UDP peut être utilisé par les versions 2 et 3 pour pouvoir fournir une connexion réseau sans état entre client et serveur. Il est possible de rendre NFS hautement disponible grâce à un système de cluster actif-passif an d'éliminer le point de défaillance sur les serveurs de stockage. Pour cela, il faut utiliser DRDB qui ore un système de réplication comparable à un RAID 1 mais en réseau. Il permet donc d'assurer la disponibilité des données même en cas de crash complet d'une machine. A cela sera couplé Heartbeat. C'est un logiciel qui surveillera les serveurs. Si un serveur devient défaillant, Heartbeat bascule les services surveillés sur un autre serveur. Cependant, NFS Actif-Passif n'utilise pas tous les serveurs en même temps. Un seul est utilisé, il est dit actif, et seulement lorsque le client n'arrive pas à communiquer avec ce serveur il utilise le serveur passif.

3.4.2.3 BeeGFS BeeGFS (anciennement FhGFS) est un système de chier parallèle en cluster open- source, optimisé pour le calcul haute performance. En développant BeeGFS, Fraunhofer visait trois principales caractéristiques : scalabilité, exibilité et facilité d'installation. BeeGFS tourne sur toutes les machines Linux. Pour exécuter BeeGFS, nous avons besoin d'au moins une instance du serveur de mé- tadonnées et du serveur de stockage. BeeGFS permet en ajoutant plusieurs instances de chaque service d'augmenter les performances. Cela nous permet en ajoutant des serveurs de métadonnées d'augmenter la vitesse de création de chiers et en ajoutant des serveurs de stockage d'augmenter le débit et les taux de lecture/écriture aléatoires. Cette augmentation de performance est linéaire, cette augmentation de performance est eective même au-delà de 20 serveurs de chaque service.

19 3.4.2.4 Comparatif GlusterFS NFS BeeGFS Version 3.8.8-1 4.0 v2015.03.r10 POSIX Oui Pas entièrement Oui Open Source Oui Oui Client Oui / Serveur EULA Metadonnées Non Oui Oui avec Manager Striping Oui Oui Oui Support Oui Oui Oui RDMA/Inniband Failover Réplication de Pacemaker + Réplication de données Corosync données Quota Oui Oui Oui Snapshots Oui Oui Non API REST API et Libnfs Striping , Cache, FUSE, mount hadoopConnector Réplication Synchrone DRBD : synchrone En miroir Répartition charge Manuel Manuel Manuel Haute disponibilité Oui Oui Oui

20 3.5 Clustering

3.5.1 Principe du Clustering Un cluster est un groupe de ressources, tel que des serveurs, qui agit comme un seul système. Une fois conguré, il ache ainsi une disponibilité élevée, voire, dans certains cas, des fonctions de traitement en parallèle et d'équilibrage de la charge. On parle ainsi de gestion en cluster ou de clustering.

3.5.1.1 Quorum Le quorum est un nombre de présence minimal parmi les membres d'une assemblée sans lequel une délibération au sein de celle-ci ne peut être valide. Dans le cas d'un cluster, c'est la même chose et il faut au moins 3 n÷uds dans un cluster pour pouvoir avoir une majorité dans une décision. Dans le cas où un n÷ud subit une défaillance, pour éviter que d'autres n÷uds eectuent diérentes opérations pouvant mener à une inconsistance de services ou du cluster, c'est le quorum qui va dénir s'il n'est nécessaire de migrer les services du n÷ud et de savoir quel n÷ud va prendre le relais.

3.5.2 Diérentes solutions 3.5.2.1 Proxmox VE Proxmox Virtual Environment est une solution open-source de virtualisation basée du l'hyperviseur KVM. En utilisant Proxmox il est possible de créer des clusters et des machines virtuelles, d'administrer et de superviser ces mêmes machines virtuelles à l'aide d'une interface web. De paramétrer des solutions de sauvegarde et de restauration ainsi que de migrations de machines. Le tout est installable sur une machine Debian en ajoutant un paquet ainsi qu'en congurant quelques chiers, soit directement en installant une image iso Proxmox VE.

3.5.2.2 Ganeti Ganeti est une solution open-source de gestion de cluster développé par Google qui utilise XEN ou KVM comme plateforme de virtualisation. Cette solution est paramétrée uniquement en mode console et ne possède pas d'interface graphique.

3.5.2.3 oVirt oVirt est une solution open-source de plateforme de virtualisation qui propose éga- lement un système de clustering. Il permet, comme ses homologues ci-dessus, de gérer diérentes instances KVM. Créé par Red Hat en parallèle à Red Hat Enterprise Virtua- lization, oVirt est souvent considéré comme étant la version non stable de RHEV sortie en amont.

21 3.5.2.4 Comparatif Proxmox VE oVirt Ganeti Prix Gratuit mais Gratuit / RHEV Gratuit support payant étant la version commerciale Créateur Proxmox Red Hat Google OS Windows, Debian RHEL/ Fedora/ Linux, Windows GNU/Linux Centos Graphique Application web Application Web CLI / Monitoring avec Ganeti Web Manager Licence Open Source, Apache Licence 2.0 2-clause BSD AGPLv3 licence Virtualisation KVM, LXC Xen, KVM Xen, KVM, LXC Stockage Local - LVM - Local - NFS - Local - DRBD - GlusterFS - NFS - GlusterFS - iSCSI Ceph Ceph/RBD - CephFS Haute disponibilité Oui, Stable et Oui Déclenché par la able, Linux HA supervision Format d'image raw - qcow2 - raw - qcow2 tous formats vmdk - subvol API Oui (REST) Oui (REST) API Open REST ; API compatible OpenStack Migration Possibilité de Possibilité de Possibilité de tout déplacer des déplacer des migrer vers machines virtuelles machines virtuelles n'importe où en marche en marche Backup, Restaura- Import/export Ligne de Import/export tion planning commande avec cong automatisé Nfs stockage des server sauvegardes Pare-feu Customisable Customisable Ajout de règles (iptables rules) avec le démon Documentation et Documentation sur Support payant Support externe, support technique Pve-Proxmox et pas Ganeti Support payant eux-mêmes

22 3.6 Réseaux

Lors du choix de l'infrastructure, nous devions nous renseigner sur le réseau convenant le mieux à notre solution. D'un côté l'Omni-Path plus performant mais coûtant plus cher que son homologue Ethernet. L'Omni-Path, autrement abrégé OPA, est une architecture de communication haute performance possédée par la société Intel qui possède une très faible latence comme indiqué sur le tableau comparatif ci-dessous. L'Ethernet, quant à lui, est l'architecture de communication la plus répandue du fait de son faible coût bien que ses performances n'égalent pas les réseaux que sont Omni-Path et InniBands. La seule raison pouvant faire préférer Ethernet à Omni-Path est donc le prix, or dans l'architecture actuelle nous voyons que le réseau actuel est déjà en Omni-Path. Nous ne voyons donc pas d'intérêt à procéder au moindre changement.

3.6.1 Comparatif Ethernet Omni-Path Fréquence 1-1000 MHz Modulable Bande passante 12,5 GB/s 125 GB/s MTU size 1500 bytes 8192 bytes Latence 20 us 910 ns Coût économique 2 euros / Câble de 2m 72 euros / Câble de 2m

23 3.7 Monitoring

Le monitoring, ou supervision, est la surveillance du fonctionnement d'un système ou d'une activité. Il nous permet de surveiller des systèmes informatiques dans leur fonctionnement et de nous informer ou nous alerter des états anormaux. Le monitoring est une partie cruciale à notre projet comme dans beaucoup de sys- tèmes informatiques. C'est ce service qui détectera toute anomalie au sein du cluster (Concernant un n÷ud ou un logiciel...). Il nous permettra d'obtenir une disponibilité éle- vée en prévenant d'une part les administrateurs mais aussi en déclenchant une migration automatique des logiciels défaillants. Ayant du retard lors de la soutenance intermédiaire, il ne nous a pas été possible de rajouter un outil de supervision, comme prévu initialement et ce faute de temps.

3.8 Ansible

Ansible est un logiciel libre conçu pour la conguration et la gestion d'ordinateurs ainsi que pour le déploiement de logiciels. Dans le cadre du projet tuteuré nous avions prévu d'utiliser Ansible pour automatiser la création de machines virtuelles avec une même conguration mais faute de temps après la soutenance intermédiaire nous n'avons malheureusement pas pu nous atteler à la tâche.

24 Chapitre 4

Outils utilisés

4.1 Planner

Planner ou GNOME Planner est un logiciel permettant de faire des diagrammes de Gantt et de les exporter en PDF ou en HTML pour être aisément visible dans un navi- gateur. Nous ne connaissions pas ce logiciel et l'avons utilisé pour la première fois lors de ce projet pour mettre en place le diagramme se trouvant dans la partie "Organisation" du rapport.

4.2 VPN

Pour se connecter à distance aux serveurs Proxmox VE, il nous faut nous connecter au réseau de la faculté de science où se trouvent les serveurs et pour cela nous utilisons Cisco VPN Client qui est un logiciel propriétaire.

4.3 X2GO

Une fois connecté au réseau à l'aide du VPN ci-dessus, nous utilisons X2GO, un logiciel libre permettant de se connecter à un ordinateur serveur linux à distance. Dans notre cas nous nous connectons à une machine se trouvant sur le réseau des serveurs Proxmox VE pour pouvoir y accéder à l'aide de l'interface web.

4.4 Vagrant

Vagrant est un logiciel libre de virtualisation que nous avons appris à utiliser lors de cette année à l'IUT Charlemagne. Nous l'avons utilisé principalement pour créer dié- rentes machines virtuelles et ainsi pouvoir tester l'utilisation de logiciels tels que Glus- terFS.

25 4.5 Git

Pour communiquer avec notre tuteur et pour partager les diérents documents relatifs à notre avancement, nous utilisons Framagit que nous avons appris à utiliser au cours de notre année à l'IUT Charlemagne.

4.6 LATEX LaTeX est un langage permettant de créer des PDF et des slides ayant une mise en forme standard. Utilisé pour la première fois cette année, nous avons décidé de l'utiliser pour créer le rapport ainsi que les slides du projet tuteuré.

4.7 Google Drive

Google Drive a été principalement utilisé pour la création de Google Sheets permettant de travailler à plusieurs sur les tableaux comparatifs et de manière simultanée. Ces dits tableaux se trouvent dans les diérentes parties "Comparatif" du rapport.

4.8 Draw.io

Draw.io est l'application qui nous a servi à faire les diérents Schémas présents dans le rapport. Une personne dans le groupe étant habitué à utiliser cette application nous a montré son fonctionnement et nous avons rapidement opté pour son utilisation.

26 Chapitre 5

Problèmes rencontrés

Au cours de notre projet, nous avons rencontré divers problèmes aussi bien logiciels qu'au niveau du matériel. Le premier problème que nous avons rencontré a été la puissance des machines que nous avions à l'IUT qui nous empêchait de faire diérents tests avec plusieurs machines ou simple de faire plusieurs machines virtuelles sur un même ordinateur. Le problème principal a été la compréhension du sujet qui nous a fait avoir quelques problèmes d'organisation. Nous avions du mal à nous mettre d'accord sur les tâches de chacun. Cela a également engendré une non-compréhension de l'objectif du sujet malgré le travail eectué au préalable. Nous avons également rencontré quelques soucis lors de l'installation de Ganeti et même avec la documentation que nous trouvions, nous n'avons pas réussi à le faire fonctionner correctement. Nous avons eu un problème avec BeeGFS concernant la communication entre les diérents services que nous n'avons pas réussi à corriger. Nous avons eu quelques soucis avec les premiers tests pratiques GlusterFS où le réplica ne fonctionnait pas de la même manière sur toutes les machines.

27 Chapitre 6

Conclusion

Ce projet tuteuré fut enrichissant à de nombreux points de vue. Au fur et à mesure de l'avancement du projet, nos recherches de documentation se sont anées jusqu'à aller rechercher des informations dans les bibliothèques universitaires. Nous avons appris, au l de l'avancement du projet, de nombreuses informations qui ont étayé nos connaissances en virtualisation. Le sujet principal évoquant KVM, nous nous sommes attelés à trouver un maximum de documentation sur la haute disponibilité ainsi que sur la virtualisation en général. Dans la majorité des documents parlant de KVM nous avions davantage de renseignements concernant les diérents logiciels de clustering que nous avions à charge de traiter. Chacun d'entre nous se pencha sur les diérents sujets que nous devions voir puis nous partagions les informations pour décider ensuite de celui que nous allions nalement utiliser. Nous étant rapidement décidé sur l'utilisation de Proxmox VE, nous avons centré nos recherches sur ce point. Ce logiciel étant utilisé en entreprise nous étions intéressé de développer ce sujet qui s'est montré pratique à l'utilisation. Le sujet initial évoquant 3 solutions de stockages à tester, nous avons exploré les solutions et avons fait diérents tests sur des machines Vagrant pour comprendre le fonctionnement de chacune de ces solutions avant de pouvoir les appliquer dans notre maquette. Suite à un allégement de l'objectif de notre projet tuteuré après la soutenance intermédiaire, nous avons eu pour objectif de mettre en place GlusterFS. En dehors de l'objectif principal de notre projet, nos diérentes réunions avec notre tuteur et ses explications quant à l'infrastructure de son centre de calcul nous ont aidés à avoir une meilleure vision de l'infrastructure que nous devions modier ainsi que de son fonctionnement. Cela nous a également fait utiliser de nombreux outils et logiciels que nous n'avions jamais utilisés auparavant comme Planner ou X2GO que nous pourrions être amené à utiliser un jour dans un cadre professionnel. Notre approche du projet fut confuse en amont et il nous a fallu quelque temps avant de nous recentrer sur le sujet et de travailler en équipe pour partager les diérentes informations et les diérents problèmes que nous avons rencontrés. Malgré les lacunes que nous avions au début du projet, après avoir été recadré par notre tuteur, nous nous sommes nalement concentrés sur notre objectif nal. Nous avons, au cours de ce projet, beaucoup appris dans les diérents domaines ci-contre et nous sommes satisfaits concernant le dénouement de ce projet tuteuré.

28 Chapitre 7

Bibliographie

- Stockage : https://indico.fnal.gov/event/12347/contribution/3/material/slides/0.pdf http://moo.nac.uci.edu/~hjm/fhgfs_vs_gluster.html#_introduction https://www.tecmint.com/introduction-to-glusterfs-file-system-and-installation-on-rhelcentos-and-fedora/ https://docs.gluster.org/en/latest/Install-Guide/Configure/ https://help.ubuntu.com/community/HighlyAvailableNFS https://www.beegfs.io/wiki/MDMirror Réseau : https://www.nextplatform.com/2017/11/29/the-battle-of-the-infinibands/ http://www.teratec.eu/library/pdf/forum/2017/Presentations/A7_03_Forum_ TERATEC_2017_%20SWINBURNE_%20INTEL.pdf https://www.intel.com/content/www/us/en/products/network-io/high-performance-fabrics/ omni-path-cables.html http://hpc-opinion.blogspot.com/2016/02/intel-omnipath-network-what-happened-to. html http://calcul.math.cnrs.fr/IMG/pdf/intel-omni-path-for-journees-mesocentre. pdf https://en.wikipedia.org/wiki/List_of_interface_bit_rates#Local_area_networks - Proxmox VE : https://www.proxmox.com/en/proxmox-ve/comparison https://www.proxmox.com/en/proxmox-ve/features https://pve.proxmox.com/wiki/Main_Page https://pve.proxmox.com/wiki/Category:Reference_Documentation https://blog.lrdf.fr/article2/retour-experience-proxmox https://pve.proxmox.com/wiki/Backup_and_Restore - oVirt : https://www.ovirt.org/documentation/install-guide/chap-System_Requirements. html https://en.wikipedia.org/wiki/OVirt https://ovirt.org/documentation/ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/ 6/html/high_availability_add-on_overview/ch-virt

29 https://www.ovirt.org/develop/release-management/features/storage/image-upload. html - Ganeti : http://www.ganeti.org/ https://blog.syloe.com/outil-de-gestion-de-cluster-ganeti https://fr.slideshare.net/gpaterno1/comparing-iaas-vmware-vs-openstack-vs-googles-ganeti-28016375 - Installation Proxmox VE : https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch - Install KVM et conguration de bridge : https://www.server-world.info/en/note?os=Debian_9&p=kvm&f=1 - VM KVM avec Virt Manager : https://www.guillaume-leduc.fr/premiere-vm-distante-avec-virt-manager.html - Installation de machines Unix Virt : https://raymii.org/s/articles/virt-install_introduction_and_copy_paste_ distro_install_commands.html#Debian_8 - Introduction au cluster sous Linux : https://www.sebastien-han.fr/blog/2011/07/04/introduction-au-cluster-sous-linux/ - Comparaison KVM Virtualbox : http://www.deltasight.fr/kvm-ou-virtualbox-pour-virtualiser-sous-linux/ - Virtualisation KVM Schéma : https://linux.goffinet.org/09-virtualisation-kvm/ - Schéma Cluster Proxmox : https://www.osnet.eu/fr/content/tutoriels/mise-en-place-dun-cluster-proxmox-4-avec-nfs-sous-freenas - PCA PRA : http://www.solutionitpme.fr/2013/10/04/lecon-n-15-comprendre-la-difference-entre-pca-et-pra-2403 - E-book : http://univ.scholarvox.com.bases-doc.univ-lorraine.fr/book/88843333? http://univ.scholarvox.com.bases-doc.univ-lorraine.fr/book/88842876? - Livre : https://eds-a-ebscohost-com.bases-doc.univ-lorraine.fr/eds/detail/detail? vid=3&sid=4d2dd453-aa6e-4f20-af7d-cb8261b19a17%40sessionmgr4010&bdata=JkF1dGhUeXBlPWlwLHVybCx1aWQmbGFuZz1mciZzaXRlPWVkcy1saXZlJnNjb3BlPXNpdGU% 3d#AN=cbu.660542&db=cat04003a

30 Chapitre 8

Annexes

Installation des n÷uds GlusterFS pour les 3 serveurs: mkfs.xfs -f /dev/sdb1 mkfs.xfs -f /dev/sdb2 mkdir /mnt/sdb1 mkdir /mnt/sdb2 mount /dev/sdb1 /mnt/sdb1 mount /dev/sdb2 /mnt/sdb2

#echo "/dev/sdb /mnt/sdb xfs defaults 0 0" >> /etc/fstab #montage permanent

Serveur 1: apt install -y glusterfs-server apt update && apt upgrade -y /lib/systemd/systemd-sysv-install enable glusterfs-server service glusterfs-server status gluster peer probe 10.2.0.111 gluster peer probe 10.2.0.112 gluster peer probe 10.2.0.113 gluster pool list mkdir /mnt/sdb

#gfs nom du volume gluster volume create gfs replica 3 transport tcp 10.2.0.111:/mnt/sdb1 10.2.0.112:/mnt/sdb1 10.2.0.113:/mnt/sdb1 10.2.0.111:/mnt/sdb2 10.2.0.112:/mnt/sdb2 10.2.0.113:/mnt/sdb2 force gluster volume list gluster volume start gfs gluster volume status gfs gluster volume info gfs

31 (sécurisation par IP) #gluster volume set gfs auth.allow 10.2.0.111,10.2.0.112,10.2.0.113

Serveur 2: apt install -y glusterfs-server apt update && apt upgrade -y /lib/systemd/systemd-sysv-install enable glusterfs-server

#mount.glusterfs localhost:/gfs /mnt #df -h

Serveur 3: apt install -y glusterfs-server apt update && apt upgrade -y /lib/systemd/systemd-sysv-install enable glusterfs-server

#mount.glusterfs localhost:/gfs /mnt #df -h

Montage client sans Proxmox: apt install -y glusterfs-client -y apt update && apt upgrade -y mount.glusterfs 10.2.0.111:/gfs /mnt

Conguration etc/hosts

127.0.0.1 localhost.localdomain localhost 10.2.0.111 pmx01.prod.pct pmx01 10.2.0.112 pmx02.prod.pct pmx02 10.2.0.113 pmx03.prod.pct pmx03

# The following lines are desirable for IPv6 capable hosts

::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts

32 Conguration etc/network/interfaces auto lo iface lo inet loopback iface enp2s0f0 inet manual auto vmbr0 iface vmbr0 inet static address 10.2.0.11X netmask 255.255.255.0 gateway 10.2.0.8 bridge_ports enp2s0f0 bridge_stp off bridge_fd 0 iface enp2s0f1 inet manual

Conguration etc/resolv.conf search prod.pct nameserver 10.2.0.8 nameserver 10.2.0.9

Installation d'une machine virtuelle en ligne de commande virt-install --name $machine --ram 1024 --disk path=/var/kvm/images/$machine.img, size=10 --vcpus 1 --os-type linux --os-variant debian9 --network bridge=$br --console pty,target_type=serial --cdrom=$Images/debian-9.6.0-amd64-DVD-1.iso