Your SlideShare is downloading. ×

Weblogic Administration Managed Server migration

1,292

Published on

The following depicts the automatic automatic migration of administration and managed server in case of failure …

The following depicts the automatic automatic migration of administration and managed server in case of failure
This concept is useful very useful in site failover as well as managed server failover
We have used the Virtual IP and Virtual Hostname concept

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,292
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
77
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Oracle SOA Suite 11g Clustered ConfigurationOracle Fusion Middleware Server MigrationAdministration / Managed ServerOracle SOA Suite & Oracle Service Bus ClusterPrepared By – Rakesh B GujjarlapudiCopyright 2013, Page 1
  • 2. Oracle SOA Suite 11g Clustered ConfigurationTable of Contents1. INTRODUCTION .................................................................................................................................................................. 32. ASSUMPTIONS ................................................................................................................................................................... 33. REQUIREMENTS .................................................................................................................................................................. 44. WEBLOGIC CLUSTER STARTUP PROCEDURE ............................................................................................................................ 65. MANUALLY FAILING OVER THE ADMINISTRATION SERVER TO SOAHOST2 .............................................................................. 76. SERVER MIGRATION ............................................................................................................................................................ 87. TESTING SERVER MIGRATION ............................................................................................................................................ 11Copyright 2013, Page 2
  • 3. Oracle SOA Suite 11g Clustered Configuration 1. INTRODUCTION The Purpose of this document is introduce the concept of weblogic server migration Most services in weblogic server cluster are deployed across all the managed servers in the cluster enabling transparent failover. However for services like JMS and JTA transactions recovery systems are targeted at individual managed server instances in a cluster, hence failover is not the appropriate solution. For services like these weblogic recovery with migration is used instead of failover Managed server migration is a process of moving the instance of the weblogic managed server elsewhere if a failure occurs. The whole managed server instance is migrated to a different physical server upon failure (system hangs, network failure, host system fails). This provides all the services including the JMS and JTA transaction systems to be highly available. Upon failure, a migratable managed server automatically restarts on the same system if possible. If the migratable server cannot restart on the system it failed on, it is migrated to another system. In addition, an administrator can manually initiate migration of a server instance. ifconfig - Enable your network to register the new location of the virtual IP arping - Enable your network to register the new location of the virtual IP. 2. ASSUMPTIONS Base domain is installed using the virtual host name Administration Server installed on SOA_HOST1 using soa-as.comany.com as the host name Managed Server 1(MS1) is installed on SOA_HOS1 using soa_ms1.company.com Managed Server 1(MS1) is installed on SOA_HOS1 using soa_ms2.company.comCopyright 2013, Page 3
  • 4. Oracle SOA Suite 11g Clustered Configuration 3. REQUIREMENTS Network Requirements IP Address Host Name XXX.XXX.XXX.XXX SOA_HOST1 YYY.YYY.YYY.YYY SOA_HOST2 Server 1(SOA_HOST1) - VIP Configuration VIP Ethernet HOST Virtual Host Name Status Interface/Index AAA.AAA.AAA.AAA Eth0-0 SOA_HOST1 soa-as.compnay.com Up BBB.BBB.BBB.BBB Eth0-1 SOA_HOST1 soa-ms1.compnay.com Up CCC.CCC.CCC.CCC Eth0-2 SOA_HOST1 soa-ms1.compnay.com Down Server 1(SOA_HOST1) – /etc/hosts file Configuration AAA.AAA.AAA.AAA soa-as.company.com BBB.BBB.BBB.BBB soa-ms1.company.com CCC.CCC.CCC.CCC soa-ms2.company.com Server 1 – SOA_HOST1 Configuration VIP Ethernet HOST Virtual Host Name Status Interface/IndexCopyright 2013, Page 4
  • 5. Oracle SOA Suite 11g Clustered Configuration AAA.AAA.AAA.AAA Eth0-0 SOA_HOST1 soa-as.compnay.com Up BBB.BBB.BBB.BBB Eth0-1 SOA_HOST1 soa-ms1.compnay.com Up CCC.CCC.CCC.CCC Eth0-2 SOA_HOST1 soa-ms1.compnay.com Down Server 2(SOA_HOST2) – /etc/hosts file Configuration AAA.AAA.AAA.AAA soa-as.company.com BBB.BBB.BBB.BBB soa-ms1.company.com CCC.CCC.CCC.CCC soa-ms2.company.com File Storage (Common Mount Point) Middleware Home - /u04/oracle/Middleware Weblogic Server Home - /u04/oracle/Middleware/wlserver_10.3 SOA Home - /u04/oracle/Middleware/Oracle_SOA1 OSB Home - /u04/oracle/Middleware/Oracle_OSB1 Domain Home - /u04/oracle/admin/domains/base_domain Admin Server Home - /u04/oracle/admin/domains/base_domain/aserver/base_domain Application Home - /u04/oracle/admin/domains/base_domain/applications/base_domain Managed Server 1 Home - /u04/oracle/admin/domains/base_domain/aserver/base_domain/servers/ms1 Managed Server 2 Home - /u04/oracle/admin/domains/base_domain/aserver/base_domain/servers/ms2 Node Manager Configuration on SOA_HOST1 and SOA_HOST2 Both the node manager properties should have the following additional entries File Name - nodemanager.properties File Location - $MW_HOME/wlserver_10.3/common/nodemanager StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=trueCopyright 2013, Page 5
  • 6. Oracle SOA Suite 11g Clustered Configuration 4. WEBLOGIC CLUSTER STARTUP PROCEDURE Start up cluster with migratable server/ Failure of Managed Server 4. Obtain Configuration 2. Contact NM Application Host 1 Application Host 2 6.Obtains migration server lease Weblogic Cluster 1. Start Cluster VIP 1 6.Obtains migration server lease and cluster master lease Admin Server and cluster master lease VIP 3 VIP 2 4. Obtain Configuration Managed Server 1 Managed Server 1 Leasing Table 5. Cache Config FMW DB (Migratable) (Migratable) 2. Contact NM 5. Cache Config 3. Start Managed Server 3. Start Managed Server 7. Renew lease 7. Renew lease Node Manager - 5557 Node Manager - 5557 HOST FILE ENTRY HOST FILE ENTRY Virtual IP Virtual Host Name Virtual Host Name Virtual IPEthernet Interface 0 – Index 0 VIP 1 aaa.aaa.aaa.aaa Soa-as.company.com Soa-as.company.com aaa.aaa.aaa.aaa Ethernet Interface 1 – Index 0Ethernet Interface 0 – Index 1 VIP 2 bbb.bbb.bbb.bbb Soa-ms1.company.com Soa-ms1.company.com bbb.bbb.bbb.bbb ccc.ccc.ccc.ccc Soa-ms2.company.com Soa-ms2.company.com ccc.ccc.ccc.ccc 1. Application Host 2 with Managed Server 2 fails 2. Cluster Master detects that Managed Server 2 lease has expired in the lease table in the next preiodic review 3. Cluster master tries to contact the Node Manager of applicaation host 2 to restart Managed Server 2 Prepared By Since applicathion host 2 is down the contact fails Rakesh B 4. Cluster Master contacts Node Manager on Application Host 1(which is configured as an available host for migratabke servers in the cluster) 5. Node Manager migrate the VIPs(VIP 3 to on application host 2 to application host 1) and starts up Managed Server 2 Gujjarlapudi 6. Managed Server 2 starts up and contacts the Administration Server to obtain its configuration. 7. Managed Server 2 caches the configuration it started up with. 8. Managed Server 2 obtains a migratable server lease table Periodically, the server renews its "lease" by updating the timestamp in the lease table. By default a migratable server renews its lease every 30,000 milliseconds—the product of two configurable ServerMBean properties: – HealthCheckIntervalMillis, which by default is 10,000. – HealthCheckPeriodsUntilFencing, which by default is 3.Copyright 2013, Page 6
  • 7. Oracle SOA Suite 11g Clustered Configuration 5. MANUALLY FAILING OVER THE ADMINISTRATION SERVER TO SOAHOST2 Assumptions The Administration Server is configured to listen on soa_as.company.com, and not on ANY address. The Administration Server is failed over from SOA_HOST1 to SOA_HOST2, and the two nodes have these IP addresses: SOA_HOST1: XXX.XXX.XXX.XXX SOA_HOST2: YYY.YYY.YYY.YYY soa_as.company.com - AAA.AAA.AAA.AAA This is the VIP where the Administration Server is running, assigned to eth0:0, available in SOA_HOST1 and SOA_HOST2. The domain directory where the administration server is running in SOA_HOST1 is on a shared storage and is mounted also from SOA_HOST2. Procedure The following procedure shows how to fail over the Administration Server to a different node (SOA_HOST2): 1. Stop the Administration Server if it is running. 2. Migrate the IP address to the second node: Run the following command as root on SOA_HOST1 SOA_HOST1> /sbin/ifconfig eth0:0 down Run the following command on SOA_HOST2: SOAHOST2> /sbin/ifconfig eth1:0 AAA.AAA.AAA.AAA netmask 255.255.255.0 Make sure that the netmask and interface to be used match the available network configuration in SOA_HOST2. Update the routing tables using arping, for example: SOA_HOST2> /sbin/arping -b -A -c 3 -I eth0 AAA.AAA.AAA.AAA 3. Start Node Manager in SOA_HOST2 4. Start the Administration Server on SOA_HOST2 5. Test that you can access the Administration Server on SOA_HOST2 Ensure that you can access the Oracle WebLogic Server Administration Console Check that you can access and verify the status of components in the Oracle Enterprise ManagerCopyright 2013, Page 7
  • 8. Oracle SOA Suite 11g Clustered Configuration 6. SERVER MIGRATION In this enterprise topology, you must configure server migration for the MS1 and MS2 managed servers.  The MS1 managed server is configured to restart on SOA_HOST2 should a failure occur.  The MS2 managed server is configured to restart on SOA_HOST1 should a failure occur. For this configuration, the MS1 and MS2 servers listen on specific floating IPs that is failed over by WLS Server Migration. Step 1 - Setting Up a User and Tablespace for the Server Migration Leasing Table The first step is to set up a user and tablespace for the server migration leasing table: Create a tablespace called leasing. For example, log on to SQL*Plus as the sysdba user and run the following command: SQL> create tablespace leasing logging datafile DB_HOME/oradata/orcl/leasing.dbf size 32m autoextend on next 32m maxsize 2048m extent management local; Create a user named leasing and assign to it the leasing tablespace. SQL> create user leasing identified by welcome1; SQL> grant create table to leasing; SQL> grant create session to leasing; SQL> alter user leasing default tablespace leasing; SQL> alter user leasing quota unlimited on LEASING; Create the leasing table using the leasing.ddl script. Copy the leasing.ddl file located in either the ORACLE_BASE/product/osbmw/wlserver_10.3/server/db/oracle/920 directory to your database node. Connect to the database as the leasing user. Run the leasing.ddl script in SQL*Plus. SQL> @copy_location/leasing.ddl; Step 2: Creating a Multi-Data Source Using the Oracle WebLogic Server Administration Console for the leasing table Create a data source to each of database instances Make sure that this is a non-xa data source Use Oracles Driver (Thin) Version 9.0.1, 9.2.0, 10, 11 Use Supports Global Transactions, One-Phase Commit, and specify a service name for your database Target these data sources to the clusterCopyright 2013, Page 8
  • 9. Oracle SOA Suite 11g Clustered Configuration Step 3 – Configure MS1 and MS2 for migration targets Configuring Server Migration Targets 1. Log into the Oracle WebLogic Server Administration Console 2. In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page appears. 3. Click the cluster for which you want to configure migration (SOA_Cluster) in the Name column of the table. 4. Click the Migration tab. 5. In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select SOA_HOST1 and SOA_HOST2. 6. Select the data source to be used for automatic migration. In this case select the leasing data source. 7. Click Save. 8. Set the Candidate Machines for Server Migration. You must perform this task for all of the managed servers as follows: 9. In Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers. 10. Select the server for which you want to configure migration. 11. Click the Migration tab. 12. In the Available field, located in the Migration Configuration section, select the machines to which to allow migration and click the right arrow. For MS1, select SOA_HOST2. For MS2, select SOA_HOST1. 13. Select Automatic Server Migration Enabled. This enables the Node Manager to start a failed server on the target node automatically. 14. Click Save. 15. Restart the Administration ServerCopyright 2013, Page 9
  • 10. Oracle SOA Suite 11g Clustered Configuration Configuration MS1 as a migratable target to SOA_HOST2Copyright 2013, Page 10
  • 11. Oracle SOA Suite 11g Clustered Configuration 7. TESTING SERVER MIGRATION To verify that Server Migration is working properly, follow these steps: From Node 1:  Stop the MS1 managed server.  To do this, run this command: SOA_HOST1> kill -9 <pid> pid specifies the process ID of the managed server. You can identify the pid in the node by running this command: SOA_HOST1> ps -ef | grep MS1  Watch the Node Manager console: you should see a message indicating that MS1’s floating IP has been disabled.  Wait for the Node Manager to try a second restart of MS1. Node Manager waits for a fence period of 30 seconds before trying this restart.  Once Node Manager restarts the server, stop it again. Now Node Manager should log a message indicating that the server will not be restarted again locally. From Node2:  Watch the local Node Manager console. After 30 seconds since the last try to restart MS1 on Node 1, Node Manager on Node 2 should prompt that the floating IP for MS1 is being brought up and that the server is being restarted in this node.  Access the soa-infra console in the same IP. Verification From the Administration Console  Migration can also be verified in the Administration Console: Log into the Administration Console. Click on Domain on the left console. Click the Monitoring tab and then the Migration subtab. The Migration Status table provides information on the status of the migration.Copyright 2013, Page 11
  • 12. Oracle SOA Suite 11g Clustered ConfigurationCopyright 2013, Page 12

×