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

Сообщение компании Microsoft о намерении активировать для корпоративных подписчиков Office 365 «действительно бездонный архив» (http://blogs.office.com/2015/06/03/announcing-auto-expanding-highly-scalable-

archives-for-office-365-email/) вызвало волну интереса пользователей. Как именно они собираются это реализовать? Очевидно, что речь идет не об очередном увеличении доступного дискового пространства, поскольку всем хорошо известно, что предоставление пользователям обширных дисковых хранилищ уже было декларировано как одна из особенностей Office 365.

И, самое главное, как же обычный архивный почтовый ящик может трансформироваться таким образом, чтобы полностью отвечать пользовательским аппетитам, сколь неуемны бы они ни были? Основная идея проста: пользователи продолжают работать с архивом, не задумываясь об объемах хранящейся там информации, а Exchange Online при необходимости автоматически расширяет архив таким образом, чтобы «переварить» все, чтобы было туда заброшено. Причем неважно, каким именно образом это было сделано — в ходе обычной работы, импорта файлов PST или автоматической архивации в соответствии с политиками хранения. Но это вовсе не означает, что отдельно взятый архивный почтовый ящик просто вырастет до объема 1 Тбайт и выше. Как мы увидим далее, решение основано на принципиально новом подходе к уже существующей технологии, и тем оно удивительнее.

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

Указанной иерархии «известно», в каком именно почтовом ящике общих папок содержится та или иная общая папка. Таким образом, когда от пользователя приходит запрос на доступ к общей папке, иерархия может просто перенаправить этот запрос в соответствующий почтовый ящик. А если происходит какое-либо изменение, например общую папку перемещают в другой почтовый ящик, данный факт фиксируется в иерархии и описанная схема продолжает работать.

Здесь надо отметить, что Office 365, помимо всего прочего, включает функцию авторазделения (auto-split), назначение которой — автоматически создавать новые почтовые ящики общих папок, когда один из ящиков вдруг становится слишком большим (более 50 Гбайт). После того как создается новый почтовый ящик общих папок, общие папки, содержавшиеся в исходном почтовом ящике, распределяются между новым и старым почтовыми ящиками. А теперь вспомним об архивных почтовых ящиках и представим, что аналогичная штука могла бы происходить и с архивами пользователей. Все начинается с единичного архивного почтового ящика; после того, как этот почтовый ящик достигает размера 50 Гбайт, Exchange автоматически добавляет новый почтовый ящик и формирует логический набор или цепочку, состоящую из двух почтовых ящиков. Если накапливается еще 50 Гбайт, к набору добавляется третий почтовый ящик и т. д. При этом различные почтовые ящики из одного архивного набора даже не обязаны находиться в одной и той же базе данных. Производительность такой схемы гарантированно будет на высоком уровне, поскольку отдельный почтовый ящик чувствует себя весьма неплохо в пределах 100-гигабайтного, поддерживаемого Exchange, максимума. А для конкретного пользователя все это будет выглядеть как привычный единый, «бесшовный» архив.

Когда к описанному выше архивному набору добавляется новый почтовый ящик, Exchange автоматически переносит часть содержимого первоначального архива в новый почтовый ящик, чтобы перераспределить нагрузку между всеми почтовыми ящиками, входящими в этот архивный набор. Перераспределением папок между всеми доступными почтовыми ящиками архивного набора занимается служба репликации почтовых ящиков Mailbox Replication Service (MRS), использующая тот же самый тип инкрементной синхронизации, который применяется при перемещении обычных почтовых ящиков и общих папок.

Конечно, здесь все же не обходится без некоторой «магии». Современный архивный почтовый ящик связан со своим основным почтовым ящиком посредством глобального идентификатора GUID, хранящегося как одно из его свойств. Exchange может использовать GUID для того, чтобы отыскать этот архивный почтовый ящик в базе данных, где он хранится. «Бездонный» же архив реализуется посредством замены этого единственного GUID, связывающего основной почтовый ящик с его «классическим» архивом, на список сопряженных идентификаторов GUID. Каждый из этих идентификаторов указывает на отдельный архивный почтовый ящик размером до 50 Гбайт. Набор таких архивных почтовых ящиков обрабатывается Exchange так, как если бы это был единый огромный почтовый ящик. Клиенты также видят его как единую сущность, поэтому в обновлении Outlook или Outlook Web App необходимости нет, ведь задача клиентов — только запросить архивную информацию у Exchange, а вот найти и предоставить запрашиваемую информацию — задача целиком Exchange. Соответственно на его же плечи ляжет выяснение, в каком именно из сопряженных почтовых ящиков содержится нужная информация.

