VDO. Часть 1 – Компрессия и дедупликация в Linux

Недавно, находясь на Workshop компании Red Hat, понял, что слишком много интересных вещей успели пройти мимо меня. Возможно, это запустит цикл статей по “новшествам”, многим из которых уже несколько лет.

Одна из этих вещей – VDO, или же Virtual Data Optimizer, позволяющая обеспечивать дедупликацию и компрессию на блочном уровне.

VDO?

VDO представляет собой блочное устройство в системе Linux, к которому применяются технологии уменьшения занимаемого объема данных:

  1. Thin Provisioning;
  2. Deduplication;
  3. Compression.

На схеме ниже представлен порядок операций, которые применяются к данным, размещаемым на VDO:

VDO состоит из двух модулей:

kvdo – непосредственно предоставляющий нам дедуплицированное и сжатое блочное устройство;

uds – занимается вопросами дедупликации данных.

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

Понятия физического и логического размера для VDO:

Физический размер, как можно догадаться, – размер блочного устройства, поверх которого располагается VDO. Максимальный размер такого устройства может составлять 256TB.

Доступный физический размер – общий объем за минусом пространства под метаданные и индекс.

Логический размер – если не указан, по умолчанию равняется физическому размеру. Однако, может быть изменен до размера, превышающего физический до 254 раз с максимумом в 4PB.

Режимы записи:

VDO поддерживает три режима записи – синхронный (sync) и асинхронный (async), автоматический (auto).

При синхронном режиме записи VDO посылает сигнал о записи данных (ACK), только после того, как нижестоящее устройство выполнило запись. Синхронный режим должен быть установлен в случае, если нижестоящее устройство гарантирует запись после завершения команды. Например, у системы отсутствует энергозависимый кэш, либо используется Write Through Cache.

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

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

Slabs:

Диск VDO делится на блоки (Slabs), размер которых выражается в степени числа 2, общее количество блоков для устройства может составлять 8096, таким образом при размере блока в 2GB (значение по умолчанию), максимальный размер диска составит около 16TB.

Таблица рекомендуемого значения Slab:

Размер VDO Размер Slab
10-100GB 1GB
100GB–1TB 2 GB
2-256TB 32GB

Размер slab не влияет на производительность VDO.

Системные требования:

ОЗУ:

Не трудно догадаться, но бесплатного пространства не бывает и в данном случае придется пожертвовать в первую очередь оперативной памятью системы.

Каждый модуль VDO требует 370MB ОЗУ и дополнительно 268MB на 1TB физического пространства.

UDS Index требует минимум 250MB, и зависит от выбранного типа индексирования Sparse Indexing (Рекомендованный для VDO тип), либо Dense Indexing и общего физического пространства.

Sparse Indexing использует 1GB ОЗУ на 10TB физического пространства. Согласно документации, в большинстве случаев на 40TB физического пространства достаточно 1GB ОЗУ;

Dense Indexing использует 1GB ОЗУ на 1TB физического пространства. Согласно документации, в большинстве случаев 1GB ОЗУ хватает на 4TB физического пространства.

Дисковое пространство:

Метаданные и индексы так же занимают дисковое пространство физического носителя, на котором располагается VDO.

VDO использует два типа метаданных:

Первый тип метаданных напрямую зависит от физического размера тома и использует примерно 1 мегабайт на каждые 4 гигабайта и, дополнительно, 1 мегабайт на один блок (slab), максимальное количество которых, как уже было сказано выше, может составлять 8096;

Второй тип метаданных зависит от логического размера VDO и составляет примерно 1.25MB на 1 гигабайт.

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

Sparse Indexing использует до 170GB на 1GB занимаемой ОЗУ;

Dense Indexing использует до 17GB на 1GB занимаемой ОЗУ.

Примеры требования к ресурсам:

В данном примере я взял таблицы из документации Red Hat, поскольку тестов на подобных объемах мной не проводились.

Таблица расчета смешанных данных:

Физический размер тома 10GB – 1TB 2-10TB 11-50TB 51-100TB 101-256TB
Исп. ОЗУ 250MB Dense: 1GB/Sparse 250MB 2GB 3GB 12GB
Исп. Диск 2.5GB Dense: 10GB/Sparse 22GB 170GB 255GB 1020GB
Тип индекса Dense Dense or Sparse Sparse Sparse Sparse

Таблица расчета пространства для хранилища резервных копий:

Физический размер тома 10GB – 1TB 2-10TB 11-50TB 51-100TB 101-256TB
Исп. ОЗУ 250MB 2GB 10GB 20GB 26GB
Исп. Диск 2.5GB 170GB 850GB 1700GB 3400GB
Тип индекса Dense Sparse Sparse Sparse Sparse

Как можно заметить, индекс Dense более требователен к объему оперативной памяти, но менее требователен к дисковому пространству. В то время, как индекс Sparse потребляет меньшее количество ОЗУ, при большем потреблении ресурсов HDD.

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

В качестве заключения:

  1. VDO позволяет обеспечить Inline Data Reduction применяя механизмы компрессии, дедупликации, тонких дисков;
  2. Поддерживаются синхронный, асинхронный режимы записи;
  3. При планировании использования VDO особое внимание необходимо уделить объему оперативной памяти на сервере исходя из общего физического объема,  и выбранного типа индексирования.

Leave a Reply

Your email address will not be published. Required fields are marked *