Ceph-alopod

Cet article décrit la migration d’un déploiement Ceph existant vers une version conteneurisée sur Ubuntu 18.04.

Public visé : administrateurs Ceph voulant faire la migration vers les conteneurs en avec le playbook ceph-ansible officiel.

Par Gauvain Pocentek, Consultant Cloud

Migrer Ceph vers un déploiement conteneurisé sur Ubuntu 18.04 : retour d’expérience

Ceph @ Obectif Libre

Nous utilisons Ceph en interne pour 2 raisons :

  • stocker nos backups via la RadosGW
  • faciliter l’intégration d’outils avec Ceph : simple et rapide si le cluster est déjà disponible.

Le cluster Ceph est mutualisé avec les nœuds compute de notre OpenStack. Cette configuration fonctionne très bien, sauf pour les mises à jour. La mise à jour de Ceph ou d’OpenStack peut devenir compliquée à cause de conflits de dépôts ou de paquets.

Nous avons donc décidé de passer aux conteneurs pour Ceph, afin de faciliter les montées de version. Le projet ceph-ansible supporte les déploiements conteneurisés, ainsi que la migration d’un déploiement standard vers la version avec conteneurs. Ayant utilisé ce projet depuis le déploiement initial, nous avions confiance dans la réussite de l’opération ! A part les problèmes mineurs décrits dans cet article, la migration s’est passée sans difficulté majeure.

Comment passer aux conteneurs

Les étapes sont :

  1. Mise à jour de la configuration du playbook pour activer la version conteneurisée
  2. Exécution du playbook de migration
  3. Enjoy

Le changement de configuration consiste en l’ajout de ces 2 lignes dans host_vars/all.yml :

# activation de la version conteneurisée
containerized_deployment: true

# définition explicite de la version voulue
ceph_docker_image_tag: latest-mimic

Le liste des tags disponibles est accessible sur le docker hub.

Une fois les changements de configuration faits, exécution du playbook :

$ ansible-playbook infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml

Simple, mais quelques problèmes sont survenus. Si vous utilisez Ubuntu, il est fort probable que vous les rencontriez aussi. Voici comment nous avons corrigé ces problèmes.

Les problèmes

Paquets Docker

Le playbook installe le paquet docker disponible dans les dépôts Ubuntu. Si docker a déjà été installé via les dépôts docker.io, le playbook échouera.

Nous avons contourné le problème en désinstallant les paquets docker car nous n’avions pas de conteneur critique actif. Si ce n’est pas possible pour vous, il faut alors supprimer les tâches d’installation du playbook.

Conflits d’IDs

Un problème plus gênant est la différence d’ID pour le groupe et l’utilisateur Ceph entre le système et les conteneurs. Pendant la migration du premier nœud OSD, les conteneurs n’ont pas démarré correctement à cause d’un problème de droits : l’utilisateur ceph n’avait pas les droits d’écriture dans /var/lib/ceph.

Nous avons donc changé les droits sur le dossier en question pour que son contenu appartienne à l’utilisateur et au groupe 167, ID de ceph dans les conteneurs. Mais Ceph était toujours incapable d’écrire sur /var/lib/ceph/osd/ceph-*/block : un lien symbolique pointant sur un périphérique disque. Les droits d’écriture sur les disques des OSDs sont gérés sur le système hôte par udev, avec des règles définies dans /lib/udev/rules.d/95-ceph-osd.rules. La méthode la plus sûre et efficace pour appliquer les règles avec le nouvel ID a été le redémarrage des nœuds OSD, les uns après les autres.

Le process pour la préparation de chaque nœud a été :

# sed -i s/64045/167/g /etc/group /etc/passwd
# chown 167:167 /etc/ceph
# chown -R 167:167 /var/lib/ceph
# reboot

Une fois ces actions réalisées sur toutes les machines, le playbook de migration s’est exécuté sans problème.

Conclusion

Bien que la procédure de migration vers un déploiement de Ceph conteneurisé soit simple, un peu de préparation est nécessaire si le système hôte est Ubuntu. Les migrations sur des systèmes RedHat ou CentOS ne devraient pas poser de problème, l’ID 167 étant déjà utilisé par défaut.

Ceph a une fois de plus prouvé sa robustesse : les opérations en cours sur le cluster pendant la perte du premier nœud OSD n’ont pas du tout été impactées, et la migration a été transparente !