Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Documentation de SUSE Enterprise Storage 7 / Guide d'opérations et d'administration / Stockage de données dans une grappe / Gestion des données stockées
S'applique à SUSE Enterprise Storage 7

17 Gestion des données stockées

L'algorithme CRUSH détermine comment stocker et récupérer des données en calculant les emplacements de stockage de données. CRUSH donne aux clients Ceph les moyens de communiquer directement avec les OSD plutôt que via un serveur ou un courtier centralisé. Grâce à une méthode algorithmique de stockage et de récupération des données, Ceph évite que son évolutivité soit entravée par un point de défaillance unique, un goulot d'étranglement des performances ou une limite physique.

CRUSH requiert une assignation de votre grappe et l'utilise pour stocker et récupérer de façon pseudo-aléatoire des données sur les OSD avec une distribution uniforme des données sur l'ensemble de la grappe.

Les cartes CRUSH contiennent une liste d'OSD, une liste de compartiments (« buckets ») pour l'agrégation des périphériques à des emplacements physiques et une liste de règles indiquant à CRUSH comment répliquer les données dans les réserves d'une grappe Ceph. En reflétant l'organisation physique sous-jacente de l'installation, CRUSH peut modéliser (et ainsi corriger) les sources potentielles de défaillances de périphériques corrélés. Les sources courantes incluent la proximité physique, une source d'alimentation partagée et un réseau partagé. En codant ces informations dans l'assignation de grappe, les stratégies de placement CRUSH peuvent séparer les répliques d'objet entre différents domaines de défaillance, tout en conservant la distribution souhaitée. Par exemple, pour prévoir le traitement de défaillances simultanées, il peut être souhaitable de s'assurer que les répliques de données se trouvent sur des périphériques utilisant des étagères, des racks, des alimentations électriques, des contrôleurs et/ou des emplacements physiques différents.

Une fois que vous avez déployé une grappe Ceph, une carte CRUSH par défaut est générée, ce qui est parfait pour votre environnement de sandbox Ceph. Cependant, lorsque vous déployez une grappe de données à grande échelle, vous devez envisager sérieusement de développer une carte CRUSH personnalisée, car elle vous aidera à gérer votre grappe Ceph, à améliorer les performances et à garantir la sécurité des données.

Par exemple, si un OSD tombe en panne, une carte CRUSH peut vous aider à localiser le centre de données physique, la salle, la rangée et le rack de l'hôte avec l'OSD défaillant dans le cas où vous auriez besoin d'une intervention sur site ou de remplacer le matériel.

De même, CRUSH peut vous aider à identifier les défaillances plus rapidement. Par exemple, si tous les OSD d'un rack particulier tombent en panne simultanément, la défaillance peut provenir d'un commutateur réseau ou de l'alimentation du rack, plutôt que des OSD eux-mêmes.

Une carte CRUSH personnalisée vous aide également à identifier les emplacements physiques où Ceph stocke des copies redondantes de données lorsque le ou les groupes de placement (voir Section 17.4, « Groupes de placement ») associés à un hôte défaillant se trouvent dans un état altéré.

Une carte CRUSH comporte trois sections principales.

  • Périphériques OSD : comprend tous les périphériques de stockage d'objets correspondant à un daemon ceph-osd.

  • Compartiments : définit une agrégation hiérarchique des emplacements de stockage (par exemple, des rangées, des racks, des hôtes, etc.) et les pondérations qui leur sont assignées.

  • Ensembles de règles : définit la manière de sélectionner les compartiments.

17.1 Périphériques OSD

Pour assigner des groupes de placement aux OSD, une carte CRUSH nécessite une liste de périphériques OSD (nom du daemon OSD). La liste des périphériques apparaît en premier dans la carte CRUSH.

#devices
device NUM osd.OSD_NAME class CLASS_NAME

Par exemple :

#devices
device 0 osd.0 class hdd
device 1 osd.1 class ssd
device 2 osd.2 class nvme
device 3 osd.3class ssd

En règle générale, un daemon OSD est assigné à un seul disque.

