Сама платформа не перезавантажується без причини: майже завжди спрацьовує щось зовнішнє — перебої живлення, перегрів, несправна пам'ять або сторож кластера, який скидає вузол при втраті зв'язку з рештою. Перевіряти варто по порядку, від частого і дешевого до рідкісного.
Перезавантаження чи зависання — як відрізнити
Спершу варто зрозуміти, що саме сталося: перезавантаження — це повний цикл вимкнення і ввімкнення, вузол знову зʼявляється в мережі через відомий час. Зависання — це коли вузол перестає відповідати, а живлення саме по собі не скидалося, і без втручання він не повернеться.
Різниця видна в журналі: після справжнього перезавантаження новий запис починається з чистої ініціалізації ядра і переліку обладнання. Після зависання з апаратним скиданням запис перед новим завантаженням просто обривається — останні повідомлення не встигли записатися на диск.
Куди дивитися в першу чергу
Для первинної діагностики вистачає кількох джерел, і кожне відповідає на своє питання.
- журнал з моменту попереднього завантаження — команда
journalctl -b -1показує, що відбувалося перед зупинкою - поточний аптайм — команда
uptimeпоказує, скільки система працює без перерви прямо зараз - повідомлення ядра про обладнання — команда
journalctl -kпоказує помилки пам'яті, диска і контролерів - температура компонентів — команда
sensorsпоказує нагрів процесора і плати, якщо встановлений пакет датчиків
Таблиця причин: від частого до рідкісного
Причини перезавантажень трапляються нерівномірно: одні — майже в кожному випадку, інші — вкрай рідко. Порядок у таблиці це відображає.
| Причина | Як проявляється | Чим перевірити |
|---|---|---|
| Перебої живлення або просідання напруги | перезавантаження раптове, часто під навантаженням, без попереджень | журнал за час збою, стан блока живлення і кабелю, журнал ДБЖ |
| Перегрів процесора або плати | вузол йде в перезавантаження саме під навантаженням | sensors, повідомлення ядра про теплозахист |
| Несправна пам'ять | перезавантаження і зависання випадкові, без закономірності | тест пам'яті, повідомлення про помилки корекції в журналі ядра |
| Помилка файлової системи | перезавантаження відбувається під час перевірки диска при старті | повідомлення файлової системи в журналі, перевірка диска |
| Сторож кластера при втраті кворуму | перезавантажуються лише вузли в кластері і лише при проблемах із мережею | журнал кластерної служби, стан кворуму |
| Оновлення з новим ядром | перезавантаження передбачуване і відбувається після оновлення пакетів | журнал менеджера пакетів, перелік встановлених ядер |
| Переповнення диска | вузол зависає і втрачає служби одну за одною, а не перезавантажується чисто | вільне місце на розділах |
Сторож кластера і втрата кворуму
У кластері окремий механізм — сторож — стежить за зв'язком між вузлами і станом кворуму. При втраті зв'язку з рештою і зникненні кворуму сторож навмисно перезавантажує вузол, щоб той не продовжував працювати в ізоляції і не розійшовся з рештою в даних.
Найчастіше це трапляється саме в кластері з двох вузлів: при розриві зв'язку між ними жоден не набирає більшість голосів, і перезавантаження спрацьовує майже при будь-якому мережевому збої. У кластері з більшою кількістю вузлів меншість лишається в ізоляції, а більшість продовжує працювати без перезавантажень.
Як лишити собі доказ на майбутнє
Коли причина не знайшлася з першого разу, варто заздалегідь підготувати вузол до наступного збою — інакше доказу знову не лишиться.
- увімкнути збереження журналу між завантаженнями, а не лише в оперативній пам'яті
- надсилати журнал на інший вузол або сервер, щоб запис не губився разом із диском
- поставити моніторинг температури і навантаження блока живлення, а не перевіряти їх після збою
- підключити вузол через ДБЖ зі сповіщенням про зникнення зовнішнього живлення
Чому гостьові машини здаються повільними
Це сусіднє, але інше питання: вузол працює стабільно і водночас видає гостям недостатньо ресурсів.
- забагато віртуальних машин ділять між собою одні й ті самі ядра процесора
- диски сховища не встигають за одночасними запитами кількох гостей
- гостю бракує виділеної пам'яті, і він іде в підкачку всередині себе
Докладний розбір цієї теми особливо важливий для компактних вузлів — його розкриває стаття про домашню лабораторію на міні-ПК.
Часті питання
Чому сервер Proxmox перезавантажується сам?
Сама платформа не містить коду, який перезавантажує справний вузол без причини. Майже завжди спрацьовує щось зовнішнє: перебої живлення, перегрів, несправна пам'ять або сторож кластера, який скидає вузол при втраті зв'язку з рештою. Перевірку ведуть від частого і дешевого до рідкісного і складного.
Як подивитися журнал минулого завантаження?
Команда journalctl з ключем -b -1 показує журнал попереднього завантаження, якщо увімкнене його збереження між перезапусками. Там видно останні повідомлення перед зупинкою: помилки ядра, попередження про пам'ять чи диски, або різкий обрив запису, якщо сталося не штатне вимкнення, а апаратне скидання.
Чи може кластер перезавантажити вузол?
Так: вузол у кластері стежить за станом кворуму, і при втраті зв'язку з рештою спеціальний сторож навмисно перезавантажує його, щоб вузол не продовжував працювати в ізоляції. На двох вузлах це трапляється особливо часто, бо при розриві зв'язку жоден не набирає більшість голосів.
Як перевірити пам'ять?
Несправну пам'ять шукають тестом, який проганяє вільну пам'ять вузла циклами читання і запису і шукає розбіжності; його варто запускати при підозрі на випадкові і незрозумілі перезавантаження. Повідомлення про корекцію помилок пам'яті також видно в журналі ядра — вони часто зʼявляються задовго до першого зависання.
Висновок
Діагностику варто вести по порядку: спершу дешеві і часті причини — живлення, перегрів, пам'ять і диск, і лише потім рідкісні — оновлення ядра і поведінку сторожа кластера. Збережений між завантаженнями журнал економить більшу частину часу на наступному розборі. Загальну картину платформи і її роль в інфраструктурі описує стаття про Proxmox VE.