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

Константин Пьянзин

Основные особенности работы файловой системы NFS на платформе UNIX.

Счастье - это когда наши желания совпадают с чужими возможностями.

"Времечко"

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

В настоящее время операционная система UNIX переживает своего рода ренессанс, и во многом она обязана таким подъемом интереса свободно распространяемой ОС Linux. Вместе с тем на настольных компьютерах используются различные варианты Windows, прежде всего, Windows 9x и Windows NT/2000, хотя и здесь постепенно получают гражданство свободно распространяемые разновидности UNIX.

Для многих организаций размещение сетевого файлового сервиса на компьютерах с UNIX является весьма привлекательным решением при условии, что такой сервис имеет достаточную производительность и надежность. Учитывая многочисленные различия в файловых системах UNIX и Windows, прежде всего в схемах именования файлов, особенностях прав доступа, блокировках и системных вызовах при обращении к файлам, особое значение приобретает обеспечение прозрачности доступа в гетерогенной среде UNIX/Windows. Кроме того, нередко файловые серверы UNIX устанавливаются в качестве дополнения к уже имеющимся серверам Windows NT и NetWare.

Для операционной системы UNIX имеются реализации всех более или менее популярных сетевых файловых систем, включая используемых в сетях Microsoft (SMB), NetWare (NCP), Macintosh (AFP). Разумеется, для сетей UNIX существуют свои собственные протоколы, прежде всего, NFS и DFS. Следует иметь в виду, что любой сервер UNIX может одновременно предоставлять услуги NFS и SMB (так же, как NCP и AFP) и таким образом обеспечивает дополнительную гибкость при создании сетевой инфраструктуры.

Несмотря на разнообразие сетевых файловых систем UNIX, безусловными лидерами являются системы NFS (Network File System, дословный перевод - сетевая файловая система) и SMB (Service Message Block). В данной статье речь пойдет о возможностях NFS. Вместе с тем в одном из ближайших номеров мы планируем рассмотреть характеристики работ SMB на платформе UNIX и, в первую очередь, продукт Samba, который хорошо зарекомендовал себя в сетях UNIX/Windows.

ВЕРСИИ NFS

Первая реализация сетевой файловой системы NFS была разработана компанией Sun Microsystems еще в 1985 году. С тех пор NFS получила широкое распространение в мире UNIX, и количество ее инсталляций исчисляется десятками миллионов. Кроме UNIX система NFS как серверная платформа нашла применение в операционных системах VMS, MVS и даже Windows.

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

В настоящее время NFS представлена второй и третьей версиями (первая версия NFS на рынке никогда не появлялась). Несмотря на ряд ограничений, NFS v2 пользуется большой популярностью; именно она входит в состав свободно распространяемых UNIX (в частности, Linux), а также некоторых коммерческих UNIX.

Третья версия NFS была разработана в середине 90-х годов совместными усилиями Sun, IBM, Digital и других компаний с целью повышения производительности, безопасности и удобства администрирования сетевой файловой системы. NFS v3 обратно совместима с предыдущей спецификацией NFS, т. е. сервер NFS v3 может обслуживать не только клиентов NFS v3, но и клиентов NFS v2.

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

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

ПРОТОКОЛЫ NFS V2

На Рисунке 1 представлена сетевая модель NFS v2 в соответствии с эталонной моделью OSI. В отличие от большинства сетевых служб TCP/IP система NFS явным образом использует протоколы презентационного и сеансового уровня. Работа NFS опирается на концепцию вызовов удаленных процедур (Remote Procedure Call, RPC). Согласно этой концепции, при доступе к удаленному ресурсу (например, к файлу) программа на локальном компьютере выполняет обычный системный вызов (предположим, вызов функции открытия файла), но на самом деле процедура выполняется удаленно - на сервере ресурсов. При этом пользовательский процесс не в состоянии определить, как выполняется вызов - локально или удаленно. Установив, что процесс обращается к ресурсу на удаленном компьютере, выступающем в качестве сервера, ядро или специальный демон системы упаковывает аргументы процедуры вместе с ее идентификатором в сетевой пакет, открывает сеанс связи с сервером и пересылает ему данный пакет. Сервер распаковывает полученный пакет, определяет запрашиваемую процедуру и аргументы, а затем выполняет процедуру. Далее сервер пересылает клиенту код возврата процедуры, а тот передает его пользовательскому процессу. Таким образом, RPC полностью соответствует сеансовому уровню модели OSI.

Возникает справедливый вопрос: зачем в сетевой модели NFS нужен специальный протокол презентационного уровня? Дело в том, что Sun благоразумно рассчитывала на применение NFS в гетерогенных сетях, где компьютеры имеют различную системную архитектуру, в том числе различный порядок представления байтов в машинном слове, различное представление чисел с плавающей точкой, несовместимые границы выравнивания структур и т. д. Поскольку протокол RPC предполагает пересылку аргументов процедур, т. е. структурированных данных, то наличие протокола презентационного уровня является насущной необходимостью в гетерогенной среде. В качестве такового выступает протокол внешнего представления данных (eXternal Data Representation, XDR). Он описывает так называемую каноническую форму представления данных, не зависящую от системной архитектуры процессора. При передаче пакетов RPC клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию. Следует иметь в виду, что каноническая форма XDR соответствует представлению данных, принятому для семейства процессоров SPARC и Motorola. В серверах, где реализована аналогичная форма представления данных, это позволяет добиться некоторого (правда, скорее всего, микроскопического) преимущества в производительности над конкурентами в случаях интенсивного обращения к файловому серверу.

В NFS v2 в качестве транспортного протокола был выбран UDP. Разработчики объясняют это тем, что сеанс RPC длится короткий промежуток времени. Более того, с точки зрения выполнения удаленных процедур каждый пакет RPC является самодостаточным, т. е. каждый пакет несет полную информацию о том, что необходимо выполнить на сервере, или о результатах выполнения процедуры. Сервисы RPC обычно не отслеживают состояние связи (connectionless), т. е. сервер не хранит информацию о том, какие запросы клиента обрабатывались в прошлом: например, с какого места файла клиент считывал данные последний раз. Для сетевой файловой системы это определенное преимущество с точки зрения надежности, так как клиент может продолжать файловые операции сразу же после перезагрузки сервера. Но такая схема чревата возникновением проблем при записи и блокировке файлов, и, чтобы их обойти, разработчики NFS были вынуждены применять разные обходные маневры (использование UDP порождает еще один ряд специфических проблем, но их мы коснемся позже).

Важное отличие сервисов RPC, входящих в состав NFS, от других сетевых серверных служб состоит в том, что они не используют супердемон inetd. Рядовые сетевые службы, наподобие telnet или rlogin, обычно не запускаются в виде демонов при старте системы, хотя это делать не возбраняется. Чаще всего они задействуют так называемый супердемон inetd, который "прослушивает" программные порты протоколов TCP и UDP. Службы задаются в конфигурационном файле супердемона (обычно /etc/inetd.conf). При поступлении запроса на программный порт со стороны клиента inetd запускает в качестве дочернего процесса соответствующую сетевую службу (например, in.rlogind), которая и обрабатывает запрос.

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

Еще одно важное отличие сервисов RPC от обычных сетевых служб состоит в том, что они не используют заранее заданных программных портов UDP. Вместо этого применяется так называемая система трансляции портов portmapper. Для ее поддержки при загрузке системы инициализируется специальный демон portmap. В рамках системы трансляции портов за каждым сервисом RPC закрепляется программный номер (program number), номер версии, номер процедуры (procedure number) и протокол (UDP или TCP). Программный номер однозначно идентифицирует конкретный сервис RPC. Взаимосвязь между именами сервисов RPC и программными номерами можно проследить на основании содержимого файла /etc/rpc. Каждая программа RPC поддерживает множество процедур, которые определяются по их номерам. Номера процедур можно узнать в соответствующих header-файлах: например, для сервиса NFS они задаются в файле /usr/include/nfs/nfs.h.

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

Принцип работы транслятора portmap достаточно прост. При инициализации (в частности, в момент загрузки ОС) какого-либо сервиса RPC он регистрируется с помощью демона portmap. При запуске на сервере сервис RPC ищет незанятый программный порт, резервирует его за собой и сообщает номер порта демону portmap. Для того чтобы связаться с сервером, клиент RPC должен сначала обратиться к portmap сервера и узнать у него, какой программный порт занимает конкретный сервис RPC на сервере. Только затем клиент может непосредственно связаться с сервисом. В некоторых случаях клиент связывается с нужным сервисом косвенным образом, т. е. вначале он обращается к демону portmap, а тот запрашивает сервис RPC от лица клиента. В отличие от сервисов RPC, транслятор портов portmap всегда привязан к заранее заданному порту 111, так что клиент связывается с portmap стандартным способом.

СОСТАВ NFS V2

В общем случае помимо portmap сервер NFS включает демоны rpc.mountd, nfsd, rpc.lockd, rpc.statd. На клиентской машине NFS, функционирующей на платформе UNIX, должны быть запущены демоны biod (необязательно), rpc.lockd и rpc.statd.

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

Демон rpc.mountd обслуживает запросы клиентов на монтирование файловых систем. Сервис монтирования реализован в виде отдельного демона, так как протокол монтирования не является частью NFS. Это вызвано тем, что операция монтирования тесно привязана к синтаксису имен файлов, а принципы именования файлов различаются для UNIX и, скажем, для VMS.

