Pull to refresh

Comments 50

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


А как вы убеждаетесь, что пишете именно у шпинделя, например? Контроллер диска же не выдаёт наружу данные о реальной геометрии. Или я чего-то не знаю? Можно этот вопрос раскрыть поподробнее?

Мы исходим из предположения что геометрия линейна и сектора в начале и конце диска находятся на центро круговых концах блина. Я согласен с вами что возможны варианты. Но в нашем мире обычно усе одинакого, мы считаем что извращенцев не существует.

Насколько я понимаю, тестирование памяти загружается по TFTP — что мешает выгрузить итог тестирования на тот-же TFTP в виде файла?
По-идее, TFTP влезает на флешку внутри сетевухи, вместе со всем сетевым стеком, включая DHCP, BOOTP, PXE?

Возможно хороший вариант. Но к сожалению загрузка в два этапа pxe и tftp и потом Ос заного просит ип у dhcp и заного настраивает сетевой стек. В версии ос memtest нет сетевого стека или мы его не нашли. Это мое видение процесса ге берусь утверждать что оно на 100% верное. Готов менять мнение глядя на факты. :)

Есть еще история с дешифрованием кода энигмы, который был перехвачен из подлодки в 45-ом. Ребятам тоже нужны вычислительные мощи)
В 2013 году вытащили следующее
Today around 02:30 GMT+2 ThrasherX-17 from team Keep The Fire Alive! returned the plaintext of 76 letters long FNYG MXHU message:

leitungvvvuuustuetzpktxwwwhavenxxfffttteunszwozwovierhuermitvrrhhhvvvgeloest

The message says:
«AN LEITUNG VON U BOOT STUETZPUNKT WILHELMSHAVEN: FUNKTELEGRAMM EINS ZWO ZWO VIER HIER MIT RHV GELOEST»

Which translates to:

"[To] Control from Submarine Base Wilhelmshaven: Radio message 1224 solved with RHV"


www.enigmaathome.net

А так же список проектов, которым бы вы тоже могли помогать.
boinc.berkeley.edu/projects.php
«После этого остается у RAID проверить батарейку. Кто не знает — батарейки на RAID хватает, чтобы все диски еще 2 часа покрутить. То есть ты выключаешь сервер, вынимаешь, а он еще 2 часа вращает диск, чтобы завершить все записи.»

чё, правда штоле? :-) а можно точную модель такого рейда и размеры батарейки привести??

лёгкая недосказанность — харды не от батарейки крутятся, просто RAID контроллер хранит в себе открытые сессии записи и дописывает их, даже когда система тушится -)

Не берусь утверждать откуда иммено ток на хардах. Я практик, запускаешь долгую операцию на хардах. Гасишь сервер открываешь и замечаешь шум и вибрацию от хардов. У нас их обычно не более 4. Батарейка была как от первых сотовых телефонов. Возможно чуть больше.

Это шедеврально. :)))
Нет конечно, 2 часа память рейда сохраняется. Если свет дадут — кеш будет сброшен на диски.
Тоже удивила эта строчка. Просьба к автору предоставить пруфы.
Я не автор, и пруфов у меня нет, но…
Кэш — это оперативная память на котроллере, для сохранения данных в ней ей требуется постоянное питание и батарейка именно это питание и обеспечивает. Однако, если батарейка разрядится, то данные пропадут, хотя программа их писавшая будет уверена в обратном — ей отчитался контролер что всё записано — но по факту на диски данные так и не попали.
Есть и ещё один вариант, но там не батарейка используется, а суперконденсатор, т.к. необходимый промежуток работы после выключения известен. В этом случае питание нужно для полного копирования кэш-памяти из оперативной памяти на накопитель с энергонезависимой памятью. Дальше питание может отсутствовать сколь угодно долго, при возобновлении питания, все данные возвращаются в кэш-память и, в дальнейшем, попадают-таки на диски.
вы наверное не догадываетесь, но все, кто имел дело с рейдом всерьёз, о бекапе кеша батарейкой, ионистором, флешем — знают. я, как и другие спрашивающие, был поражен заявлением, что диски (ну фигня-же, что они совсем по другой линии, не относящейся к контроллеру, запитаны, да?) крутятся у него 2 часа. все 12 штук. от батарейки смартфона. ладно, ошибся человек, бывает. закроем тему.
UFO just landed and posted this here

Длина окружности с края больше.

UFO just landed and posted this here
У меня как-то возникла бредовая мысль, а почему бы для подобных проверок не использовать софт для юнит-тестирования? Ну типа пишешь юнит тесты, раскидываешь ассерты, а потом запускаешь. Если отработало без ошибок — тестирование завершено. Если с ошибками — вот отчет чего сломалось. Не то чтобы прям кардинально меняет ситуацию, но прикольно. Наверное можно с другими дев-инструментами как-то объединить. Пробовал написать просто набор теста на адекватность сервера, в принципе не сложно получилось.
Надеялся что для Memtest есть какие нибудь альтернативы, по аналогии с процессором и простыми числами.

Просто иногда попадал в ситуации, когда система работает с трудом, постоянно BSODы, memtest — OK! Но стоит пошевелить планки, поменять местами — все начинает работать. Мистика, в итоге решил что наверное кроме самих ячеек есть еще какие то операции-инструкции процессора-памяти которые можно было бы проверить под нагрузкой
Memtest по-хорошему надо сутки гонять или около того.
Это для обывателей, когда памяти 4-8-16 гиг край. А если у вас 256?

Есть и другой момент. Сервера все поголовно с ECC, что там поймает мемтест? Выдает ли ECC наружу какую диагностику?

