Administering a Tuxedo Application at Run Time
This topic includes the following sections:
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.
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
.
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).
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.
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.
The BEA Tuxedo system allows you to migrate:
MASTER
machine to a BACKUP
machine, and vice-versaYou can also cancel a migration.
By migrating a combination of the application components listed here, and using the system utilities for recovering a partitioned network, you can migrate entire machines.
When a MASTER
machine must be shut down for maintenance, or is no longer accessible due to an unanticipated problem (such as a partitioned network), then you must transfer the work of the MASTER
to a configured BACKUP
machine.
Note: Before you can migrate the MASTER
, both the MASTER
and BACKUP
machines must be running the same release of the BEA Tuxedo system software.
This type of switching is done by migrating the DBBL from the MASTER
to the BACKUP
. To migrate the DBBL, enter the following command:
In most cases, you need to migrate application servers to alternate sites, or restore the MASTER
machine. For more detail about the tmadmin
command, see the tmadmin(1) reference page in the File Formats, Data Descriptions, MIBs, and System Processes Reference.
The following two sample tmadmin
sessions show how to switch MASTER
and BACKUP
machines regardless of whether the MASTER
machine is accessible from the BACKUP
machine. In the first example, the MASTER
machine is accessible, so the DBBL
process is migrated from the MASTER
to the BACKUP
.
Listing 7-1 Switching MASTER and BACKUP When MASTER Is Accessible from BACKUP
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
> master
are you sure? [y,n] y
Migrating active DBBL from SITE1 to SITE2, please wait...
DBBL has been migrated from SITE1 to SITE2
> q
In the second example, because the MASTER
machine is not accessible from the BACKUP
machine, the DBBL
process is created on the BACKUP
machine.
Listing 7-2 Switching MASTER and BACKUP When MASTER Is Not Accessible from BACKUP
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
TMADMIN_CATT:199: Cannot become administrator. Limited set of commands available.
> master
are you sure? [y,n] y
Creating new DBBL on SITE2, please wait... New DBBL created on SITE2
> q
LMID
parameter (for the server group being migrated) in the GROUPS
section of the UBBCONFIG
file. Servers in the group must specify RESTART=Y
and the MIGRATE
option must be specified in the RESOURCES
section of the UBBCONFIG
file.
tmshutdown -R -g
groupname
tmadmin
To migrate a server group when the alternate machine is accessible from the primary machine, complete the following procedure.
To migrate a server group when the alternate machine is not accessible from the primary machine, switch the MASTER
and BACKUP
machines, if necessary.
tmadmin
pclean
primary_machine
migrate
groupname
boot -g
groupname
The following two sample sessions show how you can migrate a server group, regardless of whether the alternate machine is accessible from the primary machine. In the first example, the alternate machine is accessible from the primary machine.
Listing 7-3 Migrating a Group When the Alternate Machine Is Accessible from the Primary Machine
$ tmshutdown -R -g GROUP1
Shutting down server processes...
Server ID = 1 Group ID = GROUP1 machine = SITE1: shutdown succeeded
1 process stopped.
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> migg GROUP1
migg successfully completed
> q
In the second example, the alternate machine is not accessible from the primary machine.
Listing 7-4 Migrating a Group When the Alternate Machine Is Not Accessible from the Primary Machine
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> pclean SITE1
Cleaning the DBBL.
Pausing 10 seconds waiting for system to stabilize.
3 SITE1 servers removed from bulletin board
> migg GROUP1
migg successfully completed.
> boot -g GROUP2
Booting server processes ...
exec simpserv -A :
on SITE2 -> process id=22699 ... Started.
1 process started.
> q
LMID
parameter to name the processor on which the server group(s) have been running. The alternate location must be the same for all server groups on the LMID
.
tmshutdown
-R
migratemach
(migm
) command to migrate all server groups from one machine to another when the primary machine must be shut down for maintenance or when the primary machine is no longer accessible. (The command takes one logical machine identifier as an argument.)To migrate a machine when the alternate machine is accessible from the primary machine, complete the following procedure.
To migrate a machine when the alternate machine is not accessible from the primary machine, switch the MASTER
and BACKUP
machines, if necessary.
tmadmin
pclean
primary_machine
migratemach
primary_machine
boot -l
alternate_machine
The following sample session shows how to migrate machines. In the first example, the alternate machine is accessible from the primary machine.
Listing 7-5 Migrating a Machine When the Alternate Machine Is Accessible from the Primary Machine
$ tmshutdown -R -l SITE1
Shutting down server processes...
Server ID = 1 Group ID = GROUP1 machine = SITE1: shutdown
succeeded 1 process stopped.
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> migm SITE1
migm successfully completed
> q
In the second example, the alternate machine is not accessible from the primary machine.
Listing 7-6 Migrating a Machine When the Alternate Machine Is Not Accessible from the Primary Machine
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
>pclean SITE1
Cleaning the DBBL.
Pausing 10 seconds waiting for system to stabilize.
3 SITE1 servers removed from bulletin board
> migm SITE1
migm successfully completed.
> boot -l SITE2
Booting server processes ...
exec simpserv -A :
on SITE2 -- process id=22782 ... Started.
1 process started.
>q
If you decide, after deactivating a server group or machine, that you do not want to continue, you can cancel the migration before reactivating the server group or machine. All the information in the name server for the deactivated servers and services is deleted.
To cancel a migration after a shutdown but before issuing the migrate
command, enter one of the following commands.
Server entries are deleted from the bulletin board. You must reboot the servers once the migration procedure is canceled. |
||
The following sample tmadmin
session shows how a server group and a machine can be migrated between their respective primary and alternate machines.
Listing 7-7 Canceling a Server Group Migration for GROUP1
$tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> psr -g GROUP1
a.out Name Queue Name Grp Name ID RqDone Ld Done Current Service
---------- ---------- -------- -- ------ ------- ---------------
simpserv 00001.00001 GROUP1 1 - - (DEAD MIGRATING)
> psr -g GROUP1
TMADMIN_CAT:121: No such server
migg -cancel GROUP1
>boot -g GROUP1
Booting server processes...
exec simpserv -A:
on SITE1 ->process id_27636 ... Started. 1 process started.
> psr -g GROUP1
a.out Name Queue Name Grp Name ID RqDone Ld Done Current Service
---------- ---------- -------- -- ------ ------- ---------------
simpserv 00001.00001 GROUP1 1 - - ( - )
> q
To migrate a transaction log to a BACKUP
machine, complete the following procedure.
tmadmin
dumptlog [-z
config
] [-o
offset
] [-n
filename
] [-g
groupname
]
Note: The TLOG
is specified by the config
and offset
arguments. The value of offset
defaults to 0
; name
defaults to TLOG
. If the -g
option is chosen, only those records coordinated by the TMS
from groupname
are dumped.
loadtlog -m
machine filename
logstart
machine