@ Карта сайта News Автора!

Bog BOS: NFS - сетевая файловая система

Последние изменения:
2024.11.11: sysadmin: Linux: пространства имён
2024.11.06: sysadmin: настройка TCP/IP в Linux: виртуальный интерфейс и виртуальный мост
2024.10.25: sysadmin: Linux VFS, атрибуты, расширенные атрибуты, ACL
2024.10.22: sysadmin: Монтирование файловых систем: bind, shared и OverlayFS

Последнее изменение файла: 2019.08.20
Скопировано с www.bog.pp.ru: 2024.11.21

Bog BOS: NFS - сетевая файловая система

Протокол NFS (версия 2 - RFC 1094 (1989); версия 3 - RFC 1813 (1995); версия 4 - RFC 7530 (2000, 2003, 2015); версия 4.1 - RFC 5661 (2010)) обеспечивает "прозрачный " доступ к файлам на удалённом компьютере, т.е. прикладная программа не должна замечать разницы между локальными и удалёнными файлами. Описание реализации делается в приложении к Linux (дистрибутивы Red Hat). Предварительно требуется знакомство с протоколом RPC.

Архитектура NFS

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

NFS2 и NFS3 сильно привязаны к семантике файловых операций в Unix (файлы ".", "..", права, uid/gid, имена в символьных ссылках и т.д.). Предполагается, что файловая система имеет иерархическую структуру, каждый файл или каталог имеет имя. Разделитель имён не важен, т.к. все процедуры NFS имеют дело только с простыми именами. Максимальная длина в NFS2 для простого имени файла - 255 байт, составного - 1024 байта. Протокол NFS3 не накладывает ограничения на длины простого и составного имён, но клиент и сервер могут иметь их. Максимальный размер блока данных - 8192 байта в NFS2, определяется процедурой FSINFO в NFS3. В NFS3 добавлены типы файлов: блочное устройство, символьное устройство, сокет, канал. Максимальный размер файла увеличен в NFS3 с 2^31-1 до 2^64-1 байта. В NFS3 добавлены средства слабой синхронизации (т.е. отсутствует гарантия) кеша клиента (weak cache consistency).

Построен над RPC, ранние версии используют UDP, поздние - TCP, обычно используется порт 2049 (т.е. rpcbind использовать необязательно). При работе в режиме TCP позволяет установить постоянное соединение для конкретной файловой системы (одно для всех клиентских процессов), а опция TCP keepalive позволяет определить сбой в работе сервера или перезагрузку и автоматически осуществлять повторное соединение и повтор "зависших" запросов.

Сервер NFS версий 2 и 3 не хранит информацию о состоянии клиентов и их предыдущих запросах (stateless), это упрощает для клиента обработку сбоев сервера (перезагрузка сервера воспринимается как простая задержка). Процедуры open и close отсутствуют. Все операции в NFSv2 синхронные, в NFSv3 предусмотрено кеширование записи (асинхронный режим WRITE). Клиент может кешировать запись самостоятельно. Большинство клиентов NFS3 кешируют атрибуты файлов. Невозможно реализовать удаление открытого файла так, чтобы его можно было продолжать читать до закрытия (нет команд open и close), но некоторые клиенты имитируют это свойство создавая временные файлы вида ".nfs...". Аналогичная проблема с динамическим изменением прав доступа к файлу (из-за этого в реализациях считается, что владелец файла всегда имеет доступ к нему). Кстати, права доступа к файлу необходимо проверять при каждом обращении, т.к. сервер не способен определить, что файл уже был открыт. Сервер не способен отличить запрос на чтение файла от запроса на выполнение, поэтому разрешает чтение, если у пользователя есть права на чтение или исполнение.

Теоретически, NFS клиент и сервер возможно реализовать в виде приложения, а не в ядре. Для одновременного обслуживания множества запросов используется либо многопоточная реализация NFS сервера или запускается несколько экземпляров процесса nfsd/nfsd4 (их количество необходимо подгонять под нагрузку). Аналогично, на клиентской стороне можно использовать многопоточную реализацию или запустить требуемое количество процессов biod (rpciod). Как сервер, так и клиент может поддерживать несколько версий протокола, выбор версии производится с помощью соответствующего механизма RPC.