Получить подробную информацию об идентификаторах GUID можно, запустив команду Get-Mailbox, которая предназначена для отображения свойств почтового ящика. Если мы взглянем на свойство MailboxLocations, то увидим что-то вроде этого:

Get-Mailbox -Identity TRedmond | Format-List MailboxLocations
MailboxLocations: {1;0370f354-2752-4437-878d-cf0e5310a8d4; Primary;
eurprd04.prod.outlook.com;353ce1b5-5044-4974-93f0-7b6f4a54edf8,
1; afc1e472-0826-498e-b990-85de223e809d;
   MainArchive; eurprd04.prod.outlook.com;
353ce1b5-5044-4974-93f0-7b6f4a54edf8}

Отображаемая командой Get-Mailbox информация о местоположении искомого почтового ящика разделена на две секции. Первая относится к основному почтовому ящику, вторая — к архивному. В данном случае мы видим только единичные почтовый ящик и архив. Если бы у данного почтового ящика имелись бы дополнительные архивы, то они были бы перечислены в «архивной» секции как почтовый ящик 2, 3, 4 и т. д. В приведенном выше примере мы можем увидеть для наших двух почтовых ящиков следующую информацию.

Основной почтовый ящик

  • ExchangeGUID (который привязывает почтовый ящик к учетной записи пользователя).
  • «Primary» указывает на то, что эти данные относятся к основному почтовому ящику пользователя.
  • Если используется Exchange Online (как в нашем случае), то отображается имя леса, в котором расположена база данных почтового ящика. Для локально развернутых серверов это значение будет пустым.
  • Идентификатор GUID базы данных, в которой расположен почтовый ящик.

Архив

  • ArchiveGUID (который присутствует, только если у почтового ящика активирован архив).
  • MainArchive указывает на то, что эти данные являются первыми в архивном наборе. Если бы присутствовали прочие архивные почтовые ящики, они были бы отмечены как AuxArchive.
  • Как уже отмечалось выше, здесь указано имя леса Exchange Online, содержащего архивный почтовый ящик.
  • Идентификатор GUID базы данных, содержащей данный архив.

В нашем случае и основной почтовый ящик, и его архив расположены в одной и той же базе данных (в этом можно убедиться, выполнив команду Get-Mailbox с отображением параметров Database и ArchiveDatabase). И, как можно было бы ожидать, они также находятся в одном и том же лесу Exchange Online. Что интересно, при использовании параметра MailboxLocations отображается и первичный почтовый ящик, и архив. Сразу возникает вопрос: не собирается ли компания Microsoft использовать тот же самый подход для создания в будущем расширяемых основных почтовых ящиков?

Разделение общих папок и отслеживание фактического местонахождения их содержимого посредством обращения к списку местоположений — простая и проверенная схема, которая отлично работает для общих папок. И можно с полным на то основанием ожидать, что она будет успешно работать и для расширяемых архивов.

Рассматриваемая функция сейчас тестируется небольшим количеством подписчиков Office 365. Кроме того, планируется реализовать ее в сервере Exchange 2016. Однако теперь мне хотелось бы посмотреть на реакцию администраторов локальных серверов, насколько им придется по душе это новшество, которое обязательно повлечет за собой дополнительные затраты на расширение дискового пространства, необходимого для хранения этого «бездонного» архива. Конечно, можно получить немало преимуществ, особенно с точки зрения соответствия требованиям законодательства, когда у вас есть возможность манипулировать архивными PST, однако все это потребует весьма значительных ресурсов хранения.

В целом здесь еще есть над чем поработать. Например, невозможно перенести один из архивов на локальный сервер, поскольку в этом случае серверу Exchange придется перепаковать все архивы в цепочке, чтобы сформировать большой архивный почтовый ящик, прежде чем его можно будет переместить на локальный сервер Exchange 2010 или Exchange 2013. Серверы Exchange 2016 новый формат понимают, поэтому перемещение на эти серверы осуществить гораздо проще.

Компания Microsoft стимулирует пользователей к переносу данных в «облако» посредством захвата файлов PST и их импорта в Office 365, и в этом свете наличие расширяемых архивов, готовых к приему и обработке всех входящих данных, наполнено особенным смыслом. Существует ли аналогичная потребность для локальных серверов Exchange, пока неясно. Но не сомневаюсь, что в скором времени мы это узнаем.

Купить номер с этой статьей в PDF