книги / Диагностические модели и методы повышения контролепригодности элементов и устройств распределенных информационно-управляющих систем на основе комбинирования логик

темы управления такого типа для традиционных информационных систем может служить (с некоторыми оговорками) продукт SPECTRUM компании Aprisma.

Следует отметить, что для управления распределенными системами в большинстве случаев используются системы элементарного управления, что впрямую связано с относительной простотой их развертывания и поддержки. Каждый производитель оборудования разрабатывает и поставляет вместе с ним программные средства управления и конфигурации. При этом для оборудования разного типа зачастую используются различные программные средства управления, например, для управляющих контроллеров – одни, для коммутационной аппаратуры – другие, для оборудования передачи данных – третьи и т.д. Также обычной является практика, когда отдельные компоненты систем управления задействуют для выполнения операций управления свои локальные ресурсы (коммуникационные протоколы, физические интерфейсы, аппаратные средства и системное программное обеспечение) и не имеют возможности интеграции на базе единой платформы управления, разработанной производителем оборудования [23].

Наряду с системами элементарного управления в последнее время получили распространение системы поддержки операций (Operations Support System – OSS). При создании интегрированной системы управления, построенной на оборудовании различных производителей, используется, как правило, некоторое количество систем элементарного управления (элемент-менеджеров). Системы элементарного управления объединяют между собой с помощью OSS. Это сложный, длительный и дорогостоящий процесс, поэтому в общем случае понятие «типовая OSS» не применимо к подавляющему большинству систем управления.

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

FCAPS (Fault, Configuration, Administration, Performance, Security [199]) для сис-

темы, построенной на оборудовании различных производителей. Как правило, автономные системы управления и мониторинга (АвСУМ) относятся к классу систем элементарного управления, а интегрированные системы управления и мониторинга (ИСУМ) или единые системы мониторинга и администрирования (ЕСМА) относятся к классу систем управления Enterprise-класса.

1.1.3. Основные универсальные требования к распределенным информационно-управляющим системам и их компонентам

Основные требования, выдвигаемые к системам управления:

простота и скорость внедрения и обновления программного обеспечения;

21

«дружелюбный» графический интерфейс пользователя и оператора;

оперативная локализация неисправностей и событий;

сбор, хранение и обработка данных о состоянии элементов сети в режиме реального времени;

возможность реконфигурации в режиме реального времени;

масштабируемость при расширении и усложнении структуры;

ведение журналов тревог и возможность генерации отчетов;

поддержка областей функционального управления (FCAPS);

реализация одного или нескольких уровней управления;

поддержка оборудования разных вендоров;

наличие блока адаптации для взаимодействия с сетевыми и управляющими элементами; возможность взаимодействия по нестандартным протоколам;

построение физической и виртуальной карт сети;

причинно-следственный анализ событий и неисправностей;

контроль производительности и загрузки каналов и трактов;

мониторинг сетевых сервисов;

контроль параметров системы для проверки качества услуг (QoS);

контроль выполнения регламентных работ по обслуживанию системы;

инвентаризация сетевых ресурсов;

анализ детальной информации о соединениях;

соблюдение требований политики безопасности.

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

1.2. Стандартизация процедур разработки и реализации элементов распределенных информационно-управляющих систем

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

иконтроля элементов и устройств РИУС

Кнастоящему моменту принято несколько стандартов в области разработки распределенных систем управления, которые базируются на модели взаимодействия открытых систем (стандарты ISO/OSI). Наиболее продвинутым и структурированным стандартом построения систем управления является серия стандартов

22

ITU-T Х.700, которые практически совпадают с соответствующими стандартами ISO и являются базовыми для создания информационного и коммуникационного обеспечения элементов и устройств подсистем РИУС.

Согласно Х.700, объектами стандартизации являются [191]:

сервисы и протоколы, используемые для передачи управляющей информации между открытыми системами;

абстрактный синтаксис и семантика информации, передаваемой управляющими протоколами.

Стандарт Х.700 определяет пять функциональных областей управления, известных также под аббревиатурой FCAPS:

Fault management – управление отказами (выявление отказов, их изоляция и восстановление работоспособности элементов и системы);

Configuration management – управление конфигурацией (установка параметров для нормального функционирования, запуск и остановка компонентов, сбор информации о текущем состоянии элементов и системы, прием извещений о существенных изменениях в условиях функционирования, изменение конфигурации элементов и системы);

Accounting management – управление учетом (учет и контроль использования системных ресурсов и определение их стоимости, оповещение пользователей о потребляемых ими ресурсах, тарификация, ведение счетов и установление лимитов на использование тех или иных ресурсов);

Performance management – управление производительностью (сбор и анализ статистической информации, определение производительности элементов

исистемы в штатных и нештатных условиях, изменение режима работы элементов и системы);

Security management – управление безопасностью (проведение в жизнь политики безопасности путем создания, удаления и изменения сервисов и механизмов безопасности, распространения соответствующей информации и реагирования на инциденты).

Следует заметить, что в современных промышленных РИУС, реализованных в базисе «полевых технологий» в связи с ограниченностью ресурсов и жесткими требованиями к вероятностно-временным характеристикам, большинство указанных выше подсистем вырождено [41].

Всоответствии с Х.700, возможности элементов и устройств системы управления должны:

позволять администраторам планировать, организовывать, контролировать и учитывать использование информационных сервисов;

давать возможность отвечать на изменение требований;

обеспечивать предсказуемое поведение информационных сервисов;

обеспечивать защиту информации.

23

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

Области управления, определенные в структуре управления OSI, описывают достаточно широкий круг задач управления. Каждая из этих задач выполняется с использованием функций системного управления (System Management Functions – SMFs). Следует отметить, что конкретные функции могут использоваться сразу в нескольких группах задач управления. Например, функция «отчет о событии» (event-report) может быть применима ко всем группам задач.

Определены следующие функции системного управления:

1.Управление объектом (Object Management). Обеспечивает создание и уничтожение управляемого объекта, чтение и изменение его атрибутов.

2.Управление состоянием (State Management). Определяет модель представления состояния управляемого объекта. Обеспечивает службы поддержки модели.

3.Управление связями (Relationship Management). Определяет модель для представления и управления взаимоотношениями между управляемыми объектами. Обеспечивает службы поддержки модели.

4.Отчет об авариях (Alarm Reporting). Определяет сигналы аварий и уведомления, используемые для отчета об авариях.

5.Управление отчетом о событиях (Event-report Management). Поддерживает контроль отчета о событиях, включая: спецификацию реципиентов отчетов, определение формы отчетов, спецификацию критериев для генерации и распространения отчетов.

6.Контроль журналов событий и учета (Log Control). Обеспечивает создание журналов, создание и хранение учетных записей, определение критериев для журнализации.

7.Отчет о сигналах безопасности (Security-alarm Reporting). Определяет сигналы тревоги, связанные с безопасностью и уведомления, используемые для отчетов о них.

8.Ведение аудита безопасности (Security-audit trail). Определяет типы отчетов о событиях, которыедолжны быть включены в журнал дляоценки безопасности.

9.Контроль доступа (Access Control). Поддерживает контроль доступа к информации управления и операциям управления.

10.Счетчик учета (Accounting Meter). Необходим для учета и установления ограничений использования ресурсов системы.

11.Мониторинг нагрузки (Workload Monitoring). Поддерживает мониторинг атрибутов управляемых объектов, которые относятся к представлению ресурса.

12.Управление тестированием (Test Management). Поддерживает управление тестовыми процедурами: конфиденциальными и диагностическими.

13.Накопление статистической информации (Summarization). Определяет параметры сбора статистики и отчетности о накопленной информации.

24

1.2.2. Архитектура систем управления распределенными объектами

Согласно рекомендации Х.701, системы управления распределенными ИС строятся в архитектуре менеджер/агент, где менеджер выдает агенту команды на управляющие воздействия и получает извещения, а агент (как программная модель управляемого объекта) выполняет управляющие действия и порождает (при возникновении определенных событий) извещения от его имени (рис. 1.5).

Рис. 1.2. Модель взаимодействия агент-менеджер

Агент является посредником между управляемым ресурсом (сетевым элементом – Network Element, NE) и основной управляющей программойменеджером. Чтобы один и тот же менеджер мог управлять различными реальными ресурсами, создается некоторая модель управляемого ресурса, которая отражает только те характеристики ресурса, которые нужны для его контроля и управления. Таким образом, основой любой системы сетевого управления является база данных, содержащая информацию о ресурсах и элементах сети, которыми нужно управлять. В системе управления OSI эта база называется MIB (Management Information Base). Основная структура, в соответствии с которой проектируется и описывается MIB, называется структурой информации управления (Structure Management Information, SMI). SMI определяет типы данных, которые могут использоваться в MIB, описание ресурсов и их обозначение (именование) в базе. Ресурс может быть описан как управляемый объект (Managed Object – MO).

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

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

25

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

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

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

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

Агенты могут отличаться уровнем интеллекта – они могут обладать как минимальным интеллектом, необходимым для выполнения простейших команд, так

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

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

инаоборот. Данная иерархия может иметь несколько уровней, элементы которых при нахождении на промежуточном уровне, по отношению к вышестоящим элементам являются агентами, а для нижестоящих – менеджерами. Логически связанной с такой многоуровневой архитектурой является концепция доверенного (или делегированного) управления, согласно которой менеджер промежуточного уровня может управлять объектами, использующими собственные протоколы, в то время как менеджер верхнего уровня опирается исключительно на стандартные средства. Многоуровневая архитектура менеджер/агент является основным ключом к распределенному, масштабируемому управлению большими системами

