FAS (NetApp) vs EVA (HP)

[Сергей Дубров]

Граждане, встал вопрос выбора сетевой системы хранения. И если с хипишными продуктами (типа EVA 4400) я немного знаком, то с FAS-ми уважаемой фирмы NetApp никогда близко не сталкивался в доступных мне окрестностях. Есть тут пользователи СХД от NetApp? Интересуют младшие модели, 20xx. Например, мне очень понравилась новая FAS2040 - 2x2 FC, 2x4 1Gb Ethernet, умеет (это традиция NetApp) одновременно, не требуя дополнительных лицензий, работать как SAN (FC), NAS (NFS, cifs), iSCSI при вполне умеренной цене ~7.5K$ (правда, это не у нас, а "там", и цена без дисков, естественно).

Нет ли здесь счастливых обладателей FAS-ов? Необязательно указанной модели, интересуют и цены и общее впечатление. Совсем здорово, если бы кто-нибудь мог сравнить соответствующие решения от HP и NetApp. EMC не рассматриваю вполне сознательно, в указанной нише они заведомо прогрывают конкурентам по ценам.

[Константин Ошмян]

Сергей, приветствую!

У нас вводятся сейчас в эксплуатацию как раз два массива - FAS2040 и FAS2050, предполагается использовать миррор между ними (они будут на разных площадках) и снапшоты. К сожалению, грамотно сравнить с чем-либо мне затруднительно, поскольку из других массивов у нас только IBM DS6800 (но у неё FC-интерфейсы лишь на 2Gb, а у FAS-ов - на 4).

Я тут недавно сравнивал производительность дисковой подсистемы при доступе с сервера NetWare, получил любопытные результаты, которые меня несколько удивили. Тестировал программой Portlock Storage Manager v5.03, на сайте можно взять evaluation, который работает с первым гигабайтом устройства или тома (мне для тестирования вполне хватает). Во время тестов я обращался к голому устройству (не создавая на нём томов, файловой системы и т.д.), и гонял с парамером "количество секторов на одну операцию ввода/вывода", равным 8 (т.е. 4кБ, что соответствует размеру блока для NSS).

В отличие от IBM-овского массива, у которого все FC-интерфейсы равноправны, в NetApp-овском массиве работа с конкретным LUN-ом ведётся фактически лишь через один интерфейс (а в случае аварии может переключиться на резервный). Т.е. распределения нагрузки по разным путям не будет в любом случае. Несмотря на это, при работе по основному пути FAS показал себя явно лучше, чем DS, даже когда я для справедливости "зажимал" скорость до 2 Gb на FC-адаптере сервера. С другой стороны, при работе массива по резервному интерфейсу производительность получается очень неровной (разные замеры давали разницу до 30 раз), поскольку она зависит от общей нагрузки на массив (в частности - делаются ли снапшоты и мирроры). Т.е. надо отдавать себе отчёт в том, что работа по резервному интерфейсу - всё же нештатная ситуация.

Разница в производительности при использовании различных технологий multipathing-а - NetWare и драйвера SDD - невелика (это тестировалось только с массивом IBM). Драйвер SDD (обеспечивающий распределение нагрузки по разным путям) даёт некоторый выигрыш при чтении, но, в то же время, немного проигрывает в операциях записи.

Неожиданностью явилось то, что производительность операций произвольного чтения (R/O Random) зачастую оказывалась гораздо ниже ожидаемой. Например, у массива IBM разница между R/O Sequential и R/O Random составляла два порядка (40-50 раз), у массива NetApp максимальная разница была менее чем вдвое (всего 45%). Отдельно стоит отметить, что на производительность именно в этих тестах наиболее сильно сказывался параметр "количество блоков на одну операцию ввода/вывода": при его увеличении производительность сразу же существенно возрастала. Однако, поскольку меня интересовали данные, как было сказано выше, для стандартного блока 4 КБ, то результаты оказались таковы. Возможно, следует уделить большее внимание аналогичному параметру при настройке самих дисковых массивов.

Наконец, явилась полной неожиданностью настолько низкая производительность при доступе к тому же самому дисковому массиву NetApp по протоколу iSCSI. По сравнению с FC - разница была более чем 120 раз (при последователных чтении и записи). При этом, с одной стороны, использование Jumbo-frames даёт заметный прирост производительности (по сравнению с фреймами стандартного размера - прирост от 50 до 75%). С другой стороны, все прочие ухищрения по оптимизации (описанные, например, тут или тут), не дали сколько-нибудь ошутимых изменений вообще. Правда, я не могу утверждать, что виноват здесь именно массив NetApp - вполне возможно, что это особенности реализации протокола iSCSI у NetWare; для корректной интерпретации данных результатов было бы желательно подключить по iSCSI ту же нетварь к другому массиву (но у меня больше не к чему), либо подключить к этому же массиву по iSCSI другие операционки (но до этого у нас не дошло).

Ну и немаловажный для нас момент - возможность мониторинга массива по SNMP. У NetApp-а - нормальный MIB, можно видеть практически все более-менее важные параметры. У IBM мы долго разбирались, как его мониторить (поскольку SNMP-management кое-где в описании упоминался), пока не нашли открытым текстом информацию о том, что ни на какие запросы по SNMP отвечать оно не умеет. По SNMP это чудо умеет лишь слать трапы, всё.