Data Domain. Объем очистки — это оценка

Часто возникает путаница с значением «Очищаемые ГиБ», представленным в системе Data Domain, и неправильными ожиданиями относительно объема пространства, которое будет восстановлено при выполнении очистки.

Приведенное число «Очищаемые ГиБ» является приблизительным, и невозможно получить точное значение того, какой объем пространства будет восстановлен при выполнении очистки, из-за технологических решений, принятых при разработке файловой системы Data Domain.

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

При приеме данных системой Data Domain значение после сжатия вычисляется и сохраняется в виде статических данных для каждого файла. Значение «Cleanable» — это просто сумма значений после сжатия для всех удаленных файлов с момента последнего запуска очистки DD до завершения.
 

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

Более подробный пример, показывающий этот эффект, приведен ниже:

Предположим, что у вас есть 5 файлов, добавленных один за другим в систему Data Domain, без каких-либо других данных.

Поскольку первые файлы размером 100 ГБ содержали все уникальные данные, их коэффициент сжатия равен 1x (при условии, что первый файл не имел избыточности в самом файле). Для 2-го и 5-го файлов была выполнена дедупликация данных 1-го файла и каждого из старых файлов по мере их добавления, причем каждый из них получал все большую дедупликацию из-за увеличения количества файлов, подлежащих дедупликации.

File 1: precomp: 100 GB postcomp: 100 GB compression ratio: 1x
File 2: precomp: 100 GB postcomp:  50 GB compression ratio: 2x
File 3: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 4: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 5: precomp: 100 GB postcomp:   1 GB compression ratio: 100x

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         500           -      -                -
/backup: post-comp      1000         201         799    20%                0
----------------   ---------   ---------   ---------   ----   --------------

Пример 1. Состояние после удаления первых 3 файлов из /backup :
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         200           -      -                -
/backup: post-comp      1000         201         799    20%              175
----------------   ---------   ---------   ---------   ----   --------------

Если вы запустите очистку после этого, вы сможете восстановить 125 вместо полных 175 для очистки. Это связано с тем, что последние 2 файла делят сегменты с файлами 1-3.  Очистка не восстановит оставшиеся 50 Гбайт пространства, так как эти сегменты все еще используются файлами 3–5.
 

Пример 2 Используя ту же отправную точку, что и в примере 1, предположим, что был удален файл 1, затем выполняется быстрая копия для всей папки /backup (т. е. всех 5 файлов), затем удаление файлов 2–4. 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         201         799    20%              200
----------------   ---------   ---------   ---------   ----   --------------

Значение "Размер ГиБ" для pre-comp составляет (500-100)=400*2=800, что дает 500 для 5 исходных файлов, вычитание 100 для удаления файла 1 дает 400 ГиБ.  Далее 400 ГиБ умножаются на 2 за счет быстрой копии на всех 4 оставшихся файлах.

Обратите внимание, что используемое пространство после сжатия остается прежним, поскольку копия файла добавляет лишь небольшое количество пространства, состоящее из указателей метаданных на исходные данные. Использование пространства не изменилось несмотря на удаление файла 1, так как не было выполнено «fileys clean start» (для запуска очистки). 
 

После очистки мы увидим:
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         176         824    18%                0
----------------   ---------   ---------   ---------   ----   --------------

Обратите внимание, что, несмотря на то, что 200 ГБ было показано как поддающееся очистке, на самом деле было очищено только 25 ГБ. Параметр «Очищаемый ГиБ» отображался как 200, так как размер файлов с 1 по 4 после создания композиции в сумме составлял 200 Гбайт.  Был удален только файл 1, который составлял 100 Гбайт, но 75 Гбайт из которого по-прежнему использовались остальными 4 файлами (из-за дедупликации).  

Это может показаться странным, так как файлы с «File 2» по «File 4» также были удалены, но помните, что, хотя система будет отображать «Файлы 2» по «File 4» как удаленные, фактические сегменты данных для этих файлов не могли быть удалены, потому что эти файлы были быстро скопированы в другую папку.   Только после того, как все версии быстрой копии будут удалены, пространство может быть полностью восстановлено путем очистки.

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

Это может привести к путанице при том, следует ли разрешить выполнение запланированной очистки DDFS или выполнить ее вручную, если использование пространства DDFS приближается к 100% из-за того, что значение Cleanable GiB отображается рядом или совпадает с «/data: post-comp».

Чтобы иметь лучший и более надежный способ оценки объема дискового пространства, которое очистится при запуске, начиная с DDOS 7.7.x, теперь можно определить с помощью интерфейса командной строки фактическое «Общее освобождаемое пространство», которое сможет освободить следующая сборка мусора на активном уровне. Ниже приведена сводка по интерфейсу командной строки:
 

# filesys cleanable-space calculate
Cleanable space calculation started. Use 'filesys cleanable-space watch' to monitor progress.

Процесс будет делать то же самое, что и обычная сборка мусора, проходя через фазы с 1 по 4, но пропуская фазу 5 (копирование), которая будет эффективно копировать контейнеры вперед для освобождения мертвого дискового пространства. Таким образом, для возврата значения потребуется столько же времени, сколько требуется обычной сборке мусора для завершения чистых фаз с 1 по 4, поэтому это не то, что следует запускать регулярно для получения обновленной оценки, а только при необходимости. Другими словами, «filesys cleanable-space calculate» выполнит сборку мусора на активном уровне, просто пропустив ту часть, в которой он освобождает пространство.

Процесс можно отслеживать следующим образом:
 

# filesys cleanable-space watch
Beginning 'filesys cleanable-space calculation' monitoring.  Use Control-C to stop monitoring.

Cleaning: phase 1 of 4 (pre-merge)
  100.0% complete, 96233 GiB free; time: phase  0:02:07, total  0:02:07

Cleaning: phase 2 of 4 (pre-analysis)
  100.0% complete, 96233 GiB free; time: phase  0:06:51, total  0:08:59

Cleaning: phase 3 of 4 (pre-enumeration)
  100.0% complete, 96233 GiB free; time: phase  0:00:20, total  0:09:20

Cleaning: phase 4 of 4 (pre-select)
  100.0% complete, 96233 GiB free; time: phase  0:00:25, total  0:09:46

После завершения можно получить доступ к очищаемому результату измерения:

# filesys cleanable-space status

Cleanable space on active tier is 94649698202 bytes. Last calculated on 2023/08/25 03:29:51
Cleanable space calculation finished at 2023/08/25 03:29:51.

В приведенном выше примере, если DD GC будет запущен сейчас, то он освободит 94649698202 байт. Это 88,1 ГиБ, тогда как на момент расчета оценка, полученная от «df» в используемой лаборатории DD, составляла 41,9 ГиБ. Конечно, по мере внесения изменений в файловую систему (новые резервные копии, новые удаления, создание и истечение срока действия снимков и т. д.) расчет будет выполняться.

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

# filesys cleanable-space stop

The 'filesys cleanable-space stop' command stops calculating cleanable space in the system.
Are you sure? (yes|no) [no]: yes

ok, proceeding.

# filesys cleanable-space status
Cleanable space on active tier is 2607064 bytes. Last calculated on 2021/06/27 23:23:05
Cleanable space calculation started at 2021/06/27 23:27:58 and was aborted at 2021/06/27 23:28:19.
Cleaning was aborted by user.

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