Если у кого-то вдруг возникнет желание горячо поспорить с администратором сервера Microsoft Exchange, стоит начать с досужего совета о том, как правильно спроектировать и настроить хранилище. Exchange 2000 и Exchange 2003 предусматривают множество настроек хранилища, так что выбрать оптимальную конфигурацию бывает весьма затруднительно. К тому же существует достаточное количество общепринятых заблуждений относительно «правильной» настройки Exchange, которые еще сильнее сбивают с толку и затрудняют и без того нелегкий выбор. В этой статье мы рассмотрим несколько не столь широко известных способов проектирования хранилища Exchange, которые помогут понять, как все это работает, и принять верное решение при проектировании конкретной конфигурации.

Сегментирование хранилища

Сервер Exchange 5.5 использует единую базу данных, при этом на каждом сервере может быть не более трех баз: база почтовых ящиков, база общих папок и база каталога. Такой принцип позволяет создавать почти немыслимые конфигурации; например, у меня был один клиент, у которого размер базы почтовых ящиков на сервере Exchange 5.5 составлял около 140 Гбайт.

Разработчики Exchange 2000 в свою очередь предложили концепцию множественных групп хранения, каждая из которых может содержать множественные базы данных; Exchange 2003 использует аналогичный механизм. Группа хранения SG (логический объект) — это сущность информационного хранилища Exchange (IS), которое функционирует внутри процесса store.exe и контролирует журналы транзакций всех почтовых ящиков и базы данных общих папок в группе. Каждая база данных является отдельным логическим объектом, которому физически на диске соответствуют два файла.edb и.stm. Во время обновления с Exchange 5.5 до Exchange 2000 или Exchange 2003 многие принимают установки миграции по умолчанию. На самом деле это не лучший вариант, поскольку в данном случае вместо того, чтобы в полной мере воспользоваться теми преимуществами, которые предоставляют множественные базы данных, мы получаем в наследство от Exchange 5.5 громадную монолитную базу данных почтовых сообщений.

Для одной группы хранения в одно и то же время можно производить резервное копирование либо восстановление только одной базы данных. Если же у вас имеются множественные группы хранения, можно одновременно архивировать либо восстанавливать множественные базы данных. Предположим, в компании есть база данных размером 140 Гбайт, которая разделена на четыре группы хранения, по 35 Гбайт на базу данных каждой. Резервное копирование разделенной подобным образом базы данных занимает столько же времени, сколько резервное копирование единой базы данных на 140 Гбайт; однако резервное копирование индивидуальной базы данных каждой из групп хранения займет вчетверо меньше времени. Если вы используете для архивации ленту стриммера, то можно добавить второй привод и производить резервное копирование двух баз данных параллельно, сокращая таким образом время архивирования вдвое. Но наибольший выигрыш в производительности можно получить, если осуществлять параллельное восстановление из резервной копии множественных баз данных. Если вы ранее сделали резервные копии множественных групп хранения, то можно одновременно восстанавливать по одной базе данных из каждой группы хранения и значительно сократить общее время восстановления.

Есть и еще один аргумент в пользу разделения хранилища: таким образом вы значительно облегчите себе выполнение соглашения об уровне предоставления услуг. Предположим, что согласно SLA администратор обязан в случае сбоя восстановить доступ к электронной почте сотрудникам руководящего звена в течение часа, а всем остальным — в течение пяти часов. Если почтовые ящики руководителей и рядовых сотрудников будут размещены в разных группах хранения, то базы данных можно будет восстановить независимо. Учитывая тот факт, что начальников обычно намного меньше, чем подчиненных, удовлетворить требования SLA будет довольно легко.

В рекомендациях Microsoft к первому выпуску Exchange 2000 значилось пожелание создавать наименее возможное количество дополнительных групп хранения, поскольку для каждой такой группы требовалось резервирование дополнительных 100-250 Мбайт оперативной памяти, а это весьма значительный объем для того времени. Пакет обновлений 3 для Exchange 2000 вносит модификации в процесс резервирования в требованиях к оперативной памяти, благодаря чему ее объем, необходимый для дополнительных групп хранения, существенно сократился. Нынешняя рекомендация Microsoft — создавать как можно больше групп хранения. Как показано на приведенном выше примере, Microsoft рекомендует создание четырех групп хранения c одной базой данных для каждой вместо одной группы хранения c четырьмя базами данных, поскольку каждая группа хранения Exchange имеет свой набор журналов.

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

RAID

Давным-давно системные администраторы спорили — а так ли хорош массив дисков RAID в сочетании с Exchange? Спорили долго, пока наконец не решили: RAID-массив играет существенную роль в защите данных Exchange. Нынешние дебаты сводятся к тому, какой тип RAID-массива лучше использовать.

Чтобы решить, какой тип RAID-массива применять, нужно помнить, что каждый уровень RAID влияет на соотношение производительность/восстанавливаемость. То, что хорошо для одного типа данных, может не подойти для другого. Рассмотрим том, распределенный по двум физическим дискам. Распределение значительно увеличивает скорость обмена, поскольку приложения, производя чтение или запись, могут обращаться ко всем физическим дискам одновременно. Однако в такой конфигурации выход из строя одного физического диска равносилен выходу из строя всего тома. Следовательно, подобная конфигурация допустима в тех случаях, когда на первом месте стоит высокая производительность, а кратковременный сбой дисковой подсистемы не означает конец света (например для очередей SMTP на почтовом шлюзе). Однако надо быть большим любителем острых ощущений, чтобы разместить на таком томе базы данных.

Когда целостность данных стоит на первом месте (например, для журналов транзакций, системного тома), специалисты Microsoft рекомендуют использовать зеркалирование томов. Когда и целостность данных, и скорость доступа к ним одинаково важны, можно применять RAID 5 или RAID 0+1. При этом RAID 0+1 является более бюджетным решением.

Журналы и базы данных

Если во время развертывания или обновления Exchange вы принимаете предложенные по умолчанию пути размещения файлов журнала и базы данных, то все данные Exchange будут размещены на одном томе. Однако Microsoft рекомендует размещать журналы транзакций и базы данных на разных томах из-за различий в механизмах доступа. Файлы журналов всегда пишутся последовательно и во время считывания журнала читаются так же. В свою очередь базы данных и пишутся, и читаются произвольно, согласно запросам пользователей. Таким образом, существует две причины для того, чтобы не размещать файлы журналов и баз данных на одном дисковом томе: значительно снижается производительность и ставится под сомнение сама возможность восстановить данные в случае дискового сбоя. Этот риск сохраняется, даже если вместо обычных дисков используются RAID-массивы. Рассмотрим случай, когда у нас есть один большой массив RAID 5 из десяти физических дисков, на котором размещены журналы транзакций и базы данных двух групп хранения. С точки зрения высокой производительности и возможности восстановления при сбое в данном случае можно будет использовать два физических диска для создания зеркалированного тома для хранения журналов транзакций, семь дисков отвести под RAID 5 для размещения баз данных и один диск оставить неразмеченным на случай горячей замены. Учитывая особенности механизма доступа к базам данных, можно создать для их раздельного размещения разные тома RAID 5 (каждый со своим набором физических дисков).

Также необходимо помнить, что после создания полной резервной копии журналы транзакций очищаются. Если после завершения архивирования вы обнаружите множество файлов журналов, процесс архивирования нельзя считать удачным и необходимо разобраться в причинах происходящего. Не следует удалять файлы журналов транзакций вручную, особенно если у вас нет для этого веских причин, например рекомендации сделать это от Центра поддержки и обслуживания Microsoft. И даже в таком случае сначала нужно убедиться, что у вас есть копия журналов, сохраненная в надежном месте.

Циклическое журналирование

Циклическое журналирование — малопонятная возможность Exchange, которую многие администраторы не без оснований оставляют без внимания, как потенциально рискованную. Когда включается режим циклического журналирования, Exchange ограничивает размер дискового пространства, которое отводится под журналы, и перезаписывает журналы транзакций поверх предыдущих по исчерпании резерва. И хотя такой метод теоретически имеет право на существование, на практике это означает, что у вас может не быть полного набора журналов для конкретной базы данных, что подразумевает невозможность ее полного восстановления в случае сбоя.

Однако существует пара ситуаций, в которых включение циклического журналирования для группы хранения может быть оправданным. Первый такой случай — внешние серверы SMTP. Служба SMTP в Exchange 2003 требует подключения базы данных почтовых ящиков для создания отчетов о несостоявшейся доставке. С течением времени, если циклическое журналирование не включено, журналы транзакций этой базы данных займут все свободное дисковое пространство. Еще циклическое журналирование может потребоваться, если вам необходимо решить задачу, связанную с большим количеством транзакций. Например, если вам нужно переместить 500 почтовых ящиков с одного сервера на другой за одну ночь. Подобное действие порождает на обоих серверах рост объема журналов транзакций, сравнимый по размеру с объемом перемещенной почты. Чтобы решить эту проблему, нужно выполнить полное резервное копирование на обоих серверах, а затем включить циклическое журналирование для группы хранения, из которой перемещаются почтовые ящики. Можно также включить циклическое журналирование и на принимающем сервере, хотя из соображений безопасности лучше этого не делать. Во всех остальных случаях лучше оставлять циклическое журналирование выключенным во избежание перезаписи транзакционных данных, которые могут потребоваться в будущем.

SAN

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

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

Рекомендации поставщиков SAN, как правило, соответствуют рекомендациям Microsoft, о которых говорилось выше. Основные расхождения во мнениях касаются главным образом размера и типа дисков, используемых в определенных конфигурациях, а также организации массивов RAID (например, устройства от Network Applicance обычно используют RAID 4, а не RAID 5). Прежде чем вверить почтовые ящики Exchange решению SAN, следует оценить его производительность с помощью инструмента Microsoft Jetstress tool (jetstress.msi). Загрузить этот инструмент можно по адресу http://www.microsoft.com/downloads/details.aspx?familyid=94b9810b-670e-433ab5ef-b47054595e9c&displaylang=en. Рекомендуется привлечь к процессу развертывания инженеров поставщика SAN. Это обеспечит уверенность в том, что предложенное решение и его конкретная реализация полностью отвечают всем требованиям, а также обезопасит от неприятных и, возможно, весьма недешевых сюрпризов в будущем, когда вам, может быть, потребуется увеличить размеры хранилища.

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

Поль Робишо - ведущий инженер компании 3sharp, имеет сертификаты MCSE и Exchange MVP. Создатель Web-сайта
http://www.exchangefaq.org. troubleshooter@robichaux.net

Проверочная таблица для создания эффективного хранилища Exchange

  • Создайте множественные группы хранения с одной базой данных на каждую.
  • Определите, какой тип RAID-массива оптимально подойдет для имеющейся конфигурации.
  • Разместите журналы транзакций и базы данных на разных томах.
  • Включите при необходимости циклическое журналирование.
  • Узнайте рекомендации поставщика решения SAN по организации хранилища Exchange.