Введение

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

Для оценки производительности хранилища, дабы понимать его возможности для выполнения реальных задач, необходимо проведение нагрузочного тестирования. Самыми простыми в реализации являются синтетические тесты, выполняемые, например, с помощью таких популярных утилит как Iometer и Fio. Классическое применение: тестирование локального хранилища узла либо внешней СХД с одного или нескольких узлов.

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

Тестировать общее хранилище для такой инфраструктуры путем запуска Iometer/Fio на одной или нескольких ВМ либо с выделенного узла на голом железе будет некорректным. Такое тестирование должно быть распределенным и обеспечивать параллельную генерацию ввода/вывода и централизованный учет результатов с множества ВМ со всех хостов кластера vSphere. Только такой подход позволит сэмулировать нагрузку реального высоконагруженного виртуального кластера.

Лично я пробовал на своем тестовом кластере vSphere vSAN 6 update 3 из 4х хостов ручками развернуть 4 ВМ на Винде с Iometer, через командную строку подключить Dynamo на 3х ВМ к консоли Iometer на четвертой ВМ, с которой и проводил распределенное тестирование. Даже для 4х ВМ дело это скучное и неблагодарное, разворачивать по несколько ВМ на хост вручную вообще не вариант.

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

Общее представление

HCIBench – это утилита (я бы сказал фрэймвёрк) для автоматизации нагрузочного тестирования хранилища данных vSphere. Собственного движка для генерации ввода/вывода HCIBench не имеет, для выполнения этой задачи он использует менее попсовую, но на мой взгляд более мощную/гибкую, чем Fio и тем более Iometer (хотя они тоже хороши), бесплатную утилиту от Oracle под названием Vdbench.

HCIBench в приемлемом по удобству, простоте и возможностям графическом web-интерфейсе позволяет сформировать задание на тестирование подсистемы хранения после запуска которого остается только дождаться результатов выполнения. Утилита сама развернет заданное пользователем количество тестовых ВМ с нужными параметрами дисков и встроенным Vdbench, равномерно распределив их по узлам кластера, проведет тестирование и сформирует итоговый результат с основными общими показателями производительности. Кроме того, предоставляется возможность просмотра сохраненных журналов работы теста и детальных отчетов для поиска нюансов и устранения проблем.

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

Несмотря на то, что HCIBench, даже судя по названию, разрабатывался как инструмент для тестирования распределенных хранилищ и гиперконвергентных инфраструктур (HCI), прежде всего VMware vSAN, он является универсальным средством тестирования инфраструктуры хранения и совместим с любым хранилищем (datastore) подключенным к vSphere:

• локальные носители хостов и общие ресурсы хранения (local и shared storage);
• блочные и файловые хранилища;
• классические и программные (SDS) СХД;
• единые и распределенные хранилища;
• выделенные и гиперконвергентные хранилища.

Архитектура

HCIBench распространяется в виде готового виртуального эплаенса (файла .ova), включающего управляющую ВМ (Controller VM) и шаблон для развертывания тестовых ВМ (Vdbench Guest VMs).

Управляющая и тестовые ВМ достаточно компактны (4ГБ — ОЗУ и 16ГБ – системный диск) и работают под управлением новой контейнерной ОС от VMware на базе Linux – Photon OS 1.0.

Controller VM включает в себя следующие компоненты:

• Ruby vSphere Console (RVC)
• Средства автоматизации (Automation bundle)
• vSAN Observer
• Конфигурационные файлы



vSAN Observer – утилита VMware, предназначенная для мониторинга состояния кластера vSAN, отображающая различные показатели его работы в виде графиков. Он запускается только в случае тестирования vSAN и помимо результатов Vdbench сохраняет в отчет графики со статистикой работы хранилища в интерактивном формате (html).

Средства автоматизации представляют собой набор скриптов на Ruby и Bash. Пользователь задает конфигурацию тестовый среды и параметры нагрузки, всё это сохраняется в конфигурационных файлах. Скрипты посредством RVC, которая по сути является ядром HCIBench, на основе заданной конфигурации автоматически выполняют тестирование, включающие следующие этапы:

• подключение к тестируемой инфраструктуре vSphere;
• развертывание нужного количества тестовых ВМ с заданным количеством и размером тестовых вДисков (vmdk);
• передача конфигурационных параметров Vdbench, определяющих нагрузку и продолжительность тестирования, на каждую тестовую ВМ;
• запуск vSAN Observer в случае тестирования vSAN;
• запуск сущностей Vdbench на каждой тестовой ВМ – тестируются все развернутые вДиски, продолжительность согласно заданной конфигурации;
• по окончанию теста данные собираются со вcех тестовых ВМ и формируется результирующий отчет.

