Размещено на http://www.allbest.ru/

Оглавление

Введение

Глава 1. Анализ предметной области

1.1 Анализ исходных данных

1.2 Актуальность разработки и аналоги

1.3 Обзор методов резервирования данных и выбор наиболее оптимального для бортового вычислителя

1.4 Обзор операционной системы реального времени QNX 4.25

1.5 Постановка задачи

Глава 2. Разработка алгоритмов программного обеспечения

2.1 Разработка алгоритмов и программного обеспечения модуля создания и изменения конфигураций кластера

2.2 Разработка алгоритмов и программного обеспечения модуля менеджера проектов кластера

2.3 Разработка алгоритмов и программного обеспечения модуля мониторинга состояния кластера

Глава 3. Отладка и тестирование программного обеспечения

Глава 4. Контрольный пример

Заключение

Список литературы

Приложение



Введение

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

Главной задачей разработки программного обеспечения является создание удобного инструмента, позволяющего создавать, модифицировать и отлаживать конфигурации отказоустойчивого кластера, обеспечивающего «горячее» резервирование данных и их быстрое восстановление в случаях их утраты при аварии одного из процессоров бортового вычислительного комплекса. Также в рамках поставленной задачи требуется разработать графическую систему отображения состояния узлов вычислительного комплекса для последующего мониторинга оператором с удаленного терминала. Разрабатываемое программное обеспечение должно функционировать под операционной системой реального времени QNX 4.25, ввиду ее соответствия высоким стандартам надежности, безопасности и масштабируемости, предъявляемых к бортовым системам.

Решению описанной задачи и посвящен данный дипломный проект.



Глава 1. Анализ предметной области

1.1 Анализ исходных данных

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

- операционная система реального времени QNX 4.25;

- унифицированный отказоустойчивый бортовой вычислитель (шифр «Кластер»);

- модуль сбора статистики о функционировании каждого из узлов кластера;

- язык программирования высокого уровня (Си/Си++).

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

Операционная система QNX 4.25 будет установлена на бортовой вычислитель, состоящий из 3-х узлов, также разрабатываемый на ОАО «НИИ «Аргон». В связи с тем, что вычислитель создается для использования на борту и крайне важны такие параметры как вес и размер, вычислитель спроектирован таким образом, чтобы имея в своем составе 3 полноценных процессорных модуля, ограничиваться всего одним физическим корпусом с централизованной системой охлаждения и вентиляции. Такая конструкция призвана сэкономить пространство и электроэнергию при работе вычислителя. Между узлами будет осуществляться соединение по технологии Ethernet, что обеспечит высокую пропускную способность при обмене данными между узлами сети.

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

В состав программного обеспечения также будут входить графические пользовательские интерфейсы. Для создания графических пользовательских интерфейсов используется визуальное средство разработки приложений Photon Application Builder 1.14, поставляемое вместе с графической оболочкой Photon для операционной системы реального времени QNX 4.25.

1.2 Актуальность разработки и аналоги

Менеджер высокой готовности QNX Neutrino

Менеджер высокой готовности (High availability manager (HAM)) функционирует в среде операционной системы реального времени QNX Neutrino.

Менеджер высокой готовности обеспечивает:

- Мгновенное обнаружение сбоя. HAM применяет сообщения проверки работоспособности (heartbeating), чтобы отслеживать состояние любого компонента, позволяя фиксировать сбои как можно раньше. Если HAM фиксирует определенное условие или сбой, он может немедленно и автоматически посылать сообщение о неисправности другим компонентам;

- Адаптированное к пользователю восстановление после сбоя. Используя библиотеку HAM, приложение может дать указание HAM, какие действия по восстановлению должны быть предприняты, в соответствии с порядком, в котором произошли ошибочные условия;

- Немедленное повторное соединение. HAM также обеспечивает библиотеку программ для выполнения действий по восстановлению клиента, которая позволяет системе немедленно повторно устанавливать разорванное соединение в случае сбоя компонента;

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

В качестве самоуправляемого менеджера HAM устойчив к внутренним сбоям. Если он по каким-либо причинам аварийно останавливается, он может немедленно и полностью реконструировать свое собственное состояние.

Менеджер высокой доступности (HAM) обеспечивает механизм, позволяющий выполнять мониторинг процессов и сервисов в функционирующей системе. Целью менеджера является восстановление вычислительного процесса, когда системные сервисы или процессы выходят из строя, не отвечают или обеспечивают неприемлемый уровень сервиса. Структура HAM прозрачно расширяет механизм локального мониторинга в сетевой мониторинг.

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

HAM состоит из следующих трех компонентов:

- Объекты (Entities)

- Условия (Conditions)

- Действия (Actions)

Объекты (Entities) являются фундаментальными единицами мониторинга в системе. По существу объектом является процесс, каждый процесс имеет уникальный идентификатор pid. Каждому объекту соответствует символическое имя, которое может использоваться, чтобы обращаться к этому специфическому объекту. Имена, соответствующие объектам уникальны в системе. Менеджеры в настоящий момент соответствующие узлу, также применяют к узлу уникальные правила. Эти уникальные требования очень похожи на схему наименований, используемую в иерархической файловой системе.

Условия соответствуют объектам. Эти условия представляют собой состояние объекта. Примеры условий:

- объект завершился;

- объект пропустил сообщение heartbeat;

- объект аварийно завершился, генерируется файл дампа памяти;

- выполнен рестарт объекта.

Условия (Conditions)соответствуют символические имена, которые также должны быть уникальны внутри объекта.

Действия соответствуют условиям. Условие может содержать множество действий. Действия выполняются каждый раз, когда соответствующее условие выполнено, т.е. истинно. Действия внутри условия выполняются в порядке FIFO (порядок, в котором они были добавлены в условие). Множество условий, которые являются истинными запускаются одновременно в произвольном (arbitrary) порядке. Условия, специфицированные как HCONDINDEPENDENT будут выполняться в отдельном потоке (separate thread) выполнения, параллельно с другими условиями.

Примеры действий:

- рестарт объекта;

- посылка сигнала некоторому процессу.

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

Когда действие в списке действий выполняется ошибочно, можно определить альтернативный список действий, которые будут выполнены, чтобы реализовать восстановление после сбоя данного действия.

Механизм восстановления позволяет выполнить восстановление в случае сбоя единичного сервиса или процесса.

Фактически внутреннее состояние HAM похоже на иерархическую файловую систему, где объекты похожи на директории, условия соответствуют этим объектам как поддиректории, и действия внутри этих условий похожи на узлы листьев этой структуры дерева.

HAM также представляет это состояние как файловую систему в режиме только чтения (read-only) под управлением директории /proc/ham. В результате такого представления произвольные процессы могут также просматривать текущее состояние (например, можно выполнить команду ls /proc/ham).

Мультиплекс-ОВ

Мультиплекс-ОВ представляет собой комплект средств (КС) для организации отказоустойчивых вычислений. Он предназначен для обеспечения отказоустойчивого функционирования серверных приложений в локальной вычислительной сети под управлением ОС МСВС 3.0.

Основные возможности:

Автоматическое восстановление функционирования приложения после сбоя (время восстановления не более 10 сек);

Возможность балансировки вычислительной нагрузки на серверах;

Возможность изменения логики принятия решения при осуществлении балансировки;

Возможность мониторинга и управления работой компонентов кластера серверов и выполняемых на нем приложений;

Возможность расширения списка регистрируемых событий;

Взаимодействие внешних клиентов с КС ОВ;

Контроль технологических параметров функционирования кластера.

В состав комплекта входят следующие программы:

1) Программа «Управление ОВ» обеспечивает управление функционированием КС «Мультиплекс-ОВ», его инициализацию и конфигурирование. Для организации логики управления КС «Мультиплекс-ОВ» используются две основные технологии:

- технология управления ресурсами основана на распределении и перераспределении ресурсов между ЦВМ КС «Мультиплекс-ОВ» в зависимости от настроек конфигурации, состояния ЦВМ, состояния самих ресурсов;

- технология балансировки нагрузки основана на виртуализации ЦВМ КС «Мультиплекс-ОВ» и перераспределении процессов обработки клиентских запросов между ЦВМ;

2) Программа «Организация ОВ» обеспечивает реализацию функций управления процессом организации отказоустойчивых вычислений. В процессе подключения и отключения новых ЦВМ к системе ОВ происходит масштабирование системы, При этом логика управления ресурсами берет на себя функции их распределения между работающими ЦВМ системы. Кроме того, на основе анализа состояния системы ОВ в целом, определяется наличие кворума и целесообразность продолжения функционирования сегмента, как элемента ОВ;

3) Программа «Мониторинг ОВ» обеспечивает мониторинг и управление работой компонентов КС «Мультиплекс-ОВ». Мониторинг необходим для отслеживания событий, требующих вмешательства оператора. При правильных настройках конфигурационных файлов КС «Мультиплекс-ОВ» оператор автоматически извещается о всех нарушениях работы. Задачей оператора является своевременное информирование соответствующих или иных служб и инициирование ликвидации сбоя;

4) Программа «Сопряжение ОВ» обеспечивает сопряжение различных модулей и их совместное функционирование в составе КС «Мультиплекс-ОВ»;

5) Программа «Тестирование ОВ» обеспечивает тестирование функций КС «Мультиплекс-ОВ».

На ЦВМ, входящих в состав кластера серверов Мультиплекс-ОВ, для выполнения программ должно быть настроено сетевое взаимодействие между ЦВМ по протоколу TCP/IP.

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

Входными данными для КС Мультиплекс-ОВ являются события изменения узлов и/или ресурсов кластера. Выходными данными КС Мультиплекс-ОВ являются новые оптимальные состояния узлов и ресурсов кластера как результат соответствующей миграции процессов, ресурсов и приложений.

Обоснование разработки

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

Актуальность разработки отказоустойчивого кластера подтверждается полным отсутствием программного обеспечения такого типа для рассматриваемой операционной системы QNX 4.25. Необходимость разработки именно под данную операционную систему обусловлена ее гибкостью, встраиваемостью и масштабируемостью, а также низкими системными требованиями и очень высокой надежность, которые полностью соответствуют заявленным заказчиком требованиям. Также стоит отметить, что операционная система QNX 4.25 сертифицирована для использования Государственной технической комиссией при Президенте РФ для подобных разработок.

1.3 Обзор методов резервирования данных и выбор наиболее оптимального для бортового вычислителя

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

Для того, чтобы система обладала высокими показатели готовности, необходимо:

1. чтобы ее компоненты были максимально надежными;

2. чтобы она была отказоустойчивая, желательно, чтобы не имела точек отказов;

3. а также важно, чтобы она была удобна в обслуживании и разрешала проводить замену компонент без останова.

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

В рассматриваемой ситуации, когда необходимо обеспечить бесперебойную работу такого важного коммуникационного компонента, как модуля связи с наземными объектами, чаще всего используются 3 вида систем резервирования (обеспечения отказоустойчивости):

- «Холодное» резервирование

- «Горячее» резервирование

- Мажоритарные системы.

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

Системы с «холодным» резервированием

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

1. обмен текущими результатами выполнения задачи;

2. определение признака сбоя обработки данных;

3. при наличии признака - восстановление вычислительного процесса на минимально-загруженном узле или на изначальном узле в случае его корректного функционирования.

Для обеспечения перезапуска процесса вычислений необходимо создавать контрольные точки, то есть запоминать результаты вычислений. Рестарт (перезапуск) осуществляется с ближайшей контрольной точки. Чем чаще устанавливаются контрольные точки, тем меньше времени будет потрачено на повторение вычислений в процессе рестарта, однако создание контрольных точек также требует дополнительного времени и объема памяти для их хранения.

Данная бортовая система характеризуется следующими особенностями:

- полная поддержка замены одних узлов другими в горячем режиме;

