Дедупликация хранилища резервных копий виртуальных машин oVirt с помощью QUADStor Storage Virtualization на CentOS Linux 7.2

Рассматривая в одной из прошлых заметок тему резервного копирования виртуальных машин oVirt, я остановился на мысли о том, что описанный метод с регулярным созданием полных резервных копий ВМ может стать причиной большого потребления дисковой ёмкости, используемой для хранения резервных копий. В данной заметке будет предложен один из вариантов решения данной проблемы – настройка программной дедупликации для дискового раздела с резервными копиями ВМ на базе свободно распространяемого продукта QUADStor Storage Virtualization Software индийского проекта QUADStor.

В моём случае для хранения резервных копий виртуальных машин в oVirt на файловом сервере с CentOS Linux ранее был создан программный RAID средствами mdadm из дисковых multipath-устройств. В этой заметке поверх уже существующего программного RAID-массива /dev/md0 будет создан виртуальный диск QUADStor, поверх которого, в свою очередь, будет создан раздел ext4 и экспортирован через NFS серверу управления oVirt для дальнейшего использования в качестве ISO Domain (для хранения ISO-образов) и Export Domain (для хранения резервных копий ВМ). Для создаваемого виртуального диска QUADStor будет задействован механизм программной дедупликации, которая позволит реализовать существенную экономию дискового пространства и увеличить количество хранимых резервных копий ВМ.

Основной набор документации можно найти по ссылке Storage Virtualization Documentation. Некоторую дополнительную информацию можно найти здесь: Tech Library. Если при внедрении QUADStor вы столкнётесь с проблемами, то вопросы можно задавать в Google-группе QUADStor Storage Virtualization.

С системными требованиями можно ознакомится на странице System Requirements, где, в частности, есть такая фраза:

The recommendation is to add an additional 2 GB of memory for every 1 TB of storage configured or every 4 VDisks created or for every 2 physical disks configured

В моём случае планируется использовать дисковую ёмкость размером не более 4TB. Поэтому исходя из требования, что самой системе минимум требуется 4GB ОЗУ (8GB если планируется использовать функции NAS, то есть, если я правильно понимаю, речь идёт про iSCSI) + рекомендация добавлять по 2GB ОЗУ на каждый 1TB хранилища (в моём случае планируется 4TB), получается 12GB или 16GB ОЗУ, в зависимости от того, буду ли я использовать функционал NAS. В моём файловом сервере предустановлено 16GB ОЗУ, поэтому будем считать, что в требования я вписываюсь.

 

Установка QUADStor

Порядок установки QUADStor на разные дистрибутивы Linux описан в документе Installation/Upgrading on RHEL/CentOS 5.x, 6.x, SLES 11 and Debian 6.x, 7.x. Я буду предпринимать последовательность действий исходя из того что установка выполняется на CentOS Linux 7.2.

Устанавливаем предварительно требуемые пакеты:

# yum install httpd gcc perl kernel-devel sg3_utils iotop sysstat lsscsi

Проверим версию установленного пакета kernel-devel:

# rpm -qa | grep kernel-devel

kernel-devel-3.10.0-327.36.2.el7.x86_64

И сравним эту версию с версией рабочего ядра системы:

# uname -r

3.10.0-327.36.2.el7.x86_64

Версии должны совпадать. Если версии не совпадают, то необходимо выполнить сначала обновление ядра, заем выполнить перезагрузку системы, а после выполнить обновление пакета kernel-devel:

# yum upgrade kernel
# reboot
# yum upgrade kernel-devel

В конечном итоге мы должны получить совпадающие версии ядра и пакета kernel-devel.

Теперь переходим к установке QUADStor Storage Virtualization. Если ранее была установлена предыдущая версия, то перед установкой новой версии потребуется удалить старую версию. При этом все метаданные, необходимые для работы уже сконфигурированных виртуальных дисков QUADStor останутся на дисках участвующих в дисковом пуле QUADStor. После установки новой версии эти метаданные должны будут автоматически интерпретированы управляемым кодом QUADStor.   

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

# chkconfig quadstor off

Note: Forwarding request to 'systemctl disable quadstor.service'.
Removed symlink /etc/systemd/system/multi-user.target.wants/quadstor.service.

# reboot

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

# rpm -qa | grep quadstor

quadstor-virt-3.2.9-rhel.x86_64

# rpm -e quadstor-virt-3.2.9-rhel.x86_64

