Обеспечение устойчивости сайтов с помощью SCR, рекомендуемый объем корневого тома и прочее

В. Сейчас я разрабатываю инфраструктуру обмена сообщениями, построенную на Exchange Server 2007, для крупного предприятия. Требуется, чтобы решение обеспечивало устойчивость сайтов. Я рассматриваю развертывание серверов почтовых ящиков на основе кластеров с непрерывной репликацией (CCR), используя отказоустойчивые кластеры Windows Server 2008 с активным узлом в основном (активном) и пассивным узлом во вторичном (резервном) центре данных.

Центры данных находятся в различных подсетях, но принадлежат одному сайту Active Directory, а это значит, что данный сценарий поддерживается при установке серверов почтовых ящиков на основе CCR в Windows Server 2008. Вы бы порекомендовали развертывание серверов почтовых ящиков на основе CCR в среде с несколькими подсетями?

О. Верно, что данный сценарий поддерживается до тех пор, пока один сайт Active Directory растянут на все центры данных, поскольку Exchange 2007 не поддерживает развертывание активных и пассивных узлов CCR на различных сайтах Active Directory. Тем не менее, важно иметь в виду, что CCR был разработан для высокой доступности в пределах центра данных, а не для обеспечения устойчивости сайтов (которая в большей мере связана с аварийным восстановлением, чем с высокой доступностью).

Именно по этой причине группа разработчиков Exchange представила резервную непрерывную репликацию (SCR) в Exchange 2007 с пакетом обновления 1 (SP1). SCR и CCR используют одну и ту же технологию доставки и воспроизведения журналов, но SCR не полагается на функции отказоустойчивости кластеров Windows, в отличие от CCR. Это значит, что репликацию в целевой объект SCR можно сделать возможной как для кластеризованных, так и для некластеризованных серверов почтовых ящиков. Целевой объект может быть некластеризованным сервером почтовых ящиков или резервным кластером, на котором была установлена роль пассивного кластеризованного сервера почтовых ящиков.

Это иллюстрируется рисунком 1, взятым из раздела документации Exchange 2007, описывающего резервную непрерывную репликацию.

Я бы не рекомендовал реализацию географически рассредоточенного кластера (гео-кластера) на основе CCR, но такой вариант, как уже упомянуто, полностью поддерживается корпорацией Майкрософт. Так или иначе, необходимо знать недостатки такого подхода.

Рис. 1. Модель резервной непрерывной репликации

Во-первых, это необходимость растягивать сайт Active Directory. Похоже, что вы уже так и делаете, но об этом стоит упомянуть и для остальных наших читателей, которые могут этого не знать. Необходимо также учитывать, что поскольку узлы CCR расположены в различных подсетях, то при отработке отказа с переходом на другой сайт у кластерного сервера почтовых ящиков (CMS) изменится IP-адрес. Это изменение будет необходимо реплицировать для всех серверов DNS, используемых клиентами Microsoft Outlook и, что не менее важно, нужно будет очистить кэш DNS всех компьютеров с клиентами Outlook, подключающихся к CMS.

Пока это не произойдет, клиенты Outlook будут отключены от своих почтовых ящиков на CMS. По этой причине значение срока жизни (TTL) DNS для сети CMS следует изменить на пять минут (300 секунд) или меньше. Дополнительные сведения о том, как это делается, можно найти по адресу technet.microsoft.com/library/bb676687.aspx.

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

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

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

В. Наша организация состоит из нескольких физических сайтов, разбросанных по США, а также расположенных в Европе, Африке и на Ближнем Востоке. В настоящий момент все почтовые ящики наших пользователей размещены на серверах почтовых ящиков, локально развернутых на каждом из физических сайтов, но мы хотели бы объединить эти серверы в один центр данных, расположенный в США. Не могли бы вы сообщить, какова будет в свете этого плана максимально допустимая задержка для клиентов Outlook 2003/2007, работающих в режиме кэширования?

