Outils pour utilisateurs
Panneau latéral
Table des matières
Remplacer un disque sur le cluster Ceph
Sur phobos, il n'est pas possible de changer un disque à chaud, il faut donc reboot et aller sur le contrôleur SATA du serveur (F10 au démarrage), ajouter un nouveau disque virtuel. Et voilà!!
disque signe de défaillances…. explications, etc
Pour des erreurs de lecture sur le disque vous allez probablement avoir des erreurs sur les placements groups, du type : scrub errors; Possible data damage: X pg inconsistent, que vous pourrez observer grâce à ceph status
Vous avez la documentation officielle de ceph sur le troubleshooting des pgs pour vous aider.
Normalement ce type d'erreur met votre cluster dans l'état HEALTH_ERR, donc vous êtes prévenus.
Pour connaître exactement le problème, vous pouvez utiliser ceph health status ou rados list-inconsistent-pg POOL_NAME. Je vous conseille le premier qui va vous montrer directement tous les placements groups affectés.
On regarde donc pour chaque pg quel est le problème grâce à
rados list-inconsistent-obj PG_ID --format=json-pretty
Si dans les champs errors vous voyiez read_errors, cela veut sans doute dire que l'un (ou plusieurs) des disques sur lesquels se trouve le placement group, commence à donner des signes de faiblesse.
Identifier le disque
Grâce à la commande qui liste les objets affectés vous remarquez sans doute qu'un seul (j'espère pour vous) des OSD est affectés.
Bon donc on a l'ID de l'OSD, maintenant il nous faut récupérer le disque correspondant, pour pouvoir tester le disque pour savoir si on le remplace ou non. Mais ce n'est pas avec un simple lsblk que vous allez pouvoir connaître le disque associé.
On identifie la machine qui possède l'OSD avec un simple ceph osd tree, puis on identifie le volume lvm associé grâce à ceph-volume lvm list (sur l'hôte concerné bien sur).
On a donc l'identifiant du volume logique grâce au champ block device.
Un petit lsblk avec l'aide de grep et le tour et joué. Attention vous remarquerez que les tirets sont doublés dans la sortie de lsblk pour identifier les volumes (sauf celui qui sépare le vg du lv dans le nom), donc vous aurez probablement à doubler les tirets dans le nom du volume logique, remplacer le / par un simple tiret.
Parce qu'on aime les one-liners (pas sur qu'il fonctionne encore dans quelques années), en voici un qui à partir de l'OSD vous donne le disque associé (remplacer X par l'ID de l'OSD):
lsblk | grep -B1 $(ceph-volume lvm list | grep -A14 osd.X | tail -n1 \ | cut -d'/' -f3,4 | sed 's/\-/\-\-/g' | tr '/' '-')
Tests sur le disque
Maintenant que le disque est identifié, il nous reste plus qu'à le tester et prendre une décision. Pour ça on utilise l'outil de référence : smartmontools. On peut déjà regarder l'état de santé du disque avec :
smartctl -H /dev/sdX
Puis tester le disque grâce à l'option -t. Je vous invite à regarder le manuel pour voir les différences entre les types de tests.
Le test de santé peut être PASS, bien que le disque cause des erreurs, et PASS ne veut pas forcément dire garder le disque.
Remplacer le disque
C'est bon, vous avez décidé de remplacer le disque.
Si vous vous fichez des données sur le(s) disque(s) (grâce à votre politique de réplication)
Vous pouvez directement suivre l'extrait de documentation “Remplacer un OSD” après avoir lu le reste mais en n'oubliant pas que si vous utilisez le cache de bluestore il faut préciser –block.db dans le prepare:
ceph-volume lvm prepare --osd-id {id} --data /dev/sdX --block.db /dev/sdY
La documentation officielle de ceph : ajouter/enlever des OSDs, et une page sur leur blog pour remplacer un disque défaillant, qui vous montre d'ailleurs que dans certains cas, Ceph lui-même va éteindre l'OSD quand le disque est défaillant.
Sinon
Vous pouvez directement suivre l'extrait de documentation “Remplacer un OSD” après avoir lu le reste :
La documentation officielle de ceph : ajouter/enlever des OSDs, et une page sur leur blog pour remplacer un disque défaillant, qui vous montre d'ailleurs que dans certains cas, Ceph lui-même va éteindre l'OSD quand le disque est défaillant.
Si vous avez absolument besoin de récupérer des données sur le(s) disque(s) (À MiNET si la réplication marche, on suit la partie précédente !!!)
Je répète : Si vous avez absolument besoin de récupérer des données sur le(s) disque(s)
On commence par sortir l'OSD du cluster :
ceph osd out osd.X
Il ne vous reste plus qu'à attendre que Ceph déplace les données dont il ne peut pas se passer si l'OSD est down : les PGs qui sont présents uniquement sur le disque vont être déplacés ailleurs. C'est ce qui arrive si vous n'avez pas de réplication ni de correction d'erreur (erasure code qui est l'équivalent du RAID5), vos données qui ne pourront être lues sur le disque seront perdues, il faudra alors évaluer les conséquences (refaire des machines virtuelles, re-télécharger du contenu,…)
Vous pouvez observez le déplacement des PGs avec
ceph -w
qui de manière générale vous affiche ce que fait le cluster lorsqu'il n'est pas dans l'état HEALTH_OK.
Dans le cas où des données sont introuvables, je vous conseille de vous référez à la documentation officielle : troubleshooting des pgs
Une fois que vous avez réussi à revenir dans un état correct, on stoppe l'OSD grâce à :
ceph osd down OSD_ID
On vérifie que le service est bien down :
ceph osd tree systemctl status ceph-osd@OSD_ID.service
Si ce n'est pas le cas, éteignez l'OSD avec systemd :
systemctl stop ceph-osd@OSD_ID.service
Ensuite on enlève l'OSD de la crushmap, pour que ceph déplace les objets qui étaient présents sur l'OSD ailleurs, grâce à la politique de réplication : les PGs présents sur le disque sont déplacés grâce aux réplicas.
ceph osd crush remove osd.OSD_ID
Encore une fois vous allez devoir attendre. Une fois que l'étape de récupération des données est terminée, vous pouvez supprimer les clés de l'OSD:
ceph auth del osd.OSD_ID
Puis le supprimer:
ceph osd rm osd.OSD_ID
Pour identifier le disque dans le serveur vous pouvez essayer de trouver le disque dont la LED reste éteinte, pour confirmer votre supposition vous pouvez utiliser : Attention à bien effectuer cette commande sur le disque que vous allez remplacer, sinon vous allez perdre des données.
dd if=/dev/zero of=/dev/sdX bs=1M
La LED devrait s'allumer en continu, et rester allumé après un Control-C, à cause du délai entre écriture demandée et écriture effectuée.
Vous pouvez maintenant retirer le disque et le remplacer.
Vous pouvez donc identifier le nouveau disque et recréer un OSD. Bien penser à spécifier la partition de cache si vous utiliser bluestore avec du cache. Vous pouvez l'identifier en cherchant celle qui manque dans :
ceph-volume lvm list
Si vous utilisez ceph-deploy merci de vous réferer au blog cité plus haut.
/dev/sdX : votre nouveau disque
/dev/sdY : votre cache utilisé pour cet OSD
ceph-volume lvm zap /dev/sdX ceph-volume lvm prepare --osd-id OSD_ID --data /dev/sdX --block.db /dev/sdY
Avec ceph-volume lvm list récupérer le FSID de l'OSD (osd fsid), si l'ID de l'OSD ne correspond pas à l'ancien idenfiant, ne l'activez surtout pas.
Sinon si tout s'est bien passé :
ceph-volume lvm activate ID FSID
Et voilà !
— Romain Cherré 2018/06/16 21:56
Outils de la page
