Диагностика сервера который пингуется но не отвечает по SSH через серийную консоль и IPMI с анализом нагрузки

Утро начинается с сообщения мониторинга: сервис недоступен. Хост отвечает на ping ровно и без потерь, но ssh молчит на этапе подключения, а проверка порта показывает таймаут. Классическое состояние: сетевой карте хватает питания, стек ядра жив, а пользовательская часть стоит. В стойке серверного зала нет монитора и клавиатуры, и задача сводится к одному: попасть внутрь машины мимо сети. Для этого существуют контроллеры IPMI и серийные консоли, и ниже реальный порядок: подключение через Serial over LAN, первичная разведка нагрузки, проверка службы sshd и разбор журналов с поиском виновника.

Пинг проходит но SSH не подключается разграничение уровней проблемы

Ответ на ICMP мало что говорит о здоровье сервера. Эхо-ответ формируется сетевой подсистемой ядра в контексте обработки прерываний, планировщик не участвует, и задыхающийся сервер отвечает на ping до самого конца. Соединение по TCP на порт 22 устроено сложнее: ядро отвечает на SYN само, а вот принять соединение и провести аутентификацию должен процесс sshd. Сценарии разделяются с рабочей машины за минуту:

ping -c 4 10.0.0.5
nc -vz 10.0.0.5 22

Если ping проходит, а nc показывает открытый порт, ядро живо и слушает, но дальше соединение виснет: пользовательские процессы голодают без процессорного времени. Если SYN уходит в пустоту, вариантов больше: не работает сама служба, порт закрыт правилами фильтрации, либо переполнена таблица соединений ядра. Третий вариант, когда соединение устанавливается и рвётся после баннера, намекает на проблемы аутентификации или записи на диск.

Ночной бэкап без лимитов, сборка проекта в контейнере или незнакомый процесс с утилитой сжатия: сценарии, при которых пинг живёт, а ssh молчит, одинаковы по симптомам и различаются только виновником. Латентность пинга при этом честно намекает: если время ответа выросло в разы, прерывания обрабатываются с задержкой, и система стоит на грани.

Вывод из этой разведки скромный, но важный: без входа мимо сети диагноз не поставить. Ни перезагрузка по питанию, ни терпеливое ожидание не дают ответа, кто занял систему. Аппаратный вход нужен до того, как принято решение о перезапуске, потому что после перезапуска улики обычно исчезают.

Подключение через IPMI с активацией консоли Serial over LAN

Контроллер BMC на серверной плате это отдельный мини-компьютер со своим сетевым интерфейсом и питанием от дежурной линии. Он работает, когда операционная система висит, обновляется или выключена. Доступ к нему организуется утилитой ipmitool с админской машины:

ipmitool -I lanplus -H 10.0.0.9 -U admin chassis status
ipmitool -I lanplus -H 10.0.0.9 -U admin sel list

Первая команда покажет питание и общее состояние, вторая откроет журнал событий платы: ошибки памяти ECC, события источников питания, термические срабатывания. Аппаратный журнал нередко отвечает раньше системного, и одна строка про ошибку ECC способна объяснить все странности дня.

Консоль Serial over LAN активируется так:

ipmitool -I lanplus -H 10.0.0.9 -U admin sol activate

На экране появится то, что ядро и служба getty выводят на порт ttyS0: загрузочные сообщения и приглашение входа. Сессия закрывается escape последовательностью из тильды и точки, полный набор последовательностей описан в справке man ipmitool. Перед активацией полезен вывод sol info: он показывает, включён ли SOL на контроллере и на какой скорости работает порт.

Параметр -I lanplus включает протокол RMCP+ с усиленным шифрованием и должен быть выбором по умолчанию: старый режим lan годится только для древних плат. Состояние контроллера читается командой mc info: версия прошивки и производитель BMC полезны при поиске известных проблем конкретных ревизий. Учётная запись с правами operator создаётся подкомандами user set name, user set password и user priv той же утилиты.

