Nfs скорость передачи данных. Network File System (NFS) - сетевая файловая система

» и уже имеешь представление о «сетевой файловой системе», ее возможностях и степени защищенности. Однако в указанной статье все разбиралось в основном с точки зрения клиента… а вот как быть если тебе захотелось поиметь собственный NFS-сервер? (прим.: «поиметь» не значит «сломать», а значит «установить и настроить»).

Ну, а если желание такое у тебя появилось, то первый вопрос, который ты должен задать себе: «А нафига козе баян?». Ибо ставить NFS-сервер у себя дома
довольно бессмысленно — никто не оценит, а вот если тебе посчастливилось админить в конторе «людей в черном», или в новомодной «ДОМашней сети» — тогда совсем другое дело…

Запустить сам сервер дело довольно нехитрое, если ты читал предыдущую статью, то вполне с этим справишься. Итак, тебе понадобятся следующие демоны:

  • nfsd — непосредственное обслуживание протокола
    NFS;
  • mountd — обслуживание операций монтирования;
  • rpc.portmap — демон портов RPC; нужен поскольку запросы к NFS-серверу передаются в виде пакетов
    RPC;

Как это сделать? Очень просто — сходи в файл «/etc/rc.d/rc.inet2» и раскомментируй соответствующие строки. Все можно считать, что первичный запуск произведен, немного сложнее будет все это настроить…
Первое, что нужно решить — это кто и какие права имеет относительно той или иной информации. Это настраивается посредством файла «/etc/exports». Разрешения бывают «на чтение» и «на чтение и запись». Как это настраивается, описано в «Основах
NFS».

Второе — это конечно же нагрузка на сервер, т.е. количество активных пользователей и их примерные запросы. Запросы к NFS-серверу обычно делят на два типа: первый — когда клиент работает с атрибутами, второй — когда клиент запрашивает непосредственно данные. Запросы первого типа — это поиск файла, считывание списка разрешений и т.д., конечно, ты понимаешь, что они слабо нагружают сеть. Запросы второго типа — это передача и прием от клиента непосредственно содержимого файлов; и именно здесь встает вопрос: «что и как часто будет передаваться?» Этот особенно актуален, если у тебя сеть в 10 Мбит/сек (ну проще говоря — стандартная российская сеть). Если ты знаешь, то 10 Мбит/сек — это чуть больше 1 Мбайта в секунду; естественно, если постоянно будут передаваться файлы размером в десятки мегабайт, то сеть попросту умрет. Если твоя ситуация именно такова, то тебе понадобится установит кэширование данных на клиентской машине (демон biod). Тогда, однажды затребовав какой либо файл и обратившись к нему повторно, клиент не будет «качать» его заново с сервера, а возьмет у себя из кэша; при этом будет регулярно проверяться не изменился ли файл на сервере, если же факт изменения будет выявлен, то файл в кэше будет заменен «свежей версией»
(как ты понимаешь, проверка «изменился ли файл» — это запрос «по атрибутам», который зачастую в сотни раз меньше, чем сам файл).

Ну что ж: NFS-сервер мы запустили, разрешения на доступ определили, с нагрузкой разобрались… Теперь осталось забить винт необходимой инфой и пользоваться
возможностями NFS на полную катушку…

Вместо заключения:

Если перед тобой стоит вопрос организации обмена данными в сети, то не раздумывая выбирай NFS — NFS на три головы выше головы выше, чем
FTP и на голову выше виндовых «шаров», а в настройке не так уж и сложна…

Network file system (NFS) - протокол сетевого доступа к файловым системам, позволяет подключать удалённые файловые системы.
Первоначально разработан Sun Microsystems в 1984 г. Основой является Sun RPC: вызов удаленной процедуры (Remote Procedure Call). NFS независим от типов файловых систем сервера и клиента. Существует множество реализаций NFS-серверов и клиентов для различных ОС. В настоящее время используется версия NFS v.4, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).
NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера. В отличие от FTP, протокол NFS осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство его в том, что он делает этот доступ прозрачным. Благодаря этому любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без изменений самой программы.
NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC-запросов на сервер. Это может быть реализовано с использованием обычных пользовательских процессов - а именно, NFS клиент может быть пользовательским процессом, который осуществляет конкретные RPC вызовы на сервер, который так же может быть пользовательским процессом.

Версии
NFSv1 была только для внутреннего пользования в экспериментальных целях. Детали реализации определены в RFC 1094.
NFSv2 (RFC 1094, март 1989 года) первоначально полностью работала по протоколу UDP.
NFSv3 (RFC 1813, июнь 1995 года). Описатели файлов в версии 2 - это массив фиксированного размера - 32 байта. В версии 3 - это массив переменного размера с размером до 64 байт. Массив переменной длины в XDR определяется 4-байтным счётчиком, за которым следуют реальные байты. Это уменьшает размер описателя файла в таких реализациях, как, например, UNIX, где требуется всего около 12 байт, однако позволяет не-Unix реализациям обмениваться дополнительной информацией.
Версия 2 ограничивает количество байт на процедуры READ или WRITE RPC размером 8192 байта. Это ограничение не действует в версии 3, что, в свою очередь, означает, что с использованием UDP ограничение будет только в размере IP датаграммы (65535 байт). Это позволяет использовать большие пакеты при чтении и записи в быстрых сетях.
Размеры файлов и начальное смещение в байтах для процедур READ и WRITE стали использовать 64-битную адресацию вместо 32-битной, что позволяет работать с файлами большего размера.
Атрибуты файла возвращаются в каждом вызове, который может повлиять на атрибуты.
Записи (WRITE) могут быть асинхронными, тогда как в версии 2 они должны были быть синхронными.
Одна процедура была удалена (STATFS) и семь были добавлены: ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1 информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение).
На момент введения версии 3, разработчики стали больше использовать TCP как транспортный протокол. Хотя некоторые разработчики уже Использовали протокол TCP для NFSv2, Sun Microsystems добавили поддержку TCP в NFS версии 3. Это сделало использование NFS через Интернет более осуществимым.
NFSv4 (RFC 3010, декабрь 2000 г., RFC 3530, пересмотренная в апреле 2003), под влиянием AFS и CIFS, включила в себя улучшение производительности, высокую безопасность, и предстала полноценным протоколом. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF), после того, как Sun Microsystems передала развитие протоколов NFS. NFS версии v4.1 была одобрена IESG в январе 2010 года, и получила номер RFC 5661. Важным нововведением версии 4.1 является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые "облачные" ("cloud") хранилища и информационные системы.

Структура NFS
Структура NFS включает три компонента разного уровня:
Прикладной уровень (собственно NFS) - это вызовы удаленных процедур (rpc), которые и выполняют необходимые операции с файлами и каталогами на стороне сервера.
Функции уровня представления выполняет протокол XDR (eXternal Data Representation), который является межплатформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую, форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
Сервис RPC (Remote Procedure Call), обеспечивающий запрос удаленных процедур клиентом и их выполнение на сервере, представляет функции сеансового уровня.Подключение сетевых ресурсов
Процедура подключения сетевого ресурса средствами NFS называется "экспортированием". Клиент может запросить у сервера список представляемых им экспортируемых ресурсов. Сам сервер NFS не занимается широковещательной рассылкой списка своих экспортируемых ресурсов.
В зависимости от заданных опций, экспортируемый ресурс может быть смонтирован (присоединён) "только для чтения", можно определить список хостов, которым разрешено монтирование, указать использование защищенного RPC (secureRPC) и пр. Одна из опций определяет способ монтирования: "жесткое" (hard) или "мягкое" (soft).
При "жестком" монтировании клиент будет пытаться смонтировать файловую систему во что бы то ни стало. Если сервер не работает, это приведет к тому, что весь сервис NFS как бы зависнет: процессы, обращающиеся к файловой системе, перейдут в состояние ожидания окончания выполнения запросов RPC. С точки зрения пользовательских процессов файловая система будет выглядеть как очень медленный локальный диск. При возврате сервера в рабочее состояние сервис NFS продолжит функционирование.
При "мягком" монтировании клиент NFS сделает несколько попыток подключиться к серверу. Если сервер не откликается, то система выдает сообщение об ошибке и прекращает попытки произвести монтирование. С точки зрения логики файловых операций при отказе сервера "мягкое" монтирование эмулирует сбой локального диска.
Выбор режима зависит от ситуации. Если данные на клиенте и сервере должны быть синхронизированы при временном отказе сервиса, то "жесткое" монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах "только для чтения", режим "мягкого" монтирования представляется более удобным.

Общий доступ в смешанной сети
Сервис NFS идеально подходит для сетей на основе UNIX, так как поставляется с большинством версий этой операционной системы. Более того, поддержка NFS реализована на уровне ядра UNIX. Использование NFS на клиентских компьютерах с Windows создает определенные проблемы, связанные с необходимостью установки специализированного и довольно дорогого клиентского ПО. В таких сетях использование средств разделения ресурсов на основе протокола SMB/CIFS, в частности ПО Samba, выглядит более предпочтительным.

Стандарты
RFC 1094 NFS: Network File System Protocol Specification] (March 1989)
RFC 1813 NFS Version 3 Protocol Specification] (June 1995)
RFC 2224 NFS URL Scheme
RFC 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols
RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5
RFC 2624 NFS Version 4 Design Considerations
RFC 3010 NFS version 4 Protocol
RFC 3530 Network File System (NFS) version 4 Protocol
RFC 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol

Используемые источники
1. ru.wikipedia.org
2. ru.science.wikia.com
3. phone16.ru
4. 4stud.info
5. yandex.ru
6. gogle.com

