Управление производительностью с использованием NNM (Network Node Manager)

Размещено на http://www.allbest.ru/

Лекция

На тему: «Управление производительностью с использованием NNM»

План

Введение

1. Данные о производительности

2. Обеспечение данных для SLA

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

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

5. Принцип неопределенности Гейзенберга для SNMP-опроса

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

7. Данные SNMP о производительности в MIB2 и персональных MIB

8. Стратегии установки пороговых значений

9. Создание MIB-выражения

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

11. Предоставление данных о производительности потребителю

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

Заключение

Литература

Введение

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

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

Независимо от применяемой методологии планирования, чтобы управлять производительностью сети, важно уметь ее измерять. Для поиска и устранения неисправностей сети требуются данные о загрузке и ошибках в реальном времени. Для службы поддержки важно иметь представление о производительности в связи с нареканиями пользователей. Инженерам сети данные о производительности нужны для планирования нагрузки. Группе 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 может импортировать данные о производительности и топологии. Вооружившись вопросами вида "что, если", можно использовать симулятор для проверки, сможет ли сеть удовлетворять требованиям производительности при указании тех или иных условий.

1. Данные о производительности

Данные о производительности сети являются существенным компонентом управления сетью, поскольку "нельзя управлять тем, что не измеряется".

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

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

Рис. 1.1. Потенциальные источники проблем производительности

Для поиска и устранения сетевых проблем между клиентской системой и соответствующим сервером требуется размещение инструментальных средств в пяти позициях. Проблема производительности может быть вызвана недостатком ресурсов, чрезмерной загрузкой, ошибками контроля при помощи циклического избыточного кода (CRC) или потерей пакетов. Агенты SNMP, размещенные в позициях 1-5, могут помочь изолировать проблему и скорректировать направление действий.

При сборе базовой информации в ответ на жалобу пользователя персоналу службы поддержки требуется просматривать данные о нагрузке, ошибках и утере пакетов. Если на пользовательской рабочей станции имеется работающий агент SNMP, то можно измерить показатели производительности для ее LAN-адаптера. Для усовершенствованных агентов доступны данные об использовании таких ресурсов, как ЦП, RAM и диск. Серверные системы почти всегда поддерживают SNMP. Большинство жалоб пользователей на производительность касается клиентской, сетевой и серверной систем, поэтому для установления истинной причины важно оценивать данные SNMP во всех этих системах. Проблемы производительности не всегда вызываются сетью. Например, вполне возможно, что неудовлетворительное время реакции в связке клиент-сервер объясняется тем, что у клиента открыто слишком много приложений, что приводит к чрезмерно интенсивной работе виртуальной памяти (VM).

Для инженерного персонала сети требуются операционные показатели, чтобы обосновывать изменения сети и повышение пропускной способности. Важно знать показатели нагрузки каналов, но так же важно и знание показателей "источник-назначение" для различных приложений. Например, некоторая часть web-трафика будет направляться на локальные серверы, а остаток может предназначаться для Internet через брандмауэр. То же самое верно и для e-mail. Файловый и печатный трафик обычно направляется на локальный файловый сервер и локальный, подсоединенный к LAN принтер. Понимание специфичных для приложений пар "источник-назначение" помогает решить, как следует переконструировать сеть. В то время как простые данные о загрузке каналов можно использовать для коррекции распределения пропускной способности, данные RMON2 нужны для сбора специфичных для приложений пар "источник-назначение". С помощью средств отображения, таких как HP NetMetrix, можно отображать эти данные в виде диаграмм, а также создавать табличные отчеты. Эти данные о производительности часто вводятся в комплексный процесс планирования пропускной способности сети. Они подтверждают, что имеющаяся конструкция сети, очевидным образом обеспечивающая необходимую связность, также обеспечивает и необходимую производительность.

Для IT-организации требуются показатели для соблюдения условий соглашений об уровне обслуживания (SLA) и их пользовательских сообществ. Каждое пользовательское сообщество является отдельной группой лиц с общими интересами, которой свойственны особые требования к сети, а SLA является соглашением между ними и IT о том, какой ожидается уровень обслуживания. Согласованные показатели должны быть доступными для понимания и измеримыми. Время реакции приложения очень трудно измерить, если разработчики не включили в свой код соответствующие инструментальные средства. Код, который реализован с применением API монитора ресурсов приложения (ARM), очень просто отслеживать с помощью стандартного приложения HP PerfView. Для приложений, код которых не рассчитан на применение ARM, основой для SLA обычно являются более простые показатели, получаемые через SNMP, такие как интенсивность нагрузки.

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

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

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

Рис. 1.2. Демонстрация пропускной способности с использованием данных SNMP

2. Обеспечение данных для SLA

Составим список того, о чем реально заботятся пользователи, когда это касается их сетевых приложений.

О чем заботятся пользователи:

· время реакции для интерактивных транзакций;

· пропускная способность при передаче файлов и заданий на печать;

· высокая доступность;

· простота использования;

· удобство.

Теперь составим список того, о чем пользователи не заботятся, когда используют свои каждодневные сетевые приложения:

О чем пользователи не заботятся:

· интенсивность использования сетевой магистрали;

· процентное отношение ошибок;

· процентное отношение потери пакетов;

· полное время работы утилиты ping.

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

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



Рис. 1.3. Пример диаграммы, используемой в SLA

Отдел IT и сообщество пользователей договорились, что 90% времени интенсивность использования линии Internet не будет превышать 50% при наличии менее 100 активных пользователей. Именно в таком графическом представлении данных видно, что пятница - самый загруженный день недели, и последний день месяца тоже наиболее загружен. Определенные рабочие дни часто привлекают большее число пользователей, применяющих различные сочетания приложений.

Сетевые и системные администраторы точно так же знают, что для хорошей производительности важны предельные значения пропускной способности. Поэтому они измеряют интенсивность нагрузки и поэтому в SLA должно содержаться соглашение о данном показателе. Вспомним, что SLA является инструментом, используемым сообществом конечных пользователей, и их IT сервис-провайдером для достижения согласия. Собрания SLA не являются ежемесячными оправданиями в ответ на нарекания пользователей, поисками виновных, состязаниями политических программ и ниспровержением имен.

Итак, очевидно, что SLA должно быть "настолько простым, насколько возможно, но не проще"¹⁾ и базироваться на измеримых величинах. Например, можно договориться, что отдел IT обеспечит подключение к Internet таким образом, что интенсивность нагрузки не будет превышать 50% в 90% случаев при наличии менее 100 активных пользователей. Данные об интенсивности нагрузки легко получить с маршрутизатора через SNMP. Число активных пользователей нельзя измерить непосредственно с помощью SNMP. На самом деле, этот показатель трудно измерить должным образом, но его можно получить из журнала proxy-сервера брандмауэра или с маршрутизатора посредством его средства учета использования ресурсов IP. Каждый месяц на собраниях SLA представляется простая диаграмма, подобная той, которая показана на рис. 1.3.

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

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

Если нужно обеспечивать поддержку пользователей, производящих собственный сбор данных SNMP, то требуется предоставить им необходимое дисковое пространство. Предполагается, что такие пользователи будут вести себя ответственно. Вот золотые правила специального сбора данных:

· громоздкие коллекции данных обычно неприемлемы;

· очень долгосрочные коллекции данных должны иметь ограниченный размер;

· по окончании изучения данных коллекцию следует удалять;

· следует ограничить изучение результатов быстрого опроса временем интервала сессии.

В качестве общей услуги для сообщества пользователей многие системы NNM конфигурируются таким образом, чтобы собирать основную информацию SNMP на всех устройствах домена управления. По умолчанию в только что внедренной (Out Of The Box, OOTB) системе NNM все определенные коллекции данных находятся в отложенном состоянии, так что никакие данные SNMP не являются доступными без вмешательства системного администратора NNM. В NNM имеются утилита ovbackup и средство построения хранилища данных для выполнения резервного копирования исторических данных SNMP или их сжатия.

Сокращение объема исторических данных SNMP является обязательным, поскольку в противном случае рано или поздно диск переполнится. Кроме того, разбухание базы данных существенно замедляет поиск данных для построения диаграмм при выполнении средства отображения данных xnmgraph. Для решения задач поиска и устранения неисправностей требуются только свежие данные SNMP. Долговременные данные о производительности, используемые сетевым инженерным персоналом, так же просто могут выбираться из резервных копий данных NNM.

На оперативной странице руководства для приложения snmpColDump HP приводит примерный UNIX-скрипт, предназначенный для сокращения объема данных SNMP (см. рис. 1.4). Большинство администраторов NNM модифицирует этот скрипт, приспосабливая его к своим локальным нуждам и создает в UNIX периодически, например, ежечасно, выполняющееся задание cron.

Рис. 1.4. Образец скрипта сокращения объема данных SNMP

Этот небольшой shell-скрипт из оперативной страницы руководства snmpColDump сокращает объем данных файла 1MinLoadAvg до 2000 записей. Это SNMP-переменная UNIX, в которой сохраняется среднее число процессов в очереди на запуск в течение минутного интервала. Следует настроить скрипт, пропустив его для каждого файла данных SNMP системы. Если администратор системы NNM знаком с теоремой Найквиста (Nyquist Sampling Theorem), то выборка образцов из 1MinLoadAvg, вероятно, будет производиться каждые 30 секунд. Остающиеся 2000 образцов данных соответствуют 1000 минут (около 16,7 часов) данных.

Для ускорения процесса сокращения объема данных в многопроцессорной системе можно запустить параллельные скрипты сокращения объема данных, каждый из которых предназначается для некоторой независимой части базы данных SNMP. Будет заметно впечатляющее повышение скорости. Вместо периодического запуска скрипта с использованием cron можно сконфигурировать HP OV Operations таким образом, чтобы отслеживался размер базы данных. Тогда HP OV Operations может по мере необходимости автоматически выполнять скрипт сокращения объема данных.

Обсудим некоторые доводы в пользу сохранения возможности доступа к историческим данным SNMP в оперативном режиме. Допустим, что рассмотренные выше проблемы можно смягчить. Можно увеличить емкость дисковой памяти RAID, установить второй SCSI-контроллер, приобрести дополнительный ЦП для повышения производительности. Можно модифицировать скрипт, приведенный на рис. 9.4, чтобы произвести повторную выборку образцов данных, усредняя более давние пятиминутные образцы в часовые образцы и уменьшая, таким образом, объем данных в 12 раз. Тогда выгодно иметь в оперативном режиме достаточный объем исторических данных SNMP, покрывающих следующие важные периоды любого бизнеса:

· самый загруженный час дня;

· самый загруженный день недели;

· самый загруженный день месяца;

· самый загруженный день квартала;

· самый загруженный день года;

· самый загруженный день при особых обстоятельствах.

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

Заключительное замечание по поводу долгосрочного хранения данных SNMP относится к вопросу стоимости дисковых устройств. На данный момент стоимость 18-гигабайтного внутреннего SCSI-диска находится в пределах $600. Поэтому 18-гигабайтный дисковый массив с двойным зеркалированием и тремя дисками для каждого зеркала можно построить примерно за $3600. Очевидно, что требуется выбрать компьютерную платформу для размещения этих дисков внутренним или внешним образом, и это соответственно увеличивает цену. Но эти цифры не являются чем-то необычным; на самом деле, для критически важной системы NNM они более чем приемлемы.

4. Оценка частоты выборки образцов данных 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 байт. Накладные расходы трафика в сети являются еще одним доводом в пользу использования больших интервалов опроса.

Рис. 1.5. Как интенсивность отбора влияет на качество данных

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

Короткие интервалы опроса многих объектов 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 и сетевые устройства.

5. Принцип неопределенности Гейзенберга для SNMP-опроса

Профессионалы в области квантовой механики высоко ценят известный принцип неопределенности Гейзенберга (Heisenberg), который устанавливает, что невозможно одновременно точно определить координаты положения и импульса частицы. Произведение двух неопределенностей всегда больше некоторого минимального значения, оцениваемого постоянной Планка (6.6256*10^-34). Специалисты в области квантовой физики знают, что это объясняется тем, что действие измерения нарушает измеряемый процесс.

У сетевых менеджеров отсутствует сформулированный принцип для объяснения этого явления, но известно, что использование в сети управляющего программного обеспечения SNMP изменяет ее поведение. Опрос сети с интенсивностью, которая позволила бы оценить ее реальное поведение, нарушает его настолько грубо, что приходится ограничиваться довольно робким интервалом опроса в пять минут. Эмпирическим правилом является ограничение трафика SNMP до 10% пропускной способности линии. Что же нарушается в сети, когда NNM используется для опроса устройств? Рассмотрим следующий список:

· добавляется трафик, который только повышает интенсивность нагрузки;

· нагружаются сетевое оборудование и серверные системы;

· сами данные подвергаются искажению по причине наличия задержек;

· на многих устройствах агенты SNMP обладают низкими приоритетами.

Большей части этих проблем можно избежать. Например, рассмотрим использование агентов RMON2 для сбора сетевой статистики. Датчикам RMON2 не требуется опрашивать сетевое оборудование, а HP NetMetrix может периодически загружать статистику с минимальным влиянием на сеть.

6. Насколько большой трафик создает 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) маршрутизатора. Такие нелепости являются симптомами дисфункциональности команд.

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



Рис. 1.6. Вычисление влияния опроса производительности

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

До развертывания 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

7. Данные SNMP о производительности в MIB2 и персональных MIB

В промышленном стандарте MIB-2 имеются сотни полезных переменных. Большая их часть располагается в разделе интерфейсов, и еще несколько переменных можно найти в разделе IP. Разумно ограничить объем собираемых данных до абсолютно необходимого минимума. Это позволит избежать перегрузки агентов SNMP, излишнего обременения сети и хранения на жестком диске множества ненужных данных о производительности.

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

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

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

8. Стратегии установки пороговых значений

Следует ли устанавливать пороговые значения для опроса производительности? Что собирается делать персонал с пороговыми событиями?

В чем состоит локальная обработка? Ответ следующий: ничего сделать нельзя и ничего делать не следует. В конце концов, если пользователь загружает по сети большой файл или если выполняется резервное копирование, уместно ли выслеживать систему-нарушительницу и отключать порт коммутатора, к которому она подключена? Такой вид полицейского управления сетью определенно вызовет негативную реакцию пользователей.

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

Если предполагается, что желательно генерировать пороговые события, то каким образом следует устанавливать пороговые значения? Можно рассмотреть три подхода.

Простейший способ основан на использовании опубликованных эмпирических правил, подобных тем, которые приведены в таблице 1.2, и учебников по планированию пропускной способности.²⁾

Более сложный подход состоит в повышении уровня пороговых уровней до тех пор, пока интенсивность событий не станет приемлемо низкой. Очевидно, что этот подход является трудоемким, поскольку приходится отслеживать каждый интерфейс и производить индивидуальную наладку. Этот метод еще называют "последовательной оптимизацией". Для каждого устройства показатели производительности отслеживаются на протяжении нескольких недель, и затем соответствующим образом изменяются пороговые уровни. Заметим, что эти пороговые уровни можно вручную добавить в файл $OV_CONF/snmpCol.conf, чтобы избежать утомительной работы с GUI конфигурирования сборщика данных SNMP. Формат этого файла изменен в версии NNM 6.0, так что при модернизации системы NNM следует соблюдать осторожность при миграции этого файлового формата.



Рис. 1.7. Пропускная способность TCP и потеря пакетов

Как показано на этом рисунке, аналитический подход к установке порогов ошибок включает исследование опытных данных. На этом графике показано одно потоковое соединение TCP между рабочими станциями одного сегмента LAN, подверженного потере пакетов. Как видно, самый незначительный процент потери пакетов фактически сводит на нет преимущества потоковой передачи данных на основе TCP. Эти данные обосновывают установку значения порога ошибок в один процент.

