Whole Server Migration by Rene van Wijk

clip_image002In a WebLogic Server cluster, most services are deployed homogeneously on all server instances in the cluster, enabling transparent fail-over from one server instance to another. In contrast, for ‘pinned services’ such as JMS and the JTA transaction recovery system are targeted at individual server instances within a cluster, WebLogic Server supports failure recovery with migration, as opposed to fail-over.
Migration in WebLogic Server is the process of moving a clustered WebLogic Server instance or a component running on a clustered server instance elsewhere in the event of failure. Upon failure, a migratable server is automatically restarted on the same machine, if possible. If the migratable server cannot be restarted on the machine where it failed, it is migrated to another machine. In addition, an administrator can manually initiate migration of a server instance.

Configure whole server migration

Before we configure whole server migration, we need to know the requirements:

  • The migratable server candidate machines have to be in the same subnet (because the virtual IP address must be valid on each candidate machine). Whole server migration uses a virtual IP address for each migratable server.
  • On each candidate machine, the Node Manager must be initialized such that it can accept commands from the Admin Server.
  • The Node Manager is used to migrate the virtual IP address and assign it to the target machine (i.e., invoke ${DOMAIN_HOME}/bin/server_migration/wlsifconfig.sh addif or invoke ${DOMAIN_HOME}/bin/server_migration/wlsifconfig.sh removeif). Note that the default configuration assumes that the machines are similar, i.e.,
    • The netmask associated with the virtual IP is the same on each candidate machine.
    • The network device (interface) name (for example, eth0 on Linux) is the same on each candidate machine.
    • The functional behavior of the platform-specific OS command used to add and remove the virtual IP (for example, ifconfig and arping on Linux) is the same.
  • Migratable servers cannot define any network channels that use a Listen Address different from the virtual IP address associated with the server. If servers must use multiple network channels associated with multiple IP addresses, whole server migration cannot be used as only migration of a single virtual IP address for each migratable server is supported.
  • Server-specific state must be shared through some highly available sharing mechanism, i.e., the default persistent stores where the XA transaction logs are kept must be accessible on each candidate machine.

As mentioned above the Node Manager invokes the script wlsifconfig.sh to run ifconfig and arping commands (more information on these commands can be found here), for example, Read the complete article here.

WebLogic Partner Community

For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Forum Wiki

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.