about NetApp

Я тут уже несколько раз останавливался на новых продуктах 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 (лат.) – “Покупатель – остерегись!”, приписка традиционно делаемая при изложении чувствительной для покупателя информации, особенно в области технических характеристик или условий покупки.

Продолжаю свои изыскания в теме технологий EMC. На этот  раз я заинтересовался механизмом, лежащим в основе всех новых фишечек EMC CLARiiON/VNX – так называемым Storage Pool. Самым интересным и понятным для меня объяснением оказалась статья блоггера virtualeverything (он не сотрудник EMC, а, как я понял, работает в партнере-интеграторе, и имеет довольно широкое поле зрения, в котором и продукты EMC, и NetApp, и, например, Hitachi). Незначительно сокращенный перевод этой его заметки я предлагаю вашему вниманию.

Глубокое погружение в тему EMC Storage Pool.

Posted by veverything on March 5, 2011

Использование Storage Pools это довольно частая тема для дискуссии с моими коллегами и пользователями. Многая информация о устройстве и механизмах работы не слишком распространена или известна, поэтому я решил провести мое собственное исследование на этот счет, и поделиться его результатами.

Некоторое время назад EMC представила в своей линейке систем хранения CLARiiON новый принцип так называемого Virtual Provisioning и Storage Pools. Основная идея заключалась в упрощении администрирования системы хранения. Традиционный метод управления хранилищем это взять дисковый массив, наполненный дисками, создать из них дискретные группы RAID, и затем нарезать из этих групп LUNы, которые, затем, предоставляются хостам. Дисковый массив, в зависимости от своего размера, при этом может содержать до нескольких сотен таких групп, и часто превращается в архипелаг разрозненных "островков хранения" на этих RAID-группах. Это может вызывать серьезные затруднения при планировании пространства хранилища, чтобы устранить проблему нерационально потраченного при таком разбиении места, так как у большинства пользователей их потребности к хранилищу, и планы как разбить под задачи, меняются со временем, и, обычно, еще не ясны до конца в "день 1". Нужны были средства гибкого и простого администрирования, и родилась идея Storage Pools.

Storage pools, как следует из его имени, позволяет администраторам создавать "общий массив" (pool) хранения. В ряде случаев вы даже можете создать один большой, общий пул, куда входят все диски системы хранения, что значительно упрощает процессы администрирования. Больше нет отдельных пространств, не нужно углубляться в "тонкие материи" устройства и организации RAID group, схем разбиения, и так далее. Кроме того, появилась также технология FAST VP, которая позволяет перемещать блоки данных в соответствии с их активностью, по уровням хранения, например на более емкие и дешевые, или более быстрые и дорогие диски. Просто выделите и назначьте пространство из такого "пула" вашей задаче, динамически, гибко, и при этом еще и позволяя использовать auto tiering. Звучит здорово так? По крайней мере так утверждает маркетинг. Давайте разберемся с тем, как это работает "физически", и нет ли не вполне очевидных "подводных камней".

Continue reading ‘EMC Storage Pools – как это работает “под крышкой”.’ »

Как заповедали старшие – изучаю вооружение потенциального противника :)

Нашел тут EMC CLARiiON Best Practices for Performance and Availability (FLARE 30, 01.03.2011) и сижу, читаю.

Особо примечательные места выделяю. Ничего, что я сегодня без перевода? По-моему, в выделенном все достаточно понятно.

Уделяю особое внимание storage pool-ам и LUN-ам в них, так как только в pool-ах возможны новые фишечки, такие как FAST и thin provisioning.

Continue reading ‘Учу матчасть :)’ »

Несмотря на то, что EMC наотрез отказывается публиковать результаты производительности систем с FASTcache и FAST VP, храня по этому поводу многозначительное и загадочное молчание, невозможно запретить частным лицам анализировать и делиться своими результатами приобретенных ими систем.

Недавно в интернете удалось раскопать вот такие результаты.

Некто проследил и опубликовал результаты real world-работы системы NS480 (CX4-480), объемом 480 SAS, SATA и EFD дисков, на 28TB block и 100TB NAS data, оснащенной как FAST VP, так и FASTcache (4 диска EFD по 100GB, общей usable capacity в FASTcache – 183GB).

Пожалуйста, примите во внимание, что это Real World data, то есть реальная производительность системы, используемой под реальную пользовательскую работу (в рассмотренном случае – ERP, VMware, SQL server databases, CIFS shares), а не какие-то специальные тестовые условия. В этом и сила и слабость приведенных результатов. Сила в том, что это реальные, практические данные. Слабость – в том, что, вполне вероятно, мы не видим всех возможностей FAST/FASTcache.

