Aller au contenu

Diagnostic par symptôme : VM lente, nœud grisé, backup en échec

Day 2 · ExploiterNiveau 2 · OpérerArbre de décisionRédigé · à valider en lab

Partez de ce que vous voyez, suivez l'arbre jusqu'à une cause probable, puis appliquez le runbook indiqué. En moins de 10 minutes, vous savez si vous traitez seul ou si vous ouvrez un ticket, et avec quelle sévérité.

Trois réflexes avant tout diagnostic

  1. Périmètre : une VM, un nœud, ou tout le cluster ? Un problème qui touche tout le monde en même temps est presque toujours réseau ou stockage partagé.
  2. Chronologie : qu'est-ce qui a changé ? Mise à jour, sauvegarde en cours, migration, disque ajouté, intervention réseau.
  3. Lecture seule d'abord : pvecm status, ceph -s ou zpool status -x, pvesm status. Aucune action corrective avant d'avoir une hypothèse. Méthode de lecture : Lire les logs.

Arbre de décision

flowchart TD
    S["Quel symptome ?"] --> A["Noeud grise ou croix rouge"]
    S --> B["VM lente ou figee"]
    S --> C["Sauvegarde en echec"]
    S --> D["Action impossible sur une VM"]

    A --> A1{"pvecm status : Quorate Yes ?"}
    A1 -- "Non" --> RB09Q["RB-09 cas 3 : perte de quorum, ticket P1"]
    A1 -- "Oui" --> A2{"Noeud joignable en SSH ?"}
    A2 -- "Non" --> RB09H["RB-09 cas 2 : noeud hors ligne"]
    A2 -- "Oui" --> RB09G["RB-09 cas 1 : pvestatd, stockage injoignable"]

    B --> B1{"Toutes les VM du noeud ou du cluster ?"}
    B1 -- "Oui" --> B2{"ceph -s ou zpool status sain ?"}
    B2 -- "Non" --> STO["RB-01, RB-04, RB-07 selon l'alerte"]
    B2 -- "Oui" --> B3["Noeud sature : CPU, RAM, swap, ARC"]
    B1 -- "Non, une seule" --> B4{"Verrou ou tache en cours ?"}
    B4 -- "Oui" --> RB10["RB-10 VM verrouillee"]
    B4 -- "Non" --> B5["Ressources de la VM, agent, pilotes VirtIO"]

    C --> C1{"Stockage PBS actif dans pvesm status ?"}
    C1 -- "Non" --> C2["Reseau, certificat, jeton : RB-14"]
    C1 -- "Oui" --> C3["Lire le log vzdump : RB-14"]

    D --> D1{"Cadenas sur la VM ?"}
    D1 -- "Oui" --> RB10
    D1 -- "Non" --> A1

Tableau symptôme → cause → action → runbook

Symptôme Cause probable Vérification / action Runbook
Nœud et VMs avec un point d'interrogation gris pvestatd bloqué par un stockage NFS/CIFS injoignable pvesm status, puis systemctl restart pvestatd (sans impact sur les VMs) RB-09 cas 1
Nœud avec une croix rouge Nœud éteint, planté ou coupé du réseau Corosync Console IPMI, pvecm status depuis un nœud sain RB-09 cas 2
Configuration en lecture seule, « cluster not ready - no quorum? » Perte de quorum pvecm status, journalctl -u corosync -n 200 ; jamais pvecm expected 1 seul RB-09 cas 3
Nœud redémarré seul, VMs HA relancées ailleurs Fencing HA après perte du réseau Corosync journalctl -b -1 -e, ha-manager status RB-09
Toutes les VMs lentes, Ceph en WARN Reconstruction en cours (backfill, recovery) ou OSD lent ceph -s, ceph health detail, ceph osd perf RB-01
VMs figées, écritures bloquées OSD full (95 %) ceph osd df tree ; ticket P1 RB-04
VMs lentes sur un nœud ZFS Pool dégradé, resilver ou scrub en cours, pool plein au-delà de 80 % zpool status -x, zpool list, zpool iostat -v 5 RB-07
VMs lentes, IO delay élevé (nœud → Summary) Disque lent ou en fin de vie, contrôleur en erreur journalctl -k --grep timeout, smartctl -a RB-05 / RB-03
Nœud lent, swap utilisé RAM surallouée, ARC ZFS trop gros free -h, arc_summary -s arc Plan de capacité
Une VM lente, les autres normales vCPU ou RAM insuffisants, pas de VirtIO, pas de discard, snapshot ancien VM → Summary, qm config 101, VM → Snapshots Créer une VM optimisée
VMs lentes toutes les nuits Fenêtre de sauvegarde, de scrub ou de GC PBS Comparer avec les horaires des jobs RB-14 (ordre des tâches)
VM avec un cadenas, impossible à arrêter Verrou backup, migrate, snapshot qm config 101 (ligne lock:), tâches en cours RB-10
Sauvegarde en échec : « fingerprint does not match » Certificat PBS renouvelé Mettre à jour l'empreinte du stockage pbs-local RB-14
Sauvegarde en échec : « no space left » Datastore plein, GC non planifiée PBS → Datastore → Summary, Prune & GC RB-14
Sauvegarde en échec : « guest-fsfreeze-freeze failed » Agent invité absent ou bloqué qm guest cmd 101 ping, service de l'agent dans la VM RB-14
Copie MSP en retard de plus de 24 h Lien, pare-feu, jeton, quota PBS → Sync Jobs → log RB-15
Réplication ZFS en erreur Pool cible plein, snapshot commun perdu, SSH pvesr status, pvesr run --id 101-0 --verbose RB-11
Plusieurs nœuds perdent la baie en même temps Chemins multipath ou réseau de stockage multipath -ll, pvesm status Perte d'accès à la baie
GUI inaccessible, SSH OK pveproxy arrêté, certificat invalide, disque système plein systemctl status pveproxy, df -h / Lire les logs

Recommandations MSP

  • Le client traite seul : nœud grisé (cas 1), VM verrouillée, sauvegarde en échec simple, VM isolée lente.
  • Le client ouvre un ticket immédiatement : perte de quorum, Ceph en HEALTH_ERR ou full, pool ZFS SUSPENDED, plusieurs nœuds touchés.
  • Ne changez jamais plusieurs choses à la fois : un changement, une vérification.

Pièges vus en support

  • Redémarrer un nœud « pour voir » pendant un incident Ceph ou Corosync : on transforme une alerte en panne.
  • Lancer ceph osd out, zpool clear ou qm unlock pour faire disparaître le symptôme sans en connaître la cause.
  • Diagnostiquer une lenteur la nuit sans regarder les horaires de sauvegarde, de scrub et de GC.
  • Démarrer à la main une VM HA sur un autre nœud pendant un fencing : risque de VM lancée deux fois.

Quand ouvrir un ticket iTop

Dès que l'arbre mène à un ticket, ou après 30 minutes sans hypothèse claire. Sévérité selon la grille ; joindre pvecm status, ceph -s ou zpool status -v, pveversion -v et l'heure de début du symptôme.

Ouvrir un ticket iTop

Pour aller plus loin