Содержание


Установка и настройка стандартной топологии Decision Server Insights

Новый продукт IBM ODM Advanced V8.7 Decision Server Insights позволяет предприятиям выявлять риски и коммерческие возможности и реагировать на них на самой ранней стадии. Decision Server Insights получает данные в виде событий, поступающих из разных источников, таких как бизнес-системы, социальные сети, мобильные устройства и датчики. Чтобы извлечь полезные идеи, которые позволяют принимать обоснованные решения, события обрабатываются с использованием аналитических функций и бизнес-правил, которые влияют на данные, полученные из этих событий, и данные, хранящиеся в памяти.

Для эффективного выполнения такой обработки Decision Server Insights требуется платформа исполнения, способная обрабатывать большое количество событий, обычно порядка десятков тысяч в секунду, и допускающая линейное масштабирование. Распределенная сеть обработки данных WebSphere eXtreme Scale и сервер приложений WebSphere Application Server Liberty Profile обеспечивают нужное сочетание функциональных возможностей, позволяя выполнять обработку транзакций такого масштаба в оперативной памяти.

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

Зачем нужна стандартная топология

Топологии «на все случаи жизни», способной удовлетворить любые требования заказчика, не существует. Разные приложения могут иметь нефункциональные требования разного уровня и разную толерантность к риску. Описание стандартной топологии Decision Server Insights преследует две цели: 1) сбалансированно удовлетворить «типичный» набор нефункциональных требований с учетом любых ограничений программного обеспечения IBM ODM и того программного обеспечения, которое на нем работает или зависит от него, и 2) обеспечить понимание требований, параметров и возможностей, определяющих и ограничивающих выбор определенной топологии.

Основные понятия WebSphere eXtreme Scale

Этот раздел знакомит читателя с минимальным набором концепций WebSphere eXtreme Scale, необходимых для понимания конфигурации стандартной топологии.

WebSphere eXtreme Scale – это «эластичная» сеть обработки данных в оперативной памяти. Чтобы уметь настраивать эту сеть, нужно иметь представление о следующих понятиях:

  • карта данных (map)– это простая структура данных, состоящая из пар "ключ значение";
  • множество карт данных (map set) — совокупность логически связанных карт данных, которые можно распределять между несколькими серверами;
  • сеть (grid) – в WebSphere eXtreme Scale это коллекция множеств карт данных, которая может охватывать несколько виртуальных машин Java и с которой можно устанавливать связь и получать доступ к данным;
  • раздел (partition) – подмножество данных, содержащихся в множестве карт данных, плюс любые реплики, которые может иметь каждое подмножество. Количество разделов (n) представляет собой настраиваемый атрибут множества карт данных. Данные множества карт распределены по n разделам в соответствии со значениями hashcode() ключевого объекта;
  • реплика (replica) – репликация обеспечивает механизм избыточности, посредством которого достигается высокая готовность в среде WebSphere eXtreme Scale. Реплика представляет собой копию исходных данных раздела, которая хранится удаленно по отношению к исходной и другим репликам. Синхронная реплика обновляется транзакционно при обновлении исходной реплики, что гарантирует отсутствие потери данных в случае потери исходных данных. Асинхронная реплика не обновляется транзакционно по отношению к исходной реплике, и нет никакой гарантии идентичности асинхронной реплики исходным данным;
  • сегмент (shard) – обеспечивает физическое хранение исходной или любой другой реплики в разделе. В разделе всегда есть исходный сегмент и может быть один или несколько сегментов-реплик в зависимости от степени требования высокой готовности;
  • контейнер сети (grid container) – контейнер для сегментов;
  • сервер контейнера сети (grid container server) – виртуальная машина Java, на которой работает WebSphere eXtreme Scale и размещается один или несколько контейнера сети. Decision Server Insights использует в качестве своих серверов контейнера сети профиль WebSphere Application Server Liberty.
    Примечание. Предпочтительная топология сети Decision Server Insights имеет всего один контейнер сети на каждый сервер контейнера сети. Кроме того, на каждой хост-машине выполняется только один сервер контейнера сети. По этой причине в настоящем руководстве термин контейнер используется для обозначения как сервера контейнера сети, так и контейнера сети, за исключением тех случаев, когда требуется соответствующее разделение понятий. Хост-машина в этом руководстве называется узлом контейнера;
  • служба каталога – для отслеживания разделов и сегментов, перераспределения сегментов в случае подключения контейнера к сети или отключения контейнера, наблюдения за работоспособностью сети и предоставления клиентам сети служб поиска данных требуется некоторый интеллект. Эти действия выполняет служба каталога. Работу серверов по обеспечению службы каталога координирует один или несколько серверов каталога. При наличии нескольких серверов каталога один из них несет особую ответственность и называется главным или основным сервером каталога. Группа серверов каталога вместе с группой серверов контейнера, которые они контролируют, составляет домен службы каталога;
  • кворум (quorum) – для операций жизненного цикла сети требуется соглашение между членами группы серверов каталога о необходимых действиях. Например, если происходит частичное отключение сети, связь между серверами каталога может прерваться, и основными серверами могут стать несколько серверов каталога. Такая ситуация называется синдромом дробления. Если разрешен кворум, то в таких случаях работа сети приостанавливается, но для восстановления после потери кворума обычно требуется ручное вмешательство. См. раздел Кворумы серверов каталога в документации WebSphere eXtreme Scale V8.6. По состоянию на WebSphere eXtreme Scale V8.6 введение кворума большинства означает, что пока большинство (более половины) членов группы службы каталога остаются активными и «знают» друг друга, имеет место кворум, и сеть может продолжать работу. Это одна причин иметь три сервера каталога, а не два (или любое нечетное число серверов вместо четного);
  • конечные точки кластера серверов каталога – контейнеры используют конечные точки кластера серверов каталога, которые включены в конфигурацию сервера контейнера для установления связи с серверами каталога. Они становятся частью домена службы каталога, а это означает, что они становятся частью сети.

