NFS позволяет программам одной системы напрямую работать с файлами другой системы путем монтирования удаленного каталога. Обычно, после загрузки сервера, с помощью команды exportfs открывается доступ к каталогам; затем запускаются демоны (демону nfsd), управляющие удаленным доступом. Аналогично, при загрузке клиента монтируются удаленные каталоги и запускаются демоны блочного ввода-вывода (biod).
В версиях до AIX 4.2.1, демоны nfsd и biod были процессами, для работы которых требовалась настройка нескольких демонов nfsd и biod. Начиная с версии AIX 4.2.1, существует один демон nfsd и один демон biod, каждый из которых является многонитевым (то есть в одном процессе существует несколько нитей ядра). Число нитей настраивается автоматически - при необходимости создаются дополнительные нити.
Структура диалога между клиентами NFS и сервером показана на следующем рисунке. Если нить клиентской системы создает запрос на чтение или запись в файл, находящийся в каталоге NFS, запрос перенаправляется от обычного механизма ввода-вывода одному из демонов biod системы клиента. Демон biod отправляет запрос соответствующему серверу, где он присваивается одному из демонов сервера NFS (nfsd). Во время обработки запроса оба демона - biod и nfsd - не могут выполнять другие операции.
Рис. 10-1. Взаимодействие клиент-сервер NFS. На этом рисунке показано взаимодействие двух клиентов и одного сервера, расположенных в сети, созданной по топологии типа "звезда". Клиент A запускает нить m, в которой данные направляются одному из его демонов biod. Клиент B запускает нить n, направляя данные одному из своих демонов biod. Демоны пересылают данные через сеть на сервер Z, где они присваиваются одному из демонов сервера NFS (nfsd).
Связь в NFS осуществляется по протоколу Вызова удаленных процедур (RPC). Этот протокол основан на протоколе Внешнего представления данных (XDR), преобразующем данные в общий формат перед передачей по сети и позволяющем обмениваться информацией системам с различной архитектурой. Библиотека RPC - это библиотека процедур, позволяющая локальному (клиентскому) процессу вызывать процедуры в удаленном (серверном) процессе точно так же, как обычные процедуры в своем адресном пространстве. Так как клиент и сервер - это два отдельных процесса, они не должны обязательно существовать в одной и той же физической системе.
Рис. 10-2. Процессы Mount и NFS. Этот рисунок - это таблица из трех столбцов - Деятельность клиента, Клиент и Сервер. Первой деятельностью клиента является монтирование. Клиент направляет вызов удаленной процедуры демону сервера portmapper mountd. Вторым действием клиента является открыть/закрыть запись/чтение. Между демонами клиента biod и сервера nfsd существует двустороннее взаимодействие.
Демон portmap, portmapper, - это демон сетевой службы, позволяющий клиенту узнавать номер порта, связанного с указанной программой. При вызове служб сервера их регистрация выполняется с помощью демона portmap в качестве доступного сервера. На основе этой информации демон portmap создает и обслуживает таблицу соответствия между программами и портами.
Если клиент создает запрос к серверу, сначала происходит соединение с демоном portmap, в результате чего выясняется местонахождение службы. Демон portmap работает с портом, известным клиенту. Демон portmap сообщает клиенту номер порта службы, запрашиваемой клиентом. После этого клиент может направлять все свои запросы напрямую приложению.
Демон mountd - это демон сервера, отвечающий на запросы клиента на монтирование экспортированной файловой системы или каталога сервера. Демон mountd определяет доступные файловые системы, считывая информацию из файла /etc/xtab. Процесс монтирования происходит следующим образом:
Клиент соединяется с демоном portmap по запросу на монтирование только после повторного запуска системы. После того, как клиент узнает номер порта демона mountd, со всеми последующими запросами он будет обращаться непосредственно по этому порту.
Демон biod - это демон блочного ввода-вывода; он необходим для выполнения запросов на упреждающее чтение, отложенную запись и чтение каталогов. Демон biod повышает быстродействие NFS, заполняя или очищая кэш от имени пользователя NFS. Если пользователь клиентской системы создает запрос на запись или чтение файлов сервера, демон biod отправляет его запрос на сервер. Следующие операции NFS передаются серверу непосредственно из расширения ядра операционной системы клиента NFS и не проходят через демон biod:
До версии AIX 4.2.1 по умолчанию число демонов biod было равно шести и могло увеличиваться и уменьшаться по необходимости.
Демон nfsd - это активный агент, предоставляющий службы NFS с сервера NFS. Прием любого запроса по протоколу NFS происходит с помощью демона nfsd; он работает с этим запросом до завершения запроса и результаты его обработки отправлены обратно клиенту. До версии AIX 4.2.1 по умолчанию число демонов nfsd было равно восьми и могло увеличиваться и уменьшаться по необходимости.
NFS версии 3 была добавлена в AIX версии 4.2.1. Операционная система поддерживает NFS как версии 2, так и версии 3 на одном и том же компьютере.
До версии AIX 4.2.1, протокол UDP был единственным протоколом передачи пакетов NFS. В версии AIX 4.2.1 был добавлен дополнительный протокол TCP. Рекомендуется применять UDP в чистых и быстрых сетях и на быстрых серверах. В глобальных сетях, сетях с большой занятостью и на медленных серверах рекомендуется применять протокол TCP, так как применение в нем точного управления потоками уменьшает количество повторных передач.
NFS версии 3 улучшает производительность системы в следующих областях:
Приложения клиентской системы могут периодически записывать данные в файл, обновляя его содержимое. Интервал времени, в течение которого приложение ожидает завершения записи данных на сервер, и является мерой производительности записи глобальной файловой системы. Производительность записи существенно влияет на общую производительность. Все глобальные файловые системы, включая NFS, должны обеспечивать надежную запись данных в указанный файл, в то же время уменьшая время ожидания сервера.
В протоколе NFS версии 2 производительность записи можно было увеличить только путем отказа от синхронности. Версия 3 предусматривает и другой способ. В версии 3 достигается существенное сокращение числа запросов на запись, поступающих от клиента, за счет объединения запросов и последующей записи совокупных данных в кэш сервера, а не на диск. Затем серверу передается запрос на фиксацию данных, и данные переносятся на носитель. Эта функция, называемая также надежная асинхронная запись, существенно уменьшает количество запросов на ввод-вывод на сервере, тем самым сильно увеличивая производительность записи.
Операции записи считаются "надежными", поскольку отслеживается состояние данных, что позволяет убедиться в их записи на носитель. Таким образом, если сбой сервера происходит до операции фиксации, клиент узнает об этом с помощью индикатора состояния, указывающего на необходимость повторного запроса на запись.
Производительность последовательного чтения NFS измеряется на клиентском компьютере с помощью механизмов упреждающего чтения VMM и кэширования. Упреждающее чтение позволяет передавать клиенту данные файла с сервера NFS до того, как эти данные были запрошены приложением клиента NFS. К тому времени, как приложение создает запрос на данные, эти данные уже могут находиться в памяти клиентского компьютера и, следовательно, запрос будет выполнен немедленно. Кэширование VMM позволяет выполнять повторное чтение данных мгновенно, так как данные остаются в памяти клиентского компьютера, вследствие чего нет необходимости повторно получать их с сервера NFS.
Кроме того, при ограниченном объеме памяти клиентов, работе с очень большими файлами и/или медленными сетями для увеличения скорости чтения можно использовать Кэширующую файловую систему (см. Кэширующая файловая система , CacheFS), позволяющую сохранять ответы на запросы клиентов в кэше на локальном диске.
Поскольку считываемые данные иногда хранятся в кэше достаточно долго, они могут устареть, и клиентам приходится проверять их. Для этого клиент NFS периодически просматривает атрибуты файла, По дате последнего изменения клиент может проверить актуальность данных в кэше.
Уменьшение числа запросов к атрибутам файла повышает эффективность работы клиента, снижает нагрузку на сервер и повышает масштабируемость и производительность. Поэтому в NFS версии 3 атрибуты передаются при любой операции над файлом. Это увеличивает вероятность того, что информация в кэше окажется не устаревшей, и уменьшает число запросов на получение атрибутов.
В NFS версии 2 размер буфера не превышал 8 Кб, что ограничивало объем одновременно передаваемых данных NFS. В NFS версии 3 это ограничение было ослаблено. По умолчанию ввод-вывод выполняется блоками по 32 Кб, что позволяет NFS создавать и передавать блоки данных большего размера. Эта особенность позволяет NFS более эффективно использовать возможности высокопроизводительных сетей, например FDDI, 100baseT Ethernet, 1000baseT Ethernet и SP Switch, и существенно повышает производительность последовательного ввода-вывода.
Вывод полного списка содержимого каталога (например, командой ls -l) требует получения от сервера имен и атрибутов всех файлов. В NFS версии 2 клиенты отправляли серверу отдельный запрос на имя и атрибуты для каждого файла каталога. В NFS версии 3 список имен и атрибутов передается за одну операцию, что снижает нагрузку как на клиент, так и на сервер. Однако, в некоторых средах выполнение операции readdirplus() NFS версии 3 может привести к снижению производительности.
В AIX версии 4.2.1 были также изменены демоны nfsd, biod и rpc.lockd NFS версий 2 и 3. До версии 4.2.1, демоны nfsd и biod были процессами, требующими настройки числа запущенных экземпляров. Начиная с версии 4.2.1 демоны nfsd и biod представляют собой один многонитевый процесс. Новые нити создаются динамически по мере необходимости. Однако вы можете ограничить их максимальное число с помощью команды nfso, а также ограничить число нитей biod для каждого монтирования с помощью опций монтирования.
Демон rpc.lockd также стал многонитевым, что позволяет обрабатывать несколько запросов на блокирование одновременно.
До AIX версии 4.3 протоколом по умолчанию для NFS как версии 2, так и версии 3. Начиная с версии 4.3 протоколом по умолчанию для NFS версии 3 стал TCP, причем клиент может задавать транспортный протокол для каждой точки монтирования с помощью опции proto команды mount. Пример:
# mount -o proto=tcp