Управление и мониторинг сервисов во время исполнения

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

Юйчан Цзяо, инженер-программист, IBM

Юйчан Цзяо (YuChang Jiao) – инженер-программист в China SOA Design Center. Специализируется на разработке SOA-приложений. Работает в международной группе SOA Technical Sales, которая предоставляет кросс-платформенные SOA-решения и концептуальные проекты. До этого был старшим разработчиком в группе SOADEE.



17.02.2012

Обзор

Среда управления и мониторинга сервисов, позволяющая выполнять мониторинг сервисов и предоставляющая методы управления и руководства, занимаете все более важное место в жизненном цикле SOA. Она позволяет организациям управлять развернутыми сервисами и обеспечивать гибкость развертывания сервисов и их взаимодействий для удовлетворения потребностей бизнеса. Именно эффективное управление этим жизненным циклом и является ключевой целью SOA Governance. В данной статье рассматривается интегрированная среда управления и мониторинга IBM Services Monitoring and Management (кратко ISMM), основанная на продуктах IBM. Будут продемонстрированы также новые функциональные возможности этих продуктов, в том числе IBM® WebSphere® Service Registry and Repository V6.2, IBM® Tivoli® Composite Application Manager for SOA V7.1.1, WebSphere® Application Server V7.0, Tivoli® Security Policy Manager V7.0 и WebSphere DataPower V3.7.3. Следует также отметить, что среда ISMM помогает решать проблемы безопасности сервисов, которые сегодня приобретают все большую важность.


Проблемы, возникающие в жизненном цикле SOA и архитектуре решения ISMM

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

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

Вторая проблема связана с мониторингом и использованием качества сервиса (QoS). Сервисы, используемые в бизнесе, не могут быть статичными. Часто бывает, что сервисы необходимо выбирать во время исполнения из набора сервисов на основе QoS с учетом их доступности. Не следует даже пытаться вызывать неработающие сервисы. Иногда требуется выявлять оконечные точки с плохой производительностью и блокировать их на основании настроенных пороговых значений. Это означает, что вызовы сервисов можно маршрутизировать на базе QoS.

Третья проблема – динамическая отчетность о работе сервиса и его неполадках. Клиентам необходимо выполнять мониторинг показателей жизнеспособности сервиса на бизнес-уровне, чтобы выявлять нарушения соглашений об уровне сервиса (Service Level Agreement – SLA) и простои сервисов. Также необходимо найти способ визуализировать эти показатели. Более того, при обнаружении неполадок уведомления должны автоматически отправляться администраторам, которые должны предпринять соответствующие меры.

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

Для решения всех этих проблем предназначена интегрированная среда IBM Services Monitoring and Management Framework, основанная на продуктах и решениях IBM. Ниже представлена архитектура решения ISMM.

Рисунок 1. Архитектура решения ISMM
Рисунок 1. Архитектура решения ISMM

Показанную на рисунке 1 архитектуру решения ISMM можно разделить на три уровня. Первый уровень – это уровень клиента. На этом уровне сервисы могут предоставляться клиентам и бизнес-партнерам. По соображениям безопасности нам нужно авторизовать и аутентифицировать запросы сервисов, поэтому мы добавляем DMZ (демилитаризованную зону) в качестве второго уровня для реализации такой системы авторизации и аутентификации.

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

Реестр и репозиторий сервисов (Service Registry Repository) обеспечивает видимость сервисов для SOA-сервисов, стратегий и ассоциированных метаданных с поддержкой SOA Governance. Политика защиты помогает обезопасить доступ к приложениям, способствует совместимости и поддерживает оперативное руководство всей информационной инфраструктурой. Все эти компоненты основаны на системе управления информационными сервисами (IT Service Management – ITSM), которая выполняет мониторинг жизненного цикла SOA, гарантируя высокую готовность и производительность. ITSM предлагает интегрированные средства управления, ускоряющие и упрощающие идентификацию и разрешение проблем SOA.

Рисунок 2. Карта продуктов в решении ISMM
Рисунок 2. Карта продуктов в решении ISMM

На рисунке 2 представлена карта продуктов для решения ISMM. Каждый продукт, представленный на рисунке 2, можно отобразить на соответствующий компонент рисунка 1. WebSphere® DataPower SOA Appliance используется как шлюз системы защиты для аутентификации и авторизации запроса сервиса. Tivoli® Directory Server используется в качестве сервера каталогов для хранения профилей пользователей. WebSphere® ESB используется в качестве ESB для реализации маршрутизации и выбора сервисов на основе QoS. Продукт WebSphere® Service Registry and Repository применяется в качестве компонента реестра и репозитория сервисов для управления и реализации реестра сервисов. Tivoli® Security Policy Manager используется в качестве компонента для поддержки политик безопасности. Платформа Tivoli® Composite Application Manager for SOA выполняет функции ITSM по мониторингу и управлению данными QoS.

