Nfs протокол что. Сетевая файловая служба. Установка Server For NFS с помощью PowerShell

#image.jpgНеплохого времени, читатели и гости моего блога. Очень большой перерыв меж постами был, но я снова в бою). В сегодняшней статье рассмотрю работу протокола NFS , а так же настройку сервера NFS и клиента NFS на Linux .

Введение в NFS

NFS (Network File System - сетевая файловая система) по моему мнению - идеальное решение в локальной сети, где нужен быстрый (более быстрый по сравнению с SAMBA и менее ресурсоемкий по сравнению с удаленными файловыми системами с шифрованием - sshfs, SFTP, etc...) обмен данными и во главе угла не стоит безопасность передаваемой инфы. Протокол NFS позволяет монтировать удалённые файловые системы через сеть в локальное дерево каталогов, как если бы это была примонтирована дисковая файловая система.

Тем локальные приложения могут работать с удаленной файловой системой, как с локальной. Но нужно быть осторожным (!) с настройкой NFS , ибо при определенной конфигурации можно подвесить операционную систему клиента в ожидании бесконечного ввода/вывода.

Протокол NFS основан на работе протокола RPC , который пока не поддается моему пониманию)) поэтому материал в статье будет малость расплывчат... Прежде, чем Вы сможете использовать NFS, будь это сервер или клиент, Вы должны удостовериться, что Ваше ядро имеет поддержку файловой системы NFS. Проверить поддерживает ли ядро файловую систему NFS можно, просмотрев наличие соответствующих строк в файле /proc/filesystems:

ARCHIV ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd

Если обозначенных строк в файле /proc/filesystems не окажется, то необходимо установить описанные ниже пакеты. Это скорее всего дозволит установить зависимые модули ядра для поддержки подходящих файловых систем.

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

История Network File System

Протокол NFS разработан компанией Sun Microsystems и имеет в своей истории Четыре версии. NFSv1 была разработана в Одна тыща девятьсот восемьдесят девять и являлась экспериментальной, работала на протоколе UDP. Версия Один описана в RFC 1094.

NFSv2 была выпущена в том же Одна тыща девятьсот восемьдесят девять г., описывалась тем же RFC1094 и так же базировалась на протоколе UDP, при всем этом позволяла читать наименее 2Гб из файла. NFSv3 доработана в Одна тыща девятьсот девяносто 5 г. и описана в RFC 1813.

Основными нововведениями третьей версии стало поддержка файлов большого размера, добавлена поддержка протокола TCP и TCP-пакетов большущего размера, что существенно ускорило работоспосбоность технологии. NFSv4 доработана в Две тыщи г. и описана в RFC 3010, в Две тыщи три г. пересмотрена и описана в RFC 3530.

4-ая версия включила в себя улучшение производительности, поддержку различных средств аутентификации (а конкретно, Kerberos и LIPKEY с внедрением протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов). NFS версии v4.1 была одобрена IESG в Две тыщи 10 г., и получила номер RFC 5661.

Принципным нововведением версии 4.1, является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в образце сетевой файловой системы поможет строить распределённые «облачные» («cloud») хранилища и информационные системы.

NFS сервер

Так как у нас NFS - это сетевая файловая система, то необходимо настроить сеть в Linux. (Так же можно почитать статью главные понятия сетей). Далее необходимо установить соответствующий пакет. В Debian это пакет nfs-kernel-server и nfs-common, в RedHat это пакет nfs-utils.

А так же, необходимо разрешить запуск беса на подходящих уровнях выполнения (команда в RedHat - /sbin/chkconfig nfs on, в Debian - /usr/sbin/update-rc.d nfs-kernel-server defaults).

Установленные пакеты в Debian запускается в следующем порядке:

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx Один root root 20 Окт Восемнадцать 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx Один root root 20 семь Окт 20 два 01:23 S16nfs-kernel-server -> ../init.d/nfs-kernel-server

Другими словами, сначала запускается nfs-common , позже сам сервер nfs-kernel-server .

В RedHat ситуация схожая, за тем только исключением, что 1-ый скрипт называется nfslock , а сервер называется просто nfs . Про nfs-common нам сайт debian дословно говорит следующее: общие файлы для клиента и сервера NFS, этот пакет нужно устанавливать на машину, которая будет работать в качестве клиента или сервера NFS.

В пакет включены программы: lockd, statd, showmount, nfsstat, gssd и idmapd. Просмотрев содержимое скрипта запуска /etc/init.d/nfs-common можно отследить следующую последовательность работы: скрипт проверяет наличие исполняемого бинарного файла /sbin/rpc.statd, проверяет наличие в файлах /etc/default/nfs-common, /etc/fstab и /etc/exports черт, требующих запуск бесов idmapd и gssd , запускает демона /sbin/rpc.statd , далее перед запуском /usr/sbin/rpc.idmapd и /usr/sbin/rpc.gssd проверяет наличие этих исполняемых бинарных файлов, далее для беса /usr/sbin/rpc.idmapd проверяет наличие модулей ядра sunrpc, nfs и nfsd, а так же поддержку файловой системы rpc_pipefs в ядре (другими словами наличие ее в файле /proc/filesystems), если все удачно, то запускает /usr/sbin/rpc.idmapd . Дополнительно, для беса /usr/sbin/rpc.gssd проверяет модуль ядра rpcsec_gss_krb5 и запускает бес.

Если просмотреть содержимое скрипта запуска NFS-сервера на Debian (/etc/init.d/nfs-kernel-server), то можно проследить следующую последовательность: при старте, скрипт проверяет существование файла /etc/exports, наличие модуля ядра nfsd, наличие поддержки файловой системы NFS в ядре Linux (другими словами в файле /proc/filesystems), если все на месте, то запускается бес /usr/sbin/rpc.nfsd , далее проверяет задан ли параметр NEED_SVCGSSD (задается в файле опций сервера /etc/default/nfs-kernel-server) и, если задан - запускает беса /usr/sbin/rpc.svcgssd , последним запускает беса /usr/sbin/rpc.mountd . Из данного скрипта видно, что работа сервера NFS состоит из бесов rpc.nfsd, rpc.mountd и если употребляется Kerberos-аутентификация, то и бес rcp.svcgssd. В краснойшляпе еще запускается бес rpc.rquotad и nfslogd (В Debian я почему-то не нашел инфы об этом демоне и о причинах его отсутствия, видимо удален...).

Из этого становиться понятно, что сервер Network File System состоит из следующих процессов (читай - бесов) , расположенных в каталогах /sbin и /usr/sbin:

