Suite au dernier problème rencontré sur l'infra d'ARN, je viens de mettre à jour cette page. On y parle des split-brain DRBD et de que faire lorsqu'un gnt-instance --cleanup
reste bloqué Si ça peut aider des gens…
En gros, voici ce qui s'est passé : je souhaitais appliquer la màj de sécurité de Linux ajoutée dans Debian 8.7. Je migre toutes les VMs sur le 2e hypeviseur, je màje le premier hyperviseur, je le reboot, il revient à la vie, les DRBD remontent, etc.
Je migre toutes les VMs sur le 1er hyperviseur, je màj le deuxième hyperviseur, je reboot. Le deuxième hyperviseur revient à la vie, les premiers DRBD commencent à peine à remonter et là… perte de contrôle sur le premier hyperviseur : plus de SSH (pas même de SSHoIPv6), plus de ping (mais encore ping6 !) sur le lien d'interco direct entre les deux hyperviseurs, plus de BGP (IPv4 comme IPv6) entre les deux hyperviseurs, impossible d'obtenir un quelconque affichage sur la console virtuelle de la BMC, etc. Évidemment, rien dans les logs sinon ça rend le post-mortem trop facile.
À ce stade, j'aurais pu tenter de mettre en sécurité les VMs dont le DRBD était remonté (pour autant qu'il y en ait eu, ce que je ne sais pas) en forçant le 2e hyperviseur à devenir le master puis en migrant les VMs sur ce 2e hyperviseur. Je n'y ai pas pensé.
Vu l'ampleur du problème, je décide de forcer le redémarrage physique du premier hyperviseur avec la BMC. Je reprends la main dans la console de la BMC et via SSH.
Tous les DRBD remontent et Ganeti démarre toutes les VMs… Mais, notre monitoring me remonte qu'un DRBD est dans un sale état : « 24: cs:WFBitMapS ro:Primary/Secondary ds:UpToDate/Consistent C r----- ».
On est typiquement dans une conséquence d'un split-brain DRBD. Sauf qu'il est d'un type nouveau que nous n'avons pas encore documenté. C'est désormais chose faite. Notons qu'après coup, je ne suis pas satisfait de la solution car elle répond plutôt à la question « comment annuler un job dans l'état running ? » qu'à la question « comment résoudre ce type de split-brain ? ». Il aurait pu être intéressant de tenter un gnt-instance activate-disks
plutôt qu'un gnt-instance --cleanup
mais bon…