Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

В поисках наилучшего подхода к мониторингу приложений

Брюс Бордман

Обычно пользователи получают уведомления об аварийной ситуации через свои приложения после того, как сбой уже случился. Чтобы предсказать, в каком месте в следующий момент может возникнуть очередная проблема, и был придуман мониторинг приложений. Несмотря на то что эта концепция не нова — мониторы времени отклика в больших ЭВМ уже давно зарекомендовали себя с лучшей стороны — в последние год-полтора число продуктов мониторинга приложений стремительно возросло. Отчасти это произошло благодаря всеобщему признанию Windows NT и тому, что в корпоративных сетях предпочтение все больше отдается протоколу IP.

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

ERP-приложения (Enterprise Resource Planning), Web-серверы или серверы базы данных. Некоторые из этих продуктов работают в режиме фоновой службы, осуществляя замер показателей производительности локального ПК, сети и сервера в реальном времени или согласно заданному расписанию.

Контроль может вестись из трех основных точек: с клиентских машин, сервера приложений и из сети (в виде зондов RMON). Со стороны сети контроль осуществляется по протоколу SNMP. Последней новинкой в области мониторинга производительности стали облегченные агенты, устанавливаемые на клиентских машинах или серверах. Поскольку существует два типа агентов — активные и пассивные — можно выделить и два типа мониторинга: активный, основанный на искусственной генерации передаваемых через сеть транзакций, пассивный — на регистрации событий, происходящих на локальном клиенте.

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

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

К сожалению, данный метод не учитывает условия эксплуатации сети, зато он имеет преимущество — централизованное измерение на сервере приложений.

Серверный метод позволяет собрать информацию, наиболее детально описывающую работу тех или иных приложений для их диагностики, настройки и прогнозирования их поведения. Приложения фирм Envive, Oracle и PeopleSoft благодаря средствам настройки позволяют учитывать особенности транзакций различного вида, например используемых в СУБД или в серверных прикладных процессах.

Менее сложными, но в то же время и менее специализированными в области мониторинга приложений являются такие продукты, как Patrol фирмы BMC Software, Performance Monitor фирмы Computer Associates и PerView фирмы Hewlett-Packard. Наряду с другими измерениями они в первую очередь ориентированы на регистрацию показателей операционной системы об использовании памяти, результативности обращений к кэшу, дисковым и сетевым устройствам ввода-вывода. Их роль в мониторинге приложений приобретает все большее значение. Если исходить из правильного предположения: раз операционная среда функционирует хорошо, так же хорошо работают и приложения, то к достоинствам данных продуктов можно отнести легкость их освоения и более простую, чем у специализированных серверных продуктов, методику контроля.

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

Тестирование производительности

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

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

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

Мы поместили зонд Apptitude в сегмент с пропускной способностью 100 Мбит/с, обеспечивающий соединение с Интернет по каналу Т3. Интенсивность трафика была так же высока, как и в остальной сети, и зонд регистрировал в среднем более 200 000 сеансов в час. В то же время централизованное приложение анализа позволяло обрабатывать лишь 140 000 сеансов в час. Добавленное на серверную платформу оборудование не изменило ситуацию, так как анализирующее приложение отнюдь не перегружало оборудование или операционную систему.

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

Если у вас нет абсолютной уверенности, какой метод предпочесть, подумайте об установке облегченного агента в свой ПК. С точки зрения клиента производительность приложения имеет смысл оценивать только в том случае, если вся промежуточная инфраструктура, сеть, серверы и локальные приложения работают исправно. Так называемые облегченные агенты отслеживают конечный результат транзакции и/или работоспособность приложения, а затем заносят результат на центральный сервер. Впоследствии результаты объединяются в консолидированную отчетность.

Сторонники пассивного метода отмечают, что он обеспечивает реальные замеры производительности с учетом особенностей клиентов в данной сети — типов используемых транзакций, времени дня, времени реакции пользователя и т. д. Единственный его недостаток — это разброс длительности транзакций. Число пакетов в реальных транзакциях постоянно варьируется, поэтому у вас не будет точных измерений сетевой производительности. Но это не означает, что вы вовсе не можете получить время ожидания. Например, пакет VitalSuite фирмы Vital Signs для вычисления времени выполнения транзакции использует пакеты с выставленным битом SYN.

Альтернативными являются продукты, использующие искусственные транзакции, которые либо запрограммированы, либо оперативно меняются пользователем и запускаются с удаленного агента по заранее намеченному графику. Это могут быть запросы ping или DNS, обращения по протоколу SMTP или такие специфические, как SQL-операторы или определяемые пользователем транзакции. Время их выполнения известно заранее, поэтому любое отклонение от его базовой величины будет означать ухудшение производительности.

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

Другая модификация метода искусственной транзакции включает использование и транзакции клиента, и сервера приложения. Продукт Pegasus фирмы Ganymede Software реализует именно такой подход. Несмотря на то что генерируемые им транзакции в реальных условиях не используются, они позволяют исключить влияние сетевой инфраструктуры на замеры производительности приложений.

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

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

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

Сетевая диагностика

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

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





  
12 '1999
СОДЕРЖАНИЕ

колонка редактора

• Вопрос на триллион долларов

локальные сети

• Мультимедийные розетки изменяются к лучшему

• Кабельные короба: когда стены и потолок непреодолимы

• Стандарты для заводских испытаний оптических кабелей

• Тестируем серверы NAS

интернет и интрасети

• Не пренебрегайте возможностью настроить TCP

системы учрежденческой связи

• Системы речевой почты

новые продукты

• Объединяя сети, Новая платформа

корпоративные сети

• Почтовые системы для предприятий проходят тесты SMTP

• В поисках наилучшего подхода к мониторингу приложений

• Магистральные маршрутизирующие коммутаторы: убедительные результаты в отсутствие грандов

услуги сетей связи

• Серверы удаленного доступа для небольших и средних предприятий

• Телекоммуникационные операторы нового поколения

• Создание мультисервисных сетей: задачи и перспективы

защита данных

• Отечественные средства построения для виртуальных частных сетей

• Как обеспечить конфиденциальность открытых ключей

• "Встроенная" пожароопасность трехфазных ИБП с однофазным выходом



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх