Протокол NFS. Network File System (NFS) - сетевая файловая система

Когда речь идет о компьютерных сетях, зачастую можно услышать упоминание NFS. Что такое означает эта аббревиатура?

Это протокол распределенной файловой системы, первоначально разработанный компанией Sun Microsystems в 1984 году, позволяющий пользователю на клиентском компьютере получать доступ к файлам через сеть, подобно доступу к локальному хранилищу. NFS, как и многие другие протоколы, основывается на системе Open Network Computing Remote Procedure Call (ONC RPC).

Другими словами, что такое NFS? Это открытый стандарт, определенный в Request for Comments (RFC), позволяющий любому реализовать протокол.

Версии и вариации

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

NFS v2

Версия 2 первоначально работала только по протоколу User Datagram Protocol (UDP). Ее разработчики хотели сохранить серверную сторону без блокировки, реализованной за пределами основного протокола.

Интерфейс виртуальной файловой системы позволяет выполнять модульную реализацию, отраженную в простом протоколе. К февралю 1986 года были продемонстрированы решения для таких операционных систем, как System V release 2, DOS и VAX/VMS с использованием Eunice. NFS v2 позволял считывать только первые 2 ГБ файла из-за 32-разрядных ограничений.

NFS v3

Первое предложение по разработке NFS версии 3 в Sun Microsystems было озвучено вскоре после выпуска второго дистрибутива. Главной мотивацией была попытка смягчить проблему производительности синхронной записи. К июлю 1992 года практические доработки позволили решить многие недостатки NFS версии 2, оставив при этом лишь недостаточную поддержку файлов (64-разрядные размеры и смещения файлов).

• поддержку 64-битных размеров и смещений файлов для обработки данных размером более 2 гигабайт (ГБ);
• поддержку асинхронной записи на сервере для повышения производительности;
• дополнительные атрибуты файлов во многих ответах, позволяющие избежать необходимости их повторного извлечения;
• операцию READDIRPLUS для получения данных и атрибутов вместе с именами файлов при сканировании каталога;
• многие другие улучшения.

Во время введения версии 3 поддержка TCP как протокола транспортного уровня начала увеличиваться. Использование TCP в качестве средства передачи данных, выполненного с использованием NFS через WAN, стало позволять передавать большие размеры файлов для просмотра и записи. Благодаря этому разработчики смогли преодолеть пределы ограничений в 8 КБ, налагаемые протоколом пользовательских дейтаграмм (UDP).

Что такое NFS v4?

Версия 4, разработанная под влиянием Эндрской файловой системы (AFS) и блока сообщений сервера (SMB, также называемая CIFS), включает в себя повышение производительности, обеспечивает лучшую безопасность и вводит протокол с соблюдением установленных условий.

Версия 4 стала первым дистрибутивом, разработанным в Целевой группе Internet Engineering Task Force (IETF) после того, как Sun Microsystems передала разработку протоколов сторонним специалистам.

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

Новейший протокол файловой системы - NFS 4.2 (RFC 7862) - был официально выпущен в ноябре 2016 года.

Другие расширения

С развитием стандарта появились и соответствующие инструменты для работы с ним. Так, WebNFS, расширение для версий 2 и 3, позволяет протоколу сетевого доступа к файловым системам легче интегрироваться в веб-браузеры и активировать работу через брандмауэры.

Различные протоколы сторонних групп стали также ассоциироваться с NFS. Из них наиболее известными выступают:

• Network Lock Manager (NLM) с поддержкой протокола байтов (добавлен для поддержки API-блокировки файлов UNIX System V);
• удаленной квоты (RQUOTAD), который позволяет пользователям NFS просматривать квоты на хранение данных на серверах NFS;
• NFS через RDMA - адаптация NFS, которая использует дистанционный прямой доступ к памяти (RDMA) в качестве средства передачи;
• NFS-Ganesha - сервер NFS, работающий в пользовательском пространстве и поддерживающий CephFS FSAL (уровень абстракции файловой системы) с использованием libcephfs.

Платформы

Network File System часто используется с операционными системами Unix (такими как Solaris, AIX, HP-UX), MacOS от Apple и Unix-подобными ОС (такими как Linux и FreeBSD).

Он также доступен для таких платформ, как Acorn RISC OS, OpenVMS, MS-DOS, Microsoft Windows, Novell NetWare и IBM AS/400.

Альтернативные протоколы удаленного доступа к файлам включают в себя блок сообщений сервера (SMB, также называемый CIFS), протокол передачи Apple (AFP), базовый протокол NetWare (NCP) и файловую систему сервера OS/400 (QFileSvr.400).

Это связано с требованиями NFS, которые ориентированы по большей части на Unix-подобные «оболочки».

При этом протоколы SMB и NetWare (NCP) применяются чаще, чем NFS, в системах под управлением Microsoft Windows. AFP наиболее широко распространен в платформах Apple Macintosh, а QFileSvr.400 наиболее часто встречается в OS/400.

Типичная реализация

Предполагая типичный сценарий в стиле Unix, в котором одному компьютеру (клиенту) нужен доступ к данным, хранящимся на другом (сервер NFS):

• Сервер реализует процессы Network File System, запущенные по умолчанию как nfsd, чтобы сделать свои данные общедоступными для клиентов. Администратор сервера определяет, как экспортировать имена и параметры каталогов, обычно используя файл конфигурации/etc/exports и команду exportfs.
• Администрирование безопасности сервера гарантирует, что он сможет распознавать и утверждать проверенного клиента. Конфигурация его сети гарантирует, что соответствующие клиенты могут вести переговоры с ним через любую систему брандмауэра.
• Клиентская машина запрашивает доступ к экспортированным данным, как правило, путем выдачи соответствующей команды. Она запрашивает сервер (rpcbind), который использует порт NFS, и впоследствии подключается к нему.
• Если все происходит без ошибок, пользователи на клиентской машине смогут просматривать и взаимодействовать с установленными файловыми системами на сервере в пределах разрешенных параметров.

Следует обратить внимание и на то, что автоматизация процесса Network File System также может иметь место - возможно, с использованием etc/fstab и/или иных подобных средств.

Развитие на сегодняшний день

К 21-му столетию протоколы-конкуренты DFS и AFS не достигли какого-либо крупного коммерческого успеха по сравнению с Network File System. Компания IBM, которая ранее приобрела все коммерческие права на вышеуказанные технологии, безвозмездно передала большую часть исходного кода AFS сообществу свободных разработчиков программного обеспечения в 2000 году. Проект Open AFS существует и в наши дни. В начале 2005 года IBM объявила о завершении продаж AFS и DFS.

В свою очередь, в январе 2010 года компания Panasas предложила NFS v 4.1 на основе технологии, позволяющей улучшить возможности параллельного доступа к данным. Протокол Network File System v 4.1 определяет метод разделения метаданных файловой системы из местоположения определенных файлов. Таким образом, он выходит за рамки простого разделения имен/данных.

Что такое NFS этой версии на практике? Вышеуказанная особенность отличает его от традиционного протокола, который содержит имена файлов и их данных под одной привязкой к серверу. При реализации Network File System v 4.1 некоторые файлы могут распределяться между многоузловыми серверами, однако участие клиента в разделении метаданных и данных ограничено.

При реализации четвертого дистрибутива протокола NFS-сервер представляет собой набор серверных ресурсов или компонентов; предполагается, что они контролируются сервером метаданных.

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

Для раздачи файлов внутри локальной сети можно выделить такие технологии (рассматриваются системы на базе Linux):

• Network File System (NFS) - протокол сетевого доступа к файловым системам;
• Files transferred over Shell protocol (FISH) - сетевой протокол, который использует или RSH для передачи файлов между компьютерами;
• Secure SHell FileSystem (SSHFS) - клиент файловой системы для монтирования дисковых устройств на удаленных системах, для взаимодействия с удаленной системой используется SFTP ;
• Samba - пакет программ, которые позволяют обращаться к сетевым дискам и принтерам на различных операционных системах по протоколу SMB/CIFS;

В данной заметке речь пойдет про NFS .

NFS (Network File System) полезна когда нужно раздать файлы/директории всем внутри сети. Прозрачность доступа с помощью NFS позволяет клиентам подключить удаленную файловую систему как локальную директорию, причем файловые системы могут быть разных типов. Это означает, что любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с файлом подключенным по NFS , без каких либо модификаций самой программы.

К преимуществам NFS можно отнести:

На данный момент доступна NFS v4.1 , в которой ввели новую возможность pNFS позволяющей распараллелить реализацию общего доступа к файлам. Также есть расширение для NFS 2 и 3 - WebNFS , которое позволяют легче интегрироваться в веб-браузеры и дает возможность работать через брандмауэр.

Схема работы NFS протокола.

Установка и настройка NFS-сервер под Linux

Проверим поддерживает ли система NFS

Cat /proc/filesystems | grep nfs

Под Arch Linux сервер и клиент находиться в одном пакете

Yaourt -S nfs-utils

Для установки сервера (nfs-kernel-server ) и клиента (nfs-common ) под Ubuntu необходимы пакеты

Sudo apt-get install nfs-kernel-server nfs-common portmap

Дальше в заметке для сервера будет использоваться IP 192.168.1.100 . Для того что бы за сервером всегда был закреплен один и тот же IP необходимо в DHCP-сервере (чаще всего роутер) указать раздачу конкретного IP конкретному MAC-адресу. Или поднять свой локальный DNS-сервер. Например или .

MAC-адрес можно узнать с помощью ifconfig (поле ether в Arch Linux ).

NFSv4 предполагает что есть корневая директория, внутри которой уже расположены файлы для раздачи. Например, /srv/nfs - корень, /srv/nfs/audio - директория для раздачи музыки. Если не следовать этому новому указанию в версии 4 , то можно получить ошибку при подключении клиентом:

Mount.nfs: access denied by server while mounting 192.168.1.100:/home/proft/torrents

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

# для команды mount mount -o "vers=3" 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents # для fstab 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents nfs soft,nfsvers=3 0 0

Я буду использовать NFSv4 с root-директорией в /srv/nfs/ и монтированием вложенных директорий с помощью mount --bind .

Предположим, что мы хотим

• раздавать директорию ~/torrents с rw доступом для всех внутри локальной сети;
• раздавать директорию ~/photos с ro доступом для хоста с IP 192.168.1.101 ;

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

Sudo mkdir -p /srv/nfs/{torrents,photos}

Примонтируем существующие директории torrents, photos в /srv/nfs .

# sudo vim /etc/fstab /home/proft/torrents /srv/nfs/torrents none bind 0 0 /home/proft/photos /srv/nfs/photos none bind 0 0

Отредактируем /etc/exports , в котором описываются все директории для совместного доступа

# sudo vim /etc/exports # формат файла: directory allowed-hosts(options) /srv/nfs/torrents 192.168.1.1/24(rw,async) /srv/nfs/photos 192.168.1.101(ro,async)

Обратите внимание на отсутствие пробела между allowed-hosts и (options) . Наличие пробела вводит другую трактовку правил.

Доступные опции:

• ro (rw) - разрешить доступ только на чтение (чтение/запись);
• subtree_check (no_subtree_check) - в некоторых случаях приходится экспортировать не весь раздел, а лишь его часть. При этом сервер NFS должен выполнять дополнительную проверку обращений клиентов, чтобы убедиться в том, что они предпринимают попытку доступа лишь к файлам, находящимся в соответствующих подкаталогах. Такой контроль поддерева (subtree checks ) несколько замедляет взаимодействие с клиентами, но если отказаться от него, могут возникнуть проблемы с безопасностью системы. Отменить контроль поддерева можно с помощью опции no_subtree_check . Опция subtree_check , включающая такой контроль, предполагается по умолчанию. Контроль поддерева можно не выполнять в том случае, если экспортируемый каталог совпадает с разделом диска;
• sync (async) - указывает, что сервер должен отвечать на запросы только после записи на диск изменений, выполненных этими запросами. Опция async указывает серверу не ждать записи информации на диск, что повышает производительность, но понижает надежность, т.к. в случае обрыва соединения или отказа оборудования возможна потеря данных;
• noaccess - запрещает доступ к указанной директории. Может быть полезной, если перед этим был задан доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям;
• no_root_squash – по умолчанию пользователь root на клиентской машине не будет обладать теми же правами к директории на сервера. Эта опция снимает это ограничение;
• nohide - NFS автоматически не показывает нелокальные ресурсы (например, примонтированые с помощью mount --bind), эта опция включает отображение таких ресурсов;
• insecure - использование непривилегированных портов (> 1024);

Запускаем NFS-сервер

# под archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # под ubuntu sudo /etc/init.d/nfs-kernel-server start

В дальнейшем при изменении конфигурационного файла достаточно его перечитать командой:

Sudo exportfs -rav

Команда rpcinfo -p | grep nfs позволяет проверить успешность запуска сервера.

Клиент под Linux

Установка

# под archlinux yaourt -S nfs-utils # под ubuntu sudo apt-get install portmap nfs-common

Создадим директории для монтирования сетевых ресурсов torrents и photos

Mkdir -p ~/nfs/{torrents,photos}

Для ручного монтирования выполним

Sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/torrents /home/proft/nfs/torrents sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/photos /home/proft/nfs/photos

Опция soft указывает тихо отменить попытки подключить шару после определенного количества времени (время задается опцией retrans ). Подробнее в man nfs .

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

Для автоматического монтирования редактируем файл /etc/fstab

# sudo vim /etc/fstab 192.168.1.100:/srv/nfs/torrents /home/proft/net/torrents nfs rw,soft 0 0 192.168.1.100:/srv/nfs/photos /home/proft/net/photos nfs ro,soft 0 0

Но и у этого способа есть свои недостатки, например, если сервер не доступен то загрузка клиента может подвиснуть из-за попыток подключиться к NFS-серверу. Для исправления этого см. ниже про AutoFS .

AutoFS - автоматическое подключение сетевых ресурсов

Есть возможность монтировать удаленный ресурс с помощью AutoFS при первом обращении и автоматически отмонтировать при отсутствии активности.

AutoFS использует для настройки шаблоны, расположенные в /etc/autofs . Основной шаблон называется auto.master , он может указывать на один или несколько других шаблонов для конкретных типов носителей.

Установка

# под archlinux yaourt -S autofs # под ubuntu sudo apt-get install autofs

Существует несколько способов указать способы автомонтирования. Я использую такой: в /home/proft/nfs автоматически создается директория с именем NFS-сервера, в которой автоматически создаются доступные директории на сервере.

# sudo vim /etc/autofs/auto.master /home/proft/nfs /etc/autofs/auto.nfs --timeout=60

Дополнительный параметр timeout устанавливает количество секунд после которых устройство будет размонтировано. Параметр ghost указывает что сконфигурированные ресурсы будут отображаться всегда, а не только тогда, когда они доступны (эта опция включена по умолчанию в AutoFS 5 )

Опишем в /etc/autofs/auto.nfs NFS-сервер и root-директорию.

# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs

Теперь при первом обращении /home/proft/nfs/torrents произойдет автоматическое монтирование NFS-ресурса.

Перезапустим службу autofs:

# под archlinux sudo systemctl restart autofs # под ubuntu sudo /etc/init.d/autofs restart

Еще можно указать время ожидания доступности NFS-ресурса. Для этого необходимо изменить значения MOUNT_WAIT .

# под archlinux # sudo vim /etc/conf.d/autofs MOUNT_WAIT=5 # под ubuntu sudo /etc/default/autofs MOUNT_WAIT=5

Форсирование использования NFS v3

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

Удобное решение для доступа к распределенной файловой системе

Файловая система - это необходимость. Мы работаем на компьютерах, предоставляющих доступ к принтерам, камерам, базам данных, удаленным датчикам, телескопам, компиляторам и мобильным телефонам. Эти устройства имеют мало общего - в частности, многие из них стали реальностью уже после того, как Интернет стал повсеместным явлением (например, электронные фотокамеры и мобильные устройства, выполняющие функции маленьких компьютеров). Однако всем им необходима файловая система для хранения и защищенного доступа к информации.

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

Сетевые файловые системы и другие священнодействия

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

Распределенные вычисления против сетевых

Традиционные сетевые протоколы не много могут предложить для организации вычислений, распределенных между компьютерами и, тем более, между сетями. Только безрассудные программисты полагались бы на протокол передачи данных и оптические кабели для организации параллельных вычислений. Обычно мы полагаемся на последовательную модель, в которой после установления соединения начинают работать протоколы канального уровня, выполняющие довольно сложную процедуру приветствия между сетевыми картами. Параллельные вычисления и распределенные файловые системы больше не зависят от IP или Ethernet. В настоящее время мы можем их просто не принимать во внимание, говоря о производительности. Однако проблемы защиты - это другое дело.

Одним из звеньев головоломки является способ организации доступа к файлам в компьютерной системе. Сейчас для системы, осуществляющей доступ к файлам, является несущественным, доступны ли необходимые файлы на одном компьютере, или они расположены по каким-либо причинам на нескольких компьютерах. В настоящее время семантика файловой системы и структуры данных файловой системы являются двумя очень разными темами. Семантика файловой системы Plan 9 или распределенной файловой системы AFS-стиля (Andrew File System) скрывает способ организации файлов или способ отображения файловой системы на аппаратное и сетевое обеспечение. NFS не обязательно скрывает способ хранения файлов и каталогов на удаленных файловых системах, но она также не раскрывает действительный аппаратный способ хранения файловых систем, каталогов и файлов.

NFS: Решение UNIX-проблемы

Доступ к распределенной файловой системе, тем не менее, требует несколько больше пары команд, разрешающих пользователям монтировать каталог, который расположен на другом компьютере в сети. Sun Microsystems столкнулась с этой проблемой несколько лет назад, когда начинала распространять нечто, названное Remote Procedure Calls (RPCs), и NFS.

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

Конечно же, NFS делает больше, чем предоставление доступа к текстовым файлам. Вы можете также распределять по NFS "запускаемые" приложения. Процедуры системы защиты служат для предохранения сети от вредоносного вмешательства исполняемых файлов. Но как именно это происходит?

NFS - это RPC

NFS традиционно определяется как RPC-приложение, требующее наличия TCP для NFS-сервера, а также либо TCP, либо другого не перегружающего сеть протокола для NFS-клиента. Организация Internet Engineering Task Force (IETF) опубликовала Request for Comments (RFC) для RPC в RFC 1832. Другой жизненно важный для функционирования NFS-реализации стандарт описывает форматы данных, используемые NFS; он был опубликован в RFC 1831 как документ "External Data Representation" (XDR).

Другие RFC имеют дело с защитой и алгоритмами шифрования, используемыми при обмене информацией для аутентификации во время NFS-сессий, но мы сначала остановимся на базовых механизмах. Одним из протоколов, которые нас интересуют, является протокол Mount , описанный в Приложении 1 RFC 1813.

Этот RFC описывает, какие протоколы обеспечивают функционирование NFS, но в нем не описывается, как NFS функционирует в настоящее время . Вы уже узнали кое-что важное, а именно - NFS-протоколы задокументированы в виде IETF-стандартов. После того, как последняя версия NFS застряла на цифре 3, RPC-протоколы не развивались дальше информационной фазы RFC и воспринимались, в основном, как не выходящие за пределы интересов (предположительно) огромной инженерной рабочей группы Sun Microsystems и патентованных разновидностей UNIX. С 1985 года Sun выпустила несколько версий NFS, на несколько лет предвосхитившей большинство современных разновидностей файловых систем. Sun Microsystems передала контроль над NFS организации IETF в 1998 году, и большая часть работы над NSF версии 4 (NFSv4) проводилась под эгидой IETF.

То есть, работая сегодня с RPC и NFS, вы работаете с версией, которая отражает интересы компаний и групп, не имеющих отношения к Sun. Однако многие инженеры Sun сохраняют глубокий интерес к разработке NFS.

NFS версии 3

NFS в своем воплощении в виде версии 3 (NFSv3) не сохраняет свое состояние (не является stateful), а NFSv4 сохраняет. Это фундаментальное выражение сегодня едва ли кого-то удивляет, хотя мир TCP/IP, на котором построена NFS, по большей части не сохраняет своего состояния (stateless) - факт, который помогает компаниям, производящим программное обеспечение для анализа трафика и системы защиты, чувствовать себя довольно хорошо.

Протокол NFSv3 должен был полагаться на несколько дополнительных протоколов для прозрачного монтирования каталогов на удаленных компьютерах, чтобы не зависеть от используемых на них механизмов файловых систем. NFS не всегда преуспевала в этом. Хороший пример - протокол Mount вызывал начальный идентификатор файла, в то время как протокол Network Lock Manager занимался блокировкой файла. Обе операции нуждались в текущем состоянии, которое протокол NFSv3 не предоставлял. Следовательно, имели место сложные взаимодействия между уровнями протоколов, которые не отражали аналогичные механизмы потоков данных. Кроме того, если добавить тот факт, что создание файла и каталога в Microsoft® Windows® осуществляется совершенно не так, как в UNIX, ситуация еще более усложнится.

Протокол NFSv3 должен был использовать порты для предоставления некоторых из его вспомогательных протоколов; при этом получается довольно сложная картина портов, уровней протоколов и сопутствующих всему этому вопросов безопасности. Сегодня от такой модели функционирования отказались, и все операции, которые ранее выполняли реализации вспомогательных протоколов через индивидуальные порты, управляются протоколом NFSv4 через один хорошо известный порт.

Протокол NFSv3 был также готов для работы с файловыми системами, поддерживающими Unicode - преимущество, которое до конца 1990-х годов оставалось в некоторой степени чисто теоретическим. Он хорошо соответствовал семантике файловой системы UNIX и явился причиной создания конкурирующих реализаций файловых систем, таких как AFS и Samba. Не удивительно, что Windows-поддержка была бедной, но файловые серверы Samba обеспечивали общий доступ к файлам для систем UNIX и Windows.

NFS версии 4

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

Все NFS-версии определяли каждую единицу работы в понятиях операций RPC-клиента и сервера. Каждый NFSv3-запрос требовал довольно значительного количества RPC-вызовов и вызовов операций открытия портов для выдачи результата. Версия 4 упростила это, введя понятие так называемой составной (compound) операции, к которой относится большое количество операций над объектами файловой системы. Прямым эффектом, разумеется, стало значительно меньшее количество RPC-вызовов и меньший объем данных, которые нужно передавать по сети, даже при том, что каждый RPC-вызов нес, по сути, больше данных, выполняя значительно больший объем работы. Было приблизительно подсчитано, что RPC-вызовы в NFSv3 требовали в пять раз большее количество клиент-серверных взаимодействий по сравнению с составными RPC-процедурами.

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

Использование NFS

Установка NFS, в общем, аналогична установке Samba. На стороне сервера вы определяете файловые системы или каталоги для экспорта или совместного использования ; клиентская сторона монтирует эти каталоги. После монтирования удаленным клиентом NFS-каталога этот каталог становится доступен так же, как любой другой каталог локальной файловой системы. Настройка NFS на сервере - это простой процесс. Как минимум, вы должны создать или отредактировать файл /etc/exports и запустить NFS-демон. Для настройки более защищенной NFS-службы вы должны также отредактировать файлы /etc/hosts.allow и /etc/hosts.deny. NFS-клиент требует выполнения только команды mount . Дополнительная информация и параметры описаны в оперативной документации по Linux® (man page).

NFS-сервер

Записи в файле /etc/exports имеют понятный формат. Для организации совместного доступа к файловой системе измените файл /etc/exports и опишите файловую систему (с параметрами) в следующем общем формате:

Общие параметры

Для настройки вашей NFS-реализации доступно несколько общих параметров. К ним относятся:

