Тестирование аварийной непрерывной репликации в производственной среде (часть 2)

В этом цикле мы рассматриваем шаги, необходимые для процесса восстановления Exchange 2007 SCR без ущерба для существующей среды CCR, работающей в качестве источника SCR. В первой части мы в основном обозначили сцену действий для тестирования обхода отказа, я описал серверы и роли каждого сервера в тестовой среде. В этой части мы рассмотрим процесс остановки среды CCR, восстановление групп хранения на аварийном кластере SCR, а также внесение необходимых изменений в DNS. В предыдущей части мы закончили на втором шаге общего процесса, поэтому данную часть мы начнем с третьего шага.

Шаг 3 ‘ остановка CMS

Далее нам нужно остановить CMS, который в свою очередь демонтирует все базы данных на CMS. Это также осуществляется через оболочку Exchange Management Shell с помощью команды Stop-ClusteredMailboxServer. Для успешного использования этой команды нужно ввести имя сервера CMS, который вы хотите остановить, а также нужно указать причину остановки в параметре ‘StopReason. То, что вы укажите в параметре StopReason, затем будет добавлено в журнал регистрации событий под кодом ID 105, как показано на рисунке 2.

Полная команда, используемая для остановки сервера CMS, может выглядеть, как показано в примере, где имя сервера CMS было E2K7:

Stop-ClusteredMailboxServer E2K7 ‘StopReason ‘SCR failover test’ ‘Confirm:$false

В результате выполнения этой команды вы получаете данные о том, что сервер CMS теперь работает в автономном режиме, как показано на рисунке 3.

Также обратите внимание, что я использовал параметр ‘Confirm и задал ему значение false, в результате чего вопрос подтверждения ‘Вы уверены, что хотите продолжить (Are you sure)?’ задаваться не будет, и вам не придется давать свое подтверждение. Затем нужно проверить через консоль Exchange Management Console или оболочку Exchange Management Shell, что все базы данных были демонтированы в результате выполнения команды Stop-ClusteredMailboxServer. Лично я считаю полезным выполнение программы Cluster Administrator (если вы используете Windows 2003) или программы Failover Cluster Management (в случае использования Windows 2008) для проверки того, что все ресурсы кластера CMS находятся в автономном режиме после выполнения команды. На рисунке 4 показана программа Failover Cluster Management в действии на Windows 2008.

Шаг 4 ‘ отключение среды CCR

Об этом шаге можно не многое сказать. Когда CMS остановлен, а базы данных демонтированы, самое время отключать оба узла среды CCR. Сначала нужно отключить пассивный узел, а после этого – активный. В результате среда CCR будет безопасно отключена, а в будущем вам это может пригодиться.

Шаг 5 ‘ восстановление групп хранения

Теперь мы находимся на том этапе, когда среда CCR отключена и нужно переместить сервер CMS на аварийный кластер SCR. Как упоминалось ранее, я не рассматривал процесс установки SCR, поскольку он отлично описан в других статьях. Поэтому предполагается, что на данном этапе у вас включена SCR, и кластер корректно работает. Если это так, то я перехожу к описанию процесса, необходимого для перемещения CMS на аварийный кластер.

Для выполнения процесса перемещения вам понадобится команда Restore-StorageGroupCopy. Эта команда является ключевым компонентом в активации копии групп хранения на аварийном кластере SCR. Двумя основными параметрами являются параметры ‘StandbyMachine и ‘Force. В параметре ‘StandbyMachine указывается имя целевого SCR сервера, на котором будет размещен сервер CMS, а параметр ‘Force используется в тех ситуациях, когда источник SCR недоступен, например, когда среда CCR была утеряна. Это может быть либо полный отказ обоих узлов среды CCR, либо потеря центра данных, на котором располагалась среда CCR. Конечно, в моем примерном сценарии среда CCR недоступна, так как она была отключена, поэтому я использую параметр ‘Force. Если вы не укажите параметр ‘Force, и источник SCR будет недоступен, вы получите ошибку, говорящую о том, что процесс восстановления не смог проверить условия монтирования исходной базы данных.

Примечание: Потеря данных предполагается, если используете параметр ‘Force, как показано на рисунке 5.

Поскольку в моем примере есть две группы хранения, мне нужно выполнить команду Restore-StorageGroupCopy дважды. Обратите внимание, что я выполняю эту команду на самом кластере SCR. Полный синтаксис этой команды выглядит следующим образом:

Restore-StorageGroupCopy ‘Identity ‘E2K7\First Storage Group’ ‘StandbyMachine SCR ‘Force

Restore-StorageGroupCopy ‘Identity ‘E2K7\Second Storage Group’ ‘StandbyMachine SCR ‘Force

Результаты выполнения этих команд показаны на рисунке 5. Как я уже говорил, будут предупреждения о потере данных при использовании параметра ‘Force. Поскольку это тестовый обход отказа, в котором среда CCR была безопасно отключена, мы не утратим никаких данных.

Если у вас много групп хранения, которые нужно восстановить, вы можете воспользоваться сценарием GetScrSources.ps1, который поставляется в комплекте с Exchange 2007 Service Pack 1. Вы найдете этот сценарий в папке с остальными сценариями в \Program Files\Microsoft\Exchange Server\Scripts. Если вы просто выполнение отдельно этот сценарий, вы получите результаты, похожие на те, что показаны на рисунке 6.

Можно выполнить этот сценарий и обработать результаты в команде Restore-StorageGroupCopy, не забыв включить параметры -StandbyMachine и -Force. Пример, который я использовал в своей тестовой среде, был следующим:

GetScrSources | Restore-StorageGroupCopy ‘StandbyMachine SCR ‘Force

На рисунке 7 приведены результаты использования этой команды в моей среде. Как вы, вероятно, подозревали, результаты получились одинаковыми, поэтому данный сценарий отлично подходит для тех, у кого на самом деле есть много групп хранения, которые нужно восстановить.

Шаг 6 ‘ изменение DNS

Прежде чем восстанавливать сервер CMS на аварийном кластере, нужно выполнить два очень важных шага. Первый шаг включает внесение изменений в DNS, если ваша среда работает под управлением Windows 2008. В этом случае вам нужно удалить существующие записи DNS для CMS. Для этого просто воспользуйтесь оснасткой DNS Management и удалите запись DNS A, которая соответствует серверу CMS, как показано на рисунке 8. Помните, что это подходит только для Windows 2008; не нужно этого делать для Windows 2003. Если вы не сделаете этот шаг для Windows 2008, вы будете получать ошибки при попытке восстановления CMS, говорящие о невозможности подключения к Internet Information Server (IIS) на целевом сервере SCR.

Когда вы удалили запись DNS A для CMS, убедитесь что DNS не только обновлен для всех контроллеров домена, но и что вы отчистили кэш на своем резервном кластере SCR с помощью команды ipconfig /flushdns.

Заключение

В этой части цикла статей мы находимся на той стадии, где существующая среда CCR была отключена, и копии групп хранения были активированы на аварийном кластере SCR. В следующей части мы закончим рассмотрение шагов, необходимых для перехода на аварийный кластер SCR путем восстановления сервера CMS, монтирования баз данных и проверки доступности почтовых ящиков.