about NetApp

Хотел бы обратить внимание тех, кто планирует использование новой возможности на системах хранения NetApp – WAFL online compression, то есть сжатия данных “на лету”, для хранения их на диске в сжатом виде. В настоящий момент блоки, которые были компрессированы таким образом, не кэшируются в Flash Cache / PAM.

Как вы знаете, у NetApp есть сейчас две основных технологии снижения storage footprint, то есть объемов хранения, занимающих физическое дисковое пространство, это давно существующая и хорошо себя зарекомендовавшая во многих случаях дедупликация, и появившаяся сравнительно недавно онлайн-компрессия. Две эти технологии существуют и работают независимо друг от друга, и даже дополняют друг друга. Каждая из них имеет свои предпочтительные области применения. Например, дедупликация хорошо работает для сред виртуализации, где ее эффективность (величина экономии после ее применения) может достигать 70-85% от первоначально занятого на дисках, но в рядя других применений, например для баз данных, ее эффективность (по разным причинам, на которых мы не будем сейчас подробно останавливаться) значительно ниже, часто не более 10-20%.

Напротив, компрессия довольно неплохо уменьшает объем хранения для пользовательских файлов и баз данных (35-50%). Она также сравнительно неплохо работает даже и на уже дедуплицированных данных, что может еще повысить результаты экономии.

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

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

Если у вас система с Flash Cache, и вы одновременно собираетесь использовать компрессию для данных – то будьте внимательны. Компрессированные тома в системе с Flash Cache могут иметь значительно отличающуюся от некомпрессированных производительность, за счет того, что с некомпрессированными томами работа будет идти через Flash Cache, а с компрессированными – нет. Эта разница, не слишком заметная для систем без Flash Cache, за счет такого поведения для систем с Flash Cache, может быть неприятным сюрпризом.

Эта особенность работы компрессии описана в новом TR-3958 Compression and Deduplication for DataONTAP 8.1 operating in 7-Mode на странице 22:

7.6 PAM AND FLASH CACHE CARDS

In environments with high amounts of shared blocks that are read repeatedly, the PAM or Flash Cache card can significantly reduce the number of disk reads, thus improving the read performance. The PAM or Flash Cache card does not increase performance of the compression engine or of reading compressed data. The amount of performance improvement with the PAM or Flash Cache card depends on the amount of shared blocks, the access rate, the active dataset size, and the data layout. The PAM or Flash Cache card has provided significant performance improvements in VMware® VDI environments. These advantages are further enhanced when combined with shared block technologies, such as NetApp deduplication or NetApp FlexClone® technology.

Так что обратите внимание на этот момент, и не применять компрессию для томов, производительность которых для вашей задачи критична, и которые вы планируете ускорить с помощью Flash Cache

UPD: Попросили уточнить. По-прежнему кэшируются во Flash Cache НЕсжатые блоки на сжатом томе (например, если эти блоки были исключены из процесса сжатия в результате плохого compression rate на этапе estimate для этих блоков). Но, так как нет механизма управлять тем, какие именно блоки или файлы будут компрессированы на томе, а какие - нет (компрессия назначается на том целиком), то это, в общем, довольно теоретическая поправка, не меняющая моей итоговой рекомендации.

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

Я пообещал разыграть, в случайном порядке, между всеми приславшими, по выбору выигравшего, gift card Apple iTunes на 25$, такую же карточку от Amazon, или же подарочную карту от OZON на 1000 рублей.

То есть от вас – вывод команды, и, возможно, карточка достанется вам. Карточка, разумеется, не физическая, а ее номер, который вы можете активировать в соответствующем интернет-магазине.

Подробнее – в том посте.

Конкурс “экономия пространства на NetApp”

Напоминаю, что результаты принимаются до 1 июня. Вы еще вполне успеете сделать свою попытку в понедельник или вторник.

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

Не так давно, споря в комментариях по поводу эффективности работы дедупликации, я предложил показывать всем желающим их результаты space savings с помощью вывода команды консоли df –s.

Мой оппонент утверждал, что величина достигаемой дедупликации “в реальных системах, а не по словам маркетологов” совсем незначительна, и значимость дедупликации данных сильно преувеличена нетаппом.
Я же возражал, что это не так, и это легко проверить, сделав вывод команды df –s и посмотрев величину в графе % savings.

Так вот, “удваиваю это предложение”!

Я принимаю от вас ваши результаты df –s, а затем, чтобы простимулировать вас в этом начинании, разыграю между всеми приславшими, случайным образом, код подарочного сертификата.

На выбор предлагается:

• Подарочный сертификат магазина OZON.ru (1000 рублей)
• Gift card Apple iTunes (25$)
• Amazon gift card (25$)

Выигравший получит на свой email любой один, по вашему выбору (ну то есть если кто-то не любит Apple, и iTunes Gift Card ему не нужна, значит можно выбрать другой вариант).

Дальше вы полученный код можете использовать как захотите, например для приобретения программ в Appstore, или книжек/музыки на Amazon или OZON.ru. На ОЗОНе рекомендую, кстати, книгу коллеги-блоггера, и автора vm4.ru – Администрирование VMware vSphere 4.1.

Ограничим эту затею ровно месяцем с момента публикации этого предложения.
Ваши ставки принимаются по e-mail: romx@mail.ru или в комментариях к этому посту.

Отдельно уточню, что это не “пузомерка”, “победа” определяется случайным образом, а не по величине достигнутой экономии пространства. Принимаются любые результаты, даже 1%, если у вас достигнут только такой.
Хотя, конечно, хотелось бы, чтобы хотя бы дедупликация у вас была включена и работала.

Вывод этой команды выглядит примерно так:

> df -s -g
Filesystem used saved %saved
/vol/vol1/ 1279GB 668GB 34%
/vol/vol2/ 1462GB 239GB 14%
/vol/vol3/ 1133GB 270GB 19%

Будет совсем хорошо, если вы вместе с результатами хотя бы в нескольких словах охарактеризуете свои данные. Например: “/vol/vol1/virt – nfs-хранилище виртуальных машин VMware, /vol/files/ – файлы домашних папок пользователей, /vol/db-luns/db1…db8 – тома для LUN-ов базы данных MS SQL2005 по FCP”

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

PS. Один участник у меня, кстати, уже есть в комментариях к тому посту.

В сегодняшнем переводе у нас будет еще один активный блоггер 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)

Как вы заметили, стандартными днями публикации в этом блоге являются понедельник и четверг. В эти дни выходят мои собственные заметки в блоге. Но недавно я решил “расширить предложение”, и по средам тут будут публиковаться наиболее интересные публикации переводов постов из англоязычных блогов, в частности из 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, хранящимися по отдельности друг от друга, будут заметно выше. Но, в принципе, оба варианта вполне рабочие.

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

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

Лучше то, что лучше работает на ваших данных и ваших задачах.

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

Вот какой рисунок приводит NetApp по поводу эффективности дедупликации и компрессии в одном из своих документов (выше – лучше):

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

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

Часто приходится отвечать на вопрос: "Насколько использование дедупликации снижает производительность системы хранения NetApp?"

Официальное мнение, подтверждаемое отчетами пользователей: "Снижение производительности либо практически не заметно, либо находится в пределах 5-7% , в зависимости от нагрузки и характера доступа к системе"

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

Простой пример. Вы используете систему хранения FAS3140, с размером кэш-памяти на контроллере в 8GB (на два контроллера - 16GB, по 8 на каждом), для хранения множества однотипных виртуальных машин.
Не секрет, что системные разделы виртуальных машин Windows, в том случае если вы, как оно обычно и бывает, используете одну и ту же версию OS и сервиспаков, отличаются между собой очень незначительно. Допустим, что 90% всего содержимого OS, установленного на раздел виртуального диска, размером 4GB, идентичны для всех 20 имеющихся у вас виртуальных машин (данные у них, разумеется, различные, но мы говорим сейчас только о системных разделах).
Легко видеть, что, в этом случае, после проведения дедупликации, на разделе, ранее занятом на 4GB*20=80GB высвободится 90%  места, и все данные поместятся в 11,6GB (4GB + (0,4GB*19)).

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

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

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

Ответ: Потому что кэш не знает ничего о содержимом блоков, он знает только о расположении его. Кэш помещает в себя "блок номер 12037", "блок номер 34560" и "блок номер 545200". Даже если они полностью идентичны внутри, каждый из трех займет место в кэше, потому что для кэша они разные, они  их видит только “по номеру”.
В случае же дедупликации "виртуальный уровень хранения", при необходимости считать их содержимое, запросит из них только один.
Ситуацию пояснят рисунки:

Кстати следующий подготовленный перевод, который можно будет найти, как всегда, на страничке технической библиотеки российского дистрибутора NetApp, компании Netwell, это большое руководство Best Practices о использовании и настройке дедупликации на системах FAS и V-series . Думаю, что вскоре вы сможете подробно прочитать обо всех аспектах применения дедупликации "от производителя"

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

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

А дело вновь в “волшебных пузырьках”, которые называются WAFL. :)

Один из блоггеров NetApp, за которым я внимательно слежу и читаю все его выпуски, уже не раз тут упомянутый Костадис Руссос, полемизируя с “блогорупором EMC” Чаком Холлисом, который использовал в одном из постов в приложении к продуктам EMC слова “Настоящий FibreChannel” (Real FibreChannel), в противовес “всяким там эмуляциям, SAN-ам из NAS-а, и прочим ‘виртуальным’ стораджам”, стал использовать термин “Лучше Чем Настоящий FibreChannel” (Better Than Real FibreChannel).

??так, чем же NetApp Лучше Чем Настоящий FibreChannel.

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

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

Это настоящий кошмар для любого “класического стораджа”, который любой ценой стремится минимизировать random-компоненту доступа, так как на нем эффективность его резко падает как на записи (особенно), так и на чтении (большое “замусоривание” кэша и отсутствие эффективного “предсказания”/”read ahead”).

Но ведь вспомните, такой режим “постоянно-рандомной записи и чтения” есть по сути “нативный” режим для WAFL! Блоки WAFL записываются и считываются произвольно и рандомно не только в случае дедуплицирования данных, но и при обычной, естественной работе, которой стораджи NetApp занимаются уже много лет!
То есть переход от “классического” к “дедуплицированному” хранилищу, и вызванная этим “фрагментация данных”, такая катастрофическая для “классического” стораджа, вполне обычна и повседневна для NetApp, и включение дедупликации на быстродействии системы хранения никак не отразится!

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

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

Вот что нам дает такая классная штука, как придуманная и написанная аж в 92 году специальная “файловая система”, вот в чем преимущества “виртуальных стораджей” над “настоящим FibreChannel”. Вот чего “настоящий FibreChannel” не может.

??так, если я вас убедил взять и попробовать использовать дедупликацию, то сделать это можно разными путями. Например таким:
Допустим лицензия на дедупликацию получена и введена.
Включить ее можно любым из доступных для управления системой хранения способов, например через командную строку. Но давайте посмотрим как это сделать с помощью нового System Manager-а, о котором я рассказывал совсем недавно. System Manager это приложение администрирования систем хранения NetApp, в виде MMC-оснастки (Microsoft Management Console) для любой Windows-системы.
Вот так включается дедупликация для тома, при его создании:

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

Страница управления томами также имеет средства запуска процесса вручную, например немедленно.

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

Ну и, наконец, если у вас используется VMware, и вы выбрали для хранения его датастора том по NFS, о преимуществах такого решения я много писал, то для такого случая есть специальный “мастер”.

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

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

Что же такое дедупликация, или, как она называлась раньше у NetApp, ASIS - Advanced Single Instance Store?

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

Однако есть другие варианты, наиболее просто демонстрируемый и широко распространенный сегодня - содержимое виртуальных машин. Если у вас есть пять виртуальных машин на базе Windows, то у вас есть, скорее всего, пять полностью идентичных инсталляций Windows, минимум на 2-3 гигабайта каждая, отличающихся на момент их создания, грубо говоря, только “именем компьютера” и IP-адресом, лежащих отдельно друг от друга на дисках, и занимающих свои 2-3 гигабайта.
Однако, так как это содержимое хранится внутри файла “виртуальных дисков”, то обычными методами мы никак не сможем устранить это дублирование. Ведь файлы этих виртуальных дисков все же не идентичны (на какие-то единицы процентов).
Аналогичный пример - базы данных. Если у нас для записи базы данных для полутора тысяч сотрудников указано “не женат/не замужем”, равно как и наоборот, или, например, в поле “город” указано “Москва”, а предусмотренное архитектурой базы BLOB-поле для хранения фотографии у 90% пустое, то это также будет дублированием.

Может быть просто обидно, хранить на дорогостоящих SAS и FC дисках многократно повторяющиеся, и по сути не нужные, не несущие информацию, избыточные блоки данных. Мы сохранили уникальный блок - все. Нужно его содержимое - берите его там, зачем копировать его по диску в сотнях и тысячах копий!
Так дело обстоит с точки зрения банальной логики.
Мы победили на файловом уровне, с помощью разных средств, рассылальщиков “башорга” по конторе, но с дублированием множества копий идентичных данных в виртуальных машинах справиться гораздо сложнее.

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

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

