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

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

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

15.1.1 Назначение NFS

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

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

Рис. 15.1. Сервер NFS в локальной сети

15.1.2 Соотношения между NFS, RPC и XDR

NFS работает поверх вызовов удаленных процедур (Remote Procedure Call — RPC). RPC был разработан в начале использования приложений клиент/сервер. В этой главе мы познакомимся со службами NFS и архитектурой открытых сетевых вычислений (Open Network Computing — ONC), на основе которой реализуется RPC.

Стандарт внешнего представления данных (eXternal Data Representation — XDR) является важной частью архитектуры RPC. XDR включает язык описания типов данных и методы их кодирования в стандартный формат. Это позволяет производить обмен данными между компьютерами различных типов, например между хостами Unix, PC, Macintosh, системами VAX VMS компании Digital Equipment Corporation и большими ЭВМ компании IBM.

15.1.3 RPC как стандарт Интернета

Компания Sun Microsystems опубликовала RFC с описанием RPC в 1988 г., a NFS — в 1989 г. Однако Sun контролировала эти протоколы вплоть до 1995 г., пока не появились новые версии. С этого момента ответственность за RFC архитектуры ONC перешла к комитету IETF, а сама архитектура была принята в качестве стандарта для процессов Интернета. Sun взаимодействовала с консорциумом X/Open при разработке новой версии NFS.

15.1.4 Реализации NFS и RPC

NFS и RPC были реализованы многими разработчиками систем Unix, а также перенесены во многие лицензированные операционные системы. Например, IBM VM, IBM MVS и DEC VAX VMS могут работать как файловые серверы NFS.

Некоторые разработчики объединили программное обеспечение клиента и сервера NFS с собственными продуктами TCP/IP, в то время как другие предоставляли NFS за дополнительную плату. Во многих продуктах NFS содержится программная библиотека для RPC.

Множество продуктов TCP/IP для Windows обеспечивает работу системы Windows в качестве клиента NFS, а некоторые реализации — и как серверы NFS. Последние версии NetWare компании Novell поддерживают NFS вместе с собственными службами файлов и печати. Любой клиент может обращаться к серверу по любому из этих протоколов. В частности, поддерживаются клиенты DOS, Macintosh и Unix.

Уже разработано много программ клиент/сервер. А будет написано их еще больше. Предоставление каждому приложению общеизвестных портов ограничено — как же клиенты смогут распознавать все большее количество служб?

15.6.1 Назначение Portmapper

Архитектура RPC предоставляет метод для динамического обнаружения присвоенного службе порта. На каждом серверном хосте специальная программа RPC работает как хранилище данных о других программах RPC этого сервера. Такая программа называется portmapper (отображение портов) либо в более новых версиях операционных систем — rpcbind (связывание в RPC). В этой главе мы будем именовать такую программу portmapper, подразумевая, что rpcbind обеспечивает аналогичные функции.

Portmapper поддерживает следующие элементы:

■ Локальные активные программы RPC

■ Номера версий этих программ

■ Транспортный протокол или протокол обмена

■ Порты, через которые работают программы

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

Рис. 15.4. Поиск порта службы через portmapper

Portmapper (или rpcbind) отслеживает запросы к общеизвестному порту 111. Когда клиенту требуется доступ к службе, он посылает запрос в сообщении RPC на порт 111 (т.е. к portmapper). В запросе указывается номер программы требуемой службы, ее версия и протокол пересылки (UDP или TCP). В ответе от portmapper клиенту возвращается текущий номер порта требуемой службы.

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

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

Дело в том, что клиент вставляет свой запрос в специальный вызов косвенного запроса (indirect request) к portmapper и посылает такой запрос на порт 111. Portmapper пересылает полученный запрос к службе и затем возвращает ответ службы клиенту. Номер порта службы включается в ответ, чтобы последующие запросы клиента могли быть посланы непосредственно к службе, а не к portmapper.

15.6.2 Процедуры portmapper

Выполняемые программой portmapper процедуры перечислены в таблице 15.2.

Таблица 15.2 Процедуры portmapper

15.6.3 Просмотр служб RPC через portmapper

