Привет! Меня зовут Олег Рябов, я главный эксперт Управления исследований и разработок новых решений компании «Ростелеком-ЦОД» и автор программы и методики испытаний (ПМИ) серверов.

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

Предыстория

В 2020 году перед нами поставили задачу выбрать процессор для типового вычислительного узла, который будет использоваться в 95% наших проектов.

На тот момент еще никто в мире не смог разработать единую метрику производительности процессоров. Метрика производительности сетевого оборудования — это PPS (Packet Per Second), например, а производительность СХД измеряется в IOPS (Input/Output Operations Per Second). А у процессора нет единицы измерения, с помощью которой можно измерить производительность и сопоставить результаты тестов.

Мы начали с того, что выбрали утилиты VMmark и Geekbench. Естественно, они выдают результаты в своих показателях, и эти показатели никак не соотнести друг с другом. Поэтому трудно разработать единую метрику производительности на основе получаемых данных, в этом вся загвоздка. Тем не менее мы продолжали набирать базу результатов тестирования процессоров и серверов и тогда же написали первую версию ПМИ серверов.

В конце 2021 года мы планировали провести тестирование процессоров Intel Xeon Scalable 3rd Gen и для этого обратились в Intel. Рассказали им, как проводим испытания, показали свою ПМИ. Чуть позже представители Intel пришли к нам с предложением вместе разработать единую метрику производительности процессоров, так как им самим этого сделать не удалось. Мы успели протестировать две модели процессоров на их серверах, но не смогли завершить проект, потому что случился 2022 год и вскоре Intel ушел из России. В рамках импортозамещения приоритет получила задача испытания отечественных серверов.

Сейчас перед нами снова поставлена задача выбрать процессор для типовых вычислительных узлов и разработать единую метрику производительности процессоров. Но теперь мы будем тестировать их уже на отечественных серверах.

Как происходит тестирование сейчас

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

Мы оцениваем серверы при нагрузке определенных типов, с учетом их позиционирования для применения в инфраструктуре и проверяем:

• функциональные возможности серверов;

• производительность;

• отказоустойчивость;

• надежность и стабильность работы серверов в предоставленных конфигурациях под нагрузкой, близкой к 100%;

• соответствие заявленным характеристикам;

• применимость в существующих и перспективных продуктивных инсталляциях в инфраструктуре нашей компании.

Обязательно оцениваем взаимодействие с поставщиком или производителем серверов в ходе испытаний и его реакции на выявленные ошибки и недоработки.

Содержание

1. Пусконаладочные работы

2. Функциональное тестирование

3. Нагрузочное тестирование

4. Тестирование отказоустойчивости компонентов серверов

5. Тестирование совместимости серверов с модулями доверенной загрузки

6. Оценка взаимодействия с поставщиком и производителем серверов

7. Стоп-факторы при оценке применимости серверов

8. Заключение

Пусконаладочные работы

Собираем и подключаем стенд: устанавливаем серверы в стойки и подключаем их в сеть передачи данных (LAN), сеть хранения данных (SAN) и сеть управления (management). На рисунке представлены подключения в рамках тестового стенда и дополнительное оборудование для проведения тестирования.

Затем:

• обновляем версии микрокода BMC, BIOS и других компонентов сервера;

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

• включаем Hyperthreading (SMT), если в проекте нет требования отключить его.

Важно: обновленные версии микрокода BMC, BIOS и других компонентов сервера не меняем до завершения испытаний.

Систему запускаем в режиме UEFI, но в виде исключений, например, когда не поддерживается PCIe-карта или какая-либо функциональность, используем режимы Legacy или DUAL (смешанный режим).

Мы можем проводить испытания как на Bare Metal, так и в ВМ для задач виртуализации. Используем ОС семейства Linux или Windows, гипервизоры VMware ESXi или другие, согласованные с заказчиком испытаний. Версия ОС, на которой выполняются тесты, должна быть сертифицирована производителем серверов или указана заказчиком.

Функциональное тестирование

Функциональные возможности серверов, которые мы проверяем:

1. Использование как статического, так и динамического (DHCP) режима конфигурации сетевого подключения интерфейса управления (BMC).

2. Взаимодействие с интерфейсом управления по протоколам IPMI и SNMP v3.

3. Взаимодействие c интерфейсом управления посредством Redfish API.

4. Доступность в интерфейсе управления базовой информации:

• о сервере (модель сервера, серийный номер, версия микрокода BIOS и BMC);

• об аппаратной конфигурации (количество и тип CPU, модулей RAM, HDD, PCIe-карт);

• о состоянии аппаратных компонентов и журналов событий, аудита и обслуживания.

• о сервере (модель сервера, серийный номер, версия микрокода BIOS и BMC);

• об аппаратной конфигурации (количество и тип CPU, модулей RAM, HDD, PCIe-карт);

• о состоянии аппаратных компонентов и журналов событий, аудита и обслуживания.

5. Доступность в интерфейсе управления:

