Проблемы сетевых файловых систем

Нетрудно обнаружить, что в прошлом каждое радикальное изменение операционных сред индуцировало новации в файловых системах. Скажем, в ранних версиях MS-DOS внешняя память для постоянного хранения данных была организована в виде иерархии каталогов, содержащих именованные файлы. ОС предлагала API-интерфейсы для наполнения/корректировки файлов и манипуляции каталогами — вот, пожалуй, и все. Существенным шагом стало появление операционных систем с многозадачностью (например, Windows 95, хотя многозадачность в ней и мнимая). В такой ОС несколько задач могут открыть один и тот же файл, поэтому ее разработчикам пришлось позаботиться об управлении параллельным доступом. У создателей Unix с ее многопользовательским режимом работы, столкнувшихся с необходимостью обеспечить разграничение доступа к данным, файлы получили владельцев, а каждый пользователь стал обладателем определенного набора прав доступа.

Когда отдельные компьютеры соединились сетями, ничего подобного стройной модели файловых систем (теперь их можно называть локальными) не возникло, и такое положение в большой степени сохраняется до сих пор. Как показало время, решения, скажем, от Microsoft или Novell, оказались недостаточно общими, ограничивающими возможности создания приложений. Появились протоколы HTTP и FTP, которые предоставляли очень хороший способ удаленного доступа к данным, но фактически были частными. Многие задачи распределенной обработки данных по-прежнему решаются на уровне сокетов, базового механизма ОС для обмена сообщениями. Более того, на практике довольно типичной остается ситуация, когда данные загружаются с сервера в локальную файловую систему, обрабатываются и затем возвращаются обратно.

Не секрет, что многие наиболее общие и качественные решения приходят в компьютерную индустрию из мира Unix. Что касается сетевого доступа к данным, то вектор его развития в середине 80-х задали компания Sun Microsystems и Университет Карнеги-Меллон, которые предложили распределенные файловые системы NFS и AFS соответственно. Нельзя сказать, что в этих разработках содержались исчерпывающие ответы на все принципиальные проблемы сетевых файловых систем. Так, область применения распределенных файловых систем, по-видимому, ограничена корпоративными сетями с централизованным администрированием, а при переходе к масштабам Internet многие решения не проходят. Тем не менее, они по-прежнему заслуживают самого пристального внимания. NFS стала фактическим стандартом для интеграции сред Windows и Unix в гетерогенных локальных сетях. Кроме того, распределенные файловые системы хорошо иллюстрируют болевые точки более широкого подхода.

Удаленный доступ к данным

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

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

Конечно, в этой ситуации — как и во многих других — можно найти выход из положения, заготовив специальные командные файлы для автоматизированной доставки файлов. (Здесь может оказаться уместным замечание о частных и общих решениях. Часто думается, что частное решение проще и «дешевле», но затем получается, что для его применения нужны различные вспомогательные средства, и число «подпорок» катастрофически нарастает.)

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

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

Какой должна быть сетевая файловая система и в чем состоит ее отличие от локальной?

Даже на одном компьютере располагается большое количество файлов, и если бы они не были упорядочены, с ними было бы невозможно справиться. Модель файловой системы Unix предполагает очень хорошее решение — иерархическую организацию, в которой каждый новый уровень озаглавлен каталогом. Эта модель ориентирована на пользователей; каждый из них имеет собственный домашний каталог и может организовывать все внутри по своему разумению, имея при этом возможность сделать так, чтобы никто из посторонних не сможет испортить или даже посмотреть его собственность. Каждый файл получает имя в виде маршрута от корня до своего местоположения в едином дереве.

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

В DFS построение единого файлового пространства производится централизовано — на выделенном сервере, причем одно и то же объединенное дерево каталогов становится доступным всем клиентским компьютерам. В NFS монтирование нужно выполнять отдельно на каждом компьютере, и, вообще говоря, структура файлового пространства может отличаться от клиента к клиенту.

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

