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

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

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


Авторизация

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

Подписка

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

Статистика

Hits 1848469
2723
Hosts 1597377
196
Visitors 127051
201

14

Главная / Статьи / Exchange 2007 / Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 3)


Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 3)

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

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

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

Введение

Это третья часть серии статей, посвященной проекту перехода с существующей среды Exchange 2003 на новую среду Exchange 2007. Если вы читали первую и вторую части этой серии статей, вы знаете, что до настоящего времени мы рассмотрели установку первых серверов Exchange 2007, сочетание Hub Transport и Client Access Server, в среде Exchange 2003. Я также рассказал о начальных шагах подготовки среды Clustered Continuous Replication (CCR). Здесь в третьей части я продолжу рассказывать об установке среды CCR.

Конфигурация кластера

Теперь, когда кластер создан, я смог его настроить для работы в производстве. Первым элементом настройки было использование сети кластера. Для этого в иерархии Администрирования кластера я перешел к объекту Сети, расположенному в объекте Конфигурация кластера. Вызвав свойства Частной сети, я проверил, что эта сеть была задана для Только взаимодействия внутреннего кластера (Internal cluster communications only (private network)), как показано на рисунке 6. Публичная сеть была настроена для Всех взаимодействий (All communications (mixed network)).

Рисунок 6: Настройка частной сети Рисунок 6: Настройка частной сети

Далее, нужно было убедиться, что сети были расположены в правильном порядке в Администраторе кластера. Для этого правой клавишей нажимаем на названии кластера, CLUSTER1, справа вверху иерархии в администраторе кластера выбираем Свойства из контекстного меню. В результате открывается окно свойств, в котором переходим в закладку Приоритеты сетей (Network Priority), где проверяем, чтобы частная сеть располагалась вверху списка, как показано на рисунке 7.

Рисунок 7: Настройка приоритетов кластерных сетей Рисунок 7: Настройка приоритетов кластерных сетей

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

cluster.exe CLUSTER1 /priv HeartBeatLostInterfaceTicks=10:DWORD

cluster.exe CLUSTER1 /priv HeartBeatLostNodeTicks=10:DWORD

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

Конфигурация общего каталога построения (File Share Witness)

На данном этапе я еще не закончил с настройкой серверов Hub Transport, поскольку на этих серверах нужно было разместить общий каталог построения (File Share Witness). Решение об использовании серверов Hub Transport для размещения этого каталога было принято на основании рекомендаций компании Microsoft. Конечно можно использовать любой сервер, способный содержать общий каталог, но поскольку по понятным причинам серверы Hub Transport попадают под управление администраторов Exchange в большинстве организаций, это делает их лучшим вариантом для выбора.

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

  1. В корне диска D: я создал папку под названием MNS_FSW_DIR_EX2007. Такое название данной папки также было выбрано по рекомендациям компании Microsoft к использованию названия MNS_FSW_DIR_, вслед за которым должно идти название CMS. В этом случае MNS обозначает Majority Node Set, FSW - File Share Witness, а DIR указывает на то, что это имя директории или папки. Можно создать эту папку где угодно, но, как я уже сказал, я создал ее в корне диска D: в данном примере. В будущем, я буду создавать эту папку где-нибудь внутри главной папки, в которую установлен Exchange, поскольку она является частью структуры установки Exchange.
  2. После этого, к папке, созданной в первом шаге, был дан общий доступ с помощью общего имени MNS_FSW_EX2007. Этот формат общего имени является форматом, рекомендуемым компанией Microsoft. Учетной записи службы кластера также был дан полный доступ к этому новому ресурсу. Для этого я использовал следующую команду: net share mns_fsw_ex2007 = d:\mns_fsw_dir_ex2007 /grant:neilhobson\excluster,full
  3. Дополнительные разрешения для ресурса были даны встроенным администраторам и учетной записи службы кластера с помощью следующей команды: cacls d:\mns_fsw_dir_ex2007 /g builtin\administrators:f neilhobson\excluster:f
  4. И наконец, ресурс Majority Node Set был настроен путем выполнения следующей команды в утилите cluster.exe: Cluster cluster1 res ‘Majority Node Set’ /priv MNSFileShare=\\HUBCAS1\MNS_FSW_EX2007

Обратите внимание, что в шаге 4 путь UNC включает имя сервера HUBCAS1. Некоторое время назад компания Microsoft изменила свои рекомендации к восстановлению потерянных серверов, содержащих общий каталог построения. Старый способ включал использование DNS CNAME записи, а новый способ использует метод cluster ‘forcequorum‘. Причины этих изменений описаны на блоге команды Exchange здесь, и я рекомендую прочитать эту статью.

