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



Введение В сфере непрерывности бизнеса существует множество различных проблем, связанных с быстрым ростом объема данных в современных ИТ-инфраструктурах.

На мой взгляд, есть два основных:

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

А как насчет эффективного хранения и резервного копирования? Ведь в сутках максимум 24 часа и окно резервного копирования не может расти бесконечно (в отличие от самих данных).

Сегодня я хочу поговорить о том, как дедупликация может помочь уменьшить эту проблему.



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



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

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

    Когда люди говорят о дедупликации на уровне файлов, они часто упоминают также технологию Единовременное хранилище (SIS) .

  • Дедупликация на уровне блоков (блочная дедупликация) — здесь единицей дедупликации является блок данных произвольной длины, который часто повторяется в различных логических объектах системы хранения данных.

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

Что такое СИС? Суть метода проста, например, если есть 2 абсолютно одинаковых файла, то один из них заменяется ссылкой на другой.

Этот механизм успешно работает на почтовых серверах (например, Exchange) и в базах данных.

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

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

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

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

Система дедупликации поддерживает хеш-таблицу для всех хранящихся в ней блоков данных.

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

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

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

В связи с этим существует два метода дедупликации блоков: с постоянный (заранее задано) и переменная (динамически выбирается для конкретных данных) длина.



Применение дедупликации

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

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

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

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

Другой способ использования дедупликации — использовать ее на рабочих серверах.

Это можно сделать с помощью самой ОС, дополнительного программного обеспечения или оборудования для хранения данных.

Здесь требуется осторожность, например, Windows 2008, ОС, позиционируемая как способная к дедупликации данных, делает только SIS. При этом системы хранения могут выполнять дедупликацию на уровне блоков, представляя пользователю файловую систему в развернутом (исходном) виде, скрывая все детали, связанные с дедупликацией.

Предположим, что в системе хранения имеется 4 ГБ данных, дедуплицированных до 2 ГБ.

Другими словами, если пользователь обратится к такому хранилищу, он увидит 4 ГБ данных и именно такой объем данных будет помещен в резервные копии.



Снижение интереса и большие надежды

Процент сэкономленного дискового пространства — это наиболее важная область, которой легко манипулировать, когда говорят о «уменьшении размера файлов резервных копий на 95 %».

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

Первая переменная, которую следует учитывать, — это типы файлов.

Такие форматы, как ZIP, CAB, JPG, MP3, AVI, уже представляют собой сжатые данные, которые обеспечивают более низкий коэффициент дедупликации, чем несжатые данные.

Не менее важна частота изменения данных для дедупликации и объем архивируемых данных.

Если вы используете продукт, который выполняет дедупликацию существующих данных на файловом сервере, не волнуйтесь.

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

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

Как видите, процент зависит от многих факторов и в теории достигает 95%, но на практике может достигать лишь нескольких процентов.



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

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

Существует три основных типа дедупликации:

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


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

Он запускается на самом устройстве, где находятся исходные данные.

Любые данные, помеченные для резервного копирования, разбиваются на блоки и для них вычисляется хэш.

Здесь следует обратить внимание на 3 потенциальные проблемы.

  1. Первая проблема в том, что здесь задействованы ресурсы исходной машины .

    Поэтому вам необходимо убедиться, что у него достаточно ресурсов ЦП и ОЗУ.

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

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

  2. Вторая проблема: где лучше всего хранить хеш-таблицы? Вы можете разместить хеш-таблицы на том же исходном сервере или на централизованном сервере в сети (это необходимо сделать, если используется глобальная дедупликация), однако данное решение создает дополнительную нагрузку на сеть .

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



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

Как только данные поступят, репозиторий может создать хеш-таблицу с блоками этих данных.

Первое преимущество этого метода — больший объем данных, причем чем больше пул данных, тем больше будет хеш-таблица и соответственно больше шансов найти одинаковые блоки.

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

Однако этот вариант не решает всех проблем.

Есть некоторые моменты, которые необходимо принять во внимание.

  1. Первый - зависимость от свободного места .

    Если у вас большая инфраструктура, необходимое пространство может быть очень большим.

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

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

    Это делает дисковую подсистему узким местом архитектуры.

  3. Третий недостаток может заключаться в том, что Каждая хэш-функция имеет вероятность хеш-коллизии.

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

    Это приводит к повреждению исходных данных.

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

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

    Надо сказать, что вероятность коллизий хэшей с современными хеш-функциями довольно мала.

  4. Четвертый потенциальный недостаток заключается в том, что весь объём данных с "производства" должен быть передан через сеть не создавая значительной нагрузки на сеть и саму производительную систему.

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



Транзитная дедупликация
Транзитная дедупликация объясняет процесс, который происходит во время передачи данных от источника к цели.

Этот термин немного сбивает с толку.

Данные фактически не дедуплицируются «в проводном режиме».

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

Это исключает время поиска на диске.

Транзитную дедупликацию можно рассматривать как лучшую форму целевой дедупликации.

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

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

Этот метод требует больше всего вычислительных ресурсов (процессора и памяти) среди всех перечисленных.



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

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

Следует внимательно выбирать тип дедупликации.

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



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

[1] Оригинальная статья (англ.

) [2] Статья в блоге Veeam: Как добиться невероятных результатов дедупликации с помощью Windows Server 2012 и Veeam Backup & Replication! [3] Видео (на английском языке): Рекомендации по дедупликации с MS Windows Server 2012 и Veeam Backup & Replication 6.5 [4] Встроенные возможности сжатия и дедупликации в Veeam Backup & Replication. Теги: #Виртуализация #Системное администрирование #Резервное копирование #Хранение данных #Системы хранения #дедупликация

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.