What Is Migration?

Under normal circumstances, an administrator performs daily administrative tasks on the configured MASTER machine. The DBBL on the MASTER machine monitors other machines in a configuration, handles configuration updates, and broadcasts dynamic changes to the TMIB. If the MASTER machine fails, for example, due to a machine crash, database corruptions, BEA Tuxedo system problems, network partitioning, or application faults, the application does not stop running. Clients can still join the application, servers can still service requests, and naming is still available on each local machine. However, until the MASTER machine is restored, servers cannot be activated or deactivated, and an administrator cannot dynamically reconfigure the system.

Similarly, application servers are configured to run on specific machines to service client requests. However, if a machine fails or must be brought down to be serviced, the servers on that machine become unavailable. In each case, you can migrate the servers to a configured BACKUP or alternate machine.

An administrator who performs a migration in preparation for shutting down a machine for service or upgrading, does not face the problems inherent in a machine failure. Therefore an administrator in this situation has a relatively high degree of control over migration activities.

Performing a Master Migration

A master migration is the process of moving the DBBL from the configured MASTER machine to the configured BACKUP machine so that servers can continue to be serviced while the configured MASTER machine is down. To start a migration, an administrator requests that the configured BACKUP assume the role of acting MASTER, and the configured MASTER, the role of acting BACKUP. The acting MASTER then performs all administrative functions: it begins monitoring other machines in the configuration and accepts any dynamic reconfiguration changes.

In the following illustration, Machine 2, the configured BACKUP machine, assumes the role of MASTER, while Machine 1, the configured MASTER, assumes the role of acting BACKUP. When the configured MASTER is available again, it can be reactivated from the acting MASTER (that is, the configured BACKUP). The configured MASTER then regains control as acting MASTER.

Migrating a Server Group

For each group of servers, an administrator specifies a primary machine and an alternate machine. The process of migrating a server group involves activating the server group on the alternate machine.

In the following illustration, GroupA is assigned to Machine 1 (that is, Machine 1 is configured as the primary machine); Machine 2 is configured as the alternate machine for GroupA. After migration, GroupA is activated on Machine 2, which means that all servers in this group and the services associated with them, are available on Machine 2 (the acting primary).

Migrating Machines

While it is sometimes useful to migrate only a single server group, it is more often necessary to migrate an entire machine. This type of migration may be necessary, for example, when a computer fails. Migrating a machine involves migrating each of the server groups running on the machine. An alternate machine must be configured for each server group.

Performing a Scheduled Migration

In a controlled situation, such as when a computer needs to be offline for a while, or needs to be upgraded, an administrator can preserve information about the current configuration for servers and services, and use that information when activating servers on alternate machines. Such use of configuration information is possible because server entries are retained on a primary machine, even after the servers are deactivated and become unavailable in response to a request for a migration.

You can migrate an entire server group or an entire machine. Migration of an entire machine is possible when the same machine is configured as the alternate for all the server groups on a primary machine. When that is not the case (that is, when different alternate machines are configured for different server groups on a primary machine), then the servers must be migrated by group, rather than by machine.

In the following illustration, Machine 1 is the configured MASTER and the primary machine for GroupB; Machine 2 is the configured BACKUP. Server GroupB is configured with Machine 1 as its primary machine and Machine 3 as its alternate. If Machine 1 is taken down, Machine 2 becomes the acting MASTER, and Server GroupB is deactivated, migrated to its alternate (Machine 3), and reactivated.

After deactivating all the servers in a group, you can migrate the group from the acting primary to the acting alternate. You do not need to specify which servers are running, which services are currently advertised, or which, if any, dynamic configuration changes are being made. The configured alternate machine obtains this information from the configuration information for the servers that is available on the configured primary machine, when the servers are deactivated. If data-dependant routing is being used and will continue to be used on the alternate machine, services are routed on the basis of the target group name, instead of the target machine name.

Whether you need to migrate an entire application or only portions of it, be sure to make the necessary changes with minimal service disruption. The integrity of all machines, networks, databases, and other components of your application must remain intact. The BEA Tuxedo system provides a way to migrate an application while preserving the integrity of all its components.