Perte d'accès à la baie : symptômes et reprise¶

Day 2 · ExploiterNiveau 3 · MaîtriserRunbookRédigé · à valider en lab

Quand la baie SAN ou le NAS ne répond plus, l'objectif est de qualifier vite (un chemin, un nœud ou tout le cluster), de ne rien aggraver, puis de relancer proprement les VM une fois l'accès rétabli. Une perte de stockage ne déclenche pas la haute disponibilité : HA réagit à la perte d'un nœud (Corosync), pas à celle d'un stockage. Les VM restent sur place, figées.

Qui exécute : client pour le diagnostic et l'ouverture du ticket (tous contrats) ; MSP pour la reprise en N2/N3.

Symptômes¶

Symptôme	Où le voir	Signification probable
VM figées, console qui ne répond plus	GUI, console noVNC	I/O en attente (`queue_if_no_path`)
Statut `io-error`	`qm status 101 --verbose` → `qmpstatus: io-error`	QEMU a mis la VM en pause sur erreur d'écriture
Stockage avec point d'interrogation gris	Arborescence GUI, sous chaque nœud	Stockage inactif sur ce nœud
`failed faulty` sur un ou tous les chemins	`multipath -ll`	Perte partielle ou totale des chemins
`I/O error`, `rejecting I/O to offline device`	`journalctl -k`	Le noyau ne joint plus le LUN
`nfs: server 10.20.0.20 not responding`	`journalctl -k`	NAS injoignable, montage `hard` en attente

Avant de toucher la prod

Ne redémarrez aucun nœud : un redémarrage ne rétablit pas la baie et ajoute un risque de quorum.
N'exécutez aucune commande de réparation (vgcfgrestore, pvcreate, fsck) sur le VG du SAN.
Ne forcez pas l'arrêt des VM tant que la cause n'est pas connue : avec des I/O en file d'attente, elles peuvent reprendre sans perte.
Le cluster est quorate : pvecm status → Quorate: Yes. Sinon, suivez d'abord RB-09.
Le ticket iTop P1 est ouvert dès que plusieurs nœuds sont touchés.

Étapes¶

1. Qualifier l'étendue¶

GUICLI

Datacenter → Summary : nœuds en ligne ? Datacenter → Storage : quels stockages sont inactifs, sur quels nœuds ?
Ouvrez chaque nœud → Syslog : recherchez I/O error, multipath, iscsid, nfs.
Notez les VM affichées avec un état anormal (en pause, io-error).

# sur chaque nœud
pvesm status
multipath -ll                         # SAN : état des chemins
iscsiadm -m session -P1 | grep -E "Target|State"   # iSCSI : sessions LOGGED_IN ?
findmnt -t nfs,nfs4                   # NFS
journalctl -k --since "-30min" | grep -iE "i/o error|offline|not responding|multipath"
for id in $(qm list | awk 'NR>1{print $1}'); do echo -n "$id "; qm status $id --verbose | grep qmpstatus; done

Constat	Cause probable	Suite
Un chemin `failed` sur un nœud, autres OK	Câble, port de switch, SFP, HBA	Ticket P3, intervention physique, pas d'impact VM
Tous les chemins `failed` sur un nœud	Carte, switch d'accès, IQN refusé	Ticket P2, migrer les VM qui répondent encore depuis les autres nœuds si possible
Tous les chemins `failed` sur tous les nœuds	Baie, contrôleurs, cœur de réseau de stockage	Ticket P1, appel au support du constructeur de la baie
NFS `not responding` partout	NAS ou réseau de stockage	Ticket P1 si disques de VM dessus, P3 si ISO seulement

2. Stabiliser¶

Laissez les VM figées en l'état : avec queue_if_no_path ou un montage NFS hard, les écritures reprendront au retour de la baie.
Suspendez les tâches planifiées qui solliciteraient le stockage (sauvegardes en cours, réplications) : Datacenter → Backup → désactiver le job temporairement.
Ne modifiez pas /etc/multipath.conf ni les sessions iSCSI pendant l'incident.

3. Reprendre après retour de la baie¶

GUICLI

Vérifiez que le stockage repasse actif sous chaque nœud (rafraîchir l'arborescence).
Pour chaque VM en pause : VM → Resume. Si la VM ne repart pas : Shutdown, puis Stop en dernier recours, et Start.
Ouvrez la console de chaque VM et vérifiez les journaux de l'OS invité.

iscsiadm -m node --login            # iSCSI : relance les sessions absentes (sans effet sur les sessions actives)
multipath -r && multipath -ll       # tous les chemins active ready running
pvscan --cache && vgs vg_san        # VG visible
pvesm status                        # san-lvm active
qm resume 101                       # VM en io-error ou en pause
qm status 101 --verbose | grep qmpstatus    # attendu : running

Redémarrez ensuite les VM par ordre de dépendance (annuaire, bases de données, applications).

Vérifications

multipath -ll : tous les chemins active ready running sur chaque nœud. pvesm status : tous les stockages active. qm list : VM running ; qmpstatus: running. Dans les VM : aucune erreur de système de fichiers (dmesg sous Linux, observateur d'événements sous Windows). Lancez une sauvegarde PBS manuelle des VM critiques vers pbs-local.

Rollback

Ce runbook ne modifie pas la configuration : rien à annuler. Si une VM présente une corruption après reprise, restaurez-la depuis PBS avec RB-12, sur un autre stockage (local ou Ceph) si la baie reste suspecte.

Pièges vus en support

Redémarrer tous les nœuds « pour débloquer » : les VM ne démarrent pas sans baie, et le cluster perd son quorum pendant la manœuvre.
qm stop en boucle sur des VM en I/O bloquées : processus QEMU en état D impossible à tuer, nœud à redémarrer ensuite.
Lancer vgcfgrestore ou recréer le PV « parce que le VG a disparu » : le VG revient seul avec la baie. Ces commandes écrasent les métadonnées.
Baie revenue mais un nœud garde une session iSCSI morte : stockage actif sur deux nœuds, inactif sur le troisième. Vérifiez chaque nœud.
Snapshot de LUN restauré côté baie pendant que le cluster tourne : incohérence des métadonnées LVM, perte de données.

Quand ouvrir un ticket iTop

Dès que des disques de VM sont inaccessibles sur plusieurs nœuds : P1, immédiatement, en parallèle de l'appel au constructeur. Un seul nœud : P2. Un seul chemin : P3. Joindre la sortie de pvesm status, multipath -ll, iscsiadm -m session -P1 et journalctl -k --since "-1h" de chaque nœud, la liste des VM figées, l'heure du début de l'incident. Voir Sévérité.

Ouvrir un ticket iTop