3.2.2. Кэширование файлов

В системах, состоящих из клиентов и серверов, возможны два различных подхода к месту для хранения кэшируемых файлов и их частей:

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

• Кэширование на стороне клиента, которое реализуется как с использованием диска клиента (если имеется), так и его оперативной памяти, разгружает сервер и уменьшает нагрузку на сеть.

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

• алгоритм сквозной записи, когда новое значение записывается в кэш и одновременно посылается на сервер для обновления главной копии при каждой модификации кэшируемого элемента (стиль UNIX);

• алгоритм периодической (примерно раз в 30 с) проверки кэша и изменения главной копии;

• запись изменений в главную копию только при закрытии файла.

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

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

• инициирование проверки клиентом – перед каждым доступом к файлу, периодические или при открытии файла;

• инициирование проверки сервером – более эффективен, но сервер обязательно должен быть типа stateful (чтобы хранить информацию о состоянии клиентов) и делает сервер не стандартным, так как он становится не чисто пассивным элементом в модели «клиент-сервер».

3.2.3. Репликация файлов

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

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

Достоинства репликации:

• увеличение надежности хранения данных за счет наличия независимых копий каждого файла на разных файловых серверах;

• распределение нагрузки между несколькими серверами – клиенты могут обращаться к данным реплицированного файла на ближайший файловый сервер.

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

Файловая система обеспечивает достоверность данных реплики и защиту ее данных.

Прозрачность репликации зависит от двух факторов: используемой схемы именования реплик и степени вовлеченности пользователя в управление репликацией.

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

В частности, файлу присваивается имя, не содержащее старшей части, соответствующей имени компьютера. В справочной службе этому имени соответствует несколько идентификаторов, указывающих на серверы, хранящие реплики файла. Например, для файла st/file могут соответствовать следующие три полные сетевые адреса: \\server1\st\file; \\server2\st\file; \\server3\st\file.

Управление репликацией. Существует два режима управления репликацией: явный и неявный.

При явной репликации пользователю (программисту) предоставляется возможность управления процессом репликации. При этом не исключается автоматический режим поддержания согласованности реплик, которые создал и разместил на серверах пользователь.

При неявной репликации выбор количества и места размещения реплик производится в автоматическом режиме. Без участия пользователя. Приложение не должно указывать место размещения файла при запросе на его создание – это делает сама файловая система.

Существует несколько способов обеспечения согласованности реплик.

• Чтение любой реплики – запись во все (стиль UNIX). Недостаток – не все серверы в момент записи обновления могут быть доступны.

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

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

• Кворум. В сети существует n реплик, изменения файла записываются в w реплик, а при чтении файла клиент обязательно производит обращение к r репликам. Так как выполняется правило w + r > n, то среди просматриваемых реплик обязательно будет реплика с последней модификацией. Например, при n = 8 и w = 4, необходимо обратиться не менее чем к r = 5 репликам, чтобы наверняка попасть хотя бы на одну последнюю версию файла.