Context Navigation

TemplateCustomization

Timestamp:: Oct 29, 2008, 8:12:48 PM (17 years ago)
Author:: /O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=Michel Jouvin
Comment:: End of general review

Legend:

: Unmodified
: Added
: Removed
: Modified

Doc/gLite/TemplateCustomization

-              v97
+              v98
 == DPM Configuration ==
 DPM related standard templates require a site template to describe the service site configuration. The variable `DPM_CONFIG_SITE` must contain the name of this template. This template defines the whole DPM configuration, including all disk servers used and is used to configure all the machines part of the DPM configuration.
 On DPM head node, variable `SEDPM_SRM_SERVER` must be defined to `true`. This variable is `false` by default (DPM disk servers).
+DPM-related standard templates require a site template to describe site/SE configuration for DPM. The variable `DPM_CONFIG_SITE` must contain the name of this template. This template defines the whole DPM configuration, including all disk servers used and is used to configure all the machines part of the DPM configuration.
+On DPM head node (in the node profile), variable `SEDPM_SRM_SERVER` must be defined to `true`. This variable is `false` by default (DPM disk servers).
 If you want to use Oracle version of DPM server define the following variable in your machine profile :
 …
 There is no default template provided for DPM configuration. To build your own template, you can look at template [source:templates/trunk/sites/example/site/pro_se_dpm_config.tpl pro_se_dpm_config.tpl] in examples provided with QWG templates.
 Starting with QWG Templates release gLite-3.0.2-9, there is no default password value provided for account used by DPM daemons and for the DB accounts used to access the DPM database. You '''MUST''' provide one in your site configuration. If you forget to do it, you'll get a not very explicit panc error :
+Starting with QWG Templates release gLite-3.0.2-9, there is no default password value provided for account used by DPM daemons and for the DB accounts used to access the DPM database. You '''must''' provide one in your site configuration. If you forget to do it, you'll get a not very explicit panc error :
 {{{
 [pan-compile] *** wrong argument: operator + operand 1: not a property: element
 }}}
 If you want to use a specific VO list on your DPM server and you have several nodes in your DPM configuration (DPM head node + disk servers), you need to write a template defining `VOS` variable (with a non default value) and define variable `NODE_VO_CONFIG` to this template.
+If you want to use a specific VO list on your DPM server and you have several nodes in your DPM configuration (DPM head node + disk servers), you need to write a template defining `VOS` variable (with a non default value) and define variable `NODE_VO_CONFIG` to this template in the profile of DPM nodes (both head node and disk servers).
 === Using non standard port numbers ===
+It is possible to use non standard port numbers for DPM daemons `dpm`, `dpns` and all SRM daemons. To do this, you only need to define the `XXX_PORT` variable corresponding to the service. Look at gLite [source:templates/trunk/grid/glite-3.0.0/defaults/glite.tpl default parameters] to find the exact name of the variable.
+It is possible to use non standard port numbers for DPM daemons `dpm`, `dpns` and all SRM daemons. To do this, you  need to define the `XXX_PORT` variable corresponding to the service in your gLite site parameters. Look at gLite [source:templates/trunk/grid/glite-3.0.0/defaults/glite.tpl default parameters] to find the exact name of the variable.
+''Note: this is not recommended to change the port number used by DPM services in normal circumstances.''
 === Using a non standard account name for dpmmgr ===
 …
-=== Script to publish dynamic information into BDII ===
-It is possible to define and configure a site specific version of the GIP plugin used to publish DPM dynamic information into BDII (space used/free per VO). This is achieved by :
- * Writing a site or cluster specific template providing the script itself and optionally its name and arguments.
- * Define variable `GIP_SCRIPT_DPM_DYNAMIC_CONFIG` to the name of this template.
-The template must define the following variables :
- * `GIP_SCRIPT_DPM_DYNAMIC` : this variable is mandatory and must contain the plugin code (generally a shell or Perl script).
- * `GIP_SCRIPT_DPM_DYNAMIC_NAME` (optional) : name of the plugin. Default to `libexec/lcg-info-dynamic-dpm-alternate` in LCG installation directory (generally `/opt/lcg`).
- * `GIP_SCRIPT_DPM_DYNAMIC_ARGS` (optional) : script arguments. Default : `var/gip/ldif/static-file-SE.ldif` in LCG installation directory (generally `/opt/lcg`).
-''Note : QWG templates for gLite 3.0 provides a modified version of original GIP plugin for DPM working with DPM versions 1.5.10 to 1.6.3 included (standard plugin provided with these versions doesn't work properly with VO dedicated pools). To use it define variable `GIP_SCRIPT_DPM_DYNAMIC_CONFIG` to `glite/se_dpm/server/info_dynamic_voms`.''
 == LFC Configuration ==
+__Base template__ : `machine-types/lfc`.
 LFC related standard templates require a site template to describe the service site configuration. The variable `LFC_CONFIG_SITE` must contain the name of this template.
 …
 }}}
 VOs listed in both lists must be present in `VOS` variable. These 2 variables have no impact on GSI (security) configuration and don't control access to the server. If you want to have `VOS` variable (controlling access to the server) matching the list of VOs supported by the LFC server (either as central or local catalogues), you can add the following definition to your LCF server profile :
