You are currently viewing Ceph

Ceph

Dans ce billet nous vous proposons d’explorer les caractéristiques d’une solution de Stockage Distribué qui fait référence dans le domaine.

Mais en préambule qu’est-ce que le stockage distribué ? Il s’agit d’un système de stockage réparti sur un certain nombre de nœuds et qui permet une croissance dynamique à la fois de sa volumétrie et de sa performance. Il suffit de rajouter une unité de traitement/stockage (en général du commodity hardware) pour augmenter la capacité globale de la solution.

Il existe sur le marché de nombreuses solutions qui répondent à ces critères, certaines sont propriétaires,  comme  Scality, Cleversafe, Amplidata, XtremIO ou d’autres, Open sources, comme HDFS, Gluster et Ceph.

A noter que Red Hat présente Ceph comme LA solution de stockage OpenStack.

Ceph est un projet open source qui offre via un cluster distribué un système de stockage objet, block et fichiers. Ceph est conçu pour être à la fois :
•    tolérant aux pannes (NoSPOF)
•    garantir l’intégrité des données
•    offrir une évolution dynamique (scale-out)
•    et  fonctionner sur du « commodity hardware ».

 

Architecture logique

 

Basé sur RADOS (A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters) , les clusters de stockage Ceph sont composés de deux de démons :

Ceph OSD : il stocke les données sur le nœud de stockage, gère la réplication des données, la récupération, le rééquilibrage et fournit des informations pour Ceph Monitor. On recommande 1 OSD par disque physique.

Ceph Monitor : il maintient une copie du « cluster map » (le dispatch et les métas data), c’est également lui qui gère la circulation des cluster map vers les autres Monitors et les nœuds OSD.
Un cluster Ceph peut ainsi contenir des milliers de nœuds de stockage. Une confirmation minimale sera toutefois toujours constituée d’un Ceph Monitor et de deux Ceph OSD.

LIBRADOS
La librairie de Ceph fournit des applications clients avec un accès direct au système de stockage objets basé sur RADOS, et fournit également la base pour certaines des fonctionnalités avancées de Ceph, y compris RADOS Block Device (RBD), RADOS Gateway, et le système de fichiers CephFS.

La Passerelle : RADOSGW est accessible via Amazon Simple Storage Services (S3) et OpenStack Swift Representational State Transfer (REST).

L’accès Block : RDB met à disposition un disque virtuel (Ceph Block)  qui peut être rattaché directement à un serveur Linux ou à des machines virtuelles (VM). Rados offre les fonctionnalités classiques du stockage blocs tels que les réplications, snapshot , thin provisioning , compression.. Ceph RADOS Block (RBD) est capable également de travailler en back-end avec OpenStack Block Storage.

Le File System : CephFS est un système de fichier compatible  POSIX qui s’appuie sur RADOS et offre de facto les mêmes avantages (disponibilité et sécurisation, ..) que ceux proposés en mode bloc.

 

Comment Ceph stocke-t’il les données

Ceph stocke les données d’un client comme des objets dans des pools de stockage. En utilisant l’algorithme de CRUSH (Controlled Replication Under Scalable Hashing), ce dernier calcule quel groupe de placement (PG) doit contenir l’objet, et quel  OSD Daemon doit stocker le groupe de placement. L’algorithme CRUSH permet ainsi au cluster de gérer dynamiquement, sa croissance (Scale-out), son rééquilibrage et la protection des données.

Ceph dispose de différents pools, ces derniers sont les groupes logiques permettant de stocker les objets. Ces pools sont constitués de PG (Groupes de Placement). Au moment de la création du pool, il est demandé de fournir le nombre de groupes de placements que le «pool» va contenir et le nombre de réplica d’objets (de valeur 3 par défaut).

Ci-dessous un schéma qui synthétise le placement des objets dans Ceph.

 

Pour résumer

  •   Un Pool contient des objets     

  •   Un PG contient la liste des différents objets placés dans les Pools

  •   Un objet appartient à un seul PG    

  •   Un PG appartient à plusieurs OSDs

 

La Protection des données

Depuis la version 0.80 Firefly Ceph propose deux types de protection de données :

•   Réplication : multiples copies de la source

  •   Erasure-code : codage et fragmentation de la source

La notion de RAID n’est plus d’actualité avec le stockage distribué. Le RAID n’étant pas en mesure d’assurer correctement ces fonctions de reconstructions dans des délais et à des coûts raisonnables (dès lors que l’on adresse des volumétries de plusieurs PetaOctet), la protection des données est remplacée par des processus de copies multiples ou de chunks spreading.

 

 

L’Erasure-coding requière moins d’espace de stockage comparé aux méthodes de réplication, classique ce qui amène dès que l’on introduit des volumétries importantes une réductions substantielle des coûts.
Sans rentrer dans les détails (c’est l’objet d’un billet à part entière) via la fonction d’erasure code, les données sont divisées en k fragments, puis combinées et codées avec n morceaux de données redondantes et finalement réparties sur différents nœuds du cluster.

On obtient ainsi seulement 50% d’overhead en erasure coding quand il faut compter 300% pour une réplication (par défaut 3x la source).

Ce gain de volumétrie induit en contrepartie un overhead de traitement cpu ainsi qu’une limitation sur certaines opérations d’écritures (écriture partielle).

 

Ceph hardware configuration

D’un point vue hardware une architecture Ceph se décompose en 4 éléments : Réseau, CPU , Mémoire et Disques

 

Réseaux

Le schéma ci-dessous illustre la configuration requise, rien d’extravagant pour un cluster. Des réseaux séparés et dédiés, un double attachement pour chacun des éléments de l’infrastructure (un seul lien actif). Pour un cluster de taille moyenne et non critique un lien 1Gb devrait être suffisant. Pour un environnement de production il est recommandé de disposer de liens 10 Go (la bande passante joue notamment un rôle primordiale dans les phases de reconstruction).

 

 

CPU

CPUUn seul core sera suffisant pour Mon (le Moniteur), qui maintient notamment les copies des cluster map.
L’OSD, lui fournit un effort bien plus important puisqu’il présente les données aux clients. Par ailleurs le choix du mode de protection des données (Réplication ou Erasure-code) va également influer sur la charge CPU nécessaire à ce traitement. Ainsi il faudra compter sur 2 cores pour l’OSD en mode réplication et 4 cores pour l’Erasure-code.

 

Le démon MDS (optionnel puisqu’il n’est nécessaire que si l’on implémente CephFS) est par contre très consommateur de CPU et un minimum de 4 cores sera requis.

 

Mémoire :

memoryConcernant la mémoire  le démon Mon qui va avoir besoin de réaliser des transferts rapides, un minimum de 2Go sera nécessaire. OSD pour une charge moyenne nécessitera un minimum de 1 Go par instance et 2 Go si l’on cherche à optimiser les performances. Pour rappel Ceph recommande un démon OSD par disque physique.

 

Disques :

disksUn cluster Ceph est composé de 2 types de besoins I/O. Une partie sera dédiée au stockage des données clients et l’autre aux journaux et aux données propre de l’OSD. Il est important de noter que chaque écriture est d’abord inscrite dans le journal puis transférée dans la zone Data et seulement ensuite l’acquittement est envoyé au client. On comprend vite que l’utilisation de disques performants pour le journal est essentielle. L’utilisation de disques SSD pour le journal est donc fortement préconisée. Il est également recommandé de ne pas associer plus de 4 journaux OSD par disque SSD.

Dav. C.

Note de l’auteur : nous n’avons ici aucunement l’intention de vanter ou de promouvoir un produit plutôt qu’un autre. La Société Olcya étant par nature indépendante de tout constructeur et éditeur, notre objectif n’est que de restituer des éléments factuels.

Laisser un commentaire