Preparing for Automatic Whole Server Migration

7-6 Using Clusters for Oracle WebLogic Server

7.4 Automatic Whole Server Migration

This section outlines the procedures for configuring automatic whole server migration and provides a general discussion of how whole server migration functions within a WebLogic Server environment. The following topics are covered: ■ Section 7.4.1, Preparing for Automatic Whole Server Migration ■ Section 7.4.2, Configuring Automatic Whole Server Migration ■ Section 7.4.3, Using High Availability Storage for State Data ■ Section 7.4.4, Server Migration Processes and Communications

7.4.1 Preparing for Automatic Whole Server Migration

Before configuring automatic whole server migration, be aware of the following requirements: ■ Verify that whole server migration is supported on your platform. See Support for Server Migration in Oracle WebLogic Server, WebLogic Portal and WebLogic Integration 10gR3 10.3 ■ Each Managed Server uses the same subnet mask. Unicast and multicast communication among servers requires each server to use the same subnet. Server migration will not work without multicast or unicast communication being configured. For information on using multicast, see Section 3.1.1, Using IP Multicast for Backward Compatibility. For information on using unicast, see Section 3.1.2, One-to-Many Communication Using Unicast. ■ All servers hosting migratable servers are time-synchronized. Although migration works when servers are not time-synchronized, time-synchronized servers are recommended in a clustered environment. ■ If you are using different operating system versions among migratable servers, make sure that all versions support identical functionality for ifconfig. ■ The primary interface names used by migratable servers are the same. If your environment requires different interface names, then configure a local version of wlscontrol.sh for each migratable server. For more information on wlscontrol.sh, see Using Node Manager to Control Servers in Node Manager Administrators Guide for Oracle WebLogic Server. ■ See Databases Supporting WebLogic Server Features in Oracle WebLogic Server, WebLogic Portal and WebLogic Integration 10gR3 10.3 for a list of databases for which WebLogic Server supports automatic server migration. ■ You cannot create channelsnetwork access points that have a different listen address on a migratable server. Caution: Support for automatic whole server migration on Solaris 10 systems using the Solaris Zones feature can be found in Note 3: Support For Sun Solaris 10 In Multi-Zone Operation at http:www.oracle.comtechnetworkmiddlewareiasoracleas- supported-virtualization-089265.html . Whole Server Migration 7-7 ■ There is no built-in mechanism for transferring files that a server depends on between machines. Using a disk that is accessible from all machines is the preferred way to ensure file availability. If you cannot share disks between servers, you must ensure that the contents of domain_dirbin are copied to each machine. ■ Ensure that the Node Manager security files are copied to each machine using the nmEnroll WLST command. For more information, see Using Node Manager to Control Servers in Node Manager Administrators Guide for Oracle WebLogic Server. ■ Use high availability storage for state data. For highest reliability, use a shared storage solution that is itself highly available—for example, a storage area network SAN. See Section 7.4.3, Using High Availability Storage for State Data. ■ For capacity planning in a production environment, keep in mind that server startup during migration taxes CPU utilization. You cannot assume that because a machine can handle x number of servers running concurrently that it also can handle that same number of servers starting up on the same machine at the same time.

7.4.2 Configuring Automatic Whole Server Migration