О. Очень хорошо, что вы используете лишь клиенты Outlook 2003 или 2007, причем в режиме кэширования, поскольку режим кэширования является настоящим спасательным кругом при объединениях, подобных описываемому.

В прошлом корпорация Майкрософт рекомендовала задержку в 1000 мс или менее при обращении к серверу почтовых ящиков, для работающих в режиме кэширования клиентов Outlook 2003. Для клиентов Outlook 2003, не использующих режим кэширования, рекомендовалось 200 мс или менее.

Согласно моему личному опыту, 1000 мс – это многовато даже для клиентов Outlook 2007 в режиме кэширования. Если задержка превышает 500 мс, Outlook начинает зависать и в целом работать медленно. Я бы посоветовал стремиться к задержке между клиентом Outlook и сервером почтовых ящиков в 500 мс или менее. На рис. 2 можно увидеть среднее время ответа для моего клиента Outlook 2007, подключенного к почтовому ящику в Редмонде.

Вот подсказка: чтобы открыть окно Connection Status (состояния подключений), показанное на рис. 2, можно щелкнуть правой кнопкой мыши значок Outlook в панели задач, удерживая нажатой клавишу CTRL. Кроме того, Outlook можно запустить, щелкнув кнопку «Пуск» | «Выполнить» и введя Outlook.exe /RPCDIAG.

Увеличить

Рис. 2. Среднее время ответа в Outlook 2007

Учитывая, что я живу в Дании, среднее время ответа приемлемо. Можно заметить, что среднее время ответов от сервера глобального каталога существенно выше, но, поскольку этот сервер используется реже (для просмотра адресной книги и тому подобного) это не имеет большого значения.

В. Мы только что развернули в нашей организации Exchange 2007 с пакетом обновления 1 (SP1). Топология Active Directory состоит из двух сайтов. На первом сайте мы развернули сервер почтовых ящиков на основе CCR и два сервера, на каждом из которых установлены роли транспортного сервера-концентратора и сервера клиентского доступа. На втором сайте мы развернули сервер почтовых ящиков на основе кластера с единым хранилищем (SCC), а также два сервера с ролями транспортного сервера-концентратора и сервера клиентского доступа, так же как на первом сайте Active Directory.

Большинство клиентов обоих сайтов Active Directory по-прежнему используют Outlook 2003, а это значит, что для сведений о доступности и автономной адресной книги требуется хранилище общих папок (общие папки будут использоваться исключительно для этой цели, а не для хранения данных). Наш первоначальный план состоял в размещении одного хранилища общих папок на серверах почтовых ящиков, основанных на CCR, а другого –– на серверах, основанных на SCC, чтобы изменения общих папок могли бы реплицироваться на других сайтах Active Directory. Но затем мы узнали, что корпорация Майкрософт не рекомендует создавать более одного хранилища общих папок в организации Exchange, если одно из них размещено на сервере почтовых ящиков, основанном на CCR, из-за плохой совместимости репликации общих папок с репликацией CCR.

С учетом всего этого, чтобы вы порекомендовали нам сделать? Мы не хотели бы использовать подход, о котором отрицательно отзывается корпорация Майкрософт. В то же время нам бы не хотелось, чтобы клиентам Outlook 2003 на одном сайте Active Directory приходилось связываться с общей папкой на другом сайте Active Directory.

