CloudStack - перезагружаются host(ы) с KVM во время падения сети

может ipmi чудит? к примеру, из-за перегрева. что за железо?

Dell FX2s c 630ми лезвиями. Я тоже думал сначала, что пропылесосить или продуть серваки нужно, после того как заметил такую проблему при power cycle его внутреннего свича. Тогда два блейда перегрузилось... А теперь во время замены внешнего свича перегрузились все 6 кроме тех 2-х которые не входят в CloudStack. Ну вроде как закономерность на лицо.

А что в dmesg самих нод? И что в логах менеджмент ноды?

Похоже на обычный fencing или self fencing

Да, мне тоже так кажется. Но если в pacemaker понятно где искать, то в CloudStack совсем не понятно. На самой KVM ноде где-то в настройках агента или на управляющем сервере или в настройках на веб-морде... Не подскажете где посмотреть, куда копнуть?

Ну в dmesg ожидаемо ничего интересного, только процесс загрузки...
А вот messages похоже найден триггер
pr 8 21:05:29 fx2-1-2 kernel: nfs: server 192.168.1.41 not responding, still trying
Apr 8 21:07:16 fx2-1-2 init: tty (/dev/tty1) main process (2693) killed by TERM signal
Apr 8 21:07:16 fx2-1-2 init: tty (/dev/tty2) main process (2695) killed by TERM signal
Apr 8 21:07:16 fx2-1-2 init: tty (/dev/tty3) main process (2697) killed by TERM signal
Apr 8 21:07:16 fx2-1-2 init: tty (/dev/tty4) main process (2699) killed by TERM signal
Apr 8 21:07:16 fx2-1-2 init: tty (/dev/tty5) main process (2701) killed by TERM signal
Apr 8 21:07:16 fx2-1-2 init: tty (/dev/tty6) main process (2703) killed by TERM signal
Apr 8 21:07:16 fx2-1-2 avahi-daemon[2264]: Got SIGTERM, quitting.
Apr 8 21:07:16 fx2-1-2 avahi-daemon[2264]: Leaving mDNS multicast group on interface cloud0.IPv4 with address 169.254.0.1.
Apr 8 21:07:16 fx2-1-2 avahi-daemon[2264]: Leaving mDNS multicast group on interface virbr0.IPv4 with address IP.
Apr 8 21:07:16 fx2-1-2 avahi-daemon[2264]: Leaving mDNS multicast group on interface cloudbr1.IPv4 with address IP.
Apr 8 21:07:16 fx2-1-2 avahi-daemon[2264]: Leaving mDNS multicast group on interface cloudbr3.IPv4 with address IP.
Apr 8 21:07:16 fx2-1-2 avahi-daemon[2264]: Leaving mDNS multicast group on interface cloudbr4.IPv4 with address IP.
Apr 8 21:07:16 fx2-1-2 avahi-daemon[2264]: Leaving mDNS multicast group on interface cloudbr0.IPv4 with address IP.
Apr 8 21:07:17 fx2-1-2 rhnsd[2634]: Exiting
Apr 8 21:07:24 fx2-1-2 kernel: nfsd: last server has exited, flushing export cache
Apr 8 21:07:24 fx2-1-2 rpc.mountd[2402]: Caught signal 15, un-registering and exiting.
Apr 8 21:07:24 fx2-1-2 ntpd[2470]: ntpd exiting on signal 15
Apr 8 21:20:27 fx2-1-2 kernel: nfs: server 192.168.1.41 OK
Apr 8 21:20:31 fx2-1-2 init: Disconnected from system bus
Apr 8 21:20:31 fx2-1-2 rpcbind: rpcbind terminating on signal. Restart with «rpcbind -w»
Apr 8 21:20:31 fx2-1-2 auditd[2159]: The audit daemon is exiting.
Apr 8 21:20:31 fx2-1-2 kernel: type=1305 audit(1491686431.248:24558): audit_pid=0 old=2159 auid=4294967295 ses=4294967295
Apr 8 21:20:31 fx2-1-2 kernel: res=1
Apr 8 21:20:31 fx2-1-2 kernel: type=1305 audit(1491686431.350:24559): audit_enabled=0 old=1 auid=4294967295 ses=4294967295
Apr 8 21:20:31 fx2-1-2 kernel: res=1
Apr 8 21:20:31 fx2-1-2 kernel: Kernel logging (proc) stopped.

Похоже, что когда CloudStack не видит CEPH хранилище срабатывает этот защитный механизм перезагрузки. Вот только где он и как отключить?

cloudstack никогда не тыкал даже палкой, просто поведение уж очень типичное для нормальной кластерной системы. Я бы поискал на мейлинг листах проекта или, если есть, на их IRC канале

Ну похоже много народу от этого страдает,

https://issues.apache.org/jira/browse/CLOUDSTACK-8943

Нашел скрипт /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm в котором кодируется поведение этого heartbeat и там если cflag=1, то reboot. Попробую проверить завтра в нерабочее время.

Так и оказалось /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/kvmheartbeat.sh отправляет в reboot если есть проблемы с сетью. Поставил заглушку с отправкой email на случай срабатывания. Но по опыту ни одного случая срабатывания с пользой еще ни разу не было поэтому думаю, что от этой фичи вреда больше чем пользы.

Запостил результат, так что может кому сгодится и сэкономит несколько часов времени.

отправляет сам себя или соседей? если себя то это вполне легитимный метод SBA, соседи запустят машины по HA, а этот хост, чтоб ничего не запороть, самоубивается

поэтому думаю, что от этой фичи вреда больше чем пользы.

Читать про split brain до просветления. А вообще, от таких фейлов спасает дублирование свичей.

Да себя. Но в моем случае реальных срабатываний небыло ни разу. А ложных из-за технических работ с сетевым оборудованием уже несколько раз.

В моем случае сплит-брэйн не возможен. В базах своя защита на этот счет имеется. А здесь тупо KVM ноды, даже CEPH нет, просто виртуалки. Т.ч. один вред.

Похоже, что когда CloudStack не видит CEPH хранилище срабатывает этот защитный механизм перезагрузки
В моем случае сплит-брэйн не возможен.

Ты пойди, почитай всё же.