Startup Process in a Cluster with Migratable Servers

Whole Server Migration 7-9 9. Set the candidate machines for server migration. Each server can have a different set of candidate machines, or they can all have the same set. 10. Restart the Administration Server.

7.4.3 Using High Availability Storage for State Data

The server migration process migrates services, but not the state information associated with work in process at the time of failure. To ensure high availability, it is critical that such state information remains available to the server instance and the services it hosts after migration. Otherwise, data about the work in process at the time of failure may be lost. State information maintained by a migratable server, such as the data contained in transaction logs, should be stored in a shared storage system that is accessible to any potential machine to which a failed migratable server might be migrated. For highest reliability, use a shared storage solution that is itself highly available—for example, a storage area network SAN. In addition, if you are using a database to store leasing information, the lease table, described in the following sections, which is used to track the health and liveness of migratable servers, should also be stored in a high availability database. For more information, see Section 7.3, Leasing.

7.4.4 Server Migration Processes and Communications

The sections that follow describe key processes in a cluster that contains migratable servers: ■ Section 7.4.4.1, Startup Process in a Cluster with Migratable Servers ■ Section 7.4.4.2, Automatic Whole Server Migration Process ■ Section 7.4.4.3, Manual Whole Server Migration Process

7.4.4.1 Startup Process in a Cluster with Migratable Servers

Figure 7–1 illustrates the processing and communications that occur during startup of a cluster that contains migratable servers. The example cluster contains two Managed Servers, both of which are migratable. The Administration Server and the two Managed Servers each run on different machines. A fourth machine is available as a backup—in the event that one of the migratable servers fails. Node Manager is running on the backup machine and on each machine with a running migratable server. Note: You should ensure that your login scripts .cshrc, .profile, .login, and such only echo messages from your shell profile if the shell is interactive. WebLogic Server uses an ssh command to login and echo the contents of the server.state file. Only the first line of this output is used to determine the server state. 7-10 Using Clusters for Oracle WebLogic Server Figure 7–1 Startup of Cluster with Migratable Servers These are the key steps that occur during startup of the cluster illustrated in Figure 7–1 : 1. The administrator starts up the cluster. 2. The Administration Server invokes Node Manager on Machines B and C to start Managed Servers 1 and 2, respectively. See Section 7.4.4.4, Administration Server Role in Whole Server Migration. 3. The Node Manager on each machine starts up the Managed Server that runs there. See Section 7.4.4.6, Node Manager Role in Whole Server Migration. Whole Server Migration 7-11 4. Managed Servers 1 and 2 contact the Administration Server for their configuration. See Section 7.4.4.5, Migratable Server Behavior in a Cluster. 5. Managed Servers 1 and 2 cache the configuration with which they started up. 6. Managed Servers 1 and 2 each obtain a migratable server lease in the lease table. Because Managed Server 1 starts up first, it also obtains a cluster master lease. See Section 7.4.4.7, Cluster Master Role in Whole Server Migration. 7. Managed Server 1 and 2 periodically renew their leases in the lease table, proving their health and liveness.

7.4.4.2 Automatic Whole Server Migration Process