Каждый знает, что в UNIX-системах файловая система логически представляет собой набор физических файловых систем, подключенных к одной точке. Одна из самых основных прелестей такой организации, на мой взгляд, состоит в возможности динамически модифицировать структуру существующей файловой системы. Также, благодаря усилиям разработчиков, мы на сегодняшний день имеем возможность подключить ФС практически любого типа и любым удобным способом. Говоря «способом», я прежде всего хочу подчеркнуть возможность работы ядра ОС с файловыми системами посредством сетевых соединений.

Множество сетевых протоколов предоставляют нам возможность работы с удаленными файлами, будь то FTP, SMB, Telnet или SSH. Благодаря способности ядра, в конечном итоге, не зависеть от типа подключаемой ФС, мы имеем возможность при помощи программы mount подключать что угодно и как угодно.

Сегодня мне хочется рассказать об NFS — Network File System. Эта технология позволяет подключать отдельные точки ФС на удаленном компьютере к файловой системе локального компьютера. Сам протокол NFS позволяет выполнять операции с файлами достаточно быстро, безопасно и надежно. А что нам еще нужно? :-)

Что необходимо для того, чтобы это работало

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

Установка

Для запуска сервера NFS в моей Ubuntu 7.10 — the Gutsy Gibbon понадобилось установить пакеты nfs-common и nfs-kernel-server. Если же нужен только клиент NFS, то nfs-kernel-server устанавливать не нужно.

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

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

/etc/init.d/nfs-kernel-server status

Если демон не запущен, его нужно запустить командой

/etc/init.d/nfs-kernel-server start

После того, как все успешно запустилось, можно приступать к экспорту файловой системы. Сам процесс очень прост и занимает минимум времени.

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

Directory machine1(option11,option12) machine2(option21,option22)

directory — абсолютный путь к каталогу ФС сервера, к которому нужно дать доступ

machineX — DNS-имя или IP-адрес клиентского компьютера, с которого разрешается доступ

optionXX — параметры экспорта ФС, наиболее часто используемые из них:

  • ro — доступ к файлам разрешается только для чтения
  • rw — доступ предоставляется на чтение/запись
  • no_root_squash — по умолчанию, если вы подключаетесь к ресурсу NFS от имени root, сервер, безопасности ради, на своей стороне будет обращаться к файлам от имени пользователя nobody. Однако, если включить эту опцию, то обращение к файлам на стороне сервера будет будет производиться от имени root. Аккуратней с этой опцией.
  • no_subtree_check — по умолчанию, если вы на сервере экспортируете не весь раздел, а только часть ФС, демон будет проверять, является ли запрошенный файл физически размещенным на том же разделе или нет. В случае, если вы экспортируете весь раздел или точка подключения экспортируемой ФС не затрагивает файлы с других физических томов, то можно включить эту опцию. Это даст вам увеличение скорости работы сервера.
  • sync — включайте эту опцию, если есть вероятность внезапного обрыва связи или отключения питания сервера. Если эта опция не включена, то очень повышается риск потери данных при внезапной остановке сервера NFS.

Итак, допустим, нам нужно дать доступ компьютеру ashep-desktop к каталогу /var/backups компьютера ashep-laptop. Доступ к каталогу необходим для копирования резервных копий файлов с ashep-desktop. У меня файл получился следующим:

/var/backups ashep-desktop(rw,no_subtree_check,sync)

После добавления строки в /etc/exports необходимо перезапустить сервер NFS для вступления изменений в силу.

/etc/init.d/nfs-kernel-server restart

Вот и все. Можно приступать к подключению экспортированной ФС на клиентском компьютере.

Настройка клиента

На клиентской стороне удаленная файловая система монтируется так же, как и все остальные — командой mount. Также, никто не запрещает вам использовать /etc/fstab в случае, если подключать ФС нужно автоматически при загрузке ОС. Итак, вариант с mount будет выглядеть так:

Mount -t nfs ashep-laptop:/var/backups/ /mnt/ashep-laptop/backups/

Если все прошло успешно и вам необходимо выполнять подключение к удаленной ФС автоматически при загрузке — просто добавляем строку в /etc/fstab:

Ashep-laptop:/var/backups /mnt/ashep-laptop/backups nfs auto 0 0

Что еще

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

#image.jpgНеплохого времени, читатели и гости моего блога. Очень большой перерыв меж постами был, но я снова в бою). В сегодняшней статье рассмотрю работу протокола NFS , а так же настройку сервера NFS и клиента NFS на Linux .

Введение в NFS

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

Тем локальные приложения могут работать с удаленной файловой системой, как с локальной. Но нужно быть осторожным (!) с настройкой NFS , ибо при определенной конфигурации можно подвесить операционную систему клиента в ожидании бесконечного ввода/вывода.

Протокол NFS основан на работе протокола RPC , который пока не поддается моему пониманию)) поэтому материал в статье будет малость расплывчат... Прежде, чем Вы сможете использовать NFS, будь это сервер или клиент, Вы должны удостовериться, что Ваше ядро имеет поддержку файловой системы NFS. Проверить поддерживает ли ядро файловую систему NFS можно, просмотрев наличие соответствующих строк в файле /proc/filesystems:

ARCHIV ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd

Если обозначенных строк в файле /proc/filesystems не окажется, то необходимо установить описанные ниже пакеты. Это скорее всего дозволит установить зависимые модули ядра для поддержки подходящих файловых систем.

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

История Network File System

Протокол NFS разработан компанией Sun Microsystems и имеет в своей истории Четыре версии. NFSv1 была разработана в Одна тыща девятьсот восемьдесят девять и являлась экспериментальной, работала на протоколе UDP. Версия Один описана в RFC 1094.

NFSv2 была выпущена в том же Одна тыща девятьсот восемьдесят девять г., описывалась тем же RFC1094 и так же базировалась на протоколе UDP, при всем этом позволяла читать наименее 2Гб из файла. NFSv3 доработана в Одна тыща девятьсот девяносто 5 г. и описана в RFC 1813.

Основными нововведениями третьей версии стало поддержка файлов большого размера, добавлена поддержка протокола TCP и TCP-пакетов большущего размера, что существенно ускорило работоспосбоность технологии. NFSv4 доработана в Две тыщи г. и описана в RFC 3010, в Две тыщи три г. пересмотрена и описана в RFC 3530.

4-ая версия включила в себя улучшение производительности, поддержку различных средств аутентификации (а конкретно, Kerberos и LIPKEY с внедрением протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов). NFS версии v4.1 была одобрена IESG в Две тыщи 10 г., и получила номер RFC 5661.

Принципным нововведением версии 4.1, является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в образце сетевой файловой системы поможет строить распределённые «облачные» («cloud») хранилища и информационные системы.

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 запускается в следующем порядке:

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx Один root root 20 Окт Восемнадцать 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx Один root root 20 семь Окт 20 два 01:23 S16nfs-kernel-server -> ../init.d/nfs-kernel-server

Другими словами, сначала запускается nfs-common , позже сам сервер nfs-kernel-server .

В RedHat ситуация схожая, за тем только исключением, что 1-ый скрипт называется 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 (В Debian я почему-то не нашел инфы об этом демоне и о причинах его отсутствия, видимо удален...).

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

  • rpc.statd - Бес наблюдения за сетевым состоянием (он же Network Status Monitor, он же NSM). Он позволяет корректно отменять блокировку после сбоя/перезагрузки. Для уведомления о нарушении употребляет программу /usr/sbin/sm-notify. Бес statd работает как на серверах, так и на клиентах. Ранее данный сервер был нужен для работы rpc.lockd, но за блокировки сейчас отвечает ядро (прим: если я не ошибаюсь #image.jpg). (RPC программа 100 тыщ 20 один и 100 тыщ 20 четыре - в новых версиях)
  • 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, который обеспечивает проверку подлинности клиента на стороне сервера.

portmap и протокол 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 порт 100 одиннадцать и UDP порт 111.

Выше, при указании состава бесов сервера NFS я указал главные RPC номера программ. Я, наверняка, малость запутал Вас данным абзацем, поэтому произнесу основную фразу, которая должна внести ясность: основная функция отображателя портов заключается в том, чтобы по запросу клиента, который предоставил номер RPC-программы (или RPC-номер программы) и версию, вернуть ему (клиенту) порт, на котором работает запрошенная программа . Соответственно, если клиенту нужно обратиться к RPC с определенным номером программы, он сначала должен войти в контакт с процессом portmap на серверной машине и отыскать номер порта связи с необходимым ему обслуживанием RPC.

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

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

ARCHIV ~ # rpcinfo -p прог-ма верс прото порт 100 тыщ Два tcp 100 одиннадцать portmapper 100 тыщ Два udp 100 одиннадцать portmapper 100 тыщ 20 четыре Один udp 50 девять тыщ четыреста 50 один status 100 тыщ 20 четыре Один tcp Шестьдесят тыщ восемьсот 70 два status 100 тыщ 20 один Один udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Три udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Четыре udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Один tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ 20 один Три tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ 20 один Четыре tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ три Два tcp Две тыщи 40 девять nfs 100 тыщ три Три tcp Две тыщи 40 девять nfs 100 тыщ три Четыре tcp Две тыщи 40 девять nfs 100 тыщ три Два udp Две тыщи 40 девять nfs 100 тыщ три Три udp Две тыщи 40 девять nfs 100 тыщ три Четыре udp Две тыщи 40 девять nfs 100 тыщ 5 Один udp 50 одна тыща триста 6 mountd 100 тыщ 5 Один tcp 40 одна тыща четыреста 5 mountd 100 тыщ 5 Два udp 50 одна тыща триста 6 mountd 100 тыщ 5 Два tcp 40 одна тыща четыреста 5 mountd 100 тыщ 5 Три udp 50 одна тыща триста 6 mountd 100 тыщ 5 Три tcp 40 одна тыща четыреста 5 mountd

Как видно, rpcinfo указывает (в столбиках слева на право) номер зарегистрированной программы, версию, протокол, порт и название.

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

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

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

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

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

Описание протокола 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 клиента, и с этого момента хоть какое обращение пользовательских процессов к файлам на файловой системе сервера будет использовать описатель файла как стартовую точку.

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

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

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

Настройка сервера 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 сервисах

Прим: вообще, в интернете куча трактовок и формулировок назначения файлов xtab, etab, rmtab, кому верить - не знаю #image.jpg Даже на http://nfs.sourceforge.net/ трактовка не однозначна.

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

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

  • Какие клиенты могут обращаться к файлам на сервере
  • К каким иерархиям каталогов на сервере может обращаться каждый клиент
  • Как пользовательские имена клиентов будут отображаться на локальные имена юзеров

Неважно какая строка файла exports имеет следующий формат:

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

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

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

ARCHIV ~ # cat /etc/exports /archiv1 files(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

В данном примере компьютерам files и 10.0.0.1 разрешен доступ к точке экспорта /archiv1, при всем этом, хосту files на чтение/запись, а для хоста 10.0.0.1 и подсети 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)

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

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

  • auth_nlm (no_auth_nlm) или secure_locks (insecure_locks) - указывает, что сервер должен добиваться аутентификацию запросов на блокировку (с помощью протокола NFS Lock Manager (диспетчер блокировок NFS)).
  • nohide (hide) - если сервер экспортирует две иерархии каталогов, при всем этом одна вложенна (примонтированна) в другую. Клиенту необходимо разумеется смонтировать вторую (дочернюю) иерархию, по другому точка монтирования дочерней иерархии будет смотреться как пустой каталог. Функция nohide приводит к появлению 2-ой иерархии каталогов без тривиального монтирования. (прим: я данную опцию так и не смог вынудить работать...)
  • 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.

Функции отображения (соответствия) идентификаторов юзеров

Для большего понимания нижесказанного я бы посоветовал ознакомиться со статьей Управление пользователями Linux. Каждый пользователь Linux имеет свои UID и главный GID, которые описаны в файлах /etc/passwd и /etc/group.

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


Следующие функции задают правила отображения удаленных юзеров в локальных:

Пример использования файла маппинга юзеров:

ARCHIV ~ # cat /etc/file_maps_users # Маппинг юзеров # remote local comment uid 0-50 Одна тыща два # сопоставление юзеров с удаленным UID 0-50 к локальному UID Одна тыща два gid 0-50 Одна тыща два # сопоставление юзеров с/span удаленным GID 0-50 к локальному GID 1002

Управление сервером 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 адресами хостов, которым разрешено монтировать обозначенные сборники:

FILES ~ # showmount --exports archiv Export list for archiv: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

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

ARCHIV ~ # showmount files clnt_create: RPC: Program not registered # данное сообщение говорит нам, что на хосте FILES бес NFSd не запущен

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;

Клиент NFS

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

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

  • вручную, с помощью команды mount
  • автоматом при загрузке, при монтировании файловых систем, обрисованных в /etc/fstab
  • автоматом с помощью беса autofs

3-ий способ с autofs в данной статье я рассматривать не буду, ввиду его большой инфы. Может быть в следующих статьях будет отдельное описание.

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

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

FILES ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small FILES ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big FILES ~ # mount ....... archiv:/archiv-small on /archivs/archiv-small type nfs (rw,addr=10.0.0.6) archiv:/archiv-big on /archivs/archiv-big type nfs (ro,addr=10.0.0.6)

1-ая команда монтирует экспортированный каталог /archiv-small на сервере archiv в локальную точку монтирования /archivs/archiv-small с опциями по умолчанию (другими словами для чтения и записи).

Хотя команда mount в последних дистрибутивах умеет обдумывать какой тип файловой системы употребляется и без указания типа, все же указывать параметр -t nfs лучше. 2-ая команда монтирует экспортированный каталог /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 ожидает до обновления атрибутов каталога (по-умолчанию Шестьдесят сек.)
  • acdirmin=n (attribute cache directory file minimum - кэширование атрибута минимум для файла каталога) - Маленькое количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 30 сек.)
  • acregmax=n (attribute cache regular file maximum - кэширование атрибута максимум для обыденного файла) - Максимаьное количество секунд, которое NFS ожидает до обновления атрибутов обыденного файла (по-умолчанию Шестьдесят сек.)
  • acregmin=n (attribute cache regular file minimum- кэширование атрибута минимум для обыденного файла) - Маленькое количество секунд, которое NFS ожидает до обновления атрибутов обыденного файла (по-умолчанию Три сек.)
  • 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 - значение таймаута) - Количество 10-х толикой секунды ожидания службой NFS до повторной передачи в случае RPC или малого таймаута (по-умолчанию 7). Это значение растет при каждом таймауте до большего значения Шестьдесят секунд или до пришествия большого таймаута. В случае занятой сети, медленного сервера или при прохождении запроса через несколько маршрутизаторов или шлюзов увеличение этого значения может повысить производительность.

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

Описание файла /etc/fstab я затрагивал в соответствующей статье. В текущем примере я рассмотрю несколько примеров монтирования файловых систем NFS с описанием опций:

FILES ~ # cat /etc/fstab | grep nfs archiv:/archiv-small /archivs/archiv-small nfs rw,timeo=4,rsize=16384,wsize=16384 Нуль Нуль nfs-server:/archiv-big /archivs/archiv-big nfs rw,timeo=50,hard,fg Нуль 0

1-ый пример монтирует файловую систему /archiv-small с хоста archiv в точку монтирования /archivs/archiv-small, тип файловой системы указан nfs (всегда необходимо указывать для данного типа), файловая система монтирована с опцией для чтения, записи (rw).

Хост archiv подключен по быстрому локальному каналу, поэтому для роста производительности параметр timeo уменьшен и существенно увеличены значения rsize и wsize. Поля для программ dump и fsck заданы в ноль, чтобы данные программы не использовали файловую систему, примонтированную по NFS.

2-ой пример монтирует файловую систему /archiv-big с хоста nfs-server. Т.к. к хосту nfs-server мы подключены по медленному соединению, параметр timeo увеличен до 5 сек (50 10-х толикой сек), а так же жестко задан параметр hard, чтобы NFS продолжала перемонтировать файловую систему после большого таймаута, так же задан параметр fg, чтобы при загрузке системы и недоступности хоста nfs-server не вышло зависания.

До того как сохранять конфигурации в /etc/fstab, обязательно попробуйте смонтировать вручную и убедитесь, что всё работает!!!

Повышение производительности NFS

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

Так же, одним из самых легких способов роста производительности NFS - увеличение количества байтов, передаваемых за один раз. Размер в Четыре тыщи девяносто 6 б очень мал для современных быстрых соединений, увеличивая это значение до Восемь тыщ 100 девяносто два и более можно экспериментальным способом найти наилучшую скорость.

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

Но на загруженных и медленных соединениях это время может быть меньше времени реакции сервера и способности каналов связи, в конечном итоге чего могут быть излишние повторные пересылки, замедляющие работу.По умолчанию, timeo равно 0,7 сек (700 миллисекунд). после неответа в течении Семьсот мс сервер совершит повторную пересылку и удвоит время ожидания до 1,4 сек., увеличение timeo будет продолжаться до большего значения в Шестьдесят сек. Далее зависимо от параметра hard/soft произойдет какое-либо действие (см.выше).

Подобрать наилучший timeo для определенного значения передаваемого пакета (значений rsize/wsize), можно с помощью команды ping:

FILES ~ # ping -s 30 две тыщи семьсот шестьдесят восемь archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) bytes of data. 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0.931 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 time=0.958 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 time=1.00 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms ^C --- archiv.DOMAIN.local ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 0.931/1.002/1.083/0.061 ms

Как видно, при отправке пакета размером 30 две тыщи семьсот шестьдесят восемь (32Kb) время его путешествия от клиента до сервера и вспять плавает в районе Один миллисекунды. Если данное время будет зашкаливать за Двести мс, то стоит задуматься о повышении значения timeo, чтобы оно превышало значение обмена в три-четыре раза. Соответственно, данный тест лучше делать во время сильной загрузки сети

Запуск NFS и настройка Firewall

Заметка скопипсчена с блога http://bog.pp.ru/work/NFS.html, за что ему большущее спасибо!!!

