Сетевая файловая система nfs
На Рис. 9 представлена сетевая модель NFS v2 в соответствии с эталонной моделью OSI. В отличие от большинства сетевых служб TCP/IP система NFS явным образом использует протоколы презентационного и сеансового уровня. Работа NFS опирается на концепцию вызовов удаленных процедур (Remote Procedure Call, RPC). Согласно этой концепции, при доступе к удаленному ресурсу (например, к файлу) программа на локальном компьютере выполняет обычный системный вызов (предположим, вызов функции открытия файла), но на самом деле процедура выполняется удаленно – на сервере ресурсов. При этом пользовательский процесс не в состоянии определить, как выполняется вызов – локально или удаленно. Установив, что процесс обращается к ресурсу на удаленном компьютере, выступающем в качестве сервера, ядро или специальный демон системы упаковывает аргументы процедуры вместе с ее идентификатором в сетевой пакет, открывает сеанс связи с сервером и пересылает ему данный пакет. Сервер распаковывает полученный пакет, определяет запрашиваемую процедуру и аргументы, а затем выполняет процедуру. Далее сервер пересылает клиенту код возврата процедуры, а тот передает его пользовательскому процессу. Таким образом, RPC полностью соответствует сеансовому уровню модели OSI.
Рисунок 9 – Система NFS в соответствии с сетевой моделью OSI
В NFS v2 в качестве транспортного протокола был выбран UDP. Разработчики объясняют это тем, что сеанс RPC длится короткий промежуток времени. Более того, с точки зрения выполнения удаленных процедур каждый пакет RPC является самодостаточным, т. е. каждый пакет несет полную информацию о том, что необходимо выполнить на сервере, или о результатах выполнения процедуры. Сервисы RPC обычно не отслеживают состояние связи (connectionless), т. е. сервер не хранит информацию о том, какие запросы клиента обрабатывались в прошлом: например, с какого места файла клиент считывал данные последний раз. Для сетевой файловой системы это определенное преимущество с точки зрения надежности, так как клиент может продолжать файловые операции сразу же после перезагрузки сервера. Но такая схема чревата возникновением проблем при записи и блокировке файлов, и, чтобы их обойти, разработчики NFS были вынуждены применять разные обходные маневры.
Архитектурные особенности NFS
Файловые системы NFS должны подчиняться двум условиям:
1. С точки зрения клиентских пользовательских программ файловая система NFS располагается как бы на локальном диске. Программы не имеют возможности отличить файлы NFS от обычных файлов.
2. Клиент NFS не в состоянии определить, какая платформа используется в качестве сервера. Это может быть и UNIX, и MVS, и даже Windows NT. Различия в архитектуре серверов сказываются только на уровне конкретных операций, а не в отношении возможностей NFS. Для клиента файловая структура NFS аналогична локальной системе.
Первый уровень прозрачности достигается за счет использования в UNIX виртуальной файловой системы (Virtual File System, VFS). VFS отвечает за взаимодействие не только с NFS, но и с локальными системами наподобие UFS, ext2, VxFS и т. д.
Второй уровень прозрачности обеспечивается благодаря использованию так называемых виртуальных узлов (virtual nodes, vnodes), структуру которых можно соотнести с inodes в файловых системах UNIX.
Операции над файловыми системами NFS являются операциями VFS, тогда как взаимодействие с отдельными файлами и каталогами определяется операциями vnode. Протокол RPC из состава NFS v2 описывает 16 процедур, связанных с операциями не только над файлами и каталогами, но и над их атрибутами. Важно понимать, что вызовы RPC и интерфейс vnode – разные понятия. Интерфейсы vnode определяют сервисы ОС для доступа к файловым системам независимо от того, локальные они или удаленные. RPC же из состава NFS представляет собой специфическую реализацию одного из интерфейсов vnode.
Операции чтения/записи кэшируются на стороне клиента, т. е. клиент кэширует содержимое файлов и каталогов. Обычно размер буфера кэша NFS составляет 8 Кбайт. Если на клиенте запущены демоны biod, то чтение производится с опережением, а запись осуществляется в отложенном режиме. Например, если пользовательский процесс записывает информацию, то данные накапливаются в буфере кэша и лишь затем производится их пересылка, причем обычно в одном пакете RPC. В момент выполнения операции записи ядро сразу же возвращает управление процессу, а функции пересылки запросов RPC передаются biod. Если же демоны biod не запущены и ядро не поддерживает многопоточной обработки RPC, то пересылкой пакетов RPC в однопоточном режиме должно заниматься ядро, а пользовательский процесс переходит в состояние ожидания окончания пересылки. Но и в этом случае кэш NFS по-прежнему используется.
Помимо содержимого файлов и каталогов NFS на стороне клиента производится кэширование атрибутов файлов и каталогов, причем обновление кэша атрибутов осуществляется на периодической основе (обычно раз в несколько секунд). Это связано с тем, что по значению атрибутов можно судить о состоянии файла или каталога. Поясним данный подход на примере. При выполнении пользователем операции чтения из файла содержимое файла помещается в кэш NFS, но одновременно в кэш атрибутов помещаются атрибуты файла (время создания/обновления, размер и т. д.). Если в этот момент другой клиент производит запись в тот же самый файл, то это может привести к рассогласованию содержимого в кэшах разных клиентов. Однако поскольку на первом клиенте кэш атрибутов обновляется каждые несколько секунд, то он в состоянии определить, что атрибуты изменились (в данном случае время обновления файла), поэтому клиент должен провести операцию обновления кэша содержимого файла (данная операция выполняется автоматически).
Для обслуживания запросов клиентов на сервере должны быть запущены демоны nfsd. При этом демоны осуществляют кэширование информации при чтении с дисков сервера. Все демоны обслуживают одну и ту же очередь запросов клиентов, что позволяет оптимально использовать ресурсы процессора.