Глава 10 Сетевые службы

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

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

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

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

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

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

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

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

• Репликация

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

• Служба каталогов

• Назначение и принципы организации

• Служба каталогов NDS

• Межсетевое взаимодействие

• Основные подходы к организации межсетевого взаимодействия

• Трансляция

• Мультиплексирование стеков протоколов

• Инкапсуляция протоколов

• Выводы

• Задачи и упражнения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 10.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). Протокол сетевого доступа к файлам должен учитывать такую организацию файловой службы, например, обращаясь в случае отказа одного файлового сервера к другому, работоспособному и поддерживающему реплику требуемого файла. Репликация файлов не только повышает отказоустойчивость, но решает также и проблему перегрузки файловых серверов, так как запросы к файлам распределяются между несколькими серверами и повышают производительность сетевой файловой системы. Репликация в некоторых аспектах похожа на кэширование — в том и другом случаях в сети создается несколько копий одного и того же файла, при этом повышается скорость доступа к данным. Основным отличием репликации от кэширования является то, что реплики хранятся на файловых серверах, а кэшированные файлы — на клиентах.

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

1 Вопросы безопасности рассматриваются в главе 11 «Сетевая безопасность».

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

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

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

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

Рис. 10.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, требовалось сохранить удобную среду. В результате в сети появились различные файловые серверы, поддерживающие различные локальные файловые системы и протоколы клиент-сервер, а также клиенты, обеспечивающие приложениям и пользователям различные интерфейсы. Возникла проблема — как обеспечить доступ клиента любого типа к файловому серверу любого типа? Рассмотренные выше принципы организации сетевой файловой системы и ее основных компонентов подсказывают, что существует несколько вариантов решения этой проблемы, основанных на комбинировании локальных файловых систем, протоколов клиент-сервер и интерфейсов, поддерживаемых клиентами файловой системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Серверы stateless:

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

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

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

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

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

• Серверы stateful:

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

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

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

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

Кэширование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Репликация

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

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

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

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

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

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

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

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

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

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

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

• При явной репликации (explicit replication) пользователю (или прикладному программисту) предоставляется возможность управления процессом репликации. При создании файла сначала создается первая реплика с явным указанием сервера, на котором размещается файл, а затем создается несколько реплик, причем для каждой реплики сервер также указывается явно. Пользователь при желании может впоследствии удалить одну или несколько реплик. Явная репликация не исключает автоматического режима поддержания согласованности реплик, которые создал и разместил на серверах пользователь.

• При неявной репликации (implicit replication) выбор количества и места размещения реплик производится в автоматическом режиме, без участия пользователя. Приложение не должно указывать место размещения файла при запросе на его создание. Файловая система самостоятельно выбирает сервер, на который помещает первую реплику файла. Затем в фоновом режиме система создает несколько реплик этого файла, выбирая их количество и серверы для их размещения. Если надобность в некоторых репликах исчезает (это также определяется автоматически), то система их удаляет.

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

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

Чтение любой — запись во все (Read-Any — Write-All). При необходимости записи в файл все реплики файла блокируются, затем выполняется запись в каждую копию, после чего блокировка снимается и файл становится доступным для чтения. Чтение может выполняться из любой копии. Этот способ обеспечивает семантику разделения файлов в стиле UNIX. Недостатком является то, что запись не всегда можно осуществить, так как некоторые серверы, хранящие реплики файла, могут в момент записи быть неработоспособными.

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

Первичная реплика (Primary-Copy). В этом методе запись разрешается только в одну реплику файла, называемую первичной (primary). Все остальные реплики файла являются вторичными (secondary), и из них можно только читать данные. После модификации первичной реплики все серверы, хранящие вторичные реплики, должны связаться с сервером, поддерживающим первичную реплику, и получить от него обновления. Этот процесс может инициироваться как первичным сервером, так и вторичными (периодически проверяющими состоянии первичной реплики). Это метод является одной из реализаций метода «чтение любой — запись во все», в которой процесс записи реализован иерархическим способом. Для аккумулирования нескольких модификаций и сокращения сетевого трафика распространение модификаций может быть выполнено с запаздыванием, но в этом случае ухудшается согласованность копий. Недостатком метода является его низкая надежность — при отказе первичного сервера модификации файла невозможны (для решения этой проблемы необходимо повысить статус некоторого вторичного сервера до первичного).

Кворум (Quorum). Этот метод обобщает подходы, реализованные в предыдущих методах. Пусть в сети существует п реплик некоторого файла. Алгоритм основан на том, что при модификации файла изменения записываются в w реплик, а при чтении файла клиент обязательно производит обращение к г репликам. Значения да и г выбираются так, что w+r>n. При чтении клиент должен иметь возможность сначала проверить версию каждой реплики, а затем выбрать старшую и читать данные уже из нее. Очевидно, что при модификации файла номер версии должен наращиваться, а если при записи в w реплик они имеют разные версии, то выбирается максимальное значение версии для наращивания и присваивания всем репликам.

