Jump to content

Управление неисправностями

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

При возникновении неисправности или события сетевой компонент часто отправляет уведомление оператору сети с использованием такого протокола, как SNMP . Аварийный сигнал — это постоянное указание на неисправность, которое исчезает только после устранения условия срабатывания. Текущий список проблем, возникающих в сетевом компоненте, часто хранится в форме списка активных сигналов тревоги, например, определенного в RFC 3877, MIB сигналов тревоги . Список устраненных неисправностей также поддерживается большинством систем управления сетью . [2]

Системы управления неисправностями могут использовать сложные системы фильтрации для присвоения тревогам уровней серьезности. По степени серьезности они могут варьироваться от отладочных до аварийных, как в протоколе системного журнала . [3] В качестве альтернативы они могут использовать поле воспринимаемой серьезности функции оповещения ITU X.733. Это принимает значения очищенного, неопределенного, критического, серьезного, незначительного или предупреждения. Обратите внимание, что последняя версия проекта протокола системного журнала, разрабатываемого в IETF, включает сопоставление между этими двумя различными наборами серьезностей. Хорошей практикой считается отправлять уведомление не только о возникновении проблемы, но и о ее устранении. Последнее уведомление будет иметь степень серьезности «ясно».

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

Существует два основных способа управления отказами: активный и пассивный. Пассивное управление сбоями осуществляется путем сбора сигналов тревоги от устройств (обычно через ловушки SNMP ), когда что-то происходит в устройствах. В этом режиме система управления неисправностями знает только, достаточно ли интеллектуально устройство, которое она контролирует, чтобы сгенерировать ошибку и сообщить об этом инструменту управления. Однако если отслеживаемое устройство полностью выйдет из строя или заблокируется, оно не подаст сигнал тревоги и проблема не будет обнаружена. Активное управление сбоями решает эту проблему путем активного мониторинга устройств с помощью таких инструментов, как проверка связи , чтобы определить, активно ли устройство и отвечает ли оно. Если устройство перестает отвечать, активный мониторинг выдаст сигнал тревоги, указывающий, что устройство недоступно, и позволит заранее устранить проблему.

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

См. также

[ редактировать ]

Примечания

[ редактировать ]
  1. ^ «Что такое управление отказами? — Определение с сайта WhatIs.com» . Проверено 06 октября 2015 г.
  2. ^ «Что такое управление отказами? Определение и вводное руководство» . Анализ журналов XpoLog, управление ими и просмотр . 07.04.2020 . Проверено 15 ноября 2020 г.
  3. ^ RFC 3164
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 0b22ba1a11e3a65a43daf900e8f17e22__1608994500
URL1:https://arc.ask3.ru/arc/aa/0b/22/0b22ba1a11e3a65a43daf900e8f17e22.html
Заголовок, (Title) документа по адресу, URL1:
Fault management - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)