REMERCIEMENTS. Merci à tous ceux qui nous lierons et apprécierons notre travail.

(1)

(2)

« Que je veuille connaître une machine, je la découperai pour en étudier séparément chaque partie. Quand j’aurai de chacune une idée exacte et que je pourrai les remettre dans le même ordre où elles étaient, alors je concevrai parfaitement cette machine, parce que je l’aurai décomposée et recomposée. »

Condillac

(3)

REMERCIEMENTS

Nous tenons à remercier tout d’abord nos formateurs Jérôme Bonin et Frédéric Bourdeix de nous avoir permis de réaliser ce mémoire très intéressant.

Merci aussi à Hadi Alnabrisui qui, grâce à ses tutoriels sur le web, nous a permis de comprendre certaines notions du cluster et de mettre en œuvre notre sujet de mémoire.

Nous n’oublierons pas les torréfacteurs qui nous ont permis de nous tenir éveillés toutes ces longues nuits passées à se documenter et mettre en place ce système de clustering.

Merci à tous ceux qui nous lierons et apprécierons notre travail.

(4)

SOMMAIRE

1 INTRODUCTION ... 5

1.1 SCHEMA RESEAU ... 6

1.2 SCHEMA EXPLICATIF DU PROJET A ATTEINDRE ... 7

2 PROXMOX VE ... 8

2.1 DECOUVERTE DE PROXMOX VE ... 8

2.1.1 KVM et QEMU ... 9

2.1.2 OpenVZ ... 9

2.2 LES FONCTIONNALITES ... 10

2.2.1 Central management ... 10

2.2.2 Sauvegarde et restauration ... 10

2.2.3 Console html 5 ... 10

2.2.4 Proxmox mobile ... 11

2.2.5 Pare-feu intégré. ... 12

2.3 PROCEDURE D’INSTALLATION DE PROXMOX VE ... 12

2.3.1 Mise en place de Proxmox VE ... 12

3 LE CLUSTERING ... 18

3.1 DEFINITIONS ... 18

3.1.1 Fencing ... 18

3.1.2 Quorum ... 19

3.1.3 HA (High Availability) ... 20

3.1.4 Migration ... 20

3.2 DESCRIPTION TECHNIQUE DE LA CREATION D’UN CLUSTER ... 20

3.2.1 Mise en place d’un cluster a trois nœuds ... 20

3.2.2 Creation d’une machine virtuelle ... 35

3.2.1 Activation de la haute disponibilité sur une machine virtuelle ... 42

3.2.2 Analyse fonctionnelle du cluster ... 46

4 CONCLUSION ... 50

(5)

1 INTRODUCTION

Pour ce mémoire, Rémi Perrin et moi-même, Serge Braconnier, avons choisi le sujet « PROXMOX VE ».

Nous avions déjà pu voir le fonctionnement de cet hyperviseur à l’EEP de L’ADAPT à Monéteau. Dans cette entreprise d’entrainement pédagogique (EEP), il n’y a qu’un seul hyperviseur contenant 3 machines virtuelles – Un serveur Zentyal, un pare-feu routeur pfSense et un Windows XP pour le serveur CIEL-.

Nous voulions aller plus loin encore avec ce mémoire. Même si ce système de virtualisation est déjà très modulable, nous sommes obligés d’arrêter les machines virtuelles si nous devons intervenir physiquement sur l’hyperviseur. Avec plusieurs serveurs Proxmox en grappe, nous gagnons en flexibilité et nous pouvons migrer les machines virtuelles d’un serveur à un autre. C’est ce que nous allons mettre en place à travers ce mémoire.

Trois hyperviseurs Proxmox seront reliés en cluster avec une haute disponibilité de façon à pouvoir migrer les machines virtuelles d’un nœud à un autre à chaud sans que l’utilisateur final soit perturbé dans son travail.

Nous verrons plus en détails les particularités, les avantages et inconvénients, ainsi que les nouvelles fonctionnalités de la version 3.2.

Pour mettre en place ce travail, nous avons choisi de le faire virtuellement pour avoir plus de souplesse.

La configuration technique des outils utilisés pour cette mise en œuvre est la suivante :

 VirtualBox version 4.3.12 (Hyperviseur de type 2)

 3 Machines virtuelles sous PROXMOX VE 3.2 X64 - Système : 6 Go de mémoire vive.

- Stockage : Un disque dur de 50 Go qui accueillera le système Proxmox.

Un disque dur de 50 Go non partitionné pour la partition RBD.

- Réseau : Une carte réseau Ethernet en mode « interne » dédiée au flux principal entrant et sortant (10.0.2.0/24).

Une carte réseau Ethernet en mode « interne » pour la liaison Ceph entre chaque nœud (10.0.3.0/24).

 1 machine virtuelle sous pfSense pour faciliter la redirection de ports et l’accès aux interfaces web.

Tout ceci prend place sur un ordinateur portable équipé d’un processeur Intel i7 3630Q et de 32 Go de mémoire vive.

(6)

1.1 SCHEMA RESEAU

Réseau virtualisé

(7)

1.2 SCHEMA EXPLICATIF DU PROJET A ATTEINDRE

(8)

2 PROXMOX VE

2.1 DECOUVERTE DE PROXMOX VE

Proxmox VE est une solution open source complète de virtualisation de type 1 pour serveurs. Il est basé sur les technologies de virtualisation KVM et conteneurs OpenVZ et gère les machines virtuelles, le stockage, les réseaux virtualisés, et la haute disponibilité.

