Многоуровневое представление

Прикладные программы управления воздушным движением в системе ров ISSS исполняются в среде AIX — одной из коммерческих разной операционной системы UNIX. Впрочем, для обеспечения функционирования отказоустойчивой распределенной системы, каковой является ISSS, набора служб UNIX недостаточно. Отсюда потребность в введении дополнительного обслуживающего программного обеспечения. Иерархия уровней программной среды стандартного процессора ISSS представлена на рис. 6.8.

Строго говоря, на рис. G.8 изображена накладка (overlay) совмещающая многоуровневое представление и представление "компонент и соединитель", - дело в том, что на этой схеме показаны характерные для периода прогона связи между подмодулями на разных уровнях. Правда, связи между службами комплексной системы автоматизации (AAS) и драйверами прочих устройств, с одной стороны и остальными подмодулями с другой, здесь не показаны — они многочисленны, что могли бы занять все пространство диаграммы. Большинство элементов многоуровневой системы могут обращаться к ней совершенно свободно. Фактически установленные связи мы перечислим в пояснительном тексте.

Два нижних ряда элементов, расположенные непосредственно над ядром Щ заняты расширениями AIX, исполняемыми внутри адресного пространства этого ядра. Согласно требованиям к производительности и совместимости с операционной системой AIX, эти расширения в основном выполнены в виде небольших программ на языке С. Поскольку исполняются эти программы в адресном пространстве ядра, их неисправности потенциально способны нанести ущерб системе AIX; таким образом, это должны быть относительно небольшие и надежные программы, отражающие тактику ограничения внешних воздействий (см. главу 5), Эта тактика, изначально предназначенная для реализации безопасности (конкретнее, для предотвращения атак типа «отказ от обслуживания), в ISSS используется для повышения готовности. К счастью, некоторые тактики с одинаковым успехом реализуют сразу несколько атрибутов качества.

Основную роль во взаимодействии между модулями диспетчера локальной готовности в рамках блока управления секторами исполняет диспетчер элементарной трансляции (atomic broadcast manager, ABM) — он обеспечивает готовность функций этого блока. Диспетчер станций, с одной стороны, представляет в основной сети передачи данных службы дейтаграмм, а с другой — выступает в роли локального представителя управляющих служб этой сети. Аналогичные функции для двухточечной передачи сообщений предусматриваются на подуровне сетевых интерфейсов, который пользуется сетевой информацией совместно с диспетчером станций.

На двух следующих уровнях представлены расширения операционной системы; поскольку они исполняются вне адресного пространства ядра AIX, их не исправности не способны напрямую повредить AIX. Как правило, эти программ составляются на языке Ada.

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

На верхнем уровне находятся приложения. Диспетчер локальной 14)1 и программа внутренней временной синхронизации представляют coбой системные службы прикладного уровня. Диспетчер локальной готовности осуществляет управление запуском, завершением и готовностью прикладных программ. Путем взаимодействия со всеми адресными пространствами на своем процессоре он контролирует их работу и проверяет состояние. Кроме того, он обменивается информацией с диспетчерами локальной готовности на других процессорах в рамках данного блока управления сектором и, таким образом, координирует готовность его функций — в частности, функции переключения с первичной на резервную копию прикладной программы. Наконец, диспетчер локальной готовности взаимодействует с глобальным приложением контроля готовности, находящимся на консоли мониторинга и управления, — в ходе этого он составляет для последнего отчеты о состоянии и принимает от него команды управления. Программа внутренней временной синхронизации синхронизирует такт процессора с тактами других процессоров системы ISSS, обеспечивая, таким образом, нормальную работу функций контроля готовности. (См. представление отказоустойчивости на рис. 6.9.)

