Как настроить сервер чтобы он не выдавал ошибок

Проблемы с сервером — что делать?

Как могут выглядеть типичные сбои сервера:

• сервер вообще не запускается
• проблема с загрузкой сервера — сервер запускается, но показывает “синий экран смерти” (BSOD)
• сервер запускается, на нем загружается операционная система, но некоторые сервисы не работают (например, сайт)
• произошел сбой связи с сервером по сети
• сервер сильно нагревается при работе
• постоянные перезагрузки без видимых причин
• заметно падает скорость выполнения операций

Причины сбоя и поломок сервера, типичные неисправности:

• Физическое отключение — вероятнее всего, причиной неисправности серверов являются проблемы с аппаратной частью или пропало электричество. В первом случае понадобится ремонт или замена отказавшей детали, быстро исправить это вряд ли получится. Во втором попробуйте сначала загрузить/перезагрузить сервер, когда электричество появится — есть шансы, что его работоспособность восстановится.
• Сервер запускается, но находится не в сети, клиентские приложения пытаются к нему подключиться и выдают ошибку подключения к серверу — неожиданная проблема связи с сервером может возникнуть из-за неполадок в сетевой карте сервера или из-за неправильных сетевых настроек (неправильный IP-адрес, маска подсети, шлюз, проблема в сетевых протоколах). Также есть возможность, что ошибка соединения с сервером вызвана неисправностью сетевого кабеля или другого сетевого оборудования — роутера/свитча/хаба.
• Причиной отключения сервера может быть поломка одной из комплектующих, согласно статистике, чаще всего “летят” жесткие диски HDD, материнские платы, адаптеры, процессоры.
• Ошибки в конфигурации — многие типичные неисправности сервера являются прямым следствием ошибок в его настройке, для их устранения понадобится помощь квалифицированного системного администратора.
• Причиной сбоя сервера может быть перегрузка системы, вызванная внутренними процессами, например, активностью пользователей или неудачно настроенным снятием резервных копий, или DOS/DDOS-атакой снаружи.
• Запуск сервера и сбой запуска? Возможно, в этом виновен перегрев сервера.

Как устранить и предотвратить проблемы с сервером

Предотвратить поломки сервера значительно проще и дешевле, чем устранять, когда они уже проявились.

Вот несколько требований, выполняя которые вы сможете снизить вероятность отказа вашего сервера:

• Если у вас собственная серверная, организуйте в ней качественное охлаждение и старайтесь держать ее всегда закрытой, чтобы туда не проникала лишняя пыль. Обязательно используйте источники бесперебойного питания.
• Регулярно проводите профилактическое обслуживание серверов — чистку от пыли, замену термопасты и т.д.
• Используйте специализированное ПО для мониторинга, чтобы отслеживать состояние сервера и вовремя заметить проблемы работы сервера.
• У вас обязательно должно быть настроено резервное копирование и восстановление данных сервера, чтобы предотвратить потерю важной информации в случае, если сервер все же “упадет”. Регулярно делайте бекапы, а если есть возможность — используйте отказоустойчивый кластер, тогда при сбоях в работе сервера его работа будет распределена между остальными серверами в кластере.

Если несмотря на все предпринятые меры у вас все же возникли проблемы с сервером, что делать?

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

• Просмотреть логи событий сервера — возможно, по ним удастся понять причину неполадок.
• Физически осмотреть комплектующие сервера, иногда их поломки бывают заметны визуально.
• Если это возможно, запустить тест памяти.
• Запустить проверку жестких дисков на наличие ошибок.
• Проверить сервер антивирусом. Это может помочь в устранении неисправностей файлового сервера, часто такие неисправности являются результатом работы вредоносного ПО.
• Проверить загрузку процессора, состояние памяти, использование дискового пространства с помощью специализированного ПО.

Срочный ремонт серверов, что можно сделать

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

Например, неквалифицированная попытка восстановить данные может вместо этого окончательно их уничтожить.

Обслуживание серверов

Инженеры ГК «Интегрус» уже много лет занимаются сервисным обслуживанием и ремонтом серверов, к нам всегда можно обратиться за бесплатной консультацией, аудитом, а если понадобится — то и за срочным ремонтом серверов.

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

Источник

Что такое ошибка сервера

21 ноября 2017 Опубликовано в разделах: Азбука терминов. 48468

