3 Restoring Failed Server Instances

The following sections provide information and procedures for restoring and moving failed servers in a Oracle Communications Services 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 Services Gatekeeper Administration Server while Managed Servers continue to run, by default the Administration Server can discover the presence of the running Managed Servers.

When starting the server, make sure that the startup command or startup script does not include the -Dweblogic.management.discover=false option, which prevents an Administration Server from discovering its 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. 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 still has the status RUNNING in running-managed-servers.xml. The Administration Server attempts to discover non-running servers and throws 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 enables the Administration Server only to monitor the Managed Servers or make runtime changes in dynamic attributes, which are those that can be configured while a server is running.

Restarting an Administration Server on Another Machine

If a machine crash prevents restarting the Administration Server on the same machine, you can recover management of the running Managed Servers as follows:

1. Install the Services Gatekeeper software on the new administration machine, if this has not already been done.

2. Make the application files available to the new Administration Server by copying them from backups or by using a shared disk. 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.

3. Make 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".

4. 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, 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” in Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server at:

http://download.oracle.com/docs/cd/E15523_01/web.1111/e13740/starting_nodemgr.htm

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 “Understanding Managed Server Independence Mode” in Oracle Fusion Middleware Managing Server Startup and Shutdown for Oracle WebLogic Server in:

http://download.oracle.com/docs/cd/E15523_01/web.1111/e13708/failures.htm#START185.

To start up a Managed Server in MSI mode:

1. 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, do one of the following:

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

   2. Rename the configuration file msi-config.xml. When you start the server, it will use the copied configuration files.

   or

   • Use the -Dweblogic.RootDirectory=path startup option to specify a root directory that already contains theconfig.xml and SerializedSystemIni.dat files.

2. 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, 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, 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:

1. Access the Administration Console for the domain.

2. Click the Lock & Edit button to start a configuration session.

3. Click the Environment tab and then the Servers tab in the left pane.

4. Select the name of the server to update from the list of servers in the right pane.

5. Click the Configuration tab and then the General tab. Modify the listen address and port settings to match the new server hardware.

6. Click the Protocols tab and then the Channels tab. Modify any configured network channels to match the network settings of the new server hardware.

7. Click Activate Changes to apply your configuration changes.

8. Start the Managed Server on the new server hardware, using the instructions in "Restarting Failed Access and Network Tier Servers".

In addition to the preceding 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. Remove any old routes that involve the affected Network tier server, and create new routes based on the new server machine's network configuration. For more information, see “Managing and Configuring the Plug-in Manager” in System Administrator's Guide, another document in this set.