Проверенные приемы IBM Cognos: Маршрутизация с помощью компонентов IBM Cognos 8 BI Dispatcher

Характер документа:руководство; Продукт(продукты): IBM Cognos BI;область интересов:инфраструктура; Версия:1.2

Компактное объяснение основных концепций, применяемых при маршрутизации запросов с помощью компонентов IBM Cognos 8 Dispatcher.

Введение

Назначение документа

Данный документ дополняет документы Security and Administration Guide (Руководство по безопасности и администрированию) и Architecture and Deployment Guide (Руководство по архитектуре и развертыванию), которые входят в состав комплекта документации по продукту IBM Cognos BI.

В документе детально рассматриваются концепции, применяемые при маршрутизации запросов с помощью компонентов типа Dispatcher, включая выравнивание нагрузок и маршрутизацию Advanced Routing в сценариях интерактивной и пакетной обработки. Документ ориентировано на администраторов и архитекторов.

Применимость

Описанные в данной статье концепции применимы ко всем версиям продуктов IBM Cognos 8 BI и IBM Cognos 10 BI, если обратное не указано явно.

Исключения

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

Допущения

Предполагается, что читатель знаком с концепциями, описанными в документе Architecture and Deployment Guide (Руководство по архитектуре и развертыванию).

Кроме того, полезно понимать основы Java и J2EE.


Маршрутизация в среде IBM Cognos BI

Зачем нужна маршрутизация

Продукт IBM Cognos BI базируется на сервис-ориентированной архитектуре (Service Oriented Architecture, SOA). Это подразумевает, что данный продукт состоит из набора независимых сервисов, которые взаимодействуют по сети посредством технологии SOAP. Существует множество различных сервисов, которые реализуют различные возможности данного продукта. Каждый из этих сервисов способен обслуживать только запросы определенного типа. Одна из задач маршрутизации в SOA-среде и состоит в том, чтобы маршрутизировать запрос к тому сервису, который способен обслужить этот тип запросов.

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

Компонент типа Dispatcher

В продукте IBM Cognos BI обе вышеописанные задачи маршрутизации решаются с помощью программного компонента под названием Dispatcher. С технической точки зрения компонент Dispatcher представляет собой т.н. Java-сервлет (Java Servlet), что подразумевает, что он обрабатывает входящую информацию в формате HTML и генерирует исходящую информацию в формате HTML. В случае продукта IBM Cognos BI входящая и исходящая полезные нагрузки фактически используют технологию SOAP (Simple Object Access Protocol) и таким образом (с технической точки зрения) являются XML-нагрузками, которые транспортируются по протоколу HTTP.

Каждый Dispatcher осуществляет хостинг набора сервисов, состав которого определяется системными компонентами, установленными на данном экземпляре продукта IBM Cognos BI. Эти сервисы зарегистрированы в этом компоненте Dispatcher, который и осуществляет управление этими сервисами. Одновременно с этим данный Dispatcher "знает", хостинг экземпляров какого сервиса он осуществляет, и соответственно запросы каких типов он способен обслуживать на локальном уровне.

При запуске компонента Dispatcher он регистрирует себя в активном экземпляре Content Manager (CM). При этом он сообщает о сервисах, хостинг которых он осуществляет, и получает от компонента CM информацию о системе. В ходе этого процесса каждый Dispatcher собирает информацию обо всех остальных компонентах типа Dispatcher в системе и обо всех сервисах, хостинг которых осуществляют эти компоненты.

Хотя для тестирования может быть вполне достаточно простой среды с одним сервером, производственные системы обычно состоят из нескольких установленных экземпляров (иногда называемых узлами), на каждом из которых исполняется компонент Dispatcher с собственным набором зарегистрированных сервисов. В случае нескольких узлов становится возможным применение таких механизмов, как выравнивание нагрузки и переключение при сбое. В архитектуре IBM Cognos BI эти функции реализуются с помощью логической шины, которая существует между компонентами типа Dispatcher, имеющимися на каждом узле. По этой логической шине запросы передаются/маршрутизируются между имеющимися в системе компонентами типа Dispatcher и, в конечном итоге, к определенному экземпляру сервиса, зарегистрированному в одном из компонентов Dispatcher. Как будет объяснено ниже, этот процесс обеспечивает возможность выравнивания нагрузки и доступность сервиса.

Клиенты отправляют компоненту Dispatcher запросы, предназначенные для обслуживания сервисом определенного типа. Установленные в системе компоненты типа Dispatcher гарантируют направление такого запроса к доступному экземпляру запрашиваемого сервиса, который обработает этот запрос и отправит результат обратно клиенту.

Соображения относительно точки входа

Поскольку Dispatcher является Java-сервлетом, он должен быть развернут на компоненте типа Servlet Container/Java Application Server (контейнер сервлетов/сервер Java-приложений), который в классической трехуровневой архитектуре обычно размещается на уровне приложений (Application Tier). Это порождает потенциальный риск открытия уровня приложений для прямого доступа со стороны внешних клиентов (т.е. из неконтролируемой или из менее контролируемой среды), поэтому для взаимодействия с внешними клиентами настоятельно рекомендуется использовать какой-либо другой компонент на веб-уровне, например, веб-сервер. Между серверами веб-уровня и серверами уровня приложений разрешаются только специально выделенные, контролируемые и защищаемые коммуникационные каналы.

Архитектура IBM Cognos BI поддерживает этот подход с помощью компонентов IBM Cognos BI Gateway, которые существуют в шести различных реализациях (CGI, MOD, MOD2, MOD2_2, ISAPI), и с помощью реализации дополнительного сервлета. В типичных развертываниях используется компонент (компоненты) типа Gateway (шлюз), который действует как точка входа в систему IBM Cognos BI. Следует отметить, что компонент типа Gateway ничего не делает с запросом, он лишь перенаправляет его к первому доступному компоненту Dispatcher в своем сконфигурированном списке компонентов типа Dispatcher. Таким образом, компонент Gateway можно рассматривать как посредника. Servlet Gateway – это специальная реализация шлюза, которая должна быть развернута на компоненте Java Application Server или на компоненте Servlet Container, обычно размещаемых на уровне приложений (Application Tier). Этот шлюз применяется в таких средах, в которых какое-либо другое программное обеспечение используется в качестве посредника для перенаправления запросов от веб-уровня к уровню приложений. Характерным примером являются плагины серверов приложений, развертываемые на веб-серверах именно с этой целью; подобные плагины существуют для IBM WebSphere или для JBOSS.

Компонент типа Gateway (шлюз) не осуществляет маршрутизацию запросов, он использует статическое соединение с первым доступным Dispatcher в своей конфигурации. Этот порядок изменяется лишь в том случае, если первый сконфигурированный Dispatcher недоступен. Только в этом случае шлюз пытается направить запрос второму компоненту Dispatcher в своем сконфигурированном списке компонентов типа Dispatcher и т.д. Другими словами, маршрутизация запроса начинается лишь тогда, когда этот запрос поступает в компонент IBM Cognos BI Dispatcher в самый первый раз. Компонент Dispatcher, который первым получает запрос от клиента, называется компонентом FRONT Dispatcher для этого запроса. Это важно в случае нескольких потоков определенных запросов, связанных с аутентификацией (см. Приложение A).

