Снова про EMC VNX

Так как я теперь, стихийным образом (вернее будет сказать попустительством 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:

fastoracle[1]

Стрелки добавил я. Отметьте, что наибольшее преимущество в производительности достигается тогда, когда кэш правильно сконфигурирован с точки зрения сайзинга. Дополнительные 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:

vnxthin[1]

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

  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

11 комментариев

  1. Konstantin:

    Добрый день.
    Кстати дополнительная полка на VNX5300 для расширения существующего VNX5300, будет стоить дороже чем новый VNX5300. Вот такая политика :( Подтверждено комерсами в ЕМС Россия.

  2. Konstantin:

    Не, ну такое-то и у нетаппа бывает (ну как, “бывает” - “есть”;)
    Просто обычно новая система покупается с большими акционными скидками, которые правильный продавец знает и умеет их использовать для проталкивания продажи, а полка уже идет по ценам листпрайса, ну может небольшая скидка, если повезет.
    В одном проекте, где я принимал участие, была забавная ситуация, там для покупки 12 дополнительных дисков и одной лицензии к уже купленной системе оказалось выгодно “затрейдинить” старую систему и купить вместо нее новую, с плюс дисками и complete bundle, чем докупать апгрейд к имеющейся.

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

  3. Neoris:

    Я бы ещё добавил в предостережения схему работы EMC VNX в файловом или Unified варианте.
    DataMover-ы или по другому X-Blad-ы, сами не отрабатывают отказ одного из файловых контроллеров, это делает Control Station, которая является сервером под RHEL, соответственно для отказоустойчивости таких CS надо две штуки(прим. в базе считается одна, вторую добавляют на этапе конфигурирования спецификации, может выйти накладка и клиент получит только одну CS)

  4. Pavel Kosachev:

    Используем обе системы EMC VNX , NetApp.
    Это опыт конкретной компании, тактика размещения виртуальных машин - полное дублирование серверов на netapp и emc.

    В защиту VNX
    1. Действительно эффективная система wide-striping (пулы) и его tiering! В netapp получили что почти закончилось место в SAS и пустует место в SATA, тоже касается нагрузки на контроллеры, как тут сможет помощь Virtual Tiering? ILM на базе приложений обойдется не пример дороже.
    2. Как заметили ранее - цены на доп. полки в netapp - тоже сопоставимы со стоимостью новой системы, для VNX пока не смотрели потому что там места еще много.
    3. Штатно сгоняли на период maitanance луны на один из контроллеров - проблем с производительностью не замечали.
    4. QoS в пулах есть , правда нужна доп. лицензия. Она есть, но вопросы QoS обычно затрагиваются при достижении пороговых значений по Bandwidth или iops.

    Это я к тому, что у всех систем есть свои особенности , как у netapp , так и у EMC.
    Например thin provisioning работает только в условиях однократной записи данных в LUN, как только включаются процессы ILM на уровне приложений, эффект от thin provisioning пропадает.

  5. Pavel Kosachev:

    1. “В netapp получили что почти закончилось место в SAS и пустует место в SATA” - NetApp DataMotion.
    2. К вопросу не относится
    3. Речь не про переключение, а про работу не со “своим” контроллером
    4. Вопрос не про наличие QoS

  6. Александр:

    NetApp DataMotion - справедливости ради стоит заметить, что нетапчик это делает между агрегатами только одного контроллера (7-mode). EMC LUN’ы двигает откуда угодно и куда угодно.
    А вообще, когда у вас пара стороджей со статичными задачами, то действительно сложно заметить степень удобства и функциональности, а вот когда стороджей уже несколько сотен, то тут уже можно сравнить и чёрт возьми нетапчик начинает “рулить”.

    Цены тут под запретом, но тем не менее у нетапа самое честное ценообразование, если можно так выразиться.

  7. Александр:

    Да нет, не под запретм, просто так как они (цены) индивидуальны, то особого смысла их обсуждать нет. Да и лично мне это не особенно инткересно, это “область деятельности” продавцов, а не продавец.

    > между агрегатами только одного контроллера (7-mode).

    Разве? в 8.1 7-mode многое поменялось, кстати.

  8. s1d:

    Добрый день.
    Подскажите, где найти новую бумагу, в которой написано про перемещение томов между агрегатами разных контроллеров, нашел только это:
    http://www.netapp.com/us/system/pdf-reader.aspx?m=ds-3122.pdf&cc=us
    Спасибо

  9. Pavel Kosachev:

    1. NetApp DataMotion. - Подходит для перемещение целиком LUN или Volume. Это плохо работает для виртуализации, когда в рамках одного луна может находиться несколько VM. Но даже если разместить LUN=VM , все равно придется делить данные приложения на активно используемую часть и неактивно используемые, что не всегда возможно и/или очень трудозатратно.

  10. Александр:

    Роман, в 8.1.2P1 7-mode ещё нельзя.. :(
    > vol move
    vol move: No subcommand supplied.
    usage:
    Move a single 7-mode flexible volume between two aggregates within a controller.

  11. zerg:

    Pavel Kosachev:

    Уже год балтаются луны в Tresspass на одном Clariion(ну считай тот же VNXBlock). Не дает SP переместить их нагрузка слишком большая. А вы говорите о том что все хорошо. Может у вас при maitanance нагрузки не было? Дык ведь VMAX тоже на это грешит.

Оставить комментарий

20/0.148

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.