about NetApp

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

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

В сегодняшнем переводе у нас будет еще один активный блоггер NetApp, Larry Freeman, пишущий с ником Dr.Dedupe. Его основная тема в блоге – технология дедупликации в системах хранения NetApp, а поводом для переведенного поста – “Неспровоцированная агрессия” в отношении NetApp со стороны HP, которая выпустила в свет документ, под названием “Understanding the Challenges Associated with NetApp’s Deduplication” – “Разбор проблем, связанных с технологией дедупликацией NetApp”.

Ну что-ж, ответом на неспровоцированную агрессию будет наше принуждение к миру. ;)

HP Launches an Unprovoked Attack on NetApp Deduplication

By Larry Freeman AKA Dr.Dedupe

На днях я наткнулся на приведенный ссылкой выше документ, опубликованный HP, и озаглавленный “Разбор проблем, связанных с технологией дедупликации NetApp”. Я хочу поблагодарить HP за их попытку указать нам на наши проблемы, и постараюсь ответить взаимностью позже в моем блоге.

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

Утверждение HP:

“Первичные данные (здесь и далее я буду переводить слово primary как “первичные”, этим словом принято называть основные, активные, “боевые” данные приложений, в противоположность данным резервных копий и архивов, например. Прим. romx) имеют случайный характер  доступа по своей природе. Дедупликация приводит к тому, что различные блоки данных записываются в различные места диска. NetApp WAFL усугубляет проблему, записывая данные в свободные места, ближайшие к головке записи дисков. Чтение данных вызывает пересборку этих блоков, в формат пригодный для чтения приложением. Оверхед, вызываемый этой пересборкой данных, оказывает влияние на производительность, обычно на 20-50%”

Ответ Dr.Dedupe:

NetApp WAFL (Write Anywhere File Layout) – это структура размещения произвольно расположенных данных на диске, оптимизированная на производительность доступа к ним. Дедупликация еще более “рандомизирует” эту структуру, переназначая указатели на блоки данных и удаляя дубликаты. После дедупликации производительность на чтении иногда слегка возрастает, иногда слегка падает, однако подавляющее большинство пользователей говорят, что не заметили никакой разницы вообще. Важным моментом является то, что мы не перемещаем данные как таковые, просто переставляем на их блоки указатели. Если вы хотите получше разобраться в том, как работает наша технология, то я рекомендую посмотреть пример работы дедупликации.

Утверждение HP:

“Когда клиенты NetApp испытывают проблемы с производительностью, первая рекомендация NetApp это не использовать дедупликацию”

Ответ Dr.Dedupe:

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

Утверждение HP:

“Снижение темпов роста емкостей хранения имеет большое значение, и экономит затраты пользователя. Однако для первичных данных другие технологии, например Thin Provisioning обеспечивают сходные результаты уменьшения объемов, но без сопутствующего снижения производительности; эти возможности имеются у HP P4000 и HP InServ.”

Ответ Dr.Dedupe:

Заметьте, HP не сказала “эти возможности имеются только у HP P4000 и HP InServ.” Потому что у систем NetApp тоже есть Thin Provisioning, а также много других технологий уменьшения занимаемых объемов хранения и повышения их эффективности, которые могут использоваться как по по отдельности, так и друг с другом, одновременно:

• Дедупликация
• Thin Provisioning
• Эффективно расходующие место снэпшоты
• Виртуальные клоны данных
• Thin-репликация
• RAID-DP
• Онлайн-компрессия данных
• Автоматический виртуальный tiering c дисками SATA

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

Утверждение HP:

“Метод с фиксированными участками [используемый NetApp] означает, что изменения в данных могут привести к очень плохому результату дедупликации… ??спользование метода с переменной длиной участка позволяет HP StorOnce D2D обеспечить более интеллектуальный и эффективный подход к дедупликации.”

Ответ Dr.Dedupe:

Ох, черт. Неужели мне так и придется писать это, снова и снова? NetApp записывает все данные в блоки (ну, то есть “участки”), размером 4KB. За прошедшие 20 лет мы сделали довольно неплохую работу по оптимизации того, насколько быстро мы можем писать и читать эти “участки”. Наиболее простой и быстрый способ дедупликации в нашем случае, это получать “цифровой отпечаток пальца” каждого такого участка, и сканировать базу этих “отпечатков” на дубликаты. Это лучший вариант для одновременного использования дедупликации в обоих сферах применения, как для первичных данных, так и для резервных копий. Достаточная экономия пространства хранения и минимальное влияние на производительность. В HP читают хоть что-нибудь в моем блоге? Переменные участки это хорошо для экономии места, но совсем не так здорово для производительности. Кто более интеллектуален и эффективен? Судите сами.