При выполнении условия w+r > n среди любых выбранных произвольным образом г реплик всегда найдется хотя бы одна из w реплик, в которую были записаны последние обновления. Так, если реплик восемь (и = 8), можно выбрать в качестве г значение 4, а в качестве w — значение 5 (рис. 10.7). Условие w+r> n при этом удовлетворяется.

Рис. 10.7. Примеры работы метода кворума

Предположим, что запись последних изменений была выполнена в реплики с номерами 3, 4, 5, 6, 8. Если при чтении выбраны реплики 1, 2, 3, 7, то реплика 3 окажется общей для операций записи и чтения, поэтому прочитаны будут корректные данные. В другом примере, который тоже иллюстрирует рисунок, г выбрано равным 2, a w — 7. Результат также получен корректный.

У метода кворума имеются частные случаи. Так, если r = 1, a w = n, то получаем метод «чтение любой — запись во все».

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

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

Сетевая файловая служба на основе протокола FTP (File Transfer Protocol) представляет собой одну из наиболее ранних служб, используемых для доступа к удаленным файлам. До появления службы WWW это была самая популярная служба доступа к удаленным данным в Интернете и корпоративных IP-сетях. Первые спецификации FTP относятся к 1971 году. Серверы и клиенты FTP имеются практически в каждой ОС семейства UNIX, а также во многих других сетевых ОС. Клиенты FTP встроены сегодня в программы просмотра (браузеры) Интернета, так как архивы файлов на основе протокола FTP по-прежнему популярны и для доступа к таким архивам браузером используется протокол FTP.

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

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

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

• User Interface — пользовательский интерфейс, принимающий от пользователя символьные команды и отображающий состояние сеанса FTP на символьном экране.

• User-Pi — интерпретатор команд пользователя. Этот модуль взаимодействует с соответствующим модулем сервера FTP.

• User-DTP — модуль, осуществляющий передачу данных файла по командам, получаемым от модуля User-Pi по протоколу клиент-сервер. Этот модуль взаимодействует с локальной файловой системой клиента.

FTP-сервер включает следующие модули:

• Server-Pi — модуль, который принимает и интерпретирует команды, передаваемые по сети модулем User-PL

• Server-DTP — модуль, управляющий передачей данных файла по командам от модуля Server-PL Взаимодействует с локальной файловой системой сервера.

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

Общая схема взаимодействия клиента и сервера выглядит следующим образом:

1. Сервер FTP всегда открывает управляющий порт TCP 21 для прослушивания, ожидая приход запроса на установление управляющего сеанса FTP от удаленного клиента.

2. После установления управляющего соединения клиент отправляет на сервер команды, которые уточняют параметры соединения:

• имя и пароль клиента;

• роль участников соединения (активная или пассивная);

• порт передачи данных;

• тип передачи;

• тип передаваемых данных (двоичные данные или ASCII-код);

• директивы на выполнение действий (читать файл, писать файл, удалить файл и т. п.).

3. После согласования параметров пассивный участник соединения переходит в режим ожидания открытия соединения на порт передачи данных. Активный участник инициирует это соединение и начинает передачу данных.

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

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

Протокол FTP использует при взаимодействии клиента с сервером несколько команд (не следует их путать с командами пользовательского интерфейса клиента, которые использует человек).

Эти команды делятся на три группы:

• команды управления доступом к системе;

• команды управления потоком данных;

• команды службы FTP.

В набор команд управления доступом входят следующие команды:

• USER — доставляет серверу имя клиента. Эта команда открывает управляющий сеанс и может также передаваться при открытом управляющем сеансе для смены имени пользователя.

• PASS — передает в открытом виде пароль пользователя.

• CWD — изменяет текущий каталог на сервере.

• REIN — повторно инициализирует управляющий сеанс.

• QUIT — завершает управляющий сеанс.

Команды управления потоком устанавливают параметры передачи данных:

• PORT — определяет адрес и порт хоста, который будет активным участником соединения при передаче данных. Например, команда PORT 194,85,135,126,7,205 назначает активным участником хост 194.85.135.126 и порт 1997 (вычисление номера порта не тривиально, но вполне однозначно).

• PASV — назначает хост пассивным участником соединения по передаче данных. В ответ на эту команду должна быть передана команда PORT с указанием адреса и порта, находящегося в режиме ожидания.

• TYPE — задает тип передаваемых данных (ASCII-код или двоичные данные).

• STRU — определяет структуру передаваемых данных (файл, запись, страница).

• MODE — задает режим передачи (потоком, блоками и т. п.).

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

Команды службы FTP инициируют действия по передаче файлов или просмотру удаленного каталога:

• RETR — запрашивает передачу файла от сервера на клиентский хост. Параметрами команды является имя файла. Может быть задано также смещение от начала файла — это позволяет начать передачу файла с определенного места при непредвиденном разрыве соединения (этот параметр Используется в команде reget пользовательского интерфейса).

• STOR — инициирует передачу файла от клиента на сервер. Параметры аналогичны команде RETR.

• RNFR и RNTO — команды переименования удаленного файла. Первая в качестве аргумента получает старое имя файла, а вторая — новое.

• DELE, MKD, RMD, LIST — эти команды соответственно удаляют файл, создают каталог, удаляют каталог и передают список файлов текущего каталога.

Каждая команда протокола FTP передается в текстовом виде по одной команде в строке. Строка заканчивается символами CR и LF ASCII-кода.

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

Символьные клиенты обычно поддерживают следующий основной набор команд:

• open имя_хоста — открытие сеанса с удаленным сервером.

• bye — завершение сеанса с удаленным хостом и завершение работы утилиты ftp.

• close — завершение сеанса с удаленным хостом, утилита ftp продолжает работать.

• ls (dir) — печать содержимого текущего удаленного каталога.

• get имя_файла — копирование удаленного файла на локальный хост.

• put имя_файла — копирование удаленного файла на удаленный сервер.

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

Файловая система NFS (Network File System) создана компанией Sun Microsystems. В настоящее время это стандартная сетевая файловая система для ОС семейства UNIX, кроме того, клиенты и серверы NFS реализованы для многих других ОС. Принципы ее организации на сегодня стандартизованы сообществом Интернета, последняя версия NFS v.4 описывается спецификацией RFC ЗОЮ, выпущенной в декабре 2000 года.

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

Одной из целей разработчиков NFS была поддержка неоднородных систем с клиентами и серверами, работающими под управлением различных ОС на различной аппаратной платформе. Этой цели способствует реализация NFS на основе механизма Sun RFC, поддерживающего по умолчанию средства XDR для унифицированного представления аргументов удаленных процедур.

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

Основная идея NFS — позволить произвольной группе пользователей разделять общую файловую систему. Чаще всего все пользователи принадлежат одной локальной сети, но не обязательно. Можно выполнять NFS и на глобальной сети. Каждый NFS-сервер предоставляет один или более своих каталогов для доступа удаленным клиентам. Каталог объявляется достудным со всеми своими подкаталогами. Список каталогов, которые сервер передает, содержится в файле /etc/exports, так что эти каталоги экспортируются сразу автоматически при загрузке сервера. Клиенты получают доступ к экспортируемым каталогам путем монтирования. Многие рабочие станции Sun бездисковые, но и в этом случае можно монтировать удаленную файловую систему к корневому каталогу, при этом вся файловая система целиком располагается на сервере. Выполнение программ почти не зависит от того, где расположен файл: локально или на удаленном диске. Если два или более клиента одновременно смонтировали один и тот же каталог, то они могут связываться путем разделения файла.

В своей работе файловая система NFS использует два протокола.

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

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

Второй NFS-протокол используется для доступа к удаленным файлам и каталогам. Клиенты могут послать запрос серверу для выполнения какого-либо действия над каталогом или операции чтения или записи файла. Кроме того, они могут запросить атрибуты файла, такие как тип, размер, время создания и модификации. NFS поддерживается большая часть системных вызовов UNIX, за исключением open и close. Исключение open и close не случайно. Вместо операции открытия удаленного файла клиент посылает серверу сообщение, содержащее имя файла, с запросом отыскать его (lookup) и вернуть дескриптор файла. В отличие от вызова open вызов lookup не копирует никакой информации во внутренние системные таблицы. Вызов read содержит дескриптор того файла, который нужно читать, смещение в уже читаемом файле и количество байт, которые нужно прочитать. Преимуществом такой схемы является то, что сервер не запоминает ничего об открытых файлах. Таким образом, если сервер откажет, а затем будет восстановлен, информация об открытых файлах не потеряется, потому что она не поддерживается.

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

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

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

Репликация в NFS не поддерживается.

Служба каталогов

Назначение и принципы организации

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

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

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

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

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

• В последнее время в сетях все чаще стали применяться средства управления качеством обслуживания трафика (Quality of Service, QoS), которые также требуют наличия сведений обо всех пользователях и приложениях системы, их требованиях к параметрам качества обслуживания трафика, а также обо всех сетевых устройствах, с помощью которых можно управлять трафиком (маршрутизаторах, коммутаторах, шлюзах и т. п.).

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

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

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

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

Для крупной сети неэффективным является также применение большого числа справочных служб узкого назначения: одной для аутентификации, другой — для управления сетью, третей — для разрешения имен компьютеров и т. д. Даже если каждая из таких служб хорошо организована и сочетает централизованный интерфейс с распределенной базой данных, большое число справочных служб приводит к дублированию больших объемов информации и усложняет администрирование и управление сетью. Например, в Windows NT имеется по крайней мере пять различных типов справочных баз данных. Главный справочник домена (NT Domain Directory Service) хранит информацию о пользователях, которая требуется при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных поддерживают разрешение адресов: WINS устанавливает соответствие Netbios-имен IP-адресам, справочник DNS (сервер имен домена) оказывается полезным при подключении NT-сети к Интернету, и наконец, справочник протокола DHCP используется для автоматического назначения IP-адресов компьютерам сети. Очевидно, что такое разнообразие справочных служб усложняет жизнь администратора и приводит к дополнительным ошибкам, когда учетные данные одного и того же пользователя нужно ввести в несколько баз данных. Поэтому в новой версии Windows 2000 большая часть справочной информации о системе может храниться службой Active Directory — единой централизованной справочной службой, использующей распределенную базу данных и интегрированной со службой имен DNS.

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

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

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

Существуют два популярных стандарта для служб каталогов. Во-первых, это стандарт Х.500, разработанный ITU-T (во время разработки стандарта эта организация носила имя CCITT). Этот стандарт определяет функции, организацию справочной службы и протокол доступа к ней. Разработанный в первую очередь для использования вместе с почтовой службой Х.400 стандарт Х.500 позволяет эффективно организовать хранение любой справочной информации и служит хорошей основой для универсальной службы каталогов сети.

Другим стандартом является стандарт LDAP (Light-weight Directory Access Protocol), разработанный сообществом Интернета. Этот стандарт определяет упрощенный протокол доступа к службе каталогов, так как службы, построенные на основе стандарта Х.500, оказались чересчур громоздкими. Протокол LDAP получил широкое распространение и стал стандартом де-факто в качестве протокола доступа клиентов к ресурсам справочной службы.

Существует также несколько практических реализаций служб каталогов для сетевых ОС. Наибольшее распространение получила служба NDS компании Novell, разработанная в 1993 году для сетевой ОС NetWare 4.0, а сегодня реализованная также и для Windows NT/2000. Большой интерес вызывает служба каталогов Active Directory, разработанная компанией Microsoft для Windows 2000. Обе эти службы поддерживают протокол доступа LDAP и могут работать в очень крупных сетях благодаря своей распределенности.

Служба каталогов NDS

Служба NDS (NetWare Directory Services) — это глобальная справочная служба, опирающаяся на распределенную объектно-ориентированную базу данных сетевых ресурсов. База данных NDS содержит информацию обо всех сетевых ресурсах, включая информацию о пользователях, группах пользователей, принтерах, томах и компьютерах. ОС NetWare (а также другие клиенты NDS, работающие на других платформах) использует информацию NDS для обеспечения доступа к этим ресурсам.

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

База данных службы NDS представляет собой многоуровневую базу данных, поддерживающую информацию о ресурсах всех серверов сети. Для совместимости с предыдущими версиями NetWare в службе NDS предусмотрен механизм эмуляции базы bindery.

Служба NDS — это значительный шаг вперед по сравнению с предыдущими версиями за счет:

• распределенности;

• реплицируемости;

• прозрачности;

• глобальности.

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

Рис. 10.8. Разделы базы данных NDS

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

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

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

Объектно-ориентированный подход

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

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

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

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

Дерево каталогов

NDS использует для хранения информации логическую структуру, называемую деревом каталогов (Directory Tree, DT). Эта иерархическая структура имеет корневой элемент (root) и ветви (рис. 10.9). Администратору сети NetWare 4.x предоставляется удобная графическая утилита NetWare Administrator, работающая в среде Windows, наглядно представляющая каждый объект дерева каталогов NDS в виде значка и отражающая связи между объектами. Пользователи также получают удобства прозрачного доступа к ресурсам всей сети, если они пользуются оболочкой NetWare для Windows, которая поддерживает диалог с NDS и представляет доступные пользователю ресурсы в виде вложенных значков.

Дерево каталогов содержит объекты двух типов:

• объекты-контейнеры,

• объекты-листья.

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

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

• страна (Country) — необязательный объект, который можно использовать в сетях, охватывающих несколько стран;

• организация (Organization) — располагается уровнем ниже, чем объекты-страны (если они используются);

• отдел или подразделение организации (Organizational Unit) — располагается уровнем ниже, чем объекты-организации, помогает в дальнейшем упорядочивании остальных объектов.

Рис. 10.9. Типичная структура дерева каталогов NDS

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

• организатор — идентифицирует руководящих лиц фирмы (руководитель группы или вице-президент);

• сервер;

• сервер печати;

• очередь печати;

• карта каталогов на томе;

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

Служба NDS и файловая система

