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

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

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

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

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

  • время реакции для интерактивных транзакций;
  • пропускная способность при передаче файлов и заданий на печать;
  • высокая доступность;
  • простота использования;
  • удобство.

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

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

  • интенсивность использования сетевой магистрали;
  • процентное отношение ошибок;
  • процентное отношение потери пакетов;
  • полное время работы утилиты ping.

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

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

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

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

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

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

Итак, очевидно, что SLA должно быть "настолько простым, насколько возможно, но не проще"1Эта цитата приписывается Альберту Эйнштейну. и базироваться на измеримых величинах. Например, можно договориться, что отдел IT обеспечит подключение к Internet таким образом, что интенсивность нагрузки не будет превышать 50% в 90% случаев при наличии менее 100 активных пользователей. Данные об интенсивности нагрузки легко получить с маршрутизатора через SNMP. Число активных пользователей нельзя измерить непосредственно с помощью SNMP. На самом деле, этот показатель трудно измерить должным образом, но его можно получить из журнала proxy-сервера брандмауэра или с маршрутизатора посредством его средства учета использования ресурсов IP. Каждый месяц на собраниях SLA представляется простая диаграмма, подобная той, которая показана на рис. 9.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 (см. рис. 9.4). Большинство администраторов NNM модифицирует этот скрипт, приспосабливая его к своим локальным нуждам и создает в UNIX периодически, например, ежечасно, выполняющееся задание cron.

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

увеличить изображение
Рис. 9.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 они более чем приемлемы.