Для того, кто осознанно приобретает совсем недешёвое умное (intelligent) оборудование компании Cisco, не является секретом, за что он переплачивает. По сути, типовые сетевые устройства Cisco (маршрутизаторы, коммутаторы и брандмауэры) представляют собой серверы, заточенные под выполнение узкоспециализированных задач – обработку сетевых пакетов.

Как и во всех нормальных серверах, в сетевых устройствах Cisco есть центральный процессор, оперативная и постоянная память, и даже операционная система с процессами, которые эти самые процессор и память используют для своих нужд.

Ресурсы центрального процессора циски расходуются на два типа задач – обработку прерываний и работу процессов.

Прерывания происходят всякий раз, когда пакет выходит с консольного или AUX порта. Высокая загрузка процессора, связанная с обработкой прерываний, обычно означает, что через устройство проходит большой трафик. В нормальных условиях при полном использовании пропускной способности циски, эта загрузка не превышает 30-40%. Однако, если допустить бесконтрольный рост сети, то рано или поздно, через устройства начнёт идти такой объём трафика, что загрузка процессоров по прерываниям превысит допустимые нормы.

Процессы, помимо простого перенаправления пакетов с порта на порт в зависимости от таблицы маршрутизации/коммутации, занимаются и более интеллектуальными задачами (OSPF, SNMP, NBAR, STP и т.д.). Ошибки, допущенные при конфигурировании цисок могут привести к чрезмерной загрузке процессора, связанной с обработкой процессов. Не стоит, к примеру, настраивать на маршрутизаторе 200 туннелей и включать на каждом NBAR, или задавать интервал опроса циски средствами мониторинга меньше, чем 5 минут.

Бывают однако и более экзотические случаи, когда не удаётся сходу разобраться, почему центральный процессор нагружен сверх меры. Для таких ситуаций На сайте Cisco есть несколько статей:

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

Именно по причине высокой важности контроля загруженности центрального процессора, мониторить эту загруженность умеют почти все средства мониторинга цисок. Не исключение и Metrex Cisco Management Pack для SCOM 2007.

Он позволяет:

1. отслеживать загруженность центрального процессора, усреднённую по 5-минутному, 1-минутному и 5-секундному интервалам,

Нагрузка на процессор.

Чем больше период усреднения, тем глаже график.

2. отслеживать загрузку процессора, связанную с прерываниями,

Обработка прерываний отъедает солидный кусок процессорных ресурсов, но всё в передлах нормы.

Обработка прерываний отъедает солидный кусок процессорных ресурсов, но пока всё в пределах нормы.

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

Типичный набор для коммутатора уровня ядра.

Типичный набор для коммутатора уровня ядра.

Тишь да гладь.

Тишь да гладь.

Здесь важно оговориться, почему мы решили отслеживать только самые жадные процессы, а не вообще все. Дело в том, что в зависимости от сложности выполняемых задач, в циске бывает одновременно запущено 150-300 процессов. По каждому процессу в идеале нужно выводить три графика – усредняемый по 5 минутам, 1 минуте и 5 секундам. Итого – 450 – 900 графиков по каждому устройству. Помимо того, что от такого потока информации распухнет база данных SCOM, перспектива работы с 900 графиками приведёт в уныние любого оператора мониторинга.

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

Похоже, что с трафиком перебор.

Похоже, что с трафиком перебор.

Благодаря такому умному уведомлению, сетевой администратор на момент происшествия уже может примерно прикинуть, в чём причина высокой загрузки процессора, это позволяет сократить время реакции до минимума. Да и что греха таить, выглядит такое уведомление просто круто.

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

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

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

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

Ни один процесс не шелохнётся.

Ни один процесс не шелохнётся.

Судя по ним, центральный процессор коммутатора постоянно загружен на 20-25% не понятно чем. Все процессы по нулям, и прерывания тоже. Чем же он занят?

А вот это – уведомление с него же:

На прерывания ушёл 1%, на процессы - 0%, а суммарно - 79%.

На прерывания ушёл 1%, на процессы - 0%, а суммарно - 79%.

Бессмыслица какая-то, не правда ли? Причём творились эти странности только на некоторых коммутаторах, а вот со всех маршрутизаторов поступали вполне адекватные данные.

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

Данные из CLI.

Данные из CLI.

Как видите, тут не нули, а вполне осмысленные значения. А во-вторых, выяснилось, что нули по SNMP возвращают исключительно коммутаторы с относительно старым IOS (2008 года и старше). А после прошивки свежего IOS ситуация волшебным образом меняется, по SNMP начинают приходить реальные значения.

Однако, как же отследить, что IOS устройства врёт и его нужно обновить на новый? Для этого мы добавили в наш менеджмент пак ещё один монитор. Принцип его работы предельно прост, он 10 раз собирает статистику по процессам, и если из этих 10 опросов ни один не вернул ни одного значения, отличного от нуля, то монитор рапортует, что IOS нуждается в перепрошивке. Дело в том, что в реальных условиях не может быть такого, чтобы использование процессора всеми процессами постоянно было нулевым. К примеру,  значение 5-секундной загрузки для процесса SNMP Engine, практически всегда отлично от нуля.

Вот как выглядит статистика по версиям IOS у одного из наших клиентов.

Большую часть коммутаторов нужно перепрошивать.

4 из 6 коммутаторов нуждаются в заливке свежего IOS

А вот маршрутизаторы в перепрошивке не нуждаются, даже если IOS датирован 2005-м годом.

А вот маршрутизаторы в перепрошивке не нуждаются, даже если IOS датирован 2005-м годом.

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