Компания HP
Опубликован: 22.09.2006 | Доступ: свободный | Студентов: 675 / 67 | Оценка: 4.22 / 3.72 | Длительность: 22:59:00
ISBN: 978-5-9556-0042-6
Лекция 9:

Управление производительностью с использованием NNM

SNMPv2c и 64-битные счетчики

Стандартное целое число в SNMP MIB2 состоит из 32 бит. В SNMPv2C MIB определяется новый тип целых чисел длиной в 64 бита с отличительным именем unsigned64. Его максимальным значением является число

18,446,744,073,709,551,615

Причина определения такого длинного счетчика обосновывается в rfc2233:

"Поскольку скорость сетевой среды возрастает, уменьшается минимальное время, за которое 32-битный счетчик будет переполняться. Например, поток подтверждаемых полноразмерных пакетов в 10Mbs приведет к переполнению ifInOctets всего лишь за 57 минут; при 100Mbs минимальное время переполнения составляет 5,7 минут, а при 1Gbs этот минимум составляет 34 секунды. Соблюдение требования производить опрос интерфейсов настолько часто, чтобы не застать переполнение счетчика, становится все более проблематичным".

Заметим, что NNM хорошо управляется с единичным переполнением счетчика, но если между взятиями образцов SNMP случаются два переполнения счетчика, в результате мы получим неверные данные. Напомним, что предлагалось использовать пятиминутный интервал взятия образцов для сбора данных SNMP (см. "Оценка частоты выборки образцов данных SNMP" в этой лекции). Таким образом, очевидно, что интерфейсы обычного Fast Ethernet должны опрашиваться почти с такой интенсивностью, чтобы избежать переполнения счетчика в ситуациях высокой загруженности. Поскольку невозможно знать заранее, насколько загружен канал, чтобы избежать переполнения, все они должны подвергаться опросу с пятиминутными интервалами. Если же используются 64-битные счетчики SNMPv2C, то можно позволить себе больший интервал взятия образцов для коллекций исторических данных SNMP.

Как показано на рис. 9.9, новые 64-битные счетчики SNMPv2C находятся в подразделе IfXEntry раздела интерфейсов MIB2. Подробные определения можно найти в rfc2233.

Заметим, что NNM производит стандартную проверку конфигурации для каждого SNMP-устройства, чтобы определить, поддерживается ли в нем SNMPv2C. Эту проверку можно запретить, указав опцию –2 в $OV_CONF/netmon.lrf. Некоторые устройства и системы при получении запроса SNMPv2C могут вести себя неправильно, журнализировать сообщение или выдавать предупреждение. Указанная опция демона netmon позволяет избежать этой проблемы. В долгосрочном плане лучше обновлять таких агентов SNMP, временно переводя соответствующие устройства в неуправляемое состояние или включая их IP-адреса в netmon.noDiscover.

Неразумно управлять гигабитным Ethernet без использования 64-битных счетчиков.

64-битные счетчики в SNMPv2C

увеличить изображение
Рис. 9.9. 64-битные счетчики в SNMPv2C

Это расширенный раздел интерфейсов, определенный в SNMPv2C. Заметим, что при наличии таких переменных вида Counter64, как ifHCInOctets и ifHCOutOctets, линия с пропускной способностью в 1 терабит в секунду (1,000 Gbps) приведет к переполнению счетчика только через пять лет. Старая переменная ifSpeed ограничена пропускной способностью около 2.2Gbps, тогда как единицей измерения новой переменной ifHighSpeed является 1,000,000 бит в секунду.

Заключение

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

Методология планирования нагрузки

Рис. 9.10. Методология планирования нагрузки

Средство имитационного моделирования является ядром методологии планирования нагрузки. Много времени можно сэкономить путем импортирования топологии сети из NNM, данных о производительности – из NetMetrix, и трасс транзакций – из LAN-анализаторов. Поставив задачу, администратор запускает симулятор, чтобы выяснить, отвечает ли сеть требованиям ко времени реакции и интенсивности использования. Если требования не удовлетворяются, нужно вернуться назад и передвинуть серверы, добавить пропускную способность, изменить топологию или ограничить загрузку трафика, и повторять это до тех пор, пока требования не будут удовлетворены. Когда выясняется, что конструкция сети может обеспечить желаемую производительность, можно привести доказательства этого в виде графиков и диаграмм.