NetApp опубликовал результаты SPC-1 в 8.1.1 C-mode
На днях, NetApp официально опубликовал результаты бенчмарка SPC-1, главного бенчмарка по демонстрации производительности на блочном (SAN) доступе.
Как вы знаете, в Data ONTAP 8.1.x Cluster-mode появилась новая возможность – кроме доступа к системе хранения как к NAS, по протоколу NFS или CIFS/SMB, теперь возможна и работа с блочным стораджем, то есть как SAN-утройства. В версии 8.1 кластер SAN был ограничен 4 узлами (2 HA-парами), но, как я и предполагал, этот размер будет постепенно увеличиваться, и вот уже в 8.1.1 он был увеличен до 6 узлов (нод) в кластере. Напомню, что для NAS (NFS) максмальный размер кластера составляет 24 узла.
Однако для любой новинки всегда остается вопрос, как и насколько хорошо это на самом деле работает? ??менно на этот вопрос отвечают бенчмарки, то есть эталонные процедуры тестирования, на которых можно протестировать свою конфигурацию, получить определенный результат, который уже можно сравнить с результатами бенчмарков других систем. Специально останавливаюсь на том, что именно стандартизованная среда тестирования, и только она, позволяет в дальнейшем сравнивать результаты между собой. Нельзя сравнивать результаты какого-то одного теста, выраженного в IOPS, с результатами в IOPS какого-то другого.
?? если для NAS NetApp достаточно давно показывал свои результаты в бенчмарке SPEC sfs2008, в том числе и для Cluster-mode, то для блочных протоколов, таких как FC или iSCSI, или FCoE, таких данных не было. А отсутствие результатов бенчмарков всегда тревожит, как же оно там, на самом деле, не на бумаге маркетинговых буклетов?
Наконец, на прошлой неделе, NetApp показал свои (почти)топовые результаты, для 6-узлового кластера, с использованием контроллеров FAS6240, под управлением Data ONTAP 8.1.1.
??нтересно, что бенчмарк SPC-1 требует публиковать цену тестируемой конфигурации (в терминах SPC-1 – TSC, Tested Storage Configuration), и, следовательно, вычислять параметр $/IOPS, “цену транзакции”. Но тут следует обратить внимание, что не запрещается искусственно занижать “листовую” цену продукта (например указав в цене уже некий “дисконт” относительно листпрайса), получая более “выгодно выглядящие” $/IOPS. Показатель $/IOPS приводится вместе с показателем IOPS, достигнутым на тестировании, даже в короткой версии результата, так называемом executive summary, в то время, как за полной конфигурацией тестируемой системы и за опубликованными на нее ценами, надо идти в full disclosure report.
NetApp на тестировании SPC-1 всегда приводит в качестве цены на систему полный, официальный листпрайс на момент тестирования, без дисконтов, и, что интересно, со включенным SupportEdge 24×7х4h на 3 года. Специально хочу напомнить, что листпрайс в реальной жизни не является реальной ценой продажи, так как в подавляющем числе случаев при продаже для конечного пользователя из цены вычитаются разнообразные, порой значительные, в десятки процентов, дисконты (скидки).
Поэтому если вы хотите просто тупо сравнить циферку $/IOPS системы одного вендора, с опубликованным $/IOPS у NetApp, обязательно посмотрите, исходя из какой цены было это значение вычислено, и, соответствующим образом, скорректируйте результаты.
18 июня 2012 года NetApp опубликовал официальный отчет о тестировании 6-узлового кластера в SAN, на протоколе доступа FC 8Gb/s и тестируемом объеме ~72TB (~193TB raw, 36% от raw), 432 диска SAS 450GB в 18 полках, показав результат 250 039,67 IOPS, и, при листпрайсе $1 672 602, показатель $/IOPS составил 6,69$/IOPS SPC-1.
За подробностями – в executive summary и в full disclosure report.
а состав ПО тестируемой конфигурации netapp известен? Возможно ли, что там только один рабочий протокол открыт , без всяких плюшек?
panvartan:
> а состав ПО тестируемой конфигурации netapp известен?
Конечно. А то зачем я вам давал бы ссылки на описания?
> Возможно ли, что там только один рабочий протокол открыт , без всяких плюшек?
1. SPC-1 это бенчмарк чисто блочного протокола (читай, FC).
2. В NetApp включение плюшек (таких, как, например снэпшоты, FlexVol, thin provisioning) практически не влияент на производительность.
Добрый день, уважаемые.
А есть какой-нибудь свежий документ, показывающий стабильную производительность системы, при всех включенных плюшках и достаточной заполненности системы (около 80%). По этому поводу много было Fuda, а заказчики не всегда верят на слово.
Спасибо.
> В NetApp включение плюшек (таких, как, например снэпшоты, FlexVol, thin provisioning) практически не влияент на производительность
на IOPS не влияет, зато сильно влияет на $/IOPS
в Priced Storage Configuration Pricing отдельной строкой ПО нет, скорее всего FAS6240 с открытым на выбор FC протоколом, все остальное надо докупать отдельно. Если нескромно заложиться на SW-6240A-COMP-BNDL, то 6*~300k$ дает удвоение $/IOPS.
s1d:
Почти все, что вы хотите, есть в официальных документах, их просто надо внимательно читать (и верить им больше, чем слухам злонамеренных анонимных “доброжелателей).
> показывающий стабильную производительность системы
48-hr sustainability test:
http://www.storageperformance.org/results/a00062_NetApp_FAS3040-48hr-sustain_full-disclosure.pdf
Также обратите внимание, что тест, о котором шла речь в посте выше (6240, cluster-mode), проводился течение 9 часов (при формальном требовании спецификации теста SPC-1 - 3 часа), и продемонстрировал неизменяющуюся и стабильную величину показателей, после первых нескольких минут ramp-up (прогрева), см. стр 25 в full disclosure report.
> при всех включенных плюшках
См, например, тест, демонстрирующий влияние snapshots на производительность на WAFL:
http://www.storageperformance.org/results/a00058_NetApp_FAS3040-Snapshot_full-disclosure-r1.pdf
та же конфигурация, но с отключенными снэпшотами:
http://www.storageperformance.org/results/a00057_NetApp_FAS3040_full-disclosure-r1.pdf
Также обратите внимание, что системы NetApp тестируются с работающим thin provisioning: (стр 60, http://www.storageperformance.org/benchmark_results_files/SPC-1/NetApp/A00115_NetApp_FAS6240-cluster/a00115_NetApp_FAS6240-cluster_SPC-1_full-disclosure.pdf)
Также отключается параметр walf.optimize_write_once (в ряде случаев могущий улучшить производительность за счет уменьшения write fragmentation), остальные параметры томов остаются по умолчанию “из коробки”, в том виде, в каком они приходят к клиенту и рекомендуются в Best Practices (например, отключать snapshot schedules для SAN-томов).
> достаточной заполненности системы
FAS3170A SPC-1/E test - Protected Application Utilization: 70.07%
http://www.storageperformance.org/results/a00066_NetApp_FAS3170_full-disclosure.pdf
Также полезно внимательно прочитать пост-перевод в этом блоге:
Как заполненность данными системы хранения влияет на ее производительность?
http://blog.aboutnetapp.ru/archives/1083
Мне кажется, я ответил на все ваши вопросы?
> По этому поводу много было Fuda, а заказчики не всегда верят на слово.
Заказчики верят на слово неизвестным анонимам, распространяющим слухи и FUD путем надписей на заборе “Лешка - пи*арас!”, но не верят вам? Думаю, что тут проблема, в первую очередь, не в FUD, и не в NetApp, а в вашей низкой убедительности и авторитетности для заказчика, не так ли? ;)
panvartan:
> на IOPS не влияет, зато сильно влияет на $/IOPS
> то 6*~300k$ дает удвоение $/IOPS.
Вот вы и ответили сами себе, почему в _тестировании_ в конфигурацию не включается ничего лишнего по цене, кроме того, что используется в этом тестировании, и почему некоторые вендоры указывают даже эти цены уже с искусственным дисконтом. :)
Мне кажется, я ответил на все ваши вопросы?
100%
Заказчики верят на слово неизвестным анонимам, распространяющим слухи и FUD путем надписей на заборе “Лешка - пи*арас!”, но не верят вам?
Неизвестные анонимы - это порой серьезные и такие же авторитетные товарищи из “Storage Vendor’а #1″, вот тут и начинаются конфронтации.
Думаю, что тут проблема, в первую очередь, не в FUD, и не в NetApp, а в вашей низкой убедительности и авторитетности для заказчика, не так ли? ;)
Не так ;)
s1d:
> Неизвестные анонимы - это порой серьезные и такие же авторитетные товарищи из “Storage Vendor’а #1″, вот тут и начинаются конфронтации.
Ну давайте тогда спорить предметно, с доказательствами в руках. У распространяющих FUD есть доказательства их слов, опубликованные, и пригодные к проверке сторонними, независимыми, а также собственно специалистами NetaApp?
Вот когда NetApp утверждает, что использование снэпшотов на системах “классической” архитектуры приводит к почти трехкратному падению их производтельности, они берут соответствующую систему, и демонстрируют это, публикуя проверяемые и хорошо документированные результаты (см. тот же SPC-1).
В самом лучшем случае (если не брать “заборные варианты”, типа “а вы, что, не знаете, что у NetApp производительность при заполнении падает? Да это же все знают, хаха!”) это публикации вида:
http://h30507.www3.hp.com/t5/Around-the-Storage-Block-Blog/Understanding-FAS-ESRP-Results/ba-p/78914
“Мы тут собрали и померили, так вот, оно там все ужас-ужас!”
В ответ на предложение специалиста из NetApp: “Это странно, мы такого не наблюдали, можно посмотреть конфигурацию, которую вы тестировали, может быть вы какие-то ошибки по неопытности допустили? Давайте мы вам поможем их исправить, если они есть.”
вторая сторона уходит в глухую несознанку: “Ничо не знаем, мы сконфигурировали все правильно, раз производительность падает, значит все правильно сделано. Ничо не покажем, уйдите ваще, противные”.
В комментах там очень показательная дискуссия между Джоном Мартином, NetApp ANZ, и Кальвином, из HP, автором поста.
Добрый день.
Я понимаю что чтобы работать в 8 моде нужно создать отдельный aggr для root volume.
Это значит что для каждого контроллера 3 диска пойдут на эту цель.