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

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

9.5. Итоги 621

Репликация в CORBA поддерживается только в плане отказоустойчивости.

DCOM вообще не поддерживает репликацию, разработчик приложения должен

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

явную программную репликацию. В Globe репликация поддерживается каждым

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

ет конкретный протокол репликации объекта, частью которого он является.

С репликацией тесно связаны вопросы отказоустойчивости. CORBA обеспе-

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

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

устойчивость поддерживается при помощи транзакций (автоматических). Globe

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

становления не имеет.

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

ет средства защиты. CORBA предлагает полностью защищенную архитектуру,

которая позволяет обеспечить индивидуальную защиту каждого объекта. В DCOM

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

таким как Kerberos. В Globe защита также определяется для каждого объекта

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

ществующим службам защиты. Вопросы защиты в Globe продолжают исследо-

ваться и в настоящее время.

Вопросы и задания

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

ния интерфейсов (IDL)?

Когда могут пригодр1Ться механизмы динамического обращения CORBA? При-

ведите пример.

Какой из шести видов связи, обсуждавшихся в разделе 2.4, соответствует мо-

дели обращений, принятой в CORBA?

Опишите простой протокол, реализующий семантику обращений к объектам

«максимум однажды».

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

ные объекты в CORBA были сохранными?

6. В сообщении Request протокола GIOP ссылка на объект и имя метода явля-

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

венно в тело сообщения?

Поддерживает ли CORBA правило обращений «один поток выполнения

—

один объект», которое мы рассматривали в главе 3?

8. Пусть имеется две системы CORBA, каждая из которых имеет свою службу

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

объединенную службу именования.

9. Мы утверждали, что при привязке к объекту CORBA клиентский брокер ORB

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

ты.

Как клиентскрш брокер ORB может узнать о существовании этих служб?

622 Глава 9. Распределенные системы объектов

10.

Если ORB системы CORBA использует несколько перехватчиков, не имеющих

отношение к защите, насколько важен порядок вызова этих перехватчиков?

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

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

12.

Если сравнивать DCOM с CORBA, какой маршалинг обеспечивает CORBA,

стандартный или пользовательский? Дайте подробный ответ.

13.

Пусть в DCOM имеется метод ш, содержащий интерфейс X, который в каче-

стве входного параметра получает указатель на интерфейс У. Объясните, что

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

реализацию заместителя X, обратится к т.

14.

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

получивший «упакованный» (путем маршалинга) заместитель, работал на ма-

шине того же типа, что и процесс-отправитель?

15.

Опишите алгоритм переноса объекта DCOM на другой сервер.

16.

Нарушает JIT-активизация представление об объекте или соответствует это-

му представлению?

17.

Опишите, что произойдет, если два клиента с разных машин задействуют один

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

создано экземпляров объекта, один или два?

18.

Какой существует очевидный способ реализации событий в Globe, не нару-

шающий принципа пассивности объектов?

19.

Приведите пример, когда использование (невнимательное) механизмов обрат-

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

20.

В CORBA узлы графа имен, то есть каталоги, также считаются объектами.

Имеет ли смысл и в Globe считать каталоги распределенными разделяемыми

объектами?

21.

Предположим, что на сервер объектов Globe установлен локальный сохран-

ный объект. Предположим также, что этот объект имеет контактный адрес.

Должен ли сохраняться этот адрес при отключении сервера?

22.

ЭТ0Р1

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

печения защиты в Globe. Имело бы смысл шифрование талона каким-нибудь

другим общим ключом (вместо ключа KSJGT) объекта и службы предоставле-

ния талонов?

Глава 10

Распределенные

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

10.1.

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

10.2.

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

10.3.

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

10.4.

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

10.5.

Итоги

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

—

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

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

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

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

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

и защищенность. По этой причине они нередко используются в качестве базового

уровня распределенных систем и приложений. В этой главе мы рассмотрим рас-

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

тем общего назначения.

Мы детально изучим две совершенно разные распределенные файловые CPIC-

темы. В качестве первого примера мы рассмотрим сетевую файловую систему

NFS компании Sun Microsystem, имеющую гигантское число установок и в на-

стоящее время в форме версий для Интернета постепенно разрастающуюся до

глобальных масштабов. Большинство реализаций NFS основаны на специфика-

ции версии 3. Недавно была описана и выпущена пробная редакция версии 4.

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

Coda

—

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

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

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

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

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

лей (то есть пользователей переносных компьютеров), которые вынуждены час-

то отключаться от сети.

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

Также мы кратко рассмотрим еще три системы. Plan 9

—

это распределенная

система, в которой все ресурсы рассматриваются как файлы. В этом смысле ее

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

мы рассмотрим,

—

это xFS, характерная тем, что в ней отсутствуют серверы, а фай-

ловую систему реализуют клиенты. И наконец, мы познакомимся с ситемой SFS,

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

руемой системой защиты.

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

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

лизуется каждый из них на примерах существующих систем. В заключение мы

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

10.1.

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

компании Sun

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

системы {Network File

System,

NFS) компании Sun Microsystem. Система NFS из-

начально была разработана Sun для использования в рабочих станциях на базе

UNIX, но затем была реализована и на многих других платформах. Основная

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

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

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

вая система

—

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

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

нящимся на сервере файлам. Такой подход позволяет разнородным наборам

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

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

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

ла пределов компании Sun. Вторая версия NFS была встроена в операционную

систему SunOS 2.0 и описана в

[395].

Это произошло за несколько лет до выпус-

ка версии 3

[346].

Обе версии подробно описаны в [80].

NFS версии 3 в настоящее время претерпевает серьезные изменения, которые

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

[413].

Изменения должны привести

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

что превратит NFS в настоящую глобальную файловую систему. В систему были

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

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

ляя основное внимание версиям 3 и 4.

10.1.1.

Обзор

Как мы уже говорили, NFS

—

это не столько файловая система, сколько набор

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

10.1.

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

файловой системы. В этом смысле NFS можно сравнить с системой CORBA, ко-

торая, в сущности, также существует только в виде описаний. Как и CORE

А,

NFS

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

онных систем на разных машинах. Протоколы NFS разрабатывались таким обра-

зом,

чтобы их разнообразные реализации

легкостью могли работать совместно.

NFS Architecture

Модель, лежащая в основе NFS,

—

это удаленная файловая служба

{remote

file

service).

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

ме,

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

домлены об истинном местоположении файлов. Вместо этого им предоставляет-

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

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

ны разнообразные операции с файлами, но за реализацию этих операций отвеча-

ет сервер. Поэтому такая модель называется также

моделью удаленного

доступа

{remote access

model). Она показана на рис.

10.1,

а.

Клиент

Сервер

1 1

Запрос от клиента \

на доступ Файл постоянно

к удаленному находится

файлу на сервере

Файл перемещается к клиенту

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

Доступ

осуществляется

на клиенте

3. Когда клиент

заканчивает работу,

файл возвращается

на сервер

а б

Рис. 10.1. Модель удаленного доступа (а). Модель загрузки-выгрузки (б)

В противоположность ей в

модели загрузки-выгрузки {upload/download

model)

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

показано на рис. 10.1, б. Когда клиент заканчивает работать с файлом, файл вы-

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

Таким образом используется Интернет-служба FTP

—

клиент загружает файл

целиком, вносит в него изменения, а затем возвращает на место.

Система NFS реализована для многих платформ, хотя версии для UNIX пре-

обладают. Фактически для всех современных UNIX-систем NFS реализуется

в соответствии с многоуровневой архитектурой, показанной на рис. 10.2.

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

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

темы UNIX заменяется интерфейсом виртуальной файловой системы {Virtual

File

System,

VFS), который в настоящее время является де-факто стандартом ин-

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

[237].

Операции с интерфейсом VFS

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

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

поненту, известному под названием клиента NFS (NFS client) и отвечающему за

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

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

вов RPC. Клиент NFS реализует операции файловой системы NFS в форме

запросов RPC, посылаемых серверу. Отметим, что набор операций, который пре-

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

ентом NFS. Основная идея VFS состоит в том, чтобы замаскировать различия

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

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

Уровень системных

вызовов

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

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

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

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

Клиент NFS

Заглушка RPC

клиента

Уровень системных

вызовов

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

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

Сервер NFS

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

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

Заглушка RPC

сервера

Сеть

Рис. 10.2. Базовая архитектура NFS для UNIX-систем

Подобным же образом организован и сервер. Сервер NFS отвечает за обра-

ботку приходящих запросов клиентов. Заглушка извлекает запросы RPC из со-

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

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

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

Важное достоинство этой схемы заключается в том, что NFS практически не

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

вую систему

—

UNIX, Windows 2000 или даже архаичную MS-DOS

—

реализует

операционная система клиента или сервера. Единственное, что важно,

—

чтобы

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

поддерживает NFS. Так, например, система MS-DOS с ее короткими именами

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

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

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

UNIX-систем. Файлы трактуются как неинтерпретируемые последовательности

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

представляют собой каталоги и файлы. NFS поддерживает жесткие ссылки, а так

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

10.1.

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

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

ных

дескрипторов

файлов {file

handle),

о которых мы далее поговорим подробно.

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

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

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

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

В табл. 10.1 сведены воедино общие операции над файлами, поддерживаемые,

соответственно, NFS версий 3 и 4. Операция create используется для создания

файлов, но имеет разный смысл в версиях 3 и 4. В версии 3 эта операция служит

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

гой операции. Операция 11пк позволяет создавать жесткие ссылки, а при помощи

операции

syml 1 пк

создаются символические ссылки. Операция

mkdi г

служит для со-

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

сокеты и именованные каналы, создаются операцией mknod.

Таблица 10.1. Неполный список файловых операций в NFS

Операция

V. 3

V.4

Описание

create

link

symlink

mkdir

mknod

rename

remove

rmdir

open

lookup

readdir

readlink

getattr

setattr

read

write

Да

Нет

Да

Нет

Да

Нет

Да

Нет

Да

Нет

Да

Создать обычный файл

Создать нестандартный файл

Создать жесткую ссылку на файл

Создать символическую ссылку на файл

Создать вложенный каталог в текущем

каталоге

Создать специальный файл

Изменить имя файла

Удалить файл из файловой системы

Удалить пустой вложенный каталог

из каталога

Открыть файл

Закрыть файл

Найти файл по имени файла

Прочитать элементы в каталоге

Прочитать путь к файлу, записанный

в символической ссылке

Получить значение атрибута файла

Установить значение одного или нескольких

атрибутов файла

Прочитать данные, содержащиеся в файле

Записать данные в файл

В версии 4 картина совершенно иная. В новой версии операция create ис-

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

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

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

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

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

лами, принятые в прежних версиях. Вплоть до версии 4 система NFS строилась

так, что ее файловые серверы не сохраняли информацию о состоянии. По причи-

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

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

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

Операция rename используется для изменения имени существующего файла.

Файлы удаляются при помощи операции remove. В версир! 4 эта операция ис-

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

ния вложенных каталогов существовала отдельная операцрш rmd1r. Файлы уда-

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

единицу. Если число ссылок падает до нуля, файл можно уничтожить.

Версия 4 позволяет клиентам открывать и закрывать обычные файлы. От-

крытие несуществующего файла приводит к его созданию. Для открытия файла

клиент указывает его имя, а также те или иные значения атрибутов. Так, напри-

мер,

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

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

ра файла. Этот дескриптор используется также и для закрытия файла (операция

close).

При помощи операции close клиент уведомляет сервер, что доступ к фай-

лу ему больше не нужен. Сервер, в свою очередь, может сбросить информацию

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