Развертывание

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



В качестве «Public Network» необходимо указать сеть из которой доступны vCenter и хосты ESXi, это позволит HCIBench получить доступ к инфраструктуре для развертывания тестовых ВМ и проведения тестирования.

Если в «Public Network» развернут DHCP-сервер и есть достаточное количество свободных IP-адресов для проведения тестирования (их может понадобиться очень много), то тестовые ВМ можно разворачивать в этой общей сети (Public Network). Соответственно выбор Private Network можно проигнорировать или назначить туже сеть, что для Public Network.

Если в Public Network нет DHCP-сервера, нет достаточного количество свободных IP-адресов для раздачи тестовым ВМ, есть необходимость разместить тестовые ВМ в отдельной подсети (где также может не быть DHCP-сервера), то мы указываем нужную нам сеть в качестве Private Network и при необходимости используем встроенный в утилиту DHCP-сервер.



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

Интерфейс

После развертывания фреймвёрка необходимо подключиться к его web-консоли по адресу http://HCIBench_IP:8080/ (нужно посмотреть в vSphere-клиенте какой IP-адрес получила Controller VM), авторизоваться паролем root-а и вуаля, можно настраивать и запускать тест.

По порядку сверху вниз пройдемся про всем параметрам страницы конфигурирования HCIBench.

Раздел — vSphere Environment Information

В первых пяти полях указываем доменное имя или IP-адрес сервера vCenter, имя и пароль админа vCenter, имя датацентра и кластера vSphere к которым подключено тестируемое хранилище.

Затем указываем имя сети (имя группы портов vSphere) в которой будут развертываться тестовые ВМ. При необходимости ставим галку включить DHCP, если своего сервиса в данной подсети нет.
В поле «Datastore name» указываем имя Datastore (целевое хранилище) которое будем тестировать. В данном поле можно указать несколько хранилищ для тестирования (каждое в новой строке), тогда тестовые ВМ будут равномерно распределены между всеми указанными хранилищами.

Можно поставить галку «Clear Read/Write Cache» для очистки кэша хранилища перед тестом. Это работает только для vSAN, при этом необходимо указывать параметры доступа к хостам ESXi (поля Host Username и Host Password), для всех хостов они должны быть одинаковы (указать для каждого хоста отдельно не получится).

Раздел — Cluster Hosts Information

Если не ставить галку «Deploy on Hosts», то поле «Hosts», расположенное ниже, нужно оставлять пустым. В этом случае развертывание тестовых ВМ будет производиться через vCenter, они равномерно будут распределены по всем хостам кластера в круговой манере (round-robin). Если мы не активировали параметр «Clear Read/Write Cache», то поля «Host Username» и «Host Password» также нужно оставить пустыми.

В противном случае (поставили галку «Deploy on Hosts») все указанные выше поля необходимо заполнить: в поле «Hosts» указываем доменные имена или IP-адреса хостов (каждое в новой строке), заполняем параметры доступа к хостам (как я уже говорил, логин и пароль админа на всех хостах должны быть идентичны).

При активации режима «Deploy on Hosts» тестовые ВМ устанавливаются на указанные хосты напрямую и параллельно, для сокращения нагрузки на сеть сначала на первые 5 хостов, потом на следующие и так далее с шагом 5 хостов.

В общем случае рекомендуется использовать режим «Deploy on Hosts» при развертывании большого количества тестовых ВМ. Однако, данный режим не поддерживается при использовании распределенных вКоммутаторов – его активация вызовет ошибку на этапе сохранения/проверки теста в конфигурации которого указана сеть, подключенная к распределенной группе портов.

Режим «Deploy on Hosts» также необходим для тестирования носителей или хранилищ, подключенных к определенному хосту напрямую (DAS), в таком случае указываем целевой хост и параметры доступа к нему.

Параметр «EASY RUN» предназначен только для тестов VMware vSAN, его активация позволяет автоматически выбрать оптимальную конфигурацию расположенных ниже параметров исходя из архитектуры тестируемого кластера vSAN. Это позволяет определить нужное количество тестовых ВМ, количество, размер и тип подготовки их вДисков для проведения оптимального тестирования данного кластера. Все расположенные ниже параметры конфигурации будут скрыты при активации «EASY RUN».

Раздел — Vdbench Guest VM Specification

Обязательным параметром является «Number of VMs», он определяет количество тестовых ВМ, которые будут развернуты в инфраструктуре для генерации нагрузки. Остальные параметры раздела опциональны.

«Number of Data Disk» определяет количество вДисков (vmdk), которые будут созданы для каждой тестовой ВМ. Они будут размещаться на тестируемом хранилище и на них будет генерироваться нагрузка Vdbench.

«Size of Data Disk» определяет размер каждого из указанных выше вДисков в ГБ.

Значение обоих параметров по умолчанию равно 10.

Включение параметра «Re-Use The Existing VMs If Possible» позволит повторно использовать развернутые тестовые ВМ в новом тесте, если эти машины существуют (не удалены) и соответствуют параметрам нового теста (параметрам данного раздела: количество ВМ, дисков и их размер).

Раздел — Vdbench Testing Configuration

В поле «Test Name», как несложно догадаться, необходимо указать имя теста и желательно это сделать так, чтобы потом можно было найти нужные результаты. Если поле оставить пустым, утилита автоматом присвоит тесту имя «resultВРЕМЯ».

Результаты всех тестов сохраняются в отдельных папках с именами, соответствующими именам тестов, размещение — /opt/output/results/ на управляющей ВМ, для их просмотра необходимо в браузере ввести адрес http://Controller_VM_IP/results.

Для проведения тестирования необходимо отдать утилите файл параметров Vdbech, его можно сгенерировать самостоятельно на этой же странице – кнопка «Generate» или загрузить готовый файл извне – кнопка «Upload parameter file». После загрузки или генерации файла параметров необходимо нажат кнопку «Refresh», чтобы данный файл стал отображаться в меню «Select a Vdbench parameter file».

Если сгенерировать и/или загрузить несколько файлов параметров, то они все сохранятся и можно будет выбрать нужный в меню «Select a Vdbench parameter file». Ненужные можно удалить кнопкой «Delete».

Рекомендация
Меню «Select a Vdbench parameter file» кроме имен файлов параметров содержит строку «Use all». Вместо того, чтобы для каждого типа нагрузки, которому соответствует свой файл параметров, запускать отдельный тест, целесообразно подготовить набор файлов параметров под каждый тип интересующей нагрузки и выбрать «Use all». В этом случае фреймвёрк сам последовательно проведет все эти тесты и отдельно сохранит их результаты. Это удобно, поскольку продолжительность хорошего теста составляет не менее 1,5 часов, типов нагрузки которую нужно оценить много, отслеживать завершение и запускать каждый тест вручную неудобно, а так можно запустить разом всю последовательность, например, на ночь или на сутки и спокойно утром получить все результаты разом.

Параметр «Prepare Virtual Disk Before Testing» позволяет выполнить подготовку вДисков тестовых ВМ перед тестированием. По умолчанию выбрано значение «NONE» — без подготовки, кроме него есть ещё 2 значения: «ZERO» и «RANDOM». При выборе значения ZERO вДиски при подготовке будут записаны нулями, это позволит избежать задержек на инициализацию хранилища при первоначальной записи. При выборе значения «RANDOM» вДиски при подготовке будут записаны случайными данными, что актуально для тестирования хранилищ с включенной дедупликацией. Это логично, поскольку если вДиск пустой или записан нулями, то дедуплицировать нечего, эффект от работы дедупа при первоначальной записи получить не удастся. Если же вДиск записан случайными данными, дедуп начнет отрабатывать сразу, и эффект от его работы будет более равномерным на всем интервале тестирования.

Параметр «Testing Duration» переопределяет продолжительность тестирования, задаваемую в файле параметров Vdbench. Если такой необходимости нет, то данное поле нужно оставить пустым.

Если поставить галку «Clean up VMs», то по завершении теста все тестовые ВМ будут удалены, в противном случае они будут сохранены, что дает возможность использовать их повторно.

Раздел — Download Vdbench

HCIBench изначально не включает с себя Vdbench, видимо из-за особенностей его распространения. Поэтому после развертывания при первом применении необходимо скачать Vdbench с сайта Oracle (к сожалению придется зарегистрироваться) и загрузить в HCIBench, для этого и нужен настоящий раздел.

Настройка параметров Vdbench

После нажатия кнопки «Generate» открывается окно конфигурирования файлов параметров Vdbench, которые будут применяться для генерации нагрузки на каждой тестовой ВМ.

