Ceph

De Justine's wiki
Aller à la navigation Aller à la recherche

Sources

Présentation

Wikipédia : "Ceph est une solution libre de stockage distribué (software-defined storage) très populaire qui propose trois protocoles en un avec : Bloc, Fichiers & Objet (S3). Les objectifs principaux de Ceph sont d'être complètement distribués 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 permet de disposer d'un cluster de partage de fichiers assez efficace et manageable. Il est associé à son propre FS, CephFS.

Une architecture Ceph peut contenir plusieurs rôles, qui correspondent chacun à un daemon:

  • Une machine d'administration on l'on installera cephadm. Celle-ci aura donc le rôle _adm dans le cluster.
  • Le rôle ceph-mon (monitor), qui maintient une série de maps de l'état du cluster. Celles-ci sont critiques pour que les daemon Ceph puissent se coordonner. Les monitors gèrent aussi l'authentification entre les daemons et les clients et servent de point d'accès aux FS. Il en faut au moins 3 pour avoir de la redondance et de la haute dispo.
  • Des OSD (Object Storage Daemon), qui stockent les données, s'occupent des réplications et de la recovery. Il en faut au moins 3 pour avoir de la redondance et de la HA. C'est le gros du cluster.
  • Des serveurs MDS (Metadata Server). Ils stockent les métadonnées pour CephFS. Cela permet à un système POSIX de lancer des commandes comme ls, find... sans placer une grosse charge sur les MDS.
  • Le rôle manager (ceph-mgr), dont le but est de fournir du monitoring additionnel ainsi que des interfaces pour les systèmes externes.

Globalement, ces rôles seront gérés automatiquement par le cluster, à l'exception des OSD.

Une seule machine peut recouvrir plusieurs rôles, notamment dans le cadre d'un lab.

Je suis sur Debian.

Installation, prérequis

NB: Ceph dispose de plusieurs méthodes d'installation. La méthode Ansible semble à postériori intéressante. Il est visiblement également possible de conteneuriser ou non les daemon; dans la suite j'ai tout fait avec docker. Les docs Ceph sont vraiment compliquées à suivre.

Je vais ici passer par la méthode CephADM, qui est l'installation en mode paquet. Il existe aussi Rook, qui permet une installation sur un cluster k8s.

Outre les Prérequis hardware, les prérequis pour notre cluster sont:

  • Python 3
  • Systemd
  • Docker
  • Une synchro temporelle
  • LVM est recommandé pour gérer notre stockage. On va utiliser un lv dédié, en xfs ou ext4.
  • Les machines doivent être accessibles en root, via clef SSH, sans mot de passe. depuis la machine cephadm.
  • Il vaut mieux avoir de la résolution DNS et des fichiers hosts correctement peuplés. Cephadm n'aime pas quand le nom de sa machine est un fqdn, même si on peut normalement passer outre.
  • Un réseau partagé entre les machines. Cela semble évident, mais la gestion des réseaux peut demander un peu de finesse.
  • Prévoir de la place dans le /boot et le /var.
  • ntp ! Les machines doivent être à l'heure.

Les ports à ouvrir:

Pour les monitor:

  • 3300/tcp et 6789/tcp
sudo iptables -A INPUT -i {iface} -p tcp -s {ip-address}/{netmask} --dport 6789 -j ACCEPT

Pour les OSD, MDS et managers:

  • Tout le range 6800-7300/tcp
sudo iptables -A INPUT -i {iface} -m multiport -p tcp -s {ip-address}/{netmask} --dports 6800:7300 -j ACCEPT

NB : cephadm configure firewalld tout seul, si celui-ci est présent.

Avant tout : logs

Ceph peut être fort casse-pieds, et n'est pas explicite dans ses erreurs.

Le meilleur moyen de débugger est de voir les logs: 

ceph log last cephadm

Mise en place avec ceph-adm

Je pars de ma machine ceph-mon.

Je récupère le script d'install: 

curl --silent --remote-name --location https://github.com/ceph/ceph/raw/pacific/src/cephadm/cephadm
chmod +x cephadm

Le script d'install ajoute les repos ceph à apt, donc pas de questions à se poser ici.

