Watchdog – незалежний моніторинг стану VM у хмарі: від /dev/watchdog до тесту перезавантаження

Блог WebDisk · категорія: Хмарні обчислення · час читання: ~9 хвилин

Коротко:- Панель хмари може показувати «Running», хоча система всередині VM уже чверть години не відповідає – механізми HA гіпервізора бачать машину ззовні, а не її нутрощі.- Watchdog – це лічильник, який відлічує час поза гостьовою системою: якщо система перестане його регулярно «обнуляти», гіпервізор жорстко перезавантажить VM – навіть тоді, коли ядро цілком зависло.- Реакцією є перезавантаження, а не ремонт – тому у WebDisk Cloud пристрій /dev/watchdog доступний у машинах, але механізм ми не вмикаємо за Вас; у статті показуємо, як зробити це свідомо. >Не працюєте з терміналом? Пропустіть блоки команд – опис механізму, порівняння з HA та розділ про межі рішення читаються й без них.

Зараз 3:00 ночі. Моніторинг інфраструктури світиться зеленим, панель хмари показує біля Вашої машини статус «Running» – а клієнти вже двадцять хвилин не можуть відкрити застосунок. Операційна система всередині VM зависла остаточно: ядро перестало планувати процеси, консоль не реагує, від SSH немає й сліду. З погляду інфраструктури нічого не сталося, бо процес віртуальної машини на фізичному сервері працює бездоганно. Аварія невидима саме там, куди дивиться автоматика.

На цей сценарій існує механізм, старший за хмару: watchdog – буквально «сторожовий пес», лічильник часу, який треба регулярно обнуляти, бо інакше він кусає. У цій статті пояснюємо, чим watchdog, запущений усередині машини, відрізняється від високої доступності (HA) на рівні гіпервізора, як працює пристрій /dev/watchdog, як крок за кроком увімкнути й перевірити watchdog в Ubuntu – та, чесно кажучи, коли краще його не вмикати. Текст стане в пригоді кожному, хто утримує віртуальні машини в хмарі – у WebDisk Cloud і не тільки.

Чому панель хмари показує «Running», хоча VM не працює?

Класичні механізми високої доступності в хмарі працюють на рівні інфраструктури. Гіпервізор (програмне забезпечення, яке запускає віртуальні машини на фізичному сервері) та шар керування стежать за двома речами: чи живий хост і чи живий процес VM. Коли впаде фізичний сервер – машини піднімаються на іншому; коли процес VM несподівано зникне – його буде запущено повторно. Це важлива страхувальна сітка, але вона дивиться на машину виключно ззовні.

Тим часом чимала частина реальних аварій відбувається всередині гостьової системи: блокування ядра (kernel lockup), зависання процесу init/systemd, вичерпана пам’ять, після якої система метається між убиванням процесів і swap, помилка драйвера. Машина «працює» – іноді навіть відповідає на ping – але не надає послугу, і до неї неможливо залогуватися. Для механізмів HA гіпервізора такий стан не відрізнити від здорового: процес VM існує, отже, з їхнього погляду рятувати нема чого.

Саме цю прогалину закриває watchdog, запущений у самій машині.

Як працює watchdog і /dev/watchdog?

Принцип дії навмисно примітивний – і в цьому його сила. Watchdog – це лічильник зворотного відліку, розміщений поза контролем системи, за якою він наглядає. Система мусить циклічно його обнуляти; якщо перестане – лічильник добігає кінця й запускає наперед визначену реакцію. У фізичних серверах таку роль виконує мікросхема на материнській платі; у віртуальній машині – віртуальний пристрій watchdog, який гіпервізор надає гостю. У Linux він видимий як файл пристрою /dev/watchdog. Після його відкриття лічильник зводиться: відтоді хтось мусить регулярно до нього писати.

На практиці це робить демон watchdog: відкриває пристрій і «звітує» кожні кілька–кільканадцять секунд. Доки система працює, звіти надходять. Коли ядро зависне, демон не отримає процесорного часу, лічильник добіжить нуля, а гіпервізор виконає налаштовану дію – жорстке перезавантаження машини. Ключове те, що виконання відбувається поза гостьовою системою: зависле ядро не може його зупинити, бо лічильник цокає не в цьому ядрі, а поверхом нижче.

