Недавно компания GartnerGroup опубликовала отчет об исследовании возможностей масштабирования Microsoft Exchange Server до систем старшего класса. По мнению специалистов Gartner Group, управление базами данных, которые формируют в Exchange Server 5.5 хранилище информации Information Store (IS) — особенно, когда такие базы данных вырастают до весьма больших размеров — становится затруднительным. Мнение аналитиков GartnerGroup имеет в компьютерной индустрии большой вес, а результаты проведенного анализа интересны и убедительны.

Разработчикам Platinum, очередной версии Exchange Server, которая должна появиться в начале 2000 года, удалось найти ответы на многие вопросы GartnerGroup. Программное обеспечение Platinum основывается на платформе Windows 2000 и дебютирует вскоре после ее выпуска. В своей статье я предлагаю вниманию читателей обзор ряда ограничений числа почтовых ящиков, которые можно разместить на одном сервере Exchange, а также расскажу о выполненных в Platinum доработках, способных облегчить масштабирование системы. В основу статьи положен опыт работы с первой бета-версией Platinum.

Последние достижения в области аппаратного обеспечения способствовали значительному увеличению пропускной способности Exchange Server и позволили достичь нового уровня масштабирования системы. Даже самые простенькие серверы основных производителей компьютеров в состоянии поддерживать сотни пользователей, а если оснастить сервер дополнительным процессором, большей оперативной памятью и быстрыми дисками, то их число возрастет до нескольких тысяч. Можно и далее продолжать добавлять процессоры, память, диски, и даже объединять пары серверов в кластеры, но наиболее опытные проектировщики систем на основе Exchange Server не рекомендуют размещать на одном сервере (или кластере) более 3000 почтовых ящиков. Об этом же говорят и результаты тестирования системы с помощью симулятора нагрузки LoadSim, который производители используют для тестирования своих аппаратных платформ. Некоторые из самых современных 4- и 8-процессорных серверов рассчитаны на поддержку 26 тыс. одновременно работающих пользователей. Что же ограничивает масштабирование почтовой системы?

Разумеется, данные. Три тысячи почтовых ящиков вмещают огромное количество данных. Независимо от того, насколько хорошо «экипирован» сервер, по мере увеличения числа почтовых ящиков возрастает количество сообщений и присоединенных файлов. Exchange Server при этом генерирует все большую базу IS.

Exchange Server 5.5 разделяет IS на Private Store (priv.edb) и Public Store (pub.edb). В Private Store содержатся все почтовые ящики пользователей, и по объему хранимых данных он имеет тенденцию перерастать Public Store, особенно на очень больших серверах (информацию о возможных размерах Private Store можно найти во врезке «Насколько большим станет хранилище»). Чтобы Exchange Server мог поддерживать десятки тысяч почтовых ящиков на одном сервере, разработчики Platinum вышли далеко за рамки первоначальной модели, в основе которой лежит одна большая база данных.

Подобно Exchange Server 5.5, Platinum использует Extensible Storage Engine (ESE) как базовую для IS технологию. ESE работает на очень низком (т. е. страничном) уровне. Всю обработку данных выполняет процесс IS (store.exe). Существенным усовершенствованием архитектуры базы данных в Platinum стало введение концепции «групп хранения» Storage Group (SG). SG — это набор баз данных, управляемый одним процессом IS. Группой SG можно управлять как единым объектом, либо иметь дело с каждой базой данных индивидуально. По умолчанию, при установке Platinum конфигурируется с одной группой SG, содержащей открытое (public) и закрытое (private) хранилища IS, точно так же, как и в случае с Exchange Server 5.5. Процесс IS управляет всеми активными группами SG сервера. Каждая группа SG имеет отдельный набор журналов транзакций, так что резервировать и восстанавливать группы можно по отдельности. Именно этот механизм и обеспечивает Platinum дополнительную гибкость при работе с базами данных по сравнению с Exchange Server 5.5. Сейчас в случае повреждения диска ни один пользователь не может работать с почтой до тех пор, пока проблемы с диском не будут решены. В Platinum почтовые ящики можно распределить между различными SG так, чтобы подобная проблема касалась только тех пользователей, которые связаны с определенной группой SG.

