Восстановление сервера Exchange 2007 Clustered Mailbox Server (CMS) с помощью RecoverCMS Switch

В предыдущей статье этой серии из двух частей о восстановлении потерянного сервера CMS в Exchange Server 2007, мы рассмотрели процесс установки пассивного почтового сервера, восстановление самого CMS, а также процесс восстановления базы данных почтового ящика из резервной копии. В этой статье мы продолжим с того места, на котором остановились в прошлый раз. Мы установим роль пассивного почтового сервера (Passive Mailbox Server) на дополнительные узлы кластера Windows, обновим копии групп хранения, возобновим репликацию, протестируем кластер обхода отказов и, наконец, объясним вам, как удалять устаревшие объекты учетных записей компьютера и записи A-records в Active Directory и DNS соответственно.

Установка роли пассивного почтового сервера (Passive Mailbox Server) на дополнительные узлы

На данном этапе наш кластер Exchange 2007 восстановлен и готов к работе, но поскольку пока у нас есть только один узел, он не обеспечивает достаточно дублирования! Итак, давайте продолжим и добавим дополнительные узлы кластера на сервер Clustered Mailbox Server. Добавление дополнительных узлов на CMS представляет собой весьма простую задачу, так как требуется только запустить мастера установки Exchange Setup и затем установить роль пассивного кластерного почтового сервера на каждом узле. Процедура идентична той, что была описана в разделе 'Установка роли пассивного почтового сервера на одном из новых узлов' ранее в этой серии, поэтому я не буду перечислять эти шаги снова.

Рисунок 2.1: Установка роли пассивного почтового сервера на дополнительные узлы кластера

Обновление копий групп хранения (Storage Group Copies) на пассивном узле

Итак, осталось пройти пару шагов, прежде чем мы сможем назвать процесс восстановления после сбоя успешным. На данный момент репликация в копии групп хранения на пассивном узле приостановлена. На рисунке 2.2 показана база данных почтовых ящиков и путь групп хранения на пассивном узле в моей лабораторной сети (поскольку это лабораторная сеть, я могу хранить все данные на одних и тех же дисках, но этого конечно же не стоит делать в производственном окружении) и как вы видите, она не содержит никаких EDB баз данных или файлов журналов, потому что, как я уже говорил, репликация приостановлена.

Рисунок 2.2: Папки групп хранения все еще пусты, так как они приостановлены

Чтобы возобновить процесс репликации, нам нужно обновить копии групп хранения на пассивном узле. Для этого открываем консоль EMC на пассивном узле, затем находим Server Configuration > Mailbox и выбираем группы хранения, по одной за раз, выбираем опцию «Обновить копии групп хранения» в панели действий. В мастере обновления Update Storage Group Copy (рисунок 2.3) ставим галочки напротив опции «Удалить все существующие файлы журналов по указанному пути», затем жмем «Далее» и «Обновить».

Рисунок 2.3: Обновление копий групп хранения в пассивном узле

Когда соответствующая копия групп хранения была успешно обновлена, репликация будет автоматически возобновлена.

Рисунок 2.4: Все копии групп хранения были обновлены на пассивном узле

Когда мастер завершил выполнение этих шагов для оставшихся приостановленных групп хранения.

Заметка:вы, конечно, можете обновить все копии групп хранения одновременно с помощью команды Update-StorageGroupCopy CMDlet в оболочке Exchange Management Shell (EMS). Как и в большинстве случаев с мастерами EMC, страница завершения мастера обновления Update Storage Group Copy отображает команду и заданные параметры, которые вы можете использовать для выполнения этой задачи. Как показано на рисунке 2.5, база данных и путь группы хранения теперь выглядят гораздо лучше, то есть EDB базы данных и журналы файлов были реплицированы, и теперь у нас есть полноценное работающее решение Clustered Mailbox Server.

Рисунок 2.5: Журналы и EDB файлы теперь реплицируются в соответствующие папки групп хранения на пассивном узле

Теперь мы можем выполнить последнее задание, которым является проверка того, работает ли кластер обхода отказов на пассивном узле как ожидалось.

Тестирование кластера обхода отказов на пассивном узле

Когда дополнительные узлы были добавлены в CMS, а репликация групп хранения была возобновлена, давайте проверим, удастся ли нам переместить CMS на пассивный узел с помощью мастера Manage Clustered Mailbox. Чтобы переместить CMS на пассивный узел, открываем консоль управления Exchange Management Console, затем спускаемся вниз к Server Configuration > Mailbox и жмем Manage Clustered Mailbox Server в панели действий (рисунок 2.6).

Рисунок 2.6: Выбор Manage Clustered Mailbox Server в панели действий

На приветственной странице мастера Manage Clustered Mailbox Server, выбираем первую опцию «Переместить кластерный почтовый сервер на другой узел» (рисунок 2.7), и жмем «Далее».

Рисунок 2.7: Перемещение кластерного почтового сервера на пассивный узел

Теперь жмем «Обзор» и выбираем узел, на который CMS должен быть перемещен, затем вписываем комментарий перемещения (рисунок 2.8) и жмем «Далее».

Рисунок 2.8: Определение целевого узла и введение комментария перемещения

Когда CMS был перемещен на другой узел, жмем «Закончить», чтобы выйти из мастера Manage Clustered Mailbox Server.

Заметка: перемещение CMS на пассивный узел с помощью консоли EMC возможно лишь в том случае, если вы установили Exchange Server 2007 Service Pack 1 на эти узлы. Если вы все еще используете Exchange 2007 RTM версию, вам нужно применить оболочку Exchange Management Shell, а точнее команду Move-ClusteredMailboxServer. Полная команда выглядит следующим образом: Move-ClusteredMailboxServer <CMS name> -TargetMachine: <passive node name> -MoveComment 'note on why the CMS is moved!'

Давайте откроем страницу свойств для CMS в EMC и перейдем по вкладке кластерный почтовый сервер (рисунок 2.9), теперь проверим, что ранее пассивный узел (в данном случае CCR4) теперь активен.

Рисунок 2.9: Второй узел (CCR4) – активный узел

Мы также можем проверить, где теперь находится CMS с помощью администратора кластера, но мне захотелось показать вам одно из замечательных усовершенствований в Exchange 2007 Service Pack 1 J

Отчистка Active Directory и DNS

Итак, мы закончили шаги по восстановлению после форс-мажорных обстоятельств, и теперь все выглядит замечательно. Последним шагом будет отчистка Active directory и DNS путем удаления теперь уже устаревших объектов учетной записи компьютера, узла кластера Windows и DNS записей A records.

Чтобы удалить старые объекты учетной записи компьютера в узле кластера из Active Directory, открываем оболочку MMS пользователей и компьютеров Active Directory, затем выбираем организационные единицы компьютера (Computers organization unit (OU)). Находим соответствующие объекты учтенной записи компьютера, и удаляем их путем правого клика по каждой и выбора опции «Удалить» в контекстном меню (рисунок 2.10).

Рисунок 2.10: Удаление учетных записей компьютера для старого узла кластера

Чтобы удалить устаревшие DNS записи, открываем консоль DNS Management и выбираем соответствующую зону поиска. Находим записи и удаляем их путем правого клика на каждой и выбора опции «Удалить» в контекстном меню (рисунок 2.11).

Рисунок 2.11: Удаление записей DNS A records для старого узла кластера и кластера Windows. Вот и все! Отличные ощущения после преодоления всех шагов по восстановлению CMS после форс-мажорных обстоятельств, не так ли?

Заключение

Так как почтовые системы считаются очень важными в большинстве организаций, многие организации разворачивают резервные почтовые решения, чтобы избежать сбоев. Но даже такие системы как Exchange 2007 Single Copy Cluster (SCC) или Cluster Continuous Replication (CCR) Clustered Mailbox Server (CMS) могут быть утрачены (например, при землетрясениях или прочих природных катаклизмах). Если вы оказались в такой ситуации, крайне важно знать, как восстанавливать системы после таких ситуаций, а это возможно только в том случае, если вы выполнили тестирование процесса восстановления перед катастрофой. В этой статье мы рассмотрели процесс восстановления CMS. Как вы видели по ходу этой статьи, процесс восстановления кластерного сервера Exchange Server 2007 Server был менее сложен, чем процесс восстановления кластеров Exchange Server в предыдущих версиях Exchange Server. Но это вовсе не означает, что вам не нужно тестировать то, как восстанавливать CMS в качестве одной из частей вашего плана восстановления после форс-мажорных обстоятельств.