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

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

10.1.

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

Защищенные вызовы RPC

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

в NFS

выполняется с помощью защищенных вызовов RPC. До NFS версии 4 за-

щищенный вызов RPC означал лишь проведение аутентификации. Существова-

ло три способа аутентификации. Рассмотрим каждый из них по отдельности.

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

ще назвать аутентификацией, известен под названием системной аутентифика-

ции. В этом методе, основанном на технологиях системы UNIX, клиент просто

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

вателя и группы вместе со списком групп, в которых он состоит. Другими словами,

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

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

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

и может по праву распоряжаться клиентской машиной.

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

предполагает метод обмена ключами Диффи—Хеллмана для создания сеансово-

го ключа и организации так называемой защищенной системы NFS. Как работа-

ет обмен ключами Диффи—Хеллмана, мы рассматривали в главе 8. Такой под-

ход значительно лучше, чем системная аутентификация, но сложнее, а потому

реже применяется. Обмен ключами Диффи—Хеллмана можно считать крипто-

системой с открытым ключом. Изначально способа защищенного распростране-

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

был исправлен путем организации защищенной службы именования. Нарекания

всегда вызывал относительно короткий открытый ключ, который в NFS имеет

длину всего 192 бита. В [248] было продемонстрировано, что взломать систему

Диффи—Хеллмана с таким коротким ключом довольно легко.

Третий протокол аутентификации

—

это система Kerberos (версии 4), кото-

рую мы также рассматривали в главе 8.

С появлением NFS версии 4 защита системы была усилена благодаря

RPCSEC_GSS. RPCSECjGSS

—

это обобщенная схема защиты, которая при ор-

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

защиты

[134].

В частности, она предоставляет не только средства подключения

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

циальность сообщений, две характеристики, которые в прежних версиях NFS не

поддерживались.

RPCSEC_GSS базируется на стандартном для служб защиты интерфейсе

GSS-API,

о котором мы упоминали в главе 8 и который подробно описан в

[267].

Схема RPCSEC_GSS работает поверх этого интерфейса, как показано на

рис.

10.13.

В NFS версии 4 схема RPCSEC_GSS должна быть сконфигурирована для

поддержки Kerberos версии 5. Кроме того, система в состоянии поддерживать

метод под названием LIPKEY, описанный в

[133].

LIPKEY

—

это система с от-

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

лю,

в то время как сервер аутентифицируется с помощью открытого ключа.

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

Машина клиента

Клиент NFS

RPCSEC GSS

GSS-API

Клиентская

заглушка

RPC

Машина сервера

Сервер NFS

RPCSEC GSS

GSS-API

Серверная

заглушка

RPC

Сеть

Рис, 10.13. Защищенный вызов RPC в NFS версии 4

Один из важных аспектов защищенных вызовов RPC в NFS состоит в том,

что разработчикам не нужно создавать собственных механизмов защиты, доста-

точно организовать стандартный способ обеспечения защиты. Механизмы защи-

ты,

такие как Kerberos, можно встраивать непосредственно в реализацию NFS,

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

ствующие механизмы защиты оказываются ненадежными (как это произошло

с алгоритмом Диффи—Хеллмана с короткими ключами), их легко можно заменить.

Следует отметить, что поскольку схема RPCSEC_GSS реализована в виде

части уровня RPC, поверх которого работают протоколы NFS, она может быть

использована и в предыдущих версиях

NFS.

Однако такая адаптация уровня RFC

стала возможной только с появлением NFS версии 4.

Контроль доступа

Авторизация в NFS аналогична авторизации защищенных вызовов RFC: она пре-

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

пом поддерживается при помощи атрибута ACL файлов. Этот атрибут представ-

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

права доступа определенного пользователя или группы пользователей. Операции

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

ны.

Они перечислены в табл. 10.8.

Таблица 10.8. Классификация операций контроля доступа в NFS

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

read_data

wr1te_data

append_data

execute

I1st_d1rectory

add file

Право на чтение данных файла

Право на изменение данных файла

Право на добавление данных в файл

Право на выполнение файла

Право на получение содержимого каталога

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

10.1.

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

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

acld__subcl1

rectory

delete

delete_ch1ld

read_acl

wr1te_acl

read_attr1butes

write_attributes

read_named_attrs

wr1te_named_attrs

wr1te_owner

synchronize

Право на создание вложенного каталога внутри каталога

Право на удаление файла

Право на удаление файла или вложенного каталога из каталога

Право на чтение списка ACL

Право на запись в список ACL

Право на чтение других основных атрибутов файла

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

