Данный пост написан по мотивам отличной сессии с прошедшего VeeamON 2021 под названием “Architect’s Desk: Sizing of Veeam Backup & Replication, Proxies and Repositories”, которая, кстати, доступна в записи, как и все остальные сессии с VeeamON.
Под катом мы посмотрим на то, какое количество ресурсов следует выделять основным компонентам Veeam и от каких вводных данных стоит отталкиваться в своих расчетах.
Сервер VBR
Начинается все с выделения ресурсов мозгу, т.е. Backup Server. При планировании ресурсов стоит отталкиваться от количества одновременно выполняемых задач резервного копирования.
Для вычислительных ресурсов сервера VBR правило следующее:
- 1 процессорное ядро на каждые 10 одновременно работающих задач;
- 512 MB оперативной памяти на каждую выполняющуюся задачу.
- 3 GB дискового пространства для логов на каждые 100 VM, резервное копирование которых производится каждый день;
- В случае использования индексации – 100 MB на 1 миллион файлов в случае с Windows и 50 MB на 1 миллион файлов в случае с Linux.
Пример:
- 2000 виртуальных машин;
- 28 задач по 70 виртуальных машин в каждой и все выполняются одновременно.
В таком случае нам потребуется:Процессорные ядра = 28 / 10 = 2.8 или же 3;Оперативная память = 28 * 512 MB = 14336 MB.
Итого, только под нужды VBR без учета ресурсов необходимых для работы ОС, следует выделить 4 процессорных ядра, 15 GB ОЗУ и порядка 60 GB дисковых ресурсов.
Основные принципы, которыми следует руководствоваться:
- Думать про сайзинг сервера VBR уже после того, как где-то будет сформирован предполагаемый список задач резервного копирования;
- Отталкиваться от количества одновременных задач;
- Снизить нагрузку на сервер VBR можно не запуская все задачи одновременно, а разнести их по времени, тем самым снизив количество параллельных задач (если это, конечно, допустимо);
- Не нужно использовать сервер VBR под какие-либо другие задачи. Исключением может стать разве что локальный MS SQL сервер, который идет в комплекте.
База данных MS SQL
Как и в случае с сервером VBR, здесь мы отталкиваемся от количества параллельно выполняемых задач.
Правила расчета ресурсов следующие:
- 2 процессорных ядра на каждые 25 параллельно выполняющихся задач;
- 4 GB оперативной памяти на каждые 25 параллельно выполняющихся задач;
- Дисковых ресурсов база данных потребляет немного, но в некоторых случаях может вырасти до 25 GB. Express версия, которая идет в комплекте, ограничена максимальным размером базы в 10 GB и ее стоит использовать только если количество бэкапируемых VM не превышает 500.
Пример:
- 28 одновременно работающих задач.
Процессорные ядра = 28 / 25 * 2 = 2.24 с округлением – 3;Оперативная память = 5 / 25 * 28 = 4.5 с округлением – 5 GB.
Исходя из тех же 28 параллельных задач, под сервер MS SQL, без учета нужд операционной системы, стоит выделить 3 процессорных ядра и 5 GB оперативной памяти.
Прокси сервер
Здесь начинается самое интересное. Основная цель – определить верное количество ресурсов, чтобы задачи резервного копирования успевали выполняться за отведенное для них время (Backup Window).
В расчете участвуют три переменные – тип резервного копирования (полный, либо инкрементальный), объем бэкапируемых данных и отведенное для резервного копирования время.
Начать стоит с ввода понятия, такого как task или процесс – обработка одного диска, например, VMDK. Один такой процесс работает на скоростях около 100 MB/s при полном резервном копировании и на 25 MB/s при инкрементальном (от инфраструктуры к инфраструктуре цифры могут отличаться).
На один процесс выделяется одно процессорное ядро и 2 GB оперативной памяти. В случае с Nutanix прокси – 1 GB.
Теперь начинается математика в 3 этапа:
- У нас есть объем данных и время, отведенное на процедуры резервного копирования. Соответственно, нам нужно определить скорость, с которой с которой должно выполняться резервное копирование, чтобы уложиться в отведенное время;
Делается это просто – Объем данных в мегабайтах делится на время, выделенное под резервное копирование, в секундах. Как результат, мы получаем требуемую скорость в MB/s.
- Зная требуемую скорость и среднюю скорость одного процесса, мы можем определить количество необходимых процессов;
Требуемая пропускная способность из предыдущего шага делится на среднюю скорость одного процесса (эта скорость различается для полного и инкрементального процесса). Результатом будет необходимое количество процессов.
- Исходя из того, что один процесс требует 1 процессорное ядро и 2 GB оперативной памяти, мы без труда определяем требуемые под прокси ресурсы.
Процессорные ядра = количество требуемых процессов из шага 2;
Оперативная память = количество требуемых процессорных ядер, умноженное на 2.
Пример:
- Объем данных – 260 TB;
- Окно резервного копирования – 8 часов;
- Требуется выполнить полное резервное копирование.
Переводим 260 TB в MB = 260 * 1024 * 1024 = 272629760 MB;
8 часов переводим в секунды = 8 * 60 * 60 = 28800 секунд.
Требуемая скорость = 272629760 MB / 28800 секунд = 9466 MB/s
Зная требуемую скорость и скорость одного процесса для полного резервного копирования (100 MB/s) определим количество требуемых процессов.
Количество процессов = 9466 / 100 = 94,66 или же 95 с округлением в большую сторону.
Определим требуемые вычислительные ресурсы:Процессорные ядра = 95;Оперативная память = 95 * 2 = 190 GB.
Теперь посмотрим, сколько ресурсов потребуется под инкрементальное резервное копирование.
В случае с инкрементальным резервным копированием, мы оперируем не полным объемом, а какой-то его частью (% изменения данных в день, в случае ежедневного резервного копирования, например, 10% от 260 TB или же 26 TB) и скоростью инкрементального резервного копирования в 25 MB/s. Калькуляция остается та же.
Переводим 26 TB в MB = 26 * 1024 * 1024 = 27262976 MB;
8 часов переводим в секунды = 8 * 60 * 60 = 28800 секунд.
Требуемая пропускная способность = 27262976 / 28800 = 947 MB/s
Количество процессов = 947 / 25 = 37.8 с округлением – 38;
Процессорные ядра = 38;Оперативная память = 38 * 2 = 76 GB.
Как можно заметить, требуемое количество ресурсов под инкрементальное резервное копирование почти в три раза меньше, чем под полное. И здесь стоит задать вопрос – а нужно ли делать такой объемный полный бэкап за одно окно резервного копирования? Если его разнести на два дня, требуемых ресурсов нужно будет в два раза меньше.
Всегда есть о чем подумать и как оптимизировать процессы и необходимые ресурсы.
Важный момент: Все цифры выше – цифры, от которых можно отталкиваться, однако итоговые результаты будут отличаться от инфраструктуры к инфраструктуре. Где-то в лучшую сторону, где-то в худшую. Какими бы мощными не были прокси, толку от них будет мало, если они подключены гигабитными интерфейсами и так далее.
Основные моменты, на которые следует обратить внимание:
- Компрессия так же потребляет ресурсы. Чем сильнее – тем больше требуется;
- Правильный сайзинг прокси не может гарантировать надлежащую скорость резервного копирования, если остальная инфраструктура не справляется;
- Большие диски не могут обрабатываться несколькими прокси и это важно учитывать.
Отдельно хотелось бы упомянуть прокси для NAS
При сайзинге прокси для NAS мы оперируем следующими значениями – одно процессорное ядро требуется для обработки 5млн файлов в час, либо 0.34 TB данных в час (что из этого раньше наступит). Например, 40 файлов по 10 GB, либо 6 млн. файлов, общим объемом 200 GB.
На одно процессорное ядро выделяется 2 GB оперативной памяти.
С калькуляцией проблем, думаю, не возникнет. Все вычисляется аналогичным образом на основании объемов данных и окна резервного копирования.
Репозитории
Здесь мы так же отталкиваемся от количества одновременных процессов. Один такой процесс требует около 1 процессорного ядра и 4 GB оперативной памяти.
Однако, мне нравится вариант, предложенный на портале https://veeambp.com – рассчитывать количество требуемых ресурсов на основании уже имеющегося сайзинга прокси, используя коэффициент 1.5 для процессорных ядер.
Процессорные ядра = Количество ядер прокси / 1.5;
Оперативная память = количество процессорных ядер * 4 GB.
Для объяснения процесса калькуляции требуемого пространства под резервные копии следует писать отдельную статью, поэтому предложу самый простой вариант – воспользоваться уже готовым калькулятором https://rps.dewin.me/
Пример:
- Под прокси было выделено 38 ядер и указано 38 параллельных процессов.
Из расчетов ресурсов под прокси мы установили необходимость в 38 процессорных ядрах. Теперь вычислить конфигурацию репозитория не составит особого труда.Процессорные ядра = 38 / 1.5 = 25.3 или же 26 ядер;
Оперативная память = 26 * 4 = 104 GB.
Не стоит забывать, что в случае с ReFS потребуется дополнительный объем оперативной памяти.
В качестве заключения:
Мы выяснили, что для правильного расчета необходимых ресурсов нам важно знать следующие параметры:
- Общее количество виртуальных машин;
- Планируемое количество задач резервного копирования;
- Количество одновременно запускаемых задач;
- Объем данных;
- Продолжительность окна резервного копирования.
Для сервера VBR и базы данных мы выполняем расчет на основании количества параллельных задач. Ресурсы под прокси сервера определяются на основании объемов данных и размера окна резервного копирования. Вычислительные ресурсы под репозиторий напрямую зависят от выделенных ресурсов для прокси.
На основании этих данных мы можем рассчитать требуемые ресурсы под основные компоненты Veeam. Не стоит забывать про то, что все можно оптимизировать, разнести по времени, и тем самым уменьшить итоговое количество ресурсов.
Я в свою очередь настоятельно рекомендую просмотреть сессию «Architect’s Desk: Sizing of Veeam Backup & Replication, Proxies and Repositories» в разделе записей VeeamON 2021, а также изучить ресурс https://veeambp.com – там есть ответы практически на все интересующие вопросы. Еще один полезный ресурс – блог Veeam на Хабре – в блоге много полезной информации, включая отличные статьи по сайзингу и траблшутингу.
