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

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

10.4.

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

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

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

ми,

в NFS версии 4 клиенты могут считаться скорее «толстыми», чем «тонкими».

Те же самые рассуждения годятся и для процесса Venus, представляющего

собой клиентскую часть систем AFS и Coda. Venus выполняет на стороне клиен-

та массу работы. Он, в частности, целиком берет на себя кэширование файлов,

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

В противоположность ему разработчики Plan 9 постарались сохранить клиен-

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

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

Тем не менее клиентские процессы могут кэшировать файлы, хотя система про-

должает отлично работать и при отсутствии какого-либо кэширования.

Клиентские процессы в xFS также можно считать «толстыми», если принять во

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

—

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

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

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

клиентом Plan 9 и усложненным вариантом клиента Coda. Клиент SFS

—

это

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

бенностей своего локального состояния. Он просто предоставляет доступ к уда-

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

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

Серверы разных систем очень отличаются друг от друга. Только Coda и xFS

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

лицированные файлы или, в случае xFS, отвечать за нарезку файлов. В NFS,

Plan 9 и SFS, в сущности, предполагается, что файл расположен на одном нереп-

лицируемом сервере.

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

За исключением SFS, рассмотренные примеры файловых систем поддерживают

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

как это делается и в системах UNIX. Монтирование производится дроблением

каталогов, как в NFS (а также и в SFS), или при помош.и файловой системы, как

в Coda, Plan 9 и xFS (которая унаследовала этот способ от LFS и Zebra).

Более интересен подход к организации пространства имен. Существует два

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

венное пространство имен. Так построены системы NFS и Plan 9. Недостаток

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

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

возникают сложности. Чтобы снизить остроту некоторых из этих проблем, часть

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

Второй подход состоит в том, чтобы создать глобальное общее пространство

имен, как это сделано в Coda, xFS и SFS. Во всех этих системах каждый поль-

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

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

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

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

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

ентов SFS.

Имеются также различия и в ссылках на файлы. За исключением Coda и xFS

ни одна из систем не использует глобально уникальные ссылки на файлы. В Coda

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

—

это не зависящий от ме-

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

—

дескриптор, который одно-

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

бально уникальное имя.

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

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

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

дексного узла. Эти ссылки на файл глобально уникальны.

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

стью которой являются эти файлы (как в NFS и SFS), или для сервера, отвечаю-

щего за эти файлы, как в случае Plan 9. В результате для поиска файла эти систе-

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

10.4.5. Синхронизация

Наиболее важный аспект синхронизации при обсуждении распределенных фай-

ловых систем

—

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

Грубо говоря, в NFS принята семантика сеансов, то есть на сервере запоминаются

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

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

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

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

обновлений, который затем должен быть разрешен.

Поскольку все операции с файлами в Plan 9 осуществляются на файловом

сервере. Plan 9 поддерживает семантику UNIX, Аналогичная семантика поддер-

живается также и в системе xFS при помощи встроенного в нее механизма ко-

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

имеет право выполнять операции записи.

Семантика совместного использования файлов в SFS не определена. Однако

поскольку система SFS в значительной степени основана на протоколах NFS, она

как минимум поддерживает семантику сеансов.

10.4.6.

Кэширование и репликация

Все приведенные примеры систем поддерживают кэширование на клиенте. Толь-

ко в Plan 9 используется протокол непротиворечивости кэша сквозной записи,

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

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

са кэша на диск сервера выполнить несколько операций записи. В NFS (а также

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

в SFS) протокол поддержания целостности кэша в значительной степени опреде-

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

сервер при закрытии файла.

XFS кэширует блоки данных файлов. Plan 9 кэширует данные с переменным

шагом, в зависимости от характера доступа клиента. NFS (и SFS) отставляют

этот вопрос открытым, хотя можно рассчитывать, что в системе NFS версии 4

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

вания целых файлов. В Coda кэширование целых файлов поддерживается явно,

эта особенность унаследована еще от AFS.

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

ем Coda, в основном не реализована. NFS версии 4 предоставляет минимальную

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

FS_LOCATIONS.

В NFS вер-

сии 3 репликация не реализована.

Plan 9 также не предоставляет явной поддержки репликации. В xFS поддер-

живаются некоторые возможности репликации через нарезку. В Coda явно учи-

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

непротиворечивости используется протокол ROW А.

10.4.7.

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

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

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

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

тики «максимум однажды». В Coda для повышения доступности применяется

кэширование и репликация. В xFS используется нарезка, которая способна защи-

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

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

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

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

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

средств восстановления при дроблении сети. Такая же методика применяется и для

повторного включения восстановившегося после сбоя сервера в группу серверов.

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

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

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

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

ния не реализована.

10.4.8.

Защита

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

зацией. Для организации защищенных каналов NFS предоставляет стандартный

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

ществующих систем защиты. До момента реализации NFS об используемом ме-

ханизме можно не заботиться.

694

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

Coda и Plan 9 предоставляют защищенные каналы, причем их реализация в обе-

их системах основана на протоколе аутентификации Нидхема—Шредера, который

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

ключи.

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

ния защиты системы возлагается на разные машины. Поэтому для доступа к сис-

