Inquisitor

https://www.youtube.com/watch?v=mD_ch49vDtw
https://sourceforge.net/projects/inq/
LTT рассказал о том, что они начали писать программу для автоматизации
тестирования железа. Сразу вспомнил про проект Inquisitor, которым я
занимался много лет на своей первой работе. Уже десять лет толком его
никто не трогал, но SourceForge говорит что до сих пор кто-то его образы
ещё скачивает.

Не я был его архитектором, но в целом то всё грамотно было сделано.
Задача проста: максимально автоматизировать процесс проверки собранного
сервера (тогда в компании ETegro Technologies). Нужно убедиться что всё
установленное в него железо соответствует заказу (собирают же это всё
люди, так что можно перепутать компонент или недовставить его). Нужно
убедиться что каждый компонент работает. Причём под работой
подразумевается реальная жизнеспособность под нагрузкой. Нужно убедиться
что, хоть железо и работает, но не выходит при этом за пределы
допустимых температур например. Нужно возможно предустановить какую-то ОС.

Все серверы после сборки клались в стойки и подключались всеми своими
Ethernet-ами к коммутаторам и KVM. Тестировщик должен включить машину и
настроить автоматическую загрузку по сети. Все коммутаторы подключены к
одному единственному серверу Inquisitor, на котором запущены DHCP, TFTP,
NFS для PXE загрузки. Компьютер загружался в GNU/Linux, init-ом в
котором был скрипт от Inquisitor экосистемы. Ядро конечно же было
самосборное, чтобы работало на огромном разнообразии железа. Если
возникала необходимость загрузки какого-то особенного, то в PXE/TFTP
меню была возможность выбора других образов, которые уже готовили
программисты (в том числе я).

Клиентская часть Inquisitor была почти полностью написана на POSIX
shell. На сервере был Ruby On Rails, с которым клиент мог
взаимодействовать через HTTP API, дёргаемый curl-ом из скриптов.

Первым делом клиент, насколько помню делал self-id процедуру. Компьютер
должен как-то уникально себя мочь представить серверу и узнать свой
серийный номер -- идентификатор в контексте экосистемы базы данных
выпущенных компьютеров компании. Он мог отправить свой FRU (серийный
номер шасси?) или MAC-адреса на сервер и тот по своей базе данных
компонент мог бы ответить кем он является. Когда компьютер ещё не
тестировался, то БД ничего про него не знает и ввод серийника делался
либо сканированием наклейки на нём, либо вообще просто ручным вводом с
клавиатуры (аварийный режим когда или нет сетевых карт или ещё чего
подобное).

После запуска ОС и Inquisitor клиента, тестировщик берёт сканер
штрих-кодов и сканирует свой badge с идентификатором тестировщика,
сканирует наклейку с серийным номером на сервере и наклейку полки в
стойке. Сканер по радиоинтерфейсу подключён через COM-порт с Inquisitor
сервером. Каждый штрих-код, кроме номера, содержит и обозначение класса
(тестировщик ли это, полка или сервер). Демон, написанный на Ruby,
получив триаду из таких номеров, знает кто тестирует какой сервер и где
он находится (в стойке).

Каждая полка в стойке имеет несколько Ethernet кабелей. Уже не помню
сколько. То ли четыре, то ли больше. Чтобы ими можно было заткнуть все
сетевые карты большинства серверов. И все эти кабели для каждой
отдельной полки находятся в выделенном VLAN-е. Зная местоположение
полки, можно детерминировано (просто hardcode) понять к какому VLAN-у
они относятся.

Клиент, проведя self-id процедуру, если когда-то уже тестировался
прежде, то узнает свой id от сервера по данным из БД. Если же он не
тестировался, то запускается скрипт, слушающий на Ethernet адресах
пакета с данными от сервера. Когда тестировщик всё отсканировал, то
сервер по broadcast (не помню уже так ли это) адресам посылает сообщение
клиенту с серийным номером сервера.

Дальше шёл процесс detect-ов. Нужно было понять что за компоненты
установлены в железе. Это всякие shell-скрипты, запускающие сторонние
утилиты, парсящие их вывод, формирующие XML-ки с информацией о железе.
Класс железа (CPU/HDD/etc), vendor, серийный номер (самое главное) и
версия прошивки (опционально конечно же). lshw утилита была основной что
выдавала кучу информации. Einarc утилита выдавала знание о наличии BBU
(battery backup unit) у RAID контроллеров. impitool выдавала информацию
о BMC и шасси, материнке, платформе, источнике питания и SCSI backplane.
Банальный /proc/cpuinfo что-то говорил о CPU (не помню уже чем
отличается от вывода lshw). Что-то определялось через HAL (его же вроде
уже нет в современных GNU/Linux?). Информация о памяти бралась из IPMI,
DMI, SPD, в худшем случае /proc. USB устройства узнавались гуляя по /sys.

Всё это то ли формировало XML-ники, то ли каждый раз дёргало серверные
методы добавления компонентов. Компьютер уже мог представиться своим
серийным номером при этом. Во время работы компьютер регулярно делал
(curl-ом) heartbeat на сервер.

В Web-интерфейсе Inquisitor сервера были нарисованы стойки. Сервер уже
понимал где в стойках есть компьютеры и какое у них состояние. И
тестировщик, сидя на своём рабочем месте, смотрел полностью за
состоянием компьютеров в стойках. Жёлтый цвет полки в стойке (вроде)
означал то, что требуется вмешательство тестировщика. Красный -- что
что-то точно пошло не так. Зелёный -- все тесты завершились и сервер
можно убирать с полки. Белый -- идёт процесс тестирования.

После первоначальных детектов, от тестировщика ожидается подтверждение
того, что процесс тестирования можно запустить. Он идёт на страницу
компьютера, уже зарегистрированного в БД (MySQL был) под своим серийным
номером. Тестировщику показывается страница с результатами детектов
(очень человекочитаемый формат, похожий на то, как описывается железо в
Интернет-магазинах) и с информацией из 1С БД (которая пересасывалась
скриптом) из заказа. И человек сравнивал и оценивал всё ли соответствует
ожиданиям. Ведь формат полей заказа 1С относительно произвольным мог
быть. Если что-то не так, например что-то не установлено, или перепутано
или возможно просто не работает и поэтому не определилось, то обычно
надо сервер достать с полки и корёжиться с ним дальше. Снова установить
на полку и включить. Если сетевые карты, материнская плата не менялись,
то self-id уже пройдёт без участия человека. Тестировщик поменяв
компонент, просто ставит в стойку, включает и идёт за своё рабочее
место, ожидая жёлтого цвета полки, и снова оценивая результаты детектов.

Позже были добавлены и software-detect-ы. Это, в первую очередь, нужно
только архивного хранения знаний под чем именно тестировался компьютер.
Версия Linux, его командная строка, версия bonnie, ФС по умолчанию,
flac, GNU ассемблера, GCC, gzip, iozone, mencoder, oggenc, openssl,
p7zip, speexenc, tar, x264 и наверное ещё чего-нибудь.

Когда детекты подтверждены тестировщиком, то запускается, собственно,
сам процесс тестирования. У сервера есть свой индивидуальный план
тестирования, так называемый профиль (profile). Это просто навсего
XML-ка в которой указаны какие тесты надо запустить и с какими опциями.
Есть профили по умолчанию. Профили можно массово применить к целой
партии компьютеров. Можно индивидуально (всё через web-интерфейс)
выставить в любое время. Профиль по сути просто говорит какие
shell-скрипты надо запустить и с какими параметрами.

Каждый тест это shell-скрипт, в комментариях которого указана
метаинформация, объясняющая какие параметры тестирования можно задать.
Тестов написано с полсотни. Например тесту bonnie можно передать
используемую ФС, кол-во файлов, размеры min/max файлов, и т.д.. Тесту
dhrystone можно передать только время тестирования. Какие-то тесты
вообще не принимают аргументов/опций. "Настоящие" тесты: bonnie,
BYTEmark какой-то, burnK7/burnP6, dhrystone, whetstone, smart тест,
hdparm, dd, iozone, linpack (тот самый, которым суперкомпьютеры все
тестируют), memtester, mencoder в память или HDD, STREAM,
stressapptest от Google, stress-compress (параллельное создание архивов
больших на дисках), unixbench, и т.д..

Какие-то тесты загружают только один или несколько компонентов. Какие-то
нагружают только целочисленные АЛУ процессора, не трогая кучу других. В
идеале надо нагрузить всё всё всё под завязку и максимум, что не
тривиально. Помню что linpack являлся лучшим по нагрузке CPU с памятью
одновременно. badblocks тест не сказать что является нагрузкой для
дисков, но он хотя бы пройдёт полностью по всей поверхности диска,
затронет блоки. Поэтому тест HDD это несколько тестов.