Для работы NFS, кроме собственно NFS (RPC программа 100003) требуется программа удалённого монтирования (RPC программа 100005), блокировки файлов (RPC программа 100021), проверки статуса (RPC программа 100024), квотирования (RPC программа 100011). При работе с файлами клиент использует указатели на файл (file handles, фиксированная длина 32 байта в NFS2, переменная длина до 64 байт в NFS3), т.е. при открытии файла сервер возвращает указатель, которым клиент пользуется в дальнейшем при работе с файлом. Содержимое указателя не должно интерпретироваться клиентом, но в Unix реализации там хранится major/minor устройства, на котором смонтирована файловая система, inode и версия inode (требуется при повторном использовании одного и того же inode для различных файлов). Если указатели совпадают, то они указывают на один и тот же файл. Если они различны, то это не означает, что файлы различны. Указатель может "зачервстветь" (stale), если между обращениями клиента к серверу он, например, перезагрузился и major/minor блочного устройства изменились.

NFSv4 (RFC 3010 - устарел, RFC 3530 - устарел, RFC 7530) не использует rpcbind, поддерживает NT ACL и сохраняет информацию о состоянии клиентов. Только режим TCP. Протоколы монтирования, блокировки и статуса встроены непосредственно в NFSv4. При монтировании аутентифицируется конечный пользователь, а не хост (причём по IP) как в NFSv3.

NFSv4.1 (RFC 5661, RFC 5662, RFC 5663, RFC 5664, RFC 6688) вводит расширения: pNFS (параллельное распределение доступа к файлам), сессии, многосерверное пространство имён, ACL, делегирование каталогов и извещения,

Процедуры RPC NFS2 и NFS3

Процедуры NFS (в NFS3 каждый вызов, изменяющий атрибуты файла, возвращает их новое значение):

Аутентификация и авторизация

Для авторизации запросов при использовании RPC аутентификации AUTH_UNIX используются uid и gid передаваемые клиентом, т.е. сервер полностью доверяет клиенту, а единственной возможностью проверить клиента является его IP адрес и таблицы преобразования идентификаторов (обычно производится на сервере по статической таблице или таблица создаётся в момент монтирования).

Обычно uid=0 клиента преобразуется в UID_NOBODY (nfsnobody, 65534, -2) на сервере, кроме случаев использования NFS в качестве корневой файловой системы.

Предполагается возможность использовать аутентификацию AUTH_DES или AUTH_KERB.

Протокол монтирования

Прежде чем обратиться к файлу на удалённой файловой системе клиент (ОС клиента) должен смонтировать её и получить от сервера указатель на неё с помощью явной команды mount или с помощью одного из расплодившихся автоматических монтировщиков (amd, autofs, automount, supermount, superpupermount). Для этого клиентская программа монтирования (mount, amd) с помощью rpcbind определяет номер порта, на котором на сервере слушает программа RPC mount нужной версии (1, 2, 3), обращается к ней за указателем на корень требуемой файловой системы, далее этот указатель хранится на клиентской машине до размонтирования и используется при открытии файлов на удалённой файловой системе. Протокол RPC mount 1 используется совместно с NFS2, аутентификация AUTH_UNIX или AUTH_NONE (RFC 1094). Состояния клиентов хранятся. Может использовать как UDP, так и TCP. Сервер проверяет права клиента, основываясь на его IP адресе и "привилегированности" исходящего порта. Совместно с NFS3 используется RPC mount 3 (RFC 1813), максимальный размер простого имени файла - 255, составного - 1024.

Процедуры протокола RPC mount 1 (RFC 1094):

Процедуры протокола RPC mount 3 (RFC 1813):

Сервер монтирования

Список экспортируемых каталогов (в RH4.2, RH5.2 и RH9 используется непосредственно nfsd и mountd; в FC4 используется утилитой exportfs) задаётся в файле /etc/exports в виде отдельных строк для каждого каталога с указанием допустимых клиентов и опций монтирования для них (строки комментариев начинаются с '#', после редактирования файла необходимо перезагрузить (reload) сервис nfs):
имя-каталога описание-клиента(опции,через,запятую) [описание-клиента(опции,через,запятую) ...]

Описание клиента:

Опции (по умолчанию, в FC4: sync, ro, root_squash, no_all_squash, wdelay, secure, hide, subtree_check, secure_locks, nocrossmnt; в RHEL5: ro, wdelay, root_squash):

Утилита exportfs (RH9, FC3, FC4, FC5) управляет списком экспортируемых с сервера файловых систем. Список хранится в файле /var/lib/nfs/etab, список смонтированных клиентами файловых систем хранится в /var/lib/nfs/xtab), используется mountd при запросе на монтирование с удалённого компьютера. Представления ядра 2.6 об экспортируемых файловых системах (активная часть) в файле /proc/fs/nfsd/exports, лежащем в виртуальной файловой системе типа nfsd в точке монтирования /proc/fs/nfsd. Файл /proc/fs/nfs/exports содержит список когда-либо затребованных клиентами точек монтирования (?). Утилита exportfs в режиме ядра 2.6 выдаёт информацию только для mountd (через /var/lib/nfs/xtab) и не общается с ядром напрямую. В режиме ядра 2.4 (или не смонтирована /proc/fs/nfsd) запросы с описанием конкретных хостов (не подсетки и не сетевые группы) напрямую передаются в ядро наряду с записью в /var/lib/nfs/xtab, а также запросы из /var/lib/nfs/rmtab (записи о существующих монтированиях для клиентов, сохраняются при перезагрузках и похоже навсегда) передаются в ядро. Насколько я понял, таблица ядра не может работать с шаблонами адресов. Без параметров выдаёт список текущих экспортируемых файловых систем. Параметры exportfs:

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

Сервер rpc.mountd запускается из сервиса /etc/init.d/nfs:

Параметры можно задавать в /etc/sysconfig/nfs:

Заметьте, что монтирование в NFSv2 и NFSv3 осуществляется от имени хоста клиента, а не от конкретного пользователя, что требует изрядного доверия к администратору данного хоста. Причём хост определяется по имени (IP адресу). NFSv4 аутентифицирует конечного пользователя (RPCSEC_GSS, Kerberos 5).

Имеется поддержка tcp_wrapper (имя программы - mountd).

Протокол блокировки

Протокол блокировки файлов Network Lock Manager (NLM, RFC 1813, X/OpenNFS) версии 3 (для NFS2) и 4 (для NFS3) обеспечивает возможность блокировки файлов и записей. Клиент NFS должен быть готов к его отсутствию на сервере. После запуска сервера некоторое время (grace period, 45 секунд) принимаются только восстановления блокировок, новые блокировки не принимаются. Блокировки делятся на отслеживаемые и неотслеживаемые. Отслеживаемые блокировки должны восстанавливаться после перезапуска сервера без участия клиента и сбрасываться при сбое клиента. Для реализации отслеживаемых блокировок требуется наличие серверов мониторинга состояния (NSM) на сервере и клиенте. Перед запросом блокировки клиент NLM выдаёт запрос к своему NSM на мониторинг сервера. Сервер перед выполнением запроса на блокировку выдаёт запрос к своему NSM на мониторинг клиента. По снятию блокировки или отказу от неё мониторинг клиента снимается. При перезагрузке сервера его NSM извещает все клиентские NSM об изменении состояния. Те, в свою очередь, извещают заинтересованные локальные NLM клиенты, которые восстанавливают блокировки во время "льготного" периода. При перезагрузке клиента его NSM извещает все серверные NSM об изменении состояния. Те, в свою очередь, извещают заинтересованный локальный NLM сервер, который снимает все блокировки от данного клиента.

Неотслеживаемые блокировки (SHARE, UNSHARE, NM_LOCK, FREE_ALL) предназначены для совместимости с однозадачными ОС типа DOS. Клиент должен самостоятельно заботиться о восстановлении блокировок после перезапуска сервера и освобождать старые блокировки при своей перезагрузке.

В основном, NLM4 отличается от NLM3 увеличение длины и смещения в файле с 32 до 64 бит.

NLM4 может использовать как UDP, так и TCP протокол (RPC 100021, версия 4). Процедуры:

Асинхронные запросы

Асинхронные ответы

Сервер блокировки

Сервер блокировки rpc.lockd (/etc/init.d/nfslock, /var/lock/subsys/nfslock, параметры из /etc/sysconfig/nfs). Запускается в пространстве пользователя только для старых ядер (до 2.2.18). Для новых ядер запускается как модуль ядра (lockd). Параметры в /etc/sysconfig/nfs:

Параметры модуля ядра

Или задать те же параметры с помощью sysctl: 

/sbin/sysctl -w fs.nfs.nlm_tcpport=номер-порта
/sbin/sysctl -w fs.nfs.nlm_udpport=номер-порта

Протокол мониторинга состояния

Сервер NSM (Network Status Monitor) обеспечивает приложения информацией о состоянии хостов, установивших блокироки, и хостов, держащих блокировки. NSM сервер хранит информацию о текущем состоянии своего хоста и предоставляет информацию об изменении состояния другим NSM серверам (NSM сервера равноправны). Состояние представляет собой монотонно увеличивающееся число. Чётное - когда сервер остановлен, нечётное - когда он работает. NSM не мониторит другие серверы, а терпеливо ждёт от них извещения (NOTIFY). Каждый сервер NSM держит у себя список соседей (имена хостов, хранится в постоянной памяти), состояние которых необходимо отслеживать для локальных клиентов (добавляются запросом MON), который хранится в постоянной памяти. Соседей из этого же списка NSM сервер извещает процедурой NOTIFY при изменении состояния своего хоста.

