Administrator's Guide: How to set up a gCube infrastructure
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.
Contents
Non-secure configuration
Minimal configuration
The setup a minimal configuration of a non-secure infrastructure requires the following steps:
- decide the VOs hierarchy configuration: at least one root VO and a subVO are required to be there
- identify a set of machines to turn on as DHNs (their number may vary depending on the infrastructure needs)
- prepare a VO Map XML file for each VO
- setup the root VO
- identify two machines to dedicate to the VO management
- 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
- configure one DHN (named DIS root DHN) as root, join it to the root VO as default VO and install the DIS core services (DIS-IC, DIS-Registry, DIS-Broker) there dedicated to the management of the root VO
- configure one DHN (named DLMan root DHN) to join it to the root VO as default VO and
- 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
- 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
- configure one DHN as root, join it to the subVO as default VO and install the DIS core services (DIS-IC, DIS-Registry, DIS-Broker) there dedicated to the subVO (named DIS subVO DHN)
- configure one DHN (named DLMan subVO DHN) to join it to the subVO as default VO and 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
- 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
- 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
Secure configuration
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.
Apart from the steps required for the non-secure configurations, the following ones are needed:
- configure the Java WS Core container running on each DHN to run with host credentials
- configure the HNM Service hosted on each DHN to run with the security enabled
- install a MyProxy and a VOMS service
- identify a DHN where to install an instance of the Credentials Renewal service (the DHN must host only this service)
- configure each service to use the security
Regarding each gCube service, the steps needed depends 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.
Service credentials
- delegate proxy credentials on the MyProxy for each gCube service stored on the Package Repository
- create an Account on the Credential Renewal instance for each proxy credentials stored
- create a Renewal Task (using the appropriate Account Resource) on the Credentials Renewal instance for each Running Instance of a gCube service
- each running instance has to retrieve its own credentials from the local Delegation Service for the current VRE (extracted from the caller credentials)
Caller credentials
- each running instance has to retrieve the credentials from the context (extracted from the caller credentials)
- each running instance must be invoked by using the Full Delegation modality
Manuelesimi 11:15, 5 December 2007 (EET)