Рисунок 1 иллюстрирует обеспечиваемую SG большую гибкость Platinum по сравнению с Exchange Server 5.5. В приведенном примере используются две группы SG. Если возникла проблема с диском, содержащим «Fourth Private Store», то достаточно отключить только SG2, переведя его в автономный режим, а SG1 остается активной, и пользователи, чьи почтовые ящики находятся в ней, спокойно продолжют работать. Однако в автономный режим следует переключить все базы SG2, даже если аппаратная проблема касается только одной базы данных в группе; дело в том, что Platinum записывает все транзакции группы в общий набор журнальных файлов.

Поскольку каждая группа имеет отдельный набор журнальных файлов, администратору Exchange Server нужно уметь правильно использовать механизм транзакций для восстановления необходимых данных. Опыт показывает, что большинство администраторов совершает ошибки в процессе восстановления: удаляют журнальные файлы или пытаются применить неправильный их набор. Необходимо разобраться в принципах работы всех основных системных процедур, имеющих дело с новой структурой базы (таких как, выполнение резервирования, монтирование и удаление индивидуальных баз данных). Планируя развертывание почтовой системы на базе Platinum, следует также полностью пересмотреть и обновить свои процедуры восстановления данных.

Разбиение IS повышает гибкость Exchange Server. Служба IS в Exchange Server 5.5 не запускается, если возникает проблема (пусть даже небольшая) с открытым или частным хранилищем. Ее не удастся запустить, пока все неполадки не будут устранены. Представьте, что произойдет, если она должна обслуживать по 20-30 баз данных на сервере. В Platinum же, если обнаруживается какие-либо нарушения в работе базы данных, система полагает, что база данных находится в автономном режиме, и служба IS загружает следующую. Влияние этой проблемы распространяется только на почтовые ящики или общие папки, которые находятся в отключенной базе данных, а не на всей системе в целом. После устранения проблемы базу данных можно восстановить и вернуть ее в активный режим.

Platinum поддерживает до 15 групп SG на одном сервере. Каждая из них может управлять шестью базами данных. В результате разбиения IS можно получить 90 отдельных баз данных на одном сервере. Однако пока неизвестно, как сбалансировать запросы к процессору, памяти и подсистеме ввода-вывода, чтобы добиться максимальной эффективности (мне трудно представить себе человека, который стал бы создавать более двух групп SG или больше чем три-четыре базы внутри каждой группы). Внутренние структуры (например, индексы) каждой загруженной базы данных кэшируются в память. Поэтому при загрузке слишком большого количества баз данных есть риск израсходовать ресурсы виртуальной памяти системы.

Чтобы накопить подобные данные по производительности системы, потребуется определенное время. Дабы определить, каковы теоретические ограничения на Platinum, производители компьютеров и Microsoft должны провести тестирование системы в лабораторных условиях. А затем уже пользователи будут оценивать адекватность полученных в лаборатории результатов в реальной обстановке.

В ближайшем будущем даже самый мощный сервер вряд ли станет использовать более 20 баз данных. Исходя из этого предположения, можно попытаться сформулировать правила для планирования систем на основе Platinum. Предельный размер хранилищ, на которые следует разбить IS, можно выбрать самостоятельно, равно как и установить принцип распределения пользователей по группам SG (скажем, разместить всех сотрудников отдела маркетинга вместе). Как показывает опыт, размер почтовых баз данных для средних и больших систем (более 500 почтовых ящиков на сервере) не превышает 20 Гбайт. Поэтому, возможно, как раз эта цифра послужит отправной точкой для создания нового частного хранилища. Кстати, 20 Гбайт — это как раз подразумеваемый размер нового хранилища или первой группы SG. Следовательно, создание новой группы SG размером 20 Гбайт дает максимальную гибкость. Однако с каждой дополнительной группой сложность управления системой возрастает, особенно в части резервирования и восстановления информации. Поэтому я рекомендовал бы в качестве порогового значения для создания новой группы SG 50 Гбайт.

О кластерах разговор особый. Группа SG становится кластерным ресурсом, который можно переключать между серверами в кластере. Очевидно, что работа с группами SG станет важной составляющей каждодневного администрирования кластера Platinum.

ЭКРАН 1. Создание SG при помощи Exchange System Server.