Установка CMS

Теперь, когда кластер был установлен и настроен корректно, равно как и функция общего каталога построения, был создан сам CMS путем установки роли Active Clustered Mailbox сервера Exchange 2007 SP1 на узел кластера под названием NODE1. Для этого мы запустили программу Exchange 2007 setup.exe в обычном режиме и следовали указаниям мастера установки. Необходимо было убедиться, что выполнялась выборочная установка Exchange 2007, поскольку обычная установка не позволяет устанавливать CMS. На странице Роли сервера мастера установки была выбрана опция Active Clustered Mailbox, как показано на рисунке 8.

Рисунок 8: Установка роли Active Clustered Mailbox Рисунок 8: Установка роли Active Clustered Mailbox

На следующей странице Настройки кластера опция Тип кластера (Cluster type) была установлена на Cluster Continuous Replication. Было введено имя CMS в виде EX2007, которое, если вы помните, является именем сервера Exchange, используемым для подключения клиентов Outlook. Был выбран подходящий IP адрес для CMS, это был IP адрес, отличный от того, который является действительным IP адресом кластера, выбранным ранее.

CCR и публичные папки

Следует отметить, что во время установки CMS я выбрал опцию создания базы данных публичных папок в среде CCR. Хотя среда CCR может содержать публичные папки, есть некоторые моменты, которые нужно понимать. Эти моменты описаны в статье Planning for Cluster Continuous Replication, в разделе под названием Cluster Continuous Replication and Public Folder Databases, и я рекомендовал бы вам внимательно ознакомиться с этим разделом. Причина такого подхода к созданию базы данных публичных папок в этой конфигурации заключается в том, что эта база данных в соответствии с требованиями среды должна быть постоянно доступной, равно как и база данных почтовых ящиков.

Однако, базы данных публичных папок имеют собственные механизмы репликации данных, а модели этой репликации и репликации среды CCR в определенном смысле несовместимы. Поскольку я установил CCR среду в существующую среду Exchange 2003, там теперь существовало две базы данных публичных папок, что означало, что репликация публичных папок была включена вдобавок к модели репликации CCR. Компания Microsoft четко говорит, что в таких ситуациях, если имеет место незапланированный выход из строя среды CCR, база данных публичной папки не сможет быть монтирована на новый активный узел до тех пор, пока он не сможет связаться с оригинальным активным узлом. Обратите внимание на словосочетание незапланированный выход из строя. Другими словами, во время обычных операций проблем не возникает.

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

Завершение установки CMS

Когда CMS был установлен, все узлы должны быть перезагружены в соответствии с правилами, приведенными в установке Exchange 2007. Когда активный узел был перезагружен и снова полностью запустился, была выполнена установка пассивного узла под названием NODE2. Этот процесс гораздо проще, чем установка активного узла, поскольку единственным действительным решением, которое необходимо принять, был выбор роли Passive Clustered Mailbox, опция для которого стоит прямо под опцией роли Active Clustered Mailbox, рисунок 8. И снова программа установки предложила перезагрузить этот сервер, прежде чем использовать его в производстве, что я, собственно, и сделал.

После перезагрузки NODE2 я применил одинаковые обновления на обоих узлах по той простой причине, что я просто пренебрег установкой этих обновлений во время установки самого сервера! Это необязательно плохо, поскольку новые обновления будут выпускаться в будущем, и поэтому умение их применить в производственной среде является обязательным требованием. Процесс применения этих обновлений довольно прост, и вот, что я сделал. Я убедился, что все ресурсы были перемещены на узел кластера, который не обновлялся, после чего я установил обновления на пассивный узел. Когда я закончил эту процедуру, я снова переместил ресурсы с предыдущего узла на обновленный, и применил обновления на том узле, который теперь был пассивными. Не забывайте использовать команду Move-ClusteredMailboxServer для перемещения CMS между узлами кластера. В моем случае команда была следующей:

Move-ClusteredMailboxServer EX2007 ‘TargetMachine NODE2 ‘MoveReason ‘Apply Update Rollup 3’

Заключение

На этом мы закончим третью часть, в которой у нас уже есть работающая среда CCR наряду с нашей комбинацией серверов Hub Transport и Client Access Servers, сосуществующих со средой Exchange 2003. Очень важно уделить достаточно времени на корректную настройку кластеров, прежде чем устанавливать роль почтового сервера Exchange 2007 на узлы кластера. В четвертой части этой серии мы сконцентрируемся на установке роли сервера Edge Transport.

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





Рейтинг:  
2.5 (голосов 12)  
 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