IT-шные заметки

четверг, 19 апреля 2012 г.

Автоматизированное тестирование композитов в Oracle SOA Suite 11g

Рассмотрим автоматизированное тестирование (Unit- или модульное тестирование, подробнее здесь) на примере простейшего композита с BPEL-процессом, который вызывает другой HelloWorld-композит (руководство по созданию здесь).

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

Создадим композит (например TestingProject) с BPEL-процессом (например TestBPELProcess), который на входе принимает строку, вызывает HelloWorld-композит и возвращает ответ от вызываемого композита:
Создадим новый набор тестов (TestSuite):
Создадим первый тест (например Test1):
Откроется дизайнер теста:
Проинициализируем входную переменную:
Сгенерируем входную переменную нажав "Generate":
Теперь проинициализируем выходную переменную:
Добавить новое утверждение (Assert), выбрать тип "Assert Output", сгенерировать выходную переменную и изменить её значение:
Получился простейший тест - вводим входную и выходную переменную, если значения совпадут, то тест пройден успешно, если нет, то тест не пройден.
Теперь сделаем простейший тест с использованием эмуляции вызова сервиса (т.е. вместо реального вызова сервиса будет возвращаться определённое значение). Для этого создадим новый тест (например Test2):
Повторить шаги 5-8 для второго теста. Получится следующее:
Далее создадим эмуляцию для сервиса HelloWorldProcess. Для этого:
Перейти в закладку "Emulates" и создать эмуляцию:
Сгенерируем ответ сервиса:
Второй тест получился таким:
Развернём композит на сервере Oracle SOA Suite 11g.
Зайти в Oracle Enterprise Manager Fusion Middleware Control, выбрать наш композит и перейти в закладку "Unit Tests":
Выбрать тесты для запуска и нажать "Execute":
Ввести имя запуска теста:
После окончания выполнения тестов можно увидеть результат выполнения каждого теста:
А так же увидеть детали сравнения на основе которых определяются результаты теста:

среда, 18 апреля 2012 г.

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

Описание: Описана настройка автоматической миграции серверов в конфигуции с двумя физическими машинами.
ПО: 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:
Перезапустить сервера и протестировать миграцию.

среда, 11 апреля 2012 г.

Ошибка "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

четверг, 5 апреля 2012 г.

Поиск Java-класса в директории

Для поиска java-класса по всем jar в директории и поддиректориях можно воспользоваться утилитой JarScan (автор Geoff Yaworski). Загрузить её можно с сайта автора или отсюда.

Пример использования:

 $ java -jar jarscan.jar -dir /opt -class weblogic.jdbc.sqlserver.SQLServerDriver

где /opt - директория для поиска;
weblogic.jdbc.sqlserver.SQLServerDriver - имя класса.

среда, 4 апреля 2012 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

воскресенье, 1 апреля 2012 г.

Кластеризация 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-приложения.
Первоначальная конфигурация:

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

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

Необходимо разрешить пользователю операционной системы под которым развернут 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:$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
```
Зайти в bam_server1 и ввести Server Listen Address - 192.168.2.139.
Клонируем 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.130;
- 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:
- JOC-Shutdown;
- JOC-Startup
Создать новый Data Source для механизма контроля миграции (если потребуется, то создать отдельного пользователя в СУБД. Не использовать административных пользователей, таких как SYS и SYSTEM) и соотнесём его с кластером BAM_Cluster.
Создадим необходимую служебную таблицу для механизма контроля миграции, для этого надо выполнить скрипт лежащий в $MW_HOME/wlserver_10.3/server/db/<СУБД>/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.139;
- 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".
Перезапустить сервера и протестировать миграцию.

четверг, 29 марта 2012 г.

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

Описание: 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/db/<СУБД>/leasing.ddl.
Затем перейти в "Environment"->"Migratable Targets" выбрать "jms_server1 (migratable)" и изменить Service Migration Policy, например:
Аналогично для "jms_server2 (migratable)":
Перезапустить AdminServer, а после этого запустить jms_server1 и jms_server2:
Тестируем миграцию JMS-сервера. Например с помощью данного консольного клиента.

среда, 28 марта 2012 г.

Простой консольный JMS-клиент для Weblogic Server

Возникла необходимость тестирования миграции JMS-очередей (queue-типа), для этого сделана утилита для:

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

Скомпилированный jar-файл здесь, а исходный код здесь.

Как настроить соединение с сервером:
В jar-файле есть текстовый файл connection.properties - параметры соединения хранятся в нём.
Пример содержимого данного файла:

 url=t3://192.168.2.130:7501,192.168.2.96:7502  
 user=weblogic  
 password=welcome1  
 queue=jms/Queue  
 connectionFactory=jms/JMSConnectionFactory  
 textMessage=<elem><val1>#DATE_LONG#</val1><val2>#RND#</val2><val3>#DATE#</val3></elem>

где textMessage - шаблон сообщения для отправки. Можно использовать следующие подстановочные значения:

#DATE_LONG# - текущая дата в формате количества милисекунд с 1 января 1970 года;
#DATE# - текущая дата в формате "ЧАСЫ:МИНУТЫ:СЕКУНДЫ.МИЛИСЕКУНДЫ ДЕНЬ-МЕСЯЦ-ГОД";
#RND# - произвольное целое число в диапазоне от 0 до 10000.

Как запустить:

Отправка сообщений в очередь, например:
```
 java -classpath C:\Apps\SimpleClientForJMS.jar;C:\Apps\Oracle\Weblogic\10.3.5\wlserver_10.3\server\lib\weblogic.jar com.blogspot.stan1slav.jms.testing.SimpleJMSClient send 12  
```
где C:\Apps\Oracle\Weblogic\10.3.5\wlserver_10.3\server\lib\weblogic.jar - путь к weblogic.jar;
12 - какое кол-во сообщений отправить в очередь.

Забрать сообщения из очереди, например:

 java -classpath C:\Apps\SimpleClientForJMS.jar;C:\Apps\Oracle\Weblogic\10.3.5\wlserver_10.3\server\lib\weblogic.jar com.blogspot.stan1slav.jms.testing.SimpleJMSClient receive 10

где 10 - сколько секунд ожидать получение новых сообщенийю

вторник, 27 марта 2012 г.

Ошибка "BEA-149265 java.lang.IllegalArgumentException: Cannot convert value of type" и вариант её решения

Ошибка:
После создания домена с SOA Suite (может быть и в других случаях) не стартует SOA-INFRA, а в логе серверы фигурирует ошибка:

 ...  
 WARNING: unable to read logging configuration from file '/u01/WLS/user_projects/domains/jms_domain/config/fmwconfig/servers/soa_server1/logging.xml'; exception: oracle.core.ojdl.logging.LoggingConfigurationException: ODL-52049: cannot create instance of class 'oracle.dfw.incident.IncidentDetectionLogFilter': java.lang.ExceptionInInitializerError  
 oracle.core.ojdl.logging.LoggingConfigurationException: ODL-52049: cannot create instance of class 'oracle.dfw.incident.IncidentDetectionLogFilter': java.lang.ExceptionInInitializerError  
      at oracle.core.ojdl.logging.impl.LoggingConfigurationImpl.getInstance(LoggingConfigurationImpl.java:651)  
      at oracle.core.ojdl.logging.impl.LoggingConfigurationImpl.access$000(LoggingConfigurationImpl.java:104)  
 ...  
 <Mar 26, 2012 3:46:31 PM MSD> <Critical> <WebLogicServer> <BEA-000286> <Failed to invoke startup class "DMS-Startup", java.lang.NoClassDefFoundError: oracle/dfw/impl/common/TempFileManager  
 java.lang.NoClassDefFoundError: oracle/dfw/impl/common/TempFileManager  
      at oracle.dfw.spi.portable.PortableDiagnosticsFrameworkProvider.init(PortableDiagnosticsFrameworkProvider.java:120)  
 ...  
 WARNING: Error during preRegister for MBean oracle.dfw:name=Streamer,type=oracle.dfw.jmx.Streaming  
 java.lang.RuntimeException: java.lang.NoClassDefFoundError: oracle/dfw/impl/common/TempFileManager  
      at oracle.as.jmx.framework.generic.spi.interceptors.LoggingMBeanInterceptor.internalPreRegister(LoggingMBeanInterceptor.java:663)  
 ...  
 Mar 26, 2012 3:46:33 PM oracle.as.jmx.framework.LoggerHelper log  
 WARNING: Error initializing MBean "oracle.dfw:name=Streamer,type=oracle.dfw.jmx.Streaming", declared in file "/u01/WLS/user_projects/domains/jms_domain/config/fmwconfig/servers/soa_server1/mbeans/dfw_mbeans.xml".  
 javax.management.RuntimeMBeanException: RuntimeException thrown in preRegister method  
      at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.preRegisterInvoke(DefaultMBeanServerInterceptor.java:1012)  
 ...  
 Mar 26, 2012 3:46:33 PM oracle.as.jmx.framework.LoggerHelper log  
 WARNING: Error during preRegister for MBean oracle.dfw:name=DiagnosticsConfig,type=oracle.dfw.jmx.DiagnosticsConfigMBean  
 java.lang.RuntimeException: java.lang.NoClassDefFoundError: oracle/dfw/impl/common/TempFileManager  
      at oracle.as.jmx.framework.generic.spi.interceptors.LoggingMBeanInterceptor.internalPreRegister(LoggingMBeanInterceptor.java:663)  
 ...  
 ...  
 WARNING: Error during postRegister for MBean oracle.adf.share.config:ApplicationName=soa-infra,name=ADFConfig,type=ADFConfig,Application=soa-infra  
 java.lang.RuntimeException: java.lang.NoClassDefFoundError: oracle/dfw/impl/common/TempFileManager  
      at oracle.as.jmx.framework.generic.spi.interceptors.LoggingMBeanInterceptor.internalPostRegister(LoggingMBeanInterceptor.java:703)  
 ...  
 SEVERE: Failed to register config mbean for soa-infra.  
 SEVERE:   
 javax.management.RuntimeMBeanException: RuntimeException thrown in postRegister method  
      at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1037)  
 ...  
 Caused by: java.lang.NoClassDefFoundError: oracle/dfw/impl/common/TempFileManager  
      at oracle.dfw.spi.portable.PortableDiagnosticsFrameworkProvider.init(PortableDiagnosticsFrameworkProvider.java:120)  
 ...

Причина:
Во временных директориях закончилось свободное место или нет привилегий.

Вариант решения:

Остановить все Managed-серверы и Admin-сервер.

Очистить временные директории и дать права записи:

  $ cd /var/tmp/  
  $ rm -rf ora*  
  $ chmod 777 /var/tmp/  
  $ cd /tmp  
  $ rm -rf *  
  $ chmod 777 /tmp

Запустить все Managed-серверы и Admin-сервер.

понедельник, 26 марта 2012 г.

Настройка NFS на Linux

Залогиниться на сервер NFS (в нашем случае 192.168.2.95).
Добавляем в файл /etc/exports на сервере:
```
 /u02/data         192.168.2.96(rw,no_root_squash)  
```
где 192.168.2.96 - ip-адрес или доменное имя клиента;
/u02/data - директория на сервере.

Перезапустить сервер NFS:

 $ /etc/init.d/nfs restart  
 ..................................................................  
 Starting NFS services:                     [ OK ]  
 Starting NFS quotas:                       [ OK ]  
 Starting NFS daemon:                       [ OK ]  
 Starting NFS mountd:                       [ OK ]

Залогиниться на клиент NFS (в нашем случае 192.168.2.96).
Необходимо подмонтировать данный ресурс в директорию:
```
 $ mount 192.168.2.95:/u02/data /share  
```
где 192.168.2.95 - адрес сервера;
/u02/data - расшаренная директория на сервере;
/share - директория на клиенте.
Если нужно чтобы сетевая папка монтировалась автоматически при старте системы, тогда добавляем в файл /etc/fstab:
```
 192.168.2.95:/u02/data /share nfs timeo=50,hard,intr  
```
В случае невозможности подмонтирования сетевого ресурса необходимо разрешить доступ к портам (111, 2049) настройкой firewall (лучше) или выполнить следующую команду (хуже) на сервере:
```
 $ service iptables stop  
```
Или отключить полность:
```
 $ chkconfig iptables off 
```

четверг, 15 марта 2012 г.

Клонирование Oracle Fusion Middleware 11g

Клонирование Oracle Fusion Middleware 11g (SOA Suite, ODI, IDM, Webcenter и т.д.) условно можно разделить на две логические части:

Клонирование Middleware Home;
Клонирование доменов.

Существует несколько ограничений по клонированию:

окружения должны быть идентичными, т.к. сервер назначения и сервер источник должны иметь одну и ту же операционную систему и разрядность (32 или 64);
система назначения и система источник должны иметь одного и того же административного пользователя (например, weblogic), но пароли могут быть различны. После завершения клонирования можно изменить пользователя.

Клонирование СУБД и других внешних систем, которые используются в приложениях/композитах выходят за рамки данной статьи.

Клонирование Middleware Home

Типовая структура Middleware Home (MW_HOME):

Останавливаем все сервера (AdminServer и ManagedServer-а) всех доменов (на источнике), которые используют клонируемый Middleware Home;
На источнике перейти в директорию:
```
 $ cd $MW_HOME/oracle_common/bin/  
```
Затем выполнить команду:
```
 $ ./copyBinary.sh -javaHome /opt/jrockit-jdk1.6.0_26-R28.1.4-4.0.1/ 
-archiveLoc /tmp/mw_copy.jar -sourceMWHomeLoc /opt/Middleware/
```
где javaHome – директория c JDK;
archiveLoc – имя файла для экспорта;
sourceMWHomeLoc – директория в которой развернут MW_HOME.

Скопировать файл экспорта с сервера источника на сервер назначения. А так же следующие файлы:
```
 $ ls $MW_HOME/oracle_common/bin/pasteBinary.sh  
 $ ls $MW_HOME/oracle_common/jlib/cloningclient.jar  
```

Запускаем импорт Middleware Home на сервере назначения:
```
 $ ./pasteBinary.sh -javaHome /u01/jdk1.6.0_30/ 
-archiveLoc mw_copy.jar -targetMWHomeLoc /u01/ofm  
```
где javaHome – директория c JDK;
archiveLoc – имя файла для импорта;
targetMWHomeLoc – директория в которой будет развернут MW_HOME.

Клонирование доменов

Проверяем, что все сервера домена (на источнике) для клонирования стартованы.
Если в домене есть machine типа Unix Machine, то необходимо изменить её на тип Machine. Для этого необходимо:
```
 $ cp $DOMAIN_HOME/config/config.xml $DOMAIN_HOME/config/config.xml.bkp  
 $ vi $DOMAIN_HOME/config/config.xml  
```
Далее найти следующую строку (или строки если несколько машин):
```
 <machine xsi:type="unix-machineType">  
```
И заменить её (или их) на:
```
 <machine>  
```
После этого перезапустить AdminServer.
На сервере источнике перейти в директорию:
```
 $ cd $MW_HOME/oracle_common/bin/  
```
Затем выполнить на источнике команду:
```
 $ ./copyConfig.sh -javaHome /opt/jrockit-jdk1.6.0_26-R28.1.4-4.0.1/  
                -archiveLoc /tmp/soa_domain.jar 
                -sourceDomainLoc /opt/user_projects/domains/soa_domain/     
                -sourceMWHomeLoc /opt/Middleware/                         
                -domainHostName oracle-sb.tsretail.ru    
                -domainPortNum 9000 
                -domainAdminUserName weblogic 
                -domainAdminPassword /tmp/wlspwd.txt  
```
где javaHome – директория c JDK;
      archiveLoc – имя файла для экспорта;
      sourceDomainLoc – директория домена;
      sourceMWHomeLoc – директория в которой развернут MW_HOME;
      domainHostName – хост домена;
      domainPortNum – порт AdminServer-а;
      domainAdminUserName – логин администратора;
      domainAdminPassword – путь к текстовому файлу с паролем администратора.
Скопировать файл экспорта с сервера источника на сервер назначения.
На сервере назначения перейти в директорию:
```
 $ cd $MW_HOME/oracle_common/bin/  
```
Запускаем генерацию плана переноса домена на сервере назначения:
```
 $ ./extractMovePlan.sh -javaHome /u01/jdk1.6.0_30  
               -archiveLoc /home/weblogic/clone_domain/soa_domain.jar
               -planDirLoc /home/weblogic/clone_domain/plan  
```
где javaHome – директория c JDK;
archiveLoc – имя файла для экспорта;
planDirLoc – директория в которую будет сгенерирован план.
Редактируем сгенерированный план переноса:
```
 $ vi /home/weblogic/clone_domain/plan/moveplan.xml  
```
Следует обратить внимание на создание текстовых файлов содержащих пароли к Data Source-ам и указание пути к файлу с паролем для каждого конкретного Data Source-а.

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

 $ /home/weblogic/clone_domain/plan/  
 $ ls -l  
 total 312  
 drwxr-xr-x 2 weblogic app  4096 Mar 14 10:47 adapters  
 drwxr-xr-x 2 weblogic app 12288 Mar 14 10:47 composites  
 drwxr-xr-x 2 weblogic app  4096 Mar 14 10:48 deployment_plans  
 -rw-r--r-- 1 weblogic app 274543 Mar 14 10:44 moveplan.xml

Запускаем импорт домена на сервере назначения:
```
 $ ./pasteConfig.sh -javaHome /u01/jdk1.6.0_30   
      -archiveLoc /home/weblogic/clone_domain/soa_domain.jar   
      -movePlanLoc /home/weblogic/clone_domain/plan/moveplan.xml  
      -targetDomainLoc /u01/user_projects/domains/clonned_soa_domain  
      -targetMWHomeLoc /u01/ofm/   
      -domainAdminPassword /home/weblogic/clone_domain/plan/domainpwd.txt  
```
где javaHome – директория c JDK;
      archiveLoc – имя файла для экспорта;
      sourceDomainLoc – директория домена;
      movePlanLoc – имя файла плана переноса;
      targetDomainLoc – директория в которую импортируется домен;
      targetMWHomeLoc – директория в которой развернут MW_HOME;
      domainAdminPassword – путь к текстовому файлу с паролем администратора.

понедельник, 20 февраля 2012 г.

Основы Oracle Fusion Middleware High Availability

Обеспечение высокой доступности это одна из ключевых требований в любом промышленном внедрении. Внедрение систем высокой доступности обеспечивает минимизацию времени простоя системы и максимизацию времени доступности.
Простой системы бывает двух видов:

Планируемый – запланированные административные операции;
Непланируемый – любой незапланированный сбой.

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

Табл.1 Планируемые простои и их решения для семейства продуктов Oracle Fusion Middleware

Операции	Решения
Развертывание и удаление приложений	Hot Deployment
Патчинг	Rolling Patching
Конфигурационные изменения	Online configuration Changes Change Notification Batching of changes Deferred Activation
Масштабируемость	Cluster Scale-Out

Табл.2 Непланируемые простои и их решения для семейства продуктов Oracle Fusion Middleware

Тип сбоя	Решения
Программный сбой	Death Detection and restart using Node Manager for Java EE and OPMN for system components. Server Clusters & Load Balancing Cold Failover Clusters Server Migration Service Migration State Replication and Replica aware Stubs
Аппаратный сбой	Server Clusters & Load Balancing Server Migration Clusterware Integration
Потеря данных	Backup and Recovery
Site Disaster	Oracle Fusion Middleware Disaster Recovery Solution

Решения высокой доступности можно разделить на два вида:

Локальная высокая доступность – предоставляется в одном датацентре;
Глобальная высокая доступность – предоставляется в географически различных датацентрах (защищает от региональных бедствий, например наводнений).

Решения локальной высокой доступности можно разделить на два вида:

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

Концептуальная схема решения глобальной высокой доступности:

четверг, 26 января 2012 г.

Ошибка "java.lang.AssertionError: Could not obtain the localhost address" при старте Weblogic-сервера и вариант её решения

Ошибка:
При старте Weblogic-сервера возникает следующая ошибка и происходит ошибка старта (сервер переходит в статус FAILED):

 <BEA-000386> <Server subsystem failed. Reason: java.lang.AssertionError: Could not obtain the localhost address. The most likely cause is an error in the network configuration of this machine.  
 java.lang.AssertionError: Could not obtain the localhost address. The most likely cause is an error in the network configuration of this machine.  
     at weblogic.server.channels.AddressUtils$AddressMaker.getLocalHost(AddressUtils.java:38)  
     at weblogic.server.channels.AddressUtils$AddressMaker.<clinit>(AddressUtils.java:33)  
     at weblogic.server.channels.AddressUtils.getIPAny(AddressUtils.java:154)  
     at weblogic.protocol.configuration.ChannelHelper.checkConsistency(ChannelHelper.java:61)  
     at weblogic.server.channels.ChannelService.start(ChannelService.java:207)  
     at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)  
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)  
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)  
 Caused By: java.net.UnknownHostException: vm1.mydomain.com : vm1.mydomain.com 
     at java.net.InetAddress.getLocalHost(InetAddress.java:1360)  
     at weblogic.server.channels.AddressUtils$AddressMaker.getLocalHost(AddressUtils.java:36)  
     at weblogic.server.channels.AddressUtils$AddressMaker.<clinit>(AddressUtils.java:33)  
     at weblogic.server.channels.AddressUtils.getIPAny(AddressUtils.java:154)  
     at weblogic.protocol.configuration.ChannelHelper.checkConsistency(ChannelHelper.java:61)  
     at weblogic.server.channels.ChannelService.start(ChannelService.java:207)  
     at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)  
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)  
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

Причина:
По имени хоста (выделено синим выше) на котором напускается Weblogic-сервер невозможно получить его IP-адрес.

Решение:
Варианты решения:

Прописать в DNS
Прописать в файл /etc/hosts

четверг, 19 апреля 2012 г.

среда, 18 апреля 2012 г.

среда, 11 апреля 2012 г.

четверг, 5 апреля 2012 г.

среда, 4 апреля 2012 г.

воскресенье, 1 апреля 2012 г.

четверг, 29 марта 2012 г.

среда, 28 марта 2012 г.

вторник, 27 марта 2012 г.

понедельник, 26 марта 2012 г.

четверг, 15 марта 2012 г.