Лекция 2 Службы каталогов сетевых серверных ОС

Лекция 2 Службы каталогов сетевых серверных ОС

Понятие службы каталогов

Архитектура Active Directory

Контроллеры домена и сайты

Управление объектами Active Directory

Концепция распределенной обработки в сетевых ОС

Модели распределенных приложений

Передача сообщений в распределенных системах

Вызов удаленных процедур

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

Контрольные вопросы к главе 5

Понятие службы каталогов

Современный этап развития ОС характеризуется созданием и совершенствованием корпоративных сетевых операционных систем [12, 28, 35, 37]. Эти системы отличаются способностью обеспечивать надежное и безопасное функционирование крупных сетей, характерных для больших предприятий, имеющих отделения в различных городах или даже странах. Таким сетям присуща высокая неоднородность программных и аппаратных средств, в рамках которой сетевая ОС должна надежно взаимодействовать с различными операционными системами и работать на различных компьютерах. С ростом сети возникает множество дополнительных проблем, таких как, например, поиск необходимого ресурса, компьютера или пользователя. С этой целью вся информация об объектах сети объединяется в так называемый каталог (directory), подобный каталогам файловой системы обычных ОС.

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

Существует несколько реализаций служб каталогов для различных ОС. Из наиболее известных можно выделить Novell Directory Service, Banyan Street Talk, Microsof Windows NT Directory Service (затем Windows Active Directory). Отдельно стоит упомянуть стандарт Х.500, разработанный Комитетом по коммуникациям (Consultative Committee for International Telephone and Telegraph, CCITT) совместно с Международной организацией стандартизации (International Organization for Standardization, ISO) как стандарт построения службы каталогов.

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

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

Понимая всю ограниченность Windows NT Directory Service, разработчики Microsoft в ОС Windows 2000 предложили, а затем усовершенствовали в Windows 2003 новую модель службы каталогов - Active Directory [I, 35,40].

Служба Active Directory, реализованная в Windows 2000, позволяет организовать централизованное управление всеми объектами сети, скрывая от пользователей физическую организацию сети. Чтобы получить доступ к объекту, пользователю совершенно не нужно знать, где этот объект физически находится. При этом проверка прав доступа пользователя происходит лишь один раз - в момент входа в систему. Администраторы получают в свое распоряжение средства для организации объектов и последующего управлениями ими.

Служба каталогов Windows 2000/2003 упорядочивает сетевые ресурсы и упрощает к ним доступ, используя два типа сетей: рабочие группы и домены (рис. 5.7). Рабочая группа (Workgroup) - это логическая группировка объединенных в сеть компьютеров, предоставляющих доступ к некоторым ресурсам, например принтерам или файлам (рис. 5.7, а). Рабочую группу можно сравнить с одноранговой сетью, так как в ней все компьютеры могут совместно обращаться к ресурсам без выделенного сервера.

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

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

 

 

 

 

Рис 5.7

 

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

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

Active Directory Windows 2000/2003 предоставляет способ разработать структуры каталога с учетом потребностей и специфики предприятия. Поэтому перед установкой и использованием Active Directory необходимо исследовать бизнес-структуру и деятельность организации.

Контроллеры домена и сайты

В роли контроллера домена в среде Windows 2000/2003 выступает компьютер, отвечающий за аутентификацию пользователей и содержащий полную копию базы данных AD этого домена. В каждом домене один или несколько компьютеров должны выполнять функции контроллеров доменов. Для поиска контроллера домена клиент обращается к протоколу, описанному в DNS, - стандартной службе каталогов, применяемой в настоящее время для сетей TCP/IP. Главное назначение службы DNS – преобразовать простые для запоминания имена (DNS-имена) в IP-адреса.

Каждый DNS-сервер ≪знает≫ свое место в глобальном пространстве DNS-имен, что позволяет передавать неразрешенные запросы другим серверам. Поэтому - пусть и не сразу - каждый клиентский запрос находит нужный контроллер домена. После этого для доступа к данным AD используется протокол LDAP. Протокол LDAP работает поверх TCP/IP и определяет способы доступа к каталогу со стороны клиентов. Кроме механизма доступа протокол реализует соглашение по именованию информации в каталоге, в явном виде описывая структуру этой информации.

Для получения информации о некотором элементе клиент должен указать уникальное имя этого элемента, которое называется отличительным, или различающимся, именем (distinguished name, DN). Отличительное имя - это набор имен, отражающих путь от корня дерева домена до интересующего элемента. Например, следующее DNS-имя идентифицирует объект - пользователя James Smith в домене microsoft.com:

DC = com/DC = Microsoft/CN = Users/CN = James Smith.

Разделители и значения, использованные в DN для James Smith, в данном случае имеют смысл, показанный ниже.

Вызов удаленных процедур

Удобным способом взаимодействия ОС и приложений в сети является вызов удаленных процедур (Remote Procedure Call, RPC). Этот механизм представляет собой надстройку над системой обмена сообщениями ОС, поэтому в ряде случаев он позволяет более удобно и прозрачно организовать взаимодействие программ в сети, однако его полезность не универсальна [28].

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

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

1. Вызов процедуры - широко распространенная, используемая и понятная абстракция.

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

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

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

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

• асимметричность - одна из взаимодействующих сторон является инициатором взаимодействия;

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

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

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

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

• при аварийном завершении вызывающей процедуры удаленно вызванные процедуры становятся ≪осиротевшими≫;

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

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

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

М = my_write (fd, buf, length);

Здесь fd - дескриптор файла (целое число), buf - указатель на массив символов, length - длина массива (целое число).

Чтобы осуществить вызов, вызывающая процедура помещает указанные параметры в стек в обратном порядке и передает управление вызываемой процедуре my_write. Эта пользовательская процедура после некоторых манипуляций с данными символьного массива buf выполняет системный вызов write для записи данных в файл, передавая ему параметры тем же способом, т. е. помещая их в стек (при реализации системного вызова они копируются в стек системы, а при возврате из него результат помещается в пользовательский стек). После того как процедура my_write выполнена, она помещает возвращаемое значение m в регистр, перемещает адрес возврата и возвращает управление вызывающей про__ которая выбирает параметры из стека, возвращая его в ис

Заметим, что в языке С параметры могут вызываться по ссылке (by name), представляющей собой адрес глобальной области памяти, в которой хранится параметр, или по значению (by value) в этом случае параметр копируется из исходной области памяти в локальную память процедуры, располагаемую обычно в стековом сегменте. В первом случае вызываемая процедура работает с оригинальными значениями параметров и их изменения сразу же видны вызывающей процедуре. Во втором случае вызываемая процедура работает с копиями значений параметров и их изменения никак не влияют на значение оригиналов этих переменных в вызывающей процедуре. Эти обстоятельства весьма существенны для RPC.

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

Рис. 5.27 иллюстрирует передачу параметров вызываемой процедуре: стек до выполнения вызова write (а), стек во времени выполнения процедуры (б), стек после возврата в вызывающую программу (в).

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

рис 5.27

 

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

Стабы используют для передачи данных через сеть средства подсистемы обмена сообщениями, т. е. существующие в ОС примитивы send и receive. Иногда в подсистеме обмена сообщениями выделяется программный модуль, организующий связь стабов с примитивами передачи сообщений, называемый модулем RPCRuntime.

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

рис 5.28

 

 

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

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

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

Стабы могут генерироваться вручную или автоматически. В первом случае программист использует средства, предоставляемые ему разработчиком средств RPC, но это достаточно объемная работа. При автоматическом способе применяется специальный язык определения интерфейса (Interface Definition Language), с помощью которого программист описывает интерфейс между клиентом и сервером RPC [28].

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

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

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

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

 

 

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

1. Приложение-клиент дожидается ответа на все отправленные запросы.

2. По окончании выполнения последовательности асинхронных RPC клиент выполняет синхронный вызов удаленной процедуры. Сервер ответит на синхронный вызов только после окончания обработки всех предшествующих асинхронных вызовов.

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

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

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

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

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

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

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

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

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

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

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

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

рис 5.29

 

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

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

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

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

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

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

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

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

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

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

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

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

рис 5.30

 

рис 5.31

 

 

Контрольные вопросы к главе 5

1. Какими преимуществами обладают сети по сравнению с раздельным использованием компьютеров?

2. Всегда ли совпадают физическая и логическая топологии сети?

3. Как классифицируются сети по величине охватываемой территории?

4. Какой компьютер может выполнять роль сервера в сети?

5. Что такое файловый сервер и сервер печати?

6. Какие функции выполняют регистрационные серверы?

7. Какие функции выполняют серверы удаленного доступа?

8. Что такое прокси-сервер?

9. Перечислите возможных клиентов компьютерной сети.

10. Что такое ≪толстый≫ и ≪тонкий≫ клиенты в компьютерной сети?

11. Как вы понимаете термин ≪сегментация≫ сети?

12. Что такое МАС-адрес?

13. Чем распределенная ОС отличается от сетевой? Существуют ли в настоящее время по-настоящему распределенные сетевые системы?

14. Перечислите основные компоненты сетевой ОС. Что такое сетевая служба? Какие сетевые службы вы можете назвать?

15. Часть сетевых служб направлена не на пользователя, а на администратора. Какие это службы?

16. Что представляли собой первые сетевые ОС? Какие подходы к созданию сетевых ОС используются в настоящее время?

17. Назовите характерные черты одноранговых сетей. В чем основная особенность многоранговой сети?

18. Что такое серверная ОС? Какие они бывают? Чем серверная ОС отличается от клиентской?

19. Сколько вариантов двухзвенных схем используется для распределенной обработки приложений?

20. Чем хороша двухзвенная обработка приложений при сотрудничестве сервера и клиента?

21. Есть ли преимущества у трехзвенной схемы обработки приложений, в чем они заключаются?

22. Как могут взаимодействовать процессы в распределенных системах?

23. Какие основные примитивы используются в транспортной системе сетевой ОС?

24. Как организуется синхронизация процессов в сети?

25. Что понимается под вызовом удаленных процедур?

Лекция 2 Службы каталогов сетевых серверных ОС

Понятие службы каталогов