Файл: РАСПРЕДЕЛЕННАЯ ТЕХНОЛОГИЯ ОБРАБОТКИ ИНФОРМАЦИИ.pdf

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

Масштабируемость системы обработки информацииможет измеряться по трем различным показателям. Во-первых, система может быть масштабируемой по отношению к ее размеру, что означает легкость подключения к ней дополнительных пользователей и ресурсов. Во-вторых, система обработки информацииможет масштабироваться географически, то есть пользователи и ресурсы могут быть разнесены в пространстве. В-третьих, система может быть масштабируемой в административном смысле, то есть быть проста в управлении при работе во множестве административно независимых организаций. ^[4]

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

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

Таблица 3 - Примеры ограничений масштабируемости в распределённых системах обработки информации

Безопасность распределенных систем обработки информации связана с обеспечением защиты ресурсов от атак со стороны враждебно настроенных пользователей. С целью повышения безопасности распределенные системы обработки информации должны использовать защищенные каналы передачи данных, разрешать доступ к ресурсам только для авторизованных пользователей и допускать чтение передаваемых по сети данных только получателем.^[5]

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

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

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

1.2 Требования к архитектурному построению систем распределённой обработки информации

Исторически первым вариантом архитектурного построения вычислительной системы была архитектура с централизованной обработкой информации, когда одна мощная универсальная ЭВМ являлась единственной платформой, выполняющей все слои логики приложения. Централизованная архитектура характеризуется рядом существенных достоинств: простота разработка приложений, легкость обслуживания и управления. Именно эти достоинства обеспечили широкое практическое применение и долгое существование вычислительных систем с централизованной обработкой информации.^[6]

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

На уровне программного обеспечения разделение на клиента и сервер является логическим: процессы клиента и сервера могут физически размещаться как на одной, так и на разных машинах. Так в рассмотренных выше архитектурных построениях при размещении процессов клиента и сервера на одной машине (обычно принято называть эту машину звеном, или ярусом – от англ. «tier») говорят об однозвенной реализации архитектуры клиент/сервер, а при размещении процессов клиента и сервера соответственно на двух разных машинах говорят о двухзвенной реализации такой архитектуры. Таким образом под общим концептуальным названием модели «клиент/сервер» скрывается несколько вариантов архитектурного построения вычислительных систем, а именно архитектуры однозвенные, двухзвенные, трехзвенные и т. д. (обычно при числе звеньев более трех архитектуру называют многозвенной).^[7]

Однозвенная архитектура вырождается в классическую архитектуру с централизованной обработкой информации. В двухзвенной архитектуре приложение разделено на две части: клиентскую и серверную. Возможные варианты распределения слоев прикладного программного обеспечения в двухзвенной архитектуре представлены на Рисунке 1.

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

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

логика

представления

а

логика

представления

клиент сервер

бизнес-

логика

логика

доступа к

данным

б

бизнес-

логика

логика

доступа к

данным

логика

представления

в

логика

доступа к

данным

логика

представления

г

бизнес-

логика

логика

доступа к

данным

логика

представления

логика

представления

бизнес-

логика

бизнес-

логика

Рисунок 1 - Варианты построения схемы двухзвенной архитектуры клиент/сервер

Стремление повысить гибкость и масштабируемость многопользовательской распределенной системы привело к архитектурным решениям с тремя и более звеньями. С середины 1990-х годов интенсивное практическое внедрение получила трехзвенная архитектура, которая, как и двухзвенная, поддерживает концепцию «клиент/сервер», но разделяет систему по функциональным границам между тремя слоями: логикой представления, бизнес-логикой и логикой доступа к данным (Рисунок 2).

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

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

клиент сервер сервер БД

приложений (СУБД)

логика

представления

бизнес-

логика

логика

доступа к

данным

Рисунок 2 - Схема трехзвенной архитектуры клиент/сервер

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

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

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

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

Дальнейшее увеличение гибкости и масштабируемости распределенных систем достигается переходом к многозвенным архитектурам, включающим более чем три звена, и соответствующим распределением слоев прикладного программного обеспечения (и их частей) по разным машинам.^[8] Например, слой логики доступа к данным может быть разделен на СУБД и собственно базу данных, хранимую на отдельном устройстве (или группе устройств). Такая конфигурация отражает реализацию распределенной СУБД.(Рисунок 3).

клиент сервер сервер БД

приложений СУБД

логика

представ-

ления

бизнес-

логика

логика

доступа к

данным

логика

доступа к

данным

Рисунок 3 - Схема четырехзвенной архитектуры клиент/сервер

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

Глава 2. Механизмы реализации технологии распределенной обработки информации

2.1 Механизм удаленного вызова процедур

Синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером) поддерживает спецификация удаленного вызова процедур (remote procedure call - RPC). Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам - клиентскому и серверному переходникам, или заглушкам (от англ. stub - заглушка, переходник). Эти stub-процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) прикладных модулей. Каждая функция на сервере, которая может быть вызвана удаленным клиентом, должна иметь такой процесс.^[9]

Спецификация удаленного вызова процедур (remote procedure call– RPC) поддерживает синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером). Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам – клиентскому и серверному переходникам, или заглушкам (от англ.stub – заглушка, переходник). Эти stub-процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) прикладных модулей. Каждая функция на сервере, которая может быть вызвана удаленным клиентом, должна иметь такой процесс.