Migration urgence vers RAID 1 SSD : sauver un lab du disque mourant

Mise à jour : avril 2026

Récit d'un week-end de migration en urgence, du diagnostic SMART au monitoring Zabbix, en passant par un cluster Kubernetes au bord de l'asphyxie et un snapshot VMware oublié pendant 10 mois.

Le contexte : un lab en production réelle

Mon home lab héberge Avuru Vision, la plateforme fintech sur laquelle je développe au quotidien, ainsi qu'une partie des services critiques de la maison. Concrètement, sur un Dell PowerEdge T350 :

• Un cluster Kubernetes DEV à 6 nœuds (3 control planes + 3 workers)
• Une base PostgreSQL 18 hébergeant 18 bases (Zabbix, Keycloak, PowerDNS, Graylog…)
• La VM DevOps : GitLab self-hosted, Harbor registry, Nexus, Jenkins
• La VM management : OpenLDAP, PowerDNS, ModSecurity, Wazuh manager
• L'observabilité : Graylog, ELK (Elasticsearch + Kibana), Jaeger, Kiali

Bref, du sérieux. Quand un disque commence à crier, ce n'est pas une option de remettre ça à la semaine prochaine.

Un home lab qui héberge ta plateforme de développement, ton blog et les services de ta famille n'est plus un home lab. C'est de la production. Avec ses contraintes.

Les premiers symptômes : un cluster qui suffoque

Avant même que SMART ne tire la sonnette d'alarme, c'est Kubernetes qui a commencé à tousser. Petit échantillon des messages d'erreur que je voyais passer plusieurs fois par heure :

$ kubectl get pods -A
E0413 21:10:38.675 4010079 memcache.go:265] "Unhandled Error" \
  err="couldn't get current server API group list: \
  Get \"https://10.0.0.56:8443/api?timeout=32s\": \
  dial tcp 10.0.0.56:8443: connect: connection refused"

The connection to the server 10.0.0.56:8443 was refused

L'API server qui refuse les connexions. Puis qui revient. Puis qui re-timeout. Le pattern classique d'un etcd qui n'arrive plus à fsync à temps : chaque écriture etcd doit être persistée sur disque avant d'être acquittée, et avec des centaines de millisecondes de latence I/O sur un HDD agonisant, les leases expirent et le cluster se met à élire de nouveaux leaders en boucle.

etcd est implacable avec son storage. Sa garantie de cohérence repose sur des fsync synchrones. Sur un disque sain, c'est invisible. Sur un disque qui retry sa lecture 30 fois avant de répondre, c'est un déni de service distribué.

Le rôle inattendu d'Elasticsearch

En investiguant les logs vmkernel, je remarque qu'une grosse partie de l'I/O writes vient d'Elasticsearch. Et là, double erreur architecturale qui me sautait aux yeux :

1. ELK tournait sur le datastore qui héberge les workers Kubernetes, donc ses indexations massives consommaient le même I/O que la DB etcd
2. Elasticsearch sur un HDD mécanique est un anti-pattern documenté depuis longtemps : les segments Lucene, les translogs, les merges de shards génèrent un profil d'I/O aléatoire que les SSD avalent sans broncher mais que les HDD subissent

Décision pragmatique : arrêter le stack ELK le temps de la migration.

## Sur le cluster K8s
kubectl scale deployment -n logging elasticsearch --replicas=0
kubectl scale deployment -n logging logstash --replicas=0
kubectl scale deployment -n logging kibana --replicas=0
kubectl scale daemonset -n logging filebeat --replicas=0

L'effet a été immédiat. En 5 minutes, la latence I/O du datastore est descendue de 300+ ms à 40 ms. Les pods Kubernetes ont arrêté de redémarrer en boucle. kubectl est redevenu utilisable. Le cluster pouvait respirer.

C'est à ce moment-là que j'ai pu poser un diagnostic propre et planifier la migration sereinement, plutôt que de courir après les fires.

Quand ton cluster suffoque, le réflexe est de chercher quoi débrancher en priorité. L'observabilité est paradoxalement une excellente candidate : tu en as moins besoin pendant les 4 heures de migration que pendant les 4 mois qui suivent.

Le diagnostic SMART : 1,7 milliard d'erreurs de lecture

Une fois la pression I/O retombée, je peux enfin lancer un diagnostic complet. Et là, c'est sans appel :

[root@hpesxi01:~] esxcli storage core device stats get -d naa.5000c50083cf2aab
   Device: naa.5000c50083cf2aab
   Successful Commands: 8 947 219 003
   Blocks Read: 12 458 991 234
   Blocks Written: 4 829 119 882
   Read Operations Failed: 1 700 529 214   ← !!
   Write Operations Failed: 24

