[….EN COURS…..]
Ceph est un stockage distribué orienté ojbect mais supporte également le stockage de fichiers et par blocs.
L’architecture de Ceph tient compte du SPOF : le traitement des donnés est distribué et en cas de panne sur un noeud specifique il est capable de s’auto-réparer.
https://ssup2.github.io/images/theory_analysis/Ceph/Ceph_Architecture.PNG
Type de stockage
Ceph possède 3 types de stockage :
- stockage d’objets
- stockage de blocs
- stockage de fichiers
Stockage d’objets
Lorsque Ceph utilise le stockage d’objets, la passerelle RADOS joue le rôle de client et de proxy.
La passerelle RADOS stocke et contrôle les objets à l’aide de Librados. L’API REST est appelée pour enregistrer les données et fournit des fonctions liées au compte ainsi que des fonctions de gestion de compartiment qui servent de dossiers dans le système de fichiers (compatible avec AWS S3 et Swift d’OpenStack).
Plusieurs passerelles RADOS peuvent être utilisées en même temps pour éviter le SPOF.
Le load balancing entre les passerelles RADOS n’est pas intégré dans Ceph.
Stockage par blocs
Lorsque Ceph fonctionne en tant que Block Storage, le module RDB du noyau Linux ou Librbd basé sur Librados devient un client de cluster RADOS. Le noyau peut recevoir et utiliser le stockage par blocs du cluster RADOS via le module RBD. QEMU peut se voir attribuer un stockage de bloc à donner aux machines virtuelles via Librbd.
Stockage de fichiers
Lorsque Ceph fonctionne en tant que stockage de fichiers, Ceph File System ou Ceph Fuse Daemon dans le noyau Linux devient un client du cluster RADOS. Le noyau Linux peut monter Ceph File Storage via Ceph Filesystem ou Ceph Fuse.
Cluster RADOS
Le cluster RADOS se compose de 3 parties :
- OSD (Object Storage Daemon)
- Monitor
- MDS (Meta Data Server)
OSD (démon de stockage d’objets)
https://ssup2.github.io/images/theory_analysis/Ceph/Ceph_Object.PNG
OSD est un démon qui stocke des données sous forme d’objets sur le disque. L’enregistrement sous forme d’objet signifie l’enregistrement des données sous forme de clé/valeur/métadonnées. [Figure 2] montre comment l’OSD enregistre les données. Les données sont stockées dans un endroit appelé Namespace, qui sert de dossier dans le système de fichiers. Le compartiment de la description de stockage d’objets ci-dessus est le même concept que l’espace de noms OSD. Les espaces de noms ne constituent pas une hiérarchie arborescente comme les dossiers dans le système de fichiers. Les métadonnées sont à nouveau composées de clé/valeur.
Un démon OSD distinct fonctionne pour chaque disque de nœud. Le disque utilise principalement un disque formaté avec le système de fichiers XFS. Cependant, les systèmes de fichiers ZFS et EXT4 peuvent également être utilisés, et la dernière version de l’OSD de Ceph utilise le BlueStore Backend pour utiliser directement le disque sans utiliser de système de fichiers séparé.
Moniteur
La carte de cluster est une information nécessaire au fonctionnement et à la maintenance du cluster RADOS et se compose de la carte de surveillance, de la carte OSD, de la carte PG, de la carte CRUSH et de la carte MDS. Monitor est un démon qui gère et maintient ces cartes de cluster. De plus, Monitor est responsable de la gestion de la sécurité de Ceph ou de la création de journaux. Plusieurs moniteurs peuvent être utilisés en même temps, et il est recommandé d’utiliser plusieurs moniteurs pour éviter le SPOF. Lorsque plusieurs moniteurs sont utilisés, le moniteur utilise l’algorithme Paxos pour faire correspondre le consensus de la carte de cluster stockée par chaque moniteur.
MDS (serveur de métadonnées)
MDS est un démon qui gère les métadonnées nécessaires pour fournir un système de fichiers compatible POSIX, et n’est nécessaire que lorsque Ceph fonctionne comme un stockage de fichiers. Stocke et gère les méta-informations de fichier telles que la hiérarchie des répertoires, le propriétaire et l’horodatage sous la forme d’objets dans le cluster RADOS.
https://ssup2.github.io/images/theory_analysis/Ceph/Ceph_MDS_Namespace.PNG
[Figure 3] montre l’espace de noms du système de fichiers Ceph. La forme arborescente représente la structure de répertoires du système de fichiers. Dans Ceph, l’arbre ou le sous-arbre entier est exprimé sous la forme d’un espace de noms. Chaque MDS ne gère qu’un seul espace de noms et ne gère que les métadonnées liées à l’espace de noms géré. L’espace de noms est modifié dynamiquement en fonction de l’état de chargement et de l’état de la réplique de l’arborescence.
Client (Librados, module RBD, système de fichiers Ceph)
Comme mentionné ci-dessus, Librados, le module RBD du noyau et le système de fichiers Ceph du noyau agissent en tant que clients du cluster RADOS. Le client se connecte directement au moniteur via la liste d’adresses IP du moniteur écrite dans le fichier de configuration par le gestionnaire Ceph et obtient les informations de carte de cluster gérées par le moniteur. Après cela, le client se connecte directement à OSD et MDS en utilisant des informations telles que la carte OSD et la carte MDS dans la carte de cluster et effectue les opérations nécessaires. Le consensus des cartes de cluster stockées par chaque client et moniteur est également mis en correspondance à l’aide de l’algorithme paxos.
CRUSH et CRUSH Map
https://ssup2.github.io/images/theory_analysis/Ceph/Ceph_PG_CRUSH.PNG
CRUSH est un algorithme qui détermine sur quel OSD placer un objet. Lors de la configuration d’une réplique, l’emplacement de la réplique est déterminé via CRUSH. [Figure 4] montre le processus d’attribution d’objets à l’OSD. Les objets sont attribués à un PG spécifique (groupe de placement) via le hachage d’ID d’objet. Et PG est à nouveau attribué à un OSD spécifique via PG ID et CRUSH. [Figure 4] suppose que Replica est défini sur 3. Par conséquent, CRUSH alloue 3 OSD par objet.
https://ssup2.github.io/images/theory_analysis/Ceph/Ceph_CRUSH_Map.PNG
CRUSH utilise une topologie de stockage appelée CRUSH Map. [Figure 5] montre la carte CRUSH. CRUSH Map est composé d’une couche d’unités logiques appelées buckets. Le bucket se compose de 11 types : racine, région, centre de données, salle, pod, pdu, rangée, rack, châssis, hôte et osd. La feuille de la carte CRUSH doit être un compartiment osd.
Chaque seau a une valeur de poids, et le poids représente le pourcentage d’objets de chaque seau. Si le poids du seau A est de 100 et que le poids du seau B est de 200, cela signifie que le seau B contient deux fois plus d’objets que le seau A. Par conséquent, en général, la valeur de poids du type de bucket osd est définie proportionnellement à la capacité du disque géré par l’OSD. Le poids des types de buckets restants est la somme des poids de tous les buckets inférieurs. Les nombres dans le seau de la [Figure 5] indiquent le poids.
CRUSH démarre à partir du compartiment racine de la carte CRUSH, sélectionne autant de sous-compartiments que de répliques et répète la même opération dans le compartiment sélectionné pour trouver le compartiment osd dans la feuille. Le nombre de répliques d’un objet est déterminé en fonction de la réplique définie dans Type de compartiment. Si 3 répliques sont définies pour le type de compartiment de rack et 2 répliques sont définies pour le type de compartiment de rangée, CRUSH sélectionne 3 compartiments de rack et sélectionne 2 compartiments de rangée, sous-compartiments du compartiment de rack sélectionné, pour chaque compartiment de rack. La réplique de est 6. Le critère de sélection du godet inférieur est déterminé en fonction de l’algorithme de godet défini pour chaque type de godet. Les algorithmes de compartiment incluent Uniform, List, Tree, Straw et Straw2.
Lire et écrire
https://ssup2.github.io/images/theory_analysis/Ceph/Ceph_Read_Write.PNG
L’une des caractéristiques de Ceph est que Ceph Client accède directement à l’OSD et gère les objets. [Figure 6] montre le processus de lecture/écriture de Ceph. Le client Ceph obtient les informations de carte CRUSH du moniteur de cluster RADOS avant d’exécuter la lecture/écriture. Après cela, le client peut utiliser la carte CRUSH et CRUSH pour trouver l’emplacement de l’OSD où se trouve l’objet à accéder sans communication externe séparée.
Parmi les OSD déterminés par CRUSH, le premier OSD est exprimé en tant qu’OSD principal. Dans le cas du processus de lecture, l’opération de lecture est effectuée en utilisant uniquement l’OSD principal. Dans le cas du processus d’écriture, le client envoie l’OSD principal avec des informations OSD supplémentaires dans lesquelles la réplique de l’objet sera enregistrée, avec l’objet. Lorsque l’OSD principal reçoit tous les objets du client, il transmet les objets reçus au reste des OSD. Une fois toutes les transmissions terminées, l’OSD principal envoie un accusé de réception d’écriture au client.