• информации о текущих показаниях датчиков температуры, напряжения, скорости вращения вентиляторов, энергопотребления и пр.;

• управления включением, выключением, перезагрузкой сервера, а также перезагрузкой и сбросом BMC до заводских настроек;

• информации и возможности создания дисковых томов с использованием аппаратного и встроенного программного RAID-контроллера.

6. Отправка сообщений о событиях с использованием SMTP, syslog и SNMP Trap.

7. Доменная аутентификация и авторизация посредством LDAP, Active Directory, RADIUS, ролевой доступ.

8. Генерация нового или добавление существующего SSL-сертификата.

9. Создание новых пользователей с определенными правами доступа (администратор, оператор, только чтение).

10. Создание новых прав доступа и назначение их пользователям.

11. Использование HTML KVM-консоли или Java-консоли для установки и управления ОС. Подключение через консоль образов оптических дисков.

12. Подключение образов жестких дисков (img) и проброс USB-накопителей в интерфейсе управления.

13. Обновление версии микрокода BMC без влияния на работу ОС.

14. Разделение предопределенных сетевых портов для доступа в интерфейс управления и в ОС (NCSI).

15. Полноценный Command Line Interface, по возможностям настройки и управления не уступающий интерфейсу управления.

16. Автоматическое открытие сервисных заявок (call home) в технической поддержке производителя.

17. Экспорт и импорт конфигурации интерфейса управления.

18. Возможность настройки сетевых параметров интерфейса управления в BIOS Legacy или UEFI и создания пользователей для доступа в интерфейс управления.

19. Наличие преднастроенных профилей производительности в BIOS Legacy или UEFI.

20. Создание дисковых томов с помощью утилиты RAID-контроллера в BIOS Legacy или в режиме UEFI.

21. Наличие у производителя серверов MIB-файлов.

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

Нагрузочное тестирование

В зависимости от того, выполняем ли мы тестирование отдельного компонента сервера (CPU, RAM, сеть и др.) или сервера в целом, есть свой набор тестов и утилит. Для сравнения полученных результатов тестирования мы запускаем утилиты с одинаковым набором параметров.

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

У нас есть эталон — определенная модель сервера с процессорами Intel Xeon Gold 6254, которая подходит для использования в нашей инфраструктуре. Все результаты нагрузочного тестирования серверов должны быть не хуже результатов эталона. Дополнительно проводим сравнение результатов тестируемых серверов с результатами, которые опубликованы на официальных сайтах используемых утилит тестирования.

Всего используем восемь утилит:

1. VMware VMmark;

2. Sysbench;

3. Stress-ng;

4. Geekbench;

5. Iperf3;

6. Intel MP Linpack;

7. Тест Гилева;

8. PassMark CPU.

Оцениваем:

• производительность процессоров в одноядерном и многоядерном режимах;

• скорость доступа к оперативной памяти при операциях чтения и записи;

• скорость работы дисковой подсистемы серверов;

• пропускную способность сетевой подсистемы серверов;

• производительность платформы виртуализации для задач виртуализации;

• производительность платформы «1С:Предприятие».

1. Утилита VMware VMmark

Утилита предназначена для тестирования производительности серверов в качестве серверов виртуализации под управлением VMware vSphere. Показатели производительности выражаются в баллах и в количестве тайлов. Инфраструктуру для проведения тестирования подготавливаем по документу VMmark Users Guide.          

Один тайл (tile) включает 20 виртуальных машин различного объема в части вычислительных ресурсов и назначения, чтобы имитировать рабочие нагрузки на платформу виртуализации. Нагрузку масштабируем путем инициализации необходимого количества тайлов.

Каждый тайл — это:

• 20 виртуальных машин;

• 55 (47) виртуальных ядер (не все ядра активные);

• около 900 ГБ дискового пространства на хранилище;

• около 180 ГБ RAM.

Требования по производительности на один тайл:

• не менее 3 500 IOPS;

• полоса пропускания — 600–650 Мбит/с, подключение — от 1 Гбит/с.

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

Для корректного тестирования используем:

• не менее двух идентичных по конфигурации серверов, на которые устанавливаем гипервизор VMware ESXi версии 7.0 или новее;

• выделенный VMware vSphere или VMware vCenter версии, совместимой с гипервизором;

• две подсети: одна из них изолированная и используется для сетевой связанности всех виртуальных машин с управляющим сервером (виртуальная машина, именуемая как prime client), а другая — для доступа и управления prime client;

• систему хранения данных или сервер в виде СХД. Во втором случае презентуются блочные диски с использованием iSCSI TGT. Через NFS тест работает некорректно. При тестировании рекомендуем не изменять конфигурацию СХД. Объем свободного дискового пространства на СХД — не менее 900 ГБ на один тайл + необходимый запас 20%.

  — При использовании СХД дисковое пространство предоставляем одним LUN (дисковое пространство) всем серверам.

  — При использовании сервера в виде СХД каждый накопитель презентуется серверам отдельным LUN, далее создаются VMFS-хранилища, и по этим хранилищам равномерно распределяются тайлы, предпочтительно по одному на LUN;

