Nous évoquions il y a peu de temps la tendance au “Software Defined” dans le stockage comme dans l’infrastructure et le réseau, et l’intérêt de de Ceph comme solution de stockage distribué. Suite au Meetup Ceph qui a eu lieu le 4 juillet dernier à Paris, nous vous proposons de découvrir les nouveautés de la dernière version de Ceph Jewel 10.2.

Rappelons pour commencer que Ceph est une solution de stockage software unifiée, distribuée et open source, construite dans l’objectif de gagner en performance, en disponibilité et en scalabilité. Cette nouvelle version de Ceph Jewel 10.2, fait suite aux versions Infernalis 9.2 (novembre 2015) et Hammer 0.94 (mars 2015).

Ceph est composé de 3 couches :

Rados : c’est le moteur de Ceph, qui stocke les données, leur placement sur le cluster, corrige les erreurs et le tout de manière autonome.
Librados : assure la communication entre Rados et les connecteurs en frontal.

Connecteurs :

• RadosGW, le connecteur objet compatible avec les API Amazon S3 et OpenStack SWIFT
• Rados Block Device (RBD), le connecteur bloc (équivalent SAN mais sur IP)
• CephFS, le connecteur filesystem distribué, enfin stable pour la production dans Jewel

Nouveautés de Ceph Jewel 10.2

Durant le Meetup, nous avons donc présenté les dernières nouveautés de Ceph Jewel 10.2 et évoqué les fonctionnalités expérimentales des prochaines versions, Kraken et Luminous, prévues respectivement pour Novembre 2016 et Avril 2017.

• Dorénavant tous les daemon Linux tournent avec l’utilisateur Ceph. Il fallait auparavant se contenter de l’utilisateur Root, ce qui pouvait poser des problèmes de sécurité.
• Gestion du module de sécurité SELinux et du daemon Systemd
• Ceph Ansible installer : permet d’automatiser l’installation, la configuration, les déploiements, les mises à jour, l’ajout et le retrait de noeuds. Une démonstration d’installation a d’ailleurs été faite durant le meetup.

Ceph FS

C’est la plus importante nouveauté de Ceph Jewel 10.2, une première version stable du FileSystem. Il reste cependant des limitations, par exemple dans cette version de CephFS, il n’est pas encore recommandé d’avoir plusieurs MDS actifs (mais 1 actif avec plusieurs passifs), et cela reste limité jusqu’aux prochaines versions.

Par défaut, la gestion des snapshots est désactivée, mais peut être activée à chaud. Pour le moment il n’y a pas de bugs connus mais la fonctionnalité n’a tout simplement pas encore été assez testée pour être validée en production. Par ailleurs, cette version propose aussi de nouveaux outils plus aboutis pour gérer la réparation et la restauration du filesystem, ainsi qu’une application pour gérer les exports (CephFS volume manager).

CephFS propose aussi un driver Manila, application OpenStack qui permet de faire des exports NFS et CIFS (comme un NAS).

Quels sont les apports en termes de performances ?

Les données sont écrites en direct sur les OSD (sans passer par un “proxy”). Donc pour augmenter les performances, on ajoute des OSD. Du côté des serveurs de metadata (MDS), on notera qu’il faut beaucoup de RAM, et de préférence des SSD si on ne veut pas ralentir l’écriture des fichiers.

A noter également que dans CephFS, il n’y a pas de limitation du nombre de fichiers et de taille de Filesystem. Ceci est dû à la possibilité d’utiliser plusieurs serveurs de metadata qui se partageront la gestion d’un subset du FS (Dynamic Subtree Partitioning). En fonction de ses besoins, on peut scaler le nombre de MDS pour augmenter les performances.

Côté sécurité et consistance des données :

• Amélioration du cache de Ceph, et un mécanisme de lock de fichier pour valider sa consistance (si le fichier est modifié coté serveur, il est invalidé dans le cache du client)
• Sécurité : il est maintenant possible de confiner un client à un dossier ou un namespace.

Certaines nouvelles fonctionnalités sont désactivées par défaut, comme le snapshot qui peut maintenant être renommé. Même chose pour le Directory Fragmentation, qui permet de découper un dossier en shards, et gagner en performance. Le Metadata Scrubbing, un filesystem check qui parcourt tout le filesystem, recherche les erreurs et les corrige si besoin, doit aussi être lancé de façon manuelle.

Ceph Jewel 10.2 introduit également de nouveaux outils de recovery pour reconstruire un filesystem corrompu, à partir de metadata.

Rados Block Device, le stockage Bloc

Dans ses précédentes versions, Ceph fonctionnait de façon complètement synchrone : dans le cas où on avait deux datacenters, l’écriture d’une donnée était immédiatement répliquée. Mais si les datacenters étaient éloignés, on avait des risques de forte latence et de dégradation des performances, peu acceptables par les applications. Ceph Jewel 10.2 introduit la possibilité de fonctionner en asynchrone, avec le daemon RBD Mirror, et ainsi de résoudre les problèmes de performance. Notons que le cluster distant étant en lecture seule, il est possible de basculer sur le second datacenter en cas de perte du premier (scénario de disaster recovery).

De nouvelles fonctionnalités RDB sont maintenant activées par défaut comme le deep flaten, l’exclusive lock, le fast diff et l’object map.

On citera également la nouvelle commande rdb du, qui donne la taille utilisée sur une image, ou l’interface ligne de commande améliorée, avec notamment plus d’aide et de l’auto-complétion.

Rados Gateway – Partie objet

La réplication multi-sites évolue, avec la possibilité de répliquer N zones dans N directions. Ceci est utile pour les scénarios de fail-over, fail-back et pour sécuriser les données sur un site distant.

On dispose également d’une interface NFS pour réaliser un export NFSv4 (utilisable dans le cadre d’une migration de données, mais pas dans un contexte de production).

Enfin, il est possible d’avoir des buckets sans index, ce qui peut être intéressant pour les applications nécessitant de très hautes performances : il est possible de by-passer l’index RGX, et de le gérer dans l’application.

Mises à jour des API

Amazon S3 :

• Authentification V4 AWS
• Connexion LDAP/AD
• Sites Web statiques
• Service de token de sécurité pour créer des authentifications à durée limitée (RGW STS)
• Compatibilité prochaine avec Kerberos et AD

Openstack :

• Authentification Keystone v3 (outil d’authentification OpenStack)
• Multi tenancy : séparation de tous les clients de la solution (le client A n’a pas accès aux données du client B)
• Object expiration : gère la durée de vie d’un fichier, il est possible de lui donner une durée de vie et de déterminer une action à la fin, le détruire, le déplacer ailleurs…
• Static cloud object : permet de contourner la limitation de Swift (5Go), et de découper le fichier, d’envoyer les shards en simultané, puis de les reconstruire sur le stockage
• Bulk Delete : pour la suppression de masse
• Object versioning : l’équivalent d’un Git pour les objets ; un système de pointeurs où seuls les changements sont écrits.

RADOS

Ici aussi, de nombreux changements, qui sont le plus souvent techniques. Commençons par l’arrivée d’un système de queue unifiée, qui permet également de prioriser les process (snaphots, IO, réparation du FS…).

Ext4 n’est plus recommandé et est remplacé par XFS : il n’y a plus de limitation sur le nombre de caractères. Rados utilisant des noms longs pour chaque OSD, cela pouvait poser des problèmes récurrents.

Cache tiering : amélioration du cache, qui permet d’aller chercher une donnée non pas dans le disque, mais en utilisant le cache comme proxy.

SHEC erasure code : une version améliorée de erasure coding qui permet de distribuer les données (le fichier est découpé en blocs et bits de parités). SHEC consomme plus d’espace, mais est plus efficace sur la reconstruction en prenant en compte 3 paramètres : le nombre de blocs, le nombre de bits de parités et le taux de résilience acceptable (nombre d’osd qui peuvent être perdus avant de perdre des données).

Enfin, Bluestore est actuellement proposé comme backend de stockage expérimental dans Ceph Jewel 10.2. Bluestore utilise RocksDB, une base de données non relationnelle. Développée par Facebook, RocksDB est une BDD ultra-performante et scalable: les données sont écrites en direct sur les blocs du disque, sans passer par filesystem; les metadata sont écrites ensuite. RocksDB permet de faire de la compression inline, c’est-à-dire la compression de la donnée avant de l’écrire; la base de données garantit la consistance des données, et effectue un checksum à chaque lecture.