что такое дедупликация данных

Обзор дедупликации данных

область применения: Windows server 2022, Windows server 2019, Windows Server 2016, Azure Stack хЦи, версия 20H2

Что такое дедупликация данных

Дедупликация данных, часто называемая дедупликацией, — это функция, которая помогает снизить влияние избыточных данных на затраты на хранение. Если дедупликация данных включена, она оптимизирует свободное место в томе за счет проверки данных тома на наличие дублирующихся частей. Дублирующиеся части набора данных тома сохраняются один раз и (при необходимости) сжимаются для дополнительной экономии. Дедупликация оптимизирует избыточные данные, не нарушая достоверность или целостность данных. Дополнительные сведения о работе дедупликации данных см. в разделе Как работает дедупликация данных? на странице Understanding Data Deduplication (Понимание процесса дедупликации данных).

KB4025334 содержит сведение исправлений для дедупликации данных, включая важные исправления надежности, и настоятельно рекомендуется устанавливать его при использовании дедупликации данных с Windows Server 2016 и Windows Server 2019.

Преимущества дедупликации данных

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

Экономия места, которую может обеспечить дедупликация данных, зависит от набора данных или рабочей нагрузки в томе. В наборах данных с высоким уровнем дупликации скорость оптимизации достигает 95 %, а объем использования службы хранилища может уменьшаться в 20 раз. В следующей таблице представлены типичные значения экономии за счет дедупликации для разных типов содержимого.

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

Источник

Понимание процесса дедупликации данных

область применения: Windows server 2022, Windows server 2019, Windows Server 2016, Azure Stack хЦи, версия 20H2

В этом документе описывается, как работает дедупликация данных.

Как работает дедупликация данных

Дедупликация данных для Windows Server разрабатывалась на основе двух важнейших принципов.

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

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

После включения дедупликации данных для тома она выполняет в фоновом режиме следующие задачи:

Этот процесс выполняется в четыре этапа:

При считывании оптимизированных файлов файловая система отправляет файлы с точкой повторного анализа в фильтр дедупликации данных файловой системы (Dedup.sys). Фильтр перенаправляет операцию чтения к соответствующим блокам, которые образуют поток этого файла в хранилище блоков. Изменения фрагментов дедуплицированного файла записываются на диск в неоптимизированном виде. Их при следующем запуске обрабатывает задание оптимизации.

Типы использования

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

Задания

Функция дедупликации данных использует стратегию постобработки для оптимизации и эффективного использования пространства на томе.

Глоссарий дедупликации данных

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

Часто задаваемые вопросы

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

Чем отличается дедупликация данных от хранилища единственных копий? Хранилище единственных копий (SIS) является предшественником технологии дедупликации данных и впервые было представлено в выпуске Windows Storage Server 2008 R2. Для оптимизации тома хранилище единственных копий выявляло в нем полностью идентичные файлы и заменяло их логическими ссылками на одну копию такого файла, размещенную в общем хранилище SIS. В отличие от хранилища единственных копий, дедупликация данных способна уменьшить пространство, занимаемое файлами, которые не полностью идентичны, но имеют некоторые одинаковые элементы, а также файлами, в которых встречается много повторяющихся элементов. Хранилище единственных копий считается устаревшим начиная с выпуска Windows Server 2012 R2, а в Windows Server 2016 его полностью заменила дедупликация данных.

Чем отличается дедупликация данных от сжатия NTFS? Сжатие NTFS используется файловой системой NTFS на уровне тома. Эта необязательная функция NTFS оптимизирует каждый файл по отдельности, сжимая его во время записи. В отличие от сжатия NTFS, дедупликация данных использует для экономии места одновременно все файлы на томе. Это гораздо эффективнее, чем сжатие NTFS, ведь файл может одновременно иметь как внутреннее дублирование данных (которое устраняется сжатием NTFS), так и сходство с другими файлами в томе (которое не устраняется сжатием NTFS). Кроме того, дедупликация данных использует модель постобработки. Это означает, что новые или измененные файлы записываются на диск в неоптимизированном виде, и лишь затем дедупликация данных оптимизирует их.

Чем отличается дедупликация данных от форматов архивации файлов, таких как ZIP, RAR, 7Z, CAB и т. д.? Форматы ZIP, RAR, 7Z, CAB и другие выполняют сжатие для определенного набора файлов. Как и в случае с дедупликацией данных, оптимизируются повторяющиеся фрагменты внутри файлов и в разных файлах. Однако вам необходимо выбрать файлы, которые должны быть включены в архив. Семантика доступа также отличается. Чтобы получить доступ к определенному файлу в архиве, необходимо открыть архив, выбрать файл, а затем распаковать его для использования. Дедупликация данных работает незаметно для пользователей и администраторов, не требуя никаких ручных операций. Кроме того, дедупликация данных сохраняет семантику доступа — оптимизированные файлы выглядят для пользователя точно так же, как и раньше.

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

Можно ли вручную запускать задания дедупликации данных? Да, все задания дедупликации данных можно запускать вручную. Это удобно, если запланированное задание не было выполнено из-за недостатка системных ресурсов или ошибки. Кроме того, есть специальное задание отмены оптимизации, которое запускается только вручную.

Можно ли просмотреть историю запусков заданий дедупликации данных? Да, все задания дедупликации данных создают записи в журнале событий Windows.

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

Источник

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

Дедупликация данных — это технология, при помощи которой обнаруживаются и исключаются избыточные данные в дисковом хранилище. В результате это позволяет сократить объёмы физических носителей для хранения тех же объёмов данных.
Дедупликация данных это одна из самых «горячих» тем в области систем хранения данных последних двух-трех лет. Ведь очевидно, что в том гигантском объеме данных, который сейчас приходится хранить современным системам хранения, неизбежно встречаются дубликаты и идентичные данные, за счет устранения которых можно было бы значительно сократить объемы хранения.
Пожалуй наибольшего успеха снискали реализации технологий дедупликации в области систем дискового резервного копирования (например 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% этого пространства освободится.

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

(pic)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник