Understanding Control Compliance Suite (CCS) Reporting and Analytics Service Startup

book

Article ID: 181012

calendar_today

Updated On:

Products

Control Compliance Suite Windows

Issue/Introduction

 

Resolution

 

This article explains the service start-up as follows:
This section provides information on DPS Service startup and its main components.
DPS Service startup
The following is the process of DPS Service startup:
 
  1. Sets the base directory and temp directory.
This is a working scratch directory for DPS service.
  1. Initiates executors and registers handlers for various job types.
  2. Registers the following jobs to DPS:
·         Sets up scheduler.
·         Sets up session manager.
·         Sets up failed target subsystem.
  1. Validates DPS certificate.
  2. Starts Workerprocess Manager.
 
 DPS Service Startup
Figure 1: DPS Service startup
 
 
  


Main components of DPS Service
The main components of a DPS Service are as follows:
·         Executor
·         Scheduler
·         Session Manager
·         Worker Process Manager
 
This component plays a critical role during DPS startup sequence and is responsible in arranging and bringing together various internal subsystems.
During DPS startup, the executor does the following:
1.       Loads the configuration from *.config.xml files.
These files are used when .net remoting is the communication protocol that is used.
2.       Reads the following host specific configuration of blade from ADAM:
    • Communication settings
    • Scheduler settings
    • Session manager settings
    • IS credential settings
    • Worker process manager settings
    • Failed target subsystem settings
3.       Prepares parameters for the scheduler of the blade with the information that is read from the configuration store. The parameters that are included are as follows:
    • Min/max submit threads
    • Min/max resume threads
    • Min/max scheduler threads
4.       Starts blades scheduler singleton instance with the schedule specific parameters that are specified in step 3.
5.       Resets the following session manager configuration to default:
    • Default poll time – 5000 ms
    • Ready poll time – 0 ms
    • Job cleanup time
    • Max collect failures
    • Dispatch job timeouts and inquiry timeouts – 3600000
    • Max atomic collection size in bytes
    • Min/max command threads – 2 and 20 respectively
    • Command poll timeout
    • Others
6.       Initiates session manager startup sequence.
7.       Resets or initializes failed target subsystem with default parameters.
8.       Loads MOS and SCAP translation.
 
 
This subsystem schedule commands or jobs as and when they are requested by the other subsystems,  which in most situations is the session manager.
Internally this subsystem implements priority queues that maintain a list of commands or jobs that are to be executed and pool of thread servicing each queue.
 
 The Session manager does the following:
  • Facilitate registration and un-registration of various job factories.
  • Allow local as well as remote job submission to remote DPS or local worker process.
  • Perform bookkeeping of parent and child jobs.
  • Allow submitting remote jobs to other DPS.
  • Collect and submit results.
  • Implements job cancellation support for local as well as remote jobs.
 
The Worker process manager component maintains the pool of workerprocess executables to run the jobs. It is responsible for starting a job and stopping workerprocess executable, recycling the process once the process executes set number of jobs, count of process to run, count of concurrent jobs to execute per process. The default configuration is as follows, but you can overwrite it by changing the values in DPS service configuration file:
  • WPM_MinimumWorkerProcesses = 2
  • WPM_MaximumWorkerProcesses = 5
  • WPM_MaximumJobsPerWorkerProcess = 1
  • WPM_WorkerProcessStartTimeout_Seconds =5 mins
  • WPM_WorkerProcessIdleRecycleTime_Seconds = 5 mins
  • WPM_JobSubmissionRetryCount = 5
  • WPM_JobSubmissionTotalRetryTime_Seconds = 3 mins
  • WPM_WorkerProcessLaunchRetryLimit = 4
 
This section provides information on Application server service startup and its main components.
 
Application server service startup
The activities that are given below occur in a sequence. If you want to track the progress, you can also track these activities by setting the Application Server log in the verbose mode.
 
1.       Enter startup sequence
Log: Server.Start: Appserver remoting server starting
 
2.       Establish connection to ADAM
Log: Server.Start: Checking for ADAM
Service reads the ADAM server name from the configuration file and tries to connect to the Symantec CCS ADAM instance. If the connection is successful, it builds the CCS object schema cache. If ADAM server is unreachable then service initiates a service shutdown event.
 
3.       Create a Role Based Access Control instance (RBAC)
Log: Server.Start: Loading RBAC
Creates an RBAC instance. This instance is used for all the access control requests.
 
4.       Check for valid core license
Log: Server.Start: Checking Core License
Checks if the CCS core license is valid and creates a timer object that checks the validity for core licenses periodically.
 
5.       Validate server certificate
Log: Server.Start: Validating APS certificate
Validates the Application Server certificate.
 
6.       Establish DPS session manager
Log: Server.Start: Starting Blade Session Manager
Loads the MOS and SCAP schema and sets up the job management infrastructure to facilitate operations such as submit job, collect job results, terminate job, job status, shutdown, and so on.
 
7.       Start WCF service host
Log: Server.Start: Starting up WCF service hosts
Starts to .Net WCF object that allows communication from remote computers or clients to the Application Server.
 
8.       GenerateSymmetricKey
Log: Server.Start: Generating Symmetric key
Generates key for symmetric cryptography. This must happen before using the secure storage.
 
9.       CheckForLocalCreds
Log: Server.Start: Checking local storage for credentials
Application Server service maintains a local secure storage, which is a local credential cache. During installation, the credentials are stored in local cache. When service starts, it checks for this cache and if required reads and updates the secure store cache in ADAM.
 
10.    Start workflow job manager
Log: Server.Start: Starting workflow singleton
Creates objects of job management. Reads database and ADAM, schedules jobs that are required to be scheduled, and schedules a quick health and status job.
 
11.    Start the integration bridge
Log: Server.Start: Starting bridge manager subsystem
Loads the integration bridge manager. The sub system allows consumers of this system to load the Application Server service and also helps the users to call the IB APIs. The clients can be of Symantec workflow components and Powershell script.
 
12.    Triggers system jobs
Log: Server.Start: Running the system jobs
The following predefined jobs are triggered:
·         DPS Configuration push
·         Full Health and status
·         Custom role permissions sync
·         Automatic Live update installation job.
 
13.    Service started
Log: Server.Start: Finished starting Application Server
 
 Application server main components
 The main components of an Application server service startup are as follows:
·         Job management
·         License manager
·         Schedule management
Job management
The Job Manager executes the jobs in the Application Server. These jobs are implemented using the Windows Workflow Foundation and are in the form of .Net workflows. The Job management component reads these XOML and executes the workflow by loading appropriate binaries.
 
License manager
Licenses are stored in ADAM. The License manager does the following:
  • Monitor license metering
  • Check for license expiry
 
 Schedule management
The Application Server creates Job Manager and Schedule Job Manager Thread. The Job Manager is responsible for executing jobs and the Schedule Job Manager is responsible for scheduling jobs and calling the Job Manager to execute the scheduled jobs.
Communication between CCS components
The diagram demonstrates how different components in CCS communicate with each other. The focus is on how console, web console, web services communicates with ADAM and the Application Server.
 
CCS Console uses the WCF TCP/IP to connect to the Application Server. For faster reads, the CCS Console connects to ADAM directly authenticating the user by Application Server.
 
 
Figure 2: Communication between CCS components
 

Attachments