Другое дело, что в обоих вариантах требуется выполнить значительную административную работу (в DFS она выполняется более централизовано) как по поддержанию файловой структуры, так и по согласованию прав доступа пользователей, доверительных отношений между компьютерами. Практически безболезненно обслуживать NFS можно только при небольшом числе компьютеров (10-20) и пользователей. DFS, конечно, обслуживается проще, но централизованное администрирование, делает и ее неподходящей для открытой распределенной среды масштабов Internet.

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

Второй способ именования файлов в сети — универсальная адресация наподобие URL, идея которой проста — адрес файла составляется из двух компонентов: имени компьютера, на котором он лежит, и имени в локальной файловой системе. Понятно, что при таком способе адресуемыми становятся вообще все файлы, существующие в природе. Другой вопрос, являются ли они реально доступными. Чтобы это было так, на экспортирующем компьютере должен работать сервер файлового доступа, определяющий протокол, в соответствии с которым может происходить работа с файлами. Независимость от протокола — важное достоинство универсальной адресации. Кроме того, она обладает также свойством однородности именования — все файлы имеют фиксированные имена независимо от того, с какого клиентского компьютера они используются.

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

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

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

Итак, в сетевой файловой системе были бы желательны следующие свойства именования:
• однородность;
• независимость имен от физического расположения файлов;
• ориентация на персональное владение файлами.

При больших масштабах сети эти свойства должны сочетаться с отсутствием централизованного администрирования.

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

С другой стороны базовая функциональность локального API-интерфейса для доступа к файлам вполне годится и для сетевой среды. Сегодня, по-видимому, правильным ориентиром будет соответствие стандарту IEEE/POSIX 1003.1, определяющему интерфейс доступа к неструктурированным данным (байтовые и потоковые файлы). Хотя этот стандарт спроектирован для локальных систем и не учитывает особенности сетевых приложений, специфицированные в нем примитивы в большой степени подходят и для распределенных файловых систем.

Более рационально модифицировать реализацию операций файловой системы в рамках заданных интерфейсов и функциональности, учтя передачу данных по сети. Благодаря этому любые программы, в которых используются обычные операции над файлами open(), read(), write() и т.д., становятся сетевыми и единообразно работают как с локальными, так и с удаленными файлами — это свойство называется прозрачностью удаленного доступа. Все стандартные программы, входящие в состав ОС — утилиты, компиляторы и пр. — будут без изменения обращаться к удаленным файловым системам для доступа к их каталогам и файлам по глобальным именам. Так, пользователи на Unix-машинах смогут по-прежнему использовать команду cd для смены текущего каталога, ls — для просмотра его содержимого, mkdir — для создания нового каталога и т.д.

Модификация ПО на уровне двоичных кодов — классическая проблема программирования, не получившая, правда, за долгие годы удовлетворительного решения. Несмотря на это, известно несколько методов прозрачного изменения файловой системы (см. например, http://www.cs.ucsb.edu/research/ufo).

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

Для работы с распределенными файловыми системами в ядро ОС Unix внедрен специальный интерфейс Virtual File System (VFS). По сути, он вводит абстрактный тип данных — файловую систему со стандартизованным набором операций и структурами данных, так что ядро ОС может быть расширено новыми реализациями. В такой интерпретации под файловой системой понимается, во-первых, способ организации информации на внешнем носителе, набор процедур и структур данных, обычно размещающихся в ядре, и, во-вторых, конкретные данные, хранящиеся на внешнем носителе в соответствии с типом файловой системы. На одном компьютере может одновременно существовать несколько как однотипных, так и разнотипных локальных файловых систем, объединенных в одно дерево с общим корнем. Благодаря переключателю VFS все программы работают с данными независимо от их принадлежности тому или иному типу файловых систем. При открытии файла в операционной системе с VFS производится разбор имени по входящим в имя каталогам. Если какой-то из них является точкой монтирования, то происходит переключение на иной тип файловой системы, а последующий разбор и все операции с каталогами и файлами будут выполняться процедурами, соответствующими именно этому типу.

Подключение новой локальной файловой системы производится путем ее инициализации (mkfs) и включения в дерево каталогов посредством монтирования (mount). Точно также подключаются и удаленные файловые системы. Более того, распределенные файловые системы NFS и DFS в рамках VFS оказываются не более чем сетевым интерфейсом к локальным файловым системам. Процедуры распределенной файловой системы, реализующие операции с файлами и выполняющиеся на клиенте, инициируют удаленное обращение к серверу, там запускается соответствующая операция локальной файловой системы, непосредственно работающая с диском, а результат возвращается клиенту.

Возможен ли вообще эффективный удаленный доступ при использовании современного сетевого оборудования? Локальный доступ надежен и предсказуем: время записи и чтения данных, как правило, гарантировано, а сбои редки.

Используемые в удаленном вводе/выводе сети делят полосу пропускания между многими потоками данных, что влечет потенциально большие задержки и низкую пропускную способность. Даже при хороших соединениях время передачи плохо предсказуемо и может доходить до 100 мсек, что на два порядка больше времени доступа к диску. Если же говорить об удаленном доступе для высокопроизводительных вычислений (а это одно из наиболее важных и ярких приложений), то оценка времени передачи в 100 мсек на три-четыре порядка больше времени передачи данных в типичном параллельном компьютере. Кроме того, значительно меньшей становится пропускная способность и число путей доступа (в параллельных компьютерах обычно имеется несколько интерфейсов процессор-диск).

Улучшить ситуацию можно с помощью ряда программных механизмов: буферизации, кэширования, репликации и резервирования. Буферизация позволяет скомпоновать несколько операций файлового доступа в один пакет, уменьшив тем самым число пересылок. Кэширование предполагает достаточно длительное хранение часто используемых файлов во временной памяти и сводит удаленный доступ к локальному. С помощью репликации создается несколько копий файлов на разных серверах, процессы обработки распределяются по копиям — тем самым нагрузка на каждый отдельный сервер уменьшается. Что касается резервирования, то здесь началу обработки файла предшествует его «заказ», в результате чего файл передается в кэш исполнительного компьютера. К методам резервирования можно отнести и механизм гарантированного качества обслуживания (QoS), в котором заказывается фиксированная пропускная полоса.

Однако для высокопроизводительных сетевых приложений перечисленных приемов недостаточно; применяется расширение стандартного набора файловых операций. Расширения, имеющие корни в параллельных библиотеках ввода/вывода, включают асинхронные и массовые операции. Расширение можно реализовать прозрачно; например, для работы с DFS стандартный вариант VFS был преобразован в VFS+. В тех случаях, когда проблема наследования ПО не столь актуальна, вполне годится и более простой подход — дополнительные библиотеки высокопроизводительного ввода/вывода [1-2].

Как и в локальном варианте, сетевая файловая система должна обеспечивать коллективный доступ к файлам. Основная проблема при этом — согласование доступа к данным. В локальном варианте этот вопрос практически полностью отдается на откуп пользователям. Правда, когда два процесса одновременно пишут в общий файл, его модификация блокируется на уровне описателя i-node, что предотвращает нарушение целостности данных в рамках выполнения одной операции write.

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

Коллективный доступ, пожалуй, самая тяжелая проблема из всех рассмотренных, до сих пор не получила удовлетворительного решения. Во всех известных подходах остается элемент случайности — например, при одновременной записи обычно применяется стратегия «выигрывает последний».

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

В связи с проблемами надежности сетевого ввода/вывода обычно рассматриваются три ситуации: разрыв связи между клиентом и сервером, сбой сервера и сбой клиента. Минимальное решение для всех случаев — выдача сообщения об ошибке в одной из форм: код возврата после аварийного завершения операции, либо асинхронный вызов call-back функции.

Основные коллизии при аварии могут возникнуть на сервере — нарушение целостности данных, ошибки в файловой системе. Известны два типа серверов: с памятью (statefull) и без памяти (stateless). Серверы без памяти (таковы серверы NFS) работают как конечный автомат, отрабатывая независимо каждую очередную файловую операцию. Соответственно, здесь восстановление от ошибок ложится на клиентов и на штатные средства ОС (fsck); достоинство такого варианта — простота. В серверах с памятью (DFS) используются такие приемы, как журналирование, откат и быстрое восстановление.

В эту же категорию можно отнести проблемы, обусловленные качеством современных сетей. При их коллективном использовании время передачи данных может варьироваться очень сильно. В такой среде рекомендуется воспользоваться сетевыми технологиями, обеспечивающими гарантированное качество, например ATM. Из более доступных средств — наличие нескольких стратегий ввода/вывода с возможностью выбора оптимальной.

Как и в вопросе именования файлов, безопасность для сетевой файловой среды необходимо существенно пересмотреть на уровне модели. Это касается всех аспектов: аутентификации, авторизации, секретности и пр., но в связи с файловой системой уместно остановиться на правах доступа. Поскольку речь идет об объединении локальных файловых систем разных компьютеров, единственный пользовательский процесс должен отображаться во множество контекстов безопасности. При этом аутентификация пользователя производится однократно — при входе в систему.

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

Пока подобная схема реализуется только в исследовательских проектах; далеко не все проблемы решены. Так, например, в открытых средах крупного масштаба трудно рассчитывать на то, что все пользователи будут зарегистрированы на всех доступных им компьютерах. Скорее, следует применить динамическую авторизацию (mapping) с созданием контекста безопасности в соответствии с глобальными идентификаторами или сертификатами. Вторая проблема — как без централизованного администрирования моделировать различные уровни привилегий пользователей и доверительных отношений между организациями? Кто их должен устанавливать? (Вопросы глобальной безопасности рассматриваются, например, в [3].)

Оценки существующих систем

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

Файловая система NFS [4] разработана компанией Sun Microsystems в 1984 году и к настоящему времени перенесена на все распространенные платформы; число инсталляций NFS оценивается в 10 млн. экземпляров. Задача NFS — обеспечение прозрачного удаленного доступа к локальным файловым системам компьютеров разных типов. NFS спроектирована в архитектуре клиент-сервер, где сервер — это программа на компьютере, предоставляющем свои файловые ресурсы, а клиент — программа, осуществляющая к ним доступ по сети. Основной принцип функционирования NFS можно сформулировать так: при выполнении удаленных файловых операций на клиенте все обращения к ядру ОС передаются по сети на сервер, где они собственно и выполняются, а результаты возвращаются клиенту. Реализация сетевого обмена в NFS опирается на механизм RPC.

Пространство файлов. NFS не имеет единого глобального пространства именования файлов — даже в рамках одной обслуживаемой сети каждому клиенту может быть доступно свое подмножество удаленных файлов. Вместо используется механизм «предварительного связывания» (монтирования). Администратор клиента может включить удаленную файловую систему в дерево локальной файловой системы с помощью команды mount. Эта операция выполняется однократно, после чего смонтированная удаленная файловая система становится частью дерева локальной на равных правах с остальными каталогами. Преимущество такого подхода — клиент имеет дело с именем удаленного компьютера всего один раз, в команде mount.

Технически доступ к удаленным файлам обеспечивается согласованными действиями администраторов сервера и клиента. На стороне сервера производится экспорт какого-либо r-каталога путем добавления в файл /etc/exports строки <имя r-каталога> access=<имя компьютера-клиента> и выполняется утилита exportfs -a.

На стороне клиента администратор создает пустой каталог, который будет соответствовать удаленно расположенному и монтирует последний на локальный: mount <имя сервера>:<имя r-каталога> <локальное имя каталога>. После этого клиент может работать со всеми файлами удаленного каталога, указывая маршрут в своей локальной файловой системе.

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

Администрирование файлового пространства в NFS нельзя назвать ни централизованным, ни динамическим — подключение удаленных файловых систем производится вручную и на серверной, и на клиентской стороне.

Прозрачность. Именно при разработке NFS был предложен метод обеспечения прозрачного переключения файловых систем — интерфейс VFS, ставший стандартом для Unix SVR4. В результате при работе с NFS удаленные файлы делаются доступными программе без каких-либо ее изменений, даже без перегенерации системы. Установка и конфигурирование NFS сами по себе превращают локальные программы в глобальные, так что они не знают, к каким файлам — локальным или удаленным — осуществляется доступ. Действительно, вся новая функциональность файловой системы оказывается реализованной на уровне расширения ядра ОС.

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

Производительность. Считается, что NFS работает со скоростью локального диска с интерфейсом SCSI, по крайней мере, такая задача ставилась при ее разработке. Для повышения производительности используется буферизация, поддерживающая опережающее чтение и запись с запаздыванием. Запись идет медленней, чем чтение: так как протокол NFS не имеет «памяти», все модифицированные данные должны быть записаны на диск до возвращения результата клиенту. При записи выталкивается не только блок данных, но и все косвенно модифицированные блоки, включая блок, содержащий i-node.

NFS кэширует файлы на стороне клиента, используя стратегию, основанную исключительно на временной информации: после того как файл получен, предполагается, что он актуален в течение некоего фиксированного промежутка (например, 3 секунды для файла, 30 секунд для каталога). Такой механизм не дает никаких гарантий согласованности кэшей в случае, когда файл одновременно используется несколькими клиентами, — некоторые из них могут получить устаревшую версию.

Коллективный доступ. В протокол NFS умышленно не включено блокирование доступа к удаленным файлам как средства синхронизации параллельных операций нескольких клиентов. Предполагается, что они могут воспользоваться средствами RPC. Однако происходит следующее. В локальных файловых системах модификации файла блокируются на уровне i-node, и это предотвращает нарушение целостности данных при одновременных операциях write(). Поскольку сервер NFS не поддерживает блокирования между запросами, а write() может разворачиваться в несколько запросов RPC, два клиента, пишущих в один удаленный файл, при длинных записях целостность данных может быть нарушена.

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

Безопасность. В NFS она основана на том, что каждый из пользователей должен быть зарегистрирован на всех доступных ему серверах и, более того, он должен иметь везде одни и те же идентификаторы UID, GID. Для этого либо копируются по всей сети файлы /etc/passwd и /etc/group, либо производится согласование UID и GID. Ясно, что если сеть большая, администрирование в подобном стиле становится проблематичным. Поэтому для NFS была разработана Сетевая Информационная Служба (NIS), представляющая собой распределенную базу данных, с помощью которой можно централизованно обслуживать конфигурационные файлы.

NFS использует метод контроля прав доступа, полностью заимствованный из Unix, поэтому пользователи не замечают никакой разницы. Различные идентификационные параметры вставляются в заголовок каждого сообщения, передающегося посредством RPC между клиентом и сервером. Сервер используют переданные идентификаторы UID и GID для проверки прав в точности так же, как и в локальном варианте.

Файловая система DFS [5] была разработана компанией Transarc и впоследствии включена OSF в среду распределенных вычислений (DCE, Distributed Computing Environment), куда помимо нее входят еще пять служб: нитей, удаленного вызова процедур, безопасности, каталогов и времени. В отличие от NFS, DFS предлагает централизованное решение адресации файлов, безопасности и администрирования файловой системы. Соответствующие службы реализованы в виде серверов, запускаемых на одной или нескольких машинах. Состав серверов может меняться в зависимости от потребностей и сложности сети.

Пространство файлов. В обслуживаемой сети DFS определяет единое пространство файлов со следующей структурой имен:

/.../<имя ячейки>/fs/<локальное имя>
например:
/.../C=US/O=OSF/OU=
Cambridge/fs/usr/nl/file.c

Здесь fs — стандартный переключатель, ограничивающий собственно имя файла. Пространство файлов разбито на ячейки, образующие префикс полного маршрутного имени файла. Внутри ячейки адресация упрощается: имя ячейки может опускаться.

Клиенты могут обращаться и к файлам, лежащим в других ячейках. Однако в сети с несколькими ячейками конфигурация DFS усложняется: полная адресация файлов поддерживается службой глобальных каталогов (GDS или DNS). Разбиение на ячейки не связано исключительно с географией размещения компьютеров. Благодаря этому подразделения получают автономию и могут проводить собственную политику администрирования.

Как и NFS, DFS позволяет объединять путем монтирования локальные файловые системы различных типов, но кроме того, DFS вводит свой собственный тип — LFS DCE с дополнительными возможностями, ориентированными на сетевую среду. Это исключение — обычно сетевые файловые среды опираются исключительно на «родные» для нижележащих ОС файловые системы. NFS и DFS хорошо совмещаются: NFS-компьютеры могут монтировать файловое пространство DFS и работать с ними в соответствии с семантикой NFS.

Фактическое формирование файлового пространства (то есть включение отдельных файловых систем в общую структуру) происходит в NFS и DFS сходным образом — путем монтирования. Принципиальное отличие состоит в том, что монтирование в DFS производится на сервере и его результаты становятся доступны всем клиентам. В NFS же монтирование новой файловой системы производится отдельно на каждом клиенте и точка монтирования каждый раз может быть другой.

Прозрачность. С точки зрения клиента DFS обеспечивает такую же полную прозрачность файловых операций, что и NFS. Тем более, что реализация прозрачности использует тот же способ — интерфейс VFS, правда, расширенный до VFS+ (в DFS увеличен набор файловых операций).

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

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

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

Хотя DFS, как и NFS, базируется на RPC, серверы файлов в DFS «запоминают» состояние обработки файла, сохраняя историю запросов и обменов с клиентами. Для обеспечения корректности и синхронизации операций файловой системы в DFS используется механизм квитанций (token). Есть несколько типов квитанций: открытия, статуса, данных и блокирования, в которых устанавливаются права доступа клиентов к определенному файлу или даже его сегменту. Создает квитанции файл-сервер, передавая их запрашивающим клиентам и запоминая, кому они выданы. Контроль доступа проявляется, например, в том, что перед тем как выдать квитанцию записи, отзываются назад выданные ранее квитанции чтения.

Надежность. В DFS добавлено журналирование — специальный механизм восстановления серверов после сбоя. Журналирование производит запись системных метаданных, обеспечивающих целостность структуры файловой системы и сокращающих время восстановления после падения системы. Журналирование в комплексе со средствами восстановления позволяют системе либо довести до конца, либо полностью отменить прерванные операции, перед тем как вернуться к нормальной работе после перезагрузки системы.

Безопасность. DFS контролирует доступ к файлам и каталогам с помощью списков контроля доступа — DCE Access Control List (ACL). Это относительно новый для Unix подход к правам доступа, отличительная особенность которого — централизация. В стандартных файловых системах и NFS для того, чтобы пользователь мог работать с какими-либо ресурсами, требуется его регистрация на компьютере. В противоположность этому, механизм ACL делает регистрацию в локальных системах излишней. Она производится в централизованной службе безопасности, обслуживаемой отдельным сервером. В хранящихся на нем списках ACL, определяются глобальные идентификаторы пользователя и соответствующие ресурсы локальных систем, которые ему предоставляются. При аутентификации пользователя происходит унифицированное обращение к серверу безопасности, который и устанавливает права доступа.

В DFS число разновидностей прав доступа расширено, их шесть: стандартные для Unix права на чтение, запись и выполнение (поиск), а также три дополнительных — управление, вставка и удаление. При взаимодействии с ОС дополнительные права отображаются в стандартные.

К сожалению, защита с помощью ACL применима только для файлов из LFS DCE, стандартные же файловые системы «защищаются» обычными средствами.

Заключение

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