• secure: Этот параметр (по умолчанию) использует для NFS-соединения доступный порт TCP/IP, меньший 1024. Указание insecure запрещает это.
• rw: Этот параметр разрешает NFS-клиентам доступ для чтения/записи. Доступ по умолчанию - только для чтения.
• async: Этот параметр может повысить производительность, но он может также вызвать потерю данных при перезапуске NFS-сервера без предварительной процедуры остановки NFS-демона. Настройка по умолчанию - sync .
• no_wdelay: Этот параметр отключает задержку при записи. Если установлен режим async , NFS игнорирует этот параметр.
• nohide: Если вы монтируете один каталог поверх другого, старый каталог обычно скрывается или выглядит пустым. Для запрета такого поведения разрешите параметр hide .
• no_subtree_check: Этот параметр отключает контроль подкаталогов, выполняющийся для некоторых проверок системой защиты, которые вы, возможно, не хотите игнорировать. Параметр по умолчанию - разрешить контроль подкаталогов.
• no_auth_nlm: Этот параметр при значении insecure_locks указывает NFS-демону не проводить аутентификацию во время запросов на блокировку. Параметр по умолчанию - auth_nlm или secure_locks .
• mp (mountpoint=path) : При явном объявлении этого параметра NSF требует монтирования экспортируемого каталога.
• fsid=num: Этот параметр обычно используется при организации системы восстановления после сбоя NFS. Если вы хотите реализовать восстановление после сбоя для NFS, обратитесь к документации по NFS.

Отображение пользователей

Через отображение пользователей в NFS вы можете отождествить псевдопользователя или реального пользователя и группы с пользователем, работающим с NFS-томом. NFS-пользователь имеет права пользователя или группы, которые позволяет отображение. Использование единого (generic) пользователя и группы для NFS-томов обеспечивает уровень защиты и гибкость без значительных усилий по администрированию.

При использовании файлов на NFS-монтированной файловой системе пользовательский доступ обычно "подавляется" (squashed). Это означает, что пользователь обращается к файлам как анонимный пользователь, который имеет доступ к этим файлам только по чтению. Это поведение особенно важно для пользователя root. Однако, существуют ситуации, когда вы хотите, чтобы пользователь обращался к файлам на удаленной системе как root или какой-либо другой определенный пользователь. NFS позволяет указать пользователя (по идентификационному номеру пользователя (UID) и идентификационному номеру группы (GID)) для доступа к удаленным файлам, и вы можете запретить нормальное поведение "подавления" по умолчанию.

К параметрам отображения пользователей относятся:

• root_squash: Этот параметр не позволяет пользователю root обращаться к смонтированному NFS-тому.
• no_root_squash: Этот параметр позволяет пользователю root обращаться к смонтированному NFS-тому.
• all_squash: Этот параметр, полезный для NFS-томов с открытым доступом, подавляет все UID и GID и использует только учетную запись анонимного пользователя. Установка по умолчанию - no_all_squash .
• anonuid и anongid: Эти параметры меняют UID и GID анонимного пользователя на указанную учетную запись.

В листинге 1 приведены примеры записей /etc/exports.

Листинг 1. Примеры записей /etc/exports

Первая запись экспортирует каталог /opt/files для всех хостов сети 192.168.0. Следующая запись экспортирует /opt/files для одного хоста: 192.168.0.120. Третья запись указывает хост 192.168.0.125 и предоставляет доступ по чтению/записи к файлам с правами пользователя, имеющего user id=210 и group id=100 . Последняя запись используется для общедоступного каталога и разрешает доступ только по чтению и только под учетной записью анонимного пользователя.

NFS-клиент

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

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

Для использования NFS в роли клиента на клиентском компьютере должен выполняться rpc.statd и portmap. Вы можете выполнить команду ps -ef для проверки присутствия двух этих демонов. Если они работают (как и должны), вы можете монтировать экспортируемый сервером каталог при помощи следующей общей команды:

Вообще говоря, при монтировании файловой системы вы должны работать как пользователь root. На удаленном компьютере вы можете использовать следующую команду (в предположении, что NFS-сервер имеет IP-адрес 192.168.0.100):

Ваш дистрибутив системы может потребовать указания типа файловой системы при ее монтировании. Если это так, используйте команду:

Удаленный каталог должен монтироваться безо всяких проблем, если вы корректно настроили сервер. Теперь выполните команду cd для перехода в каталог /mnt, затем команду ls для просмотра файлов. Для того чтобы сделать такое монтирование постоянным, вы должны изменить файл /etc/fstab и создать запись, аналогичную следующей:

Примечание: Дополнительная информация по записям /etc/fstab приведена в оперативной справке по fstab.

Критика NFS

Критика способствует улучшению

Критика, связанная с защищенностью NFS, была причиной многих улучшений в NSFv4. Создатели новой версии провели реальные мероприятия по усилению защищенности клиент-серверных взаимодействий. Фактически, они решили реализовать абсолютно новую модель системы защиты.

Для понимания модели системы защиты вы должны ознакомиться с интерфейсом прикладного программирования Generic Security Services (GSS-API) версии 2, редакции 1. GSS-API полностью описан в RFC 2743, который, к сожалению, является одним из наиболее сложных для понимания RFC-документов.

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

Соединения между NFS-клиентами и серверами защищаются посредством так называемой (довольно поверхностно) системы защиты strong RPC. NFSv4 использует стандарт Open Network Computing Remote Procedure Call (ONCRPC), определенный в RFC 1831. Система защиты должна была быть усилена, поэтому вместо простой аутентификации (известной как AUTH_SYS ) как обязательная часть протокола NFSv4 была определена и реализована разновидность основанной на GSS-API системы защиты, известная под названием RPCSEC_GSS . К наиболее важным доступным в NFSv4 механизмам защиты относятся Kerberos версии 5 и LIPKEY.

Если Kerberos имеет ограничения при использовании в Интернет, то у LIPKEY есть приятное преимущество - работая как Secure Sockets Layer (SSL), он запрашивает у пользователей их имена и пароли, избегая, в то же время, TCP-зависимости от SSL - зависимости, которую NFSv4 не разделяет. Вы можете настроить NFS на реализацию разновидностей системы защиты, если RPCSEC_GSS не требуется. Предыдущие версии NFS не имели такой возможности и, следовательно, не могли обеспечить качественную защиту, целостность данных, требования по аутентификации или типы шифрования.

Протокол NFSv3 подвергся существенной критике в области защищенности. Если NFSv3-серверы работали по TCP, было абсолютно реально запускать NFSv3-сети по Интернет. К сожалению, нужно было также открывать несколько портов, что приводило к появлению нескольких хорошо разрекламированных дыр в системе защиты. Сделав порт 2049 обязательным для NFS, стало возможным использование NFSv4 с брандмауэрами (firewall) без необходимости уделять слишком большое внимание тому, какие порты прослушивали другие протоколы, например, протокол Mount. Таким образом, исключение протокола Mount имело несколько положительных эффектов:

• Обязательные механизмы строгой аутентификации: NFSv4 сделал механизмы строгой аутентификации обязательными. Разновидности Kerberos довольно распространены. Также должен поддерживаться Lower Infrastructure Public Key Mechanism (LIPKEY). NFSv3 никогда не поддерживал что-то большее, чем стандартное UNIX-шифрование для аутентификации доступа - это порождало основные проблемы защиты в больших сетях.
• Обязательные схемы списков контроля доступа (access control list - ACL) в стиле Microsoft Windows NT : Хотя NFSv3 позволял реализовать строгое шифрование для аутентификации, он не использовал схемы ACL-доступа в стиле Windows NT. Списки ACL в стиле Portable Operating System Interface (POSIX) иногда реализовывались, но никогда не были общепринятыми. NFSv4 сделал ACL-схемы в стиле Windows NT обязательными.
• Договорные механизмы и стили аутентификации : NFSv4 предоставил возможность договариваться о механизмах и стилях аутентификации. В NSFv3 было невозможно сделать что-то большее, чем ручное определение используемого стиля шифрования. Системный администратор должен был затем согласовывать протоколы шифрования и защиты.

До сих пор ли NFS вне конкуренции?

NFSv4 заменяет NFSv3 на большинстве систем UNIX и Linux. Как сетевая файловая система NSFv4 имеет мало конкурентов. Жизнеспособным конкурентом могла бы считаться Common Internet File System (CIFS)/Server Message Block (SMB), исходя из того, что она присутствует во всех разновидностях Windows и (в настоящее время) в Linux. AFS никогда не имела большого коммерческого влияния; в ней придавалось особое значение элементам распределенных файловых систем, которые облегчали миграцию и репликацию данных.

Готовые к использованию Linux-версии NFS были выпущены после достижения ядром версии 2.2, но одной из наиболее общих неудач версий ядра Linux было то, что Linux принял NFSv3 довольно поздно. Фактически, прошло много времени до того, когда Linux стал полностью поддерживать NSFv3. С появлением NSFv4 этот недостаток был быстро устранен и полную поддержку NSFv4 реализовали не только в Solaris, AIX и FreeBSD.

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

NFS: удобная и перспективная сетевая файловая система

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

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

Краткая история NFS

Первая сетевая файловая система называлась FAL (File Access Listener - обработчик доступа к файлам) и была разработана в 1976 году компанией DEC (Digital Equipment Corporation). Она являлась реализацией протокола DAP (Data Access Protocol – протокол доступа к данным) и входила в пакет протоколов DECnet. Как и в случае с TCP/IP, компания DEC опубликовала спецификации своих сетевых протоколов, включая протокол DAP.

NFS была первой современной сетевой файловой системой, построенной поверх протокола IP. Её прообразом можно считать экспериментальную файловую систему, разработанную в Sun Microsystems в начале 80-х годов. Учитывая популярность этого решения, протокол NFS был представлен в качестве спецификации RFC и впоследствии развился в NFSv2. NFS быстро утвердилась в качестве стандарта благодаря способности взаимодействовать с другими клиентами и серверами.

Впоследствии стандарт был обновлен до версии NFSv3, определенной в RFC 1813. Эта версия протокола была более масштабируема, чем предыдущие, и поддерживала файлы большего размера (более 2 ГБ), асинхронную запись и TCP в качестве транспортного протокола. NFSv3 задала направление развития файловых систем для глобальных (WAN) сетей. В 2000 году в рамках спецификации RFC 3010 (переработанной в версии RFC 3530) NFS была перенесена в корпоративную среду. Sun представила более защищенную NFSv4 c поддержкой сохранения состояния (stateful) (предыдущие версии NFS не поддерживали сохранение состояния, т.е. относились к категории stateless). На текущий момент последней версией NFS является версия 4.1, определенная в RFC 5661, в которой в протокол посредством расширения pNFS была добавлена поддержка параллельного доступа для распределенных серверов.

История развития NFS, включая конкретные RFC, описывающие её версии, показана на рисунке 1.

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

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

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

Рисунок 2. Реализация модели "клиент-сервер" в архитектуре NFS

В ОС Linux® виртуальный коммутатор файловой системы (virtual file system switch - VFS) предоставляет средства для одновременной поддержки на одном хосте нескольких файловых систем (например, файловой системы ISO 9660 на CD-ROM и файловой системы ext3fs на локальном жестком диске). Виртуальный коммутатор определяет, к какому накопителю выполняется запрос, и, следовательно, какая файловая система должна использоваться для обработки запроса. Поэтому NFS обладает такой же совместимостью, как и другие файловые системы, применяющиеся в Linux. Единственное отличие NFS состоит в том, что запросы ввода/вывода вместо локальной обработки на хосте могут быть направлены для выполнения в сеть.

VFS определяет, что полученный запрос относится к NFS, и передает его в обработчик NFS, находящийся в ядре. Обработчик NFS обрабатывает запрос ввода/вывода и транслирует его в NFS-процедуру (OPEN , ACCESS , CREATE , READ , CLOSE , REMOVE и т.д.). Эти процедуры, описанные в отдельной спецификации RFC, определяют поведение протокола NFS. Необходимая процедура выбирается в зависимости от запроса и выполняется с помощью технологии RPC (вызов удаленной процедуры). Как можно понять по названию, RPC позволяет осуществлять вызовы процедур между различными системами. RPC-служба соединяет NFS-запрос с его аргументами и отправляет результат на соответствующий удаленный хост, а затем следит за получением и обработкой ответа, чтобы вернуть его инициатору запроса.

Также RPC включает в себя важный уровень XDR (external data representation – независимое представление данных), гарантирующий, что все пользователи NFS для одинаковых типов данных используют один и тот же формат. Когда некая платформа отправляет запрос, используемый ею тип данных может отличаться от типа данных, используемого на хосте, обрабатывающего этот запрос. Технология XDR берет на себя работу по преобразованию типов в стандартное представление (XDR), так что платформы, использующие разные архитектуры, могут взаимодействовать и совместно использовать файловые системы. В XDR определен битовый формат для таких типов, как float , и порядок байтов для таких типов, как массивы постоянной и переменной длины. Хотя XDR в основном известна благодаря применению в NFS, это спецификация может быть полезна во всех случаях, когда приходится работать в одной среде с различными архитектурами.

После того как XDR переведет данные в стандартное представление, запрос передается по сети с помощью определенного транспортного протокола. В ранних реализациях NFS использовался протокол UDP, но сегодня для обеспечения большей надежности применяется протокол TCP.

На стороне NFS-сервера применяется схожий алгоритм. Запрос поднимается по сетевому стеку через уровень RPC/XDR (для преобразования типов данных в соответствии с архитектурой сервера) и попадает в NFS-сервер, который отвечает за обработку запроса. Там запрос передается NFS-демону для определения целевой файловой системы, которой он адресован, а затем снова поступает в VFS для обращения к этой файловой системе на локальном диске. Полностью схема этого процесса приведена на рисунке 3. При этом локальная файловая система сервера – это стандартная для Linux файловая система, например, ext4fs. По сути NFS – это не файловая система в традиционном понимании этого термина, а протокол удаленного доступа к файловым системам.

Для сетей с большим временем ожидания в NFSv4 предлагается специальная составная процедура (compound procedure ). Эта процедура позволяет поместить несколько RPC-вызовов внутрь одного запроса, чтобы минимизировать затраты на передачу запросов по сети. Также в этой процедуре реализован механизм callback-функций для получения ответов.

Протокол NFS

Когда клиент начинает работать с NFS, первым действием выполняется операция mount , которая представляет собой монтирование удаленной файловой системы в пространство локальной файловой системы. Этот процесс начинается с вызова процедуры mount (одной из системных функций Linux), который через VFS перенаправляется в NFS-компонент. Затем с помощью RPC-вызова функции get_port на удаленном сервере определяется номер порта, который будет использоваться для монтирования, и клиент через RPC отправляет запрос на монтирование. Этот запрос на стороне сервера обрабатывается специальным демоном rpc.mountd , отвечающим за протокол монтирования (mount protocol ). Демон проверяет, что запрошенная клиентом файловая система имеется в списке систем, доступных на данном сервере. Если запрошенная система существует и клиент имеет к ней доступ, то в ответе RPC-процедуры mount указывается дескриптор файловой системы. Клиент сохраняет у себя информацию о локальной и удаленной точках монтирования и получает возможность осуществлять запросы ввода/вывода. Протокол монтирования не является безупречным с точки зрения безопасности, поэтому в NFSv4 вместо него используются внутренние RPC-вызовы, которые также могут управлять точками монтирования.

Для считывания файла его необходимо сначала открыть. В RPC нет процедуры OPEN , вместо этого клиент просто проверяет, что указанные файл и каталог существуют в смонтированной файловой системе. Клиент начинает с выполнения RPC-запроса GETATTR к каталогу, в ответ на который возвращаются атрибуты каталога или индикатор, что каталог не существует. Далее, чтобы проверить наличие файла, клиент выполняет RPC-запрос LOOKUP . Если файл существует, для него выполняется RPC-запрос GETATTR , чтобы узнать атрибуты файла. Используя информацию, полученную в результате успешных вызовов LOOKUP и GETATTR , клиент создает дескриптор файла, который предоставляется пользователю для выполнения будущих запросов.

После того как файл идентифицирован в удаленной файловой системе, клиент может выполнять RPC-запросы типа READ . Этот запрос состоит из дескриптора файла, состояния, смещения и количества байт, которое следует считать. Клиент использует состояние (state ), чтобы определить может ли операция быть выполнена в данный момент, т.е. не заблокирован ли файл. Смещение (offset ) указывает, с какой позиции следует начать чтение, а счетчик байт (count ) определяет, сколько байт необходимо считать. В результате RPC-вызова READ сервер не всегда возвращает столько байт, сколько было запрошено, но вместе с возвращаемыми данными всегда передает, сколько байт было отправлено клиенту.

Инновации в NFS

Наибольший интерес представляют две последние версии NFS – 4 и 4.1, на примере которых можно изучить наиболее важные аспекты эволюции технологии NFS.

До появления NFSv4 для выполнения таких задач по управлению файлами, как монтирование, блокировка и т.д. существовали специальные дополнительные протоколы. В NFSv4 процесс управления файлами был упрощен до одного протокола; кроме того, начиная с этой версии UDP больше не используется в качестве транспортного протокола. NFSv4 включает поддержку UNIX и Windows®-семантики доступа к файлам, что позволяет NFS "естественным" способом интегрироваться в другие операционные системы.

В NFSv4.1 для большей масштабируемости и производительности была введена концепция параллельной NFS (parallel NFS - pNFS). Чтобы обеспечить больший уровень масштабируемости, в NFSv4.1 реализована архитектура, в которой данные и метаданные (разметка ) распределяются по устройствам аналогично тому, как это делается в кластерных файловых системах. Как показано на , pNFS разделяет экосистему на три составляющие: клиент, сервер и хранилище. При этом появляются два канала: один для передачи данных, а другой для передачи команд управления. pNFS отделяет данные от описывающих их метаданных, обеспечивая двухканальную архитектуру. Когда клиент хочет получить доступ к файлу, сервер отправляет ему метаданные с "разметкой". В метаданных содержится информация о размещении файла на запоминающих устройствах. Получив эту информацию, клиент может обращаться напрямую к хранилищу без необходимости взаимодействовать с сервером, что способствует повышению масштабируемости и производительности. Когда клиент заканчивает работу с файлом, он подтверждает изменения, внесенные в файл и его "разметку". При необходимости сервер может запросить у клиента метаданные с разметкой.

С появлением pNFS в протокол NFS было добавлено несколько новых операций для поддержки такого механизма. Метод LayoutGet используется для получения метаданных с сервера, метод LayoutReturn "освобождает" метаданные, "захваченные" клиентом, а метод LayoutCommit загружает "разметку", полученную от клиента, в хранилище, так что она становится доступной другим пользователям. Сервер может отозвать метаданные у клиента с помощью метода LayoutRecall . Метаданные с "разметкой" распределяются между несколькими запоминающими устройствами, чтобы обеспечить параллельный доступ и высокую производительность.

