Архитектура управления сервисами в WEB-центрированной системе

Е.А. КОПЫТОВА, Л.В. ГЛАДИЙ

(Харьковский национальный университет радиоэлектроники)

АРХИТЕКТУРА УПРАВЛЕНИЯ СЕРВИСАМИ В WEB-ЦЕНТРИРОВАННОЙ СИСТЕМЕ

Потребности общества в новых услугах, обуславливающие рост трафика, привели к широкому распространению концепции построения сетей следующего поколения (Next Generation Network, NGN). При внедрение новых сервисов возникает необходимость в предъявлении более жестких требования к основным показателям качества работы сети, таким как задержка, вероятность потери данных и т.д.  Основой при решении задач управления в сетях связи следующего поколения является концепция TMN [1], направленная на организацию интегрированного управления сетями с разнообразной структурой, составом оборудования, объемами передаваемой информации, типами нагрузки. Модель TMN реализуется через элемены сети NGN на основе единых интерфейсов и протоколов. Однако сегодня имеющиеся технологии построения систем управления не дают возможности построить интегрированную систему управления целиком на базе концепции TMN. Возникает необходимость в разработке новых методов управления.

Попытки реализовать архитектуру управления сервисами, в которой распределенные прикладные модули, представленные как объекты, взаимодействуют посредством четко описанных интерфейсов, предпринимаются давно и с определенным успехом (CORBA, DCOM, SOA). В CORBA и DCOM взаимодействующие объекты являются сильно связанными, и внесение изменений в управление компонентами, предоставляющими сервис, должно быть согласовано между собой. Основное достоинство SOA и web-сервисов состоит в том, что такая архитектура позволяет строить слабо связанные приложения, то есть такие, в которых одну часть можно менять, не затрагивая другую.

При анализе моделей системы управления трафиком  выделяются две технологии [2], получившие распространение на сегодняшний день — модели, основанные на технологии CORBA и SOA. Структура распределенного управления инфокоммуникационной сетью на базе CORBA представлена на рис.1.

Рисунок 1 – Структура распределенного управления сетью на базе CORBA

Алгоритм работы модели управления сетью на базе CORBA можно представить в виде размеченного графа  состояний (рис. 2).

Рисунок 2 – Размеченный граф состояний модели управления сетью на основе CORBA

В соответствии с проведенным анализом технологий построения распределенных управляющих систем [2] наиболее соответствующей существующим требованиям является сервис-ориентированная архитектура (SOA). SOA предполагает взаимодействие между пользователем и слабо связанными сервисами. Клиенты и сервисы общаются друг с другом и понимают друг друга вне зависимости от того, на какой платформе они работают [3]. К основным достоинствам такой архитектуры относят гибкость, повторное использование компонентов программы, которые могут быть территориально распределены по разным узлам сети. Базовыми элементами SOA архитектуры являются: со стороны сервера – предоставляемые сервисы, сервисная шина (ESB) и репозиторий описаний сервисов, со стороны пользователя  – Web-службы.

Для сокращения времени обработки запроса предложена распределенная модель управления на основе SOA, граф состояний которой представлен на рисунке 3, а структура распределенного управления сетью на основе сервис-ориентированной архитектуры представлена на рисунке 4.

Рисунок 3 – Размеченный граф состояний распределенной модели на основе SOA

Рисунок 4 – Структура распределенного упркавления сетью на основе SOA

Базовыми элементами предложенной модели являются сервисы, предоставляющие различные услуги пользователям, репозиторий, proxy- и front-end-сервера.

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

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

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

Когда пользователь отправляет запрос на предоставление сервиса,  на первом шаге запрос обрабатывается front-end-сервером, который преобразует запрос в специальный формат.

Front-end-сервер отправляет запрос в репозиторий, для поиска соответствующего сервиса (параметры, местоположение, стоимость и т.д.). В случае, если запрашиваемого сервиса нет в предоставляемых данными (существующими) ресурсами, репозиторий сообщает об этом front-end серверу, и тот пересылает запрос на redirect-сервер. Если сервис есть — выполняется перенаправление запроса на proxy-сервер, управляющий группой серверов, предоставляющих запрашиваемый тип сервисов.

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

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

В рассматриваемом n-мерном пространстве проведем тензорное описание изменений состояний модели с помощью одновалентного тензора объема передаваемого трафика H с компонентами hi , одновалентного тензора задержки передачи запросов Т компонентами τj  и тензора валентности два V. В качестве информативных систем координат (СК) будут введены в рассмотрение две координатные системы. Первая – система координат ветвей сети, а вторая – система координат узловых пар сети. [4]

Анализ существующих подобных систем позволил сформировать вектор интенсивностей поступающих запросов в систему: 25[запросов/с] (входящий трафик через i-е пары узлов)

Пропускная способность отдельных элементов системы задана в виде диагональных элементов матрицы пропускных способностей [запросов/с]:

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

Тогда:

              Компоненты данного вектора характеризуют величину задержки [c] на каждой ветви графа (рис.3).

Для подтверждения эффективности предложенной архитектуры проведен анализ архитектуры CORBA, граф состояний которой представлен на рис. 2. Согласно проведенному анализу рассчитана величина задержки [c] на каждой ветви графа:

Полученные результаты показывают, что при предельной нагрузке длительность обработки запроса в предложенной архитектуре будет составлять 2.5[c], а в архитектуре CORBA — 3,9 [c].

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

Библиографический список

1.          Рекомендации МСЭ-Т М.3000-М.3599 – Telecommunications Management Network (TMN).

2.          Копытова Е.А. Анализ технологий построения распределенных управляющих систем//Радиотехника. - 2009. –Вып. №159. - С. 256-260.

3.          Paul C. Brown. Implementing SOA: Total Architecture in Practice. - Addison Wesley Professional.- 2008.- 736.

4.          Копытова Е.А., Гладий Л.В. Анализ динамики функционирования web-сервера//Радиотехника.- 2010.