296 lines
9.9 KiB
Markdown
296 lines
9.9 KiB
Markdown
---
|
||
categories: cloud storage
|
||
title: Howto Ceph
|
||
...
|
||
|
||
* Documentation : <http://docs.ceph.com>
|
||
|
||
|
||
# Installation
|
||
|
||
On cherche à créer l'architecture suivante où un client interagit avec un cluster Ceph :
|
||
|
||
<---- cluster Ceph ----->
|
||
+-------+
|
||
+-> | ceph1 |
|
||
| +-------+
|
||
+-------+ +-------+ | +-------+
|
||
| cephc | <-> | cephm | <-+-> | ceph2 |
|
||
+-------+ +-------+ | +-------+
|
||
| +-------+
|
||
+-> | ceph3 |
|
||
+-------+
|
||
cephc : client Ceph
|
||
cephm : nœud maitre ou nœud admin
|
||
ceph[1-3] : nœud cephs
|
||
|
||
|
||
## Préparation
|
||
|
||
On suppose ici que :
|
||
|
||
- chaque machine a été installée sous Debian 9 ;
|
||
- chaque machine du cluster peut se connecter via SSH sur une autre ;
|
||
- cephc et cephm peuvent se connecter via SSH sur l'autre.
|
||
|
||
Pour la configuration SSH, on aura, pour cephm:
|
||
|
||
$ cat ~/.ssh/config
|
||
Hostname ceph1
|
||
Host ceph1
|
||
User cephuser
|
||
|
||
Hostname ceph2
|
||
Host ceph2
|
||
User cephuser
|
||
|
||
Hostname ceph2
|
||
Host ceph2
|
||
User cephuser
|
||
|
||
Il est peut-être nécéssaire d'ajouter les machines dans le fichier `/etc/hosts` :
|
||
|
||
X.X.X.X ceph1
|
||
Y.Y.Y.Y ceph2
|
||
Z.Z.Z.Z ceph3
|
||
|
||
> En réalité seul le nœud maître à besoin de se connecter aux autres nœud du cluster mais je n'ai pas essayé.
|
||
|
||
Dans cet exemple, chaque noeud - ceph1, ceph2 et ceph3 - à un disque supplémentaire à sa disposition. Ce disque contiendra les données à stocker dans le cluster et doit être vide, sans table de partitions et être utilisé comme volume physique :
|
||
|
||
wipefs -a /dev/sdb
|
||
pvcreate /dev/sdb
|
||
|
||
> /dev/sdb est le volume supplémentaire.
|
||
|
||
|
||
## Installation
|
||
|
||
On commence par installer `ceph-deploy`, l'outil qui permet de déployer un cluster Ceph.
|
||
|
||
sudo wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -
|
||
echo deb https://download.ceph.com/debian-luminous/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
|
||
sudo apt update && sudo apt install ceph-deploy
|
||
|
||
> Les commandes précédentes ne sont à exécuter que sur le nœud maître.
|
||
|
||
Puis, on installe NTP sur l'ensemble des nœuds.
|
||
|
||
sudo apt install ntp
|
||
sudo timedatectl set-ntp true
|
||
|
||
**TODO** Il est recommandé de créer un utilisateur spécifique pour Ceph, mais ça fonctionne sans.
|
||
|
||
> Jusqu'à indication du contraire, les commandes qui suivent sont à exécuter sur le nœud maître.
|
||
|
||
On commence par créer un dossier qui contiendra les fichiers de configuration et les clefs.
|
||
|
||
mkdir my-cluster
|
||
cd my-cluster
|
||
|
||
On crée le cluster :
|
||
|
||
ceph-deploy new deb1 deb2 deb3
|
||
|
||
Ajouter le « public_network » à la configuration de Ceph :
|
||
|
||
cat <<eof >>ceph.conf
|
||
public_network = 192.168.4.0/24
|
||
eof
|
||
|
||
On installe les paquets Ceph sur les nœeuds :
|
||
|
||
ceph-deploy install --release luminous deb1 deb2 deb3
|
||
|
||
On initialise le moniteur. Cela va créer un tas de fichiers `*.keyring`. On copie ensuite ces fichiers sur tous les nœeuds. Un monitor sert à maintenir une carte de l'état du cluster.
|
||
|
||
ceph-deploy mon create-initial
|
||
ceph-deploy admin deb0 deb1 deb2 deb3
|
||
|
||
On déploie un manager. Celui-ci permet de regrouper l'état du cluster à un seul endroit.
|
||
|
||
ceph-deploy mgr create deb1
|
||
|
||
On crée les OSD :
|
||
|
||
ceph-deploy osd create --data /dev/sdb deb1
|
||
ceph-deploy osd create --data /dev/sdb deb2
|
||
ceph-deploy osd create --data /dev/sdb deb3
|
||
|
||
> On peut lancer la commande suivante pour s'assurer que le cluster fonctionne bien :
|
||
>
|
||
> ssh ceph1 sudo ceph -s | grep HEALTH_OK && echo yee || echo fail
|
||
|
||
On ajoute des moniteurs afin d'assurer la bonne disponibilité du cluster. Il vaut mieux avoir un nombre impair de moniteurs.
|
||
|
||
ceph-deploy mon add deb2
|
||
ceph-deploy mon add deb3
|
||
|
||
De la même manière, on ajoute des managers. Dans le cas où un manager décide de ne plus fonctionner.
|
||
|
||
ceph-deploy mgr create deb2
|
||
ceph-deploy mgr create deb3
|
||
|
||
Il ne reste qu'à créer un pool et à l'initialiser pour RBD :
|
||
|
||
sudo ceph osd pool create rbd 128
|
||
sudo ceph osd pool set rbd nodelete true
|
||
sudo ceph osd pool application enable rbd rbd
|
||
sudo rbd pool init rbd
|
||
|
||
> La seconde commande empêche la suppression du pool. Il sera impossible de le supprimer par accident (ou de le supprimer tout court).
|
||
|
||
Le cluster est prêt. On peut maintenant s'occuper du client.
|
||
|
||
|
||
## Client
|
||
|
||
L'installation du client est analogue à celle des nœuds. Depuis le nœud admin :
|
||
|
||
ceph-deploy install --release luminous debc
|
||
ceph-deploy admin debc
|
||
|
||
> Si cette étape échoue à cause d'un problème de clefs, il faut copier les clefs dans /etc/ceph :
|
||
>
|
||
> sudo cp ceph.client.admin.keyring /etc/ceph
|
||
|
||
Sur le client, on peut désormais récupérer le block device :
|
||
|
||
sudo rbd create foo --size 4096 --image-feature layering
|
||
sudo rbd map foo --name client.admin
|
||
|
||
Si on compte utiliser le block device pour y installer une machine virtuelle, on s'arrêter là. Sinon, il ne reste qu'à le formater puis à le monter :
|
||
|
||
sudo mkfs.ext4 -m0 /dev/rbd/rbd/foo
|
||
sudo mkdir /mnt/ceph-block-device
|
||
sudo mount /dev/rbd/rbd/foo /mnt/ceph-block-device
|
||
cd /mnt/ceph-block-device
|
||
|
||
|
||
# Gestion des pools
|
||
|
||
|
||
## Supprimer un pool
|
||
|
||
Par défaut, il est impossible de supprimer un pool. Il y a deux gardes-fous à passer pour permettre la suppression. On s'assure d'abord que le flag « nodelete » est bien à « false » :
|
||
|
||
sudo ceph osd pool get $POOL_NAME nodelete | grep -q true && ceph osd pool set $POOL_NAME nodelete false
|
||
|
||
Une fois ce flag désactivé, il faut configurer le cluster pour autoriser la suppression d'un pool :
|
||
|
||
sudo ceph tell mon.* injectargs --mon-allow-pool-delete=true
|
||
|
||
Pour finir, on supprime le pool puis on active à nouveau la sécurité :
|
||
|
||
sudo ceph osd pool delete pool_name pool_name --yes-i-really-really-mean-it
|
||
sudo ceph tell mon.* injectargs --mon-allow-pool-delete=false
|
||
|
||
|
||
# Gestion des block devices
|
||
|
||
|
||
## Créer une VM
|
||
|
||
On peut utiliser un block device pour y installer une machine virtuelle avec `virt-install`. Le chemin du disque doit mener au block device :
|
||
|
||
# virt-install --connect=qemu:///system \
|
||
--name=$VMNAME \
|
||
--cpu mode=host-passthrough --vcpus=$VCPU \
|
||
--ram=$RAM \
|
||
--disk path=/dev/rbd/rbd/foo,bus=virtio,io=threads,cache=none,format=raw \
|
||
--network=bridge:br0,model=virtio \
|
||
--noautoconsole --graphics vnc,listen=127.0.0.1,keymap=fr \
|
||
--rng /dev/random \
|
||
--cdrom=/home/images/slackware64-14.2-install-dvd.iso
|
||
|
||
|
||
## Redimensionner
|
||
|
||
Il est possible d'étendre ou de réduire un block device au sein d'un pool. Si des machines virtuelles ont été installée sur le block device en question, il n'est pas nécéssaire de les éteindre. On suppose ici que l'on souhaite étendre le block device foo de 8 Gio à 16 Gio. Depuis le nœud admin ou client, il suffit de faire :
|
||
|
||
$ sudo rbd resize foo --size 16G
|
||
|
||
Il reste à avertir la machine que le device a changé de taille :
|
||
|
||
$ sudo virsh blockresize testrbd /dev/rbd/rbd/foo 10G
|
||
|
||
> Si on souhaite réduire la taille du block device :
|
||
>
|
||
> $ sudo rbd resize foo --size 8G --allow-shrink
|
||
|
||
Le reste de la procédure dépend du système de fichiers utilisé et est à faire sur la VM. Si on souhaite étendre une partition `ext4` :
|
||
|
||
~~~
|
||
fdisk /dev/vdb1 # suppression puis récréation de la partition
|
||
partprobe
|
||
e2fsck -yf /dev/vdb1
|
||
resize2fs /dev/vdb1
|
||
~~~
|
||
|
||
|
||
## Répliquer
|
||
|
||
Un block device est répliqué fois 2 par défaut. La commande suivante permet de changer cette valeur :
|
||
|
||
sudo ceph osd pool set rbd size 2
|
||
|
||
Le block device `rbd` sera ainsi répliqué 1 fois. Dans le cluster, on trouvera le block device original plus une réplication, d'où le « 2 ».
|
||
|
||
Pour accéder au nombre de réplicats :
|
||
|
||
sudo ceph osd pool get rbd size
|
||
|
||
> **NB** Si on augmente le nombre de réplications, la commande `ceph -s` affichera certainement « HEALTH WARN ». Ce warning est normal et signale qu'une des réplications n'est pas complète. Il s'agit de celle qui vient d'être ajoutée. Le warning disparaitra quand la nouvelle réplication sera à jour.
|
||
|
||
|
||
# Troubleshooting
|
||
|
||
**TODO** ajouter les messages d'erreur
|
||
|
||
|
||
## Crash
|
||
|
||
Si une ou plusieurs machines du cluster s'éteigent brutalement, il suffit de les redémarrer et de s'assurer que le service NTP soit lancé sur la machine :
|
||
|
||
# timedatectl status | grep -q '^NTP synchronized: yes$' || timedatectl set-ntp true
|
||
|
||
|
||
## Installation client impossible
|
||
|
||
Si l'installation d'un client n'est pas possible à cause d'une erreur de configuration des paquets avec dpkg :
|
||
|
||
# dpkg --configure ceph-common
|
||
|
||
Puis recommencez l'installation depuis le nœud admin.
|
||
|
||
|
||
## « FS degraded »
|
||
|
||
**TODO** À reproduire, procédure incomplète
|
||
|
||
|
||
## « Reduced data availability »
|
||
|
||
Après avoir éteint le cluster pendant un week-end, la commande `sudo ceph -s` peut retourner le warning suivant :
|
||
|
||
abmj@deb0:~$ sudo ceph -s
|
||
cluster:
|
||
id: beaa2317-eecb-4e2b-b5d2-358b072fe05d
|
||
health: HEALTH_WARN
|
||
Reduced data availability: 154 pgs inactive, 152 pgs peering
|
||
Degraded data redundancy: 888/5094 objects degraded (17.432%), 66 pgs degraded
|
||
|
||
Dans la plupart des cas il suffira d'attendre que le cluster se soigne seul. On peut surveiller l'état du cluster avec `watch sudo ceph -s`. En dernier recours, si le cluster est bloqué, la commande suivante *peut* de corriger ce warning :
|
||
|
||
$ sudo ceph sync force --yes-i-really-mean-it --i-know-what-i-am-doing
|
||
|
||
## Manque de placement groups
|
||
|
||
Si on ajoute un grand nombres d'OSD sur un cluster de petite taille (c.à.d ayant moins de 10 OSD) le rapport de santé de Ceph peut nous avertir d'un manque de placement groups (noté « pgs »). Il suffit d'en ajouter avec la commande suivante :
|
||
|
||
~~~
|
||
ceph osd pool set $POOL_NAME pg_num $PG_NUM
|
||
ceph osd pool set $POOL_NAME pgp_num $PG_NUM
|
||
~~~
|
||
|
||
> $PG_NUM devrait être une puissance de 2 pour permettre une répartition des données plus homogène sur le cluster. |