Сервер NSM обязан реализовать поддержку протокола UDP, в дополнение может реализовать поддержку TCP протокола (RPC 100024, версия 1). Процедуры:

Сервер мониторинга состояния

Сервер мониторинга состояния rpc.statd. Запускается из сервиса nfslock (/etc/init.d/nfslock). Список отслеживаемых хостов хранится в /var/lib/nfs/statd/sm/. Параметры:

Параметры могут задаваться в /etc/sysconfig/nfs:

Имеется поддержка tcp_wrapper (имя программы - statd).

Протокол ограничения использования ресурсов

Сервер ограничения использования ресурсов

Сервер ограничения использования ресурсов rpc.rquotad. Запускается из /etc/init.d/nfs. Параметры можно задавать в /etc/sysconfig/nfs:

Параметры:

Имеется поддержка tcp_wrapper (имя программы - rquotad).

Сервер преобразования идентификаторов

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

[General]
Domain = имя-домена # должно совпадать на клиенте и сервере

[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

[Translation]
Method = nsswitch # umich_ldap и static

Запуск: 

[mkdir /var/lib/nfs/rpc_pipefs]
[mount -t rpc_pipefs sunrpc /var/lib/nfs/rpc_pipefs]
service rpcidmapd start

Все незнакомые клиенту uid и gid будут преобразованы в nobody.

Сервер NFS

Перед запуском NFS сервера необходимо убедиться в наличии сервиса portmap. Основная функциональность в модуле ядра nfsd.

Сервис nfs запускает серверы rpcsvcgssd, rpc.nfsd, rpc.mountd и rpc.rquotad (скрипт - /etc/init.d/nfs, параметры - /etc/sysconfig/nfs). Сервис nfslock запускает серверы rpc.lockd и rpc.statd (скрипт - /etc/init.d/nfslock). Сервис nfs-rdma (/etc/rdma/rdma.conf) обеспечивает NFS через RDMA (загружает модули svcrdma и xprtrdma).

Параметры для rpc.nfsd в /etc/sysconfig/nfs:

Ключи rpc.nfsd:

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

Версии серверов проще всего посмотреть с помощью команды "rpcinfo -p".

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

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

mount -t nfsd nfsd /proc/fs/nfsd

Файлы в /proc/fs/nfsd

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

Каталог /proc/sys/sunrpc содержит "ручки управления" отладочной печатью (сюда надо записывать битовые маски классов отладочной печати: RPCDBG_, NFSDBG_, NFSDDBG_, NLMDBG_ в include/linux/sunrpc/debug.h, include/linux/nfs_fs.h, include/linux/nfsd/debug.h и include/linux/lockd/debug.h; вывод идёт в syslog в раздел kernel):

rpc_debug (44):

nfs_debug (241):

nfsd_debug (759):

nlm_debug (511):

Клиент монтирования

Чтобы смонтировать файловую систему NFS командой mount необходимо указать тип файловой системы (-t nfs[4]), вместо блочного устройства указать имя-хоста:каталог и указать точку монтирования. Размонтировать можно с помощью обычной команды umount (она не извещает сервер). Если необходимо размонтировать не дожидаясь завершения процессов, то можно использовать ключ "-f" в Solaris (процессы получат сообщения об ошибках ввода-вывода) или ключ "-l" в Linux (реальное размонтирование произойдёт по завершению процесса). Опции монтирования можно указать в /etc/fstab, в командной строке после ключа -o или в настройках автомонтировщика:

Настройка производительности

Рекомендации для максимальной потоковой скорости (nfs-tuning-secrets-130-lca2008-d7.odp):

NFSv4

Описывается в RFC 7530 (RFC 3530). Не требуется portmap (хотя RPC используется), rpc.lockd и rpc.statd, rpc.mountd имеется, но он не обменивается данными с клиентом, необходим rpc.idmapd (т.е. соответствие имён пользователей на сервере и клиенте текстовое, а не по uid/gid), имеется поддержка ACL (Windows NT, а не POSIX!), сервер хранит информацию о клиентах (stateful), что позволяет клиентам безопасно кешировать данные и метаданные (используется механизм делегирования - delegations, leases; клиенты NFSv3 кешируют "на удачу" - в надежде, что в ближайшие секунды этот файл никому не будет нужен).

В RHEL5 имеются сервер и клиент NFSv4. Файловые системы экспортируются в виде единой псевдофайловой системы NFSv4 (в настройках которой указывается fsid=0), в которую необходимо подмонтировать все предназначенные на экспорт файловые системы: 

mkdir /exports
mkdir /exports/test1
mkdir /exports/test2
mount --bind /test1 /exports/test1
mount --bind /test2 /exports/test2
exportfs -o fsid=0[,no_subtree_check] /exports
exportfs -o rw,nohide[,fsid=1][,no_subtree_check] /exports/test1
exportfs -o rw,nohide[,fsid=2][,no_subtree_check] /exports/test2

Монтирование (имена импортируемых файловых систем указываются относительно корневой файловой системы): 

mount -t nfs4 -o hard имя-сервера:/ /mnt # статистика не о той файловой системе
  или
mount -t nfs4 -o hard имя-сервера:/test1 /mnt # доступно только содержимое test1

В RHEL5.7 в настройках сервиса rpcidmapd (/etc/idmapd.conf) указан домен localdomain, если эту строку закоментировать и перезапустить службу rpcidmapd, то имя домена для отображения будет извлекаться из DNS имени хоста. В RHEL5.8 - ошибка исправлена.

В RHEL6 экспортировать файловую систему можно "по старому", без использования дерева /exports. Правила монтирования описаны в /etc/nfsmount.conf.

Сервер может отсылать клиента на другой сервер указав в параметрах экспорта: "refer=/export@другой-сервер".

NFS и RDMA в RHEL6

Необходимо установить InfiniBand и IPoIB, настроить сеть и запустить opensm. Добавить на сервере RDMA_PORT=20049 в /etc/sysconf/nfs. На клиенте загрузить модуль xprtrdma и монтировать с опциями rdma и port=20049. Подробности смотри в Documentation/filesystems/nfs/nfs-rdma.txt. RFC 5532, RFC 5666.

NFSv4.1

Протокол NFSv4.1 является не расширением NFSv4, а самостоятельным протоколом. Описывается в RFC 5661-5667.

Параллельное расширение NFSv4.1

Сервер pNFS и клиент обмениваются только метаданными (разметка, layout, pNFS протокол). Разметка хранится в каталоге на сервере и может кешироваться клиентами. Сервер хранит информацию о клиентах, т.е. не является stateless, есть понятие "open" - команды LOOKUP+OPEN, LAYOUTGET, LAYOUTRETURN, LAYOUTCOMMIT. Сервер асинхронно извещает клиентов об изменениях разметки (CB_LAYOUTRECALL). Содержимое файлов хранится на отдельных серверах системы хранения данных. Протокол управления (не стандартизован) позволяет серверу управлять распределением файлов по серверам хранения. Протокол доступа к системе хранения данных позволяет клиентам осуществлять параллельный доступ к содержимому файлов. Возможны системы хранения различного типа:

Головным разработчиком pNFS для Linux является CITI (University of Michigan Center for Information Technology Integration).

В RHEL6.2 доступен клиент только файлового типа (бета), в RHEL7 - всех трёх. Сервер pNFS для Linux в виде прототипа поддерживает подлежащие файловые системы GFS2/OCFS2 (файловый тип хранения), EXOFS (объектный тип хранения), ext4/btrfs/xfs (блочный тип хранения). Ядро 4.0 включает блочный сервер. GlusterFS 3.7 умеет экспортировать по pNFS (с помощью NFS-Ganesha).

rpcdebug и прочие средства отладки

Утилита rpcdebug позволяет включить (-s) или отключить (-c) различные типы трассировки (-s) в syslog модулей (-m) rpc, nfs, nfsd, nlm. Типы трассировки можно узнать выдав "rpcdebug -vh". Статистику на стороне клиента можно получить с помощью "iostat -n", nfsiostat и mountstats.

Удивительно много статистики можно получить из /proc/self/mountstats. Расшифровка: общая, Bytes и Events, Xptr, Ops.

Ссылки
@ Карта сайта News Автора!

Bog BOS: NFS - сетевая файловая система

Последние изменения:
2024.11.11: sysadmin: Linux: пространства имён
2024.11.06: sysadmin: настройка TCP/IP в Linux: виртуальный интерфейс и виртуальный мост
2024.10.25: sysadmin: Linux VFS, атрибуты, расширенные атрибуты, ACL
2024.10.22: sysadmin: Монтирование файловых систем: bind, shared и OverlayFS
Copyright © 1996-2024 Sergey E. Bogomolov; www.bog.pp.ru