Difference between revisions of "Procedure Infrastructure Deployment"
Andrea.manzi (Talk | contribs) (→gLite Nodes) |
Andrea.manzi (Talk | contribs) (→gLite Nodes) |
||
| Line 29: | Line 29: | ||
gLite components are in general expected to run on dedicated machines. For example the gLite [http://glite.web.cern.ch/glite/packages/R3.2/sl5_x86_64/deployment/glite-CREAM/glite-CREAM.asp CREAM-CE] or the gLite [http://glite.web.cern.ch/glite/packages/R3.2/sl5_x86_64/deployment/glite-SE_dpm_mysql/glite-SE_dpm_mysql.asp SE] should run in dedicated gLite nodes. However it maybe be possible to have some gLite components co-existing with other gLite/gCube nodes. For example the gLite [http://glite.web.cern.ch/glite/packages/R3.2/sl5_x86_64/deployment/glite-WN/glite-WN.asp WN] can be installed together with other gLite components or even in the same machine of a gCube node. | gLite components are in general expected to run on dedicated machines. For example the gLite [http://glite.web.cern.ch/glite/packages/R3.2/sl5_x86_64/deployment/glite-CREAM/glite-CREAM.asp CREAM-CE] or the gLite [http://glite.web.cern.ch/glite/packages/R3.2/sl5_x86_64/deployment/glite-SE_dpm_mysql/glite-SE_dpm_mysql.asp SE] should run in dedicated gLite nodes. However it maybe be possible to have some gLite components co-existing with other gLite/gCube nodes. For example the gLite [http://glite.web.cern.ch/glite/packages/R3.2/sl5_x86_64/deployment/glite-WN/glite-WN.asp WN] can be installed together with other gLite components or even in the same machine of a gCube node. | ||
| − | The gLite nodes of the D4Science Ecosystem run the following gLite | + | The gLite nodes of the D4Science Ecosystem run the following gLite components: Cream_CE, WN, DPM_SE, WMS, LB, VOMS, MyProxy, and 3 of them ( WMS, VOMS and MyProxy) still run the glite 3.1 version but they are in the process to be upgraded to gLite 3.2 |
Revision as of 10:17, 8 December 2011
Contents
gCube Nodes
The gCube nodes of the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Ecosystem run the gCube software as released by the iMarine WP7 activity. gCube can be deployed in 32 and 64 bits machines and supports several Linux distributions. It has been tested on CERN Scientific Linux, RedHat Enterprise, Ubuntu, and Fedora.
A gCube node of the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Ecosystem is composed by two main constituents:
- A base gHN-distribution container. Managed locally by Site Managers;
- gCube services running on the gHN. Managed remotely by VO Admins and the VRE Managers.
Installation
- gHN - The gHN distribution is available from the gCube website. The Administrator Guide provides detailed information about the gHN installation process.
- gCube Service - gCube services are installed when new VOs/VREs are deployed. Check the VO Creation and VRE Creation procedures.
Upgrade
- gHN - The upgrade of gHNs is based on upgrade plans published in the Resources Upgrade page. Upgrades are announced via the WP5 mailing list.
- gCube - The upgrade of gCube services is based on upgrade plans published in the Resources Upgrade page. Upgrades are announced via the WP5 mailing list.
gLite Nodes
The gLite middleware is composed by several components providing different grid services for distributed computing and storage. The latest stable release is gLite 3.2. This release is certified to run on CERN Scientific Linux 5. All gLite components run on i386 architectures and some also support x86_64.
gLite components are in general expected to run on dedicated machines. For example the gLite CREAM-CE or the gLite SE should run in dedicated gLite nodes. However it maybe be possible to have some gLite components co-existing with other gLite/gCube nodes. For example the gLite WN can be installed together with other gLite components or even in the same machine of a gCube node.
The gLite nodes of the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Ecosystem run the following gLite components: Cream_CE, WN, DPM_SE, WMSSee Workload Management System or Web Mapping Service., LB, VOMSVirtual Organization Membership Service., MyProxy, and 3 of them ( WMSSee Workload Management System or Web Mapping Service., VOMSVirtual Organization Membership Service. and MyProxy) still run the glite 3.1 version but they are in the process to be upgraded to gLite 3.2
Installation
The default installation method for SLC5 packages is the YUM tool. All gLite components have a YUM meta-packages associated.
The configuration of gLite nodes is performed by a set of shell scripts provided by the YAIM framework (the tool doesn't support the installation of gLite). The provided configuration scripts can be used by Site Managers with no need for in-depth knowledge of specific middleware configuration details. They must adapt some configuration files, according to provided examples. The resulting configuration is a default site configuration.
Detailed instructions about the installation of gLite can be found in the gLite 3.2 Installation Guide. iMarine specify configuration examples can be found here.
Upgrade
Upgrades in gLite are done on a per component basis. Each upgrade is associated with one web page containing the details of the upgrade and the list of affected components. All updates are announced via the EGI CIC Portal broadcast tool and are requested on a regular basis. Sites are asked to keep their installations up-to-date with respect to the latest update released.
Detailed instructions about the upgrade of gLite can be found in the gLite 3.2 Installation Guide.
Hadoop Nodes
Due to the variety of installations methods (single node, VM Master/slave, via cloud systems), the Hadoop nodes installation does not follow a predefined procedure.
