На главную страницу
 
  Главная 
  Новости 
  Статьи  RSS
  Программное обеспечение 
  Форум 
  Опросы 
  Полезные ссылки 
MSExchange.ru ISADocs.ru WinSecurity.ru NetDocs.ru

Exchange 5.5
Exchange 2000
Exchange 2003
Exchange 2007
Общее
Exchange 2010

Поиск по сайту


Авторизация

Запомнить меня на этом компьютере
  Забыли свой пароль?
  Регистрация

Подписка

Изменение параметров

Статистика

Hits 2085403
10847
Hosts 1617598
2305
Visitors 166694
2814

8

Главная / Статьи / Exchange 2007 / Тестирование SCR в производственной среде (часть 2)


Тестирование SCR в производственной среде (часть 2)

Версия для печати Версия для печати

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.

Если вы хотите прочитать первую часть этого цикла статей, перейдите по ссылке Тестирование SCR в производственной среде (часть 1).

Введение

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

Шаг 3 ‘ остановка CMS

Далее нам нужно остановить CMS, который в свою очередь демонтирует все базы данных на CMS. Это также осуществляется через оболочку Exchange Management Shell с помощью команды Stop-ClusteredMailboxServer. Для успешного использования этой команды нужно ввести имя сервера CMS, который вы хотите остановить, а также нужно указать причину остановки в параметре ‘StopReason. То, что вы укажите в параметре StopReason, затем будет добавлено в журнал регистрации событий под кодом ID 105, как показано на рисунке 2.

Рисунок 2: CMS Event ID 105 Рисунок 2: CMS Event ID 105

Полная команда, используемая для остановки сервера CMS, может выглядеть, как показано в примере, где имя сервера CMS было E2K7:

Stop-ClusteredMailboxServer E2K7 ‘StopReason ‘SCR failover test’ ‘Confirm:$false

В результате выполнения этой команды вы получаете данные о том, что сервер CMS теперь работает в автономном режиме, как показано на рисунке 3.

Рисунок 3: Остановка сервера CMS Рисунок 3: Остановка сервера CMS

Также обратите внимание, что я использовал параметр ‘Confirm и задал ему значение false, в результате чего вопрос подтверждения ‘Вы уверены, что хотите продолжить (Are you sure)?’ задаваться не будет, и вам не придется давать свое подтверждение. Затем нужно проверить через консоль Exchange Management Console или оболочку Exchange Management Shell, что все базы данных были демонтированы в результате выполнения команды Stop-ClusteredMailboxServer. Лично я считаю полезным выполнение программы Cluster Administrator (если вы используете Windows 2003) или программы Failover Cluster Management (в случае использования Windows 2008) для проверки того, что все ресурсы кластера CMS находятся в автономном режиме после выполнения команды. На рисунке 4 показана программа Failover Cluster Management в действии на Windows 2008.

Рисунок 4: Ресурсы CMS в автономном режиме Рисунок 4: Ресурсы CMS в автономном режиме

Шаг 4 ‘ отключение среды CCR

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

Шаг 5 ‘ восстановление групп хранения

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

Для выполнения процесса перемещения вам понадобится команда Restore-StorageGroupCopy. Эта команда является ключевым компонентом в активации копии групп хранения на аварийном кластере SCR. Двумя основными параметрами являются параметры ‘StandbyMachine и ‘Force. В параметре ‘StandbyMachine указывается имя целевого SCR сервера, на котором будет размещен сервер CMS, а параметр ‘Force используется в тех ситуациях, когда источник SCR недоступен, например, когда среда CCR была утеряна. Это может быть либо полный отказ обоих узлов среды CCR, либо потеря центра данных, на котором располагалась среда CCR. Конечно, в моем примерном сценарии среда CCR недоступна, так как она была отключена, поэтому я использую параметр ‘Force. Если вы не укажите параметр ‘Force, и источник SCR будет недоступен, вы получите ошибку, говорящую о том, что процесс восстановления не смог проверить условия монтирования исходной базы данных.

Примечание: Потеря данных предполагается, если используете параметр ‘Force, как показано на рисунке 5.

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

