С версии 6 Veeam Backup & Replication приобрел распределенную инфраструктуру: прокси и репозитории. Собственно про роли я уже писал. Основная цель разделения/распределения — это масштабирования инсталляции.
Как говорится, it depends — и зависит это от вашей инфраструктуры.
Когда-то использовали условное число 5ТБ передаваемых данных на один сервер VBR, то есть на один прокси 5ТБ ежедневно инкрементально копируемых данных, чтобы уложиться в стандартное ночное окно резервного копирования. Но, повторюсь, это условное число. Скорости бывают разные.
Вот по сумме всех значений объемов реально скопированных данных по всем заданиям за период и можно вычислить реальное значение изменяемых данных.
Еще одно рекомендуемое значение: 1 задание на 2 процессорных потока (vCPU, ядра) прокси-сервера. Количество одновременно обрабатываемых заданий указывается в настройках каждого прокси. Если указать это значение больше рекомендованного, то вероятнее всего сервер резервного копирования станет узским местом в процессе копирования.
И напомню: множество заданий — это обязательно необходимое условие. Если вы бэкапите всю инфраструктуру одним заданием, и тысяча прокси-серверов не поможет.
В настройках репозитария есть опция ограничения количества одновременно выполняемых задач. Под задачами понимается не только сам процесс записи резервных копий, но и процессы преобразования резервных копий. Например, создание синтетической полной копии.
В общем, следим за IOPSами.
Вторая часть масштабирования репозитариев – оценка необходимого дискового пространства для хранения резервных копий. Считаем по формуле:
,где:
Прокси
Увеличиваем количество прокси для того, чтобы распараллелить выполнение заданий между ними. Необходимо осуществлять, когда не хватает выделенного окна резервного копирования и при этом имеем множество заданий. Зависит соответственно от количества изменяемых данных с момента предыдущего резервного копирования.Как сайзить? Сколько мне запланировать прокси? Какие прокси брать физические или виртуальные?
Как говорится, it depends — и зависит это от вашей инфраструктуры.
Когда-то использовали условное число 5ТБ передаваемых данных на один сервер VBR, то есть на один прокси 5ТБ ежедневно инкрементально копируемых данных, чтобы уложиться в стандартное ночное окно резервного копирования. Но, повторюсь, это условное число. Скорости бывают разные.
Физический vs. вируальный прокси.
1. СкоростьФизический сервер обычно быстрее копирует большие данные, чем виртуальный прокси (технология hotadd от VMware), а копирование по сети LAN — самый медленный. Но не все так просто.
При небольших изменениях (инкрементальное копирование) FC не успевает "разогнаться" в процессе копирования до полной скорости, и практически дает те же значения, что и hotadd.
К этому добавим, что и сеть LAN оказывается может быть не такой уж и медленной. Например, я долгое время считал, что LAN разгоняется обычно до 5МБ/с, а 10МБ/с это просто круто. Но вот я на гигабитной сети увидел 45-50МБ/с — а это уже стандартные скорости hotadd. // А сегодня я иду смотреть, как оно побежит на 10Гб ;)
2. Простота
В этом неоспоримо преимущество виртуальных машин. Развернуть можно достаточно быстро несколько ВМ, чего не скажешь про быстроту закупки физических серверов.3. Нагрузка
Но. Если вы хотите сделать все-в-одном. Проще всего поставить 1 физический сервер, сделать его Direct SAN Access прокси и репозитарием для локального хранения копий вне основной СХД. А когда понадобится — создать дополнительные виртуальные прокси.
Если нагрузка на ESX критична для вас, тут преимущество на стороне физического сервера. Виртуальный прокси потребляет процессорные мощности хоста и ввод-вывод FC HBA и NIC. С другой стороны, если один сервер VBR вызывает серьезные проблемы с производительностью хостов ESX, то вам следует в первую очередь озаботиться масштабированием самой виртуальной инфраструктуры.
Цифры
Значение изменяемых данных проще всего определить эмпирически. Ставим VBR, запускаем задания и смотрим на циферки статистики:
Еще одно рекомендуемое значение: 1 задание на 2 процессорных потока (vCPU, ядра) прокси-сервера. Количество одновременно обрабатываемых заданий указывается в настройках каждого прокси. Если указать это значение больше рекомендованного, то вероятнее всего сервер резервного копирования станет узским местом в процессе копирования.
И напомню: множество заданий — это обязательно необходимое условие. Если вы бэкапите всю инфраструктуру одним заданием, и тысяча прокси-серверов не поможет.
Репозитарии
На репозитарии требуется меньше нагрузки по производительности процессоров. Но при большом количестве одновременно исполняемых заданий, происходит конкуренция за потоки записи дисковой системы. В определенных случаях это может стать узким местом инсталляции.В настройках репозитария есть опция ограничения количества одновременно выполняемых задач. Под задачами понимается не только сам процесс записи резервных копий, но и процессы преобразования резервных копий. Например, создание синтетической полной копии.
В общем, следим за IOPSами.
Вторая часть масштабирования репозитариев – оценка необходимого дискового пространства для хранения резервных копий. Считаем по формуле:
,Vbackups — рассчитываемое дисковое пространство для резервных копий;Ну, а получив нужные цифры уже можно решать, как увеличивать существующее пространство или добавлять новые хранилища.
Vdata — количество реальных данных ВМ;
Vdaily — количество ежедневно изменяемых данных;
Nfulls — количество полных резервных копий для каждой ВМ;
Nincrements — количество инкрементальных копий для каждой ВМ;
Rdedup — среднее значение сжатия данных.
Про другие компоненты VBR
Не про масштабирование, но про размещение других компонентов инсталляции Veeam Backup.
- Сервер MS SQL для баз данных Veeam Backup и Veeam Backup Enterprise Manager. Учитывая, что VBR хранит в БД только настройки своей инфраструктуры и заданий, а также статистику, то сервер в масштабируемости не нуждается.
- Veeam Backup Enterprise Manager имеет смысл ставить на тот же сервер, что и первый VBR-сервер, так как ресурсов не особо не потребляет и в масштабируемости также не нуждается.
- Search-сервер нужно разворачивать на сервере/ах, где установлен Microsoft Search Server.
- Мастера восстановления (AIR) необходимо ставить на компьютеры с которых будет осуществляться процесс восстановления объектов. Т.е. сервер VBR, рабочие места администраторов приложений.
Так, например, администратор SQL может не иметь доступ и права на виртуальную инфраструктуру и резервные копии. Но запросив с помощью мастера восстановления объектов SQL создание лаборатории, после одобрения запроса со стороны администратора резервного копирования получит доступ к машинам, запущенным из резервных копий в лаборатории.
Комментариев нет:
Отправить комментарий