Возможно задать следующие параметры:

Number of Disks to Test – выбираем количество вДисков каждой тестовой ВМ, для которых будет генерироваться нагрузка, оно должно быть не больше количества определенного в поле «Number of Data Disk» (количество дисков тестовых ВМ).

В моих тестах эти значения всегда совпадали. Однако, можно развернуть пул тестовых ВМ у которых будет, например, по 20 вДисков, и для этого пула провести серию последовательных тестов, которые будут грузить по 5-10-15-20 вДисков за раз. Это возможно при установке галки «Re-Use The Existing VMs If Possible», вместо 4х развертываний ограничиваемся одним для всех 4х тестов.

Working-Set Persentage – выбираем долю пространства вДисков, для которых будет генерироваться нагрузка.

В моих тестах я всегда выбирал значение 100 (100% пространства диска). Можно выбрать другое значение (от 0 до 100), в таком случае будет тестироваться не весь вДиск, а часть его пространства. Логика та же, что и пунктом выше: разворачиваем пул тестовых ВМ 1 раз, затем в каждом новом тесте играемся с долей вДиска, таким образом варьируем нагрузку. Возможно есть другие сценарии.

Number of Threads per Disk – количество потоков нагрузки на вДиск тестовой ВМ, чем больше значение, тем больше нагрузка.

Значение по-умолчанию – 2. С этим параметром можно поиграться выбирая оптимальную нагрузку для тестирования, при этом необходимо учитывать количество тестовых ВМ и вДисков, так, чтобы в результате теста получить адекватное соотношение производительности и задержки. Если тестовых ВМ и вДисков в конфигурации много (от 20-30 вДисков на хост), то параметр следует выбирать в рамках 1-4, если мало, то больше 4. У меня было по 20 вДисков на хост, значение 2 было оптимальным.

Block Size – размер блока, Read Percentage – доля операций чтения, Random Percentage – доля случайных операций. С этим всё понятно, выбираем нужные значения под тип целевой нагрузки.

I/O Rate – лимит IOPS на тестовую ВМ, опциональный параметр, если оставить пустым, лимита нет.

Test Time – продолжительность основного теста в секундах. Интервал времени, в течении которого измеренные показатели учитываются в итоговых результатах теста, говоря иначе, здесь генерируется и учитывается полезная нагрузка теста.

Warmup Time – время прогрева в секундах. Опциональный параметр, задаёт продолжительность прогрева хранилища, который производится перед основным тестом для того, чтобы довести хранилище и кэш до нужной кондиции, заполнить их данными и получить результаты отражающие реальную картину. Генерируемая во время прогрева нагрузка не учитывается в результатах основного теста.

Если мы определенным образом подготовили вДиски перед тестом (поле «Prepare Virtual Disk Before Testing»), то прогрев может оказаться лишним.

В моих тестах я выделял 30 минут на прогрев и 1 час на основной тест, меньше на мой взгляд тестировать не стоит, результат может оказаться сомнительным. Основной критерий, чтобы времени прогрева и тем более основного теста хватило как минимум на одну полную запись всех тестовых вДисков (выбранного объема тестируемого хранилища).

Reporting interval – интервал с которым Vdbench сохраняет промежуточные результаты теста, в секундах. Опциональный параметр, по умолчанию не задан, соответственно по окончанию теста мы видим только итоговые значения за все время тестирования. Можно задать некоторое значение (скажем 5 или 10 минут), тогда в результатах теста мы увидим промежуточные показатели с указанной периодичностью. Это может быть полезно при определенных условиях. Однако, не стоит этим злоупотреблять, при каждом сохранении промежуточного результата Vdbench будет приостанавливать ввод-вывод и это негативно повлияет на общие показатели. Я этот параметр не использовал, оставлял пустым.

Рекомендации по планированию тестов

Каждое тестирование требует подбора правильных параметров исходя из характеристик хранилища и виртуальной инфраструктуры. Основной критерий правильных параметров: выжать из хранилища максимальные показатели производительности (IOPS и Throughput) и сохранить значения задержки (Latency) в разумных пределах. Разумные пределы задержки либо её чёткий порог у каждого свои и определяются задачей: кому-то нужна задержка < 4-10 мс (миллисекунд), кому-то некритично если будут десятки мс (даже пара сотен), а кому-то важны микросекунды.

