Requirements and Limitations for VMware Backup Proxies
Before you assign the role of a VMware backup proxy, check the following prerequisites and limitations.
The following list shows possible connections between the machine and storage that keeps backups of this machine. The first connection is the most efficient, the last one is the least efficient.
- A machine used as a VMware backup proxy should have direct access to the storage on which VMs reside or the storage where VM data is written. This way, the VMware backup proxy will retrieve data directly from the datastore bypassing LAN.
- The VMware backup proxy can be a VM with HotAdd access to VM disks on the datastore. This type of proxy also enables LAN-free data transfer between the host and the VMware backup proxy.
- If neither of the above scenarios is possible, you can assign the role of the VMware backup proxy to a machine whose network is located closer to the source or the target storage to which the proxy will connect. In this case, VM data will be transported over LAN using the NBD protocol.
General Requirements and Limitations
- The role of a VMware backup proxy can be assigned to the following machines:
- Physical or virtual Microsoft Windows machine
- Physical or virtual Linux machine
- Before assigning the role of the VMware backup proxy to a machine, you must first add a vCenter server to the backup infrastructure.
- The machine must meet the system requirements. For more information, see System Requirements .
- The account that you specify when adding a server must have permissions described in Permissions .
- It is recommended that you balance the number of tasks on backup proxies and backup repository to avoid the situation where some backup infrastructure resources remain idle while others are overloaded.
- You must add the machine to the Veeam Backup & Replication console as a managed server.
- If you back up proxies that use the Virtual appliance (Hot-Add) mode to process VM data, the change block tracking mechanism (CBT) will be disabled. For more information on CBT, see Changed Block Tracking .
- If you back up encrypted VMs that use the Virtual appliance (Hot-Add) mode, make sure backup proxies are also encrypted. For more information, see Encrypted VMs .
- A VMware backup proxy should be as close to the source data as possible with a high bandwidth connection. Consider a good connection between proxy and repository.
In addition to the general requirements and limitations, the following ones apply to Linux backup proxies:
- Linux backup proxies use the transport service for connection with backup infrastructure components. If the transport service cannot be installed, Linux backup proxy require SSH connection.
- You can assign the role of a VMware backup proxy to a Linux server added with single-use credentials, for example, a Linux server used as a hardened repository. For this configuration, only the Network mode (NBD) is supported, other transport modes will not be available for selection.
- Linux backup proxies cannot be used with VMware Cloud on AWS. This is because VDDK settings required by VMware cannot be enabled on Linux backup proxies.
- Linux backup proxies that use virtual appliance (Hot-Add) transport mode do not support the VM copy scenario.
- Linux backup proxies cannot be used for guest interaction.
- For Direct SAN with iSCSI access , note that Linux backup proxies must have the Open-iSCSI initiator enabled.
- For Direct NFS access , consider the following:
- Linux backup proxies must have NFS client package installed.
- Debian-based backup proxies must have the nfs-common package installed.
- RHEL-based backup proxies must have the nfs-utils package installed.
- See recommendations for VMware backup proxy parameters in the Veeam Backup & Replication Best Practice Guide .
Veeam V10. Proxy на Linux системах
В одной из предыдущих тем мы обсуждали новшества, которые принесло 10-е обновление системы резервного копирования Veeam Availability Suite. Одним из новшеств является, несомненно, прокси сервер, размещенный на Linux платформе.
Под катом мы пройдемся по этапам настройки данного прокси, и проверим его работоспособность.
Для начала стоит пройтись по ограничениям, которые накладывает на нас использование Linux прокси в данный момент:
- Поддерживается только режим Virtual Appliance, он же HotAdd;
- Отсутствует интеграция с СХД;
- Отсутствует возможность резервного копирования файловых шар (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.
- Прокси сервер + репозиторий под управлением CentOS 7.7. 8vCPU, 8GBMem;
- Прокси сервер + репозиторий под управлением 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:
Данный показатель одинаковый для всех машин. У 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.
2 thoughts on “Veeam V10. Proxy на Linux системах”
Добрый день
Случайно нашёл ваш сайт – читаю с большим интересом.
Спасибо за интересные и полезные статьи.
Хотелось бы спросить – а какие проблемы у вас есть с HotAdd? Почему он вам не нравится? У меня гораздо больше претензий к NBD…
Спасибо