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

  • Tutorial

Введение


В области обеспечения непрерывности бизнеса существует много различных проблем, связанных с быстрым ростом данных в современных 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

Veeam Software
122,45
Продукты для резервного копирования информации
Поделиться публикацией

Комментарии 10

    0
    Очень жаль, что в Veeam дедупликация реализована на уровне непрерывных архивов в WinRAR.
    В то время как конкуренты используют полноценную блочную дедупликацию всего хранилища резервных копий.
      0
      Возьмём конкурентов с самой достойной дедупликацией, к примеру VMware VDP и EMC Avamar. У VDP дедупликация «для всего хранилища», но размер хранилища ограничен 2TB. У Avamar тоже дедупликация «для всего хранилища», но размер хранилища ограничен 8TB. И сравним это с Veeam: маркетингово Вы правы, дедупликация у нас не для всего хранилища резервных копий, а только внутри одной задачи резервного копирования (одного архива). Но в тоже время, размер задачи не ограничен (то есть может быть к примеру 64TB, и даже 128TB – что сильно больше 8TB). То есть можно весь ЦОД при желании в одну задачу положить, и дедуплицировать между всем вообще. Вывод о реальной глобальности дедупликации напрашивается сам?
        0
        Почему не сравнить с CommVault, IBM или Unitrends (ваш прямой конкурент)?

        То есть можно весь ЦОД при желании в одну задачу положить, и дедуплицировать между всем вообще.

        Какой в этом случае будет RTO? И как разделять сервисы с разным RPO?
          0
          Собственно, не имею ничего против Veeam.
          У вас отличное решение для резервного копирования, но оно не идеально и в некоторых аспектах уступает конкурентам.
            0
            Насчёт идеала, он не возможен. Для каждой проблемы есть только одно наилучшее решение, при этом разные поставщики решают разные проблемы, наиболее актуальные для их рыночного сегмента. Соответственно принимаются некие архитектурные решения, у каждого из которых есть свои плюсы и минусы.

            Например, мы изначально решили, что бакап должен быть файлом, который можно легко скопировать и унести. А не дедупликационным хранилищем, «пришитым» к СХД намертво. Для нас плюсы этого подхода (мобильность, portability) перевешивают минусы. А глобальность дедупликации всегда можно при желании добиться, храня все резервные копии на железке со встроенной дедупликацией. Например, тот же Windows Server 2012 со включенной дедупликацией вполне пойдёт, если размеры данных не слишком большие.
            0
            Просто потому, что я не в курсе ограничений у названных вами решений. У них похуже дедупликация, поэтому плотно ими не интересовался, так что боюсь наврать. Хотел лишь подчеркнуть, что у многих голова замылена маркетинговом «глобальности», когда в реальности она вообще не глобальна (как говорится, те же яйца, вид сбоку). 8 хранилищ по 8TB равняется 8 задач по 8 TB.

            По Вашим вопросам:
            1. На RTO никак не (в случае Veeam, по-крайней мере).
            2. Насчёт RPO Вы теоретически правы, вот только серьёзных инфраструктурах с десятками TB чаще чем раз в сутки VMware сложно бакапить из-за проблем коммита снапшотов в бизнес часы.
            3. Unitrends не конкурент, это только они так считают. В реальности же, у них менее 5000 клиентов за 25 лет — у нас больше 80000 за 6 лет. Мы их не встречаем в шорт листах никогда.
            0
            Как я понимаю, все механизмы дедубликации предполагают, что сравниваемые данные выравнены на границу блока (сектора блочного устройства например или больше) или даже целого файла.

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

            p.s. какие есть решения для дедупликации данных в сетевом трафике? грубо говоря передавать bzdiff от данных, которые ранее уже были переданы. Особенно это весело когда каждый пакет данных отличается на доли процента.
              0

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

                0
                хех, я тут пронекропостил по ошибке а кто то отреагировал.

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

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое