Какой рейтинг вас больше интересует?
|
Главная / Главные темы / Тэг «weblogic»
Конфигурирование автоматической миграции сервера 2012-04-19 01:00:00
... > Соотнесём Weblogic-сервера и Weblogic-машины следующий ...
+ развернуть текст сохранённая копия
Описание: Описана настройка автоматической миграции серверов в конфигуции с двумя физическими машинами. ПО: RHEL 5.5, Weblogic 10.3.5. Есть простой Weblogic-домен следующей конфигурации: Weblogic сервера: - AdminServer - порт 7001;
- mserver1 - порт 7100.
Есть две физические машины (с точки зрения ОС) с IP-адресами, например: - 192.168.2.130
- 192.168.2.96
Последовательность шагов:- Необходимо разрешить пользователю операционной системы под которым развернут Oracle FMW (в нашем случае - это 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. ......
- Для обеспечения работоспособности необходим дополнительный "плавающий"/виртуальный 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
- Добавить в переменную 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
- Зайти в mserver1 и ввести Server Listen Address - 192.168.2.139:
- Клонируем mserver1 (переходим в "Environment"->"Servers", выбираем mserver1 и нажимаем на кнопку "Clone"). Новый сервер:
- Server Name - mserver2;
- Server Listen Address - 192.168.2.96;
- Server Listen Port - 7200.
- Создаем кластер:
- Name - WLS_Cluster;
- Messaging Mode - Unicast.
- Добавляем в данный кластер оба сервера - mserver1 и mserver2:
- На каждой физической машине (с т.з. операционной системы) сконфигурируем по Node Manager-у (подробнее здесь) и создадим две Weblogic-машины (Machines):
- Machine1 - 192.168.2.130;
- Machine2 - 192.168.2.96.
- Соотнесём Weblogic-сервера и Weblogic-машины следующий образом:
- mserver1 - Machine1;
- mserver2 - Machine2.
- Создать новый Data Source для механизма контроля миграции (если потребуется, то создать отдельного пользователя в СУБД. Не использовать административных пользователей, таких как SYS и SYSTEM) и соотнесём его с кластером WLS_Cluster:
- Создадим необходимую служебную таблицу для механизма контроля миграции, для этого надо выполнить скрипт лежащий в $MW_HOME/wlserver_10.3/server/db/<СУБД>/leasing.ddl.
- Если используется технология JMS, то перейти в "Services"->"Persistence Stores" и проверить какие типы Persistence Store-ов используются:
- Если FileStore, то обеспечить доступ к директориям со второго сервера, как правило для этого используется раздел дискового массива или кластерной файловой системы.
- Если JDBCStore, то соотнести используемый Data Source с кластером WLS_Cluster.
- Необходимо донастроить Node Manager-ы на каждой физической машине, добавить опции для сетевых интерфейсов в файл nodemanager.properties:
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
где eth0 - имя сетевого интерфейса на котором будет поднят "плавающий"/виртульный IP-адрес. - Затем в Weblogic Console выбрать кластер WLS_Cluster и перейти в "Configuration"->"Migration" и заполнить поле "Data Source For Automatic Migration:", где выбрать созданный Data Source для механизма контроля миграции (см. пункт 11):
- Далее перейти в "Environment"->"Servers" выбрать mserver1. Перейти в "Configuration"->"Migration" и поставить галку "Automatic Server Migration Enabled". Аналогично для mserver1:
- Перезапустить сервера и протестировать миграцию.
Тэги: migrate, weblogic
Ошибка "BEA-149259 Server ... in cluster ... is being brought up in administration state due to failed deployments" и вариант её решения 2012-04-11 10:47:00
... : В Weblogic-кластере сервер (в ... состояния ADMIN в Weblogic-сервере: ошибки возникающие ...
+ развернуть текст сохранённая копия
Ошибка:В 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
Тэги: cluster, error, weblogic
Weblogic Cluster: принцип работы Сonsensus leasing 2012-04-04 08:57:00
В Weblogic Cluster есть два ...
+ развернуть текст сохранённая копия
В Weblogic Cluster есть два механизма контроля миграции: - Database - информация хранится/изменяется в СУБД;
- Сonsensus - информация хранится в памяти.
В данной статье пойдёт речь об принципах работы механизма Сonsensus. Принцип работы:Допущение: для простоты восприятия принципа работы будем считать, что данные хранятся в виртуальной таблице в памяти мастера (никакого отношения к таблицам СУБД не имеет). Все сервера кластера периодически отправляют информацию о статусе, так называемые лизы (от слова leasing) мастеру кластера, которую он кладёт в "виртуальную" таблицу в памяти, а от него в ответ получают текущую копию виртуальной таблицы - делается это для обеспечения отказоустойчивость при выходе из строя мастера. Мастер выбирается всеми запущенными серверами кластера. Сервер становится мастером после одобрения большинства. Если Node Manager сообщает, что статус сервера: - остановлен (SHUTDOWN), то потенциальный мастер считает, что остановленный сервер одобрил его кандидатуру, как мастера;
- неизвестен (UNKNOWN), то потенциальный мастер считает, что сервер не одобрил его кандидатуру;
- запускается (STARTING), то состоится перевыбор мастера (так же это случится при выходе из строя самого мастера), где основной критерий выбора - наименьшее время старта сервера.
Механизм Сonsensus требует большинства серверов для продолжения функционирования: при выходе из строя (или невозможности доступа к мастеру) сервера кластер логически делится на две части - большая часть кластера продолжает, а меньшая завершает функционировать (переходит в статус FAILED). В двухмашинной конфигурации использование Сonsensus Leasing проблематично и рекомендуется использование Database Leasing. Пример: При старте первого сервера он ищет остальных участников кластера, чтобы узнать есть ли мастер: Если нет мастера, то он становится мастером: При старте второго сервера из кластера он ищет участников кластера, находит первый сервер, являющийся мастером: Далее оба сервера пересматривают вопрос по мастеру кластера: если время старта второго меньше, чем первого (который на данный момент является мастером), то мастером становится второй сервер: Аналогично с третьим и последующим серверами.
Тэги: consensus, lease, migrate, weblogic
Кластеризация Oracle BAM 11g 2012-04-01 09:13:00
... конфигурации: Weblogic сервера: < ... li>Соотнесём Weblogic-сервера и Weblogic-машины ...
+ развернуть текст сохранённая копия
Описание: Описана кластеризация 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-приложения. Первоначальная конфигурация: В случае выхода из строя первого физического сервера: Последовательность шагов:- Необходимо разрешить пользователю операционной системы под которым развернут 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. ......
- Для обеспечения работоспособности необходим дополнительный "плавающий"/виртуальный 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
- Добавить в переменную PATH следующее (лучше на уровне профиля пользователя, если используется bash, то это файл ~/.bash_profile):
PATH=$PATH:$FW_HOME/wlserver_10.3/common/nodemanager:$FW_HOME/user_projects/domains/bam_domain/bin/server_migration:$FW_HOME/wlserver_10.3/common/bin export PATH
- Клонируем bam_server1 (переходим в "Environment"->"Servers", выбираем bam_server1 и нажимаем на кнопку "Clone"). Новый сервер:
- Server Name - bam_server2;
- Server Listen Address - 192.168.2.96;
- Server Listen Port - 9002.
- Создаем кластер:
- Name - BAM_Cluster;
- Messaging Mode - Unicast.
- Добавляем в данный кластер оба сервера - bam_server1 и bam_server2.
- На каждой физической машине (с т.з. операционной системы) сконфигурируем по Node Manager-у (подробнее здесь) и создадим две Weblogic-машины (Machines):
- Machine1 - 192.168.2.139;
- Machine2 - 192.168.2.96.
- Соотнесём Weblogic-сервера и Weblogic-машины следующий образом:
- bam_server1 - Machine1;
- bam_server2 - Machine2.
- Теперь соотнесём приложения и библиотеки с созданным нами кластером (BAM_Cluster), а не только с bam_server1:
- DMS Application (11.1.1.1.0)
- oracle-bam (11.1.1)
- usermessagingdriver-email
- usermessagingserver
- wsil-wls
- wsm-pm
- Соотнести приложение "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 | - Так же соотнести следующие Data Source-ы с кластером BAM_Cluster:
- BAMDataSource;
- mds-owsm;
- OraSDPMDataSource.
- Соотнести следующие Startup and Shutdown Classes с BAM_Cluster:
- Создать новый Data Source для механизма контроля миграции (если потребуется, то создать отдельного пользователя в СУБД. Не использовать административных пользователей, таких как SYS и SYSTEM) и соотнесём его с кластером BAM_Cluster.
- Создадим необходимую служебную таблицу для механизма контроля миграции, для этого надо выполнить скрипт лежащий в $MW_HOME/wlserver_10.3/server/sb/<СУБД>/leasing.ddl.
- Перейти в "Services"->"Persistence Stores" и проверить какие типы Persistence Store-ов используются:
- Если FileStore, то обеспечить доступ к директориям со второго сервера, как правило для этого используется раздел дискового массива или кластерной файловой системы.
- Если JDBCStore, то соотнести используемый Data Source с кластером BAM_Cluster.
- Запустить bam_server1 и bam_server2.
- Зайти в 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.130;
- ServerPort - порт на котором запущен BAM-сервер, в нашем случае это 9001;
- Перезапустить AdminServer.
- Необходимо донастроить Node Manager-ы на каждой физической машине, добавить опции для сетевых интерфейсов в файл nodemanager.properties:
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
где eth0 - имя сетевого интерфейса на котором будет поднят "плавающий"/виртульный IP-адрес. - Затем в Weblogic Console выбрать кластер BAM_Cluster и перейти в "Configuration"->"Migration" и заполнить поле "Data Source For Automatic Migration:", где выбрать созданный Data Source для механизма контроля миграции (см. пункт 13).
- Далее перейти в "Environment"->"Servers" выбрать bam_server1. Перейти в "Configuration"->"Migration" и поставить галку "Automatic Server Migration Enabled".
- Перезапустить сервера и протестировать миграцию.
Тэги: bam, soa, suite, weblogic
Конфигурирование автоматической миграции JMS-серверов 2012-03-29 01:00:00
... >Описание: WebLogic-кластере приложения и ... имплементирован интерфейс weblogic.cluster.singleton. ...
+ развернуть текст сохранённая копия
Описание: WebLogic-кластере приложения и Data Source-ы могут быть распределены на всех узлах кластера, но есть несколько типов singleton-ресурсов, которые должны быть в единственном экземпляре в кластере: - JMS-сервера и их destinations;
- JMS SAF-агенты;
- Persistance store;
- Менеджер транзакций и его логи;
- Созданные пользователем классы (должен быть имплементирован интерфейс weblogic.cluster.singleton.SingletonService).
Для обеспечения высокой доступности данных ресурсов используются два подхода: - Миграция всего Managed-сервера;
- Миграция сервисов (т.е. данных singleton-ресурсов с одного Managed-сервера на другой в Weblogic-кластере).
В данной статье пойдёт речь об автоматической миграцией JMS-ресурсов в конфигурации из двух физических серверов (с точки зрения операционной системы). Последовательность шагов:- Создадим два Managed-сервера, например jms_server1 и jms_server2:
- Создадим кластер, например JMS_Cluster и добавим ранее созданные Managed-сервера:
- Создадим две Machine и соотнесём их с каждым Managed-сервером:
- Создадим Data Source для целей миграции, например MigrationDS:
- Создадим JDBC Persistence Store, например JDBCStore1:
- Создадим JMS-сервер, например JMSServer1:
- Создадим JMS-модель, например JMSModule1:
- Создадим в JMSModule1 новый Subdeployment, например JMSServer1Sub, и назначим его на JMSServer1:
- В JMSModule1 создадим Connection Factory и очередь, например JMSConnectionFactory и TestQueue соответственно, и соотвесём их с SubDeployment - JMSServer1Sub:
- Перейти в JMS_Cluster на страницу "Configuration"->"Migration" и выбрать тип механизма контроля миграции, в нашем случае будем использовать Database и выберем созданный (на шаге 4) Data Source - MigrationDS:
- Создадим необходимую служебную таблицу для механизма контроля миграции, для этого надо выполнить скрипт лежащий в $MW_HOME/wlserver_10.3/server/sb/<СУБД>/leasing.ddl.
- Затем перейти в "Environment"->"Migratable Targets" выбрать "jms_server1 (migratable)" и изменить Service Migration Policy, например:
- Аналогично для "jms_server2 (migratable)":
- Перезапустить AdminServer, а после этого запустить jms_server1 и jms_server2:
- Тестируем миграцию JMS-сервера. Например с помощью данного консольного клиента.
Тэги: jms, migrate, weblogic
Главная / Главные темы / Тэг «weblogic»
|
Взлеты Топ 5
Падения Топ 5
|