Сетевые файловые системы типа nfs. Сетевая файловая система UNIX. Повышение производительности NFS

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

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

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

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

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

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

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

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

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

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

Файловая система NFS (Network File System) создана компанией Sun Microsystems. В настоящее время это стандартная сетевая файловая система для ОС семейства UNIX, кроме того, клиенты и серверы NFS реализованы для многих других ОС. Принципы ее организации на сегодня стандартизованы сообществом Интернета, последняя версия NFS v.4 описывается спецификацией RFC ЗОЮ, выпущенной в декабре 2000 года.

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

Одной из целей разработчиков NFS была поддержка неоднородных систем с клиентами и серверами, работающими под управлением различных ОС на различной аппаратной платформе. Этой цели способствует реализация NFS на основе механизма Sun RFC, поддерживающего по умолчанию средства XDR для унифицированного представления аргументов удаленных процедур.

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

Основная идея NFS - позволить произвольной группе пользователей разделять общую файловую систему. Чаще всего все пользователи принадлежат одной локальной сети, но не обязательно. Можно выполнять NFS и на глобальной сети. Каждый NFS-сервер предоставляет один или более своих каталогов для доступа удаленным клиентам. Каталог объявляется достудным со всеми своими подкаталогами. Список каталогов, которые сервер передает, содержится в файле /etc/exports, так что эти каталоги экспортируются сразу автоматически при загрузке сервера. Клиенты получают доступ к экспортируемым каталогам путем монтирования. Многие рабочие станции Sun бездисковые, но и в этом случае можно монтировать удаленную файловую систему к корневому каталогу, при этом вся файловая система целиком располагается на сервере. Выполнение программ почти не зависит от того, где расположен файл: локально или на удаленном диске. Если два или более клиента одновременно смонтировали один и тот же каталог, то они могут связываться путем разделения файла.

В своей работе файловая система NFS использует два протокола.

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

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

Второй NFS-протокол используется для доступа к удаленным файлам и каталогам. Клиенты могут послать запрос серверу для выполнения какого-либо действия над каталогом или операции чтения или записи файла. Кроме того, они могут запросить атрибуты файла, такие как тип, размер, время создания и модификации. NFS поддерживается большая часть системных вызовов UNIX, за исключением open и close. Исключение open и close не случайно. Вместо операции открытия удаленного файла клиент посылает серверу сообщение, содержащее имя файла, с запросом отыскать его (lookup) и вернуть дескриптор файла. В отличие от вызова open вызов lookup не копирует никакой информации во внутренние системные таблицы. Вызов read содержит дескриптор того файла, который нужно читать, смещение в уже читаемом файле и количество байт, которые нужно прочитать. Преимуществом такой схемы является то, что сервер не запоминает ничего об открытых файлах. Таким образом, если сервер откажет, а затем будет восстановлен, информация об открытых файлах не потеряется, потому что она не поддерживается.

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

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

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

Репликация в NFS не поддерживается.

Служба каталогов

Назначение и принципы организации

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

Приведем примеры наиболее важных задач, требующих наличия в сети централизованной базы справочной информации:

