25.3. Network File System (NFS)

Реорганизация и улучшения Tom Rhodes. Текст создал Bill Swingle.

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

Вот некоторые из наиболее заметных преимуществ, которые даёт использование NFS:

25.3.1. Как работает NFS

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

На сервере работают следующие даемоны:

Даемон Описание
nfsd Даемон NFS, обслуживающий запросы от клиентов NFS.
mountd Даемон монтирования NFS, который выполняет запросы, передаваемые ему от nfsd(8).
rpcbind Этот даемон позволяет клиентам NFS определить порт, используемый сервером NFS.

Клиент может запустить также даемон, называемый nfsiod. nfsiod обслуживает запросы, поступающие от сервера от сервера NFS. Он необязателен, увеличивает производительность, однако для нормальной и правильной работы не требуется. Для получения дополнительной информации обратитесь к разделу справочной системы о nfsiod(8).

25.3.2. Настройка NFS

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

Проверьте, что на NFS-сервере в файле /etc/rc.conf имеются такие строки:

rpcbind_enable="YES"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 4"
mountd_flags="-r"

mountd запускается автоматически, если включена функция сервера NFS.

На клиенте убедитесь, что в файле /etc/rc.conf присутствует такой параметр:

nfs_client_enable="YES"

Файл /etc/exports определяет, какие файловые системы на вашем сервере NFS будут экспортироваться (иногда их называют ''совместно используемыми''). Каждая строка в /etc/exports задаёт файловую систему, которая будет экспортироваться и какие машины будут иметь к ней доступ. Кроме машин, имеющих доступ, могут задаваться другие параметры, влияющие на характеристики доступа. Имеется полный набор параметров, которые можно использовать, но здесь пойдёт речь лишь о некоторых из них. Описания остальных параметров можно найти на страницах справочной системы по exports(5).

Вот несколько примерных строк из файла /etc/exports:

В следующих примерах даётся общая идея того, как экспортировать файловые системы, хотя конкретные параметры могут отличаться в зависимости от ваших условий и конфигурации сети. К примеру, чтобы экспортировать каталог /cdrom для трёх машин, находящихся в том же самом домене, что и сервер (поэтому отсутствует доменное имя для каждой машины) или для которых имеются записи в файле /etc/hosts. Флаг -ro указывает на использование экспортируемой файловой системы в режиме только чтения. С этим флагом удалённая система не сможет никоим образом изменить экспортируемую файловую систему.

/cdrom -ro host1 host2 host3

В следующей строке экспортируется файловая система /home, которая становится доступной трем хостам, указанным по их IP-адресам. Это полезно, если у вас есть собственная сеть без настроенного сервера DNS. Как вариант, файл /etc/hosts может содержать внутренние имена хостов; пожалуйста, обратитесь к справочную систему по hosts(5) для получения дополнительной информации. Флаг -alldirs позволяет рассматривать подкаталоги в качестве точек монтирования. Другими словами, это не монтирование подкаталогов, но разрешение клиентам монтировать только каталоги, которые им требуются или нужны.

/home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4

В строке, приведённой ниже, файловая система /a экспортируется таким образом, что она доступна двум клиентам из других доменов. Параметр -maproot=root позволяет пользователю root удалённой системы осуществлять запись на экспортируемую файловую систему как пользователь root. Если параметр -maproot=root не задан, то даже если пользователь имеет права доступа root на удалённой системе, он не сможет модифицировать файлы на экспортированной файловой системе.

/a  -maproot=root  host.example.com box.example.org

Для того, чтобы клиент смог обратиться к экспортированной файловой системе, он должен иметь права сделать это. Проверьте, что клиент указан в вашем файле /etc/exports.

В файле /etc/exports каждая строка содержит информацию об экспортировании для отдельной файловой системы для отдельно взятого хоста. Удалённый хост может быть задан только один раз для каждой файловой системы, и может иметь только одну запись, используемую по умолчанию, для каждой локальной файловой системы. К примеру, предположим, что /usr является отдельной файловой системой. Следующий /etc/exports будет некорректен:

# Invalid when /usr is one file system
/usr/src   client
/usr/ports client

Одна файловая система, /usr, имеет две строки, задающие экспортирование для одного и того же хоста, client. Правильный формат в этом случае таков:

/usr/src /usr/ports  client

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

Ниже приведён пример правильного списка экспортирования, где /usr и /exports являются локальными файловыми системами:

# Экспортируем src и ports для client01 и client02, но
# только client01 имеет права пользователя root на них
/usr/src /usr/ports -maproot=root    client01
/usr/src /usr/ports        client02
# Клиентские машины имеют пользователя root и могут монтировать всё в
# каталоге /exports.  Кто угодно может монтировать /exports/obj в режиме чтения
/exports -alldirs -maproot=root      client01 client02
/exports/obj -ro

Даемон mountd должен быть проинформирован об изменении файла /etc/exports, чтобы изменения вступили в силу. Это может быть достигнуто посылкой сигнала HUP процессу mountd:

# kill -HUP `cat /var/run/mountd.pid`

или вызовом скрипта mountd подсистемы rc(8) с соответствующим параметром:

# /etc/rc.d/mountd reload

За подробной информацией о работе скриптов rc.d обращайтесь к Разд. 11.7.

Как вариант, при перезагрузке FreeBSD всё настроится правильно. Хотя выполнять перезагрузку вовсе не обязательно. Выполнение следующих команд пользователем root запустит всё, что нужно.

На сервере NFS:

# rpcbind
# nfsd -u -t -n 4
# mountd -r

На клиенте NFS:

# nfsiod -n 4

Теперь всё должно быть готово к реальному монтированию удалённой файловой системы. В приводимых примерах сервер будет носить имя server, а клиент будет носить имя client. Если вы только хотите временно смонтировать удалённую файловую систему, или всего лишь протестировать ваши настройки, то просто запустите команды, подобные приводимым здесь, работая как пользователь root на клиентской машине:

# mount server:/home /mnt

По этой команде файловая система /home на сервере будет смонтирована в каталог /mnt на клиенте. Если всё настроено правильно, вы сможете войти в каталог /mnt на клиенте и увидеть файлы, находящиеся на сервере.

Если вы хотите автоматически монтировать удалённую файловую систему при каждой загрузке компьютера, добавьте файловую систему в /etc/fstab. Вот пример:

server:/home     /mnt    nfs     rw      0   0

На страницах справочной системы по fstab(5) перечислены все доступные параметры.

25.3.3. Практическое использование

У NFS есть много вариантов практического применения. Ниже приводится несколько наиболее широко распространённых способов её использования:

25.3.4. Автоматическое монтирование с amd

Текст предоставил Wylie Stilwell. Текст переписал Chern Lee.

amd(8) (даемон автоматического монтирования) автоматически монтирует удалённую файловую систему, как только происходит обращение к файлу или каталогу в этой файловой системе. Кроме того, файловые системы, которые были неактивны некоторое время, будут автоматически размонтированы даемоном amd. Использование amd является простой альтернативой статическому монтированию, так как в последнем случае обычно всё должно быть описано в файле /etc/fstab.

amd работает, сам выступая как сервер NFS для каталогов /host и /net. Когда происходит обращение к файлу в одном из этих каталогов, amd ищет соответствующий удаленный ресурс для монтирования и автоматически его монтирует. /net используется для монтирования экспортируемой файловой системы по адресу IP, когда как каталог /host используется для монтирования ресурса по удаленному имени хоста.

Обращение к файлу в каталоге /host/foobar/usr укажет amd на выполнение попытки монтирования ресурса /usr, который находится на хосте foobar.

Пример 25-2. Монтирование ресурса при помощи amd

Вы можете посмотреть доступные для монтирования ресурсы отдалённого хоста командой showmount. К примеру, чтобы посмотреть ресурсы хоста с именем foobar, вы можете использовать:

% showmount -e foobar
Exports list on foobar:
/usr                   10.10.10.0
/a               10.10.10.0
% cd /host/foobar/usr

Как видно из примера, showmount показывает /usr как экспортируемый ресурс. При переходе в каталог /host/foobar/usr даемон amd пытается разрешить имя хоста foobar и автоматически смонтировать требуемый ресурс.

amd может быть запущен из скриптов начальной загрузки, если поместить такую строку в файл /etc/rc.conf:

amd_enable="YES"

Кроме того, даемону amd могут быть переданы настроечные флаги через параметр amd_flags. По умолчанию amd_flags настроен следующим образом:

amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"

Файл /etc/amd.map задает опции, используемые по умолчанию при монтировании экспортируемых ресурсов. В файле /etc/amd.conf заданы настройки некоторых более сложных возможностей amd.

Обратитесь к справочным страницам по amd(8) и amd.conf(5) для получения более полной информации.

25.3.5. Проблемы взаимодействия с другими системами

Текст предоставил John Lind.

Некоторые сетевые адаптеры для систем PC с шиной ISA имеют ограничения, которые могут привести к серьезным проблемам в сети, в частности, с NFS. Эти проблемы не специфичны для FreeBSD, однако эту систему они затрагивают.

Проблема, которая возникает практически всегда при работе по сети систем PC (FreeBSD) с высокопроизводительными рабочими станциями, выпущенными такими производителями, как Silicon Graphics, Inc. и Sun Microsystems, Inc. Монтирование по протоколу NFS будет работать нормально, и некоторые операции также будут выполняться успешно, но неожиданно сервер окажется недоступным для клиент, хотя запросы к и от других систем будут продолжаться обрабатываться. Такое встречается с клиентскими системами, не зависимо от того, является ли клиент машиной с FreeBSD или рабочей станцией. Во многих системах при возникновении этой проблемы нет способа корректно завершить работу клиента. Единственным выходом зачастую является холодная перезагрузка клиента, потому что ситуация с NFS не может быть разрешена.

Хотя ''правильным'' решением является установка более производительного и скоростного сетевого адаптера на систему FreeBSD, имеется простое решение, приводящее к удовлетворительным результатам. Если система FreeBSD является сервером, укажите параметр -w=1024 на клиенте при монтировании. Если система FreeBSD является клиентом, то смонтируйте файловую систему NFS с параметром -r=1024. Эти параметры могут быть заданы в четвертом поле записи в файле fstab клиента при автоматическом монтировании, или при помощи параметра -o в команде mount(8) при монтировании вручную.

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

В следующих примерах fastws является именем хоста (интерфейса) высокопроизводительной рабочей станции, а freebox является именем хоста (интерфейса) системы FreeBSD со слабым сетевым адаптером. Кроме того, /sharedfs будет являться экспортируемой через NFS файловой системой (обратитесь к страницам справочной системы по команде exports(5)), а /project будет точкой монтирования экспортируемой файловой системы на клиенте. В любом случае, отметьте, что для вашего приложения могут понадобиться дополнительные параметры, такие, как hard, soft или bg.

Пример системы FreeBSD (freebox) как клиента в файле /etc/fstab на машине freebox:

fastws:/sharedfs /project nfs rw,-r=1024 0 0

Команда, выдаваемая вручную на машине freebox:

# mount -t nfs -o -r=1024 fastws:/sharedfs /project

Пример системы FreeBSD в качестве сервера в файле /etc/fstab на машине fastws:

freebox:/sharedfs /project nfs rw,-w=1024 0 0

Команда, выдаваемая вручную на машине fastws:

# mount -t nfs -o -w=1024 freebox:/sharedfs /project

Практически все 16-разрядные сетевые адаптеры позволят работать без указанных выше ограничений на размер блоков при чтении и записи.

Для тех, кто интересуется, ниже описывается, что же происходит в при появлении этой ошибки, и объясняется, почему ее невозможно устранить. Как правило, NFS работает с ''блоками'' размером 8 килобайт (хотя отдельные фрагменты могут иметь меньшие размеры). Так, пакет Ethernet имеет максимальный размер около 1500 байт, то ''блок'' NFS разбивается на несколько пакетов Ethernet, хотя на более высоком уровне это все тот же единый блок, который должен быть принят, собран и подтвержден как один блок. Высокопроизводительные рабочие станции могут посылать пакеты, которые соответствуют одному блоку NFS, сразу друг за другом, насколько это позволяет делать стандарт. На слабых, низкопроизводительных адаптерах пакеты, пришедшие позже, накладываются поверх ранее пришедших пакетов того же самого блока до того, как они могут быть переданы хосту и блок как единое целое не может быть собран или подтвержден. В результате рабочая станция входит в ситуацию тайм-аута и пытается повторить передачу, но уже с полным блоком в 8 КБ, и процесс будет повторяться снова, до бесконечности.

Задав размер блока меньше размера пакета Ethernet, мы достигаем того, что любой полностью полученный пакет Ethernet может быть подтвержден индивидуально, и избежим тупиковую ситуацию.

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

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <[email protected]>.
По вопросам, связанным с этой документацией, пишите <[email protected]>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <[email protected]>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.