Повышение надежности системы передачи электронных сообщений

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

Основные понятия

У специалистов по построению кластеров существует собственный жаргон. Часто употребляется, например, слово failover. Failover - это отказ работающей службы на узле кластера. Суть понятия failover состоит в автоматическом перезапуске службы отказавшего узла и продолжении ее работы на функционирующем узле кластера без вмешательства администратора (и желательно незаметно для пользователей). Слово failback обозначает действие обратное failover: когда отказавший узел возобновляет свою работу, а службы, перешедшие после сбоя на другие узлы, возвращаются на свои места.

Несколько других терминов обозначают, какой из узлов в кластере выполняет работу. В идеале каждый узел кластера должен что-нибудь делать; используя Exchange, мы хотим, чтобы каждый узел непрерывно обслуживал клиентов. В Microsoft такие кластеры называют active/active — два узла одновременно обслуживают разных клиентов. Модель active/active отличается от кластерной модели Exchange 5.5, когда один узел работает с клиентами, а второй находится в резерве, на случай отказа первого. Такая кластеризация называется active/passive. Если кластер содержит более двух узлов и один из них простаивает в ожидании сбоя какого-либо узла, то такая система называется N+1 узловой кластер.

Обратите внимание, что для пользователей кластер выглядит как один компьютер в сети. Кластер представляется единым целым, поскольку при его создании ресурсы узлов объединяются. Ресурс может быть физическим (например, диск) или логическим (например, IP-адрес). Набор отдельных ресурсов (например, IP-адрес, имя NetBIOS, некоторые службы Exchange) составляет виртуальный сервер Exchange, который является экземпляром Exchange и выглядит как отдельный реальный компьютер, хотя это не так. Пользователи подключаются к виртуальному серверу, не заботясь о физическом расположении сервера.

Сколько узлов можно включить в состав кластера? Многие администраторы Exchange свято верят, что кластер всегда состоит из двух узлов. Однако это не так, и кластеры, построенные на других операционных системах, могут состоять из 16, 32, 64 и более узлов. Это возможно даже на Windows, если использовать кластерное программное обеспечение независимых разработчиков. Кластер нельзя создать на базе обычного сервера Windows 2000. Windows 2000 Advanced Server поддерживает двухузловой кластер, а Windows 2000 Datacenter Server - четырехузловой. Можно надеяться, что в будущем Microsoft увеличит число поддерживаемых узлов. Разумеется, кластер Exchange не может содержать узлов больше, чем позволяет операционная система. Поэтому максимальное число узлов для Exchange равняется четырем при установке на операционной системе Datacenter (с пакетом SP1 для Exchange или более поздним).

Кластеризация и Exchange 2000

Рассмотрим, как Exchange 2000 использует предоставляемые кластером преимущества. Группа хранения (SG) является базовым элементом, которым оперирует механизм восстановления при сбое узла Exchange. При отказе узла все группы хранения SG переносятся на работоспособный узел. Этим механизм failover в Exchange 2000 отличается от failover кластера Exchange 5.5, где роль базового элемента играла служба, например, такая, как служба информационного хранилища IS или агента передачи сообщений MTA. Использование групп хранения SG в качестве базового элемента значительно упрощает процесс восстановления failover: хранилище IS на принимающем узле просто монтирует SG и соответствующие базы данных — вместо более длительного процесса внесения изменений в хранилище в соответствии с журнальными файлами.

Базовая поддержка кластера Exchange 2000 осуществляется двумя библиотеками DLL. Excluadm.dll обеспечивает взаимодействие Exchange с менеджером кластера Windows, а exres.dll - взаимодействие служб и ресурсов Exchange с менеджером служб и ресурсов кластера. Разумеется, на нижнем уровне все гораздо сложнее. Каждый компонент Exchange 2000, поддерживающий работу в кластере, обязан использовать соответствующие API и интерфейсы. Обращаем внимание читателей на слова «поддерживающий работу» или «cluster-ready». Не все службы Exchange 2000 в одинаковой степени адаптированы для работы в кластере. Службы System Attendant, IS, Routing service и SMTP - полностью cluster-ready. Служба MTA поддерживает только режим active/passive; если происходит сбой MTA на одном узле, то приходится перезапускать ее на другом узле с самого начала. Не поддерживают работу в кластере такие службы, как сервер NNTP, Instant Messaging, коннектор каталога ADC, сервер Chat и раздачи ключей Key Management Service (KMS). Поэтому при проектировании кластера следует помнить, что работоспособность части приложений может быть потеряна даже в кластере.

Практические соображения

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

Второе преимущество кластера заключается в том, что администратор может в любое время провести регламентные работы. Рассмотрим процесс установки пакета исправлений SP для Exchange или обновления антивирусного программного обеспечения. Сначала следует или остановить работающий сервер (а это можно сделать только на Рождество, когда на работе нет ни одного сотрудника, отправляющего электронную почту), или попытаться быстро-быстро установить пакет и молиться, чтобы все шло как надо. В кластере Exchange обновление пакета выполнить гораздо проще. Достаточно перевести виртуальный сервер на другой узел, и можно производить регламентное обновление пакета. При этом пользователи продолжают работать как обычно. После окончания обслуживания виртуальный сервер возвращается назад.

Кластеризация имеет ряд ограничений, которые при планировании следует учесть. Первоначально разработчики Microsoft не давали рекомендаций по числу одновременно работающих пользователей в кластере типа active/active. Поэтому администраторы стараются загрузить сервер максимально. Например, если в двухузловом кластере каждый узел поддерживает 2000 одновременно работающих пользователей, то в случае сбоя одного из узлов нагрузка на оставшийся узел составит 4000 пользователей, что нельзя назвать самым удачным способом повышения надежности Exchan-ge. Для решения этой проблемы (которая усложняется некоторыми внутренними особенностями архитектуры) теперь рекомендуется, чтобы на узле в кластерах с количеством узлов N+1 (т. е. кластерах типа active/passive для двухузловых установок) работало одновременно не более 1500 пользователей. Эта формула пригодится в будущем, когда станет возможным построение кластеров Exchange с количеством узлов N+1.

Конечно, кластер не решает всех проблем. Основная причина «падений» кластера не в аппаратуре или программном обеспечении, а в ошибках обслуживающего персонала. Кластер не заменит администрирования и резервного копирования, не защитит от таких сбоев, как отключение питания или недоступность канала в Internet. Однако понимание лежащих в основе кластеризации технологий и присущих ей ограничений позволит спроектировать надежную систему Exchange.

Поль Робишо - старший системный архитектор компании EntireNet, име-ет сертификаты MCSE и MCT. С ним можно связаться по адресу: getting-started@robichaux.net.