Структура системы

Использование файлов

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

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

Приступая к реализации очень важно понимать, как система будет использоваться. Приведем результаты некоторых исследований использования файлов (статических и динамических) в университетах. Очень важно оценивать представительность исследуемых данных.

ü большинство файлов имеют размер менее 10К (следует перекачивать целиком).

ü чтение встречается гораздо чаще записи (кэширование).

ü чтение и запись последовательны, произвольный доступ редок (упреждающее кэширование, чтение с запасом, выталкивание после записи следует группировать).

ü большинство файлов имеют короткое время жизни (создавать файл в клиенте и держать его там до уничтожения).

ü мало файлов разделяются (кэширование в клиенте и семантика сессий).

ü существуют различные классы файлов с разными свойствами (следует иметь в системе разные механизмы для разных классов).

Есть ли разница между клиентами и серверами? Имеются системы, где все машины имеют одно и то же ПО и любая машина может предоставлять файловый сервис. Есть системы, в которых серверы являются обычными пользовательскими процессами и могут быть сконфигурированы для работы на одной машине с клиентами или на разных. Есть системы, в которых клиенты и серверы являются фундаментально разными машинами с точки зрения аппаратуры или ПО (требуют различных ОС, например).

Второй вопрос - должны ли быть файловый сервер и сервер директорий отдельными серверами или быть объединенными в один сервер. Разделение позволяет иметь разные серверы директорий (UNIX, MS-DOS) и один файловый сервер. Объединение позволяет сократить коммуникационные издержки.

В случае разделения серверов и при наличии разных серверов директорий для различных поддеревьев возникает следующая проблема. Если первый вызванный сервер будет поочередно обращаться ко всем следующим, то возникают большие коммуникационные расходы. Если же первый сервер передает остаток имени второму, а тот третьему, и т.д., то это не позволяет использовать RPC.

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

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

Серверы с состоянием. Достоинства.

ü Короче сообщения (двоичные имена используют таблицу открытых файлов).

ü выше эффективность (информация об открытых файлах может храниться в оперативной памяти).

ü блоки информации могут читаться с упреждением.

ü убедиться в достоверности запроса легче, если есть состояние (например, хранить номер последнего запроса).

ü возможна операция захвата файла.

Серверы без состояния. Достоинства.

ü устойчивость к ошибкам.

ü не требуется операций ОТКРЫТЬ/ЗАКРЫТЬ.

ü не требуется память для таблиц.

ü нет ограничений на число открытых файлов.

ü нет проблем при крахе клиента.

Дата добавления: 2015-04-25