 |
|
|
|
Разворачиваем кластер Microsoft Exchange
Разворачиваем кластер Microsoft Exchange Надежность – зачастую основное требование, которое предъявляется к любой системе. Не являются исключением и различные информационные системы, например сервис электронной почты. Один из наиболее распространенных способов обеспечения отказоустойчивости этой службы – почтовый кластер Microsoft Exchange. Вступление к продолжению Сервис электронной почты является неотъемлемой частью бизнес-процессов в любой компании, независимо от ее размеров. А такие мощные почтовые системы, как Microsoft Exchange или Lotus Domino, предоставляют, помимо отправки и приема почтовых сообщений, также средства планирования и организации бизнеса. Очевидно, что при таком положении вещей почтовая система становится, пожалуй, самым критичным сервисом, и даже минутный простой этой системы чреват большими неприятностями для системных администраторов. Возможным решением проблемы отказоустойчивости является использование кластеров. Сегодня я расскажу о развертывании и обслуживании кластеров Microsoft Exchange. Материал является продолжением статьи [1], посвященной кластерам на базе Microsoft. Когда кластер не поможет… Так как внедрение кластерных систем связано с определенными, иногда весьма серьезными финансовыми затратами, прежде чем приступать к описанию технологии, мне бы хотелось обсудить такой вопрос: от каких проблем помогают кластеры, а от каких – нет? Кластерные технологии предоставляют отказоустойчивость, но не гарантируют ее. Другими словами, несмотря на использование данной технологии вам не стоит забывать о таких вещах, как регулярное резервное копирование, обеспечивающее сохранность данных и настроек, резервирование и дублирование служб и приложений (например, развертывание нескольких почтовых релеев, серверов DNS и т. д.). Следующий важный момент, связанный с обслуживанием почтовых систем. До 80% простоев почтовых служб связано с человеческим фактором, т.е. с ошибками администраторов и технических специалистов (если в вашей сети рядовой пользователь может вывести из строя почтовую систему, то дела совсем плохи, и кластер тут точно не поможет). В такой ситуации почтовый кластер также не слишком полезен, ведь ошибки допускаются людьми, и техника не всегда способна определить, верно ли выполнены те или иные действия администратора. Кластер предназначен для защиты прежде всего от аппаратных сбоев. Не забудьте про масштабируемость вашего решения. Организации с течением времени расширяются, увеличивается количество рабочих мест, учетных записей электронной почты и т. д. В связи с этим выбирайте аппаратное обеспечение для вашего кластера с запасом по мощности и ресурсам. Иначе вы рискуете столкнуться с ситуацией, когда ваш отказоустойчивый кластер будет справляться с запросами пользователей все медленнее и медленнее. Это общий принцип, который актуален не только для кластеров, но и для любых других систем. И, наконец, немаловажный вопрос стоимости внедрения. Необходимо определить стоимость простоя и исходя из этого подобрать конфигурацию кластерного решения. Не очень разумно разворачивать четырехузловой кластер в сети из 50 пользователей, однако не менее неразумно использовать для почтовой системы одиночный сервер в сети из нескольких тысяч пользователей. Итак, думаю мои размышления по поводу внедрения кластерных технологий и проблем, связанных с этим, помогут вам лучше определиться с теми требованиями и задачами, которые вы предъявляете к данной технологии. Для того чтобы проверить, поддерживается ли ваше аппаратное обеспечение Windows Server 2003, вы можете воспользоваться ресурсом http://www.microsoft.com/whdc/hcl/default.mspx. Постановка задачи Имеется два сервера: Node 1 и Node 2. Необходимо развернуть почтовую систему на базе отказоустойчивого кластера. В результате мы должны получить почтовый кластер. Данная почтовая система должна быть создана на основе двухузлового отказоустойчивого кластера, который назовем Mail. Архитектура Прежде всего определимся с редакциями Microsoft Exchange, которые мы можем использовать. По аналогии с операционной системой необходимо использовать редакцию Enterprise Edition, так как Standard не поддерживает кластеризацию. Microsoft Exchange 2003 Enterprise Edition поддерживает до 8 узлов, но в качестве примера я буду рассматривать установку двухузлового кластера. Для кластерных приложений типа Exchange возможны два режима работы: Active/Active и Active/Passive. То есть в первом случае в каждый момент времени оба узла обрабатывают задачи Exchange, во втором случае только один узел обрабатывает задачи, а второй простаивает. Microsoft настоятельно рекомендует использовать режим Active /Passive, так как использование режима Active/Active приводит к появлению ограничений в использовании аппаратных ресурсов узлов, а также к проблемам с отказоустойчивостью. Перед тем как начать процесс установки, нам необходимо развернуть кластер на основе службы Microsoft Cluster Service. Подробное описание, как это сделать, читайте в статье [1]. Напомню, что перед установкой нужно подготовить кворум-устройство, то есть общий диск, который будут использовать все узлы кластера. В данном случае емкость этого диска должна превышать 100 Гб, при этом для отказоустойчивости лучше всего использовать аппаратные RAID-1 или RAID-5. Также при создании кластера Exchange вам потребуется использовать оба сетевых адаптера на каждом из узлов. Это обусловлено необходимостью оптимизации пропускной способности сети. Предназначение сетевых интерфейсов аналогично описанным в предыдущей статье: Heartbeat и LAN. Первый предназначен для обмена сообщениями о состоянии узлов кластера, а второй служит для связи с внешней сетью. Обмен данными в кластере осуществляется через кворум-устройство, не через сеть. Итак, в случае правильного выполнения рекомендаций статьи [1] у вас должен был получиться отказоустойчивый двухузловой кластер под названием Mail, как и предполагалось в разделе «Постановка задачи». Учитываем ограничения Для того чтобы лучше спланировать использование кластером некоторых аппаратных ресурсов, в частности, жесткого диска, вам необходимо ознакомиться с рядом ограничений в Microsoft Exchange. В Exchange 2003 есть жесткое ограничение на количество хранилищ, не более четырех групп на один сервер. Как правило, четырех хранилищ вполне достаточно для решения задач средней сети. Развивая тему ограничений, используемых в кластере Exchange, привожу список служб, используемых в Active/Passive-кластере:
Все прочие службы, такие как шлюзы, коннекторы Exchange и другие, должны быть установлены на отдельных серверах. Приступая к установке Прежде чем запустить файл установки, нам придется проделать некоторые предварительные работы, помимо установки кластера Microsoft Cluster Service. Для начала необходимо убрать все ненужные настройки и сетевые службы, так как они замедляют работу кластера, а также снижают уровень защищенности системы. Так, для внутреннего интерфейса Heartbeat не нужны настройки DNS и шлюз по умолчанию. Также удалите на внутреннем интерфейсе службы Client for Microsoft Networks, File & Printer Sharing for Microsoft Networks. На закладке «Advanced Properties» в разделе «Internet Protocol (TCP/IP)» выберите «DNS» и отключите «Register This Connection’s Address In DNS». Затем выберите закладку «WINS» и удалите все IP-адреса WINS-серверов. Также отключите «Netbios over TCP/IP». Кроме сетевых служб, также желательно отключить следующие службы на каждом из узлов кластера:
Следующим этапом проверьте соответствие наименования дисков на каждом из узлов кластера. Например, в нашем случае имеются два узла, у каждого из них имеется диск Q, P, R. Ситуация, при которой на одном узле эти диски видны как Q, P, R, а на другом L, M, N, недопустима. На обоих узлах должны быть видны Q, P, R. Также проследите за тем, чтобы Exchange на всех узлах был установлен на локальном ресурсе и имел идентичную структуру каталогов и файлов. Также удостоверьтесь, что на каждом из узлов установлены следующие службы: Web, NNTP, SMTP, ASP.NET. И еще хотелось бы напомнить о том, что крайне нежелательно размещать какие-либо сторонние приложения на узлах кластера (за исключением приложений, взаимодействующих с почтовой системой, таких как почтовый антивирус). После завершения выполнения предварительных настроек можно приступать к началу инсталляции. Прежде всего необходимо запустить /Domainprep для подготовки домена Active Directory к установке Microsoft Exchange. Обратите внимание, что для запуска вам потребуются права из группы Domain Admins. Далее, на первом узле кластера (том, который предполагается использовать в качестве «хозяина» ресурса) запускаем установочный файл setup.exe. В нашем случае это Node 1. В первом окне после лицензионного соглашения видим Component Selection Screen. Обычно используется типичная (Typical) установка компонентов. В этом же окне необходимо указать расположение каталога, в который будет установлен Exchange. Ещё раз обращаю внимание на то, что на всех узлах кластера этот путь должен быть одинаковым, но располагаться этот каталог должен на локальном ресурсе. Далее нажимаете «Next» и производите установку. В результате по завершении процесса установки Exchange установлен, но сервисы не настроены. Аналогичную операцию необходимо проделать и на втором узле кластера Node 2. Объединяем ресурсы Теперь приступаем к самому интересному – к настройке почтового кластера. Оба узла содержат файлы, необходимые для поддержки Exchange Virtual Server, виртуального сервера, который в качестве физической структуры использует наш кластер. Первым делом проверьте, видят ли оба узла общий кворум-ресурс. Затем в консоли Cluster Administrator необходимо создать группу. Для этого нажимаем правою кнопку мыши на разделе «Groups», и выбираем «Create A New Group». Далее указываем наименование группы и ее описание. На следующем шаге указываем предпочтительного владельца ресурса. В нашем случае это будет Node 1. После этого нам необходимо создать ресурс. Однако тут придется сделать небольшое отступление. Как уже упоминалось в предыдущей статье [1], ресурсы в Microsoft Cluster Service, как правило, обладают зависимостями. Для Exchange эти зависимости отображены на рис. 1.
Рисунок 1. Схема зависимости ресурсов в кластере Exchange Как видно из рисунка, ключевым элементом в схеме зависимостей является служба System Attendant – ключевой компонент Microsoft Exchange. Так что такая зависимость вполне оправданна. От этой службы зависят службы протоколов SMTP, HTTP, IMAP, POP3, а также Exchange Store и Microsoft Search. Также служба связана с Message Transfer Agent и Routing. В свою очередь System Attendant зависит от Network Name и Physical Disk. А Network Name в свою очередь традиционно зависит от IP Address. За подробностями, описывающими построение зависимостей, рекомендую обратиться к [2]. Итак, все эти ресурсы необходимо будет создать для успешного функционирования кластера. Причем создавать нужно в соответствующей последовательности. Начнем с ресурса IP Address. Выбираем «New -> Resource». В появившемся окне тип ресурса IP Address, а также имя, описание и группу, к которой принадлежит данный ресурс. В следующем окне указываем возможных владельцев, это узлы Node 1 и Node 2. Затем необходимо прописать IP-адрес ресурса, который будет использоваться для доступа к кластеру. В соответствии со схемой следующим требуется указать сетевое имя. Обратите внимание на то, что это имя впоследствии будет использоваться для подключения профилей почтовых клиентов Outlook к почтовому кластеру. Проделываем действия, аналогичные описанным в предыдущем разделе. Только в качестве создаваемого ресурса указываем Network Name. Соответственно, в окне «Dependencies» необходимо выбрать «IP address». В качестве сетевого имени кластера указываем Mail. Следующий ресурс – это Disk Resources. Так же как и ранее, указываем в качестве ресурса Disk Resource и выбираем общие кворум-устройства. Необходимо указать все общие диски, используемые для хранилища, журнала событий и т. д. В качестве зависимости указываем «Network Name». Создав Disk Resources, мы подготовили наш кластер к созданию ресурсов, используемых непосредственно Exchange. Первым из этих ресурсов должен быть Exchange System Attendant. Для этого выбираете «Exchange Server Group», далее «Create -> New», далее «Exchange System Attendant Resource». Укажите оба узла в качестве возможных владельцев ресурса. В окне зависимостей нужно указать только Network Name. У вас может возникнуть ошибочное мнение, что нужен также IP-адрес, но так как сетевое имя уже зависит от IP‑адреса, то в списке зависимостей его выделять не нужно. После этого определяем administrative group, в которой данный виртуальный сервер Exchange будет создан. Будьте внимательны, сменить административную группу потом будет невозможно. Далее выбираем «Routing group», в которой будет создан данный виртуальный сервер. В отличие от предыдущего действия, это впоследствии можно будет изменить. Затем нужно указать пути к почтовым базам (databases) и журналам событий (transaction logs). И наконец, после завершения указания путей в следующем окне мы получаем рабочие ресурсы Exchange. Выглядеть это должно следующим образом (см. рис. 2).
Рисунок 2. Установленный почтовый кластер Exchange Обратите внимание на то, что все ресурсы должны иметь состояние Online. Если это не так, нужно вручную запустить остановленный ресурс. Далее откройте «Exchange System Administrator» на одном из узлов свежесозданного кластера. Затем «Administrative Group», контейнер «Servers». Выбираем «Mailbox Store», после чего открываем закладку «Database». Здесь, возможно, указан локальный путь к почтовому хранилищу, необходимо указать путь на общем ресурсе. После завершения всех этих нехитрых манипуляций вы получаете работоспособный, отказоустойчивый кластер. Если что-то пошло не так… Что делать, если в процессе создания кластера что-то пошло не так и вы получили сообщение об ошибке или какие-то ресурсы не запускаются? Проверьте, не использует ли какой-либо из узлов кластера TLS/SSL. В случае, если вам требуется использование защищенных каналов, обратитесь к документации по Exchange на Microsoft.com. Удостоверьтесь, что каталог SMTP\Mailroot находится на кворум-ресурсе, не на локальном диске узла. Проверьте соответствие букв дисков на узлах в кластере. Еще одна проблема, с которой вы можете столкнуться, особенно после перезагрузки или отключения узлов кластера, – это то, что ресурсы Exchange «повисают» в состоянии Pending Online. В такой ситуации необходимо проверить доступность контроллеров домена Microsoft Active Directory. Как правило, узлы не могут переключиться в состояние Online, если контроллер домена недоступен. Если проблема имеет более сложное решение, просмотрите сообщения об ошибках в журналах событий на узлах кластера. Тонкая настройка Теперь необходимо произвести некоторые дополнительные настройки для обеспечения дополнительной отказоустойчивости и надежности. Прежде всего необходимо определиться с политиками отключения при сбое. Этот процесс очень важен, так что я рассмотрю его более подробно. Когда один из узлов кластера выходит из строя (политика Failover), с данного узла перестают приходить сигналы Heartbeat. Другие узлы кластера обнаруживают отсутствие одного из узлов, и запускается процесс передачи владения (ownership) рабочим узлам кластера. Информация о передаче владения находится на кворум-устройстве. В случае возвращения в строй выбывшего узла (политика Failback) происходит обратная передача владения рабочему узлу. Политики перехода Failover и Failback доступны в разделе свойства Exchange Server. В политике перехода отключения при сбое нужно определить два параметра поведения кластера: пороговое значение количества сбоев (threshold) за интервал времени (period). Значения по умолчанию это 10 сбоев ресурса в группе за 6 часов. Такие значения этих параметров будут вполне приемлемы для нашего двухузлового кластера (см. рис. 3).
Рисунок 3. Политика перехода отключения при сбое Политика возвращения ресурса аналогична политике выхода из строя. Но здесь вы можете запретить Failback. Это необходимо в тех ситуациях, когда смена владельца ресурса может привести к сбоям приложений кластера. В случае, если вы хотите разрешить возвращение ресурса, то вы можете разрешить делать это немедленно (Immeditely) или же в определенный интервал времени, например, в нерабочие часы, когда нагрузка на кластер минимальная (см. рис. 4).
Рисунок 4. Политика возвращения ресурса Как правило, вместе с почтовым сервером в крупных сетях используется также различное дополнительное программное обеспечение, например, антивирус, антиспам, система шифрования и т. д. Что касается средств защиты от нежелательных почтовых сообщений (антиспама), то мое мнение, что данная служба должна располагаться на почтовом шлюзе (relay) и не должна расходовать ресурсы нашего кластера. Что же касается таких средств, как почтовый антивирус, то перед развертыванием кластера необходимо узнать, поддерживает ли ваш антивирус кластеризацию. Как правило, все современные антивирусные системы для почтовых серверов позволяют осуществлять установку на кластерные системы. При этом антивирус после установки превращается в ресурс кластера, и вы можете управлять им так же, как и прочими ресурсами. В следующем примере используется Trend Micro ScanMail for Exchange в качестве антивирусной системы для почтового сервера (см. рис. 5).
Рисунок 5. Ресурсы кластера Основным инструментом управления почтовым кластером является консоль Cluster Administration. Работа с почтовым кластером имеет свои особенности, в частности, нужно быть очень осторожным при работе с ресурсами, остановка основных, таких как System Attendant, приведет к остановке всех зависимых ресурсов. К тому же не стоит забывать о тех вопросах, которые освещались в параграфе «Когда кластер не поможет…». Заключение с продолжением Тема реализации кластеров на основе служб Windows ещё не заканчивается. Не стоит обходить стороной такую службу, как Network Load Balancing, и установку кластера с её помощью. В следующей статье читайте создание кластера на основе NLB, а также о его настройке и обслуживании.
|
Андрей Бирюков
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