Je pourrais utiliser le script tel quel, mais je vais l'installer ainsi que la dépendance ceph-common. On ajoute les repos pour la version "pacific", la dernière en date quand j'écris ces lignes. 

./cephadm add-repo --release pacific
./cephadm install
./cephadm install ceph-common

Initialisation du cluster

Toujours sur ceph-mon, je vais commencer le cluster, à commencer par le monitor. Il faut lui dire d'utiliser docker et pas podman. Ce noeud sera monitor, mais aussi admin et manager. 

sudo cephadm --docker bootstrap --mon-ip 192.168.1.208

Puis je vais ajouter la clef SSH de bootstrap sur tous mes hôtes, y compris le ceph-mon, depuis ce dernier. 

ssh-copy-id -f -i /etc/ceph/ceph.pub root@host

Utilisation du shell Ceph

Le shell Ceph est un shell bash contenant toutes les commandes nécessaires. Pour y accéder, il suffit de faire: 

cephadm shell

Ajouter des hosts

Lorsque l'on ajoute des hôtes, on rajoute la possibilité de faire tourner différents daemons qui viendront contribuer au cluster.

Je vais ensuite ajouter mes hôtes. 

sudo ceph orch host add ceph-mon ceph-mon.sq.lan

...Pour chaque hôte.

Je peux enfin les lister. 

cephuser@ceph-mon:~$ sudo ceph orch host ls
HOST              ADDR           LABELS   STATUS  
ceph-mon.sq.lan   192.168.1.208            
ceph-osd1.sq.lan  192.168.1.209            
ceph-osd2.sq.lan  192.168.1.210

Supprimer des hôtes

En ligne

Je peux supprimer un hôte en ligne: 

ceph orch host drain monhote

Cela lui applique le label "_no_schedule", voir la section sur les labels. Cela le vide également de tout daemon Ceph. C'est important !

Et ensuite suivre la procédure de suppression des osd: 

ceph orch osd rm status

Je peux, une fois que c'est fini, le sortir du cluster. 

 ceph orch host rm <host> --force


Hors ligne

Si mon hôte n'est plus en ligne (exemple : il a explosé, il a pris feu, il a été écrasé par un bulldozer...), je peux le sortir du cluster direct. 

ceph orch host rm <host> --offline --force

Attacher des LV, état du cluster

Je vais désormais attacher mes LV dédiés (ils s'appellent debian-vg/CephLV). 

ceph orch daemon add osd ceph-mon:debian-vg/CephLV

Pour chaque hôte, depuis ma machine admin.

Puis je regarde l'état de mon cluster. 

ceph -s

Dashboard

Ceph dispose d'un dashboard web. Je vais le déployer sur mon ceph-mon. Il est normalement activé par la commande de bootstrap qui va afficher les détails de connexion. Si il n'est pas présent: 

ceph mgr module enable dashboard
ceph dashboard create-self-signed-cert

Je créée un fichier contenant le mdp de mon futur compte admin (nommé dashboardpw), puis je créée un utilisateur nommé admin: 

ceph dashboard ac-user-create admin -i ./dashboardpw administrator

À partir de là, les possibilités sont nombreuses. Ceph propose beaucoup de fonctionnalités très cool. Je vais essayer CephFS.

CephFS

Depuis mon ceph-mon, je vais créer un fs (destiné à mon cluster swarm, d'où son nom). 

ceph fs volume create swarm_storage

Puis je vais le monter sur mes machines. La doc précise que l'on a 2 possibilités:

  • Le client FUSE : FUSE est un module du kernel servant à permettre aux users d'accéder au FS sans avoir à modifier le kernel. Pour Ceph, le FS sera donc monté dans le userspace, et pas par le kernel. Ce n'est pas la meilleure solution, mais elle a le mérite de proposer une alternative. Doc
  • Via un driver kernel dédié : comme n'importe quel FS, donc. Recommandé. doc

Je vais passer par la méthode kernel.

Prérequis

Prérequis: Les clients doivent avoir une conf minimale et un keyring. Donc, sur chaque client: 

mkdir -p -m 755 /etc/ceph
ssh root@ceph-mon.sq.lan "sudo ceph config generate-minimal-conf" | sudo tee /etc/ceph/ceph.conf
chmod 644 /etc/ceph/ceph.conf

Ces commandes vont, notamment, récupérer une conf minimale pour notre client depuis notre noeud admin (ceph-mon.sq.lan en l'occurence). Si mon cluster avait plusieurs monitors au moment de la récupération de la conf, il seront pris en compte plus tard par le fstab du client (qui disposera alors de plusieurs points d'accès au cluster). Sinon, si des monitors sont apparus, que la conf à changé, etc... il est toujours possible de plus tard relancer la commande "sudo ceph config generate-minimal-conf" sur un noeud admin et de recopier la conf générée dans /etc/ceph/ceph.conf sur le client.

J'ai donc une conf minimale récupérée depuis mon node admin; celle-ci va permettre à mon client de récupérer ses données via tous les mmonitors du cluster. Je vais ensuite récupérer un keyring pour chaque host. 

ssh root@ceph-mon.sq.lan "sudo ceph fs authorize swarm_storage client.swarm / rw" | sudo tee /etc/ceph/ceph.client.swarm.keyring

Ici:

  • swarm_storage est le nom du FS créé juste avant.
  • dans client.swarm, swarm est le nom du client. C'est bien d'en avoir un. Il peut servir à plusieurs machines qui accèdent au même fs.

Bien remplacer les valeurs ! Enfin, je mets les bons droits: 

chmod 600 /etc/ceph/ceph.client.swarm.keyring

Je peux vérifier mes clients depuis mon hote ceph-adm: 

ceph auth get client.swarm

Packages

Sur mes clients, je peux avoir besoin des packages Ceph. Il existe plusieurs méthodes, mais en gros, il faut utiliser les repos Ceph. 

sudo apt-get install software-properties-common
sudo apt-add-repository 'deb https://download.ceph.com/debian-pacific/ {codename} main'
wget -q -O- 'https://download.ceph.com/keys/release.asc' | sudo apt-key add -

Remplacer {codename} par le codename de la version de Debian. Je peux ensuite installer cephfs-shell et ceph-common (qui est nécessaire).

Montage (mono-monitor)

Je vais monter mon fs dans /data. 

mkdir /data

Ceph utilise un petit helper pour aider au montage. Je vérifie qu'il est bien présent (normalement oui si ceph-common est installé). 

stat /sbin/mount.ceph

Je lance la commande.J'ai eu du mal à la trouver, celle-là... La doc est absurde. 

mount.ceph 192.168.1.208:6789:/ /data -o name=swarm

(192.168.1.208 est l'IP de mon ceph_mon). Il est possible de passer plusieurs monitors en les séparant par des virgules, à tester.

Je peux ensuite m'y rendre. Je peux aussi voir dans l'interface web que j'y suis bien connectée.

fstab

Je vais mettre ce montage dans le fstab pour ne pas le perdre. 

192.168.1.208:6789:/ /data ceph name=swarm,noatime,_netdev	0	2

Ce montage se fera en fonction de la conf dans /etc/ceph/ceph.conf, créée lors de l'étape des prérequis.

Gestion du cluster

RAPPEL : l'interface web de Ceph est un excellent moyen de comprendre son cluster.

Labels

Les labels sont des tags sous forme libre, que l'on peut appliquer aux hôtes. Il peuvent être ajoutés à la création de l'hôte ou après: 

ceph orch host add my_hostname --labels=my_label1
ceph orch host add my_hostname --labels=my_label1,my_label2

ceph orch host label add my_hostname my_label

#Retirer un label
ceph orch host label rm my_hostname my_label

Il existe 3 labels spéciaux qui ont une signification pour ceph:

  • _no_schedule: Do not schedule or deploy daemons on this host.
  • _no_autotune_memory: Do not autotune memory on this host.
  • _admin: Distribute client.admin and ceph.conf to this host. Appliqué automatiquement au premier hôte du cluster.

Rôles dans le cluster

Lister les hôtes et leur daemons

Je peux lister mes hôtes 

sudo ceph orch host ls

Et voir les daemons d'un hôte 

sudo ceph orch ps monhote

Mode maintenance

Je peux placer un hôte en mode maintenance, ce qui va placer tous ses daemons en mode maintenance: 

ceph orch host maintenance enter <hostname> [--force]
ceph orch host maintenance exit <hostname>

Gestion des monitors

Ceph modifie lui-même le nombre de monitors en fonction de la taille du cluster, d'après la documentation. Plus le cluster grandit, et plus on ajoute de monitors. Dans mon cas, mon cluster à 3 machines n'as qu'un seul monitor. Si toutes nos machines sont dans le même subnet, il n'y a pas de gestion à faire.

On peut désactiver ce comportement avec: 

ceph orch apply mon --unmanaged

Ce qui permet d'ajouter à la main un monitor avec: 

ceph orch daemon add mon *<host1:ip-or-network1>

Gestion réseau des monitors

J'en ai marre d'écrire. La doc dit: To designate a particular IP subnet for use by ceph monitor daemons, use a command of the following form, including the subnet’s address in CIDR format (e.g., 10.1.2.0/24): 

ceph config set mon public_network *<mon-cidr-network>*

For example: 

ceph config set mon public_network 10.1.2.0/24

Cephadm deploys new monitor daemons only on hosts that have IP addresses in the designated subnet.

You can also specify two public networks by using a list of networks: 

ceph config set mon public_network *<mon-cidr-network1>,<mon-cidr-network2>*

For example: 

ceph config set mon public_network 10.1.2.0/24,192.168.0.1/24

Gestion des serveurs MDS

Les services MDS sont utilisés par les FS. Tout comme les monitors, ils semblent par défaut gérés automatiquement.

On peut néanmoins en ajouter; ce sera particulièrement utiles pour les gros FS. Il est recommandé que les MDS soient hébergés par des serveurs particulièrement efficaces niveau CPU en single-

Il existe plusieurs méthodes autopmatisées (notamment ceph-ansible), voici la méthode manuelle:

  • Create an mds directory /var/lib/ceph/mds/ceph-${id}. The daemon only uses this directory to store its keyring.
  • Create the authentication key, if you use CephX:
sudo ceph auth get-or-create mds.${id} mon 'profile mds' mgr 'profile mds' mds 'allow *' osd 'allow *' > /var/lib/ceph/mds/ceph-${id}/
  • Start the service:
sudo systemctl start ceph-mds@${id}
  • The status of the cluster should show:
mds: ${id}:1 {0=${id}=up:active} 2 up:standby
  • Optionally, configure the file system the MDS should join (Configuring MDS file system affinity):
ceph config set mds.${id} mds_join_fs ${fs}

Pour les retirer:

  • (Optionnal) Create a new replacement Metadata Server. If there are no replacement MDS to take over once the MDS is removed, the file system will become unavailable to clients. If that is not desirable, consider adding a metadata server before tearing down the metadata server you would like to take offline.
  • Stop the MDS to be removed.
sudo systemctl stop ceph-mds@${id}
  • The MDS will automatically notify the Ceph monitors that it is going down. This enables the monitors to perform instantaneous failover to an available standby, if one exists. It is unnecessary to use administrative commands to effect this failover, e.g. through the use of ceph mds fail mds.${id}.
  • Remove the /var/lib/ceph/mds/ceph-${id} directory on the MDS.
sudo rm -rf /var/lib/ceph/mds/ceph-${id}

Upgrade de Ceph

Vérifier que tous les noeuds sont online: 

ceph -s

Lancer l'upgrade: 

ceph orch upgrade start --ceph-version <version>

Par exemple: 

ceph orch upgrade start --ceph-version 16.2.6

Gestion du réseau

Ceph utilise deux notions de réseau:

  • Le réseau dit "public network" est celui sur lequel le cluster sera interrogé par les clients; et si on utilise qu'un seul réseau pour notre cluster, tout se passera par là. Dans le fichier de conf, il peut être configuré avec:
[global]
    public_network = 192.168.x.x/24

On a aussi la notion de réseau de cluster. Ce réseau servira à faire transiter les heartbeats des OSD, la réplication, et les recovery... Bref tout le trafic du cluster en lui-même. Avoir un réseau de cluster peut améliorer les performances de celui-ci. Il se déclare dans la conf avec: 

[global]
    cluster_network = 172.16.x.x/24
Récupérée de « https://wiki.squi.fr/index.php?title=Ceph&oldid=2089 »