Введение в дедупликацию данных

Введение

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

1. Как запланировать место для хранения большого объема данных
2. Как сделать резервную копию этих данных

Действительно, рост объема данных на терабайты в год у какой-нибудь крупной организации – сегодня вполне реальный сценарий. Но как быть с эффективным хранением и резервным копированием? Ведь в сутках есть максимум 24 часа и окно резервного копирования не может расти бесконечно (в отличие от самих данных). Сегодня я хочу рассказать, как дедупликация может помочь уменьшить остроту этой проблемы.

Дедупликация

В широком смысле, существует два основных вида дедупликации:

• File-level deduplication (дедупликация на уровне файлов) — единицей дедупликации в данном методе, как несложно понять, является отдельный файл, когда дублирующие файлы исключаются из системы хранения данных. Когда говорят о дедупликации на уровне файлов, часто также упоминают технологию Single-Instance Storage (SIS).
• Block-level deduplication (блочная дедупликация) – здесь единицей дедупликации является блок данных произвольной длины, который часто повторяется в различных логических объектах системы хранения данных.

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

Что такое SIS? Суть метода проста, например, если существуют 2 файла, которые абсолютно идентичны, то один из них заменяется ссылкой на другой. Такой механизм успешно работает в почтовых серверах (например, Exchange) и в базах данных. Например, если один пользователь корпоративной почты отправит письмо с прикрепленным файлом нескольким адресатам, то этот файл будет сохранен в базе Exchange только один раз.

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

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

Области применения дедупликации

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

Другой способ использования дедупликации – использование ее на серверах продуктивной системы. Это может быть сделано средствами самой ОС, дополнительным ПО или аппаратурой хранилища данных (СХД). Здесь требуется внимательность, например, Windows 2008 — ОС, позиционируемая, как способная производить дедупликацию данных, делает только SIS. В тоже время СХД могут производить дедупликацию на блочном уровне, представляя файловую систему для пользователя в развернутом (оригинальном) виде, скрывая все детали связанные с дедупликацией. Предположим, что на СХД есть 4 ГБ данных, дедуплицированных до 2 ГБ. Иными словами, если пользователь обратится к такому хранилищу, он увидит 4 ГБ данных и именно такой их объем будет помещен в резервные копии.

Сокращенные проценты и большие надежды

Процент сохраненного места на диске – наиболее важная область, которой легко манипулируют, говоря о “95% уменьшении размеров файлов резервного копирования”. Однако, алгоритм, используемый для подсчета этого соотношения, может быть не вполне релевантным к вашей конкретной ситуации. Первую переменную, которую следует принять во внимание, – это типы файлов. Такие форматы, как ZIP, CAB, JPG, MP3, AVI – это уже сжатые данные, которые дают меньший коэффициент дедупликации, чем несжатые данные. Не менее важна частота изменения данных для дедупликации и количество архивных данных. Если вы используете продукт, который дедуплицирует существующие данные на файловом сервере, то не стоит переживать. Но если дедупликация используется, как часть системы резервного копирования, то нужно ответить на следующие вопросы:

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

Дедупликацию легко рассчитать online с помощью специальных калькуляторов, но таким образом нельзя представить, какой она будет в вашей конкретной ситуации. Как можно заметить, процент зависит от множества факторов и в теории достигает 95%, но на практике может достигать только нескольких процентов.

Время – наше все

Говоря о дедупликации в системах резервного копирования, нам важно знать, как быстро она выполняется. Существует три основных типа дедупликации:

• source (на стороне источника данных);
• target (или «пост-обработка дедупликации»);
• непрерывная (или «транзитная дедупликация»);

Первый тип: Дедупликация на стороне источника данных

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

1. Первая проблема в том, что здесь задействованы ресурсы исходной машины. Поэтому нужно убедиться, что у нее имеется достаточно ресурсов процессора и оперативной памяти. Нет никакой разумной причины выполнять дедупликацию на уже нагруженном почтовом сервере. Конечно, некоторые производители говорят о легкости их решений, но это не отменяет тот факт, что эффективность работы исходной среды будет затронута, и это может быть неприемлемо.
2. Вторая проблема – где лучше хранить хеш-таблицы? Можно располагать хеш-таблицы на том же source-сервере, либо на централизованном сервере в сети (это необходимо сделать в случае, если применяется глобальная дедупликация), однако такое решение создает дополнительную нагрузку на сеть.
3. Несмотря на свои минусы, source дедупликация имеет свое право на применение, например, в компаниях с малым размером ИТ-инфраструктуры, где в инфраструктуре несколько серверов, нерационально использовать глобальную дедупликацию.

Target (или пост-процессная) дедупликация

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

Однако этот вариант не решает все проблемы. Есть некоторые моменты, которые должны быть приняты во внимание.

1. Первое – зависимость от свободного места. Если у вас обширная инфраструктура, то размер требуемого места может быть очень большим.
2. Также второй недостаток target дедупликации – требовательность к дисковой подсистеме репозитория. Обычно данные должны быть записаны на диск репозитория перед разбивкой на блоки, и только потом начинается процесс хеширования и дедупликации. Это делает дисковую подсистему узким местом архитектуры.
3. Третий недостаток может быть в том, что у каждой хеш-функции есть вероятность хеш-коллизии, то есть ситуации, когда для двух разных блоков вычисляется один и тот же хеш. Это приводит к повреждению оригинальных данных. Для предотвращения необходимо выбирать хеш-алгоритм с минимальной вероятностью коллизий, что в свою очередь требует бОльшей вычислительной мощности. Обычно, это не проблема, так как для target дедупликации используется аппаратное обеспечение, способное справляться с такой нагрузкой. Надо сказать, что вероятность хеш-коллизий современных хеш-функций довольно мала.
4. Четвертый потенциальный недостаток в том, что полный объем данных из «продакшн» должен быть передан через сеть без создания существенной нагрузки на сеть и саму продуктивную систему. Это может быть решено использованием ночных или других менее загруженных часов для системы, либо изолированием этого трафика в другую сеть (что является распространенной практикой в средних и крупных компаниях).

Транзитная дедупликация

Транзитная дедупликация объясняется, как процесс, происходящий в течение переноса данных из source на target. Термин немного сбивает с толку. Данные на самом деле не дедуплицируются «в проводе». На самом деле это значит, что данные, собранные в оперативной памяти target устройства, дедуплицируются там перед операцией записи на диск. Это выводит время поиска диска из уравнения. Транзитная дедупликация может рассматриваться как лучшая форма target дедупликации. Она имеет все преимущества глобального представления данных наряду с разгрузкой процесса хеширования, но ни одного из недостатков медленного I/O дисков.

Однако она все еще представляет большой сетевой трафик и потенциальные хеш-коллизии. Этот метод требует наибольших вычислительных ресурсов (процессора и памяти) среди всех перечисленных.

Подведение итогов

Технологии дедупликации могут помочь снизить затраты на покупку систем хранения. Следует продуманно выбирать тип дедупликации. В конечном счете, дедупликация позволит компании медленнее наращивать расходы на хранение своих растущих данных.

Полезные материалы

[1] Оригинальная статья (англ. яз.)
[2] Статья в блоге Veeam (англ. язык): How to Get Unbelievable Deduplication Results with Windows Server 2012 and Veeam Backup & Replication!
[3] Видео (англ. язык): Deduplication best practices with MS Windows Server 2012 and Veeam Backup & Replication 6.5
[4] Встроенная компрессия и дедупликация в Veeam Backup & Replication

Автор: anoronn

Источник