Обход отказа на основе кластерной непрерывной репликации с помощью аварийного копирования Standby Continuous Replication (часть 3)

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

• Обход отказа на основе кластерной непрерывной репликации с помощью аварийного копирования Standby Continuous Replication (часть 1)
• Обход отказа на основе кластерной непрерывной репликации с помощью аварийного копирования Standby Continuous Replication (часть 2)

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

Перемещение обратно на производственный центр данных

Теперь у нас следующая ситуация: CMS под названием CCREX01 запущен на кластере под названием E2K7CLU02, который состоит из двух узлов NH-W2K3-SRV01 и NH-W2K3-SRV05. Однако существует вероятность того, что в какой-то момент в будущем основной центр данных снова будет доступен, а вместе с ним и оригинальные узлы CCR кластера NH-W2K3-SRV03 и NH-W2K3-SRV04. Многие организации предпочитают запускать свои системы с первичных центров данных, поэтому ситуацию перехода обратно на первичный центр данных необходимо рассмотреть. Первичный (основной) кластер все еще считает, что на нем установлен и настроен CMS, поэтому его нужно удалить. Для этого нужно сделать следующее.

Сначала я выведу оба узла NH-W2K3-SRV03 и NH-W2K3-SRV04 в режим онлайн. Конечно, это подразумевает, что такие службы, как Active Directory, Hub Transport и Client Access Servers уже настроены и запущены на основном производственном центре данных. На момент сбоя основного центра данных активным узлом был NH-W2K3-SRV03, поэтому запуск администратора кластера Cluster Administrator на этом узле показывает нам, что все ресурсы CMS работают в автономном режиме, как вы и предполагали. Это показано на рисунке 9.

Чтобы удалить ресурсы CMS с кластера, нам нужно запустить программу Exchange 2007 setup.com на узле NH-W2K3-SRV03 с переключателем /ClearLocalCMS. Нам также нужно указать имя CMS. Полная команда выглядит так:

setup.com /ClearLocalCMS /CMSName:CCREX01

На рисунке 10 показаны результаты использования этой команды.

Как только это было выполнено, обновление администратора кластера подтверждает, что ресурсы CMS были удалены. Если вы задумаетесь, то поймете, что серверы NH-W2K3-SRV03 и NH-W2K3-SRV04 теперь имеют такую же конфигурацию, что и серверы NH-W2K3-SRV01 и NH-W2K3-SRV05 до того, как мы начали процесс копирования SCR; у нас есть четкое зеркало предыдущей установки.

Активация SCR на производственном центре данных

Поскольку у нас есть зеркало нашей предыдущей установки, нам нужно воспроизвести SCR настройку, которую мы осуществили ранее в этой статье. Другими словами, нам нужно активировать SCR с аварийного центра данных, на котором в настоящее время лежит CMS, на производственный центр данных. NH-W2K3-SRV03 будет выбран в качестве целевого узла для SCR, и поэтому нам нужно запустить следующие команды:

Enable-StorageGroupCopy 'CCREX01\First Storage Group' 'StandbyMachine NH-W2K3
-SRV03 'ReplayLagTime 0.0:0:0

Enable-StorageGroupCopy 'CCREX01\Second Storage Group' 'StandbyMachine NH-W2K3
-SRV03 'ReplayLagTime 0.0:0:0

Конечно в моем сценарии я просто отключил питание узлов NH-W2K3-SRV03 и NH-W2K3-SRV04, а это означает, что старые базы данных и файлы логов все еще можно использовать. Однако в этой статье я предположу, что необходима полная повторная отправка, наряду с применением SCR обратно на производственный центр данных. Мы уже рассматривали эти команды в предыдущей части, поэтому я не буду приводить еще один рисунок.

Повторная отправка (Reseed) базы данных

Поскольку NH-W2K3-SRV03 сейчас имеет включенное SCR и копию базы данных, важно позаботиться об отправке базы данных на NH-W2K3-SRV04, что можно сделать либо после того, как CMS выведен в режим онлайн на NH-W2K3-SRV03, либо ускорить этот процесс путем настройки NH-W2K3-SRV04 в качестве целевого узла SCR для CMS. Поскольку я работаю с тестовой средой, я не против повторной отправки базы данных на NH-W2K3-SRV04, однако стоит учитывать этот вариант при работе с производственной средой. Я уже рассказывал о переносе баз данных во второй части этой серии статей, поэтому не буду повторять.

Демонтирование баз данных

Прежде чем перейти обратно к NH-W2K3-SRV03, следующим шагом будет демонтирование баз данных, используемых на CCREX01, поскольку в отличие от первого случая, когда мы переносили CMS между узлами, в этот раз CMS все еще работает и обслуживает пользователей. Базы данных сначала нужно демонтировать, чтобы убедиться, что они не генерируют новых логов трансакций, которые потом нужно будет передавать через NH-W2K3-SRV03. В продолжение нашей темы использования оболочки EMS процесс демонтирования баз данных может быть выполнен с помощью двукратного использования команды Dismount-Database, как показано ниже:

Dismount-Database 'CCREX01\First Storage Group\Mailbox Database'

Dismount-Database 'CCREX01\Second Storage Group\Public Folder Database'

О результатах использования этих команд можно сказать совсем немного, поскольку все, что вы получите после их использования, это сообщение 'are you sure?', если вы не отключите эту опцию. Чтобы отключить эту опцию, просто добавьте к командам, указанным выше, параметр 'Confirm:$false.

Восстановление групп хранения

Далее нужно подготовить группы хранения к монтированию, используя команду Restore-StorageGroupCopy. Нужно использовать следующие две команды:

Restore-StorageGroupCopy 'CCREX01\First Storage Group' 'StandbyMachine NH-W2K3-SRV03

Restore-StorageGroupCopy 'CCREX01\Second Storage Group' 'StandbyMachine 
NH-W2K3-SRV03

Возможно вы помните из второй части, что мы использовали команду Restore-StorageGroupCopy с параметром 'Force. На этот раз такой параметр не требуется, поскольку узлы CMS запущены, а, следовательно, вся необходимая информация доступна. Я не буду приводить здесь рисунок, поскольку в результате использования этих команд не выводится никаких данных.

Остановка CMS

Теперь CMS, запущенный на резервном центре данных, нужно остановить, используя команду Stop-ClusteredMailboxServer, поскольку на этот раз CMS все еще работает в отличие от изначальной ситуации обхода отказа, где он не был запущен. Здесь используется следующая команда:

Stop-ClusteredMailboxServer CCREX01 'StopReason 'Moving back to production 
data center'

В приведенной выше команде мы видим параметр 'StopReason, который используется для добавления в журнал регистрации событий причины остановки CMS. Если вы посмотрите журнал регистрации событий после запуска этой команды, вы должны будете увидеть событие ID 105 с выбранной вами фразой. Запуск команды Stop-ClusteredMailboxServer должен вывести данные подобные тем, что показаны на рисунке 11. Вам также следует проверить, используя администратора кластера, что ресурсы CMS находятся в автономном режиме.

Восстановление CMS

После всего проделанного мы дошли до того момента, когда нам нужно восстановить CMS на сервер NH-W2K3-SRV03. Мы уже рассматривали этот процесс во второй части, поэтому я лишь вкратце опишу его еще раз. Просто помните, что вам нужно указать IP адрес для CMS, когда используете /RecoverCMS переключатель, поэтому в этот раз вы будете назначать для CMS IP адрес в IP подсети производственного центра данных. Скорее всего, вы назначите для CMS его изначальный IP адрес.

На рисунке 12 показано повторное восстановление CMS с назначением изначального IP адреса 172.16.6.80.

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

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

• Удалить локальный CMS с кластера E2K7CLU02, запущенного на резервном центре данных.
• Активировать SCR с основной CCR среды на целевой аварийных кластер.

Резюме

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

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

• Обход отказа на основе кластерной непрерывной репликации с помощью аварийного копирования Standby Continuous Replication (часть 1)
• Обход отказа на основе кластерной непрерывной репликации с помощью аварийного копирования Standby Continuous Replication (часть 2)