- прозрачное переключение задачи на другой узел при отказе;

- возможность диагностики в реальном времени;

- мониторинг и составление отчетов.

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

- запоминание/восстановление в памяти значений параметров состояния вычислительного процесса, обеспечивающих возможность восстановления с помощью процедуры рестарта;

- перераспределение полномочий управления процессами между ЦВМ.

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

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

Кластерные системы с «горячим» резервированием

Кластер высокой готовности - это группа модулей, работающих как единая система для предоставления высокой скорости доступа к данным.

Кластерная система характеризуется высокой надежностью, производительностью, гибким масштабированием и легкостью в управлении. Высокая надежность достигается путем дублирования всех критически важных для работы компонентов. Высокая производительность и масштабируемость - за счет распределения нагрузки между узлами (серверами) кластера. Легкость управления подразумевает собой возможность управлять как централизованно всем кластером, так и отдельными модулями, входящими в его состав.

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

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

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

Мажоритарные системы

В случае построения отказоустойчивого вычислителя по принципу мажоритарной системы, он состоит из трех процессорных модулей, соединенных между собой. Каждый процессорный модуль представляет собой отдельную БЦВМ.

Начальная загрузка БЦВМ мажоритарной системы (МС) производится одновременно при включении питания. В процессе начальной загрузки каждая БЦВМi (i -номер БЦВМ) имеет в памяти идентичные программные средства. В памяти каждой БЦВМ имеется таблица конфигурации, в которой отражается состояние всех БЦВМ МС. Строки таблицы конфигурации содержат следующие данные:

- признак наличия БЦВМ в конфигурации;

- состояние БЦВМ;

- признак текущей БЦВМ;

- режим работы БЦВМ для каждого внешнего интерфейса (активный, пассивный);

- признак главной БЦВМ. Одна из БЦВМ является главной;

- типы сбоев и реакция на них;

- информация для реконфигурации.

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

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

В процессе функционирования системы синхронизация БЦВМ выполняется по контрольным точкам. Параллельный просчет выполняется на всех трех БЦВМ, при этом содержимое памяти этих БЦВМ должно быть идентичным. Для проверки правильности результатов вычислений и синхронизации работы БЦВМ при параллельном просчете используется синхронный механизм контрольных точек сравнения.

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

Восстановление вычислительного процесса в МС выполняется в случае несовпадения результатов при параллельном просчете, или в случае обнаружения каких- либо случайных сбоев при контрольном тестировании. При этом выполняется синхронное восстановление вычислительного процесса во всех БЦВМ МС. Процедура восстановления вычислительного процесса заключается в выполнении следующих действий:

1. рестарте всех БЦВМ МС с последней контрольной точки хранения;

2. определении правильных исходных данных для продолжения вычислительного процесса.

3. Если перечисленные действия не дали результата, определяется неисправная БЦВМ. Неисправной БЦВМ считается в следующих случаях:

4. происходят ошибки при выполнении операций, которые фиксируются процессором (например, переполнение, ошибка адресации и т.п.), и которые не исправляются при выполнении рестарта с контрольной точки хранения;

5. данные БЦВМ не совпали с данными двух других БЦВМ (в двух других БЦВМ данные совпали);

6. контрольные тесты выявили неисправимые ошибки;

7. зафиксировано отсутствие ответа от какой-либо БЦВМ МС в течение определенного промежутка времени (истекает тайм-аут).

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

Выбор метода резервирования данных для бортового вычислителя

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

Таблица 1. Особенности методов кластеризации

Метод	Особенности
Холодное резервирование	Восстановление задачи происходит быстро, но только с начальными данными, все вычисления придется проводить заново
Горячее резервирование	Восстановление задачи быстрое, данные и прогресс выполнения задачи будут восстановлены с момента отказа, т.к. данные доступны всем узлам сразу
Мажоритарная система	Задачи выполняются одновременно на всех узлах и результаты сравниваются, при ошибке происходит синхронное возвращение всех данных на последнее верное значение

Исходя из приведенных в таблице 1 особенностей каждого из методов, второй является самым оптимальным, поскольку позволит восстановить данные максимально быстро. Значит, для бортового вычислителя будет использоваться метод «горячего» резерва.

Реализация механизма резервирования данных для бортового вычислителя

Из рассмотренных ранее методов кластеризации вычислительных процессов в нашем случае наиболее подходящим является метод «горячего» резервирования данных. Это объясняется тем, что в каждый момент времени может произойти миграция ресурсов с одного узла на другой практически без временных и вычислительных потерь за счет сохранения всех результатов вычислений для каждого из процессов на каждом из узлов.

В общем виде схема бортового вычислителя, построенного на принципе «горячего» резервирования будет выглядеть следующим как на рис. 1.

Рисунок 1. Схема кластерного ПО бортового вычислителя

Рассмотрим подробнее схему, показанную на рис. 1. Сам бортовой вычислитель состоит из нескольких (минимум 3-х) узлов. Каждый из них может выполнять свою задачу параллельно с работой остальных. Все результаты своей работы он хранит на общем носителе так, чтобы они были доступны всем остальным узлам. С точки зрения внешних систем, взаимодействующих с бортовым вычислителем, он выглядит как единое целое и вне зависимости от количества узлов будет дальше работать и передавать данные наружу.

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

То есть, после к примеру выхода из строя узла №4, на котором были запущены несколько задач(процессов) произойдет реконфигурация системы на взаимодействие меньшего количества узлов(4 вместо 5). Во время реконфигурации будет произведен перенос всех выполняемых ранее процессов с узла №4 на другой, наиболее свободный узел сети. Перенесенные процессы на новом узле будут запущены с того самого состояния, на котором было прервано их выполнение на родном узле. Таким образом, с точки зрения вычислительного процесса не произойдет никаких изменений и конечный вывод результатов из вычислителя будет на выходе ничем не отличаться от вывода системы со всеми работоспособными узлами. Схематично работу системы до и после аварии можно изобразить как показано на рис. 2.

Рисунок 2. Работа системы до и после аварии одного из узлов

Таким образом, система становится гораздо более устойчивой к отказам, становится вычислительно более мощной и способна за счет резервирования данных потерять до 30% своих аппаратных ресурсов, не теряя при этом данных и продолжая выполнение поставленной задачи.

1.4 Обзор операционной системы реального времени QNX 4.25

Разработка комплекса программного обеспечения для создания отказоустойчивого кластера производилось для операционной системы реального времени QNX версии 4.25.

QNX -- это POSIX-совместимая операционная система реального времени, предназначенная преимущественно для встраиваемых систем. QNX является коммерческим продуктом, то есть проприетарным программным обеспечением, а следовательно требует лицензии для установки на вычислительные машины и комплексы.

Как микроядерная операционная система, QNX основана на идее работы основной части своих компонентов как небольших задач, называемых сервисами. Это отличает ее от традиционных монолитных ядер, в которых ядро операционной системы - одна большая программа, состоящая из большого количества «частей», каждая со своими особенностями. Использование микроядра в QNX позволяет пользователям (разработчикам) отключить любую ненужную им функциональность, не изменяя ядро. Вместо этого можно просто не запускать определённый процесс. Система достаточно небольшая, вместе с этим она считается очень быстрой и должным образом «законченной» (практически не содержащей ошибок).

Рисунок 3. Схема архитектуры операционной системы QNX

QNX состоит из небольшого ядра, координирующего работу взаимодействующих процессов. Как показано на рисунке 3, структура больше напоминает не иерархию, а команду, в которой несколько игроков одного уровня взаимодействуют между собой и со своим "защитником" - ядром.

Микроядро операционной системы выполняет основные следующие функции:

передача сообщение - микроядро обеспечивает маршрутизацию всех сообщений между всеми процессами в системе;

диспетчеризация - планировщик - это часть микроядра, и он получает управление всякий раз, когда процесс изменяет свое состояние в результате получения сообщения или прерывания.