Запуск сервера NFS, монтирования, блокировки, квотирования и статуса с "правильными" портами (для сетевого экрана)

  • лучше предварительно размонтировать все ресурсы на клиентах
  • остановить и запретить запуск rpcidmapd, если не планируется внедрение NFSv4: chkconfig --level Триста 40 5 rpcidmapd off service rpcidmapd stop
  • если нужно, то разрешить запуск сервисов portmap, nfs и nfslock: chkconfig --levels Триста 40 5 portmap/rpcbind on chkconfig --levels Триста 40 5 nfs on chkconfig --levels Триста 40 5 nfslock on
  • если нужно, то остановить сервисы nfslock и nfs, запустить portmap/rpcbind, выгрузить модули service nfslock stop service nfs stop service portmap start # service rpcbind start umount /proc/fs/nfsd service rpcidmapd stop rmmod nfsd service autofs stop # где-то позднее его необходимо запустить rmmod nfs rmmod nfs_acl rmmod lockd
  • открыть порты в iptables
    • для RPC: UDP/111, TCP/111
    • для NFS: UDP/2049, TCP/2049
    • для rpc.statd: UDP/4000, TCP/4000
    • для lockd: UDP/4001, TCP/4001
    • для mountd: UDP/4002, TCP/4002
    • для rpc.rquota: UDP/4003, TCP/4003
  • для сервера rpc.nfsd добавить в /etc/sysconfig/nfs строку RPCNFSDARGS="--port 2049"
  • для сервера монтирования добавить в /etc/sysconfig/nfs строку MOUNTD_PORT=4002
  • для функции rpc.rquota для новых версий необходимо добавить в /etc/sysconfig/nfs строку RQUOTAD_PORT=4003
  • для функции rpc.rquota необходимо для старых версий (все таки, необходимо иметь пакет quota 3.08 или свежее) добавить в /etc/services rquotad 4003/tcp rquotad 4003/udp
  • проверит адекватность /etc/exports
  • запустить сервисы rpc.nfsd, mountd и rpc.rquota (заодно запускаются rpcsvcgssd и rpc.idmapd, если не забыли их удалить) service nfsd start или в новых версиях service nfs start
  • для сервера блокировки для новых систем добавить в /etc/sysconfig/nfs строки LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001
  • для сервера блокировки для старых систем добавить непосредственно в /etc/modprobe[.conf]: options lockd nlm_udpport=4001 nlm_tcpport=4001
  • привязать сервер статуса rpc.statd к порту Четыре тыщи (для старых систем в /etc/init.d/nfslock запускать rpc.statd с ключом -p 4000) STATD_PORT=4000
  • запустить сервисы lockd и rpc.statd service nfslock start
  • убедиться, что все порты привязались нормально с помощью "lsof -i -n -P" и "netstat -a -n" (часть портов употребляется модулями ядра, которые lsof не видит)
  • если перед "перестройкой" сервером пользовались клиенты и их не удалось размонтировать, то придётся перезапустить на клиентах сервисы автоматического монтирования (am-utils, autofs)

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

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

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

ARCHIV ~ # cat /etc/exports # Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя Девяносто девять с gid Девяносто девять /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99)) # Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя Девяносто девять с gid Девяносто девять /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

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

# chown -R nobody.nobody /files

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

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

FILES ~ # mount -t nfs archiv:/files /archivs/files

Резюме

Фух... Статья завершена. На данный момент мы изучили что такое Network File System и с чем ее едят, в следующей статье попробую сделать HOWTO с аутентификацией Kerberos. Надеюсь материал вышел доходчивым и нужным.

Буду рад Вашим дополнениям и комментариям!

NFS HOWTO, nfs.sourceforge, man nfs? man mount, man exports

RFC Одна тыща девяносто четыре - NFSv1, v2
RFC Одна тыща восемьсот тринадцать - NFSv3
RFC Три тыщи 500 30 - NFSv4
RFC 5 тыщ 600 шестьдесят один - NFSv4.1
NFS HOWTO
nfs.sourceforge.net
man mount
man exports

С протоколами передачи данных знаком не каждый. А вот соединить свои компьютеры в одну сеть или использовать сервер для хранения файлов хотели бы многие. Один из способов это осуществить: NFS. Как настроить NFS сервер в Ubuntu - читайте далее.

Правильно настроив NFS можно объединить в одну сеть компьютеры на разных ОС.

Network File System - протокол сетевого доступа к файлам. Как водится, состоит из двух частей. Одна - клиентская, которая расположена на компьютере, с которого просматривают удалённые данные. Другая - серверная - расположена на компьютере, где эти данные хранятся. Довольно удобно использовать дополнительное дисковое пространство, особенно в локальной сети . А если речь идёт о каких-то корпоративных ПК, то это просто необходимо.

Чем отличается?

Сегодня существует большое число протоколов и самого разного программного обеспечения, которое выполняет те же самые функции. Чем выделяется NFS?

  • Возможность соединения в одну сеть компьютеров на разных операционных системах. Часто ОС Windows удобно соединить по NFS с Unix-системой , например, Ubuntu. Для этих же целей существует и применяется Samba, но NFS легче, проще и быстрее этой программы, поскольку реализован на уровне ядра. Поэтому настроить доступ через него, как правило, будет проще.
  • NFS предоставляет прозрачный доступ к файлам. Это означает, что все удалённые файлы воспроизводятся точно так же, как и локальные. Программы не надо апгрейдить, чтобы воспроизвести любой файл, находящийся на сервере.
  • NFS отправляет только запрашиваемую часть файла, а не весь файл.

Устанавливать Network File System для полноценной работы необходимо, как минимум, на два компьютера: сервер и клиент. Естественно, новичку больше всего попотеть придётся над серверной частью, поскольку именно там необходимо «расшаривать» (открывать доступ) папки. Однако всё это выполняется довольно легко.

Как и большинство протоколов передачи данных, NFS совсем не молод. Разработан он был в 1984 году и предназначался для UNIX-систем. Это и сейчас главная роль NFS, однако многие обнаружили, что при помощи его очень удобно соединять Windows-компьютеры с линуксовыми. Кроме того, NFS отлично подходит для воспроизведения мультимедийного контента по локальной домашней сети. Samba в этой роли часто подвисает и подтормаживает.

Установка серверной части NFS

Серверную часть протокола мы будем ставить на Ubuntu 16.04. Естественно, если у вас стоит редакция Server, то процесс никоим образом не отличается. Просто в традиционной версии Убунту некоторые действия можно выполнить при помощи графического интерфейса.

Устанавливаем программу. Для этого можно воспользоваться центром загрузки приложений , а можно просто ввести команду:

sudo apt install nfs-kernel-server

После этого нелишним будет проверить корректность установки. Делать это не обязательно, но мы всё же проверим. Вводим команду:

Порт везде должен быть 2049.

Теперь проверяем, поддерживает ли ядро NFS. Для этого вводим:

cat /proc/filesystems | grep nfs

Полученное значение должно выглядеть так: nodev nfsd

Это означает, что всё функционирует правильно. Если нет, то вводим команду:

При помощи её мы ставим модуль ядра самостоятельно.

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

sudo systemctl enable nfs

Итак, серверную часть мы установили, осталось правильно её настроить и перейти к клиентской.

Настройка

Настройка NFS в Ubuntu заключает в себе расшаривание определённых папок.

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

  • rw - reading and writing этот параметр разрешает чтение и запись файлов в папке.
  • ro - reading only - разрешает только чтение папки.
  • sync (по умолчанию) - параметр обеспечивает надёжность передачи. Если включен он, то нельзя будет одновременно передавать несколько файлов или на разные компьютеры. Эта настройка не даст отвечать на другие запросы. Предотвращает утерю данных, но передача может идти медленнее.
  • async - обратный предыдущему параметр. Передача идёт быстрее, но возникает риск потери информации.
  • secure - опция разрешает использовать только порты, номер которых ниже 1024. Включена по умолчанию.
  • insecure - разрешает использование любых портов.
  • nohide - если вы монтируете несколько директорий, среди которых есть вложенные, то вложенные в отличие от родительской будут отображаться как пустые. Исправить это поможет параметр
  • anonuid - указывает uid для анонимов. Это специальный идентификатор пользователя.
  • anongid - указывает gid для анонимов. GID (Group ID) - ещё один идентификатор пользователя.
  • no_subtree_check - функция отключает контроль поддерева. Дело в том, что без неё NFS дополнительно проверяет, что пользователи обращаются только в нужные разделы каталога. Это замедляет работу. Параметр позволяет ускорить её, но понижает безопасность.

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

Создадим новую папку. Можно использовать и новую. Наша папка будет /var/network.

Теперь необходимо добавить эту папку в файл /etc/exports. Там хранятся все файлы и папки с открытым сетевым доступом. Запись должна выглядеть так:

/var/network168.1.1(rw,async,no_subtree_check)

192.168.1.1 - это IP, по которому мы осуществляем передачу. Указывать его обязательно.

Обновляем таблицу экспорта:

Теперь попробуем получить доступ к папке со стороны клиента.

Установка и настройка клиентской части NFS

Ubuntu

На Убунту подключить настроенный сервер не составит труда. Делается это всего за пару команд.

Устанавливаем специальный клиентский пакет:

sudo apt install nfs-common

sudo mount 192.168.1.1:/var/network/ /mnt/

Сетевая папка подключена. С помощью df можно проверить все подключенные сетевые папки:

Также можно проверить свой уровень доступа специальной командой:

Отключаем файловую систему следующим образом:

Почти везде используется команда mount. Она отвечает за процесс монтирования, то есть, подготовки пространства на жёстком диске для использования его операционной системой. Звучит сложно, но если упростить, получится, что мы просто перекидываем сетевые файлы на наш компьютер в новоявленную папку. Здесь она называется /mnt/.

Windows

С Виндой, как правило, всё складывается куда сложнее. NFS клиент без проблем можно запустить на всех серверных Windows. Из стандартных он присутствует на:

  • Windows 7 Ultimate/Enterprise
  • Windows 8/8.1 Enterprise
  • Windows 10 Enterprise

Больше нигде не найти. Если у вас одна из этих версий, делаем следующее:

  1. Открываем меню «Программы и компоненты».
  2. Жмём «Добавление компонентов».
  3. Находим там NFS и ставим только «Клиент для NFS», другой компонент нам не нужен.

После подключения монтируется всё такой же командой:

mount 192.168.1.1:/var/network/ /mnt/

Размонтировать можно следующим образом:

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

А что делать, если клиента для NFS на компьютере нет? Можно попробовать загрузить софт через сайт Microsoft или со сторонних ресурсов. Возможно, что здесь понадобятся другие команды или действия.

Теперь у вас появились базовые представления о том, как можно использовать NFC и провести простейшую настройку. Этих знаний хватит, чтобы наладить доступ с одного компьютера к другому. Причём в роли клиента может выступить и ПК на Windows.