Синтез систем реального времени с гарантированной доступностью программно-информационных ресурсов

А. В. Прокопенко
М. А. Русаков
Р. Ю. Царев

Монография

Институт космических и информационных технологий

синтез систеМ 
РеАльного ВРеМени 
с гАРАнтиРоВАнной достуПностьЮ 
ПРогРАММно-инфоРМАЦионных
РесуРсоВ

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

9 785763 827484

ISBN 978-5-7638-2748-4

Оглавление 

1 

Министерство образования и науки Российской Федерации 
Сибирский федеральный университет 
 
 
 
 
 
 
 
 
А. В. Прокопенко, М. А. Русаков, Р. Ю. Царев 
 
 
 
СИНТЕЗ СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ 
С ГАРАНТИРОВАННОЙ ДОСТУПНОСТЬЮ 
ПРОГРАММНО-ИНФОРМАЦИОННЫХ РЕСУРСОВ 
 
 
Монография 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Красноярск 
СФУ 
2013 

Оглавление 
 

2 

УДК 004.031.43 
ББК 32.973.233-018 
        П804 
 
 
 
 
 
Р е ц е н з е н т ы:  А._Н._Антамошкин, д-р техн. наук, проф., зав. 
кафедрой мат. моделирования и информатики Краснояр. гос. аграр. ун-та; 
А. В. Медведев, д-р техн. наук, проф. кафедры «Системный анализ 
и исследование операций» Сиб. гос. аэрокосм. ун-та им. акад. М. Ф. Решетнева 
 
 
 
 
 
 
 
 
 
Прокопенко, А. В. 
П804        Синтез систем реального времени с гарантированной доступностью программно-информационных ресурсов : монография / А. В. Прокопенко, М. А. Русаков, Р. Ю. Царев. – Красноярск : Сиб. федер. ун-т, 
2013. – 92 c. 
ISBN 978-5-7638-2748-4 
 
Рассмотрена проблема формирования систем реального времени с гарантированной доступностью ресурсов. Предложены модели использования программно-информационных ресурсов с учетом ресурсной базы и ограничений на 
время исполнения. Описаны методика и алгоритмы формирования вектора временной развертки для кластерных структур распределенных архитектур систем 
реального времени, учитывающие занятость ресурсов.  
Предназначается магистрантам направления 230100.68 «Информатика           
и вычислительная техника», а также специалистам в области проектирования 
систем управления и обработки информации, аспирантам и докторантам. 
 
УДК 004.031.43 
ББК 32.973.233-018 
 
ISBN 978-5-7638-2748-4 
                                                      © Сибирский федеральный  
                                                                                              университет, 2013 

Оглавление 

3 

ОГЛАВЛЕНИЕ 
 
 
ВВЕДЕНИЕ………………………………………………………………. 
5
 
1. АНАЛИЗ СОВРЕМЕННЫХ  МЕТОДОВ  РЕАЛИЗАЦИИ 
    ОТКАЗОУСТОЙЧИВОГО  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ 
6
1.1. Обеспечение отказоустойчивости……………………………… 
6
1.1.1. Адекватность программного обеспечения………………. 
6
1.1.2. Обеспечение доступности ресурсов……………………... 
9
1.2. Обеспечение гарантированной готовности…………………….. 
13
1.2.1. Аппаратно-программная избыточность серверов………. 
13
1.2.2. Модель централизованного управления………………… 
15
1.2.3. Интеграция сетевого и системного администрирования 
16
1.2.4. Программно-информационные технологии  
          сетевого администрирования…………………………….. 
17

1.2.5. Программно-информационные технологии  
          системного администрирования…………………………. 
20
1.2.6. Анализ проблем управления  
          программно-информационными технологиями………… 
24
1.3. Проектная парадигма мультиверсионного формирования 
       отказоустойчивого программного обеспечения……………….. 
25
1.3.1. Особенности проектной парадигмы…………………….. 
25
1.3.2. Принципы формирования………………………………… 
28
 
2. ТЕХНОЛОГИЯ  ФОРМИРОВАНИЯ  
    ОТКАЗОУСТОЙЧИВОГО  ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ 
36
2.1. Постановка задачи формирования  
       отказоустойчивого мультиверсионного  
       программного обеспечения…………………………………….. 
36
2.2. Модель использования ресурсов с учетом ресурсной базы  
       и ограничений на время исполнения…………………………… 
39
2.2.1. Формальное представление вектора временной развертки   
 с учетом ресурсных и временных ограничений……………… 
43
2.2.2. Формальное представление оптимального вектора  
          конфигурации при стоимостных ограничениях……….. 
48
2.3. Алгоритмы мультиверсионного формирования  
       программного обеспечения…………………………………….. 
