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 :
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.
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 :
~~~
# 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 :
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 :
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.
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 » :
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 :
> **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.
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.
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 :
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 :
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 :