Демон nfsd принимает и обслуживает запросы NFS RPC. Обычно в целях повышения производительности на сервере запускают несколько экземпляров nfsd.

Демон rpc.lockd, функционирующий как на клиенте, так и на сервере, предназначен для блокировки файлов, тогда как демон rpc.statd (также исполняемый на сервере и клиенте) ведет статистику блокировок на случай необходимости их автоматического восстановления при крахе сервиса NFS.

Демон biod, запускаемый на клиенте, способен производить операции "чтение с опережением" и "отложенная запись", что серьезно повышает производительность. Однако наличие biod не является обязательным для работы клиента. Для еще большего повышения производительности на клиентской машине можно загрузить несколько демонов biod.

Еще один демон, выполняющийся на сервере, отвечает за аутентификацию и сервис печати для клиентов DOS/Windows, в некоторых системах он носит имя pcnfsd, в других - in.pcnfsd.

Кроме того, в комплект поставки NFS входят различные системные утилиты и программы диагностики (showmount, rpcinfo, exportfs, nfsstat).

ПРАВИЛА ЭКСПОРТИРОВАНИЯ

Файловые системы и каталоги, которые клиенты могут удаленно монтировать на сервере NFS, должны быть явно заданы. Данная процедура называется в NFS "экспортированием" ресурсов. В то же время сервер NFS, в отличие от, скажем, сервера SMB, не занимается широковещательной рассылкой списка своих экспортируемых ресурсов. Тем не менее клиент может запросить у сервера такой список. На стороне сервера за обслуживание запросов монтирования отвечает демон rpc.mountd.

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

1. Файловую систему можно экспортировать как целиком, так и по частям, каковыми являются каталоги и файлы. При этом следует помнить, что самой крупной экспортируемой единицей является файловая система. Если на сервере некая файловая система (/usr/bin) смонтирована по иерархии ниже другой файловой системы (/usr), то экспортирование системы /usr систему /usr/bin не затронет.
2. Экспортировать можно только локальные файловые ресурсы, иными словами, если на сервере смонтирована чужая файловая система, т. е. находящаяся на другом сервере, то ее нельзя реэкспортировать.
3. Нельзя экспортировать подкаталоги уже экспортированной файловой системы, если только они не представляют собой самостоятельных файловых систем.
4. Нельзя экспортировать родительские каталоги уже экспортированного каталога, если только родительский каталог не представляет собой независимую файловую систему.

Любое нарушение этих правил приведет к ошибке в работе NFS.

Таблица экспортируемых ресурсов располагается в файле /etc/exports. К сожалению, синтаксис этого файла зависит от конкретных UNIX, поэтому в качестве примера мы возьмем Solaris. Файл /etc/exports состоит из текстовых строк, имеющих формат:

-,...

Некоторые наиболее популярные опции перечислены в Таблице 1. Фактически опции описывают права доступа к экспортируемым ресурсам со стороны клиентов. Важно помнить, что права доступа, перечисленные при экспортировании, никоим образом не отменяют права доступа, действующие непосредственно в файловой системе. Например, если файловая система экспортируется с возможностью записи, а конкретный файл имеет атрибут "только для чтения", то его изменение будет невозможно. Таким образом, при экспортировании права доступа выступают в качестве дополнительного фильтра. Более того, если, скажем, файловая система экспортируется с опцией ro (read only), то клиент имеет право смонтировать ее с опцией rw (read/write), однако при этом попытка произвести запись приведет к выдаче сообщения об ошибке.

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

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

Опция root позволяет указать хосты, в которых локальные суперпользователи root получают права root сервера на экспортируемый ресурс. В противном случае, даже если хосту даны права rw, пользователь root на нем приравнивается к пользователю nobody (uid=-2), т. е. к пользователю с минимальными правами доступа. Вышесказанное относится именно к правам доступа к удаленному ресурсу и не влияет на права доступа к локальным ресурсам клиента.

Опции anon и secure будут рассмотрены при описании схемы аутентификации NFS.

ПРАВИЛА МОНТИРОВАНИЯ

Если для сервера экспортируемые ресурсы могут выступать в качестве файловой системы или отдельного каталога, то для клиента они всегда выглядят как файловые системы. Поскольку поддержка NFS встроена в ядро UNIX, то операция монтирования файловых систем NFS производится стандартной утилитой mount (отдельный демон для монтирования NFS не требуется), при этом необходимо лишь оговорить, что монтируемая файловая система - NFS. Еще один способ монтирования - с помощью файла /etc/fstab (/etc/filesystems в некоторых версиях UNIX). В данном случае удаленные системы NFS (так же, как и локальные) монтируются на стадии загрузки ОС. Точки монтирования могут быть любые, в том числе и в составе других файловых систем NFS, т. е. системы NFS можно "нанизывать" друг на друга.

Основные опции монтирования NFS перечислены в Таблице 2.

Опция bg позволяет производить монтирование в фоновом режиме, в этом случае можно запускать другие команды монтирования.

Весьма интересной представляется пара опций hard/soft. При "жестком" монтировании клиент будет пытаться смонтировать файловую систему во что бы то ни стало. Если сервер не работает, это приведет к тому, что весь сервис NFS как бы зависнет: процессы, обращающиеся к файловой системе, перейдут в состояние ожидания окончания выполнения запросов RPC. С точки зрения пользовательских процессов файловая система будет выглядеть как очень медленный локальный диск. При возврате сервера в рабочее состояние сервис NFS будет продолжать функционировать как ни в чем не бывало. Использование опции intr позволяет с помощью системного сигнала INTERRUPT прервать процесс "жесткого" монтирования.

При "мягком" монтировании клиент NFS сделает несколько попыток подключиться к серверу, как оговорено в опциях retans и timeo (некоторыми системами поддерживается также специальная опция retry). Если сервер не откликается, то система выдает сообщение об ошибке и прекращает попытки произвести монтирование. С точки зрения логики файловых операций при отказе сервера "мягкое" монтирование эмулирует сбой локального диска. Если опция retrans (retry) не задана, то количество попыток ограничено значением, принятым по умолчанию для данной системы UNIX. Параметры retrans и timeo относятся не только к монтированию, но и к любым операциям RPC, производимым с файловой системой NFS. Т. е. если клиент осуществляет операцию записи, а в это время в сети или на сервере происходит сбой, то клиент будет пытаться повторить запросы.

На вопрос, какой из режимов, "мягкий" или "жесткий", лучше, однозначно ответить невозможно. Если данные на сервере должны быть согласованы при его временном отказе, то "жесткое" монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах "только для чтения", режим "мягкого" монтирования представляется более предпочтительным.

АУТЕНТИФИКАЦИЯ И БЕЗОПАСНОСТЬ

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

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

Вот, собственно, и весь нехитрый набор средств аутентификации клиентов, пользователи же никак не аутентифицируются. Тем не менее каждый запрос RPC содержит идентификатор пользователя uid, инициировавшего запрос, и список идентификаторов групп gid, куда входит пользователь. Но эти идентификаторы используются не для аутентификации, а для определения прав доступа конкретного пользователя к файлам и каталогам.

Обратите внимание, что uid и gid определяются на стороне клиента, а не сервера. Поэтому перед администраторами встает проблема согласования содержимого /etc/passwd (и /etc/group) между клиентами и серверами NFS, чтобы пользователю Васе на сервере не присвоили права пользователя Пети. Для больших сетей это представляет серьезные трудности. Обеспечить согласованность пользовательской базы данных, а также таких системных файлов, как /etc/hosts, /etc/rpc, /etc/services, /etc/protocols, /etc/aliases и др., можно с помощью сетевой информационной службы (Network Information System, NIS), разработанной компанией Sun еще в 1985 году и входящей в состав большинства версий UNIX (более продвинутая ее разновидность NIS+ не нашла широкого применения). NIS представляет собой информационную службу, в первом приближении напоминающую службу каталогов Windows NT, и позволяет централизованно хранить и обрабатывать системные файлы. Между прочим, NIS построена по тому же принципу, что и NFS, в частности она использует протоколы RPC и XDR.

Еще одна важная особенность NFS состоит в том, что в каждом запросе RPC передается список групп gid пользователя. Для ограничения размера пакета RFC в большинстве реализаций NFS количество групп не может превышать 8 или 16. Если пользователь входит в состав большего количества групп, то это может привести к ошибкам при определении прав доступа на сервере. Данная проблема весьма актуальна для корпоративных файловых серверов. Радикальным решением является использование списков контроля доступа ACL, но, к сожалению, далеко не все разновидности UNIX их поддерживают.

Принятая в NFS система аутентификации весьма убога и не обеспечивает надежной защиты. Любой, кто имел дело с NFS, знает, как просто обойти ее систему безопасности. Для этого даже не обязательно применять методы подделки IP-адресов (IP-spoofing) или имен (DNS-spoofing). Злоумышленнику достаточно перехватить "магическое число", и в дальнейшем он может проводить действия от имени клиента. К тому же "магическое число" не меняется до следующей перезагрузки сервера.

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

Исходя из этих соображений, Sun разработала протокол SecureRPC с использованием как несимметричных, так и симметричных ключей шифрования. При этом криптографические методы применяются для аутентификации не только хостов, но и пользователей. Однако сами данные не шифруются. К сожалению, из-за экспортных ограничений правительства США не все UNIX поставляются с поддержкой SecureRPC. Поэтому мы не будем останавливаться на возможностях этого протокола. Тем не менее если ваша версия UNIX поддерживает SecureRPC, то неоценимую помощь в его настройке окажет книга Хала Стейна "Managing NFS and NIS" издательства O"Reilly & Assоciates.

