Veeam сайзинг
Veeam — это крайне универсальное решение. Его можно развернуть как в конфигурации из одной виртуальной машины и при этом получить полнофункциональную систему. Но когда мы переходим к довольно большим и сложным инфраструктурам, содержащим большое количество прокси серверов, серверов репозиториев и т.д. для нас становится важным вопрос о правильном масштабировании системы с учётом наших потребностей. Сегодня мы и будем смотреть как правильно сайзить основные компоненты системы для Veeam.
Прежде чем приступить к расчётам, нам необходимо придумать некую компанию, данные которой мы должны бекапить и под которые мы масштабируем СРК.
Пример:
100TB продуктивных данных VM
4Тб продуктивных данных на физических серверах
Окно резервного копирования — 8 часов
Сhange rate — 10% для виртуальных серверов и 15% для физических
VM — 3000 штук
Физических серверов — 10 штук
Файловая шара на базе физической СХД — 100 TB, change rate — 3%, 200 миллионов файлов
Продуктивная СХД — NetApp AFF с полным набором лицензий
Все системы располагаются в рамках одной площадки
Храним резервные копии мы локально на выделенном сервере РК на протяжении 1 месяца
Начнём мы нашу работу с составления таблиц с нашими ресурсами, на основе которых (и дополнительной информации к ним) мы и будем строить наш сайзинг. Вообще, обследование инфраструктуры перед сайзингом — одна из наиболее важных задач. Независимо от того, новая это инфраструктура или уже давно рабочая, все эти данные потребуются нам для наиболее точного сайзинга всех компонентов.
Физические серверы
| Операционная система | Приложение | Количество | Объём |
|---|---|---|---|
| Microsoft Windows Server 2016 | Active Directory | 2 | 200 GB |
| Red Hat Enterprise Linux 8.2 | Oracle database server standard edition 18c | 3 | 1200 Gb |
Виртуальные серверы
| Операционная система | Приложение | Количество | Объём |
|---|---|---|---|
| Red Hat Enterprise Linux 8.2 | MySQL Server 8.0 | 6 | 800 GB |
| Microsoft Windows Server 2019 | Microsoft SQL Server 2016 | 6 | 4000 Gb |
| Смешанная инфраструктура | Смешанная инфраструктура | 2988 | 250 Gb |
Теперь составим табличку, какие сервисы и как мы будем защищать (такие данные нам потребуется уточнить у нашего заказчика и использовать их для составления полной таблицы данных, на которые мы будем опираться как при сайзинге, так и при дальнейшей настройки СРК).
| Группа ресурсов | RPO | RTO | Retention | Объём | Объём изменений |
|---|---|---|---|---|---|
| PA-Active Directory | 24H | Не определено | 31D, 12M | 400 Gb | 15% |
| PA-Oracle | 6H | 6H | 31D, 12M, 3Y | 3600 Gb | 15% |
| VA-MySQL | 6H | 6H | 31D, 12M, 3Y | 4800 Gb | 10% |
| V-Microsoft SQL | 3H | 3H | 31D, 12M, 3Y | 24000 Gb | 10% |
| V-mix | 24H | Не определено | 31D, 12M | 72000 Gb | 10% |
Теперь составим аналогичную ресурсную таблицы для бекапа нашего NAS
| NAS | Количество шар | Объём | Количество файлов | Объём изменений | Окно резервного копирования | Retention |
|---|---|---|---|---|---|---|
| Физическая СХД | 15 | 120000 Gb | 1500000 | 10% | 8H | 31D, 12M |
Теперь мы можем перейти непосредственно к сайзингу компонентов и начнём мы при этом сразу с прокси серверов. В описании нашей «компании» мы говорили о том, что у нас есть СХД, совместимая с Veeam и полным набором лицензий, т.е. мы сможем использовать Direct SAN Access со снепшотами СХД для резервного копирования. Это сразу влечёт за собой необходимость использовать физические серверы, т.к. работа Direct SAN Access в виртуальных прокси не является поддерживаемым решением (хотя и работает).
Сайзинг прокси
Пропускная полоса прокси сервера
Формула: Кол-во продуктивных данных в MB = Кол-во продуктивных данных в TB * 1024 (переводим GB в MB)
Формула: Окно резервного копирования в секундах = Окно резервного копирования в часах * 60 (переводим часы в минуты) * 60 (переводим минуты в секунды)
Формула: Пропускная способность MB/s = Кол-во продуктивных данных в MB / Окно резервного копирования в секундах
Объёмы для физических серверов и для виртуальных посчитаем по отдельности, т.к. потом параметр change rate будет для нас важным при дальнейших расчётах.
4096000 / 28800 = 143 MB/s для физических серверов
103219200 / 28800 = 3584 MB/s для виртуальных серверов
Требуемое количество ядер
Формула: Пропускная способность MB/s / 100 * Объём изменений % / скорость работы (Incremental) MB/s
Скорость работы (Incremental) в данном случае рекомендуется «по-умолчанию» принимать как 25MB/s, если не проведены тесты производительности и не получена другая цифра для выполнения инкрементальных резервных копий. Для Active full используется 100MB/s или другая цифра, полученная при помощи тестов производительности.
(143 / 100 * 15) / 25 = 1 ядро
(3584 / 100 * 10) / 25 = 15 ядер
Требуемый объём памяти
Формула: Требуемое количество CPU * 2
16 * 2 = 32 GB
Теперь посчитаем требования для роли File Proxy
Формула: Необходимая пропускная способность инкрементального РК = (Кол-во продуктивных данных в TB / 100 * change rate %) / окно резервного копирования (в часах)
(100 / 100 * 3) / 8 = 0.375
Формула: Файлов в час = Количество файлов (в миллионах) / окно резервного копирования (в часах)
200 / 8 = 25
Эти параметры являются рекомендуемыми для расчётов
Пропускная способность прокси — 0.34 TB/hour (100 MB/s)
Обработанных файлов в час — 5 миллионов/час
Формула: Количество CPU (guide 1) = Необходимая пропускная способность инкрементального РК / Пропускная способность прокси
0.375 / 0.34 = 2 ядер
Формула: Количество CPU (guide 2) = Файлов в час / Обработанных файлов в час
25 / 5 = 5 ядер
Требуемое количество CPU
Выбираем наибольшее значение среди guide 1 и guide 2 — 5 ядер
Формула: Требуемый объём памяти = Количество CPU * 2
5 * 2 = 10 GB
Также для резервного копирования NAS нам необходим Cache Repository
Этот параметр является рекомендуемым для расчётов
File Proxy cores to cache repo cores ratio — 1.5
Формула: Требуемое количество CPU для файлового прокси / 1.5
5 /1.5 = 4 ядер
Формула: Требуемый объём памяти = Количество CPU * 4
4 * 4 = 16 GB
Вернёмся к ещё одному важному моменту — мы используем физические серверы для резервного копирования, но не можем использовать их для восстановления. Вернее можем, но только при условии, что наши виртуальные машины при восстановлении получат thick диски. Если же мы хотим использовать thin, тогда нам придётся использовать либо восстановление по сети (что на мой взгляд является наиболее худшим вариантом), либо использовать виртуальные прокси. Их сайзинг нужно также рассчитать отдельно в зависимости от нашего плана восстановления систем, а точнее — одновременно восстанавливаемых дисков виртуальных машин.
Сервер репозиториев
Требуемое количество ядер
Формула: Требуемое количество CPU = (Кол-во CPU для роли Backup Proxy VM + Кол-во CPU для роли Backup Proxy Agents) / 3
(15 + 1) / 3 = 6 ядер
Требуемый объём памяти
Формула: Требуемый объём памяти = Количество CPU * 4
6 * 4 = 24 Gb
Аналогично нам необходимо рассчитать требования для резервного копирования NAS
Формула: Требуемое количество CPU = Кол-во CPU для роли File Proxy / 2
4 / 2 = 2 CPU
Формула: Требуемый объём памяти = Количество CPU * 6
2 * 6 = 12 GB
А так же для метадаты NAS’а
Формула: Требуемое количество CPU = Кол-во CPU для роли Backup Repository NAS CPU
Формула: Требуемый объём памяти = Количество CPU * 6
2 * 6 = 12GB
Здесь нужно добавить, что есть нюансы при использовании в качестве серверов репозиториев Windows машины и ReFS. Существует рекомендация — чтобы не получить проблем с производительностью нужно иметь на сервере 1 Gb памяти на каждый 1 Tb объёма репозитория.
Сервер управления
Количество инстансов = агенты физических серверов + агенты виртуальных серверов + виртуальные машины
Количество одновременных заданий = Количество инстансов / 70
Рекомендуемый средний размер джобы 70 VM/агентов
3000 + 10 = 3010
3010 / 70 = 43
Для каждых 10 одновременных заданий: 1 CPU и 4 GB памяти
43 / 10 = 5 CPU, 20 GB памяти
База данных
Количество одновременно запущенных заданий:
<=25: 2 CPU + 4 GB памяти
<=50: 4 CPU + 8 GB памяти
<=100: 8 CPU + 16 GB памяти >100: 2 CPU и 4 GB памяти для каждых 25 джобов
Так же следует не забывать, что это сайзинг под компоненты самого Veeam, и нам потребуется отдельно заложить 2 CPU и 8 Gb памяти для работы самой ОС.
Итог
Начнём с точки зрения отказоустойчивости системы. Т.к. мы имеем дело с физическими серверами, у нас всегда есть вероятность их полного отказала или поломки оборудования. Если смотреть с точки отказоустойчивости, то нам необходимо приобрести как минимум 2 сервера, которые будут играть роль прокси. Также роли Backup Proxy и File Backup Proxy мы соединим в единый сервер:
- 2 CPU и 8 GB памяти под ОС
- 16 CPU и 32 GB памяти под роль Backup Proxy
- 5 CPU и 10 GB памяти под роль File Backup Proxy
- 4 CPU и 16 GB памяти под роль NAS Cache Repository
Соответственно, нам нужно 2 сервера с процессорами на 16 ядер и 32Гб памяти на каждом. Не забываем также про карточки для подключения проксей к массиву по SAN, что бы можно было забирать данные со снепшотов.
Теперь серверы-репозитории. Я намеренно не стал давать никаких рекомендаций с точки зрения репозитория. Лично я стараюсь придерживаться максимально отказоустойчивой конфигурации и под репозитории использую внешние СХД с блочным доступом, для вас это решение может быть совсем иным, например, использование физического сервера с большим количеством дисков сразу под роли прокси сервера и сервера репозиториев. В нашем случаем нам понадобится:
- 2 CPU и 8 GB памяти под ОС
- 6 CPU и 24 GB памяти под роль Repository
- 2 CPU и 12 GB памяти под роль Repository NAS
- 0 CPU и 12 GB памяти под метадату NAS’а
А для точного расчёта объёма, необходимого для хранения резервных копий, лучше всего использовать Veeam Backup Calculator.
Для нашего бекапа виртуальных машин мы получим следующие значения:
Backup 525.85 TB
Full backup: 50 TB
Incremental backup: 150 TB
Workspace: 25.85 TB
Для физических серверов:
Backup 31.1 TB
Full backup: 3 TB
Incremental backup: 9 TB
Workspace: 2.1 TB
И для резервного копирования NAS:
Backup 210.85 TB
Full backup: 15 TB
Incremental backup: 45 TB
Workspace: 25.85 TB
Нужно учесть в какое время у нас будет запускаться резервное копирования виртуальных машин и файловой шары. Если это время будет отличаться, то нам будет достаточно 30TB в качестве пространства для работы с данными, если же они будут запускаться одновременно, то нам понадобится уже 55TB свободного пространства.
В качестве дополнительного материала для изучения данной темы рекомендую посетить Veeam Backup & Replication Best Practices.
