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

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

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

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

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


Rambler's Top100

  

Принципы и средства SLM

Брюс Бордман

Управление уровнем обслуживания (Service Level Management — SLM) призвано существенно повысить эффективность работы отделов информационных технологий на предприятиях. В последнее время этот процесс настойчиво рекламируют в качестве нового подхода к управлению информационными службами, и сейчас практически уже все программы сетевого управления имеют в своем составе средства мониторинга работы сетевых служб и приложений. Видя рекламную шумиху вокруг SLM, охватившую рынок, вы можете подумать, что совершаете большую ошибку, не сформулировав и не заключив до сих пор соглашение об уровне обслуживания — (Service Level Agreement — SLA), которое определяет необходимые вам уровни качества обслуживания.

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

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

SLM не новая концепция. Она появилась в то время, когда пользователи больших ЭВМ стали настаивать на необходимости слежения за их доступностью и временем отклика. Централизованная обработка данных на больших ЭВМ и предсказуемость параметров работы протокола SNA позволили без особых проблем реализовать эту функцию. К сожалению, в среде клиент—сервер с распределенной обработкой данных, недетерминированными (коллизионными) протоколами и разрозненными средствами управления реализовать контроль за уровнем обслуживания значительно сложнее. Чтобы справиться с этим, мы рекомендуем среду клиент—сервер условно разделить на следующие элементы: клиент, сеть, сервер, база данных и приложение. SLM включает в себя установку, мониторинг работы этих элементов и диагностику их отказов, а также планирование развития среды для обеспечения необходимого уровня обслуживания пользователей.

Чтобы удачно реализовать систему SLM, вам сначала надо понять, на чем делает деньги ваша компания (или ваш клиент) и какое влияние на этот процесс могут оказать информационные технологии. Без этого вы не определите перечень услуг, параметры которых следует нормировать в SLA. Консультантов, готовых помочь с организацией SLM, найти очень просто, но не торопитесь обращаться к ним. Первоначальный анализ эффективности работы информационных служб предприятия правильнее сделать силами его собственных специалистов: они лучше знают специфику бизнеса своего предприятия.

Разговор на одном языке

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

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

Часто бывает важно правильно определить не только контролируемые параметры, но и место (в системе клиент—сервер) проведения контрольных измерений. Многие средства SLM, осуществляющие мониторинг работы сетевых служб на сервере, рекламируются как обеспечивающие “сквозное”, или полное (end-to-end), управление уровнем обслуживания пользователей. Это не соответствует действительности, так как нельзя получить адекватное представление о качестве предоставляемых пользователям услуг, собирая соответствующие данные в одной удаленной от них точке сети. В то же время более предпочтительное размещение измерительного инструментария на конечных узлах сети стоит дорого и может оказаться неоправданным, если контролируемый таким образом процесс не имеет достаточно большого значения для экономической эффективности предприятия.

Вообще говоря, специалисты по информационным технологиям должны предлагать не просто технологические возможности по обработке данных, а системные решения, ориентированные на решение основных задач своего предприятия. Только уяснив для себя, что нужно вашему предприятию для успешного ведения бизнеса, можно правильно определить перечень контролируемых параметров услуг и должным образом составить SLA (см. “Рекомендация по составлению SLA”).

В этом деле вам могут помочь внешние консультанты по составлению SLA. Впрочем, особенно полагаться на них не стоит: они “нарисуют” детальную картину будущего процесса SLM, но, когда придет время реализовать его, вряд ли будут рядом. Однако это совсем не означает, что внешние консультанты абсолютно бесполезны. Важность системы SLM в том, что она затрагивает интересы разных отделов предприятия или даже разных предприятий (поставщика и потребителей), поэтому свежий взгляд со стороны на ее организацию может оказаться очень полезным.

Анализируем продукты

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

В данный момент самые полные средства SLM поставляют фирмы, производящие мощные интегрированные пакеты управляющих программ. Среди них стоит отметить компанию Hewlett-Packard, которая недавно приобрела фирму Prolin Software и включила в свой пакет OpenView ее SLM-продукт IT Service Manager. Он соответствует принципам управления уровнем обслуживания, изложенным в наборе документации ITIL (Information Technology Infrastructure Library).

