Содержание

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

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

Вопросы разработки

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

Взгляд со стороны пользователя

Цели разработки

Компоненты NFS

Отсутствие сохранения состояния

Общие сведения о работе и нагрузке NFS

Операции с атрибутами

Операции с данными

Сравнение приложений с разными наборами операций NFS

Характер рабочей нагрузки NFS

"Полностью активные" клиенты

Типовой пример использования NFS

NFS и клиентские ПК

Операционные системы реальной памяти

Более мелкие файлы

Менее требовательные клиенты

Клиент NFS

Взаимодействие с системой виртуальной памяти

Файловая система с репликацией данных (CFS)

Конфигурирование NFS-сервера

Исходные предпосылки

Конфигурация сети (локальной и глобальной)

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

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

NFS и глобальные сети

Выбор типа сети и количества клиентов

Потребление процессорных ресурсов

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

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

Организация произвольного доступа в NFS с интенсивными запросами атрибутов

Распределение нагрузки по доступу к дискам с помощью программного обеспечения типа Online:DiskSuit

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

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

Нестандартные требования к памяти

PrestoServe/NVSIMM

Обеспечение резервного копирования и устойчивости к неисправностям

Предварительная оценка рабочей нагрузки

Измерение существующих систем

Оценка нагрузки в отсутствие системы

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

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

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

Появившаяся в 70-х годах возможность объединения компьютеров в единую сеть произвела революцию в компьютерной промышленности. Эта возможность прежде всего вызвала желание организовать разделение доступа к файлам между различными компьютерами. Первые достижения в этой области были ограничены возможностью копирования целых файлов из одной машины в другую. В качестве примера можно указать программу UNIX-to-UNIX copy (uucp) и File Transfer Protocol (ftp). Однако эти решения не позволяли даже близко подойти к реализации доступа к файлам на удаленной машине, по своим возможностям напоминающего доступ к файлам на локальных дисках.

Только в середине 80-х годов появилось несколько распределенных файловых систем, которые обеспечили прозрачный доступ по сети к удаленным файлам. Это были Network File System (NFS) компании Sun Microsystems (1985), Remote File Sharing system (RFS) компании AT&T (1986) и Andrew File System (AFS) университета Карнеги-Меллона (1995). Эти три системы резко отличались друг от друга по целям разработки, архитектуре и семантике, хотя все они пытались решить одну и ту же фундаментальную проблему. Сегодня RFS доступна практически на всех системах, базирующихся на UNIX System V. Разработка ASF перешла корпорации Transarc, в которой она была развита и превращена в Distributed File System (DFS) - компоненнт распределенной вычислительной среды DSE (Distributed Computing Environment) Open Software Foundation. Но наибольшее распространение получила NFS, которая поддерживается на всех UNIX и многих "не UNIX" системах.

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

Традиционная централизованная файловая система позволяет множеству пользователей, работающих на одной системе, разделять доступ к файлам, хранящихся локально на этой машине. Распределенная файловая система расширяет эти возможности, позволяя разделять доступ к файлам пользователям на разных машинах, объединенных между собой с помощью сети. В основе распределенных файловых систем лежит модель клиент-сервер. В данном случае под клиентом понимается машина, которая обращается к некоторому файлу, а под сервером - машина, хранящая файлы и обеспечивающая к ним доступ. Некоторые системы требуют, чтобы клиенты и серверы были разными машинами, в то время как другие допускают, чтобы одна машина работала и как клиент, и как сервер.

Важно отметить различие между распределенными файловыми системами и распределенными операционными системами. Распределенная операционная система, подобная V или Amoeba, для пользователя выглядит как централизованная операционная система, но работает одновременно на нескольких машинах. Она может иметь файловую систему, которая разделяется всеми машинами системы. В отличие от них, распределенная файловая система представляет собой определенный слой программного обеспечения, который управляет связью между традиционными операционными системами и файловыми системами. Этот слой программных средств интегрируется с операционными системами мащин-хостов сети и обеспечивает сервис распределенного доступа к файлам для систем, которые имеют централизованное ядро.

Распределенные файловые системы имеют ряд важных свойств. Каждая конкретная система может обладать всеми или частью этих свойств. Это как раз и создает основу для сравнения различных архитектур между собой.

Сетевая прозрачность - Клиенты должны иметь возможность обращаться к удаленным файлам пользуясь теми же самыми операциями, что и для доступа к локальным файлам. Прозрачность размещения - Имя файла не должно определять его местоположения в сети. Независимость размещения - Имя файла не должно меняться при изменении его физического меторасположения. Мобильность пользователя - Пользователи должны иметь возможность обращаться к разделяемым файлам из любого узла сети. Устойчивость к сбоям - Система должна продолжать функционировать при неисправности отдельного компонента (сервера или сегмента сети). Однако это может приводить к деградации производительности или к исключению доступа к некоторой части файловой системы. Масштабируемость - Система должна обладать возможностью масштабирования в случае увеличения нагрузки. Кроме того, должна существовать возможность постепенного наращивания системы путем добавления отдельных компонентов. Мобильность файлов - Должна быть возможность перемещения файлов из одного месторасположения в другое на работающей системе. Вопросы разработки

Имеется несколько важных вопросов, которые рассматриваются при разработке распределенных файловых систем. Они касаются функциональных возможностей, семантики и производительности системы. Различные файловые системы можно сравнивать между собой, выясняя как они решают эти вопросы:

Пространство имен - Некоторые распределенные файловые системы обеспечивают однородное пространство имен такое, что каждый клиент использует одно и то же путевое имя для доступа к данному файлу. Другие системы позволяют клиенту создавать свое пространство имен путем монтирования разделяемых поддеревьев к произвольным каталогам в иерархии файлов. Оба метода имеют свою привлекательность. Операции с сохранением и без сохранения состояний - Сервер сохраняющий состояния обеспечивает хранение информации об операциях клиента между запросами и использует эту информацию о состоянии для корректного обслуживания последующих запросов. Такие запросы как open или seek связаны с изменением состояний, так как кто-то должен запомнить информацию о том, какие файлы открыл клиент, а также все смещения в открытых файлах. В системе без сохранения состояний каждый запрос является "самодостаточным" и сервер не поддерживает устойчивых состояний о клиентах. Например, вместо того, чтобы поддерживать информацию о смещении в открытом файле сервер может требовать от клиента указания смещения в каждой операции чтения или записи. Серверы с сохранением состояний работают быстрее, поскольку они могут использовать знания о состоянии клиента для существенного уменьшения сетевого трафика. Однако они должны иметь и целый комплекс механизмов поддержания согласованного состояния системы и восстановления после ее отказа. Серверы без сохранения состояний более просты в разработке и реализации, но не дают такой высокой производительности. Семантика разделения - Распределенная файловая система должна определить семантику, которая применяется когда несколько клиентов одновременно обращаются к одному файлу. Семантика UNIX требует, чтобы все изменения, сделанные одним клиентом, были бы видны другим клиентам, когда они выдают следующий системный вызов read или write. Некоторые файловые системы обеспечивают "семантику сессии" (session semantics), при которой изменения становятся доступными другим клиентам на основе гранулированности системных вызовов open и close. А некоторые системы дают даже еще более слабые гарантии, например, интервал времени, который должен пройти прежде, чем изменения наверняка попадут к другим клиентам. Методы удаленного доступа - В простой модели клиент-сервер используется метод удаленного обслуживания, при котором каждое действие инициируется клиентом, а сервер просто представляет собой агента, который выполняет заявки клиента. Во многих распределенных системах, особенно в системах, сохраняющих состояние, сервер играет гораздо более активную роль. Он не только обслуживает запросы клиентов, но и участвует в работе механизма обеспечения когерентности, уведомляя клиентов о всех случаях, когда кэшированные в нем данные становятся недостоверными. Сетевая файловая система NFS

Компания Sun Microsystems представила NFS в 1985 году как средство обеспечения прозрачного доступа к удаленным файловым системам. Помимо публикации протокола Sun лицензировала его базовую реализацию, которая была использована различными поставщиками для портирования NFS на разные операционные системы. С тех пор NFS стала фактически промышленным стандартом, который поддерживается действительно всеми вариантами системы UNIX, а также некоторыми другими системами, например, VMS и MS-DOS.

Архитектура NFS базируется на модели клиент-сервер. Файл-сервер представляет собой машину, которая экспортирует некоторый набор файлов. Клиентами являются машины, которые имеют доступ к этим файлам. Одна машина может для различных файловых систем выступать как в качестве сервера, так и в качестве клиента. Однако программный код NFS разделен на две части, что позволяет иметь только клиентские или только серверные системы.

Клиенты и серверы взаимодействуют с помощью удаленных вызовов процедур (rpc - remote procedure call), которые работают как синхронные запросы. Когда приложение на клиенте пытается обратиться к удаленному файлу, ядро посылает запрос в сервер, а процесс клиента блокируется до получения ответа. Сервер ждет приходящие запросы, обрабатывает их и отсылает ответы назад клиентам.

Взгляд со стороны пользователя

Сервер NFS экспортирует одну или несколько файловых систем. Каждая экспортируемая файловая система может быть либо целым разделом диска либо его поддеревом. (Различные варианты UNIX имеют свои собственные правила дробления экспортируемых систем. Некоторые из них могут, например, разрешать экспортировать только файловую систему целиком, другие - только одно одно поддерево в каждой файловой системе). Сервер может определить, обычно посредством строк в файле /etc/exports, какие клиенты могут иметь доступ к каждой экспортируемой файловой системе, а также разрешенный режим доступа к ней: "только чтение" или "чтение и запись".

Затем клиентские машины могут подмонтировать такую файловую систему или ее поддерево к любому каталогу в своей существующей иерархии файлов, точно так же, как они смогли бы смонтировать любую локальную файловую систему. Клиент может монтировать каталог с режимом "только чтение", даже если сервер экспортирует его в режиме "чтение и запись". NFS поддерживает два типа монтирования: жесткое и мякгое. От типа монтирования зависит поведение клиента в случае, если сервер не отвечает на запрос. Если файловая система смонтирована жестко, клиент продолжает повторные запросы до получения ответа. В случае мягкого монтирования клиент спустя некоторое время отказывается от повторных запросов и получает ошибку. Когда монтирование произведено, клиент может обращаться к файлам в удаленной файловой системе, используя те же самые операции, которые применяются к локальным файлам. Некоторые системы поддерживают также такой тип монтирования, поведение которого соответствует жесткому монтированию при организации повторных попыток смонтировать файловую систему, но оказывается мягким для последующих операций ввода/вывода.

Операции монтирования NFS менее ограничены по сравнению с операциями монтирования локальных файловых систем. Протокол не требует, чтобы вызывающий операцию монтирования пользователь был привилегированным, хотя большинству пользователей навязываются эти требования. (Например, ULTRIX компании Digital позволяет любому пользователю монтировать файловую систему NFS до тех пор, пока этот пользователь имеет права доступа по записи в каталог точки монтирования. Пользователь может монтировать ту же самую файловую систему к нескольким точкам дерева каталогов, даже к своему подкаталогу. Сервер может экспортировать только свои локальные файловые системы и не может пересекать свои собственные точки монтирования во время прохода по путевому имени. Таким образом, чтобы увидеть все файлы сервера, клиент должен смонтировать все его файловые системы.

На рисунке 4.1 приведен пример. Серверная система nfssrv имеет два диска. Она смонтировала диск 1 к каталогу /usr/local диска 0 и экспортировала каталоги /usr и /usr/local. Предположим, что клиент выполняет следующие четыре операции mount:

   mount -t nfs  nfssrv:/usr        /usr

mount -t nfs nfssrv:/usr/u1 /u1

mount -t nfs nfssrv:/usr /users

mount -t nfs nfssrv:/usr/local /usr/local

Рис.4.1. Монтирование файловых систем NFS

Все четыре операции монтирования будут успешно выполнены. На клиенте поддерево /usr отражает полное поддерево /usr на nfssrv, поскольку клиент также смонтировал /usr/local. Поддерево /u1 на клиенте отображает поддерево /usr/u1 на nfssrv. Этот пример иллюстрирует, что вполне законно можно монтировать подкаталог экспортированной файловой стстемы (это позволяют не все реализации). Наконец, поддерево /users на клиенте отображает только ту часть поддерева /usr сервера, которая размещена на диске 0. Файловая система диска 1 под /users/local не видна.

Цели разработки

Первоначальная разработка NFS имела следующие цели:

NFS не должна ограничиваться операционной системой UNIX. Любая операционная система должна быть способной реализовать сервер и клиент NFS. Протокол не должен зависеть от каких либо определенных аппаратных средств. Должны быть реализованы простые механизмы восстановления в случае отказов сервера или клиента. Приложения должны иметь прозрачный доступ к удаленным файлам без использования специальных путевых имен или библиотек и без перекомпиляции. Для UNIX-клиентов должна поддерживаться семантика UNIX. Производительность NFS должна быть сравнима с производительностью локальных дисков. Реализация должна быть независимой от транспортных средств. Компоненты NFS

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

Протокол NFS определяет набор запросов (операций), которые могут быть направлены клиентом к серверу, а также набор аргументов и возвращаемые значения для каждого из этих запросов. Версия 1 этого протокола существовала только в недрах Sun Microsystems и никогда не была выпущена. Все реализации NFS (в том числе NFSv3) поддерживают версию 2 NFS (NFSv2), которая впервые была выпущена в 1985 году в SunOS 2.0. Версия 3 протокола была опубликована в 1993 году и реализована некоторыми фирмами-поставщиками. В таблице 3.1 приведен полный набор запросов NFS. Протокол удаленного вызова процедур (RPC) определяет формат всех взаимодействий между клиентом и сервером. Каждый запрос NFS посылается как пакет RPC. Расширенное представление данных (XDR - Extended Data Representation) обеспечивает машинно-независимый метод кодирования данных для пересылки через сеть. Все запросы RPC используют кодирование XDR для передачи данных. Следует отметить, что XDR и RPC используются для реализации многих других сервисов, помимо NFS. Программный код сервера NFS отвечает за обработку всех запросов клиента и обеспечивает доступ к экспортируемым файловым системам. Программный код клиента NFS реализует все обращения клиентской системы к удаленным файлам путем посылки серверу одного или нескольких запросов RPC. Протокол монтирования определяет семантику монтирования и размонтирования файловых систем NFS. NFS использует несколько фоновых процессов-демонов. На сервере набор демонов nfsd ожидают запросы клиентов NFS и отвечают на них. Демон mountd обрабатывает запросы монтирования. На клиенте набор демонов biod обрабатывает асинхронный ввод/вывод блоков файлов NFS. Менеджер блокировок сети (NLM - Network Lock Manager) и монитор состояния сети (NSM - Network Status Monitor) вместе обеспечивают средства для блокировки файлов в сети. Эти средства, хотя формально не связаны с NFS, можно найти в большинстве реализаций NFS. Они обеспечивают сервисы не возможные в базовом протоколе. NLM и NSM реализуют функционирование сервера с помощью демонов lockd и statd соответственно. Отсутствие сохранения состояния

Возможно наиболее важной характеристикой протокола NFS является то, что сервер, чтобы работать корректно, не запоминает состояний и не нуждается ни в какой информации о своих клиентах. Каждый запрос является полностью независимым от других запросов и содержит всю необходимую информацию для его обработки. Серверу не нужно поддерживать никаких записей о прошлых запросах клиентов, за исключением необязательных возможностей, которые могут использоваться с целью кэширования данных или для сбора статистики.

Например, в протоколе NFS отсутствуют запросы по открыванию и закрыванию файлов, поскольку они создали бы информацию о состоянии, которая должна запоминаться сервером. По этой же причине, запросы read и write передают в качестве параметра начальное смещение, в отличие от операций read и write с локальными файлами, которые получают смещение из объекта "открытый файл".

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

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

Протоколы с сохранением состояния требуют реализации сложных механизмов восстановления после отказа. Сервер должен обнаруживать отказы клиента и ликвидировать все состояния, связанные с этим клиентом. Если отказывает и перезагружается сервер, он должен уведомить клиентов так, чтобы они могли заново создать свое состояние на сервере.

Главная проблема работы без сохранения состояния заключается в том, что сервер должен зафиксировать все изменения в стабильной памяти до посылки ответа на запрос. Это означает, что не только данные файла, но и все метаданные, такие как индексные дескрипторы или косвенные блоки должны быть сброшены на диск до возвращения результатов. В противном случае сервер может потерять данные, о которых клиент уверен, что они успешно записались на диск. (Отказ системы может привести к потере данных даже в локальной файловой системе, но в таких случаях пользователи знают об отказе и о возможности потерять данные). Работа без сохранения состояния связана также с другими недостатками. Она требует отдельного протокола (NLM) для обеспечения блокировки файлов. Кроме того, чтобы решить проблемы производительности операций синхронной записи большинство клиентов кэшируют данные и метаданные локально. Но это противоречит гарантиям протокола о соблюдении согласованного состояния.

Общие сведения о работе и нагрузке NFS

По крайней мере на системах Sun чистые серверы NFS представляют собой наиболее простые для конфигурирования широкомасштабные серверы, главным образом потому, что они работают с одним и тем же кодом операционной системы (имеется только одна реализация сервера NFS, которую можно найти на Sun, поскольку она представляет собой связанный с операционной системой продукт). Более того, сами по себе сервисы NFS относительно просты, так как NFS выполняет всего 18 операций, которые своей семантикой ограничены размещением удаленных файлов и обеспечением к ним доступа. Они намного менее сложны, например, по сравнению с сервисами реляционной базы данных, где имеются более 75 операций, определенных стандартом SQL, причем эти операции применяются к сложному набору единиц данных, которые включают структурные отношения. NFS решает только часть этих проблем и поэтому гораздо проще.

Ниже в таблице 3.1 представлены 18 операций NFS. Шесть из них являются основными и представляют громадное большинство реально выполняемых операций как по количеству, так и по потреблению ресурсов: getattr, setattr, lookup, readlink, read и write. Эти операции реализуют поиск и модификацию атрибутов файла, поиск имени файла, разрешение символических связей, а также чтение и запись данных соответственно. Можно явно выделить два принципиально разных набора операций: в частности, операции read и write манипулируют действительным содержимым файла, в то время как другие операции манипулируют атрибутами файлов. Отличия между этими наборами операций определяются прежде всего типом нагрузки, которая ложится при выполнении соответствующего запроса на серверные и сетевые ресурсы системы.

Таблица 4.1. Операции NFS