сетевые службы и сервисы модели сетевых служб и распределенных приложений

Модели сетевых служб и распределенных приложений

ТЕМА 3. ГЛОБАЛЬНЫЕ И ЛОКАЛЬНЫЕ СЕТЕВЫЕ ТЕХНОЛОГИИ

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

С этой целью практически любая локальная сеть имеет выход в глобальную сеть Интернет и постепенно становиться частью глобальной сети. Транспортной базой для такой интеграции стал единый стек протоколов TCP/IP.

Основные протоколы сетевого и транспортного уровня (IP, ICMP, ARP, TCP, UDP, RIP, OSPF) подробно изучались в учебной дисциплине «Вычислительные системы, сети и телекоммуникации». Они обеспечивают внутрисетевое и межсетевое взаимодействие компьютеров.

Доступ пользователей к разделяемым ресурсам как локальных, так и глобальных сетей осуществляется на основе набора разнообразных протоколов прикладного уровня (протокол доступа к гипертекстовым сервисам HTTP, протокол пересылки файлов FTP, почтовый протокол SMTP, протокол эмуляции удаленного терминала Telnet и другие).

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

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

Цель темы – раскрыть назначение и основные механизмы глобальных и локальных сетевых технологий, элементы системной интеграции, принципы и модели распределенной обработки данных в сетевых операционных системах.

В результате изучения темы обучаемые должны усвоить:

· Назначение и модели распределенных приложений.

· Механизм организации взаимодействия между элементами распределенных приложений.

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

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

· Принципы функционирования системы защиты информации Kerberos.

ТЕМА 3. ГЛОБАЛЬНЫЕ И ЛОКАЛЬНЫЕ СЕТЕВЫЕ ТЕХНОЛОГИИ 1

3.1. Тенденции и перспективы развития распределенных операционных сред 2

3.1.1. Модели сетевых служб и распределенных приложений.. 3

3.1.2. Механизм организации взаимодействия в распределенных системах. 6

3.2. Распределенные файловые системы.. 10

3.2.1. Основные принципы построения. 10

3.2.2. Кэширование файлов. 14

3.2.3. Репликация файлов. 15

3.2.4. Распределенная файловая система DFS.. 16

3.3. Элементы системной интеграции. 18

3.3.1. Служба каталогов. 18

3.3.2. Домены и доверительные отношения. 24

3.4. Средства защиты информации в сети. 26

3.4.1. Базовые технологии сетевой безопасности.. 27

3.4.2. Система Kerberos. 28

Вопросы для самопроверки. 33

Тенденции и перспективы развития распределенных операционных сред

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

Распределенные приложения могут обладать рядом преимуществ по сравнению с локальными:

· более высокая производительность;

· приближение к пользователю.

Следует выделить три основных параметра организации работы приложений в сети:

· способ разделения приложения на части, выполняющиеся на разных компьютерах сети;

· выделение специализированных серверов в сети, на которых выполняются некоторые общие для всех приложений функции;

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

Модели сетевых служб и распределенных приложений

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

· средства представления данных на экране, например средства графического пользовательского интерфейса;

· логика представления данных на экране, которая описывает правила и возможные сценарии взаимодействия пользователя с приложениями: выбор из системы меню, выбор элемента из списка и т. д.;

· прикладная логика – набор правил для принятия решений, вычислительные процедуры и операции;

· логика данных – операции с данными, хранящимися в некоторой базе, которые нужно выполнить для реализации прикладной логики;

· внутренние операции базы данных – действия СУБД (системы управления базами данных), вызываемые в ответ на выполнение запросов логики данных, такие как поиск записи по определенным признакам;

· файловые операции – стандартные операции над файлами и файловой системой, которые обычно являются функцией операционной системы.

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

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

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

Рис. 3.1. Варианты распределения частей приложения по двухзвенной схеме

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

