Измерение и контроль реальной производительности сети - идея отличная, но что управление уровнем сервиса означает на практике?
НЕОБРАБОТАННЫЕ ДАННЫЕ: ОТДЕЛЯЯ ЗЕРНА ОТ ПЛЕВЕЛ
Корреляция событий
Сложность, наверно, наиболее очевидное свойство современных сетей. Вряд ли кто-либо из администраторов не хотел бы знать, насколько сеть справляется с той задачей, для которой она создавалась. Целое множество продуктов и методик готово предоставить для этого разного рода управляемые сервисы. Но прежде, чем приобретать тот или иной продукт или применять ту или иную методику, необходимо понять концепцию, которую, будем на это надеяться, отрасль наконец-то приняла - концепцию соглашения об уровне сервиса.
Соглашение об уровне сервиса определяет, что пользователь - потребитель услуги - вправе ожидать от сервис-провайдера. В идеале условия соглашения должны быть тесно увязаны с практическими задачами, а не с абстрактными техническими величинами типа уровня ошибок.
Например, соглашение об уровне сервиса может определять, как долго пользователю придется ждать обновления экрана, после того как он нажал клавишу Enter, среднее время для размещения транзакции с указанием допустимой вариации и т. д. Оно может содержать также описание процедуры ремонта или замены неработающего оборудования и даже определять время восстановления после аварии.
Как и во всех других случаях, полностью понять рассматриваемую нами концепцию можно, только зная предысторию ее появления. В данном случае мы должны обратиться к миру мэйнфреймов и телефонии, именно оттуда берут начало многие ее составляющие. Использующие мэйнфреймы организации первыми стали применять соглашения об уровне сервиса со своими сообществами пользователей.
МЭЙНФРЕЙМЫ И ТЕЛЕФОНЫ
Соглашения об уровне сервиса для мэйнфреймов опирались зачастую на схемы взаимозачетов, в соответствии с которыми отдел ИТ пытался использовать рыночные механизмы для регулирования спроса на компьютерные ресурсы. Однако с распространением компьютерных ресурсов по всей организации, в том числе настольных компьютеров, локальных сетей, серверов подразделений, межсетевых устройств и линий глобальной сети, разработанные для мэйнфреймов учетные схемы оказались невостребованы. Теперь купить "железку" IBM на размер больше недостаточно для того, чтобы жалобы пользователей на слишком долгое время отклика прекратились.
В мире телефонии соглашения об уровне сервиса строятся, как правило, на основе тарифов. Таким образом, технические факторы, например время ответа телефона на другом конце линии после того, как последняя цифра телефонного номера набрана, учитываются в самом устройстве телефонных систем и в конечном итоге в ценовой политике для этой регулируемой среды.
Некоторые операторы связи предлагают гарантируемые услуги. Следствием предоставления гарантии является то, что если какая-либо сторона соглашения об уровне сервиса не выполняется, то оператор связи должен возвратить часть суммы. Телефонные компании проводят различия по классу услуг во многом тем же образом, что и авиакомпании по первому классу, бизнес-классу и эконом-классу (лучшие классы стоят, естественно, дороже).
Некоторые сетевые протоколы, прежде всего APPN (Advanced Peer-to-Peer Networking) и SNA, предусматривают поле класса услуг в каждом пакете. Вообще говоря, IP имеет редко используемое поле типа сервиса (Type of Service, TOS), и в принципе оно может применяться для задания приоритета того или иного типа трафика.
Наиболее часто, однако, для дифференциации пакетного трафика используется термин "качество услуг" (Quality of Service, QOS). Типичными параметрами QOS являются процент потерянных кадров или ячеек, задержка трафика и вариативность задержки. В маршрутизируемых сетях качество услуг обеспечивается, как правило, за счет манипуляции выходными очередями в зависимости от адресной информации, типа протокола, номера порта и других факторов. ATM разрабатывался специально для поддержки нескольких классов услуг, причем они различаются по качеству предоставляемых каждым классом услуг.
РАСПРЕДЕЛЕННЫЕ СИСТЕМЫ
Характеристики сервиса, которые организации хотели бы измерять в своих сетевых системах, не так уж отличаются от тех, что используются в случае мэйнфреймов и телефонных сетей. Основные категории здесь производительность и доступность. Производительность характеризуется коэффициентом использования ресурсов или количеством заданных событий за определенный промежуток времени; а доступность - наличием или отсутствием сервиса.
Проблема в том, что инструментарий управления сетями и системами нацелен по большей части на предоставление информации о конкретных устройствах или конкретных сегментах сети. Нахождение всех компонентов, имеющих отношение к конкретному клиент-серверному приложению, само по себе весьма проблематично. Например, представьте себе систему ввода заказов на базе Web. В этом случае мы имеем сервер базы данных, обновление информации на котором происходит в результате выполнения сценария CGI на сервере Web. Перебой в работе или замедление любого из этих серверных процессов, операционных систем, аппаратных платформ, клиентского программного или аппаратного обеспечения, промежуточного брандмауэра, маршрутизатора или линии связи, связывающих эти компоненты вместе, может сказаться на доступности или производительности приложения. Более того, ответственность за работоспособность этих компонентов может быть возложена на различные лица или даже на различные организации. А бизнес-процесс в целом может предусматривать использование нескольких приложений: зачастую ввод заказа связан, например, с обращением к каталогу товаров, и процесс прохождения заказа может остановиться, если покупатель не в состоянии определить, есть ли на складе нужный ему товар.
Путь к успешному управлению уровнем сервиса начинается с определения организацией критичных бизнес-процессов. Организации, постоянно совершенствующие или применяющие тотальное управление качеством сервиса для улучшения бизнес-процессов, будут иметь здесь преимущество - понимание реальных процессов зачастую сложнее составления формальных графиков и описаний работ для структурирования деятельности организации.
Разделение традиционных областей деятельности на строго определенные процессы может потребовать немалых усилий, но по завершению этой задачи вы без труда определите необходимые для каждого процесса приложения. Из данной группы вы должны будете выделить устройства и средства связи, без которых процесс не работает; производительность критичных для процесса приложений и доступность этих компонентов являются исходным материалом для разработки целей и соглашений об уровне сервиса.
Управление уровнем сервиса вряд ли имеет смысл, если вы не ставите перед ним конкретных целей. Устройства и приложения могут включаться и отключаться без каких-либо последствий, пока кто-либо не скажет: "Приложение для ввода заказов должно быть доступно 99% времени между 8.00 и 18.00 по рабочим дням при времени отклика менее одной секунды".
Часто, например, специалисты по ИТ считают 95%-ный уровень доступности вполне приемлемым, тогда как распорядители конкретного бизнес-процесса могут полагать простой в 2,5 часа каждую неделю непомерно высоким. В подтверждение своего мнения они, как правило, приводят жалобы пользователей и данные о потерях - они готовы согласиться лишь с 15 минутами простоя в неделю (99,5%-ная доступность). Здесь-то и может пригодиться соглашение об уровне сервиса - сервис-провайдер и потребитель ИТ должны оговорить условия предоставления сервиса.
Если используется метод взаимозачетов, то, скорее всего, стороны придут к соглашению достаточно быстро. Взаимозачет может иметь форму внутреннего кредита или других фиктивных денег, но без того или иного механизма принуждения единственным ограничением для потребителя сервиса будет его добропорядочность, и она может оказаться для них менее значима, чем критичные бизнес-процессы.
ВЫПОЛНЕНИЕ СОГЛАШЕНИЯ
Без измерения уровня сервиса вы не в состоянии выполнить соглашение. Традиционные платформы управления сетями и системами предоставляют не совсем то, что надо. Многие продукты на базе SNMP сообщают состояние и статистику для таких устройств, как маршрутизаторы и концентраторы. Системы на базе RMON, в особенности использующие RMON-2, могут сообщать информацию о сетевом сегменте или даже о трафике приложения между конечными точками, но их поле зрения ограничивается, как правило, пределами сети.
Продукты для управления системами - это по большей части узкоспециализированные продукты. Они сообщают о поведении сервера или клиента либо, возможно, предоставляют данные о конкретном приложении, например базе данных или электронной почте. Для нормальной работы какого-либо конкретного приложения необходима нормальная работа всех задействованных устройств и сетевых сегментов. Чтобы система управления была полезна для контроля за выполнением соглашения об уровне сервиса, она должна сообщать результаты измерений для конкретного сервиса, а не общую задержку пакета, пропускную способность канала передачи данных или среднее время поиска записи в базе данных.
Традиционные платформы управления ориентированы на сеть как вещь в себе: они способны обнаружить устройства в сети, определить соединения между ними и опросить их при помощи команд SNMP. В ранней версии HP Oрen-View, SunNet Mana-ger и NetView 6000 компании IBM все результаты опросов аккумулировались на одной главной консоли. В случае сбоя администратор крупной сети мог спуститься до уровня устройства, но связь между устройством и уровнем сервиса существовала только в его голове. Если администратор имел ясное представление о том, как приложение работает и как различные устройства влияют на его работу, он мог диагностировать проблему и, возможно, выдать некоторые общие рекомендации по повышению производительности приложения.
Последние редакции некоторых платформ управления, в том числе SPECTRUM компании Cabletron и OpenView Network Node Manager компании Hewlett-Packard, способны кое в чем помочь в решении проблемы измерения уровня сервиса. Во-первых, консоли этих продуктов могут быть распределенными практически в любой степени. Как следствие, консоль предоставляет конкретный вид только тех устройств и каналов, в которых администратор данной группы заинтересован (или уполномочен), что позволяет исключить лишние устройства из карты сети и сосредоточиться на конкретном сервисе. Производители этих платформ управления образовали также альянсы с такими крупнейшими поставщиками инструментария управления системами, как Computer Associates и Tivoli. Появившиеся в результате методы корреляции системных событий позволяют установить связь между, например, отсутствием доступа к таблице базы данных с сетевыми событиями типа тайм-аута на транспортном уровне.
Благодаря стандартизации RMON-2, совместимые с новой расширенной MIB зонды способны осуществлять мониторинг трафика на прикладном уровне. Таким образом, приложения на базе RMON-2 могут оказаться весьма полезными в мониторинге и генерации отчетов об уровне сервиса. NetScout Manager от NetScout Systems (ранее Frontier Software) имеет функцию Domain Manager, позволяющую задавать предопределенные комбинации сетевых компонентов на прикладном и более низких уровнях. Однако функциональность приложений на базе RMON, как и традиционных программ управления сетями и системами, ориентирована на конкретные устройства и сегменты, а не на приложения и бизнес-процессы.
Типичным представителем еще одного класса продуктов, развивающихся в направлении управления уровнем сервиса, является линия продуктов Network Health компании Concord Communications. В отличие от платформ управления сетью, основная цель которых - сообщения о событиях в сети в реальном времени, эти продукты представляют в первую очередь ретроспективные отчеты об использовании ресурсов, в том числе сегментов локальной сети и каналов frame relay. Traffic Accountant умеет работать с данными RMON-2, на основании которых он предоставляет информацию об использовании приложений, а также других ресурсов одним или группой пользователей.
Продукт Service Level Manager компании Network General, ориентированный на устройства и сетевые сегменты, предназначен в первую очередь для мониторинга сбоев и рабочих характеристик. Если платформы управления сетью предоставляют диаграммы или карты устройств, то основная консоль SLM представляет собой список контролируемых устройств и сегментов. Элементы списка сообщают о состоянии (красная стрелка, указывающая вниз, означает, что устройство не работает: в противном случае стрелка направлена вверх), о "здоровье" и доступности каждого элемента, причем значения последних двух полей усреднены за предопределенный период.
SLM собирает данные от агентов SNMP, зондов RMON и RMON-2 и устройств Distributed Sniffer компании Network General. Затем продукт передает все поступающие данные Experience Technology Engine, в котором воплощены многие методы анализа протоколов Expert Sniffer. Experience Technology Engine сопоставляет и сводит воедино данные, а затем сохраняет их в базе данных SQL (см. врезку "Корреляция ошибок").
Несмотря на свое название, менеджер уровня сервиса отнюдь не последнее слово Network General в области управления уровнем сервиса. Компания планирует реализовать базовую архитектуру SLM (именуемую Total Network Visibility) и в других продуктах, в том числе для анализа использования приложений из конца в конец и для определения времени отклика.
На управление приложениями и измерение их времени отклика нацелены несколько продуктов. Результаты этих измерений зачастую гораздо ближе к информации, необходимой менеджеру для контроля за выполнением соглашения об уровне сервиса, чем результаты анализа устройств и сегментов, предоставляемые традиционными продуктами для мониторинга сбоев и рабочих характеристик.
Одним из лучших продуктов по управлению приложениями общего назначения является EcoScope 3.0 (ранее называвшийся EcoNet) компании Compuware. EcoScope оснащен специальными программными зондами (Super Monitors), устанавливаемыми на рабочие станции, которые оснащены сетевыми платами, работающими в режиме приема всех пакетов. Приложение для консоли именуется Single View.
EcoScope может автоматически определить и затем измерить потребляемую пропускную способность и время отклика для более чем 1200 приложений; кроме того, по желанию заказчика его можно настроить и на другие приложения. Single View рисует топологическую карту сети (в том числе каналы глобальной сети) и отображает статистику о каждом приложении. EcoScope понимает SQL, а значит, способен предоставлять данные о конкретных типах транзакций SQL. Приложение можно сконфигурировать так, что оно будет отправлять прерывания SNMP на Single View или другую консоль управления при превышении порога для времени отклика или исчерпании пропускной способности. Средства генерации отчетов EcoScope пригодны и для документирования характеристик сервиса.
Patrol компании BMC Software - другая система управления приложениями, способная сыграть существенную роль в мониторинге данных для целей контроля за выполнением соглашения об уровне сервиса. Линия Patrol имеет многочисленные Knowledge Modules, представляющие собой агентов для серверов обмена сообщениями, Lotus Notes и Microsoft Exchange, различных разновидностей баз данных SQL, в том числе Oracle, Sybase, Informix, DB2 и Microsoft SQL Server, серверных операционных систем типа UNIX, OS/2, NetWare и Windows NT Server, а также серверов транзакций и других типов промежуточного программного обеспечения.
ЗОНДИРОВАНИЕ ВГЛУБЬ
Netcool/Omnibus от Micromuse - продукт, который благодаря своим функциям наиболее близко отвечает задаче контроля за выполнением соглашения об уровне сервиса. Инструментальными средствами Netcool/Omnibus являются программные зонды Collectors. Micromuse имеет коллекторы для HP OpenView Network Node Manager и IT Operations, Sun Solstice, Novell ManageWise, Cabletron SPECTRUM, IBM NetView и Windows NT. Зонды могут черпать информацию не только от агентов SNMP, но также из системных и других журнальных файлов и с консолей операционных систем. Комплект для разработчика позволяет быстро создавать новые коллекторы.
Информация, собираемая зондами, сводится воедино, сопоставляется и сохраняется в базе данных ObjectServer. Netcool/Omnibus Desktop предлагает Event Lists и Objective Views. Event Lists - это генерируемые на основе информации ObjectServer и выделенные цветом предупреждения, а Objective Views - карты или диаграммы всей системы.
Списки Event Lists и виды Objective Views без труда могут быть настроены администраторами и конечными пользователями с помощью графических инструментов. Любые поля или комбинации полей в ObjectServer могут использоваться для определения отфильтрованных видов, соответствующих приложениям и бизнес-процессам. Конечные пользователи, или "потребители сервиса", для самостоятельного контроля уровня сервиса имеют возможность обращаться к Java Event List из своих браузеров Web.
Netcool/Omnibus можно использовать сразу после установки для контроля выполнения типичных соглашений об уровне сервиса. Альтернативные подходы, если они хоть в какой-то мере соответствуют задачам контроля за соглашением об уровне сервиса, предполагают необходимость дополнительного программирования в значительном объеме. Инструменты разработки Micromuse в значительной мере упрощают задачу разработчика, однако факт остается фактом: объем работ по интеграции и доводке, необходимый для установки системы контроля за соглашениями об уровне сервиса, весьма значителен.
ПОЛИТИЧЕСКИЙ ПЕРЕВОРОТ
Помимо продуктов, упоминаемых в нашей статье, ряд других крупных программистских компаний объявили о многоплатформенных, многопротокольных продуктах для управления уровнем сервиса. Unicenter-TNG от Computer Associates, IT/Operations от Hewlett-Packard и TME 10 от IBM/Tivoli собираются предоставить ориентированное на бизнес-процессы управление. Важным вопросом для любого продукта управления уровнем сервиса является то, какие усилия по программированию, интеграции и конфигурации потребуются для получения системы, способной справляться с задачей измерения уровня сервиса лучше, чем ориентированная на устройства система.
К сожалению, чисто техническая проблема создания ориентированной на процессы автоматизированной системы управления отнюдь не самая сложная. В отделах ИТ ответственность сотрудников ограничивается обычно конкретными сетями или системными компонентами. В результате одни сотрудники администрируют базу данных, другие пишут сценарии CGI, третьи занимаются поддержкой конечных пользователей, четвертые отвечают за серверы и концентраторы, пятые колдуют над маршрутизаторами и т. д. Всех этих разношерстных специалистов довольно трудно организовать таким образом, чтобы каждый из них отвечал за достижение той или иной цели в отношении уровня сервиса для конкретного бизнес-процесса.
Может статься, что реализация управления уровнем сервиса приведет к кардинальной перестройке традиционных отделов ИТ. От ситуации, когда распорядители бизнес-процесса пользуются выделенными им ресурсами ИТ, до ситуации, когда персонал ИТ поддерживает конкретный бизнес-процесс и отчитывается перед его распорядителями, а те компенсируют их затраты, осталось не так уж и далеко. Будет ли тогда смысл в отделах ИТ со своими собственными менеджерами и администрацией?
Стив Штайнке - старший редактор Network Magazine. С ним можно связаться по адресу: ssteinke@mfi.com.
НЕОБРАБОТАННЫЕ ДАННЫЕ: ОТДЕЛЯЯ ЗЕРНА ОТ ПЛЕВЕЛ
Корреляция событий
Одной из ключевых технологий, без которых продукты по управлению уровнем сервиса просто немыслимы, является корреляция событий. Очень часто совместными усилиями агенты управления просто перегружают приложение управления, сообщая огромное число симптомов, причиной которых является один и тот же источник. Классическим примером здесь служит потеря связи по каналу глобальной сети, возможно, в случае аварии на удаленном маршрутизаторе. В такой ситуации традиционные продукты управления сетью будут посылать запросы SNMP ко всем устройствам на другом конце недоступного уже канала, и, естественно, все эти агенты не будут отвечать. Половина пиктограмм на экране консоли зажжется красным светом. Все же реальные последствия от недоступности канала не всегда столь серьезны - разве что несколько опоздавших писем электронной почты; при этом сети по обе стороны канала будут работать прекрасно.
NeverCenter Pro компании Seagate Software предназначена специально для приема взаимозависимых данных о событиях от таких платформ управления сетью, как HP OpenView, Cabletron SPECTRUM или IBM NetView for AIX, и отбора среди них критических событий для принятия необходимых мер. События NeverCenter Pro имеют вид "конечного автомата", а это означает, что администратор должен моделировать различные состояния и переходы между состояниями в ответ на поступление управляющих данных, а также сообщить системе, как выявить дублирующие друг друга предупреждения и как отличить причину от следствий, т. е. какое событие повлекло за собой другие.
Experience Technology Engine (ETE) компании Network General имеет помимо сбора информации некоторые из этих функций, но заказчик не в состоянии в нем что-либо изменить, по крайней мере в имеющихся продуктах. Программное обеспечение ETE может соотнести конкретные сообщения ICMP с задержкой получения ответа при диалогах и определить, что маршрутизатор слишком загружен. Заказчики могут не сомневаться, что Network General правильно коррелирует события, тогда как при самостоятельном моделировании конечного автомата полной уверенности в результате быть не может.
Принятый Micromuse подход в Netcool/Omnibus можно сформулировать следующим образом: "Все возможные события, данные о которых собрали зонды Collector, хранятся в базе данных SQL (ObjectServer). Эти данные можно фильтровать и манипулировать ими как угодно". Администратор сети, столкнувшись с массой одновременных событий, способен отфильтровать некоторые события, если он знает, что на самом деле они сообщают об одном и том же событии. В отличие от NeverCenter Pro, этот анализ зачастую нельзя провести заранее, но хорошо хотя бы то, что приложение управления уровнем сервиса может работать без необходимости определения множества сложных моделей.