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

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

10.2.

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

671

В том случае, когда файл отображается

на

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

гут осуществлять операции

данными этого файла

режиме транзакций.

RVM

ничего

не

знает

структурах данных. Поэтому данные

транзакции передаются

приложению явно,

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

ла. Все операции, которые производятся над

ЭТИМР!

данными

памяти машины,

записываются

отдельный журнал с упреждающей записью. Этот журнал следу-

ет держать

устойчивом хранилище. Отметим,

что

благодаря относительно

ма-

лым размерам журнала

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

питанием

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

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

10.2.8.

Защита

Система Coda унаследовала архитектуру защиты

от

AFS. В AFS система защиты

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

организацией защищенного кана-

ла между клиентом

сервером

использованием защищенных вызовов

RPC

и системной аутентификации. Вторая часть относится

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

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

эти

части.

Защищенные каналы

Для организации защищенного канала между клиентом

сервером Coda исполь-

зует криптосистему

закрытым ключом. Протокол основан

на

протоколе аутен-

тификации Нидхема—Шредера, который

мы

рассматривали

главе

Говоря

вкратце, сначала пользователь должен получить от сервера аутентификации (AS)

специальный маркер,

или

токен. Этот маркер несколько похож

на

талон, выда-

ваемый

протоколе Нидхема—Шредера,

том смысле, что он тоже используется

для организации защищенного канала

сервером.

Все взаимодействие между клиентом

сервером основано

на

механизме

за-

щищенных вызовов

RPC (рис.

10.24). Если Алиса (клиент) хочет пообщаться

с Бобом (сервером),

она

посылает Бобу свои данные вместе

вызовом

RA,

кото-

рый зашифрован общим для Алисы

Боба секретным ключом

КА,В-

ЭТО

сообще-

ние обозначено номером

го

1Г

А.КД,В(РА)

KA.B(RA+1.RB)

KA.B(RB+1)

Кл

jKr.) L

'^A.Bv'^s/

Рис.

10.24. Взаимная аутентификация

RPC2

Боб,

расшифровав сообщение

отвечает

на

него

возвращает /?л

1»

пока-

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

значит,

он

—

действи-

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

тельно Боб. Еще он возвращает вызов

(как часть сообщения 2), который Али-

са расшифровывает и возвращает ему обратно (сообщение 3). После взаимной

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

ваться при последующем взаимодействии между Алисой и Бобом.

Защищенные вызовы RPC в Coda требуются только для организации защи-

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

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

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

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

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

Маркер

ауте}1тификации

{authentication token) аналогичен талону Kerberos.

Он содержит идентификатор получающего его процесса, идентификатор марке-

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

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

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

—

это маркер,

К^псе

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

Vice,

а Я

—

хэш-функция, то [Г, Я

{К^гсе,

Т)]

—

криптографически удостоверен-

ная версия

Т.

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

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

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

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

чить от сервера AS маркеры аутентификации. При этом она переходит на защи-

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

KA,AS^

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

аутентификации по ранее описанному механизму. AS возвращает ей два маркера

аутентификации.

Свободный маркер {clear token)

СТ= [Л,

TID,

Ks,

Tetany Tend]

иден-

тифицирует Алису и содержит идентификатор маркера

TID,

сеансовый ключ Ks

и две отметки времени,

Tstan

Tend^

определяющие срок действия маркера. Кроме

того,

AS посылает

секретный

маркер

{secret

token) ST=

К^ке{[СТ\*Кгпсе),

который

представляет собой свободный маркер

СТ,

подписанный общим для всех серве-

ров Vice секретным ключом

K^^ice

и зашифрованный тем же самым ключом.

Сервер Vice в состоянии расшифровать маркер ST

извлечь из него как мар-

кер

СТ,

так и сеансовый ключ

Ks.

Кроме того, поскольку ключ

К^се

известен толь-

ко серверам Vice, такой сервер может проверить целостность и с легкостью об-

наружить подмену свободного маркера СТ (подобная проверка требует знания

ключа

K^ice)-

Когда бы Алиса ни создавала защищенный канал с сервером Vice, для иден-

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

рис.

10.25. Для шифрования запроса

RA,

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

ся сеансовый ключ

Ks,

полученный ранее от AS в свободном маркере.

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

ретный ключ

Kz^ice,

и получает СТ. После этого он ищет ключ Ks, который далее

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

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

СТ и

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

вителен.

10.2.

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

673

Kvice(ST).

KS(RA)

KS(RA+1.RB) \

KS(RB+1)

] Ks(Ks2)

Рис. 10.25. Организация защищенного канала в Coda между клиентом (Venus)

и сервером Vice

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

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

Аутентификацию провести невозможно, поскольку контакта с сервером нет. В этом

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

клиент восстанавливает соединение с сервером (серверами), аутентификация про-

изводится в состоянии

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

(см. рис. 10.23).

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

Обсудим кратко схему ограничения доступа в Coda. Как и в AFS, для гарантии

того,

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

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

серверах Vice списки контроля доступа ведутся только для каталогов, но не для

файлов. Все обычные файлы (то есть исключая вложенные каталоги) в одном

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

Coda подразделяет права доступа по типам операций (табл. 10.11). Отметим,

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

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

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

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

Таблица

10.11.

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

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

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

read

write

lookup

insert

delete

administer

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

Изменение любого файла в каталоге

Определения статуса любого файла

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

Удаление существующего файла

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

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

прав,

которыми обладают пользователи или группы, Coda также поддерживает

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

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

ный пользователь не

имеет

некоторых прав доступа. Такой подход кажется весь-

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

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

10.3.

Другие распределенные

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

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

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

хожи на NFS или Coda. В этом разделе мы кратко рассмотрим три системы, каж-

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

Сначала мы обсудим систему Plan 9, в которой все ресурсы трактуются как фай-

лы.

XFS являет собой пример файловой системы без серверов. Последней мы

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

в имена файлов.

В отличие от тех описаний, которые мы делали для NFS и Coda, для обсуж-

даемых в этом разделе систем мы умышленно отбросим множество деталей, а со-

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

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

темам.

10.3.1.

Plan 9

—

ресурсы как файлы

Приблизительно в 80-х годах появилась тенденция к замене централизованных

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

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

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

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

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

централизованных серверов и множества клиентских машин в качестве ответа

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

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

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

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

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

Система задумывалась в основном той же группой людей в Bell Labs, которая

разрабатывала UNIX. Проект был начат в конце 80-х. Большое число современ-

ных локальных распределенных систем построены по принципу относительно

простых клиентов и нескольких мощных серверов. Если обратить внимание на

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

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

вполне актуальной и сейчас. Обзор Plan 9 можно найти в

[353].

Подробная ин-

формация содержится в [42].

10.3.

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

Plan

—

не

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

пределения файлов. Доступ

ко

всем ресурсам системы

(в

том числе

таким,

как

процессы

сетевые интерфейсы) осуществляется единообразно,

использова-

нием характерных

для

файлов синтаксиса

операций.

Эта

идея заимствована

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

но

в Plan

этот подход значительно расширен

выдерживается более последова-

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

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

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

имен,

по

аналогии

подходами, используемыми

NFS.

Для

того чтобы обеспе-

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

Подобный подход

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

архитек-

туре,

показанной на рис. 10.26. Plan 9 состоит из набора серверов, предоставляю-

щих клиентам ресурсы

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

Для

доступа

к ре-

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

свое собственное

пространство имен. Хотя

мы и

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

серверами,

следует отметить, что

Plan 9 эта грань не всегда ощутима. Так, например, серве-

ры

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

свою очередь, клиенты мо-

гут экспортировать свои ресурсы

на

сервер.

Шлюз

Файловый сервер

Сервер CPU

Сетевой

интерфейс

В Интернет

Клиент смонтировал

NS1 и NS2

Клиент Клиент

Рис. 10.26. Общая организация Plan

Связь

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

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

9Р,

ко-

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

на

операции

файлами. Так,

на-

пример, протокол

9Р

содержит операции открытия

закрытия файлов, чтения

записи блоков данных, навигации

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

9Р ра-

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

локальных сетях он исполь-

зует надежный протокол дейтаграмм Internet Link

(IL)

—

надежный протокол

на

основе сообщений, обеспечивающий доставку сообщений

порядке FIFO.

Для

глобальных сетей

9Р

использует TCP.

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

Интересная особенность Plan 9 состоит в способе поддержания связи на уров-

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

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

ход заимствован из UNIX, хотя сетевые интерфейсы в UNIX существуют в виде

файлов и не имеют файловой системы. Отметим, что файловая система в данном

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

жащее все данные и метаданные, составляющие набор файлов. В Plan 9, напри-

мер,

отдельное соединение TCP представляется в виде вложенного каталога, со-

держащего файлы. Именно так оно выглядит в табл. 10.12.

Таблица 10.12. Файлы, соответствующие в Plan 9 одному соединению TCP

Файл Описание

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

data Используется для чтения и записи данных

listen Используется для получения входящих запросов на соединение

local Предоставляет информацию на вызывающей стороне

remote Предоставляет информацию на другом конце соединения

status Предоставляет диагностическую информацию о текущем состоянии

соединения

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

например, для открытия сеанса Telnet на машине с IP-адресом 192.31.231.42

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

«connect 192.31.231.42123» в файл ctl. Получатель должен предварительно запи-

сать в свой файл ctl строку «announce 23», указывая, что он принимает входящие

запросы на сеанс на порт 23.

Файл data используется для обмена данными при помощи обычных операций

read и write. Эти операции имеют стандартную семантику UNIX для операций

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

зывает следующую операцию:

res = wr1te(fd. buf. nbytes);

Здесь fd

—

дескриптор файла, полученный после открытия файла data, buf

—

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

—

число байтов,

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

записаны, возвращается и сохраняется в переменной res.

Файл listen используется для ожидания запроса на установку соединения.

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

ние,

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

запрос, вызов возвращает дескриптор нового файла ctl из созданного каталога

соединения.

Процессы

в Plan 9 существуют разные серверы. Каждый сервер реализует свое иерархиче-

ское пространство имен. Самый простой пример

—

файловый сервер Plan 9, кото-

10.3.

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

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

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

щее набору файлов, хранящихся на нескольких дисках. Логически, как это видно

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

Машина файлового сервера

Кэш

в памяти

Только в WORM есть

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

Дисковый кэш WORM

Рис. 10.27. Файловый сервер Plan 9

Самый нижний уровень образует устройство

однократной записи

множест-

венным чтением {Write-Once

Read-Many,

WORM), представляющее собой хранили-

ще

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

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

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

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

рые играют роль большой системы кэширования устройства WORM. При доступе

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

ния временно, как и при традиционном буферном кэшировании в UNIX-систе-

мах, также сохраняются на диске. Один раз в сутки все изменения записываются

на устройство WORM, которое таким образом реализует ежедневную архива-

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

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

ти,

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

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

ти,

которые время от времени сбрасываются на диск.

Абсолютно другой пример сервера Plan 9

—

сервер для системы работы с ок-

нами 8V2

[354].

Концептуально этот сервер должен предоставлять клиентским

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

Интерфейсы этих устройств похожи на файлы. Устройства не реализуются в ви-

де файлов, но сделаны очень похожими на них. Так, например, программе, рабо-

тающей в окне, принадлежит файл с именем /dev/mouse для хранения текущего по-

ложения мыши в окне. Каждое окно имеет свою версию файла /dev/mouse. Ввод

с клавиатуры каждая программа читает из файла по имени /dev/cons, также от-

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

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

Подход, используемый в Plan 9, представляет собой интересную альтернати-

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

шине экспортировать локальное адресное пространство или его часть. На самом

деле этот сервер принимает сообщения 9Р и транслирует их в локальные систем-

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

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

интерфейсов, которые доступны из локального каталога /net. Пусть /net/inet обозна-

чает сетевой интерфейс низкоуровневого доступа к внешней сети. Если М экс-

портирует /net, клиент может использовать М в качестве шлюза, локально смон-

тировав /net, а затем открыв /net/inet. Записывая данные в этот файл, клиент

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

ентская машина не имеет интерфейса с этой сетью.

Подобным же образом клиент может экспортировать свои собственные фай-

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

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

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

не,

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

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

зрения выполняющейся на удаленной машине программы подобный подход пре-

вращает машину клиента в файловый сервер.

Именование

Как мы уже говорили, любой процесс в Plan 9 имеет свое внутреннее пространст-

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

имен. Стоит отметить особую специфику именования в Plan 9, которая состоит

том,

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

точку.

Это при-

ведет к образованию так называемого

объединенного

каталога (union directory),

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

менили логическую операцию ИЛИ (OR), хотя реально они просто упорядочива-

ются. Так, например, представим себе, что файловая система FSA имеет вложен-

ные каталоги /home и /usr, а файловая система FSB

—

вложенные каталоги /bin,

/src и /lib. Как показано на рис. 10.28, когда клиент монтирует эти две файловые

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

женных каталогов.

/home

/home \ /usr

Рис. 10.28. Объединенный каталоге Plan 9

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

систем в определенном порядке. Это необходимо для разрешения конфликтов

10.3.

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

679

имен.

Так,

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

при монтировании

FSB

после

FSA

вложенный каталог

/bin

системы

FSB

будет

помещен после одноименного вложенного каталога FSA.

результате

при

поис-

ке имени /remote/bin/prog будет возвращен идентификатор файла, найденного

в FSA, разумеется, если

он там

есть,

противном

же

случае поиск будет продол-

жен

каталоге

/bin в FSB.

Когда

на

файловом сервере

или

устройстве создается файл,

он

помечается

двумя целыми числами. Путь {path)

—

это уникальный номер файла, идентифи-

цирующий

его по

отношению

данному серверу

или

устройству. Номер версии

{version)

увеличивается

при

каждом изменении файла

на

единицу.

Для

глобаль-

ной идентификации файла

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

себя

файловую систему, должен знать

тип и

номер устройства сервера

или

устройст-

ва,

на

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

Эти

номера

со-

ответствуют старшему

младшему номерам устройств

UNIX. В результате

все

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

тифицирующими сервер или другое устройство,

на

котором хранится файл, и дву-

мя,

идентифицирующими файл

месте

его

хранения.

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

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

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

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

ми

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

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

изменения, внесенные остальными кли-

ентами, пропадают.

Plan

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

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

ся

на

сервер. Операции параллельно работающих

над

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

тываются

том порядке, который задает сервер. Изменения при этом никогда

не

теряются.

Кэширование

репликация

Plan

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

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

вер пользовательского уровня

под

названием

cfs,

который обычно запускается

автоматически

при

загрузке машины,

cfs

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

за-

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

на

сервер.

Чтобы избежать излишнего перемещения файлов

места

на

место, клиент мо-

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

они

продолжают оставаться

корректными. Корректность проверяется путем сравнения номера версии кэши-

рованного файла

номером версии файла, хранящегося

на

сервере. Если

с мо-

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

был

изменен, номера версий

не

совпадут.

этом случае клиент считает свой

кэш

некорректным

получает новую копию

файла

сервера.

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

Защита

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

Нидхема—Шредера. Для организации защищенного канала связи с другим поль-

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

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

ботать по поручению пользователя. Plan 9 поддерживает делегирование.

Защита файлов в Plan 9 осуществляется так же, как в UNIX. По сравнению

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

Plan 9 о группах. В Plan 9 группа считается просто еще одним пользователем,

который, возможно, имеет идентифицируемого лидера. Лидер группы обладает

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

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

ными.

10.3.2.

xFS

—

файловая система без серверов

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

рассмотрим,

—

это система xFS [15], разработанная в Беркли в качестве части

проекта NOW [16]. xFS интересна своей архитектурой без серверов. Вся файло-

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

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

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

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

ным системам относятся AFS и Coda.

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

вая система под названием XFS (то есть с прописной «X»), разработанная одно-

временно с xFS

[444].

Обзор

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

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

множество существующих сетей, например внутренние сети кластеров рабочих

станций (мы кратко рассматривали их в главе 1). Для полного рассредоточения

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

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

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

ми (возможно, реплицируемыми). Прототип xFS работал на рабочих станциях

Sun SPARC и UltraSPARC, соединенных сетью Myrinet [70].

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

Сервер

хранения {storage

server)

—

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

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

ковых массивов RAID [97].

Менеджер

метаданных (metadata manager) — это

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

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

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