Доброе утро.
Настройки одной из ВМ в кластере:
primitive Linux-amd64-syslog ocf:heartbeat:VirtualDomain \
params config="/etc/libvirt/qemu/gentoo-amd64-syslog.xml" migration_transport="ssh" \
meta target-role="Started" allow-migrate="true" \
op monitor interval="10"После тестирования онлайн-миграции ВМ программным путём (т.е. через консоль resource migrate и node standby), было проведено испытание жёстче: нода, на которой работала ВМ, была внезапно выключена через кнопку питания, имитируя kernel panic.
Вот что наблюдалось при этом на живой ноде:
Node fs_1: online
Linux-amd64-ldapm (ocf::heartbeat:VirtualDomain) Started
Win2003 (ocf::heartbeat:VirtualDomain) Started
ssh-fencing:0 (stonith:ssh) Started
Node fs_2: UNCLEAN (offline)
ssh-fencing:1 (stonith:ssh) Started
Linux-amd64-ldaps (ocf::heartbeat:VirtualDomain) Started
Linux-amd64-syslog (ocf::heartbeat:VirtualDomain) Started
Inactive resources:
Clone Set: Fencing [ssh-fencing]
Started: [ fs_1 ]
Stopped: [ ssh-fencing:1 ]
Resource Group: ClusterIP
InternalIP (ocf::heartbeat:IPaddr2): Stopped
ExternalIP (ocf::heartbeat:IPaddr2): Stopped
Linux-amd64-syslog (ocf::heartbeat:VirtualDomain): Started fs_2
Linux-amd64-ldaps (ocf::heartbeat:VirtualDomain): Started fs_2
Migration summary:
* Node fs_1:т.е. миграция двух виртуалок не прошла. Я понимаю, почему: данные, которые они занимали в памяти, неоткуда было брать. Дисковые устройства раздаются по сети с другого хоста, так что, с этим всё ок. Проблема только с процессом ВМ.
Итак, существует ли решение подобной проблемы? Или же kernel panic, отвалившаяся внезапно сетевая карта и т.п. штуки означают невозможность миграции всех ВМ с такой ноды?
Если же миграция невозможна, то можно ли упавшую виртуалку запустить на живой ноде автоматически? Как это указать pacemaker'у?
Я посмотрел: вроде как железячные решения, обеспечивающие failover существуют, могут ли их заменить программные?
