Понятие и использование Network File System

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

Введение

1 История Network File System

2 NFS сервер

2.1 Portmap и протокол RPC (Sun RPC)

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

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

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

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

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

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

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

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

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

5 Клиент NFS

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

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

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

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

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

Заключение

Список используемых источников

ВВЕДЕНИЕ

NFS (Network File System - сетевая файловая система) по моему мнению - идеальное решение в локальной сети, где необходим быстрый обмен данными и во главе угла не стоит безопасность передаваемой информации. Протокол NFS позволяет монтировать удалённые файловые системы через сеть в локальное дерево каталогов, как если бы это была примонтирована дисковая файловая система. Тем самым локальные приложения могут работать с удаленной файловой системой, как с локальной. Но нужно быть осторожным с настройкой NFS, иначе при определенной конфигурации можно подвесить операционную систему клиента в ожидании бесконечного ввода/вывода [1].

Цель курсовой работы - приобретение навыков по работе с Network File System.

Для достижения данной цели поставлены следующие задачи:

1. Изучить историю Network File System;

2. Изучить NFS сервер;

3. Научиться работать с протоколом Network File System;

4. Научиться управлять сервером NFS;

5. Изучить клиента NFS;

6. Изучить конфигурации NFS сервера и клиента.

1. История Network File System

Протокол NFS разработан компанией Sun Microsystems и имеет в своей истории 4 версии. NFSv1 была разработана в 1989 и являлась экспериментальной, работала на протоколе UDP. Версия 1 описана в RFC 1094. NFSv2 была выпущена в том же 1989 г., описывалась тем же RFC1094 и так же базировалась на протоколе UDP, при этом позволяла читать не более 2Гб из файла. NFSv3 доработана в 1995 г. и описана в RFC 1813. Основными нововведениями третьей версии стало поддержка файлов большого размера, добавлена поддержка протокола TCP и TCP-пакетов большого размера, что существенно ускорило работоспособность технологии. NFSv4 доработана в 2000 г. и описана в RFC 3010, в 2003 г. пересмотрена и описана в RFC 3530. Четвертая версия включила в себя улучшение производительности, поддержку различных средств аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов). NFS версии v4.1 была одобрена IESG в 2010 г., и получила номер RFC 5661. Важным нововведением версии 4.1, является спецификация pNFS -- Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые «облачные» («cloud») хранилища и информационные системы.

2. NFS сервер

Так как у нас NFS - это сетевая файловая система, то необходимо настроить сеть в Linux. Далее необходимо установить соответствующий пакет. В Debian это пакет nfs-kernel-server и nfs-common, в RedHat это пакет nfs-utils. А так же, необходимо разрешить запуск демона на необходимых уровнях выполнения ОС (команда в RedHat - /sbin/chkconfig nfs on, в Debian - /usr/sbin/update-rc.d nfs-kernel-server defaults).

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

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

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

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

· rpc.statd - Демон наблюдения за сетевым состоянием (он же Network Status Monitor (NSM)). Он позволяет корректно отменять блокировку после сбоя/перезагрузки. Для уведомления о сбое использует программу /usr/sbin/sm-notify. Демон statd работает как на серверах, так и на клиентах. Ранее данный сервер был необходим для работы rpc.lockd, но за блокировки сейчас отвечает ядро (прим: если я не ошибаюсь). (RPC программа 100021 и 100024 - в новых версиях)

· rpc.lockd - Демон блокировки lockd (он же NFS lock manager (NLM)) обрабатывает запросы на блокировку файлов. Демон блокировки работает как на серверах, так и на клиентах. Клиенты запрашивают блокировку файлов, а серверы ее разрешают. (устарел и в новых дистрибутивах не используется как демон. Его функции в современных дистрибутивах (с ядром старше 2.2.18) выполняются ядром, точнее модулем ядра (lockd). ) (RPC программа 100024)

· rpc.nfsd - Основной демон сервера NFS - nfsd (в новых версиях иногда называется nfsd4). Этот демон обслуживает запросы клиентов NFS. Параметр RPCNFSDCOUNT в файле /etc/default/nfs-kernel-server в Debian и NFSDCOUNT в файле /etc/sysconfig/nfs в RedHat определяет число запускаемых демонов (по-умолчанию - 8).(RPC программа 100003)

· rpc.mountd - Демон монтирования NFS mountd обрабатывает запросы клиентов на монтирование каталогов. Демон mountd работает на серверах NFS. (RPC программа 100005)

· rpc.idmapd - Демон idmapd для NFSv4 на сервере преобразует локальные uid/gid пользователей в формат вида имя@домен, а сервис на клиенте преобразует имена пользователей/групп вида имя@домен в локальные идентификаторы пользователя и группы (согласно конфигурационному файлу /etc/idmapd.conf, подробней в man idmapd.conf)

· дополнительно, в старых версиях NFS использовались демоны: nfslogd- демон журналов NFS фиксирует активность для экспортированных файловых систем, работает на серверах NFS и rquotad - сервер удаленных квот предоставляет информацию о квотах пользователей в удаленных файловых системах, может работать как на серверах, так и на клиентах.(RPC программа 100011)

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

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

· rpc.svcgssd - Демон сервера NFSv4, который обеспечивает проверку подлинности клиента на стороне сервера.

2.1 рortmap и протокол RPC (Sun RPC)

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

Коротко говоря, работа сервера RPC (Remote Procedure Call) заключается в обработке RPC-вызовов (т.н. RPC-процедур) от локальных и удаленных процессов. Используя RPC-вызовы, сервисы регистрируют или удаляют себя в/из преобразователя портов (он же отображатель портов, он же portmap, он же portmapper, он же, в новых версиях, rpcbind), а клиенты, с помощью RPC-вызовов направляя запросы к portmapper, получают необходимую информацию. Юзер-френдли названия сервисов программ и соответствующие им номера определены в файле /etc/rpc. Как только какой-либо сервис отправил соответствующий запрос и зарегистрировал себя на сервере RPC в отображателе портов, RPC-сервер сопоставляет сервису TCP и UDP порты на которых запустился сервис и хранит в ядре соответствующую информацию о работающем сервисе (об имени), уникальном номере сервиса (в соответствии с /etc/rpc) , о протоколе и порте на котором работает сервис и о версии сервиса и предоставляет указанную информацию клиентам по запросу. Сам преобразователь портов имеет номер программы (100000), номер версии - 2, TCP порт 111 и UDP порт 111. Выше, при указании состава демонов сервера NFS указаны основные RPC номера программ. Основная функция отображателя портов заключается в том, чтобы по запросу клиента, который предоставил номер RPC-программы (или RPC-номер программы) и версию, вернуть ему (клиенту) порт, на котором работает запрошенная программа. Соответственно, если клиенту нужно обратиться к RPC с конкретным номером программы, он сначала должен войти в контакт с процессом portmap на серверной машине и определить номер порта связи с необходимым ему сервисом RPC.

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

1. Преобразователь портов должен стартовать первым, обычно при загрузке системы. При этом создается конечная точка TCP и осуществляется открытие TCP порта 111. Также создается конечная точка UDP, которая находится в ожидании, когда на UDP порт 111 прибудет UDP датаграмма.

2. При старте программа, работающая через сервер RPC, создает конечную точку TCP и конечную точку UDP для каждой поддерживаемой версии программы. (Сервер RPC может поддерживать несколько версий. Клиент указывает требуемую версию при посылке RPC-вызова.) Динамически назначаемый номер порта закрепляется за каждой версией сервиса. Сервер регистрирует каждую программу, версию, протокол и номер порта, осуществляя соответствующий RPC-вызов.

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

4. В ответ на этот запрос север возвращает номер порта.

5. Клиент отправляет сообщение RPC-запрос на номер порта, полученный в пункте 4. Если используется UDP, клиент просто посылает UDP датаграмму, содержащую сообщение RPC-вызова , на номер UDP порта, на котором работает запрошенный сервис. В ответ сервис отправляет UDP датаграмму, содержащую сообщение RPC отклика. Если используется TCP, клиент осуществляет активное открытие на номер TCP порта требуемого сервиса и затем посылает сообщение вызова RPC по установленному соединению. Сервер отвечает сообщением отклика RPC по соединению.

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

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

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

удаленный каталог сервер клиент

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

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

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

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

1. На сервере и клиенте запускается RPC сервер (обычно при загрузке), обслуживанием которого занимается процесс portmapper и регистрируется на порту tcp/111 и udp/111.

2. Запускаются сервисы (rpc.nfsd,rpc.statd и др.), которые регистрируются на RPC сервере и регистрируются на произвольных сетевых портах (если в настройках сервиса не задан статичный порт).

3. Команда mount на компьютере клиента отправляет ядру запрос на монтирование сетевого каталога с указанием типа файловой системы, хоста и собственно - каталога, ядро отправляет формирует RPC-запрос процессу portmap на NFS сервере на порт udp/111 (если на клиенте не задана опция работать через tcp)

4. Ядро сервера NFS опрашивает RPC о наличии демона rpc.mountd и возвращает ядру клиента сетевой порт, на котором работает демон.

5. mount отправляет RPC запрос на порт, на котором работает rpc.mountd. Теперь NFS сервер может проверить достоверность клиента основываясь на его IP адресе и номере порта, чтобы убедиться, можно ли этому клиенту смонтировать указанную файловую систему.

6. Демон монтирования возвращает описание запрошенной файловой системы.

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

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

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

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

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

Модуль ядра kernel/fs/nfs/nfs.ko, который выполняет функции NFS клиента, отправляет RPC запросы NFS серверу через модуль TCP/IP. NFS обычно использует UDP, однако более новые реализации могут использовать TCP.

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

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

Результат обращения диску возвращается клиенту.

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

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

· /etc/exports - основной конфигурационный файл, хранящий в себе конфигурацию экспортированных каталогов. Используется при запуске NFS и утилитой exportfs.

· /var/lib/nfs/xtab - содержит список каталогов, монтированных удаленными клиентами. Используется демоном rpc.mountd, когда клиент пытается смонтировать иерархию (создается запись о монтировании).

· /var/lib/nfs/etab - список каталогов, которые могут быть смонтированы удаленными системами с указанием всех параметров экспортированных каталогов.

· /var/lib/nfs/rmtab - список каталогов, которые не разэкспортированы в данный момент.

· /proc/fs/nfsd - специальная файловая система (ядро 2.6) для управления NFS сервером.

-exports - список активных экспортированных иерархий и клиентов, которым их экспортировали, а также параметры. Ядро получает данную информацию из /var/lib/nfs/xtab.

-threads - содержит число потоков (также можно изменять)

-с помощью filehandle можно получить указатель на файл

· /proc/net/rpc - содержит "сырую" (raw) статистику, которую можно получить с помощью nfsstat, а также различные кеши.

· /var/run/portmap_mapping - информация о зарегистрированных в RPC сервисах

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

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

· Какие клиенты могут обращаться к файлам на сервере

· К каким иерархиям каталогов на сервере может обращаться каждый клиент

· Как пользовательские имена клиентов будут отображаться на локальные имена пользователей

Каждая строка файла exports имеет следующий формат

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

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

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

подсети 10.0.230.1/24 доступ только на чтение.

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

· Имена отдельных узлов описываются, как files или files.DOMAIN.local.

· Описание маски доменов производится в следующем формате: *DOMAIN.local включает все узлы домена DOMAIN.local.

· Подсети задаются в виде пар адрес IP/маска. Например: 10.0.0.0/255.255.255.0 включает все узлы, адреса которых начинаются с 10.0.0.

· Задание имени сетевой группы @myclients имеющей доступ к ресурсу (при использовании сервера NIS).

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

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

· auth_nlm (no_auth_nlm) или secure_locks (insecure_locks) - указывает, что сервер должен требовать аутентификацию запросов на блокировку (с помощью протокола NFS Lock Manager (диспетчер блокировок NFS)).

· nohide (hide) - если сервер экспортирует две иерархии каталогов, при этом одна вложена в другую. Клиенту необходимо явно смонтировать вторую (дочернюю) иерархию, иначе точка монтирования дочерней иерархии будет выглядеть как пустой каталог. Опция nohide приводит к появлению второй иерархии каталогов без явного монтирования. (прим: я данную опцию так и не смог заставить работать... )

· ro (rw) - Разрешает только запросы на чтение (запись). (В конечном счете - возможно, прочитать/записать или нет, определяется на основании прав файловой системы, при этом сервер не способен отличить запрос на чтение файла от запроса на исполнение, поэтому разрешает чтение, если у пользователя есть права на чтение или исполнение.)

· secure (insecure) - требует, чтобы запросы NFS поступали с защищенных портов (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.

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

· sync (async) - указывает, что сервер должен отвечать на запросы только после записи на диск изменений, выполненных этими запросами. Опция async указывает серверу не ждать записи информации на диск, что повышает производительность, но понижает надежность, т.к. в случае обрыва соединения или отказа оборудования возможна потеря информации.

· wdelay (no_wdelay) - указывает серверу задерживать выполнение запросов на запись, если ожидается последующий запрос на запись, записывая данные более большими блоками. Это повышает производительность при отправке больших очередей команд на запись. no_wdelay указывает не откладывать выполнение команды на запись, что может быть полезно, если сервер получает большое количество команд не связанных друг с другом.

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

· в клиентской файловой системе должен существовать объект ссылки

· необходимо экспортировать и смонтировать объект ссылки

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

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

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

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

· nfsstat

· showmsecure (insecure)ount

· exportfs

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

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

showmount: вывод информации о состоянии NFS

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

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

· --directories - выдаётся список точек монтирования

· --exports - выдаётся список экспортируемых файловых систем с точки зрения nfsd

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

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

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

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

Параметры exportfs:

[клиент:имя-каталога] - добавить или удалить указанную файловую систему для указанного клиента)

· -v - выводить больше информации

· -r - переэкспортировать все каталоги (синхронизировать /etc/exports и /var/lib/nfs/xtab)

· -u - удалить из списка экспортируемых

· -a - добавить или удалить все файловые системы

· -o - опции через запятую (аналогичен опциям применяемым в /etc/exports; т.о. можно изменять опции уже смонтированных файловых систем)

· -i - не использовать /etc/exports при добавлении, только параметры текущей командной строки

· -f - сбросить список экспортируемых систем в ядре 2.6.

5. Клиент NFS

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

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

· вручную, с помощью команды mount

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

· автоматически с помощью демона autofs

Третий способ с autofs в данной статье я рассматривать не буду, ввиду его объемной информации. Возможно в следующих статьях будет отдельное описание.

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

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

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

· nosuid - Данная опция запрещает исполнять setuid программы из смонтированного каталога.

· nodev (no device - не устройство) - Данная опция запрещает использовать в качестве устройств символьные и блочные специальные файлы.

· lock (nolock) - Разрешает блокировку NFS (по умолчанию). nolock отключает блокировку NFS (не запускает демон lockd) и удобна при работе со старыми серверами, не поддерживающими блокировку NFS.

· mounthost=имя - Имя хоста, на котором запущен демон монтирования NFS - mountd.

· mountport=n - Порт, используемый демоном mountd.

· port=n - порт, используемый для подключения к NFS серверу (по умолчанию 2049, если демон rpc.nfsd не зарегистрирован на RPC-сервере). Если n=0 (по умолчанию), то NFS посылает запрос к portmap на сервере, чтобы определить порт.

· rsize=n (read block size - размер блока чтения) - Количество байтов, читаемых за один раз с NFS-сервера. Стандартно - 4096.

· wsize=n (write block size - размер блока записи) - Количество байтов, записываемых за один раз на NFS-сервер. Стандартно - 4096.

· tcp или udp - Для монтирования NFS использовать протокол TCP или UDP соответственно.

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

· fg - При потери доступа к серверу, повторять попытки в приоритетном режиме. Данный параметр может заблокировать процесс загрузки системы повторениями попыток монтирования. По этой причине параметр fg используется преимущественно при отладке.

Опции, влияющие на кэширование атрибутов при монтировании NFS

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

· ac (noac) (attrebute cache - кэширование атрибутов) - Разрешает кэширование атрибутов (по-умолчанию). Хотя опция noac замедляет работу сервера, она позволяет избежать устаревания атрибутов, когда несколько клиентов активно записывают информацию в общию иерархию.

· acdirmax=n (attribute cache directory file maximum - кэширование атрибута максимум для файла каталога) - Максимальное количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 60 сек.)

· acdirmin=n (attribute cache directory file minimum - кэширование атрибута минимум для файла каталога) - Минимальное количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 30 сек.)

· acregmax=n (attribute cache regular file maximum - кэширование атрибута максимум для обычного файла) - Максимаьное количество секунд, которое NFS ожидает до обновления атрибутов обычного файла (по-умолчанию 60 сек.)

· acregmin=n (attribute cache regular file minimum- кэширование атрибута минимум для обычного файла) - Минимальное количество секунд, которое NFS ожидает до обновления атрибутов обычного файла (по-умолчанию 3 сек.)

· actimeo=n (attribute cache timeout - таймаут кэширования атрибутов) - Заменяет значения для всех вышуказаных опций. Если actimeo не задан, то вышеуказанные значения принимают значения по умолчанию.

Опции обработки ошибок NFS

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

· fg (bg) (foreground - передний план, background - задний план) - Производить попытки монтирования отказавшей NFS на переднем плане/в фоне.