Требование к схеме одно: она настраивается заранее. Контроллер получает адрес в сети управления, у пользователя права уровня operator, а скорость порта в BIOS совпадает с параметрами консоли в загрузчике. У сервера без настроенного контроллера остаётся серийный порт на терминальном сервере стойки либо выезд инженера.

Заранее настроенная серийная консоль работает когда сеть бесполезна

Серийная консоль не требует IPMI и спасает даже на скромном железе. Параметры ядра прописываются в загрузчике:

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8"

После правки конфигурация GRUB пересобирается командой grub-mkconfig или grub2-mkconfig, название зависит от дистрибутива. Сообщения ядра пойдут на обе консоли, а приглашение входа на серийную поднимет systemd, который сам создаёт getty для консолей из параметров загрузки; при желании это закрепляется явным включением Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.. Проверяется всё одной перезагрузкой: если в терминале видны строки загрузки и приглашение, запасной вход готов.

Приём работает и в виртуализации: гостевой системе с параметром console=ttyS0 доступна консоль через virsh console с указанием имени домена на хост-машине. Сетевые проблемы гостя в этом случае не мешают диагностике, а вся процедура разведки переносится без изменений.

Смысл подготовки прост: когда служба sshd снята из-за нехватки памяти или застряла, серийная консоль продолжает работать. getty не требует сети и почти не требует ресурсов, а значит, вход сохраняется даже тогда, когда сеть для диагностики бесполезна.

Первые команды после входа оценка нагрузки и дисковых очередей

Задача первых минут не лечение, а оценка масштаба. Порядок первичной разведки из аппаратной консоли обычно такой:

1. посмотреть значения load average в uptime и сравнить их с числом ядер;
2. минуту понаблюдать за vmstat за колонками r us sy wa si so;
3. вывести верхушку процессов по процессору и список задач в состоянии D;
4. проверить память командой free и дисковые очереди через iostat;
5. убедиться что порт 22 слушается просмотром вывода ss -tlnp;
6. открыть журнал sshd и ошибки текущей загрузки в journalctl.

Чтение результатов требует контекста. Load average 80 при 16 ядрах означает очередь к процессору, но очередь в Linux составляют и задачи в непрерываемом ожидании ввода-вывода, поэтому высокий load при пустом процессоре указывает на диск. В vmstat колонка r показывает очередь задач, wa долю ожидания ввода-вывода, si и so интенсивность обмена со страницами подкачки, а st отбираемое гипервизором время. Верхушка процессов, собранная командой ps aux --sort=-%cpu | head -12, обычно называет виновника сразу, а список задач в состоянии D, полученный через ps -eo state,pid,cmd | awk '$1=="D"', показывает, что именно застряло.

Разведочные утилиты запускаются с интервалами:

vmstat 1 5
iostat -x 1 3

Первая строка vmstat показывает средние значения с момента загрузки, поэтому смотреть нужно на последние строки: именно они отражают происходящее сейчас.

Дисковые очереди смотрятся утилитой iostat из пакета sysstat: %util у устройства около ста и await в сотни миллисекунд означают, что накопитель перегружен или деградирует. Команда free дополняет картину: колонка available важнее остальных, и значения около нуля объясняют, почему sshd не успевает ответить на соединения.

Задачи в состоянии D не отвечают на обычные сигналы завершения: снять такой процесс штатно нельзя, пока не завершится операция ввода-вывода или не истечёт её таймаут. По этой причине сервер с деградирующим накопителем рано или поздно доезжает до аппаратной перезагрузки.

Каждая команда разведки читает состояние и ничего не меняет, поэтому список прогоняется целиком, без страха ухудшить ситуацию.

Проверка службы sshd и сетевых портов из локальной консоли

Служба sshd в Debian и Ubuntu называется ssh, в RHEL и родственных дистрибутивах sshd. Статус, прослушиваемые порты и последние строки журнала собираются тремя командами:

systemctl status ssh
ss -tlnp | grep -w 22
journalctl -u ssh -b --no-pager | tail -n 40