• Одной из наиболее часто выполняемых в системе задач, опирающихся на справочную информацию о пользователях, является их аутентификация, на основе которой затем выполняется авторизация доступа. В сети должны каким-то образом централизованно храниться учетные записи пользователей, содержащие имена и пароли.
• Наличия некоторой централизованной базы данных требует поддержка прозрачности доступа ко многим сетевым ресурсам. В такой базе должны храниться имена этих ресурсов и отображения имен на числовые идентификаторы (например, IP-адреса), позволяющие найти этот ресурс в сети. Прозрачность может обеспечиваться при доступе к серверам, томам файловой системы, интерфейсам процедур RPC, программным объектам распределенных приложений и многим другим сетевым ресурсам.
• Электронная почта является еще одним популярным примером службы, для которой желательна единая для сети справочная служба, хранящая данные о почтовых именах пользователей.
• В последнее время в сетях все чаще стали применяться средства управления качеством обслуживания трафика (Quality of Service, QoS), которые также требуют наличия сведений обо всех пользователях и приложениях системы, их требованиях к параметрам качества обслуживания трафика, а также обо всех сетевых устройствах, с помощью которых можно управлять трафиком (маршрутизаторах, коммутаторах, шлюзах и т. п.).
• Организация распределенных приложений может существенно упроститься, если в сети имеется база, хранящая информацию об имеющихся программных модулях-объектах и их расположении на серверах сети. Приложение, которому необходимо выполнить некоторое стандартное действие, обращается с запросом к такой базе и получает адрес программного объекта, имеющего возможность выполнить требуемое действие.
• Система управления сетью должна располагать базой для хранения информации о топологии сети и характеристиках всех сетевых элементов, таких как маршрутизаторы, коммутаторы, серверы и клиентские компьютеры. Наличие полной информации о составе сети и ее связях позволяет системе автоматизированного управления сетью правильно идентифицировать сообщения об аварийных событиях и находить их первопричину. Упорядоченная по подразделениям предприятия информация об имеющемся сетевом оборудовании и установленном программном обеспечении полезна сама по себе, так как помогает администраторам составить достоверную картину состояния сети и разработать планы по ее развитию.

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

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

Для крупной сети неэффективным является также применение большого числа справочных служб узкого назначения: одной для аутентификации, другой - для управления сетью, третей - для разрешения имен компьютеров и т. д. Даже если каждая из таких служб хорошо организована и сочетает централизованный интерфейс с распределенной базой данных, большое число справочных служб приводит к дублированию больших объемов информации и усложняет администрирование и управление сетью. Например, в Windows NT имеется по крайней мере пять различных типов справочных баз данных. Главный справочник домена (NT Domain Directory Service) хранит информацию о пользователях, которая требуется при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных поддерживают разрешение адресов: WINS устанавливает соответствие Netbios-имен IP-адресам, справочник DNS (сервер имен домена) оказывается полезным при подключении NT-сети к Интернету, и наконец, справочник протокола DHCP используется для автоматического назначения IP-адресов компьютерам сети. Очевидно, что такое разнообразие справочных служб усложняет жизнь администратора и приводит к дополнительным ошибкам, когда учетные данные одного и того же пользователя нужно ввести в несколько баз данных. Поэтому в новой версии Windows 2000 большая часть справочной информации о системе может храниться службой Active Directory - единой централизованной справочной службой, использующей распределенную базу данных и интегрированной со службой имен DNS.

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

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

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

Существуют два популярных стандарта для служб каталогов. Во-первых, это стандарт Х.500, разработанный ITU-T (во время разработки стандарта эта организация носила имя CCITT). Этот стандарт определяет функции, организацию справочной службы и протокол доступа к ней. Разработанный в первую очередь для использования вместе с почтовой службой Х.400 стандарт Х.500 позволяет эффективно организовать хранение любой справочной информации и служит хорошей основой для универсальной службы каталогов сети.

Другим стандартом является стандарт LDAP (Light-weight Directory Access Protocol), разработанный сообществом Интернета. Этот стандарт определяет упрощенный протокол доступа к службе каталогов, так как службы, построенные на основе стандарта Х.500, оказались чересчур громоздкими. Протокол LDAP получил широкое распространение и стал стандартом де-факто в качестве протокола доступа клиентов к ресурсам справочной службы.

Существует также несколько практических реализаций служб каталогов для сетевых ОС. Наибольшее распространение получила служба NDS компании Novell, разработанная в 1993 году для сетевой ОС NetWare 4.0, а сегодня реализованная также и для Windows NT/2000. Большой интерес вызывает служба каталогов Active Directory, разработанная компанией Microsoft для Windows 2000. Обе эти службы поддерживают протокол доступа LDAP и могут работать в очень крупных сетях благодаря своей распределенности.

Служба каталогов NDS

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

База данных NDS заменила в свое время справочник bindery предыдущих версий NetWare. Справочник bindery - это «плоская», или одноуровневая база данных, разработанная для поддержки одного сервера. В ней также использовалось понятие «объект» для сетевого ресурса, но трактовка этого термина отличалась от общепринятой. Объекты bindery идентифицировались простыми числовыми значениями и имели определенные атрибуты. Однако для этих объектов не определялись явные взаимоотношения наследования классов объектов, поэтому взаимоотношения между объектами bindery устанавливались администратором произвольно, что часто приводило к нарушению целостности данных.

База данных службы NDS представляет собой многоуровневую базу данных, поддерживающую информацию о ресурсах всех серверов сети. Для совместимости с предыдущими версиями NetWare в службе NDS предусмотрен механизм эмуляции базы bindery.

Служба NDS - это значительный шаг вперед по сравнению с предыдущими версиями за счет:

• распределенности;
• реплицируемости;
• прозрачности;
• глобальности.

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

Рис. 10.8. Разделы базы данных NDS

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

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

Глобальность NDS заключается в том, что после входа вы получаете доступ к ресурсам всей сети, а не только одного сервера, как было в предыдущих версиях. Это достигается за счет процедуры глобального логического входа (global login). Вместо входа в отдельный сервер пользователь NDS входит в сеть, после чего он получает доступ к разрешенным для него ресурсам сети. Информация, предоставляемая во время логического входа, используется для идентификации пользователя. Позже, при попытке пользователя получить доступ к ресурсам, таким как серверы, тома или принтеры, фоновый процесс идентификации проверяет, имеет ли пользователь право на данный ресурс.

Глава 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 различных серверах, необходимо ли клиенту иметь различные зарезервированные номера портов для каждого соединения?

Network file system (NFS) - протокол сетевого доступа к файловым системам, позволяет подключать удалённые файловые системы.
Первоначально разработан Sun Microsystems в 1984 г. Основой является Sun RPC: вызов удаленной процедуры (Remote Procedure Call). NFS независим от типов файловых систем сервера и клиента. Существует множество реализаций NFS-серверов и клиентов для различных ОС. В настоящее время используется версия NFS v.4, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).
NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера. В отличие от FTP, протокол NFS осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство его в том, что он делает этот доступ прозрачным. Благодаря этому любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без изменений самой программы.
NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC-запросов на сервер. Это может быть реализовано с использованием обычных пользовательских процессов - а именно, NFS клиент может быть пользовательским процессом, который осуществляет конкретные RPC вызовы на сервер, который так же может быть пользовательским процессом.

Версии
NFSv1 была только для внутреннего пользования в экспериментальных целях. Детали реализации определены в RFC 1094.
NFSv2 (RFC 1094, март 1989 года) первоначально полностью работала по протоколу UDP.
NFSv3 (RFC 1813, июнь 1995 года). Описатели файлов в версии 2 - это массив фиксированного размера - 32 байта. В версии 3 - это массив переменного размера с размером до 64 байт. Массив переменной длины в XDR определяется 4-байтным счётчиком, за которым следуют реальные байты. Это уменьшает размер описателя файла в таких реализациях, как, например, UNIX, где требуется всего около 12 байт, однако позволяет не-Unix реализациям обмениваться дополнительной информацией.
Версия 2 ограничивает количество байт на процедуры READ или WRITE RPC размером 8192 байта. Это ограничение не действует в версии 3, что, в свою очередь, означает, что с использованием UDP ограничение будет только в размере IP датаграммы (65535 байт). Это позволяет использовать большие пакеты при чтении и записи в быстрых сетях.
Размеры файлов и начальное смещение в байтах для процедур READ и WRITE стали использовать 64-битную адресацию вместо 32-битной, что позволяет работать с файлами большего размера.
Атрибуты файла возвращаются в каждом вызове, который может повлиять на атрибуты.
Записи (WRITE) могут быть асинхронными, тогда как в версии 2 они должны были быть синхронными.
Одна процедура была удалена (STATFS) и семь были добавлены: ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1 информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение).
На момент введения версии 3, разработчики стали больше использовать TCP как транспортный протокол. Хотя некоторые разработчики уже Использовали протокол TCP для NFSv2, Sun Microsystems добавили поддержку TCP в NFS версии 3. Это сделало использование NFS через Интернет более осуществимым.
NFSv4 (RFC 3010, декабрь 2000 г., RFC 3530, пересмотренная в апреле 2003), под влиянием AFS и CIFS, включила в себя улучшение производительности, высокую безопасность, и предстала полноценным протоколом. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF), после того, как Sun Microsystems передала развитие протоколов NFS. NFS версии v4.1 была одобрена IESG в январе 2010 года, и получила номер RFC 5661. Важным нововведением версии 4.1 является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые "облачные" ("cloud") хранилища и информационные системы.

