Весной 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). |
| Быстро стартует, отсутствие задержки на монтирование дисков. Нет проблем со снапшотами. | Создает нагрузку (небольшую) на интерфейс управления и гипервизор. |
Программа тестирования
На описанной выше инфраструктуре необходимо выполнить бэкап тестовых ВМ и зафиксировать следующие показатели:
- Нагрузка на CPU, %
- Потребление RAM, GB
- Нагрузка на сеть, Гбит/с
- Производительность бэкапа, МБ/с
- Время бэкапа, мм: сс
Показатели должны быть зафиксированы для бэкапа одной тестовой ВМ и для параллельного бэкапа двух, четырех и шести тестовых ВМ.
Показатели должны быть зафиксированы для Virtual appliance и Network режимов работы бэкап-прокси. Каждый раз должен выполняться полный бэкап, никаких инкрементов.
Таким образом, необходимо создать 4 задания бэкапа (backup job):
- Для одной тестовой ВМ
- Для двух тестовых ВМ
- Для четырех тестовых ВМ
- Для шести тестовых ВМ
В рамках тестирования необходимо:
- Последовательно прогнать все задания в одном режиме
- Удалить созданные бэкапы, чтобы не было инкрементов
- Повторить прогоны во втором режиме, каждый раз фиксируя показатели
В настройках каждого задания необходимо вручную выбрать бэкап-прокси, подготовленный для тестирования, поскольку в общей VBR-инфраструктуре он не единственный, а по умолчанию прокси выбирается автоматически.
Режим работы бэкап-прокси по умолчанию также выбирается автоматически. Поэтому, в настройках бэкап-прокси перед каждым прогоном вручную выставляем нужный транспортный режим.
Наиболее интересный показатель – средняя скорость или производительность бэкапа. Его можно увидеть в результатах выполнения задания в консоли VBR. Там же будет показано время выполнения бэкапа.
Кроме того, необходимо оценить нагрузку на бэкап-прокси в каждом из тестов. Показатели загруженности процессора, памяти и сети можно отслеживать с помощью инструментов гостевой ОС (Windows 2016) и на уровне VMware.
На бэкап-прокси и бэкап-репозитории параметр максимального количества одновременных задач выставлен в значение 6. Это значит, что в рамках тестирования все ВМ в каждом задании будут обрабатываться параллельно, ни одна из них не будет ждать в очереди, производительность будет максимальной.
Veeam® рекомендует, чтобы количество параллельных задач не превышало количество процессорных ядер на прокси и репозитории. Рекомендуемый объем ОЗУ на репозитории – по 2ГБ на ядро, итого 12ГБ. Конфигурация инфраструктуры показывает, что все рекомендации соблюдены.
Скорость бэкапа и нагрузка в режиме Virtual Appliance (Hot Add)
Бэкап 1 ВМ
| Показатель | Значение |
| Нагрузка на CPU, % | 55-95 |
| Потребление RAM, GB | 2-2,2 |
| Нагрузка на сеть, Гбит/с | 4,7-6,4 |
| Показатель | Значение |
| Производительность бэкапа, МБ/с | 709 |
| Время бэкапа, мм: сс | 06:35 |
Бэкап 2 ВМ
| Показатель | Значение |
| Нагрузка на CPU, % | 70-100 (полка 100% с резкими короткими падениями до 70%) |
| Потребление RAM, GB | 2,3-2,5 |
| Нагрузка на сеть, Гбит/с | 5-7,7 |
| Показатель | Значение |
| Производительность бэкапа, МБ/с | 816 |
| Время бэкапа, мм: сс | 10:03 |
Бэкап 4 ВМ
| Показатель | Значение |
| Нагрузка на CPU, % | 100 (полка 100% с редкими небольшими падениями) |
| Потребление RAM, GB | 3-3,5 |
| Нагрузка на сеть, Гбит/с | 5-8,2 |
| Показатель | Значение |
| Производительность бэкапа, МБ/с | 885 |
| Время бэкапа, мм: сс | 17:10 |
Бэкап 6 ВМ
| Показатель | Значение |
| Нагрузка на CPU, % | 100 (полка 100% с редкими небольшими падениями) |
| Потребление RAM, GB | 4-4,2 |
| Нагрузка на сеть, Гбит/с | 5-8,2 |
| Показатель | Значение |
| Производительность бэкапа, МБ/с | 888 |
| Время бэкапа, мм: сс | 24:42 |
Скорость бэкапа и нагрузка в режиме Network (NBD)
Бэкап 1 ВМ
| Показатель | Значение |
| Нагрузка на CPU, % | 18-24 |
| Потребление RAM, GB | 1,9-2,1 |
| Нагрузка на сеть, Гбит/с | 1,2-1,8 |
| Показатель | Значение |
| Производительность бэкапа, МБ/с | 192 |
| Время бэкапа, мм: сс | 18:30 |
Бэкап 2 ВМ
| Показатель | Значение |
| Нагрузка на CPU, % | 25-33 |
| Потребление RAM, GB | 2,2-2,4 |
| Нагрузка на сеть, Гбит/с | 1,5-2,5 |
| Показатель | Значение |
| Производительность бэкапа, МБ/с | 269 |
| Время бэкапа, мм: сс | 25:50 |
Бэкап 4 ВМ
| Показатель | Значение |
| Нагрузка на CPU, % | 45-55 |
| Потребление RAM, GB | 2,8-3,5 |
| Нагрузка на сеть, Гбит/с | 2,8-4,5 |
| Показатель | Значение |
| Производительность бэкапа, МБ/с | 446 |
| Время бэкапа, мм: сс | 31:14 |
Бэкап 6 ВМ
| Показатель | Значение |
| Нагрузка на CPU, % | 50-70 |
| Потребление RAM, GB | 3,5-4 |
| Нагрузка на сеть, Гбит/с | 3,5-5 |
| Показатель | Значение |
| Производительность бэкапа, МБ/с | 517 |
| Время бэкапа, мм: сс | 40:02 |
Сравнение производительности и нагрузки в режимах 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
Мы получили реальные показатели производительности и нагрузки, что очень полезно для выбора оптимального режима эксплуатации и последующего масштабирования системы.
На данный момент нас вполне устраивает имеющаяся производительность бэкапа, мы понимаем как правильно её увеличить при появлении такой необходимости.
Комментариев нет:
Отправить комментарий