Как стать автором
Обновить
0

Дедупликация данных — подход NetApp

Время на прочтение 10 мин
Количество просмотров 26K
image
Дедупликация данных — это технология, при помощи которой обнаруживаются и исключаются избыточные данные в дисковом хранилище. В результате это позволяет сократить объёмы физических носителей для хранения тех же объёмов данных.
Дедупликация данных это одна из самых «горячих» тем в области систем хранения данных последних двух-трех лет. Ведь очевидно, что в том гигантском объеме данных, который сейчас приходится хранить современным системам хранения, неизбежно встречаются дубликаты и идентичные данные, за счет устранения которых можно было бы значительно сократить объемы хранения.
Пожалуй наибольшего успеха снискали реализации технологий дедупликации в области систем дискового резервного копирования (например EMC Avamar, Data Domain), однако компания NetApp первой объявила о возможности использования дедупликации для так называемых «primary storage», то есть основного, «боевого» хранилища активных данных, так как смогла предложить технологию дедупликации, практически не снижающую производительность его работы.
Сегодня я бы хотел рассказать как и за счет чего это удалось, и почему пока не получается у других.

Итак, дедупликация — это устранение дублирующихся данных при их хранении на дисках хранилища. Каким образом?
Под общим названием «дедупликация» может скрываться сразу целый ряд различных реализаций. Простейшая из них — реализация дедупликации на «файловом» уровне. Это то, что давно реализовано в «UNIX-like» файловых системах с помощью механизма «линков». Одна и та же физическая цепочка блоков может адресоваться из разных точек файловой системы. Если, к примеру, одна и та же стандартная библиотека используется без изменения множеством разных программ, то, вместо того, чтобы копировать один и тот же файл в десятки мест на диске, мы храним одну копию, а остальные заменяем на линк. Когда OS или приложение обращается к файловой системе за этим файлом, то файловая система прозрачно перенаправляет по линку это обращение к тому самому единственному экземпляру.

Но что делать, если вышла новая версия библиотеки, которая хоть и отличается всего на пару сотен байт содержимого, но уже является в целом иным файлом? Такой механизм уже не сработает. Также не работает он для «нефайловых» данных, например в SAN-хранилищах, работающих по FC или iSCSI.Именно поэтому механизмы линков, или «файловая дедупликация», в настоящий момент используется относительно ограниченно. Вот если бы можно было по линку ссылаться на часть содержимого!

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

Если вы вспомните мою статью об основе всех систем хранения NetApp, файловой структуре WAFL, то увидите, почему NetApp так заинтересовалась дедупликацией. Ведь субфайловая, блочная дедупликация абсолютно естественно реализуется в терминах WAFL, где «всё есть линки» на блоки хранения.

Где же может применяться дедупликация?
Я уже упомянул хранилище резервных копий, и в этой области дедупликация применяется относительно давно и успешно (часто в резервные копии попадают одни и те же, мало измененные по содержимому, обширные файлы, пользовательские документы, в том числе в копиях, например в разных папках, разных пользователей,). Но есть и другие перспективные области применения.
Один из них — хранение данных виртуальных машин в среде серверной виртуализации VMware ESX, MS Hyper-V, Xen Server, и так далее.
Однако использовать для дедупликации методы, хорошо работающие с резервными копиями, чаще всего не получится. Никому не захочется заплатить за пространство катастрофическим падением производительности дискового хранилища, как это часто происходит.
То, что годится для бэкапов — не годится для primary storage.
Нужно не просто устранить дубликаты, но и сделать это таким образом, чтобы не пострадала производительность.

За счет чего дедупликация столь эффективна на данных виртуальных инфраструктур?
Приведу какой-нибудь наиболее вопиющий пример. Допустим, вы разворачиваете систему серверной виртуализации в среде VMware, и в датаcторах сервера ESX у вас находится десяток серверов Windows или Linux, каждый выполняющий свою собственную задачу. Все виртуальные машины одного типа, конечно же, развернуты из предварительно подготовленного «темплейта», содержащего эталонную OS, со всеми необходимыми патчами, настройками и сервис-паками.
Для создания нового сервера вы просто копируете этот темплейт, и получаете новую, уже настроенную и обновленную виртуальную машину, состоящую из файла индивидуальных настроек, и большого файла «виртуального диска», содержащего в себе все файлы «гостевой OS» и ее приложений.

