S'applique à SUSE Enterprise Storage 7

12 Détermination de l'état d'une grappe #

Lorsque vous disposez d'une grappe en cours d'exécution, vous pouvez utiliser l'outil ceph pour la surveiller. Pour déterminer l'état de la grappe, il faut généralement vérifier le statut des OSD Ceph, des moniteurs Ceph, des groupes de placement et des serveurs de métadonnées.

Astuce : mode interactif

Pour exécuter l'outil ceph en mode interactif, tapez ceph sans argument sur la ligne de commande. Le mode interactif est plus pratique si vous voulez entrer plusieurs commandes ceph consécutives. Par exemple :

cephuser@adm > ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon stat

12.1 Vérification de l'état d'une grappe #

La commande ceph status ou ceph -s permet de connaître l'état immédiat de la grappe :

cephuser@adm > ceph -s
cluster:
    id:     b4b30c6e-9681-11ea-ac39-525400d7702d
    health: HEALTH_OK

  services:
    mon: 5 daemons, quorum ses-min1,ses-master,ses-min2,ses-min4,ses-min3 (age 2m)
    mgr: ses-min1.gpijpm(active, since 3d), standbys: ses-min2.oopvyh
    mds: my_cephfs:1 {0=my_cephfs.ses-min1.oterul=up:active}
    osd: 3 osds: 3 up (since 3d), 3 in (since 11d)
    rgw: 2 daemons active (myrealm.myzone.ses-min1.kwwazo, myrealm.myzone.ses-min2.jngabw)

  task status:
    scrub status:
        mds.my_cephfs.ses-min1.oterul: idle

  data:
    pools:   7 pools, 169 pgs
    objects: 250 objects, 10 KiB
    usage:   3.1 GiB used, 27 GiB / 30 GiB avail
    pgs:     169 active+clean

La sortie fournit les informations suivantes :

ID de grappe
État d'intégrité de la grappe
Époque d'assignation du moniteur et état du quorum du moniteur
Époque d'assignation des OSD et état des OSD
Statut des instances Ceph Manager
Statut des instances Object Gateway
Version d'assignation des groupes de placement
Nombre de groupes de placement et de réserves
Quantité théorique de données stockées et nombre d'objets stockés
Quantité totale de données stockées

Astuce : méthode utilisée par Ceph pour calculer l'utilisation des données

La valeur de used reflète la quantité réelle de stockage brut utilisée. La valeur de xxx Go/xxx Go désigne la quantité disponible de la capacité de stockage globale de la grappe (la quantité disponible correspond à la valeur inférieure). Le nombre théorique reflète la taille des données stockées avant qu'elles soient répliquées ou clonées ou qu'elles fassent l'objet d'un instantané. Par conséquent, la quantité de données réellement stockée dépasse généralement la quantité théorique stockée, car Ceph crée des répliques des données et peut également utiliser la capacité de stockage pour le clonage et la création d'instantanés.

Les autres commandes affichant des informations d'état immédiat sont les suivantes :

ceph pg stat
ceph osd pool stats
ceph df
ceph df detail

Pour obtenir les informations mises à jour en temps réel, utilisez l'une de ces commandes (y compris ceph -s) comme argument de la commande watch :

root # watch -n 10 'ceph -s'

Appuyez sur Ctrl–C pour refermer la sortie de la commande.

12.2 Vérification de l'état de santé de la grappe #

Après avoir démarré votre grappe et avant de commencer à lire et/ou à écrire des données, vérifiez l'état d'intégrité de votre grappe :

cephuser@adm > ceph health
HEALTH_WARN 10 pgs degraded; 100 pgs stuck unclean; 1 mons down, quorum 0,2 \
node-1,node-2,node-3

Astuce

Si vous avez choisi des emplacements autres que ceux par défaut pour votre configuration ou votre trousseau de clés, vous pouvez les indiquer ici :

cephuser@adm > ceph -c /path/to/conf -k /path/to/keyring health

La grappe Ceph renvoie l'un des codes d'intégrité suivants :

OSD_DOWN

Un ou plusieurs OSD sont marqués comme étant arrêtés. Le daemon OSD peut avoir été arrêté ou les OSD homologues peuvent ne pas être en mesure d'accéder à l'OSD via le réseau. Un daemon arrêté ou bloqué, un hôte en panne ou une panne réseau font partie des causes les plus courantes de ce problème.

Vérifiez que l'hôte est intègre, que le daemon a été démarré et que le réseau fonctionne. Si le daemon est tombé en panne, le fichier journal du daemon (/var/log/ceph/ceph-osd.*) peut contenir des informations de débogage.

OSD_type crush_DOWN, par exemple, OSD_HOST_DOWN

Tous les OSD d'une sous-arborescence CRUSH particulière sont marqués comme étant arrêtés, par exemple tous les OSD d'un hôte.

OSD_ORPHAN

Un OSD est référencé dans la hiérarchie des cartes CRUSH, mais n'existe pas. L'OSD peut être retiré de la hiérarchie CRUSH avec :

cephuser@adm > ceph osd crush rm osd.ID

OSD_OUT_OF_ORDER_FULL

Les seuils d'utilisation pour backfillfull (par défaut : 0,90), nearfull (par défaut : 0,85), full (par défaut : 0,95) et/ou failsafe_full ne sont pas croissants. backfillfull < nearfull, nearfull < full et full < failsafe_full sont agencés dans cet ordre.

Pour lire les valeurs actuelles, exécutez la commande suivante :

cephuser@adm > ceph health detail
HEALTH_ERR 1 full osd(s); 1 backfillfull osd(s); 1 nearfull osd(s)
osd.3 is full at 97%
osd.4 is backfill full at 91%
osd.2 is near full at 87%

Les seuils peuvent être ajustés avec les commandes suivantes :

cephuser@adm > ceph osd set-backfillfull-ratio ratio
cephuser@adm > ceph osd set-nearfull-ratio ratio
cephuser@adm > ceph osd set-full-ratio ratio

OSD_FULL

Un ou plusieurs OSD ont dépassé le seuil full et empêchent la grappe de gérer les écritures. L'utilisation par réserve peut être vérifiée comme suit :

cephuser@adm > ceph df

Le ratio full actuellement défini peut être vu avec :

cephuser@adm > ceph osd dump | grep full_ratio

Une solution à court terme de restauration de la disponibilité en écriture consiste à augmenter légèrement le seuil full :

cephuser@adm > ceph osd set-full-ratio ratio

Ajoutez un nouveau stockage à la grappe en déployant plus d'OSD ou supprimez les données existantes afin de libérer de l'espace.

OSD_BACKFILLFULL

Un ou plusieurs OSD ont dépassé le seuil backfillfull, ce qui empêche le rééquilibrage des données sur ce périphérique. Cet avertissement anticipé indique que le rééquilibrage peut ne pas aboutir et que la grappe approche de sa pleine capacité. L'utilisation par réserve peut être vérifiée comme suit :

cephuser@adm > ceph df

OSD_NEARFULL

Un ou plusieurs OSD ont dépassé le seuil nearfull. Cet avertissement anticipé indique que la grappe approche de sa pleine capacité. L'utilisation par réserve peut être vérifiée comme suit :

cephuser@adm > ceph df

OSDMAP_FLAGS

