 |
|
DAILY NEWS AND INFORMATION
FOR THE GLOBAL GRID COMMUNITY / JUNE 9, 2003: VOL. 2 NO. 23
|
Special Features:
SMART NEIGHBORHOODS -- NEXT STEP
IN GRID SERVICES? PART II
By K.S.Venkatram, University Of Poona
Engineer
This article is the second in a series about "Defining a concept for a
Smart
Neighborhood". These articles are not a published solution. Rather, they
introduce the reader to a concept for a smarter neighborhood and guide the
user through a comparative analysis and extensibility of a sensor-controlled
network against what is ordinarily presented in Grid computing.
Understanding Sensor And Resource Tracking
1. Today solutions only work with the concept of pre-defined resource
definitions; in this support the sensor-controlled network does conceive
connection points that collaborate to deal with pre-defined and other
resources extensions. The sensor-controlled network supports spectrums or
mixed varieties of resources, as newer resources are added or existing
resources deleted, the Simple Model stores the resource definitions and their
status in a database and synchronizes this information to help any network
computer locate resources.
2. The concept proposed through the sensor-controlled network, relies on
storing and synchronizing resource information from various sensors. On
successful storage, the sensor-controlled network looks up these resource
definitions to query resource objects in the enterprise grid.
Understanding the sensor and the Simple Model:
1. Like regular databases, Enterprise Resource Databases will be installed
on
Enterprise Resource Servers. The Enterprise Resource Server (ERS) is an
Enterprise Location Server (ELS) that helps collect the list of resource
definitions from the various network computers and adds the same to an
Enterprise Resource Database.
2. Enterprise Resource Databases (ERDb) will host a set of tables to store
and
track information about various resources available in an enterprise grid. The
proposed ERS solution uses information publishing and information
synchronization services to guide, report and architect the mechanism of
locating resources irrespective of their location in the enterprise grid.
3. The Enterprise Resource Server (ERS) will store and synchronize resource
definitions across other Enterprise Resource Servers and Enterprise Resource
Databases. An Enterprise Resource Server will use a distribution service to
synchronize resource definitions, thus enabling tracking resources in an
enterprise grid with mixed platform support.
4. The schema for the Enterprise Resource Database (ERDb) is a Simple Model
to
store and report information of any resource on the network. To understand the
Simple model, the following guidelines are presented:
- In the ERS, all resources will have an Enterprise identifier.
- In the ERS, all resources will have a resource class. Commonly known
classes are Hardware class, or Software class, or Performance Indicator class
or Extension Resource class.
- In the ERS, all resources will have an Object-Collection identifier.
- In the ERS, an Object-Collection model will define resource class and the
various attributes associated with the class. All resources in the Object-
Collection model will have attributes like a resource identifier, a
description, value and units for the value.
- In the ERS, all resources will have attributes that track the resource on
the basis of the timestamps.
The variety of timestamps in the ERS are:
1. Timestamp when the resource was configured or described first in the
enterprise network.
2. Timestamp when the resource was tracked or accessed or updated in the
enterprise network.
3. Timestamp when the resource was deleted or exposed to lifecycle updates
in
the enterprise network.
- In the ERS, all resources will have attributes like lifetime signing and
criticality that determine the lifecycle of a resource in the enterprise
network.
- In the ERS, all the attributes will focus on manageability and
strategizing
focus for resource lifecycles in the enterprise network.
Understanding the sensor and resource services:
1. A sensor will support a unique connection point for each resource
service
or management agent on the network computer. Typically a network computer
could be installed with management agents such as a SNMP agent or a WMI agent
or a Directory agent. The sensor conceives a solution to describe resources,
by which there will be a connection point for each management agent on a
network computer i.e. in this example network computer there will be a
connection point for SNMP, there will be a connection point for WMI and a
connection point for the Directory agent. The sensor will report resources
available on this example network computer, by interfacing with the management
agents through these active connection points. The connection points use the
management agents to consolidate and describe the various resources on the
network computer.
For example an SNMP agent in today's support describes the resources in the
SNMP namespace with the SNMP mappings, a WMI agent in today's support
describes the resources in the Windows Management Instrumentation namespace
with the WMI mappings and a Directory agent in today's support describes
resources in the Directory namespace with the Directory mapping.
Enterprise Location System - Sensor Configuration for the WMI
sample...
<application>
<service>
<wellknown
<parameter name="mode" value="Singleton"/>
<parameter name="type" value="WMI"/>
<parameter name="lifetime" value="extension"/>
<parameter name="objectURI" value="Custom_WMI"/>
/>
<channel
<parameter name="ref" value=""/>
<parameter name="port" value=""/>
/>
<handler
<parameter name="arguments" value="contributor,contribution,response"/>
<parameter name="responsefile" value="WMI.int"/>
<parameter name="submit" value="Custom_WMI_Submit"/>
<parameter name="receive" value="Custom_WMI_Receive"/>
/>
<filesystem
<parameter name="schema" value="xml"/>
<parameter name="schemafile" value="WMI.scm"/>
<parameter name="resourcefile" value="WMI.xml"/>
<parameter name="rulesfile" value="WMI.rul"/>
<parameter name="contentdirectory" value="c:\\sensor\\content\\Custom_WMI"/>
<parameter name="cache" value="enabled"/>
/>
</service>
</application>
2. One side of the problem is using an existing management agent; the other
well-known problem is that, a change in the data model or a change in the
management agent interfaces does require new alignment. To ease the effort in
alignment and also satisfy the common network requirement, the ELS proposes a
mechanism that connects with each of these agents and enumerates their
resource descriptions. This sensor-controlled mechanism consolidates resource
descriptions using a data model algorithm and then updates them into the
Enterprise Resource Database (ERDb) on an Enterprise Resource Server
(ERS).
3. In any sensor-controlled framework an Enterprise Tracking Agent (ETA)
will
be installed on the network computer irrespective of the other management
agents. The Enterprise Tracking Agent will consolidate or collect the resource
descriptions from the various connection points and keep this cached for any
sensor query or response.
Understanding the implementation of the Enterprise Location System:
1. In the proposed Enterprise Location System, simple design specifications
direct the scope and guidelines recommended to implement the solution. The
design requires the implementation of specific functions, input and output
parameter formats and published op-codes for mixed grids and management
girds.
2. Unlike the focus in Grid computing, the proposal for the Enterprise
Location System has not finalized support for a toolkit, by design the
Enterprise Location System recommends interfaces and tracking service
installation through implementation of connection points. As different network
engineers and developers in the Grid community rate the concept, implementing
the design by large can conceive support in the same way as the Grid.
3. The proposal for the Enterprise Location System defines connection point
interfaces like the "Tracking_Submit" and "Tracking_Receive" functions that
must be implemented by any resource service extension integrated with the
sensor-controlled network. Invocation of the "Tracking_Submit" and
"Tracking_Receive" functions will be stringently verified for parameters and
op-codes. Parameters are passed to the "Tracking_Submit"and "Tracking_Receive"
functions by passing arguments in a formatted string such as
"contributor=", "contribution= ", "response= success or
failure or response file" The op-codes are required for the functions to
execute certain services in resource reporting and access
4. For readers interested in implementing resource service extensions, the
required support from op-codes will be made known and published as part of the
framework. This means that any reader interested in developing a resource
service extension will be supported with guidelines and published
specifications. The fundamental step would be to develop the extension and
implement the "Tracking_Submit" function and "Tracking_Receive" function with
the signature, formatted parameter interpretation and op-code support.
5. The Enterprise Tracking Agent (ETA) will have a class scope and the
resource service extensions will have a library or extension scope. Such class
or library scope is well known in today's development scenarios, the sensor-
controlled network makes it possible for any network user to direct the scope
of the resource management solution in the network.
Describing Grid Resource Services:
To quote from an existing article on Grid computing "In a computational
Grid,
information is a critical resource, and gathering this information is a vital
activity. The information services component of the Globus Toolkit, the
Monitoring and Discovery Service (MDS), gathers information about Grid
resources by means of the Grid Resource Information Service (GRIS) and the
Grid Index Information Service (GIIS)".
For readers familiar with Grid computing and solutions, I would like to
list
a
few benefits of MDS:
1. Access to static and dynamic information about system components.
2. Uniform, flexible access to information. Important support for services
to
report the current Status of the Grid:
- Services to report what resources are available.
- Services to report state of the computational Grid.
- Services to report applications and recommend optimizations based on the
configuration of the underlying system.
3. Access to multiple information sources
4. A basis for configuration and adaptation in heterogeneous, dynamic
environments
5. Decentralized maintenance
After focusing on the MDS, comparatively the benefits of the proposed
Enterprise Location System are:
1. Access to static and dynamic information about system components.
2. Uniform, flexible access to information
3. Access to multiple information sources
4. A basis for configuration and adaptation in heterogeneous, dynamic
environments
5. Decentralized maintenance
6. The reliability to report status of the Grid is reviewed in the
following
questions:
1. What resources are available? The Enterprise Resource Locator (ERL)
service is proposed in the Enterprise Location System. The sensors installed
on the various network computers use connection points to report the available
resource descriptions to an Enterprise Resource Server (ERS) and Enterprise
Resource Database (ERDb). The Enterprise Resource Database services use the
Enterprise Location System-Simple Model to store the resource definitions in
the database. These resource definitions are then available for any network
user or Administrator to enumerate and use in locating resources in the
enterprise network. In a common example, if the sensor installed on a network
computer does report "Win32_ComputerSystem.Win32_DiskDrive" resources, the
network user irrespective of platform support can locate "Win32_DiskDrive"
resources and the manageability supported through the Windows Manageability
and Instrumentation solution.
2. Whether newer resources can be located in the enterprise network? The
schema of the Enterprise Resource Database (ERDb) is not static or is not
expected to store well-known resources only. At this stage the reader needs to
understand that the schema is defined on the guidelines of a Simple Model. In
the Enterprise Location System, any resource available on a network computer
running any version of an operating system and resource services can be
tracked. The network user looks up existing resource definitions in an
Enterprise Resource Database (ERDb) and then sends out XML Locator queries to
the sensors in the enterprise. Sensors support preprocessing these XML Locator
queries and send results for the Administrator to follow up or enforce
management actions.
3. What is the state of the computational Grid? As the state of a
computational Grid or enterprise network is typically controlled by the
resources available, performance indicators and tracking support, the
Enterprise Location System designs a solution to monitor the state of the
enterprise network at any time.
4. How can applications be optimized based on the configuration of the
underlying system? The identification part of the question is answered, as
most management applications do not work in mixed networks. For any
Administrator, to manage mixed networks there are limitations imposed by the
underlying system. To address such limitations, the Enterprise Location System
does propose a mechanism to track resources in identifying usage or in
measuring performance or in knowing resources available in neighborhoods. The
optimization and configuration part of the question is answered, as the
sensor-controlled network does interface with Directories to support this
requirement. To optimize or configure specific resources on a network
computer, the first recommendation in the sensor-controlled network is to
update the supported Directory (LDAP-conformant Directory) with the
resource(s) available on the network computer. Once the resource definitions
are published in the Directory as Directory objects, the requirement is to
implement a policy based solution to manage these Directory objects. The
sensor could optionally create and publish policies for these Directory
objects. When the management service needs to optimize or guide resource
access or availability, it sends a XML Locator command with rules attached.
The rule is either the policy name to be read from the directory or the XML
format configuration. The sensor on preprocessing the XML Locator command will
extend its role to support performance measurement and optimization if the
resource service provider supports functions to init, reset, shut down or
control operations. This feature is classified as critical monitoring services
in the Enterprise Location System. Details will be presented in ensuing
articles.
-- K.S.Venkatram is a computer engineer from the University Of Poona.
|