2. Реализация Почтовой Системы 2.1. Расположение и роли серверов
Согласно принятой модели Почтовой Организации сервера располагаются следующим образом:
• Front-end сервер размещается в головном офисе управляющей компании и на каждом предприятии • Back-end серверы так же размещаются в головном офисе управляющей компании и на каждом предприятии. Back-end сервер, как наиболее критичный, представляет собой кластер из двух машин. У мобильных клиентов, а так же в малых офисах, клиентское ПО MS Outlook работает в режиме Cached Exchange Mode.
2.2. Административные группы Административные группы служат для объединения почтовых хранилищ, системных политик, групп маршрутизации, серверов в единую точку управления. В зависимости от потребностей Компании, при наличии необходимости в введении различных системных политик для отдельных предприятий, филиалов, будет определено количество необходимых административных групп и разработан набор политик для них.
2.2.1. Маршрутизация почтовых сообщений. Группы маршрутизации. Предполагается, что MX записи обслуживаемых доменов будут указывать на сервер CheckPoint, который функционирует в режиме шлюза для почтовых сообщений. После проверки входящей почты она будет передана Front-end серверу. Front-end сервер обрабатывает поступающую корреспонденцию и пересылает ее на нужный Back-end сервер, то есть на сервер, содержащий почтовый ящик пользователя-получателя сообщения. В целях защиты от спама и несанкционированного использования применяется фильтрация запросов:
• по IP адресам (только CheckPoint или локальная сеть для SMTP) • Авторизация на основе сертификатов (для HTTPs)
В случае, когда в организации используется несколько серверов Exchange, при передаче сообщения с одного сервера на другой используется механизм групп маршрутизации. В группы маршрутизации объединяются сервера связанные постоянными надежными линиями связи. В данном случае, необходимо и достаточно применение одной группы маршрутизации, группы по умолчанию. По дополнительному согласованию будут определены так же следующие характеристики:
• ограничения по размеру сообщения, проходящего через соединение. • ограничения на доставку (по группам или пользователям). • тип соединений (x.400, SMTP, другие) • необходимость в шифровании коммуникаций между серверами
2.2.2. Политики В рамках административной группы действует набор системных политик. Системные политики подразделяются на следующие виды:
• Mailbox store policies (политики хранилищ сообщений), включают в себя ограничения на размер хранилища, определение интервалов обслуживания и т.д. • Public store policies (политики общих папок), включают в себя расписание обслуживания, интервалы репликации ограничения на размер хранилищ и т.д. • Server policies (политики серверов), распространяют на сервера единые правила ведения журналов, отслеживания сообщений и т.д.
Разработка политик проводится с учетом условий функционирования системы, в том числе имеющихся дисковых ресурсов и существующих административных правил.
2.3. Пользовательские политики Пользовательские политики позволяют управлять такими параметрами как:
• Шаблоны адресов для вновь создаваемых ящиков • Управление процессом обслуживания почтовых ящиков (MailBox Manager) Шаблоном адреса по умолчанию в организации заказчика будет иметь следующий вид:
N.Surname@domain
где N – первая буква имени пользователя, Surname – фамилия. В случае конфликта имя приобретет следующий вид: NI.Surname@domain, где I – первая буква отчества. Эти имена будут генерироваться автоматически на основании указанных в политике шаблонов.
2.4. Структура хранилищ При наличии большого количества пользователей а так же четкого дифференцирования как по правам так и по объемам работы, целесообразно разбить их на группы. Каждая группа обслуживается своим почтовым хранилищем со своим набором политик. Разделение на группы так же позволяет восстанавливать отдельную группу (поврежденную) после сбоя дискового носителя, что быстрее, чем восстановление всей информации; раздельные политики резервного копирования групп (в зависимости от ценности) и другое. Разработка структуры хранилищ включает в себя:
• Определение структуры • Разработка дифференцированных системных политик • Разработка стратегии резервирования
Планируется выделение по крайней мере трех групп для каждого из серверов: • VIP • Office • Guest
2.5. Структура общих папок Общие папки представляют собой ресурс, разделенный между множеством пользователей. Они могут использоваться как хранилище для документов совместной работы, доски объявлений, дискуссионных групп, журнала службы поддержки и т.д. Исходя из общей доступности данных в общих папках и принципов совместной работы, становится очевидной необходимость тщательной проработки структуры прав. Таким образом, проектирование структуры общих папок состоит из:
• Разработка структуры • Разработка системы прав • Определение реплицируемых и не реплицируемых папок • Рекомендации по использование полнотекстового индексирования (повышает скорость поиска информации в общих папках)
Учитывая то, что частично уже применяется механизм общих папок, планируется использование существующей структуры с внесением изменений, учитывающих новые возможности Почтовой Организации на базе MS Exchange 2003.
2.6. Схема репликации Основная информация конфигурации организации Exchange реплицируется на уровне AD и прорабатывается на этапе подготовки AD. В то же время, существует информация, которая реплицируется самими серверами организации Exchange. Это общие папки. Разработка схемы репликации включает:
• Разработку топологии серверов (определение серверов, на которых будет доступна реплика реплицируемой папки) • Определение расписания репликации
2.7. Структура почтовых групп и GAL В семействе серверных продуктов Microsoft поколения 2003 появилась поддержка групп, базированных на ldap запросе (query-groups). Такие группы полезны в том случае, когда членство пользователей в группе зависит от совокупности атрибутов AD. При этом отсутствует необходимость добавлять в группу конкретных пользователей, достаточно лишь изменить атрибуты и при следующем запросе состава группы пользователь «появится» в ней автоматически. Оборотной стороной таких групп является низкая скорость работы с ними, поскольку каждый раз при вызове списка членства в группе формируется и отрабатывается ldap запрос. Исходя из этого, становится понятной необходимость планирования количества query-based групп и их наполнения. Проектирование почтовых групп состоит из:
• Определение стандартных (mail-enabled) групп. Такими группами, например, являются группы доступа. • Определение групп, базированных на ldap запросах (query-based groups). Например, в такую группу могут входить «работники 4 этажа» или «все старше 28 лет». • Определение ограничений на доступ и использование группами пользователей mail-enabled групп для рассылки сообщений Следующим шагом является проектирование адресных книг. Для каждого отдела (департамента) может существовать своя адресная книга, в рамках GAL (global address list – глобальная адресная книга). • Разработка структуры адресных книг (определение уровня подразделений) • Разработка структуры offline address book (адресная книга, доступная при отсутствии соединения с сервером) • Определение дополнительных адресных книг (используются для того, чтобы не перегружать пользователя избытком ненужных адресов) • Определение доступности (видимости) адресных книг для различных категорий пользователей
2.8. Делегирование административных полномочий Объекты Exchange видны в консоли управления (стандартная mmc консоль) в виде дерева. Администратор системы может делегировать управление на уровне любого узлов этого дерева локальным администраторам или другим пользователям. Миграция выполняется согласно выбранному плану миграции для Службы Каталога.
• Осуществляется установка ПО Exchange 2003 • Осуществляется базовая конфигурация • Производится наполнение каталога объектами (Миграция Службы каталога), на этом же этапе происходит перенос ACLs для почтовых ящиков • Осуществляется перенос почтовых ящиков • Осуществляется реплицирование общих папок в новую Почтовую Организацию • Устанавливаются системные и пользовательские политики
3. Интеграция с AD Используемое решение предполагает плотную интеграцию с системой активного каталога. Пользователь системы в терминологии ОС будет по умолчанию рассматриваться и как пользователь ПС. Необходимые профили информации могут быть созданы автоматически при генерации нового пользователя. Политиками проводится разграничение использования почтовых адресов. Почтовый домен выбирается автоматически согласно домена AD, в котором находится пользователь.
4. Отказоустойчивость. В качестве Back-end сервера используется кластер из двух серверов. Это означает, что в случае выхода из строя одного из серверов кластерной пары, партнер продолжает поддерживать функционирование системы в полном объеме, в прозрачном для пользователя режиме. Таким образом, интерфейс отправки и получения почты постоянно доступен. В случае выхода из строя целиком кластера Back-end серверов по прежнему остается возможность отправки почты (благодаря единому пространству имен). Если Back-end сервер недоступен в течении длительного времени, возможно временно изменить настройки системы, указав новую storage group для пользователей площадки, что опять же пройдет незамеченным для пользователей. В случае разрыва соединения с головным офисом, по прежнему возможна передача почты как внутри площадки, так и использованием доступных групп маршрутизации.
5. Миграция
По результатам обследования, имеющиеся почтовые службы можно разделить на следующие виды:
• Организации Exchange. Миграция осуществляется стандартным образом. • Почтовые службы, базированные на MDaemon и/или sendmail .
Миграция состоит из следующих этапов:
• Развертывание почтовой службы Exchange 2003 o Осуществляется установка ПО Exchange 2003 o Осуществляется базовая конфигурация o Производится наполнение каталога объектами (Миграция Службы каталога), на этом же этапе происходит перенос ACLs для почтовых ящиков
• Миграция почты и клиентов из старой организации Exchange. o Осуществляется перенос почтовых ящиков o Осуществляется реплицирование общих папок в новую Почтовую Организацию o Устанавливаются системные и пользовательские политики
• Миграция почты и клиентов из систем отличных от Exchange/ o Установка Outlook на компьютеры пользователей o Перенаправление входящей корреспонденции на сервера почтовой организации Exchange o Выгрузка имеющихся почтовых баз на серверы Exchange o Ликвидация старой почтовой службы и клиентского ПО, не соответствующего корпоративной политике
Планируется сохранение (в рамках возможностей) существующих почтовых адресов. Они буду назначены в качестве псевдонимов к соответствующим почтовым ящикам новой почтовой организации.
