dCache Storage Middleware

Functional description

dCache is a distributed storage solution. It organises storage across computers so the combined storage can be used without the end-users being aware of where their data is stored. They simply see a large amount of storage.

Because end-users do not need to know on which computer their data is stored, it can be migrated from one computer to another without any interruption of service. As a consequence, (new) servers may be added to or taken away from the dCache storage cluster at any time.

dCache supports requesting data from a tertiary storage system. Such systems typically store data on magnetic tapes instead of disks, which must be loaded and unloaded using a tape robot. The main reason for using tertiary storage is the better cost-efficiency, archiving a very large amount of data on rather inexpensive hardware. In turn the access latency for archived data is significantly higher.

dCache also supports many transfer protocols (allowing users to read and write to data). These have a modular deployment, allowing dCache to support expanded capacity by providing additional front-end machines.

Another performance feature of dCache is hot-spot data migration. In this process, dCache will detect when files are requested very often. If this happens, dCache can generate duplicates of the popular files on other computers. This allows the load to be spread across multiple machines, so increasing throughput.

The flow of data within dCache can also be carefully controlled. This is especially important for large sites as chaotic movement of data may lead to suboptimal usage. Instead, incoming and outgoing data can be marshaled so they use designated resources guaranteeing better throughput and improving end-user experience.

dCache provides a comprehensive administrative interface for configuring the dCache instance.

Released version

Current release of dCache server as well as client can be found on the webpage http://www.dcache.org/downloads/1.9/index.shtml

Daemons running

The following daemons need to be running:

For dCache server:

  • /etc/init.d/postgresql

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 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:

Port number Description Component 32768 and 32768 is used by the NFS layer within dCache which is based upon rpc. This service is essential for rpc. NFS 1939 and 33808 is used by portmapper which is also involved in the rpc dependencies of dCache. portmap 34075 is for postmaster listening to requests for the PostgreSQL database for dCache database functionality. Outbound for SRM, PnfsDomain, dCacheDomain and doors; inbound for PostgreSQL server. 33823 is used for internal dCache communication. By default: outbound for all components, inbound for dCache domain. 8443 is the SRM port. See Chapter 15, dCache Storage Resource Manager Inbound for SRM 2288 is used by the web interface to dCache. Inbound for httpdDomain 22223 is used for the dCache admin interface. See the section called “The Admin Interface” Inbound for adminDomain 22125 is used for the dCache dCap protocol. Inbound for dCap door 22128 is used for the dCache GSIdCap . Inbound for GSIdCap door

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

Location of reference documentation for administrators

-- ChristianBernardt - 09-Feb-2011

Edit | Attach | Watch | Print version | History: r7 | r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2011-02-10 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &© 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback