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

Введение

Часто приходится слышать философские рассуждения об управлении производительностью в реальном мире такого примерно толка:

"Чтобы правильно планировать производительность сети, нужно измерять нагрузку во всех точках сети и детально моделировать топологию. Если нет ресурсов для измерения нагрузки всех компонентов, то нет и реального знания о том, как выглядит сеть, и потребуется вечность, чтобы все это смоделировать. Поэтому нереально планировать возможности сети, и, чтобы справиться с проблемами производительности, следует продолжать обеспечивать требуемую пропускную способность".

Независимо от применяемой методологии планирования, чтобы управлять производительностью сети, важно уметь ее измерять. Для поиска и устранения неисправностей сети требуются данные о загрузке и ошибках в реальном времени. Для службы поддержки важно иметь представление о производительности в связи с нареканиями пользователей. Инженерам сети данные о производительности нужны для планирования нагрузки. Группе IT требуются данные для представления на ежемесячных совещаниях участников соглашения об уровне сервиса (SLA).

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

Определяя, в течение какого времени следует поддерживать доступность данных о производительности NNM в оперативном режиме, приходится искать компромисс между производительностью, удобством и стоимостью. Для ремонтников ценными являются данные, получаемые в режиме реального времени в течение последнего часа работы системы, а планировщикам нагрузки требуются данные за годы. Хранение большого объема данных, доступных в оперативном режиме, может снизить производительность и увеличить накладные расходы системного администрирования, если только не будет сконфигурирована более мощная и дорогая NNM-платформа.

С какой интенсивностью следует производить взятие образцов данных SNMP? Слишком частая выборка может приводить к перегрузке некоторых сетевых устройств и реально увеличивать трафик управления сетью. Но при редком взятии образцов теряются все полезные отклонения показателей производительности. Рекомендуется использовать пятиминутный интервал отбора данных.

Чтобы объяснить тот факт, что чрезмерно интенсивное исследование сети с помощью SNMP может ограничить точность измерений ее показателей, можно с натяжкой привлечь принцип неопределенности Гейзенберга из квантовой физики.

Насколько велик трафик, реально создаваемый системой NNM? Можно попытаться количественно оценить его с помощью простого примера опроса. Заметим, что проверка конфигурации, опрос состояния, HTTP и Java, X-Windows, HP OV Operations и Measureware также вносят свой вклад в трафик.

Принимая решение о том, какие данные SNMP следует отбирать из сотен возможных значений MIB, лучше всего руководствоваться принципом KISS (Keep It Simple, Stupid – "не усложняй, болван"). Часто оказывается достаточной статистика загрузки системы и сети, а также статистика ошибок. Целесообразно использовать MIB-выражения, поскольку процентные отношения полезнее необработанной числовой информации.

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

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

Можно просмотреть исторические данные о производительности в оперативном режиме в диаграммной форме с помощью утилиты xnmgraph или же воспользоваться GUI для конфигурирования исторических данных SNMP. Данные можно просмотреть и сохранить в текстовом виде с использованием xnmgraph или snmpColDump.

Представление данных в автономном режиме означает снятие мгновенных снимков экрана или экспортирование текстовых данных в такие средства презентации или работы с электронными таблицами, как Star Office, Wingz или их эквиваленты для Windows или Macintosh.

В SNMPv2C поддерживаются 64-битные счетчики. Это существенно для управления линиями, функционирующими на скоростях более 100 мегабит в секунду (Mbps). NNM автоматически выявляет устройства с поддержкой SNMPv2C, а в разделе ifXentry интерфейсной части MIB2 определено несколько 64-битных переменных счетчиков.

Данные RMON лучше всего собирать с использованием HP NetMetrix. Можно также отслеживать (ограниченным образом) удаленные сегменты Ethernet с разделяемой средой передачи с помощью непосредственного использования в NNM группы Etherstarts и нескольких полезных MIB-выражений.

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

После того, как в масштабе сети с помощью NetMetrix будут собраны данные о производительности и содержательной для NNM базовой топологии, можно переходить к планированию нагрузки. Средство HP Service Simulator может импортировать данные о производительности и топологии. Вооружившись вопросами вида "что, если", можно использовать симулятор для проверки, сможет ли сеть удовлетворять требованиям производительности при указании тех или иных условий.