Veeam V10. Proxy на Linux системах

В одной из предыдущих тем мы обсуждали новшества, которые принесло 10-е обновление системы резервного копирования Veeam Availability Suite. Одним из новшеств является, несомненно, прокси сервер, размещенный на Linux платформе.

Под катом мы пройдемся по этапам настройки данного прокси, и проверим его работоспособность.

Для начала стоит пройтись по ограничениям, которые накладывает на нас использование Linux прокси в данный момент:

1. Поддерживается только режим Virtual Appliance, он же HotAdd;
2. Отсутствует интеграция с СХД;
3. Отсутствует возможность резервного копирования файловых шар (NAS).

Достаточно серьезные ограничения, учитывая мою не особую любовь к HotAdd, но, я думаю, что в ближайших версиях функционал будет развиваться и появятся всеми любимые интеграции с СХД, Direct SAN, NBD.

Настройка прокси:

В лабораторных исследованиях выступает сервер VBR с лицензий Enterprise Plus, максимально доступной на момент написания статьи версии 10.0.0.4461. В качестве прокси сервера мы будем использовать CentOS Linux 7.7 minimal с последними обновлениями пакетов и ядра.

Предварительно, поскольку это тестовая инсталляция, я отключил на сервере с CentOS брандмауэр и Selinux. Обычно, так делать не стоит и лучше открыть только рекомендуемые порты.

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

Далее указывается адрес управляемого Linux сервера, логин, пароль для доступа по SSH. Ничего нового.

В остальном же, процесс добавления прокси аналогичен. Если появляется сообщение: ”Failed to get disk UUIDs from Guest OS <..> Do you want to specify the proxy VM manually?”.

Необходимо либо добавить данный параметр в Advanced Settings виртуальной машины, либо указать виртуальную машину, которая является прокси, в списке следующего диалогового окна. Я добавил параметр в VM:

Далее наш прокси будет перезагружен:

И получаем информацию о том, что все прошло успешно:

Далее, добавим бэкапный репозиторий на той же самой Linux машине. Процесс добавления репозитория аналогичен прошлой версии. Единственный момент, необходимо установить пакет perl-Data-Dumper, который не включен в поставку минимальной версии системы. Данный пакет, конечно, потянет за собой ряд зависимостей.

[root@vbr-proxy ~]# yum -y install perl-Data-Dumper

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

Делается это нажатием правой кнопки мыши по названию репозитория.

Теперь создадим задачу резервного копирования и проверим работоспособность решения. В задаче я указал созданный на базе Linux репозиторий:

Запускаем задачу и наблюдаем. Резервное копирование идет аналогично, никаких отличий от прокси под управлением Windows. Прокси выбрал режим HotAdd для резервного копирования:

Вывод lsblk в момент выполнения резервного копирования методом HotAdd на прокси:

sdd, sde и пр. – диски бэкапируемых виртуальных машин.

В случае, если возникли проблемы с резервным копированием, логи задач доступны по адресу /var/log/VeeamBackup/Job_Name/. Так же, некоторую информацию можно найти в файле /var/log/messages

Как можно заметить, Linux Proxy вполне работоспособен. Далее перейдем к небольшим проверкам.

Сравнение Linux и Windows Proxy в работе:

Для проверки я создал аналогичную задачу резервного копирования, при этом используя прокси сервер и репозиторий под управлением MS Windows 20012.

Дано:

1. Прокси сервер + репозиторий под управлением CentOS 7.7. 8vCPU, 8GBMem;
2. Прокси сервер + репозиторий под управлением Windows Server 2012. 8vCPU, 8GB Mem;

Тест 1. 8 маленьких полупустых виртуальных машин

Результаты для режима HotAdd. 8 почти пустых виртуальных машин. Общим объемом 130GB.

	Linux	Windows
Processing Rate	111MB/s	171MB/s
Duration	00:07:30	00:08:57
Bottleneck	Source	Network

И вот, первый интересный момент. Сразу видно, что Processing Rate при Windows Proxy у нас выше, при этом время выполнения задачи – дольше. Разбираемся.

Скорость чтения диска при использовании Linux колеблется от машины к машине в диапазоне от 40 до 70MB/s

Аналогичные показатели той же машины для Windows:

Возникает вопрос – если обработка идет быстрее, в чем загвоздка? Судя по отчету, Windows Proxy затрачивает больше времени на монтирование диска в режиме HotAdd, чем прокси под управлением Linux:

Windows:

Linux:

Данный показатель одинаковый для всех машин. У Linux 10-15 секунд, в Windows от 10 секунд до 4 минут.

Результат: На небольших машинах в режиме HotAdd Linux прокси показывает себя быстрее, за счет более быстрой скорости монтирования дисков к прокси.

Тест 2. 3 машины побольше

В данном тесте используется 3 клонированные виртуальные машины с несколькими дисками разного объема. Один из дисков заполнен на ~150GB случайными данными. Диски машин лежат на разных хранилищах, с разной производительностью. Суммарный объем машин ~900GB.

	Linux	Windows
Processing Rate	168MB/s	165MB/s
Duration	00:45:53	00:50:16
Bottleneck	Source	Nework

На большей дистанции оба прокси показываю себя почти одинаково. Явного лидера нет.

Тест 3. Обменяемся репозиториями

Изменим правила. Для прокси под управлением Linux назначим репозиторий от сервера Windows и наоборот. Не забываем так же изменить настройки Affinity.

	Linux	Windows
Processing Rate	115MB/s	116MB/s
Duration	1:05:22	1:07:33
Bottleneck	Source	Proxy

Результат аналогичный, равные показатели по времени и скорости резервного копирования.

Тест 4. Восстановление

В данном тесте я восстанавливаю одну виртуальную с заполняемостью ~150GB из 300.

	Linux	Windows
Processing Rate	103MB/s	140MB/s
Duration	0:48:13	00:38:04

В моей тестовой среде прокси сервер под управлением Windows показал себя быстрее. Скорость процессинга дисков была выше примерно на 15-20%. Тест проводил несколько раз. Результат примерно одинаковый.

В качестве заключения:

На момент написания статьи, прокси сервер под управлением Linux показывает себя работоспособным решением, однако, с очень ограниченным функционалом.

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

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

В целом, я считаю на данный момент Linux Proxy вполне применим в небольших инсталляциях, где не используются интеграции с СХД, Direct SAN. Его ограниченный функционал (который, как я думаю, будет расширен в ближайших релизах) прекрасно нивелируется отсутствием в необходимости приобретения лицензий на MS Windows.