• rpc.statd - Бес наблюдения за сетевым состоянием (он же Network Status Monitor, он же NSM). Он позволяет корректно отменять блокировку после сбоя/перезагрузки. Для уведомления о нарушении употребляет программу /usr/sbin/sm-notify. Бес statd работает как на серверах, так и на клиентах. Ранее данный сервер был нужен для работы rpc.lockd, но за блокировки сейчас отвечает ядро (прим: если я не ошибаюсь #image.jpg). (RPC программа 100 тыщ 20 один и 100 тыщ 20 четыре - в новых версиях)
• rpc.lockd - Бес блокировки lockd (он же NFS lock manager (NLM)) обрабатывает запросы на блокировку файлов. Бес блокировки работает как на серверах, так и на клиентах. Клиенты запрашивают блокировку файлов, а серверы ее разрешают. (устарел и в новых дистрибутивах не употребляется как бес. Его функции в современных дистрибутивах (с ядром старше 2.2.18) выполняются ядром, точнее модулем ядра (lockd).) (RPC программа 100024)
• rpc.nfsd - Основной бес сервера NFS - nfsd (в новых версиях временами называется nfsd4 ). Этот бес обслуживает запросы клиентов NFS. Параметр RPCNFSDCOUNT в файле /etc/default/nfs-kernel-server в Debian и NFSDCOUNT в файле /etc/sysconfig/nfs в RedHat определяет число запускаемых бесов (по-умолчанию - 8).(RPC программа 100003)
• rpc.mountd - Бес монтирования NFS mountd обрабатывает запросы клиентов на монтирование каталогов. Бес mountd работает на серверах NFS. (RPC программа 100005)
• rpc.idmapd - Бес idmapd для NFSv4 на сервере преобразует локальные uid/gid юзеров в формат вида имя@домен, а сервис на клиенте преобразует имена юзеров/групп вида имя@домен в локальные идентификаторы пользователя и группы (согласно конфигурационному файлу /etc/idmapd.conf, подробней в man idmapd.conf):.
• дополнительно, в старых версиях NFS использовались бесы: nfslogd - бес журналов NFS фиксирует активность для экспортированных файловых систем, работает на серверах NFS и rquotad - сервер удаленных квот предоставляет информацию о квотах юзеров в удаленных файловых системах, может работать как на серверах, так и на клиентах.(RPC программа 100011)

В NFSv4 при использовании Kerberos дополнительно запускаются бесы:

• rpc.gssd - Бес NFSv4 обеспечивает методы аутентификации через GSS-API (Kerberos-аутентификация). Работает на клиенте и сервере.
• rpc.svcgssd - Бес сервера NFSv4, который обеспечивает проверку подлинности клиента на стороне сервера.

portmap и протокол RPC (Sun RPC)

Не считая обозначенных выше пакетов, для корректной работы NFSv2 и v3 требуется дополнительный пакет portmap (в более новых дистрибутивах заменен на переименован в rpcbind ). Данный пакет обычно устанавливается автоматом с NFS как зависимый и реализует работу сервера RPС, другими словами отвечает за динамическое назначение портов для некоторых служб, зарегистрированных в RPC сервере.

Дословно, согласно документации - это сервер, который преобразует номера программ RPC (Remote Procedure Call) в номера портов TCP/UDP. portmap оперирует несколькими сущностями: RPC-вызовами или запросами, TCP/UDP портами, версией протокола (tcp или udp), номерами программ и версиями программ. Бес portmap запускается скриптом /etc/init.d/portmap до старта NFS-сервисов.

Коротко говоря, работа сервера RPC (Remote Procedure Call) заключается в обработке RPC-вызовов (т.н. RPC-процедур) от локальных и удаленных процессов.

Используя RPC-вызовы, сервисы регистрируют или убирают себя в/из преобразователя портов (он же отображатель портов, он же portmap, он же portmapper, он же, в новых версиях, rpcbind), а клиенты с помощью RPC-вызовов направляя запросы к portmapper получают подходящую информацию. Юзер-френдли наименования сервисов программ и соответствующие им номера определены в файле /etc/rpc.

Как какой-либо сервис отправил соответствующий запрос и зарегистрировал себя на сервере RPC в отображателе портов, RPC-сервер присваивает сопоставляет сервису TCP и UDP порты на которых запустился сервис и хранит в себе ядре соответствующюю информацию о работающем сервисе (о имени), уникальном номере сервиса (в согласовании с /etc/rpc) , о протоколе и порте на котором работает сервис и о версии сервиса и предоставляет обозначенную информацию клиентам по запросу. Сам преобразователь портов имеет номер программы (100000), номер версии - 2, TCP порт 100 одиннадцать и UDP порт 111.

Выше, при указании состава бесов сервера NFS я указал главные RPC номера программ. Я, наверняка, малость запутал Вас данным абзацем, поэтому произнесу основную фразу, которая должна внести ясность: основная функция отображателя портов заключается в том, чтобы по запросу клиента, который предоставил номер RPC-программы (или RPC-номер программы) и версию, вернуть ему (клиенту) порт, на котором работает запрошенная программа . Соответственно, если клиенту нужно обратиться к RPC с определенным номером программы, он сначала должен войти в контакт с процессом portmap на серверной машине и отыскать номер порта связи с необходимым ему обслуживанием RPC.

Работу RPC-сервера можно представить следующими шагами:

Для получения инфы от RPC-сервера употребляется утилита rpcinfo. При указании черт -p host программа выводит список всех зарегистрированных RPC программ на хосте host. Без указания хоста программа выведет сервисы на localhost. Пример:

ARCHIV ~ # rpcinfo -p прог-ма верс прото порт 100 тыщ Два tcp 100 одиннадцать portmapper 100 тыщ Два udp 100 одиннадцать portmapper 100 тыщ 20 четыре Один udp 50 девять тыщ четыреста 50 один status 100 тыщ 20 четыре Один tcp Шестьдесят тыщ восемьсот 70 два status 100 тыщ 20 один Один udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Три udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Четыре udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Один tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ 20 один Три tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ 20 один Четыре tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ три Два tcp Две тыщи 40 девять nfs 100 тыщ три Три tcp Две тыщи 40 девять nfs 100 тыщ три Четыре tcp Две тыщи 40 девять nfs 100 тыщ три Два udp Две тыщи 40 девять nfs 100 тыщ три Три udp Две тыщи 40 девять nfs 100 тыщ три Четыре udp Две тыщи 40 девять nfs 100 тыщ 5 Один udp 50 одна тыща триста 6 mountd 100 тыщ 5 Один tcp 40 одна тыща четыреста 5 mountd 100 тыщ 5 Два udp 50 одна тыща триста 6 mountd 100 тыщ 5 Два tcp 40 одна тыща четыреста 5 mountd 100 тыщ 5 Три udp 50 одна тыща триста 6 mountd 100 тыщ 5 Три tcp 40 одна тыща четыреста 5 mountd

Как видно, rpcinfo указывает (в столбиках слева на право) номер зарегистрированной программы, версию, протокол, порт и название.

С помощью rpcinfo можно удалить регистрацию программы или получить информацию об отдельном сервисе RPC (больше опций в man rpcinfo). Как видно, зарегистрированы бесы portmapper версии Два на udp и tcp портах, rpc.statd версии Один на udp и tcp портах, NFS lock manager версий 1,3,4, бес nfs сервера версии 2,3,4, а так же бес монтирования версий 1,2,3.

NFS сервер (точнее бес rpc.nfsd) получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS работает с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт Две тыщи 40 девять жестко закреплен за NFS в большинстве реализаций.

Работа протокола Network File System

Монтирование удаленной NFS

Процесс монтирования удаленной файловой системы NFS можно представить следующей схемой:

Описание протокола NFS при монтировании удаленного каталога:

1. На сервере и клиенте запускается RPC сервер (обычно при загрузке), обслуживанием которого занимается процесс portmapper и регистрируется на порту tcp/111 и udp/111.
2. Запускаются сервисы (rpc.nfsd,rpc.statd и др.), которые регистрируются на RPC сервере и регистрируются на случайных сетевых портах (если в настройках сервиса не задан статичный порт).
3. команда mount на компьютере клиента отправляет ядру запрос на монтирование сетевого каталога с указанием типа файловой системы, хоста и практически - каталога, ядро отправляет сформировывает RPC-запрос процессу portmap на NFS сервере на порт udp/111 (если на клиенте не задана функция работать через tcp)
4. Ядро сервера NFS опрашивает RPC о наличии беса rpc.mountd и возвращает ядру клиента сетевой порт, на котором работает бес.
5. mount отправляет RPC запрос на порт, на котором работает rpc.mountd. На данный момент NFS сервер может проверить достоверность клиента основываясь на его IP адресе и номере порта, чтобы убедиться, можно ли этому клиенту смонтировать обозначенную файловую систему.
6. Бес монтирования возвращает описание запрошенной файловой системы.
7. Команда mount клиента выдает системный вызов mount, чтобы связать описатель файла, обретенный в шаге 5, с локальной точкой монтирования на хосте клиента. Описатель файла хранится в коде NFS клиента, и с этого момента хоть какое обращение пользовательских процессов к файлам на файловой системе сервера будет использовать описатель файла как стартовую точку.

Обмен данными меж клиентом и сервером NFS

Обыденный доступ к удаленной файловой системе можно описать следующей схемой:

Описание процесса обращения к файлу, расположенному на сервере NFS:

Настройка сервера NFS

Настройка сервера в целом заключается в задании локальных каталогов, разрешенных для монтирования удаленными системами в файле /etc/exports. Это действие называется экспорт иерархии каталогов . Основными источниками инфы об экспортированных каталогах служат следующие файлы:

• /etc/exports - основной конфигурационный файл, хранящий в себе конфигурацию экспортированных каталогов. Используется при запуске NFS и утилитой exportfs.
• /var/lib/nfs/xtab - содержит список каталогов, монтированных удаленными клиентами. Употребляется бесом rpc.mountd, когда клиент пробует смонтировать иерархию (создается запись о монтировании).
• /var/lib/nfs/etab - список каталогов, которые могут быть смонтированы удаленными системами с указанием всех черт экспортированных каталогов.
• /var/lib/nfs/rmtab - список каталогов, которые не разэкспортированы в данный момент.
• /proc/fs/nfsd - особенная файловая система (ядро 2.6) для управления NFS сервером.
• exports - список активных экспортированных иерархий и клиентов, которым их экспортировали, также свойства. Ядро получает данную информацию из /var/lib/nfs/xtab.
• threads - содержит число потоков (также можно изменять)
• с помощью filehandle можно получить указатель на файл
• и др...
• /proc/net/rpc - содержит "сырую" (raw) статистику, которую можно получить с помощью nfsstat, также различные кеши.
• /var/run/portmap_mapping - информация о зарегистрированных в RPC сервисах

Прим: вообще, в интернете куча трактовок и формулировок назначения файлов xtab, etab, rmtab, кому верить - не знаю #image.jpg Даже на http://nfs.sourceforge.net/ трактовка не однозначна.

Настройка файла /etc/exports

В ординарном случае, файл /etc/exports является единственным файлом, требующим редактирования для функции NFS-сервера. Данный файл управляет следующими свойствами:

• Какие клиенты могут обращаться к файлам на сервере
• К каким иерархиям каталогов на сервере может обращаться каждый клиент
• Как пользовательские имена клиентов будут отображаться на локальные имена юзеров

Неважно какая строка файла exports имеет следующий формат:

точка_экспорта клиент1(функции) [клиент2(функции) ...]

Где точка_экспорта абсолютный путь экспортируемой иерархии каталогов, клиент1 - n имя 1-го или более клиентов или Ip-адресов, разбитые пробелами, которым разрешено монтировать точку_экспорта . Функции обрисовывают правила монтирования для клиента, обозначенного перед опциями.

Вот обыденный пример конфигурации файла exports:

ARCHIV ~ # cat /etc/exports /archiv1 files(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

В данном примере компьютерам files и 10.0.0.1 разрешен доступ к точке экспорта /archiv1, при всем этом, хосту files на чтение/запись, а для хоста 10.0.0.1 и подсети 10.0.230.1/24 доступ только на чтение.

Описания хостов в /etc/exports допускается в следующем формате:

• Имена отдельных узлов описываются, как files или files.DOMAIN.local.
• Описание маски доменов делается в следующем формате: *DOMAIN.local включает все узлы домена DOMAIN.local.
• Подсети задаются в виде пар адрес IP/маска. Например: 10.0.0.0/255.255.255.0 включает все узлы, адреса которых начинаются с 10.0.0.
• Задание имени сетевой группы @myclients имеющей доступ к ресурсу (при использовании сервера NIS)

Общие функции экспорта иерархий каталогов

В файле exports употребляются следующие общие функции (сначала указаны функции применяемые по-умолчанию в большинстве систем, в скобках - не по-умолчанию):

• auth_nlm (no_auth_nlm) или secure_locks (insecure_locks) - указывает, что сервер должен добиваться аутентификацию запросов на блокировку (с помощью протокола NFS Lock Manager (диспетчер блокировок NFS)).
• nohide (hide) - если сервер экспортирует две иерархии каталогов, при всем этом одна вложенна (примонтированна) в другую. Клиенту необходимо разумеется смонтировать вторую (дочернюю) иерархию, по другому точка монтирования дочерней иерархии будет смотреться как пустой каталог. Функция nohide приводит к появлению 2-ой иерархии каталогов без тривиального монтирования. (прим: я данную опцию так и не смог вынудить работать...)
• ro (rw) - Разрешает только запросы на чтение (запись). (в конечном счете - может быть прочитать/записать или нет определяется на основании прав файловой системы, при всем этом сервер не способен отличить запрос на чтение файла от запроса на выполнение, поэтому разрешает чтение, если у пользователя есть права на чтение или выполнение.)
• secure (insecure) - просит, чтобы запросы NFS поступали с защищенных портов (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (no_subtree_check) - Если экспортируется подкаталог фаловой системы, но не вся файловая система, сервер проверяет, находится ли запрошенный файл в экспортированном подкаталоге. Отключение проверки уменьшает безопасность, но увеличивает скорость передачи данных.
• sync (async) - указывает, что сервер должен отвечать на запросы только после записи на диск конфигураций, выполненных этими запросами. Функция async указывает серверу не ждать записи инфы на диск, что наращивает производительность, но понижает надежность, т.к. в случае обрыва соединения или отказа оборудования возможна утрата инфы.
• wdelay (no_wdelay) - указывает серверу задерживать выполнение запросов на запись, если ожидается последующий запрос на запись, записывая данные более большими блоками. Это наращивает производительность при отправке больших очередей команд на запись. no_wdelay указывает не откладывать выполнение команды на запись, что может быть полезно, если сервер получает неограниченное количество команд не связанных совместно.

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

• в клиентской файловой системе должен существовать объект ссылки
• необходимо экспортировать и смонтировать объект ссылки

Файл устройства относится к интерфейсу ядра Linux. При экспорте файла устройства экспортируется этот интерфейс. Если клиентская система не имеет устройства такого же типа, то экспортированное устройство не будет работать.

В клиентской системе, при монтировании NFS объектов можно использовать опцию nodev, чтобы файлы устройств в монтируемых каталогах не использовались.

Функции по умолчанию в разных системах могут различаться, их можно посмотреть в файле /var/lib/nfs/etab. После описания экспортированного каталога в /etc/exports и перезапуска сервера NFS все недостающие функции (читай: функции по-умолчанию) будут отражены в файле /var/lib/nfs/etab.

Функции отображения (соответствия) идентификаторов юзеров

Для большего понимания нижесказанного я бы посоветовал ознакомиться со статьей Управление пользователями Linux. Каждый пользователь Linux имеет свои UID и главный GID, которые описаны в файлах /etc/passwd и /etc/group.

Сервер NFS считает, что операционная система удаленного узла выполнила проверку подлинности юзеров и назначила им корректные идентификаторы UID и GID. Экспортирование файлов дает пользователям системы клиента такой же доступ к этим файлам, как если бы они регистрировались напрямую на сервере. Соответственно, когда клиент NFS посылает запрос серверу, сервер употребляет UID и GID для идентификации пользователя в локальной системе, что может приводить к некоторым проблемам:

Следующие функции задают правила отображения удаленных юзеров в локальных:

Пример использования файла маппинга юзеров:

ARCHIV ~ # cat /etc/file_maps_users # Маппинг юзеров # remote local comment uid 0-50 Одна тыща два # сопоставление юзеров с удаленным UID 0-50 к локальному UID Одна тыща два gid 0-50 Одна тыща два # сопоставление юзеров с/span удаленным GID 0-50 к локальному GID 1002

Управление сервером NFS

Управление сервером NFS осуществляется с помощью следующих утилит:

• nfsstat
• showmsecure (insecure)ount
• exportfs

nfsstat: статистика NFS и RPC

Утилита nfsstat позволяет посмотреть статистику RPC и NFS серверов. Функции команды можно посмотреть в man nfsstat.

showmount: вывод инфы о состоянии NFS

Утилита showmount запрашивает бес rpc.mountd на удалённом хосте о смонтированных файловых системах. По умолчанию выдаётся отсортированный список клиентов. Ключи:

• --all - выдаётся список клиентов и точек монтирования с указанием куда клиент примонтировал каталог. Эта информация может быть не надежной.
• --directories - выдаётся список точек монтирования
• --exports - выдаётся список экспортируемых файловых систем исходя из убеждений nfsd

При запуске showmount без аргументов, на консоль будет выведена информация о системах, которым разрешено монтировать локальные сборники. Например, хост ARCHIV нам предоставляет список экспортированных каталогов с IP адресами хостов, которым разрешено монтировать обозначенные сборники:

FILES ~ # showmount --exports archiv Export list for archiv: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Если указать в аргументе имя хоста/IP, то будет выведена информация о данном хосте:

ARCHIV ~ # showmount files clnt_create: RPC: Program not registered # данное сообщение говорит нам, что на хосте FILES бес NFSd не запущен

exportfs: управление экспортированными каталогами

Данная команда обслуживает экспортированные сборники, данные в файле /etc/exports , точнее будет написать не обслуживает, а синхронизирует с файлом /var/lib/nfs/xtab и удаляет из xtab несуществующие. exportfs делается при запуске беса nfsd с аргументом -r. Утилита exportfs в режиме ядра 2.6 говорит с бесом rpc.mountd через файлы каталога /var/lib/nfs/ и не говорит с ядром напрямую. Без черт выдаёт список текущих экспортируемых файловых систем.

Свойства exportfs:

• [клиент:имя-каталога] - добавить или удалить обозначенную файловую систему для обозначенного клиента)
• -v - выводить больше инфы
• -r - переэкспортировать все сборники (синхронизировать /etc/exports и /var/lib/nfs/xtab)
• -u - удалить из списка экспортируемых
• -a - добавить или удалить все файловые системы
• -o - функции через запятую (аналогичен опциям применяемым в /etc/exports; т.о. можно изменять функции уже смонтированных файловых систем)
• -i - не использовать /etc/exports при добавлении, только свойства текущей командной строки
• -f - сбросить список экспортируемых систем в ядре 2.6;

Клиент NFS

До того как обратиться к файлу на удалённой файловой системе клиент ( клиента) должен смонтировать её и получить от сервера указатель на неё . Монтирование NFS может производиться с помощью команды mount или с помощью 1-го из расплодившихся автоматических монтировщиков (amd, autofs, automount, supermount, superpupermount). Процесс монтирования отлично продемонстрирована выше на иллюстрации.

На клиентах NFS никаких бесов запускать не нужно, функции клиента делает модуль ядра kernel/fs/nfs/nfs.ko, который используется при монтировании удаленной файловой системы. Экспортированные сборники с сервера могут устанавливаться на клиенте следующими способами:

• вручную, с помощью команды mount
• автоматом при загрузке, при монтировании файловых систем, обрисованных в /etc/fstab
• автоматом с помощью беса autofs

3-ий способ с autofs в данной статье я рассматривать не буду, ввиду его большой инфы. Может быть в следующих статьях будет отдельное описание.

Монтирование файловой системы Network Files System командой mount

Пример использования команды mount представлен в посте Команды управления блочными устройствами. Тут я рассмотрю пример команды mount для монтирования файловой системы NFS:

FILES ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small FILES ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big FILES ~ # mount ....... archiv:/archiv-small on /archivs/archiv-small type nfs (rw,addr=10.0.0.6) archiv:/archiv-big on /archivs/archiv-big type nfs (ro,addr=10.0.0.6)

1-ая команда монтирует экспортированный каталог /archiv-small на сервере archiv в локальную точку монтирования /archivs/archiv-small с опциями по умолчанию (другими словами для чтения и записи).

Хотя команда mount в последних дистрибутивах умеет обдумывать какой тип файловой системы употребляется и без указания типа, все же указывать параметр -t nfs лучше. 2-ая команда монтирует экспортированный каталог /archiv-big на сервере archiv в локальный каталог /archivs/archiv-big с опцией только для чтения (ro). Команда mount без черт наглядно указывает нам результат монтирования. Не считая функции только чтения (ro), может быть задать другие главные функции при монтировании NFS :

• nosuid - Данная функция запрещает исполнять setuid программы из смонтированного каталога.
• nodev (no device - не устройство) - Данная функция запрещает использовать в качестве устройств символьные и блочные особенные файлы.
• lock (nolock) - Разрешает блокировку NFS (по умолчанию). nolock отключает блокировку NFS (не запускает бес lockd) и комфортабельна при работе со старыми серверами, не поддерживающими блокировку NFS.
• mounthost=имя - Имя хоста, на котором запущен бес монтирования NFS - mountd.
• mountport=n - Порт, используемый бесом mountd.
• port=n - порт, используемый для подключения к NFS серверу (по умолчанию 2049, если бес rpc.nfsd не зарегистрирован на RPC-сервере). Если n=0 (по умолчанию), то NFS посылает запрос к portmap на сервере, чтобы отыскать порт.
• rsize=n (read block size - размер блока чтения) - Количество байтов, читаемых за один раз с NFS-сервера. Стандартно - 4096.
• wsize=n (write block size - размер блока записи) - Количество байтов, записываемых за один раз на NFS-сервер. Стандартно - 4096.
• tcp или udp - Для монтирования NFS использовать протокол TCP или UDP соответственно.
• bg - При утраты доступа к серверу, повторять пробы в фоновом режиме, чтобы не перекрыть процесс загрузки системы.
• fg - При утраты доступа к серверу, повторять пробы в приоритетном режиме. Данный параметр может заблокировать процесс загрузки системы повторениями попыток монтирования. По этой причине параметр fg употребляется в основном при отладке.

Функции, действующие на кэширование атрибутов при монтировании NFS

Атрибуты файлов , хранящиеся в inod (индексных дескрипторах), такие как время модификации, размер, жесткие ссылки, владелец, обычно изменяются изредка для обыденных файлов и еще реже - для каталогов. Многи программы, например ls, обращаются к файлам только для чтения и не меняют атрибуты файлов или содержимое, но затрачивают ресурсы системы на дорогостоящие сетевые операции.

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

• ac (noac) (attrebute cache - кэширование атрибутов) - Разрешает кэширование атрибутов (по-умолчанию). Хотя функция noac замедляет работу сервера, она позволяет избежать устаревания атрибутов, когда несколько клиентов активно записывают информацию в общию иерархию.
• acdirmax=n (attribute cache directory file maximum - кэширование атрибута максимум для файла каталога) - Наибольшее количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию Шестьдесят сек.)
• acdirmin=n (attribute cache directory file minimum - кэширование атрибута минимум для файла каталога) - Маленькое количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 30 сек.)
• acregmax=n (attribute cache regular file maximum - кэширование атрибута максимум для обыденного файла) - Максимаьное количество секунд, которое NFS ожидает до обновления атрибутов обыденного файла (по-умолчанию Шестьдесят сек.)
• acregmin=n (attribute cache regular file minimum- кэширование атрибута минимум для обыденного файла) - Маленькое количество секунд, которое NFS ожидает до обновления атрибутов обыденного файла (по-умолчанию Три сек.)
• actimeo=n (attribute cache timeout - таймаут кэширования атрибутов) - Заменяет значения для всех вышуказаных опций. Если actimeo не задан, то вышеуказанные значения принимают значения по умолчанию.

