Характерной особенностью многих клиент-серверных приложений корпоративных систем управления предприятием (КСУП) является их разнородность и распределенная архитектура [3]. При проектировании распределенных программных архитектур КСУП имеется ряд специфических особенностей. Это в первую очередь зависимость архитектурной модели от ряда нефункциональных системных требований, например производительности, защищенности, безопасности, надежности [7]. При анализе архитектурных решений современных КСУП существенное значение имеет возможность оценки архитектурной надежности клиент-серверных приложений как важной составляющей системы [10].
В распределенной системе разные компоненты могут быть реализованы на разных языках программирования и выполняться на разных типах процессоров [2]. Модели данных, представление информации и протоколы взаимодействия не являются однотипными в распределенных системах, поэтому архитектурная надежность программного обеспечения (ПО), обеспечивающего взаимодействие и обмен данными, является немаловажным фактором при проектировании КСУП [4, 5].
В архитектуре «клиент-сервер» серверная часть, как правило, устанавливается на отдельном компьютере-сервере, а клиентские части ПО на рабочих местах, причем функциональный состав ПО на рабочих местах различен. Серверная и клиентские части ПО могут функционировать в различных операционных средах, поэтому системы клиент-серверных приложений представляют интерес на предмет анализа надежностных характеристик архитектуры этого ПО [8, 12].
В работе анализ клиент-серверных приложений рассматривается на примере корпоративной системы управления предприятием «Галактика». Данная система ориентирована на автоматизацию решения задач, возникающих на всех стадиях управленческого цикла: прогнозирование и планирование, учет и контроль реализация планов, анализ результатов, коррекция прогнозов и планов [1, 6].
Корпоративная система управления предприятием «Галактика» соответствует по уровню функциональности, технологичности и степени интеграции системы современным концепциям ERP (Enterprise Resource Planning – «планирование ресурсов предприятия»), SCRP (Custom Synchronized Resource Planning – «планирование ресурсов, синхронизированное покупателем»), SEM (Strategic Enterprise Management – «стратегическое управление предприятием»), а также стандартам открытых систем. КСУП «Галактика» имеет модульную структуру, причем сотни автоматизированных рабочих мест могут иметь различный функциональный состав. При этом КСУП «Галактика» имеет общую базу данных для всего предприятия, поддерживает различные платформы СУБД: Pervasive SQL, MS SQL, Oracle.
Оценка программного обеспечения КСУП «Галактика»
Анализ архитектуры распределенного ПО КСУП «Галактика» является одним из наиболее значимых моментов при разработке программных продуктов данного класса. Архитектуру системы «Галактика» можно рассматривать как состоящую из следующих слоев:
– слой интерфейсов (клиентская часть КСУП «Галактика»);
– слой бизнес-логики (серверная часть КСУП «Галактика»);
– слой БД (серверная часть СУБД).
Для анализа надежности архитектур ПО КСУП «Галактика» введем следующие обозначения: M = 3 – число уровней архитектуры ПО; D1 и D2 – непересекающиеся множества компонент на уровнях 1 и 2; D3 – состоит из одного элемента – СУБД; Ri – коэффициент надежности каждого элемента архитектуры (коэффициент надежности СУБД также входит в это множество как отдельный элемент); TCi и TEi – для всех i равны нулю (так как анализ и устранение сбоя в системе не предусмотрены), кроме TCs и TEs для СУБД (практически каждая СУБД имеет механизмы восстановления после сбоя); TAi и TUi – для разных компонент могут быть различны (сильно зависят от быстродействия сети передачи данных).
При анализе архитектурной надежности клиент-серверных приложений следует учитывать, что архитектурные компоненты взаимосвязаны, т.е. отказ в одном компоненте может распространиться через систему на другие компоненты [11]. При этом могут быть использованы показатели, позволяющие определить безотказность и работоспособность программного обеспечения клиент-серверных приложений КСУП [9].
Среднее время простоя системы TR в архитектуре зависит как от условных и безусловных вероятностей сбоев на всех уровнях архитектуры, так и от среднего времени доступа, анализа и восстановления сбойных компонент [5]. При предлагаемом подходе время устранения сбоя на архитектурном уровне СУБД равно времени, которое требуется для доступа, анализа, восстановления, а это означает, что время восстановления меньше, чем время устранения сбоя.
Если используется автоматическое восстановление и компонент не содержит сбоев, то он в рамках модели рассматривается, как восстановленный компонент. При этом ошибка того же типа, что была устранена ранее, считается новой ошибкой.
Среднее время простоя системы вычисляется для всех трех архитектурных уровней и всех компонентов на каждом уровне КСУП. Для каждого выделенного уровня в архитектуре ПО вероятность использования каждого компонента умножается на вероятность сбоя компонента и на сумму средних времен анализа, доступа и восстановления для этого компонента.
Дополнительно, сбойный компонент может вызывать сбои в зависящих от него компонентах как на других уровнях архитектуры, так и на том же самом уровне. Поэтому для каждого отдельного уровня архитектуры и для всех компонентов условная вероятность появления сбоя умножается на сумму относительных времен доступа, анализа и восстановления этих компонентов.
Также, для одного уровня и для всех компонентов, условная вероятность появления сбоя умножается на сумму относительных времен доступа, анализа и восстановления этих компонентов.
Относительное время анализа и восстановления для данной модели учитывается только для уровня сервера СУБД, а для остальных компонент принимается равным нулю.
Таким образом, среднее время простоя системы может быть определено по формуле
(1)
где F – общее число компонент в архитектуре ПО; M – число уровней архитектуры ПО; Di – непересекающиеся множества компонент на уровне i, i ∈ {1, …, M}; PUi – вероятность использования компонента i, i ∈ {1, …, F}; PFi – вероятность сбоя в компоненте i, i ∈ {1, …, F}; PLij – условная вероятность сбоя в компоненте i при сбое в компоненте j, i ∈ {1, …, F}, j ∈ {1, …, F}; TAi – относительное время доступа к компоненту i, i ∈ {1, …, F}; TCi – относительное время анализа сбоя в компоненте i, i ∈ {1, …, F}; TEi – относительное время устранения сбоя в компоненте i, i ∈ {1, …, F}. Кроме того, PU5, PF5, TA5, TC5, TE5, PL55 – соответствующие параметры для компонента сервера СУБД.
Среднее время появления сбоя MTTF зависит как от условных и безусловных вероятностей сбоев во всех компонентах на всех архитектурных уровнях, так и от относительного времени использования компонентов, в которых сбой не происходит [5].
Среднее время сбоя вычисляется для всех архитектурных уровней и всех компонентов на каждом архитектурном уровне. Для каждого архитектурного уровня ПО вероятность использования компонента умножается на вероятность того, что каждый компонент будет работать без сбоев в течение относительного времени его использования.
Вдобавок для каждого отдельного архитектурного уровня и для всех компонентов условная вероятность работы без сбоев умножается на относительное время использования этих компонентов. Для того же архитектурного уровня и для всех компонентов условная вероятность работы без сбоев перемножается на относительное время использования этих компонентов. Уровень, на котором сбой не происходит, также влияет на среднее время появления сбоя.
Определим среднее время появления сбоя следующим образом:
(2)
где TUi – относительное время использования компонента i, i ∈ {1, …, F}.
Коэффициент готовности системы вычисляется по формуле
S = MTTF/(MTTF + TR).
Коэффициент надежности архитектуры ПО может быть оценен согласно следующей формуле:
где Ri – коэффициент надежности компонента i, i ∈ {1,..,F}.
Для анализа надежности реально функционирующих клиент-серверных приложений КСУП часто могут быть полезны упрощенные формулы для определения среднего времени простоя системы и среднего времени появления сбоя, которые используются при экспресс-анализе надежностных характеристик архитектуры ПО.
Так, для простоты расчетов формулы (1) и (2) можно модифицировать, не учитывая в них множества компонент Di. При этом соответствующие формулы примут вид
Формулы (3) и (4) являются более грубыми по сравнению с (1) и (2), но могут успешно применяться для экспресс-анализа надежностных характеристик ПО клиент-серверных приложений КСУП «Галактика» при расчете показателей (3) и (4).
(3)
(4)
Заключение
Оценка надежности клиент-серверных приложений корпоративной системы управления предприятием, которые моделируются как набор сервисов, предоставляемых сервером клиентским процессам, важен для предотвращения потерь информации в системах данного класса. Сбор и хранение данных – дорогостоящая процедура, поскольку часто данные стоят больше, чем компьютерная система, на которой они обрабатываются. Предлагаемые аналитические выражения позволяют выполнить оценку основных показателей надежности клиент-серверных приложений корпоративной системы управления предприятием и на основе полученных данных принять решение о необходимости усовершенствования архитектуры и доработки отдельных программных компонент с целью повышения уровня надежности программного обеспечения корпоративной системы управления предприятием в целом.
Предлагаемый подход может быть использован при разработке современного программного обеспечения корпоративных систем управления предприятием, к которым предъявляются повышенные требования по надежности. Рассмотренный в работе набор показателей, используемых при анализе надежности клиент-серверных приложений корпоративных систем управления предприятием, может быть расширен, так как наиболее подходящие показатели для конкретной системы определяются в зависимости от типа системы и области ее применения. Более того, для различных корпоративных систем управления предприятием могут оцениваться разные показатели надежности.
Рецензенты:
Носков М.В., д.ф.-м.н., профессор, заместитель директора по научной работе, Институт космических и информационных технологий, Сибирский федеральный университет, г. Красноярск;
Ченцов С.В., д.т.н., профессор, зав. кафедрой «Системы автоматики, автоматизированное управление и проектирование», Сибирский федеральный университет, г. Красноярск.