17.1.1 Classes de périphériques

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.

OSD avec classes de périphériques mixtes
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.

17.1.1.2 Classes de périphériques

Une solution élégante proposée par Ceph consiste à ajouter une propriété appelée device class (classe de périphériques) à chaque OSD. Par défaut, les OSD définissent automatiquement leur classe de périphériques sur « hdd », « ssd » ou « nvme » en fonction des propriétés matérielles exposées par le kernel Linux. Ces classes de périphériques sont répertoriées dans une nouvelle colonne de la sortie de la commande ceph osd tree :

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

Si la détection automatique de la classe de périphériques échoue, par exemple parce que le pilote du périphérique n'expose pas correctement les informations sur ce dernier via /sys/block, vous pouvez ajuster les classes de périphériques à partir de la ligne de commande :

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'

17.1.1.3 Définition des règles de placement CRUSH

Les règles CRUSH peuvent limiter le placement à une classe de périphériques spécifique. Par exemple, vous pouvez créer une réserve répliquée « fast » qui distribue des données uniquement sur les disques SSD en exécutant la commande suivante :

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

Par exemple :

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

Créez une réserve nommée « fast_pool » et assignez-la à la règle « fast » :

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

Le processus de création des règles de code à effacement est légèrement différent. Tout d'abord, vous créez un profil de code à effacement qui inclut une propriété pour votre classe de périphériques souhaitée. Ensuite, utilisez ce profil lors de la création de la réserve codée à effacement :

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

Si vous devez modifier manuellement la carte CRUSH pour personnaliser votre règle, la syntaxe a été étendue de sorte à permettre de spécifier la classe de périphériques. Par exemple, la règle CRUSH générée par les commandes ci-dessus ressemble à ceci :

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
}

La différence importante ici est que la commande « take » inclut le suffixe supplémentaire de « classe CLASS_NAME ».

17.1.1.4 Commandes supplémentaires

Pour répertorier les classes de périphériques utilisées dans une carte CRUSH, exécutez :

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

Pour répertorier les règles CRUSH existantes, exécutez :

cephuser@adm > ceph osd crush rule ls
replicated_rule
fast

Pour afficher les détails de la règle CRUSH nommée « fast », exécutez :

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"
						}
		]
}

Pour répertorier les OSD appartenant à une classe « ssd », exécutez :

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

17.1.1.5 Migration d'une règle SSD héritée vers des classes de périphériques

Dans une version SUSE Enterprise Storage antérieure à la version 5, vous deviez modifier manuellement la carte CRUSH et maintenir une hiérarchie parallèle pour chaque type de périphérique spécialisé (comme SSD) afin d'écrire des règles qui s'appliquent à ces appareils. Depuis SUSE Enterprise Storage 5, la fonction de classe de périphériques permet d'effectuer cette opération en toute transparence.

Vous pouvez transformer une règle et une hiérarchie héritées en nouvelles règles basées sur la classe à l'aide de la commande crushtool. Plusieurs types de transformation sont possibles :

crushtool --reclassify-root ROOT_NAME DEVICE_CLASS

Cette commande prend tout ce qui se trouve dans la hiérarchie sous ROOT_NAME et ajuste toutes les règles qui font référence à cette racine via

take ROOT_NAME

vers

take ROOT_NAME class DEVICE_CLASS

Elle réattribue des numéros aux compartiments de sorte que les anciens ID sont utilisés pour l'arborescence fantôme (« shadow tree ») de la classe spécifiée. Par conséquent, aucun mouvement de données ne se produit.

Exemple 17.1 : crushtool --reclassify-root

Considérez la règle existante suivante :

rule replicated_ruleset {
   id 0
   type replicated
   min_size 1
   max_size 10
   step take default
   step chooseleaf firstn 0 type rack
   step emit
}

Si vous reclassez la racine « default » en tant que classe « hdd », la règle devient la suivante :

rule replicated_ruleset {
   id 0
   type replicated
   min_size 1
   max_size 10
   step take default class hdd
   step chooseleaf firstn 0 type rack
   step emit
}
crushtool --set-subtree-class BUCKET_NAME DEVICE_CLASS

Cette méthode marque chaque périphérique de la sous-arborescence associée à la racine BUCKET_NAME avec la classe de périphériques spécifiée.

--set-subtree-class est normalement utilisé avec l'option --reclassify-root pour garantir que tous les périphériques de cette racine sont étiquetés avec la bonne classe. Cependant, certains de ces périphériques peuvent volontairement avoir une classe différente et vous ne souhaitez donc pas changer leur étiquette. Dans de tels cas, excluez l'option --set-subtree-class. Gardez à l'esprit que ce type de réassignation n'est pas parfait, car la règle précédente est distribuée entre des périphériques de différentes classes, tandis que les règles ajustées seront uniquement assignées aux périphériques de la classe spécifiée.

crushtool --reclassify-bucket MATCH_PATTERN DEVICE_CLASS DEFAULT_PATTERN

Cette méthode permet de fusionner une hiérarchie spécifique à un type parallèle avec la hiérarchie normale. Par exemple, de nombreux utilisateurs possèdent des cartes CRUSH similaires à la suivante :

Exemple 17.2 : crushtool --reclassify-bucket
host node1 {
   id -2           # do not change unnecessarily
   # weight 109.152
   alg straw
   hash 0  # rjenkins1
   item osd.0 weight 9.096
   item osd.1 weight 9.096
   item osd.2 weight 9.096
   item osd.3 weight 9.096
   item osd.4 weight 9.096
   item osd.5 weight 9.096
   [...]
}

host node1-ssd {
   id -10          # do not change unnecessarily
   # weight 2.000
   alg straw
   hash 0  # rjenkins1
   item osd.80 weight 2.000
   [...]
}

root default {
   id -1           # do not change unnecessarily
   alg straw
   hash 0  # rjenkins1
   item node1 weight 110.967
   [...]
}

root ssd {
   id -18          # do not change unnecessarily
   # weight 16.000
   alg straw
   hash 0  # rjenkins1
   item node1-ssd weight 2.000
   [...]
}

Cette fonction reclasse chaque compartiment qui correspond à un modèle donné. Le modèle peut ressembler à %suffix ou prefix%. Dans l'exemple ci-dessus, vous utiliseriez le modèle %-ssd. Pour chaque compartiment correspondant, la partie restante du nom qui est représentée par le caractère joker « % » spécifie le compartiment de base. Tous les périphériques du compartiment correspondant sont étiquetés avec la classe de périphériques spécifiée, puis déplacés vers le compartiment de base. Si le compartiment de base n'existe pas (par exemple, si « node12-ssd » existe, mais pas « node12 »), il est créé et lié sous le compartiment parent par défaut spécifié. Les anciens ID de compartiment sont conservés pour les nouveaux compartiments fantômes afin d'empêcher le mouvement de données. Les règles avec des étapes take qui font référence aux anciens compartiments sont ajustées.

crushtool --reclassify-bucket BUCKET_NAME DEVICE_CLASS BASE_BUCKET

Vous pouvez utiliser l'option --reclassify-bucket sans caractère joker pour assigner un compartiment unique. Par exemple, dans l'exemple précédent, nous voulons que le compartiment « ssd » soit assigné au compartiment par défaut.

La commande finale pour convertir l'assignation composée des fragments ci-dessus serait la suivante :

cephuser@adm > ceph osd getcrushmap -o original
cephuser@adm > crushtool -i original --reclassify \
  --set-subtree-class default hdd \
  --reclassify-root default hdd \
  --reclassify-bucket %-ssd ssd default \
  --reclassify-bucket ssd ssd default \
  -o adjusted

Afin de vérifier que la conversion est correcte, il existe une option --compare qui teste un grand échantillon d'entrées dans la carte CRUSH et compare si le même résultat revient. Ces entrées sont contrôlées par les mêmes options que celles qui s'appliquent à --test. Pour l'exemple ci-dessus, la commande se présenterait comme suit :

