Планирование, выполнение и решение проблем

Многие администраторы видят в возможности выполнять последовательную модернизацию на кластере основное преимущество внедрения кластеров Exchange Server. Если в компании используется Exchange 2000 Server, следует знать об изменениях в Exchange Server 2003, которые вносят некоторую сложность в процедуры обновления кластера Exchange 2000 до Exchange 2003, а также обновления кластера Exchange 2003 до Exchange 2003 Service Pack 1 (SP1) или старше. Это относится и к применению исправлений, которые изменяют номер сборки файла exsetdata.dll. Разобраться в этих изменениях необходимо до планирования и выполнения обновления. Некоторые высказанные в этой статье идеи относительно решения проблем также пригодятся для успешного выполнения поставленной задачи. Статья требует базовых знаний по технологии кластеров Microsoft и понимания различий внедрения кластерных и одиночных серверов Exchange. Врезка «Последовательная модернизация кластера» содержит полезную информацию по этой теме.

Изменения

Разработчики Microsoft с выпуском Exchange 2003 и Exchange 2003 SP1 внесли некоторые изменения в модель последовательной модернизации кластера. При обновлении Exchange 2000 требовалось просто обновить файлы на каждом узле. Обновление Exchange 2003 до SP1 или старше требует решения дополнительных задач. После выполнения модернизации на одном узле необходимо с помощью Cluster Administrator перевести Exchange Virtual Server (EVS) в режим Offline, а затем перенести EVS на уже обновленный узел. После этого следует щелкнуть правой кнопкой на ресурсе System Attendant и выбрать Upgrade Exchange Virtual Server. Эта процедура обновляет данные, ассоциированные с EVS в Active Directory (AD) для соответствия новой версии Exchange.

Если в сети работает кластер Exchange с более чем одним EVS, следует в один момент времени обновлять только один EVS. Это требование применимо к кластерам типа активныйактивный и к кластерам типа активныйпассивный. Процедура модернизации использует глобальную переменную (g_csCachedXSes), которая может быть изменена только один раз во время сессии обновления программного обеспечения. В статье Microsoft «Setup Stops Responding When You Upgrade Multiple Exchange Server Virtual Servers at the Same Time» поясняется, что надо делать, если запуск обновлений EVS выполнялся параллельно.

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

Прежде чем проводить модернизацию до Exchange 2003 SP1, следует определиться с теми элементами, которые будут изменены (описанные требования подходят и к некластеризованным серверам Exchange).

Можно выполнять обновление до SP1, и в это время пользователи могут работать в Microsoft Office Outlook 2003 в режиме Cached Exchange Mode. Cached Exchange Mode уменьшает видимое время простоя, поскольку пользователи продолжают работать автономно, имея кэшированную копию почтового ящика. Процедура обновления включает две фазы, требующие отключения EVS. Пользователи Outlook заметят простой, если виртуальный сервер EVS остановить на одном узле и не активизировать на другом. Перенос ресурсов с активизацией на другом узле является стандартной процедурой в случае сбоя. О том, как сократить время «переезда» ресурсов, рассказано в статье «Как улучшить работу кластера Exchange», опубликованной в Windows IT Pro/RE № 5 за 2004 год. Исходя из опыта можно сказать, что время простоя при переводе EVS на другой узел составляет от 3 до 6 минут. Если соглашение об уровне обслуживания (Service Level Agreement, SLA) позволяет, рекомендуется отвести 30 минут на время простоя для установки пакета обновлений. Exchange не будет недоступен все это время, но периодически его придется отключать для тестирования процедуры миграции на другой узел. Если есть возможность запланировать час простоя, сделайте это! В случае проблем во время модернизации будет дополнительное время на их решение. Также можно ограничить нарушения работоспособности во время простоя, установив соответствующее исправление в системе безопасности Windows. Для этого следует загрузить исправление 831464 для Windows 2003 с сайта Microsoft, которое требуется развернуть до установки Exchange 2003 SP1. Это исправление решает проблему предоставления информации для отображения клиентам Outlook Web Access (OWA).

