В моей другой статье, я показывал, как можно восстанавливать сервер Exchange Server 2007 с одной или несколькими ролями, установленными на него, используя переключатель RecoverServer. Но что хорошего в том, что вы вдруг окажетесь в ситуации, когда все узлы были потеряны, и вам нужно восстанавливать весь кластер? Согласен, ничего, так как этот переключатель нельзя использовать для восстановления кластерных почтовых серверов на базе Exchange Server 2007 Single Copy Cluster (SCC) или Cluster Continuous Replication (CCR).
В Exchange Server 2003 мы могли восстанавливать не кластерные серверы Exchange 2003, используя настройку переключателя DisasterRecovery (метод, о котором я рассказывал здесь), так же, как мы можем восстанавливать не кластерные серверы Exchange 2007 с помощью переключателя RecoverServer. Но, как и в случае с RecoverServer, переключатель DisasterRecovery не может использоваться для восстановления кластерных серверов Exchange 2003. Вместо этого мы часто восстанавливаем потерянный сервер Clustered Mailbox Server (или Exchange Virtual Server, как он назывался в Exchange 2003), используя кластер Standby.
Кластер Standby – это кластер, который является зеркалом кластера корпоративного окружения производственной сети. Он настраивается с той же ОС, версией Exchange Server, с тем же пакетом обновления, обновлением Windows и патчами. Вдобавок, конфигурация разделов (буквы приводов) соответствовали этим элементам производственного кластера. Единственной разницей было то, что виртуальный сервер Exchange еще не был создан на кластере Standby. Имена NetBIOS, IP адреса не должны были соответствовать этим элементам в производственном кластере, но вам нужно использовать туже учетную запись служб кластера, созданную в Active Directory. Кластеры Exchange 2003 Standby можно было также использовать для способности сайта к восстановлению, и они на самом деле были хорошей альтернативой дорогим и часто сложным решениям Geo-Clustering, поскольку можно было восстанавливать производственные кластеры, используя Standby Cluster на другом сайте. Но эта серия статей не о том, как восстанавливать кластеры Exchange Server 2003 с помощью Standby Cluster, поэтому я не буду вдаваться в подробности этой операции. Для дополнительной информации я советую вам прочесть этот раздел в руководстве Exchange 2003 Disaster Recovery Operations на Microsoft TechNet.
Заметка:В Exchange Server 2003 было также возможно восстанавливать сервер после сбоя, когда все узлы были потеряны. Это делалось восстановлением полной резервной копии компьютера или с помощью записей информации кластера, хотя последнее было довольно сложной операцией.
Вы готовы выполнить процедуру восстановления после сбоя, когда сервер Exchange Server 2007 Clustered Mailbox Server (CMS) работает в автономном режиме, так как вы утратили все узлы своего кластера Windows? Если вы не пытались проделать необходимые для восстановления CMS шаги в тестовой сети, думаю, вы не готовы! Как я покажу вам в этой статье, благодаря тому, что у нас есть переключатель RecoverCMS, процесс восстановления сервера Exchange 2007 Clustered Mailbox Server даже проще, чем был в случае с Exchange Server 2003, но, как и в прочих случаях, вам нужно протестировать эту процедуру, как часть вашего плана по восстановлению после сбоев.
Итак мой сервер Clustered Mailbox Server слетел, что теперь?
Все зависит от того, имеется ли у вас в наличии Standby Cluster. Standby Cluster должен быть кластером Windows с той же конфигурацией разделов (буквами приводов и размерами LUN), как и у потерянного. Как и в случае с Exchange Server 2003, имена NetBIOS и IP адреса могут отличаться от тех, которые были в узлах утраченного кластера, так как Exchange Setup достаточно умен, чтобы определить эту разницу, когда вы запускаете Setup в /RecoverCMS. Даже название виртуального кластера Windows может отличаться.
Для подробного описания процесса настройки новых узлов кластера и формирования кластера Windows, обратитесь к моей предыдущей серии статей, которая дает пошаговые инструкции того, как разворачивать Single Copy Cluster (SCC) или Cluster Continuous Replication Cluster (CCR) кластерные почтовые серверы в вашем почтовом окружении:
- Installing a Two Node Exchange Server 2007 Single Copy Cluster (SCC) in a Virtual Server Test Environment - Part 1: Preparing the virtual environment
- Installing, Configuring and Testing an Exchange 2007 Cluster Continuous Replication (CCR) Based Mailbox Server (Part 1)
Также не забудьте настроить новый кластер Windows Cluster для ссылки на Majority Node Set File ресурс (сервер Hub Transport, на котором был создан ресурс при установке оригинального кластера). Убедитесь, что вы установили все необходимые компоненты и патчи Windows на всех узлах в новом кластере Windows.
Установка роли Passive Mailbox Server на одном из новых узлов
Прежде чем мы сможем восстановить сервер Clustered Mailbox Server, нам необходимо сначала установить роль Passive Mailbox Server на одном из новых узлов. Как большинство из вас знает, это можно сделать, используя мастера установки Exchange Setup или интерфейс командной строки. В этой статье мы будем делать это с помощью мастера Exchange Setup.
Входим в первый узел нового кластера Windows, затем запускаем мастера Exchange Setup, выполнив Setup.exe в корне диска DVD или папки, в которой расположены файлы Exchange Server 2007. Когда появляется окно меню установки (так же известное как программа самозагрузки), нажимаем «установить Microsoft Exchange Server 2007». На вводной странице, показанной на рисунке 1.1, жмем Далее.
Рисунок 1.1: Вводная страница мастера установки Exchange 2007 Setup
Принимаем условия лицензионного соглашения и нажимаем Далее, затем определяем, хотим ли мы получать отчет об ошибках или нет, и жмем Далее. Теперь выбираем «Выборочную установку Exchange Server» и жмем далее (рисунок 1.2).
Рисунок 1.2: Выборочная установка сервера Exchange
Отмечаем галочкой роль Passive Clustered Mailbox и жмем Далее, как показано на рисунке 1.3.
Рисунок 1.3: Выбор установки роли Passive Clustered Mailbox
После того как проверка готовности завершена, жмем установить, чтобы установить роль Passive Clustered Mailbox. Когда процесс установки завершен, жмем Закончить, чтобы завершить работу мастера Exchange Setup.
Восстановление сервера Clustered Mailbox Server с помощью переключателя RecoverCMS Switch
Теперь, когда у нас установлена роль Passive Clustered Mailbox на первом узле нового кластера Windows, мы можем начать сам процесс восстановления CMS. В этой статье я буду восстанавливать CMS, который использует технологию кластеров CCR, но шаги восстановления более или менее сходны и для восстановления SCC CMS. Единственная разница заключается в том, что SCC использует общие разделы. Вдобавок решение на базе SCC кластера часто имеет более двух узлов (2 – максимальное количество узлов для кластеров CCR).
В том узле, на который вы только что установили роль Passive Clustered Mailbox, откройте окно ввода команды и затем измените папку корзины (Bin folder) в установочной папке Exchange (по умолчанию C:\Program Files\Microsoft\Exchange Server). Здесь введите следующую команду и нажмите Enter:
Setup.com /RecoverCMS /CMSName:EXCHMBX01 /CMSIPAddress:10.10.1.200
Где CMSName – это имя вашего оригинального кластерного почтового сервера (имя, к которому подключаются клиенты Outlook во внутренней корпоративной сети), а CMSIPAddress – это назначенный ему IP адрес.
Теперь Exchange Setup выполнит требуемые предустановочные шаги, а затем начнет процесс восстановления CMS, извлекая информацию из Active Directory (рисунок 1.4).
Рисунок 1.4: Восстановление сервера Clustered Mailbox Server с помощью RecoverCMS
Как видно на рисунке 1.5 ниже, CMS был заново создан с помощью информации и параметров конфигурации, хранящихся в Active Directory. Также обратите внимание на то, что группы хранения (Storage groups) соответствующих баз данных работают в автономном режиме (рисунок 1.6), и что репликация групп хранения находится в режиме ожидания. Причина тому кроется в том, что вы, возможно, захотите или вам понадобится восстановить базы данных после восстановления самого CMS.
Рисунок 1.5: CMS только частично в режиме онлайн после восстановления
Рисунок 1.6: Все группы хранения в режиме ожидания, и все базы данных демонтированы после восстановления
Теперь мы восстановили сам сервер CMS и можем перейти к следующему заданию, которым будет восстановление всех утраченных баз данных.
Восстановление баз данных почтовых ящиков из резервной копии
В зависимости от того, использует ли сервер CMS, который вы восстанавливаете, решение на базе Directed Attached Storage (DAS) или Storage Аrea Network (SAN), а также в зависимости от того, утратили ли вы только CMS или CMS и все связанные с ним базы данных и журналы регистрации, хранящиеся на DAS или SAN, вам, возможно, понадобится восстанавливать эти базы данных путем извлечения их из самых последних резервных копий.
В этой статье мы предположим, что базы данных тоже были утрачены. Мы также предположим, что для создания резервных копий этих баз данных использовался Windows Server 2003 Backup. Вдобавок, мы будем восстанавливать базы данных из .bkf, что очень схоже с процессом восстановления на базе ленты (tape based restores).
На сервере CMS, на котором базы данных почтовых ящиков еще не были смонтированы, не будет существовать никаких EDB баз данных или журналов событий в базе данных Mailbox и маршрутах групп хранения, а это означает, что мы можем сразу же приступать к восстановлению. Но если вы, по каким-то причинам, пытались смонтировать базы данных почтовых ящиков, вам нужно убедиться, что вы активировали опцию 'Эту базу данных можно перезаписать при восстановлении' во вкладке «Общие» на странице свойств для каждой базы данных почтовых ящиков в консоли Exchange Management Console (EMC), как показано на рисунке 1.7.
Рисунок 1.7: Выбор разрешения перезаписи базы данных при восстановлении
Во вкладке «Активные» откройте Windows Server 2003 Backup, нажав Пуск > Запустить и введите NTBackup, после этого нажмите Enter. Выберите «дополнительные настройки» (Advanced Mode) и затем перейдите по вкладке Восстановление и управление данными (Restore and Manage Media), как показано на рисунке 1.8.
Рисунок 1.8: Восстановление базы данных из резервной копии
В меню выберите Инструменты (Tools) > Каталог файлов резервных копий. Выберите .bkf, который содержит резервные копии баз данных почтовых ящиков и затем нажмите Открыть > OK (рисунок 1.9).
Рисунок 1.9: Открытие .bkf, содержащего базы данных почтовых ящиков, которые нужно восстановить
Теперь отмечаем галочкой группы хранения, содержащие базы данных, которые вы хотите восстановить (рисунок 1.10).
Рисунок 1.10: Выбор баз данных, которые нужно восстановить
Мы готовы восстановить базы данных почтовых ящиков, поэтому жмем «Начать восстановление» (Start Restore). В появившемся окне проверяем, что имя CMS введено в поле Restore To:, затем определяем временное место расположения журналов и патчей. Если вам не нужно выполнять инкрементное или дифференциальное восстановление, убедитесь, что поставили галочку напротив строки Last Restore Set (после завершения восстановления начнется воспроизведение файла журнала), как сделал я на рисунке 1.11.
Рисунок 1.11: Определение сервера Mailbox Server и временного хранилища для файлов журнала и патчей
Жмем OK, и процесс восстановления начнется (рисунок 1.12).
Рисунок 1.12: Базы данных восстанавливаются
Когда процесс восстановления завершился (надеюсь успешно!) мы можем смонтировать базы данных почтовых ящиков.
Для этого открываем EMC и выбираем соответственные базы данных почтовых ящиков (по одной за раз) и жмем «Смонтировать базу данных почтового ящика» (Mount Mailbox Database) (рисунок 1.13).
Рисунок 1.13: Монтирование баз данных
Заметка:Вы можете также установить автоматическое монтирование баз данных после завершения восстановления, отметив галочкой поле Mount Database After Restore, но я предпочитаю делать это вручную.
Теперь все ресурсы в консоли Cluster Administrator в режиме онлайн (рисунок 1.14), и мы можем перейти к следующему заданию, которым будет установка роли Passive Mailbox Server на все дополнительные узлы (в этом случае второй и последний узел, так как мы имеем дело с CCR кластером).
Рисунок 1.14: Все ресурсы консоли администратора кластера (Cluster Administrator Console) в режиме онлайн
На этом мы закончим первую часть серии статей, посвященных тому, как устанавливать роль пассивного почтового сервера (passive mailbox server) на первом узле, а также восстанавливать утраченный CMS и базы данных. В следующей части я расскажу о том, как устанавливать роль Passive Mailbox Server на дополнительные узлы, обновлять копии групп хранения, возобновлять репликацию, тестировать обход отказа кластера, и, наконец, я объясню, как удалять устаревшие объекты учетных записей компьютера и A-записи Active Directory и DNS.
В предыдущей статье этой серии из двух частей о восстановлении потерянного сервера 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 в качестве одной из частей вашего плана восстановления после форс-мажорных обстоятельств.