Курсовая работа: Основы конфигурирования сетевых файловых систем (на примере 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