пятница, 20 июля 2012 г.

Синхронизация копий баз данных в кластерах Exchange 2007/2010

imageКак известно, между базами данных почтовых ящиков, в кластерных решениях MS Exchange 2007/2010, информация реплицируется при помощи файлов журнала транзакций (transaection logs), далее мы их будем просто называть логами транзакций. Давайте разберемся подробнее как этот механизм работает.

Копирование логов транзакций

Итак, логи транзакций генерируются на сервере с активной базой данных, затем копируются на пассивный сервер и проигрываются в базу.

На Exchange 2010 процессом копирования логов управляет служба Replication Service, которая самостоятельно отправляет (push) логин на все сервера баз банных в DAG группе. Этот процесс кардинально отличается от аналогичного в Exchange 2007, где вместо push`a имеет место механизм pull, т.е. сервер с пассивной копией “забирает” логи с активного сервера.

Сам процесс передачи файлов также отличается – в Exchange 2010 для каждой базы данных открывается свой собственный TCP сокет, при этом в Exchange 2007 используется SMB протокол, и более того, открывается только одна сессия на сервер.

Примечание: Перед пересылкой логи в Exchange 2010 сжимаются! По оценкам Microsoft это снижает трафик репликации примерно на 20%.

Проигрывание логов (Transaction log replay)

После того, как информация будет передана на сервер с пассивной копией, она должна быть “проиграна” (replays) в базу. В Exchange 2010 за это отвечает служба Information Store, в отличи от Exchange 2007, где работала служба MS Exchange Replication Service. Использование IS дает преимущество в том, что IS всегда “знает” в каком состоянии база. В Exchange 2007 процесс заполнения базы происходил за пределами IS, таким образом кэш в памяти сервера не мог начать использоваться быстро и при активации пассивной копии Information Store`y приходилось очень много читать с диска и заполнять кэш, для того, чтобы быстро обеспечить пользователей оперативной информацией, в результате при переключении I/O резко возрастало.

Примечание: DAG - граница репликации данных. Т.е. логи нельзя проиграть в базу из другого DAG-a.

Несмотря на все описанные выше различия, принципиально, при переходе от Exchange 2007 к 2010, процесс копирования остался прежним и заключается в следующих этапах:

  • Закрытые Information Store-ом файлы логов копируются на все сервера, где есть копии базы. Копирование происходит в определенную папку. Файлы обрабатываются "инспектором". Процесс этот асинхронный - как появляется новый закрытый лог, так он сразу копируется.

Исключение появилось в Exchange 2010 SP1, где был внедрен новый тип репликации - Block replication, т.е. репликация идет блоками, это значит, что SP1 не ждет когда файл лога будет закрыт. Как только данные записаны на диск, они сразу реплицируются. Если в процессе Block replication возникают ошибки или сложности (например накопилось более 4-х логов в очереди, в следствии большой загруженности сети), то Exchange переходит обратно в File Mode Replication.

  • Инспектор постоянно проверяет "свою папку" на предмет наличия новых файлов и проверяет каждый файл на целостность. Если файл проходит проверку, то он перемещает его в другую папку (replay directory). Если файл проверку не проходит, то выполняется попытка его повторной загрузки. Если эта попытка оказывается неудачной, то копия базы считается плохой и инициируется процесс повторного заполнения базы (reseed).
  • Log replayer проигрывает полученные файлы из папки “replay directory” в базу каждые 60 сек., или каждые 10 новых логов. Это процесс выполняется при помощи службы Information Store`a. Процесс похож на soft recover выполняемый утилитой eseutil.
  • Truncate deletor удаляет проигранные Log replayer`ом файлы. Более подробно про удаление файлов транзакций мы поговорим в следующей статье.
  • Механизм Incremental seeder отвечает за то, что база находится в консистентном состоянии после восстановления или переключения.

Состояние базы и количество логов в очередях на копирование и проигрывание можно посмотреть в EMC (см. рис.)

image

Заключение

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

Комментариев нет:

Отправить комментарий