Основные понятия Decision Server Insights

Подробный обзор возможностей Decision Server Insights выходит за рамки этого руководства. За дополнительной информацией обращайтесь к документации продукта IBM Operational Decision Manager Advanced V8.7 Decision Server Insights. Это руководство ограничивается представлением минимального набора базовых понятий, относящихся стандартной топологии.

Решения Decision Server Insights, которые можно рассматривать как разновидность приложения, хранят в сети сущности (объекты данных) и обрабатывают события, которые обычно связаны с этими сущностями. События передаются в контейнер, где хранятся данные с соответствующим идентификатором. В контейнере они обрабатываются соответствующими агентамиправил, Java или предикативной оценки (IBM SPSS Statistics).

События из внешних систем могут поступать в среду выполнения Decision Server Insights непосредственно через Solution Gateway API (с применением Java) или косвенно через входные каналы. Для входных каналов настраивается один или несколько серверов профиля Liberty в качестве серверов входных каналов, выполняющих роль моста между внешними конечными точками и Solution Gateway API. Исходящие события, передаваемые во внешние системы, направляются в один или несколько сервероввыходных каналов.

Стандартная топология Decision Server Insights

Стандартная топология Decision Server Insights – это сосредоточенная топология. Многозональные топологии или топологии с несколькими главными узлами выходят за рамки этого руководства, хотя во многих случаях они рекомендуются.

Преследуемые цели

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

  • сеть должна быть постоянно доступной в «нормальном» режиме работы;
  • сеть должна выдерживать потерю одного сервера-контейнера без потери данных и доступа к данным;
  • сеть должна допускать управляемое отключение одного контейнера в целях применения «последовательных обновлений» или любых других мероприятий по техобслуживанию;
  • сеть должна принимать и использовать новые контейнеры (в пределах, определяемых установленным числом разделов и реплик);
  • сеть должна допускать одновременную потерю двух контейнера с приемлемым риском некоторой потери данных;
  • служба каталога должна быть высоконадежной и опираться на кворум большинства;
  • в случае аварии, когда теряются более двух контейнера (например, при отключении электроэнергии), сеть данных должна восстанавливаться. При этом приемлем риск некоторой потери данных;
  • в случае управляемого выключения сети (например, если нужно увеличить число разделов) сеть данных должна восстанавливаться без потерь;
  • система должна допускать отказ по крайней мере одного сервера входных и одного сервера выходных каналов;
  • перечисленные требования не должны значительно повлиять на пропускную способность в отношении событий.

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

Серверы входных и выходных каналов

Серверы входных и выходных каналов отвечают за ввод потока событий в систему и его вывод из системы, так что должна иметь место некоторая избыточность этих серверов. Хорошей отправной точкой является использование для того и другого двух разных машин, что составляет минимальное требование по устранению единой точки отказа. Эмпирического правила определения фактического количества серверов входных или выходных каналов, которое требуется для достижения определенной пропускной способности в отношении событий, не существует. Количество серверов входных и выходных каналов зависит от многих параметров, включая объем данных по событию, тип возможных преобразований событий, используется ли персистентность событий для Java Messaging Service (JMS) и тип используемого протокола (HTTP, JMS и т.п.). Для достижения наилучших результатов начните с двух серверов и контролируйте использование ресурсов (процессора, памяти и т.п.). При высокой интенсивности событий можно добавлять новые серверы входных и выходных каналов на той же машине до тех пор, пока не будет достигнут ее теоретический порог потребления ресурсов. После этого при необходимости можно добавить новые машины.

Служба каталога

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

Серверы контейнера

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

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

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

Максимальное количество контейнера, которые можно динамически добавлять к сети, ограничивается количеством разделов и числом реплик, настроенных для каждого раздела. Это ограничение связано с тем, что количество разделов можно изменить только тогда, когда сеть отключена, а также с тем, что не имеет смысла заводить больше серверов контейнера, чем максимальное число серверов, которые можно использовать. Это число определяется как количество разделов x (1 + количество реплик). Например, если у вас 20 разделов и две реплики, то 20 основных реплик + 20 x 2 реплики (= 20*(1+2)) дает максимум 60 контейнера, которые можно добавить к сети и которые будут фактически использоваться (по одной реплике или одному основному сегменту на каждую машину).

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

На практике, учитывая рекомендацию одного сервера контейнера на машину, хорошее правило – установить количество разделов, равное предполагаемому максимальному числу контейнера (C), умноженному на количество ядер хост-узла контейнера (М) и на два (т.е. C x М x 2). При этом предполагается, что у всех машин контейнера равное количество ядер. Кроме того, учитывая, что определенные операции WebSphere eXtreme Scale выполняются эффективнее, если количество разделов — простое число, рекомендуется округлить это число до следующего простого числа. Например, если предполагается иметь максимум 6 серверов контейнера, у каждого из которых по 4 ядра, то подходящим значением числа разделов будет: nextPrime(6 x 4 x 2) = 53. В конфигурации по умолчанию число разделов равно 127.

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

Рисунок 1. Сеть с тремя контейнерами и n разделами

Сохранение в базе данных

Decision Server Insights работает с сетью данных в оперативной памяти. Однако в сосредоточенной топологии необходимо сохранять данные сети в базе данных для обеспечения возможности послеаварийного восстановления или любых редких мероприятий по техобслуживанию, для которых требуется отключение сети. Можно выбирать между синхронным (сквозным) и асинхронным (с задержкой) режимами записи в базу данных. Использование синхронной записи необходимо тщательно обдумать, потому что обычно оно подразумевает высокий расход ресурсов производительности. С другой стороны, при асинхронной записи обновление базы данных выполняется пакетами и не требует высокого расхода ресурсов производительности. Частота обновлений базы данных зависит от уровня приемлемого риска и устанавливается в форме временного интервала и количества пакетных обновлений с использованием параметра writeBehind. Например, значение параметра конфигурации writeBehind, равное 'T20;C200', означает, что запись в базу данных происходит каждые 20 секунд или каждый раз, когда количество ожидающих обновлений достигает 200, смотря что наступит раньше.

Отметим, что в случае управляемого отключения сети не должно быть потери данных при выполнении следующие условий:

  • сначала остановлен поток входящих событий;
  • все события обработаны;
  • все ожидающие пакетные обновления записаны в базу данных.

Не выключайте сеть, пока не будут выполнены эти условия.

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

WebSphere eXtreme Scale может ставить обновления базы данных в очередь, что позволяет допустить некоторый простой базы данных, но в идеале база данных должна быть высокодоступной (например, с использованием механизма аварийного восстановления высокой готовности DB2). Для очень высокой интенсивности событий рассмотрите возможность использования высокомасштабируемой базы данных для гарантии того, что база данных не станет узким местом.

Описанная стандартная топология Decision Server Insights показана на рисунке 2.

Обратите внимание, что в примере для каждого сервера топологии Decision Server Insights используется отдельный физический сервер – такая конфигурация обеспечивает высокий уровень изоляции между компонентами. Целей высокой готовности и восстанавливаемости можно достичь при наличии минимум трех физических серверов, не считая базы данных. Однако топология с четырьмя серверами будет более подходящей в качестве минимальной топологии высокой готовности. Такая топология позволяет иметь четыре сервера контейнера, по одному на каждой машине. И на трех из этих машин может быть размещен сервер каталога. Кроме того, по крайней мере на двух из четырех физических серверов должны быть серверы входных и выходных каналов.

Рисунок 2. Стандартная топология Decision Server Insights

Установка и настройка

Для установки и настройки стандартной топологии Decision Server Insights используйте следующую стратегию:

  1. Установите IBM Installation Manager на каждый сервер, чтобы разрешить установку и обновление Decision Server Insights с использованием Installation Manager.
  2. С помощью Installation Manager установите Decision Server Insights на каждый из необходимых серверов. В примере к этому руководству используется 12 машин. Три из них образуют кластер каталога, четыре используются в качестве серверов контейнера, и еще есть два сервера входных и два сервера выходных каналов. Остальные машины (называемые прототипами) используются для создания прототипов серверов. Они помогают разрабатывать новые серверы, и ничего больше. Прототипы используются для клонирования серверов на каждую из 11 других машин топологии и на любые дополнительные машины, которые могут быть добавлены в будущем.
  3. Создайте и настройте серверы каталога на машинах-прототипах:
    1. Создайте прототип сервера каталога с помощью шаблона cisCatalog.
    2. Настройте файл начальной загрузки свойств для этого сервера.
    3. Настройте Secure Sockets Layer (SSL).
    4. Настройте реестр и роли пользователей.
    5. Клонируйте сервер каталога на три машины, предназначенные для кластера каталога.
  4. Создайте и настройте серверы контейнера на машинах-прототипах:
    1. Создайте прототип сервера контейнера с помощью шаблона cisContainer.
    2. Настройте файл начальной загрузки свойств для этого сервера.
    3. Настройте SSL.
    4. Настройте реестр и роли пользователей.
    5. Настройте сеть.
    6. Настройте сохранение в базе данных.
    7. Клонируйте сервер контейнера на четыре машины, используемые для размещения четырех серверов контейнера.
  5. Создайте и настройте серверы входных и выходных каналов на машинах-прототипах:
    1. Создайте прототипы серверов входных и выходных каналов, используя шаблоны cisInbound и cisOutbound соответственно.
    2. Настройте файл начальной загрузки свойств для этого сервера.
    3. Настройте SSL.
    4. Настройте реестр и роли пользователей.
    5. Клонируйте на две машины настроенный сервер входных каналов, а на оставшиеся две машины сервер выходных каналов.

Создание и настройка серверов каталога

Для обеспечения высокой готовности каталога eXtreme Scale создайте домен, состоящий из трех серверов каталога.

Шаг 1. Создание прототипа сервера каталога

Из installation_directory/runtime/wlp/bin на машине-прототипе выполните следующую команду для создания сервера по шаблону cisCatalog:

./server create cisCatalog --template=cisCatalog

Обратите внимание, что для параметра template используются два дефиса (--).

Шаг 2. Настройка файла каталога bootstrap.properties

Настройте конечные точки кластера каталога в файле bootstrap.properties, как показано в следующем примере. Измените vmwtpmxxxx на свои собственные имена узлов.

ia.clusterEndpoints=vmwtpm094x-cisCatalog:vmwtpm094x:6600:6601,vmwtpm0953-cisCatalog:vmwtpm0953:6600:6601,vmwtpm098d-cisCatalog:vmwtpm098d:6600:6601.

Примечание. Чтобы облегчить клонирование серверов каталога, избегайте переменных ${ia.serverName} и ${ia.host} при указании конечных точек кластера каталога.

Шаг 3. Настройка безопасности

Для создания среды безопасного сервера необходимо настроить следующие параметры:

  • SSL для безопасной связи;
  • реестр пользователей, обычно LDAP;
  • роль администратора для управления доступом (Java Management Extensions);
  • роли чтения и записи для REST API (только для серверов контейнера).

Примечание. Эта конфигурация предполагает защищенную сеть и не обеспечивает безопасность серверов в сети и связь между этими серверами. За дополнительной информацией обращайтесь к технической записке Обеспечение безопасности сети Decision Server Insights.

  1. Настройте SSL.
    Чтобы включить SSL-связь для серверов, необходимо сначала создать файл хранилища ключей. Хранилище ключей содержит сертификат для сервера, который в производственной среде должен быть выдан или подписан уполномоченным центром сертификации. За более подробной информацией обращайтесь к разделу Включение SSL-связи для профиля Liberty в документации продукта. Создайте хранилище ключей, содержащее самозаверяемый сертификат, с помощью утилиты безопасности из каталога installation_directory/runtime/wlp/bin, как показано в следующем примере: ./securityUtility createSSLCertificate --server=cisCatalog --password=ins1ghts --validity=1000 –subject=CN=*.ibm.com,O=IBM,C=UK
    Выполнение команды createSSLCertificate должно привести к следующему результату:
    Creating keystore /opt/IBM/ODMInsights87/runtime/wlp/usr/servers/cisCatalog/resources 
    /security/key.jks 
    Created SSL certificate for server cisCatalog 
    Add the following lines to the server.xml to enable SSL: 
       <featureManager> 
    <feature>ssl-1.0</feature>
    </featureManager> <keyStore id="defaultKeyStore" password="{xor}NjEsbjg3Kyw=" />

    Определение функции SSL уже присутствует в файле server.xml, так что вам не нужно добавлять его в этот файл. Однако в файл server.xml нужно скопировать определение хранилища ключей <keyStore id="defaultKeyStore" password="{xor}NjEsbjg3Kyw=" />. Иначе, можно раскомментировать определение хранилища ключей, уже имеющееся в файле server.xml, и просто добавить пароль. Эта настройка необходима для всех серверов, входящих в состав сети, и для всех серверов связи.

  2. Настройте реестр и роли пользователей.
    Для краткости в этом руководстве пропущена настройка реестра LDAP, которая обычно имеет место в производственной среде. За дополнительной информацией обращайтесь к разделу Настройка реестров пользователей LDAP документации WebSphere Application Server Network Deployment V8.5.5. Вместо LDAP в следующем примере используется базовый реестр, настроенный в файле server.xml:
    <basicRegistry id="basic" realm="DWRealm"> 
    <user name="admin" password="ins1ghts"/> 
    <group name="DWGroup"> 
    <member name="admin"/> 
    </group> 
    </basicRegistry>

    Еще в файле server.xml определите роль administrator, которая используется для доступа к JMX:

    <administrator-role> 
    <group>DWGroup</group> 
    </administrator-role>

Шаг 4. Разрешение кворума большинства

Чтобы разрешить кворум, добавьте свойство enableQuorum="true" в элемент xsServer в файле server.xml, как показано в следующем примере:

