- PVSM.RU - https://www.pvsm.ru -
Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware [1] посредством Veeam® Backup&Replication™ (далее VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:
Как оказалось – не зря. Услуга стабильно функционирует, клиенты могут бэкапить свои виртуалки, а у нас появилась определенная экспертиза, которой мы хотим поделиться.
В этой статье мы хотим рассказать о результатах нагрузочного тестирования VBR для двух наиболее популярных режимов работы бэкап-прокси с учетом вариации количества параллельных задач.
Здесь вы сможете увидеть:
В качестве платформы для тестирования производительности VBR выступил один из production-кластеров публичного Облака на базе VMware [1].
В основе кластера лежат следующие решения:
Производительность платформы для тестирования более чем достаточна и не вызывает никаких сомнений. Конечно, для высокого быстродействия всё это должно быть правильно настроено, но поскольку это production, с живыми и довольными клиентами, можно быть уверенным, что и в этом плане всё хорошо.
Вместе с Облаком на базе VMware, Selectel запустил услугу [2] для его бэкапа на платформе 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 идентичных ВМ в следующей конфигурации:
Диск занят почти полностью – 193GB. Кроме файлов ОС, на нем создана папка с дистрибутивами различных ОС и СУБД объёмом 60GB (уникальные данные). На том же диске создано 3 копии данной папки – итого 180GB несистемных данных.
Никаких приложений на эти ВМ установлено не было, только «чистая» ОС и «холодные» данные. Никакой нагрузки, вычислительной или сетевой, не запускалось. В рамках данного тестирования этого не требовалось.
В кластере vSphere включен DRS, поэтому тестовые ВМ автоматически оптимально распределяются по хостам VMware ESXi™ для балансировки нагрузки.
ВМ с бэкап-прокси развернута непосредственно в описанном выше кластере vSphere (инфраструктура-источник, далее – кластер vSphere), это необходимое условие для тестирования в режиме Virtual Appliance.
Конфигурация ВМ:
Параметр «Max concurrent tasks» для бэкап-прокси на уровне VBR выставлен в значение 6. Это значит, что бэкап-прокси сможет одновременно (параллельно) обрабатывать до 6 задач (task) бэкапа. Один task – это бэкап одного виртуального диска ВМ.
В качестве фронтенда хранилища бэкапов выступает физический сервер, выполняющий роль бэкап-репозитория VBR. Конфигурация сервера:
Бекенд хранилища – кластер 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. После запуска задания бэкапа (бэкап-джобы) в зависимости от выбранного транспортного режима, особенности которых рассмотрены ниже, бэкап-прокси:
Бэкап-прокси (Backup proxy) является компонентом инфраструктуры VBR, непосредственно выполняющим обработку задания бэкапа. Он извлекает данные из ВМ, обрабатывает их (сжимает, дедуплицирует, шифрует) и отправляет на репозиторий, где они сохраняются в файлы бэкапа.
Бэкап-прокси позволяет работать в трёх транспортных режимах:
Облако на базе VMware Selectel в качестве хранилища использует vSAN [3], в такой конфигурации Direct storage access не поддерживается, поэтому данный режим не рассматривается и не был протестирован. Оставшиеся два режима замечательно работают на каждом из наших кластеров vSphere, остановимся на них подробнее.
Virtual appliance – рекомендуемый режим при развертывании бэкап-прокси в виде ВМ. Хосты ESXi, на которых развернуты бэкап-прокси, должны иметь доступ ко всем Datastore кластера vSphere, хранящим бэкапируемые ВМ. Суть режима заключается в том, что прокси монтирует к себе диски бэкапируемых ВМ (VMware SCSI HotAdd) и забирает с них данные как с собственных. Извлечение данных происходит с Datastore по сети хранения.
В нашем случае бэкап-прокси ВМ должна находиться на одном из хостов ESXi кластера vSAN, который мы бэкапим. Извлечение данных происходит по сети vSAN. Таким образом, для работы в режиме Virtual appliance в каждом кластере vSAN должно быть развернуто минимум по одному бэкап-прокси. Развернуть пару бэкап-прокси (например, в менеджмент-кластере) и бэкапить ими все кластеры vSAN не получится.
Плюсы | Минусы |
Быстрый, как правило, значительно быстрее NBD, особенно в случае полного бэкапа или больших инкрементов. По скорости может уступать только Direct storage access. | Операция монтирования дисков (HotAdd) к прокси может занимать до 2 минут на диск. При инкрементном бэкапе небольших порций данных NBD может оказаться быстрее. |
Утилизирует сеть хранения. Не грузит менеджмент-интерфейс и гипервизор. | Прокси-ВМ потребляет часть ресурсов хоста. Иногда могут быть проблемы с удалением снапшотов. |
Является самым простым и универсальным режимом, подходит как для физических, так и для виртуальных бэкап-прокси. Извлечение данных, в отличие от предыдущих двух режимов, происходит не по сети хранения. Бэкап-прокси забирает данные ВМ, подключаясь к менеджмент-интерфейсу хостов ESXi, на которых они крутятся.
Такой подход имеет следующие недостатки:
Плюсы | Минусы |
Простой и универсальный. Прокси может быть физическим и виртуальным. | Как правило, значительно медленнее HotAdd, особенно на больших объёмах бэкапа и малом количестве параллельных задач (tasks). |
Быстро стартует, отсутствие задержки на монтирование дисков. Нет проблем со снапшотами. | Создает нагрузку (небольшую) на интерфейс управления и гипервизор. |
При этом, многие источники утверждают, что NBD очень медленный на 1GbE, но на 10GbE может быть достаточно быстрым. Это мы обязательно проверим.
На описанной выше инфраструктуре необходимо выполнить бэкап тестовых ВМ и зафиксировать следующие показатели:
Показатели должны быть зафиксированы для бэкапа одной тестовой ВМ и для параллельного бэкапа двух, четырех и шести тестовых ВМ.
Показатели должны быть зафиксированы для Virtual appliance и Network режимов работы бэкап-прокси. Каждый раз должен выполняться полный бэкап, никаких инкрементов.
Таким образом, необходимо создать 4 задания бэкапа (backup job):
В рамках тестирования необходимо:
В настройках каждого задания необходимо вручную выбрать бэкап-прокси, подготовленный для тестирования, поскольку в общей VBR-инфраструктуре он не единственный, а по умолчанию прокси выбирается автоматически.
Режим работы бэкап-прокси по умолчанию также выбирается автоматически. Поэтому, в настройках бэкап-прокси перед каждым прогоном вручную выставляем нужный транспортный режим.
Наиболее интересный показатель – средняя скорость или производительность бэкапа. Его можно увидеть в результатах выполнения задания в консоли VBR. Там же будет показано время выполнения бэкапа.
Кроме того, необходимо оценить нагрузку на бэкап-прокси в каждом из тестов. Показатели загруженности процессора, памяти и сети можно отслеживать с помощью инструментов гостевой ОС (Windows 2016) и на уровне VMware.
На бэкап-прокси и бэкап-репозитории параметр максимального количества одновременных задач выставлен в значение 6. Это значит, что в рамках тестирования все ВМ в каждом задании будут обрабатываться параллельно, ни одна из них не будет ждать в очереди, производительность будет максимальной.
Veeam® рекомендует, чтобы количество параллельных задач не превышало количество процессорных ядер на прокси и репозитории. Рекомендуемый объем ОЗУ на репозитории – по 2ГБ на ядро, итого 12ГБ. Конфигурация инфраструктуры показывает, что все рекомендации соблюдены.
Показатель | Значение |
Нагрузка на CPU, % | 55-95 |
Потребление RAM, GB | 2-2,2 |
Нагрузка на сеть, Гбит/с | 4,7-6,4 |
Показатель | Значение |
Производительность бэкапа, МБ/с | 709 |
Время бэкапа, мм: сс | 06:35 |
Показатель | Значение |
Нагрузка на CPU, % | 70-100 (полка 100% с резкими короткими падениями до 70%) |
Потребление RAM, GB | 2,3-2,5 |
Нагрузка на сеть, Гбит/с | 5-7,7 |
Показатель | Значение |
Производительность бэкапа, МБ/с | 816 |
Время бэкапа, мм: сс | 10:03 |
Показатель | Значение |
Нагрузка на CPU, % | 100 (полка 100% с редкими небольшими падениями) |
Потребление RAM, GB | 3-3,5 |
Нагрузка на сеть, Гбит/с | 5-8,2 |
Показатель | Значение |
Производительность бэкапа, МБ/с | 885 |
Время бэкапа, мм: сс | 17:10 |
Показатель | Значение |
Нагрузка на CPU, % | 100 (полка 100% с редкими небольшими падениями) |
Потребление RAM, GB | 4-4,2 |
Нагрузка на сеть, Гбит/с | 5-8,2 |
Показатель | Значение |
Производительность бэкапа, МБ/с | 888 |
Время бэкапа, мм: сс | 24:42 |
Показатель | Значение |
Нагрузка на CPU, % | 18-24 |
Потребление RAM, GB | 1,9-2,1 |
Нагрузка на сеть, Гбит/с | 1,2-1,8 |
Показатель | Значение |
Производительность бэкапа, МБ/с | 192 |
Время бэкапа, мм: сс | 18:30 |
Показатель | Значение |
Нагрузка на CPU, % | 25-33 |
Потребление RAM, GB | 2,2-2,4 |
Нагрузка на сеть, Гбит/с | 1,5-2,5 |
Показатель | Значение |
Производительность бэкапа, МБ/с | 269 |
Время бэкапа, мм: сс | 25:50 |
Показатель | Значение |
Нагрузка на CPU, % | 45-55 |
Потребление RAM, GB | 2,8-3,5 |
Нагрузка на сеть, Гбит/с | 2,8-4,5 |
Показатель | Значение |
Производительность бэкапа, МБ/с | 446 |
Время бэкапа, мм: сс | 31:14 |
Показатель | Значение |
Нагрузка на CPU, % | 50-70 |
Потребление RAM, GB | 3,5-4 |
Нагрузка на сеть, Гбит/с | 3,5-5 |
Показатель | Значение |
Производительность бэкапа, МБ/с | 517 |
Время бэкапа, мм: сс | 40:02 |
Кол-во ВМ | Скорость – 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® показало себя весьма достойно:
Мы получили реальные показатели производительности и нагрузки, что очень полезно для выбора оптимального режима эксплуатации и последующего масштабирования системы.
На данный момент нас вполне устраивает имеющаяся производительность бэкапа, мы понимаем как правильно её увеличить при появлении такой необходимости.
Автор: yahonts
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/backup/301220
Ссылки в тексте:
[1] Облака на базе VMware: https://selectel.ru/services/cloud/vmware/
[2] услугу: https://selectel.ru/services/additional/veeam-backups/
[3] использует vSAN: https://blog.selectel.ru/vsan-v-oblake-na-baze-vmware/
[4] Источник: https://habr.com/post/431596/?utm_campaign=431596
Нажмите здесь для печати.