Журнал о компьютерных сетях и телекоммуникационных технологиях
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК:
    Домой
 
   
АРХИВ ЖУРНАЛА
   

2008: 1 2 3 4 5 6 7 8 9 10 11 12 13
2007: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2006: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2005: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2004: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2003: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2002: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2001: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2000: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1999: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1998: 1 2 3 4 5 6 7 8 9 10 11 12
1997: 1 2 3 4 5 6 7 8 9 10 11 12
1996: 1 2 3 4 5 6 7 8 9 10


Rambler's Top100

  

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

Майкл Биддик

Если вы когда-нибудь получали выволочку от разъяренных корпоративных пользователей по поводу медленной работы приложения, то должны понимать, что хороший пакет управления производительностью приложений (Application Performance Management — APM) стоит тех денег, которые просят за него поставщики. Сегодняшние приложения настолько сложны, что пакет APM необходим всем предприятиям, за исключением, может быть, самых маленьких. Между тем выбор подходящей системы APM является весьма трудным делом.

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

Те, кто уже «поиграл» с профессиональными системами управления производительностью, такими, как eHealth компании CA, OpenView Performance Insight компании Hewlett-Packard и Performance Manager компании BMC, стоят сегодня перед дилеммой: внедрять им специализированный пакет APM с нуля или «слепить» что-нибудь самим из нескольких уже имеющихся инструментальных средств? Если вы решите пойти по первому пути, то будьте готовы к тому, что вам придется обосновывать свое решение перед руководством и, что называется, вскрывать свою копилку, поскольку внедрение пакетов APM обойдется вам отнюдь не дешево: от 80 тыс. долл. до суммы более чем 1 млн долл. Чтобы помочь вам выбрать па-кет APM, мы решили протестировать несколько продуктов этой категории и определить, имеется ли среди них такой, который может превосходно собирать информацию и генерировать удобные отчеты.

Основные компоненты пакетов APM

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

ПО генерации синтетических транзакций. Такой компонент содержат пакеты компаний BMC, HP/Mercury, IBM Tivoli и Symantec. Оно размещается на ключевой системе сетевой инфраструктуры и генерирует трафик, имитирующий обращения пользовательского приложения, а затем генерирует отчет с результатами измерения производительности.

Сетевые зонды или анализаторы (network probes). Они входят в состав продуктов Wily компании CA и Foglight компании Quest Software и представляют собой физические сетевые устройства, обычно подключаемые к порту анализатора (Switched Port Analyzer) коммутатора. Они отслеживают и классифициру-ют трафик приложений, осуществляя мониторинг сеансов связи веб-приложений или трафика TCP.

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

Клиентские агенты широко используются, например, в продуктах компаний Compuware и HP/Mercury; размещаются на пользовательских машинах и осуществляют мониторинг производительности, используя интерфейсы API и сокеты TCP.

Системные агенты осуществляют глубинный анализ производительности аппаратного обеспечения клиентских систем и серверов и генерируют отчеты о производительности ЦПУ, дисковой подсистемы и других важных аппаратных компонентов. Системные агенты поддерживаются APM-пакетами компаний BMC, Compuware, Quest и других фирм.

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

Покупать или не покупать?

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

Заметьте, что очень часто спорадические, или «пропадающие», проблемы не фиксируются отчетами о производительности, хотя и оказывают на нее реальное влияние. Если вы подозреваете наличие каких-либо глубинных причин их возникновения, то вам необходимо обратиться за помощью к таким компаниям, как BMC, Keynote или Mercury, в качестве сервиса предоставляющим мониторинг трафика на основе синтетических тестовых пользовательских запросов.

Разрешение проблем требует понимания сложности приложений и таких взаимозависимых характеристик, как загрузка ЦПУ системного уровня, сетевая производительность, задержка отклика базы данных, и клиентские проблемы, каждая из которых по-своему отражается на работе приложений. Хотя многие организации осуществляют мониторинг тех или иных компонентов, лишь немногие из них могут контролировать сложные взаимосвязи между ними, что необходимо для понимания влияния, оказываемого локальными сбоями на систему в целом. Это как раз то, чем и занимается комплексный пакет APM.

Части одной головоломки

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

Производители продуктов, основанных на синтетических тестовых транзакциях, заявляют, что могут обнаруживать проблемы производительности в сценариях, в которых развертывание агентов является практически неосуществимым. Нас интересует, насколько хорошо они это делают. С другой стороны, некоторые компании используют устройства, отслеживающие и измеряющие время отклика на запрос пользователя в отсутствие агентов. Однако требуются ли вам клиентские агенты для того, чтобы реально определять тот момент, когда производительность становится для пользователя неприемлемо низкой? Если организация осуществляет мониторинг большинства компонентов своей прикладной среды, то имеет ли смысл внедрять комплексную архитектуру APM? Ясно одно: количественное определение прибыли на инвестиции в развертывание пакета APM может превратиться в реальную проблему, требующую немало сил и изобретательности.

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

Особые случаи

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

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

Стимулируемые специальным нормативным законодательством и такими стандартами, как ITIL v3 или ISO 2000, сервис-провайдеры обращаются к пользовательскому интерфейсу типа инструментальная панель (dashboard) для ИТ-менеджеров или к пакетам управления бизнес-сервисами, задействующим ПО APM. Подобный пользовательский интерфейс требует понимания функционирования приложений и лежащей в их основе инфраструктуры. И хотя контроль за отказами ИТ-инфраструктуры по-прежнему остается весьма существенным компонентом, он перестает быть центром внимания ИТ-руководства, поскольку для бизнеса принципиально важно предпринимать действия, направленные на предупреждение отказов.

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

  
2 '2008
СОДЕРЖАНИЕ

бизнес

• IP-коммуникации и операторы связи

• Как заслужить звание «лучшего работодателя»?

инфраструктура

• Особенности построения ЦОДа для оператора связи

• Планирование ЦОДа с нуля: выбор места размещения

• Точки доступа БЛВС: от «толстых» к «тонким» и снова на круги своя

информационные системы

• Обеспечь поддержку виртуализации или уходи

• Анализаторы речи для контакт-центров

• XenServer Enterprise — достойный вариант виртуализации

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

• Идеальная поисковая машина

сети связи

• Видеосервисы нового поколения

• IP-телефония: продвижение в некоммерческом секторе

• Windows Mobile 6 набирает обороты

• Нужны ли вам фемтосоты?

кабельные системы

• Оптические кабельные инфраструктуры: соединительное и распределительное оборудование

• На пути к 100-Гбит/с технологии Ethernet

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

• Рискованное дело

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

• Концентраторы абонентского доступа для сетей NGN; Разъемы Smart Quick-Fit компании Huber-Suhner


• Калейдоскоп


Реклама:
 Copyright © 1996-2008 ООО "Сети и Системы Связи". вверх