Еще одна проблема связана с клиентами NFS на платформах MS-DOS и Windows 3.x/9x. Эти системы являются однопользовательскими, и обычными средствами NFS идентифицировать пользователя невозможно. Для целей идентификации пользователей DOS/Windows на сервере запускается демон pcnfsd. При подключении (монтировании) дисков NFS на клиентской машине он запрашивает имя и пароль пользователя, что позволяет не только идентифицировать, но и аутентифицировать пользователей.

Хотя ОС Windows NT является многопользовательской, но ее пользовательская база данных и схема идентификации пользователей несовместимы с принятой в UNIX. Поэтому клиентские места NFS на базе Windows NT также вынуждены задействовать возможности pcnfsd.

Кроме аутентификации пользователей pcnfs позволяет осуществлять печать на UNIX с клиентских мест DOS/Windows. Правда, в состав Windows NT изначально входит программа LPR.EXE, также позволяющая осуществлять печать на серверах UNIX.

Для доступа к файловому сервису и сервису NFS на машинах DOS/Windows необходимо инсталлировать специальное клиентское ПО, причем цены на эти продукты весьма кусаются.

Вернемся, однако, к опциям экспортирования файлов NFS (см. Таблицу 1). Опция anon определяет идентификатор пользователя uid в том случае, когда пользователь DOS/Windows не мог себя аутентифицировать (задал неверный пароль) или когда пользователь хоста, подключенного по SecureRPC, не прошел аутентификацию. По умолчанию anon имеет uid=-2.

Опция secure применяется, когда используется протокол SecureRPC.

АРХИТЕКТУРНЫЕ ОСОБЕННОСТИ NFS V2

Файловые системы NFS должны подчиняться двум условиям (кстати, эти же требования относятся не только к NFS, но и к другим сетевым файловым системам).

1. С точки зрения клиентских пользовательских программ файловая система NFS располагается как бы на локальном диске. Программы не имеют возможности отличить файлы NFS от обычных файлов.
2. Клиент NFS не в состоянии определить, какая платформа используется в качестве сервера. Это может быть и UNIX, и MVS, и даже Windows NT. Различия в архитектуре серверов сказываются только на уровне конкретных операций, а не в отношении возможностей NFS. Для клиента файловая структура NFS аналогична локальной системе.

Первый уровень прозрачности достигается за счет использования в UNIX виртуальной файловой системы (Virtual File System, VFS). VFS отвечает за взаимодействие не только с NFS, но и с локальными системами наподобие UFS, ext2, VxFS и т. д.

Второй уровень прозрачности обеспечивается благодаря использованию так называемых виртуальных узлов (virtual nodes, vnodes), структуру которых можно соотнести с inodes в файловых системах UNIX.

Операции над файловыми системами NFS являются операциями VFS, тогда как взаимодействие с отдельными файлами и каталогами определяется операциями vnode. Протокол RPC из состава NFS v2 описывает 16 процедур, связанных с операциями не только над файлами и каталогами, но и над их атрибутами. Важно понимать, что вызовы RPC и интерфейс vnode - разные понятия. Интерфейсы vnode определяют сервисы ОС для доступа к файловым системам независимо от того, локальные они или удаленные. RPC же из состава NFS представляет собой специфическую реализацию одного из интерфейсов vnode.

Операции чтения/записи кэшируются на стороне клиента, т. е. клиент кэширует содержимое файлов и каталогов. Обычно размер буфера кэша NFS составляет 8 Кбайт. Если на клиенте запущены демоны biod, то чтение производится с опережением, а запись осуществляется в отложенном режиме. Например, если пользовательский процесс записывает информацию, то данные накапливаются в буфере кэша и лишь затем производится их пересылка, причем обычно в одном пакете RPC. В момент выполнения операции записи ядро сразу же возвращает управление процессу, а функции пересылки запросов RPC передаются biod. Если же демоны biod не запущены и ядро не поддерживает многопоточной обработки RPC, то пересылкой пакетов RPC в однопоточном режиме должно заниматься ядро, а пользовательский процесс переходит в состояние ожидания окончания пересылки. Но и в этом случае кэш NFS по-прежнему используется.

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

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

К сожалению, определить оптимальное количество демонов biod и nfsd очень непросто. С одной стороны, чем больше количество работающих демонов, тем большее количество запросов может быть обработано одновременно; с другой стороны, увеличение количества демонов может неблагоприятно повлиять на производительность системы ввиду возрастания накладных расходов на переключение процессов. Тонкая настройка NFS представляет собой весьма утомительную процедуру и требует учета не только количества клиентов и пользовательских процессов, но и таких характеристик, как время переключения между контекстами процессов (т. е. особенности архитектуры процессора), размер оперативной памяти, загрузка системы и т. д. Такие настройки лучше определять экспериментальным путем, хотя в большинстве случаев подойдут и стандартные (обычно на сервере запускают 8 демонов nfsd, а на клиентах - 4 демона biod).

Рисунок 2. Операция записи в NFS v2.

Очень важной особенностью NFS v2 является то, что на стороне сервера операции записи не кэшируются (см. Рисунок 2). Это было сделано в целях обеспечения высокой надежности сервиса NFS и позволяет гарантировать целостность данных после перезагрузки сервера в случае его отказа. Отсутствие кэширования информации при записи представляет собой самую большую проблему NFS v2. На операциях записи NFS значительно уступает конкурирующим технологиям, хотя на операциях чтения мало в чем им проигрывает. Единственный метод борьбы с невысокой производительностью записи состоит в использовании дисковых подсистем с независимым от электропитания встроенным кэшем, как в довольно дорогих массивах RAID.

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

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

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

Система RPC не отслеживает состояние соединения, что создает проблемы при одновременном обращении нескольких клиентов к одному и тому же файлу. Здесь возникают две сложности:

• как осуществить блокировку файла, в частности при записи в него;
• как гарантировать целостность блокировок в случае краха и перезагрузки сервера или клиента NFS?

Для этого в NFS применяются два специальных демона: rpc.lockd отвечает за блокировку файлов, а rpc.statd - за мониторинг состояния блокировок (см. Рисунок 3). Эти демоны запускаются как на стороне клиента, так и на стороне сервера. За демонами rpc.lockd и rpc.statd закреплены два специальных каталога (sm и sm.bak), где хранится информация по блокировкам.

Своеобразный и достаточно удобный дополнительный сервис automounter позволяет автоматически монтировать файловые системы при обращении к ним пользовательских процессов. В дальнейшем automounter периодически (по умолчанию раз в пять минут) пытается размонтировать систему. Если она занята (допустим, открыт файл), то сервис продолжает работать в обычном режиме. Если же к файловой системе больше нет обращений, то она автоматически размонтируется. Функция automounter реализует несколько программ, особой популярностью среди них пользуются amd и autofs.

ВОЗМОЖНОСТИ NFS V3

Третья версия NFS полностью обратно совместима со второй версией, т. е. сервер NFS v3 "понимает" клиентов NFS v2 и NFS v3. Аналогично, клиент NFS v3 может обращаться к серверу NFS v2.

Важным нововведением NFS v3 является поддержка транспортного протокола TCP. UDP прекрасно подходит для локальных сетей, но не годится для медленных и не всегда надежных глобальных линий связи. В NFS v3 весь клиентский трафик мультиплексируется в одно соединение TCP.

В NFS v3 размер буфера кэша увеличен до 64 Кбайт, что благотворно повлияло на производительность, особенно в свете активного использования высокоскоростных сетевых технологий Fast Ethernet, Gigabit Ethernet и ATM. Кроме того, NFS v3 позволяет хранить кэшируемую на клиенте информацию не только в оперативной памяти, но и на локальном диске клиента (справедливости ради, стоит отметить, что некоторые реализации NFS v2 тоже предусматривают такую возможность). Такая технология известна как CacheFS.

Рисунок 4. Операция записи в NFS v3.

Но, пожалуй, еще более важным новшеством NFS v3 можно считать радикальное увеличение производительности на операциях записи. Теперь кэширование записываемой информации производится также на стороне сервера, при этом регистрация и подтверждение факта записи данных на диск осуществляются с помощью специального запроса commit (см. Рисунок 4). Эту технологию называют безопасной асинхронной записью. После того как данные пересланы в кэш сервера, клиент посылает ему запрос commit, инициирующий операцию записи на диск сервера. В свою очередь по окончании записи информации на диск сервер отправляет клиенту подтверждение ее успешного завершения.

Новым в NFS v3 является поддержка 64-разрядных файловых систем и улучшенная поддержка списков контроля доступа ACL.

Что касается перспектив, то сейчас Sun продвигает технологию WebNFS, использование которой позволяет получить доступ к файловым системам из любого браузера Web или через приложения, написанные на Java. При этом никакого клиентского ПО устанавливать не требуется. WebNFS (по утверждению Sun) дает выигрыш в производительности по сравнению с ftp или HTTP в три-пять раз.

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

Установка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что еще

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

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

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

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

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

Локальные файловые системы;

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

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

Клиенты сетевой файловой системы;

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

Протокол клиент-сервер сетевой файловой системы.

