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

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

Управление бизнес приложениями клиента, работающими
в сети NSP

Все больше компаний начинают переносить свои бизнес приложения в сеть провайдеров услуг связи (NSP, Network Service Provider). Классическим примером такого переноса является создание корпоративной IP-телефонии, использующей арендуемые каналы связи. Чтобы сделать перенос "безболезненным", необходимо решить несколько важных задач: определить требуемое качество услуг, разграничить зоны ответственности, согласовать процедуры разрешения конфликтных ситуаций, организовать оперативное управление сбоями и т.п. Для эффективного решения этих задач необходим соответствующий инструментарий. В данной статье мы хотим рассказать о том, как эти задачи могут быть решены с помощью отечественной технологии SLa-ON компании ProLAN (www.prolan.ru/slaon).

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

В случае сетевого управления обычно контролируются параметры, характеризующие работу активного оборудования и каналов передачи данных: утилизация портов, число ошибок передачи данных, задержка передачи данных (delay), число потерянных пакетов (packet loss), разброс во времени прихода пакетов (jitter) и т.п. Главное то, что для измерения этих параметров используются программы, извлекающие данные из встроенных в активное сетевое оборудование агентов. Это могут быть SNMP-агенты или SAA-агенты (если используется оборудование компании Cisco Systems). Примерами таких программ являются Cisco Works компании Cisco Systems и Observer Suite компании Network Instruments.

В случае сквозного управления сетью контролируются характеристики работы не только оборудования и каналов связи, но и конкретных пользовательских приложений. Например, при сквозном управлении VoIP-сетью, обычно контролируются значения характеристики MOS (Mean Opinion Score), которая говорит о качестве телефонной связи. Если осуществляется управление ИТ-Инфраструктурой SAP R3, то может контролироваться время выполнения конкретных бизнес транзакций.

Существует несколько основных методов реализации сквозного управления сетью: Network Sniffing (анализ сетевого трафика), Client Capture (анализ данных на стороне клиента), Transaction Simulation (моделирование транзакций), Application Instrumentation (создание управляемых приложений). При использовании любого из этих способов в сети должно устанавливаться дополнительное оборудование или программное обеспечение. (Это одно из главных отличий сквозного управления от сетевого управления.) Подробнее об этих способах - см. Приложение "Четыре метода организации сквозного управления сетью".

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

Технология SLa-ON основана на трех идеях.

1.	Консолидация в реальном времени в единой БД характеристик, получаемых с использованием различных систем управления.
2.	Экспертный анализ в реальном времени консолидированных данных в соответствии с набором правил, настраиваемых пользователем.
3.	Математическая обработка консолидированных данных методами корреляционного, регрессионного и вероятностного анализа. Результатом обработки является информация о взаимозависимости между различными характеристиками, хранящимися в консолидированной базе данных.

Давайте рассмотрим, как технология SLa-ON может использоваться на этапах проектирования и эксплуатации корпоративной VoIP-сети.

Определение требуемого качества услуг

Первая задача, возникающая при проектировании VoIP-сети - это выбор NSP, который может обеспечить требуемое качество услуг за приемлемую стоимость. Обеспечить качество услуг - это гарантировать клиенту, что характеристики работы сети NSP не будут выше (или ниже) определенных пороговых значений. В процессе эксплуатации VoIP-сети эти характеристики должны контролироваться системой управления NSP. Для систем IP-телефонии такими характеристиками обычно являются: доступность канала связи (availability), задержка передачи данных в одну сторону (one way delay), число потерянных пакетов (packet loss), разброс во времени прихода пакетов (jitter). Поскольку качество услуг неразрывно связано с их стоимостью, клиенту необходимо иметь информацию о необходимом и достаточном качестве услуг.

Основным критерием для определения требуемого качества услуг является требуемое качество работы бизнес приложений. Например, для IP-телефонии - это требуемое значение MOS (Mean Opinion Score), измеряемое по пяти-бальной шкале. Известно, что если значение MOS ниже чем 3.6, то большинство пользователей VoIP-сети будут недовольно качеством связи. Характеристику MOS можно измерить только с использованием метода сквозного управления сетью, например, с помощью пакета Vivinet Manager компании NetIQ.

Чтобы на этапе проектирования VoIP-сети клиент мог определить, какие пороговые значения характеристик delay, packet loss и jitter ему необходимы (и достаточны), он должен знать, как значение MOS зависит от значений delay, packet loss и jitter. При этом ему необходимо знать эту зависимость для конкретной сети, конкретных типов кодеков, конкретной полосы пропускания и конкретных условий эксплуатации сети (для заданного числа одновременных телефонных разговоров, заданного уровня фонового трафика и т.п.). Напомним, что характеристика MOS и характеристики delay, packet loss и jitter измеряются с помощью различных программ.

В рамках технологии SLa-ON эта задача решается следующим образом. Средствами программы Trend Analyst данные, измеренные программами Vivinet Manager и Observer Suite (или Internetwork Performance Monitor), импортируются в общую базу данных и методом усреднения "привязываются" к общей временной шкале. Затем, с помощью функции корреляционного анализа, реализованной в программе Trend Analyst, определяется, в какой степени значение MOS зависит от значений delay, packet loss и jitter. Затем, с помощью функции регрессионного анализа, также реализованной в программе Trend Analyst, строятся графики зависимости значений MOS от значений этих характеристик. Пример такого графика показан на рис. 1.

		Рисунок 1. График зависимости MOS от Delay, построенный с помощью программы Trend Analyst.

Имея такие графики для всех характеристик работы сети NSP, легко определить требуемые пороговые значения, т.е. определить необходимое и достаточное качество услуг.

Оперативное управление сбоями

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

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

На площадке NSP устанавливается специальный Зонд, который в реальном времени анализирует данные системы управления NSP, характеризующие качество услуг, которое получает клиент. Зонд - это специальное приложение на базе SLa-ON агента. Для контроля качества услуг Зонд автоматически импортирует соответствующие метрики из базы данных системы управления NSP, обрабатывает их и создает интегральную оценку качества услуг (далее "светофор"). "Светофор" - это результат сравнения текущих значений характеристик работы сети с пороговыми значениями. Пороговые значения определяются на этапе проектирования сети или могут быть сформулированы в SLA (Service Level Agreement).

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

Чтобы иметь возможность управлять сбоями в работе бизнес приложения, необходимо сопоставить три вида "светофоров" (оценок): "светофор" качества работы бизнес приложения, "светофор" качества услуг NSP, "светофор" качества работы корпоративной сети клиента (за которую отвечает клиент). Два последних "светофора" создаются с помощью такого же Зонда, но только установленного в корпоративной сети клиента. В этом случае оценка качества работы бизнес приложения и качества работы корпоративной сети может проводиться двумя способами. Зонд может импортировать метрики работы сети и приложений из других программ (например, Observer Suite компании Network Instruments, AppManager или Vivinet Manager компании NetIQ), а может осуществлять все измерения сам.

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

		Рисунок 2. Отображение "светофоров" с помощью программы Web TrendViewer.

Управление сбоями, т.е. определение "виновника" сбоя и информирование ответственных специалистов, осуществляется с помощью экспертной системы (программы NPM Visor), входящей в состав технологии SLa-ON.

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

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

Контроль по требованию

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

Это не так. Технология SLa-ON позволяет организовать так называемый контроль по требованию, для которого не требуется наличия у клиента системы управления сетью (но требуется желание NSP предоставить клиенту такой контроль).

Каждый клиент получает в свое распоряжение свободную программу (SelFTrend и/или PageLoad Robot), которая представляют собой систему сквозного управления сети в миниатюре. Как и настоящая система управления, эти программы могут измерять время реакции сетевых сервисов (файлового, SQL, TCP, SMTP, POP3, HTTP и др.), собирать SNMP-статистику с активного сетевого оборудования, получать метрики работы серверов MS Windows NT4/2000/XP. Время реакции сетевых сервисов измеряется методом "моделирование транзакций". От "настоящих" систем управления эти программы отличают только ограниченные возможности по отображению измеряемых данных и ограниченные возможности по оповещению о возникновении сбоев.

Свободные программы могут отображать только текущие значения измеряемых данных и сигналы "светофора", а система оповещения позволяет посылать только win popup сообщения и запускать внешние программы. Все остальные измеряемые данные сохраняются на жестком диске. "Светофор" создается на основе сравнения измеряемых данных с пороговыми значениями, которые настраиваются. Пример "светофора" показан на рисунке 3.

		Рисунок 3. "Светофор" качества работы сети, реализованный в программе SelFTrend.

С помощью свободных программах SelFTrend и PageLoad Robot клиент может организовать постоянный контроль качества получаемых услуг и контроль качества работы своей сети. Если качество работы сети начнет ухудшаться, то сигнал "светофора" изменится и клиент получит соответствующее win popup сообщение. Чтобы выяснить кто в этом виноват, клиент должен отослать NSP файл с результатами измерений (тот файл, который сохраняется на диске). Получив файл, NSP импортирует его в консолидированную базу данных и сопоставляет со статистической информацией о работе своей сети. (Это делается автоматически с помощью функции корреляционного анализа, реализованной в программе Trend Analyst.) В результате этого NSP получает достоверную информацию о том, в чем причина сбоя. Таким способом NSP и клиент могут наладить конструктивное взаимодействие, основанное на объективных данных о работе сети, а не на субъективных ощущениях об этом.

Приложение "Четыре метода организации сквозного управления сетью"

Если необходимо контролировать качество работы бизнес приложений, то обычно используется технология сквозного управления сетью. Существует четыре основных метода организации сквозного управления: Network Sniffing (анализ сетевого трафика), Client Capture (анализ данных на стороне клиента), Transaction Simulation (моделирование транзакций), Application Instrumentation (создание управляемых приложений).

Метод "анализ сетевого трафика" основан на извлечении информации о работе приложений из сетевого трафика. Для этого в сети устанавливаются специальные Зонды, которые в реальном времени захватывают весь проходящий мимо них трафик и извлекают из него информацию о работе приложений. Достоинство данного метода в его универсальности. Недостаток - плохая масштабируемость и высокая стоимость, т.к. для возможности декодирования в реальном времени всех сетевых протоколов Зонды должны иметь высокую вычислительную мощность. Именно поэтому такие Зонды являются, как правило, специализированными аппаратными устройствами. Примером такого устройства является NetScout WAN Probes, компании NetScout (www.netscout.com).

Метод "анализ данных на стороне клиента" основан на извлечении данных о работе приложений из операционной системы компьютера, где работает приложение. Для этого на компьютере пользователя устанавливается специальный Агент, который отслеживает взаимодействие приложения и ОС, и таким образом извлекается информация о работе приложения. Привлекательность данного метода в его универсализме. Недостаток - дополнительные накладные расходы на компьютере пользователя. Данный метод реализован, например, в программном пакете VitalSuite компании Lucent (www.lucent.com)

Метод "моделирование транзакций" основан на использовании программных Роботов, эмулирующих работу пользователей приложения. Робот - это специальная программа, которая выполняет в сети синтезированные транзакции и измеряет время их выполнения. Достоинство этого метода заключается в его доступности, а также в том, что он позволяет оценивать производительность приложений с точки зрения пользователей. Этот метод используется в большом числе различных продуктов, в частности, в пакетах AppManager и Vivinet Manager компании NetIQ (www.netiq.com) и пакете ProLAN: Эксперт компании ProLAN (www.prolan.ru/npmanalyst).

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

наверх