Nfs файловая система кратко

Обновлено: 05.07.2024

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

Описание компонента

с помощью протокола NFS можно передавать файлы между компьютерами, на которых выполняется Windows, и другими операционными системами, не являющимися Windows, такими как Linux или UNIX.

nfs в Windows server включает server для nfs и Client для nfs. компьютер, на котором работает Windows server, может использовать сервер для nfs в качестве файлового сервера nfs для других клиентских компьютеров, не являющихся Windows. клиент для NFS позволяет компьютеру с Windows, на котором работает Windows server, получать доступ к файлам, хранящимся на сервере NFS, отличном от Windows.

версии Windows и Windows Server

Windows поддерживает несколько версий клиента NFS и сервера в зависимости от версии операционной системы и семейства.

Операционные системы Версии NFS Server Версии клиента NFS
Windows 7, Windows 8.1, Windows 10 Недоступно NFSv2, NFSv3
Windows Server 2008, Windows Server 2008 R2 NFSv2, NFSv3 NFSv2, NFSv3
Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 NFSv2, NFSv3, Нфсв 4.1 NFSv2, NFSv3

Практическое применение

Ниже приведены некоторые способы использования NFS.

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

Новые и измененные функции

Новые и измененные функциональные возможности в сетевой файловой системе включают поддержку NFS версии 4,1 и Улучшенное развертывание и управляемость. дополнительные сведения о новых или измененных функциональных возможностях Windows Server 2012 см. в следующей таблице.

Компонент или функция Новинка или обновление Описание
NFS версии 4,1 Новое Повышенная безопасность, производительность и совместимость по сравнению с NFS версии 3.
Инфраструктура NFS Обновленные возможности Улучшает развертывание и управляемость и повышает безопасность.
Постоянная доступность NFS версии 3 Обновленные возможности Повышает постоянную доступность на клиентах NFS версии 3.
Улучшения развертывания и управляемости Обновленные возможности позволяет легко развертывать NFS и управлять ими с помощью новых командлетов Windows PowerShell и нового поставщика WMI.

NFS версии 4,1

NFS версии 4,1 реализует все необходимые аспекты в дополнение к некоторым дополнительным аспектам RFC 5661:

  • Файловая система, котораяразделяет физическое и логическое пространство имен и СОВМЕСТИМА с NFS версии 3 и NFS версии 2. Для экспортированной файловой системы, которая является частью псевдо-файловой системы, предоставляется псевдоним.
  • Составные удаленные вызовы процедур объединяют соответствующие операции и сокращают число бесед.
  • Сеансы и многосеансовая коммутация сеансов обеспечивают только одну семантику и обеспечивают постоянную доступность и лучшую производительность при использовании нескольких сетей между клиентами NFS 4,1 и сервером NFS.

Инфраструктура NFS

улучшения в общей инфраструктуре NFS в Windows Server 2012 описаны ниже.

  • Инфраструктура транспорта /External (RPC) , используемая сетевым протоколом Winsock, доступна как для сервера NFS, так и для клиента для NFS. Это заменяет интерфейс TDI, обеспечивает лучшую поддержку и обеспечивает лучшую масштабируемость и масштабирование на стороне приема (RSS).
  • Функция мультиплексора RPC-портов является удобной для брандмауэра (меньше портов для управления) и УПРОЩАЕТ развертывание NFS.
  • Автоматически настроенные кэши и пулы потоков являются возможностями управления ресурсами в новой инфраструктуре RPC/XDR, которая является динамической, автоматически настраивает кэши и пулы потоков на основе рабочей нагрузки. Это полностью удаляет предоставляя, который участвует во время настройки параметров, обеспечивая оптимальную производительность сразу после развертывания NFS.
  • Новые варианты реализации и проверки подлинности Kerberos с добавлением поддержки Kerberos (Krb5p) и существующих параметров проверки подлинности krb5 и krb5i.
  • сопоставление удостоверений Windows PowerShell командлеты модуля упрощают управление сопоставлением удостоверений, настройку службы Active Directory облегченного доступа к каталогам (AD LDS) и настройку UNIX, а также и неструктурированных файлов Linux.
  • Точка подключения тома позволяет получить доступ к томам, подключенным к общему ресурсу NFS, с помощью nfs версии 4,1.
  • Функция мультиплексирования портов поддерживает МУЛЬТИПЛЕКСОР порта RPC (порт 2049), который является удобным для брандмауэра и УПРОЩАЕТ развертывание NFS.

Постоянная доступность NFS версии 3

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

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

Улучшения развертывания и управляемости

Развертывание и управление NFS улучшены следующими способами.

  • более 40 новых командлетов Windows PowerShell упрощают настройку файловых ресурсов NFS и управление ими. Дополнительные сведения см. в разделе командлеты NFS в Windows PowerShell.
  • сопоставление удостоверений улучшено с помощью локального хранилища сопоставления неструктурированных файлов и новых командлетов Windows PowerShell для настройки сопоставления удостоверений.
  • Диспетчер сервера графический пользовательский интерфейс проще в использовании.
  • Новый поставщик WMI версии 2 доступен для упрощения управления.
  • Мультиплексор портов RPC (порт 2049) является удобным для брандмауэра и упрощает развертывание NFS.

Сведения о диспетчере сервера

в диспетчер сервера или более поздней версии центра администрирования Windows — используйте мастер добавления ролей и компонентов, чтобы добавить службу роли сервера для NFS (в файле и роли служб iSCSI). Общую информацию об установке компонентов см. в разделе Установка и удаление ролей, служб ролей или компонентов. Средства сервера для NFS включают оснастку "службы для сетевой файловой системы" MMC для управления сервером для NFS и клиентом для компонентов NFS. С помощью оснастки можно управлять компонентами сервера для NFS, установленными на компьютере. сервер для NFS также содержит несколько Windows средств администрирования командной строки:

  • подключение подключает удаленный общий ресурс NFS (также известный как экспорт) локально и сопоставляет его с буквой локального диска на клиентском компьютере Windows.
  • Nfsadmin управляет параметрами конфигурации сервера для NFS и клиента для компонентов NFS.
  • Нфсшаре настраивает параметры общего ресурса NFS для общих папок с помощью сервера для NFS.
  • Нфсстат отображает или сбрасывает статистику вызовов, полученных сервером для NFS.
  • Шовмаунт Отображает подключенные файловые системы, экспортированные сервером для NFS.
  • Umount удаляет диски, подключенные к NFS.

nfs в Windows Server 2012 представляет модуль nfs для Windows PowerShell с несколькими новыми командлетами специально для NFS. Эти командлеты предоставляют простой способ автоматизации задач управления NFS. Дополнительные сведения см. в разделе командлеты NFS в Windows PowerShell.

NFS (Network File System), а по-русски просто - сетевая файловая система была задумана в ОС Unix для того, чтобы пользователь, сидящий за своим компьютером, мог обращаться к файловой системе удаленного компьютера так, как если бы она находилась на его собственной машине; иными словами NFS позволяет монтировать файловую систему с удаленного компьютера так, как будто она находится в вашей системе. Это чем-то похоже на "подключить сетевой диск" в Windows системах, однако несравненно БОЛЕЕ защищенное. Хотелось бы также отметить, что, при монтировании удаленной файловой системы, существует только один экземпляр файла, находящийся в удаленной файловой системе.

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

Вторая строка читается как: предоставить директорию /pub только для чтения всем кому угодно без проверки прав доступа. Следовательно
замаунтить ее себе смогут все кому ни лень. Система NFS работает в сети TCP/IP, для чего запускается два демона rpc.mountd и rpc.nfsd.
Раздел NFS можно присоединить обычной для Unix`а командой mount с опцией -t
nfs. Если вы не знакомы с синтаксисом данной команды, то он таков:

mount откуда_монтировать куда_монтировать

Т.е. в нашем примере это примерно следующее:

Кстати, заметь, что монтировать файловую систему может только root - так что сделай исключение - зайди на свою машину как привилегированный пользователь.

Ну с общей теорией по-моему мы закончили, но какова же все-таки возможная польза NFS для деструктивных действий? Ответ прост: в большинстве случаев абсолютно никакой - записи, разрешающие экспорт файловой системы кем ни попадя (вроде второй строчки нашего примера) практически не встретишь (потому как нужно быть Абсолютным лопухом, чтобы сделать ТАКОЕ), либо это действительно бесполезный каталог /pub. Однако, если машина находится в большой сети, то полуграмотный админ может создать запись "для всех", имея в виду свою сеть (у сам у себя хакать не будешь), а про то, что машина имеет выход в инет он забывает…. И вот тогда наступает время деструктивных действий.

NFS
Уровень (по модели OSI): Прикладной
Семейство: стек протоколов TCP/IP
Порт/ID: 67, 68/UDP
Назначение протокола: Получение сетевой конфигурации
Спецификация: RFC 2131
Основные реализации (серверы): dhcpd, ISC DHCP Server, Infoblox
Вступил в силу с: 1990

NFS (англ. Network File System ) — протокол сетевого доступа к файловым системам, первоначально разработан Sun Microsystems в 1984 году. Основан на протоколе вызова удалённых процедур (ONC RPC). Позволяет подключать (монтировать) удалённые файловые системы через сеть. [1]

NFS абстрагирован от типов файловых систем как сервера, так и клиента, существует множество реализаций NFS-серверов и клиентов для различных операционных систем и аппаратных архитектур. Наиболее зрелая версия NFS — v.4, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).


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

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

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

Содержание

История

Протокол NFS имеет в своей истории 4 версии.

Первая версия применялась только для внутреннего использования в Sun в экспериментальных целях. Версия 2 выпущена в марте 1989 года, первоначально полностью работала по протоколу UDP. Разработчики решили не хранить данных о внутреннем состоянии внутри протокола, как пример, блокировка, реализованная вне базового протокола. Люди, вовлечённые в создание NFS версии 2 — Расти Сэндберг (Rusty Sandberg,) Боб Лайон (Bob Lyon), Билл Джой и Стив Клейман (Steve Kleiman).

NFSv3 вышла в июне 1995 года, в ней добавлена поддержка дескрипторов файлов переменного размера до 64 байт (в версии 2 — массив фиксированного размера 32 байта), снято ограничение на 8192 байта в RPC-вызовах чтения и записи (тем самым, размер передаваемого блока в вызовах ограничен только пределом для UDP-датаграммы — 65535 байт), реализована поддержка файлов больших размеров, поддержаны асинхронные вызовы операций записи, к процедурам READ и WRITE добавлены вызовы ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1-информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение). На момент введения версии 3 отмечен рост популярности в среде разработчиков протокола TCP. Некоторые независимые разработчики самостоятельно добавили поддержку протокола TCP для NFS версии 2 в качестве транспортного, Sun Microsystems добавили поддержку TCP в NFS в одном из дополнений к версии 3. С поддержкой TCP повысились практическая осуществимость использования NFS в глобальных сетях.

NFSv4 выпущена в декабре 2000 года под влиянием AFS и CIFS, в неё включены улучшения производительности и безопасности. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF). NFS версии v4.1 была одобрена IESG в январе 2010 года (новая спецификация, объёмом 612 страниц, стала известна как самый длинный документ, одобренный IETF). Важным нововведением версии 4.1 является спецификация pNFS — Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые облачные хранилища и информационные системы.

Цели разработки

Изначальными требованиями при разработке NFS были:

  • потенциальная поддержка различных операционных систем (не только UNIX), чтобы серверы и клиенты NFS возможно было бы реализовать в разных операционных системах;
  • протокол не должен зависеть от каких-либо определённых аппаратных средств;
  • должны быть реализованы простые механизмы восстановления в случае отказов сервера или клиента;
  • приложения должны иметь прозрачный доступ к удаленным файлам без использования специальных путевых имен или библиотек и без перекомпиляции;
  • для UNIX-клиентов должна поддерживаться семантика UNIX;
  • производительность NFS должна быть сравнима с производительностью локальных дисков;
  • реализация не должна быть зависимой от транспортных средств.

Принцип работы NFS

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

Протокол NFS определяет набор запросов (операций), которые могут быть направлены клиентом к серверу, а также набор аргументов и возвращаемые значения для каждого из этих запросов. Версия 1 этого протокола существовала только в недрах Sun Microsystems и никогда не была выпущена. Все реализации NFS (в том числе NFSv3) поддерживают версию 2 NFS (NFSv2), которая впервые была выпущена в 1985 году в SunOS 2.0. Версия 3 протокола была опубликована в 1993 году и реализована некоторыми фирмами-поставщиками.

Протокол удаленного вызова процедур (RPC) определяет формат всех взаимодействий между клиентом и сервером. Каждый запрос NFS посылается как пакет RPC. На сервере работают следующие даемоны [2] :

  • 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.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.idmapd - Даемон idmapd для NFSv4 на сервере преобразует локальные uid/gid пользователей в формат вида имя@домен, а сервис на клиенте преобразует имена пользователей/групп вида имя@домен в локальные идентификаторы пользователя и группы (согласно конфигурационному файлу /etc/idmapd.conf).

Клиент может запустить также даемон, называемый nfsiod. nfsiod обслуживает запросы, поступающие от сервера от сервера NFS. Он необязателен, увеличивает производительность, однако для нормальной и правильной работы не требуется. [3] В NFSv4 при использовании Kerberos дополнительно запускаются демоны:

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

Даемоны старых версий (NFS v.3 и ниже):

  • nfslogd - даемон журналов NFS фиксирует активность для экспортированных файловых систем, работает на серверах NFS
  • rpc.rquotad - сервер удаленных квот предоставляет информацию о квотах пользователей в удаленных файловых системах, может работать как на серверах, так и на клиентах.

Кроме указанных выше пакетов, для корректной работы NFSv2 и v3 требуется дополнительный пакет portmap (в более новых дистрибутивах заменен на переименован в rpcbind). Sun 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 получают необходимую информацию.

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

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

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

  • Клиенту (пользовательскому процессу) безразлично, получает ли он доступ к локальному файлу или к NFS файлу. Ядро занимается взаимодействием с железом через модули ядра или встроенные системные вызовы.
  • Модуль ядра kernel/fs/nfs/nfs.ko, который выполняет функции NFS клиента отправляет RPC запросы NFS серверу через модуль TCP/IP. NFS обычно использует UDP, однако более новые реализации могут использовать TCP.
  • NFS сервер получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS может работать с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт 2049 жестко закреплен за NFS в большинстве реализаций.
  • Когда NFS сервер получает запрос от клиента, он передаётся локальной подпрограмме доступа к файлу, которая обеспечивает доступ к локальному диску на сервере.
  • Результат обращения диску возвращается клиенту.

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

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


В файле exports используются следующие общие опции: [4]

  • auth_nlm (no_auth_nlm) или secure_locks (insecure_locks) - указывает, что сервер должен требовать аутентификацию запросов на блокировку (с помощью протокола NFS Lock Manager (диспетчер блокировок NFS)).
  • nohide (hide) - если сервер экспортирует две иерархии каталогов, при этом одна вложенна (примонтированна) в другую. Клиенту необходимо явно смонтировать вторую (дочернюю) иерархию, иначе точка монтирования дочерней иерархии будет выглядеть как пустой каталог. Опция nohide приводит к появлению второй иерархии каталогов без явного монтирования.
  • ro - Разрешает только запросы на чтение.
  • rw - Разрешает запросы на запись.
  • secure (insecure) - требует, чтобы запросы NFS поступали с защищенных портов ( Управление сервером NFS

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

  • nfsstat
  • showmsecure (insecure)ount
  • exportfs

Утилита nfsstat позволяет посмотреть статистику RPC и NFS серверов.

showmount

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

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

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

exportfs

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

  1. [клиент:имя-каталога] - добавить или удалить указанную файловую систему для указанного клиента)
  2. -v - выводить больше информации
  3. -r - переэкспортировать все каталоги (синхронизировать /etc/exports и /var/lib/nfs/xtab)
  4. -u - удалить из списка экспортируемых
  5. -a - добавить или удалить все файловые системы
  6. -o - опции через запятую (аналогичен опциям применяемым в /etc/exports; т.о. можно изменять опции уже смонтированных файловых систем)
  7. -i - не использовать /etc/exports при добавлении, только параметры текущей командной строки
  8. -f - сбросить список экспортируемых систем в ядре 2.6.

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

Пример команды mount для монтирования файловой системы NFS в Debian:

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

Кэш атрибутов периодически обновляется в соответствии с заданными параметрами:

  1. ac (noac) (attrebute cache - кэширование атрибутов) - Разрешает кэширование атрибутов (по-умолчанию). Хотя опция noac замедляет работу сервера, она позволяет избежать устаревания атрибутов, когда несколько клиентов активно записывают информацию в общию иерархию.
  2. acdirmax=n (attribute cache directory file maximum - кэширование атрибута максимум для файла каталога) - Максимальное количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 60 сек.)
  3. acdirmin=n (attribute cache directory file minimum - кэширование атрибута минимум для файла каталога) - Минимальное количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 30 сек.)
  4. acregmax=n (attribute cache regular file maximum - кэширование атрибута максимум для обычного файла) - Максимаьное количество секунд, которое NFS ожидает до обновления атрибутов обычного файла (по-умолчанию 60 сек.)
  5. acregmin=n (attribute cache regular file minimum- кэширование атрибута минимум для обычного файла) - Минимальное количество секунд, которое NFS ожидает до обновления атрибутов обычного файла (по-умолчанию 3 сек.)
  6. actimeo=n (attribute cache timeout - таймаут кэширования атрибутов) - Заменяет значения для всех вышуказаных опций. Если actimeo не задан, то вышеуказанные значения принимают значения по умолчанию.

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

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

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

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

Одним из способов повышения производительности NFS - увеличение количества байтов, передаваемых за один раз. Размер в 4096 байт слишком мал для современных быстрых соединений, увеличивая это значение до 8192 и более можно экспериментальным путем найти оптимальную скорость.

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

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

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

Вы должны контролировать работу этого сервиса - ведь не совсем хорошая мысль позволять помещать данные в вашу сеть кому угодно;-) Несколько обычных настроек уменьшат вероятность возникновения такой ситуации.

Заметка построена следующим образом - сначала кратко вообще о файловых системах, затем рассмотрим протокол NFS, далее ( менее теоретическая часть ) - инсталляция NFS - сервера и клиента, и наконей пример взаимодействия NFS, NIS и autofs.

Перед знакомством с NFS познакомимся с термином "файловая система". В основе это - способ хранения, организации и управления данными на носителе. Существует множество разновидностей их - New Technology FileSystem (NTFS), High Performance FileSystem (HPFS), DOS, FAT 12/16/32, VFAT, Macintosh Hierarchical Filesystem (HFS), ISO 9660 (for CD-ROM), extended filesystems (Ext, Ext2, Ext3), некоторые более распространены, некоторые менее и т.д.

Пример - предположим, что любой носитель информации ( например жесткий диск) - набор ячеек определенного размера для хранения информации, так называемые блоки ( blocks ). Каждая файловая система работает с этими блоками по - своему. На рисунке 1 изображена попытка разместить файл, состоящий из 2 блоков. На верхнем рисунке файл размещается за последним занятым блоком, оставляя свободными блоки в начале, на другом рисунке - файл помещается в первое свободное место. Если термин "фрагментация" напоминает вам что - нибудь - теперь вы знаете о чем речь ;-)



Рисунок. 1 : 2 метода расположения блоков

Наиболее популярная файловая система для ОС Linux - ext2fs (extended 2 file system), в которой каждый файл представлен таким термином как inode 1 . Каталоги содержат списки входящих файлов, доступ к которым осуществляется посредством операций чтения/записи.

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

Протокол NFS - это на самом деле сочетание четырех различных протоколов. Каждый взаимодействует с Remote Procedure Calls( RPC ) и portmap (также используется название rpc.portmap). Вспомним, что эта программа преобразует номера программ RPC в номера портов. Когда RPC - сервер начинает свою работу, он передает информацию portmap какой порт будет использоваться программой. Когда клиент посылает RPC - запрос программе, сначала происходит взаимодействие с portmap на предмет получения номера порта, используемого данной программой. И только после этого запрос направляется на соответствующий порт.

Рассмотрим функции каждого протокола :

Протокол Описание Демон
nfs создание, чтение/запись, поиск файлов. Также управляет аутентификацией и статистикой. nfsd
mountd ответственный за присоединение внешних систем для доступа через nfs. Сервер получает запросы mount и umount и хранит информацию об экспортируемых системах. mountd
nsm
(Network Status Monitor)		 следит за текущим состоянием компьютера ( сервера или клиента ) для информирования ( например о перезагрузке ). statd
nlm
(Network Lock Manager)		 для предотвращения одновременного изменения данных разными клиентами ( используется система блокировки ). С помощью Nsm протокол получает информацию о начале работы клиента, соответственно снимаются все блокировки для осуществления доступа и если он происходит - ресурс опять блокируется. lockd

Демон knfsd, доступный в последних версиях ядра поддерживает протоколы nfs и nlm. С другой стороны - протоколы mountd и nsm больше не поддерживаются. Когда NFS инсталлирован и запущен можно проконтролировать его работу следующим образом :

>> ps auxwww | egrep "nfs|mount|lock|stat"
root 1370 0.0 0.2 1176 580 ? S 22:28 0:00 rpc.mountd --no-nfs-version 3
root 1379 0.0 0.0 0 0 pts/0 SW 22:28 0:00 [nfsd]
root 1380 0.0 0.0 0 0 pts/0 SW 22:28 0:00 [nfsd]
root 1381 0.0 0.0 0 0 pts/0 SW 22:28 0:00 [nfsd]
root 1382 0.0 0.0 0 0 pts/0 SW 22:28 0:00 [nfsd]
root 1383 0.0 0.0 0 0 pts/0 SW 22:28 0:00 [nfsd]
root 1384 0.0 0.0 0 0 pts/0 SW 22:28 0:00 [nfsd]
root 1385 0.0 0.0 0 0 pts/0 SW 22:28 0:00 [nfsd]
root 1386 0.0 0.0 0 0 pts/0 SW 22:28 0:00 [nfsd]
root 1399 0.0 0.0 0 0 pts/0 SW 22:28 0:00 [lockd]
root 1409 0.0 0.2 1156 560 ? S 22:28 0:00 rpc.statd
root 1652 0.0 0.1 1228 484 pts/3 S 22:49 0:00 egrep nfs|mount|lock|stat

В настоящее время существуют две версии NFS - 2 и 3, обозначаемые NFSv2 и NFSv3 соответственно. NFS - серверы Linux поддерживают только версию 2 ( в соответствии с опцией mountd из предыдущего примера ).

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

Сервер

Первое, что необходимо сделать - запустить portmap, так как мы знаем, что протоколы, входящие в NFS используют RPCs:

root >>/usr/sbin/rpcinfo -p
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused
root >>/sbin/portmap
root >>/usr/sbin/rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper

Опция -p команды rpcinfo позволяет просмотреть сервисы RPC, работающие в данный момент на компьютере. Сначала мы видим, что portmap не запущен, активизируем его ( многие дистрибутивы Linux осуществляют это при запуске системы специальными скриптами ) и проверяем еще раз. Другой причиной негативного отклика системы на команду rpcinfo являются файлы /etc/hosts. , другими словами запрет в них на отклики portmapper.

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

  • имя компьютера;
  • wildcards в названии домена (например : linux-*.mondomaine.fr) ;
  • netgroup, в виде @group, если используется NIS и определены какие - либо;
  • IP - адрес.
  • rw (read write) : клиент может использовать чтение/запись;
  • ro (read only) : клиент может использовать только чтение;
  • root_squash : предпочтительно, чтобы root - пользователь не принимался за root сервера. Чтобы предотвратить это UID/GID 0 ( т.е. root ) стал одним из пользователей nobody. Данная опция устанавливается по умолчанию, но ее можно отменить используя no_root_squash;
  • all_squash : все пользователи экспортируемой системы используют nobody's UID/GID;
  • anonuid, anongid: пользователь nobody использует UID/GID предоставляемый этими опциями.

Так как мы изменили /etc/exports - необходимо оповестить об этом daemons. Команда exportfs передает эту информацию серверам : опция -r - синхронизирует файл /etc/mtab 2 c /etc/exports; опция -v - экспортируемые ресурсы получают свои установки.

  • /var/lib/nfs/rmtab: в каждой строке указано имя клиента и импортируемый ресурс;
  • /var/lib/nfs/etab:Файл используется rpc.mountd при запуске.
  • /proc/fs/nfs/exports: содержит список известных ядру клиентов;
  • /var/lib/nfs/xtab: если etab содержит имена клиентов и групп, указанных с помощью wildcards или netgroups, данный файл состоит из точных имен компьютеров.

Клиент

В общем случае ничего делать не надо. Доступ к файловой системе, предоставляемый NFS, управляется непосредственно ядром, которое знает как получить доступ к данным в той или иной системе. В каталоге /lib/modules/ /fs находятся модули файловых систем, поддерживаемые ядром. В файле /proc/filesystems находится список файловых систем, непосредственно поддерживаемых ядром. Все, что вам нужно сделать - сообщить ядру, что вы хотите получить доступ к данным, предоставляемым NFS.

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

Для NFS существуют специальные опции команды mount : например rsize и wsize меняют размер блоков для чтения/записи, которые можно комбинировать с обычно используемыми, такими как intr, noexec или nosuid. Man page mount рассказывает о всех доступных.

Пример : предположим, что на компьютере charly работает NFS - сервер и предоставляет в пользование свой /usr/local, для доступа к которому с компьютера с именем jill необходимо выполнить следующую команду :

В команде используются следующие опции - -t nfs ( доступ к файловой системе NFS ), nosuid, hard. Рассмотрим подробнее последние два аргумента : предпоследний определяет "что" надо монтировать ( обратите внимание на синтаксис - для NFS отличается от обычно используемого : сначала указываем имя сервера, а затем каталог ( Внимание : обычно каталог, а не устройство )), последний - "куда". Совместное использование каталога /usr/local компьютерами charly и jill предотвращает повторную установку некоторых программ. В файле etc/fstab указываются устройства, монтируемые при загрузке. В данном случае файл etc/fstab будет содержать следующую строку :

Предостережение

Главная опасность использования NFS состоит в том, что между клиентом и сервером устанавливаются доверительные отношения. Следовательно при возникновении проблемной ситуации с root account сервера то же самое произойдет и с root account клиента. В NFS-HOWTO рассказывается об основных мерах, которые необходимо предпринять для избежания этого. Клиент не должен слепо доверять серверу, поэтому возникает необходимость использования специальных опций команды mount. Об одной мы уже упоминали - это nosuid, ее назначение - отмена эффекта SUID и SGID. Root сервера сначала регистрируется пользователем на клиенте и только потом становится root'ом. Следующая опция - noexec, ее назначение - запрет на использование программ, установленных на экспортируемом ресурсе.

Теперь немного о серверной стороне - также не доверять root'у, соответственно клиента. Ранее мы уже упоминали об этом - файл /etc/exports, опция root_squash. Механизм работы следующий : пользователь с UID 0 ( root ) клиента при обращении к серверу с запросом на доступ к данным - получает UID nobody. Эта опция используется в Linux по умолчанию, но может быть отменена с помощью no_root_squash. Также можно определить набор UID для которого использовать опцию. Вспомним, что опции anonuid и anongid помогают в изменении пользовательского UID/GID с nobody на любой другой.

Некоторые действия направлены на взаимодействие с portmapper. Например можно запретить доступ с любого компьютера, поместив следующую строку в файл /etc/hosts.deny :

Затем в файле /etc/hosts.allow можно указать компьютеры, которым разрешен доступ.

Не следует забывать и об использовании firewall'ов. В таблице указаны сервисы, номера портов и используемые протоколы :

RPC сервис Порт Протокол
portmap 111 upd / tcp
nfsd 2049 udp
mountd variable udp / tcp

Для наглядности обратимся к сети, установленной нами в предыдущей заметке о NIS. Напомню, что имя сервера - "charly", который мы сконфигурировали в качестве NIS - сервера, а другие компьютеры в сети - "sabrina", "jill" и "kelly" - его клиенты ( конечно необходимо иметь дублирующий сервер, но в настоящий момент перед нами стоит другая задача ).

Сначала рассмотрим конфигурацию нашего сервера charly - во-первых определим некоторые NIS maps, содержащие всю необходимую информацию.

В файле /etc/netgroup перечислены группы компьютеров со схожими характеристиками ( например с одинаковой архитектурой ). Данная NIS map очень полезна для NFS. Мы собрали вместе все компьютеры, у которых есть право на доступ к одной и той же экспортируемой файловой системе и далее эта группа будет использоваться в файле /etc/exports вместо определения каждого компьютера в отдельности :

Что касается NFS - конфигурирование ограничено. Посмотрим на содержимое файла /etc/exports на сервере charly:

Мы решили использовать automount для каталога /usr/local вместо монтирования при загрузке, эта процедура будет выполнена автоматически при попытке пользователя использовать файл из него. Также создадим файл /etc/auto.map и определим что будет одновременно доступно и automount и NIS:

Далее, если мы хотим чтобы информация из файлов auto.map и netgroup была интегрирована в базу данных NIS - необходимо изменить Makefile. Мы должны быть уверены, что netgroup будет обязательно добавлен, что касается auto.map - этот файл не определен по умолчанию и поэтому надо указать на его присутствие, добавив новый элемент в Makefile ( на основе существующих, взяв их в качестве основы ):

Далее необходимо выполнить make из каталога /var/yp.

Теперь о клиентах sabrina, jill and kelly. Эдесь ничего особенного делать не надо:) Просто информируем autofs об управлении новой картой представляемой YP. Следующая строка присутствует в каждом файле /etc/auto.master у клиентов и позволяет получать информацию о наличии auto.map от YP сервисов.

После установки программ на компьютере charly, все клиенты могут использовать их.

Можно пойти еще дальше и создать один /usr на всех, один /usr/doc на всех, но как показывает практика - это не совсем хорошая идея. Это влечет за собой изменения в каталоге /etc и других. Далее приходится обновлять не экспортируемые файлы на компьютерах и т.д.

Ссылки

Сноски

. inode 1 дескриптор файла ( последовательность бит содержащая такую информацию как права доступа к файлу, владелец, адреса блоков содержащих данные и т.д.). . /etc/mtab 2 файл содержащий список файловых систем монтируемых ядром.

Читайте также: