Содержание к диссертации
Введение
1. Анализ систем управления телекоммуникационными сетями 15
1.1. Стандарты сетевого управления телекоммуникациями 15
1.2. Анализ методов построения распределенных систем управления телекоммуникациями 35
1.3. Анализ методов формализованного описания структур распределенных систем 50
Выводы 61
2. Анализ методов обеспечения отказоустойчивости процессов интеграции ПК РСУ 62
2.1. Анализ концепций интеграций ПК РСУ 64
2.2. Анализ отказоустойчивости систем интеграции ПК РСУ 82
2.3. Сетевая модель брокера объектных запросов 93
2.4. Аналитическая и имитационная модели подсистемы управления обнаружения распределенных объектов 98
Выводы 102
3. Разработка и анализ методов повышения отказоустойчивости распределенных приложений 103
3.1. Модель взаимодействия распределенных приложений системы CORBA 103
3.2. Разработка алгоритмов повышения отказоустойчивости РСУ 114
3.3. Математическая модель подсистемы управления вызовами распределенных приложений 120
3.4. Математическая модель комбинированного метода интеграции ПК 124
3.5. Метод анализа пропускной способности системы сигнализации РСУ 132
Выводы 140
4. Исследование показателей качества отказоустойчивой РСУ 141
4.1. Исследование показателей качества брокера объектных запросов CORBA 141
4.2. Исследование подсистемы управления обнаружением распределенных объектов технологии CORBA 144
4.3. Исследование подсистемы управления вызовами удаленных методов технологии CORBA 146
4.4 Исследование отказоустойчивой подсистемы управления вызовами распределенных приложений 151
Выводы 157
Заключение 158
Литература 160
- Анализ методов построения распределенных систем управления телекоммуникациями
- Анализ отказоустойчивости систем интеграции ПК РСУ
- Математическая модель подсистемы управления вызовами распределенных приложений
- Исследование подсистемы управления обнаружением распределенных объектов технологии CORBA
Анализ методов построения распределенных систем управления телекоммуникациями
Для вызова метода серверного объекта, клиент осуществляет запрос посредством stub. При этом stub обращаясь к клиентской части ORB вызывает специализированный сервис middleware – Smart Agent (установлен на определенном компьютере в сети), который является служобй directory service, отвечающей за поиск доступного сервера для выполнения необходимого сервиса. После определения сервера, создается необходимый серверный объект со скелетоном, к которому обращается ORB для передачи клиентского запроса с помощью базового объектного адаптера Basic Object Adapter (BOA). BOA – это каталог интерфейсов для создания ссылок на удаленные методы объектов, активизации приложений, регистрации объектов, авторизации запросов. При помощи данной службы скелетон, используя Smart Agent, производит регистрацию нового серверного объекта, сообщает о факте создания, доступности и готовности объекта обрабатывать запросы клиента.
На серверной стороне данные о каждом новом классе объектов, поддерживаемом конкретным сервером, заносятся в репозиторий реализаций. Эту операцию выполняет объектный адаптер.
При реализации запроса брокер через объектный адаптер активирует соответствующий компонент. Далее клиент-серверное взаимодействие происходит через стабы.
Основными элементами модели CORBA являются: GIOP (General Inter ORB Protocol) - многоуровневая система преобразования и передачи информации для обеспечения взаимодействия между ORB; ORB - специальный комплекс программ, предназначенный для поддержки компонентов вызова и системы распределенных компонентов; Object Stub - сущность в модели языка реализации, обращение к которому транслируются в сетевые запросы к другим ORB; язык программирования, относящийся к языкам реализации системы CORBA, для которого существует стандарт отображения IL, транслятор, генерирующий скелетон и стабы; Object Skeleton - соответствующая некоторому локальному интерфейсу CORBA система операторов, принимающая вызов от стаба объекта и формирует из него вызов метода серванта;
Сервант - система программных модулей, служащих для реализации определенного CORBA-интерфейса.
Язык IDL предназначен для взаимодействия компонент, написанных на различных платформах. IDL дает возможность описывать интерфейсы компонент CORBA (рисунок 1.18).
Программные модули должны быть реализованы в CORBA-среде. Для реализации программных компонент в среде CORBA компилятор IDL выполняет следующие действия:
1. метаданные для каждого класса объектов помещаются в репозиторий интерфейсов, имеющийся в ORB;
2. компилятор создает серверный и клиентский стабы для каждого метода, определенного на IDL.
Компоненты в процессе выполнения запроса могут получать данные из репозитория интерфейсов о форматах и структуре IDL-интерфейсов для формирования динамических запросов.
Описания интерфейсов размещены в репозитории, как множество объектов. Доступ к этим объектам обеспечивается также репозиторием. Являясь одним из основных элементов стандарта CORBA, ORB обеспечивает взаимодействие брокеров различных производителей. Репозиторий интерфейсов также представляет собой программный компонент и имеет собственный IDL-интерфейс, через который другие компоненты получают информацию об остальных объектах CORBA.
Выбор рационального варианта построения РСУ осуществляется путем решения многокритериальной задачи. Показателями качества системы при этом являются: - время обработки запросов на услуги связи; - вероятность отказа в реализации услуги; - количество одновременно реализуемых услуг; - допустимое время реализации задания; - ВВХ времени ожидания обслуживания и др.
По рекомендациям Форума управления телекоммуникациями (TMF) в качестве критерия оценки эффективности РСУ может использоваться функционал Ф = YjPkTk(A) - min, Л = (F-(D + R))/F, к где Тк - время завершения обслуживания, Рк - приоритет к-ого требования, F - время между сбоями, D - время выявления сбоев, R -время восстановления после сбоев, А - отказоустойчивость.
Очевидно, что единственным фактором, не поддающимся контролю, является промежуток времени между сбоями, он непредсказуем. Параметры D и R могут быть оптимизированы путем совершенствования алгоритмов управления вызовами удаленных методов и управления обнаружением распределенных объектов.
Данная схема взаимодействия типа «клиент-сервер» является статической. В стандарте CORBA возможны также динамические вызовы, для осуществления которых не создаются CORBA-стабы, используя компилятора языка IDL.
Анализ отказоустойчивости систем интеграции ПК РСУ
При исследовании параллельных РСУ в качестве базовой информации используются данные о взаимосвязи событий в системе. Данные о моментах времени наступления событий, интервалах реализации, тактированных временных шкалах, как правило, не используются. Причинно-следственная связь событий в асинхронных системах, к которым относятся параллельные РСУ, задается множеством отношений вида "условия-события". Построение полной структуры таких отношений для РСУ - задача сложная. Однако использование структурированной информации о предметной области моделирования позволяет существенно упростить эту работу. В настоящее время выделяют два подхода к описанию семантики параллельных систем. Первый подход опирается на понятие последовательности действий (О-последовательности), второй - основывается на понятии процесса. В то время как первый подход более удовлетворяет практическим целям, во втором подходе параллельность представляется более "правильным" образом. Теория СП предоставляет аппарат, который позволяет при описании модели учесть преимущества обоих подходов.
Построение моделей РСУ в терминах СП включает следующие действия: 1. Моделируемые процессы, протекающие в РСУ, описываются множеством событий и условий, которыми эти события определяются, а также причинно-следственными отношениями, устанавливаемыми на множестве "события-условия". 2. Определяются события, последовательность наступления которых управляется состояниями системы. Состояние системы задается множеством условий. Условия формулируются в виде предикатов. 3. Условия (предикаты) могут выполняться и не выполняться. Только выполнение условий обеспечивает возможность наступления событий. 4. После того как событие наступило, будет обеспечено выполнение других условий, находящихся с ранее выполненными условиями в причинно-следственной связи.
В СП условие – это позиции, а события – это переходы. Последовательности событий отображаются срабатыванием переходов. Выполнение какого-либо условия связано с появлением метки в соответствующей этому условию позиции. Соглашение о правилах срабатывания переходов является способом выражения концепции причинно-следственных связей между условиями и событиями в системе. Момент фактической реализации события неизвестен, поскольку иногда бывает трудно восстановить полные цепи непосредственных причин и следствий, определяющих факт и время наступления события.
Поясним некоторые варианты применения математического аппарата СП для получения общих качественных оценок событий и процессов в параллельных РСУ.
1. СП могут иметь позиции, число меток в которых растет неограниченно. Свойство ограниченности сетей связано с введением ограничений на число меток в позициях. Если, например, интерпретировать метки данными в сетях обмена информацией, а некоторые позиции буферами или регистрами, то ограниченность СП будет естественным условием, проверка выполнимости которого позволит выяснить, возможно ли в данной сети переполнение буфера, вместимость которого ограничена.
2. В СП возможны такие ситуации, когда ни при каких изменениях в сети не выполняются условия активизации некоторых переходов. Эти переходы оказываются как бы лишними и могут быть исключены из СП без всякого ущерба для ее функционирования.
Может случиться также, что после реализации в сети определенной последовательности срабатываний переходов возникает такая разметка позиций, при которой некоторые переходы никогда больше не сработают ни при каких получаемых в дальнейшем разметках. Такие ситуации соответствуют тупиковым событиям в моделируемой системе. Выявление тупиковых разметок связано с анализом живости СП.
3. СП являются эффективным аппаратом для анализа состояний в параллельных РСУ. Например, при необходимости установить возможность или невозможность некоторого состояния в РСУ можно использовать процедуры анализа СП на достижимость. Проверяемая ситуация в СП задается некоторой разметкой. Исследование заключается в проверке достижимости этой разметки от некоторой исходной разметки.
4. Важным направлением формального анализа СП является возможность их исследования по частям. Исходная сеть разбивается на фрагменты, каждый из которых исследуется независимо, а затем проводится анализ свойств целостной СП, в которой каждый фрагмент замещается отдельным переходом или позицией (иерархическим фрагментом).
5. Интересным расширением СП являются так называемые временные СП. Позиции или переходы во временных СП взвешиваются "временем выполнения". Метка при попадании в позицию или "захваченная" взвешенным переходом становится недоступной для возбуждения соответствующего перехода в течение "времени выполнения".
Математическая модель подсистемы управления вызовами распределенных приложений
Вызов метода может осуществляться синхронным и асинхронным способом в зависимости от заданной логики реализации услуги.
Синхронный вызов удаленных объектов блокирует данный запрос до получения результата вызова. Язык IDL поддерживает концепцию однонаправленных операторов, которые пересылаются клиентом асинхронно. Таким образом, клиент может отправить запрос, после чего продолжать работу, не дожидаясь завершения обработки запроса сервером. Однако, если пользователь ожидает ответа, на получение которого требуется достаточно много времени, он может подумать, что программа зависла. Во время потенциально долговременной обработки запросов желательно обеспечить возможность взаимодействия программы с пользователем, а также предоставить пользователю возможность прервать выполнение операции. Рассмотрим однопоточный сервер, который иногда выступает в роли клиента. Пока этот сервер обрабатывает запрос клиента, он недоступен для всех остальных клиентов. Однако если клиент посылает запрос, он блокируется и ожидает ответа. В течение этого времени сервер не сможет выполнять никакой полезной работы, так как он занят обработкой входящих запросов. Подобная ситуация крайне нежелательна. Она приводит к снижению скорости передачи данных в системе и даже к зависанию, если серверы будут создавать циклические вызовы. Единственный способ избежать этих проблем состоит в том, чтобы сделать компоненты многопоточными. Однако это не всегда возможно. Рассмотрим несколько способов использования CORBA, которые позволяют увеличить скорость работы системы без применения многопоточности.
Один из способов решения проблемы состоит в разделении блокирующего вызова на пару однонаправленных операций. Таким образом, клиенты, отправившие запрос, не блокируются до тех пор, пока не получат ответ, а смогут продолжать свою работу. В дальнейшем, когда сервер завершит обработку запроса, он "возвратит" результаты клиенту, вызвав соответствующий метод клиента и отправив ответ. Сервер обрабатывает запрос и, как только результаты готовы, отправляет их клиенту, вызывая метод объекта обратного вызова. Таким образом, вызывающее приложение не блокируется на то время, в течение которого сервер занимается поиском и табуляцией данных об изменении стоимостей акций. Клиент может спокойно обрабатывать данные, которые вводит пользователь, в течение потенциально большого времени обработки вызова сервером. Блок-схемы взаимодействия двух описанных методов приведены на рисунках 2.20 и 2.21. Подобные методы могут применяться и в ситуации, когда серверы выступают в роли клиентов, так как у них появляется возможность обрабатывать входные запросы клиентов. Это позволяет достигнуть большой скорости работы системы без применения многопоточности, но усложняет сервер. Также этот метод требует разделения логики приложения таким образом, чтобы обеспечить обработку данных при отсутствии связи с клиентом.
Технология CORBA поддерживает еще один способ создания неблокирующих вызовов, основанный на использовании интерфейсов динамических вызовов DII (Dynamic Invocation Interface). Интерфейсы DII используются для того, чтобы осуществлять вызовы интерфейсов, о которых программы-клиенты на момент компиляции ничего не знают. При использовании обычных интерфейсов статических вызовов SII (Static Invocation Interface) разработчики программ-клиентов просто применяют вызовы методов на объектах-посредниках. Класс объектов-посредников, генерируемый компилятором IDL, отвечает за кодирование аргументов, проведение удаленных вызовов и декодирование результатов запроса. При использовании интерфейсов DII выполнение всех операций производится разработчиком программы-клиента. Данный метод намного сложнее, однако для определенных классов приложений (шлюзов и браузеров) очень важна независимость от конкретных IDL.
Интерфейс DII также поддерживает концепцию разностного синхронного вызова. Это означает, что неблокирующие удаленные вызовы осуществляются безо всяких ограничений, накладываемых IDL, с помощью однонаправленных методов. Таким образом, клиенты проводят неблокирующие вызовы даже в том случае, если в результате вызова метода возвращаются определенные данные (клиенты должны проверить результаты запроса через некоторое время после его отправления). Такая ситуация дает очень много преимуществ. Однако существуют и отрицательные моменты: этот метод возможен только при применении интерфейсов DII, что неприемлемо для некоторых приложений. Также следует отметить, что при использовании разностных синхронных вызовов, как и при использовании пары однонаправленных запросов, клиенты должны разделять свою логику и выполнять различные действия в определенные моменты времени. Использование разностных синхронных вызовов на стороне клиентов для серверов совершенно прозрачно.
Брокерами объектных запросов поддерживается упреждающий обмен сообщениями. Использование односторонних запросов или разностных синхронных вызовов позволяет получить вариант асинхронного соединения. Однако в некоторых ситуациях возможностей брокеров объектных запросов недостаточно. Компоненты все еще недостаточно связаны между собой: между клиентами и серверами должна существовать прямая связь, что приводит к взаимной зависимости компонентов. К другим средствам обмена сообщениями, которые нужно реализовать в системах, относятся постоянное хранение сообщений (благодаря чему клиенты и серверы нельзя запускать одновременно), соединения "один-со-многими" (благодаря чему сообщение по одному вызову отправляется нескольким получателям), а также прозрачная доставка сообщений
Исследование подсистемы управления обнаружением распределенных объектов технологии CORBA
На сервис интеграции от m контроллеров ЦУ поступают запросы с интенсивностью . Обработка запроса на сервисе осуществляется в четыре этапа: отбор запросов, относящихся к одному и тому же процессорному модулю (ПМ); обработка запросов путём их разбиения с выбором полей параметров; получение объектной ссылки взаимодействия и маркировка значений полей параметров; создание объединенного запроса, полученного после предварительной обработки.
Процесс интеграции ПК, представленный на рисунке 3.15, можно рассматривать как многофазную систему массового обслуживания (СМО), где поток запросов ПК является пуассоновским, а времена создания единого объединенного запроса и формирование единого вызова подчинены произвольному закону распределения, то есть СМО типа M/G/m [62].
Необходимо найти время пребывания в очереди, длину очереди и вероятность отказа в случае совместного обращения m ЦУ к сервису. Опишем СМО, изображенную на рисунке 3.15. Данная СМО представлена четырьмя фазами:
1. Источники имитируют передачу запросов ПК от m элементов ЦУ в среду взаимодействия.
2. Запросы поступают на сервис интеграции и становятся в очередь для дальнейшего обслуживания. Если очередь занята, то запрос удаляется, а на источник, откуда этот запрос поступил, отправляется сообщение о повторном запросе через время обслуживания первого в очереди запроса.
3. Управление запросом, получение объектной ссылки взаимодействия и маркировка значений полей параметров.
4. Обработка запроса ZПК[Мy Фазу приема запросов представим как СМО типа M/G/1/.
Основными случайными величинами (СВ), характеризующими эту систему, являются: - период занятости 77; - время ожидания обслуживания Wn; - время пребывания Vn.
Обозначим через Щ) функцию распределения (ФР) периода занятости системы Щ) =р{П t}, а через n(q) - ее преобразование Лапласа-Стилтьеса (ПЛС). Функцию распределения Wn(t) представим в виде w„(t)=\-p{w„ t}; B(t) = P{g t}, p(q) - ПЛС B(t), где P\wn t}=YJPkp\wn tlr(=K} - условная вероятность выполнения неравенства w„ t для пребывающего требования при условии, что в момент его поступления в системе находилось К других требований. Очевидно, время пребывания требования V в стационарном режиме равно V = W + где - время обслуживания требования. ФР Vn(t) СВ V можно определить следующим образом: V„(t) = P{V„ t}. ПЛС СВ Wn и Vn равны
Обозначим через P(q) ПЛС времени обслуживания СВ I Тогда Для данной системы вероятность того, что в момент времени окончания обслуживания в ней находится; других требований, равна [68] Воспользовавшись формулой Поллачека-Хинчина ад получаем w(a-az)=(l p)(l Z) . Учитывая, что q = a-az, имеем: Данное выражение дает возможность вычислить два первых момента стационарного времени ожидания и пребывания требований в системе:
Первые два момента периода занятости определяются следующим образом: щ = я- (О) = (ju-ау1, л2 = я"(0) = 2ju(ju-ay3. Используя таблицы преобразований Лапласа, получаем 11W == L(2utJp)e-(l-p)fJt, p = alu, dt t-Jp где I 1(t ) - функция Бесселя первого рода. Для анализируемой системы справедливы формулы Литтла L = Щ , N = Xwx, М = Щ, где L, N, M - соответственно математическое ожидание числа требований в системе, числа требований, ожидающих обслуживания, и стационарного числа занятых обслуживающих приборов (ОП).
Фазу обработки запросов представим как СМО M/D/1/. Для данной СМО имеем = t0 = const, поэтому Производная функция (ПФ) числа требований в СМО в стационарном режиме, как следует из формулы Поллачека-Хинчина, имеет вид
Обращая преобразование Лапласа w(q)/q (например, с помощью таблиц), приходим к выводу, что ФР стационарного времени ожидания в этом случае имеет вид
Для данной фазы СМО Ml D/1/ имеем Р = м0, где t0 = const - время обслуживания, а ПЛС времени обслуживания соответственно /3(g) = е . Из [59] следует, что вероятность обслуживания поступивших требований
Фазу управления представим совокупностью т СМО типа M/G/1/oo. В соответствии с [61] время обслуживания в СМО определяется состоянием сканирующего устройства системы.
Будем считать, что поступившее требование обслуживается мгновенно, если состояние датчика случайных чисел сканирующего устройства принимает значение 1. В противном случае считаем, что время обслуживания распределено экспоненциально с параметром Р.