Un ou plusieurs indicateurs de grappe présentant un intérêt ont été définis. À l'exception de full, ces indicateurs peuvent être définis ou effacés comme suit :

cephuser@adm > ceph osd set flag
cephuser@adm > ceph osd unset flag

Ces indicateurs comprennent :

full: La grappe est marquée comme pleine et ne peut donc pas traiter les écritures.
pauserd, pausewr: Les lectures et les écritures sont mises en pause.
noup: Les OSD ne sont pas autorisés à démarrer.
nodown: Les rapports d'échec OSD sont ignorés de sorte que les moniteurs ne marquent pas les OSD comme down (arrêtés).
noin: Les OSD précédemment marqués comme out (hors service) ne sont pas marqués comme in (en service) lors de leur démarrage.
noout: Les OSD down (arrêtés) ne seront pas automatiquement marqués comme out (hors service) à l'issue de l'intervalle configuré.
nobackfill, norecover, norebalance: La récupération ou le rééquilibrage des données est suspendu.
noscrub, nodeep_scrub: Le nettoyage (reportez-vous à la Section 17.6, « Nettoyage des groupes de placement ») est désactivé.
notieragent: L'activité de hiérarchisation du cache est suspendue.

OSD_FLAGS

Un ou plusieurs OSD possèdent chacun un indicateur OSD. Ces indicateurs comprennent :

noup: L'OSD n'est pas autorisé à démarrer.
nodown: Les rapports d'échec sont ignorés pour cet OSD.
noin: Si cet OSD était auparavant marqué comme out automatiquement après un échec, il ne sera pas marqué comme in lors du démarrage.
noout: Si cet OSD est arrêté, il n'est pas automatiquement marqué comme out à l'issue de l'intervalle configuré.

Les indicateurs OSD peuvent être définis et effacés comme suit :

cephuser@adm > ceph osd add-flag osd-ID
cephuser@adm > ceph osd rm-flag osd-ID

OLD_CRUSH_TUNABLES

La carte CRUSH doit être mise à jour, car elle utilise des paramètres très anciens. Les paramètres les plus anciens qui peuvent être utilisés (c'est-à-dire la version client la plus ancienne pouvant se connecter à la grappe) sans déclencher cet avertissement d'intégrité sont déterminés par l'option de configuration mon_crush_min_required_version.

OLD_CRUSH_STRAW_CALC_VERSION

La carte CRUSH utilise une méthode non optimale plus ancienne afin de calculer les valeurs de pondération intermédiaires des compartiments straw. La carte CRUSH doit être mise à jour pour utiliser la nouvelle méthode (straw_calc_version=1).

CACHE_POOL_NO_HIT_SET

Une ou plusieurs réserves de cache ne sont pas configurées avec un jeu d'accès pour le suivi de l'utilisation, ce qui empêche l'agent de hiérarchisation d'identifier les objets inactifs à évincer du cache. Les jeux d'accès peuvent être configurés sur la réserve de cache comme suit :

cephuser@adm > ceph osd pool set poolname hit_set_type type
cephuser@adm > ceph osd pool set poolname hit_set_period period-in-seconds
cephuser@adm > ceph osd pool set poolname hit_set_count number-of-hitsets
cephuser@adm > ceph osd pool set poolname hit_set_fpp target-false-positive-rate

OSD_NO_SORTBITWISE

Aucun OSD d'une version antérieure à la version 12 « Luminous » ne s'exécute actuellement, mais l'indicateur sortbitwise n'est pas défini. Vous devez définir l'indicateur sortbitwise pour permettre le démarrage des OSD antérieurs à la version 12 « Luminous » ou plus récents :

cephuser@adm > ceph osd set sortbitwise

POOL_FULL

Une ou plusieurs réserves ont atteint leur quota et n'autorisent plus les écritures. Vous pouvez définir des quotas de réserve et leur utilisation comme suit :

cephuser@adm > ceph df detail

Vous pouvez augmenter le quota de réserve comme suit :

cephuser@adm > ceph osd pool set-quota poolname max_objects num-objects
cephuser@adm > ceph osd pool set-quota poolname max_bytes num-bytes

ou supprimer des données existantes pour réduire l'utilisation.

PG_AVAILABILITY

La disponibilité des données est réduite, ce qui signifie que la grappe ne peut pas traiter les requêtes de lecture ou d'écriture potentielles pour certaines de ses données. Plus précisément, un ou plusieurs groupes de placement se trouvent dans un état qui ne permet pas de traiter les requêtes d'E/S. Les états de groupe de placement posant problème sont les suivants : peering (homologation), stale (périmé), incomplete (incomplet) et l'absence d'état active (actif) (si ces conditions ne disparaissent pas rapidement). Pour plus de détails sur les groupes de placement affectés, exécutez la commande suivante :

cephuser@adm > ceph health detail

Dans la plupart des cas, la cause première est due au fait qu'un ou plusieurs OSD sont actuellement arrêtés. Pour connaître l'état des groupes de placement incriminés, exécutez la commande suivante :

cephuser@adm > ceph tell pgid query

PG_DEGRADED

La redondance des données est réduite pour certaines données, ce qui signifie que la grappe ne dispose pas du nombre de répliques souhaité pour toutes les données (pour les réserves répliquées) ou pour les fragments de code d'effacement (pour les réserves codées à effacement). Plus précisément, l'indicateur degraded (altéré) ou undersized (de taille insuffisante) est associé à un ou plusieurs groupes de placement (le nombre d'instances de ce groupe de placement est insuffisant dans la grappe) ou l'indicateur clean ne leur est pas associé depuis un certain temps. Pour plus de détails sur les groupes de placement affectés, exécutez la commande suivante :

cephuser@adm > ceph health detail

cephuser@adm > ceph tell pgid query

PG_DEGRADED_FULL

La redondance des données peut être réduite ou menacée pour certaines données en raison d'un manque d'espace libre dans la grappe. Plus précisément, l'indicateur backfill_toofull ou recovery_toofull est associé à un ou plusieurs groupes de placement, ce qui signifie que la grappe ne parvient pas à migrer ou à récupérer les données, car un ou plusieurs OSD ont dépassé le seuil backfillfull.

PG_DAMAGED

Le nettoyage des données (voir Section 17.6, « Nettoyage des groupes de placement ») a détecté des problèmes de cohérence des données dans la grappe. Plus précisément, l'indicateur inconsistent ou snaptrim_error est associé à un ou plusieurs groupes de placement, ce qui indique qu'une opération de nettoyage antérieure a détecté un problème ou que l'indicateur repair est défini, car une réparation est actuellement en cours pour une telle incohérence.

OSD_SCRUB_ERRORS

Les nettoyages récents d'OSD ont révélé des incohérences.

CACHE_POOL_NEAR_FULL

Une réserve de niveau de cache est presque pleine. Dans ce contexte, l'état Full est déterminé par les propriétés target_max_bytes et target_max_objects de la réserve de cache. Lorsque la réserve atteint le seuil cible, les requêtes d'écriture dans la réserve peuvent être bloquées pendant que les données sont vidées et évincées du cache, un état qui entraîne généralement des latences très élevées et des performances médiocres. La taille cible de la réserve de cache peut être définie ainsi :

cephuser@adm > ceph osd pool set cache-pool-name target_max_bytes bytes
cephuser@adm > ceph osd pool set cache-pool-name target_max_objects objects

L'activité normale de vidage et d'éviction du cache peut également être entravée en raison de la disponibilité ou des performances réduites du niveau de base ou de la charge globale de la grappe.

TOO_FEW_PGS

Le nombre de groupes de placement utilisés est inférieur au seuil configurable de mon_pg_warn_min_per_osd groupes de placement par OSD. Cela peut entraîner une distribution et un équilibrage sous-optimaux des données entre les OSD de la grappe, ce qui fait baisser les performances globales.

TOO_MANY_PGS

Le nombre de groupes de placement utilisés est supérieur au seuil configurable de mon_pg_warn_max_per_osd groupes de placement par OSD. Cela peut conduire à une utilisation plus importante de la mémoire pour les daemons OSD, à une homologation plus lente après des changements d'état de grappe (redémarrages, ajouts ou suppressions d'OSD, par exemple) et à une charge plus élevée des instances Ceph Manager et Ceph Monitor.

Contrairement à la valeur pg_num, la valeur pgp_num peut être réduite pour des réserves existantes. Cela permet de regrouper efficacement certains groupes de placement sur les mêmes ensembles d'OSD, atténuant ainsi quelques-uns des effets négatifs décrits ci-dessus. Il est possible d'ajuster la valeur de pgp_num comme suit :

cephuser@adm > ceph osd pool set pool pgp_num value

SMALLER_PGP_NUM

La valeur de pgp_num est inférieure à celle de pg_num pour une ou plusieurs réserves. Ceci indique normalement que le nombre de groupes de placement a été augmenté indépendamment du comportement de placement. Ce problème est résolu en définissant pgp_num et pg_num sur la même valeur, ce qui déclenche la migration de données, comme suit :

cephuser@adm > ceph osd pool set pool pgp_num pg_num_value

MANY_OBJECTS_PER_PG

Pour une ou plusieurs réserves, le nombre moyen d'objets par groupe de placement est sensiblement supérieur à la moyenne globale de la grappe. Le seuil spécifique est contrôlé par la valeur de configuration de mon_pg_warn_max_object_skew. Cela indique généralement que la ou les réserves contenant la plupart des données de la grappe possèdent un nombre trop faible de groupes de placement et/ou que les autres réserves ne contenant pas autant de données possèdent un nombre excessif de groupes de placement. Pour ne plus afficher l'avertissement d'intégrité, vous pouvez relever le seuil en ajustant l'option de configuration mon_pg_warn_max_object_skew sur les moniteurs.

POOL_APP_NOT_ENABLED

Il existe une réserve qui contient un ou plusieurs objets, mais qui n'a pas été marquée pour une utilisation par une application particulière. Pour que cet avertissement ne s'affiche plus, étiquetez la réserve pour qu'elle soit utilisée par une application. Par exemple, si la réserve est utilisée par RBD :

cephuser@adm > rbd pool init pool_name

Si la réserve est utilisée par une application personnalisée « foo », vous pouvez également l'étiqueter à l'aide de la commande de bas niveau :

cephuser@adm > ceph osd pool application enable foo

POOL_FULL

Une ou plusieurs réserves ont atteint leur quota (ou sont proches des 100 %). Le seuil de déclenchement de cette condition d'erreur est contrôlé par l'option de configuration mon_pool_quota_crit_threshold. Les quotas de réserve peuvent être ajustés à la hausse ou à la baisse (voire supprimés) comme suit :

cephuser@adm > ceph osd pool set-quota pool max_bytes bytes
cephuser@adm > ceph osd pool set-quota pool max_objects objects

Définir la valeur de quota sur 0 désactive le quota.

POOL_NEAR_FULL

Une ou plusieurs réserves se rapprochent de leur quota. Le seuil de déclenchement de cette condition d'avertissement est contrôlé par l'option de configuration mon_pool_quota_warn_threshold. Les quotas de réserve peuvent être ajustés à la hausse ou à la baisse (voire supprimés) comme suit :

cephuser@adm > ceph osd osd pool set-quota pool max_bytes bytes
cephuser@adm > ceph osd osd pool set-quota pool max_objects objects

Définir la valeur de quota sur 0 désactive le quota.

OBJECT_MISPLACED

Un ou plusieurs objets de la grappe ne sont pas stockés sur le noeud prévu par la grappe. Cela indique que la migration de données due à une modification récente de la grappe n'a pas encore abouti. Un mauvais placement des données n'est pas dangereux en soi. La cohérence des données n'est jamais compromise et les anciennes copies d'objets ne sont jamais supprimées tant que le nombre de nouvelles copies souhaité n'est pas atteint (dans les emplacements souhaités).

OBJECT_UNFOUND

Un ou plusieurs objets de la grappe sont introuvables. Plus précisément, les OSD savent qu'une copie nouvelle ou mise à jour d'un objet doit exister, mais la copie de cette version de l'objet est introuvable sur les OSD actuellement opérationnels. Les requêtes de lecture ou d'écriture sur les objets « introuvables » seront bloquées. Idéalement, l'OSD hors service qui héberge la copie la plus récente de l'objet introuvable peut être remis en service. Les OSD candidats peuvent être identifiés à partir de l'état d'homologation du ou des groupes de placement associés à l'objet introuvable :

cephuser@adm > ceph tell pgid query

REQUEST_SLOW

Une ou plusieurs requêtes OSD sont longues à traiter. Cela peut indiquer une charge extrême, un périphérique de stockage lent ou un bogue logiciel. Vous pouvez interroger la file d'attente des requêtes sur le ou les OSD en question, exécutez la commande suivante à partir de l'hôte OSD :

cephuser@adm > ceph daemon osd.id ops

Vous pouvez afficher le résumé des requêtes récentes les plus lentes :

cephuser@adm > ceph daemon osd.id dump_historic_ops

Vous pouvez trouver l'emplacement d'un OSD avec :

cephuser@adm > ceph osd find osd.id

REQUEST_STUCK

Une ou plusieurs requêtes d'OSD ont été bloquées pendant une période relativement longue, par exemple 4 096 secondes. Cela indique que l'état de santé de la grappe n'est pas bon depuis un certain temps (par exemple, en raison du faible nombre d'OSD actifs ou de groupes de placement inactifs), ou que l'OSD concernée présente un problème interne.

PG_NOT_SCRUBBED

Un ou plusieurs groupes de placement n'ont pas été nettoyés récemment (reportez-vous à la Section 17.6, « Nettoyage des groupes de placement »). Les groupes de placement sont normalement nettoyés toutes les mon_scrub_interval secondes ; cet avertissement se déclenche lorsque mon_warn_not_scrubbed intervalles se sont écoulés sans nettoyage. Les groupes de placement ne sont pas nettoyés s'ils ne sont pas marqués comme propres, ce qui peut arriver s'ils sont mal placés ou altérés (voir PG_AVAILABILITY et PG_DEGRADED ci-dessus). Vous pouvez lancer manuellement le nettoyage d'un groupe de placement :

cephuser@adm > ceph pg scrub pgid

PG_NOT_DEEP_SCRUBBED

Un ou plusieurs groupes de placement n'ont pas été nettoyés en profondeur récemment (reportez-vous à la Section 17.6, « Nettoyage des groupes de placement »). Les groupes de placement sont normalement nettoyés toutes les osd_deep_mon_scrub_interval secondes ; cet avertissement se déclenche lorsque mon_warn_not_deep_scrubbed secondes se sont écoulées sans nettoyage. Les groupes de placement n'ont pas été nettoyés (en profondeur) s'ils ne sont pas marqués comme propres, ce qui peut arriver s'ils sont mal placés ou altérés (voir PG_AVAILABILITY et PG_DEGRADED ci-dessus). Vous pouvez lancer manuellement le nettoyage d'un groupe de placement :

cephuser@adm > ceph pg deep-scrub pgid

Astuce

Si vous avez choisi des emplacements autres que ceux par défaut pour votre configuration ou votre trousseau de clés, vous pouvez les indiquer ici :

root # ceph -c /path/to/conf -k /path/to/keyring health

12.3 Vérification des statistiques d'utilisation d'une grappe #

Pour vérifier l'utilisation des données d'une grappe et leur distribution entre les réserves, utilisez la commande ceph df. Pour obtenir plus de détails, utilisez ceph df detail.

cephuser@adm > ceph df
--- RAW STORAGE ---
CLASS  SIZE    AVAIL   USED     RAW USED  %RAW USED
hdd    30 GiB  27 GiB  121 MiB   3.1 GiB      10.40
TOTAL  30 GiB  27 GiB  121 MiB   3.1 GiB      10.40

--- POOLS ---
POOL                   ID  STORED   OBJECTS  USED     %USED  MAX AVAIL
device_health_metrics   1      0 B        0      0 B      0    8.5 GiB
cephfs.my_cephfs.meta   2  1.0 MiB       22  4.5 MiB   0.02    8.5 GiB
cephfs.my_cephfs.data   3      0 B        0      0 B      0    8.5 GiB
.rgw.root               4  1.9 KiB       13  2.2 MiB      0    8.5 GiB
myzone.rgw.log          5  3.4 KiB      207    6 MiB   0.02    8.5 GiB
myzone.rgw.control      6      0 B        8      0 B      0    8.5 GiB
myzone.rgw.meta         7      0 B        0      0 B      0    8.5 GiB

La section RAW STORAGE de la sortie donne un aperçu de la quantité de stockage utilisée pour vos données par la grappe.

CLASS : classe de stockage du périphérique. Reportez-vous à la Section 17.1.1, « Classes de périphériques » pour plus d'informations sur les classes de périphériques.
SIZE : capacité de stockage globale de la grappe.
AVAIL : quantité d'espace disponible dans la grappe.
USED : espace (accumulé sur tous les OSD) alloué uniquement pour les objets de données conservés sur le périphérique de bloc.
RAW USED : somme de l'espace « USED » et de l'espace alloué/réservé au niveau du périphérique de bloc pour Ceph, par exemple la partie blueFS pour BlueStore.
% RAW USED : pourcentage de stockage brut utilisé. Utilisez ce nombre avec le ratio full et le ratio near full pour vous assurer que vous n'atteignez pas la capacité de votre grappe. Reportez-vous à la Section 12.8, « Capacité de stockage » pour plus de détails.
Note : niveau de remplissage de grappe
Lorsqu'un niveau de remplissage de stockage brut se rapproche de 100 %, vous devez ajouter un nouveau stockage à la grappe. Une utilisation plus élevée peut conduire à la saturation de certains OSD et à des problèmes d'intégrité de la grappe.
Utilisez la commande ceph osd df tree pour établir la liste de niveau de remplissage de tous les OSD.

La section POOLS de la sortie fournit la liste des réserves et l'utilisation théorique de chaque réserve. La sortie de cette section ne reflète pas les répliques, les clones ou les instantanés existants. Par exemple, si vous stockez un objet de 1 Mo de données, l'utilisation théorique est de 1 Mo, mais l'utilisation réelle peut être de 2 Mo ou plus selon le nombre de répliques, de clones et d'instantanés.

POOL : nom de la réserve.
ID : identifiant de la réserve.
STORED : quantité de données stockées par l'utilisateur.
OBJECTS : nombre théorique d'objets stockés par réserve.
USED : quantité d'espace allouée exclusivement aux données par tous les noeuds OSD (en ko).
% USED : pourcentage de stockage théorique utilisé par réserve.
MAX AVAIL : espace maximal disponible dans la réserve indiquée.

Note

Les nombres figurant dans la section POOLS sont théoriques. Ils n'incluent pas le nombre de répliques, d'instantanés ou de clones. Par conséquent, la somme des montants USED et %USED ne correspond pas aux montants RAW USED et %RAW USED dans la section RAW STORAGE de la sortie.

12.4 Vérification de l'état des OSD #

Vous pouvez vérifier les OSD pour vous assurer qu'ils sont opérationnels et activés à l'aide de la commande suivante :

cephuser@adm > ceph osd stat

cephuser@adm > ceph osd dump

Vous pouvez également afficher les OSD en fonction de leur position dans la carte CRUSH.

ceph osd tree permet d'afficher une arborescence CRUSH avec un hôte, ses OSD, leur état et leur pondération :

   cephuser@adm > ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME              STATUS  REWEIGHT  PRI-AFF
-1      3  0.02939  root default
-3      3  0.00980    rack mainrack
-2      3  0.00980            host osd-host
0       1  0.00980                    osd.0   up   1.00000   1.00000
1       1  0.00980                    osd.1   up   1.00000   1.00000
2       1  0.00980                    osd.2   up   1.00000   1.00000

12.5 Contrôle des OSD pleins #

Ceph vous empêche d'écrire sur un OSD plein afin de vous éviter de perdre des données. Pour une grappe opérationnelle, un message d'avertissement doit s'afficher lorsque celle-ci est sur le point d'atteindre son ratio complet. La valeur par défaut de monosd full ratio est 0.95, c'est-à-dire 95 % de la capacité au-delà de laquelle les clients ne peuvent plus écrire de données dans la grappe. La valeur par défaut de monosd nearfull ratio est de 0.85, c'est-à-dire 85 % de la capacité à partir de laquelle un message d'avertissement d'intégrité est émis.

Les noeuds OSD pleins sont signalés par la commande ceph health :

cephuser@adm > ceph health
  HEALTH_WARN 1 nearfull osds
  osd.2 is near full at 85%

cephuser@adm > ceph health
  HEALTH_ERR 1 nearfull osds, 1 full osds
  osd.2 is near full at 85%
  osd.3 is full at 97%

La meilleure façon de gérer une grappe pleine consiste à ajouter de nouveaux hôtes/disques OSD permettant à la grappe de redistribuer les données à l'espace de stockage récemment disponible.

Astuce : prévention de la saturation des OSD

Un OSD plein utilise 100 % de son espace disque. Lorsqu'il atteint ce taux de remplissage, l'OSD se bloque sans avertissement. Voici quelques conseils à retenir lors de l'administration de noeuds OSD.

L'espace disque de chaque OSD (généralement monté sous /var/lib/ceph/osd/osd-{1,2..}) doit être placé sur une partition ou un disque sous-jacent dédié.
Vérifiez les fichiers de configuration Ceph et assurez-vous que Ceph ne stocke pas son fichier journal sur les partitions/disques dédiés aux OSD.
Assurez-vous qu'aucun autre processus n'écrit sur les partitions/disques dédiés aux OSD.

12.6 Vérification de l'état des instances Monitor #

Après avoir démarré la grappe et avant la première lecture et/ou écriture de données, vérifiez le statut du quorum des instances Ceph Monitor. Lorsque la grappe dessert déjà des requêtes, vérifiez périodiquement le statut des instances Ceph Monitor pour vous assurer qu'elles sont en cours d'exécution.

Pour afficher l'assignation des moniteurs, exécutez la commande suivante :

cephuser@adm > ceph mon stat

cephuser@adm > ceph mon dump

Pour contrôler l'état du quorum de la grappe de moniteurs, exécutez la commande suivante :

cephuser@adm > ceph quorum_status

Ceph renvoie l'état du quorum. Par exemple, une grappe Ceph composée de trois moniteurs peut renvoyer les éléments suivants :

{ "election_epoch": 10,
  "quorum": [
        0,
        1,
        2],
  "monmap": { "epoch": 1,
      "fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
      "modified": "2011-12-12 13:28:27.505520",
      "created": "2011-12-12 13:28:27.505520",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "192.168.1.10:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "192.168.1.11:6789\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "192.168.1.12:6789\/0"}
           ]
    }
}

12.7 Vérification des états des groupes de placement #

Les groupes de placement assignent des objets aux OSD. Lorsque vous surveillez vos groupes de placement, vous voulez qu'ils soient actifs (active) et propres (clean). Pour une explication détaillée, reportez-vous à la Section 12.9, « Surveillance des OSD et des groupes de placement ».

12.8 Capacité de stockage #

Lorsqu'une grappe de stockage Ceph se rapproche de sa capacité maximale, Ceph vous empêche d'écrire ou de lire à partir d'OSD Ceph afin d'éviter toute perte de données. Par conséquent, laisser une grappe de production s'approcher de son ration « full » n'est pas une bonne pratique, car cela nuit au principe de haute disponibilité. Le ratio « full » par défaut est défini sur 0,95, soit 95 % de la capacité. C'est une valeur très agressive pour une grappe de test avec un petit nombre d'OSD.

Astuce : augmentation de la capacité de stockage

Lorsque vous surveillez votre grappe, soyez attentif aux avertissements liés au ratio nearfull. Cela signifie qu'une défaillance de certains OSD pourrait entraîner une interruption de service temporaire en cas d'échec d'un ou de plusieurs OSD. Pensez à ajouter d'autres OSD pour augmenter la capacité de stockage.

Un scénario courant pour les grappes de test implique qu'un administrateur système supprime un OSD Ceph de la grappe de stockage Ceph pour examiner le rééquilibrage de la grappe. Il supprime ensuite un autre OSD Ceph, puis encore un autre, et ainsi de suite jusqu'à ce que la grappe atteigne le ratio « full » et se verrouille. Nous recommandons un minimum de planification de la capacité, même avec une grappe de test. La planification vous permet d'estimer la capacité de réserve dont vous avez besoin pour maintenir une haute disponibilité. Idéalement, vous souhaitez envisager une série de défaillances Ceph OSD où la grappe peut récupérer un état actif et propre (active + clean) sans remplacer ces Ceph OSD immédiatement. Vous pouvez exécuter une grappe dans un état actif et altéré (active + degraded), mais ce n'est pas idéal pour des conditions de fonctionnement normales.

Le diagramme suivant représente une grappe de stockage Ceph simpliste contenant 33 noeuds Ceph avec un Ceph OSD par hôte, chacun d'eux disposant d'un accès en lecture-écriture pour une unité de 3 To. Cette grappe présente une capacité réelle maximale de 99 To. L'option mon osd full ratio est définie sur 0,95. Si la grappe arrive à 5 To de la capacité restante, elle ne permettra plus aux clients de lire et d'écrire des données. Par conséquent, la capacité d'exploitation de la grappe de stockage est de 95 To, et pas de 99.

Figure 12.1 : grappe Ceph #

Il est normal dans une telle grappe qu'un ou deux OSD échouent. Un scénario moins fréquent, mais plausible, implique une défaillance du routeur ou de l'alimentation d'un rack, ce qui met hors service plusieurs OSD simultanément (par exemple, les OSD 7 à 12). Dans un tel scénario, vous devez toujours viser à disposer d'une grappe qui peut rester opérationnelle et atteindre un état active + clean, même si cela implique d'ajouter sans délai plusieurs hôtes avec des OSD supplémentaires. Si l'utilisation de votre capacité est trop élevée, vous ne pouvez pas risquer de perdre des données. Cela dit, vous pourriez encore sacrifier la disponibilité des données pendant la résolution d'une panne au sein d'un domaine défaillant si l'utilisation de la capacité de la grappe dépasse le ratio « full ». C'est pour cette raison que nous recommandons au moins une certaine planification approximative de la capacité.

Identifiez deux nombres pour votre grappe :

Le nombre d'OSD.
La capacité totale de la grappe.

Si vous divisez la capacité totale de votre grappe par le nombre d'OSD que celle-ci contient, vous obtenez la capacité moyenne d'un OSD au sein de votre grappe. Pensez à multiplier cette valeur par le nombre d'OSD qui, selon vous, pourraient échouer simultanément lors d'opérations normales (un nombre relativement faible). Enfin, multipliez la capacité de la grappe par le ratio « full » pour arriver à une capacité d'exploitation maximale. Ensuite, soustrayez la quantité de données des OSD susceptibles d'échouer pour obtenir un ratio « full » raisonnable. Répétez ce processus avec un nombre plus élevé de défaillances OSD (un rack d'OSD) afin d'obtenir un nombre raisonnable pour un ratio « nearfull ».

Les paramètres suivants ne s'appliquent qu'à la création d'une grappe et sont ensuite stockés dans la carte OSD :

[global]
 mon osd full ratio = .80
 mon osd backfillfull ratio = .75
 mon osd nearfull ratio = .70

Astuce

Ces paramètres ne s'appliquent que lors de la création d'une grappe. Par la suite, ils doivent être modifiés dans la carte OSD à l'aide des commandes ceph osd set-nearfull-ratio et ceph osd set-full-ratio.

mon osd full ratio: Pourcentage d'espace disque utilisé avant qu'un OSD soit considéré comme complet (full). La valeur par défaut est 0,95.
mon osd backfillfull ratio: Pourcentage d'espace disque utilisé avant qu'un OSD soit considéré comme trop rempli (full) pour un renvoi. La valeur par défaut est 0,90.
mon osd nearfull ratio: Pourcentage d'espace disque utilisé avant qu'un OSD soit considéré comme presque complet (nearfull). La valeur par défaut est 0,85.

Astuce : vérification de la pondération des OSD

Si certains OSD sont presque complets (nearfull), mais que d'autres ont beaucoup de capacité, la pondération CRUSH peut être problématique pour les OSD nearfull.

12.9 Surveillance des OSD et des groupes de placement #

Les principes de haute disponibilité et de haute fiabilité exigent une approche de tolérance aux pannes dans le cadre de la gestion des problèmes matériels et logiciels. Ceph n'a pas de point d'échec unique et peut desservir les requêtes de données en mode altéré (« degraded »). Le placement de données de Ceph introduit une couche d'indirection pour s'assurer que les données ne se lient pas directement à des adresses OSD particulières. Cela signifie que le suivi des pannes du système nécessite de trouver le groupe de placement et les OSD sous-jacents à l'origine du problème.

Astuce : accès en cas de défaillance

Une panne dans une partie de la grappe peut vous empêcher d'accéder à un objet particulier. Cela ne signifie pas que vous ne pouvez pas accéder à d'autres objets. Lorsque vous rencontrez une panne, suivez les étapes de surveillance de vos OSD et groupes de placement. Commencez ensuite le dépannage.

Ceph peut généralement se réparer lui-même. Toutefois, lorsque des problèmes persistent, la surveillance des OSD et des groupes de placement vous aide à identifier ce qui ne va pas.

12.9.1 Surveillance des OSD #

Le statut d'un OSD est soit dans la grappe (« rentré », c'est-à-dire « in » en anglais), soit hors de la grappe (« sorti » - « out »). Par ailleurs, il est soit opérationnel et en cours d'exécution (« opérationnel » - « up »), soit arrêté et pas en cours d'exécution (« arrêté » - « down »). Si un OSD est « opérationnel », il peut être dans la grappe (vous pouvez lire et écrire des données) ou hors de celle-ci. S'il était dans la grappe et a été sorti récemment de cette dernière, Ceph migre les groupes de placement vers d'autres OSD. Si un OSD est hors de la grappe, CRUSH ne lui assigne pas de groupes de placement. Si un OSD est « arrêté », il doit également être « sorti ».

Note : état altéré

Si un OSD est « arrêté » et « rentré », il y a un problème et la grappe présente un état altéré.

Si vous exécutez une commande telle que ceph health, ceph -s ou ceph -w, vous pouvez remarquer que la grappe ne renvoie pas toujours la valeur HEALTH OK (État de santé OK). En ce qui concerne les OSD, vous devez vous attendre à ce que la grappe ne renvoie pas la valeur HEALTH OK dans les circonstances suivantes :

Vous n'avez pas encore démarré la grappe (elle ne répondra pas).
Vous avez démarré ou redémarré la grappe et elle n'est pas encore prête, car les groupes de placement sont en cours de création et les OSD, en cours d'homologation.
Vous avez ajouté ou supprimé un OSD.
Vous avez modifié votre assignation de grappe.

Un aspect important de la surveillance des OSD consiste à s'assurer que lorsque la grappe est opérationnelle et en cours d'exécution, tous ses OSD le sont aussi. Pour vérifier si tous les OSD sont en cours d'exécution, utilisez la commande suivante :

root # ceph osd stat
x osds: y up, z in; epoch: eNNNN

Le résultat devrait vous indiquer le nombre total d'OSD (x), combien sont « opérationnels » (y), combien sont « rentrés » (z), et l'époque d'assignation (eNNNN). Si le nombre d'OSD « rentrés » dans la grappe est supérieur au nombre d'OSD qui sont « opérationnels », exécutez la commande suivante pour identifier les daemons ceph-osd qui ne sont pas en cours d'exécution :

root # ceph osd tree
#ID CLASS WEIGHT  TYPE NAME             STATUS REWEIGHT PRI-AFF
-1       2.00000 pool openstack
-3       2.00000 rack dell-2950-rack-A
-2       2.00000 host dell-2950-A1
0   ssd 1.00000      osd.0                up  1.00000 1.00000
1   ssd 1.00000      osd.1              down  1.00000 1.00000

Par exemple, si un OSD avec l'ID 1 est arrêté, démarrez-le :

cephuser@osd > sudo systemctl start ceph-CLUSTER_ID@osd.0.service

Reportez-vous au Section 4.3, « OSDs not running » pour obtenir des informations sur les problèmes associés aux OSD qui se sont arrêtés ou qui ne redémarrent pas.

12.9.2 Assignation d'ensembles de groupes de placement #

Lorsque CRUSH assigne des groupes de placement aux OSD, il examine le nombre de répliques pour la réserve et attribue le groupe de placement aux OSD de telle sorte que chaque réplique du groupe de placement soit assignée à un OSD différent. Par exemple, si la réserve nécessite trois répliques d'un groupe de placement, CRUSH peut les assigner à osd.1, osd.2 et osd.3 respectivement. CRUSH vise en fait un placement pseudo-aléatoire qui tiendra compte des domaines de défaillance que vous avez définis dans votre carte CRUSH, de sorte que vous verrez rarement des groupes de placement assignés à des OSD voisins les plus proches dans une vaste grappe. Nous nous référons à l'ensemble d'OSD qui devraient contenir les répliques d'un groupe de placement particulier en tant qu'ensemble agissant. Dans certains cas, un OSD de l'ensemble agissant est arrêté ou n'est pas en mesure de desservir les requêtes d'objets dans le groupe de placement pour l'une ou l'autre raison. Ces situations peuvent se présenter dans l'un des scénarios suivants :

Vous avez ajouté ou supprimé un OSD. Ensuite, CRUSH a réassigné le groupe de placement à d'autres OSD et a donc modifié la composition de l'ensemble agissant, provoquant la migration de données avec un processus de renvoi (« backfill »).
Un OSD était « arrêté », a été redémarré et est maintenant en cours de récupération.
Un OSD de l'ensemble agissant est « arrêté » ou n'est pas en mesure de desservir les requêtes, et un autre OSD a assumé temporairement ses fonctions.
Ceph traite une requête client à l'aide de l'ensemble opérationnel, qui est l'ensemble d'OSD qui traitera réellement les requêtes. Dans la plupart des cas, l'ensemble opérationnel et l'ensemble agissant sont pratiquement identiques. Lorsqu'ils ne le sont pas, cela peut indiquer que Ceph migre des données, qu'un OSD est en cours de récupération ou qu'il existe un problème (par exemple, dans de tels scénarios, Ceph renvoie habituellement un état HEALTH WARN avec un message « stuck stale » [obsolète bloqué]).

Pour récupérer une liste des groupes de placement, exécutez la commande suivante :

cephuser@adm > ceph pg dump

Pour voir quels OSD se trouvent dans l'ensemble agissant ou dans l'ensemble opérationnel pour un groupe de placement donné, exécutez la commande suivante :

cephuser@adm > ceph pg map PG_NUM
osdmap eNNN pg RAW_PG_NUM (PG_NUM) -> up [0,1,2] acting [0,1,2]

Le résultat devrait vous indiquer l'époque osdmap (eNNN), le nombre de groupes de placement (PG_NUM), les OSD dans l'ensemble opérationnel (« up ») et les OSD dans l'ensemble agissant (« acting ») :

Astuce : indicateur de problème de grappe

Si l'ensemble opérationnel et l'ensemble agissant ne correspondent pas, cela peut indiquer que la grappe est occupée à se rééquilibrer ou qu'elle rencontre un problème potentiel.

12.9.3 Homologation #

Avant de pouvoir écrire des données dans un groupe de placement, celui-ci doit présenter un état actif (« active ») et propre (« clean »). Pour que Ceph puisse déterminer l'état actuel d'un groupe de placement, l'OSD primaire du groupe de placement (le premier OSD dans l'ensemble agissant) effectue une homologation avec les OSD secondaires et tertiaires pour établir un accord sur l'état actuel du groupe de placement (dans le cas d'une réserve avec trois répliques du groupe de placement).

