Posts tagged ‘spec’

Почем обходится производительность?

Сегодня еще один пост Recoverymonkey, на тему довольно странной методики, используемой EMC для публикации своих результатов в тесте SPEC SFS NFS, для своих новых систем VNX.

Во что же обходится производительность, измеренная в “долларах на IOPS”?

Вновь обращаю ваше внимание, что в полемику с автором, если такая кому-то покажется необходимой, можно вступить в комментариях к оригинальной статье, а не к моему переводу.

Examining value for money regarding the SPEC benchmarks

Posted on February 28, 2011 by Dimitris

Некоторые комментарии к предыдущему моему посту, ответ на вопросы о цене $/IOPS и $/TB.

Поскольку SPEC не требует указывать цену тестируемой конфигурации, я проделал собственный анализ цен.

Данные по NetApp это просто умноженные на 4 наши опубликованные на сайте SPEC результаты для FAS6240, точно то же самое, что сделала EMC со своими результатами, они взяли 4 независимых системы, запустили на каждой из них тест, и просуммировали результат всех четырех.

Система хранения обычно имеет несколько “узких мест” – кластерный интерконнект, диски и канал к ним, полоса пропускания интерфейсов контроллера, и так далее.

Когда вы тестируете одну систему, вы, в конечном счете, упираетесь в одно из таких мест.

Когда вы тестируете несколько отдельных систем, независимых одна от другой, у каждой будут свои собственные, изолированные от других такие bottlenecks, не будет узких мест, связанных с совместной работой нескольких контроллеров,  и производительность будет масштабироваться линейно, с добавлением все новых систем.

Например, если на один грузовик можно нагрузить 10 тонн, то на 4 грузовика можно погрузить 40, а на 10 – 100 тонн груза. Предела нет.

Но когда есть общий ограничивающий фактор (например, все участвующие грузовики должны одновременно проехать по мосту), тогда вас ограничивает то, сколько грузовиков вы можете нагрузить, и поставить на мост.

EMC протестировала общую грузоподъемность четырех “грузовиков”. Я поступил также, и взял результаты четырех нетапповских “грузовиков”, и вот что получилось:

  EMC NetApp Разница
Цена (USD list) 6 000 000 5 000 000 NetApp дешевле на 16% по абсолютной величине
SPEC SFS NFS IOPS 497623 762700 NetApp быстрее на 53% по абсолютной величине
Average Latency 0,96 1,17 У EMC всего на 18% меньше latency (при меньших IOPS) несмотря на SSD!
Емкость (TB) 60 343 У NetApp 5,7 раза больше емкость usable space
$/IOPS 12,06 6,53 У NetApp на 45,6% дешевле IOPS
$/TB 100000 14577 У NetApp терабайт стоит всего 1/6 от стоимости EMC
RAID RAID-5 RAID-DP Пространство хранения на NetApp в тысячи раз надежнее
Количество корпусов 15 8 NetApp значительно проще в конфигурировании и работе

 

Ну, кто покажет наилучший вариант? ;)

Как вы знаете, пользователю системы хранения с определенным уровнем производительности,  нужна скорость, объем хранения и высокая надежность. Не просто один параметр из трех, а все три вместе. Хороший документ по поводу относительной надежности разных типов RAID можно почитать тут.

NetApp предлагает все три параметра, разом, плюс хорошую цену, простоту и гибкость unified storage, и высокую эффективность использования.

Большинству пользователей нужно видеть производительность реальных конфигураций. Я довольно часто показываю клиентам наши результаты в SPEC SFS или SPC-1, так как протестированные там конфигурации обычно довольно близки к тому, что они спрашивают.

Возможно было бы хорошо для EMC показать результат, который на самом деле продается клиентам, например:

  • Систему с SSD, FASTcache, SAS и High Capacity SAS дисками вместе
  • Autotiering (FAST)
  • RAID6
  • Типичным объемом usable для данной конфигурации

И уже этот результат публиковать.

Пусть остается нынешний результат, но покажите также то, какова реальная   производительность систем, не лабораторных “звездолетов”, а тех, которые вы продаете реальным клиентам.

Я правда не понимаю, почему это для вас так сложно.

EMC убедительно демонстрирует проблемы VNX

В моем блоге очередной перевод поста в блоге Recoverymonkey (Dimitris Kr.)

Я бы хотел обратить внимание читателей, что то, что публикуется по средам, это переводы. Я стараюсь сохранять манеру и стиль оригинального автора, потому что это – перевод. Лично я могу быть несогласен (или согласен, как получится) с излагаемой позицией, но, так как это не мои собственные тексты, за исключением небольших сокращений, я стараюсь их не править, и переводить в том виде, в котором они были опубликованы их авторами. Если у вас есть возражения по существу написанного, то не нужно писать их в комментариях к этому посту, и вообще к “средовым” переводным постам мне, сюда. Если вы хотите подискутировать с автором – напишите непосредственно ему, я всегда оставляю ссылки на оригинальные публикации. Спасибо за понимание. А теперь – как всегда острая и полемическая статья Recoverymonkey, с очередной шпилькой в адрес EMC VNX.

EMC conclusively proves that VNX bottlenecks NAS performance

Posted on February 24, 2011 by Dimitris

Немного провокативный заголовок, не правда ли?

Позвольте мне объяснить.

EMC опубликовала новые результаты SPEC SFS в рамках своей маркетинговой кампании (которая работает, смотрите чем я занят – я говорю о них).

Если по-простому, то EMC получила почти 500 тысяч SPEC SFS NFS IOPS (уточню последнее, чтобы не спутать с “блочными” IOPS в SPC-1) на следующей конфигурации:

  • Четыре (4) полностью независимых массивах VNX, каждый на дисках SSD (всего 8 контроллеров, так как каждый массив имеет 2 контроллера).
  • Пять (5) Celerra VG8 NAS heads/gateways (1 как spare), по одному поверх каждого VNX
  • Две (2) Control Station
  • Восемь (8) экспортов  файловых систем (по две на каждую голову VG8/VNX)
  • Несколько пулов хранения (по крайней мере один на каждую VG8) – без совместного доступа, например с других контроллеров, без переноса данных с других контроллеров.
  • Всего 60TB пространства NAS под RAID5 (или по 15TB с каждого массива)

Этот пост не о том, что приведенная конфигурация нереальная и дорогая (никто не заплатит 6 миллионов долларов за 60TB в NAS). Как я понял, EMC старается опубликовать наилучший результат теста путем объединения в кучу нескольких отдельных массивов с SSD. Это в принципе нормально, если понимать детали.

Претензии мои тут в том, как это подается.

EMC говорит о тестируемой конфигурации очень расплывчато (за деталями приходится идти непосредственно на сайт SPEC). В рекламных материалах просто говорится, что EMC VNX показала результат 497623 SPECsfs2008_nfs.v3 операций в секунду. Это что-то типа того, как если бы вы сказали, что нормально пройти четверым первоклассникам на сеанс в кино “до 18”, потому что, дескать, “всем четырем вместе больше 18”.

Нет, более правильно и корректно было бы сказать, что четыре массива VNX, работающих отдельно и независимо друг от друга, показали результат 124405 SPECsfs2008_nfs.v3 IOPS  - каждый.

EMC просто сложила результаты четырех отдельных, независимых устройств вместе!

У NetApp уже есть результат SPEC SFS для FAS6240, где всего два контроллера выдают 190675 SPEC NFS IOPS, в одной системе, настоящем unified, без нагромождения отдельных контроллеров, без использования SSD (на обычных SAS, плюс большой кэш), то есть на реальной, практической конфигурации, которую мы продаем ежедневно, а не на каком-то там лабораторном “звездолете”.

Если сделать также, как поступил EMC, то есть сложить четыре таких системы вместе (в случае NetApp, у нас при этом можно использовать Cluster-mode, с общим файловером между этими четырьмя нодами ), то мы получим следующие результаты:

  • 762700 SPEC SFS NFS операций
  • 8 экспортируемых файловых систем
  • 334TB usable пространства в RAID-DP (в тысячи раз надежнее RAID-5)

Какой вариант, по вашему, более выгодная покупка? Та что более быстрая, 343TB с большей надежностью, или та, что медленнее, 60TB и меньше надежности? ;)

Пользователи других систем также могут легко проделывать такой же трюк с умножением их результатов измерений, вперед!

Если же говорить серьезно, то, что побудило меня так озаглавить пост, это факт того, что тестирование EMC убедительно продемонстрировало, что VNX сам по себе является узким местом. Фактически мы видим, что VNX может обслуживать только одну “голову” VG8 на максимальной для себя скорости, зачем и понадобилось четыре отдельных системы для демонстрации нужного результата. Таким образом, факт того, что VNX может иметь над собой до 8 “голов” Celerra ничего не значит, так как в такой системе back-end это и есть ограничивающий производительность фактор.

Но с одной “головой” NAS вы будете ограничены доступным объемом в 256TB, столько одна голова Celerra может адресовать на момент написания статьи. Впрочем, этого достаточно для обычного пользователя.

Любопытно, а те “головы” NAS, которые продаются вместе с VNX, медленнее, чем VG8, и насколько? Понятно, что большинство пользователей будут использовать те “головы”, что идут в комплекте, так как это обходится дешевле. Как быстро работают они? Уверен, клиенты хотели бы знать как быстро работает именно то, что они, обычно, покупают.

Также очень интересно, как быстро работает RAID6.

А вообще было бы здорово измерять бенчмарки именно того, что пользователь на самом деле покупает, а не абстрактных “болидов Formula 1”!

20/0.141

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.