В прошлой части мы рассмотрели основные моменты, касающиеся VDO, а также немного затронули момент сайзинга.
В этой части займемся инсталляцией пакетов для работы с VDO, созданием блочного устройства и тестированием работы дедупликации и компрессии.
В качестве тестового стенда используется виртуальная машина под управлением CentOS 8.1, с 4 vCPU и 16GB оперативной памяти.
В виртуальную машину добавлен диск размером 100GB, на котором будут проходить опыты.
В первую очередь обновим систему и перезагрузимся, для того чтобы начать работу на самом доступном в репозитории ядре.
[root@v-test ~]# yum -y update
[root@v-test ~]# reboot
Теперь установим пакеты, необходимые для работы VDO. В качестве зависимостей так же установится Python, который является одним из требований к работе:
[root@v-test ~]# yum –y install vdo kmod-kvdo
Создаем тестовый том VDO:
Когда VDO установлен в системе, можно перейти к созданию тома.
При создании не забываем про размер Slab (–vdoSlabSize=slab_size). Поскольку наши диски размером 100GB, и рекомендуемый slab для данного объема – 2GB, данный параметр не указываем, поскольку 2GB является значением по умолчанию.
[root@v-test ~]# vdo create --name vdo_lvm --device=/dev/vg_vdo/lv_vdo Creating VDO vdo_lvm
Starting VDO vdo_lvm
Starting compression on VDO vdo_lvm
VDO instance 0 volume is ready at /dev/mapper/vdo_lvm
Проверим результат создания:
[root@v-test ~]# vdostats --human-readable Device Size Used Available Use% Space saving% /dev/mapper/vdo_lvm 99.9G 4.0G 95.9G 3% N/A
Создадим файловую систему xfs на разделе:
[root@v-test ~]# mkfs.xfs /dev/mapper/vdo_lvm
Смонтируем раздел и попробуем записать 20GB нулей:
[root@v-test ~]# mkdir /tmp/vdo_lvm
[root@v-test ~]# mount -t xfs /dev/mapper/vdo_lvm /tmp/vdo_lvm
[root@v-test ~]# dd if=/dev/zero of=/tmp/vdo_lvm/1.txt bs=1M count=20000
Как можно было заметить ранее, мы не указывали параметр логического размера диска, ввиду чего он автоматически становится равным размеру нижележащего физического устройства.
Проверим результат двух команд:
[root@v-test ~]# vdostats
--human-readable
Device Size Used Available Use% Space saving%
/dev/mapper/vdo_lvm 99.9G 4.0G
95.9G 3% 99%
[root@v-test ~]# df -h | grep vdo
/dev/mapper/vdo_lvm 96G 21G
76G 22% /tmp/vdo_lvm
Команда vdostats показывает, что на наших томах занято не более 4GB пространства, при этом значение Space saving составляет 99%.
В этот же момент df –h показывает, что из 100GB занято 21, что соответствует действительности, поскольку ранее было создано два файла, по 20GB каждый.
Попробуем заполнить раздел более чем на 100% и проверим результат. Запишем в файл 200 гигабайт нулей:
[root@v-test ~]# dd if=/dev/zero of=/tmp/vdo_lvm/1.txt bs=1M count=200000
102079922176 bytes (102 GB, 95 GiB) copied, 235.916 s, 433 MB/s
Не трудно догадаться, произошла запись не более 100 гигабайт, тем самым заполнив раздел в ОС до 100%. При этом vdostats так же показывает 99% space savings:
[root@v-test ~]# vdostats
--human-readable
Device Size Used Available Use% Space saving%
/dev/mapper/vdo_lvm 99.9G 4.1G
95.8G 4% 99%
Как же задействовать сохраненное пространство? Если вы читали первую часть, в ней фигурировал параметр Logical Size – пространство, которое видит конечный пользователь. Поскольку мы не задавали данный параметр, это значение равняется физическому размеру нижележащего устройства. В нашем случае 100GB.
Изменим размер для нашего диска. Размер указывается в мегабайтах и должен являться степенью числа 2:
[root@v-test ~]# vdo growLogical --name=vdo_lvm --vdoLogicalSize=204800
Расширим файловую систему на новый объем и проверим, что параметр LogicalSize дает желаемый результат:
[root@v-test ~]# xfs_growfs /tmp/vdo_lvm
/dev/mapper/vdo_lvm 200G 97G
104G 49% /tmp/vdo_lvm
Результат ожидаем. Файловая система теперь объемом в 200GB.
[root@v-test ~]# vdostats
Device 1K-blocks Used Available Use% Space saving%
/dev/mapper/vdo_lvm 104755200 4283672 100471528 4%
99%
При этом для VDO ничего не изменилось. Низлежащее блочное устройство так же занято на 4%, так же имеет объем 100GB и 99% Space saving.
Как можно заметить, с нулями VDO справляется хорошо. Проверим работу компрессии и дедупликации. Предварительно я очистил директорию, и она свободна на 100%:
[root@v-test ~]# vdostats --human-readable
Device Size Used Available Use% Space saving%
/dev/mapper/vdo_lvm 99.9G 23.6G
76.3G 23% 0%[root@v-test ~]# dd if=/dev/urandom of=/tmp/vdo_lvm/1.txt bs=1M count=20000
20971520000 bytes (21 GB, 20 GiB) copied, 369.636 s, 56.7 MB/s
Как можно заметить, на псевдослучайных данных показатель компрессии/дедупликации получился нулевой.
Проверим работу дедупликации. Добавим явно повторяющиеся данные:
[root@v-test ~]# cp /tmp/vdo_lvm/1 /tmp/vdo_lvm/2
[root@v-test ~]# cp /tmp/vdo_lvm/1 /tmp/vdo_lvm/3
Результат дедупликации положительный:
[root@v-test ~]# vdostats --human-readable
Device Size Used Available Use% Space saving% /dev/mapper/vdo_lvm 99.9G 23.6G 76.3G 23% 66%
Space saving 66%, что соответствует действительности.
По умолчанию, на томах VDO включена компрессия и дедупликация. Попробуем отключить оба этих параметра и проверим результат:
[root@v-test ~]# vdo disableCompression --name=vdo_lvm
Disabling compression on vdo vdo_lvm
Stopping compression on VDO vdo_lvm
[root@v-test ~]# vdo disableDeduplication --name=vdo_lvm
Disabling deduplication on vdo vdo_lvm
[root@v-test ~]# vdostats vdo_lvm --human-readable
Device Size Used Available Use% Space saving%
vdo_lvm 99.9G 23.6G 76.3G 23% 66%
С существующими данными ничего не изменилось. Попробуем скопировать существующий файл еще раз и сравним результат:
[root@v-test ~]# cp /tmp/vdo_lvm/1 /tmp/vdo_lvm/4
[root@v-test ~]# vdostats vdo_lvm --human-readable
Device Size Used Available Use% Space saving%
vdo_lvm 99.9G 42.5G
57.4G 42% 50%
Вывод в данном случае можно сделать только один – при отключении компрессии и дедупликации, старые данные остаются так же в дедуплицированном\сжатом состоянии, а вот новые ложатся уже целиком. Технологии эффективности к ним не применяются.
Включим сохранение пространства обратно и проверим результат:
[root@v-test ~]# vdo enableCompression --name=vdo_lvm
Enabling compression on vdo vdo_lvm
Starting compression on VDO vdo_lvm
[root@v-test ~]# vdo enableDeduplication --name=vdo_lvm
Enabling deduplication on vdo vdo_lvm
Значение Space savings не изменилось:
[root@v-test ~]# vdostats vdo_lvm --human-readable
Device Size Used Available Use% Space saving%
vdo_lvm 99.9G 43.1G
56.8G 43% 50%
Скопируем еще раз файл:
[root@v-test ~]# cp /tmp/vdo_lvm/1 /tmp/vdo_lvm/5
[root@v-test ~]# vdostats --human-readable
Device Size Used Available Use% Space saving%
/dev/mapper/vdo_lvm 99.9G 43.2G
56.7G 43% 60%
Space saving отрабатывает, как и ожидалось. Занято 43GB, часть из данных занимают метаданные, половину – первый загруженный файл, вторую половину – файл, который был загружен в момент отключения технологий эффективности.
Операционная система сообщает, что на текущий момент из 200GB занято 100 (5 файлов по 20 гигабайт), при реальном занятом пространстве в 43GB:
/dev/mapper/vdo_lvm 200G 100G
101G 50% /tmp/vdo_lvm
В качестве заключения:
Начать работать с VDO не составляет особой сложности. Все, что нужно сделать – это выделить блочное устройство, поверх которого будет работать непосредственно VDO, создать файловую систему и смонтировать.
К сожалению, у меня под рукой не оказалось подходящих файлов, чтобы проверить работоспособность компрессии, но вот с дедупликацией и отрезанием нулей VDO справилось положительно.
В следующих частях попробуем копнуть еще глубже.
Прошлые выпуски про VDO:
Часть 1. Основы.
