Microsoft Exchange Server 2007. Переходим на кластер::Журнал СА 7.2008

СЕРГЕЙ ЛОПУТНЕВ, ДМИТРИЙ ИЛЬИН

Microsoft Exchange Server 2007. Переходим на кластер

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

Для начала давайте вспомним, а для тех, кто не успел по каким-либо причинам прочитать предыдущую статью (см. №2 за 2008 г.), опишем наше окружение на том моменте, где мы остановились в предыдущей статье. Мы описывали установку и первоначальную настройку Exchange Server 2007 с ролями – Client Access, Hub Transport, Mailbox Server. И на момент завершения первой статьи у нас была построена почтовая подсистема, изображенная на рис. 1.

Рисунок 1. Состояние почтовой системы до развертывания кластера

Сегодня речь пойдет об отделении роли Mailbox Server от Hub Transport и Client Access и построении кластера высокой доступности. Это позволит нам увеличить надежность и бесперебойность работы почтовой подсистемы, а также уменьшить нагрузку на сервер Exchange. Конфигурации сервера, на котором были подняты указанные выше роли, для работы 400 почтовых пользователей было ещё достаточно, но уже не оставалось запаса производительности для обеспечения потребностей предприятия в условиях постоянного увеличения количества пользователей. Поэтому было принято решение о разделении указанных выше ролей (подробнее о ролях Exchange можно прочитать в предыдущей статье или по адресу http://technet.microsoft.com/en-us/library/bb124935.aspx) и создании почтового сервера высокой доступности с ролью Mailbox.

Так все-таки что же такое кластер и для чего он нужен? Кластер – это два или более компьютера, объединенных с целью выполнения определенной задачи и используется как один логический компьютерный ресурс.

За более подробным описанием лучше всего обратиться к Wikipedia – http://ru.wikipedia.org/wiki/Кластер_(группа_компьютеров).

Отметим лишь, что наша задача направлена на построение кластера высокой доступности – High Availability.

Выбор

На момент возникновения вопроса о создании сервера Exchange с высокой доступностью мы имели возможность выбрать один из вариантов реализации перечисленных ниже.

Примечание: данные реализации относятся и доступны только в Microsoft Exchange Server 2007.

Local continuous replication (LCR) – локальная непрерывная репликация

Это решение, построенное на одном сервере, с двумя дисковыми массивами. Оно позволяет быстрое переключение на резервную копию данных в случае выхода из строя основного дискового массива, на котором хранятся данные. Приблизительная схема работы приведена на рис. 2.

Рисунок 2. Локальная непрерывная репликация

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

Плюсы: простая и дешевая реализация.
Минусы: единая точка отказа – операционная система или сервисы Microsoft Exchange, хранилище данных. При отказе последнего требуется ручное переключение на исправный источник данных.

Подробнее о LCR – http://technet.microsoft.com/en-us/library/bb125195.aspx.

Single copy clusters (SCC) – кластер единой копии

Этот вариант дороже, чем предыдущий, так как требует покупки минимум одного дополнительного сервера, а в случае, если все роли до этого были на одном сервере, то двух серверов. Также требует наличия дорогостоящего специального хранилища данных SAN. Схема этого варианта приведена на рис. 3.

Плюсы: непрерывность работы сервера с почтовой ролью – автоматическое переключение при отказе одной из нод.
Минусы: специальные требования к хранилищу данных; единая точка отказа – хранилище данных.

Рисунок 3. Кластер единой копии

Подробнее о SCC – http://technet.microsoft.com/en-us/library/bb125217.aspx.

Cluster continuous replication (CCR) – кластер непрерывной репликации

Для его реализации необходимо, как минимум, два сервера для организации кластера и один для размещения Hub Transport и Client Access ролей. Один из вариантов реализации (забегая вперед, скажу, что именно на ней мы и остановились) изображен на рис. 4.

Плюсы: отсутствие единой точки отказа, нет специальных требований к хранилищу данных, автоматическое переключение при отказе любого из компонентов ноды – ОС, сервисов Microsoft Exchange или хранилища данных.
Минусы: дорогая реализация и сложность в настройке.

Рисунок 4. Кластер непрерывной репликации

Следующий тип стал доступен только после выхода Exchange Server 2007 Service Pack 1 (подробнее о том, какие новшества были сделаны в нем, мы остановимся в следующей статье), поэтому выбор мы делали между тремя предыдущими вариантами, так как Service Pack на момент принятия решения еще не был выпущен.

Standby continuous replication (SCR) – резервная непрерывная репликация

Она использует те же методы репликации, что локальная непрерывная репликация и кластерная непрерывная репликация, и может реплицировать почтовые серверы, находящиеся в кластере, или одиночный почтовый сервер (источники) на одиночный почтовый сервер или почтовые серверы, находящиеся в кластере (получатели).

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

В качестве источников эта репликация может использовать следующие серверы:

сервер с ролью почтовых ящиков;
кластер с SCC (кластер единой копии);
кластер с CCR (кластер непрерывной репликации).

Обязательно рекомендую ознакомиться с этими вариантами реализации серверов высокой доступности: http://technet.microsoft.com/en-us/library/bb676502.aspx. Простейшая схема реализации показана на рис. 5.

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

Рисунок 5. Резервная непрерывная репликация

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

Для обеспечения наибольшей безотказности работы было выбрано создание CCR-кластера. Таким образом, мы обеспечили отсутствие единой точки отказа, продублировав оборудование, работоспособность операционной системы, а также сервисов Microsoft Exchange Server 2007.

Планирование

Планирование, наверное, является одним из самых долгих этапов. Описывать его в рамках статьи не имеет смысла. Поэтому прежде чем читать дальше, рекомендуем пройти по этой ссылке http://technet.microsoft.com/en-us/library/bb123996.aspx и ознакомиться с требованиями для построения кластера непрерывной репликации. Мы же приведём здесь отдельные требования, которые требуют акцентированного внимания. Итак, для построения этого варианта сервера высокой доступности необходима операционная система Microsoft Windows 2003 Enterprise Edition. Microsoft Windows 2003 Standard Edition не позволяет воспользоваться функциями кластеризации. То есть для создания необходимой нам структуры нужно к уже имеющимся у нас лицензиям под организацию почтовой подсистемы (рассмотрение лицензий клиентского доступа оставим за рамками этой статьи):

Microsoft Windows 2003 Server Standard Edition 64bit – 1 шт;
Microsoft Exchange Server 2007 Standard Edition – 1 шт.

Приобрести следующие лицензии:

Microsoft Windows 2003 Server Enterprise Edition 64bit – 2 шт.
Microsoft Exchange Server 2007 Enterprise Edition – 2 шт.

Теории выбора оборудования мы уже частично рассматривали в предыдущей статье, поэтому останавливаться на ней не будем. Для тех, кто пропустил, предлагаем начать с этой ссылки http://technet.microsoft.com/en-us/library/bb738142.aspx. И пройтись по пунктам планирования памяти, процессора и дисковой подсистемы.

Для расчета дисковой подсистемы очень пригодится калькулятор – http://msexchangeteam.com/files/12/attachments/entry438481.aspx.

Мы лишь приведём спецификацию оборудования, закупленного для реализации нашего кластера непрерывной репликации (CCR) для компании со штатом на момент планирования 400 человек и предполагаемым увеличением на 50-60% в ближайшие 1-2 года. С усредненным почтовым потоком на человека: входящие, внешние/внутренние – 3/5; исходящие, внутренние/внешние – 3/2. С усредненным размером почтового сообщения – 100 килобайт.

Как можно увидеть из таблицы 1, второй сервер более слабый по конфигурации, однако мы рассчитываем, что он будет работать только в «трудные времена» и не очень долго, то для экономии средств его конфигурация намеренно сделана ниже. За исключением дискового массива, так как объем данных на обоих серверах будет одинаковым.

Таблица 1. Краткая спецификация оборудования кластера

№ п.п.	Имя узла кластера	Процессор	Память	Тип RAID	Размер хранилища
1	S-GAMMA	2*Xeon 2,6	8 Гб	10	1 Tб
2	S-EPSILON	Xeon 2,6	4 Гб	10	1 Tб

На этом месте теоретическую часть данной статьи мы закончим и приступим непосредственно к выполнению самой задачи.

Реализация

Для начала приведем схему того, что у нас должно получиться в конечном итоге (cм. рис. 6).

Рисунок 6. Конечная схема почтовой подсистемы

Исходя из этой схемы, составим список этапов, которые нам необходимо пройти для реализации оной.

1. Установка, настройка и ввод в домен двух компьютеров с установленными операционными системами Windows 2003 Enterprise Server x64.

2. Построение кластера.

3. Настройка FSW (File Share witness) – файлового ресурса свидетеля на сервере с ролью Hub Transport.

4. Установка и настройка активного сервера с Mailbox ролью (активной ноды S-GAMMA).

5. Установка и настройка пассивного сервера с Mailbox ролью (пассивной ноды S-EPSILON).

6. Тестирование кластера на отказоустойчивость.

7. Перенос почтовых ящиков и общих папок на кластер.

8. Удаление роли Mailbox c сервера S-BETA.

Этап 1. Установка и настройка операционной системы

Надеемся, что описывать установку ОС не стоит, напомним лишь, что, помимо самой операционной системы, SP2 и всех критических обновлений, вам необходимо установить:

.NET Framework 2.0 – в случае если у вас Windows 2003 R2, то его можно установить из Windows Component Wizard, вызвать его можно следующей командой:

C:>sysocmgr.exe /i:c:windowsinfsysoc.inf

Internet Information Services (IIS) – устанавливается тоже из компонентов Windows;
PowerShell 1.0.

После установки всех необходимых пакетов (проверить, что все необходимые для начала установки компоненты установлены, можно, запустив Setup.EXE с установочного диска Microsoft Exchange Server 2007, и проверить доступность пункта 4 в меню установки) необходимо добавить пользователя, от имени которого будет запускаться и работать сервис кластера. Для добавления пользователя выполните следующую команду с любой машины, входящей в домен:

C:>net user ClusterAdmin pass@word1 /add /expires:never /passwordchg:no /domain

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

C:>net localgroup Administrators howtoClusterAdmin /add

Примечание: по тексту будет встречаться много команд, поэтому обратите внимание, в какой оболочке выполняются те или иные команды. Если команда начинается с «C:>» или «D:>» значит, эта команда выполняется из обычной командной оболочки Windows. Если же команда начинается с «[PS] C:>» значит, данная команда должна быть выполнена в командной оболочке «Exchange -> Exchange Management Shell».

Этап 2. Построение кластера

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

Введем немного обозначений, которыми будем пользоваться в процессе настройки кластера:

S-BETA – текущий почтовый сервер с ролями Mailbox, Hub Transport, Client Access;
S-GAMMA – активная нода;
S-EPSILON – пассивная нода;
S-EXCHANGE – название кластера.

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

1. Настраиваем на обоих серверах частные сетевые интерфейсы (настройку публичных интерфейсов, смотрящих в сеть, описывать не будем, однако напомним, что IP-адреса обязательно сделать статическими), которые необходимы для работы кластера, см. таблицу 2.

Таблица 2. Параметры частных сетевых интерфейсов

№ п.п.	Имя сервера	IP-адрес	Network mask	Default Gateway, DNS Servers
1	S-GAMMA	10.10.10.2	255.255.255.255	–
2	S-EPSILON	10.10.10.3	255.255.255.255	–

Подробнее по настройке частных интерфейсов можно почитать тут: http://support.microsoft.com/kb/258750. Нужно настраивать исходя из того, что будет использоваться Majority Node Set.

2. Запускаем мастер настройки кластера на S-GAMMA (мастер можно запускать с любой машины, входящей в домен, но рекомендуется делать это именно на машине, которая будет входить в кластер) с помощью команды:

C:>cluster.exe /create /wizard

либо «Start -> Programs -> Administrative Tools -> Cluster Administrator -> Cancel -> File -> New -> Cluster». Жмем «Далее», выбираем домен и вводим желаемое имя кластера (см. рис. 7).

Рисунок 7. Выбор домена и имени кластера

3. На следующем шаге помощника (см. рис. 8) выбираем кнопку «Advanced -> Advanced (minimum) configuration» и нажимаем «OK».

Рисунок 8. Выбор конфигурации кластера

4. Нажимаем «Далее» и исправляем все диагностические сообщения, которые мешают завершить этот шаг. В идеале должно остаться только одно предупреждение, говорящее о том, что проверка дисков не была выполнена, потому что используется минимальная настройка кластера (см. рис. 9). То есть именно то, что мы выбрали, поэтому ничего страшного, и двигаемся дальше.

Рисунок 9. Анализ конфигурации

5. На следующем шаге указываем уникальный публичный IP-адрес для нашего кластера, который будет использоваться для доступа к нему из сети, и нажимаем «Далее».

6. Вводим данные пользователя, созданного на первом этапе настройки кластера (см. рис. 10). Эти данные будут, как мы уже говорили, использоваться для запуска сервиса.

Рисунок 10. Ввод учетных данных, необходимых для запуска сервиса

Поэтому после завершения шага 9 рекомендуем проверить правильность введенных данных с помощью команд:

C:>net stop clussvc

C:>net start clussvc

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

7. Убеждаемся, что создание первой ноды прошло нормально (см. рис. 11), и нажимаем «Далее» и «Завершить».

Рисунок 11. Завершение установки первой ноды кластера

8. У нас готова первая нода, но прежде чем добавлять вторую ноду к нашему кластеру, необходимо произвести «легкий тюнинг». И чтобы сэкономить место уважаемому журналу и поднять свой профессиональный уровень, предлагаем проделать оставшиеся действия из командной строки. Однако эти же действия, конечно, можно сделать через GUI, запустив CluAdmin.exe и, думаю, по ходу комментариев к выполняемым командам можно без труда найти, где это сделать.

Итак, первое, что нам необходимо, – это изменить кворум, созданный по умолчанию, на кворум, необходимый для конфигурации CCR. Для этого добавим к нашему кластеру новый ресурс с именем «MNS» и типом Majority Node Set и включим его, выполнив следующие команды:

C:>cluster s-exchange res "MNS" /create /group:"Cluster Group" /type:"Majority Node Set"

C:>cluster s-exchange res "MNS" /online

9. Теперь настраиваем кластер на использование созданного нами ресурса как основного для кворума и удаляем ненужный нам Local Quorum (локальный кворум):

C:>cluster s-exchange /quorum:MNS

C:>cluster s-exchange res "Local Quorum" /offline

C:>cluster s-exchange res "Local Quorum" /delete

10. Добавим вторую ноду к нашему кластеру с помощью следующей команды.

C:>cluster s-exchange /add:s-epsilon /password:pass@word1 /min

где:

s-exchange – название нашего кластера;
pass@word1 – пароль учетной записи, созданной на первом этапе;
s-epsilon – имя сервера второй ноды.

Ее можно выполнить на любой ноде или компьютере домена (см. рис. 12). Конечно, все можно сделать и с помощью GUI, выбрав меню «File -> New -> Node», и, пройдя более короткий помощник добавления ноды, получить тот же результат, что и на рис. 13.

Рисунок 12. Добавление второй ноды к кластеру

Рисунок 13. Результат по завершению 2-го этапа настройки

Этап 3. Настройка FSW (File Share witness) – файлового ресурса свидетеля

Итак, уже практически все готово к установке Microsoft Exchange Server 2007, за исключением свидетеля – File Share Witness (FSW). Его-то мы сейчас и подготовим.

Внимание: FSW должен настраиваться после добавления последней ноды кластера. В случае изменения количества нод его необходимо перенастроить. Рекомендуемое Microsoft расположение FSW для почтового кластера CCR – Hub Transport роль.

Так как роль Hub Transport у нас играл сервер S-BETA, то и настраивать FSW будем на нем.

1. Создаем папку для размещения FSW и предоставляем к ней доступ учётной записи ClusterAdmin. А затем изменим Security Permissions, предоставляя доступ локальным администраторам и ClusterAdmin.

Напомним, что почтовые БД у нас хранились на RAID-массиве, поэтому для надежности размещения помещаем эту папку туда:

C:>mkdir "d:FSW_MNS_exchange"

C:>net share "FSW-MNS-S-EXCHANGE"="d:FSW_MNS_exchange" /GRANT:ClusterAdmin,Full

C:>cacls "d:FSW_MNS_exchange" /G BUILTINAdministrators:F ClusterAdmin:F

На вопрос при последней команде отвечаем утвердительно.

Такое название созданной папке выбрано не случайно, так как точно описывает назначение папки (File Share Witness Majority Node Set of exchange cluster) и рекомендуется Microsoft к использованию. Однако на самом деле может быть абсолютно таким, каким хотите видеть его вы. Главное, случайно не удалить, подчищая диски при нехватке места или удаляя «смущающие», непонятные папки.

2. Чтобы проверить правильность настройки папки свидетеля, попробуйте подмонтировать ее как диск с любой ноды под учетной записью ClusterAdmin. Если подмонтируется, то вы все настроили правильно. И можно продолжать дальше. В противном случае проверяем права доступа к папке или создаем привычным способом, главное, не ошибиться с правами.

3. Теперь настроим наш кворум на использование папки свидетеля. Для этого выполним в командной строке на первой ноде следующую команду:

C:>cluster "s-exchange" res "MNS" /priv MNSFileShare="s-beta.howto.ruFSW-MNS-S-EXCHANGE"

4. На возникшее от предыдущего шага предупреждение (см. рис. 14) не обращаем внимания и для вступления изменений в силу два раза выполняем следующую команду:

C:>cluster s-exchange group "Cluster Group" /move

Рисунок 14. Изменение места хранения FSW для Majority Node Set

5. Для проверки, что Majority Node Set использует созданный нами File Share Witness, выполните следующую команду (см. рис. 15):

C:>cluster s-exchange res "MNS" /priv

Рисунок 15. Проверка назначения нового ресурса свидетеля

На этом третий этап завершен, и переходим к основному этапу настройки кластера Exchange Server 2007.

Этап 4. Установка активной ноды

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

C:>mkdir e:MBD

2. Теперь запустим установку Microsoft Exchange 2007 с установочного диска и дойдем до выбора устанавливаемых ролей (см. рис. 16), выбрав на предыдущем шаге выборочную установку пакета. Отметим галочкой, что мы хотим установить Active Clustered Mailbox Role, и нажимаем «Далее».

Рисунок 16. Выбор ролей и пути установки

Важно: если вы по каким-либо причинам выберете другой путь установки системных файлов Microsoft Exchange Server, то вам необходимо запомнить это, так как данная информация будет необходима при установке пассивной ноды.

3. В следующем окне (см. рис. 17) вас попросят выбрать тип кластера, указать его имя и публичный IP-адрес, а также указать место размещения групп хранения (созданное на первом шаге этого этапа). Указываем необходимые сведения и двигаемся дальше.

Рисунок 17. Окно выбора параметров создаваемого кластера

4. На следующем шаге еще раз проверяются все необходимые требования к установке выбранной нами конфигурации кластера, и если установщик не нашел каких-либо ошибок, нам любезно предложат начать установку. В случае, если все же установщик скажет вам, что не выполнены некоторые требования, то вам придется подчиниться и выполнить их.

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

5. Жмем «Install», и пока идет установка, жуем бутерброды и пьем кофе до тех пор, пока не увидим на экране окно, такое же, как на рис. 18.

Рисунок 18. Завершение установки активной ноды

Примечание: процесс установки активной ноды можно выполнить из командной строки с помощью следующей команды:

D:>setup.com /mode:install /roles:mailbox /newcms /cmsname:c-exchange /cmsipaddress:192.168.10.10 /CMSDataPath:e:MBD

Более подробную информацию о ключах установки Microsoft Exchange Server 2007 из командной строки вы можете найти тут – http://technet.microsoft.com/en-us/library/bb288906.aspx.

6. Нажимаем кнопку «Завершить» и, если потребует перезагрузки, отказываемся и запускаем Exchange Management Console (далее EMC), чтобы ввести лицензионный ключ: «EMC -> Microsoft Exchange -> Server Configuration», на панели справа щелкаем правой кнопкой мыши на кластере – Enter Product Key (см. рис. 19) и вводим ключ Enterprise-версии.

Рисунок 19. Ввод ключа

7. После ввода ключа необходимо перезагрузить нашу ноду (если вас попросили о перезагрузке после установки), но предварительно нужно выполнить следующую команду в Exchange Management Shell (далее EMS), которая позволит перезагрузить ее правильно:

[PS] C:>Stop-ClusteredMailboxServer c-exchange -StopReason "installing 1st node" -Confirm:$false

8. И сразу после перезагрузки запускаем наш кластер из EMS с помощью команды (см. рис. 20):

[PS] C:>Start-ClusteredMailboxServer c-exchange

Рисунок 20. Результат выполнения команды включения кластера

Этап 5. Установка пассивной ноды

1. Вторую ноду поставим из командной строки, выполнив следующую команду (выполнять на второй ноде):

D:>setup.com /roles:mailbox

Установка пассивной ноды не нуждается в дополнительных параметрах, поэтому команда выглядит коротко, так как остальные параметры наследуются от уже установленной активной ноды. Однако если вы изменяли путь установки сервера (например, с «C:Program FilesMicrosoftExchange Server» на «E:MicrosoftExchange Server») на первой ноде, то вам необходимо добавить еще один параметр /target, с новым путем. Таким образом, команда будет выглядеть приблизительно так:

D:>setup.com /roles:mailbox /targetdir:"E:MicrosoftExchange Server"

После окончания установки окно установки должно выглядеть как на рис. 21.

Рисунок 21. Установка пассивной ноды из командной строки

2. Перезагружаем вторую ноду и запускаем cluadmin.exe на любом сервере домена и подключаемся к созданному кластеру. Получившийся кластер без дополнительных настроек должен выглядеть так, как показано на рис. 22.

Рисунок 22. Проверка кластера через интерфейс управления кластером

Восклицательных знаков, красных крестиков и прочей прелести быть не должно.

3. Теперь настраиваем максимальный размер данных, передаваемых траспортным сервером в хранилище. Для этого необходимо выполнить следующую команду:

[PS] C:> TransportConfig -MaxDumpsterSizePerStorageGroup 12,5MB

Значение 12,5 Mб получается умножением максимально доступного сообщения для отправки и получения, умноженное на коэффициент 1,25. То есть если у вас оно равно 20 Mб, то вам необходимо в команде указать 25 Mб.

4. Проверяем на обеих нодах журнал событий на наличие ошибок и предупреждений, ну и соответственно боремся с ними не покладая рук, если таковые имеются (в смысле ошибки). Если вдруг возникли какие-либо проблемы с CCR, то начните их решение с этой ссылки – http://technet.microsoft.com/en-us/library/aa996020.aspx. Ну и если не найдете решения, обращайтесь на форумы, посвященные этому продукту Microsoft – http://forums.microsoft.com/TechNet-RU/ShowForum.aspx?ForumID=971&SiteID=40.

На этом шаге настройка нашего кластера завершена.

Этап 6. Проверка кластера

К данному этапу следует отнестись с особым вниманием. Потому что после полного переноса почтовых ящиков выполнять данный этап без «оглядки» уже не получится. Существует несколько физических способов проверки для эмуляции выхода из строя одной из ноды кластера:

отключение сетевого интерфейса;
выключение питания ноды;
отключение дисков.

Более изощренные способы – взять молоток и проверить сервер (жесткие диски) на прочность; вылить чашку кофе в системный блок – предлагать не будем, так как бюджет на еще один сервер для проверки нам больше не выделят. Хотя количество вариантов таких проверок значительно расширяется и зависит от богатства фантазии.

В любом случае после каждой проверки нам необходимо убедиться, что:

мы имеем доступ к тому ящику, который в данный момент уже находится в группе хранения на кластере;
мы можем отправлять и получать на него письма;
при выполнении команды:

[PS] C:>Get-StorageGroupCopyStatus

мы не получаем ошибок в графе SummaryCopyStatus.

Ну и наконец для программной эмуляции выхода из строя одной из нод кластера, а также для выбора активной ноды нам понадобится следующая команда:

[PS] C:>Move-ClusteredMailboxServer c-exchange –TargetMachine:"S-EPSILON" -MoveComment:"test moving" -Confirm:$false

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

Команда

C:>cluster s-exchange group "C-EXCHANGE" /move

делает то же самое, однако в этом случае:

не производится проверка состояния пассивной копии БД;
в некоторых частных случаях БД может не перейти в состояние ONLINE.

Поэтому используем ее только в качестве тестирования, в остальных случаях крайне рекомендуется использовать команду Move-ClusteredMailboxServer. Скрипт, который вам поможет делать автоматическое безопасное переключение между нодами во время перезагрузки, можно посмотреть и скачать тут – http://telnetport25.wordpress.com/2007/12/15/exchange-2007-ensuring-a-clean-ccr-node-shutdown.

Этап 7. Перенос почтовых ящиков и общих папок

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

1. Если вы храните все почтовые ящики в одном хранилище данных и у вас нет каких-либо условий на принадлежность почтовых ящиков пользователей к группам хранения, переместить их можно будет одной строкой, выполненной в EMS:

[PS] C:>Get-Mailbox | move-mailbox -TargetDatabase "S-BETAFirst Storage GroupMailbox Database" -Confirm:$false | FT DisplayName, MoveStage, StatusMessage

Естественно, если вы имели несколько групп хранилищ и хотите переместить почтовые ящики в таком же составе на кластер, тогда вам необходимо выполнить следующую команду, подставив в нее свои переменные:

[PS] C:>Get-Mailbox | where {$_.Database -like "S-BETAFirst Storage GroupMailbox Database"} | move-mailbox -TargetDatabase

"C-EXCHANGEFirst Storage GroupMailbox Database" -Confirm:$false | FT DisplayName, MoveStage, StatusMessage

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

2. Для переноса общих папок необходимо:

Создать на кластере группу хранения общих папок, выполнив команду в EMS:

[PS] C:>new-StorageGroup -Server "C-EXCHANGE" -Name "PFSG" -LogFolderPath "E:MBDPFSG" -SystemFolderPath "E:MBDPFSG"

Создать базу данных общих папок:

[PS] C:>new-publicfolderdatabase -StorageGroup "PFSG" -Name "PFDB" -EdbFilePath "E:MBDPFSGPFDB.edb"

Подключить созданную базу данных:

[PS] C:>mount-database -Identity "PFDB"

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

[PS] E:>Get-MailboxDatabase | where {$_.PublicFolderDatabase -like "S-BETASecond Storage GroupPublic Folder Database"} |

Set-MailboxDatabase -PublicFolderDatabase "C-EXCHANGEPFSGPFDB"

На сервере, с которого мы хотим перенести общие папки, выполните следующие команды:

[PS] C:\>cd "C:\Program Files\Microsoft\Exchange Server\Scripts\"

[PS] C:\Program Files\Microsoft\Exchange Server\Scripts>MoveAllReplicas.ps1 -Server S-BETA -NewServer C-EXCHANGE

Последняя команда перенесет реплики со старой базы данных общих папок в созданную нами.

2.6. Если структура общих папок большая, то подождите некоторое время (день или два), пока не закончится репликация общих папок на созданный кластер. Проверить это можно, отмонтировав базу данных общих папок на сервере, с которого вы их переносите, и, внеся какие-либо изменения в общих папках, проверить, что они завершились удачно.

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

[PS] C:>remove-PublicFolderDatabase "s-betasecond storage grouppublic folder database"

Этап 8. Удаление роли Mailbox

Удаление роли Mailbox – завершающий этап. Здесь у нас было небольшое опасение: «А вдруг все сломается?!» На самом деле это безопасная операция, хотя иметь резервные копии AD на этом этапе все же рекомендуется. Кстати, папки с группами хранения не удаляются! Так что перестраховываться и копировать или делать резервную копию их не обязательно.

Выполняется удаление роли очень просто (см. рис. 23).

Рисунок 23. Удаление роли Mailbox

Достаточно выполнить команду:

D:>setup.com /mode:uninstall /role:mailbox

Теперь открываем EMC и убеждаемся, что у нас остался один сервер с почтовой ролью («EMS -> Microsoft Exchange -> Server Configuration»). Также можно увидеть наши сервера и установленные на них роли с помощью команды (см. рис. 24):

[PS] C:>Get-ExchangeServer | FT Name, ServerRole

Рисунок 24. Результат выполнения команды вывода ролей

Мы не зря приводили большое количество команд управления сервером из командной строки. Потому что некоторые действия невозможно выполнить с помощью консоли управления EMS. И настройка отдельных компонентов сервера требует знания команд и умения пользоваться ими. Поэтому для тех, кто будет управлять сервером Exchange 2007, в обязательном порядке придется ознакомиться со списком доступных для этого команд – http://technet.microsoft.com/en-us/library/bb691129.aspx.

Заключение

Надеемся, многие дочитали до этого момента, но не только дочитали, но и почерпнули для себя что-то новое. Жаль, что количество страниц в журнале ограничено и приходится давать важную информацию в довольно сжатом виде. Но в ссылках по тексту и в конце статьи вы найдете много интересного и полезного относительно этой темы и не только. На этом разрешите сказать вам большое спасибо за уделенное время и пожелать удачи в работе!

P.S.: некоторые материалы с ссылками на http://technet.microsoft.com доступны на русском языке. Для того чтобы посмотреть его в русском варианте, достаточно в ссылке исправить «en-us» на «ru-ru».

P.P.S.: все пожелания, замечания, критику будем рады выслушать на форуме журнала www.samag.ru/forum.