Restoring original qla2xxx driver from/lib/modules/3.10.0-327.36.2.el7.x86_64/kernel/drivers/scsi/qla2xxx/qla2xxx.ko.qssave
Recreating initrd image

# reboot

Теперь скачиваем и устанавливаем основной пакет QUADStor Storage Virtualization (ссылку на актуальную версию пакета берём здесь: Storage virtualization downloads):

# mkdir ~/QUADStor-files
# wget http://www.quadstor.com/virtentdub3z/quadstor-virt-3.2.10-rhel.x86_64.rpm -P ~/QUADStor-files
# rpm -i ~/QUADStor-files/quadstor-virt-3.2.10-rhel.x86_64.rpm

...
Performing post install. Please wait...
Created symlink from /etc/systemd/system/multi-user.target.wants/quadstor.service to /usr/lib/systemd/system/quadstor.service.
Building required kernel modules
Running /quadstor/bin/builditf. This may take a few minutes.

Установка пакета должна завершиться без ошибок.

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

Настроим автозагрузку веб-сервера Apache, если это ещё не было сделано ранее, так как он нам понадобиться для управления QUADStor:

# systemctl enable httpd.service

Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

После этого ещё раз перезагружаем сервер и убеждаемся в том, что после загрузки системы обе службы успешно автоматически стартуют:

# service httpd status
# service quadstor status

Если службы успешно запущены, можем переходить к дополнительной настройке веб-сервера.

 

Базовая настройка веб-сервера

Включим в firewalld разрешающее правило для подключения к веб-серверу, чтобы у нас была возможность подключиться к нему удалённо:

# firewall-cmd --permanent --zone=public --add-service=http
# firewall-cmd --permanent --zone=public --add-service=https
# firewall-cmd --reload

Проверяем доступ к веб-интерфейсу пройдя по ссылке http://{сервер}. Веб-сервер должен будет перенаправить нас по ссылке http://{сервер}/cgi-bin/system.cgi

Как видим, мы без каких-либо запросов аутентификации получаем полный доступ к веб-консоли управления QUADStor, поэтому первоочередной задачей для нас станет настройка ограничения доступа к этой веб-консоли.

***

На данном этапе мы произведём лишь простейшее базовое ограничение доступа в соответствии с рекомендациями статьи Accessing the Web Management Interface.

Ограничим доступ к веб-интерфейсу с помощью файла .htaccess, который создадим в каталоге cgi-bin (в этом каталоге расположены исполняемые файлы QUADStor, которые используются при работе веб-консоли):

# nano /var/www/cgi-bin/.htaccess

Наполним файл содержимым (включим Basic-аутентификацию и укажем пусть к файлу с учётными данными для проверки):

AuthName "QUADStor Authentication"
AuthType Basic
AuthUserFile /etc/httpd/conf/.htpasswd
Require valid-user

Сгенерируем файл .htpasswd с именем пользователя и паролем, которые мы используем для ограничения доступа к веб-сайту QUADStor:

# htpasswd -s -b -c /etc/httpd/conf/.htpasswd vasyawebadmin PAsZw0rD

Исправим конфигурационный файл веб-сервера /etc/httpd/conf/httpd.conf. Найдём в нём блок описания доступа к подкаталогу /var/www/cgi-bin:

<Directory "/var/www/cgi-bin">
     AllowOverride None
     Options None
     Require all granted
</Directory>

Изменим этот блок, добавив параметры вызова аутентификации

<Directory "/var/www/cgi-bin">
     AllowOverride AuthConfig Limit
     Options None
     Order allow,deny
     Allow from all
</Directory>

Для вступления изменений в силу перезагрузим службу веб-сервера (перезапуск службы должен происходить без ошибок):

# service httpd restart

Разумеется, выполненная настройка веб-сервера не является правильной с точки зрения безопасности, а позволяет лишь базово ограничить доступ к веб-консоли QUADStor на первоначальном этапе настройки. Позже, в отдельной заметке мы изменим настройки веб-сервера таким образом, чтобы можно было использовать доменную аутентификацию в связке с SSSD и защитим HTTP соединения с веб-консолью QUADStor с помощью SSL-сертификата. 

 

 

Конфигурация дисковой подсистемы QUADStor

Базово настройка дисковой подсистемы QUADStor состоит в том, чтобы создать пул хранения (Storage Pool), включить в этот пул дисковые устройства (Physical Storage), после чего пул можно будет использовать для создания виртуального диска (Virtual Disk).

 

Создаём Storage Pool

Информацию о такой сущности, как Storage Pool, можно найти в документе Configuring Storage Pools. По умолчанию в QUADStor уже создан пул Default. Это служебный пул, изменить или удалить который нельзя. Как я понял, пул выступает в качестве границы определения общности физических устройств, для которых будет использоваться единая база метаданных, используемых для механизма дедупликации. При этом пул Default способен хранить на своих дисках метаданные дедупликации из прочих пулов. То есть пул Default, на мой взгляд, можно расценивать как некий служебный пул, поэтому я не трогаю этот пул, а создаю отдельный. Для этого переходим по ссылке Storage Pools и под таблицей пулов используем кнопку Add Pool 

Указываем имя пула, включаем признак того, что данный пул будет содержать собственный набор метаданных (Dedupe Metadata и Logs) и жмём Submit

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

 

Добавляем Physical Storage в Storage Pool

Физически диски определяются путём сканирования вывода /proc/scsi/scsi, также поддерживаются виртуальные устройства software raid на базе mdadm. При этом недоступны будут диски с существующими смонтированными разделами, а также диски размером менее 4GB. Поддерживается также использование томов ZFS ZVOL (подробней об этом в документе Configuring Physical Storage). Доступные для использования в пулах QUADStor дисковые устройства можно увидеть пройдя по ссылке Physical Storage.

В моём случае, меня не очень приятно удивил тот факт, что я увидел в списке доступных устройств диски, из которых был собран мой программный RAID. При этом диски отображаются, как отдельные multipath-устройства.

Самого же RAID устройства /dev/md0 в списке я не видел, но это вполне закономерно, так как на нём в этот момент ещё присутствовал смонтированный в системе раздел ext4. Мне стало интересно, как поведёт себя QUADStor, если я попытаюсь добавить перечисленные multipath-устройства в созданный ранее пул. В общем, не смотря на то, что на этих дисках был расположен смонтированный раздел ext4 поверх md0, веб-консоль QUADStor "не моргнув глазом" дала включить эти диски в пул и затем даже создать виртуальный диск на базе этого пула. А на виртуальном диске я уже смог бы создать новый раздел ext4, уничтожив тем самым раздел на ext4 поверх md0 (конечно при условии что первичный раздел предварительно был бы отмонтирован). Доводить этот безобразный эксперимент до конца я конечно не стал, а просто сделал вывод о том, что нужно очень внимательно относиться к тому, что нам предлагает вкладка Physical Storage, чтобы не наделать себе проблем. Ну и разумеется, включая диски в пул, нужно понимать, что все данные, которые есть на этих дисках будут в конечном итоге потеряны.

Итак, чтобы получить возможность использования своего программного RAID диска md0, я удалил из системы все ссылки на раздел ext4, используемый в моём случае на устройстве /dev/md0, в частности отключил NFS шары, расположенные на этом разделе с последующим перезапуском конфигурации nfs-сервера. Затем нужно не забыть выполнить отсоединение раздела от точки монтирования:

# umount /mnt/mdadm-vv1/

Затем в /etc/fstab закомментировать строчку монтирования раздела /mnt/mdadm-vv1/ при загрузке. В общем нужно провести все мероприятия, необходимые для "освобождения" интересующего нас дискового устройства, которое мы хотим использовать для включения в пул QUADStor.

После этого возвращаемся в веб-консоль QUADStor на вкладке Physical Storage жмём Rescan и видим что RAID-устройство md0 появилось в списке доступных. Щёлкаем по ссылке Add, чтобы добавить это устройство в созданный ранее пул Pool1

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

В списке пулов выбираем созданный нами ранее пул Pool1

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

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

Включать опцию HA Disk в моём случае тоже смысла нет, так как эта опция используется в случае если диск планируется использовать в качестве quorum-диска при построении высоко-доступных конфигураций QUADStor.

 

После нажатия кнопки Submit дисковое устройство изменит свой статус на Initializing

 

Дождёмся, завершения инициализации дискового устройства. Так как в моём случае с устройства md0 не был удалён созданный там ранее раздел ext4 c данными, то время ожидания затянулось примерно на 15 минут:

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

 

Создаём виртуальный диск VDisk

Подробную информацию о создании и управлении виртуальными дисками можно найти в документе Creating and Managing Virtual Disks (VDisks).

Чтобы создать виртуальный диск, переходим по ссылке Virtual Disks и жмём кнопку Add VDisk

Зададим произвольное имя диска VDisk Name и укажем его размер VDisk Size в GB. Максимально допустимое значение размера виртуального диска – 64 TB (65536 GB). По своей сути виртуальный диск представляет собой динамически расширяемый Thin-диск и поэтому размер виртуального диска можно указывать больше, чем размер физических дисков пула. Не смотря на это я постараюсь указать размер виртуального диска сопоставимый с реальным размером пула, то есть в нашем случае – реальным размером дискового raid-устройства md0. Для того, чтобы выяснить текущий размер пула можно заглянуть в свойства пула Storage Pools > выбираем в списке пул и переходим по ссылке View:

Можем взять значение, указанное в Total Size и умножить его на 1024. В моём случае получится ~3725 GB.

Кстати виртуальный диск QUADStor после создания, при необходимости, может быть как увеличен так и уменьшен (см.часть Resizing a VDisk). Если с увеличением какое-то логическое объяснение найти можно, то вопрос о том, какие есть требования для возможности уменьшения с техническими подробностями процесса, остался открытым, так как этой информации я нигде найти не смог.  

Опция 512 byte Emulation используется в том случае, если нужно чтобы размер сектора на создаваемом виртуальном диске был 512 байт вместо используемых по умолчанию 4096 байт. Как я понял из документа Creating and Managing Virtual Disks (VDisks), эту опцию рекомендуется включать в случае если виртуальный диск будет использоваться в качестве рабочего хранилища для виртуальных машин. В нашем случае виртуальный диск будет использован под хранение резервных копий, поэтому эффективней будет использовать значение по умолчанию в 4КБ.

В списке пулов соответственно выбираем созданный ранее Storage Pool и жмём Submit

После этого в списке сконфигурированных виртуальных дисков появится новая позиция со ссылками Modify и View

По ссылке Modify мы сможем изменять размер виртуального диска, изменять опции дедупликации и компрессии, настраивать зеркалирование диска (подробнее в документах  Tutorial: Configuring high availability with synchronous mirroring и High Availability with Synchronous Mirroring), а также настраивать конфигурацию экспорта ёмкости диска по протоколу iSCSI.

К ссылке View мы вернёмся чуть позже, чтобы посмотреть статистику уровня экономии места от операций дедупликации.

 

Создаём раздел на виртуальном диске VDisk

Возможные способы доступа к виртуальному диску перечислены в документе Accessing Virtual Disks (VDisks). В рамках нашей задачи я выбираю локальный доступ к устройству, который можно получить обратившись в каталог /dev/quadstor/:

# ls -la /dev/quadstor/
...
lrwxrwxrwx.  1 root root    6 Oct 18 14:54 VDisk1 -> ../sdu

Как видим, после создания виртуального диска в системе появилось одноимённое устройство /dev/quadstor/VDisk1, которое является ссылкой на блочное устройство, в нашем случае это диск /dev/sdu с ранее упоминавшимся размером сектора в 4KB

# fdisk -l /dev/quadstor/VDisk1

Disk /dev/quadstor/VDisk1: 3999.7 GB, 3999688294400 bytes, 976486400 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 524288 bytes

Создадим файловую систему (в нашем случае это будет ext4) на виртуальном диске, затем создадим каталог, в который будем монтировать созданный раздел и, наконец, смонтируем этот раздел:

# mkfs.ext4 /dev/quadstor/VDisk1
# mkdir /mnt/quadstor-vv1
# mount /dev/quadstor/VDisk1 /mnt/quadstor-vv1
# df -H /dev/quadstor/VDisk1

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdu        4.0T   93M  3.8T   1% /mnt/quadstor-vv1

Затем пропишем в fstab информацию для автоматического монтирования раздела в точку монтирования /mnt/quadstor-vv1 в процессе загрузки системы в соответствии с рекомендациями документа Automounting a filesystem created on a VDisk. Добавим информацию о монтировании в конец файла /etc/fstab

...
#
# Mount QUADStor Virtual Disk /dev/quadstor/VDisk1 on /mnt/quadstor-vv1
#
/dev/quadstor/VDisk1 /mnt/quadstor-vv1 ext4 defaults,nofail,noauto 0 0