Команда rpcinfo из Unix выводит полезную информацию о программах RPC, посылая запрос RPC к portmapper. Аналогичную программу обеспечивают и другие операционные системы с поддержкой клиентов RPC.

Приведенный ниже результат работы rpcinfo -p содержит сведения о программах RPC, работающих на хосте bulldog.cs.yale.edu (т.е. был послан запрос к процедуре PMAPPROC_DUMP программы portmapper).

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

> rpcinfo -p bulldog.cs.yale.edu

Program vers proto port

100000    2   tcp   111 portmapper

100000    2   udp   111 portmapper

100029    1   udp   657 keyserv

100005    1   udp   746 mountd

100005    2   udp   746 mountd

100005    1   tcp   749 mountd

100003    2   udp  2049 nfs

100005    2   tcp   749 mountd

100026    1   udp   761 bootparam

100024    1   udp   764 status

100024    1   tcp   766 status

100021    1   tcp   767 nlockmgr

100021    1   udp  1033 nlockmgr

100021    3   tcp   771 nlockmgr

100021    3   udp  1034 nlockmgr

100020    1   udp  1035 llockmqr

100020    1   tcp   776 llockmgr

100021    2   tcp   779 nlockmgr

100021    2   udp  1036 nlockmgr

100011    1   udp  1070 rquotad

100001    2   udp  1111 rstatd

100001    3   udp  1111 rstatd

100001    4   udp  1111 rstatd

100002    1   udp  1124 rusersd

100002    2   udp  1124 rusersd

100012    1   udp  1127 sprayd

100008    1   udp  1132 walld

Отметим интересный момент: для определения состояния приложения RPC использовалось другое приложение Remote Procedure Call.

Команда rpcinfo -b выполняет широковещательную рассылку в сети, запрашивая все работающие серверы о выполняемых ими программах и версиях этих программ. В приведенном ниже примере запрашиваются сведения о версии 1 программы spray под номером 100012.

> rpcinfo -b 100012 1

128.36.12.1 casper.na.cs.yale.edu 128.36.12.28 tesla.math.yale.edu 128.36.12.6 bink.na.cs.yale.edu

Каждая программа RPC имеет пустую процедуру с номером 0, возвращающую только ответ "Я активна". Нижеприведенная команда rpcinfo -u посылает сообщение пустой процедуре программы spray хоста bulldog.cs.yale.edu:

> rpcinfo -u bulldog.cs.yale.edu 100012

program 100012 version 1 ready and waiting

В последних версиях RPC программа portmapper заменена на rpcbind. Исходная программа portmapper связывалась с UDP или TCP. Rpcbind независима от используемого транспортного протокола. Эта программа возвращает строку ASCII, содержащую адресную информацию, которая не зависит от используемого транспорта и называется форматом универсального адреса (universal address format).

15.7.1 Назначение rpcbind

Программа rpcbind основана на тех же принципах, что и portmapper. При инициализации программы RPC ей выделяется один или несколько динамически назначенных адресов для транспорта. Программа регистрирует полученные адреса в rpcbind, через которую они становятся известными клиентам.

Запрос клиента содержит номер программы и номер версии. Но в ответе rpcbind указывается универсальный адрес, который может предоставлять специальные сведения для NetWare SPX/IPX, SNA, DECnet или AppleTalk, а не для TCP или UDP. Тип предоставленного в ответе транспортного адреса зависит от используемого для запроса транспортного протокола.

Как и к portmapper, к rpcbind обращаются по общеизвестному порту 111 через UDP или TCP. Для других коммуникационных протоколов должен использоваться другой, заранее определенный локальный доступ.

Подобно portmapper, rpcbind поддерживает службу широковещательных рассылок RPC. Рассылки направляются на общеизвестную точку доступа к транспорту, определенную для службы rpcbind, например порт 111 для UDP или TCP. Каждая программа rpcbind, которая отслеживает широковещательные рассылки, может от имени клиента вызвать нужную ей локальную сервисную программу, получить ответ и переслать его клиенту. Версия 4 протокола RPC позволяет клиентам получать через rpcbind такой же вид косвенного обслуживания при многоадресной рассылке, как и при широковещательной.

15.7.2 Процедуры rpcbind

Процедуры программы rpcbind версии 4 представлены в таблице 15.3.

Таблица 15.3 Процедуры rpcbind

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

В сообщении запроса аутентификационные сведения RPC пересылаются в двух полях:

■ Поле мандата (credentials) — содержит идентификационную информацию.

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

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

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

15.9.1 Нулевая аутентификация

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

15.9.2 Аутентификация систем

Аутентификация систем моделирует аналогичную информацию операционной системы Unix. Мандат системы содержит:

Поле проверочных сведений аутентификации — нулевое.

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

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

15.9.3 Аутентификация DCS

Стандарт шифрования данных (Data Encryption Standard — DES) использует симметричный алгоритм шифрования. DES — это федеральный стандарт обработки информации (Federal Information Processing Standard — FIPS), который был определен Национальным бюро стандартов США, в настоящее время называемым Национальным институтом стандартов и технологий (National Institute of Standards and Technology — NIST).

Аутентификация DES для RPC основана на сочетании асимметричных общедоступных и личных ключей с симметричным шифрованием DES:

■ Имя пользователя связано с общедоступным ключом.

■ Сервер шифрует ключ сеанса DES с помощью общедоступного ключа и посылает его клиентскому процессу пользователя.

■ Ключ сеанса DES используется для шифрования аутентификационной информации клиента и сервера.

15.9.4 Аутентификация в Kerberos

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

■ использования секретных ключей (клиента и сервера), зарегистрированных на сервере безопасности Kerberos и распространяемых как ключи сеансов DES для клиентов и серверов

■ применения ключа сеанса DES для шифрования аутентификационной информации клиента и сервера

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

Все параметры в сообщениях Sun RPC определены и кодируются по протоколу представления внешних данных (external Data Representation — XDR). Этот протокол специфицирует:

■ Язык описания данных XDR, определяющий тип данных в запросах и ответах

■ Правила кодирования XDR по форматированию данных при пересылке

Большая часть библиотеки программирования RPC состоит из запросов, которые преобразуют типы данных в/из сетевого формата XDR.

15.11.1 Язык описания данных XDR

Описания данных XDR похожи на описания данных в языках программирования и не являются слишком сложными. Существует несколько основных типов данных XDR: целые числа со знаком и без знака, последовательные (или порядковые) целые числа, строки ASCII, логические значения и числа с плавающей точкой. Для пересылки строк октетов общего вида применяется тип данных opaque (непрозрачный, без преобразования). В полях с этим типом данных может пересылаться зашифрованная информация. К более сложным типам данных относятся массивы, структуры и объединенные типы данных (union datatypes), построенные на основе базовых типов.

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

enum msg_type {

 CALL = 0,

 REPLY = 1

};

В данном поле может появляться только одно из целых чисел: 0 или 1. Ввод любого другого целого числа приведет к ошибке.

Структура определения тела сообщения запроса RPC:

struct call_body {

 unsigned int rpcvers; /* Версия должна быть равна 2 */

 unsigned int prog;    /* Это номер программы        */

 unsigned int vers;    /* Это версия программы       */

 unsigned int proc;    /* Определение процедуры      */

 opaque_auth cred;     /* Мандат, например userid    */

 opaque_auth verf;     /* Verifier для мандата       */

 /* Здесь может быть зашифрованное поле */

