Ошибка "BEA-149259 Server ... in cluster ... is being brought up in administration state due to failed deployments" и вариант её решения

Ошибка:
В Weblogic-кластере сервер (в моём случае soa_server) стартует в статус ADMIN, а в логе серверы фигурирует ошибка:

...
<Emergency> <Deployer> <BEA-149259> <Server 'soa_server' in cluster 'SOA_Cluster' is being brought up in administration state due to failed deployments.>   
...

Причина:
Особенность состояния ADMIN в Weblogic-сервере: ошибки возникающие в состоянии PREPARE заставляют сервер оставаться в фазе ADMIN.

Вариант решения:
Исправить ошибки в состоянии PREPARE (лучший вариант) или запускать сервер с ключом:

-Dweblogic.deployment.IgnorePrepareStateFailures=true

Weblogic Cluster: принцип работы Сonsensus leasing

В Weblogic Cluster есть два механизма контроля миграции:

• Database - информация хранится/изменяется в СУБД;
• Сonsensus - информация хранится в памяти.

В данной статье пойдёт речь об принципах работы механизма Сonsensus.

Принцип работы:
Допущение: для простоты восприятия принципа работы будем считать, что данные хранятся в виртуальной таблице в памяти мастера (никакого отношения к таблицам СУБД не имеет).

Все сервера кластера периодически отправляют информацию о статусе, так называемые лизы (от слова leasing) мастеру кластера, которую он кладёт в "виртуальную" таблицу в памяти, а от него в ответ получают текущую копию виртуальной таблицы - делается это для обеспечения отказоустойчивость при выходе из строя мастера.

Мастер выбирается всеми запущенными серверами кластера. Сервер становится мастером после одобрения большинства. Если Node Manager сообщает, что статус сервера:

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

Механизм Сonsensus требует большинства серверов для продолжения функционирования: при выходе из строя (или невозможности доступа к мастеру) сервера кластер логически делится на две части - большая часть кластера продолжает, а меньшая завершает функционировать (переходит в статус FAILED).

В двухмашинной конфигурации использование Сonsensus Leasing проблематично и рекомендуется использование Database Leasing.

Пример:
При старте первого сервера он ищет остальных участников кластера, чтобы узнать есть ли мастер:

Если нет мастера, то он становится мастером:

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

Далее оба сервера пересматривают вопрос по мастеру кластера: если время старта второго меньше, чем первого (который на данный момент является мастером), то мастером становится второй сервер:

Аналогично с третьим и последующим серверами.

Кластеризация Oracle BAM 11g

Описание: Описана кластеризация BAM 11g в конфигуции с двумя физическими машинами.
ПО: RHEL 5.5, Weblogic 10.3.5, Oracle BAM 11.1.1.5 + некоторые патчи.

Есть простой BAM-домен следующей конфигурации:
Weblogic сервера:

• AdminServer - порт 7001;
• bam_server1 - порт 9001.

Есть две физические машины (с точки зрения ОС) с IP-адресами, например:

• 192.168.2.130
• 192.168.2.96

Создадим отказоустойчивую конфигурацию для Oracle BAM 11g.
Особенность: BAM Server является singleton-компонентом в Oracle BAM и может быть только один в Weblogic-домене. Его кластеризовать нельзя, обычно настраивается на него миграция сервера, а компоненты BAM Web кластеризуются как обычные Web-приложения.
Первоначальная конфигурация:

В случае выхода из строя первого физического сервера:

Последовательность шагов:

1. Необходимо разрешить пользователю операционной системы под которым развернут Oracle BAM (в нашем случае - это weblogic) полномочия для запуска команд /sbin/ifconfig и /sbin/arping. Для этого пользователем root добавим в файл /etc/sudoers следующую строку (выделена красным):
   

    ......
    ## Next comes the main part: which users can run what software on  
    ## which machines (the sudoers file can be shared between multiple  
    ## systems).  
    ## Syntax:  
    ##  
    ##   user  MACHINE=COMMANDS  
    ##  
    ## The COMMANDS section may have other options added to it.  
    ##  
    ## Allow root to run any commands anywhere  
    root  ALL=(ALL)    ALL  
    weblogic    ALL=NOPASSWD:  /sbin/ifconfig,/sbin/arping  
   
    ## Allows members of the 'sys' group to run networking, software,  
    ## service management apps and more.  
    ...... 

