| Oracle® Communications ASAP Server Configuration Guide Release 7.2 E24629-01 |
|
 Previous |
 Next |
This chapter provides information about the Control and Daemon servers and configuration parameters associated with these servers.
The Control server is an application server that controls all other Oracle Communications ASAP applications and manages system startup and shutdown. For more information about starting up ASAP, see ASAP System Administrator's Guide. In a distributed environment, a Control server is required on every ASAP machine to start and shut down ASAP processes. One of the Control servers must be configured as the master.
Figure 3-1 illustrates the control and master server configuration in a distributed ASAP environment.
ASAP consists of application processes running in the background as servers and clients. Application processes can be configured using the Service Activation Configuration Tool (SACT) (see "Configuring ASAP Servers"). ASAP uses each service request processor (SRP), service activation request manager (SARM), network element processors (NEPs), and Admin processes as an application server, and they are configured to run as part of the system.
The Control server starts these applications by first verifying that the UNIX program executable file for the application server is located in the ASAP_home/programs directory and is executable. If it is executable, the Control server then instructs the fork agent process to spawn a child process, which in turn overlays itself with the application executable. At this point, the application process starts and the fork agent returns details of the application back to the Control server. For more information about configuring the fork agent, see "Fork Agent Process Generation Configuration".
In addition to providing details about the application back to the Control server, the fork agent also helps the Control server manage alarms generated by the individual server processes. For more information see "Control Server Alarm Generation".
The Control server monitors every client and server application in the ASAP system. If an application terminates unexpectedly, the Control server generates the alarm for the relevant operational community and can also attempt to restart a terminated process. For information about alarm configurations, see the chapter about monitoring and managing ASAP in ASAP System Administrator's Guide. For more information about configuring Control server monitoring and setting process restart attempts, see "Control Server Database and File System Monitoring".
After the application processes have been identified based on your service requirements, determine the Host machine for each process. You can use a single machine or multiple machine configuration to run the ASAP system. Each host machine is then assigned a Control server to control and monitor the ASAP processes for the machine. For more information about installing ASAP on multiple machines, see ASAP Installation Guide.
Next, assign the application processes (servers and clients) to a particular machine, a Control server.
Table 3-1, shows an example of an ASAP system:
Table 3-1 Sample ASAP Configuration
| ASAP Process | Host | Description |
|---|---|---|
|
SARM |
HOST1 |
SARM server for the system |
|
NEPDMS, NEPAXE, NEP5ESS |
HOST2 |
NEPs for the system on HOST2 where the ports and communications devices are installed |
|
SRPTCPIP |
HOST1 |
SRP Server that manages the TCP/IP interface with a host system |
|
SRPLU62 |
HOST1 |
SRP Server that manages the LU62 interface with a host system |
|
LU62SEND & LU62RECV |
HOST1 |
LU62 communication clients that pass data between the Host system and SRP2. These LU62 clients must be started before SRP2 is started. |
You may want to configure ASAP to execute one or more of its processes on a separate or remote server. This can be done to improve performance (for example, to distribute processing loads), or because certain downstream interfaces or networks are not accessible from the machine where ASAP is running.
The server that runs the master control server is called the local machine, host or server. The server where the remote server is running is called the remote machine, host or server.
The ASAP daemon makes it possible for the WebLogic server to reside on a different machine than the one on which an ASAP instance resides. Consequently, the ASAP daemon manages I/O operations required by Oracle WebLogic Server against a remote ASAP instance.
The ASAP daemon handles the file I/O operation requests issued from another UNIX user group or another machine. The ASAP daemon accommodates I/O operations between ASAP applications that use a WebLogic server, such as the SACT, Service Activation Deployment Tool (SADT), and Java SRP.
Specifically, the ASAP daemon supports WebLogic applications to do the following:
File operations against an ASAP instance, as an alternative to Java's File class:
ASAP file read or write
ASAP file/directory state checking, such as isFile, canRead, canWrite, exists, length, or lastModified time
Other ASAP file manipulations, such as delete, renameTo
Special commands performed on the ASAP side:
File copy from source to target
File move from source to target
File extract from a jar to a certain file
Execute a script
Other special commands
Figure 3-2 displays I/O operations for an ASAP instance on a UNIX file system, such as reading and writing a file, or executing a UNIX command or ASAP script. Some methods of accessing ASAP or the UNIX file system, such as RPCs and JDBCs, are independent of the daemon.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
