about NetApp

Сегодня еще один пост 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.

На интересный факт обратили на днях внимание. Оказывается сегодня Market Cap (“Рыночная капитализация” по-русски), у EMC, если отнять из нее Market Cap VMware, уже меньше, чем у NetApp. При этом NetApp – это, по сути, “вендор одного продукта”, в отличие от “коллекции” EMC, где Symmetrix, Clariion, Celerra, Data Domain, Isilon, Iomega, Avamar, Centera,  etc, etc.

А вот так выглядят темпы роста бизнеса компаний за два года.

??сточник: Google

Ничего удивительного, что EMC так нервно реагирует на всякое упоминание слова “NetApp”. ;)

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

“Умный, честный и партийный. В одном человеке бывают вместе только два свойства из трех” шутили в пору моего детства (кстати шутка обрела второе дыхание в нынешней России).
??ли же есть вариант, особенно для IT -  “быстро, хорошо и дешево”.

EMC, кажется, нашла еще один вариант ;)

Я бы, на месте 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, в понедельник, накануне официального анонса, но так как прошла утечка, и народ в интернетах загомонил, решил не ждать, да и вам интереснее.

“Какой пассаж!”, как говаривала гоголевская дама. Столько ведер презрения было вылито на NetApp Чаком Холлисом за эти три года за использование им в своих системах блочного протокола поверх “файловой системы”, и ради чего?

Ради того, чтобы три года этой ругани спустя, потеряв много больше лет, на протяжении которых NetApp совершенствовал свою систему, EMC пришел в своих продуктах, по сути, к тому же самому решению – блочному протоколу поверх нижележащей файловой системы.

??рония судьбы.

У одного из нетапповских блоггеров увидел хорошую статью, перевод фрагмента которой хочу опубликовать у себя.

Одной из самых популярных “страшилок-говнилок” в отношении NetApp является пугалка о том, как неэффективно расходуется пространство на системах хранения NetApp, как мало получается usable space из данного объема raw. Пожалуй, по популярности эта “говнилка” у наших конкуретнов идет сразу за страшилкой о фрагментации (и ее мифическим “катастрофическим влиянием на производительность”), и за пугалкой про “эмуляцию LUN поверх файловой системы”. Я уже писал ранее про то, как обстоит дело с первой, и рассказывал как устроена организация данных на “низком уровне” в WAFL, объясняющая ситуацию со со второй.

Пришла пора разобрать где правда в третьей.
??так, правда ли, что usable space на NetApp получается значительно меньше на том же объеме raw, например при сравнении с “более традиционными” системами?

Давайте разберем пример, хоть и не исчерпывающий, но довольно зрелищный.

Continue reading ‘О расчете дискового пространства: NetApp FAS и EMC NS – что стоит за FUD (часть 1)’ »