Il faut savoir qu’un « environnement virtuel » est une entité séparée et cloisonnée. Du point de vue de son propriétaire, il ressemble à un vrai serveur physique.

Chaque Environnement Virtuel a son propre compte système « root », ainsi que ses propres utilisateurs et groupes.

L'interface réseau virtuelle permet à un Environnement Virtuel d'avoir ses propres adresses IP, aussi bien qu'un ensemble de règles pare-feu et de routage.

Si nécessaire, on peut accorder à n'importe quel Environnement Virtuel l'accès à de vrais périphériques tels que des interfaces réseau, des ports séries, des partitions de disque, etc…

L'installation du système à partir du CD formate le disque entrainant l'effacement complet des données qui pouvaient être présentes sur le serveur.

Cependant, étant donné que Proxmox VE repose sur une distribution Debian, il est tout à fait possible de l'installer à partir de paquets sur une machine existante (sous réserve que celle-ci soit sous Debian), sans pour autant perdre ses données.

Un accès à un service payant est disponible (https://www.proxmox.com/fr/proxmox-ve/pricing) et donne droit à plusieurs options supplémentaires telles que :

 L'accès au référentiel d'entreprise (Mises à jour des paquets « entreprise »)

 Soutien via le portail client

 Temps de réponse du support : 1 jour ouvrable

Proxmox VE est utilisé dans les entreprises indépendamment de leur taille, secteur ou de l'industrie ainsi que dans les ONG et dans le secteur de l'éducation. A titre informatif, OVH (Gros hébergeur internet Européen) est dans une phase de migration de toutes ses solutions d’hypervision actuelles vers Proxmox VE.

Les fonctionnalités avancées et l'interface Web intuitive sont conçues pour vous aider à optimiser l'utilisation de vos ressources existantes, réduire les coûts en matériel et le temps nécessaire à l'administration en entreprise ainsi qu'à la maison. Vous pouvez facilement virtualiser les charges de travail les plus élevées sous Linux, Windows et même d’autres systèmes comme BSD.

Cet hyperviseur n’a pas à rougir devant les « monstres » VMware et Hyper-V.

Système requis recommandé :

 Dual ou Quad Socket Server.

 CPU : 64 bits (Intel EMT64 ou AMD64).

 Intel VT / AMD-V CPU capable / Carte mère (pour le support complet de virtualisation KVM)

 8 Go de RAM ou plus.

 RAID matériel avec des piles cache protégée en écriture (BBU) ou protection flash.

 Disques durs rapides.

 Cartes réseau Gigabit.

(9)

2.1.1 KVM et QEMU

KVM, Kernel Virtual Machine, permet une virtualisation matérielle et donc une accélération de la virtualisation de système d’exploitation.

KVM est un hyperviseur libre de type 1 pour Linux. Il est intégré dans le noyau Linux depuis la version 2.6.20.

Le développement de KVM a commencé au sein de la société Qumranet par Avi Kivity. Red Hat a racheté Qumranet le 4 septembre 2008. Depuis KVM est co-maintenu par le développeur Marcelo Tosatti.

KVM est une instance de QEMU. Les développeurs des deux projets essayent de ne pas trop diverger et le code source des deux projets est fréquemment resynchronisé. La principale modification apportée est la prise en charge du module KVM. Lorsqu'on parle de KVM, on parle généralement de l'ensemble : la version modifiée de QEMU et le module KVM. C’est pour cela que, bien souvent, on peut voir l’appellation: « qemu-kvm ». QEMU et KVM sont complémentaires et dépendants. Ils sont d'ailleurs regroupés dans un même paquet linux.

QEMU est capable, grâce à son module KQEMU (K pour Kernel), d'exécuter du code machine directement sur le processeur hôte afin d'accélérer l'émulation. Mais cette technologie, bien qu'apportant un gain de performance important, n'est pas parfaite, car des mécanismes de protection pour intercepter et émuler les évènements privilégiés doivent être mis en place ; or le code noyau du système invité, fonctionnant normalement entièrement en mode privilégié et étant émulé de manière classique, est donc fortement pénalisé alors qu'il s'agit de l'élément crucial du système.

Les technologies mises en place par les deux principaux fondeurs que sont AMD et Intel étant différentes, le module KVM se décline en deux sous-modules : kvm-Intel et kvm-AMD ; le module kvm n'étant là en fait que pour fournir à l'émulateur une couche d’abstraction supplémentaire.

2.1.2 OpenVZ

OpenVZ est une technique de virtualisation de niveau système d'exploitation (Hypervision de type 1) basée sur le noyau Linux. Il a été créé par la société Parallels et est distribué sous la licence publique générale GNU version2.

Le noyau d'OpenVZ est un noyau Linux modifié qui ajoute la notion d'environnement virtuel. Le noyau fournit la virtualisation, l'isolement et la gestion de ressource. Cette solution intègre un système de gestion de conteneurs et permet à un serveur physique d'exécuter de multiples instances de systèmes d'exploitation isolés, qualifiées de serveurs privés virtuels (VPS) ou environnements virtuels (VE).

Vous pouvez télécharger et installer plus de 50 appliances virtuelles. Une appliance virtuelle est un environnement entièrement préinstallé et préconfiguré.

L’inconvénient de ce procédé est d’obliger les systèmes d’exploitation invités et hôte à être tous les deux basés sur le noyau Linux.

La fonctionnalité de migration live et de checkpoint pour OpenVZ a été annoncée en avril 2006. Elle permet de migrer un environnement virtuel d'un serveur physique à un autre sans arrêt/relance du VE. Ce processus est connu comme application « checkpointing » : le VE est gelé et son état entier est sauvegardé dans un fichier sur disque. Ce fichier peut alors être transféré sur une autre machine sur laquelle le VE pourra être restauré. Le délai de migration est de quelques secondes, et ce n'est pas un temps d'arrêt, juste un retard.

Les scénarios suivants d'utilisation sont communs à toutes les techniques de virtualisation. Cependant, un avantage unique de la virtualisation de niveau OS comme OpenVZ est de ne pas trop dégrader les performances, ce qui rend ces scénarios plus attrayants.

(10)

Sécurité :

La virtualisation permet d'isoler chaque service réseau (comme Apache, le serveur mail, le serveur DNS, etc…) dans un environnement virtuel séparé. Dans ces conditions, si un intrus trouvait une faille de sécurité dans une des applications, il ne pourrait maltraiter que ce service même ; puisque tous les autres services sont dans des environnements virtuels séparés, il ne pourrait pas y accéder.

Consolidation de serveur :

Actuellement, la plupart des serveurs sont peu employés. En utilisant OpenVZ, de tels serveurs peuvent être consolidés en les migrants dans des environnements virtuels. Le gain est dans l'espace pris par les racks, les factures d'électricité, et les coûts de gestion.

2.2 LES FONCTIONNALITES

2.2.1 Central management

Le propre Web-GUI vous donne un aperçu de tous vos invités KVM et conteneurs Linux et même de votre grappes entières. Il n'y a pas besoin d'un serveur de gestion distincte et complexe.

Proxmox VE utilise le « Cluster file system », un système de fichiers de base de données axée pour stocker des fichiers de configuration. Cela vous permet de stocker la configuration de milliers de machines virtuelles. En utilisant corosync, ces fichiers sont répliqués en temps réel sur tous les nœuds du cluster. Le système de fichier stocke toutes les données à l'intérieur d'une base de données permanente sur le disque, néanmoins, une copie des données réside dans la RAM qui fournit une taille maximale de stockage de 30 Mo - plus que suffisant pour des milliers de machines virtuelles.

Proxmox VE est la seule plate-forme de virtualisation à utiliser ce système de fichiers en cluster unique.

2.2.2 Sauvegarde et restauration

L'outil de sauvegarde intégré (vzdump) crée des instantanés cohérents de fonctionnement OpenVZ VE et invités KVM. Il crée essentiellement une archive des données VM ou CT et inclut également les fichiers de configuration VM et CT.

« KVM Live Backup » fonctionne pour tous les types de stockage y compris les images de machines virtuelles sur NFS, iSCSI, Ceph, RBD, GlusterFS ou ZFS. Le nouveau format de sauvegarde est optimisé pour stocker des sauvegardes de machines virtuelles rapides et efficaces.

2.2.3 Console html 5

Depuis la version 3.2, Proxmox VE supporte l’HTML5. Désormais les consoles d’accès à la machine virtuelle se font directement en HTML5. Avant l’arrivée de l’HTML5 dans Proxmox VE, les accès console se faisaient via Java et VNC. La facilité d’accès aux consoles a été grandement améliorée

(11)

2.2.4 Proxmox mobile

Depuis le mois de septembre 2014 et donc la version 3.2, Proxmox VE a développé une interface mobile pour gérer ses environnements virtuels à distance. En vous connectant à partir de votre mobile dans un navigateur web, vous pourrez découvrir une nouvelle interface spécialement conçue pour les Smartphones. Elle est un peu déroutante au début quand on a l’habitude de l’interface web standard, mais toutes les options principales de surveillance sont disponibles.

(12)

2.2.5 Pare-feu intégré.

Un pare-feu est intégré pour gérer la sécurité des machines virtuelles ou container et des nœuds physiques. Plusieurs parties sont configurables :

 La direction du flux : In et Out

 L’action : ACCEPT/DROP/REJECT

 L’interface.

 L’adresse ip source.

 L’adresse ip de destination.

 Le protocole.

 Le port source.

 Le port de destination.

Un menu « MACRO » est disponible pour choisir des protocoles et des ports préconfigurés.

On peut attribuer les règles aux VM, aux containers ou aux nœuds.

Cette fonctionnalité évite l’obligation d’ajouter un pare-feu sur chaque environnement virtuel et permet de centraliser la sécurité à partir de l’interface web de PROXMOX.

2.3 PROCEDURE D’INSTALLATION DE PROXMOX VE

2.3.1 Mise en place de Proxmox VE

Durant ces prochaines lignes vous allez découvrir l’installation de Proxmox VE 3.

Nous avons voulu rendre cette procédure d’installation facile à l’aide de captures d’écrans.

Avant de commencer, il faut vérifier certains points :

 Votre configuration RAID, si vous l’installez sur un serveur physique.

 La mise en place des deux cartes réseau.

 Le branchement des câbles Ethernet

Une fois l’étape de vérification faite, vous pouvez insérer le disque d’installation de Proxmox.

Note : Reportez-vous au chapitre 1 (configuration technique des outils utilisés pour cette mise en œuvre).

Voici l’écran que vous devriez apercevoir au début de l’installation :

(13)

Avant de lancer l’installation, nous allons paramétrer la taille du swap et de la partition root.

Tapez la ligne de commande « linux ext4 maxroot=10 swapsize=1 » (Attention ! Pour cette étape le clavier est en qwerty)

Sachez que les valeurs représentent des gigaoctets. Vous pouvez modifier ces valeurs si vous le souhaitez.

A noté que, par défaut, la taille du swap sera automatiquement de la même taille que la quantité totale de votre mémoire vive installée. Si vous avez 16 Go de RAM sur votre serveur, le swap sera de 16 Go aussi. C’est pour cela qu’il est préférable de modifier la taille de la zone de swap tout en prenant en compte la taille de votre stockage. Par contre si vous estimez avoir besoin du swap, ne modifiez pas ce paramètre.

Lisez et acceptez les conditions d’utilisation si vous désirez installer Proxmox VE.

Cliquez sur « I agree » pour continuer.

(14)

Sélectionnez le disque dur qui accueillera le système Proxmox VE.

Sélectionnez votre pays, le fuseau horaire et la version de votre clavier.

Définissez votre mot de passe et votre adresse e-mail.

(15)

Saisissez vos propres paramètres réseau correspondant au réseau principal que vous aurez choisi.

Attendez jusqu’à la fin de l’installation.

Une fois l’installation terminée, retirer le disque du lecteur et cliquez sur « Reboot ».

(16)

Suite au redémarrage du serveur vous devriez voir cet écran. Ne touchez à rien, Proxmox VE se lancera de lui- même.

Une fois le serveur démarré, vous devriez apercevoir cet écran.

Pour accéder à l’interface de Proxmox, vous devez avoir une machine connectée sur le même réseau avec un navigateur à jour (Si possible Chrome ou Mozilla). Pour accéder en mode « Secure SHell » (SSH) vous devez avoir un émulateur de terminal (Putty fera très bien l’affaire). Ouvrez le navigateur web et tapez l’adresse du lien comme indiqué sur la capture d’écran précédente. Dans notre cas nous allons taper : https://10.0.2.201:8006. N’oubliez pas de renseigner le port 8006.

Votre navigateur vous alertera que votre connexion n’est pas privée dû au certificat de sécurité qui n’est pas considéré comme fiable. Passez outre et continuez.

(17)

Connectez-vous avec le mot de passe que vous avez défini pendant l’installation. Le « User name » est « root » par défaut. Vous pouvez mettre l’interface en français, mais personnellement je préfère la laisser en anglais à cause de certaines traductions approximatives.

Voici l’interface de Proxmox :

Maintenant que vous savez installer Proxmox, vous allez devoir reproduire cette procédure deux fois pour avoir au total trois Proxmox. N’oubliez pas de modifier les adresses IP ainsi que leurs noms sur chaque hyperviseur.

Une fois les trois Proxmox installés et en fonction, vous pouvez passer au chapitre suivant pour comprendre et mettre en place un système de cluster entre ces trois serveurs.

(18)

3 LE CLUSTERING

Le Clustering (regroupement en français) est une technologie qui permet une interconnexion permanente entre plusieurs machines indépendantes et qui permet d’avoir une haute disponibilité dans le partage des ressources informatiques. Le Cluster forme un système fiable de par sa redondance des données sur chaque serveur. Cette technologie permet aussi, par une répartition sur les différents nœuds, de réaliser un équilibrage de charge de travail plus conséquent et/ou plus rapide.

Si une machine venait à être en surcharge, alors les autres pourraient prendre le relais.

Dans notre cas, le Clustering consiste à connecter un ensemble de trois serveurs que l’on appelle des nœuds et qui communiquent en permanence afin de palier à la moindre panne d’un des serveurs.

C’est ce que l’on appelle la haute disponibilité qui permet la disponibilité et la stabilité des ressources proche des 100%.

Cela permet d’augmenter un peu plus la tolérance de pannes matérielles ou logicielles.

3.1 DEFINITIONS

3.1.1 Fencing

Le fencing n'a pas vraiment d'équivalent en français. C'est une notion liée à la haute disponibilité de la même façon que le quorum, et qui sert principalement à éviter des situations où les services tournent sur deux parties du cluster indépendantes. Le fencing consiste à pouvoir isoler chaque nœud du cluster pour être sûr qu'elle ne reviendra pas inopinément.

Par exemple, si un serveur redémarre par accident, le cluster se voyant en majorité va démarrer les services du nœud défaillant. Sauf qu’une fois le nœud redémarré, il va rentrer de nouveau dans le cluster, donc avoir la majorité, et donc décider de lancer ses services. Ce qui va provoquer de nouveau une situation de doublon.

Le rôle du fencing est donc d'autoriser le groupe du cluster ayant le quorum (ayant la majorité) à isoler artificiellement le ou les nœuds défaillants. Le système de HA ne fonctionne pas si le fencing n'est pas configuré correctement.

Globalement, le quorum sert à pallier à une panne sur la liaison entre les machines, alors que le fencing sert à pallier à une panne matérielle de la machine. Ces deux concepts fonctionnent donc côte à côte.

(19)

3.1.2 Quorum

Le quorum est un concept assez difficile à appréhender, et pourtant il est absolument nécessaire de le comprendre pour travailler sur un cluster en HA. D'après la page wikipédia, un quorum est le nombre minimal de personnes nécessaires pour prendre une décision dans un groupe. C'est un terme utilisé en droit habituellement, et un quorum représente en général la majorité, si tout le monde vote pour une voix. En informatique, le quorum est le nombre minimal de votes à atteindre pour prendre une décision automatiquement, comprendre sans intervention humaine.

Dans le cas d'un cluster, on peut donner à chaque serveur du cluster un poids différent ou identique, qui va influencer sur les choix que va prendre l'intelligence du cluster en cas de besoin. Par exemple, tous les serveurs ont un poids de un. S'il y a 5 serveurs, le quorum va être de 3. Il faut être au moins 3 pour prendre une décision.

Dans ce cas, en cas de panne par exemple sur la liaison réseau entre les serveurs, ceux-ci prendront des décisions en fonction de leur quorum.

Prenons un exemple :

Nous avons 5 serveurs, montés en HA, avec un poids de 1 chacun. Une panne réseau survient, qui isole 3 serveurs d'un côté et 2 de l'autre. Chaque serveur va vérifier la connectivité avec les autres. Les serveurs ayant le quorum (le groupe de 3), se trouvant en majorité, peuvent prendre la décision de démarrer chez eux les services précédemment hébergés chez les 2 serveurs manquants. Les serveurs n'ayant plus le quorum (le groupe de 2) vont par contre décider qu'ils ne sont plus en majorité, et donc déduire que d'autres ayant le quorum vont prendre leur place. Ils vont donc prendre la décision de couper leurs services, voire de s'éteindre en attendant une intervention extérieure.

Ce système permet d'éviter que des services tournent en même temps à deux endroits différents. Imaginez par exemple que la connexion entre les 2 groupes soit interrompue, mais que la connectivité Internet de chaque groupe fonctionne encore. Sans quorum, les utilisateurs seraient dirigés sur le site web de gauche ou de droite, rendant ingérable la restauration. En effet, si le site est un forum, alors les utilisateurs vont postés des messages à droite et à gauche, il faudrait donc les fusionner pour revenir à un état stable sans perdre de données. C'est un casse-tête qui a été réglé par la notion de Quorum.

Bien sûr, ce système n'est pas parfait : Pour reprendre notre exemple, si le problème de connectivité fait que nous avons deux groupes de 2 serveurs et un groupe de 1, aucun des groupes n'a le quorum et tous risquent de s'éteindre. De la même façon, si nous avons un nombre pair de serveurs (Par exemple 4), le quorum est exactement la moitié, ce qui fait qu'en cas de répartition égale des groupes de serveurs, chacun va décider de démarrer les services de l'autre groupe !

En conséquence, il est très important de bien comprendre cette notion. Dans l'idéal, vous devez toujours monter des clusters avec un nombre impair de serveurs, quitte à ce que l'un deux soit juste une machine virtuelle dans un coin servant « d'arbitre ». Monter un cluster pair est possible, mais vous acceptez alors le risque de créer des situations qui seront difficilement gérables.

(20)

3.1.3 HA (High Availability)

Proxmox VE Cluster HA permet la mise en service de machines virtuelles avec des disponibilités élevées.

Si une machine virtuelle ou un conteneur virtuel (VM ou CT) est configuré comme HA et l'hôte physique tombe en panne, la machine virtuelle est automatiquement redémarrée sur l'un des Proxmox restant parmi les nœuds de cluster.

Les Proxmox VE Cluster HA sont basés sur des technologies Linux HA éprouvées, assurant le service de HA stable et fiable.

La disponibilité des ressources sur le Cluster est proche de 100%.

Dans le cas où des nœuds ne pourraient plus fournir de réponses aux requêtes des clients, alors les autres nœuds du Cluster prennent le relais.

Ainsi elle évite quasiment toute interruption de communication entre les applications ou ressources et le client.

3.1.4 Migration

La migration est un atout indéniable du Clustering. Celle-ci peut s’exécuter à froid : Cela correspond à déplacer une ou plusieurs VMs d’un nœud, toutes éteintes, sur un autre nœud. L’inconvénient est que durant cette phase de transition, les services que délivraient les VMs ne sont plus disponibles pour les utilisateurs.

En revanche, c’est la migration à chaud qui porte tout l’intérêt de cette méthode.

Pour exemple, si l’on doit intervenir sur un serveur du Cluster pour une maintenance quelconque, il est possible de transférer les VMs sur un autre serveur sans les éteindre et extrêmement rapidement. Les utilisateurs n’auront même pas conscience de ce qu’il s’est passé.

3.2 DESCRIPTION TECHNIQUE DE LA CREATION D’UN CLUSTER 3.2.1 Mise en place d’un cluster a trois nœuds

3.2.1.1 Préparation des nœuds

Désormais vous devriez avoir vos trois nœuds (Proxmox) prêts à être configurés pour installer un service de haute disponibilité entre ces trois hyperviseurs. Ouvrez une session en SSH sur chaque nœud car nous allons passer d’un nœud à l’autre durant cette procédure.

Connectez-vous sur le premier nœud (Dans notre exemple, nous avons nommé les Proxmox node1, node2 et node3). Vérifiez que vous avez bien une connexion à Internet pour les mises à jour des Proxmox.

Attention, vous allez être connecté automatiquement en tant que « root ». Faites attention aux commandes que vous entrerez.

(21)

Tapez la commande « nano /etc/network/interfaces » afin de modifier le fichier de configuration TCP/IP de Proxmox. (Vous pouvez aussi changer la configuration réseau à partir de l’interface web dans l’onglet « Network »)

C’est dans ce fichier que vous pouvez ajouter une adresse IP à l’interface vmbr1 de Proxmox pour le second réseau.

Pensez à modifier ce fichier sur tous les nœuds si vous utilisez un deuxième réseau pour le Ceph et à redémarrer les machines pour que les configurations TCP/IP soient bien prises en compte.

Note : A chaque modification apportée à un fichier, sauvegardez avec CTRL+O et ENTRÉE puis quittez avec CTRL+X.

(22)

Nous allons modifier la liste des dépôts de Proxmox. Tapez la commande comme ci-dessous :

Commentez la première ligne avec un « # », ajoutez la seconde ligne comme ci-dessous et sauvegardez avec CTRL+O et ENTRÉE puis quittez avec CTRL+X.

Tapez la commande « apt-get update && apt-get dist-upgrade –y »

Cette commande va installer les paquets et la dernière version de Proxmox en validant toutes les demandes prompt automatiquement.

(23)

Pour faciliter l’installation du cluster nous allons modifier le fichier hosts. Tapez la commande « nano /etc/hosts »

Vous pouvez aussi faire ces déclarations dans le serveur DNS.

Une fois dans le fichier hosts, nous allons ajouter les machines distantes à la suite de la machine actuelle.

Référez-vous à la capture ci-dessous pour modifier votre fichier. Pensez à sauvegarder puis fermer le fichier.

Une fois ceci fait, redémarrez le Proxmox.

Vous devez maintenant procéder de la même manière sur les autres nœuds.

Faites les mises à jours et modifiez les fichiers hosts.

Sur le nœud 1 ajoutez les nœuds 2 et 3.

L’ajout des nœuds dans le fichier hosts n’est pas obligatoire mais il allègera la suite des procédures. Elle permet de faire les configurations en rappelant les noms des nœuds et non les adresses IP.

Faites des tests de ping à partir de leurs noms pour vérifier que les machines communiquent bien entre elles.

(24)

3.2.1.2 Liaison des nœuds

Maintenant que vos 3 nœuds sont configurés nous allons pouvoir créer le cluster. Pour notre exemple nous resterons originaux car le cluster se nommera : « cluster ». Vous pouvez bien sûr choisir un autre nom.

Tapez la commande « pvecm create cluster ».

Ensuite, depuis les nœuds 2 et 3 nous allons ajouter le cluster précédemment créé sur le nœud 1.

Un message indique que l’authentification du nœud 1 n’a pas pu être établie. Continuez en tapant « yes » et validez.

(25)

Les nœuds rejoignent le cluster :

Redémarrez les nœuds une fois qu’ils sont ajoutés au cluster.

Une fois les 3 nœuds redémarrés, nous pouvons passer à l’installation de l’architecture de stockage distribué à haute tolérance aux pannes développée pour la virtualisation : Le Ceph.

Lancez la commande « pveceph install » sur chaque nœud.

Si vous avez un réseau secondaire réservé pour le cluster c’est maintenant que vous allez pouvoir indiquer au nœud le réseau à utiliser pour le Ceph.

Tapez la commande « pveceph init --network 10.0.3.0/24 » seulement sur le nœud 1.

Nous devons installer les moniteurs. Ils gèrent la surveillance des "OSD" (disques durs faisant partie du volume Ceph) et la redondance des différents "Pools" (volumes virtuels servant à l'hébergement des machines virtuelles).

Tapez la commande « pveceph creatmon » sur tous les nœuds

Note : Si la commande ne se lance pas, relancez le service pve-cluster avec la commande:

« service pve-cluster restart »

(26)

Redémarrez les 3 nœuds et connectez-vous sur l’interface web du nœud 1 de préférence.

Sélectionnez le nœud 1 et positionnez-vous sur l’onglet « Ceph » puis sur l’onglet « Disks ». Vous apercevez les disques disponibles de ce nœud.

 /dev/sda (Le disque où est installé Proxmox)

 /dev/sdb (Le disque qui fera office de volume RBD)

Note : Les disques /dev/sdb ne doivent pas être partitionnés à l’avance.

Positionnez-vous sur le disque /dev/sdb et cliquez sur « Create OSD »

(27)

Vérifiez que vous êtes bien sur le disque /dev/sdb et validez en cliquant sur « Create »

Créez les OSD sur tous les nœuds.

Vous devez avoir les OSD visibles comme ci-dessous en allant dans l’onglet OSD :

(28)

Toujours dans le l’onglet principal « Ceph », cliquez sur l’onglet « Pools » puis sur « create ».

Pour que notre exemple reste simple, nous donnons le nom « rbdvol » au pool, une valeur de 2 à la taille, une taille minimum de 1, le Crush RuleSet reste à 0 et 256 au pg_num.

Cette partie de configuration est un peu obscure. En parcourant internet, on peut s’apercevoir que tout le monde donne ces valeurs (sauf le nom).

Les valeurs à donner pour le pg_num sont le résultat de calculs entre le nombre d’OSD et le nombre de réplicas.

Voici la formule : nombre d'OSD x 100 / nombre de réplicas puis puissance de 2 supérieure Pour notre exemple cela donne : (3x100) / 3² = 33,33.

33 étant le minimum à accorder, nous avons choisi de donner un multiple de « taille mémoire » (128, 256, 512, 1024…) en tant que valeur.

Retournez sur la session SSH du nœud 1.

Créez un dossier nommé « ceph » dans « /etc/pve/priv/ ». Copiez la clé située dans

« /etc/pve/priv/ceph.client.admin.keyring » puis collez la avec un nouveau nom dans « /etc/pve/priv/ceph/ ».

(29)

Désormais retournez sur l’interface web de Proxmox et sélectionnez « datacenter » puis cliquez sur l’onglet

« Storage ». Cliquez sur « Add » puis dans le menu choisissez « RBD ».

Note : L’ID du volume RBD, le nom du pool RBD ainsi que la clé doivent avoir le même nom. « rbdvol » pour notre exemple.

Vous devez lister toutes les adresses IP des nœuds en les inscrivant dans le champ « Monitor Host » (Ce sont les adresses IP du réseau Ceph). Les adresses doivent être séparées par un espace. Cela sert à lier les moniteurs entre eux pour qu’ils puissent communiquer.

Indiquer un nom d’utilisateur et, dans le champ « Nodes », sélectionnez tous les nœuds et vérifiez que

« Enable » est bien coché. Validez en cliquant sur « Add ».

(30)

Retourner sur la session en SSH du nœud 1.

Nous arrivons dans une phase où il faut bien comprendre le mécanisme de version du fichier cluster.conf.

Ce fichier vous servira à modifier les paramètres du cluster qui comprend le fence, la méthode, le vote du quorum et si besoin le failover.

A chaque modification de ce fichier, il faut copier/coller et renommer celui-ci et incrémenter « 1 » à sa version.

La ligne <cluster name="cluster" config_version="3"> devient <cluster name="cluster" config_version="4">, etc…

Pour ce faire, tapez les commandes :

« cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new »

« nano /etc/pve/cluster.conf.new »

Voici le fichier de base « non modifié » du cluster :

(31)

Modifiez le fichier avec les informations décrites comme ci-dessous. Pensez à bien changer votre numéro de version.

Pour simplifier la modification du fichier (et si vous avez la version numérique de ce document) vous pouvez faire un copier/coller à partir de la configuration de la page suivante toujours en pensant à changer le numéro de version, vos mots de passe et les adresses IP :

(32)

<?xml version="1.0"?>

<!--

Pour 3 nodes ou plus : retirer les options du <cman> comme ci-dessous Pour 2 nodes mettre <cman two_nodes="1" expected_votes="1" keyfile..../>

-->

</cman>

</fencedevices>

<fence>

</method>

</fence>

</clusternode>

<fence>

</method>

</fence>

</clusternode>

<fence>

</method>

</fence>

</clusternode>

</clusternodes>

</cluster>

(33)

Une fois le fichier modifié et sauvegardé, retournez sur l’interface web du nœud 1 et sélectionnez

« DataCenter » puis cliquez sur l’onglet « HA ».

Vous pouvez voir les paramètres du fichier « cluster.conf.new ». Cliquez sur « Activate ». Le Proxmox va enregistrer le fichier dans « cluster.conf » et supprimer le fichier « cluster.conf.new » automatiquement.

C’est sur cette interface que vous pourrez activer plus tard la haute disponibilité sur vos machines virtuelles.

Nous devons désormais activer le fence sur chaque nœud.

Dans les sessions SSH des nœuds 1, 2 et 3, tapez la commande suivante :

« Décommentez » la ligne # FENCE_JOIN= "yes" en retirant le "#".

(34)

Ensuite, toujours sur tous les nœuds, tapez la commande suivante « fence_tool join ».

Retournez sur l’interface web de Proxmox sur n’importe quel nœud et créez une machine virtuelle (voir le chapitre 3.2.2).

(35)

3.2.2 Creation d’une machine virtuelle

Pour la création d’une VM, vous devez cliquer sur l’onglet « CreateVM » qui se trouve en haut et à droite de l’interface web de Proxmox.

Vous accédez à la boite de dialogue où différents onglets vous sont proposés.

Ainsi, l’onglet « General » permet de choisir sur quel nœud vous souhaitez créer la VM. Vous devez choisir un ID et définir un nom pour cette VM.

Choisissez le type de système d’exploitation que vous souhaitez installer.

(36)

Vous pouvez sélectionnez l’endroit où se situe le système. Soit sur le disque local (Il faut envoyer l’image sur le disque au préalable), soit sur le lecteur CD/DVD physique de la machine. Sinon vous pouvez désactiver le média.

Paramétrages du disque dur. Vous pouvez sélectionner plusieurs types de disques : IDE, SATA, VIRTIO ou SCSI.

Note : Le type « SATA » ne permet pas de faire des « snapshot » à chaud. Pensez à selectionnez le stockage sur « rbdvol » pour migrer vos machines.

(37)

Sélectionnez le nombre de processeurs pour votre machine virtuelle.

Vous pouvez choisir une taille de mémoire fixe ou dynamique pour la machine.

Cet onglet présente différents modes de connexions pour la carte réseau.

(38)

L’onglet « confirm » récapitule la configuration choisi avant de valider par le bouton « finish » en bas à droite.

(39)

Ensuite, étant donné que les nœuds Proxmox sont eux même virtualisés avec Virtualbox, il est nécessaire de désactiver « KVM hardware virtualization » pour permettre aux machines virtuelles de démarrer.

En revanche, sur des serveurs physiques, il faut laisser cette option activée.

Afin d’allumer la nouvelle VM, il vous suffit de cliquer sur « Start » en haut à droite ou en faisant un clic droit directement sur la VM puis « Start ».

Il apparait ainsi dans l’onglet « Tasks » en bas de l’interface, la confirmation que la VM est en marche.

Cet onglet d’information est très utile pour identifier certains problèmes.

(40)

Une fois que la VM est en marche, il est nécessaire de lancer la console. Vous pouvez le faire par un clic droit sur la VM puis en cliquant sur console. Vous pouvez également le faire grâce au bouton « Console » en haut à droite de l’interface web. Il vous permet de choisir entre la version VNC et noVNC (HTML5).

Voici un aperçu de la console en HTML5 permettant d’éviter une connexion via VNC. Effectivement VNC, qui utilise Java, n’est pas idéal car il procure des défaillances au moment des connexions.

(41)

Voici un aperçu des options disponibles dans la console HTML5 :

Bouton d’envoi de combinaisons de touches. Bouton d’envoi de commandes d’extinction.

(42)

3.2.1 Activation de la haute disponibilité sur une machine virtuelle Sur l’interface web, sélectionnez « DataCenter » et cliquez sur l’onglet « HA ».

Note : Dans notre exemple la machine est éteinte, mais vous pouvez aussi activer la haute disponibilité sur une machine allumée.

Cliquez sur « Add » et sélectionnez dans le menu : « HA managed VM/CT ».

Renseignez l’ID de la machine virtuelle dans le champ « VM ID » et cochez « Autostart » si vous voulez que votre machine démarre automatiquement au démarrage du nœud ou après une migration. Cliquez sur « Create » pour valider.

(43)

Suite à l’activation de la haute disponibilité de la machine, le fichier de configuration du cluster a été modifié.

Cliquez sur « Activate » afin de valider cette nouvelle configuration. Notez que la version du fichier a été automatiquement incrémentée de 1. Vous pouvez aussi ajouter d’autres machines en allant modifier le fichier de configuration vu dans le chapitre « 3.2.1.2 Liaison des nœuds » ou reproduire cette procédure à partir de l’interface web.

Après activation :

(44)

Voici à quoi ressemblera le fichier de configuration après activation. C’est entre les balises <rm> que vous ajouterez les nouvelles machines destinées à être en haute disponibilité

(45)

Démarrez le service RGManager sur tous les nœuds. Pour se faire sélectionnez le nœud, cliquez sur l’onglet

« Services », sélectionnez RGManager et cliquez sur « Start ».

Ce service se charge en grande partie de la communication entre les nœuds.

Vos trois nœuds sont configurés en cluster avec une haute disponibilité sur la machine virtuelle.

(46)

3.2.2 Analyse fonctionnelle du cluster

3.2.2.1 Migration

Démarrez votre VM si ce n’est pas déjà fait :

Faites un test de ping sur la machine pour contrôler le temps d’interruption durant la migration.

(ping –t adresseIPdelamachine)

Faites un clic droit sur la VM et selectionnez « Migrate »

(47)

Sélectionnez le nœud cible et laissez coché « Online » pour une migration à chaud.

Résultat de la migration :

Le temps de coupure est de 1 seconde environ, passant ainsi pratiquement inaperçu pour l’utilisateur final.

(48)

En réalisant ce mémoire, nous avons pu migrer une machine virtuelle pendant une installation de son système sans problème. Nous avons juste dû mettre le fichier iso du système sur un disque RBD pour que celui- ci soit bien répliqué sur tous les nœuds.

3.2.2.2 Simulation d’une panne

Pour simuler une panne afin de tester la haute disponibilité de la VM, arrêtez le service RGManager sur le nœud où se situe la machine virtuelle et constatez que la VM passe automatiquement sur un autre nœud.

Patientez quelques instants le temps que le service s’arrête complètement.

(49)

Vous pouvez constater, suite à la simulation d’arrêt du nœud 1, que la VM a migré sur le nœud 3 automatiquement.

(50)

4 CONCLUSION

A travers ce mémoire nous avons pu appréhender le système de clustering avec haute disponibilité des machines virtuelles. Nous avons dû faire beaucoup de recherches sur internet afin de se documenter sur ce procédé et comprendre parfaitement son fonctionnement. Certaines parties n’étaient pas faciles à maitriser (nous pensons à la configuration du pool avec le « pg_num » par exemple). Certaines parties de Proxmox ont été volontairement omises. Nous ne voulions pas non plus entrer trop en détails dans le fonctionnement de Proxmox mais nous savons que notre but a été atteint : Installer trois serveurs Proxmox en cluster avec une haute disponibilité sur les machines virtuelles et faire une procédure pour qu’un administrateur réseau puisse l’utiliser.

Vous ne trouverez nulle part sur internet une procédure aussi détaillée et fonctionnelle. Certes, il y a bien des morceaux ici et là, des schémas mais rien qui explique de A à Z l’installation de trois Proxmox en cluster avec la haute disponibilité. Et pour cause, les administrateurs mettant en place un cluster choisissent la version payante. Un support technique leur est mis à disposition pour l’installation des clusters.

Nous avons rencontré un problème majeur durant ce projet. Une nouvelle version de Proxmox était sortie et nous avons voulu mettre à jour les serveurs. Malheureusement cette version (la 3.2.4) ne prenait pas en compte l’ancienne version du Ceph et nous empêchait de continuer notre projet. Nous avons du « downgrader » la version des Proxmox pour faire fonctionner le Ceph. Une semaine plus tard, Proxmox sortait une correction de bug grâce à des paquets Ceph mis à jour.

Nous sommes très heureux et fiers d’avoir pu mener ce projet à terme et espérons que sa lecture vous aura plu.