“Хэш-функция” это некая формула, по которой можно получить более или менее уникальный “фингерпринт”, “цифровой отпечаток пальца”, некое число, уникальное для данного сочетания байт. Сравнивать такие числа гораздо проще, чем содержимое файлов, от которых они взяты.
Простейший вариант хэш-функции, это так называемая “контрольная сумма”. У нас есть набор чисел-байт, давайте просуммируем их, и на выходе получим некое число, зависящее от значения тех, кого мы просуммировали. Проблема использования простейшей контрольной суммы очевидна.
Сумма 5+3+2 дает 10. Но и сумма 4+4+2 дает тоже 10.
Это называется “хэш-коллизия”, ситуация, когда разные по содержимому блоки дают идентичный результат хэш-функции. Чем это чревато - нетрудно сообразить. Основываясь только на результате хэша мы можем ошибочно удалить вовсе не идентичные по содержимому данные.

Решение в общем-то очевидно. На самом деле никто не пользуется примитивной контрольной суммой, я ее привел просто в качестве примера, иллюстрирующего проблему.
Для вычисления хэш-функции используются различные математические алгоритмы, более устойчивые к хэш-коллизии, наиболее известны, например, CRC32 или MD5.
Более устойчивые - да, но не абсолютно.
Устроит ли вас результат, что “ваши данные скорее всего, с высокой степенью вероятности, не будут ошибочно удалены”? По видимому - нет.

Что же делать? Снова очевидно - усложнять алгоритм, снижая вероятность коллизии.
Однако, возникает проблема накладных расходов. Вычисление сложного алгоритма есть довольно непростая и ресурсоемкая задача. А если учесть, что мы должны проделывать ее для каждого записываемого на систему хранения блока без исключения? Процессорные ресурсы сейчас дешевы, но не настолько же.

??менно это является причиной того, что массивно-дедуплицирующие системы, например такие, как система типа CAS (Content-addressable Storage) EMC Centera, очень, ОЧЕНЬ медленные на запись.

NetApp, представив в 2007 году свое решение той задачи, предсказуемо пошел своим путем.
Как я уже упоминал, системы NetApp хранят результат CRC, это сравнительно простой в вычислении и “недорогой”, но недостаточно устойчивый к коллизиям алгоритм вычисления, для каждого 512-байтного блока. Этот CRC достается нам, по сути, бесплатно, он в принципе уже есть на дисках, хотим мы этого, или нет, пользуемся им, или нет.
Но использовать только его для определения дубликатов нельзя.

Файловая структура WAFL, лежащая “в основе” всех систем хранения NetApp использует блок данных размером 4KB, то есть 8 таких секторов.
CRC от этих 8 секторов дают нам некий более или менее уникальный fingerprint такого блока.
Эти фингерпринты сводятся в массив внутренней “базы”, по которой производится поиск идентичных фингерпринтов. Как вычисление несложного хэша, так и поиск по значениям такого хэша, это, в принципе, не слишком сложная и ресурсоемкая задача, тем более, что, как я написал выше, значительная часть задачи уже и так решена, так как CRC у нас уже есть для всех секторов “бай дизайн”, изначально, по умолчанию.
??дентичные фингерпринты являются основанием предполагать идентичность соответствующих им блоков.
Обратите внимание, не “означают идентичность”, для этого алгоритм слишком прост.

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

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

Однако “чистый offline” процесса дедупликации дает нам пренебрежимо малое влияние процесса на производительность системы. Конечно многое зависит от мощности системы, характера данных, и так далее, но чаще всего пользователи сообщают о влиянии на производительность от включенной дедупликации в 0% для чтения, и в районе 5-7% при записи, то есть, во многих случаях, пренебрежимо малых величинах.
В результате, системы NetApp могут использовать дедупликацию на ролях так называемых Primary storages, то есть основных, “боевых” системах хранения, а не только на хранилищах бэкапов, DR-реплик и резервных, ненагруженных системах.
Хотя применение дедупликации на primary storages и требует соблюдения рада оговорок, оно, как показывает практика прошедших пары лет, вполне работоспособно и широко применяется сегодня. ?? уж точно дедупликация пригодна для разнообразных secondary storages, таких как D2D Backup, реплики данных и резервные системы.

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

Q: Насколько эффективна дедупликация для хранимых данных?
А: NetApp сделал специальный эмпирический калькулятор, с помошью которого можно приблизительно оценить результат для разных типов данных.
http://www.dedupecalc.com/

Q: А как бы не приблизительные и эмпирические цифры узнать, а на моих конкретных данных?
A: У NetApp есть небольшая программка, которую можно запустить на том данных, она просчитает по нему fingerprint и сообщит ожидаемую эффективность дедупликации. Взять ее можно у партнера NetApp, так как она под определенными ограничениями, не просите ее у меня.
Партнеру скажите, что вам нужна программка SSET под Windows или Linux, он ее может скачать с партнерского раздела.

Q: Я запустил дедупликацию (или SSET) по тому данных, на котором у меня лежит сотня full backup моих данных, и я ожидал получить высокую степень эффективности на таких данных, ведь по сути это полностью одинаковые данные за небольшими изменениями, но получил результат заметно менее ожидаемого, почему так?
A: Дело в том, что для дедупликации важна абсолютная идентичность данных в пределах 4KB-блока. Если идентичные данные имеют по какой-то причине смещение между сравниваемыми блоками, хоть на байт (такое часто случается в форматах файлов резервного копирования), они уже будут считаться неидентичными для алгоритма дедупликации FAS, который не умеет обрабатывать смещение данных в блоках. Эта проблема решена в алгоритме дедупликации для систем VTL, лучше подходящих, и специально заточенных под бэкапы.
По этой причине, кстати, дедупликация FAS так эффективна для виртуальных дисков виртуальных машин, обычно виртуальные диски всегда идентично выровнены между собой, и границы блоков для них совпадают.

Q: Как можно получить лицензию для имеющейся системы?
A: Свяжитесь с ее продавцом, он закажет для вашей системы лицензию. Она бесплатна, но она нужна. Как правило для всех новых систем она поставляется по умолчанию, как iSCSI, например.

Q: Есть ли какие-то ограничения по использованию?
A1: Конечно есть :) Для полного понимания рекмендуется прочесть соответствующий Best Practices на сайте NetApp, а из FAQ-овых вопросов - обязательно посмотрите, какой лимит определен для вашей системы хранения. Он зависит от версии используемой Data ONTAP, и на момент написания этого текста, для 7.3.1 составляет 1TB для FAS2020 (самой младшей), 2TB для 2050 и 3020, 3TB для 3050, 4TB для 3040 и 3140, выше (3070, 3160, 6000) размер тома с включенной дедупликацией может быть равен максимальному размеру тома на системе хранения - 16TB. Это ограничение вызвано нежеланием перегружать возможным процессом не слишком большие объемы памяти и процессоров для этих систем, что могло бы вызвать заметное снижение рабочей производительности системы.
Если вы создали том больше, чем разрешено для данной OS и данного “железа”, то дедупликация не запустится. С другой стороны и ничего плохого тоже не произойдет :).
А2: Обратите также внимание, что дедупликация производится только для активной файловой системы. Если много блоков данных “заперто” в снэпшотах, то степень достигнутой дедупликации будет ниже, так как блоки данных в снэпшотах не обрабатываются. Возможно со временем эту проблему решат, но пока перед началом дедупликации рекомендуется удалять снэпшоты, провести дедупликацию, после чего снэпшоты можно снова брать и использовать.

Q: Велична в 2TB на том данных, подлежащих дедупликации, это объем записываемых в него данных?
A: Нет, это именно размер тома. Если у вас на системе ограничение 2TB на том с дедупликацией, и при этом вы пишете на него данные, которые могут быть дедуплицированы вдвое, то после записи 2TB и первого прохода процесса дедупликации, у вас освободится 1TB, который вы, в свою очередь, сможете записать после окончания этого процесса. Далее по этому записанному 1TB также пройдет дедупликация, и после ее окончания вы снова получите свободное место. Но первоначально объем записи равен размеру тома, не забывайте, что это именно оффлайновая дедупликация, даже если вы заливаете 2TB нулей, вы получите эффект только после его обработки.
Однако, если вы включили дедупликацию на томе большего размера, на котором есть всего 2TB и менее данных, то дедупликация просто не включится. Важен именно размер тома.

Q: Могу я вернуть “как было” если у меня что-то пойдет “не так”?
A: Конечно, можно как включить, так и выключить дедупликацию в любой момент, а также вернуть назад “дупликацию”, если почему-то что-то не устроит.

Где еще почитать поподробнее по-русски о технических аспектах:
RUS TR-3505 Deduplication for FAS and V-series Best Practices.pdf

–
UPD:
О том, как дедупликация влияет на производительность работы систем хранения NetApp можно прочитать здесь:
Дедупликация и производительность работы

–
UPD2: Кстати, знаете ли вы, что NetApp гарантирует экономию по меньшей мере 50% объема хранения в случае использования дедупликации для данных виртуальных сред (VMware ESX/vSphere, MS Hyper-V/Hyper-V R2, Citrix Xen)?
http://www.netapp-vi.eu/ru/