Больше видео на нашем канале — изучайте интернет-маркетинг с SEMANTICA

У вас кончилась еда. Нужно идти в магазин за продуктами. На дверях табличка — “Учет”. Вы без продуктов.

Пользователь хочет зайти на сайт. На сервер направляется запрос. И если на сервере какие-то проблемы, то человек увидит сообщение об ошибке в окне браузера.

Какие есть ошибки сервера

Как мы выяснили, внутренние ошибки сервера составляют класс состояний HTTP.

• 500. Обозначает широкий спектр серверных ошибок, если они не относятся к нижеперечисленным проблемам рассматриваемого класса.
• 501. Означает, что сервер не обладает необходимыми возможностями для совершения обработки пользовательского запроса. Как правило, ошибка 501 появляется в тех случаях, когда сервер не может распознать метод запроса. Если сервер распознал метод запроса, но он не может быть использован на данном интернет ресурсе отображается ошибка 405 (произошла по вине пользователя).
• 502 (Bad Gateway). Возникает в тех случаях, когда сервер выполняет функцию прокси-сервера или шлюза. Ошибка говорит о том, что вышестоящий сервер отправляет недействительный ответ.
• 503. Отображается при невозможности обработки пользовательских запросов сайтом. Это может быть обусловлено перегрузкой, неполадками в обслуживании, техническими неполадками и так далее. Чаще всего при отображении ошибки 503 в поле Retry-After указывается время, когда пользователю необходимо повторить запрос.
• 504. Здесь опять сервер выполняет функцию шлюза или прокси сервера. Он перенаправляет запрос вышестоящему серверу, но не дожидается ответа, следовательно, не может завершить обработку запроса.
• 505. Означает, что версия запроса не поддерживается сервером.
• 506. Это значит, что текущий вариант сервера имеет ошибочную конфигурацию. В связи с этим процесс связывания не доходит до завершения и все время обрывается.
• 507. Чтобы закончить запрос и обработать его, на сервере нет места. Проблемы подобного рода могут быть временными и легко устранимыми.
• 509. Если интернет ресурс потратил весь трафик, который был отведен ему, возникает данная ошибка. Для решения проблемы необходимо обратиться к провайдеру хостинга .
• 510. Данную ошибку можно встретить в тех случаях, когда клиент делает запрос и хочет использовать определенное расширение, однако сервер не использует и не может предоставить данное расширение.
• 511. Данная ошибка идет не от самого сервера, к которому обращается пользователь, а от посредника, в роли которого может выступать провайдер. Как правило, проблема возникает, когда клиенту необходимо авторизоваться в глобальной сети (указать пароль от платной точки доступа). При этом в форме ответа отображается специальное поле для выполнения авторизации.
• 520. Говорит о том, что есть ошибка, однако сервер сети доставки содержимого не может правильно обработать ее и отобразить клиенту.
• 521. Возникает в ситуациях, кода сервер отклоняет подключение сети доставки содержимого.
• 522. Отображается, если система передачи данных не может подключиться к серверу, истекает время ожидания серверного ответа.
• 523. Сервер нельзя «достичь», при обращении к серверу возникают серьезные препятствия, преодоление которого на данный момент не является возможным.
• 524. Истекло время подключения необходимого сервера и сервера сети доставки содержимого.
• 525. Если в процессе рукопожатия самого сервера и сервера сети доставки содержимого возникают ошибки, отображается код 525.
• 526. Означает, что на данный момент нет возможности подтвердить сертификат шифрования.

Что делать, если пишут “Ошибка сервера”

Перечисленные ошибки, как правило, возникают из-за файла .htaccess, тем оформления и плагинов. Рассмотрим варианты решения проблемы.

Итак, вам понравилась новая тема оформления и вы ее установили. Все бы хорошо, но после возникает внутренняя проблема сервера. Для восстановления работоспособности сервера выбираем один из способов действия:

Через FTP

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

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

Через PhpMyAdmin

Если вами была удалена/отредактирована стандартная тема, ее нужно скачать и установить заново. Это можно сделать со следующих ресурсов: TwentyTen, TwentyEleven, TwentyTwelve. После скачивания открываем PhpMyAdmin, затем базу данных.

Перейдите во вкладку SQL и скопируйте в нее код, представленный ниже.

Обратите внимание, что название темы должно быть указано правильно. Затем сайт заработает в обычном режиме.

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

1. Открываем FTP ресурса.
2. Открываем папку с имеющимися плагинами.
3. Удаляем/изменяем имя/редактируем плагин.

Если ошибки заключаются в неполадках файла .htaccess, необходимо сделать следующее:

1. Открываем FTP-клиент FileZilla, меню «Сервер» и ставим флажок напротив пункта «Отображать скрытые файлы принудительно». Обновляем перечень файлов и находим наш файл .htaccess.

2. Открываем файл через блокнот/текстовый редактор. Перед вами отображается текст- перечь указаний и правил для функционирования веб сервера. Просмотрите файл и ликвидируйте ошибки. Альтернативный вариант — удалить файл полностью, а затем написать с помощью WordPress новый файл (откройте администраторскую панель, далее «Параметры», затем «Постоянные ссылки». Выберите нужный вариант, нажмите «Сохранить»).

Если перечисленные мероприятия не дали должного результата, необходимо обратиться к квалифицированному программисту.

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

Специалисты студии SEMANTICA проведут комплексный анализ сайта по следующему плану:

– Технический аудит.
– Оптимизация.
– Коммерческие факторы.
– Внешние факторы.

Мы не просто говорим, в чем проблемы. Мы помогаем их решить

Источник

Нетривиальные случаи работы с серверами

Любое оборудование, в том числе и серверное, иногда начинает работать непредсказуемо. Абсолютно не важно — новое ли это оборудование, или же оно уже несколько лет работает с полной нагрузкой.

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

Ниже мы расскажем о некоторых интересных и нетривиальных случаях.

Обнаружение неполадок

Регистрация проблемы чаще всего происходит после обращения клиентов в службу технической поддержки посредством тикет-системы.

В случае обращения клиента, который арендует у нас выделенные серверы фиксированной конфигурации, мы проводим диагностику, чтобы выяснить, что проблема не носит программный характер.

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

Если становится ясно, что проблема аппаратная (например, сервер не видит часть оперативной памяти), то на этот случай у нас всегда есть в резерве аналогичная серверная платформа.

В случае выявления аппаратной проблемы мы переносим диски со сбойного сервера на резервный и, после небольшой перенастройки сетевого оборудования, выполняется запуск сервера в работу. Таким образом данные не теряются, а время простоя не превышает 20 минут с момента обращения.

Примеры неполадок и способы их устранения

Сбой в работе сети на сервере

Существует вероятность, что после переноса дисков со сбойного сервера на резервный перестанет работать сеть на сервере. Это обычно происходит в случае использования операционных систем семейства Linux, например Debian или Ubuntu.

Дело в том, что при первоначальной установке операционной системы, MAC-адреса сетевых карт записываются в специальный файл, расположенный по адресу: /etc/udev/rules.d/70-persistent-net.rules.

При старте операционной системы этот файл сопоставляет имена интерфейсов MAC-адресам. При замене сервера на резервный, MAC-адреса сетевых интерфейсов уже не совпадают, что и приводит к неработоспособности сети на сервере.

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

Операционная система, не найдя этого файла, автоматически сгенерирует аналогичный и сопоставит интерфейсы уже с новыми MAC-адресами сетевых карт.

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

Плавающая проблема с зависаниями

Однажды к нам на диагностику поступил сервер с проблемой случайных зависаний в процессе работы. Проверили логи BIOS и IPMI — пусто, никаких ошибок. Поставили на стресс-тестирование, нагрузив все ядра процессора на 100%, с одновременным контролем температуры — завис намертво через 30 минут работы.

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

Далее следовало исключить вероятные сбои модулей оперативной памяти, поэтому поставили сервер на тест памяти с помощью достаточно популярного Memtest86+. Минут через 20 сервер ожидаемо завис, выдав ошибки по одному из модулей оперативной памяти.

Заменив модуль на новый, мы поставили сервер на тест повторно, однако нас ждало фиаско — сервер вновь завис, выдав ошибки уже по другому модулю ОЗУ. Заменили и его. Еще один тест — еще раз завис, вновь выдав ошибки по оперативной памяти. Внимательный осмотр слотов ОЗУ не выявил никаких дефектов.

Оставался один возможный виновник проблемы — центральный процессор. Дело в том, что контроллер оперативной памяти расположен именно внутри процессора и именно он мог давать сбой.

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

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

Мнимое зависание сервера при установке ОС

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

К нам обратился пользователь с жалобой на зависание сервера при попытке установки операционной системы Windows Server 2008 R2. После успешного запуска инсталлятора, сервер прекращал реагировать на мышь и клавиатуру в KVM-консоли. Для локализации проблемы подключили к серверу физическую мышь и клавиатуру — все то же самое, инсталлятор запускается и перестает реагировать на устройства ввода.

На тот момент этот сервер у нас был одним из первых на базе материнской платы X11SSL-f производства Supermicro. В настройках BIOS был один интересный пункт Windows 7 install, выставленный в Disable. Поскольку Windows 7, 2008 и 2008 R2 разворачиваются на одном и том же инсталляторе, выставили этот параметр в Enable и чудесным образом мышь и клавиатура наконец-то заработали. Но это было лишь только начало эпопеи с установкой операционной системы.

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

Википедия сообщила, что проблема решается отключением в BIOS поддержки USB 3.0 (XHCI-контроллера). Когда мы открыли документацию к материнской плате, нас ожидал сюрприз — разработчики решили полностью отказаться от контроллера EHCI (Enhanced Host Controller Interface) в пользу XHCI (eXtensible Host Controller Interface). Иными словами, все порты USB на этой материнской плате являются портами USB 3.0. И если отключить контроллер XHCI, то мы этим самым отключим и устройства ввода, сделав невозможным работу с сервером и соответственно установку операционной системы.

Поскольку серверные платформы не были оборудованы приводами для чтения CD/DVD дисков, единственным решением проблемы стало интегрирование драйверов непосредственно в дистрибутив операционной системы. Только интегрировав драйвера контроллера USB 3.0 и пересобрав установочный образ, мы смогли установить Windows Server 2008 R2 на этот сервер, а этот случай вошел в нашу базу знаний, чтобы инженеры не тратили лишнее время на бесплодные попытки.

Интересная особенность Dell PowerVault

Еще забавнее бывают случаи, когда клиенты привозят нам оборудование на размещение, а оно ведет себя не так, как ожидается. Именно так и произошло с дисковой полкой линейки Dell PowerVault.

Устройство представляет собой систему хранения данных c двумя дисковыми контроллерами и сетевыми интерфейсами для работы по протоколу iSCSI. Помимо этих интерфейсов присутствует MGMT-порт для удаленного управления.

Среди наших услуг для размещенного оборудования как раз есть специальная услуга «Дополнительный порт 10 Мбит/с», которую заказывают в случае необходимости подключения средств удаленного управления сервером. Эти средства носят разные названия:

• «iLO» у Hewlett-Packard;
• «iDrac» у Dell;
• IPMI у Supermicro.

Функционал у них приблизительно одинаков — мониторинг состояния сервера и доступ к удаленной консоли. Соответственно большая скорость канала им не требуется — 10 Мбит/с вполне достаточно для комфортной работы. Именно эта услуга и была заказана клиентом. Мы проложили соответствующую медную кроссировку, и настроили порт нашего сетевого оборудования.

Для ограничения скорости порт просто настраивается как 10BASE-T и включается в работу, имея максимальную скорость в 10 Мбит/с. После того, как все было готово — мы подключили MGMT-порт дисковой полки, но клиент почти сразу сообщил, что у него ничего не работает.

Проверив состояние порта коммутатора, мы обнаружили неприятную надпись «Physical link is down». Такая надпись говорит, что имеется проблем с физическим соединением между коммутатором и подключенным в него клиентским оборудованием.

Плохо обжатый коннектор, сломанный разъем, перебитые жилы в кабеле — вот небольшой перечень проблем, которые приводят именно к отсутствию линка. Разумеется, наши инженеры сразу взяли тестер витой пары и проверили соединение. Все жилы идеально прозванивались, оба конца кабеля были обжаты идеально. К тому же, включив в этот кабель тестовый ноутбук, мы получили как и положено соединение со скоростью 10 Мбит/с. Стало ясно, что проблема на стороне оборудования клиента.

Поскольку мы всегда стараемся помочь нашим клиентам в решении проблем, решили разобраться, что именно вызывает отсутствие линка. Внимательно изучили разъем порта MGMT — все в порядке.