Служба NDS предназначена для управления такими сетевыми ресурсами, как серверы и тома NetWare, но она не обеспечивает управление файловой системой. Файлы и каталоги не являются объектами службы NDS. Одним из атрибутов объекта-тома является месторасположение физического тома, который содержит файлы и каталоги. Таким образом, объект-том представляет собой связь между NDS и файловой системой.

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

Имена и контексты

Именование объектов службы NDS организовано по тем же принципам, что и в файловых системах с иерархической организацией каталогов. Эти же принципы построения составных имен используются в стандартах Х.500, LDAP, а также в службе DNS.

Объект-лист имеет краткое имя, называемое Common Name (CN). Оно может состоять максимум из 64 символов, включая пробелы. Поэтому имя принтера «Быстрый, но часто ломающийся Epson» является законным. Аналогом полного имени файловой системы является так называемое «различимое имя» — Distinguished Name. Различимое имя представляет собой конкатенацию всех имен объектов, расположенных на пути этого объекта к корню дерева. Составляющие различимого имени отделяются друг от друга точкой. В отличие от полных имен файлов крайней левой составляющей различимого имени является краткое имя объекта, а крайней правой составляющей — имя корневого объекта. Например, следующая запись представляет собой различимое имя объекта-пользователя с сетевым именем Vova S, работающего в сетевом отделе фирмы BestFirm, расположенной в России:

Vova S.NetProgrammers.BestFirm.RU

Возможен и другой вариант записи различимого имени с указанием типов объектов:

CN=Vova s.Ou=NetProgrammers.0=BestFi rm. C=RU

Такой вид записи более содержателен.

Средства защиты объектов в NDS

Служба NDS определяет права доступа одних сетевых объектов к другим. Различаются права доступа к объекту в целом и права доступа к его атрибутам.

По отношению к объектам существует следующий набор прав:

• Browse — просмотр;

• Add — добавление;

• Delete — удаление;

• Rename — переименование;

• Supervi sor — обеспечивает все перечисленные выше права.

По отношению к атрибутам объектов используются такие права:

• Compare — сравнение значения атрибута;

• Read — чтение значения атрибута;

• Write — запись нового значения атрибута;

• Sel f — присвоение себя в качестве значения атрибута другого объекта, например, если объект-группа разрешает право Sel f для объекта User, то последний может сделать себя членом этой группы;

• Supervisor — все права по доступу к" атрибутам.

С каждым объектом связан список управления доступом (ACL), в котором определяются права доступа к данному объекту со стороны других объектов.

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

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

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

Существуют три типа реплик: главная реплика (master replica), вторичная реплика (read/write replica) и реплика только для чтения (read-only replica).

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

Межсетевое взаимодействие

Только небольшое количество сетей обладает однородностью (гомогенностью) программного и аппаратного обеспечения. Однородными чаще всего являются сети, которые состоят из небольшого количества компонентов от одного производителя.

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

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

Неоднородность — это также естественное следствие того, что люди, ответственные за функционирования сети, стремятся выбрать программные и аппаратные средства, которые наилучшим образом отвечают поставленным целям. Часто оказывается, что средство, которое хорошо подходит для решения одной задачи, совсем необязательно также хорошо работает при решении другой задачи. Поэтому и появляются в сети коммуникационное оборудование разных технологий и разных производителей, сегменты Ethernet соседствуют с сегментами ATM, а серверы работают под управлением Windows 2000, Solaris или NetWare.

Отсюда следует важное требование, предъявляемое к современных сетевым ОС, — способность к интеграции с другими ОС.

Основные подходы к организации межсетевого взаимодействия

На первый взгляд выражение «организация межсетевого взаимодействия» может показаться парадоксальным. Действительно, если сети взаимодействуют, значит, их компьютеры связаны между собой и, следовательно, они все вместе образуют сеть. Тогда что же понимается под сетями, взаимодействие которых надо организовать? Понимается ли под этим совокупность компьютеров, которые работают под управлением одной сетевой операционной системы, например Windows NT или NetWare? Или это те компьютеры, которые связаны между собой средствами одной и той же базовой сетевой технологии, такой как, например, Ethernet или Token Ring? И наконец, может быть, здесь имеются в виду сети в терминах протокола сетевого уровня, то есть части большой сети, разделенные между собой маршрутизаторами?

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

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

Равным образом проблема межсетевого взаимодействия может возникнуть в сети, построенной исключительно на основе технологии Ethernet, но в которой установлено несколько разных сетевых ОС. В этом случае все компьютеры и все приложения используют для транспортировки сообщений один и тот же набор протоколов, но взаимодействие клиентских и серверных частей сетевых служб осуществляется по разным протоколам прикладного уровня. В этом случае компьютеры могут быть отнесены к разным сетям, если у них различаются протоколы прикладного уровня, например компьютеры, использующие для доступа к файлам протокол 8MB, образуют сеть Windows NT, а компьютеры, использующие для доступа к файлам протокол NCP, — сеть NetWare. Конечно, эти сети могут сосуществовать независимо, передавая данные через общие транспортные средства, но не предоставляя пользователям возможности совместно использовать ресурсы. Однако если потребуется обеспечить доступ к данным файлового сервера Windows NT для клиентов NetWare, администратор сети столкнется с необходимостью согласования сетевых служб.

Задачи устранения неоднородности имеют некоторую специфику и даже разные названия в зависимости от того, к какому уровню модели OSI они относятся. Задача объединения транспортных подсистем, отвечающих только за передачу сообщений, обычно называется internetworking — образование интерсетей. Классическим подходом для ее решения является использование единого сетевого протокола, такого, например, как IP или IPX. Однако существуют ситуации, когда этот подход неприменим или нежелателен, и они будут рассмотрены ниже.

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

Кардинальным решением проблемы межсетевого взаимодействия могло бы стать повсеместное использование единого стека протоколов. И такая попытка введения единого стека коммуникационных протоколов была сделана в 1990 году правительством США, которое обнародовало программу GOSIP — Government OSI Profile, в соответствии с которой стек протоколов OSI предполагалось сделать общим для всех сетей, устанавливаемых в правительственных организациях США. Однако массового перехода на стек OSI не произошло. Тем временем в связи с быстрым ростом популярности Интернета стандартом де-факто становится стек протоколов TCP/IP. Но это пока не означает, что другие стеки протоколов полностью вытесняются протоколами TCP/IP. По-прежнему очень много сетевых узлов поддерживает протоколы IPX/SPX, DECnet, IBM SNA, NetBEUI, так что до единого стека протоколов еще далеко.

Самыми общими подходами к согласованию протоколов являются:

• трансляция;

• мультиплексирование;

• инкапсуляция (туннелирование).

Трансляция

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

В зависимости от типа транслируемых протоколов процедура трансляции может иметь разную степень сложности. Так, преобразование протокола Ethernet в протокол Token Ring сводится к нескольким несложным действиям, главным образом благодаря тому, что оба протокола ориентированы на единую адресацию узлов. А вот трансляция протоколов сетевого уровня IP и IPX представляет собой гораздо более сложный, интеллектуальный процесс, включающий не только преобразование форматов сообщений, но и отображение адресов сетей и узлов, различным образом трактуемых в этих протоколах.

Трансляция протоколов прикладного уровня включает отображение инструкций одного протокола в инструкции другого, что представляет собой сложную логически неоднозначную интеллектуальную процедуру, которую можно сравнить с работой переводчика с одного языка на другой. Например, в файловой службе операционной системы NetWare (протокол NCP) определены следующие права доступа к файлу: read, write, erase, create, file scan, modify, access control, supervisory, а файловая служба UNIX (протокол NFS) оперирует совсем другим перечнем прав доступа: read, write, execute. Для некоторых из этих прав доступа существует прямое соответствие, для других же оно полностью отсутствует. Так, если клиент NCP назначает право доступа к файлу supervi sory или access control, то трансляция этих операций на язык протокола NFS не является очевидной. С другой стороны, в протоколе NCP отсутствует обычное для протокола NFS понятие монтирования файловой системы.

На рис. 10.10 показан шлюз, размещенный на компьютере 2, который согласовывает протоколы клиентского компьютера 1 в сети А с протоколами компьютера 3 в сети В. Допустим, что стеки протоколов в сетях А и В отличаются на всех уровнях. В шлюзе установлены оба стека протоколов.

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

Рис. 10.10. Принципы функционирования шлюза

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

Примером шлюза, транслирующего протоколы прикладного уровня, является компонент Windows NT Gateway Services for NetWare (GSNW), который обеспечивает клиентам Windows NT прозрачный доступ к томам и каталогам серверов NetWare 3.x и 4.x. Шлюз устанавливается на том же компьютере, на котором установлен сервер Windows NT. Между шлюзом и сервером NetWare устанавливается связь по протоколу NCP.

Для доступа к файлам NetWare клиенты Windows NT, используя свой «родной» протокол 8MB, обращаются к серверу Windows NT, на котором работает шлюз GSNW. Шлюз виртуализирует разделяемые каталоги серверов NetWare: они выглядят для клиентов SMB точно так же, как и разделяемые каталоги сервера Windows NT (рис. 10.11). Если запрос, поступивший на сервер Windows NT, относится к ресурсам серверов NetWare, то он переадресуется шлюзу, который транслирует его в понятный для сервера NetWare вид и передает по протоколу NCP соответствующему серверу. При этом шлюз выступает по отношению к серверам NetWare как клиент-пользователь.

Рис. 10.11. Шлюз Gateway Service for NetWare

Таким образом, шлюз реализует взаимодействие «многие ко многим».

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

Мультиплексирование стеков протоколов

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

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

Рис. 10.12. Два варианта согласования протоколов: трансляция протоколов (а), мультиплексирование стеков протоколов (б)

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

Рис. 10.13. Мультиплексирование стеков

При использовании технологии мультиплексирования структура коммуникационных средств операционной системы может быть и более сложной. В общем случае на каждом уровне вместо одного протокола появляется целый набор протоколов и может существовать несколько мультиплексоров, выполняющих коммутацию между протоколами разных уровней. Например, рабочая станция, стек протоколов которой показан на рис. 10.14, может через один сетевой адаптер получить доступ к сетям, работающим по протоколам NetBIOS, IP, IPX. Данная рабочая станция может быть клиентом сразу нескольких файловых серверов: NetWare (NCP), Windows NT (SMB) и Sun (NFS).

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

Рис. 10.14. Мультиплексирование протоколов

Производителями операционных систем предпринимаются попытки стандартизации не только межуровневых интерфейсов, но и менеджеров протоколов. Наиболее известными стандартами являются менеджеры Network Driver Interface Specification — NDIS (первоначально — совместная разработка 3Com и Microsoft, версии NDIS 3.0 и 4.0 — реализации Microsoft), а также стандарт Open Data-Link Interface — ODI, представляющий совместную разработку компаний Novell и Apple. Эти менеджеры реализуют мультиплексирование протоколов канального уровня, реализованных в драйверах сетевых адаптеров. С помощью мультиплексора NDIS или ODI можно связать один драйвер сетевого адаптера с несколькими протоколами сетевого уровня, а также с несколькими однотипными сетевыми адаптерами.

Мультиплексирование протоколов реализует отношение «один ко многим», то есть один клиент с дополнительным стеком может обращаться ко всем серверам, поддерживающим этот стек, или один сервер с дополнительным стеком может предоставлять услуги многим клиентам.

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

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

Заметим, что при организации взаимодействия двух разнородных сетей в общем случае нужно решать две задачи согласования служб (рис. 10.15):

• обеспечение доступа клиентам сети А к ресурсам сети В;

• обеспечение доступа клиентам сети В к ресурсам сети А.

Рис. 10.15. Направления согласования служб

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

Рассмотрим возможные варианты размещения программных средств, реализующих взаимодействие двух сетей, которые основаны на мультиплексировании протоколов. Введем обозначения: С — сервер, К — клиент, А — дополнительный протокол (или протоколы), предоставляющий возможности межсетевого взаимодействия.

На рис. 10.16 показаны оба возможных варианта однонаправленного взаимодействия А—>В: путем добавления нового стека к клиентам сети А (рис. 10.16, а) либо путем присоединения «добавки» к серверам сети В (рис. 10.16, б).

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

Примером «добавки», модифицирующей клиентскую часть, может служить популярное программное средство компании Microsoft Client Services for NetWare (CSNW), которое превращает клиента Windows NT в клиента серверов NetWare за счет установки клиентской части протокола NCP.

Рис. 10.16. Варианты размещения средств межсетевого взаимодействия

Примером расширения возможностей сетевого взаимодействия сервера является установка на сервер Windows NT продукта Microsoft File and Print Services for NetWare, который реализует серверную часть протокола NCP. Это позволяет клиентам NetWare обращаться к файлам и принтерам сервера Windows NT.

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

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

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

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

В табл. 10.1 приведены сравнительные характеристики двух подходов к реализации межсетевого взаимодействия.

Таблица 10.1. Сравнение методов трансляции и мультиплексирования протоколов

Метод	Достоинства	Недостатки
Мультиплексирование протоколов	Более быстрый доступ; повышение надежности взаимодействия за счет установки стека на нескольких узлах сети; хорошо масштабируемое средство	Усложнение администрирования и контроля доступа; высокая избыточность, требующая дополнительных ресурсов от рабочих станций; менее удобно для пользователя, чем шлюзы
Трансляция протоколов (шлюзы, маршрутизаторы, коммутаторы)	Сохранение привычной среды пользователей; отсутствие необходимости в дополнительном программном обеспечении на рабочих станциях; локализация всех проблем межсетевого взаимодействия; обеспечение возможности доступа к «чужим» ресурсам сразу для нескольких клиентов	Замедление работы; снижение надежности; плохая масштабируемость; необходимость в двух сетевых передачах для выполнения одного запроса

Инкапсуляция протоколов

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

В процессе инкапсуляции принимают участие три типа протоколов:

• протокол-«пассажир»;

• несущий протокол;

• протокол инкапсуляции.

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

В связи с большой популярностью Интернета и стека TCP/IP несущим протоколом транзитной сети все чаще выступает протокол IP, а в качестве протоколов-пассажиров — все остальные протоколы локальных сетей (как маршрутизируемые, так и не маршрутизируемые).

