Протокол сетевой файловой службы (Network File Server, NFS) - это открытый стандарт на предоставление пользователю удаленного доступа к файловым системам. Созданные на его основе централизованные файловые системы облегчают ежедневное выполнение таких задач, как резервное копирование или проверка на вирусы, а объединенные дисковые разделы проще обслуживать, чем множество небольших и распределенных.
Кроме того, что система NFS предоставляет возможность централизованного хранения, oна оказалась весьма полезной и для других приложений, включая работу с бездисковыми и тонкими клиентами, разбиение сети на кластеры, а также для совместно работающего межплатформенного ПО.
Лучшее понимание как самого протокола, так и деталей его реализации позволит легче справиться с практическими задачами. Данная статья посвящена NFS и состоит из двух логических частей: вначале описывается сам протокол и цели, поставленные при его разработке, а затем реализации NFS в Solaris и UNIX.
С ЧЕГО ВСЕ НАЧИНАЛОСЬ...
Протокол NFS разработан компанией Sun Microsystems и в 1989 г. появился в Internet в виде документа RFC 1094 под следующим названием: «Спецификация протокола сетевой файловой системы» (Network File System Protocol Specification, NFS). Интересно отметить, что и стратегия компании Novell в то время была направлена на дальнейшее усовершенствование файловых служб. До недавнего времени, пока движение за открытые коды еще не набрало силу, Sun не стремилась раскрывать секреты своих сетевых решений, однако даже тогда в компании понимали всю важность обеспечения взаимодействия с другими системами.
В документе RFC 1094 содержались две первоначальные спецификации. К моменту его публикации Sun разрабатывала уже следующую, третью версию спецификации, которая изложена в RFC 1813 «Спецификация протокола NFS, версия 3» (NFS Version 3 Protocol Specification). Версия 4 данного протокола определена в RFC 3010 «Спецификация протокола NFS, версия 4» (NFS Version 4 Protocol).
NFS широко используется на всех типах узлов UNIX, в сетях Microsoft и Novell, а также в таких решениях компании IBM, как AS400 и OS/390. Будучи неизвестной за пределами сетевого «королевства», NFS, пожалуй, самая распространенная платформенно-независимая сетевая файловая система.
ПРАРОДИТЕЛЕМ БЫЛ UNIX
Хотя NFS - платформенно-независимая система, ее прародителем является UNIX. Другими словами, иерархичность архитектуры и методы доступа к файлам, включая структуру файловой системы, способы идентификации пользователей и групп и приемы работы с файлами - все это очень напоминает файловую систему UNIX. Например, файловая система NFS, будучи по структуре идентичной файловой системе UNIX, монтируется непосредственно в ней. При работе с NFS на других операционных системах идентификационные параметры пользователей и права доступа к файлам подвергаются преобразованию (mapping).
NFS
Система NFS предназначена для применения в клиент-серверной архитектуре. Клиент получает доступ к файловой системе, экспортируемой сервером NFS, посредством точки монтирования на клиенте. Такой доступ обычно прозрачен для клиентского приложения.
В отличие от многих клиент-серверных систем, NFS для обмена информацией использует вызовы удаленных процедур (Remote Procedure Calls, RPC). Обычно клиент устанавливает соединение с заранее известным портом и затем, в соответствии с особенностями протокола, посылает запрос на выполнение определенного действия. В случае вызова удаленных процедур клиент создает вызов процедуры и затем отправляет его на исполнение серверу. Подробное описание NFS будет представлено ниже.
В качестве примера предположим, что некий клиент смонтировал каталог usr2 в локальной корневой файловой системе:
/root/usr2/ -> remote:/root/usr/
Если клиентскому приложению необходимы ресурсы этого каталога, оно просто посылает запрос операционной системе на него и на имя файла, а та предоставляет доступ через клиента NFS. Для примера рассмотрим простую команду UNIX cd, которая «ничего не знает» о сетевых протоколах. Команда
Cd /root/usr2/
разместит рабочий каталог на удаленной файловой системе, «даже не догадываясь» (пользователю тоже нет в этом необходимости), что файловая система является удаленной.
Получив запрос, сервер NFS проверит наличие у данного пользователя права на выполнение запрашиваемого действия и в случае положительного ответа осуществит его.
ПОЗНАКОМИМСЯ ПОБЛИЖЕ
С точки зрения клиента, процесс локального монтирования удаленной файловой системы средствами NFS состоит из нескольких шагов. Как уже упоминалось, клиент NFS подаст вызов удаленной процедуры для выполнения ее на сервере. Заметим, что в UNIX клиент представляет собой одну программу (команда mount), в то время как сервер на самом деле реализован в виде нескольких программ со следующим минимальным набором: служба преобразования портов (port mapper), демон монтирования (mount daemon) и сервер NFS.
Вначале клиентская команда mount взаимодействует со службой преобразования портов сервера, ожидающей запросы через порт 111. Большинство реализаций клиентской команды mount поддерживает несколько версий NFS, что повышает вероятность нахождения общей для клиента и сервера версии протокола. Поиск ведется, начиная с самой старшей версии, поэтому, когда общая будет найдена, она автоматически станет и самой новой версией из поддерживаемых клиентом и сервером.
(Излагаемый материал ориентирован на третью версию NFS, поскольку она наиболее распространена на данный момент. Четвертая версия большинством реализаций пока не поддерживается.)
Служба преобразования портов сервера откликается на запросы в соответствии с поддерживаемым протоколом и портом, на котором работает демон монтирования. Клиентская программа mount вначале устанавливает соединение с демоном монтирования сервера, а затем передает ему с помощью RPC команду mount. Если данная процедура выполнена успешно, то клиентское приложение соединяется с сервером NFS (порт 2049) и, используя одну из 20 удаленных процедур, которые определены в RFC 1813 и приводятся нами в Таблице 1, получает доступ к удаленной файловой системе.
Смысл большинства команд интуитивно понятен и не вызывает каких-либо затруднений у системных администраторов. Приведенный ниже листинг, полученный с помощью tcdump, иллюстрирует команду чтения, создаваемую командой UNIX cat для прочтения файла с именем test-file:
10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013650 eth0 192.168.1.254.3492875163: reply ok 108 read (DF) 10:30:16.013650 eth0 192.168.1.254.3492875163: reply ok 108 read (DF)
NFS традиционно реализуется на основе UDP. Однако некоторые версии NFS поддерживают TCP (в спецификации протокола определена поддержка TCP). Главное преимущество TCP - более эффективный механизм повторной передачи в ненадежно работающих сетях. (В случае UDP, если произошла ошибка, то полное сообщение RPC, состоящее из нескольких пакетов UDP, пересылается заново. При наличии TCP заново пересылается лишь испорченный фрагмент.)
ДОСТУП В NFS
В реализациях NFS обычно поддерживаются четыре способа предоставления прав доступа: посредством атрибутов пользователя/файла, на уровне разделяемых ресурсов, на уровне главного узла, а также в виде комбинации других методов доступа.
Первый способ основывается на встроенной в UNIX системе прав доступа к файлам для индивидуального пользователя или группы. Для упрощения обслуживания идентификация пользователей и групп должна быть единообразной для всех клиентов и серверов NFS. Защиту следует тщательно продумать: в NFS можно по неосторожности предоставить такой доступ к файлам, который не планировался при их создании.
Доступ на уровне разделяемых ресурсов позволяет ограничивать права, разрешив только определенные действия, независимо от принадлежности файла или привилегий UNIX. Например, работу с файловой системой NFS можно ограничить только чтением. Большинство реализаций NFS позволяет дополнительно ограничить доступ на уровне разделяемых ресурсов конкретными пользователями и/или группами. Например, группе «Отдел кадров» разрешается просмотр информации и не более того.
Доступ на уровне главного узла позволяет монтировать файловую систему только на конкретных узлах, что, вообще говоря, хорошая идея, поскольку файловые системы могут легко создаваться на любых узлах, поддерживающих NFS.
Комбинированный доступ просто объединяет вышеописанные виды (например, доступ на уровне разделяемых ресурсов с доступом, предоставляемым конкретному пользователю) или разрешает пользователям работу с NFS только с определенного узла.
NFS В СТИЛЕ «ПИНГВИН»
Относящийся к Linux излагаемый материал основывается на системе Red Hat 6.2 с ядром версии 2.4.9, которая поставляется с пакетом nfs-utils версии 0.1.6. Существуют и более новые версии: на момент написания этой статьи самое последнее обновление пакета nfs-utils имело номер 0.3.1. Его можно загрузить по адресу: .
Пакет nfs-utils содержит следующие исполняемые файлы: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount и statd.
К сожалению, иногда поддержка NFS вызывает путаницу у администраторов Linux, поскольку наличие той или иной функциональной возможности напрямую зависит от номеров версий как ядра, так и пакета nfs-utils. К счастью, в настоящее время положение дел в этой области улучшается: последние дистрибутивные комплекты включают самые новые версии и того, и другого. Для предыдущих выпусков в разделе 2.4 документа NFS-HOWTO приводится полный список функциональных возможностей системы, имеющихся в наличии для каждой комбинации ядра и пакета nfs-utils. Разработчики поддерживают обратную совместимость пакета с более ранними версиями, уделяя много внимания обеспечению безопасности и устранению программных ошибок.
Поддержку NFS следует инициировать во время компиляции ядра. Если необходимо, в ядро нужно добавить и возможность работы с NFS версии 3.
Для дистрибутивов, поддерживающих linuxconf, легко сконфигурировать службы NFS как для клиентов, так и для серверов. Однако быстрый способ установки NFS с помощью linuxconf не дает информации о том, какие файлы были созданы или отредактированы, что очень важно знать администратору для понимания ситуации в случае сбоя системы. Архитектура NFS в Linux имеет слабую связь с версией BSD, поэтому необходимые файлы и программы поддержки легко найти администраторам, работающим с BSD, Sun OS 2.5 или более ранними версиями NFS.
Файл /etc/exports, как и в более ранних версиях BSD, определяет файловые системы, к которым разрешен доступ клиентам NFS. Кроме того, он содержит ряд дополнительных возможностей, относящихся к вопросам управления и безопасности, предоставляя администратору средство для тонкой настройки. Это текстовый файл, состоящий из записей, пустых или закомментированных строк (комментарии начинаются с символа #).
Предположим, что мы хотим предоставить клиентам доступ только для чтения к каталогу /home на узле Lefty. Этому в /etc/exports будет соответствовать следующая запись:
/home (ro)
Здесь нам необходимо сообщить системе, какие каталоги мы собираемся сделать доступными с помощью демона монтирования rpc.mountd:
# exportfs -r exportfs: В /home (ro) не указано имя узла, введите *(ro) чтобы избежать предупреждения #
При запуске команда exportfs выводит предупреждение о том, что /etc/ exports не ограничивает доступ к отдельному узлу, и создает соответствующую запись в /var/lib/nfs/etab из /etc/exports, сообщающую, какие ресурсы можно просмотреть с помощью cat:
# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_ squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)
Другие параметры, перечисленные в виде списка в etab, включают значения по умолчанию, используемые NFS. Детали будут описаны ниже. Чтобы предоставить доступ к каталогу /home, необходимо запустить соответствующие службы NFS:
# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad
В любой момент после запуска демона монтирования (rpc.mountd) cправиться об отдельных файлах, доступных для вывода, можно, просмотрев содержимое файла /proc/fs/nfs/exports:
# cat /proc/fs/nfs/exports # Version 1.0 # Path Client(Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #
То же самое можно просмотреть и с помощью команды showmount с параметром -e:
# showmount -e Export list for lefty: /home (everyone) #
Забегая несколько вперед, скажу, что команду showmount можно также использовать для определения всех смонтированных файловых систем, или, другими словами, чтобы выяснить, какие узлы являются клиентами NFS для системы, на которой запущена команда showmount. Команда showmount -a выведет все клиентские точки монтирования:
# showmount -a All mount points on lefty: 192.168.1.252:/home #
Как указывалось выше, большинство реализаций NFS поддерживает различные версии этого протокола. Реализация в Linux позволяет ограничивать список запускаемых версий NFS путем указания ключа -N для демона монтирования. Например, для запуска NFS третьей версии, и только ее, введите следующую команду:
# rpc.mountd -N 1 -N 2
Привередливым пользователям может показаться неудобным, что в Linux демон NFS (rpc.nfsd) находится в режиме ожидания пакетов версий 1 и 2, хотя это и достигает желаемого эффекта отказа от поддержки соответствующего протокола. Будем надеяться, что разработчики следующих версий внесут необходимые исправления и сумеют добиться большей согласованности компонентов пакета в отношении различных версий протокола.
«ЗАПЛЫВ С ПИНГВИНАМИ»
Доступ к сконфигурированной выше Lefty, экспортируемой файловой системе NFS на базе Linux, зависит от клиентской операционной системы. Стиль установок для большинства операционных систем семейства UNIX совпадает со стилем либо исходных систем Sun OS и BSD, либо более новой Solaris. Так как данная статья посвящена обеим системам, Linux и Solaris, давайте рассмотрим клиентскую конфигурацию Solaris 2.6 с точки зрения установления соединения с Linux-версией NFS, описанной нами выше.
Благодаря свойствам, унаследованным Solaris 2.6, ее легко сконфигурировать для работы в качестве клиента NFS. Для этого требуется лишь одна команда:
# mount -F nfs 192.168.1.254:/home /tmp/tmp2
Предположим, что предыдущая команда mount выполнена успешно, тогда команда mount без параметров выведет следующее:
# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Mon Sep 3 23:19:25 2001
Давайте проанализируем вывод tcpdump, полученный на узле Lefty, после того, как пользователь ввел команду ls /tmp/tmp2 на узле Sunny:
# tcpdump host lefty and host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:43.490678 lefty.mcwrite.n.nfs > sunny.2191983953: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: 132 access fh Unknown/10001 (DF) 06:07:43.491463 lefty.mcwrite.n.nfs > sunny.2191983954: reply ok 120 access c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus fh 0,1/16777984 1048 bytes @ 0x000000000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: reply ok 1000 readdirplus (DF)
Мы видим, что узел Sunny запрашивает для ls описатель файла (fh), на что узел Lefty в ответ посылает OK и возвращает структуру каталога. Затем Sunny проверяет разрешение на право доступа к содержимому каталога (132 access fh) и получает ответ с разрешением от Lefty. После этого узел Sunny, используя процедуру readdirplus, считывает полное содержимое каталога. Вызовы удаленных процедур описаны в документе RFC 1813 и приведены нами в начале данной статьи.
Хотя последовательность команд для доступа к удаленным файловым системам очень проста, ряд обстоятельств может привести к некорректному монтированию системы. Перед монтированием каталога точка монтирования должна уже существовать, в противном случае ее необходимо создать с помощью команды mkdir. Обычно единственной причиной ошибок на клиентской стороне является отсутствие локального каталога для монтирования. Большинство же проблем, связанных с NFS, обязано своим происхождением несоответствию между клиентом и сервером или некорректной конфигурации сервера.
Проще всего устранить проблемы на сервере с узла, на котором работает сервер. Однако, когда администрированием сервера занимается вместо вас кто-то другой, это не всегда возможно. Быстрый способ убедиться, что соответствующие службы сервера правильно сконфигурированы, - использовать команду rpcinfo с параметром -p. С узла Solaris Sunny можно определить, какие процессы RPC зарегистрированы на узле Linux:
# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1 tcp 694 status 100005 3 udp 1024 mountd /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #
Заметим, что здесь же приводится информация о версиях, что достаточно полезно, когда для работы системы требуется поддержка различных протоколов NFS. Если какая-либо служба не запущена на сервере, то такая ситуация должна быть исправлена. В случае неудачного монтирования приводимая ниже команда rpcinfo -p позволит выяснить, что служба mountd на сервере не работает:
# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #
Команда rpcinfo очень полезна для выяснения, активен ли тот или иной удаленный процесс. Параметр -p - самый важный из ключей. Для ознакомления со всеми возможностями rpcinfo обратитесь к справочной странице man.
Другое полезное средство - команда nfsstat. С ее помощью можно узнать, обращаются ли в действительности клиенты к экспортируемой файловой системе, а также вывести статистическую информацию в соответствии с версией протокола.
Наконец, еще одним достаточно полезным инструментом определения причин сбоев системы является tcpdump:
# tcpdump host lefty and host sunny -s512 tcpdump: listening on eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2191984022 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Unknown/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023: reply ok 120 create ERROR: Permission denied (DF)
Вышеприведенный листинг, полученный после выполнения инструкции touch test.c, отражает следующую последовательность действий: сначала команда touch пытается получить доступ к файлу по имени test.c, затем она ищет каталог с этим же именем, а после неудачных попыток пытается создать файл test.c, что также не приводит к успеху.
Если файловая система смонтирована, то большинство типичных ошибок связано с обычными правами доступа UNIX. Использование uid или NIS+ в Sun помогает избежать глобального установления прав доступа на все файловые системы. Некоторые администраторы практикуют «открытые» каталоги, когда права доступа на их чтение даются «всему миру». Однако этого следует избегать по причинам безопасности. Даже отбросив в сторону проблемы защиты, все равно придется признать такой подход порочной практикой, поскольку пользователи редко создают данные с намерением сделать их доступными для чтения всем подряд.
Обращения привилегированного пользователя (root) к смонтированным файловым системам NFS трактуются по-особому. Чтобы избежать предоставления привилегированному пользователю неограниченного доступа, запросы от него трактуются так, как будто бы они поступают от пользователя nobody («никто»). Этот действенный механизм ограничивает доступ привилегированного пользователя глобально доступными для чтения и разрешенными для записи файлами.
СЕРВЕР NFS, ВЕРСИЯ SOLARIS
Конфигурирование Solaris для работы в качестве сервера NFS так же просто, как и в случае с Linux. Однако команды и местоположение файлов несколько отличаются. При начальной загрузке Solaris по достижении уровня загрузки 3 (run level 3) автоматически запускаются службы NFS и экспортируются все файловые системы. Для запуска этих процессов вручную введите команду:
#/usr/lib/nfs/mountd
Для запуска демона монтирования и сервера NFS введите:
#/usr/lib/nfs/nfsd
Начиная с версии 2.6 в Solaris для указания экспортируемых файловых систем больше не используется файл экспорта. Теперь файлы экспортируются с помощью команды share. Предположим, мы хотим позволить удаленным узлам смонтировать /export/home. Введем для этого следующую команду:
Share -F nfs /export/home
Мероприятия по обеспечению безопасности
БЕЗОПАСНОСТЬ В LINUX
Некоторые системные службы NFS на основе Linux имеют дополнительный механизм ограничения доступа посредством управляющих списков или таблиц. На внутреннем уровне этот механизм реализован с помощью библиотеки tcp_wrapper, которая для формирования списков контроля доступа использует два файла: /etc/hosts.allow и /etc/hosts/deny. Исчерпывающий обзор правил работы с tcp_wrapper выходит за рамки данной статьи, основной же принцип состоит в следующем: сопоставление вначале производится с etc/hosts.allow, а затем с /etc/hosts. deny. Если правило не найдено, то запрашиваемая системная служба не представляется. Чтобы обойти последнее требование и обеспечить очень высокий уровень безопасности, в конец /etc/hosts.deny можно добавить следующую запись:
ALL: All
После этого можно использовать /etc/ hosts.allow, чтобы установить тот или иной режим работы. Например, файл /etc/hosts. allow, который я использовал при написании данной статьи, содержал следующие строки:
Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0 statd:192.168.1.0/255.255.255.0
При этом разрешается определенный вид доступа к узлам до того, как будет предоставлен доступ на уровне приложений. В Linux доступом на уровне приложений управляет файл /etc/exports. Он состоит из записей в следующем формате:
Экспортируемый каталог {пробел} узел|сеть(опции)
«Экспортируемый каталог» - это каталог, обработка запроса к которому разрешена демону nfsd. «Узел|сеть» - это узел или сеть, имеющие доступ к экспортируемой файловой системе, а «опции» определяют те ограничения, какие демон nfsd налагает на использование данного разделяемого ресурса, - доступ только для чтения или преобразование идентификатора пользователя (user id mapping).
В следующем примере всему домену mcwrite.net предоставлен доступ в режиме только для чтения к /home/mcwrite.net:
/home/mcwrite.net *.mcwrite.net(ro)
Другие примеры можно найти на справочной странице exports man.
БЕЗОПАСНОСТЬ NFS В SOLARIS
В Solaris возможности по предоставлению доступа к NFS аналогичны Linux, однако в этом случае ограничения задаются с помощью определенных параметров в команде share с ключом -o. Следующий пример показывает, как разрешить монтирование в режиме только для чтения /export/mcwrite.net на любом узле домена mcwrite.net:
#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net
Справочная страница man для share_nfs подробно описывает предоставление доступа с помощью управляющих списков в Solaris.
Ресурсы Internet
В NFS и RPC не обошлось без «дыр». Вообще говоря, NFS не следует использовать при работе в Internet. Нельзя делать «дыры» в брандмауэрах, предоставляя какой бы то ни было доступ посредством NFS. Необходимо тщательно следить за всеми появляющимися заплатами для RPC и NFS, в чем могут помочь многочисленные источники информации по вопросам безопасности. Два наиболее популярных источника - Bugtraq и CERT:
Первый можно регулярно просматривать в поисках необходимой информации или воспользоваться подпиской на периодическую рассылку новостей. Второй предоставляет, может быть, не столь оперативную, по сравнению с другими, информацию, зато в достаточно полном объеме и без оттенка сенсационности, свойственной некоторым сайтам, посвященным информационной безопасности.
NFS: удобная и перспективная сетевая файловая система
Сетевая файловая система – это сетевая абстракция поверх обычной файловой системы, позволяющая удаленному клиенту обращаться к ней через сеть так же, как и при доступе к локальным файловым системам. Хотя NFS не является первой сетевой системой, она сегодня развилась до уровня наиболее функциональной и востребованной сетевой файловой системы в UNIX®. NFS позволяет организовать совместный доступ к общей файловой системе для множества пользователей и обеспечить централизацию данных для минимизации дискового пространства, необходимого для их хранения.
Эта статья начинается с краткого обзора истории NFS, а затем переходит к исследованию архитектуры NFS и путей её дальнейшего развития.
Краткая история NFS
Первая сетевая файловая система называлась FAL (File Access Listener - обработчик доступа к файлам) и была разработана в 1976 году компанией DEC (Digital Equipment Corporation). Она являлась реализацией протокола DAP (Data Access Protocol – протокол доступа к данным) и входила в пакет протоколов DECnet. Как и в случае с TCP/IP, компания DEC опубликовала спецификации своих сетевых протоколов, включая протокол DAP.
NFS была первой современной сетевой файловой системой, построенной поверх протокола IP. Её прообразом можно считать экспериментальную файловую систему, разработанную в Sun Microsystems в начале 80-х годов. Учитывая популярность этого решения, протокол NFS был представлен в качестве спецификации RFC и впоследствии развился в NFSv2. NFS быстро утвердилась в качестве стандарта благодаря способности взаимодействовать с другими клиентами и серверами.
Впоследствии стандарт был обновлен до версии NFSv3, определенной в RFC 1813. Эта версия протокола была более масштабируема, чем предыдущие, и поддерживала файлы большего размера (более 2 ГБ), асинхронную запись и TCP в качестве транспортного протокола. NFSv3 задала направление развития файловых систем для глобальных (WAN) сетей. В 2000 году в рамках спецификации RFC 3010 (переработанной в версии RFC 3530) NFS была перенесена в корпоративную среду. Sun представила более защищенную NFSv4 c поддержкой сохранения состояния (stateful) (предыдущие версии NFS не поддерживали сохранение состояния, т.е. относились к категории stateless). На текущий момент последней версией NFS является версия 4.1, определенная в RFC 5661, в которой в протокол посредством расширения pNFS была добавлена поддержка параллельного доступа для распределенных серверов.
История развития NFS, включая конкретные RFC, описывающие её версии, показана на рисунке 1.
Как ни удивительно, NFS находится в стадии разработки уже почти 30 лет. Она является исключительно стабильной и переносимой сетевой файловой системой с выдающимися характеристиками масштабируемости, производительности и качества обслуживания. В условиях увеличения скорости и снижения задержек при обмене данными внутри сети NFS продолжает оставаться популярным способом реализации файловой системы внутри сети. Даже в случае локальных сетей виртуализация побуждает хранить данные в сети, чтобы обеспечить виртуальным машинам дополнительную мобильность. NFS также поддерживает новейшие модели организации вычислительных сред, нацеленные на оптимизацию виртуальных инфраструктур.
Архитектура NFS
NFS использует стандартную архитектурную модель "клиент-сервер" (как показано на рисунке 2). Сервер отвечает за реализацию файловой системы совместного доступа и хранилища, к которому подключаются клиенты. Клиент реализует пользовательский интерфейс к общей файловой системе, смонтированной внутри локального файлового пространства клиента.
Рисунок 2. Реализация модели "клиент-сервер" в архитектуре NFS
В ОС Linux® виртуальный коммутатор файловой системы (virtual file system switch - VFS) предоставляет средства для одновременной поддержки на одном хосте нескольких файловых систем (например, файловой системы ISO 9660 на CD-ROM и файловой системы ext3fs на локальном жестком диске). Виртуальный коммутатор определяет, к какому накопителю выполняется запрос, и, следовательно, какая файловая система должна использоваться для обработки запроса. Поэтому NFS обладает такой же совместимостью, как и другие файловые системы, применяющиеся в Linux. Единственное отличие NFS состоит в том, что запросы ввода/вывода вместо локальной обработки на хосте могут быть направлены для выполнения в сеть.
VFS определяет, что полученный запрос относится к NFS, и передает его в обработчик NFS, находящийся в ядре. Обработчик NFS обрабатывает запрос ввода/вывода и транслирует его в NFS-процедуру (OPEN , ACCESS , CREATE , READ , CLOSE , REMOVE и т.д.). Эти процедуры, описанные в отдельной спецификации RFC, определяют поведение протокола NFS. Необходимая процедура выбирается в зависимости от запроса и выполняется с помощью технологии RPC (вызов удаленной процедуры). Как можно понять по названию, RPC позволяет осуществлять вызовы процедур между различными системами. RPC-служба соединяет NFS-запрос с его аргументами и отправляет результат на соответствующий удаленный хост, а затем следит за получением и обработкой ответа, чтобы вернуть его инициатору запроса.
Также RPC включает в себя важный уровень XDR (external data representation – независимое представление данных), гарантирующий, что все пользователи NFS для одинаковых типов данных используют один и тот же формат. Когда некая платформа отправляет запрос, используемый ею тип данных может отличаться от типа данных, используемого на хосте, обрабатывающего этот запрос. Технология XDR берет на себя работу по преобразованию типов в стандартное представление (XDR), так что платформы, использующие разные архитектуры, могут взаимодействовать и совместно использовать файловые системы. В XDR определен битовый формат для таких типов, как float , и порядок байтов для таких типов, как массивы постоянной и переменной длины. Хотя XDR в основном известна благодаря применению в NFS, это спецификация может быть полезна во всех случаях, когда приходится работать в одной среде с различными архитектурами.
После того как XDR переведет данные в стандартное представление, запрос передается по сети с помощью определенного транспортного протокола. В ранних реализациях NFS использовался протокол UDP, но сегодня для обеспечения большей надежности применяется протокол TCP.
На стороне NFS-сервера применяется схожий алгоритм. Запрос поднимается по сетевому стеку через уровень RPC/XDR (для преобразования типов данных в соответствии с архитектурой сервера) и попадает в NFS-сервер, который отвечает за обработку запроса. Там запрос передается NFS-демону для определения целевой файловой системы, которой он адресован, а затем снова поступает в VFS для обращения к этой файловой системе на локальном диске. Полностью схема этого процесса приведена на рисунке 3. При этом локальная файловая система сервера – это стандартная для Linux файловая система, например, ext4fs. По сути NFS – это не файловая система в традиционном понимании этого термина, а протокол удаленного доступа к файловым системам.
Для сетей с большим временем ожидания в NFSv4 предлагается специальная составная процедура (compound procedure ). Эта процедура позволяет поместить несколько RPC-вызовов внутрь одного запроса, чтобы минимизировать затраты на передачу запросов по сети. Также в этой процедуре реализован механизм callback-функций для получения ответов.
Протокол NFS
Когда клиент начинает работать с NFS, первым действием выполняется операция mount , которая представляет собой монтирование удаленной файловой системы в пространство локальной файловой системы. Этот процесс начинается с вызова процедуры mount (одной из системных функций Linux), который через VFS перенаправляется в NFS-компонент. Затем с помощью RPC-вызова функции get_port на удаленном сервере определяется номер порта, который будет использоваться для монтирования, и клиент через RPC отправляет запрос на монтирование. Этот запрос на стороне сервера обрабатывается специальным демоном rpc.mountd , отвечающим за протокол монтирования (mount protocol ). Демон проверяет, что запрошенная клиентом файловая система имеется в списке систем, доступных на данном сервере. Если запрошенная система существует и клиент имеет к ней доступ, то в ответе RPC-процедуры mount указывается дескриптор файловой системы. Клиент сохраняет у себя информацию о локальной и удаленной точках монтирования и получает возможность осуществлять запросы ввода/вывода. Протокол монтирования не является безупречным с точки зрения безопасности, поэтому в NFSv4 вместо него используются внутренние RPC-вызовы, которые также могут управлять точками монтирования.
Для считывания файла его необходимо сначала открыть. В RPC нет процедуры OPEN , вместо этого клиент просто проверяет, что указанные файл и каталог существуют в смонтированной файловой системе. Клиент начинает с выполнения RPC-запроса GETATTR к каталогу, в ответ на который возвращаются атрибуты каталога или индикатор, что каталог не существует. Далее, чтобы проверить наличие файла, клиент выполняет RPC-запрос LOOKUP . Если файл существует, для него выполняется RPC-запрос GETATTR , чтобы узнать атрибуты файла. Используя информацию, полученную в результате успешных вызовов LOOKUP и GETATTR , клиент создает дескриптор файла, который предоставляется пользователю для выполнения будущих запросов.
После того как файл идентифицирован в удаленной файловой системе, клиент может выполнять RPC-запросы типа READ . Этот запрос состоит из дескриптора файла, состояния, смещения и количества байт, которое следует считать. Клиент использует состояние (state ), чтобы определить может ли операция быть выполнена в данный момент, т.е. не заблокирован ли файл. Смещение (offset ) указывает, с какой позиции следует начать чтение, а счетчик байт (count ) определяет, сколько байт необходимо считать. В результате RPC-вызова READ сервер не всегда возвращает столько байт, сколько было запрошено, но вместе с возвращаемыми данными всегда передает, сколько байт было отправлено клиенту.
Инновации в NFS
Наибольший интерес представляют две последние версии NFS – 4 и 4.1, на примере которых можно изучить наиболее важные аспекты эволюции технологии NFS.
До появления NFSv4 для выполнения таких задач по управлению файлами, как монтирование, блокировка и т.д. существовали специальные дополнительные протоколы. В NFSv4 процесс управления файлами был упрощен до одного протокола; кроме того, начиная с этой версии UDP больше не используется в качестве транспортного протокола. NFSv4 включает поддержку UNIX и Windows®-семантики доступа к файлам, что позволяет NFS "естественным" способом интегрироваться в другие операционные системы.
В NFSv4.1 для большей масштабируемости и производительности была введена концепция параллельной NFS (parallel NFS - pNFS). Чтобы обеспечить больший уровень масштабируемости, в NFSv4.1 реализована архитектура, в которой данные и метаданные (разметка ) распределяются по устройствам аналогично тому, как это делается в кластерных файловых системах. Как показано на , pNFS разделяет экосистему на три составляющие: клиент, сервер и хранилище. При этом появляются два канала: один для передачи данных, а другой для передачи команд управления. pNFS отделяет данные от описывающих их метаданных, обеспечивая двухканальную архитектуру. Когда клиент хочет получить доступ к файлу, сервер отправляет ему метаданные с "разметкой". В метаданных содержится информация о размещении файла на запоминающих устройствах. Получив эту информацию, клиент может обращаться напрямую к хранилищу без необходимости взаимодействовать с сервером, что способствует повышению масштабируемости и производительности. Когда клиент заканчивает работу с файлом, он подтверждает изменения, внесенные в файл и его "разметку". При необходимости сервер может запросить у клиента метаданные с разметкой.
С появлением pNFS в протокол NFS было добавлено несколько новых операций для поддержки такого механизма. Метод LayoutGet используется для получения метаданных с сервера, метод LayoutReturn "освобождает" метаданные, "захваченные" клиентом, а метод LayoutCommit загружает "разметку", полученную от клиента, в хранилище, так что она становится доступной другим пользователям. Сервер может отозвать метаданные у клиента с помощью метода LayoutRecall . Метаданные с "разметкой" распределяются между несколькими запоминающими устройствами, чтобы обеспечить параллельный доступ и высокую производительность.
Данные и метаданные хранятся на запоминающих устройствах. Клиенты могут выполнять прямые запросы ввода/вывода на основе полученной разметки, а сервер NFSv4.1 хранит метаданные и управляет ими. Сама по себе эта функциональность и не нова, но в pNFS была добавлена поддержка различных методов доступа к запоминающим устройствам. Сегодня pNFS поддерживает использование блочных протоколов (Fibre Channel), объектных протоколов и собственно NFS (даже не в pNFS-форме).
Развитие NFS продолжается, и в сентябре 2010 года были опубликованы требования к NFSv4.2. Некоторые из нововведений связаны с наблюдающейся миграцией технологий хранения данных в сторону виртуализации. Например, в виртуальных средах с гипервизором весьма вероятно возникновение дублирования данных (несколько ОС выполняют чтение/запись и кэширование одних и тех же данных). В связи с этим желательно, чтобы система хранения данных в целом понимала, где происходит дублирование. Такой подход поможет сэкономить пространство в кэше клиента и общую емкость системы хранения. В NFSv4.2 для решения этой проблемы предлагается использовать "карту блоков, находящихся в совместном доступе" (block map of shared blocks). Поскольку современные системы хранения все чаще оснащаются собственными внутренними вычислительными мощностями, вводится копирование на стороне сервера, позволяющее снизить нагрузку при копировании данных во внутренней сети, когда это можно эффективно делать на самом запоминающем устройстве. Другие инновации включают в себя субфайловое кэширование для флэш-памяти и рекомендации по настройке ввода-вывода на стороне клиента (например, с использованием mapadvise).
Альтернативы NFS
Хотя NFS – самая популярная сетевая файловая система в UNIX и Linux, кроме нее существуют и другие сетевые файловые системы. На платформе Windows® чаще всего применяется SMB, также известная как CIFS ; при этом ОС Windows также поддерживает NFS, равно как и Linux поддерживает SMB.
Одна из новейших распределенных файловых систем, поддерживаемых в Linux - Ceph - изначально спроектирована как отказоустойчивая POSIX-совместимая файловая система. Дополнительную информацию о Ceph можно найти в разделе .
Стоит также упомянуть файловые системы OpenAFS (Open Source-версия распределенной файловой системы Andrew, разработанной в университете Карнеги-Меллона и корпорации IBM), GlusterFS (распределенная файловая система общего назначения для организации масштабируемых хранилищ данных) и Lustre (сетевая файловая система с массовым параллелизмом для кластерных решений). Все эти системы с открытым исходным кодом можно использовать для построения распределенных хранилищ.
Заключение
Развитие файловой системы NFS продолжается. Подобно ОС Linux, подходящей для поддержки и бюджетных, и встраиваемых, и высокопроизводительных решений, NFS предоставляет архитектуру масштабируемых решений для хранения данных, подходящих как отдельным пользователям, так и организациям. Если посмотреть на путь, уже пройденный NFS, и перспективы её дальнейшего развития, становится понятно, что эта файловая система будет продолжать изменять наши взгляды на то, как реализуются и используются технологии хранения файлов.
Network file system (NFS)
- протокол сетевого доступа к файловым системам, позволяет подключать удалённые файловые системы.
Первоначально разработан Sun Microsystems в 1984 г. Основой является Sun RPC: вызов удаленной процедуры (Remote Procedure Call). NFS независим от типов файловых систем сервера и клиента. Существует множество реализаций NFS-серверов и клиентов для различных ОС. В настоящее время используется версия NFS v.4, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).
NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера. В отличие от FTP, протокол NFS осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство его в том, что он делает этот доступ прозрачным. Благодаря этому любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без изменений самой программы.
NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC-запросов на сервер. Это может быть реализовано с использованием обычных пользовательских процессов - а именно, NFS клиент может быть пользовательским процессом, который осуществляет конкретные RPC вызовы на сервер, который так же может быть пользовательским процессом.
Версии
NFSv1 была только для внутреннего пользования в экспериментальных целях. Детали реализации определены в RFC 1094.
NFSv2 (RFC 1094, март 1989 года) первоначально полностью работала по протоколу UDP.
NFSv3 (RFC 1813, июнь 1995 года). Описатели файлов в версии 2 - это массив фиксированного размера - 32 байта. В версии 3 - это массив переменного размера с размером до 64 байт. Массив переменной длины в XDR определяется 4-байтным счётчиком, за которым следуют реальные байты. Это уменьшает размер описателя файла в таких реализациях, как, например, UNIX, где требуется всего около 12 байт, однако позволяет не-Unix реализациям обмениваться дополнительной информацией.
Версия 2 ограничивает количество байт на процедуры READ или WRITE RPC размером 8192 байта. Это ограничение не действует в версии 3, что, в свою очередь, означает, что с использованием UDP ограничение будет только в размере IP датаграммы (65535 байт). Это позволяет использовать большие пакеты при чтении и записи в быстрых сетях.
Размеры файлов и начальное смещение в байтах для процедур READ и WRITE стали использовать 64-битную адресацию вместо 32-битной, что позволяет работать с файлами большего размера.
Атрибуты файла возвращаются в каждом вызове, который может повлиять на атрибуты.
Записи (WRITE) могут быть асинхронными, тогда как в версии 2 они должны были быть синхронными.
Одна процедура была удалена (STATFS) и семь были добавлены: ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1 информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение).
На момент введения версии 3, разработчики стали больше использовать TCP как транспортный протокол. Хотя некоторые разработчики уже Использовали протокол TCP для NFSv2, Sun Microsystems добавили поддержку TCP в NFS версии 3. Это сделало использование NFS через Интернет более осуществимым.
NFSv4 (RFC 3010, декабрь 2000 г., RFC 3530, пересмотренная в апреле 2003), под влиянием AFS и CIFS, включила в себя улучшение производительности, высокую безопасность, и предстала полноценным протоколом. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF), после того, как Sun Microsystems передала развитие протоколов NFS. NFS версии v4.1 была одобрена IESG в январе 2010 года, и получила номер RFC 5661. Важным нововведением версии 4.1 является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые "облачные" ("cloud") хранилища и информационные системы.
Структура NFS включает три компонента разного уровня:
Прикладной уровень (собственно NFS) - это вызовы удаленных процедур (rpc), которые и выполняют необходимые операции с файлами и каталогами на стороне сервера.
Функции уровня представления выполняет протокол XDR (eXternal Data Representation), который является межплатформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую, форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
Сервис RPC (Remote Procedure Call), обеспечивающий запрос удаленных процедур клиентом и их выполнение на сервере, представляет функции сеансового уровня.Подключение сетевых ресурсов
Процедура подключения сетевого ресурса средствами NFS называется "экспортированием". Клиент может запросить у сервера список представляемых им экспортируемых ресурсов. Сам сервер NFS не занимается широковещательной рассылкой списка своих экспортируемых ресурсов.
В зависимости от заданных опций, экспортируемый ресурс может быть смонтирован (присоединён) "только для чтения", можно определить список хостов, которым разрешено монтирование, указать использование защищенного RPC (secureRPC) и пр. Одна из опций определяет способ монтирования: "жесткое" (hard) или "мягкое" (soft).
При "жестком" монтировании клиент будет пытаться смонтировать файловую систему во что бы то ни стало. Если сервер не работает, это приведет к тому, что весь сервис NFS как бы зависнет: процессы, обращающиеся к файловой системе, перейдут в состояние ожидания окончания выполнения запросов RPC. С точки зрения пользовательских процессов файловая система будет выглядеть как очень медленный локальный диск. При возврате сервера в рабочее состояние сервис NFS продолжит функционирование.
При "мягком" монтировании клиент NFS сделает несколько попыток подключиться к серверу. Если сервер не откликается, то система выдает сообщение об ошибке и прекращает попытки произвести монтирование. С точки зрения логики файловых операций при отказе сервера "мягкое" монтирование эмулирует сбой локального диска.
Выбор режима зависит от ситуации. Если данные на клиенте и сервере должны быть синхронизированы при временном отказе сервиса, то "жесткое" монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах "только для чтения", режим "мягкого" монтирования представляется более удобным.
Общий доступ в смешанной сети
Сервис NFS идеально подходит для сетей на основе UNIX, так как поставляется с большинством версий этой операционной системы. Более того, поддержка NFS реализована на уровне ядра UNIX. Использование NFS на клиентских компьютерах с Windows создает определенные проблемы, связанные с необходимостью установки специализированного и довольно дорогого клиентского ПО. В таких сетях использование средств разделения ресурсов на основе протокола SMB/CIFS, в частности ПО Samba, выглядит более предпочтительным.
Стандарты
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
Используемые источники
1. ru.wikipedia.org
2. ru.science.wikia.com
3. phone16.ru
4. 4stud.info
5. yandex.ru
6. gogle.com
Основные особенности работы файловой системы 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 производится в соответствии с четырьмя основными правилами.
- Файловую систему можно экспортировать как целиком, так и по частям, каковыми являются каталоги и файлы. При этом следует помнить, что самой крупной экспортируемой единицей является файловая система. Если на сервере некая файловая система (/usr/bin) смонтирована по иерархии ниже другой файловой системы (/usr), то экспортирование системы /usr систему /usr/bin не затронет.
- Экспортировать можно только локальные файловые ресурсы, иными словами, если на сервере смонтирована чужая файловая система, т. е. находящаяся на другом сервере, то ее нельзя реэкспортировать.
- Нельзя экспортировать подкаталоги уже экспортированной файловой системы, если только они не представляют собой самостоятельных файловых систем.
- Нельзя экспортировать родительские каталоги уже экспортированного каталога, если только родительский каталог не представляет собой независимую файловую систему.
Любое нарушение этих правил приведет к ошибке в работе 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, но и к другим сетевым файловым системам).
- С точки зрения клиентских пользовательских программ файловая система NFS располагается как бы на локальном диске. Программы не имеют возможности отличить файлы NFS от обычных файлов.
- Клиент 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).
| Рисунок 2. Операция записи в NFS v2. |
Очень важной особенностью 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.
| Рисунок 4. Операция записи в NFS v3. |
Но, пожалуй, еще более важным новшеством 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.
На данный момент в вашем распоряжении должно быть работающее TCP/IP-подключение к вашей сети. Вы должны быть в состоянии пинговать другие компьютеры сети и, если вы соответствующим образом настроили шлюз, вы также должны быть в состоянии пинговать компьютеры в Интернете. Как известно, главной целью подключения компьютера к сети, является получение доступа к информации. Хотя некоторые люди могут подключать компьютер к сети просто так, большинство людей хотели бы предоставлять и получать доступ к файлам и принтерам. Они хотели бы получать доступ к документам в Интернете или играть в онлайновые игры. Установив в свою новую систему Slackware поддержку TCP/IP и необходимое программное обеспечение, вы всё это получите; однако, установив только поддержку TCP/IP, функциональность будет очень ограниченной. Чтобы предоставлять и получать общий доступ к файлам, нам потребуется переносить их туда и обратно, используя FTP или SCP. Мы не можем посматривать на нашем новой компьютере со Slackware дерево файлов через значки “Сетевое окружение” или “Вся сеть” с Windows-компьютеров. Мы хотели бы иметь возможность иметь постоянный доступ к файлам на других Unix-машинах.
В идеале мы хотели бы использовать сетевую файловую систему , позволяющую нам иметь прозрачный доступ к файлам на компьютерах. Программам, которые мы используем для работы с информацией, хранимой на компьютерах, на самом деле даже не надо знать на каком компьютере хранится нужный файл. Им нужно только знать, что этот файл существует, и способ для его получения. Дальнейшее уже является задачей операционной системы, обеспечивающей доступ к этому файлу с помощью доступных локальных и сетевых файловых систем. Две наиболее часто используемые сетевые файловые системы - это SMB (реализованная через Samba) и NFS.
5.6.1. SMB/Samba/CIFS
SMB (Server Message Block, блок серверных сообщений) - это потомок более старого протокола NetBIOS, изначально разработанного в IBM для их продукта LAN Manager. Компанию Microsoft в свою очередь всегда интересовал NetBIOS и его наследники (NetBEUI, SMB и CIFS). Проект Samba начал своё существование в 1991 году, когда он был написан для обеспечения связи между IBM PC и сервером Unix. Сегодня предоставление общего доступа к файлам и службам печати через сеть SMB является предпочитаемым методом практически для всего цивилизованного мира, поскольку его поддерживает и Windows.
Конфигурационный файл Samba /etc/samba/smb.conf является одним из самых хорошо документированных конфигурационных файлов, которые вы сможете найти. К вашим услугам уже готовые примеры с настройками общих ресурсов, так что вы можете просмотреть и изменить их согласно своим потребностям. Если же вам нужен ещё больший контроль, к вашим услугам страница руководства smb.conf. Поскольку Samba имеет такую хорошую документацию, мы не будем её здесь переписывать. Однако быстро остановимся на основных моментах.
smb.conf разбит на несколько разделов: по одному разделу на общий ресурс плюс один глобальный раздел для настройки параметров, которые используются везде. Некоторые параметры являются действительными только в глобальном разделе, а некоторые верны только за его пределами. Помните, что глобальный раздел может быть переопределён любым другим разделом. За дополнительной информацией обращайтесь к страницам руководства.
Вы скорее всего захотите отредактировать свой файл smb.conf, чтобы отразить в нём параметры своей локальной сети. Советуем вам изменить перечисленные ниже пункты:
Это будет описание вашего компьютера Slackware, показываемое в папке Сетевое окружение (или Вся сеть).
Вы почти наверняка захотите использовать в своей системе Slackware уровень безопасности user.
Если шифрование паролей не включено, вы не сможете использовать Samba с системами NT4.0, Win2k, WinXP и Win2003. Для предыдущих версий операционных систем Windows для предоставления доступа к общим ресурсам шифрование не требовалось.
SMB является протоколом с аутентификацией, т.е. вы можете указать имя пользователя и пароль, чтобы воспользоваться возможностями этой службы. Мы сообщаем серверу samba о том, что имена пользователей и пароли верны, посредством команды smbpasswd. smbpasswd допускает использование общих ключей для добавления как обычных пользователей, так и машин-пользователей (для SMB необходимо, чтобы вы добавили NETBIOS-имена компьютеров как машин-пользователей, ограничивая тем самым круг компьютеров, с которых может осуществляться аутентификация).
Важно учесть, что данное имя пользователя или имя машины должно уже существовать в файле /etc/passwd. Вы можете добиться этого с помощью команды adduser. Обратите внимание, что при использовании команды adduser для добавления имени компьютера к нему необходимо добавить знак доллара (“$”). Однако этого не нужно делать при работе с smbpasswd. Утилита smbpasswd самостоятельно добавляет знак доллара. Нарушение этого правила посредством adduser приведёт к ошибке при добавлении имени машины в samba.
|
#adduser machine$ |
5.6.2. Сетевая файловая система (NFS)
NFS (Network File System) изначально была написана компанией Sun для Solaris - их реализации системы Unix. И хотя её значительно легче поднять и настроить по сравнению с SMB, NFS гораздо менее безопасна. Главным слабым местом в безопасности является несложность подмены идентификаторов пользователя и группы одной машины на идентификаторы с другой машины. В протоколе NFS не реализована аутентификация. Было заявлено, что в будущих версиях протокола NFS безопасность будет повышена, однако на время написания этой книги это ещё не было сделано.
Настройка NFS осуществляется через файл /etc/exports. Когда вы загрузите стандартный файл /etc/exports в редактор, вы увидите пустой файл с комментарием вверху на две строки. Нам надо будет добавить строку в файл exports для каждого из каталогов, которые мы хотим экспортировать, с перечнем клиентских рабочих станций, которым будет разрешён доступ к этому каталогу. Например, если нам нужно экспортировать каталог /home/foo для рабочей станции Bar, нам надо будет добавить в наш файл /etc/exports такую строку:
Как видите, существует несколько различных опций, однако большинство из них должны быть понятными из этого примера.
NFS полагает, что заданный пользователь с одной из машин в сети имеет один и тот же идентификатор на всех остальных машинах. Когда NFS-клиент делает попытку чтения или записи на NFS-сервер, UID передаётся как часть запроса на чтение/запись. Этот UID считается таким же, как если бы запрос был выполнен с локальной машины. Как видите, если кто-то сможет произвольным образом указать заданный UID при обращении к ресурсам на удалённой машине, неприятности могут случиться и случаются. Средство, отчасти позволяющее избежать этого, заключается в монтировании всех каталогов с параметром root_squash . Это переопределяет UID любого пользователя, объявившего себя root"ом, на другой UID, предотвращая таким образом root"овый доступ к файлам и каталогам в экспортируемом каталоге. Похоже, что root_squash включается по умолчанию по соображениям безопасности, однако авторы всё равно рекомендуют явно указывать его в своём файле /etc/exports.
Вы также можете экспортировать каталог на сервере непосредственно из командной строки, воспользовавшись командой exportfs, как показано ниже:
|
# exportfs -o rw,no_root_squash Bar:/home/foo |
Эта команда экспортирует каталог /home/foo для компьютера “Bar” и предоставляет ему доступ на чтение/запись. Кроме того на сервере NFS не включен параметр root_squash , означающий, что любой пользователь на Bar с UID “0” (UID root"а) будет иметь на сервере те же привилегии, что и root. Синтаксис выглядит довольно странно (обычно, когда вы указываете каталог в виде computer:/directory/file, вы ссылаетесь на файл в каталоге на заданном компьютере).
Дополнительную информацию о файле exports вы найдёте в странице руководства.
