Using Whole Server Migration with Dynamic Clusters

When a WebLogic cluster is small, database leasing provides a better migration experience. WebLogic includes SQL scripts to create the database leasing table for the most common databases. This course uses an Oracle database, and uses the SQL for creating the table in an Oracle database.

1. Execute the following command to create the database leasing table. Replace the oracle user with your user and Welcome1 wtih your password. Replace [WL_HOME] with your actual WebLogic installation folder because environment variables will not work.

   $ sqlplus oracle/Welcome1 @[WL_HOME]/server/db/oracle/920/leasing.ddl
   SQL> quit

   

Now that the database is configured for whole server migration, let's assign virtual IP addresses to the servers in the cluster.

You have already configured Node Manager with a pool of dynamic IP addresses it can use to migrate IP addresses on the machines where servers run. Now, you configure the server template that the dynamic cluster is based on to use IP addresses that are included in that pool.

1. Navigate to Server Templates in the administration console.

   

2. Select your server template.

   

3. Select the Configuration > General tabs and configure the template with the values listed in the table below.

   • You do not specify a machine for the template because WebLogic automatically assigns each server in a dynamic cluster across the machines that are part of the cluster.
   • You configure the listen address so that the last number of the IP address is calculated based on the ID of the server. The first server that starts will be id=1 and the next is id=2.
   • You configure the listen port, which is the starting point for calculated port numbers. The initial setting is 8000, so the first server in the cluster will use port 8001 and subsequent servers will continue to increment the number by one.
   
   

   Name	Value
   Machine	None
   Cluster	[your-dynamic-cluster-name]
   Listen Address	[your-dynamic-IP-address]${id}
   Listen Port Enabled	Yes
   Listen Port	8000

   
   

   

   Now that you have configured your servers to use dynamic IP addresses, let's configure WebLogic JMS-related components that migrate with the servers.

You configure JDBC and JMS components in your domain, which are used to demonstrate migrating JMS on a dynamic cluster.

Configure a JDBC Data Source

1. Navigate to Data Sources in the administration console.

   

2. Click New > Generic Data Source to create a new data source.

   

3. Walk through the JDBC data source configuration wizard and configure a data source with the values listed in the table below.

   Name	Value
   Name	JDBC Data Source-0
   JNDI Name	jdbc.ds0
   Database Type	Oracle
   Database Driver	Oracle's Driver (Thin) for Instance connections; Versions: Any (Do NOT choose an XA Driver)
   Supports Global Transactions	False
   Database Name	[your-data-base-name] Example: orcl
   Host Name	[your-database-host-name] Example: host02
   Port	[your-database-port] Example: 1521
   Database User Name	[your-database-user-name] Example: oracle
   Password	[your-database-user-password] Example: Welcome1

   
   

   

4. Test the database connection and verify that your settings work.

   

5. Target the data source to your dynamic cluster.

   

Configure a JDBC Persistent Store

6. Navigate to Persistent Stores in the administration console.

   

7. Click New > Create JDBC Store to create a new persistent store.

   

8. Configure your persistent store with the values listed in the table below.

   The obe prefix ensures that this store uses a unique table name in the database.

   Name	Value
   Name	JDBCStore-0
   Target	dyncluster1
   Data Source	JDBC Data Source-0
   Prefix Name	obe

   
   

   

Configure a JMS Server

9. Navigate to JMS Servers in the administration console.

   

10. Click New to create a new JMS Server.

    

11. Configure the JMS Server with the settings in the table below.

    Name	Value
    Name	JMSServer-0
    Persistent Store	JDBCStore-0

    
    

    

12. Target the JMS Server to the dynamic cluster.

    

Configure a JMS Module

13. Navigate to JMS Modules in the administration console.

    

14. Click New to create a new JMS Module.

    

15. Configure the JMS Module with the settings in the table below.

    Name	Value
    Name	SystemModule-0
    Descriptor File Name	leave default
    Location in Domain	leave default

    
    

    

16. Target the JMS Module to the dynamic cluster.

    

17. Select the option to add resources to the module and click Finish.

    

Configure a Subdeployment

18. Click the Subdeployment tab.

    

19. Click New to create a new subdeployment in order to target resources to your JMS Server.

    

20. Name your subdeployment DeployTo-JMSServer-0.

    

21. Target your connection factory to JMSServer-0 and click Finish.

    

Configure a JMS Connection Factory

22. Click the Configuration tab.

    

23. Click New to create a new JMS resource.

    

24. Select Connection Factory as the type of resource to create.

    

25. Configure the connection factory with the settings in the table below.

    Name	Value
    Name	ConnectionFactory-0
    JNDI Name	jms.MyCF

    
    

    

26. On the Targets page, click Advanced Targeting to use your subdeployment to target the JMS Server.

    

27. Select the DeployTo-JMSServer-0 subdeployment you created previously, ensure that JMSServer-0 is selected as the only target, and click Finish.

    

Configure a JMS Distributed Queue

28. Click New to create a new JMS resource.

    

29. Select Distributed Queue as the type of resource to create.

    

30. Configure the distributed queue with the settings in the table below.

    Name	Value
    Name	DistributedQueue-0
    JNDI Name	jms.MyDQ
    All other parameters	leave at default settings

    
    

    

31. On the Targets page, click Advanced Targeting to use your subdeployment to target the JMS Server.

    

32. Select the DeployTo-JMSServer-0 subdeployment you created previously, ensure that JMSServer-0 is selected as the only target, and click Finish.

    

Now that you have configured JMS resources, let's configure whole server migration for the dynamic cluster.

1. Navigate to Server Templates in the administration console.

   

2. Select your template.

   

3. Click the migration tab to configure migration settings.

   

4. Select Automatic Server Migration Enabled and save your changes. This enables whole server migration for servers that are based on this template.

   

5. Navigate to Clusters in the administration console.

   

6. Select your dynamic cluster.

   

7. Click the migration tab to configure migration settings.

   

8. Locate the Candidate Machines For Migratable Servers field. Use the button to move both of your machines from the Available column to the Chosen column. Continue to configure migration with settings in the table below.

   Name	Value
   Migration Basis	Database
   Data Source for Automatic Migration	JDBC Data Source-0
   Auto Migration Table Name	ACTIVE
   All other parameters	leave at default settings

   
   

   

9. Save your changes.

At this point, you should have only the AdminServer running. If not, then you must shutdown any other server processes. You may even want to restart your AdminServer to ensure that all configuration changes have taken place. Before restarting the AdminServer, you can use the Change Center in the upper left-hand corner of the administration console to check if any restarts are required. You start the servers that form your dynamic cluster across the machines of your domain. After they are started, you can force a situation that causes migration to occur.

1. Navigate to Servers in the administration console.

   

2. Click the Control tab to access tools for managing the life cycle for your servers.

   

3. Select the first server in your dynamic cluster and click Start. This server should be located on the same machine that the AdminServer is running on. Starting this server first ensures that the server on machine1 becomes the cluster master.

   

4. View the Node Manager console window and verify that it successfully adds the IP address dynamically to the machine.

   

5. Click the button in the administration console to cause the page to refresh automatically. Watch the administration console window and the Node Manager console window for changes. Proceed after you see that the server is in a RUNNING state. Verify dynamic IP address handling in the Node Manager console window.

   

   

6. Navigate to your dynamic cluster in the administration console and click the Monitoring tab and the Summary sub tab. Horizontally scroll the page all the way to the right and verify that the server you started is the cluster master.

   

7. Repeat these steps to start the other managed server running on machine2.

   

Now that your domain is running, let's place messages on the JMS queues.

This tutorial includes JMS components to show that WebLogic supports migration of JMS resources that are targeted to servers in a dynamic cluster. Part of showing that migration is successful is showing that data is accessible in a JMS queue after migration occurs. You use the administration console to place some messages on a JMS queue belonging to a server that you are going to migrate. After migration occurs, you will verify that you can still access the message on the queue.

1. Navigate to JMS Modules in the administration console.

   

2. Select your JMS module.

   

3. Select your distributed queue.

   

4. Click the Monitoring tab.

   

5. Select the queue for server 2 (the server ID will have a 2 in the server name) and click Show Messages.

   

6. Click New to create a new JMS message to place on the queue.

   

7. Locate the Body field and type in a message. Leave all of the other fields at their default values and click OK.

   

8. Verify that your message has been persisted to the queue.

   

9. Repeat these steps again to add more messages.

Now that you have some messages on your queue, let's migrate one of your servers.

At this point, you should have the following set up:

• The AdminServer and server 1 of your dynamic cluster running on machine 1.
• Server 2 of your dynamic cluster running on machine 2.
• Node Manager running on each machine.
• Server 1 and server 2 were both started using the Node Manager.
• The database running on a machine that is accessible to the servers on both machines.
• Servers are configured to migrate automatically.
• Database leasing is configured.
• JMS resources are configured and targeted to the dynamic cluster via the JMS Server subdeployment.
• Some messages placed on the JMS queue for server 2.
• Server 1 was started first to ensure it is the cluster master.

After everything is set up, you are ready to migrate a server. Perform the following steps to migrate server 2 from machine 2 to machine 1.

1. Again, verify that all of your servers are running.

   

2. Press the enter key in both Node Manager terminal windows to clear the screens of any previous messages. This makes it easier to see what is happening during migration.

   

3. Open the killServers.sh script, paste it into a new file on machine 2, and execute the following command to make the file executable.

   $ chmod +x killServers.sh

4. The killServers.sh script kills all java processes running on the machine. You have some different options to use to cause server migration to occur. You can kill the Node Manager and server processes that are running on machine 2, or you can make the machine inaccessible from machine 1 somehow. If your database is not running on machine 2, you can power the machine off, unplug the network from the machine, or anything similar that accomplishes the same thing. If your database is running on server 2 like mine is, then you must kill the Node Manager and server on machine 2 to emulate a machine crash, which is achieved by executing the killServers.sh script as shown below. Choose which approach you will use and execute it now.

   $ ./killServers.sh

   

5. Wait for a minute or two until you see some output in the Node Manager terminal window on machine 1. You should see messages indicating that server 2 is now being migrated and started on machine 1. You should see messages stating that the IP address for server 2 is brought up on machine 1 and that server 2 is being started. After the server is started, you will also see a message that server 2 is now running.

   

6. Verify in the administration console that both servers are still running.

   

7. Server 2 still lists machine 2 as its machine here, so you should check to see if an actual migration occurred. Navigate to your domain in the console, click the Monitoring tab, and then click the Migration tab. This page shows migrations that have taken place.

   

8. Verify that you can access the JMS messages you created earlier. Return to the monitoring tab for your distributed queue on server 2 and click Show Messages. You should now be able to select your messages and view them in the console. This is because the messages are persisted to the database, which is accessible from server even when it is running on machine 1.

   

Congratulations! You just configured and used WebLogic Server whole server migration with JMS and dynamic clusters. Now that you have a working environment, you can experiment with other migration scenarios.