Поиск и устранение неисправностей, связанных с низкой дедупликацией и коэффициентом сжатия файлов в устройствах восстановления Data Domain (DDR)

Средства восстановления Data Domain (DDR) предназначены для хранения больших объемов логических (предварительно сжатых) данных, используя минимальное физическое (после сжатие) дисковое пространство. Для этого используются:

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

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

• Сценарий использования
• Типы данных, которые используются
• Конфигурация приложения резервного копирования

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

• DDR для быстрого исчерпания полезной емкости
• Влияние на производительность резервного копирования, восстановления или репликации
• Сбой DDR в удовлетворении ожиданий заказчиков

В этой статье рассматриваются следующие вопросы:

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

Как data Domain Restorer получает новые данные?

• Приложение резервного копирования отправляет данные (то есть файлы) в DDR.
• DDR разделяет эти файлы на фрагменты размером 4–12 Кбайт, каждый фрагмент отображается как «сегмент».
• DDR создает уникальный «отпечаток пальца» (аналогичный контрольной сумме) для каждого сегмента в зависимости от данных, содержащихся в сегменте.
• Отпечатки недавно созданных сегментов проверяются на индексах дисков на DDR, чтобы определить, содержит ли DDR сегмент с тем же отпечатком.
• Если модуль DDR уже содержит сегмент с тем же отпечатком пальца, соответствующий сегмент в недавно созданных данных является дубликатом и может быть пропущен (дедуплицированный).
• После удаления всех дублирующихся сегментов из новых данных остаются только уникальные или новые сегменты.
• Эти уникальные или новые сегменты сгруппированы в «области сжатия» размером 128 Кбайт, а затем сжимаются (по умолчанию используются алгоритмы lz ).
• Сжатые области сжатия упаковываются в единицы хранения размером 4,5 Мбайт, известные как «контейнеры», которые затем записываются на жесткий диск.

Как DDR отслеживает, какие сегменты делают определенный файл?

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

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

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

Как определить общий коэффициент сжатия в DDR?

Общий коэффициент использования DDR (и коэффициент сжатия) можно просмотреть с помощью команды «filesys show space». Например:

Active Tier:
Resource Size GiB Used GiB Use GiB% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 115367.8 - -
/data: post-comp 6794 2 6242.4 551.8 92% 202.5
/ddvar 49.2 9.1 37.6 20% -


---------------- -------- -------- --------- ---- -------------- в этом случае мы видим следующее:

• Предварительно сжатые или логические данные, которые удерживаются в DDR: 115367,8 Гбайт
• После сжатие или физическое пространство, используемое в DDR: 6242,4 Гбайт
• Общий коэффициент сжатия составляет 115367,8/6242,4 = 18,48

Выходные данные команды filesys show compression подтверждают сохраненные данные, используемое пространство и коэффициент сжатия. Пример.

                   Коэффициент коэффициента локального сжатия (GiB) (GiB) после сжатия после сжатия (Global-Comp Total-Comp
) (GiB)
(коэффициент сокращения %)

---------------- -------- --------- ----------- ---------- -------------ис использования:*   115367.8 6242.4 — 18,5x (94,6) <=== Примечание
. Запись:                                                                          
  Последние 7 дней 42214.7 1863.2 11.0x 2,1x 22,7x (95,6)
  Последние 24 ч 4924,8 274,0 8,8x 2,0x 18,0x (94,4)
---------------- -------- --------- ----------- ---------- -------------

Одиновые показатели использования DDR рассчитываются следующим образом:

• Общее количество предварительно сжатых данных: Сумма предварительно сжатого (логического) размера всех файлов, которые находятся в DDR.
• Общее количество данных после сжатия: Количество «контейнеров» на диске, умноженное на 4,5 Мбайт (размер одного контейнера).
• Общий размер после сжатия: Максимальное количество «контейнеров», которые создаются при наличии свободного дискового пространства в системе.

Статистика по максимальному объему используемой емкости в контейнерах доступна в autosupports. Например: набор контейнеров 73fcacadea763b48:b66f6a65133e6c73:
...


    attrs.psize = 4718592 <=== размер контейнера в байтах
