Транспортные протоколы резервного копирования VMware

Всем привет! Сегодня хочу рассказать про транспортные протоколы резервного копирования VMware. Данная информация на мой взгляд поможет лучше понимать процессы в ESXI.Вы сможете лучше понимать ошибки, которых могут возникать в Veeam Backup при бэкапе, осознаете, какие службы можно отключать, а какие нет. Вообще тема связанная с системами хранения данных очень интересная и обширная, и ее полезно знать, как администраторам по виртуализации, так и администраторам баз данных, так как и в том и в другом случае, в своих сервисах и серверах они будут использовать ее мощности, и если они понимают ее правильную настройку, то это залог успеха.

NBD (Network Block Device) является наиболее универсальным и доступным для любых видов СХД и окружений. При его использовании поток данных с СХД проходит через гипервизор ESXi и направляется на сервер резервного копирования по локальной сети. На практике его не рекомендуют использовать, если есть возможность работы с протоколами SAN и HotAdd, превосходящими его по разным отзывам от двух до десяти и более раз по скорости передачи данных.
SAN – используется при прямом подключении сервера резервного копирования в сеть хранения данных. Для его использования серверу РК необходим прямой доступ к томам с VMFS, что накладывает требования на конфигурирование хоста и ограничение доступа к нему. Для Windows необходимо отключить автоматическую инициализацию дисков во избежание перетирания сигнатур и метаданных VMFS. И разумеется никто не хочет, чтобы чьи-то неумелые или напротив, опытные, но зловредные потерли сами данные. Возможно предварительно их утащив.

В случае с Fiber Channel сетью сервер РК должен быть физическим и физически подключен в оптическую фабрику. В процессе резервного копирования гипервизор сообщает какие блоки необходимо забирать с тома VMFS и сервер РК читает их с СХД самостоятельно. Скорость резервного копирования ограничена лишь нагрузкой на СХД и способностью сервера РК справиться с потоком данных. Влияние гипервизора в данном случае минимально.

Несмотря на очевидное преимущество SAN протокола, не все так просто. Идеальным вариантом он является только при восстановлении толстых (thick) дисков, но наихудшим для тонких из-за постоянных вызовов API дискового менеджера (AllocateBlock, ClearLazyZero). В случае восстановления тонких дисков предпочтительно использовать NBD.

Также при восстановлении по SAN необходимо отключать CBT. Также не поддерживается запись в redo логи (снапшоты), восстановление идет только базовых дисков.
Особая тонкость в том, что размер диска должен быть точно кратен размеру блоку VMFS, иначе последний блок не сможет быть записан и весь процесс упадет с ошибкой "Invalid Argument". Для обхода этой проблемы софт резервного копирования должен дописать в конец блока недостающие нули.

HotAdd – способ, при котором к специальной виртуальной машине-прокси на горячую подключаются виртуальные диски целевой виртуальной машины, после чего прокси машина пересылает данные по локальной сети на сервер РК. Прокси может выполнять компрессию и дедупликацию данных при пересылке, в зависимости от используемого продукта РК. Роль прокси и сервера РК может быть также совмещена. Несмотря на использование дискового стека гипервизора для доступа к данным, скорость на практике практически равна варианту SAN.

В случае VMFS3 располагайте прокси на томах с большим размером блока VMFS, чтобы быть в состоянии бэкапить и восстанавливать очень большие файлы. Для VMFS5 размер блока унифицирован и эта рекомендация более неактуальна.

Поскольку при работе HotAdd создаются redo логи, не удаляйте подключенную ВМ пока не завершится процесс резервного копирования. Иначе гипервизор потом не сможет правильно обработать redo логи и диски от прокси придется отключать вручную. (!) Не удаляйте снапшоты до окончания резервного копирования (!)

Материал сайта pyatilistnik.org

Транспортные протоколы резервного копирования VMware

Популярные Похожие записи: