Для резервного копирования виртуальных машин используется несколько транспортных протоколов – NBD, SAN, HotAdd.
NBD (Network Block Device) является наиболее универсальным и доступным для любых видов СХД и окружений. При его использовании поток данных с СХД проходит через гипервизор ESXi и направляется на сервер резервного копирования по локальной сети. На практике его не рекомендуют использовать, если есть возможность работы с протоколами SAN и HotAdd, превосходящими его по разным отзывам от двух до десяти и более раз по скорости передачи данных.
SAN – используется при прямом подключении сервера резервного копирования в сеть хранения данных. Для его использования серверу РК необходим прямой доступ к томам с VMFS, что накладывает требования на конфигурирование хоста и ограничение доступа к нему. Для Windows необходимо отключить автоматическую инициализацию дисков во избежание перетирания сигнатур и метаданных VMFS. И разумеется никто не хочет, чтобы чьи-то неумелые или напротив, опытные, но зловредные потерли сами данные. Возможно предварительно их утащив.
В случае с Fiber Channel сетью сервер РК должен быть физическим и физически подключен в оптическую фабрику. В процессе резервного копирования гипервизор сообщает какие блоки необходимо забирать с тома VMFS и сервер РК читает их с СХД самостоятельно. Скорость резервного копирования ограничена лишь нагрузкой на СХД и способностью сервера РК справиться с потоком данных. Влияние гипервизора в данном случае минимально.
Особая тонкость в том, что размер диска должен быть точно кратен размеру блоку VMFS, иначе последний блок не сможет быть записан и весь процесс упадет с ошибкой "Invalid Argument". Для обхода этой проблемы софт резервного копирования должен дописать в конец блока недостающие нули.
Несмотря на очевидное преимущество SAN протокола, не все так просто. Идеальным вариантом он является только при восстановлении толстых (thick) дисков, но наихудшим для тонких из-за постоянных вызовов API дискового менеджера (AllocateBlock, ClearLazyZero). В случае восстановления тонких дисков предпочтительно использовать NBD.
Также при восстановлении по SAN необходимо отключать CBT. Также не поддерживается запись в redo логи (снапшоты), восстановление идет только базовых дисков.Особая тонкость в том, что размер диска должен быть точно кратен размеру блоку VMFS, иначе последний блок не сможет быть записан и весь процесс упадет с ошибкой "Invalid Argument". Для обхода этой проблемы софт резервного копирования должен дописать в конец блока недостающие нули.
HotAdd – способ, при котором к специальной виртуальной машине-прокси на горячую подключаются виртуальные диски целевой виртуальной машины, после чего прокси машина пересылает данные по локальной сети на сервер РК. Прокси может выполнять компрессию и дедупликацию данных при пересылке, в зависимости от используемого продукта РК. Роль прокси и сервера РК может быть также совмещена. Несмотря на использование дискового стека гипервизора для доступа к данным, скорость на практике практически равна варианту SAN.
В случае VMFS3 располагайте прокси на томах с большим размером блока VMFS, чтобы быть в состоянии бэкапить и восстанавливать очень большие файлы. Для VMFS5 размер блока унифицирован и эта рекомендация более неактуальна.
Поскольку при работе HotAdd создаются redo логи, не удаляйте подключенную ВМ пока не завершится процесс резервного копирования. Иначе гипервизор потом не сможет правильно обработать redo логи и диски от прокси придется отключать вручную. (!) Не удаляйте снапшоты до окончания резервного копирования (!).
Сообщения
