Sensor

1
R-GMA Relational Grid Monitoring Architecture
An information and monitoring system for static
and dynamic information about grid resources,
applications, networks
R-GMA
Implementation
When a user creates a consumer or producer, a
corresponding instance is created remotely on the
server. This handles all the communication with
other R-GMA components (producers, registry etc.)
so the client code can be simple and lightweight.
The client API uses HTTP GET/POST to send
requests to the servers the response is in the
form of an XML string, which contains returned
data (e.g. a set of tuples) or an error.
The Relational Grid Monitoring Architecture
(R-GMA) is being developed as a generic
information and monitoring system as part of the
EGEE project. It offers powerful capabilities
for monitoring in a distributed environment.
Producer Service
1. declare table
Registry Service
Schema Service
3. transfer data
server
server
RegistryService
Registry Service (proxy)
Consumer Service
2. locate producers
R-GMA provides a framework to publish and
retrieve information using a producer/consumer
model defined by the GMA standard from the OGF.
In this model, applications publish data using a
producer a consumer is used to retrieve the
data. Properties defining the producer are stored
within a registry so that when a consumer is
created, it can query the registry to find
producers that satisfy its search criteria. Once
a list of producers is found, data then flows
directly from the producer to the consumer. The
schema holds a list of table definitions.
Sensor
PrimaryProducerService


Primary Producer API
Primary Producer Instance
ConsumerService

Consumer Instance
Application code
Consumer API
Virtual Database
Sensor
server
PrimaryProducerService

From a user's perspective, an R-GMA installation
appears as a single virtual database (VDB). The
scope of an R-GMA VDB is defined by its schema
and registry. Users can define their own tables
and operational authorization for them on a per
VDB basis. Currently, producers and consumers
can only interact with a single VDB. Since
creating multiple VDBs is a natural way to create
different name spaces this limitation will soon
be removed.
Primary Producer API

Primary Producer Instance
control data
Registry Replication
Typically one server is deployed per site. The
implementation is such that the loss of any
control message between servers can be tolerated.
For a VDB more than one registry can be deployed
to provide fault tolerance and increased
performance. In fact there is a registry service
on each server, although the service may not
necessarily host the data but instead act as a
proxy and forward the messages. Having more than
one copy of the registration data requires a
mechanism to keep the registries synchronized.
Soft State Registration
An instance is created and destroyed at the
explicit request of the user, but in order to
protect itself from an accumulation of redundant
instances, R-GMA makes use of a termination
interval.
Producer A
Producer B
Service aware of API during terminationInterval
duration
Existence of service instances in Registry up to
terminationTime
Registry 1
Registry 2
Info mastered by Registry 1
Info mastered by Registry 2
Sensor
Copy of info from Registry 2
Copy of info from Registry 1
PrimaryProducerService
RegistryService
Primary Producer Instance
Producer Registration
Primary Producer API
Each registry is responsible for pushing its
local data to other registries. Registry 1
ensures Registry 2 has a copy of all information
it masters (and vice versa).
If the service doesn't hear from the user for any
period exceeding the termination interval, the
instance is destroyed. This is the concept of
soft-state registration. It puts the onus on the
user to keep the instance alive, by making
periodic contact with the service. The registry
protects itself in the same way against producers
and consumers which register then disappear, so a
periodic keep-registered message has also to be
sent to the registry, by the consumer and
producer services.
Schema Replication
The schema differs from the registry in that over
99 of calls are lookups as opposed to about 50
on the registry. Therefore a different
replication model has been used. For a VDB
there is one master schema and many slaves. Each
server that supports the VDB will have a slave
that will periodically poll the master for
updates. As there will always be a local copy of
the schema, lookups will be fast and there will
be protection from wide area network problems. In
the event of the update of the schema via a
slave, the master must be updated in order for
the operation to succeed. With an average update
frequency of once a month over the lifetime of
EGEE, the risk of the master being un-contactable
for updates is considered acceptable.
http//www.r-gma.org/