Представление процессов

Параллелизм в ISSS основывается на элементах типа «приложение» (application). Приложение в данном случае примерно соответствует процессу (в том смысле, который вкладывал в это понятие Дийкстра, рассуждая о кооперации последовательных процессов) и лежит в центре методики, которую разработчики ISSS адаптировали для обеспечения отказоустойчивости. Каждое приложение реализуется в виде «основного» модуля языка Ada (процесса, планируемого операционной системой) и составляет один из элементов CSCI (что помогает выявить соответствие между представлениями декомпозиции модулей и процессов). Взаимодействие приложений проходит в форме передачи сообщений, которые в рамках представления «компонент и соединитель» выступают в роли соединителей.

В конструкции системы ISSS предусматривается возможность многопроцессорной обработки. Логическая комбинация процессоров называется группой процессоров (processor group — об этом мы говорили применительно к физическому представлению), а предназначена она для размещения ряда отдельных копии одного или нескольких приложений. На этом принципе основывается отказоустойчивость, а следовательно, и готовность. Одна исполняемая копия является первичной, а все остальные — вторичными; отсюда названия отдельных копии приложения: основное адресное пространство (primary address space, PAS) и запасное адресное пространство (standby address space, SAS). Совокупность основного адресного пространства и сопровождающих его запасных адресных пространств называется операционным блоком (operational unit). Каждый отдельно взятый операционный блок полностью размещается в процессорах одной группы - напомним, ч го на одну группу может приходиться от одного до четырех процессоров. Те элементы системы ISSS, которые конструируются без расчета на отказоустойчивость (другими слонами, не предполагают сосуществования основной и запасной версий), запускаются независимо на разных процессорах. Называемые функциональными группами (functional groups), они при необходимости могут быть размещены на любом процессоре; при этом каждая копия представляет собой отдельный экземпляр программы с собственным состоянием.

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

Приложения взаимодействуют по модели «клиент-сервер». Клиент транзакции отсылает серверу сообщение-запрос на обслуживание (service request message), на которое тот отвечает подтверждением. (Как и во всех прочих реализациях клиент-серверной схемы, любая сторона — в данном случае приложение — в одной транзакции может выступать в роли клиента, а в другой — в роли сервера.) Основное адресное пространство (PAS) внутри операционного блока отправляет всем своим резервным пространствам (SAS) уведомления о смене состояния; резервные пространства, готовые в случае отказа основного пространства или соответствующего процессора заменить его, постоянно пребывают в состоянии ожидания тайм-аутов и других стимулов к действию. Рисунок 6.6 иллюстрирует координацию основного и резервных адресных пространств приложения при резервировании и передаче результатов их взаимодействия группам процессоров.

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

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

1. Одно из резервных адресных пространств становится основным.

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

3. Для замены предыдущего основного адресного пространства запускается новое резервное адресное пространство.

4. Новое резервное адресное пространство извещает новое основное пространство о своем существовании и с этого момента начинает получать от последнего сообщения с обновлениями.

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

Введение нового операционного блока осуществляется следующим образом-

♦ Определяются и локализуются необходимые входные данные.

♦ Определяются операционные блоки, рассчитывающие на получении выходных данных от нового операционного блока.

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

♦ Сообщения конструируются в расчете на достижение заданных данных.

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

♦ Данные состояния разбиваются на сообщения, соответствующие формату применяемой сети.

♦ Определяются необходимые типы сообщений.

♦ На случай отказов составляется план переключения, который в целях обеспечения полноты состояния регулярно обновляется.

♦ Планируется непротиворечивость данных в случае переключения.

♦ Необходимо сделать так, чтобы отдельные этапы обработки проходили быстрее, чем продолжается один «такт» системы.

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

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

Представление процессов отражает сразу несколько тактик реализации готовности — в частности, «повторную синхронизацию состояния», «затенение», «активное резервирование» и «снятие с эксплуатации».