Как функционирует непрерывная репликация кластера (CCR) в Microsoft Exchange Server?

Хранилища Microsoft Exchange Server состоят из двух базовых элементов: журналов транзакций и базы данных. Информация сначала записывается в кэш памяти Extensible Storage Engine, потом в журнал транзакций через модуль записи журналов, а затем в базу данных (файл. edb). Операции записи в базу данных выполняются через другой набор записей в буферы кэша Information Store, которые затем переносятся на диск модулем отложенной записи. Максимальный размер файлов журнала транзакций Exchange 2007 — 1 Мбайт. Если журнал транзакций заполняется или истекает определенное время, то создается новый файл журнала, а текущий последовательно переименовывается в формате E (группа хранения; восьмизначное шестнадцатеричное число).log. Эти журналы транзакций пересылаются в базу данных через различные компоненты Exchange, как описано выше. После того как все содержимое журнала транзакций переписано в базу данных, файл контрольных точек (Edb.chk) обновляется с учетом того, что транзакция записана в базу данных и не должна считываться повторно, если потребуется выполнить восстановление после аварии.

При использовании CCR строится двухузловой кластер Windows Server 2003 или Windows Server 2008, и на пассивном узле запускается Exchange с собственным экземпляром базы данных, без клиентских соединений или предоставляемых служб. Имеется два экземпляра данных, по одному для каждого узла, поэтому строится модель без общих компонентов, в которой данные не являются единственной точкой отказа. Первоначальный экземпляр базы данных формируется в ходе процесса, именуемого заполнением (seeding): существующая база данных копируется из активного узла в хранилище пассивного. Начальное копирование может занять много времени, в зависимости от размера базы данных. После того как база данных организована, пассивный узел извлекает журналы транзакций из активного узла через скрытый, защищенный общий каталог. После того как журналы транзакций закрыты, пассивный узел копирует их в папку инспектора, инспектирует журналы, а затем вносит журналы в свой экземпляр базы данных почтовых ящиков. Таким образом, производится обновление базы данных. Данная структура показана на рисунке 1. В случае планового переключения на резервный узел пассивный узел становится активным, подключается к ранее активному (теперь пассивному) узлу, копирует все оставшиеся файлы журналов (в том числе только что закрытый), вносит журналы в свою базу данных и подключается к сети.

 

Рисунок 1. Кластер с непрерывной репликацией

При неплановом переключении на запасной ресурс текущий активный узел может быть недоступен, поэтому некоторые журналы транзакций, скорее всего, будут утеряны. Пассивный узел обратится к транспортной корзине на серверах Hub Transport в том же сайте, в котором находится кластер, в поисках пропавших данных, и любые недостающие данные будут внесены в базу данных. Поскольку два узла являются частью кластера, переключение выполняется автоматически. Именно по причине использования серверов Hub Transport CCR-кластеры Exchange 2007 могут охватывать несколько подсетей, но не несколько сайтов Active Directory.

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

Можно ли заполнить пассивный экземпляр CCR из архивной копии?

Отчасти. Автоматический процесс заполнения обычно происходит через сеть, но базу данных можно перевести в автономный режим, скопировать ее на носитель, а затем скопировать в пассивный узел. Компания Microsoft не поддерживает восстановление архива активной базы данных на пассивном узле, но такая функциональность предусмотрена в некоторых сторонних продуктах архивации.

Как функционирует резервная непрерывная репликация Standby Continuous Replication (SCR)?

SCR — компонент репликации в Exchange 2007 SP1 и более поздних выпусках. SCR функционирует аналогично непрерывной репликации кластера (CCR). Закрытые файлы журналов извлекаются сервером SCR и вносятся в SCR-копию почтовой базы данных. Основное различие между CCR и SCR заключается в том, что SCR не задействует серверы в составе кластера. Это означает, что переключение на SCR — процедура, выполняемая вручную, требующая изменения объектов в Active Directory (AD) с указанием на новый сервер почтовых ящиков. SCR обычно используется для репликации во вспомогательное хранилище в другом месте, так как компьютер SCR не обязательно располагается в одном сайте AD с почтовым сервером, с которого выполняется репликация. Процесс резервного копирования SCR показан на рисунке 2. Группа хранения, защищенная SCR, может содержать только одну базу данных. Группа хранения может иметь неограниченное число реплик SCR, но оптимальный вариант — не более четырех. Источником для SCR может быть некластеризованный сервер почтовых ящиков, кластеризованный сервер почтовых ящиков CCR или кластеризованный сервер почтовых ящиков SCC. Сервер SCR может быть целевым для нескольких серверов почтовых ящиков.

 

Рисунок 2. Процесс резервного копирования SCR

Еще одно различие между CCR и SCR заключается в задержке внесения реплицированных журналов в локальный экземпляр почтовой базы данных. У такой задержки много причин, в том числе обработка связанных с потерями переходов на другой ресурс, если источник SCR является кластером CCR, и предотвращение логических искажений в SCR. По умолчанию журналы задерживаются на 50 журналов транзакций и 24 часа (выбирается более позднее событие), и база данных на SCR не будет заполняться до тех пор, пока не достигнута отметка в 50 журналов транзакций и 24 часа. 24-часовую задержку можно изменить с помощью атрибута ReplayLagTime, но нельзя изменить задержку в 50 журналов транзакций.

Что представляют собой переходы между ресурсами с потерями и расхождение в Exchange?

Переходы между ресурсами с потерями относятся к решению непрерывной репликации кластера (CCR) Exchange 2007 с высокой готовностью. Переходы между ресурсами с потерями доставляют неудобства из-за метода асинхронного копирования журналов транзакций из активных узлов в пассивные по мере закрытия журналов транзакций. Если на активном узле произойдет авария и он станет недоступным, прежде чем пассивный узел сможет извлечь все журналы транзакций из активного узла, то произойдет переключение ресурса с потерями.

Переключение с потерями не приводит к потере данных. Как описано в приведенных выше ответах, пассивный узел запросит серверы Hub Transport в своем сайте AD и восстановит все недостающие сообщения. Отличие заключается в том, что пассивный узел продолжит нумерацию журналов транзакций с номера последнего полученного журнала. Если последний файл журнала на предшествующем пассивном узле был E0000000050.log, то следующий будет E0000000051.log, даже если на предшествующем активном узле уже есть номера журналов E0000000051.log и E0000000052.log, как показано на рисунке 3.

 

Рисунок 3. Переключение с потерями

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

Служба репликации может обнаружить расхождение, сравнивая последний файл журнала в экземпляре CCR с тем же файлом журнала на активном узле. Если их содержимое одинаково, значит, все в порядке. Если они различны, служба репликации возвращается назад, просматривая каждую пару файлов журналов, пока не обнаружит двух совпадающих файлов, указывающих момент, когда два узла были синхронны. Все файлы журналов после этой точки удаляются (включая открытый журнал, Enn.log, если он обнаружен), и копируются журналы из активного узла, что обеспечивает одинаковое содержимое файла журнала на двух узлах.

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

Можно предположить, что в обычных обстоятельствах с очень быстрой записью журналов транзакций в базы данных расхождения в базах данных будут частым явлением при переключениях с потерями. В результате потребуется частое повторное заполнение всей базы данных. Это могло бы произойти, но компания Microsoft дополнила Exchange 2007 компонентом Last Log Resiliency, который ограничивает потребность в повторных полных заполнениях.

Что представляет собой компонент Last Log Resiliency в Exchange 2007?

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

Чтобы избежать этой ситуации, Exchange 2007 размещает компонент Last Log Resilience на активном узле CCR. Last Log Resilience задерживает операции записи из журналов транзакций в базу данных для 10 журналов транзакций. Задержка 10 журналов транзакций базы данных почтовых ящиков активного узла CCR уменьшает вероятность записи в локальную базу данных сведений из журналов транзакций, которые не попадут в пассивный узел в случае переключения узлов с потерями. Задержка в 10 журналов транзакций происходит только на активном узле кластера CCR, но не на пассивном. Схема показана на рисунке 4.

 

Рисунок 4. Использование Last Log Resilience

Здесь зеленым цветом обозначены файлы журналов транзакций, записанные в базу данных. На активном узле CCR последний журнал транзакций имеет номер 12, но из-за задержки в 10 журналов транзакций последний журнал, записанный в базу данных, имеет номер 2. В пассивном узле журналы принимаются по возможности быстро и немедленно вносятся в базу данных, поэтому база данных пассивного узла опережает активный узел. Опережение пассивного узла — не проблема в случае переключения узлов, так как расхождения нет, просто одна база данных опережает другую.

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP