Подход к обеспечению высокой готовности

Преимущества программных методов обеспечения высокой готовности

Решение в виде "перезагрузки" системы

К традиционным механизмам обнаружения программных сбоев относятся:

Аппаратный/программный сторожевой таймер

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

Ручное вмешательство оператора

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

Обнаружение нарушения границ памяти

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

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

Традиционная архитектура ОСРВ

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

Поскольку все задачи (в том числе критически важные системные службы) работают в едином адресном пространстве, нарушение выполнения одной задачи создает риск общесистемного сбоя. Например, неполадки в драйвере устройства могут вывести из строя всю ОСРВ. В терминах высокой готовности это означает, что каждый программный компонент является единой точкой отказа (англ. Single Point Of Failure, SPOF).

Единственным эффективным механизмом восстановления такой системы является ее перезагрузка и возобновление работы «с нуля».

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

Гибкий модульный подход

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

Модульный подход также кардинально уменьшает среднее время восстановления системы (англ. Mean Time To Repair, MTTR), поскольку перезагрузка всей системы выполняется на порядок дольше возобновления одной задачи.

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

Далее мы кратко рассмотрим основные из этих возможностей и их применение в проектировании и разработке эффективных систем высокой готовности.

Отказоустойчивость на уровне операционной системы

Архитектура ЗОСРВ «Нейтрино» обладает тремя ключевыми атрибутами, которые позволяют применять ее в разработке систем высокой готовности:

Микроядро

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

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

Модель процессов POSIX

Устройство управления памятью (MMU) позволяет с легкостью изолировать и полностью защищать отдельные задачи, а процессная модель предусматривает динамическое создание и уничтожение процессов; эти механизмы играют важную роль в системах высокой готовности, поскольку позволяют обнаруживать сбои, а также восстанавливать и обновлять системы в полевых условиях.

API POSIX формирует стандартную программную среду, упрощает структуру систем, облегчает их валидацию и верификацию.

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

Передача сообщений

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

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

Перечисленные основные атрибуты позволяют применять ЗОСРВ «Нейтрино» в качестве платформы для проектирования систем высокой готовности.

Предыдущий раздел: Менеджер высокой готовности (HAM)