Несмотря на возросшую надежность техники и ПО, случается и такое, что системным администраторам приходится засучить рукава и начинать разбираться почему же не работает сервер.

Огромная неопределенность таиться в словах не работает. Чтобы локализовать проблему фирма IBM для своих сервисных инженеров предлагает набор из шести последовательных состояний в которых может находиться сервер:

1. Нет напряжения на входе блока питания.

2. Нет напряжения на выходе блока питания.

3. Сервер не проходит POST.

4. Операционная система не начинает загрузку.

5. Операционная система не может завершить загрузку.

6. В процессе работы возникают сбои операционной системы.

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

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

Применим вышесказанное на практике.

№1 и 2. Тестером проверяем напряжение на входе и на выходе БП. Если со входом все ясно, то с выходом на системную плату могут быть варианты - читаем документацию по соответствующим разъемам. Напряжение на выходе с БП проверяем, отсоединив его от системной платы, а затем в подключенном состоянии. Это позволит сделать вывод о наличии короткого замыкания на системной плате из-за которого срабатывает защита БП.

Переходим к пункту №3. Источник информации сообщения BIOS на экране и звуковые сигналы, а также различные индикаторы. Часть из них расположена на системной плате или платах различных контроллеров, внутри корпуса сервера. Если причина не установлена, попробуйте запустить системную плату в "чистом виде", только с процессором и памятью.

Вполне вероятно, вы прийдете к выводу, что требуется замена системной платы. Тут вы почувствуете зачем нужна виртуализация ОС и регулярное архивирование.

№4 - BIOS завершила POST с одиночным звуковым сигналом, а загрузка ОС не начинается.

Первым делом проверим доступность загрузочного устройства через BIOS и убедимся, что оно установлено первым в списке на загрузку.

А то ведь как бывает. Стоит себе сервер, в дисководе наполовину вставлена дискета. Кто и зачем ее вставил никто уже не знает и не помнит. Дотошный системный администратор решает посмотреть, что там такое есть. Вставляет, смотрит - ничего интересного. Тут его дергают по срочному делу... вобщем дискета так в дисководе и остается. Проходит еще год, поменялся администратор, дискету снаружи не видно, о ней не знает никто. Наступает момент, когда требуется перезагрузка. Начинается интересное, сервер после перезагрузки не отвечает. Когда все методы удаленной диагностики ни к чему не приводят, администратор идет в серверную. И видит ошибку non-system disk. К этому моменту нервы уже взвинчены звонками пользователей и начальства, начинается паника...

Лирическое отступление закончено. Дальнейшая диагностика заключается в проверке всех компонентов первоначальной загрузки компьютера. Которая может выполняться через стандартную BIOS или через UEFI. В обоих случаях потребуется загрузка с внешнего устройства. А вот наборы используемого ПО будут разные.

Случай номер 5. ОС начинает, но не может завершить загрузку. Все больше убеждаюсь, что начинать всегда надо с проверки устройства на котором расположена ОС. Проверяем аппаратный уровень: смотрим атрибуты SMART и выполняем посекторное чтение диска. Если ошибок не обнаружено, проверяем целостность файловой системы и файлов ОС.

Информацию для дальнейших размышлений можно получить из blue screen в Windows и panic messages в Linux, а также лог файлов ОС (журналы событий, аварийные дампы памяти и т.д.) и приложений. Так как система не может завершить загрузку, потребуется загрузка с внешнего устройства. Возможно получится загрузиться в безопасном режиме (ядро с минимальным набором драйверов и служб).

При анализе причин шестого состояния используються те же источники информации, что и в пятом. Это различные логи операционной системы и приложений. Доступ к ним облегчен и выполняется средствами самой ОС, не требуя загрузки с внешних устройств.

Решение любой проблемы это сбор и анализ информации. Желательно чтобы источников было два и больше и выводы сделанные по первому можно было подтвердить данными второго. Только когда проблема четко определена, можно приступать к ее решению.

Попытки действовать наугад приведут к большому количеству ошибок, что неприемлимо для информационной системы предприятия. Кроме того, в этом случае вы не будете уверены, что применили наиболее правильное решение.