Для обновления кластера Exchange 2003 необходимо использовать учетную запись с правами Exchange Full Administrator в соответствующей административной группе с EVS, причем эта учетная запись должна быть в составе локальной группы администраторов на каждом узле. Более подробную информацию о требованиях к правам доступа можно найти в материалах Microsoft «Working with Active Directory Permissions in Exchange Server 2003». Управление правами доступа можно упростить, если создать группу с типом Security для администраторов кластера Exchange. Например, можно создать группу Exchange ClusterAdmins, делегировать права Exchange Full Administrator этой группе и добавить ее в группу Local Administrators на каждом узле кластера. Если требуется добавить узел в кластер, то понадобится только добавить группу ExchangeCluster Admins в группу Local Administrators на узле, вместо того чтобы добавлять для каждого администратора учетные записи. Если возникнет необходимость отстранить кого-нибудь от администрирования кластера, достаточно будет просто удалить его учетную запись из группы ExchangeClusterAdmins. Кроме того, сэкономит время еще и то, что не потребуется удалять индивидуальные учетные записи из групп Local Administrators на каждом узле, чтобы лишить кого-то прав на управление Exchange.

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

Статья Microsoft «How to obtain the latest service packs for Exchange Server 2003» содержит дополнительную информацию о последнем пакете обновлений для Exchange 2003. Важно учесть, что если в организации используется архитектура с внешними и внутренними (Front-end/Back-end) серверами Exchange, то обновления следует начинать с внешних серверов.

Установка пакета обновлений

В статье Microsoft «How to install Exchange Server 2003 Service Pack 1 in a clustered Exchange environment» описывается процедура установки Exchange 2003 SP1 на кластере. Рассмотрим детально процедуру для двухузлового (Node1 и Node2) кластера Exchange 2003, работающего в режиме активныйпассивный, с одним EVS (EVS1). Node1 является активным и текущим владельцем EVS1.

Если исправление 831464 на Node2 еще не установлено, следует его установить и перезагрузиться. Когда Node2 подключится к кластеру, можно устанавливать на этом узле Exchange 2003 SP1.

Для установки обновления требуется переключить EVS1 в режим Offline, но ресурсы Network Name, IP Address и ресурсы хранилищ, ассоциированных с EVS, оставить в активном режиме. Для этого нужно щелкнуть правой кнопкой на ресурсе System Attendant и выбрать Take Offline (экран 1). Это действие переведет в автономный режим ресурсы Exchange, зависимые от System Attendant (например, ресурсы, относящиеся к Information Store, протоколам IMAP и POP). Перенесите кластерную группу Exchange, ассоциированную с EVS1, с Node1 на Node2.

Затем нужно зайти на Node2 и открыть Cluster Administrator. Если ресурсы Exchange, касающиеся EVS, находятся в режиме Offline, следует правой кнопкой щелкнуть на ресурсе System Attendant и выбрать Upgrade Exchange Virtual Server. Надо отметить, что эту процедуру нельзя выполнить из Cluster Administrator, работающего на Node1, поскольку требуется, чтобы текущим узлом был тот, на котором прошла процедура установки обновления. Требование выполнять дополнительное действие при процедуре установки пакета обновлений Exchange через Cluster Administrator стало новинкой в Exchange 2003 (впервые оно появилось в процедуре обновления кластера Exchange 2000 на Exchange 2003). Когда процесс обновления завершится, должно появиться сообщение The Exchange Virtual Server has been upgraded successfully.

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

На данном этапе файлы SP1 установлены на Node2, и объекты AD, относящиеся к EVS, обновлены и показывают, что EVS работает с SP1. Это изменение можно проверить через Exchange System Manager (ESM), посмотрев версию сборки EVS (экран 2). Exchange 2003 SP1 имеет номер сборки 7226.6.

Node1 содержит младшую версию сборки файлов Exchange и поэтому перенести обновленный EVS на данный узел не удастся. Если попытаться это сделать, будет выведено сообщение об ошибке Version of Exchange on this machine does not match the version of Exchange server NodeName. Далее следует установить исправление 831464 на Node1 и перезагрузиться. Когда Node1 загрузится, нужно установить Exchange 2003 SP1.

Для подтверждения успешной модернизации следует перенести EVS1 на Node1 и убедиться, что на данном узле Exchange стартовал без ошибок. В случае Exchange 2000 это делать необязательно, поскольку все узлы в кластере работают с одной и той же версией программного обеспечения, но полезно для проверки корректности установки.

Необходимо выполнить резервное копирование узлов кластера Exchange, состояния системы каждого узла и полное резервное копирование баз данных Exchange. Дело в том, что восстановить базы данных, созданные младшей версией Exchange, не получится. Когда Exchange 2003 подключает базы данных, в них отмечается, что с ними работала новая версия ядра Extensible Storage Engine (ESE), осуществляющая логическое взаимодействие IS с низкоуровневым процессором баз данных Jet.

Описанная процедура подходит и для кластеров с количеством узлов более двух. Однако таким кластерам свойственны некоторые ограничения по отказоустойчивости. Кластеры, имеющие более двух узлов, могут поддерживать только один EVS на узле в один момент времени. Любые попытки перенести второй EVS на узел с уже существующим EVS приведут к появлению сообщения об ошибке An error occurred attempting to bring the System Attendant resource online: The cluster resource could not be brought online by the resource monitor. Error ID: 5018 (0000139a). В статье Microsoft «XADM: Exchange Virtual Server Limitations on Exchange 2000 Clusters and Exchange 2003 Clusters That Have More than Two Nodes» описывается такое вынужденное ограничение.

Расширим пример добавлением еще двух узлов (Node3 и Node4) и второго EVS (EVS2) в наш кластер. Node3, Node4 и EVS2 работают с Exchange 2003 без пакета обновлений. Node1, Node2 и EVS1 были обновлены до Exchange 2003 SP1, и EVS1 активирован на Node1.

Переведем кластерный ресурс EVS2 в режим Offline. Перенесем EVS2 с Node3 на Node2 (перенести EVS2 на Node1 нельзя, поскольку на этом узле уже поддерживается EVS1). Далее следует щелкнуть правой кнопкой на ресурсе Exchange System Attendant для EVS2 и выбрать Upgrade Exchange Virtual Server для обновления в AD информации о EVS2. Когда обновление завершится, появится сообщение The Exchange Virtual Server has been upgraded successfully.

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

EVS1 и EVS2 теперь обновлены до Exchange 2003 SP1 и работают на Node1 и Node2 соответственно. Для завершения установки обновления надо обновить файлы Exchange на Node3 и Node4. Необходимо установить исправление 831464 на Node3 и Node4 и затем перезагрузить эти узлы. Установите Exchange 2003 SP1 на Node3 и Node4 и опять перезагрузите узлы. Когда Node3 подключится к кластеру, нужно перенести EVS2 на Node3. Проверим системный журнал приложений и убедимся, что Exchange запустился корректно. Затем следует перенести EVS2 с Node3 на Node4 для проверки корректной отработки переноса приложения на другой узел в случае сбоя. Опять проверим журнал приложений, чтобы убедиться в успешном запуске Exchange. В завершение необходимо выполнить полное резервное копирование баз данных EVS2 и резервное копирование Node3 и Node4.

Советы по решению проблем

Как упоминается в материале «How to install Exchange Server 2003 Service Pack 1 in a clustered Exchange environment», во время выполнения обновления проблемы могут возникнуть дважды. Рассмотрим эти случаи подробнее.

Если в Cluster Administrator пункт Upgrade Exchange Virtual Server недоступен, сначала следует определить, находится ли EVS на обновленном узле. Если это не так, нужно попробовать перенести EVS на обновленный узел. Другой возможной причиной может быть то, что Cluster Administrator запущен на еще не обновленном узле, поэтому надо зарегистрироваться на обновленном узле и там запустить Cluster Administrator. Если эти варианты не подходят, следует проверить, не запущен ли Cluster Administrator на сервере, который не является частью кластера.

