Основные принципы построения

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

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

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

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

Сетевая файловая система в общем случае включает следующие элементы (рис. 3.4):

· локальная файловая система файлового сервера;

· интерфейс локальной файловой системы файлового сервера;

· сервер сетевой файловой системы;

· клиент сетевой файловой системы;

· интерфейс сетевой файловой системы;

· протокол клиент-сервер сетевой файловой системы.

Рис. 3.4. Структура сетевой файловой системы (ФС)

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

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

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

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

Клиент и сервер сетевой файловой системы взаимодействуют друг с другом по сети по определенному протоколу на прикладном уровне модели OSI. В случае совпадения интерфейсов локальной и сетевой файловых систем этот протокол может быть достаточно простым – в его функции будет входить ретрансляция серверу запросов, принятых клиентом от приложений, с которыми тот затем будет обращаться к локальной файловой системе. Одним из механизмов, используемых для этой цели, может быть механизм RPC (вызова удаленных процедур).

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

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

В настоящее время в сетевых файловых службах применяются следующие протоколы клиент-сервер:

· SMB (Server Message Block) – в операционных системах семейства Windows (его последние расширенные версии получили название Common Internet File System, CIFS);

· NCP(NetWare Control Protocol) – основной протокол сетевой операционной системы NetWare компании Novell;

· NFS (Network File System) – популярный протокол в различных вариантах операционных систем семейства UNIX.

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

В некоторых файловых системах (например, NFS или файловых системах семейства ОС Windows) на всех компьютерах сети работает одно и то же базовое программное обеспечение, включающее как клиентскую, так и серверную части, так что любой компьютер, которых захочет предложить услуги файловой службы, может это сделать. Для этого администратору ОС достаточно объявить имена выбранных каталогов разделяемыми, чтобы другие машины могли иметь к ним доступ

В некоторых случаях выпускается так называемая серверная версия операционной системы (например, Windows 2000/2003 Server), которая использует то же программное обеспечение файловой службы, но только позволяющее за счет выделения файловому серверу большего количества ресурсов (в основном оперативной памяти) обслуживать одновременно большее число пользователей, чем версии файлового сервера для клиентских компьютеров.

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

Файловый сервер может быть реализован по одной из двух схем: с запоминанием данных о последовательности файловых операций клиента, т. е. по схеме stateful, и без запоминания таких данных, т. е. по схеме stateless.

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

Серверыstatelessне поддерживают в протоколе обмена с клиентами таких операций, как открытие и закрытие файлов. Они предоставляют клиентам только две команды: читать (read) и писать (write), поэтому для сервера statelessкаждый запрос должен содержать всю информацию о файле.

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

Таким образом, можно сформулировать основные преимущества каждого из подходов.

Серверы stateless:

· отказоустойчивы, так как таблицы открытых файлов хранятся распределено по клиентским машинам;

· не нужно передавать по сети вызовы открытия/закрытия файлов;

· меньше памяти сервера расходуется, так как не хранятся таблицы открытых файлов;

· нет ограничений на число открытых файлов;

· выход из строя клиента не создает проблем для сервера.

Серверы stateful:

· формируются более короткие сообщения при запросах;

· лучше производительность системы;

· возможно опережающее чтение данных из файлов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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