49
2.3.1. Общий алгоритм решения задачи оптимизации  
          мультиверсионного состава……………………………… 
50
 

Оглавление 
 

4 

 

2.3.2. Алгоритм проверки вектора конфигурации  
          на ресурсные и временные ограничения……………….. 
51
2.3.3. Алгоритм формирования вектора следования…………. 
53
2.3.4. Алгоритм формирования ресурсного вектора  
         временной развертки………………………………………. 
56
 
3. ФОРМИРОВАНИЕ  ОТКАЗОУСТОЙЧИВЫХ   
    ПРОГРАММНО-ИНФОРМАЦИОННЫХ  ТЕХНОЛОГИЙ  
    ПРЕДПРИЯТИЯ……………………………………………………… 
59
3.1. Процедуры формирования……………………………………… 
59
3.1.1. Обеспечение функциональности………………………… 
60
3.1.2. Обеспечение надежности и масштабируемости………… 
60
3.1.3. Формирование ресурсных требований………………….. 
61
3.1.4. Формирование топологии корпоративного кластера…... 
63
3.1.5. Выбор сервером дисковых подсистем и соединений….. 
64
3.1.6. Корпоративная операционная система………………….. 
66
3.1.7. RMS – программное обеспечение кластера…………….. 
68
3.1.8. Принципы корпоративной системы……………………... 
71
3.2. Программная система поддержки  
       мультиверсионного формирования  
       отказоустойчивого ПО СРВ……………………………………... 
74
3.2.1. Конструктор структуры мультиверсионных компонент 
75
3.2.2. Объектная модель………………………………………… 
75
3.2.3. Функциональные возможности системы……………….. 
77
3.3. Использование программной системы поддержки  
       для повышения доступности ресурсов корпоративной СУБД 
81
3.3.1 Процедуры настройки и оптимизации СУБД ORACLE 
81
3.3.2. Оптимизация быстродействия СУБД ORACLE  
          для гарантированной доступности ресурсов……..………... 
83
 
ЗАКЛЮЧЕНИЕ…………………………………………………………. 
86
 
БИБЛИОГРАФИЧЕСКИЙ  СПИСОК………………………………… 
88
 

Оглавление 

5 

ВВЕДЕНИЕ 

Анализ современных систем реального времени (СРВ), используемых в различных областях производства, показывает, что ключевую роль в 
обработке информации играет программное обеспечение (ПО). Создание и 
модернизация СРВ предъявляют высокие требования по надежности к 
программному обеспечению, так как именно ПО определяет надежностные 
характеристики систем данного класса.  
Невыполнение этих требований может стать причиной отказа СРВ, 
что повлечет за собой значительные экономические потери в рамках как 
отдельного предприятия, так и всего Красноярского края. На сегодняшний 
день существует ряд подходов к созданию высоконадежного ПО СРВ.  
Одним из самых распространенных подходов к реализации программной отказоустойчивости является введение избыточности. Методология мультиверсионного программирования как один из подходов к реализации идеи введения избыточности в структуру программного обеспечения на практике доказала свою эффективность. С ее использованием были 
реализованы программные комплексы систем управления летательными 
аппаратами, атомными электростанциями и т. п. Однако такой метод ведет 
к увеличению стоимости системы, в которой он применяется. 
Рациональное структурное построение программного обеспечения 
СРВ гарантирует достаточно полное применение ресурсов системы, а технологические особенности проектирования ПО СРВ, дополняя проблему 
структурного программного и информационного проектирования, выводят 
ее в разряд общих проблем разработки методов и автоматизированных 
систем проектирования сложных программно-информационных комплексов. 
Проблеме формирования программных комплексов, проектируемых 
на основе принципов программной избыточности, в настоящее время уделяется значительное внимание. Проектирование программных комплексов с использованием методологии мультиверсионного программирования рассматривалось в работах А. Авижиениса, Н. Ашрафи, О. Бермана, М. Катлер, Дж. Ву, 
К. Яо, Р. К. Скотта, Д. МакАллистера, К. Е. Гросспитча и многих других. 
Разрабатываются новые методы оптимизации версионного состава, новые 
системы формирования структуры, но без учета временных и ресурсных 
ограничений. 
Таким образом, существует важная социально-экономическая проблема, связанная с созданием новой технологии производства ПО, обеспечивающей высокий уровень надежности и отказоустойчивости ПО СРВ с 
гарантированной доступностью ресурсов, что требует разработки комплекса моделей и алгоритмов, предназначенных для создания оптимального по составу высоконадежного ПО СРВ с учетом ресурсной базы и ограничений на время выполнения основных задач системы. 

1. Анализ современных методов реализации отказоустойчивого программного обеспечения 
 

6 

1.  АНАЛИЗ   
СОВРЕМЕННЫХ  МЕТОДОВ  РЕАЛИЗАЦИИ  
ОТКАЗОУСТОЙЧИВОГО  
 ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ 
 
 
Надежность и отказоустойчивость программного обеспечения (ПО) 
систем реального времени (СРВ) обходится дорого. Существующие отказоустойчивые решения базируются либо на операционных системах собственной разработки, либо на одном из клонов Unix [33]. Поставщики аппаратных платформ СРВ обеспечивают высокую надежность, заставляя платить за избыточность аппаратных и программных средств. Еще больше 
возрастает эта плата, когда необходимо решать программными средствами 
не нашедшие своего аппаратного решения проблемы, возникающие в ходе 
неизбежных упущений в процессе разработки. Здесь анализируется проблема повышения надежности ПО СРВ и рассматриваются современные 
аппаратно-программные решения, обеспечивающие требуемую отказоустойчивость СРВ и доступность ресурсов.  
 
 
1.1. Обеспечение отказоустойчивости 
 
В работах [33, 36, 37] отмечается, что до недавнего времени надежными системами считались только сложные закрытые и дорогие СРВ, 
предполагающие частое дублирование узлов. С появлением открытых 
компьютерных сетей появилась возможность строить надежные управляющие системы из универсальных компонентов, которые можно заменить 
в случае аварии без нарушения работоспособности СРВ.  
 
1.1.1. Адекватность программного обеспечения 

Задача создания программного обеспечения СРВ, которое успешно 
функционирует даже при наличии ошибок, гораздо труднее, чем может 
показаться на первый взгляд. Причем проблема сильно отличается от проблемы исправления ошибок, возникающих при работе аппаратных платформ. Очевидно, что разработка программ, защищающихся от ошибок, 
стоит дорого. Однако избыточность является минимальной платой за надежность не только аппаратных средств, но и программного обеспечения.  
Хотя кажется, что выход СРВ из строя можно легко определить,        
в действительности это не совсем так [1, 31]. Дело в том, что не всегда 
простая работа серверов или обработка запросов является достаточным 

1.1. Обеспечение отказоустойчивости 

7 

признаком функционирования СРВ. Если при этом получаемая или хранящаяся в базе данных информация не соответствует реальности, то систему 
можно считать неработоспособной. В то же время авария одного сервера 
может не нарушить работоспособность всей системы в целом. Рассмотрим 
подробнее, какие именно условия должны соблюдаться при нормальном 
функционировании системы [43]. 
Целостность данных. Данные, находящиеся в корректно функционирующей СРВ, должны быть непротиворечивыми и соответствовать реальности. Система может стать нефункциональной, если в нее внесены несанкционированные изменения. К сожалению, проконтролировать точность данных достаточно сложно, тем не менее, в критически важных СРВ 
нужно предусмотреть контроль целостности, например, по контрольной 
сумме или с помощью электронно-цифровой подписи. 
Управляемость. Для изменения конфигурации и исправления ошибок в СРВ должны быть предусмотрены механизмы управления и контроля 
ее состояния. Если система выйдет из-под контроля, то также нельзя говорить 
о ее штатной работе, поскольку она может неадекватно реагировать на запросы. Поэтому все СРВ должны иметь механизмы контроля состояния          
и инструменты для изменения их конфигурации без остановки всей системы. 
Безопасность. Чтобы исключить несанкционированное изменение 
системы управления и целостность данных, нужно предусмотреть механизмы идентификации и авторизации пользователей, а также обеспечить 
конфиденциальность определенных данных. В некоторых случаях компрометация конфиденциальной информации эквивалентна выходу системы из строя. Это, например, относится к данным системы контроля целостности. Поэтому нужно предусмотреть механизмы идентификации пользователей, авторизации их доступа к ресурсам системы и криптографической защиты конфиденциальных данных. 
Связность. Современное сложное программное обеспечение СРВ 
состоит, как правило, из нескольких компонентов. Естественно, при нарушении связи между компонентами система не сможет выполнять свои 
функции, поэтому логично предусмотреть подсистемы сетевого управления и мониторинга. Сейчас большинство каналов связи в СРВ строятся на 
базе протокола TCP/IP, который был разработан для ненадежных сетей        
и имеет все необходимые механизмы для установления надежных сеансов 
связи. Поэтому в большинстве случаев для контроля связности достаточно 
использовать стандартные способы, предусмотренные в TCP/IP. Для критически важной по отказоустойчивости СРВ (ее подсистемы или компонента) нужно иметь механизмы для проверки работоспособности, поскольку важно знать – корректно или нет работает система (подсистема 
или компонент).  

1. Анализ современных методов реализации отказоустойчивого программного обеспечения 
 

8 

За соблюдением целостности данных, как правило, следят те компоненты, которые эти данные и обрабатывают. В то же время контроль связности и безопасности лучше всего делать централизованно, поскольку для 
работоспособности СРВ важно общее состояние этих подсистем. Для решения конкретных задач, возможно, потребуется наложение дополнительных условий. 
Когда определены критерии работоспособности ПО СРВ, можно обсуждать основные рабочие характеристики, которые будут обеспечивать 
корректную работу. Следующие характеристики легко формализуемы и 
могут быть указаны в техническом задании для разработчиков. 
Надежность. Доля времени непрерывной работы ПО СРВ – чем 
больше эта величина, тем меньше система простаивает. Для критически 
важных приложений [31] нужно добиваться минимум 99,9 % надежности. 
Общим требованием сегодня стало «пять девяток» – 5 мин простоя в год. 
Однако такие же требования нужно предъявлять и к сетевому оборудованию, каналам подключения и электропитанию. Естественно, что надежность серверов должна быть выше надежности рабочих станций и мобильных устройств. 
Отказоустойчивость. Количество одновременных отказов компонентов ПО СРВ, которые приводят к прекращению работы: чем больше 
узлов системы нужно вывести из строя для прекращения ее работы, тем 
более отказоустойчива такая система. Отказоустойчивость повышает общую надежность СРВ, собранной из недостаточно надежных компонентов 
[27]. Требования по отказоустойчивости определяются по разности между 
требуемым уровнем надежности и реальной надежностью существующих 
компонентов. 
Доступность. Время, за которое обеспечивается доступ к данным 
или сервису СРВ: чем меньше это время, тем выше доступность. Доступность определяется несколькими факторами, наиболее важными из которых являются: надежность ПО СРВ, ее производительность и количество 
абонентов. 
Масштабируемость. Отношение текущей производительности СРВ 
к максимально достижимой без архитектурных изменений. То есть чем 
больше можно наращивать производительность, тем выше масштабируемость. Эта характеристика влияет на доступность системы: когда компьютеры уже не успевают обрабатывать запросы, нужно увеличить производительность системы, а это зависит от возможностей масштабируемости. 
Требования по масштабируемости определяются исходя из затрат на архитектурную перестройку системы и стоимости простоя в случае, когда текущей производительности уже не хватает. 

1.1. Обеспечение отказоустойчивости 

9 

Время восстановления. Даже самое надежное ПО СРВ иногда выходит из строя, например, вследствие аппаратного сбоя или аварии. Время 
восстановления после аварии также является важной характеристикой для 
жизненно важных систем. Причем восстановление ПО СРВ – это не только 
обеспечение доступа к серверам и приложениям, но и восстановление целостности важных данных. Необходимое время восстановления определяется по ущербу от простоя системы [19]. 
Ключевой характеристикой является доступность, которую, с одной 
стороны, можно легко замерить, а с другой – она зависит от всех остальных характеристик. Следует отметить, что требования по доступности могут меняться в зависимости от времени суток, дня недели и месяца. Например, если в конце месяца готовится финансовый отчет, то в эти дни 
требования по доступности финансовой подсистемы СРВ ужесточаются. 
Регламентные работы нужно планировать так, чтобы обеспечить требования по доступности жизненно важных приложений. 
 
1.1.2. Обеспечение доступности ресурсов 

Возможны два способа повышения доступности ресурсов СРВ: увеличение индивидуальной надежности серверов и улучшение общесистемной отказоустойчивости системы [12–14, 37]. В первом случае увеличивается надежность каждого элемента системы, что позволяет строить конфигурации высокой доступности из небольшого количества компонентов. 
Для построения надежной распределенной СРВ обычно используется 
большое количество не очень надежных компонентов, а высокая надежность всей системы достигается многократным дублированием. Рассмотрим методы увеличения аппаратной надежности.  
Резервирование. Таким способом увеличивается отказоустойчивость СРВ по отношению к сбоям внутренних компонентов: блоков питания, дисков, процессоров и т. п. При использовании резервирования главное вовремя заметить сбой и перевести систему на работу с резервным 
аналогом выходящего из строя компонента. При этом для резервирования, 
например, блоков питания не требуется программной поддержки, в то время как для памяти, жестких дисков и процессора часто приходится менять 
и ПО. В результате решение перестает быть универсальным, и его нельзя 
применить для других серверов. 
Горячая замена. Вместе с дублированием горячая замена позволяет 
выполнять ремонт серверов без прекращения их работы, что увеличивает 
доступность, но уменьшает отказоустойчивость и надежность СРВ во время смены блока. Наиболее сложно обеспечить горячую замену процессоров, памяти и жестких дисков, поскольку для этого нужно реализовать динамическую перестройку операционной системы. Кроме того, необходимо