Право на чтение именованных атрибутов файла

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

Право на смену владельца

Право на локальный доступ к файлу на сервере с синхронным

чтением и записью

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

например, в системах UNIX, в NFS значительно больше операций. Следует осо-

бо отметить, что операция synchronize действует даже в том случае, если процесс,

располагающийся на сервере, имеет прямой (в обход протокола NFS) доступ

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

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

UNIX. Эта разница вызвана требованием совместной работы NFS и операцион-

ной системы Windows 2000. Основная идея состояла в том, что значительно про-

ще нарастить модель управления доступом UNIX до аналогичной модели Win-

dows 2000, чем провести обратную операцию.

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

шинства файловых систем, включая UNIX, состоит в том, что доступ можно оп-

ределять для разных пользователей и разных групп пользователей. Традиционно

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

группы пользователей (например, членов коллектива разработчиков, работаю-

щего над проектом) и для всех остальных. NFS, как показано в табл. 10.9, под-

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

Таблица 10.9. Разные типы пользователей и процессов

при контроле доступа в NFS

Тип пользователя Описание

Owner

Group

Everyone

Interactive

Network

Dialup

Владелец файла

Группа пользователей, ассоциированных с файлом

Любой пользователь или процесс

Любой процесс, имеющий доступ к файлу через

интерактивный терминал

Любой процесс, имеющий доступ к файлу через сеть

Любой процесс, имеющий доступ к файлу через

коммутируемое соединение с сервером

продолжение^

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

Таблица 10.9

(продолжение)

Тип пользователя Описание

Batch Любой процесс, имеющий доступ к файлу в составе

пакетного задания

Anonymous Всякий, кто получает доступ к файлу без аутентификации

Authenticated Всякий аутентифицированный пользователь или процесс

Serviсе Всякий служебный системный процесс

10.2.

Файловая система Coda

Coda

—

следующий пример распределенной файловой системы. Система Coda

была разработана в университете Карнеги—Меллона (Carnegie Mellon University,

CMU) в 1990-х годах и в настоящее время интегрирована в несколько популяр-

ных операционных систем на базе UNIX, например в Linux. Coda во многих

отношениях отличается от NFS, особенно в отношении высокой доступности.

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

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

жать операцию даже в случае отключения от сервера. Обзор Coda приведен

в [236, 397]. Детальное описание системы можно найти в

[235].

10.2.1.

Обзор

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

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

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

лей как можно более похожей на локальную файловую систему. Помимо высокой

доступности разработчики Coda постарались также обеспечить высокую степень

прозрачности отказов системы.

Coda родилась из второй версии

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

Andrew {Andrew

File

Sys-

tem,

AFS), которая также была разработана в CMU [205, 399] и позаимствовала у

AFS множество архитектурных решений. Система AFS, собственно, и создава-

лась для поддержания инфраструктуры университета CMU. В эту инфраструк-

туру входит приблизительно 10 000 рабочих станций, которым нужно обеспе-

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

разделены на две группы. Одна группа состоит из относительно небольшого чис-

ла выделенных файловых серверов

Vice

с централизованным администрировани-

ем.

Другая группа -- это значительно большее число рабочих станций

Virtue,

кото-

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

показано на рис. 10.14.

Coda имеет такую же организацию, как и AFS. Все рабочие станции Virtue

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

роли клиента

NFS.

Процесс Venus отвечает за предоставление доступа к файлам,

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

Vice.

Venus в Coda отвечает также и за то,

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

10.2.

Файловая система Coda

655

к файловым серверам невозможен (временно). Эта дополнительная роль значи-

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

Прозрачный доступ

к файловым серверам Vice

Клиент

Virtue

Файловый

сервер Vice

Рис. 10.14. Общая организация AFS

Внутренняя архитектура рабочей станции Virtue показано на рис. 10.15. Наи-

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

цессом. На системном уровне клиента запущен отдельный уровень виртуальной

файловой системы (VFS), который перехватывает все вызовы из клиентских при-

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

систему или процессу Venus. Эта структура, включая VFS, аналогична соответ-

ствующей структуре NFS. Venus, в свою очередь, общается с файловыми сервера-

ми Vice, используя систему RPC пользовательского уровня. Система RPC по-

строена поверх дейтаграмм UDP и поддерживает семантику «максимум однажды».

На стороне сервера имеется три разных процесса. Большая часть работы вы-

полняется собственно файловыми серверами Vice, которые отвечают за поддерж-

ку локального набора файлов. Как и Venus, файловый сервер работает на пользо-

вательском уровне. Кроме того, доверенные машины Vice имеют право запустить

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

