Во время начальной разработки сервера Exchange 2007 в Интернете ходили слухи о том, что хранилища будут переведены в SQL. Но эти планы достаточно быстро были отклонены, и сейчас дело обстоит так, что мы не увидим Exchange-сервер с хранилищами на SQL до выхода E15 (это следующая версия после E14). Но это не значит, что в сервере Exchange 2007 не появились никакие изменения и улучшения, связанные с хранилищами. Хотя Exchange-сервер до сих пор основан на более или менее не изменившейся базе данных ESE, была проведена большая работа по улучшению расширяемости, надежности и оптимизации продукта, который стал гораздо лучше, по сравнению с предыдущими версиями.
Exchange 2007 – настоящее 64-битное приложение
Ни для кого не будет сюрпризом, что в реальных условиях будет поддерживаться только 64-битная версия Exchange 2007. Поскольку сервер Exchange 2007 разработан как 64-битное приложение, он получает доступ к большему количеству памяти, что гарантирует высокую производительность и надежность, при этом увеличивается размер почтового ящика и количество учетных записей на сервер. Теперь размер по умолчанию почтового ящика, а также размер Общих папок, стал чуть более 2ГБ!
Рисунок 1: Новые ограничения почтового ящика по умолчанию в Exchange 2007
Будучи 64-битным приложением, Exchange 2007 сократил до 75 процентов требования на количество операций I/O в секунду. Также в сервере улучшилось использование существующей системы хранилищ, что позволит администраторам использовать даже в самом требовательном окружении такие недорогие варианты, как Непосредственно подключаемые хранилища (Direct Attached Storage – DAS).
Как видно из Рисунка 1, изменились и настройки удаленных элементов и продолжительности использования почтовых ящиков. В сервере Exchange 2003 по умолчанию удаленные элементы сохранялись в течение 7 дней, в Exchange 2007 – 14 дней. Это же верно и для Общих папок.
Группы хранилищ и базы данных сервера Exchange 2007
Группа хранилищ – это набор баз данных почтовых ящиков и/или Общих папок, которые совместно используют единый план резервного копирования и единый набор файлов журналов транзакций. Группы хранилищ управляют отдельными серверными процессами. Идея разделения баз данных в группы хранилищ состояла в том, чтобы уменьшить накладные расходы от использования нескольких наборов файлов журналов транзакций.
Как многие из вас должны помнить, сервер Exchange 2003 Standard edition поддерживал 1 группу хранилищ и 2 хранилища – почтовых ящиков и общих папок (исключая, естественно, группу хранилища для восстановления). Сервер Exchange 2003 Enterprise Edition поддерживал всего 4 группы хранилищ, каждая из которых могла состоять из максимум 5 баз данных. Размер базы данных в Exchange 2003 Standard edition был ограничен 16 ГБ (поднимался до 75 ГБ при использовании пакета обновлений Exchange 2003 Service Pack 2). Если говорить о сервере Exchange 2003 Enterprise edition, то предела размера базы данных там не было (на самом деле был – 26 Терабайт, но это лимит был обусловлен только аппаратным обеспечением).
Также как и предыдущие версии, сервер Exchange 2007 поставляется в двух вариантах: Standard Edition и Enterprise Edition. Вариант Exchange Server 2007 Standard edition поддерживает всего 5 групп хранилищ и 5 баз данных. В отличие от сервера Exchange 2003 и предыдущих версий Exchange-сервера, теперь в версии Standard Edition нет ограничений для хранилища баз данных. Сервер на базе Exchange 2007 Enterprise edition поддерживает до 50 групп хранилищ и максимум 50 баз данных на сервер. При использовании сервера Exchange 2007 вы можете, как и в случае с сервером Exchange 2003, создать до 5 баз данных в каждой группе хранилищa, но лучше всего создавать 1 базу данных для каждую группу хранилищ. Зачем же иметь между группами и базами отношение один к одному? В основном для того, чтобы различные сценарии восстановления после сбоев работали быстрее.
Рисунок 2: Управление базами данных в консоли Exchange Management Console
Как и в случае с сервером Exchange 2003, группы хранилищ можно располагать на одном диске, но для улучшения производительности лучше всего держать их отдельно друг от друга, хотя, для некоторых организаций, у которых, например, 30 групп хранилищ, это звучит несколько неубедительно.
Как я уже говорил, базы данных в сервере Exchange 2007 основаны на практически неизменившейся Расширяемой оболочке хранилища (Extensible Storage Engine – ESE). Как многие знают, ESE зависит от двух файлов баз данных: .EDB и .STM. Задачей файла потока (.STM) было хранение потоков содержимого сообщений Интернета, как определено в RFC 822. Поскольку .EDB-файл не очень подходит для хранения потоков содержимого сообщений Интернета, идея использования .STM-файл была понятна. Но в сервере Exchange 2007 .STM-файл не используется, так же, как и Устанавливаемая файловая система Exchange-сервера (Exchange Installable File System – ExIFS). Таким образом, было достигнуто снижение общего использования дисковых операций I/O для Exchange 2007.
Как и в предыдущих версиях, сервер Exchange 2007 также поддерживает и единое место хранения сообщений. Это значит, что если сообщение отослано одному получателю, а копии его отправлены еще 20 пользователям, чьи почтовые ящики располагаются в одном хранилище, сервер хранит только одну копию этого сообщения в базе данных. Сервер Exchange 2007 создает указатели, которые ссылаются на оригинального получателя и на 20 дополнительных получателей сообщения. Если оригинальный получатель и 20 дополнительных получателей переносятся в другое хранилище почтовых ящиков, только одна копия сообщения переносится в новое хранилище. Те из вас, кто знаком с SIS, видят, что данная функциональность не изменилась со времен сервера Exchange 2003.
Изменения размера файла журнала транзакций
Другим изменением в сервере Exchange 2007 стало то, что размер файлов журналов транзакций стал равным 1МБ вместо 5 МБ, как было в предыдущих версиях Exchange-сервера.
Рисунок 3: Новый размер файлов журналов транзакций сервера Exchange 2007
Какая же была причина для этого изменения? В предыдущих версиях Exchange-сервера, если в случае аварии были уничтожены последние несколько файлов журналов, которые еще не были зафиксированы в базе данных, вам приходилось восстанавливать базу данных для того, чтобы ее присоединить. В сервер Exchange 2007 включена новая функция, называемая Устойчивость последних журналов (Lost Log Resilience – LLR), которая хранит в памяти несколько последних журналов до того, как база данных не будет отключена. Это значит, что теперь не возникнет ситуаций, когда, например, часть журнала 5 запишется в базу, а часть журнала 4 нет. Преимущество в том, что если вы не против потерять несколько последних журналов, вы можете сказать Exchange-серверу просто отбросить данные и присоединить базу данных.
Так что причиной того, что размер файлов уменьшился до 1 МБ, является уменьшение загрузки LLR. Теперь если вы потеряете последний журнал, вместе с ним вы потеряете только 1 МБ данных, а не 5 МБ.
Другим улучшением, которое стоит отметить, является то, что нумерация файлов журналов теперь может превышать миллион. Как вы, возможно, знаете, в предыдущих версиях было установлено ограничение в 1 миллион, поэтому если база данных использовалась достаточно долго и создавала миллион журналов, вам приходилось останавливать базу и заново запускать ее, начиная с журнала №1 ("сброс нумерации журналов "). Для большинства баз данных это случалось раз в несколько лет. При уменьшенном размере журнала и увеличения количества сообщений, проходящих через систему, разработчики Exchange-сервера решили, что 4 миллиардов будет достаточно для максимального номера журнала.
Общие папки
Общие папки до сих пор поддерживаются в сервере Exchange 2007, но помните, что им теперь не придают такого значения, как раньше, а это значит, что, скорее всего, в следующей версии Exchange-сервера их не будет (имя текущей версии - E14). Зная об этом, подумайте о переходе к другому решению, например, SharePoint.
Замечание:
Даже учитывая тот факт, что Общие папки теперь не имеют такого значения, как раньше, Microsoft будет поддерживать их до конца 2016 года, так что у вас есть куча времени.
Одним из главных недостатков является то, что количество задач администрирования Общих папок, доступных из консоли управления Exchange Management Console, значительно ограничено. Поэтому, если вам нужно сделать что-нибудь, кроме создания, удаления или перемещения базы данных общих папок, а также настройки ограничений, вам придется использовать либо оболочку Exchange Management Shell, либо Outlook либо консоль управления System Manager на сервере Exchange 2003, являющемся частью организации Exchange.
Рисунок 4: Создание общей папки с помощью оболочки Exchange Management Shell
Так что если ваша компания широко использует общие папки, я рекомендую сохранить в организации рабочий сервер Exchange 2003 до тех пор, пока вы не избавитесь от общих папок совсем или пока не выйдет пакет обновлений Exchange 2007 SP1 (надеюсь, административные задачи в нем будут выполнимы через графический интерфейс EMC).
Высокая работоспособность сервера Exchange 2007
Как вы, возможно, уже читали в моих последних статьях по Exchange 2007, в сервер Exchange 2007 также включены некоторые возможности повышения работоспособности, такие как Постоянная локальная репликация (Local Continuous Replication - LCR), Постоянная кластерная репликация (Cluster Continuous Replication - CCR) и Кластеры с единственной копией (Single Copy Clusters - SCC). Я не буду описывать подробно все эти технологии, если вам интересно, просто прочтите соответствующие статьи.
Обратите внимание, что технология LCR поддерживается в сервере Exchange 2007 Standard edition, но для использования технологий CCR и SCC вам необходим сервер Exchange 2007 Enterprise edition. Поскольку технологии CCR и SCC основаны на службе Microsoft Clustering Service (MSCS), для их использования в вашем окружении вам необходимо установить сервер Exchange 2007 на Windows 2003 Server Enterprise edition.
На данный момент это все, и теперь вы должны быть лучше подготовлены к планированию внедрения сервера Exchange 2007 в вашей организации.