Железо не подведет. Как я готовлю к бою десятки серверов в день

    Проверить один сервер — не проблема. Берешь чек-лист и по порядку проверяешь: процессор, память, диски. Но с сотней серверов такой способ вряд ли хорошо сработает. Чтобы исключить человеческий фактор, сделать проверки более надежными и быстрыми, надо автоматизировать процесс. Кому знать, как это лучше сделать, как не хостинг-провайдеру. Артём Артемьев на HighLoad++ Siberia рассказал, какие методы можно использовать, что лучше запускать руками, а что отлично получается автоматизировать. Далее текстовая версия доклада с советами, которые сможет повторить каждый, кто работает с железом и нуждается в регулярной проверке его работоспособности.



    О спикере: Артём Артемьев (artemirk) технический директор в большом хостинг-провайдере FirstVDS, сам работает с железом.

    У FirstVDS есть два дата-центра. Первый — собственный, сами построили свое здание, привезли и поставили свои стойки, сами обслуживают, переживают за ток и охлаждение дата-центра. Второй дата-центр — это большая комната в большом ЦОДе снятая в аренду, с ней все проще, но она тоже есть. Суммарно это 60 стоек и порядка 3000 железных серверов. Было на чем потренироваться и проверить разные подходы, значит нас ждут практически подтвержденные рекомендации. Приступим к просмотру или чтению доклада.


    Примерно 6-7 лет назад мы поняли, что просто поставить операционную систему на сервер недостаточно. ОС стоит, сервер бодр и готов к бою. Запускаем его на продакшен — начинаются непонятные перезагрузки и зависания. Что делать, непонятно — процесс идет, перевести целиком рабочий проект на новую железяку — это тяжело, дорого, больно. Куда бежать?

    Современные методы деплоя позволяют этого избежать и перевозить сервер за 5 секунд, но наши клиенты (тем более 6 лет назад) точно не летали в облаках, ходили по земле и использовали обычные железяки.



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

    В чем проблема?


    По идее, проверить сервер — не проблема. Изначально у нас был процесс, как на картинке ниже. Садится человек, берет чек-лист, проверяет: процессор, память, диски, морщит лоб, принимает решение.



    Тогда в месяц устанавливалось 3 сервера. Но, когда серверов становится все больше и больше, этот человек начинает плакать и жаловаться, что он гибнет на работе. Человек все чаще ошибается, потому что проверка превратилась в рутину.

    Мы приняли решение: автоматизируем! А человек будет заниматься более полезными вещами.

    Небольшая экскурсия




    Уточню, что я имею в виду, когда я говорю о сервере сегодня. Мы, как и все, экономим место в стойках и используем серверы высокой плотности. На сегодня это 2 юнита, в которые может поместиться либо 12 узлов однопроцессорных серверов, либо 4 узла двухпроцессорных серверов. То есть каждому серверу достается по 4 диска — всё по-честному. Плюс в стойке два блока питания, то есть всё резервировано и всем нравится.

    Откуда железо?


    Железо к нам в дата-центр привозят наши поставщики — как правило, это Supermicro и Intel. В дата-центре наши ребята-операторы, устанавливают серверы в свободное место в стойке и подключают два проводка, сеть и питание. Также в обязанности операторов входит настроить BIOS в сервере. То есть подключить клавиатуру, монитор и настроить два параметра: Restore on AC/Power Loss — [Power On], чтобы сервер включался всегда, как только появляется питание. Он должен работать без остановок. Второе First boot device — [PXE], то есть первый загрузочный девайс мы ставим в сеть, иначе не сможем достучаться до сервера, так как не факт, что в нем есть сразу диски и т.д.



    После этого оператор открывает панель учета железных серверов, в которой нужно зафиксировать факт установки сервера, для чего указывается:

    • стойка;
    • наклейка;
    • порты сети;
    • порты питания;
    • номер юнита.

    После этого порт сети, куда оператор поставил новый сервер, с целью безопасности переходит в специальный карантинный VLAN, на котором к тому же висит DHCP, Pxe, TFtp. Далее на сервере загружается наш любимый Linux, в котором есть все необходимые утилиты, и запускается процесс диагностики.

    Так как у сервера все еще остается первый загрузочный девайс по сети, то у серверов, которые уходят в продакшен, порт переключается на другой VLAN. В другом VLAN нет DHCP, и мы не боимся, что мы свой продакшен-сервер нечаянно переустановим. Для этого у нас предусмотрен отдельный VLAN.

    Бывает так, что сервер поставили, все хорошо, но он в систему диагностики так и не загрузился. Случается это, как правило, из-за того, что при задержке переключения VLAN не все сетевые свичи быстро переключают VLAN и т.д.



    Тогда оператор получает задачу на перезагрузку сервера руками. Раньше не было IPMI, мы ставили удаленные розетки и фиксировали, в каком порту розетки сервер, дергали розетку по сети, и сервер перезагружался.

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

    Если после этого сервер не загрузился, то он заносится в специальный список на починку. В этот список попадают серверы, на которых не запустилась диагностика, или ее результаты оказались не удовлетворительными. Отдельный человек — который любит железо — каждый день сидит и разбирает—собирает, смотрит, почему не работает.

    Процессор


    Все хорошо, сервер запустился, начинаем тестировать. Первым тестируем процессор, как один из самых важных элементов.



    Первым порывом было использовать приложение от вендора. У нас почти все процессоры Intel — зашли на сайт, скачали Intel Processor Diagnostic Tool — все хорошо, показывает много интересной информации, в том числе наработку сервера в часах и график потребления питания.

    Но проблема в том, что Intel PTD работает под Windows, что нам уже не понравилось. Чтобы запустить в нем проверку, нужно просто подвести мышку, нажать кнопку «СТАРТ», и начнется проверка. Результат выводится на экран, но нет возможности его куда-либо экспортировать. Это нам не подходит, потому что процесс не автоматизируется.



    Пошли читать форумы и нашли два самых простых способа.

    1. Вечный цикл cat/dev/zero > /dev/null. Можно проверить в top — 100% одно ядро потребляется. Считаем количество ядер, запускаем нужное количество cat/dev/zero, умножаемое на нужное количество ядер. Все отлично работает!
    2. Утилита /bin/stress. Она строит матрицы в памяти и начинает их постоянно переворачивать. Тоже все хорошо — процессор греется, нагрузка есть.

    Отдаем серверы в продакшен, возвращаются пользователи и говорят, что процессор нестабилен. Проверили — процессор нестабилен. Стали расследовать, взяли сервер, который проверки проходит, но в бою падает, включили в Linux ядре debug, собрали Core dump. Сервер перед перезагрузкой сбрасывает в файлик все, что было в памяти перед падением.



    В процессоры встраивают различные оптимизации для частых операций. Мы можем посмотреть флаги отражающие, какие оптимизации процессор поддерживает, например, оптимизации работы с числами с плавающей запятой, оптимизации мультимедиа и т.д. Но наша /bin/stress, и вечный цикл просто прожигают процессор одной операцией и не используют дополнительные возможности. Расследование показало, что CPU падает при попытке использовать функциональность одного из встроенных флагов.

    Первым порывом было оставить /bin/stress — пусть греет процессор. Потом в цикле пробежим по всем флагам, дернем их. Пока думали, как это реализовать, какие команды вызвать, чтобы вызвать функции каждого флага, читали форумы.

    На форуме оверклокеров наткнулись на интересный проект по поиску простых чисел Great Internet Mersenne Prime Search. Ученые сделали распределенную сеть, к которой каждый может подключиться и помочь найти простое число. Ученые никому не верят, поэтому программка работает очень хитро: сначала ты ее запускаешь, она просчитывает простые числа, которые она уже знает, и сравнивает результат с тем, что ей известно. Если результат не совпадает, то значит процессор работает неправильно. Это свойство нам очень понравилось: при любой ерунде она склонна к падению.

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

    Mprime не имеет ограничения по времени, если не остановить — работает вечно. Мы запускаем ее на 30 минут.

    /usr/bin/timeout 30m /opt/mprime -t
    /bin/grep -i error /root/result.txt
    

    После завершения работы проверяем, чтобы в result.txt не было ошибок, и смотрим логи ядра, в частности в файле /proc/kmsg ищем ошибки.

    Еще экскурсия




    3 января 2018 года нашли 50-е простое число Мерсенна (2p-1). В этом числе всего 23 миллиона цифр. Его можно скачать, чтобы посмотреть, — это zip-архив 12 Мб.

    Для чего нам нужны простые числа? Во-первых, любое RSA-шифрование использует простые числа. Чем больше простых чисел мы знаем, тем надежнее ваш SSH ключ. Во-вторых, ученые проверяют свои гипотезы и математические теоремы, а мы не против помогать ученым — нам это ничего не стоит. Получается win-win история.



    Итак, процессор работает, все хорошо. Осталось выяснить, что это за процессор. Используем dmidecode -t processor и видим все слоты, которые есть в материнской плате, и какие процессоры стоят в этих слотах. Эта информация поступает в нашу систему учета, интерпретировать ее будем позже.

    Улов


    Таким образом, на удивление можно найти сломанные ноги. /bin/stress и вечный цикл отработали, а Mprime упал. Долго гоняли, искали, открыли — результат на картинке ниже — тут все понятно.



    Такой процессор просто не запустился. Оператор был очень сильный, взял не тот процессор — но поставить смог.



    Еще один прекрасный случай. Черный ряд на фотографии ниже — это вентиляторы, стрелка показывает, как дует воздух. Видим: радиатор стоит поперек потока. Конечно, все перегрелось и отключилось.



    Память


    С памятью все довольно просто. Это ячейки, в которые мы записываем информацию, а через некоторое время снова ее читаем. Если там осталось то же, что мы записали, то данная ячейка исправна.



    Всем известна хорошая, прямо классическая, программа Memtest86+, которая запускается с любого носителя, по сети или даже с флоппи-диска. Она сделана для того, чтобы проверить как можно больше ячеек памяти. Любые занятые ячейки проверить уже нельзя. Поэтому memtest86+ имеет минимальный размер чтобы не занимать память. К сожалению, memtest86+ отображает свою статистику только на экран. Мы пытались ее как-то расширить, но все уперлось в то, что внутри программы даже нет сетевого стека. Чтобы ее расширить, нужно было бы с собой притащить Linux-ядро и все остальное.

    Есть платная версия этой программы, которая уже умеет скидывать информацию на диск. Но на наших серверах не всегда есть диск, и не всегда есть файловая система на этих дисках. А сетевой диск, как мы уже выяснили, подключить нельзя.

    Мы стали копать дальше и нашли похожую программу Memtester. Эта программа работает с уровня ОС из Linux. Самый большой ее минус в том, что сама ОС и Memtester занимают какие-то ячейки памяти, и эти ячейки не будут проверяться.

    Memtester запускается командой: memtester `cat /proc/meminfo |grep MemFree | awk ’{print $2-1024}’`k 5

    Здесь мы передаем количество свободной памяти минус 1 Мб. Это сделано так, потому что иначе Memtester занимает всю память, и его убивает down killer. Гоняем этот тест 5 циклов, на выходе имеем табличку либо с ОК, либо fail.

    Stuck Address ok
    Random Value ok
    Compare XOR ok
    Compare SUB ok
    Compare MUL ok
    Compare DIV ok
    Compare OR ok
    Compare AND ok


    Итоговый результат сохраняем и дальше анализируем на предмет провалов.



    Для понимания масштабов проблемы — у нас самый маленький сервер имеет 32 Гб памяти, наш образ Linux c Memtester занимает 60 Мб, 2% памяти мы не проверяем. Но по статистике за последние 6 лет такого, что в продакшен попала откровенно битая память, не было. Это тот компромисс, на который мы согласны, и который нам дорого исправить — так и живем с ним.

    По пути собираем также dmidecode -t memory, который отдает все банки памяти, которые у нас есть на материнской плате (обычно их до 24 штук), и какие плашки стоят в каждом банке. Эта информация пригодится, если захотим проапгрейдить сервер — будем знать, куда что можно добавить, сколько планок взять и к какому серверу пойти.

    Устройства хранения


    6 лет назад все диски были с блинами, которые крутились. Отдельная история была собрать просто список всех дисков. Было несколько разных подходов, поскольку не верилось, что можно просто ls /dev/sd посмотреть. Но в итоге остановились, что смотрим ls /dev/sd* и ls /dev/cciss/c0d*. В первом случае это SATA девайс, во втором — SCSI и SAS.



    Буквально в этом году начали продавать nvme-диски и добавили сюда nvme list.

    После того, как собран список дисков, мы пытаемся с него прочитать 0 байт, чтобы понять, что это блочное устройство и все хорошо. Если не смогли прочитать, то считаем, что это какое-то приведение, и такого диска у нас нет и никогда не было.

    Первым подходом к проверке дисков было очевидное: «Давайте на диск запишем случайные данные и посмотрим скорость» — dd -o nocache -o direct if=/dev/urandom of=${disk}. Как правило, блиновые диски выдают 130-150 Мбайт/с. Мы, прищурив глаз, для себя решили, что 90 Мбайт/с — это та цифра, после которой идут исправные диски, все, что меньше — неисправные.

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



    Есть угловая скорость, и, как правило, когда запускаешь -dd, он пишет возле шпинделя. Если по каким-то причинам скорость шпинделя деградировала, то это менее заметно, чем если писать с краю диска.

    Пришлось поменять принцип проверки. Теперь мы проверяем в трех местах: возле шпинделя, посерединке и снаружи. Наверное, можно проверять только снаружи, но так уж у нас исторически сложилось. А, что работает, не трогаем.

    Можно использовать smartctl, чтобы спросить у диска, как у него дела. Мы считаем, что у хорошего диска:

    • Нет Reallocated секторов (Reallocated Sectors Count = 0), то есть все секторы, что вышли с завода, работают.
    • Мы не используем диски старше 4 лет, хотя они вполне рабочие. До того, как мы ввели эту практику, у нас были диски и по 7 лет. Сейчас мы считаем, что после 4 лет диск окупился, и мы не готовы принимать риск износа.
    • Нет секторов, которые собираются быть Reallocated ( Current_Pending_Sector = 0).
    • UltraDMA CRC Error Count = 0 — это ошибки на SATA-шлейфе. Если ошибка есть, надо просто поменять провод, менять диск не нужно.



    Распространившиеся SSD — вообще прекрасные диски, работают быстро, не шумят, не греются. Мы считаем, что хороший SSD имеет скорость записи больше 200 Мбайт/с. Наши клиенты любят невысокие цены, и к нам не всегда попадают серверные модели, которые выдают 320-350 Mбайт/с.

    Для SSD мы так же смотрим smartctl. Те же Reallocated, Power_On_Hours, Current_Pending_Sector. Все SSD-диски умеют отображать степень износа, ее показывает параметр Media_Wearout_Indicator. Мы истираем диски до 5% жизни, и только потом вынимаем. Такие диски иногда находят вторую жизнь в личных нуждах сотрудников. Например, недавно я узнал, что за 2 года такой диск истерся еще на 1% в ноутбуке сотрудника, хотя у нас он под SSD-кэшем примерно за 10 месяцев истирает 95%.

    Но проблема в том, что не все производители дисков договорились о названиях параметра, и этот Media_Wearout_Indicator, например, у Toshiba называется Percent_Lifetime_Used, у других производителей Wear Leveling Count, Percent Lifetime Remaining, либо просто .*wear.*.

    У Crucial вообще нет этого параметра. Тогда мы просто считаем объем перезаписи диска — «byte writed» — сколько байт мы на этот диск уже записали. Далее по спецификации пытаемся выяснить на сколько перезаписей этот диск рассчитан производителем. Элементарной математикой определяем, сколько он еще проживет. Если пора менять — меняем.

    RAID


    Я не знаю, почему в современном мире наши клиенты все еще хотят RAID’ы. Люди покупают RAID, ставят туда 4 SSD, которые сильно быстрее этого RAID’а (6 Гбит). У них есть какая-то инструкция, и они по ней собирают. Я считаю, что это почти ненужная штука.

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

    Когда наша система диагностики видит RAID, она разбирает логический том на отдельные диски, чтобы можно было померить скорость каждого диска, почитать его Smart. После этого остается у RAID проверить батарейку. Кто не знает — батарейки на RAID хватает, чтобы все диски еще 2 часа покрутить. То есть ты выключаешь сервер, вынимаешь, а он еще 2 часа вращает диск, чтобы завершить все записи.

    Сеть


    С сетью у нас все довольно просто — внутри дата-центра должно быть на меньше 300 Мбит. Если меньше, то надо чинить. Также смотрим ошибки на интерфейсе. Ошибок на сетевом интерфейсе быть не должно совсем, и если они есть, то все плохо.



    По пути стараемся обновить BIOS и IPMI firmware. Оказалось, что мы не все BIOS’ы любим. У нас еще есть BIOS’ы, которые не умеют UEFI и другие фичи, которые мы используем. Стараемся обновить его автоматически, но это не всегда получается, там все не очень просто. Если не получается, то человек идет и руками обновляет.

    IPMI Supermicro мы не отдаем в мир, у нас он на серых адресах через OpenVPN. Тем не менее мы опасаемся, что однажды вылезут очередные уязвимости и мы пострадаем. Поэтому стараемся, чтобы просто прошивка IPMI была всегда последняя. Если это не так, то обновляем.

    Из странного недавно вылезло что Intel на 10 и 40-гигабитных сетевых картах не включает PXE загрузку. Оказывается, если сервер находится в стойке, в которой есть только 40-гигабитная карта, то невозможно загрузиться по сети, потому что надо грузиться в гигабитную карточку. Мы отдельно прошиваем сетевые карты на 40G, чтобы у них появилось PXE и можно было дальше жить.

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



    Итого у нас проводится примерно 350 проверок в месяц, 69% серверов исправны, 31% — не исправны. Это связано с тем, что у нас богатая история, некоторые серверы стоят уже по 10 лет. Большинство серверов, которые не прошли проверку, мы просто выкидываем.

    Для любознательных: у нас есть 3 клиента, которые все еще живут на Pentium IV, и не хотят никуда уезжать. Им хватает 512 Мб оперативной памяти.

    Будущее пришло! Если бы я городил эту систему сегодня…



    Вышла прекрасная утилита Hardware Lister (lshw), которая умеет общаться с ядром, красиво отображать, какое железо есть в ядре, что ядро смогло определить. Не нужны все эти пляски. Если будете повторять — настойчиво советую посмотреть на эту утилиту и использовать ее. Все станет сильно проще.

    Итоги:


    • Компромиссы — это не плохо, это всего лишь вопрос цены. Если решение очень дорогое, надо искать уровень, когда и надежность, и цена приемлемая.
    • Непрофильные программы порой классно подходят для тестирования. Остается их только найти.
    • Тестируйте все, до чего дотянетесь!

    Следующий большой HighLoad++ уже 8 и 9 ноября в Москве. В программе известные специалисты и новые имена, традиционные и новые задачи. В секции DevOps, например, уже приняты:


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

    Конференции Олега Бунина (Онтико)

    576,00

    Конференции Олега Бунина

    Поделиться публикацией

    Похожие публикации

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


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

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

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

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

          0
          Есть еще история с дешифрованием кода энигмы, который был перехвачен из подлодки в 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
            0
            «После этого остается у RAID проверить батарейку. Кто не знает — батарейки на RAID хватает, чтобы все диски еще 2 часа покрутить. То есть ты выключаешь сервер, вынимаешь, а он еще 2 часа вращает диск, чтобы завершить все записи.»

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

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

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

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

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

                      +4
                      Правильно, потому скорость чтения будет больше, ибо линейная скорость будет больше у края, чем у центра
                    0
                    У меня как-то возникла бредовая мысль, а почему бы для подобных проверок не использовать софт для юнит-тестирования? Ну типа пишешь юнит тесты, раскидываешь ассерты, а потом запускаешь. Если отработало без ошибок — тестирование завершено. Если с ошибками — вот отчет чего сломалось. Не то чтобы прям кардинально меняет ситуацию, но прикольно. Наверное можно с другими дев-инструментами как-то объединить. Пробовал написать просто набор теста на адекватность сервера, в принципе не сложно получилось.
                      0
                      Надеялся что для Memtest есть какие нибудь альтернативы, по аналогии с процессором и простыми числами.

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

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

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

                              0
                              ECC не всесильна, она корректирует единичную ошибку, от случайной флуктуации, от космических лучей. Вот и интересно, есть счетчик где нибудь этих ошибок?
                                0
                                Есть такой, в винде это вроде бы журнал WHEA.
                                В линуксе что то тоже должно быть. Механизм как раз служит для замены сбойной памяти до того как сбои сказываются на работе.
                                А проверять ECC память мемтестом как то не очень похоже на выбор который бы сделал профессионал.
                                  0
                                  В IPMI сыпет ошибки вида Correctable ECC @ DIMM2A CPU2 — Asserted
                                  Т.е во время теста мемтестом, даже если сам мемтест не покажет ошибки, в логах IPMI вы их уведите
                                    0
                                  0
                                  На имеющемся у меня древнем серваке в БИОС присутствует Лог Событий Памяти, где в случае проблем с памятью появляются соотв. записи.
                                    0
                                    А какая разница? Так можно и стресс-тесты на 15 секунд запускать — ой, ничего не упало, значит все хорошо.
                                      0
                                      Уважающее себя железо даёт посмотреть, что с ним происходит. В логе IPMI/iLO есть записи о корректируемых ошибках памяти. Не припомню, чтобы видел некорректируемые, впрочем. В Linux есть такой github.com/andikleen/mcelog, который умеет это всё доставать и писать в лог. В /sys/ тоже есть данные EDAC (вот пример использования), и их оттуда можно читать и передавать в ваш любимый мониторинг. Только отличное от 0 значение в uncorrectable errors я тоже никогда не видел, и даже в свое время смотрел в ядре, почему так, но не помню точной причины.
                                        0
                                        пишут, что /dev/mcelog (через который работает одноимённая программа) deprecated
                                          0
                                          del
                                      +1
                                      Пользуюсь вот такой штукой github.com/stressapptest/stressapptest в моих случаях гораздо эффективнее мемтеста, если мемтест надо часами крутить прежде чем ошибку найти, то тут хватает и 10 минут на аналогичное, уж не знаю что за конкретная магия там внутри )
                                      0
                                      При тестировании дисков ещё надо замерять latency, чтобы исключить проблемы на шине контроллера. Это когда диск пишет со скоростью 250 МБ/с в один поток, но с latency в 1.5 секунды.
                                        0
                                        Будет интересно взглянуть на образ, ждем когда у Вас дойдут до него руки :)
                                          0
                                          1. 60 мегабайт от 32 Гигабайт это 0,2%, а не 2%.
                                          2. У жесткого диска, в отличие от компакт-диска, запись идет от края внутрь, соответственно и максимальная скорость падает по мере записи.
                                            +3
                                            Кто не знает — батарейки на RAID хватает, чтобы все диски еще 2 часа покрутить. То есть ты выключаешь сервер, вынимаешь, а он еще 2 часа вращает диск, чтобы завершить все записи.
                                            Понятно.
                                              +1
                                              Кто не знает — батарейки на RAID хватает, чтобы все диски еще 2 часа покрутить. То есть ты выключаешь сервер, вынимаешь, а он еще 2 часа вращает диск, чтобы завершить все записи.
                                              Вы это серьезно? После этих слов ко всей статье начинаешь относиться как к чисто маркетинговой…
                                              Для сведения: BBU — Battery Backup Unit (Модуль Резервной Батареи). BBU обеспечивает батарейную защиту питания для кэша контроллера RAID. В случае сбоя питания, BBU поможет сохранить данные в кэше.
                                                0
                                                На сегодня это 2 юнита, в которые может поместиться либо 12 узлов однопроцессорных серверов, либо 4 узла двухпроцессорных серверов.

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

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

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

                                                Intel и был LSI
                                                  0

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

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

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

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

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

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

                                                        Ваш любимый Linux — этой стандарный Linux или кастомный?
                                                          0
                                                          Исторически сложилось что в качестве базы для всего этого используется DCIManager от компании ISPsystem. Различным надстройками и хуками вокруг него запускаем все эти крипты.
                                                          0
                                                          Большинство серверов, которые не прошли проверку, мы просто выкидываем.
                                                          да? куда выкидываете? где забирать? :)

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

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