Figure 12.2 : Schéma d'homologation #

12.9.4 Surveillance des états des groupes de placement #

Si vous exécutez une commande telle que ceph health, ceph -s ou ceph -w, vous remarquerez peut-être que la grappe ne renvoie pas toujours un message HEALTH OK (État de santé OK). Après avoir vérifié si les OSD sont en cours d'exécution, vous devez également vérifier l'état des groupes de placement.

Attendez-vous à ce que la grappe ne renvoie pas un message HEALTH OK dans un certain nombre de circonstances liées aux homologations des groupes de placement :

Vous avez créé une réserve et les groupes de placement n'ont pas encore effectué l'homologation.
Les groupes de placement sont en cours de récupération.
Vous avez ajouté ou supprimé un OSD au niveau de la grappe.
Vous avez modifié votre carte CRUSH et vos groupes de placement sont en cours de migration.
Les données sont incohérentes entre différentes répliques d'un groupe de placement.
Ceph est en train de nettoyer les répliques d'un groupe de placement.
Ceph ne dispose pas de suffisamment de capacité de stockage pour effectuer des opérations de renvoi.

Si en raison de l'une des circonstances mentionnées ci-dessus, Ceph renvoie un message HEALTH WARN, ne paniquez pas. Dans de nombreux cas, la grappe se rétablit d'elle-même. Parfois, il peut cependant arriver que vous deviez intervenir. Un aspect important de la surveillance des groupes de placement consiste à vous assurer que lorsque la grappe est opérationnelle et en cours d'exécution, tous les groupes de placement sont actifs et, de préférence, dans un état propre. Pour voir l'état de tous les groupes de placement, exécutez la commande suivante :

cephuser@adm > ceph pg stat
x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

Le résultat devrait vous indiquer le nombre total de groupes de placement (x), le nombre de groupes de placement dans un état particulier tel que le « active + clean » (y) et la quantité de données stockées (z).

En plus des états des groupes de placement, Ceph renverra également la quantité de capacité de stockage utilisée (aa), la quantité de capacité de stockage restante (bb) et la capacité de stockage totale pour le groupe de placement. Ces chiffres peuvent être importants dans certains cas :

Vous vous approchez de votre ratio nearfull (presque complet) ou full (complet).
Vos données ne sont pas distribuées dans l'ensemble de la grappe en raison d'une erreur dans votre configuration CRUSH.

Astuce : ID de groupe de placement

Les ID de groupe de placement se composent du numéro de la réserve (pas de son nom) suivi d'un point (.) et de l'ID du groupe de placement (un nombre hexadécimal). Vous pouvez consulter les numéros des réserves et leur nom dans la sortie de la commande ceph osd lspools. Par exemple, la réserve par défaut rbd correspond au numéro de réserve 0. Un ID de groupe de placement complet se présente sous la forme suivante :

POOL_NUM.PG_ID

Il ressemble généralement à ceci :

0.1f

Pour récupérer une liste des groupes de placement, exécutez la commande suivante :

cephuser@adm > ceph pg dump

Vous pouvez également mettre la sortie au format JSON et l'enregistrer dans un fichier :

cephuser@adm > ceph pg dump -o FILE_NAME --format=json

Pour interroger un groupe de placement particulier, exécutez la commande suivante :

cephuser@adm > ceph pg POOL_NUM.PG_ID query

La liste suivante décrit en détail les statuts courants des groupes de placement.

CREATING

Lorsque vous créez une réserve, celle-ci crée le nombre de groupes de placement que vous avez spécifié. Ceph renvoie le statut « creating » (en cours de création) lorsqu'un ou plusieurs groupes de placement sont en cours de création. Une fois les groupes créés, les OSD qui font partie de l'ensemble agissant du groupe de placement effectuent l'homologation. Lorsque l'homologation est terminée, le statut du groupe de placement doit être « active + clean », ce qui signifie qu'un client Ceph peut commencer à écrire dans le groupe de placement.

Figure 12.3 : État des groupes de placement #

PEERING

Lorsque Ceph effectue l'homologation (« peering ») d'un groupe de placement, il amène les OSD qui stockent les répliques du groupe de placement à un accord concernant l'état des objets et des métadonnées que ce dernier contient. Lorsque Ceph termine l'homologation, cela signifie que les OSD qui stockent le groupe de placement s'accordent sur l'état actuel du groupe de placement. Toutefois, l'achèvement du processus d'homologation ne signifie pas que chaque réplique dispose du contenu le plus récent.

Note : historique faisant autorité

Ceph ne reconnaîtra une opération d'écriture pour un client que lorsque tous les OSD de l'ensemble agissant conserveront l'opération d'écriture. Cette pratique garantit qu'au moins un membre de l'ensemble agissant aura un enregistrement de chaque opération d'écriture reconnue depuis la dernière opération d'homologation réussie.

Avec un enregistrement précis de chaque opération d'écriture reconnue, Ceph peut construire et développer un nouvel historique faisant autorité pour le groupe de placement, à savoir un ensemble complet et organisé d'opérations qui, si elles sont effectuées, permettent de mettre à jour la copie d'un OSD de groupe de placement.

ACTIVE

Une fois que Ceph a terminé le processus d'homologation, un groupe de placement peut devenir actif (« active »). L'état « active » signifie que les données du groupe de placement sont généralement disponibles dans le groupe de placement primaire et les répliques pour les opérations de lecture et d'écriture.

CLEAN

Lorsqu'un groupe de placement est dans l'état propre (« clean »), cela signifie que l'OSD primaire et les OSD des répliques ont été homologués, et qu'il n'y a pas de répliques errantes pour le groupe de placement. Ceph a effectué le bon nombre de répliques de tous les objets du groupe de placement.

DEGRADED

Lorsqu'un client écrit un objet sur l'OSD primaire, ce dernier est responsable de l'écriture des répliques sur les OSD des répliques. Une fois que l'OSD primaire a écrit l'objet dans le stockage, le groupe de placement reste dans un état altéré (« degraded ») jusqu'à ce que l'OSD primaire ait reçu une confirmation des OSD des répliques indiquant que Ceph a bien créé les objets des répliques.

La raison pour laquelle un groupe de placement peut être à la fois actif et altéré (« active + degraded ») est qu'un OSD peut être actif même s'il ne détient pas encore tous les objets. Si un OSD s'arrête, Ceph marque chaque groupe de placement assigné à l'OSD comme altéré. Lorsque l'OSD en question redevient opérationnel, tous les OSD doivent à nouveau effectuer l'homologation. Toutefois, un client peut toujours écrire un nouvel objet sur un groupe de placement altéré s'il est actif.

Si un OSD est arrêté et que la condition d'altération persiste, Ceph peut marquer l'OSD arrêté comme étant sorti (« out ») de la grappe et réassigne les données de l'OSD arrêté à un autre OSD. Le délai entre le moment où un OSD est marqué comme arrêté et celui où il est considéré comme sorti de la grappe est déterminé par l'option mon osd down out interval, qui est définie par défaut sur 600 secondes.