...
    attrs.max_containers = 1546057 <===
Максимально возможные контейнеры attrs.free_containers = 125562 <===
В настоящее время бесплатные контейнеры attrs.used_containers = 1420495 <===
В настоящее время используются контейнеры...

См. следующее:
 
Как можно определить коэффициенты дедупликации и сжатия для отдельного файла, каталога или дерева каталогов?

При включении файла DDR записывает статистические данные о файле, в том числе:

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

Можно создать дамп некоторых из этих статистических данных с помощью команды «filesys show compression [path]», например для отчета статистики для одного файла:

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files: 1;  байт/storage_used: 2,9 исходных
байта:        3 242 460 364
глобально сжатые данные:        1 113 584 070
с локальным сжатием:        1 130 871 915 метаданных
:            4772 672

Чтобы отобразить

статистику для всего дерева каталогов SE@DDVE60_JF## filesys отображает сжатие /data/col1/backup
Total files: 3;  байт/storage_used: 1.4
Исходные байты:        7 554 284 280 Глобально сжатые
данные:        5 425 407 986 Локально
сжатые:        5 510 685 100
метаданных:           23 263 692

Обратите внимание, что при использовании этой статистики необходимо отметить несколько нюансов.

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

Поэтому эти показатели следует рассматривать только как оценки.

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

Может ли получение данных «низкого качества» привести к снижению общего коэффициента сжатия?

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

Предварительно сжатые/предварительно зашифрованные данные:

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

Из-за работы алгоритма сжатия или шифрования относительно небольшое изменение базовых данных файла приводит к изменениям в файле. Например, клиент может содержать зашифрованный файл размером 100 Мбайт, в котором изменены 10 Кбайт. Обычно полученный файл будет идентичен до и после изменения, кроме измененного раздела размером 10 Кбайт. При использовании шифрования, даже если до и после изменения изменился только 10 Кбайт незашифрованных данных, алгоритм шифрования приводит к изменению всего содержимого файла.

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

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

В качестве общего указания перед распаковка/предварительное шифрование приводит к следующим причинам:

• Предварительно зашифрованные данные: Низкий коэффициент дедупликации, но допустимый коэффициент сжатия
• Предварительно сжатые данные: Низкий коэффициент дедупликации и низкий коэффициент сжатия

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

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

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

Файлы носителей:

Некоторые типы файлов содержат предварительно сжатые или предварительно зашифрованные данные по конструкции. Пример.

• Файлы PDF
• Определенные аудиофайлы (mp3, wma, ogg и т. д.)
• Видео файлы (avi, mkv и т. д.)
• Файлы изображений (png, bmp, jpeg и т. д.)
• Файлы для конкретных приложений (Microsoft Office, Open Office, Libre Office и т. д.)

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

Файлы с высокой уникальности:

Достижение достаточного коэффициента дедупликации зависит от того, что DDR несколько раз видит один и тот же набор сегментов (и отпечаток сегментов). Однако некоторые типы данных содержат только уникальные транзакционные данные, которые по проекту содержат «уникальные» данные.

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

Примеры таких файлов:

• Журналы транзакций баз данных (например, журналы архивирования Oracle).
• Журналы транзакций Microsoft Exchange

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

Небольшие файлы:

Небольшие файлы вызывают различные проблемы при записи в DDR. К ним относятся:

• Раздутие метаданных — DDR начинает содержать больше метаданных файлов, чем ожидалось, по сравнению с физическими данными.
• Низкая эффективность использования контейнеров — по проекту (из-за архитектуры Data Domain Stream Informed Segment Layout или SISL, выходящих за рамки данного документа), контейнер 4,5 Мбит на диске содержит данные только из одного файла. В результате резервное копирование одного файла размером 10 Кбайт приводит, например, к записи по крайней мере одного полного контейнера размером 4,5 Мбайт для этого файла. Это может означать, что для таких файлов DDR использует значительно больше физического пространства после сжатия, чем соответствующее количество резервных копий (логических) данных, что, в свою очередь, приводит к отрицательному общему коэффициенту сжатия.
• Плохой коэффициент дедупликации. Файлы размером менее 4 Кбайт (минимальный поддерживаемый размер сегмента в DDR) состоят из одного сегмента, заполненного до 4 Кбайт. Такие сегменты не дедуплицируются, а записываются непосредственно на диск. Это может привести к тому, что DDR будет содержать несколько копий одного и того же сегмента (как дублирующиеся сегменты).
• Низкая производительность резервного копирования, восстановления или чистой производительности . При перемещении из одного файла в другой возникают большие издержки при резервном копировании, восстановлении или очистке (поскольку необходимо переключение контекста используемых метаданных).

