Резервное копирование MS Exchange DAG кластера средствами Veeam Backup

Один наш хороший товарищ, A. Vasiliev, поделился опытом хождения по граблям. Привожу его текст чуть ниже.

В нашей организации мы движемся к 100% виртуализации всех сервисов. Один из приятных моментов виртуализации – нам практически не надо думать как выполнять резервное копирование сервиса. Есть универсальное средство – Veeam Backup.

Не так давно у нас появился и стал расти DAG кластер Microsoft Exchange Server 2010. На данный
момент его емкость составляет примерно 3000 ящиков, 27 почтовых баз, 27 VMDK по 110 Гб под базы. MS Exchange DAG кластер состоит из 2-х нод, на каждой из которых лежат все 27 баз.

Конечно же все это надо бэкапить и решение по выбору средства создания резервных копий было очевидно.

А вот результат получился не совсем ожидаемым…

Первое с чем столкнулся при выполнении бэкапа – успешно проходит задание только для полностью пассивной ноды (нет активных БД). Наличие же хотя бы одной активной копии БД на ноде приводило с 80% вероятностью к ошибке:

Cannot create a shadow copy of the volumes containing writer's data. A VSS critical writer has failed. Writer name: [Microsoft Exchange Writer]. Class ID: [{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}]. Instance ID: [{cd169187-75d1-4c72-96f2-d41f9673f22e}]. Writer's state: [VSS_WS_FAILED_AT_FREEZE]. Error code: [0x800423f2].]

Понял, что где-то я был не прав, и обратился к первоисточнику, из которого http://technet.microsoft.com/ru-ru/library/dd876851.aspx выяснил, что необходимо отключить модуль записи VSS службы репликации Microsoft Exchange:

HKEY_LOCAL_MACHINE\Software\Microsoft\ExchangeServer\v14\Replay\Parameters.

Добавить новое значение DWORD с именем EnableVSSWriter и установить для него значение 0.

Отлично! Теперь бэкап выполняется….. в 60-70% случаев успешно;)

Техсаппорт Veeam отправил меня сюда http://www.veeam.com/kb_articles.html/KB1337/All:1:1/vss
что вообщем-то логично. Ну что ж, следовало ожидать. Будем трясти нашего железячника на предмет ускорения дисковой подсистемы.

Однако это еще не все проблемы, с которыми пришлось столкнуться:

Как многие знают, MS Exchange DAG кластер работает на базе стандартного MS Cluster Service. Суть кластера – обмен хертбитами. Если хертбиты пропадают, значит нода упала – надо поинтересоваться у свидетеля на предмет, не меня ли отрубили от сети и поднимать сервис.

А теперь вспомним, чем нам грозит создание и удаление снапшота виртуальной машины, который так необходим при выполнении бэкапа в виртуальной инфраструктуре. Правильно, потерей связи до гостя.

Иначе говоря, в моем случае, при выполнении бэкапа при создании или удалении снапшота, моя нода превращалась в полностью пассивную, что меня не очень устраивало. Хотелось разделить нагрузку.

По совету интернетов, поправил настройку MS Cluster Service http://technet.microsoft.com/en-us/library/dd197562(WS.10).aspx,
увеличив до максимума задержку между хертбитами (2 секунды) и порог срабатывания (количество пропущенных хертбитов до 10):

cluster /cluster:<ClusterName> /prop SameSubnetDelay=2

cluster /cluster:<ClusterName> /prop SameSubnetThreshold=10

Это помогло, но отчасти. Переключение между нодами стало происходить реже, но все таки пару раз в неделю я хватаю данный инцидент.

Дальнейшие разбирательства с темой привели меня все к тому же логическому заключению – необходимо ускорять дисковую подсистему.

Резюмируя данные результаты, приходим к выводу: если вы хотите бэкапить виртуальный кластер DAG, то у вас есть три варианта:

1. Бэкапить на уровне приложения (например при помощи
   DPM)
2. Бэкапить полностью пассивную ноду
3. Тюнинговать производительность ваших
   систем.