Data Domain, сжатие, Compression FAQ

ЗАТРОНУТЫЕ РЕШЕНИЯ

• Все модули DDR
• Все выпуски

Сжатие. Часто задаваемые вопросы

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

• Метаданные занимают около 0,5% логического размера резервной копии. Предположим, что логический размер полной резервной копии составляет 100 Гбайт, а инкрементной — 2 Гбайт. Предположим, что инкрементное сжатие составляет 1 Гбайт. Тогда полная резервная копия займет не менее 1,5 Гбайт.
• Модуль сжатия Data Domain перезаписывает некоторые дублирующиеся сегменты данных для повышения производительности. Чем хуже расположения данных изменений, тем больше дубликатов записывается. Дубликаты позже восстанавливаются с помощью команды «filesys cleaning». Встречались случаи, когда примерно 2% от логического размера было переписано в виде дубликатов. Допуская такое соотношение дубликатов, полное заполнение может занять 1 Гбайт (сжато) + 0,5 Гбайт (метаданные) + 2 Гбайт (дубликаты) = 3,5 Гбайт. Объемом записанных дубликатов можно управлять при помощи системного параметра, но обычно мы пропускаем его настройку в поле.
• Сегментация данных может немного отличаться в разных резервных копиях в зависимости от порядка отправки данных клиентом NFS. Этот порядок не является детерминированным. В целом, алгоритм сегментации допускает сдвиги и перегруппировку данных. Однако он также создает некоторые «принудительные» сегменты, которые подвержены сдвигам и перегруппировке. Как правило, около 0,2% сегментов используются принудительно, поэтому можно ожидать, что используется гораздо больше пространства.

Команда «filesys show space» обеспечивает коэффициент сжатия на основе логического размера сохраненных данных и дискового пространства, используемого во время выполнения команды.

«filesys show compression» отображает коэффициент сжатия для каждого файла, учитывая способ сжатия, примененный при создании файла.

Команда «filesys show compression» в основном используется для поддержки и отладки. При наличии удалений файлов «filesys show compression» переоценивает коэффициент сжатия.

К примеру, допустим, что при первом полном резервном копировании выполняется 2-кратное сжатие. Последующее полное резервное копирование без изменений данных получает 200-кратное сжатие. Первая полная резервная копия удаляется. Команда «filesys show space» отображает 2-кратное сжатие. Теперь «filesys show compression» покажет коэффициент сжатия 200x, поскольку при создании единственного существующего теперь файла было выполнено 200-кратное сжатие.

В приведенном выше примере после второго резервного копирования «filesys show space» отобразит совокупный коэффициент сжатия около 4x. Совокупный коэффициент будет асимптотически улучшаться до 200 раз, если выполнять больше резервных копий без удаления.

Существуют и другие незначительные различия:

•  Команда «filesys show compression» не учитывает потери на уровне контейнера, поэтому коэффициент сжатия еще больше завышается
•  Команда «filesys show compression» не учитывает исключение дубликатов при глобальном сжатии, что занижает коэффициент сжатия
•  Команда «filesys show compression» может предоставлять информацию о каждом файле или каталоге, а «filesys show space» — только о всей системе
•  Команда «filesys show compression» обеспечивает распределение между глобальным и локальным сжатием, а «filesys show space» — нет

СПРАВОЧНЫЕ МАТЕРИАЛЫ

• Почему коэффициенты сжатия отличаются для «filesys show space» и «vtl tape show summary»?

Коэффициент сжатия, показанный в «vtl tape show summary», соответствует «filesys show compression /backup/vtc».

В более общем случае этой команде виртуальной ленточной библиотеки (VTL) может быть предоставлен дополнительный фильтр для выбора поднабора накопителей на магнитной ленте, и сжатие должно соответствовать «filesys show compression» в этом поднаборе.

Однако из-за ошибки в коде пользовательского интерфейса VTL сжатие, отображаемое в «vtl tape show Summary», является ошибочным. Это известная проблема, которая устранена в выпуске 4.5.0.0.
 

• Почему параметр «filesys show compression last 24 hours» не соответствует ожиданиям для VTL?

Для виртуальной ленточной библиотеки выходные данные команд, таких как «filesys show compression last 24 hours», часто не соответствуют ожиданиям на основе других источников, таких как «system show performance».

Проблема возникает из-за особенности «filesys show compression» (fsc). В целом, команда «filesys show compression» отображает суммарные статистические данные для выбранных файлов. Спецификатор «last 24 hours» выбирает файлы, которые были обновлены за последние 24 часа. Статистика по-прежнему накапливается с момента создания или последнего усечения файла до нулевого размера. Таким образом, если файл был добавлен в течение последних 24 часов, то «filesys show compression last 24 hours» будет отображать суммарную статистику за последние 24 часа.

В средах, отличных от VTL, файлы резервного копирования записываются только один раз, поэтому между обновленными и созданными файлами нет большого расхождения. С использованием VTL резервные копии могут быть добавлены к существующим файлам на магнитных лентах. Например, рассмотрим магнитную ленту емкостью 100 Гбайт, заполненную до 50 Гбайт. Если 10 Гбайт данных добавляется к этой ленте за последние 24 часа, «filesys show compression last 24 hours» отображает «Original bytes» файла в размере 60 Гбайт.
 

• Как вычисляется совокупный коэффициент сжатия?

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

Предположим, что сжатие в первой полной резервной копии равно 2x, а во второй полной резервной копии — 20x. Суммарное сжатие равняется не (2+20)/2, то есть с коэффициентом 11x, а 2/(1/2+1/20), то есть с коэффициентом 3,64x.

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

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

C = (общий логический размер)/(общее используемое пространство)
Общий логический размер = s1 + s2 + .. + sk
Общее используемое пространство = s1/c1 + s2/c2 + ... + sk/ck

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

К примеру, если первое полное резервное копирование получает 3-кратное сжатие, каждое последующее — 30-кратное сжатие, а срок хранения составляет 30 дней, пользователь видит совокупное сжатие 30/(1/3+29/30) или 23x.
 

• Как работает сжатие Data Domain?

Ответ на этот вопрос подробно описан в отдельной статье базы знаний «Понимание сжатия Data Domain» Data Domain. Понимание сжатия Data Domain
 

• Поддерживает ли Data Domain мультиплексирование? ​​​​​​​

Мультиплексированные данные из приложения резервного копирования приводят к очень низкой глобальной дедупликации. Дополнительные сведения см. в соответствующей статье «Мультиплексирование в ПО для резервного копирования не поддерживается» Data Domain: Мультиплексирование в программном обеспечении для резервного копирования. 
 

• Почему при репликации каталогов «один в один» реплика показывает лучшее глобальное сжатие?

Как правило, это происходит из-за различий в уровне повторяющихся сегментов, записанных в системе:

• Данные, хранящиеся в исходной системе, дедуплицировались один раз — в отношении к предыдущим данным, хранящимся в исходной системе.
• Данные, переданные по проводной сети, дедуплицировались один раз — в отношении данных, хранящихся в реплике.
• Данные, хранящиеся в реплике, дедуплицировались дважды: один раз при передаче данных по проводной сети и еще раз при записи полученных данных в реплику.

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

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

• Что изменилось в сжатии при использовании параметров локального сжатия lz, gzfast и gz?

filesys option set compression {none | lz | gzfast | gz}
 

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

Обычно порядок сжатия следующий:

Приблизительная разница:

• lz в gzfast обеспечивает примерно на 15 % лучшее сжатие и потребляет в 2 раза больше ресурсов ЦП
• lz в gz обеспечивает примерно на 30% лучшее сжатие и потребляет в 5 раз больше ресурсов ЦП
• gzfast в gz обеспечивает примерно на 10–15% лучшее сжатие

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

Если в системе заказчика ресурсов ЦП уже недостаточно, особенно если заказчик выполняет резервное копирование и репликацию одновременно, это может замедлить резервное копирование и/или репликацию. Заказчик может выразить явное желание зарезервировать время для выполнения этого преобразования.

Ссылки базы знаний:

• Решение проблем с переходом
• Data Domain. Понимание сжатия Data Domain