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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В централизованной схеме (рис. 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, в том числе:

□ средства асинхронной обработки сообщений (message-oriented middleware, MOM); -

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

Архитектура «файл-сервер»

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

Сначала были одноранговые сети - все компьютеры равноправны.

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

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

Архитектура «файл-сервер»

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

ѓЮ Функция хранения данных вынесена на выделенный компьютер - файл-сервер

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

Плюсы:

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

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

Минусы:

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

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

 

Схема «клиент-сервер»