Модели сетевых файловых систем

Модель сетевой файловой системы

Сетевая файловая система (ФС) в общем случае включает следующие элементы:

• локальная файловая система;
• интерфейс локальной файловой системы;
• сервер сетевой файловой системы;
• клиент сетевой файловой системы;
• интерфейс сетевой файловой системы;
• протокол клиент-сервер сетевой файловой системы.

Клиенты сетевой ФС — это программы, которые работают на многочисленных компьютерах, подключенных к сети. Эти программы обслуживают запросы приложений на доступ к файлам, хранящимся на удаленном компьютере. В качестве таких приложений часто выступают графические или символьные оболочки ОС, такие как Windows Explorer или UNIX shell, а также любые другие пользовательские программы. Рис. 10.1. Модель сетевой файловой системы Клиент сетевой ФС передает по сети запросы другому программному компоненту — серверу сетевой ФС, работающему на удаленном компьютере. Сервер, получив запрос, может выполнить его либо самостоятельно, либо, что является более распространенным вариантом, передать запрос локальной файловой системе для отработки. После получения ответа от локальной файловой системы сервер передает его по сети клиенту, а тот, в свою очередь, — приложению, обратившемуся с запросом. Приложения обращаются к клиенту сетевой ФС, используя определенный программный интерфейс, который в данном случае является интерфейсом сетевой файловой системы. Этот интерфейс стараются сделать как можно более похожим на интерфейс локальной файловой системы, чтобы соблюсти принцип прозрачности. При полном совпадении интерфейсов приложение может обращаться к локальным и удаленным файлам и каталогам с помощью одних и тех же системных вызовов, совершенно не принимая во внимание места хранения данных. Например, если на серверах сети используются локальные файловые системы FAT, то интерфейс сетевой файловой системы повторяет системные вызовы FAT. Клиент и сервер сетевой файловой системы взаимодействуют друг с другом по сети по определенному протоколу. В случае совпадения интерфейсов локальной и сетевой файловых систем этот протокол может быть достаточно простым — в его функции будет входить ретрансляция серверу запросов, принятых клиентом от приложений, с которыми тот затем будет обращаться к локальной файловой системе. Одним из механизмов, используемых для этой цели, может быть механизм RPC. Рассмотрим несколько ситуаций, в которых протокол взаимодействия клиента и сервера файловой системы может повлиять на эффективность удаленного доступа к файлам.

• Отказ компьютера, па котором выполняется сервер сетевой файловой системы, во время сеанса связи с клиентом. Локальная файловая система запоминает состояние последовательных операций, которые приложение выполняет с одним и тем же файлом, за счет ведения внутренней системной таблицы открытых файлов (системные вызовы open, read, write изменяют состояние этой таблицы). Если таблица открытых файлов хранится на серверном компьютере, то после его перезагрузки, вызванной крахом системы, содержимое этой таблицы теряется, так что приложение, работающее на клиентском компьютере, не может продолжить нормальную работу с открытыми до краха файлами. Протокол должен позволять приложениям выйти из такой ситуации с наименьшими потерями. Одно из решений этой проблемы основано на передаче функции ведения и хранения таблицы открытых файлов от сервера клиенту. Файловый сервер в этом варианте получил название «stateless», то есть «не запоминающий состояния». Протокол клиент-сервер при такой организации упрощается, так как перезагрузка сервера приводит только к паузе в обслуживании, но работа с файлами может быть после этого продолжена безболезненно для клиента.
• Большие задержки обслуживания из-за заторов в сети и перегрузки файлового сервера при подключении большого числа клиентов. Протокол может для решения этой проблемы организовывать кэширование файлов целиком или частично на стороне клиента. При этом протокол должен учитывать то обстоятельство, что в сети при этом может образоваться одновременно большое количество копий одного и того же файла, которые независимо могут модифицироваться разными пользователями. То есть протокол должен каким-то образом обеспечивать согласованность копий файлов, имеющихся на разных компьютерах.
• Потери данных и разрушение целостности файловой системы при сбоях и отказах компьютеров, играющих роль файловых серверов. Для повышения отказоустойчивости файловой системы в сети можно хранить несколько копий каждого файла (или целиком локальной файловой системы), причем каждую копию — на отдельном компьютере. Такие копии файлов называются репликами (replica). Протокол сетевого доступа к файлам должен учитывать такую организацию файловой службы, например, обращаясь в случае отказа одного файлового сервера к другому, работоспособному и поддерживающему реплику требуемого файла. Репликация файлов не только повышает отказоустойчивость, но решает также и проблему перегрузки файловых серверов, так как запросы к файлам распределяются между несколькими серверами и повышают производительность сетевой файловой системы. Репликация в некоторых аспектах похожа на кэширование — в том и другом случаях в сети создается несколько копий одного и того же файла, при этом повышается скорость доступа к данным. Основным отличием репликации от кэширования является то, что реплики хранятся на файловых серверах, а кэшированные файлы — на клиентах.
• Аутентификация выполняется на одном компьютере, например на клиентском, а авторизация, то есть проверка прав доступа к каталогам и файлам, — на другом, выполняющем роль файлового сервера. Эта общая проблема всех сетевых служб должна каким-то образом учитываться и протоколом взаимодействия клиентов и серверов файловой службы 1 .

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

Источник

22. Модели хранения информации в файловых системах. Надёжность и непротиворечивость файловых систем.

Файловый сервер — сервер, предоставляющий свои данные для доступа прочим компьютерам сети. В сети может быть множество как серверов, так и клиентов.

Интерфейс делается как на локальной системе для прозрачности.

Принцип построения сетевых файловых систем. Обращение к удалённому файлу может происходить в центральной файловой системе. Уменьшается число атрибутов.

1. Модель переноса данных

1. модель считывания записи — чтобы получить доступ к файлу, процесс сначала считывает его с удалённого сервера, а потом обновлённый файл отправляется обратно на сервер. Преимуществом является то, что модель простая и позволяет переносить файл целиком.
2. Модель удалённого доступа — файл остаётся на сервере, а клиент посылает серверу команды для работы с файлом. «+» — файл не надо перемещать.

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

1. Локальная файловая система сервера.
2. Интерфейс локальной файловой системы сервера
3. Для связи с клиентом должен быть сервер сетевой файловой системы.

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

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

1. Кеширование файлов: происходит всегда только на стороне клиента.

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

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

1. Слабая согласованность – изменение внесенное в одну из реплик немедленно становится видно клиенту. Далее это изменение

распространяется на другие реплики. Данные реплик остаются несогласованными.

1. Строгая согласованность – изменение становится доступным клиенту только после его распространения на все реплики.

Алгоритмы разделения файлов:

1. Для централизованных систем
2. Для сетевых систем

Это модели:

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

23. Организация доступа к удалённым данным. Доступ, основанный на файловой системе. Модели переноса.

Реализация сервисов сетевых файловых систем: 1) сервис хранения файлов. Для каждого файла есть системный файловый идентификатор (SFID); 2) сервис каталога файлов. Каталог – некоторый структурированный объект, состоящий из списка элементов. Общая схема доступа к файлу, в четыре этапа: 1) обращение к сервису каталогов, с указанием текстового имени файла; 2) сервис каталога файлов в ответ на такой запрос выдаёт SFID; 3) обращение к сервису хранения файлов по полученному SFID; 4) сервис хранения файлов в ответ на это обращение выдаётся соответствующая инфа. При этом системой ещё решается задача одновременных запросов. Нужно блокировать файл. В сетевых ФС может быть блокирован доступ не ко всему файлу, а только к некоторой его части. Архитектуры хранения сетевых файловых сервисов подразделяются на открытые и закрытые. Если архитектура закрытая, то в системе существует единый сервис, предоставляющий клиентам как операции сервиса каталога, так и сервиса хранения: А у открытой – всё как в обычном четырёхэтапном доступе к файлу. Распределение серверной и клиентской частей между узлами сети: 1) на всех узлах сети реализуется одно и то же ПО, которое включает как клиентскую, там и серверную часть и любой узел можно предложить услуги файловой службы; 2) файловый сервер представляет собой специализированный компонент серверной ОС, отсутствующий в клиентских компьютерах. Две схемы реализации серверной части: 1) схема с запоминанием данных о последовательности операций (stateful) – работают по схеме обычной локальной ФС. Более короткие сообщения при запросах, выше производительность, лучше возможности блокировки файлов; 2) без запоминания данных о последовательности операций (stateless) – не хранят никакой информации о текущем состоянии клиента. Отказоустойчивый, меньше памяти расходуется, нет ограничения на число открытых файлов, отказ клиента не создаёт проблем для сервера. Кэширование в файловых системах позволяет повысить скорость доступа и повышает надёжность ФС, Три вопроса, решаемые при кэшировании: 1) место расположения кэша. Имеется три места, где может храниться кэш: память сервера, память клиента и диск клиента; 2) способы согласования копий кэша. Проблема возникает, когда в сети есть несколько копий одного и того же файла, которые хранятся в кэше клиентов. Способы: — алгоритм сквозной записи. Кэшируемый элемент модифицируется, новое значение записывается в кэш и одновременно посылается на сервер для обновления главной копии файла; — алгоритм отложенной записи. В этом случае при кэшировании файла на клиенте запись в главный кэш не производится, а просто отмечается, что файл модифицируется. Запись в главный кэш осуществляется через определённые моменты времени; — запись по закрытию. Запись на сервер происходит только по закрытию файла; 3) проверка достоверности кэша. Схема кэширования определяется моделью переноса файлов между клиентами и сервером (загрузки-выгрузки или удалённого доступа). LPC (Local Procedure Call) и RPC (Remote Procedure Call). Вызов удалённых процедур в сетевых ОС реализован так, чтобы этот вызов был как будто локальной процедуры. Это и есть прозрачность – посредника не видно, его как бы нет.

Источник