 /* начало описания специфичных для процедуры параметров */

15.11.2 Кодирование в XDR

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

00 00 00 05

Строки ASCII кодируются как 4-октетное целое число, содержащее длину строки со следующими далее символами ASCII, дополненными до полей, кратных 4 байт. Например, строка README будет выглядеть как:

(длина строки = 6) R  E  A  D  M  E (заполнитель)

00 00 00 06       52 45 41 44 4D 45 00 00

Альтернативный метод определения и кодирования специфицирует стандарт описания данных в первой абстрактной синтаксической нотации OSI (OSI Abstract Syntax Notation 1 — ASN.1) и стандарт базовых правил кодирования (Basic Encoding Rules — BER,). ASN.1 и BER используются некоторыми приложениями TCP/IP. Наиболее значимым из них является Simple Network Management Protocol (SNMP).

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

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

Файлы и каталоги Unix идентифицируются путем, состоящим из имен, проходимых при перемещении по дереву каталогов от корня к данному файлу или каталогу. Каждое имя отделяется символом косой черты, например /etc/hosts или /usr/john/abc.

Синтаксис записи путей в других операционных системах может быть не таким, как в Unix. Например, в DOS имя файла записывается как E:\WP\LETTER.DOC. В NFS предполагается, что каждый файл полностью определяется своим путем.

15.14.1 Источник формирования модели NFS

Отдельные части системы каталогов Unix могут размещаться на различных жестких дисках. Например, файлы и каталоги /etc могут находиться на одном физическом диске, а каталог /var и его подкаталоги — на другом. Команда mount операционной системы Unix служит для соединения отдельных частей каталогов в единое дерево. Типичная команда mount выглядит так:

mount /dev/ху0b /var

В данном случае файлы физического устройства xy0b будут идентифицироваться как файлы каталога /var.

При разработке NFS возможности команды mount были расширены на удаленные поддеревья, которые стали также подключаться к дереву каталогов компьютера. Например, если сетевой администратор хочет использовать место на компьютере bighost для резервного копирования файлов хоста tiger, то он создает на компьютере bighost каталог /users. С системы tiger администратор вводит команду:

mount -t nfs bighost:/users /usr

Каталог сервера /users и все его подкаталоги логически подключаются к дереву каталогов системы tiger в точке /usr. Для конечных пользователей tiger дерево каталогов расширяется (см. рис. 15.9). Однако файлы в /usr/john/abc реально будут находиться в каталоге /users/john/abc сервера bighost.

После монтирования, когда локальный пользователь будет запрашивать файлы из каталога /usr, операционная система будет знать, что эти файлы реально размещаются в каталоге /users компьютера bighost.

Дерево каталогов Unix имеет одну корневую точку. DOS может иметь множество деревьев (не назвать ли их лесом?), начинающихся от устройств A:, B:, С: и т.д. При монтировании удаленного каталога в DOS он становиться новым устройством локальной системы (например, E:).

Рис. 15.9. Монтирование удаленного каталога

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

Команда mount служит для подключения (монтирования) удаленного каталога к локальной файловой системе. Эта команда реализуется программой RPC с номером 100005, а используемый порт предоставляется программой portmapper. Монтирование работает поверх UDP и TCP.

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

/Man   -ro

/Bin   -ro,access = tiger:lion

/Users -rw,access = tiger

В данном случае доступ к первому каталогу разрешен любым системам, но только для чтения (-ro). Ко второму каталогу могут обращаться для чтения хосты tiger и lion, а к каталогу /users доступ для чтения и записи (-rw) разрешен системе tiger.

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

Клиент должен явным образом указать все монтируемые им каталоги удаленных серверов. Обычно это делается при выполнении последовательности команд монтирования во время запуска операционной системы клиента. Иногда команда mount читает специальный конфигурационный файл.

Команда монтирования может иметь необязательные параметры, среди которых наиболее важны те, что определяют:

■ Должен ли каталог иметь полномочия для чтения и записи или только для чтения.

■ Нужно ли периодически возобновлять попытки монтирования в фоновом режиме при неудаче монтирования во время запуска системы.

■ Требуется ли прерывать выполнение запроса RPC к NFS при длительном ожидании ответа.

■ Реализована ли в NFS одна из версий системы безопасности RPC.

Команда mount приводит к отправке на сервер запроса RPC с именем Add Mount Entry (добавить точку монтирования). В ответе на это сообщение протокол монтирования возвращает описатель файла, который клиент будет использовать для идентификации каталога в последующих запросах. Вспомним, что описателем является строка, содержащая идентификатор сервера и соответствующего каталога или файла. Например, когда происходит монтирование /users как локального каталога /usr, в ответе на запрос монтирования будет возвращен описатель файла для каталога /users.

15.15.1 Процедуры монтирования

Процедуры, поддерживающие программу mount на сервере, показаны в таблице 15.4.

Таблица 15.4 Процедуры монтирования

Последней реализацией NFS является версия 3, хотя продолжают успешно применяться реализации версии 2. Программа NFS сервера имеет номер 100003 и, по соглашению, NFS захватывает при инициализации порт 2049.

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

Когда клиент монтирует каталог, протокол возвращает ему описатель файла (file handle), который должен идентифицировать данный каталог в последующих запросах клиента. Монтируемый каталог может содержать подкаталоги, имеющие, в свою очередь, собственные подкаталоги, и т.д. Возможно, путь к файлу будет содержать несколько уровней вложенности. Например, перед тем как клиент сможет изменить файл:

/usr/john/book/chapter3

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

■ Послать на сервер запрос на просмотр описателей файлов каталога /users и указать имя John. В ответе будет возвращен описатель каталога /users/john.

■ Послать на сервер запрос на просмотр описателей файлов каталога /users/john и указать имя book. Сервер возвратит описатель для /users/john/book.

■ Послать на сервер запрос на просмотр описателей файлов каталога /users/john/book и указать имя chapter3. В ответе будет содержаться описатель нужного файла.

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

15.17.2 Процедуры NFS

Существуют процедуры NFS, обеспечивающие клиенту доступ, чтение или запись удаленного файла. Клиент может узнать структуру и реальную емкость удаленной файловой системы либо запросить атрибуты удаленного файла. Допустимо удалять и переименовывать файлы. Некоторые процедуры специфичны для файловой системы Unix (например, связывание с именем псевдонима файла). Процедуры NFS версий 2 и 3 кратко представлены в таблице 15.5.

Таблица 15.5 Процедуры NFS версий 2 и 3

15.17.3 Специальные утилиты

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

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

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

Когда клиенту DOS нужно прочитать текстовый файл, созданный в Unix, возникает несколько проблем. Прежде всего, имена файлов в DOS ограничены 8-ю символами, а далее следуют необязательные точка и еще 3 или меньше символов (расширение имени файла). В DOS все имена файлов принято записывать символами верхнего регистра. Например: COMMAND.COM. Имена файлов в Unix могут быть гораздо длиннее и состоять из символов верхнего и нижнего регистров. Например, в Unix вполне допустимо имя aLongerName.More.

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

Однако существуют и другие проблемы. Строки текстовых файлов DOS завершаются символами возврата каретки (CR) и перевода строки (LF), в то время как в Unix применяется только LF. Некоторые разработчики реализуют автоматическую трансляцию на основе специальных утилит преобразования к локальному формату.

15.17.4 Блокировка файлов

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

Блокировка файлов в NFS реализуется двумя службами: диспетчером блокировки (lock manager) и программой статуса (status). Диспетчер блокировки управляет клиентскими запросами на блокировку файлов. Программа status на сервере отслеживает текущие блокировки, выполняемые клиентскими хостами. При крахе сервера программа статуса отсылает уведомление зарегистрированным клиентским хостам, запрашивая от них снятие блокировок файлов.

15.17.5 Заметки о реализациях NFS

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

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

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

15.17.6 Мониторинг NFS

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

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

> ntsstat

Server rpc:

Calls    badcalls nullrecv badlen xdrcall

25162314    0         0       0      0

Server nfs:

Calls    badcalls

25162314  491

Null   getattr     setattr   root lookup      readlink

478 0% 9689121 38% 380591 1% 0 0% 5596396 22% 5992775 23%

read

1009813 4%

Wrcache write      create    remove   rename   link    symlink

0 0%    1146142 4% 627381 2% 66180 0% 13089 0% 6042 0% 265 0%

Mkdir   rmdir readdir   fsstat

1718 0% 66 0% 626437 2% 5820 0%

Client rpc:

Calls   badcalls retrans badxid timeout wait newcred timers

3931394 2069       0      42    2037     0      0    1697

Client nfs:

Calls   badcalls nclget  nclsleep

3929178   32     3929357    0

Null getattr     setattr root lookup      readlink

0 0% 2221718 56% 6689 0% 0 0% 1423702 36% 93498 2%

Read     wrcache write    create  remove  rename

54110 1% 0 0%    19501 0% 7362 0% 6493 0% 158 0%

Link symlink mkdir rmdir readdir  fsstat

5 0% 0 0%    28 0% 12 0% 95804 2% 98 0%