Network File System (Network File System)

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

NFS абстрагирован от типов файловых систем как сервера, так и клиента. Существует множество реализаций серверов и клиентов NFS для различных операционных систем и аппаратных архитектур. Наиболее зрелая версия NFS — v.4, поддерживающая различные средства аутентификации (в частности, 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, соответственно.

Версии

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

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

NFSv3 вышла в июне 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 выпущена в декабре 2000 года под влиянием AFS и CIFS, в неё включены улучшения производительности и безопасности. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF). NFS версии v4.1 была одобрена IESG в январе 2010 года (новая спецификация объёмом 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

Ссылки

• Network File System Version 4 // IETF
• wiki.linux-nfs.org
• Российская реализация протоколов сетевого доступа к файловым системам NFS версии 2 и NFS версии 3 от компании ООО "Открытые технологии виртуализации"

Стандарты:

• 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