Difference between revisions of "VRE Management"
Manuele.simi (Talk | contribs) (→Reference Architecture) |
Luca.frosini (Talk | contribs) (→Reference Architecture) |
||
(18 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
+ | [[Category:User's Guide]][[Category:VRE Management]] | ||
== VRE Management == | == 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 [[ | + | The VRE Management subsystem is the family of services and software components responsible for the definition and the dynamic deployment of VREs as well as the management of resources in a Virtual Organization. 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 Gateway]]'', ''[[Resource Broker]]'', ''[[gHN Manager|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. |
+ | |||
+ | [[Image:VREManagementComponents-Fig1.png|frame|center| VREManagement components and main interactions]] | ||
=== Reference Architecture === | === 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 | ||
+ | * managing resources within a Virtual Organization | ||
− | + | The stack of services forming the subsystem has been designed according to this patterns: | |
− | + | ||
− | + | ||
* '''[[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); |
− | * '''[[gHN Manager]]''' – this Service provides the ''[[ | + | * '''[[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 [[gCore Based 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). |
− | * '''[[Deployer]]''' – this Service is a local service equipping any gHN in order to provide the ''[[ | + | * '''[[gHN Manager]]''' – this Service provides the ''[[Resource 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; |
− | * '''[[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; | + | * '''[[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]]'''(until gCube 2.8.1) – 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 Gateway]]''' (from gCube 2.9.0) - this Service... | ||
+ | * '''[[Executor]]''' – (DEPRECATED use [[SmartExecutor]] instead) 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. | ||
+ | * '''[[SmartExecutor]]''' – this Service acts as a container for '''gCube Tasks''' and replace the old '''[[Executor]]'''. The Service is runs on Smartgears. | ||
+ | |||
− | [[ | + | Starting from gCube 2.5.0, the dynamic deployment at the heart of the subsystem has been extended to target also different platforms that gCore. This led to define the following two additional components: |
+ | * '''[[Virtual Platform]]''' – a model to be extended for transparently interfacing a potentially unlimited number of hosting environments | ||
+ | * '''[[Tomcat Virtual Platform]]''' – an implementation of the model for Tomcat 6. |
Latest revision as of 13:50, 19 October 2016
VRE Management
The VRE Management subsystem is the family of services and software components responsible for the definition and the dynamic deployment of VREs as well as the management of resources in a Virtual Organization. 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 Gateway, 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
- managing resources within a Virtual Organization
The stack of services forming the subsystem has been designed according to this patterns:
- 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 gCore Based 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 Resource 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(until gCube 2.8.1) – 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 Gateway (from gCube 2.9.0) - this Service...
- Executor – (DEPRECATED use SmartExecutor instead) 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.
- SmartExecutor – this Service acts as a container for gCube Tasks and replace the old Executor. The Service is runs on Smartgears.
Starting from gCube 2.5.0, the dynamic deployment at the heart of the subsystem has been extended to target also different platforms that gCore. This led to define the following two additional components:
- Virtual Platform – a model to be extended for transparently interfacing a potentially unlimited number of hosting environments
- Tomcat Virtual Platform – an implementation of the model for Tomcat 6.