Difference between revisions of "Administrator's Guide: How to set up a gCube infrastructure"

From Gcube Wiki
Jump to: navigation, search
(Secure configuration)
(Other possible configurations)
 
(62 intermediate revisions by 7 users not shown)
Line 1: Line 1:
A ''gCube infrastructure'' is a set of working nodes (so-called DHNs, DILIGENT Hosting Nodes) glued by the gCube enabling services and able to host gCube services in a cooperative way. When creating a new infrastructure, there are two kinds of configuration: secure configuration and non-secure configuration The setup of the latter is easier than the former, since the secure infrastructures require some additional steps.<br>
+
[[Category:Administrator's Guide]]
== Non-secure configuration ==
+
__NOTOC__
==== Minimal configuration ====
+
{| align="right" style="color:red; border:1px solid #aaa; background-color: #f9f9f9; padding: 5px; font-size: 95%;" cellspacing="0"
Perform the following steps to create and configure a non-secure infrastructure:
+
|+  <b>Section contents</b>
#decide a name for the new infrastructure
+
|-  
#decide the VOs hierarchy configuration: at least one root VO and a subVO are required to be there
+
|[[Administrator's_Guide:How_to_set_up_a_gCube_infrastructure#Minimal_deployment_scenario|1 Minimal deployment scenario]]
#identify a set of machines to turn on as DHNs (their number may vary depending on the infrastructure needs)
+
|-  
#[[DHN_Installation#VOMap_files|prepare a VO Map]] file for each VO
+
|[[Administrator's_Guide:How_to_set_up_a_gCube_infrastructure#Other_possible_configurations|2 Other possible configurations]]
#setup the root VO
+
|}
##identify two machines to dedicate to the VO management
+
A ''gCube infrastructure'' is a set of working nodes (so-called gHNs, gCube Hosting Nodes) glued by the gCube enabling services and able to host gCube services in a cooperative way.
##[[DHN_Installation|install the DHN 1.0 bundle]] in the two machines and copy the VO Map files under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder
+
<br>
##[[DHN_Installation#Post-installation_configuration|configure]] one DHN (named ''DIS root DHN'') as root, join it to the root VO as default VO and [[Core_Services_Installation#DILIGENT_Information_Service_.28DIS.29|install the DIS core services]] (DIS-IC, DIS-Registry, DIS-Broker) there dedicated to the management of the root VO
+
##[[DHN_Installation#Post-installation_configuration|configure]] one DHN (named ''DLMan root DHN'') to join it to the root VO as default VO and
+
##*[[Core_Services_Installation#Package_Repository|install and populate a Package Repository]] there
+
##*[[Core_Services_Installation#DL_Management|install and configure a DL Management Service]] there
+
##start the container on the ''DIS root DHN'' and then on the ''DLMan root DHN'' and verify that they work properly
+
#setup the subVO
+
##identify two machines to dedicate to the subVO management
+
##[[DHN_Installation|install the DHN 1.0 bundle]] in the two machines and copy the VO Map files under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder
+
##[[DHN_Installation#Post-installation_configuration|configure]] one DHN as root, join it to the subVO as default VO and [[Core_Services_Installation#DILIGENT_Information_Service_.28DIS.29|install the DIS core services]] (DIS-IC, DIS-Registry, DIS-Broker) there dedicated to the subVO (named ''DIS subVO DHN'')
+
##[[DHN_Installation#Post-installation_configuration|configure]] one DHN (named ''DLMan subVO DHN'') to join it to the subVO as default VO and [[Core_Services_Installation#DL_Management|install and configure a DL Management Service]] there
+
##start the container on the ''DIS subVO DHN'' and then on the ''DLMan subVO DHN'' and verify that they work properly
+
#configure and start generic DHNs
+
##[[DHN_Installation|install the DHN 1.0 bundle]] in each machine and copy the VO Map files under the ''$GLOBUS_LOCATION/etc/org_diligentproject_keeperservice_hnm/VOMaps'' folder
+
##[[DHN_Installation#Post-installation_configuration|configure]] the DHNs to join the subVO as default VO:
+
##start the container on each machine and verify that the DHN is correctly published both in the root VO and in the subVO DIS
+
#setup the portal by following the [[DILIGENT Gridsphere and Portal Security patch]] instructions.
+
#configure one or more VREs by exploiting the [[Administration]] user interface capability reported in the User's Guide manual.
+
  
==== Other possible configurations ====
+
=== Minimal deployment scenario ===
Alternative configurations can improve the infrastructure performances. In particular:
+
* the DIS-Broker can be hosted on a different(and standard, i.e. non-root) DHN with respect to the other two DIS core services
+
* the Package Repository can be hosted on a different (and standard, i.e. non-root) DHN with respect to the DL Management service
+
* multiple subVOs can be defined
+
* more than one DIS can be setup for each VO in order to distribute the load over them
+
  
The 'optimal' configuration mainly depends on the number of available DHNs. More DHNs joining the infrastructure means a better distribution of resources and services across them.
+
In this section, we report the steps to setup a gCube infrastructure:
  
== Secure configuration ==
+
#decide the [https://gcore.wiki.gcube-system.org/gCube/index.php/Scope_Management#Modelling_Scope scope] configuration, i.e. the name of the infrastructure
The setup of a secure configuration is a bit more complex with respect to a non-secure one, but it introduces some advantages. In fact, having such a configuration allows sharing of service instances among multiple VREs. <br>
+
#identify a set of machines to turn on as gHNs (their number may vary depending on the Infrastructure needs)
The steps described for the [[Administrator's_Guide:How_to_set_up_a_gCube_infrastructure#Non-secure_configuration|non-secure configurations]] have to be integrated by the additional actions reported below.
+
#[[Information_System_Installation#Service_Map|prepare a Service Map]] file for the infrastructure
<br>
+
#install the infrastructure enabling services:
*Steps 5.2, 6.2 e 7.1 requires the following:
+
##identify 3 machines to dedicate to the Infrastructure Enabling Services
:a) [[How_To_Configure_DHN_Security|configure the Java WS Core container]] running on each DHN to run with host credentials
+
##[https://gcore.wiki.gcube-system.org/gCube/index.php/Administrator_Guide#Installation install gCore] in the 3 machines and copy the two Service Map files under the ''$GLOBUS_LOCATION/config'' folder
:b) [[DHN_Installation#JNDI_file|configure the HNM Service]] hosted on each DHN to run with the security enabled
+
##[https://gcore.wiki.gcube-system.org/gCube/index.php/Administrator_Guide#Configuration configure] the first gHN to join to the infrastructure scope and
<br>
+
##* deploy and configure an [[Information_System_Installation#Version_2.0.0_or_higher|IS-Collector]] instance and configure it to join the infrastructure scope
*The setup of the root VO includes this preliminary actions:
+
##[https://gcore.wiki.gcube-system.org/gCube/index.php/Administrator_Guide#Configuration configure] the second gHN as ROOT and to join to the infrastructure scope and
:a) [[Core_Services_Installation#Pre-installation_setup_6|install]] a MyProxy repository and a MyProxy OnlineCA
+
##* deploy and configure an [[Information_System_Installation#IS-Registry|IS-Registry]] instance and configure it to join the infrastructure scope
:b) [[Core_Services_Installation#Pre-installation_setup_6|install]] a VOMS service
+
##* deploy and configure an [[Information_System_Installation#IS-Notifier|IS-Notifier]] instance and configure it to join the infrastructure scope
:c) [[DILIGENT_Gridsphere_and_Portal_Security_patch#Install_and_configure_the_VOMS_servlet|install]] a VOMSServlet on a Tomcat hosting environment
+
##[https://gcore.wiki.gcube-system.org/gCube/index.php/Administrator_Guide#Configuration configure] the third gHN to join it to the infrastructure scope and
:d) identify a further DHN to dedicate to the VO management and [[DHN_Installation#Post-installation_configuration|configure]] it (named ''CR root DHN'') as root, join it to the root VO as default VO  
+
##* deploy a [[VRE_Management_Installation#Software_Gateway|Software Gateway]] instance and configure it to join both the infrastructure and the VO scope
:e) [[Core_Services_Installation#Credentials_Renewal_Installation|install an instance of the Credentials Renewal service]] on the ''CR root DHN''
+
##* deploy a [[VRE_Management_Installation#Resource_Manager|Resource Manager]] instance and a [[VRE_Management_Installation#Resource_Broker|Resource Broker]] instance and configure them to join the infrastructure scope
:f) [[How_To_Configure_Service_Security|configure each service]] to use the security
+
##start the 3 containers following the order of the deployments and verify that they work properly
: The startup sequence in this case is: start the container on the DIS root DHN, then on the CR root DHN and then on the DLMan root DHN and verify that they work properly
+
  
Regarding the security used by each gCube service, the steps needed depends here on the way the service behaves with respect to the credentials used. It can act by using the service credentials or by using the caller credentials.<br>
+
=== Other possible configurations ===
'''Service credentials'''
+
Alternative configurations can improve the infrastructure performances. In particular:
:a) [[How_To_Configure_Identities_For_DILIGENT_Services#Delegate_credentials_to_MyProxy|delegate proxy credentials]] on the MyProxy for the service stored on the Package Repository
+
* the IS-Notifier can be hosted on a different gHN with respect to the IS-Registry service
:b) [[How_To_Configure_Identities_For_DILIGENT_Services#Create_a_new_Credentials_Renewal_account|create an Account]] on the Credential Renewal instance for each proxy credentials stored
+
* the Software Gateway can be hosted on a different gHN with respect to the Resource Management services
:c) create a Renewal Task (using the appropriate Account Resource) on the Credentials Renewal instance for each Running Instance of a gCube service
+
* multiple Virtual Organizations can be defined and deployed
:*this operation is performed automatically by the CL services in case of dynamically deployed instances
+
:*this operation has to be done [[How_To_Configure_Identities_For_DILIGENT_Services#Set-up_a_credentials_renewal_task|manually]] in case of statically deployed instances
+
:d) each running instance [[How_To_Configure_Service_Security#Provide_your_service_with_credentials|retrieves its own credentials]] from the local Delegation Service for the current VRE (extracted from the caller credentials)
+
  
'''Caller credentials'''
+
The 'optimal' configuration mainly depends on the number of available gHNs and on the expected exploitation of the infrastructure. The more gHNs join the infrastructure the better distribution of resources and services across them is doable.
:a) each running instance retrieves the credentials from the context (delegated from the caller credentials)
+
:b) each running instance is invoked by using the Full Delegation modality
+
 
+
<br>
+
<br>
+
[[User:Manuelesimi|Manuelesimi]] 13:45, 5 December 2007 (EET)
+

Latest revision as of 10:16, 10 April 2015


Section contents
1 Minimal deployment scenario
2 Other possible configurations

A gCube infrastructure is a set of working nodes (so-called gHNs, gCube Hosting Nodes) glued by the gCube enabling services and able to host gCube services in a cooperative way.

Minimal deployment scenario

In this section, we report the steps to setup a gCube infrastructure:

  1. decide the scope configuration, i.e. the name of the infrastructure
  2. identify a set of machines to turn on as gHNs (their number may vary depending on the Infrastructure needs)
  3. prepare a Service Map file for the infrastructure
  4. install the infrastructure enabling services:
    1. identify 3 machines to dedicate to the Infrastructure Enabling Services
    2. install gCore in the 3 machines and copy the two Service Map files under the $GLOBUS_LOCATION/config folder
    3. configure the first gHN to join to the infrastructure scope and
      • deploy and configure an IS-Collector instance and configure it to join the infrastructure scope
    4. configure the second gHN as ROOT and to join to the infrastructure scope and
      • deploy and configure an IS-Registry instance and configure it to join the infrastructure scope
      • deploy and configure an IS-Notifier instance and configure it to join the infrastructure scope
    5. configure the third gHN to join it to the infrastructure scope and
    6. start the 3 containers following the order of the deployments and verify that they work properly

Other possible configurations

Alternative configurations can improve the infrastructure performances. In particular:

  • the IS-Notifier can be hosted on a different gHN with respect to the IS-Registry service
  • the Software Gateway can be hosted on a different gHN with respect to the Resource Management services
  • multiple Virtual Organizations can be defined and deployed

The 'optimal' configuration mainly depends on the number of available gHNs and on the expected exploitation of the infrastructure. The more gHNs join the infrastructure the better distribution of resources and services across them is doable.