Демон при цьому вміє більше, ніж звітувати «я живий». У конфігураційному файлі можна додати тести стану: максимальне навантаження системи, наявність процесу із вказаним PID-файлом, свіжість файлу (чи лог і далі зростає), відповідь указаного хоста на ping, зрештою власні тестові скрипти. Якщо якийсь тест постійно не проходить, демон навмисно припиняє обнуляти лічильник і доводить до перезавантаження – попри те, що ядро формально працює. Завдяки цьому він реагує також на «м’які» зависання, а не лише на клінічну смерть системи.

Чим watchdog відрізняється від HA гіпервізора?

• Що спостерігає – HA на рівні гіпервізора: фізичний хост і процес VM · Watchdog усередині VM: нутрощі гостьової системи
• Виявляє – HA на рівні гіпервізора: аварію хоста, зникнення процесу VM · Watchdog усередині VM: зависання ядра, брак відповіді системи, непройдені тести стану
• Не виявляє – HA на рівні гіпервізора: зависання всередині працюючого процесу VM · Watchdog усередині VM: аварії хоста (це не його роль)
• Реакція – HA на рівні гіпервізора: повторний запуск VM, напр. на іншому хості · Watchdog усередині VM: жорстке перезавантаження VM
• Хто вмикає й налаштовує – HA на рівні гіпервізора: постачальник хмари · Watchdog усередині VM: користувач, усередині власної машини

Ці два механізми не конкурують між собою – вони дивляться на ту саму машину з двох протилежних боків і лише разом замикають картину аварії: від падіння фізичного сервера до зависання ядра. Що важливо у спільному середовищі: watchdog налаштовується повністю всередині VM, без змін на боці гіпервізора – отже, користувач хмари може підвищити стійкість своєї системи самостійно, не порушуючи розподілу відповідальності між ним і постачальником.

Як увімкнути watchdog в Ubuntu крок за кроком?

Приклад стосується Ubuntu Server (напр. 22.04 або 24.04); в інших дистрибутивах Linux відрізняються щонайбільше назви пакетів.

1. Перевірте, чи машина бачить пристрій:

ls -l /dev/watchdog*
# crw------- 1 root root 10, 130 ... /dev/watchdog

Якщо файлу немає, гіпервізор не надав машині віртуального пристрою watchdog (що робити в такій ситуації – див. FAQ; у WebDisk Cloud пристрій доступний).

2. Встановіть демон:

sudo apt update
sudo apt install watchdog

3. Налаштуйте файл /etc/watchdog.conf:

sudo nano /etc/watchdog.conf

Мінімальна, розумна стартова конфігурація:

# пристрій і ритм звітів
watchdog-device = /dev/watchdog
interval = 10 # демон звітує кожні 10 с; це має бути
                           # помітно менше, ніж ліміт часу пристрою

# необов’язкові тести стану – розкоментовуйте свідомо:
#max-load-1 = 24 # перезавантаження при 1-хв. load > 24
#pidfile = /run/mysqld/mysqld.pid # стеж за конкретним процесом
#file = /var/log/syslog # вказаний файл має змінюватися…
#change = 1800 # …принаймні кожні 1800 с

4. Увімкніть службу та спостерігайте:

sudo systemctl enable --now watchdog
systemctl status watchdog
journalctl -u watchdog -f # звіти й результати тестів наживо

Від цієї миті машина під наглядом. Дві організаційні зауваги: планова зупинка служби (systemctl stop watchdog) закриває пристрій «чисто» і роззброює лічильник, тож у типовій конфігурації не закінчується перезавантаженням; тести стану додавайте по одному й спостерігайте за логами після кожної зміни – про те, чому це важливо, за мить у балансі.

Перевірте, перш ніж довіряти

Попередження. Наведений нижче тест жорстко перезавантажує машину – точно так, як зробив би watchdog при справжній аварії. Виконуйте його виключно на тестовій машині або в узгодженому сервісному вікні; усі незбережені дані пропадуть.

Watchdog, який ніколи не перевіряли, – це лише запис у конфігурації. Найбільш достовірний тест симулює саме той сценарій, від якого механізм має захищати – миттєве зависання ядра:

# примусовий crash ядра – система негайно перестає відповідати
echo c | sudo tee /proc/sysrq-trigger

Машина завмирає: сесія SSH обривається, консоль не реагує. Демон припиняє звітувати пристрою, лічильник добігає нуля, і гіпервізор перезавантажує VM. Після повернення системи перевірте перебіг події:

uptime # свіжий час роботи = перезавантаження спрацювало
journalctl -b -1 -e # останні записи з попереднього запуску

Якщо машина замість перезавантаження після спливання ліміту висить нескінченно – поверніться до попереднього розділу: найчастіше виявляється, що демон не працював або не відкривав належного пристрою.

Коли не вмикати watchdog і які в нього обмеження?

Назвімо речі своїми іменами: watchdog нічого не діагностує й не ремонтує. Його єдина реакція – жорстке перезавантаження, еквівалент висмикування вилки з розетки:

• Перезавантаження перериває все, зокрема й операції в процесі. Журнальовані файлові системи (ext4, XFS) і бази даних із механізмами відновлення після аварії спроєктовані так, щоб такий рестарт пережити, але дані, не записані на диск, пропадають. Watchdog у жодному разі не замінює резервних копій – ми писали про них у статті Резервна копія в хмарі – основа сучасної IT-безпеки.
• Перезавантаження маскує причину. Машина, яка «сама» рестартує кожні кілька днів, у статистиці доступності виглядає здоровою, хоча хворіє. Watchdog має йти в парі з моніторингом і аналізом логів: перезавантаження – це лише пластир, а не лікування.
• Ви втрачаєте доказовий матеріал. Зависла машина – це також стоп-кадр аварії; перезавантаження його стирає. Коли Ви намагаєтеся діагностувати важковідтворюване зависання, watchdog буває ворогом розслідування.
• Тести стану бувають хибнопозитивними. Правило на кшталт max-load-1 на машині, яка згідно з планом рахує щось важке, здатне перезавантажити систему посеред коректно виконуваної роботи. Тому пороги добирають до характеру навантаження, а нові тести вмикають по одному, з періодом спостереження.

Коли watchdog не вмикати? Коли машина виконує довгі пакетні завдання без контрольних точок; коли Ви аналізуєте повторюване зависання і потребуєте «живої» машини для діагностики; коли служба й так стоїть за балансувальником навантаження, який сам вимикає хворі екземпляри. Найбільше watchdog дає на самостійних машинах, яких ніхто не дублює: одиничний сервер застосунків, VPN-шлюз, адміністративна панель, поштовий сервер.

Watchdog у WebDisk Cloud

Наша хмара працює на платформі Apache CloudStack, а станом фізичних серверів і шару віртуалізації опікуємося ми: аварії на боці інфраструктури – це наша відповідальність. Проте лишається саме та прогалина, з якої ми почали: машина, зависла всередині, ззовні може виглядати справною – і жоден механізм на боці постачальника не повинен тоді вгадувати за Вас, чи жорстке перезавантаження саме зараз є безпечним.

Тому розподіл ролей простий:

• Машини у WebDisk Cloud стартують із доступним пристроєм /dev/watchdog – Вам не треба нічого замовляти чи змінювати в конфігурації послуги.
• Механізм не увімкнено типово в наших шаблонах систем. Оскільки реакцією є перезавантаження, рішення про зведення – і добір тестів стану під Ваш застосунок – належать Вам.
• Увімкнення відбувається повністю всередині машини, точно так, як в інструкції вище – без втручання в гіпервізор і без участі нашої команди.

Якщо Ви переходите до нас із середовища VMware, де споріднену роль виконує моніторинг машин на основі сигналу гостьових інструментів, концепція буде знайома – а про сам переїзд пишемо у статті про міграцію з VMware до WebDisk Cloud.

Часті запитання

Чим watchdog усередині VM відрізняється від HA гіпервізора? HA гіпервізора дивиться на машину ззовні: стежить за фізичним хостом і процесом VM, тож не бачить зависання всередині працюючої системи. Watchdog діє навпаки – наглядає за нутрощами гостьової системи і за браку звітів доводить до жорсткого перезавантаження машини, виконаного гіпервізором. Це взаємодоповнювальні механізми: лише разом вони охоплюють аварії від падіння фізичного сервера до завислого ядра.

Чи замінює watchdog моніторинг – графіки, сповіщення, нотифікації? Ні, доповнює його. Моніторинг каже, що і чому відбувається, та будить людину; watchdog лише повертає машину до життя, коли ніхто не дивиться. Зріла конфігурація має і одне, і друге: watchdog скорочує простій, моніторинг дозволяє усунути причину.

Застосунок завис, але система працює. Чи виявить це watchdog? Сам собою ні – без тестів стану він реагує лише на брак відповіді системи. Першою лінією оборони для окремої служби є рестарт самого процесу (напр. Restart=on-failure у systemd). Тест із PID-файлом або власним скриптом може бути другою лінією, але пам’ятайте: його наслідком є перезавантаження всієї машини – це найгрубіший доступний інструмент, і саме так до нього слід ставитися.

Чи може жорстке перезавантаження пошкодити дані? Сучасні журнальовані файлові системи та бази даних із відновленням після аварії переносять його зазвичай без шкоди – ціною втрати даних, які не встигли потрапити на диск. Ризик реальний для застосунків, що пишуть без транзакційних запобіжників. Висновок завжди той самий: перезавантаження не звільняє від наявності перевірених резервних копій.

У моїй машині немає /dev/watchdog. Що тепер? Поза WebDisk Cloud – запитайте постачальника, чи надає він віртуальний пристрій watchdog. Альтернатива – softdog, модуль ядра, що емулює watchdog суто програмно (sudo modprobe softdog). Чесно: softdog працює в тому самому ядрі, за яким має наглядати, тож при повному блокуванні ядра може відмовити разом із ним – пристрій, наданий гіпервізором, дає надійнішу гарантію.

Як перевірити, чи watchdog справді працює? На тестовій машині або в узгодженому сервісному вікні примусово викличте crash ядра командою echo c | sudo tee /proc/sysrq-trigger – система негайно перестане відповідати. Якщо watchdog справний, після спливання ліміту гіпервізор жорстко перезавантажить VM; після повернення системи Ви підтвердите це свіжим uptime та записами з попереднього запуску в journalctl -b -1. Машина, що висить нескінченно, найчастіше означає, що демон не працював або не відкривав належного пристрою.

Чи це працює лише в Linux? Приклади в цій статті стосуються Linux – це найкраще задокументований і найпростіший шлях. В інших системах потрібен драйвер віртуального пристрою watchdog і відповідник демона; перед впровадженням перевірте в документації, чи Ваша система підтримує такий пристрій.

Підсумок

Watchdog належить до механізмів жанру «простий, а тому дієвий»: лічильник, який відлічує час поза гостьовою системою, перетворює найгірший різновид аварії – тиху, невидиму ззовні – на звичайний, короткий рестарт. Три речі варто запам’ятати: HA гіпервізора і watchdog дивляться на машину з двох різних боків і лише разом замикають картину; реакцією watchdog є жорстке перезавантаження, тож зводять його свідомо й після тесту; у WebDisk Cloud пристрій /dev/watchdog чекає у Вашій машині, а звести його – це вже Ваше рішення і чверть години роботи. А якщо Ви лише шукаєте середовище для своїх машин, перегляньте, чим є публічна хмара за розумною ціною.

Не впевнені, чи watchdog пасує до Вашого навантаження? Напишіть нам – команда підтримки WebDisk допоможе оцінити, чи це рішення підходить для Вашого сценарію.