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

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

Если вы читали предыдущие части этой статьи, то вы знаете, что на данном этапе мы уже близки к тому, чтобы восстановить CMS на аварийный кластер SCR. Во второй части цикла мы завершили один из двух шагов, которые необходимо выполнить, прежде чем выполнять /RecoverCMS часть программы Exchange 2007 setup.com. Давайте перейдем ко второму (из этих двух) шагу.

Шаг 7 ‘ Изменение разрешений учетной записи компьютера

Второй важный шаг, который нужно выполнить, прежде чем восстанавливать CMS, связан с разрешениями учетной записи компьютера CMS. Если говорить более точно, то вам нужно убедиться на Windows 2008, что Cluster Name Object (CNO) полностью контролирует учетную запись компьютера CMS. Если вы используете Windows 2003, замените CNO учетной записью службы кластера. Поскольку в своей тестовой лаборатории я использую Windows 2008, я буду подробно описывать процесс, который использовал в этой среде. Я обнаружил, что если не сделать этот шаг, то я получал следующую ошибку при выполнении команды /RecoverCMS, которую я подробно описал ниже:

‘Cluster Common Failure Exception: Failed to bring cluster resource Network name (<NAME>) in cluster group <NAME> online. The group or resource is not in the correct state to perform the requested operation. (Exception from HRESULT:0x8007139f)’

Тим Макмайкл из компании Microsoft в документах описал, почему это происходит, здесь. Вот шаги, которые я выполнил для корректной настройки разрешений:

1. В оснастке Active Directory Users and Computers находим учетную запись компьютера CMS.
2. Прежде чем сделать что-либо еще, выберите опцию Дополнительные функции (Advanced Features) из меню Вид (View), чтобы у вас отображалась закладка Безопасность (Security) на странице свойств учетной записи компьютера.
3. Нажмите правой клавишей на учетной записи компьютера CMS и выберите опцию Свойства (Properties) из контекстного меню.
4. Перейдите в закладку Безопасность и нажмите кнопку Добавить (Add).
5. В открывшемся окне под названием Выбор пользователей, компьютеров или групп (Select Users, Computers, or Groups) нажмите кнопку Типы объектов (Object Types) и убедитесь, что опция Компьютеры (Computers) выбрана. Это показано на рисунке 9.

1. В окне выбора пользователей, групп или компьютеров введите кластерное имя объекта (Cluster Name Object), которое соответствует аварийному кластеру, а затем нажмите кнопку Проверка имен (Check Names). В моей тестовой среде CNO для аварийного кластера было CLUSTER-S, а CNO для среды CCR было CLUSTER-P.
2. В закладке безопасности учетной записи компьютера CMS убедитесь, что CNO имеет полный набор разрешений. Это показано на рисунке 10.

Шаг 8 ‘ восстановление CMS

Далее нам нужно восстановить CMS на целевом сервере SCR, используя программу Exchange 2007 setup.com. Программа setup.com включает /RecoverCMS ключ, который используется для восстановления CMS на новом сервере. Ключ /RecoverCMS имеет два основных параметра, которые вам нужно использовать, а именно /CMSName и /CMSIPAddress параметры. Названия этих параметров говорят сами за себя, они обеспечивают имя и IP адрес сервера CMS. Очевидно, что имя CMS не измениться, поскольку именно к этому имени клиенты Outlook подключаются, и тот же CMS восстанавливается на новый физический сервер. Однако следует учитывать, что во многих конфигурациях CMS, скорее всего, будет восстанавливаться на другой центр данных, на котором задан другой диапазон IP адресов, поэтому вполне вероятно, что параметр /CMSIPAddress будет содержать абсолютно новый IP адрес для вашего CMS. Это абсолютно нормально во многих ситуациях. В моем примере ниже новый IP адрес сервера CMS указан, но он находится в одной подсети. Дело обстоит так только потому, что тестовая среда, которую я использую, расположена в одной подсети. Полный синтаксис команды setup.com, которую я использовал, выглядит следующим образом:

setup.com /RecoverCMS /CMSName:E2K7 /CMSIPAddress:192.168.50.57

Результаты выполнения этой команды показаны на рисунке 11. Вы увидите, что в результате успешного завершения этого шага будет приведен список ЗАВЕРШЕННЫХ (COMPLETED) действий, проводившихся во время проверки на совместимость и конфигурации объекта CMS. Также после выполнения этого шага я всегда проверяю DNS, чтобы убедиться, что новая DNS A запись существует для CMS с корректным IP адресом.

Стоит проверить программу Failover Cluster Management после выполнения процесса /RecoverCMS, чтобы посмотреть статус различных ресурсов кластера. В моем примере (рисунок 12) вы заметите, что два ресурса баз данных еще не находятся в режиме онлайн. Дело обстоит так, потому что базы данных в настоящее время демонтированы, и мы исправим это в следующем шаге.

Процесс setup.com /RecoverCMS также требует обновления DNS, а именно записи CMS A, которая преобразуется в новый IP адрес.

Шаг 9 ‘ монтирование баз данных

Когда CMS успешно восстановлен на аварийный кластер SCR, можно монтировать базы данных. Для этого можно использовать команду Mount-Database, хотя, конечно, можно воспользоваться и консолью Exchange Management Console. Вы помните, что в моем примере есть одна база данных почтовых ящиков и одна база данных публичной папки, которые необходимо смонтировать, поэтому я выполняю команду Mount-Database дважды:

Mount-Database ‘Identity ‘E2K7\First Storage Group\Mailbox Database’

Mount-Database ‘Identity ‘E2K7\Second Storage Group\Public Folder Database’

На рисунке 13 показано, что успешное монтирование баз данных через Exchange Management Shell не генерирует сообщения об успешном завершении процесса в результатах команды. Можно воспользоваться консолью Exchange Management Console для проверки того, что все базы были смонтированы.

Если у вас есть один почтовый сервер с множеством баз данных почтовых ящиков, вы можете быстро смонтировать их все с помощью следующей команды:

Get-MailboxDatabase | Mount-Database

Первая команда Get-MailboxDatabase получит базы данных почтовых ящиков и направит результаты на обработку командой Mount-Database.

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

Хотя вы вполне можете воспользоваться консолью Exchange Management Console для проверки того, что базы данных были смонтированы, есть еще один способ проверки доступности CMS для пользователей, нужно лишь зайти в почтовые ящики пользователей. В конце концов, в применении SCR не будет смысла, если у вас не будет рабочей системы после аварии. На данном этапе вам нужно зайти в почтовый ящик с сервера CMS, используя Outlook или Outlook Web Access. Проверьте наличие последней информации, которая могла быть добавлена в почтовые ящики. К тому же, вам, возможно, понадобится убедиться в том, что CMS может взаимодействовать с сервером Hub Transport на аварийном сайте, и вы всегда можете отправить тестовые сообщения между двумя почтовыми ящиками на одном сервере CMS. Однако не стоит забывать о том, что в этом конкретном сценарии мы собираемся вернуть оригинальную среду CCR в режим онлайн, поэтому все отправленные сообщения не вернутся в среде CCR; именно поэтому важно убедиться, что пользователи не используют систему во время тестирования.

Заключение

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