gLite Workload Management Service

Functional description

The Workload Management System (WMS) comprises a set of grid middleware components responsible for the distribution and management of tasks across grid resources, in such a way that applications are conveniently, efficiently and effectively executed.

The core component of the Workload Management System is the Workload Manager (WM), whose purpose is to accept and satisfy requests for job management coming from its clients. For a computation job there are two main types of request: submission and cancellation.

In particular the meaning of the submission request is to pass the responsibility of the job to the WM. The WM will then pass the job to an appropriate Computing Element for execution, taking into account the requirements and the preferences expressed in the job description. The decision of which resource should be used is the outcome of a matchmaking process between submission requests and available resources.

Released version

gLite WMS has been released for the gLite 3.1 release series. You can find the latest released version together with the installation instructions and repositories at the gLite WMS release pages.

Daemons running

The following daemons need to be running:

For gLite:

• /etc/init.d/gLite

starting the following services:

• /opt/glite/etc/init.d/glite-wms-jc
• /opt/glite/etc/init.d/glite-wms-lm
• /opt/glite/etc/init.d/glite-wms-ice (this starts 2 ICE related processes: /opt/glite/bin/glite-wms-ice-safe and /opt/glite/bin/glite-wms-ice)
• /opt/glite/etc/init.d/glite-wms-wm
• /opt/glite/etc/init.d/glite-proxy-renewald
• /opt/glite/etc/init.d/glite-wms-wmproxy
• /opt/glite/etc/init.d/glite-lb-proxy

For the MySQL server:

• /etc/init.d/mysqld

For globus:

• /etc/init.d/globus-gridftp

For BDII:

• /etc/init.d/bdii

Init scripts and options (start|stop|restart|...)

• /etc/init.d/gLite
• /etc/init.d/globus-gridftp
• /etc/init.d/mysqld

• How to stop/suspend/start/resume the service:
  • For the WMS as a whole:
  • service gLite { start | stop | restart | status | version }

• Each single service has its own start/stop script:
  • /etc/init.d/globus-gridftp { start | stop | restart | status }
  • /opt/glite/etc/init.d/glite-wms-wmproxy { start | stop | restart | status }
  • /opt/glite/etc/init.d/glite-wms-wm { start | stop | restart | status }
  • /opt/glite/etc/init.d/glite-wms-lm { start | stop | restart | status | check }
  • /opt/glite/etc/init.d/glite-wms-jc { start | stop | restart | reload | status | check }
  • /opt/glite/etc/init.d/glite-wms-ice { start | stop | restart | status }
  • /opt/glite/etc/init.d/glite-proxy-renewald { start | stop | restart | status }
  • /opt/glite/etc/init.d/glite-lb-proxy { start | stop | restart | status }
  • /opt/glite/etc/init.d/glite-lb-locallogger { start | stop | restart | status }

Configuration files location with example or template

The configuration files for the WMS service are located in:

• /opt/glite/etc/

and are

• glite_wms.conf
• glite_wms_wmproxy_httpd.conf
• wmproxy_gacl

Corresponding templates are:

• glite_wms.conf.template
• glite_wms_wmproxy_httpd.conf.template
• wmproxy_gacl.template

in the same directory.

Logfile locations (and management) and other useful audit information

The gLite log files can be found in general under

• /var/log/glite

and for the WMS, there are the following log files:

• glite-lb-purger.log
• glite-wms-purgeStorage.log
• glite-wms-wmproxy-purge-proxycache.log
• httpd-wmproxy-access.log
• httpd-wmproxy-errors.log
• jobcontoller_events.log
• lcmaps.log
• logmonitor_events.log
• wmproxy.log
• workload_manager_events.log

The condor log files are located under

• /var/local/condor/log/

and are:

• CollectorLog
• GridmanagerLog.glite
• MasterLog
• MatchLog
• NegotiatorLog
• SchedLog

Open ports

The default ports used by WMS are:

• 2170 : standard BDII
• 2811 : Globus GridFTP control channel
• 7010 : ICE - status notifications from CEMon on CREAM CEs
• 7443 : Apache/GridSite web service (SOAP over https)
• 9618 : condor_collector

• 20000-25000 : GLOBUS_TCP_PORT_RANGE for GridFTP data channels, Condor-G LOWPORT/HIPORT

Possible unit test of the service

Submission of job.

Where is service state held (and can it be rebuilt)

The submitted jobs are first stored in:

• /var/glite/workload_manager/input.fl

once submitted to job controller they are stored in:

• /var/glite/jobcontrol/queue.fl

and for condor, the information can be found in

• /var/local/condor/spool

Cron jobs

The cron jobs can be found in:

• /etc/cron.d/

and are:

• bdii-proxy
• fetch-crl
• glite-lb-purge.cron
• glite-wms-purger.cron
• glite-wms-wmproxy-purge-proxycache.cron
• glite-wms-check-daemons.cron
• lcg-expiregridmapdir
• lcg-mon-job-status-proxy
• wmproxy_logrotate

Security information

• The authZ in WMS is managed by GridFTP and GridSite with two different mechanisms:
  • GridFTP: performed by LCAS
  • GridSite: specified by means of GACL, an XML-based formalism

Access control Mechanism description (authentication & authorization)

Be filled by OSCT team

How to block/ban a user

• The file "/opt/glite/etc/glite_wms_wmproxy.gacl" contains the identities (VO, user, etc) with distinct permissions (exec, read, write, ...) to use the WMS.
• If it is necessary to ban a user/group/VO the site admin must add his/her DN/FQAN and a deny tag, e.g.:

       <entry>
         <person>
           <dn>/C=IT/O=INFN/OU=Personal Certificate/L=DATAMAT DSAGRD/CN=John Doe</dn>
         </person>
         <deny>
           <exec/>
         </deny>
       </entry>

Network Usage

• The WMS runs a SOAP web service, based on Apache/GridSite, over secured and authenticated HTTPS to accept requests for computations. A GridFTP server is in place for managing user sandboxes.
• The WMS connects to a wide variety of services to get/set useful information for job management operations.

Firewall configuration

Be filled by OSCT team

Security recommendations

Be filled by OSCT team

Security incompatibilities

Be filled by OSCT team

List of externals (packages are NOT maintained by Red Hat or by gLite)

Be filled by OSCT team

Other security relevant comments

• Each user sandbox, stored in the filesystem, contains delegated credentials (which can be renewed by MyProxy) together with users input/output data.

Utility scripts

The wms scripts/binaries can be found in

• /opt/glite/bin

and are:

• glite-lb-proxy
• glite-proxy-renew
• glite-proxy-renewd
• glite-wms-get-configuration
• glite-wms-grid-console-shadow
• glite-wms-job_controller
• glite-wms-job-agent
• glite-wms-log_monitor
• glite-wms-pipe-input
• glite-wms-pipe-output
• glite-wms-stats.py
• glite_wms_wmproxy_dirmanager
• glite-wms-wmproxy-gacladmin
• glite-wms-wmproxy-gridmapfile2gacl
• glite-wms-wmproxy-purge-proxycache
• glite_wms_wmproxy_server
• glite-wms-workload_manager

Location of reference documentation for users

• Combined CE and WMS User and Reference Guide
• Workload Management System User and Reference Guide
• WMProxy User Guide
• JDL Attributes Specification (submission via WMS Network Server)
• JDL Attributes Specification (submission via WMS WMProxy)

Location of reference documentation for administrators

• https://twiki.cnaf.infn.it/twiki/bin/view/EgeeJra1It/WMS_guide