Комментарии 51
А расскажите, зачем вообще нужно ограничивать скорость на порту 10Мбит? У вас что, специально для таких случаев гора 10Мбит коммутаторов стоит? :)) По нынешним временам это установка порта в 10Мбит выглядит нелепицей, а поддержка только 100/1000 даже на портах управления не то что бы обычный случай, но ни разу не удивительна.
Раз оплачено 10 — то клиент 10 и должен получить
Судя по тексту статьи, клиент просил не 10, а просто дополнительный порт для управления, а 10 ему втюхали, не позаботившись спецификации оборудования прочитать. Хорошо, один умный инженер нашелся, который не застрял мозгами в далеком прошлом. :)
неужели 100мбит на столько дорого обходятся в российких цодах? меня очень мучает этот вопрос, ибо любой забугорный хостинг с арендой сервера предоставляет гигабитный выделенный канал, при этом цена аренды сервера не превышает 5000 рублей. у нас же и 100мбит не везде можно получить выделенные. неужели у нас всё настолько плохо?
Выставить 10Base гораздо «дешевле» по ресурсам коммутатора чем настраивать шейпер
Прекрасно, не далее как недавно была тема про самосборные сервера: habrahabr.ru/post/340638
Супермикро как раз из этой серии, на мой взгляд. Траблшутить интересно, а вот когда хочется чтобы все работало как надо — нет.
Супермикро как раз из этой серии, на мой взгляд. Траблшутить интересно, а вот когда хочется чтобы все работало как надо — нет.
Из моего опыта был слот памяти разбитый на том же supermicro, причем по словам коллег, сервер в таком виде, пришел собранный из штатов.
Поскольку серверные платформы не были оборудованы приводами для чтения CD/DVD дисков, единственным решением проблемы стало интегрирование драйверов непосредственно в дистрибутив операционной системы.А как же виртуальные приводы по IPMI?
Давненько было, сервер Supermicro находился в режиме циклической перезагрузки. До старта операционной системы дело не доходило, перезагрузка происходила сразу после включения. На сервере было два БП под горячую замену. Вынули один из БП, и сервер поднялся. Как оказалось проблема была в одном из БП, и хотя в штатном режиме сервер работает на одном БП при загрузке мат. плата не видела линию 3.3 В на сбойном БП, и перезагружалась.
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 было последнее.
Замена блоков питания, платы 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 было последнее.
Это обычно происходит в случае использования операционных систем семейства 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 привязываются именно к имени интерфейса.
А win разве не создает новое «Подключение по локальной сети 666» если видит новую сетевуху?Создаёт.
Но политиками можно озаботиться, чтобы расположение сети было не общедоступным, а доменным. Ну и заранее в резервировании DHCP прописать новые маки.
DHCP работает и для варианта с Linux, верно ведь? :)
Не знаю, я не знаком с тонкостями работы сетевого стека на Linux.
Не во всех конфигурациях. Просто на винде на любом новом сетевом интерфейсе по умолчанию включен DHCP. А в линуксе новый сетевой интерфейс по умолчанию ненастроен.
Проверил на стенде на всякий случай :)
- При смене мака — Deb и CentOS (при условии чистых правил udev для сети) просто сменили мак у актуального интерфейса оставив настройки (имя интерфейса-то не сменилось)
- При запуске новой сетевухи (добавил вторую) — CentOS включил ее и поднял dhcp-клиента, Deb — действительно не поднял новый интерфейс.
del
Был интересный случай лет 10 назад.
Начал народ жаловаться, что не доходит почта до определенных пользователей. Причем конкретное письмо не доходит, а тестовое или любое другое — на ура. Антиспама нет, это было внутри одной организации по WAN каналам. Взял это письмо, отправил — реально висит в очереди, остальные письма добираются. После некоторого сбора информации и сниффинга сети, нашли причину — не доходило до определенных площадок, которые были подключены через VPN одного из провайдеров. В сети было тройное резервирование каналов: туннель через интернет, и два VPN от разных магистральщиков с разными последними милями. Прежде чем обвинять провайдера в непонятно чём, запустили сниффинг проблемной сессии, поняли что бьется TCP пакет внутри VPN, то есть не провайдер… Оказалось что на сетевом оборудовании была аппаратная проблема, которая повреждала сетевые пакеты с определенной последовательностью и удаленная сторона их отбрасывала. А эта последовательность как раз случайно была в этом проблемном письме. Заменили железку — проблема ушла.
После этого случая, я уже верю почти во что угодно. :)
Начал народ жаловаться, что не доходит почта до определенных пользователей. Причем конкретное письмо не доходит, а тестовое или любое другое — на ура. Антиспама нет, это было внутри одной организации по WAN каналам. Взял это письмо, отправил — реально висит в очереди, остальные письма добираются. После некоторого сбора информации и сниффинга сети, нашли причину — не доходило до определенных площадок, которые были подключены через VPN одного из провайдеров. В сети было тройное резервирование каналов: туннель через интернет, и два VPN от разных магистральщиков с разными последними милями. Прежде чем обвинять провайдера в непонятно чём, запустили сниффинг проблемной сессии, поняли что бьется TCP пакет внутри VPN, то есть не провайдер… Оказалось что на сетевом оборудовании была аппаратная проблема, которая повреждала сетевые пакеты с определенной последовательностью и удаленная сторона их отбрасывала. А эта последовательность как раз случайно была в этом проблемном письме. Заменили железку — проблема ушла.
После этого случая, я уже верю почти во что угодно. :)
Прошу не называть вентиляторы турбинками, это устройства с принципиально разными задачами.
У меня как раз сейчас непонятный случай. Сервер на Intel Xeon-ах. Но почему то ПО не видит аппаратного AES. Весь bios перерыл, ничего не нашел. Первый раз с таким сталкиваюсь. Ничего не могу понять. Кто знает что делать?
Если сервер (компьютер, ноутбук) не включается, попробуйте сначала отключить питание и нажать кнопку включения. Так вы сбросите напряжение.
После этого опять подключите питание и включите сервер.
Помогало не один раз.
После этого опять подключите питание и включите сервер.
Помогало не один раз.
Про драйвера для контроллера USB 3.0 знакомая ситуация и парадоксальная одновременно. То есть инсталлятор с этого USB грузится, а дальше не может, потому что для того же USB драйвера нет. А как оно без драйвера сработало? О_0. Когда первый раз увидел тоже словил когнитивный диссонанс. Что мешало и дальше тоже самое сделать для продолжения? USB 2.0 пока еще чаще бывает в наличии и выручает от необходимости потрошения дистрибутивов.
С отсутствием поддержки 10BASE-T увы, приходилось уже сталкиваться, и эта идея при прочтении первая пришла в голову.
Спасибо за статью, сборник таких головоломок с решениями откладывается где-то в дальних уголках памяти и помогает в решении своих неполадок.
С отсутствием поддержки 10BASE-T увы, приходилось уже сталкиваться, и эта идея при прочтении первая пришла в голову.
Спасибо за статью, сборник таких головоломок с решениями откладывается где-то в дальних уголках памяти и помогает в решении своих неполадок.
Коллеги, а кто сталкивался с перепайкой сокета? Есть контакты?
10 Мбит/с вполне достаточно для комфортной работы.
Спорное заявление, если учесть, что тот же iDRAC позволяет монтировать ISO (например, для установки системы).
При скорости в 10Мбит — это откровенное издевательство.
Например, ISO Windows Server 2016 (X21-30350) 5750МБ придётся ждать 75 минут. При том что сама по себе установка(с той же USB флешки) занимает меньше 10 минут.
Классно, как сошлись мысли. Я написал об аналогичном опыте, но в траблшутинге сетевых проблем habrahabr.ru/company/flant/blog/343348
Не надо стесняться делать RTFM :)
В спеках на Dell PowerVault MD3800i (подходит по описанию) вполне недвусмысленно написано — One 100/1000 Mbps Ethernet connection for out-of-band management of the enclosure (MGMT).
Из собственного опыта. Пользователи жаловались, что иногда система управления телефонным коммутатором «отваливается». Ну как жаловались — они просто шли и переключали на резерв, уже много лет так делали, привыкли. Попросил спеки на управляйку, посмотрел настройки коммутатора… Если производитель сказал, что сетевой порт следует настроить на 10 Мбит полудуплекс, то сделайте именно так. Даже если линк поднялся на автомате на 100 Мбит полный дуплекс и месяцами работает без проблем.
В спеках на Dell PowerVault MD3800i (подходит по описанию) вполне недвусмысленно написано — One 100/1000 Mbps Ethernet connection for out-of-band management of the enclosure (MGMT).
Из собственного опыта. Пользователи жаловались, что иногда система управления телефонным коммутатором «отваливается». Ну как жаловались — они просто шли и переключали на резерв, уже много лет так делали, привыкли. Попросил спеки на управляйку, посмотрел настройки коммутатора… Если производитель сказал, что сетевой порт следует настроить на 10 Мбит полудуплекс, то сделайте именно так. Даже если линк поднялся на автомате на 100 Мбит полный дуплекс и месяцами работает без проблем.
С проблемой установки Windows 7 из-за USB 3.0 столкнулся этой весной, когда получил партию моноблоков DELL (со встроенным контроллером USB 3.0, USB 2 не было вообще, как выяснилось позднее). После долгих бесплодных попыток установки (перелазил весь UEFI, пробовал подключать разные клавы/мыши) наткнулся на Windows 7 USB 3.0 Creator Utility, бесплатная утилита от Intel, буквально по паре кликов встраивает драйверы в образ винды — только это и помогло.
Мы как-то соединяли 2 встроенных в материнку сетевухи патчкордом, чтоб Win2012 установился. Выясняли мы, что дело именно в этом, не один день разумеется :)
По поводу отказа «турбин охлаждения» в серверах HP. Был аналогичный кейс. В итоге решение нашел сам: в BIOS/RBSU есть опция Thermal shutdown (загуглите картинки с точным расположением в разных поколениях серверов). По умолчанию включена. Если ее отключить, автоматической перезагрузки не будет. Ничего паять не надо.
В статье описана проблема, которая на языке HP называется Fan solution not sufficient, в сервере с двумя процессорами без двух вентилей система не проходит POST. Это фича, т.к. конфигурации с одним процессором поставляются с двумя заглушками вместо двух вентилей, в setup при этом войти не выйдет, т.к. до него инициализация не доходит. BIOS пишет на экран Fan solution not sufficient и шасси отключается.
Отключать thermal shutdown я бы поостерегся, у нас на одной точке при полном отказе кондиционирования ambient intake sensor в мониторинге через час показывал 60 градусов цельсия...
Хочу заметить, что все случаи в статье объединяет один бренд серверов (не буду называть какой). Для статистики — в парке из 60 физических серверов. Dell — 50шт (поколения 410\710), HP — 6шт (g6-g8), Supermicro — 2шт (модель не припомню, год 2015). После первой же перезагрузки не поднялся — один из не_буду_называть_бренд.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нетривиальные случаи работы с серверами