- 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-сервера. Например с помощью данного консольного клиента.