Волнения первого раскрытия

Тонкая настройка фильтра раскрытия

Первое раскрытие – это всегда неожиданность. Наблюдение за подсхемой Internet, когда NNM раскрывает новую сеть, всегда обеспечивает свежие впечатления. Когда это раскрытие завершается, наступает время оценить то, что находится в базе данных. На первых порах фильтр раскрытия часто оставляют открытым для идентификации каждого IP-адресуемого устройства. Это "раздувает" базу данных NNM. Поэтому теперь приходит время инвентаризации всех OID в сети. Будут присутствовать многие знакомые OID, но найдутся и новые, которые необходимо исследовать до конца. NNM поставляется с большим списком OID от хорошо знакомых производителей, но в сети могут "гостить" и некоторые неизвестные поставщики.

Вооружившись новым пониманием компонентов сети, вероятно, следует модифицировать файл filters, чтобы включать одни дополнительные sysObjectIDs и отвергать другие. Использование sysObjectID в фильтре раскрытия целесообразно, поскольку таким образом обеспечивается простой и изящный метод определения устройств независимо от других трудно определяемых и тяжело управляемых атрибутов, таких как IP-адреса, которые подвержены изменениям в реальной сети. Нужно решить, какие устройства желательно раскрыть и поместить на схему. Возвращаясь к "лекции 3" , напомним, что фильтр схемы определяет, какие устройства показываются на заданной схеме, тогда как фильтр раскрытия определяет, какие устройства netmon допускает в базу данных.

Заметим, что не требуется очищать базу данных и заново раскрывать сеть только для того, чтобы удалить устройства, которые решено не включать в файл filters. Выполнение команды ovtopofix -f filtername применит к текущей базе данных пересмотренный фильтр раскрытия filtername и удалит устройства, которые через этот фильтр не проходят.

Одна из стратегий разработки фильтра раскрытия состоит в определении всего сетевого оборудования в соответствии с OID. Предостережение: некоторые поставщики включают в состав своих sysObjectID версию ОС. Если ОС на одной из этих систем модернизируется, фильтр может перестать работать. Чтобы обойти эту ситуацию, следует пользоваться метасимволами (wildcard), т. е. обозначить метасимволом ту часть OID, в которой фигурирует ОС. Этот прием удобен для менеджеров сети, которые хотят управлять только своей инфраструктурой. Администраторы файловых и принтерных серверов обычно хотят видеть на схеме только свои файловые серверы, сетевые принтеры и сканеры, так что в их системе NNM будет работать другой фильтр раскрытия. Если обе категории пользователей совместно используют одну и ту же систему NNM, то фильтр раскрытия должен будет пропустить оба набора устройств, и может быть определен фильтр схемы, обеспечивающий каждому пользователю представление устройств, которыми он хочет управлять.

Регулировка и наблюдение очередей netmon

Во время первого раскрытия можно заметить, что netmon использует ЦП куда менее интенсивно, чем ожидалось, скорость раскрытия, соответственно, удручающе низка, или NNM с запозданием отображает изменения в состоянии устройств. Да и общая загрузка системы является достаточно низкой. Хотелось бы знать, почему netmon не раскрывает устройства быстрее, и что можно сделать для изменения ситуации.

Следует ввести в файл netmon.lrf необязательные параметры демона netmon -q ICMP-queue-length и -Q SNMP-queue-length. Для обоих параметров значением по умолчанию является 20 в UNIX-системах и 3 в системах Windows NT. Эти значения могут быть увеличены в соответствии со следующими инструкциями.

Параметр ICMP-queue-length следует увеличивать, только если netmon не успевает (на что указывает очередь, всегда заполненная по максимуму), потому что может переполниться буфер операционной системы для хранения входящих ответов ICMP, что может выразиться в беспорядочных ошибочных изменениях состояния. Параметры SNMP-queue-length следует увеличивать, только если netmon не успевает, потому что операционная система ограничивает число дескрипторов открытых файлов для каждого процесса. Это настраиваемый параметр ядра, и его значением по умолчанию часто задается 64. (Заметим, кстати, что аналогичным образом ограничивается демон snmpCollect. ) Не забудьте записать изменения в файл netmon.lrf с помощью команды ovaddobj, прежде чем останавливать и снова запускать netmon.

Теоретическим обоснованием увеличения этих максимальных длин очередей является то, что это позволяет демону netmon выдавать большее число невыполненных запросов. Это увеличивает пропускную способность и помогает демону netmon придерживаться своего расписания опроса. Например, при использовании установленной по умолчанию длины очереди 20 можно ожидать, что netmon будет поддерживаться должным образом, пока среднее время ответа на запросы SNMP не будет превышать 50 миллисекунд.

Увеличение максимальной длины очереди SNMP также повышает устойчивость netmon к медлительным и "неотзывчивым" агентам SNMP. Например, в один из неудачных дней netmon может заниматься опросом 15 медлительных устройств в сети (или, возможно, они будут находиться в удаленной LAN, подключенной через перегруженную линию WAN). Тогда в течение всего этого времени netmon сможет опрашивать только пять других устройств.

Насколько велики могут быть эти предельные значения для очередей? Эмпирическая оценка – 200. После увеличения максимальных значений длин очередей следует часто контролировать поведение очередей демона netmon. Необходимо отслеживать аномальное поведение при раскрытии и опросе и следить за журнальными файлами на предмет потенциальных проблем, вызываемых слишком длинными очередями.

Нужно проконтролировать процесс опроса демона netmon с использованием меню NNM Performance:Network Polling Statistics, затем подождать примерно минуту для получения графического представления течения опроса на основе 10-секундных выборок. Вариант командной строки для контроля функционирования демона netmon – netmon -a 5. Эта команда предписывает работающему экземпляру демона netmon вывести размеры списков тестового опроса (ICMP) и SNMP в файл $OV_LOG/netmon.trace. Эффективным способом использования этого средства является открытие двух shell в отдельных окнах. В первом окне нужно набрать tail -f $OV_LOG/netmon.trace, а во втором – netmon -a 5. При каждом наборе netmon -a 5 в другом окне появляется вывод.

Эффективность настройки netmon основывается на предположении, что отсутствуют какие-либо другие сдерживающие факторы его производительности. Если в NNM интенсивно используется система дискового ввода-вывода (проверьте это с помощью HP Glance/Plus Motif, команды top или команды iostat ), то настройка netmon с целью увеличения его пропускной способности не принесет никакой выгоды. Если серверы DNS крайне медленны, или если канал WAN с низкой пропускной способностью и высокой загрузкой разделяет систему NNM и ее домен управления, то настройка netmon не слишком сильно повысит производительность.

Рабочая лошадка netmon часто залатывается, обновляется и исправляется по мере того, как HP развивает продукт NNM. Появляются новые функции и аргументы командной строки, а некоторые старые исчезают. Держите под рукой оперативную страницу руководства. Пользователям Windows NT следует искать справочную страницу про netmon в оперативной справочной системе. Обычно эта документация является самой свежей, поскольку поступающие от HP патчи наряду с изменением кода обновляют и оперативные страницы руководства. Таким образом, внимание пользователей будет направлено на новые способы настройки netmon.