company_banner

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



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

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

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

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


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

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

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

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

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

    Заключение


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

    Вот такие забавные случаи были в нашей практике.
    А с какими сталкивались вы? Добро пожаловать в комментарии.
    Selectel
    151,95
    ИТ-инфраструктура для бизнеса
    Поддержать автора
    Поделиться публикацией

    Комментарии 51

      0

      А расскажите, зачем вообще нужно ограничивать скорость на порту 10Мбит? У вас что, специально для таких случаев гора 10Мбит коммутаторов стоит? :)) По нынешним временам это установка порта в 10Мбит выглядит нелепицей, а поддержка только 100/1000 даже на портах управления не то что бы обычный случай, но ни разу не удивительна.

        +2
        Раз оплачено 10 — то клиент 10 и должен получить
          0

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

            0
            неужели 100мбит на столько дорого обходятся в российких цодах? меня очень мучает этот вопрос, ибо любой забугорный хостинг с арендой сервера предоставляет гигабитный выделенный канал, при этом цена аренды сервера не превышает 5000 рублей. у нас же и 100мбит не везде можно получить выделенные. неужели у нас всё настолько плохо?
            +1
            Выставить 10Base гораздо «дешевле» по ресурсам коммутатора чем настраивать шейпер
              0

              Я знаю. Вопрос в том, зачем вообще резать порт, куда воткнут интерфейс управления, до десятки?

            0
            Прекрасно, не далее как недавно была тема про самосборные сервера: habrahabr.ru/post/340638
            Супермикро как раз из этой серии, на мой взгляд. Траблшутить интересно, а вот когда хочется чтобы все работало как надо — нет.
              +3
              Не соглашусь с Вами. Исходя из собственного опыта работы скажу, что Supermicro почти всегда работает именно так как и положено. Разумеется, присутствуют некоторые особенности, о которых можно узнать только на практике. В целом это достаточно качественное и стабильно работающее железо.
              +4
              Из моего опыта был слот памяти разбитый на том же supermicro, причем по словам коллег, сервер в таком виде, пришел собранный из штатов.
              image
                0
                Поскольку серверные платформы не были оборудованы приводами для чтения CD/DVD дисков, единственным решением проблемы стало интегрирование драйверов непосредственно в дистрибутив операционной системы.
                А как же виртуальные приводы по IPMI?
                  +3
                  Проброс клавиатуры, мыши и виртуальных приводов CD/DVD через IPMI происходит по шине USB, так что установщик все равно выдаст ту же ошибку.
                    0
                    Устанавливать с WDS не пробовали? Иногда удается поставить 7 даже туда, куда с USB и дисков не ставится.
                      0
                      Что такое есть WDS?
                        +1
                        Имеется в виду Windows Deployment Services — служба развертывания ОС Windows по сети, используя PXE.
                  +3
                  Давненько было, сервер Supermicro находился в режиме циклической перезагрузки. До старта операционной системы дело не доходило, перезагрузка происходила сразу после включения. На сервере было два БП под горячую замену. Вынули один из БП, и сервер поднялся. Как оказалось проблема была в одном из БП, и хотя в штатном режиме сервер работает на одном БП при загрузке мат. плата не видела линию 3.3 В на сбойном БП, и перезагружалась.
                    +5
                    DL380 G7 (подозреваю, что эта проблема общая у всех линеек, использующих iLO3 BMC) после пропадания и восстановления внешнего питания не включается. Кнопка питания горит оранжевым, ошибки не индицируются, но и реакция на кнопку отсутствует. Возможна ситуация, когда сервер позже включается, если выдержать длительную паузу (десятки минут) или переподключить внешнее питание. iLO работает, на включение питания через iLO реакции нет, ошибок в SEL и логе iLO нет. При некоторой настойчивости в подключении и отключении внешнего питания сервер включается, инициализируется и отключается с индикацией рандомной ошибки на передней панели — ошибка памяти, ошибка процессора, fan solution not sufficient и проч.

                    Замена блоков питания, платы PD, сброс CMOS, снятие батарейки, полный резет всего путем хитрых комбинацией переключателей результата не дал. Диагноз HP Care — неисправность материнской платы, требуется замена. Сервер заменен, отправлен на склад.

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

                    Итог дальнейших длительных и увлекательных исследований — при любом отключении внешнего питания iLO 3 пишет в NVRAM событие в event log. Если при этом напряжение на батарейке питания CMOS CR2032 ниже 1.9 вольта, эта запись в память вызывает перезаписывание случайных участков NVRAM рандомными данными, хорошо заметное глазом на текстовых полях в BIOS Setup. Замена батарейки на нормальную с выполнением сброса через System Maintenance Switch решает проблему.

                    Эффект верифицирован на трех серверах путем установки в них подсаженной батареи и отключении внешнего питания, результат в виде разложения памяти достигается максимум с пятого захода. У HP есть advisory про программный баг в iLO 1.05 с похожими последствиями, но в описываемом случае iLO было последнее.
                      0
                      Тоже словил такую проблему. Новый построенный дом, новый офис на 1 этаже, частые отключения питания. iLO был 1.05. После нескольких обращений HP-шный инженер приехал и мат.плату заменил. Что это было — до сих пор не знал. Спасибо.
                      0
                      Это обычно происходит в случае использования операционных систем семейства Linux

                      А win разве не создает новое «Подключение по локальной сети 666» если видит новую сетевуху?

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

                      А вот не надо! Не записывается туда ничего при инсталле (по меньшей мере на сегодняшний момент для rhel- и deb- based). Чаще и самого файла-то нет. Но МОЖЕТ быть записано при необходимости. Вот пример типичной директории у Deb7:
                      # ls -la /etc/udev/rules.d/
                      итого 12
                      drwxr-xr-x 2 root root 4096 Окт  6  2014 .
                      drwxr-xr-x 4 root root 4096 Окт  6  2014 ..
                      -rw-r--r-- 1 root root  536 Окт  6  2014 70-persistent-cd.rules
                      

                      А вот — CentOS7:
                      # ls -la /etc/udev/rules.d/
                      итого 12
                      drwxr-xr-x. 2 root root 4096 Июл 26 14:26 .
                      drwxr-xr-x. 3 root root 4096 Июл 26 14:26 ..
                      -rw-r--r--. 1 root root  709 Май 25  2017 70-persistent-ipoib.rules


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

                      Сеть остается работать, но новый интерфейс получает уже новое имя (при условии что кто-то «привязал» старое имя к маку через вышеуказанный файл) и соответственно новые настройки, т.к. настройки IP привязываются именно к имени интерфейса.
                        0
                        А win разве не создает новое «Подключение по локальной сети 666» если видит новую сетевуху?
                        Создаёт.
                        Но политиками можно озаботиться, чтобы расположение сети было не общедоступным, а доменным. Ну и заранее в резервировании DHCP прописать новые маки.
                          0
                          DHCP работает и для варианта с Linux, верно ведь? :)
                            0
                            Не знаю, я не знаком с тонкостями работы сетевого стека на Linux.
                              0
                              Не во всех конфигурациях. Просто на винде на любом новом сетевом интерфейсе по умолчанию включен DHCP. А в линуксе новый сетевой интерфейс по умолчанию ненастроен.
                                0
                                Проверил на стенде на всякий случай :)
                                • При смене мака — Deb и CentOS (при условии чистых правил udev для сети) просто сменили мак у актуального интерфейса оставив настройки (имя интерфейса-то не сменилось)
                                • При запуске новой сетевухи (добавил вторую) — CentOS включил ее и поднял dhcp-клиента, Deb — действительно не поднял новый интерфейс.
                          0
                          del
                            +10
                            Был интересный случай лет 10 назад.
                            Начал народ жаловаться, что не доходит почта до определенных пользователей. Причем конкретное письмо не доходит, а тестовое или любое другое — на ура. Антиспама нет, это было внутри одной организации по WAN каналам. Взял это письмо, отправил — реально висит в очереди, остальные письма добираются. После некоторого сбора информации и сниффинга сети, нашли причину — не доходило до определенных площадок, которые были подключены через VPN одного из провайдеров. В сети было тройное резервирование каналов: туннель через интернет, и два VPN от разных магистральщиков с разными последними милями. Прежде чем обвинять провайдера в непонятно чём, запустили сниффинг проблемной сессии, поняли что бьется TCP пакет внутри VPN, то есть не провайдер… Оказалось что на сетевом оборудовании была аппаратная проблема, которая повреждала сетевые пакеты с определенной последовательностью и удаленная сторона их отбрасывала. А эта последовательность как раз случайно была в этом проблемном письме. Заменили железку — проблема ушла.
                            После этого случая, я уже верю почти во что угодно. :)
                              0
                              Звучит странно.

                              на сетевом оборудовании была аппаратная проблема, которая повреждала сетевые пакеты с определенной последовательностью


                              Сетевые пакеты с определённой последовательностью чего?
                                –1
                                из чего состоят сетевые пакеты? из бит конечно же!
                              0
                              Прошу не называть вентиляторы турбинками, это устройства с принципиально разными задачами.
                                0
                                У меня как раз сейчас непонятный случай. Сервер на Intel Xeon-ах. Но почему то ПО не видит аппаратного AES. Весь bios перерыл, ничего не нашел. Первый раз с таким сталкиваюсь. Ничего не могу понять. Кто знает что делать?
                                  0
                                  Вот тут например описана похожая проблема. Эту опцию не поддерживает материнская плата.
                                    0
                                    Есть предположение, что в процессорах импортируемых в Россию AES-NI заблокирован из-за наших законов. Быстро нагуглилось только это
                                      0
                                      Да, видимо так и есть. А разблокировать безопасно их не получится? Не желательно чтобы такие дорогущие процессоры испортились.
                                    +4
                                    Если сервер (компьютер, ноутбук) не включается, попробуйте сначала отключить питание и нажать кнопку включения. Так вы сбросите напряжение.
                                    После этого опять подключите питание и включите сервер.
                                    Помогало не один раз.
                                      0
                                      Хороший совет, я как раз проблемы с IPMI\ILO так лечил. Было что-то похожее на описанное выше в комментах про dl380g7.
                                        0
                                        Точно, было такое пару раз. ATX блоки питания залипали (уходили защиту?), особенно после выключения света.
                                        +1
                                        Про драйвера для контроллера USB 3.0 знакомая ситуация и парадоксальная одновременно. То есть инсталлятор с этого USB грузится, а дальше не может, потому что для того же USB драйвера нет. А как оно без драйвера сработало? О_0. Когда первый раз увидел тоже словил когнитивный диссонанс. Что мешало и дальше тоже самое сделать для продолжения? USB 2.0 пока еще чаще бывает в наличии и выручает от необходимости потрошения дистрибутивов.
                                        С отсутствием поддержки 10BASE-T увы, приходилось уже сталкиваться, и эта идея при прочтении первая пришла в голову.
                                        Спасибо за статью, сборник таких головоломок с решениями откладывается где-то в дальних уголках памяти и помогает в решении своих неполадок.
                                          +2
                                          Так раньше оно работало в UEFI/mbr/syslinux или какой там загрузчик, а потом управление передаётся winPE, a вот он штатными дровами не умеет 3.0
                                            0
                                            Вот и я о том же. Его наконец уже нужно научить этому. 1 раз и для всех.
                                              +1
                                              Его давно уже научили всему этому. Просто старые дистрибутивы об этом не знают. Десятка установится без каких-либо проблем. 8/8.1 тоже. Как и соответствующие им серверные версии.
                                          0
                                          Коллеги, а кто сталкивался с перепайкой сокета? Есть контакты?
                                            0
                                            10 Мбит/с вполне достаточно для комфортной работы.

                                            Спорное заявление, если учесть, что тот же iDRAC позволяет монтировать ISO (например, для установки системы).
                                            При скорости в 10Мбит — это откровенное издевательство.
                                            Например, ISO Windows Server 2016 (X21-30350) 5750МБ придётся ждать 75 минут. При том что сама по себе установка(с той же USB флешки) занимает меньше 10 минут.
                                              +2
                                              Классно, как сошлись мысли. Я написал об аналогичном опыте, но в траблшутинге сетевых проблем habrahabr.ru/company/flant/blog/343348
                                                0
                                                Не надо стесняться делать RTFM :)
                                                В спеках на Dell PowerVault MD3800i (подходит по описанию) вполне недвусмысленно написано — One 100/1000 Mbps Ethernet connection for out-of-band management of the enclosure (MGMT).
                                                Из собственного опыта. Пользователи жаловались, что иногда система управления телефонным коммутатором «отваливается». Ну как жаловались — они просто шли и переключали на резерв, уже много лет так делали, привыкли. Попросил спеки на управляйку, посмотрел настройки коммутатора… Если производитель сказал, что сетевой порт следует настроить на 10 Мбит полудуплекс, то сделайте именно так. Даже если линк поднялся на автомате на 100 Мбит полный дуплекс и месяцами работает без проблем.
                                                  0
                                                  С проблемой установки Windows 7 из-за USB 3.0 столкнулся этой весной, когда получил партию моноблоков DELL (со встроенным контроллером USB 3.0, USB 2 не было вообще, как выяснилось позднее). После долгих бесплодных попыток установки (перелазил весь UEFI, пробовал подключать разные клавы/мыши) наткнулся на Windows 7 USB 3.0 Creator Utility, бесплатная утилита от Intel, буквально по паре кликов встраивает драйверы в образ винды — только это и помогло.
                                                    0
                                                    Спасибо! Полезно
                                                    0
                                                    Мы как-то соединяли 2 встроенных в материнку сетевухи патчкордом, чтоб Win2012 установился. Выясняли мы, что дело именно в этом, не один день разумеется :)
                                                      0
                                                      По поводу отказа «турбин охлаждения» в серверах HP. Был аналогичный кейс. В итоге решение нашел сам: в BIOS/RBSU есть опция Thermal shutdown (загуглите картинки с точным расположением в разных поколениях серверов). По умолчанию включена. Если ее отключить, автоматической перезагрузки не будет. Ничего паять не надо.
                                                        0

                                                        В статье описана проблема, которая на языке HP называется Fan solution not sufficient, в сервере с двумя процессорами без двух вентилей система не проходит POST. Это фича, т.к. конфигурации с одним процессором поставляются с двумя заглушками вместо двух вентилей, в setup при этом войти не выйдет, т.к. до него инициализация не доходит. BIOS пишет на экран Fan solution not sufficient и шасси отключается.
                                                        Отключать thermal shutdown я бы поостерегся, у нас на одной точке при полном отказе кондиционирования ambient intake sensor в мониторинге через час показывал 60 градусов цельсия...

                                                          0
                                                          Именно поэтому был более простой выход — просто снять один проц и переставить вентиляторы.
                                                            0
                                                            Спасибо за дополнение. С отказом двух вентиляторов не сталкивался. Буду знать.
                                                          0
                                                          Хочу заметить, что все случаи в статье объединяет один бренд серверов (не буду называть какой). Для статистики — в парке из 60 физических серверов. Dell — 50шт (поколения 410\710), HP — 6шт (g6-g8), Supermicro — 2шт (модель не припомню, год 2015). После первой же перезагрузки не поднялся — один из не_буду_называть_бренд.

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

                                                          Самое читаемое