6.2. Программные средства поддержки распределенных вычислений

Наиболее простая форма архитектуры КС является двухзвенной. Теоретически возможны следующие варианты реализации архитектуры КС (табл.11).

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

Таблица 11

	1. Хост-терминал	2. Сервер БД	3. Сервер приложений	4. Доступ к удаленным данным		5.Автономные вычисления
КЛИЕНТ		Интерфейс	Интерфейс Логика	Интерфейс Логика	Интерфейс Логика Данные	Интерфейс Логика Данные
СЕРВЕР	Интерфейс Логика Данные	Логика Данные	Логика Данные	Данные	Данные

Поэтому для работы в условиях значительных вычислительных нагрузок (1000 и больше клиентов) применяют трех- и многозвенные архитектуры КС. Их основными программными компонентами являются:

• ПО клиента – взаимодействует с пользователем, устанавливает связь с серверами, формирует и отправляет запросы серверу, получает и обрабатывает ответную информацию;

• ПО сервера – получает и обрабатывает запросы клиентов;

• промежуточное ПО (Middleware) – связывает между собой ПО клиентов и серверов, ограждая их от сложностей взаимодействия с ОС, сетевыми протоколами и серверами ресурсов; преобразует данные и позволяет совершенно разным программным системам работать вместе; может основываться на разных средствах: системах управления БД, средствах асинхронной обработки сообщений, мониторах транзакций, средствах разделения программ, удаленном вызове процедур, программах-посредниках – брокерах запроса объекта и т.д.

Таким образом, программа, поддерживающая многозвенную архитектуру КС, распределяется по нескольким дополнительным звеньям (серверам), обеспечивающим дополнительную вычислительную мощность [1, 8, 13].

Рассмотрим некоторые программные средства слоя Middleware.

1. Монитор (обработки) транзакций (Transaction-Processing, TP) или TP-монитор). Транзакция представляет собой многошаговую последовательность действий, связанных с изменением содержимого БД, имеющую смысл только при удачном завершении всех ее шагов. Пример транзакции: перевод некоторой суммы денег в БД с одного счета на другой. При неудачном завершении или невыполнении хотя бы одного шага должен быть выполнен полный «откат транзакции» с восстановлением исходного состояния БД на момент начала этой транзакции. Таким образом, TP-монитор, по сути, является сложным промежуточным ПО, которое функционирует на отдельном сервере сети, мультиплексирует запросы и ответы, удерживает их в потоке между клиентами и серверами БД и управляет ими (рис.6.5):

Рис.6.5. TP-монитор

• подключается к серверам БД;

• пропускает через себя запросы к БД;

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

• осуществляет маршрутизацию транзакций между разнообразными системами;

• уравновешивает нагрузку на серверы БД;

• управляет потоками;

• перезапускает системы и транзакции после сбоев;

• поддерживает целостность распределенной БД.

Принимая запросы от клиентов и мультиплексируя их, TP-монитор избавляет от необходимости создавать для каждого клиента отдельное соединение с БД. Показательно, что известный TP-монитор TUXEDO разработала компания Novell.

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

3. Технология удаленного вызова процедур (Remote Procedure Call, RPC) является процедурной блокирующей синхронной технологией и обычно применяется в случаях распределения по разным компьютерам частей одной программы при их сравнительно тесной взаимосвязи. Удаленный вызов процедур подобен вызову функций в языке С. Части программы заранее распределяются по разным компьютерам сети, а программист должен, пользуясь языком высокого уровня для описания сценариев, только определить типы и структуры данных и указать адреса узлов, в которые эти данные будут передаваться для обработки. Технология RPC удобна, если составление нового сценария требуется сравнительно редко и по нему решается большое число задач. В RPC обмен данными происходит по синхронному принципу: клиент вырабатывает запрос к серверу и приостанавливает свою работу до получения ответа, что является недостатком. При пересылках на основе транспортных протоколов TCP и UDP данные представляются в едином формате обмена.

Для RPC разработан специальный язык определения интерфейса (Interface Definition Language, IDL), позволяющий пользователю оперировать различными объектами безотносительно к их расположению в сети. На IDL можно записывать обращения к серверам приложений.

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

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

4. Технология асинхронной обработки сообщений (Message-Oriented Middleware, MOM) свободна от недостатка предыдущей технологии. Асинхронность обмена достигается организацией очередей сообщений и управления ими в соответствующих узлах сети. MOM не зависит от платформы и приложения, позволяет приложениям, созданным для разных платформ и сетей, надежно и безопасно обмениваться данными, посылая наборы данных в очереди сообщений. Сообщения хранятся в этих очередях до тех пор, пока другое приложение не обратится к ним за данными. Отправитель сообщения не знает, какое приложение извлечет его сообщение с данными из очереди. Сообщения могут представлять собой как наборы данных, так и запросы на выполнение определенных действий.

5. Технология брокера запроса объекта (Object Request Broker, ORB) основана на идеях объектно-ориентированного программирования и спецификациях общей ORB-архитектуры (Common ORB Architecture, CORBA), устанавливающих способы использования удаленных объектов (серверных компонентов) в клиентских программах. В технологии ORB значительно снижены трудности организации распределенных вычислений. Не нужно (в отличие от RPC) хранить в узле-клиенте сведения о расположении серверных объектов (программ, данных, принтеров и т.п.). Достаточно знать расположение в сети программы-посредника (брокера) – ORB, с помощью которого и происходит взаимодействие клиента с сервером. При этом ORB

• определяет место запрашиваемого ресурса (объекта) в сети и инициализирует серверную программу;

• направляет запрос пользователя в соответствующий серверный узел;

• после выполнения запроса возвращает результаты пользователю.

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

Технология ORB менее производительна, чем MOM. Применение ORB может увеличить нагрузку на сеть, однако имеет и ряд преимуществ:

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

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

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

В архитектуре CORBA создан межсетевой протокол взаимодействия брокеров разных производителей (Internet Inter-ORB Protocol, IIOP).

6. Технология среды распределенных вычислений (Distributed Computing Environment, DCE) не противопоставляется другим технологиям (RPC, ORB), а поддерживает среду для их использования. Например, в одной из реализаций DCE пакет Encina представляет собой TP-монитор, а пакет Orbix – средство ORB.

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

К функциям DCE относятся: распределение вычислений по технологии RPC; распараллеливание вычислений (но программист сам проектирует параллельные процессы); защита данных; синхронизация (согласование времени); поддержка распределенной файловой системы.

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

Определение нужного сервера в DCE либо происходит автоматически с помощью ORB, либо возлагается на программиста, как в RPC.

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

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