Необходимым условием репликации общих папок в пределах организации является наличие процесса синхронизации каталога между площадками в ее составе. Прежде, чем будет выполнена настройка репликации той или иной папки, в каталоге должны присутствовать сведения о площадках в составе организации, серверах в составе этих площадок и иерархии общих папок. Поскольку в общем случае серверы, участвующие в процессе репликации, не имеют непосредственного соединения друг с другом, процесс репликации общих папок опирается на обмен специальными почтовыми сообщениями.
Каждая общая папка имеет свой домашний сервер, на котором она была впервые создана. Все остальные копии папки на серверах организации называются репликами исходной папки. Каждая реплика хранит информацию о домашнем сервере исходной папки. Реплики и исходная папка абсолютно равноправны с точки зрения участия в репликации изменений, вносимых в содержащиеся в них данные. Процесс репликации данных выполняется по принципу multi-master, это означает что, если пользователь создает, модифицирует или удаляет сообщение в реплике, внесенные изменения автоматически распространяются на все остальные копии папки, включая исходную. Единственное отличие между исходной папкой и репликой заключается в том, что при удалении исходной папки на домашнем сервере, будут удалены все ее реплики. Удаление же реплики без одновременного прекращения репликации приведет к тому, что реплика будет воссоздана по завершении следующего цикла репликации.
Поддержка режима multi-master при репликации общих папок требует наличия механизмов определения степени новизны сообщения и разрешения конфликтов. Первая задача решается следующим образом. В момент создания сообщению присваивается уникальный идентификатор, содержащий информацию о месте его создания. Кроме того, с сообщением ассоциируется список, содержащий счетчик модификаций, увеличиваемый при каждом изменении сообщения и хранящий информацию о сервере, на котором были внесены эти изменения. Если входящее сообщение имеет большее значение счетчика модификаций, оно замещает существующее, в противном случае - просто игнорируется. Конфликт возникает в том случае, когда сообщение подвергается модификации одновременно в двух хранилищах и, следовательно, имеет различную историю модификации. Факт возникновения конфликта регистрируется хранилищем, и запрос на его разрешение отправляется лицу, назначенному администратором ответственным за папку (Folder Contact), в которой произошел конфликт. Ответственный за папку разрешает конфликт на свое усмотрение. Ущемленная сторона в лице пользователя, внесшего отвергнутые изменения, получает соответствующее уведомление. Процесс разрешения конфликта поясняется рисунком 2.17.
Репликация общих папок может выполняться по принципу проталкивания (push replication) или вытягивания (pull replication). В первом случае инициатором процесса репликации выступает сервер, обладающий исходной папкой или ее репликой. Он принудительно рассылает служебные сообщения на создание реплик своим партнерам. Во втором случае инициатором выступает сервер, который желает получить копию папки, хранящейся на другом сервере. В данной версии Exchange запросы на организацию репликации принимаются и обрабатываются серверами автоматически.
Рис. 2.17. Разрешение конфликтов репликации общих папок
Репликация факта удаления сообщения происходит аналогично тому, как это делается при синхронизации каталога, с тем лишь исключением, что удаление может быть выполнено на любой реплике пользователем с соответствующими полномочиями. Кроме того надгробие сообщения выполняет еще одну полезную функцию, оно препятствует помещению в папку модифицированных версий удаленного сообщения, реплицируемых с серверов, еще не получивших уведомления о том, что данное сообщение было удалено.
Вместе с данными, хранящимися в общих папках, реплицируются также их настройки, сделанные администратором исходной папки. К ним относятся:
Для оптимизации доступа клиентов к ресурсам общих папок используются следующие приемы:
Рис. 2.18. Использование показателя близости для управления порядком опроса серверов при обращении к общей папке
В случае частичного разрушения информации в результате сбоя, незаконченного процесса репликации, потери сообщений при передаче или при восстановлении хранилища с резервной копии общая папка на сервере может оказаться не синхронизированной с другими репликами в составе организации. В случае возникновения одной из указанных ситуаций, сервер в течение заданного времени ожидает получения недостающей информации от своих партнеров по репликации, после чего самостоятельно инициирует запрос к двум ближайшим серверам, которые по его сведениям располагают репликами требуемой информации. Данный механизм называется обратным заполнением (Backfilling) реплицируемых папок. Схема обратного заполнения приведена на рисунке 2.19. После получения первого ответа и устранения рассогласований восстанавливается исходная схема репликации.
Рис. 2.19. Обратное заполнение общих папок
Назад | Содержание | Вперед