<xsServer catalogServer="true" catalogClusterEndpoints="${ia.clusterEndpoints}" 
 listenerPort="${ia.listenerPort}" transport="XIO" serverName="${ia.serverName}" enableQuorum="true"/> ]

Кроме того, для кворума большинства необходимо присвоить значение 'true' параметру виртуальной машины Java com.ibm.websphere.objectgrid.server.catalog.majority.quorum в файле jvm.options (которой находится в каталоге cisCatalog), как показано в следующем примере:

-Dcom.ibm.websphere.objectgrid.server.catalog.majority.quorum=true

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

I CWOBJ1251I: Quorum is enabled for the catalog service. 
I CWOBJ0054I: The value of the "com.ibm.websphere.objectgrid.server.catalog.majority.quorum" 
 property is "true"

Шаг 5. Клонирование серверов каталога

Клонируйте три сервера каталога из прототипа сервера каталога с помощью следующей команды, выполненной из каталога /opt/IBM/installation_directory/runtime/ia/bin::

./cloneServer cisCatalog root catalog_host_name  /opt/IBM/installation_directory/runtime

Создание и настройка серверов контейнера

Теперь создайте и настройте серверы контейнера.

Шаг 1. Создание прототипа сервера контейнера

Из каталога installation_directory/runtime/wlp/bin выполните следующую команду для создания сервера из шаблона cisContainer:

./server create cisContainer –template=cisContainer

Шаг 2. Настройка файла bootstrap.properties для контейнера

Настройте конечные точки каталога bootstrap в файле контейнера bootstrap.properties, как показано в следующем примере:

ia.bootstrapEndpoints=vmwtpm094x:2809,vmwtpm0953:2809,vmwtpm098d:2809

Во время клонирования 'localhost' автоматически заменяется соответствующим именем хоста.

Шаг 3. Настройка SSL

Для серверов контейнера используйте ту же конфигурацию безопасности, что и для серверов каталога. Скопируйте каталог resources из прототипа cisCatalog, например, /opt/IBM/ODMInsights87/runtime/wlp/usr/servers/cisCatalog/resources, в каталог cisContainer прототипа cisContainer.

Добавьте в файл server.xml прототипа сервера контейнера определение keyStore (<keyStore id="defaultKeyStore" password="{xor}NjEsbjg3Kyw=" />).

Шаг 4. Настройка реестра пользователей и ролей

Настройте базовый реестр в файле server.xml так же, как для сервера каталога:

<basicRegistry id="basic" realm="DWRealm"> 
<user name="admin" password="ins1ghts"/> 
<group name="DWGroup"> 
<member name="admin"/> 
</group> 
</basicRegistry>

В файле server.xml определите роль administrator, которая используется для доступа к JMX:

<administrator-role> 
<group>DWGroup</group> 
</administrator-role>

Для серверов контейнера необходимо настроить роли безопасности «читатель» (get) и «писатель» (get, post, put и delete), используемые API-интерфейсом REST, как показано в следующем примере:

<authorization-roles id="iaAuthorization"> 
<security-role name="iaRESTWriter"> 
<group name="DWGroup"/> 
</security-role> 
<security-role name="iaRESTReader"> 
<group name="DWGroup"/> 
</security-role> 
</authorization-roles>

Шаг 5. Настройка сети

Откройте файл installation_directory/runtime/wlp/usr/servers/cisContainer/grids/objectGridDeployment.xml.

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

Важное замечание. Во избежание лишней работы по выравниванию нагрузки при запуске сети выполните команду installation_directory/runtime/ia/bin/serverManager suspendbalancing после запуска серверов каталога и до запуска серверов контейнера. После запуска все серверы контейнера подадут команду serverManager resumebalancing, что гарантирует выполнение выравнивания нагрузки в сети во время запуска только один раз.

В примере из этого руководства количество контейнера по умолчанию 127 изменяется на 53.

После настройки множество карт данных 'iaMaps' выглядит примерно так:

<mapSet name="iaMaps" numberOfPartitions="53" numInitialContainers="3" minSyncReplicas="1" 
 minAsyncReplicas="1" maxSyncReplicas="1" maxAsyncReplicas="1" developmentMode="false">

