csc feature note download

Confidential Version 1.0

Common Services Centre

CSC On Line Monitoring

(Technology Solution)

July 2009

Infrastructure Leasing & Financial Services Limited

Effectively Monitoring CSCs

Confidential-Feature Note

Table of Contents

1 Background ______________________________________________________________ 3

1.1 Vision for CSCs ________________________________________________________ 4

2 Monitoring Requirements and Challenges _____________________________________ 5

2.1 Technology Challenges___________________________________________________ 5

2.2 Key Monitoring Parameters and Solution ____________________________________ 7

3 High level solution architecture: _____________________________________________ 9

3.1 Uptime Monitoring Solution_______________________________________________ 9

4 IT Architecture and Cost Summary __________________________________________ 14

4.1 IT Architecture________________________________________________________ 14

5 Glossary ________________________________________________________________ 15



1 Background

The objective of this document is to discuss an approach to effectively monitor the

CSCs using IT tools under various SCA-CSC connectivity scenarios. This document

provides business requirements, IT architecture, and estimate of project cost for ICT

infrastructure and software development and its implementation.

Prior to this note, IL&FS had discussed the solution with senior members of the CSC

project at DIT and also evinced interest amongst vendors to provide Proof of

Concept (POC) for such solution.

On the basis of a conceptual framework discussed, we have received proposals from

software vendors to help develop a customized solution of this tool.

This report discusses:

(a) Conceptual framework of solution to monitor CSCs

(b) ICT Architecture

(c) Opex / Capex Estimates

(d) Software vendor selection

(e) Areas where we need DIT’s concurrence to kick start the project



1.1 Vision for CSCs

The Vision for CSC is to make the various digital services accessible to the

common man in his rural locality, throughout his life through an integrated

service delivery platform thereby ensuring efficiency, transparency and

reliability at affordable costs to meet his basic needs.

CSCs would form the front-end for the citizens to access all the possible G2C

and B2C services, information and other localized services, which may be

needed by the local community.

With advances in the Information and communication technologies (ICT), it is

possible to provide whole range of high-quality and cost-effective services

relating to video, voice and data through single communication channel using

appropriate terminal equipment. This has opened up a whole new stream of

opportunity to provision for e-Governance and B2C services such as

entertainment, education, telemedicine, e-commerce, info-services etc.

A large scale roll-out of this scale would warrant use of advanced tools to

monitor the uptime of CSC delivery channels and ensure service outages are

minimum.



2 Monitoring Requirements and Challenges

For such a large-scale roll out, it would be important to ensure that the proposed

services are made available to the citizens and all the CSCs are operational as

intended. The States would like to prescribe appropriate SLAs of availability and

service delivery for the services to be delivered through CSCs. DIT would also be

keen to regularly review the entire server delivery mechanism. The important

requirements hence would be that CSC ICT services should be available and the

citizens should be able to use the CSCs during the designated hours of operation.

Application of technology tools and options for monitoring this requirement using

technologies would add credibility and facilitate successful monitoring of the scheme

with such a vast spread across the country. It is important to examine the various

technology challenges and options available for on-line monitoring of CSCs.

One of the primary expectations from CSC’s would be that IT environment is

available to end users and Internet access is available to provide various on-line

services.

Monitoring of CSC on the above lines would require monitoring two independent

sources of information:

1) The uptime of IT terminals at each CSC

2) Monitoring network uptime at each of the CSCs

This note analyses this requirement and solution in more details hereinafter:

2.1 Technology Challenges

The SCA-CSC IT environment would vary across SCAs and across States.

Each SCA-CSC unit could implement a different architecture under the overall

IT specifications prescribed. A large-scale roll out across the country may not

provide one standard enterprise grade architecture. The available, standard

off-the-shelf Enterprise Management Solutions hence would not be able to

meet the needs for the CSC monitoring.



It is important to highlight the hybrid environment under which the CSCs

would operate:

(a) The end devices at CSCs i.e. the PC/Kiosk/Client could run Windows

or Linux variants. The variants could include Windows 2000 and

above i.e. XP, Vista (Win95 and Win98 are omitted due to product

and service not available from Microsoft) and for Linux could be

Redhat, Ubuntu , Fedora Core 4 (FC4) or SUSE (there are many of

these around)

(b) Each CSC may opt for varying modes of networking for accessing the

Internet bandwidth:

i) Some SCAs may set up intranet and provide internet backhaul

using centralised SCA

ii) The SCA may provision Internet directly at the end point CSC

iii) CSC route would choose connectivity and be readily available -

wireless – Wifi /Wimax / RF / VSAT: Wired –

DSL/Cable/Ethernet/Dial/VPN

iv) Internet access to CSCs could be provided by different ISPs,

depending on which service provider has better footprints and

approve offerings in the respective areas

v) In an environment like the above, static IP address to an end

CSC may not be always available, though it is highly desirable

vi) No Permanent Internet connection. Some CSCs would face this

