Дедупликация данных что это

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Понимание процесса дедупликации данных

область применения: Windows server 2022, Windows server 2019, Windows Server 2016, Azure Stack хЦи, версия 20H2

В этом документе описывается, как работает дедупликация данных.

Как работает дедупликация данных

Дедупликация данных для Windows Server разрабатывалась на основе двух важнейших принципов.

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

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

После включения дедупликации данных для тома она выполняет в фоновом режиме следующие задачи:

Этот процесс выполняется в четыре этапа:

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

Типы использования

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

Задания

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

Глоссарий дедупликации данных

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

Часто задаваемые вопросы

Чем отличается дедупликация данных от других средств оптимизации? Есть несколько важных различий между дедупликацией данных и другими распространенными решениями для оптимизации хранения.

Чем отличается дедупликация данных от хранилища единственных копий? Хранилище единственных копий (SIS) является предшественником технологии дедупликации данных и впервые было представлено в выпуске Windows Storage Server 2008 R2. Для оптимизации тома хранилище единственных копий выявляло в нем полностью идентичные файлы и заменяло их логическими ссылками на одну копию такого файла, размещенную в общем хранилище SIS. В отличие от хранилища единственных копий, дедупликация данных способна уменьшить пространство, занимаемое файлами, которые не полностью идентичны, но имеют некоторые одинаковые элементы, а также файлами, в которых встречается много повторяющихся элементов. Хранилище единственных копий считается устаревшим начиная с выпуска Windows Server 2012 R2, а в Windows Server 2016 его полностью заменила дедупликация данных.

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

Чем отличается дедупликация данных от форматов архивации файлов, таких как ZIP, RAR, 7Z, CAB и т. д.? Форматы ZIP, RAR, 7Z, CAB и другие выполняют сжатие для определенного набора файлов. Как и в случае с дедупликацией данных, оптимизируются повторяющиеся фрагменты внутри файлов и в разных файлах. Однако вам необходимо выбрать файлы, которые должны быть включены в архив. Семантика доступа также отличается. Чтобы получить доступ к определенному файлу в архиве, необходимо открыть архив, выбрать файл, а затем распаковать его для использования. Дедупликация данных работает незаметно для пользователей и администраторов, не требуя никаких ручных операций. Кроме того, дедупликация данных сохраняет семантику доступа — оптимизированные файлы выглядят для пользователя точно так же, как и раньше.

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

Можно ли вручную запускать задания дедупликации данных? Да, все задания дедупликации данных можно запускать вручную. Это удобно, если запланированное задание не было выполнено из-за недостатка системных ресурсов или ошибки. Кроме того, есть специальное задание отмены оптимизации, которое запускается только вручную.

Можно ли просмотреть историю запусков заданий дедупликации данных? Да, все задания дедупликации данных создают записи в журнале событий Windows.

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

Источник

Обзор дедупликации данных

область применения: Windows server 2022, Windows server 2019, Windows Server 2016, Azure Stack хЦи, версия 20H2

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

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

KB4025334 содержит сведение исправлений для дедупликации данных, включая важные исправления надежности, и настоятельно рекомендуется устанавливать его при использовании дедупликации данных с Windows Server 2016 и Windows Server 2019.

Преимущества дедупликации данных

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

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

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

Источник

8 мифов о дедупликации

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

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

Не важно, являетесь ли вы администратором системы хранения уровня 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 есть набор утилит и сайзеров, позволяющий спрогнозировать (с неким допущением) тот объем систем хранения, который необходим заказчикам.

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

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

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

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

Источник