Множество карт данных 'iaPreloadMaps' имеет аналогичную конфигурацию, но заметьте, что iaGrMaps имеет только один раздел.

Шаг 6. Сохранение объектов и событий

По умолчанию данные обрабатываются в сети и не сохраняются. Чтобы обеспечить сохранение данных для аварийного восстановления, выполните следующие действия:

  • Создайте новую базу данных.
  • Создайте таблицы базы данных с помощью DDL из файла your_installation_location\runtime\ia\persistence\sql\DB2\DB2Distrib.sql. Обратите внимание, что ваш администратор БД может пожелать внести некоторые изменения в DDL из соображений производительности или определенных стандартов организации.
  • Затем выполните следующие действия, чтобы разрешить функцию JDBC и создать определение источника данных в файле server.xml прототипа cisContainer:
  1. Добавьте <feature>jdbc-4.0</feature> в элемент featureManager.
  2. Раскомментируйте определение datasource в файле server.xml и укажите свои собственные свойства, например:
	<dataSource jndiName="jdbc/ia/persistence"> 
	   <connectionManager/> 
	   <jdbcDriver> 
	      <library> 
	         <fileset dir="/opt/DB2/java" includes="db2jcc4.jar db2jcc_license_cisuz.jar" /> 
	      </library> 
	   </jdbcDriver> 
	   <properties.db2.jcc 
	      databaseName="DSIDB" 
	      user="db2admin" 
	      password="pwd1" 
	      serverName="someHostName" 
	      currentSchema="ADMIN" 
	      portNumber="50000" /> 
	</dataSource>

Раскомментируйте также ia_persistence entry:

	<ia_persistence datasourceName="jdbc/ia/persistence" maxBatchSize="10000" maxCacheAge="1000" />

Наконец, укажите, какие карты данных должны сохраняться в файле objectgrid.xml. Самый простой способ сделать это – использовать шаблон в installation_directory/runtime/ia/persistence/grids/write-behind/objectgrid.xml. В этом руководстве используется шаблон write-behind, так что все карты данных сохраняются асинхронно.

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

<backingMap name="Entity.*" template="true" lockStrategy="PESSIMISTIC" 
 copyMode="COPY_TO_BYTES" pluginCollectionRef="EntityPlugins" 
 writeBehind="T10;C100" />

Шаг 7. Клонирование сервера контейнера

Клонируйте четыре сервера контейнера из прототипа сервера контейнера с помощью следующей команды, выполненной из каталога /opt/IBM/installation_directory/runtime/ia/bin:

./cloneServer cisContainer root container_host_name  /opt/IBM/installation_directory/runtime

Шаг 8. Создание серверов входных и выходных каналов

Создайте прототипы серверов входных и выходных каналов из соответствующих шаблонов.

Настройте файл bootsrap.properties для сервера с использованием конечных точек сервера каталога.

Настройте параметры безопасности так же, как для сервера контейнера (роли авторизации API REST настраивать не нужно).

Раскомментируйте функцию безопасности приложения, как в следующем примере:
<feature>appSecurity-2.0</feature>

Настройте функции входных или выходных каналов, как того требует решение, например:

<featureManager> 
<feature>appSecurity-2.0</feature> 
<feature>ia:iaConnectivityInboundJMS-8.7.0</feature> 
<feature>wmqJmsClient-1.1</feature> 
</featureManager>

Заключение

В этом руководстве описана топология Decision Server Insights. Вы познакомились с необходимыми основными концепциями WebSphere eXtreme Scale и Decision Server Insights и с важными настраиваемыми элементами сети, такими как количество разделов. В руководстве рассмотрен набор нефункциональных требований к топологии и описан процесс выбора макета и конфигурации топологии, исходя из этих требований. Наконец, вы научились устанавливать и настраивать стандартную топологию.


Ресурсы для скачивания


Похожие темы

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=1023136
ArticleTitle=Установка и настройка стандартной топологии Decision Server Insights
publish-date=12032015