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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• средства удаленного вызова процедур (Remote Procedure Call, RFC);

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

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

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

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

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