Если появляется требование сделать бэкап виртуальной машины какой-либо среды виртуализации, то разные производители подходят к этому требованию по-разному. Кто-то реализует специальный REST-интерфейс исключительно для операций резервного копирования, как, например, Proxmox. У каких-то производителей нужно использовать стандартный REST-интерфейс, предназначенный для общих задач, как в OpenStack. VMware подошли к этому вопросу, реализовав REST-интерфейс для нужд автоматизации, который можно использовать и для бэкапа, и для восстановления конфигурации непосредственно виртуальных машин, а также выпустив специальную библиотеку на языке программирования C, которая называется vixDiskLib, для бэкапа и восстановления непосредственно дисков виртуальных машин. О библиотеке vixDiskLib мы уже писали ранее тут.

Особенность vixDiskLib заключается в том, что при ее использовании хост клиента системы резервного копирования не обязательно должен находиться в самой среде виртуализации VMware в качестве виртуальной машины. Вполне допускается, чтобы этот клиент системы резервного копирования находился за пределами среды виртуализации VMware. Это, казалось бы, логичное требование, далеко не всегда выполнимо при использовании других средств виртуализации. Например, для бэкапа или восстановления виртуальных машин OpenStack клиент системы резервного копирования должен находиться внутри самой среды виртуализации как виртуальная машина. В случае, если клиент системы резервного копирования находится за пределами среды виртуализации VMware, библиотека vixDiskLib использует сетевые соединения для работы с дисками виртуальной машины, для которой нужно выполнить операцию бэкапа. Но какие же преимущества будут в случае, когда клиент системы резервного копирования находится внутри среды виртуализации VMware как виртуальная машина? В этом случае диски виртуальной машины, для которой нужно осуществить операции резервного копирования, могут подключаться напрямую к виртуальной машине-клиенту системы резервного копирования. Эта технология называется HotAdd. То есть HotAdd — это технология среды виртуализации VMware, с помощью которой виртуальные жесткие диски могут быть подключены напрямую к виртуальной машине-клиенту системы резервного копирования во время операций бэкапа или восстановления. В дальнейшем в этой статье будут рассмотрены только операции бэкапа.

Особенности работы HotAdd

Системе резервного копирования выгодно использовать HotAdd, так как это более быстрый способ передачи данных с виртуального жесткого диска виртуальной машины на клиент системы резервного копирования, чем обычный способ работы с виртуальным жестким диском через сетевое соединение. Технология HotAdd чем-то напоминает описываемый нами ранее способ подключения томов виртуальной машины к клиенту системы резервного копирования в среде виртуализации OpenStack. Подробнее это описано в статье. 

Но технология HotAdd имеет и ограничения: 
1. HotAdd работает только на виртуальных машинах с дисками SATA и не поддерживается для резервного копирования виртуальных дисков IDE. Таким образом, виртуальная машина-клиент системы резервного копирования и виртуальная машина, для которой осуществляется процедура бэкапа, должны иметь SATA контроллеры и SATA диски. Также допускаются SCSI контроллеры и диски.
2. Виртуальная машина-клиент системы резервного копирования должна иметь доступ к тому же хранилищу данных, что и целевая виртуальная машина, для которой предполагается осуществлять операции резервного копирования. При этом версия VMFS и размеры блоков данных целевой виртуальной машины должны совпадать с хранилищем данных, где находится клиент системы резервного копирования.

HotAdd, по сути, является одним из способов доступа к дискам. В терминологии VMware это называется транспортом. То, какой транспорт будет использоваться модулем rb_module_vmware_vm и с каким приоритетом, определяется параметром disk_transport в файле конфигурации модуля, расположенном по пути /opt/rubackup/etc/rb_module_vmware_vm.conf. По умолчанию значение параметра disk_transport выглядит так: file:san:hotadd:nbdssl:nbd. В этой строке транспорты виртуальных жестких дисков выстроены по приоритету – от самого быстрого к самому медленному. Именно в таком порядке они и будут использоваться vixDiskLib при работе с виртуальными жесткими дисками. Если какой-либо транспорт не удается использовать, то vixDiskLib пытается использовать следующий по списку.

Преимущества HotAdd

При работе с библиотекой vixDiskLib нам предлагается для бэкапа виртуальных жестких дисков, подключенных по HotAdd, использовать те же методы работы с данными от vixDiskLib, такие как VixDiskLib_Read и VixDiskLib_Write. Но есть ли альтернатива? Если, подключив диск виртуальной машины с использованием технологии HotAdd к клиенту системы резервного копирования, посмотреть на список доступных дисков на виртуальной машине-клиенте, то можно увидеть, что к ранее присутствующим дискам добавились новые, подключенные с помощью технологии HotAdd. В Linux это можно сделать командой ls -la /dev/sd*.

У такого подхода на операционных системах семейства Windows могут быть проблемы: при попытке открытия диска, подключенного по технологии HotAdd, библиотека vixDiskLib может вернуть ошибки следующего вида:

W32Util_DismountVolumes: FSTCL_LOCK_VOLUME failed on volume \?\Volume{1724347c-6f52-00e2-853e-116046922237}: 5
W32Util_CloseDismountHandle: Unlocking and closing handles for 1 volumes on PhysicalDrive1...
DISKLIB-FLAT : Open: Failed to dismount physical drive 1. Perhaps its volumes have open files on them?
DISKLIB-FLAT : "\.\PhysicalDrive1" : failed to open (73): .
DISKLIB-LINK : "C:\Windows\TEMP\vmware-user\3120558e-65bc-a1c6-a2b0-69991a9ac6a2-vm-111\hotadd\VmdkStubs\scsi0-0-0-vm_name.vmdk" : failed to open (The physical disk is already in use).
DISKLIB-CHAIN : "C:\Windows\TEMP\vmware-user\3120558e-65bc-a1c6-a2b0-69991a9ac6a2-vm-111\hotadd\VmdkStubs\scsi0-0-0-vm_name.vmdk" : failed to open (The physical disk is already in use).
DISKLIB-LIB : Failed to open 'C:\Windows\TEMP\vmware-user\3120558e-65bc-a1c6-a2b0-69991a9ac6a2-vm-111\hotadd\VmdkStubs\scsi0-0-0-vm_name.vmdk' with flags 0x1e The physical disk is already in use (73).

Это происходит потому, что при подключении виртуальных жестких дисков по технологии HotAdd от виртуальных машин, для которых выполняется резервное копирование, эти диски монтируются на клиенте виртуальной машины резервного копирования. Это необходимо, чтобы клиент системы резервного копирования мог получить к ним доступ как к локальным дискам. Если клиент резервного копирования работает под управлением Windows, то Windows попытается автоматически смонтировать вновь добавленный диск в операционную систему и назначит букву этому диску, что для системы резервного копирования нежелательно. Поэтому нам необходимо отключить автоматическое монтирование виртуальных жестких дисков при использовании транспорта HotAdd. Чтобы это сделать, на виртуальной машине-клиенте системы резервного копирования под управлением операционной системы семейства Windows нужно воспользоваться утилитой командной строки diskpart и выполнить следующие команды.

    Запуск утилиты

C:\>diskpart

DISKPART>

    Отключение автоматического монтирования на клиенте резервного копирования.

DISKPART> automount disable

	Предотвращение повторного подключения всех ранее подключенных дисков при следующем использовании.

DISKPART> automount scrub

    Выход из утилиты.

DISKPART> exit

