Производительность, надежность и безопасность сетевой файловой системы

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

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

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

Надежность сетевой файловой системы в той или иной степени зависит от следующих событий:

• отказы компьютеров, на которых работают клиентские программы,

• разрывы сетевых связей между клиентами и серверами;

• отказы компьютеров, на которых работают серверные программы.

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

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

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

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

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

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

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

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

Во многих ФС с каждым разделяемым файлом связывается список управления доступом (Access Control List, ACL), обеспечивающий защиту данных от несанкционированного доступа по сети. В том случае, когда локальная файловая система поддерживает механизм ACL для файлов и каталогов при локальном доступе, сетевая файловая система использует этот механизм и при доступе по сети. Если же механизм защиты в локальной файловой системе отсутствует, то сетевой файловой системе приходится поддерживать его самостоятельно, иногда — упрощенным способом, защищая разделяемый каталог и входящие в него файлы и подкаталоги как единое целое.

Рассмотрим, например, как решила задачу контроля сетевого доступа к файлам компания Novell в ОС NetWare. Как уже было сказано, компания Novell вынуждена была разработать собственную версию локальной файловой системы, так как наиболее популярная файловая система для персональных компьютеров тех лет — FAT — не хранила в своих служебных структурах данных о правах пользователей. В то же время протокол взаимодействия с локальной файловой системой NetWare, названный NCP, сохранил привычный для приложений персональных компьютеров интерфейс доступа к FAT, расширив его передачей атрибутов, необходимых для удаленной проверки прав доступа. Протокол NCP является хорошим примером зависимости между свойствами интерфейса, предоставляемого приложениям на клиентских машинах, и свойствами локальной ФС сервера.

Совершенно другой прием для разграничения прав доступа для удаленных пользователей был применен в файловых системах компаний Microsoft и IBM, построенных на основе протокола SMB. В качестве локальной ФС на сервере была оставлена неизмененная файловая система FAT, но сами серверы стали хранить в ней дополнительные служебные файлы с указанием прав пользовате­лей на доступ к разделяемым каталогам. Эти права проверялись сервером при поступлении запроса из сети, локальные же запросы обслуживались в FAT по-прежнему без проверки прав доступа. Естественно, средства защиты каталогов нашли отражение в командах и ответах протокола SMB, а в качестве сетевого интерфейса на стороне клиентов стал использоваться расширенный интерфейс FAT. Позже протокол SMB был применен и для доступа к локальным файловым системам HPFS и NTFS.

В ОС семейства Windows NT существует два механизма защиты — на уровне разделяемых каталогов и на уровне локальных каталогов и файлов. Последний работает только в том случае, когда в качестве локальной файловой системы используется система NTFS, поддерживающая механизм ACL. Механизм защиты разделяемых каталогов нужен для того, чтобы защищать данные, хранящиеся в локальной файловой системе FAT, не имеющей механизмов защиты. В том случае, когда работает оба уровня защиты, у пользователей и администраторов могут иногда возникать некоторые логические сложности, связанные с определением реальных прав доступа как комбинации нескольких правил.

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