Насколько большой трафик создает NNM

Система управления сетью порождает много различных видов трафика в разных объемах. Вот достаточно полный список видов трафика:

• · прямой и обратный поиск DNS плюс зонные пересылки;
• · опрос состояния (запрос и ответ отклика ICMP);
• · SNMP-опрос конфигурации, выполняемый netmon;
• · трафик от накопительной станции к управляющей станции;
• · SNMP-прерывания, получаемые из сети;
• · трафик HTTP и Java удаленных пользователей браузеров;
• · трафик X-Window удаленных пользователей ovw;
• · сбор данных о производительности, выполняемый snmpCollect;
• · трафик RMON SNMP, собираемый NetMetrix;
• · трафик агента HP OV Operations к менеджеру HP OV Operations;
• · передача PerfView статистики HP OV Performance Agents.

Этот трафик имеет пульсирующий характер, и для подключения к сети станции управления сетью (NMS) следует использовать выделенный дуплексный порт коммутатора 100BASE-T. Дуплексное средство исключает возможность коллизий, и линия со скоростью 100 мегабит в секунду обеспечивает высокую пропускную способность и сводит к минимуму задержку LAN. Это также позволяет своевременно выполнять процесс резервного копирования удаленных дисков.

Несмотря на приведенные выше осторожные суждения, мой опыт автора говорит о том, что обычно удовлетворительным является стандартное подключение через Ethernet. Но по-прежнему желательно знать, насколько велик трафик, порождаемый системой NNM. Этого можно добиться путем применения одного из следующих методов:

• · дать системе NNM возможность опрашивать ее собственный LAN-интерфейс;
• · дать системе NNM возможность опрашивать порт коммутатора, к которому она подключается;
• · использовать агента HP OV Performance Agents системы NNM и PerfView;
• · задействовать NetMetrix и датчик RMON для мониторинга трафика NNM;
• · подсоединить анализатор LAN к Ethernet-порту системы NNM.

Предполагается, что система NNM будет располагаться в центре своего домена управления, чтобы минимизировать влияние трафика управления сетью путем его разграничения. Весь входящий и исходящий трафик системы NNM влияет только на один контур WAN. Хотя, если большое число управляемых устройств и подсетей находится на дальнем конце относительно медленной последовательной линии, следует оценить влияние трафика NNM, чтобы избежать нарушения правила 10%. Точно измерить трафик помогут датчики RMON2 и HP NetMetrix.

Заметим, что управленческому персоналу сети и администраторам NNM нужно работать вместе. Проблема уже в том, что агентам SNMP маршрутизаторов назначается низший приоритет задач на маршрутизаторах Cisco. Еще хуже, если менеджер маршрутизатора назначает для трафика SNMP низкоприоритетную очередь, или если IP-адрес системы NNM исключается из списка управления доступом (ACL) маршрутизатора. Такие нелепости являются симптомами дисфункциональности команд.

данные производительность хранение просмотр

До развертывания NNM невозможно ответить на вопрос о влиянии трафика NNM посредством измерений, так что требуется предпринять попытку быстрого анализа. Допустим, что домен управления выглядит так, как показано на рис. 1.6. Можно ли вычислить влияние трафика SNMP, производимого при опросе производительности, при заданных пропускной способности каналов WAN и числе управляемых устройств в области каждого кампуса? (У нас еще нет возможности пользоваться датчиками RMON2 и NetMetrix.) Допустим, что трафик между сайтами A и D проходит через сайты B и C. На канале между сайтами F и C трафик NNM отсутствует, поскольку у обоих этих сайтов имеется прямой канал к сайту D. Для сведения данных в таблицу и вычисления результатов используется простая электронная таблица. Можно предположить наличие пятиминутного интервала опроса и 200-байтного размера пакетов. При вычислениях предполагается, что у каждого опрашиваемого устройства имеется один интерфейс. Нужно внести поправку, отражающую среднее число интерфейсов у управляемых устройств. Вычисления показывают, что канал между сайтами E и D нагружается всего лишь на 2,1%, а у всех других каналов, для которых проводились вычисления, нагрузка еще меньше. Это намного ниже 10%, предусмотренных нашим эмпирическим правилом. Вычисления систематизированы в таблице 1.1. Трафик опроса в байтах в секунду вычисляется путем умножения размера пакета в байтах на восьмикратное число узлов и деления на пятиминутный интервал опроса, выраженный в секундах:

(packet_size_in_bytes * 8 * Number_of_nodes)/(300 seconds).

Теперь вычислим процентное отношение нагрузки канала, разделив трафик опроса в битах в секунду на скорость линии в битах в секунду и умножив на 100:

(polling_traffic/line_speed) * 100.