IMA3/IMA4 2019/2021 P3+
Sommaire
Présentation générale
- Nom du projet : Installation d'un orchestrateur de machines virtuelles
- Stagiaire : Souleymane SOW
- Encadrant : Xavier REDON
- Durée : 6 semaines (17 Mai - 25 Juin 2021)
Objectifs
On aura à installer une infrastructure permettant à des utilisateurs de gérer un ensemble de machines virtuelles.
Description
Plusieurs composants sont nécessaires dans cet infrastructure :
- un système de fichiers distribué ;
- un système de virtualisation ;
- l'orchestrateur des machines virtuelles;
Pour le système de fichiers on va regarder du coté de CEPH. Pour l'orchestrateur ProxMox semble incontournable. Le système de virtualisation peut être kvm ou Xen. Le démonstrateur aura à utiliser des disques sur au moins deux serveurs physiques et permettre de faire tourner des machines virtuelles sur au moins deux serveurs physiques. Les mécanismes de haute disponibilité et de migrations serons mis en place.
Préparation du projet
Cahier des charges
Choix techniques : matériel et logiciel
- Logiciels:
- CEPH: Solution libre de stockage distribué (software-defined storage)
- Proxmox: Solution de virtualisation libre basée sur l'hyperviseur Linux KVM, et offrant aussi une solution de containers avec LXC
- KVM/Xen: Logiciel libre de virtualisation
- Matériel:
- Serveur DELL PowerEdge R520
- Serveur DELL PowerEdge 2950
Liste des tâches à effectuer
Calendrier prévisionnel
Réalisation du Projet
Semaine 1
Mise en route du serveur Dell PowerEdge R520
Du à un probléme du capteur thermique, le serveur faisait beaucoup de bruit car les ventilateurs tournaient à fond dés qu'il est en service. Donc on a du trouver une solution afin de pallier à ce probléme. Afin de réduire le bruit c'est à dire réduire la ventilation dans le serveur, on a rajouté des résistances de 47 Ohms et de puissance d'1/2 W sur l'alimentation des ventilateurs. Aprés cela on a pu constater que la ventilation a été considérablement réduite donc on devait faire des tests afin de savoir si la ventilation était convenable pour refroidir assez le systéme en marche. Aprés avoir installé un nouveau Os (Devuan 3) sur notre serveur, on a effectué les configurations réseaux afin de permettre à notre serveur d'avoir accés au réseau de l'école et à Internet. On a installé lm-sensors qui est un logiciel libre pour les systèmes GNU/Linux fournissant des outils pour gérer la température, la tension, la vitesse des ventilateurs et l'humidité.Ensuite on a installé Stress permettant de charger à fond nos CPU afin de nous permettre de tester si la ventilation est suffisante. Aprés avoir stresser les CPU pendant 10 minutes, avec la commande sensors on a pu constater que la température augmentait jusqu'à atteindre une limite d'environ 53°C loin des 97°C de seuil critique.
Un second test a été effectué pour valider les modifications apportées en stressant les cpu pour une durée plus longue avec la commande: sudo stress --cpu 8 --timeout 7200.L'option --cpu 8 permet de générer 8 workers tournant sur la fonction sqrt (). L'option --timeout 7200 permet de spécifier la durée du stress, ici 7200 secondes soit 2 heures. Ensuite, on a mis en place un script shell permettant de monitorer la température de nos CPU chaque 10 minutes:
while true;
do
sensors
sleep 600
done
On observe que durant les deux heures, la température est monté jusqu'à atteindre un niveau de stabilité de 55°C au bout de 30 minutes. Ensuite elle tournait autour de ce seuil jusqu'à la fin du test. On peut affirmer ainsi que la solution mise en place afin de résoudre le probléme de ventilation du serveur PowerEdge R520 a été efficace car assurant un bon refroidissement des CPU mais aussi une grande réduction du bruit lors de sa mise en marche.
Installation de Devuan 3.0 sur nos serveurs
Sur chaque serveur, une distribution de Devuan y a été installé.
Sur notre R520, on dispose ainsi d'un disque de 1 To partitionné comme suit: 100 Go pour l'OS, 2 partitions de 250Go et une de 300Go. Pour la configuration réseau, elle dispose de l'addresse IP @:172.26.145.223.
Sur la PowerEdge 2950, on dispose de 2 disques de 300 Go et une de 70Go, l'OS a été installé sur ce dernier ayant ainsi deux disques disponible. Pour la configuration réseau, elle a comme adresse IP @172.26.145.224.
Semaine 2
Mise en place du systéme de fichiers distribué CEPH
Pour faire fonctionner Ceph, nous aurons besoin de :
- le serveur d’administration du cluster nommé admin. Il permet d'effectuer les tâches d’administration de l'ensemble du cluster.
- le serveur moniteur nommé mon qui permet de suivre l'activité de l'ensemble du cluster.
- les serveurs de données nommés osdX qui stockent les objets
On ajoute d'abord les différentes machines de l'architecture dans le fichier /etc/hosts:
172.26.145.224 osd1 172.26.145.224 osd2 172.26.145.223 admin 172.26.145.223 mon
Installation et configuration de CEPH: Pour installer CEPH, nous allons avoir besoin d’un utilisateur dédié. Il va donc falloir créer un utilisateur commun sur nos 2 serveurs de notre cluster:
- Création de l’utilisateur ceph:
useradd -d /home/ceph -m ceph passwd ceph (pasglop) echo "ceph ALL = (root) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/ceph (Donner le droit sudo sans mot de passe pour tous les logiciels de la machine pour l'utilisateur ceph) sudo chmod 0440 /etc/sudoers.d/ceph
- Mise en place du ssh:
Pour s’installer, CEPH utilise le protocole SSH et nécessite une authentification par paire de clé. On va donc mettre en place une authentification par paire de clé entre notre serveur d’administration (admin) et les autres machines de notre cluster. Sur admin: on bascule sur le user ceph et on crée la paire de clef
su - ceph ssh-keygen ssh-copy-id ceph@osd1 (On envoie la clé publique vers les autres machines de notre cluster)
Enfin pour finir la configuration du SSH du serveur d’administration, il faut créer un fichier config dans /home/ceph/.ssh
Host osd1 Hostname osd1 User ceph Host osd2 Hostname osd2 User ceph Host mon Hostname mon User ceph
- Configuration des dépôts:
On va maintenant configurer les dépôts de notre serveur d’administration pour pouvoir installer la dernière version de CEPH. Les opérations suivantes sont réalisées sur le serveur d’administration uniquement en utilisateur ceph. Mise en place des dépôts CEPH:
wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add - echo deb https://download.ceph.com/debian-luminous/ jessie main | sudo tee /etc/apt/sources.list.d/ceph.list sudo apt update sudo apt install ceph-deploy ntp
On installe ntp pour éviter les dérives d’horloge dans les moniteurs ceph.
- Création du cluster ceph:
Nous allons maintenant installer Ceph sur chacune des machines pour en faire un cluster puis nous les spécialiserons une à une. Sur la machine d'administration (admin) et en tant qu'utilisateur ceph, il faut créer un dossier nommé test-ceph dans lequel les commandes ceph-deploy seront utilisées (ceph-deploy crée des fichiers localement là où il est exécuté):
mkdir /home/ceph/test-ceph
Un cluster Ceph ne peut fonctionner sans moniteur, aussi nous devons commencer par indiquer quelle machine aura ce rôle futur. Pour ce faire, la commande suivante commence le déploiement d'un nouveau cluster en ajoutant une machine moniteur dans ce cluster. Elle crée également trois fichiers : un fichier de clefs, un fichier de log et un fichier de configuration.
ceph-deploy new mon
Nous allons ensuite installer l'ensemble des programmes et librairies nécessaires à Ceph sur l’autre serveur. À la fin, nos 2 serveurs seront tous identiques et leur rôle leur sera attribué par la suite.
ceph-deploy install admin mon osd1 osd2
Mais nous rencontrons l'erreur suivante lors de l'installation:
[admin][ERROR ] RuntimeError: command returned non-zero exit status: 100
[ceph_deploy][ERROR ] RuntimeError: Failed to execute command: env DEBIAN_FRONTEND=noninteractive DEBIAN_PRIORITY=critical apt-get --assume-yes -q --no-install-recommends install ceph ceph-osd ceph-mds ceph-mon radosgw
Mise en place du système de fichiers distribué CEPH (Suite)
Le problème rencontré précédemment lors de l'installation a pu être résolu en installant des paquets manquants : radosgw et gnupg1
Un autre problème lié à l'OS de nos serveurs est survenu lors de la spécification de la machine moniteur avec la commande :
ceph-deploy mon create mon ("mon" étant mon moniteur)
En effet Devuan est "systemd-free" donc ne peut exécuter les commandes systemctl or notre commande s’exécute avec. Pour résoudre ce problème, on doit trouver une procédure d'installation de CEPH avec sysv-init disponible sur Devuan.
Semaine 3
On a pas pu trouver une alternative d'installation de Ceph sans Systemd. Lors des recherches de solutions, il s'est trouvé que Proxmox était systemd dépendant donc ne pourrait etre installé sur nos deux serveurs. On a décidé de mettre en place des machines virtuelles et y installer un Debian 10 pour pouvoir mettre en place nos solutions.
Installation machine virtuelle
Installation des paquets requis
Pour vérifier que les microprocesseurs de nos machines permettent la virtualisation avec KVM on tape la commande suivante:
grep -E 'vmx|svm' /proc/cpuinfo &>/dev/null && echo "La virtualisation est possible sur cette machine." || echo "Le microprocesseur de cette machine ne permet pas d'utiliser la virtualisation avec KVM."
On installer ensuite les paquetages qemu-kvm et libvirt-daemon
apt-get install qemu-system libvirt-clients libvirt-daemon-system virtinst
- QEMU est un logiciel libre de machine virtuelle, pouvant émuler un processeur et, plus généralement, une architecture différente si besoin. Il permet d'exécuter un ou plusieurs systèmes d'exploitation via les hyperviseurs KVM et Xen, ou seulement des binaires, dans l'environnement d'un système d'exploitation déjà installé sur la machine.
- libvirt est une bibliothèque, une API, un daemon et des outils en logiciel libre de gestion de la virtualisation. Elle est notamment utilisée par KVM, Xen, VMware ESX, QEMU et d'autres solutions de virtualisation. Elle est notamment utilisée par la couche d'orchestration des hyperviseurs.
Ensuite on utilise la commande adduser pour ajouter notre nom d'utilisateur aux groupes kvm et libvirt:
adduser pifou kvm & adduser pifou libvirt
Installation de notre VM Proxmox
Avant de lancer l'installation, il nous faut au préalable avoir notre fichier d'installation sur notre machine avant de lancer la commande d'installation suivante:
virt-install --name proxmox --ram 4096 --disk path=/var/lib/libvirt/images/proxmox.img,size=20 --vcpus 2 --os-type linux --os-variant debian10 --network network=default --graphics none --console pty,target_type=serial --location /var/lib/libvirt/boot/debian-10.9.0-amd64-netinst.iso --extra-args 'console=ttyS0,115200n8 serial'
- --name: Nom de la machine
- --ram: spécifie la quantité de mémoire qu'utilise la machine virtuelle en mégaoctets
- --disk path: montre le chemin d'accès au disque virtuel qui peut être un fichier, une partition ou un volume logique. Dans cet exemple, un fichier nommé proxmox.img dans le répertoire /var/lib/libvirt/images/, avec une taille de 20 gigaoctets
- --location: Fichier à utiliser comme CDROM d’installation virtuel
- --os-type: Optimise la configuration pour un type de système d'exploitation (Linux/windows)
- --os-variant: Optimise davantage la configuration pour une variante de système d'exploitation spécifique(Debian 10/ Ubuntu 20)
- --vcpus: Nombre de processeurs virtuels à configurer pour notre vm
- --network: Connectez la vm au réseau de la machine hôte
A la fin de l'installation on pourra gérer notre machine avec les commandes suivantes:
- Lister les machines virtuelles
virsh list --all
- Puis, pour démarrer, arrêter ou encore redémarrer une machine, nous pourrons utiliser les commandes suivantes :
virsh start proxmox
virsh shutdown proxmox
virsh reboot proxmox
- Se connecter à la console de notre VM
virsh console proxmox
- D’autre part, pour forcer l’arrêt de notre VM :
virsh destroy proxmox
Mise en place de Proxmox
Dans cette partie on va décrire les étapes pour l'installation de Proxmox sur un systéme Debian 10
- Ajout d’une entrée dans /etc/hosts pour notre @ip:
Le nom d’hôte de notre machine doit pouvoir être résolu avant de commencer l'installation de Proxmox sur notre Debian
127.0.0.1 localhost.localdomain localhost
192.168.122.10 proxmox1.plil.info proxmox1
On teste notre configuration avec la commande hostname --ip-address qui nous renvoie notre adresse IP si tout est ok!
- Ajout du répos Proxmox
On ajoute le répos:
echo "deb http://download.proxmox.com/debian/pve buster pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list
Et sa clé :
wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
On la rend executable :
chmod +r /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
On met à jour nos dépôts:
sudo apt update && sudo apt full-upgrade
- Installation des packages de Proxmox VE
Pour commencer l'installation on lance :
apt install proxmox-ve postfix open-iscsi
A la fin de l'installation, le système reboot, et démarre automatiquement sur le kernel Proxmox. Pour accéder à la page d'administration de notre Proxmox à partir du navigateur d'une machine de TP de la salle, on va mettre en place un Reverse Proxy au niveau de nos serveurs pour faciliter l'administration. On rappelle que l'interface d'aministration de Proxmox est disponible à l'adresse IP de la machine hote (notre VM) dans le port 8006.
Mise en place d’un Reverse Proxy Apache pour l'accès à l'interface de gestion de Proxmox
Le reverse proxy sera une passerelle permettant aux hôtes appartenant au réseau 172.26.145.0/24 d’accéder au réseau virtuel interne de nos serveurs Cordouan 192.168.122.0/24 et Container 192.168.123.0/24. Il nous faudra spécifier à notre machine d'administration appartenant au réseau 172.26.145.0 la route lui permettant d'accéder au réseau virtuel de nos Vms grace à la commande ip route add.
- Installation Apache:
Dans un premier temps il nous faut installer Apache2:
apt-get install apache2
- Activation des modules utilisés:
Pour utiliser Apache en mode proxy inverse, il nous faut activer les 2 modules proxy et proxy_http via la commande a2enmod et les modules ssl pour une connexion sécurisée https
a2enmod ssl proxy rewrite proxy_connect proxy_http
Le module proxy permet l’implémentation d’un serveur mandataire / passerelle et le module proxy_http apporte le support des requêtes HTTP et HTTPS au module proxy. Pour activer ces services, il est nécessaire de redémarrer apache.
service apache2 restart
- Mise en place du Virtualhost:
La configuration suivante correspond
vi /etc/apache2/sites-available/proxmox.polytech-lille.fr.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName proxmox.polytech-lille.fr
ProxyPreserveHost On
ProxyRequests Off
ProxyErrorOverride Off
ProxyPass / https://192.168.122.10:8006/
ProxyPassReverse / https://192.168.122.10:8006/===Mise en place d’un Reverse Proxy Apache pour l'accès à l'interface de gestion de Proxmox===
SSLEngine on
SSLCertificateFile /etc/ssl/server.crt
SSLCertificateKeyFile /etc/ssl/server.key
SSLProxyEngine On
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
SSLProxyVerify none
</VirtualHost>
</IfModule>
ServerName permet de spécifier le nom de domaine voulu;ProxyPass et ProxyPassReverse donnent la correspondance entre le path voulu et l’adresse du serveur destinataire et ajustent l’URL dans les en-têtes HTTP. ProxyRequests permet d’activer et de désactiver la fonctionnalité de serveur mandataire. Pour la configuration du SSL, il nous faut créer une certificat SSL.
- Création d’un certificat SSL:
Prérequis: Installation du paquet openssl:
apt-get install openssl
Création de la clef: On se place au niveau du répertoire /etc/ssl/ avant de créer la clef:
sudo openssl genrsa -out server.key 2048
Cette commande va créer la clé privée avec l'algorithme RSA 2048 bits. Demande de signature du certificat:Ensuite il faut générer un fichier de « demande de signature de certificat », en anglais CSR : Certificate Signing Request
sudo openssl req -new -key server.key -out server.csr
On répond à un certain nombre de questions. On veille surtout à mettre le nom du serveur tel qu'il est appelé de l'extérieur dans le champ « Common Name » ( ici : "proxmox.polytech-lille.fr"). Pour visualiser le contenu du fichier généré:
sudo openssl req -text -noout -in server.csr
Signature du certificat:Enfin, on génére le certificat signé au format x509: (certificat autosigné pour 365 jours)
sudo openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Installation du certificat:
cp /etc/ssl/server.crt /etc/ssl/certs/
cp /etc/ssl/server.key /etc/ssl/private/
Maintenant que notre certificat SSL est généré et notre fichier de configuration virtualhost défini ,nous devons l’activer puis recharger Apache
a2ensite proxmox.polytech-lille.fr.conf
service apache2 reload
On met aussi en place une masquerade sur nos 2 serveurs pour permettre à nos VMs d'accéder au réseau externe en utilisant l'adresse IP de leur serveur hote sur le réseau 172.26.145.0/24.
iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.168.122.10/32 (Sur Cordouan)
iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.168.123.10/32 (Sur Container)
Pour tester si notre configuration fonctionne à partir d'un navigateur de notre machne d'administration, aprés avoir désactivé les proxy pour les réseaux de nos machines proxmox et rajouté le nom de nos hotes dans le fichier /etc/hosts comme suit:
172.26.145.223 cordouan proxmox.polytech-lille.fr===Mise en place d’un Reverse Proxy Apache pour l'accès à l'interface de gestion de Proxmox===
172.26.145.224 container proxmox2.polytech-lille.fr
On arrive à accéder aux interfaces d'administration de nos proxmox via les adresses proxmox.polytech-lille.fr et proxmox2.polytech-lille.fr.
Mise en place de notre cluster Proxmox
On va mettre en place un cluster de 2 noeuds:
Cordouan----> Name: proxmox1 @IP: 192.168.122.10 Container----> Name: proxmox2 @IP: 192.168.123.10
Vu que nos proxmox sont installés sur des machines virtuelles qui n'ont pas accés à l'espace de stockage des serveurs hotes, on doit rajouter de l'espace de stockage sur nos Vms. Pour cela on va utiliser la commande:
Sur Cordouan:
virsh attach-disk proxmox1 /dev/sda3 vdb
Sur Container:
virsh attach-disk proxmox2 /dev/sdb vdb
virsh attach-disk proxmox2 /dev/sdc vdc
- Création du cluster:On va créer le cluster sur Promox1
pvecm create mycluster
- Vérification du statut du cluster:
pvecm status
Semaine 4
- Adhésion au cluster de proxmox2:On va demander à proxmox2 de rejoindre le cluster mycluster
pvecm add 192.168.122.10 -link0 192.168.123.10
On peut vérifier sur l'interface d'administration de Proxmox si notre cluster a été crée et que nos noeuds ont été ajouté avec succés
- Eviter la problématique du Quorum:Très important pour la suite nous allons effectuer une manipulation pour éviter de se retrouver avec un hyperviseur en "lecture seule" dans le cas ou le second noeud viendrait à rencontrer un problème (réseau, matériel ...). Afin de maintenir la synchronisation entre les nœuds, une exigence Proxmox est qu'au moins trois nœuds doivent être ajoutés au cluster. Dans notre architecture cela n'est pas faisable. Dans les configurations à deux nœuds, ce qui se passe, c'est que les deux nœuds doivent toujours être opérationnels pour que toute modification, telle que le démarrage, l'arrêt ou la création de machines virtuelles et de conteneurs, soit effectuée. Afin de résoudre ce problème, nous pouvons utiliser un QDevice externe dont le seul but est de régler les votes pendant les périodes de panne de nœud. Ce QDevice ne sera pas un composant visible du cluster Proxmox et ne pourra pas y exécuter de machine virtuelle ou de conteneur.
On installe le paquet corsync-qdevice sur nos deux noeuds
apt install corosync-qdevice
Ensuite sur notre machine d'administration qui va jouer le role du Qdevice on installe les paquets suivants:
apt install corosync-qnetd corosync-qdevice
Enfin à partir d'un noeud, on joint notre Qdevice à notre cluster via la commande (@IP Qdevice:172.26.145.70)
pvecm qdevice setup 172.26.145.70 -f
Pour vérifier si notre configuration a bien été pris en compte on regarde l'état de notre clustre via la commande pvecm status, on observe bien que le nombre de votes est passé de 2 à 3 et que notre Qdevice a rejoint le cluster.
Mise en place d'une solution de stockage distribué avec Proxmox et Ceph
Ceph c'est quoi? Ceph est une plateforme libre de stockage distribuée. Les objectifs principaux de Ceph sont d’être complètement distribué sans point unique de défaillance, extensible jusqu’à l’exaoctet et librement disponible. Les données sont répliquées, permettant au système d’être tolérant aux pannes. Ceph fonctionne sur du matériel non spécialisé. Le système est conçu pour s'auto-réparer et automatiser au maximum ses tâches administratives afin de réduire les coûts d’exploitation.
Pour faire simple, Ceph nous permet d’utiliser les disques de plusieurs hôtes pour réaliser du stockage distribué, permettant par exemple de réaliser des migrations de machines virtuelles à chaud, ou encore d’éviter les pannes étant donné qu’il n’y aura pas de SPOF, c’est-à-dire de « Single Point of Failure », pas de point unique de défaillance. Dans le cas des VMs toujours, si nous les stockons sur notre cluster Ceph, celles-ci seront donc répliquées sur chacun des hôtes.
Installation de Ceph:Alternativement à l'assistant d'installation recommandé de Proxmox VE Ceph disponible dans l'interface Web, nous pouvons utiliser la commande suivante sur chaque nœud de notre cluster :
pveceph install
Cela configure un référentiel de packages apt dans /etc/apt/sources.list.d/ceph.list et installe le logiciel requis.
Configuration initiale de Ceph:On exécute la commande suivante sur un des noeuds
pveceph init --network 192.168.122.0/24
pveceph init --network 192.168.123.0/24
Cela crée une configuration initiale dans /etc/pve/ceph.conf avec un réseau dédié pour Ceph. Ce fichier est automatiquement distribué à tous les nœuds Proxmox VE de notre cluster, à l'aide de pmxcfs. La commande crée également un lien symbolique dans /etc/ceph/ceph.conf, qui pointe vers ce fichier. Ainsi, nous pouvons simplement exécuter les commandes Ceph sans avoir besoin de spécifier un fichier de configuration.
Ceph monitor:Le moniteur Ceph conserve une copie principale de la carte de cluster. Un minimum de trois monitor nodes est recommandé pour garantir la fiabilité. Mais dans notre architecture, on a que 2 noeuds disponibles dans notre cluster.
- Création de moniteurs: Sur chaque nœud où l'on souhaite placer un moniteur, on exécute :
pveceph mon create
- Suppression de moniteurs: Pour supprimer un moniteur Ceph, on se connecte d'abord au nœud sur lequel le MON est en cours d'exécution. Ensuite on exécute la commande suivante
pveceph mon destroy
Ceph manager: Ces nodes gèrent l’état de l’utilisation de la mémoire, de la charge du système et de l’exploitation des nodes.
- Création de manager:
pveceph mgr create
- Suppression de manager:
pveceph mgr destroy
Ceph OSDs:Physiquement, les données sont stockées sur des disques ou SSD formatés avec un système de fichiers comme ext et que Ceph baptise Ceph OSD (Ceph Object Storage Device). À chaque OSD correspond un démon chargé de stocker les données, de les répliquer ou de les redistribuer en cas de défaillance d’un équipement. Chaque démon OSD fournit aussi des informations de monitoring et de santé aux moniteurs Ceph. Un cluster Ceph doit à minima disposer de deux démons OSD (3 sont recommandés) pour démarrer.Il est recommandé d'utiliser un OSD par disque physique.
- Création d'OSD: Sur chaque noeud ou on veut créer un OSD on éxécute la commande suivante en spécifiant le disque à utiliser comme OSD(sdb et sdc pour le proxmox2 et vdb pour le proxmox1)
pveceph osd create /dev/sdb
- Suppression d'OSD:
ceph osd out <ID>
systemctl stop ceph-osd@<ID>.service
La première commande indique à Ceph de ne pas inclure l'OSD dans la distribution des données. La deuxième commande arrête le service OSD. Jusqu'à ce moment, aucune donnée n'est perdue.
Ceph Pool:Un cluster Ceph stocke les données sous forme d’objets stockés dans des partitions logiques baptisées “pools”. À chaque pool Ceph correspond un ensemble de propriétés définissant les règles de réplications (le nombre de copie pour chaque donnée inscrite) ou le nombre de groupes de placement (placement groups) dans le pool. Les pools peuvent être répliqués ou protégés par l’utilisation de code à effacement (erasure coding). Dans un pool répliqué, le système stocke autant de copies que spécifié de chaque donnée (le coût de stockage augmente linéairement avec le nombre de copies spécifié). Par exemple, si l’on a spécifié trois copies et que le cluster dispose de trois nœuds, la triple réplication permet de survivre à deux pannes de nœuds ou à la panne de deux disques. Lorsqu'aucune option n'est donnée, nous définissons une valeur par défaut de 128 PG, une taille de 3 répliques et une taille_min de 2 répliques, pour garantir qu'aucune perte de données ne se produise en cas d'échec d'un OSD.
- Création du pool: Sur un des noeuds de notre cluster on tape la commande suivante pour créér notre pool nommé ceph-pool
pveceph pool create ceph-pool --add_storages
- Suppression du pool:
pveceph pool destroy ceph-pool
