Difference between revisions of "Infrastructure Viewer"

Revision as of 15:47, 5 August 2009

The Infrastructure Viewer is a monitoring tool that offers a new highly customizable visual infrastructure experience. It relies on TreeMaps technology and it was largely inspired by gridmap.cern.ch by customized and designed to accommodate the gCube needs. It offers three views, each designed to offer an immediate understanding of the infrastructure status.

• The gHN View presents the infrastructure organized in sites. For each site, the gHNs belonging to the site, their status, and the list of RIs per gHN with their status.

• The Service View presents the infrastructure organized in Service Classes. For each service class, the available services and the location and status of the running instances of that service. In particular ‘Outdated’ RIs are RIs whose profile is stored in the Information System but that are not running in any gHN (there are a number of cases that can drive to this anomaly. The new IS-Manager service will manage also these anomalies).

• The Data View presents the infrastructure organized in Collections. For each collection, the available metadata collection are reported by indicating the number of metadata objects, the format of the metadata, and the number of indices available for such a collection. For each metatada collection the type of indices and number of indexed objects are displayed.

Implementation

IV Data manipulation

All data show by the IV is retrieved from the IS using the IS-Client. The profiles retrieved are elaborated to generate the information necessary to map generation. Because the profiles elaboration require reusing same profiles multiple times a cache level has been inserted between the IS and the IV.

Views Datasources

Each views for map creation needs some data. This data is produced elaborating the GCUBE resource profiles retrieved by the ASLCache.

The kind of elaboration depends on IV view.

GHN View

All GHNs are grouped by site (the domain attribute profile).

The GHN status calculation follow this rules:

• if the difference between the GHN update time and the last cache update time are more than 25 minutes the status is set to UNREACHEABLE
• otherwise:
  • if the GHN profile is generated by GCORE 0.4.X the GHN state is calculated based on his RI states:
    • if there are no RI the status is set to READY
    • if almost one RI is DOWN the status is set to READY
    • if almost one RI is FAILED the status is set to FAILED
    • if none of previous cases are meet the status is set to CERTIFIED
  • if the GHN profile is generated by GCORE 0.5.x the GHN state is retrieved from the status property.

For each scope (VO, VRE) the minimum common service set (MCS) is calculated (excluding the GHN with no RI associated). In case of VRE scope the GHN that have the same service in minimum set are removed.

A the end for each GHN is calculated if all his RIs belong to the scope following this rules:

• for all RI match one of following statement:
  • the RI is instance of a service that belong to MCS
  • the RI have only one scope and this is equals to the GHN one

If all GHN RIs belong to the scope the GHN is set to belong to scope (no mask is applied).

Package View

To calculate the package view data some preparing steps are necessary:

1. Retrieve the list of packages for service:

   All service profiles are retrieved and elaborated to obtain this map:

   Service Class -> Service Name -> Packages

   where packages are the list of service packages plus each packages dependencies.

   This list is used to retrieved the list of packages deployed on each GHN.

2. Calculate the packages deployed for GHN:

   All ghn profiles are retrieved:

   • For each ghn a list of al RI running on it is retrieved.
     • For each RI a tree of packages dependencies is calculated and putted into the ghn possible packages dependencies list.
       • The ghn possible packages dependecies list is used to purge the ghn deployed packages list.

   A the end of the process a map package -> GHN list is made.

Using the calculated data a package view data map is created:

Service Class->Service Name->Packages->GHN

where the packages are the only the ones that compose the service.

Service View

All RI are processed. For each RI the corresponding Service profile is retrieved using Service Class, Service Name, Service Version in the RI profile. Each service profile retrieved is grouped by Service Class and then by Service Name. For each service all dependencies are retrieved from the profile.

For each RI the following elaboration is done: The RI status is calculated with following rules:

• if the GHN where the RI is runnig is not found in the scope the status is set to OUTDATED
• if the GHN where the RI is running is unreachable the status is set to UNREACHEABLE
• if the RI have an old string state the following map is done:

READY to READY;

DEPLOYED to DOWN;

INITIALISED to DOWN;

PATCHED to DOWN;

REDEPLOYED to DOWN;

FAILED to FAILED;

OUTDATED to OUTDATED;

UNREACHEABLE to UNREACHEABLE;

• otherwise the new status string is used.

A the end the belong to scope property is set to true if in the RI scopes list the current scope is present.

Data View

First of all for the given scope the IV try to retrieve the ScenarioCollectionInfo resource. If found all the collection ids are extracted.

If a collection don't belong to the ScenarioCollectionInfo is marked. For each collection all metadata collections are retrieved.

A metadata collection is set as Annotation if his secondary role in relation with the collection is is-annotated-by. For each metadata collection all indexes are retrieved.

There are two index elaboration depending on the type:

• XML Indices where the only attribute available is the number of docs with the property NumDocs
• the other indices where the following attributes are retrieved:
  • Type from the property IndexTypeName
  • KeyName from the property KeyName
  • IndexStatus from the property IndexStatus
  • last modified from the property Modified
  • number of docs from the property DocumentCount

Package Dependencies View

To calculate the package view data some preparing steps are necessary:

1. Retrieve the list of packages for service:

   All service profiles are retrieved and elaborated to obtain this map:

ASL Cache

The ASL cache aims to reduce the number of queries sent to IS-IC and to cache the retrieved the profiles for successive elaboration. The ASL cache retrieve all profiles querying the IS-Client with a scheduled period. The profiles are retrieved for each VRE, VO and infrastructure.

There the detailed list of performed queries and retrieved profiles:

GCUBEHostingNode

GCUBEGHNQuery

GCUBEService

GCUBEServiceQuery

GCUBERunningInstance

a modified version of RIQuery so that some RI are not filtered

GCUBECollection

GCUBECollectionQuery

GCUBEMCollection

GCUBEMCollectionQuery

RPDocument

a specialized query to retrieve all XML indexes, common indices

GCUBEGenericResource

a specialized query for ScenarioCollectionRetrieving