Структура NFS
Структура NFS включает три компонента разного уровня:
Прикладной уровень (собственно NFS) - это вызовы удаленных процедур (rpc), которые и выполняют необходимые операции с файлами и каталогами на стороне сервера.
Функции уровня представления выполняет протокол XDR (eXternal Data Representation), который является межплатформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую, форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
Сервис RPC (Remote Procedure Call), обеспечивающий запрос удаленных процедур клиентом и их выполнение на сервере, представляет функции сеансового уровня.Подключение сетевых ресурсов
Процедура подключения сетевого ресурса средствами NFS называется "экспортированием". Клиент может запросить у сервера список представляемых им экспортируемых ресурсов. Сам сервер NFS не занимается широковещательной рассылкой списка своих экспортируемых ресурсов.
В зависимости от заданных опций, экспортируемый ресурс может быть смонтирован (присоединён) "только для чтения", можно определить список хостов, которым разрешено монтирование, указать использование защищенного RPC (secureRPC) и пр. Одна из опций определяет способ монтирования: "жесткое" (hard) или "мягкое" (soft).
При "жестком" монтировании клиент будет пытаться смонтировать файловую систему во что бы то ни стало. Если сервер не работает, это приведет к тому, что весь сервис NFS как бы зависнет: процессы, обращающиеся к файловой системе, перейдут в состояние ожидания окончания выполнения запросов RPC. С точки зрения пользовательских процессов файловая система будет выглядеть как очень медленный локальный диск. При возврате сервера в рабочее состояние сервис NFS продолжит функционирование.
При "мягком" монтировании клиент NFS сделает несколько попыток подключиться к серверу. Если сервер не откликается, то система выдает сообщение об ошибке и прекращает попытки произвести монтирование. С точки зрения логики файловых операций при отказе сервера "мягкое" монтирование эмулирует сбой локального диска.
Выбор режима зависит от ситуации. Если данные на клиенте и сервере должны быть синхронизированы при временном отказе сервиса, то "жесткое" монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах "только для чтения", режим "мягкого" монтирования представляется более удобным.

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

Стандарты
RFC 1094 NFS: Network File System Protocol Specification] (March 1989)
RFC 1813 NFS Version 3 Protocol Specification] (June 1995)
RFC 2224 NFS URL Scheme
RFC 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols
RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5
RFC 2624 NFS Version 4 Design Considerations
RFC 3010 NFS version 4 Protocol
RFC 3530 Network File System (NFS) version 4 Protocol
RFC 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol

Используемые источники
1. ru.wikipedia.org
2. ru.science.wikia.com
3. phone16.ru
4. 4stud.info
5. yandex.ru
6. gogle.com

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

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