Перечисленные продукты IBM позволяют реализовать решение ISMM с возможностью мониторинга сервисов и поддержкой методов руководства и управления всем жизненным циклом SOA.


Контроль и устранение "неучтенных" сервисов

Рисунок 3. Мониторинг и анализ "неучтенных" сервисов
Рисунок 3. Мониторинг и анализ

Сервисы необходимо контролировать аналогично любым другим ресурсам. Только тогда можно будет выполнять мониторинг сервисов и решать проблемы. Платформа ITCAM for SOA позволяет выполнять мониторинг только активизированных сервисов и собирать метаданные об их использовании, производительности и доступности. WSRR служит центральным реестром и репозиторием сервисов. Все сервисы должны быть зарегистрированы в WSRR. Адаптеры библиотеки обнаружения (Discovery Library Adapters – DLA) извлекают данные из исходного приложения и генерируют XML-файлы, т.н. книги адаптера библиотеки обнаружения. Эти файлы, использующие XML-формат Identity Markup Language, используются в данном сценарии для передачи указанных метаданных. После генерирования программой DLA файла DLA-книги, в котором содержатся взаимоотношения между сервисами, порты сервисов, операции, бизнес-процессы, серверы приложений и компьютерные системы, на которых они развернуты, пользователи могут загружать файлы этого типа в TCORE и отображать их в Tivoli® Enterprise Portal. В ISMM используется два типа источников данных: ITCAM for SOA, содержащий информацию о сервисах, и WSRR, содержащий информацию о зарегистрированных сервисах. Подробная информация об этом приведена в справочной системе ITCAM for SOA.

После успешной загрузки DLA Books в ITCAM for SOA автоматически создаются топология и взаимоотношения сервис-сервис. Информация об использовании сервиса, состоянии реестра, потоках и взаимоотношениях также будет отображаться в портале Tivoli® Enterprise Portal.

На рисунке 4 красной рамкой обведены сервисы, которые видны ITSM, но не зарегистрированы в реестре и репозитории сервисов. Такие сервисы называются "неучтенными" (rogue). Можно также идентифицировать сервисы, которые зарегистрированы в WSRR, но не активизируются. Сервисы этого типа отмечаются на рисунке 4 желтой рамкой и называется "ненужными" сервисами (shelf-ware services). Чем меньше таких сервисов, тем лучше реализация SOA-решения. Имеется еще один тип сервисов, которые видимы, но не зарегистрированы. Их можно назвать "неподатливыми" сервисами (rigid services). Такие сервисы являются неуправляемыми и будут разрушать систему управления сервисами. Сервисы такого типа нужно устранять.

Рисунок 4. Обзор сервисов в TEP
Рисунок 4. Обзор сервисов в TEP

Посредством описанного выше процесса можно идентифицировать дублирование Web-сервисов и предоставить информацию о неиспользуемых сервисах с целью сокращения числа ненужных сервисов. ИТ-подразделение получает информацию по использованию развернутых сервисов и способ визуализации работающих сервисов. Только в этом случае можно реализовать ожидаемое снижение затрат на обслуживание в результате внедрения SOA.


Мониторинг и использование QoS сервисов

Собираемые данные о качестве сервиса (Qualities of Services – QoS), например, производительности и доступности, можно использовать для динамического выбора оконечных точек сервисов. Поскольку деятельность бизнеса становится все более и более динамичной, Web-сервисы, используемые в бизнес-процессах, не могут быть статичными. Web-сервисы должны выбираться во время исполнения из набора сервисов, определенных во внешнем реестре. Нам также нужна система управления доступностью сервисов. Следует использовать только доступные Web-сервисы и всячески избегать вызова недоступных. Таким образом, необходимо выявлять оконечные точки с плохой производительностью и блокировать их на основании установленных пороговых значений.

В решении ISMM, использующем WSRR, ITCAM for SOA Platform и Enterprise Service Bus, ESB может через модуль-посредник динамически извлекать информацию о работоспособности сервисов из WSRR и соответственно маршрутизировать запросы к сервисам, чтобы гарантировать адекватное качество обслуживания. В свою очередь, платформа ITCAM for SOA Platform выполняет мониторинг работающих сервисов и обновляет метаданные в WSRR в соответствии с текущим состоянием среды исполнения (производительностью, доступностью и т.д.).

Рисунок 5. Обзор сервисов в TEP
Рисунок 5. Обзор сервисов в TEP

На рисунке 5 показаны извлечение статистики сервисов-кандидатов, динамический выбор и позднее связывание с оконечной точкой сервиса. Как показано на рисунке 5, в данном сценарии используются: ITCAM for SOA Platform, WebSphere® Enterprise Service Bus и WebSphere® Service Registry and Repository. Поставщик сервиса выбирается динамически на основе запроса от клиента. Полная процедура такова:

  1. Платформа ITCAM for SOA собирает QoS-данные сервисов, например, касающиеся доступности и производительности этих сервисов.
  2. Все собранные QoS-данные синхронизируются с WSRR с целью обновления соответствующих метаданных сервисов модулем ITCAM for SOA Integration Module. Подробная информация о модуле ITCAM for SOA Integration Module приведена в руководстве ftp://ftp.software.ibm.com/software/integration/support/supportpacs/individual/sa04_UserGuide_6.0.2.pdf.
  3. Запрос сервиса от клиента поступает в WESB. В сообщении запроса от клиента инкапсулируется идентификационный маркер клиента и другая информация.
  4. При получении сообщения ESB считывает информацию о политике и атрибуты для WSRR, выполняет подходящий алгоритм и выбирает соответствующий сервис для использования на основании наблюдаемого качества сервисов в среде. Непосредственно после примитива Endpoint Lookup WESB можно добавить примитив Custom Mediation, который отсортирует результаты WSRR Endpoint Lookup и выберет "самую быструю" оконечную точку. Выбирая "самую быструю" оконечную точку, Java™-код в примитиве Custom Mediation сортирует результаты Endpoint Lookup в порядке возрастания свойства WSRR ResponseTime и настраивает цель маршрутизации (url назначения) в URL с самым низким значением ResponseTime. Этот Custom Primitive также имеет передаваемое (promotable) свойство ResponseLimit. Если в упомянутом выше Java-коде WSRR ResponseTime больше, чем данное свойство (ResponseLimit), Java-код должен отклонить такую оконечную точку.
  5. Запрашивающая сторона связывается с выбранной оконечной точкой сервиса, а затем активизирует ее. Клиент с низким приоритетом направляется в первую оконечную точку сервиса, тогда как клиент с высоким приоритетом направляется во вторую оконечную точку сервиса.
  6. Клиент с высоким приоритетом направляется во вторую оконечную точку сервиса.

Динамическая отчетность о жизнеспособности сервисов и уведомления

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

Применяемая в решении ISMM платформа IBM Tivoli® Composite Application Manager for SOA (сокращенно ITCAM for SOA) также позволяет операторам выполнять мониторинг групп сервисов на бизнес-уровне, чтобы помочь контролировать приоритеты нарушений SLA и простоев сервиса. Для просмотра информации, предоставляемой ITCAM for SOA, и определения основной причины проблем среды исполнения сервисов можно использовать Tivoli® Enterprise Portal (сокращенно TEP).

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

Рисунок 6. Клиентское представление жизнеспособности сервиса
Рисунок 6. Клиентское представление жизнеспособности сервиса

Состоянием по умолчанию группы сервисов является healthy (жизнеспособная). Это означает отсутствие проблем во всех сервисах данной группы. Такое состояние отмечается зеленой галочкой. Объект группы сервисов передает индикаторы жизнеспособности, например данные о производительности (время реакции в секундах) и объеме (количество сообщений), которые рассчитываются каждые 2.5 минуты (по умолчанию) и отображаются в представлениях группы сервисов. Если эти индикаторы превышают определенный оператором порог, инициируется определенная ситуация и создаются уведомления.

Недоступность группы сервисов основывается на этом типе ситуаций, ассоциированных с интерфейсными (front-end) сервисами группы сервисов. Такие специфические ситуации обычно используют атрибуты недоступности сервиса и показатели, предоставляемые платформой ITCAM for SOA.

Рисунок 7. Уведомление для нежизнеспособной группы сервисов
Рисунок 7. Уведомление для нежизнеспособной группы сервисов