Клиенты сетевой ФС - это программы, работающие на многочисленных компьютерах, подключенных к сети. Эти программы обслуживают запросы приложений на доступ к файлам, хранящимся на удаленных компьютерах. Клиент сетевой ФС передает по сети запросы другому программному компоненту - серверу сетевой ФС, работающему на удаленном компьютере. Сервер, получив запрос, может выполнить его самостоятельно либо, что является более распространенным вариантом, передать запрос для обработки локальной файловой системе. После получения ответа от локальной ФС сервер передает его по сети__

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

В операционных системах Windows основной сетевой файловой службы является протокол SMB (Server Message Block), который был совместно разработан компаниями Microsoft, Intel и IBM. Его последние расширенные версии получили название Common Internet File System, CIFS.

Протокол работает на прикладном уровне модели OSI. Для передачи по сети своих сообщений SMB использует различные транспортные протоколы. Исторически первым таким протоколом был NetBIOS (и его более поздняя версия NetBEUI), но сейчас сообщения SMB могут передаваться и с помощью других протоколов (TCP/UDP и IPX).

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

1. Отказ компьютера, на котором выполняется сервер сетевой файловой системы, во время сеанса связи с клиентом. Локальная ФС запоминает состояние последовательных операций, которые приложение выполняет с одним и тем же файлом, за счет ведения__ внутренней таблицы открытых файлов (системные вызовы open, read, write изменяют состояние этой таблицы). При крахе системы таблица открытых файлов теряется после перезагрузки серверного компьютера. В этом случае приложение, работаю-щее на клиентском компьютере, не может продолжить работу с файлами, открытыми до краха.

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

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

3. Потери данных и разрушение целостности файловой системы при сбоях и отказах компьютеров, играющих роль файловых серверов. Для повышения отказоустойчивости сетевой ФС можно хранить несколько копий каждого файла (или целиком всей ФС) на нескольких серверах. Такие копии файла называются репликами (replica).

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

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

Перечисленные проблемы решаются комплексно путем создания службы центра лизованной аутентификации, репликации, кэширования и др. Эти дополнительные службы находят свое отражение в протоколе взаимодействия клиентов и серверов, в результате чего создаются различные протоколы этого типа, поддерживающие тот или иной набор дополнительных функций. Поэтому для одной и той же локальной ФС могут существовать различные протоколы сетевой ФС (рис. 5.30). Так, к файловой системе NTFS сегодня можно получить доступ с помощью протоколов SMB, NCP (NetWare Control Protocol) и NFS (Network File System - протокол сетевой ФС компании Sun Microsystems, используемой в различных вариантах ОС семейства UNIX).

С другой стороны, с помощью одного и того же протокола может реализоваться удаленный доступ к локальным ФС разного типа. Например, протокол SMB используется для доступа не только к ФС типа FAT, но и ФС NTFS, HPFS (рис. 5.31). Эти ФС могут располагаться как на разных, так и на одном компьютере.__

Контрольные вопросы к главе 5

1. Какими преимуществами обладают сети по сравнению с раздельным использованием компьютеров?

2. Всегда ли совпадают физическая и логическая топологии сети?

3. Как классифицируются сети по величине охватываемой территории?

4. Какой компьютер может выполнять роль сервера в сети?

5. Что такое файловый сервер и сервер печати?

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

7. Какие функции выполняют серверы удаленного доступа?

8. Что такое прокси-сервер?

9. Перечислите возможных клиентов компьютерной сети.

10. Что такое ≪толстый≫ и ≪тонкий≫ клиенты в компьютерной сети?

11. Как вы понимаете термин ≪сегментация≫ сети?

12. Что такое МАС-адрес?

13. Чем распределенная ОС отличается от сетевой? Существуют ли в настоящее время по-настоящему распределенные сетевые системы?

14. Перечислите основные компоненты сетевой ОС. Что такое сетевая служба? Какие сетевые службы вы можете назвать?

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

16. Что представляли собой первые сетевые ОС? Какие подходы к созданию сетевых ОС используются в настоящее время?

17. Назовите характерные черты одноранговых сетей. В чем основная особенность многоранговой сети?

18. Что такое серверная ОС? Какие они бывают? Чем серверная ОС отличается от клиентской?

19. Сколько вариантов двухзвенных схем используется для распределенной обработки приложений?

20. Чем хороша двухзвенная обработка приложений при сотрудничестве сервера и клиента?

21. Есть ли преимущества у трехзвенной схемы обработки приложений, в чем они заключаются?

22. Как могут взаимодействовать процессы в распределенных системах?

23. Какие основные примитивы используются в транспортной системе сетевой ОС?

24. Как организуется синхронизация процессов в сети?

25. Что понимается под вызовом удаленных процедур?

Глава 29 NFS: сетевая файловая система

Введение

В этой главе мы рассмотрим сетевую файловую систему ( NFS - Network File System), популярное приложение, которое предоставляет приложениям клиентов прозрачный доступ к файлам. Краеугольным камнем NFS является Sun RPC: вызов удаленной процедуры (Remote Procedure Call), что мы и опишем в первую очередь.

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

Мы не будем подробно рассматривать, как реализуется доступ к файлам, а рассмотрим, как при этом используются протоколы Internet, особенно UDP.

Вызов удаленной процедуры компании Sun

В большинстве случаев задачи сетевого программирования решаются путем написания программ приложений, которые вызывают функции, предоставляемые системой, чтобы осуществить конкретные сетевые операции. Например, одна функция осуществляет активное открытие TCP, другая пассивное открытие TCP, третья посылает данные по TCP соединению, четвертая устанавливает конкретные опции протокола (включает TCP таймер "оставайся в живых") и так далее. В разделе "Интерфейсы прикладного программирования" главы 1 мы упоминали, что существует два популярных набора функций для сетевого программирования (прикладной программный интерфейс, API), это сокеты и TLI. Программный интерфейс, используемый клиентом, и программный интерфейс, используемый сервером, могут отличаться, так же как и операционные системы, которые функционируют у клиента и сервера. Именно коммуникационный и прикладной протоколы определяют, сможет ли конкретный клиент общаться с сервером. Unix клиент, написанный на C, использующий сокеты в качестве программного интерфейса, и TCP - в качестве коммуникационного протокола, может общаться с сервером на мейнфрейме, написанным на COBOLе с использованием других API и TCP, если оба хоста подключены к сети и оба имеют реализацию TCP/IP.

Обычно клиент посылает серверу команды, а сервер отправляет клиенту отклики. Все рассмотренные нами приложения, - Ping, Traceroute, демоны маршрутизации, клиенты и сервера DNS, TFTP, BOOTP, SNMP, Telnet, FTP, SMTP - все построены именно таким образом.

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

1. Когда клиент вызывает удаленную процедуру, вызывается функция на локальном хосте, которая сгенерирована пакетом RPC. Эта функция называется client stub. client stub упаковывает аргументы процедуры в сетевое сообщение и отправляет сообщение серверу.
2. server stub на хосте сервера получает сетевое сообщение. Аргументы извлекаются из сетевого сообщения, и осуществляется вызов процедуры сервера, написанной прикладным программистом.
3. Функция сервера возвращает управление server stubу, который, в свою очередь, принимает полученные значения, упаковывает их в сетевое сообщение и отправляет сообщение обратно к client stub.
4. client stub возвращает приложению клиента значения из сетевого сообщения.

Сетевое программирование, использующее stubы и библиотечные RPC подпрограммы использует интерфейсы прикладного программирования API (сокеты или TLI), однако пользовательские приложения (программа клиента и процедуры сервера, вызываемые клиентом) никогда не обращаются к API. Приложению клиента достаточно вызывать процедуру сервера, при этом все детали реализации спрятаны пакетом RPC, client stubом и server stubом.

Пакеты RPC имеют следующие положительные стороны.

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

Программирование RPC подробно описано в главе 18 . Два наиболее популярных RPC пакета это Sun RPC и RPC пакет в Open Software Foundation"s ( OSF) Distributed Computing Environment ( DCE). Мы рассмотрим, как осуществляется вызов процедуры, как выглядит возвращаемое сообщение и как это соотносится с пакетом Sun RPC, так как именно этот пакет используется в сетевой файловой системе. Версия 2 Sun RPC описана в RFC 1057 [ Sun Microsystems 1988a].

Существует два вида Sun RPC. Одна версия построена с использованием API сокет и работает с TCP и UDP. Другая называется TI-RPC (независимо от транспорта - transport independent), построена с использованием TLI API и работает с любыми транспортными уровнями, предоставляемыми ядром. С нашей точки зрения между ними нет никакой разницы, так как в этой главе мы рассматриваем только TCP и UDP.

На рисунке 29.1 показан формат сообщения вызова процедуры RPC, с использованием UDP.

Рисунок 29.1 Сообщения вызова процедуры RPC в формате UDP датаграммы.

Стандартные IP и UDP заголовки показаны раньше (рисунок 3.1 и рисунок 11.2). Все, что следует после UDP заголовка, определяется пакетом RPC.

Идентификатор транзакции ( XID - transaction ID) устанавливается клиентом и возвращается сервером. Когда клиент получает отклик, он сравнивает XID, возвращенный сервером, с XID отправленного запроса. Если они не совпадают, клиент отбрасывает сообщение и ожидает прихода следующего. Каждый раз, когда клиент выдает новый RPC, он меняет XID. Однако если клиент передает RPC повторно (если отклик не был получен), XID не меняется.

Переменная call равна 0 для вызова и 1 для отклика. Текущая версия RPC (RPC version) равна 2. Три следующие переменные, номер программы (program number), номер версии (version number) и номер процедуры (procedure number), идентифицируют конкретную процедуру, которая должна быть вызвана на сервере.

Полномочия (credentials) идентифицируют клиента. В некоторых примерах это поле остается незаполненным, а в других здесь можно встретить цифровой идентификатор пользователя и идентификатор группы к который он принадлежит. Сервер может заглянуть в полномочия и решить, обработать ли запрос или нет. Проверка (verifier) используется для защищенного RPC (Secure RPC), которое использует DES шифрование. Несмотря на то, что поля полномочий и проверки это поля с переменной длиной, их длина передается как часть поля.

Дальше следуют параметры процедуры. Их формат зависит от того, как приложение определяет удаленную процедуру. Как получатель (server stub) узнает размер параметров? Так как используется UDP, размер параметров можно рассчитать как размер UDP датаграммы минус длина всех полей вплоть до поля проверки. Когда вместо UDP используется TCP, понятия фиксированной длины не существует, так как TCP это поток байтов без разделителей записей. В подобном случае, между TCP заголовком и XID появляется 4-байтовое поле длины, из которого приемник узнает длину RPC вызова в байтах. Это позволяет, если необходимо, послать сообщение вызова RPC в нескольких TCP сегментах. (DNS использует подобную технику; упражнение 4 главы 14.)

На рисунке 29.2 показан формат RPC отклика. Он отправляется от server stub к client stub, когда удаленная процедура завершает свою работу.

Рисунок 29.2 Формат сообщения отклика процедуры RPC как UDP датаграмма.

XID вызова просто копируется в XID отклика. В поле reply находится 1, по этому полю проводится различие между вызовом и откликом. Поле статуса (status) содержит нулевое значение, если сообщение вызова было принято. (Сообщение может быть отброшено, если номер версии RPC не равен 2 или если сервер не может аутентифицировать клиента.) Поле проверки (verifier) используется в случае защищенного RPC, чтобы указать сервер.

В поле статуса приема (accept status) находится нулевое значение, если все нормально. Ненулевое значение может указывать, например, на неверный номер версии или неверный номер процедуры. Если вместо UDP используется TCP, то, как и в случае сообщения вызова RPC, между TCP заголовком и XID посылается 4-байтовое поле длины.

XDR: представление внешних данных

Представление внешних данных ( XDR - External Data Representation) это стандарт, используемый для кодирования значений в RPC вызове и отклике сообщениях - полей заголовка RPC (XID, номер программы, статус приема и так далее), параметров процедуры и результатов процедуры. Стандартный способ кодирования данных позволяет клиенту вызвать процедуру в системе с отличной архитектурой. XDR определен в RFC 1014 [ Sun Microsystems 1987].

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

Соответствие портов

Программы RPC сервера, содержащие удаленные процедуры, используют динамически назначаемые порты, а не заранее известные порты. Это требует "регистрации" в какой-либо форме, для того чтобы постоянно иметь информацию, какая динамически назначаемый порт использует та или иная RPC программа. В Sun RPC этот регистратор называется преобразователь портов (port mapper). (Port mapper - это сервер, который конвертирует номера RPC программ в номера портов протоколов DARPA. Этот сервер обязательно должен быть запущен, чтобы можно было исполнить RPC вызов.)

Термин "порт" (port) в названии происходит от номеров портов TCP и UDP, характеристики семейства протоколов Internet. Так как TI-RPC работает поверх любых транспортных уровней, а не только поверх TCP и UDP, название port mapper в системах, использующих TI-RPC ( SVR4 и Solaris 2.2, например), было преобразовано в rpcbind. Однако мы будем продолжать использовать более привычное - port mapper.

В действительности, сам преобразователь портов должен иметь заранее известный порт: UDP порт 111 и TCP порт 111. Преобразователь портов - это всего лишь программа RPC сервера. Он имеет номер программы (100000), номер версии (2), TCP порт 111 и UDP порт 111. Серверы регистрируют друг друга в преобразователе портов, используя RPC вызовы, а клиенты запрашивают преобразователь портов, используя RPC вызовы. Преобразователь портов предоставляет четыре процедуры сервера:

1. PMAPPROC_SET. Вызывается RPC сервером при старте, чтобы зарегистрировать номер программы, номер версии и протокол в преобразователе портов.
2. PMAPPROC_UNSET. Вызывается сервером, чтобы удалить ранее зарегистрированное преобразование.
3. PMAPPROC_GETPORT. Вызывается RPC клиентом при старте, чтобы получить номер порта для заданного номера программы, номера версии и протокола.
4. PMAPPROC_DUMP. Возвращает все пункты (номер программы, номер версии, протокол и номер порта) в базу данных преобразователя портов.

Когда стартует программа сервер RPC и позже, когда она вызывается программой клиента RPC, осуществляются следующие шаги.

1. Преобразователь портов должен стартовать первым, обычно при загрузке системы. При этом создается конечная точка TCP и осуществляется пассивное открытие TCP порта 111. Также создается конечная точка UDP, которая находится в ожидании, когда на UDP порт 111 прибудет UDP датаграмма.
2. При старте программа сервера RPC создает конечную точку TCP и конечную точку UDP для каждой поддерживаемой версии программы. (Программа RPC может поддерживать несколько версий. Клиент указывает требуемую версию при вызове процедуры сервера.) Динамически назначаемый номер порта закрепляется за каждой конечной точкой. (Нет никакой разницы, одинаковые ли номера портов TCP и UDP или разные.) Сервер регистрирует каждую программу, версию, протокол и номер порта, осуществляя удаленной вызов процедуры преобразователя портов PMAPPROC_SET.
3. Когда стартует программа клиента RPC, она вызывает процедуру преобразователя портов PMAPPROC_GETPORT, чтобы получить динамически назначаемый номер порта для заданной программы, версии и протокола.
4. Клиент отправляет сообщение вызова RPC на номер порта, полученный в пункте 3. Если используется UDP, клиент просто посылает UDP датаграмму, содержащую сообщение вызова RPC (рисунок 29.1), на номер UDP порта сервера. В ответ сервер отправляет UDP датаграмму, содержащую сообщение RPC отклика (рисунок 29.2). Если используется TCP, клиент осуществляет активное открытие на номер TCP порта сервера и затем посылает сообщение вызова RPC по соединению. Сервер отвечает сообщением отклика RPC по соединению.

Программа rpcinfo(8) печатает все текущие настройки преобразователя портов. (Здесь происходит вызов процедуры преобразователя портов PMAPPROC_DUMP.) Ниже показан обычный вывод:

Sun % /usr/etc/rpcinfo -p
program vers proto port
100005 1 tcp 702 mountd демон монтирования NFS
100005 1 udp 699 mountd
100005 2 tcp 702 mountd
100005 2 udp 699 mountd

100003 2 udp 2049 nfs сам NFS

100021 1 tcp 709 nlockmgr менеджер блокирования NFS
100021 1 udp 1036 nlockmgr
100021 2 tcp 721 nlockmgr
100021 2 udp 1039 nlockmgr
100021 3 tcp 713 nlockmgr
100021 3 udp 1037 nlockmgr

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

Доступ к обеим версиям монтирующего демона можно получить через один и тот же номер TCP порта (702) и один и тот же номер UDP порта (699), однако каждая версия блокирующего менеджера имеет свой собственный номер порта.

Протокол NFS

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

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

В этом разделе мы рассмотрим версию 2 NFS, как она документирована в RFC 1094 [ Sun Microsystems 1988b]. Лучшее описание Sun RPC, XDR и NFS дано в [ X/Open 1991]. Подробности использования и администрирования NFS приведены в [ Stern 1991]. Спецификации версии 3 протокола NFS были реализованы в 1993 году, о чем мы поговорим в разделе этой главы.

На рисунке 29.3 показаны типичные настройки NFS клиента и NFS сервера. На этом рисунке необходимо обратить внимание на следующее.

1. Клиенту безразлично, получает ли он доступ к локальному файлу или к NFS файлу. Ядро определяет это, когда файл открыт. После того как файл открыт, ядро передает все обращения к локальным файлам в квадратик, помеченный как "доступ к локальным файлам", а все ссылки на NFS файлы передаются в квадратик "NFS клиент".
2. NFS клиент отправляет RPC запросы NFS серверу через модуль TCP/IP. NFS обычно использует UDP, однако более новые реализации могут использовать TCP.
3. NFS сервер получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS может работать с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт 2049 жестко закреплен за NFS в большинстве реализаций.

Рисунок 29.3 Типичные настройки NFS клиента и NFS сервера.

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

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

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

Большинство Unix хостов может функционировать как NFS клиент и как NFS сервер, или как и то и другое одновременно. Большинство PC реализаций (MS-DOS) имеют только реализации NFS клиента. Большинство IBM мейнфреймов предоставляет только функции NFS сервера.

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

Приложение	Номер программы	Номер версии	Количество процедур
преобразователь портов
NFS
программа mount
менеджер блокирования
монитор статуса

Рисунок 29.4 Различные RPC программы, используемые в NFS.

Версии, которые мы показали на этом рисунке в виде единиц, найдены в таких системах как SunOS 4.1.3. Новые реализации предоставляют более новые версии некоторых программ. Solaris 2.2, например, также поддерживает версии 3 и 4 преобразователя портов и версию 2 демона mount. SVR4 также поддерживает версию 3 преобразователя портов.