• один LUN объемом не менее 1 ТБ для размещения prime client и проведения инфраструктурных операций;

• образ теста VMmark, из которого мы клонируем prime client и настраиваем его дальше по VMmark Users Guide.

LUN с СХД презентуется серверам платформы виртуализации по протоколу iSCSI или Fibre Channel так, чтобы LUN был доступен по двум путям или более, при этом используется политика round-robin.

При использовании сервера в виде СХД и протокола iSCSI, если невозможно обеспечить два независимых пути или более, устанавливаем два IP-адреса в одной подсети на сервере iSCSI.

Установка первого тайла занимает около 12 часов, так как на одной из ВМ создается база данных. Последующие тайлы копируют образ первого, поэтому их установка занимает не более 1 часа. Тестирование проводится с постепенным увеличением количества тайлов до тех пор, пока показатели растут, а вычислительные ресурсы в системе еще доступны для использования.

Важно: при тестировании в VMware vCenter необходимо обращать внимание на показатели таких параметров, как CPU Ready, CPU Usage, CPU Utilization, Memory Active, Memory Consumed.

Итоговый результат тестирования включает три показателя:

• VMmark3_Applications_Score — показатель производительности приложений на тестируемой системе;

• VMmark3_Infrastructure_Score — показатель производительности инфраструктурных операций на тестируемой системе;

• VMmark3_Score — общая оценка производительности системы, которая рассчитывается как сумма VMmark3_Applications_Score и VMmark3_Infrastructure_Score, причем 80% рабочей нагрузки приходится на работу приложений, а остальные 20% — на инфраструктурные операции.

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

Затем мы анализируем производительность платформы виртуализации при увеличении рабочей нагрузки на нее, выраженной в количестве тайлов, и сравниваем результат с эталонными результатами сервера с процессорами Intel Xeon Gold 6254 (на один сервер 2 тайла, AppScore — 2.18) и с верифицированными результатами на сайте VMware.

2. Утилита Sysbench

Эту утилиту используем для тестирования производительности процессоров и оперативной памяти серверов. Она позволяет найти узкие места подсистемы памяти, NUMA нод, Hyperthreading/SMT и пр. на простых операциях, которые легко параллелятся.

На тестируемых серверах устанавливаем совместимую ОС, например Ubuntu Server 20.04, Ubuntu Server 22.04 или новее. Утилиту Sysbench загружаем и устанавливаем из репозитория ОС или из другого доверенного источника.

При тестировании производительности процессоров в серверах вариативность теста обеспечивается за счет использования параметра cpu-max-prime с различными значениями (10 000, 20 000, 40 000). Этот параметр определяет, до какого значения будет идти вычисление простых чисел. Вычисления происходят с использованием 64-битных целых чисел. Производительность процессоров выражается в количестве событий (event) в секунду.

Утилиту Sysbench запускаем командой

 ~# sysbench cpu --cpu-max-prime=<10000, 20000 или 40000> --num-threads=<количество потоков> run

Для параметра cpu-max-prime подставляем одно из трех значений (10 000, 20 000 или 40 000) а для параметра num-threads подставляем любое количество процессорных потоков, которое не должно превышать общего количества потоков в тестируемом сервере.

При тестировании производительности (скорости доступа) оперативной памяти в серверах как при операциях чтения, так и при операциях записи вариативность теста обеспечивается за счет использования параметра memory-block-size с различными значениями (4, 8, 16, 32, 64, 128 ГБ). Этот параметр означает размер блока оперативной памяти. Производительность оперативной памяти выражается в пропускной способности (МиБ/с) при операциях чтения и записи.

Для запуска утилиты используем команду

~# sysbench memory --memory-block-size=<4G,8G,16G,32G,64G или 128G> --memory-total-size=<объем RAM в сервере> --memory-scope=local --memory-oper=read --threads=<количество потоков> run

Здесь для параметра memory-block-size подставляем одно из шести значений (4G, 8G, 16G, 32G, 64G или 128G), для параметра memory-total-size подставляем значение, равное объему оперативной памяти в сервере, а для параметра threads — любое значение количества потоков, которое при умножении на значение параметра memory-block-size не превышает объема оперативной памяти сервера.

Тестирование производительности оперативной памяти проводим на локальных блоках памяти, когда каждый поток взаимодействует со своим выделенным блоком памяти, поэтому в команде запуска Sysbench используем параметр memory-scope=local.

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

и рассчитываем стандартное отклонение (дисперсию) по формуле

По результатам тестирования производительности процессоров и оперативной памяти анализируем показатели производительности и описываем зависимость производительности от используемого количества потоков и размера блока памяти. Затем сравниваем результаты с эталонными.

3. Утилита Stress-ng

Используем для нагрузочного и стресс-тестирования компонентов серверов: процессоров, кэш-процессоров, оперативной памяти и дисковой подсистемы.

На тестируемых серверах устанавливаем совместимую ОС. Утилиту Stress-ng загружаем из репозитория ОС или из другого доверенного источника.

Запускаем нагрузочное и стресс-тестирование на 48 часов, на протяжении которых посредством контроллера BMC контролируем доступность серверов и показатели датчиков температуры на предмет превышения пороговых значений. Если температура превысит критическое значение, появится уведомление и отметка в системном журнале.

Для запуска утилиты используем команду

~# stress-ng --cpu 0 --cache 0 -m 0 --vm-bytes <объем RAM в сервере> --io 0 --hdd 0 -t 172800s --metrics-brief --tz

Для параметра vm-bytes подставляем значение в ГБ, равное объему оперативной памяти сервера.

Основным показателем производительности является параметр bogo ops/s (real time) — количество фиктивных операций в секунду. Значение данного параметра рассчитывается для каждого компонента сервера, включенного в тестирование. Также утилита Stress-ng в ходе тестирования фиксирует показатели температуры, которые включаем в результат тестирования в виде минимального и максимального значений.

По результатам тестирования мы анализируем работу серверов под 100%-й нагрузкой или близкой к таковой. Сравниваем полученные в утилите Stress-ng и зафиксированные в BMC серверов показатели температуры с критическими значениями температуры датчиков в BMC. Если во время тестирования серверы работали безошибочно, а максимальные температуры, согласно датчикам, были на 10 ℃ ниже критического уровня температур, то тест считается успешно завершенным.

4. Утилита Geekbench

Включает в себя несколько тестов, характеризующих работу приложений с различной нагрузкой. Эту утилиту используем для тестирования производительности серверов как в одноядерном (Single-Core Performance), так и в многоядерном режиме (Multi-Core Performance).

На тестируемых серверах устанавливаем совместимую ОС. Загружаем с официального сайта или из другого доверенного источника утилиту Geekbench.

В тестировании используем версии 5.х и 6.х.

Важно: в утилите Geekbench 6.х тесты модернизированы и их меньше, чем в Geekbench 5.х, что приводит к разным результатам тестирования, которые невозможно сравнить между собой.

Для запуска Geekbench необходимо распаковать архивы tar.gz и воспользоваться файлом geekbench5 или geekbench6. Результат тестирования будет представлен виде баллов по каждому тесту, входящему в утилиту, для обоих режимов (Single-Core Performance, Multi-Core Performance), и на основе полученных баллов рассчитывается общая оценка производительности серверов.

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

5. Утилита Iperf3

Позволяет генерировать TCP- и UDP-трафик и используется для тестирования пропускной способности сетевых интерфейсов серверов.

На тестируемых серверах устанавливаем совместимую ОС и загружаем утилиту Iperf3 из репозитория ОС или из другого доверенного источника.

Если мы используем на серверах более одного сетевого интерфейса, агрегируем несколько сетевых интерфейсов в один логический сетевой интерфейс с использованием протокола LACP стандарта IEEE 802.3ad. Это нужно для повышения пропускной способности и отказоустойчивости сети передачи данных. Для агрегированного сетевого интерфейса применяем режим работы mode=4 (802.3ad) с политикой хэширования на уровне layer3+4. Дополнительно на коммутаторах, куда подключены порты серверов, выполняем настройку по агрегации сетевых интерфейсов в один логический интерфейс.

Утилита Iperf3 работает в один поток, что может отразиться на способности одного ядра процессора нагрузить сеть, поэтому рекомендуем разрешить Jumbo frames и увеличить MTU до максимально возможного. В случае если загрузка одного ядра процессора равна 100%, а пропускная способность сетевых интерфейсов серверов не достигла максимальных результатов, тогда надо увеличить количество потоков с трафиком, генерируемым клиентом Iperf3.

Тестируем одновременно на двух серверах в течение 24 часов, с периодической проверкой доступности серверов. На одном сервере утилита Iperf3 запускается с ролью «сервер», на другом — с ролью «клиент».

Для запуска утилиты Iperf3 с ролью «сервер» используем команду

~# iperf3 -s -p 5201

Для запуска утилиты Iperf3 с ролью «клиент» используем команду

~# iperf3 -c <IP адрес сервера, где iperf3 запущен с ролью сервера> -p 5201 -P <количество потоков> -t 86400

Для параметра -P подбираем такое значение количества потоков, при котором пропускная способность и процент утилизации сетевых интерфейсов были бы максимальными.

По результатам тестирования проводим анализ полученных показателей пропускной способности сетевых интерфейсов серверов и рассчитываем процент утилизации сетевых интерфейсов. Тест пройден успешно, если процент утилизации больше 90 от максимального показателя в 25 Гбит/с.

6. Утилита Intel MP Linpack

