Сама платформа не перезагружается без причины: почти всегда срабатывает что-то внешнее — перебои питания, перегрев, неисправная память или сторож кластера, который сбрасывает узел при потере связи с остальными. Проверять стоит по порядку, от частого и дешёвого к редкому.
Перезагрузка или зависание — как отличить
Сначала стоит понять, что именно произошло: перезагрузка — это полный цикл выключения и включения, узел снова появляется в сети через известное время. Зависание — это когда узел перестаёт отвечать, а питание само по себе не сбрасывалось, и без вмешательства он не вернётся.
Разница видна в журнале: после настоящей перезагрузки новая запись начинается с чистой инициализации ядра и перечисления оборудования. После зависания с аппаратным сбросом запись перед новой загрузкой просто обрывается — последние сообщения не успели записаться на диск.
Где смотреть в первую очередь
Для первичной диагностики хватает нескольких источников, и каждый отвечает на свой вопрос.
- журнал с момента предыдущей загрузки — команда
journalctl -b -1показывает, что происходило перед остановкой - текущий аптайм — команда
uptimeпоказывает, сколько система работает без перерыва прямо сейчас - сообщения ядра об оборудовании — команда
journalctl -kпоказывает ошибки памяти, диска и контроллеров - температура компонентов — команда
sensorsпоказывает нагрев процессора и платы, если установлен пакет датчиков
Таблица причин: от частого к редкому
Причины перезагрузок встречаются неравномерно: одни — почти в каждом случае, другие — крайне редко. Порядок в таблице это отражает.
| Причина | Как проявляется | Чем проверить |
|---|---|---|
| Перебои питания или просадки напряжения | перезагрузка внезапная, часто под нагрузкой, без предупреждений | журнал за время сбоя, состояние блока питания и кабеля, журнал ИБП |
| Перегрев процессора или платы | узел уходит в перезагрузку именно под нагрузкой | sensors, сообщения ядра о тепловой защите |
| Неисправная память | перезагрузки и зависания случайны, без закономерности | тест памяти, сообщения об ошибках коррекции в журнале ядра |
| Ошибка файловой системы | перезагрузка происходит во время проверки диска при старте | сообщения файловой системы в журнале, проверка диска |
| Сторож кластера при потере кворума | перезагружаются только узлы в кластере и только при проблемах с сетью | журнал кластерной службы, состояние кворума |
| Обновление с новым ядром | перезагрузка предсказуема и происходит после обновления пакетов | журнал менеджера пакетов, список установленных ядер |
| Переполнение диска | узел зависает и теряет службы одну за другой, а не перезагружается чисто | свободное место на разделах |
Сторож кластера и потеря кворума
В кластере отдельный механизм — сторож — следит за связью между узлами и состоянием кворума. При потере связи с остальными и пропаже кворума сторож намеренно перезагружает узел, чтобы тот не продолжал работать в изоляции и не разошёлся с остальными в данных.
Чаще всего это происходит именно в кластере из двух узлов: при разрыве связи между ними ни один не набирает большинство голосов, и перезагрузка срабатывает почти при любом сетевом сбое. В кластере с большим числом узлов меньшинство остаётся в изоляции, а большинство продолжает работать без перезагрузок.
Как оставить себе улику на будущее
Когда причина не нашлась с первого раза, стоит заранее подготовить узел к следующему сбою — иначе улики снова не останется.
- включить сохранение журнала между загрузками, а не только в оперативной памяти
- отправлять журнал на другой узел или сервер, чтобы запись не терялась вместе с диском
- поставить мониторинг температуры и нагрузки блока питания, а не проверять их после сбоя
- подключить узел через ИБП с уведомлением о пропадании внешнего питания
Почему гостевые машины кажутся медленными
Это соседний, но другой вопрос: узел работает стабильно и при этом выдаёт гостям недостаточно ресурсов.
- слишком много виртуальных машин делят между собой одни и те же ядра процессора
- диски хранилища не успевают за одновременными запросами нескольких гостей
- гостю не хватает выделенной памяти, и он уходит в подкачку внутри себя
Подробный разбор этой темы особенно важен для компактных узлов — его раскрывает статья о домашней лаборатории на мини-ПК.
Частые вопросы
Почему сервер Proxmox перезагружается сам?
Сама платформа не содержит кода, который перезагружает исправный узел без причины. Почти всегда срабатывает что-то внешнее: перебои питания, перегрев, неисправная память или сторож кластера, который сбрасывает узел при потере связи с остальными. Проверку ведут от частого и дешёвого к редкому и сложному.
Как посмотреть журнал прошлой загрузки?
Команда journalctl с ключом -b -1 показывает журнал предыдущей загрузки, если включено его сохранение между перезапусками. Там видны последние сообщения перед остановкой: ошибки ядра, предупреждения о памяти или дисках, либо резкий обрыв записи, если случилось не штатное выключение, а аппаратный сброс.
Может ли кластер перезагрузить узел?
Да: узел в кластере наблюдает за состоянием кворума, и при потере связи с остальными специальный сторож намеренно перезагружает его, чтобы узел не продолжал работать в изоляции. На двух узлах это происходит особенно часто, потому что при разрыве связи ни один не набирает большинство голосов.
Как проверить память?
Неисправную память ищут тестом, который прогоняет свободную память узла циклами чтения и записи и ищет несовпадения; его стоит запускать при подозрении на случайные и необъяснимые перезагрузки. Сообщения о коррекции ошибок памяти также видны в журнале ядра — они часто появляются задолго до первого зависания.
Вывод
Диагностику стоит вести по порядку: сначала дешёвые и частые причины — питание, перегрев, память и диск, и только потом редкие — обновление ядра и поведение сторожа кластера. Сохранённый между загрузками журнал экономит большую часть времени на следующем разборе. Общую картину платформы и её роль в инфраструктуре описывает статья о Proxmox VE.