· hard (soft) - выводит на консоль сообщение "server not responding" при достижении таймаута и продолжает попытки монтирования. При заданной опции soft - при таймауте сообщает вызвавшей операцию программе об ошибке ввода/вывода. (опцию soft советуют не использовать)

· nointr (intr) (no interrupt - не прерывать) - Не разрешает сигналам прерывать файловые операции в жестко смонтированной иерархии каталогов при достижении большого таймаута. intr - разрешает прерывание.

· retrans=n (retransmission value - значение повторной передачи) - После n малых таймаутов NFS генерирует большой таймаут (по-умолчанию 3). Большой таймаут прекращает выполнение операций или выводит на консоль сообщение "server not responding", в зависимости от указания опции hard/soft.

· retry=n (retry value - значение повторно попытки) - Количество минут повторений службы NFS операций монтирования, прежде чем сдаться (по-умолчанию 10000).

· timeo=n (timeout value - значение таймаута) - Количество десятых долей секунды ожидания службой NFS до повторной передачи в случае RPC или малого таймаута (по-умолчанию 7). Это значение увеличивается при каждом таймауте до максимального значения 60 секунд или до наступления большого таймаута. В случае занятой сети, медленного сервера или при прохождении запроса через несколько маршрутизаторов или шлюзов увеличение этого значения может повысить производительность.

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

В текущем примере я рассмотрю несколько примеров монтирования файловых систем NFS с описанием опций

Первый пример монтирует файловую систему /archiv-small с хоста archiv в точку монтирования /archivs/archiv-small, тип файловой системы указан nfs (всегда необходимо указывать для данного типа), файловая система монтирована с опцией для чтения, записи (rw). Хост archiv подключен по быстрому локальному каналу, поэтому для повышения производительности параметр timeo уменьшен и существенно увеличены значения rsize и wsize. Поля для программ dump и fsck заданы в ноль, чтобы данные программы не использовали файловую систему, примонтированную по NFS. Второй пример монтирует файловую систему /archiv-big с хоста nfs-server. Т.к. к хосту nfs-server мы подключены по медленному соединению, параметр timeo увеличен до 5 сек (50 десятых долей сек), а так же жестко задан параметр hard, чтобы NFS продолжала перемонтировать файловую систему после большого таймаута, так же задан параметр fg, чтобы при загрузке системы и недоступности хоста nfs-server не произошло зависания.

6. Конфигурации NFS сервера и клиента

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

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

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

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

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

Заключение

NFS абстрагирована от типов файловых систем, как сервера, так и клиента, существует множество реализаций NFS-серверов и клиентов для различных операционных систем и аппаратных архитектур. В настоящее время используется наиболее зрелая версия NFS v.4 (RFC 3010,RFC 3530), поддерживающая различные средства аутентификации и списков контроля доступа.

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

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

Все поставленные задачи в ходе работы были выполнены, цель достигнута.

Основным методом исследования был анализ литературных источников.

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1. В.Костромин, Linux для пользователя: Самоучитель: Изд-во «БХВ-Петербург», 2002

2. Д. Н. Колисниченко, Питер В. Аллен, Linux: полное руководство - Изд. Наука и техника; 2005. - 784 с.

3. Эви Немет, Гарт Снайдер, Трент Хейн, Бэн Уэйли, Unix и Linux. Руководство системного администратора: 4 - е издание, Изд. Вильямс, 2012.

4. Владислав Маслаков, . Linux на 100%. - Питер. 2009. - 352 с.

5. Кристофер Негус, Франсуа Каэн, Ubuntu и Debian Linux для продвинутых. Более 1000 незаменимых команд. -Питер. 2010. - 464 с.

6. К. В. Голобродский, Знакомьтесь: Ubuntu [Электронный ресурс]- Изд. Феникс, 2010. - 255 с. - Режим доступа: http://www.knigafund.ru/books/424707.

7. NFS [Электронный ресурс]: Википедия - Режим доступа: http://ru.wikipedia.org/wiki/NFS

8. Войтов Н. М., Основы работы с Linux. Учебный курс- 3-е изд., Изд. - ДМК Пресс, 2011. - 263 с.: ил.

9. Морис Дж. Бах, Архитектура операционной системы UNIX: Изд-во Prentice-Hall, 1995. - 153 с. - 100 экз.

10. TCP/IP крупным планом [Электронный ресурс]: учебник / Режим доступа: http://www.soslan.ru/tcp/tcp29.html

Размещено на Allbest.ur