В случае тестирования VMware vSAN для начала можно запустить «EASY RUN», посмотреть на его показатели и параметры, а затем пробовать их менять и перебирать для получения оптимального результата. Для других хранилищ при подборе параметров придется полагаться на собственный опыт и здравый смысл (провел тест, посмотрел отчет, попробовал увеличить нагрузку, либо снизить если задержки большие). Естественно это долгий процесс, может уйти не один день или даже неделя.

Параметры, с которыми можно поиграться:

• количество тестовых ВМ, минимум 2 ВМ на хост;

• количество вДисков, в среднем 10 вДисков на ВМ;

• объем вДисков, 1-10-20 ГБ на вДиск, возможно больше, все зависит от объемов хранилища и кэша;

• количество потоков на вДиск, про это я писал выше;

• доля пространства вДиска, про это я писал выше.

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

Кстати, это надо учитывать, анализируя показатели производительности, которые заявляют производители СХД. Ваш результат может оказаться сильно хуже, поскольку производитель всё протестил честно, но забыл упомянуть, что всё его тестируемое пространство находилось в кэше.

Сохранение и проверка конфигурации, запуск теста

После настройки всех параметров тестирования необходимо сохранить конфигурацию (кнопка «Save Configuration») иначе будет использована последняя сохраненная. Затем необходимо выполнить проверку конфигурации, убедиться в корректности заданных параметров и доступности тестируемой инфраструктуры. После нажатия кнопки «Validate» начнется проверка, результаты которой будут показаны на всплывающей странице.



Если в конце страницы мы видим фразу «All the config has been validated, please go ahead to kick off testing», значит всё хорошо и можно запускать тест, иначе будет выдана ошибка с описанием причины.

После нажатия кнопки «Test» запускается процесс тестирования и выскакивает окно, отображающее ход процесса, при желании его можно прервать. О завершении теста утилита также оповестит всплывающим окном.

По завершению теста рекомендую обязательно нажать кнопку «Save Result», это сохранит его результат в zip-архиве на Controller VM и загрузит его на ваш локальный ПК, иначе в последствии результаты будет скачать проблематично (через браузер не получится), особенно если вы не любите Linux.

Просмотр результатов

Результаты тестов, как я писал выше, сохраняются в папке /opt/output/results/ на управляющей ВМ, для их просмотра необходимо в браузере ввести адрес http://Controller_VM_IP/results.



Находим папку с интересующим нас тестом (имя папки соответствует имени теста), проваливаемся в неё и видим примерно такую картину:



Количество одноименных файлов (vdb-xxx-res.txt ) и папок (vdb-xxx) зависит от того сколько тестов было проведено под одним именем (поле «Test Name» в консоли). Как я писал выше, можно разом запустить последовательное выполнение множество тестов с разными параметрами («Use all»), тогда все их результаты сохранятся в одной папке, тоже самое будет если не менять имя теста («Test Name»).

Текстовые файлы с именами vdb-xxx-res.txt – самое интересное, они хранят итоговые обобщенные результаты теста, их содержимое выглядит так:

Datastore: vsanDatastore
VMs = 8
IOPS = 157556.66 IO/s
THROUGHPUT = 615.47 MB/s
LATENCY = 1.0114 ms
R_LATENCY = 0.9182 ms
W_LATENCY = 1.2282 ms
=============================
Datastore: vsanDatastore
95th Percentile Latency = 1.0671249999999999
IOPS associated with 95th Percentile Latency = 149653.0
=============================
Resource Usage:
CPU USAGE = 59.33%
RAM USAGE = 24.03%
VSAN PCPU USAGE = 20.287%


Одноименные папки содержат детали каждого теста:


Текстовые файлы vdbench-ххх.txt содержат детали результатов отработки Vdbench на каждой тестовой ВМ. Папка iotest-vdbench-Хvm содержит статистику работы VMware vSAN, собранную vSAN Observer за время работы теста, её результаты в графическом виде можно узреть открыв файл stats.html.

Разборки с проблемами

При появлении проблем в первую очередь необходимо анализировать логи HCIBench, расположенные в http://Controller_VM_IP/hcibench_logs/.



Кроме того, может быть полезно посмотреть результаты отработки Vdbench на тестовых ВМ по отдельности — http://Controller_VM_IP/results/test_name/vdb-xxx/.



Выглядят они так:


С возникающими вопросами и проблемами помогают разобраться непосредственно разработчики фреймвёрка на его официальной странице.

Итоги

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

Использование HCIBench в тестах storagereview.com также вызывает уважение.