Перемещение почтовых ящиков Exchange 2010 и их отказоустойчивость

Одна из целей отказоустойчивости почтовых ящиков Exchange 2010 заключается в том, чтобы минимизировать потерю информации. В Exchange 2010 SP1 мы добавили непрерывную репликацию - блочный режим (continuous replication - block mode) для дальнейшего уменьшения потери информации во время сбоев. Однако на высоконагруженных почтовых базах с очень высокой скоростью генерации журналов существует большая вероятность потери информации, если репликация на пассивные копии почтовых баз не может справиться с генерацией журналов.

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

• Пример 1: Вы -администратор, и решили переместить почтовый ящик из DatabaseA в DatabaseB. Перемещение завершается успешно. Однако сразу после завершения операции перемещения сервер с активной копией базы DatabaseB выходит из строя. Другая копия DatabaseB активируется с потерей информации, т.к. AttemptCopyLastLogs не может завершиться успешно. В результате порция информации почтового ящика будет потеряна.
• Пример 2: Вы - администратор, и решили переместить набор почтовых ящиков в рамках вашей организации Exchange 2010 RTM, при этом размер информации помещается в единственный файл журнала размером 1 Мбайт. Вы выполняете перемещение, и почтовые ящики успешно переносятся из DatabaseA в DatabaseB. Сразу после этого сервер с базой DatabaseB выходит из строя. Другая копия базы DatabaseB активируется с потерей информации, т.к.  AttemptCopyLastLogs не может завершиться успешно. Во время отказа активный файл журнала, который содержит всю связанную с перемещением почтовых ящиков информацию, не был реплицирован на другие копии. В результате копия монтируется, но без перемещенных почтовых ящиков в базе DatabaseB. Кроме того, поскольку  служба Exchange Mailbox Replication отметила перемещение почтовых ящиков как завершенное, то эти почтовые ящики больше не находятся в базе DatabaseA.

Как вы понимаете, это серьезные проблемы потери информации. К счастью мы подумали о них во время разработки Exchange 2010.

Data Guarantee API & the Mailbox Replication Service

Exchange 2010 включает Data Guarantee API, который используется службой репликации почтовых ящиков (Mailbox Replication Service, MRS) для того, чтобы проверять "здоровье" системы копирования почтовых баз на основе определенных настроек почтовой базы, которые задаются системой или администратором. В частности, Data Guarantee API может использоваться для:

1. Проверки  Replication Health - подтверждение того, что доступно заданное число копий почтовой базы.
2. Проверки Replication Flush - подтверждение того, что необходимые файлы журналов успешно применены к заданному числу копий почтовой базы.

После выполнения API возвращает следующую информацию вызывающему приложению:

1. Статус возвращает одно из следующих значений:

o Retry: возвращается как  результат промежуточных ошибок, которые делают невозможным проверку состояния почтовой базы.
o Satisfied: возвращается, когда почтовая база соответствует заданным условиям или база не реплицируется.
o NotSatisfied: возвращается, когда почтовая база не соответствует заданным условиям. Кроме того вызывающему приложению возвращается информация о том, почему получен код NotSatisfied.

2. Как долго вызывающему приложению следует ждать перед повторной проверкой.

a. Если информация о копировании не получена, то время ожидания по умолчанию составляет  10 секунд.
b. Если не найдено ни одной здоровой копии почтовой базы, то время ожидания по умолчанию составляет 2 минуты.
c. Если здоровая копия почтовой базы найдена, но она отстает в репликации, то время ожидания по умолчанию составляет 1 минуту.

Максимально возможное время ожидания 10 минут.

DataMoveReplicationConstraint

Значение свойства DataMoveReplicationConstraint почтовой базы определяет, сколько копий почтовой базы должно быть возвращено в запросе. Свойство DataMoveReplicationConstraint имеет следующие варианты значений:

• None: Это значение по умолчанию, когда создается почтовая база. Когда значение равно None, условия в data guarantee API игнорируются. Это значение должно использоваться только для почтовых баз, которые  не реплицируются.
• SecondCopy: Как минимум одна пассивная копия потовой базы должна соответствовать условиям Data Guarantee API. Это значение по умолчанию, когда вы добавляете вторую копию почтовой базы.
• SecondDatacenter: Как минимум одна копия пассивной почтовой базы в другом сайте Active Directory должна соответствовать условиям Data Guarantee API.
• AllDatacenters: Как минимум одна копия пассивной почтовой базы в каждом сайте Active Directory должна соответствовать условиям Data Guarantee API.
• AllCopies: Все копии почтовой базы должны соответствовать условиям Data Guarantee API.

Check Replication Health

Когда Data Guarantee API определяет "здоровье" инфраструктуры копий почтовых баз, вычисляются следующие параметры:

1. Если DataMoveReplicationConstraint имеет значение SecondCopy, то для данной реплицируемой почтовой базы как минимум одна пассивная копия почтовой базы должна:

a. быть "здоровой";
b. иметь очередь применения журналов с задержкой не более 10 минут;
c. иметь длину очереди не более  10 журналов;
d. иметь среднюю длину очереди не более 10 журналов (средняя длина очереди вычисляется на основе количества раз, которое приложение запрашивало статус почтовой базы.

2. Если DataMoveReplicationConstraint имеет значение SecondDatacenter, то для данной почтовой базы как минимум одна копия пассивной почтовой базы в другом сайте Active Directory должна:

a. быть "здоровой";
b. иметь очередь применения журналов с задержкой не более 10 минут;
c. иметь длину очереди не более  10 журналов;
d. иметь среднюю длину очереди не более 10 журналов.

3. Если DataMoveReplicationConstraint имеет значение AllDatacenters, то для данной почтовой базы активная копия должна быть смонтирована, а пассивная копия в каждом сайте AD должна:

a. быть "здоровой";
b. иметь очередь применения журналов с задержкой не более 10 минут;
c. иметь длину очереди не более  10 журналов;
d. иметь среднюю длину очереди не более 10 журналов.

4. Если DataMoveReplicationConstraint имеет значение AllCopies, то для данной почтовой базы активная копия должна быть смонтирована, а все пассивные копии почтовой базы должны:

1. быть "здоровыми";
2. иметь очередь применения журналов с задержкой не более 10 минут;
3. иметь длину очереди не более  10 журналов;
4. иметь среднюю длину очереди не более 10 журналов.

Check Replication Flush

Data Guarantee API в 2010 SP1 может  также использоваться для проверки того, что заданное число копий почтовой базы применяет требуемые транзакционные журналы. Это проверяется сравнением временной метки последнего примененного журнала с временной меткой подтверждения от вызывающего сервиса (в большинстве случаев это временная метка последнего файла журнала, который содержит требуемую информацию) плюс 5 секунд (это связано с отклонениями системного времени). Если метка времени применения больше, чем время подтверждения, то DataMoveReplicationConstraint удовлетворяется.

Если метка времени применения не больше, чем время подтверждения, то DataMoveReplicationConstraint не удовлетворяется.

Mailbox Replication Service

MRS вызывает Data Guarantee API несколько раз за время выполнения запроса на перемещение. Как описано в документации в статье Общие сведения о запросах на перемещение, перемещение почтовых ящиков выполняется в следующем порядке:

1. Запрос на перемещение обновляет Active Directory и помещает сообщение в системный почтовый ящик, расположенный в почтовой базе целевого сайта Active Directory. Затем MRS запрашивает Data Guarantee API, чтобы определить здоровье  целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
2. Затем MRS начинает перемещение информации, клонируя структуру почтового ящика в целевую почтовую базу. Затем MRS запрашивает Data Guarantee API, чтобы определить здоровье  целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
3. Затем MRS выполняет начальную синхронизацию, создавая мгновенный снимок почтового ящика-источника и реплицируя его папки и содержимое. Во время этого процесса MRS запрашивает Data Guarantee API каждые 10 секунд, чтобы определить "здоровье"  целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
4. Затем MRS выполняет дополнительную синхронизацию, реплицируя изменения, появившиеся по отношению к первоначальному мгновенному снимку. Во время этого процесса MRS запрашивает Data Guarantee API каждые 10 секунд, чтобы определить "здоровье"  целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
5. Затем MRS блокирует почтовый ящик-источник.
6. Затем MRS выполняет дополнительную синхронизацию, чтобы провести изменения, сделанные с момента последнего события синхронизации, кроме того, копирует другие данные почтового ящика. Начиная SP1, MRS будет заставлять целевую базу применить активный транзакционный журнал, если он еще не применился, тем самым гарантируя, что непрерывная репликация может реплицировать информацию этого журнала, который содержит данные синхронизации перемещаемого почтового ящика. MRS определяет выполнилось ли это успешно с помощью вызова Check Replication Flush в Data Guarantee API.
7. Затем MRS запрашивает Data Guarantee API, чтобы определить "здоровье" инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
8. Затем MRS обновляет учетную запись пользователя в Active Directory, отмечая, что перемещение завершено.
9. Затем MRS заблокирует целевой почтовый ящик.
10. Затем MRS изменяет состояние почтового ящика в почтовой базе-источнике в soft-deleted. Эта функция была добавлена в Exchange 2010 SP1, и гарантирует, что в случае потери целевой почтовой базы вы сможете восстановить почтовый ящик из предыдущей почтовой базы.

Если во время шагов с 1 по 4 Data Guarantee API вернет NotSatisfied или Retry, MRS поместит запрос на перемещение в очередь и будет повторять запрос каждые 30 секунд. MRS помещает запрос на перемещение в очередь не более чем на 15 минут, после чего аварийного его завершает. Если в пределах этих 15 минут возвращается ответ Satisifed, MRS будет автоматически возобновлять запрос на перемещение.

Во время шага 6 MRS будет ждать максимум 30 минут, пока Data Guarantee API не вернет Satisfied (повторяя запрос каждые 10 секунд). Если Satisfied не получен, то MRS будет аварийно завершать перемещение почтового ящика.

Когда запрос на перемещение завершается аварийно, он не будет возобновляться сервисом MRS автоматически. До выполнения Resume-MoveRequest администратору следует выполнить Get-MoveRequestStatistics для того, чтобы определить причину аварийного завершения перемещения. После этого администратор может выполнить Resume-MoveRequest.

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

Определение подходящего для вашей среды DataMoveReplicationConstraint

Вы должны правильно настроить DataMoveReplicationConstraint на каждой почтовой базе в соответствии со следующими правилами:

Заключение

Чтобы минимизировать потерю информации в результате перемещения почтовых ящиков в высокодоступной среде Exchange 2010, установите правильное значение DataMoveReplicationConstraint на каждой почтовой базе.