Бенчмаркинг является широко обсуждаемой темой в компьютерной индустрии из-за бесчисленных методов и подходов. Однако в этом блоге не будут перечислены все эти подходы, а будет дано представление о том, как мы сравниваем различные типы хранилищ, доступных в рамках наших решений на основе размещенного частного облака.
Прежде чем обсуждать это более подробно, мы должны понять, почему мы в первую очередь ориентируемся. Причина номер один в том, что мы должны оценить влияние на наших клиентов, прежде чем что-то вводить в производство. Это может быть что угодно, от новой платформы хранения, новой модели диска, патча ядра, до обновления прошивки и любого количества вариантов использования.
Короткий рассказ
По мере того, как мы продолжаем совершенствовать нашу инфраструктуру хранения и внедрять новые технологии хранения, мы регулярно совершенствуем наши методологии и инструменты сравнительного анализа. С тысячами аппаратных ссылок и равным количеством конфигураций количество эталонных тестов, которое нам нужно достичь, является экспоненциальным. Вот почему жизненно важно индустриализировать процесс.
Стремясь повысить прозрачность, мы решили провести наши тесты с точки зрения конечного пользователя. Это означает, что вся оркестровка, которую мы описываем в этом сообщении в блоге, может быть выполнена любым из наших клиентов Hosted Private Cloud.
Инструменты и оркестровка
FIO, vdbench, I / O Meter, (dd!) — это лишь некоторые из широко используемых и проверенных инструментов для тестирования хранилища. Они дают вам обзор сырой производительности для данного типа хранилища. Но что, если вы хотите сравнить всю инфраструктуру от начала до конца? Это может включать 1, 10, 100, 1000 виртуальных машин или более, с несколькими настройками диска / рейда, несколькими размерами дисков, несколькими размерами блоков. Все с различными общими рабочими нагрузками, состоящими из определенного процента операций чтения / записи, последовательных или случайных и выполняемых таким количеством потоков. Вам также необходимо использовать рабочие нагрузки, соответствующие вашим рабочим нагрузкам. На самом деле комбинации бесконечны.
Учитывая все это, для нашей первой итерации мы начали использовать HCIbench для автоматизации наших тестов.
Тест гиперконвергентной инфраструктуры
HCibench (https://flings.vmware.com/hcibench) — это бесплатный инструмент автоматизации тестирования с открытым исходным кодом. Он определяет себя как «Гиперконвергентный контрольный показатель инфраструктуры». По сути, это оболочка автоматизации вокруг популярных и проверенных инструментов тестирования производительности с открытым исходным кодом: Vdbench и Fio, упрощающая автоматизацию тестирования в кластере HCI. HCIBench стремится упростить и ускорить тестирование производительности POC-клиентов согласованным и контролируемым образом. Инструмент полностью автоматизирует сквозной процесс развертывания тестовых виртуальных машин, координации прогонов рабочей нагрузки, агрегирования результатов тестирования, анализа производительности и сбора необходимых данных для устранения неполадок.
HCIbench так же прост в установке, как и развертывание OVA (Open Virtual Appliance) в вашей инфраструктуре VMware:
Как только HCIbench настроен, просто укажите в браузере https: // IP: 8483, и вы готовы начать тесты:
После ввода учетных данных vCenter и некоторой дополнительной информации (центр обработки данных, кластер, сеть, хранилище данных и т. Д.) Вы сможете настроить параметры гостевых виртуальных машин:
- Количество виртуальных машин для развертывания
- Количество дисков для каждой виртуальной машины
- Размер диска
- Инструмент тестирования (FIO или vdbench)
- Файл параметров ввода / вывода (подробности см. Ниже)
- продолжительность
- И более …
Затем HCIbench возьмет на себя все операции по развертыванию / переработке ВМ и выполнит ваш тест. Результаты доступны в различных формах, от интерфейсов Grafana до файлов Excel или просто текстовых файлов для дальнейшего внешнего анализа…
Файлы параметров рабочей нагрузки, моделирование операций ввода-вывода
Файлы параметров рабочей нагрузки (здесь используется vdbench) лежат в основе всех операций тестирования. Они описывают модель ввода-вывода, которую вы хотите запустить для данной конечной точки хранения. Доступны процент чтения / записи, случайный / последовательный, размер блока, потоки и многие другие параметры.
Мы выбрали 3 различных подхода для оценки наших платформ хранения: общие рабочие нагрузки, прикладные рабочие нагрузки и производственные рабочие нагрузки.
«Общие» рабочие нагрузки
Под «общими» рабочими нагрузками мы понимаем все рабочие нагрузки, которые выглядят как «ТОЛЬКО СЛУЧАЙНЫЕ ЧИТАНИЯ» или «ТОЛЬКО ПОСЛЕДОВАТЕЛЬНЫЕ ПИСЬМА». Они позволяют нам проверить, как тип хранилища реагирует на линейные случаи и как он работает с «экстремальными» случаями.
Пример «универсального» файла параметров рабочей нагрузки vdbench
root@photon-HCIBench [ /opt/automation/vdbench-param-files ]# cat
GENERIC-ONLY-READS-RANDOM-16K-vdb-1vmdk-80ws-16k-100rdpct-100randompct-4threads
*SD: Storage Definition
*WD: Workload Definition
*RD: Run Definitionsd=sd1,
lun=/dev/sda,openflags=o_direct,
hitarea=0,range=(0,80),
threads=4,
wd=wd1,
sd=sd1,
rd=run1,
xfersize=16k,
rdpct=100,
seekpct=100,
iorate=max,
elapsed=120,
interval=1
«Прикладные» рабочие нагрузки
Под «прикладными» рабочими нагрузками мы понимаем рабочие нагрузки, которые соответствуют распространенным производственным сценариям использования, таким как «DATABASE WORKLOAD», «VDI WORKLOAD», «BACKUP WORKLOAD» и т. Д. С помощью этих тестов мы можем эмулировать типичную рабочую нагрузку и проверять области, где данный тип хранилища первенствует.
Пример файла параметров рабочей нагрузки vdbench «Приложение»
root@photon-HCIBench [ /opt/automation/vdbench-param-files ]# cat
OLTP-SQL-Oracle-Exchange-vdb-1vmdk-80ws-16k-100random-70rdpct-4threads
*SD: Storage Definition
*WD: Workload Definition
*RD: Run Definitionsd=sd1,
lun=/dev/sda,
openflags=o_direct,
hitarea=0,range=(0,80),
threads=4wd=wd1,
sd=(sd1),
xfersize=16k,
rdpct=70,
seekpct=100,
rd=run1,
wd=wd1,
iorate=max,
elapsed=120,
interval=1
«Производственные» нагрузки.
Наконец, еще один подход, над которым мы работаем, — это возможность «записывать» производственную рабочую нагрузку и «воспроизводить» ее на другой конечной точке хранилища, чтобы оценить, как целевое хранилище работает с вашей рабочей нагрузкой без необходимости запуска на ней реального производства. Хитрость заключается в том, чтобы использовать комбинацию из 3 инструментов blktrace, btrecord и btreplay для отслеживания и отслеживания вызовов ввода-вывода низкого уровня и возможности воспроизведения этих трассировок на другой платформе хранения.
В следующем сообщении мы поделимся этой возможностью с вами, следите за обновлениями!
Индустриализация HCIbench выполняется с помощью планировщика Rundeck
Как мы видели, с помощью нескольких щелчков мыши мы можем определить и запустить эталонный сценарий для конкретной рабочей нагрузки. Развертывание и утилизация зондирующих виртуальных машин полностью автоматизированы. Что, если затем мы хотим выполнить несколько сценариев? Например, как часть полной проверки новой платформы хранения? В этот момент мы начали использовать Rundeck (http://www.rundeck.com), бесплатный и открытый планировщик автоматизации Runbook, перед HCIbench. Идея состоит в том, чтобы иметь возможность создавать полные коллекции сценариев тестирования.
Первым шагом было понять, как HCIbench работает под капотом, чтобы мы могли управлять им с помощью планировщика Rundeck. HCIbench предназначен для использования через веб-интерфейс, но вся механика, стоящая за ним, выполняется с помощью чистых и отдельных скриптов, таких как start / stop / kill. Все настройки бенчмарка хранятся в чистом плоском файле конфигурации, который было легко преобразовать в шаблон…
Шаблонный файл конфигурации HCIbench
root@photon-HCIBench [ /opt/automation/conf ]# cat template.yaml
vc: '<VCENTER_HOSTIP>'
vc_username: '<USERNAME>'
vc_password: '<PASSWORD>'
datacenter_name: '<DATACENTER>'
cluster_name: '<CLUSTER>'
number_vm: '<NUMBERVM>'
testing_duration: '<DURATION>'
datastore_name:- '<DATASTORE>'
output_path: '<OUTPUT_PATH>'
...
Bench “root job”
Задание rundeck состоит из последовательности шагов, которые будут выполняться в определенном списке узлов. В нашем контексте узлами являются виртуальные машины, работающие под управлением HCIbench.
То, что мы называем «корневым заданием», — это рабочее задание, которое является основной точкой входа. Его общая роль должна вызываться другими работами и запускать один конкретный стенд.
Параметры (параметры) этого задания — это все элементы из шаблона конфигурации HCIbench (см. Выше).
Рабочий процесс для этой работы выглядит следующим образом:
- Разбор вариантов работы
- SSH подключиться к HCIbench VM
- Заполните шаблон конфигурации с соответствующими параметрами работы
- Запустить HCIbench
Верстак
Во-вторых, у нас есть «рабочие места». Через API rundeck мы создали задания для каждой рабочей нагрузки, чтобы иметь возможность запускать стенды индивидуально или по группам, как требуется. Каждое из этих «рабочих заданий» называется «корневым заданием», описанным выше, с соответствующими параметрами.
«Супер» рабочие места
Наконец, у нас есть «Супер рабочие места». Это наборы заданий, их рабочие процессы представляют собой серию вызовов рабочих мест. Мы используем механизм опций каскадирования для передачи опций через задания. В приведенном ниже примере мы тестируем кластер vSAN через полную панель моделей ввода / вывода.
Еще одна интересная особенность использования Rundeck в качестве планировщика HCIbench — это возможность хранить все журналы с виртуальных машин HCIbench и время каждого теста в одном месте. Таким образом, легко просматривать и искать все наши тесты или ориентироваться на конкретное поведение, показанное графикой.
Результаты и варианты использования
VSAN
Интеграция vSAN в наш продукт Hosted Private Cloud была типичным эталонным проектом, в котором нам нужно было не только проверить, как работает вся платформа в каждой области, но и уточнить дизайн самой платформы. С одной стороны, мы оценили аппаратные конструкции с несколькими ссылками на диски, а с другой стороны мы улучшили дизайн программного обеспечения, оценивая различные группы дисков vSAN и конфигурации кэша.
Влияние нового ядра на массивы хранения
Другой интересный случай использования — это когда мы оцениваем влияние нового ядра на наши массивы хранения на основе OmniOS (http://www.omniosce.org). OmniOS — это бесплатная операционная система с открытым исходным кодом, основанная на OpenSolaris, которая объединяет некоторые замечательные технологии, такие как поддержка зон ZFS, DTrace, Crossbow, SMF, Bhyve, KVM и Linux. Этот случай показывает не только немного лучшую производительность, но и значительное улучшение обработки ввода-вывода.
Действительно, среди множества различных тестов новое ядро (r151022) демонстрирует гораздо более стабильные и линейные операции ввода-вывода. Этот стенд также подтверждает несколько исправлений ZFS / NFS, которые были включены в это ядро и которые устраняют проблемы с задержкой во время моментального снимка отправки / получения ZFS.
Индустриализация наших тестов позволила нам контролировать производительность нашего хранилища. Прежде всего, поскольку мы создали их с учетом потребностей наших пользователей, мы согласны с тем, что получат наши клиенты. Кроме того, эталонные тесты дают нам представление об устранении проблем хранилища, которые очень специфичны и / или видны только на виртуальных машинах. Мы планируем расширить это, чтобы мы могли проверить, как работает сторона вычислений (CPU / RAM /…). Наконец, мы сейчас сосредоточены на функции рабочей нагрузки записи / воспроизведения, позволяющей нашим пользователям прогнозировать, как их рабочая нагрузка будет работать на платформах «XYZ», без необходимости фактически запускать на них свою производственную среду. Мы подробно расскажем об этом в следующем сообщении, следите за обновлениями.