Данные и метаданные хранятся на запоминающих устройствах. Клиенты могут выполнять прямые запросы ввода/вывода на основе полученной разметки, а сервер NFSv4.1 хранит метаданные и управляет ими. Сама по себе эта функциональность и не нова, но в pNFS была добавлена поддержка различных методов доступа к запоминающим устройствам. Сегодня pNFS поддерживает использование блочных протоколов (Fibre Channel), объектных протоколов и собственно NFS (даже не в pNFS-форме).

Развитие NFS продолжается, и в сентябре 2010 года были опубликованы требования к NFSv4.2. Некоторые из нововведений связаны с наблюдающейся миграцией технологий хранения данных в сторону виртуализации. Например, в виртуальных средах с гипервизором весьма вероятно возникновение дублирования данных (несколько ОС выполняют чтение/запись и кэширование одних и тех же данных). В связи с этим желательно, чтобы система хранения данных в целом понимала, где происходит дублирование. Такой подход поможет сэкономить пространство в кэше клиента и общую емкость системы хранения. В NFSv4.2 для решения этой проблемы предлагается использовать "карту блоков, находящихся в совместном доступе" (block map of shared blocks). Поскольку современные системы хранения все чаще оснащаются собственными внутренними вычислительными мощностями, вводится копирование на стороне сервера, позволяющее снизить нагрузку при копировании данных во внутренней сети, когда это можно эффективно делать на самом запоминающем устройстве. Другие инновации включают в себя субфайловое кэширование для флэш-памяти и рекомендации по настройке ввода-вывода на стороне клиента (например, с использованием mapadvise).

Альтернативы NFS

Хотя NFS – самая популярная сетевая файловая система в UNIX и Linux, кроме нее существуют и другие сетевые файловые системы. На платформе Windows® чаще всего применяется SMB, также известная как CIFS ; при этом ОС Windows также поддерживает NFS, равно как и Linux поддерживает SMB.

Одна из новейших распределенных файловых систем, поддерживаемых в Linux - Ceph - изначально спроектирована как отказоустойчивая POSIX-совместимая файловая система. Дополнительную информацию о Ceph можно найти в разделе .

Стоит также упомянуть файловые системы OpenAFS (Open Source-версия распределенной файловой системы Andrew, разработанной в университете Карнеги-Меллона и корпорации IBM), GlusterFS (распределенная файловая система общего назначения для организации масштабируемых хранилищ данных) и Lustre (сетевая файловая система с массовым параллелизмом для кластерных решений). Все эти системы с открытым исходным кодом можно использовать для построения распределенных хранилищ.

Заключение

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

Сетевая файловая система NFS или Network File System, это популярный протокол сетевой файловой системы, который позволяет пользователям подключать удаленные сетевые каталоги на своей машине и передавать файлы между серверами. Вы можете использовать дисковое пространство на другой машине для своих файлов и работать с файлами, расположенными на других серверах. По сути, это альтернатива общего доступа Windows для Linux, в отличие от Samba реализована на уровне ядра и работает более стабильно.

В этой статье будет рассмотрена установка nfs в Ubuntu 16.04. Мы разберем установку всех необходимых компонентов, настройку общей папки, а также подключение сетевых папок.

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

Установка компонентов NFS

Перед тем как мы сможем работать с NFS, нам придется установить несколько программ. На машину, которая будет сервером нужно установить пакет nfs-kernel-server, с помощью которого будет выполнено открытие шары nfs в ubuntu 16.04. Для этого выполните:

sudo apt install nfs-kernel-server

Теперь давайте проверим правильно ли установился сервер. Сервис NFS слушает соединения как для TCP, так и для UDP на порту 2049. Посмотреть действительно ли сейчас используются эти порты можно командой:

rpcinfo -p | grep nfs

Также важно проверить поддерживается ли NFS на уровне ядра:

cat /proc/filesystems | grep nfs

Видим, что работает, но если нет, нужно вручную загрузить модуль ядра nfs:

Давайте еще добавим nfs в автозагрузку:

sudo systemctl enable nfs

На клиентском компьютере вам нужно установить пакет nfs-common, чтобы иметь возможность работать с этой файловой системой. Вам необязательно устанавливать компоненты сервера, достаточно будет только этого пакета:

sudo apt install nfs-common

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

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

адрес_папки клиент (опции)

Адрес папки - это та папка, которую нужно сделать доступной по сети. Клиент - ip адрес или адрес сети, из которой могут получить доступ к этой папке. А вот с опциями немного сложнее. Рассмотрим некоторые из них:

• rw - разрешить чтение и запись в этой папке
• ro - разрешить только чтение
• sync - отвечать на следующие запросы только тогда, когда данные будут сохранены на диск (по умолчанию)
• async - не блокировать подключения пока данные записываются на диск
• secure - использовать для соединения только порты ниже 1024
• insecure - использовать любые порты
• nohide - не скрывать поддиректории при, открытии доступа к нескольким директориям
• root_squash - подменять запросы от root на анонимные
• all_squash - превращать все запросы в анонимные
• anonuid и anongid - указывает uid и gid для анонимного пользователя.

Например, для нашей папки эта строка может выглядеть вот так:

/var/nfs 127.0.0.1(rw,sync,no_subtree_check)

Когда все было настроено, осталось обновить таблицу экспорта NFS:

sudo exportfs -a

Вот и все, открытие шары nfs в ubuntu 16.04 завершено. Теперь попытаемся настроем клиента и попытаемся ее примонтировать.

Подключение NFS

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

Чтобы подключить сетевую папку вам не нужен никакой nfs клиент ubuntu, достаточно использовать команду mount:

sudo mount 127.0.0.1:/var/nfs/ /mnt/

Теперь вы можете попытаться создать файл в подключенной директории:

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

127.0.0.1:/var/nfs 30G 6,7G 22G 24% /mnt

Чтобы отключить эту файловую систему достаточно использовать стандартный umount:

sudo umount /mnt/

Выводы

В этой статье была рассмотрена настройка nfs ubuntu 16.04, как видите, все делается очень просто и прозрачно. Подключение NFS шары выполняется в несколько кликов, с помощью стандартных команд, а открытие шары nfs в ubuntu 16.04 ненамного сложнее подключения. Если у вас остались вопросы, пишите в комментариях!

Похожие записи: