Сетевые службы

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

ГБОУ СПО Колледж предпринимательства №15

Реферат

Тема: Сетевые службы

Выполнил:

Студент группы ИС0112

Иванов Владислав

Преподаватель:

Куковский.Б.Л

Москва 2013г



Содержание

сетевая файловая система кэш

1. Введение

2. Сетевые файловые системы

2.1 Принципы построения

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

2.3 Интерфейс сетевой файловой службы

2.3.1 Структура файла

2.3.2 Модифицируемость файлов

2.3.3 Семантика разделения файлов

2.3.4 Контроль доступа

2.3.5 Единица доступа

3. Вопросы реализации сетевой файловой системы

3.1 Размещение клиентов и серверов по компьютерам и в ОС

3.2 Файловые серверы типа stateful и stateless

3.3 Кэширование

3.3.1 Место расположения кэша

3.3.2 Способы распространения модификаций

3.3.3 Проверка достоверности кэша

3.4 Репликация

3.4.1 Прозрачность репликации

3.4.2 Согласование реплик

3.5 Примеры сетевых файловых служб: FTP и NFS

3.5.1 Протокол передачи файлов FTP

3.5.2 Файловая система NFS

Выводы

Список использованной литературы



1. Введение

Практически все современные операционные системы являются сетевыми, то есть позволяют своим пользователям получать доступ не только к локальным ресурсам их собственных компьютеров, но и к ресурсам других компьютеров, подключенных к сети (конечно, только в том случае, если удаленные ресурсы объявлены разделяемыми и у пользователя есть соответствующие права на доступ к ним).

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



2. Сетевые файловые системы

2.1 Принципы построения

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

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

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

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

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

Современные сетевые файловые системы пока еще не полностью соответствуют идеалу. В большинстве коммерческих ОС (таких, как ОС семейств UNIX, Windows NT/2000, NetWare) пользователь должен явно указать имя файлового сервера при доступе к его ресурсам. Большую степень прозрачности демонстрируют сетевые файловые системы экспериментальных операционных систем -- Amoeba, Mach и Chorus. Тем не менее работы в этом направлении продолжаются и сетевые файловые системы постепенно приближаются к истинно распределенным.  

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

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

 локальная файловая система;

 интерфейс локальной файловой системы;

 сервер сетевой файловой системы;

 клиент сетевой файловой системы;

 интерфейс сетевой файловой системы;

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

Клиенты сетевой ФС -- это программы, которые работают на многочисленных компьютерах, подключенных к сети. Эти программы обслуживают запросы приложений на доступ к файлам, хранящимся на удаленном компьютере. В качестве таких приложений часто выступают графические или символьные оболочки ОС, такие как Windows Explorer или UNIX shell, а также любые другие пользовательские программы.

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

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

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

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

Рассмотрим сетевую файловую систему, построенную на базе локальной файловой системы FAT и использующую в качестве протокола клиент-сервер протокол SMB (Server Message Block), который был совместно разработан компаниями Microsoft, Intel и IBM и до сих пор является основой сетевой файловой службы в операционных системах семейства Windows (его последние расширенные версии получили название Common Internet File System, CIFS).

Как и все протоколы файловых служб, этот протокол работает на прикладном уровне модели OSI. Для передачи по сети своих сообщений протокол SMB использует различные транспортные протоколы. Исторически основным протоколом передачи сообщений SMB был протокол NetBIOS (и его более поздняя реализация NetBEUI), но сейчас сообщения SMB могут передаваться и с помощью других протоколов, например TCP/UDP и IPX.

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

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

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

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

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

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

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

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

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

Поэтому для одной и той же локальной файловой системы могут существовать различные протоколы сетевой файловой системы. Так, к файловой системе NTFS сегодня можно получить доступ с помощью различных протоколов (рис. 2), в том числе таких распространенных, как SMB, NCP (NetWare Control Protocol -- основной протокол доступа к файлам и принтерам сетевой ОС NetWare компании Novell) и NFS (Network File System -- протокол сетевой файловой системы компании Sun Microsystems, чрезвычайно популярный в различных вариантах ОС семейства UNIX).

Рис. 2. Доступ к одной локальной файловой системе с помощью нескольких протоколов клиент-сервер

С другой стороны, помощью одного и того же протокола может реализовываться удаленный доступ к локальным файловым системам разного типа. Например, протокол SMB используется для доступа не только к файловой системе FAT, но и к файловым системам NTFS и HPFS (рис. 3). Эти файловые системы могут располагаться как на разных, так и на одном компьютере.

Рис. 3. Доступ к локальным файловым системам различного типа с помощью одного протокола клиент-сервер

За достаточно долгий срок развития сетей в них утвердилось несколько сетевых файловых систем. В локальных сетях на протяжении многих лет доминировала сетевая операционная система NetWare, которая использовала на файловых серверах оригинальную локальную файловую систему, также носящую имя NetWare, и уже упомянутый протокол NCR Клиенты этой сетевой файловой системы обеспечивали приложениям расширенный интерфейс файловой системы FAT -- расширения включали в основном поддержку разграничения прав доступа к файлам и каталогам. Интерфейс FAT был выбран как наиболее распространенный локальный интерфейс для приложений и пользователей персональных компьютеров, работающих под управлением MS-DOS или Windows 3.x и поддерживающих только FAT в качестве локальной файловой системы. Сетевая файловая система NetWare является хорошим примером зависимости между свойствами интерфейса, предоставляемого приложениям на клиентских машинах, и свойствами локальной файловой системы сервера. Требования к поддержке прав доступа пользователей сети к удаленным файлам (помимо других существенных соображений) привели к разработке новой локальной файловой системы NetWare, так как FAT не хранит в своих служебных структурах данных о правах пользователей.

Другим популярным типом сетевых файловых систем стали системы компаний Microsoft и IBM, которые также были первоначально разработаны для локальных сетей на основе персональных компьютеров под управлением MS-DOS и Windows 3.x. Общим для этих сетевых файловых систем стало использование FAT в качестве локальной файловой системы, протокола SMB и интерфейса FAT с расширениями для клиентов. Для разграничения прав доступа здесь был применен другой прием -- файловая система FAT была оставлена в качестве локальной системы серверов, но сами серверы стали хранить в ней дополнительные служебные файлы с указанием прав пользователей на доступ к разделяемым каталогам. Эти права проверялись сервером при поступлении запроса из сети, локальные же запросы обслуживались в FAT по-прежнему без проверки прав доступа. Естественно, средства защиты каталогов нашли отражение в командах и ответах протокола SMB, а также в расширениях интерфейса FAT на стороне клиентов. Позже протокол SMB был применен и для доступа к локальным файловым системам HPFS и NTFS.

В среде операционной системы UNIX наибольшее распространение получили две сетевые файловые системы -- FTP (File Transfer Protocol) и NFS (Network File System). Они первоначально разрабатывались для доступа к локальной файловой системе s5/ufs, являющейся основной для большинства ОС семейства UNIX. Эти сетевые файловые системы используют собственные протоколы клиент-сервер FTP и NFS, предоставляя интерфейс s5/ufs своим клиентам.

Со временем в крупных сетях стали одновременно применяться несколько сетевых файловых систем разных типов, например NetWare и SMB или NetWare и NFS. Это часто происходило при объединении нескольких сетей в одну. Для пользователей каждой из сетей, привыкших к определенному интерфейсу и работающих с приложениями, рассчитанными на интерфейс FAT или s5/ufs, требовалось сохранить удобную среду. В результате в сети появились различные файловые серверы, поддерживающие различные локальные файловые системы и протоколы клиент-сервер, а также клиенты, обеспечивающие приложениям и пользователям различные интерфейсы. Возникла проблема -- как обеспечить доступ клиента любого типа к файловому серверу любого типа? Рассмотренные выше принципы организации сетевой файловой системы и ее основных компонентов подсказывают, что существует несколько вариантов решения этой проблемы, основанных на комбинировании локальных файловых систем, протоколов клиент-сервер и интерфейсов, поддерживаемых клиентами файловой системы.

На рис. 4 показан вариант организации неоднородной сетевой файловой системы, в которой на компьютере с локальной файловой системой NTFS работает несколько файловых серверов, поддерживающих различные протоколы клиент-сервер. Каждый файловый сервер обеспечивает доступ к одним и тем же данным всем клиентам, работающим по протоколу данного сервера, например протоколу NFS. Клиенты, в свою очередь, поддерживают для приложений и пользователей интерфейс s5/ufs, для которого разрабатывался протокол NFS.

Рис. 4. Неоднородная сетевая файловая система

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

2.3 Интерфейс сетевой файловой службы

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

2.3.1 Структура файла

Для любой файловой службы, независимо от того, централизована она или распределена, самым главным является вопрос, что такое файл? Во многих системах, таких как UNIX и Windows, файл -- это не интерпретируемая последовательность байтов. Значение и структура информации в файле является заботой прикладных программ, операционную систему это не интересует. В ОС мэйнфреймов поддерживаются разные типы логической организации файлов, каждый с различными свойствами. Файл может быть организован как последовательность записей, и у операционной системы имеются вызовы, которые позволяют работать на уровне этих записей.

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

2.3.2 Модифицируемость файлов

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

2.3.3 Семантика разделения файлов

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

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

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

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

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

 Транзакционная семантика. Четвертый способ работы с разделяемыми файлами в распределенных системах -- это использование механизма неделимых транзакций, достаточно подробно описанного в главе 8 «Дополнительные возможности файловых систем».

2.3.4 Контроль доступа

С каждым разделяемым файлом обычно связан список управления доступом (Access Control List, ACL), обеспечивающий защиту данных от несанкционированного доступа. В том случае, когда локальная файловая система поддерживает механизм ACL для файлов и каталогов при локальном доступе, сетевая файловая система использует этот механизм и при доступе по сети. Если же механизм защиты в локальной файловой системе отсутствует, то сетевой файловой системе приходится поддерживать его самостоятельно, иногда -- упрощенным способом, защищая разделяемый каталог и входящие в него файлы и подкаталоги как единое целое, В Windows NT/2000 существуют два механизма защиты -- на уровне разделяемых каталогов и на уровне локальных каталогов и файлов. Последний работает только в том случае, когда в качестве локальной файловой системы используется система NTFS, поддерживающая механизм ACL. Механизм защиты разделяемых каталогов нужен для того, чтобы защищать данные, хранящиеся в локальной файловой системе FAT, не имеющей механизмов защиты. В том случае, когда работают оба уровня защиты, у пользователей и администраторов могут иногда возникать некоторые логические сложности, связанные с определением реальных прав доступа как комбинации нескольких правил.

2.3.5 Единица доступа

Файловый интерфейс может быть отнесен к одному из двух типов в зависимости от того, поддерживает ли он модель загрузки-выгрузки или модель удаленного доступа. В модели загрузки-выгрузки пользователю предлагаются средства чтения или записи файла целиком. Эта модель предполагает следующую схему обработки файла: чтение файла с сервера на машину клиента, обработка файла на машине клиента и запись обновленного файла на сервер. Типичным представителем этого вида файлового интерфейса является служба FTP, пользователь которой должен применить команду get file_ame для перемещения файла с сервера на клиентский компьютер и команду put file_name для возвращения файла на сервер.

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

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

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



3. Вопросы реализации сетевой файловой системы

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

3.1 Размещение клиентов и серверов по компьютерам и в операционной системе

Рассмотрим прежде всего вопрос о распределении серверной и клиентской частей между компьютерами. В некоторых файловых системах (например, NFS или файловых системах Windows 95/98/NT/2000) на всех компьютерах сети работает одно и то же базовое программное обеспечение, включающее как клиентскую, так и серверную части, так что любой компьютер, который захочет предложить услуги файловой службы, может это сделать. Для этого администратору ОС достаточно объявить имена выбранных каталогов разделяемыми (экспортируемыми в терминах NFS), чтобы другие машины могли иметь к ним доступ. В некоторых случаях выпускается так называемая серверная версия ОС (например, Windows NT Server), которая использует то же программное обеспечение файловой службы, но только позволяющее за счет выделения файловому серверу большего количества ресурсов (в основном оперативной памяти) обслуживать одновременно большее число пользователей, чем версии файлового сервера для клиентских компьютеров.

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

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

Файловый сервер и клиенты могут в некоторых случаях оформляться и как модули, работающие в пользовательском режиме. Такое построение было характерно для ранних сетевых файловых систем сетей персональных компьютеров (например, IBM LAN Program), от которых не требовалась высокая скорость доступа, а объемы хранимых данных были весьма невелики. Используется такой режим работы и в файловых серверах ОС, основанных на микроядерной архитектуре, например ОС, построенных на основе микроядра Mach. Такие файловые серверы предназначены для выполнения самой ответственной работы (в отличие от серверов ранних систем для персональных компьютеров), и перенесение сервера в пользовательский режим обусловлено общим подходом к архитектуре ОС, преследующим, как это уже было отмечено в главе 3 «Архитектура операционной системы» такие цели, как повышение устойчивости и модифицируемости ОС. Однако работа файлового сервера в пользовательском режиме снижает его производительность, из-за чего на практике такая архитектура применяется пока редко.



