Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

10.1.

Сетевая файловая система компании Sun 641

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

тема NFS теоретически следует модели удаленного доступа, представленной на

рис.

10.1,

(2,

большинство ее реализаций использует локальное кэширование, под-

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

10.1,

б.

В случае семантики сеансов встает вопрос о том, что произойдет, если два

или более клиентов станут одновременно кэшировать и изменять один и тот же

файл. Одно из решений состоит в том, чтобы содержимое файла передавалось

обратно на сервер после закрытия файла. Итоговый результат будет зависеть от

того,

какой запрос на закрытие файла будет обработан сервером последним. Ме-

нее приятной, но более простой в осуществлении альтернативой является выбор

финального результата из нескольких кандидатов с отбрасыванием всех измене-

ний, внесенных в файл другими процессами.

Абсолютно другой подход к семантике совместного использования файлов

распределенных системах состоит в том, чтобы сделать все файлы неизменяе-

мыми. Это означает, что способа открыть файл на запись не существует. В ре-

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

Все,

что мы можем сделать в этом случае,

—

открыть абсолютно новый файл

и поместить его в систему каталогов под именем ранее существовавшего, кото-

рый с этого момента становится недоступным (по крайней мере, под прежним

именем). Таким образом, хотя изменить файл х нельзя, остается возможность ав-

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

но каталоги изменять можно! Как только мы приходим к решению запретить из-

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

в файл, а другой читает из него, просто исчезает.

Остается проблема двух процессов, пытающихся одновременно заменить один

и тот же файл. Как и в семантике сеансов, наилучшим решением здесь кажется

выбор одного из этих новых файлов для замены старого

—

либо последнего из

пришедших, либо по какому-либо другому критерию.

Довольно типичная проблема

—

что делать, если файл заменяется в тот мо-

мент, когда другой процесс занимается его чтением. Одно из решений состоит

в том, чтобы как-нибудь обеспечить использование читающим процессом старо-

го файла, даже если его больше нет в каталогах, аналогично тому, как UNIX по-

зволяет процессам, открывшим файл, продолжать использовать файл даже после

того,

как он удален из всех каталогов. Другое решение состоит в том, чтобы об-

наруживать факт изменения файла и делать все последующие попытки чтения

из него невозможными.

Четвертый способ работы с разделяемыми файлами в распределенных систе-

мах

—

использование транзакций, о которых мы подробно говорили в главе 5.

Обобщим эту информацию. Для доступа к файлу или группе файлов процесс

должен сначала выполнить один из вариантов примитива BEGIN^TRANSACTION, ука-

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

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

Когда работа заканчивается, выполняется примитив

END_TRANSACTION.

Система га-

рантирует, что все вызовы в рамках транзакции будут выполнены в указанном

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

642 Глава 10. Распределенные файловые системы

Если две или более транзакции начинаются одновременно, система гарантирует,

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

в некоторой (неопределенной) последовательности.

В табл. 10.4 обобщены данные по рассмотренным вариантам работы

совме-

стно используемыми файлами

распределенных системах.

Таблица

10.4,

Четыре варианта работы

совместно используемыми файлами

в распределенной системе

Метод Комментарий

Семантика UNIX Каждая операция

файлом немедленно становится видна

всем процессам

Семантика сеансов Изменения невидимы для других процессов до закрытия

файла

Неизменяемые файлы Изменения невозможны, упрощены разделение

репликация

Транзакции Все изменения происходят атомарно

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

Для распределенной файловой системы, серверы которой могут не сохранять ин-

формацию о состоянии, блокировка файлов представляет собой проблему.

NFS

блокировка файлов традиционно осуществлялась при помощи специального про-

токола, реализованного в менеджере блокировок, который, разумеется, состояние

сохранял. Однако по различным причинам блокировка файлов с использованием

протокола блокировок NFS никогда не была слишком популярной из-за сложно-

сти протокола

и, как

следствие, малопроизводительных

или

вообще неверных

реализаций

[412].

В версии

блокировка файлов интегрирована

протокол дос-

тупа

файлам NFS. Ожидалось,

что в

подобном подходе будет удобнее приме-

нять системную блокировку,

а не те

частные решения, которые использовались

вместо системной блокировки

NFS версии

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

распределенных файловых системах осложняется тем,

что клиенты

серверы

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

задача правильного восстановления после сбоев,

что

гарантирует непротиворе-

чивость общих файлов.

Мы

вернемся

этому вопросу чуть позже, когда будем

обсуждать отказоустойчивость

NFS.

Концепция блокировки файлов

NFS версии

проста.

сущности, имеется

всего четыре операции, относящиеся

блокировке файлов,

они

перечислены

в табл. 10.5. NFS отделяет блокировку

на

чтение

от

блокировки

на

запись.

Не-

сколько клиентов могут одновременно работать

одной

той же частью файла,

если они занимаются только чтением данных. Для получения исключительного

доступа

файлу для его модификации необходима блокировка

на

запись.

Таблица 10.5. Операции, относящиеся к блокировке файлов в NFS версии 4

Операция Описание

оск Блокировка набора байтов

ockt Проверка, не назначена ли конфликтующая блокировка

10.1.

Сетевая файловая система компании Sun 643

Операция Описание

1 оски

Снятие блокировки

набора байтов

renew Продление аренды указанной блокировки

Операция lock используется для запроса

на

установку блокировки

на

чтение

или запись последовательного набора байтов

файле. Это неблокирующая опе-

рация; если блокировку невозможно назначить из-за того, что она будет конфлик-

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

жет снова обратиться

серверу

этим запросом. Клиент может также потребо-

вать постановки запрошенной блокировки

список FIFO, который поддерживает

сервер.

Как

только мешающая блокировка будет снята, сервер сможет устано-

вить следующую блокировку, взяв ее с вершины списка и на определенное время

предоставив соответствующему клиенту право

на

работу

сервером. Такой под-

ход избавляет сервер

от

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

на установку блокировки были отклонены, поскольку блокировки устанавлива-

ются

порядке FIFO.

Операция lockt позволяет проверить факт существования конфликтующей

блокировки. Так, например, клиент может проверять, существуют

ли

блокиров-

ки на чтение, установленные на определенную последовательность байтов в фай-

ле,

прежде чем потребует установки на эту последовательность байтов блокиров-

ки

на

запись.

случае конфликта отправивший запрос клиент информируется

том,

кто

на какую последовательность байтов назначил вызвавшую конфликт

блокировку. Это позволяет более эффективно реализовать проверку, чем при при-

менении операции lock, поскольку

случае lockt нет необходимости

открытии

файла.

Снятие блокировки

файла производится при помощи операции locku.

Блокировки устанавливаются

на

конкретное определяемое сервером время.

Другими словами, они связаны

соответствующей арендой. Если клиент не про-

длит аренду своей блокировки, сервер автоматически снимет ее. Как мы увидим,

такой же подход соблюдается

и в

отношении других ресурсов, предоставляемых

сервером,

способствует

его

восстановлению

случае отказов. Используя опе-

рацию renew, рслиент просит сервер продлить аренду его блокировки

(а

также дру-

гих ресурсов).

Кроме этих операций

распоряжении пользователя имеется

еще

один осо-

бый способ блокировки файлов, известный под названием

совместного

резервы-

ровапия

{share

reservation).

Совместное резервирование никак не связано

обыч-

ными блокировками

может использоваться для реализации NFS на платформе

Windows. Когда клиент открывает файл,

он

определяет

тип

доступа, которого

требует для себя

(READ,

WRITE

или

BOTH),

тип доступа,

котором сервер должен

отказать всем прочим клиентам

(NONE,

READ,

WRITE

или

BOTH).

Если сервер

не в со-

стоянии удовлетворить требования клиента, операция открытия файла заверша-

ется с ошибкой. С помощью табл. 10.6 показано, что происходит при попытке от-

крытия новым клиентом файла, уже успешно открытого другим клиентом.

Для

открытого файла мы выделяем два состояния. Состояние доступа определяет тип

доступа, заявленный текущим клиентом. Состояние запрещения определяет,

ка-

644 Глава 10. Распределенные файловые системы

кие виды доступа

файлу запрещены подключающимся

нему дополнитель-

ным клиентам.

Таблица 10.6. Типы совместного доступа для заданных типов запрещения

Текущий тип запрещения

NONE READ WRITE BOTH

Тип

запраши-

ваемого

доступа

READ

WRITE

BOTH

Успешно

Ошибка

Успешно

Ошибка

Успешно

Ошибка

По табл. 10.6 мы можем судить

том, что происходит, когда клиент пытается

открыть файл, запрашивая определенный тип доступа с учетом текущего состоя-

ния запрета для этого файла. Соответственно,

табл. 10.7 представлены резуль-

таты открытия файла, который уже открыт другим клиентом,

одновременной

попыткой запретить определенные типы доступа.

Таблица 10.7. Типы запрещения заданных типов совместного доступа

Тип запрашиваемого запрещения

READ

WRITE

BOTH

NONE

Успешно

READ

Ошибка

Успешно

Ошибка

WRITE

Успешно

Ошибка

BOTH

Ошибка

Текущий тип

доступа

10.1.6.

Кэширование

репликация

Как

многие другие распределенные файловые системы, NFS

для

повышения

производительности интенсивно использует кэширование на клиенте. Кроме то-

го,

она предлагает некоторые средства репликации файлов.

Кэширование на клиенте

Кэширование

NFS версии

3 в

основном не было определено

протоколах. По-

добный подход приводил

созданию различных методик кэширования, боль-

шинство

из

которых никогда

не

гарантировали непротиворечивости.

лучшем

случае кэшированные данные пребывали

устаревшем состоянии

течение не-

скольких секунд, необходимых

для

сравнения

их с

данными, хранящимися

на

сервере. Однако существовали

реализации,

для

которых вполне естественно

было оставлять кэшированные данные устаревшими в течение 30 секунд без уве-

домления клиента. Такое состояние дел было абсолютно нежелательно.

В NFS версии

некоторые

из

этих проблем непротиворечивости были реше-

ны,

но зависимость непротиворечивости кэша от способа его реализации,

сущ-

ности, осталась. Общую модель кэширования, принятую

NFS, иллюстрирует

рис.

10.9.

Каждый клиент может иметь кэш-память

для

хранения считанных

10.1.

Сетевая файловая система компании Sun

645

сервера данных. Кроме того, может существовать также и дисковый кэш, яв-

ляющийся дополнением к кэш-памяти и использующий те же параметры непро-

тиворечивости.

Приложение

клиента

Сервер NFS

Сеть

Рис. 10.9. Кэширование на стороне клиента

NFS

Обычно клиенты кэшируют данные из файлов, атрибуты, дескрипторы фай-

лов и каталогов. Для поддержания непротиворечивости кэшированных данных

и атрибутов были разработаны различные стратегии. Рассмотрим сначала кэши-

рование данных, которые содержатся в файлах.

NFS версии 4 поддерживает два способа кэширования данных. Наиболее про-

стой из них состоит в том, что клиент открывает файл и кэширует содержащиеся

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

Кроме того, над кэшироваными данными можно осуществлять и операцию запи-

си.

После того как клиент закрывает файл, NFS требует, чтобы в том случае, ес-

ли в кэшированные данные были внесены изменения, они были переданы обрат-

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

семантики сеансов, которую мы обсуждали выше.

Как только хотя бы часть файла оказывается кэшированной, клиент может

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

го,

несколько клиентов на одной машине могут использовать один и тот же кэш

совместно. NFS требует, чтобы когда бы клиент ни открыл ранее закрытый файл

с даже частично кэшированными данными, он должен немедленно перепрове-

рить эти данные. Подобная проверка включает в себя проверку времени внесе-

ния в файл последнего изменения и обновление кэша, если он содержит устарев-

шие данные.

Новым для спецификации NFS является то, что сервер после открытия файла

может делегировать часть своих прав клиенту. В том случае, если машине клиента

разрешается локально обрабатывать операции открытия и закрытия файлов других

клиентов той же машины, имеет место

делегирование открытия {open

delegation).

Обычно сервер может определить, было ли успешным открытие файла, напри-

мер,

когда необходимо учитывать совместное резервирование. В случае делеги-

рования открытия машина клиента время от времени может принимать решение

сама, что позволяет исключить контакт с сервером.

646 Глава 10. Распределенные файловые системы

Так, например, в том случае, если сервер делегировал открытие файлов кли-

енту, который запросил право на запись в файл, блокировка файла, которую

запросил другой клиент той же машины, может быть обработана локально. Сер-

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

шин, просто запрещая этим клиентам доступ к файлу. Отметим, что подобная

схема не работает в случае делегирования файла клиенту, имеющему право толь-

ко на чтение. В этом случае, когда другой клиент захочет получить право на за-

пись,

ему придется связаться с сервером; локально обработать такой запрос не-

возможно.

Одно из важных следствий делегирования файла клиенту состоит в том, что

сервер должен быть в состоянии отменить это делегирование, например, когда

права на доступ к файлу захочет получить другой клиент с другой машины. От-

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

но на рис. 10.10.

Клиент

Клиент запрашивает файл

Сервер делегирует файл

3. Сервер отменяет

делегирование

Сервер

Старый файл|

Измененный

файл

4. Клиент возвращает файл

Рис. 10.10. Использование механизма обратного вызова в NFS версии 4

для отмены делегирования файла

Обратный вызов реализуется в NFS при помощи базовых механизмов RPC.

Отметим, однако, что для обратного вызова необходимо, чтобы сервер отслежи-

вал тех клиентов, которым он делегировал файл. Вот и еще одна причина, по

которой больше не может быть сервера NFS без фиксации состояния. Как мы

увидим ниже, совместное использование делегирования и серверов с фиксацией

состояния в случае отказа сервера или клиента может стать источником различ-

ных проблем.

Клиенты могут также кэшировать значения атрибутов, но обычно они остав-

ляют их теми, которые были, чтобы значения в кэше оставались непротиворечи-

выми. Однако значения атрибутов одного и того же файла, кэшированные двумя

разными клиентами, могут быть разными, если, конечно, клиенты не поддержи-

вают эти атрибуты взаимно непротиворечивыми. Модификации значений атри-

бутов немедленно передаются на сервер в соответствии с правилами согласован-

ности кэша сквозной записи.

Таким же образом выполняется кэширование дескрипторов файлов (или, ско-

рее,

отображений имен файлов в дескрипторы) и каталогов. Чтобы снизить от-

рицательный эффект от возможной в этом случае противоречивости, NFS ис-

пользует аренду кэшируемых атрибутов, дескрипторов файлов и каталогов.

После истечения определенного периода времени хранимая в кэше информация

10.1.

Сетевая файловая система компании Sun 647

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

зовать эти данные, их необходимо обновить с сервера.

Серверы реплик

NFS версии 4 предоставляет минимальную поддержку репликации файлов. Реп-

лицирована может быть только файловая система целиком (то есть все логиче-

ское устройство, включая файлы, атрибуты, каталоги и блоки данных). Поддержка

предоставляется в виде атрибута

FS_LOCATIONS,

который для всех файлов является

рекомендуемым. Этот атрибут поддерживает список мест, в которых может нахо-

диться файловая система, содержащая данный файл. Каждое из этих мест указы-

вается в форме DNS-имени или IP-адреса. Отметим, что для действительной реа-

лизации реплицируемых серверов необходима специальная реализация NFS.

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

10.1.7.

Отказоустойчивость

Вплоть до появления последней версии NFS отказоустойчивость в этой системе

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

протокол NFS не предусматривал хранения серверами информации о состоянии.

В результате восстановление сервера после сбоя было идеально простым

—

ведь

никакого состояния не терялось. Разумеется, состояние поддерживалось отдель-

ными менеджерами блокировок, и в этих случаях было необходимо предприни-

мать определенные меры.

После отказа от архитектуры без фиксации состояния в NFS версии 4 воз-

никла необходимость заниматься отказоустойчивостью и восстановлением все-

рьез.

В частности, хранение информации о состояния проявляется в двух случа-

ях

—

блокировке файлов и делегировании. Кроме того, необходимо принимать

особые меры в связи с ненадежностью механизма RPC, который лежит в основе

протокола NFS. Давайте рассмотрим эти вопросы по отдельности и начнем с от-

казов RPC.

Отказы RPC

Проблема механизма RPC, используемого в NFS, состоит в том, что он не гаран-

тирует надежности. На практике клиентские и серверные заглушки RPC могут

создаваться как на базе ориентированного на соединение надежного транспорт-

ного протокола, такого как TCP, так и на базе ненадежного транспортного прото-

кола без установления соединения, например UDP.

Основная проблема, которую система NFS унаследовала от базовой семанти-

ки RPC,

—

это отсутствие средств определения дублированных запросов. Как

следствие, когда RPC

воспроизводит

потерянный запрос, а клиент заново посы-

лает исходный запрос, сервер в конечном итоге обслужит запрос более одного

раза. При работе с не идемпотентными операциями подобная ситуация происхо-

дить не должна.

Эти проблемы можно решить при помощи кэша дублированных запросов

{duplicate-request

cache),

реализуемого сервером

[221].

Каждый запрос RPC, по-

648 Глава 10. Распределенные файловые системы

сылаемый клиентом, содержит

заголовке уникальный

идентификатор

тран-

закции

(Transaction

Identifier^

XID), который кэшируется сервером, когда запрос

до него доходит.

До тех

пор пока сервер

не

пошлет ответ,

он

будет показывать,

что запрос RPC находится

процессе обработки. Когда обработка запроса завер-

шается, ассоциированный с ним ответ также кэшируется, после чего возвращает-

ся клиенту.

Существует

три

ситуации, которые

нам

следует рассмотреть.

первом слу-

чае,

продемонстрированном

на

рис.

10.11,

<2,

клиент посылает запрос

запускает

таймер. Если время ожидания истекает до прихода ответа, клиент воспроизводит

исходный запрос

с тем же

самым идентификатором XID,

что и

оригинальный.

Если сервер еще

не

выполнил исходного запроса, повторный запрос

он

просто

игнорирует.

Клиент Сервер

ХЮ = 1234

Время

Клиент Сервер

ХЮ = 1234

\ Обработка

J запроса

Кэш

Время

ХЮ = 1234

Клиент Сервер

ХЮ = 1234

Кэш

Время

Рис.

10.11.

Три ситуации повторной передачи. Запрос еще выполняется

(а).

Ответ только что отправлен (б). Ответ давно отправлен, но затерялся

(е)

Во втором случае сервер может принять повторно посланный запрос сразу

после того,

как он

отошлет клиенту ответ. Если время доставки повторного

за-

проса близко ко времени отправки сервером ответа, сервер делает вывод, что по-

вторный запрос

ответ пересеклись,

потому игнорирует повторный запрос. Эту

ситуацию иллюстрирует рис.

10.11,

В третьем случае ответ действительно теряется,

результатом повторного за-

проса должна стать отправка сохраненных

кэше результатов операции клиен-

ту,

что и

показано

на

рис.

10.11,

в.

Отметим,

что

результат файловой операции

должен быть кэширован, поскольку отсутствуют всякие гарантии того,

что по-

вторная посылка

на

этот раз увенчается успехом.

Блокировка файлов при отказах

Блокировка файлов в NFS версии 3 обрабатывалась выделенным сервером. В ре-

зультате можно было использовать протокол NFS,

не

предполагающий сохране-

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

решались сервером блокировок. Однако

появлением

NFS версии

средств

блокировки файлов включение

протокол NFS базового механизма обработки

10.1.

Сетевая файловая система компании Sun 649

отказов клиента и сервера стало неминуемым. Решаемая этим механизмом про-

блема относительно проста. Чтобы заблокировать файл, клиент посылает на сер-

вер соответствующий запрос. Далее рассмотрим проблемы, возникающие при от-

казах клиента или сервера в предположении, что блокировка уже предоставлена.

Чтобы разобраться с проблемами отказа клиента, сервер на каждую предо-

ставленную блокировку устанавливает аренду. Когда срок аренды истекает, сер-

вер удаляет блокировку, освобождая, таким образом, связанные с ней ресурсы

(то есть файлы). Чтобы предотвратить удаление сервером блокировки, клиент

должен продлить свою аренду до того, как она истечет. Именно этой цели слу-

жит в NFS описанная ранее операция renew.

Существуют ситуации, когда блокировки удаляются, даже если клиент нахо-

дится во вполне работоспособном состоянии. Собственно, ложные удаления мо-

гут произойти, если клиент вовремя не сообщит серверу о необходимости про-

дления аренды, например, из-за того, что сеть оказалась (временно) разделенной

на

части.

Для разрешения такой ситуации не применяется никаких специальных

мер.

Если сервер сначала отказывает, а затем он восстанавливается, информация

по блокировкам, предоставленным клиентам, будет предположительно потеряна.

Подход, принятый в NFS версии 4, состоит в том, чтобы предоставить клиентам

период амнистии {grace

period),

в течение которого клиент может повторно предъ-

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

восстанавливает свое предыдущее состояние в части, касающейся блокировок.

Отметим, что подобное восстановление блокировок никак не связано с восстанов-

лением прочих данных. В период амнистии обычно принимаются только запро-

сы на восстановление блокировок, обычные запросы на предоставление блокиро-

вок до окончания этого периода не рассматриваются.

Здесь следует отметить, что аренда вносит многочисленные проблемы, кото-

рые решаются в NFS лишь частично. Так, например, аренда требует, чтобы кли-

ент и сервер синхронизировали свои часы. Если сервер считает, что аренда исте-

кает в момент времени Г, часы клиента должны показывать то же время, что

и часы сервера. С другой стороны, если сервер считает, что аренда истекает через

некий период времени D, то ему требуется знать время, которое занимает от-

правка аренды клиенту. В глобальных системах вопросы точного времени ре-

шить не так-то легко.

Другая проблема состоит в надежности сообщения о продлении аренды, от-

правленного серверу. Если доставка сообщений не работает или производится

опозданием, аренда может быть ненамеренно просрочена. В этом случае клиент,

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

вера новой аренды.

Делегирование открытия при отказах

В случае отказа клиента или сервера делегирование открытия создает дополни-

тельные проблемы. Рассмотрим для начала клиента, которому делегировано пра-

во открытия файла. Если клиент отказывает, предполагается, что он, поработав

со своей локальной копией файла, не успел передать изменения на

сервер.

Други-

650 Глава 10. Распределенные файловые системы

ми словами, клиент следует правилам согласованности кэша обратной записи.

Пока клиент не восстановит локально сохраненный файл в устойчивое хранили-

ще,

полное восстановление файла невозможно. В любом случае за восстановле-

ние файла отчасти отвечает клиент.

Когда сервер сначала отказывает и затем восстанавливается, он следует про-

цедуре, похожей на установку блокировки. Клиент, которому было делегировано

открытие файла, требует восстановление прав на это делегирование, когда сер-

вер вновь становится работоспособным. Однако в противоположность блокиров-

кам сервер заставляет клиента передать все изменения назад на сервер, отменяя

таким образом делегирование.

Подобный подход имеет два эффекта. Во-первых, на сервере оказываются по-

следние результаты изменений каждого из файлов, права на которые он делеги-

ровал клиенту. Во-вторых, поскольку сервер снова обладает полным контролем

над файлом, он может делегировать его другому клиенту.

10.1.8.

Защита

Как мы ранее говорили, основная идея, лежащая в основе

NFS,

состоит в том, что

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

их собственной локальной файловой системы. В свете этого для нас не будет

неожиданностью тот факт, что система защиты в NFS сконцентрирована в основ-

ном на вопросах взаимодействия между клиентом и сервером. Защищенное взаи-

модействие, как мы выяснили в главе 8, предполагает наличие защищенного ка-

нала между взаимодействующими сторонами.

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

к файлам, который в NFS обрабатывается при помощи атрибутов контроля дос-

тупа файлов. За подтверждение прав доступа клиентов, как будет показано да-

лее,

отвечает файловый сервер. В сочетании с защищенными вызовами RPC ар-

хитектура защиты NFS выглядит так, как показано на рис. 10.12.

Клиент

Уровень виртуальной

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

Контроль

доступа

Интерфейс локальной

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

с:—^—!i

- J [

Сервер

NFS 1

Серверная 1

заглушка RPC Г

'ш

Защищенный

канал '•

Сервер

1 Уровень виртуальной

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

> к

Сервер

NFS

J Серверная

1 заглушка RPC

Контроль

доступа

ilr

Интерфейс локальной

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

р-"

•••••• w^

Рис. 10.12. Архитектура защиты NFS