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 для этих блоков). Но, так как нет механизма управлять тем, какие именно блоки или файлы будут компрессированы на томе, а какие - нет (компрессия назначается на том целиком), то это, в общем, довольно теоретическая поправка, не меняющая моей итоговой рекомендации.

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

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

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

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

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

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

Как я уже писал раньше, начиная с Data ONTAP 8.0.1, для пользователей систем хранения NetApp становится доступной опция компрессии хранимых на дисках данных. Эта возможность довольно популярна среди современных файловых систем, например она хорошо работает в NTFS. Теперь эта возможность, дополняющая дедупликацию, появилась у NetApp.

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

Преимущество хранения скомпрессированного файла очевидно. В такой форме файлы занимают значительно меньше места на диске. Насколько меньше – зависит от характера данных. Например уже обработанные тем или иным компрессором файлы, а также цифровое видео и аудио, обычно также сжатое тем или иным алгоритмом, уже практически не сжимается. Исполняемые файлы, например программы, сжимаются примерно на 25-35%. Файлы данных, такие, как документы Word и Excel – обычно на 30-50 процентов.

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

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

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

Теоретически мы могли бы попробовать архивировать отдельно составляющие файл блоки WAFL размером 4KB, используя компрессию на уровне блоков , но что делать с высвободившемся от такой компрессии местом? WAFL не может работать с местом на таком “субблочном” уровне. Если у нас есть файл, который занимает 3 блока WAFL по 4KB, то еть имеет размер в 12KB, и файл сжимается вдвое, то после компрессии на уровне блоков WAFL мы получим три наполовину пустых блока WAFL, однако свободное место на них (так называемые tail-ы) использовать не получится – субблочное пространство не адресуется в ONTAP, и файл по прежнему будет занимать три блока – 12KB.

Выход – в использовании групповой обработки. Каждый хранимый файл последовательно делится на так называемые compression groups, размером 32KB, то есть состоящие из 8 блоков WAFL, с которыми и производятся неободимые операции. Compression Groups рассматриваются как единый объект воздействия компрессии. Поделенный на такие группы файл считывается только в той части, что необходима. Если нам нужно изменить блок данных в середине, то считывается в память 32KB данных, содержащих данный блок, блок изменяется, и затем группа компресируется и записывается.

Любопытно, что перед тем, как компрессировать группу, Data ONTAP проводит “на лету” оценку эффективности компрессии. Если компрессия незначительна (очевидно, что это менее 1/8 размера), то группа записывается в исходном виде. Таким образом, файл сжатого видео, записанный на “сжатый” том, будет записан в “исходном” его состоянии, время и процессор на сжатие явно несжимаемго не тратятся. Оценка же производится для 32KB групп. Если внутри в целом несжимаемого файла обнаружится последовательный блок размером 32KB и более, пригодный для сжатия, он будет сжат обычным образом.

Как обычно, коротко, в вопросах и ответах.

Q: Сколько это стоит?
А: Данная лицензия будет доступна бесплатно, как, например, было и есть с дедупликацией.

Q: Это будет работать только для Data ONTAP 8?
A: Нет, еще какое-то время будет продолжаться развитие ветви “семерки”, и, по предварительным данным, в ней тоже будет доступна компрессия. Если у вас активна подписка на обновление ПО, и вы можете поставить новую версию ONTAP на вашу систему, в ней будет и компрессия. Но вообще говоря, стоит уже задуматься о переходе на Generation 8.

Q: Это вместо дедупликации?
A: Нет, это работает независимо, и может компресировать даже уже дедуплицированные тома! И дедупликацию, и компрессию, вы можете использовать независимо, и даже одновременно, на одних и тех же томах.

Q: А если дедупликация уже дедуплицировала, разве остается что-то, что можно еще и сжать?
A: Конечно. Вот, например, описание эксперимента, в котором оценивалась эффектвноссть дедупликации и компрессии: http://habrahabr.ru/blogs/sysadm/104979/
Кроме этого, представим, что у нас на диске лежит сто одинаковых документов. После дедупликации у нас на диске останутся занятыми только блоки одного экземпляра (и по 99 ссылок на них из других файлов). Но этот единственный файл, в свою очередь также можно скомпрессировать! На дедупликацию и содержимое остальных, дедуплицированных файлов это не повлияет. Они просто будут ссылться на компрессированные блоки.

Q: Когда компрессировать получается лучше, чем дедуплицировать?
A1: Представим себе, что на диске лежит множество файлов, которые уникальны по содержимому. То есть, например, текстовая база документов. Каждый, кто архивировал текстовые файлы знает, что такие файлы хорошо компрессируются. Однако вероятнее всего, в неповторяющихся файлах, дедупликация будет неэффективна. Ведь в таких файлах наверняка нет кусков по 4KB размером, строго идентичных до байта. Любая неидентичность в пределах блока WAFL в 4KB отменяет возможность дедупликации.
A2: Другой вариант, сильно ухудшающий возможности дедупликации – смещение. Даже незначительное смещение в содержимом файлов мешает правильно сработать дедупликации. Но ничуть не ухудшает возможности компрессии.

Q: А что вообще лучше, дедупликация или компрессия?
A: Для разных применений – лучше разное. Что-то лучше дедуплицируется, пример – файлы дисков виртуальных машин, что-то – компрессируется, пример – большинство баз данных, или хоумдиры документов с малым количеством дублирующихся между разными пользователями данных, или бэкапы с переменным смещением, сильно портящие “статистику” дедупликации. Наконец, вы можете компрессировать уже дедуплицированные данные.
Конечно, дедупликация несколько меньше нагружает систему по процессорным ресурсам и почти не влияет на производительность, так как работает, в отличие от компрессии, в “оффлайне”. Но в ряде случаев и нагрузкой компрессии можно пренебречь, а экономия пространства – штука нелишняя. Смотрите по обстановке.

Q: Круто, спасибо!
A: Да на здоровье :)

В блоге Vaughan Stewart была найдена интресная картинка:

Да, это то что вы подумали. Начиная с Data ONTAP 7.3.3 и 8.0.1 на WAFL теперь работает компрессия (лицензия бесплатна, как iSCSI, или дедупликация, например), причем использование компрессии не отменяет и не заменяет, и может использоваться как совместно с дедупликацией, так и по отдельности. Это такая же знакомая и привычная онлайн-компрессия как на NTFS, например.

Компрессия пригодится в случаях, когда на диске лежат различные по содержимому данные, но не слишком дублирующиеся внутри на уровне 4KB-блоков WAFL. Тем не менее содержимое этих файлов вполне может сжиматься классическими LZ-алгоритмами. Например у меня на ноутбуке папка Program Files диска C: сжата почти на 30% от ее, примерно 2GB, объема.
Хороший пример – homedir различных пользователей организации. Хотя в хоумдирах иногда и попадаются идентичные документы и файлы у разных людей, в основном же, как показывает практика, большая часть содержимого хоумдиров достаточно уникальна, и не слишком эффективно дедуплицируется. Однако вполне поддается традиционному zip-like сжатию с неплохими показателями.

Для 7.3.3 компрессия идет как PVR, то есть доступна по запросу, но запланирована как стандартная опция в 8.0.1, которая выйдет этой осенью.