У меня после полугода работы пара планок ecc памяти начало сыпать ошибками. Выяснили когда zfs начала ругаться на неверные контрольные суммы файлов. Проверка на memtest показывала ошибки.

ECC не всесильна, она корректирует единичную ошибку, от случайной флуктуации, от космических лучей. Вот и интересно, есть счетчик где нибудь этих ошибок?
Есть такой, в винде это вроде бы журнал WHEA.
В линуксе что то тоже должно быть. Механизм как раз служит для замены сбойной памяти до того как сбои сказываются на работе.
А проверять ECC память мемтестом как то не очень похоже на выбор который бы сделал профессионал.
В IPMI сыпет ошибки вида Correctable ECC @ DIMM2A CPU2 — Asserted
Т.е во время теста мемтестом, даже если сам мемтест не покажет ошибки, в логах IPMI вы их уведите
На имеющемся у меня древнем серваке в БИОС присутствует Лог Событий Памяти, где в случае проблем с памятью появляются соотв. записи.
А какая разница? Так можно и стресс-тесты на 15 секунд запускать — ой, ничего не упало, значит все хорошо.
Уважающее себя железо даёт посмотреть, что с ним происходит. В логе IPMI/iLO есть записи о корректируемых ошибках памяти. Не припомню, чтобы видел некорректируемые, впрочем. В Linux есть такой github.com/andikleen/mcelog, который умеет это всё доставать и писать в лог. В /sys/ тоже есть данные EDAC (вот пример использования), и их оттуда можно читать и передавать в ваш любимый мониторинг. Только отличное от 0 значение в uncorrectable errors я тоже никогда не видел, и даже в свое время смотрел в ядре, почему так, но не помню точной причины.
пишут, что /dev/mcelog (через который работает одноимённая программа) deprecated

"Выдает ли ECC наружу какую диагностику?" - Event Log в IPMI

Пользуюсь вот такой штукой github.com/stressapptest/stressapptest в моих случаях гораздо эффективнее мемтеста, если мемтест надо часами крутить прежде чем ошибку найти, то тут хватает и 10 минут на аналогичное, уж не знаю что за конкретная магия там внутри )
При тестировании дисков ещё надо замерять latency, чтобы исключить проблемы на шине контроллера. Это когда диск пишет со скоростью 250 МБ/с в один поток, но с latency в 1.5 секунды.
UFO just landed and posted this here
1. 60 мегабайт от 32 Гигабайт это 0,2%, а не 2%.
2. У жесткого диска, в отличие от компакт-диска, запись идет от края внутрь, соответственно и максимальная скорость падает по мере записи.
Кто не знает — батарейки на RAID хватает, чтобы все диски еще 2 часа покрутить. То есть ты выключаешь сервер, вынимаешь, а он еще 2 часа вращает диск, чтобы завершить все записи.
Понятно.
Кто не знает — батарейки на RAID хватает, чтобы все диски еще 2 часа покрутить. То есть ты выключаешь сервер, вынимаешь, а он еще 2 часа вращает диск, чтобы завершить все записи.
Вы это серьезно? После этих слов ко всей статье начинаешь относиться как к чисто маркетинговой…
Для сведения: BBU — Battery Backup Unit (Модуль Резервной Батареи). BBU обеспечивает батарейную защиту питания для кэша контроллера RAID. В случае сбоя питания, BBU поможет сохранить данные в кэше.
На сегодня это 2 юнита, в которые может поместиться либо 12 узлов однопроцессорных серверов, либо 4 узла двухпроцессорных серверов.

12 серверов — 3U
Утилита /bin/stress.

/usr/bin/stress
убивает down killer

OOM killer
Раньше было 3 производителя: Adaptec; 3ware; Intel. У нас было 3 утилиты, мы заморачивались, но проводили диагностику для всех. Сейчас LSI купил всех — осталась одна утилита.

Intel и был LSI

Тема контроллеров hp smartarray не раскрыта!
А вообще с замечаниями согласен. Именно они мне и бросились в глаза. Часть, предполагаю, возникла при расшифровке доклада, корректура не проводилась. А вот часть, обидно, получилась из-за ляпов уже в самом

так и lsi с adaptec'ом вроде не сливались, или я что-то пропустил?

P.S. «BBU крутит диски два часа», «LSI купил всех производителей RAID, в том числе и Intel» — может это просто стёб?
А чего не крипту майнить для проверки ЦПУ?
Я не знаю как достоверно проверить что она правильно майнится. В целом я не против :)

Прочитал с большим удовольствием.
У вас интересная работа.

Используете ли вы какой-нибудь фреймворк для сбора/хранения/отображения информации (серийные номера памяти, ЦПУ, HDD, SSD, где какие модули установлены)?

У вас запуск этих утилит автоматизирован или человек запускает их вручную?

Ваш любимый Linux — этой стандарный Linux или кастомный?
Исторически сложилось что в качестве базы для всего этого используется DCIManager от компании ISPsystem. Различным надстройками и хуками вокруг него запускаем все эти крипты.
А где вы храните информацию из dmidecode, других утилит?
Если да, то как вы отправляете эту информацию в автоматическом режиме?
DCImgr слушает http. Изнутри diag linux скрипта зовется curl с post data. Хранится все в dcimgr, Он это просто в базе хранит. Парсится потом отдельной задачкой.
Большинство серверов, которые не прошли проверку, мы просто выкидываем.
да? куда выкидываете? где забирать? :)
Only those users with full accounts are able to leave comments. Log in, please.