about NetApp

Совсем немного времени остается до того момента, когда, по регулярно знакомой владельцам техники Apple схеме, гордые владельцы передовых систем хранения от лидера рынка увидят, как их недавнее приобретение превращается в тыкву становится вчерашним днем.
Ведь в VNX2, новом поколении midrange-систем EMC, и “в 4 раза выше производительность” (с) EMC), и новое кэширование во flash, и обновленный софт управления, и даже долгожданная блочная дедупликация.
Вот только все это - для новых систем, которые придется заново купить. А старые… Старые уже будут не столь передовыми и не столь ведущими, на фоне новых. Они останутся теми, прежними, да, но вряд ли это обрадует клиентов EMC, наконец-то получивших свой долгожданный VNX полгода назад.

Как я и обещал, прошлым постом новости про VNX не ограничатся, тем более, что EMC World дал кое-какую интересную пищу для размышлений. В новом посте Dimitris Krekoukias кратко описывает своим мысли, посетившие его после интересного анонса на EMC World экспериментального контроллера, который, возмжно, будет в будущем моделью VNX.Next.

Напоминаю, что это не мой личный авторский текст, а перевод текста в его блоге, оригинальный текст которого вы можете найти по ссылке и там же, при желании, поучаствововать в обсуждении.

Как расшифровать анонс EMC о новых VNX и заглянуть за маркетинговую завесу

http://recoverymonkey.org/2013/05/16/how-to-decipher-emcs-new-vnx-pre-announcement-and-look-behind-the-marketing

Я с интересом посмотрел некоторые объявления, сделанные в ходе EMC World. Отчасти оттого, что это новости нашего конкурента, отчасти же потому, что я нерд, которому интересно увидеть и узнать что-нибудь по настоящему технически крутое.

BTW: Хочу сказать спасибо Mark Kulacz за его помощь в отношении пруфов. Марк, хоть это и трудно признать, даже больший нерд, чем я.

??так… EMC сделал что-то новое. Демонстрация возможного VNX следующего поколения (VNX2?), недоступна на момент написания поста (на самом деле было много суеты вокруг того, что это существует пока только в виде лабораторного стенда, и т.д.).

Один из результатов, который был показан, это увеличенная производительность по сравнению с их топовой на сегодня VNX7500.

Задача данной статьи - показать, что продемонстрированное увеличение производительности не пропорционально тому, что на этот счет утверждает EMC, и что оно достигнуто не настолько за счет программного улучшения, как это утверждает EMC, и более того, это может означать, что текущие системы VNX внезапно "устареют" без разумной на то причины.
Хотя это и позволит EMC опять поднять денег.

Много шумихи было создано вокруг того, что софт есть ключевой движущий элемент за всеми улучшениями производительности, и того, как теперь можно задействовать все ядра CPU, в то время как раньше, оказывается, это было не так. Софт - здесь, софт - там, и, в общем, это было основной темой всего мероприятия.

OK, убедили. Многоядерность и расширение ее поддержки в сегодняшнем IT-ландшафте это то, о чем говорят все. Параллелизация задач - ключевой момент сегодняшнего IT.

Затем они показали интересный график (я взял слайд из публичного видео):

Я добавил стрелки для уточнения наиболее интересных моментов.

Отметьте, что на левом графике, согласно утверждению самой EMC, текущий VNX использует примерно 2,5 ядра из 6 имеющихся, если вы составите все столбики вместе (например, Core 0 загружен целиком, Core 1 на 50%, Cores 2-4 заняты немного, Core 5 не занят почти ничем). Это важно, и мы к этому еще вернемся. Но, в настоящий момент, если это в самом деле правда, это показывает крайнюю неэффективность использования многоядерности. Все выглядит так, будто ядра процессора фиксированно закреплены за процессами - Core 0 занимается только RAID, например, и так далее. Возможно это способ снизить накладные расходы на переключение контекстов?

Затем они показали, как работает новый контроллер, с 16 ядрами на контроллер (нынешний VNX7500 имеет 6 ядер на контроллер).

ОК, пока все нормально.

Затем они показали, как Святым Духом Программного Обеспечения (в оригинале By The Holy Power Of Software, прим romx), они могут равномерно задействовать все 16 ядер этого нового контроллера поровну (картинка справа).

Далее была интересная часть. Они показали тесты в IOmeter для этого нового контроллера (и только для него).

Они упомянули, что текущий VNX 7500 достигает 170,000 8K операций произвольного чтения (random reads) с SSD (эти цифры сами по себе хороший подарок для разговора с продавцами EMC, обещающими безумные показатели VNX7500 IOPS). ?? что существующая в текущей модели проблема с производительностью связана с тем, что софт не может загрузить равномерно все ядра.

Затем был показан экспериментальный контроллер, продемонстрировавший показатели ввода-вывода в пять раз выше. Это, конечно, впечатляет, хотя вряд ли это реально демонстрирует производительность, но я принимаю это как факт того, что они хотя бы попытались продемонстрировать то, насколько на операциях одного только чтения можно получить от дополнительных ядер, плюс это круто выглядящие маркетинговые цифры.

Записи это всегда отдельная сложность для дискового массива, конечно. Как мы уже сталкивались с этим производительность VNX в этом случае падает радикально.

Однако, это все оставило несколько больших вопросов:

1. Если все это действительно результат оптимизации софта VNX, будет ли это также работать для VNX7500?
2. Почему бы не показать новый софт также и на VNX7500? Это, возможно, даст увеличение производительности более 2x раз, просто за счет лучшей (равной) загрузки ядер контроллера. Но если простой апргрейд софта на VNX7500 позволит стораджу заработать вдвое быстрее, разве не будет это сильнейшим подтверждением утверждения EMC, что “софт – рулит”? Почему нужно пропускать такую прекрасную возможность это доказать?
3. ?? если с новым софтом на VNX7500 мы можем получить, допустим, 400 000 read IOPS на том же тесте, разница между старым контроллером и новым не будет столь радикальна, как ее показывает EMC… правильно? :)
4. Но если загрузка ядер CPU VNX7500 все же НЕ столь плоха, как это показывает EMC в графике выше (зачем было бы заморачиваться с двумя дополнительными ядрами на VNX7500 в сравнении с VNX5700, если бы это было действительно так), тогда улучшение производительности вызвано в основном простой дополнительной мощностью нового железа контроллера. Что, опять же, противоречит заявленной идее про то, что “софт – рулит”!
5. Почему клиентам EMC нужен XtremeIO если новый VNX так быстр? Как насчет VMAX? ;)

