Difference between revisions of "VRE Management"

From Gcube Wiki
Jump to: navigation, search
(Reference Architecture)
(Reference Architecture)
Line 8: Line 8:
  
 
* '''[[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 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''''';
 
+
* '''[[Resource Manager]]''' – this service is in charge of managing gCube Scopes. It stays on top of the rest of the VREManagement services and coordinates them to satisfy the VRE Modeler requests.More specifically, the service manages the gCube resource belonging the Scope and creates new instances of services within it. To do so, it interacts with the Software Repository (for dependecies resolution), the Resource Broker (for allocating the service on gHNs), the Deployer (for deploying the services), the gHN Manager (for managing gHN's Scope) and the Information System (for publishing and retrieving resource's profiles);
* '''[[Resource Manager]]''' – [''a description will follow soon.'']
+
 
* '''[[Resource Broker]]''' – this service promotes and supports the ''optimal selection ''and'' usage'' of resources during the deployment phase. In particular, it is invoked to select the most appropriate pool of gHNs to be used, among those available in the context of the Scope, during the deployment of the services needed to operate the Scope. Because of this, it interacts with the [[Information System]] to be aware of the available gHNs as well as of their distinguishing features (e.g. the number of Running Instances currently hosted by it, the RAM the machine is equipped with).
 
* '''[[Resource Broker]]''' – this service promotes and supports the ''optimal selection ''and'' usage'' of resources during the deployment phase. In particular, it is invoked to select the most appropriate pool of gHNs to be used, among those available in the context of the Scope, during the deployment of the services needed to operate the Scope. Because of this, it interacts with the [[Information System]] to be aware of the available gHNs as well as of their distinguishing features (e.g. the number of Running Instances currently hosted by it, the RAM the machine is equipped with).
 
* '''[[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;  
 
* '''[[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;
+
* '''[[Deployer]]''' – this Service is a local service equipping any gHN in order to provide the ''[[Resource Manager]]'' with the facilities needed to deploy, manage and un-deploy software components on it. Through it, the [[Resource 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 can be dynamically deployed into the service and executed through its interface.  
 
* '''[[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.  
 +
 +
The subsystem has recently broaden its vision to a more general resource management area. This means that all the services (with the exception of the VRE Modeler) can be used to manage even Virtual Organizations, not only VREs.
  
 
[[Category:VRE Management]]
 
[[Category:VRE Management]]

Revision as of 19:54, 8 June 2010

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 Resource Manager, by coordinating four distinguished services (Deployer, Software Repository, Resource Broker, 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

The primary role assigned to this subsystem consists in supporting the implementation of Virtual Research Environments from their definition/specification to their operation and maintenance. The stack of services forming the subsystem has been designed according to this path as described below.

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;
  • Resource Manager – this service is in charge of managing gCube Scopes. It stays on top of the rest of the VREManagement services and coordinates them to satisfy the VRE Modeler requests.More specifically, the service manages the gCube resource belonging the Scope and creates new instances of services within it. To do so, it interacts with the Software Repository (for dependecies resolution), the Resource Broker (for allocating the service on gHNs), the Deployer (for deploying the services), the gHN Manager (for managing gHN's Scope) and the Information System (for publishing and retrieving resource's profiles);
  • Resource Broker – this service promotes and supports the optimal selection and usage of resources during the deployment phase. In particular, it is invoked to select the most appropriate pool of gHNs to be used, among those available in the context of the Scope, during the deployment of the services needed to operate the Scope. Because of this, it interacts with the Information System to be aware of the available gHNs as well as of their distinguishing features (e.g. the number of Running Instances currently hosted by it, the RAM the machine is equipped with).
  • 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 Resource Manager with the facilities needed to deploy, manage and un-deploy software components on it. Through it, the Resource 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.

The subsystem has recently broaden its vision to a more general resource management area. This means that all the services (with the exception of the VRE Modeler) can be used to manage even Virtual Organizations, not only VREs.