управление запуском, завершением и готовностью прикладных программ. Пу- М взаимодействия со всеми адресными пространствами на своем процессоре он контролирует их работу и проверяет состояние. Кроме того, он обменивается информацией с диспетчерами локальной готовности на других процессорах в рамках данного блока управления сектором и, таким образом, координирует готов­ность его функций — в частности, функции переключения с первичной на резерв­ную копию прикладной программы. Наконец, диспетчер локальной готовности взаимодействует с глобальным приложением контроля готовности, находящим­ся на консоли мониторинга и управления, — в ходе этого он составляет для по следнего отчеты о состоянии и принимает от него команды управления. Программа внутренней временной синхронизации синхронизирует такт процессора с такта­ми других процессоров системы ISSS, обеспечивая, таким образом, нормальную работу функций контроля готовности. (См. представление отказоустойчивости на рис. 6.9.)

Новое представление: отказоустойчивость

Как мы уже говорили, перечень представлений, приведенный в главе 2, не явля­ется исчерпывающим. Перечня, учитывающего все представления программной архитектуры для всех возможных систем или для отдельно взятой системы, не может быть в принципе. Радостно, что в последнее время все больше внимания уделяется вопросам влияния программной архитектуры на реализацию атрибу­тов качества; соответственно, признается важность ясного формулирования ожи­даемых от архитектуры атрибутов качества. Пытаясь достичь этой цели, архитек­торы имеют обыкновение составлять такие представления, которые демонстрируют реализацию архитектурой конкретного атрибута качества, — например, представ­ление безопасности. Что касается атрибутов качества периода прогона, то здесь представления составляются в категориях «компонент и соединитель» и демон­стрируют взаимодействие между элементами в этот период. Для атрибутов каче­ства, не относящихся к периоду прогона, представления составляются в категориях модулей и показывают проектные характеристики блоков реализации, направ­ленные на реализацию того или иного атрибута качества — например, модифи­цируемости.

Из-за повышенных требований к готовности системы ISSS отказоустойчивость стала неотъемлемой характеристикой ее проектного решения. Во-первых, воз­можность холодного перезапуска системы в случае отказа следовало полностью исключить. Лучшим выходом из ситуации признали немедленное (по меньшей мере, быстрое) переключение на резервный компонент. По мере проектирования этот принцип вырисовывался со все большей четкостью, и в конечном итоге по­явилась новая архитектурная структура — иерархия отказоустойчивости (рис. 6.9). Она описывает механизм обнаружения и устранения неисправностей, а также восстановления системы. В то время как схема «основное/резервные адресные пространства» отвечает за перехват ошибок и восстановление в рамках отдель­ного приложения, иерархия отказоустойчивости обеспечивает обнаружение и вос­становление после ошибок, явившихся результатом взаимодействия между при­ложениями

Иерархия отказоустойчивости в системе ISSS предусматривает несколько уровней обнаружения неисправностей и восстановления. Каждый из них в асинхронном режиме выполняет следующие действия:

♦ проводит обнаружение ошибок в себе, в одноранговых элементах и на нижележащих уровнях;

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

♦ проводит диагностические мероприятия, восстановление, составляет отчетность и порождает исключения.

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

♦ физический уровень (сеть, процессор и устройства ввода-вывода);

♦ уровень операционной системы;

♦ уровень исполняемой среды;

♦ прикладной уровень;

♦ уровень локальной готовности;

♦ уровень групповой готовности;

♦ уровень глобальной готовности;

♦ уровень системного мониторинга и управления.

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

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

о применении того или иного типа восстановления принимается диспетчером локальной готовности согласно таблицам решений в зависимости от текущего рабочего состояния:

♦ в случае переключения резервное адресное пространство почти без промедления принимает на себя обязанности бывшего основного адресного пространства;

♦ при теплом перезапуске задействуются контрольные точки (они сохраняются в энергонезависимой памяти);

♦ при холодном перезапуске теряется история состояний и применяются данные по умолчанию;

♦ для перехода на новую (или старую) логику или адаптационные данные проводится переключение (cutover).

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

В дополнение к тактикам реализации готовности, которые мы описали в представлении процессов, обнаружению сбоев служат ping/echo-пакеты и heartbeat- запросы; для оповещения элементов, ответственных за исправление ошибок, служат исключения (exceptions), а для проведения восстановления применяются резервы (spares).

Дата добавления: 2015-04-25