На самом деле подтверждение детектов это тоже является тестом. Обычно
просто первым. Если тестировщик отклонил детекты, то тест падает, на
мониторе (если переключить KVM) будет показана ошибка.

Есть тесты сетевых карт, где на каждой сетевой карте настраивается
IP-адрес и скачивается что-то большое и что-то загружается, затем
сравнивая MD5. Для меня было удивительным, но действительно бывает так,
что пакеты могут сетевухой биться и портиться. Типа вроде бы всё и
работает, но данные портятся.

Есть тесты FDD и ODD (optical disk drive). Причём тесты могут требовать
вмешательства тестировщика. Такой тест curl-ом сообщает серверу о том,
что надо позвать человека. На экране он показывает сообщение типа
"insert FDD/ODD/whatever disk и нажмите enter". Оптические диски обычно
заранее вставлялись. Тест на чтение заключается в чтении заранее
известного диска и сравнивании с указанным в профиле MD5. Тест на запись
диска была тоже.

badblocks команда работает только с одним диском. Поэтому была написана
обёртка которая визуализировала прогресс и процесс тестирования всех
этих дисков. Вроде бы даже тесты умели вызывать SAS/SES команды мигания
лампочки рядом с неисправным диском.

Но badblocks это про тестирование отдельного диска. А как быть с
RAID контроллерами-ами? Для них была написана Einarc утилита. Это и
"einarc is not a raid controller" и "ein arc" (единственный/один arc).
Это обёртка над существующими разнообразными проприетарными утилитами
vendor-ов для управления своими контроллерами. Она за своим единым API
прятала весь разный интерфейс этих утилит. Einarc утилите можно было
сказать: покажи мне список дисков, из вот этих выбранных сделай мне
RAID1. И одним из тестов является просто запуск einarc-а с указанными
параметрами. Можно было просто сказать: сделай "оптимальный" массив и, в
зависимости от кол-ва дисков, будет создан тот или иной уровень RAID-а.
А следующим тестом уже будет запущен процесс работающий с созданным
массивом. В конце профиль мог вызвать einarc с разрушением всех
созданных массивов, чтобы клиенту не подсовывать что-то настроенное. Или
наоборот можно было заранее это сконфигурировать, ведь процесс rebuild
длительным может быть и имеет смысл его заранее запустить.

Почти всегда также требовалось и обновление прошивок железа на что-то
посвежее. Это отдельные тесты. Для прошивки BIOS тест сообщал серверу
что при следующей загрузки сервера по сети надо подсунуть заранее
приготовленный тестировщиком образ дискеты. Сервер для заданных
MAC-адресов создаёт одноразовые файлы для PXE загрузки. Удалял их вроде
подправленный TFTP сервер. То есть: загрузка по сети, детекты, получение
профиля тестирования, которое уже пропускало успешно прошедшие тесты,
запуск "теста" прошивки, которая curl-ом сообщала серверу о PXE
загрузке, перезапуск, загрузка с one-time образа дискеты, в которой
autoexec запускал процесс перепрошивки, снова перезагрузка, загрузка PXE
и снова Inquisitor клиента, получение профиля, запуск теста прошивки,
сверка что детекты определили обновлённую версию ПО, сообщение серверу
что тест прошёл успешно. Перепрошивка RAID/HBA-контроллеров делалась
через einarc утилиту тоже и перезагрузка не нужна.

Через перезагрузку запускался и memtest86. Уже не помню как он сообщал
что что-то пошло не так. Предполагаю что если была ошибка, то он не
перезагружал компьютер и тестировщик уже просто по времени/timeout-у
проверял что там на экране сервера. А если всё успешно, то memtest86
просто перезагружал компьютер.

Тесты могли сообщать (curl запрос) серверу о прогрессе тестирования.
Тоже парся вывод команд или просто сообщая что тест займёт 300сек, если
так было указано в профиле. И уже сам сервер, видя что 300сек уже давно
прошли -- мог окрасить в красный цвет полку.

Часть тестов была benchmark-ами. Тесты по кодированию видео mencoder-ом
(помню что это было перекодирование Big Buck Bunny) и нагружали CPU/RAM,
но и отдельными curl API вызовами публиковали результаты benchmark-ов.
Во-первых это и просто интересно: увидеть насколько такой-то AMD
Bulldozer мощнее такого-то Xeon, но и позволяет выявить аномалии, типа
работоспособности железа, но почему-то очень низких показателей
benchmark-ов. Возможно проблемы с CPU или теплоотводом и он постоянно в
перегретом режиме, что можно считать неисправностью. Хочется прогнать
только benchmark-и? Просто надо указать профиль с benchmark-ами.

Кроме тестов, параллельно ещё запускались мониторинги. Это тоже
shell-скрипты которые просто регулярно отправляли температуру процессора
(через sensors, IPMI), обороты вентиляторов, loadavg, SMART информацию
дисков, скорость чтения ODD. И web-интерфейс на основе этого строил
графики. Какие-то тесты отправляли собственные мониторинги тоже.
Тестировщик глазами должен был пробежаться по этим графикам (просто
Gnuplot-ом построенные из данных MySQL). Тут можно или высокие
температуры увидеть, или неожиданно низкие скорости или аномальное
поведение какого-то одного сервера из целой партии (при его прочей
работоспособности).

Если сервер пришёл по гарантии, то когда его подключат к системе, первым
делом заработают детекты и покажут не поменяли ли пользователь чего-то
из железа. Всё автоматизировано. Если клиент жалуется на проблемы с RAID
контроллером, то можно использовать профиль усердно насилующий только
дисковую подсистему. Среди тестов и профилей есть и недеструктивные
режимы, которые не погубят данные на дисках (если, конечно, диск не
умрёт и контроллер не испортит всё).

Позже был сделан вариант Inquisitor в LiveCD исполнении. Типа когда надо
провести какие-то работы по поддержке у клиента, не имея возможности
привезти сервер и подключить к стойке. По сути это была просто
client-only версия, загружаемая с диска, где на лету, на основе
метаинформации из shell-скриптов тестов/мониторингов/прочего
генерировались dialog-овые полноэкранные TUI окна, где можно было
задавать параметры тестирования. Командую строку можно было не
использовать: всё через менюшки. Точно уже не помню, но вроде бы можно
и, как минимум, детекты было выгрузить на подмонтированный накопитель.
А экран показывал GNU Screen, в котором вроде бы и мониторинги
показывались пользователю сразу же. Про tmux я тогда не знал, но Screen
уже невзлюбил. И вообще, учитывая что ядро имело много патчей и
драйверов, и что из коробки сразу много всяких полезных утилит, в том
числе сетевых -- диск был полезен и сам по себе, как админский
инструмент.

Особняком ещё стояли тесты которые могли просто накатить dd или
partimage образ системы на диски. Хочется на массив? Просто в профиль
надо добавить соответствующий "тест" с нужными параметрами. Образы,
соответственно, брались по NFS. Но как-то возникла проблема: когда стоят
несколько десятков серверов, на которые надо залить несколько сотен
гигабайт данных, то бутылочным горлышком становится сам NFS сервер
Inquisitor. Коммутаторы стояли на 100Mbps, но всё равно такое количество
параллельных клиентов заставляло трудится дисковый массив сервера. И я
помню как общаясь с техдиром, я просто бросил фразу о том, что надо как
порнографию по BitTorrent-у распространять эти образы. Секунды тишины,
пока оба мы переваривали это в голове, и осознание того, что ведь
действительно для этой задачи BitTorrent подходил бы как никогда лучше.
В итоге, просто навсего был поднят BitTorrent сервер, с патчем, который
не игнорировал 10/8 адреса локальной сети (да, на тот момент всё было на
IPv4, древние времена) и самый обычный ctorrent "скачивал" образ прямо
поверх блочного устройства (патч к ctorrent). Серверы друг другу
помогали всё это скачать. Стоечная сеть максимально утилизировалась.

Это был первый большой проект в котором я участвовал. Тьмища опыта.
Незабываемая фраза "Серёг, сейчас отреверчу всё нахуй", относящаяся к
коммиту сделанном на ноутбуке в электричке. И лютая нелюбовь к железу.
Точнее к тому, что постоянно всюду и везде возникают те или иные
особенности работы то материнки, то процессора, то сочетания тех или
иных компонент.

Тогда я воочию увидел каким же лютым говнищем стали Seagate диски. С
той работы я вообще не допускаю использование Seagate-ов где бы то ни
было. Компания которая не рассматривается как вариант.