ЖелезоХабрахабр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Улов

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

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

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

Память

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

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

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

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

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

Это сделано так, потому что иначе Memtester занимает всю память, и его убивает down killer. Здесь мы передаем количество свободной памяти минус 1 Мб. Гоняем этот тест 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RAID

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

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

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

Сеть

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

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

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть