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

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

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


Авторизация

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

Подписка

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

Статистика

Hits 2083938
9382
Hosts 1617500
2181
Visitors 166548
2652

13

Главная / Статьи / Exchange 2007 / Развертывание многосайтовых CCR кластеров Exchange 2007 – что нужно и чего не нужно делать (часть 4)


Развертывание многосайтовых CCR кластеров Exchange 2007 – что нужно и чего не нужно делать (часть 4)

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

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

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

Введение

В предыдущей части этого цикла статей мы рассматривали стратегии транспортной корзины, а также размещение и настройку свидетеля файлового ресурса.

В этой части мы продолжим с того места, на котором остановились в предыдущей. Мы рассмотрим обход отказа между двумя узлами кластера, и то, как обход отказа между двумя узлами кластера, расположенными в разных центрах данных, влияет на конечных пользователей. И, наконец, мы немного поговорим о стратегиях резервного копирования во время установки многосайтовых кластеров CCR. Это последняя часть данного цикла статей.

Поведение обхода отказа между двумя узлами кластера

Если доступны два голоса, обход отказа сервера CMS на пассивный узел в резервном центре данных произойдет автоматически. Это означает, что в отличие от SCR, не требуется никакого вмешательства и ручной работы в этом процессе. Сначала это может показаться отличной идеей, поскольку потребуется выполнить на один шаг меньше во время обхода отказа сайта. Но уверены ли вы, что вам действительно нужно выполнить обход отказа сервера CMS на резервный центр данных таким образом? Этот вопрос зависит от таких моментов, как количество пользователей, пропускная способность сети между центрами данных, количество баз данных групп хранения/почтовых ящиков. Представьте, что на основном центре данных возникает незапланированный незначительный сбой сети, в результате чего срабатывает процесс автоматического перевода CMS на аварийный центр данных. В худшем случае перевод сервера CMS при отказе займет 30 минут. Помимо всего прочего возникает ситуация, в которой все серверы Exchange HT и CAS, контроллеры домена /серверы глобальных каталогов, а также клиенты Outlook должны теперь взаимодействовать с сервером CMS, который расположен в аварийном центре данных. Если вы не хотите допускать возникновения автоматического обхода отказа сервера CMS в ситуации, когда IP адрес или сетевое имя кластера недоступно, вам нужно приостановить службу кластера на пассивном узле.

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

Поставьте службу кластера на узле аварийного кластера Windows Server 2008 на паузу, откройте консоль управления аварийным кластером > разверните объект кластер (cluster), а затем Узлы (Nodes). Теперь нажмите правой клавишей на пассивном узле и выберите опцию Пауза (Pause) в контекстном меню, как показано на рисунке 1 ниже.

Рисунок 1: Приостановка службы кластера на пассивном узле кластера CCR Рисунок 1: Приостановка службы кластера на пассивном узле кластера CCR

Можно также приостановить кластер с помощью cluster.exe. Для этого воспользуйтесь следующей командой:

CLUSTER.EXE NODE /PAUSE

Рисунок 2: Приостановка пассивного узла кластера

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

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

Вдобавок, если службы ядра кластера не принадлежали пассивному узлу в резервном центре данных, когда мы поставили кластер на этом узле на паузу, необходимо принудительно запустить ресурсы ядра кластера в режим онлайн, прежде чем снова запускать узел кластера после потери активного узла кластера в основном центре данных. Чтобы посмотреть, какому кластеру принадлежат ресурсы ядра кластера, нажмите на кластере под Failover Cluster Management, а затем разверните Cluster Core Resources в средней панели. Здесь вы увидите текущего владельца ресурсов ядра кластера, как показано на рисунке 4. Чтобы в принудительном порядке вывести ресурсы ядра кластера в режим онлайн на пассивном узле, нажмите правой клавишей на IP адресе, назначенном приостановленному узлу, и выберите опцию Вывести эти ресурсы в режим онлайн (Bring this resource online) в контекстном меню.

Рисунок 4: Текущий владелец ресурсов ядра кластера Рисунок 4: Текущий владелец ресурсов ядра кластера

Хотя пассивный узел был поставлен на паузу, когда активный узел вышел из строя, пассивный узел стал текущим владельцем ресурсов кластера/Exchange.

Чтобы вернуть ресурсы в режим онлайн, нажмите правой клавишей на пассивном узле и выберите опцию Возобновить (Resume) в контекстном меню (рисунок 5).

Рисунок 5: Возобновление работы узла кластера Рисунок 5: Возобновление работы узла кластера

Теперь откройте оболочку Exchange Management Shell и введите следующую команду, чтобы включить CMS на пассивном узле:

Start-ClusteredMailboxServer

Ресурсы кластера и Exchange теперь будут возвращены в режим онлайн, и клиенты Outlook смогут подключиться к почтовому ящику.

Рисунок 6: CMS в режиме онлайн на узле кластера в аварийном центре данных Рисунок 6: CMS в режиме онлайн на узле кластера в аварийном центре данных

Как обход отказа влияет на пользователей Outlook 2007

Итак, теперь, когда мы настроили свой многосайтовый CCR кластер в соответствии с рекомендациями к лучшим методикам, давайте попробуем сымитировать ситуацию обхода отказа сервера CMS на аварийный центр данных. Давайте посмотрим, как это влияет на пользователей Outlook в организации. На рисунке 7 ниже у нас есть снимок клиента Outlook 2007, подключенного (в режиме кэша) к почтовому ящику, хранящемуся на нашем сервере CMS, который в настоящее время находится в режиме онлайн на узле кластера основного центра данных.

Рисунок 7: Outlook клиент подключен к почтовому ящику, хранящемуся на сервере CMS, который в настоящее время находится в режиме онлайн в основном центре данных Figure 7: Outlook клиент подключен к почтовому ящику, хранящемуся на сервере CMS, который в настоящее время находится в режиме онлайн на узле основного центра данных
Давайте переместим сервер CMS на пассивный узел кластера в резервном центре данных. Для этого можно воспользоваться следующей командой:

Move-ClusteredMailboxServer -TargetMachine -MoveComment Test

Рисунок 8: Перемещение сервера CMS на пассивный узел кластера в резервном центре данных

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

Рисунок 9: Подключение к Microsoft Exchange утеряно Рисунок 9: Подключение к Microsoft Exchange утеряно

Когда CMS возвращен в режим онлайн, запись DNS необходимо обновить IP адресом, который был назначен серверу CMS в подсети резервного центра данных. По умолчанию эта запись имеет значение TTL в 20 минут. Но как вы видели ранее в этой статье, мы изменили TTL значение записи DNS на 5 минут. Однако это не означает, что Outlook возобновит работу после пяти минут. Слияние клиента Outlook составляет (10 минут на издание обновления, поскольку многосайтовый кластер Windows 2008 задерживает обновление записи на сервере DNS на 10 минут) + (задержка репликации сервера DNS) + (оставшееся или полное время в КЭШе преобразователя на истечение TTL), поэтому следует ожидать от 10 до 30 минут (последнее подходит для больших или медленных сред с большим количеством DNS серверов).

Хорошая новость заключается в том, что когда Outlook 2003/2007 работает в режиме кэширования, пользователь может продолжить работу и может даже не заметить, что Outlook работает в автономном режиме. Также конечным пользователям не придется перезапускать клиента Outlook, он автоматически восстановит подключение.

Рисунок 10: Подключение к Microsoft Exchange было восстановлено Рисунок 10: Подключение к Microsoft Exchange было восстановлено
Как большинство из вас знает, Outlook 2007 использует службу доступности/автообнаружения (availability/autodiscover). После обхода отказа клиент Outlook 2007 просто выберет CAS сервер в резервном центре данных для службы availability/autodiscover.

На рисунке 11 видно, что Outlook не может подключиться к двум серверам CAS в основном центре данных и переходит к серверу CAS в резервном центре данных, когда мы тестируем Autodiscover.

Рисунок 11: Тестирование функции Autodiscover для проверки выбора сервера CAS в резервном центре данных Рисунок 11: Тестирование функции Autodiscover для проверки выбора сервера CAS в резервном центре данных

Если вы используете Outlook 2003, то OAB и поиски free/busy полагаются на ваши системные папки в базе данных публичной папки. Если у вас установлены клиенты Outlook 2003, убедитесь, что у вас есть копия иерархии публичной папки (PF) на резервном центре данных.

Выполнение резервного копирования на резервном центре данных

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

Заключение

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

БлагодарностьЯ бы хотел поблагодарить Тима Макмайкла (Профессионала службы поддержки почты в MSFT) и Грега Тэйлора (программного менеджера в программе Exchange MCM/MCA) за отличную информацию, которую они предоставили во время написания этой статьи.

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





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

Автор: Генрик Валзер (Henrik Walther)
Генрик Валзер (Henrik Walther) является Microsoft Exchange MVP и работает в качестве Старшего Технического Консультанта в Interprise, Золотом Партнере Microsoft, расположенном в Дании. Вы можете посетить его web-сайт по адресу: www.exchange-faq.dk (на датском).
Эта статья переведена и опубликована с разрешения www.msexchange.org

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





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