Построение Exchange 2000 на кластере

Часть 2

Проектирование хранилища - прежде всего

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

При настройке Exchange 2000 в кластерной среде необходимо тщательно спланировать дисковые тома, которые предстоит сделать разделяемыми для узлов кластера. «Разделяемые» не означает, что системная служба Cluster будет работать в режиме, не предусматривающем одновременный доступ (т. е. когда только один член кластера в текущий момент может получить доступ к тому). Механизм общего хранилища для службы Cluster, технология Storage Area Network (SAN), обеспечивает большую масштабируемость, надежность и производительность. Это позволяет должным образом спроектировать хранилище и расположить его в кластерной среде. Знакомясь с технологией SAN, также придется изучить такие понятия, как репликация данных и Business Continuance Volumes (BCV).

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

Во-первых, нужно понять, как будет распределяться пользовательская нагрузка на кластере. Пусть предполагается поддержка 10 000 пользователей на четырех узлах кластера Exchange 2000 (только Windows 2000 Datacenter Server поддерживает четырехузловой кластер). При равномерном распределении пользователей на кластере можно разделить их по 2500 на узел. При этом есть возможность для каждого узла определить отдельные требования к производительности и отказоустойчивости для своих 2500 пользователей. Требования можно устанавливать, основываясь на общепринятом соглашении об уровне обслуживания SLA (service level agreements).

Во-вторых, следует определиться со сценариями восстановления после сбоя и тем, что для этого требуется в конфигурации кластера. Первый промышленный выпуск (RTM) Enter-prise Server ограничивал количество групп хранения SG по четыре штуки на узел кластера. Следовательно, одновременно на узле кластера могли работать не более четырех SG Exchan-ge Server. Это ограничение очень важно для отказоустойчивости кластера. Когда происходит сбой и EVS переносится на другой узел, общее количество SG не должно быть больше четырех. Возможно, это ограничение не будет свойственно последующим версиям Exchange Server, когда станет доступной 64-разрядная адресация памяти. Однако пока оно сохраняется, и это нужно учитывать при проектировании кластера. Для всего кластера необходимо разработать правила отказоустойчивости с учетом ограничения в четыре SG на узел.

Далее следует определить, сколько пользователей помещать в SG. Один EVS может содержать множество SG, и это надо учитывать, чтобы не превысить ограничение на количество групп при нормальной работе и в случае сбоя. Например, простейший способ разместить 10 000 пользователей на кластере - это создать один EVS на узле и одну SG в EVS (соотношение 1:1). Такое соотношение позволяет на одном EVS с одной SG обслуживать 2500 пользователей на узле кластера (если кластер состоит из 4-х узлов).

Продолжая проектирование «от обратного», следует определить требования к хранилищу и конфигурации каждого узла кластера. Для этого надо ознакомиться с методами увеличения производительности операций ввода/вывода (см. врезку «Повышаем производительность операций ввода/вывода»), чтобы оптимально распределить последовательные и случайные операции ввода/вывода. На Рисунке 1 показан пример кластера с четырьмя узлами для поддержки 10 000 пользователей.

Требования к установке и настройке новых кластеров

Этап установки кластера Exchange 2000 относительно прост. Однако для его успешного завершения важно понимать, как происходит этот процесс. Основные отличия между кластером Exchange 2000 и кластером Exchange Server 5.5 заключаются в размещении устанавливаемых файлов. Установка Exchange 2000 не нуждается в размещении файлов на диске с общим доступом для всего кластера. Exchange 2000 может работать в режиме active/active на всех узлах кластера, а это означает, что каждый сервер в кластере должен иметь локальные копии исполняемых файлов.

В процессе инсталляции Exchange 2000 программа установки определяет конфигурацию кластера и запрашивает подтверждение записи программного обеспечения на каждом узле кластера. После этого процесс инсталляции расширяет схему Active Directory (AD), если она еще не была обновлена. Можно обновить схему AD перед установкой сервера Exchange 2000 (дополнительную информацию о расширении схемы AD для Exchange 2000 можно найти в статье Тони Редмонда «Exchange 2000 Server и Active Directory», опубликованной во втором номере журнала за 2000 г.). После того как Exchange 2000 будет установлен на узле, узел следует перезагрузить.

После установки на первом узле кластера нужно продолжить установку на остальных узлах. Здесь можно использовать те же настройки. Во время последовательных инсталляций Exchange 2000 программа установки определяет конфигурацию кластера и проверяет наличие Exchange Server. Поэтому не следует производить инсталляцию на нескольких узлах кластера одновременно.

Для управления EVS используется расширение консоли MMC, называемое Exchange System Manager (ESM). Прежде чем виртуальный сервер EVS будет виден в ESM, его следует создать на кластере. Для этого нужно вручную настроить соответствующую ресурсную группу. Каждая ресурсная группа должна содержать как минимум ресурс «IP-адрес», ресурс «сетевое имя» (т. е. то имя, которое использует для EVS в организации Exchange 2000 и доступно пользователям по сети) и один или более дисковых ресурсов, на которых EVS будет размещать файлы регистрации транзакций, базу данных и временные файлы. В созданную ресурсную группу нужно добавить ресурс Exchange System Atten-dant. Программа Cluster Admini-strator использует библиотеку Ex-change Cluster Administrator (т. е. excluadm.dll) для создания других ресурсов, которые понадобятся EVS. Cluster Administrator, создавая ресурсы, запрашивает у Exchange System Attendant ресурсную зависимость. Эта зависимость должна включать все используемые дисковые ресурсы (дополнительную информацию о ресурсной зависимости можно найти в первой части данной статьи). Перед созданием EVS все дисковые ресурсы надо настраивать. Это требование является основным при проектировании хранилища на стадии планирования кластера. Программа запросит путь к каталогам данных (изначально можно принять диск и каталог, предлагаемые по умолчанию, а в дальнейшем изменить их, используя ESM для перемещения файлов регистрации транзакций и баз данных на другие диски или в другие каталоги). Далее, если существуют административные или маршрутные группы, программа запросит их. Эти группы доступны только в том случае, если Exchange 2000 устанавливается в режиме Native (т. е. организация Exchange формируется только из серверов Exchange версии 2000).

Обновление существующих кластеров

Документация по Exchange 2000 содержит описание модернизации кластера Exchange Server 5.5 до кластера Exchange 2000. Если будет меняться или обновляться аппаратное обеспечение, проводить обновление Exchange не следует. При таком сценарии рекомендуется использовать перенос почтовых ящиков. Также следует иметь в виду, что сначала необходимо перейти на Windows 2000.

Стратегия обновления кластера на том же оборудовании. Если стоимость или другие условия требуют модернизировать кластер на том же аппаратном обеспечении, следует внимательно рассмотреть все аспекты этого процесса и протестировать обновление в лабораторных условиях на стенде, чтобы уменьшить вероятность сбоя. Не стоит начинать эту процедуру без соответствующей подготовки. Также следует предусмотреть план отмены внесенных изменений в случае сбоя или других проблем, чтобы не потерять данные пользователей. Когда выполняется обновление кластера Exchange Server 5.5 на том же оборудовании на кластер Exchange 2000, происходит удаление системных файлов с общих кластерных дисков и установка системных файлов Exchange 2000 на каждом узле кластера. Процедура обновления настраивает Exchange Server для использования существующего (т. е. оставшегося от Exchange Server 5.5) хранилища Information Store (т. е. файлов priv.edb и pub.edb) с сохранением общего ресурса. Созданный виртуальный сервер EVS надо перевести в рабочий режим для обновления данных, расположенных в этих хранилищах.

Процесс обновления данных конвертирует базу данных из формата Exchange Server 5.5 Extensible Storage Engine (ESE) в формат Exchange 2000. Он может продолжаться длительное время в зависимости от размера базы данных Exchange Server 5.5.

Стратегия переноса почтовых ящиков. Эта стратегия подразумевает добавление кластера Exchange 2000 в тот же почтовый узел, в котором находится кластер Exchange Server 5.5. Хотя такая процедура обходится дороже (требуется новое программное и аппаратное обеспечение), многие организации выбирают именно ее, так как она достаточно проста, выполняется последовательно и сопряжена с минимальным риском потери данных.

Так как служба Site Replication Service (SRS), необходимая Exchange 2000 для работы в одном узле с Exchange Server 5.5, в кластерной конфигурации не поддерживается, в узле нужно предварительно установить сервер Exchange 2000 как обычно (не на кластере). Затем можно будет переносить пользовательские почтовые ящики и общие папки с кластера Exchange Server 5.5 на кластер Exchange 2000. Для этого надо воспользоваться Microsoft Exchange Administrator, оснастками MMC Active Directory Users and Computers или утилитой Exmerge (следует помнить, что при использовании Exmerge назначенные разрешения теряются).

Стратегия переноса почтовых ящиков является оптимальной для выполнения миграции с кластера Exchange Server 5.5 на кластер Exchange 2000. Эта стратегия позволяет минимизировать риск потери информации и не требует сложной процедуры восстановления в случае сбоя. Недостаток переноса почтовых ящиков в том, что параллельно должны работать две системы, требующие дополнительных инвестиций в аппаратное и программное обеспечение. Не надо забывать о других этапах миграции на Exchange 2000 (таких, как перенос учетных записей с Windows NT 4.0 на AD и установка Active Directory Connector, ADC), которые уже должны быть выполнены. Однако после того, как все личные и общие данные с кластера Exchange Server 5.5 будут перенесены на кластер Exchange 2000 и на новом сервере будут обновлены пользовательские настройки, кластер Exchange Server 5.5 из общей системы можно удалить. Вполне возможно, правда, что только после того, как будут выполнены еще некоторые дополнительные требования, как в случае, если Exchange Server 5.5 был первым сервером почтового узла.

Повышение сложности

Многие системные администраторы и менеджеры опасаются трудностей, связанных с обслуживанием кластерного Exchange Server. Разработчики Microsoft сделали администрирование кластера Exchange Server таким же, как для одиночного сервера. На Экране 1 представлено окно менеджера ESM с кластером из четырех узлов. Оно выглядит так же, как и при использовании одиночного сервера. Взаимосвязь Exchange 2000 и службы каталога AD упрощает процесс администрирования. Добавление и удаление пользователей, управление хранилищем и другие административные функции не различаются в случае кластерной среды и одиночного сервера. Назначение прав также производится аналогично. Однако, несмотря на схожесть, некоторые аспекты кластера Exchange 2000 вносят изменение в обычные процедуры администрирования.

Экран 1. Окно менеджера ESM в случае кластера.

Администрирование ресурсов. Основное отличие проявляется в управлении службами Exchange Server. Управление ресурсами кластера является следующей ступенью по сравнению с управлением простыми службами. Изучение кластерных ресурсов позволит успешно управлять кластерными приложениями. Прежде чем устанавливать кластер Exchange 2000, следует изучить особенности кластеров и служб Windows 2000 и тонкости работы Exchange 2000 на кластерной платформе.

Планирование нагрузки. Другим отличием управления является планирование нагрузки кластера. Существует три основные стратегии планирования нагрузки: максимальная загрузка всех узлов, максимальная нагрузка и ожидающий узел (т. е. отказоустойчивость по формуле количество узлов + 1) и сбалансированная нагрузка кластера (тут возможны два варианта - каскадная и распределенная отказоустойчивость). Выбор стратегии зависит от нескольких факторов. Можно выбрать стратегию ожидающего узла, если есть необходимость в простой схеме отказоустойчивости. При этом один узел всегда будет готов к отказу. Можно выбрать стратегию сбалансированной нагрузки - при каскадировании работа продолжается при отказе нескольких узлов. В этом случае EVS защищаются от отказа многих узлов. Стоимость системы, необходимая производительность, архитектура хранилища и требования к управлению - вот факторы, которые могут повлиять на окончательный выбор. Каждая стратегия имеет слабые и сильные стороны, и каждая требует времени на изучение и тестирование. В разделе документации Exchange 2000, посвященном кластеру, описаны стратегии планирования нагрузки.

Резервное копирование и восстановление. Планирование стратегии резервирования и восстановления является частью программы ввода в эксплуатацию Exchange 2000. Для кластерной среды следует дополнительно продумать требования к отказоустойчивости системы. Многие решения основаны на вариантах не для программного обеспечения кластера, и требуется только определить расписание выполнения резервирования. Для резервирования и восстановления Exchange Server рекомендуется оперативный режим (программа резервирования работает с IS с помощью API). Могут использоваться те сценарии восстановления кластера Exchange Server, которые применяются для одиночного компьютера с Exchange Server. Независимо от того, локально установлены устройство резервирования и программное обеспечение или удаленно, это усложняет кластерную среду Exchange Server. Необходимо изучить аспекты влияния на кластер процедур резервирования и восстановления. Придется разрабатывать другую методику и новые процедуры для кластерного Exchange Server, так как восстанавливать только ОС и Exchange Server недостаточно. Чтобы выбрать лучший сценарий восстановления кластерной системы после сбоя, следует проконсультироваться с представителями компаний, обеспечивающих техническую поддержку используемого программного и аппаратного обеспечения.

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

Полезные советы

Многие организации пока не устанавливают Exchange 2000 в ожидании лучших решений для ввода системы в эксплуатацию и ее сопровождения. Я надеюсь, приведенные здесь рекомендации помогут сгладить сложности, связанные с установкой и освоением этой системы.

