NFS

NFS - протокол сетевого доступа к файловым системам, основанный на протоколе вызова удаленных процедур (ONC RPC, Open Network Computing Remote Procedure Call, RFC 1057, RFC 1831). Первоначально разрабатывался компанией Sun Microsystems, и увидел свет в 1984 году. С помощью данного протокола можно подключать удаленные файловые системы посредством сети. Протокол описан в RFC 1094, RFC 1813, RFC 3530 и RFC 5661.

Главным преимуществом NFS является то, что этот протокол абстрагирован от типов файловых систем, причем, как серверных, так и клиентских. В настоящее время существует множество реализаций NFS-серверов и клиентов, предназначенных для различных операционных систем. Сегодня особой популярностью на рынке пользуется версия NFS v.4 (RFC 3010,RFC 3530), которая имеет поддержку различных средств аутентификации. В частности, эта одна их самых зрелых версий протокола поддерживает Kerberos и LIPKEY (с применением протокола RPCSEC GSS), а также списки контроля доступа (POSIX, и Windows-типы).

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

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

Что касается последней версии протокола NFS - v4.1. - то в ней главным нововведением стала спецификация pNFS, которая нацелена на осуществление распараллеленной реализации общего доступа к файлам. Она увеличивает скорость передачи данных пропорционально размерам параллелизма самой системы.

Цели NFS

Первоначально, при создании NFS, разработчики вкладывали в него следующие цели:

  • Избавление NFS от ограничений в операционной системе UNIX. Сервер и клиент NFS должен быть реализован любой операционной системой;
  • NFS не должен быть зависим от каких-либо аппаратных средств;
  • Необходимость реализации простых механизмов восстановления при отказе сервера или клиента;
  • Необходимость обеспечения приложениям прозрачного доступа к удаленным файлам, без применения специальных путевых имен/библиотек;
  • UNIX-семантика для UNIX-клиентов;
  • Производительность NFS-протокола должна быть сопоставима с производительностью локальных дисков;
  • Отсутствие зависимости реализации от транспортных средств.

Компоненты NFS

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

  • Набор запросов и операций, направленных клиентом к серверу, опеределяется протоколом NFS. Также в этот набор входят и аргументы со значениями - для каждого из запросов. Версия 1 протокола NFS существовала лишь внутри компании-разработчика, и никогда не была обнародована. Все реализации NFS имеют поддержку Версии 2, она была впервые представлена в 1985 году, в рамках SunOS 2.0. Третья версия протокола вышла в 1993 году.
  • Протокол удаленного вызова процедур (RPC). Определяет формат взаимодействий клиент-сервер. Каждый запрос протокола NFS выглядит как пакет RPC.
  • Внешнее представление данных (XDR — External Data Representation). Обеспечивает машинно-независимый метод копирования. Предназначается для пересылки данных посредством сети. Все запросы RPC используют кодирование XDR. Так передаются данные. Кроме того, XDR и PRC применяются также и для реализации других серверов, не только NFS.
  • Программный код NFS-сервера осуществляет обработку клиентских запросов, и отвечает за доступ к экспортируемым файловым системам.
  • Программный код NFS-клиента реализует обращения клиентской системы к удаленным файлам посредством отправки серверу одного или нескольких RPC-запросов.
  • Протокол монтирования. Определяет семантику монтирования/размонтирования файловых систем NFS. В NFS применяется несколько фоновых процесс-демонов. Набор демонов NFSD ожидает на сервере запросы клиентов NFS и посылает ответы на них.
  • Демон Mountd занимается обработкой запросов монтирования. Набор демонов biod у клиента занимается обработкой асинхронного ввода/вывода блоков файлов NFS. 
  • Менеджер сетевых блокировок (NLM — Network Lock Manager) и монитор сетевого состояния (NSM — Network Status Monitor) совместно обеспечивают средства для разблокировки сетевых файлов. И несмотря на то, что эти средства формально никак не связаны с NFS, их можно найти в большинстве реализаций NFS. Благодаря им в базовом протоколе появляются непредусмотренные протоколом сервисы. NLM и NSM обеспечивают функционирование сервера благодаря использованию демонов lockd и statd, соответственно.

Версии

Версия 1

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

Версия 2

Данная версия протокола NFS (RFC 1094) была выпущена в марте 1989 года. Изначально она работала по протоколу UDP. Однако позже разработчиками было принято решение не хранить данные о внутреннем состоянии протокола, и данная версия получила логическое продолжение. Над Версией 2 NFS работали Расти Сендберг (Rusty Sandberg,) Боб Лайон (Bob Lyon), Билл Джой (Bill Joy) и Стив Клейман (Steve Kleiman).

Версия 3

Версия 3 имеет описатели файлов в виде массива переменного размера, размером 64 байта, тогда как в Версии 2 это массив фиксированного размера в 32 бита. 4-битный счетчик определяет массив переменной длины в XDR, что уменьшает размер описателя файла в реализациях типа UNIX, где необходимо всего 12 байт. С другой стороны, такая система позволяет реализациям, отличным от UNIX, осуществлять обмен дополнительной информацией. В Версии 3 отсутствует ограничение на процедуры чтения или записи RPC, в Версии 2 это ограничение есть, оно составляет 8192 байта. Версия 3 ограничена только размером IP датаграммы (65535 байт), благодаря использованию UDP. Такое устройство позволяет системе применять большие пакеты при чтении и записи в быстрых сетях. Кроме того, размер файлов и начальное смещение в байтах для процедур чтения и записи стали использовать 64-битную адресацию взамен 32-битной. Это позволяет осуществлять работу с большими файлами. При каждом вызове, потенциально влияющем на атрибуты, атрибуты файла возвращаются, что сопутствует уменьшению количества вызовов GETATTR, запрашиваемых клиентом. В Версии 3 записи могут иметь асинхронный вид. В Версии 2 они обязательно должны быть синхронными, что улучшает производительность при записи.

В Версии 3 была удалена процедура STATFS, и добавлены семь других процедур:

  • ACCESS (проверка прав доступа к файлу);
  • MKNOD (создание специального файла Unix);
  • READDIRPLUS (возвращение имени файлов в директории вместе с их атрибутами);
  • FSINFO (возвращение статистической информации о файловой системе);
  • FSSTAT (возвращение динамической информации о файловой системе);
  • PATHCONF (возвращение POSIX.1 информацию о файле);
  • COMMIT (передача ранее сделанных асинхронных записей на постоянное хранение).

К моменту запуска Версии 3, применение TCP транспортного протокола среди разработчиков начало расти. И несмотря на то, что некоторые разработчики уже добавили поддержку протокола TCP в Версию 2, специалисты Sun Microsystems официально внедрили транспортный протокол TCP в NFS в рамках его третьей версии. Так, внедрение TCP сделало NFS более функциональным в глобальной сети.

Версия 4

Версия 4 протокола NFS, выпущенная в декабре 2000 года (RFC 3010), была пересмотрена в апреле 2003-го (RFC 3530). Этому обновлению поспособствовало влияние AFS и CIFS, что повлекло за собой улучшение производительности и высокую безопасность. Так, NFS стал полноценным протоколом. Версия 4 стала первой версией, которая была разработана совместно с Internet Engineering Task Force (IETF), которой компания Sun Microsystems и передала развитие протокола.

Версия 4.1 была подтверждена IESG в январе 2010 года. Она получила код RFC 5661. Версия 4.1 имело важное нововведение: спецификацию pNFS (Parallel NFS), которая обеспечивала механизм параллельного доступа NFS-клиента к данным распределенных NFS-серверов. Присутствие данного механизма в стандарте помогло сетевой файловой системе организовать распределенные облачные хранилища.

Прочие модули

WebNFS - расширение для NFS версий 2 и 3. Оно позволяет производить легкую интеграцию в веб-браузеры, что позволяет пользователю работать через брендмауэр. С NFS начали ассоциироваться и различные другие протоколы. Например, менеджер сетевых блокировок (NLM — Network Lock Manager) и монитор сетевого состояния (NSM — Network Status Monitor), которые и обеспечивают совместными усилиями средства для блокировки сетевых файлов. Эти средства находятся в большинстве реализаций NFS, как и говорилось выше.

Протокол удаленной информации о квотах (RQUOTAD) позволяет пользователям NFS просматривать дисковую квоту на удаленном сервере.

Платформы

NFS используется зачастую в UNIX-системах, или подобных, но он также доступен и для других операционных систем: Mac OS Classic, OpenVMS, Microsoft Windows, Novell NetWare, и IBM AS/400. NFS имеет также альтернативные протоколы доступа к файлам: Server Message Block (SMB или CIFS) протокол, Apple Filing Protocol (AFP), NetWare Core Protocol (NCP).

В операционной системе Microsoft Windows протокол SMB и NetWare Core Protocol (NCP) применяются гораздо чаще, нежели NFS. Что касается систем Macintosh, то там чаще NFS встречается протокол AFP.

Стандартные настройки NFS-клиента и NFS-сервера

  • Клиенту не важно, к чему именно он получает доступ: к локальному файлу или к NFS-файлу. Это определяет ядро в момент открытого файла.
  • RPC-запросы отправляются NFS-серверу NFS-клиентом посредством модуля TCP/IP. Обычно применяется UDP, но может использоваться и TCP, особенно в более новых реализациях.
  • Запросы от клиента получаются в виде UDP-датаграмм NFS-сервером. Принимает порт 2049. И хотя NFS работает с преобразованием портов, что дает возможность серверу применять динамически назначаемые порты, UDP-порт 2049 четко закреплен за NFS, в большинстве случаев.
  • При получении запроса от клиента NFS-сервером, доступ к файлу передается локальной подпрограмме, обеспечивающей доступ к локальному диску на сервере.
  • Серверу необходимо время для обработки клиентских запросов. Некоторое время может потребоваться даже для доступа к локальной файловой системе. На протяжение этого времени сервер не будет блокировать запросы от других клиентов. Большинство NFS-серверов в таких случаях запускаются некоторое количество раз, таким образом, внутри ядра имеется несколько NFS-серверов. Методы решения в большей степени зависят от операционной системы. Например, в UNIX-серверах, в большинстве своем, не имеется несколько NFS-серверов. Вместо такого метода, просто запускается несколько процессов, осуществляющих один системный вызов, они остаются внутри ядра в качестве процесса (обычно зовутся nfsd).
  • NFS-клиенту требуется время для обработки запроса со стороны пользовательского процесса. После этого возникает отклик. Чтобы процессы на клиентском хосте могли в любой момент воспользоваться NFS, имеется несколько NFS-клиентов, которые запускаются внутри ядра. Тут также, реализация во многом зависит от самой операционной системы. Например, в UNIX-системах, как правило, применяется техника, напоминающая NFS-сервер (пользовательский процесс осуществляет системный вызов и остается внутри ядра в качестве процесса).
  • С большей частью Unix хостов может работать как NFS-клиент и NFS-сервер (или и то, и другое одновременно). Большая часть ПК-реализаций привязаны только к реализации NFS-клиента. А большинство IBM-реализаций осуществляет исключительно функции NFS-серверов.

Стандарты

  • RFC 1094 NFS: Network File System Protocol Specification] (March 1989)
  • RFC 1813 NFS Version 3 Protocol Specification] (June 1995)
  • RFC 2224 NFS URL Scheme
  • RFC 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols
  • RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5
  • RFC 2624 NFS Version 4 Design Considerations
  • RFC 3010 NFS version 4 Protocol
  • RFC 3530 Network File System (NFS) version 4 Protocol
  • RFC 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol
#