D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

66
ISC-CNRS Migration de la solution de virtualisation Formation ENI-AFPA Madour Youssef Stage entreprise du 16/04/2018 au 28/06/201 18/06/2018

Transcript of D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

Page 1: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

ISC-CNRS

Migration de la solution de

virtualisation Formation ENI-AFPA

Madour Youssef Stage entreprise du 16/04/2018 au 28/06/201 18/06/2018

Page 2: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

1

Table des matières Abstract ................................................................................................................................................... 6

Remerciements ....................................................................................................................................... 6

L’ISC en quelques mots ........................................................................................................................... 7

2 Départements ............................................................................................................................... 7

Le service informatique ................................................................................................................... 7

Infrastructure actuelle ......................................................................................................................... 8

Cahier des charges................................................................................................................................... 9

Introduction ......................................................................................................................................... 9

Etude des besoins ................................................................................................................................ 9

Contraintes .......................................................................................................................................... 9

Contrainte de temps ........................................................................................................................ 9

Planning prévisionnel ...................................................................................................................... 9

Contraintes techniques ................................................................................................................. 10

Moyens mis en œuvres ..................................................................................................................... 10

Moyens humains ........................................................................................................................... 10

Moyens matériels .......................................................................................................................... 10

Risques potentiels ............................................................................................................................. 10

Risques humains ............................................................................................................................ 10

Risques matériels .......................................................................................................................... 10

Risques Logiciels ............................................................................................................................ 10

Gestion des risques ........................................................................................................................... 10

Concepts de base de la virtualisation .................................................................................................... 11

Qu’est-ce que Proxmox ..................................................................................................................... 11

KVM versus LXC ............................................................................................................................. 11

Maquettage ........................................................................................................................................... 12

Prise en main et premier contact ...................................................................................................... 12

Pré requis........................................................................................................................................... 12

Problèmes rencontrés ................................................................................................................... 12

Solutions apportées ....................................................................................................................... 12

Matériel utilisé : ............................................................................................................................ 13

Mise en place de l’environnement de maquettage .......................................................................... 13

Paramétrage du iDRAC sur le serveur R640 .................................................................................. 13

Installation proxmox ve 5.1 ........................................................................................................... 13

Paramétrage post installation ....................................................................................................... 13

Problèmes rencontrés ................................................................................................................... 14

Page 3: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

2

Solutions apportées ....................................................................................................................... 14

Solution 1 : ............................................................................................................................................. 15

Création d’une solution de stockage zfs partagé en NFS et d’une sauvegarde croisée s’appuyant également sur du partage NFS .............................................................................................................. 15

Introduction ....................................................................................................................................... 15

Choix du système de fichier .......................................................................................................... 16

Création également d’une VM Debian .............................................................................................. 16

Mise en cluster des 4 nœuds ............................................................................................................. 18

Prérequis : ..................................................................................................................................... 18

Gestion des VM ................................................................................................................................. 20

Partage NFS ................................................................................................................................... 20

Mise en place de la Haute Disponibilité (HA) .................................................................................... 23

Prérequis ....................................................................................................................................... 23

Ajout de ressources ....................................................................................................................... 23

Test de fonctionnement de la Haute Disponibilité ....................................................................... 24

Sauvegarde croisée ........................................................................................................................... 25

Test de sauvegarde ........................................................................................................................ 26

Amélioration des performances : cache des disques sur SSD ........................................................... 28

Mise en place du cache lvmcache ..................................................................................................... 28

Créer un volume physique ................................................................................................................ 28

Verification: ................................................................................................................................... 29

Créer les LV (Volume Logique) .......................................................................................................... 29

Associer les 2 LV via un pool .......................................................................................................... 29

Allocation « cache pool » à pve/data ................................................................................................ 30

Vérification du résultat via le shell : .............................................................................................. 31

Résultat via interface web: ............................................................................................................ 31

Retour d’expériences ........................................................................................................................ 31

Avantages ...................................................................................................................................... 31

Inconvénients ................................................................................................................................ 31

Solution 2 : ............................................................................................................................................. 32

Création d’une solution de stockage CEPH ........................................................................................... 32

Introduction ....................................................................................................................................... 32

Notions importantes ......................................................................................................................... 32

Récapitulatif sur les composants Ceph ......................................................................................... 33

Implémentation ................................................................................................................................. 34

Prérequis ....................................................................................................................................... 34

Page 4: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

3

Mise en cluster proxmox ............................................................................................................... 34

Installation de Ceph ........................................................................................................................... 34

Initialisation ................................................................................................................................... 35

Création des monitors ................................................................................................................... 35

Création des OSD ........................................................................................................................... 36

Création de Pools .......................................................................................................................... 38

Création des stockages : ................................................................................................................ 39

Création du Stockage au sens de la ressource Proxmox ............................................................... 39

Mise en place de la Haute Disponibilité ............................................................................................ 40

Test de fonctionnement de la HA .................................................................................................. 40

Retour d’expériences ........................................................................................................................ 41

Avantages ...................................................................................................................................... 41

Inconvénients ................................................................................................................................ 41

Solution 3 ............................................................................................................................................... 42

Partage via le Distributed Replicated Block Device ............................................................................... 42

Introduction ....................................................................................................................................... 42

Principe de fonctionnement de DRBD ........................................................................................... 42

Protocoles de synchronisation du miroir ...................................................................................... 43

Les ressources ............................................................................................................................... 43

Les rôles ......................................................................................................................................... 43

Mise en place..................................................................................................................................... 44

Prérequis ....................................................................................................................................... 44

Mise en cluster .............................................................................................................................. 44

Création d’un réseau de synchronisation...................................................................................... 44

Vérification du réseau de synchronisation .................................................................................... 44

Installation de drbd ....................................................................................................................... 44

Vérification: ................................................................................................................................... 45

Création du volume logique LVM .................................................................................................. 45

Initialisation ................................................................................................................................... 46

Ajout du Storage dans proxmox .................................................................................................... 46

Ajout des Nœuds au cluster .......................................................................................................... 47

Ajout d’un nœud satellite .............................................................................................................. 48

Paramétrage du protocole de synchronisation ............................................................................. 49

Problème rencontré ...................................................................................................................... 49

Solution.......................................................................................................................................... 49

Tests .................................................................................................................................................. 49

Page 5: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

4

Scénario n°1 ................................................................................................................................... 49

Scénario n°2 ................................................................................................................................... 50

Scénario n°3 ................................................................................................................................... 50

Retour d’expériences ........................................................................................................................ 50

Avantages ...................................................................................................................................... 50

Inconvénients ................................................................................................................................ 50

Solution retenue .................................................................................................................................... 51

Mise en place..................................................................................................................................... 52

Configuration matérielle ............................................................................................................... 52

Organisation des Disques : ............................................................................................................ 52

Paramètre des interfaces dédiées iDRAC ...................................................................................... 52

Pré installation ............................................................................................................................... 53

Installation Proxmox .......................................................................................................................... 53

Paramètre des interfaces 1Go ....................................................................................................... 53

Politique de nommage des nœuds du cluster ............................................................................... 53

Paramètres disque système .......................................................................................................... 53

Procédure de migration du cluster .................................................................................................... 53

Problèmes rencontrés ....................................................................................................................... 54

1er problème .................................................................................................................................. 54

Solution apportée .......................................................................................................................... 54

2e problème ................................................................................................................................... 54

Solution apportée .......................................................................................................................... 54

3e Problème ................................................................................................................................... 54

Solution apportée .......................................................................................................................... 54

4e problème ................................................................................................................................... 55

Solution apportée .......................................................................................................................... 55

Implémentation de DRBD .................................................................................................................. 55

Procédure ...................................................................................................................................... 55

Paramétrage du dépôt .................................................................................................................. 56

Paramétrage des interfaces dédiées ............................................................................................. 56

Installation de drbd ....................................................................................................................... 56

Mise en place du cluster DRBD ..................................................................................................... 57

Création du volume logique LVM .................................................................................................. 57

Initialisation ................................................................................................................................... 57

Ajout des Nœuds au cluster .......................................................................................................... 58

Paramétrage des nœuds satellites ................................................................................................ 58

Page 6: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

5

Test ................................................................................................................................................ 59

Benchmark ..................................................................................................................................... 59

Migration des VM .............................................................................................................................. 59

Protection contre le Split Brain ......................................................................................................... 60

Mise en place de la solution de sauvegarde ..................................................................................... 60

Coût ....................................................................................................................................................... 60

Bilan ....................................................................................................................................................... 61

Conclusion ......................................................................................................................................... 62

Glossaire ................................................................................................................................................ 63

Annexes ............................................................................................................................................. 65

Ressources ............................................................................................................................................. 65

Page 7: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

6

Abstract

The purpose of this internship was to take advantage of the need for the ISCMJ to replace aging virtualization servers, to rethink the architecture in order to improve it. My role was all to first, assess the needs expressed by the IT manager. Then to learn about the operation of proxmox and to inform me about the various existing storage technologies that can be integrated. And finally to test them to be able to propose a viable solution, in phase with the criteria of the IT manager ‘s need namely to stay on proxmox, improve the system without complicating it. And as much as possible to preserve its flexibility for possible future changes. I had first needed to apprehend a virtualization solution that I knew very little. Then I had to learn many storage technologies and find out which the most able to be associated with proxmox. And at last participate in selection of the solution used. The result was a more efficient system, the removal of a SPOF and relating to me a personal and professional enrichment.

Remerciements

Avant toutes choses, je tiens à remercier toutes les personnes qui ont rendu ce stage possible et profitable. Notamment Hugues Pestres formateur AFPA qui m’a mis en contact avec le CNRS, mais également et surtout Sylvain Maurin qui m’a fait confiance pour mener à bien ce projet et pour sa patience ainsi que l’aide précieuse qu’il m’a fournie. Je tiens à remercier également Yohan Pacquit (Technicien support) pour son accueil et son aide sur l’existant ainsi que Marco Bimbi (ingénieur de recherche) pour nos nombreux échanges. Je tiens à remercier également le personnel de l’ISC pour son accueil.

Page 8: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

7

L’ISC en quelques mots

L’institut des Sciences Cognitives était à l’origine un laboratoire propre du CNRS avant de devenir un institut composé d’unités mixtes de recherche, rattaché au CNRS et l’université de Lyon 1.

2 Départements L’UMR5229 qui étudie les mécanismes cérébraux de la cognition et ses dysfonctionnements. De nombreux thèmes sont abordés au sein des équipes de recherche qui le composent, dont la perception, la plasticité motrice, les processus attentionnels, la prise de décision, la motivation et la cognition sociale. Les compétences multidisciplinaires réunies dans le laboratoire incluent la physiologie et la psychologie, mais aussi les mathématiques, l'économie et les disciplines médicales telles que la neurologie et la psychiatrie.

L’UMR5304 quant à lui, intègre les expertises interdisciplinaires de chercheurs des sciences de la vie (psychologie cognitive, neurosciences) et des sciences médicales (psychiatrie de l'enfant, neuropédiatrie) avec celles des arts et des humanités (linguistique théorique et computationnelle, philosophie) pour étudier la nature et la spécificité de l'esprit humain.

Le service informatique Composé de 3 personnes :

Sylvain Maurin, Ingénieur système et réseau responsable du service

Marco Bimbi, ingénieur de recherche

Johan Pacquit : Gestionnaire de parc

Page 9: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

8

Infrastructure actuelle LYRES, MAN1 des établissements publics, relie différents sites de recherche et de formation supérieure sur l’agglomération Lyonnaise par une infrastructure haut débit basée sur une boucle en fibre optique et utilisant des technologies classiques (norme 802.1 et IP).

L’ISCMJ est raccordé par ce réseau à RENATER2 mais utilise également cette infrastructure pour faire héberger dans les datacenter de l’IBCP (Institut de Biologie des Protéines et du Centre de Calcul de l’IN2P3 (Institut National de Physique Nucléaire et de Physique des Particules), ses armoires de serveurs.

L’IN2P3 héberge également le serveur de stockage NFS (hanfs) pour le cluster. L’ISCMJ quant à lui, héberge le serveur de sauvegarde des VM (Melian) ce qui permet d’avoir les sauvegardes sur un site différent du site qui héberge les données et participe ainsi à leur sécurité. Le serveur de téléphonie (xivo) et le serveur DNS/DHCP (Bilbo) ainsi que le serveur NTP (Skinbark) sont également sur l’ISCMJ.

La solution de messagerie s’articule autour de Postfix (Arathorn), serveur de messagerie libre, sous debian 8, et du client Thunderbird, libre également, de la fondation Mozilla. Client utilisé aussi bien pour les postes Windows, que Mac ou Linux.

La taille du quota, pour les boites mails, est importante (10 Go) en raison de son utilisation par les chercheurs comme d’un espace de stockage pour leurs nombreux et parfois volumineux échanges (publications, études, etc…).

La politique de sécurité de L’ISC consiste à rendre les utilisateurs autonomes. La majorité des personnes ayant de bonnes bases en informatique, ils sont administrateurs de leur poste avec des comptes en workgroup sans service d’annuaire. L’activité (accès aux serveurs, mac address se connectant sur les ports, entêtes des flux IP, requête web, accès SSH, etc.) est enregistrée par le service informatique pour des besoins de contrôle en cas de problème de sécurité.

Sur le site de l’ISCMJ se trouve la majorité des postes de travail et d’acquisition expérimentale.

On compte en moyenne 140 utilisateurs (le nombre exact fluctue de par le nombre important de stagiaires et d’étudiants), pour un total de 400 machines, dont 80% environ, disposent d’un contrat de maintenance. Un stock de pièces de remplacement est constitué pour les machines hors garantie.

Voici leur répartition : 160 ordinateurs portables, renouvelés tous les 3 ans 120 postes fixes, renouvelés tous les 4 ans 120 postes pour les expériences, renouvelés tous les 6 ans

Les utilisateurs ont le choix pour leur matériel. La seule limite étant une liste de recommandations établie par Sylvain Maurin (principalement des postes DELL, HP et Apple), sans que cela soit un facteur limitant en cas de besoin spécifique.

Les environnements de travail sont hétérogènes avec une majorité de postes sous Windows 10 et une part moins importante de postes sous Linux et macOS.

1 Metropolitan Area Network : réseau reliant des ressources informatiques des sites distants comme 2 bâtiments par exemple 2 Réseau national de télécommunications pour la technologie, l'enseignement et la recherche

Page 10: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

9

Cahier des charges

Introduction Dans le cadre du remplacement des serveurs vieillissants composant le cluster de la solution de virtualisation proxmox par 4 serveurs Dell PowerEdge C 6420, l’ISC souhaite mettre à profit cette migration pour repenser la solution en terme de disponibilité, de sauvegarde et de retour sur incident.

Etude des besoins Un premier entretien avec le responsable informatique et l’analyse de l’existant m’amène à orienter mes recherches du côté des technologies de stockage et de sauvegarde possible avec Proxmox, étant entendu au départ que la solution de virtualisation resterait Proxmox, pour des raisons de compétences déjà acquise sur cette solution mais également de coût.

Il m’a donc été demandé, d’envisager plusieurs solutions de stockage et de les tester sur des maquettes, afin d’en vérifier le bon fonctionnement et la faisabilité, puis d’accompagner mon maître de stage dans la mise en production de celle qu’il aura retenu.

Le rapport rédigé et soumis au jury, au 18 juin, j’aurai pour tâche jusqu’à la fin de mon stage de produire une documentation et ainsi de préparer mon oral.

Mes maquettes doivent explorer les trois pistes de stockage suivantes :

des volumes locaux ZFS partagés par NFS avec une sauvegarde croisée entre les nœuds du cluster.

des volumes redondants via le réseau (DRBD 9) et partagés avec la fonctionnalité de client ‘diskless’

un stockage distribué recommandé par Proxmox : CEPH

Contraintes Contrainte de temps En terme de planning, il est prévu une semaine de collecte de l’existant, trois semaines de maquettage, et une semaine de tests et de mise en production.

Planning prévisionnel

Le projet devra être finalisé pour le 18 juin 2018 date de remise du rapport à l’AFPA

Page 11: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

10

Contraintes techniques La solution adoptée doit reposer sur Proxmox ve, dans la continuité de l’existant. Les tests et autres mises en place provisoires devront être faits de manière étanche sans risques de perturber la production.

Certains serveurs virtualisés étant critiques, la mise en place finale devra générer le moins de perturbations possible.

Il faudra également éviter les solutions monobloc ne permettant pas un contrôle fin de chaque module, ce qui pourrait amener, en cas de soucis, à remplacer un ensemble.

Moyens mis en œuvres J’ai pu bénéficier de moyen humain et matériel pour m’acquitter de ma tâche.

Moyens humains J’ai eu l’aide de Sylvain MAURIN (ingénieur responsable du service) de Johan PACQUIT (Gestionnaire de parc) et de Marco BIMBI (ingénieur de recherche).

Moyens matériels J’ai eu à ma disposition un serveur DELL PowerEdge EMC R640 afin de mettre en place le bac à sable nécessaire à mes tests ainsi qu’un poste fixe pour me connecter à proxmox, au web et rédiger mon rapport.

Risques potentiels Divers aléas pourraient freiner ou stopper le projet, le but ici est de les identifier autant que faire ce peu.

Risques humains En cas de problème majeur sur une autre partie de l’infrastructure de l’ISCMJ, l’équipe, moi y compris, pourrions être indisponibles et la mise en place freinée ou stoppée.

Risques matériels Pannes électriques :

Pour l’ISCMJ le risque est faible, du fait du raccordement aux lignes ondulées des hôpitaux Est. Pour le Data Center, un générateur et une double adduction Haute Tension minimisent les risques.

Risques Logiciels Il est possible qu’un bug ou une mauvaise manipulation me fasse perdre une ou plusieurs VM.

Gestion des risques Dans l’éventualité de la survenue de l’un de ces risques, j’ai prévu d’effectuer des maquettes chez moi en utilisant VmWare Workstation pour mes VM, même si mes ressources matérielles risquent de me limiter.

Concernant les risques logiciels, j’ai prévu d’effectuer des Sauvegardes régulières.

Page 12: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

11

Concepts de base de la virtualisation La virtualisation consiste à exécuter sur une machine hôte, dans un environnement isolé, des systèmes d’exploitation : on parle alors de virtualisation système. Ou des applications : on parle alors de virtualisation applicative. Ces ordinateurs virtuels sont appelés « serveur privé virtuel » (Virtual Private Server ou VPS) ou encore environnement virtuel (Virtual Environment ou VE)3. Les intérêts d'une telle infrastructure sont multiples : Utilisation optimale des ressources, économie sur le matériel par mutualisation, allocation dynamique des ressources permettant de gérer une montée en charge. Dans notre cas, l'aspect intéressant est une installation, un déploiement et une migration facile des machines virtuelles d'une machine physique à une autre, ce que la mise en cluster permet. Cependant, en cas de panne d'un serveur hôte, l'ensemble des machines virtuelles hébergées sur celui-ci sera impactées. Dès lors, il est nécessaire de réaliser des redondances lors de la mise en œuvre d'un environnement virtualisé, ce qui permettra d’en assurer la haute disponibilité.

Qu’est-ce que Proxmox Proxmox, dont la première version stable date de 2008, est un environnement complet de virtualisation offrant une interface et des fonctionnalités comparables à celle de V Sphère de VMware ou HyperV de Microsoft, à ceci près qu’il est sous licence GPL et s’appuie sur les couches logicielles Open Source comme Perl, Apache, KVM ou LXC. Une souscription entreprise permet de subventionner ces développements et donne accès à un dépôt différencié pour les mises à jour.

Proxmox est basé sur une Debian et inclut un système complet (aujourd’hui une debian Stretch) avec une image kernel recompilée spécifiquement pour les besoins de la solution et un assemblage d’outils et de codes OpenSource pré-paramétrés.

Les deux technologies de virtualisation, l’hypervision (partage de matériel) via KVM/QEMU et la conteneurisation par le partage de kernel via LXC sont implémentées dans Proxmox.

KVM versus LXC KVM (Kernel-based Virtual Machine) permet de créer des VM complétements indépendantes et isolés du système hôte, mais nécessite que l’option de virtualisation du processeur de l’hôte soit activée dans le BIOS.

A contrario les « containers », LXC dans le cas de proxmox, sont dépendants du système Linux sous-jacent et de ce fait ne peuvent conteneuriser que des OS Linux. Ils ne peuvent être déplacées à chaud, mais leur installation est plus rapide que via KVM et ils nécessitent moins de RAM.

Pour toutes ces raisons et notamment le déplacement de VM sans les éteindre, et LXC n’étant pas implémenté à l’adoption de proxmox par l’ISC, c’est la virtualisation KVM qui été privilégié.

3 https://fr.wikipedia.org/wiki/Virtualisation

Page 13: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

12

Maquettage

Prise en main et premier contact Afin de mettre en place une maquette pour que je puisse tester les différentes solutions possibles, un pool est créé sur le nœud pve6 de l’infrastructure existante, ainsi qu’un compte pour que je puisse travailler depuis ce nœud du cluster, mais sans risquer de l’affecter. Le but est de monter un Cluster de 4 nœuds via des VM (Nested Virtualization). Pour se faire, quelques manipulations préalables sont nécessaires.

Pré requis A l’installation d’une solution de virtualisation, quelle qu’elle soit, on doit activer le support matériel de la virtualisation via le bios, or ici, nos 4 nœuds reposeront sur un hôte de virtualisation et pas directement sur la couche matérielle, comme tout hyperviseur de type1.

Pour disposer des possibilités de virtualisation matérielle prévues sur les processeurs récents Intel, mais au travers de l’hôte PROXMOX installé sur la machine, il faut effectuer les paramétrages suivants :

Vérifier si l’option Nested est active

root@pve6:~# cat /sys/module/kvm_intel/parameters/nested Si la commande affiche N c’est qu’il faut l’activer en modifiant une ligne dans le fichier :

/etc/modprobe.d/kvm-intel.conf

# echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf

Ensuite il est nécessaire de recharger le module modprobe -r kvm_intel modprobe kvm_intel

Une dernière vérification de l’activation de l’option Nested nous renvoie bien Y (activé) Problèmes rencontrés Malheureusement, suite au reboot de pve 6 qui devait accueillir les VM pour le cluster de test, celui-ci ne s’est pas relancé. Après investigation il s’est avéré qu’il s’agissait d’une perte des paramètres de support du système de fichier ZFS dans le gestionnaire d’amorçage GRUB, suite à une mise à jour du nœud proxmox.

Solutions apportées Ne pouvant pas effectuer mes tests sur l’environnement, initialement prévu à cet effet, il a été mis à ma disposition un serveur physique PROXMOX pour accueillir, un cluster de 4 nœuds sur VM.

Page 14: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

13

Matériel utilisé : Un switch Cisco Catalyst 2900 XL Un Serveur DELL PowerEdge R640 Carte contrôleur RAID PERC H730P 2 HDD en Raid 0 pour faire un volume de 446 Go Processeurs : Intel(R) Xeon(R) Silver 4108 (x2) RAM : DDR4 8Go (x4) Carte Réseau : Intel(R) 2P X550/2P I350-t NDC (x4)

Le serveur se trouve sur un VLAN afin d’être isolé du réseau de l’ISCMJ pour des raisons de sécurité.

Mise en place de l’environnement de maquettage Paramétrage du iDRAC sur le serveur R640

Adresse ip iDRAC : 192.168.0.60 Adresse ip de la carte réseau eno3 : 192.168.0.61 Création d’un RAID 0 avec les 2 disques pour en faire un volume de 446 Go Emplacement : /dev/sda

Installation proxmox ve 5.1 Installation via l’interface graphique du CD d’installation. Paramétrage de pays : France Paramétrage du clavier : Anglais US

Paramétrage réseau :

Management Interface eno3

Hostname (FQDN) Pve0.isc.cnrs.fr

Adresse ip 192.168.0.61

Masque 255.255.255.0

Passerelle 192.168.0.1

Serveur dns 195.220.109.5

Paramétrage post installation J’ai créé un utilisateur (ymadour) via le Shell, afin de ne pas utiliser root. Cet utilisateur passe par l’utilitaire sudo pour effectuer des commandes qui nécessitent des droits root, mais l’outil sudo n’étant pas installé par défaut sous debian, j’ai dû le faire au préalable via la commande ci-dessous.

root@pve0:~# apt-get install sudo

Une fois sudo installé, il a fallu paramétrer son fichier dédié « sudoers » pour permettre au compte ymadour d’effectuer des tâches avec les droits root.

root@pve0:~# nano /etc/sudoers

ymadour ALL=(ALL :ALL) ALL

Page 15: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

14

L’installation de sudo crée également un groupe auquel il faut ajouter l’utilisateur pour que cela fonctionne.

root@pve0:~#adduser ymadour sudo

Ces actions réalisées, il ne reste plus qu’à créer l’utilisateur ymadour dans proxmox via l’interface graphique.

4 méthodes d’authentification sont possibles sous proxmox :

L’authentification via le standard PAM (Pluggable Authentication Modules) Linux Authentification proxmox server utilisable que sous proxmox Via un annuaire LDAP Via un annuaire Active Directory

J’ai utilisé l’authentification PAM4 qui permet une authentification commune et ainsi pouvoir reprendre l’utilisateur ymadour créé précédemment via le système Debian sous-jacent.

Je lui ai attribué également un des privilèges prédéfinis (Rôles) proxmox, Administrator sur la racine « / » de pve0

Problèmes rencontrés En cours d’installation, la clé USB utilisée n’a plus été reconnue. Au départ, j’ai utilisé l’outil Rufus pour créer le média d’installation, or proxmox n’est pas compatible avec Rufus. Problème également de clavier qui affiche du qwerty alors que le clavier est en azerty.

Solutions apportées Pour le plantage à l’installation, l'utilisation d'un CD-ROM a résolu le problème. Pour les soucis de clavier, cela a été résolu en branchant un clavier qwerty et en sélectionnant à l’installation pays : France et paramétrage du clavier : Anglais US.

4 Pluggable Authentification Module, système d'authentification Linux s’appuyant sur plusieurs points d’autorisation plutôt qu’uniquement le couple login/mot de passe

Page 16: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

15

Solution 1 :

Création d’une solution de stockage zfs partagé en NFS et d’une sauvegarde croisée s’appuyant également sur du partage NFS

Introduction Une fois l’environnement de virtualisation en place pour les maquettes, j’ai pu créer les VM qui serviront à tester plusieurs solutions de Cluster avec sauvegarde afin de trouver celle qui sera le plus en phase avec les exigences liées à l’infrastructure actuelle de l’ISCMJ. J’ai donc mis en place 4 VM proxmox (ver 5.1.3). Pour chaque VM, 3 disques SATA de 8 Go plus 3 disques SCSI de 2 Go ont été alloués. Les disques SATA seront utilisés pour le système et le stockage, selon les solutions testées, et les 3 disques SCSI serviront à faire du cache en écriture sur disque via lvmcache. Sur la solution en production, les disques pour le cache seront des SSD.

Tableau récapitulatif :

Prox1

Prox2

Prox3

Prox4

Disques 3 disques SATA de 8Go en raidz-1 à l’installation

3 disques SATA de 8Go en raidz-1 à l’installation

3 disques SATA de 8Go en raidz-1 à l’installation

3 disques SATA en de 8Go raidz-1 à l’installation

CPU 1x8 cœurs 1x8 cœurs 1x8 cœurs 1x8 cœurs

Memoire 1024 – 8192 via ballooning

1024 – 8192 via ballooning

1024 – 8192 via ballooning

1024 – 8192 via ballooning

IP 192.168.100.101 192.168.100.102 192.168.100.103 192.168.100.104

Page 17: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

16

Choix du système de fichier A l’installation de Proxmox, il est demandé de choisir le système de fichier voulu, j’ai opté pour du ZFS.

Pour les raisons suivantes :

Zfs est à la fois un système de fichier et un gestionnaire de volume logique, ce qui permet de faire du raid logiciel (RAIDZ)

C’est un système sur 128 bits (capacité de disque quasi infini) Protection étendue contre la corruption de données (copy-on-write transactionnel) si RAM

ECC Vérification de l’intégrité en continu et réparation automatique des disques via scrub5 Efficacité en Lecture/Ecriture

Pour garantir l’intégrité des données, le choix s’est porté sûr du RAID logiciel zfs RAIDZ-1 équivalent au RAID5.

Création également d’une VM Debian Cette VM m’a servi à me connecter à distance sur le cluster comme en situation réelle. Elle sert également d’unique point de sortie vers l’extérieur afin de pouvoir faire des mises à jour, le cluster étant isolé du reste du réseau.

Nom d’hôte : debian-service

Interface réseau cluster : ens18

Interface réseau de sortie : ens19

Installation de SSH pour les connexions au cluster

apt install ssh

Installation d’un serveur DHCP

apt install isc-dhcp-server

Paramétrage du serveur DHCP via le fichier de configuration dhcpd.conf afin de renseigner l’interface à utiliser

vi /etc/dhcp/dhcpd.conf

5 Technique de correction d’erreur qui inspecte les périphériques de stockage en tâche de fond périodiquement

Page 18: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

17

Une fois la modification enregistrée il ne reste plus qu’à relancer le service.

Systemctl restart isc-dhcp-server

Paramétrage du DHCP sur une VM debian créée via l’un des proxmox virtualisés afin de voir si notre serveur DHCP fournit bien des adresses en modifiant le fichier /etc/network/interfaces pour l’adressage automatique.

Paramétrage du Masquerading pour faire l’interface entre le réseau étanche du cluster et l’extérieur en modifiant le fichier rc.local pour que le masquerading soit pris en compte sur l’interface réseau ens19.

vi /etc/rc.local

iptables –t nat –I POSTROUTING –o ens19 –j MASQUERADING

sauvegarde de la règle dans iptables

service iptables save

service iptables restart

Modification du fichier de variable d’environnement /etc/sysctl.conf afin d’activer le forwarding ipv4

Page 19: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

18

Vérification du bon fonctionnement dans la table de routage

Mise en cluster des 4 nœuds Concernant le cluster, nous parlerons de nœuds pour évoquer les serveurs le composant.

Prérequis : La date et l’heure doivent être synchronisées Utilisation de SSH pour l’ajout des nœuds au cluster déjà créé sur un premier nœud minimum 3 nœuds pour un quorum fiable Il est recommandé d’avoir une carte réseau dédiée pour le trafic cluster et une carte dédiée

pour le stockage partagé. Sur prox1 création du cluster via le Shell à l’aide de l’outil pvecm implémenté dans proxmox

ve

Je donne au cluster le nom prox-cluster

root@pve1:~# pvecm create prox-cluster

Vérification du résultat post création via la commande pvecm status:

Page 20: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

19

Ajout au cluster des 3 nœuds restant en se connectant sur ceux-ci via SSH depuis le post debian service, créé pour les manipulations et les accès externes. En utilisant la commande :

Pvecm add 192.168.0.100 (adresse ou nom du serveur sur lequel a été créé le cluster)

Vérification post installation :

On peut maintenant gérer les 4 nœuds via une seule interface web sans avoir à ouvrir une page par nœud :

Page 21: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

20

Gestion des VM Création sur chaque serveur d’un dataset dans le pool par défaut pour le stockage des images de VM.

Partage NFS Le système de fichier étant basé sur ZFS, il n’est pas possible de créer un partage par défaut. Pour pouvoir faire un partage qui nous permettra le stockage des images de VM et un partage pour le stockage des sauvegardes de VM d’un nœud vers un autre, je crée tout d’abord un dataset dédié dans mon pool par défaut « /rpool » sur chaque nœud pour les VM et un autre pour les sauvegardes.

Exemple sur prox3:

root@prox3:~# zfs create rpool/VM3

root@prox3:~# zfs create rpool/Backup3

J’ai ensuite installé un serveur NFS sur chaque nœud afin de pouvoir partagé ce dataset :

root@prox3:~# apt install nfs-kernel-server

Chaque fichier exporté vers les utilisateurs distants via NFS ainsi que les droits d'accès liés à ces systèmes de fichiers sont énumérés dans le fichier /etc/exports. Celui-ci se crée à l’installation du serveur NFS mais il faut paramétrer. Je partage le dataset en renseignant le fichier /etc/exports créé à l’installation du serveur NFS :

root@prox3:~# nano /etc/exports

/rpool/VM3 192.168.1.151(rw,no_subtree_check,sync,no_root_squash)

/rpool/VM3 192.168.1.152(rw,no_subtree_check,sync,no_root_squash)

/rpool/VM3 192.168.1.153(rw,no_subtree_check,sync,no_root_squash)

/rpool/Backup3 192.168.1.151(rw,no_subtree_check,sync,no_root_squash)

/rpool/Backup3 192.168.1.152(rw,no_subtree_check,sync,no_root_squash)

/rpool/Backup3 192.168.1.153(rw,no_subtree_check,sync,no_root_squash)

Explication des paramètres :

Rw : Permet aux hôtes d’apporter des modifications au système de fichier

no_subtree_check : permet d'annuler la vérification de la sous-arborescence

sync : tous les transferts vers le disque sont validés avant que la requête d'écriture par le client ne soit achevée.

no_root_squach : annule la fonction de réduction des privilèges du super-utilisateur distant.

Page 22: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

21

Export de tous les répertoires listés dans /etc/exports vers les autres nœuds :

root@prox3:~# exportfs –r

Une fois le dataset partagé je l’active dans proxmox via l’interface web :

Figure 1 Datacenter\Storage\Add\NFS

Comme stockage partagé pour les données des VM je garde « /rpool/VM3 sur prox3 », ainsi les VM créés sur les diffèrent nœuds, ont leur stockage qui pointe sur Prox3/rpool/VM3

Les fichiers de configurations sont sur leur nœud respectif

/etc/pve/nodes/prox1/qemu-server/

root@prox1:~# ls -l /etc/pve/nodes/prox1/qemu-server/

total 1

-rw-r----- 1 root www-data 298 May 9 23:20 100.conf

root@prox1:~# ls -l /etc/pve/nodes/prox2/qemu-server/

total 1

-rw-r----- 1 root www-data 331 May 9 23:12 101.conf

root@prox1:~# ls -l /etc/pve/nodes/prox3/qemu-server/

total 1

-rw-r----- 1 root www-data 331 May 9 22:31 102.conf

Page 23: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

22

Depuis l’interface web on observe que les partages sont visibles sur tous les nœuds

Mais les données sont bien uniquement sur Prox3 dans le dataset partagé VM3

root@prox3:~# ls -l /rpool/VM3/images/

total 2

drwxr----- 2 root root 3 May 9 22:59 100

drwxr----- 2 root root 3 May 9 23:04 101

drwxr----- 2 root root 3 May 9 22:25 102

root@prox3:~# ls -l /rpool/VM3/images/100

total 2437293

-rw-r----- 1 root root 10739318784 May 9 23:03 vm-100-disk-1.qcow2

root@prox3:~# ls -l /rpool/VM3/images/101

total 2418845

-rw-r----- 1 root root 10739318784 May 9 23:12 vm-101-disk-1.qcow2

root@prox3:~# ls -l /rpool/VM3/images/102

total 917

-rw-r----- 1 root root 10739318784 May 9 22:25 vm-102-disk-1.qcow2

Page 24: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

23

Mise en place de la Haute Disponibilité (HA) La haute disponibilité va permettre une continuité de service en cas de défaillance d’un des nœuds, en basculant les ressources vers les nœuds fonctionnels et ceci de manière automatisée.

Prérequis Au moins 3 nœuds pour un Quorum fiable Un stockage partagé pour les VM Watchdog activé

Les fichiers de configuration se trouvent dans :

/etc/pve/ha/

Et sont automatiquement distribués aux autres nœuds du cluster. La HA dans proxmox est gérée par la suite d’outil ha-manager aussi bien pour l’ajout/suppression/vérification des ressources du HA que pour la détection automatique d’erreurs et de défaillances.

Ajout de ressources Pour ajouter les ressources :

# ha-manager add vm:101

Le fichier de configuration des ressources est /etc/pve/ha/resources.cfg Il n’est créé qu’une fois que des ressources ont été ajoutées au HA et de ce fait active la HA.

Avant :

Après :

Ci-dessus le fichier ressources.cfg n’est plus vide

Page 25: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

24

J’ai pu vérifier l’état du HA en utilisant l’outil fournit par proxmox ha-manager :

root@prox1:~# ha-manager status

Quorum OK

Ce qui donne via le GUI :

Test de fonctionnement de la Haute Disponibilité Pour m’assurer des capacités du système à rester disponible en cas de panne, j’ai effectué un test d’arrêt brutal d’un nœud afin d’en observer le comportement :

Figure 1 : Etat et disposition de la VM de test avant arrêt Figure 2: Etat après arrêt de Prox2

Page 26: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

25

Il s’avère que la VM passe bien automatiquement sur un autre nœud tout en étant toujours fonctionnelle, moyennant quelques minutes d’indisponibilité :

Sauvegarde croisée Mes dataset de sauvegardes créées (Backup1, Backup2, Backup3) et partagées comme pour les dataset de VM, je les active via l’interface web :

Figure 1:Datacenter\Storage\Add\NFS

Explication des options ci-dessus :

ID : nom que je donne à mon partage

Server : ip du serveur ou se trouve le dataset partagé

Export : chemin vers le dataset

Content : ce qu’il contiendra ex : vzdump pour les sauvegardes

NB : En cliquant sur export le menu déroulant doit proposer /rpool/Backup

Page 27: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

26

Toutes ces manipulations ont été effectuées sur chaque nœud (avec les bons noms de dataset).

Ainsi les VM de Prox2 sont sauvegardées sur Prox3 via le dataset partagé dédié Backup3.

Les VM de Prox1 sont sauvegardées sur Prox2 via le dataset partagé dédié Backup2.

Les VM de Prox3 sont sauvegardées sur Prox1 via le dataset partagé dédié Backup1.

Test de sauvegarde La solution de sauvegarde mise en place, j’ai donc réalisé un test afin de m’assurer du bon fonctionnement de la solution en exécutant une tâche de sauvegarde de VM de prox2 vers le stockage partagé Backup3 sur prox3.

Création de la tâche sur Prox2 :

Page 28: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

27

Figure 3: La sauvegarde se lance bien à l’heure voulue et se déroule normalement

Résultat test de sauvegarde :

root@prox3:~# ls -l /rpool/Backup3

total 1

drwxr-xr-x 2 root root 4 May 3 17:41 dump

drwxr-xr-x 2 root root 2 May 3 17:36 images

root@prox2:~# ls -l /rpool/Backup2/dump/

total 2036464

-rw-r--r-- 1 root root 4564 May 3 17:41 vzdump-qemu-102-2018_05_03-17_39_02.log

-rw-r--r-- 1 root root 2111092495 May 3 17:41 vzdump-qemu-102-2018_05_03-17_39_02.vma.lzo

On voit ci-dessus que la vm 102 de prox2 est bien sauvegardée sur prox3

Page 29: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

28

Amélioration des performances : cache des disques sur SSD Afin d’accélérer les accès disques, j’ai mis en place une solution de cache sur disque dédié SSD : lvmcache6.

Mise en place du cache lvmcache J’ai utilisé un disque SSD (nvme0n1) pour en faire un cache en écriture du disque système proxmox, le disque système doit être en ext4. Une vérification via lsblk doit nous indiquer le répertoire racine de proxmox comme VG (pve) :

Avec vgscan :

Créer un volume physique Déclaration de la partition /dev/ nvme0n1 comme volume physique disponible pour LVM :

pvcreate /dev/nvme0n1

Ajout de la nouvelle PV au VG proxmox « pve » déjà existant :

6 Le lvmcache est une solution s’appuyant sur le gestionnaire de volume LVM intégré à debian

Page 30: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

29

Verification:

Créer les LV (Volume Logique) Pour le cache des données :

Pour le cache des metadata :

Associer les 2 LV via un pool Je l’ai nommé « cache pool ».

Page 31: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

30

Je vérifie le résultat via la commande lvs -a -o +devices :

On a bien nos volumes logiques pour le cache associé au Groupe Virtuel pve. On constate qu’ils sont renommés avec un « c » pour cacher (_cdata; _cmeta), comme mentionné dans la documentation red hat7.

Allocation « cache pool » à pve/data La dernière étape consiste à associer le pool de LV créé (cache pool) au LV par défaut de proxmox /pve/data.

Je crée le volume logique de cache en combinant le LV « cache pool » avec le LV d’origine « data » comme ceci :

7 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/LV#lvm_cache_volume_creation

Page 32: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

31

Vérification du résultat via le shell :

Résultat via interface web:

Ces opérations ont dû être répétées pour chaque nœud.

Retour d’expériences Avantages Solution relativement simple à mettre en place moyennant quelques manipulations.

Bonnes performances avec des accès locaux.

Inconvénients Pas de stockage distribué ce qui crée un Single Point Of Failure (stockage partagé sur prox3).

Page 33: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

32

Solution 2 :

Création d’une solution de stockage CEPH

Introduction Ceph est une solution logicielle de stockage distribué indépendante du matériel, évolutive et sans SPOF. Les données sont stockées en tant que volume sous la forme de bloks8 et sont rattachées aux nœuds. Ce qui procure une plus grande capacité de stockage et une grande fiabilité. L’accès aux données en mode block se fait via la couche RBD. RBD gère entre autres les snapshots, le thinprovisionning, le clonage et le copy-on-write.

L’accès aux données se fait via RADOS :

Accès direct depuis une application (proxmox) avec la bibliothèque librados Accès via une API REST grâce à radosgw

Notions importantes Les principaux composants de CEPH :

Monitor (mon) : Surveille et contrôle l’état du cluster, maintient une cartographie de l’état de celui-ci. Ne stocke aucune donnée.

OSD : Stock les données du cluster sur HDD/SSD. Tout est stocké sous forme d’Objets. OSD est responsable de toutes les réplications, restaurations et déplacements de données. Un cluster Ceph nécessite un minimum de 2 OSD pour être en état active+clean.

Journal OSD : Dans Ceph, toutes les E/S le sont d’abord dans un journal avant d’être transférées à l’OSD. C’est une partition plus petite qui n’accepte que des bits de données plus petits à la fois.

PG : Permets de combiner plusieurs objets dans un groupe et de mapper ce groupe vers plusieurs OSD.

Les Pools : Les pools sont comme des partitions logiques ou Ceph stocke les données. Lors de la création d’un Cluster Ceph 3 pools sont créés par défaut : data, metadata, et RBD.

CRUSH (Controlled Replication Under Scalable Hashing) : est un algorithme de répartition des données permettant d’utiliser de manière optimale les ressources et de réorganiser les données en cas d’ajout ou suppression de disques du cluster. La distribution est contrôlée par le Cluster map qui représente les ressources de stockage disponible.

MDS : Il stock les Metadata pour le système de fichier Ceph (CephFS), système de fichiers dont l’utilisation est à éviter pour le moment, car pas complètement standardisé. Les blocs et Objets de stockage Ceph n’utilisent pas MDS.

8 Mode de stockage des données sans système de fichier, référencé par une adresse et pas par des metadata

Page 34: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

33

Récapitulatif sur les composants Ceph Récapitulatif pour comprendre les relations entre chaque composant Ceph présenté plus haut :

Chaque Pool comprend plusieurs PG, chaque PG comprend plusieurs OSD. Une map OSD fait un suivi du nombre d’OSD dans le Cluster et dans les nœuds le composant.

Le map mon fait un suivi du nombre de monitor dans un cluster pour former un quorum et maintenir une copie de la cartographie du Cluster. Une CRUSH map décide combien de données doivent êtres écrite dans un OSD et comment les écrire et les lires.

Ce sont les blocs fondateurs d’un Cluster Ceph.

Le diagramme suivant est un exemple de la manière dont les composants interagissent pour former le système de stockage :

Figure 4 issue de Mastering Proxmox ed Packt

Page 35: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

34

Figure 5 http://docs.ceph.com

Implémentation Prérequis

3 serveurs minimum 2 cartes réseau à 1Gbp/s minimum, une pour l’accès web et console web et une autre dédiée

au cluster. Un lien réseau réservé pour le cluster Ceph CPU d’au moins 4 cœurs Pas de RAID sous-jacent De préférence au moins 1 To de disque si possible SSD De préférence 2 disques minimum par OSD Designer son cluster au regard des E/S et pas de la taille des disques Reboot régulier

Mise en cluster proxmox La mise en cluster est identique à la première solution

Installation de Ceph Installation de ceph sur les 3 nœuds :

root@Ceph1:~# pveceph install –version luminous

Page 36: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

35

Initialisation Pour le nœud Ceph1 en précisant la plage d’adresse du lien pour les synchros Ceph :

root@Ceph1:~# pveceph init –network 172.16.30.0/24

Ce qui crée le fichier de configuration /etc/pve/ceph.conf

Création des monitors Le Ceph manager est installé en même temps

Création via le shell pour le premier sur Ceph1

Puis, via l’interface web proxmox j’ai pu effectuer la création des monitors sur les 2 nœuds suivants pour la redondance :

Ceph2\Ceph\Monitor\Create

Idem sur Ceph3 afin d’avoir le nombre de monitors nécessaires pour un quorum fiable.

Page 37: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

36

Création des OSD Les OSD serviront au stockage des données, chaque OSD nécessite un disque entier.

Les disques doivent être de type GPT pour être visibles par CEPH pour la création des OSD. J’ai donc dû passer mon SSD en GPT :

Figure 6 Avant activation GPT disque SSD non visible dans l’outil de création d’OSD

Modification du disque :

root@Ceph1:~# gdisk /dev/nvme0n1

Mon SSD est maintenant bien en GPT

Une fois le SSD passé en GPT j‘ai pu pointer dessus pour l’emplacement du journal

Page 38: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

37

J’ai effectué la même opération pour le deuxième disque ce qui finalement donne ceci

Page 39: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

38

Comme pour les monitors il a été nécessaire de répéter l’opération sur les 2 autres nœuds y compris l’activation GPT sur le SSD

Pour obtenir ceci :

Création de Pools Pour pouvoir utiliser Ceph pour les VM il a fallu créer 2 pools

Explication des paramètres :

Size : Conteur de réplication (3 pour être efficace)

Min Size : Le nombre min de répliquas de données devant exister pour que le pool fonctionne. Dans notre exemple si plusieurs disques où se trouvent les OSD contenant 2 répliques tombent en panne, le cluster passera hors ligne. Si on le passe à 1 tant que le cluster Ceph voit 1 réplique des données n’importe où dans le cluster et même dans le cas d’une défaillance de plusieurs OSD, le Cluster fonctionnera.

Pg_num : Nombre de PG (combinaison d’OSD) attention au choix, car le chiffre peut être augmenté plus tard, mais pas diminué. Il existe un calculateur afin de déterminer le pg_num approprié, à l’adresse ci-dessous :

https://ceph.com/pgcalc/

Dans mon cas, vu la petite taille de la maquette je laisse le chiffre par défaut qui correspond à une infrastructure de 2 à 6 disques.

Page 40: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

39

Création des stockages :

Création du Stockage au sens de la ressource Proxmox Afin de pouvoir utiliser un pool comme stockage proxmox, il faut l’ajouter via l’interface web. Pour se faire, même procédure que pour un stockage NFS, ZFS ou autre et sélection de RBD (PVE) comme type de stockage puis le pool précédemment créé.

Page 41: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

40

Mise en place de la Haute Disponibilité La procédure reste identique car il s’agit, comme pour la solution précédente, de la Haute Disponibilité intégrée à proxmox.

Test de fonctionnement de la HA J’ai ensuite effectué un test de récupération après défaillance en arrêtant le nœud Ceph1 pour m’assurer que la VM était bien prise en charge sur un des autres nœuds.

Le Test s’est avéré concluant, comme on peut le voir sur les impressions-écrans ci-dessous :

Arrêt de Ceph1

Le fencing se met en place pour éviter l’utilisation de la vm

Transfert et démarrage de la VM sur Ceph2

Page 42: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

41

Retour d’expériences

Avantages Une fois le mécanisme de fonctionnement compris, cette solution n’est pas trop difficile à mettre en place : le système de stockage étant distribué, il n’y a pas de SPOF. Autre avantage, pour étendre un cluster Ceph, il suffit d’ajouter un disque ou un nœud pour qu’il soit détecté et pris en compte. Ceph apporte une solution cohérente, disponible et tolérante au partitionnement9.

Inconvénients Ceph ne semble pas aisé à maintenir du fait du caractère packagé de la solution, en effet en cas de dysfonctionnement il est difficile de savoir quel élément en est la cause et n’agir que sur celui-ci. De même pour l’algorithme CRUSH, qui gère la façon dont les données sont écrites et lues, et sur lequel il est difficile d’agir.

Autre inconvénient, RBD ne peut stocker que des images au format. Raw.

9 Aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement

Page 43: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

42

Solution 3

Partage via le Distributed Replicated Block Device

Introduction La troisième solution consiste en l’implémentation de DRBD solution de stockage distribué qui, sur le principe, se rapproche de Ceph vu précédemment, à savoir que c’est un SDS10 mais non implémenté dans proxmox et installé sur la Debian sous-jacente.

DRBD s’appuie sur des volumes LVM et non pas sur le système de fichier (block device), ce qui permet de faire du stockage distribué de la Haute Disponibilité, des Snapshots et d’ajouter des disques facilement.

La société LINBIT créatrice de DRBD a développé un package dédié pour proxmox afin d’en faciliter l’interaction.

Principe de fonctionnement de DRBD

Figure 7 docs.linbit.com/docs/users-guide-9.0

Comme on peut le voir ci-dessus, DRBD se place entre la couche matérielle et le système de fichier, il ne prend pas en compte le matériel et ne peut donc pas être impacté par une quelconque modification à ce niveau.

DRBD crée un miroir réseau entre 2 nœuds comme un RAID1 qui ne s’appuierait pas une carte contrôleur.

10 Software Defined Storage

Page 44: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

43

Protocoles de synchronisation du miroir DRBD utilise plusieurs protocoles de synchronisation des données pour le mirroring (raid1) :

Asynchrone (A) : les opérations d'écriture sur le nœud primaire sont considérées comme terminées après que les données aient été écrites localement, mais avant la propagation des données au nœud distant.

Semi-synchrone (B) : les opérations d'écriture sur le nœud primaire sont considérées comme terminées après que les données aient été écrites localement et ont été propagées sur le nœud distant, mais avant écriture sur ce dernier.

Synchrone (C) : les opérations d'écriture sur le nœud primaire sont considérées comme terminées après que l'écriture des données ai été effectuée sur le nœud local et sur le nœud distant.

Le choix est donc fait d’utiliser le mode C (synchrone), plus judicieux dans notre cas, pour nos besoins de retour sur incident. En effet avec le mode C en cas de perte d’un des nœuds on est sûr d’avoir une réplique exacte sur le nœud opérationnel.

Les ressources Dans DRBD « ressource » est un terme générique qui fait référence à tout ce qui concerne une donnée répliquée comme un volume, le nom auquel il se rapporte, un device drbd (block). Dans DRBD toutes les ressources ont un rôle qui peut être « primary » ou « secondary ».

Les rôles Il existe deux rôles pour la gestion des ressources, « primary » ou « secondary » Une ressource avec le rôle « primary » peut être utilisée sans restriction en lecture/écriture. Une ressource avec le rôle « secondary » reçoit toutes les mises à jour, mais n’est pas accessible et ne peut être utilisée ni en lecture ni en écriture. On peut définir que les ressources soient en « primary » sur un seul nœud du cluster (Single Primary mode) pour garantir qu’un seul membre du cluster manipule les données, ou sur deux nœuds du cluster (Dual primary mode) afin que deux nœuds puissent indifféremment avoir accès en lecture/écriture aux ressources.

Dans notre cas, étant donné nos besoins en migration de VM, le choix s’est porté sur du « Dual primary mode ».

Page 45: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

44

Mise en place

Prérequis LVM2 installé Drbd-utils installé Au moins deux interfaces réseau

Mise en cluster La mise en cluster est identique aux solutions précédentes.

Création d’un réseau de synchronisation Afin d’isoler la partie synchronisation et échange de données des autres domaines de collisions, je crée un réseau à part, en utilisant l’interface web de Proxmox et l’une des interfaces réseau libre. L’opération est effectuée sur tous les nœuds.

Vérification du réseau de synchronisation Chaque nœud doit pouvoir se connecter aux autres via SSH et ceci sans demande d’authentification et par les adresses du réseau de synchronisation DRBD précédemment créées.

Comme ceci :

root@pves3v1:~# ssh [email protected]

The authenticity of host '172.16.20.152 (172.16.20.152)' can't be established.

ECDSA key fingerprint is SHA256:8PZQRax8jCuF2eda+N0YWYOn1TxrPYWr4rAW0GKq+J8.

Are you sure you want to continue connecting (yes/no)? yes

root@pves2v1:~#

Installation de drbd Avant d’installer drbd il faut installer pve-headers et paramétrer le dépôt linbit pour récupérer DRBD

wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add -

# PVERS=5 && echo "deb http://packages.linbit.com/proxmox/ proxmox-$PVERS drbd-9.0" > \

/etc/apt/sources.list.d/linbit.list

root@pves2v1:~# apt-get update

root@pves2v1:~# apt install pve-headers

root@pves2v1:~# apt-get install --reinstall drbd-dkms

Page 46: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

45

Vérification: root@pves2v1:~# ps -edaf w | grep -i drbd

J’ai pu ensuite installer la solution packagée pour proxmox mais au préalable il a fallu stopper le service drbd

root@pves2v1:~# service drbd stop

root@pves2v1:~# apt-get update && apt-get install drbdmanage-proxmox

J’ai également installé l’outil drbdtop afin de pouvoir visualiser les ressources et l’état de drbd

root@pves2v1:~# apt-get install drbdtop

Il a été nécessaire de désactiver drbd avant d’activer drbdmanaged

root@pves2v1:~# systemctl disable drbd

root@pves2v1:~# systemctl enable drbdmanaged

Création du volume logique LVM Sur chaque nœud, je crée un volume logique qui sera la couche sous-jacente à drdb ainsi que le pool drbd le LV sera créé en thin provisionning.

Création au préalable du device /dev/sdb1 à partir duquel sera créé le volume

root@pves1v1:~# fdisk /dev/sdb

n,p,1,w

Création du pool avec comme nom drbdpool comme conseiller par linbit

vgcreate drbdpool /dev/sdb1

Physical volume "/dev/sdb1" successfully created.

Volume group "drbdpool" successfully created

Création du volume logique en thinprovisionning

root@pves1v1:~# lvcreate -L 10G --thinpool drbdthinpool drbdpool

Using default stripesize 64.00 KiB.

Logical volume "drbdthinpool" created.

Page 47: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

46

Initialisation L’initialisation se fait sur le nœud principal sur lequel les autres se rattacheront et qui sera utilisé pour stocker la configuration du cluster de manière redondante. Pour effectuer l’initialisation, l’adresse IP utilisée pour le réseau de synchronisation DRBD doit être préalablement créée.

root@pves1v1:~# drbdmanage init 172.16.20.15111

Ensuite sur chaque nœud, à l’exception de ceux qui ne contiendront pas de stockage, j’ai repris les opérations effectuées depuis le chapitre « Installation de drbd » jusqu’à « Création du volume logique LVM » inclus.

Ajout du Storage dans proxmox Afin que proxmox prenne en compte le storage DRBD il a fallu modifier le fichier /etc/pve/storage.cfg

Ajouter au fichier les lignes suivantes :

dir: local

path /var/lib/vz

content iso,vztmpl,backup

lvmthin: local-lvm

thinpool data

vgname pve

content rootdir,images

drbd: drbdstorage

content images,rootdir

redundancy 3

NB : Redundancy 3, car 3 nœuds dans le cluster proxmox

11 Adresse de synchronisation drbd de pves1v1

Page 48: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

47

Résultat via la console web :

Avant Apres

Ajout des Nœuds au cluster Une fois le cluster créé j’ai ajouté un nœud supplémentaire pour obtenir un stockage distribué, car il ne comportait que celui d’initialisation. Comme on peut le voir ci-dessous grâce à l’outil drbdtop :

Pour être sûr que le nom du nœud à ajouter soit bien reconnu par la commande d’ajout, il faut s’en assurer via uname –n . J’ai donc ajouté le nœud pves2v1 pour être mon nœud de stockage secondaire, en utilisant l’adresse de synchronisation DRBD du nœud à ajouter :

root@pves1v1:~# drbdmanage add-node pves2v1 172.16.20.152

Operation completed successfully

Executing join command using ssh.

IMPORTANT: The output you see comes from pves2v1

IMPORTANT: Your input is executed on pves2v1

You are going to join an existing drbdmanage cluster.

Confirm:

yes/no: yes

Waiting for server to start up (can take up to 1 min)

Operation completed successfully

Give leader time to contact the new node

Operation completed successfully

On voit ici pourquoi les tests de connexion SSH vus plus haut sont nécessaires

Page 49: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

48

J’ai ainsi obtenu 2 nœuds dans le cluster DRBD12

Ces nœuds sont : l’un en primary, celui ou c’est fait l’initialisation,

Et l’autre en secondary, le nœud ajouté

Ajout d’un nœud satellite Les nœuds satellites n’ont pas d’accès direct au volume control (pves1v1), ils reçoivent une copie de la configuration via TCP/IP, ils ont un stockage local si ce sont des « satellites normaux » et pas de stockage du tout si ce sont des « satellites clients ».

Dans mon cas, j’ai donc installé un satellite client, car le but est d’avoir la configuration à jour, mais pas de stockage, ce qui permet d’utiliser ce nœud comme une sorte de parité pour mon miroir. Si l’un de mes nœuds devait être hors service, il serait possible de s’appuyer sur ce nœud client pour repartir.

Ajout de pves3v1 comme nœud client

root@pves1v1:~# drbdmanage add-node --satellite --no-storage pves3v1 172.16.20.153

Operation completed successfully

Executing join command using ssh.

Give leader time to contact the new node

Operation completed successfully

J’ai ainsi pu finaliser mon cluster DRBD

12 Commande drbdmanage list-nodes

Page 50: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

49

Paramétrage du protocole de synchronisation Le fichier qui gère la configuration du cluster DRBD est « global_common.conf » se trouve dans « /etc/drbd.d/ ». J’ai modifié ce fichier sur les 2 nœuds de stockage afin qu’il prenne en compte le mode synchrone que je souhaite pour mon cluster. Cela permettra d’avoir une copie exacte des 2 côtés en cas de panne. Dans la section « net » du fichier, j’ai ajouté protocole C13

net {

protocole C;

Problème rencontré Lors de la phase d’initialisation j’ai eu un échec avec le message suivant :

Solution J’ai effectué un upgrade de la 5.2-1 à la 5.2-2

# apt upgrade (sur tous les nœuds)

Ce qui n’a résolu que partiellement le problème : L’initialisation s’est faite, mais pas l’accès aux ressources, car j’avais initialisé avant l’ajout du Storage DRBD, comme mentionné dans la documentation LINBIT, or il s’avère qu’il faut faire l’inverse14 .

Tests

Scénario n°1 Maintenance programmée d'un nœud : Le premier cas de test a pour but de vérifier l'état des services lors d'une maintenance programmée sur un nœud. Ce cas peut apparaitre, lors de mises à jour du noyau par exemple. Ainsi, il est nécessaire de migrer les machines virtuelles vers un autre nœud. Deux démarches sont possibles : la migration à froid ou à chaud des machines virtuelles. Étant donné qu'on dispose d'un stockage distribué, et voulant assurer une disponibilité maximale des services, les machines virtuelles seront migrées sans arrêter leur fonctionnement. Ce test est réalisé très simplement à travers l'interface Proxmox : le seul paramètre à indiquer est le nœud hôte cible.

13 Synchrone 14 Erreur reproduite plusieurs fois pour confirmation

Page 51: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

50

Scénario n°2 Arrêt d'urgence d'un nœud :

L'objectif de ce test est de vérifier la migration automatique des machines virtuelles. On peut simuler un tel scénario en étudiant le comportement de la machine lors de l'arrêt brutal (shutdown now) ou le redémarrage du nœud ; les machines virtuelles étant gérées par la HA via le service pve-hamanager.

Scénario n°3 Arrêt brutal d'un nœud : Une coupure électrique peut subvenir, j’ai donc simulé une panne électrique via la console web de proxmox.

Retour d’expériences

Avantages C’est une solution qui n’est pas trop difficile à mettre en place, Système de stockage distribué et donc pas de SPOF.

Pour étendre un cluster DRBD, il suffit d’ajouter un nœud via l’outil drbdmanage après l’avoir intégré au réseau dédié et il sera détecté et pris en compte par le Cluster.

Inconvénients La documentation est fournie mais mal faite, par exemple il n’est pas fait mention du thinprovisionning et comme mentionné plus haut, l’ordre des actions à effectuer pour l’initialisation est inversé. DRBD n’étant pas intégré à Proxmox, ce dernier n’en assure pas le support, il faut définir que le problème vient de DRBD et dans ce cas se tourné vers LINBIT et vice versa.

RBD ne peut stocker que des images au format. Raw, pas les .cqow2 de qemu.

Page 52: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

51

Solution retenue

La première solution est la plus simple, mais ne permet pas de stockage distribué, contrairement au stockage Ceph qui reste la solution la plus complexe à maintenir avec les compétences sur site.

La partie intéressante de l’erasure coding15 de CEPH ne satisfaisait pas les critères de stabilité et de preuve de bon fonctionnement pour l’ingénieur sur site.

Sylvain Maurin a opté pour DRBD qui s’appuie sur des technologies qui ont fait leurs preuves notamment LVM et le modèle par couche des périphériques en mode block de Linux, mais apporte les avantages des 2 autres :

pas de SPOF

bonne compréhension des mécanismes et des codes sous-jacents

utilisation d’un modèle de stockage distribué.

Cette solution est faite de plusieurs briques bien différenciées (module client/serveur dans le kernel, outils de gestion en couche basse drbdsetup/drbdadm et outils d’administration de haut niveau drbdmanager/linstor).

Elle favorise une meilleure visibilité du fonctionnement de chaque module et permet d’aller rapidement explorer les sources et les modifier en cas de problème.

Nous avons mis en place DRBD qui forme par design, un RAID1 réseau. Dans notre cas, il s’appuie sur les disques SSD des deux RAID6 (un par nœud) d’une capacité de 1.7 To chacun pour stocker les données (image VM). Les 2 autres nœuds ne sont que clients DRBD et ne stockent donc que la configuration et aucune donnée, mais communiquent avec le cluster et en font partie. Leur rôle principal est d’agir comme une double parité.

A chaque lecture de l’un des quatre nœuds on accède à l’un des deux nœuds en SSD, à chaque écriture. Par contre, comme il s’agit d’un RAID1, on écrit sur les 2 nœuds SSD et on ne dispose de ce fait que de la moitié de la bande passante.

Ces 2 nœuds clients, qui reposent également sur du RAID 6 mais SAS avec une capacité de 7 To chacun, vont être utilisés indépendamment du DRBD, à des fins de stockage de Backup ainsi que pour les VM volumineuses ou accédées principalement en lecture.

Ce qui nous permet ainsi d’avoir de la haute disponibilité, de la redondance, un système de sauvegarde (mais non croisée, comme prévu à l’origine du projet) et ainsi d’assurer une résilience optimale du système.

15 Méthode de contrôle d’erreur

Page 53: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

52

Mise en place

Configuration matérielle DELL PowerEdge C6420 composé de 4 slots correspondants à 4 serveurs Chaque Slot est composé de : 1 Carte contrôleur H730P 6 barrettes de RAM 8 Go RDIMM 2 Processeurs Intel Xeon Silver 1 DRAC iDRAC 9 2 Carte réseau 10 Gb/ 1 Carte réseau 1 Gb/s

Organisation des Disques : Les slots 1 et 2 sont organisés ainsi :

6 SSD SATA 480Go (Intel S4600) RAID 6 PERC /sda: 49.75 Go(50GB) pour le système /sdb: 1.7 To pour les Données (VM)

Et les slots 3et4 comme ceci :

6 HDD SAS7200RPM 2To RAID 6 PERC /sda: 49.75 Go(50GB) pour le système /sdb: 7.23 To pour les Données (Backup VM)

Paramètre des interfaces dédiées iDRAC Afin de pouvoir prendre la main pour la maintenance des serveurs, ceux-ci étant sur un site distant, un paramétrage d’IP a été effectué pour les 4 DRAC embarquées16, chacune disposant d’un port dédié à 1 Gb/s.

Pour le slot 1 : pves1rac.isc.cnrs.fr has address 192.168.0.212

Pour le slot 2 : pves2rac.isc.cnrs.fr has address 192.168.0.213

Pour le slot 3 : pves3rac.isc.cnrs.fr has address 192.168.0.210

Pour le slot 4 : pves4rac.isc.cnrs.fr has address 192.168.0.211

16 1 par serveur

Page 54: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

53

Pré installation Il a fallu tout d’abord paramétrer les disques, pour correspondre à l’organisation vue plus haut, en terme de RAID matériel, ceci en utilisant les DRAC.

Sur chaque RAID un volume de 50 Go est créé pour accueillir le système. Un volume constitué du reste de l’espace disque disponible accueille les données, ce qui représente 1.7 To sur le volume DATA du RAID SSD pour les nœuds « DRBD Controler » et 7.23 To sur le Volume DATA du RAID SAS pour les sauvegardes et les VM volumineuses. Le réseau dédié est également créé et utilise les interfaces 10 Go pour la synchronisation et les échanges du cluster drbd.

Installation Proxmox

Paramètre des interfaces 1Go pves1v2.isc.cnrs.fr has address 192.168.0.204

pves2v1.isc.cnrs.fr has address 192.168.0.205

pves3v1.isc.cnrs.fr has address 192.168.0.206

pves4v1.isc.cnrs.fr has address 192.168.0.207

Politique de nommage des nœuds du cluster

Pves1v1 : pour proxmox ve, slot qu’occupe le serveur, version du nom de nœud

L’ajout au nom de la version du nom de nœud va permettre, en cas de besoin de sortie provisoire du cluster, de renommer celui-ci pour éviter un quelconque problème lors de sa réaffectation au cluster. Dans ce cas, la configuration du cluster garde une trace du nom et la réaffectation échoue.

Paramètres disque système Sélection du volume de 50 Go créé précédemment pour l’installation du système via l’interface d’installation de proxmox

ext4 FS , max root = 50GB, min vz = 2GB

Procédure de migration du cluster

Après l’installation sur chaque serveur de proxmox ve 5.1.3, il a fallu les mettre en cluster et qu’ils récupèrent les VM de l’existant.

Mais plutôt que de créer un Cluster et de faire une récupération compliquée des VM du cluster historique vers le nouveau, l’idée a été d’ajouter nos quatre nouveaux serveurs pves1v1, pves2v1, pves3v1 et pves4v1 au cluster existant comprenant pve4, pve5 et pve6.

Puis, selon le principe des vases communicants, de migrer les VM vers nos nouveaux nœuds et pour finir de retirer les nœuds historiques du cluster et mettre en place DRBD.

Page 55: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

54

Problèmes rencontrés 1er problème Pve6 étant tombé en panne récemment, il ne reste plus que 2 nœuds. Il n’y a donc plus de quorum car le cluster attends 3 nœuds et empêche l’ajout de pves1v1 au cluster car le fichier corosync.conf passe en lecture seule.

Solution apportée Paramétrage du cluster pour qu’il n’attende que 2 nœuds :

root@pve5# expected 2

Suppression de pve6 du cluster

root@pve5# delnode pve6

Remise en place des paramètres de cluster

root@pve5# expected 3

2e problème Une fois pve6 retiré et le quorum remis en place, il y a encore un problème d’ajout de pves1v1. Après vérification il s’avère que le nouveau nœud n’a pas son horloge synchronisée avec le cluster.

Solution apportée Paramétrage du serveur NTP de l’ISCMJ sur pves1v1 et les 3 autres nouveaux serveurs.

3e Problème Après vérification avec TCPdump17 il s’avère que le multicast nécessaire à la synchronisation du cluster ne passe pas, l’un des switch de l’ISCMJ semble avoir la fonction désactivée.

Solution apportée Afin de ne pas perdre de temps, le reste du paramétrage se fait directement au data-center, du centre de calcul à l’emplacement cible du cluster.

Des recherches seront faites ultérieurement, concernant le problème de Multicast sur l’ISCMJ, cela n’étant pas impactant pour la production.

17 Analyseur de paquet en ligne de commande

Page 56: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

55

4e problème Maintenant pves2v1 est bien dans le cluster. pve4, 5 et 6 n’y sont plus, mais pve6 qui était déjà HS est toujours visible via le GUI alors que cela ne devrait pas être le cas. La commande pvecm status renvoie bien uniquement pves2v1 comme membre du cluster et un quorum à 1 et à l’inverse pves1v1 est ajouté au cluster, mais pas accessible via le GUI (vue comme inactif). Le problème semble venir, entre autres, d’une différence de version entre les nœuds.

Solution apportée Pves2v1 est donc upgradé de la 5.1 à la 5.2.1 et pves1v1 réinstallé en version 5.2.1, mais renommé en pves1v2 afin d’éviter tout risque de conflits liés au nom (d’où l’intérêt d’intégrer une notion de version dans la politique de nommage).

Maintenant que nous avons bien pves1v2, pves2v1, pves3v1 et pves4v1 dans notre cluster proxmox, nous passons à la phase suivante qui est l’implémentation de DRBD dans la solution.

Implémentation de DRBD

LINBIT le créateur de drbd fournit une solution packagé drbd pour proxmox installable via un dépôt dédié.

Procédure Le module drbd9 pour le noyau étant un package dkms18, pve-headers19 doit être installé afin d’être sûr de la compatibilité avec le noyau de notre version de proxmox.

Installation de pve-header:

root@pves2v1:~# apt-get install pve-headers-4.13.13-2-pve

ou

root@pves2v1:~# apt-get install pve-headers-$(uname -r)

Synchronisation de l’horloge sur chaque nœud

root@pves2v1:~# apt install ntp ntpdate

root@pves2v1:~# service ntp stop

Add server ntp.isc.cnrs.fr

root@pves2v1:~# ntpdate ntp.isc.cnrs.fr

root@pves2v1:~# service ntp start

root@pves2v1:~# ntpq -c peers

18 framework utilisé pour la création de modules du noyau Linux, dont les sources ne résident pas dans celles du noyau. 19 Bibliothèque proxmox

Page 57: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

56

Paramétrage du dépôt

root@pves2v1:~# wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add -

root@pves2v1:~# PVERS=5 && echo "deb http://packages.linbit.com/proxmox/ proxmox-$PVERS drbd-9.0" >/etc/apt/sources.list.d/linbit.list

Paramétrage des interfaces dédiées Afin d’assurer des échanges et synchronisations du cluster drbd optimal, il est nécessaire de créer un sous réseau dédié.

Depuis le GUI proxmox nous paramétrons les interfaces qui serviront au réseau dédié pour la synchronisation de drbd.

Masque : 192.168.100.240/28

.241 Interco pves1

.242 Interco pves2

.237 Interco pves3

.238 Interco pves4

Une vérification de connexions via ssh en utilisant ce réseau dédié est nécessaire, car c’est ce qu’utilise DRBD pour l’ajout des nœuds au cluster et pour les échanges. Il faut donc que les adresses soient atteignables via SSH et bien sûr, sans demande de mot de passe.

Via un script:

root@pves2v1:~# for HOSTPVE in pves1v2 192.168.100.241 pves2v1 192.168.100.242 pves3v1 192.168.100.237 pves4v1 192.168.100.238; do ssh $HOSTPVE 'echo $HOSTNAME' ; done

Ou manuellement, une adresse après l’autre.

Installation de drbd root@pves2v1:~# apt-get update

root@pves2v1:~# apt-get install --reinstall drbd-dkms

Verification:

root@pves2v1:~# ps -edaf w | grep -i drbd

root 3170 1725 0 18:54 pts/0 S+ 0:00 grep -i drbd

root@pves2v1:~# apt-get purge drbdmanage

Page 58: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

57

Nous pouvons maintenant installer la solution packagée pour proxmox, mais au préalable il faut stopper le service drbd

root@pves2v1:~# service drbd stop

root@pves2v1:~# apt-get update && apt-get install drbdmanage-proxmox

Nous installons également l’outil drbdtop qui nous permet d’afficher l’état des ressources et des status drbd

root@pves2v1:~# apt-get install drbdtop

Il est nécessaire de désactiver drbd avant d’activer drbdmanaged

root@pves2v1:~# systemctl disable drbd

root@pves2v1:~# systemctl enable drbdmanaged

Mise en place du cluster DRBD

Après avoir installé DRBD il faut paramétrer un espace de stockage de taille égale sur chaque nœud, et indépendant de DRBD, ce sera le périphérique de stockage de bas niveau pour les ressources DRBD.

Pour ce faire nous utiliserons LVM pour créer un volume logique.

Création du volume logique LVM J’ai créé le volume logique qui est la couche sous-jacente à drdb ainsi que le pool drbd le LV qui lui est créé en thinprovisionning20

root@pves2v1:~# pvcreate /dev/sdb

root@pves2v1:~# vgcreate drbdpool /dev/sdb

root@pves2v1:~# lvcreate -L 1.6T --thinpool drbdthinpool drbdpool

Initialisation J’ai dû paramétrer le Storage proxmox pour DRBD avant l’initialisation sinon cela ne fonctionnait pas, pour ce faire, il m’a suffi de modifier le fichier /etc/pve/storage.cfg21

root@pves2v1:~# service drbdmanaged start

20 Avec le thin-provisionning les 10 Go sont virtuels et l’espace occupé n’est que de celui réellement utilisé jusqu‘à atteindre la taille mentionnée (10Go dans notre exemple). 21 Voir la rubrique concernée dans le chapitre Solution 3

Page 59: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

58

A partir de là, l’initialisation sur le nœud principal sur lequel les autres se rattacheront et d’où la synchronisation de la configuration sera effectuée, a pu se faire.

L’adresse IP utilisée dans la commande doit être celle créée pour le réseau de synchronisation DRBD.

Cette manipulation est à effectuer sur un seul nœud.

# drbdmanage init 192.168.100.23722

Ensuite sur chaque nœud, à l’exception de ceux qui ne contiendront pas de stockage, nous reprenons les opérations effectuées depuis le chapitre « Installation de drbd » jusqu’à « Création du volume logique LVM » inclus.

Ajout des Nœuds au cluster Depuis le nœud principal uniquement et pour les nœuds prévus pour contenir le stockage :

root@pves2v1:~# drbdmanage add-node pves4v1 192.168.100.242

Paramétrage des nœuds satellites Les nœuds satellites sont des nœuds clients qui exécutent les commandes, mais ne stockent pas de données.

root@pves3v1:~# apt-get update

root@pves3v1:~# apt-get install --reinstall drbd-dkms

root@pves3v1:~# apt-get purge drbdmanage

root@pves3v1:~# # service drbd stop

root@pves3v1:~# apt-get update && apt-get install drbdmanage-proxmox

root@pves3v1:~# systemctl disable drbd

root@pves3v1:~# systemctl enable drbdmanaged

Ensuite, depuis le nœud principal :

root@pves2v1:~# drbdmanage add-node --no-storage pves3v1 192.168.100.24123

22 Adresse de synchronisation drbd de pves1v2 23 « pves3v1 192.168.100.241 » identifie le nœud client

Page 60: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

59

Test Un test de migration de VM d’un nœud à l’autre s’est avéré concluant et plus rapide qu’avec la solution sur stockage ZFS avec partage NFS. Un test de migration à chaud, pendant une installation d’OS sur une VM, a montré qu’il n’y avait aucune interruption de l’installation pendant la migration.

Benchmark Les tests de latence montrent une nette amélioration par rapport à l’infrastructure historique puisque nous obtenons les résultats suivant à l’aide des outils dd et mbuffer :

Test en Lecture:

dd if=/dev/sdb of=/dev/null bs=1M count=8000

8388608000 bytes (8.4 GB, 7.8 GiB) copied, 3.29839 s, 2.5 GB/s

Test en écriture:

dd if=/dev/zero of=test bs=1M count=8000; sync | mbuffer

2806812672 bytes (2.8 GB, 2.6 GiB) copied, 3.50317 s, 801 MB/s

Migration des VM

Les VM placées provisoirement sur pves3v1, pour des besoins de migration de cluster proxmox, ont pu être migrées manuellement pour les quelques VM qui ont rejoint le stockage NFS sur le serveur hanfs.

Pour toutes les autres qui sont prises en charge par DRBD, la migration s’est faite en masse vers pves2v1 via un script bash, faisant appel à l’API REST intégré à l’interface web proxmox.

Ainsi, on peut utiliser les outils de lignes de commandes pour effectuer la migration via l’API web. Les données des VM ont été déplacées du répertoire partagé en NFS sur le serveur hanfs vers Le stockage DRBD.

Page 61: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

60

Protection contre le Split Brain

Le split brain survient lorsque des modifications sont faites sur un nœud, mais pas répliqué sur les autres, ceci à cause d'une microcoupure réseau, une erreur humaine etc ... Toute modification sur les données, après un tel incident, n’est pas répliquée.

On a donc des configurations différentes sur chaque nœud, sans possibilité de les fusionner.

Cette situation risque d’autant plus d’arrivé lorsque le cluster DRDB est configuré en Dual primary24, comme dans notre cas.

Afin de pallier à ce type de problème une procédure est mise en place25.

Mise en place de la solution de sauvegarde

Comme précisé en introduction, les sauvegardes vont se faire sur pves3v1 et pves4v1 via un partage NFS sur ZFS.

La mise en place est identique à ce que j’ai effectué lors de la première maquette, à ceci près qu’il ne sera pas possible de faire des snapshots car DRBD ne gère pas les extensions « qcow2 » de qemu et crée des «. raw ».

Une sauvegarde hebdomadaire est également prévue sur le serveur de stockage historique hanfs, son partage NFS étant disponible.

Coût Toute l'infrastructure étant fondée sur des logiciels libres, le coût de cette migration se limite au prix des serveurs et à l’achat d’une maintenance proxmox et LINBIT, ce qui avoisine les 2000 euros/an. Comparativement à une solution propriétaire :

VmWare Vsphere : 30 000 euros + 3000 euro/user du IT/an

Microsoft Hyper-V : 3000 euro/nœud pour 3 ans + 2 euros de CAL/mois/utilisateur ;

24 Voir : https://docs.linbit.com/docs/users-guide-9.0/#s-enable-dual-primary 25 Voir annexe « ProcédureSplitBrain »j

Page 62: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

61

Bilan

La migration a, au final, pris plus de temps que prévu. Le planning prévisionnel ayant été dépassée d'une semaine suite à quelques imprévus comme la défaillance du nœud qui devait me servir de bac à sable, pour n'en citer qu'un, mais également parce qu'il m'a fallu plus de temps que prévu pour appréhender les diverses technologies mises en œuvre.

Nous avons également été pressés par le temps, car le nœud défaillant mentionné précédemment commençait à avoir de plus en plus d’effets néfastes sur la production, ce qui a mobilisé toutes les ressources et ralentit le projet.

Pour accomplir ma mission, j’ai eu à ma disposition un serveur DELL PowerEdge EMC R640 afin de réaliser toutes les VM nécessaires à mes tests, et un poste fixe afin de pouvoir me connecter à proxmox, au web et pouvoir rédiger.

Les chercheurs à l’ISCMJ sont de diverses nationalités. Mr Bimbi, membre de l’équipe informatique, étant Italien, la langue la plus usitée lors de nos divers échanges était l’anglais. Même si au départ se fut un facteur limitant pour la compréhension des tenants et des aboutissants des sujets abordés, cela m’a permis d’améliorer mon anglais.

Ayant principalement travaillé en environnement propriétaire par le passé, j’avais quelques inquiétudes quant à l’efficacité, les possibilités, la robustesse d’une solution libre. Surtout du fait qu’elle soit gratuite, car une telle solution nécessite des coûts importants de développement. Ces quelques doutes ont été vite balayés aux vues des possibilités qu’offre une telle solution et en deux mois et demi, je suis bien évidemment loin d’en avoir fait le tour.

Finalement ce stage m'a offert l'opportunité de découvrir une solution de virtualisation libre et performante, offrant de nombreuses options, mais également plusieurs technologies de stockages aussi passionnantes les unes que les autres, ce qui a été une vraie chance pour moi.

Page 63: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

62

Conclusion Face aux risques de dégradation de service liée à l’ancienneté des serveurs de la solution de virtualisation en place, le responsable informatique de l’ISC a souhaité profiter de leur remplacement programmé pour étudier les possibilités de l’optimiser. C’est la mission qui m’a été confiée. Ces améliorations potentielles se devant de rester dans un cadre précis que sont le maintien de la solution de virtualisation existante, un stockage des VM partagé et une sauvegarde croisée. L’objectif de ma mission étant de déterminer les axes d’améliorations possibles. Dans un premier temps, j’ai pris connaissance du contexte en m’intéressant en premier lieu à l’environnement de l’ISC, à son organisation informatique puis à sa solution de virtualisation. J’ai découvert un environnement de virtualisation Proxmox efficace et performant à l’instar de solutions plus connues comme vSPhere ou Hyper-V, mais fait de modules dont certains sont développés par d’autres sociétés, son modèle étant l’OpenSource. La société Proxmox intègre ces outils libres, en fonction de leur pertinence avec sa solution de virtualisation. Ce mode de fonctionnement permet d’avoir une solution compétitive, stable et moins coûteuse qu’une solution propriétaire mais ne permet pas une visibilité à moyen terme sur son développement et sa pérennité due à la multiplicité des acteurs. Compte tenu du champ d’action qui était imposé, ma recherche s’est portée sur trois technologies de stockage compatibles avec proxmox : Une solution comprenant un stockage partagé via NFS sur l’un des serveurs pour lui-même et les trois autres, Stockage utilisant un système de fichier ZFS. Une solution composée d’un stockage CEPH distribué. Et une troisième utilisant un stockage également distribué mais utilisant DRBD. A l’issue de ces recherches et des tests qu’elles ont nécessité, le choix s’est porté sur les deux solutions basées sur du stockage distribué : elles évitent les risques de tous perdre, les données n’étant pas sur un serveur en particulier mais synchronisé sur tous. A partir de là, le choix s’est fait sur des considérations de ressources, car la mise en place d’une nouvelle technologie nécessite du personnel formé à celle-ci afin de la maintenir, mais également de reconnaissance : à t’elle fait ses preuves ? Autre élément important dans le choix de la technologie adoptée : la pérennité de celle-ci. Quid de son maintien par l’éditeur à moyen ou long terme ? Son évolution future permettra-t-elle toujours son intégration à proxmox ou nécessitera-t-elle une refonte complète de la solution et de ce fait des coûts supplémentaires ? Finalement, l’ingénieur système a opté pour DRBD plutôt que CEPH, notamment pour la question des ressources, ayant lui-même déjà une expertise sur la solution DRBD. Par ailleurs, des améliorations sont envisageables à moyen et long terme. La solution retenue créant un RAID1 entre deux serveurs, le goulet d’étranglement se situe donc principalement sur le lien réseau qui sert à la synchronisation entre les nœuds DRBD. Par exemple, l’ajout de cartes réseau Infiniband26 pourrait en améliorer grandement le débit. D’autre part, Proxmox semble avoir pour politique de favoriser CEPH, qu’elle a d’ailleurs intégré dans son interface, ce qui laisse à penser que c’est une solution pérenne, qui pourrait à long terme remplacer DRBD dans la solution mise en place.

26 Interface réseau haut débit (40 Go/s) à faible latence du fait entre autre d’une pile de protocole IP allégé

Page 64: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

63

Glossaire

Cluster Un cluster est un ensemble de serveurs travaillant de concert et gérables comme un seul

Corosync Utilisation de corosync pour la communication du groupe constitué de 3 à plus de 32 nœuds

La configuration corosync se trouve dans le fichier /etc/pve/corosync.conf

Ce fichier joue un rôle central dans un cluster proxmox car il contrôle les membres de ce cluster et son réseau

Vérification de l’état via systemctl status corosync

Vérification du journal journalctl –b –u corosync

Corosync synchronise un système de fichiers distribués stockant les états du système pour tous les services PVE, il utilise l’algorithme votequorum pour geler les modifications en bloquant les écritures en cas de défaillante d’un ou plusieurs membres du cluster.

Dataset Les dataset sont des systèmes de fichier ou des volumes logiques équivalents aux volumes (lv) de LVM dans un zpool ZFS.

DRBD (Distributed Replicated Block Device) Architecture de stockage distribué permettant la réplication de périphériques en mode « block » au sens des types fichiers UNIX comme des disques, partitions, volumes logiques... etc. au travers d’un réseau informatique.

Fencing Lorsqu’un nœud tombe en panne, le fencing s’assure que le nœud défectueux soit bien hors ligne ceci afin de garantir qu’aucune ressource ne soit utilisée sur 2 nœuds en même temps lors de la remise en service du nœud défaillant ce qui pourrait causer la destruction des VM (de par la mise en commun sur deux OS d’un même support des données).

Haute Disponibilité La haute disponibilité permet de déplacer les ressources (VM dans notre cas) d’un nœud en panne vers un autre nœud du cluster et ceci de manière automatique.

iDRAC (integrated Dell Remote Access Controller) Option sur les serveurs Dell PowerEdge, elle permet de déployer, mettre à jour, surveiller et entretenir les serveurs Dell PowerEdge indépendamment de l'OS installé.

Nœuds Appellation des serveurs composant un Cluster

Page 65: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

64

Qemu Hyperviseur open source utilisé par proxmox pour créer et gérer les VM.

Quorum Proxmox VE utilise une technique basée sur quorum pour garantir la cohérence de l’état entre les nœuds du cluster. Un Quorum est un nombre minimum de votes qu’une transaction distribuée doit obtenir pour être autorisée à effectuer une tâche. Proxmox VE assigne par défaut un vote unique à chaque nœud. En cas de perte du Quorum le cluster passe en mode lecture seul. Le quorum s’effectue via un algorithme (votequorum) qui s’assure que chaque nœud du cluster est présent en maintenant des échanges des preuves de vie sur des flux multicast IP auxquels chaque nœud est abonné. RAIDZ C’est un raid logiciel ZFS à multiples niveaux de correction d’erreurs supportant de 1 à 3 médias de perte d’information.

Snapshot Sauvegarde à un instant T dans l’état, par exemple d’une VM.

ZFS Combinaison à la fois d’un système de fichiers et d’un gestionnaire de volumes logiques.

Il est évolutif et comporte de nombreuses protections contre la corruption de données, il possède également une très importante capacité de stockage, car contrairement aux systèmes de fichiers classiques basés sur 64 bits, ZFS est un système de fichiers 128 bits.

Sa partie gestion de volume lui permet de faire du raid logiciel (raidz) et du contrôle d’erreur (utilisation des « erasure code »sur les données).

Page 66: D ] P ] } v o } o µ ] } v À ] µ o ] ] } v · í î D µ P W ] v u ] v u ] } v ^ } o µ ] } v }

65

Annexes

Topologie de la solution adoptée de sauvegarde Topologie de la solution adoptée de stockage Gantt du réalisé Procédure split brain

Ressources

Pour Proxmox :

https://pve.proxmox.com/pve-docs/pve-admin-guide.html

MASTERING_PROXMOX_THIRD_EDITION par Wasim Ahmed aux éditions Packt

Pour ZFS

https://pthree.org/2012/12/04/zfs-administration-part-i-vdevs/

https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/gamtu/index.html

https://www.snia.org/sites/default/orig/sdc_archives/2009_presentations/monday/JeffBonwickzfs-Basic_and_Advanced.pdf

Pour NFS :

http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-fr-4/s1-nfs-server-export.html

Pour Ceph :

http://docs.ceph.com/docs/luminous/start/hardware-recommendations/

https://pve.proxmox.com/pve-docs/pve-admin-guide.html

https://www.redhat.com/en/technologies/storage/ceph

https://ceph.com/wp-content/uploads/2016/08/weil-thesis.pdf

Pour DRBD :

https://docs.linbit.com/docs/users-guide-9.0


s µ ] o o Ì o ] } v v o [ v ] u ]...s µ ] o o Ì ] v o ] µ } µ u v s µ ] o o Ì o ] } v v o [ v ] u ] u î ì í õ E } v r v ] o µ o ]

s µ ] o o Ì o ] } v v o [ v ] u ]...s µ ] o o Ì ] v o ] µ } µ u v s µ ] o o Ì o ] } v v o [ v ] u ] u î ì í õ E } v r v ] o µ o ]

v v µ ] ( u ] v ] v µ D o ] W o } u u µ v / µ ] ] u l }

v v µ ] ( u ] v ] v µ D o ] W o } u u µ v / µ ] ] u l }

v } o [ u u ] ] } v v v ] µ ] À ] o ] u } o } } ] o µ v µ ...

v } o [ u u ] ] } v v v ] µ ] À ] o ] u } o } } ] o µ v µ ...

c ] o µ v P ] v ] P ] o v t o ^ o , µ ( } µ v P ( º ^ Z µ o · ] ( ( X ] P ] o

c ] o µ v P ] v ] P ] o v t o ^ o , µ ( } µ v P ( º ^ Z µ o · ] ( ( X ] P ] o

D /dK W Y µ o ] o o [ ] v P v u v } o } v ] µ } o u ] P o ...€¦ · W } P Ì ] } v U u ] v } ] ( ( µ ] } v ] µ u v ] o À ] ( ] À o µ Ì ] } v P o ] o µ v v ] X

D /dK W Y µ o ] o o [ ] v P v u v } o } v ] µ } o u ] P o ...€¦ · W } P Ì ] } v U u ] v } ] ( ( µ ] } v ] µ u v ] o À ] ( ] À o µ Ì ] } v P o ] o µ v v ] X

E Á o v D ] v ^ µ ] v v ] o o µ Ç } o ] ^ Z v ] X...d Z ] o o µ } v ] v Z ] } } l u Ç } ] ( } µ } v o µ } X D } ] o K ] o E Á o v > ] u ] } À ] ( µ v ( } } u u µ v ] Ç

E Á o v D ] v ^ µ ] v v ] o o µ Ç } o ] ^ Z v ] X...d Z ] o o µ } v ] v Z ] } } l u Ç } ] ( } µ } v o µ } X D } ] o K ] o E Á o v > ] u ] } À ] ( µ v ( } } u u µ v ] Ç

CONSTRUCCIîN...> }o]u v ] v µ }v} ]u] v } µu]u } v ]U Z_ µ ]vÀ] ] (} u À µv } o } v o}]v ] µ U (} u o µ } ] v(} o o} v ] }V ^ o Àoµ ] v µ o]Ì o ]v] ]} µ v ] ] Ç µ u

CONSTRUCCIîN...> }o]u v ] v µ }v} ]u] v } µu]u } v ]U Z_ µ ]vÀ] ] (} u À µv } o } v o}]v ] µ U (} u o µ } ] v(} o o} v ] }V ^ o Àoµ ] v µ o]Ì o ]v] ]} µ v ] ] Ç µ u

v o P í Ì µ Z ] Z o ] v ] ( º ] ' Á Z µ v P À } v µ Á v µ v P v µ u ^ } v ... · v o P í Ì µ Z ] Z o ] v ] ( º ] ' Á Z µ v P À } v µ Á v µ v P v µ u ^ } v µ

v o P í Ì µ Z ] Z o ] v ] ( º ] ' Á Z µ v P À } v µ Á v µ v P v µ u ^ } v ... · v o P í Ì µ Z ] Z o ] v ] ( º ] ' Á Z µ v P À } v µ Á v µ v P v µ u ^ } v µ

o } v o d ( ( ] ] · D µ v } U d À ] } U W ] v Ì v } µ o o } ] u ] ^ µ o X / v µ v ] v } v } v µ } ] ] o ï o µ P o ] } } v o

o } v o d ( ( ] ] · D µ v } U d À ] } U W ] v Ì v } µ o o } ] u ] ^ µ o X / v µ v ] v } v } v µ } ] ] o ï o µ P o ] } } v o

v } u t ^ } ] ] o ] µ } / v ] ] o ] v } u µ v ... · / v } u t ^ } ] ] o ] µ } / v ] ] o ] v } u µ v ] } ys// } v P ...

v } u t ^ } ] ] o ] µ } / v ] ] o ] v } u µ v ... · / v } u t ^ } ] ] o ] µ } / v ] ] o ] v } u µ v ] } ys// } v P ...

o · & ] o ] } ] v o X W } i } µ } } µ } ( o µ µ v U

o · & ] o ] } ] v o X W } i } µ } } µ } ( o µ µ v U

Programa V Seminario · W u v v ] Ç µ v ] µ v o } ] v µ ] o X > Z µ o o o o y } o v o i ] } µ v } 3DXVD FDIp &RQIHUHQFLD PDJLVWUDO

Programa V Seminario · W u v v ] Ç µ v ] µ v o } ] v µ ] o X > Z µ o o o o y } o v o i ] } µ v } 3DXVD FDIp &RQIHUHQFLD PDJLVWUDO

> v } À } v Z u ] µ u ] } v ] v ] À ] µ o o } µ o µ ...

> v } À } v Z u ] µ u ] } v ] v ] À ] µ o o } µ o µ ...

µ o ( ] v o µ ] µ o µ u µ o µ ] µ v ] À ]

µ o ( ] v o µ ] µ o µ u µ o µ ] µ v ] À ]

micr oem presarialcobachsonora.edu.mx/files/semestre5-2017/cpt/describe_los_elemen… · ^ o Ào µ ] v µ o ]Ì o ] v] ]} µ v ] ] Ç µ u] }v ] v µ }v} ]u] v } o u µ } X

micr oem presarialcobachsonora.edu.mx/files/semestre5-2017/cpt/describe_los_elemen… · ^ o Ào µ ] v µ o ]Ì o ] v] ]} µ v ] ] Ç µ u] }v ] v µ }v} ]u] v } o u µ } X

Z } [ À o µ ] } v o u ] v µ À µ ^ ' µ } µ o } v v ] W ... · µ í i v À ] î ì í ñ µ ï í u î ì í ò X / o v µ Æ v v } v µ ] À v ] } v µ ( ]

Z } [ À o µ ] } v o u ] v µ À µ ^ ' µ } µ o } v v ] W ... · µ í i v À ] î ì í ñ µ ï í u î ì í ò X / o v µ Æ v v } v µ ] À v ] } v µ ( ]

Rwanda W µ Ç ] v ] v µ } v o µ } v ] o ] v€¦ · RES-Research Studies Z ] o ] v ] v µ } v ^ Ç u W Z Á v ^ µ Ç Rwanda W µ Ç ] v ] v µ } v o µ } v ] o ] v

Rwanda W µ Ç ] v ] v µ } v o µ } v ] o ] v€¦ · RES-Research Studies Z ] o ] v ] v µ } v ^ Ç u W Z Á v ^ µ Ç Rwanda W µ Ç ] v ] v µ } v o µ } v ] o ] v

v µ À o µ ] v v v ] Ç v ] u ] v } µ o }

v µ À o µ ] v v v ] Ç v ] u ] v } µ o }

v À v ] } i ] ] } v ( } ! Z µ À o µ } o } P ] µ ~ µ ...

v À v ] } i ] ] } v ( } ! Z µ À o µ } o } P ] µ ~ µ ...

W } P u u } ( ] v v u v } i [ µ ] } v v ] } µ o ] } Ç v ... · ] v v ] } v o t o o } v ] r µ Æ o o [ ] v ] P o u v v o K i ] ( µ À o } u v µ o U v ] µ o ] o µ ] µ ] o K

W } P u u } ( ] v v u v } i [ µ ] } v v ] } µ o ] } Ç v ... · ] v v ] } v o t o o } v ] r µ Æ o o [ ] v ] P o u v v o K i ] ( µ À o } u v µ o U v ] µ o ] o µ ] µ ] o K