И, наконец, существует подход к установке пороговых значений на основе аналитических рассуждений. Например, предположим, что последовательный канал моделируется как простая очередь M/M/1. Напомним, что если эта очередь нагружается на 90%, то среднее время ожидания превышает норму в 10 раз. Это уважительная причина для сигнала тревоги. По поводу частоты ошибок и потери пакетов рассмотрим график, приведенный на рис. 1.7. Он показывает, как падает пропускная способность TCP у приложения, выполняющего непрерывную передачу данных с использованием TCP, при увеличении процентного отношения потерянных пакетов. Наличие всего одного процента потери пакетов фактически снижает пропускную способность до ничтожного уровня.

Рис. 1.8. Пороговые параметры NNM

В примерах, приведенных в тексте, для генерации порогового события требовалось превышение значение порога тревоги в четырех последовательных выборках образцов. Образец B приведет к генерации события, а образец A - нет, поскольку только в одной из последовательных выборок превышено значение порога тревоги. В двух последовательных выборках образцов не должен превышаться порог отмены тревоги, так что образец C является единственно пригодным.

Чтобы избежать генерации сигнала тревоги по причине случайной одиночной ошибки, можно воспользоваться пороговыми опциями NNM. Если указать, что данный показатель должен превысить пороговое значение для четырех последовательных выборок образцов, то можно гарантировать, что сигнал тревоги будет вырабатываться только при продолжительном существовании условия ошибки. При пятиминутных выборках это означает, что для подачи сигнала тревоги требуется 20-минутная продолжительность существования условия ошибки. Чтобы обеспечить быстрое обнаружение восстановления обслуживания, можно установить продолжительность интервала снятия сигнала тревоги всего лишь в две выборки образцов, или в 10 минут. Эти принципы объясняются на рис. 1.8.

9. Создание MIB-выражения

И в стандартной MIB2, и в корпоративных MIB поддерживаются переменные-счетчики для байтов, октетов, пакетов и ошибок. Среди действительно полезных показателей, необходимых для управления производительностью сети, имеются процентное отношение интенсивности нагрузки и процентное отношение ошибок. В сборщике исторических данных SNMP NNM предопределено довольно много полезных MIB-выражений. Подробный перечень см. в главе 11 руководства Managing Your Network with HP OpenView Network Node Manager. MIB-выражение представляет собой арифметическую формулу в обратной польской записи (Reverse Polish Notation, RPN), составленную из идентификаторов объектов стандартной MIB. Выражения сохраняются в файле $OV_CONF/mibExpr.conf, который поддерживается вручную с использованием какого-либо текстового редактора.

Вот пример MIB-выражения:

If%deferred \ "packets deffered/packets transmitted" \

.1.3 6.1.4.1.11.2.4.1.1.1.4. .1.3.6.1.4.1.11.2.4.1.1.1.2. / 100 *

Метка If%deferred в первом поле указывает на "процентное отношение задержки интерфейса"; это поле предназначается для вычисления процентного отношения числа переданных пакетов, для которых наблюдается задержка перед передачей. Обратный слеш является разделителем полей. Текст в кавычках во втором поле является комментарием, который обычно содержит информацию о MIB-выражении. В данном случае он показывает нам формулу для вычисления процентного отношения задержанных пакетов. Третье поле содержит реальную формулу в формате RPN (иначе называемом постфиксным форматом). В приведенном выше примере имеется пять элементов. Первые два являются идентификаторами объектов из определяемых поставщиком HP MIB для задержанных и переданных пакетов; они помещаются в стек. Третий элемент - это прямой слеш, который представляет операцию деления. Частное помещается в стек. Четвертый элемент - это целое число 100, которое помещается в стек. Пятый элемент - это звездочка, которая обозначает операцию умножения, а результатом является процентное отношение, остающееся в стеке и представляющее собой процент задержанных пакетов.

Когда демону snmpCollect встретится в коллекции это MIB-выражение, он запросит у устройства значения для всех объектов, содержащихся в выражении, вычислит формулу и сохранит результат в базе данных.

Вот еще один пример MIB-выражения, в котором измеряется процентное отношение потерянных пакетов в маршрутизаторе:

На практике маршрутизаторы Cisco включают в показатель ipOutDiscards те пакеты, которые не могли быть перенаправлены, несмотря на попытки найти MAC-адрес устройства с использованием ARP, поскольку в ARP-кэше отсутствует запись для целевого IP-адреса назначения из отбрасываемого пакета. Другими словами, если пакет невозможно доставить по назначению, то маршрутизатор будет увеличивать счетчик, даже если это не имеет отношения к переполнению буфера, в надежде на обнаружение которого и производилось данное измерение. Из этого следует сделать вывод, что, несмотря на все соображения здравого смысла при создании MIB-выражения, необходимо очень отчетливо представлять, что в действительности измеряет реализация SNMP данного поставщика.

В главе 11 из руководства Managing Your Network with HP OpenView Network Node Manager можно найти подробную информацию о написании и использовании MIB-выражений.

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

Простейшим способом просмотра исторических данных SNMP является выделение интересующего устройства и выбора меню Performance:Display SNMP data:For Selected Nodes. Это приводит к появлению GUI xnmgraph, отображающего данные о производительности устройства, если они обнаруживаются в базе данных.

Чтобы просмотреть реальные данные SNMP для нескольких устройств на конкретных интерфейсах, можно запустить приложение xnmgraph из командной строки. Например, чтобы получить диаграмму ifInOctets и ifOutOctets для экземпляров MIB 2-5 для node1 и node2, можно использовать команду

xnmgraph -mib \

"interfaces.ifTable.ifEntry.ifInOctets:In Bytes: [2-5] ::::::, \

interfaces.ifTable.ifEntry.ifInOctets:Out Bytes: [2-5] ::::::" \

node1 node2

Для вывода на печать собранных данных SNMP можно использовать приложение snmpColDump совместно с некоторыми скриптами. Предположим, что данные собираются с использованием snmpCollect в файле macDeferred.1. Чтобы вывести на печать среднее значение macDeferred.1 для node1, можно воспользоваться командой

snmpColDump $OV_DB/snmpCollect/macDeferred.1 |

awk -F\t `/node1/{num++; sum+=$3} END{print sum/num}'

Файл macDeferred.1 содержит исторические данные SNMP для всех узлов, и скрипт awk отфильтровывает данные для node1, подсчитывает суммарные значения, вычисляет среднее значение и отображает результат.

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

Пользователи, желающие просмотреть статистические данные SNMP в web-браузере, могут воспользоваться развитым Java-средством просмотра.

11. Предоставление данных о производительности потребителю

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

Если доступны исторические данные о производительности NNM, то может быть достаточно нескольких простых снимков экрана (см. "Получение мгновенных снимков схем"). Заметим, что стандартный фон окна xnmgraph имеет черный цвет, что подчеркивает цвета других линий. Цвет фона управляется ресурсом X-Windows, размещенным в файле ресурсов $APP_DEFS/XNmgraph. Результирующий файл следует передавать из среды UNIX системы NNM на рабочую станцию создателя презентации в бинарном формате.

Если предпочтение отдается текстовому представлению данных о производительности, то можно использовать утилиту xnmgraph для сохранения отображаемых данных в текстовом файле. Несмотря на то, что в среде UNIX не требуются и не распознаются расширения имен файлов, может оказаться целесообразным добавить расширение .txt специально для рабочих станций создателей презентаций, где эти расширения действительно нужны. Текстовый файл в формате ASCII следует передать из системы NNM на рабочую станцию создателя презентации. Текстовые данные, оформленные в виде столбцов, обычно импортируют в электронную таблицу или текстовый процессор, чтобы переформатировать ее для целей презентации.

Можно также использовать утилиту snmpColDump, чтобы сохранить в текстовом файле специальные данные SNMP о производительности.

13. 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.

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

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

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



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

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

Заключение

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

...