LS-Sb90335

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

Распределенная обработка данных реализуется на основе архитектуры «клиент– сервер».

3.1. Архитектура «клиент– сервер»

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

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

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

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

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

21

логий «клиент– сервер» определяются способами распределения между ними компонентов сетевого приложения и реализуемых им функций.

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

−функции ввода и отображения данных (обеспечивают взаимодействие с пользователем);

−прикладные функции (характерные для данной предметной области);

−функции хранения и управления ресурсами (файловой системой, базой даных и т.д.);

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

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

−компонент представления, реализующий функции первой группы;

−прикладной компонент, поддерживающий функции второй группы;

−компонент доступа к информационным ресурсам.

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

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

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

Модели и методы технологии «клиент– сервер» можно разделить на следующие четыре группы:

−файловый сервер (File Server – FS);

−доступ к удаленным данным (Remote Data Access – RDA);

−сервер базы данных (DataBase Server – DBS);

−сервер приложений (Application Server – AS).

Файловый сервер (выделенный узел в сети) работает под управлением сетевой операционной системы и осуществляет доступ к информационным

22

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

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

Более технологичный метод и модель доступа к удаленным данным

(RDA-модель) существенно отличаются от FS-модели характером доступа к информационным ресурсам. Это обеспечивается операторами специального языка (например, SQL-Structured Query Language). Клиент направляет по сети запросы информационным ресурсам (например, базам данных) удаленного компьютера. На нем функционирует ядро СУБД, которое обрабатывает запросы, выполняя предписанные в них действия, и возвращает клиенту результат, оформленный как блок данных. При этом инициатором манипуляций с данными выступают программы, выполняющиеся на компьютерахклиентах, в то время как ядру СУБД отводится пассивная роль – обслуживание запросов и обработка данных. Такое распределение обязанностей между клиентами и сервером базы данных не догма – сервер БД может играть более активную роль, чем та, которая предписана ему традиционной парадигмой. Основное достоинство RDA-модели – унификация интерфейса «клиент– сервер» в виде языка SQL.

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

Основу модели DBS составляет механизм хранимых процедур – средство программирования SQL-сервера. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. Язык, на котором разраба-

23

тываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL. Он уникален для каждой конкретной СУБД.

Достоинства DBS-модели очевидны: это возможность централизованного администрирования прикладных функций, снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур), возможность разделения процедуры между несколькими приложениями, экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры. К недостаткам модели можно отнести ограниченность средств для написания хранимых процедур, которые представляют собой разнообразные процедурные расширения SQL, не выдерживающие сравнения по средствам и функциональным возможностям с языками третьего поколения, такими как C, С+ или Pascal. Сфера их использования ограничена конкретной СУБД; в большинстве СУБД отсутствуют возможности отладки и тестирования разработанных хранимых процедур.

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

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

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

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

RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В AS-модели реализована трехзвенная схема разделения функций.

Двухзвенная архитектура. Двухзвенной (two-tier, 2-tier) она называется из-за необходимости распределения трех базовых компонентов между двумя узлами (клиентом и сервером). В любой сети (даже одноранговой), построен-

24

ной на современных сетевых технологиях, содержатся элементы клиентсерверного взаимодействия, основанного чаще всего на двухзвенной архитектуре.

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

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

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

Третьим звеном в трехзвенной архитектуре становится сервер приложе-

ний.

Программы-агенты и модель «клиент– агент– сервер». Правильная ори-

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

25

пользователя с БД. Вместо этого «клиент» посылает своему «агенту» короткие сообщения-запросы.

Многозвенная архитектура. Трехзвенная архитектура может быть расширена до многозвенной (N-tier, Multi-tier).

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

3.2. Способы распределенной обработки данных

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

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

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

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

4. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ

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

26

СУРБД – это программный комплекс СУБД, предназначенный для управления РаспБД и позволяющий сделать распределенность прозрачной для конечного пользователя.

Логически единая БД разделяется на фрагменты, каждый из которых хранится на одном компьютере, а все компьютеры соединены линиями связи. Каждый из этих фрагментов работает под управлением своей СУБД.

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

Прозрачность РаспБД – фундаментальный принцип, основанный на том, что для пользователя распределенная система должна выглядеть точно так же, как НЕраспределенная. При этом должны обеспечиваться:

−простота использования системы;

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

−высокая степень эффективности.

4.1. Цели и правила распределенных систем

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

1.Локальная автономия.

2.Независимость от центрального узла.

3.Непрерывное функционирование.

4.Независимость от расположения.

5.Независимость от фрагментации.

6.Независимость от репликации.

7.Обработка распределенных запросов.

8.Управление распределенными транзакциями.

9.Независимость от аппаратного обеспечения.

10.Независимость от операционной системы.

11.Независимость от сети.

12.Независимость от СУБД.

Отметим, что эти двенадцать позиций не являются независимыми одна от другой и не все они равнозначны. Различные пользователи могут прида-

27

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

4.1.1. Локальная автономия

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

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

4.1.2. Независимость от центрального узла

Второй критерий является следствием первого и формулируется следу-

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

−центральный узел может быть «узким» местом;

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

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

28

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

4.1.3. Непрерывное функционирование

Удаление или добавление узла не должно требовать остановки системы в целом. Этот принцип призван обеспечить более высокую надежность и доступность распределенных систем, например, при незапланированном выключении некоторого компонента внутри системы, добавлении нового узла или обновлении версии СУБД.

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

Доступность – вероятность того, что система исправна и работает в течение некоторого промежутка времени.

4.1.4. Независимость от расположения

(прозрачность расположения)

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

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

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

29

4.1.5. Независимость от фрагментации

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

4.1.6. Независимость от репликации

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

4.1.7. Обработка распределенных запросов

Система должна автоматически определять методы выполнения соединения (объединения) данных, обрабатывая распределенный запрос наиболее оптимальным образом как с точки зрения количества передаваемых данных, так и с точки зрения времени их передачи (за минимальное время передать максимальное количество данных).

4.1.8. Управление распределенными транзакциями

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

30