Достоинство этого варианта: компьютер пользователя загружается незначительно и поэтому может быть низко производительным.

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

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

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

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

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

Система управления базами данных (СУБД) является одним из наиболее часто применяемых в сетях распределенных приложений.

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

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

Рис. 3.2. Вариант трехзвенной схемы распределения частей приложения

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

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

Источник

Сетевые службы и приложения

Сетевые службы — это системные распределенные программы, реализующие сетевые сервисы, Они часто представляют собой пару «клиент-сервер» и являются неотъемлемыми компонентами ОС.

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

Не всякое приложение, выполняемое в сети, является распределенным. Значительная часть истории локальных сетей связана как раз с использованием таких нераспределенных приложений. Рассмотрим, например, как происходила работа пользователя с известной в свое время СУБД dBase. Файлы базы данных, с которыми работали все пользователи сети, располагались на файловом сервере. Сама же СУБД хранилась на каждом клиентском компьютере в виде единого программного модуля. Программа dBase была рассчитана только на обработку данных, расположенных на том же компьютере, что и сама программа. Пользователь запускал dBase на своем компьютере, и программа искала данные на локальном диске, совершенно не принимая во внимание существование сети. Чтобы обрабатывать с помощью dBase данные, расположенные на удаленном компьютере, пользователь обращался к услугам файловой службы, которая доставляла данные с сервера на клиентский компьютер и создавала для СУБД эффект их локального хранения.

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

Источник

Модели сетевых служб и распределеных приложений

Распределенная обработка информации в сетевых ОС.

Файловая система с шифрованием EFS.

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

Для организации защиты имеется набор утилит. Более эффективную защиту предоставляет шифрование информации.

Работа EFS.

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

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

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

-более высокая производительность;

приближение к пользователю.

Приложения могут быть распределены по нескольким компьютерам. Распределенными в сети могут быть как прикладное так и системное программное обеспечение.

Компоненты операционной системы в этом случае называют системными службами.

Основные параметры организации приложений в сети:

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

2. Выделение специализированных серверов в сети на которых выполняется некоторые общие для всех приложений функции;

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

Способ разделения приложений на части.

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

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

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

3. Функциональная часть (прикладная логика) – это набор правил для принятия решений, вычислительные процедуры и операции;

4. Логика данных – это операции с данными в базе данных, которые нужно выполнить для реализации прикладной логики;

5. Внутренние операции базы данных;

6. Файловые операции – стандартные операции с файлами и с файловой системой.

На основе этой модели можно построить несколько схем распределения частей приложения между компонентами сети.

Пример:Двухзвенные схемы.

Обычно приложения делят на 2 или 3 части. Необходимо распределить 6 функциональных частей между 2-мя компонентами, причем сделать это несколькими способами.

Вариант 1. (централизованная схема).

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

Программа, обслуживающая комп пользователя, называется – эмулятор терминала.

Вариант 2.(файловый сервер)

На компе пользователя выполняют все части приложения, кроме файловых операций.

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

Распределенное приложение мало отличается от локального приложения.

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

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

Вариант 3. (промежуточная схема)

На серверный комп возлагают функции проведения внутренних операций БД и файловых операций.

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

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

Термин «клиент-сервер» применяется для двухзвенной схемы.

Трехзвенная схема

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

На клиентской машине выполняются средства представления данных и логика представлений данных, а также программный интерфейс к серверу приложений.

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

Сервер базы данных аналогичен серверу в предыдущей схеме.

— упрощается разработка крупных приложений

(-): вместо одного интерфейса появляются 2.

Источник

Модели сетевых служб и распределенных приложений

Лекция №21

Тема. Моделі мережевих служб і розподілених застосувань. Спосіб розподілу додатків на частини. Дволанкові схеми, триланкові схеми.

Цель. Объяснить модели сетевых служб, двухзвенные и трехзвенные схемы.

1. Учебная.Рассказать о моделях сетевых служб.

3. Воспитательная. Воспитывать интерес к научным достижением и открытиям.

Межпредметные связи:

· Обеспечивающие: информатика, математика, вычислительная техника и МП, системы программирования.

· Обеспечиваемые:Стажерская практика

Методическое обеспечение и оборудование:

1. Методическая разработка к занятию.

3. Учебная программа

4. Рабочая программа.

5. Инструктаж по технике безопасности.

Технические средства обучения: персональный компьютер.

Обеспечение рабочих мест:

Ход лекции.

Организационный момент.

Анализ и проверка домашней работы

3. Ответьте на вопросы:

4. Дайте определение файлу

5. Что такое «Мьютекс», его задача?

6. Какие подходы существуют в определении прав доступа?

7. Дайте описание мандатному способу доступа.

8. Опишите процесс входа пользователя в систему.

9. Как определяются права доступа в OS UNIX?

10. Суть и назначение монитора безопасности?

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

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

Модели сетевых служб и распределенных приложений

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

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

Целесообразно выделить три основных параметра организации работы приложе­ний в сети. К ним относятся:

□ способ разделения приложения на части, выполняющиеся на разных компью­терах сети;

□ выделение специализированных серверов в сети, на которых выполняются не­которые общие для всех приложений функции;

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

Источник

Модели сетевых служб и распределенных приложений.

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

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

Целесообразно выделить три основных параметра организации работы приложе­ний в сети. К ним относятся:

□ способ разделения приложения на части, выполняющиеся на разных компью­терах сети;

□ выделение специализированных серверов в сети, на которых выполняются не­которые общие для всех приложений функции;

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

Способ разделения приложений на части

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

□ средства представления данных на экране, например средства графического пользовательского интерфейса;

□ логика представления данных на экране описывает правила и возможные сце­нарии взаимодействия пользователя с приложением: выбор из системы меню, выбор элемента из списка и т. п.;

□ прикладная логика — набор правил для принятия решений, вычислительные процедуры и операции;

□ логика данных — операции с данными, хранящимися в некоторой базе, кото­рые нужно выполнить для реализации прикладной логики;

□ внутренние операции базы данных — действия СУБД, вызываемые в ответ на выполнение запросов логики данных, такие как поиск записи по определен­ным признакам;

□ файловые операции — стандартные операции над файлами и файловой систе­мой, которые обычно являются функциями операционной системы.

Двухзвенные схемы

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

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

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

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

В схеме «файловый сервер» (рис. 9.1, б) на клиентской машине выполняются все части приложения, кроме файловых операций. В сети имеется достаточно мощ­ный компьютер, имеющий дисковую подсистему большого объема, который хра­нит файлы, доступ к которым необходим большому числу пользователей. Этот компьютер играет роль файлового сервера, представляя собой централизованное хранилище данных, находящихся в разделяемом доступе. Распределенное при­ложение в этой схеме мало отличается от полностью локального приложения. Единственным отличием является обращение к удаленным файлам вместо ло­кальных. Для того чтобы в этой схеме можно было использовать локальные при­ложения, в сетевые операционные системы ввели такой компонент сетевой фай­ловой службы, как редиректор, который перехватывает обращения к удаленным файлам (с помощью специальной нотации для сетевых имен, такой, например, как //server 1/doc/filet.txt) и направляет запросы в сеть, освобождая приложение от необходимости явно задействовать сетевые системные вызовы.

Файловый сервер представляет собой компонент наиболее популярной сетевой службы — сетевой файловой системы, которая лежит в основе многих распре­деленных приложений и некоторых других сетевых служб. Первые сетевые ОС (NetWare компании Novell, IBM PC LAN Program, Microsoft MS-Net) обычно поддерживали две сетевые службы — файловую службу и службу печати, остав­ляя реализацию остальных функций разработчикам распределенных приложе­ний.

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

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

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

Другие варианты двухзвенной модели более равномерно распределяют функции между клиентской и серверной частями системы. Наиболее часто использует­ся схема, в которой на серверный компьютер возлагаются функции проведения внутренних операций базы данных и файловых операций (ряс. 9.1, Клиент­ский компьютер при этом выполняет вое функции, специфические для данного приложения, а сервер — функции, реализация которых не зависит от специфи­ки приложения, из-за чего эта функции могут быть оформлены в вида сетевых служб. Поскольку функции управления базами данных нужны далеко не всем приложениям, то в отличие от файловой системы они чаще всего не реализуются в виде службы сетевой ОС, а являются независимой распределенной приклад­ной системой. Система управления базами данных (СУБД) является одним из наиболее часто применяемых в сетях распределенных приложений. Не все СУБД являются распределенными, но практически все мощные СУБД* позволяющие поддерживать большое число сетевых пользователей, построены в соответствие с описанной моделью клиент-сервер. Сам термин «клиент-сервер» справедлив для любой двухзвенной схемы распределения функций, но исторически он ока­зался наиболее тесно связанным со схемой, в которой сервер выполняет функ­ции по управлению базами данных (и, конечно, файлами, в которых хранятся эти базы) и часто используется как синоним этой схемы.

Трехзвенные схемы

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

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

Сервер баз данных, как и в двухзвенной модели, выполняет функции двух по­следних слоев — операции внутри базы данных и файловые операции. Приме­ром такой схемы может служить неоднородная архитектура, включающая кли­ентские компьютеры под управлением Windows 95/98, сервер приложений с монитором транзакций TUXEDO в среде Solaris на компьютере компании Sua Microsystems и сервер баз данных Oracle в среде Windows 2000 на компьютере компании Compaq.

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

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

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

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

□ средства удаленного вызова процедур (Remote Procedure Call, КРС);

□ брокеры запроса объектов (Object Request Broker, ORB), которые находят объекты, хранящиеся на различных компьютерах, н помогают их использо­вать в одном приложении или документе

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

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

Схема «файл-сервер»

В архитектуре «файл-сервер» (File Server, FS-модель) все основные функции приложения информационной системы (презентационная логика, бизнес-логика и функции обработки и управления данными) располагаются на клиенте (рис. 13).

На сервере находятся файлы с данными и поддерживается доступ к файлам.

В этой модели клиент обращается к серверу на уровне файловых команд, система управления файлами (СУФ) считывает запрашиваемые данные из БД и поблочно передает эти данные клиентскому приложению. Фактически, FS-модель предполагает автономную работу программного обеспечения ИС на разных машинах в сети. Компоненты ИС взаимодействуют только за счет наличия общего хранилища данных. Безусловно, таким хранилищем должна быть хорошо спроектированная БД под управлением СУБД, поддерживающей FS-модель, например, СУБД Informix SE. Такого рода СУБД нельзя считать «истинным сервером».

При использовании FS-модели копия СУБД создается для каждого инициированного пользователем сеанса работы с СУБД, которая выполняется на том же процессоре, что и пользовательский процесс.

В целом в архитектуре ИС «файл-сервер» мы имеем «толстого» клиента и очень «тонкий» сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти.

К недостаткам архитектуры «файл-сервер» можно отнести:

 высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложениям клиентов;

 ограниченное множество команд манипулирования данными, фактически это только файловые команды;

 отсутствие развитых средств защиты данных (только на уровне файловой системы).

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

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

Появились локальные сети. Файлы начали передаваться по сети.

Потом возникла идея хранения всех общедоступных файлов на выделенном

Основные особенности:

ѓЮ Поддержка многопользовательской работы

Плюсы:

ѓЮ Многопользовательский режим работы с данными

ѓЮ Удобство централизованного управления доступом

Минусы:

ѓЮ Проблемы многопользовательской работы с данными:

последовательный доступ, отсутствие гарантии целостности

Источник