Однако с технической точки зрения нет никакой разницы, компонент какого типа является точкой входа: Dispatcher или Gateway. Это примечательная особенность, которая позволяет разработчикам применять такие опции сервера приложений, как подключаемые веб-серверы, которые как посредники перенаправляют получаемые на веб-уровне запросы на уровень приложений – точно так же, как это делает компонент IBM Cognos BI Gateway.

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


Концепции маршрутизации

В следующем разделе объясняются основные концепции маршрутизации продукта IBM Cognos BI.

Концепция Server Group (группа Server Group)

Сначала рассмотрим концепцию под названием Server Groups (группы Server Group).

Группа Server Group (SG) представляет собой заданный некоторым образом набор компонентов типа Dispatcher. В определенный момент времени каждый компонент Dispatcher может быть приписан не более чем к одной группе Server Group.

По умолчанию при установке системы для компонента Dispatcher в явном виде не задается никакой группы Server Group. В результате Dispatcher автоматически становится членом группы default Server Group (группа Server Group по умолчанию). Группа default SG существует лишь в неявном виде и не может быть изменена или переконфигурирована. Тем не менее администратор может приписать компонент Dispatcher к любой другой явно заданной группе SG. Эта задача решается присвоением соответствующего строкового значения свойству Server Group объекта Dispatcher с помощью инструмента IBM Cognos Administration. Это значение неявным образом определяет новую группу Server Group с этим именем, если такой группы еще не существует. Если такая группа уже существует, то соответствующий компонент Dispatcher добавляется в существующую группу Server Group с этим именем.

Рисунок 1. Компонент Dispatcher, приписанный к группе SG с именем Endor
Figure 1 - Dispatcher which was assigned to SG

Группы Server Group имеет большое значение, поскольку именно они в общем и целом определяют область для выравнивания нагрузки и для распределения сервисов.

  • Каждый раз, когда компоненты типа Dispatcher ищут активный экземпляр определенного сервиса, масштабы этого поиска определяются соответствующей группой Server Group.
  • Каждый раз, когда компоненты типа Dispatcher занимаются выравниванием нагрузки, они делают это только для сервисов в рамках той же группы SG, к которой приписан соответствующий компонент Dispatcher.

Необходимо помнить эти два весьма важных факта.

И, наконец, группы Server Group являются необходимым условием для использования технологии Advanced Routing, которая будет описана позднее.

Определения групп Server Group хранятся в хранилище Content Store; только компонент CM способен предоставлять информацию о приписывании конкретного Dispatcher к определенной группе Server Group. Управление этими определениями осуществляется только в неявном виде – посредством присвоения значения свойству Server Group компонента Dispatcher. Другими словами, если вводится новое значение, не существовавшее до этого, то неявным образом формируется новая группа Server Group с этим именем. Если больше не существует никакого компонента Dispatcher, который использует значение X, то группа Server Group с именем X удаляется. Список групп Server Group может быть получен с помощью значения SELECT DISTINCT у свойства Server Group для всех компонентов типа Dispatcher в системе.

Необходимо отличать группы Server Group от папок. Инструмент IBM Cognos Administration поддерживает возможность для концентрации компонентов типа Dispatcher в папках. Однако такая папка не равносильна группе Server Group. Это всего лишь организационное группирование. С помощью папок можно одновременно присвоить те или иные свойства нескольким Dispatcher. По умолчанию компоненты типа Dispatcher наследуют значения свойств от родительского объекта, такого как папка, если в явном виде не указано иное.

Информация Dispatcher Cluster Information

Чтобы компонент Dispatcher мог назначать запросы запрашиваемому сервису и "наиболее подходящему" экземпляру этого сервиса, а также корректно маршрутизировать эти запросы, ему требуется следующая всеобъемлющая информация:

  • какие компоненты типа Dispatcher функционируют в системе IBM Cognos BI;
  • к каким группам Server Group принадлежат эти компоненты типа Dispatcher;
  • какие сервисы зарегистрированы на каждом компоненте типа Dispatcher;
  • каково состояние исполнения каждого экземпляра данного сервиса.

Эта совокупность важнейшей информации о состоянии системы носит название Dispatcher Cluster Information. Централизованное управление этой информацией осуществляет Content Manager; соответственно все обновления и вопросы должны направляться к активному экземпляру сервиса Content Manager Service.

Как было отмечено выше, после запуска каждого компонента типа Dispatcher он регистрирует себя в Content Manager Service. В процессе этой регистрации Dispatcher информирует CM о соответствующих сервисах и о состоянии их исполнения (разрешено/запрещено). CM добавляет эту информацию к информации Dispatcher Cluster Information, собранной к данному моменту времени. Затем Dispatcher запрашивает у CM (через Content Manager Service) копию этой обновленной и самой свежей информации Dispatcher Cluster Information. Очевидно, что эта информация содержит сведения обо всех зарегистрированных компонентах типа Dispatcher и обо всех экземплярах сервисов, зарегистрированных на них, в результате чего каждый Dispatcher после своего запуска обладает информацией обо всех остальных компонентах типа Dispatcher и о зарегистрированных на них сервисах. Несомненно, необходимо поддерживать синхронизацию этой локальной копии Dispatcher Cluster Information с соответствующей информацией CM.

Эта синхронизация осуществляется с помощью не потребляющих много ресурсов ping-запросов (keep-alive ping) к CM; все исполняющиеся компоненты типа Dispatcher каждые 30 секунд самостоятельно отправляют к CM такие запросы. Этот запрос решает две задачи. Во-первых, Dispatcher сообщает CM, что он по-прежнему функционирует надлежащим образом. Это концепция позволяет CM выявить любой Dispatcher, который по какой-либо причине стал недоступен – умышленно (был остановлен) или неумышленно (фатальный сбой). В результате CM обновляет эталонную копию информации Dispatcher Cluster Information, которая затем автоматически распространяется всем остальным компонентам Dispatcher в рамках следующего 30-секундного цикла выявления изменений с помощью ping-сигналов. Во-вторых, с помощью этого запроса Dispatcher получает возможные обновления информации Dispatcher Cluster Information для синхронизации своей локальной копии этой информации. Если механизм keep-alive ping сигнализирует о необходимости синхронизации изменений, в CM отсылается конфигурационный вызов. Этот вызов извлекает самую свежую копию информации Dispatcher Cluster Information и инициирует принудительную локальную реконфигурацию, в результате чего Dispatcher и все зарегистрированные на нем сервисы обновляют свою конфигурацию соответствующим образом.

Во-вторых, с помощью этого запроса Dispatcher выявляет возможные обновления информации Dispatcher Cluster Information, чтобы поддерживать синхронизацию свою локальную копии этой информации. Если обнаружено какое-либо изменение, в CM отсылается конфигурационный вызов. Этот вызов извлекает самую свежую копию информации Dispatcher Cluster Information и инициирует принудительную локальную реконфигурацию, в результате чего Dispatcher и все зарегистрированные на нем сервисы обновляют свою конфигурацию соответствующим образом.

Помимо вышеописанного механизма keep-alive ping существует лишь один альтернативный способ обновления информации Dispatcher Cluster Information. Этот способ базируется на использовании команды admin, которую компоненты типа Dispatcher отправляют в CM после изменения состояния исполнения какого-либо сервиса. Это происходит в тех случаях, когда администратор с помощью инструмента Cognos Administration запускает или останавливает определенный сервис на компоненте Dispatcher. После отсылки в CM команды admin эталонная копия информации Dispatcher Cluster Information обновляется и распространяется на другие компоненты Dispatcher системы посредством запросов типа keep-alive.

Просмотреть информацию Dispatcher Cluster Information определенного компонента Dispatcher можно с помощью следующего URL-адреса: http://<INTERNAL_DISPATCHER_URI>/p2plbDiag

Для получения доступа по этому URL-адресу пользователю требуются полномочия canUseAdministrationPortal.

Рисунок 2. Представление Dispatcher Cluster Information после обращения пользователя по URL-адресу /p2plbDiag
Figure 2 - Cluster View output of /p2plbDiag URL

Концепция Load Balancing (выравнивание нагрузки)

Концепция Load Balancing (выравнивание нагрузки) может применяться в тех случаях, когда в рамках некоторой группы Server Group имеется несколько доступных экземпляров одного и того же сервиса IBM Cognos BI. Находящиеся в разных группах Server Group экземпляры одного и того же сервиса непригодны для применения механизма выравнивания нагрузки.

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

Механизм Load Balancing активируется с помощью контрольного окошка для опции Load balancing mode (Режим выравнивания нагрузки) в конкретном компоненте Dispatcher (рис. 1). Этой опции может быть присвоено значение Weighted Round Robin или значение Cluster Compatible. Рекомендуется для всех имеющихся в системе компонентов типа Dispatcher использовать один и тот же режим, что позволяет избежать непредвиденных последствий. Тем не менее данная рекомендация не является строгим требованием, – если вы хорошо осведомлены обо всех потенциальных последствиях, то можете использовать разные настройки на разных компонентах Dispatcher, техническая возможность для этого есть.

Режим Weighted Round Robin подразумевает, что компоненты IBM Cognos BI Dispatcher должны маршрутизировать лишь приемлемые запросы. Такая маршрутизация облегчает применение этой разновидности метода Round Robin для распределения запросов между правомочными (находящимися в одной группе Server Group) экземплярами запрашиваемого сервиса. Механизм Round Robin осуществляет простое прямое присвоение запросов, поэтому он не учитывает возможных различий между экземплярами одного сервиса. Продукт IBM Cognos BI базируется на SOA, поэтому велика вероятность того, что вышеупомянутые экземпляры сервиса размещаются на разных физических устройствах с сильными различиями в доступных ресурсах (объем "кучи", количество процессоров). Как результат, потенциально возможны ситуации, когда не все экземпляры одного сервиса обладают одинаковыми ресурсами. Так, сервис, исполняющийся на многоядерной системе с большим объемом доступной оперативной памяти, способен обработать больше нагрузки, чем сервис, работающий на одноядерной системе с 2 гигабайтами памяти. С целью учета этого обстоятельства к алгоритму Round Robin был добавлен параметр Weight (весовой коэффициент). Этот коэффициент определяет, сколько запросов получит конкретный экземпляр сервиса. Реальное присвоение весового коэффициента осуществляется на уровне компонента Dispatcher, а не на уровне сервиса, поэтому этот коэффициент применяется ко всем сервисам, хостинг которых осуществляет данный Dispatcher. Это разумный подход, поскольку все эти сервисы совместно используют одни и те же аппаратные средства. Весовой коэффициент задается в свойстве Processing Capacity (Процессорные ресурсы) компонента Dispatcher (рис. 1). С учетом этого весового коэффициента (Weight) алгоритм Round Robin работает следующим образом.

Пример. Имеется четыре компонента Dispatcher с различными объемами процессорных ресурсов, определенные следующим образом.

  • Dispatcher A, весовой коэффициент 1
  • Dispatcher B: весовой коэффициент 2
  • Dispatcher C: весовой коэффициент 1
  • Dispatcher D: весовой коэффициент 4

Запросы будут назначаться этим компонентам Dispatcher в следующем порядке: A, B, B, C, D, D, D, D, A, B, B, C, D, D, D, D, …

Следует отметить, что это распределение справедливо лишь в статистическом смысле; не осуществляется никакого строгого назначения согласно вышеизложенной последовательности. Вышеупомянутое распределение запросов будет получено как результат усреднения с течением времени.

Продукт IBM Cognos BI 10 имеет для алгоритма Weighted Round Robin дополнительный параметр настройки под названием IPRF (In-Process Request Factor). Этот параметр снижает весовой коэффициент Dispatcher с каждым очередным запросом, который обрабатывается в настоящий момент времени.

По умолчанию параметр IPRF деактивирован; его необходимо активировать в явном виде заданием дополнительного свойства для компонента Dispatcher (применяется ко всем сервисам, зарегистрированным на этом компоненте Dispatcher) или для сервиса (применяется только к запросам на этот сервис). Рекомендуется использовать значение 2.0; значение 0.0 означает отсутствие IPRF. Документ Security and Administration Guide (Руководство по безопасности и администрированию) содержит подробные сведения по заданию данного параметра.

Причина добавления этого коэффициента "поверх" алгоритма Weighted Round Robin состояла в отсутствии понимания степени "загруженности" конкретного компонента Dispatcher (точнее, зарегистрированных на нем сервисов) и, соответственно, степени реального использования доступных сервисам ресурсов (аппаратных). Параметр Processing capacity указывает лишь на потенциальный максимум. Если сервисы, зарегистрированные на данном Dispatcher, уже обрабатывают несколько запросов, назначение этому компоненту Dispatcher еще одного запроса может оказаться неблагоразумным – даже несмотря на положительные результаты расчетов по алгоритму Weighted Round Robin. Параметр IPRF позволяет принять во внимание это обстоятельство.

Второе возможное значение для опции Load balancing mode (Режим выравнивания нагрузки) – Cluster Compatible.

В режиме Cluster Compatible выравнивание нагрузки осуществляется таким образом, чтобы максимальный приоритет предоставлялся локальным экземплярам запрашиваемого сервиса (размещенным на компоненте Dispatcher, который в настоящий момент обрабатывает этот запрос). Всякий раз, когда поступает запрос на сервис X, компонент Dispatcher сначала пытается назначить данный запрос локальному экземпляру этого сервиса. И только если эта попытка завершится неудачей, будет использована опция fall-back алгоритма Weighted Round Robin. Таким образом, данная опция предоставляет наивысший приоритет локальным экземплярам и игнорирует ресурсы, которые оцениваются лишь на следующем шаге.

Этот режим вполне можно задействовать при использовании внешнего выравнивания нагрузки посредством аппаратного или программного распределения нагрузки между узлами (т.е. между компонентами типа Dispatcher).

Например, это рекомендуется делать при развертывании продукта IBM Cognos BI в кластере IBM WebSphere. В данном случае программные компоненты IBM WebSphere сами решают, к какому узлу/компоненту Dispatcher следует маршрутизировать тот или иной запрос. Следует, однако, отметить, что такая маршрутизация основана не на доступности или загруженности конкретного сервиса IBM Cognos BI, а лишь на доступности и загруженности компонента типа Dispatcher. Предполагается, что все узлы кластера являются идентичными, поэтому все они должны исполнять одни и те же сервисы. Соответственно было бы непродуктивно осуществлять повторную маршрутизацию запроса. Тем не менее даже если сервис не существует локально, опция fall-back алгоритма Weighted Round Robin по-прежнему вполне применима.

Разговоры и родственность

Одна из самых важных концепций IBM Cognos BI – использование контекстно связанных последовательностей запросов клиента и ответов сервиса, направленных на реализацию определенной операции. Эти последовательности называются разговорами (conversation).

Наиболее характерным примером разговора в IBM Cognos BI является интерактивное исполнение отчета. Обычно оно запускается нажатием на нужный отчет в инструменте Cognos Connection, которое и инициирует исполнение этого отчета. После этого клиент может получить несколько подсказок по выбору источника данных для предоставления надлежащих значений. После начала исполнения готового отчета браузерный клиент получает соответствующие обновления посредством на странице «Ваш отчет исполняется». После завершения исполнения отчета пользователь может просмотреть его (при условии, что этот отчет представлен в формате HTML). Вся операция исполнения отчета состоит из нескольких шагов. На протяжении этого разговора клиент отправляет несколько запросов и получает несколько ответов.

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

Другими словами, запросы в рамках разговора о маршрутизации с помощью Dispatcher должны иметь наивысший приоритет! Показатель важности маршрутизации запроса к определенному экземпляру запрашиваемого сервиса и, соответственно, к определенному компоненту Dispatcher, называется request affinity (родственность запроса).

Родственность запроса зависит от сервиса, на которой он направлен, и от того, является или не является этот запрос частью разговора. Система IBM Cognos BI устанавливает родственность неявным образом согласно трем простым правилам:

  • запросы к Content Manager Service являются "абсолютно родственными";
  • первичные запросы в рамках разговора не имеют родственности;
  • вторичные запросы в рамках разговора имеют высокую степень родственности.

Родственность хранится в виде значения, которое является частью заголовка SOAP-действия для соответствующего запроса. В среде IBM Cognos BI родственность может иметь одно из пяти различных значений:

  • (значение не присвоено) – родственность отсутствует; иногда обозначается как низкая степень родственности (low).
    Запрос может быть маршрутизирован к любому доступному экземпляру целевого сервиса IBM Cognos BI.
  • high – высокая степень родственности.
    Запрос должен быть маршрутизирован к экземпляру сервиса, исполняемому в компоненте Dispatcher, который специфицирован параметром nodeID. Этот параметр обязателен для запросов со значениям родственности high, absolute и control; соответственно, он задается в SOAP-заголовке запроса. Если запрашиваемый компонент Dispatcher недоступен, тогда данный запрос будет рассматриваться как неродственный.
  • session – родственность на уровне сеанса.
    Аналогично высокой степени родственности (high affinity), за исключением того, что параметр nodeID является необязательным. Если параметр nodeID не задан, запрос рассматривается как неродственный.
  • absolute – абсолютная родственность.
    Dispatcher должен маршрутизировать запрос к экземпляру сервиса, исполняемому в компоненте Dispatcher, который специфицирован параметром nodeID. Если специфицированный компонент Dispatcher недоступен, запрос заканчивается неудачей и возвращается ошибка SOAP Fault.
  • control – родственность на уровне управления.
    Аналогичен высокой степени родственности (high affinity), однако это значение зарезервировано для системных операций, связанных с исполнением отчетов (например, отмена отчета).

Компоненты IBM Cognos BI Dispatcher стремятся соблюдать предпочтения, выраженные степенью родственности. Как будет подробно рассмотрено ниже, процесс маршрутизации в явном виде учитывает значение родственности.

Снова вернемся к разговорам, поскольку необходимо рассмотреть еще один аспект разговоров. Если запрос не может быть обслужен в пределах конфигурируемого лимита времени, соответствующий разговор может стать асинхронным (async).

После отправки своего запроса клиент ждет результата, что приводит к блокировке клиента и всех задействованных ресурсов на стороне клиента и на стороне сервера. Это разумно только для коротких промежутков времени (несколько секунд). Если целевой сервис не сможет предоставить результат в эти сроки, он ответит сообщением типа still working (продолжаю работать), после чего клиент переключится в асинхронный режим. В асинхронном режиме клиент должен регулярно отправлять запросы типа heartbeat (тактовый импульс) с целью поддержания дальнейших разговоров. Если такие heartbeat-запросы не поступают в экземпляр сервиса, обрабатывающего запрос, то этот экземпляр будет исходить из предположения, что данный клиент больше не функционирует. Это приведет к завершению разговора, после чего целевой сервис прекратит обработку, а все ресурсы на стороне клиента и на стороне сервера будут высвобождены. Это объясняет, почему heartbeat-запросы являются вторичными запросами с абсолютным уровнем родственности. То же самое происходит, когда клиент отправляет команду отмены, за исключением того, что при этом используется вторичный запрос со значением родственности control affinity. Если разговор продолжается ожидаемым образом, клиент может выполнять другие задачи обработки в промежутках между тактовыми импульсами. То же самое применимо к ресурсам, задействованным в разговоре на стороне сервера, например, к потокам Dispatcher. В целом это повышает общую производительность системы.

После того как целевой сервис завершит обработку запроса, его состояние изменится на ready to provide result (готов предоставить результат), после чего клиент сможет извлечь результат посредством отсылки вторичных запросов с высокой степенью родственности (high affinity). После выполнения всей операции производится извлечение всех результатов, а клиент отсылает последний вторичный запрос с целью корректного завершения текущего разговора.

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

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

Концепция Advanced Routing (Усовершенствованная маршрутизация)

В предыдущем разделе была представлена концепция Server Group. Группы Server Group являются основой для важной возможности настройки в рамках общих концепций маршрутизации, рассматриваемых ниже.

В любой момент времени каждый Dispatcher является членом какой-либо группы Server Group. По умолчанию имеется лишь единственная неявно заданная группа default Server Group, членом которой являются все компоненты типа Dispatcher в системе IBM Cognos BI. Выравнивание нагрузки в среде IBM Cognos BI происходит только в рамках группы Server Group. Это означает, что в нормальных обстоятельствах после логического назначения запроса какой-либо группе Server Group он не способен покинуть эту группу Server Group.

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

В некоторых случаях нужно гарантировать, чтобы исполнение определенного отчета осуществлялось определенными компонентами типа Dispatcher. Некоторые рациональные примеры:

  • Отчеты, исполняемые руководителями, должны обрабатываться на выделенных аппаратных средствах.
  • Система может быть географически распределена. Обработка отчетов, вызываемых клиентами из определенного офиса, должна осуществляться локальными или географически близкими серверами с целью сведения к минимуму сетевой задержки и трафика.
  • Определенный тип соединения с базой данных может существовать или не существовать только у определенных компонентов типа Dispatcher. Например, если в некоторой системе имеется несколько компонентов типа Dispatcher, исполняющихся под Windows и UNIX, то экземпляры сервиса ReportService, хостинг которых осуществляет компонентом Dispatcher на базе UNIX, не смогут получить доступ к Microsoft SQL Server, поскольку для UNIX нет поддерживаемого клиента базы данных SQL Server. Необходимо гарантировать, что отчеты, исполняемые с привлечением SQL Server, будут обрабатываться экземпляром сервиса ReportService, размещенным на компоненте Dispatcher на базе Windows.
  • Отчеты, исполняемые с привлечением IBM Cognos PowerCubes, требуют, чтобы файлы соответствующего куба были доступны локально. Вместо того чтобы копировать эти файлы на несколько машин или использовать сетевое хранилище, можно обрабатывать все отчеты, связанные с определенными кубами, на машинах с локальным доступом к соответствующим файлам.

Механизм Advanced Routing позволяет маршрутизировать неродственные запросы к большинству сервисов в определенных группах Server Group согласно соответствующим правилам маршрутизации (Routing Rule). После того как запросы будут назначены в какую-либо группу Server Group, они подвергаются выравниванию нагрузки в этой группе Server Group.

Это положение имеет ограничения – оно распространяется на "большинство" сервисов, поскольку не все сервисы поддерживают механизм Advanced Routing. Этот механизм поддерживают все сервисы, которые исполняют запросы к определенным хранилищам данных, в том числе такие сервисы, как (Batch-) ReportService, PowerPlay Service, (Relational) Metadata Service и Query Service (обратите внимание, что некоторые из вышеперечисленных сервисов имеются только в версиях IBM Cognos BI 10.1 или 10.2).

Правила маршрутизации задают отображение т.н. наборов маршрутизации (Routing Set) на группы Server Group. Правила маршрутизации определяются в глобальном масштабе для всей системы IBM Cognos BI. Эти правила хранятся в единственном списке; управление ими осуществляется с помощью компонента Content Manager при посредстве инструмента Cognos Administration.

Рисунок 3. Кнопка Specify Routing Rules (Задать правила маршрутизации) в инструменте Cognos Administration
Figure 3 -

Сопоставление запросов с правилами маршрутизации осуществляется компонентом CM (а не компонентом типа Dispatcher!). Правила анализируются последовательно; первое же совпадение запускает процесс маршрутизации и останавливает процесс дальнейшей оценки правил. Другими словами, некоторый запрос может соответствовать правилу #1 и правилу #3, однако он будет всегда обрабатываться согласно правилу #1, поскольку первое совпадение запускает процесс маршрутизации.

Если запрос должен обрабатываться с использованием механизма Advanced Routing, то клиент, который отправляет этот запрос, отвечает за вызов компонента CM с целью оценки правил маршрутизации и за помещение информации Server Group Information в запрос, передаваемый в компонент Dispatcher. Необходимо отметить, что в рассматриваемом контексте "клиент" в действительности означает клиентский сервис. Это объясняется следующим образом. Всякий раз, когда заявка на исполнение запроса к определенному хранилищу данных направляется к исполняющему сервису, она будет отправлена к другому "клиентскому" сервису.

Например, если некоторый отчет был вызван в интерактивном режиме через Cognos Connection, то сервис Presentation Service (XTS) будет узнавать у компонента CM, подчиняется ли этот предназначенный для исполнения отчет каким-либо правилам маршрутизации. Если это так, то сервис CM Service в качестве ответа сообщает имя группы Server Group. Сервис Presentation Service добавляет это имя к запросу, который он передает для обработки своему локальному компоненту Dispatcher. Для плановых отчетов аналогичную роль клиентского сервиса играет сервис Monitoring Service (MS). Существует множество других подобных сценариев, однако в каждом случае имеется клиентский сервис, несущий ответственность за заполнение атрибута target Server Group (целевая группа Server Group) для запроса. Компонент Dispatcher просто придерживается этого порядка, он не добавляет правил маршрутизации и не оценивает их.

Рисунок 4. Определение правил маршрутизации в инструменте Cognos Administration
Figure 4 - Definition of Routing Rules in Cognos Administration

Окончательно то, к каким случаям исполнения запроса следует применить механизм Advanced Routing, определяет набор маршрутизации (Routing Set). Набор маршрутизации – это имя, метка, присвоенная набору объектов определенного типа. Существуют три типа наборов маршрутизации, которые различаются по типу объектов в соответствующем наборе.

  • Package Routing Set:
    Данный набор состоит из пакетов. Исполнение отчета согласно данным из определенных пакетов маршрутизируется в указанную группу Server Group.
  • Group Routing Set:
    Данный набор состоит из групп безопасности. Исполнение отчета инициируется пользователем, который является членом одной из групп в данном наборе, и маршрутизируется в указанную группу Server Group.
  • Role Routing Set:
    Данный набор состоит из ролей безопасности. Исполнение отчета инициируется пользователем, который имеет одну из ролей в данном наборе, и маршрутизируется в указанную группу Server Group.

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

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

Компонент CM будет проверять запросы на соответствие атрибутов этих запросов определенным правилам маршрутизации. Если соответствующее правило будет найдено, компонент CM возвратит имя специфицированной группы Server Group клиентскому сервису, который, как предполагается, добавит это имя к атрибутам запроса. После этого компоненты типа Dispatcher будут маршрутизировать запрос любому компоненту Dispatcher в этой целевой группе Server Group. В целевой группе Server Group может происходить выравнивание загрузки; в конечном итоге этот запрос будет назначен экземпляру запрашиваемого сервиса. Если ни один из экземпляров запрашиваемого сервиса не будет доступен, запрос завершится неудачей, после чего будет сгенерировано сообщение об отсутствии доступного сервиса для обработки запроса данного типа.

Механизм Advanced Routing весьма универсален и способен значительно улучшить обработку нагрузки в целом и формирование трафика посредством маршрутизации к выделенным ресурсам.


Процесс маршрутизации

