Что такое дедупликация в тинькофф

Обновлено: 19.04.2024

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

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

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

У каждого такого метода есть свои положительные и отрицательные стороны. Рассмотрим их подробнее.

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

Уровень блоков

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

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

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

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

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

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

Уровень файлов

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

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

Уровень байтов

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

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

Дедупликация данных и резервное копирование

Кроме всего вышеописанного, в процессе создания резервной копии данных дедупликация может выполняться разными методами по:

месту выполнения;
источнику данных (клиенту);
стороне хранения (серверу).

Дедупликация клиент-сервер

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

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

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

Такой вид дедупликации всегда реализуется при помощи программного обеспечения. А главный минус описанного метода заключается в высокой нагрузке на ОЗУ и процессор клиента. Ключевое преимущество же кроется в возможности передачи данных по сети с низкой пропускной способностью.

Дедупликация на сервере

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

Аппаратный тип

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

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

Программный тип

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

Плюсы и минусы

К положительным сторонам дедупликации, как процесса, можно отнести следующие моменты:

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

У каждого такого метода есть свои положительные и отрицательные стороны. Рассмотрим их подробнее.

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

Уровень блоков

Уровень файлов

Уровень байтов

Дедупликация данных и резервное копирование

месту выполнения;
источнику данных (клиенту);
стороне хранения (серверу).

Дедупликация клиент-сервер

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

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

Дедупликация на сервере

Аппаратный тип

Программный тип

Плюсы и минусы

К положительным сторонам дедупликации, как процесса, можно отнести следующие моменты:

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

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

Действительно, рост объема данных на терабайты в год у какой-нибудь крупной организации – сегодня вполне реальный сценарий. Но как быть с эффективным хранением и резервным копированием? Ведь в сутках есть максимум 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 потенциальные проблемы.

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

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

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

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

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

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

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

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

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

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

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

Не важно, являетесь ли вы администратором системы хранения уровня tier-1, архивного хранилища или all-flash гибридных систем хранения, вам будет интересно пройтись по мифам и легендам дедупликации, чтобы избежать досадных ошибок при проектировании или работе с вашими системами хранения.

Коэффициент сокращения данных: чудес не бывает

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

Дедупликация — это автоматический процесс, существующий на многих массивах известных производителей, но потенциальный коэффициент, который вы можете получить, отличается у массивов разного типа. В результате, например, если вам будет нужен массив на 100ТБ, а вы будете считать коэффициент 10:1, то и приобретете хранилище под 10ТБ, или, скажем, если вы будете оценивать коэффициент как 2:1, следовательно, приобретете хранилище на 50ТБ – в итоге, эти совершенно разные подходы, приводят к совершенно разной стоимости покупки! Вы должны на практике понять какой коэффициент вы можете получить на ваших продуктивных данных, прежде чем сделать выбор в пользу определенной модели с определенным объемом.

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

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

Миф1. Больший коэффициент дедупликации дает больше преимуществ для хранения данных

Верно ли утверждение, что если один вендор предлагает коэффициент дедупликации 50:1 это в пять раз лучше альтернативного предложения 10:1? Нужно проверять и сравнивать совокупную стоимость влдения! Дедупликация позволяет сократить требования к ресурсам, но какова потенциальная экономия объема? 10:1 позволяет уменьшить размер хранимых данных (reduction ratio) на 90%, в то время как коэффициент в 50:1 увеличивает этот показатель на 8% и дает 98% reduction ratio (см. график ниже). Но это только 8% разницы…

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

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

Рис. 1 Рост коэффициента дедупликации и сокращение объемов хранения

Миф2. Есть четкое определение термина «дедупликация»

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

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

Для систем хранения оперативных данных в массиве 3PAR разработан целый комплекс утилит и механизмов, позволяющий сократить объем данных на продуктивном массиве.
Этот комплекс носит название HPE 3PAR Thin Technologies и состоит из нескольких механизмов:

Рис. 2 Технологии Thin в массивах 3PAR

Миф3. Коэффициенты дедупликации на основном массиве такие же, как и на массиве с резервными копиями.

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

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

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

Если рассматривать продукты компании HPE, то в массивах для оперативного хранения HPE 3PAR поиск повторяющихся последовательностей (например, при инициализации виртуальных машин или создании снэпшотов) проходит «на лету» на специальной микросхеме ASIC, установленной в каждом контроллере массива. Этот подход позволяет разгрузить центральные процессоры массива для других, более важных, задач и дает возможность включить дедупликацию для всех типов данных, не боясь, что массив «просядет» под нагрузкой. Подробнее про дедупликацию на массиве 3PAR можно прочитать.

Рис.3 Дедупликация в массивах 3PAR выполняется на выделенной микросхеме ASIC

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

Рис. 4 Портфель систем резервного копирования HPE StoreOnce

Про преимущества систем резервного копирования StoreOnce можно почитать в других статьях.
Для заказчиков может быть интересно, что связка HPE 3PAR и StoreOnce позволяет упростить и ускорить процесс переноса данных с продуктивного массива на систему резервного копирования без использования ПО резервного копирования или выделенного сервера бэкапа. Такая связка получила название HPE StoreOnce RMC и подробнее о ней также можно почитать в нашей статье.

Миф4. Все данные одинаковы

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

Рис. 5 Оценка коэффициента дедупликации в зависимости от типов данных и политики резервного копирования

Миф5. Группировка несвязных типов данных повышает уровень дедупликации

В теории, вы можете смешивать совершенно разные типы данных в общем пуле хранения для дедупликации. Может возникнуть ощущение, что вы имеете очень большой набор уникальных данных и, следовательно, вероятность нахождения в этом пуле уже записанных ранее блоков или объектов будет велика. На практике же этот подход не работает между несвязанными типами данных, например, между БД и Exchange, поскольку форматы данных разные, даже если хранится один и тот же набор данных. Такой, все время растущий пул, становится более сложным и требует больше времени для поиска повторяющихся последовательностей. Лучшей практикой является разделение пулов по типу данных.

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

Рис.6 Зависимость коэффициента дедупликации от количества виртуальных машин в пуле и размеров блока данных.

Миф6. Ваше первое резервное копирование покажет вам ожидаемый коэффициент дедупликации.

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

График ниже показывает очень типичную кривую коэффициента дедупликации. Приложение, в этом графике — БД SAP HANA, но большинство приложений показывает схожую кривую. Ваше первое резервное копирование показывает определенную дедупликацию, но большая экономия достигается благодаря сжатию данных. Как только вы начинаете держать в пуле больше копий данных — коэффициент дедупликации пула начинает расти (голубая линия). Коэффициент индивидуального бэкапа взмывает вверх уже после создания второй копии (орнжевая линия), т.к. на блочном уровне первый и второй бэкап очень похожи.

Рис. 7 График роста коэффициента дедупликации при увеличении количества резервных копий (подробнее в документе).

Миф7. Вы не можете увеличить уровень дедупликации

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

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

Миф8. Нет возможности заранее спрогнозировать коэффициент дедупликации

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

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

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

Рис. 8 Изменение коэффициента дедупликации и объема занимаемых данных в зависимости от политики резервного копирования на данных конкретного заказчика

У компании HPE есть набор утилит и сайзеров, позволяющий спрогнозировать (с неким допущением) тот объем систем хранения, который необходим заказчикам.

И получить предварительную оценку:

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

Следует отметить, что современный рост объемов SSD и снижения стоимости хранения на 1ГБ на flash накопителях (а стоимость уже соответствует $1.5 за ГБ) отодвигают вопросы, связанные с эффективностью дедупликации на второй план для оперативного хранилища, но становятся все более актуальными для систем резервного копирования.

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

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

Дедупликация данных — это технология, при помощи которой обнаруживаются и исключаются избыточные данные в дисковом хранилище. В результате это позволяет сократить объёмы физических носителей для хранения тех же объёмов данных.
Дедупликация данных это одна из самых «горячих» тем в области систем хранения данных последних двух-трех лет. Ведь очевидно, что в том гигантском объеме данных, который сейчас приходится хранить современным системам хранения, неизбежно встречаются дубликаты и идентичные данные, за счет устранения которых можно было бы значительно сократить объемы хранения.
Пожалуй наибольшего успеха снискали реализации технологий дедупликации в области систем дискового резервного копирования (например EMC Avamar, Data Domain), однако компания NetApp первой объявила о возможности использования дедупликации для так называемых «primary storage», то есть основного, «боевого» хранилища активных данных, так как смогла предложить технологию дедупликации, практически не снижающую производительность его работы.
Сегодня я бы хотел рассказать как и за счет чего это удалось, и почему пока не получается у других.

Итак, дедупликация — это устранение дублирующихся данных при их хранении на дисках хранилища. Каким образом?
Под общим названием «дедупликация» может скрываться сразу целый ряд различных реализаций. Простейшая из них — реализация дедупликации на «файловом» уровне. Это то, что давно реализовано в «UNIX-like» файловых системах с помощью механизма «линков». Одна и та же физическая цепочка блоков может адресоваться из разных точек файловой системы. Если, к примеру, одна и та же стандартная библиотека используется без изменения множеством разных программ, то, вместо того, чтобы копировать один и тот же файл в десятки мест на диске, мы храним одну копию, а остальные заменяем на линк. Когда OS или приложение обращается к файловой системе за этим файлом, то файловая система прозрачно перенаправляет по линку это обращение к тому самому единственному экземпляру.

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

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