В Platinum на смену программе Microsoft Exchange Administrator пришел набор расширений для Microsoft Management Console (MMC). Консоль Exchange System Manager (см. Экран 1) предлагает необходимый комплект этих расширений. Данная консоль позволяет выполнять обычные административные действия с сервером Exchange, например, создавать новую базу данных внутри уже существующей группы SG или определять новую группу. С ее помощью можно выполнить многие общие административные действия, которые сейчас позволяет реализовать программа Microsoft Exchange Administrator (например, создавать новые почтовые ящики или списки рассылки). Эту работу можно выполнять на различных консолях MMC, которые взаимодейтсвуют со службой каталогов Active Directory (AD) (например, с каталогом пользователей и компьютеров).

Организовать новую группу SG несложно. Фактически разработчики Microsoft упростили эту операцию до такой степени, что неосмотрительные администраторы могут создавать новую группу SG или хранилище, даже не продумав заранее этой процедуры на этапе планирования. Однако чтобы сформировать новое хранилище надо иметь четкое обоснование. Например, может потребоваться объединить «важных» пользователей в отдельном хранилище, увеличив там квоты на размер почтовых ящиков. Пороговое значение на размер базы данных уже обсуждалось. Очевидно, что если новое хранилище создается в случае достижения этого порога, то часть почтовых ящиков надо переместить в новое хранилище. Если сервер Exchange обслуживает сразу несколько организаций, возможно придется создавать много групп SG. В Exchange Server 5.5 все они вынуждены работать с общим хранилищем. Однако в Platinum благодаря технологии разбиения хранилища можно реализовать надежную защиту информации каждой из компаний.

Любая новая группа, как и новая база данных, требует дополнительных системных ресурсов. Базы данных занимают дисковое пространство, а создание группы ведет к появлению нового набора журнальных файлов. В Windows 2000 при запуске службы IS базы данных загружаются в память; при этом даже на начальном этапе каждая база данных требует 10 Мбайт физической оперативной памяти.

Когда создается новая группа, Platinum запрашивает ее имя и место, где будет располагаться соответствующий журнальный файл (см. Экран 2). Опытные администраторы наверняка знают, как распределить информацию по дискам, чтобы добиться оптимальной эффективности. Опыт работы с Exchange Server 5.5 показывает, что хранить базы данных IS и их журнальные файлы следует на различных физических устройствах. Точно так же при использовании Platinum с множественными группами SG, группы баз данных и соответствующие журнальные файлы следует хранить раздельно, располагая каждый набор журналов транзакций на отдельных томах. Серверы, которые поддерживают несколько тысяч почтовых ящиков, скорее всего, оборудованы несколькими различными контроллерами и укомплектованы многими физическими дисками. Поэтому следует разместить файлы таким образом, чтобы отказ одного диска не повлиял на многочисленные базы данных или наборы журнальных файлов. Для большей производительности систем старшего класса необходимо поместить каждую группу SG на отдельный дисковый массив. Эти процедуры на первый взгляд могут показаться сложными в настройке. Тем не менее выполнять их все же проще и дешевле, чем управлять операциями ввода-вывода, которые могут породить множественные группы SG, или же устранять последствия отказов дисков, затронувшие одновременно базу данных и связанный с ней журнальный файл.

Когда новая группа определена, можно приступать к созданию хранилищ, которыми она будет управлять. На Экране 3 показано, как настроить реквизиты недавно созданного хранилища почтовых ящиков. Обратите внимание, что каждая база данных имеет отдельное расписание действий наподобие фоновой дефрагментации. Такое планирование гарантирует, что сервер не «зависнет» из-за конфликта одновременно выполняемых процедур, связанных с сопровождением различных баз данных.

На Экране 3 указаны два файла нового хранилища. Первый файл с расширением .edb использовался и в Exchange Server начиная с версии 4.0. Потоковая база данных (файл vip mailboxes.stm) — новая возможность Platinum, позволяющая обрабатывать MIME-запросы, генерируемые такими клиентами, как Outlook Express, или браузер. Outlook Express для доступа к IS использует протоколы IMAP4 или POP3. В браузерах же задействована новая версия Outlook Web Access (OWA) совместно с Microsoft Internet Information Server (IIS), а доступ к данным осуществляется по протоколу HTTP-DAV. Новая потоковая база данных берет на себя часть работы, выполняемой в Exchange Server 5.5 службой IS. При этом для обработки запросов клиентов и предоставления информации в том формате, в котором она запрашивается, используется механизм IMAIL, встроенный и в IS. Разбиение базы данных и распределение функциональности IS я считаю важным шагом в эволюции Exchange Server, поскольку это служит основой для формирования двухзвенных конфигураций front-end/back-end, способных поддерживать десятки тысяч почтовых ящиков на одном виртуальном сервере.

Клиенты, поддерживающие протокол Messaging API (например, Outlook Express 98 или Outlook Express 2000) игнорируют потоковую базу данных и используют файл .edb. При этом все необходимые операции берет на себя Exchange Server, скрывая от пользователя взаимодействие между двумя базами данных, инициированное запросами MAPI-клиентов к содержимому хранилища, необходимыми для выборки содержимого из потоковой базы данных. Потоковая база данных хранит и обеспечивает быстрый доступ к данным, которые не подходят для хранения в базе данных Exchange (EDB), разбитой на страницы по 4 Кбайт. Например, получение по электронной почте сообщения с вложенным видеофайлом размером 25 Мбайт с фрагментами из «Скрытой угрозы» влечет за собой высокие накладные расходы, поскольку системе при обращении к файлу вследствие фрагментации придется обрабатывать множество разбросанных по всей базе страниц. Для того чтобы решить эту проблему, в потоковой базе данных информация размещается последовательно. Подобно Exchange Server 5.5, Platinum сохраняет заголовки сообщений в EDB.

ЭКРАН 4. Задание имени новой группы SG.

При установке Platinum система размещает все почтовые ящики в создаваемой с подразумеваемыми параметрами группе SG c единым частным хранением. Создав дополнительные частные хранилища в первой или в новой группе, можно перемещать почтовые ящики между хранилищами. Новые почтовые ящики размещаются в любом доступном частном хранилище (см. Экран 4).

Чтобы переместить почтовый ящик из одного хранилища в другое, следует указать пользовательскую учетную запись на консоли MMC, которая управляет каталогом пользователей и компьютеров. Если щелкнуть правой кнопкой мыши, указав на объект, на экране отобразится набор действий, которые можно выполнять. Если у пользователя есть почтовый ящик на Exchange Server, в списке появится ряд соответствующих действий (см. Экран 5).

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

Множественность баз данных оказывает существенное влияние на модель хранения информации. Если сообщение отправляется трем получателям, а почтовые ящики находятся в различных хранилищах, Exchange Server должен создать отдельную копию сообщения в каждом из них. Чтобы не потерять преимущества единого хранения информации, следует по возможности уменьшить число баз данных. Например, почтовые ящики пользователей, которые обмениваются сообщениями между собой, можно попытаться расположить в пределах одного хранилища. Точно так же уместно разместить в одном хранилище рабочие группы или подразделения, обменивающиеся друг с другом информацией. Однако на это мне могут вполне резонно возразить, что отказ дисковой системы отразится на работе всей группы или подразделения. Если же разместить пользователей в различных хранилищах, отказ не скажется на всех членах рабочей группы, но это ухудшит общую производительность. Думаю, после выпуска Platinum нас ожидают жаркие дебаты относительно оптимального подхода к методам планирования почтовой системы.

В Platinum предусмотрена возможность создания множественных Public Storage — открытых собраний общих папок. До сих пор им, как правило, уделялось существенно меньше внимания, нежели почтовым ящикам. Пользователи в основном работают с почтовыми сообщениями и программными дополнениями (например, служба отправки факсов или антивирусная защита), вместо того, чтобы уделить внимание организации инфраструктуры общих папок. Общие папки очень удобны для сбора и хранения документов; если объединить их с электронными формами, они могут составить хорошую базу для различных приложений. Однако эти возможности используются редко. Поэтому, вероятно, не часто можно будет встретить пользователей, определяющих множественные Public Storage. Впрочем, для тех, кто нуждается в этом, такая возможность есть.

Platinum в полном объеме поддерживает работу с адресным пространством URL. Посредством URL можно ссылаться на любые объекты и папки. Например, к общей папке можно обратиться, используя формат http:// Exchange Server name/exchange/foldername. Аналогично для почтовых ящиков используется формат http:// Exchange Server name/exchange/alias. В Microsoft такую функцию назвали Web Store. Появление этого компонента подтверждает заявление представителей корпорации о том, что IS может быть частью Web-узла. При этом хранилище Exchange заменяет каталоги NTFS, которые обычно применяются для хранения информации Web-узла. Общие папки подходят для хранения содержимого Web, но, возможно, администраторы не захотят поощрять Web-доступ к папкам в почтовых ящиках. Следует отметить, что IS обрабатывает определенные HTTP-запросы лучше, чем NTFS. IS использует методы кэширования потоков оперативно доставляя информацию клиентам. NTFS не может обеспечить поток информации, когда этого требует формат данных (например, видеоизображение или звук).

Большинство серверов Exchange выполняет не только базовый набор встроенных функции. Разработчиками осздано много программ независимых компаний, расширяющих возможности Exchange Server новыми функциями. При переходе на Platinum следует обновить и протестировать эти программные продукты, чтобы они не вызывали сбоев системы при работе на новой версии Exchange с разделенной службой IS.

В Platinum содержатся элементы, которые будут совершенствоваться вплоть до того момента, когда Microsoft выпустит конечный продукт. Но уже бета-версия Platinum показывает, что в технологии Exchange Server происходят значительные изменения. Этот продукт в Microsoft воспринимают как будущую базу масштабируемой системы, способной удовлетворить требования как самого маленького почтового сервера, так и самого большого из тех, которыми обладают Internet-провайдеры. Разбиение IS — важная часть стратегии Microsoft Exchange Server, отражающая одно из фундаментальных изменений в семействе Exchange Server. Прежде чем разбивать хранилище на составные части, необходимо сперва выделить основные задачи и четко спланировать структуру почтовой системы. Однако само по себе появление новых функциональных возможностей, бесспорно, не может не радовать.

Консультантам часто приходится оценивать возможный размер частного хранилища в Microsoft Exchange Server 5.5. При решении этой задачи я предпочитаю пользоваться следующей формулой.

[(лимит для почтового ящика * число почтовых ящиков)/коэффициент кратности вхождения] + <кэш для удаленных записей>

Лимит для почтового ящика — это объем данных, который резервируется для каждого пользователя. Обычно этот параметр колеблется в пределах от 20 до 50 Мбайт. В Exchange Server используется модель единого хранения. Другими словами, если сообщение адресовано 10 получателям, работающим на сервере, одна копия текста этого сообщения размещается в базе данных, а в почтовом ящике каждого получателя создаются указатели на этот текст. Коэффициент кратности вхождения определяет, насколько эффективно используется данная возможность. Исходя из собственного опыта, могу сказать, что это соотношение обычно меняется в диапазоне от 1,2 (очень плохо) до 2 (нормально), а иногда даже 3 или выше (очень хорошо). Серверы, с которыми работают пользователи, посылающие много сообщений на внешние адреса, будут иметь меньший коэффициент, чем серверы, на которых большинство сообщений передается в почтовые ящики того же самого сервера. Определить это значение для данного сервера можно с помощью Performance Monitor, проанализировав счетчик MSExchangeIS PrivateSingle Instance Ratio Performance Monitor. Наконец, кэш для удаленных записей представляет собой долю общей емкости хранилища, которую занимают удаляемые программным образом записи. Система сохраняет «мягко» удаляемые записи до тех пор, пока не истек назначенный им срок хранения, а затем удаляет их окончательно. Этот показатель зависит от длительности срока сохранения. Можете с достаточной степенью точности полагать, что кэш будет составлять примерно 5% базы данных, если срок равен 7 дням, и до 10%, если он составляет 14 дней.

Приведем пример такого расчета.

Объем хранилища = (50 Мбайт * 3000 почтовых ящиков)/1,8) + 5% = 87,5 Гбайт (округленно).

Согласны вы с этим или нет, но хранилище объемом 87,5 Гбайт нельзя назвать очень уж большим. Во многих компаниях размер частных хранилищ превышает 100 Гбайт и, как мне доводилось слышать, иногда достигает даже 200 Гбайт. Чем больше база данных, тем большего она требует внимания от администратора (и, кстати, соблюдения строгого режима резервного копирования). Современное аппаратное и программное обеспечение намного надежнее, чем прежде, но ошибки, тем не менее, время от времени все же возникают.

Наконец, необходимо обратить внимание и на тот факт, что выполнение полного резервного копирования столь значительных по объему баз данных требует длительного времени. Следует убедиться в том, что подсистема ввода/вывода может справиться с нагрузкой. Сервер, даже оснащенный самыми быстрыми процессорами, абсолютно бесполезен, если из него нельзя быстро извлечь необходимые данные.