Пункт #4 наиболее важен. Например, EMC годами рекламирует улучшение многоядерной производительности. Текущий релиз VNX FLARE имеет якобы на 50% выше эффективность использования ядер, чем ранее. ??, ранее, в 2008 году, многоядерность рекламировалась как дающая двукратное преимущество по сравнению с софтом, использовавшемся ранее. Однако, после всего последовательного улучшения, график выше показывает нам крайне низкую эффективность использования ядер. Кто же тут прав?

??ли же, может быть, новый контроллер демонстрирует улучшение производительности не столько за счет волшебного нового софта, а, в основном, за счет значительно быстрее работающей аппаратной платформы – более быстрый процессор Intel (выше частота, не просто больше ядер, плюс более эффективные инструкции), более новый чипсет, быстрее память, быстрее SSD, шина, и т.д, и т.п. Потенциально новый контроллер сам по себе в 3-5 раз быстрее, без всякого софта, только за счет новой аппаратной платформы.

Однако я, или, по крайней мере действующие клиенты VNX, скорее всего будут более всего обеспокоены пунктом 1. Разу уж, как нам пообещали, все это решается программным путем… :)

Если новый софт так здорово помогает, будет ли он доступен на существующей платформе VNX? Это должно было бы пойти им на пользу, с учетом того, что, согласно EMC, часть ядер там не занимается ничем. Бесплатное улучшение производительности!

Однако… Если они все же НЕ сделают это доступным, единственным рациональным объяснением тут будет то, что они намерены в очередной раз принудить своих клиентов купить новое железо, и сделать новый forklift upgrade (CX->VNX->”new box”).

??ли же, возможно, это улучшение требует аппаратных изменений в платформе. Но тогда это, вообще говоря, разрушает всю рассказанную историю про "волшебный софт", который “рулит”.

Если все это про "Software Defined Storage", то почему этот софт так привязан к железу?

У нас в лабе стоят старинные NetApp FAS3070. ??х контроллеры выпущены поколения назад (2006 год, древняя старина), и при этом они работают под текущей версией кода GA ONTAP. Они были произведены примерно 3-4 поколения контроллеров назад, и, на момент их выпуска, они работали изначально под управлением софта очень, очень отличающегося от существующего сегодня, и все равно нормально работающего на них.

??ногда я думаю, что мы тем самым портим наших клиентов :)

Могут ли CX3-80 (самая навороченная в линейке CX3, такая же древность, как NetApp FAS3070) взять и использовать код, показанный на EMC World? Могут ли они взять действующий GA-код для VNX? Могут ли они взять хотя бы код для CX4? Может ли CX4-960 (опять же, самая навороченная из CX4) взять софтовый код с VNX? Я могу продолжать. Но все это рисует только лишь угнетающую картину того, как EMC относится к защите инвестиций в железо для своих клиентов.

Но разговор про работу с устаревающим оборудованием и его поддержка это отдельная крутая история, о которой мы поговорим в другой раз.

D

??сточник <http://recoverymonkey.org/>

Так как я теперь, стихийным образом (вернее будет сказать попустительством EMC, похоже положившим на продвижение VNX в русскоязычном интернете крупный дюймовый болт) являюсь, в некотором роде, неожиданно для себя, авторитетным источником информации про эту модель стораджей, будем пользоваться сим фактом. ?? сегодня вам очередной перевод из блога Recoverymonkey, с очередными укусами за жёппу ;).

Напоминаю, что тексты, которые я публикую в этом блоге на правах переводов, являются переводами, а не моими текстами, поэтому спорить со мной, наезжать в коментах, или упрекать в чем-либо, например за тон изложения – бесполезно. Сходите по приведенной ссылке, и если испытываете той или иной степени попаболь от того, что автор пишет – скажите это вот прямо там.

Еще несколько предостережений про EMC VNX

http://recoverymonkey.org/2013/05/06/more-emc-vnx-caveats/.

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

Я уже писал в недалеком прошлом вот эту статью (есть перевод, прим. romx), и сегодня я хочу углубленнее рассмотреть несколько аспектов. Обсуждаемые сегодя темы:

1. Эффективность хранения на VNX
2. Утверждение, что LUN-ы могут обслуживаться обоими контроллерами
3. Утверждение, что autotiering помогает в большинстве задач
4. Утверждение, что сторадж-пулы – это просто
5. Производительность thin provisioning
6. Новые снэпшоты VNX

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

Эффективность хранения на VNX

EMC любит утверждать, что на ее системах не требуется отдать 10% пространства в “налог” OS, как это требуется у NetApp (WAFL reserve, прим. romx). Однако, как утверждается по  ссылке рекомендации best practices указывают, что на autotiered pool, как минимум 10% свободного места должны быть всегда доступны на каждом из tier-ов, для обеспечения его нормальной работы.

Также присутствует минимально 3GB оверхеда на каждом LUN, плюс оверхед на метаданные, который вычисляется по формуле, приведенной в статье по ссылке. Плюс дополнительно метаданные, если вы используете дедупликацию.

Моя позиция: Не бывает бесплатного сыра. Если вы хотите новых фич, использующих для своей работы пулы, за это есть определенная цена. В противном случае продолжайте использовать традиционные RAID-группы, там нет новых фич, но они дают гораздо более предсказуемую производительность и характер использования пространства дисков.

LUN-ы могут обслуживаться обоими контроллерами, обеспечивая “load balancing”

Вот тут пошло веселье. Утверждается, что LUN ownership может быть мгновенно переключен с одного контроллера VNX на другой, чтобы обеспечить балансировку их загрузки. Ну, как всегда тут есть тонкости. Важно также отметить здесь, что на момент написания этого поста, в VNX не было никаких средств для организации автоматической балансировки LUN ownership в зависимости от загрузки контроллеров.

1. Если это делается с традиционными RAID LUN-ами: Передача LUN ownership делается без проблем. Это так, как было всегда.
2. Если же LUN находится в пуле – это история другая. Нет способа быстро переключить LUN ownership для такого LUN, без существенного влияния этого процесса на производительность системы.

Обильная информация по тому поводу может быть найдена здесь. Говоря коротко: Вы не можете менять LUN ownership, при использовании пулов, вместо этого вам придется перенести содержимое LUN, на другой LUN, на другом контроллере (именно на другой LUN, перенос LUN-а “как есть” может создать проблемы), в противном случае готовьтесь заплатить производительностью.

Утверждение, что autotiering помогает на большинстве задач

