Как улучшить работу кластера Exchange

Простые приемы совершенствования кластера

Объединив в кластер системы Exchange Server 2003 или Exchange 2000 Server, можно повысить отказоустойчивость, столь необходимую для приложений электронной почты, от которых не в последнюю очередь зависит деятельность предприятия. Приступая к созданию кластеров Exchange, полезно сделать некоторые подготовительные шаги, в частности организовать обучение персонала, составить перспективный план, повысить избыточность кластера и развернуть надежную инфраструктуру Windows. Предполагается, что читатели имеют некоторое представление о кластерах. Основы организации кластеров изложены в статье «Объединение серверов Exchange 2000 в кластер», опубликованной в Windows & .NET Magazine/RE № 1 за 2002 г., и в статье Microsoft «Deploying Microsoft Exchange 2000 Server Clusters», которую можно найти по адресу http://www.microsoft.com/downloads/details.aspx?familyid=824a63a2-f722-4bff-a223-e71b856f83c4. Сравнительный анализ кластеров Exchange 2003 и Exchange 2000 приведен в статье «Кластеры на базе Exchange Server 2003», опубликованной в Windows & .NET Magazine/RE № 8 за 2003 г.

Обучение

Кластеры сложнее односерверных систем Exchange, поэтому администраторам необходимо познакомиться с принципами и функциями кластеров, такими как кворум (quorum), передача функций отказавшего узла исправному и обратный переход после возобновления работы отказавшего узла (failover/failback), использование утилиты управления Cluster Administrator. Важно также разобраться в требованиях, предъявляемых к аппаратным средствам кластера. Например, совместно используемая память должна быть доступна всем узлам, поэтому администратору предстоит правильно настроить любое оборудование, которое обеспечивает связь с хранилищами памяти (например, контроллеры массивов, коммутаторы сетей устройств памяти — SAN), чтобы избежать конфликтов и порчи баз данных. Без внимания к деталям невозможно обеспечить корректную установку Windows перед развертыванием Exchange и соблюсти правильную последовательность установки и настройки Exchange для работы в кластере — этот процесс существенно отличается от развертывания Exchange на одном сервере. Например, чтобы организовать двухузловой, активный/пассивный кластер, нужно выполнить в строгой последовательности ряд операций.

Запустить Exchange Setup на узле 1.
Запустить Exchange Setup на узле 2.
Сформировать кластерную группу для виртуального сервера Exchange (Exchange Virtual Server, EVS).
Переместить дисковые ресурсы, используемые EVS, в кластерную группу Exchange.
Создать необходимые ресурсы для EVS (например, Microsoft MSDTC - Distributed Transaction Coordinator, координатор распределенных транзакций - ресурс IP Address, ресурс Network Name).
Создать ресурс System Attendant для EVS. При этом необходимо указать имя EVS, административную и маршрутную группы, к которым будет принадлежать EVS, и разделяемую папку, где Exchange будет создавать и хранить базы данных, журналы транзакций и папки SMTP во время установки.
Cluster Administrator автоматически создает кластерные ресурсы Exchange для EVS (например, Information Store - IS; HTTP- и IMAP-серверы для виртуального сервера; необходимые связи для ресурсов IP Address и Network Name).
Использовать Exchange System Manager (ESM) для перемещения компонентов Exchange (баз данных, журналов транзакций и SMTP-папок) на разделяемые устройства или в общие папки в соответствии с принятой методикой. Требуется обеспечить доступ Exchange к этим ресурсам из каждого узла в процессе отработки отказов EVS.