cephuser@adm > crushtool -i original --compare adjusted
rule 0 had 0/10240 mismatched mappings (0)
rule 1 had 0/10240 mismatched mappings (0)
maps appear equivalent
Astuce
Astuce

S'il existait des différences, vous verriez le taux d'entrées réassignées dans les parenthèses.

Si vous êtes satisfait de la carte CRUSH ajustée, vous pouvez l'appliquer à la grappe :

cephuser@adm > ceph osd setcrushmap -i adjusted

17.1.1.6 Informations supplémentaires

Pour plus de détails sur les cartes CRUSH, reportez-vous à la Section 17.5, « Manipulation de la carte CRUSH ».

Pour plus de détails sur les réserves Ceph en général, reportez-vous au Chapitre 18, Gestion des réserves de stockage.

Pour plus de détails sur les réserves codées à effacement, reportez-vous au Chapitre 19, Réserves codées à effacement.

17.2 Compartiments

Les cartes CRUSH contiennent une liste d'OSD pouvant être organisée en une arborescence de « compartiments » afin d'agréger les périphériques dans des emplacements physiques. Les OSD individuels comprennent les feuilles de l'arborescence.

0

osd

Périphérique ou OSD spécifique (osd.1, osd.2, etc.).

1

host

Nom d'un hôte contenant un ou plusieurs OSD.

2

chassis

Identificateur du châssis du rack contenant l'hôte.

3

rack

Rack d'un ordinateur. La valeur par défaut est unknownrack.

4

row

Rangée dans une série de racks.

5

pdu

Abréviation de « Power Distribution Unit » (unité de distribution de l'alimentation).

6

pod

Abréviation de « Point of Delivery » (point de livraison) : dans ce contexte, groupe de PDU ou groupe de rangées de racks.

7

room

Salle contenant des rangées de racks.

8

datacenter

Centre de données physique comprenant une ou plusieurs salles.

9

region

Région géographique du monde (par exemple, NAM, LAM, EMEA, APAC, etc.)

10

root

Noeud racine de l'arborescence des compartiments OSD (normalement défini sur la valeur default).

Astuce
Astuce

Vous pouvez modifier les types existants et créer vos propres types de compartiment.

Les outils de déploiement de Ceph génèrent une carte CRUSH contenant un compartiment pour chaque hôte et une racine nommée « default », qui est utile pour la réserve rbd par défaut. Les types de compartiment restants permettent de stocker des informations sur l'emplacement physique des noeuds/compartiments, ce qui facilite grandement l'administration des grappes lorsque des OSD, des hôtes ou le matériel réseau sont défectueux et que l'administrateur doit accéder au matériel physique.

Chaque compartiment possède un type, un nom unique (chaîne), un identifiant unique exprimé en tant que nombre entier négatif, une pondération par rapport à la capacité totale de son ou ses éléments, l'algorithme de compartiment (straw2 par défaut) et le hachage (0 par défaut, reflet du hachage CRUSH rjenkins1). Un compartiment peut contenir un ou plusieurs éléments. Les éléments peuvent être constitués d'autres compartiments ou OSD. Les éléments peuvent posséder une pondération relative les uns par rapport aux autres.

[bucket-type] [bucket-name] {
  id [a unique negative numeric ID]
  weight [the relative capacity/capability of the item(s)]
  alg [the bucket type: uniform | list | tree | straw2 | straw ]
  hash [the hash type: 0 by default]
  item [item-name] weight [weight]
}

L'exemple suivant illustre la façon dont vous pouvez utiliser des compartiments pour agréger une réserve et des emplacements physiques, tels qu'un centre de données, une salle, un rack et une rangée.

host ceph-osd-server-1 {
        id -17
        alg straw2
        hash 0
        item osd.0 weight 0.546
        item osd.1 weight 0.546
}

row rack-1-row-1 {
        id -16
        alg straw2
        hash 0
        item ceph-osd-server-1 weight 2.00
}

rack rack-3 {
        id -15
        alg straw2
        hash 0
        item rack-3-row-1 weight 2.00
        item rack-3-row-2 weight 2.00
        item rack-3-row-3 weight 2.00
        item rack-3-row-4 weight 2.00
        item rack-3-row-5 weight 2.00
}

rack rack-2 {
        id -14
        alg straw2
        hash 0
        item rack-2-row-1 weight 2.00
        item rack-2-row-2 weight 2.00
        item rack-2-row-3 weight 2.00
        item rack-2-row-4 weight 2.00
        item rack-2-row-5 weight 2.00
}

rack rack-1 {
        id -13
        alg straw2
        hash 0
        item rack-1-row-1 weight 2.00
        item rack-1-row-2 weight 2.00
        item rack-1-row-3 weight 2.00
        item rack-1-row-4 weight 2.00
        item rack-1-row-5 weight 2.00
}

room server-room-1 {
        id -12
        alg straw2
        hash 0
        item rack-1 weight 10.00
        item rack-2 weight 10.00
        item rack-3 weight 10.00
}

datacenter dc-1 {
        id -11
        alg straw2
        hash 0
        item server-room-1 weight 30.00
        item server-room-2 weight 30.00
}

root data {
        id -10
        alg straw2
        hash 0
        item dc-1 weight 60.00
        item dc-2 weight 60.00
}

17.3 Ensembles de règles

Les cartes CRUSH prennent en charge la notion de « règles CRUSH », lesquelles déterminent le placement des données dans une réserve. Pour les grappes vastes, vous pouvez créer un grand nombre de réserves dans lesquelles chaque réserve peut avoir son propre ensemble de règles ou ses propres règles CRUSH. La carte CRUSH par défaut a une règle pour la racine par défaut. Si vous voulez plus de racines et plus de règles, vous devez les créer plus tard ou elles seront créées automatiquement lors de la création de réserves.

Note
Note

Dans la plupart des cas, vous n'avez pas besoin de modifier les règles par défaut. Lorsque vous créez une réserve, son ensemble de règles par défaut est 0.

Une règle est définie selon le format suivant :

rule rulename {

        ruleset ruleset
        type type
        min_size min-size
        max_size max-size
        step step

}
ruleset

Nombre entier. Classifie une règle en tant que membre d'un ensemble de règles. Option activée en définissant l'ensemble de règles dans une réserve. Elle est obligatoire. La valeur par défaut est 0.

type

Chaîne. Décrit une règle pour une réserve codée « replicated » (répliqué) ou « erasure » (effacement). Cette option est obligatoire. La valeur par défaut est replicated.

min_size

Nombre entier. Si un groupe de réserves produit moins de répliques que ce nombre, CRUSH ne sélectionne PAS cette règle. Cette option est obligatoire. La valeur par défaut est 2.

max_size

Nombre entier. Si un groupe de réserves produit plus de répliques que ce nombre, CRUSH ne sélectionne PAS cette règle. Cette option est obligatoire. La valeur par défaut est 10.

step take compartiment

Récupère un compartiment spécifié par un nom, puis commence à effectuer une itération en profondeur dans l'arborescence. Cette option est obligatoire. Pour en savoir plus sur l'itération dans l'arborescence, consultez la Section 17.3.1, « Itération de l'arborescence de noeuds ».

step ciblemodenum type type-compartiment

cible peut être choose ou chooseleaf. Lorsque la valeur est définie surchoose, un nombre de compartiments est sélectionné. chooseleaf sélectionne directement les OSD (noeuds feuilles) dans la sous-arborescence de chaque compartiment dans l'ensemble des compartiments.

mode peut être firstn ou indep. Reportez-vous à la Section 17.3.2, « firstn et indep ».

Sélectionne le nombre de compartiments du type donné. Où N correspond au nombre d'options disponible, si num > 0 && < N, choisissez autant de compartiments ; si num < 0, cela signifie N - num ; et si num == 0, choisissez N compartiments (tous disponibles). Suit step take ou step choose.

step emit

Affiche la valeur actuelle et vide la pile. Figure généralement à la fin d'une règle, mais permet également de former des arborescences différentes dans la même règle. Suit step choose.

17.3.1 Itération de l'arborescence de noeuds

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.

Exemple d'arborescence
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
}

17.3.2 firstn et indep

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.

Méthodes de remplacement de noeud
Figure 17.3 : Méthodes de remplacement de noeud

17.4 Groupes de placement

Ceph assigne les objets aux groupes de placement (PG). Les groupes de placement sont des partitions ou des fragments d'une réserve d'objets logique qui placent les objets en tant que groupe dans des OSD. Les groupes de placement réduisent la quantité de métadonnées par objet lorsque Ceph stocke les données dans les OSD. Un plus grand nombre de groupes de placement, par exemple, 100 par OSD, permet un meilleur équilibrage.

17.4.1 Utilisation de groupes de placement

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.

Groupes de placement d'une réserve
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 :

Groupes de placement et 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.

17.4.2 Détermination de la valeur de PG_NUM

Note
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 :

Moins de 5 OSD :

définissez PG_NUM sur 128.

Entre 5 et 10 OSD :

définissez PG_NUM sur 512.

Entre 10 et 50 OSD :

définissez PG_NUM sur 1024.

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.

17.4.2.1 Calcul du nombre de groupes de placement pour plus de 50 OSD

Si vous avez moins de 50 OSD, utilisez la présélection décrite à la Section 17.4.2, « Détermination de la valeur de PG_NUM ». Si vous avez plus de 50 OSD, nous recommandons environ 50 à 100 groupes de placement par OSD pour équilibrer l'utilisation des ressources, la durabilité des données et la distribution. Pour une seule réserve d'objets, vous pouvez utiliser la formule suivante afin d'obtenir une base de référence :

total PGs = (OSDs * 100) / POOL_SIZE

POOL_SIZE représente soit le nombre de répliques pour les réserves répliquées, soit la somme « k »+« m » pour les réserves codées à effacement, en fonction du retour de la commande ceph osd erasure-code-profil get. Vous devez arrondir le résultat à la puissance de 2 la plus proche. L'arrondissement est recommandé pour l'algorithme CRUSH afin d'équilibrer uniformément le nombre d'objets entre les groupes de placement.

Par exemple, pour une grappe avec 200 OSD et une taille de réserve de 3 répliques, vous estimez le nombre de groupes de placement comme suit :

          (200 * 100) / 3 = 6667

La puissance de 2 la plus proche est 8192.

Lorsque vous utilisez plusieurs réserves de données pour stocker des objets, vous devez veiller à équilibrer le nombre de groupes de placement par réserve avec le nombre de groupes de placement par OSD. Vous devez parvenir à un nombre total raisonnable de groupes de placement qui varie suffisamment peu par OSD, sans surcharger les ressources système ni rendre le processus d'homologation trop lent.

Par exemple, une grappe de 10 réserves, dont chacune comporte 512 groupes de placement sur 10 OSD, représente un total de 5 120 groupes de placement répartis sur 10 OSD, soit 512 groupes de placement par OSD. Une telle configuration n'utilise pas trop de ressources. Toutefois, si 1 000 réserves étaient créées avec 512 groupes de placement chacune, les OSD gèreraient environ 50 000 groupes de placement chacun, ce qui nécessiterait beaucoup plus de ressources et de temps pour l'homologation.

17.4.3 Définition du nombre de groupes de placement

Note
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

17.4.4 Détermination du nombre de groupes de placement

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

17.4.5 Détermination des statistiques relatives aux groupes de placement d'une grappe

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 ».

17.4.6 Détermination des statistiques relatives aux groupes de placement bloqués

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).

17.4.7 Recherche d'une assignation de groupe de placement

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]

17.4.8 Récupération des statistiques d'un groupe de placement

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

root # ceph pg PG_ID query

17.4.9 Nettoyage d'un groupe de placement

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.

17.4.10 Définition de priorités pour le renvoi et la récupération des groupes de placement

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é.

17.4.11 Rétablissement des objets perdus

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

17.4.12 Activation de la mise à l'échelle automatique des groupes de placement

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 :

off

Désactive la mise à l'échelle automatique pour cette réserve. L'administrateur doit choisir un numéro de groupe de placement approprié pour chaque réserve.

on

Active les ajustements automatisés du nombre de groupes de placement pour la réserve donnée.

avertissement

Génère des alertes d'état de santé lorsque le nombre de groupes de placement doit être ajusté.

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

17.5 Manipulation de la carte CRUSH

Cette section décrit des méthodes simples de manipulation de carte CRUSH, telles que la modification d'une carte CRUSH, la modification de paramètres de carte CRUSH et l'ajout/le déplacement/la suppression d'un OSD.

17.5.1 Modification d'une carte CRUSH

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

  1. Obtenez une carte CRUSH. Pour obtenir la carte CRUSH pour votre grappe, exécutez la commande suivante :

    cephuser@adm > ceph osd getcrushmap -o compiled-crushmap-filename

    Ceph associe (-o) une carte CRUSH compilée au nom de fichier que vous avez indiqué. Comme la carte CRUSH est compilée, vous devez la décompiler pour pouvoir la modifier.

  2. Décompilez une carte CRUSH. Pour décompiler une carte CRUSH, exécutez la commande suivante :

    cephuser@adm > crushtool -d compiled-crushmap-filename \
     -o decompiled-crushmap-filename

    Ceph décompile (-d) la carte CRUSH compilée et l'associe (-o) au nom de fichier que vous avez indiqué.

  3. Modifiez au moins l'un des paramètres des périphériques, des compartiments et des règles.

  4. Compilez une carte CRUSH. Pour compiler une carte CRUSH, exécutez la commande suivante :

    cephuser@adm > crushtool -c decompiled-crush-map-filename \
     -o compiled-crush-map-filename

    Ceph stocke alors une carte CRUSH compilée et l'associe au nom de fichier que vous avez indiqué.

  5. Définissez une carte CRUSH. Pour définir la carte CRUSH pour votre grappe, exécutez la commande suivante :

    cephuser@adm > ceph osd setcrushmap -i compiled-crushmap-filename

    Ceph considérera la carte CRUSH compilée du nom de fichier que vous avez spécifié comme la carte CRUSH de la grappe.

Astuce
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
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

17.5.2 Ajout ou déplacement d'un OSD

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 ...
id

Nombre entier. ID numérique de l'OSD. Cette option est obligatoire.

name

Chaîne. Nom complet de l'OSD. Cette option est obligatoire.

weight

Nombre de type double. Pondération CRUSH de l'OSD. Cette option est obligatoire.

root

Paire clé/valeur. Par défaut, la racine de la hiérarchie CRUSH correspond à la valeur par défaut de la réserve. Cette option est obligatoire.

bucket-type

Paires clé/valeur. Vous pouvez indiquer l'emplacement de l'OSD dans la hiérarchie CRUSH.

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

17.5.3 Différence entre ceph osd reweight et ceph osd crush reweight

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
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.

17.5.3.2 ceph osd crush reweight

Syntaxe :

cephuser@adm > ceph osd crush reweight OSD_NAME NEW_WEIGHT

ceph osd crush reweight définit la pondération CRUSH de l'OSD. Cette pondération est une valeur arbitraire (généralement la taille du disque en To) et contrôle la quantité de données que le système tente d'allouer à l'OSD.

17.5.4 Suppression d'un OSD

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

17.5.5 Ajout d'un compartiment

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

17.5.6 Déplacement d'un compartiment

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

17.5.7 Suppression d'un compartiment

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
Note : compartiment vide uniquement

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

17.6 Nettoyage des groupes de placement

