réplication

A l'instar des clients Ceph, les OSD Ceph peuvent contacter les moniteurs Ceph pour extraire la dernière copie de la mappe de cluster. Les définitions OSD Ceph utilisent également l'algorithme CRUSH, mais ils l'utilisent pour calculer l'emplacement de stockage des répliques d'objets. Dans un scénario d'écriture classique, un client Ceph utilise l'algorithme CRUSH pour calculer l'ID de groupe de placement et l'OSD principal dans l'ensemble actif pour un objet. Lorsque le client écrit l'objet dans l'OSD principal, celui-ci trouve le nombre de répliques qu'il doit stocker.

La valeur se trouve dans le paramètre osd_pool_default_size . Ensuite, l'OSD principal prend l'ID objet, le nom de pool et la mappe de clusters et utilise l'algorithme CRUSH pour calculer les ID des OSD secondaires pour l'ensemble actif. L'OSD principal écrit l'objet dans les OSD secondaires. Lorsque l'OSD principal reçoit un accusé de réception des OSD secondaires et que l'OSD principal termine lui-même son opération d'écriture, il accuse réception d'une opération d'écriture réussie sur le client Ceph.

Figure 1. IO répliqué
E-S répliquées
Grâce à la possibilité d'effectuer la réplication de données pour le compte des clients Ceph, les démons Ceph OSD soulagent les clients Ceph de cette obligation, tout en garantissant une haute disponibilité des données et la sécurité des données.
Remarque: L'OSD principal et les OSD secondaires sont généralement configurés pour se trouver dans des domaines de défaillance distincts. CRUSH calcule les ID des OSD secondaires en prenant en compte les domaines d'échec.

Copies de données

Dans un pool de stockage répliqué, Ceph a besoin de plusieurs copies d'un objet pour fonctionner dans un état dégradé. Idéalement, un cluster de stockage Ceph permet à un client de lire et d'écrire des données même si l'un des OSD d'un ensemble actif échoue. Pour cette raison, Ceph effectue par défaut trois copies d'un objet avec un minimum de deux copies propres pour les opérations d'écriture. Ceph conserve les données même si deux OSD échouent. Cependant, il interrompt les opérations d'écriture.

Dans un pool codé en effacement, Ceph doit stocker des blocs d'un objet sur plusieurs OSD afin qu'il puisse fonctionner dans un état dégradé. Comme pour les pools répliqués, idéalement, un pool codé par effacement permet à un client Ceph de lire et d'écrire dans un état dégradé.
Important: Les valeurs de codage jerasure suivantes pour ket m sont prises en charge:
  • k=8 m=3

  • k=8 m=4

  • k=4 m=2