Summary of Migratable Targets
Column Display Related Tasks Related Topics
This page allows you to customize the column display in the table, create a new migratable target, and delete a migratable target. A migratable target is a special target that can serve as a grouping of pinned services. It is active on only one server member in a cluster so that a member will not be a single point of failure.
Migratable pinned services include JMS servers, SAF agents, path service, custom persistent stores, and the JTA Transaction Recovery Service. You can manually migrate a migratable target in response to a server failure or as part of regularly scheduled maintenance.
You can show fewer or additional data points on this page by expanding Customize this table and modifying the Column Display list. Each data point displays in its own table column.
The following table lists all of the data points that you can display in columns on this page.
Name Description Name
The name that you specified when you created the migratable target.
Returns the cluster this singleton service is associated with.
User Preferred Server
Returns the server that the user prefers the singleton service to be active on.
The list of servers that are candiates to host the migratable services deployed to this migratable target. If the constrainedCandidateServers list is empty, all servers in the cluster are returned. If the constrainedCandidateServers list is not empty, only those servers will be returned. The user-preferred server will be the first element in the list.
Pre-Migration Script Path
Specifies the path to the pre-migration script to run before a migratable target is actually activated. The script must be in the
Before the migratable target is activated, if there is a script specified, and Node Manager is available, then the script will run. Specifying a script without an available Node Manager will result in an error upon migration.
If the script fails or cannot be found, migration will not proceed on the current server, and will be tried on the next suitable server. This could be the next server in the candidate server list, or in the cluster, if there is no candidate server list.
Post-Migration Script Path
Specifies the path to the post-migration script to run after a migratable target is fully deactivated. The script must be in the
After the migratable target is deactivated, if there is a script specified, and Node Manager is available, then the sript will run. Specfiying a script without an available Node Manager will result in an error upon migration.
Non-local Post-Migration Script Allowed
Specifies whether or not the post-deactivation script is allowed to run on a different machine.
Normally, when automigration occurs, the post-deactivation script will be run on the service's current location, and the pre-activation script on the service's new location. If the current location is unreachable for some reason, this value will be checked to see if it is safe to run it on the service's new machine.
This is useful if the post-deactivation script controls access to a networked resource and does not need any data from the current machine.
- Configure server migration in a cluster
- Configure JMS-related services migration
- Configure the JTA Transaction Recovery Service for migration