Не торопитесь. (в оригинале: “Not so FAST”, прим. romx). Собственные документы EMC, такие как “best practice guides” полны предупреждений и замечаний, относительно использования autotiering. Несмотря на то, что эта фича фактически пропагандируется в каждой кампании продаж, как создающее множество преимуществ гигантское достоинство.

Вот, например, очень подробный документ “EMC Scaling performance for Oracle Virtual Machine“, этот график найден там на странице 35:

Стрелки добавил я. Отметьте, что наибольшее преимущество в производительности достигается тогда, когда кэш правильно сконфигурирован с точки зрения сайзинга. Дополнительные 5 SSD для VNX tiering (FAST VP) почти не дают существенного повышения производительности на задаче с нагрузкой типа базы данных.

Можно только гадать, какой прирост дали бы эти 4 SSD, если бы были установлены не в autotiering, а увеличили бы кэш…

Быть может, если бы все 8 SSD были бы использованы как all-flash-storage, это было бы даже еще быстрее, чем 4 cache SSD и 5 tier SSD, но это просто лишний раз продемонстрирует слабый “замах” autotiering-а FAST-VP и недостатки его маркетинга.

Утверждение, что storage pools это упрощение работы со стораджем

Типичный подход сэйла EMC к пользователю для продажи VNX это: используйте единый, суперпупер-простой пул дисков с автотирингом данных на нем. Однако вопреки тому, что утверждает маркетинговое шоу, к сожалению, с использованием пулов VNX сложность снижается совсем не так, как это обещается, наприме просто потому что пулы рекомендуются совсем не для любой задачи и не для любой рабочей нагрузки. Рассмотрим типовой сцеарий развертывания VNX, смоделированный по документам best practice:

1. Журнальные LUN-ы RecoverPoint рекомедуется держать на отдельной группе RAID10
2. LUN-ы SQL log на отдельной группе RAID10
3. Exchange 2010 log LUN-ы на отдельной группе RAID10 
4. Exchange 2010 data LUN-ы могут находиться в пуле, но лишь в случае, если он состоит из однотипных дисков, в противном случае нужно использовать несколько традиционных RAID-групп
5. SQL data могут быть помещены на autotiered pool
6. VM могут быть на отдельном пуле, или жить совместно на пуле SQL
7. Репозиторий VDI linked clone может использовать SSD в отдельной группе RAID10

Ну, отлично. Я понимаю все достоинства разделения ввода-вывода, которыми продиктованы рекомендации выше. Однако “продающая” позиция компании в отношении пулов и autotiering это то, что они призваны снизить сложность, общую стоимость решения, улучшить производительность и эффективность распределения пространства. Ясно, что вряд ли все приведенные варианты могут одновременно встретиться в одном стораже на практике. Но что за причина, отчего они не могут быть в одном, или двух пулах, и использовать какой-то вид QoS на массиве, чтобы обеспечить приоритезацию трафика?

?? что получится, если вы отдали лишнего на диски под традиционные RAID-группы в примере выше? Как насчет вернуть или перераспределить это неиспользуемое там пространство другим задачам?

А что насчет варианта, когда места не хватает, как просто вам будет добавить немножко пространства или производительности? (Не в 2-3 раза, допустим, а всего на 20% больше). Сможете вы расширить традиционные VNX RAID-группы на несколько дисков?

?? как там насчет общей эффективности хранения, если все эти задачи нам придется держать отдельно друг от друга? Хмммм…

Для подробностей смотрите документы по дизайну хранилища под Exchange и SQL.

Производительность thin provisioning

О,это просто здорово. Производительность VNX thin provisioning сильно хуже в сравнении с thick, а они оба – в сравнении с традиционными RAID-группами. Проблема с производительнстью возникает прежде всего вследствие того, как VNX выделяет пространство при записи на thin LUN. При этом используются блоки, размером 8KB. Хорошее описание того, как распределяется пространство на сторадж-пуле можно найти здесь (у меня есть перевод, прим. romx). VNX пишет в пулы сементами, размером 1GB. Thick LUN-ы резервируют столько сегментов, размеров 1GB, сколько необходимо, и производительность получается вполне приемлемая. Thin LUN-ы не резервируют место, и, тем самым, не имеют возможности оптимизировать записи и чтения – в результате начинается фрагментация, вдобавок к более высокой загрузке CPU, дискового оверхеда, больше занимается памяти контроллера, все это для обслуживания thin LUN-ов.

Вновь смотрим документ по дизайну хранилища под Exchange 2010, страница 23:

Снова, стрелки на скриншоте, выделяющие важные моменты, добавлены мной:

1. Thin provisioning не рекомендован для высокой нагрузки на VNX
2. Конечно, он такой медленный сам по себе, что вы должны делать ваши thin pools хотя бы на RAID10!!!

Но погодите, thin provisioning придуман для экономии места на дисках, а теперь я должен использовать его на RAID10, который это место просто пожирает?

Какой-то нонсенс.

А что если пользователь желает повышенную надежность и, поэтому, хочет использовать RAID6 на весь пул? Как быстро с этим будет работать thin provisioning?

А, вдобавок у VNX нет способа устранить фрагментацию, которая бесчинствует на их thin LUN-ах. Только через миграцию на другой LUN.

Новые снэпшоты VNX

В VNX появился способ облегчить удар по производительности, присущий традиционным снэпшотам FLARE, перейдя от метода создания снэпшота COFW (Copy On First Write) на ROFW (Redirect On First Write).

Проблема?

Новым снэпшотам VNX требуется использование пулов и thin LUN-ов. Это кажется только технической особеностью, но…

Это те самые две фичи VNX, которые существенно понижают его производительность.

Есть и другие существенные проблемы с новыми сэпшотами VNX, но это тема другого поста. Так что ничего удивительного, что EMC проталкивает RecoverPoint гораздо активнее, чем свои снэпшоты…

??того

Существует маркетинг, и существует “инженерная” реальность.

Поскольку VNX может работать как с пулами, так и с традиционными RAID-группами, маркетинг мудро выбрал не слишком вдаваться в детали о том, что с чем там у него работает.

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

Если вы рассматриваете вариант покупки VNX – по меньшей мере убедитесь, что понимаете, какая из проталкиваемых маркетингом фич будет работать для конкретно вашей задачи. Попросите сделать полную схему разбиения системы на LUN-ы (LUN layout).

?? опять же, мы никак еще не говорили про использование RAID-6 для защиты данных в пуле, это опять же отдельная история для отдельного поста.

D

Я тут уже несколько раз останавливался на новых продуктах EMC, их достоинствах, недостатках, и скрытых, возможно, для кого-то, “подводных камнях”, но не планировал снова возвращаться к теме, по крайней мере, пока не появятся какие-нибудь новости. Однако столкнулся с рядом не очень приятных фактов в жизни моих коллег-кастомеров, и вынужден несколько подробнее остановиться на одной из моделей линейки VNX – VNX5100, самой “младшей” в серии VNX.

Дело в том, что я уже не в первый раз сталкиваюсь с попытками сейлов партнеров EMC продавать EMC VNX5100 клиентам, не указывая ясно им на ряд ограничений конкретно этой модели. Скорее всего это не злонамеренное действие, а просто недостаток информации, или, возможно, просто нехватка компетенции в новых продуктах. Так или иначе, я хочу остановиться на этой тонкости для кастомеров чуть более подробно.

EMC VNX5100 это самая “младшая” в “старшей” линейке VNX (напомню, что VNXe, несмотря на схожесть аббревиатуры, это совсем иная система), а если учесть и весьма низкую цену, по которой она предлагается, неудивительно, что ее активно продвигают на российском рынке. Разумеется с VNX5100 частенько приходится сталкиваться и предложениям NetApp. Однако, сравнивая, стоит помнить, что VNX5100 – это “не совсем VNX”, и вот почему.

Все мы видели эффектный маркетинговый launch EMC, все мы помним что именно на нем было “выкачено” в качестве основных, ключевых возможностей систем новой линейки VNX. Это:

• Мультипротокольность (EMC называет это Unified Storage)
• Порты 10Gb Ethernet и iSCSI “в базе”
• Файловые протоколы (NAS), доступные “из коробки”, на той же системе, без допзатрат
• Дедупликация
• FAST VP (tiering) и FASTcache

Это то, что, в первую очередь, ассоциируется у пользователя с понятием “VNX”, о чем говорится во всех маркетинговых материалах, и что клиент логично надеется получить, покупая систему с названием VNX.

Проблема в том, что в VNX 5100 ничего этого нет.

EMC VNX 5100 это “чисто FC” сторадж, этакий “Clariion CX4 с дисками SAS”, поэтому:

• Только FC (нет ‘unified’ даже в понимании EMC), следовательно:
• Нет файловых протоколов NFS, CIFS.
• Нет дедупликации (даже в ее ограниченном "файловом" понимании EMC)
• Нет iSCSI и FCoE
• Нет FAST VP (tiering)
• Поддерживает использование в FASTcache только одного SSD емкостью 100GB (93,1GB эффективной, форматированной емкости. Плюс необходимые mirror и spare).
• Апгрейд на другой, настоящий VNX (5300/5500/5700) возможен только полной заменой системы (нет data in place upgrade). Это вообще отдельная система, отличающаяся по организации данных от всех остальных VNX/VNXe.

Является конкурентом NetApp в сегменте FAS2040 или FAS3210, но:

• Максимальное количество дисков невелико - 75 (против 136 у 2040 или 240 у 3210), то есть всего около 30 дисков данных, при использовании RAID-10, при нехватке дисков - см выше про невозможность апгрейда на 5300/5500/5700.
• Только 4 FC-порта для хостов/фабрик и 2 порта SAS для полок (на контроллер, на пару - 8/4 ) без возможности расширения.
• Очень ограниченное предложение по софтовой части решения (за счет отсутствия NAS-компоненты и связанных с ним софтовых продуктов EMC).

Да, VNX 5100 дешев. Ранее я уже говорил, почему “цена ниже рыночной” должна вас сперва настораживать, а потом уже радовать. Обычно за этим скрывается ряд засад, подобных указанным выше.

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

“NetApp?” – говорит сэйл компании партнера EMC – “Мы вам предложим кое-что получше! Новый сторадж от лидера отрасли – VNX 5100! Вот, возьмите брошюру (в которой рассказывается про 5300 и 5700, а пункты про 5100 сопровождены маленькой серой звездочкой-ссылкой на мелкий шрифт в конце: “not available for 5100”), а главное: она в полтора раза дешевле этого NetApp! Что раздумывать, берите!”

В результате пользователь, заплативший заманчиво низкую цену за “новую систему хранения от лидера рынка” получает, фактически, систему предыдущего поколения, без всех рекламируемых новых функциональных фич, да еще и без возможность апгрейда, оказываясь разом на “боковой тупиковой ветке” продукта.
Зато задешево. :-|

Остерегайтесь “заманчиво низкой цены”. Внимательно читайте мелкий шрифт. ?? не забывайте, что, очень часто, сэйлы, и даже пресэйлы партнеров, особенно многопрофильных интеграторов, могут не вполне твердо владеть темой в новых продуктах вендора.

Такой вот вам Caveat Emptor*

PS. Я, как и ранее, должен отметить, что я не являюсь специалистом в системах EMC, и если в перечисленных выше фактах о 5100 в моих источниках ненамеренно вкралась ошибка, то, если вы куда больший специалист, и у вас есть данные о том, что я по ошибке написал что-то неверное про EMC, обязательно сообщите мне это, я обязательно поправлю это место в тексте.

PPS. Благодаря Сергею из комментариев было поправлено несколько не вполне ясно написанных мест и неточностей.

* Caveat Emptor (лат.) – “Покупатель – остерегись!”, приписка традиционно делаемая при изложении чувствительной для покупателя информации, особенно в области технических характеристик или условий покупки.

Сегодня еще один пост 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 протестировала общую грузоподъемность четырех “грузовиков”. Я поступил также, и взял результаты четырех нетапповских “грузовиков”, и вот что получилось:

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

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

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

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

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

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

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

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

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

В моем блоге очередной перевод поста в блоге 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”!

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

На что же следует обратить внимание, останавливая свой выбор на EMC VNXe, из того, о чем, часто, самим EMC упоминается вскользь. ??ли, как пишет один блоггер, “всегда читайте то, что написано на странице самым мелким шрифтом”. Вооружимся лупой и приступим к чтению :)

Как я уже писал в первой части, очевидной целью VNX/VNXe на рынке являются системы NetApp, слишком очевидно, что многое в них сделано с прицелом “ответ на”. А поэтому давайте определим, с какими системами NetApp соответствующие модели EMC VNXe конкурируют, и оценим их плюсы и минусы.

VNXe – это системы “младшего” семейства. ??х естественным конкурентом являются модели 2000-й серии NetApp FAS, а также, отчасти, модель 3210 из “новых”. Напомню, что серия 2000 у NetApp состоит на сегодня из трех моделей, это FAS2020 и 2050, производящиеся с 2007 года, и подходящих к концу своей активной карьеры, и более новой FAS2040. Также частично в это семейство попадает FAS3210.

Совершенно естественно, что для VNXe возможности FAS2000 надо “крыть”, что, впрочем, по идее, не должно быть сложным, перебивать системы 4-летней давности.

В серии VNXe имеются две модели – VNXe 3100 и VNXe 3300.

VNXe 3100 превосходит по формальным параметрам FAS2020 (было бы удивительно, если бы новая система проигрывала бы по ним системе 4-летней давности;), например по максимальному количеству дисков (96 у 3100 против 60 у 2020) и больше кэш памяти (8GB против 2GB). Однако VNXe 3300 проигрывает по максимальному количеству дисков системе FAS2040 (120 против 136 дисков), но превосходит по объемам кэша (24 против 8 GB). Также в системах класса FAS2000 нет опции 10GB Ethernet, она появляется только на 3210.

Однако давайте посмотрим внимательнее на сторону общих ???факапов’ ;)

Как я уже мельком упоминал в первой части, EMC решила в VNXe полностью отказаться от FC. FibreChannel в VNXe не предлагается даже как опция. В чем-то я даже соглашусь с таким решением, как вы знаете я последовательный сторонник Ethernet storage, но если в случае FAS2020 у нас есть выбор, продолжать использовать FC или нет, то в VNXe это решили за нас. Все, FC – вчерашний день. Его в этих системах не будет. Точка.
Как опция есть 10G Ethernet (для 3300 только). впрочем, как я понимаю, это не Unified Target, завести в него все интерфейсы и протоколы, и сделать в нем FCoE не выйдет. Также вопрос, насколько 10G Ethernet полноценно потянет внутренняя шина. В новых 3200/6200 у NetApp шина сделана PCIe 2.0, вдвое более широкая, чем обычный PCIe, не в последнюю очередь именно ради комфортного и достаточного обеспечения работы 10G Ethernet портов.

Довольно теоретическое ограничение для систем “малого класса” на количество LUN/Vol. У 3100 допустимо максимум 128 LUN и 256 Vol (512 у 3300), что сильно меньше, чем 1024 у FAS2020, хотя я  не думаю, что такая маленькая система, как 3100 сможет упереться в 128 LUN-ов в реальной жизни. Но держать в памяти стоит.

Самая серьезная проблема, с которой столкнутся будущие покупатели VNXe, это, на мой взгляд, невозможность апгрейда с data-in-place (то есть с сохранением данных “на их местах”, на дисках) на более “взрослые” системы VNX, а также, если вы уже клиент EMC, то невозможности data-in-place с ваших текущих систем, например AX4 или NX4.

Если вы переросли VNXe, и захотели перейти на VNX, то не обманывайтесь похожестью аббревиатур, различие тут не в одной маленькой буковке ???e’.
EMC VNX и VNXe это принципиально разные по внутреннему устройству системы. Просто перенестись между ними не выйдет, как и не выйдет перейти, например, с сегодняшней вашей Clariion AX4 или CX4-120, или Celerra NX4, на VNXe.
Переход возможен только с полным переносом данных со старой на новую. Старую систему забэкапили, остановили, вынули, новую собрали и поставили, проинсталлировали и разбили, и данные на нее восстановили. Старую можно попробовать продать на eBay ;)

У FAS2000 тоже не все в порядке с апгрейдабельностью на midrange, увы, это общая плата за дешевизну, но у них вы хотя бы штатно можете взять все ваши имеющиеся полки с дисками расширения и переключить их, прямо кабелями, на контроллер новой системы, будь то хоть даже FAS6280, и все данные увидятся, поднимутся и заработают немедленно после физического переключения. ?? в любом случае вы сможете использовать диски и полки от старых систем на новых. Новая серия FAS3200/6200, как и более ранние, поддерживает как FC, так и SAS.

По софту. Я уже говорил в первой части о определенных проблемах софтверного плана, остановлюсь на этом более подробно.

Я уже упоминал, что дедупликация на VNX/VNXe только пофайловая, то есть работает на NAS-уровне только, и дедуплицирует только полностью идентичные файлы, в отличие от субфайловой/блочной дедупликации NetApp, которая может дедуплицировать и содержимое различных файлов, если внутри у них есть сходные фрагменты. Пример – разные файлы vmdk с разными виртуальными машинами в них, но с идентичной OS, и, следовательно, сильно совпадающих по содержимому. В целом файлы vmdk не одинаковы, но в значительной мере идентичны внутри.
Как показывает исследование (например см. публикацию с конференции FAST’11: A Study of Practical Deduplication), субфайловая дедупликация сравнительно маленькими блоками (в случае NetApp размер фиксированного блока равен 4KB) более эффективна, чем файловая.
Следует также помнить, что “файловая” дедупликация EMC не работает на самых “вкусных” с точки зрения дедупликации задачах, например на NFS-хранилище для VMware, где NetApp стабильно показывает 70-90% снижения занимаемого данными объема.

Возможно, во второй половине года, будет объявлено о выпуске блочной дедупликации у VNX. Обещаю тогда, когда она стант официально доступна, внимательно рассмотеть ее, прочитать все написанное мелким шрифтом (есть ощущение, что радость придет далеко не всем), и рассказать вам о ней.

Репликация для VNXe имеется только асинхронная. Конечно, асинхронная репликация более востребована, особенно на небольших системах, но тут опять же “все выбрали за нас”. “Вам не нужна синхронная репликация” (и рукой так, по джедайски;). Кроме того, репликация также не имеет никаких средств оптимизации (например компрессии) трафика, передаваемого по WAN. Это возможно сделать какими-то сторонними, внешними средствами, например с помощью устройств Riverbed, но у NetApp эта “компрессия” встроена.

Нет собственных средств для offsite-backup, например чего-то аналогичного SnapVault, а хранение снэпшотов на дисках системы по прежнему больно ударяет по производительности, каковой проблемы лишен NetApp.

SnapSure несовместим с дедупликацией (single-instancing) и компрессией. Либо снэпшоты, либо дедупликация и компрессия. Если вы планируете использовать дедупликацию и компрессию, вы сильно сокращаете набор доступных вам для этих данных возможностей, таких как клоны и снэпшоты.

Компрессия – постпроцесная, то есть как дедупликация в NetApp. Сперва записали много, а потом что-то вернули когда отработают процессы. У NetApp компрессия онлайн. То есть вы “на ходу” записываете на диски меньше.

