Команда наших системных архитекторов выпустила уже второе руководство с лучшими практиками по развертыванию решений Veeam - на сей раз для ставшего весьма популярным Veeam Backup for Microsoft Office 365. (Еще бы ему не набрать популярности в эпоху удаленной работы, если он умеет бэкапить и восстанавливать почту, OneDrive, а теперь и Teams.) Полезные советы наших экспертов, а также рекомендации от коллег из Veeam QA сегодня предлагаются вашему вниманию.
О чем пойдет речь
Музыка, как говорил Дмитрий Борисович Кабалевский, основывается на “трех китах” - это песня, марш и танец. А Veeam Backup for Microsoft Office 365 (VBO) включает в себя четыре основных компонента:
Veeam Backup for Microsoft Office 365 Server
Veeam Backup for Microsoft Office 365 Proxy Server
Veeam Backup for Microsoft Office 365 Repository
Veeam Explorers
Такая архитектура поддерживает масштабирование: в небольшой инфраструктуре можно установить все компоненты на один сервер, а в более крупной - задействовать несколько серверов, развернуть несколько прокси-серверов для параллельной обработки задач, а также несколько репозиториев для хранения резервных копий.
Примечание: У VBO прокси и репозитории соотносятся как “один-ко-многим”, то есть один прокси может работать с несколькими репозиториями, но один репозиторий можно подключить лишь к одному прокси.
В этой статье мы обсудим то, что касается планирования деплоймента VBO server, прокси и репозитория.
Физический сервер или виртуальная машина?
Для инфраструктуры Veeam Backup for Microsoft Office 365 возможны оба сценария. Если это виртуальная машина, то можно развернуть ее как непосредственно в вашей виртуальной инфраструктуре, так и в частном облаке или на платформе провайдера, будь то Microsoft Azure или Amazon AWS. Вариант с облаком подходит, например, для быстрого старта и эвалюации продукта.
При планировании держим в уме и требования бизнеса: для одних важно сохранять бэкапы у себя в инфраструктуре, других привлекает готовый шаблон в Azure Marketplace. Но в любом случае при выборе варианта развертывания VBO нужно учитывать, где будет находиться репозиторий и как будет организован трафик.
Если вы планируете развернуть VBO в облаке Microsoft Azure, то для оптимальной производительности рекомендуется выбрать тип машины F или D-Type (тип B имеет ограничения на ресурс процессора).
План послеаварийного восстановления VBO
Для быстрого послеаварийного восстановления сервера VBO и его инфраструктуры вам нужно проработать соответствующий план для всех компонентов, включая VBO Server, прокси и репозитории.
За бэкап компонентов VBО с учетом состояния приложений (application-consistent backup) отвечает Veeam VSS writer - у каждого сервера VBO Server и прокси-сервера есть такой. Перечень этих VSS writers можно получить по команде vssadmin list writers . Называться они будут соответствующим образом - Veeam Backup for Microsoft Office 365 Writer (и его ID).
Если же у вас развернут еще и Veeam Backup & Replication (VBR), то это просто отлично, ибо:
При необходимости можно будет быстро и просто восстановить нужные компоненты VBO, включая конфигурационную базу ConfigDB, базу данных ProxyDB и соответствующие файлы.
Благодаря интегрированному VSS и возможности создавать бэкапы с учетом работы приложений можно выполнять гранулярное восстановление объектов из локальных репозиториев с помощью всевозможных Veeam Explorers (для Veeam Backup and Replication 9.5 Update 4 и выше).
Можно сохранять бэкапы в разные местоположения и на разные tiers, поддерживая правило “3-2-1” - к примеру, на магнитную ленту, в масштабируемый репозиторий Scale-Out-Backup-Repository или в облако с помощью Cloud Connect Provider.
Вот еще несколько важных моментов для планирования бэкапа инфраструктуры VBO:
Если у вас несколько прокси и репозиториев, предусмотрите резервное копирование для каждого из них.
Если репозиторий устроен на SMB-шарах, то их нужно бэкапить отдельно.
Важно обеспечить защиту базы конфигурации ConfigDB (на VBO Server) и базы прокси ProxyDB (на VBO Proxy), поскольку в них содержатся настройки инфраструктуры. В случае необходимости именно из их бэкапов можно будет восстановить конфигурацию, не создавая при этом помех работе заданий Veeam Backup for Microsoft Office 365.
Про объектные хранилища
Как известно, начиная с Veeam Backup for Microsoft Office 365 v4 поддерживаются и объектные хранилища, как в частных, так и в публичных облаках. При работе с объектным хранилищем VBO использует локальный кэш - в нем хранятся метаданные, которые синхронизируются с объектным хранилищем для повышения надежности. (Подробно об этом шла речь в этой статье.) Если с локальным кэшем что-то случится, данные можно будет восстановить из облака. У самого же объектного хранилища доступность обеспечивается распределенным хранением объектов по разным географическим локациям/нодам кластеров/хабам.
Примечание про Veeam Backup & Replication: Поскольку по натуре своей Veeam Backup & Replication выполняет image-level backup, бэкапить данные из репозитория VBO на базе объектного хранилища с его помощью не получится.
Онлайн-калькулятор
У нас есть общедоступный удобный калькулятор, который поможет рассчитать размер репозитория и других необходимых ресурсов согласно вашим данным (можно подгрузить их автоматически, указав ваш аккаунт Office 365, либо вводить вручную). Расчет выполняется для объектов, которые надлежит бэкапить.
Например, для Exchange Online и On-Premises это будут:
Primary Mailbox
Archive Mailbox
Shared Mailboxes
Public Mailboxes
Exchange Resources (Room, Equipment)
Подробнее об объектах, которые умеет бэкапить VBO, можно почитать здесь.
Пример
Допустим, что в компании из 500 человек нужно бэкапить все пользовательские мейлбоксы (Primary и Archive), а также 200 Shared Mailboxes, 10 Public Mailboxes, и вдобавок все Personal Sites и OneDrives, а также 1000 SharePoint sites и 100 Teams (каждый такой объект считается за 2 из-за сложности). Итого получится 3 410 объектов.
Для бэкапа всего этого богатства будет достаточно развернуть один репозиторий с рекомендованными параметрами, которые будут описаны в следующем разделе.
Примечание: Достаточно-то - это да, но не оптимально, лучше всего бэкапить данные Exchange и SharePoint в разные репозитории, как будет разъяснено ниже.
Microsoft Teams
Сам по себе сервис Microsoft Teams хранит небольшой объем данных. Гораздо больший объем распределен между другими сервисами Microsoft Office 365. Так что для планирования места под данные Teams можно ориентироваться на соответствующие расчеты для этих сервисов.
Чтобы сэкономить место и время, рекомендуется бэкапить конкретную команду (Team) в тот же репозиторий, куда и Team’s SharePoint site и групповые мейлбоксы для данной Team. Резон вот такой: файлы Teams хранятся в соответствующих сайтах SharePoint, в папках, чьи имена аналогичны каналам (например, General). Задание бэкапа Teams сделает резервные копии этих папок наряду со ссылками на Team. В ходе же работы задания бэкапа Teams SharePoint будет выполнено резервное копирование всех данных с целевого SharePoint (включая и эти папки, относящиеся к Teams). А поскольку их object IDs будут одни и те же, то при бэкапе в один и тот же репозиторий бэкапные задания для Teams и Teams SharePoint “дедуплицируют” такие объекты.
VBO Server
Требования к серверу подробно описаны здесь. Ограничения и важные замечания - здесь.
Настоятельно рекомендуется иметь одну и ту же версию ОС на всех компонентах инфраструктуры VBO, включая сервер, прокси и репозитории - поскольку VBO задействует Microsoft Jet Blue database, встроенную в ОС. Соответственно, каждая новая версия ОС выходит с новой версией Jet Blue database - и при “зоопарке” версий на разных компонентах возможны проблемы с совместимостью.
Репозиторий
Репозиторий Veeam Backup for Microsoft Office 365 содержит папки, называемые по сроку хранения. Для каждой папки имеется файл базы репозитория (.adb) и файлы журналов транзакций и проверок (.jrs и .chk). Поддерживаемый размер базы - до 64 TB. Подробности про срок хранения (ретеншен) с примерами можно найти в нашей статье на Хабре.
Примечание: В отличие от Veeam Backup & Replication, тут нет различия по функциональности в зависимости от типа хранилища.
Репозиторий на диске
Репозиторий может располагаться на Direct Attached Storage (DAS), Storage Area Network (SAN) или SMB3 Network Attached Storage (NAS).
Рекомендуется задействовать СХД с высокой пропускной способностью и небольшой latency. Соответственно, это будут DAS либо SAN. Можно не менять дефолтные настройки контроллера и размера страйпа. В качестве файловой системы рекомендовано использовать NTFS с дефолтными настройками (с аллокейшеном по 4k).
Не следует включать шифрование, дедупликацию или компрессию на репозитории, чтобы не снижать производительность.
Рекомендуется организовывать отдельные репозитории для разных типов данных (Exchange, SharePoint) - для большей гибкости.
Вместо того, чтобы складировать очень большие объемы данных в одном репозитории, лучше завести несколько репозиториев поменьше - например, для разных отделов или филиалов.
Держите свободными не менее 10% места на диске, чтобы не допустить переполнения.
Объектное хранилище
Начиная с VBO v4, поддерживаются и объектные хранилища. Как вы помните, для таких репозиториев локально хранится только кэш небольшого размера (обычно ~1% от всего объема репозитория), а все остальные данные хранятся в контейнерах объектного хранилища.
Тут действуют общеизвестные рекомендации, которые, тем не менее, будет нелишним перечислить:
Создайте выделенную учетную запись для работы с облачным хранилищем.
Настройте ограничения для ACL.
Не следует устанавливать политики для разноуровневого хранения (tiering policies) на стороне объектного хранилища - они не поддерживаются, а попытки их все же настроить могут вызвать проблемы.
Не следует удалять что-либо из контейнера вручную (если, конечно, вы не планируете прекратить работу с репозиторием - тогда можно удалить все).
Да, и, конечно же, отведите примерно ~1% от объема исходных данных под локальный кэш.
Прокси
Для прокси-сервера обычно рекомендуется использовать 8-ядерный процессор и 32 GB памяти. Масштабируемость планируем, исходя из количества объектов, которые надо бэкапить - это могут быть объекты типа Mail, Archive, Site, OneDrive или Teams. Соответствующие метрики приведены в разделе "Планирование ресурсов".
Кроме того, нужно учитывать еще количество потоков и пропускную способность, о которых расскажем подробнее.
Количество потоков (number of threads) - это число активных подключений, которые инициировал VBO Proxy, занимающийся бэкапом. Оно может быть в пределах от 0 до 256. По умолчанию это значение равно 64. Однако не следует задавать его слишком большим, иначе могут возникнуть проблемы с Throttling Policy (политика тротлинга), с помощью которой Microsoft Office 365 контролирует ресурсы, необходимые для внешних клиентов\подключений. Мы рекомендуем сначала настроить и помониторить тестовые задания, чтобы выбрать оптимальное значение.
Примечание: Высокая нагрузка на процессор и память является индикатором чересчур большого значения количества потоков.
Пропускная способность (amount of bandwidth) - это пропускная способность сети, распределенная по указанному числу потоков. По умолчанию она задается как неограниченная (unlimited). В этом случае будет задействована вся пропускная способность, имеющаяся в распоряжении VBO Proxy. Но лучше все-таки назначить разумное ограничение. Заметим, что вовсе необязательно VBO Proxy будет использовать максимально возможную пропускную способность, поскольку опять же политики тротлинга для Office 365 ограничивают скорость для подключений.
Задания резервного копирования - backup jobs
Казалось бы, проще всего создать одно задание для бэкапа всего-на-свете. Однако тут вас подстерегают потенциальные риски, связанные с продолжительностью бэкапа, сложностью в настройке, нетривиальностью восстановления. Вот какие рекомендации для настройки заданий резервного копирования приводят системные архитекторы:
Создавайте отдельные задания для каждого из приложений - то есть отдельно для бэкапа данных Exchange, отдельно для SharePoint, для Teams и отдельно для OneDrive - ибо размер данных для них прирастает по-разному. Кроме того, можно будет сохранять данные каждого из таких заданий в отдельный репозиторий с соответствующим сроком хранения данных (то бишь ретеншеном).
На одно задание не должно приходиться больше 4,000 объектов (про то, что считается объектом, см. здесь).
Для больших инфраструктур в настройках задания лучше увеличить интервал повторения попыток после неудачного запуска (Retry failed object processing - Wait before each retry attempt for) до 20 минут и более. Про эти настройки подробнее здесь.
Лучше запускать задания во внерабочее время (например, ночью), дабы избежать нагрузки на внутреннюю сеть, когда работают другие клиенты (OneDrive, ActiveSync и т.п.).
Для Microsoft Exchange (в зависимости от объема данных мейлбоксов, а также если у вас 500+ мейлбоксов) лучше создать несколько заданий, ориентируясь на почтовые группы - например, организованные по департаментам. У таких заданий производительность будет достаточно хорошей, и выполнять восстановление с ними будет несложно. При необходимости исключить какой-либо мейлбокс из обработки это можно быстро сделать в интерфейсе VBO.
Veeam Backup for Microsoft Office 365 может бэкапить целиком on-premise SharePoint farm, однако мы рекомендуем в одно задание помещать не больше 50 сайтов SharePoint (ориентироваться, конечно, следует и на объемы содержимого сайтов).
Планирование ресурсов и масштабирование
Значения, приведенные ниже, могут служить ориентиром в сценариях с различными сочетаниями Online и On-Premises инфраструктур, где работают Microsoft Exchange, Microsoft SharePoint, OneDrive for Business и Microsoft Teams. В качестве объектов принимаются:
Mailboxes (Primary, Archive, Shared, Public)
Sites (SharePoint, включая Subsites, Personal, Teams)
OneDrive for Business
Teams
Данные значения были получены в ходе тестирования командой Veeam QA и согласуются с остальными рекомендациями.
Минимальная конфигурация - 4-ядерный процессор, 8 GB RAM.
Рекомендованная конфигурация - 8-ядерный процессор, 32 GB RAM.
Что же касается потребления RAM для Repository database в расчете на 1 прокси, то тут цифры будут такие:
0.1% памяти хоста по умолчанию потребляет однин экземпляр JET database (база репозитория Veeam Backup for Microsoft Office 365)
50% памяти хоста по умолчанию занимает кэш для JET database engine
Рекомендованное количество баз JET databases на один прокси (с дефолтными настройками) - 250
Максимальное количество баз JET databases на один прокси (с кастомными настройками) - 700 - 750
Примечание: Для дефолтного прокси (который ставится вместе с Veeam Backup for Microsoft Office 365 Server) надо иметь в виду, что минимум 15% RAM будет требоваться для работы этого VBO Server.
Если вам нужно по-особому настроить распределение памяти для прокси, обратитесь в службу поддержки Veeam.
Полезные ссылки
Best Practices for Veeam Backup for Microsoft Office 365 (на англ. языке)
Руководство пользователя для Veeam Backup for Microsoft Office 365 (на англ. языке)
Калькулятор ресурсов для VBO
Статья на Хабре о политиках хранения в VBO
