 |
|
DAILY NEWS AND INFORMATION
FOR THE GLOBAL GRID COMMUNITY / JUNE 23, 2003: VOL. 2 NO. 25
|
Special Features:
DEFINING A CONCEPT FOR A SMART
NEIGHBORHOOD - PART IV
by K.S.Venkatram, computer engineer, University Of
Poona
This article is the closure on the 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 in enterprise scenarios.
Introduction:
The proposal for the Enterprise Location System (ELS) is also described as a
proposal for a "sensor-controlled network (SensorCN)" or a "sensor-controlled
enterprise (SensorCE)". The design context and specification of the sensor-
controlled network is based on Location Entities and also support from
extensible sensor-controlled services.
The enterprise network resources are typically hardware, software
applications, performance measurement objects and network manageability
objects in the enterprise network or grid.
The enterprise network is a consolidation of mixed network computers, mixed
network resources and mixed network services. In this mixed grid, the
Enterprise Location will be a network address or DNS or network name for a
network computer or server participating in resource tracking. The Enterprise
Location will be identified with the help of sensors, resource tracking and
access.
The Enterprise Location Protocol defines the network transport and service in
querying resource availability in the enterprise grid.
The Enterprise Location Server (ELS) will be a management server that
participates in the Enterprise Location System.
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.
The Enterprise Resource LDAP Server (ELRS) is an Enterprise Location Server
(ELS) that helps collect the LDAP resource definitions from the various
network computers and adds the same to an LDAP Directory.
To introduce the reader to "Location entities" - Location entities are the
network computers in the network that are installed with sensors. The Location
entities are classified as One-way or Two-way systems.
Sensors are qualifying agents in the Enterprise Location System that are
placed on the Location entities classified as One-way or Two-way systems. A
Sensor qualifies a single Location entity for a resource query or qualifies a
set of Location entities for a resource query.
+ One-way systems are Location entities running sensors; the resources are
tracked by queries sent from the network user or Administrator's machine to
the sensors. The network user does either configure the sensors to be queried
or relies on querying one sensor which conferences pools of sensors.
When querying a sensor that conferences various related sensors, the network
user or Administrator does not expect to know which related sensors service
the request and respond. So the sensor-control is single or multi-purpose for
querying resources.
+ Two-way systems are unlike One-way systems, these sensors are One-way
systems and additionally connect into the network and play the role of
transmitting messages independently to the network user or Administrator's
machine. The Two-way sensors also enhance the location system by forwarding or
retrieving the information from other Location entities and have some
association in criticality or resource definitions.
The Enterprise Location Service Catalog (ELSC) is a contextual infrastructure
that designs manageability of the smart neighborhood through a Directory or
Database Map and synchronizes this service information across the sensor-
controlled network. The management information from the sensor-controlled
network computer will be stored, modelled through a "Database or Directory
map, this map is also termed as a Service Catalog. The Database Service
Catalog or schema model will be supported by ELS-ERS infrastructure. The
Directory Service Catalog or schema model will be supported by the ELS-ELRS
infrastructure.
Article:
This article does consolidate the introduction and description of the
enterprise infrastructure presented in the series, and concludes by
conventionally describing how easy it is to make interoperability and
enterprise services a core solution.
Performance Monitor Scenarios for ISPs - Interoperability and Enterprise
Services
Some companies may adopt the decision to own enterprise support or may decide
to purchase solutions from the market to interoperate in the enterprise. It is
known that most outsourced solutions will not address the management of
platform specific or domain specific entities and additionally will not
effectively address resource management on that platform. In time-effort
roadmaps, deciding on a model is critical to support service extenders and
resource management applications. This decision or design limitation can
easily be addressed by conceiving an enterprise infrastructure and then
investing in Data Center solutions or Application Center solutions.
For Windows developers and network users the PerfMon is a Performance Monitor
Tool included with Windows 2000 Server/Windows 2003 Server. The Performance
Monitor Tool is dependent on the monitoring services provided along with the
Windows operating system, the information and the tool do not deal with the
mixed network dependencies. If we were to preview well known performance
processes and control the scope such that the management information is
available in a grid environment, we conceive a neighborhood that is grid
available and interoperable.
Typical usage of the PerfMon and the Smart Neighborhood
1. Run PerfMon on its own server. This article does not present an
understanding of the PerfMon Tool and description of it's usage, but evaluates
sample results to conceive an extendable design.
2. In this usage of the PerfMon, use comma-separated value (CSV) files to
record PerfMon data. In the Performance Monitor Tool user options click Log
file type drop-down box, choose Text File (Comma delimited). Click Configure
to open the Configure Log File dialog box and specify the
PerfMon_ConnectionPointService file name.
Performance data stored in databases or enterprise directories make it
possible for any network user to administer the processes in an interoperable
neigborhood. Such interoperable neighborhoods can be planned by a sensor-
controlled enterprise.
3. Installing and configuring this neighborhood, does mean recommending the
various management servers that are to be supported. The PerfMon usage through
the Smart Neighborhood could be configured using the listed recommendations:
i. We would need to install and configure an Enterprise Location Server (ELS)
as the PerfMon management information and service data need to be monitored on
a sensor basis. The ELS is a management server that participates in the
Enterprise Location System. An Enterprise Location Server will support
registration, discovery and monitoring of sensors in the enterprise grid.
Sensor location, registration, access information will be stored and
synchronized through a database called the Sensor Resource Database. The
Enterprise Location Server is a configurable entity that controls sensor
signaling and collaboration in the enterprise grid, the network dependencies
decide whether the sensor network configuration should be "stored and
synchronized" across the network or whether the sensor network configuration
should be "stored on a lookup from this server" basis only.
ii. We would need to install and configure an Enterprise Resource Server
(ERS). The 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. The Enterprise Resource Database
model will be that of a relational database with tables, stored procedures,
and database support to host information about mixed resources in an
enterprise network or grid.
We could choose to install and configure the Location Domain Support for the
ERS-ELS. Like typical network support and relationships built through domains,
the Enterprise Location System also defines enterprise support and resource
neighborhoods through the Enterprise Location Domain. The Enterprise Location
Domain implementation registers sensors, pooled sensors and services with a
Location Server like the Enterprise Resource Server (ERS) or Enterprise
Resource Server + Enterprise Location Domain support (ERS-ELD) or Enterprise
Location Server (ELS). Grid associations built on the Enterprise Location
Domain concept enhance the searching, tracking and support functionality in
the sensor-controlled network. This is recommended if we decide that the
PerfMon management information is to be associated with a smart neighborhood
namespace and not in common association with a DNS namespace related model.
iii. If we wish the PerfMon information is to be available through the
enterprise directory we could choose to install and configure the Enterprise
Resource LDAP Server (ELRS). The ELRS is an Enterprise Location Server (ELS)
that helps collect the LDAP resource definitions from the various network
computers and adds the same to an LDAP Directory. The Enterprise Location
System uses the ELRS for publishing resources in a LDAP Directory. The LDAP-
based resource model will describe the resources using the LDAP schema.
Like the ERS-ELS, the Enterprise Location Domain associates a DNS name or
domain name with the LDAP support (ELRS-ELD). Many Grid associations today
need this DNS namespace integration for searching, tracking and support
functionality in the network. Along with the LDAP directory naming and
indexing, the ELRS-ELD feature will build a DNS like Enterprise Location
directory that will be maintained on the ELRS and through notification support
synchronized across the network's ELRS installations.
We start by installing the ERS-ELS-ELRS management server solution on a
Windows 2000 Server or Windows 2003 Server. As presented in previously
published articles we configure the management servers so the ERS-ELS-ELRS is
a simpler deployment where we could register the sensor in the ERS or the ELRS
itself. This means that the management server provides a colloborated support
to register, discover and monitor sensors and store, publish and synchronize
resource definitions across the mixed grid. On deciding the interoperability
with the mixed grid, the network user could search for the PerfMon data
support and results on a real time basis. The real time search will be guided
by the synchronization controlled by the ERS-ELRS, when the network user
confirms that the real time feature is a requirement for a sensor enumerated
PerfMon counter, the Enterprise Location Protocol supports mechanisms for the
network user to send out locator queries to the sensors whose network
configuration could be read from the Sensor Resource Database.
Like any network, the sensor support and sychronization across the mixed grid
is not static. We could have new network computers registering sensor support
in any time plan option. This means that storing sensor network configuration
and leveraging the same from the Sensor Resource Database is recommended, if
this option is not chosen or well planned to leverage sensor support, the
network user could conference neighborhoods. Conferencing neighborhoods could
be effective using the DNS namespace role or sensor signal. Sensors could be
installed on the network computer to initialize configuration, enumerate
connection points and signal location to a well known network computer in the
mixed grid. This well known network computer is any Enterprise Location Server
with notification services only. The notification server provides for
scenarios that connect with not so well scoped networks where registration of
sensors is not an option.
Planning the PerMon_ConnectionPointService development:
The development of the connection point service will need to know the format
of data in the PerfMon Comma Separated Value file and map the same to a XML
format. This mapping is integral to the administration capability supported by
the sensor-controlled network.
iv. We install the sensor on the machine, we plan to monitor by running the
PerfMon Tool. The network solution does require a
PerfMon_ConnectionPointService to be deployed along with the sensor. The
sensor will enumerate the PerfMon_ConnectionPointService and query the PerfMon
data readings from a a comma-separated value file. As the connection point and
ERS-ELS-ELRS model data in resolving enterprise investments, the CSV data
will need to be enumerated in the XML resource format-schema definition. This
new step will present the PerfMon data in a context that is interoperable
content and well scoped for the Enterprise Location System.
v. The sensor will invoke the Tracking_Submit function with the op-code "read
resources". When this is successful, the ETA will check the availability of
resource definitions. On enumerating the various connection points and
checking for the resulting resource definitions, the sensor follows these
principles:
+ For each resource connection point with "resources defined" initialization
results, the Tracking_Submit request will invoke the
PerfMon_ConnectionPointService_Submit with the "read resources" op-code. On
being invoked with the op-code "read resources", the
PerfMon_ConnectionPointService_Submit extension will link the PerfMon.xml
results file with the Tracking_Submit function. The Tracking_Submit function
will use this PerfMon.xml results file for location manageability by placing
it in the content directory. In the article the content directory for the
Enterprise Tracking Agent is "network computer
location:\\sensor\\content\\PerfMon_ConnectionPointService".
+ When the Tracking_Submit function preprocesses the resource xml file, the
results will be validated for success in parsing. If the results cannot be
processed by simple parsing techniques, the algorithm will process the content
of the results xml file by invoking the PerfMon_ConnectionPointService_Submit
function with the op-code "read schema". When the invocation of the
PerfMon_ConnectionPointService_Submit function returns references to the
schema file, the ETA will place the resource schema file in the content
directory. If no schema is available, then the Tracking_Submit function will
place the PerfMon.xml file with a PerfMon_ConnnectionPointService.blob file in
the content directory. This PerfMon_ConnectionPointService.blob file will be
processed without interpretation and stored in the Enterprise Resource
Database for binary lookup or application results.
+ When the ETA calls the PerfMon_ConnectionPointService_Submit function, if
the resource definitions are available then the ETA will add the results xml
file and available xml schema file to it's collection of enterprise content in
the content directory. In the example this connection directory is "network
computer location:\\sensor\\content\\connections".
+ When the connection points have all been read for the resource definitions
then the Tracking_Submit function will invoke it's resource definition update
algorithm. The resource definitions will be transmitted to the ERS for parsing
and database storage. The sensor implementation will propose to address
success or failure of all transmissions to the ERS. The ERS will use available
schema .scm files to construct a parser. For any resource xml, the ERS
executes a parser, if parsing is successful the resource xml will be stored in
the resource class information, else if parsing is a failure, then the
resource-blob files will be stored in the resource class information.
+ The resource xml files define a namespace attribute for resource class
definitions and include information for integrating domain information with
the network name of the network computer installed with the sensor.
+ When the resource definitions and corresponding .xml file definitions are
parsed and successfully updated into the ERS-ERDb, the ETA will place the
resource .xml files into a content directory for monitoring successful
updates. In our example the content directory for successful updates is
"network computer location:\\sensor\\content\\succcesful". Additional support
for monitoring the resource .xml files is accommodated by prefixing the ERS
name in the name of the results xml file.
Sample Windows Enterprise Resource Server configuration:
<resource>
<ip address>203.200.15.170</ip address>
<resourceserver>
<parameter name="hostname" value="RESOURCE_DOMAIN_WINDOWS"/>
<parameter name="domainclass" value="Server"/>
<parameter name="schemaclass" value="ServerSchemaMaster"/>
<parameter name="schemamaster" value="RESOURCE_DOMAIN_WINDOWS"/>
<wellknown
<parameter name="type" value="Windows2000.version"/>
<parameter name="lifetime" value=""/>
/>
<wellknown
<parameter name="type" value="Windows2003.version"/>
<parameter name="lifetime" value=""/>
/>
</resourceserver>
</resource>
In the illustrated example the PerfMon.xml will become
RESOURCE_DOMAIN_WINDOWS_PerfMon.xml.
By design if the resource definitions and .xml files are not updated due to
errors, the ETA will place the .xml file into a content directory for error
updates. In our example the content directory for error updates will be
"network computer location:\\sensor\\content\\error". To support monitoring
functionality, the sensor will also prefix the error xml file by the ERS name,
a file name like PerfMon_Error.xml will become
RESOURCE_DOMAIN_WINDOWS_PerfMon_Error.xml
+ When the sensor has completed execution of the Tracking_Submit function, the
sensor will now set state to respond to locators or queries. This sensor is
now capable of responding to Locator requests and Enterprise requests for
information.
How to Set Up PerfMon Logging de the Enterprise Location System
The network user will need to create an account to execute the PerfMon service
in the Enterprise Location System domain. The network user in the Enterprise
Location System will not need to use this account for the enterprise rights
and access. The Enterprise Location System does support security in
programming the network computer for enterprise search and locatibility. For
presentation of this concept we review the plan to monitor the processes and
counters described below:
Proposal for PerfMon counters
1.Memory and sample counters
+ Memory\Page Faults/sec
+ Memory\Page Reads/sec
+ Memory\Page Writes/sec
2.Network interfaces and sample counters
As any network computer can have multiple network interfaces installed, the
proposal resolves unique reporting by including the CatalogID generated for
network interfaces. The CatalogID could easily be the name associated with the
network interface.
+Network Interface(_Network_Interface_CatalogID)\Bytes Total/sec
+Network Interface(_Network_Interface_CatalogID)\Packets Received/sec
+Network Interface(_Network_Interface_CatalogID)\Packets Sent/sec
+Network Interface(_Network_Interface_CatalogID)\Current Bandwidth
3."Processors and sample counters
As any network computer can have multiple processors, the proposal resolves
unique reporting by including the CatalogID generated for processors. The
CatalogID could easily be the name associated with the processor. +
Processor(_Processor_CatalogID_Total)\% Processor Time
For presentation of the concept if the PerfMon Tool is used to select at least
one of the above counters, a Sample data section will appear in the dialog
box. Enter 15 minutes as the interval. This will enable the Tracking_Submit
function invoked by the sensor framework to read the required management
information and reroll or migrate the information to the ERS/ELS/ELRS servers.
When the PerfMon information is processed and stored in the repository on the
ERS/ELS/ELRS servers the deployment addresses the mixed grid availability.
Proposal for enterprise location support
1. Any enterprise investment will need to support interoperability and the
planning of a proposal for sample counters. Today Application Data Center
investments will require infrastructure for supporting management servers like
the following:
+ Application Data Center Server - This is the management server for the
Application Data Center solution. The services supported by the Data Center
Server will commonly store definitions, descriptions and counters to
administer the management solution. This Application Data Center could be
modelled as an ELS PerfMon Service Provider.
+ Application Data Center Primary Server/Secondary Server - This is the
management support for defining a role for each of the Application Data Center
servers in the network. Like any primary member role, the primary Data Center
server will be the member to receive all transported management information
and management support. On receipt, storage and successive configuration the
data will be transmitted and published to the other Application Data Center
servers for backup or alternate support.
+ Application Data Center BackUp Server - This is the management support
provided by the Application Data Center Secondary Server or any other
Operations Server that needs backup or alternate availability.
+ Application Data Center Operations Manager Server - This is the management
server that supports the core services for managing the Application Data
Center solution. The Operations Manager will be core support for ensuring that
the resource definitions, descriptions and counters are available in the mixed
grid. The Operations Manager Server will administer the settings and options
for the Data Center information.
Application Data Center Operations Manager Server
In the design for a ELS Application Data Center Operations Manager Server or
Connector these options are integral in service manageability:
+ The Operations Manager or Connector will need to know the Application Center
or ELD database involved. The Connector will also need to know the number of
connectors that can be installed on a Application Data Center host server.
+ The Connector will need to know the names of the ERS-ELD or ELRS-ELD servers
to be contacted for synchronization. These are some classifications of
synchronization, Bi directional synchronization, Selective attribute
synchronization, Change synchronization and synchronization of attribute level
changes.
+ The Connector will need to know the object classes to be included in the
synchronization process between ERS-ELD and ELRS-ELD servers.
+ The Connector will need to know the object classes to be included in the
detection and use of the member synchronization process between ERS servers.
+ The Connector will need to know the direction in which the synchronization
should occur.
+ The Connector will need scheduling information for the synchronization
process
+ The Connector will need to know how deleted objects will be dealt with
+ The Connector will need to know the list of attributes to be synchronized
and how the attributes map between ERS-ELD or ELRS-ELD servers.
+ The Connector will need to know which method is used for creating new
objects
+ The Connector will need to know the authentication methods supported
+ The Connector will need to know the list of containers that will be involved
in synchronization and how they map between ERS-ELD and ELRS-ELD servers.
+ The Connector will need to define options and support performance monitoring
through custom performance objects and counters. Typical objects and counters
like Processor Performance monitoring objects, Memory Performance monitoring
objects, Disk Performance monitoring objects, Network Performance monitoring
objects, software resource objects and object classes for selective attribute
tracking sessions.
+ The Connector will need to know the support for logging status details for
Replication events, Account Management events that occur during a write/read
of an object during replication, Attribute Mapping events that occur while
mapping attributes from one database to another, Service Controller events
that occur when the connector services are started, reset, stopped and events
for Enterprise Location Domain Services operations that occur while ERS/ELRS
services access the Location Domain database.
Application Data Center: Performance Monitoring and sample counters
As multiple Connectors can be installed on any network computer, the proposal
resolves unique reporting by including the CatalogID generated for
"Connectors. The CatalogID could easily be the name associated with the
Connector.
1. Synchronization(_Connector_CatalogID)\Number of changes
2. Synchronization(_Connector_CatalogID)\Number of Reads
3. Synchronization(_Connector_CatalogID)\Number of Writes
4. Synchronization(_Connector_CatalogID)\Number of containers
5. Synchronization(_Connector_CatalogID)\Number of Members
6. Synchronization(_Connector_CatalogID)\Scheduling parameters
7. Synchronization(_Connector_CatalogID)\Number of deletes
Application Data Center: Memory and sample counters
1. Memory\Page Faults/sec
2. Memory\Page Reads/sec
3. Memory\Page Writes/sec
Application Data Center: Network interfaces and sample counters
As multiple Network Interfaces can be installed on any network computer, the
proposal resolves unique reporting by including the CatalogID generated for
network interfaces. The CatalogID could easily be the name associated with the
network interface.
1.Network Interface(_Network_Interface_CatalogID)\Bytes Total/sec
2.Network Interface(_Network_Interface_CatalogID)\Packets Received/sec
3.Network Interface(_Network_Interface_CatalogID)\Packets Sent/sec
4.Network Interface(_Network_Interface_CatalogID)\Current Bandwidth
Application Data Center: Processors and sample counters
As multiple Processors can be installed on any network computer, the proposal
resolves unique reporting by including the CatalogID generated for processors.
The CatalogID could easily be the name associated with the processor.
1. Processor(_Processor_CatalogID_Total)\% Processor Time
Application Data Center Software Resources and Applications
1. Administering resources is a potent solution thereby it needs cost
effectiveness and smarter design. The effectiveness is real only if the
network user can access resources irrespective of the network or domain or
neighborhood. Software resources are core providers for any network and
service collaboration. The sensor-controlled enterprise does strategize
software access through associating scope for software applications. The scope
is conceived as access driven and specific to software support.
Software Applications Illustration A:
HostSoftwareResources: Software installed on the host; most products will be
conceived as HostSoftwareResources associations. HostSoftwareResources will
use settings for scope and colloboration:
+ "The Enterprise Domain setting - Enterprise domain associated with the
sensor/sensors.
+ The Hash setting - A cryptographic fingerprint for the software or file.
+ The Certificate setting - A software publisher certificate used to digitally
sign a software or file.
+ The Path setting - The local or universal naming convention (UNC) path of
where the software is stored.
Software Applications Illustration B:
ComponentSoftwareResources: Software installed on the host but as components
of other software. ComponentSoftwareResources will use settings for scope and
colloboration:
+ The Enterprise Domain setting - Enterprise domain associated with the
sensor/sensors.
+ The Hash setting - A cryptographic fingerprint of the component or file.
+ The Certificate setting - A software publisher certificate used to digitally
sign a software or file.
+ The Path setting - The local or universal naming convention (UNC) path of
where the software is stored.
+ The HostSoftwareResourceHash setting - A cryptographic fingerprint for the
HostSoftwareResources that this software or file is a component for.
Software Applications Illustration C:
OptionalSoftwareResources: Software installed on the host as optional
components by themselves or as updates to extend products.
OptionalSoftwareResources will use settings for scope and colloboration:
+ The Enterprise Domain setting - Enterprise domain associated with the
sensor/sensors.
+ The Hash setting - A cryptographic fingerprint of the component or file.
+ The Certificate setting - A software publisher certificate used to digitally
sign a software or file.
+ The Path setting - The local or universal naming convention (UNC) path of
where the software is stored.
+ The HostSoftwareResourceHash setting - A cryptographic fingerprint for the
HostSoftwareResources that this software application or file is a component
for.
+ The ComponentSoftwareResourceHash setting - A cryptographic fingerprint for
the ComponentSoftwareResources that this software application or file is a
component for.
Software Applications Illustration D:
ServiceSoftwareResources: Software installed as services on the host. The
ServiceSoftwareResources will use settings for scope and colloboration:
+ The Enterprise Domain setting - Enterprise domain associated with the
sensor/sensors.
+ The Enterprise Domain Model setting - A model associated with the Enterprise
Domain
+ The Hash setting - A cryptographic fingerprint of the service or file.
+ The Certificate setting - A software publisher certificate used to digitally
sign a software or file.
+ The Path setting - The local or universal naming convention (UNC) path of
where the software is stored.
+ The HostSoftwareResourceHash setting - A cryptographic fingerprint for the
HostSoftwareResources that this service or file is a component for.
+ The ComponentSoftwareResourceHash setting - A cryptographic fingerprint for
the ComponentSoftwareResources that this service or file is a component for.
Software Applications Illustration E:
DriverSoftwareResources: Software installed as drivers on the host.
DriverSoftwareResources will use settings for scope and colloboration:
+ The Enterprise Domain setting - Enterprise domain associated with the
sensor/sensors.
+ The Enterprise Domain Model setting - A model associated with the Enterprise
Domain
+ The Hash setting - A cryptographic fingerprint of the driver or file.
+ The Certificate setting - A software publisher certificate used to digitally
sign a software or file.
+ The Path setting - The local or universal naming convention (UNC) path of
where the software is stored.
+ The HostSoftwareResourceHash setting - A cryptographic fingerprint for the
HostSoftwareResources that this driver or file is a component for.
+ The ComponentSoftwareResourceHash setting - A cryptographic fingerprint for
the ComponentSoftwareResources that this driver or file is a component for.
Software Applications Illustration F:
InternetSoftwareResources: Software downloaded from the Internet or scoped to
run on the Internet. The sites and trusts associated are important for this
scope. The InternetSoftwareResources will use settings for scope and
colloboration:
+ The Enterprise Domain setting - Enterprise domain associated with the
sensor/sensors.
+ The Internet Sites setting - These are sites that can be predefined or needs
to be initialized when the software resource is downloaded or saved locally.
+ The Internet Trusts or Security Authentication and secure access settings.
Options available from the Internet services define manageability.
+ The Enterprise Domain Model setting - A model associated with the Enterprise
Domain
+ The Hash setting - A cryptographic fingerprint of the software application
or file.
+ The Certificate setting - A software publisher certificate used to digitally
sign a software or file.
+ The GenericHash setting - A cryptographic fingerprint for the software
application or file set.
+ The HostSoftwareResourceHash setting - A cryptographic fingerprint for the
HostSoftwareResources that this software or file is a component for.
+ The ComponentSoftwareResourceHash setting - A cryptographic fingerprint for
the ComponentSoftwareResources that this software or file is a component for.
Software Applications Illustration G:
IntranetSoftwareResources: Software scoped to run within the intranet or
within the hosting network. IntranetSoftwareResources will use settings for
scope and colloboration:
+ The Enterprise Domain setting - Enterprise domain associated with the
sensor/sensors.
+ The Intranet Domain setting - These are domains or network subnets that can
be predefined. The sensor when installed on a resource provider.
+ The Intranet Trusts or Security Authentication and secure access setting.
Options available from the Intranet services define manageability.
+ The Enterprise Domain Model setting - A model associated with the Enterprise
Domain
+ The Hash setting - A cryptographic fingerprint of the software or file.
+ The Certificate setting - A software publisher certificate used to digitally
sign a software or file.
+ The Path setting - The local or universal naming convention (UNC) path of
where the software is stored.
+ The GenericHash setting - A cryptographic fingerprint for the software
application or file set.
+ The HostSoftwareResourceHash setting - A cryptographic fingerprint for the
HostSoftwareResources that this software or file is a component for.
+ The ComponentSoftwareResourceHash setting - A cryptographic fingerprint for
the ComponentSoftwareResources that this software or file is a component for.
Application Data Center: Software Resources and sample counters
As multiple software resources can be installed on any network computer, the
proposal resolves unique reporting by including the CatalogID generated for
software resources. The CatalogID could easily be the name associated with the
software resource.
+Software(_Software_CatalogID)\Manufacturer Name
+Software(_Software_CatalogID)\Software Type
+Software(_Software_CatalogID)\Product Name
+Software(_Software_CatalogID)\Product Version
+Software(_Software_CatalogID)\Description
+Software(_Software_CatalogID)\Path to the directory where the product is installed
+Software(_Software_CatalogID)\Size of the core program files installed for the product
+Software(_Software_CatalogID)\Date associated with the Product
+Software(_Software_CatalogID)\Unique identifier for the Product
+Software(_Software_CatalogID)\Core\Program File list
+Software(_Software_CatalogID)\Track\addition
+Software(_Software_CatalogID)\Track\deletion
+Software(_Software_CatalogID)\Track\changes
Application Data Center Enterprise Domain Server
This management server supports DNS namespace integration or network
integration. Reliable access to the Data Center services will be provided
by the Domain role.
Remote Process or Remote Procedure Call mechanisms for remote network
computers
1. The Enterprise Location Protocol defines the network transport and service
in querying resource availability in the enterprise grid. The ELP
infrastructure will support configurable options, these options will permit
support for IP, IPv6, enterprise IP based protocols. The Smart Neighborhood
prototype presented in the article series uses IP as the protocol.
To review understanding the ELS and IP security
Conceptually the search for resources and resource access needs to satisfy
security permissions and various rights. It needs to be said that Microsoft
today does support "Ipsec" configuration and IP security policies on Windows
platforms. These security policies define options for network computer access
as "Respond only", "Request Security" and "Require Security".
Looking further, we find that searching or accessing resources in the
enterprise requires permissions and security clauses to be satisfied. This
requirement for satisfying permissions and security clauses is associated with
resources across namespaces, domains, networks and directories. To adapt to
these security requirements, the ELS will base its PerfMon data search,
management and reporting on security configurations such as:
i. Proposal for a "Respond only" option: This configuration identifies that
permission to signal or query a sensor on the network computer is sufficient
for the requestor to access PerfMon resources.
ii. Proposal for a "Request Security" option: This configuration uses network
security if requested by the sensor. This means that if the sensor on the
network computer requires network security to be satisfied and secures
transport of information; the requestor will need to associate security
information along with the signal or query transmission. Alternatively if the
sensor requests no network security, then this configuration will work the
same as the "Respond only" option.
iii. Proposal for a "Require Security" option: This configuration option
identifies that the requestor always needs extended network security. The
sensor will respond to search and access queries only if the requestor does
satisfy the security requirements. In this configuration the requestor and
network computer on which the sensor is installed, transmit a signed key with
the resource access or resource information. Like existing industry support
for security through keys, this configuration will secure the transport of
information through the signed key mechanism.
The Front End and Management Application to use the Service Provider
1.The Enterprise Console features available through the ELS support simple
tracking, searching of network resources, ability to guide decisions for
network management and grids.
2. 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) or ELRS Directory and then sends out XML
Locator queries to the sensors in the enterprise. The various sensors will
process the XML Locator request by checking the results of the Enterprise
Tracking Agent and connection point infrastructure. If the resource
availability is determined, then the sensor will respond with the XML resource
information. The resource information will be formatted as XML sections and
entries that can be read or processed by XML conformant or aware applications.
Links to any background information for this article
1. Any reader interested in the concept is recommended reviewing the articles
"Defining a concept for a Smart Neighborhood" at the site
http://www.gridtoday.com.
2. I would recommend the reader to refer links on "Implementing and
Administering a Microsoft, Windows 2000 Network Infrastructure" and
"Implementing and Administering a Microsoft, Windows 2003 Network
Infrastructure". Microsoft publications for comparing the Active Directory
and the NDS, detecting the Schema Master in Active Directory installations,
developing AD connectors and Administering Directory Services. Readers will
need to access the links on the Microsoft site for these details.
3. I would recommend the reader to refer links on "Novell, Network
Infrastructure and Open Standard based initiatives", available at
http://www.gridtoday.com/03/0616/101552.html.
4. I would recommend interested readers to refer available links on "Defining
a concept for a Smart Neighborhood - Scenarios for integration". This series
is not published or scheduled for publication but is being planned and
proposed for interested readers.
5. Readers will need to access Microsoft publications for Performance Monitor
feature releases and services.
6. I would recommend the reader to refer to the internet link for "Performance
Monitor Scenarios for ISPs, By the Coho Internet Team, and Lee Kimber,
Microsoft Program Manager June 2002".
Readers can access related resources for information
1.Wireless and Mobile Network Architectures, Publisher John Wiley & Sons, ISBN
9971-51-366-8
2.For MDS and other information on the Globus project: see
http://www.globus.org/.
3. MCSE Windows 2000 Directory Services Administration Exam Notes, Sybex, ISBN
81-7656-379-X.
-- K.S.Venkatram is a computer engineer from the University Of Poona.
|