challenge and may resort to dial-up

(c) CSCs being in rural areas where apart from the telecom challenges

there are other challenges like power availability and environmental

(e.g. operating in areas easily affected by rain, floods etc.) put

constraints on the network component being always on



(d) CSCs system would be using IT Platforms based on Intel / AMD

architecture

(e) SCA across the centre may not be amenable to implement a Standard

Enterprise Monitoring solutions for monitoring SCA-CSC channels,

owing to the above constraints

2.2 Key Monitoring Parameters and Solution

Having regard to the hybrid environment for the uptime monitoring of CSCs

needs to be custom-built. Key features of this system are as below:

• The CSC monitoring system for an all India roll out needs to be a

centralized system to ease the collection and dissemination of

information

• All the stakeholders would have a view to the uptime information

• All the CSC computers should run a Micro CSC agent, which would

feed the information to the Centralized Aggregation Point (to a pool of

central servers).

• Each CSC machine would connect once to a centralized Monitoring

Hub to download this tool and to obtain a unique authentication key

• The micro agent would generate and store Logs such as Switch

on/Switch off data and would be very thin agent with bare bones

information

• CSCs would connect to the central Hub using internet connectivity

• Micro agent communicator should update information at periodic

intervals which should then monitor against set parameters / SLAs

• The centralized system should monitor SLA violation raise a ticket

against specific SCA

• Various stakeholders would have access to various reports published

by the Central Hub

• This system would require very minimal bandwidth and would be

automated



Design Considerations:

In order to design and develop such a sophisticated tool, it is important to

identify certain design considerations:

(a) The proposed solution would not require any specific skills from the

CSC admin or from the personnel administering the end PCs

(b) This system would have a built-in mechanism to self start by

automating one time agent installation work

(c) Micro agent would be installed as a system service and hence starting

the agent when the machine is started should be taken care by the

agent installation procedures and should not require any manual

intervention from the administrator

(d) The collected CSC uptime data can be viewed in a easily

understandable format in the web interface

(e) The micro agent would not result in any form of overhead on the

system or bandwidth

(f) The bandwidth requests of polling logs from CSC to a central server

should be very low, so as to have a minimal impact on CSC

(g) The system would work on a auto scheduler or a watchdog timer

mechanism by virtue of which the data is ported from CSCs terminal

to a central server

(h) The uptime monitoring tool would not need any static IP address, but,

should have some form of authentication in the form of a mail

address and key embedded on the client machine during the

registration process

(i) The frequency of data polling would be configurable and should not

lead to any bottleneck at the central server

(j) All CSCs should communicate with the central server using only the

Internet

(k) The micro agent would support all the constraints of a hybrid

environment as listed above



3 High level solution architecture:

Based on the monitoring requirements the monitoring tools would be used, which

would allow enforcement of the defined policies, and monitoring and complying with

the Service Levels. This section analyses the requirement of different types of tools

for on-line monitoring.

Sr. No. Business Requirement Tool/Technology

1 Monitor uptime of IT terminal at each

CSC under all constraints listed above

Using a micro-monitoring

agent under Windows /

Linux environment

3.1 Uptime Monitoring Solution

Requirement:

It would be pertinent to monitor the availability of the IT terminals (PCs) by

installing a micro agent in each of the IT terminals



System Architecture

The proposed solution for the CSC Monitoring System is based on a Central

Server – Agent architecture

(a) Central Server:

Central Server should be deployed in the Central data center. Central server

should have Web and data base component. These three components

should be deployed in the central data center in a manner to minimize the

processing load on the systems. The central server should have two Web

servers. One of the web servers should perform the job of receiving and

processing the data given by the agent (running on the CSC) and the other

Web Server should be used to publish the collected data in the Web User

Interface. There would be load balancers to balance the load from several

concurrent nodes

CSC-1

```

ServiceLevel

Manager

ServiceDesk

CSC Agent

Communicator

Centralised CSC Monitoring Hub

Self Monitoring

B2CApplications

G2CApplications

CSC-3CSC-2

Internet

CSC MICRO AGENT – Machine Logs



(b) Micro Agent:

The Micro Agent is a piece of software that would be deployed in each of the

CSCs. The Agent would start as a system service (with no option of disabling

it) while booting the device at the CSC.

Key features and prerequisite steps for operationlising this agent are listed

hereinafter:

• The micro agent would be active as soon as the PC is booted up

• Tempering of this agent will stop the functions of agent and logs will

not be sent to the Central location. This would then be monitored

through exception handling process

• The logged data would be encrypted. The decryption of the logged

data would be permitted only at the Central location

• The Log size generated by the Micro agent and the overhead on the

Client terminal would remain at the bare minimum. This is necessary

to ensure that performance of the CSC terminal; the network and the

central location

• The micro agent would report the uptime data to the central server at

pre-determined intervals. Central server would receive the data

uploaded by the agent and persist in the database for report

generation and to display the collected information in the Web

Interface

• For logs upload the Internet connectivity at the CSC is a must. The

communication between the agent and the central server would be

secured. It is advisable to have one-way communication from agent

to central server to avoid load on the central server



• It would be mandatory to have all the PCs operating from the CSCs to

have registered once with the central server. The registration would

be a simple on line process and the successful registration would

enable the CSC to download this agent. Further, the first time

software distribution could also happen through distribution of

physical CDs or sending software to SCAs for dissemination to the

end CSC terminals, if they have setup an Intranet environment

• The onus of installation and keeping the micro agent active at CSCs

should rest with the SCAS and this could be prescribed under MSA

(c) Reporting Startup/Shutdown time:

Once the agent is installed on the CSC computers, whenever it is booted,

agent should self-start and record the time to the central server. Similarly

when the computer is shutdown, the agent should record the shutdown time

and report to the central server. There may be other special events like

screensaver, locking of the computer or hibernation which needs to be

recorded / reported

(d) Privilege based segmented view:

Central server administrator logging into the ILFS CSC Monitoring System

should be able to view the details about all the CSCs monitored by the

system through the Web based interface. Similarly, the central server

administrator should create user account for the CSCs through the web

interface. User with SCA privilege can view the details about the uptime of

the end PCs pertaining to the corresponding SCA. In a similar way, CSC

accounts can also be created with which the CSC user can view the uptime

data of the PCs pertaining to this CSC.

(e) Reports:

Using the web interface, reports should be generated with the data collected

and analysed by the Central Server from the agents deployed in the CSC.

Reports capturing the list of CSCs from which start uptime / shutdown time is

not received for the past XX days could be useful to the CSC Monitoring



System administrator. Options to export the report data to CSV/PDF should

be provided.

The system would be useful for DIT, NLSA, SDAs (States), SCAs and CSCs.

User log-in would be role based for e.g. SCAs should be able to review

performance of CSCs under their direct control.

The key reports that would help monitoring uptime performance includes:

• Information on CSCs meeting the uptime requirements during a range

of dates within a Block, District, State and SCA

• Uptime Performance of CSCs within a Block, District, State and SCA

• Exceptional occurrences and Trouble tickets for CSCs under a SCA or

state for corrective action

• Uptime Performance on an All India basis by States, By SCAs

• Inter State and Inter SCA performance comparison on uptime

(f) Exception Handling:

If the CSC Monitoring System does not receive the uptime data from a

particular CSC/PC, or fails to meet required SCAs, it should generate an

email notification to the configured administrator. Most of the existing

trouble ticketing helpdesk system can receive email notifications and

generate tickets. Hence, in addition to notifying the administrator through

email, the CSC Monitoring System should generate email and log a ticket in

the trouble ticketing system.

The trouble ticketing are exception reports for action. These reports would be

sent to the concerned state authorities, SCAs. for corrective action. For e.g. a

trouble ticket would be raised if a CSC were reported down for 3 consecutive

days in a week. A mail alert would be sent to SCA and States.



4 IT Architecture and Cost Summary

4.1 IT Architecture

An high level IT Architecture of the solution discussed in Section 3 is depicted

in the exhibit below, The budgetary estimates of infrastructure cost is provided

later in this section:

INTERNET CLOUD

TotalStorageDS4300

Internet Routers

Perimeter Firewall

DATABASE SERVERS

CSC 2

CSC “n”

Mail GatewayWeb Server

DMZ

Application Mailbox ServerManagement

INTRANET SERVERSSTORAGE AREA NETWORK

MGMT. NETWORK

CSC 1

Internet link from ISP 1

Internet link from ISP 2

IT ARCHITECTURE FOR CSC MONITORING

CENTRAL MONITORING INFRASTRUCTURE



5 Glossary

AMC - Annual Maintenance Contract BOD - Beginning of day CSC – Common Services Centre

DIT - Department of IT, Govt. of India

EMS - Enterprise Management System

GIS - Geographical information system

HA - High availability

ICT – Information & Communication Technologies

IP - Internet Protocol

ISP - Internet Service Provider

LDAP – Lightweight Directory Access Protocol

MMP - Mission Mode Project

MSA - Master service agreement

NeGP - National e-Governance Plan

NDC – National Data Centre

NLSA – National Level Service Agency

NMS - Network Management Solution

POC - Proof of Concept

RAID - Redundant array of inexpensive disks

RPO - Recovery point objective- is the maximum allowable data loss

RTO - Recovery Time objective -Maximum time by which a system must be

returned to operation

SCA – Service Centre Agency

SLA – Service Level Agreement

SDC – State Data Centre

SDA - State Development Agency

SWAN – State Wide Area Network

TSP - Telecom Serv ice Provider

VLE – Village Level Entrepreneur

csc feature note download

Documents

uptime monitoring solution

monitoring requirements

b2c services

costeffective services

localized services

customized solution

common services centre

csc project