Николай Куликов опубликовал своё руководство по тестированию систем хранения на английском языке, поэтому захотелось получить русский вариант. Данный перевод выполнен ИИ с моими правками (возможны правки формулировок).
Введение
Определение целей бенчмаркинга
Выбор подхода и методологии бенчмаркинга
- Перенос или клонирование существующей производственной рабочей нагрузки на тестовую систему
- Синтетические бенчмарки на уровне приложений
- Синтетический бенчмарк хранилища данных
Выбор инструментов и утилиты для синтетического бенчмаркинга хранилища данных
Формирование конфигурации демонстрационной среды
Введение
За более чем десять лет работы в ИТ-индустрии я провел множество тестов и проверок концепций (proof-of-concepts, POC) различных систем хранения данных (СХД). Хотя это были совершенно разные типы систем хранения – традиционные SAN-системы хранения с подключением по FC, NAS, SDS (Software Defined Storage, программно-определяемое хранилище) и платформы HCI (Hyper Converged Infrastructure, гиперконвергентная инфраструктура), задачи были практически одинаковыми. И довольно часто я сталкивался с ситуацией, когда тесты никак не соответствовали потребностям бизнеса и даже были технически некорректны, что приводило к невозможности получить какие-либо значимые результаты.
Все мы знаем, насколько критически важными могут быть системы хранения данных для ИТ- и бизнес-операций. Мы также знаем, как много усилий требуется от всех вовлеченных сторон, чтобы правильно протестировать систему хранения и получить значимые результаты, способствующие процессу принятия решений. Именно поэтому я верю, что хорошо структурированный подход с полным вниманием к деталям является обязательным условием для любого вида тестирования и/или бенчмаркинга систем хранения данных.
В большинстве случаев валидация/POC систем хранения данных состоит из трех частей – тесты доступности, функциональные тесты и тесты производительности (они же бенчмаркинг):
- Функциональные тесты очень специфичны для конкретной организации, поскольку они должны быть согласованы с ИТ-ландшафтом заказчика, бизнес-процессами и другими отличительными аспектами.
- Тесты доступности требуют много времени, но это самая очевидная часть – заказчик должен составить список потенциальных рисков, описать ожидаемое поведение в каждом случае, определить с производителем/поставщиком/дистрибьютором варианты моделирования таких сценариев и выполнить такие тесты.
- Тесты производительности или бенчмаркинг – сложная и часто противоречивая часть плана тестирования, потому что это всегда баланс между применимостью и точностью против осуществимости и сложности.
В этом руководстве я рассмотрю только аспект тестирования производительности, и он будет связан в основном с синтетическим бенчмаркингом основной системы хранения общего назначения. Основная цель данного руководства – предоставить указания и рекомендации по проведению бенчмаркинга любого типа корпоративных систем хранения данных для получения значимых результатов при минимизации усилий. Я не буду много говорить об общих вещах, связанных с тестированием в целом и с организацией POC.
Это руководство состоит из двух частей – первая часть более универсальна и подходит практически для любой ситуации, когда вам необходимо провести синтетическое нагрузочное тестирование. Поэтому она состоит в основном из общих приемов, лучших практик и рекомендаций (хотя я постараюсь добавить больше примеров), а не из конкретных действий. Вторая часть – практическая и конкретная, где я на примере показываю, как можно проводить нагрузочное тестирование и как каждый из параметров нагрузочного тестирования влияет на результат.
Чтобы быть более конкретным и, по сути, отразить мой самый последний опыт, все дальнейшие примеры будут связаны с тестированием систем хранения данных в среде виртуальной инфраструктуры VMware. Однако эти рекомендации могут быть применены и в других случаях с минимальными изменениями.
Определение целей бенчмаркинга
Первый и самый важный вопрос, на который вы должны точно и подробно ответить перед началом планирования бенчмаркинга: “Какова цель (согласованная с потребностями бизнеса) этой деятельности? Каким должен быть результат и к какому выводу я должен в конечном итоге прийти?”. Чтобы ответить на этот вопрос, необходимо провести беседу со всеми ключевыми заинтересованными сторонами, включая владельца проекта, системных администраторов и владельцев приложений. Это критически важный шаг, прежде чем двигаться дальше.
Цели могут быть разными в зависимости от ситуации, но основными являются следующие:
- Доказать, что система(ы) хранения удовлетворяет(ют) потребности ваших приложений и служб.
- Определить пределы и максимумы системы, чтобы быть готовым к тому, что система насытится и не сможет дальше удовлетворять потребности потребителей.
- Определить регулируемые настройки и параметры системы для использования в продуктивной среде, поскольку они могут повлиять на производительность. Примерами таких настроек являются дедупликация, сжатие, тип избыточного кодировании (erasure coding), RAID-уровни, реализация технологий аварийного восстановления/катастрофоустойчивости, таких как репликация (и тип репликации), и т.д., а также понимание их влияния. Также определите, нужно ли настраивать какие-либо дополнительные параметры.
Довольно часто цель описывается как “сравнить различные системы хранения данных, чтобы выбрать, какую из них приобрести”. Если вы задумаетесь об этом на минуту, то поймете, что это не сама цель – это лишь следствие одной из вышеперечисленных целей. Прежде всего, вам нужно решить, какую конфигурацию системы хранения (лицензии, сырая ёмкость(RAW), узлы и т.д.) вам следует приобрести. Всегда хочется сравнивать яблоки с яблоками, а для этого в вашем распоряжении должны быть точные цифры.
Если вы выбираете систему хранения данных для четко определенной и предсказуемой рабочей нагрузки (например, для налаженной продуктивной среды), не стоит основывать свое решение на чистой производительности. Не имеет значения, в 2 или 3 раза быстрее требуемая система хранения данных – и та, и другая способны справиться с вашими рабочими нагрузками, и решение следует принимать на основе функциональных, финансовых и других критериев.
В противном случае, если вы ищете систему хранения для новых и/или непредсказуемых рабочих нагрузок, максимальные показатели системы важны для понимания потенциала и пределов возможностей системы.
Итак, перед началом любого бенчмаркинга необходимо определить и установить цели, критерии успеха и согласовать их со всеми заинтересованными сторонами.
Популярные примеры целей бенчмарка:
“Убедиться, что система хранения способна справиться с рабочей нагрузкой от приложений A, B и C (или любой части инфраструктуры), и определить параметры и конфигурацию системы хранения, при которых это возможно”.
“Определить максимальное количество пользователей приложений X, Y, Z, которые могут обрабатываться на системе хранения данных, оставаясь в пределах допустимого времени отклика. Проанализировать влияние параметров/конфигурации системы хранения (например, дедупликации и сжатия) на количество обслуживаемых пользователей.”
“Определить возможное количество виртуальных машин, которые могут быть развернуты из частного облака, при условии, что они соответствуют текущим средним показателям с точки зрения производительности и емкости.”
Выбор подхода и методологии бенчмаркинга
После определения целей необходимо выбрать способ создания нагрузки и измерения производительности. Вообще говоря, я могу выделить три типа подходов:
- перенос или клонирование производственной рабочей нагрузки (другими словами, тем или иным способом воспроизвести реальную нагрузку);
- синтетический бенчмаркинг на уровне приложения;
- синтетический бенчмаркинг на уровне хранилища.
Давайте подробно рассмотрим каждый подход.
Перенос или клонирование существующей производственной рабочей нагрузки на тестовую систему
В данном случае необходимо определить ключевые показатели для измерения, критерии успеха и воспроизвести/проанализировать существующую рабочую нагрузку на тестируемой системе хранения. Я настоятельно рекомендую выбирать метрики, ориентированные на бизнес, а не на ИТ. Эти метрики должны быть согласованы с бизнес-операциями и соответствующими целями и задачами, такими как обслуживание клиентов или другими. Например, это может быть время отклика приложения с точки зрения конечного пользователя, время обработки бизнес-запросов, время создания отчетов, количество пользователей, которые могут использовать приложение с приемлемым временем отклика, и т.д. После этого необходимо перенести или клонировать приложение в новую систему и сравнить ключевые метрики. Если вы решили клонировать рабочую нагрузку, необходимо помнить, что количество пользователей и активность их взаимодействия с системой должны быть соизмеримы с исходной системой или масштабироваться соответствующим образом.
Такой подход является наиболее точным способом оценить поведение рабочей нагрузки на тестируемой системе. Это также эффективный способ настройки и выбора параметров системы хранения данных совместно с производителем, партнером и заказчиком.
В то же время, это самый трудный способ, требующий наибольшего количества ресурсов, времени и глубокого вовлечения владельцев приложений. Сложность таких тестов часто делает этот подход практически нежизнеспособным, особенно в ситуациях, когда хранилище будет использоваться совместно несколькими бизнес-приложениями. Если вы решите перенести существующие приложения на новую тестируемую систему, вам следует тщательно управлять соответствующими рисками, поскольку если что-то пойдет не так, это повлияет на продуктивную среду, а значит, и на текущие бизнес-операции. Кроме того, этот подход применим только к существующим рабочим нагрузкам, а не к будущим потребностям.
С учетом вышесказанного, этот метод обычно применяется в качестве окончательного подтверждения, когда система уже отобрана после первого раунда тестирования, а хранилище предполагается использовать для конкретного критически важного для бизнеса приложения, такого как основная банковская система, ERP и т.д.
Синтетические бенчмарки на уровне приложений
Как правило, бенчмаркинг на уровне приложения представляет собой комбинацию реального приложения и программного обеспечения, генерирующего нагрузку. Примеры включают:
- Любая база данных SQL (MS SQL, Oracle, PostgreSQL, MariaDB и т.д.) + HammerDB.
- Веб-сервер + wrk/ApacheBenchmark (или JMeter, но он сложнее и обычно используется для сквозного бенчмарка веб-приложений).
- SAP + SAP Standard Application Benchmark.
- Среда VDI + LoginVSI.
В зависимости от сценариев использования системы хранения данных стоит использовать один или несколько таких бенчмарков на уровне приложений.
Эти тесты достаточно репрезентативны (хотя могут не полностью учитывать специфику приложений заказчика), их легче использовать благодаря готовым планам тестирования и они дают возможность довести систему до её ограничений за счет масштабирования количества испытателей(workers)/генераторов нагрузки.
Но все же часто требуется участие владельца приложения, и иногда трудно интерпретировать результаты, особенно в смешанных средах. Кроме того, бывает проблематично выделить влияние хранилища на общий результат из-за влияния процессора, сети и т.д.
По этим причинам данный метод обычно используется для сравнения систем хранения данных или для проверки применимости существующей системы для конкретной рабочей нагрузки.
Синтетический бенчмарк хранилища данных
Концепция полностью отличается от предыдущих подходов – нет реального приложения, только инструмент, который отправляет запросы ввода-вывода с необходимыми параметрами в зависимости от ожидаемой рабочей нагрузки в нижележащую инфраструктуру. Обработка данных на уровне приложения отсутствует, как и реальные данные.
Основными преимуществами этого метода являются гибкость и простота использования. Участие команд приложений не требуется, инфраструктурная команда может выполнить все тесты самостоятельно. Тесты легко автоматизируются, поэтому можно параллельно проводить тестирование многих систем хранения данных, что значительно сокращает продолжительность POC.
Однако следует быть очень внимательным при работе с синтетическими бенчмаркингами систем хранения данных, поскольку очень легко провести абсолютно бессмысленные тесты и в итоге получить нерелевантные выводы, хотя на первый взгляд они выглядят нормально. В то же время, хотя синтетические тесты и могут показать репрезентативные результаты с точки зрения общей производительности, гораздо сложнее предсказать некоторые нюансы для конкретного приложения.
Собственно говоря, ошибочно воспринимаемая простота синтетических бенчмарков для систем хранения данных и их ошибочность стали основными причинами, по которым я решил написать это руководство. Далее в этом руководстве я сосредоточусь только на синтетическом бенчмарке не потому, что это лучший способ тестирования производительности системы хранения, а потому, что это самый популярный подход, который меньше всего зависит от специфики конкретной среды.
Выбор инструментов и утилит для синтетического бенчмаркинга хранилища данных
Как я уже говорил, для синтетических эталонных тестов нам нужен инструмент, который подготавливает данные, отправляет запросы ввода-вывода в хранилище, собирает и анализирует результаты. Он должен быть достаточно гибким и настраиваемым, чтобы соответствовать вашей инфраструктуре и целям. Кроме того, он должен поддерживать сценарии автоматизации и оркестровки.
Золотым стандартом в отрасли являются FIO, Vdbench и DiskSPD. Все они хорошо зарекомендовали себя, широко применяются и являются кроссплатформенными, но исторически DiskSPD чаще используется в средах Microsoft, а FIO или Vdbench – в средах Linux. Не вдаваясь в подробности, можно сказать, что они предоставляют схожие возможности для бенчмаркинга систем хранения данных и имеют схожие кривые обучения, поэтому выбор инструментов обычно основывается на опыте и привычках.
Существует также несколько ориентированных на ПК бенчмарков накопителей, таких как CrystalDiskMark/HDTune/PCMark/etc. ПОЖАЛУЙСТА, не используйте их для бенчмаркинга корпоративных систем хранения данных. Они неплохи сами по себе (более того, например, CrystalDiskMark построен на базе DiskSPD), но их цели и сценарии использования совершенно разные. Отсутствие контроля и настройки, а также отсутствие поддержки кластеризации делает их малоприменимыми для корпоративных нужд. Большинство корпоративных сред создают сложные профили рабочей нагрузки из многих источников параллельно, а не из одной ОС, наборы данных составляют десятки и сотни ТБ, нагрузка генерируется непрерывно в течение часов и дней, а не минут и нескольких ГБ, как это происходит на ПК.
Другой тип бенчмаркинговых утилит построен поверх FIO/Vdbench и использует их в качестве генератора рабочих нагрузок. Они предоставляют больше возможностей, таких как графический интерфейс, развертывание и автоматизация из коробки, планирование, сценарии и т.д., сохраняя при этом FIO/Vdbench в качестве генератора рабочей нагрузки.
HCIBench – один из таких инструментов, чрезвычайно популярный для бенчмаркинга систем хранения данных в средах VMware vSphere. Изначально он был создан для бенчмаркинга платформ HCI, но теперь может использоваться универсально с любым типом хранилища. В двух словах, это готовое к развертыванию виртуальное приложение (virtual appliance) с управляющей виртуальной машиной (ВМ) и парком виртуальных машин с движками рабочих нагрузок. Управляющая ВМ обеспечивает пользовательский интерфейс для конфигурации и просмотра результатов, содержит образ микро-ВМ с предустановленным FIO/Vdbench, а также скрипты для автоматизации развертывания, запуска, сбора данных и т.д. Более подробную информацию о настройке можно найти в этой статье блога VMware, а примеры тестовых профилей – на этой странице Github. Если вы ищете дополнительные возможности автоматизации HCIBench, загляните в эту статью Industrialising storage benchmarks with Hosted Private Cloud from OVHcloud – OVHcloud Blog from OVHCloud.
Высокоуровневая архитектура HCIBench
Технически вы можете достичь такого же или даже лучшего уровня автоматизации с помощью пользовательских скриптов, но это редко имеет смысл из-за значительных временных затрат. Поэтому, если основной задачей вашей системы хранения является размещение хранилищ данных виртуальной инфраструктуры VMware, то вполне разумно использовать HCIBench в качестве инструмента бенчмаркинга по умолчанию и переходить на пользовательскую настройку FIO/Vdbench, если на то есть причины. Главная ценность HCIBench заключается в том, что он использует общепринятые генераторы рабочих нагрузок (вы можете выбрать FIO или Vdbench) и обеспечивает полный контроль над параметрами бенчмарка, ничего не скрывая от вас и не предполагая за вас. Очень важно иметь полный контроль над инструментом – ничего не должно быть решено за вас, настроено по умолчанию или скрыто за кулисами.
Формирование конфигурации демонстрационной среды
Аппаратное обеспечение
В идеале вы должны тестировать ту же конфигурацию системы хранения, которую планируете приобрести. Однако, это редко происходит в реальной жизни из-за ограничений пула демонстрационных систем на стороне производителя/системного интегратора. Иногда можно воспользоваться программой “try-and-buy” (“Попробовал? Купи!”), но обычно производители предлагают такую возможность только для окончательной проверки. По условиям такой программы заказчик обязуется выкупить систему, если она соответствует заранее установленным квалификационным критериям. В противном случае система возвращается обратно производителю/системному интегратору. Это может быть приемлемым вариантом валидации, но не очень с точки зрения сравнения производителей.
Чаще всего, система, которую вы получаете для испытаний, будет слабее вашей целевой конфигурации. В этом случае, следует тестировать хранилище того же класса, поколения и модели. Компоненты должны быть одного класса производительности и типа – если вы планируете приобрести СХД с дисками SATA/SAS и интерфейсами FC/SCSI, то нет смысла тестировать All NVMe СХД с подключением NVMe-o-F поверх RoCEv2, даже если контроллер СХД совпадает. Также одинаковыми должны быть версии программного обеспечения (ПО) СХД и конфигурация/режим ПО СХД (например, варианты NetApp ASA/AFF, режимы ПО Unified/Block Optimized для Dell EMC Powerstore T и т. д.).
С другой стороны, может быть нормально, если система имеет меньшую ёмкость, диски или узлы, если вы понимаете процесс масштабирования. Но будьте осторожны, потому что во многих случаях это не так очевидно. Например, многие массивы All Flash достигают плато производительности при 10-30 SSD-накопителях, потому что контроллер становится узким местом. Это приводит к тому, что общая производительность системы хранения с 24 SSD и 100+ будет одинаковой. Другой пример – увеличение количества контроллеров (SAN/NAS) или узлов (SDS, HCI) не всегда приводит к росту производительности для отдельного LUN/Share/vmdk, несмотря на общее увеличение производительности.
Поэтому очень важно подробно обсудить все это с производителем, запросить доказательства/тесты/бенчмарки, а после этого попытаться провести собственное тестирование (даже в минимальном масштабе) для подтверждения концепции.
После подготовки и определения целей/критериев успеха следует указать конфигурацию системы, подходящую для бенчмарка, и запросить ее для POC.
Программное обеспечение
Эта часть может быть сложной на практике, но простой в теории:
- Проверьте версии программного обеспечения и установите последние (поддерживаемые аппаратными и программными компонентами) обновления на каждый компонент тестовой среды.
- Точно проверьте списки совместимости сверху вниз.
- Установите и настройте тестовую среду в соответствии с применимыми руководствами по лучшей практике.
- Проверьте настройку с производителем/системным интегратором и получите письменное подтверждение того, что настройка выполнена правильно (соответствует лучшим практикам).
При настройке среды документируйте все параметры и настроенные опции. Скорее всего, вам покажется, что легко запомнить всего несколько флажков, но я уверяю вас, что через несколько месяцев вы уже ничего не вспомните. Хорошей практикой является выполнение любых настроек и операций с включенной записью экрана (я обычно использую облачную запись Zoom, даже если настройку выполняю только я). Таким образом, вы сможете в любой момент проверить любые детали и/или доказать свою правоту.
Заключение
Тестирование производительности – это не простая, но, безусловно, чрезвычайно важная процедура, поскольку она создает основу для принятия долгосрочных решений, которые могут оказать непосредственное влияние на производственные процессы и достижение бизнес-целей.
Тщательная подготовка и планирование являются критическими факторами успеха для успешного нагрузочного тестирования. Это в равной степени относится к определению целей, сбору данных и подробному описанию программы испытаний. Если подготовка проведена до конца, то само тестирование становится простым, понятным и даже, в некотором смысле, рутинным действием.
Во второй части я покажу вам, какие именно данные необходимы для успешного синтетического бенчмаркинга, как их получить и как сформулировать критерии успеха.