Функции обработки ошибок NFS

Следующие функции управляют действиями NFS при отсутствии ответа от сервера или в случае возникновения ошибок ввода/вывода:

• fg (bg) (foreground - передний план, background - задний план) - Создавать пробы монтирования отказавшей NFS на переднем плане/в фоне.
• hard (soft) - выводит на консоль сообщение "server not responding" при достижении таймаута и продолжает пробы монтирования. При данной функции soft - при таймауте докладывает вызвавшей операцию программе об ошибке ввода/вывода. (опцию soft советуют не использовать)
• nointr (intr) (no interrupt - не прерывать) - Не разрешает сигналам прерывать файловые операции в жестко смонтированной иерархии каталогов при достижении большого таймаута. intr - разрешает прерывание.
• retrans=n (retransmission value - значение повторной передачи) - После n малых таймаутов NFS генерирует большой таймаут (по-умолчанию 3). Большой таймаут прекращает выполнение операций или выводит на консоль сообщение "server not responding", зависимо от указания функции hard/soft.
• retry=n (retry value - значение повторно пробы) - Количество минут повторений службы NFS операций монтирования, до того как сдаться (по-умолчанию 10000).
• timeo=n (timeout value - значение таймаута) - Количество 10-х толикой секунды ожидания службой NFS до повторной передачи в случае RPC или малого таймаута (по-умолчанию 7). Это значение растет при каждом таймауте до большего значения Шестьдесят секунд или до пришествия большого таймаута. В случае занятой сети, медленного сервера или при прохождении запроса через несколько маршрутизаторов или шлюзов увеличение этого значения может повысить производительность.

Автоматическое монтирование NFS при загрузке (описание файловых систем в /etc/fstab)

Описание файла /etc/fstab я затрагивал в соответствующей статье. В текущем примере я рассмотрю несколько примеров монтирования файловых систем NFS с описанием опций:

FILES ~ # cat /etc/fstab | grep nfs archiv:/archiv-small /archivs/archiv-small nfs rw,timeo=4,rsize=16384,wsize=16384 Нуль Нуль nfs-server:/archiv-big /archivs/archiv-big nfs rw,timeo=50,hard,fg Нуль 0

1-ый пример монтирует файловую систему /archiv-small с хоста archiv в точку монтирования /archivs/archiv-small, тип файловой системы указан nfs (всегда необходимо указывать для данного типа), файловая система монтирована с опцией для чтения, записи (rw).

Хост archiv подключен по быстрому локальному каналу, поэтому для роста производительности параметр timeo уменьшен и существенно увеличены значения rsize и wsize. Поля для программ dump и fsck заданы в ноль, чтобы данные программы не использовали файловую систему, примонтированную по NFS.

2-ой пример монтирует файловую систему /archiv-big с хоста nfs-server. Т.к. к хосту nfs-server мы подключены по медленному соединению, параметр timeo увеличен до 5 сек (50 10-х толикой сек), а так же жестко задан параметр hard, чтобы NFS продолжала перемонтировать файловую систему после большого таймаута, так же задан параметр fg, чтобы при загрузке системы и недоступности хоста nfs-server не вышло зависания.

До того как сохранять конфигурации в /etc/fstab, обязательно попробуйте смонтировать вручную и убедитесь, что всё работает!!!

Повышение производительности NFS

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

Так же, одним из самых легких способов роста производительности NFS - увеличение количества байтов, передаваемых за один раз. Размер в Четыре тыщи девяносто 6 б очень мал для современных быстрых соединений, увеличивая это значение до Восемь тыщ 100 девяносто два и более можно экспериментальным способом найти наилучшую скорость.

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

Но на загруженных и медленных соединениях это время может быть меньше времени реакции сервера и способности каналов связи, в конечном итоге чего могут быть излишние повторные пересылки, замедляющие работу.По умолчанию, timeo равно 0,7 сек (700 миллисекунд). после неответа в течении Семьсот мс сервер совершит повторную пересылку и удвоит время ожидания до 1,4 сек., увеличение timeo будет продолжаться до большего значения в Шестьдесят сек. Далее зависимо от параметра hard/soft произойдет какое-либо действие (см.выше).

Подобрать наилучший timeo для определенного значения передаваемого пакета (значений rsize/wsize), можно с помощью команды ping:

FILES ~ # ping -s 30 две тыщи семьсот шестьдесят восемь archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) bytes of data. 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0.931 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 time=0.958 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 time=1.00 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms ^C --- archiv.DOMAIN.local ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 0.931/1.002/1.083/0.061 ms

Как видно, при отправке пакета размером 30 две тыщи семьсот шестьдесят восемь (32Kb) время его путешествия от клиента до сервера и вспять плавает в районе Один миллисекунды. Если данное время будет зашкаливать за Двести мс, то стоит задуматься о повышении значения timeo, чтобы оно превышало значение обмена в три-четыре раза. Соответственно, данный тест лучше делать во время сильной загрузки сети

Запуск NFS и настройка Firewall

Заметка скопипсчена с блога http://bog.pp.ru/work/NFS.html, за что ему большущее спасибо!!!

Запуск сервера NFS, монтирования, блокировки, квотирования и статуса с "правильными" портами (для сетевого экрана)

• лучше предварительно размонтировать все ресурсы на клиентах
• остановить и запретить запуск rpcidmapd, если не планируется внедрение NFSv4: chkconfig --level Триста 40 5 rpcidmapd off service rpcidmapd stop
• если нужно, то разрешить запуск сервисов portmap, nfs и nfslock: chkconfig --levels Триста 40 5 portmap/rpcbind on chkconfig --levels Триста 40 5 nfs on chkconfig --levels Триста 40 5 nfslock on
• если нужно, то остановить сервисы nfslock и nfs, запустить portmap/rpcbind, выгрузить модули service nfslock stop service nfs stop service portmap start # service rpcbind start umount /proc/fs/nfsd service rpcidmapd stop rmmod nfsd service autofs stop # где-то позднее его необходимо запустить rmmod nfs rmmod nfs_acl rmmod lockd
• открыть порты в iptables
  • для RPC: UDP/111, TCP/111
  • для NFS: UDP/2049, TCP/2049
  • для rpc.statd: UDP/4000, TCP/4000
  • для lockd: UDP/4001, TCP/4001
  • для mountd: UDP/4002, TCP/4002
  • для rpc.rquota: UDP/4003, TCP/4003
• для сервера rpc.nfsd добавить в /etc/sysconfig/nfs строку RPCNFSDARGS="--port 2049"
• для сервера монтирования добавить в /etc/sysconfig/nfs строку MOUNTD_PORT=4002
• для функции rpc.rquota для новых версий необходимо добавить в /etc/sysconfig/nfs строку RQUOTAD_PORT=4003
• для функции rpc.rquota необходимо для старых версий (все таки, необходимо иметь пакет quota 3.08 или свежее) добавить в /etc/services rquotad 4003/tcp rquotad 4003/udp
• проверит адекватность /etc/exports
• запустить сервисы rpc.nfsd, mountd и rpc.rquota (заодно запускаются rpcsvcgssd и rpc.idmapd, если не забыли их удалить) service nfsd start или в новых версиях service nfs start
• для сервера блокировки для новых систем добавить в /etc/sysconfig/nfs строки LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001
• для сервера блокировки для старых систем добавить непосредственно в /etc/modprobe[.conf]: options lockd nlm_udpport=4001 nlm_tcpport=4001
• привязать сервер статуса rpc.statd к порту Четыре тыщи (для старых систем в /etc/init.d/nfslock запускать rpc.statd с ключом -p 4000) STATD_PORT=4000
• запустить сервисы lockd и rpc.statd service nfslock start
• убедиться, что все порты привязались нормально с помощью "lsof -i -n -P" и "netstat -a -n" (часть портов употребляется модулями ядра, которые lsof не видит)
• если перед "перестройкой" сервером пользовались клиенты и их не удалось размонтировать, то придётся перезапустить на клиентах сервисы автоматического монтирования (am-utils, autofs)

Пример конфигурации NFS сервера и клиента

Конфигурация сервера

Если вы желаете сделать ваш разделённый NFS каталог открытым и с правом записи, вы можете использовать опцию all_squash в композиции с опциями anonuid и anongid. Например, чтобы установить права для пользователя "nobody" в группе "nobody", вы можете сделать следующее:

ARCHIV ~ # cat /etc/exports # Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя Девяносто девять с gid Девяносто девять /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99)) # Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя Девяносто девять с gid Девяносто девять /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

Это также означает, что если вы желаете разрешить доступ к обозначенной директории, nobody.nobody должен быть владельцем разделённой директории:

# chown -R nobody.nobody /files

Конфигурация клиента

На клиенте необходимо примонтировать удаленный каталогудобным способом, например командой mount:

FILES ~ # mount -t nfs archiv:/files /archivs/files

Резюме

Фух... Статья завершена. На данный момент мы изучили что такое Network File System и с чем ее едят, в следующей статье попробую сделать HOWTO с аутентификацией Kerberos. Надеюсь материал вышел доходчивым и нужным.

Буду рад Вашим дополнениям и комментариям!

NFS HOWTO, nfs.sourceforge, man nfs? man mount, man exports

RFC Одна тыща девяносто четыре - NFSv1, v2
RFC Одна тыща восемьсот тринадцать - NFSv3
RFC Три тыщи 500 30 - NFSv4
RFC 5 тыщ 600 шестьдесят один - NFSv4.1
NFS HOWTO
nfs.sourceforge.net
man mount
man exports

Сетевая файловая система (NFS - Network File System) является решением об­щего доступа к файлам для организаций, которые имеют смешанные среды машин с Windows и Unix/Linux. Файловая система NFS дает возможность открывать общий доступ к файлам между указанными разными платформами при функционирую­щей операционной системе Windows Server 2012. Службы NFS в Windows Server 2012 включают следующие возможности и усовершенствования.

1. Поиск в Active Directory. Вы имеете возможность применять Windows Active Directory для доступа к файлам. Расширение схемы Identity Management for Unix (Управление удостоверениями для Unix) для Active Directory содержит поля идентификатора пользователя Unix (Unix user identifier - UID) и иден­тификатора группы (group identifier - GID). Это позволяет службам Server for NFS (Сервер для NFS) и Client for NFS (Клиент для NFS) просматривать отображения учетных записей пользователей Windows на Unix прямо из служб домена Active Directory (Active Directory Domain Services). Компонент Identity Management for Unix упрощает управление отображением учетных записей пользователей Windows на Unix в Active Directory Domain Services.

2. Улучшенная производительность сервера. Службы для NFS включают драйвер фильтра файлов, который значительно сокращает общие задержки при досту­пе к файлам на сервере.

3. Поддержка специальных устройств Unix. Службы для NFS поддерживают спе­циальные устройства Unix (mknod).

4. Расширенная поддержка Unix. Службы для NFS поддерживают следующие вер­сии Unix: Sun Microsystems Solaris версии 9, Red Hat Linux версии 9, IBM AIX версии 5L 5.2 и Hewlett Packard HP-UX версии 11i, а также многие современные дистрибутивы Linux.

Один из наиболее распространенных сценариев, который создает необходи­мость в применении NFS, предусматривает открытие доступа пользователям в среде Windows к системе планирования ресурсов предприятия (enterprise resource planning - ERP), основанной на Unix. Находясь в системе ERP, пользователи могут создавать отчеты и/или экспортировать финансовые данные в Microsoft Excel для дальнейшего анализа. Файловая система NFS позволяет обращаться к этим файлам, по-прежнему находясь в среде Windows, что сокращает потребность в наличии специальных технических навыков и снижает временные затраты на экспорт файлов с использованием сценария Unix и последующий их импорт в определенное приложение Windows.

Может также возникнуть ситуация, когда у вас имеется система Unix, которая применяется для хранения файлов в какой-то сети хранения данных (Storage Area Network - SAN). Запуск служб NFS на машине Windows Server 2012 позволяет пользователям в организации получать доступ к сохраненным там файлам без накладных расходов, связанных со сценариями на стороне Unix.

До установки служб NFS вы должны удалить любые ранее установленные компоненты NFS, такие как компоненты NFS, которые были включены в состав Services for Unix.

Компоненты служб NFS

Доступны следующие два компонента служб NFS.

1. Server for NFS (Сервер для NFS). Обычно компьютер, основанный на Unix, не может обращаться к файлам, расположенным на компьютере, основанном на Windows. Тем не менее, компьютер, на котором функционирует Windows Server 2012 R2 и компонент Server for NFS, может действовать в качестве файло­вого сервера для компьютеров с Windows и Unix.

2. Client for NFS (Клиент для NFS). Обычно компьютер, основанный на Windows, не может обращаться к файлам, находящимся на компьютере, основанном на Unix. Тем не менее, компьютер, на котором функционирует Windows Server 2012 R2 и компонент Client for NFS, может получать доступ к файлам, которые хранятся на сервере NFS, основанном на Unix.

Установка Server For NFS с помощью PowerShell

Давайте посмотрим, как применять PowerShell для установки роли NFS на сервере и для создания общего файлового ресурса NFS.

1. Откройте окно Windows PowerShell через панель задач от имени учетной запи­си администратора.

2. Введите следующие команды, чтобы установить роль NFS на сервере:

PS С:\> Import-Module ServerManager PS С:\> Add-WindowsFeature FS-NFS-Services PS С:\> Import-Module NFS

3. Введите приведенную ниже команду, чтобы создать новый общий файловый ресурс NFS:

PS С:\> New-NfsShare -Name "Test" -Path "C:\Shares\Test"

4. Для просмотра всех новых командлетов PowerShell, относящихся к NFS, кото­рые доступны в Windows Server 2012 R2, выполните следующую команду:

PS С:\> Get-Command -Module NFS

5. Щелкните по папке C:\Shares\Test правой кнопкой мыши, выберите «свойства», далее перейдите на вкладку NFS Sharing (Общий доступ NFS). Нажмите на кнопку Manage NFS Sharing (Управлять общим доступом NFS), в появившемся диалоговом окне вы можете управлять разрешениями для доступа к папке, разрешить анонимный доступ, настроить параметры кодировки файлов. Вы можете открывать общий доступ к папке по NFS с помощью диалогового окна NFS Advanced Sharing без использования PowerShell.

Установка стандартных разрешений

Теперь нам потребуется открыть некоторые порты брандмауэра для функционирования NFS. Порты, необходимые для нормального функционирования служб NFS, представлены ниже в таблице.

Сетевые службы

Лекция 10

Совокупность серверной и клиентской частей ОС, предоставляющих доступ к конкретному типу ресурса компьютера через сеть, называется сетевой службой . Клиентская часть обращается с сетевыми запросами к серверной части другого компьютера. Серверная часть удовлетворяет запросы к локальным ресурсам сервера. Клиентская часть – активная, серверная – пассивная.

При сетевом взаимодействии значительное место занимает доступ через сеть к файловой системе. В этом случае клиентская и серверная части, совместно с сетевой файловой системой образуют файловую службу

Ключевым компонентом распределенной ОС является сетевая файловая система. Сетевая файловая система поддерживается одним или несколькими компьютерами, хранящими файлы (файловые сервера)

Клиентские компьютеры подсоединяются или монтируют эти файловые системы к своим локальным файловым системам

Файловая служба включает программы-серверы и программы-клиенты, взаимодействующие по сети с помощью протокола.

Файловые службы включает собственно файловую службу (файловые операции) и службу каталогов (управление каталогами)

Модель сетевой файловой службы включает следующие элементы:

Локальная файловая система (FAT, NTFS)

Интерфейс локальной файловой системы (системные вызовы)

Сервер сетевой файловой системы

Клиент сетевой файловой системы (Windows Explorer, UNIX shell и пр.)

Интерфейс сетевой файловой системы(повторяет системные вызовы локальной файловой системы)

Протокол клиент-сервер сетевой файловой системы (SMB-Server Message Block для Windows, NFS (Network File System) и FTP (File Transfer Protocol) для UNIX)

Интерфейс сетевой файловой системы

Существуют несколько типов интерфейсов, которые характеризуются:

Структура файлов . Большинство сетевых ФС поддерживают неструктурированные файлы

Модифицируемость файлов . В большинстве сетевых ФС имеется возможность модифицировать файл. Некоторые распределенные ФС запрещают операции модификации. Возможны лишь create и read. Для таких файлов легче организовать кэширование и тиражирование.

Семантика разделения файлов:

Семантика UNIX (централизованная). Если чтение следует за несколькими операциями записи, то читается последнее обновление. Этот принцип возможен и в распределенной файловой системе, при условии одного файлового сервера и отсутствия кэширование файлов у клиента.

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

Механизм транзакций. Это способ работы с разделяемыми файлами с помощью механизма транзакций (неделимых операций)

Контроль доступа . Например для Windows NT/2000 существует два механизма: на уровне каталогов (для FAT) и на уровне файлов (NTFS)

Единица доступа. Модель загрузки-выгрузки файла целиком (FTP). Вторая модель - использование операций над файлами.

Основные особенности работы файловой системы NFS на платформе UNIX.

Счастье - это когда наши желания совпадают с чужими возможностями.

"Времечко"

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

В настоящее время операционная система UNIX переживает своего рода ренессанс, и во многом она обязана таким подъемом интереса свободно распространяемой ОС Linux. Вместе с тем на настольных компьютерах используются различные варианты Windows, прежде всего, Windows 9x и Windows NT/2000, хотя и здесь постепенно получают гражданство свободно распространяемые разновидности UNIX.

Для многих организаций размещение сетевого файлового сервиса на компьютерах с UNIX является весьма привлекательным решением при условии, что такой сервис имеет достаточную производительность и надежность. Учитывая многочисленные различия в файловых системах UNIX и Windows, прежде всего в схемах именования файлов, особенностях прав доступа, блокировках и системных вызовах при обращении к файлам, особое значение приобретает обеспечение прозрачности доступа в гетерогенной среде UNIX/Windows. Кроме того, нередко файловые серверы UNIX устанавливаются в качестве дополнения к уже имеющимся серверам Windows NT и NetWare.

Для операционной системы UNIX имеются реализации всех более или менее популярных сетевых файловых систем, включая используемых в сетях Microsoft (SMB), NetWare (NCP), Macintosh (AFP). Разумеется, для сетей UNIX существуют свои собственные протоколы, прежде всего, NFS и DFS. Следует иметь в виду, что любой сервер UNIX может одновременно предоставлять услуги NFS и SMB (так же, как NCP и AFP) и таким образом обеспечивает дополнительную гибкость при создании сетевой инфраструктуры.

Несмотря на разнообразие сетевых файловых систем UNIX, безусловными лидерами являются системы NFS (Network File System, дословный перевод - сетевая файловая система) и SMB (Service Message Block). В данной статье речь пойдет о возможностях NFS. Вместе с тем в одном из ближайших номеров мы планируем рассмотреть характеристики работ SMB на платформе UNIX и, в первую очередь, продукт Samba, который хорошо зарекомендовал себя в сетях UNIX/Windows.

ВЕРСИИ NFS

Первая реализация сетевой файловой системы NFS была разработана компанией Sun Microsystems еще в 1985 году. С тех пор NFS получила широкое распространение в мире UNIX, и количество ее инсталляций исчисляется десятками миллионов. Кроме UNIX система NFS как серверная платформа нашла применение в операционных системах VMS, MVS и даже Windows.

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

В настоящее время NFS представлена второй и третьей версиями (первая версия NFS на рынке никогда не появлялась). Несмотря на ряд ограничений, NFS v2 пользуется большой популярностью; именно она входит в состав свободно распространяемых UNIX (в частности, Linux), а также некоторых коммерческих UNIX.

Третья версия NFS была разработана в середине 90-х годов совместными усилиями Sun, IBM, Digital и других компаний с целью повышения производительности, безопасности и удобства администрирования сетевой файловой системы. NFS v3 обратно совместима с предыдущей спецификацией NFS, т. е. сервер NFS v3 может обслуживать не только клиентов NFS v3, но и клиентов NFS v2.

Несмотря на свое достаточно длительное присутствие на рынке, по количеству инсталляций NFS v3 до сих пор уступает NFS v2. Исходя из этих соображений, мы остановимся вначале на основных характеристиках NFS v2, а затем познакомимся с нововведениями в третьей версии NFS.

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

ПРОТОКОЛЫ NFS V2

На Рисунке 1 представлена сетевая модель NFS v2 в соответствии с эталонной моделью OSI. В отличие от большинства сетевых служб TCP/IP система NFS явным образом использует протоколы презентационного и сеансового уровня. Работа NFS опирается на концепцию вызовов удаленных процедур (Remote Procedure Call, RPC). Согласно этой концепции, при доступе к удаленному ресурсу (например, к файлу) программа на локальном компьютере выполняет обычный системный вызов (предположим, вызов функции открытия файла), но на самом деле процедура выполняется удаленно - на сервере ресурсов. При этом пользовательский процесс не в состоянии определить, как выполняется вызов - локально или удаленно. Установив, что процесс обращается к ресурсу на удаленном компьютере, выступающем в качестве сервера, ядро или специальный демон системы упаковывает аргументы процедуры вместе с ее идентификатором в сетевой пакет, открывает сеанс связи с сервером и пересылает ему данный пакет. Сервер распаковывает полученный пакет, определяет запрашиваемую процедуру и аргументы, а затем выполняет процедуру. Далее сервер пересылает клиенту код возврата процедуры, а тот передает его пользовательскому процессу. Таким образом, RPC полностью соответствует сеансовому уровню модели OSI.

Возникает справедливый вопрос: зачем в сетевой модели NFS нужен специальный протокол презентационного уровня? Дело в том, что Sun благоразумно рассчитывала на применение NFS в гетерогенных сетях, где компьютеры имеют различную системную архитектуру, в том числе различный порядок представления байтов в машинном слове, различное представление чисел с плавающей точкой, несовместимые границы выравнивания структур и т. д. Поскольку протокол RPC предполагает пересылку аргументов процедур, т. е. структурированных данных, то наличие протокола презентационного уровня является насущной необходимостью в гетерогенной среде. В качестве такового выступает протокол внешнего представления данных (eXternal Data Representation, XDR). Он описывает так называемую каноническую форму представления данных, не зависящую от системной архитектуры процессора. При передаче пакетов RPC клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию. Следует иметь в виду, что каноническая форма XDR соответствует представлению данных, принятому для семейства процессоров SPARC и Motorola. В серверах, где реализована аналогичная форма представления данных, это позволяет добиться некоторого (правда, скорее всего, микроскопического) преимущества в производительности над конкурентами в случаях интенсивного обращения к файловому серверу.

В NFS v2 в качестве транспортного протокола был выбран UDP. Разработчики объясняют это тем, что сеанс RPC длится короткий промежуток времени. Более того, с точки зрения выполнения удаленных процедур каждый пакет RPC является самодостаточным, т. е. каждый пакет несет полную информацию о том, что необходимо выполнить на сервере, или о результатах выполнения процедуры. Сервисы RPC обычно не отслеживают состояние связи (connectionless), т. е. сервер не хранит информацию о том, какие запросы клиента обрабатывались в прошлом: например, с какого места файла клиент считывал данные последний раз. Для сетевой файловой системы это определенное преимущество с точки зрения надежности, так как клиент может продолжать файловые операции сразу же после перезагрузки сервера. Но такая схема чревата возникновением проблем при записи и блокировке файлов, и, чтобы их обойти, разработчики NFS были вынуждены применять разные обходные маневры (использование UDP порождает еще один ряд специфических проблем, но их мы коснемся позже).

Важное отличие сервисов RPC, входящих в состав NFS, от других сетевых серверных служб состоит в том, что они не используют супердемон inetd. Рядовые сетевые службы, наподобие telnet или rlogin, обычно не запускаются в виде демонов при старте системы, хотя это делать не возбраняется. Чаще всего они задействуют так называемый супердемон inetd, который "прослушивает" программные порты протоколов TCP и UDP. Службы задаются в конфигурационном файле супердемона (обычно /etc/inetd.conf). При поступлении запроса на программный порт со стороны клиента inetd запускает в качестве дочернего процесса соответствующую сетевую службу (например, in.rlogind), которая и обрабатывает запрос.

Службы RPC не пользуются супердемоном inetd, поскольку, как уже было сказано, сеанс RPC длится очень недолго, фактически лишь в течение обработки одного-единственного запроса. Т. е. для каждого запроса inetd был бы вынужден запускать новый дочерний процесс службы RPC, что весьма накладно для UNIX. По аналогичным соображениям процесс RPC не может порождать новые процессы и не может параллельно обслуживать сразу несколько запросов. Поэтому в целях повышения производительности сервисы RPC запускаются в виде нескольких одновременно работающих экземпляров демонов. При этом количество экземпляров конкретного демона напрямую не связано с количеством клиентов. Даже один демон может обслуживать множество клиентов, но за один раз он способен обрабатывать единственный запрос, остальные будут помещаться в очередь.

Еще одно важное отличие сервисов RPC от обычных сетевых служб состоит в том, что они не используют заранее заданных программных портов UDP. Вместо этого применяется так называемая система трансляции портов portmapper. Для ее поддержки при загрузке системы инициализируется специальный демон portmap. В рамках системы трансляции портов за каждым сервисом RPC закрепляется программный номер (program number), номер версии, номер процедуры (procedure number) и протокол (UDP или TCP). Программный номер однозначно идентифицирует конкретный сервис RPC. Взаимосвязь между именами сервисов RPC и программными номерами можно проследить на основании содержимого файла /etc/rpc. Каждая программа RPC поддерживает множество процедур, которые определяются по их номерам. Номера процедур можно узнать в соответствующих header-файлах: например, для сервиса NFS они задаются в файле /usr/include/nfs/nfs.h.

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

Принцип работы транслятора portmap достаточно прост. При инициализации (в частности, в момент загрузки ОС) какого-либо сервиса RPC он регистрируется с помощью демона portmap. При запуске на сервере сервис RPC ищет незанятый программный порт, резервирует его за собой и сообщает номер порта демону portmap. Для того чтобы связаться с сервером, клиент RPC должен сначала обратиться к portmap сервера и узнать у него, какой программный порт занимает конкретный сервис RPC на сервере. Только затем клиент может непосредственно связаться с сервисом. В некоторых случаях клиент связывается с нужным сервисом косвенным образом, т. е. вначале он обращается к демону portmap, а тот запрашивает сервис RPC от лица клиента. В отличие от сервисов RPC, транслятор портов portmap всегда привязан к заранее заданному порту 111, так что клиент связывается с portmap стандартным способом.

СОСТАВ NFS V2

В общем случае помимо portmap сервер NFS включает демоны rpc.mountd, nfsd, rpc.lockd, rpc.statd. На клиентской машине NFS, функционирующей на платформе UNIX, должны быть запущены демоны biod (необязательно), rpc.lockd и rpc.statd.

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

Демон rpc.mountd обслуживает запросы клиентов на монтирование файловых систем. Сервис монтирования реализован в виде отдельного демона, так как протокол монтирования не является частью NFS. Это вызвано тем, что операция монтирования тесно привязана к синтаксису имен файлов, а принципы именования файлов различаются для UNIX и, скажем, для VMS.

Демон nfsd принимает и обслуживает запросы NFS RPC. Обычно в целях повышения производительности на сервере запускают несколько экземпляров nfsd.

Демон rpc.lockd, функционирующий как на клиенте, так и на сервере, предназначен для блокировки файлов, тогда как демон rpc.statd (также исполняемый на сервере и клиенте) ведет статистику блокировок на случай необходимости их автоматического восстановления при крахе сервиса NFS.

Демон biod, запускаемый на клиенте, способен производить операции "чтение с опережением" и "отложенная запись", что серьезно повышает производительность. Однако наличие biod не является обязательным для работы клиента. Для еще большего повышения производительности на клиентской машине можно загрузить несколько демонов biod.

Еще один демон, выполняющийся на сервере, отвечает за аутентификацию и сервис печати для клиентов DOS/Windows, в некоторых системах он носит имя pcnfsd, в других - in.pcnfsd.

Кроме того, в комплект поставки NFS входят различные системные утилиты и программы диагностики (showmount, rpcinfo, exportfs, nfsstat).

ПРАВИЛА ЭКСПОРТИРОВАНИЯ

Файловые системы и каталоги, которые клиенты могут удаленно монтировать на сервере NFS, должны быть явно заданы. Данная процедура называется в NFS "экспортированием" ресурсов. В то же время сервер NFS, в отличие от, скажем, сервера SMB, не занимается широковещательной рассылкой списка своих экспортируемых ресурсов. Тем не менее клиент может запросить у сервера такой список. На стороне сервера за обслуживание запросов монтирования отвечает демон rpc.mountd.

Экспортирование файловых ресурсов NFS производится в соответствии с четырьмя основными правилами.

1. Файловую систему можно экспортировать как целиком, так и по частям, каковыми являются каталоги и файлы. При этом следует помнить, что самой крупной экспортируемой единицей является файловая система. Если на сервере некая файловая система (/usr/bin) смонтирована по иерархии ниже другой файловой системы (/usr), то экспортирование системы /usr систему /usr/bin не затронет.
2. Экспортировать можно только локальные файловые ресурсы, иными словами, если на сервере смонтирована чужая файловая система, т. е. находящаяся на другом сервере, то ее нельзя реэкспортировать.
3. Нельзя экспортировать подкаталоги уже экспортированной файловой системы, если только они не представляют собой самостоятельных файловых систем.
4. Нельзя экспортировать родительские каталоги уже экспортированного каталога, если только родительский каталог не представляет собой независимую файловую систему.

Любое нарушение этих правил приведет к ошибке в работе NFS.

Таблица экспортируемых ресурсов располагается в файле /etc/exports. К сожалению, синтаксис этого файла зависит от конкретных UNIX, поэтому в качестве примера мы возьмем Solaris. Файл /etc/exports состоит из текстовых строк, имеющих формат:

-,...

Некоторые наиболее популярные опции перечислены в Таблице 1. Фактически опции описывают права доступа к экспортируемым ресурсам со стороны клиентов. Важно помнить, что права доступа, перечисленные при экспортировании, никоим образом не отменяют права доступа, действующие непосредственно в файловой системе. Например, если файловая система экспортируется с возможностью записи, а конкретный файл имеет атрибут "только для чтения", то его изменение будет невозможно. Таким образом, при экспортировании права доступа выступают в качестве дополнительного фильтра. Более того, если, скажем, файловая система экспортируется с опцией ro (read only), то клиент имеет право смонтировать ее с опцией rw (read/write), однако при этом попытка произвести запись приведет к выдаче сообщения об ошибке.

Опция access позволяет указать хосты с правом монтирования ресурса. Соответственно, ни один другой хост, кроме упомянутых в ней, не имеет возможности монтировать, а значит, и проводить операции над ресурсом.

Список хостов, которые могут записывать информацию, задается с помощью опции rw. Если в опции rw список хостов не указан, то производить запись имеет право любой хост.

Опция root позволяет указать хосты, в которых локальные суперпользователи root получают права root сервера на экспортируемый ресурс. В противном случае, даже если хосту даны права rw, пользователь root на нем приравнивается к пользователю nobody (uid=-2), т. е. к пользователю с минимальными правами доступа. Вышесказанное относится именно к правам доступа к удаленному ресурсу и не влияет на права доступа к локальным ресурсам клиента.

Опции anon и secure будут рассмотрены при описании схемы аутентификации NFS.

ПРАВИЛА МОНТИРОВАНИЯ

Если для сервера экспортируемые ресурсы могут выступать в качестве файловой системы или отдельного каталога, то для клиента они всегда выглядят как файловые системы. Поскольку поддержка NFS встроена в ядро UNIX, то операция монтирования файловых систем NFS производится стандартной утилитой mount (отдельный демон для монтирования NFS не требуется), при этом необходимо лишь оговорить, что монтируемая файловая система - NFS. Еще один способ монтирования - с помощью файла /etc/fstab (/etc/filesystems в некоторых версиях UNIX). В данном случае удаленные системы NFS (так же, как и локальные) монтируются на стадии загрузки ОС. Точки монтирования могут быть любые, в том числе и в составе других файловых систем NFS, т. е. системы NFS можно "нанизывать" друг на друга.

Основные опции монтирования NFS перечислены в Таблице 2.

Опция bg позволяет производить монтирование в фоновом режиме, в этом случае можно запускать другие команды монтирования.

Весьма интересной представляется пара опций hard/soft. При "жестком" монтировании клиент будет пытаться смонтировать файловую систему во что бы то ни стало. Если сервер не работает, это приведет к тому, что весь сервис NFS как бы зависнет: процессы, обращающиеся к файловой системе, перейдут в состояние ожидания окончания выполнения запросов RPC. С точки зрения пользовательских процессов файловая система будет выглядеть как очень медленный локальный диск. При возврате сервера в рабочее состояние сервис NFS будет продолжать функционировать как ни в чем не бывало. Использование опции intr позволяет с помощью системного сигнала INTERRUPT прервать процесс "жесткого" монтирования.

При "мягком" монтировании клиент NFS сделает несколько попыток подключиться к серверу, как оговорено в опциях retans и timeo (некоторыми системами поддерживается также специальная опция retry). Если сервер не откликается, то система выдает сообщение об ошибке и прекращает попытки произвести монтирование. С точки зрения логики файловых операций при отказе сервера "мягкое" монтирование эмулирует сбой локального диска. Если опция retrans (retry) не задана, то количество попыток ограничено значением, принятым по умолчанию для данной системы UNIX. Параметры retrans и timeo относятся не только к монтированию, но и к любым операциям RPC, производимым с файловой системой NFS. Т. е. если клиент осуществляет операцию записи, а в это время в сети или на сервере происходит сбой, то клиент будет пытаться повторить запросы.

На вопрос, какой из режимов, "мягкий" или "жесткий", лучше, однозначно ответить невозможно. Если данные на сервере должны быть согласованы при его временном отказе, то "жесткое" монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах "только для чтения", режим "мягкого" монтирования представляется более предпочтительным.

АУТЕНТИФИКАЦИЯ И БЕЗОПАСНОСТЬ

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

В NFS аутентификация производится исключительно на этапе монтирования файловой системы и только на основании доменного имени (или IP-адреса) клиентской машины. Т. е. если клиент NFS (здесь подразумевается компьютер, а не пользователь компьютера) обращается к серверу с запросом на монтирование, то сервер определяет права доступа по таблице /etc/exports, при этом клиент идентифицируется по имени (IP-адресу) компьютера. Если клиенту разрешено производить те или иные операции над экспортируемым ресурсом, то ему сообщается некое "магическое число" (magic cookie). В дальнейшем для подтверждения своих полномочий клиент должен включать это число в каждый запрос RPC.

Вот, собственно, и весь нехитрый набор средств аутентификации клиентов, пользователи же никак не аутентифицируются. Тем не менее каждый запрос RPC содержит идентификатор пользователя uid, инициировавшего запрос, и список идентификаторов групп gid, куда входит пользователь. Но эти идентификаторы используются не для аутентификации, а для определения прав доступа конкретного пользователя к файлам и каталогам.

Обратите внимание, что uid и gid определяются на стороне клиента, а не сервера. Поэтому перед администраторами встает проблема согласования содержимого /etc/passwd (и /etc/group) между клиентами и серверами NFS, чтобы пользователю Васе на сервере не присвоили права пользователя Пети. Для больших сетей это представляет серьезные трудности. Обеспечить согласованность пользовательской базы данных, а также таких системных файлов, как /etc/hosts, /etc/rpc, /etc/services, /etc/protocols, /etc/aliases и др., можно с помощью сетевой информационной службы (Network Information System, NIS), разработанной компанией Sun еще в 1985 году и входящей в состав большинства версий UNIX (более продвинутая ее разновидность NIS+ не нашла широкого применения). NIS представляет собой информационную службу, в первом приближении напоминающую службу каталогов Windows NT, и позволяет централизованно хранить и обрабатывать системные файлы. Между прочим, NIS построена по тому же принципу, что и NFS, в частности она использует протоколы RPC и XDR.

Еще одна важная особенность NFS состоит в том, что в каждом запросе RPC передается список групп gid пользователя. Для ограничения размера пакета RFC в большинстве реализаций NFS количество групп не может превышать 8 или 16. Если пользователь входит в состав большего количества групп, то это может привести к ошибкам при определении прав доступа на сервере. Данная проблема весьма актуальна для корпоративных файловых серверов. Радикальным решением является использование списков контроля доступа ACL, но, к сожалению, далеко не все разновидности UNIX их поддерживают.

Принятая в NFS система аутентификации весьма убога и не обеспечивает надежной защиты. Любой, кто имел дело с NFS, знает, как просто обойти ее систему безопасности. Для этого даже не обязательно применять методы подделки IP-адресов (IP-spoofing) или имен (DNS-spoofing). Злоумышленнику достаточно перехватить "магическое число", и в дальнейшем он может проводить действия от имени клиента. К тому же "магическое число" не меняется до следующей перезагрузки сервера.

На многочисленных серверах Internet можно узнать и другие, в том числе весьма экзотические, способы взлома NFS. Количество обнаруженных "дыр" исчисляется тысячами. Поэтому NFS v.2 рекомендуется использовать только внутри защищенных сетей.

Исходя из этих соображений, Sun разработала протокол SecureRPC с использованием как несимметричных, так и симметричных ключей шифрования. При этом криптографические методы применяются для аутентификации не только хостов, но и пользователей. Однако сами данные не шифруются. К сожалению, из-за экспортных ограничений правительства США не все UNIX поставляются с поддержкой SecureRPC. Поэтому мы не будем останавливаться на возможностях этого протокола. Тем не менее если ваша версия UNIX поддерживает SecureRPC, то неоценимую помощь в его настройке окажет книга Хала Стейна "Managing NFS and NIS" издательства O"Reilly & Assоciates.

Еще одна проблема связана с клиентами NFS на платформах MS-DOS и Windows 3.x/9x. Эти системы являются однопользовательскими, и обычными средствами NFS идентифицировать пользователя невозможно. Для целей идентификации пользователей DOS/Windows на сервере запускается демон pcnfsd. При подключении (монтировании) дисков NFS на клиентской машине он запрашивает имя и пароль пользователя, что позволяет не только идентифицировать, но и аутентифицировать пользователей.

Хотя ОС Windows NT является многопользовательской, но ее пользовательская база данных и схема идентификации пользователей несовместимы с принятой в UNIX. Поэтому клиентские места NFS на базе Windows NT также вынуждены задействовать возможности pcnfsd.

Кроме аутентификации пользователей pcnfs позволяет осуществлять печать на UNIX с клиентских мест DOS/Windows. Правда, в состав Windows NT изначально входит программа LPR.EXE, также позволяющая осуществлять печать на серверах UNIX.

Для доступа к файловому сервису и сервису NFS на машинах DOS/Windows необходимо инсталлировать специальное клиентское ПО, причем цены на эти продукты весьма кусаются.

Вернемся, однако, к опциям экспортирования файлов NFS (см. Таблицу 1). Опция anon определяет идентификатор пользователя uid в том случае, когда пользователь DOS/Windows не мог себя аутентифицировать (задал неверный пароль) или когда пользователь хоста, подключенного по SecureRPC, не прошел аутентификацию. По умолчанию anon имеет uid=-2.

Опция secure применяется, когда используется протокол SecureRPC.

АРХИТЕКТУРНЫЕ ОСОБЕННОСТИ NFS V2

Файловые системы 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. При этом демоны осуществляют кэширование информации при чтении с дисков сервера. Все демоны обслуживают одну и ту же очередь запросов клиентов, что позволяет оптимально использовать ресурсы процессора.

К сожалению, определить оптимальное количество демонов biod и nfsd очень непросто. С одной стороны, чем больше количество работающих демонов, тем большее количество запросов может быть обработано одновременно; с другой стороны, увеличение количества демонов может неблагоприятно повлиять на производительность системы ввиду возрастания накладных расходов на переключение процессов. Тонкая настройка NFS представляет собой весьма утомительную процедуру и требует учета не только количества клиентов и пользовательских процессов, но и таких характеристик, как время переключения между контекстами процессов (т. е. особенности архитектуры процессора), размер оперативной памяти, загрузка системы и т. д. Такие настройки лучше определять экспериментальным путем, хотя в большинстве случаев подойдут и стандартные (обычно на сервере запускают 8 демонов nfsd, а на клиентах - 4 демона biod).

Очень важной особенностью NFS v2 является то, что на стороне сервера операции записи не кэшируются (см. Рисунок 2). Это было сделано в целях обеспечения высокой надежности сервиса NFS и позволяет гарантировать целостность данных после перезагрузки сервера в случае его отказа. Отсутствие кэширования информации при записи представляет собой самую большую проблему NFS v2. На операциях записи NFS значительно уступает конкурирующим технологиям, хотя на операциях чтения мало в чем им проигрывает. Единственный метод борьбы с невысокой производительностью записи состоит в использовании дисковых подсистем с независимым от электропитания встроенным кэшем, как в довольно дорогих массивах RAID.

При работе в распределенных и глобальных сетях NFS v2 свойственен еще один недостаток вследствие выбора UDP в качестве транспортного протокола для сервиса. Как известно, UDP не гарантирует доставку пакетов, кроме того, порядок приема пакетов может не соответствовать порядку их отправки.

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

Ситуация задержки обработки запросов RPC ввиду, допустим, большой загрузки сервера или проблем в сети также достаточно неприятна. При превышении заданного лимита времени клиент будет считать, что пакет потерян и попытается повторить запрос. Для многих операций NFS это не страшно, так как даже операцию записи сервер может произвести повторно. Но что делать с такими операциями, как "удалить каталог" или "переименовать файл"? К счастью, большинство реализаций NFS поддерживает кэширование дублированных запросов на стороне сервера. Если сервер получил повторный запрос на какую-либо операцию в течение краткого промежутка времени, то такой запрос игнорируется.

Система RPC не отслеживает состояние соединения, что создает проблемы при одновременном обращении нескольких клиентов к одному и тому же файлу. Здесь возникают две сложности:

• как осуществить блокировку файла, в частности при записи в него;
• как гарантировать целостность блокировок в случае краха и перезагрузки сервера или клиента NFS?

Для этого в NFS применяются два специальных демона: rpc.lockd отвечает за блокировку файлов, а rpc.statd - за мониторинг состояния блокировок (см. Рисунок 3). Эти демоны запускаются как на стороне клиента, так и на стороне сервера. За демонами rpc.lockd и rpc.statd закреплены два специальных каталога (sm и sm.bak), где хранится информация по блокировкам.

Своеобразный и достаточно удобный дополнительный сервис automounter позволяет автоматически монтировать файловые системы при обращении к ним пользовательских процессов. В дальнейшем automounter периодически (по умолчанию раз в пять минут) пытается размонтировать систему. Если она занята (допустим, открыт файл), то сервис продолжает работать в обычном режиме. Если же к файловой системе больше нет обращений, то она автоматически размонтируется. Функция automounter реализует несколько программ, особой популярностью среди них пользуются amd и autofs.

ВОЗМОЖНОСТИ NFS V3

Третья версия NFS полностью обратно совместима со второй версией, т. е. сервер NFS v3 "понимает" клиентов NFS v2 и NFS v3. Аналогично, клиент NFS v3 может обращаться к серверу NFS v2.

Важным нововведением NFS v3 является поддержка транспортного протокола TCP. UDP прекрасно подходит для локальных сетей, но не годится для медленных и не всегда надежных глобальных линий связи. В NFS v3 весь клиентский трафик мультиплексируется в одно соединение TCP.

В NFS v3 размер буфера кэша увеличен до 64 Кбайт, что благотворно повлияло на производительность, особенно в свете активного использования высокоскоростных сетевых технологий Fast Ethernet, Gigabit Ethernet и ATM. Кроме того, NFS v3 позволяет хранить кэшируемую на клиенте информацию не только в оперативной памяти, но и на локальном диске клиента (справедливости ради, стоит отметить, что некоторые реализации NFS v2 тоже предусматривают такую возможность). Такая технология известна как CacheFS.

Но, пожалуй, еще более важным новшеством NFS v3 можно считать радикальное увеличение производительности на операциях записи. Теперь кэширование записываемой информации производится также на стороне сервера, при этом регистрация и подтверждение факта записи данных на диск осуществляются с помощью специального запроса commit (см. Рисунок 4). Эту технологию называют безопасной асинхронной записью. После того как данные пересланы в кэш сервера, клиент посылает ему запрос commit, инициирующий операцию записи на диск сервера. В свою очередь по окончании записи информации на диск сервер отправляет клиенту подтверждение ее успешного завершения.

Новым в NFS v3 является поддержка 64-разрядных файловых систем и улучшенная поддержка списков контроля доступа ACL.

Что касается перспектив, то сейчас Sun продвигает технологию WebNFS, использование которой позволяет получить доступ к файловым системам из любого браузера Web или через приложения, написанные на Java. При этом никакого клиентского ПО устанавливать не требуется. WebNFS (по утверждению Sun) дает выигрыш в производительности по сравнению с ftp или HTTP в три-пять раз.

ЗАКЛЮЧЕНИЕ

Зная принципы работы протоколов NFS, администратор может произвести оптимальную настройку сервиса. Сетевая файловая система NFS идеально подходит для сетей UNIX, так как поставляется практически со всеми версиями этой ОС. Более того, поддержка NFS реализована на уровне ядра UNIX. Поскольку Linux начинает постепенно набирать вес на уровне настольных компьютеров, то NFS имеет шансы завоевать признание и здесь. К сожалению, использование NFS на клиентских компьютерах с Windows создает определенные проблемы, связанные с необходимостью установки специализированного и довольно дорогого клиентского ПО. В таких сетях применение сервиса SMB, в частности ПО Samba, выглядит более предпочтительным. Впрочем, к продуктам SMB для UNIX мы вернемся в одном из ближайших номеров LAN.