En plus de réaliser plusieurs copies d'objets, Ceph assure l'intégrité des données en nettoyant les groupes de placement (pour en savoir plus sur les groupes de placement, voir Section 1.3.2, « Groupes de placement »). Le nettoyage que réalise Ceph est analogue à l'exécution de fsck sur la couche de stockage d'objets. Pour chaque groupe de placement, Ceph génère un catalogue de tous les objets et compare chaque objet principal et ses répliques pour s'assurer qu'aucun objet n'est manquant ou discordant. Le nettoyage léger réalisé quotidiennement vérifie la taille et les attributs de l'objet, tandis que le nettoyage approfondi hebdomadaire lit les données et utilise les sommes de contrôle pour garantir l'intégrité de celles-ci.

Le nettoyage est essentiel au maintien de l'intégrité des données, mais il peut réduire les performances. Vous pouvez ajuster les paramètres suivants pour augmenter ou réduire la fréquence des opérations de nettoyage :

osd max scrubs

Nombre maximum d'opérations de nettoyage simultanées pour un Ceph OSD. La valeur par défaut est 1.

osd scrub begin hour, osd scrub end hour

Heures du jour (0 à 24) qui définissent une fenêtre temporelle pendant laquelle le nettoyage peut avoir lieu. Par défaut, elle commence à 0 et se termine à 24.

Important
Important

Si l'intervalle de nettoyage du groupe de placement dépasse la valeur du paramètre osd scrub max interval, le nettoyage se produit quelle que soit la fenêtre temporelle que vous avez définie.

osd scrub during recovery

Autorise les nettoyages durant la récupération. Si vous définissez cette option sur « false », la planification de nouveaux nettoyages ne sera pas possible tant qu'une récupération est active. L'exécution des nettoyages déjà en cours se poursuivra. Cette option est utile pour réduire la charge sur les grappes occupées. La valeur par défaut est « true ».

osd scrub thread timeout

Durée maximale en secondes avant le timeout d'un thread de nettoyage. La valeur par défaut est 60.

osd scrub finalize thread timeout

Durée maximale en secondes avant le timeout d'un thread de finalisation de nettoyage. La valeur par défaut est 60*10.

osd scrub load threshold

Charge maximale normalisée. Ceph n'effectue pas d'opération de nettoyage lorsque la charge du système (définie par le rapport de getloadavg()/nombre d'online cpus) est supérieure à ce nombre. La valeur par défaut est 0,5.

osd scrub min interval

Intervalle minimal en secondes pour le nettoyage de Ceph OSD lorsque la charge de la grappe Ceph est faible. La valeur par défaut est 60*60*24 (une fois par jour).

osd scrub max interval

Intervalle maximal en secondes pour le nettoyage de Ceph OSD indépendamment de la charge de la grappe. La valeur par défaut est 7*60*60*24 (une fois par semaine).

osd scrub chunk min

Nombre minimal de tranches de magasin d'objets à nettoyer en une seule opération. L'écriture des blocs Ceph porte sur une seule tranche pendant un nettoyage. La valeur par défaut est 5.

osd scrub chunk max

Nombre maximal de tranches de magasin d'objets à nettoyer en une seule opération. La valeur par défaut est 25.

osd scrub sleep

Temps de veille avant le nettoyage du prochain groupe de tranches. L'augmentation de cette valeur ralentit toute l'opération de nettoyage alors que les opérations client sont moins impactées. La valeur par défaut est 0.

osd deep scrub interval

Intervalle de nettoyage approfondi (lecture complète de toutes les données). L'option osd scrub load threshold n'a pas d'effet sur ce paramètre. La valeur par défaut est 60*60*24*7 (une fois par semaine).

osd scrub interval randomize ratio

Ajoute un délai aléatoire à la valeur osd scrub interval randomize ratio lors de la planification du prochain travail de nettoyage d'un groupe de placement. Le délai est une valeur aléatoire inférieure au résultat du produit osd scrub min interval * osd scrub interval randomized ratio. Par conséquent, le paramètre par défaut répartit de manière aléatoire les nettoyages dans la fenêtre temporelle autorisée de [1, 1,5] * osd scrub min interval. La valeur par défaut est 0,5.

osd deep scrub stride

Taille des données à lire lors d'un nettoyage en profondeur. La valeur par défaut est 524288 (512 Ko).