Дедупликация и компрессия работают только на файловом уровне, а размер файлового тома не может превышать 16TB. Компрессия и дедупликация не работает для LUN-ов, VMDK, файлов PST, данных Oracle over dNFS, и прочего подобного.

Когда EMC говорит о полной сертификации под VMware, то тут есть определенная доля лукавства. В настоящий момент, по моим данным, VNXe 3100 сертифицирован только как NAS, а VNXe 3300 – только как iSCSI (если на момент публикации это уже изменилось – поправьте меня). Я уже писал ранее, в части 1, как все непросто с так называемым Unified Storage (делает жест “кавычки” пальцами рук;) в понимании EMC. ?? следовательно как все непросто с функциональной совместимостью между NAS и iSCSI SAN в такой конструкции.

Сильно муссируется факт принадлежности VMware компании EMC, из этого как-бы естественно должен вытекать вывод, что системы EMC для VMware “более родные”, однако тут не все так просто. Несмотря на то, что 70% акций VMware действительно принадлежит EMC, VMware (VMW) это independently listed company, то есть ее акции котируются на бирже независимо от акций EMC (а вот, например, Isilon (ISLN), или Data Domain (DDUP) других недавних покупок EMC – уже нет), и она во многом самостоятельно определяет свою политику на рынке. Парадоксально, но, если мне не изменяет память, отношения технологического партнерства у VMware с NetApp чуть ли не более продолжительные, чем с собственно EMC! Они были установлены еще до “покупки” VMware!

У VNXe (сейчас) нет возможности использовать SSD, а следовательно – нет FASTcache. У NetApp для FAS2000 тоже нет FlashCache, зато он есть в FAS3210, который вполне можно, умеючи, “умять” по цене в “старшие low-enterprise”, если Flash вам понадобится. Тем не менее помните, что когда EMC говорит про FASTcache, это не относится к VNXe.

Нет FAST VP – автоматизированного storage tiering, с переносом данных с SAS на NL-SAS.

Нет официальных, подтвержденных данных о производительности новой архитектуры. Ну то есть заталкивать девушек в Mini это прикольно и честно-благородно, но все же как там насчет баб производительности, а? ??звините, что я вам весь пафос момента сбиваю, нам бы вот на IOPS-ы бы посмотреть, а? ;)
Впрочем, про производительность и о “EMC’s approach” к этому вопросу это мы еще поговорим в среду и далее.

Да, несомненно системы VNXe имеют поразительно низкую для своего класса цену. Но, строго говоря, “цена ниже рыночной” должна вас сперва насторожить (а только потом – обрадовать). Если VNXe так хорош, то почему его отдают так дешево? Нет ли тут some gotchas, как выражаются наши англоязычные друзья? Ведь не секрет, что в энтерпрайзе  “потребительская ценность” есть сумма из:

Цена железа + бренд + потребительские свойства = потребительская ценность

Если бренд высок у обоих вендоров, если цена физического железа примерно равна, то низкую цену для потребителя на выходе мы можем получить только за счет какой-то недостачи в потребительских свойствах, по сравнению с аналогичным продуктом конкурента, какую мы и постараемся замаскировать “привлекательной ценой”. Либо же объявленная цена есть фактический “порог рентабельности”, а значит нет надежд на значительную скидку в процессе привычного торга в “треугольнике” вендор-партнер-клиент.

Да, цена у NetApp обычно высока, но почему именно она высока, я уже писал в посте ранее. За большую цену и возможностей вам достается больше. Для многих это достаточный аргумент, для кого-то – нет. Но я бы хотел, чтобы вы помнили очень хорошую фразу в отношении цены покупки в IT: “Деньги вы экономите один раз и “дядины”, а геморрой покупаете надолго и свой”.
Пусть не застилает вам глаза низкая цена.

Сегодня у нас не просто дюжина, а целых три дюжины ножей в спину EMC-шной “революции”, “неудобные вопросы” к EMC по поводу VNX/VNXe от блоггера Recoverymonkey (Dimitris Krekoukias), общим числом 36, опубликованные в его блоге.

Dimitris – сотрудник NetApp, но ведущий собственный, автономный и независимый блог, вне blogs.netapp.com, пишущий много интересного, так что переводы его публикаций в этом блоге будут появляться часто.

Беспрецедентная маркетинговая шумиха, поднятая вокруг старта новых продуктов EMC – систем VNX/VNXe не должна совсем запорошить нам глаза, настолько, чтобы мы не могли критически проанализировать возможные недостатки новой системы, а их, если посмотреть внимательно, хватает. ?? в особенности остановимся на многократно повторяемом EMC-персонами в отношении новых систем слово Unified. 
Немного сокращенный перевод поста recoverymonkey предлагается сегодня вашему вниманию.

Questions to ask EMC regarding their new VNX systems…

Posted on January 13, 2011 by Dimitris

