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

1. Увеличение надежности за счет наличия независимых копий каждого файла на разных файлах-серверах.

2. Распределение нагрузки между несколькими серверами.

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

На рисунке 3.12 показанные три возможных средства репликации. При использовании первого средства (а) программист самый управляет всем процессом репликации. Когда процесс создает файл, он делает это на одном определенном сервере. Потом, если нужно, он может сделать дополнительные копии на других серверах. Если сервер каталогов позволяет сделать несколько копий файла, то сетевые адреса всех копий могут быть ассоциированы с именем файла, как показано на рисунке снизу, и когда имя найдено, это означает, что найденные все копии. Чтобы сделать концепцию репликации более понятной, рассмотрим, как может быть реализованная репликация в системах, основанных на отдаленном монтировании, типа UNIX. Предположим, что рабочий каталог программиста имеет имя /machine1/usr/ast. После создания файла, например, /machine1/usr/ast/xyz, программист, процесс или библиотека могут использовать команду копирования для того, чтобы сделать копии /machine2/usr/ast/xyz и machine3/usr/ast/xyz. Возможно программа использует в качестве аргумента строка /usr/ast/xyz и последовательно попробует отворять копии, пока не достигнет успеха. Эта схема хотя и работает, но имеет много недостатков, и по этим причинам ее не следует использовать в распределенных системах.

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

Последним рассмотрим метод, который использует групповые связи (рисунок 3.12,в). В этом методе все системные вызовы ЗАПИСАТЬ передаются одновременно на все серверы, таким образом копии создаются одновременно с созданием оригинала. Есть два принципиальных расхождения в использовании групповых связей и ленивой репликации. Во-первых, при ленивой репликации адресуется один сервер, а не группа. Во-вторых, ленивая репликация происходит в фоновом режиме, когда сервер имеет промежуток свободного времени, а при групповой репликации все копии создаются в то самое   время.

Рис. 3.12.  а) Точная репликация файла; б) Ленивая репликация файла;
в) Репликация файла, что использует группу

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

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

Чтобы предотвратить ситуацию, когда через отказ первичный сервер не успевает оповестить об изменениях все повторные серверы, изменения должны быть сохранены в постоянном устройстве, которое запоминает, еще к изменению первичной копии. В этом случае после перезагрузки серверу есть возможность сделать проверку, не проводились ли любые восстановления в момент краха. Недостаток этого алгоритма типичный для централизованных систем - сниженная надежность. Во избежание его, используется метод, предложенный Гиффордом и известный как "голосование". Пусть есть n копий, тогда изменения должны быть внесенные в любые W копий. При этом серверы, на которых хранятся копии, должны отслеживать порядку номера их версий. В случае, когда какой-либо сервер выполняет операцию чтения, он оборачивается с запросом к любым R серверам. Если R+W > n, то, хотя бы один сервер содержит последнюю версию, которая можно определить по максимальному номеру.

Интересной модификацией этого алгоритма является алгоритм "голосование с приведениями". В большинстве приложений операции чтения встречаются намного чаще, чем операции записи, поэтому R обычно делают небольшим, а W - близким к N. При этом выход из порядка нескольких серверов приводит к отсутствию кворума для записи. Голосование с приведениями решает эту проблему путем создания фиктивного серверу без дисков для каждого что отказали или отключенного серверу. Фиктивный сервер не принимает участие в кворуме чтения (прежде всего, у него нет файлов), но он может присоединиться к кворуму записи, причем он просто записывает в никуда переданный ему файл. Запись только тогда успешная, когда хотя бы один сервер действительный.

 

Возможно стоит прочитать: