Особенности обеспечения надежности ВС

Построение многопроцессорных ВС привело к пересмотру всех традиционных представлений о надежности.

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

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

Таким образом, в проблемно-ориентированных ВС проблема сбоев и отказов решается комплексно в соответствии с применением ВС.

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

Аппаратновыполняются следующие действия:

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

2. Передача информации об аварии по специальным шинам в другие модули.

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

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

Программновыполняются следующие действия:

1. Сбор и обработка диагностическо информации аварийного модуля.

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

3. Сохранение в системном журнале информации об аварии.

Таким образом, в САР предусмотрены различные реакции на разные типы аварий.

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

Возникновение асинхронно аварии на процессе ОС всегда завершается большим рестартом.