Теперь, когда мы представили все необходимые концепции, мы, наконец, можем описать процесс маршрутизации.

Примечание: Это изложение имеет концептуальный характер и не всегда строго описывает последовательность шагов для каждого действия. Тем не менее этого описания вполне достаточно для освоения концепций, рассматриваемых в этом документе.

Шаг 1. Выявление обработчиков

Обработка в компоненте Dispatcher осуществляется в соответствии со статическим списком так называемых обработчиков (handler). Когда Dispatcher получает запрос, он опрашивает каждого обработчика, чтобы узнать, сможет ли тот обработать полученный запрос. Имеются обработчики для выполнения функций, таких как аутентификация, выравнивание нагрузки и т.д., а также для сервисов, таких как Presentation Service. Не углубляясь в детали, достаточно сказать, что каждый обработчик определяет последовательность шагов по обработке полученного запроса, которая может включать вызовы других обработчиков. По результатам исследования обработчиков формируется план исполнения для обработки запроса.

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

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

Шаг 2. Выявление целевого сервиса.

Следующий шаг состоит в выявлении целевого сервиса, способного обработать данный запрос. Целевой сервис выявляется на основе следующей информации в представленном порядке.

  • HTTP-заголовок SOAPAction
    Например, http://developer.cognos.com/schemas/reportService/1
    В данном случае заголовок SOAPAction будет содержать ссылки на конкретные схемы, которые подразумевают использование определенного сервиса.
  • Service Mappings(Отображения сервиса)
    У каждого компонента типа Dispatcher имеется статический список SOAPAction -> Service mappings, из которого можно извлечь целевой сервис.
  • URL-параметр “b_action”
    HTTP-команда GET или POST для Dispatcher может содержать параметр b_action, значение которого указывает на целевой сервис. Например, параметр b_action=xts.run указывает на сервис Presentation Service (XTS)
  • PATH_INFO для запроса
    Некоторые URL-маршруты указывают на целевой сервис.
    Например, /cgi-bin/cognosisapi.dll/gd/… указывает на определенное действие (извлечение подготовленной к отображению схемы или диаграммы), которое выполняется определенным обработчиком/сервисом.
  • Если запрос не содержит ни одного из вышеупомянутых указаний, он перенаправляется на начальную страницу IBM Cognos Connection, что подразумевает использование сервиса Presentation Service.

После выполнения данного шага осуществляется аутентификация запроса и выявление целевого сервиса.

Обработка запросов к Content Manager

Если целевым является сервис Content Manager Service, то запрос маршрутизируется к активному компоненту Content Manager, вне зависимости от таких опций, как Advanced Routing, Server Group или Load-Balancing. Это необходимо для функционирования продукта.

Обработка запросов со значениями родственности Absolute Affinity и Control Affinity

Если родственность представленного запроса имеет значение Absolute Affinity или Control Affinity, он не годится для применения механизма Advanced Routing или для выравнивания загрузки. Этот запрос перенаправляется компоненту Dispatcher, который указан в идентификаторе NodeID данного запроса. Если это действие завершится неудачей, то выполнение данного запроса прекратится и будет создано сообщение об ошибке, которое будет записано в журнал и, возможно, отослано обратно клиенту.

Формирование представления Cluster View

На этом шаге Dispatcher формирует набор потенциальных целевых компонентов Dispatcher, на которых исполняются доступные экземпляры запрашиваемого сервиса. Этот набор имеет название Cluster View.

Если реальный запрос специфицирует целевую группу Server Group, то представление Cluster View будет содержать только компоненты Dispatcher из этой группы Server Group. Такая ситуация имеет место в случае применения механизма Advanced Routing. Если целевые группы Server Group не были определены, то представление Cluster View потенциально способно содержать любой компонент Dispatcher из любой группы Server Group (в том числе из группы Default Server Group), в которой исполняется доступный экземпляр запрашиваемого сервиса.

Учет родственности

Следующий компонент Dispatcher попытается учесть значение родственности. Запросы со значениями родственности Absolute Affinity и Control Affinity были обработаны на предыдущем шаге, поэтому у любого запроса, обрабатываемого на данном шаге, родственность может иметь значение только High Affinity или Session Affinity. Компонент Dispatcher осуществляет перенаправление к запрашиваемому компоненту Dispatcher, если тот присутствует в представлении Cluster View, сформированном на предыдущем шаге. Если это действие завершится неудачей, поскольку требуемый Dispatcher отсутствует в представлении Cluster View (что маловероятно) или поскольку запрашиваемый сервис в этом компоненте Dispatcher недоступен по причине его загрузки (т.е. к данному моменту какой-либо другой запрос уже израсходовал все свободные ресурсы) либо сбоя, то данный запрос просто объявляется неродственным. После этого обработка продолжается.

Процесс выравнивания нагрузки

Теперь, когда представление Cluster View сформировано и когда для распределения остались только неродственные запросы, производится оценка выравнивания нагрузки.

Сначала осуществляется проверка режима выравнивания нагрузки.

Если этому режиму присвоено значение Cluster Compatible, то Dispatcher попытается назначить данный запрос локальному экземпляру запрашиваемого сервиса (который тем не менее должен присутствовать в представлении Cluster View), в результате чего выравнивание нагрузки будет проигнорировано. Другими словами, несмотря на то, что данный запрос подпадает под применение выравнивания нагрузки, локальный экземпляр получает наивысший приоритет. При этом группы Server Group по-прежнему учитываются. Представление Cluster View содержит только компоненты Dispatcher, образующие нужную группу Server Group. Если компонент Dispatcher, обрабатывающий данный запрос, отсутствует в представлении Cluster View, то вышеуказанное назначение окажется неудачным. То же самое произойдет в том случае, если локальный компонент Dispatcher не предлагает запрашиваемого сервиса. При неудачной попытке применения режима Cluster Compatible используется процесс fall-back, который осуществляется согласно алгоритму Weighted Round Robin, как в случае любого другого запроса.

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

В конечном итоге, если выбран режим выравнивания нагрузки Weighted Round Robin или если режим выравнивания нагрузки Cluster Compatible завершился неудачей, то выравнивание нагрузки для запроса осуществляется между экземплярами запрашиваемого сервиса, которые предлагаются компонентами типа Dispatcher в рамках представления Cluster View.

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


Приложение A Известные проблемы

Требования FRONT Dispatcher

Печальную известность приобрело поведение, довольно часто воспринимаемое как проблема или как дефект в средах, в которых был сконфигурирован механизм единого входа в систему (SSO, Single Sign-On) и в которых клиенты обращаются к компонентам типа Dispatcher непосредственно, без использования компонента типа Gateway.

Типичными примерами сред без компонента типа Gateway являются ситуации, когда продукт IBM Cognos BI развертывается на таком сервере приложений, как IBM WebSphere, а на веб-уровне используются плагины серверов приложений. Другой пример – ситуации, в которых использование компонента типа Dispatcher в качестве точки входа является разумным для обеспечения соответствия продукта (отсутствие подходящего шлюза, в частности, 64-разрядных реализаций MOD) или для соблюдения инфраструктурных требований. Нередко задачу выравнивания нагрузки выполняют внешние решения, которые также балансируют клиентские запросы между несколькими точками входа Cognos.

В подобных средах при каждой n-й попытке входа (а иногда - даже спорадически) механизм SSO отказывает, а клиенту взамен возвращается XML-текст. Следует, однако, отметить, что эта ситуация обуславливается нынешним дизайном продукта и устраняется простым изменением конфигурации. Необходимо помнить представленное выше определение компонентов типа Front Dispatcher.

Опишем происходящие события (в предположении конфигурационных значений по умолчанию для Dispatcher Servlet Context-Root).

  1. Запрос по адресу http(s)://<host>:<port>/p2pd/servlet/dispatch" поступает в Dispatcher. Это произвольный URL-адрес, который используется начальным запросом нового клиентского сеанса.
    Таким образом, доступ осуществляется к компоненту типа FRONT Dispatcher.
  2. Поскольку нет никакого другого указания на то, вызов какого сервиса должен осуществляться, данный запрос назначается сервису XTS (Presentation Service).
  3. Это первичный запрос (а не вторичный запрос в рамках разговора), не имеющий родственности, поэтому он обрабатывается механизмом выравнивания нагрузки.
  4. В конфигурации по умолчанию для режима выравнивания нагрузки выбирается значение Weighted Round Robin.
    Теперь, если в текущей группе Server Group доступно более одного экземпляра сервиса Presentation Service (по умолчанию все компоненты типа Dispatcher являются членами группы default Server Group), то данный запрос может быть направлен любому компоненту Dispatcher в этой группе Server Group, который осуществляет хостинг одного из доступных экземпляров сервиса Presentation Service. Это неявно подразумевает, что данный запрос вполне может быть направлен на удаленный экземпляр сервиса на другом компоненте Dispatcher!
  5. Обрабатывающий компонент Dispatcher (осуществляющий хостинг экземпляра XTS, которому был назначен данный запрос) проверяет сеанс на наличие аутентификации. Описываемый клиентский сеанс еще не прошел аутентификацию, поэтому инициируется процедура аутентификации, которая предусматривает передачу данного запроса сервису Content Manager Service. Исходный запрос сохраняется (например, посредством его перемещения в стек).
  6. Запрос вместе с некоторой дополнительной информацией отсылается в сервис CAMAAAsyncService (это справедливо для версии IBM Cognos 10; в предыдущих версиях запрос был бы направлен в сервис CMService).
  7. Сервис CAM-AAA определяет, какому провайдеру аутентификации следует передать данный запрос. Этот выбор осуществляется на основе параметра URL (CAMNamespace) или на основе того факта, что для аутентификации доступен лишь единственный активный провайдер аутентификации.
  8. Запрос направляется провайдеру аутентификации, выбранному для выполнения аутентификации на предыдущем шаге. Этот провайдер проверяет наличие данных для входа в систему, которые были бы достаточны для обработки аутентификационного запроса с помощью сконфигурированного провайдера. Эта проверка дает отрицательный результат, иначе никаких проблем бы не возникло.
  9. После этого провайдер аутентификации инициирует механизм SSO; другими словами, он должен бросить исключение SystemRevoverableException, которое с технической точки зрения представляет собой ответ с использованием HTTP-кода состояния 599 и некоторых специфических данных.
  10. Этот ответ возвращается отправителю, который является обрабатывающим компонентом Dispatcher из шага 5.

ТЕПЕРЬ: Если обрабатывающий компонент Dispatcher не совпадает с компонентом FRONT Dispatcher, к которому осуществляется обращение (на шаге 1), происходит следующее.

  1. Обрабатывающий компонент Dispatcher устанавливает, что он не является компонентом типа FRONT Dispatcher для данного сеанса, который получил исходный запрос. В результате этого он не отвечает за обработку ответа, полученного от провайдера аутентификации (шаг 9). Вместо этого он преобразует/оставляет этот ответ в его исходном формате (в SOAP, т.е. в XML) и передает его фактическому компоненту FRONT Dispatcher для данного сеанса.
  2. Этот компонент FRONT Dispatcher рассматривает ответ, полученный от взаимодействующего с ним компонента Dispatcher, как нормальный ответ на запрос, который, как предполагается, должен быть передан клиенту; что FRONT Dispatcher и делает.

Именно таким образом XML-код появляется в браузерных клиентах (поскольку они знают, как представлять его) или возвращается клиентам других типов (таким как Framework Manager).

Желаемое поведение достигается только в том случае, если обрабатывающий компонент Dispatcher (т.е. тот, который осуществляет хостинг экземпляра сервиса Presentation Service, обрабатывающего данный запрос) является тем же самым компонентом, к которому осуществляется обращение (FRONT-компонентом для данного сеанса) на шаге 1. В этом случае происходит следующее.

  1. Обрабатывающий компонент Dispatcher устанавливает, что он является компонентом типа FRONT Dispatcher для данного сеанса и поэтому несет ответственность за обработку ответа.
  2. Dispatcher исследует код ответа на наличие каких-либо особенностей. Он находит код HTTP-ответа 599, в результате чего инициирует выполнение специального кода обработки SSO.
  3. Этот SSO-код исследует SOAP-запрос (с XML-синтаксисом) и находит сообщение SystemRecoverableFault. Это порождает вызов соответствующего обработчика для выполнения необходимых действий (это осуществляется только для запросов на сервис XTS и на сервис CM Service).
    В рамках этого обработчика компонент Dispatcher реагирует на SystemRecoverableException следующим образом: сначала он извлекает значение переменной среды из своей локальной среды CGI, а затем повторяет аутентификационный запрос к провайдеру аутентификации, но на этот раз передавая извлеченное значение переменной в виде параметра со знаком.
  4. После того как провайдер аутентификации получает этот второй запрос с прикрепленным к нему значением переменной, осуществляется аутентификация. Если успешный ответ содержит требуемый контент, то cookie-файл cam_passport и идентификаторы сеанса рассматриваются как cookie. Если аутентификация оказывается неудачной, то провайдер аутентификации выдает исключение UnrecoverableException, которое будет использоваться в качестве первого ответа. В этом случае Dispatcher перехватывает исключение и возвращает клиента обратно на страницу входа в систему.

Приведенное выше объяснение позволяет понять, что для предотвращения XML-ответов, отсылаемых обратно клиенту, необходимо сделать так, чтобы начальные запросы для неаутентифицированного сеанса обрабатывались только экземплярами сервиса Presentation Service на компоненте FRONT Dispatcher для данного сеанса. Изложим то же самое иными словами.

  • Сервис Presentation Service должен исполняться на компоненте типа FRONT Dispatcher.
  • Начальные запросы в рамках сеанса должны обрабатываться локальным экземпляром сервиса Presentation Service, который исполняется на компоненте FRONT Dispatcher именно для данного сеанса. Они не должны маршрутизироваться к другим сервисам.

Такой результат может быть достигнут с помощью любой из этих двух конфигураций.

  • Необходимо гарантировать, что в определенной группе Server Group имеется лишь один компонент типа FRONT Dispatcher, на котором исполняется единственный экземпляр сервиса Presentation Service в этой группе Server Group.
  • Этот подход может быть с легкостью применен для явного формирования дополнительных групп Server Group, в которые помещен единственный компонент Dispatcher, соответствующий вышеупомянутому требованию. Подобным образом также можно указать конкретные точки входа для клиентов определенных типов, например, одну точку входа Dispatcher для клиентов Framework Manager, специальный набор точек входа для браузерных клиентов и т.д.
  • В неявном виде это означает, что если не было определено никаких групп Server Group и существует несколько экземпляров сервиса Presentation Service, то возникает проблема отсутствия необходимых конфигурационных изменений, поскольку все компоненты типа Dispatcher сконцентрированы в одной группе Server Group. Если в какой-либо группе Server Group имеется несколько компонентов типа FRONT Dispatcher, то для них следует выбрать режим выравнивания нагрузки под названием Cluster Compatible. Необходимо помнить, что если для исполнения на компоненте FRONT Dispatcher сконфигурированы какие-либо дополнительные сервисы (помимо минимального набора сервисов в составе Dispatcher Service, Presentation Service и Dispatcher Service), то режим Cluster Compatible также применяется и к этим сервисам; другими словами, локальная обработка отменяет выравнивание нагрузки, когда это возможно.

Экземпляры сервиса Dispatcher Service

После формирования групп Server Group необходимо гарантировать, что в каждой из них будет исполняться не менее одного экземпляра сервиса Dispatcher Service. В противном случае запросы могут маршрутизироваться некорректно.

К примеру, это может произойти в случае формирования группы Server Group, содержащей лишь один узел, в котором установлен только компонент Content Manager. По умолчанию в таких узлах сервис Dispatcher Service не исполняется.

Рекомендуется формировать группы Server Group таким образом, чтобы к явно определенным группам Server Group добавлялись только те узлы, в которых функционируют сервисы исполнения отчетов, такие как (Batch-)ReportService, Query Service (в случае версии IBM Cognos BI 10) и PowerPlay Service, а все остальные узлы оставались бы в группе Server Group по умолчанию, если это является приемлемым.

64-разрядный режим исполнения Report Server

В пакете IBM Cognos BI version 10.1 Refresh Pack 1 (10.1.1) имеется новая функция, которая позволяет конфигурировать режим исполнения Report Server как 32-разрядный или как 64-разрядный. Этот выбор по существу определяет, будет ли исполнение отчетов на основе пакетов реляционных источников данных осуществляться в режиме совместимых запросов (CQM – унаследованная, такая же, как в версии 10.1, исполняемая 32-разрядная программа на C++) или в новом режиме динамических запросов (DQM - 64-разрядный Java-механизм).

Применительно к маршрутизации следует помнить, что хотя механизм DQM и сконфигурирован, маршрутизация запросов базируется на доступности сервиса (Batch)ReportService, а не сервиса Query Service. Последний из упомянутых сервисов является не целевым сервисом для выравнивания нагрузки, а скорее вспомогательным сервисом для сервиса (Batch)ReportService. Только если будет доступен локальный экземпляр сервиса ReportService, будет использоваться и размещенный вместе с ним сервис Query Service.

Составление расписаний

Для всей фоновой обработки основным является сервис Monitoring Service (MS). В отличие от активного выравнивания нагрузки с помощью компонента типа Dispatcher вышеупомянутый механизм для фоновой обработки осуществляет т.н. "автоматическое выравнивание нагрузки" и работает принципу "извлечения по запросу".

Экземпляр сервиса Monitoring Service исследует системную очередь глобальных задач и сопоставляет ее элементы с локально доступными “целевыми сервисами”. Только если в том же компоненте Dispatcher (локальном) доступен соответствующий целевой сервис, сервис Monitoring Service станет выяснять, имеются ли у этого экземпляра целевого сервиса необходимые ресурсы для выполнения еще одной задачи. Ответ на этот вопрос определяется количеством нераспределенных родственных соединений для этого сервиса. Это количество может быть сконфигурировано в инструменте Cognos Administration на уровне отдельного сервиса. При наличии свободного соединения сервис Monitoring Service извлекает задачу из очереди, настраивает средства для надзора за ее исполнением и передает эту задачу целевому сервису для обработки.

Таким образом, только если сервис Monitoring Service расположен в том же компоненте Dispatcher, в котором размещен экземпляр другого сервиса, например, сервиса Agent Service, то именно этот экземпляр сервиса Monitoring Service извлечет задачу из глобальной очереди задач и запустит ее на исполнение. В неявном виде это означает, что для того, чтобы целевые сервисы смогли получать выделенную им работу, сервис Monitoring Service должен исполняться на компоненте Dispatcher. К целевым сервисам относятся следующие сервисы:

  • Batch Report Service
  • PowerPlay Service
  • Agent Service
  • ContentManager Service
  • Job Service
  • Index Update Service
  • Delivery Service
  • ...

Если эти сервисы исполняются на компоненте Dispatcher, на котором не исполняется сервис Monitoring Service, то они не будут участвовать в работе над задачами.

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

По этой причине рекомендуется иметь работающий сервис Monitoring Service практически в каждом компоненте Dispatcher. Этот сервис не будет потреблять большого объема ресурсов до тех пор, пока он не станет реально контролировать исполнение фоновой обработки, что он способен делать только при наличии активных экземпляров целевых сервисов, хостинг которых осуществляет тот же компонент Dispatcher. Это, например, означает, что исполнение сервиса Monitoring Service на "маршрутизирующем" компоненте Dispatcher, на котором исполняются лишь минимальный набор таких сервисов, как Dispatcher Services и Presentation Service, не причинит никакого вреда. В то же время на компоненте с установленным сервисом Content Manager сервис Monitoring Service требуется лишь для того, чтобы выполнять такие фоновые задачи Content Manager Service, как развертывание. Если сервис Monitoring Service, который на таких компонентах активируется по умолчанию, будет отключен, то развертывание окажется неудачным.

Что касается маршрутизации, то сервис Monitoring Service следует отключать на компоненте Dispatcher только в том случае, если на этом компоненте Dispatcher нет никаких целевых сервисов и сервиса Presentation Service.

Оригинал статьи: IBM Cognos Proven Practices: IBM Cognos BI Dispatcher Routing Explained.

Комментарии

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=Information Management
ArticleID=945176
ArticleTitle=Проверенные приемы IBM Cognos: Маршрутизация с помощью компонентов IBM Cognos 8 BI Dispatcher
publish-date=09162013