Однако мощные интегрированные пакеты слишком сложны и громоздки, и не исключено, что далеко не все их функции действительно нужны вам. Чтобы успешно отделить “зерна от плевел”, обратитесь за помощью к производителю пакета. Например, как заявляет компания Hewlett-Packard, она предлагает покупателям только те продукты, которые решают необходимые для их бизнеса конкретные задачи управления. Иными словами, она не настаивает на том, чтобы в каждое решение входило, к примеру, приложение OpenView Network Node Manager. Hewlett-Packard вполне может предложить вам только программу управления ресурсами.

Другим многофункциональным продуктом для SLM, хотя и не таким мощным, как OpenView, является пакет Empirical Suite фирмы Empirical Software. В нем имеется модуль Empirical Planner, выдающий подробные рекомендации по разработке SLA, изложенные в стиле рецептов поваренной книги.

Полное управление

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

Набор продуктов EcoSYSTEMS фирмы Compuware обеспечивает управление уровнем обслуживания в режиме реального времени. Как полагает Compuware, его должна устанавливать и эксплуатировать отдельная группа специалистов, производящая мониторинг работы приложений и являющаяся связующим звеном между сетевыми администраторами и разработчиками приложений. Эти продукты не осуществляют полной проверки работы сетевых узлов и не выявляют, например, отказавшие жесткие диски и “грязные” кэш-буферы. Вместо этого они предлагают набор функций управления обслуживанием на уровне клиента, сети и сервера. Программа EcoSCOPE (в составе EcoSYSTEMS), измеряющая производительность приложений, отслеживает их сетевой трафик по номерам портов TCP и именам открытых файлов.

Продукт COMMAND/POST, выпускаемый давнишним производителем SLM-средств фирмой Boole & Babbage (недавно слилась с фирмой BMC Software. — Прим. ред.), обеспечивает детальное и почти полное управление уровнем обслуживания. Для абсолютной полноты ему не хватает сетевой компоненты. Уже многие годы COMMAND/POST используется для мониторинга работы больших ЭВМ фирм Amdahl, Burroughs и IBM. С появлением систем клиент—сервер возможности этого продукта были расширены, и теперь он поддерживает коммуникационные контроллеры, мини-компьютеры, хост-машины Unix, серверы Novell и Microsoft, настольные компьютеры. Более того, с его помощью можно контролировать работу даже систем кондиционирования воздуха.

На противоположном “фланге” продуктов SLM находятся более простые пакеты: Pegasus фирмы Ganymede Software, VitalSuite (VitalHelp, VitalAnalysis, VitalAgent и др.) фирмы VitalSigns Software, VeriServ фирмы Response Networks, в которых реализована концепция “от стекла к стеклу” (glass-to-glass). Она предполагает оценку производительности приложений путем измерения временноўго интервала (задержки) между вводом команды с пользовательского компьютера и появлением на его дисплее результатов ее выполнения. Этот показатель является одним из важнейших для оценки уровня обслуживания конечных пользователей. Недостаток данных продуктов — отсутствие у них возможностей диагностики или очень незначительные такие возможности.

Продукт Pegasus периодически измеряет производительность сети, эмулируя трафик сетевых приложений. Программа VeriServ фирмы Response инсталлируется на сервере Windows NT и измеряет время задержки при передаче пакетов между клиентами и другими серверами. Для того чтобы распознать широко известные TCP/IP-приложения типа DNS, SMTP и FTP, Veri-Serv проверяет доступность определенных TCP-портов.

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

А как дела с приложениями?

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

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

Основными сторонниками API-подхода являются компании Tivoli и Hewlett-Packard, разработавшие API-интерфейс ARM (Application Response Measurement). Суть их идеи состоит в том, чтобы интегрировать в приложение специальный код, который будет обеспечивать измерение его производительности и диагностику отказов. Однако это потребует определенных усилий со стороны программистов и создаст дополнительную нагрузку на контролируемые приложения. Кроме того, компания Microsoft не собирается поддерживать ARM в своих приложениях и управляющих средствах.

Компании Microsoft и Optimal Networks для измерения производительности приложений предпочитают использовать транзакционный подход.

В продукте Visual Studio от Microsoft содержится трассировщик, с помощью которого можно оценивать эффективность кода контролируемого приложения, но этим (в плане SLM) возможности данного продукта и ограничиваются.

В программе Application Expert фирмы Optimal Networks реализован более сложный метод измерений. Для получения данных о производительности сетевого приложения в ней используются трассировочные файлы, получаемые с помощью сетевого анализатора Sniffer фирмы Network Associates. Программа фирмы Optimal позволяет определить время реакции сети на запросы пользователей в зависимости от ее параметров и других факторов.

В продуктах фирм Platinum Technology, Technically Elite и NetScout Systems для измерения производительности приложений используются средства мониторинга сетевого трафика. В средствах WireTap и TransTracker фирмы Platinum Technology задействованы фирменные программные зонды, а продукты фирм Technically Elite и NetScout Systems ориентированы на применение зондов RMON. В обоих случаях очень важно оптимально разместить эти зонды, что сделать не всегда просто. Достоинством перечисленных продуктов является то, что они не создают дополнительной нагрузки на клиентские машины и серверы.

Продукт Network Health фирмы Concord Communications выдает весьма подробные отчеты о работе сети, используя для их составления информацию из баз данных SNMP MIB II и RMON2. К сожалению, он не учитывает специфику работы конкретных приложений, но наличие подробных данных о загруженности сети всегда позволит определить, является ли она причиной плохой работы приложения.

Следующий подход к измерению производительности сетевых приложений поддерживается фирмами, разрабатывающими средства контроля за производительностью баз данных и серверов. Мониторы приложений баз данных, такие, как модули Knowledge Module, входящие в пакет Patrol фирмы BMC Software, функционируют с учетом специфики работы приложений фирм Oracle, PeopleSoft и SAP.

Подобно пакету Patrol, продукт фирмы Empirical Software контролирует уровни обслуживания, следя за работой серверных приложений. Он собирает информацию о потреблении ресурсов базы данных, ЦПУ и памяти сервера. Продукт успешно отслеживает транзакции приложений фирм Oracle, PeopleSoft и Baan.

Своеобразным мостиком между программами сетевого и системного управления является продукт Netcool/OMNIbus фирмы Micromuse. С его помощью собирается и обрабатывается информация о системных событиях, которую он получает от управляющих программ, а также от SNMP-устройств, офисных ATC, компьютеров с ОС Windows NT и других средств, способных создавать журнальные файлы. Данный продукт не надо конфигурировать, и в нем имеются широкие возможности по управлению выводом накопленной информации.

Продукт Continuity фирмы International Communications Software тесно интегрирован с платформой управления Spectrum фирмы Cabletron Systems. Он существенно улучшает ее механизм генерации предупреждающих сообщений.


срочное вступление в сро .Услуги для бизнеса от "СтройЮрист".




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

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

• Интернет — лекарство от кризиса?

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

• NetWare 5: что новенького?

• Сеть для домашнего использования

• Оптические соединения в СКС

• Как выбрать подходящую технологию ввода-вывода

бизнес

• Великий перелом в малом бизнесе

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

• Выбор среды разработки для Java

• Инструментальные наборы для дизайна Интернет-магазиновБарри Нэнс

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

• Принципы

• Шесть проектов корпоративной сети АТМ

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

• Качество обслуживания на сетях связи. Обзор рекомендаций МСЭ-Т

• Система сигнализации B-ISDN UNI 3.x: функционирование и тестирование. Часть II

• «Тупая сеть» как светлое будущее телекоммуникаций. Часть II

• АТМ в кадрах переменной длины

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

• Аудит сетей как фактор обеспечения безопасности информации

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

• Оптические коннекторы MT-RJ фирмы АМР на российском рынке



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