2. Для обеспечения работоспособности необходим дополнительный "плавающий"/виртуальный IP-адрес из той же подсети, например: 192.168.2.139. После этого выполнить следующие команды на первой машине:
   

    $ sudo /sbin/ifconfig eth0:1 192.168.2.139 netmask 255.255.252.0  
    $ sudo /sbin/arping -q -U -c 3 -I eth0 192.168.2.139  
   

3. Добавить в переменную PATH следующее (лучше на уровне профиля пользователя, если используется bash, то это файл ~/.bash_profile):
   

    PATH=$PATH:$MW_HOME/wlserver_10.3/common/nodemanager:$MW_HOME/user_projects/domains/bam_domain/bin/server_migration:$MW_HOME/wlserver_10.3/common/bin  
    export PATH
   

4. Зайти в bam_server1 и ввести Server Listen Address - 192.168.2.139.
5. Клонируем bam_server1 (переходим в "Environment"->"Servers", выбираем bam_server1 и нажимаем на кнопку "Clone"). Новый сервер:
   
   • Server Name - bam_server2;
   • Server Listen Address - 192.168.2.96;
   • Server Listen Port - 9002.
6. Создаем кластер:
   
   • Name - BAM_Cluster;
   • Messaging Mode - Unicast.
7. Добавляем в данный кластер оба сервера - bam_server1 и bam_server2.
8. На каждой физической машине (с т.з. операционной системы) сконфигурируем по Node Manager-у (подробнее здесь) и создадим две Weblogic-машины (Machines):
   
   • Machine1 - 192.168.2.130;
   • Machine2 - 192.168.2.96.
9. Соотнесём Weblogic-сервера и Weblogic-машины следующий образом:
   
   • bam_server1 - Machine1;
   • bam_server2 - Machine2.
10. Теперь соотнесём приложения и библиотеки с созданным нами кластером (BAM_Cluster), а не только с bam_server1:
    
    • DMS Application (11.1.1.1.0)
    • oracle-bam (11.1.1)
    • usermessagingdriver-email
    • usermessagingserver
    • wsil-wls
    • wsm-pm
11. Соотнести приложение "oracle-bam (11.1.1)" следующим образом:
    

    oracle-bam(11.1.1)	BAM_Cluster
    /oracle/bam	bam_server1
    oracle-bam-adc-ejb.jar	bam_server1
    oracle-bam-ems-ejb.jar	bam_server1
    oracle-bam-eventengine-ejb.jar	bam_server1
    oracle-bam-reportcache-ejb.jar	bam_server1
    oracle-bam-statuslistener-ejb.jar	bam_server1
    OracleBAM	BAM_Cluster
    OracleBAMWS	BAM_Cluster
    sdpmessagingclient-ejb.jar	bam_server1

12. Так же соотнести следующие Data Source-ы с кластером BAM_Cluster:
    
    • BAMDataSource;
    • mds-owsm;
    • OraSDPMDataSource.
13. Соотнести следующие Startup and Shutdown Classes с BAM_Cluster:
    
    • JOC-Shutdown;
    • JOC-Startup
14. Создать новый Data Source для механизма контроля миграции (если потребуется, то создать отдельного пользователя в СУБД. Не использовать административных пользователей, таких как SYS и SYSTEM) и соотнесём его с кластером BAM_Cluster.
15. Создадим необходимую служебную таблицу для механизма контроля миграции, для этого надо выполнить скрипт лежащий в $MW_HOME/wlserver_10.3/server/db/<СУБД>/leasing.ddl.
16. Перейти в "Services"->"Persistence Stores" и проверить какие типы Persistence Store-ов используются:
    • Если FileStore, то обеспечить доступ к директориям со второго сервера, как правило для этого используется раздел дискового массива или кластерной файловой системы.
    • Если JDBCStore, то соотнести используемый Data Source с кластером BAM_Cluster.
