The following sections provide information and procedures for restoring and moving failed servers in a Oracle Communications Services Gatekeeper domain:
When you restart a failed Administration Server, no special steps are required. Start the Administration Server as you normally would.
If the Administration Server shuts down while Managed Servers continue to run, you do not need to restart the Managed Servers that are already running in order to recover management of the domain. The procedure for recovering management of an active domain depends upon whether you can restart the Administration Server on the same machine it was running on when the domain was started.
If you restart the WebLogic Administration Server while Managed Servers continue to run, by default the Administration Server can discover the presence of the running Managed Servers.
|Note:||Make sure that the startup command or startup script does not include
The root directory for the domain contains a file,
running-managed-servers.xml, which contains a list of the Managed Servers in the domain and describes whether they are running or not. When the Administration Server restarts, it checks this file to determine which Managed Servers were under its control before it stopped running.
When a Managed Server is gracefully or forcefully shut down, its status in
running-managed-servers.xml is updated to “not-running”. When an Administration Server restarts, it does not try to discover Managed Servers with the “not-running” status. A Managed Server that stops running because of a system crash, or that was stopped by killing the JVM or the command prompt (shell) in which it was running, will still have the status “running’ in
running-managed-servers.xml. The Administration Server will attempt to discover them, and will throw an exception when it determines that the Managed Server is no longer running.
Restarting the Administration Server does not cause Managed Servers to update the configuration of static attributes. Static attributes are those that a server refers to only during its startup process. Servers instances must be restarted to take account of changes to static configuration attributes. Discovery of the Managed Servers only enables the Administration Server to monitor the Managed Servers or make runtime changes in attributes that can be configured while a server is running (dynamic attributes).
If a machine crash prevents you from restarting the Administration Server on the same machine, you can recover management of the running Managed Servers as follows:
When the Administration Server starts, it communicates with the Managed Servers and informs them that the Administration Server is now running on a different IP address.
If the machine on which the failed Managed Server runs can contact the Administration Server for the domain, simply restart the Managed Server manually or automatically using Node Manager. Note that you must configure Node Manager and the Managed Server to support automated restarts, as described in Oracle WebLogic Server Managing Server Startup and Shutdown at.
If the Managed Server cannot connect to the Administration Server during startup, it can retrieve its configuration by reading locally-cached configuration data. A Managed Server that starts in this way is running in Managed Server Independence (MSI) mode. For a description of MSI mode, and the files that a Managed Server must access to start up in MSI mode, see the section about replicating domain configuration files for managed server independence in Oracle WebLogic Server Management Console On-line Help at.
To start up a Managed Server in MSI mode:
SerializedSystemIni.datfile from the Administration Server’s root directory (or from a backup) to the Managed Server’s root directory.
msi-config.xml. When you start the server, it will use the copied configuration files.
|Note:||Alternatively, use the -Dweblogic.RootDirectory=
The Managed Server will run in MSI mode until it is contacted by its Administration Server. For information about restarting the Administration Server in this scenario, see Restarting a Failed Administration Server.
Sometimes it is necessary to restart an Access Tier or Network tier server instance on a different machine. This situation might occur if a server machine’s motherboard fails or if you upgrade to newer server hardware. When restarting a server on a new machine, maintain the same IP address and network configuration (DNS name, port numbers, and so forth) as the previous machine, if possible. If the network configuration remains unchanged, then the server can accept the existing domain configuration and you can restart it using the techniques described in Restarting Failed Access and Network Tier Servers.
If the network configuration is changed on the newer machine, then you must update the domain network configuration to match the server machine. Follow these steps before booting either an Access Tier or Network Tier server:
In addition to the above steps, Network Tier servers require that you update the routing configuration for backwards compatible communication service plug-ins. This is required because the routing configuration uses Network Tier servers’ IP addresses in the plug-in ID. Simply remove any old routes that involve the affected Network Tier server, and create new routes based on the new server machine’s network configuration. Seein the System Administrator’s Guide for more information.