1. Возьмем, к примеру, систему VNX емкостью  100TB. Допустим, что мы отдали все 100TB под NAS. Допустим, что все 100TB были первоначально заполнены данными, но затем, год спустя, объемы данных в NAS уменьшились, и сейчас занимают всего 70TB. Могу я взять эти освободившиеся 30TB и немедленно использовать их под FC? Ну хранилище же теперь “unified”, так? Без необходимости нарушать  best practices для размещения LUN на Celerra?
2. Является ли VNX (или хотя бы NS, стоящая перед ним) системой, сертифицированной на “пять девяток”? (Это так для CX, но как насчет комбинации CX/NS?)
3. Где в архитектуре принципиальная разница с тем, что было до сих пор? Все выглядит так, что у вас есть 2 штуки CX SP, и перед ними NAS gateways. Выглядит очень похоже на то что было, и по прежнему в этом нет ничего unified. Давайте все же привнесем немного правды в рекламу! Только маленькие VNXe выглядят чуть иными (не с точки зрения софта, но хотя бы с точки зрения количества корпусов, на которых это работает).
4. Кажется новые системы лицензируются по емкости?
5. Могут ли новые системы использовать больше 2TB в FAST Cache? (больше чем текущий CLARiiON CX4-960)
6. Как дела с гранулярностью при использовании RecoverPoint при репликации NAS-части? Кажется там необходимо реплицировать весь NAS как единый чанк, как одну большую consistency group, с необходимостью использовать Celerra Replicator для большей гранулярности?
7. Как дела с гранулярностью при восстановлении NAS в RecoverPoint? Нельзя сделать восстановление на уровне отдельного файла или даже тома?
8. Можно ли сделать обновление с сохранением данных на дисках, в случае уже имеющихся CX3 или CX4 (data-in-place upgrade) или это обновление с полной заменой (forklift upgrade)?
9. Почему FASTv2 не рекомендован для Exchange 2010?
10. Может ли FAST на VNX исключать из анализа ряд периодов времени, которые могут сбить его алгоритм, например период создания резервной копии данных?
11. А FAST файлового уровня это по прежнему отдельная подсистема?
12. Почему для VNXe в принципе нет варианта использовать FC?
13. Можно ли обновиться с VNXe на VNX?
14. А на VNXe есть FAST?
15. Почему FAST по-прежнему использует такой огромный и неэффективный чанк размером аж 1GB?
16. Почему такие функции, как блочный доступ, NAS и репликация по прежнему требуют использования отдельного друг от друга железа и софта?
17. Почему по-прежнему существуют две различные системы создания снэпшотов?
18. Ну хотя бы теперь блочные снэпшоты не вызывают такого огромного падения производительности? Кстати, как дела со снэпшотами на NAS?
19. Хотя бы теперь мы можем хранить снэпшоты на системе подолгу, например год, если это нам необходимо?
20. Почему предлагается целых 4(четыре!) разных средства репликации? (Mirrorview, Celerra Replicator, Recoverpoint, SAN copy)
21. Что там о сих пор делают в таком количестве все эти разные OS? (Windows в StorageProcessor, Linux в Control Station и RecoverPoint, DART в NAS-blades, может быть больше, если вы захотите добавить Rainfinity и Atmos)
22. Почему по-прежнему нет дедупликации для FC и iSCSI?
23. Почему нет дедупликации для памяти/кэша?
24. Наконец, почему нет суб-файловой дедупликации вообще?
25. Почему Celerra по-прежнему ограничена объемом 256TB на один data mover?
26. ?? Celerra по-прежнему ограничена объемом 16TB на том? ??ли нам нужна еще одна, полностью отдельная система (Isilon), чтобы получить объем тома больше 16TB?
27. Celerra по-прежнему не умеет совместно использовать том между data movers? ??ли для этого опять нужен Isilon?
28. Почему мы не можем передавать все протоколы по одному 10Gb-линку, если VNX это настоящий “unified”?
29. Устранены ли проблемы с производительностью при использовании thin provisioning ?
30. Устранены ли проблемы с “узким горлом” (bottlenecks) для пула?
31. Можем ли мы в самом деле делать stripe/restripe в пуле FLARE? Когда добавляем пространство? С использованием thin provisioning?
32. Для того, чтобы использовать thin provisioning, по-прежнему нужна миграция данных?
33. Устранены ли проблемы с низкой эффективностью RAID5 и RAID6 при записи? ?? каким образом?
34. Будут ли бенчмарки для новых систем показываться для RAID6, или это будет, по-прежнему, только RAID10? Как насчет участия в бенчмарках SPC-1?
35. Почему EMC по-прежнему обходит стороной тот факт, что ее пулы теперь построены с использованием файловой системы? Может быть потому, что они продолжают утверждать, что такое, де, не настоящий SAN, даже в совсем недавних утверждениях?
36. Теперь, когда EMC использует файловую систему чтобы получить в CX SPs функциональность пулов, thin provisioning, компрессии и auto-tiering (и, возможно, дедупликаци в будущем), как собирается решаться проблема фрагментации? (О как повернулась ситуация!)

Таким образом, когда EMC говорит о “Unified Storage”, они на самом деле имеют ввиду “Unified Management”. Было бы здорово, если бы они были честными, и так бы это и говорили, о “наших новых системах хранения, с новым единым управлением, пусть и не unified-архитектурой”.
Но “новые системы хранения с unified-управлением но не-unified-архитектурой” гораздо хуже выговаривается, чем “unified storage”.
Unified Management, к сожалению,  не может помочь решить многих нижележаших проблем и ограничений, хотя, безусловно, позволяет показать ряд впечатляющих демонстраций.

Крутой GUI под которым находится наскоро слепленный франкенсторадж с использованием множества различных технологий, это конечно “работает” для пользователя, и винегрет под общей крышкой хорошо замаскирован снаружи, пока все… как правило в самый неподходящий для этого момент.

Конечно, средства управления это основной “интерфейс к системе” для конечного пользователя, многие люди не заботятся о том, что там, за ним, внутри, у них нет ни времени, ни склонности учиться. Я просто хочу пригласить их узнать побольше, начать думать о том, как оно там устроено внутри, потому что когда там внутри устраиваются какие-то трюки, и когда внешний GUI прикрывает разрозненных 4-5 различных продуктов, собранных под ним вместе, и когда оно перестает работать так, как задумано, то вас могут начать “футболить” между 3-4 различными и плохо связанными между собой группами поддержки, которые будут пытаться выяснить, какой из продуктов в итоге явился причиной проблемы.

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

?? всегда помните, что чем сложнее машина, тем сложнее найти поломку, тем сложнее ее починить, когда она сломалась (а она сломается, они всегда ломаются, все и всегда). Никакая внешняя красота не заменяет чистого и простого инженерного решения внутри.

Конечно, машина в стиле Rube Goldberg-а это прикольно, если прикол есть ваша конечная цель.

Ну вот, как я и обещал раньше, дав поднятой маркетинговыми лаунчами пыли осесть, взбутетененной мути – отстояться, а объективным данным и анализам – появиться, начнем мы в этом блоге серию постов про продукт нашего ближайшего “соседа”-конкурента, новинку EMC, системы хранения серии VNX/VNXe.

Напомню, что в январе EMC с большим шумом и беспрецедентным размахом выкатил ряд новинок, и главную – новую линейку систем хранения младшего-среднего “энтерпрайза” – EMC VNX/VNXe, приходящую на смену классическим CLARiiON/Celerra.
Шум при этом был настолько большой и гм-м.. странный по форме, что сразу возникло подозрение, что этим масштабным лаунчем и сценическим шоу пытаются отвлечь внимание от определенных недостатков и “недоработок” продукта.

Следует отметить, что, безусловно, выпуск VNX это большой шаг EMC, причем шаг в правильном направлении. ?? пусть злые языки сейчас говорят, что EMC, мол, выпустила новый сторадж, “чтобы было как у NetApp”, мы отметем эти реплики с мест как неорганизованные (с). Приятно, конечно, когда мировой лидер взялся реализовать, пусть и с многолетним опозданием, решения, которые придумала и много лет продвигала значительно меньшая компания, тем самым признавая ее приоритет в этом вопросе, и правильность ее пути. Но все же это решение EMC. Что же нового в этих полностью новых системах хранения?

Ну-у, у них теперь крутая интегрированная система управления Unisphere.

А что там в аппаратной части? Как оно вообще, этот новый Unified Architecture? 
Новые процессора, переход на SAS-диски и SAS-интерфейсы к полкам (велкам ту зе клаб, наконец-то). Новые передние панели, очень эффектные :)
…?? все?
А вот похоже на то, что и все. Удивлены? Да не то слово.

Но как же, как же, ведь нам обещали новую, прогрессивную, передовую Unified Architecture, нечто по-настоящему новое, оно где? Оно ведь есть?

Ну-у… Давайте посмотрим, что появилось нового.
Слева – классическая Celerra NS, справа – новый VNX.

Может быть я недостаточно фанат EMC (что очевидно), но по моему нам пытаются продать то же самое, но, в лучших традициях ритейла, “теперь в новой, удобной упаковке”, с банановым вкусом. :)

Да, VNX действительно может отдавать данные на дисках по разным, как блочным, так и файловым протоколам, это то, что “у нас в деревне” называется multiprotocol. 
Но Multiprotocol это все же не то же самое, что Unified.
Рядом, но не то же самое.

Это все равно, как если бы некто, с большим шумом объявил бы о ребрендинге и новом, прогрессивном логотипе компании ЗЕЛЕНОГО цвета. Зеленый это экологичность, он несет в себе стабильность, позитивность, дружественность…
- Погодите, – перебиваете вы докладчика – я что-то не понял. Вы говорите “зеленый”, но логотип же – синий?
- Да какая разница, – отвечают вам, зеленый это теперь новый оттенок синего! Главное что он – ЗЕЛЕНЫЙ, новый, и прогрессивный!

Самое печальное в этой истории, что когда такая маркетинговая и сейловая машина, какой располагает сегодня EMC, начнет настойчиво твердить рынку, что зеленый – это новый оттенок синего, а мультипротокольность – это и есть unified architecture, то рынок неизбежно, в конце концов, и сам поверит, что черное - белое (просто плохо освещенное) , зеленое – синее (ну, другой оттенок просто), а Unified Architecture – это собрать пять ящиков под тремя OS в одном шкафу, и продать клиенту по одной накладной.

Давайте все же остановимся на некоторых очевидных недостатках и проблемах для клиента при переходе на VNX/VNXe, видимых, так сказать, с “нашего берега” этой реки:
(Прошу держать в памяти, что я не являюсь специалистом по оборудованию EMC, и что если где-то здесь, или в любом другом посте, где я говорю о продуктах конкурентов, я допускаю неточность или ошибку, не стесняйтесь мне на нее указать, я поправлю это место, спасибо.)

• Полный отказ от “старых” дисковых полок, подключаемых по FC. Невозможность сделать data-in-place upgrade, то есть с сохранением данных на уже существующих дисках. Ну и что, что у вас уже два шкафа с дисками EMC под год назад купленный Кларион CX4 и 24×7 ERP-база на них? Купите еще два шкафа дисков, скопируете, потом старые продадите кому-нибудь.
• Forklift upgrade даже и с VNXe на VNX, как бы ни были похожи аббревиатуры моделей – апгрейд только целиком, никакого data-in-place (с сохранением данных). “Внутри” VNX от VNXe отличаются сильно, не позволяя прямого перехода.
• Для VNXe нет FC как интерфейса подключения. Вообще нет. 
  Да, VNXe это entry level, и использование entry level с FC это, обычно, overkill, но, допустим, у вас есть уже развитая FC-инфраструктура с “большими” стораджами, и вам понадобилось включить в нее небольшой вспомогательный сторадж, для бэкапа-ли, для удаленной реплики, неважно. Включить в FC-фабрику VNXe вы не можете. Просто некуда.
• В VNXe нет FASTcache. Нет и не будет. Увы.
• По-прежнему полностью раздельная архитектура. Отдельно блочный сторадж (под FLARE), отдельно файловый гейтвей data mover (под DART), отдельно Control Station (под Linux), отдельно объектный гейтвей Athmos. С общим, снаружи, управлением под Unisphere. Никакого Unified Target.
• Только файловая дедупликация. Значит нет дедупликации для LUN-ов, например для Datastore под VMFS в VMware. Совсем нет. А для файлов эффективность меньше, чем в случае субфайловой/блочной дедупликации. Кстати для VMware и Oracle по NFS ее нет тоже.
• Множество разнородных софтверных средств для одних и тех же задач. Три разных инструмента для использования снэпшотов (SnapSure (file), SnapView (block), RecoverPoint SE/CDP (block)), три – для репликации (Replicator (file), MirrorView (block), RecoverPoint SE/CRR (block)), два – для локальных клонов (SnapSure (file), SnapView Clones (block)). Все с разными функциональными возможностями и особенностями применения.
• Capacity-based licensing. Низкая цена “на старте” может оказаться совсем не такой низкой, если вам понадобится увеличить емкость (а вам понадобится ее увеличить, это, в нынешнем мире, неизбежно) – готовьтесь платить еще, позже.

В среду читайте перевод статьи блоггера recoverymonkey о вопросах к EMC по поводу запуска VNX, а далее, на следующей неделе, в понедельник и четверг соответственно, мы рассмотрим подробнее каждое семейство, VNXe и VNX, и то как, и чем они собираются конкурировать с системами NetApp.

Продукт, о котором долго говорили, результат скрещения жабы с мотоциклом Celerra и CLARiiON, настоящего (еще более настоящего;) Unified Storage от EMC, базирующегося на файловой системе shenanigan-ского блочного стораджа – VNX.

Да уж, давайте, давайте, заждались (потирает ручонки), наконец-то посоревнуемся за пользователей всерьез, без глупого лечилова про “настоящий fibre channel”.

??сточник: http://www.theregister.co.uk/2011/01/04/emc_vnx_unified_storage/

Подробности, по всей видимости - 18.01.

PS. ??нтересно, съест ли свою шляпу Чак Холлис? ;)

UPD: Подробности нашлись на SearchStorage

UPD: Да, вернулся в эфир чуть раньше, сначала предполагал запостить это 17, в понедельник, накануне официального анонса, но так как прошла утечка, и народ в интернетах загомонил, решил не ждать, да и вам интереснее.