для сохранения непротиворечивости метаинформации на каждом из серверов Vice

используются процессы обновления.

Coda предоставляет своим пользователям традиционную UNIX-подобную фай-

ловую систему. Она поддерживает большинство операций, входящих в ту часть

спецификации VFS, которая приводились в табл. 10.1

[237].

Повторять эту таб-

лицу здесь мы не будем. В отличие от NFS Coda имеет глобальное разделяемое

пространство имен, поддерживаемое серверами Vice. Клиенты получают доступ

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

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

ном адресном пространстве, например /afs. Когда клиент ищет в этом вложенном

каталоге имя, Venus гарантирует, что соответствующая часть общего пространства

имен монтируется локально. Детали мы рассмотрим позже.

Клиентская машина Virtue

Процесс

пользователя

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

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

Процесс

пользователя

Процесс Venus

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

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

Клиентская

заглушка RPC

Локальная ОС

Сеть

Рис. 10.15. Внутренняя структура рабочей станции Virtue

10.2.2.

Связь

Взаимодействие между процессами в Coda реализуется при помощи вызовов RPC.

Однако система

RPC2,

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

систем RPC, таких как система ONC RPC, применяемая в NFS.

RPC2 реализует надежные вызовы RPC на базе протокола UDP (ненадежного).

При каждом вызове удаленной процедуры код клиента RPC2 запускает новый

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

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

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

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

или позже поток обработки запроса понимает, что сообщения перестали посту-

пать,

и возвращает уведомление об ошибке в приложение, инициировавшее

обмен.

Интересным аспектом RPC2 является поддержка побочных

эффектов

(side

effects).

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

и сервером с использованием специфического протокола приложения. Рассмот-

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

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

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

10.2.

Файловая система Coda

657

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

деленными минимальным

максимальным значениями,

как это

было описано

в главе

RPC2 позволяет клиенту

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

дачи клиенту видеоданных

режиме реального времени. Установка такого

со-

единения является побочным эффектом вызова RPC

на

сервере. Для этой цели

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

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

ствуют процедуры для установки соединения и процедуры для передачи данных.

Эти процедуры автоматически вызываются исполняющими системами RPC2

клиента

сервера соответственно,

но их

реализация абсолютно независима

от

RPC2.

Этот принцип побочных эффектов иллюстрирует рис. 10.16.

RPC-

Клиентское

приложение

Побочный

эффект

клиента

1 Заглушка

Скл

иента

Протокол

приложения

Протокол RPC

Сервер

J Побочный

1 эффект

I сервера

Заглушка

RPC сервера

Рис. 10.16. Побочные эффекты системы RPC2 в Coda

Другое свойство системы RPC2, отличающее ее от прочих систем RPC,

—

под-

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

стоит

в том, что

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

файла.

При

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

вильными

уведомляет

об

этом

при

помощи

RPC

соответствующих клиентов.

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

за

раз, опове-

щение всех клиентов может занять изрядное время, что иллюстрирует

рис.

10.17,

а.

Проблему порождает

тот

факт,

что

вызов

RPC

может потерпеть неудачу.

Объявление файлов неправильными

строго последовательном порядке может

существенно задержаться, поскольку сервер

не в

состоянии связаться

отказав-

шим (возможно) клиентом, но при этом прекратит попытки связаться

этим кли-

ентом только через достаточно длительное время. Тем временем остальные кли-

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

Лучшее решение продемонстрировано

на

рис. 10.17, б. Вместо того чтобы объ-

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

о не-

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

уведомляются одновременно. Кроме того, сервер после требуемой паузы узнает,

что определенные клиенты не

состоянии принять RPC,

может объявить этих

клиентов отказавшими.

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

Клиент

Сервер

Объявить

копию

неправильной

Объявить

копию

неправильной

Клиент

Объявить

копию

неправильной

Сервер

Объявить

копию

неправильной

Клиент

Отклик

Время •

Время

Рис. 10.17. Последовательная отправка сообщения о неправильности копии (а).

Параллельная отправка сообщения о неправильности копии (б)

Параллельные вызовы RPC реализуются при помощи системы MultiRPC

[401],

которая является частью пакета RPC2. Важная особенность MultiRPC со-

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

теля. Другими словами, получатель вызова MultiRPC не может отличить этот

вызов от обычного вызова RPC. Со стороны отправителя параллельное выпол-

нение также вполне прозрачно. Так, например, семантика MultiRPC при на-

личии отказов очень похожа на аналогичную семантику обычного вызова RPC.

Механизм побочных эффектов тоже работает схожим образом.

