SearchStorage Quality Award 2011
Удивительно быстро летит время. Уже почти год прошел, с момента, когда авторитетное веб-издание Storage Magazine проводило свой предыдущий опрос пользователей Enterprise Storage Systems, о котором я писал в этом блоге, и вот подготовлены результаты нового, шестого по счету.
Напомню, что Storage Magazine ежегодно опрашивает пользователей различных систем хранения, с целью получить их оценку глазами самих пользователей. Оценка проводится по нескольким критериям, таким как: Sales Force Competence (компетентность продавцов продукта), Product Features (богатство функциональности), Initial Product Quality (базовое качество поставленного продукта), Product Reliability (эксплуатационная надежность), Technical Support (качество техподдержки), и, наконец, “Would you buy this product again?” - “Купите ли вы такую систему в дальнейшем еще?”.
441 респондент оценил суммарно 727 системы (что почти вдвое выше, чем при опросе прошлого года).
Каждая категория вопросов оценивалась в диапазоне от 1 до 8, и в отчет вошли следующие системы:
- 3PAR InServ Storage Server T400/T800 or S400/S800 (32)
- EMC Symmetrix, DMX/DMX-3/DMX-4, V-Max (240)
- Hewlett-Packard XP Series or StorageWorks P9000 Series (126)
- Hitachi Data Systems USP/USP V/VSP Series (95)
- IBM DS8000 Series or XIV Storage System (106)
- NetApp FAS6000 Series or V6000 (123)
В скобках указано общее количество оцененных систем данного вендора. Отмечу также, что результаты опроса прошлого года критиковались за решение включить в него у NetApp и серию 3000, вместе с 6000, в этом опросе было решено оценивать midrange-серию 3000 отдельно. По сравнению с опросом прошлого года из результатов полностью выпала Sun/Oracle. Также не набрала достаточного количества отзывов для участия Fujitsu. 3Par в данном опросе пока еще участвует под своим именем.
Как вы понимаете, пишу я это в блоге конечно же потому, что NetApp опять продемонстрировал хороший результат. Появившись в этом опросе только в 2007 году, NetApp быстро пошел вверх, в 2009-м сравнялся с лидером, EMC, и вчистую победил в 2010. ?? вот новая оценка пользователей.
Я всегда отмечаю, что самая суть не в абсолютной величине, а в динамике, в тренде. Самая польза от таких результатов в их изменениях. Вот, например, сравнивая с результатами прошлого года, мы видим, как хорошо себя показала в глазах пользователей Hitachi, которой, судя по всему, уход Sun из ее OEM-клиентов придал силы к мобилизации, и как тяжело дался прошедший год EMC.
Завершается опрос, по традиции, вопросом к пользователям: “Купите ли вы еще такую систему?” Вновь, как и в прошлом году, пользователи демонстрируют доверие и удовлетворенность продуктами NetApp. В прошлом году результат NetApp в 91,4% был самым высоким из всех опросов Storage Magazine. Отрадно видеть, что в этом году он побил даже прошлогодний рекорд.
Полную версию отчета можно прочесть по ссылке (версия для печати на одной странице).
Уважаемый автор!
Пишу из желания обьяснить некорректность проводимого SearchStorage сравнения, а главное причины почему SearchStorage, зная об этой некорректности, все равно проводит сопоставление данных продуктов и именно в таком составе. Не из желания поспорить, а постараться разъяснить некоторые моменты, которые, похоже, вам полностью неизвестны в силу вашего малого знакомства (или незнакомства) с high-end (enterprise level) стораджами.
??так, по-порядку…
1.Отличие high-end enterprise CХД от midrange.
Disclaimer: совершенно ничего не имею против NetApp, особенно в качестве файловых хранилищ, где по производительности им просто нет равных.
Вопреки распространенному среди пользователей midrange массивов мнению, есть четкий ГЛАВНЫЙ критерий определяющий что является high-end массивом, а что нет. Критерий этот — наличие symmetrical active/active доступа к LUN независимо от порта и контроллера по которому производится обращение (в протоивоположность asymmetrical active/active (ALUA)). Критерий настолько определяющий, что обуславливает полное отличие архитектуры high-end enterprise массивов от любых midrange любых производителей.
Массивы midrange любых моделей и производителей (NetApp, EMC, HDS, HP, IBM) реализуют т.н controller based design, при котором front-end порты физически привязаны к контроллерам которые содержат одновременно и back-end порты. ALUA в таком случае является практически единственным (за редким исключением) возможным вариантом организации одновременного доступа к LUN.
В противоположность этому, в high-end массивах контроллеров как таковых нет вообще и FE порты, расположенные на FED (front-end directors) имеют доступ к КАЖДОМУ из BED (back-end directors) которые реализуют доступ к блочной части массива. Независимо от порта обращения, достигается одновременный одинаковый по времени задержки доступ к любому LUN с любого порта.
Кроме того, такая архитектура позволяет реализовать большое количество FE портов (128 и более) и высокую отказоустойчивость (при выходе из строя FED, выходит из строя, скажем, 1/10 всех FE портов, а не половина как в 2-х контроллерных midrange массивах).
Далее, high-end массивы, обязательно имеют порты FICON/ESCON для mainframe connectivity.
Уже исходя из этого видно, что на рынке имеется всего два по-настоящему high-end продукта подобного класса: HDS USP/VSP (он же продается Hewlett-Packard в виде XP series как ОЕМ от HDS с кастомным firmware от HP) и EMC DMX/V-MAX. Если вы поищете обсуждения high-end машин, то увидите сопоставление именно двух этих вариантов как единственных в своем роде. Вы не найдете действительно знающего технологические решения хранения данных специалиста, который сопоставляет на равных скажем HDS VSP и NetApp FAS/V6000.
NetApp 6000 серии — архитектурно совершенно типичный mid-range, controller based СХД c ALUA, невысокой (по high-end меркам) надежностью (вместе с контроллером “умирает” половина(!) имеющихся FE портов) и вообще БЕЗ mainframe connectivity.
Уверяю вас, даже если работают все 32-64 Fibre Channel порта, этого может быть мало для СХД которая должна “крутить” OLTP базы в 50 и более ТБ с минимальным service time на каждую транзакцию. Такие базы распределяют на большое количество портов и по ВСЕМ должно быть одинаковое время обработки, даже в случае выхода из строя на массиве одного FE либо BE контроллера. Указанные выше модели, такое, безусловно обеспечивают. NetApp — безусловно, НЕТ.
2). Почему SearchStorage их таки сопоставляет.
Disclaimer: я уважаю и читаю SearchStorage.
Ответ прост: SearchStorage при вручении таких премий нужно сопоставить чем больше вендоров, тем лучше. Если бы они выдвинули на соискание премии всего двух вендоров, эта “премия” была бы почти никому из аудитории не интересна, особенно сторонникам других вендоров. Поэтому, специально для таких случаев, был принят такой критерий как drive count. В соответствии с ним, массивы, у которых максимальное количество обслуживаемых шпинделей превышает определенную величину, большую чем у midrange, считаются “high-end” и попадают под “нужный” для премии критерий. А система FAS/V6000 от NetApp здесь как раз “подошла” и пополнила сравниваемый ряд массивов (что и требовалось), хотя фактически, по всем архитектурным критериям и просто по характеристикам является upper-end midrange.
Как написал на своем ресурсе один знающий человек, “Drive count does not make an enterprise array in any way”
Последний disclaimer: я не работаю ни на одного из перечисленных вендоров, но имею опыт эксплуатации mid-range моделей всех основных вендоров, а также перечисленных моделей high-end.
whocares:
Спасибо за столь развернутый комментарий. Тема “что считать хайэндом” возникает тут у меня ежегодно (можете проверить, каждая публикация результатов SearchStorage этим сопровождается ;)
Проблема, порождающая все эти комментарии, заключается в том, что на сегодня НЕТ точного критерия, отделяющего Hi-End от
Hi-FiMidrange. Это деление весьма условное.Возьмем, к примеру, предложенные вами критерии:
> Критерий этот — наличие symmetrical active/active доступа к LUN независимо от порта и контроллера
В таком случае “хайэндом” нужно считать HDS AMS, что, объекивно, нелепо. Это типичнейший модульный midrange, но он работает ровно так, как вы написали.
Критерий не работает.
> Далее, high-end массивы, обязательно имеют порты FICON/ESCON для mainframe connectivity.
То есть, руководствуясь этим критерием, мы должны считать, что если HDS USP продан без ESCON/FICON (например потому, что они никому особо не нужны в современном мире, как и сами мэйнфреймы), то он при этом сразу превращается в midrange. Снова очевидная нелепость и неработоспособность критерия.
Каков же критерий, отделяющий Midrange oт Highend?
Дело в том, что нет такого критерия. Вернее он один. Мнение и позиционирование продукта вендором. Если вы придете в NetApp shop, и попросите показать вам “high-end”, вам покажут FAS6200. У EMC вам покажут Symmetrix. У 3Par вам покажут F-series, и так далее.
А дальше уж дело ваше, как покупателя, что выбрать из предложенного. Но объективного деления НЕТ, оно есть только в позиционировании линеек внутри одного вендора, и вы рискуете всю жизнь потратить определяя неопределимое.
Помните исторический анекдот про “Платоновского человека” в интерпретации Диогена? Вот-вот. :о)
Вот, собственно и весь критерий, именно им и пользуется Searchstorage.
Я, видимо, не все указал; подумал, что и так будет достаточно, а места уже много занял :-) ОК, проясню,
В первую очередь, обратите внимание, я Н??ГДЕ не упомянул о маркетинговых заявлениях вендоров; мои аргументы строго технические/эксплуатационные, а ваши, к сожалению, сводятся исключительно к заявлениям вендоров (AMS 2000 заявлен как symm active/active, каждый вендор позици.онирует свое как хай-енд, и.т.п). Пожалуйста, romx, давайте оперировать исключительно обьективными, техническими критериями. ??наче будет совсем-совсем неинтересно, банальное брендозадротво, а мне оно чуждо :-(
Главный технический критерий — controller based design. Он и только он. Это главный показатель midrange архитектуры. Он принципиально не позволят создать массив высокой доступности и никто не использует его в enterprise массивах. Вылетел контроллер — нет половины FE портов. Как вы себе представляете работу с FAS/V6000 в максимальной конфигурации (48 FC портов) после выхода из строя одного контроллера? То, что производительность упадет гораздо ниже допустимого минимума, даже говорить не приходится. Еще раз припомните мой пример с >50ТБ OLTP базой подключенной по >32 портам с симметричным доступом. AMS2000 не в состоянии такого обеспечить что бы ни говорил вендор. Заметьте, если оперировать даже их собственными заявлениями, они smart enough чтобы не заявлять что это high end enterprise array, а скромно говорят что это mid-range.
В крупных телекомах такие чрезвычайно нагруженные СУБД (тот же биллинг) повсеместно, и ни один из них не “крутит” их на dual-controller массиве никакого производителя, НЕЗАВ??С??МО от позиционирования их вендорами. Надежность ниже, производительность ниже. Обьективно ниже. При любом раскладе. Это чисто техническая аргументация, понимаете? :-)
(Отвлекусь на возможное возражение, опять же, касающееся маркетинга: я прекрасно знаю про аргументацию, (распилы,откаты) при принятии решений о закупке массивов под такие задачи, но тут ни один откат не помогает — надежность и производительность превыше всего, это core business на миллионы долларов простоя в час и mission critical-системы).
Я специально довольно подробно описал архитектуру с FED и BED. Найдите в ??нтернете ее в картинках, вам скорее всего, все станет понятно и вопросы отпадут сами собой. Путем набора матрицы из FED и BED где все подключено ко всему, не только убирается единая точка отказа, приводящая к фактической к неработоспособности controller based design массива с одним оставшимся контроллером но и обеспечивается возможность установить действительно большое количество FE портов. Я думаю, если вы познакомитесь с такой архитектурой, вы первый же скажете что FAS/V6000 — типичный mid-range dual controller design. ??з особенностей ставящих его на голову выше того же AMS2000 — очень большой drive count. Однако вы увидите что по архитектурно-техническому уровню он на пять голов ниже V-MAX или USP/VSP. ?? это будет правдой — ПО ФАКТУ, NetApp никогда не конкурировала и не конкурирует на рынке таких решений, независимо от того, в какую категорию ее поставил Storage Magazine.
По поводу FICON — вы опять в маркетинг… :-) Мы же вроде договорились строго про технические вещи. Все массивы которые enterprise по факту — поддерживают FICON на уровне архитектуры. Причем тут купите вы эту поддержку или нет? Кому надо тот купит, кому не надо — не купит. Факт в том что у NetApp ее не было, нет и не будет. По поводу мейнфреймов — они применяются гораздо шире чем вам кажется. Это далеко не вымирающий вид систем. Другое дело, что это т.н flat market — он не растет и не уменьшается. Кому необходимо, тот это использует. Это также один из самых прибыльных секторов рынка. ??звините, сам отвлекся на маркетинг в последних двух предложениях :-)
Если вы готовы продолжить чисто техническую дискуссию, я только за ;-)
whocares:
> мои аргументы строго технические/эксплуатационные
> Если вы готовы продолжить чисто техническую дискуссию, я только за
Так ведь нету у нас технического спора, идет субъективный, “вкусовой” спор.
Спасибо вам за многочисленные примеры и описания, но они все равно не объясняют, почему вы проводите разделительную линию тут вот, а не вот там вот.
Почему вы взяли именно эти критерии, а не вот те.
Понимаете, это как сказать, что “Реальные бизнесмены ездят на шестисотых мерседесах”, и затем делить: “Вот это - реальный, конкретный бизнесмен, у него мерседес, а вот этот сикилявка какая-то, у него не мерс, а какой-то Ауди A8. Почему? Да по определению!”.
Ну вот я могу вам еще один, стопроцентный критерий определения storage highend сказать, у его производителя должно быть имя из трех букв. :) Между прочим, абсолютно точный критерий, не правда ли? ;)
> банальное брендозадротво, а мне оно чуждо
> Главный технический критерий — controller based design. Он и только он.
Боюсь, что вам присуще задротство совсем другого плана ;)
> поддерживают FICON на уровне архитектуры.
Вау! FICON на уровне архитектуры! ;)
> По поводу мейнфреймов — они применяются гораздо шире чем вам кажется.
Когда сидишь на приеме в больнице - кажется что вся страна болеет. :)
Рэнок мэйнфреймов это замкнутый, ничтожный по абсолютной величине и темпам роста рынок, и именно поэтому он не интересен производителям, ориентированным на массовый, растущий рынок. На сегодня, насколько я знаю, нет ни одной задачи, которая не могла бы быть решена только мэйнфреймами, сегодня их удел - legacy. Это банально неинтересно. Обязывать вендора обязательно поддерживать такие системы только для того, чтобы whocares удостоил его чести называться производителем highend storage? Хм ;)
romx, я после уже двух постов с конкретными техническими примерами ожидал что вы попробуете хоть как-то на них отреагировать. Но пока что мы спорим с вашей подачи о чисто маркетинговых аспектах. Перечитайте мои посты и ваши :-) О приведенных технических. примерах вы не сказали Н?? СЛОВА. Напомню:
Пост первый:
“NetApp 6000 серии — архитектурно совершенно типичный mid-range, controller based СХД c ALUA, невысокой (по high-end меркам) надежностью (вместе с контроллером “умирает” половина(!) имеющихся FE портов).
Уверяю вас, даже если работают все 32-64 Fibre Channel порта, этого может быть мало для СХД которая должна “крутить” OLTP базы в 50 и более ТБ с минимальным service time на каждую транзакцию. Такие базы распределяют на большое количество портов и по ВСЕМ должно быть одинаковое время обработки, даже в случае выхода из строя на массиве одного FE либо BE контроллера. Указанные выше модели, такое, безусловно обеспечивают. NetApp — безусловно, НЕТ.”
Пост второй:
Вылетел контроллер — нет половины FE портов. Как вы себе представляете работу с FAS/V6000 в максимальной конфигурации (48 FC портов) после выхода из строя одного контроллера? То, что производительность упадет гораздо ниже допустимого минимума, даже говорить не приходится. Еще раз припомните мой пример с >50ТБ OLTP базой подключенной по >32 портам с симметричным доступом.
Я не утверждаю что “Реальные бизнесмены ездят на шестисотых мерседесах”. Я привожу пример ТЕХН??ЧЕСКОГО РЕШЕН??Я для которого “high-end”-позиционируемый вендором NetApp FAS/V6200 не подходит потребителю как бы не пытался его позиционировать вендор. Просто по обьективным техническим критериям: мало портов (48 FC max против 192 у VSP и 128 у V-MAX), а в случае выхода из строя ОДНОГО контроллера, их становится двухкратно меньше, равно как и процессорных ресурсов самого массива. Не -1/10, -1/20, а минус половина.
Я эксплуатировал такие решения. С такими обьемами и требованиями к производительности OLTP. Вы, как видимо, нет, или я ошибаюсь?
Я резюмирую для вашего удобства:
V-MAX/VSP: 128/192 max FE FC prts, FED/BED matrix design
FAS/V6200: 48 max FE FC prts, dual HA controller design
Технические аргументы (как я понимаю, опровергающие мои выше приведенные о надежности и производительности в случае отказа контроллера) о хоть какой-либо конкурентноспособностиданного решения от NetApp против приведенных архитектур… будут? ??ли все-таки честно запишем его в категорию пониже. В категорию “хай-ендов от NetApp”.
Про FICON и мейнфреймы отдельный вопрос, по большей части маркетинговый. Обьясню подробней:
Под “FICON на уровне архитектуры” имеется в виду что данные (да и любые другие массивы high-end) поддерживают FICON на уровне микрокода. Они в состоянии обрабатывать I/O протоколу FICON. Будет FICON или нет в том массиве который вы купите — зависит только от наличия или отсутствия FED с FICON портами.
Массивы NetApp FICON не поддерживают в принципе.
Нет, конечно, никто не требует NetApp обязательно иметь mainframe connectivity. Тут мне пришлось просто помянуть рынок. ??х рынок хоть и мал, но весьма стабилен и гораздо прибыльнее чем любой другой. При этом к мейнфреймам подключаются исключительно enterpirse СХД, поэтому те, кто хочет иметь там очень жирные продажи, имеют поддержку FICON в своих устройствах.
Disclaimer: я не работал с мейнфреймами. Все мои технические примеры приведенные в постах выше, основаны на применении исключительно открытых систем.
Но это был ответ ради ответа :-) Вопрос не слишком важный и практически на 95% маркетинговый (данный производитель просто решил не выходить на данный рынок, вполне понятно), поэтому я больше спорить о нем не буду.
Гораздо более меня интересует ваш ответ на технические аргументы приведенные в третьем посте.