14 Starting and Stopping Servers

This chapter describes how to start and stop servers in an Oracle Communications Converged Application Server domain:

Startup Sequence for a Converged Application Server Domain
Administration Server Best Practices

Startup Sequence for a Converged Application Server Domain

Converged Application Server start scripts use default values for many JVM parameters that affect performance. For example, JVM garbage collection and heap size parameters may be omitted, or may use values that are acceptable only for evaluation or development purposes. In a production system, you must rigorously profile your applications with different heap size and garbage collection settings in order to realize adequate performance. See "Modifying JVM Parameters in Server Start Scripts" in the chapter "Tuning JVM Garbage Collection for Production Deployments" for suggestions about maximizing JVM performance in a production domain.

Caution:

When you configure a domain with multiple engine and SIP data tier servers, you must accurately synchronize all system clocks to a common time source (to within one or two milliseconds) in order for the SIP protocol stack to function properly. See "Configuring NTP for Accurate SIP Timers" in Chapter 8, "Configuring Engine Tier Container Properties" for more information.

Because a typical Converged Application Server domain contains numerous engine and SIP data tier servers, with dependencies between the different server types, you should generally follow this sequence when starting up a domain:

Start the Administration Server for the domain. Start the Administration Server in order to provide the initial configuration to engine and SIP data tier servers in the domain. The Administration Server can also be used to monitor the startup/shutdown status of each Managed Server. You generally start the Administration Server by using the startWebLogic.sh or startWebLogic.cmd script (depending on your OS) installed with the Configuration Wizard, or a custom startup script.
Start SIP data tier servers in each partition. The engine tier cannot function until servers in the SIP data tier are available to manage call state data. Although all replicas in each partition need not be available to begin processing requests, at least one replica in each configured partition must be available in order to manage the concurrent call state. All replicas should be started and available before opening the system to production network traffic.

You generally start each SIP data tier server by using either the startManagedWebLogic.cmd script installed with the Configuration Wizard, or a custom startup script. startManagedWebLogic.cmd requires that you specify the name of the server to startup, as well as the URL of the Administration Server for the domain, as in:
```
startManagedWebLogic.cmd datanode0-0 t3://adminhost:7001
```
Start engine tier servers. After the SIP data tier servers have started, you can start servers in the engine tier and begin processing client requests. As with SIP data tier servers, engine tier servers are generally started using the startManagedWebLogic.cmd script or a custom startup script.

Following the above startup sequence ensures that all Managed Servers use the latest SIP Servlet container and SIP data tier configuration. This sequence also avoids engine tier error messages that are generated when servers in the SIP data tier are unavailable.

Administration Server Best Practices

The Administration Server in a Converged Application Server installation is required for configuring, deploying, and monitoring services and applications.

Note:

If an Administration Server fails due to a hardware, software, or network problem, only management, deployment, and monitoring operations are affected. Managed Servers do not require the Administration Server for continuing operation; Java EE applications and SIP features running on Managed Server instances continue to function even if the Administration Server fails.

Oracle recommends the following best practices for configuring Administration Server and Managed Server instances in your Converged Application Server domain:

Run the Administration Server instance on a dedicated machine. The Administration Server machine should have a memory capacity similar to Managed Server machines, although a single CPU is generally acceptable for administration purposes.
Configure all Managed Server instances to use Managed Server Independence. This feature allows the Managed Servers to restart even if the Administration Server is unreachable due to a network, hardware, or software failure. See Managing Server Startup and Shutdown for Oracle WebLogic Server in the Oracle WebLogic Server 11g documentation for more information.
Configure the Node Manager utility to automatically restart all Managed Servers in the Converged Application Server domain. See Oracle WebLogic Scripting Tool in the Oracle WebLogic Server 11g documentation for more information.

Should an Administration Server instance or machine fail, remember that only configuration, deployment, and monitoring features are affected, but Managed Servers continue to operate and process client requests. Potential losses incurred due to an Administration Server failure include:

Loss of in-progress management and deployment operations.
Loss of ongoing logging functionality.
Loss of SNMP trap generation for WebLogic Server instances (as opposed to Converged Application Server instances). On Managed Servers, Converged Application Server traps are generated even in the absence of the Administration Server.

To resume normal management activities, restart the failed Administration Server instance as soon as possible.