Тем не менее “чем богаты – тем и рады”. Пока EMC хранит загадочное молчание, приходится перебиваться тем, что подарят сердобольные пользователи. Подробно о системе и полученных результатах – по ссылке выше.

Напомню, что, в отличие от EMC, NetApp результаты своих систем с Flash Cache не только не таит, а наоборот, активно пропагандирует и публикует, потому что, по справедливости, там есть чем гордиться.

UPD: В комментариях к посту также нашлось упоминание еще одних результатов.

http://sudrsn.wordpress.com/2011/03/19/storage-efficiency-with-awesome-fast-cache/
http://sudrsn.wordpress.com/2011/04/16/emc-fast-cache-increase-performance-while-reducing-disk-drive-count/

Правда там человек темнит о конфигурации.

Как мне тут не раз уже попеняли, некорректно сравнивать tiering-as-datamoving и tiering-as-caching, то есть, например, NetApp Flash Cache и EMC FAST VP. Допустим, как я ни старался в соответствующей статье, я вас не убедил, что обе эти формы повышения эффективности системы хранения для пользователя есть суть одно.

Хорошо, давайте рассмотрим отдельно особенности, достоинства и недостатки только Flash Cache (PAM-II) и FASTcache.

Во первых, конечно, вы бы могли вместе со мной поехдничать о извилистом пути достижения цели у EMC. Сперва превратить flash-память в "диски" в форме SSD, а затем из этих дисков эмулировать "память" кэша. Ну ладно, допустим не смогли напрямую, оказалось проще через "двойную эмуляцию".

Во-вторых если мы посмотрим на то, как у EMC предполагается использовать SSD диски под FASTcache, вы, уверен, вместе со мной поразитесь неффективности.

Допустим, мы разворачиваем систему хранения для 1000 рабочих мест под десктопную виртуализацию на XenDesktop. Рекомендуемая схема включает в себя три диска SSD, из которых один - hotspare, а два других образуют "зеркало" RAID-1. Таким образом, очевидно, что эффективность использования flash в такой конструкции будет примерно 33%, то есть одна треть от купленной емкости flash. Да, при увеличении объема FASTcache, кроме роста цены будет расти и эффективность использования, но она никогда не превысит 50%, за счет использования RAID-1 (плюс hotspare). Больше половины затраченных на SSD денег будут простаивать. По контрасту, если вы покупаете 256GB Flash Cache, вы можете использовать под кэширование и ускорение работы с данными все 256GB, сто процентов от затраченных на них денег.

В третьих, стоит обратит внимание, что использование SSD как дисков вынуждает EMC разместить этот кэш "снаружи" контроллера, в "петле" дискового ввода-вывода на интерфейсе SAS. В то время, как у NetApp плата Flash Cache располагается непосредственно на системной шине контроллера, на PCIe (PCIe v2.0 x8 в моделях 3200/6200, пропускная способность 32Gbit/s в каждом направлении). То есть взаимодействие контроллера с кэшем в случае FASTcache такое: данные пришли через ввод-вывод на контроллер, по каналу SAS к дискам, вышли через другой порт и записались на SSD по интерфейсу SAS. Затем, если к данным кэша обращение, они должны считаться через дисковый канал ввода-вывода по SAS обратно в контроллер, и отдаться через третий канал ввода-вывода, собственно инициатору запроса, по FC или iSCSI, или NFS/CIFS. Все это, безусловно, нагружает и так не бесконечные возможности дискового канала ввода-вывода к полкам, и, потенциально, может привести к ограничению производительности.

Наконец, стоит помнить, что, хотя в FASTcache удалось значительно снизить размер оперируемого "чанка" до 64KB, против гигабайта в FAST-"просто", все же этот размер достаточно велик для многих задач, работающих в random read/write, размер блока кэша, значительно превышающий рабочий для соответствующей файловой системы или задачи, например блока базы данных, также снижает эффективность использования такого кэша, если, допустим, только 4KB из блока в 64KB нам действительно нужны (при 100% random это довольно обычная ситуация), то это значит, что эффективность кэша составляет лишь 1/16 от своего фактического объема.

Что же в плюсах? Очевидно, что это активно "педалируемая" EMC возможность работы такого кэша на запись. Особенно на это нажимают в сравнении с NetApp Flash Cache, который на запись не работает, и эта возможность действительно производит впечатление на тех людей, которые не особенно разбираются как там у NetApp все устроено, и знают только то, что "что-то иметь это гораздо лучше чем не иметь", и уж все знают, что запись надо кэшировать, без кэширования запись на диски очень медленная, это знает даже начинающий пользователь, впервые покупающий кэш-контроллер в сервер.

Чем прежде всего занимается кэш на запись?
Давайте рассмотрим на примере.

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

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