Группы сервисов успешно определены. В этом представлении могут отображаться данные о производительности и объему всех сервисов. Если в контролируемой группе сервисов происходит что-то ненормальное, в данном представлении будут активизироваться и отображаться уведомления. На рисунке 7 группа сервисов под названием VerifyCreditServiceGroup отмечена большим красным крестом. Это означает, что некоторые сервисы в данной группе показывают плохую производительность, что приводит к инициированию критической ситуации. Можно углубиться (выполнив двойной щелчок левой кнопкой мыши на узле с красным крестом) в представление Interaction Detail, чтобы детально проверить состояние каждого сервиса данной группы и определить, что же с ними произошло.

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


Управление безопасностью сервисов на основе политик

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

Рисунок 8. Управление безопасностью сервисов на основе политик
Рисунок 8. Управление безопасностью сервисов на основе политик

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

  1. Разработчик SOA определяет и регистрирует сервисы в WSRR.
  2. Разработчик системы защиты определяет политику защиты через Tivoli® Security Policy Manager (сокращенно TSPM). Tivoli® Security Policy Manager – это продукт IBM, помогающий защитить доступ к приложениям, обеспечить совместимость и поддерживать оперативное руководство информационной инфраструктурой. Он выступает в роли точки администрирования политик (Policy Administration Point – PAP). Разработчик системы защиты извлекает определение сервиса из WSRR и связывает политику с этим сервисом.
  3. Затем разработчик системы защиты может передать эти сервисы и назначенные политики в WSRR. WSRR выступает в роли цели распределения политик (Policy Distribute Target – PDT).
  4. Разработчик системы защиты может также передать эти сервисы и назначенные политики непосредственно в DataPower. Тогда в роли PDT будет выступать DataPower.
  5. Неважно, какой компонент работает как PDT, – в конечном итоге все эти сервисы и назначенные политики должны подписываться DataPower. DataPower работает как точка реализации политики (Policy Enforcement Point – PEP). Для сервисов такого типа в DataPower создается Web Service Proxy. Также в DataPower настраиваются конфигурационные параметры WS-Policy и параметры WS-Proxy.
  6. Клиент отправляет запрос к сервисам, предоставляемым организацией. Запрос сначала направляется в Web Service Proxy и должен пройти аутентификацию и проверку на соответствие политикам, определенным разработчиком системы защиты. При этом DataPower реализует предопределенную политику

В ISMM контролируется и проверяется три типа политик системы защиты – защита на уровне сообщений, авторизация на основе роли и авторизация на основе правил.

Защита на уровне сообщений применяется для конкретных сообщений, циркулирующих в рамках предприятия. Разработчик системы защиты входит в пользовательский интерфейс TSPM и создает политику, требующую шифрования и аутентификации сообщений с утверждением (assertion) SAML. Разработчик системы защиты затем назначает эту политику предоставляемому сервису, настраивает политику системы защиты в TSPM и передает ее из TSPM в WSRR. DataPower настраивается на синхронизацию WSRR-подписки для извлечения WSDL со стратегией из WSRR. Разработчик системы защиты создает простой прокси Web-сервисов в DataPower. Клиентские запросы будут направляться в этот прокси Web-сервисов, в котором во время вызова транзакции сервиса с помощью политики защиты в сообщение сервиса принудительно добавляется защита сообщения. Потребители данного сервиса используют для доступа к поставщику сервиса шифрованный поток сообщений запросов сервиса и маркер SAML, добавленный к потоку. В таком сценарии устройство IBM WebSphere® DataPower используется как точка выбора политики (Policy Decision Point – PDP) и точка реализации политики (Policy Enforcement Point – PEP).

Авторизация на основе роли. Разработчик системы защиты обнаруживает сервисы в реестре и импортирует их, отображает роли на существующую систему идентификации IBM Tivoli® Directory Server, а затем создает, конфигурирует и передает политики системы защиты из TSPM в DataPower. Запрос клиента к сервису запрещается, если клиенту не назначена соответствующая роль. Разработчик системы защиты может изменить назначение роли, предоставив роль клиенту. Только после этого клиент может обратиться к соответствующим сервисам. Например, сервис UpdateEmployeeSalary предназначен для обновления базовой зарплаты сотрудников и может вызываться только сотрудниками, имеющими роль Manager. Джек является сотрудником данной компании. Он не имеет доступа к сервису UpdateEmployeeSalary, так как не является менеджером. В данном сценарии устройство IBM WebSphere® DataPower используется как точка выбора политики (Policy Decision Point – PDP) и точка реализации политики (Policy Enforcement Point – PEP).

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


Заключение

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

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=794324
ArticleTitle=Управление и мониторинг сервисов во время исполнения
publish-date=02172012