Pr0grammer 29 октября 2009 в 01:31
В настоящее время, в условиях роста информации, возникают задачи хранения и обработки данных очень большого объема. Поэтому эти данные обрабатывается сразу на нескольких серверах одновременно, которые образуют кластеры. Для упрощения работы с данными на кластерах и разрабатывают распределенные файловые системы. Мы подробно рассмотрим пример распределенной файловой системы Google File System
, используемую компанией Google
. (Статья является, фактически, вольным и урезанным переводом оригинальной статьи).
GFS
является наиболее, наверное, известной распределенной файловой системой. Надежное масштабируемое хранение данных крайне необходимо для любого приложения, работающего с таким большим массивом данных, как все документы в интернете. GFS
является основной платформой хранения информации в Google
. GFS
- большая распределенная файловая система, способная хранить и обрабатывать огромные объемы информации.
GFS
строилась исходя из следующим критериев:
Рисунок взят из оригинальной статьи.
В системе существуют мастер-сервера и чанк-сервера, собственно, хранящие данные. Как правило, GFS
кластер состоит из одной главной машины мастера (master) и множества машин, хранящих фрагменты файлов чанк-серверы (chunkservers). Клиенты имеют доступ ко всем этим машинам. Файлы в GFS разбиваются на куски - чанки (chunk, можно сказать фрагмент). Чанк имеет фиксированный размер, который может настраиваться. Каждый такой чанк имеет уникальный и глобальный 64 - битный ключ, который выдается мастером при создании чанка. Чанк-серверы хранят чанки, как обычные Linux файлы, на локальном жестком диске. Для надежности каждый чанк может реплицироваться на другие чанк-серверы. Обычно используются три реплики.
Мастер отвечает за работу с метаданными всей файловой системы. Метаданные включают в себя пространства имен, информацию о контроле доступа к данным, отображение файлов в чанки, и текущее положение чанков. Также мастер контролирует всю глобальную деятельность системы такую, как управление свободными чанками, сборка мусора (сбор более ненужных чанков) и перемещение чанков между чанк-серверами. Мастер постоянно обменивается сообщениями (HeartBeat messages) с чанк-серверами, чтобы отдать инструкции, и определить их состояние (узнать, живы ли еще).
Клиент взаимодействует с мастером только для выполнения операций, связанных с метаданными. Все операции с самими данными производятся напрямую с чанк-серверами. GFS
- система не поддерживает POSIX API, так что разработчикам не пришлось связываться с VNode уровнем Linux.
Разработчики не используют кеширование данных, правда, клиенты кешируют метаданные. На чанк-серверах операционная система Linux и так кеширует наиболее используемые блоки в памяти. Вообще, отказ от кеширования позволяет не думать о проблеме валидности кеша (cache coherence).
Что такое распределенные файловые системы?
Способность совместно использовать диски, каталоги, и файлы по сети это одно из наиболее значительных достижений современных информационных технологий. Эта способность может существенно сократить требования к дисковому пространству компьютеров и облегчить совместную работу пользователей. Компьютеры с Microsoft Windows и MacOS Apple / MacOS X используют для этого механизм совместного использования дисков и директорий. В системах Linux / Unix для тех же самых задач традиционно используется NFS сетевая файловая система.
NFS это самый известный механизм совместного доступа к файлам для Linux и других Unix-систем, потому что он присутствует во многих Unix-подобных системах и очень прост в настройке. NFS поддерживается ядром Linux, и утилиты, связанные с NFS, присутствуют в каждом дистрибутиве. Но в мире Linux существуют и более современные механизмы для совместного использования файлов и каталогов. Каждый из них имеет определенные преимущества в настройке или в использовании.
Распределенная файловая система OpenAFS (http://www.openafs.org/ ) это Open Source-аналог известной коммерческой распределенной файловой системы AFS. Поддержка для распределенных файловых систем InterMezzo (http://www.inter-mezzo.org/) и Coda (http://coda.cs.cmu.edu/) уже присутствует в новых ядрах Linux из серии 2.4. Новые механизмы совместного использования файлов, основанные на Web (например, WebDAV (http://www.webdav.org/)), тоже могут использоваться в качестве файловых систем.
В этой статье дается краткий обзор преимуществ распределенных файловых систем, обсуждаются самые распространенные проблемы и их решения, и описываются самые интересные из распределенных файловых систем, доступных для Linux сегодня.
Введение в распределенные файловые системы.
Сейчас сетевые файловые системы называют <<распределенными>>. Этот термин отражает тот факт, что многие из этих файловых систем имеют гораздо больше возможностей, чем простая передача данных по сети. Носители данных, связанные с этими файловыми системами, не обязательно могут быть расположены на одном компьютере они могут быть распределены между многими компьютерами.
Распределенные файловые системы OpenAFS и Coda имеют собственные механизмы управления разделами, которые упрощают возможности хранения общедоступной информации. Они так же поддерживают дублирование способность делать копии разделов и сохранять их на других файловых серверах. Если один файловый сервер становится недоступным, то все равно к данным, хранящимся на его разделах, можно получить доступ с помощью имеющихся резервных копий этих разделов.
Самое главное различие между подходом Windows / MacOS (совместное использование каталогов и дисков) и подходом Linux, MacOS X и других Unix-подобных многопользовательских операционных систем в том, как эти операционные системы используют и организовывают разделы. Windows / MacOS экспортируют разделы как отдельные каталоги или диски, и удаленные системы, которые хотят обратиться к общедоступным устройствам, должны обязательно подключить их к себе.
Когда самый высокий уровень организации в файловой системе это раздел диска (например, как в файловых системах Windows), рабочие станции клиентов для получения доступа к этим данным должны обязательно подключиться к разделу и назначить ему отдельную букву в своей локальной раскладке (например, диск E, F, G, и т.д). Буквы могут быть назначены сетевым разделам в пользовательских и групповых профилях Windows (для стандартизации). Но, к сожалению, не на всех компьютерах расположение букв может быть одинаковым. Например, на компьютере с большим количеством жестких дисков и разделов нужные буквы могут быть заняты, и поэтому придется давать сетевым разделам другие обозначения.
Напротив, файловая система Unix это иерархическая файловая система, к которой дополнительные разделы добавляются с помощью монтирования их к существующей директории. Это позволяет эффективно добавить любой источник данных в любую существующую файловую систему. Если вы монтируете новый источник информации к каталогу, являющемуся частью распределенной файловой системы, он сразу же становится доступным всем клиентам этой распределенной системы.
Современные распределенные файловые системы типа OpenAFS или Coda включают в себя специальные сервисы для управления разделами. Это позволяет вам смонтировать разделы различных файловых серверов в центральную иерархию директорий, поддерживаемую файловыми системами. OpenAFS использует центральный каталог, называемый <>, а Coda использует <>. Эти иерархии директорий доступны всем клиентам распределенной файловой системы, и выглядят одинаково на любой из клиентск х рабочих станций. Это дает возможность пользователям работать со своими файлами одинаково на любом компьютере. Если ваш настольный компьютер не работает, вы совершенно спокойно можете использовать любой другой все ваши файлы находятся в безопасности на сервере.
Распределенные файловые системы, предоставляющие одни и те же данные многим различным компьютерным системам, дают пользователям возможность использовать любую операционную систему, лучше всего подходящую для их задач. Пользователи Macintosh могут пользоваться всеми преимуществами графических инструментальных средств, доступных в Mac OS, и одновременно хранить свои данные на централизованных файловых серверах. Пользователи Windows так же могут иметь доступ к устойчивой глобальной файловой системе. Распределенные файловые системы особенно привлекательны при попытке координации работы между группами, расположенными в различных городах, государствах, или даже в разных странах. Преимущество общие данные всегда доступны по сети, независимо от вашего местонахождения.
Проблемы администрации распределенных файловых систем.
Использование распределенных файловых систем дает системным администраторам не только новые возможности, но и новые проблемы. Но распределенные системы способны упростить многие из стандартных административных задач. В сетевой среде пользователи должны иметь возможность зайти в сеть под своим именем с любого компьютера. Это значит, что механизм входа в сеть (или аутентификации) тоже должен быть сетевым. Поэтому в среде распределенной файловой системы файлы групп и паролей, расположенные на индивидуальных компьютерах, вторичны по отношению к сетевым механизмам аутентификации (таким, как Kerberos или NIS, которые предоставляют пользователям возможность работать на любом компьютере). Но стандартные локальные механизмы проверки пароля все же должны существовать, чтобы администраторы могли выполнять на локальных компьютерах необходимые задачи. Сохранение общих данных на централизованных файловых серверах (а не на индивидуальных компьютерах) упрощает такие административные задачи, как резервирование и восстановление файлов и каталогов. Это так же централизует такие стандартные административные задачи, как контроль за использованием файловой системы, и представляет новые возможности управления хранением данных например, балансирование загрузки.
Распределенные файловые системы типа OpenAFS и Coda обеспечивают встроенные логические системы управления разделами, которые дают администраторам возможность переместить интенсивно используемые данные на более мощные или менее используемые компьютеры. Если распределенная файловая система поддерживает дублирование, копии интенсивно используемых данных могут распределяться между многими файловыми серверами. Это может уменьшить нагрузку на сеть, и облегчить работу серверов. Распределенные файловые системы используют логические разделы вместо физических дисковых разделов, и это позволяет легко добавить в сеть новую свободную память прямо во время работы. (Для добавления нового диска в локальный компьютер пришлось бы потратить некоторое время).
Использование распределенных файловых систем так же облегчает возможность совместного доступа к программному и аппаратному обеспечению. Но перед этим нужно удостовериться, что лицензии к используемым программам разрешают установку программного обеспечения в распределенной файловой системе. Сервера печати одна из первоначальных причин появления среды <<клиент-сервер>>. Распределенные файловые системы так же упрощают совместный доступ к специализированным аппаратным средствам, соединяясь по сети с компьютером, на котором установлены нужные аппаратные средства, и при этом все еще имея доступ к вашим данным.
Использование централизованной распределенной файловой системы может обеспечивать существенные преимущества в стоимости и быстродействии выполнения работы для клиентских систем. Распределенные файловые системы существенно уменьшают аппаратные затраты, минимизируя количество памяти на любом десктопе или ноутбуке. Использование распределенной файловой системы в качестве архива для пользовательских данных обычно означает более быструю загрузку клиентских машин, потому что большое количество данных больше не хранится локально и поэтому не нуждается в проверке после перезапуска клиента. Комбинация распределенной файловой системы и использования журналируемых файловых систем на клиентских компьютерах может дать значительное увеличение скорости запуска системы.
Поддержка автономной работы с данными.
Использование распределенной файловой системы увеличивает зависимость компьютерных систем от сети. Эта зависимость от данных, к которым люди могут обращаться только по сети, вызывает некоторые интересные проблемы для пользователей лаптопов/мобильных компьютеров, которые нуждаются в доступе к своим данным даже тогда, когда доступ к сети невозможен. Это называется <<автономная работа>> система должна функционировать, если ресурсы, которые обычно присутствуют в сети (например, пользовательские данные), по каким-то причинам не доступны. Даже Windows обеспечивает графический интерфейс для возможности маркировки файлов, с которыми вы хотите работать, когда вы отключены от сети, и для синхронизации этих файлов, когда вы соединяетесь повторно.
Распределенные файловые системы Coda и InterMezzo, которые являются в настоящее время доступными для Linux, тоже обеспечивают интегрированную поддержку для автономной работы. Так же сейчас ведется работа над обеспечением этой возможности для файловых систем NFS. Coda и InterMezzo уже поддерживаются ядром Linux поддержка Intermezzo встроена в ядро, начиная с версии 2.4.5, а Coda вообще была интегрирована в ядро 2.4 с самого начала.
Coda распределенная файловая система с происхождением из OpenAFS, которая разрабатывается в университете Carnegie Mellon с 1987 года. InterMezzo относительно новая распределенная файловая система, упор в разработке которой сделан на высокой доступности, гибком дублировании каталогов, поддержке автономных операций, и постоянном кэшировании. Создатели InterMezzo были вдохновлены CMU Coda, но этот проект не основан на исходном тексте Coda. Начальный создатель InterMezzo, Питер Браам, был главой проекта Coda в CMU в течение нескольких лет, и после этого он сам начал разрабатывать InterMezzo и несколько других проектов.
Расширение файловых систем с помощью Web.
До создания распределенных файловых систем совместное использование файлов через сеть ограничивалось простыми передачами файлов с помощью использования протокола передачи файлов FTP (File Transfer Protocol). Появление Всемирной паутины в значительной степени упростила процесс работы с FTP теперь не нужно знать команды, потому что протокол FTP интегрирован в большинство броузеров. Способность легко передавать файлы через Web также вела к расширению Паутины и существенному улучшению основного протокола передачи гипертекста
HTTP (HyperText Transfer Protocol), который сейчас является основанием для многих систем распределенного использования файлов.
Самая известная
из них это WebDAV, которая расшифровывается
как <
Поддержка WebDAV встроена во многие популярные Web-серверы, например Apache, где это основывается на опознавательных механизмах сервера. (От простых файлов.htaccess до интегрированных NIS, LDAP, или даже механизма аутентификации Windows). Использование WebDAV для доступа и модификации файлов через Web встроено в операционные системы Mac OS X, в новые версии Microsoft Internet Explorer, а так же доступно и в Linux при использовании таких приложений, как менеджер файлов Nautilus. Хотя это и не файловая система в традиционном смысле, но вы можете даже смонтировать WebDAV в Линуксе, используя загружаемый модуль ядра под названием davfs.
WebDAV обеспечивает такие стандартные для распределенных систем возможности, как блокировка файлов, создание, переименование, копирование, удаление файлов, а так же поддерживает такие продвинутые возможности, как meta-данные файла (более подробная информация о файле заголовок, тема, создатель, и т.д). В ближайшем будущем WebDAV будет включать интегрированную поддержку управления версиями, которая упростит работу многих пользователей над общими файлами, отслеживая изменения, авторов этих изменений, и другие аспекты общего использования документа. Эти возможности контроля над версиями обеспечиваются в соответствии с протоколом DeltaV, который активно разрабатывается Рабочей группой DeltaV (http://www.webdav.org/deltav) подразделением Проектировочной группы Интернета (IETF Internet Engineering Task Force). Некоторые проекты, например, Subversion (http://subversion.tigris.org/) (WebDAV и DeltaV-основанная замена стандарту CVS), уже доступны в альфа-версии. Subversion обеспечивает систему контроля над версиями и сохранение архива файла на основе базы данных, имеющей API языка C, и моделирует версионную файловую систему, легко доступную через Web.
Две главные цели.Сетевая прозрачность.
Самая важная цель - обеспечить те же самые возможности доступа к файлам,
распределенным по сети ЭВМ, которые обеспечиваются в системах разделения
времени на централизованных ЭВМ.
Высокая доступность.
Другая важная цель - обеспечение высокой доступности. Ошибки систем
или осуществление операций копирования и сопровождения не должны приводить
к недоступности файлов.
Понятие файлового сервиса и файлового сервера .
Файловый сервис
- это то, что файловая система предоставляет
своим клиентам, т.е. интерфейс с файловой системой.
Файловый сервер
- это процесс, который реализует файловый сервис.
Пользователь не должен знать, сколько файловых серверов имеется и где они расположены.
Так, как файловый сервер обычно является обычным пользовательским процессом, то в системе могут быть различные файловые серверы, предоставляющие различный сервис (например, UNIX файл сервис и MS-DOS файл сервис).
Распределенная система обычно имеет два существенно отличающихся компонента - непосредственно файловый сервис и сервис директорий.
Для любой файловой системы первый фундаментальный вопрос - что такое файл. Во многих системах, таких как UNIX и MS-DOS, файл - не интерпретируемая последовательность байтов. На многих централизованных ЭВМ (IBM/370) файл представляется последовательность записей, которую можно специфицировать ее номером или содержимым некоторого поля (ключом). Так, как большинство распределенных систем базируются на использовании среды UNIX и MS-DOS, то они используют первый вариант понятия файла.
Файл может иметь атрибуты (информация о файле, не являющаяся его частью). Типичные атрибуты - владелец, размер, дата создания и права доступа.
Важный аспект файловой модели - могут ли файлы модифицироваться после создания. Обычно могут, но есть системы с неизменяемыми файлами. Такие файлы освобождают разработчиков от многих проблем при кэшировании и размножении.
Защита обеспечивается теми же механизмами, что и в однопроцессорных ЭВМ - мандатами и списками прав доступа. Мандат - своего рода билет, выданный пользователю для каждого файла с указанием прав доступа. Список прав доступа задает для каждого файла список пользователей с их правами. Простейшая схема с правами доступа - UNIX схема, в которой различают три типа доступа (чтение, запись, выполнение), и три типа пользователей (владелец, члены его группы, и прочие).
Файловый сервис может базироваться на одной из двух моделей - модели загрузки/разгрузки и модели удаленного доступа . В первом случае файл передается между клиентом (памятью или дисками) и сервером целиком, а во втором файл сервис обеспечивает множество операций (открытие, закрытие, чтение и запись части файла, сдвиг указателя, проверку и изменение атрибутов, и т.п.). Первый подход требует большого объема памяти у клиента, затрат на перемещение ненужных частей файла. При втором подходе файловая система функционирует на сервере, клиент может не иметь дисков и большого объема памяти.
Обеспечивает операции создания и удаления директорий, именования и переименования файлов, перемещение файлов из одной директории в другую.
Определяет алфавит и синтаксис имен. Для спецификации типа информации в файле используется часть имени (расширение) либо явный атрибут.
Все распределенные системы позволяют директориям содержать поддиректории - такая файловая система называется иерархической . Некоторые системы позволяют создавать указатели или ссылки на произвольные директории, которые можно помещать в директорию. При этом можно строить не только деревья, но и произвольные графы (разница между ними очень важна для распределенных систем, поскольку в случае графа удаление связи может привести к появлению недостижимых поддеревьев. Обнаруживать такие поддеревья в распределенных системах очень трудно).
Ключевое решение при конструировании распределенной файловой системы - должны или не должны машины (или процессы) одинаково видеть иерархию директорий. Тесно связано с этим решением наличие единой корневой директории (можно иметь такую директорию с поддиректориями для каждого сервера).
Прозрачность именования
.
Две формы прозрачности именования различают - прозрачность расположения
(/server/d1/f1) и прозрачность миграции (когда изменение расположения файла
не требует изменения имени).
Имеются три подхода к именованию:
Двухуровневое именование
.
Большинство систем используют ту или иную форму двухуровневого именования.
Файлы (и другие объекты) имеют символические имена для пользователей, но
могут также иметь внутренние двоичные имена для использования самой системой.
Например, в операции открыть файл пользователь задает символическое имя,
а в ответ получает двоичное имя, которое и использует во всех других операциях
с данным файлом.
Способы формирования двоичных имен различаются в разных системах:
UNIX-семантика
Естественная семантика однопроцессорной ЭВМ - если за операцией записи
следует чтение, то результат определяется последней из предшествующих операций
записи. В распределенной системе такой семантики достичь легко только в
том случае, когда имеется один файл-сервер, а клиенты не имеют кэшей. При
наличии кэшей семантика нарушается. Надо либо сразу все изменения в кэшах
отражать в файлах, либо менять семантику разделения файлов.
Неизменяемые файлы
- очень радикальный подход к изменению
семантики разделения файлов.
Только две операции - создать и читать. Можно заменить новым файлом
старый - т.е. можно менять директории. Если один процесс читает файл, а
другой его подменяет, то можно позволить первому процессу доработать со
старым файлом в то время, как другие процессы могут уже работать с новым.
Семантика сессий
Изменения открытого файла видны только тому процессу (или машине), который
производит эти изменения, а лишь после закрытия файла становятся видны
другим процессам (или машинам). Что происходит, если два процесса одновременно
работали с одним файлом - либо результат будет определяться процессом,
последним закрывшим файл, либо можно только утверждать, что один из двух
вариантов файла станет текущим.
Транзакции
Процесс выдает операцию НАЧАЛО ТРАНЗАКЦИИ, сообщая тем самым, что последующие
операции должны выполняться без вмешательства других процессов. Затем выдает
последовательность чтений и записей, заканчивающуюся операцией КОНЕЦ ТРАНЗАКЦИИ.
Если несколько транзакций стартуют в одно и то же время, то система гарантирует,
что результат будет таким, каким бы он был в случае последовательного выполнения
транзакций (в неопределенном порядке). Пример - банковские операции.
Выше были рассмотрены аспекты распределенных файловых систем, которые видны пользователю. Ниже рассматриваются реализационные аспекты.
Приступая к реализации очень важно понимать, как система будет использоваться. Приведем результаты некоторых исследований использования файлов (статических и динамических) в университетах. Очень важно оценивать представительность исследуемых данных.
Есть ли разница между клиентами и серверами ? Имеются системы, где все машины имеют одно и то же ПО и любая машина может предоставлять файловый сервис. Есть системы, в которых серверы являются обычными пользовательскими процессами и могут быть сконфигурированы для работы на одной машине с клиентами или на разных. Есть системы, в которых клиенты и серверы являются фундаментально разными машинами с точки зрения аппаратуры или ПО (требуют различных ОС, например).
Второй вопрос - должны ли быть файловый сервер и сервер директорий отдельными серверами или быть объединенными в один сервер. Разделение позволяет иметь разные серверы директорий (UNIX, MS-DOS) и один файловый сервер. Объединение позволяет сократить коммуникационные издержки.
В случае разделения серверов и при наличии разных серверов директорий для различных поддеревьев возникает следующая проблема. Если первый вызванный сервер будет поочередно обращаться ко всем следующим, то возникают большие коммуникационные расходы. Если же первый сервер передает остаток имени второму, а тот третьему, и т.д., то это не позволяет использовать RPC.
Возможный выход - использование кэша подсказок. Однако в этом случае при получении от сервера директорий устаревшего двоичного имени клиент должен быть готов получить отказ от файлового сервера и повторно обращаться к серверу директорий (клиент может не быть конечным пользователем!).
Последний важный вопрос - должны ли серверы хранить информацию о клиентах.
Серверы с состоянием
.
Достоинства.
Серверы без состояния
. Достоинства.
Во-первых, хранение файлов на дисках сервера. Нет проблемы когерентности, так как одна копия файла существует. Главная проблема - эффективность, поскольку для обмена с файлом требуется передача информации в обе стороны и обмен с диском.
Кэширование в памяти сервера. Две проблемы - помещать в кэш файлы целиком или блоки диска, и как осуществлять выталкивание из кэша.
Коммуникационные издержки остаются.
Избавиться от коммуникаций позволяет кэширование в машине клиента.
Кэширование на диске клиента может не дать преимуществ перед кэшированием в памяти сервера, а сложность повышается значительно.
Поэтому рассмотрим подробнее организацию кэширования в памяти клиента.
Алгоритм с отложенной записью
.
Через регулярные промежутки времени все модифицированные блоки пишутся
в файл. Эффективность выше, но семантика непонятная пользователю (UNIX).
Алгоритм записи в файл при закрытии файла
.
Реализует семантику сессий. Не намного хуже случая, когда два процесса
на одной ЭВМ открывают файл, читают его, модифицируют в своей памяти и
пишут назад в файл.
Алгоритм централизованного управления
.
Можно выдержать семантику UNIX, но не эффективно, ненадежно, и плохо
масштабируется.
Каждый сервер экспортирует некоторое число своих директорий для доступа к ним удаленных клиентов. При этом экспортируются директории со всеми своими поддиректориями, т.е. фактически поддеревья. Список экспортируемых директорий хранится в специальном файле, что позволяет при загрузке сервера автоматически их экспортировать.
Клиент получает доступ к экспортированным директориям путем их монтирования. Если клиент не имеет дисков, то может монтировать директории в свою корневую директорию.
Если несколько клиентов одновременно смонтировали одну и ту же директорию,
то они могут разделять файлы в общей директории без каких либо дополнительных
усилий. Простота - достоинство NFS.
Протоколы NFS.
Поскольку одна из целей NFS - поддержка гетерогенных систем, клиенты и
серверы могут работать на разных ЭВМ с различной архитектурой и различными
ОС. Поэтому необходимо иметь строгие протоколы их взаимодействия. NFS имеет
два таких протокола.
Первый протокол поддерживает монтирование
. Клиент может
послать серверу составное имя директории (имя пути) и попросить разрешения
на ее монтирование. Куда будет монтировать директорию клиент для сервера
значения не имеет и поэтому не сообщается ему. Если путь задан корректно
и директория определена как экпортируемая, то сервер возвращает клиенту
дескриптор директории. Дескриптор содержит поля, уникально идентифицирующие
тип ЭВМ, диск, номер i-вершины (понятие ОС UNIX) для данной директории,
а также информацию о правах доступа к ней. Этот дескриптор используется
клиентом в последующих операциях с директорией.
Многие клиенты монтируют требуемые удаленные директории автоматически при запуске (используя командную процедуру shell-интерпретатора ОС UNIX).
Версия ОС UNIX, разработанная Sun (Solaris), имеет свой специальный режим автоматического монтирования. С каждой локальной директорией можно связать множество удаленных директорий. Когда открывается файл, отсутствующий в локальной директории, ОС посылает запросы всем серверам (владеющим указанными директориями). Кто ответит первым, директория того и будет смонтирована. Такой подход обеспечивает и надежность, и эффективность (кто свободнее, тот раньше и ответит). При этом подразумевается, что все альтернативные директории идентичны. Поскольку NFS не поддерживает размножение файлов или директорий, то такой режим автоматического монтирования в основном используется для директорий с кодами программ или других редко изменяемых файлов.
Второй протокол - для доступа к директориям и файлам. Клиенты посылают сообщения, чтобы манипулировать директориями, читать и писать файлы. Можно получить атрибуты файла. Поддерживается большинство системных вызовов ОС UNIX, исключая OPEN и CLOSE. Для получения дескриптора файла по его символическому имени используется операция LOOKUP, отличающаяся от открытия файла тем, что никаких внутренних таблиц не создается. Таким образом, серверы в NFS не имеют состояния (stateless). Поэтому для захвата файла используется специальный механизм.
NFS использует механизм защиты UNIX. В первых версиях все запросы содержали идентификатор пользователя и его группы (для проверки прав доступа). Несколько лет эксплуатации системы показали слабость такого подхода. Теперь используется криптографический механизм с открытыми ключами для проверки законности каждого запроса и ответа. Данные не шифруются.
Все ключи, используемые для контроля доступа, поддерживаются специальным сервисом (и серверами) - сетевым информационным сервисом (NIS). Храня пары (ключ, значение), сервис обеспечивает выдачу значения кода при правильном подтверждении ключей. Кроме того, он обеспечивает отображение имен машин на их сетевые адреса, и другие отображения. NIS-серверы используют схему главный -подчиненные для реализации размножения (ленивое размножение). Реализация NFS (XDR - External Data Represantation)
Задача уровня виртуальной файловой системы - поддерживать для каждого открытого файла строку в таблице (v-вершину), аналогичную i-вершине UNIX. Эта строка позволяет различать локальные файлы от удаленных. Для удаленных файлов вся необходимая информация хранится в специальной r-вершине в NFS-клиенте, на которую ссылается v-вершина. У сервера нет никаких таблиц.
Передачи информации между клиентом и сервером NFS производятся блоками размером 8К (для эффективности).
Два кэша - кэш данных и кэш атрибутов файлов (обращения к ним очень часты, разработчики NFS исходили из оценки 90%). Реализована семантика отложенной записи - предмет критики NFS.
Имеется также кэш подсказок для ускорения получения v-вершины по символическому имени. При использовании устаревшей подсказки NFS-клиент будет обращаться к NFS-серверу и корректировать свой кэш (пользователь об этом ничего не должен знать).
Лаборатория Параллельных Информационных Технологий, НИВЦ МГУ
Ключевым компонентом любой распределенной системы является файловая система. Как и в централизованных системах, в распределенной системе функцией файловой системы является хранение программ и данных и предоставление доступа к ним по мере необходимости. Файловая система поддерживается одной или более машинами, называемыми файл-серверами. Файл-серверы перехватывают запросы на чтение или запись файлов, поступающие от других машин (не серверов). Эти другие машины называются клиентами. Каждый посланный запрос проверяется и выполняется, а ответ отсылается обратно. Файл-серверы обычно содержат иерархические файловые системы, каждая из которых имеет корневой каталог и каталоги более низких уровней. Рабочая станция может подсоединять и монтировать эти файловые системы к своим локальным файловым системам. При этом монтируемые файловые системы остаются на серверах.
Важно понимать различие между файловым сервисом и файловым сервером. Файловый сервис – это описание функций, которые файловая система предлагает своим пользователям. Это описание включает имеющиеся примитивы, их параметры и функции, которые они выполняют. С точки зрения пользователей файловый сервис определяет то, с чем пользователи могут работать, но ничего не говорит о том, как все это реализовано. В сущности, файловый сервис определяет интерфейс файловой системы с клиентами.
Файловый сервер – это процесс, который выполняется на отдельной машине и помогает реализовывать файловый сервис. В системе может быть один файловый сервер или несколько, но в хорошо организованной распределенной системе пользователи не знают, как реализована файловая система. В частности, они не знают количество файловых серверов, их месторасположение и функции. Они только знают, что если процедура определена в файловом сервисе, то требуемая работа каким-то образом выполняется, и им возвращаются требуемые результаты. Более того, пользователи даже не должны знать, что файловый сервис является распределенным. В идеале он должен выглядеть также, как и в централизованной файловой системе.
Так как обычно файловый сервер – это просто пользовательский процесс (или иногда процесс ядра), выполняющийся на некоторой машине, в системе может быть несколько файловых серверов, каждый из которых предлагает различный файловый сервис. Например, в распределенной системе может быть два сервера, которые обеспечивают файловые сервисы систем UNIX и MS-DOS соответственно, и любой пользовательский процесс пользуется подходящим сервисом.
Файловый сервис в распределенных файловых системах (впрочем как и в централизованных) имеет две функционально различные части: собственно файловый сервис и сервис каталогов. Первый имеет дело с операциями над отдельными файлами, такими, как чтение, запись или добавление, а второй – с созданием каталогов и управлением ими, добавлением и удалением файлов из каталогов и т.п.
Для любого файлового сервиса, независимо от того, централизован он или распределен, самым главным является вопрос, что такое файл? Во многих системах, таких как UNIX и MS DOS, файл – это неинтерпретируемая последовательность байтов. Значение и структура информации в файле является заботой прикладных программ, операционную систему это не интересует.
В ОС мейнфреймов поддерживаются разные типы логической организации файлов, каждый с различными свойствами. Файл может быть организован как последовательность записей, и у операционной системы имеются вызовы, которые позволяют работать на уровне этих записей. Большинство современных распределенных файловых систем поддерживают определение файла как последовательности байтов, а не последовательности записей. Файл характеризуется атрибутами: именем, размером, датой создания, идентификатором владельца, адресом и другими.
Важным аспектом файловой модели является возможность модификации файла после его создания. Обычно файлы могут модифицироваться, но в некоторых распределенных системах единственными операциями с файлами являются СОЗДАТЬ и ПРОЧИТАТЬ. Такие файлы называются неизменяемыми. Для неизменяемых файлов намного легче осуществить кэширование файла и его репликацию (тиражирование), так как исключается все проблемы, связанные с обновлением всех копий файла при его изменении.
Файловый сервис может быть разделен на два типа в зависимости от того, поддерживает ли он модель загрузки-выгрузки или модель удаленного доступа. В модели загрузки-выгрузки пользователю предлагаются средства чтения или записи файла целиком. Эта модель предполагает следующую схему обработки файла: чтение файла с сервера на машину клиента, обработка файла на машине клиента и запись обновленного файла на сервер. Преимуществом этой модели является ее концептуальная простота. Кроме того, передача файла целиком очень эффективна. Главным недостатком этой модели являются высокие требования к дискам клиентов. Кроме того, неэффективно перемещать весь файл, если нужна его маленькая часть.
Другой тип файлового сервиса соответствует модели удаленного доступа, которая предполагает поддержку большого количества операций над файлами: открытие и закрытие файлов, чтение и запись частей файла, позиционирование в файле, проверка и изменение атрибутов файла и так далее. В то время как в модели загрузки-выгрузки файловый сервер обеспечивал только хранение и перемещение файлов, в данном случае вся файловая система выполняется на серверах, а не на клиентских машинах. Преимуществом такого подхода являются низкие требования к дисковому пространству на клиентских машинах, а также исключение необходимости передачи целого файла, когда нужна только его часть.
Природа сервиса каталогов не зависит от типа используемой модели файлового сервиса. В распределенных системах используются те же принципы организации каталогов, что и в централизованных, в том числе многоуровневая организация каталогов.
Принципиальной проблемой, связанной со способами именования файлов, является обеспечение прозрачности. В данном контексте прозрачность понимается в двух слабо различимых смыслах. Первый – прозрачность расположения – означает, что имена не дают возможности определить месторасположение файла. Например, имя /server1/dir1/ dir2/x говорит, что файл x расположен на сервере 1, но не указывает, где расположен этот сервер. Сервер может перемещаться по сети, а полное имя файла при этом не меняется. Следовательно, такая система обладает прозрачностью расположения.
В системах, состоящих из клиентов и серверов, потенциально имеется четыре различных места для хранения файлов и их частей: диск сервера, память сервера, диск клиента (если имеется) и память клиента. Наиболее подходящим местом для хранения всех файлов является диск сервера. Он обычно имеет большую емкость, и файлы становятся доступными всем клиентам. Кроме того, поскольку в этом случае существует только одна копия каждого файла, то не возникает проблемы согласования состояний копий.
Проблемой при использовании диска сервера является производительность. Перед тем, как клиент сможет прочитать файл, файл должен быть переписан с диска сервера в его оперативную память, а затем передан по сети в память клиента. Обе передачи занимают время.
Значительное увеличение производительности может быть достигнуто за счет кэширования файлов в памяти сервера. Требуются алгоритмы для определения, какие файлы или их части следует хранить в кэш-памяти.
При выборе алгоритма должны решаться две задачи. Во-первых, какими единицами оперирует кэш. Этими единицами могут быть или дисковые блоки, или целые файлы. Если это целые файлы, то они могут храниться на диске непрерывными областями (по крайней мере в виде больших участков), при этом уменьшается число обменов между памятью и диском а, следовательно, обеспечивается высокая производительность. Кэширование блоков диска позволяет более эффективно использовать память кэша и дисковое пространство.
Во-вторых, необходимо определить правило замены данных при заполнении кэш-памяти. Здесь можно использовать любой стандартный алгоритм кэширования, например, алгоритм LRU (least recently used), соответствии с которым вытесняется блок, к которому дольше всего не было обращения.
Кэш-память на сервере легко реализуется и совершенно прозрачна для клиента. Так как сервер может синхронизировать работу памяти и диска, с точки зрения клиентов существует только одна копия каждого файла, так что проблема согласования не возникает.