Вопросы о кластерах Exchange 2007 (часть 2)

В первой части этого цикла статей мы рассмотрели некоторые вопросы, часто задаваемые на различных форумах и в новостных группах, связанные с функциями непрерывной репликации Exchange 2007. Эти вопросы концентрируются на таких темах, как статус копий групп хранения, применение пакетов обновления к кластерам и количество узлов в средах непрерывной кластерной репликации (Cluster Continuous Replication – CCR). Во второй части мы продолжим рассмотрение дополнительных вопросов о кластерах Exchange 2007.

Как переместить существующий единый сервер в новую среду CCR?

Некоторые организации установили единый комбинированный сервер Exchange 2007 для удовлетворения своих нужд. На этих серверах всегда запущены роли серверов почтовых ящиков, серверов клиентского доступа и пограничного сервера-концентратора, поскольку эти роли являются обязательными в любой организации Exchange 2007. В некоторых случаях роль сервера унифицированной системы обмена сообщения (Unified Messaging) также располагалась на одном сервере. Иногда такие организации осознают, что почтовая система становится все более важной для бизнеса, и поэтому переход на одну из ролей кластерного почтового сервера становится привлекательным. Под кластерным почтовым сервером я подразумеваю среду CCR или Single Copy Cluster (SCC).

Первым моментом, важным для понимания при переходе на CCR или SCC среду является следование «правилам» относительно кластерной среды:

1. Если вы устанавливаете кластерный почтовый сервер в среду CCR или SCC, у вас не может быть никаких ролей помимо кластерного почтового сервера на этой машине.
2. Учитывая пункт 1, это означает, что за пределами среды CCR или SCC требуется как минимум еще один сервер, под управлением которого будут запущены роли сервера клиентского доступа (Client Access Server) или сервера Hub Transport.
3. Среда CCR состоит из двух узлов, в то время как SCC среда может включать от двух до восьми узлов.

Итак, давайте рассмотрим вероятную конфигурацию новой инфраструктуры, которая перемещается с единого комбинированного сервера. Если единый сервер работает удовлетворительно, то надо признать, что среды CCR или SCC с двумя узлами будет более чем достаточно. Ее нужно будет построить на новом аппаратном оборудовании наряду с существующим сервером, с новыми группами хранения и новыми базами данных. После создания новой кластерной среды почтовые ящики можно просто переместить с существующего единого сервера в новую кластерную среду, используя встроенные инструменты, имеющиеся в консоли Exchange Management Console или оболочке Exchange Management Shell. После этого роль сервера почтовых ящиков можно удалить с единого сервера, и оставить там только роли Client Access Server и Hub Transport.

Возможно, здесь вы зададите вопрос о том, какой смысл в кластерной среде, если используется совместная роль серверов Hub Transport или Client Access Server. Это веский аргумент, поскольку единый сервер, на котором установлены обе роли, может дать сбой, и такие важные для предприятия функции, как способность пользователей отправлять, или получать новые сообщения, будут утрачены. Если вы собираетесь установить технологию высокой доступности и отказоустойчивости для роли сервера почтовых ящиков, вам в действительности придется использовать эту технологию и для ролей сервера Client Access Server и Hub Transport. Таким образом, здесь будет наиболее рациональной установка дополнительного сервера, на котором вы можете установить роли Client Access Server и Hub Transport, а также использовать для них компенсацию нагрузки с существующим сервером, на котором установлены те же роли. Это означает, что вся новая система будет обладать высокой отказоустойчивостью и доступностью.

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

Требуется ли кластерный ресурс MSDTC в Exchange 2007?

Простой ответ на этот вопрос будет «нет». В предыдущих версиях Exchange, таких как Exchange 2003, ресурс Microsoft Data Transaction Coordinator (DTC) требовался в кластерных средах для таких операций, как установка пакетов обновления Exchange. В случае с Exchange 2007 дело обстоит не так, и кластерные ресурсы DTC более не требуются.

Может ли единый SCR сервер служить целевым сервером для множественной среды CCR?

Да, одной из функций аварийной непрерывной репликации (Standby Continuous Replication – SCR) является то, что один сервер SCR может служить целевым сервером для нескольких исходных серверов. Например, производственная система может состоять из двух отельных сред CCR в одном центре данных, в то время как один аварийный кластер может существовать в аварийном центре восстановления данных и служить в качестве SCR целевого сервера для обеих производственных сред CCR. Однако следует отметить, что такая конфигурация не обеспечит действительной гибкости сайта для обеих производственных CCR сред, поскольку только одна среда CCR в определенное время может быть восстановлена на целевом SCR сервере. Такой сценарий обычно используется в ситуациях, где одна из сред CCR содержит важные почтовые ящики VIP, которые восстанавливаются, если сайт, содержащий обе производственные среды CCR, дает сбой. Если вы планируете использовать такую конфигурацию, необходимо учитывать следующие моменты:

• Целевой сервер SCR может содержать не более 50 групп хранения в общей сложности. Следовательно, обе среды CCR в производственном центре данных не могут содержать общее количество групп хранения, превышающее 50. Например, работоспособной конфигурацией будет та, в которой каждая среда CCR содержит не более 25 групп хранения.
• Целевой сервер SCR должен работать под управлением той же операционной системы, что и среды CCR.
• Очень важно планировать пути групп хранения и баз данных в средах CCR и SCR, поскольку они не должны повторяться. Например, необходимо избегать ситуации, где обе среды CCR содержат первые группы хранения, расположенные, скажем, по следующему пути D:\SG1DB. В этом случае невозможно будет включить SCR для данной группы хранения, поскольку обе группы будут претендовать на одно и то же место на целевом сервере SCR.

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

Как обстоят дела с автономной адресной книгой в кластере?

Многие администраторы Exchange установили CCR среду и расположили автономную адресную книгу (Offline Address Book – OAB) в этой среде CCR, чтобы впоследствии обнаружить, что запись в журнале регистрации событий, как показано на рисунке 4, была создана через некоторое время после сбоя среды CCR.

Давайте более подробно разберемся, что означает эта запись. Возьмем только что установленную среду CCR, которая состоит из двух узлов с названиями CCRA и CCRB. В этой CCR среде узел CCRA был установлен первым. Если вы посмотрите в раздел реестра HKLM\System\CurrentControlSet\Services\MSExchangeSA\Parameters\CCRA любого из узлов, то увидите, что запись EnableOabGenOnThisNode имеет значение CCRA, а это имя первого узла, установленного в среде CCR, рисунок 5.

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

Чтобы исправить эту проблему после обхода отказа, можно изменить ключ реестра, указав активный узел в вышеприведенном ключе. Например, в среде CCR, о которой я здесь говорю, узел CCRA был установлен первым, следовательно, ключ реестра обращается к этому узлу. Если ваш CMS теперь перемещен на узел CCRB, ключ реестра в узле CCRB можно изменить, чтобы он ссылался на имя сервера CCRB. Однако здесь следует быть очень осторожным, поскольку в результате генерируется новая книга OAB. В результате новая книга OAB должна быть загружена клиентами, что может вызвать значительное увеличение нагрузки по трафику. Конечно, если CMS перемещен обратно на узел CCRA, потребуется такой же процесс.

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

Заключение

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