11.3.2. Файловая система nfs

Самым известным примером реализации распределенных файловых систем является Network File System (NFS). Сегодня NFS является стандартной файловой системой большинства UNIX-совместимых ОС.

Принцип действия NFS

Файловая система NFS объединяет отдельные каталоги файловых систем отдаленных компьютеров в единственное дерево каталогов локального компьютера. Такое объединение является прозрачным для пользователей — с их точки зрения окончательное дерево каталогов не отличается от локальной файловой системы UNIX.

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

1. Для того, чтобы NFS-клиент мог получить доступ к каталогу локальной файловой системы NFS-сервера, этот каталог нужно экспортировать. Для этого необходимо прибавить соответствующий путь в список экспорта, который хранят на сервере, обычно в специальном файле /etc/exports. Этот список считывает ядро ОС во время загрузки системы.

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

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

NFS использует протокол монтирования и протокол NFS. Как базовые компоненты оба протокола используют отдаленные вызовы процедур в соответствии с интерфейсом Sun RPC.

Протокол монтирования

Протокол монтирования используют для задания исходного логического соединения между сервером и клиентом во время операции монтирования. Рассмотрим шаги этого протокола.

1. Клиент выполняет RPC-запрос MNT для вызова процедуры монтирования. Параметром этой процедуры на сервер передают путь к отдаленному каталогу.

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

Есть два подхода к монтированию отдаленных файловых систем.

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

Второй (более распространенный) -является автоматическое монтирование (automount), когда фактическое монтирование каталога выполняют после первого обращения к нему.

Протокол NFS

Этот протокол определяет набор RPC-запросов, которые реализуют операции с отдаленными файлами и каталогами

Поиск файла в каталоге — LOOKUP, чтение набора элементов каталога — READDIR, создание и исключение файлов и каталогов - CREATE, REMOVE, MKDIR, RMDIR, чтение и записывание файлов - READ и WRITE, работа с атрибутами файлов - GETATTR, SETATTR).

Среди этих NFS-запросов, однако, нет аналогов системных вызовов ореп() и close(). Это отображает фундаментальное свойство NFS-серверов — они не хранят состояния между обращениями клиентов. Такой подход используют из-за опасности потери состояния в случае выхода сервера из строя (в этом случае последующее использование открытых файлов станет невозможным).

То, что NFS-протокол не хранит состояния, определяет две важны характеристики запросов, которые входят у него.

1. NFS-запросы являются независимыми. Всю информацию, необходимую для выполнения такого запроса, нужно передавать в него как параметры. Например, запрос WRITE должен принимать как параметры уникальный идентификатор файла и сдвиг внутри файла.

2. Большинство NFS-запросов должны быть идемпотентными. Это значит, что NFS-клиент может отослать серверу один и тот же запрос несколько раз, при этом общий результат их выполнения должен остаться тем самым. Например, чтение дискового блока из файла (запрос READ) является идемпотентным: в результате выполнения операции возвращаются те же данные независимо от того, сколько раз она была повторена.

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

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

Если сервер выйдет из строя, клиент будет повторять запросы в цикле и продолжать работу не сможет. Способ завершения цикла задают во время монтирования каталога. В случае жесткого монтирования (hard mount) цикл будет длиться бесконечно (он может быть прерван только после возобновления работы сервера), в случае мягкого монтирования (soft mount) цикл перерывают по окончании некоторое время (обычно нескольких минут), а клиенту возвращают ошибку. За умалчиванием используют жесткое монтирование.

Кэширование в NFS

Проблемы, которые возникают во время реализации кэширования в NFS, приведены ниже.

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

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

Второй проблемой является обеспечение когерентности кэша клиентов. Опишем базовый способ решения этой проблемы в NFS.

Если клиент изменяет файл, данные хранят на сервере. При этом другие клиенты продолжают использовать старую версию со своих кэшей до исчерпания некоторого часового промежутка (длина которого может быть изменена администратором сервера; обычно она составляет от 3 до 30 сек). После этого проверяют, не изменился ли файл на сервере, и, если изменился, клиент получает новую копию и хранит ее в локальном кэше. Как следствие во время работы из NFS обычной является ситуация, когда файлы, созданные одним клиентом, остаются невидимыми для всех других на протяжении достаточно длительного времени.

Файловые блокировки в NFS

Организация файловых блокировок на уровне NFS-протокола невозможна, поскольку для этого нужно сохранение информации на сервере. Современные версии NFS реализуют поддержку блокировок с помощью отдельного протокола NLM (Network Lock Manager). Когда NFS-клиент внедряет или снимает файловую блокировку, будет згенеровано RPC-вызов в соответствии с этим протоколом.

Протокол NLM поддерживает сохранение состояния. В связи с этим его использование осложняет обработку сбоев клиента и сервера.

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

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

Безопасность данных в NFS

Управление доступом в NFS основывается на уровнях аутентификации Sun RPC.

Исходная модель управления доступом не является безопасной, поскольку она использует уровень аутентификации AUTH_UNIX. Каждый NFS-запрос сопровождают uid и набор gid, которые сравнивают с атрибутами безопасности необходимого файла. В случае совпадения идентификаторов и наличия соответствующих прав считают, что доступ к файлу разрешен.

Некоторые современные реализации NFS дают возможность использовать аутентификацию уровня AUTH_DES, такую технологию называют Secure NFS.