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

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

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

Отправка SCR цели

Давайте рассмотрим процесс отправки SCR цели. Хотя это можно сделать вручную путем демонтирования и копирования баз данных, я буду использовать оболочку Exchange Management Shell (EMS), чтобы добиться желаемого результата. Этот процесс заключается в использовании нескольких команд EMS, самой распространенной из которых будет команда Update-StorageGroupCopy, и мы будем запускать эти команды с пассивного узла NH-W2K3-SRV01.

Перед повторной отправкой базы данных необходимо остановить процесс репликации групп хранения, используя команду Suspend-StorageGroupCopy. Поскольку у нас есть две группы хранения, с которыми мы работаем, то мы одновременно приостановим дублирование обеих групп, как показано на рисунке 4 ниже. Используем следующие команды:

Suspend-StorageGroupCopy 'CCREX01\First Storage Group' 'StandbyMachine NH-W2K3-SRV01

Suspend-StorageGroupCopy 'CCREX01\Second Storage Group' 'StandbyMachine NH-
W2K3-SRV01

Когда репликация остановлена, можно удалить все существующие файлы базы данных с NH-W2K3-SRV01. Если вы еще раз посмотрите на рисунок 3 первой части, то увидите, что активация SCR уже создала несколько логов трансакций в папке группы хранения на NH-W2K3-SRV01, но не файлы баз данных. Это потому, что SCR создает целевую базу данных только после того, как, по меньшей мере, 50 логов трансакций будут скопированы из источника SCR, а также когда значение периода, указанного в 'ReplayLagTime достигнуто. Значение в 50 логов трансакций жестко прописано в коде и поэтому не может быть изменено. Как вы видели из команды, которую мы использовали для активации SCR, значение 'ReplayLagTime было установлена на 0, что означает, что действительная база данных будет создаваться только после того, как 50 логов трансакций будут переданы с источника SCR. Повторная отправка баз данных теперь будет создавать базу данных немедленно.

Давайте вернемся к удалению существующих файлов базы данных. Теперь можно безопасно удалить любые .EDB, .LOG, .JRS и .CHK файлы из папок, содержащих копии групп хранения на NH-W2K3-SRV01. Как только это сделано, базы данных можно отправить на NH-W2K3-SRV01, используя следующие команды:

Update-StorageGroupCopy 'CCREX01\First Storage Group' 'StandbyMachine NH-W2K3-SRV01

Update-StorageGroupCopy 'CCREX01\Second Storage Group' 'StandbyMachine NH-W2K3-
SRV01

Результаты использования этих команд показаны на рисунке 5, где показан процесс отправки баз данных в действии.

Команды, используемые выше, автоматически возобновят процесс репликации на SCR цели, поэтому в этот раз нет необходимости использовать команду Resume-StorageGroupCopy.

Процесса сайта обхода отказа

На данном этапе SCR была настроена и все логи трансакций, которые создаются на активном узле среды CCR, будут не только копироваться на пассивный узел CCR, но и на SCR целевой сервер NH-W2K3-SRV01. Таким образом, предположив, что среда CCR расположена на производственном центре данных, среда SCR лежит на резервном центре даных, на котором также имеются все остальные необходимые службы, гибкое решение сайтов создано. К этим другим необходимым службам относятся контроллеры доменов Active Directory, серверы Hub Transport, серверы клиентского доступа, DNS, и т.д..

Чтобы симулировать сбой производственного центра данных, а, в следствии этого, и производственной среды CCR, я просто выключу активный и пассивный узлы в среде CCR, то есть NH-W2K3-SRV03 и NH-W2K3-SRV04. На данном этапе нам нужно восстановить CMS, CCREX01, который сейчас работает на резервном кластере. Для этого нужно выполнить несколько шагов, первым из которых будет активация копирования группы хранения на резервном кластере с помощью команды Restore-StorageGroupCopy. Вы помните, что когда мы первый раз активировали копирование группы хранения, мы указывали целевой сервер, как NH-W2K3-SRV01, поэтому сейчас я запущу команду Restore-StorageGroupCopy с этого узла аварийного кластера. Используем следующие две команды:

Restore-StorageGroupCopy 'Identity 'CCREX01\First Storage
 Group' 'StandbyMachine NH-W2K3-SRV01 -Force

Restore-StorageGroupCopy 'Identity 'CCREX01\Second Storage 
Group' 'StandbyMachine NH-W2K3-SRV01 -Force