Демон монтирования вызывается на хосте NFS клиента, перед тем как клиент может получить доступ к файловой системе сервера. Мы опишем этот процесс ниже.

Менеджер блокирования и монитор статуса позволяют клиенту заблокировать часть файлов, которые находятся на NFS сервере. Эти две программы не зависимы от протокола NFS, потому что блокирование требует идентификации клиента и на хосте клиента, и на сервере, а NFS сам по себе "безразличен". (Ниже мы скажем о безразличности NFS более подробно.) Главы 9, 10 и 11 [ X/Open 1991] документируют процедуры, которые используются менеджером блокирования и монитором статуса для блокирования в NFS.

Описатели файлов

Одна из основ NFS реализуется описателями файлов. Для обращения к файлу или директории на сервере объекта используется opaque. Термин opaque обозначает, что сервер создает описатель файла, передает его обратно клиенту, который клиент затем использует при обращении к файлу. Клиент никогда не просматривает содержимое описателя файла - его содержимое представляет интерес только для сервера.

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

Обычно пользовательский процесс не работает с описателями файлов. Обмен описателями файлов осуществляют NFS клиент и NFS сервер. В версии 2 NFS описатель файла занимает 32 байта, а в версии 3 он вырос до 64 байт.

Unix серверы обычно хранят в описателе файла следующую информацию: идентификатор файловой системы (major и minor номера устройства файловой системы), номер инода (i-node) (уникальный номер внутри файловой системы), номер поколения инода (номер, который изменяется каждый раз, когда инод повторно используется для другого файла).

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

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

На рисунке 29.5 описана последовательность действий Unix клиента при исполнении команды mount(8).

Рисунок 29.5 Протокол монтирования, используемый Unix командой mount.

При этом осуществляются следующие шаги.

1. При загрузке сервера на нем стартует преобразователь портов.
2. После преобразователя портов на сервере стартует демон монтирования ( mountd). Он создает конечную точку TCP и конечную точку UDP, а также назначает каждой из них динамически назначаемый номер порта. Затем он регистрирует эти номера у преобразователя портов.
3. Клиент исполняется команду mount, которая выдает RPC вызов на преобразователь портов сервера, чтобы получить номер порта от демона монтирования на сервере. Для обмена между клиентом и преобразователем портов могут быть использованы и TCP и UDP, однако обычно используется UDP.
4. Преобразователь портов сообщает номер порта.
5. Команда mount выдает RPC вызов демону монтирования, чтобы смонтировать файловую систему сервера. И снова может быть использован как TCP, так и UDP, однако обычно используется UDP. Теперь сервер может проверить "годность" клиента основываясь на его IP адресе и номере порта, чтобы убедиться, можно ли этому клиенту смонтировать указанную файловую систему.
6. Демон монтирования откликается описателем файла указанной файловой системы.
7. Команда mount клиента выдает системный вызов mount, чтобы связать описатель файла, полученный в шаге 5, с локальной точкой монтирования на хосте клиента. Описатель файла хранится в коде NFS клиента, и с этого момента любое обращение пользовательских процессов к файлам на файловой системе сервера будет использовать описатель файла как стартовую точку.

Подобная реализация отдает весь процесс монтирования, кроме системного вызова mount на клиенте, пользовательским процессам, а не ядру. Три программы, которые мы показали - команда mount, преобразователь портов и демон монтирования - пользовательские процессы.

В этом примере на хосте sun (NFS клиент) была исполнена команда

sun # mount -t nfs bsdi:/usr /nfs/bsdi/usr

Эта команда монтирует директорию /usr на хосте bsdi (NFS сервер) как локальную файловую систему /nfs/bsdi/usr. На рисунке 29.6 показан результат.

Рисунок 29.6 Монтирование директории bsdi:/usr как /nfs/bsdi/usr на хосте sun.

После чего при обращении к файлу /nfs/bsdi/usr/rstevens/hello.c на клиенте sun, происходит обращение к файлу /usr/rstevens/hello.c на сервере bsdi.

Процедуры NFS

NFS сервер предоставляет 15 процедур, которые мы сейчас опишем. (Числа, которые использованные при описании, не совпадают с номерами NFS процедур, так как мы сгруппировали их по функциональному признаку.) Несмотря на то что NFS разрабатывалась таким образом, чтобы работать между различными операционными системами, а не только между Unix системами, некоторые из процедур основаны именно на Unix функционировании, что, в свою очередь, может не поддерживаться другими операционными системами (например, жесткие линки, символические линки, групповое пользование, права доступа на исполнение и так далее). Глава 4 содержит дополнительную информацию о характеристиках файловых систем, некоторыми из которых пользуется NFS.

1. GETATTR. Возвращает атрибуты файлов: тип файла (обычный файл, директория и так далее), права доступа, размер файла, владельца файла, время последнего обращения и так далее.
2. SETATTR. Устанавливает атрибуты файла. Установлен может быть только определенный набор атрибутов: права доступа, владелец, групповое владение, размер, время последнего обращения и время последней модификации.
3. STATFS. Возвращает статус файловой системы: размер свободного пространства, оптимальный размер для передачи и так далее. Используется, например, Unix командой df.
4. LOOKUP. "Оценивает" файл. Эта процедура вызывается клиентом каждый раз, когда пользовательский процесс открывает файл, который находится на NFS сервере. Возвращается описатель файла, вместе с атрибутами файла.
5. READ. Читает из файла. Клиент указывает описатель файла, начальное смещение в байтах и максимальное количество байтов, которое необходимо считать (до 8192).
6. WRITE. Записывает в файл. Клиент указывает описатель файла, начальное смещение в байтах, количество байт, которое необходимо записать, и данные, которые необходимо записать.

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

7. CREATE. Создает файл.
8. REMOVE. Удаляет файл.
9. RENAME. Переименовывает файл.
10. LINK. Делает жесткий линк на файл. Жесткий линк это Unix концепция, которая определяет, что конкретный файл на диске может иметь любое количество точек входа (имен, которые также называются жесткими линками), которые указывают на этот файл.
11. SYMLINK. Создает символический линк на файл. Символический линк это файл, который содержит имя другого файла. Большинство операций, которые осуществляются над символическим линком (например, открытие), в действительности совершаются с тем файлом, на котороый указывает символический линк.
12. READLINK. Чтение символического линка возвращает имя файла, на который указывает символический линк.
13. MKDIR. Создает директорию.
14. RMDIR. Удаляет директорию.
15. READDIR. Читает директорию. Используется, например, Unix командой ls.

В действительности, приведенные имена процедур начинаются с префикса NFSPROC_, который мы опустили.

UDP или TCP?

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

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

NFS поверх TCP

Реализация NFS Berkeley Net/2 поддерживает как UDP, так и TCP. [ Macklem 1991] описывает эту реализацию. Давайте рассмотрим, чем отличается использование NFS при работе поверх TCP.

1. Когда сервер загружается, он запускает NFS сервер, который осуществляет активное открытие на TCP порт 2049, ожидая прихода запроса на соединение от клиента. Это обычно делается в дополнение к обычному NFS UDP, который ожидает входящие датаграммы на UDP порте 2049.
2. Когда клиент монтирует файловую систему сервера с использованием TCP, он осуществляет активное открытие на TCP порт 2049 на сервере. При этом устанавливается TCP соединение между клиентом и сервером для этой файловой системы. Если тот же самый клиент монтирует еще одну файловую систему на том же самом сервере, создается еще одно TCP соединение.
3. И клиент, и сервер устанавливают TCP опцию "оставайся в живых" на своих концах соединения (глава 23). Это позволяет определить момент выхода из строя или перезагрузки того или иного участника обмена.
4. Все приложения на клиенте, которые используют файловую систему сервера, делят одно и то же TCP соединение для этой файловой системы. Например, если была на рисунке 29.6, бы еще одна директория на bsdi, с именем smith, ниже директории /usr, обращения к файлам в /nfs/bsdi/usr/rstevens и /nfs/bsdi/usr/smith делили бы одно и то же TCP соединение.
5. Если клиент определяет, что сервер вышел из строя или перезагрузился (после получения TCP ошибки "соединение закрыто по тайм-ауту" или "соединение закрыто хостом"), он старается повторно подсоединиться к серверу. Клиент осуществляет еще одно активное открытие, чтобы повторно установить TCP соединение для этой файловой системы. Любой запрос от клиента, для которого отработан тайм-аут на предыдущем соединении, повторно выдается на новое соединение.
6. Если клиент вышел из строя, то же происходит и с приложениями, которые работали до выхода из строя. Когда клиент перезагружается, он, возможно, повторно смонтирует файловую систему сервера с использованием TCP, причем будет использовано другое TCP соединение с сервером. Предыдущее соединение между клиентом и сервером для этой файловой системы находится в полуоткрытом состоянии (сервер думает, что оно все еще открыто), однако так как сервер установил опцию "оставайся в живых", это полуоткрытое соединение будет закрыто, когда TCP сервер пошлет следующую пробу "оставайся в живых".

Со временем и другие производители планируют начать поддержку NFS поверх TCP.

Примеры NFS

Давайте воспользуемся tcpdump, чтобы посмотреть, какие NFS процедуры привлекаются клиентом для обычных операций с файлом. Когда tcpdump определяет, что UDP датаграмма содержит RPC вызов (call равен 0 на рисунке 29.1) с портом назначения 2049, он декодирует датаграмму как NFS запрос. Точно так же, если UDP датаграмма содержит RPC отклик (reply равен 1 на рисунке 29.2) с портом источника равным 2049, он декодирует датаграмму как NFS отклик.

