В дальнейшем этот перечень требований к ОСРВ будет продолжен и детализирован.
Рассмотрим общую концепцию работы такой системы. После получения результатов расчета на очередном цикле, система должна получить информацию о своем состоянии, для чего осуществляется обмен результатами с остальными ПЭ системы. При этом следует отметить, что обмен результатами счета со всеми узлами ВС в некоторой мере избыточен, так как для выявления некорректного результата достаточно двух верных (в предположении об ординарности потока отказов). Таким образом, протокол голосования может быть построен так, что результаты счета отдельного ПЭ в ВС троируются, т.е. могут не присутствовать в некоторых узлах системы.
Во время сравнения ПЭ делает вывод о нормальном или неправильном функционировании доступной ей подсистемы и выявляет ее причину. Результатами сравнения ПЭ обменивается со всеми узлами системы, и они принимают консолидированное решение об отказе того или иного элемента или делают заключение о нормальной работе системы.
В случае обнаружения отказа, на выход выдаются результаты, признанные верными при голосовании. Отказавшему элементу предоставляется возможность «исправиться» в течение следующих трех циклов. При этом сбойному ПЭ передается контекст верно функционирующей задачи. Тройная попытка самоустранить сбой этого узла, должна практически исключать возможность отключения работоспособного ресурса системы. Если сбои в этом элементе повторились, система считает элемент отказавшим, после чего производится подключение к работе резервного ПЭ (если он предусмотрен изначальной топологией сети) с передачей текущего контекста функциональных задач. При отказе связей передача данных производится через транзитные связи. Если элемент утратил все свои связи (линки), то он изолируется на логическом или, если это возможно – на физическом уровне (отключение питания).
В настоящее время существуют различные ОСРВ, призванные решать задачи организации вычислений в системах РВ. Однако ни одна из них не удовлетворяет поставленным требованиям в полной мере. Поэтому встает вопрос о необходимости расширения существующих ОСРВ или разработки новой ОС, удовлетворяющей им. Поскольку создание ОС с удобными средствами создания и отладки прикладного программного обеспечения - длительный и трудоемкий процесс, единственным выходом является доработка существующих ОС.
В качестве основного подхода к обеспечению отказоустойчивости предлагается использовать избыточность аппаратных и программных компонент системы. Данный подход предполагает решение следующих вопросов: . дополнение ОС высокоуровневыми функциями обмена. Используемые в большинстве ОС стандартные средства обмена данными, определенные стандартом POSIX (каналы, сигналы, разделяемая память, семафоры), имеют ограниченные возможности при взаимодействии процессов, не имеющих родственных связей. Организация межпроцессного взаимодействия с помощью механизма сокетов неудобна из-за необходимости привязки к конкретной сетевой информации (IP- адрес узла, номер порта приложения) и своей ориентированностью на модель клиент-сервер. . введение приоритета для передаваемых сообщений. Важность сообщений, передаваемых по сети, неодинакова. Например, сообщения об отказе какой- либо компоненты системы должны иметь наивысший приоритет для того, чтобы оповестить узлы сети в кратчайшие сроки. . выбор и реализация механизма голосования. При этом механизм передачи/приема данных и голосования должен быть по возможности скрыт от прикладного программиста.
Такая концепция построения операционной системы предусматривает наличие специальных средств обеспечения быстрого реагирования на отказ и реконфигурации системы. Ими являются модуль маршрутизации, обеспечивающий оптимальные маршруты для передачи функциональной и системной информации как на начальном этапе инициализации системы, так и в процессе ее функционирования при отказе тех или иных элементов и при подключении резервных, модуль реконфигурации, служащий для перестройки системных таблиц при отказах и восстановлении работоспособности системы, модуль межпроцессорного обмена, для передачи информационных и системных пакетов данных. Рассмотрим их структуру и назначение подробнее.
2.4.1. Описание системных таблиц
Основная информация о функционировании операционной системы на данном ПЭ размещена в системных таблицах.
Граф информационной связности процессорных элементов задаётся в виде модифицированной матрицы связности. Отличие от стандартной матрицы связности заключается в том, что в рамках одной строки, описывающей связность данного ПЭ с другими, используется число «-1» в случае, если этот процессорный элемент не связан с ПЭ, задаваемом столбцом, и номер канала связи (линка) по которому осуществляется эта связность в противном случае, причем нумерацию линков для удобства можно начинать c m+1 узла, то есть для узла m связь с узлом m+1 будет осуществляться линком с наименьшим номером.
Таблица 2.1
Пример таблицы связности для полносвязной сети ПЭ
|№/№ |1 |2 |3 |4 |… |N | |1 |-1 |0 |1 |2 |… |N-2 | |2 |N-2 |-1 |0 |1 |… |N-3 | |3 |N-3 |N-2 |-1 |1 |… |N-4 | |4 |N-4 |N-3 |N-2 |-1 |… |N-5 | |… |… |… |… |… |… |… | |N |0 |1 |2 |3 |… |-1 |
В дополнение к таблице связности, должна существовать таблица рассылки, в которой каждому ПЭ сопоставлен номер канала связи, по которому надо передать пакет дальше, чтобы он в конечном счете дошёл до адресата. Для полносвязной сети такая информация может показаться избыточной, однако если сеть неполносвязная или в ней произошли отказы связей, то таблица рассылки, формируемая на этапе инициализации и реконфигурации системы, позволит экономить время при обмене информацией или результатами голосования на каждом цикле. Составлением таблиц рассылки занимается модуль маршрутизации, структура и алгоритм работы которого будет рассмотрена ниже.
Приведем пример таблиц рассылки. Для наглядности возьмем сеть из четырех ПЭ, представленную на рисунке 2.1.
[pic]
Рис. 2.1. Пример неполносвязной сети
Цифры в окружностях – номера процессорных элементов, вне – номера линков (физических каналов связи). Таким образом таблица связности имеет вид (таблица 2.2).
Таблица 2.2
Таблица связности для примера на рисунке 2.1 |№/№ |1 |2 |3 |4 | |1 |-1 |0 |-1 |1 | |2 |1 |-1 |0 |-1 | |3 |1 |-1 |-1 |0 | |4 |0 |-1 |1 |-1 |
Таблицы рассылки для каждого ПЭ могут иметь вид (см. Таблицу 2.3, 2.4, 2.5, 2.6).
Таблица 2.3
Таблица рассылки для ПЭ №1 |№ ПЭ |1 |2 |3 |4 | |№ Линка |-1 |0 |0 |1 |
Таблица 2.4
Таблица рассылки для ПЭ №2 |№ ПЭ |1 |2 |3 |4 | |№ Линка |1 |-1 |0 |0 |
Таблица 2.5
Таблица рассылки для ПЭ №3 |№ ПЭ |1 |2 |3 |4 | |№ Линка |0 |1 |-1 |0 |
Таблица 2.6
Таблица рассылки для ПЭ №4 |№ ПЭ |1 |2 |3 |4 | |№ Линка |0 |0 |1 |-1 |
2.4.2. Модуль маршрутизатора
Как уже отмечалось в подразделе 2.4.1 маршрутизатор выполняет следующие функции: . хранение текущей топологии многопроцессорной системы; . установление оптимальных статических маршрутов передач данных в системе и таблиц рассылки; . обработка сигналов изменения топологии системы от реконфигуратора. При инициализации требуется исходная топология системы. Таким образом, модуль маршрутизации можно представить в виде следующей упрощенной схемы:
Рис. 2.2. Модуль маршрутизации
Во время инициализации, для каждого ПЭ составляется список текущих соседних узлов системы для обмена результатами счета так, чтобы данные каждого ПЭ присутствовали в тройном экземпляре в ВС.
Таблицы рассылки, в которой каждому ПЭ сопоставлен номер канала связи, по которому надо передать пакет дальше, формируются методом волны на основе таблиц связности ПЭ. Маршрут выбирается минимальным по количеству рёбер графа сети, с учетом загрузки связей. Так как операционные системы узлов идентичны, то пакеты, проходящие через их связи можно считать одинаковыми. Загрузка связи определяется по числу возможных транзитных передач через эту связь, и транзитные передачи равномерно распределяются по узлам сети без потерь на длине маршрута.
Алгоритм определения статических маршрутов и заполнения таблицы рассылки:
1. Заполняем таблицу рассылки в соотвествие со строкой с номером, равным номеру процессорного элемента. Заполняем соответствующую таблицу расстояний единицами (счетчик длины маршрута) в тех ячейках, где есть прямая связь в таблице связности (>0).
2. Если обработаны все ПЭ, закончить.
3. Увеличиваем счетчик длины маршрута на 1 единицу (передачу).
4. По таблице рассылки находим очередной ПЭ, не имеющий связи с локальным. Если таких больше нет, шаг 8.
5. Среди имеющих связь ПЭ ищем по таблице расстояний того, у кторого маршрут был определен на предыдущем цикле. Если таких больше нет, шаг 7.
6. Если он имеет связь с нужным ПЭ, запоминаем номер линка для связи его с локальным ПЭ и загрузку линка. Шаг 5.
7. Сортируем найденные линки по наменьшей загруженности и заносим его в таблицу рассылки и таблицу расстояний. Если обработаны все ПЭ, закончить, иначе шаг 3.
2.4.3. Модуль реконфигурации
Модуль реконфигурации активизируется и выполняет перестройку системных таблиц ОС на основе информации о конкретном отказе. Рассмотрим обработку отказа функциональной задачи, отказа канала связи и отказа процессора целиком.
При этом приостановки работы системы в общем случае не должно происходить из-за возможной необходимости в выдачи управляющих воздействий в жестком цикле работы системы. Резервы времени должны предусматриваться на этапе проектирования в зависимости от вычислительных ресурсов элементов системы. Таким образом, реконфигурация должна быть выполнена до начала выдачи результатов контроллерам приемников управляющей информации. . Отказ канала связи. Первоначально корректируется матрица связности ПЭ.
При этом определяется, имеет ли отказавший канал связи отношение к данному процессорному элементу. В случае, если после отказа канала связи, какой-либо процессор оказывается изолированным, выполняется отключение процессорного элемента. . Отказ процессорного элемента. Обработка отказа всего процессорного элемента выполняется посредством коррекции матрицы связности ПЭ, удаление всех каналов связи. . Отказ функциональной задачи трактуется так же, как и отказ процессорного элемента.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
