Changes between Version 117 and Version 118 of Doc/gLite/TemplateCustomization

Timestamp:

Feb 28, 2009, 11:45:38 PM (17 years ago)

Author:

/O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=Michel Jouvin

Comment:

--

Doc/gLite/TemplateCustomization

@@ -650 +650 @@
 
 
-== gLite WMS and LB ==
+== WMS and LB ==
 
 __Base templates__ :
@@ -663 +663 @@
 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.
 
-Main variables available to customize WMS and LB configuration are :
+Main variables that need to be customized according to your WMS and LB configuration are :
  * `LB_MYSQL_ADMINPWD` : password of MySQL administrator account. There is no default, be sure to define to a non empty string.
  * `LB_TRUSTED_WMS` : a list of DN matching host DN of all WMS allowed to use this LB. May remain empty (default) on a combined WMS/LB.
  * `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 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.
+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 too high thresholds as it may lead to WMS machine to be very much overloaded and service response time to be very bad. Most of the variables are related to WM component of WMS. The main ones are:
+ * `WMS_WM_EXPIRY_PERIOD` : maximum time in seconds to retry match making in case of failure to find a resource compatible with requirements. Default: 2 hours.
+ * `WMS_WM_MATCH_RETRY_PERIOD` : Interval in seconds between 2 match making attempts. Must be less than `WMS_WM_EXPIRY_PERIOD`. Default : 30 mn.
+ * `WMS_WM_BDII_FILTER_MAX_VOS` : maximum number of VOs configured on the WMS to define a LDAP filter when querying the BDII. Default: 10.
+ * `WMS_WMPROXY_SDJ_REQUIREMENT` : match making requirement to add when `ShortDeadlineJob=true` in JDL. The same requirement is added negated for non SDJ jobs. Default should be appropriate (every queue whose name ends with `sdj`).
 
 === Load Monitor ===
@@ -680 +684 @@
  * `WMS_LOAD_MONITOR_MEMORY_USAGE` :  maximum usage (in percent) of virtual memory. Default : 95 (%).
 
+=== Draining a WMS ===
+
+It is sometimes desirable to drain a WMS. When draining a WMS doesn't accept any request to submit new jobs but continues to process already submitted jobs and accepts requests about job status or to cancel a job.
+
+With QWG, a WMS can be drain by defining in its profile the variable `WMS_DRAINED` to `true`. Undefining the variable reenable the WMS. Note that if you drain it manually and reconfigure the WMS with Quattor, it is re-enabled.
+
 == BDII ==