Использование сетевой файловой системы в AIX – пример

Как использовать NFS и повысить производительность системы

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

Шив Дутта, старший инженер-программист, IBM

Шив Дутта (Shiv Dutta) - старший инженер-программист в группе IBM System And Technology Group; он оказывает помощь независимым производителям программного обеспечения в адаптации их программ на платформе System p. Шив был одним из соавторов справочника Красная книга (redbook) AIX 5L Differences Guide Version 5.3 Edition (Новое в AIX 5L версии 5.3). Вы можете связаться с ним по электронной почте sdutta@us.ibm.com.



14.05.2010

Вступление

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

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

NFS реализован как набор удаленных вызовов процедур (Remote Procedure Call, RPC) от клиента.


Удаленный вызов процедуры (RPC) – основа NFS

RPC является библиотекой процедур. Процедуры позволяют клиенту напрямую отправлять серверу процедурные вызовы так, как если бы процесс клиента выполнял все вызовы в своем адресном пространстве. Так как клиент и сервер являются двумя отдельными процессами, им не нужно находиться на одной физической системе. Поскольку процессы клиента и сервера могут находиться на двух различных системах, которые могут работать на двух различных аппаратных платформах, RPC должен обращать внимание на возможность того, что две системы могут не поддерживать одновременно один и тот же формат данных. Поэтому RPC использует типы данных, определенные протоколом eXternal Data Representation (стандарт для аппаратно-независимых структур данных, XDR).

До AIX 4.2.1, UDP (User Datagram Protocol) был единственным транспортным протоколом для NFS-пакетов. TCP (Transmission Control Protocol) был добавлен в качестве альтернативного протокола в AIX 4.2.1. UDP хорошо работает в «чистых» сетях и на надежных серверах. Для больших или загруженных сетей или сетей с медленными серверами TCP может обеспечить лучшую производительность, поскольку его встроенная возможность управления потоками может уменьшить повторную передачу данных по сети.

Также до AIX 4.3, UDP был транспортным протоколом по умолчанию для NFS Version 2 и 3. В AIX 4.3 и более поздних версиях, TCP является протоколом по умолчанию для NFS Version 3, но, используя новую опцию монтирования (proto), клиент может выбрать TCP или UDP. Например:

# mount -o proto=tcp

Из-за более высокой скорости и простоты UDP является предпочтительным протоколом для NFS. Однако, хотя этот протокол и быстрый, он ненадежный. Сеть не гарантирует что пакеты, передаваемые через UDP, будут доставлены или что они будут доставлены по порядку. NFS пытается устранить эту проблему, требуя от NFS-сервера, чтобы он подтверждал прием каждой команды RPC отправкой клиенту кода, который должен указывать успешно была выполнена команда или нет. Если NFS-клиент не получает подтверждения в течение какого-либо определенного периода времени, он повторно передает команду.

Каковы последствия применения этого метода? Если клиент не получил подтверждения, значит UDP потерял или исходную команду RPC, или подтверждение приема RPC команды. Если исходная команда RPC была потеряна, сервер обработает эту команду как в первый раз после того, как она была повторно передана. Но если было утеряно подтверждение о приеме, сервер обработает одну и ту же команду RPC дважды.

Для большинства команд NFS это дублирование запросов не представляет проблемы. С read , например, не будет иметь никакого значения, если один и тот же блок данных будет прочитан один или несколько раз. Другие команды, однако, не могут быть выполнены два раза подряд. Например, mkdir во второй раз выполнена не будет. Для команд, подобных этой, некоторые NFS-серверы содержат кэш последних 400 команд, которые были выполнены. Когда сервер получает запрос mkdir, он сначала проверяет кэш, чтобы узнать, не получал ли он только что другой запрос mkdir. Если так оно и есть, сервер только повторно передает подтверждение. Если клиент NFS так и не получил подтверждения, клиент будет передавать команду серверу раз за разом, удваивая время повторения запроса. Если сетевая файловая система была смонтирована с опцией soft, то, в конечном счете, время выполнения запроса истечет; если с опцией hard – клиент будет продолжать отсылать запрос до тех пор, пока его не перезагрузят или не придет подтверждение. (Более подробно об этих опциях будет рассказано позже).


Серверы NFS – connectionless и stateless

По архитектуре NFS-серверы считаются сonnectionless и stateless. Connectionless означает то, что серверная программа не отслеживает состояние связи с каждым клиентом, который удаленно смонтировал файловую систему. Stateless означает, что вся информация, которая нужна клиенту для монтирования удаленной файловой системы, хранится на самом клиенте. Как только появится дескриптор файла, это файловый дескриптор останется действительным, даже если сервер выключится или перезагрузится, так долго, пока существует файл и до тех пор, пока не сделаны значительные изменения в конфигурации сервера.

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

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

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


Создание NFS-среды

NFS состоит из конечного числа компонентов, включая протокол монтирования, файл export и демон-процессы (mountd, nfsd, biod, rpc.lockd, rpc.stad), которые координируют основные файловые службы.

Файл export – /etc/exports

Системы, использующие NFS, делают файлы доступными по сети для других систем, "экспортируя" свои каталоги в сеть. Сервер NFS экспортирует свои каталоги, помещая их имена в файл /etc/exports и выполняя команду exportfs. В простейшем случае файл /etc/exports состоит из строк вида:

pathname -option, option ...

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

/cyclop/users	  -access=homer:bart, root=homer
/usr/share/man	  -access=marge:maggie:lisa
/usr/mail

Этот файл export позволяет смонтировать файловую систему /cyclops/users пользователям homer и bart, и разрешает администраторский доступ к этой файловой системе для пользователя homer (как и для cyclop, фактического владельца файловой системы). В дополнение, файл позволяет смонтировать файловую систему /usr/share/man пользователям marge, maggie и lisa. Файловая система /usr/mail может быть смонтирована любой системой в сети. Файловые системы, перечисленные в файле export без задания хостов, можно смонтировать на всех компьютерах. Это может быть значительной уязвимостью в безопасности.

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

# /usr/sbin/exportfs -a

Если содержимое /etc/exports изменится, необходимо сделать так, чтобы mountd перечитал этот файл. Сделать это можно, выполнив еще раз команду exportfs после того, как содержимое файла export изменилось.

Точные атрибуты, которые могут быть заданы в файле /etc/exports, зависят от конкретной системы. Наиболее распространенными атрибутами являются:

АтрибутОписание
-access=listСписок имен хостов и сетевых групп, которые могут монтировать файловую систему (отделяется двоеточием).
-roЭкспорт только для чтения; никакие клиенты не могут осуществлять запись в файловую систему.
-rw=listЭкспортирование для чтения большинством. Список list перечисляет все хосты, которые могут монтировать файловую систему для записи в нее данных; все остальные хосты могут монтировать файловую систему только для чтения.
-root=listПеречисляет хосты, которым разрешен доступ к файловой системе в качестве администратора. Без этой опции администраторский доступ с клиентского компьютера является эквивалентным доступу пользователя nobody (обычно UID -2).
-anonЗадает UID , который должен использоваться для запросов, приходящих от неизвестных пользователей. По умолчанию UID пользователя nobody.
-hostnameПозволяет хосту с именем hostname смонтировать файловую систему.

Например:

/cyclop/users	-rw=moe,anon=-1
/usr/inorganic	-ro

Данный код позволяет moe монтировать /cyclop/users для чтения и записи и преобразует UID анонимных пользователей – имена пользователей с других хостов, которых не существует на локальной системе, а также пользователя root с любого удаленного компьютера – к UID -1. Это соответствует учетной записи nobody и заставляет NFS закрыть подобным пользователям доступ ко всем данным. На некоторых системах UID -2 может использоваться для предоставления доступа на чтение публичного файла анонимным пользователям. Доступ только для чтения относится к доступу "в основном для чтения " (read-mostly).

Серверные программы и процессы-демоны

Серверные программы NFS mountd, nfsd, biod, rpc.lockd, rpc.statd и portmap выполняют фактическое управление сетью каталогов. Для того чтобы NFS работал, эти программы должны выполняться постоянно. Хотя можно запустить эти программы в любое время, когда понадобится запустить на системе NFS, в AIX они включены в /etc/rc.nfs, который запускается из файла автозапуска /etc/inittab.

$ cat /etc/rc.nfs
.......... [Deleted].........
dspmsg cmdnfs.cat -s 8 1 "Starting NFS services:\n"
trap 'dspmsg cmdnfs.cat -s 8 3 "Completed NFS services.\n"' 0
if [ -x /usr/sbin/biod ]; then
	start biod /usr/sbin/biod 8
fi

#
# If nfs daemon is executable and /etc/exports, become nfs server.
#
if [ -x /usr/sbin/nfsd -a -f /etc/exports ]; then
	> /etc/xtab
	/usr/sbin/exportfs -a
	start nfsd /usr/sbin/nfsd 8
	start rpc.mountd /usr/sbin/rpc.mountd
fi

#
# start up status monitor and locking daemon if present
#
if [ -x /usr/sbin/rpc.statd ]; then
	start rpc.statd /usr/sbin/rpc.statd
fi

if [ -x /usr/sbin/rpc.lockd ]; then
	start rpc.lockd /usr/sbin/rpc.lockd
fi

..............[Deleted]........

## Begin AutoFS startup   ## Do NOT remove
##
if [ -s /etc/auto_master ]; then 
	/usr/sbin/automount
fi
##
## End AutoFS startup   ## Do NOT remove
$

Демон-процесс mountd

После экспорта файлов, каталогов и/или файловых систем NFS-клиент, прежде чем сможет их использовать, должен корректно их смонтировать. Этот процесс управляется демоном mountd (иногда его называют rpc.mountd). Сервер проверяет запрос на монтирование чтобы убедиться, что клиент должным образом прошел авторизацию, затем передает клиенту "волшебное cookie" ("magic cookie"), на самом деле случайное число, которое клиент может использовать позднее для получения доступа. Схема со случайным числом поддерживает состояние stateless для сервера. Сookies сохраняются в случае перезагрузки, поэтому перезапущенный сервер может возвратиться к своему предыдущему состоянию нормального функционирования. Обычно размонтирование и повторное монтирование файловых систем на сервере меняет сookies.

Как только клиент получит свой cookie (случайное число), он использует RPC для выполнения запросов операций файловой системы, например, создание файла или чтение сегмента данных. Поскольку NFS является stateless, сервер не волнует, какие запросы клиент уже сделал или не сделал. В частности, клиент ответственен за обеспечение того, что сервер вернет подтверждение запроса на запись данных прежде, чем удалит свою копию данных, которые войдут в запрос.

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

#  mount  -t  nfs  server1:/usr/src  /src
#

Здесь структура каталога /usr/src, находящаяся на удаленной системе server1, смонтирована в каталог /src на локальной системе. Параметр -t nfs определяет, что типом файловой системы является удаленный NFS-каталог.

Когда удаленная файловая система больше не нужна, ее можно демонтировать командой umount

#  umount  server1:/usr/src
#

mount и df предоставляют информацию о локальной и удаленной файловых системах:

#df
filesystem512-blocksFree% usedIused%IusedMounted on
/dev/hd43276874498%233129%/
/dev/hd2491520034851293%489098%/usr
/dev/hd9var104857685579219%12101%/var
/dev/hd365536628245%611%/tmp
/dev/hd111796489816100%10871%/home
/proc-----/proc
/dev/hd10opt403046439071291%6474413%/opt
server1:/usr/src23962243320%130021%/test
mount
nodemountedmounted overvfsdateoptions

/dev/hd4/jfsJul 29 12:58rw,log=/dev/hd8

/dev/hd2/usrjfsJul 29 12:58rw,log=/dev/hd8

/dev/hd9var/varjfsJul 29 12:58rw,log=/dev/hd8

/dev/hd3/tmpjfsJul 29 12:58rw,log=/dev/hd8

/dev/hd1/homejfsJul 29 13:02rw,log=/dev/hd8

/proc/procprocfsJul 29 13:02rw

/dev/hd10opt/optjfsJul 29 13:02rw,log=/dev/hd8

Команда showmount перечисляет экспортируемые файловые системы (используя опцию -e) или другие хосты, которые удаленно смонтировали локальные системы (-a). Приведенный ниже пример показывает, что хосты server1 и server2 смонтировали файловые системы sourcefiles и datafiles соответственно:

#showmount  -a
server1:/sourcefiles
Server2:/datafiles

Команда mount может использоваться для установки временных сетевых точек монтирования, но точки монтирования, которые являются частью постоянной конфигурации системы, должны быть перечислены в /etc/filesystems (для AIX) или обработаны средством автоматического монтирования, как то automount или amd.

Команда mount – опции

Следующие опции доступны для использования с командой mount:

