Оценка частоты выборки образцов данных SNMP

Если спросить у пяти менеджеров сети, какова разумная частота отбора данных SNMP, мы услышим шесть разных ответов. Имеется много конфликтующих аспектов, влияющих в этом случае на ответ. Рассмотрим некоторые из них.

Собственно в NNM размер наименьшего интервала отбора данных SNMP составляет одну секунду. Агенты SNMP, работающие как низкоприоритетные процессы на 8-битовой аппаратуре, могут быть не в состоянии за такое короткое время ответить на SNMP-запрос для нескольких объектов. При слишком сильном давлении они будут часто превышать установленный лимит времени и становиться «неотзывчивыми». Напомним, что по умолчанию NNM конфигурируется таким образом, чтобы выполнялись три дополнительные попытки запроса SNMP с возрастающими в геометрической прогрессии тайм-аутами, начиная с 0.8 секунды (0.8, 1.6, 3.2 и 6.4 секунд для четырех тайм-аутов, в общей сложности составляющих 12 секунд). Повторные попытки только послужат перегрузке медленных SNMP-агентов. Интервалов опроса в одну секунду обычно избегают, поскольку они меньше, чем интервалы тайм-аута. Администраторы NNM не хотят тратить дополнительное время на конфигурирование специфических временных параметров SNMP для особых сетевых устройств.

При опросе устройств удаленной сети может возникать суммарная задержка около одной секунды, особенно если при передаче используются перегруженные последовательные каналы. Установленные по умолчанию короткие интервалы опроса SNMP только добавят трафик в сети. Для подсетей в целом действительно практично определять один набор значений тайм-аута SNMP, поскольку для этого требуется всего лишь установить один метасимвол в GUI конфигурирования. Для этого случая период опроса в одну секунду по-прежнему слишком мал, поскольку упомянутая задержка увеличит временные показатели опроса до нескольких секунд.

Высокоскоростной и объемный SNMP-опрос может порождать значительный сетевой трафик. При том, что во многих системах NNM используются адаптеры Fast Ethernet, возможна ситуация, когда последовательный канал может быть завален трафиком SNMP в ущерб критически важному трафику. Эвристическое правило состоит в том, что для трафика управления сетью не должно использоваться более 10% пропускной способности любого канала. Полагая, что размер пакета SNMP составляет 200 байт, для вычисления добавочного объема сетевого трафика, возникающего по причине наличия SNMP-опроса, можно умножить это число на количество устройств и разделить на размер интервала опроса. Заметим, что snmpCollect стремится сократить число SNMP-запросов, определяя для агента SNMP каждого устройства число значений, которые он может возвратить в ответ на один запрос. Это сокращает накладные расходы на пересылку множественных запросов одиночных параметров, что очень радует. Это также увеличивает средний размер пакета свыше предполагаемых по умолчанию 200 байт. Накладные расходы трафика в сети являются еще одним доводом в пользу использования больших интервалов опроса.

Короткие интервалы опроса многих объектов SNMP вынуждают демона snmpCollect расходовать больше времени ЦП. Это может негативно влиять на небольшие системы NNM. В идеальном случае желательно, чтобы демон snmpCollet потреблял не более 10% ресурсов ЦП. С другой стороны, если одновременно предпринимается слишком много попыток сбора информации, snmpCollect может не успевать. Стоит упростить работу snmpCollect путем задания опцииn numberconcurrentsnmp в snmpCollect.lrf. Кроме того, нужно следить за содержимым файла $OV_LOG/ snmpCol. trace на предмет возможных проблем, поскольку в этой опции может быть установлено слишком высокое значение. Это значение должно быть строго меньше maxfiles, параметра операционной системы, задающего максимальное число одновременно открытых файлов. Если значение maxfiles равно 64, то эмпирически находится хорошо работающий параметрn 35 (но следует контролировать $OV_LOG/snmpCol.trace, чтобы убедиться в жизнеспособности snmpCollect). И опять есть все основания поддерживать интервалы опроса на верхней границе.

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