Повышение надежности программного обеспечения для распределенных систем управления

Качество любой вычислительной сети (ВС) можно оценить, используя ее основные характеристики. К ним относятся полнота выполняемых функций, производительность, пропускная способность, надежность, безопасность, прозрачность, масштабируемость и универсальность [1]. Ни один из этих критериев нельзя однозначно назвать самым важным, но среди них можно выделить несколько наиболее весомых. Одним из таких критериев является надежность [2–5].

Надежность – это способность ВС безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью [6–8]. При низком уровне надежности ВС будет затронут и функционал систем, отвечающих за показатели других критериев качества. Поэтому обеспечение надежности ВС является приоритетной задачей при построении компьютерной сети [9].

Полностью искоренить возможность возникновения сбоев невозможно, а потому обеспечение надежности заключается в уменьшении количества ошибок, с которыми может столкнуться пользователь при функционировании сети. Одним из наиболее проверенных и зарекомендовавших себя способов повышения надежности является введение избыточности [10; 11].

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

Программную избыточность нельзя достигнуть с помощью дублирования – ошибки, возникающие в программных модулях, имеют внутреннюю природу [12], что приводит к появлению тех же ошибок в идентичных копиях. Поэтому вместо копий необходимо создавать новые версии, отличающиеся друг от друга языком программирования, разработавшими их программистами, использованными алгоритмами. Благодаря внутренним отличиям разных версий вероятность возникновения аналогичных сбоев минимизируется [13; 14].

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

Модель оценки надежности ПО

На надежность СПО влияют его иерархические уровни - зависимость программных модулей друг от друга может привести к тому, что сбой в одном модуле распространится по архитектуре всего СПО [16]. Модель, описывающая надежность СПО, должна учитывать влияние иерархии программных модулей на сбои и время простоя [17].

Обозначения, применяемые в модели:

• 1)    М - количество архитектурных уровней в архитектуре СПО;

• 2)    N j - количество модулей на уровне j , j е {1, .., M};

• 3)    D ij - множество индексов модулей, зависящих от модуля i на уровне j , i е {1, .., N j }, j е {1, ., M};

• 4)    F ij - событие сбоя, произошедшего в модуле i на уровне j , i е {1, .., N j }, j е {1, .., M};

• 5)    PU jj - вероятность использования модуля i на уровне j , i е {1, ..., N j }, j е {1, ..., M};

• 6)    PF ij - вероятность появления сбоя в модуле i на уровне j , i е {1, ., N j }, j е {1, ., M};

• 7)    PL inm - условная вероятность появления сбоя в модуле m на уровне n при появлении сбоя в модуле i на уровне j , i е {1, ., N j }, j е {1, ., M}, n е {1, ., N m }, m е {1, ., M };

• 8)    TA jj - относительное время доступа к модулю i на уровне j , i е {1, ., N j }, j е {1, ., M}, определяемое как отношение среднего времени доступа к модулю i на уровне j к числу сбойных модулей на малых уровнях архитектуры за одно и тоже время;

• 9)    TC ij - относительное время анализа сбоя в модуле i на уровне j , i е {1, ., N j }, j е {1, ., M }, определяемое как отношение среднего времени анализа сбоя в модуле i на уровне j , i е {1, ., N j }, j е {1, ., M }, к числу сбойных модулей на всех уровнях архитектуры, анализируемых в одно и тоже время;

• 10)    TE ij - относительное время устранения сбоя в модуле i на уровне j , i е {1, ., N j }, j е {1, ., M }, определяемое как отношение среднего времени восстановления в модуле i на уровне j , i е {1, ., N j }, j е {1, ., M}, к числу сбойных модулей на всех уровнях архитектуры, в которых происходит устранение сбоев в одно и тоже время;

• 11)    TU ij - относительное время использования модуля i на уровне j , i е {1, ., N j }, j е {1, ., M }, определяемое как отношение среднего времени использования модуля i на уровне j , i е {1, ., N j }, j е {1, ., M}, к числу модулей на всех уровнях архитектуры, используемых в одно и тоже время;

• 12)    Z ij - множество версий модуля i , на уровне j , к = 1, ., K ;

• 13)    T ij - трудоемкость разработки модуля i на уровне j ;

• 14)    Т у - трудоемкость разработки версии к модуля i на уровне j , к е Z ij в чел-часах;

• 15)    NVX ij - трудоемкость разработки приемочного теста (для RB ) или алгоритма голосования (для NVP );

• 16)    T s - общая трудоемкость сети;

• 17)    B ij - дихотомическая переменная, принимающая значение 1 (тогда NVP ij = 0, RB ij = 0), если в программном модуле не используется программная избыточность, иначе равна 0;

• 18)    NVP ij - дихотомическая переменная, принимающая значение 1 (тогда B ij = 0, RB i = 0), если в программном модуле используется программная избыточность по методу N -версионного программирования, иначе равна 0;

• 19)    RB ij - дихотомическая переменная, принимающая значение 1 (тогда B ij = 0, NVP ij = 0), если в программном модуле используется программная избыточность по методу блока восстановления, иначе равна 0;

• 20)    TR - среднее время простоя СПО ВС, определяемое как время, в течение которого система не может выполнять свои функции;

• 21)    MTTF - среднее время появления сбоя в СПО ВС, определяемое как время, в течение которого сбоев в системе не происходит;

• 22)    S - коэффициент готовности СПО ВС;

• 23)    T s - общая трудоемкость реализация СПО.

Среднее время сбоя сетевого программного обеспечения вычислительной сети равно:

M Nj

MTTF = Vу )pu х (1 - PF 1X ГTU. + ij                   ij L ij j=1 i=1

M    ^N m

+ у у 1 - PL-3 nm

( m = 1 ) & ( m ^ j ) n = 1 k

X TU nm

У 1 - PL™\ X TU_im} lm im

1 e D nm                      J J

+

+У

k ^e D ij

( 1 - PL kj ) x k

(

TU kj

k

M   N m

У  У ( ( 1 - PL^j ) x ( TU nm +

( m = 1 ) & ( m * j ) n = 1

+ У ( ( 1 - PL™ ) x TU im ) ))))]}.

^{1 e} D nm

Среднее время простоя сетевого программного обеспечения вычислительной сети равно:

TR =

_MM j

УУ { PU j х PF ,j X j = 1 i = 1

( TA j

+ IC, + IE , ) +

M Nm

У у PL. X nm

( m = 1 ) & ( m * j ) n = 1 k

Yl

(TAnm + TCnm + TEnm) + У (PL™ x (TAm + TCm + TEim )) leDnm                                J J xy LPLkj xL( TA* + TCk + TE)+ k e Dij

х

M   N m

+ У У

( m = 1 ) & ( m # j ) n = 1

kj PL _nm

X (TAnm + TCnm + TEnm) + У PPLm™ X nm nm nm             lm k                            1 e Dnm

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

_S MTTF

= MTTF + TR

.

Сами по себе данные показатели рассматривают надежность СПО ВС лишь в ее начальном состоянии. В [18] описаны два основных метода введения мультиверсионности: NVP ( N- version programming) и RB (recovery block).

NVP подразумевает, что все версии программы выполняются параллельно, а результат их работы определяется с помощью алгоритма голосования [19]. Надёжность мультиверсионного модуля i на уровне j , построенного из K версий методом мультиверсионного программирования для любого k , равна

где p _i ^v _j – вероятность безотказной работы алгоритма голосования; p _i ^k _j – вероятность безотказной работы версии k е Z ij .

При подходе RB мультиверсионность вводится через добавление нескольких версий вычислительного модуля, создание приёмочного теста, проверяющего работу версий, и подпрограммы, которая, опираясь на результаты теста, либо принимает результат работы модуля, либо выбирает другую версию и перезапускает вычисление [19]. Надежность такого модуля:

K          k -1

kAT         l AT l AT

R ij = L p ij p ij ПЦ¹ - p y ) p ij + p ij ⁽¹ - p j ) ) , k е Z ij            l = 1

где p _i ^A _j ^T – вероятность безотказной работы приемочного теста для модуля i , i = 1, …, N на уровне j, j = 1, .., M ; p k - вероятность сбоя версии k е Z ij .

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

PF =\-R ij ij .

При введении программной избыточности всегда встает вопрос: сколько именно версий нужно вводить? Возможность применения мультиверсионности ограничена множеством факторов. Одним из наиболее весомых из них является трудоемкость, отражающая трудозатраты на постройку сети, напрямую зависящие от количества версий программных модулей, которые необходимо разработать. Для отражения этого ограничения в модели есть формула [20]:

MN i

T = УУ BT + (NVP_U + RB_U )x NVX_U + y T k  .

sijijijijijij j=1 i=1                                   (            k е Zij    J

При исследовании ВС на этот показатель можно опираться для нахождения оптимального количества версий для каждого программного модуля. Исследовать сеть можно разными способами, но у всех них одна суть: трудоемкость T s должна стремиться к минимуму, а коэффициент готовности S – к максимуму.

Исследование надежности СПО

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

Для проведения исследования возьмем СПО, состоящее из 10 модулей. Предположим, что все модули, за исключением одного, работают без сбоев (т. е. имеют надежность равную 1). Общая надежность ПО будет определяться надежностью критичного модуля со значением 0,55. В него вводится программная избыточность методом NVP , трудоемкость разработки новых версий этого модуля берется за 1000.

В таблице представлены результаты зависимости показателей надежности СПО от версий одного из его модулей, а на рисунке наглядно отображена динамика изменения параметров.

Результаты исследования СПО

Количество версий критичного модуля	Среднее время простоя	Среднее время до сбоя	Коэффициент готовности	Трудоемкость
1	82115	169838	0,5500	6981
2	47509	175844	0,7975	7981
3	21373	180379	0,9089	8981
4	9619	182420	0,9590	9981
5	4340	183336	0,9815	10981

Динамика изменения параметров ПО ВС

Computer network software parameters’ change dynamics

Заключение

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

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

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