Un disque se remplace rarement en situation calme : il y a eu une alerte, un voyant, ou une lenteur inexpliquée. C'est exactement pour cette raison que la procédure doit être écrite à l'avance. Les deux erreurs qui coûtent cher sont toujours les mêmes : retirer le mauvais disque, et oublier que sur un disque système, remplacer le support ne suffit pas à rendre la machine capable de démarrer dessus.
Renseignez le disque concerné : les commandes de la page s'adaptent. L'identifiant de l'OSD, lui, se lit à l'étape 01, il change à chaque disque.
01Identifier le bon disque
Le nom de périphérique n'est pas une identité : il peut changer d'un démarrage à l'autre. La seule identité fiable est le numéro de série, et c'est lui qui doit être lu sur l'étiquette du disque avant de le sortir de la baie.
lsblk -o NAME,SIZE,MODEL,SERIAL,MOUNTPOINTS # identite stable, a privilegier dans toutes les commandes ls -l /dev/disk/by-id/ | grep nvme2n1 # etat de sante detaille smartctl -a /dev/nvme2n1
Si le disque appartient à un miroir ZFS
zpool status -v rpool # les membres sont listes par identifiant stable si le pool a ete cree ainsi zpool status -LP rpool
Si le disque porte un OSD Ceph
# ce que Ceph signale exactement ceph health detail ceph osd tree ceph osd df # latences par OSD : le meilleur indicateur precoce ceph osd perf # quel disque physique porte quel OSD, sur le noeud concerne ceph-volume lvm list
Avant toute extraction, relevez le numéro de série du disque visé et confrontez-le à celui inscrit sur le support. Retirer un disque sain d'un miroir déjà dégradé, ou un second OSD du même domaine de défaillance, transforme un incident en perte de données. Si le châssis le permet, allumez le voyant de localisation et vérifiez que c'est bien celui-là qui clignote.
# sur un fond de panier gere par un HBA compatible ledctl locate=/dev/nvme2n1 # extinction une fois le disque repere ledctl locate_off=/dev/nvme2n1
02Remplacer maintenant ou attendre
Tous les signaux ne se valent pas. Certains imposent une intervention immédiate, d'autres autorisent à planifier. Le tableau résume nos seuils de décision.
| Signal | Où le lire | Seuil | Décision |
|---|---|---|---|
| Secteurs réalloués | SMART | > 0 et en croissance | Remplacer sans attendre |
| Secteurs en attente | SMART | > 0 | Remplacer sans attendre |
| Usure d'un SSD | SMART, pourcentage utilisé | > 85 % | Planifier le remplacement |
| Erreurs de lecture ou d'écriture | zpool status | > 0 | Remplacer, vérifier le câblage |
| Erreurs de somme de contrôle | zpool status | > 0 | Souvent câble ou fond de panier |
| Latence de validation OSD | ceph osd perf | > 50 ms durablement | Remplacer, même sans erreur SMART |
| Réinitialisations du contrôleur | dmesg | Répétées | Disque ou emplacement défaillant |
| Durée de vie | Inventaire | > 5 ans | Renouvellement à budgéter |
Sur Ceph, un OSD dont la latence se dégrade pénalise l'ensemble du pool, parce que chaque
écriture attend ses répliques. Un disque qui ralentit progressivement sans jamais déclencher
d'erreur SMART est un cas fréquent, et c'est ceph osd perf qui le révèle,
plusieurs semaines avant la panne franche.
03Remplacer un disque d'un miroir ZFS
ZFS gère le remplacement à chaud sans interruption de service, à condition que le pool soit en miroir ou en RAIDZ. La seule subtilité concerne les disques système.
# etat avant intervention, a conserver zpool status -v rpool # mise hors service du membre defaillant zpool offline rpool /dev/disk/by-id/nvme-SAMSUNG_XXXX_S1234 # le pool passe en DEGRADED, le service continue zpool status rpool
Un disque système Proxmox VE porte trois partitions : amorçage BIOS, partition système EFI, et la partition ZFS. Remplacer le disque et laisser ZFS reconstruire ne recrée ni la table de partition, ni la partition EFI. La machine continue de fonctionner, et refuse de démarrer sur ce disque le jour où l'autre tombe. C'est l'erreur la plus répandue de toute cette procédure.
# 1. copier la table de partition depuis le disque sain, puis reattribuer les GUID sgdisk /dev/nvme0n1 -R /dev/nvme2n1 sgdisk -G /dev/nvme2n1 # 2. relever l'identifiant stable du disque neuf, partitions comprises ls -l /dev/disk/by-id/ | grep nvme2n1 # 3. rendre la partition ZFS au pool : la reconstruction demarre zpool replace rpool /dev/disk/by-id/ancien-id \ /dev/disk/by-id/nouveau-id-part3 # 4. recreer la partition de demarrage, l'etape que l'on oublie proxmox-boot-tool format /dev/disk/by-id/nouveau-id-part2 proxmox-boot-tool init /dev/disk/by-id/nouveau-id-part2 # 5. le nouveau disque doit apparaitre dans la liste des supports d'amorcage proxmox-boot-tool status
Le suffixe de partition n'est pas le même partout : la troisième partition de
nvme2n1 s'appelle nvme2n1p3, celle de sdf s'appelle
sdf3. Les chemins by-id suppriment ce piège avec un suffixe
-part3 uniforme, et ils ne changent pas d'un démarrage à l'autre.
C'est aussi sous cette forme que les membres du pool doivent être déclarés.
# rafraichissement toutes les secondes, avec la duree restante estimee zpool status rpool 1 # une fois ONLINE partout, remettre les compteurs d'erreurs a zero zpool clear rpool zpool status -v rpool
04Remplacer un OSD Ceph
La logique diffère : on ne répare pas un OSD, on le détruit et on en crée un neuf. Ceph se charge de replacer les données. Tout l'enjeu est de ne pas sortir un OSD alors que la redondance est déjà entamée ailleurs.
# l'OSD cesse de recevoir des donnees, le reequilibrage commence ceph osd out osd.5 watch ceph -s # ne rien detruire tant que la reponse n'est pas affirmative ceph osd safe-to-destroy osd.5 # arret du service puis destruction, avec nettoyage du disque systemctl stop ceph-osd@5 pveceph osd destroy 5 --cleanup 1
Inutile d'attendre un rééquilibrage à partir d'un disque qui ne répond plus : Ceph a déjà
commencé à reconstruire les copies manquantes depuis les autres exemplaires. Passez directement
à la destruction de l'OSD, puis au remplacement. Posez noout seulement si vous
devez éteindre le noeud entier pour l'intervention.
# le disque doit etre vu et vierge de toute trace precedente lsblk /dev/nvme2n1 ceph-volume lvm zap /dev/nvme2n1 --destroy # creation, le nouvel OSD reprend un identifiant libre pveceph osd create /dev/nvme2n1 # topologie et retour a l'equilibre ceph osd tree ceph osd df watch ceph -s
Sur les configurations où les métadonnées sont déportées sur un support rapide, la destruction doit libérer le volume logique correspondant, ce que fait l'option de nettoyage. Vérifiez-le avant de recréer l'OSD, faute de quoi l'espace reste réservé à un OSD qui n'existe plus, et il finira par manquer.
05L'intervention physique
- Vérifier le numéro de série une dernière fois, support en main.
- Extraire le disque, sur un châssis à échange à chaud. Sinon, migrer les
machines, arrêter le noeud, et poser
nooutsi Ceph est en jeu. - Insérer le disque neuf, de même classe et de capacité au moins égale.
- Confirmer la détection avant toute commande.
dmesg -T | tail -20 lsblk -o NAME,SIZE,MODEL,SERIAL # relever l'etat de sante initial, il servira de reference smartctl -a /dev/nvme2n1 | head -30
Si l'intervention a nécessité d'arrêter le noeud, ceph osd set noout a empêché
Ceph de reconstruire inutilement. Retirez-le dès le retour du noeud. Un noout
oublié donne un cluster d'apparence saine dans lequel aucun OSD défaillant ne sera plus
remplacé automatiquement.
06Après le remplacement
- Attendre le retour à l'état nominal avant de considérer l'intervention
terminée :
HEALTH_OKsur Ceph, poolONLINEsans erreur sur ZFS. - Conserver l'état SMART initial du disque neuf. Comparer dans six mois n'a de sens qu'avec un point de départ.
- Mettre à jour l'inventaire : emplacement, modèle, numéro de série, date de mise en service, date d'achat et garantie.
- Reconstituer le stock de rechange. Un disque de rechange par modèle et par site est le minimum ; sans lui, le délai de remplacement devient le délai du fournisseur.
- Regarder la tendance. Trois disques du même lot qui lâchent en six mois n'est pas une coïncidence, c'est un lot à remplacer entièrement.
Si personne n'a vu venir la panne, c'est que l'usure des supports et les compteurs SMART ne sont pas supervisés. Ces deux indicateurs se collectent simplement et transforment une intervention d'urgence en opération planifiée. Ils figurent au tableau des indicateurs du guide cluster.
07Liste de contrôle
| Étape | Action | Vérification |
|---|---|---|
| Avant | Numéro de série relevé et confronté au support | lsblk -o NAME,SERIAL |
| Avant | État de la redondance ailleurs sur la plateforme | Aucun autre support dégradé |
| Avant | Sauvegarde récente et vérifiée | Tâche de vérification réussie |
| ZFS | Disque mis hors service, puis échangé | Pool en DEGRADED, service rendu |
| ZFS | Table de partition recopiée, GUID réattribués | lsblk montre trois partitions |
| ZFS | Partition de démarrage recréée | proxmox-boot-tool status |
| ZFS | Reconstruction terminée, compteurs effacés | Pool ONLINE, zéro erreur |
| Ceph | OSD sorti, destruction autorisée | ceph osd safe-to-destroy |
| Ceph | Disque nettoyé puis OSD recréé | ceph osd tree |
| Ceph | Rééquilibrage terminé | HEALTH_OK |
| Après | Drapeaux de maintenance retirés | ceph osd stat |
| Après | Inventaire et stock de rechange à jour | Document d'exploitation |
Une plateforme Proxmox a exploiter sereinement
Nous exploitons des clusters Proxmox VE et Ceph en production pour des PME, des structures reglementees et des collectivites. Remplacement de noeud, montee de version, reprise d'une plateforme existante : nous intervenons au forfait comme en astreinte.