In 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
andarping
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.
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.