Но при этом, на десяток таких виртуальных машин, вы имеете десяток почти полностью идентичных виртуальных дисков, с папками /Windows/System32 (или /usr) внутри, отличающихся всего в нескольких десятках килобайтов индивидуальных настроек в реестре и конфигурационных файлах.
Несмотря на то, что по содержимому они, формально, практически идентичны, каждая виртуальная машина своим «диском C:» займет на системе хранения свой десяток гигабайт. Помноженное на десять виртуальных машин это дает уже вполне весомую цифру.
Еще более вопиющие ситуации возможны в случае VDI (Virtual Desktop Infrasructure), где количество «виртуальных десктопов» может исчисляться сотнями, и все они, как правило, используют одну и ту же OS.

Практика использования дедупликации на данных файлов виртуальных дисков показывает, что результаты экономии пространства часто достигают 75-90% от изначально занятого объема, «без дедупликации».
Это довольно заманчиво, без особого риска и накладных расходов, не жертвуя производительностью, освободить на терабайте хранилища 750-900 гигабайт ранее занятого образами виртуальных машин объема.

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

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

Отказавшись от «онлайн»-дедупликации, той, что происходит непосредственно при поступлении данных, Что-то мы, безусловно, теряем.
Например, если мы записываем сильно дуплицированные данные, допустим 1TB, из которых 900GB — нули, нам придется сперва выделить на запись место, размером 1TB, заполнить его нашими «нулями на 90%», и лишь потом, в ходе процесса дедупликации, 90% этого пространства освободится.

Однако «оффлайновая» дедупликация дает нам и множество очень значимых плюсов.
  1. Мы можем использовать более эффективные и точные (читай: медленные и «процессороемкие») алгоритмы обнаружения дубликатов данных. Нам не нужно идти на компромиссы, чтобы не перегрузить работой процессор и не снизить производительность работы системы хранения с дедупликацией.
  2. Мы можем анализировать и обрабатывать значительно большие объемы данных, так как в случае «оффлайна» нам доступно для анализа и использования при дедупликации все пространство хранения, а не только нынешняя, непосредственно записываемая порция данных.
  3. Наконец, мы можем делать дедупликацию тогда и там, когда и где нам удобно.


Таким образом, ничего удивительного, что системы хранения NetApp выбрали для использования именно «оффлайновый» способ, ведь он позволил делать им дедупликацию с минимальным влиянием на собственно дисковую производительность системы.
Насколько я знаю, на сегодня NetApp единственный производитель систем хранения, использующих дедупликацию, который не опасается официально рекомендовать ее использование для так называемых primary data, то есть основных, рабочих данных, а не только бэкапов и архивов.

Как же «физически» устроен использованный в NetApp механизм дедупликации?
Часто приходится слышать, что жесткие диски FC и SAS систем хранения NetApp используют «нестандартный размер сектора» равный 520, вместо 512 байт. «Нестандартный» в кавычках, потому что, как ни странно это прозвучит, но именно сектор в 520 байт (512b data + 8b CRC) на сегодня следует считать «стандартным», так как именно это значение утверждено «комитетом T10», организацией, занимающимся разработкой и утверждением стандартов в области SCSI. Увы, пока совсем немногие системы хранения последовали этому новому стандарту (кроме NetApp я знаю только EMC Clariion, а также системы highend-класса, такие как EMC Symmetrix и HDS USP), а использование такого формата сектора дает много правильных и полезных бонусов в работе, вводя дополнительную защиту против неотслеживаемых на уровне RAID повреждений содержимого записанного сектора. Вероятность таких ошибок весьма невысока, но все же ненулевая.
Однако, помимо этой защиты, NetApp использует такие дополнительные 8 байт на сектор для организации своего механизма дедупликации данных.

image(pic)

Блок данных в WAFL занимает 4096 байт. Блок данных, это то, что в файловых системах иногда называется «дисковым кластером», одна адресуемая порция данных, не путайте с компьютерным кластером «высокой доступности». Этот блок, как вы видите, состоит из 8 секторов по 512 байт.
Как я уже рассказал ранее, каждому из этих 512 байт данных «придано» на системном уровне диска еще 8 байт CRC. Итого, на блок WAFL в 4KB мы имеем 64 байта «контрольной суммы» CRC.
У CRC есть один большой плюс — он очень быстро и просто вычисляется. Однако есть и минус — возможна так называемая «hash-коллизия», ситуация, когда два различных по содержимому блока имеют одинаковый результат хэша. Если мы будем ориентироваться только на результаты сравнения хэшей, то мы вполне можем принять за идентичные (и один из них безвозвратно удалить) два блока разного содержимого. Эта вероятность невелика, но она существует, и я уверен, вы не захотите, чтобы она произошла именно с вашими данными.
Как бороться с хэш-коллизией? Решение «влоб» — удлиннять хэш и усложнять алгоритм расчета. Однако этот вариант очень ресурсоемок, прежде всего в отношении процессора системы хранения. Именно поэтому, системы CAS — Content-Addressable Storage, так сказать «дедупликация первого поколения», например EMC Centera, ОЧЕНЬ медленные на запись, и пригодны только для архивного хранения малоизменяющихся документов.
Но для онлайн-дедупликаци у нас чаще всего просто нет иного варианта.

Однако «выйдя в оффлайн» мы получаем сразу множество новых возможностей, не будучи привязанными к собственно процессу записи данных на диск.
Процесс дедупликации, работающий в фоне, составляет базу хэшей всех блоков дискового тома, и, отсортировав ее, получает список «подозреваемых в совершении дупликации данных». Далее, получив этот список, и резко сократив круг «подозреваемых», и объем дальнейшей работы, процесс дедупликации проходит по диску, и над всеми потенциальными дубликатами проводит тривиальную операцию побайтового сравнения. И только убедившись в полном и безоговорочном совпадении содержимого рассмотренных блоков, один из них освобождает на уровне файловой системы, а на другой переставляет указатель inode, который ранее указывал на теперь высвобожденный блок. Механизм чем-то напоминает механизм линков в UNIX-ных файловых системах, только примененный не к файлам, а непосредственно к блокам данных файловой системы.

«Что же мешает такой механизм применить на обычной файловой системе?» — спросите вы. Если вы читали мой ранее опубликованный пост, про устройство WAFL, вы легко ответите на свой вопрос. Потому что на этих файловых системах блоки данных могут быть впоследствии изменены, перезаписаны. Представим себе, что у нас есть два разных файла, А и Б, каждый состоящий из трех блоков данных (по 4096Kb), так получилось, что средний из этих трех блоков у обоих файлов совпадает (два других — разные). Мы обнаруживаем это, используем такие «линки», и вместо ссылки на средний блок файла Б, устанавливаем ссылку на второй блок у файла А.

image

image

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

image

Это могло бы сработать для резервных копий, которые обычно записываются только раз, и более не изменяются, но абсолютно не подходит для активных «primary data», которые могут изменяться произвольно.

Как вы помните из статьи про устройство WAFL, она устроена таким образом, что однажды записанный блок в дальнейшем уже не перезаписывается и не изменяется, пока существует файл, и пока на данный блок есть хоть одна ссылка из активной файловой системы или любого из снэпшотов. А при необходимости записать изменение в данные файла, из пула свободных блоков выделяется место, куда производится запись, затем на этот блок переставляется указатель активной файловой системы (а указатели снэпшотов остаются на прежние блоки, поэтому мы имеем доступ одновременно и к новому содержимому файла, в «активной файловой системе», и к его старому содержимому, в снэпшоте, если он делался).

image

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

Наверное наиболее часто встречающимся вопросом про дедупликацию будет: Как дедупликация влияет на производительность использующей ее системы хранения?

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

Во-вторых, хотя дедуплицированные объемы данных и имеют несколько большие объемы связанных с ними метаданных, что теоретически может увеличить нагрузку на систему при больших объемах ввода-вывода, большинство пользователей не отмечают эффекта снижения производительности дедуплицированных данных вовсе. А в ряде случаев, за счет уменьшения объемов чтения и лучшей загрузке в кэш (а кэш NetApp знает и умеет правильно использовать дедуплицированные данные), может наблюдаться даже увеличение производительности, например в моменты так называемого 'boot storm', одновременной загрузки нескольких десятков и даже сотен виртуальных машин, когда подавляющее количество считываемых с дисков данных — одни и те же загружаемые в память файлы OS для множества разных машин.

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

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

Кстати сказать, именно дедупликация, наряду с другими технологиями NetApp, такими как RAID-DP, уже описанным Thin Provisioning, и снэпшотами, о которых вкратце было в статье о WAFL, позволила NetApp объявить два года назад беспрецедентную для индустрии акцию "50% space saving guarantee", по которой NetApp гарантирует, что тот же объем данных виртуальных машин, хранимый на любой системе хранения другого производителя, на NetApp уместится в два раза меньшем объеме дисков. А при невыполнении этого обещания — поставить бесплатно недостающие диски. Впрочем, как я знаю, за дисками так никто и не обращался.

И напоследок стоит сказать, что функция дедупликации данных доступна на любой системе хранения NetApp бесплатно, и обычно лицензия на ее активация поставляется по умолчанию с любой системой хранения, а если вам вдруг была продана система без нее, то вы можете получить ее бесплатно у вашего продавца.
Теги:
Хабы:
+32
Комментарии 36
Комментарии Комментарии 36

Публикации

Информация

Сайт
www.netapp.com
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия

Истории