См. следующее:

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

Несмотря на вышесказанное, следует избегать использования большого количества небольших файлов или рабочих нагрузок, состоящих в основном из небольших файлов. Перед резервным копированием лучше объединить большое количество небольших файлов в один несжатый/незашифрованный архив, чем отправлять небольшие файлы в DDR в их собственное состояние. Например, гораздо лучше выполнить резервное копирование одного файла размером 10 Гбит, 1048576 отдельные файлы размером 10 Кбайт, чем 1048576 файлы по отдельности.

Чрезмерное многоплекирование приложениями резервного копирования:

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

• Физическое ленточное устройство может поддерживать только один входящий поток записи.
• Приложение резервного копирования должно поддерживать достаточную пропускную способность ленточного устройства, чтобы предотвратить запуск, остановку или перемотку ленты (также известная как мигает) - Это проще, если поток, направляющийся на ленточное устройство, содержит данные, считываемых с нескольких клиентов.

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

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

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

• Приложения резервного копирования, использующие CIFS, NFS или OST (DDBoost), должны иметь увеличенное количество потоков записи (чтобы в DDR можно было параллельно записывать больше файлов).
• В средах, в которых используется виртуальная ленточная библиотека, необходимо добавить дополнительные диски в DDR, так как каждый диск поддерживает дополнительный параллельный поток записи.

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

Приложения резервного копирования, вставляя чрезмерное количество ленточных маркеров:

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

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

• В первом поколении резервного копирования было 12 Кбайт данных, которые были непрерывными. Это было распознано DDR как единый сегмент.
• Однако во втором поколении резервного копирования те же 12 Кбайт данных разделены путем включения маркера резервного копирования, который может быть представлен 6 Кбайт данных, маркер резервного копирования и 6 Кбайт данных.
• В результате сегменты, созданные во время второго поколения резервного копирования, не совпадают с сегментами, созданными во время первого поколения резервного копирования, поэтому они не дедуплицируются должным образом.

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

Чтобы избежать этой проблемы, DDR использует технологию распознавания маркеров, которая позволяет:

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

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

Однако, чтобы воспользоваться всеми преимуществами этой технологии, важно, чтобы DDR правильно распознала маркеры, вставленные в потоки резервного копирования. DDR ищет маркеры в зависимости от настройки параметра «marker type», например:

SE@DDVE60_JF## filesys show
Option Value
-------------------------------- --------
...
Marker-тип auto
...


-------------------------------- --------В этом случае следует оставить значение «автоматически», так как это позволит DDR автоматически соответствовать самым распространенным типам маркеров. Если система получает данные только из одного приложения резервного копирования, которое вставляет маркеры, возможно, будет преимуществом в производительности, указав определенный тип маркера, то есть:

# filesys option set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

См. что:

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

В результате Data Domain, как правило, рекомендует оставить для типа marker значение «auto». Для получения консультаций по изменению типа метки обратитесь к своему поставщику услуг технической поддержки.

Для систем, которые получает данные из приложений, которые используют маркеры резервного копирования, но которые не распознаются технологией автоматизированной обработки маркеров (например, с продуктами программного обеспечения BridgeHead), обратитесь к своему поставщику услуг поддержки по контракту, который затем может обратиться в службу поддержки Data Domain для определения необходимых параметров DDR для обнаружения нестандартного маркера.

Признаки «низкого качества» данных, получаемые DDR:

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

