Продолжая тему возможностей обеспечения высокой доступности (High Availability) в oVirt 4.0 нельзя упустить из виду такой функционал, как поддержка виртуальных устройств Watchdog. В этой заметке мы рассмотрим практический пример настройки Watchdog-устройства в виртуальной машине с гостевой ОС Ubuntu Linux 16.04 LTS.
Рассмотренные в прошлой части механизмы Fencing в oVirt реализуют высокую доступность на уровне хостов виртуализации и виртуальных машин, но это механизмы более низкого уровня и они не отвечают за разрешение проблемных ситуаций в плане доступности гостевой ОС внутри самих виртуальных машин. На этот случай, для особо критичных виртуальных машин, в oVirt имеется возможность активировать виртуальное Watchdog-устройство в конфигурации ВМ. Об этом типе устройств упоминается в документах Watchdog Device и oVirt Administration Guide.
Итак, рассмотрим пример настройки Watchdog для ВМ с гостевой ОС Ubuntu Linux 16.04.1 LTS.
В веб-консоли oVirt откроем свойства виртуальной машины и перейдём на вкладку High Availability. Здесь настроим использование Watchdog-устройства. Смысл в том, что в конфигурацию ВМ добавляется новое виртуальное устройство i6300esb, для обеспечения работы которого, в гостевую ОС необходимо установить и запустить специальную службу. Эта служба будет обмениваться данными с этим виртуальным Watchdog-устройством. В случае если с гостевой ОС произойдёт какой-то серьёзный сбой и, как следствие, служба станет не доступна, то Watchdog-устройство инициирует перезапуск данной виртуальной машины. В окне Watchdog Action, мы должны определить действие, которое oVirt должен выполнять в том случае, если Watchdog-устройство перестанет получать сигналы доступности от Watchdog-службы внутри гостевой ОС. В большинстве сценариев может использоваться reset, то есть форсированный перезапуск ВМ. Но есть и другие варианты действий, которые вы сможете использовать в зависимости от своих потребностей - none, poweroff, dump, pause…
После загрузки нашей виртуальной машины с гостевой ОС Ubuntu Linux убедимся в том, что в системе появилось новое Watchdog-устройство:
$ sudo lspci | grep watchdog -i
Установим соответствующую службу из пакета watchdog
$ sudo install watchdog
Сделаем минимальную корректировку конфигурационного файла /etc/watchdog.conf, то есть уберём комментарий в одной строке (другие параметры настраиваются при необходимости в зависимости от ваших потребностей):
watchdog-device = /dev/watchdog
Для проверки подгружаем модуль ядра с драйвером для поддержки нашей модели Watchdog-устройства:
$ sudo modprobe i6300esb $ sudo modinfo i6300esb
После этого попробуем включить и запустить службу watchdog:
$ sudo systemctl enable watchdog $ sudo systemctl start watchdog $ sudo systemctl status watchdog
Служба, как минимум, должна запуститься без ошибок:
Теперь нам нужно обеспечить правильную загрузку службы watchdog во время загрузки гостевой ОС. Для этого в файл /etc/default/watchdog в строку watchdog_module="none" вносим имя нашего модуля и при необходимости добавляем параметры watchdog_options. В итоге файл должен принять следующий вид:
# Start watchdog at boot time? 0 or 1 run_watchdog=1 # Start wd_keepalive after stopping watchdog? 0 or 1 run_wd_keepalive=1 # Load module before starting watchdog watchdog_module=i6300esb # Specify additional watchdog options here (see manpage). watchdog_options="-s -c /etc/watchdog.conf"
В файле блэк-листа /etc/modprobe.d/blacklist-watchdog.conf среди множества строк находим и комментируем строку с названием нужного нам модуля ядра, чтобы разрешить его загрузку:
... #blacklist i6300esb ...
В целом проделанных действий должно быть достаточно, однако, как показывает практика, в некоторых случаях при загрузке системы служба watchdog не стартует, поэтому в конец файла /etc/rc.local можно добавить излюбленный "костыль", который после запуска системы будет выполнять сначала проверку наличия в системе watchdog-устройства, а затем, если это устройство есть, будет выполнять проверку состояния службы watchdog, и если необходимо инициировать запуск этой службы.
... sleep 5 if [ "$(lspci | grep watchdog -i)" ]; then if [ -z "$(service watchdog status | grep 'Active: active')" ]; then service watchdog start fi fi exit 0
В конце проделанной настройки перезагружаем наш виртуальный сервер c Ubuntu (можно для проверки несколько раз) и убеждаемся в том, что после каждого запуска системы служба watchdog успешно стартует. Если с авто-запуском службы проблем нет, можем переходить к проверке совместной работы виртуального watchdog-устройства и watchdog-службы.
Для проверки из под root выполним команду, которая вызовет "краш" нашей гостевой Linux-системы:
$ sudo su - # echo c > /proc/sysrq-trigger
После выполнения этой команды гостевая ОС "намертво" повиснет и, как следствие, виртуальное watchdog-устройство потеряет связь с watchdog-службой внутри ОС. Спустя 60 секунд (интервал опроса по умолчанию) watchdog-устройство инициирует перезагрузку ВМ, о чём будет выведено соответствующее сообщение во вкладке отображения событий в еб-консоли oVirt
После перезагрузки наша гостевая ОС снова в работе, а пара watchdog-устройство/watchdog-служба снова будет нести для нас свою "нелёгкую вахту".
***
В связи с тем, что не так давно появилась новая версия oVirt 4.0.3, в следующей части серии заметок посвящённых oVirt, мы рассмотрим процедуру обновления oVirt Hosted Engine до актуальной новой версии внутри 4 ветки.
Дополнительные источники информации:
- Dr. Paul S. Crawford - Linux Watchdog Daemon - Installation
- Humble Chirammal - Ovirt watchdog to restart VM incase the VM became unresponsive..
- Red Hat Knowledgebase - watchdog service is not working because /dev/watchdog does not exist
Настройка для Debian описана здесь: Настройка Watchdog в виртуальной машине oVirt 4.0 с гостевой ОС Debian 8.6
Спасибо.
Чувствуется, конечно, разница с vmware. По мимо того, что настраивается в vmware это все до безобразия просто, еще и гибкость высокая. Плюс вместо watchdog используется сам агент, интересно почему в агент этот функционал не всунули здесь? Например, Перед ресетом виртуалке несколько раз запускается тест на доступность, каждый раз увеличивая временной интервал и только пото ресет. Тут, я так понимаю, 60 сек и алес. На мой взгляд лучше увеличить время как минимум до 200 сек. 60 секунд сама ОС обычно ждет спокойно, иногда выставляют 190 вручную.