теме xFS с не доверенных машин необходимо предпринимать специальные меры.

В настоящее время для этого применяют защищенные вызовы RPC, лежащие

в основе NFS версии 3.

В SFS имеется собственный способ работы с защищенными каналами. В сущ-

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

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

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

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

ся специальные агенты.

NFS версии 4 поддерживает обширный список операций контроля доступа.

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

му можно добиться большой гибкости. Coda использует другой подход, осущест-

вляя контроль доступа только по отношению к операциям над каталогами. Plan 9

и xFS в основном поддерживают стандартный подход UNIX, разделяя операции

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

доступа от NFS версии 3.

Подведем итог. В табл. 10.14 сравниваются различные аспекты пяти распре-

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

Таблица 10.14. Сравнение систем NFS, Coda, Plan 9, xFS и SFS

Аспект

Цели

создания

Модель

доступа

Связь

Клиентский

процесс

Группы

серверов

Дробность

монтиро-

вания

Простран-

ство имен

NFS

Прозрач-

ность

доступа

Удаленный

доступ

RPC

Тонкий

и толстый

Не

поддержи-

ваются

Каталог

Клиент

Coda

Высокая

доступность

Загрузки-

выгрузки

RPC

Толстый

Поддержи-

ваются

Файловая

система

Глобальное

простран-

ство

Plan 9

Унификация

Удаленный

доступ

Специальная

связь

Тонкий

Не

поддержи-

ваются

Файловая

система

Простран-

ство имен

процесса

XFS

Бессервер-

ная система

На основе

журнала

Активные

сообщения

Толстый

Поддержи-

ваются

Файловая

система

Глобальное

простран-

ство

SFS

Масштаби-

руемая

безопас-

ность

Удаленный

RPC

Средний

Не

поддержи-

ваются

Каталог

Глобальное

простран-

ство

10.5.

Итоги

695

Аспект

Область

видимости

идентифика-

тора файла

Семантика

совместного

использо-

вания

Элемент

кэширова-

ния

Непротиво-

речивость

кэша

Репликация

Отказоустой-

чивость

Восстанов-

ление

Защищен-

ные каналы

Контроль

доступа

NFS

Файловый

сервер

Семантика

сеансов

Файл (версии

Кэш

обратной

записи

Минималь-

ная

Надежная

связь

На основе

клиента

Существую-

щие

механизмы

Множество

операций

Coda

Глобальная

видимость

Семантика

транзакций

Файл

Кэш

обратной

записи

ROWA

Репликация и

кэширо-

вание

Повторная

интеграция

Протокол

Нидхема—

Шредера

Операции

с каталогами

Plan 9

Сервер

Семантика

UNIX

Файл

Кэш

сквозной

записи

Отсутствует

Надежная

связь

Не

определено

Протокол

Нидхема—

Шредера

На основе

UNIX

XFS

Глобальная

видимость

Семантика

UNIX

Блок

Кэш

обратной

записи

Нарезка

Контроль-

ные точки

и журнал

Имена путей

отсутствуют

На основе

UNIX

SFS

Файловая

система

Не

определено

Не

определено

Кэш

обратной

записи

Отсутствует

Надежная

связь

Не

определено

Самосерти-

фицирую-

щиеся имена

путей

На основе

NFS

10.5.

Итоги

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

дигм распределенных систем. Они строятся в основном в соответствии с моделью

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

для получения необходимой масштабируемости. Кэширование и репликация тре-

буются также для повышения доступности этих систем.

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

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

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

файлов (семантику UNIX) очень трудно эффективно реализовать в распределен-

ных системах. NFS поддерживает ее «урезанный» вариант, именуемый семанти-

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

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

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

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

Семантика транзакций в Coda не обладает всеми свойствами ACID настоящих

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

транзакций. В том случае, если управление всеми операциями осуществляет сер-

вер,

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

в этом случае останется под вопросом.

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

системы обычно позволяют клиентам кэшировать файлы целиком. Кэширование

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

хранять также и большие фрагменты файлов. После того как файл открыт и пере-

дан (частично) клиенту, все остальные операции могут осуществляться локально.

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

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

нации с протоколом кэша обратной записи.

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

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

вень RPC, так что все операции представляют собой вызовы RFC, адресованные

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

подход используется в NFS, Coda и SFS. Желательно, чтобы уровень RFC под-

держивал семантику обращений «максимум однажды», в противном случае эта

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

мы,

как в случае NFS.

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

держивает работу в автономном (отключенном от сети) режиме. Если гарантиро-

вать,

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

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

он временно отключен от файлового сервера. Для поддержки такого режима ра-

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

копление нелегко реализовать, тем не менее было показано, что его эффективная

реализация вполне возможна.

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

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

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

в связке с ней разнообразные системы защиты, например Kerberos. В противопо-

ложность ей Coda и Flan 9 обладают собственными механизмами защиты.

Аутентификация в этих системах осуществляется при помощи защищенных

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

фикации Нидхема—Шредера. SFS отличается от них тем, что информация об

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

управление ключами в крупномасштабных системах. На практике SFS распро-

страняет ключ, включая его в имя файла. Специальные средства помогают де-

лать это прозрачно для клиента.

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

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

версии 3, не хранил информацию о состояния?

10.5.

Итоги 697

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

в этом случае способ имитации пространства имен?

Укажите простое расширение операции NFS lookup, которое позволяло бы

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

талоги, монтируемые к другому серверу.

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

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

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

вательского уровня в системе UNIX.

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

символические ссылки, как было описано в этой главе, сложнее обеспечить

прозрачность монтирования. Почему?

6. Представьте, что текущее состояние запрета на доступ к файлу в NFS —

WRITE.

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

вает файл, а затем запрашивает блокировку на чтение?

Если рассматривать согласованность кэшей, о которой мы говорили в главе 6,

какой тип протокола согласованности кэшей реализован в NFS?

8. Реализует ли NFS поэлементную непротиворечивость? А свободную непро-

тиворечивость?

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

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

почему.

10.

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

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

на сервер немедленно?

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

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

12.

Какие меры защиты могут быть задействованы в NFS, чтобы предотвратить

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

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

стии?

13.

На рис. 10.14 предполагается, что клиент имеет абсолютно прозрачный дос-

туп к Vice. Насколько это истинно на самом деле?

14.

Благодаря побочным эффектам механизм RPC2 можно использовать для об-

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

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

над RPC.

15.

Какие изменения в базе данных репликации томов и базе данных размещения

томов Coda требуется сделать при перемещении физического тома с сервера А

на сервер В?

16.

Какую семантику вызовов использует RPC2 при наличии отказов?

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

17.

Опишите, как Coda разрешает конфликты чтения-записи в файле, который

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

18.

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

входе в систему Coda? Если да, то где должно происходить шифрование?

19.

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

ля доступа?

20.

Имеет ли смысл для сервера Vice предоставлять в файле только разрешение

WRITE? (Подсказка: подумайте, что произойдет, когда клиент откроет файл.)

21.

Могут ли объединенные каталоги в Plan 9 заменить переменную окружения

в UNIX-системах?

22.

Может ли система Plan 9 успешно использоваться в качестве глобальной?

23.

Каково основное преимущество групп нарезки в xFS по сравнению с распре-

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

24.

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

можно гарантировать, что он не имеет дело с подставным сервером?

Глава 11

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

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

11.1.

World Wide Web

11.2.

Lotus Notes

11.3.

Сравнение WWW и Lotus Notes

11.4.

Итоги

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

так и распределенных систем, стало появление Всемирной паутины (World Wide

Web).

Сила Web заключается в относительной простоте парадигмы: все вокруг

—

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

тов,

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

ние о документах как простом и мощном средстве обмена информацией. Модель

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

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

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

Web в настоящее время является наиболее важной распределенной системой

документов и, похоже, останется таковой в ближайшем будущем. Фактически,

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

Web

—

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

Другой важной системой документов, появившейся раньше Web, является

Lotus Notes. В противоположность Web в основе системы Notes лежат скорее не

файлы, а базы данных. В настоящее время система Lotus Notes остается доста-

точно популярной и часто интегрируется в технологию Web, предоставляя сред-

ства разработки web-служб. Lotus Notes будет вторым примером распределенной

системы документов, которую мы обсудим в этой главе. Завершается глава раз-

делом, в котором мы сравним эти две системы.

11.1.

World Wide Web

World Wide Web (WWW) можно считать гигантской распределенной системой,

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

700 Глава 11. Распределенные системы документов

ров.

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

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

Среда Web родилась в качестве проекта Европейской физической лаборато-

рии элементарных частиц в Женеве и предназначалась для организации доступа

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

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

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

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

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

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

ниях. Все, что было необходимо для создания документа,

—

это организация ссы-

лок на другие документы [43].

Среда Web постепенно росла благодаря появлению во всем мире сайтов, ни-

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

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

ля,

в частности интерфейса программы Mosaic

[474].

В программе Mosaic для

получения документа было достаточно всего лишь одного щелчка мыши. Доку-

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

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

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

прозрачным.

С 1994 года относящиеся к Web разработки инициируются и направляются

в первую очередь консорциумом World Wide Web, совместным органом CERN

и M.I.T. Этот консорциум отвечает за стандартизацию протоколов, улучшения

межоперационного взаимодействия и дальнейший рост возможностей Web. Его

домашняя страница находится по адресу http://www.w3.org/.

11.1.1.www

www

—

это, в сущности, гигантская система с архитектурой клиент-сервер

и миллионами серверов по всему миру. Каждый сервер поддерживает набор до-

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

кументы могут генерироваться по запросу). Сервер принимает запросы на выда-

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

на сохранение новых документов.

Наиболее простой способ сослаться на документ

—

унифицированный указа-

тель ресурса

(Uniform Resource Locator, URL). URL-адрес подобен межопераци-

онной ссылке на объект (IOR) в CORBA или контактному адресу в Globe. Он

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

вания в исходный документ DNS-имени соответствующего сервера вместе с име-

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

локальной файловой системе. Кроме того, URL определяет протокол прикладно-

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

ких протоколов существует несколько.