Нашли на сайте производителя оригинальную инструкцию по эксплуатации, чтобы уточнить — возможно ли со стороны программного обеспечения «погасить» данный порт. Однако такой возможности не предусматривалось — порт в любом случае поднимался автоматически. Несмотря на то, что подобное оборудование должно всегда поддерживать Auto-MDI(X) — иными словами правильно определять какой кабель включен: обычный или кроссовер, мы эксперимента ради обжали кроссовер и включили в тот же порт коммутатора. Пробовали принудительно выставлять параметр дуплекса на порту коммутатора. Эффект был нулевой — линка не было и идеи уже заканчивались.

Тут кто-то из инженеров высказал абсолютно противоречащее здравому смыслу предположение, что оборудование не поддерживает 10BASE-T и будет работать только на 100BASE-TX или даже на 1000BASE-X. Обычно любой порт, даже на самом дешевом устройстве совместим с 10BASE-T и вначале предположение инженера отмели как “фантастику”, но от безысходности решили попробовать переключить порт в 100BASE-TX.

Нашему удивлению не было предела, линк мгновенно поднялся. Чем именно обусловлено отсутствие поддержки 10BASE-T на порту MGMT остается загадкой. Такой случай — очень большая редкость, но имеет место быть.

Клиент был удивлен не меньше нашего и очень благодарил за решение проблемы. Соответственно ему так и оставили порт в 100BASE-TX, ограничив скорость на порту непосредственно с помощью встроенного механизма ограничения скорости.

Отказ турбин охлаждения

Как-то раз к нам приехал клиент, попросил снять сервер и вынести его в сервисную зону. Инженеры все сделали и оставили его наедине с оборудованием. Прошел час, второй, третий — клиент все время запускал/останавливал сервер и мы поинтересовались, в чем же заключается проблема.

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

Решили клиенту помочь следующим образом. Обычно сервер понимает, что с вентилятором охлаждения все хорошо, просто считывая количество оборотов. При этом, разумеется, инженеры Hewlett-Packard сделали все, чтобы нельзя было заменить оригинальную турбинку аналогом — нестандартный коннектор, нестандартная распиновка.

Оригинал такой детали стоит около $100 и ее нельзя просто так пойти и купить — надо заказывать из-за рубежа. Благо в интернете обнаружили схему с оригинальной распиновкой и выяснили, что один из пинов как раз отвечает за считывание количества оборотов двигателя в секунду.

Дальнейшее было делом техники — взяли пару проводов для прототипирования (волей случая оказались под рукой — некоторые наши инженеры увлекаются Arduino) и просто соединили пины от соседних рабочих турбинок с коннекторами вышедших из строя. Сервер запустился и клиенту наконец-то удалось выполнить миграцию виртуальных машин и запустить сервисы в работу.

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

А где же диски?

В некоторых случаях причина проблемы порой настолько нетривиальна, что на ее поиск уходит очень большое количество времени. Так и получилось, когда один из наших клиентов пожаловался на случайный отвал дисков и зависание сервера. Аппаратная платформа — Supermicro в корпусе 847 (форм-фактора 4U) с корзинами для подключения 36-ти дисков. В сервере было установлено три одинаковых RAID-контроллера Adaptec, к каждому подключено по 12 дисков. В момент возникновения проблемы, сервер переставал видеть случайное количество дисков и зависал. Сервер вывели из продакшн и приступили к диагностике.

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

Через две недели снова обращение с той же проблемой. Было решено заменить контроллер на аналогичный. Выполнили, прошили, подключили, поставили на тесты. Проблема осталась — через пару дней выпали все диски уже на новом контроллере и сервер благополучно завис.

Переустановили контроллер в другой слот, заменили бэкплейн и SATA-кабели от контроллера до бэкплейна. Неделя тестов и снова диски выпали — сервер вновь завис. Обращение в поддержку Adaptec результатов не принесло — они проверили все три контроллера и проблем не обнаружили. Заменили материнскую плату, пересобрав платформу чуть ли не с нуля. Все, что вызывало малейшие сомнения заменили на новое. И проблема вновь проявилась. Мистика да и только.

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

Заключение

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

Вот такие забавные случаи были в нашей практике.
А с какими сталкивались вы? Добро пожаловать в комментарии.

Источник