Эта утилита — реализация высокопроизводительного эталонного теста High Performance Linpack специалистами Intel для процессоров Intel, поэтому ее можно использовать только на серверах с процессорами Intel. Мы применяем ее для тестирования производительности серверов при решении случайных систем линейных уравнений.

На тестируемых серверах устанавливаем совместимую ОС. Для установки и запуска утилиты с официального сайта Intel загружаем и устанавливаем пакеты OneAPI Base Toolkit 2022.1.2.146 и OneAPI HPC Toolkit 2022.1.2.117 или более новых версий. Пакеты содержат библиотеки, необходимые для запуска утилиты.

Перед запуском утилиты выполняем команду для применения переменных окружения:

~$ . /opt/intel/oneapi/setvarsh.sh

Для проведения тестирования правим файл настроек HPL.dat в директории /opt/intel/oneapi/mkl/latest/benchmarks/mp_linpack (директория по умолчанию). Изменяем значения следующих параметров:

• Ns — размерность матрицы. Подбираем такое число, при котором утилизация оперативной памяти при работе утилиты Intel MP Linpack составляет 75–80%.

• NBs — размер блока. Выставляем значение 384.

• Ps и Qs — распределение матрицы между процессорами. Количество процессоров должно быть не меньше произведения Ps и Qs. Например, если в сервере два процессора, тогда для параметра Ps выставляем значение 1, а для параметра Qs — значение 2.

Остальные параметры в файле HPL.dat оставляем без изменения.

Запускаем файл runme_intel64_dynamic в директории /opt/intel/oneapi/mkl/latest/benchmarks/mp_linpack

Тестирование может продолжаться 2–3 часа в зависимости от установленных процессоров и оперативной памяти в серверах, а также от размера матрицы. Полученный результат выражается в GFLOPS, что означает количество операций с плавающей запятой в секунду, выполняемых тестируемым сервером. Результаты тестирования сравниваем с эталоном.

7. Тест Гилева

Тест Гилева оценивает применимость серверов и производительность платформы «1С:Предприятие» на этих серверах. Тест состоит из двух частей, которые не зависят друг от друга и запускаются по отдельности.

1. Первая часть теста (TPC) — однопоточный тест, оценивает производительность выполнения операций в один поток, что характерно для платформы «1С:Предприятие». Результатом теста является столбчатая диаграмма, на которой указан результат теста в виде количества баллов и результаты, соответствующие оценкам «плохо», «удовлетворительно», «хорошо» и «замечательно».

2. Вторая часть теста (G1C) — многопоточный тест, позволяет оценить скорость записи на диски при одновременном обращении нескольких запросов к базе данных. Результатами второй части являются:

• общая максимальная скорость записи;

• максимальная скорость записи в 1 поток;

• рекомендуемое количество пользователей.

Для выполнения теста Гилева используем ранее протестированную платформу виртуализации VMware, где установлена и настроена утилита VMware VMmark, необходимая для создания определенного уровня нагрузки на серверы.

На платформе виртуализации VMware создаем одну виртуальную машину с ресурсами 8 vCPU, 64 ГБ RAM и один виртуальный диск объемом 300 ГБ. В эту ВМ устанавливаем ОС Windows Server 2016, СУБД MS SQL 2019 и платформу «1С:Предприятие» версии 8.3. В «1С:Предприятие» создаем новую тестовую базу, куда загружаем скачанную базу Гилева.

Для корректного проведения тестирования рекомендуем выполнить дополнительные настройки:

• обновить все компоненты Microsoft через центр обновления;

• отключить Windows Defender;

• в Windows перевести режим энергосбережения в значение High Performance;

• установить VMware Tools в виртуальную машину;

• для сервера виртуализации VMware режим работы выставить в значение High Performance.

Для запуска теста Гилева необходимо открыть ранее загруженную базу в режиме «1С:Предприятие» и нажать кнопку «Выполнить тест». Выполнение каждой из двух частей теста длится около 3–5 минут. Если на ВМ есть выход в интернет, то по завершении теста результат можно сравнить с результатами других проведенных тестов.

Тестирование выполняется при трех уровнях нагрузки на платформу виртуализации (нагрузку создает утилита VMware VMmark):

• запуск теста Гилева при CPU Usage ≈ 0% на том сервере, где расположена ВМ с «1С:Предприятие»;

• запуск теста Гилева при CPU Usage ≈ 50% на том сервере, где расположена ВМ с «1С:Предприятие»;

• запуск теста Гилева при CPU Usage ≈ 75% на том сервере, где расположена ВМ с «1С:Предприятие».

Получив результаты тестирования, анализируем нагрузку на серверы. Сравниваем полученные результаты с эталоном и определяем применимость этих серверов в конкретной конфигурации для использования платформы «1С:Предприятие».

8. Утилита PassMark CPU

Набор тестов PassMark PerformanceTest Linux оценивает производительность сервера под различными типами нагрузки. Состоит из следующих тестов:

• Integer Math Test — тест на выполнение математических целочисленных операций;

• Floating Point Math Test — тест на выполнение математических операций с числами с плавающей запятой;

• Prime Number Test — тест на поиск простых чисел;

• Sorting Test — тест на сортировку строк массивов;

• Encryption Test — тест на шифрование блоков случайных данных разными методами шифрования;

• Compression Test — тест на скорость сжатия блоков данных;

• CPU Single Threaded Test — проведение тестов с плавающей запятой, сортировки строк и сжатия данных только на потоке процессора;

• Physics Test — тест на моделирование физического взаимодействия;

• Extended Instructions Test (SSE) — тест встроенных инструкций процессора.

Тестирование выполняется около 4–5 минут, результат представляется в виде баллов, характеризующих производительность CPU и RAM. Чем больше баллов, тем лучше результат. Полученный результат тестирования можно выгрузить на официальный сайт Passmark, чтобы сохранить и получить к нему доступ в любой момент.

Тестирование отказоустойчивости компонентов серверов

На этом этапе проверяем устойчивость работы серверов в случае отказа какого-либо компонента сервера и определяем поведение отработки такого отказа.

Тесты выполняем под фоновой нагрузкой, которую генерируют такие утилиты, как stress-ng и fio.

Если один из тестов отказоустойчивости не пройден, а производитель не предоставил нам патч, который исправил бы ошибку, то мы завершаем испытания и признаем сервер неприменимым в инфраструктуре компании.

1. Отключение и извлечение блока питания: имитация отказа блока питания

Этапы

1. Перед проведением тестирования для получения эталонных результатов запускаем утилиту Stress-ng на 2 часа с параметрами, которые были описаны в разделе «Утилита Stress-ng». Фиксируем результаты для последующего сравнения.

2. Для создания нагрузки на сервер при выполнении тестирования повторно запускаем утилиту Stress-ng на 2 часа с параметрами, описанными в разделе «Утилита Stress-ng».

3. От блока питания PSU1 отключаем кабель питания и наблюдаем за BMC сервера с использованием IPMI на предмет появления уведомлений об ошибках и создания записей в системном журнале.

4. Блок питания PSU1 извлекаем из сервера и наблюдаем за BMC сервера, как описано в пункте 3.

5. По истечении 2 часов работы сервера под нагрузкой на одном блоке питания PSU2 фиксируем полученные результаты работы утилиты Stress-ng, чтобы сравнить с результатами, полученными при выполнении пункта 1.

6. Устанавливаем обратно блок питания PSU1. Наблюдаем за BMC сервера, как описано в пункте 3.

7. К блоку питания PSU1 подключаем кабель питания и наблюдаем за BMC сервера, как описано в пункте 3.

8. Повторно выполняем пункты со 2 по 7 включительно для блока питания PSU2.

Критерии успешного прохождения теста

1. Во время работы под нагрузкой сервер доступен по ssh.

2. При отключении от блока питания в BMC появилось уведомление, в системном журнале создалась запись о событии, датчики зафиксировали отсутствие напряжения на блоке питания.

3. При извлечении блока питания из сервера в BMC создалось уведомление, определяется только один блок питания.

4. При возврате блока питания в сервер и подключении кабеля питания в BMC определяются все блоки питания, все датчики с нормальными значениями, в системном журнале создалась запись о наличии напряжения на блоке питания.

5. Результаты утилиты Stress-ng при работе сервера под нагрузкой и на одном блоке питания не отличаются в меньшую сторону больше чем на 10% по сравнению с результатами, полученными при работе сервера под нагрузкой на двух блоках питания.

2. Извлечение накопителей: имитация отказа накопителей

Этапы

1. На свободных накопителях в сервере создаем дисковое хранилище с уровнем резервирования RAID1, RAID6 или RAID10 через BMC, BIOS или с использованием, например, утилиты StorCLI. Тестирование проводим для каждого уровня резервирования дискового хранилища.

2. При возможности один из свободных накопителей настраиваем как резервный (Global Hot Spare).

Для дискового хранилища без файловой системы

1. Запускаем утилиту FIO с профилем нагрузки: 40% случайных операций записи и 60% случайных операций чтения блоком 8 КБ, 16 потоков. Фиксируем производительность в IOPS на чтение и запись.

2. Извлекаем из сервера один из накопителей. До начала перестроения дискового хранилища снова фиксируем производительность в IOPS на чтение и запись. Наблюдаем за BMC сервера на предмет появления уведомлений и создания записей в системном журнале.

3. Контролируем статус и процесс перестроения (rebuild) дискового хранилища, если есть свободный резервный накопитель в сервере (Global Hot Spare). Фиксируем производительность в IOPS на чтение и запись во время перестроения дискового хранилища.

4. При использовании дискового хранилища с уровнем резервирования RAID6 или RAID10 извлекаем второй накопитель из сервера. Фиксируем производительность в IOPS на чтение и запись.

5. По завершении перестроения дискового хранилища все ранее извлеченные накопители устанавливаем обратно. Отслеживаем статус всех накопителей, а также наблюдаем за BMC сервера, как описано в пункте 2.

