[Ceph](https://ceph.io/) est une plateforme libre de stockage. Historiquement développé par [Sage Weil](https://en.wikipedia.org/wiki/Sage_Weil) à la suite d'une thèse en 2007, Ceph appartient désormais à Red Hat.
Ceph peut également s'apparenter à un « disque distribué auto-réparant » ou encore une sorte de « RAID-NG ». Le principe est de s'appuyer sur des disques répartis au sein de plusieurs ordinateurs reliés en réseau, et d'avoir une tolérance de panne avec réparation rapide et de permettre l'ajout de disques de façon simple.
Ceph permet la répartition d'objets (fichiers, morceaux de fichiers, blocs, etc.) dans un volume (pool) découpé en centaines de morceaux de plusieurs Go (PG). Chaque morceau (PG) est réparti sur 3 disques (OSD) situés dans des ordinateurs distincts.
L'algorithme CRUSH décrit ce découpage et rassemble toutes les informations dans une CRUSH map.
Un cluster Ceph est constitué de démons `osd` pour chaque disque, 3 démons `monitor` et 1 démon `manager`. Si besoin de faire du CephFS il faudra avoir un ou plusieurs démons `mds`, et si besoin d'avoir un accès HTTP REST (compatible Amazon S3) des démons` rgw`.
Pour accéder à un cluster Ceph, un client Ceph peut le faire via RADOS : en mode bloc (RBD), en mode fichers (CephFS) ou en mode HTTP REST compatible Amazon S3 (RGW).
Dans cet exemple, chaque nœud - `ceph1`, `ceph2` et `ceph3` - a 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.
Par défault, Ceph passe l'utilisateur ceph.admin. On peut passer en paramètre des commandes rbd et ceph le nom et le fichier qui contient la clef de l'utilisateur. Il est plus simple d'utiliser la variable d'environnement CEPH_ARGS :
Cet utilisateur n'a que les droits de lecture sur les informations du cluster, comme l'état de santé, et les droit de lecture et d'écriture pour le pool rbd. Il devrait donc être possible de faire :
Si on compte utiliser le block device pour y installer une machine virtuelle, il faut aller à la section [Libvirt](#rbd-et-libvirt). Sinon, il ne reste qu'à le formater puis à le monter :
Si on souhaite redémarrer un des nœuds du cluster, on commence par désactiver le balancing du cluster temporairement. L'objectif est d'empêcher le cluster de répliquer les objects perdus ailleurs. Sur un des nœuds:
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 renverra 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 :
> Depuis peu, il est facultatif de donner l'option `-k` quand l'option `-n` est déjà présente si le fichier de clef de l'utilisateur est présent dans sous cette forme : `/etc/ceph/ceph.$CEPH_USER_NAME.keyring`.
> Il est suffisant de donner la clef avec l'option `-k`, le nom est facultatif.
La seconde méthode va, en plus de la création de l'utilisateur, afficher sa clef. On peut la récupérer sur la sortie standard ou via l'option `-o` pour l'écrire dans un fichier. 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`.
Cette variable définie à partir de quel seuil on considère qu’un OSD est bientôt plein. Si un OSD atteint ce ratio, ça déclenchera un *warning* pour l’état de santé du cluster. La valeur par défaut est 85%, mais elle est probablement trop élevée. On peut s’aider de ce calculateur en ligne pour choisir le ratio: [Ceph: Safely Available Storage Calculator](https://florian.ca/ceph-calculator/)
Par exemple, pour un cluster de 3serveurs OSD cumulant 24Tio d’espace disque chacun (72Tio au total), on mettre le ratio à 67%. Dans le fichier `/etc/ceph/ceph.conf`:
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 » :
Dans la section `POOLS`, la colonne `USED` devrait correspondre à la colonne `STORED` multiplié par le nombre de réplication des objets. Ici, les objets sont répliqués trois fois (un objet et deux copies). Pour le *pool*`libvirt`, on a: 8.9 × 3 = 26.7Tio, qu’on peut arrondir à 27Tio.
La colonne `MAX AVAIL` donne une estimation de la quantité de données qu’on peut ajouter dans un *pool*. Cette valeur prend notamment en compte le nombre de réplication et la valeur `mon_osd_full_ratio`.
Il est possible de faire en sorte que Libvirt parle à Ceph directement. Cela facilite l'allocation de RBD a une machine virtuelle. On peut déjà créer un RBD depuis le client:
~~~
# qemu-img create -f rbd rbd:rbd/vm0-data 8
~~~
Une autre forme permet de préciser l'utilisateur que par lequel QEMU doit passer. Il est préférable d'utiliser cette forme:
Sur la machine cliente, on ajoute la clef de l'utilisateur libvirt dans un secret:
~~~
# cat > secret.xml << EOF
<secretephemeral='no'private='no'>
<usagetype='ceph'>
<name>client.libvirt secret</name>
</usage>
</secret>
EOF
# virsh secret-define --file secret.xml # Donne la valeur de UUID
# virsh secret-set-value --secret $UUID --base64 $KEY # KEY est dans le fichier /etc/ceph/ceph.client.libvirt.keyring
~~~
Il est maintenant possible d'ajouter un RBD à une machine virtuelle. Par exemple pour ajouter le disque vm0-data du pool rbd à la VM vm0 (ne pas oublier de renseigner l'UUID) :
Il est possible d'étendre ou de réduire un block device au sein d'un pool. Si des machines virtuelles ont été installées sur le block device en question, il n'est pas nécessaire de les éteindre. On suppose ici que l'on souhaite étendre le block foo de 8 Gio à 16 Gio. On peut exécuter la commande suivante depuis n’importe quel nœud, y compris depuis un client.
> **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.
Cette commande va créer un utilisateur `client.cephuser`. Il aura accès au répertoire `/dir0` en lecture et en écriture et `/dir1` en lecture seule. On pourra monter le FS de cette manière :
Il est possible que le problème vienne du client. Dans ce cas, l'élément bloquant est certainement apparmor. On suppose ici qu'on souhaite supprimer apparmor.
Alors que apparmor est encore installé et actif, on identifie les processus pris en charge par apparmor :
~~~
# aa-status
~~~
Pour ne pas s'embêter, on dit a apparmor d'arrêter de sécuriser tous les processus :
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* 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 :
Si un fichiers *.keyring dans /etc/ceph est absent ou a été supprimé, tout va bien, on peut le générer. Si l’utilisateur est `client.libvirt`, on peut exécuter ces commandes sur un des nœuds du cluster.
**Attention**: si le *warning*`client is using insecure global_id reclaim` est aussi présent, il faut d'abord mettre à jour Ceph sur les nœuds clients ou désactiver le *warning* pour un moment. Pour désactiver le *warning*:
```bash
ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w # 1 week
```
Pour désactiver la fonctionnalité:
```bash
ceph config set mon auth_allow_insecure_global_id_reclaim false
```
Source: [Ceph Documention - Health checks](https://docs.ceph.com/en/latest/rados/operations/health-checks/#auth-insecure-global-id-reclaim-allowed)