Если у нас есть жесткий диск, и мы не используем кэширование, то три клиента, пишущих на этот диск, будут вынуждены выстроиться в очередь. Сперва диск спозиционирует головки и дождется подхода нужного сектора для записи блока данных клиента A, а пославшие на запись свой блок клиенты B и C будут вынуждены ждать, затем головки будут переставлены в новое место, диск дождется, когда мимо головок проедет блок, который требуется перезаписать клиенту B, и перезапишет его, а если за это время у клиента A появился еще один блок на запись, то он поставится в очередь следом за блоком клиента C, и будет ожидать, пока выполнятся все операции перед ним.

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

Ради создания хотя бы иллюзии одновременности и организуется кэш на запись. Приложения записывают свои данные в кэш записи, получают сразу же ответ "готово" и идут сочинять новые блоки на запись, не дожидаясь того, что данные физически поместятся на диск.

Кэш же внутри себя удерживает блок, ожидая подходящего момента на запись, а также оптимизирует записи, с тем, чтобы уменьшить "пробег" магнитных головок по диску, и возможно оптимальным образом перекомпонует записи так, чтобы уложить их максимально эффективным, с точки зрения head seek-а, способом.

Принципиальное отличие WAFL тут состоит в том, что WAFL не перезаписывает блоки уже записанные на диске, и значит при записи клиенты гораздо меньше ожидают seek-а. Вы помните, что в WAFL записи можно провести "чохом", в выделенный сегмент, а не переписывать по одному блоку, мечась по всему диску, здесь и там, ожидая, когда подъедет под головку тот или иной блок. Поэтому даже без традиционного кэширования записи на WAFL клиентские записи быстро оказываются на дисках.

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

WAFL оптимизирован именно на минимальное время от момента прихода данных "на остановку" и до входа их "в автобус" жесткого диска, превращая записи в записи последовательного порядка (sequental) из поступающих записей в произвольном порядке (random).

Результат хорошо иллюстрируется экспериментом, в котором один aggregate, состоящий из трех дисков SATA 1TB 7200rpm, в RAID-DP (2p+1d), то есть, фактически, из одного действующего диска, показывает при random write блоком 4KB не типичные для SATA 70-80 IOPS, а более 4600!

Объяснение этому простое - записи, поступающие на диск теряют свою "рандомность", и "секвентализируются". Около четырех с половиной тысяч IOPS random-записи на один диск SATA - это как раз то, отчего в системах NetApp нет свойственной для "классических систем" острой необходимости в кэше записи на уровне контроллера.

Таким образом запись действительно надо кэшировать для "классических" систем, да, безусловно, это так. Но это совсем не так безусловно для "неклассических" дисковых структур, используемых, например, в NetApp.

Вот почему NetApp Flash Cache не используется на запись данных, работая всем своим объемом только на чтение. Вот почему необходимость кэширования записи для WAFL не столь безоговорочна, как для "классических" дисковых структур.

Потому, что в WAFL необходимость обязательного кэширования данных при записи существенно ниже, чем для "традиционных" систем.

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

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

Несколько постов назад, в комментах, разгорелась нешуточная дискуссия о том, можно ли считать Flash Cache “истинно православным” средство tiering-а, и ставить его в ряд с множеством других аналогичных средств, например с EMC FAST.
Для разъяснения моей позиции на этот счет я и написал этот пост.

Для начала давайте определим что такое tiering вообще.

Tiering-ом (увы, русскоязычного термина пока не прижилось, будем использовать такое) принято называть механизм перемещения данных между “уровнями” (tiers) хранения, характеризующимися теми или иными свойствами, например ценой, быстродействием, защищенностью, и так далее. Обычно tiering-ом принято называть механизмы, для перемещения данных между дисками разных типов, или дисками и магнитными лентами, или же ROM-хранилищем, часто он используется для организации ILM – Information Lifecycling Management – хранилища данных в соответствии с их статусом и уровнями QoS.

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

Что есть tiering с точки зрения приложения или пользователя? Зачем мы его применяем?

Целью tiering-а для пользователя является возможность повысить эффективность (в первую очередь экономическую) использования его системы хранения. Когда “цена значения не имеет”, то все просто – надо купить Symmetrix. Однако в реальной жизни цена очень даже имеет значение, и пользователь вынужден идти на компромиссы между ценой решения и необходимой пользователю производительностью.

Используемые в системах хранения диски сегодня имеют различную производительность, емкость и цену, причем производительность и емкость обычно величины обратно пропорциональные: больше емкость – меньше производительность (SATA), меньше емкость – выше производительность  (SAS), еще выше производительность и цена, и меньше емкость – Flash. Система хранения-же целом характеризуется соотношением IOPS/$, то есть количества единиц производительности с “вложенного доллара”.  Повысить этот параметр стремится любой вендор и любой покупатель системы хранения.