Вы должны были обратить внимание на параметр 'Force в обеих вышеуказанных командах. Он используется, когда SCR источник, в данном случае среда CCR, состоящая из NH-W2K3-SRV03 и NH-W2K3-SRV04, больше не доступен, что и случается при сбоях на производственных центрах данных. Если бы оригинальный SCR источник все еще был доступен, параметр 'Force не использовался бы, поскольку все невыполненные логи трансакций скопировались бы с SCR источника. Результат использования этих команд показан на рисунке 6.

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

Как только группы хранения были подготовлены для монтирования с помощью команд Restore-StorageGroupCopy, можно восстанавливать CMS. Для этого просто нужно запустить программу Exchange 2007 setup.com на целевом сервере NH-W2K3-SRV01. Программа setup.com имеет специальный переключатель под названием /RecoverCMS, который требует, чтобы вы указали имя восстанавливаемого CMS, а также его IP адрес. Здесь нужно учитывать, что если вы восстанавливаете CMS на другом центре данных, то вам, скорее всего, придется указать для него новый IP адрес, поскольку восстановленный центр данных скорее всего будет на другой IP подсети. Вот почему в примере, приведенном ниже, используется IP адрес 172.16.6.153, а не ранее назначенный (172.16.6.80), когда кластерный почтовый сервер лежал на узлах NH-W2K3-SRV03 и NH-W2K3-SRV04. Это абсолютно нормально. Команда setup.com, которую я использовал в этом примере, выглядит следующим образом:

setup.com /RecoverCMS /CMSName:CCREX01 /CMSIPAddress:172.16.6.153

На рисунке 7, показаны результаты использования программы setup.com.

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

Mount-Database 'Identity 'CCREX01\First Storage Group\Mailbox Database'

Mount-Database 'Identity 'CCREX01\Second Storage Group\Public Folder Database'

Предположив, что базы данных были смонтированы правильно, EMS вернется без уведомления об ошибках. Затем я убедился, что имею доступ к своим почтовым ящикам как обычно, что было именно так.

Воссоздание среды CCR

Итак, мы успешно восстановили CMS на NH-W2K3-SRV01 и смонтировали базы данных, до настоящего момента все идет по плану. Однако поскольку производственный центр данных имеет CCR конфигурацию, желательно, чтобы резервный центр данных имел сходную конфигурацию, особенно если в планы входит дальнейшая работа с этого центра данных в течение некоторого времени. Поэтому нам необходимо убедиться, что базы данных размещены на другом узле кластера этого резервного центра данных, а именно на NH-W2K3-SRV05. В результате этого процесса, изначальный аварийный кластер, запущенный на резервном центре данных, теперь будет представлять собой полную среду CCR, на которой будет запущен оригинальный CMS под названием CCREX01. Вы уже выдели подробную информацию о процессе переноса баз данных в этой статье, поэтому я не буду повторять ее.

В качестве последнего тестирования конфигурации аварийного кластера под названием E2K7CLU02, было бы благоразумно убедиться в том, что CMS и другие ресурсы кластера могут быть корректно перемещены между двумя узлами кластера, NH-W2K3-SRV01 и NH-W2K3-SRV05. Поскольку ресурсы на данный момент запущены на NH-W2K3-SRV01, нам нужно переместить их на NH-W2K3-SRV05 и проверить на предмет корректной работы. Стандартная группа кластера, которая содержит ресурсы, такие как Majority Node Set, может быть легко перемещена путем нажатия правой клавишей на группе под названием группа кластера - Cluster Group в администраторе кластера и выбора опции Переместить из контекстного меню, как показано на рисунке 8.

Ресурсы CMS необходимо переместить с помощью команды Move-ClusteredMailboxServer. Полная команда показана ниже, где параметр 'TargetMachine используется для указания узла в кластере, на который вы собираетесь переместить ресурсы, а параметр 'MoveComment используется для указания причины переноса, которая записывается в журнал регистрации событий.

Move-ClusteredMailboxServer CCREX01 'TargetMachine NH-W2K3-SRV05 
'MoveComment 'Test move after CMS recovery'

В результате использования этой команды все ресурсы CMS должны быть переключены в автономный режим, перенесены на NH-W2K3-SRV05 и затем обратно переключены в интерактивный режим. Сейчас вам нужно убедиться, что доступ к CMS все еще имеется и, что вы можете быть уверены в том, что CMS будет надежно работать на обоих узлах кластера резервной среды CCR.

Резюме

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

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