Тестирование SCR в производственной среде (часть 4)

Если вы хотите прочитать предыдущие части этого цикла статей, перейдите по ссылкам:

• Тестирование SCR в производственной среде (часть 1)
• Тестирование SCR в производственной среде (часть 2)
• Тестирование SCR в производственной среде (часть 3)

Введение

Это четвертая и заключительная часть цикла статей о том, как восстанавливать Clustered Mailbox Server (CMS) на резервном кластере SCR для тестирования без ущерба для исходной копии данных SCR. В этой статье источник SCR представляет собой среду CCR с двумя узлами кластера.

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

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

После того, как мы убедились, что CMS был успешно восстановлен на аварийном кластере SCR, пришло время перейти обратно к производственной среде CCR. Однако мы не будем использовать процесс setup.com /RecoverCMS в среде CCR, как вы увидите позже. Во-первых, для того, чтобы перейти обратно к использованию производственной среды CCR, нужно остановить CMS на аварийном кластере SCR, для чего используется команда Stop-ClusteredMailboxServer. Так как я уже описывал эту команду во втором шаге этой статьи, я не будут повторяться.

Шаг12 ‘ отчистка SCR CMS

Даже несмотря на то, что CMS был остановлен на аварийном кластере SCR, действительный объект CMS все еще связан с этим сервером, и поэтому клиенты все еще будут пытаться подключиться к нему. Сейчас нам нужно удалить CMS, чтобы он больше не работал под аварийным кластером SCR. Помните, у нас есть отлично работающий CMS, который ждет того, чтобы мы его снова запустили в среде CCR, остановленной ранее, поэтому CMS, который работал на аварийном кластере SCR, больше не требуется.

Для удаления CMS мы можем воспользоваться программой Exchange 2007 setup.com с ключом /ClearLocalCMS. При использовании этого ключа также необходимо указать, чтобы имя CMS сервера было удалено, это делается с помощью ключа /CMSName. Пример полной команды приведен ниже:

setup.com /ClearLocalCMS /CMSName:E2K7

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

После выполнения этой команды я всегда запускаю программу Администратор кластера (Cluster Administrator) или Управление кластером обхода отказа (Failover Cluster Management) и проверяю, что ресурсы CMS были на самом деле удалены из каждого кластера. Это показано на рисунке 15. Как вы видите, на аварийном кластере CLUSTER-S больше нет работающих приложений и служб.

Здесь также следует отметить, что выполнение команды /ClearLocalCMS отключает учетную запись компьютера CMS. Добавьте сюда пояснение Тима. Ее нужно будет повторно включить немного позже.

Шаг 13 ‘ запуск CCR среды

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

Шаг 14 ‘ Reset RedundantMachines

Вы наверняка помните из первой части этого цикла статей, что я подробно рассказывал о параметре RedundantMachines, важном атрибуте команды Get-MailboxServer. После создания производственной среды CCR этот параметр будет настроен на содержание имена двух узлов, которые образуют среду CCR, как мы видели в первой части. В моем примере атрибут RedundantMachines имел значение {CCRA,CCRB}. С того времени CMS был остановлен на аварийном кластере SCR, протестирован и удален.

Теперь давайте выполним команду Get-MailboxServer на CMS и профильтруем ее, чтобы посмотреть, какое значение сейчас имеет параметр RedundantMachines. Для этого я использую следующую команду:

Get-MailboxServer E2K7 | fl RedundantMachines

Это команда отобразит только атрибут RedundantMachines в результатах, как показано на рисунке 16.

Вы видите, что параметр RedundantMachines сейчас имеет значение с одним именем сервера, а именно узла аварийного кластера SCR. Причина такого изменения заключается в том, что этот атрибут был настроен программой Exchange 2007 setup.com, когда использовался ключ /RecoverCMS. Это все хорошо, однако проблема заключается в том, что среда CCR была снова запущена, и поэтому параметр RedundantMachines снова нужно установить на {CCRA,CCRB}, так как это сейчас те два узла кластера, которые образуют среду CCR. Однако мы не собираемся восстанавливать CMS на среду CCR, поскольку он уже там есть, поэтому нет необходимости выполнять программу setup.com с ключом /RecoverCMS. Нужно вручную изменить значение атрибута RedundantMachines с помощью команды Set-MailboxServer. Это значение можно изменить, только когда оба узла кластера запущены, и именно поэтому данные шаги были выполнены ранее. Пример команды для изменения атрибута RedundantMachines приведен ниже:

Set-MailboxServer -Identity E2K7 -RedundantMachines CCRA,CCRB

Вам лишь нужно указать значение атрибута RedundantMachines в виде двух, разделенных запятой NetBIOS имен серверов. Если все прошло успешно, оболочка не вернет никаких результатов, поэтому всегда нужно повторно выполнить команду Get-MailboxServer, чтобы быть уверенным, что атрибут получил нужное значение, как показано на рисунке 17.

Шаг 15 ‘ повторное включение учетной записи компьютера

Как уже говорилось, выполнение процесса /ClearLocalCMS также отключает учетную запись компьютера CMS, поэтому ее нужно снова запустить. Следующим шагом будет запуск оснастки Active Directory Users and Computers и поиск учетной записи компьютера CMS. Когда запись найдена, просто нажмите на ней правой клавишей и выберите Включить учетную запись (Enable Account) из контекстного меню.

Шаг 16 ‘ запуск CMS

Запуск сервера CMS также включает другие ключевые ресурсы в этой группе кластера, такие как ресурсы IP адреса и сетевого имени (Network Name). Запуск ресурса сетевого имени также означает, что DNS A запись для сервера CMS теперь корректно обновлена и имеет то же значение, которое имела до остановки среды CCR.

После запуска сервера CMS вам нужно воспользоваться оснасткой Failover Cluster Management для проверки того, что все ресурсы CMS находиться в режиме онлайн.

Шаг 17 ‘ проверка доступа к почтовым ящикам

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

Заключение

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

Если вы хотите прочитать предыдущие части этого цикла статей, перейдите по ссылкам:

• Тестирование SCR в производственной среде (часть 1)
• Тестирование SCR в производственной среде (часть 2)
• Тестирование SCR в производственной среде (часть 3)