Загрузка...



  • 15.1 Введение
  • 15.1.1 Назначение NFS
  • 15.1.2 Соотношения между NFS, RPC и XDR
  • 15.1.3 RPC как стандарт Интернета
  • 15.1.4 Реализации NFS и RPC
  • 15.2 Модель RPC
  • 15.3 Программы и процедуры RPC
  • 15.4 Типичная программа RPC
  • 15.5 Работа с дубликатами запросов RPC
  • 15.6 Portmapper в RPC
  • 15.6.1 Назначение Portmapper
  • 15.6.2 Процедуры portmapper
  • 15.6.3 Просмотр служб RPC через portmapper
  • 15.7 Программа rpcbind
  • 15.7.1 Назначение rpcbind
  • 15.7.2 Процедуры rpcbind
  • 15.8 Сообщения RPC
  • 15.9 Аутентификация в RPC
  • 15.9.1 Нулевая аутентификация
  • 15.9.2 Аутентификация систем
  • 15.9.3 Аутентификация DCS
  • 15.9.4 Аутентификация в Kerberos
  • 15.10 Пример сообщении RPC версии 2
  • 15.11 XDR
  • 15.11.1 Язык описания данных XDR
  • 15.11.2 Кодирование в XDR
  • 15.12 Программные интерфейсы RPC и XDR
  • 15.13 Введение в NFS
  • 15.14 Модель файлов NFS
  • 15.14.1 Источник формирования модели NFS
  • 15.15 Протокол монтирования
  • 15.15.1 Процедуры монтирования
  • 15.16 Особенности NFS
  • 15.17 Протокол NFS
  • 15.17.1 Описатели файлов
  • 15.17.2 Процедуры NFS
  • 15.17.3 Специальные утилиты
  • 15.17.4 Блокировка файлов
  • 15.17.5 Заметки о реализациях NFS
  • 15.17.6 Мониторинг NFS
  • 15.18 Дополнительная литература
  • Глава 15

    RPC и NFS

    15.1 Введение

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

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

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

    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.2 Модель RPC

    Приложение клиент/сервер для архитектуры ONC функционирует поверх RPC. Работа RPC моделируется обычными вызовами подпрограмм. Например, в языке программирования С вызов обычной подпрограммы в общем случае имеет форму:

    код_возврата = имя_процедуры (входные_параметры, выходные_параметры)

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

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

    Рис. 15.2. Взаимодействие в RPC

    15.3 Программы и процедуры RPC

    Основные концепции RPC достаточно просты:

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

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

    ■ Каждой программе присвоен числовой идентификатор.

    ■ Каждая процедура программы также имеет числовой идентификатор.

    На момент написания книги выделением уникальных номеров для программ занималась компания Sun Microsystems (в будущем это должно перейти под юрисдикцию IANA). Диапазоны идентификаторов программ показаны в таблице 15.1. Числовой идентификатор присваивается процедурам программы разработчиком этой программы. Например, процедура чтения NFS — 6, а переименования NFS — 11.


    Таблица 15.1 Присваивание номеров в RPC

    0–1fffffff Определяются компанией Sun (rpc@sun.com)
    20000000–3fffffff Номера только для использования внутри сайта
    40000000–5fffffff Для приложений, динамически генерирующих номера программ
    60000000–7fffffff Зарезервировано
    80000000–9fffffff Зарезервировано
    a0000000–bfffffff Зарезервировано
    c0000000–dfffffff Зарезервировано
    e0000000–ffffffff Зарезервировано

    Запрос клиента RPC идентифицирует запускаемую программу и процедуру по ее номеру. Например, чтобы прочитать файл, запрос RPC обратится к программе 100003 (NFS) и процедуре 6 (чтение). На рис. 15.3 показано клиентское приложение, обращающееся к удаленной процедуре программы 100003.

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

    Рис. 15.3. Доступ к удаленной процедуре из клиентского приложения

    Удаленный запрос к процедуре (RPC) послан от клиента серверу в форматированном сообщении. RPC не заботится о том, какой транспортный протокол используется для пересылки сообщения. В мире TCP/IP RPC может работать поверх UDP или TCP, но можно использовать и другой транспорт.

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

    15.4 Типичная программа RPC

    Наиболее известной программой RPC является NFS. Соответствующая команда mount (монтировать) позволяет клиенту подключить к своей локальной файловой системе удаленный каталог. Эта команда также является программой RPC. Существуют lock manager (диспетчер блокировки) и программа status, которые обеспечивают основу для изменения пользователем разделяемых файлов на сервере NFS.

    Spray (распыление) — пример очень простой программы RPC. Клиент spray посылает серию сообщений к удаленной системе и получает ответ. Представленная ниже команда посылает 100 датаграмм хосту plum (эта программа позволяет получить статистику пересылки группы сообщений. — Прим. пер.):

    > spray -с 100 plum

    sending 100 packets of lnth 86 to plum …

    in 10.1 seconds elapsed time,

    29 packets (29.00%) dropped by plum

    Sent: 9 packets/sec, 851 bytes/sec

    Rcvd: 7 packets/sec, 604 bytes/sec

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

    > rusers

    Zonker.num.cs.yale.edu leonard jones harris

    Mark.num.cs.yale.edu   davis   sherman

    Duke.num.cs.yale.edu   burry   victor

    . . .

    15.5 Работа с дубликатами запросов RPC

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

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

    ■ Если в пределах тайм-аута не будет получен ответ, послать сообщение об ошибке конечному пользователю, который и должен снова инициировать запрос к службе.

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

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

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

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

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

    15.6 Portmapper в RPC

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

    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

    Процедура Описание
    PMAPPROC_NULL Возвращает ответ, указывающий на активное состояние portmapper.
    PMAPPROC_SET Используется при регистрации службы (т.е. при включении в список активных служб сервера локальной программы, ее версии, протокола и номера порта).
    PMAPPROC_UNSET Применяется для отмены регистрации службы (например, при удалении локальной программы из списка активных служб сервера).
    PMAPPROC_GETPORT Используется клиентом для поиска номера порта сервера. Входными параметрами являются специальный номер программы, версия программы и транспортный протокол (UDP или TCP).
    PMAPPROC_DUMP Возвращает список всех локальных программ RPC, их версий, коммуникационных протоколов и портов (используется в rpcinfo -p).
    PMAPPROC_CALLIT Пересылка поступающего от клиента косвенного запроса к локальной программе RPC. При успешном завершении процедуры возвращает ответ, включая номер порта программы. Предназначен для использования при широковещательных запросах.

    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

    15.7 Программа rpcbind

    В последних версиях 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

    Процедура Описание
    RPCBPROC_SET Используется службой регистрации программ через локальную RPCBIND.
    RPCBPROC_UNSET Используется для отмены регистрации локальной программы.
    RPCBPROC_GETADDR Возвращает клиенту универсальный адрес программы.
    RPCBPROC_GETVERSADDR В запрос включается нужный номер версии программы.
    RPCBPROC_GETADDRLIST Выводит список адресов программы. Клиент может выбрать из нескольких доступных транспортных протоколов.
    RPCBPROC_DUMP Список всех элементов базы данных RPCBIND (например, предоставление сведений для вывода командой rpcinfo).
    RPCBPROC_BCAST Поддержка широковещательного запроса — RPCBIND пересылает запрос локальной программе.
    RPCBPROC_INDIRECT Поддержка косвенных запросов, которые являются многоадресными — RPCBIND пересылает их локальной программе и возвращает назад результат или сообщение об ошибке.
    RPCBPROC_GETTIME Возвращает местное время сервера, отсчитанное в секундах от полночи первого дня января 1970 г.
    BPCBPBOC_UADDR2TADDR Преобразование универсальных адресов в адреса, специфичные для данного транспорта.
    RPCBPROC_TADDR2UADDR Преобразование специфичных для транспорта адресов в универсальные адреса.
    RPCBPROC_GETSTAT Предоставление статистики о количестве и типах полученных запросов.

    15.8 Сообщения RPC

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

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

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

    На рис. 15.5 показано взаимодействие клиента с программой сервера. Клиент посылает запрос. Когда работа затребованной процедуры завершается, серверная программа возвращает ответ. Как видно из рис. 15.5, запрос включает:

    ■ Идентификатор транзакции

    ■ Текущий номер версии RPC

    ■ Номер программы

    ■ Версию программы

    ■ Номер процедуры

    ■ Мандат аутентификации

    ■ Проверочные сведения (verifier) аутентификации

    ■ Входные параметры

    Рис. 15.5. Сообщения RPC

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

    15.9 Аутентификация в RPC

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

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

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

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

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

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

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

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

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

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

    stamp (штамп) Случайный идентификатор, сгенерированный вызывающим компьютером
    machinename (имя машины) Имя запрашивающей машины
    uid (идентификатор пользователя) Реальный номер идентификации пользователя, инициировавшего запрос
    gid (идентификатор группы) Реальный номер идентификации группы пользователя, инициировавшего запрос
    gids (идентификаторы групп) Список групп, к которым принадлежит пользователь

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

    Проверочные сведения аутентификации (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 для шифрования аутентификационной информации клиента и сервера

    15.10 Пример сообщении RPC версии 2

    На рис. 15.6 показан результат обработки монитором Sniffer компании Network General заголовка UDP и полей RPC из сообщения запроса к NFS о выводе атрибутов файла. Заголовки уровня связи данных и IP опущены, чтобы не загромождать рисунок.

    UDP: -- UDP Header --

    UDP:

    UDP: Source port = 1023 (Sun RPC)

    UDP: Destination port = 204 9

    UDP: Length = 124

    UDP: No checksum

    UDP:

    RPC: -- SUN RPC header --

    RPC:

    RPC: Transaction id = 641815012

    RPC: Type = 0 (Call)

    RPC: RPC version = 2

    RPC: Program = 100003 (NFS), version = 2

    RPC: Procedure = 4 (Look up file name)

    RPC: Credentials: authorization flavor = 1 (Unix)

    RPC: len = 32, stamp = 642455371

    RPD: machine = atlantis

    RPC: uid = 0, gid = 1

    RPC: 1 other group id(s) :

    RPC: gid 1

    RPC: Verifier: authorization flavor = 0 (Null)

    RPC: [Verifier: 0 byte(s) of authorization data]

    RPC:

    RPC: [Обычное завершение заголовка "SUN RPC".]

    RPC:

    NFS: -- SUM NFS --

    NFS:

    NFS: [Параметры для процедуры 4 (Look up file name) follow]

    NFS: File handle = 0000070A00000001000A0000000091E3

    NFS: 5E707D6A000A0000000044C018F294BE

    NFS: File name = README

    NFS:

    NFS: [Обычное завершение "SUN NFS".]

    NFS:

    Рис. 15.6. Формат сообщения RPC с запросом к NFS

    Заметим, что запрос RPC имеет тип сообщения 0. Ответ будет иметь тип 1. Протокол RPC периодически обновляется, поэтому в сообщении указывается версия RPC (в нашем случае это версия 2).

    Вызывающая сторона использует мандат Unix, определяющий реальные идентификаторы пользователя и группы (userid и groupid). Имеется дополнительный идентификатор группы. Штампом служит произвольный идентификатор, созданный вызывающей стороной. Поле проверочных сведений аутентификации имеет оттенок 0 (не обеспечивает никакой дополнительной информации). NFS часто реализуется с частичной аутентификацией, поскольку более полная зашита снижает производительность.

    За идентификатором программы 100003 (NFS) и процедуры 4 (просмотр имен файлов) следуют параметры: описатель файла (file handle) и имя файла.

    Описатель файла — это специальный идентификатор, связанный с каталогом или файлом сервера. В версии 2 протокола RPC описатель файла представлен строкой фиксированной длины в 32 бита, в версии 3 он задается строкой переменной длины с максимальной длиной в 64 бита. В запросе указан файл README, расположенный в каталоге, идентифицированном описателем файла.

    Поля в сообщении запроса кодируются по правилам форматирования XDR (см. следующий раздел).

    Мы можем получить представление о работе XDR, рассмотрев некоторые шестнадцатеричные коды в сообщении запроса:

    Тип сообщения = 0, кодируется (в шестнадцатеричных значениях) как:

    00 00 00 00

    Версия RPC = 2, кодируется как:

    00 00 00 02

    Машина = atlantis, кодируется как:

    (длина строки =8) atlantis

    00 00 00 08 61 74 6С 61 6E 74 69 73


    RPC: -- SUN RPC header --

    RPC:

    RPC: Transaction id = 641815012

    RPC: Type = 1 (Reply)

    RPC: Status = 0 (Accepted)

    RPC: Verifier: authorization flavor = 0 (Null)

    RPC: [Verifier: 0 byte(s) of authorization data]

    RPC: Accept status = 0 (Success)

    RPC:

    RPC: [Обычное завершение заголовка "SUN RPC" .]

    RPC:

    NFS: -- SUN NFS --

    NFS:

    NFS: Proc = 4 (Look up file name)

    NFS: Status = 0 (OK)

    NFS: File handle = 0000070A00000001000A000000005AC9

    NFS:               3298621C000A0000000044C018F294BE

    NFS: File type = 1 (Regular file)

    NFS:  Mode = 0100644

    NFS:  Type = Regular file

    NFS:  Owner's permissions = rw-

    NFS:  Group's permissions = r-

    NFS:  Others; permissions = r-

    NFS: Link count = 1, UID = 303, GID = 1

    NFS: File size = 130, Block size = 8192, No. of blocks = 2

    NFS: File system id = 1802, File id = 23241

    NFS: Access time = 23-Oct-95 16:35:01 GMT

    NFS: Modification time = 20-Oct-95 12:10:43 GMT

    NFS: Inode change time = 20-Oct-95 12:10:43 GMT

    NFS:

    NFS: [Обычное завершение "SUN NFS".]

    NFS:

    Рис. 15.7. Формат сообщения RPC с ответом от NFS

    В показанном на рис. 15.7 ответе присутствует тот же идентификатор транзакции. Указана нулевая аутентификационная информация. Запрос был принят, и его обработка завершилась успешно. Ответ содержит много полезной информации о файле README:

    ■ Идентификатор описателя файла. Любые дальнейшие операции с этим файлом будут использовать указанный в ответе описатель.

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

    ■ Имеются дополнительные атрибуты файла, например его размер, время последнего обращения и обновления. Можно ожидать, что эти атрибуты поддерживаются в любой файловой системе.

    15.11 XDR

    Как будут взаимодействовать разнородные (гетерогенные) машины в окружении клиент/сервер, чтобы понимать посылаемые друг другу данные? Например, клиент 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 состоит в том, что данные кодируются существенно меньшим количеством байт, а недостаток — в том, что каждое поле должно быть в предопределенном месте сообщения.

    15.12 Программные интерфейсы RPC и XDR

    Приложения клиент/сервер для RPC строятся на основе библиотеки подпрограмм для создания, отправки и получения сообщений RPC. Другие программы библиотеки служат для преобразования между локальным представлением данных для параметров сообщения и форматом XDR. Типичная подпрограмма RPC:

    int callrpc (хост, номер_программы, номер_версии, номер_процедуры, входная_программа, входные_параметры, выходная_программа, выходные_параметры)

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

    Компании NetWise и Sun разработали комплект программных инструментов, который упрощает создание приложений клиент/сервер для RPC и скрывает от разработчика запросы RPC нижнего уровня.

    15.13 Введение в NFS

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

    Перед использованием NFS хост клиента проводит монтирование (mounting) удаленного поддерева каталогов в свою собственную файловую систему, посылая запрос RPC к программе mount сервера.

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

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

    Рис. 15.8. Компоненты поддержки NFS

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

    15.14 Модель файлов NFS

    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. Монтирование удаленного каталога

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

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

    Команда 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 Процедуры монтирования

    Процедура Описание
    0 Null (пустая): Ответ указывает на активность программы.
    1 Add Mount Entry (добавить точку монтирования): В список команды mount добавляется элемент для монтируемого удаленного каталога.
    2 Return Mount Entries (возвратить точку монтирования): Возвращение клиенту текущего пути монтируемого каталога.
    3 Remove Mount Entry (удалить точку монтирования): Удалить сведения о заданном каталоге.
    4 Remove All Mount Entries (удалить все точки монтирования): Удалить всю информацию о монтировании удаленных каталогов.
    5 Return Export List (возвратить список экспортируемых каталогов): Получить список каталогов и хостов, к которым разрешен доступ.

    15.16 Особенности NFS

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

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

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

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

    15.17 Протокол NFS

    Последней реализацией 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

    Процедура Версия 2 Версия 3
    0 Пустая процедура для тестирования Пустая процедура для тестирования.
    1 Получить атрибуты файла Получить атрибуты файла.
    2 Установить атрибуты файла Установить атрибуты файла.
    3 Устаревшая процедура Просмотр имени файла. По описателю файла для каталога и имени подкаталога или файла возвратить описатель файла для подкаталога или файла.
    4 Просмотр имени файла Проверка полномочий доступа.
    5 Чтение информации о связанной с файлом символьной ссылке Чтение информации о связанной с файлом символьной ссылке.
    6 Чтение данных из файла Чтение данных из файла
    7 Не используется Записать данные в файл. Запрос может указывать, будет ли кешироваться операция записи и будет ли результат операции фиксироваться в устойчивом состоянии до отправки ответа.
    8 Записать данные в файл Создать файл.
    9 Удалить файл Создать каталог.
    10 Создать файл. Создать символьную ссылку (symbolic link).
    11 Переименовать файл Создать узел (например, специальное устройство).
    12 Создать ссылку на файл Удалить (стереть) файл.
    13 Создать символьную ссылку Удалить каталог.
    14 Создать каталог Переименовать файл или каталог.
    15 Удалить каталог Создать ссылку на объект.
    16 Прочитать имя файла или файлов из каталога Прочитать имя файла или файлов из каталога.
    17 Получают информацию о файловой системе (например, о размере блока и количестве свободных блоков) Прочитать имена файлов, поля, атрибуты и описатели из каталога.
    18 Получить динамическую информацию от файловой системы (например, об общем размере и объеме свободного пространства).
    19 Получить статическую информацию от файловой системы (например, о максимальном размере для запросов чтения и записи).
    20 Извлечение информации POSIX (например, об атрибутах и максимальной длине имени файла).
    21 Фиксация (commit): перенос предварительно размещенных в кеше данных на устройство постоянного хранения.

    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%

    15.18 Дополнительная литература

    На момент выхода книги portmapper и RPCBIND были определены в RFC 1833, протокол Remote Procedure Call версии 2 в RFC 1831, a XDR в RFC 1832.

    Версия 2 системы NFS рассматривается в RFC 1094, а версия 3 описана в RFC 1813. Очень полная спецификация версии 2 системы NFS приведена в X/Open CAE Specification: Protocols for X/Open Internetworking: XNFS, опубликованной X/Open Company, Ltd.








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх