Сетевые файловые системы. Установка стандартных разрешений. showmount: вывод информации о состоянии NFS

Сетевые службы

Лекция 10

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

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

Ключевым компонентом распределенной ОС является сетевая файловая система. Сетевая файловая система поддерживается одним или несколькими компьютерами, хранящими файлы (файловые сервера)

Клиентские компьютеры подсоединяются или монтируют эти файловые системы к своим локальным файловым системам

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

Файловые службы включает собственно файловую службу (файловые операции) и службу каталогов (управление каталогами)

Модель сетевой файловой службы включает следующие элементы:

Локальная файловая система (FAT, NTFS)

Интерфейс локальной файловой системы (системные вызовы)

Сервер сетевой файловой системы

Клиент сетевой файловой системы (Windows Explorer, UNIX shell и пр.)

Интерфейс сетевой файловой системы(повторяет системные вызовы локальной файловой системы)

Протокол клиент-сервер сетевой файловой системы (SMB-Server Message Block для Windows, NFS (Network File System) и FTP (File Transfer Protocol) для UNIX)

Интерфейс сетевой файловой системы

Существуют несколько типов интерфейсов, которые характеризуются:

Структура файлов . Большинство сетевых ФС поддерживают неструктурированные файлы

Модифицируемость файлов . В большинстве сетевых ФС имеется возможность модифицировать файл. Некоторые распределенные ФС запрещают операции модификации. Возможны лишь create и read. Для таких файлов легче организовать кэширование и тиражирование.

Семантика разделения файлов:

Семантика UNIX (централизованная). Если чтение следует за несколькими операциями записи, то читается последнее обновление. Этот принцип возможен и в распределенной файловой системе, при условии одного файлового сервера и отсутствия кэширование файлов у клиента.

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

Механизм транзакций. Это способ работы с разделяемыми файлами с помощью механизма транзакций (неделимых операций)

Контроль доступа . Например для Windows NT/2000 существует два механизма: на уровне каталогов (для FAT) и на уровне файлов (NTFS)

Единица доступа. Модель загрузки-выгрузки файла целиком (FTP). Вторая модель - использование операций над файлами.

Когда речь идет о компьютерных сетях, зачастую можно услышать упоминание 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.

Сетевые файловые системы

Одна из наиболее полезных функций, которая может быть реализована с помощью сети, это разделение файлов через сетевую файловую систему. Обычно используется система, называемая Network File System или NFS, которая разработана корпорацией Sun.

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

Почта

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

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

Почтовая система состоит из множества различных программ. Доставка писем к локальным или удаленным почтовым ящикам производится одной программой (например, sendmail или smail), в то время как для обычной отправки или просмотра писем применяется большое количество различных программ (например, Pine или elm).Файлы почтовых ящиков обычно хранятся в каталоге /var/spool/mail.

Вопросы

1. Что такое NOS и каково ее назначение?

2. Какие функции сети выполняет сетевая операционная система?

3. Из каких частей состоит структура NOS?

4. Что такое редиректор?

5. Как подразделяются сетевые операционные системы по правам доступа к ресурсам?

6. Как подразделяются сетевые операционные системы по масштабу сетей?

7. Как зависят свойства сетевой операционной системы от масштаба сетей?

8. Дать характеристику сетевой операционной системы NetWare фирмы Novell.

9. Из каких элементов состоит структура сетевой операционной системы NetWare?

10. Дать характеристику файловой системы сетевой ОС NetWare.

11. Какие уровни протоколов поддерживает сетевая операционная система NetWare?

12. Перечислить функции протоколов IPX, SPX.

13. Дать характеристику сетевой операционной системы Windows NT.

14. Перечислить задачи сетевой операционной системы Windows NT.

15. Из каких элементов состоит структура сетевой операционной системы Windows NT?

16. Дать характеристику файловой системы сетевой ОС Windows NT.

17. Какие принципы защиты используются в сетевой ОС Windows NT?

18. Перечислить особенности сетевой операционной системы Windows NT с точки зрения реализации сетевых средств.

19. Назвать свойства сетевой операционной системы Windows NT.

20. Каковы области использования Windows NT?

21. Дать характеристику сетевой операционной системы UNIX.

22. Перечислить функции сетевой операционной системы UNIX.

23. Дать характеристику файловой системы сетевой ОС UNIX.

24. Какие принципы защиты используются UNIX?

25. Дать обзор сетевой операционной системы Linux.

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

1.4 Сетевая файловая система

Файловая система CIFS доминирует на рынке сетевых файловых систем для платформы Windows. На платформе UNIX основной является сетевая файловая система (Network File System - NFS). Кроме того, NFS считается первой широко распространенной файловой системой, что произошло еще в середине 1980-х годов. Однако, несмотря на некоторые общие функциональные возможности CIFS и NFS (это сетевые файловые системы, позволяющие клиентам получать доступ к ресурсам серверов), эти системы имеют совершенно различные архитектурные особенности. С выходом NFS версии 4 некоторые различия были пересмотрены.
Протокол CIFS сохраняет сервисные данные, относящиеся к каждому клиенту. До версии 3 файловая система NFS не сохраняла статус клиента, что изменилось в версии 4.
Клиент NFS не "договаривается" с сервером NFS об установлении сеанса. Меры безопасности предпринимаются для всего сеанса или каждой операции обмена данными между клиентом и сервером. Реализация последнего варианта чрезмерно дорогостоящая, поэтому NFS возлагает задачу обеспечения безопасности на клиента. Сервер "предполагает", что идентификаторы поль¬зователя на клиентских и серверной системах совпадают (а клиент проверил личность пользователя перед тем, как дать ему зарегистрироваться под указанным идентификатором). Кроме того, NFS обеспечивает определенный уровень безопасности, контролируя список файловых систем, которые может монтировать клиент. Каждый раз, когда клиент CIFS открывает файл, получает дескриптор файла (т.е. сервисные данные, которые должен сохранять сервер) и использует его для проведения операций чтения или записи на стороне клиента, сервер NFS запрашивает сервер, который возвращает дескриптор файла. Этот дескриптор файла обрабатывается клиентами, поддерживающими стандарты NFS 3 и NFS 2. Клиент кэширует полученный дескриптор файла и ожидает, что дескриптор всегда будет указывать на один и тот же файл.
Для тех, кто знаком с UNIX, можно отметить, что дескриптор файла обычно состоит из номера inode (inode number), счетчика поколения inode (inode generation count) и идентификатора файла, который связан с разделом диска. Достаточно сказать, что inode представляет собой исключительно важную структуру данных, которая используется в файловых системах UNIX. Для удаления дескрипторов, кэшированных клиентами, хранится достаточный объем информации, необходимой, если соответствующий дескриптору файл изменился и дескриптор должен указывать на другой файл. Например, если файл удален и на его место скопирован файл с таким же именем, счетчик поколения inode будет изменен и кэшированный клиентом дескриптор файла окажется недействительным. Файловая система NFS 4 имеет отличия в реализации.
Некоторые клиенты NFS проводят кэширование на стороне клиента, храня данные на дисках, что напоминает кэширование в CIFS. Также некоторые клиенты NFS меняют значение тайм-аутов в зависимости от времени отклика сервера. Чем медленнее отзывается сервер, тем больше значение тайм-аута, и наоборот.
Файловая система NFS проектировалась, как независящая от транспорта и изначально использовала транспортный протокол UDP. Различные типы NFS могут использовать протокол TCP и другие протоколы.

1.4.1 Сетевая файловая система, версия 3

Файловая система NFS 3 позволяет увеличить быстродействие, особенно для больших файлов, разрешая клиенту и серверу динамически выбирать максимальный объем данных, которые передаются в одном логическом элементе пакета при записи или чтении. В файловой системе NFS 2 на размер пакета накладывалось ограничение в 8 Кбайт. Другими словами, клиент мог отправить максимум 8 Кбайт в запросе на запись, а сервер - максимум 8 Кбайт в ответе на запрос чтения. Кроме того, в NFS 3 переопределены смещения в файлах и размеры данных. Теперь это 64-разрядные значения, вместо 32-разрядных в NFS 2.
Далее представлены некоторые особенности NFS 3.
■ В дескрипторах файлов в NFS 3 указан переменный размер; их максимальных размер составляет 64 бит.
■ Файловая система NFS 3 позволяет клиентам и серверам выбирать максимальный размер имен файлов и каталогов.
■ В NFS 3 определяется список ошибок, которые сервер может возвращать клиентам. Сервер должен вернуть одну из определенных ошибок или не возвращать ошибку вообще.
■ В NFS 3 серверу разрешено кэшировать данные, которые клиент отправил вместе с запросом на запись. Сервер может кэшировать данные и отправлять клиенту ответ на запрос еще до того, как данные будут записаны на диск. Также добавлена команда COMMIT, которая позволяет клиенту убедиться, что все отправленные данные были записаны на диск. Это дает возможность соблюсти баланс между повышением производительности и сохранением целостности данных.
■ В NFS 3 сокращено количество операций запрос/ответ между клиентом и сервером. Для этого данные об атрибутах файла отправляются вместе с первоначальным запросом. В NFS 2 от клиента требовалось получение имен файлов и дескриптора для каждого файла, только после этого передавались атрибуты файла.

1.4.2 Сетевая файловая система, версия 4

В NFS 4 полностью пересмотрены основополагающие принципы и реализовано много функций, характерных для CIFS, что весьма расстроило некоторых апологетов NFS. Если посмотреть на историю сетевых файловых систем, то можно увидеть, что NFS получила широкое распространение. Файловая система SMB разрабатывалась с учетом сильных и слабых сторон NFS и теперь, по крайней мере в среде клиентов, CIFS/SMB распространены больше, a NFS развивается, учитывая все недостатки и преимущества CIFS/SMB. Ниже рассматриваются возможности, которые были добавлены в NFS 4 для повышения быстродействия и безопасности, а также для улучшения взаимодействия с CIFS.
■ В NFS 4 появился запрос COMPOUND, который позволяет запаковывать несколько запросов в один запрос и несколько ответов в один ответ. Это нововведение предназначено для повышения производительности за счет снижения нагрузки на сеть и сокращения задержек при передаче запросов и ответов по сети. Если это несколько напоминает функцию CIFS AndX SMB (см. раздел 3.3.5.1), то, возможно, дело не в обычном совпадении.
■ Сетевая файловая система версии 4 заимствовала некоторые возможности у WebNFS, созданной компанией Sun. В частности, в NFS 4 некоторые вторичные протоколы поддерживаются в базовой спецификации, что делает NFS более подходящей для применения вместе с брандмауэрами. В NFS 3 и более ранних версиях использовался специальный протокол для монтирования общего ресурса сервера в дерево локальной файловой системы. Поскольку служба протокола монтирования не имела назначенного порта TCP или UDP, клиент сначала отправлял запрос службе отображения портов (portmapper daemon), предоставляющей номер порта, посредством которого ожидает запросов служба монтирования. Таким образом, кроме NFS, в процессе принимали участие протоколы монтирования и отображения портов. Более того, так как служба монтирования могла использовать произвольный порт, настройка брандмауэра весьма усложнялась. В NFS 4 протоколы монтирования и отображения портов были исключены. Кроме того, блокирование было включено в базовую спецификацию протокола NFS, а протокол NLM (Network Lock Manager), который применялся в более ранних версиях NFS, окончательно устарел.
■ Файловая система NFS 4 требует использования транспортного протокола, который предоставляет возможность обнаружения "заторов" в сети. Это значит, что клиенты и серверы NFS постепенно будут переходить к протоколу TCP вместо UDP, который обычно используется вместе с NFS 3.
■ В NFS 2 и NFS 3 допускалось использование набора символов U.S. ASCII или ISO Latin 1. Это приводило к возникновению проблем, когда клиент, использующий один набор символов, создавал файл и к этому файлу получал доступ клиент с другим набором символов. В NFS 4 используется набор символов UTF-8, который поддерживает компактное сжатие 16- и 32-разрядных символов для их передачи по сети. Кроме того, набор символов UTF-8 содержит достаточный объем информации, чтобы избежать проблем при создании файла посредством одного набора символов и получении доступа к файлу с другим набором.
■ Файловая система NFS 4 требует от клиента отдельной обработки дескрипторов файлов. В NFS 3 клиент мог кэшировать дескриптор в качестве объекта, в то время как сервер заботился о том, чтобы дескриптор всегда указывал на файл. В NFS 4 определены два типа файловых дескрипторов. Один называется постоянные дескрипторы файлов и обладает возможностями дескрипторов файлов из NFS 3. Второй - временные дескрипторы файлов - предполагает истечение срока действия дескриптора после определенного промежутка времени или события. Это функция для серверов, файловые системы которых (например, NTFS) не могут обеспечить постоянного соответствия между отображаемыми файлами и дескрипторами.
■ В NFS 4 добавлена поддержка операций OPEN и CLOSE, семантика которых допускает взаимодействие с клиентами CIFS. Команда OPEN создает данные состояния на сервере.
■ Поддержка запроса OPEN в NFS 4 позволяет клиенту осуществлять запрос на открытие файла, структура которого будет аналогична запросам на открытие приложений Windows. Также поддерживается выбор совместного использования файла с другими клиентами или эксклюзивный доступ к файлу.

