Bonsoir, Pour bien finir la semaine, j'ai un hyperviseur utilisant LVM en temps que storage backend (avec une petite couche de DRBD dessus) qui semble totalement blocké.
Précisons que les VMs écrivent et lisent correctement leurs disques.
En revanche, le DRBD ne veut plus rien savoir. Il fait encore sa synchro don je n'ai pas perdu de redondance mais il reste dans un état disons 'incertain'.
Ce qui me gonfle, c'est que je n'ai AUCUN message d'erreur kernel.
En revanche, en terme de symptômes, je n'ai aucun retour de pvdisplay, lvdisplay, vgdisplay ou lvs.
Lorsque je lance la commande, elle attend indéfiniment sans retourner quoi que ce soit. Un ctrl-c ne rend pas la main, un kill ou même kill -9 non plus.
Il semblerait donc qu'un 'truc' dans LVM ai prit la main et refuse de la rendre. Ca ressemble à du lock timeout.
Quelqu'un a déjà eu des symptômes similaires ? Voir une solution ? A priori, un reboot réglerait mon soucis mais c'est un hyperviseur. Et justement, la live migration ne fonctionne plus à cause de ça (ce qui est le fond du problème justement).
Merci et bon week-end, Julien
Le Fri, May 05, 2017 at 04:55:16PM +0200, Julien Escario [escario@azylog.net] a écrit: [...]
En revanche, en terme de symptômes, je n'ai aucun retour de pvdisplay, lvdisplay, vgdisplay ou lvs.
Tu dois avec un (ou plusieurs) device qui amene tes pv* / lv* a rencontrer une i/o bloquante ( ces comandes font un scan de differents /dev/* )
Regardes ce que tu as comme file-descriptor en cours sur un des process bloqués : ls -l /proc/[le-pid]/fd/ (ou avec lsof)
Autre piste, lancer l'une des commandes qui se bloque aves strace
Si c'est un /dev/dm-* ou /dev/mapper/* tu peux peut-etre regler le probleme a grands coups de dmsetup
Le 05/05/2017 à 17:03, Dominique Rousseau a écrit :
Le Fri, May 05, 2017 at 04:55:16PM +0200, Julien Escario [escario@azylog.net] a écrit: [...]
En revanche, en terme de symptômes, je n'ai aucun retour de pvdisplay, lvdisplay, vgdisplay ou lvs.
Tu dois avec un (ou plusieurs) device qui amene tes pv* / lv* a rencontrer une i/o bloquante ( ces comandes font un scan de differents /dev/* )
Regardes ce que tu as comme file-descriptor en cours sur un des process bloqués : ls -l /proc/[le-pid]/fd/ (ou avec lsof)
Autre piste, lancer l'une des commandes qui se bloque aves strace
Si c'est un /dev/dm-* ou /dev/mapper/* tu peux peut-etre regler le probleme a grands coups de dmsetup
Ah, merci, ca me fait avancer :
# ls -l /proc/8165/fd/ total 0 lr-x------ 1 root root 64 May 5 17:44 0 -> /dev/null l-wx------ 1 root root 64 May 5 17:44 1 -> pipe:[885312848] lrwx------ 1 root root 64 May 5 17:44 2 -> socket:[3855574] lrwx------ 1 root root 64 May 5 17:44 3 -> /run/lock/lvm/V_drbdpool lrwx------ 1 root root 64 May 5 17:44 4 -> /dev/mapper/control lr-x------ 1 root root 64 May 5 17:44 5 -> /dev/sdb1 lr-x------ 1 root root 64 May 5 17:44 6 -> /dev/drbd106
(le PID d'un vgdisplay lancé dans la matinée).
Et un strace bloque sur : stat("/dev/drbd106", {st_mode=S_IFBLK|0660, st_rdev=makedev(147, 106), ...}) = 0 open("/dev/drbd106", O_RDONLY|O_DIRECT|O_NOATIME) = 4 fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(147, 106), ...}) = 0 ioctl(4, BLKBSZGET, 4096) = 0 ioctl(4, BLKPBSZGET, 512) = 0 lseek(4, 171798626304, SEEK_SET) = 171798626304 read(4,
On comment gentillement à pointer du doigt /dev/drbd106 qui est justement la ressource qui à déclencher le truc.
Au départ, j'ai fait un assign de cette ressource sur cette machine. Ca a bien démarré puis planté :
exists device name:vm-210-disk-1 volume:0 minor:106 disk:Inconsistent size:167772160 read:0 written:267956 al-writes:116 bm-writes:0 upper-pending:6 lower-pending:2 al-suspended:no blocked:no
donc /dev/drbd106 = vm-210-disk-1
et : # drbdadm status vm-210-disk-1 role:Secondary disk:Inconsistent vm4 role:Secondary replication:SyncTarget peer-disk:UpToDate done:0.11 vm7 role:Primary replication:PausedSyncT peer-disk:UpToDate done:0.10
Donc l'affichage des outils LVM plantent parce qu'il y a une I/O bloquante sur /dev/drbd106. Du coup, c'est plutôt un soucis avec DRBD. Je précise que sur les nodes vm7 et vm4, tout va bien, la ressource est synchro. Il y a un stuck avec DRBD là.
Je vais descendre dans DRBD avec du plus low level que drbdmanage et tenter de faire oublier cette ressource à DRBD sur ce node.
DRBD serait la cause et LVM le symptôme dans ce cas.
Merci pour la piste !
Julien
Le 05/05/2017 à 18:05, Julien Escario a écrit :
Et un strace bloque sur : stat("/dev/drbd106", {st_mode=S_IFBLK|0660, st_rdev=makedev(147, 106), ...}) = 0 open("/dev/drbd106", O_RDONLY|O_DIRECT|O_NOATIME) = 4 fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(147, 106), ...}) = 0 ioctl(4, BLKBSZGET, 4096) = 0 ioctl(4, BLKPBSZGET, 512) = 0 lseek(4, 171798626304, SEEK_SET) = 171798626304 read(4,
On comment gentillement à pointer du doigt /dev/drbd106 qui est justement la ressource qui à déclencher le truc.
Bonjour la liste, Petit update du vendredi après-midi : après pas mal d'essais et de discussions sur la liste DRBD, on s'apprête finalement a rebooter l'hyperviseur.
Mais, bonne nouvelle, on est en train de vider l'hyperviseur de ses VMs parce qu’étonnamment, la migration fonctionne (Proxmox arrive à monter le dual primary alors qu'en ligne de commande, pas moyen).
Bref, pas de meilleure solution que le reboot au final. Et il va falloir monter les versions de DRBD ensuite ... (on consolide le backup hein).
Bon week-end, Julien
-
Dominique Rousseau -
Julien Escario