Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware посредством Veeam® Backup&Replication™ (далее VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:

• Изучение документации и лучших практик по продуктам Veeam
• Разработку архитектуры VBR уровня сервис-провайдера
• Развертывание инфраструктуры VBR
• Тестирование решения, определение оптимальных настроек и режимов работы
• Запуск решения в промышленную (коммерческую) эксплуатацию

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

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

Здесь вы сможете увидеть:

• Описание production-инфраструктуры Selectel, использованной для тестирования
• Особенности работы бэкап-прокси (backup proxy) в различных транспортных режимах
• Описание программы тестирования и настроек компонентов VBR для её реализации
• Количественные показатели, их сравнение и выводы

Конфигурация инфраструктуры для проведения тестов

Инфраструктура-источник

В качестве платформы для тестирования производительности VBR выступил один из production-кластеров публичного Облака на базе VMware.

• Аппаратная конфигурация хостов данного кластера:
• Процессоры Intel® Xeon® Gold 6140
• NVMe-накопители Intel® DC P4600 и P3520
• 4 порта 10GbE на хост

В основе кластера лежат следующие решения:

• Физическая сеть – Ethernet-фабрика на коммутаторах Brocade VDX, архитектура Leaf-Spine (10GbE порты – подключение хостов, 40GbE аплинки до Spine)
• Среда виртуализации – VMware vSphere® 6.5
• Хранение данных ВМ – VMware vSAN™ 6.6 (All-Flash кластер vSAN)
• Виртуализация сети – VMware NSX® 6.4

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

Вместе с Облаком на базе VMware, Selectel запустил услугу для его бэкапа на платформе VBR. Заказчики получают web-портал самообслуживания, в котором могут выполнять бэкап и восстановление vApp и ВМ из своих VDC (виртуальный дата-центр).

Доступ клиентов к данному порталу (Veeam® Enterprise Manager Self-service portal) осуществляется с теми же правами, что и к vCloud Director® (vCD). Это возможно благодаря интеграции Veeam® Backup Enterprise Manager (EM) и vCD, при этом каждый клиент при подключении к ЕМ ограничен ресурсами своих VDC, чужие ВМ он не увидит.

Клиенту не нужно разворачивать собственный VBR и связанную с ним инфраструктуру бэкапа, что предполагает затраты на вычислительные и сетевые ресурсы, хранилище, лицензии Veeam и MS, администрирование. Это долго, дорого и сложно. Selectel предоставляет основные возможности VBR как услугу BaaS (Backup-as-a-Service): мгновенно, просто, удобно, экономично.

Для предоставления данной услуги в Selectel была развернута провайдерская инфраструктура VBR, охватывающая все кластеры vSphere и VDC клиентов облака VMware, в том числе кластер, в котором проводилось данное тестирование. Таким образом, результаты тестов позволят судить о максимальной скорости, с которой клиенты смогут бэкапить свои ВМ.

Тестовые ВМ

Для тестирования производительности бэкапа в кластере vSphere было развернуто 6 идентичных ВМ в следующей конфигурации:

• ОС Windows Server 2016, 2 vCPU, 4GB RAM
• 200GB vDisk

Диск занят почти полностью – 193GB. Кроме файлов ОС, на нем создана папка с дистрибутивами различных ОС и СУБД объёмом 60GB (уникальные данные). На том же диске создано 3 копии данной папки – итого 180GB несистемных данных.

Никаких приложений на эти ВМ установлено не было, только «чистая» ОС и «холодные» данные. Никакой нагрузки, вычислительной или сетевой, не запускалось. В рамках данного тестирования этого не требовалось.

В кластере vSphere включен DRS, поэтому тестовые ВМ автоматически оптимально распределяются по хостам VMware ESXi™ для балансировки нагрузки.

Бэкап-прокси

ВМ с бэкап-прокси развернута непосредственно в описанном выше кластере vSphere (инфраструктура-источник, далее – кластер vSphere), это необходимое условие для тестирования в режиме Virtual Appliance.

Конфигурация ВМ:

• 8 vCPU
• 8GB RAM
• 40GB vDisk
• 10GbE vNIC vmxnet3
• ОС Windows Server 2016

Параметр «Max concurrent tasks» для бэкап-прокси на уровне VBR выставлен в значение 6. Это значит, что бэкап-прокси сможет одновременно (параллельно) обрабатывать до 6 задач (task) бэкапа. Один task – это бэкап одного виртуального диска ВМ.

Репозиторий бэкапа

В качестве фронтенда хранилища бэкапов выступает физический сервер, выполняющий роль бэкап-репозитория VBR. Конфигурация сервера:

• CPU Е5-1650v3
• 32GB RAM
• 2 порта 10GbE

Бекенд хранилища – кластер CephFS c NVMe-кэшем.

Бэкап-репозиторий и узлы Ceph общаются по сети 10GbE, каждый из них подключен к коммутаторам двумя портами.

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

Параметр «Limit maximum concurrent tasks» для бэкап-репозитория на уровне VBR выставлен в значение 6. Это значит, что бэкап-репозиторий сможет одновременно (параллельно) обрабатывать до 6 задач (tasks) бэкапа.

Сеть бэкапа

Физическая сеть описанной выше инфраструктуры ограничена полосой пропускания 10Гбит/с, везде используются коммутаторы и порты 10GbE. Это справедливо не только для сети vSAN, но и для менеджмент-интерфейсов хостов ESXi.

Для размещения бэкап-прокси на уровне VMware NSX создана выделенная подсеть со своим логическим коммутатором. Для её связности с физикой и осуществления маршрутизации развернут NSX-edge, размер X-large.

Забегая вперед, по результатам тестов видно, что сеть выдерживает нагрузку до 8Гбит/с. Это весьма солидная пропускная способность, которой на данном этапе хватает, при необходимости она может быть увеличена.

Схема взаимодействия компонент

Бэкап-прокси и тестовые ВМ развернуты внутри одного кластера VMware vSAN. После запуска задания бэкапа (бэкап-джобы) в зависимости от выбранного транспортного режима, особенности которых рассмотрены ниже, бэкап-прокси:

• Извлекает данные из бэкапируемых ВМ по сети vSAN (HotAdd) или по сети управления (NBD)
• Передает обработанные данные на бэкап-репозиторий по выделенной для этой цели подсети

Транспортные режимы бэкап-прокси

Бэкап-прокси (Backup proxy) является компонентом инфраструктуры VBR, непосредственно выполняющим обработку задания бэкапа. Он извлекает данные из ВМ, обрабатывает их (сжимает, дедуплицирует, шифрует) и отправляет на репозиторий, где они сохраняются в файлы бэкапа.

Бэкап-прокси позволяет работать в трёх транспортных режимах:

• Direct storage access
• Virtual appliance
• Network

Облако на базе VMware Selectel в качестве хранилища использует vSAN, в такой конфигурации Direct storage access не поддерживается, поэтому данный режим не рассматривается и не был протестирован. Оставшиеся два режима замечательно работают на каждом из наших кластеров vSphere, остановимся на них подробнее.

Режим Virtual appliance (HotAdd)

Virtual appliance – рекомендуемый режим при развертывании бэкап-прокси в виде ВМ. Хосты ESXi, на которых развернуты бэкап-прокси, должны иметь доступ ко всем Datastore кластера vSphere, хранящим бэкапируемые ВМ. Суть режима заключается в том, что прокси монтирует к себе диски бэкапируемых ВМ (VMware SCSI HotAdd) и забирает с них данные как с собственных. Извлечение данных происходит с Datastore по сети хранения.

В нашем случае бэкап-прокси ВМ должна находиться на одном из хостов ESXi кластера vSAN, который мы бэкапим. Извлечение данных происходит по сети vSAN. Таким образом, для работы в режиме Virtual appliance в каждом кластере vSAN должно быть развернуто минимум по одному бэкап-прокси. Развернуть пару бэкап-прокси (например, в менеджмент-кластере) и бэкапить ими все кластеры vSAN не получится.

Плюсы	Минусы
Быстрый, как правило, значительно быстрее NBD, особенно в случае полного бэкапа или больших инкрементов. По скорости может уступать только Direct storage access.	Операция монтирования дисков (HotAdd) к прокси может занимать до 2 минут на диск. При инкрементном бэкапе небольших порций данных NBD может оказаться быстрее.
Утилизирует сеть хранения. Не грузит менеджмент-интерфейс и гипервизор.	Прокси-ВМ потребляет часть ресурсов хоста. Иногда могут быть проблемы с удалением снапшотов.

Режим Network (NBD)

Является самым простым и универсальным режимом, подходит как для физических, так и для виртуальных бэкап-прокси. Извлечение данных, в отличие от предыдущих двух режимов, происходит не по сети хранения. Бэкап-прокси забирает данные ВМ, подключаясь к менеджмент-интерфейсу хостов ESXi, на которых они крутятся.

Такой подход имеет следующие недостатки:

• Зачастую интерфейсы управления ESXi висят не на самых быстрых аплинках, как правило, это 1GbE
• Даже если менеджмент-интерфейс будет иметь 10GbE порты, ESXi не отдаст прокси всю полосу целиком — он искусственно её ограничивает и выделяет под бэкапы лишь некоторую часть пропускной способности интерфейса

Плюсы	Минусы
Простой и универсальный. Прокси может быть физическим и виртуальным.	Как правило, значительно медленнее HotAdd, особенно на больших объёмах бэкапа и малом количестве параллельных задач (tasks).
Быстро стартует, отсутствие задержки на монтирование дисков. Нет проблем со снапшотами.	Создает нагрузку (небольшую) на интерфейс управления и гипервизор.

При этом, многие источники утверждают, что NBD очень медленный на 1GbE, но на 10GbE может быть достаточно быстрым. Это мы обязательно проверим.

Программа тестирования

На описанной выше инфраструктуре необходимо выполнить бэкап тестовых ВМ и зафиксировать следующие показатели:

• Нагрузка на CPU, %
• Потребление RAM, GB
• Нагрузка на сеть, Гбит/с
• Производительность бэкапа, МБ/с
• Время бэкапа, мм: сс

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

Показатели должны быть зафиксированы для Virtual appliance и Network режимов работы бэкап-прокси. Каждый раз должен выполняться полный бэкап, никаких инкрементов.

Таким образом, необходимо создать 4 задания бэкапа (backup job):

• Для одной тестовой ВМ
• Для двух тестовых ВМ
• Для четырех тестовых ВМ
• Для шести тестовых ВМ

В рамках тестирования необходимо:

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

В настройках каждого задания необходимо вручную выбрать бэкап-прокси, подготовленный для тестирования, поскольку в общей VBR-инфраструктуре он не единственный, а по умолчанию прокси выбирается автоматически.

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

Наиболее интересный показатель – средняя скорость или производительность бэкапа. Его можно увидеть в результатах выполнения задания в консоли VBR. Там же будет показано время выполнения бэкапа.

Кроме того, необходимо оценить нагрузку на бэкап-прокси в каждом из тестов. Показатели загруженности процессора, памяти и сети можно отслеживать с помощью инструментов гостевой ОС (Windows 2016) и на уровне VMware.

На бэкап-прокси и бэкап-репозитории параметр максимального количества одновременных задач выставлен в значение 6. Это значит, что в рамках тестирования все ВМ в каждом задании будут обрабатываться параллельно, ни одна из них не будет ждать в очереди, производительность будет максимальной.

Veeam® рекомендует, чтобы количество параллельных задач не превышало количество процессорных ядер на прокси и репозитории. Рекомендуемый объем ОЗУ на репозитории – по 2ГБ на ядро, итого 12ГБ. Конфигурация инфраструктуры показывает, что все рекомендации соблюдены.

Скорость бэкапа и нагрузка в режиме Virtual Appliance (Hot Add)

Бэкап 1 ВМ

Бэкап 2 ВМ

Бэкап 4 ВМ

Бэкап 6 ВМ

Скорость бэкапа и нагрузка в режиме Network (NBD)

Бэкап 1 ВМ

Бэкап 2 ВМ

Бэкап 4 ВМ

Бэкап 6 ВМ

Сравнение производительности и нагрузки в режимах Virtual Appliance (HotAdd) и Network Mode (NBD)

Кол-во ВМ	Скорость – HotAdd, МБ/с	Скорость – NBD, МБ/с	HotAdd/NBD
1	709	192	3,69
2	816	269	3,03
4	885	446	1,98
6	888	517	1,72

Кол-во ВМ	Загрузка CPU – HotAdd, %	Загрузка CPU – NBD, %	HotAdd/NBD
1	55-95	18-24	3,06-3,96
2	70-100	25-33	2,8-3,03
4	100	45-55	1,82-2,22
6	100	50-70	1,43-2

Кол-во ВМ	Загрузка RAM – HotAdd, GB	Загрузка RAM – NBD, GB	HotAdd/NBD
1	2-2,2	1,9-2,1	1,05
2	2,3-2,5	2,2-2,4	1,04-1,05
4	3-3,5	2,8-3,5	1-1,07
6	4-4,2	3,5-4	1,14-1,05

Кол-во ВМ	Загрузка сети – HotAdd, Гб/с	Загрузка сети – NBD, Гб/с	HotAdd/NBD
1	4,7-6,4	1,2-1,8	3,56-3,92
2	5-7,7	1,5-2,5	3,08-3,33
4	5-8,2	2,8-4,5	1,79-1,82
6	5-8,2	3,5-5	1,43-1,64

Выводы по результатам тестирования

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

Напомню, что тесты для обоих режимов запускались в абсолютно идентичных условиях на одной и той же платформе. Пропускная способность сети также была одинаковой – интерфейсы управления, через которые прокси забирает данные в NBD-режиме, выдают 10 Гбит/с, как сеть vSAN для HotAdd-режима, никаких лимитов на полосу пропускания мы не устанавливали.

Очевидно, что ESXi действительно замедляет Veeam® и отдает ему лишь часть полосы в Network режиме, отсюда такие отличия в скорости бэкапа. Однако, с ростом количества потоков – одновременных задач бэкапа – Network режим ощутимо сокращает отставание.

Мы видим, что в режиме Virtual appliance уже на 4-х ВМ бэкап-прокси упирается в процессор, работать быстрее он не может, для 6-ти ВМ скорость бэкапа почти не изменилась. При этом скорость бэкапа 1-2 ВМ в этом режиме отстает незначительно, возможности бэкап-прокси и платформы используются по максимуму даже на малом количестве потоков.

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

Расход оперативной памяти бэкап-прокси невелик и примерно одинаков в обоих режимах.

Нагрузка на сеть бэкап-прокси коррелирует со скоростью бэкапа, превышая её на ~10-17%. Видимо прокси забирает данные с ВМ-источников несколько быстрее, чем заливает на репозиторий, поскольку их нужно обработать.

Интересно понаблюдать за строкой Load на картинках с результатами выполнения джоб. Она показывает уровень нагрузки на различные элементы инфраструктуры бэкапа: источник, прокси, сеть, репозиторий.

В режиме Virtual appliance мы видим, что производительность бэкапа упирается в прокси и сеть, они всегда примерно одинаково загружены. Источник и репозиторий не являются узким местом.

В Network режиме узким местом всегда является источник, даже для одного потока. Видно, что остальные элементы инфраструктуры могут выдать больше, но ESXi им не дает.

Резюме

Тестирование подтвердило, что бэкап-прокси в исследованных транспортных режимах на практике ведёт себя именно так, как это предполагает теория.

ПО Veeam® показало себя весьма достойно:

• В режиме HotAdd эффективно и полностью были утилизированы все возможности инфраструктуры
• В режиме NBD производительность ожидаемо скромнее, но это не проблема Veeam®, а особенность сетевого стека ESXi

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

На данный момент нас вполне устраивает имеющаяся производительность бэкапа, мы понимаем как правильно её увеличить при появлении такой необходимости.