bgЕсли первая попытка монтирования неудачна, вторая попытка монтирования предпринимается в фоновом режиме; по умолчанию монтирование проводится в высокоприоритетном режиме.
fgЕсли первая попытка монтирования неудачна, вторая попытка монтирования предпринимается в высокоприоритетном режиме; по умолчанию монтирование проводится в высокоприоритетном режиме.
retry=nПопытка монтирования предпринимается n раз; значения по умолчанию разнятся. Для AIX это 10 ,000.
rsize=nЗадает размер буфера чтения в n байтов; значение по умолчанию для AIX – 8192.
wsize=nЗадает размер буфера записи в n байтов; значение по умолчанию в AIX – 8192.
timeo=nВремя ожидания сетевой файловой системы (NFS) – длина интервала времени, в течение которого ожидается первая попытка индивидуального запроса NFS – измеряется в n десятых долей секунды. Каждая последующая попытка (retry) удваивает время ожидания; значение по умолчанию для AIX это 7.
retrans=nПовторно передает запрос n раз, прежде чем сдается; значение по умолчанию для AIX это 3.
softВозвращается ошибка в случае, если сервер не отвечает; по умолчанию установлено в hard.
hardЗапрос повторяется до тех пор, пока сервер не ответит; является значением по умолчанию.
roСмонтированная файловая система предназначена только для чтения.
rwСмонтированный файл доступен для чтения и записи (по умолчанию).
intrПозволяют выполнять прерывания с клавиатуры, типа завершения зависших процессов, при монтировании типа hard.

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

Если удаленная файловая система смонтирована как hard и параметр intr не указан, то процесс будет блокирован до тех пор, пока удаленная файловая система снова не появится. Для терминального процесса, в особенности, это может быть достаточно раздражающим. Если флаг intr определен, то отправка процессу завершающего сигнала завершит его выполнение. Для терминала завершающий сигнал может быть отправлен комбинацией CTRL-C (хотя процесс не будет завершен мгновенно; придется прождать время ожидания процессом запроса). Для завершения фонового процесса можно отправить сигнал INT (2) или сигнал QUIT (3) (но, возможно, завершение процесса будет не мгновенным).

Отправка сигнала KILL (-9) не завершит зависший процесс.

Казалось бы, что файловая система, смонтированная как soft, обойдет проблему зависания, но это верно только для файловых систем, смонтированных только для чтения. Однако для файловых систем на чтение/запись незаконченным запросом может оказаться запрос на запись, поэтому простой отказ от выполнения может повлечь за собой повреждение файлов на удаленной файловой системе. Следовательно, файловые системы на чтение/запись должны всегда монтироваться как hard, флаг intr тоже должен быть задан, чтобы позволить пользователям самостоятельно принимать решение относительно зависших процессов.

Файловые системы, смонтированные как hard, могут служить причиной зависания процессов, когда их серверы зависнут. Это особенно надоедает, когда зависшие процессы являются стандартными демон-процессами. В большинстве случаев комбинация опций soft и intr уменьшит количество проблем, связанных с NFS. Однако эти опции могут иметь нежелательные побочные эффекты типа прерывания процесса с общим временем выполнения 20 часов, когда тот уже отработал 18, только из-за временного сетевого сбоя. Демон-процесс для автоматического монтирования amd предоставляет некоторые средства для устранения проблем, связанных с монтированием.

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

create()Создает (или усекает) файл в каталоге.
link()Создает жесткую ссылку.
lookup()Ищет файл в каталоге.
mkdir()Создает каталог.
readdr()Считывает содержимое каталога.
remove()Удаляет файлы из каталога.
rename()Переименовывает файлы в каталоге.
rmdir()Удаляет каталог.
symlink()Создает символическую ссылку.

Файловый дескриптор для файла может использоваться для реализации любой из следующих задач:

getattr()Получает файловые атрибуты (владелец, длина и др.).
setattr()Задает атрибуты файла.
readlink()Читает путь, содержащийся в символической ссылке.
read()Считывает из файла.
write()Записывает в файл.

nfsd: серверный демон-процесс

Как только запрос клиента на монтирование был подтвержден демоном mountd, клиенту разрешается запрашивать различные операции с файловой системой. Эти запросы обрабатываются на стороне сервера демоном nfsd – демон-процессом операций NFS. (В действительности nfsd – короткая программа, которая делает системный вызов без кода возврата к серверному коду NFS, встроенному в ядро. Этот процесс «притворяется» пользовательским процессом только для того, чтобы было проще реализовывать вопросы с организацией планирования.) nfsd не требуется выполнять на клиентском компьютере с NFS, если клиент не экспортирует свои собственные файловые системы.

Начиная с AIX 4.2.1, демон-процессы nfsd и biod управляют службами NFS. Каждый из этих демонов является многопоточным (множество потоков ядра внутри процесса), хотя число потоков эти демон-процессы регулируют сами, создавая или удаляя потоки по необходимости. Однако до версии AIX 4.2.1 и nfsd, и biod требовалась настройка. Каждый демон-процесс принимал один аргумент, который определял число копий самого себя, на которые ему надо разветвиться. Подбор подходящего числа nfsds является очень важным и вместе с тем является чем-то вроде волшебства. Если это число слишком низкое или высокое, то производительность NFS может пострадать.

По умолчанию в AIX это число равняется 8. В большинстве случаев 4 является адекватной величиной для сервера, который используется не часто, и достаточно малой величиной, чтобы не повлиять на производительность. В теории, можно запустить десятки или сотни nfsds. Однако слишком большое количество nfsds ухудшит производительность, потому что эти демон-процессы будут сражаться между собой за CPU.

Максимальное число nfsds близко к числу аппаратных контекстов, поддерживаемых чипом CPU компьютера. У современных RISC-процессоров число контекстов на чипе может меняться с каждой версией процессора из конкретного семейства, но обычно оно лежит в диапазоне от 8 до 32. Если есть возможность узнать, какое число контекстов поддерживает CPU (далеко не всегда можно обойтись без справочного руководства к чипу процессора), то число демон-процессов nfsds будет N-2, где N – число контекстов.

Если нельзя определить точное число контекстов процессора, придется воспользоваться методом проб и ошибок, т.е. увеличивать число демон-процессов nfsds до тех пор, пока средняя нагрузка на сервер (выясняется по доступному для работы машинному времени) не начнет значительно увеличиваться. Когда это случится, это будет означать, что система имеет больше демон-процессов nfsds, чем ей надо. Осталось немного уменьшить число демон-процессов и значение, при котором система функционирует устойчиво, будет найдено. Помните, что найдено было максимальное, а не оптимальное число nfsds.

На загруженном сервере NFS могут быть переполнены UDP-сокеты, если запросы приходят, когда все демоны nfsds уже заняты. Число сброшенных из-за переполнения запросов можно наблюдать при помощи команды netstat -s.

Первое, что надо сделать для того чтобы выяснить, сколько дополнительных nfsds нужно запустить, – это добавить больше nfsds до тех пор, пока сброшенные UDP-запросы не пропадут, или будет достигнут максимум возможных демон-процессов nfsds.

biod: клиентский демон-процесс

Для улучшения общей производительности NFS большинство систем включают в себя демон biod, который выполняет основное блочное кэширование файловой системы асинхронного ввода/вывода. Например, когда клиент NFS читает три байта из файла, в большинстве случаев читается гораздо больший кусок (обычно 4 K). Когда клиент читает следующие три байта, нет необходимости в сетевой транзакции данных. Рекомендуется запускать этот демон-процесс на всех клиентах NFS, но эта рекомендация не носит обязательный характер.

Как nfsd, biod принимает в качестве аргумента число своих копий, которые надо запустить. Правила для выбора верного числа копий, которые используются с nfsd, применимы к biod. Если nfsd и biod выполняются на одной машине, может быть верным решением поделить между ними оптимальное число слотов процесса. В этом случае нужно экспериментировать.

Требуется изменить число nfsd и biod?

Для изменения числа демон-процессов biod или nfsd, выполняющихся на системе, надо выполнить команду:

chnfs -n 10 -b 4

Эта команда устанавливает число демонов nfsd равным 10 и число демонов biod равным 4. Также эта команда временно приостанавливает демоны, в данный момент выполняющиеся на системе, модифицирует код базы данных SRC, чтобы тот соответствовал новому числу демонов, и перезапускает демоны.

Управление блокировками NFS: rpc.lockd и rpc.statd

Хотя lockd и statd являются отдельными демон-процессами, они всегда выполняются вместе, как команда. lockd ответственен за обслуживание блокировок файлов NFS. Он управляет блокировками файла на клиентской и серверной системе. statd позволяет процессам наблюдать за статусом компьютеров, на которых выполняется NFS. Он управляет службами восстановления и снятия блокировок на клиенте и сервере. statd используется демон-процессом lockd для принятия решения, в какой момент попытаться связаться с удаленным компьютером.

Когда приложение хочет получить блокировку для локального файла, оно посылает запрос к ядру через процедуры lockf, fcntl или flockl. Затем ядро обрабатывает запрос, связанный с блокировкой. Однако, если приложение на клиенте NFS делает запрос блокировки для удаленного файла, ядро через процедуру RPC перенаправляет запрос демон-процессу клиента rpc.lockd. Когда демон клиента rpc.lockd получает удаленный запрос блокировки, он регистрирует свою заинтересованность на сервере, на котором выполняется клиентский rpc.statd. Когда демон-процесс клиента rpc.statd уведомляет клиентского демона rpc.lockd о том, что сервер функционирует, демон клиента rpc.lockd отправляет свой запрос (через процедуру RPC) серверному демон-процессу rpc.lockd. Серверный демон-процесс rpc.lockd запрашивает затем блокировку у своего собственного ядра и посылает ответ ядра назад клиенту.

Демон-процесс portmap

Каждое RPC-приложение имеет ассоциированный с собой номер программы и номер версии. Эти номера используются для коммуникации с серверным приложением в системе. Клиент, делая запрос серверу, должен знать номер порта, с которого сервер принимает запросы. Этот номер порта связан с протоколом UDP или TCP, который используется службой. Клиент знает номер программы, номер версии и имя хоста или системы, где выполняется серверная служба. Клиент нуждается в способе, который позволит сопоставить пару значений – номер программы и номер версии – номеру порта серверного приложения. Эта задача выполняется при помощи демон-процесса portmap.

Как запустить/остановить демоны NFS и как получить их текущий статус

В данном разделе под демоном подразумевается любой из демонов, управляемых SRC (как то nfsd или biod).

Демоны NFS могут автоматически запускаться при запуске или перезапуске системы путем добавления сценария /etc/rc.nfs в файл /etc/inittab.

Их также можно запустить вручную следующей командой:

startsrc -s Daemon or startsrc -g nfs

где опция -s запустит какой-либо отдельный демон и опция -g запустит все демон-процессы сразу.

Эти демон-процессы могут быть остановлены по отдельности или все сразу с помощью следующей команды:

stopsrc -s Daemon or stopsrc -g nfs

Получить текущий статус этих демонов можно, выполнив следующие команды:

lssrc -s Daemon or lssrc -a

Если файл /etc/exports не существует, демон-процессы nfsd и rpc.mountd не запустятся. Обойти это можно создав пустой файл /etc/exports. Даже если никакие файловые системы не экспортируются, это позволит запуститься демон-процессам nfsd и rpc.mountd

Административные соглашения для NFS

Любой пользователь, который хочет получить доступ к удаленному файлу в сети, должен иметь учетную запись на компьютере, где находится файл. Учетной записи не обязательно иметь реальную оболочку, связанную с ней. Более того, и UID, и GID должны быть уникальными на всех компьютерах, которые используют файловые системы коллективного доступа. Для предупреждения проблем с администрированием лучше всего будет, если номера UID и GID будут уникальными во всем сетевом окружении.


Взаимодействие между NFS и сетями

Традиционно NFS использует UDP в качестве основного транспортного протокола. Хотя NFS сама собирает пакеты и выполняет проверку на ошибки, и UDP, и NFS недостает алгоритмов контроля перегрузки, которые необходимы для хорошей производительности в больших IP-сетях. По этой причине нужно избегать монтировать традиционные разделы NFS через маршрутизаторы, по WAN или через Интернет. Подобная практика достаточно распространена на многих узлах сети, но это плохое решение.

Наиболее целесообразно использовать TCP в качестве основного транспортного протокола при монтировании NFS через маршрутизаторы или WAN-сети.


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

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

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

Третья проблема – когда отключится важный сервер, это может нарушить работоспособность пользователей, сделав важные разделы, например /usr/share/man, недоступными. В этой ситуации лучше всего будет, если копия раздела может быть временно смонтирована на запасном сервере.

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

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

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

К несчастью, у automount есть ряд дефектов и недочетов в проекте, поэтому он не является достойным противником для бесплатного альтернативного проекта amd, написанного Жан-Симоном Пендри (Jan-Simon Pendry) Имперского колледжа города Лондона (Imperial College, London). Этот проект расширяет идею реализации automount, исправляет много серьезных дефектов в automount и может быть легко установлен на различных Unix-системах.


Заключение

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=489905
ArticleTitle=Использование сетевой файловой системы в AIX – пример
publish-date=05142010