Глобальное сжатие	Локальное сжатие	Вероятной причиной
Низкий (от 1x до 4x)	Низкий (в 1–1,5 раза)	Предварительно сжатые или зашифрованные данные
Низкий (от 1 до 2)	Высокий (>в 2 раза)	Уникальные, но сжимаемые данные, например архивные журналы баз данных
Низкий (в 2–5 раз)	Высокий (>в 1,5 раза)	Маркеры, которые не обнаружены, или высокая скорость изменения данных или потоковое мультиплекирование.
Высокий (>в 10 раз)	Низкий (<в 1,5 раза)	Резервное копирование тех же сжатых или зашифрованных данных. Это редко.

Существуют ли определенные факторы в DDR, которые могут повлиять на общий коэффициент дедупликации?

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

Сбой регулярного выполнения очистки файловой системы:

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

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

• Обычная память DDR: Раз в неделю
• DDR с увеличенным сроком хранения: Раз в две недели

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

Чрезмерное количество старых снимков в системе:

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

• MTree содержит много файлов (поэтому предварительно сжатое использование является высоким).
• Создается снимок mtree.
• Многие файлы удаляются (что приводит к отключению предварительно сжатой загрузки).
• Очистка файловой системы выполняется. Обратите внимание, что минимальное пространство на жестком диске освобождается, так как копия удаленных файлов остается в моментальном снимке mtree. Это означает, что данные, на которые ссылается эти файлы, не могут быть удалены с диска.
• В результате после сжатие/физическое использование остается высоким

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

Дополнительные сведения о работе с моментальными снимками и расписаниями моментальных снимков доступны в следующей статье: Data Domain: управление расписаниями моментальных снимков

Чрезмерная задержка репликации:

Встроенная функция репликации Data Domain использует журнал репликации или моментальные снимки mtree (в зависимости от типа репликации) для отслеживания того, какие файлы или данные ожидают репликации в удаленную систему DDR. Задержка репликации — это концепция того, что реплика отстает от изменений исходной системы DDR. Это может произойти из-за различных факторов, включая:

• Отключение контекстов репликации
• Недостаточная пропускная способность сети между DDR
• Частые отключения сети.

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

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

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

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

• Уменьшение объема пространства на жестком диске, используемого файлами в DDR (например, увеличение агрессивности алгоритма сжатия, используемого DDR)
• Внезапное увеличение объема предварительно сжатых (логических) данных в DDR без соответствующего увеличения после сжатий/физического использования

Изменение алгоритма сжатия:

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

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

• Lz
• gzfast
• Gz

Ниже приведено общее сравнение каждого алгоритма.

• По сравнениюс gzfast , сжатие на 15% эффективнее и потребляет 2 ЦП.
• По сравнению с гц, сжатие на 30% эффективнее и потребляет 5-х ЦП.
• gzfast посравнению с gz обеспечивает сжатие примерно на 10–15%.

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

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

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

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

Использование fastcopy файловой системы:

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

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

Например, ниже приведены показатели использования DDR (указывающие общий коэффициент сжатия примерно в 1,8 раза):Активный уровень:

Размер ресурса GiB Used GiB Use GiB% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 12.0 - -
/data: post-comp 71.5 6.8 64.7 10% 0.0

/ddvar 49.2 1.1 45,6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

Содержит большой файл (/data/col1/backup/testfile):

!!! DDVE60_JF ЧТО ВАШИ ДАННЫЕ ПОД УГРОЗОЙ !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root 3221225472 29 июля 04:20 /data/col1/backup/testfile

Файл несколько раз fastcopied:

sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data /col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy3

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


Resource Size GiB Used GiB Use GiB% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 21.0 - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45,6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

Е результате DDR теперь показывает общий коэффициент сжатия примерно в 3,1 раза.

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

sysadmin@DDVE60_JF# filesys show compression /data/col1/backup/testfile_copy1
Total files: 1;  байт/storage_used: 21331976.1 Исходные
байты:        3 242 460 364
глобально сжатые данные:                    0
Локально сжатые:                    0
Метаданные:                  152

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