Записки IT специалиста
Технология дедупликации давно известна пользователям серверных редакций Windows и широко используется системными администраторами, позволяя эффективно использовать дисковое пространство. В клиентских системах данная возможность отсутствует, так как домашние сценарии не предусматривают хранение больших массивов данных, однако может быть легко добавлена, что, несомненно, окажется полезным для специалистов и компьютерных энтузиастов.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Мы уже рассказывали, как включить дедупликацию в Windows 8, что позволило многим, и нам в том числе, сэкономить заметные средства, отложив расширение дискового пространства за счет более эффективного его использования.
Windows 10 в момент выпуска такой возможности не имела, что легко объясняется: пакеты для дедупликации энтузиасты берут из серверной версии ОС, разработка которой производится с некоторым опозданием от клиентской. Это же следует учитывать и при обновлении ОС на новую версию, так на дату выпуска пакеты для дедупликации могут быть еще не готовы.
Следует помнить, что в отличии от предыдущих версий под названием Windows 10 скрывается целый ряд операционных систем, для каждой из которых нужны свои пакеты для поддержи дедупликации. На текущий момент существуют следующие стабильные выпуски Windows 10:
| Версия | Сборка | Дата выпуска | Окончание поддержки | Дедупликация |
|---|---|---|---|---|
| 1507 (RTM) | 10240 | 29.07.2015 | 09.05.2017 | НЕТ |
| 1511 | 10586 | 12.11.2015 | 10.10.2017 | ДА |
| 1607 | 14393 | 02.08.2016 | 10.04.2018 | ДА |
| 1703 | 15063 | 05.04.2017 | 09.10.2018 | ДА |
| 1709 | 16299 | 17.10.2017 | 09.04.2019 | ДА |
| 1803 | 17134 | 30.04.2018 | 12.10.2019 | ДА |
| 1809 | 17763 | 13.11.2018 | 10.11.2020 | ДА |
| 1903 | 18362 | 21.05.2019 | 08.12.2020 | ДА |
| 1909 | 18363 | 12.11.2019 | 11.05.2021 | ДА |
| 2004 | 19041 | 27.05.2020 | 14.12.2021 | ДА |
Здесь мы говорим об основной основном канале поддержки SAC ( Semi-Annual Channel, Полугодовой канал) и не касаемся LTSC-версий, которые не предназначены для широкого использования.
Первая сборка пакетов для дедупликации в Windows 10 была собрана из пакетов для Windows Server 2012 и предназначалась для сборки 10514, затем стали доступны пакеты на базе Windows Server 2016 ( 14393) и 2019 ( 17763) . В настоящий момент Windows Server с возможностями рабочего стола переведен в LTSC-канал (не путать с одноименным каналом Windows 10) и новые версии выпускаются раз в два три года. В полугодовом канале обслуживания (SAC) находится просто Windows Server без номера года, который не имеет возможностей рабочего стола и предназначен в первую очередь для быстрого внедрения инноваций в области контейнеров и микрослужб.
Таким образом все промежуточные версии Windows 10, не имеющие LTSC-аналога серверной системы получают пакеты дедупликации из полугодового канала. Чем это может быть чревато? Прежде всего стабильностью, так как SAC-версии Windows сервер не предполагают использования в системах с возможностями рабочего стола и на текущий момент известно об определенных проблемах с пакетами для версии 20.04, которые на одной системе могут работать, а на другой — не работать.
Отдельно следует уточнить насчет инсайдерской версии. В ней дедупликация работать не будет. Поэтому выбирайте то, что вам нужнее.
Кроме того, многих интересует вопрос: что будет с дедуплицированными томами при обновлении с Windows 8 или между версиями Windows 10. Отвечаем: ничего страшного не произойдет, но ваши данные окажутся недоступны до тех пор, пока вы не установите пакеты для текущей сборки ОС.
Важно! Дедупликация в Windows 10 не является документированной функцией и может работать некорректно (либо не работать вообще) и, хотя большинство сценариев не несет угроз целостности данных, они могут оказаться недоступными, в т.ч. и на длительное время. Поэтому используйте данную возможность исключительно на свой страх и риск.
Так как основное обсуждение дедупликации в Windows 10 и размещение пакетов происходят на зарубежном форуме, а многие ссылки ведут на файлообменники мы перепаковали содержимое пакетов и разместили их на собственном сервере.
Каждый архив содержит основные и языковые пакеты, мы оставили только en-US и ru-RU, устанавливать следует какой-то один.
Для установки откройте командную строку от имени Администратора, перейдите в каталог с распакованными пакетами и выполните приведенные ниже команды, в данном примере мы будем устанавливать пакеты для 2004 русской версии:
Для установки других версий или языков соответствующим образом измените команды. Наименования пакетов отличаются только номером сборки и указателем языка.
Сразу после установки пакетов дедуплицированные данные снова станут доступны, перезагрузка не требуется. Для управления дедупликацией в Windows 10 нет графических инструментов, поэтому воспользуемся PowerShell.
Если вы впервые включили дедупликацию, то следует импортировать модуль PowerShell, для этого запустите консоль PowerShell от имени администратора выполните следующие команды:
Теперь, например, можно проверить наличие дедуплицированных томов и их состояние:
Но не будем забегать вперед и начнем сначала. Для включения дедупликации воспользуйтесь командой:
Запущенная без параметров данная команда установит тип использования тома «по умолчанию», который подходит для общего применения, однако тип использования можно указывать явно, допустимы следующие значения:
- HyperV — тома для хранения виртуальных машин Hyper-V.
- Backup -том оптимизирован для виртуализированных серверов резервного копирования.
- Default — том общего назначения. Это значение по умолчанию.
Например, данная команда включит виртуализацию с типом использования Hyper-V или сменит его, если дедупликация для данного тома уже включена:
Обратите внимание, что данная команда только включает дедупликацию, но не производит ее, ваши данные будут оставаться неоптимизированными до тех пор, пока не будет выполнено задание оптимизации (вручную или по расписанию).
Но перед тем, как запускать задание стоит выполнить более тонкую настройку процесса дедупликации, во-первых, установим минимальный возраст данных для дедупликации, чем он ниже, тем эффективнее процесс, но тем выше нагрузка на систему (задание по оптимизации выполняется каждый час). Например, установим данное значение в 0, т.е. оптимизироваться будут все данные:
Вторая полезная опция — минимальный размер дедуплицируемого файла, на томах с виртуальными машинами имеет смысл установить это значение таким образом, чтобы дедупликации подвергались виртуальные диски, но не затрагивались мелкие файлы конфигурации. Размер устанавливается в байтах, т.е. установить 512 МБ следует командой:
Опции командлета Set-DedupVolume можно сочетать, т.е. сразу установить и минимальный размер, и минимальное время. Еще одна полезная опция — исключения, например, следующая команда исключит из процесса дедупликации папку E:\Folder1:
Путь следует указывать полностью, несколько значений разделяются запятыми, если путь содержит пробелы, то его следует взять в кавычки. Повторный запуск команды перезаписывает параметры. Важно понимать этот момент, так как если вы позже захотите добавить в исключения еще и E:\Folder2, то команда должна выглядеть так:
В противном случае вы Folder2 в список исключений добавите, а Folder1 удалите.
Аналогичным образом можно задать исключения по типам файлов, для этого укажите нужные расширения (без точки) через запятую, например, исключим временные файлы и сигнальные lck-файлы:
После того, как все необходимые настройки выполнены, можно запускать процесс оптимизации, для этого предназначена команда:
Проконтролировать ход выполнения задания можно командой:
Таким образом можно выполнять не только оптимизацию, данный командлет поддерживает следующие виды задач:
- Optimization -запуск процесса дедупликации данных.
- Garbage Collection — применяется для очистки всех неиспользуемых или удаленных данных.
- Scrubbing — проверка целостности дедуплицированных данных.
- Unoptimization — запуск процесса отмены дедупликации данных.
Первоначальный процесс оптимизации может занять продолжительное время, создавая при этом достаточно большую нагрузку на диск, учитывайте это. Скорость дедупликации на практике находится в пределах 20-40 МБ/с, так что необходимое время можно достаточно точно рассчитать и спланировать.
Стоит ли овчинка выделки? Однозначно стоит, ниже приведен результат дедупликации нашего хранилища виртуальных машин:
Если бы не данная технология, то нам давно бы пришлось топать за новыми дисками вдвое большего объема.
Закончив с дедупликацией, не забудьте проверить и откорректировать расписание регламентных заданий, некоторые из них запланированы на глубокую ночь, когда рабочая станция будет гарантировано выключена, поэтому перенесите их на рабочее время.
Если вам потребуется отключить дедупликацию тома, то сначала необходимо выполнить обратный оптимизации процесс, который вернет все данные на свои места. Если свободного места не хватит, то процесс будет приостановлен.
После того как дедупликация данных будет отменена можно будет выключить этот режим для тома, для этого выполните:
Как видим, благодаря энтузиастам, мы вполне успешно можем использовать все преимущества дедупликации в среде настольных ОС, а некоторая сложность установки и управления с лихвой компенсируется экономией дискового пространства. Да и возможность эта востребована в основном специалистами или энтузиастами, для которых работа в командной строке не является чем-то экзотическим.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Как и зачем производить дедупликацию данных
Многие компании вынуждены применять в своей работе файловый сервер. Его можно считать одним из наиболее неэффективных, так как часто, помимо необходимых данных, такой сервер содержит огромное количество «ненужной информации»: дубликаты файлов, старые бэкапы и т. д. Наличие таких файлов зависит не от сервера, а от способа организации структуры хранения. Например, очень часто в базе хранятся шаблоны файлов, которые различаются несколькими битами информации. В результате объем используемых данных постоянно увеличивается, что повышает потребность в дополнительных устройствах для хранения бэкапов. Способом борьбы с такой проблемой является проведение дедупликации данных. С помощью процедуры удается устранить избыточные копии и снизить потребность в местах для хранения. В результате оптимизируется емкость хранилища и удается избежать использования дополнительных устройств.
Методы дедупликации
Технология позволяет избавиться от многочисленных копий файлов и сохранить на носителе информации только одну единицу файла. Однако для того, чтобы такая процедура была эффективной и действительно помогла устранить все копии, потребуется правильно подобрать уровень детализации.
Data deduplication может выполняться на нескольких уровнях:
- байты;
- отдельные файлы;
- блоки.
Каждый из подходов имеет свои особенности и преимущества, которые стоит учитывать при выборе решения.
Использование блоков является самым популярным вариантом. Если говорить коротко, то дедупликация данных на этом уровне – это анализ файлов, после которого сохраняются лишь неповторяющиеся сведения для отдельного блока. Блок представляет собой логическую единицу информации с определенным размером. Причем размер этой единицы может варьироваться в зависимости от задач.
Важной особенностью дедупликации на таком уровне является использование хеширования. За счет этого удается создавать и хранить в общей базе требуемую сигнатуру, которая обозначает блок данных.
Процедура блочной дедубликации может проводиться с переменной или постоянной длиной блоков. В первом случае файлы распределяются на блоки различного размера – основой для сортировки может выступать дата создания или другой параметр. Переменный способ считается самым эффективным для сокращения объема данных.
Следующий возможный уровень deduplication – это уровень файлов. В этом случае происходит сравнение позднего файла с более ранним. В том случае, если обнаруживается уникальная информация, то она сохраняется. Если же новый файл дублирует предыдущий, то отображается только ссылка на исходные сведения.
То есть по сути записывается изначальный файл, а все последующие копии имеют указатель на информацию. Реализовать такой вариант дедупликации достаточно просто. Как правило, не происходит снижения производительности сервера во время обработки данных. Однако эффективность процедуры ниже, чем при использовании блочного подхода.
Третий из возможных способов дедупликации данных – это отдельный процесс на байтовом уровне. По принципу проведения этот вариант схож с методом блоков, но новые и старые файлы сравниваются по байтам. Именно такой подход к data deduplication позволяет полностью избавиться от дубликатов. Но есть и некоторые недостатки: процедура использует серьезные мощности сервера, поэтому к самому устройства предъявляются повышенные требования.
Дедупликация при резервном копировании
Процедура удаления дубликатов нередко выполняется в процессе сохранения резервной копии. Причем процесс может различаться по месту исполнения, источнику информации (клиенту) и способу хранения (используемому серверу).
- Клиент-сервер. Это совмещенный вариант, при котором мероприятие может выполняться как на клиенте, так и на самом сервере. Прежде чем отправлять сведения на сервер, специальное ПО пытается определить, какие сведения уже были записаны. Как правило, применяется дедупликация блочного типа. Для отдельного блока сведений вычисляется хеш, а перечень хеш-ключей отправляется на сервер. На серверном уровне выполняется сравнение ключей, после чего клиент получает необходимые блоки данных. При использовании такого решения снижается общая нагрузка на сеть, так как осуществляется передача только уникальных файлов.
- Дедубликация на сервере. Теперь поговорим о том, как делать дедупликацию данных на сервере. Такой вариант применяется в тех случаях, когда сведения передаются на устройство без обработки. Может выполняться программная или аппаратная процедура проверки данных. Программная дедубликация подразумевает применение специального ПО, которое и запускает требуемые процессы. При подобном подходе важно учитывать нагрузку на систему, так как она может быть слишком высокой. Аппаратный тип совмещает специальные решения на основе дедубликации и процедуры бэкапа.
- Дедубликация на клиенте. При создании бэкапа возможна репликация данных на самом источнике. Такой способ позволяет задействовать только мощности самого клиента. После проверки данных все файлы отправляются на сервер. Data deduplication на клиенте требует особого программного обеспечения. Недостаток решения в том, что оно приводит к повышенной загрузке оперативной памяти.
Достоинства и недостатки
К преимуществам процедуры возможно отнести следующее:
- Надежность. Deduplication позволяет хранить сделанные бэкапы практически неограниченное время.
- Эффективность. В результате проведения дедупликации удается уменьшить потребности в размерах хранилища практически в 30 раз.
- Экономичность. Решение может использоваться даже при небольшой уменьшенной пропускной способности сети. Осуществляется передача уникальных данных, что экономит трафик.
Однако у технологии есть и недостатки. Основной из них – это риск конфликта, если несколько блоков будут в одно время генерировать одинаковый хеш-ключ. Это может спровоцировать нарушение целостности баз, что приведет к невозможности восстановления созданной копии. Кроме этого, различные ошибки могут возникнуть при большом объеме данных.
Частые сложности возникают при применении службы Windows Server. Она существенно замедляет работу файлового сервера, так как во время процедуры файлы сначала копируются на диски и только после этого происходит проверка на дубликаты.
Область применения
Наверняка у многих возникает закономерный вопрос, зачем нужна дедупликация данных и можно ли обойтись без нее. Как показывает практика, рано или поздно все равно приходится прибегать к data deduplication. Со временем копии и дубликаты файлов могут заниматься в 2–3 раза больше места, чем оригинальные файлы, поэтому требуется удаление ненужных данных. Особенно часто процесс дедубликации используют разработчики на рынке резервного копирования.
Кроме этого, технология нередко применяется на серверах продуктивной системы. В этом случае процедура может выполняться средствами ОС или дополнительным программным обеспечением.
Что такое дедупликация данных
Данный обзор посвящен такой важной теме, как дедупликация данных. Разберем следующие вопросы: что такое дедупликация? как она работает? какие минусы и плюсы есть у этой технологии? А также рассмотрим практическое применение дедупликации в резервном копировании.
ДЕДУПЛИКАЦИЯ ДАННЫХ ЭТО
СПОСОБЫ ДЕДУПЛИКАЦИИ
Дедупликация на уровне блоков является самым распространенным способом дедупликации, который анализирует фрагмент данных (файл) и сохраняет только уникальные повторения каждого блока. Блок это логическая единица, поэтому он может иметь разный размер (длину). Все фрагменты данных обрабатываются с использованием хеш-алгоритма, такого как MD5 или SHA-1. Этот алгоритм создает и хранит в базе дедупликации идентификатор (сигнатуру) для каждого уникального блока.
Таким образом, если в течении жизненного цикла, файл изменился, в хранилище попадают только его изменённые блоки, а не весь файл, даже если изменилось только несколько байт.
Существует два вида блочной дедупликациий с постоянной и переменной длиной блоков. Дедупликация с переменной длиной, разбивает файлы на блоки разных размеров, что позволят получить более высокий коэффициент по уменьшению хранения данных, чем блоки фиксированной длины. К недостаткам дедупликации с переменной диной блоков относят более низкую скорость работы и создание большого количества метаданных.
Дедупликация на уровне байта по принципам своей работы похожа с дедупликацией на уровне блоков, только вместо блоков идет побайтное сравнение новых и измененных файлов. Этот метод является единственным методом, который гарантирует полное устранение дублирования данных, но он имеет очень высокие требования к производительности.
Делая вывод из вышесказанного, можно утверждать, что дедупликация на блочном уровне самые оптимальный способ, он значительно эффективнее, чем дедупликация на файловом уровне и не такой ресурснозатратный, как байтовый. Однако так же требует серьезной вычислительной мощности.
ДЕДУПЛИКАЦИЯ и РЕЗЕРВНОЕ КОПИРОВАНИЕ
Системы резервного копирования
В резервном копировании, по мимо выше описанных способов, дедупликация может отличаться по месту выполнения, на источнике данных (клиенте), на стороне устройства хранения (сервере) или как совместная работа клиент-сервера.
Дедупликация на стороне клиента выполняется непосредственно на источнике, поэтому используя только его вычислительные ресурсы. После выполнения дедупликации данные передаются на устройство хранения данных. Дедупликация на стороне клиента всегда реализована только с помощью программного обеспечения. Недостатком данного способа является высокая нагрузка на процессор и оперативную память клиента, а преимуществом возможность передачи данных по сетям с низкой пропускной способностью.
Дедупликация на стороне сервера возможна в случае, когда данные передаются на сервер полностью в необработанном (исходном) виде (без сжатия или кодирования). Дедупликация на сервере делится на аппаратную и программную. Аппаратная выполняется с помощью устройства дедупликации, которое является отдельным аппаратным решением, объединяющее логику дедупликации и восстановления данных. Преимуществом аппаратного способа является возможность передать всю нагрузку по выполнению дедупликации с сервера на отдельное устройство, и сделать саму дедупликацию полностью прозрачным процессом. Программная дедупликации использует специализированный софт, который берет всю работу по дедупликации на себя. Но в этом случае необходимо учитывать возникающую нагрузку на сервер для выполнения дедупликации.
МИНУСЫ ДЕДУПЛИКАЦИИ
Основной проблемой дедупликации является конфликт данных, который может возникнуть, если два различных блока генерируют один и тот же хэш-ключ. В этом случае возникает повреждение базы данных, что влечет сбой при восстановлении резервной копии. Чем больше база данных и выше частота изменений, тем вероятней возникновение конфликтных ситуаций. Решением данной проблемы может быть увеличение хэш пространства, так как, чем больше хэш ключей, тем меньше вероятность конфликта. На данный момент используют 160-битный ключ, генерируемый алгоритмом SHA-1. Это 2 160 =1.5 х 10 48 уникальных хэш-ключей.
ПЛЮСЫ ДЕДУПЛИКАЦИИ
На первом месте стоит эффективное использование места для хранения данных. По информации от компании EMC дедупликация данных в среднем снижает потребности в емкости хранения от 10 до 30 раз. Очевидно, это имеет большую экономическую выгоду. Так же дедупликацию выгодно использовать при низкой пропускной способности сети, так как передаются только уникальные данные. Касаемо резервного копирования дедупликация дает возможность чаще создавать резервные копии и хранить их более длительное время.
BACKUP EXEC DEDUPLICATION
Скачать
Рассмотрим более подробно настройку дедупликации на сервере Backup Exec для локального диска или диска презентованного дисковым массивом (без дедупликации на уровне массива). Для этого нам необходимо создать Storage c функцией дедупликации.
На этом настройку можно считать выполненной, остается только создать задания для бэкапа. Важно помнить, что на сервере Backup Exec может быть только один deduplication disk storage, это необходимо помнить при планировании резервного копирования.
В случае, когда используется устройство OpenStorage (с поддержкой дедупликации на стороне клиента) система позволяет выполнить дедупликацию на стороне клиента в обход сервера Backup Exec. Для этого необходимо открыть бэкап-задание нужного устройства и в свойствах на вкладке Storage указать «Enable the remote computer to directly access the storage device and to perform client-side deduplication, if it is supported».
Система Veritas Backup Exec предоставляет разные возможности для дупликации данных. Поэтому ещё на стадии проектирования системы резервного копирования важно тщательно подходить к планированию, а так же иметь полное представление о вашей инфраструктуре, понимать все узкие места. Всё это необходимо учитывать для оптимального и эффективного использования ресурсов, так как это может дать существенную экономию бюджета и выигрыш по скорости и глубине резервного копирования.
Дедупликация данных — подход 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 байт на сектор для организации своего механизма дедупликации данных.
Блок данных в 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 бесплатно, и обычно лицензия на ее активация поставляется по умолчанию с любой системой хранения, а если вам вдруг была продана система без нее, то вы можете получить ее бесплатно у вашего продавца.
Обзор и настройка средств дедупликации в Windows Server 2012
Всем доброго времени суток!
Сегодня хотелось бы провести обзор такой интересной новой фичи в Windows Server 2012 как дедупликация данных (data deduplication). Фича крайне интересная, но все же сначала нужно разобраться насколько она нужна…
А нужна ли вообще деупликация?
С каждым годом (если не днем) объемы жестких дисков растут, а при этом носители сами еще и дешевеют.
Исходя из этой тенденции возникает вопрос: «А нужна ли вообще дедупликация данных?».
Однако, если мы с вами живем в нашей вселенной и на нашей планете, то практически все в этом мире имеет свойство подчиняться 3-му закону Ньютона. Может аналогия и не совсем прозрачная, но я подвожу к тому, что как бы не дешевели дисковые системы и сами диски, как бы не увеличивался объем самих носителей — требования с точки зрения бизнеса к доступному для хранения данных пространства постоянно растут и тем самым нивелируют увеличение объем и падение цен.
По прогнозам IDC примерно через год в суммарном объеме будет требоваться порядка 90 миллионов терабайт. Объем, скажем прямо, не маленький.
И вот тут как раз вопрос о дедупликации данных очень сильно становится актуальным. Ведь данные, которые мы используем бывают и разных типов, и назначение у них могут быть разные — где-то это production-данные, где-то это архивы и резервные копии, а где-то это потоковые данные — я специально привел такие примеры, поскольку в первом случае эффект от использования дедупликации будет средним, в архивных данных — максимальным, а в случае с потоковыми данным — минимальным. Но все же экономить пространство мы с вами сможем, тем более что теперь дедупликация — это удел не только специализированных систем хранения данных, но и компонент, фича серверной ОС Windows Server 2012.
Типы дедупликации и их применение
Прежде чем перейти к обзору самого механизма дедупликации в Windows Server 2012, давайте разберемся какие типы дедупликации бывают. Предлагаю начать сверху-вниз, на мой взгляд так оно будет нагляднее.
1) Файловая дедупликация — как и любой механизм дедупликации, работа алгоритма сводится к поиску уникальных наборов данных и повторяющихся, где вторые типы наборов заменяются ссылками на первые наборы. Иными словами алгоритм пытается хранить только уникальные данные, заменяя повторяющиеся данные ссылками на уникальные. Как нетрудно догадаться из названия данного типа дедупликации — все подобные операции происходят на уровне файлов. Если вспомнить историю продуктов Microsoft — то данный подход уже неоднократно применялся ранее — в Microsoft Exchange Server и Microsoft System Center Data Protection Manager — и назывался этот механизм S.I.S. (Single Instance Storage). В продуктах линейки Exchange от него в свое время отказались из соображений производительности, а вот в Data Protection Manager этот механизм до сих пор успешно применяется и кажется будет продолжать это делать. Как нетрудно догадаться — файловый уровень самый высокий (если вспомнить устройство систем хранения данных в общем) — а потому и эффект будет самый минимальный по сравнению с другими типами дедупликации. Область применения — в основном применяется данный тип дедупликации к архивным данным.
2) Блочная дедупликация — данный механизм уже интереснее, поскольку работает он суб-файловом уровне — а именно на уровне блоков данных. Такой тип дедупликации, как правило характерен для промышленных систем хранения данных, а также именно этот тип дедупликации применяется в Windows Server 2012. Механизмы все те же, что и раньше — но на уровне блоков (кажется, я это уже говорил, да?). Здесь сфера применения дедупликации расширяется и теперь распространяется не только на архивные данные, но и на виртуализованные среды, что вполне логично — особенно для VDI-сценариев. Если учесть что VDI — это целая туча повторяющихся образов виртуальных машин, в которых все же есть отличия друг от друга (именно по этому файловая дедупликация тут бессильна) — то блочная дедупликация — наш выбор!
3) Битовая дедупликаия — самый низкий (глубокий) тип дедупликации данных — обладает самой высокой степенью эффективности, но при этом также является лидером по ресурсоемкости. Оно и понятно — проводить анализ данных на уникальность и плагиатичность — процесс нелегкий. Честно скажу — я лично не знаю систем хранения данных, которые оперируют на таком уровне дедупликации, но я точно знаю что есть системы дедупликации трафика, которые работают на битовом уровне, допустим тот же Citrix NetScaler. Смысл подобных систем и приложений заключается в экономии передаваемого трафика — это очень критично для сценариев с территориально-распределенными организациями, где есть множество разбросанных географически отделений предприятия, но отсутствуют или крайне дороги в эксплуатации широкие каналы передачи данных — тут решения в области битовой дедупликации найдут себя как нигде еще и раскроют свои таланты.
Очень интересным в этом плане выглядит доклад Microsoft на USENIX 2012, который состоялся в Бостоне в июне месяце. Был проведен достаточно масштабный анализ первичных данных с точки зрения применения к ним механизмов блочной дедупликации в WIndows Server 2012 — рекомендую ознакомиться с данным материалом.
Вопросы эффективности
Для того чтобы понять насколько эффективны технологии дедупликации в Windows Server 2012, сначала нужно определить на каком типе данных эту самую эффективность следует измерять. За эталоны были взяты типичные файловые шары, документы пользователей из папки «Мои документы», Хранилища дистрибутивов и библиотеки и хранилища виртуальных жестких дисков.
Насколько же эффективна дедупликация с точки зрения рабочих нагрузок проверили в Microsoft в отделе разработки ПО.
3 наиболее популярных сценария стали объектами исследования:
1) Сервера сборки билдов ПО — в MS каждый день собирается приличное количество билдов самых разных продуктов. Даже не значительно изменение в коде приводит к процессу сборки билда — и следовательно дублирующихся данных создается очень много
2) Шары с дистрибутивами продуктов на релиз — Как не сложно догадаться, все сборки и готовые версии ПО нужно где-то размещать — внутри Microsoft для этого есть специальные сервера, где все версии и языковые редакции всех продуктов размещаются — это тоже достаточно эффективный сценарий, где эффективность от дедупликации может достигать до 70%.
3) Групповые шары — это сочетание шар с документами и файлами разработчиков, а также их перемещаемые профили и перенаправленные папки, которые хранятся в едином центральном пространстве.
А теперь самое интересное — ниже приведен скриншот с томами в Windows Server 2012, на которых размещаются все эти данные.
Я думаю слова здесь будут лишними — и все и так очень наглядно. Экономия в 6 Тб на носителях в 2 Тб — термоядерное хранилище? Не так опасно — но столь эффективно!
Характеристики дедупликации в Windows Server 2012
А теперь давайте рассмотрим основные характеристики дедупликации в Windows Server 2012.
1) Прозрачность и легкость в использовании — настроить дедупликацию крайне просто. Сначала в мастере ролей в Windows Server вы раскрывайте роль File and Storage Services, далее File and iSCSI Services — а у же там включаете опцию Data Deduplication.
После этого в Server Manager вы выбираете Fike and Storage Services, клик правой кнопкой мыши — и там вы выбираете пункт «Enable Volume Deduplication». Спешл линк для любителей PowerShell. Все крайне просто. С точки зрения конечного пользователя и приложений доступ и работа с данными осуществляются прозрачно и незаметно. Если говорить про дедупликацию с точки зрения фаловой системы — то поддерживается только NTFS. ReFS не поддается дедупликации, ровно как и тома защищенные с помощью EFS (Encrypted Fike System). Также под дедупликацию не попадают фалы объемом менее 32 KB и файлы с расширенными атрибутами (extended attributes). Дедупликация, однако, распространяется на динамические тома, тома зашифрованные с помощью BitLocker, но не распространяется на тома CSV, а также системные тома (что логично).
2) Оптимизация под основные данные — стоит сразу отметить, что дедупликация — это не онлайн-процесс. Дедупликации подвергаются файлы, которые достигают определенного уровня старости с точки зрения задаваемой политики. После достижения определенного срока хранения данные начинают проходить через процесс дедупликации — по умолчанию этот промежуток времени равен 5 дням, но никто не мешает вам изменить этот параметр — но будьте разумны в своих экспериментах!
3) Планирование процессов оптимизации — механизм который каждый час проверяет файлы на соответствия параметрам дедупликации и добавляет их в расписание.
4) Механизмы исключения объектов из области дедупликации — данный механизм позволяет исключит файлы из области дедупликации по их типу (JPG, MOV, AVI — как пример, это потоковые данны — то, что меньше всего поддается дедупликации — если вообще поддается). Можно также исключить сразу целые папки с файлами из области дедупликации (это для любителей немецких фильмов, у которых их тьма-тьмущая).
5) Мобильность — дедуплицированный том — это целостный объект — его можно переносить с одного сервера на другой (речь идет исключительно о Windows Server 2012). При этом вы без проблем получите доступ к вашим данным и сможете продолжить работу с ними. Все что для этого необходимо — это включенная опция Data Deduplication на целевом сервере.
6) Оптимизация ресурсоемкости — данные механизмы подразумевают оптимизацию алгоритмов для снижения нагрузки по операциям чтения/записи, таким образом если мы говорим про размер хеш-индекса блоков данных, то размер индекса на 1 блок данных составляет 6 байт. Таким образом применять дедупликацию можно даже к очень массивным наборам данных.
Также алгоритм всегда проверяет достаточно ли ресурсов памяти для проведения процесса дедупликации — если ответ отрицательный, то алгоритм отложит процесс до высвобождения необходимого объема ресурсов.
7) Интеграция с BranchCache — механизмы индексация для дедупликация являются общими также и для BranchCache — поэтому эффективность использования данных технологий в связке не вызывает сомнений!
Вопросы надежности дедуплицированных томов
Вопрос надежности крайне остро встает для дедуплицированных данных — представьте, что блок данных, от корого зависят по-крайней мере 1000 файлов безнадежно поврежден… Думаю, валидол-эз-э-сервис тогда точно пригодится, но не в нашем случае.
1) Резервное копирование — Windows Server 2012, как и System Center Data Protection Manager 2012 SP1 полностью поддерживают дедуплицированные тома, с точки зрения процессов резервного копирования. Также доступно специальное API, которое позволяет сторонним разработчикам использовать и поддерживать механизмы дедупликации, а также восстанавливать данные из дедуплицированных архивов.
2) Дополнительные копии для критичных данных — те данные, которые имеет самый частый параметр обращения продвергаются процессу создания дополнительных резервных блоков — это особенности алгоритма механизма. Также, в случае использования механизмов Storage Spaces, при нахождение сбойного блока, алгоритм автоматически заменяет его на целостный из пары в зеркале.
3) По умолчанию, 1 раз в неделю запускается процесс нахождения мусора и сбойных блоков, который исправляет данные приобретенные патологии. Есть также возможность вручную запустить данный процесс на более глубоком уровне. Если процесс по умолчанию исправляет ошибки, которые были зафиксированы в логе событий, то более глубокий процесс подразумевает сканирование всего тома целиком.
С чего начать и как померить
Перед тем как включать дедупликацию, всегда нормальному человеку в голову придет мысль о том насколько эффективен будет данный механизм конкретно в его случае. Для этого вы можете использовать Deduplication Data Evaluation Tool.
После установки дедупликации вы можете найти инструмент под названием DDPEval.exe, который находится в \Windows\System32\ — данная утиль может быть портирована на сменный носитель или другой том. Поддерживаются ОС Windows 7 и выше. Так что вы можете проанализировать ваши данный и понять стоимость овечье шкурки. (смайл).
На этом мой обзор завершен. Надеюсь вам было интересно. Если у вас возникнут вопросы — можете смело найти меня в соц.сетях — ВКонтакте, Facebook — по имени и фамилии — и я постараюсь вам помочь.
Для тех, кто хочет узнать про новые возможности в Windows Server 2012, а также System Center 2012 SP1 — я всех приглашаю посетить IT Camp — 26 ноября, накануне TechEd Russia 2012 состоится данное мероприятие — проводить его будем я, Георгий Гаджиев и Саймон Перриман, который специально прилетает к нам из США.
Дедупликация данных
Дедупликация данных представляет собой процесс, при котором устраняются избыточные копии информации, в итоге снижая текущие расходы на хранение этой информации. С помощью этой технологии можно оптимизировать емкость любого хранилища данных.
Независимо от способа, дедупликация позволяет сохранять на носителях исключительно одну уникальную единицу информации. Поэтому, один из наиболее важных моментов в дедупликации — это уровень детализации.
У дедупликации данных есть несколько уровней выполнения:
- байты;
- файлы;
- блоки.
У каждого такого метода есть свои положительные и отрицательные стороны. Рассмотрим их подробнее.
Методы дедупликации данных
Уровень блоков
Считается наиболее популярным методом дедупликации, и подразумевает анализ части данных (файл), с дальнейшим сохранением лишь уникальных повторений информации для каждого отдельно взятого блока.
Блоком, при этом, считается одна логическая единица информации с характерным размером, который может варьироваться. Все данные при дедупликации на уровне блоков обрабатываются с применением хеширования (например, SHA-1 или MD5).
Хеш-алгоритмы позволяют создавать и хранить в базе дедупликации определенную сигнатуру (идентификатор), которая соответствует каждому отдельно взятому уникальному блоку данных.
Так, если на протяжении определенного времени файл будет изменен, то в хранилище данных попадет не цельный файл, а лишь его измененные блоки.
Есть 2 разновидности блочной дедупликации — с переменной и постоянной длиной блоков. Первый вариант подразумевает распределение файлов на блоки, каждый из которых может иметь разный размер.
Этот вариант более эффективный в плане уменьшения объема хранимых данных, чем при применении дедупликации с постоянной длиной блоков.
Уровень файлов
Такой метод дедупликации подразумевает сравнение нового файла с уже сохраненным. Если же попадается какой-либо уникальный файл, то он будет сохранен. Если же попавшийся файл будет не новым, то сохранится только ссылка (указатель на этот файл).
То есть, при таком виде дедупликации записывается исключительно один вариант файла, а все будущие его копии будут получать указатель на первоначальный файл. Главное преимущество такого способа — простота реализации без серьезного снижения производительности.
Уровень байтов
По своему принципу похож на первый в нашем списке рассматриваемый метод дедупликации, но вместо блоков тут используется сравнение старых и новых файлов по байтам. Такой способ — единственный, при котором можно гарантировать максимальное устранение дубликатов файлов.
Однако у дедупликации на уровне байтов есть и существенный минус: аппаратная составляющая машины, на которой запущен процесс, должна быть крайне мощной, так как к ней предъявляются более высокие требования.
Дедупликация данных и резервное копирование
Кроме всего вышеописанного, в процессе создания резервной копии данных дедупликация может выполняться разными методами по:
- месту выполнения;
- источнику данных (клиенту);
- стороне хранения (серверу).
Дедупликация клиент-сервер
Совмещенный метод дедупликации данных, при котором необходимые процессы могут запускаться как на сервере, так и на клиенте. Прежде, чем отправить данные с клиента на сервер, программное обеспечение вначале пытается «понять», какие данные уже записаны.
Для такой дедупликации изначально необходимо вычислить хеш у каждого блока данных, после чего отправить их на сервер в виде файла-списка различных хеш-ключей. На сервере же производится сравнение списка этих ключей, а затем клиенту отправляются блоки с данными.
Этот способ существенно снижает нагрузку на сеть, т. к. передаются исключительно уникальные данные.
Дедупликация на клиенте
Подразумевает выполнение операции непосредственно на источнике данных. Поэтому, при такой дедупликации будут задействованы вычислительные мощности именно клиента. После завершения процесса данные будут отправлены на устройства хранения информации.
Такой вид дедупликации всегда реализуется при помощи программного обеспечения. А главный минус описанного метода заключается в высокой нагрузке на ОЗУ и процессор клиента. Ключевое преимущество же кроется в возможности передачи данных по сети с низкой пропускной способностью.
Дедупликация на сервере
Используется в случае, когда данные поступают на сервер в полностью необработанном виде — без кодирования и сжатия. Такой вид дедупликации подразделяется на программный и аппаратный.
Аппаратный тип
Реализовывается на базе устройства дедупликации, которое предоставляется в виде определенного аппаратного решения, объединяющем логику дедупликации и процедуру восстановления данных.
Преимущество такого метода заключается в возможности передавать нагрузку с серверных мощностей на определенную аппаратную единицу. Сам процесс дедупликации при этом получает максимальную прозрачность.
Программный тип
Подразумевает использование специального программного обеспечения, которое, собственно, и выполняет все необходимые процессы дедупликации. Но, при таком подходе всегда необходимо учитывать нагрузку на сервер, которая будет возникать в процессе дедупликации.
Плюсы и минусы
К положительным сторонам дедупликации, как процесса, можно отнести следующие моменты: