Network File System

NFS (Network File System) — протокол сетевого доступа к файловым системам, первоначально разработан Sun Microsystems в 1984 году. За основу взят протокол вызова удалённых процедур (ONC RPC, англ. Open Network Computing Remote Procedure Call^[1]). Позволяет монтировать (подключать) удалённые файловые системы через сеть.

NFS абстрагирован от типов файловых систем как сервера, так и клиента. Существует множество реализаций серверов и клиентов NFS для различных операционных систем и аппаратных архитектур. Наиболее зрелая версия NFS — v.4^[2], поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списки контроля доступа (как POSIX, так и Windows-типов).

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

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

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

Цели разработки

Изначальными требованиями при разработке NFS были:

• потенциальная поддержка различных операционных систем (не только UNIX), чтобы серверы и клиенты NFS возможно было бы реализовать в разных операционных системах;
• протокол не должен зависеть от каких-либо определённых аппаратных средств;
• должны быть реализованы простые механизмы восстановления в случае отказов сервера или клиента;
• приложения должны иметь прозрачный доступ к удаленным файлам без использования специальных путевых имён или библиотек и без перекомпиляции;
• для UNIX-клиентов должна поддерживаться семантика UNIX;
• производительность NFS должна быть сравнима с производительностью локальных дисков;
• реализация не должна быть зависимой от транспортных средств.

Компоненты NFS

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

Протокол NFS определяет набор запросов (операций), которые могут быть направлены клиентом к серверу, а также набор аргументов и возвращаемые значения для каждого из этих запросов. Версия 1 этого протокола существовала только в недрах Sun Microsystems и никогда не была выпущена. Все реализации NFS (в том числе NFSv3) поддерживают версию 2 NFS (NFSv2), которая впервые была выпущена в 1985 году в SunOS 2.0. Версия 3 протокола была опубликована в 1993 году и реализована некоторыми фирмами-поставщиками.

Протокол удаленного вызова процедур (RPC) определяет формат всех взаимодействий между клиентом и сервером. Каждый запрос NFS посылается как пакет RPC.

Внешнее представление данных (XDR — External Data Representation) обеспечивает машинно-независимый метод кодирования данных для пересылки через сеть. Все запросы RPC используют кодирование XDR для передачи данных. XDR и RPC используются для реализации многих других сервисов, помимо 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, соответственно.

Версии

Первая версия^[3] применялась только для внутреннего использования в Sun в экспериментальных целях.

Версия 2^[3](NFSv2) выпущена в марте 1989 года, первоначально полностью работала по протоколу UDP. Разработчики решили не хранить данных о внутреннем состоянии внутри протокола, как пример, блокировка, реализованная вне базового протокола. Люди, вовлечённые в создание NFS версии 2 — Расти Сэндберг (Rusty Sandberg,) Боб Лайон (Bob Lyon), Билл Джой и Стив Клейман (Steve Kleiman).

NFSv3^[4] вышла в июне 1995 года, в ней добавлена поддержка дескрипторов файлов переменного размера до 64 байт (в версии 2 — массив фиксированного размера 32 байта), снято ограничение на 8192 байта в RPC-вызовах чтения и записи (тем самым, размер передаваемого блока в вызовах ограничен только пределом для UDP-датаграммы — 65535 байт), реализована поддержка файлов больших размеров, поддержаны асинхронные вызовы операций записи, к процедурам READ и WRITE добавлены вызовы ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в каталоге вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1-информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение).

На момент введения версии 3 отмечен рост популярности в среде разработчиков протокола TCP. Некоторые независимые разработчики самостоятельно добавили поддержку протокола TCP для NFS версии 2 в качестве транспортного, Sun Microsystems добавили поддержку TCP в NFS в одном из дополнений к версии 3. С поддержкой TCP появилась возможность использования NFS в глобальных сетях.

NFSv4^[2] выпущена в декабре 2000 года под влиянием AFS и CIFS, в неё включены улучшения производительности и безопасности. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF). NFS версии v4.1 была одобрена IESG в январе 2010 года^[5] (новая спецификация объёмом 612 страниц стала известна как самый длинный документ, одобренный IETF). Важным нововведением версии 4.1 является спецификация pNFS — Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые облачные хранилища и информационные системы.

NFS версии 4.2 RFC 7862 была опубликована в ноябре 2016 и включает новые особенности: клонирование и копирование на стороне сервера, рекомендации по вводу-выводу приложения, разреженные файлы, резервирование места, блок данных приложения (ADB), помеченный NFS с атрибутом sec_label, который адаптируется к любой системе безопасности MAC и две новые операции для pNFS (LAYOUTERROR и LAYOUTSTATS).

Другие модули

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

Менеджер блокировок сети (NLM — Network Lock Manager) и монитор состояния сети (NSM — Network Status Monitor) вместе обеспечивают средства для блокировки файлов в сети. Эти средства, хотя формально не связаны с NFS, можно найти в большинстве реализаций NFS. Они обеспечивают сервисы, невозможные в базовом протоколе. NLM и NSM реализуют функционирование сервера с помощью демонов lockd и statd, соответственно.

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

Платформы

Хотя NFS чаще всего используют в Unix-подобных системах, данный протокол можно также использовать и в других операционных системах, таких, как Mac OS Classic, OpenVMS, Microsoft Windows, Novell NetWare, и IBM i.

Типичные настройки NFS-клиента и NFS-сервера

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

Альтернативы NFS

В число альтернативных протоколов удаленного доступа к файлам входят протокол SMB (Server Message Block, также известный как Samba и CIFS), Apple Filing Protocol (AFP), NetWare Core Protocol (NCP). Под операционной системой Microsoft Windows SMB и NetWare Core Protocol (NCP) используется чаще, чем NFS. В системах Macintosh AFP встречается чаще, чем NFS.

См. также

• Network Information Service
• Samba
• Server Message Block
• SSHFS