JMS Service Migration Patterns

WebLogic Server supports two types of Migrations:

                   1. Service Migration

                   2. Server Migration

 WebLogic Server supports service-level migration the following Migratable Services:

- JMS-related Services
- JTA Transaction Recovery Service
- User-defined Singleton Services

SERVICE MIGRATION

Applies to services that run as singletons  in a cluster

·         JMS servers , their hosted destination and related services

·         JTA transaction recovery service for a server

·         User-define singleton services

Enables you to restart these services on another running

Server in the cluster

·         for JMS , rescue standard persistent message

·         for JTA , process incomplete transaction for a failed server

·         for user-defined singleton services, guarantees that the process

·         run exactly once in the cluster (WLS automatically restart it somewhere in the cluster)

 

SERVICE MIGRATION MECHANISMS

Manual/Scriptable Migration

Automatic service migration

·         JTA Transaction Recovery and singleton service migration from WLS10.0

·         Automatic JMS Migration from WLS10.3

·         Needs Leasing technology/options/reqs apply

·         Weblogic cluster tracks Server/service heath

* Failed services automatically migrate to healthy candidates

   In the below diagram when the JMS server2 is down it will migrate all the resources to JMSserver1

 

Requirements:

To setup the JMS service migration we need to select the migration basis

WebLogic Server provides two separate implementations of the leasing functionality.

PATTERN1

à High-availability Database Leasing - This version of leasing requires the availability of a high-availability database to store leasing information.

(The leasing table should be stored in a highly available database. Migratable servers are only as reliable as the database used to store the leasing table. XA data sources are not supported for server migration)

PATTERN2

àNon-database Consensus Leasing - This version of leasing stores the leasing information in-memory within a cluster member.

(This version of leasing requires that you use Node Manager to control servers within the cluster. Node Manager should also be running on every machine hosting managed servers within the cluster.)

I.                  High-availability Database Leasing SETUP:

In this case, the leasing information is stored in a database table (ACTIVE).  Were  are creating a dependency on the database here, for a failover service  So, it makes a lot of sense to use this scenario only if your database implementation itself is High Available (RAC).

Prerequisites:

1.       Database schema for loading the leasing information (highly Available RAC)

2.       JMS servers needs to be targeted to Migratable Targets

3.       JMS servers  must be targeted  to persistent stores 

    Persistent store must be

a)      Located on a shared file system (file based persistent store), in case the servers reside on different machines, or

b)      Located on a database (jdbc bases persistent store) to which all servers have access

Configuration  STEP1:        Create the leasing table

Oracle Ships a script to create the table for different  flavors  of databases. The scripts are called leasing.ddl and are located in $WL_HOME/server/db/<db_vendor>/leasing.ddl

For example for oracle databases the it has the below script :

DROP TABLE ACTIVE;

CREATE TABLE ACTIVE (
  SERVER VARCHAR2(150) NOT NULL,
  INSTANCE VARCHAR2(100) NOT NULL,
  DOMAINNAME VARCHAR2(50) NOT NULL,
  CLUSTERNAME VARCHAR2(50) NOT NULL,
  TIMEOUT DATE,
  PRIMARY KEY (SERVER, DOMAINNAME, CLUSTERNAME)
);

Once you execute the above script it will create  Table ACTIVE. Which holds the leasing information.

Configuration  STEP2:        Create a leasing Datasource

Create a datasource, using the credentials which you used to create the ACTIVE table in step 1
Target the datasource to the cluster. 

JNDINAME :  jmsmigration

DATASOURCENAME : jmsmigration

Configuration  STEP3:        Configure Migration in the cluster

Save and activate your changes and restart the cluster.

Configuration  STEP4:        Create a persistent store datasource

NOTE: This step is not needed if we are using shared file store.

In this POC we will use the  jmsmigration DS for creating persistence store.

( You can create a shared storage which is accessible from all the managed servers for migration)

Configuration  STEP5:        Create persistent stores

We will create two persistence stores  which uses JDBCStore and jmsmigration DataSource.

jmstore1 targeted to M1 ( Migratable)

jmstore2 targeted to M2 ( Migratable)

Go to Services > Persistent Stores

For each mirgratable target to which you are going to target a jms server, create a Persistent Store.
The prefix name is used to prepend the tablename in the database.

 

If We are planning to use FILEBASED store Specify Directory same shared location to both persistence stores

Configuration  STEP6:        Creating the JMS servers and targeting the persistence store

For testing create a jms module and create CF and Distributed Queue

JMSMoudle : migrationmodue

SubDeployment :  musub (Target it to jms-server1 and jmserver2)

ConnectionFactory :  com/oracle/appgrid/example/jms/base/cf

DistrubutedQueue:   com/oracle/appgrid/example/jms/base/queue

Configuration  STEP7:   Enable JMS Service Migration

For each Migratable Target, select the Migratable Target and go to Configuration > Migration

Select Auto-Migrate Failure Recovery Services
Select all candidate servers that can be used.

Note that the User Preferred Server itself must also be in the list of Candidate servers!

Restart all the servers including the Adminserver,  This completes our JMS migration setup failover

Demo: Automatic JMS service Migration DatabaseLeasing

       Client/Server Demo

          ** Client Sends messages faster than they are consumed

          ** Messages are load-balanced between two JMS servers

          ** Show Message backlog on Managed Sever1

          ** Kill Managed server 1 process

          ** Show the JMS Server is migrated to Managed Server2

          ** Show the messages are not lost and consumed on Managed Server2

          ** Restart the Managed Server1

          ** Manually Migrate JMS server 1 back to Managed Server1

II.                 Non-database Consensus Leasing:

In the non-database version of Consensus leasing, WebLogic  Server maintains leasing information in-memory

One member of a cluster is chosen as the cluster leader and is responsible for maintaining the leasing information. The cluster leader is chosen based on the length of time that has passed since startup. The managed server that has been running the longest within a cluster is chosen as the cluster leader. Other cluster members communicate with this server to determine leasing information, however, the leasing table is replicated to other nodes of the cluster to provide failover.

Note:

This version of leasing requires that you use Node Manager to control servers within the cluster. Node Manager should also be running on every machine hosting managed servers within the cluster

Prerequisites:

1.       Node Manager (Consensus) for clustered singleton services migration

2.       JMS servers needs to be targeted to Migratable Targets

3.       JMS servers  must be targeted  to persistent stores 

    Persistent store must be

c)       Located on a shared file system (file based persistent store), in case the servers reside on different machines, or

d)      Located on a database (jdbc bases persistent store) to which all servers have access

Configuration  STEP1:        Configure Migration in the cluster for Consensus

Console Path: Clusters —> Cluster —> Configuration [tab] —> Migration [sub-tab]
Candidate Machines For Migratable Servers: Machine
Migration Basis: Consensus

Configuration  STEP2:       

Configure Node manager on all the host’s , Verify node manager is running on all the hosts.

Repeat Steps Configuration  STEP4,STPE5,STEP6,STEP7  From    High-availability Database Leasing SETUP

NOTE:  For Non-database Consensus Leasing , You need to start the managed servers using Node Manager.

Demo: Automatic JMS service Migration DatabaseLeasing

       Client/Server Demo

          ** Client Sends messages faster than they are consumed

          ** Messages are load-balanced between two JMS servers

          ** Show Message backlog on Managed Sever1

          ** Kill Managed server 1 process

          ** Show the JMS Server is migrated to Managed Server2

          ** Show the messages are not lost and consumed on Managed Server2

          ** Restart the Managed Server1

          ** Manually Migrate JMS server 1 back to Managed Server1