Если порт слушается, а соединений нет, причина в нагрузке выше по цепочке. Если строки с портом нет, служба не работает или слушит не тот адрес. Журнал подскажет конкретику: строка Out of memory: Killed process с именем sshd означает, что oom-killer снял службу, а error: fork: Resource temporarily unavailable говорит об упоре в лимит процессов или памяти.

Нюанс со старыми ядрами: sshd мог зависнуть в ожидании энтропии для ключей сессии. В журнале загрузки ищется строка random: crng init done: если её нет, причина в генераторе случайных чисел, и лечится обновлением ядра или настройкой аппаратных источников.

Отдельно проверяется таблица соединений: сообщение nf_conntrack: table full, dropping packet в dmesg означает, что ядро отбрасывает новые соединения, и порт 22 молчит не из-за sshd. Лимит поднимается параметром net.netfilter.nf_conntrack_max, а правила фильтрации просматриваются командой nft list ruleset.

Если виновник ясен и дело в самой службе, она перезапускается командой systemctl restart ssh с немедленной проверкой порта. Перезапуск на перегруженной машине способен подвиснуть, и тогда сначала снимается лишний процесс, а служба поднимается уже после разгрузки.

Если и консоль не отвечает на клавиши, машина зависла глубже пользовательской части. Тогда по серийной линии отправляется BREAK и далее клавиши Magic SysRq в порядке REISUB: сначала дампы задач, потом управляемая перезагрузка с чистыми файловыми системами.

Разбор журнала и аппаратного лога от oom killer до перегрева

Когда машина снова отвечает, начинается связка журналов. Системный журнал показывает последовательность: рост нагрузки, первые записи oom-killer, последнюю службу перед молчанием. Ошибки собираются командой journalctl -b -p err, а хвост прошлой загрузки читается через journalctl -b -1 -e.

Аппаратный журнал BMC читается тем же ipmitool. События перегрева видны в выводе sel list, а по датчикам смотрится sensor list: температура процессора у верхней границы и строки вида Package temperature above threshold, cpu clock throttled в системном журнале складываются в единую картину деградации охлаждения.

До любой перезагрузки журнал текущей загрузки сохраняется на другую машину: команда journalctl -b --no-pager выводит его целиком, а копия уходит на рабочую станцию по scp. После перезапуска картина прошлой загрузки станет неполной, и снятый заранее снимок останется единственным полным источником.

Сопоставление временных меток системного журнала, аппаратного лога и графиков мониторинга отвечает на главный вопрос: был ли это разовый сбой или закономерность. Разовый сбой закрывается перезагрузкой и наблюдением, закономерность требует лимитов ресурсов, замены накопителя или ревизии охлаждения.

Настройка внеочередного доступа чтобы ситуация не повторилась

Инцидент с живым пингом и молчащим SSH заканчивается не перезагрузкой, а ревизией инфраструктуры доступа. Сеть управления для BMC выносится в отдельный сегмент, контроллеры получают статические адреса и свежие прошивки, доступ к ним закрывается правилами фильтрации и не выводится в общие сети.

Системная часть подготовки повторяет классику: постоянный журнал journald, модуль netconsole для доставки сообщений ядра на приёмную машину, аппаратный watchdog со строкой RuntimeWatchdogSec = 30 в /etc/systemd/system.conf, который перезагрузит зависший узел без участия человека.

Метрики BMC отправляются в систему мониторинга, и температура, обороты вентиляторов и события ECC становятся графиками наряду с load average. Это редкий случай, когда одна линия на дашборде экономит ночной выезд.

Часы BMC и операционной системы синхронизируются по одним источникам времени: без этого сопоставление аппаратного лога и системного журнала превращается в работу с секундомером. История метрик при этом хранится достаточно долго, чтобы по ней было видно приближение проблемы за часы.

Пинг это не диагноз, а лишь признак того, что плате хватает питания. Здоровье пользовательской части проверяется только наличием запасного входа, и запасной вход готовится до инцидента, а не во время.