4 Starting, Stopping, and Administering Servers

This chapter describes how to start and stop servers in an Oracle Communications Services Gatekeeper domain, and configuring the heartbeats between servers.

Overview of Starting and Stopping Servers

A typical production Services Gatekeeper domain contains multiple access tier and network tier servers, with dependencies among the different types of servers. The process of starting up a domain is given here:

  1. Start the administration server for the domain.

    The administration server provides the initial configuration to access tier and network tier servers in the domain. It can also be used to monitor the startup/shutdown status of each managed server.

    Start the administration server by using either the startAdminServer script installed with the Configuration wizard or a custom startup script.

  2. Start network tier servers in each partition.

    The access tier cannot function until servers in the network tier are available.

  3. Start access tier (application tier) servers in each partition.

Caution:

All servers should be started and available before opening the system to production network traffic.

Performance Implications

The Services Gatekeeper start scripts use default values for many Java Virtual machine (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.

Starting Service Gatekeeper Servers

To start Services Gatekeeper servers, you can use the following:

Special Instruction for Starting Servers on Solaris 64-bit Systems

If your installation supports Solaris 64-bit and you are using Sun's JVM, you must add the -d64 flag to whichever startup script you are using. If you do not use this flag, the JVM will default to 32-bit.

Starting and Stopping Services Gatekeeper Servers with Scripts

Start network tier and access tier servers by using either the startManagedWebLogic script installed with the Configuration wizard or your own custom startup script.

To use the startManagedWebLogic script, specify the name of the server to start and the URL of the administration server for the domain using the syntax:

startManagedWebLogic.sh managed_server_name admin_url

For example:

startManagedWebLogic.sh networknode0-0 t3://adminhost:7001

About User Credentials for WebLogic Servers

By default, the servers are started in production mode. This means that user credentials must be provided. For more information, see the discussion about:

Starting Servers with the WebLogic Node Manager Utility

You can also start network tier and access tier servers by using the Administration Console with an instance of Node Manager running on each machine. There are many different ways to run Node Manager.

A simple Java-based version follows:

Note:

Windows is not supported for production servers.

The following instructions assume a UNIX or Linux system. The instructions must be followed on a managed server.

  1. To properly start Services Gatekeeper, configure the nodemanager.properties file on each node.

    To start managed servers in clustered environments using Node Manager, edit nodemanager.properties to use the startup script during Services Gatekeeper domain configuration. Using this startup script ensures that the classpath is set correctly so managed servers have access to Services Gatekeeper files.

    To configure nodemanger.properties:

    1. Open nodemanager.properties in a text editor.

    2. Ensure StartScriptEnabled is set to true.

    3. Ensure StartScriptName specifies the Services Gatekeeper startup script on the node.

  2. Start the node manager.

    The best practice is to have this as part of the normal machine startup sequence. To do it manually:

    1. Log in into the server.

    2. Change to the Middleware_home/wlserver/server/bin directory.

    3. Run the ./startNodeManager.sh script.

  3. Add the domains that the Node Manager instance controls to the Middleware_home/wlserver/common/nodemanager/nodemanager.domains file.

    See "Configuring nodemanager.domains File" in Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server for a description of nodemanager.domains.

    A sample entry for a domain in this file is:

    gatekeeper-domain=/bea/user_projects/domains/gatekeeper-domain
    
  4. Edit the Middleware_home/wlserver/common/nodemanager/nodemanager.properties file. Ensure that StartScriptEnabled=true is set.

  5. Restart the node manager, using Step 1 above.

  6. To create a startup script, do the following:

    1. In the domain_home directory, create a file called startWeblogic.sh.

    2. Add the following line:

      ./bin/startManagedWebLogic.sh SERVER_NAME ADMIN_HOST_PORT
      

      For example: ./bin/startManagedWebLogic.sh NT1 192.168.1.42:7001

  7. Ensure that Listen Address is configured in the Administration Console. To do so:

    In Domain Structure, click Environment, then Machines, then machine_name, and finally Node Manager.

    You must click Lock & Edit before you make any changes. Click Save, if you make any changes.

  8. To start Services Gatekeeper servers using the Node Manager:

    1. Go to the domain's Administration Console.

    2. Under Environment, select the managed servers you want to start.

Configuring Domain Server Heartbeats

Services Gatekeeper uses a heartbeat mechanism to continuously ensure that all NT/AT servers in a cluster are available to process traffic. This feature is not enabled by default; you enable it from the Administration Console using the IsActive field of the HeartbeatMBean.

See "HeartBeatMBean Reference" for information on how to use HeartBeatMBean..

The heartbeat mechanism is designed to ensure the high availability (HA) access among servers in a cluster. This feature sends heartbeat messages to all servers in a cluster, and if one does not respond within a configurable time, it reroutes all traffic to servers that are available. This mechanism replaces the Oracle WebLogic Server heartbeat mechanism which uses the NT server JNDI tree for routing.

The heartbeat messages are very small and the default settings have a negligible affect on server performance if enabled.

Server communication may fail for many reasons, including being shutdown for maintenance, crashing, or for network problems unrelated to the server itself. The heartbeat mechanism just determines whether the server is available to process traffic. If all servers become unavailable and no traffic can be processed, the WebLogic server itself sends an error message.

For an overview of the Services Gatekeeper high availability features, see ”About High Availability” in Services Gatekeeper Concepts.

Services Gatekeeper also includes an unrelated network node heartbeat mechanism that plug-ins use to determine if network nodes are functional. See "Configuring Network Node Heartbeats" for details.

Understanding the Services Gatekeeper Heartbeat Settings

Once enabled, you use the heartbeat settings in the Administration Console (oracle.ocsg.heartbeat.nt.management object; HeartbeatMBean MBean) to control how Services Gatekeeper decides a server is unavailable for processing traffic. A server is considered unavailable if it has not responded to one of the 3 consecutive heartbeat messages within 900 milliseconds (300 milliseconds per message). If a server is unavailable, no further traffic is sent to it. The probing server continues to send heartbeat requests to the unavailable server, and returns it to service if it meets the response criteria. The number of heartbeats and the time to respond to each are configurable.

The HeartbeatMBean MBean does not generate alarms, EDRs, or error messages. See "HeartBeatMBean Reference" for information on how to use HeartBeatMBean.

HeartBeatMBean Reference

Set field values and use methods from the Administration Console by selecting Container, then Services, followed by HeartBeat. You can also set them using a Java application. For information on the methods and fields, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.

Stopping Service Gatekeeper Servers

It is recommended that you shut down WebLogic Server instances through the Administration Console. See the instructions to shut down a server instance, control graceful shutdowns, and shut down servers in a cluster in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.