1 milliard 700 millions d'erreurs de lecture. Le second disque Seagate (naa.5000c50083d15ab7) est plus calme avec « seulement » 363 millions d'erreurs read, mais c'est déjà 5 ordres de grandeur au-dessus du normal.

Le cf2aab héberge :

• datastore-dev : 7 VMs Kubernetes DEV (control planes + workers, etcd inclus)
• datastore-db : la VM PostgreSQL avec ses 18 bases

Le d15ab7 (le moins pire) héberge :

• datastore-mgnt : VM management + monitoring + Wazuh + Elasticsearch
• datastore-devops : VM avec GitLab, Harbor, Nexus, Jenkins

Pas de panique. Mais pas de procrastination non plus. Ces disques peuvent lâcher dans l'heure ou tenir trois mois. Personne ne le sait. Y compris SMART, qui les marquait toujours OK malgré ces compteurs.

La stratégie : RAID 1 SSD hardware via PERC

Le T350 supporte 4 baies hot-swap derrière un contrôleur Dell PERC H345 (compatible iDRAC9). Plan en 4 phases :

1. Hot-plug de 2 SSD SATA Micron 5300 PRO 1.92 TB
2. RAID 1 hardware créé via iDRAC (Write Through, pas de BBWC)
3. Migration thin des VMs critiques vers le nouveau datastore
4. Decommission progressif des disques mourants

Pourquoi Micron 5300 PRO et pas du grand public

Trois raisons techniques qui justifient l'écart de prix avec un Samsung EVO :

Sans PLP, le contrôleur RAID en mode Write Through (notre cas, vu qu'on n'a pas de BBWC sur le PERC H345) impose un fsync synchrone systématique. Avec PLP, le SSD peut acquitter l'écriture dès que c'est en cache local, le condensateur garantit la persistance même en cas de coupure brutale. Différence de perfs : 3 à 5× sur les workloads OLTP (PostgreSQL, etcd).

Pour un datastore qui héberge ta DB de prod, ton etcd Kubernetes et tes dépôts Git, le Power Loss Protection n'est pas une option. C'est la différence entre un disque enterprise et un disque de gamer.

Architecture cible

La méthode : vmkfstools thin clone

VMware fournit vmkfstools qui sait cloner un VMDK d'un datastore à un autre, avec conversion vers thin provisioning à la volée. La syntaxe est élégante :

vmkfstools -i /vmfs/volumes/datastore-dev/vm_dev_cp/vm_dev_cp.vmdk \
           -d thin \
           /vmfs/volumes/ssd-raid1-primary/vm_dev_cp/vm_dev_cp.vmdk

L'outil lit chaque bloc, ignore les zones allouées-mais-vides (les fameux "zero blocks"), et n'écrit que le contenu réel sur le SSD cible. Le gain est spectaculaire : sur mes 10 VMs, je suis passé de 5 TB provisionnés à environ 1 TB de données réelles. Soit -80 %.

Procédure type pour chaque VM

## 1. Shutdown gracieux
vim-cmd vmsvc/power.shutdown <VMID>
sleep 60

## 2. Préparer la cible + clone thin (en background)
mkdir -p /vmfs/volumes/ssd-raid1-primary/<vm_name>
nohup vmkfstools \
  -i /vmfs/volumes/<source>/<vm>/<vm>.vmdk \
  -d thin \
  /vmfs/volumes/ssd-raid1-primary/<vm>/<vm>.vmdk \
  > /tmp/clone-<vm>.log 2>&1 &

## 3. Copy des fichiers de config (.vmx, .nvram, .vmxf, .vmsd)
cp /vmfs/volumes/<source>/<vm>/<vm>.{vmx,nvram,vmxf,vmsd} \
   /vmfs/volumes/ssd-raid1-primary/<vm>/

## 4. Unregister l'ancien, register le nouveau
vim-cmd vmsvc/unregister <OLD_VMID>
NEW_VMID=$(vim-cmd solo/registervm /vmfs/volumes/ssd-raid1-primary/<vm>/<vm>.vmx)
vim-cmd vmsvc/power.on $NEW_VMID

## 5. Répondre "I Moved It" au prompt VMware (pour préserver MAC/UUID)
vim-cmd vmsvc/message $NEW_VMID

Avec un peu de discipline et des terminaux SSH parallèles, j'ai pu lancer 3 clones simultanés sur les workers Kubernetes (vm_dev_1, vm_dev_2, vm_dev_3 partagent le datastore source mais écrivent tous sur le SSD cible, sans contention).

Le piège que je ne voyais pas venir : un snapshot de 10 mois

Tout va bien jusqu'à vm_devops. Cette VM héberge mon stack DevOps (GitLab, Harbor, Nexus, Jenkins), et au moment de lancer le clone, je découvre :

[root@hpesxi01:~] ls -la /vmfs/volumes/datastore-devops/vm_devops/*.vmdk
-rw-------    1 root     root     271 882 551 296 Apr 20 18:39 vm_devops-000001-sesparse.vmdk
-rw-------    1 root     root              370 Apr 20 08:38 vm_devops-000001.vmdk
-rw-------    1 root     root   1 099 511 627 776 Apr 20 18:39 vm_devops-flat.vmdk
-rw-------    1 root     root              507 Apr 20 16:30 vm_devops.vmdk

Un snapshot. Du 16 juin 2025. Soit 10 mois d'écritures différentielles accumulées dans le sesparse.vmdk, qui pèse maintenant 272 GB.

Les snapshots VMware ne sont pas faits pour être conservés. Ils sont faits pour être pris avant un changement risqué, et supprimés dès que ce changement est validé. Au-delà de 48-72h, ils deviennent un risque opérationnel.

J'ai d'abord tenté la voie classique : consolidation du snapshot. ESXi commence à fusionner le delta dans le base disk… puis ralentit. Ralentit encore. Estimation après 1h : 24 à 33 heures pour finir, à 2.4 MB/s de débit. Le d15ab7, vieillissant, n'arrive plus à suivre.

Le pivot stratégique

Plutôt que d'attendre, j'ai fait un demi-tour à 180° : clone direct du snapshot enfant vers le SSD.

## Au lieu de cloner le base, on clone le sesparse. vmkfstools va
## automatiquement résoudre la chaîne et produire un VMDK consolidé sur la cible
nohup vmkfstools \
  -i /vmfs/volumes/datastore-devops/vm_devops/vm_devops-000001.vmdk \
  -d thin \
  /vmfs/volumes/ssd-raid1-primary/vm_devops/vm_devops.vmdk \
  > /tmp/clone-vm_devops-v2.log 2>&1 &

Le SSD encaisse l'écriture à pleine vitesse. 45 minutes plus tard, c'est terminé. La consolidation virtuelle a été faite à la volée, mais cette fois en lisant un disque mourant et en écrivant sur un disque rapide. Pas l'inverse.

Mais avant ça, il a fallu annuler la consolidation en cours (qui tenait toujours les locks VMFS), via un cancel puis un /etc/init.d/hostd restart pour libérer les handles. Pas glorieux. Mais efficace.

Petite correction post-clone

Le clone direct depuis un snapshot enfant produit un fichier vm_devops.vmdk propre, mais le .vmx source contient encore une référence à vm_devops-000001.vmdk (le snapshot qui n'existe plus côté SSD). Petit sed :

sed -i 's|vm_devops-000001\.vmdk|vm_devops.vmdk|g' \
  /vmfs/volumes/ssd-raid1-primary/vm_devops/vm_devops.vmx

## Et nettoyage du .vmsd (snapshot descriptor)
cat > /vmfs/volumes/ssd-raid1-primary/vm_devops/vm_devops.vmsd << 'EOF'
.encoding = "UTF-8"
EOF

vm_mgnt avait aussi un snapshot oublié (49 GB, plus modeste). Même méthode, même correction. Fini en 20 minutes.

Le bonus : DNS récursif récalcitrant

Une fois toutes les VMs redémarrées sur le SSD, je teste depuis un control plane Kubernetes :

root@vmdevcp:~# ping ghost.svc.cms.k8s.lab
ping: ghost.svc.cms.k8s.lab: Temporary failure in name resolution

root@vmdevcp:~# dig ghost.svc.cms.k8s.lab @10.0.0.35
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

SERVFAIL. Pourtant graylog.monitor.lab se résout sans souci. Et la zone k8s.lab existe bien dans PowerDNS, vérifié avec pdnsutil list-zone k8s.lab qui me montre les wildcards *.svc.cms.k8s.lab → 10.0.0.56.

Diagnostic en deux temps :

## Test direct sur l'authoritative (port 5300 local)
$ dig @127.0.0.1 -p 5300 ghost.svc.cms.k8s.lab
;; ANSWER SECTION:
ghost.svc.cms.k8s.lab. 3600 IN A 10.0.0.56  ✅

## Via le recursor (port 53 public)
$ dig @10.0.0.35 ghost.svc.cms.k8s.lab
;; status: SERVFAIL  ❌

L'authoritative répond. Le recursor non. Pourtant la zone k8s.lab est bien dans /etc/powerdns/internal-zones.conf du recursor.

Cache négatif persistant. Le recursor avait, juste après le redémarrage de la VM, mémorisé un SERVFAIL (la zone n'était pas encore montée à 100%). Et il continue à le retourner depuis sa cache.

Solution :

sudo systemctl restart pdns-recursor
sudo rec_control wipe-cache ghost.svc.cms.k8s.lab$
sudo rec_control wipe-cache k8s.lab$

15 secondes de fix. 45 minutes de diagnostic. La leçon est dans le ratio.

La cerise : monitoring Zabbix VMware

Pour éviter de revivre ça, j'ai installé le monitoring Zabbix-VMware. Trois trucs à savoir si tu attaques le sujet.

1. SNMP ne suffit pas pour les datastores

L'ESXi expose du SNMP (CPU, mémoire, VMs en cours), mais les datastores VMFS n'ont pas d'OID standard. Pour avoir l'usage d'un datastore par % en temps réel, il faut passer par le VMware SDK (template VMware Hypervisor de Zabbix).

2. La macro {$VMWARE.URL} veut un FQDN qui résout

Ce qui m'a coûté 30 minutes de debug. Si tu mets https://10.0.0.100/sdk, l'UI Zabbix peut refuser la valeur avec un "Unexpected server error" (j'ai eu ce comportement en Zabbix 7.0.18). Avec un FQDN qui résout vraiment dans le DNS interne, ça passe :

{$VMWARE.URL}      = https://hpesxi01.device.lab/sdk
{$VMWARE.USERNAME} = zabbix
{$VMWARE.PASSWORD} = ******** (Secret text)

Et côté ESXi, il faut créer un user read-only :

esxcli system account add -i zabbix -p '<password>' -c '<password>' -d "Zabbix monitoring"
esxcli system permission set -i zabbix -r ReadOnly

3. Activer les VMware collectors côté Zabbix server

## /etc/zabbix/zabbix_server.conf
StartVMwareCollectors=2
VMwareFrequency=60
VMwarePerfFrequency=60
VMwareCacheSize=32M
VMwareTimeout=10

Sans ces lignes, le template peut être attaché au host, les macros peuvent être correctes, rien ne sera collecté. Pas d'erreur explicite, juste du No data partout.

Le résultat

Une fois branché, le dashboard remonte en temps réel l'usage de chaque datastore :

Avec des triggers auto-générés à 80 % et 90 % d'utilisation. J'ai abaissé à 70 % / 85 % / 92 % via les macros {$VMWARE.HV.DATASTORE.SPACE.WARN} et .CRIT, pour avoir une marge plus confortable avant de devoir agir.

Bilan chiffré

Les leçons que je garde

1. SMART est en retard sur la réalité

Mes deux disques étaient marqués OK par ESXi. Pourtant l'un avait 1.7 milliards d'erreurs read. Le statut SMART est un seuil, pas un indicateur de santé. Les compteurs cumulés (read errors, reallocated sectors, pending sectors) sont beaucoup plus parlants. Mon prochain réflexe : un trigger Zabbix sur system.hw.diskstats[*,read.fails] au-delà de quelques milliers.

2. etcd et Elasticsearch n'ont rien à faire sur du HDD mécanique

C'est la leçon la plus structurelle de toute cette opération. Ces deux composants ont des profils d'I/O incompatibles avec du stockage mécanique en production :

• etcd fait du fsync synchrone à chaque écriture. Sa garantie de cohérence en dépend. Sur HDD, chaque fsync coûte 5 à 15 ms au mieux. Sur HDD vieillissant qui retry ses lectures, ça peut grimper à 100+ ms, et là, les leases expirent, les leaders changent, le cluster se déstabilise.
• Elasticsearch combine writes séquentiels (translogs), writes aléatoires (segment merges), et lectures aléatoires (recherches). Le profil est l'opposé exact de ce que les HDD savent bien faire (lecture séquentielle).

Si vous avez un HDD dans votre lab, demandez-vous : est-ce que je vais y mettre etcd, Elasticsearch, ou une base relationnelle avec des transactions à haute fréquence ? Si oui, stop. Ces workloads veulent du SSD, et idéalement du SSD avec PLP.

3. L'observabilité est un excellent candidat pour un arrêt temporaire

Quand ton infra suffoque sous l'I/O, le réflexe est de chercher quoi débrancher. Elasticsearch a été ma bouée de sauvetage. L'arrêter pendant les 15h de migration a permis au reste de respirer. Pendant cette fenêtre, j'ai perdu la collecte des logs centralisés. Mais j'ai gagné un cluster Kubernetes opérationnel et la possibilité de faire mon travail de migration proprement. Le bon trade-off n'est pas toujours évident dans la panique, mais il est presque toujours sacrifier l'observabilité avant de sacrifier la production.

4. Les snapshots VMware ont une durée de vie courte

Personne ne devrait avoir un snapshot de 10 mois sur une VM en production. C'est un piège silencieux : ça marche jusqu'au jour où tu dois le consolider, et là tu découvres que tu joues à la roulette russe avec ton I/O.

Ma règle désormais : un cron qui scan les datastores chaque jour et alerte par mail si un fichier *-sesparse.vmdk ou *-delta.vmdk est plus vieux que 48 heures.

5. Un plan B en cours d'exécution sauve la mise

Quand la consolidation vm_devops est partie pour 30 heures, j'aurais pu attendre. J'ai préféré annuler et basculer sur le clone direct. Le coût d'un changement de méthode en cours de route est presque toujours inférieur au coût de continuer dans une mauvaise direction.

6. Le filet de sécurité a son prix, mais pas tant que ça

J'ai gardé le disque cf2aab physiquement présent (juste détaché logiquement) pendant 7 jours après la migration. Coût : 8W de consommation et un slot occupé. Bénéfice : la possibilité de remonter les datastores originaux en 30 secondes si un cas inattendu se présentait. Excellent ratio.

7. Le DNS récursif est traître après un reboot

Le cache négatif est l'angle mort des admins. Si tu redémarres une VM qui héberge des services, et que tes clients DNS interrogent un recursor pendant ce démarrage, tu peux te retrouver avec des SERVFAIL cachés pendant des heures alors que tout est rentré dans l'ordre côté authoritative. Le wipe-cache après chaque manip de service mérite d'être réflexe.

Architecture finale

Et bien sûr, Elasticsearch est revenu, mais il a maintenant ses indices stockés sur le SSD, pas sur le HDD.

Ce qui reste à faire

Je m'inflige une discipline progressive sur ce qui suit :

• J+7 (semaine du 28 avril) : retirer physiquement le cf2aab du chassis
• Dans le mois : mettre en place les alertes Discord sur les triggers Free space critical
• Dans le trimestre : décider du sort de d15ab7. Soit le remplacer par un 3ème SSD (vers du RAID 10), soit l'utiliser uniquement pour des VMs sacrifiables et des templates
• À fixer : le cron snapshot-watchdog mentionné plus haut
• Architecture log : revoir le déploiement Elasticsearch pour qu'il utilise des PVCs explicitement liés à la storage class SSD, et ne puisse plus jamais retomber sur un HDD par défaut

Une bonne crise infrastructure laisse derrière elle plus de discipline et plus d'observabilité qu'avant. Sinon c'est qu'on n'en a pas tiré les leçons.

Pour aller plus loin

Si vous montez votre lab ou arrivez sur du matériel similaire, voici les ressources que j'aurais aimé avoir avant cette opération :

• VMware KB sur la consolidation des snapshots : utile pour comprendre quand un snapshot devient impossible à consolider sans I/O acceptable
• Documentation vmkfstools : la commande est sous-documentée mais c'est l'outil le plus puissant pour bouger des VMDK
• Template Zabbix VMware Hypervisor : disponible nativement depuis Zabbix 5.x, parfait pour ESXi standalone
• etcd hardware recommendations : la doc officielle ne mâche pas ses mots sur le besoin de SSD

Synthèse

Ce que j'ai voulu partager dans cet article, ce n'est pas tellement la procédure technique (vmkfstools -i ... -d thin, n'importe qui peut la trouver), mais le raisonnement derrière les décisions. Quand est-ce qu'on consolide vs qu'on clone direct ? Quand est-ce qu'on arrête un service pour soulager le système vs qu'on le laisse tourner ? Quand est-ce qu'on retire le disque vs qu'on le garde en filet ? Comment on évite de transformer une opération de 4 heures en marathon de 30 heures.

Mon home lab tourne maintenant sur un stockage redondé, thin-provisioned, supervisé. Les disques mourants sont sortis du circuit. etcd et Elasticsearch sont sur le SSD, où ils auraient toujours dû être. Et j'ai matière pour deux articles supplémentaires.

Prochaine partie → Stratégie de monitoring proactif : Zabbix triggers personnalisés pour anticiper les pannes hardware

Cet article a été rédigé pendant et après l'opération, sur un cluster qui tournait pendant que j'écrivais. C'est l'essence du Forgé au lab : si l'article existe, c'est que l'infra a survécu.