Таким образом, у нас появляется возможность напрямую работать с виртуальными жесткими дисками, то есть, например, сделать их бэкап, читая непосредственно содержимое этих дисков и передавая данные на медиа-сервер системы резервного копирования, минуя промежуточное файловое хранилище на локальном диске виртуальной машины-клиента системы резервного копирования. С другой стороны, это исключает работу только с аллоцированными данными виртуальных жестких дисков; работать придется с таким диском целиком, в так называемом raw формате. Для модуля rb_module_vmware_vm доступна специальная опция бэкапа, определяющая режим работы модуля при использовании технологии HotAdd. Она называется use_hotadd. Если опция use_hotadd имеет значение true, то модуль осуществляет бэкап дисков, присоединенных по технологии HotAdd, целиком, то есть в raw формате. Если же опция use_hotadd имеет значение false, то модуль осуществляет бэкап дисков с использованием методов VixDiskLib_Read, и в этом случае доступна опция backup_whole_disk, определяющая, будет ли выполнен дамп диска целиком или только аллоцированных его частей. Стоит учитывать, что использование опции use_hotadd исключает использование функционала Change Block Tracking (CBT) платформы виртуализации VMware. Из этого следует, что если для виртуальной машины и её дисков включён механизм CBT, то при использовании опции use_hotadd создание инкрементных резервных копий может работать медленнее, чем в ситуации, когда опция use_hotadd не используется.

Но как же отличить модулю на уровне операционной системы тот диск, который был ранее подключен системой резервного копирования по технологии HotAdd, от других дисков внутри операционной системы, где работает клиент системы резервного копирования? Ранее в статье уже упоминалось, что у любого виртуального жесткого диска виртуальной машины VMware есть метаданные, которые можно запросить с помощью vixDiskLib. Среди этих метаданных есть и уникальный идентификатор диска, который обозначается параметром с именем uuid. Так вот, этот параметр и является тем уникальным идентификатором, который используется в качестве WWN или WWID диска внутри операционной системы виртуальной машины клиента системы резервного копирования. Подробнее о WWN, также известном как WWID, можно прочесть тут. Внутри операционной системы WWN у любого диска можно узнать с помощью утилит командной строки, например lsscsi.

Замеры производительности HotAdd

Для демонстрации особенностей создания резервных копий с использованием технологии HotAdd и опции бэкапа use_hotadd модуля rb_module_vmware_vm была создана виртуальная машина с размером диска 10Gb, который был заполнен на 95% от номинального объема. При бэкапе виртуальной машины с параметром backup_whole_disk=false этот процент можно узнать в журнальном файле модуля rb_module_vmware_vm на узле клиента РуБэкап модуля /opt/rubackup/log/rb_module_vmware_vm.bin.log. Хост клиента имел 4 ядра CPU 2.4 Ггц и 12 Гб RAM. Для полноты картины приведем все параметры запуска модуля rb_module_vmware_vm: rbd_hash_algorithm:sha2, rbd_hash_length:256, rbd_block_size:16384, rbd_block_size:16384, rbd_transfer_buffer_size:104857600, worker_parallelism:8, memory_threshold:4 ,buffer_size:1000000, timeout:20, workers:4. Более подробная информация о данных параметрах доступна по ссылке. Все остальные параметры имеют значения по умолчанию. Было сделано 5 полных резервных копий с одинаковыми параметрами и усредненные значения занесены в таблицу ниже:

Необходимо учитывать, что при использовании опции use_hotadd со значением true, значение опции backup_whole_disk принудительно устанавливается в true. Также нужно учитывать, что опцию backup_whole_disk со значением false нет смысла использовать на хранилищах данных типа NFS, так как там аллокация любого виртуального жесткого диска всегда будет 100%.

Какие же выводы можно сделать из таблицы выше? 

1. Подключение и отключение виртуальных жестких дисков при использовании транспорта HotAdd во много раз дольше, чем при использовании транспорта nbdssl. Поэтому, если у виртуальной машины, для которой нужно сделать резервную копию, много дисков, то их подключение и отключение может занять продолжительное время.

2. Создание полных резервных копий виртуальных жестких дисков на локальные диски клиента системы резервного копирования работает быстрее при использовании транспорта HotAdd, чем при использовании транспорта nbdssl.

При работе с vixDiskLib версии 8 вы можете столкнуться с падением вашего приложения из-за ошибки в vixDiskLib. Ошибка происходит в разделяемой библиотеке libdiskLibPlugin.so и связана с тем, что библиотека пытается найти каталог /sys/class/scsi_disk, и в случае, если этот каталог не найден, происходит ошибка сегментации. Библиотека libdiskLibPlugin.so нужна vixDiskLib для поддержки продвинутых транспортов HotAdd и SAN. Ошибка происходит, если при инициализации библиотеки в вызове функции VixDiskLib_Connect не указан никакой транспорт. В этом случае для списка транспортов библиотекой vixDiskLib используется значение по умолчанию file:san:hotadd:nbdssl:nbd. Также ошибка возможна, если пользователь библиотеки vixDiskLib указал среди требуемых транспортов SAN. Чтобы избавиться от ошибки, требуется указать библиотеке список поддерживаемых транспортов без SAN.

Инсайты HotAdd

Диагностировать работу HotAdd можно через временные файлы, которые создает технология HotAdd внутри той виртуальной машины, в которой она используется. В данном случае это виртуальная машина клиента системы резервного копирования. Все дальнейшее в этом разделе будет актуально только для vixDiskLib версии 7. В процессе своей работы vixDiskLib в системном временном каталоге создает служебную папку с именем vmware-<USER>, где USER – это имя пользователя, из-под которого работает процесс, использующий библиотеку vixDiskLib. На Linux обычно это папка /tmp/vmware-root. При работе с дисками виртуальной машины в режиме HotAdd в папке /tmp/vmware-root создается папка вида UUID-MoRef, где UUID – идентификатор, созданный на основе данных текущего хоста, а MoRef – это идентификатор виртуальной машины, с дисками которой производятся операции транспортом HotAdd. Внутри этой папки создается еще несколько папок, в частности папка вида LOCK.lck/M11111.lck, которая содержит лок-файл, привязанный к процессу, использующему библиотеку vixDiskLib. Также там создается папка hotadd, внутри которой располагается файл unmount.dat, содержащий информацию о присоединенном диске.

diskhandle
{specType:0,ssId:,spec:{vmxSpec:moref=vm-111}}
hotadd

Там же создается папка VmdkStubs, которая содержит более подробную информацию о присоединенном по технологии HotAdd диске. Этот файл называется scsi0-0-0-vm_name.vmdk и, по сути, является несколько модифицированной версией файла конфигурации диска VMDK, который хранится на удаленном датасторе и описывает конфигурацию виртуального жесткого диска. В частности, в отличие от исходного файла, локальный файл имеет значение параметра createType не vmfs, а fullDevice. Также этот файл содержит имя устройства в нотации операционной системы, которое получил присоединенный диск, UUID (который мы упоминали выше) и много другой информации. Кроме того, рядом в папке хранится лок-файл, но уже не для всей виртуальной машины, а только для этого конкретного диска.

# tree -al /tmp/vmware-root
/tmp/vmware-root/
└── 164d3940-1bd0-1c30-18b0-1b56dc2ce140-vm-111
    ├── hotadd
    │   ├── unmount.dat
    │   └── VmdkStubs
    │       ├── scsi0-0-0-vm_name.vmdk
    │       └── scsi0-0-0-vm_name.lck
    │           └── M22222.lck
    └── LOCK.lck
        └── M11111.lck

5 directories, 4 files

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

Итого

В данной статье были рассмотрены технология VMware HotAdd и использующий ее параметр модуля rb_module_vmware_vm use_hotadd. Мы рассмотрели примеры использования технологии HotAdd, ее преимущества и особенности применения. В качестве подтверждения, в статье были приведены замеры производительности работы модуля rb_module_vmware_vm с различными наборами входных параметров. В конце мы рассказали об особенностях библиотеки vixDiskLib, а именно о составе и структуре временной информации, которая создается и используется библиотекой в процессе своей работы. Это можно использовать в своей работе для получения максимальной производительности в задачах, а также для обхода подводных камней и ограничений различных технологий.