CSC Feature Note Download
-
Upload
information-point-kapurthala -
Category
Documents
-
view
21 -
download
0
description
Transcript of 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 Page 2
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
Effectively Monitoring CSCs
Confidential-Feature Note Page 3
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
Effectively Monitoring CSCs
Confidential-Feature Note Page 4
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.
Effectively Monitoring CSCs
Confidential-Feature Note Page 5
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.
Effectively Monitoring CSCs
Confidential-Feature Note Page 6
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
Effectively Monitoring CSCs
Confidential-Feature Note Page 7
(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
Effectively Monitoring CSCs
Confidential-Feature Note Page 8
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
Effectively Monitoring CSCs
Confidential-Feature Note Page 9
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
Effectively Monitoring CSCs
Confidential-Feature Note Page 10
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
Effectively Monitoring CSCs
Confidential-Feature Note Page 11
(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
Effectively Monitoring CSCs
Confidential-Feature Note Page 12
• 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
Effectively Monitoring CSCs
Confidential-Feature Note Page 13
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.
Effectively Monitoring CSCs
Confidential-Feature Note Page 14
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
Effectively Monitoring CSCs
Confidential-Feature Note Page 15
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