Утверждение HP:

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

Ответ Dr.Dedupe:

Ну, HP, вот тут вы меня по настоящему разозлили. Прежде всего вы привели цитату из слов Криса Каммингса, сказанную еще в августе 2008 года, я уверен, что если бы вы могли вернуться назад во времени, вы бы могли найти консервативный комментарий о любой новой технологии от того, кто заботится о клиенте. Но фактом является то, что сегодня для нас это уже не новая технология, и мы рекомендуем ее использование нашим клиентам без каких-либо опасений.
Насчет того, что дедупликация на устройстве хранения резервных копий не влияет на производительность первичного хранилища – дык! :)

Утверждение HP:

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

Ответ Dr.Dedupe:

Вместо того, чтобы писать труд о проблемах технологии другого производителя, лучше бы HP исследовала проблемы, с которыми сталкиваются пользователи сегодня – а именно о том, что они борются с постоянным ростом объемов данных в условиях сокращающегося IT-бюджета. Может тогда бы стало понятно лицемерие сравнения с оркестром. Когда HP хочет продать пользователям оркестр в 120 человек, NetApp продает компактный, но эффективный джаз-бенд.

Утверждение HP:

“NetApp не обеспечивает достаточной гибкости для сложных сред резервного копирования сегодняшнего дня”

Ответ Dr.Dedupe:

Погодите минутку, что произошло? Кажется я что-то пропустил? Я думал, что мы говорим о проблемах дедупликации у NetApp, как это мы вдруг перескочили на гибкость резервного копирования? Это что, такой способ сбить читателя перепрыгивая с темы на тему?

Утверждение HP:

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

Ответ Dr.Dedupe:

Снэпшоты? А теперь мы говорим про снэпшоты? ??звините меня, HP, не могли бы вы все же не скакать с темы на тему? “Разбор проблем, связанных с технологией дедупликацией NetApp”, вы помните? Ну, с другой стороны, я так понял, что просто “проблемы” у нас закончились…

Dr.Dedupe (http://blogs.netapp.com/drdedupe)

А сегодня у меня в блоге наверное самый активный и интересный нетапповский блоггер, директор и евангелист направления виртуализации и cloud computing – Vaughan Stewart.

Напоминаю, что по средам я публикую переводы недавних интересных постов блоггеров самого NetApp, с их собственной блогохостинговой площадки blogs.netapp.com, кто свободно читает по-английски – рекомендую подписываться на тамошних авторов.

5 Reasons to Upgrade to Data Ontap 8.0.1

Vaughan Stewart - Director & Evangelist, Virtualization & Cloud Computing

На прошлой неделе, проводя наш Virtualization Field Readiness Summit, я много говорил с Dr.Desktop (Chris Gebhardt), который показал мне множество преимуществ наших технологий в области виртуализации десктопов, а также тем, какие преимущества несет с собой новая Data ONTAP 8.0.1, и я решил поделиться этим с вами.

Причина номер 1 – 64-битные aggregates

64-битные aggregate, или “пулы хранения”, позволяют увеличивать размеры aggregates, так как поднимают верхний лимит с 16TB в Data ONTAP 7.x.x до 100TB (в зависимости от типа и мощности контроллера). Для тех, кто еще не знаком с технологиями NetApp, aggregate это набор физических дисков, собранных в RAID-группы

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

При использовании 64-bit aggregate и RAID-DP, наш пользователи могут увеличить размер своих разделов данных, не поступаясь при этом степенью их защиты.

Причина номер 2 – NetApp DataMotion for FC, FCoE, & iSCSI LUN

NetApp DataMotion for LUNs это одна из наших технологий для организации многоуровневого хранения, с помощью которой мы можем, не прерывая доступа к данным на LUN-е, перемещать его (и соответствующий ему FlexVol) с одного aggregate на другой, на том же контроллере. DataMotion выполняет миграцию LUN-ов, вместе со всеми сопутствующими им атрибутами,такими как снэпшоты, состояние thin provisioning, состояние дедупликации и отношений между датасетами (например источник или получатель репликации, “зеркальность” для другого тома, и так далее), причем, как сказано выше, “на ходу”, не прерывая ввод-вывод данных с этих LUN-ов.

Причина номер 3 – 10GbE & FCoE Unified Target Adapter

Data ONTAP 8.0.1 обеспечивает поддержку (в форме драйверов устройств) для нашего Unified Connect Target Adapter (UTA). UTA более известен как Converged Network Adapter (CNA). Наши клиенты с UTA могут использовать его для всего их рабочего трафика, как SAN (FCoE, iSCSI), так и NAS (NFS, CIFS), одновременно, по одному проводу, с использованием Data Center Ethernet (DCE), известного как “10Gb Ethernet”, через одну карту PCI-E.

UTA кроме этого позволяет пользователям потенциально увеличить емкость хранения данных, так как позволяет высвободить слоты PCI-E, занятые под карты портов SAN и Ethernet, и установить в них порты для подключения дополнительных дисковых полок. Слоты PCI-E тут важны, так как, например, такая наша система среднего уровня, как FAS3270, может адресовать до 1,9PB хранения.

Причина номер 4 – Онлайн-компрессия на файловой системе

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

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

Причина номер 5 – поддержка VMware VAAI

Data ONTAP 8.0.1 обеспечивает поддержку VMware Storage APIs for Array Integration (VAAI), новой возможности появившейся в vSphere 4.1. Это такие возможности, как: Full Copy, Block Zeroing и Hardware-assisted Locking, расширяющие возможности масштабирования виртуальной инфраструктуры, путем переноса части операций по вводу-выводу на аппаратуру системы хранения. В настоящий момент поддерживаются только хранилища VMFS, но, верьте мне, в ближайшем будущем тут будет еще много интересного.

Ну ОК, я немного промахнулся, когда счел, что числа “пять” для причин будет достаточно. Есть еще кое-что, пусть это будет бонусом.

Бонус – Повышенная производительность!

В релизе 8.0.1 мы повысили быстродействие логики дедупликации в кэше массива, что дало нам прирост в различных тестах от 10% до 48% увеличения производительности.

Я хочу процитировать своего коллегу, Dr.Desktop, на стенде которого был проведен эксперимент с одновременной загрузкой 5000 виртуальных десктопов (VDI, VMware View) под Windows 7, что заняло 50 минут на всего 24 дисках SAS. Этот результат на 28% улучшил предыдущий результат, полученный с использованием на контроллерах Data ONTAP 7.3.4.

В комментариях указали еще один немаловажный плюс, который я счел необходимым внести в переводе (прим.romx)

Бонус 2 – лимит тома с дедупликацией теперь поднят до 16 TB для всех платформ!

Если раньше, на Data ONTAP семейства 7.х.х, емкость тома, на котором можно было включить дедупликацию, была ограничена различными величинами, в зависимости от типа контроллера, например для FAS2020 можно было включить дедупликацию только на томе, физическим размером не более 1TB, а для 2040 – 3TB, то на 8.0.1 эти лимиты на всех системах, поддерживающих 8.0.1, включая и 2040, лимиты емкости для тома с возможностью дедупликации подняты до 16TB.

Закругляясь.

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

С тех пор как нам удалось обеспечить непрерывающий (non-disruptive) работу системы хранения апгрейд с Data ONTAP 7.x на 8.0.1, апгрейд на новую версию не может быть проще!

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

Сегодня – пост Кейта Аасена, инженера службы поддержки пользователей в NetApp, где он рассказывает об основных ошибках пользователей при конфигурировании дедупликации на системах хранения NetApp.

The 4 Most Common Misconfigurations with NetApp Deduplication

Posted by Keith Aasen - CSE Virtualization

Работая сервисным инженером мне приходится встречаться с пользователями из самых разных отраслей. Когда я рассказываю пользователям про наши типичные показатели экономии пространства при дедупликации данных на “боевых” системах VMware, которые составляют 60-70% изначального объема, я часто встречаюсь со скептическим отношением: “Ну, мол, это у них, у нас-то данные особенные”, часто отвечают мне, “Поверю, только когда сам увижу”. Мы демонстрируем результат, и мне нравится слышать в ответ: “О, это совсем не то, что про вас рассказывали нам ваши конкуренты!”

Совсем недавно один из наших клиентов перенес более 600 виртуальных машин, занимавших на его действующей системе хранения 11,9TB, на новый дисковый массив NetApp, причем это были 600 виртуальных машин разного содержимого, с различными OS, с различными в них приложениями и их конфигурациями, и после дедупликации это заняло всего 3,2TB – 73% экономии!

Но иногда встречаются пользователи, которые звонят с вопросами: “Эй, а у нас тут дедупликация дала всего 5%, в чем дело?” Такие невысокие показатели дедупликации, по моему опыту, являются следствием какой-нибудь из перечисленных ниже типичных ошибок.

Ошибка №1 – Неправильно изначально включенная дедупликация (или забытая опция –s для scan)

Как уже указывал в своем блоге Dr.Dedupe, NetApp рекомендует использовать дедупликацию для всех данных VMware. Вы можете заметить, что если вы используете наш продукт Virtual Storage Console (VSC), плагин к vCenter, то созданные в нем датасторы VMware автоматически идут с включенной опцией дедупликации для них. Мы советуем оставлять включенной эту опцию, и вот почему.

Когда для тома включена дедупликация (ASIS), то контроллер отслеживает все записываемые на этот том блоки данных. Когда наступает время запуска процесса дедупликации, то контроллер просматривает все отслеженные ранее блоки, и устраняет дубликаты среди них. Но только среди тех, которые он перед этим уже отследил при записи! Что же делать, если у вас уже на диске было несколько виртуальных машин, для которых опция дедупликации не была включена изначально при их создании? Если вы не указали контроллеру NetApp специально просканировать блоки уже лежащих на его дисках данных, то эти виртуальные машины и их данные не будут обработаны дедупликацией! Это приведет к снижению результатов, показываемых дедупликацией. Но хорошая новость состоит в том, что это легко поправить. Запустите дедупликацию с опцией scan в VSC, или же вручную, из консоли управления укажите у команды sis ключ –s.

Выше – рассматриваемое действие в VSC, ниже – в System Manager, другом нашем инструменте управления контроллером системы хранения.

Для предпочитающих командную строку это будет sis start -s /vol/myvol, удивительно как много могут сделать всего два дополнительных символа.

Это, по моим наблюдениям, самая популярная ошибка, но благодаря все большему количеству наших пользователей, которые создают разделы для VMware с помощью VSC, она становится все менее распространенной.

Ошибка №2 – Включенное резервирование пространства под LUN

На контроллере NetApp у нас есть несколько различных уровней включения резервирования пространства, в зависимости от ваших потребностей. Но для VMware используются главным образом два. Первый – это резервирование на уровне тома (volume reservation). Оно резервирует пространство в объеме пула aggregate, и обеспечивает вам уверенность в том, что объект, который вы помещаете на том, на него поместится, и для него найдется достаточно места. Внутри такого тома вы можете создавать LUN-ы для VMware. Тут вы тоже можете выбрать вариант резервирования пространства под LUN, которое займет сразу все необходимое пространство на томе под создаваемый LUN. ?? с этим есть две проблемы. Первая – что вам так делать, на самом деле, не нужно. Вы уже зарезервировали место на уровне тома на aggregate, с помощью volume space reservation, вам не нужно резервировать его еще раз, с помощью LUN space reservation. Вторая – LUN reservation означает, что LUN всегда будет занимать зарезервированное пространство. То есть LUN , созданный с заданным размером 600GB, всегда займет на дисках эти 600GB, даже если он пустой, даже если на нем успешно поработала дедупликация.

Простое отключение резервирование пространства для LUN даст вам эффект от дедупликации данных на нем (да, кстати вы можете сделать это прямо на ходу, не останавливая VM, использующую этот LUN).

Ошибка №3 – Неверно выравненная VM

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

Кроме снижения результатов экономии при дедупликации и большего занятого на дисках объема, неверное выравнивание партиции оказывает довольно значительную дополнительную нагрузку на контроллер системы хранения (любой системы хранения, не только NetApp). Поэтому было бы очень неплохо исправить эту ситуацию. На рынке существует множество программных инструментов для выполнения этого действия, включая утилиту MBRalign, которую получают клиенты NetApp в составе нашего пакета VSC (Virtual Storage Console). Когда вы поправите неправильное выравнивание ваших VM, вы увидите не только улучшение показателей экономии пространства в результате дедупликации, но и снижение уровня загрузки процессоров на контроллерах системы хранения.

Ошибка №4 – Большой объем данных в VM

Это, правда, не ошибка конфигурации, а, скорее, особенность дизайна системы. Большинство наших пользователей не отделяют данные VM от системного VMDK с OS. Возможность держать все содержимое VM в одной директории выглядит слишком заманчиво, чтобы ей пренебречь. Пользователь обычно все равно получает довольно неплохие результаты дедупликации, даже если данные приложения смешаны с блоками данных самой OS. Часто пользователи держат по настоящему большие разделы виртуальных дисков, где блоки данных OS лежат вместе с большими базами данных, репозиториями образов, или базами электронной почты, все внутри одного диска VM. Такие большие разделы смешанных данных скорее всего не будут дедуплицироваться с высокими показателями экономии. В общем-то нет ничего страшного в такой схеме, но если вы переместите VMDK с такими данными на отдельные разделы с аналогичными данными, то показатели дедупликации для таких VMDK, и для VMDK с файлами OS, хранящимися по отдельности друг от друга, будут заметно выше. Но, в принципе, оба варианта вполне рабочие.

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