Комментарии 34
Неужели он питался не от батарей, чтобы так все спалило?
Добрый день! Спасибо за вопрос:)
В ЦОДе есть резервное питание от батарей и ДГУ. Что именно произошло на линии питания нам доподлинно неизвестно. Знаем, что были какие-то работы.
Кз до автомата и пофиг что там за батареи выше
Массовое отключение питания и затем включение всех этих нагрузок (мегаватт моментом?) тоже дело не сильно полезное (история в этом году с крупными дата центрами тому пример, на м9 сам пару блоков питания потерял)
Металл пыль в блок питания (мельчайшие частицы, которые занесли с обувью, одеждой)
Это так краткий перечень возможных,по моему мнению,причин
На новой работе углядел выключенный HP DL 380 G какой-то-там. Спрашиваю - почему такая красота не в работе? Выяснилось странное - сервер новый, включается, работает. Но, в течение пары-тройки недель забывает всё, что есть на RAID-массиве. Сначала мелкие сбои, потом ОС еле грузится, в конце имеем просто неформатированные диски.
Фирменный сервер, фирменный RAID-контроллер, фирменные диски от HP (хоть и купленные в другой конторе). Диски и контроллер пробовали менять на запасные - не помогло. В логах системы, raid-контрллера и в iLO чисто; SMART идеален; поверхность дисков, проверенная через MHDD на тестовом стенде, в прекрасном состоянии.
В глубинах HPшного форума в каком-то неофициальном посте выяснилось чудесное. Если у вас эта модель сервера, да с тем самым RAID-контроллером, то диски такие-то (дальше длинный список партнамберов от HP) ставить нельзя и это не лечится. Но если у вас диски (список партнамберов поменьше), то, залив прошивку конкретной версии XX в контроллер и YY (именно такую, не старше и не младше) в диски, комплектующие таки можно подружить.
Мне повезло - у меня были диски из второго списка, так что 15 минут колдунства и в нашем отделении появился могучий сервак, который потом работал без каких-либо замечаний.
ссылочка на тот форум не сохранилась ли случаем?
Ой, добро пожаловать, падаван, вас инициировали в мир замечательных пролаентов. Я на них сидел с пятёрок.
Вы прям как из жизни рассказываете, всё как по писаному, когда внезапно начинает ложиться главный RDP cервер, вообще с бодуна и без причин. Лечится всё это установкой левой прошивки, слитой с правильной правой ссылки на восьмом уровне вложенности на сайте поддержки HP.
О, да, тогда это был мой первый опыт плотного взаимодействия с HP. Начиная от старичков G2 и выше. Потом Dell'ы, SuperMicro...
Сейчас прикоснулся к машинкам попроще - Asus'ы и Gigabyte'ы (банально, взяли то, что было в наличии и укладывалось в бюджет). Так вот, с ними, как не странно, на мой взгляд головняков меньше (банально взяли первую попавшуюся нормальную память и винты/ssd - работает, не взирая на шильдики), но, впрочем, тут я не эксперт - машин немного, статистика пока никакая.
был у нас давно давно сервер hp dl360 gen7, пришёл б.у. из японии как и ещё куча других. все проверки прошёл, работал отлично, накатили систему, развернули софт, пару дней работал без нареканий. и как водится обязательно ночью с субботы на воскресенье прилетает в telegram от zabbix пачка аллертов, сервер выключен. в логах ilo вроде как по питанию, включил удалённо, подежурил часик он работает. так как сервис не самый важный да ещё и зарезервированный другим сервером в соседней стойке ушёл спать. неделю он не давал о себе знать, потом опять ночью с воскресенья на понедельник потух, симптомы те же. в общем мы меняли блоки питания, провода, перевешивали его на другие лучи питания. всё равно раз в ~неделю ± пара дней он вырубался "по питанию". с прода его сняли просто перекинув диски в его точную копию и стали разбираться дальше (больше из спортивного интереса, так как вообще таких пациентов было принято пускать на запчасти канибализируя под задачи собратьев) и за ~3 месяца в нём заменили всё кроме материнки, начиная от прошивок и заканчивая всеми платами, памятью, процами.. малыш не сдавался и раз в какое-то время вырубался. конечно очевидно было что дело в материнке и поставив на него клеймо он был убран в шкаф. спустя пару лет пришёл его собрат с сильно помятым корпусом, вот его кишки и было принято переставить в героя этой истории (как раз живую материнку из мёртвого корпуса в живой корпус с мёртвой материнкой, казалось план идеален) и при перекидывании платы была найдена причина. маленький болтик попавший под материнку который какого-то чёрта раз в неделю закорачивал контакты с обратной стороны платы. без него этот сервер с родной материнкой прослужил ещё порядка трёх лет и возможно до сих пор где-то работает так как ушёл от нас на авито.
какого-то чёрта раз в неделю закорачивал контакты
Видимо, в выходные баба Люба протирала корпуса серверов и они чуть-чуть сдвигались.
Знакомо. Мы как-то в 2006 году ЕМНИП не могли установить на самосборный сервак Windows 2003. И линукс на нём грузился только в консольном режиме, при переходе в GUI - зависал. Заменили БП - не помогло. Потом по очереди убирали совсем(если возможно) или меняли - оперативку, сетевки(они там были внешние), видяху, жесткие диски... Безрезультатно. Начали грешить на материнку, достали ее из корпуса, положили на стол и... винда встала и грузиться начала без проблем. Поставили обратно в корпус - свежеустановленная винда начала виснуть при загрузке.
Что это было - хз, вкрутили в этот корпус другую мать и с ней никаких проблем. Вот такая вот несовместимость(коротило что-то где-то?).
40 минут post? Я просто несерьезным админом был, и серваки в организациях где работал были попроще, вот те самые 300-й серии HP в основном, и какиех-то серьезных кейсов не было с ними никогда. Так вот -- 40 минут, правда?!!!
Добрый день!
Спасибо за ваш вопрос:)
Да, максимальный POST после холодного старта (отключение питания с сервера) занимает порядка 40 минут. И это не придел. Если вспомнить старенькие sun fire 25k или sparc M9000 64 (как выглядит, можно поискать в гугле), на расширенных уровнях диагностики сервер мог запускаться часами. Связано это с расширенной самодиагностикой. В нашем случае не очень помогло, что редкость
Чем больше памяти - тем дольше POST. Условные 16/32 гига, которые в мелких организациях могут встретиться, грузятся быстро, 2-3 минуты. 512 - будет грузиться в 10 раз дольше. А ведь это далеко не лимит по современным меркам крупных компаний...
Сейчас и условный десктоп с 64 гигами DDR5 памяти после холодного старта будет грузиться минут 5 с чёрным экраном во время тренировки памяти.
Так а там разве нельзя скипнуть тест памяти настройкой в биосе?
Скипнуть можно, но задача то была как раз все их пройти)
Может мы о разных вещах говорим? Post - power on self test, самотестирование при включении питания. Длительная процедура полного тестирования памяти обычно выключается в биосе пунктом меню что то типа "fast start enable". Проводится только быстрое тестирование. Обычно по умолчанию только оно и включено.
Полное тестирование памяти при поиске неисправности проводится или из биоса (если там есть встроенные утилиты) или же сторонними утилитами как memtest, например.
Во-первых, в серверах не только память тестируется, но и контроллеры. Во-вторых, цель наоборот не скипать тесты. И вот это "fast boot" как раз нужно отключить, чтобы выполнить полноценное тестирование. Потому что холодный старт обычно - после обслуживания или после аварии, после чего надо полноценно тестировать, а не скипать.
И тестирование выполняется в серверах именно встроенными средствами, а не memtest, который не работает регистровой памятью.
но и контроллеры
Причем тут контроллеры? Они быстро тестируются, о них речь не идет.
нужно отключить,
Не нужно. Показать просто неисправную память сможет и быстрый тест. А если память сбоит, встроенный тест этого не покажет, тут нужно тестирование мемтестом, различными паттернами. Кроме того, мемтест покажет в каком именно месте сбой, можно вычислить сбойную плашку.
который не работает регистровой памятью.
С чего бы это вдруг? Кто вам сказал такую чушь? Для любого запущенного ПО вся память выглядит одинаково. Различия в ее аппаратной реализации никак не влияют на возможность работы с ней.
Тренировка это тестирование, но тестирование - не тренировка
Во время тренировки материнская плата пробует разные комбинации по частотам и таймингам, чтобы найти самую стабильную конфигурацию
Но обычно это не каждый запуск происходит, и только при включении соответствующих функций в UEFI, ест-но
Хотя, возможно, с DDR5 это требование: https://www.crucial.com/support/articles-faq-memory/ddr5-memory-training
пробует разные комбинации по частотам и таймингам
Первый раз такое слышу. Обычно инфа по частотам и таймингам любой памяти берется исключительно из ее spd. Все остальное - колхоз и оверклокинг. Вряд ли на такой критически важной технике производитель будет допускать такие вещи.
Кластер на HP DL380 Gen9, дисковая полка HPE SV3200. Виртуалки потухли и не включаются. Техподдержка индусы и болгары долго выясняли как их стартануть. Ничего не получается, вендор молчит, поддержка забыла пароли на ESXi, в итоге иксы блокируют вход с каждой неверной попыткой добавляя время блокировки. Долгая несмешная история, в конце которой приехал на локацию инженер HPE и выявил в StoreVirtual все мертвые диски. Была какая-то партия, в которой в стоковой прошивке был счетчик, по истечению которого диски умирали. Поскольку диски были из одной партии, там вроде бы даже серийники подряд были, то этот счетчик на всех одновременно и натикал их смерть. До истечения таймера обновление прошивки решило бы проблему.
Классика. Вот поэтому всегда ставлю в рейды диски из разных партий и желательно даже разных вендоров
Для чего вообще нужен такой таймер?
Была какая-то партия, в которой в стоковой прошивке был счетчик, по истечению которого диски умирали.
Фигня какая-то про счетчик. Сигейты с мухой цеце, небось.
Ну почитайте что ли первоисточник - https://support.hpe.com/hpesc/public/docDisplay?docId=a00092491en_us&docLocale=en_US
Bulletin: (Revision) HPE SAS Solid State Drives - Critical Firmware Upgrade Required for Certain HPE SAS Solid State Drive Models to Prevent Drive Failure at 32,768 Hours of Operation ... и тили-тили трали-вали
Тоже HP DL 385 не помню какого уж поколения. По прошествии некоторого количества часов начинает подвисать вплоть до фриза.
Сразу проверили диски - исключили их. Затем стали смотреть в сторону памяти и мамы. Память по все тестам здоровая, мама без перегрева и явных ошибок в ILO. Стали грешить на питание. Заменили по очереди блоки питания, казалось, что сначала помогло, но нет. Затем подкинули маму с аналогичного сервера - и тоже нет. Ситуация почти тупиковая, вендор стал готовить доставку полностью нового сервера.
Я тем временем решил на горячую посидеть с мультиметром и post картами и случайно вышел на след. На шине, куда втыкался HBA адаптер было пониженное напряжение. Но маму и блоки же меняли!? Как так?
Нашёл подозрительно горячий другой контроллер на той же шине и извлек его - напряжение выровнялось. Причем, контроллер был как бы живой и корректно определятся в системе. Не верь программной диагностике :)
Был прикольный кейс один, запомнился. Не с железом связанный, но тоже сбило с толку на какое-то время ))
Работал в большой компании, много локальных пользователей, куча контрагентов-удаленщиков, в том числе и home office. И однажды пришло письмо от рандомного юзера, мол, при удаленном подключении "неожиданно во время работы вышибает рабочий стол, документы ничего не сохраняется". Сами же удаленные юзеры ходили на отдельную RDS ферму в DMZ через гейты-vpn'ы.
Так вот. Юзер пожаловался, написал. Посмотрели логи, ничего такого не нашли, хмыкнули, ответили юзеру "у нас все окей, ежели повторится, пишите снова". Прошла неделя-две. И тот же юзер пишет, снова вышибает у него удаленный рабочий стол только, добавляет уже, происходит это примерно в обед. Что про первый раз вспомнил, что совпало во второй. Снова посмотрели логи, все чисто, ничего не падало, не отваливалось, никаких ошибок, тишина. Да и других жалоб не было в принципе, только вот от него. Пока думали размышляли, спустя какое-то время он же написал и в третий раз. И снова, акцентирует, проблема происходит именно в обед. Непонятно. Систематичность вроде как проявилась, логика еще нет. То ли у нас мистика происходит, то ли у самого юзера.
Попросили прислать фото ошибки, как оно вообще выглядит это "неожиданно вылетает удаленный рабочий стол", может быть сообщение какое высвечивается, разрыв соединения или еще что. Запросили скриншот и стали ждать.
Прислал. На фото отчетливо видно Завершение работы в rdp сеансе o_0
Гостевая ВМ фермы изящно уходит в классический shut down. Все ожидали, кроме этого.
А потом осенило. Месяцем ранее настраивали плановую профилактическую перезагрузку каждого из гипервизоров через определенные 90-120 дней. Шедулер раскидали по календарю, условно раз в неделю перезагружается только один сервер. Другой сервер ребутится на следующей неделе. Третья неделя – третий сервер. И так в ротации. Последующая перезагрузка первого сервера происходила заново через 90-120 дней. Десятки гостевых ВМ RDS фермы, как и прочего остального, были размазаны по гипервизорам, по разным серверам.
Настраивали событие, естественно, на ночь. Около 4 утра по Москве, GMT+3. Удаленный сотрудник же, как в итоге выяснилось, работал с нами с Дальнего востока, чуть ли не на Камчатке. И иногда, не часто, балансировка RDS фермы при первом логине забрасывала юзера (GMT+12) на гостевую ВМ RDS того гипервизора, который под утро по Москве должен уйти в ребут. Время у Дальневосточного юзера как раз и было примерно обед.
Как решили? Добавили планировщик заранее выводящий в RDP сессии виндовое уведомление с просьбой сохранить документы, отдохнуть и попить чай 10 минут. Позже вообще разные дополнительные notification для юзеров взяли за правило хорошего тона.
В сервисной работе нет «слишком невероятных» поломок — есть только те, которые еще не нашли.
Прямо по Стругацким -"Нет событий невозможных, есть маловероятные".
удалено, ответил не в ту ветку
У меня была ситуация, когда сервер Intel после перезагрузки сжигал себе память.Причём при нормальном выключении этого не происходило.Долго с ним разбирались, много памяти сожгли вместе с поставщиком 🙂В результате поменяли материку и даже БП.
Сервер, который не хотел жить