Difference between revisions of "VRE Management"

From Gcube Wiki
Jump to: navigation, search
(Reference Architecture)
Line 14: Line 14:
 
* '''[[Deployer]]''' – this Service is a local service equipping any gHN in order to provide the ''[[VRE Manager]]'' with the facilities needed to deploy, manage and un-deploy software components on it. Through it, the [[VRE Manager]] can dynamically relocate the constituents of any VRE as to implement policies aiming at maximising the usage of existing assets;
 
* '''[[Deployer]]''' – this Service is a local service equipping any gHN in order to provide the ''[[VRE Manager]]'' with the facilities needed to deploy, manage and un-deploy software components on it. Through it, the [[VRE Manager]] can dynamically relocate the constituents of any VRE as to implement policies aiming at maximising the usage of existing assets;
 
* '''[[Software Repository]]''' – this Service is in charge of providing a gCube based infrastructure with the software components needed to operate Virtual Research Environments. In particular, it will store the software bundles that once deployed on a gHN will originate a new resource (Running Instance) that can be used in the context of one or more VREs;
 
* '''[[Software Repository]]''' – this Service is in charge of providing a gCube based infrastructure with the software components needed to operate Virtual Research Environments. In particular, it will store the software bundles that once deployed on a gHN will originate a new resource (Running Instance) that can be used in the context of one or more VREs;
* '''[[Executor]]''' – this Service acts as a container for '''gCube Tasks''', i.e. functionally unconstrained bodies of code that lack a network interface but are designed and packaged to be executed by the service and to be dynamically deployed as the payload of its plugins.  
+
* '''[[Executor]]''' – this Service acts as a container for '''gCube Tasks''', i.e. functionally unconstrained bodies of code that lack a network interface but can be dynamically deployed into the service and executed through its interface.  
  
 
[[Category:VRE Management]]
 
[[Category:VRE Management]]

Revision as of 10:43, 26 August 2009

VRE Management

The VRE Management subsystem is the family of services and software components responsible for the definition and the dynamic deployment of VREs. A user-friendly user interface supports VREs definitions by guiding the user during the specification of the desired VRE features. Through the same interface the designer is informed on the optimal deployment plan identified by the system. In fact, the resulting plan is based on availability, QoS requirements, resource inter-dependencies, and VRE sharing policies, but also on monitoring of failures (resources are dynamically redeployed) and load (resources are dynamically replicated). The VRE Manager, by coordinating four distinguished services (Deployer, Software Repository, Broker and Matchmaker, gCube Hosting Node Manager), realises the VRE dynamic deployment by, respectively, collecting service implementations, selecting target nodes for deployment within the infrastructure, and hosting resources implementations at selected nodes.

Reference Architecture

As anticipated, the mission assigned to this subsystem consists in supporting the implementation of Virtual Research Environments from their definition/specification to their operation and maintenance. The services forming the subsystem have been organised according to this path as depicted in Figure 1 and described below.

Figure 1. VRE Management Reference Architecture

To implement its role the VRE Management subsystem is organised in the following main services:

  • VRE Modeler – this Service enables users/communities (VRE Designers) to define VREs and VRE Administrators to actually create them and monitor their operational status. It allows the definition of a set of criteria by specifying the expected characteristics of the new VRE; starting from them, it identifies the set of resources required to provide the requested features. Both the characterization criteria and the resulting set of resources constitute the VRE Definition document;
  • VRE Manager – this Service coordinates the activities needed to transform a VRE as specified in a VRE Definition document into a running set of coordinated and cooperating resources implementing it. Because of its central role, it is requested to operate with almost all services forming the VRE management subsystem as well as with the rest of the services forming the backbone of a gCube based infrastructure, i.e. the Information Service, the Virtual Organisation Management Service, the Broker and Matchmaker and the Process Management. In particular, it creates and makes publicly available through the IS the VRE Resource, i.e. the operational context needed to properly operate the pool of resources forming the VRE;
  • gHN Manager – this Service provides the VRE Manager service with an entry point for managing the node, e.g. installing the mandatory software, publishing node information. Bacause of this, it is expected to be deployed on each of gCube nodes as one of the local services contributing to form the gCube run-time;
  • Deployer – this Service is a local service equipping any gHN in order to provide the VRE Manager with the facilities needed to deploy, manage and un-deploy software components on it. Through it, the VRE Manager can dynamically relocate the constituents of any VRE as to implement policies aiming at maximising the usage of existing assets;
  • Software Repository – this Service is in charge of providing a gCube based infrastructure with the software components needed to operate Virtual Research Environments. In particular, it will store the software bundles that once deployed on a gHN will originate a new resource (Running Instance) that can be used in the context of one or more VREs;
  • Executor – this Service acts as a container for gCube Tasks, i.e. functionally unconstrained bodies of code that lack a network interface but can be dynamically deployed into the service and executed through its interface.