Académique Documents
Professionnel Documents
Culture Documents
Confidential
Version 1.0
Table of Contents
1
Background ______________________________________________________________ 3
1.1
2.2
IT Architecture ________________________________________________________ 14
Glossary ________________________________________________________________ 15
Confidential-Feature Note
Page 2
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 docume nt
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.
(a)
(b)
ICT Architecture
(c)
(d)
(e)
Confidential-Feature Note
Page 3
1.1
to
provision
for
e-Governance
and
B2C
services
such
as
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.
Confidential-Feature Note
Page 4
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 CSCs 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)
2)
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.
Confidential-Feature Note
Page 5
(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)
ii)
The SCA may provision Internet directly at the end point CSC
iii)
Wifi
/Wimax
RF
VSAT:
Wired
DSL/Cable/Ethernet/Dial/VPN
iv)
v)
vi)
(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
Confidential-Feature Note
Page 6
(d)
(e)
2.2
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 CSC computers should run a Micro CSC agent, which would
feed the information to the Centralized Aggregation Point (to a pool of
central servers).
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
Confidential-Feature Note
Page 7
(a)
The proposed solution would not require any specific skills from the
CSC admin or from the personnel administering the end PCs
(b)
(c)
(d)
The
collected
CSC
uptime
data
can
be
viewed
in
easily
The micro agent would not result in any form of overhead on the
system or bandwidth
(f)
(g)
(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)
(j)
All CSCs should communicate with the central server using only the
Internet
(k)
Confidential-Feature Note
Page 8
Sr. No.
3.1
Business Requirement
Monitor uptime of IT terminal at each
CSC under all constraints listed above
Tool/Technology
Using
micro- monitoring
agent
under
Windows
Linux environment
Confidential-Feature Note
Page 9
System Architecture
B2C
Applications
G2C
Applications
Service
Level
Manager
CSC
Agent
Communicator
Internet
Service
Desk
M
Sel f
`
CSC-2
CSC-1
ri ng
onit o
CSC-3
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.
One of the web servers should perform the job of receiving and
concurrent nodes
Confidential-Feature Note
Page 10
(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:
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 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.
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
Confidential-Feature Note
Page 11
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
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)
(d)
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
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
Confidential-Feature Note
Page 12
The key reports that would help monitoring uptime performance includes:
(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.
trouble
ticketing
generate tickets.
helpdesk
system
can
receive
notifications
and
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.
Confidential-Feature Note
Page 13
IT Architecture
DMZ
Internet link
from ISP 1
CSC 1
Internet
Routers
Web Server
INTERNET
CLOUD
CSC 2
Mail Gateway
Internet link
from ISP 2
MGMT. NETWORK
CSC n
Perimeter
Firewall
INTRANET SERVERS
STORAGE AREA NETWORK
DS4300
DATABASE SERVERS
TotalStorage
Confidential-Feature Note
Page 14
Glossary
AMC
BOD
Beginning of day
CSC
DIT
EMS
GIS
HA
High availability
ICT
IP
Internet Protocol
ISP
LDAP
MMP
MSA
NeGP
NDC
NLSA
NMS
POC
Proof of Concept
RAID
RPO
RTO
SCA
SLA
SDC
SDA
SWAN
TSP
VLE
Confidential-Feature Note
Page 15