17. Запустить bam_server1 и bam_server2.
18. Зайти в Enterprise Manager (http://AdminServerHost:AdminServerPort/em) раскрыть меню BAM в нём должны быть три элемента:
    • OracleBamServer(bam_server1);
    • OracleBamWeb(bam_server1);
    • OracleBamWeb(bam_server2).
    Для каждого BAMWeb (OracleBamWeb(bam_server1) и OracleBamWeb(bam_server2)) нажать на них правой кнопкой мыши и выбрать "Mbean Browser" перейти в "oracle.bam.web"->"Server..."->"Application..."->"Config..." выбрать BAMWebConfig и изменить следующие параметры:
    • ServerName - IP-адрес или доменное имя BAM-сервера, в нашем случае это 192.168.2.139;
    • ServerPort - порт на котором запущен BAM-сервер, в нашем случае это 9001;
19. Перезапустить AdminServer.
20. Необходимо донастроить Node Manager-ы на каждой физической машине, добавить опции для сетевых интерфейсов в файл nodemanager.properties:

     Interface=eth0  
     NetMask=255.255.255.0  
     UseMACBroadcast=true  
    

    где eth0 - имя сетевого интерфейса на котором будет поднят "плавающий"/виртульный IP-адрес.
21. Затем в Weblogic Console выбрать кластер BAM_Cluster и перейти в "Configuration"->"Migration" и заполнить поле "Data Source For Automatic Migration:", где выбрать созданный Data Source для механизма контроля миграции (см. пункт 13).
22. Далее перейти в "Environment"->"Servers" выбрать bam_server1. Перейти в "Configuration"->"Migration" и поставить галку "Automatic Server Migration Enabled".
23. Перезапустить сервера и протестировать миграцию.

Конфигурирование автоматической миграции JMS-серверов

Описание: WebLogic-кластере приложения и Data Source-ы могут быть распределены на всех узлах кластера, но есть несколько типов singleton-ресурсов, которые должны быть в единственном экземпляре в кластере:

• JMS-сервера и их destinations;
• JMS SAF-агенты;
• Persistance store;
• Менеджер транзакций и его логи;
• Созданные пользователем классы (должен быть имплементирован интерфейс weblogic.cluster.singleton.SingletonService).

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

• Миграция всего Managed-сервера;
• Миграция сервисов (т.е. данных singleton-ресурсов с одного Managed-сервера на другой в Weblogic-кластере).

В данной статье пойдёт речь об автоматической миграцией JMS-ресурсов в конфигурации из двух физических серверов (с точки зрения операционной системы).

Последовательность шагов:

1. Создадим два Managed-сервера, например jms_server1 и jms_server2:
   
   
2. Создадим кластер, например JMS_Cluster и добавим ранее созданные Managed-сервера:
   
   
3. Создадим две Machine и соотнесём их с каждым Managed-сервером:
   
   
4. Создадим Data Source для целей миграции, например MigrationDS:
   
   
5. Создадим JDBC Persistence Store, например JDBCStore1:
   
   
6. Создадим JMS-сервер, например JMSServer1:
   
   
7. Создадим JMS-модуль, например JMSModule1:
   
   
8. Создадим в JMSModule1 новый Subdeployment, например JMSServer1Sub, и назначим его на JMSServer1:
   
   
9. В JMSModule1 создадим Connection Factory и очередь, например JMSConnectionFactory и TestQueue соответственно, и соотвесём их с SubDeployment - JMSServer1Sub:
   
   
10. Перейти в JMS_Cluster на страницу "Configuration"->"Migration" и выбрать тип механизма контроля миграции, в нашем случае будем использовать Database и выберем созданный (на шаге 4) Data Source - MigrationDS:
    
    
11. Создадим необходимую служебную таблицу для механизма контроля миграции, для этого надо выполнить скрипт лежащий в $MW_HOME/wlserver_10.3/server/db/<СУБД>/leasing.ddl.
12. Затем перейти в "Environment"->"Migratable Targets" выбрать "jms_server1 (migratable)" и изменить Service Migration Policy, например:
    
    
13. Аналогично для "jms_server2 (migratable)":
    
    
14. Перезапустить AdminServer, а после этого запустить jms_server1 и jms_server2:
    
    
15. Тестируем миграцию JMS-сервера. Например с помощью данного консольного клиента.

Установка WebLogic 10.3 Cluster

Описание: устанавливаем WebLogic Cluster на три Linux-машины(wlsvm1,wlsvm2,wlsvm3) и на отдельную Linux-машину плагин к Apache HTTP Server.

1. Установить Oracle WebLogic 10.3.4
2. Создаём простой домен (только AdminServer)
2.1. Запускаем config.sh (из $MIDDLEWARE_HOME/wlserver_10.3/common/bin):

2.2. Оставляем по-умолчанию:

2.3. Вводим название домена:

2.4. Вводим пароль пользователя weblogic:

2.5. Оставляем по-умолчанию:

2.6. Выбираем RDBMS Security Store:

2.7. Заполняем поля связанные с соответствующей схемой в СУБД (скрипты создания объектов схем можно найти в $MIDDLEWARE_HOME/wlserver_10.3/server/lib, имя файлов начинается на rdbms_security_store_*.sql):

2.8. Создать домен:

3. Конфигурирование домена под кластер:
3.1. Сконфигурировать и запустить NodeManager (подробне здесь).
3.2. Запустить AdminServer c использованием WLST (подробнее здесь).
3.3. Зайти в административную консоль Oracle WebLogic Server - http://хост:порт/console, например http://wlsvm1:7001/console
3.4. Выбрать Environment->Machines и создать новую машину:

3.5. Выбрать имя и тип машины:

3.6. Заполнить значения Listen Adress и Lister Port (адрес и порт на котором запущен NodeManager):

3.7. Аналогично с двумя другими машинами. Получается так:

3.8. Создаём новый ManagedServer, для этого выбрать Environment->Servers:

3.9. Заполняем имя сервера, хост, порт и нажимаем "Finish":

3.10. Аналогично делаем ещё два ManagedServer и получаем следующее:

3.11. Выбираем первый ManagedServer и изменяем поле Machine на соответствующую машину:

3.12. Аналогично для второго и третьего ManagedServer-ов:

3.13. Создаём новый кластер, для этого выбрать Environment->Clusters и нажать "Add". Ввести имя кластера и нажать "Ok":

3.14. Выбираем созданный кластер и переходим в закладку Configuration->Servers и нажимаем "Add":

3.15. Выбираем первый ManagedServer, который добавляем в кластер:

3.16. Аналогично добавляем в кластер для второго и третьего ManagedServer-о.
4. Настройка Apache HTTP Server Plug-In.
4.1. Скопировать модуль плагина mod_wl_22.so из $MIDDLEWARE_HOME/wlserver_10.3/server/plugin/linux/i686/ в директорию с модулями Apache HTTP Server (отдельная машина).
4.2. Изменить конфигурационный файл Apache HTTP Server (у меня он лежит здесь: /etc/httpd/conf/httpd.conf):
4.2.1. Добавить секцию:

 LoadModule weblogic_module   modules/mod_wl_22.so  

4.2.2. Добавить в конец файла:

 <IfModule mod_wl_22.c>  
 WebLogicCluster wlsvm1:7002,wlsvm2:7002,wlsvm3:7003  
 </IfModule>  
 <Location />  
 SetHandler weblogic-handler  
 WebLogicCluster wlsvm1:7002,wlsvm2:7002,wlsvm3:7003  
 </Location>  

4.3. Перезапустить Apache HTTP Server.
5. Запускаем все ManagedServer-а (Environment->Servers->Control):

6. Готово.