МЕТОДЫ ДИАГНОСТИКИ КОМПОНЕНТОВ ИНФОРМАЦИОННО-ТЕЛЕКОММУНИКАЦИОННЫХ СИСТЕМ
←
→
Транскрипция содержимого страницы
Если ваш браузер не отображает страницу правильно, пожалуйста, читайте содержимое страницы ниже
УДК 681.518.3
МЕТОДЫ ДИАГНОСТИКИ КОМПОНЕНТОВ ИНФОРМАЦИОННО-
ТЕЛЕКОММУНИКАЦИОННЫХ СИСТЕМ
С.Ф. Теленик, А.И. Ролик, Ю.С. Тимофеева
Национальный технический университет Украины
«Киевский политехнический институт»,
Киев, пр. Перемоги, 37, НТУУ «КПИ», корп. 18, к. 528, rolick@auts.ntu-kpi.kiev.ua
Введение
В настоящее время практически все предприятия и организации используют
информационно-телекоммуникационные системы (ИТС) для повышения эффек-
тивности бизнес-процессов или процессов деятельности. ИТС предоставляет инст-
рументы для оптимизации затрат, принятия эффективных решений, минимизации
бизнес-рисков и пр. Поэтому неэффективная работа или простой ИТС немедленно
отражается на ходе бизнеса. В современных ИТС используется большое количест-
во дорогостоящих информационных и коммуникационных технологий. Вложение
дополнительных средств в ИТ-инфраструктуру для очередного повышения эффек-
тивности бизнеса часто оказывается неоправданным по причине увеличения экс-
плуатационных расходов. Очевидным способом улучшения отдачи от ИТС являет-
ся использование централизованных систем управления ИТС (СУИ) [1]. Одна из
основных задач СУИ заключается в диагностике состояния компонентов ИТС для
последующего автоматизированного или автоматического устранения неисправно-
стей. Поэтому данная статья посвящена определению методов диагностики, при-
менение которых наиболее целесообразно в перспективных СУИ, разработке схе-
мы кодирования состояния объектов управления и совершенствованию методов
поиска неисправностей в ИТС.
Постановка проблемы
Основная задача ИТС — повышение эффективности выполнения бизнес-
процессов. Простой или неэффективная работа ИТС, не говоря уже о неработоспо-
собности функциональных или технологических подсистем, немедленно отражает-
ся на ходе бизнеса. Поэтому перспективные СУИ должны делать упор на автома-
тическое или хотя бы автоматизированное управление всеми компонентами ИТС.
Для этого необходимо выполнять всеобъемлющий мониторинг состояния компо-
нентов, оперативный анализ их текущего состояния и определение тенденций по-
следующего поведения как компонентов, так и подсистем ИТС, а также осуществ-
лять эффективное управление компонентами ИТС, функциональными и техноло-
гическими подсистемами, распределенными приложениями и пр. для поддержания
качества работы ИТС на заданном уровне.
Основная сложность при создании и внедрении СУИ обусловлена множеством
и разнообразием взаимосвязанных решаемых задач, необходимостью эффективно-
го управления ИТ-процессами и функционированием предприятия в условиях ди-
намики доступности и производительности информационных и вычислительных
ресурсов, изменяющихся свойств телекоммуникационной сети и пр.
Одной из основных составляющих СУИ является подсистема управления уст-
ранением неисправностей (ПУН), важнейшие задачи которой — диагностирование
состояния компонентов ИТС, выявление неисправностей и управление их устране-
нием. Для диагностирования компонентов ИТС необходимо иметь набор инстру-
ментария, осуществляющего мониторинг, и информацию о связях и взаимном
влиянии компонентов ИТС для определения их состояния. При проведении диаг-
ностики всевозможные компоненты ИТС выступают для СУИ в качестве объектов
мониторинга, анализа и управления (ОМУ).
Быстрая и эффективная диагностика компонентов ИТС позволяет своевремен-
но устранять неисправности и минимизировать экономические потери.Анализ публикаций
Диагностика компонентов ИТС осуществляется посредством проведения мони-
торинга. Обзор и анализ методов мониторинга ИТС произведен в [2]. Анализу со-
стояния компонентов ИТС посвящена статья [3], однако при этом не рассматрива-
ются вопросы кодирования состояний. В работе [4] рассматривается использование
активного тестирования для обнаружения неисправностей в сети в реальном мас-
штабе времени, а также алгоритмы и критерии выбора тестовых последовательно-
стей. Данные алгоритмы используют информацию о взаимосвязях между компо-
нентами коммуникационной сети, однако отсутствует описание методов получения
этой информации.
В [5] разработаны алгоритмы представления знаний об ИТС, к которым отно-
сится информация о взаимосвязи элементов системы между собой, а также элемен-
тов и сервисов, предоставляемых системой. Рассматривается переход от деревьев
решений, которые используются для определения последовательности провероч-
ных тестов, к матрицам зависимостей, являющихся удобными для представления
результатов тестов и состояния компонентов.
В работе [6] предлагается использовать для диагностики неисправностей в
больших системах деревья решений. В этом случае осуществляется большое коли-
чество тестовых проверок, что требует обработки значительных объемов текущей
информации. Это повышает точность диагностики, однако увеличивает время ее
проведения. В [7] рассматривается система диагностики, которая использует аген-
ты мониторинга и выполняет заранее установленный набор тестовых последова-
тельностей для определенных компонентов и подсистем.
В работе [8] используют адаптированное тестирование, т.е. при выборе тесто-
вых последовательностей учитываются результаты предыдущих. В данном случае
система диагностики является децентрализованной, рассматриваются алгоритмы
выбора тестовых последовательностей и станций, которые их отсылают. Данный
метод способствует быстрому обнаружению неисправностей, однако не диагности-
рует сбои и аномальное функционирование компонентов системы.
В [9] предлагается система диагностики неисправностей, осуществляющая сле-
дующие этапы: выявление неисправностей, составление отчетов о неисправностях,
предварительную диагностику, выбор диагностических тестов и их выполнение,
анализ и сохранение результатов. Однако данная система используется для диагно-
стики компонентов простой телекоммуникационной сети и подразумевает наличие
полной информации о взаимосвязях всех элементов, а также обо всех возможных
неисправностях в сети. Для представления этих зависимостей используются прави-
ла проверки и очереди в рамках применяемого языка правил DROOL.
Целью статьи является совершенствование методов диагностики компонентов
ИТС.
Методы мониторинга компонентов ИТС
СУИ должна обеспечивать эффективное функционирование ИТС, мониторинг
и анализ состояния ее аппаратных и программных компонентов, эффективное пе-
рераспределение ресурсов в случае возникновения неисправностей, диагностиро-
вание, локализацию и быстрое устранение неполадок.
Одним из модулей СУИ является подсистема управления устранением неис-
правностей, осуществляющая диагностирование состояния компонентов ИТС и
выявление неисправностей.
В ПУН могут использоваться следующие методы и средства получения инфор-
мации о состоянии ОМУ:
— методы опроса ОМУ с использованием стандартных коммуникационных
протоколов управления, таких как SNMP, CMIP, ICMP и др. или специализиро-
ванного программного обеспечения (ПО);
— косвенные методы диагностики, позволяющие делать выводы о работоспо-
собности ОМУ на основе анализа функционирования ОМУ, взаимосвязанных с
анализируемыми;— использование встроенных специализированных или универсальных средств
самодиагностики аппаратного и программного обеспечения ОМУ;
— применение агентских технологий и др.
Получение достоверной информации о состоянии ОМУ в сложных, содержа-
щих большое количество компонентов ИТС путем непрерывного или с малым пе-
риодом времени опроса сопряжено с существенным увеличением нагрузки на теле-
коммуникационную сеть. Этого недостатка лишен агентский подход, когда для ди-
агностики состояния и дистанционного или локального управления ОМУ исполь-
зуются агентские технологии [10, 11].
Программные агенты могут самостоятельно решать задачи, поставленные пе-
ред ними СУИ. Одной из таких задач является контроль функционирования аппа-
ратно-программного обеспечения телекоммуникационных узлов и серверов при-
ложений с возможностью, например, самостоятельного принятия решения и осу-
ществления перезагрузки или реализации других мероприятий для восстановления
эффективной работы серверов. Автоматизация таких процессов позволяет сущест-
венно сократить расходы на эксплуатацию ИТС.
Преимуществами агентской технологии являются:
— уменьшение загруженности телекоммуникационной сети за счет сокращения
служебного трафика;
— возможность автономного выполнения задач;
— возможность конкурентного выполнения заданий в многоагентской среде;
— параллельное выполнение заданий группой агентов сокращает время на ре-
шение общей задачи;
— миграция агентов вместе с решаемыми ими задачами позволяет выровнять
использование вычислительных ресурсов и снизить вероятность перегрузки от-
дельных узлов;
— использование мобильных агентов позволяет освободить администраторов
от операций инсталляции, запуска и завершения использования программных ком-
понентов.
К недостаткам агентской технологии следует отнести высокую сложность реа-
лизации, необходимость установки специального агентского ПО на разнообразные,
сильно отличающиеся аппаратно-программные средства ИТ-инфраструктуры, су-
щественную неопределенность в работе, проблематичность использования в ИТС с
системой комплексной защиты информации.
Поэтому в СУИ необходимо использовать комбинацию различных методов
проведения мониторинга и управления.
Классификация ОМУ
Все компоненты ИТС, для которых можно применять методы автоматического
мониторинга, оценки состояния и управления, рассматриваются СУИ как ОМУ.
Все ОМУ могут быть сгруппированы по принадлежности к отдельному компо-
ненту ИТС, объединены по функциональным признакам и разделены на уровни по
иерархическому принципу. При этом количество уровней и принципов объедине-
ния может быть множество. Например, уровень программно-технических комплек-
сов (ПТК) или обеспечивающих подсистем может быть введен или нет. Это опре-
деляется спецификой ИТС и ее характерными признаками, позволяющими четко
выделять отдельные элементы и функциональные совокупности.
В качестве ОМУ выступают функциональные и обеспечивающие подсистемы
ИТС, ПТК, автоматизированные рабочие места, серверы, рабочие станции, пери-
ферийное и вспомогательное оборудование, активное оборудование телекоммуни-
кационной сети, аппаратные и программные компоненты информационной систе-
мы и пр.
Каждый ОМУ описывается совокупностью параметров или атрибутов, а его со-
стояние определяется значениями отдельных параметров. При этом ОМУ могут
включать или не включать в себя другие ОМУ. ОМУ самого нижнего уровня ие-
рархии описывается атрибутами и параметрами, значения которых измеряются илианализируются ПУН для определения состояния ОМУ или оценки качества его
функционирования.
ОМУ могут включаться в несколько различных ОМУ верхних уровней иерар-
хии. Например, ОМУ «Сервер СЕДО» может входить в ОМУ «СЕРВЕРЫ», в ОМУ
«ПТК СЕДО» и, опосредовано, в ОМУ «Обеспечивающие подсистемы» (СЕДО —
система единого документооборота).
При необходимости, для анализа состояния ОМУ в нем могут быть выделены
новые ОМУ или введены для рассмотрения новые параметры. Например, в ОМУ
«Аппаратные средства сервера СЕДО» может быть добавлен ОМУ «ОЗУ сервера
СЕДО» или введен параметр «Средняя загрузка ОЗУ сервера СЕДО», значения ко-
торого будут учитываться при анализе состояния ОМУ «Аппаратные средства сер-
вера СЕДО» и ОМУ следующего уровня иерархии — «Сервер СЕДО».
Для определения состояния ОМУ, функциональных и технологических подсис-
тем и пр., оценки качества функционирования и управления ОМУ серверы СУИ
взаимодействуют с техническими средствами ИТС.
От технических и программных средств ИТС серверы СУИ получают значения
параметров ОМУ, обрабатывают эту информацию, выносят решение о состоянии
ОМУ, определяют необходимые управляющие воздействия для поддержания
функционирования как отдельных ОМУ, так и ИТС в целом в соответствии с за-
данным регламентом, и реализуют управляющее воздействие автоматическим или
автоматизированным способом. Обобщенная информация о функционировании
ИТС поступает администратору СУИ, который наблюдает за функционированием
ИТС и принимает решения по автоматизированному или ручному управлению
ОМУ.
Для определения состояния ОМУ j-го иерархического уровня деления ИТС,
j 1, ..., J , J — число иерархических уровней, на которые делятся ОМУ ИТС, СУИ
необходимо получить информацию о значениях параметров данного ОМУ, а также
обобщенную информацию о каждом из ОМУ (j–1)-го иерархического уровня, вхо-
дящих в состав рассматриваемого ОМУ j-го уровня.
ОМУ ИТС условно можно классифицировать по следующим признакам:
— по месту в иерархии компонентов ИТС;
— по характеру выполняемых операций для определения состояния ОМУ.
ОМУ, в соответствии с иерархией компонентов ИТС, можно разделить на:
— бизнес-процессы или процессы деятельности;
— операции бизнес-процессов;
— функциональные и технологические подсистемы;
— ПТК, комплексы средств автоматизации (КСА) и пр.;
— АРМ, хранилища данных и пр.;
— аппаратное и программное обеспечение ИТС, сервисы, службы и пр.;
— устройства ИТС (серверы, рабочие станции, активное коммуникационное
оборудование и пр.);
— элементы серверов, рабочих станций и коммуникационного оборудования.
По характеру выполняемых операций для определения состояния ОМУ их
можно разделить на ОМУ, для определения состояния которых требуется выпол-
нение операций:
— сбора и обработки данных;
— сбора, обработки и анализа информации;
— только анализа информации.
На самом нижнем уровне иерархического деления ИТС находятся ОМУ, кото-
рые не включают в себя другие ОМУ. Состояние этих ОМУ определяется только
значениями их параметров.
Для определения состояний ОМУ самого нижнего уровня СУИ выполняет опе-
рации сбора и обработки данных. Для этого ПУН или агенты ПУН должны посто-
янно получать непосредственно от ОМУ значения параметров и после их обработ-
ки определять состояние ОМУ. К ОМУ нижнего уровня относятся элементы уст-
ройств ИТС, например, ОЗУ, процессоры, порты и пр., а также компоненты ПО.На вышерасположенных уровнях для определения состояния ОМУ наряду с
операциями сбора и обработки данных о значениях параметров, характеризующих
состояние и функционирование ОМУ, присутствуют и операции анализа, когда для
определения состояния ОМУ СУИ осуществляет анализ обработанных значений
параметров ОМУ в совокупности с анализом состояний входящих в него ОМУ. К
таким ОМУ относятся серверы, рабочие станции, активное сетевое оборудование,
специализированное ПО и пр.
На верхних уровнях в состав ОМУ входят только другие ОМУ и для определе-
ния состояния ОМУ в СУИ осуществляется только анализ информации о состоя-
нии ОМУ, входящих в состав рассматриваемого ОМУ. К ОМУ такого типа отно-
сятся функциональные и обеспечивающие подсистемы, ПТК и пр.
Кодирование состояний ОМУ
Для определения качества функционирования ИТС можно ограничиться только
анализом результатов тестовых проверок компонентов информационной и теле-
коммуникационной составляющих инфраструктуры. В этом случае все компоненты
ИТС самотестируются и сообщают в СУИ результаты тестов. Сравнение в СУИ ре-
зультатов выполнения тестовых заданий с эталонными значениями позволяет не
только оценить качество работы компонентов ИТС, но и определить функциони-
руют ли они в принципе. Такой подход, благодаря своей универсальности, имеет
неоспоримое преимущество, заключающееся в возможности унификации анализа
функционирования самых разнообразных сильно различающихся приложений,
реализованных на разных платформах, написанных на разных языках программи-
рования. При этом разработчики ПО могут встраивать механизм самотестирования
в приложение, не раскрывая деталей работы приложения.
Однако, такой подход затрудняет для ПУН локализацию неисправностей и оп-
ределение причин их появления, усложняет прогнозирование поведения ОМУ и
определение СУИ управляющих воздействий, а также обладает и другими серьез-
ными недостатками. Поэтому определение качества функционирования ОМУ по
результатам тестовых проверок, несмотря на явные преимущества такого подхода,
не может быть единственным, используемым в СУИ. Необходимо применять ком-
плекс различных подходов и методов для мониторинга и анализа множества пара-
метров функционирования ОМУ, определения и анализа их состояния с целью бы-
строй локализации неисправностей, проактивного управления устранением про-
блем и эффективного управления ИТС.
Для эффективной работы ПУН требуется единая форма представления состоя-
ний разнообразных сильно отличающихся ОМУ. Для этого может быть использо-
вана предлагаемая универсальная схема кодирования состояний, базирующаяся на
следующих положениях:
— ОМУ — это все аппаратные и программные элементы и компоненты ИТС,
включая сетевые устройства, серверы, хранилища, ПО, выполняемые ИТС функ-
ции, службы, функциональные и обеспечивающие подсистемы ИТС, ПТК, АРМ и
пр.;
— состояние всех ОМУ должно быть измеряемым;
— состояние всех ОМУ характеризуется универсальными показателями произ-
водительности, надежности, устойчивости и др.
Состояние S i , j i-го ОМУ j-го иерархического уровня, j 1,..., J , i 1,..., I j , I j —
количество ОМУ на j-м иерархическом уровне, определяется через функционал Ф1
Si , j Ф1 s1,i , j , s2 ,i , j ,...,s M ,i , j , (1)
где sm ,i , j , m 1,...,M — показатель, характеризующий отдельное m-е, в общем
случае, комплексное свойство i-го ОМУ, например, производительность, надеж-
ность и пр., M — количество свойств, рассматриваемых для оценки состояния
ОМУ в ПУН.Для связи показателей отдельных свойств i-го ОМУ с наиболее существенными
параметрами, влияющими на m-е свойство sm ,i , j , введем функционал Ф2 ,m для всех
m 1, ..., M
s m ,i , j Ф2 ,m Em ,i ,( j 1) , Pm ,i , j , (2)
где Em ,i ,( j 1) s m ,i ,( j 1) — множество показателей m-го свойства ОМУ (j-1)-го
уровня, оказывающих влияние на свойство sm ,i , j , Pm ,i , j — множество оригинальных
параметров i-го ОМУ, оказывающих влияние на m-е свойство sm ,i , j i-го ОМУ j-го
уровня.
Для получения возможности измерения состояния ОМУ функционал Ф1 опре-
деления состояния i-го ОМУ независимо от иерархического уровня предлагается
задавать следующим образом.
Каждый показатель sm ,i , j , m 1,...,M приводится к численному виду и преобра-
зовывается таким образом, чтобы максимальному значению max sm ,i , j соответство-
вал максимальный положительный вклад в определение состояния S i , j i-го ОМУ
j-го уровня, и нормируется относительно max sm ,i , j . При этом значения sm ,i , j ,
m 1, ...,M будут лежать в открытом интервале от 0 до 1, т. е.
0 sm ,i , j 1, (3)
для всех m 1, ..., M , i 1, ..., I j , j 1, ..., J .
Интервал изменения sm ,i , j , m 1, ...,M разбивается на N m ,i , j непересекающихся
диапазонов d m( n,i ,)j , nm 1, ..., N m.i . j с использованием Lm ,i , j ( N m ,i , j 1) пороговых зна-
m
чений Pm(l,i ,)j , l m 1, ..., Lm.i . j . Нумерация диапазонов начинается от максимального
m
значения max sm ,i , j , равного 1.
Принадлежность значения sm ,i , j к диапазону d m( n,i ,)j определяется следующим об- m
разом
s m ,i , j d m( n,i ,)j ,
m
(4)
если выполняется условие
1 1
( Lm ,i , j 1 d m( n,i ,)j )
m
s m ,i , j ( Lm ,i , j 2 d m( n,i ,)j ) ,
m
(5)
( Lm ,i , j 1) ( Lm ,i , j 1)
( N m ,i , j )
Состояние sm ,i , j кодируется символом Ab таким образом, что значение nm
bn , nm 1, ..., N m.i . j соответствует номеру диапазона d m( n,i ,)j , в котором находится зна-
m
m
чение sm ,i , j .
Символ Ab( N ) принадлежит алфавиту A Ab( N ) , nm 1, ..., N m ,i , j , m 1, ..., M .
nm
m ,i , j
nm
m ,i , j
Кодовая комбинация для обозначения состояния S i , j i-го ОМУ, i 1, ..., I j j-го
иерархического уровня, j 1, ..., J , будет выглядеть следующим образом
( N1 ,i , j ) ( N 2 ,i , j ) ( N M ,i , j )
Ab Ab Ab , (6)
n1 n2 nM
Пример кодирования состояния ОМУ для трех- ( L1,i , j 3) и одно- ( L2 ,i , j 1) по-
рогового ранжирования состояний, а также для одно- (m 1) и двух- (m 2) пара-
метрического определения состояния приведен в таблице.Таблица — Пример кодирования состояния ОМУ
Код состоя- Код состояния Показатель Показатель
ния i-го ОМУ i-го ОМУ при производительности надежности
при m=1 m=2 i-го элемента i-го элемента
( 4)
A1( 4) A1( 2) P1(,i3, j) s1,i , j 1 P2(,1i ), j s 2 ,i , j 1
A 1 ( 4) ( 2) (3 ) (1)
A 1 A 2 P 1,i , j s1,i , j 1 0 s 2 ,i , j P 2 ,i , j
( 4) ( 2) ( 2) ( 3) (1)
A 2 A 1 P 1,i , j s1,i , j P 1,i , j P 2 ,i , j s 2 ,i , j 1
A2( 4) ( 4) ( 2) ( 2) ( 3) (1)
A 2 A 2 P 1,i , j s1,i , j P 1,i , j 0 s 2 ,i , j P 2 ,i , j
( 4) ( 2) (1) ( 2) (1)
A 3 A 1 P 1,i , j s1,i , j P 1,i , j P 2 ,i , j s 2 ,i , j 1
A3( 4 ) ( 4) ( 2) (1) ( 2) (1)
A 3 A 2 P 1,i , j s1,i , j P 1,i , j 0 s 2 ,i , j P 2 ,i , j
( 4) ( 2) (1) (1)
A 4 A 1 0 s1,i , j P
1,i , j P 2 ,i , j s 2 ,i , j 1
A4( 4) ( 4) ( 2) (1) (1)
A 4 A 2 0 s1,i , j P
1,i , j 0 s 2 ,i , j P 2 ,i , j
Если показатели надежности в принципе не рассматриваются в ИТС, то со-
стояние элемента характеризуется только одним символом алфавита
(N )
A Ab1 , n1 1,..., N1,i , j .
1 ,i , j
В таблице P1(,il, j) и P2(,li , j) , l1 1, 2 ,3 , l 2 1 — пороговые значения для показателей
1 12
производительности и надежности i-го ОМУ, соответственно. Причем Pm(l,i ,)j ≥ Pm(l,i , j1) . m m
Значения порогов устанавливаются администраторами СУИ и могут меняться в
процессе работы. По умолчанию значения Pm(l,i ,)j порогов в СУИ с учетом нормиро- m
вания (3) устанавливаются на уровне:
1
Pm(l,i ,)j
m
1 lm , (7)
( Lm ,i , j 1)
для всех l m 1, ..., Lm.i . j .
Значение производительности s1,i , j — нормированное значение производитель-
ности относительно эталонной производительности ei3, j i-го ОМУ j-го уровня.
Возможно несколько вариантов определения эталонной производительности в
реальной среде эксплуатации ОМУ.
В первом случае эталонная производительность ei3, j i-го ОМУ определяется по
результатам выполнения ряда тестовых заданий после установки операционной
системы, инсталляции ПО и оптимизационной настройки вычислительной систе-
мы. Вычисляется среднее значение, которое и становится эталонным для этого
ОМУ.
Во втором — для определения эталонной производительности i-го ОМУ СУИ в
течение достаточно длительного времени, которое может измеряться неделями, со-
бирает статистику о работе этого ОМУ, обрабатывает ее и выводит значение, уста-
навливаемое в качестве эталонного. В дальнейшем все отклонения от эталонного
состояния фиксируются СУИ. Причем, при отклонении текущего значения от эта-
лонного сигнал о возникновении проблем в ИТС вырабатывается не сразу, а после
анализа дополнительных признаков. Такими дополнительными признаками могут
быть, например, загруженность каналов связи или увеличение количества пользо-
вателей, обращающихся к серверу СЕДО. В этом случае увеличение времени полу-
чения ответа от сервера СЕДО является нормальным явлением и не требует прове-
дения мероприятий по восстановлению качества функционирования ИТС.
В третьем — i-й ОМУ периодически самостоятельно запускает тестовые зада-
ния, накапливает статистику и следит за отклонениями, о чем информирует СУИ.
Накопленные показания статистики могут сбрасываться администратором СУИпри изменении условий функционирования ИТС, например, при увеличении коли-
чества пользователей, внедрении дополнительных информационных технологий,
модернизации телекоммуникационной сети и пр.
Диагностика компонентов ИТС с помощью тестовых проверок
Для диагностики компонентов ИТС в ПУН используются тестовые проверки.
Проверка представляет собой некий запрос на проведение тестовых операций, по-
сылаемый ПУН компоненту ИТС с целью выявления ухудшения эффективности
функционирования или обнаружения неисправности. Проверки могут тестировать
как аппаратные, так и программные компоненты.
Когда необходимо определить сам факт наличия неисправности подсистемы
или системы, то сначала проводится тестирование наибольшей группы компонен-
тов, а затем может быть проведено выявление причины неисправности с помощью
алгоритмов локализации неисправностей [2].
Диагностика компонентов ИТС может осуществляться и с помощью тестовых
проверок, выбираемых на основе результатов пассивного мониторинга.
Модуль диагностики в составе ПУН в своей работе использует данные подсис-
темы мониторинга. Они представляют собой информацию о значениях параметров
и состоянии ОМУ, которая поступает от агентов мониторинга и сохраняется в базе
данных мониторинга. На основании анализа этих данных производится выбор
множества компонентов ИТС, работоспособность и эффективность функциониро-
вания которых необходимо проверить, затем осуществляется отбор предназначен-
ных для этой цели тестовых проверок.
В базе данных конфигурации хранится информация о симптомах неисправно-
стей, которые могут наблюдаться в ИТС, о возможных тестовых проверках и о
взаимосвязи между проверками и симптомами неисправностей, которые они про-
веряют. Данная информация определяется отдельно для каждого выделенного
класса подсистем, как это описано в [2] и представляется в следующем виде:
— упорядоченное множество симптомов Cn , т. е. различных признаков, свиде-
тельствующих о наличии неисправностей в n-м классе, C n cn , j , j 1, ..., J n , J n —
количество симптомов для n-го класса;
— упорядоченное множество неисправностей Fn , порождающих симптомы Cn ,
Fn f n ,i , i 1, ..., I n , I n — количество возможных неисправностей для n-го класса;
— упорядоченное множество активных проверок An , которые могут опроверг-
нуть или подтвердить наличие симптомов множества Cn , An an ,k , k 1,..., K n ,
K n — количество возможных проверок для объектов n-го класса;
— матрица размерностью I n J n неисправность-симптом Qn qn ,ij cn , j | f n ,i ,
элемент qn ,ij cn , j | f n ,i которой принимает значения:
1, если j - тый симптом возникает
q n ,ij cn , j | f n ,i при наличии i - той неисправно сти; , (8)
0, в противном случае.
— матрица размерностью K n J n симптом-проверка Vn vn ,kj cn , j | an ,k элемент
которой равен нулю vn ,kj cn , j | an ,k 0 , в случае, если k-я проверка не способна обна-
ружить j-й симптом. В противном случае vn ,kj cn , j | an ,k определяет затраты (времен-
ные или ресурсные) на проведение k-ой проверки для обнаружения j-го симптома в
n-м классе.
Максимальное количество проверок для каждого класса может достигать коли-
чества симптомов, то есть K n J n . Однако в общем случае одна и та же проверка
может обнаружить несколько симптомов, а наличие одного симптома может бытьподтверждено несколькими проверками. Например, проверка, запускающая вы-
полнение определенных операций для тестирования программных компонентов на
конкретном узле с целью проверки его функционирования, также способна обна-
ружить симптомы, свидетельствующие о неисправности элементов телекоммуни-
кационной сети на пути к данному узлу.
Введѐм следующие множества:
— множество симптомов Cn ,k cn ,k ,l , l 1, ...,Ln ,k , которые может обнаружить
проверка an ,k , Ln ,k — количество этих симптомов;
— множество неисправностей Fn , j f n , j ,g , g 1, ..., Gn , j , которые могут обусло-
вить появление симптома cn , j , Gn , j — количество этих симптомов.
Таким образом, результат каждой m-той проверки из M осуществляемых будет
представлять собой вектор Rm rm ,l , l 1,..., Lm , элемент которого rm,l принимает
следующие значения:
1, если m - я проверка обнаружила
наличие l - го симптома;
rm ,l 0, если m - я проверка не обнаружила (9)
наличие l - го симптома;
- 1, если результат проверки не был получен.
Отсутствие данных о результате проверки может свидетельствовать о времен-
ном сбое или ухудшении эффективности функционирования компонентов, участ-
вующих в осуществлении проверки, например, узлов телекоммуникационной сети,
находящихся на пути передачи запроса о проведении проверки от ПУН до опреде-
ленного компонента ИТС при условии отсутствия альтернативного пути.
Выбор каждой последующей проверки учитывает результаты предыдущей, что
осуществляется следующим образом.
В случае, когда rm ,l 1 , запускаются проверки, способные обнаружить осталь-
ные симптомы неисправностей Fn ,l , которые обусловливают появление симптома
cn ,m,l . В результате данных действий производится обнаружение неисправных ком-
понентов.
Если rm ,l 0 , то продолжается осуществление проверок для обнаружения новых
симптомов неисправностей компонентов ИТС, которые были выбраны в соответст-
вии с результатами мониторинга. Проверки выбираются из множеств An в зависи-
мости от того, к какому классу принадлежит проверяемый компонент, какие виды
неисправностей могут быть у него обнаружены и каковы симптомы данных неис-
правностей.
В случае, когда rm ,l 1 , производится повторная проверка с целью определить,
было ли неполучение результатов предыдущей проверки вызвано сбоем, времен-
ным снижением эффективности функционирования или неисправностью компо-
нентов ИТС. В последнем случае производится дополнительная диагностика дан-
ных компонентов.
В итоге проверяются все компоненты, выбранные на основании результатов
работы ПУН, определяется эффективность их работы и наличие или отсутствие не-
исправностей.
Предложенные методы диагностики реализованы в созданной в НТУУ «КПИ»
системе управления функционированием ИТС SmartBase ITSControl.
Выводы. В работе рассмотрены вопросы повышения эффективности устране-
ния неисправностей ИТС. Произведены обзор и анализ существующих методов ди-
агностики компонентов информационно-телекоммуникационных систем.
Предложенная классификация компонентов ИТС и схема кодирования их со-
стояния позволяет унифицировать обозначение состояний сильно различающихсякомпонентов ИТС и повысить эффективность работы подсистемы управления уст-
ранением неисправностей.
Предложен метод проведения диагностики компонентов ИТС с помощью тес-
товых проверок. Выбор последующей проверки производится с учетом результатов
предыдущей, что позволяет минимизировать количество осуществляемых прове-
рок, а значит сократить время, затрачиваемое на диагностирование. В дальнейшем
возможно усовершенствование алгоритма выбора первоначальных тестовых про-
верок на основании данных мониторинга.
ЛИТЕРАТУРА
1. Система управління інформаційно-телекомунікаційною системою
корпоративної АСУ/ С.Ф.Теленик, О.І.Ролік, М.М.Букасов, Р.Л.Соколовський //
Вісник НТУУ «КПІ». Інформатика, управління та обчислювальна техніка. —
2006. — № 45. — С. 112—126.
2. Ролик А.И., Тимофеева Ю.С., Турский Н.И. Управление устранением неис-
правностей в ИТ-системах// Вісник НТУУ «КПІ». Інформатика, управління та
обчислювальна техніка. — К.: «ВЕК+», — 2008. — № 49. — С. 94—107.
3. Ролик А.И., Глушко Е.В. Анализ качества функционирования элементов ин-
формационно-телекоммуникационных систем// Вісник НТУУ «КПІ».
Інформатика, управління та обчислювальна техніка. — К.: «ВЕК+», — 2008. —
№ 48. — с. 113—120.
4. Rish I., Brodie M., Odintsova N., Ma S., Grabarnik G. Real-time Problem Determi-
nation in Distributed Systems using Active Probing// Network Operations and Man-
agement Symposium. NOMS 2004. IEEE/IFIP.— April 2004.— Vol. 1.— pp. 133—
146.
5. Beygelzimer A., Brodie M., Ma S., Rish I. Test-based Diagnosis: Tree and Matrix
Representations // Integrated Network Management. IM 2005. IFIP/IEEE.— May
2005.— pp. 529—542.
6. Chen, M. Zheng, A.X. Lloyd, J. Jordan, M.I. Brewer, E. Failure diagnosis using deci-
sion trees // Autonomic Computing, 2004.— May 2004.— pp. 36—43.
7. Natu, M. Sethi, A.S. Application of adaptive probing for fault diagnosis in computer
networks // Network Operations and Management Symposium. NOMS 2008.
IEEE/IFIP.— April 2008.— pp. 1055—1060.
8. Utton, P.; Scharf, E. A fault diagnosis system for the connected home // Communica-
tions Magazine, IEEE.— Vol. 42.— November 2004.— pp. 128—134.
9. Singh V.K., Schulzrinne H., Miao K. DYSWIS: An architecture for automated diag-
nosis of networks// Network Operations and Management Symposium. NOMS 2008.
IEEE/IFIP.— April 2008.— pp. 851—854.
10. Ролик А.И., Соколовский Р.Л. Распределение мобильных компонентов системы
управления информационно-телекоммуникационной системой// Вісник НТУУ
«КПІ». Інформатика, управління та обчислювальна техніка. — К.: «ВЕК+», —
2007. — № 47.— С. 113—124.
11. Теленик С. Ф., Ролік О.І., Терещенко П.І., Літвінцов О.В. Модель управління
розподілом ресурсів інформаційно-телекомунікаційної системи збройних сил
України// Збірник науков. праць ННДЦ оборонних технологій і воєнної безпеки
України. — 2006. — №5 (34). — C. 117—124.Теленик Сергій Федорович, д. т. н., професор, завідуючий кафедрою Автоматики та управління в
технічних системах Національного технічного університету України «Київський політехнічний
інститут», тел. (044) 236-42-99, факс: (044) 241-70-39,
е-mail: telenik@auts.ntu-kpi.kiev.ua, поштова адреса: 03057, Київ, пр. Перемоги, 39, кв. 85.
Ролік Олександр Іванович, к. т. н., с. н. с., доцент кафедри Автоматики та управління в технічних
системах Національного технічного університету України «Київський політехнічний інститут», тел.
Моб. (067) 905-4041, тел. (044) 221-48-88, факс: (044) 241-70-39,
е-mail: rolick@auts.ntu-kpi.kiev.ua, поштова адреса: 01135, Київ, пр.. Перемоги, 16, кв. 131.
Тимофєєва Юлія Сергіївна, магістр кафедри Автоматики та управління в технічних системах
Національного технічного університету України «Київський політехнічний інститут», тел. (044) 443-
24-52, факс: (044) 241-70-39, е-mail: daimos@mail.i.com.ua, поштова адреса: 03190, Київ, вул.
Саратовська, 10а, кв. 26.
Методы диагностики компонентов информационно-телекоммуникационных
систем
С.Ф. Теленик, А.И. Ролик, Ю.С. Тимофеева
Статья посвящена проблемам повышения эффективности устранения неис-
правностей в информационно-телекоммуникационных системах путем совершен-
ствования методов диагностики компонентов ИТС. Предложены классификация
компонентов ИТС, схема кодирования их состояний, метод проведения диагности-
ки компонентов ИТС с помощью тестовых проверок.
Методи діагностики компонентів інформаційно-телекомунікаційних систем
С.Ф. Теленик, О.І. Ролік, Ю.С. Тимофєєва
Стаття присвячена проблемам підвищення ефективності усунення несправно-
стей в інформаційно-телекомунікаційних системах шляхом вдосконалення методів
діагностики компонентів ІТС. Запропоновано класифікацію компонентів ІТС, схе-
му кодування їх станів, та метод проведення діагностики компонентів ІТС за допо-
могою тестових перевірок.
Methods of components of information-telecommunication systems diagnostics
S.F. Telenik, A.I. Rolik, Y.S. Tymofeeva
This article is dedicated to problems of increase of efficiency of fault elimination in
IT-systems by the improvement of the methods of ITS components diagnostics. The
classification of the ITS components and the scheme of coding their states are proposed.
The method of ITS component diagnostics using probes is presented.Вы также можете почитать
