System services and EGO daemons

A system service is a self-contained, continuously running process that accepts one or more requests and returns one or more responses. Services may have multiple concurrent service instances running on multiple hosts. Most system services are automatically enabled by default at installation (derbydb is the exception, and must be manually enabled during installation).

About the service controller

The service controller is the first service that runs on top of the EGO kernel. It functions as a bootstrap mechanism for starting the other services in the cluster. It also monitors and recovers the other services. It is somewhat analogous to init on UNIX systems or Service Control Manager on Windows systems. After the kernel boots, it reads a configuration file to retrieve the list of services to be started.

The service controller acts as a client to the EGO kernel, requesting resource allocations for running services and instantiating activities to host those services. It ensures that all the defined services are running by detecting failures and restarting service instances based on the parameter settings in the Control Policy portion of the service profile.

The service controller also provides APIs to allow other tools to instantiate, control, and query services at runtime.

Service definition

The service controller reads configuration files for services that must be instantiated. The configuration files are XML documents (service profile) that contain the service definition (that is, parameters that define the type of resources the service instances need to run along with how to start and monitor the service instances). These files can be created either by the service controller administrator or by the API during runtime. There is one service definition file dedicated to each service.

Start-up sequence

Service controller start-up sequence:

  1. One of the hosts within the cluster is elected as the master. The master host, in turn, starts the EGO kernel, which then starts the service controller on the same host.

  2. The service controller opens a connection to EGO and registers as a recoverable client.

  3. The service controller loads the service definition database containing the list of services that need to be instantiated.

  4. The service controller recovers the latest state info from EGO and starts and stops services following the service definitions from the database. The service controller is ready for service.

About the service director

The service director is a basic system service that functions as a locating mechanism for other system services. The service director contains a stand-alone Domain Name Server (DNS), which is the authoritative name server for the EGO DNS sub-domain and responds to DNS queries for system services.

Restriction:

The service director is not supported by Simplified WEM.

The service director runs on the EGO master host and relies on the service controller to provide location information and state change notifications of service instances.

When a service instance enters the RUN state, the service director adds its location information into the service director DNS server. When a service instance transfers from the RUN state into other states, the service director deletes the location information from its DNS server.

When the locations of the service director DNS server or other system services are changed, the service director updates the corresponding resource record in the DNS database of the corporation DNS server or service director DNS server, respectively.

Service director DNS server

The service director DNS server is a stand-alone DNS server and has the responsibility to process DNS queries and maintain the mapping between server names and IP addresses. There is only one service director DNS server running in the EGO environment.

Service director start-up and recovery

The service director DNS server is essential to the operation of the service director. Consequently, the service director DNS server is configured with automatic startup, and therefore, the service controller starts the service director DNS server whenever it finds the DNS server is not running.

When the service controller restarts, it recovers the information of all the services from the EGO kernel. If the service controller finds the service director DNS server is still running, it recovers it.

During recovery, the service director performs the following steps:

  1. Updates the service director DNS server location information

    Removes the old location information of the service director DNS server from the corporation DNS server, and then adds the new location information.

  2. Updates services location information

    Removes the old location information of all current services, and then adds the current location information of services that have running instances.

Service instance location update

When a service instance is down and there is no other instance running on the same host, the service director deletes its location information from the service director DNS server. When a service instance is running, the service director adds its location information in the service director DNS server. The service director DNS server handles the duplicate location information.

About WEBGUI service and Web server

The WEBGUI service provides a high level view of running system services from the Platform Management Console. A cluster administrator can view detailed system service information and assess whether any actions are required for system services and service instances.

Service configuration can be done via the Platform Management Console. Configurations done through the Console are updated automatically in a service profile (XML file). The system service is also registered through the Platform Management Console.

The Web server is the host that runs the WEBGUI service (in effect, the Platform Management Console). Only one management host is elected as the Web server host.

About WebServiceGateway

The web service gateway (WebServiceGateway) service is a runtime component of EGO. The gateway provides a standards-based web services interface for web service clients to access EGO functionality. The web service client sends its request to the gateway via SOAP protocol. The gateway calls the EGO C APIs to perform the required operations on behalf of the web service client and returns the results.

Daemon file names

The following table outlines the EGO daemons and their associated log file names. Log files on Windows hosts have a .txt extension. Audit logs must be enabled first.

Daemon

Log file name

tomcat (WEBGUI)

catalina.out

datasourcetools (Database Configuration Tool)*

datasourcetools.hostname.log

egoconsumerresloader (Consumer Resource Data Loader)*

egoconsumerresloader.hostname.log

egodynamicresloader (Dynamic Metric Data Loader)*

egodynamicresloader.hostname.log

egoeventsloader (EGO Events Data Loader)*

egoeventsloader.hostname.log

egosc (EGO Service Controller)

egoservice.audit.log, esc.log.hostname

egostatisticresloader (Static Attribute Data Loader)*

egostatisticresloader.hostname.log

fam (File Access Manager)

fam.hostname.log

lim (Load Information Manager)

lim.log.hostname

named (Service Director)

named.log

pem (Process Execution Manager)

pem.log.hostname

pim (Process Information Manager)

pim.log.hostname (Linux only)

plc (Loader Controller)*

plc.hostname.log

purger (Data Purger)*

purger.hostname.log

rfa (Remote File Access)

cli.hostname.log

rs (Repository Service)

rs.hostname.log, repositoryservice.audit.log

vemkd (EGO Kernel Daemon)

ego.audit.log, vemkd.log.hostname

WSG (Web Service Gateway)

wsg.log

WSM (Platform Management Console/WEBGUI)

wsm.log.hostname