about NetApp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

D

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблема?

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

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

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

??того

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

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

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

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

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

D

Выходные – день оффтопиков. Вот такая идиллическая картина получилась в пятницу. Причем там еще два шкафа IBM-овских серверов сбоку на этой кухне. Не хватает только HP и Hitachi. :)

Посты в блоге скоро возобновлю, просто в этот четверг работа не давала времени причесать уже написанный пост. В том числе и та, что на фото выше :)

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