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

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

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

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

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

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

• Troubleshooting High CPU Utilization Due to Interrupts
• Troubleshooting High CPU Utilization due to Processes
• Troubleshooting High CPU Utilization on Cisco Routers
• Catalyst 3750 Series Switches High CPU Utilization Troubleshooting
• High CPU Utilization on Cisco IOS Software-Based Catalyst 4500 Switches

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

Именно по причине высокой важности контроля загруженности центрального процессора, мониторить эту загруженность умеют почти все средства мониторинга цисок. Не исключение и 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%.

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

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

Данные из CLI.

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

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

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

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

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

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