Если процедура Upgrade Exchange Virtual Server завершается с сообщением об ошибке ID c1037b44, нужно проверить, работает ли EVS на узле с соответствующим пакетом обновлений Exchange. Также необходимо убедиться, что следующие кластерные ресурсы Exchange для текущего EVS находятся в активном состоянии:

  • Exchange System Attendant;
  • Exchange HTTP Virtual Server Instance;
  • Exchange Information Store Instance;
  • Exchange MS Search Instance;
  • Exchange POP3 Virtual Server Instance;
  • Exchange Routing Service Instance;
  • SMTP Virtual Server Instance.

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

  • Ресурс IP Address для EVS;
  • Ресурс Network Name;
  • Ресурсы Physical disk, используемые в EVS.

Наконец, следует просмотреть файл журнала установки Exchange (файл exchange server setup.log находится на том же диске, что и каталог winnt или windows). Этот журнал играет важную роль при решении проблем, возникших во время процесса установки. Большая часть информации в этом файле понятна только разработчикам Exchange, но она поможет разобраться с тем, что происходило во время процесса обновления. На экране 3 показан фрагмент этого журнала.

Последний совет

После сравнения моделей обновления кластеров Exchange 2000 и Exchange 2003 мы можем утверждать, что Exchange 2003 не поддерживает режим последовательной модернизации кластеров для пакетов обновлений Exchange. А именно: каждый EVS должен быть в режиме Offline для обновления данных в AD о EVS, а это дополнительное время простоя, которое отражается на времени работы почтовой системы (и на SLA). Кроме того, каждая дополнительная задача повышает риск совершить ошибку во время установки обновлений. Одним из путей, снижающих такой риск, является создание тестового EVS в кластере. Следует подождать день или два до запланированной процедуры обновления, пока информация об этом EVS распространится в инфраструктуре Exchange и AD. После обновления одного узла в кластере можно протестировать обновление EVS, используя тестовый EVS, прежде чем предпринимать попытку обновления промышленного сервера EVS.

Дарах Моррисcи - Консультант группы Technology Leadership Group компании HP, работающий в Дублине, Ирландия. С ним можно связаться по адресу: daragh.morrissey@hp.com

Последовательная модернизация кластера

Последовательная модернизация кластера позволяет выполнять обновление программного обеспечения на пассивном узле кластера Microsoft, в то время как на других узлах кластера серверы Exchange Virtual Servers (EVS) находятся в активном режиме. Последовательная модернизация кластера позволяет уменьшить плановое время простоя во время обновления программного обеспечения, необходимого для развертывания исправлений для системы безопасности, пакетов обновлений или дополнительных средств (например, средств мониторинга). Такой тип обновления также позволяет модернизировать BIOS или Firmware. Последовательная модернизация имеет ограничения: некоторые продукты независимых поставщиков, такие как антивирусные сканеры, не поддерживают последовательной модернизации, требуя выполнения обновления на активном узле, пока EVS находится в режиме Offline. Кроме того, миграция на другой узел во время сбоя может выполняться некорректно, пока все узлы кластера не будут иметь идентичные версии программного обеспечения.

Exchange 2000 Server также позволяет устанавливать пакеты обновлений с использованием модели последовательной модернизации. Приведенная ниже последовательность шагов описывает процедуру обновления на двухузловом кластере, работающем в режиме активныйпассивный, где активным является Node1, а пассивным Node2, и поддерживается один EVS (EVS1):

  1. Применить пакет обновлений Exchange на Node2.
  2. Переместить EVS1 на Node2, а затем применить пакет обновлений Exchange на Node1.
  3. Переместить EVS1 на Node1 (необязательно).

Шаг 3 необязателен, поскольку в приведенном примере все узлы кластера уже работают с новым пакетом обновлений. Однако для того, чтобы убедиться в работоспособности процедуры реакции на сбой и в том, что пакет обновлений нормально установился на Node1, лучше переместить EVS на первый узел.