Если вы вспомните мою статью об основе всех систем хранения NetApp, файловой структуре WAFL, то увидите, почему NetApp так заинтересовалась дедупликацией. Ведь субфайловая, блочная дедупликация абсолютно естественно реализуется в терминах WAFL, где «всё есть линки» на блоки хранения.

Где же может применяться дедупликация?
Я уже упомянул хранилище резервных копий, и в этой области дедупликация применяется относительно давно и успешно (часто в резервные копии попадают одни и те же, мало измененные по содержимому, обширные файлы, пользовательские документы, в том числе в копиях, например в разных папках, разных пользователей,). Но есть и другие перспективные области применения.
Один из них — хранение данных виртуальных машин в среде серверной виртуализации VMware ESX, MS Hyper-V, Xen Server, и так далее.
Однако использовать для дедупликации методы, хорошо работающие с резервными копиями, чаще всего не получится. Никому не захочется заплатить за пространство катастрофическим падением производительности дискового хранилища, как это часто происходит.
То, что годится для бэкапов — не годится для primary storage.
Нужно не просто устранить дубликаты, но и сделать это таким образом, чтобы не пострадала производительность.

За счет чего дедупликация столь эффективна на данных виртуальных инфраструктур?
Приведу какой-нибудь наиболее вопиющий пример. Допустим, вы разворачиваете систему серверной виртуализации в среде VMware, и в датаcторах сервера ESX у вас находится десяток серверов Windows или Linux, каждый выполняющий свою собственную задачу. Все виртуальные машины одного типа, конечно же, развернуты из предварительно подготовленного «темплейта», содержащего эталонную OS, со всеми необходимыми патчами, настройками и сервис-паками.
Для создания нового сервера вы просто копируете этот темплейт, и получаете новую, уже настроенную и обновленную виртуальную машину, состоящую из файла индивидуальных настроек, и большого файла «виртуального диска», содержащего в себе все файлы «гостевой OS» и ее приложений.

Но при этом, на десяток таких виртуальных машин, вы имеете десяток почти полностью идентичных виртуальных дисков, с папками /Windows/System32 (или /usr) внутри, отличающихся всего в нескольких десятках килобайтов индивидуальных настроек в реестре и конфигурационных файлах.
Несмотря на то, что по содержимому они, формально, практически идентичны, каждая виртуальная машина своим «диском C:» займет на системе хранения свой десяток гигабайт. Помноженное на десять виртуальных машин это дает уже вполне весомую цифру.
Еще более вопиющие ситуации возможны в случае VDI (Virtual Desktop Infrasructure), где количество «виртуальных десктопов» может исчисляться сотнями, и все они, как правило, используют одну и ту же OS.

Практика использования дедупликации на данных файлов виртуальных дисков показывает, что результаты экономии пространства часто достигают 75-90% от изначально занятого объема, «без дедупликации».
Это довольно заманчиво, без особого риска и накладных расходов, не жертвуя производительностью, освободить на терабайте хранилища 750-900 гигабайт ранее занятого образами виртуальных машин объема.

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

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

Отказавшись от «онлайн»-дедупликации, той, что происходит непосредственно при поступлении данных, Что-то мы, безусловно, теряем.
Например, если мы записываем сильно дуплицированные данные, допустим 1TB, из которых 900GB — нули, нам придется сперва выделить на запись место, размером 1TB, заполнить его нашими «нулями на 90%», и лишь потом, в ходе процесса дедупликации, 90% этого пространства освободится.

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

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

Как же «физически» устроен использованный в NetApp механизм дедупликации?
Часто приходится слышать, что жесткие диски FC и SAS систем хранения NetApp используют «нестандартный размер сектора» равный 520, вместо 512 байт. «Нестандартный» в кавычках, потому что, как ни странно это прозвучит, но именно сектор в 520 байт (512b data + 8b CRC) на сегодня следует считать «стандартным», так как именно это значение утверждено «комитетом T10», организацией, занимающимся разработкой и утверждением стандартов в области SCSI. Увы, пока совсем немногие системы хранения последовали этому новому стандарту (кроме NetApp я знаю только EMC Clariion, а также системы highend-класса, такие как EMC Symmetrix и HDS USP), а использование такого формата сектора дает много правильных и полезных бонусов в работе, вводя дополнительную защиту против неотслеживаемых на уровне RAID повреждений содержимого записанного сектора. Вероятность таких ошибок весьма невысока, но все же ненулевая.
Однако, помимо этой защиты, NetApp использует такие дополнительные 8 байт на сектор для организации своего механизма дедупликации данных.

(pic)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор статьи

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: