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

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

Монография

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

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

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

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]. В первом случае увеличивается надежность каждого элемента системы, что позволяет строить конфигурации высокой доступности из небольшого количества компонентов. 
Для построения надежной распределенной СРВ обычно используется 
большое количество не очень надежных компонентов, а высокая надежность всей системы достигается многократным дублированием. Рассмотрим методы увеличения аппаратной надежности.  
Резервирование. Таким способом увеличивается отказоустойчивость СРВ по отношению к сбоям внутренних компонентов: блоков питания, дисков, процессоров и т. п. При использовании резервирования главное вовремя заметить сбой и перевести систему на работу с резервным 
аналогом выходящего из строя компонента. При этом для резервирования, 
например, блоков питания не требуется программной поддержки, в то время как для памяти, жестких дисков и процессора часто приходится менять 
и ПО. В результате решение перестает быть универсальным, и его нельзя 
применить для других серверов. 
Горячая замена. Вместе с дублированием горячая замена позволяет 
выполнять ремонт серверов без прекращения их работы, что увеличивает 
доступность, но уменьшает отказоустойчивость и надежность СРВ во время смены блока. Наиболее сложно обеспечить горячую замену процессоров, памяти и жестких дисков, поскольку для этого нужно реализовать динамическую перестройку операционной системы. Кроме того, необходимо 

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

10 

правильно спроектировать корпус сервера, который позволял бы менять 
внутренние элементы, не вынимая весь сервер из монтажной стойки. 
Диагностика. Немаловажным элементом высоконадежных СРВ является диагностика компонентов: перегрева процессора, памяти, системной платы, а также контроль возникновения ошибок. Диагностика позволяет предупредить аварию и вовремя заменить блок, который пока еще работает корректно, но может дать сбой. Если в системе предусмотрена горячая замена данного компонента, то это позволяет исправить поломку 
еще до ее возникновения. Правильная диагностика важна для тех серверов, 
доступ к которым получить сложно. 
Кластеризация. Имеется две реализации кластеров, обеспечивающих совместную работу нескольких компьютеров: аппаратная и программная. Аппаратный кластер предусматривает специальные компоненты 
для поддержки целостности кластера и обрабатываемых им данных. Программный позволяет реализовать кластер из универсальных серверов и сетевых технологий, но требует поддержки со стороны операционной системы: баланса загрузки, контроля работоспособности узлов, перераспределения ресурсов и решения других задач [47]. Собственно аппаратные кластеры выпускаются уже давно, а сегодня начали появляться и программные 
кластеры. 
Различные производители серверных платформ используют комбинации этих механизмов, стремясь реализовать их с меньшими затратами,           
а на некоторые компоненты надежных систем есть уже и промышленные 
стандарты – это, прежде всего, касается подсистем хранения с RAIDмассивами и микросхем памяти с коррекцией ошибок.  
Таким способом даже в простых системах можно уменьшить вероятность потери данных, однако их доступность при этом не увеличивается. 
Для повышения доступности данных и приложений нужно обеспечить постоянную работу процессоров и сетевых соединений. Для увеличения надежности сетевых соединений, как и для блоков питания, достаточно их 
дублировать и обеспечить горячую замену, хотя придется предусмотреть 
механизмы перераспределения загрузки и контроля работоспособности. 
Именно этим путем идут сегодня все производители серверного оборудования. 
Более сложной проблемой является обеспечение непрерывной работы процессоров, что возможно в многопроцессорных серверах, где процессор располагается на отдельном модуле с возможностью горячей замены. 
Однако нужно еще обеспечить программную поддержку смены процессорных модулей в операционной системе. Так, на серверах Compaq 
NonStop Himalaya [33] используется программная технология парных процессов.  

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

11 

Суть ее заключается в том, что на различных процессорах выполняются два процесса – первичный и резервный. Первичный посылает резервному контрольные сообщения, чтобы тот в случае аварии мог подхватить 
исполнение. В результате при замене или выходе из строя одного процессора его функции тут же подхватят другие. Причем эта технология никак 
не связана с конкретным типом процессора. В частности, Compaq объявил 
о переносе NonStop Kernel – ОС с поддержкой парных процессов – на процессор Itanium. 
По другому пути пошла компания IBM, которая реализовала аппаратное резервирование процессоров прямо на кристалле. Процессоры 
Power4, на которых у IBM построены серверы серии р690, имеют два одинаковых ядра, которые могут проверять работу друг друга. Кроме того,          
в серверах этой серии есть дополнительная система, которая контролирует 
состояние оборудования. В частности, именно эта система динамически 
перераспределяет вычисления между процессорами в случае выхода одного из них из строя. В серверах серии р690 также предусмотрен один независимый процессор, который контролирует работу всего оборудования:           
от процессоров до шин PCI и ISA. В результате в этих серверах обеспечивается достаточно высокий уровень надежности и доступности. 
Рассмотрим системные методы увеличения надежности ПО СРВ. 
Многоуровневые приложения. Разделение монолитного приложения на несколько уровней позволяет увеличить масштабируемость и доступность, а также частично уменьшить время восстановления. Поскольку 
компоненты многоуровневого ПО СРВ могут выполняться на процессорах, 
разнесенных на любое расстояние друг от друга, то возникает возможность 
максимально приблизить внешние компоненты к пользователям и достигнуть максимальной доступности СРВ. Кроме того, при разделении ПО 
СРВ на уровни обычно предусматривается, что компонент одного уровня 
может работать с несколькими компонентами других уровней, поэтому 
при выходе из строя одного компонента достаточно подключиться к другому аналогичному. Время восстановления в этом случае равно времени 
переподключения. 
Стандартизация. Использование для построения ПО СРВ стандартных компонентов позволяет увеличить масштабируемость и время восстановления.  
В этом случае при аварии одного компонента его можно заменить 
одним или несколькими аналогичными. Если они соответствуют стандарту, то функционирование системы не изменится, при условии, что все данные аварийного компонента будут доступны для его новых экземпляров. 
При использовании стандартных форматов представления данных компоненты можно практически в любой момент перевести на более производи