Нагрузочное тестирование VBR для VMware

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

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

• Изучение документации и лучших практик по продуктам Veeam
• Разработку архитектуры 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 не получится.

Подробнее тут
blog.selectel.ru/nagruzochnoe-testirovanie-vbr-dlya-vmware/