Согласно широкоизвестному Закону Парето (“20 процентов сотрудников делает 80 процентов всей работы”) сравнительно небольшая часть данных ответственна за значительную долю быстродействия системы. Напротив, значительная часть данных относится к так называемым “холодным”данным, скорость доступа к которым в принципе не критична.
Было бы неплохо, если бы эти 20% активных данных, скорость доступа к которым напрямую влияет на общую производительность, располагались на максимально быстром разделе хранилища, пусть он дорогой, но его емкость будет всего 20% от емкости хранилища, зато прирост мы получим во все 80%!

Именно эта идея лежала в основе идеи tiering-а. Если этот тип данных – активный, то автоматически перенесем его на более дорогие и быстродействующие диски, и повысим производительность доступа к ним, а менее активные данные – перенесем на менее производительные дешевый тип дисков. И настанет счастье, в виде повысившегося соотношения IOPS/$.

К такому, “классическому” типу tiering-а относится продукт EMC FAST – (Fully-Automated Storage Tiering). Он позволяет прозрачно для пользователя переносить фрагменты его данных между “уровнями” хранилища, например между разделами на дисках SAS и SATA.

Увы, дьявол кроется в деталях, и “всегда читайте написанное мелким шрифтом”. Первая версия FAST была весьма сырой, например, позволяла переносить только LUN-ы целиком, что, очевидно, неприемлемый на практике уровень “гранулярности” данных. Только в FASTv2 появилась возможность суб-LUN-овой миграции, впрочем, по-прежнему, мигрируемый минимальный фрагмент данных весьма велик (1GB!), да и еще окружен множеством ограничений использования (не поддерживается компрессия для данных, которые подлежат миграции, например).

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

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

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

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

Во-вторых, в область дорогого, но высокопроизводительного хранения – “кэша” – попадают “по определению” только “горячие” данные. Место в кэше всегда занимают только данные, к которым сейчас идет активное обращение. Все 100% дорогостоящего объема кэша используются для повышения производительности системы, а не просто “хранения”. Следствием этого является более высокая эффективность работы кэша. Процессор Intel Xeon имеет всего 8Mb кэша, что не мешает ему работать с в тысячи раз большими объемами ОЗУ на сервере, и, за счет этого, сравнительно небольшого, по относительной величине, кэша, эффективно ускорять доступ к размещенным в обширной памяти данным.

В третьих – процесс ускорения доступа и улучшения результата IOPS/$ путем кэширования есть, с алгоритмической точки зрения, процесс тривиальный. А раз так, он имеет минимум побочных эффектов и ограничений использования, а работать (и давать результат в виде повышения производительности) начинает сразу же, а не когда накопится статистика использования и, наконец, в соответствии с ней произойдет миграция данных с одних дисков на другие.

Минусы? Ну как же в нашей жизни и без минусов. Эффективность кэша, действительно высокая при чтении, сильно падает на операциях записи. Ведь если мы изменяем данные в их копиях в кэше, нам надо регулярно и своевременно обновлять их непосредственно по месту их размещения (этот процесс имеет название “сброса содержимого кэша” или “flush”). Значит, если мы изменяем содержимое блока, нам надо это изменение распознать и переписать его содержимое в основном хранилище, чтобы, когда блок будет вытеснен по неактивности из кэша, его новое, измененное содержимое не потерялось. Кэширование записи, хоть и ускоряет собственно процесс записи, сильно усложняет ситуацию алгоритмически, и, как следствие, может вести к значительному снижению эффективности работы.

Таким образом, взглянув на задачу “со стороны пользователя”, мы видим два эквивалентных по результатам решения. Оба решают задачу в нужном пользователю русле, а именно, распределяют данные по “уровням” хранения с различной ценой и производительностью, в зависимости от их активности, улучшая, в результате, экономическую эффективность хранилища, повышая производительность и снижая затраты, то есть улучшая уже названный выше ключевой экономический  параметр хранилища – IOPS/$.

Да, действительно, “метод кэширования” имеет в основе другой механизм, чем “метод переноса”, но если результат для пользователя – тот же самый: изменение характеристик доступа к данным, ведущее к улучшению параметра IOPS/$ и эффективности хранилища, то “неважно, какого цвета кошка, если она хорошо ловит мышей”. Будет ли это tiering как перенос данных между двумя типами дисков, или в виде переноса между диском и кэшем, для пользователя и его задач это, по большому счету, безразлично, если это дает эквивалентный прирост эффективности.

Вот почему я считаю, что как EMC FAST, так и EMC FASTcache и NetApp FlashCache, все они являются формами организации tiering-а, и их можно рассматривать вместе, как формы одного решения.

Сегодня еще один пост 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-а это прикольно, если прикол есть ваша конечная цель.