После этого перезагружаем сервер и убеждаемся в том, что конечный результат достигнут и раздел автоматически монтируется в точку монтирования /mnt/quadstor-vv1.

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

# touch /mnt/quadstor-vv1/write-test.txt
# rm /mnt/quadstor-vv1/write-test.txt

Теперь наш раздел ext4 расположенный на виртуальном диске готов к работе. Можно запускать раздел в работу. В моём случае на данном разделе было создано несколько NFS-шар, которые были подключены к oVirt в качестве ISO Domain и Export Domain.

 

Проверяем результат дедупликации

Через некоторое время после начала использования раздела с дедупликацией я сравнил по логам, которые создаёт скрипт резервного копирования ВМ (в моём случае речь идёт о ежедневном резервном копировании 6 виртуальных машин) и с удивлением обнаружил, что время выполнения резервного копирования не только не увеличилось, но даже немного уменьшилось. Ниже приведены выжимки из лога. Первый блок показывает нынешнее время выполнения резервного копирования из последнего лог-файла (используется раздел ext4 поверх виртуального диска /dev/quadstor/VDisk1, который в свою очередь работает поверх программного RAID-массива /dev/md0), а второй блок показывает время выполнения в один из предыдущих дней, когда файловые операции выполнялись на разделе ext4 сразу поверх /dev/md0

# cat /var/log/ovirt-vm-backup/ovirt-vm-backup.log | grep Duration

Oct 21 16:37:47: Duration: 7:27 minutes
Oct 21 16:39:51: Duration: 9:31 minutes
Oct 21 16:44:41: Duration: 14:21 minutes
Oct 21 16:49:22: Duration: 19:2 minutes
Oct 21 16:55:49: Duration: 25:29 minutes
Oct 21 17:00:40: Duration: 30:20 minutes

# zcat /var/log/ovirt-vm-backup/ovirt-vm-backup.log-20161018.gz | grep Duration

Oct 18 00:18:18: Duration: 8:17 minutes
Oct 18 00:21:08: Duration: 11:7 minutes
Oct 18 00:27:18: Duration: 17:17 minutes
Oct 18 00:33:07: Duration: 23:6 minutes
Oct 18 00:40:37: Duration: 30:36 minutes
Oct 18 00:45:59: Duration: 35:58 minutes

Поначалу я не поверил своим глазам и прошёлся по всем старым логам, после чего окончательно убедился в том, что с даже с учётом онлайн-дедупликации виртуальный диск QUADStor справляется с поставленной в моём случае задачей вполне достойно. И это не может не радовать. К тому же, в процессе резервного копирования, на той стадии, когда идёт переноса клонов виртуальных машин в oVirt Export Domain, то есть когда непосредственно выполняется запись на виртуальный диск QUADStor с включённой дедупликацией, я в режиме реального времени понаблюдал за нагрузкой на процессор и память на файловом сервере, и также был приятно удивлён тем, что никаких экстраординарных нагрузок при этом на систему не было обнаружено:

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

То есть, за прошедший период времени на виртуальный диск было записано около 63.94GB данных, которые на текущий момент занимают 8.49GB физической дисковой ёмкости, а 55.45GB - это сэкономленное с помощью дедупликации место. По моему, выглядит вполне интересно. Теперь можно смело увеличивать количество дней хранения резервных копий виртуальных машин.

Если посмотреть на виртуальный диск QUADStor на уровне всевозможных утилит, которые показывают информацию о размерах разделов, то можно "словить конфуз", как было со мной:

# df -H /mnt/quadstor-vv1

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdu        4.0T   65G  3.7T   2% /mnt/quadstor-vv1

Мы увидим то, что занятое место на разделе смонтированном на виртуальном диске, отображается примерно схожим с размером записанных на него данных, то есть как бы без учёта дедупликации. Как я понял, фактически это не так и для того, чтобы получить объективную картину по объёму занятого места на виртуальном диске QUADStor, нужно использовать только интерфейсы, которые предоставляет это ПО. Учитывая данное обстоятельство, для меня пока открытым остается вопрос автоматического мониторинга занимаемого места на диске QUADStor. Возможно к этому вопросу я вернуть позже, когда руки дойдут до развёртывания и эксплуатации какой-то из открытых систем для мониторинга Linux-серверов.

Дополнительные источники информации:

• QUADStor - Troubleshooting common problems
• QUADStor - Command Line Reference
• Kalle's playground - Enabling data deduplication in Linux with QUADStor