Вызов MultiRPC реализован, в сущности, как параллельное выполнение не-

скольких вызовов RPC. Это означает, что вызывающая сторона явно отправляет

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

начать ожидать ответ, она откладывает ожидание до того момента, когда будут

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

носторонних вызовов RPC, после чего блокируется до получения ответов от всех

работающих получателей. Альтернативный подход к параллельному выполнению

вызовов RPC в MultiRPC обеспечивается путем организации групп рассылки

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

ки по IP.

10.2.3.

Процессы

Coda поддерживает четкое разделение процессов на клиентские и серверные.

Клиенты представлены процессами Venus, серверы

—

процессами Vice. Оба типа

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

полнения. Потоки выполнения в Coda являются невытесняемыми и работают ис-

ключительно в пространстве пользователя. Для проведения непрерывной опера-

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

поток выполнения. Этот поток берет на себя все операции ввода-вывода, которые

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

операционной системы. Такой поток выполнения эффективно эмулирует син-

хронный ввод-вывод без блокирования процесса в целом.

10.2.

Файловая система Coda 659

10.2.4. Именование

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

щейся в UNIX. Файлы группируются в модули, именуемые томами (volumes).

Том соответствует области диска в UNIX (то есть в реальной файловой системе),

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

ву в общем пространстве имен, которое образуют серверы

Vice.

Обычно том ассо-

циируется с коллекцией файлов одного пользователя. Примерами томов являют-

ся коллекции разделяемых двоичных, или исходных, файлов и

т.

п. Как и области

дисков, тома могут монтироваться.

Тома важны для нас по двум причинам. Во-первых, они образуют базовую

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

пространства имен производится путем монтирования томов в монтажных точ-

ках. Монтажная точка в Coda

—

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

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

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

клиент может смонтировать только корень тома). Вторая причина важности то-

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

ров.

К этому аспекту томов мы позже вернемся.

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

пересекать несколько монтажных точек. Другими словами, полное имя часто со-

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

именования файловый сервер Vice возвращает в процесс Venus информацию

о монтировании, полученную в процессе разрешения имени. Эта информация по-

зволяет Venus при необходимости автоматически монтировать тома в простран-

ство имен клиента. Этот механизм схож с пересечением монтажных точек, кото-

рое поддерживается в NFS версии 4.

Важно отметить, что когда том общего пространства адресов монтируется

в пространство имен клиента, Venus следует структуре общего пространства имен.

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

имеет доступ к общему пространству имен через вложенный каталог /afs. При

монтировании тома каждый процесс Venus гарантирует, что граф именования,

присоединенный корнем к /afs, является подграфом полного пространства имен,

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

рис.

10.18.

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

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

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

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

Идентификаторы файлов

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

рована и разбросана по нескольким серверам Vice, то резко повышается важность

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

следить его истинное местоположение с одновременной поддержкой репликации

и прозрачности локализации.

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

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

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

Клиент В

Экспортируемый каталог

монтируется клиенту

Экспортируемый каталог

монтируется клиенту

Сеть

Рис. 10,18. Клиенты

Coda имеют

доступ

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

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

том может быть реплицирован на нескольких серверах. По этой причине в Coda

делается различие между логическими и физическими томами. Логический том

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

ветствующий

идентификатор реплицированного

тома {Replicated

Volume

Identi-

fier, RVID), RVID

—

это не зависящий от местоположения и репликации иденти-

фикатор тома. С одним и тем же RVID может ассоциироваться множество реплик.

Каждый физический том имеет

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

тома (Volume Identifier, VID),

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

тоположения.

Подход, принятый в Coda, состоит в том, чтобы присваивать каждому файлу

96-битный идентификатор файла. Идентификатор файла состоит из двух частей

(рис.

10.19).

Первая часть представляет собой 32-битный идентификатор RVID логичес-

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

сначала передает RVID из идентификатора файла в базу

данных репликации

то-

мов

(volume replication

database),

которая возвращает список идентификаторов VID,

соответствующих указанному идентификатору RVID. Получив VID, клиент ищет

сервер, на котором находится рабочая реплика логического тома. Этот поиск

производится путем посылки VID в базу данных размещения томов (volume

location

database),

которая возвращает текущее местоположение конкретного фи-

зического тома.

Вторая часть идентификатора файла представляет собой 64-битный дескрип-

тор файла, который уникально идентифицирует файл внутри тома. В действи-

тельности он соответствует идентификатору узла индекса в VFS. Этот вир-

туальный узел (vnode), как его называют, соответствует понятию inode в UNIX-

системах.