Лучшее понимание как самого протокола, так и деталей его реализации позволит легче справиться с практическими задачами. Данная статья посвящена NFS и состоит из двух логических частей: вначале описывается сам протокол и цели, поставленные при его разработке, а затем реализации NFS в Solaris и UNIX.

С ЧЕГО ВСЕ НАЧИНАЛОСЬ...

Протокол NFS разработан компанией Sun Microsystems и в 1989 г. появился в Internet в виде документа RFC 1094 под следующим названием: «Спецификация протокола сетевой файловой системы» (Network File System Protocol Specification, NFS). Интересно отметить, что и стратегия компании Novell в то время была направлена на дальнейшее усовершенствование файловых служб. До недавнего времени, пока движение за открытые коды еще не набрало силу, Sun не стремилась раскрывать секреты своих сетевых решений, однако даже тогда в компании понимали всю важность обеспечения взаимодействия с другими системами.

В документе RFC 1094 содержались две первоначальные спецификации. К моменту его публикации Sun разрабатывала уже следующую, третью версию спецификации, которая изложена в RFC 1813 «Спецификация протокола NFS, версия 3» (NFS Version 3 Protocol Specification). Версия 4 данного протокола определена в RFC 3010 «Спецификация протокола NFS, версия 4» (NFS Version 4 Protocol).

NFS широко используется на всех типах узлов UNIX, в сетях Microsoft и Novell, а также в таких решениях компании IBM, как AS400 и OS/390. Будучи неизвестной за пределами сетевого «королевства», NFS, пожалуй, самая распространенная платформенно-независимая сетевая файловая система.

ПРАРОДИТЕЛЕМ БЫЛ UNIX

Хотя NFS - платформенно-независимая система, ее прародителем является UNIX. Другими словами, иерархичность архитектуры и методы доступа к файлам, включая структуру файловой системы, способы идентификации пользователей и групп и приемы работы с файлами - все это очень напоминает файловую систему UNIX. Например, файловая система NFS, будучи по структуре идентичной файловой системе UNIX, монтируется непосредственно в ней. При работе с NFS на других операционных системах идентификационные параметры пользователей и права доступа к файлам подвергаются преобразованию (mapping).

NFS

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

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

В качестве примера предположим, что некий клиент смонтировал каталог usr2 в локальной корневой файловой системе:

/root/usr2/ -> remote:/root/usr/

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

Cd /root/usr2/

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

Получив запрос, сервер NFS проверит наличие у данного пользователя права на выполнение запрашиваемого действия и в случае положительного ответа осуществит его.

ПОЗНАКОМИМСЯ ПОБЛИЖЕ

С точки зрения клиента, процесс локального монтирования удаленной файловой системы средствами NFS состоит из нескольких шагов. Как уже упоминалось, клиент NFS подаст вызов удаленной процедуры для выполнения ее на сервере. Заметим, что в UNIX клиент представляет собой одну программу (команда mount), в то время как сервер на самом деле реализован в виде нескольких программ со следующим минимальным набором: служба преобразования портов (port mapper), демон монтирования (mount daemon) и сервер NFS.

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

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

Служба преобразования портов сервера откликается на запросы в соответствии с поддерживаемым протоколом и портом, на котором работает демон монтирования. Клиентская программа mount вначале устанавливает соединение с демоном монтирования сервера, а затем передает ему с помощью RPC команду mount. Если данная процедура выполнена успешно, то клиентское приложение соединяется с сервером NFS (порт 2049) и, используя одну из 20 удаленных процедур, которые определены в RFC 1813 и приводятся нами в Таблице 1, получает доступ к удаленной файловой системе.

Смысл большинства команд интуитивно понятен и не вызывает каких-либо затруднений у системных администраторов. Приведенный ниже листинг, полученный с помощью tcdump, иллюстрирует команду чтения, создаваемую командой UNIX cat для прочтения файла с именем test-file:

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013650 eth0 192.168.1.254.3492875163: reply ok 108 read (DF) 10:30:16.013650 eth0 192.168.1.254.3492875163: reply ok 108 read (DF)

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

ДОСТУП В NFS

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

Первый способ основывается на встроенной в UNIX системе прав доступа к файлам для индивидуального пользователя или группы. Для упрощения обслуживания идентификация пользователей и групп должна быть единообразной для всех клиентов и серверов NFS. Защиту следует тщательно продумать: в NFS можно по неосторожности предоставить такой доступ к файлам, который не планировался при их создании.

Доступ на уровне разделяемых ресурсов позволяет ограничивать права, разрешив только определенные действия, независимо от принадлежности файла или привилегий UNIX. Например, работу с файловой системой NFS можно ограничить только чтением. Большинство реализаций NFS позволяет дополнительно ограничить доступ на уровне разделяемых ресурсов конкретными пользователями и/или группами. Например, группе «Отдел кадров» разрешается просмотр информации и не более того.

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

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

NFS В СТИЛЕ «ПИНГВИН»

Относящийся к Linux излагаемый материал основывается на системе Red Hat 6.2 с ядром версии 2.4.9, которая поставляется с пакетом nfs-utils версии 0.1.6. Существуют и более новые версии: на момент написания этой статьи самое последнее обновление пакета nfs-utils имело номер 0.3.1. Его можно загрузить по адресу: .

Пакет nfs-utils содержит следующие исполняемые файлы: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount и statd.

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

Поддержку NFS следует инициировать во время компиляции ядра. Если необходимо, в ядро нужно добавить и возможность работы с NFS версии 3.

Для дистрибутивов, поддерживающих linuxconf, легко сконфигурировать службы NFS как для клиентов, так и для серверов. Однако быстрый способ установки NFS с помощью linuxconf не дает информации о том, какие файлы были созданы или отредактированы, что очень важно знать администратору для понимания ситуации в случае сбоя системы. Архитектура NFS в Linux имеет слабую связь с версией BSD, поэтому необходимые файлы и программы поддержки легко найти администраторам, работающим с BSD, Sun OS 2.5 или более ранними версиями NFS.

Файл /etc/exports, как и в более ранних версиях BSD, определяет файловые системы, к которым разрешен доступ клиентам NFS. Кроме того, он содержит ряд дополнительных возможностей, относящихся к вопросам управления и безопасности, предоставляя администратору средство для тонкой настройки. Это текстовый файл, состоящий из записей, пустых или закомментированных строк (комментарии начинаются с символа #).

Предположим, что мы хотим предоставить клиентам доступ только для чтения к каталогу /home на узле Lefty. Этому в /etc/exports будет соответствовать следующая запись:

/home (ro)

Здесь нам необходимо сообщить системе, какие каталоги мы собираемся сделать доступными с помощью демона монтирования rpc.mountd:

# exportfs -r exportfs: В /home (ro) не указано имя узла, введите *(ro) чтобы избежать предупреждения #

При запуске команда exportfs выводит предупреждение о том, что /etc/ exports не ограничивает доступ к отдельному узлу, и создает соответствующую запись в /var/lib/nfs/etab из /etc/exports, сообщающую, какие ресурсы можно просмотреть с помощью cat:

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_ squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)

Другие параметры, перечисленные в виде списка в etab, включают значения по умолчанию, используемые NFS. Детали будут описаны ниже. Чтобы предоставить доступ к каталогу /home, необходимо запустить соответствующие службы NFS:

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

В любой момент после запуска демона монтирования (rpc.mountd) cправиться об отдельных файлах, доступных для вывода, можно, просмотрев содержимое файла /proc/fs/nfs/exports:

# cat /proc/fs/nfs/exports # Version 1.0 # Path Client(Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

То же самое можно просмотреть и с помощью команды showmount с параметром -e:

# showmount -e Export list for lefty: /home (everyone) #

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

# showmount -a All mount points on lefty: 192.168.1.252:/home #

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

# rpc.mountd -N 1 -N 2

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