О. Это очень хороший вопрос. Верно, что сочетания репликации общих папок и репликации CCR для хранилища общих папок следует избегать (подробности о том, почему, можно найти в моей статье из рубрики «Очередь Exchange и ответы на вопросы» за январь 2009 года. Функции хранилища общих папок в данном случае будут использоваться для предоставления устаревшим клиентам Outlook возможности просматривать сведения о доступности и автономную адресную книгу. Поэтому я рекомендую установить роль сервера почтовых ящиков на одном из серверов, которые сочетают роли транспортного сервера-концентратора и сервера клиентского доступа и которые расположены на том сайте Active Directory, где находится сервер почтовых ящиков на основе CCR. Затем перенесите хранилище общих папок из сервера почтовых ящиков на основе CCR на этот сервер.

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

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

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

О. В статье базы знаний «Как настроить точки подключения тома в кластере серверов Windows Server 2008» описана настройку точек подключения тома в кластере серверов Windows Server 2008. В ней утверждается, что если корневой (узловой) том, также известный как LUN привязки, используется исключительно для точек подключения, то его размер должен быть не менее 5 МБ. Но рекомендации для корневых томов отличаются, когда речь идет об Exchange.

В Exchange 2007, как и в предыдущих версиях Exchange Server, рекомендуется использовать корневой том размером от 100 МБ до 500 МБ. При использовании Exchange 2007 на серверах Windows Server 2003 проблемы с созданием новой базы данных могут возникнуть, если размер корневого тома меньше чем 20 МБ. Для получения дополнительных сведений по этому вопросу обратитесь к разделу «Event 104 is logged after you create a new database in Exchange Server 2007 (Событие 104 регистрируется после создания новой базы данных в Exchange Server 2007)».

В. Инфраструктура обмена сообщениями нашей организации основана на Exchange 2007 с пакетом обновления 1 (SP1). Все серверы Exchange 2007 размещены в одном и том же центре данных и основаны на технологии кластеров CCR, так локальное дублирование у нас есть. Также мы только что установили второй центр данных в качестве резервного, в случае, если основной при аварии будет утерян.

Устойчивость сайтов мы планируем обеспечить, развернув один транспортный сервер-концентратор, один сервер клиентского доступа и один сервер почтовых ящиков в запасном центре данных. Далее мы хотим сделать возможным SCR с серверов почтовых ящиков на основе CCR в основном центре данных на сервер почтовых ящиков в запасном. Перед созданием серверов Exchange 2007 в запасном центре данных у нас возник вопрос, на который, мы надеемся, вы сможете ответить. Мы хотели бы знать, поддерживается ли включение SCR между источниками SCR, состоящими из серверов почтовых ящиков на основе CCR, и целевым объектом SCR, состоящим из отдельного сервера почтовых ящиков. И если да, то стоит ли использовать этот подход?

О. Короткий ответ – да, это полностью поддерживается. Длинный ответ – тоже «да», но при этом необходимо помнить, что CMS, расположенные на исходном сервере (серверах) SCR, нельзя восстановить при помощи параметра /RecoverCMS. Восстановить CMS с помощью /RecoverCMS можно только в том случае, если целевым объектом SCR является отказоустойчивый кластер Windows Server 2003/2008, на котором была установлена лишь пассивная роль сервера почтовых ящиков.

Если в качестве целевого объекта SCR развернут отдельный сервер почтовых ящиков, базы данных придется восстанавливать с использованием переноса баз данных – менее удобной процедуры, чем метод RecoverCMS. Необходимые шаги можно найти в документации Exchange 2007, а именно в статье «Пассивная непрерывная репликация. Переносимость баз данных». Если на целевом объекте SCR установлен корпоративный выпуск Windows Server 2003/2008, то можно удалить роль сервера почтовых ящиков, сформировать отказоустойчивый кластер, установить роль пассивного сервера почтовых ящиков на одном из узлов отказоустойчивого кластера и затем восстановить CMS с помощью RecoverCMS.

Если сейчас доступен лишь один физический компьютер, но еще один компьютер (и дополнительная лицензия для корпоративных выпусков Windows Server 2003/2008 и Exchange Server 2007) будут доступны в ближайшем будущем, то можно также начать формировать отказоустойчивый кластер Windows Server 2003/2008, состоящий из единственного узла; а затем установить на этом узле роль пассивного сервера почтовых ящиков. Когда этот дополнительный компьютер готов, на нем можно установить Windows Server 2003/2008, настроить параметры сети и тому подобное и, наконец, добавить его к отказоустойчивому кластеру Windows.