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

Некоторое время назад я устанавливал и настраивал инфраструктуру, которая состояла из среды непрерывной кластерной репликации (Cluster Continuous Replication - CCR), а также аварийного кластера с одним узлом, на котором была настроена резервная непрерывная репликация (Standby Continuous Replication - SCR). Инфраструктура отлично работала, и логи транзакций отлично передавались из среды CCR на аварийный кластер. Затем у меня появилась необходимость в проверке того, что резервный кластер SCR мог принимать на себя роль основного почтового сервера. Другими словами, несмотря на то, что логии транзакций копировались корректно в аварийный кластер SCR, откуда мне было знать, что этот кластер будет действительно работать, когда появится такая необходимость? Конечно, единственным надежным способом проверки такой ситуации было периодическое выполнение процесса обхода отказа. Поскольку это была рабочая среда с реальными пользователями, проверка процесса обхода отказа должна быть тщательно скоординирована. Мне нужно было убедиться в том, что существующая среда CCR не подвергнется влиянию процесса обхода отказа и данные не будут повреждены или утеряны.

В этом цикле статей я собираюсь подробно описать процесс, который я использовал для тестирования кластера SCR без негативных последствий для среды CCR. Для этого я создал тестовую среду, состоящую из нескольких серверов Windows 2008. В своем оригинальном проекте я использовал ОС Windows 2003, но поскольку Windows 2008 уже выпущена, и, скорее всего, будет использоваться именно эта версия операционной системы, я решил обновить свой процесс под Windows 2008. В своей тестовой среде я установил следующие серверы:

• DCHUBCAS: контроллер домена, на котором также установлены роли Hub Transport и Client Access Server.
• CCRA и CCRB: два узла среды CCR.
• CLUSTER-P: имя кластера среды CCR.
• E2K7: имя сервера Clustered Mailbox Server (CMS), имя, к которому подключаются клиенты Outlook.
• SCR: имя одного узла в аварийном кластере.
• CLUSTER-S: имя самого аварийного кластера.

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

Есть несколько других моментов, которые я хотел бы рассмотреть в этой статье:

• Прежде чем выполнять какие-либо тесты в своей рабочей среде, вам сначала нужно выполнить эти тесты в лабораторной среде. Не сложно создать тестовую среду, используя виртуальные машины, и вам действительно не захочется искать проблемы в своей рабочей среде после проведения таких тестов. Не могу выразить словами всю важность проведения теста в лабораторной среде.
• В моем примере есть одна почтовая база данных и одна база данных публичной папки. Если у вас больше баз данных, вам придется проверять каждую базу данных в индивидуальном порядке.
• Я лишь восстанавливаю роль CMS на аварийный кластер. Конечно, в реальности аварийные сайты кластеров SCR будут включать и другие роли, необходимые для восстановления после форс-мажорных обстоятельств, такие как контроллеры домена, DNS серверы, Hub Transport серверы и серверы Client Access Servers.
• Еще одним важным моментом является то, что как только среда CCR будет возвращена в рабочий режим, нужно будет заново заполнить базу данных на аварийном кластере SCR, чтобы он был снова готов к использованию в ситуации обхода отказа. Такая необходимость была продиктована наличием одной почтовой базы данных размером 30Гб и одной маленькой базой данных публичной папки. Может случиться так, что в ваших обстоятельствах нужно будет включить SCR на оригинальной среде CCR после выполнения теста SCR. Этот процесс я описывал в одной из своих предыдущих статей здесь на MSExchange.org, однако следует учитывать, что в той статье речь шла об операционной системе Windows 2003, а в этой статье я использую Windows 2008, и два этих процесса могут немного отличаться. Суть в том, что у вас есть несколько вариантов возвращения оригинальной производственной среды CCR в рабочий режим.

Итак, вы решили, что нужно выполнить тестирование конфигурации SCR, используя свою рабочую среду CCR. Первое, что нужно сделать, это заранее проинформировать своих пользователей о том, что на время тестирования систему нельзя использовать. Очевидно, что лучше всего это делать вне рабочего времени, как правило, это вечернее время, ночь или выходные. Необходимо, чтобы пользователи не использовали систему во время тестирования, поскольку существует вероятность того, что они потеряют сообщения, отправленные во время проверки. Позвольте мне объяснить, почему дело обстоит именно так. Во время проверки обхода отказа, о которой я будут говорить в этой статье, я буду восстанавливать CMS, чтобы он работал на аварийном кластере. Поэтому сервер CMS будет работать и отвечать на попытки подключения к нему. Поскольку он работает на аварийном кластере, он будет нормально обрабатывать сообщения через сервер Hub Transport, который также запущен на сайте аварийного восстановления. Когда проверка будет завершена, я отключу базу данных на аварийном кластере и перезапущу оригинальную рабочую среду CCR. Другими словами, все сообщения, которые были отправлены пользователями во время работы CMS на аварийном кластере, будут отсутствовать в базе данных производственной среды CCR, когда ее работа будет возобновлена. Это может смутить пользователей, если не сказать большего, поскольку в их папках будут отсутствовать некоторые сообщения, которые у них были. Вот почему важно держать пользователей подальше от системы во время проверки.

Итак, довольно слов ‘ перейдем к делу. Я описал каждый шаг в числовой последовательности.

Шаг 0 ‘ Создание резервной копии

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

Шаг 1 ‘ Разъединение подключения к интернету

Когда производственная среда CCR нормально работает, в качестве первого шага нужно будет предотвратить доставку входящих из интернета сообщений электронной почты на пользовательские почтовые ящики во время тестирования. Поэтому на данном этапе нужно отключить шлюзовой сервер SMTP, это может быть сервер Exchange 2007 Edge Transport, что означает, что все входящие сообщения из интернета будут становиться в очередь на сервере отправки SMTP. Большинство серверов SMTP будут повторять попытки доставки сообщений через 48 часов, поэтому у вас будет масса времени для выполнения проверки.

Шаг 2 ‘ Проверка избыточных машин

Следующий шаг является необязательным для всего процесса, но он может быть крайне полезен в понимании процесса. Этот шаг является выделением важности элемента конфигурации, с которым вам придется столкнуться в последующих частях. Используя оболочку Exchange Management Shell, выполните команду Get-MailboxServer и просмотрите содержимое параметра RedundantMachines. Пример показан на рисунке 1, где видно, что я выполнил команду Get-MailboxServer на сервере CMS под названием E2K7, и пропустил результаты через команду форматирования списка. Вы должны увидеть, что параметр RedundantMachines задан для имен двух узлов среды CCR, которыми в моем случае являются CCRA и CCRB. Параметр RedundantMachines изменяется программой Exchange 2007 setup.com во время процесса обхода отказа SCR, о чем я расскажу позже. А пока просто запомните параметр RedundantMachines и его значения в вашей среде.

Заключение

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