«ЗАПЛЫВ С ПИНГВИНАМИ»

Доступ к сконфигурированной выше Lefty, экспортируемой файловой системе NFS на базе Linux, зависит от клиентской операционной системы. Стиль установок для большинства операционных систем семейства UNIX совпадает со стилем либо исходных систем Sun OS и BSD, либо более новой Solaris. Так как данная статья посвящена обеим системам, Linux и Solaris, давайте рассмотрим клиентскую конфигурацию Solaris 2.6 с точки зрения установления соединения с Linux-версией NFS, описанной нами выше.

Благодаря свойствам, унаследованным Solaris 2.6, ее легко сконфигурировать для работы в качестве клиента NFS. Для этого требуется лишь одна команда:

# mount -F nfs 192.168.1.254:/home /tmp/tmp2

Предположим, что предыдущая команда mount выполнена успешно, тогда команда mount без параметров выведет следующее:

# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Mon Sep 3 23:19:25 2001

Давайте проанализируем вывод tcpdump, полученный на узле Lefty, после того, как пользователь ввел команду ls /tmp/tmp2 на узле Sunny:

# tcpdump host lefty and host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:43.490678 lefty.mcwrite.n.nfs > sunny.2191983953: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: 132 access fh Unknown/10001 (DF) 06:07:43.491463 lefty.mcwrite.n.nfs > sunny.2191983954: reply ok 120 access c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus fh 0,1/16777984 1048 bytes @ 0x000000000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: reply ok 1000 readdirplus (DF)

Мы видим, что узел Sunny запрашивает для ls описатель файла (fh), на что узел Lefty в ответ посылает OK и возвращает структуру каталога. Затем Sunny проверяет разрешение на право доступа к содержимому каталога (132 access fh) и получает ответ с разрешением от Lefty. После этого узел Sunny, используя процедуру readdirplus, считывает полное содержимое каталога. Вызовы удаленных процедур описаны в документе RFC 1813 и приведены нами в начале данной статьи.

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

Проще всего устранить проблемы на сервере с узла, на котором работает сервер. Однако, когда администрированием сервера занимается вместо вас кто-то другой, это не всегда возможно. Быстрый способ убедиться, что соответствующие службы сервера правильно сконфигурированы, - использовать команду rpcinfo с параметром -p. С узла Solaris Sunny можно определить, какие процессы RPC зарегистрированы на узле Linux:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1 tcp 694 status 100005 3 udp 1024 mountd /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Заметим, что здесь же приводится информация о версиях, что достаточно полезно, когда для работы системы требуется поддержка различных протоколов NFS. Если какая-либо служба не запущена на сервере, то такая ситуация должна быть исправлена. В случае неудачного монтирования приводимая ниже команда rpcinfo -p позволит выяснить, что служба mountd на сервере не работает:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

Команда rpcinfo очень полезна для выяснения, активен ли тот или иной удаленный процесс. Параметр -p - самый важный из ключей. Для ознакомления со всеми возможностями rpcinfo обратитесь к справочной странице man.

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

Наконец, еще одним достаточно полезным инструментом определения причин сбоев системы является tcpdump:

# tcpdump host lefty and host sunny -s512 tcpdump: listening on eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2191984022 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Unknown/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023: reply ok 120 create ERROR: Permission denied (DF)

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

Если файловая система смонтирована, то большинство типичных ошибок связано с обычными правами доступа UNIX. Использование uid или NIS+ в Sun помогает избежать глобального установления прав доступа на все файловые системы. Некоторые администраторы практикуют «открытые» каталоги, когда права доступа на их чтение даются «всему миру». Однако этого следует избегать по причинам безопасности. Даже отбросив в сторону проблемы защиты, все равно придется признать такой подход порочной практикой, поскольку пользователи редко создают данные с намерением сделать их доступными для чтения всем подряд.

