22
0
Fork 0

Ajout section « Gestion des utilisateurs » et plein de modifs

This commit is contained in:
abenmiloud 2018-05-24 15:23:03 +02:00
parent 40b7ca2b40
commit 782dd92647
1 changed files with 277 additions and 128 deletions

View File

@ -10,19 +10,26 @@ title: Howto Ceph
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
~~~
<---- cluster Ceph ----->
+-------+
+-> | ceph1 |
| +-------+
+-------+ +-------+ | +-------+
| cephc | <-> | cephm | <-+-> | ceph2 |
+-------+ +-------+ | +-------+
| +-------+
+-> | ceph3 |
+-------+
cephc : client Ceph
cephm : nœud maitre ou nœud admin
ceph[1-3] : nœud cephs
~~~
Les données seront stockées sur les nœuds `ceph[123]`. Ces trois machines doivent donc avoir des disques supplémentaires qui seront utilisés par Ceph.
> Le nœud admin peut aussi être comme un nœud à données comme les nœuds `ceph[123]`.
## Préparation
@ -30,113 +37,146 @@ On cherche à créer l'architecture suivante où un client interagit avec un clu
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.
- `cephm` à un accès SSH à `ceph[123c]`.
Pour la configuration SSH, on aura, pour cephm:
$ cat ~/.ssh/config
Hostname ceph1
Host ceph1
User cephuser
~~~
$ cat ~/.ssh/config
Hostname ceph1
Host ceph1
User cephuser
Hostname ceph2
Host ceph2
User cephuser
Hostname ceph2
Host ceph2
User cephuser
Hostname ceph2
Host ceph2
User cephuser
Hostname ceph3
Host ceph3
User cephuser
~~~
Il est peut-être nécéssaire d'ajouter les machines dans le fichier `/etc/hosts` :
L'utilisateur `cephuser` doit pouvoir exécuter la commande `sudo` sans mot de passe.
X.X.X.X ceph1
Y.Y.Y.Y ceph2
Z.Z.Z.Z ceph3
> 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 :
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
~~~
wipefs -a /dev/sdX
pvcreate /dev/sdX
~~~
> /dev/sdb est le volume supplémentaire.
> `/dev/sdX` 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
~~~
# wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -
# deb https://download.ceph.com/debian-luminous/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
# 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.
~~~
# apt install ntp
# timedatectl set-ntp true
~~~
> 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
~~~
$ mkdir ceph
$ cd ceph
~~~
> On peut aussi se placer dans `/etc/ceph`.
On crée le cluster :
ceph-deploy new deb1 deb2 deb3
~~~
$ ceph-deploy new ceph1 ceph2 ceph3
~~~
Ajouter le « public_network » à la configuration de Ceph :
cat <<eof >>ceph.conf
public_network = 192.168.4.0/24
eof
~~~
$ cat <<eof >>ceph.conf
public_network = X.X.X.0/24
eof
~~~
On installe les paquets Ceph sur les nœeuds :
ceph-deploy install --release luminous deb1 deb2 deb3
~~~
$ ceph-deploy install --release luminous ceph1 ceph2 ceph3
~~~
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.
On initialise le moniteur. Cela va créer des fichiers `*.keyring`. On copie ensuite ces fichiers sur tous les nœeuds dans `/etc/ceph` avec la commande `ceph-deploy admin. Un monitor sert à maintenir une carte de l'état du cluster.
ceph-deploy mon create-initial
ceph-deploy admin deb0 deb1 deb2 deb3
~~~
$ ceph-deploy mon create-initial
$ ceph-deploy admin ceph0 ceph1 ceph2 ceph3
~~~
On déploie un manager. Celui-ci permet de regrouper l'état du cluster à un seul endroit.
ceph-deploy mgr create deb1
~~~
$ 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
~~~
$ ceph-deploy osd create --data /dev/sdX deb1
$ ceph-deploy osd create --data /dev/sdX deb2
$ ceph-deploy osd create --data /dev/sdX 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
> ~~~
> $ 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
~~~
$ 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
~~~
$ 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
~~~
# ceph osd pool create rbd 128
# ceph osd pool set rbd nodelete true
# ceph osd pool application enable rbd rbd
# 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).
@ -147,24 +187,103 @@ Le cluster est prêt. On peut maintenant s'occuper du 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
~~~
$ 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
> ~~~
> # 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
~~~
# rbd create foo --size 4096 --image-feature layering
# 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 :
Si on compte utiliser le block device pour y installer une machine virtuelle, on peut 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
~~~
# mkfs.ext4 -m0 /dev/rbd/rbd/foo
# mkdir /mnt/ceph-block-device
# mount /dev/rbd/rbd/foo /mnt/ceph-block-device
# cat <<EOF >>/mnt/ceph-block-device
plain text is life
EOF
~~~
# Gestion des utilisateurs
Ceph a un système interne de gestion des utilisateurs. Un utilisateur est représenté par :
- un nom (et un ID) ;
- des permissions ;
- une clef.
Par exemple pour l'utilisateur `client.admin` - l'utilisateur par défaut - l'ID est `admin`, le nom est `client.admin` et la clef et ses permissions sont :
~~~
$ ceph auth get client.admin
exported keyring for client.admin
[client.admin]
key = ****************************************
caps mds = "allow *"
caps mgr = "allow *"
caps mon = "allow *"
caps osd = "allow *"
~~~
> On constate naturellement que l'utilisateur `client.admin` a tous les droits sur chacun des éléments du cluster.
Après avoir installé le cluster, `client.admin` est le seul utilisateur et celui par défaut. Si vous vous êtes placé dans `/home/$USER/ceph` pour la mise en place du cluster, les fichiers de configuration et la clef de l'utilisateur `client.admin` s'y trouvent. Cependant, par défaut, les commandes comme `ceph` ou `rbd` cherchent les clefs dans `/etc/ceph`. De ce fait, si on est pas `root` ou que la clef n'est pas dans `/etc/ceph`, Ceph renvera une erreur disant qu'il ne peut pas accéder au cluster. Pour corriger ça, il faut spécifier manuellement l'emplacement de la clef en option :
~~~
$ ceph -n client.admin -k ~/ceph/ceph.client.admin.keyring health
~~~
Il est possible de définir des arguments par défaut pour ne pas avoir à tout taper à chaque fois :
~~~
$ export CEPH_ARGS='-n client.admin -k ~/ceph/ceph.client.admin.keyring health'
$ ceph health
~~~
## Création
Il y a deux façons de procéder. La première avec `add` et la seconde avec `get-or-create` :
~~~
$ ceph auth add client.slacker0 mon 'allow r'
added key for client.john
$ ceph auth get-or-create client.slacker0 mon 'allow r'
[client.paul]
key = ****************************************
~~~
La seconde méthode va, en plus de la création de l'utilisateur, afficher sa clef. On peut ainsi récupérer la sortie standard ou utiliser l'option `-o` pour écrire la clef dans un fichier la clef. De plus, si l'utilisateur existe déjà, c'est la clé déjà existante qui sera imprimée. Si on a utilisé `ceph auth add` pour ajouter l'utilisateur, on pourra récupérer sa clef avec `ceph auth get`.
## Modification
La commande suivante permet de modifier les droits d'un utilisateur. Cela va *écraser* ses droits actuels.
~~~
$ ceph auth caps client.slacker0 mon 'profile rbd' osd 'profile rbd pool=rbd'
~~~
## Suppression
~~~
$ ceph auth del client.slacker0
~~~
# Gestion des pools
@ -174,16 +293,22 @@ Si on compte utiliser le block device pour y installer une machine virtuelle, on
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
~~~
# 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
~~~
# 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
~~~
# ceph osd pool delete pool_name pool_name --yes-i-really-really-mean-it
# ceph tell mon.* injectargs --mon-allow-pool-delete=false
~~~
# Gestion des block devices
@ -193,38 +318,46 @@ Pour finir, on supprime le pool puis on active à nouveau la sécurité :
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
~~~
# 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
~~~
# 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
~~~
# 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
> ~~~
> # 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
# fdisk /dev/sdXY # suppression puis recréation de la partition
# partprobe
# e2fsck -yf /dev/sdXY
# resize2fs /dev/sdXY
~~~
@ -232,15 +365,19 @@ resize2fs /dev/vdb1
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
~~~
# 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
~~~
# 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.
> **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 complète.
## Utiliser les snapshots
@ -249,25 +386,25 @@ Pour accéder au nombre de réplicats :
### Création
~~~
rbd snap create rbd/foo@foo_$(date +%F)
$ rbd snap create rbd/foo@foo_$(date +%F)
~~~
### Liste
~~~
rbd snap ls rbd/foo
$ rbd snap ls rbd/foo
~~~
### Rollback
~~~
rbd snap rollback rbd/foo@$SNAPNAME
$ rbd snap rollback rbd/foo@$SNAPNAME
~~~
### Suppression
~~~
rbd snap rm rbd/foo@$SNAPNAME
$ rbd snap rm rbd/foo@$SNAPNAME
~~~
**TODO** ajouter la partie protection et clonage des snapshots
@ -281,15 +418,15 @@ rbd snap rm rbd/foo@$SNAPNAME
Il est nécéssaire d'avoir un serveur de méta-données pour utiliser CephFS :
~~~
ceph-deploy mds create $CEPH_NODE
$ ceph-deploy mds create $CEPH_NODE
~~~
On créer le pool de données et de méta-données :
~~~
ceph osd pool create cephfs_data $PG_NUM
ceph osd pool create cephfs_metadata $PG_NUM
ceph fs new $FS_NAME cephfs_metadata cephfs_data
$ ceph osd pool create cephfs_data $PG_NUM
$ ceph osd pool create cephfs_metadata $PG_NUM
$ ceph fs new $FS_NAME cephfs_metadata cephfs_data
~~~
@ -298,10 +435,10 @@ ceph fs new $FS_NAME cephfs_metadata cephfs_data
Il suffit de monter le CephFS, il sera utilisable :
~~~
KEY=$(awk '/key/ { print $NF }' </etc/ceph/ceph.client.admin.keyring)
mkdir /mnt/mycephfs
mount.ceph $CEPH_MON:/ /mnt/mycephfs/ -o 'name=admin,secret=$KEY'
cat <<EOF >/mnt/mycephfs/truth
$ KEY=$(awk '/key/ { print $NF }' </etc/ceph/ceph.client.admin.keyring)
$ mkdir /mnt/mycephfs
$ mount.ceph $CEPH_MON:/ /mnt/mycephfs/ -o 'name=admin,secret=$KEY'
$ cat <<EOF >/mnt/mycephfs/truth
slackware is the best
e ≃ 2.7181828
EOF
@ -312,58 +449,70 @@ On peut aussi utiliser FUSE :
**TODO** FUSE et sudo ?
~~~
ceph-fuse -k /path/to/ceph.client.admin.keyring -m $CEPH_MON:6789 ~/mycephfs
$ ceph-fuse -k /path/to/ceph.client.admin.keyring -m $CEPH_MON:6789 ~/mycephfs
~~~
# Troubleshooting
## Clefs introuvables
**TODO** ajouter les messages d'erreur
Si une commande `ceph` ou `rbd` renvoie une erreur contenant le message : `ERROR: missing keyring, cannot use cephx for authentication`, c'est que le fichier contenant la clef pour s'authentifier n'est pas accessible. Il y a trois possibilités, le fichier contenant la clef :
- n'est pas accessible, il faut revoir ses permissions ;
- n'existe pas sur la machine, il faut qu'un nœud du cluster lui envoie ;
- n'existe pas du tout car soit l'utilisateur n'existe pas soit il faut exporter sa clef.
# Troubleshooting
## 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
~~~
# timedatectl status | grep -q '^NTP synchronized: yes$' || timedatectl set-ntp true
~~~
Ceph devrait se réparer tout seul. La commande `watch ceph -s` permet de s'en assurer.
## Installation client impossible
## 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
~~~
# 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
~~~
$ 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
~~~
$ 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
$ 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.