Перенос почтовых ящиков: способ Exchange 2010

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

Рост объема ящиков

Во всех предшествующих версиях Exchange миграция почтовых ящиков осуществляется в рамках процесса, который инициирует ее. Иначе говоря, если вы инициируете перенос почтовых ящиков с консоли управления Exchange 2007 или Exchange 2003, перемещение будет продолжаться до тех пор, пока последний объект не будет перенесен с исходного сервера на целевой. В ходе этого процесса администратор не сможет выполнять на консоли какие-либо иные действия, а пользователь будет лишен возможности обращаться к своему почтовому ящику: системе Exchange требуется исключительный доступ к этому объекту, ибо только так она может обеспечить надежный перенос всего содержимого почтовых ящиков. Данный процесс функционирует нормально, его содержание понятно администраторам — так зачем же его менять?

Все дело в постоянно растущих размерах почтовых ящиков. Отключение пользователей для переноса их почтовых ящиков на другой сервер вполне допустимо, когда стандартная квота на почтовый ящик составляет 100 Мбайт и только считанное число почтовых ящиков может разрастись до размеров в 1 Гбайт и более. Но когда квота на размер почтового ящика составляет в среднем 1 Гбайт и нередко встречаются ящики с квотами в 10 Гбайт и выше — это уже совсем другое дело. В ноябре 2009 года представители Microsoft заявили о намерении компании предоставлять подписчикам онлайн-версии Exchange почтовые ящики вместимостью 25 Гбайт (см. статью «Global Organizations Choose Microsoft Cloud Applications», http://www.microsoft.com/presspass/press/2009/nov09/11–02bposexpandspr.mspx). Это решение было принято в рамках прямой конкурентной борьбы с корпорацией Google, которая тоже предоставляет корпоративным пользователям почтовой службы Gmail ящики размером в 25 Гбайт (см. статью «Run your business, not your email server», http://www.google.com/apps/intl/en/business/gmail.html).

Выделение 25 Гбайт дискового пространства на каждый почтовый ящик можно только приветствовать, если это хранилище никогда не придется перемещать или если такое перемещение не будет создавать проблем для пользователя. Специалисты Microsoft проектировали Exchange 2010 как платформу для удобного управления очень большими почтовыми ящиками, и многие изменения, внесенные ими в Exchange Information Store, предназначены для смягчения воздействия на сервер многогигабайтных почтовых ящиков с десятками тысяч объектов. Изменения были внесены и в Microsoft Office Outlook 2007 SP2, а также в более новые версии продукта (включая версию Outlook 2010, выпуск которой ожидается в мае– июне 2010 года) для обеспечения существенного повышения производительности Outlook при обращении к большим почтовым ящикам.

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

Запрос на перенос

В запросе на перенос представлено намерение администратора переместить тот или иной почтовый ящик из одной базы данных в другую. База данных может размещаться на сервере Exchange 2010 или на сервере более старой версии Exchange 2007 SP2 либо Exchange 2003 SP2, находящемся в той же или в какой-то иной почтовой организации. Обратите внимание: мы уже не употребляем выражений «исходный сервер» и «целевой сервер». В Exchange 2010 фокус внимания перемещается на базы данных, поскольку в этой системе именно базы данных, а не серверы являются объектами управления. Как многим, вероятно, известно, базы данных Exchange 2010 могут быть представлены несколькими копиями и могут перемещаться с одного сервера почтовых ящиков на другой. Употребление терминов «исходный сервер» и «целевой сервер» лишено смысла, поскольку мы не знаем, на каком сервере размещается ныне активная копия базы данных, в которую планируется перенести почтовый ящик.

Запросы на перенос формируются с консоли управления Exchange Management Console (EMC) или с помощью составной команды New-MoveRequest в командной консоли Exchange Management Shell (EMS). В любом случае пользователь может выбрать группу почтовых ящиков и сгенерировать отдельный запрос на перенос для каждого из них. Как показано на экране 1, я выделил группу почтовых ящиков для перемещения из одной базы данных в другую (почтовые ящики можно сортировать по базе данных, что облегчает процесс выделения группы из той или иной базы данных), затем нажал кнопку New Local Move Request на панели Actions консоли EMC. В результате открылось окно мастера, генерирующего запросы на перенос. Такое групповое перемещение можно осуществить, если все почтовые ящики будут располагаться в одной и той же базе данных. Если же почтовые ящики нужно располагать в различных базах данных, для формирования запросов на перенос необходимо запускать мастер отдельно для каждой целевой базы.

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

Далее мастер предлагает ответить на вопрос, что делать в том случае, если в исходных почтовых ящиках будут обнаружены поврежденные объекты. Администратор может пропустить целый почтовый ящик, отказавшись от его перемещения, или поручить системе Exchange игнорировать определенное число поврежденных объектов. По умолчанию предлагается вариант с отказом от перемещения почтового ящика, что представляется мне крайней мерой — за исключением тех случаев, когда речь идет о только что созданном почтовом ящике. В предшествующих версиях Exchange вопрос о форматах объектов ставился не столь жестко, и, если у вас имеются почтовые ящики, использовавшиеся в системах Exchange 2003 либо Exchange 2000, или ящики, перенесенные из других систем обработки электронной почты, существует вероятность того, что в некоторых почтовых ящиках будет содержаться несколько поврежденных объектов.

Если вы решите пропустить поврежденные объекты и при этом Exchange обнаружит несколько таких объектов в процессе перемещения, эти объекты будут проигнорированы, и вы можете потерять часть данных, хотя речь идет о данных, которые не могут быть прочитаны системой Exchange 2010. Я обычно устанавливаю значение этого параметра равным 5, дабы Exchange пропускала до 5 поврежденных объектов в ходе одного перемещения. Чтобы выяснить, были ли найдены поврежденные объекты, можно заглянуть в журнал миграции. Exchange сохраняет подробности двух последних перемещений того или иного почтового ящика в виде скрытых объектов, расположенных в корневом каталоге почтового ящика. Как будет показано ниже, пользователь может обратиться к этим отчетам с помощью команды Get-MailboxStatistics. Когда все будет готово, нажмите кнопку ОК, и мастер сформирует запросы на перенос для каждого почтового ящика.

Обработка запросов на перенос

На экране 2 представлен набор запросов на перенос, сформированных мастером. Консоль EMC извлекает эту информацию из каталога Active Directory (AD); для этого выполняется поиск всех запросов на перенос в данном домене или в той области получателя, которая указывается в разделе конфигурации получателя консоли EMC. Считывание данных описанным образом удобно применять в небольших организациях, однако в крупных организациях быстродействие системы, вероятно, будет снижаться. Но администраторам из больших организаций, пожалуй, есть смысл обрабатывать запросы на перенос с помощью командной консоли Exchange (EMS), ибо эта оболочка функционирует быстрее, является более гибкой и предоставляет больше данных о запросах на перенос.

Как показано на экране 2, запросы на перенос могут иметь различные статусы. «Помещенный в очередь» запрос — это запрос, ожидающий обработки средствами службы репликации почтовых ящиков MRS. MRS выполняется на каждом сервере клиентского доступа и регулярно запрашивает AD о наличии запросов на перенос на своем узле. По умолчанию служба MRS, выполняемая на сервере клиентского доступа, может одновременно перемещать до пяти почтовых ящиков. Пользователь может модифицировать файл конфигурации MRS таким образом, чтобы служба одновременно перемещала большее количество ящиков, но в обычных условиях делать этого не стоит: вы рискуете «задавить» целевые серверы рабочей нагрузкой, сгенерированной в процессе обработки входящих почтовых данных. К примеру, Exchange обновляет свои индексы контента по мере поступления на сервер данных из почтового ящика, так чтобы по завершении процесса миграции на сервере имелся полный индекс. Возможно, существуют некоторые граничные условия, создающие обстоятельства, при которых MRS может обрабатывать данные быстрее, но пока у нас нет достаточного опыта работы с MRS в производственных сетях и мы не знаем, как следует настраивать ее в различных условиях.

Когда запрос на перенос извлекается из очереди, MRS создает копию почтового ящика в целевой базе данных и начинает передавать объекты. Если с почтовым ящиком ассоциирован архив, последний тоже переносится на новое место. На этой стадии запросы на перенос имеют статус «перемещается» (Moving). Если вы выделите индивидуальный запрос на перенос и в панели Actions щелкнете на элементе Properties, то увидите дополнительные данные, такие как размер почтового ящика.

По завершении передачи всех данных MRS приостанавливает свою работу и определяет, изменилось ли содержимое исходного почтового ящика за время, прошедшее с момента начала миграции; эта задача легко решается проверкой времени последнего обновления почтового ящика. Если изменения имели место, MRS выполняет добавочное обновление с целью синхронизации содержимого двух копий почтового ящика; по завершении этого процесса служба переключает указатель AD на почтовый ящик пользователя, так чтобы он указывал на только что перемещенную копию. Пользователь теряет связь с почтовым ящиком только на тот момент, когда осуществляется переключение. Пользователи Outlook Web App (OWA) получают сообщение об ошибке (см. экран 3), извещающее о том, что почтовый ящик временно недоступен. Если они подождут несколько секунд и повторят попытку, Exchange к этому времени завершит переключение на перемещенный почтовый ящик и сможет восстановить соединение. Пользователи Outlook на настольных системах получают всплывающее сообщение о том, что для восстановления соединения с перемещенным почтовым ящиком им следует полностью выйти из программы Outlook и вновь запустить ее. Специалисты Microsoft хотели бы пойти дальше в автоматизации этого процесса, но текущая версия Outlook предусматривает кэширование определенных касающихся почтового ящика сведений, таких как идентификатор MAPI, которые должны быть сброшены, перед тем как Outlook сможет восстановить соединение. Этот механизм сохранен и в версии Outlook 2010.

По завершении миграции Exchange присваивает ей статус «завершенной» (Complete). Если вам нужно будет вновь переместить данный почтовый ящик, придется удалить запрос на перенос из консоли EMC. Для этого нужно выделить его и на панели Actions щелкнуть на элементе Clear Move Request, как показано на экране 4. Это действие не вполне очевидно, и специалисты Microsoft планируют встроить в будущие версии Exchange определенный механизм для автоматического удаления выполненных запросов на перенос, но пока эту операцию приходится выполнять вручную.

Перемещения по расписанию

EMC не предусматривает возможности планирования запросов на перенос. Когда пользователь создает новый запрос, EMC помещает его в очередь, и служба MRS обрабатывает этот запрос по мере готовности. Однако надо сказать, что имеется два способа создания запроса на перенос с помощью EMS, которые обеспечивают определенный уровень контроля действий MRS. Вы можете использовать параметр -Suspend или параметр -SuspendWhenReadyToComplete. К примеру, можно задействовать параметр -Suspend, как в следующей команде:

New-MoveRequest
     -id ' Anil Patel' -Suspend
     -TargetDatabase ' IT Department'

В этом случае поставленный в очередь запрос регистрируется, но данные в целевую базу данных не копируются до тех пор, пока запрос на перенос не будет исполнен. Подобным же образом используется параметр -SuspendWhenReadyToComplete:

New-MoveRequest -id ‘ Anil Patel’
     -SuspendWhenReadyToComplete
     -TargetDatabase ‘ IT Department’

Основное отличие этой команды состоит в том, что она дает возможность службе MRS снять первоначальную копию содержимого почтового ящика. Скопировав почтовый ящик, служба MRS переводит запрос на перенос в статус «остановленный» (Suspended) и сообщает, что условно 90% содержимого почтового ящика скопировано. Оставшиеся 10% — это инкрементная синхронизация, которую MRS выполняет после возможности исполнения остановленного запроса на перемещение.

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

В обоих случаях повторение запроса на перемещение осуществляется с помощью команды Resume-MoveRequest:

Resume-MoveRequest -id ' Anil Patel'

Если вы хотите следить за тем, что происходит в процессе миграции, можете выбрать запрос на перенос в консоли EMC и просмотреть его свойства. Вы также можете получить более подробную информацию, воспользовавшись командой Get-MoveRequestStatistics. К примеру, чтобы получить данные о запросе на перенос, нужно передать идентификатор почтового ящика и выбрать интересующие вас поля. В следующем примере я выбираю имя почтового ящика, текущий статус миграции, общий размер объектов в почтовом ящике, число объектов, процент завершения процесса (условный), количество переданных байтов и имена переданных объектов:

Get-MoveRequestStatistics
     -id ' Anil Patel' |
     Select DisplayName, Status,
     TotalItemSize, TotalMailboxItemCount,
     PercentComplete, BytesTransferred,
     ItemsTransferred

При выполнении этой команды вы, возможно, обратите внимание на очевидное несоответствие между отображаемым общим размером почтового ящика и количеством байтов, фактически перемещенных в процессе миграции. Объясняется это двумя обстоятельствами. Наряду с объектами, которые планировалось перенести на новое место, MRS перемещает и метаданные почтовых ящиков, такие как объекты, хранящиеся в скрытых папках и содержащие настройки пользователей. Если почтовый ящик размещается на сервере Exchange 2010, MRS перемещает содержимое корзины (удаленные объекты, которые пользователи могут восстанавливать до истечения срока их хранения). Этот подход отличается от принципов работы предшествующих версий, в которых в процессе миграции почтовых ящиков содержимое корзины игнорируется. Изменение было необходимо для поддержки реализованных в Exchange 2010 средств обнаружения и функций, обеспечивающих соблюдение законодательных требований. Было бы весьма прискорбно, если бы в ходе перемещения почтовых ящиков из системы исчезали объекты, представляющие интерес при расследовании случаев мошенничества и тому подобных дел, поэтому MRS копирует содержимое корзины наряду с другими объектами почтового ящика, а средства индексирования контента фиксируют детали этих объектов, с тем чтобы их можно было обнаружить и в новом ящике. Архивные ящики — новое средство версии Exchange 2010; если почтовый ящик имеет архив, последний переносится тоже (при этом понятно, что по размерам архивный ящик может быть гораздо больше, нежели основной, так что вносите соответствующие поправки в расчет времени, необходимого для выполнения всей операции).

Накопленный к настоящему времени опыт свидетельствует о том, что сервер Exchange 2010 перемещает содержимое почтовых ящиков со скоростью от 4 до 6 Гбайт в час. Точный показатель при любой конфигурации зависит от времени суток, других нагрузок на систему, а также от производительности дисков, где индексирование содержимого и формирование журнала транзакций создают нагрузку на подсистему хранения. Как бы то ни было, согласно статистическим данным, представленным корпорацией Microsoft и проверенным в производственных условиях, Exchange 2010 перемещает данные почтовых ящиков по меньшей мере на 70% быстрее, нежели система Exchange 2007.

Отчеты о миграции

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

$MRep = Get-MailboxStatistics
     -id TR -IncludeMoveReport
$MRep.MoveHistory[0] |
     Export-CSV ' C:TEMP
          MoveReport.CSV'

Мы используем объект для приема переданных по конвейеру выходных данных команды Get-MailboxStatistics, затем выделяем данные по истории миграции из этого объекта и экспортируем их в файл со значениями, разделенными запятыми (CSV file), который можно открыть в программе Microsoft Excel или в текстовом редакторе. На экране 5 показана отредактированная версия части выходных данных этой команды. Здесь видно, как MRS подключается к исходному и целевому ящику и инициализирует целевой ящик, перемещая в него объекты, а затем приостанавливает свою работу и проверяет, не появились ли новые объекты за время миграции.

Управление службой MRS

MRS — это служба, перемещающая почтовые ящики из исходной базы данных в целевую. Ее работа управляется текстовым файлом конфигурации MSExchangeMailboxReplicationService.exe.config, находящимся в папке двоичных файлов Exchange. Вы можете изменить рабочие параметры MRS, модифицировав данный файл в текстовом редакторе. В таблице представлены параметры MRS и управляющие этой службой параметры. Чтобы изменения, внесенные в эти параметры, вступили в силу, необходимо перезапустить процесс MRS.

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

Быстрая миграция с гибкими возможностями

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

Тони Редмонд (exchguru@windowsitpro.com)  — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services