ПО для управления производительностью приложений

Подобный термин мог скорее сорваться с языка магистра делового администрирования, чем сетевого администратора.

Сегодня APM — это и практическая концепция, и развивающаяся технология. Она исходит из признания того факта, что конечных пользователей интересует только получаемый сервис. Взять для примера систему электронной коммерции. Если после щелчка на ссылке для отправки заказа пользователь не получит ответа через 10—15 секунд, то скорее всего он займется чем-нибудь другим. По чьей вине произошла задержка — провайдера Internet, неисправного маршрутизатора или низкоскоростного канала — потребителя это не интересует.

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

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

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

БИЗНЕС-КОНЦЕПЦИЯ

Прежде всего мы более внимательно рассмотрим практические потребности бизнеса, вызвавшие к жизни появление концепции APM. Управление производительностью приложений начинается с того же, что и успешное управление уровнем сервиса, — с определения организациями того, какие бизнес-процессы наиболее важны (см. статью «Вокруг SLA» в этом номере). Например, компания может решить: «Наша страница Web должна быть доступна заказчикам». После этого ей потребуется определить конкретные характеристики сервиса, в частности: «Страница Web должна загружаться не более чем за 15 секунд в 98% случаев по рабочим дням и в 90% — по выходным». Без задания конкретных параметров сервиса всякое управление бессмысленно.

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

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

Традиционный инструментарий имеет также еще один крупный недостаток, который лучше всего выражает следующая английская поговорка: «Любая проблема кажется гвоздем, когда есть молоток». Другими словами, при наличии отличного инструмента для измерения пропускной способности вы можете поддаться искушению считать своей главной проблемой недостаточную пропускную способность, тогда как в действительности причина проблемы может быть иной (например, неэффективное программное обеспечение или загрузка пользователями компьютерных игр в рабочее время).

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

Программное обеспечение для управления производительностью приложений — это подмножество так называемого бизнес-ориентированного управления сетью (Business-Oriented Network Management, BONM). Этот термин был предложен компанией Bear Stearns (http://www.bearstearns.com) в сентябрьском отчете за 1998 год, где она определяет BONM как «программный инструментарий, помогающий администраторам ИТ в измерении и повышении сквозной производительности их сетей, а также производительности с точки зрения конечных пользователей».

С тех пор, по словам Боба Лама, вице-президента Bear Stearns и соавтора отчета в качества аналитика, «BONM стал стандартным акронимом в отрасли. Он охватывает такие понятия, как диагностирование и мониторинг, управление пропускной способностью, анализ, управление SLA. APM принадлежит к их числу».

Уинстон Бампас, соавтор «Основ управления приложениями» (W. Bupmus, R. Sturm, Foundations of Application Management, Wiley, 1999, ISBN 0-471-16916-1) и президент рабочей группы по управлению настольными системами (Desktop Management Task Force, DMTF), говорит о прикладном программном обеспечении следующее: «Оно правит всем нашим бизнесом, но из-за постоянного давления на разработчиков со стороны рынка, стремящегося получить его как можно скорее, оно создавалось без расчета на управляемость. В итоге мы создали целое поколение неуправляемого программного обеспечения».

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

Программное обеспечение APM функционирует на том же уровне, что и мониторинг. Оно использует традиционные стандарты для мониторинга за производительностью сети SNMP и RMON и создается зачастую на их основе с использованием базы управляющей информации Application Response Time, предложенной NetScout (http://www.netscout.com). В некоторых случаях применяется также Application Response Measurement (ARM) API, разработанный Tivoli. (Дополнительную информацию о стандартах для APM смотри во врезке «Базовые стандарты».)

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

При всей важности подобного различия общая методология конкретного инструментария APM куда более существенна. Как говорит аналитик из IDC Элизабет Рейндж, «при выборе продукта вы должны первым делом обратить внимание на статистику, которую он предоставляет, а затем понять, откуда он в действительности получает данные. Насколько хороши окажутся эти продукты, зависит во многом от того, какие средства поддерживает ваша сетевая инфраструктура».

СЕТЕ-ЦЕНТРИЧЕСКИЙ ИНСТРУМЕНТАРИЙ

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

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

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

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

Одним из примеров подобного решения может служить семейство продуктов NetScout. Оно включает множество зондов для мониторинга разделяемых и коммутируемых локальных сетей, глобальных сетей и каналов frame relay. Кроме того, им используется SNMP, RMON-1 и 2, а также расширение MIB от NetScout. Программное обеспечение NetScout Manager позволяет декодировать 11 протоколов на всех семи уровнях. Оно имеет также средства составления отчетов в общекорпоративном масштабе.

Другое преимущественно сете-центрическое решение — EcoScope от CompuWare (http://www.compuware.com). EcoScope использует программные зонды, правда, они называются Super Monitors и выполняются на установленных в определенных местах ПК с работающими в режиме приема всех пакетов сетевыми платами. Без какой-либо предварительной конфигурации эти зонды могут автоматически обнаруживать сетевые устройства и составлять топологическую карту сети. EcoScope позволяет распознавать сотни приложений; как и NetScout, он анализирует пакеты с типичными запросами и ответами для определения реальной производительности приложения.

Еще одним важным игроком в этом секторе рынка является Network Health от Concord Communications (http://www.concord.com). В отличие от вышеупомянутого инструментария, Network Health специализируется не на предоставлении информации в реальном времени, а на определении тенденций: данные собираются за продолжительный период времени для составления подробного отчета об использовании ресурсов.

Сете-центрический инструментарий со сбором пакетов является в настоящее время наиболее распространенным подходом к APM, поэтому я просто не в состоянии рассмотреть здесь все предлагаемые продукты. Ограничусь просто перечислением названий продуктов, производителей и их серверов Web: Visualizer от Apptitude (http://www.apptitude.com), Patrol от BMC (http://www.bmc.com), Viewpoint от Datametrics (http://www.datametrics.com), Vista View от InfoVista (http://www.infovista.com), NetClarity от LANQuest (http://www.lanquest.com), NetCool от Micromuse (http://www.micromuse.com), Application Insight от Optimal (http://www.optimal.com) и ProVision от Platinum Technology (http://www.platinum.com). Разумеется, это далеко не полный список.

СИНТЕЗИРОВАННЫЕ ТРАНЗАКЦИИ

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

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

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

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

Характерным примером продукта с использованием синтезированных транзакций является Chariot от Ganymede Software (http://www.ganymedesoftware.com). Этот продукт имеет библиотеку сценариев для имитации работы десятков популярных приложений. Недавно пополнивший семейство Chariot продукт Application Scanner представляет собой по сути современную развитую версию обычной программы для записи ввода с клавиатуры. С его помощью сетевой администратор может имитировать транзакции любого приложения, в том числе собственного заказного программного обеспечения компании, а затем сохранить их в виде сценария Chariot для последующего воспроизведения.

Другим примером может служить Chisel от Network Tools (http://www.networktools.com). Для создания заказных агентов тестирования он использует модель COM компании Microsoft. Например, вы можете создать программу для заполнения и отправки форм на сервер Web. Демонстрационную копию Chisel для тестирования Web можно загрузить с сервера Web компании.

VeriServ от Response Networks (http://www.responcenetworks.com) имеет целый ряд компонентов, в том числе VeriServ Agents, имитирующих действия конечных пользователей и генерирующих множество разнообразных транзакций. Фактическим его аналогом, но с большим уклоном в сторону стрессового тестирования, является Active Measurement от Bluecurve (http://www.bluecurve.com). Эта технология предназначена исключительно для тестирования Windows NT и предполагает измерение типичной производительности с последующим определением точки насыщения, за которой производительность резко снижается. Такого рода тестирование представляет проактивный подход к определению того, сколько пользователей в состоянии обслуживать ваша инфраструктура.

NexPoint (http://www.nextpoint.com) предоставляет широкий спектр функций, включая полный набор средств сбора данных SNMP, RMON и RMON-2. И этот продукт определяет типичные характеристики сетевого трафика с последующим извещением администратора в случае необычно высокого спроса или, наоборот, когда по каким-то причинам что-то, что должно было произойти, не произошло, например ежесуточное запланированное копирование в три часа ночи. Наиболее привлекательна в этом продукте технология синтезированных транзакций NextPoint, написанная для тестирования критических сервисов IP, таких, как DNS, POP3, SMTP и HTTP.

Другим продуктом с использованием синтезированных транзакций является семейство Silk от Segue Software (http://www.segue.com).

Наконец, хотя это и выходит за рамки управления производительностью приложений, я хотел бы упомянуть Comnet III от CACI (http://www.caciasl.com). Этот готовый пакет доводит «синтез» до его логического завершения посредством моделирования всей сложной сети только с помощью программного обеспечения. Очевидно, подобное приближение аккуратно настолько, насколько точно оно воспроизводит вашу физическую сеть. Comnet III предлагает обширную библиотеку для моделирования реальных маршрутизаторов, коммутаторов, каналов и т. д. Он может также импортировать файлы с информацией о топологии и трафике из имеющихся систем управления сетью.

КЛИЕНТ-ЦЕНТРИЧЕСКИЙ ИНСТРУМЕНТАРИЙ

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

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

Недостатки представляются столь же очевидными: клиент-центрическому инструментарию необходимо предоставить ресурсы (ЦПУ, память, место на диске) на каждом клиенте. Кроме того, эти инструменты требуется вначале установить. (Многие производители решают последнюю задачу посредством ее автоматизации с помощью стандартных средств Systems Management Server (SMS), Tivoli или Computer Associates.)

Типичный представитель этой группы — FirstSense Enterprise (http://www.firstsense.com), собирает информацию от агентов Win-32 или Solaris и передает ее как приложению на консоли — для мониторинга в реальном времени, так и в базу данных SQL. FirstSense может автоматически определить, когда конкретный пользователь не получает требуемый уровень обслуживания. После этого он более внимательно изучает поступающую в реальном времени информацию о транзакциях данного пользователя. Как и многие другие инструменты, описанные в этой статье, FirstSense предназначен главным образом для приложений для работы с базами данных. Он поддерживает Oracle и Sybase, а также приложения, созданные с помощью PowerBuilder, Visual Basic и ODBC.

Еще одно решение в общем-то для тех же баз данных предлагает Landmark (http://www.landmark.com) в своем PerformanceWorks SmartWatch c агентами для клиентов Windows 95 и NT. Чрезвычайно простой в использовании, он позволяет вам определить, за какими транзакциями (или подтранзакциями) следует осуществлять мониторинг с центральной станции SmartWatch. Затем транзакция разбивается на редактируемые сценарии, представляющие все ее события, такие, как выбор раскрывающихся меню, нажатие кнопок и т. п. Для запуска сбора информации об этой транзакции на клиентском компьютере имя клиента достаточно отбуксировать в определенную папку.

International Networks Services (INS) сочетает программное обеспечение для мониторинга сети с технологией VitalSigns (http://www.vitalsigans.com), которую INS приобрела в прошлом году. Краеугольным камнем семейства VitalSuite является настольный агент VitalAgent. Как утверждается, он способен отслеживать любые транзакции пользователя по локальным и глобальным каналам. Как заявляет INS, VitalAgent полезен не только для баз данных, таких, как Oracle или SAP, но и для контроля, например за работой с электронной почтой.

Если VitalAgent пытается расширить охват клиент-центрического программного обеспечения, то некоторые другие решения намеренно сужают его. Например, Appliant (http://www.appliant.com) создала Appvisor for Microsoft Exchange с клиентским компонентом, специально предназначенным для мониторинга за клиентами Outlook 97, Outlook 98 и Exchange 32. Никакой код на сервер Exchange инсталлировать не требуется, однако при этом Appvisor выполняет весьма точные измерения задержки в клиент-серверных транзакциях.

ПЕРСПЕКТИВЫ

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

Между тем все эксперты сходятся в том, что программное обеспечение APM будет развиваться и применяться как отдельная категория продуктов. «Я не думаю, что они будут поглощены платформами управления, — считает Рейндж из IDC. — Потому что эта область продолжает очень быстро развиваться, а это требует несвойственной для производителей платформ оперативности. Этот год должен стать годом стремительного роста данного сектора рынка, когда многие мелкие компании смогут заявить о себе». Боб Лэм из Bear Stearns говорит проще: «Я не думаю, что у производителей платформ есть необходимая технология».

Уинстон Бампас утверждает, что ключевым моментом станет контроль программного обеспечения с помощью ARM, когда пользователи научатся его требовать. «Ничего не делается сразу, — поясняет он. — Пятнадцать лет назад вы могли купить широко известное программное обеспечение, не имеющее программы инсталляции. Увидев автоматические инсталляторы, люди тут же захотели иметь их. Думаю, что с контролем и измерением характеристик работы программного обеспечения будет то же самое».

В любом случае у APM хорошие перспективы, даже если администраторы ИТ устанавливают их в качестве меры предосторожности. Они могут думать так же, как магистры делового администрирования, а могут и иначе, но они уже давно получили свои полоски «CYA».

Джонатан Эйнджел — старший редактор Network Magazine. С ним можно связаться по адресу: jangel@mfi.com.