6. При необходимости через BMC или с помощью утилиты StorCLI в ОС удаляем стороннюю конфигурацию на накопителях и меняем их статусы.

7. По завершении второго перестроения дискового хранилища отслеживаем статус и состав дискового хранилища, а также статус самих накопителей.

Для дискового хранилища с файловой системой:

1. На дисковом хранилище создаем один раздел максимального размера и файловую систему ext4, которую подключаем к директории test1..

2. Запускаем копирование большого файла (несколько десятков ГБ) в директорию test1.

3. Извлекаем из сервера один из накопителей. Отслеживаем статус дискового хранилища и наблюдаем за BMC сервера на предмет появления уведомлений и создания записей в системном журнале.

4. Контролируем процесс перестроения дискового хранилища, если есть свободный накопитель в сервере (Global Hot Spare), и отслеживаем скорость копирования файла.

5. Если используем дисковое хранилище с уровнем резервирования RAID6 или RAID10, извлекаем второй накопитель из сервера.

6. После перестроения дискового хранилища и окончания копирования файла устанавливаем накопители обратно. Отслеживаем статус всех накопителей, а также наблюдаем за BMC сервера, как описано в пункте 3.

7. Вычисляем и сравниваем контрольные суммы файла-источника и скопированного файла.

8. При необходимости через BMC или с помощью утилиты StorCLI в ОС удаляем стороннюю конфигурацию на установленных накопителях с последующим изменением статусов установленных накопителей.

9. После второго перестроения дискового хранилища отслеживаем статус и состав дискового хранилища, а также статус самих накопителей.

Критерии выполнения теста

Дисковое хранилище без файловой системы

1. Работа утилиты FIO не прерывалась во время тестирования, и дисковое хранилище было постоянно доступно на чтение и запись.

2. Сработала автоматическая замена извлеченного накопителя на резервный (Global Hot Spare).

3. Дисковое хранилище успешно выполнило все перестроения.

4. Возврат к начальной конфигурации дискового хранилища (состав и статус накопителей) происходит без перезагрузки сервера.

Дисковое хранилище с файловой системой

1. Файловая система на дисковом хранилище была доступна на протяжении всего времени тестирования.

2. Копирование файла завершилось без прерываний.

3. Сработала автоматическая замена извлеченного накопителя на резервный (Global Hot Spare).

4. Дисковое хранилище успешно выполнило все перестроения.

5. Контрольные суммы файла-источника и скопированного файла остались одинаковыми.

6. Конфигурация дискового хранилища (состав и статус накопителей) вернулась в начальное состояние без перезагрузки сервера.

3. Отключение Ethernet-портов: имитация отказа Ethernet-портов на коммутаторе или на сервере, имитация отказа одного коммутатора

Этапы

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

2. На первом сервере запускаем утилиту iperf3 с ролью «сервер» и запускаем ping до второго сервера.

3. Запускаем копирование большого файла (несколько десятков ГБ) на второй сервер.

4. На втором сервере запускаем утилиту iperf3 с ролью «клиент» не меньше, чем на 1 час.

5. На коммутаторе отключаем один из портов, куда подключены порты второго сервера. Проверяем статус портов на коммутаторе.

6. Фиксируем снижение пропускной способности, исходя из работы утилиты iperf3 на стороне «сервера» и «клиента», контролируем процесс копирования файла и работы ping.

7. На коммутаторе включаем ранее отключенный порт. Проверяем статус портов на коммутаторе.

8. По выводимым результатам работы утилиты iperf3 на стороне «сервера» и «клиента» фиксируем повышение пропускной способности до исходных показателей, контролируем процесс копирования файла и работы ping.

9. По окончании копирования файла вычисляем и сравниваем контрольные суммы файла-источника и скопированного файла.

Критерии выполнения теста

1. Агрегированные сетевые интерфейсы на серверах и на коммутаторе настроены, сетевая связанность между серверами присутствует.

2. При отключении порта на коммутаторе пропускная способность снижается не более чем на 55%.

3. Прерывания при копировании файла и работе ping при отключении порта на коммутаторе отсутствовали.

4. Пропускная способность при включении порта на коммутаторе повысилась до исходных показателей.

5. Контрольные суммы файла-источника и скопированного файла остались одинаковыми.

4. Отключение портов Fibre Channel: имитация отказа портов Fibre Channel на коммутаторе или на сервере, имитация отказа одного коммутатора

Этапы

1. Проверяем, что серверу с СХД презентован LUN через два Fibre Channel коммутатора и доступен не менее чем по двум путям.

2. Проверяем, что в конфигурационном файле /etc/multipath.conf прописаны настройки многопутевого доступа LUN (multipath) для повышения уровня отказоустойчивости в случае аварийных ситуаций в сети хранения данных.

3. Командой multipath-II проверяем, что LUN доступен как единое дисковое хранилище не менее чем по двум путям. Проверяем статус всех путей доступа LUN (должны быть active, ready, running).

Дисковое хранилище без файловой системы

1. Запускаем утилиту FIO с профилем нагрузки: 40% случайных операций записи и 60% случайных операций чтения блоком 8 КБ, 16 потоков. Фиксируем производительность в IOPS на чтение и запись;

2. Последовательно отключаем все порты на одном Fibre Channel коммутаторе, куда подключены порты сервера, так, чтобы дисковое хранилище было доступно через порты другого Fibre Channel коммутатора.

3. При отключении каждого порта контролируем производительность на чтение и запись, фиксируем статусы и количество доступных путей дискового хранилища.

4. Последовательно включаем все ранее отключенные порты на Fibre Channel коммутаторе. Контролируем восстановление производительности на чтение и запись, фиксируем статусы и количество доступных путей дискового хранилища.

Дисковое хранилище с файловой системой

1. На дисковом хранилище создаем один раздел максимального размера, создаем файловую систему ext4 и подключаем к директории test1.

2. Запускаем копирование большого файла (несколько десятков ГБ) в директорию test1.

3. На одном из Fibre Channel коммутаторов последовательно отключаем все порты, к которым подключены порты сервера, так, чтобы дисковое хранилище было доступно через порты другого Fibre Channel коммутатора. Контролируем процесс копирования файла, фиксируем статусы и количество доступных путей дискового хранилища.

4. По окончании копирования файла вычисляем и сравниваем контрольные суммы файла-источника и скопированного файла.

5. Последовательно включаем все ранее отключенные порты на Fibre Channel коммутаторе. Фиксируем статусы и количество доступных путей дискового хранилища.

Критерии выполнения теста

Дисковое хранилище без файловой системы

1. Работа утилиты FIO не прерывалась на всем протяжении тестирования, и дисковое хранилище было постоянно доступно на чтение и запись.

2. Производительность снизилась не более чем на 55% относительно исходных показателей при доступности хранилища через порты одного Fibre Channel коммутатора (измеряем производительность в течение 15 минут после отключения портов на одном коммутаторе).

3. Производительность восстановилась до исходных показателей по мере включения ранее отключенных портов на Fibre Channel коммутаторе.

Дисковое хранилище с файловой системой

1. Файловая система на дисковом хранилище была доступна на всем протяжении тестирования.

2. Копирование файла успешно завершилось без прерываний.

3. Контрольные суммы файла источника и скопированного файла остались одинаковыми.

Тестирование совместимости серверов с модулями доверенной загрузки

Тестирование на совместимость серверов с модулями доверенной загрузки (МДЗ) нужно для определения возможности использования модулей для реализации мер защиты УПД.17 и УД.3.

При тестировании мы должны применять МДЗ не менее трех производителей. Если один из тестов совместимости МДЗ пройден неуспешно, то переходим к тестированию совместимости сервера с МДЗ другого производителя. Однако мы можем провести повторное тестирование, если производитель выпустит исправление для своего МДЗ. Если сервер не прошел тест совместимости ни с одним МДЗ ни одного из производителей, то сервер признается неприменимым в нашей инфраструктуре.

В таблице приведен список функциональных требований МДЗ, подлежащих проверке при выполнении тестирования.

Оценка взаимодействия с поставщиком и производителем серверов

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

Отмечаем, насколько содержательна техническая документация по серверам и доступна ли она для скачивания, а также оперативность предоставления документации, если ее нет в публичном доступе.

Стоп-факторы при оценке применимости серверов

1. Серверы с заведомо более производительными процессорами (больше ядер, выше тактовая частота ядер, больше объем кэш-памяти) по сравнению с эталонным результатом сервера с процессорами Intel Xeon Gold 6254 получают такой же или меньший результат при нагрузочном тестировании во всех используемых утилитах.

2. Полученный результат производительности тестируемых серверов при нагрузочном тестировании меньше результатов, которые размещены на официальных сайтах используемых утилит для серверов с такими же процессорами на 20% или более.

3. Любой из тестов отказоустойчивости пройден неуспешно.

4. В части критических функциональных возможностей серверов стоп-факторы применимости указаны в начале статьи в списке проверяемых функциональных возможностей серверов.

5. Для восстановления работы серверов необходимо обесточивание серверов на любой промежуток времени.

6. Критические замечания (зависание BMC, спонтанные перезагрузки сервера в процессе тестирования, отсутствие уведомлений об ошибках и другие, критически влияющие на эксплуатацию серверов).

7. Серверы несовместимы ни с одним модулем доверенной загрузки.

Заключение

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

Поскольку сейчас мы вынуждены срочно искать и тестировать отечественное железо, ПМИ будет постепенно меняться и дополняться. Сейчас мы планируем добавить утилиту по проведению испытаний производительности баз данных и выбрать утилиту для тестирования кластера из пары серверов на базе отечественных или опенстековых систем виртуализации.

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