Недавно, находясь на Workshop компании Red Hat, понял, что слишком много интересных вещей успели пройти мимо меня. Возможно, это запустит цикл статей по “новшествам”, многим из которых уже несколько лет.
Одна из этих вещей – VDO, или же Virtual Data Optimizer, позволяющая обеспечивать дедупликацию и компрессию на блочном уровне.
VDO?
VDO представляет собой блочное устройство в системе Linux, к которому применяются технологии уменьшения занимаемого объема данных:
- Thin Provisioning;
- Deduplication;
- 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.
Согласно документации, при равном количестве ОЗУ для большинства нагрузок различие в показателях дедупликации между двумя методами незначительно.
В качестве заключения:
- VDO позволяет обеспечить Inline Data Reduction применяя механизмы компрессии, дедупликации, тонких дисков;
- Поддерживаются синхронный, асинхронный режимы записи;
- При планировании использования VDO особое внимание необходимо уделить объему оперативной памяти на сервере исходя из общего физического объема, и выбранного типа индексирования.
