о насотзывыпубликациипартнерствовакансии

к выбору публикации

Увидеть слона целиком. Часть III

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

Программы для Управления Производительностью Приложений и Соглашение об Уровне Обслуживания

Попробуйте спросить у разработчика прикладной программы, может ли он сформулировать некие признаки, на основании которых можно сделать выводы о быстрой (хорошей) или, наоборот, медленной (плохой) работе его прикладной программы. Можете сформулировать вопрос и по-другому. Спросите, может ли он сказать, насколько возрастет время реакции его прикладной программы при увеличении загрузки канала связи, например, с 10% до 20% или процессора сервера с 50% до 70%? Вряд ли Вы получите конкретный ответ. Причина в том, что большинство отечественных прикладных программ не имеют встроенных средств, позволяющих измерить производительность их работы, т.е. являются неуправляемыми. Поэтому чаще всего неясно, что надо сделать, чтобы ускорить работу такой прикладной программы в сети.

В отличие от отечественных программистов, западные разработчики прикладных программ уделяют вопросам управляемости очень большое значение. Это явилось причиной того, что в настоящее время очень активно развивается сегмент рынка, который называется "ПО для управления производительностью приложений" (Application Performance Management, APM). В основе этих средств лежит, так называемое, "соглашение об уровне обслуживания или Service Level Agreement, SLA". Бизнес-концепцию SLA можно проиллюстрировать на следующем примере.

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

Цель Соглашения очевидна. Для пользователя важны не только функциональные возможности, но и производительность прикладной программы. Медленно работающие программы психологически плохо влияют на пользователей, в результате чего они быстро устают, часто ошибаются, что сказывается на производительности их труда. Если прикладная программа в режиме "on line" обрабатывает заявки клиентов, то пока программа "думает", ваша компания может "терять деньги". Кроме этого, вы хотите быть уверены, что для удовлетворительного быстродействия прикладной программы не нужно будет тратиться на приобретение нового сервера или установку новой сети.

Для заключения "Соглашения об Уровне Обслуживания" нужно не только уметь измерять производительность (время реакции) прикладной программы, но и уметь определять, как время реакции зависит от характеристик работы информационной инфраструктуры (утилизации сети, сервера, числа ошибок и т.п.) Одним из способов решения этих задач является технология "SLa-ON", о которой мы хотим вам рассказать. Данная технология разработана компанией ProLAN, Inc и является первой отечественной технологией подобного рода.

Технология SLa-ON - средство для реализации "Соглашения об уровне обслуживания"

Технология SLa-ON - это набор диагностических средств и методика их использования, позволяющие, во-первых, сформулировать и проконтролировать выполнение "Соглашения об уровне обслуживания", и, во-вторых, определить, как быстродействие пользовательских программ зависит от характеристик работы информационной инфраструктуры (утилизации сети, сервера, числа ошибок и т.п.). Все это позволяет понять: Как прикладная программа должна работать в сети? Как прикладная программа реально работает в сети? Почему прикладная программа реально работает не так, как должна?

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

-	Диагностические средства, контролирующие работу прикладных программ.
-	Диагностические средства, контролирующие работу сети.
-	Средства интеграции данных о работе прикладных программ и о работе сети.

Диагностические средства контроля работы прикладных программ

Контролировать работу прикладной программы можно по-разному. Первый метод основан на использовании средств, анализирующих работу прикладной программы без доступа к ее коду. В рамках этого метода возможны несколько способов измерения производительности работы прикладной программы. Это "извлечение" информации о работе прикладной программы из сетевого трафика (network sniffing), анализ работы клиента (client capture) и выполнение синтезированных транзакций (transaction simulation).

Второй метод основан на встраивании в прикладную программу специальных "датчиков", делающих программу управляемой. Этот метод считается более эффективным, чем первый. Это напоминает SNMP агенты, которые встраиваются в активное сетевое оборудование. Именно этот метод положен в основу технологии SLa-ON. Он означает, что сам разработчик прикладной программы должен объявить (определить) те операции прикладной программы, время выполнения которых является значимым с точки зрения быстродействия программы и, поэтому, должно контролироваться. Такие операции прикладной программы будем называть SLA-событиями. События объявляются разработчиком с использованием специализированной программной библиотеки. Такая библиотека разработана компанией ProLAN, Inc и называется SLа-ON^TM API.

Технология SLа-ON^TM позволяет определить три типа SLA-событий: "многочисленные", "единичные" и "сообщения". Многочисленные SLA-события - это многократно выполняемые прикладной программой операции. К многочисленных событиям можно отнести, например, поиск записи в базе данных, чтение или запись порции данных с диска, возможно, часто повторяющуюся транзакцию и т.п. Единичные SLA-события - это редко встречающиеся события. Например, открытие и закрытие базы данных, формирование отчетного документа. Сообщениям могут соответствовать "метки" в работе программы. Например, возникновение и обработка каких-то ошибок.

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

Прикладная программа, используя вызовы функций SLа-ON^TM API, взаимодействует со специализированным диагностическим приложением, которое называется SLа-ON^TM Agent. Это приложение должно исполняться на том же компьютере что и прикладная программа. Взаимодействие заключается в том, что прикладная программа информирует приложение SLа-ON^TM Agent о начале и завершении каждого SLA-события, а приложение SLа-ON^TM Agent вычисляет длительность этих событий. Таким образом, технология SLа-ON^TM предлагается два основных средства контроля работы прикладных программ. Это библиотека программного интерфейса SLа-ON^TM API и специализированное диагностическое приложение SLа-ON^TM Agent.

Приложение SLа-ON^TM Agent решает две задачи. Во-первых, оно создает отчет о работе прикладной программы. Ниже мы расскажем, как этот отчет используется для решения сформулированных в начале статьи задач. Во-вторых, это приложение осуществляет контроль текущего быстродействия прикладной программы.

Информация о текущем быстродействии прикладной программы имеет вид небольшого popup-индикатора в виде "светофора". "Светофор" индицирует текущее быстродействие одним из следующих сигналов: красным, красным мигающим, желтым мигающим, желтым, зеленым. Смысл каждого цвета очевиден. Собственно это и является ответом на вопрос: "Как реально работает прикладная программа". Чтобы приложение SLа-ON^TM Agent в нужный момент зажигала нужный свет, ему необходимо "сказать", в какой момент, какой свет нужно зажигать. Это делается с помощью, так называемых, SLa-ON профайлов, которые анализирует приложение SLа-ON^TM Agent.

SLa-ON профайл - это текстовый файл, составленный по принципу INI-файлов MS Windows и содержащий набор инструкций для оценки текущего быстродействия прикладной программы. В профайле определяются наборы условий для SLA-событий, которые соответствуют различным сигналам "светофора". Каждый набор условий может быть дизъюнкцией или конъюнкцией нескольких условий. Например, можно задать, что красный цвет будет гореть в том случае, время выполнения транзакции "А" больше 5 мс и транзакции "В" больше 10 мс или время выполнения транзакции "С" больше 1 мс и транзакции "D" больше 2 мс. Если ни одно из заданных условий не выполняется, то на "светофоре" будет гореть зеленый свет.

Обратите внимание, что профайл есть не что иное, как формальное описание того, как должна работать прикладная программа. Поэтому, чтобы создать профайл, нужно знать, какая длительность каждого SLA-события является допустимой, а какая уже свидетельствует о наличии проблемы. Данная задача решается с на основе результатов статистической обработки файлов отчетов, созданных приложением SLа-ON^TM Agent. Статистическая обработка выполняется программой "Trend Analyst", о которой мы уже рассказывали в первой части статьи, когда рассматривали вопросы диагностики каналов связи. При статистической обработке вычисляются следующие параметры SLA-событий: минимальное значение, максимальное значение, среднее значение, среднеквадратическое отклонение от среднего значения, а также строится выборочная плотность вероятности (гистограмма). Таким образом, статистическая оценка позволяет однозначно определить, какие значения, с какой вероятностью принимает каждое SLA-событие.

		Рисунок 1. Статистическая обработка измеренного времени реакции типовых операций прикладной программы является основой для формирования SLA на данное приложение.

В качестве примера на рисунке 1 показана гистограмма значений времени загрузки документа из базы данных в программном пакете Инотек Склад (компания Инотек НТ), который поддерживает технологию SLа-ON^TM. Как видно из рисунка, наиболее вероятное значение этого времени лежит в диапазоне 200-240 мкс. Превышение данного времени сигнализирует о замедлении работы программы. Исходя из этого, формируются условия, записываемые в профайлы. Например, можно было бы рекомендовать, что красный сигнал должен загораться при значении времени отклика более 260 мкс, желтый - при значениях от 240 до 260 мкс и т.д.

С помощью программы "Trend Analyst" разработчик прикладной программы получает возможность исследовать, как работает его программа в различных условиях. Результатом такого исследования должен стать набор профайлов "на все случаи жизни". Предполагается, что этот набор разработчик поставляет вместе с прикладной программой или размещает на своем веб-сайте. Конечный пользователь или компания, внедряющая программу, выбрав подходящий для конкретного случая профайл, всегда будет знать, хорошо или плохо с точки зрения разработчика работает пользовательское приложение. Это и будет ответом на вопрос: "Как должна работать прикладная программа?" Таким образом, разработчик прикладной программы может сформулировать "соглашение об уровне обслуживания", а конечный пользователь проконтролировать его выполнение.

Мы не можем не сказать еще об одной функциональности, которую имеют прикладные программы, поддерживающие технологию SLа-ON^TM. Дело в том, что работу светофора видит не только пользователь, но и сама прикладная программа. Это означает, что прикладная программа в любой момент времени "знает", быстро или медленно она работает. Таким образом, разработчик прикладной программа может адаптировать алгоритмы работы программы в зависимости от текущей обстановки (загруженности сети, сервера и т.п.). Это очень важная функциональность, но более детальное ее рассмотрение является темой уже другой статьи.

Диагностические средства, контролирующие работу сети

В основу технологии SLа-ON^TM положен принцип "не изобретать велосипеда". Это означает, диагностика сети должна проводится с максимальным использованием имеющихся на рынке средств. В первую очередь, это должны быть диагностические средства, поставляемые вместе с сетевыми операционными системами. Если возможностей таких средств недостаточно, то технология SLа-ON^TM предлагает использовать программу ProLAN: Эксперт компании ProLAN, системы управления сетями, анализаторы сетевых протоколов.

Многообразие имеющихся на рынке диагностических средств можно условно разделить на три категории: анализаторы серверов, анализаторы каналов связи, анализаторы рабочих станций. Для каждой категории диагностических средств технология SLа-ON^TM предлагает базовое средство и одно или несколько вспомогательных средств. Использование какого-либо диагностического средства в технологии SLа-ON^TM означает, что результаты работы этого средства могут быть обработаны средствами интеграции данных о работе прикладных программ и о работе сетевой инфраструктуры, о которых будет сказано ниже.

В качестве базового диагностического средства для анализа работы серверов технология SLа-ON^TM предлагает использовать программы, входящие в состав сетевых операционных систем. Такими программами являются Performance Monitor для MS Windows 2000/NT4 и stat.nlm для Novell NetWare. В качестве вспомогательных средств могут использоваться программы: Observer Suite компании Network Instruments и HP Open View NNM.

В качестве базового диагностического средства для анализа работы каналов связи сети технология SLа-ON^TM предлагает использовать программный пакет ProLAN: Эксперт компании ProLAN, Inc. В качестве вспомогательных средств могут использоваться: Observer и Observer Suite компании Network Instruments, HP Open View NNM, NetXRay компании Cinco Networks (сейчас Basic Sniffer компании Network Associates), LANalyzer for Windows компании Novell

В качестве диагностического средства для анализа станций, работающих в среде MS Windows, технология SLа-ON^TM предлагает использовать программу Performance Monitor. Операционные системы на рабочих станциях, отличные от MS Windows, в настоящее время технологией SLа-ON^TM не поддерживаются.

Средства интеграции данных о работе прикладных программ и о работе сети

Одной из наиболее интересных и важных задач является интеграция и совместная обработка данных о работе сети и прикладных программ. Решение этой задачи позволяет определить, что надо сделать, чтобы ускорить работу прикладной программы. Фактически это означает дать ответ на вопрос, "почему программа работает не так, как должна". В рамках технологии SLа-ON^TM основным средством для решения этой задачи является программа Trend Analyst компании ProLAN, Inc.

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

Программа Trend Analyst позволяет импортировать в единую базу данных информацию трех типов. Файлы отчетов, созданные приложениями SLа-ON^TM Agent. Эта информация характеризует работу прикладных программ. Лог файлы, являющиеся результатом работы таких диагностических средств, как MS Performance Monitor, HP Open View NNM, Observer и другие. Файл отчетов, являющиеся результатом работы программы ProLAN: Эксперт.

Программа Trend Analyst позволяет делать статистическую обработку всей информации, хранящейся в базе данных. Это означает, что по любой характеристике можно вычислить: ее минимальное значение, максимальное значение, среднее значение, среднеквадратическое отклонение от среднего значения, а также построить выборочную плотность вероятности. Ранее мы уже сказали, что статистическая обработка результатов работы приложений SLа-ON^TM Agent, позволяет определить граничные значения длительностей всех SLA-событий и, таким образом, сформулировать "соглашение об уровне обслуживания", касающееся быстродействия прикладной программы.

Статистическая обработка результаты работы программы ProLAN: Эксперт и лог файлов программ: MS Performance Monitor, HP Open View NNM, Observer, позволяет получить формальную интегральную оценку режима работы сети. Такая оценка также может использоваться в "Соглашении об уровне обслуживания", когда разработчику прикладной программы необходимо потребовать от пользователя конкретных характеристик быстродействия сети. Иначе разработчик не сможет гарантировать требуемого быстродействия прикладной программы.

Вычисление корреляционных зависимостей между характеристиками работы сети и характеристиками работы прикладных программ делает технологию SLа-ON^TM мощным аналитическим средством для локализации "узких мест, как сетей, так и самих прикладных программ.

Если длительность SLA-События условно назвать "функцией", а характеристики работы сети и сервера - "аргументами", то средствами программы Trend Analyst можно получить точные количественные оценки того, в какой степени каждая функция зависит от каждого аргумента или нескольких аргументов. Например, в какой степени время выполнения конкретной сетевой транзакции зависит от утилизации сети, числа ошибок передачи данных, утилизации процессора сервера и т.п.

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

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

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

На рисунке 3 показана вычисленная корреляционная зависимость между длительностью SLA-событий, характеристиками сервера и рабочих станций. Из рисунка наглядно видно, какие параметры наиболее сильно взаимосвязаны (эти взаимосвязи выделены красным цветом).

На рисунке 3 показана вычисленная корреляционная зависимость между длительностью SLA-событий, характеристиками сервера и рабочих станций. Из рисунка наглядно видно, какие параметры наиболее сильно взаимосвязаны (эти взаимосвязи выделены красным цветом).

Соглашение о качестве сети - неотъемлемая часть Соглашения об Уровне Обслуживания

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

Проверка исправности сети. Для проверки исправности сети необходимо и достаточно использовать три диагностических средства. Первое средство - это кабельный сканер, который локализует все явные дефекты кабельной системы. Второе средство - это программный пакет FTest. Третье средство - это анализатор протоколов, в состав которого входит экспертная система. Например, Expert Observer компании Network Instruments. Совместное использование пакета FTest и анализатора протоколов позволяет локализовать все скрытые и явные дефекты сетевой инфраструктуры.

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

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

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

Если разработчик программного обеспечения проведет такого рода измерения на нескольких сетях, где его прикладные программы работают хорошо, и предоставит эту информацию пользователю, то он даст пользователям своих программ некий ориентир, какой пропускной способностью, с его точки зрения, должна обладать сеть. Это уже сделали ряд российских компаний, например, 1С:Рарус, Интеллект-Сервис, Инотек НТ. Полученные ими результаты можно найти на веб-серверах этих компаний или на веб-сервере компании ProLAN (http://kb.netconsulting.ru/index.asp)

Недостатком рассмотренного способа является то, что в этом случае измерения проводятся без учета специфики сетевого трафика, характерного для конкретного пользовательского приложения. Поэтому, если необходимо измерить потенциальную пропускную способность сети с учетом типа трафика, то нужно воспользоваться другими методами. Одним из них является использование, так называемых, автоматических генераторов скриптов выполняющих синтезированные транзакции. В качестве примера можно привести пакет Visual Test компании Rational Software. В скрипт, созданный этим пакетом можно встроить вызовы SLа-ON^TM API и таким образом определить требуемую пропускную способность сети. Однако в ряде случаев, более целесообразно написать тестовый генератор трафика, который будет создавать в сети трафик, близкий к трафику пользовательского приложения.

Обращаем ваше внимание, что в последнем случае разработчику не нужно будет думать о том, как измерить пропускную способность сети при этом трафике. Ему достаточно лишь реализовать функциональную часть генератора трафика, и вставить в нужные места соответствующие метки с использованием библиотеки SLA API. Все необходимые измерения сделает приложение SLа-ON^TM Agent. Таким способом можно написать тестовые приложения, например, для приложений IP-телефонии, видеоконференций, клиент серверных приложений и т.п. Использование тестовых приложений в качестве инструментов для "входного контроля" потенциальной производительности сети облегчит жизнь, как разработчикам приложений, так и пользователям.

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

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

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

наверх