1.4.2.1 Безопасность NFS 4

Файловая система NFS 4 позволяет усилить безопасность хранимых данных. В частности, в NFS 4 добавлена поддержка большего количества атрибутов файла. К одному из этих атрибутов относится список управления доступом (ACL) в стиле Windows NT. Это позволяет улучшить взаимодей¬ствие между файловыми системами и укрепить структуру безопасности.
В то время как в NFS 2 и NFS 3 использование возможностей системы безопасности только рекомендовалось, в NFS 4 это стало обязательным. Файловая система NFS 4 требует реализации механизма безопасности с помощью интерфейса RPCSEC_GSS (Generic Security Services) в общем и протоколов Kerberos 5/LIPKEY в частности. Обратите внимание, что RPCSEC_GSS просто выполняет роль интерфейса API и транспортного механизма для меток и данных, связанных с безопасностью. Файловая система NFS 4 позволяет использовать несколько, схем аутентификации и обеспечения безопасности, а также дает возможность выбрать подходящую схему для клиентов и серверов.
Уделим некоторое внимание изучению технологии LIPKEY, использующей комбинацию симметричного и асимметричного шифрования. Клиент шифрует данные о пользователе и пароль, применяя случайно сгенерированный ключ размером 128 бит. Шифрование выполняется с помощью симметричного алгоритма, т.е. для дешифрации должен использоваться тот же ключ. Поскольку серверу необходим этот ключ для дешифрации сообщений, случайно сгенерированный ключ должен быть отправлен серверу. Клиент шифрует ключ (который генерируется случайно) с помощью открытого ключа сервера. Сервер дешифрует данные своим закрытым ключом, извлекает симметричный ключ и дешифрует данные о пользователе и пароль.
Клиенты могут аутентифицировать серверы по серверному сертификату, а для проверки сертификата используются службы сертификационного центра. Одним из популярных методов взлома является перехват "чужих" пакетов данных с их последующей отправкой через некоторый временной промежуток. При использовании Kerberos файловая система NFS добавляет в каждый пакет временную метку. Сервер записывает недавно полученные временные метки и сравнивает их с временными метками новых пакетов RPC. Если временные метки пакетов старше, чем полученные сервером ранее, сервер игнорирует полученные пакеты

1.5 Проблемы доступа при использовании нескольких протоколов

Несколько компаний стали предлагать системы, в которых одновременно реализована поддержка CIFS, NFS и других клиентов сетевых файловых систем. Поставщики проделали немалую работу, пытаясь преодолеть технические проблемы, которые возникают из-за потенциального использования клиентами различных операционных и файловых систем. Обратите внимание, что проблемы возникают не с самими данными, а с метаданными файлов. Простым тестом на наличие подобных проблем будет копирование фай¬ла с сервера на клиент и обратно на сервер (или наоборот). После размещения файла в первоначальном ресурсе метаданные должны содержать базовые значения, т.е. права доступа к файлу и временные метки не должны измениться. Если это не соответствует истине, то проблема обнаружена.
Далее представлены примеры некоторых возможных технических проблем.
■ В различных операционных системах используются разные методы для отслеживания разрешений доступа пользователей и групп.
■ В различных операционных и файловых системах существует разная семантика открытия и блокировки файлов.
■ Соглашения по именованию файлов обрабатываются разными способами. Различные файловые системы по-разному представляют максимальный размер имени файла, значение регистра в имени файла и набор символов, допустимый в именах.
■ Данные и их структура различаются в различных файловых системах; например, одни файловые системы отслеживают две временные метки, в то время как другие - три метки (время последнего доступа к файлу, последней модификации и создания файла). Даже если обе файловые системы отслеживают две временные метки, единицы измерения могут отличаться. Еще одним примером служат единицы измерения смещений в файлах. В некоторых файловых системах поддерживаются 32-разрядные смещения, а в некоторых - 16- или 64-разрядные.
■ Проблемы с адресацией отображаемых блокировок. Сервер CIFS принудительно поддерживает блокировку: если один клиент заблокировал область файла, то любая операция записи в эту область файла со стороны другого клиента приведет к возникновению ошибки. Однако принудительная блокировка не поддерживается серверами NFS. Поэтому необходимо выбрать, будет ли блокировка поддерживаться принудительно, что приведет к отправке сообщения об ошибке клиенту NFS.