+VOs listed in both lists must be present in `VOS` variable. These 2 variables have no impact on GSI (security) configuration and don't control access to the server. If you want to have `VOS` variable (controlling access to the server) matching the list of VOs supported by the LFC server (either as central or local catalogues), you can add the following definition to your LFC server profile :
 {{{
 variable VOS = merge(LFC_CENTRAL_VOS, LFC_LOCAL_VOS);
 …
 === LFC site parameters ===
-__Base template__ : `machine-types/lfc`.
 Normally the only thing really required in this site specific template is the password for LFC user (by default `lfc`) and the DB accounts. Look at standard LFC [source:templates/trunk/glite-3.0.0/glite/lfc/config] configuration template for the syntax.
 …
 It is possible to use non standard port numbers for LFC daemons. To do this, you only need to define the `XXX_PORT` variable corresponding to the service. Look at gLite [source:templates/trunk/grid/glite-3.0.0/defaults/glite.tpl default parameters] to find the exact name of the variable.
+''Note: this is not recommended to change the port number used by LFC services in normal circumstances.''
 === Using a non standard account name for lfcmgr ===
 If you want to use an account name different from `lfcmgr` to run LFC daemons, you need to define variable `DPM_USER` in your site configuration template and provide a template to create this account, based on [source:templates/trunk/grid/gLite-3.0.0/users/lfcmgr.tpl users/lfcmgr.tpl].
-== LCG RB Configuration ==
-''__Note__ : LCG RB is a deprecated service, replaced by gLite WMS. It is available only in gLite 3.0.''
-__Base template__ : `machine-types/rb`.
-After the initial installation of the RB, it is necessary to manually initialize the MySQL database used by the RB using MyQL script provided by YAIM and then rerun NCM components for Quattor to complete the configuration, using the command :
-{{{
-ncm-ncd --configure --all
-}}}
 …
  * `machine-types/wmslb` : a combined WMS/LB node (not recommended).
 WMS and LB are 2 inter-related services : a complete WMS is made of at least one WMS and 1 LB. For scalability reasons, it is recommended to run WMS and LB on several machines : 1 LB should scale to 1M+ jobs per day where 1 WMS scales only to 20 Kjobs per day. Several WMS can share the same LB. Don't expect a combined WMS/LB to scale upper than 10 Kjobs/day.
 WMS and LB site-specific configuration is normally kept in one template, even if they run on several machines, to maintain consistency. Variable `WMS_CONFIG_SITE` must be defined to the name of this template, even for a LB. If you want to use a separate template to configure LB (not recommended), you can also use LB-specific variable, `LB_CONFIG_SITE .
+WMS and LB are 2 inter-related services : a complete WMS is made of at least one WMS and 1 LB. For scalability reasons, it is recommended to run WMS and LB on several machines : 1 LB should scale to 1M+ jobs per day where 1 WMS scales only to 20 Kjobs per day. Several WMS can share the same LB. Don't expect a combined WMS/LB to scale upper than 10 Kjobs/day. And be aware that a WMS needs a lot of memory: 4 GB is the required minimum.
+WMS and LB site-specific configuration is normally kept in one template, even if they run on several machines, to maintain consistency. Variable `WMS_CONFIG_SITE` must be defined to the name of this template, even for a LB. If you want to use a separate template to configure LB (not recommended), you can also use LB-specific variable, `LB_CONFIG_SITE`.
 List of VOs supported by WMS, if not your default list as defined in your [source:templates/trunk/sites/example/site/site/glite/config.tpl site-specific parameters], must be defined in another template that will be included very early in the configuration. Variable `NODE_VO_CONFIG` must be defined to the name of this template. This template generally contains only variable `VOS` definition.
 …
  * `WMS_LB_SERVER_HOST` : define LB used by this WMS. Keep default value on a combined WMS/LB.
 In addition to these variables, there are several variables to tune performances of WMS, in particular its load monitor subsystem. Look at [source:templates/trunk/grid/glite-3.0.0/glite/wms/config.tpl glite/wms/config.tpl] and templates provided with `ncm-wmslb` component for a list of all available variables. Defaults shuld be appropriate, avoid to modify these variables without a clear reason to do that.
+In addition to these variables, there are several variables to tune performances of WMS, in particular its load monitor subsystem. Look at [source:templates/trunk/grid/glite-3.0.0/glite/wms/config.tpl glite/wms/config.tpl] and templates provided with `ncm-wmslb` component for a list of all available variables. Defaults should be appropriate, avoid to modify these variables without a clear reason to do that. In particular avoid to set to high thresholds as it may lead to WMS machine to be very much overloaded and service response time to be very bad.
 === Load Monitor ===
 …
 When configuring BDII on a machine, the following variables can be used (in the machine profile or in a site specific template) to tune the configuration :
  * `BDII_TYPE` : can be `resource`, `site`, `top`. `top` is the default, except if deprecated variable `SITE_BDII` is true.
  * `BDII_SUBSITE` : name of the BDII sub-site. Ignored on any BDII except `site`. Must be empty for the main site BDII (default) or defined to the sub-site name if this is a subsite BDII.
+ * `BDII_SUBSITE` : name of the BDII sub-site. Ignored on any BDII type except `site`. Must be empty for the main site BDII (default) or defined to the sub-site name if this is a subsite BDII.
  * `BDII_SUBSITE_ONLY` (gLite 3.1 only) : if false, allow to run both subsite and site BDII on the same machine. Default : true.
  * `BDII_USE_FCR` : set to false to disable use of FCR (Freedom of Choice) on top-level BDII or to true to force its use on other BDII types.
+ * `BDII_USE_FCR` : set to false to disable use of FCR (Freedom of Choice) on top-level BDII or to true to force its use on other BDII types. This value is ignored if BDII type is not `top`. Default is `true`.
  * `BDII_FCR_URL` : use a non standard source for FCR.
+Starting with QWG templates [milestone:gLite-3.0.2-13 gLite-3.0.2-13], all machine types publishing information into BDII (almost all except WN, UI and disk servers) are using BDII configured as a ''resource BDII'' for this purpose. In addition all these machine types can be configured as a site/subsite BDII by definining appropriate variable into node profile (`BDII_TYPE='site'` and if applicable `BDII_SUBSITE`). This ''combined BDII'' configuration is the default on a LCG CE : define `BDII_TYPE=resource` in CE profile to change it.
+''Note : combined BDII is the default on LCG CE for backward compatibility. But it is highly recommended to run the ''site BDII'' on another machine type.''
+Starting with QWG templates [milestone:gLite-3.0.2-13 gLite-3.0.2-13], all machine types publishing information into BDII (almost all except WN, UI and disk servers) are using a BDII configured as a ''resource BDII'' for this purpose. In addition all these machine types can also be configured as a site/subsite BDII by definining appropriate variable into node profile (`BDII_TYPE='site'` and if applicable `BDII_SUBSITE`).
+''Note : combined BDII used to be the default on LCG CE for backward compatibility but this is no longer the case. It is advised to run site BDII preferably on a dedicated machine. If this is not possible, choose any machine type but the CE as this machine can be very loaded and site BDII may become unresponsive with a lot of side effects.''
 === Configuring BDII URLs on a site BDII ===
 …
 A site BDII aggretates information published by several other BDIIs, typically resource BDIIs or subsite BDIIs. List of resources to aggregate are specicified by variable `BDII_URLS`. This variable is typically defined in site parameters, [source:templates/trunk/sites/example/site/site/glite/config.tpl site/glite/config.tpl], and is ignored on all nodes except a site (or combined) BDII.
 Variable `BDII_URLS` is nlist of URLs corresponding to the Globus MDS or resource BDII URLs to aggregate on the site BDII. Key is a arbitrary name (like `CE`, `DPM1`...) and value is the URL. See [source:templates/trunk/sites/example/site/site/glite/config.tpl site configuration] example.
+Variable `BDII_URLS` is nlist of URLs corresponding to the Globus MDS or resource BDII URLs to aggregate on the site BDII. Key is a arbitrary name (like `CE`, `DPM1`...) but must be unique and value is the URL. See [source:templates/trunk/sites/example/site/site/glite/config.tpl site configuration] example.
 For site using an internal hierarchy of site and subsite BDIIs, it is possible to use `BDII_URLS` for subsite BDIIs and `BDII_URLS_SITE` for site BDII. This allow both to coexist in the same site parameter template (typically [source:templates/trunk/sites/example/site/site/glite/config.tpl site/glite/config.tpl]).
+`BDII_URLS` can contain an entry for a ''combined BDII''. When configuring BDII on this server, this entry will be transparently removed. This allows to move site BDII server to another machine already running a resource BDII without editing `BDII_URLS`.
+''__Note__ : mds-vo-name on a combined BDII is the site or subsite name (not `resource`), even for local services.''
+`BDII_URLS` can contain an entry for a ''combined BDII''. When configuring a BDII on this server, this entry will be transparently removed. This allows to move site BDII server to another machine already running a resource BDII without editing `BDII_URLS`.
 ''__Restriction__ : each BDII in BDII hierarchy '''must''' use a different `mds-vo-name`. Thus it is not possible to use site BDII `mds-vo-name` in `BDII_URLS` or this will be considered as a loop and the entry will be ignored.''
 …
 === Configuring a subsite BDII ===
 It is possible to run a hierarchy of site BDII. This is particularly useful for a site made of several autonomous entities as it allows each subsite to export a unique access point to subsite resources. Each subsite manage the actual configuration of its subsite BDII and all the subsites are then aggregated by the site BDII. GRIF is a site example of such a configuration.
+It is possible to run a hierarchy of site BDII. This is particularly useful for a site made of several autonomous entities as it allows each subsite to export a unique access point to published subsite resources. Each subsite manages the actual configuration of its subsite BDII and all the subsites are then aggregated by the site BDII. GRIF site is an example of such a configuration.
 A subsite BDII is a site BDII where variable `BDII_SUBSITE` has been defined to a non empty value. This value is appended to site name to form the `mds-vo-name` for the subsite.
 …
 It is necessary to define the top-level BDII used by the site. This is done by variable `TOP_BDII_HOST`. This variable replaces deprecated `BDII_HOST`. It has no default.
 ''Note : this is a good practice to use a DNS alias as the top-level BDII name. This allows to change the actual top-level BDII without editing configuration.''
+''Note : this is a good practice to use a DNS alias as the top-level BDII name. This allows to change the actual top-level BDII without editing configuration. This has the advantage that the change is taken into account by running jobs (if there is no DNS caching on the WNs).''
 == MPI Support ==
 …
  * MPI_<flavour>_EXTRAVERSION : Patch number of the package (if needed e.g. MPI_MPICH_EXTRAVERSION="p1")
 By using variables, we ensure that the version published is consistent with the installed RPMs. N.B. this feature is available in QWG revisions >= 2493.
+These variables ensure that the version published is consistent with the installed RPMs.
 …
 __Base template__ : `machine-types/px`.
+A MyProxy server has no specific configuration options, except the VO list defined with `VOS` variable.
 == VOBOX ==
 …
 == RPMs Repositories ==
 [source:templates/trunk/grid/glite-3.0.0/repository/config/glite.tpl repository/config/glite.tpl] describes the RPM repositories used to locate RPMs required by gLite templates. QWG Templates require 5 RPMs repositories plus an optional one. Name given here are the default ones.
+[source:templates/trunk/grid/glite-3.0.0/repository/config/glite.tpl repository/config/glite.tpl] describes the RPM repositories used to locate RPMs required by gLite templates. Default RPM repository configuration in QWG Templates requires 5 RPMs repositories plus an optional one for each gLite version. Name given here are the default ones.
  * `glite_repos_prefix` : gLite RPMs shipped with gLite.
  * ''glite_repos_prefix''`_externals` : RPMs required by gLite and shipped with it but developed and maintained outside gLite.
 …
 `glite_repos_prefix` can be customized without editing the standard template, defining `REPOSITORY_GLITE_PREFIX` variable. If not explicitly defined, it defaults to `glite_3_0_0` for gLite 3.0 and `glite_3_1` for gLite 3.1.
 All required repositories must have an associated template whose name is the same as the repository, in site or cluster specific templates. Optional repository is ignored if its associated template is not present. Each template describe the content of the repositories. When using [wiki:Doc/SCDB/SWRepositories SCDB], this template is maintained with command `ant update.rep.templates`.
+All required repositories must have an associated template whose name is the same as the repository, in site or cluster specific templates. Optional repository is ignored if its associated template is not present. Each template describe the content of the repositories. When using [wiki:Doc/SCDB/SWRepositories SCDB], these templates are maintained with command `ant update.rep.templates`.
 ''Note : it is not required to use this structure and you can edit this template to match your local conventions, if different. When upgrading QWG templates, be sure to revert changes to this template.''
 A template version of these RPMs is distributed as part of examples ([source:templates/trunk/sites/example/repository]). They can be used to compile examples but for deployment of a real configuration, you need to build your own version of these templates. You can build an initial version of these repositories by downloading RPMs from the URL mentioned at top the template examples with `wget` or [source:SCDB/tags/pro/src/utils/misc/rpmUpdates.pl src/utils/misc/rpmUpdates.pl]. Then update the URL at the top of the template examples.
+A template version of these RPM repositories is distributed as part of examples ([source:templates/trunk/sites/example/repository]). They can be used to compile examples but for deployment of a real configuration, you need to build your own version of these templates. You can create an initial version of these repositories by downloading RPMs from the URL mentioned at top the template examples with `wget` or [source:SCDB/tags/pro/src/utils/misc/rpmUpdates.pl src/utils/misc/rpmUpdates.pl]. Then update the URL at the top of the template examples to match your local repositories.