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

Сетевая файловая система (Network File System, NFS) создана в середине 80-х годов компанией Sun Microsystems. Являясь фактическим стандартом для ОС семейства Unix, эта система реализована и для многих других ОС. Так, NFS широко используется в сетях Microsoft и Novell, а также в таких решениях компании IBM, как AS400 и OS/390. NFS, пожалуй, самая распространенная платформенно-независимая сетевая файловая система. Принципы ее организации на сегодня стандартизованы сообществом Интернета, последняя версия NFS v.4 описывается спецификацией RFC 3530 (http://www.ietf.org/rfc/ rfc3530. txt), выпущенной в апреле 2003 года.

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

Рис. 11.8. Многоуровневая структура сетевой файловой системы NFS

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

На следующем уровне модели OSI располагаются средства XDR (external Data Representation — внешнее представление данных). Поскольку одной из целей разработчиков NFS была поддержка неоднородных систем с клиентами и серверами, работающими под управлением различных ОС на различных аппаратных платформах, имеющих разный порядок представления байтов в машинном слове, разное представление чисел с плавающей точкой и др., в реализациях NFS на основе механизма RPC по умолчанию поддерживаются средства для унифицированного представления аргументов удаленных процедур.

Далее для передачи сообщений используются транспортные средства стека TCP/IP.

В файловой системе NFS можно определить два типа процедур:

• процедуры монтирования удаленной файловой системы;

• процедуры доступа к удаленным файлам.

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

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

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

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

В NFS принята схема stateless, то есть серверы при работе с файлами не хранят данные об открытых клиентами файлах. Поэтому в NFS поддерживается большая часть системных вызовов Unix, за исключением open и close. Для обеспечения устойчивости клиентов к отказам серверов системные вызовы open и close исключены. Вместо операции открытия удаленного файла клиент посылает серверу сообщение, содержащее имя файла, с запросом отыскать его (lookup) и вернуть дескриптор файла. В отличие от вызова open вызов lookup не копирует никакой информации во внутренние системные таблицы. Вызов read содержит дескриптор того файла, который нужно считать, смещение в уже читаемом файле и количество считываемых байтов. Подчеркнем, что в схеме stateless каждый вызов является самодостаточным. Он несет всю необходимую информацию для выполнения заданной операции, никак не зависит от предыдущих операций и никак не влияет на последующие.

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

К недостаткам NFS относится сложность блокировки файлов. Во многих ОС файл может быть открыт и заблокирован так, чтобы другие процессы не имели к нему доступа. Когда файл закрывается, блокировка снимается. В stateless-системах, подобных NFS, блокирование не может быть связано с открытием файла, так как сервер не знает, какой файл открыт. Для выполнения блокировки в сетевой файловой системе NFS используются специальные, формально не связанные с NFS средства управления блокированием — менеджер блокировок сети (Network Lock Manager, NLM) и монитор состояния сети (Network Status Manager, NSM), который ведет статистику блокировок. Последнее необходимо для того, чтобы при отказе NFS можно было автоматически восстановить бло­кировки.

Для повышения производительности в NFS используется кэширование на стороне как сервера, так и клиента, причем в последнем случае кэширование выполняется не только в оперативной памяти, но и на локальном диске.

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

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

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

Кэширование дублированных запросов направлено не столько на повыше­ние производительности, сколько на повышение устойчивости и корректности работы NFS. Если при выполнении запроса возникает задержка, клиент может повторить свой запрос, причем не один раз. Это является штатной ситуацией для NFS, где сервер функционирует по схеме stateless и повтор запроса клиентом является частью восстановительной процедуры. Однако клиент не может знать точно, выполнен ли его предыдущий, запрос, и может послать избыточ­ный запрос. Для одних операций, таких как запись данных на сервер, такая избыточность не несет никакой опасности — сервер просто повторяет чтение бло­ка. Повторение же других операций, таких, например, как «удалить каталог», может привести к серьезной ошибке. Для избежания этого NFS-сервер поддерживает кэширование дублированных запросов, и все повторные запросы, поступившие в течение короткого периода, игнорируются.

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

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

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

Сервер выдает разрешение клиенту на выполнение тех или иных действий в виде числового кода magic cookie. Это число служит своего рода паролем, который клиент должен включать в каждый RPC-запрос в качестве доказательства своих полномочий. Кроме того, RPC-запрос содержит идентификаторы пользователя uid, от имени которого выступает приложение, и список идентификато­ров групп gid, в которые входит данный пользователь. Заметим, что админист­ратор сервера задает права доступа к разделяемым файловым ресурсам на основе идентификаторов uid и gid клиентов. А это значит, что имеется потенци­альная возможность коллизии. Обязанностью администратора является обес­печение согласованной идентификации пользователей на сервере и клиенте. В большой сети эта задача становится нетривиальной, поэтому для этих целей используется сетевая информационная служба NIS (Network Information Sys­tem), представляющая собой достаточно простой вариант сетевой справочной службы. Функциями NIS является централизованное хранение и обработка системных файлов.

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