1.2. Актуальность разработки и аналоги 1.2.1. Менеджер высокой готовности 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).
1.2.2. Мультиплекс-ОВ
Мультиплекс-ОВ представляет собой комплект средств (КС) для организации отказоустойчивых вычислений. Он предназначен для обеспечения отказоустойчивого функционирования серверных приложений в локальной вычислительной сети под управлением ОС МСВС 3.0.
Основные возможности:
Автоматическое восстановление функционирования приложения после сбоя (время восстановления не более 10 сек);
Возможность балансировки вычислительной нагрузки на серверах;
Возможность изменения логики принятия решения при осуществлении балансировки;
Возможность мониторинга и управления работой компонентов кластера серверов и выполняемых на нем приложений;
Возможность расширения списка регистрируемых событий;
Взаимодействие внешних клиентов с КС ОВ;
Контроль технологических параметров функционирования кластера.
В состав комплекта входят следующие программы:
1) Программа «Управление ОВ» обеспечивает управление функционированием КС «Мультиплекс-ОВ», его инициализацию и конфигурирование. Для организации логики управления КС «Мультиплекс-ОВ» используются две основные технологии:
технология управления ресурсами основана на распределении и перераспределении ресурсов между ЦВМ КС «Мультиплекс-ОВ» в зависимости от настроек конфигурации, состояния ЦВМ, состояния самих ресурсов;
технология балансировки нагрузки основана на виртуализации ЦВМ КС «Мультиплекс-ОВ» и перераспределении процессов обработки клиентских запросов между ЦВМ;
2) Программа «Организация ОВ» обеспечивает реализацию функций управления процессом организации отказоустойчивых вычислений. В процессе подключения и отключения новых ЦВМ к системе ОВ происходит масштабирование системы, При этом логика управления ресурсами берет на себя функции их распределения между работающими ЦВМ системы. Кроме того, на основе анализа состояния системы ОВ в целом, определяется наличие кворума и целесообразность продолжения функционирования сегмента, как элемента ОВ;
3) Программа «Мониторинг ОВ» обеспечивает мониторинг и управление работой компонентов КС «Мультиплекс-ОВ». Мониторинг необходим для отслеживания событий, требующих вмешательства оператора. При правильных настройках конфигурационных файлов КС «Мультиплекс-ОВ» оператор автоматически извещается о всех нарушениях работы. Задачей оператора является своевременное информирование соответствующих или иных служб и инициирование ликвидации сбоя;
4) Программа «Сопряжение ОВ» обеспечивает сопряжение различных модулей и их совместное функционирование в составе КС «Мультиплекс-ОВ»;
5) Программа «Тестирование ОВ» обеспечивает тестирование функций КС «Мультиплекс-ОВ».
На ЦВМ, входящих в состав кластера серверов Мультиплекс-ОВ, для выполнения программ должно быть настроено сетевое взаимодействие между ЦВМ по протоколу TCP/IP.
Реализация отказоустойчивого функционирования достигается за счет реализации двух механизмов: механизма управления ресурсами кластера и механизма балансировки нагрузки.
Входными данными для КС Мультиплекс-ОВ являются события изменения узлов и/или ресурсов кластера. Выходными данными КС Мультиплекс-ОВ являются новые оптимальные состояния узлов и ресурсов кластера как результат соответствующей миграции процессов, ресурсов и приложений.
1.2.3. Обоснование разработки
При разработке отказоустойчивого бортового вычислителя возникла необходимость создания программного обеспечения, которое позволяло бы человеку-оператору, находящемуся за удаленным терминалом или рядом с самим комплексом, настраивать работу системы, создавать различные конфигурации кластера, запускать и тестировать их, а также проводить быструю диагностику состояния работающего кластера.
Актуальность разработки отказоустойчивого кластера подтверждается полным отсутствием программного обеспечения такого типа для рассматриваемой операционной системы QNX 4.25. Необходимость разработки именно под данную операционную систему обусловлена ее гибкостью, встраиваемостью и масштабируемостью, а также низкими системными требованиями и очень высокой надежность, которые полностью соответствуют заявленным заказчиком требованиям. Также стоит отметить, что операционная система QNX 4.25 сертифицирована для использования Государственной технической комиссией при Президенте РФ для подобных разработок.
|
