Комментарии 17
Спасибо, прям хорошо!
Ждём вторую часть про то, как сдернуть профиль рабочей нагрузки (с тем самым пятном) с существующей инфраструктуры заказчика для воспроизведения на стенде.
Я вот тут не много писал об этом Enterprise Storage Synthetic Benchmarking Guide and Best Practices. Part 2. Success Criteria and Benchmarking Parameters.
Оо.. интересный материал, спасибо. Но не могу отделаться от настороженного отношения к HCIbench. Однокомпонентные нагрузки как-то понятнее, без Random/Sequential Ratio, например. Но когда виртуалки и облака, видимо всё равно к этому приду.
Enterprise СХД крайне редко работают только на одну нагрузку (если мы не говорим про отдельные кейсы, когда СХД целиком отдается под один приклад типа АБС или mission-critical СУБД), обычно источником нагрузки является множество клиентов/приложений и т.д. Поэтому и тестировать их надо под такой же смешанной нагрузкой, ибо это обычно намного релевантнее и ближе к действительности.
А насчет HCIBench - это просто обвязка по автоматизации и GUI над теми же vdbench и FIO. Сам по себе он не генерирует никакую нагрузку - он просто деплоит worker'ы, создает конфигурационный файл в зависимости от того, что вы накликали в интерфейсе, разливает его воркеры, а потом собирает результаты. Ровно то же самое вы можете сделать в fio/vdbench руками. Я об этом тоже упоминал, но в первой части статьи :)
При этом вам абсолютно ничего не мешает развернуть хоть только одну ВМ через него и тестировать обычный datastore c SAN/NAS СХД. Сам профиль тестирования может быть тоже абсолютно любой - просто создайте конфигурационный файл fio/vdbench руками и загрузите в HCIBench. Но надо отметить, что работает он только с vSphere.
да, посмотрел все части и трогал HCIbench тоже. ) Я встречался с результатами HCIbench от заказчиков и было много спорного и непонятного (для меня). Насколько адекватно выбрана смешанная нагрузка - вопрос. Как понять, насколько она правильно выбрана? Верить разработчикам HCIbench на cлово? Например, в некоторых тестах 90% рандом, а почему именно 90%? Зачем нужны 10% seq и почему 10, а не 5 и не 20%. Где-то должно быть обоснование, но я не встречал.
Я защищаю идею, как и в статье, что от простых нагрузок пользы больше по результату. Но это просто имхо, жизнь заставит возиться со смешанными, буду..
1. Насколько новая железка быстрее того, что у него уже есть.
2. Насколько она быстрее того, что предлагает второй вендор в этом же ценовом диапазоне.
Клиент обращается к вендору с вопросом, насколько быстра СХД, ожидая в ответ получить какие-то цифры или индексы, а по факту вендор предлагает клиенту самостоятельно выполнить всё тестирование.
А почему вендор не может самостоятельно провести всё тестирование и потом просто опубликовать результаты этих тестов в открытый доступ? Зачем клиенту тратить своё время на тестирование, изучение кучи методик тестирования, чтобы вендор потом говорил: ой, да вы не правильно всё протестировали, надо было не синтетику запускать, а тестовые сценарии. Ой, да и тестовые сценарии тоже не подходят, надо на продуктиве всё смотреть и так до бесконечности.
Отсутствие цен в открытом доступе — это вторая проблема. Все цены только по запросу. Причём если делать запросы от разных компаний, то и цены будут разными.
А почему вендор не может самостоятельно провести всё тестирование и потом просто опубликовать результаты этих тестов в открытый доступ?
а вы замените в вашем тексте "всЁ тестированиЕ" на "всЕ тестированиЯ" и сразу станет понятно. под разные виды нагрузок существуют разные тесты, всё это помножается на кол-во файловых систем, на кол-во вариантов наполнения дисковой полки, на кол-во самих полок и контроллеров и так далее почти до бесконечности. даже заранее зная что хочешь протестировать и под какую задачу тратишь на это очень много времени, а чтобы протестировать все возможные вариации уйдут годы. но согласен что вендору бы выкладывать результаты тестирований которые делались для клиентов, так за пару лет можно набрать очень хороший набор результатов под разные кейсы.
Отсутствие цен в открытом доступе — это вторая проблема. Все цены только по запросу. Причём если делать запросы от разных компаний, то и цены будут разными.
а вот тут полностью согласен, мне кажется за плашку "цена по запросу" надо лишать возможности вести бизнес раз и навсегда
не забывайте про наличие "шаблонных" нагрузок, которые встречаются у пользователей в 70-80%% случаев. Например — MSSQL. Или — серверная 1С, файловая 1С. И от пользователя к пользователю — характер нагрузки врядли изменяется. Чаще всего такие тесты и интересны.
И от пользователя к пользователю — характер нагрузки врядли изменяется.
изменяется, и довольно сильно. мы можем взять типовые тесты для pgsql сервера, подобрать при и помощи железо которое покажет лучшие результаты, а потом в бою узнать что характер нагрузки постгри при работе с неким конкретным ПО всё же сильно отличается и не туда смотрели.. проходили знаем..
У большинства вендоров есть калькуляторы - вы забиваете (или отправляете) требуемые характеристики СХД (емкость, производительность, интерфейсы и т.д.), а в ответ получаете какую модель и в какой конфигурации надо купить для этого.
К тому же многие публикуют результаты тестов (сами или кто-то другой тестирует и публикует). Но вопрос в том - какое отношение имеют тесты, проведенные кем-то другим, по их методике, под их нагрузкой и в их конфигурации для конкретно вашего случая и ваших задач? В общем случае, никакого. Поэтому и берут (точнее должны брать) системы на тесты, чтобы проверить не коня в вакууме, а провести релевантный для конкретно вашего случая тест.
А чтобы не было "ой, да вы неправильно всё протестировали" согласуйте методику тестирования ДО её проведения и всё.
Потому что все потом грустят: как же так, оно неправильно работает и цифры не те
Тестировать есть смысл, если:
- вы просто из любопытства изучаете СХД, с которой вы работаете.
В тестирование лучше не лезть, если:
- вы не знаете, что конкретно вы хотите;
простите, но это разве не одна и та же причина у вас одновременно и в "за" и в "против"?
А как вы относитесь к SPDK Performance Reports. Мы как то больше на него ориентированы в тестах СХД. Рекомендации вендора - реально мало интересны. Т.к. по сравнению с этим документом - у них маркетинговый/детский лепет - особенно привычка перформанс одного диска умножать на всю полку дисков или даже кластер и отключать все виды синхронизации.
Вы в курсе что есть SNIA (Storage Networking Industry Association) по VPN сейчас доступен - у него сто лет как есть Solid State Storage (SSS) Performance Test Specification (PTS). Чтобы хотелось от СХД поставщиков - это тест (SPDK или PTS) на голой операционке и точно такой же тест с установленной СХД - например на RAID6 с дедупликацией и сжатием. Иначе читаешь - сообщение о данных теста как записки сумасшедшего. У вас в компании - наверняка есть такие тесты - вот они реально интересны. Если руководство вам разрешит - лучше о них напишите.
PTS тоже не идеальна. Например, в части последовательно доступа , тест только с TC1/QD32 - какой вывод из этого можно сделать? Кмк, это взяли с HDD, и перенесли на SSD. Часть тестов XSR, CBW ,.. - выглядят несколько хммм.. академично.
SPDK пишут отличные full disclosure report, но у них просто коробка с дисками, подключённая по NVMe, это всё таки не СХД и проверяют они софтовый стек.
Тестирование блочных стораджей: нюансы и особенности практики