Простой пример: чтение файла

В первом примере мы скопируем файл, находиться на NFS сервере, на терминал с использованием команды cat(1):

Sun % cat /nfs/bsdi/usr/rstevens/hello.c копирование файла на терминал
main()
{
printf ("hello, world\n");
}

Файловая система /nfs/bsdi/usr на хосте sun (NFS клиент) в действительности является файловой системой /usr на хосте bsdi (NFS сервер), как показано на рисунке 29.6. Ядро sun определяет это, когда cat открывает файл и использует NFS для доступа к файлу. На рисунке 29.7 показан вывод команды tcpdump.

1 0.0 sun.7aa6 > bsdi.nfs: 104 getattr
2 0.003587 (0.0036) bsdi.nfs > sun.7aa6: reply ok 96

3 0.005390 (0.0018) sun.7aa7 > bsdi.nfs: 116 lookup "rstevens"
4 0.009570 (0.0042) bsdi.nfs > sun.7aa7: reply ok 128

5 0.011413 (0.0018) sun.7aa8 > bsdi.nfs: 116 lookup "hello.c"
6 0.015512 (0.0041) bsdi.nfs > sun.7aa8: reply ok 128

7 0.018843 (0.0033) sun.7aa9 > bsdi.nfs: 104 getattr
8 0.022377 (0.0035) bsdi.nfs > sun.7aa9: reply ok 96

9 0.027621 (0.0052) sun.7aaa > bsdi.nfs: 116 read 1024 bytes @ 0
10 0.032170 (0.0045) bsdi.nfs > sun.7aaa: reply ok 140

Рисунок 29.7 Функционирование NFS при чтении файла.

Команда tcpdump декодирует NFS запрос или отклик, также она печатает поле XID для клиента, вместо номера порта. Поле XID в строках 1 и 2 равно 0x7aa6.

Имя файла /nfs/bsdi/usr/rstevens/hello.c обрабатывается функцией открытия в ядре клиента по одному элементу имени за раз. Когда функция открытия достигает /nfs/bsdi/usr, она определяет, что это точка монтирования файловой системы NFS.

В строке 1 клиент вызывает процедуру GETATTR, чтобы получить атрибуты директории сервера, которую смонтировал клиент (/usr). Этот RPC запрос содержит 104 байта данных, помимо IP и UDP заголовков. Отклик в строке 2 возвращает OK и содержит 96 байт данных, помимо IP и UDP заголовков. Мы видим на этом рисунке, что минимальное NFS сообщение содержит примерно 100 байт данных.

В строке 3 клиент вызывает процедуру LOOKUP для файла rstevens и получает отклик OK в строке 4. LOOKUP указывает имя файла rstevens и описатель файла, который был сохранен ядром, когда монтировалась удаленная файловая система. Отклик содержит новый описатель файла, который используется в следующем шаге.

В строке 5 клиент осуществляет LOOKUP файла hello.c с использованием описателя файла из строки 4. Он получает другой описатель файла в строке 6. Этот новый описатель файла как раз то, что клиент использует в строках 7 и 9, чтобы обратиться к файлу /nfs/bsdi/usr/rstevens/hello.c. Мы видим, что клиент осуществляет LOOKUP для каждого компонента имени в пути к открываемому файлу.

В строке 7 клиент еще раз исполняет GETATTR, затем следует READ в строке 9. Клиент запрашивает 1024 байта, начиная со смещения равного 0, однако получает данных меньше чем 1024 байта. (После вычитания размеров RPC полей и других значений, возвращенных процедурой READ, в строке 10 возвращаются 38 байт данных. Это как раз размер файла hello.c.)

В этом примере пользовательский процесс ничего не знает об этих NFS запросах и откликах, которые осуществляются ядром. Приложение всего лишь вызывает функцию открытия ядра, которая вызывает обмен 3 запросами и 3 откликами (строки 1-6), а затем вызывает функцию чтение ядра, которая вызывает 2 запроса и 2 отклика (строки 7-10). Для приложения клиента, файл, находящийся на NFS сервере, прозрачен.

Простой пример: создание директории

В качестве еще одного примера сменим рабочую директорию на директорию, которая находится на NFS сервере, а затем создадим новую директорию:

Sun % cd /nfs/bsdi/usr/rstevens меняем рабочую директорию
sun % mkdir Mail создаем директорию

На рисунке 29.8 показан вывод команды tcpdump.

1 0.0 sun.7ad2 > bsdi.nfs: 104 getattr
2 0.004912 (0.0049) bsdi.nfs > sun.7ad2: reply ok 96

3 0.007266 (0.0024) sun.7ad3 > bsdi.nfs: 104 getattr
4 0.010846 (0.0036) bsdi.nfs > sun.7ad3: reply ok 96

5 35.769875 (35.7590) sun.7ad4 > bsdi.nfs: 104 getattr
6 35.773432 (0.0036) bsdi.nfs > sun.7ad4: reply ok 96

7 35.775236 (0.0018) sun.7ad5 > bsdi.nfs: 112 lookup "Mail"
8 35.780914 (0.0057) bsdi.nfs > sun.7ad5: reply ok 28

9 35.782339 (0.0014) sun.7ad6 > bsdi.nfs: 144 mkdir "Mail"
10 35.992354 (0.2100) bsdi.nfs > sun.7ad6: reply ok 128

Рисунок 29.8 Функционирование NFS при смене директории (cd) на NFS директорию, а затем создание директории (mkdir).

При смене директории клиент вызывает процедуру GETATTR дважды (строки 1-4). Когда мы создаем новую директорию, клиент вызывает процедуру GETATTR (строки 5 и 6), затем LOOKUP (строки 7 и 8, чтобы проверить, что такой директории не существует), затем MKDIR, чтобы создать директорию (строки 9 и 10). Отклик OK в строке 8 не означает, что директория существует. Он просто означает, что процедура вернула какое-то значение. tcpdump не интерпретирует значение, возвращаемое NFS процедурами. Команда просто печатает OK и количество байт данных в отклике.

Безразличность

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

Причина такого "безразличного поведения" заключается в том, чтобы упростить восстановление после выхода из строя сервера, после того как он сломался и перезагрузился.

Пример: выход сервера из строя

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

На клиенте sun мы стартовали cat с очень большим файлом в качестве аргумента (/usr/share/lib/termcap на NFS сервере svr4), отсоединили Ethernet кабель в процессе передачи, выключили и перезагрузили сервер и затем снова подсоединили кабель. Клиент был сконфигурирован таким образом, чтобы читать 1024 байта за одно NFS чтение. На рисунке 29.9 показан вывод tcpdump.

Строки 1-10 соответствуют открытию файла клиентом. Эта операция напоминает ту, что показана на рисунке 29.7. В строке 11 мы видим первое чтение (READ) из файла 1024-х байт данных; отклик возвратился в строке 12. Это продолжается до строки 129 (чтение READ по 1024 байта и затем отклик OK).

В строках 130 и 131 мы видим два запроса, которые отработаны по тайм-ауту и повторно переданы в строках 132 и 133. Первый вопрос: мы видим два запроса на чтение, один начинается со смещения 65536, а другой начинается со смещения 73728, почему? Ядро клиента определило, что приложение клиента осуществляет последовательное считывание, и постаралось получить блоки данных заранее. (Большинство Unix ядер осуществляют это чтение вперед (read-ahead).) Ядро клиента также запустило несколько NFS демонов блочного ввода-вывода (I/O) (biod процессы), которые стараются сгенерировать несколько RPC запросов от имени клиента. Один демон считывает 8192 байта, начиная с 65536 (в 1024-байтных цепочках), а другие осуществляют чтение вперед по 8192 байта, начиная с 73728.

Повторные передачи клиента появляются в строках 130-168. В строке 169 мы видим, что сервер перезагрузился, и послал ARP запрос перед тем, как откликнуться на NFS запрос клиента из строки 168. Отклик на строку 168 посылается в строке 171. Запросы клиента на чтение (READ) продолжаются.

1 0.0 sun.7ade > svr4.nfs: 104 getattr
2 0.007653 (0.0077) svr4.nfs > sun.7ade: reply ok 96

3 0.009041 (0.0014) sun.7adf > svr4.nfs: 116 lookup "share"
4 0.017237 (0.0082) svr4.nfs > sun.7adf: reply ok 128

5 0.018518 (0.0013) sun.7ae0 > svr4.nfs: 112 lookup "lib"
6 0.026802 (0.0083) svr4.nfs > sun.7ae0: reply ok 128

7 0.028096 (0.0013) sun.7ae1 > svr4.nfs: 116 lookup "termcap"
8 0.036434 (0.0083) svr4.nfs > sun.7ae1: reply ok 128

9 0.038060 (0.0016) sun.7ae2 > svr4.nfs: 104 getattr
10 0.045821 (0.0078) svr4.nfs > sun.7ae2: reply ok 96

11 0.050984 (0.0052) sun.7ae3 > svr4.nfs: 116 read 1024 bytes @ 0
12 0.084995 (0.0340) svr4.nfs > sun.7ae3: reply ok 1124

Считывание

128 3.430313 (0.0013) sun.7b22 > svr4.nfs: 116 read 1024 bytes @ 64512
129 3.441828 (0.0115) svr4.nfs > sun.7b22: reply ok 1124

130 4.125031 (0.6832) sun.7b23 >
131 4.868593 (0.7436) sun.7b24 >

132 4.993021 (0.1244) sun.7b23 > svr4.nfs: 116 read 1024 bytes @ 65536
133 5.732217 (0.7392) sun.7b24 > svr4.nfs: 116 read 1024 bytes @ 73728

134 6.732084 (0.9999) sun.7b23 > svr4.nfs: 116 read 1024 bytes @ 65536
135 7.472098 (0.7400) sun.7b24 > svr4.nfs: 116 read 1024 bytes @ 73728

136 10.211964 (2.7399) sun.7b23 >
137 10.951960 (0.7400) sun.7b24 >

138 17.171767 (6.2198) sun.7b23 > svr4.nfs: 116 read 1024 bytes @ 65536
139 17.911762 (0.7400) sun.7b24 > svr4.nfs: 116 read 1024 bytes @ 73728

140 31.092136 (13.1804) sun.7b23 > svr4.nfs: 116 read 1024 bytes @ 65536
141 31.831432 (0.7393) sun.7b24 > svr4.nfs: 116 read 1024 bytes @ 73728

142 51.090854 (19.2594) sun.7b23 > svr4.nfs: 116 read 1024 bytes @ 65536
143 51.830939 (0.7401) sun.7b24 > svr4.nfs: 116 read 1024 bytes @ 73728

144 71.090305 (19.2594) sun.7b23 > svr4.nfs: 116 read 1024 bytes @ 65536
145 71.830155 (0.7398) sun.7b24 > svr4.nfs: 116 read 1024 bytes @ 73728

Повторные передачи

167 291.824285 (0.7400) sun.7b24 > svr4.nfs: 116 read 1024 bytes @ 73728
168 311.083676 (19.2594) sun.7b23 > svr4.nfs: 116 read 1024 bytes @ 65536

Сервер перезагрузился

169 311.149476 (0.0658) arp who-has sun tell svr4
170 311.150004 (0.0005) arp reply sun is-at 8:0:20:3:f6:42

171 311.154852 (0.0048) svr4.nfs > sun.7b23: reply ok 1124

172 311.156671 (0.0018) sun.7b25 > svr4.nfs: 116 read 1024 bytes @ 66560
173 311.168926 (0.0123) svr4.nfs > sun.7b25: reply ok 1124
считывание

Рисунок 29.9 Считывание файла клиентом, когда NFS сервер вышел из строя и перезагрузился.

Приложение клиента никогда не узнает, что сервер выходил из строя и перезагружался, за исключением того, что между строками 129 и 171 была 5-минутная пауза, таким образом, выход из строя сервера прозрачен для клиента.

Чтобы оценить продолжительность тайм-аутов при повторных передачах в этом примере, представьте, что существуют два демона клиента, каждый со своими собственными тайм-аутами. Интервалы для первого демона (читающего со смещения 65536) примерно следующие (округлено до двух знаков после запятой): 0,68; 0,87; 1,74; 3,48; 6,96; 13,92; 20,0; 20,0; 20,0 и так далее. Интервалы для второго демона (читающего со смещения 73728) точно такие же. Это означает, что эти NFS клиенты используют тайм-ауты, которые кратны 0,875 секунды с верхним пределом равным 20 секундам. После каждого тайм-аута интервал повторной передачи удваивается: 0,875; 1,75; 3,5; 7,0 и 14,0.

Сколько времени клиент будет осуществлять повторные передачи? Клиент имеет две опции, которые могут повлиять на это. Во-первых, если файловая система сервера смонтирована жестко (hard) , клиент будет повторно передавать вечно, однако если файловая система сервера смонтирована мягко (soft) , клиент прекратит свои попытки после фиксированного количества повторных передач. Также, в случае жесткого монтирования клиент имеет опцию, позволяющую пользователю прервать неудачные повторные передачи или не прерывать. Если при монтировании файловой системы сервера, хост клиента указывает что прервать можно, и если мы не хотим ждать 5 минут, пока сервер перезагрузится после выхода из строя, мы можем ввести символ прерывания, чтобы прекратить работу приложения клиента.

Несколько одинаковых процедур

RPC процедуры могут быть исполнены сервером несколько раз, но при этом все равно возвращают тот же самый результат. Например, процедура чтения NFS. Как мы видели на рисунке 29.9, клиент просто повторно выдает вызов READ до тех пор, пока он получает отклик. В нашем примере причина повторной передачи была в том, что сервер вышел из строя. Если сервер не вышел из строя, а сообщения, содержащие RPC отклики, были потеряны (так как UDP ненадежный протокол), клиент просто повторно передает, и сервер снова осуществляет то же самое чтение (READ). Та же самая часть того же самого файла считывается снова и посылается клиенту.

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

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

Ниже приведен список NFS процедур, которые можно исполнить несколько раз: GETATTR, STATFS, LOOKUP, READ, WRITE, READLINK и READDIR. Процедуры, которые нельзя исполнить несколько раз: CREATE, REMOVE, RENAME, LINK, SYMLINK, MKDIR и RMDIR. SETATTR обычно исполняется несколько раз, если только она не была использована для того, чтобы обрезать файл.

Так как в случае использования UDP всегда могут появиться потерянные отклики, NFS сервера должны иметь способ обработать операции, которые нельзя исполнять несколько раз. Большинство серверов имеют кэш последних откликов, в котором они хранят последние принятые отклики для подобных операций. Каждый раз, когда сервер получает запрос, он, во-первых, просматривает свой кэш, и если найдено совпадение, возвращает предыдущий отклик, вместо того чтобы вызывать NFS процедуру снова. [ Juszczak 1989] описывает детали этих типов кэша.

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

NFS версии 3

В течение 1994 года были выпущены спецификации для версии 3 протокола NFS [ Sun Microsystems 1993]. Реализации, как ожидается, станут доступными в течение 1994 года.

Здесь вкратце описаны основные различия между версиями 2 и 3. Мы будем называть их V2 и V3.

1. Описатели файлов в V2 это массив фиксированного размера - 32 байта. В V3 это массив переменного размера с размером до 64 байт. Массив переменной длины в XDR определяется 4-байтным счетчиком, за которым следуют реальные байты. Это уменьшает размер описателя файла в таких реализациях, как, например, Unix, где требуется всего около 12 байт, однако позволяет не-Unix реализациям обмениваться дополнительной информацией.
2. V2 ограничивает количество байт на процедуры READ или WRITE RPC размером 8192 байта. Это ограничение не действует в V3, что, в свою очередь, означает, что с использованием UDP ограничение будет только в размере IP датаграммы (65535 байт). Это позволяет использовать большие пакеты при чтении и записи в быстрых сетях.
3. Размеры файлов и начальное смещение байтов для процедур READ и WRITE расширены с 32 до 64 бит, что позволяет работать с файлами большего размера.
4. Атрибуты файла возвращаются в каждом вызове, который может повлиять на атрибуты. Это уменьшает количество вызовов GETATTR, требуемых клиентом.
5. Записи (WRITE) могут быть асинхронными, тогда как в V2 они должны были быть синхронными. Это может улучшить производительность процедуры WRITE.
6. Одна процедура была удалена (STATFS) и семь были добавлены: ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1 информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение).

Краткие выводы

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

Одно из наиболее широко используемых приложений RPC это Sun NFS, протокол доступа к разнородным файлам, который широко используется на хостах практически всех размеров. Мы рассмотрели NFS и то, как он использует UDP или TCP. В протоколе NFS версии 2 (NFS Version 2) определено 15 процедур.

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

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

Упражнения

На рисунке 29.7 мы видели, что tcpdump интерпретирует пакеты как NFS запросы и отклики, и при этом печатает XID. Может ли tcpdump сделать это для любых RPC запросов или откликов?

Как Вы думаете, почему в Unix системах программа RPC сервера использует динамически назначаемые порты, а не заранее известные?

RPC клиент вызвал две процедуры сервера. Первая процедура потребовалось на исполнение 5 секунд, а второй - 1 секунда. Клиент имеет тайм-аут равный 4 секундам. Нарисуйте временную диаграмму того, чем обмениваются клиент и сервер. (Представьте, что на прохождение сообщения от клиента к серверу и наоборот время не тратится.)

Что произойдет в примере на рисунке 29.9, если пока NFS сервер был выключен, его Ethernet плата была удалена?

Когда сервер перезагрузился на рисунке 29.9, он обрабатывал запрос, начинающийся на смещении 65536 (строки 168 и 171), а затем обрабатывал следующий запрос, начинающийся со смещения 66560 (строки 172 и 173). Что произойдет с запросом, начинающимся со смещением 73728 (строка 167)?

Когда мы описывали независимые от количества исполнений NFS процедуры, то показали пример отклика REMOVE, который потерялся в сети. Что произойдет в этом случае, если используется TCP вместо UDP?

Если NFS сервер использует динамически назначаемый порт вместо порта 2049, что произойдет с NFS клиентом, когда сервер выйдет из строя и перезагрузится?

Номеров зарезервированных портов (глава 1, раздел "Номера портов") очень-очень мало, их максимум 1023 на хост. Если NFS сервер требует, чтобы его клиенты имели зарезервированные порты (что обычно так и есть), и NFS клиент, использующий TCP, монтирует N файловых систем на N различных серверах, необходимо ли клиенту иметь различные зарезервированные номера портов для каждого соединения?