Intégration de cluster Ceph

La solution de stockage distribué Ceph s’appuie sur un cluster de serveurs dit « standard » et d’éléments de stockage également standards pouvant mélanger différents types de disques mécaniques, SSD ou même NVMe.

L’architecture d’un cluster Ceph repose sur différents composants :

des nœuds dit « mon » chargés d’orchestrer la répartition et l’accès aux données. Ils doivent être au minimum de 3.
des nœuds dit « osd » contenant les disques où sont stockées les données.

Redondance

Elle est native (au niveau du cluster lui-même et du protocole « rbd » qui permet d’y accéder) et permet d’autoriser aussi bien la perte d’un ou plusieurs disques que d’un ou plusieurs serveurs (« osd » ou « mon »).

Aucun système de type RAID n’est à mettre en œuvre. Ceph est conçu pour assurer l’intégrité des données, en cas d’incident réseau, serveur ou disque le cluster bloquera tout accès si les conditions de réplication configurées ne sont plus réunies. La répartition des données peut utiliser différents mécanismes :

une réplication simple : chaque élément est écrit sur X disques en même temps. X étant paramétrable par « pool »(voir plus bas) de disques.
une réplication avec correction d’erreur : fonctionne comme les systèmes RAID 5 ou 6, en utilisant des « disques » de « parité ».

Répartition de charge

Les opérations de lecture et écriture sont réparties sur l’ensemble des éléments de stockage.

Différents volumes de stockage

Les disques des serveurs « osd » sont placés dans des groupes nommés « pool », selon des règles permettant de définir :

le type de disque à inclure dans le pool
le type de serveur à inclure dans le pool

On peut ainsi créer des pools rapides, utilisant uniquement des disques SSD, ou des pools de stockage plus lent utilisant des disques mécaniques.

Mais on peut également assurer une répartition géographique si les serveurs sont placés par groupes dans des emplacements distincts et mettre en œuvre par exemple un plan de reprise d’activité entre deux sites ou baies.

Évolutivité

Une capacité d’évolution simple : que ce soit pour avoir plus d’espace de stockage ou plus de performance, il suffit d’ajouter des disques aux serveurs existants ou d’ajouter des serveurs. Il n’est pas nécessaire d’avoir du matériel en tout point identique (mais un socle minimum doit être conservé si on ne veut pas dégrader les performances).

Architecture réseau préconisée

La solution Ceph nécessite idéalement 3 réseaux distincts :

Le réseau dit « cluster »

C’est par celui-ci que sont répliquées les données lors des écritures, mais également pour maintenir la redondance lors de la perte d’un élément de stockage. Son débit doit en particulier être suffisant pour qu’un cluster qui vient de perdre un nœud (donc un certain nombre de copies des éléments stockés), quitte rapidement ce mode dégradé en recréant les copies manquantes sur les autres nœuds et revenir en situation optimale en terme de redondance. Dans la pratique il s’agit en général d’un réseau 10 Gb/s, parfois 40 Gb/s. Il doit également être redondant (deux interfaces par serveur, deux switchs) afin d’autoriser la panne et de faciliter la maintenance.

Le réseau dit « client »

C’est ce réseau qui permet aux serveurs (hyperviseurs, serveurs de stockage, etc.) d’accéder aux données. Le débit et le niveau de redondance est fonction du besoin, mais on utilise souvent un réseau redondé en 10 Gb/s également.

Le réseau utilisateur

Il s’agit du réseau en général existant, permettant aux utilisateurs d’accéder aux serveurs d’applications.
Accès aux données

Ceph est un cluster stockant des « objets ». Différents protocoles permettent d’y accéder :

radosgw : permet comme Swift ou Amazon S3 d’accéder directement au cluster pour y stocker des objets (fichiers ou autre), sans notion de « système de fichier »
rbd : permet à des solutions de virtualisation de stocker directement des images disques.
Cephfs : système de fichier s’appuyant directement sur le cluster Ceph.

Lorsqu’il s’agit de fournir des services hébergés sur des machines virtuelles, c’est donc souvent le protocole « rbd » qui est utilisé. Si un export de type CIFS ou NFS est nécessaire, il suffit de mettre en œuvre une machine virtuelle reliée à un disque via rbd et exportant les données via le protocole souhaité.

Performances

Ceph peut offrir une grande palette de performances selon les besoins. Easter-eggs configure généralement des clusters mixtes comportant un ou plusieurs pools de stockage rapide basés sur des SSD, et lent basé sur des disques mécaniques. Ce type d’architecture permet de répondre au besoin des solutions de virtualisations et applicatives déployées, en optimisant les coûts.

Il est à rappeler que Ceph est une solution logicielle de stockage distribué et qu’il n’est pas possible d’obtenir des performances égales à un stockage de même type (SSD par exemple) déployé directement sur un serveur hébergeant l’application.

Néanmoins, la solution Ceph (comme ses concurrentes) permet de déployer de grand volumes de stockage et de disposer d’une souplesse bien supérieure au déploiement de serveurs physiques dédiés.

Nous vous invitons à découvrir sur notre blog des salariés une analyse détaillée des performances d’un cluster Ceph