Сервер работать не будете

DNS-сервер не отвечает, интернет пропал и сайты не открываются

У меня пропал интернет (горит желтый восклицательный значок в трее Windows), и в браузере при попытке открыть любую страничку пишется ошибка «Не удается найти DNS-адрес». Не знаю, что делать, как исправить ошибку и вернуть интернет.

Пробовал запустить мастер диагностики сети — но он выдал ошибку, что DNS-сервер не отвечает. Подскажите какое-нибудь решение.

Всем доброго времени суток!

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

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

Что делать с ошибкой «DNS-сервер не отвечает»

ШАГ 1: перезагрузка роутера и компьютера. Запуск диагностики неполадок сети

Как бы банален совет не был, и всё-таки первое, что порекомендую — перезагрузить ноутбук/компьютер и роутер (если он у вас есть (многие провайдеры сейчас при подключении ставят его «автоматически») ).

Чтобы выключить ноутбук -зажмите кнопку питания на 10-15 сек.

👉 Примечание: чтобы перезагрузить Wi-Fi роутер — достаточно отключить его от сети питания на 15-20 сек. Так же для этого дела на корпусе устройства есть спец. кнопка.

После перезагрузки рекомендую запустить диагностику неполадок сетей (часто она решает многие проблемы с доступом к интернету) . 👉 Для запуска диагностики — нажмите правой кнопкой мышки по значку интернета в трее и во всплывшем меню выберите «Диагностика неполадок» (см. скрин ниже) .

Диагностика неполадок сети

Результат диагностики может быть непредсказуемым: в моем случае ошибка вылезла снова (пример на скриншоте ниже) . Но тем не менее, нередко после перезагрузки — сеть начинает работать в нормальном режиме.

Диагностика сети в Windows / снова ошибка!

ШАГ 2: подключите еще какое-нибудь устройство

Если вы используете роутер (маршрутизатор), попробуйте подключить к Wi-Fi сети другое устройство (например, ноутбук, телефон и пр.) .

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

Для проверки, кстати, можно подключить к Wi-Fi сети (скажем) даже обычный телефон. Также можно попробовать отключить маршрутизатор и подключить интернет-кабель напрямую к сетевой карте компьютера.

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

В этом случае, вам скорее всего, нужно будет создать PPPoE-подключение (* зависит от того, как построена сеть вашего Интернет-провайдера) . О том, как создать PPPoE-подключение — можете узнать 👉 в одной из моих статей.

ШАГ 3: корректные ли настройки сети. Автоматическое получение DNS

Переходим к главному!

Чаще всего, проблемы и ошибки, связанные с DNS, возникают из-за неверных (сбившихся) настроек сетевого подключения. Поэтому, предлагаю проверить их в первую очередь!

Чтобы увидеть все сетевые подключения, нажмите WIN+R, введите в строку «Открыть» команду ncpa.cpl и нажмите Enter (как на скрине ниже) .

ncpa.cpl — просмотр всех сетевых подключений

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

Чаще всего это либо «Беспроводное сетевое соединение» (если установлен роутер и создано Wi-Fi соединение, чаще на ноутбуках) , либо «Подключение по локальной сети» (Ethernet) — если ПК подключен к интернету сетевым кабелем.

Далее необходимо выбрать строку «Протокол Интернета версии 4 (TCP/IPv4)» и открыть ее свойства . См. скрин ниже.

Свойства протокола интернета версии 4

Во вкладке «Общие» необходимо задать IP-адрес и DNS-сервера. Здесь могут быть две ситуации:

1. 👉 первая — достаточно поставить ползунки в положения получения IP-адреса и DNS-серверов автоматически (как это у меня на скриншоте ниже) . Кстати, у большинства провайдеров Интернета — так и есть (не создают лишние проблемы пользователю 👌). Но есть исключения, см. ниже;
2. 👉 вторая — необходимо указать конкретный IP-адрес и конкретные DNS-сервера. Что нужно указывать: необходимо смотреть в вашем договоре с Интернет-провайдером (либо уточнять у него) . Если эти данные ввести неверно (либо, если они были изменены) — то интернет у вас работать не будет!

Получить автоматически адреса DNS-серверов

ШАГ 4: попробуйте установить DNS Google

Бывает такое, что у Интернет-провайдеров (чаще всего небольших) глючат DNS-сервера (что не есть хорошо). Понятно, что DNS-сервера от Google быстрее, они бесплатны и намного стабильнее.

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

Как сменить DNS в Windows , и как выбрать наиболее быстрый публичный DNS-сервер.

Если у вас установлен Wi-Fi роутер — то правильнее будет написать так:

192.168.1.1 (либо 192.168.0.1, либо 192.168.10.1 — прописывается IP-адрес роутера) ;

DNS-серверы от Google

ШАГ 5: попытка очистить кэш DNS (и др. параметры) в командной строке

Нередко избавить от ошибки, связанной с DNS, помогает чистка кэша. Сделать это можно из 👉 командной строки, открытой от имени администратора.

Чтобы открыть командную строку с администраторскими правами, нужно:

1. запустить диспетчер задач (сочетание кнопок Ctrl+Shift+Esc или Ctrl+Alt+Del) ;
2. в диспетчере задач нажать файл/новая задача ;
3. и в строку «Открыть» ввести CMD , поставить галочку «Создать задачу с правами администратора» и нажать Enter.

CMD от имени администратора

Далее необходимо поочередно выполнить следующие команды (после каждой из них нужно нажимать на Enter):

1. ipconfig /flushdns
2. ipconfig /registerdns
3. ipconfig /release
4. ipconfig /renew

CMD — вводим поочередно 4 команды

После выполнения этих 4-х команд, перезагрузите компьютер/ноутбук.

ШАГ 6: проверьте службу DNS-клиент — работает ли она в Windows

Также нужно проверить, работает ли служба DNS-клиент в Windows (по умолчанию — она должна работать, но мало ли. ) .

Чтобы это сделать, нажмите сочетание кнопок WIN+R, и введите команду services.msc, нажмите Enter.

Открываем службы — services.msc (универсальный способ)

Далее должно появиться окно со службами в Windows — найдите службу «DNS-клиент» 👇. Ее необходимо открыть (примечание: просто щелкните по ней два раза левой кнопкой мышки) .

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

Запускаем службу, ставим автоматический запуск

После чего перезагрузите ПК.

ШАГ 6: нет драйверов на сетевую карту

Если у вас нет драйверов на сетевую карту (через которую у вас идет соединение с сетью) — то у вас совсем не будет интернета (да и ошибка DNS в этом случае, как правило, появляется не часто. ).

Чтобы узнать, есть ли у вас драйвера на сетевую карту, откройте 👉 диспетчер устройств. Для этого нажмите WIN+R, и введите команду devmgmt.msc.

Запуск диспетчера устройств — devmgmt.msc

Далее посмотрите, нет ли у вас устройств напротив которых горит желтый восклицательный знак (чаще всего, они находятся в разделе «Другие устройства») . Если такие устройства есть — необходимо обновить для них драйвера.

Диспетчер задач — нет драйверов на Ethernet-контроллер (то бишь на сетевую карту)

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

1) Программы для обновления драйверов — лучшие: ТОП 20/рейтинг!

ШАГ 7: правильно ли настроены антивирус и брандмауэр

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

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

Отключение антивируса Avast на 1 час

Поэтому, рекомендация здесь простая — попробуйте на время отключить (или даже удалить) свой антивирус (брандмауэр). Если ошибка перестанет появляется, думаю, стоит сменить антивирус, либо задать в нем оптимальные настройки.

ШАГ 7: обратитесь в поддержку Интернет-провайдера

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

PS 1

Если Интернет-провайдер говорит, что на его стороне все «OK», как вариант, попробуйте восстановить Windows (если есть контрольные точки, на ту дату, когда всё работало) .

О том, как узнать какие точки есть, и как запустить восстановление, можете 👉 узнать в этой статье (статья актуальная для Windows 7/8/10).

PS 2

Если у кого есть альтернативное решение подобной ошибки — чиркните в комментариях пару строк. Заранее благодарю.

Первая публикация: 28.10.2017

• 
• Видео-Монтаж
  Отличное ПО для создания своих первых видеороликов (все действия идут по шагам!).
  Видео сделает даже новичок!

• 
• Ускоритель компьютера
  Программа для очистки Windows от «мусора» (удаляет временные файлы, ускоряет систему, оптимизирует реестр).

Здравствуйте! У меня тоже возникла проблема с подключением к сети интернет. Может Вы сталкивались с этим и подскажите где искать. Есть ноутбук HP, установлена 7-ка с родными драйверами. Дома вай-фай принимает без проблем и каких либо сбоев. До не давнего времени тоже самое было и на работе с бесплатным вай-фай. То есть всё нормально.

Но несколько дней назад на работе мой ноутбук перестал подключатся к этой сети. Сеть он видит, но «невозможно подключится «. Я подумал, что мой вай-фай адаптер накрылся. Приезжаю домой, а к моей сети ноутбук подключается без проблем. На следующий день, на работе не подключение к бесплатной сети повторилось. Это при том, что мои коллеги с телефонами и ноутбуками подключаются к рабочей сети без проблем.

Что я сделал: восстановил свою 7-ку в первоначальное состояние, не помогло. Установил с нуля 10-ку, не помогло. Вернулся обратно на 7-ку и подключил через USB внешний вай-фай адаптер с установкой соответствующих к нему драйверами — и о чудо, я подключён к рабочей сети! Но всё же, не понятно, почему мой встроенный в ноутбук вай-фай адаптер перестал подключаться к рабочей сети, а к домашней подключается без проблем?

Источник

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

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

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

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

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

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

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

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

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

В случае выявления аппаратной проблемы мы переносим диски со сбойного сервера на резервный и, после небольшой перенастройки сетевого оборудования, выполняется запуск сервера в работу. Таким образом данные не теряются, а время простоя не превышает 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, при этом какая-либо аварийная индикация отсутствовала. Контроллер при этом переставал видеть часть дисков и вновь начинал их опознавать только при переподключении по питанию. Вот так один единственный сбойный диск выводил из строя всю серверную платформу.

Заключение

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

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

Источник