Это перевод поста от 27.01.2015 из блога Dimitris Krekoukias — NETAPP POSTS TOP TEN SPC-1 PRICE-PERFORMANCE RESULTS FOR THE NEW EF560 ALL-FLASH ARRAY
Я счастлив сообщить, что сегодня мы анонсировали новый all-flash массив EF560, а также опубликовали результаты теста SPC-1. И мы показали впечатляющие результаты в этом крайне сложном тесте.
Если кратко — EF560 показал в тесте SPC-1 лучшее соотношение цена/производительность при очень низких задержках.
Линейка EF уже некоторое время пользуется большим успехом. Огромное количество систем проинсталлировано в крупнейших компаниях мира для хранения данных высокоприоритетных приложений (часть из которых мы с вами используем каждый день).
EF560 — это самый свежий AFA массив из E-серии, оптимизированный для получения очень низких задержек и высокой производительности, при этом обеспечивая высокую надежность, экономичность и простоту.
Особенности EF560
EF560 работает под управлением SANtricity — сильно оптимизированной ОС для СХД с низкими накладными расходами на обслуживание данных (short path length). То есть процесс обработки данных самой ОС оказывает очень небольшое влияние на скорость чтения и записи этих данных. В случае с EF-серией задержки со стороны ОС составляют около 30 микросекунд. Большинство других систем хранения имеют более длинный путь прохождения данных из-за бо̀льшего количества дополнительных функций и/или неэффективного кода.
Необходимость сохранять такой впечатляюще короткий путь данных одна из причин почему в системах EF так и не реализованы модные в AFA массивах дедупликация и компрессия. Однозначно можно сказать, что никакая система с такого рода функционалом не сможет обеспечить короткий путь данных. Слишком много всего придется выполнять с данными. Если для вас критично наличие богатого функционала и в том числе технологий повышения эффективности хранения данных, то мы предлагаем системы FAS. Но путь данных там не такой короткий как в EF560.
В результате короткий путь данных позволяет получить впечатляюще низкие задержки при высоких показателях IOPS на конфигурациях применимых в реальной жизни, что дальше и будет видно.
Некоторые другие особенности EF560:
- Нет специфического «обрыва» при записи на SSD, который появляется со временем или при заполнении SSD
- Нет влияния на производительность из-за «сборщика мусора» SSD дисков
- Компоненты промышленного уровня, в том числе и SSD диски
- Доступность в 6 девяток
- До 120 1.6TB SSD дисков на систему (135TB полезного пространства при использовании DDP, и еще больше с RAID5/6)
- Большая пропускная способность (throughput) — 12ГБ/сек на чтение, 8ГБ/сек на запись (некоторые забывают, что для нагрузок со стороны БД важны не только низкие задержки и высокие IOPS, но и высокая пропускная способность для части операций)
- В состав систем входят все доступные лицензии на функционал, кроме шифрования
- Массивы могут делать снэпшоты, поддерживают асинхронную и синхронную репликацию
- Поддержка Consistency Group
- Несколько плагинов для прикладного ПО
- Нет поддержки NAS протоколов, зато изобилие поддерживаемых блочных протоколов: FC, iSCSI, SAS, InfiniBand
- Стандартный набор уровней RAID — 5, 10, 6 и кроме того...
- DDP — Dynamic Disk Pools. Собственная реализация RAID6 на субдисковом уровне. DDP очень удобен для больших пулов дисков. Позволяет производить быстрый ребилд с минимальным влиянием на производительность. И все это довольно гибко используется (например, можно добавлять диски в пул поштучно без необходимости добавлять сразу целую RAID-группу)
- Поддержка стандарта T10-PI. Для обеспечения защиты от потери данных из-за т. н. «тихих ошибок записи», от которых не спасает наличие RAID. Стандарт подразумевает сквозной контроль данных от приложения до устройства хранения
- Может использовать с Clustered Data ONTAP, как виртуализированная при помощи FlexArray система
Суть всех All-Flash массивов
Возвращаясь к короткому пути обслуживания данных и низким задержкам...
Флэш оказался взрывной технологией, потому что, если его правильно применять, то он обеспечивает беспрецедентную производительность за все более разумные деньги.
Пользователи AFA обычно делятся на две категории:
- Пользователи, которые хотят кучу функционала, технологии по увеличению эффективности хранения, хорошую, но не гарантировано стабильную производительность, в меру низкие задержки — 1-2 мс (с редкими всплесками) их вполне устраивают, так как это лучше, чем у гибридных систем, и намного лучше, чем производительность классических дисковых систем
- Пользователи, которым нужна минимально возможная низкая задержка (счет идет на микросекунды и 1 мс рассматривается как худший случай) и бескомпромиссная надежность в обслуживании их данных. Они готовы пожертвовать частью функционала ради такой производительности. Таким пользователям нужна стабильно предсказуемая производительность без всякого намека на скачки задержки.
Ребята из лагеря с низкими задержками обычно используют такие приложения, которым важна низкая задержка для увеличения доходов компании. Важна каждая миллисекунда, а то и микросекунда, и при этом остановка сервиса грозит огромными финансовыми потерями.
Некоторые из читателей могут подумать «ну и что, между 1 мс и 2 мс практически нет разницы, и задержки такого уровня — это здорово». Хорошо, но для этих клиентов 2 мс это в два раза больше, чем 1 мс, и для них это на самом деле имеет значение. Для тех кому нужна низкая задержка, массив с задержкой в 1 мс в половину медленнее массива с задержкой в 500 микросекунд, даже если оба массива имеют одинаковые показатели IOPS.
Вы можете думать «SSD, которые вставляются в PCI слоты сервера тоже имеют низкую задержку, так ведь?»
Ответ — да, но вы упускаете из виду надежность, которую обеспечивает полноценная система хранения данных . Если вышел из строя сервер, доступ потерян. Если померла карта, то потеряно все.
Теперь когда вы будете думать о покупке AFA массива, решите пользователь какого типа вы. Что действительно необходимо вашему бизнесу. Это поможет принять верное решение.
Фоновые операции в All-Flash массивах могут влиять на задержки
Более продвинутые All-Flash массивы реализуют больше функционала по сравнению с системами со сверхнизкими задержками. Но при этом подвержены тому, что задержки могут быть неравномерными или даже могут появляться серьезные скачки под нагрузкой и при малом количестве свободного места на массиве. И это не учитывая то, что на таких системах и так будут более высокие задержки из-за более длинного пути данных.
Например, процессы по освобождению пространства на SSD дисках откуда данные были стерты, различные фоновые процессы, которые запускаются в разное время, различные способы обработки операций ввода/вывода в зависимости от заполненности массива — все это может вызывать всплески задержек или в целом неравномерные показатели задержек. Это нормально для массивов такой архитектуры, но это может быть неприемлемо для определенных приложений.
К слову, EF560 не страдает от таких проблем. Мы обходили решения конкурентов в сложных тестах по производительности (Видимо имеются в виду proof of concept тесты у конкретных заказчиков — прим. переводчика) с более медленной прошлой системой EF550. А теперь продолжим обходить с новым массивом :)
Хватит! Покажите же мне цифры!
Для того чтобы обновить свои знания о результатах теста SPC-1 вы возможно захотите прочитать мои старые посты раз и два, а так же мое руководство по производительности для начинающих.
Важное замечание: SPC-1 это тест блочного доступа со своим определенным профилем нагрузки и поэтому его результаты не должны сравниваться с маркетинговыми заявлениями вендоров о показателях IOPS, полученными при 100% нагрузке на чтение, или с тестами вроде SPEC SFS, которые нацелены на проверку работы с NAS протоколами и большим количеством метаданных (в них более «легкий» профиль нагрузки, чем в SPC-1, где присутствует 60% операций записи и умышленное создание hotspots). Вполне вероятно, что тестируемые конфигурации могут выдать намного больше «маркетинговых» IOPS, но SPC-1 создан не для этого.
Если вам интересны детальные результаты, то вот вам ссылки на краткий отчет и полный отчет. Вдобавок ссылка на «Топ-10 результатов по соотношению цена/производительность», чтобы вы могли сравнить результаты других вендоров (к сожалению, обычно результаты SPC-1 отсортированы в алфавитном порядке, и приходится потратить достаточно много времени, чтобы сравнить результаты разных производителей).
На что обращать внимание при просмотре результатов SPC-1
Для того, чтобы проанализировать тот или иной результат надо обращать внимание на следующие нюансы:
- Latency vs IOPS. Очень много результатов отображают большое количество IOPS при огромных задержках. Такие результаты бессмысленны для тех кому нужны системы с низкими задержками.
- Устойчивость показанного результата — была ли производительность постоянной или присутствуют заметные всплески и падения?
- Уровень RAID — большинство результатов показано с использованием RAD10, а каков будет результат при использовании RAID6?
- Application Utilization. Это важная характеристика, которую порой опускают. Она выражает сколько полезной емкости было использовано во время теста по сравнению с общей сырой емкостью без учета уровня RAID, spare-дисков и т. д.
- Цена — учитывались скидки или нет?
Давайте пройдемся по этим пунктам.
Latency vs IOPS
Средняя задержка у нас 0.93 мс при 245 011.76 SPC-1 IOPS. График изменения задержки во время тестирования практически абсолютно плоский:
Устойчивость
По правилам SPC-1 проводится не менее 8 часов подряд. На протяжении всего теста не было заметных всплесков и падений производительности:
Уровень RAID
Использовался RAID10 с включенной опцией T10-PI, которая отвечает за целостность данных и отрицательно влияет на производительность. Но приложения, которые обычно работают на таких системах требуют параноидального контроля целостности данных. При использовании RAID5 или RAID6 производительность будет хуже. Но для систем где в первую очередь важна низкая задержка, RAID10 наилучший вариант, особенно когда это система, в которой операции записи не оптимизированы под RAID6 как это сделано в Data ONTAP. Не волнуйтесь, соотношение цена/производительность все равно оказалось одним из лучших.
Утилизация пространства
В нашем случае показатель утилизации пространства (Application Utilization) оказался очень высок и составил 46.90% — этот показатель один из наилучших среди других результатов с использованием RAID10 (и среди всех остальных результатов тоже, за исключением тестов систем на Data ONTAP, где этот показатель может быть еще выше благодаря RAID-DP).
Мы практически полностью использовали все доступное после использования RAID10 полезное пространство, чтобы показать, что на производительность не влияет заполненность системы данными. Впрочем, именно показатель Application Utilization является единственной метрикой, которая показывает сколько пространства из общего сырого объема использовалось во время теста и насколько массив эффективен в плане утилизации пространства.
Иначе, кто-нибудь мог бы дважды использовать зеркалирование для 100ТБ сырой емкости, получить 25ТБ полезной емкости, заполнить их на 100% и утверждать, что их система имеет 100% эффективность утилизации дискового пространства, хотя в реальности она имела бы всего лишь 25% эффективность ;-)
Важно заметить, что никто из вендоров в этом тесте не использует технологии дедупликации и компрессии, так как в текущей версии теста это не разрешено.
Сравнение с другими вендорами
Я хочу показать сравнение 10 лучших результатов SPC-1 по соотношению цена/производительность. И я хотел бы провести два сравнения. В первом случае сравнивая абсолютные значения достигнутые в тесте, а во втором случае нормализовав эти результаты по значению задержки около 500 микросекунд. И таким образом продемонстрировать, что высокую производительность при очень низких задержках возможно получить за адекватные деньги, если вы будете использовать наше решение.
Вот вам 10 лучших результатов SPC-1 по соотношению $/IOPS на 27 января 2015 года:
- Kaminario K2-D
- NetApp EF560
- Huawei OceanStor Dorado 2100 G2
- HP 3PAR STORESERV 7400
- DELL STORAGE SC4020
- FUJITSU ETERNUS DX200 S3
- Kaminario K2 (28 nodes)
- Huawei OCEANSTOR Dorado 5100
- Huawei OCEANSTOR Dorado 2100
- FUJITSU ETERNUS DX100 S3
Я сведу в таблицу показатели всех упомянутых систем и покажу их результаты при задержке в районе 500 микросекунд. Таким образом можно будет понять как изменение требуемых показателей задержек влияет на количество достигнутых IOPS и соотношение $/IOPS.
Каким образом можно узнать результаты при нужной нам задержке? В SPC для обозначения задержек используют термин «Average Response Time». Посмотрите на график, отображающий зависимость задержек от IOPS и найдите точку наиболее близкую к значению задержки в 500 микросекунд. Для примера возьмем график системы Kaminario K2:
Обратите внимание, что показатели IOPS при задержке около половины миллисекунды почти в 10 раз меньше, чем при задержке около 3 мс. Дальше по графику производительность растет довольно быстро, но если у вас есть требование иметь задержку не превышающую 500 микросекунд, то лучше вам потратить деньги на другой массив (Это вполне реальные требования. Весьма серьезный заказчик выставил нам требование в получение задержки ниже 400 микросекунд на уровне хоста для Oracle DB на прошлом поколении массивов EF).
Вот таблица, в которой собраны обсуждаемые показатели. Значение, указанное в колонке «adjusted latency $/SPC-1 IOPS» не присутствует в отчете SPC-1. Я вычислил его просто разделив цену системы на количество IOPS, которые система показывает при задержке в 500 микросекунд.
О чем говорят эти результаты?
Если судить по представленным результатам теста SPC-1, то система EF560 вторая по наименьшему соотношению цена/производительность, позади единственного массива, использующего технологию DRAM. Но интересно, что как только мы смотрим на показатели IOPS с задержкой около 500 микросекунд, по соотношению цена/производительность EF560 выходит на первое место с большим отрывом от всех остальных систем из таблицы (ну и вдобавок системы на основе DRAM весьма ограничены в плане расширения емкости).
Обратите внимание, что некоторые производители указывают в отчетах цены со скидками, а некоторые — без. Всегда смотрите на цены (к примеру, Fujitsu указал цены со скидкой 30%, Dell — со скидкой 48%, HP — со скидкой 45%, остальные без скидок). То есть наше соотношение цена/производительность окажется еще лучше, если вы вычислите этот показатель у других вендоров без скидки.
Другое интересное наблюдение связано с влиянием длинного пути обработки данных на некоторых системах. К примеру, наименьший показатель задержки в отчете у Dell — 0.72 мс при всего лишь 10 599.32 IOPS. Абсолютно ясно, что эта система не создана для получения высокой производительности при очень низких задержках.
Наименьший показатель задержки (Least Response Time) в отчете EF560 всего лишь 0.18 мс (180 микросекунд) при 24 501.04 IOPS. Это наименьший показатель LRT, который когда-либо был показан в тестах SPC-1.
Однозначно, что-то в наших системах сделано правильно :)
Мысли напоследок
Если вам требуется хранилище с очень низкими задержками и к тому же очень надежное, то EF560 ваш выбор. Вдобавок данная система занимает очень мало места в шкафу. Озвученные результаты SPC-1 показаны на конфигурации, которая заняла в шкафу всего 2U — EF560 с 24 дисками 400GB SSD.
Вместе с системами, работающими под управлением Clustered Data ONTAP, ПО управления, анализа и автоматизации OnCommand Insight и WorkFlow Automation, NetApp имеет впечатляющее портфолио, которое позволяет решить любые задачи.