Un groupe de placement peut également être marqué comme altéré parce que Ceph ne parvient pas à trouver un ou plusieurs objets qui devraient être dans le groupe de placement. Bien que vous ne puissiez pas lire ou écrire sur des objets introuvables, vous pouvez toujours accéder à tous les autres objets du groupe de placement altéré.

RECOVERING

Ceph a été conçu pour permettre une tolérance aux pannes dans un environnement où les problèmes matériels et logiciels sont permanents. Lorsqu'un OSD est arrêté, son contenu peut devenir obsolète par rapport à l'état actuel d'autres répliques dans les groupes de placement. Lorsque l'OSD redevient opérationnel, le contenu des groupes de placement doit alors être mis à jour pour refléter l'état actuel. Durant cette opération, l'état de l'OSD peut indiquer qu'il est en cours de récupération (« recovering»).

La récupération n'est pas toujours simple, car une défaillance matérielle peut provoquer une défaillance en cascade de plusieurs OSD. Par exemple, un commutateur réseau pour un rack ou une armoire peut tomber en panne, de sorte les OSD de plusieurs machines hôtes se retrouvent dans un état obsolète par rapport à celui de la grappe. Chacun de ces OSD doit alors récupérer une fois la panne résolue.

Ceph fournit un certain nombre de paramètres pour équilibrer les conflits de ressources entre les nouvelles requêtes de service et la nécessité de récupérer les objets de données et de restaurer les groupes de placement vers l'état actuel. Le paramètre osd recovery delay start permet à un OSD de redémarrer, d'effectuer un nouveau processus d'homologation et même de traiter certaines demandes de relecture avant d'entamer sa récupération. Le paramètre osd recovery thread timeout définit un timeout de thread, car plusieurs OSD peuvent échouer, redémarrer et effectuer une nouvelle homologation à des moments différents. Le paramètre osd recovery max active limite le nombre de demandes de récupération qu'un OSD traite simultanément afin d'éviter qu'il échoue. Le paramètre osd recovery max chunk limite la taille des tranches de données récupérées pour éviter la congestion du réseau.

BACK FILLING

Lorsqu'un nouvel OSD rejoint la grappe, CRUSH réassigne des groupes de placement des OSD de la grappe à l'OSD récemment ajouté. Obliger le nouvel OSD à accepter immédiatement les groupes de placement réassignés peut lui imposer une charge excessive. Le principe de renvoi (« backfilling ») de l'OSD avec les groupes de placement permet à ce processus de commencer en arrière-plan. Une fois le renvoi terminé, le nouvel OSD commence à desservir les requêtes lorsqu'il est prêt.

Pendant les opérations de renvoi, vous pouvez voir l'un des états suivants : « backfill_wait » indique qu'une opération de renvoi est en attente, mais pas encore en cours ; « backfill » indique qu'une opération de renvoi est en cours ; « backfill_too_full » indique qu'une opération de renvoi a été demandée, mais n'a pas pu être effectuée en raison d'une capacité de stockage insuffisante. Lorsqu'un groupe de placement ne peut pas être renvoyé, il peut être considéré comme incomplet (« incomplete »).

Ceph fournit plusieurs paramètres pour gérer la charge associée à la réassignation de groupes de placement à un OSD (en particulier un nouvel OSD). Par défaut, le paramètre osd max backfills définit le nombre maximal de renvois simultanés vers un OSD ou à partir de celui-ci à 10. Le paramètre backfill full ratio permet à un OSD de refuser une demande de renvoi si l'OSD se rapproche de son ratio « full » (90 % par défaut) et de changer avec la commande ceph osd set-backfillfull-ratio. Si un OSD refuse une demande de renvoi, le paramètre osd backfill retry interval permet à un OSD de réessayer la demande (après 10 secondes, par défaut). Les OSD peuvent également définir les paramètres osd backfill scan min et osd backfill scan max pour gérer les intervalles d'analyse (64 et 512, par défaut).

REMAPPED

Lorsque l'ensemble agissant qui dessert un groupe de placement change, les données migrent de l'ancien ensemble agissant ver le nouvel ensemble agissant. Un nouvel OSD primaire peut nécessiter un certain temps pour desservir des requêtes. C'est pourquoi il peut demander à l'ancien OSD primaire de continuer à traiter les requêtes jusqu'à ce que la migration du groupe de placement soit terminée. Une fois la migration des données terminée, l'assignation utilise l'OSD primaire du nouvel ensemble agissant.

STALE

Tandis que Ceph utilise des pulsations pour s'assurer que les hôtes et les daemons sont en cours d'exécution, les daemons ceph-osd peuvent également se retrouver dans un état bloqué (« stuck ») dans lequel ils ne rendent pas compte des statistiques en temps opportun (par exemple, en cas de défaillance temporaire du réseau). Par défaut, les daemons OSD signalent leurs statistiques de groupe de placement, de démarrage et d'échec toutes les demi-secondes (0,5), ce qui est plus fréquent que les seuils de pulsation. Si l'OSD primaire de l'ensemble agissant d'un groupe de placement ne parvient pas à rendre compte au moniteur ou si d'autres OSD ont signalé l'OSD primaire comme étant arrêté, les moniteurs marquent le groupe de placement comme obsolète (« stale »).

Lorsque vous démarrez votre grappe, il est courant de voir l'état « stale » tant que le processus d'homologation n'est pas terminé. En revanche, lorsque votre grappe est en cours d'exécution depuis un certain temps, si des groupes de placement sont dans l'état « stale », cela indique que l'OSD primaire pour ces groupes de placement est arrêté ou ne rend pas compte de ses statistiques de groupe de placement au moniteur.

12.9.5 Identification de l'emplacement d'un objet #

Pour stocker les données d'objet dans le magasin d'objets Ceph, un client Ceph doit définir un nom d'objet et spécifier une réserve associée. Le client Ceph récupère la dernière assignation de grappe et l'algorithme CRUSH calcule comment assigner l'objet à un groupe de placement, puis calcule comment assigner le groupe de placement à un OSD de façon dynamique. Pour trouver l'emplacement de l'objet, tout ce dont vous avez besoin est le nom de l'objet et le nom de la réserve. Par exemple :

cephuser@adm > ceph osd map POOL_NAME OBJECT_NAME [NAMESPACE]

Exemple 12.1 : localisation d'un objet #

À titre d'exemple, créons un objet. Spécifiez un nom d'objet « test-object-1 », un chemin vers un fichier d'exemple « testfile.txt » contenant certaines données d'objet et un nom de réserve « data » à l'aide de la commande rados put sur la ligne de commande :

cephuser@adm > rados put test-object-1 testfile.txt --pool=data

Pour vérifier que le magasin d'objets Ceph a stocké l'objet, exécutez la commande suivante :

cephuser@adm > rados -p data ls

Maintenant, identifiez l'emplacement de l'objet. Ceph renverra l'emplacement de l'objet :

cephuser@adm > ceph osd map data test-object-1
osdmap e537 pool 'data' (0) object 'test-object-1' -> pg 0.d1743484 \
(0.4) -> up ([1,0], p0) acting ([1,0], p0)

Pour supprimer l'exemple d'objet, il suffit de le supprimer à l'aide de la commande rados rm :

cephuser@adm > rados rm test-object-1 --pool=data