Обращения привилегированного пользователя (root) к смонтированным файловым системам NFS трактуются по-особому. Чтобы избежать предоставления привилегированному пользователю неограниченного доступа, запросы от него трактуются так, как будто бы они поступают от пользователя nobody («никто»). Этот действенный механизм ограничивает доступ привилегированного пользователя глобально доступными для чтения и разрешенными для записи файлами.

СЕРВЕР NFS, ВЕРСИЯ SOLARIS

Конфигурирование Solaris для работы в качестве сервера NFS так же просто, как и в случае с Linux. Однако команды и местоположение файлов несколько отличаются. При начальной загрузке Solaris по достижении уровня загрузки 3 (run level 3) автоматически запускаются службы NFS и экспортируются все файловые системы. Для запуска этих процессов вручную введите команду:

#/usr/lib/nfs/mountd

Для запуска демона монтирования и сервера NFS введите:

#/usr/lib/nfs/nfsd

Начиная с версии 2.6 в Solaris для указания экспортируемых файловых систем больше не используется файл экспорта. Теперь файлы экспортируются с помощью команды share. Предположим, мы хотим позволить удаленным узлам смонтировать /export/home. Введем для этого следующую команду:

Share -F nfs /export/home

Мероприятия по обеспечению безопасности

БЕЗОПАСНОСТЬ В LINUX

Некоторые системные службы NFS на основе Linux имеют дополнительный механизм ограничения доступа посредством управляющих списков или таблиц. На внутреннем уровне этот механизм реализован с помощью библиотеки tcp_wrapper, которая для формирования списков контроля доступа использует два файла: /etc/hosts.allow и /etc/hosts/deny. Исчерпывающий обзор правил работы с tcp_wrapper выходит за рамки данной статьи, основной же принцип состоит в следующем: сопоставление вначале производится с etc/hosts.allow, а затем с /etc/hosts. deny. Если правило не найдено, то запрашиваемая системная служба не представляется. Чтобы обойти последнее требование и обеспечить очень высокий уровень безопасности, в конец /etc/hosts.deny можно добавить следующую запись:

ALL: All

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

Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0 statd:192.168.1.0/255.255.255.0

При этом разрешается определенный вид доступа к узлам до того, как будет предоставлен доступ на уровне приложений. В Linux доступом на уровне приложений управляет файл /etc/exports. Он состоит из записей в следующем формате:

Экспортируемый каталог {пробел} узел|сеть(опции)

«Экспортируемый каталог» - это каталог, обработка запроса к которому разрешена демону nfsd. «Узел|сеть» - это узел или сеть, имеющие доступ к экспортируемой файловой системе, а «опции» определяют те ограничения, какие демон nfsd налагает на использование данного разделяемого ресурса, - доступ только для чтения или преобразование идентификатора пользователя (user id mapping).

В следующем примере всему домену mcwrite.net предоставлен доступ в режиме только для чтения к /home/mcwrite.net:

/home/mcwrite.net *.mcwrite.net(ro)

Другие примеры можно найти на справочной странице exports man.

БЕЗОПАСНОСТЬ NFS В SOLARIS

В Solaris возможности по предоставлению доступа к NFS аналогичны Linux, однако в этом случае ограничения задаются с помощью определенных параметров в команде share с ключом -o. Следующий пример показывает, как разрешить монтирование в режиме только для чтения /export/mcwrite.net на любом узле домена mcwrite.net:

#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

Справочная страница man для share_nfs подробно описывает предоставление доступа с помощью управляющих списков в Solaris.

Ресурсы Internet

В NFS и RPC не обошлось без «дыр». Вообще говоря, NFS не следует использовать при работе в Internet. Нельзя делать «дыры» в брандмауэрах, предоставляя какой бы то ни было доступ посредством NFS. Необходимо тщательно следить за всеми появляющимися заплатами для RPC и NFS, в чем могут помочь многочисленные источники информации по вопросам безопасности. Два наиболее популярных источника - Bugtraq и CERT:

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