3.2 Файловые серверы типа stateful и stateless

Файловый сервер может быть реализован по одной из двух схем: с запоминанием данных о последовательности файловых операций клиента, то есть по схеме stateful, и без запоминания таких данных, то есть по схеме stateless.

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

Серверы stateful работают по схеме, обычной для любой локальной файловой службы. Такой сервер поддерживает тот же набор вызовов, что и локальная система, то есть вызовы open, read, write, seek и close, рассмотренные в главе 7 «Ввод-вывод и файловая система». Открывая файлы по вызову open, переданному по сети клиентом, сервер stateful должен запоминать, какие файлы открыл каждый пользователь в своей внутренней системной таблице (рис. 5). Обычно при открытии файла клиентскому приложению возвращается по сети дескриптор файла fd или другое число, которое используется при последующих вызовах для идентификации файла. При поступлении вызова read, write или seek сервер использует дескриптор файла для определения, какой файл нужен. В этой таблице хранится также значение указателя на текущую позицию в файле, относительно которой выполняется операция чтения или записи. Таблица, отображающая дескрипторы файлов на сами файлы, является хранилищем информации о состоянии клиентов.

Рис. 5. Сервер с сохранением состояния (stateful)

Для сервера stateless каждый запрос должен содержать исчерпывающую информацию (полное имя файла, смещение в файле и т. п.), необходимую серверу для выполнения требуемой операции. Очевидно, что эта информация увеличивает длину сообщения и время, которое тратит сервер на локальное открытие файла каждый раз, когда над ним производится очередная операция чтения или записи. Серверы, работающее по схеме stateless, не поддерживают в протоколе обмена с клиентами таких операций, как открытие (open) и закрытие (close) файлов. Принципиально набор команд, предоставляемый клиенту сервером stateless, может состоять только из двух команд: read и write (рис. 6). Эти команды должны передавать в своих аргументах всю необходимую для сервера информацию -- имя файла, смещение от начала файла и количество читаемых или записываемых байт данных.

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

Рис. 6. Сервер без сохранения состояния (stateless)

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

 Серверы stateless:

 отказоустойчивы;

 не нужны вызовы open/close;

 меньше памяти сервера расходуется на таблицы;

 нет ограничений на число открытых файлов;

 отказ клиента не создает проблем для сервера. 

 Серверы stateful:

 более короткие сообщения при запросах;

 лучше производительность;

 возможно опережающее чтение;

 возможна блокировка файлов.

3.3 Кэширование

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

Схемы кэширования, применяемые в сетевых файловых системах, отличаются решениями по трем ключевым вопросам:

 месту расположения кэша;

 способу распространения модификаций;

 проверке достоверности кэша.

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

3.3.1 Место расположения кэша

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

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

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

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

3.3.2 Способы распространения модификаций

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

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

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

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

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

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

3.3.3 Проверка достоверности кэша

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

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

 Перед каждым доступом к файлу. Этот способ дискредитирует саму идею кэширования, так как каждое обращение к файлу вызывает обмен по сети с сервером. Но зато это обеспечивает семантику разделения файлов UNIX.

 Периодические проверки. Улучшают производительность, но делают семантику разделения неясной, зависящей от временных соотношений.

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

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

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

 отвергнуть запрос;

 поместить запрос в очередь;

 запретить кэширование для данного конкретного файла, потребовав от всех клиентов, открывших этот файл, удалить его из кэша.

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

 Он отклоняется от традиционной модели взаимодействия клиента и сервера, при которой сервер только отвечает на запросы, инициированные клиентами. Это делает код сервера нестандартным и достаточно сложным.

 Сервер обязательно должен хранить информацию о состоянии сеансов клиентов, то есть иметь тип stateful.

 По-прежнему должен использоваться механизм инициирования проверки достоверности клиентами при открытии файлов.

3.4 Репликация

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

Имеется несколько причин для применения репликации, главными из которых являются две:

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

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

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

3.4.1 Прозрачность репликации

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

Прозрачность репликации зависит от двух факторов: используемой схемы именования реплик и степени вовлеченности пользователя в управление репликацией.

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

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