Restoring Failed Server Instances

The following sections provide information and procedures for restoring and moving failed servers in a WebLogic Network Gatekeeper domain:

Restarting a Failed Administration Server

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.

Restarting an Administration Server on the Same Machine

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.

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).

Restarting an Administration Server on Another Machine

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:

Install the WebLogic Network Gatekeeper software on the new administration machine (if this has not already been done).
Make your application files available to the new Administration Server by copying them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server.
Make your configuration and security data available to the new administration machine by copying them from backups or by using a shared disk. For more information, refer to Storing the Domain Configuration Offline and “Backing Up Security Data” on page 11-5.
Restart the Administration Server on the new machine.

Make sure that the startup command or startup script does not include -Dweblogic.management.discover=false, which disables an Administration Server from discovering its running Managed Servers.

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.

Restarting Failed Access and Network Tier Servers

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 Using Node Manager to Control Servers in the WebLogic Server 10 documentation.

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 Replicating domain config files for Managed Server Independence in the WebLogic Server 10 documentation.

Ensure that the following files are available in the Managed Server’s root directory:

msi-config.xml.
SerializedSystemIni.dat
boot.properties

If the files are not in the Managed Server’s root directory:

Copy the config.xml and SerializedSystemIni.dat file from the Administration Server’s root directory (or from a backup) to the Managed Server’s root directory.
Rename the configuration file to msi-config.xml. When you start the server, it will use the copied configuration files.

Note: Alternatively, use the -Dweblogic.RootDirectory=path startup option to specify a root directory that already contains these files.

Start the Managed Server at the command line or using a script.

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.

Moving an Access or Network Tier Server to a Different Machine

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:

Access the Administration Console for the domain.
Click the Lock & Edit button to start a configuration session.
Select the Environment->Servers tab in the left pane.
Select the name of the server to update from the list of servers in the right pane.
Use the Configuration->General tab to modify the listen address and port settings to match the new server hardware.
Use the Protocols->Channels tab to modify any configured network channels to match the network settings of the new server hardware.
Click Activate Changes to apply your configuration changes.
Start the Managed Server on the new server hardware, using the instructions in Restarting Failed Access and Network Tier Servers.

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. See Managing and Configuring the Plug-in Manager in the System Administrator’s Guide for more information.