Необходимо изучить концепции служб кластеризации Microsoft Cluster (более подробно об этом можно прочитать в «Белых страницах» Microsoft «Windows Clustering Technologies-An Overview» по адресу http://www.microsoft.com/windows2000/techinfo/ planning/clustering.asp). Кроме того, следует знать об ограничениях, связанных с работой Exchange 2003 или Exchange 2000 на кластере. Например, коннектор Lotus Notes кластерами Exchange 2003 и Exchange 2000 не поддерживается. Об этом рассказано в статье Microsoft «Status of Exchange 2000 Server and Exchange Server 2003 Components on a Server Cluster» (http://support.microsoft.com/?kbid=259197). Требуется развернуть дополнительные стандартные серверы для поддержки любых компонентов, не поддерживаемых кластерами. К этой категории относятся многие продукты независимых компаний, и, учитывая сложность кластеризации, я настоятельно рекомендую неподдерживаемые продукты на кластере не применять.

Обучение необходимо, однако экспериментам может помешать очень высокая стоимость развертывания тестовых кластеров, соответствующих производственным спецификациям. Расходы связаны с требованием задействовать дополнительные аппаратные средства (по сравнению с односерверными системами). Потому и бывает сложно приобрести опыт работы с кластерами перед их практическим развертыванием. Чтобы организовать тренировочные кластеры без лишних затрат, можно использовать виртуальные серверные технологии, такие как VMware или Microsoft Virtual Server. В Windows Server 2003 появилось понятие локального кворума (local quorum), позволяющего развернуть одноузловые кластеры. Однако в таких кластерах нельзя тестировать операции передачи/возврата функций в случае отказа узлов или отмены обновлений.

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

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

Аппаратные спецификации. Все аппаратные компоненты кластера Windows 2000 (например, дисковые накопители и контроллеры массивов) должны быть в списке совместимого оборудования Microsoft Hardware Compatibility List (HCL — http://www.microsoft.com/whdc/hcl/default.mspx). Администраторам кластеров Windows 2003 следует обратиться к каталогу Windows Catalog (http://www.microsoft.com/windows/catalog/server), который заменил список HCL. Компания Microsoft не поддерживает конфигурации, в которые входят устройства, отсутствующие в HCL или Windows Catalog. В списке HCL устройства разделены на категории (экран 1); такое же деление используется и в каталоге Windows Catalog.

Экран 1. Список Microsoft HCL

Конфигурация узлов. Внутри кластера следует идентично настроить конфигурацию всех узлов, на которых размещается EVS, и укомплектовать все узлы памятью, дисками, процессорами и другими компонентами с одинаковыми характеристиками. Группа Operations and Technology Group (OTG) компании Microsoft спроектировала кластеры, узлы которых укомплектованы аппаратными средствами с различными характеристиками, но я рекомендую использовать внутри кластера узлы одинаковой конфигурации. Наличие кластерных узлов с различными аппаратными характеристиками дополнительно усложняет задачу Cluster Administrator. Кроме того, применение узлов с различными характеристиками может привести к скачкам в производительности при перемещении серверов EVS между узлами. В статье Microsoft «The Microsoft Support Policy for Server Clusters and the Hardware Compatibility List» (http://support.microsoft.com/?kbid=309395) описана политика поддержки компанией кластерных аппаратных средств, а некоторые поставщики оборудования предлагают сертифицированные и поддерживаемые Microsoft кластерные пакеты со стандартными аппаратными средствами.

Ограничения, связанные с управлением памятью кластера. Кластерам активный/активный в первых системах Exchange 2000 были свойственны проблемы с виртуальной памятью. Первая версия Exchange 2000 поддерживает не более 1000 соединений на узел, Exchange 2000 Service Pack 1 (SP1) обеспечивает до 1500 соединений, а SP2 — до 1900 соединений, как и Exchange 2003. Данное ограничение применимо к кластерам, работающим с Windows 2003 и Windows 2000. Однако компания Microsoft рекомендует для Exchange 2003 и Exchange 2000 кластерную модель активный/пассивный. В кластерах активный/пассивный отсутствуют ограничения на число соединений, как в кластерах активный/активный. Проблема фрагментации виртуальной памяти в кластерах активный/пассивный не столь остра, так как EVS всегда можно запустить на пассивном узле.

В среде Exchange 2003 встроенная функциональность ESM устанавливает правила для кластеров активный/пассивный с числом узлов более двух: число серверов EVS не должно превышать (N-1), где N — число узлов в кластере. ESM блокирует попытки организовать серверы EVS, если их столько же или больше, чем узлов в кластере. Однако необходимо отслеживать фрагментацию памяти в активных/пассивных кластерах (и автономных серверах) со многими пользователями. В статье Microsoft «XADM: Monitoring for Exchange 2000 Memory Fragmentation» (http://support.microsoft.com/?kbid=296073) описано, как настроить конфигурацию Performance Monitor для контроля использования виртуальной памяти. Более подробную информацию о планировании кластеров Exchange 2003 можно найти в статье Microsoft «Planning an Exchange 2003 Messaging System» (http://www.microsoft.com/downloads/ details.aspx?familyid=9fc3260f-787c-4567-bb71-908b8f2b980d).

Избыточность, избыточность и еще раз избыточность

Главный принцип при проектировании любых кластеров — обеспечить высокую отказоустойчивость. В случае аппаратного отказа ресурсы неисправного узла будут переданы другому узлу кластера. При передаче функций пользователям Exchange нельзя обращаться к почтовым папкам в течение короткого промежутка времени, пока ресурсы отключаются от сети на отказавшем узле и подключаются на другом узле. Каждый узел в кластере следует дополнить избыточными компонентами, чтобы смягчить последствия аппаратных отказов и избежать переключения на резервный узел. В частности, можно установить избыточные сетевые адаптеры, источники питания, адаптеры хост-шины (host bus adapter, HBA) и контроллеры массивов.

Несколько сетевых адаптеров могут работать как один виртуальный адаптер, и отказ одного сетевого адаптера, кабеля или коммутатора порта (при разделении адаптеров между несколькими сетевыми коммутаторами) не приведет к перерыву в обслуживании. Я рекомендую объединять сетевые адаптеры общей (клиентской) сети в кластер, но компания Microsoft не поддерживает их объединение во внутренней сети кластера (как описано в статье Microsoft «Network Adapter Teaming and Server Clustering» at http://support.microsoft.com/?kbid=254101).

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

Если в кластере используется SAN, то полезно организовать избыточные соединения между узлами и SAN, чтобы в случае отказа адаптеров хост-шины, волоконно-оптических соединений или коммутаторов SAN продолжать работу без переключения на резервный узел. Следует уделить внимание настройке конфигурации памяти; многие проблемы первых кластеров Exchange 2000 были связаны с памятью.

Стабилизация инфраструктуры Windows

Стабильная и гибкая инфраструктура Windows — важнейший элемент любой кластерной системы Exchange. Для кластера Exchange 2003 все контроллеры домена (DC) Active Directory (AD) и серверы глобального каталога Global Catalog (GC) должны работать на Windows 2003, Windows 2000 SP3 или с более поздним пакетом исправлений; DC и серверы GC, совместимые с кластером Exchange 2000, должны работать на Windows 2000 или операционной системе более поздней версии. Каждый DC содержит полную копию всех объектов в домене, а также копию объектов, реплицированных в контексте именования конфигурации в масштабах леса. Сервер GC содержит полную копию всех объектов в домене GC-сервера, а также частичные копии объектов остальных доменов леса. DSAccess — компонент Exchange, который обнаруживает и извлекает информацию AD из контроллеров домена и серверов GC. Из контроллеров домена извлекается информация о таких логических объектах Exchange, как административные группы, коннекторы, системные политики Exchange, и информация о других серверах организации Exchange. Из серверов GC компонент DSAccess извлекает информацию о пользователях, в частности почтовый адрес и сведения о членстве в распределенных группах. Более подробную информацию о DSAccess можно найти в статье «DSAccess из второго пакета обновлений Exchange 2000» по ссылке http://www.osp.ru/win2000/exchange/49exch10.htm.

Чтобы обеспечить стабильность базовой инфраструктуры кластера, можно реализовать избыточность в организации Windows 2000 или Windows 2003, используя несколько серверов GC, DNS и WINS.

Несколько серверов GC. В тех же локальной сети и сайте Windows 2003 или Windows 2000, где размещены кластеры Exchange, следует организовать два сервера GC. Если DSAccess не может установить контакт с GC-сервером, то отказывает System Attendant, вызывая передачу функций резервному узлу, так как ресурс хранилища IS зависит от ресурса System Attendant. Благодаря наличию двух серверов GC смягчаются последствия отказа одного GC-сервера. Если в сайте имеется другой GC-сервер, то Exchange обнаружит его с помощью DSAccess. Если в сайте нет доступных GC-серверов, то Exchange пытается задействовать GC-серверы других сайтов, что приводит к простою, пока DSAccess отыскивает GC-сервер. Когда DSAccess обнаруживает GC-сервер, System Attendant и ресурсы IS вновь оказываются доступными через сеть и служба восстанавливается. Клиенты Outlook также используют GC-серверы для запроса и извлечения списка глобальных адресов (Global Address List — GAL). Если GC-сервер отключается от сети, то это отрицательно влияет на сеанс Outlook. Развернув Outlook 2003 с активным режимом кэширования, можно смягчить последствия отключения GC-сервера для пользователей. При автономной работе в режиме кэширования, без связи с сервером Exchange или GC, Outlook использует автономную адресную книгу (Offline Address Book, OAB) на клиенте для доступа к информации каталога. В некоторых случаях с целью повышения гибкости используются раздельные комплекты GC-серверов: внутренние (back-end) GC-серверы поддерживают серверы Exchange, а внешние (front-end) GC-серверы обеспечивают доступ к информации каталогов для клиентов Outlook.

Несколько DNS-серверов. DNS используется в Windows 2003 и Windows 2000 для преобразования имен серверов в TCP/IP-адреса и обнаружения ресурсов. Если DNS-сервер отключается от сети, а вторичный DNS-сервер недоступен, то Exchange не может преобразовать имена серверов в TCP/IP-адреса. В результате могут возникнуть ошибки DSAccess и сбои при доставке почтовых сообщений.

Несколько WINS-серверов. WINS-серверы используются в Windows 2003 и Windows 2000 для преобразования имен NetBIOS в IP-адреса; в сетях Windows NT WINS применяется для преобразования имен. В руководстве Exchange Server 2003 Deployment Guide указывается, что WINS необходим для развертывания Exchange 2003 и Exchange 2000; Exchange Setup и ESM также используют WINS.

Конфигурация

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

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

Для доступа к параметру задержки на серверах Windows 2000 нужно щелкнуть правой кнопкой мыши на пиктограмме My Computer и выбрать пункт Properties из контекстного меню. Затем требуется нажать последовательно кнопки Advanced и Startup and Recovery. В узлах Windows Server 2003 следует открыть диалоговое окно My Computer Properties, щелкнуть на кнопке Advanced, затем на кнопке Settings в разделе Startup and Recovery. В диалоговом окне Startup and Recovery нужно выбрать пункт Display a list of Operating Systems for __ seconds и установить оптимальную продолжительность задержки (в секундах). Активному узлу можно установить задержку 5 с, а пассивному — 20 с. Можно также вручную отредактировать файл boot.ini на каждом узле, чтобы установить нужную задержку.

Комплект ресурсов операционной системы. В Microsoft Windows 2000 Server Resource Kit есть полезные инструменты для администратора кластера. В комплект ресурсов входит около 300 утилит для управления Active Directory (AD) и серверами Windows 2000, и некоторые утилиты предназначены специально для кластеров. Самые важные из них — dumpcfg.exe для управления и записи информации о сигнатурах дисков; Cluster Tool (clustool.exe) для резервного копирования и восстановления конфигурации кластера; clusrest.exe для восстановления базы данных кворума. Среди инструментов Microsoft Windows Server 2003 Resource Kit появились новые, усовершенствованные кластерные утилиты, в том числе Cluster Server Recovery Utility (clusterrecovery.exe), с помощью которой можно восстановить файлы контрольных точек ресурсов, заменить отказавший диск, восстановить диск после изменения сигнатуры или перенести данные кластера на другой его диск, и диагностический инструмент Cluster Diagnostics and Verification Tool (clusdiag.exe) для тестирования функциональности кластера, облегчающий чтение файлов журналов.

В процессе установки инструменты следует скопировать в стандартную папку на каждом узле кластера. Всегда имея под рукой нужные утилиты, можно быстрее диагностировать проблемы, возникающие в кластере. Более подробная информация об инструментах комплекта опубликована по адресу http://www.microsoft.com/windows2000/techinfo/ reskit/default.asp.

Настройка памяти. Строку инициализации серверов Exchange 2000, работающих с Windows 2000 Advanced Server или Windows 2000 Datacenter Server и оснащенных памятью более 1 Гбайт, необходимо дополнить ключом /3GB, как объясняется в статье Microsoft «XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM» (http://support.microsoft.com/?kbid=266096). Однако при использовании ключа /3GB уменьшается число записей таблицы страниц (page table entry, PTE) Free System, а это может привести к нарушению работоспособности сервера, в частности к потере сетевых соединений и появлению «голубого экрана». Специалисты Microsoft рекомендуют следить за показаниями счетчика Free System PTE в объекте Memory монитора производительности Performance Monitor. Если они падают ниже 10 000, то следует изменить параметр SystemPages раздела реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlSession ManagerMemory Management, как описано в статье Microsoft «XADM: An Exchange 2000 Server with the ?/3GB? Switch in the Boot.ini File May Lose Network Connectivity Under a Heavy Messaging Load» (http://support.microsoft.com/?kbid=313707).

Ключ /3GB может использоваться в системах Windows 2003, Standard Edition и Windows 2003, Enterprise Edition. Однако обе редакции поддерживают и новый ключ, /userva, который позволяет установить специальные размеры среды для виртуального адресного пространства приложения и назначать записи PTE из boot.ini (а не из реестра). Для серверов Exchange 2003 с оперативной памятью емкостью более 1 Гбайт следует использовать параметр /userva=3030 в сочетании с ключом /3GB. Дополнительные процедуры настройки памяти Exchange 2003 описаны в статье «How to Optimize Memory Usage in Exchange Server 2003» (http://support.microsoft.com/?kbid=815372). И Windows 2003, и Windows 2000 требуется перезагрузить после изменения параметров памяти.

Еще один способ уменьшить нагрузку на виртуальную память — свести к минимуму число групп хранения (storage group, SG). Дополнительная виртуальная память используется при смонтированной SG, но дополнительные базы данных существующих SG мало влияют на используемый объем виртуальной памяти.

Безопасность

Чтобы предотвратить распространение «червя» W32.Blaster.Worm, вируса Nimda и остановить другие сетевые атаки, необходимо защитить кластер Exchange. Вирусы заражают системы через совместно используемые файлы, браузеры, уязвимые места операционной системы и электронную почту, поэтому меры борьбы с вирусами должны охватывать все названные области. Но нужно соблюдать осторожность: при развертывании антивирусных решений для сканирования файлов необходимо исключить из области проверки файлы базы данных Exchange и транзитные файлы (в Message Transfer Agent — MTA — и корневом почтовом каталоге). Программа поиска вирусов в файлах, которая очищает или направляет в карантин базу данных Exchange или журнал транзакций, может помешать обращениям Exchange к базе данных или журналу, что приведет к порче данных. В идеальном случае антивирусная программа, сканирующая файлы, позволяет назначить исключения в процессе установки, чтобы транзитные файлы случайно не были охвачены поиском. Рекомендации Microsoft по борьбе с вирусами в Exchange приведены в статье «XADM: Exchange and Antivirus Software» at http://support.microsoft.com/?kbid=328841.

Недавно выпущенные исправления компании Microsoft защищают от W32.Blaster.Worm и устраняют другие слабые места операционной системы, используемые авторами вирусов. С помощью анализатора Microsoft Baseline Security Analyzer (MBSA) можно провести аудит узлов кластера в поисках уязвимых мест и получить список рекомендуемых исправлений для системы безопасности. Более подробную информацию о MBSA можно получить по адресу http://www.microsoft.com/ technet/security/tools/mbsahome.asp. Альтернативный способ — загрузить новейшие исправления для системы безопасности из службы Windows Update.

Доступ к встроенным разделяемым ресурсам Message Tracking Log и Address в кластере Exchange 2000 следует ограничить только чтением. По умолчанию группа безопасности Everyone имеет полный доступ к этим ресурсам с правом записи. В статье Microsoft «XADM: The Nimda Virus May Infect the Files in Log Folders on New Exchange 2000 Virtual Servers in a Cluster» (http://support.microsoft.com/?kbid=312465) описано, как изменить эти разрешения. В качестве дополнительной меры предосторожности не следует создавать разделяемых папок в кластере Exchange. По умолчанию доступ к встроенным разделяемым ресурсам Exchange 2003 ограничивается только чтением.

Для защиты кластера от почтовых вирусов следует использовать антивирусный пакет. Антивирусные продукты независимых поставщиков (например, перечисленные в списке http://www.microsoft.com/ exchange/partners/antivirus.asp) сканируют почтовые ящики в реальном времени в поисках таких вирусов, как Sobig.F и ILOVEYOU. Не забудьте составить расписание регулярных обновлений сигнатур вирусов поставщиком продукта. Специалисты Microsoft разработали интерфейс Virus Scanning API (VS API), через который антивирусные программы могут проверять такие компоненты Exchange, как базы данных, очереди SMTP и агенты MTA. Антивирусное решение должно быть совместимым с VS API и работать на кластерах.

Передача функций другому узлу

В процессе передачи функций одного узла другому (failover) кластерная группа Exchange перемещается с одного узла на другой. В это время клиенты Microsoft Outlook не могут обращаться к Exchange, поэтому сокращение времени передачи необходимо для повышения отказоустойчивости и выполнения соглашений об уровне обслуживания (service level agreements, SLA). Чтобы уменьшить негативные последствия передачи функций между узлами, можно перевести клиентов Microsoft Office Outlook 2003 в режим кэширования, при котором в отсутствие сетевого соединения пользователи работают с локальным кэшем. Режим кэширования Outlook 2003 восполняет потерю сетевого соединения гораздо эффективнее, чем прежние версии, которые приходилось перезапускать при изменениях сетевых соединений. В режиме кэширования Outlook 2003 обнаруживает нарушения связи с сервером Exchange и автоматически переключается и синхронизируется без вмешательства пользователя. Более подробно об усовершенствованиях сетевого клиента рассказано в статье «Outlook 11 и Exchange Server», опубликованной в Windows & NET Magazine/RE № 4 за 2003 г.

Экран 2. Модель ресурсов кластера для Exchange 2000

Время переключения Exchange 2003 меньше, чем Exchange 2000, благодаря лучшей модели ресурсов с плоским деревом зависимостей. На экране 2 показана модель ресурсов кластера для Exchange 2000; такие протоколы, как HTTP, могут активизироваться в оперативном режиме только после запуска ресурса Exchange Store. На экране 3 показана модель ресурсов Exchange 2003; ресурсы протоколов зависят только от ресурса System Attendant. В результате сокращается время переключения узлов, так как ресурсы кластера могут быть запущены параллельно. В Exchange 2003 предусмотрен трехминутный тайм-аут, после которого, если переключения не произошло, процесс Store завершается, чтобы ускорить передачу. Благодаря тайм-ауту переключение узлов происходит быстрее, чем в Exchange 2000.

Экран 3. Модель ресурсов Exchange 2003

Существует два типа переключений: плановые и неплановые. Как лучше выполнять операцию каждого типа? Как усовершенствовать систему, контролируя неплановые переключения?

Плановые переключения узлов. Обычно плановые переключения производятся в рамках программы обслуживания системы, например при поочередной модернизации узлов Exchange (этот процесс будет подробно рассмотрен ниже). В частности, в двухузловом кластере пакет обновлений устанавливается сначала на пассивном узле (узел 2), после чего при необходимости производится перезагрузка. После обновления узла 1 следует переместить виртуальные серверы Exchange Virtual Servers (EVS) с активного узла (узел 1) на пассивный и модернизировать узел 1. Если узел 1 — основной узел кластера, то необходима дополнительная операция переключения узлов для обратного переноса EVS на узел 1 (failback). Во время планового переключения Exchange Resource DLL (exres.dll) переводит компоненты Exchange в кластерной группе Exchange в автономный режим; демонтирует SG; останавливает работы таких протоколов, как IMAP, POP и HTTP; переводит в автономный режим ресурсы EVS Network Name и IP Address. Затем Exres.dll делает доступными через сеть на другом узле ресурсы EVS Network Name и IP Address, а следом за ними — ресурсы Exchange. Служба Cluster Service обновляет базу данных кворума.

Время планового переключения узлов можно сократить, если выполнять его в нерабочие часы. В рабочее время нагруженный сервер Exchange может обслуживать до 3000 соединений Messaging API (MAPI), каждое из которых должно быть завершено во время переключения узлов. В нерабочие часы число соединений резко понижается. Время переключения сокращается и в режиме кэширования Outlook благодаря более эффективному использованию сети.

После применения пакета обновлений Windows процесс Store перестраивает индексы, и время переключения узлов на несколько минут увеличивается. Длительность задержки зависит от размера базы данных Exchange. Событие Event ID 611 в журнале событий Application означает, что идет перестройка индекса.

Неплановое переключение узлов. Неплановое переключение происходит в случае аварии или нарушений питания узла, на котором размещены серверы EVS. Если активный узел (узел 1) отказывает, то служба Cluster Service обнаруживает отсутствие контрольных сообщений в линии, а следовательно, связи с активным узлом, и открывает сетевой доступ к ресурсам IP Address и Network Name серверов EVS на пассивном узле (узел 2). Диски, принадлежащие EVS, переключаются в оперативный режим на узле 2. Exres.dll переключает в оперативный режим ресурсы кластера Exchange. Store монтирует группы хранения (SG) и выполняет восстановление. Обновляется база данных кворума. Если узел 1 — привилегированный владелец кластера, то будет выполнена обратная операция переключения, чтобы вернуть EVS на узел 1 после его возвращения в оперативный режим.

Значительно сократить время непланового переключения узлов нельзя. Однако если один из узлов кластера объявлен основным и в кластере происходит переключение узлов, то, по крайней мере, можно назначить операцию обратного переключения на нерабочее время. Чтобы составить график переключения узлов, следует щелкнуть правой кнопкой мыши на Exchange Group в Cluster Administrator, выбрать пункт Properties и вкладку Failback. Выберите режим Allow failback и укажите временной интервал переключения (по 24-часовому графику) в разделе Failback between ___ and ___ hours. Следует выбрать время, на которое не назначено выполнение других операций, таких как резервное копирование и дефрагментация оперативной базы данных. Эти задания будут отменены при обратном переключении узлов, в ходе которого производится демонтирование и повторное монтирование баз данных Exchange.

Время неплановых переключений можно сократить, если кластер используется в качестве внутреннего (back-end) компонента системы обработки сообщений. В статье Microsoft «How to Configure IPSec on an Exchange Server 2003 Back-End Server That Is Running on a Windows Server 2003 Server Cluster» (http://support.microsoft.com/?kbid=821839) описаны процедуры для более быстрого переключения внутренних виртуальных серверов, работающих в кластерах Windows 2003 с Exchange 2003 и использующих IP Security (IPSec) для защиты трафика между внешним (front-end) и внутренним сервером.

Мониторинг. Один из лучших способов уменьшить частоту и время неплановых переключений узлов — постоянно собирать и анализировать текущие данные о рабочих характеристиках. И Windows, и Exchange располагают встроенными инструментами мониторинга. Мониторинг крупных рабочих систем упрощается благодаря применению таких инфраструктур управления, как Microsoft Operations Manager — MOM. Перед авариями в журналы событий Windows и Exchange вносятся записи об аппаратных и программных неполадках. Например, сообщение с ID 9582 свидетельствует о фрагментации виртуальной памяти, описанной во врезке «Мониторинг виртуальной памяти» в статье «Кластеры на базе Exchange 2003», опубликованной в Windows & .NET Magazine/RE № 8 за 2003 г. Активный мониторинг журналов событий, рабочих характеристик дисков, использования памяти позволяет предотвратить многие аварии, или по крайней мере отсрочить их до такого момента (времени суток), когда они затронут меньшее число пользователей.