В отличие от всех остальных процессов, ядро никогда не получает управления в результате диспетчеризации. Входящий в состав ядра код выполняется только в результате прямых вызовов из процесса или аппаратного прерывания.

Все функции операционной системы, за исключением тех, которые выполняются ядром, в QNX предоставляются через стандартные процессы. Типичная конфигурация QNX имеет следующие системные процессы:

менеджер процессов;

менеджер файловой системы;

менеджер устройств;

менеджер сети.

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

Менеджер процессов тесно взаимодействует с Микроядром, чтобы обеспечить услуги, составляющие сущность операционной системы. Хотя он и является единственным процессом, который использует то же адресное пространство, что и Микроядро, Менеджер процессов выполняется как истинный процесс. И он, как и все остальные процессы, подвергается диспетчеризации со стороны Ядра и использует предоставляемые Микроядром примитивы передачи сообщений для связи с другими процессами в системе.

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

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

Микроядро QNX поддерживает три важнейшие формы связи между процессами: сообщения, прокси и сигналы.

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

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

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

Для непосредственной связи друг с другом взаимодействующие процессы используют встроенные в систему функции языка программирования Си (табл. 2).



Таблица 2. Функции взаимодействия процессов

Функция языка Си	Назначение
Send()	посылка сообщений
Receive()	получение сообщений
Reply()	ответ процессу, пославшему сообщение

Однако рассмотренные выше функции работают с сообщениями, состоящими из непрерывной последовательности байт. На практике сообщения часто состоят из двух или более отдельных частей. Например, сообщение может иметь заголовок фиксированной длины, за которым следуют данные переменной длины. Для того чтобы избежать копирования частей такого сообщения во временные промежуточные буферы при передаче или приеме, может быть использовано составное сообщение, состоящее из двух или более отдельных буферов сообщений. Именно благодаря этой возможности менеджеры ввода/вывода QNX, такие как Dev и Fsys, достигают своей высокой производительности.

Следующие функции позволяют обрабатывать составные сообщения: Creceivemx(), Readmsgmx(), Receivemx(), Replymx(), Sendmx(), Writemsgmx(). Некоторые из них будут использоваться в блоке взаимодействия программного обеспечения с драйвером и со сторонним программным обеспечением. При этом составные сообщения описываются с помощью встроенной mx структуры.

Обзор технологий QNX 4.25 для создания кластерного программного комплекса

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

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

1.5 Постановка задачи

Целью дипломного проекта является разработка программного модуля диспетчера высокой готовности для ОСРВ QNX 4.25, позволяющего запускать различные конфигурации отказоустойчивого кластера, а также в режиме реального времени проводить мониторинг его состояния. Исходя из требований, предъявляемых проекту необходимо разработать 3 основных блока программного комплекса:

- блок менеджера проектов;

- блок создания и изменения конфигураций кластера;

- блок мониторинга состояния кластера.



Рисунок 4. Структурная схема комплексного программного обеспечения «Кластер»

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

Кроме того, каждый из блоков будет взаимодействовать со сторонними элементами операционной системы:

- блок менеджера проектов должен производить функции записи и чтения из файловой системы

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

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



Глава 2. Разработка алгоритмов программного обеспечения

2.1 Разработка алгоритмов и программного обеспечения модуля создания и изменения конфигураций кластера

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

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

Блок создания, изменения и хранения конфигураций

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

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

Схематично иерархия конфигурации представлена на Рис. 5.

Рисунок 5. Иерархия формата конфигурации кластера

Настройки узлов в конфигурации кластера

В соответствии с требованиями заказчика каждый узел должен иметь в конфигурации некий минимум информации, характеризующей его назначение. В связи с этим при создании узла оператор назначает уникальный цифровой идентификатор узла кластера, задает имя узла (к примеру «Главный») и может добавить к нему краткое описание, чтобы в дальнейшем, при редактировании или пересмотре конфигурации можно было понять функции выбранного узла. К примеру, на первом узле будут запущены все процессы, которые должны выполняться системой. А оставшиеся 2 узла будут выполнять резервирующую функцию. Тогда первому можно будет в описании указать, что все процессы должны выполняться на нем, а двум другим, что они резервные. В итоге изменяя информацию о процессах, оператор уже заранее будет знать, что распределение процессов на другие узлы в начальной конфигурации выбранного проекта не предусматривалось и, следовательно, не допустит ошибок.

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

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

Разработанный тип хранения данных узлов, оформленный в виде структуры, выглядит на языке Си следующим образом:

typedef struct

int NodeId;

char Name[20];

char Descr[255];

char ProcFile[20];

struct Node *next;

} Node;

Node Nodes[3];

Следовательно, для трех узлов объявляется 3 структуры такого типа.

Настройки процессов на узлах в конфигурации кластера

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

- распределение всех процессов по узлам после добавления узлов;

- распределение процессов на конкретном узле сразу же после его создания.

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

Каждый процесс, также как и узел, имеет свой уникальный идентификатор, имя и описание. Но помимо стандартных параметров процессу могут быть заданы дополнительные свойства:

- параметры запуска процесса;

- приоритет запуска процесса;

- флаг запуска при старте;

- весовой коэффициент процесса;

- индекс очередности запуска;

- привязка процесса к определенному IP-адресу;

- зависимость от другого процесса.

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

Каждый из данных параметров также хранится в структурах, характеризующих каждый из процессов. Для этого был разработан формат хранения структур и на языке Си он выглядит следующим образом:

typedef struct

{ int Num;

int Descr[255];

char FileName[100];

char Opts[20];

int Deps[299];

int Prio;

int Run;

int Order;

int Weight;

} Process NodePcs[3][300];

Нижняя строчка информирует нас о том, что данным типом будет объявлен двумерный массив, первый идентификатор которого привязывает процесс к узлу, а второй закрепляет за процессом его уникальный идентификатор на этом узле. Количество процессов в 300 штук вызвано ограничением на узел, установленным заказчиком.

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

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

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

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

Вторым отличием главного узла от остальных является наличие полномочий принятия решения о перераспределении ресурсов между узлами кластера. Поскольку именно главному узлу первому доступна вся статистики использования и загрузки всех узлов сети, то именно на него возложена роль анализа состояния кластера и его оптимизация. Функции анализа загрузки и операции распределения задач по узлам кластера выполняются сторонним статистическим модулем, входящим в состав программного комплекса «Кластер».

Обязанности узлов и пути передачи информации иллюстрированы на рис. 6.

Рисунок 6. Обязанности узлов кластера

Блок инициализации кластера по созданной конфигурации

После создания конфигурации в редакторе, она может быть сразу превращена в реальную систему. Для этого в интерфейсе конфигуратора предусмотрена кнопка «Создать».

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

Рисунок 8. Файловая иерархия узла кластера

Каталог с рабочими фалами всех узлов находится по адресу //home/cluster каждого из узлов и содержит приведенный на рис. 6 набор файлов и директорий.

Папка +bin при работе кластера будет содержать уже скомпилированные для исполнения файлы процессов. Файл f_cluster.cfg содержит конфигурационную информацию, касающуюся узла. Папка +node_1 хранит в себе все файлы, отвечающие за пути к выбранным процессам, временные файлы, общие ресурсы узла и конфигурационные файлы процессов. Цифра в названии этой папки говорит об уникальном идентификаторе рассматриваемого узла.

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

Графический интерфейс пользователя для создания конфигураций кластера

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

Для удобства восприятия окно конфигуратора поделено на 3 области:

1. область задания и настройки узлов;

2. область задания и настройки процессов;

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

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

Все поля, где необходимо вводить цифровые значения, дополнены «качельками» вверх-вниз, для возможности альтернативного ввода без использования клавиатуры.

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

Все списковые элементы, а именно: узлы, процессы и зависимости между процессами выделяются синим цветом, как показано на рисунке 8. Яркий цвет выбран для того, чтобы пользователь всегда четко видел выделенный элемент, с которым он работает и не мог допустить случайную ошибку.

...