Корректно назначайте права. Представьте учетной записи Ex-change Admin те же права, что и учетной записи службы Cluster (которая должна иметь права Exchange Full Admin). Создание и управление EVS требует прав Exchange Full Admin. Назначать соответствующие права можно с помощью программы Ex-change Delegation Wizard.

Используйте стандартизованные и простые имена и адреса IP. Узлы кластера и службы, которые на них работают, требуют уникальных имен и адресов IP. Служба Cluster требует статических адресов IP для кластера, узлов и системных служб. Другими словами, для этих целей нельзя использовать DHCP. Кроме того, каждому EVS необходим уникальный адрес IP. Поэтому следует определить адреса IP для всех узлов и служб (таких, как EVS) прежде, чем устанавливать Exchange 2000. Структура этих адресов определяет степень сложности дальнейшей настройки и управления узлами и службами. Аналогично на простоту настройки и управления влияют имена узлов и виртуальных серверов EVS. В Таблице 1 показана примерная стратегия адресации IP и именования для четырехузлового кластера Exchange 2000. Надо отметить, что адреса IP для узла и для EVS являются последовательными.

Настройка владельцев ресурсов и отказоустойчивость. Когда настраивается EVS, Cluster Administrator автоматически представляет всем узлам кластера Exchange 2000 права Possible Owner («Возможный владелец») для каждого ресурса. Если же ресурс создается до того, как узел присоединяется к кластеру или до установки Exchange 2000 на узле, то в свойствах ресурсов EVS данный узел не попадет в список возможных владельцев. В такой ситуации необходимо будет вручную настроить свойства ресурса, чтобы узел мог нормально отрабатывать ситуацию отказа. Надо быть внимательным, когда идет настройка аппаратного обеспечения (т. е. дисков и сети), адресации (т. е. IP и сетевых имен) и ресурсов Exchange Server (таких, как System Attendant), так как Cluster Administrator предоставляет всем этим ресурсам права Possible Owner. При настройке отказоустойчивости и создании сценариев восстановления следует перечислить все узлы (в том порядке, в каком планируется осуществлять обработку сценария восстановления) в каждой ресурсной группе в окне Cluster Administrator Preferred Owners. Это обеспечит нормальное выполнение операций обработки отказа и восстановления.

Аккуратно удаляйте EVS и системные файлы из кластера. Когда из кластера удаляется Exchange Server, надо соблюдать осторожность, чтобы не нарушить работоспособность узлов. При удалении EVS прежде всего следует кластерную группу перевести в автономный режим (offline). Далее требуется удалить ресурсы Exchange Server. При удалении ресурса System Attendant, Cluster Administrator удаляет все остальные ресурсы (в порядке их зависимости). После того как AD автоматически обновится в соответствии с изменениями, виртуальные серверы EVS больше не будут отображаться в ESM. В заключение, для удаления исполняемых файлов и библиотек Exchange с узлов кластера надо будет запустить программу установки Exchange 2000 и указать пункт «Удаление». Программа выдаст запрос об удалении кластерных ресурсов Exchange Server, но делать это надо только в том случае, когда удаление происходит на последнем узле с работающими службами Exchange Server.

Разработайте структуру хранилища, прежде чем настраивать кластер. Так как Exchange 2000 поддерживает на кластере в режиме active/active множественные группы SG и базы данных, следует очень внимательно отнестись к разработке структуры хранилища. Необходимо рассмотреть все аспекты при настройке кластера. В кластере Exchange 2000 группы SG являются подуровнем EVS, и каждая SG должна отрабатывать отказ вместе с EVS. Это требование отражается на структуре хранилища. Если будет выбрано решение, основанное на повышении производительности, то следует расположить на различных физических дисковых массивах файлы регистрации транзакций и базы данных. При этом каждая SG должна иметь как минимум два массива (один для транзакций и второй для данных), чтобы обеспечить необходимый уровень независимости и детализации при обработке ситуации отказа. Следует аккуратно распределить EVS по SG. Особое внимание надо уделить имеющемуся в Exchange 2000 ограничению на количество SG в узле, до и после сбоя их должно быть более четырех на узел. При разработке структуры хранилища следует начать с требований SLA для достижения необходимого уровня обслуживания.

Новые возможности

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

(Окончание.)

Джерри Кохран - автор редакторской колонки в новостных выпусках Exchange Administrator UPDATE. Старший консультант по технологиям в группе Applied Microsoft Technologies Group в Compaq Global Services. С ним можно связаться по адресу: jerry.cochran@compaq.com.

Повышаем производительность операций ввода/вывода

назад

назад