Difference between revisions of "VO Services Deployment and Configuration"
Manuele.simi (Talk | contribs) (→Content Management) |
m |
||
(6 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
+ | [[Category:Administrator's Guide]] | ||
__NOTOC__ | __NOTOC__ | ||
Line 10: | Line 11: | ||
The recommended deployment scenario, it is suggested to deploy at VO level the following groups of services: | The recommended deployment scenario, it is suggested to deploy at VO level the following groups of services: | ||
* Content Management | * Content Management | ||
− | |||
* Index Management | * Index Management | ||
* Personalisation Services | * Personalisation Services | ||
Line 18: | Line 18: | ||
* Time Series | * Time Series | ||
* Ontology Management | * Ontology Management | ||
− | * Data | + | * Data Transformation Services |
=== Preparing the hosting gHNs === | === Preparing the hosting gHNs === | ||
Line 34: | Line 34: | ||
''Dynamic Deployment'' is a key feature of the gCube system. It refers to the possibility to remotely deploy any service of the gCube system on any gHNs available in a Scope. | ''Dynamic Deployment'' is a key feature of the gCube system. It refers to the possibility to remotely deploy any service of the gCube system on any gHNs available in a Scope. | ||
− | An authorized user (VO-Manager) can perform deployment on a VO with the features offered by the | + | An authorized user (VO-Manager) can perform deployment on a VO with the features offered by the [https://gcube.wiki.gcube-system.org/gcube/index.php/Resource_Management Resource Management Portlet]. |
Dynamic Deployment is the default way to deploy the VO-level Services presented below. | Dynamic Deployment is the default way to deploy the VO-level Services presented below. | ||
Line 70: | Line 70: | ||
It does not have any special requirement on the target gHN. | It does not have any special requirement on the target gHN. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Content Management === | === Content Management === | ||
Line 85: | Line 75: | ||
The following services have to be selected for dynamic deployment: | The following services have to be selected for dynamic deployment: | ||
− | * Content | + | * Content Manager |
+ | * View manager | ||
* Storage Management | * Storage Management | ||
* Archive Import | * Archive Import | ||
Line 95: | Line 86: | ||
* TimeSeriesService | * TimeSeriesService | ||
− | This service requires an instance of MySQL DBMS on the target | + | This service requires an instance of MySQL DBMS on the target node. |
=== gCube Personalization === | === gCube Personalization === | ||
Line 102: | Line 93: | ||
* User Profile Access | * User Profile Access | ||
− | |||
− | They do not have any special requirement on the target | + | |
+ | They do not have any special requirement on the target node. |
Latest revision as of 09:09, 24 July 2013
VO Services
Besides the Enabling Services, in a typical deployment scenario, a subset of the gCube Services are deployed at VO level (while the remaining part is deployed at VRE level). The criteria for selecting the target scope level for a specific service are:
- better performances in case of shared instances
- complexity of the service's initialization/state creation
- special requirements on the target gHN (such as a local DBMS instance)
- high demand of storage/computational resources
The recommended deployment scenario, it is suggested to deploy at VO level the following groups of services:
- Content Management
- Index Management
- Personalisation Services
- VRE Modeler
Then, according to the VO needs, other services could be optionally deployed at VO level:
- Time Series
- Ontology Management
- Data Transformation Services
Preparing the hosting gHNs
Before to proceed with the services' deployment, the related hosting gHNs must be prepared in order to host their running instances. In the suggested deployment scenario, at least 5 machines must be turned as gHNs.
Per each machine:
- install gCore and copy the Service Map files under the $GLOBUS_LOCATION/config folder
- configure the gHN to join the VO scope
- start the container and verify that the gHN is correctly published both in the infrastructure and in the VO Information Systems.
These 5 gHNs will be used to host the 5 suggested groups of services enumerated in the previous section.
Dynamic Deployment in gCube
Dynamic Deployment is a key feature of the gCube system. It refers to the possibility to remotely deploy any service of the gCube system on any gHNs available in a Scope. An authorized user (VO-Manager) can perform deployment on a VO with the features offered by the Resource Management Portlet.
Dynamic Deployment is the default way to deploy the VO-level Services presented below.
VRE Modeler
The following service has to be selected for dynamic deployment:
- VRE Modeler
It does not have any requirement on the target gHN.
Data Transformation
The following service has to be selected for dynamic deployment:
- DataTransformationService
It does not have any requirement on the target gHN.
Index Management
The following services have to be selected:
- Index Lookup
- Index Management
- Index Updater
These services are both memory and storage demanding, therefore the target dedicated gHN must match these characteristics (their values mainly depend on the VO expected content).
Ontology Management
The following service has to be selected:
- OntologyManagementService
It does not have any special requirement on the target gHN.
Content Management
The following services have to be selected for dynamic deployment:
- Content Manager
- View manager
- Storage Management
- Archive Import
and installed on a clean gHN with a storage capacity of > 50 GB (this value mainly depends on the VO expected content).
Optionally, depending on the VO needs, the following service is selected and installed on a separated gHN:
- TimeSeriesService
This service requires an instance of MySQL DBMS on the target node.
gCube Personalization
The following services have to be selected for dynamic deployment:
- User Profile Access
They do not have any special requirement on the target node.