этому файлу.

Операция lookup используется для получения дескриптора файла по заданно-

му полному пути к нему. В NFS версии 3 операция lookup не разрешала имена за

монтажной точкой (напомним, что, как мы говорили в главе 4, монтажная точ-

ка

—

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

ный каталог в чужом пространстве имен). Так, предположим, что имя /remote/vu

соответствует монтажной точке в графе имен. При разрешении имени /remote/

vu/nnbox операция lookup в NFS версии 3 возвращает дескриптор файла монтаж-

ной точки /remote/vu вместе с остатком полного имени (то есть mbox). После

этого клиент должен был явно смонтировать файловую систему, необходимую

для завершения поиска имени. Файловая система в таком контексте

—

это набор

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

в виде логического устройства с блочной структурой данных [117, 450].

В версии 4 все стало значительно проще. Теперь lookup в состоянии разре-

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

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

смонтирована в соответствующую монтажную точку. Клиент в состоянии обна-

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

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

Для чтения элементов каталога существует отдельная операция readdl

г,

кото-

рая возвращает список пар {имя,

дескриптор

файла) вместе со значениями атри-

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

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

использовано при следующем вызове readdir для чтения следующей порции эле-

ментов.

10.1.

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

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

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

тем можно разрешить обычным образом. Отметим, что операция поиска не может

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

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

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

решения имен.

Файлы имеют различные атрибуты. В способах работы с атрибутами файлов

состоит еще одно серьезное различие между NFS версий 3 и 4. Подробнее о нем

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

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

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

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

считывать и записывать при помощи операций getattr и setattr соответственно.

И, наконец, операции чтения данных из файла и записи данных в файл. Чте-

ние данных производится при помощи операции read. Клиент определяет смеще-

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

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

о достижении конца файла).

Запись данных в файл производится при помощи операции write. Клиент

вновь определяет позицию в файле, с которой должна начаться запись, число за-

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

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

ждали устойчивые хранилища в главе 7). Серверы NFS должны поддерживать

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

же отказы операционной системы и аппаратного обеспечения.

10.1.2.

Связь

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

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

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

операционной системы Windows, с файловым сервером UNIX. Эта независи-

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

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

ными платформами

сетями.

В NFS все взаимодействие между клиентом и сервером происходит в соответ-

ствии с протоколом RPC для

открытых сетевых вычислений

(Open

Network

Com-

puting

RPC,

ONC RPC), формально определенным в [430] вместе со стандартами

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

[431].

Протокол ONC RPC подобен

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

и практическое использование описаны в [69].

Все операции NFS могут быть реализованы в виде вызова одиночной удален-

ной процедуры на файловом сервере. На самом деле до появления NFS версии 4

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

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

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

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

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

на чтение, как это показано на рис. 10.3, а.

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

) Поиск имени

Чтение данных

из файла

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

LOOKUP

OPEN

READ

Время

I Поиск имени

' Открытие файл

; Чтение данных

из файла

Рис. 10.3. Чтение данных из файла в NFS версии 3 (а). Чтение данных с использованием

составной процедуры в версии 4 (б)

Такой подход требовал успешного выполнения двух вызовов RPC. Его недос-

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

чае ожидание второго вызова RPC может привести к резкому падению произво-

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

составные

процедуры

{compound

procedures),

в которых несколько вызовов RPC

могут быть объединены в один запрос, как показано на рис. 10.3, б.

В нашем примере клиент объединяет запросы на поиск и чтение в один вызов

RFC.

В случае версии 4 необходимо также открыть файл перед тем, как читать

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

open, после чего сервер продолжает работу, совершая операцию read. В результа-

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

щениями.

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

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

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

мер для разрешения возможных конфликтов не предпринимается. Если опера-

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

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

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

тия файла не делается.

10.1.3.

Процессы

NFS

—

это традиционная система клиент-сервер, в которой клиент для выполне-

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

ционных специфических особенностей NFS по сравнению с другими распре-