Restore-StorageGroupCopy ‘Identity ‘E2K7\First Storage Group’ ‘StandbyMachine SCR ‘Force

Restore-StorageGroupCopy ‘Identity ‘E2K7\Second Storage Group’ ‘StandbyMachine SCR ‘Force

Результаты выполнения этих команд показаны на рисунке 5. Как я уже говорил, будут предупреждения о потере данных при использовании параметра ‘Force. Поскольку это тестовый обход отказа, в котором среда CCR была безопасно отключена, мы не утратим никаких данных.

Рисунок 5: Восстановление копий групп хранения Рисунок 5: Восстановление копий групп хранения

Если у вас много групп хранения, которые нужно восстановить, вы можете воспользоваться сценарием GetScrSources.ps1, который поставляется в комплекте с Exchange 2007 Service Pack 1. Вы найдете этот сценарий в папке с остальными сценариями в \Program Files\Microsoft\Exchange Server\Scripts. Если вы просто выполнение отдельно этот сценарий, вы получите результаты, похожие на те, что показаны на рисунке 6.

Рисунок 6: Результаты стандартного выполнения сценария GetScrSources Рисунок 6: Результаты стандартного выполнения сценария GetScrSources

Можно выполнить этот сценарий и обработать результаты в команде Restore-StorageGroupCopy, не забыв включить параметры -StandbyMachine и -Force. Пример, который я использовал в своей тестовой среде, был следующим:

GetScrSources | Restore-StorageGroupCopy ‘StandbyMachine SCR ‘Force

На рисунке 7 приведены результаты использования этой команды в моей среде. Как вы, вероятно, подозревали, результаты получились одинаковыми, поэтому данный сценарий отлично подходит для тех, у кого на самом деле есть много групп хранения, которые нужно восстановить.

Рисунок 7: Восстановление нескольких групп хранения с помощью GetScrSources Рисунок 7: Восстановление нескольких групп хранения с помощью GetScrSources

Шаг 6 ‘ изменение DNS

Прежде чем восстанавливать сервер CMS на аварийном кластере, нужно выполнить два очень важных шага. Первый шаг включает внесение изменений в DNS, если ваша среда работает под управлением Windows 2008. В этом случае вам нужно удалить существующие записи DNS для CMS. Для этого просто воспользуйтесь оснасткой DNS Management и удалите запись DNS A, которая соответствует серверу CMS, как показано на рисунке 8. Помните, что это подходит только для Windows 2008; не нужно этого делать для Windows 2003. Если вы не сделаете этот шаг для Windows 2008, вы будете получать ошибки при попытке восстановления CMS, говорящие о невозможности подключения к Internet Information Server (IIS) на целевом сервере SCR.

Рисунок 8: Удаление CMS DNS записи Рисунок 8: Удаление CMS DNS записи

Когда вы удалили запись DNS A для CMS, убедитесь что DNS не только обновлен для всех контроллеров домена, но и что вы отчистили кэш на своем резервном кластере SCR с помощью команды ipconfig /flushdns.

Заключение

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

Если вы хотите прочитать первую часть этого цикла статей, перейдите по ссылке Тестирование SCR в производственной среде (часть 1).





Рейтинг:  
0.0 (голосов 2)  
 1   2   3   4   5    

Автор: Нейл Хобсон (Neil Hobson)

Нейл является основным консультантом в Silverslands (http://www.silversands.co.uk), Золотом партнере Microsoft в Великобритании и отвечает за разработку, применение и поддержку приложений для многих крупных клиентов по всей Европе. В IT отрасли он трудится с 1987 года и специализируется на отправке сообщений с 1995. Он начинал работать еще с Exchange 4.0. Он также обладает званием Exchange MVP и уделяет некоторую часть своего личного времени на помощь различным пользователям Exchange, ведет блоги, посвященные Exchange. Эти блоги вы можете найти по адресу http://www.msexchangeblog.com.

С Нейлом можно связаться по адресу [email protected].

Эта статья переведена и опубликована с разрешения www.msexchange.org

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.





Работает на «Битрикс: Управление сайтом»
Работает на «Битрикс:
 Управление сайтом»
© MSExchange.ru, 2005-2010