about NetApp

Я уже рассказывал о том, что, начиная с ONTAP 8.х, и на 64-bit aggregate, у WAFL есть механизм компрессии хранимых на дисках данных. Механизм онлайн-компрессии сравнительно хорошо знаком пользователям, так как, например, давно поддерживается на NTFS. Однако, по моим наблюдениям, используют его не так часто, боясь его заметного влияния на производительность, и большей нагрузки на процессор сервера. Следует, тем не менее, отметить, что для современных процессоров, производительность которых сильно выросла со времен Stacker и MS DiskDrive, такая дополнительная нагрузка на процессор операций запаковки-распаковки весьма незначительна по абсолютной величине, но при этом значительно уменьшает объемы дискового трафика. Например, если компрессия, вдвое уменьшает “футпринт”, то есть хранимый объем данных, то за счет сравнительно небольшого увеличения (проценты, как правило) нагрузки на процессор, мы можем вдвое увеличить производительность чтения-записи, так как объем данных считываемых и записываемых на диск уменьшается, в нашем случае, вдвое, данные попадают на диск и считываются с него всегда уже сжатыми.

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

Но любопытно подробнее разобраться с тем, как реализована компрессия у NetApp. Дело в том, что для файловых систем, хранящих данные в фиксированных блоках-“кластерах” файловой системы, компрессия внутри этих кластеров, зачастую, бесполезна. Данные не могут занимать места менее одного блока (для WAFL – 4KB), то есть экономия места внутри блока никак не может быть использована. Сложность вызывает также работа с большим файлами. Например, в случае “обычной” компрессии файла архиватором типа ZIP, и прочими аналогичными, нам, часто, для того, чтобы извлечь, изменить или записать данные в середину большого файла, приходится распаковать и перепаковать его целиком. Это влечет за собой большую затрату времени и занятой памяти RAM. То что годится для оффлайновых архиваторов – не подходит для онлайн-компрессии.

При создании механизма компрессии инженерам NetApp пришлось решить как эти, так и многие другие проблемы.

Первый интересный с точки зрения “техники процесса” момент организации работы компрессии состоит в том, что алгоритм компрессии работает не с “файлом” целиком, а бъет его на фиксированные сегменты, под названием “Compression Groups”. Каждая Compression Group содержит 8 секторов WAFL, размером 4KB, и имеет размер 32K.

Каждый файл, размещенный на томе, со включенной компрессией, рассматривается алгоритмом компрессии как разбитый на некоторое количество независимо обрабатываемых Compression Groups (CG). Например файл, размером 60KB будет содержать две CG, одну размером 32KB, и одну неполную, размером 28KB. При этом компрессия не применяется к файлам, размерам 8KB и менее.

Каждая CG обрабатывается отдельно, а, при необходимости считывания части файла “из середины”, считывается и распаковывается не весь файл, а только необходимая Compression Group в нем.

Но это еще не все интересное.

Выглядит довольно очевидным решение как-то определять факт невозможности или низкой эффективности сжатия для данных, и данные, которые не жмутся (например JPEG, ZIP, MP3 или AVI) не жать вовсе, сэкономив на этом ресурсы процессора. Ведь в противном случае процессор будет полноценно занят сжатием-разжатием содержимого Compression Groups ради жалких долей процента результата. ??менно так поступили в NetApp. Перед операцией для Compression Group определяется эффективность сжатия, и, если результат получается ниже 25% (менее четверти содержимого группы, то есть менее 8KB, удается высвободить в результате компрессии), то сжатие для данной группы не прозводится вовсе и она записывается неизменной.

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

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

Постпроцессная компрессия выполняется по тому же расписанию, что и дедупликация, и запускается после выполнения процесса дедупликации для данного тома. Стоит также отметить, что дедупликация и компрессия возможны на одном и том же томе, прекрасно сосуществуют, и не отменяют одна другую. Более того, компрессия после дедупликации вполне возможна. Представьте себе множество виртуальных машин, которые хорошо дедуплицируются, так как содержат одно и то же содержимое, и дедупликация позволит нам хранить не сто виртуальных машин, а одну (и некоторое количество сохраненной “дельты” между этой VM и сотней индивидуальных VM с дедуплицированным нами содержимым) . Но ведь файлы Program Files или пользовательские файлы этого единственного экземпляра, как правило, можно еще и сжать раза в полтора! ?? эта компрессия будет осуществлена над уже дедуплицированным содержимым.

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

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

Лаборатория NetApp опубликовала следующие оценки производительности для системы FAS6080 (на сегодня это уровень хорошего такого midrange класса FAS3240, пожалуй). Для такой системы были достигнуты показатели работы постпроцессной компрессии на уровне 140MB/s для одного процесса, и 210MB/s максимальной производительности для нескольких процессов одновременно. На загрузке характера файлового сервера, с нагрузкой на процессор не более 50%, задачи inline-компрессии увеличивали нагрузку на менее чем 20% для датасетов, сжимающихся минимум на 50%.

Оценочная эффективность компрессии и дедупликации показывается NetApp для разных наборов данных на следующем графике:

Я бы хотел также упомянуть, что имеющаяся у партнеров NetApp утилита SSET (Space Savings Estimation Tool) в текущей версии позволяет провести оценку эффекивности дедупликации ?? компрессии на реальных пользовательских данных, вычисляя на них результат работы алгоритма NetApp. Эта утилита запускается на реальных данных пользователя, работая в read-only, и, никак не изменяя и не повреждая эти данные, позволяет оценить результат дедупликации и компрессии даже без использования стораджа NetApp, например до его покупки. Эту утилиту можно просить у партнеров, она имеется для Linux и Windows.

Хотел бы обратить внимание тех, кто планирует использование новой возможности на системах хранения 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, которая выйдет этой осенью.