(рис. 1.6).

Внастоящее время на практике применяются несколько стандартов управления распределенными системами на уровне подсистемы сбора, передачи и распределения информации РИУС – стандарты Internet, построенные на базе протокола SNMP, концепция TMN и стандарты управления распределенными вычислительными сетями на базе технологий CORBA, Java и веб-технологий.

26

Система управлениясетью

Менеджер

Рис. 1.6. Иерархические связи между менеджерами

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

1.2.3. Анализ архитектуры и возможности планирования современных систем управления и мониторинга элементов и устройств РИУС

Современное состояние РИУС таково, что в большинстве случаев эксплуатируется оборудование различных отечественных и зарубежных фирм-изготови- телей. Наиболее часто управление оборудованием реализуется самим производителем (вендором) в виде консольных приложений («крафт-терминалов») или оригинальных («фирменных») систем управления отдельно для каждого типа оборудования. Протоколы управления в большинстве случаев являются также оригинальными разработками фирм-изготовителей и выполняются либо не по стандартам, либо с некоторыми отклонениями от стандартов, несмотря на заявленную поддержку стандартных протоколов. В результате оператору приходится управлять имеющимся у него оборудованием при помощи нескольких систем управления, каждая из которых управляет и контролирует ограниченную номенклатуру оборудования. Взаимодействие систем управления разных производителей невозможно из-за разницы в используемых протоколах и информационных моделях. Таким образом, отсутствие единого управления ресурсами РИУС сильно влияет на качество функционирования системы в целом.

Выходом из сложившейся ситуации может стать создание единой системы мониторинга и администрирования (ЕСМА) мультивендорного оборудования.

27

Наиболее оптимальной архитектурой ЕСМА является архитектура иерархической интегрированной распределённой системы управления, состоящей из отдельных систем управления, объединённых с помощью какой-либо управляющей платформы на основе одной из технологий TMN, CORBA, Java RMI, DCOM. На уровне управления элементами используется система управления производителя, которая обеспечивает полнофункциональное управление. Управление системой в целом производится на уровне управления сетью и услугами, которые предоставляет система управления производителя. Это позволяет скрыть от системы управления сетью верхнего уровня специфику оборудования производителя, которая учитывается в системе управления производителя, без снижения функциональности и эффективности управления в целом. При этом требуется модификация систем управления производителя – необходимо обеспечить предоставление интерфейса взаимодействия менеджера с системой верхнего уровня. Не требуется модификация аппаратно-программных средств оборудования (агентов). Имеется механизм построения иерархии систем управления.

В основе архитектуры ЕСМА для организации иерархии управления используется модель взаимодействия агент-менеджер. Непосредственная реализация ЕСМА предполагает использование двухуровневой иерархии управления. Первый уровень (уровень СУМ-Пр) выполняет функции по управлению элементами и функции сетевого управления. Реализация этих функций обеспечивается СУМ-Пр на отдельных участках сети, ограниченность и автономность которых определяются установленными оборудованием и СУМ-Пр одного производителя. Второй уровень выполняет все функции уровня управления сетью и часть функций уровня предоставления услуг.

Для построения ЕСМА необходимо обеспечить:

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

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

В составе ЕСМА можно выделить следующие компоненты (рис. 1.7):

система управления и мониторинга (СУМ) – элемент ЕСМА второго уровня, выполняющий функции управления сетью и управления услугами;

транспортная магистраль, обеспечивающая взаимодействие и передачу информации между отдельными элементами системы;

адаптированная система управления производителя – система управления и мониторинга, лежащая в основе иерархии управления, протоколы и информационная модель которой унифицированы с СУМ верхнего уровня иерархии;

агент-шлюз, обеспечивающий согласование информационной модели ЕСМА с внутренним представлением информации в СУМ-Пр.

28

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

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

ит.п.). В каждом из указанных видов функции элементов могут быть реализованы:

программно (как функции в прикладном или системном программном обеспечении, например, служба агента SNMP в операционной системе Microsoft Windows);

как встроенные на аппаратно-программном уровне (специализированные модули в аппаратуре, например, сетевые платы в компьютере);

как выделенные на аппаратно-программном уровне (выделенные модули в составе устройства или плат блока; специальные платы контроля и сигнализации (управления и мониторинга) в составе оборудования; отдельные блоки (устройство сервисного обслуживания – УСО); программируемые логические контролеры (ПЛК) в составе подсистем систем автоматизации и управления и т.д.).

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

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

Рассмотрим основные задачи физических элементов системы управления для каждого уровня иерархии:

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

– агент/медиатор (в специализированной плате контроля и сигнализации): сбор, обработка, формирование и хранение диагностической информации по всем платам контролируемого блока, а также поддержка коммуникационных протоколов взаимодействия с соответствующим медиатором системы управления;

30