В приведенном на рис. 10.17 примере две сети, использующие протокол IPX, нужно соединить через транзитную сеть TCP/IP. Необходимо обеспечить только взаимодействие узлов двух сетей IPX, а взаимодействие между узлами IPX и узлами сети TCP/IP не предусматривается. Поэтому для соединения сетей IPX можно применить метод инкапсуляции.

Рис. 10.17. Туннелирование протоколов сетевого уровня

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

Инкапсуляция может быть использована для транспортных протоколов разного уровня. Например, протокол сетевого уровня Х.25 может быть инкапсулирован в протокол транспортного уровня TCP или же протокол сетевого уровня IP может быть инкапсулирован в протокол сетевого уровня Х.25. Существуют протоколы инкапсуляции трафика РРР через сети IP.

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

Выводы

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

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

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

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

• Файловый интерфейс может быть отнесен к одному из двух типов в зависимости от того, поддерживает ли он модель загрузки-выгрузки или модель удаленного доступа.

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

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

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

• Существует несколько способов обеспечения согласованности реплик, которые, общаются в методе кворума.

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

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

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

• Наиболее перспективным стандартом доступа к службе каталогов является стандарт LDAP (Light-weight Directory Access Protocol), разработанный сообществом Интернета.

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

• Средства, позволяющие организовать взаимодействие на нижних уровнях стека протоколов, называются средствами internetworking, а средства согласования протоколов и служб верхних уровней — средствами interoperability.

• Существуют три основных способа согласования протоколов: трансляция, мультиплексирование и инкапсуляция (туннелирование).

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

• Мультиплексирование заключается в установке нескольких стеков протоколов на клиентах или серверах согласуемых сетей.

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

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

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

Задачи и упражнения

1. Какие из следующих протоколов являются протоколами взаимодействия клиентской и серверной частей файлового сервиса: SMTP, NFS, SMB, SNMP, UDP, NLSP, FTP, TFTP, NCP?

2. Какая модель файлового сервера (stateful или stateless) обеспечивает большую степень устойчивости к отказам сервера?

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

4. Заполните таблицу, отметив наличие или отсутствие соответствующих свойств у механизмов репликации и кэширования файлов:

	Повышение производительности	Повышение отказоустойчивости
Репликация
Кэширование

5. Можно ли с помощью одного прикладного протокола осуществлять доступ по сети к различным локальным файловым системам?

6. Может ли несколько пользователей одновременно модифицировать один и тот же файл в ОС Windows NT? А в ОС UNIX?

7. Какой результат видят на экране два пользователя ОС UNIX, набирающие текст в одном и том же файле?

8. Какая модель сетевого файлового сервиса более прозрачна для пользователя: загрузки-выгрузки или удаленного доступа?

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

10. Какими свойствами должна обладать база данных службы каталогов?

11. Вставьте один из двух терминов — «реплицируемостъ» или «распределенностъ — вместо пропущенных слов в следующем утверждении: «База данных службы каталогов должна обладать... для обеспечения масштабируемости службы, и ... для обеспечения ее отказоустойчивости».

12. Поясните разницу в терминах «internetworking» и «interoperability».

13. Если на клиентской машине установлен стек протоколов, не совпадающий со стеком протоколов, установленным на сервере, то положение можно исправить, дополнительно установив соответствующий стек протоколов на одной из машин. Имеет ли значение, на какой из машин (сервере или клиенте) будет установлен этот стек?

14. Возможно ли в принципе обеспечить доступ всех клиентов сети А к серверам сети В и доступ всех клиентов сети В к серверам сети А путем установки дополнительного программного обеспечения только в одной из сетей, например в сети А?

15. Пусть в некоторой сети Windows NT, состоящей из сервера и клиентских станций, работают немногочисленные пользователи-непрофессионалы, выполняющие некритические приложения. Клиентские станции имеют весьма ограниченные ресурсы. Время от времени у пользователей возникает необходимость доступа к данным, находящимся на файл-сервере NetWare, который подключен к тому же сегменту Ethernet. Как вы считаете, какой вариант межсетевого взаимодействия является более предпочтительным в этой ситуации? О А) на всех компьютерах установить клиентскую часть протокола NCP; О В) на сервере Windows NT установить шлюз.

16. Пусть в сети Ethernet, в которой на всех компьютерах установлены протоколы сетевого уровня IP, драйверы сетевых адаптеров одних компьютеров выполнены в стандарте NDIS, а других — в стандарте ODI. Может ли это помешать нормальной работе сети?

17. Пусть распределенное приложение состоит из двух частей. Одна часть распределенного приложения выполняется на компьютере, на котором установлены следующие коммуникационные протоколы: О на прикладном уровне: SMB, SMTP; О на транспортных уровнях: TCP, IP, Ethernet.

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

• на прикладном уровне: NFS, X.400;

• на транспортных уровнях: TCP, IP, Ethernet.

Может ли в таких условиях приложение работать нормально?

Содержание

Процессы и потоки стр 69