17 Gestion des données stockées #

La flexibilité de la carte CRUSH pour le contrôle du placement de données est l'une des forces de Ceph. C'est aussi l'une des parties les plus difficiles à gérer de la grappe. Les classes de périphériques automatisent les modifications les plus courantes apportées aux cartes CRUSH que l'administrateur devait effectuer manuellement auparavant.

17.1.1.1 Problème de gestion de CRUSH #

 

Les grappes Ceph sont souvent créées avec plusieurs types de périphériques de stockage : HDD, SSD, NVMe ou même des classes mixtes de ce qui précède. Nous appelons ces différents types de périphériques de stockage classes de périphériques pour éviter toute confusion entre la propriété type des compartiments CRUSH (par exemple, hôte, rack ou ligne ; voir Section 17.2, « Compartiments » pour plus de détails). Les Ceph OSD soutenus par des disques SSD sont beaucoup plus rapides que ceux s'appuyant sur des disques rotatifs, ce qui les rend plus appropriés pour certains workloads. Ceph facilite la création de réserves RADOS pour différents ensembles de données ou workloads, et l'assignation de règles CRUSH distinctes pour contrôler le placement de données pour ces réserves.

Figure 17.1 : OSD avec classes de périphériques mixtes #

 

Toutefois, la configuration de règles CRUSH pour placer les données uniquement sur une certaine classe de périphériques est fastidieuse. Les règles fonctionnent en termes de hiérarchie CRUSH, mais si les périphériques sont mélangés sur des hôtes ou racks identiques (comme dans l'exemple de hiérarchie ci-dessus), ils seront (par défaut) mélangés et apparaîtront dans les mêmes sous-arborescences de la hiérarchie. Les séparer manuellement dans des arborescences distinctes impliquait la création de plusieurs versions de chaque noeud intermédiaire pour chaque classe de périphériques dans les versions précédentes de SUSE Enterprise Storage.

cephuser@adm > ceph osd tree
 ID CLASS WEIGHT   TYPE NAME      STATUS REWEIGHT PRI-AFF
 -1       83.17899 root default
 -4       23.86200     host cpach
 2   hdd  1.81898         osd.2      up  1.00000 1.00000
 3   hdd  1.81898         osd.3      up  1.00000 1.00000
 4   hdd  1.81898         osd.4      up  1.00000 1.00000
 5   hdd  1.81898         osd.5      up  1.00000 1.00000
 6   hdd  1.81898         osd.6      up  1.00000 1.00000
 7   hdd  1.81898         osd.7      up  1.00000 1.00000
 8   hdd  1.81898         osd.8      up  1.00000 1.00000
 15  hdd  1.81898         osd.15     up  1.00000 1.00000
 10  nvme 0.93100         osd.10     up  1.00000 1.00000
 0   ssd  0.93100         osd.0      up  1.00000 1.00000
 9   ssd  0.93100         osd.9      up  1.00000 1.00000

cephuser@adm > ceph osd crush rm-device-class osd.2 osd.3
done removing class of osd(s): 2,3
cephuser@adm > ceph osd crush set-device-class ssd osd.2 osd.3
set osd(s) 2,3 to class 'ssd'

cephuser@adm > ceph osd crush rule create-replicated RULE_NAME ROOT FAILURE_DOMAIN_TYPE DEVICE_CLASS

cephuser@adm > ceph osd crush rule create-replicated fast default host ssd

cephuser@adm > ceph osd pool create fast_pool 128 128 replicated fast

cephuser@adm > ceph osd erasure-code-profile set myprofile \
 k=4 m=2 crush-device-class=ssd crush-failure-domain=host
cephuser@adm > ceph osd pool create mypool 64 erasure myprofile

rule ecpool {
  id 2
  type erasure
  min_size 3
  max_size 6
  step set_chooseleaf_tries 5
  step set_choose_tries 100
  step take default class ssd
  step chooseleaf indep 0 type host
  step emit
}

cephuser@adm > ceph osd crush class ls
[
  "hdd",
  "ssd"
]

cephuser@adm > ceph osd crush rule ls
replicated_rule
fast

cephuser@adm > ceph osd crush rule dump fast
{
		"rule_id": 1,
		"rule_name": "fast",
		"ruleset": 1,
		"type": 1,
		"min_size": 1,
		"max_size": 10,
		"steps": [
						{
										"op": "take",
										"item": -21,
										"item_name": "default~ssd"
						},
						{
										"op": "chooseleaf_firstn",
										"num": 0,
										"type": "host"
						},
						{
										"op": "emit"
						}
		]
}

cephuser@adm > ceph osd crush class ls-osd ssd
0
1

La structure des compartiments peut être considérée comme une arborescence de noeuds. Les compartiments sont des noeuds et les OSD sont les feuilles de cette arborescence.

Les règles de la carte CRUSH définissent la façon dont les OSD sont sélectionnés dans cette arborescence. Une règle commence par un noeud, puis réalise une itération dans l'arborescence pour renvoyer un ensemble d'OSD. Il n'est pas possible de définir quelle branche doit être sélectionnée. Au lieu de cela, l'algorithme CRUSH garantit que l'ensemble des OSD remplit les conditions de réplication et répartit équitablement les données.

Avec step take compartiment, l'itération dans l'arborescence des noeuds commence à partir du compartiment donné (et non pas du type de compartiment). Pour que les OSD de toutes les branches de l'arborescence puissent être renvoyés, le compartiment doit être le compartiment racine. Dans le cas contraire, l'itération se poursuit simplement dans une sous-arborescence.

Après step take, une ou plusieurs entrées step choose figurent dans la définition de la règle. Chaque step choose choisit un nombre défini de noeuds (ou de branches) dans le noeud supérieur précédemment sélectionné.

À la fin de l'itération, les OSD sélectionnés sont renvoyés avec step emit.

step chooseleaf est une fonction pratique qui sélectionne les OSD directement dans les branches du compartiment donné.

La Figure 17.2, « Exemple d'arborescence » illustre la façon dont step permet d'effectuer un traitement itératif dans une arborescence. Les flèches et les chiffres orange correspondent à example1a et example1b, tandis que la couleur bleue est associée à example2 dans les définitions de règles suivantes.

Figure 17.2 : Exemple d'arborescence #

 

# orange arrows
rule example1a {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # orange (1)
        step take rack1
        # orange (2)
        step choose firstn 0 host
        # orange (3)
        step choose firstn 1 osd
        step emit
}

rule example1b {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # orange (1)
        step take rack1
        # orange (2) + (3)
        step chooseleaf firstn 0 host
        step emit
}

# blue arrows
rule example2 {
        ruleset 0
        type replicated
        min_size 2
        max_size 10
        # blue (1)
        step take room1
        # blue (2)
        step chooseleaf firstn 0 rack
        step emit
}

Une règle CRUSH définit les remplacements des noeuds ou des OSD défaillants (voir Section 17.3, « Ensembles de règles »). Le mot clé step nécessite le paramètre firstn ou le paramètre indep. La Figure 17.3, « Méthodes de remplacement de noeud » fournit un exemple.

firstn ajoute des noeuds de remplacement à la fin de la liste des noeuds actifs. Dans le cas d'un noeud défaillant, les noeuds sains suivants sont décalés vers la gauche afin de combler l'espace laissé vacant par le noeud défaillant. Il s'agit de la méthode par défaut souhaitée pour les réserves répliquées, car un noeud secondaire possède déjà toutes les données et peut donc prendre immédiatement en charge les tâches du noeud principal.

indep sélectionne des noeuds de remplacement fixes pour chaque noeud actif. Le remplacement d'un noeud défaillant ne modifie pas l'ordre des noeuds restants. Cette approche est souhaitée pour les réserves codées à effacement. Dans les réserves codées à effacement, les données stockées sur un noeud dépendent de la position de celui-ci dans la sélection des noeuds. En cas de modification de l'ordre des noeuds, toutes les données des noeuds affectés doivent être déplacées.

Figure 17.3 : Méthodes de remplacement de noeud #

 

Un groupe de placement (PG) regroupe des objets au sein d'une réserve. La principale raison est que le fait que le suivi du placement des objets et des métadonnées sur une base « par objet » est coûteux en termes de calcul. Par exemple, un système avec des millions d'objets ne peut pas suivre directement le placement de chacun de ses objets.

Figure 17.4 : Groupes de placement d'une réserve #

 

Le client Ceph calcule à quel groupe de placement un objet appartient. Pour ce faire, il hache l'ID d'objet et applique une opération basée sur le nombre de groupes de placement dans la réserve définie et l'ID de cette dernière.

Le contenu de l'objet au sein d'un groupe de placement est stocké dans un ensemble d'OSD. Par exemple, dans une réserve répliquée de taille deux, chaque groupe de placement stocke des objets sur deux OSD :

Figure 17.5 : Groupes de placement et OSD #

 

Si l'OSD 2 échoue, un autre OSD est assigné au groupe de placement 1 et est rempli avec des copies de tous les objets de l'OSD 1. Si la taille de la réserve est modifiée de deux à trois, un OSD supplémentaire est assigné au groupe de placement et reçoit des copies de tous les objets du groupe de placement.

Les groupes de placement ne sont pas propriétaires de l'OSD, ils le partagent avec d'autres groupes de placement de la même réserve, voire avec d'autres réserves. Si l'OSD 2 échoue, le groupe de placement 2 devra également restaurer des copies d'objets à l'aide de l'OSD 3.

Lorsque le nombre de groupes de placement augmente, les nouveaux groupes de placement se voient assigner des OSD. Le résultat de la fonction CRUSH change également et certains objets des anciens groupes de placement sont copiés dans les nouveaux groupes de placement et retirés des anciens.

Note

Depuis Ceph Nautilus (v14.x), vous pouvez utiliser le module pg_autoscaler de Ceph Manager pour mettre à l'échelle automatiquement les groupes de placement si nécessaire. Si vous souhaitez activer cette fonction, reportez-vous au Section 6.1.1.1, « Default PG and PGP counts ».

Lorsque vous créez une nouvelle réserve, vous pouvez toujours choisir la valeur de PG_NUM manuellement :

root # ceph osd pool create POOL_NAME PG_NUM

PG_NUM ne peut pas être calculé automatiquement. Voici quelques valeurs couramment utilisées, en fonction du nombre d'OSD dans la grappe :

Plus le nombre d'OSD est élevé, plus il est important de bien choisir la valeur de PG_NUM. PG_NUM influence fortement le comportement de la grappe ainsi que la durabilité des données en cas de défaillance d'OSD.

total PGs = (OSDs * 100) / POOL_SIZE

          (200 * 100) / 3 = 6667

Note

Depuis Ceph Nautilus (v14.x), vous pouvez utiliser le module pg_autoscaler de Ceph Manager pour mettre à l'échelle automatiquement les groupes de placement si nécessaire. Si vous souhaitez activer cette fonction, reportez-vous au Section 6.1.1.1, « Default PG and PGP counts ».

Si vous devez encore spécifier manuellement le nombre de groupes de placement dans une réserve, vous devez le faire au moment de la création de la réserve (reportez-vous à la Section 18.1, « Création d'une réserve »). Une fois que vous avez établi des groupes de placement pour une réserve, vous pouvez augmenter leur nombre à l'aide de la commande suivante :

root # ceph osd pool set POOL_NAME pg_num PG_NUM

Après avoir augmenté le nombre de groupes de placement, vous devez également accroître le nombre de groupes de placement pour le placement (PGP_NUM) avant que votre grappe ne se rééquilibre. PGP_NUM correspond au nombre de groupes de placement qui seront pris en compte pour le placement par l'algorithme CRUSH. L'augmentation de PG_NUM divise les groupes de placement, mais les données ne sont migrées vers les groupes de placement plus récents qu'une fois PG_NUM augmenté. PGP_NUM doit être égal à PG_NUM. Pour augmenter le nombre de groupes de placement pour le placement, exécutez la commande suivante :

root # ceph osd pool set POOL_NAME pgp_num PGP_NUM

Pour connaître le nombre de groupes de placement dans une réserve, exécutez la commande get suivante :

root # ceph osd pool get POOL_NAME pg_num

Pour connaître les statistiques relatives aux groupes de placement de votre grappe, exécutez la commande suivante :

root # ceph pg dump [--format FORMAT]

Les formats valides sont « plain » (brut, valeur par défaut) et « json ».

Pour déterminer les statistiques relatives à tous les groupes de placement bloqués dans un état donné, exécutez la commande suivante :

root # ceph pg dump_stuck STATE \
 [--format FORMAT] [--threshold THRESHOLD]

STATE correspond à l'une des valeurs suivantes : « inactive » (inactif - les groupes de placement ne peuvent pas traiter les lectures ou les écritures, car ils attendent qu'un OSD disposant des données les plus à jour soit opérationnel), « unclean » (impropre - les groupes de placement contiennent des objets qui ne sont pas répliqués le nombre de fois souhaité), « stale » (obsolète - les groupes de placement sont dans un état inconnu ; les OSD qui les hébergent n'ont pas rendu de compte à la grappe depuis un certain temps spécifié par l'option mon_osd_report_timeout), « undersized » (de taille insuffisante) ou « degraded » (altéré).

Les formats valides sont « plain » (brut, valeur par défaut) et « json ».

Le seuil définit le nombre minimum de secondes pendant lesquelles le groupe de placement doit être bloqué avant qu'il soit inclus dans les statistiques renvoyées (300 secondes par défaut).

Pour rechercher l'assignation d'un groupe de placement particulier, exécutez la commande suivante :

root # ceph pg map PG_ID

Ceph renvoie alors l'assignation du groupe de placement, le groupe de placement et le statut OSD :

root # ceph pg map 1.6c
osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

Pour récupérer les statistiques d'un groupe de placement particulier, exécutez la commande suivante :

root # ceph pg PG_ID query

Pour nettoyer (Section 17.6, « Nettoyage des groupes de placement ») un groupe de placement, exécutez la commande suivante :

root # ceph pg scrub PG_ID

Ceph vérifie les noeuds primaires et des répliques, génère un catalogue de tous les objets du groupe de placement et les compare pour s'assurer qu'aucun objet n'est manquant ou discordant et que son contenu est cohérent. Si toutes les répliques correspondent, un balayage sémantique final garantit que toutes les métadonnées d'objets associées à l'instantané sont cohérentes. Les erreurs sont signalées via les journaux.

Vous pouvez vous retrouver dans une situation où plusieurs groupes de placement nécessitent une récupération et/ou un renvoi, alors que certains groupes hébergent des données plus importantes que celles d'autres groupes. Par exemple, vous pouvez avoir des groupes de placement qui contiennent des données pour des images utilisées par les machines en cours d'exécution, tandis que d'autres groupes de placement peuvent être utilisés par des machines inactives ou héberger des données moins essentielles. Dans ce cas, vous pouvez donner la priorité à la récupération des groupes plus critiques afin que les performances et la disponibilité des données stockées sur ces groupes soient restaurées plus rapidement. Pour marquer des groupes de placement particuliers comme prioritaires lors du renvoi ou de la récupération, exécutez la commande suivante :

root # ceph pg force-recovery PG_ID1 [PG_ID2 ... ]
root # ceph pg force-backfill PG_ID1 [PG_ID2 ... ]

De cette façon, Ceph effectuera la récupération ou le renvoi sur les groupes de placement spécifiés d'abord, avant de poursuivre avec d'autres groupes de placement. Cela n'interrompt pas les renvois ou les récupérations en cours, mais permet que des groupes de placement spécifiés soient traités dès que possible. Si vous changez d'avis ou si vous avez mal défini les groupes prioritaires, annulez la définition des priorités :

root # ceph pg cancel-force-recovery PG_ID1 [PG_ID2 ... ]
root # ceph pg cancel-force-backfill PG_ID1 [PG_ID2 ... ]

Les commandes cancel-* suppriment le drapeau « force » des groupes de placement afin qu'ils soient traités selon l'ordre par défaut. Dans ce cas également, cela n'affecte pas les groupes de placement en cours de traitement, seulement ceux qui sont encore en file d'attente. Le drapeau « force » est automatiquement effacé une fois la récupération ou le renvoi du groupe terminé.

Si la grappe a perdu un ou plusieurs objets et que vous avez décidé d'abandonner la recherche des données perdues, vous devez marquer les objets introuvables comme « perdu ».

Si les objets sont toujours perdus après avoir interrogé tous les emplacements possibles, vous devrez peut-être renoncer à ces objets. Cela est possible moyennant des combinaisons inhabituelles d'échecs qui permettent à la grappe d'apprendre à partir des opérations d'écriture qui ont été effectuées avant que les écritures elles-mêmes soient récupérées.

Actuellement, la seule option prise en charge est « revert » (rétablir), qui permet soit de revenir à une version précédente de l'objet, soit de l'oublier entièrement dans le cas d'un nouvel objet. Pour marquer les objets « unfound » (introuvable) comme « perdu », exécutez la commande suivante :

  cephuser@adm > ceph pg PG_ID mark_unfound_lost revert|delete

Les groupes de placement sont un détail d'implémentation interne de la façon dont Ceph distribue les données. En activant la mise à l'échelle automatique des groupes de placement, vous pouvez autoriser la grappe à créer ou à ajuster automatiquement des groupes de placement en fonction de l'utilisation de la grappe.

Chaque réserve du système possède une propriété pg_autoscale_mode qui peut être définie sur off, on ou warn :

La mise à l'échelle automatique est configurée pour chaque réserve et peut s'exécuter dans trois modes :

Pour définir le mode de mise à l'échelle automatique pour les réserves existantes :

cephuser@adm > ceph osd pool set POOL_NAME pg_autoscale_mode mode

Vous pouvez également configurer le paramètre pg_autoscale_mode par défaut appliqué à toutes les réserves créées par la suite comme suit :

cephuser@adm > ceph config set global osd_pool_default_pg_autoscale_mode MODE

Vous pouvez afficher chaque réserve, son utilisation relative et toute modification suggérée du nombre de groupes de placement à l'aide de cette commande :

cephuser@adm > ceph osd pool autoscale-status

Pour modifier une carte CRUSH existante, procédez comme suit :

Astuce : utilisation du système de contrôle de version

Utilisez un système de contrôle de version, comme git ou svn, pour les fichiers de carte CRUSH exportés et modifiés. Cela permet un éventuel retour à l'état initial.

Astuce : test de la nouvelle carte CRUSH

Testez la nouvelle carte CRUSH ajustée à l'aide de la commande crushtool ‑‑test et comparez avec l'état avant l'application de la nouvelle carte CRUSH. Les paramètres de commande suivants pourraient vous être utiles : --show-statistics, --show-mappings, --show-bad-mappings, --show-utilization, --show-utilization-all, --show-choose-tries

Pour ajouter ou déplacer un OSD dans la carte CRUSH d'une grappe en cours d'exécution, exécutez la commande suivante :

cephuser@adm > ceph osd crush set id_or_name weight root=pool-name
bucket-type=bucket-name ...

L'exemple suivant ajoute osd.0 à la hiérarchie ou déplace l'OSD à partir d'un emplacement précédent.

cephuser@adm > ceph osd crush set osd.0 1.0 root=data datacenter=dc1 room=room1 \
row=foo rack=bar host=foo-bar-1

Il existe deux commandes similaires qui modifient la pondération (« weight ») d'un Ceph OSD. Le contexte de leur utilisation est différent et peut causer de la confusion.

17.5.3.1 ceph osd reweight #

 

Syntaxe :

cephuser@adm > ceph osd reweight OSD_NAME NEW_WEIGHT

ceph osd reweight définit une pondération de remplacement pour le Ceph OSD. Cette valeur est comprise entre 0 et 1, et oblige CRUSH à repositionner les données qui, autrement, seraient sur cette unité. Elle ne modifie pas les pondérations assignées aux compartiments au-dessus de l'OSD ; c'est une mesure corrective pour le cas où la distribution CRUSH normale ne fonctionne pas correctement. Par exemple, si l'un de vos OSD est à 90 % et les autres à 40 %, vous pourriez réduire cette pondération pour essayer de compenser.

Note : la pondération OSD est temporaire

Notez ceph osd reweight n'est pas un paramètre persistant. Lorsqu'un OSD est marqué comme sorti, sa pondération est définie sur 0 et lorsqu'il est à nouveau marqué comme rentré, sa pondération passe à 1.

cephuser@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT

Pour supprimer un OSD de la carte CRUSH d'une grappe en cours d'exécution, exécutez la commande suivante :

cephuser@adm > ceph osd crush remove OSD_NAME

Pour ajouter un compartiment à la carte CRUSH d'une grappe en cours d'exécution, exécutez la commande ceph osd crush add-bucket :

cephuser@adm > ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE

Pour déplacer un compartiment vers un autre emplacement ou une autre position dans la hiérarchie de la carte CRUSH, exécutez la commande suivante :

cephuser@adm > ceph osd crush move BUCKET_NAME BUCKET_TYPE=BUCKET_NAME [...]

Par exemple :

cephuser@adm > ceph osd crush move bucket1 datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

Pour supprimer un compartiment de la hiérarchie de la carte CRUSH, exécutez la commande suivante :

cephuser@adm > ceph osd crush remove BUCKET_NAME

Note : compartiment vide uniquement

Un compartiment doit être vide pour pouvoir le retirer de la hiérarchie CRUSH.