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

For BDII:

• /etc/init.d/bdii

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

• How to stop/start/restart the service:
  • /opt/d-cache/bin/dcache { start | stop | restart | status | version }

Configuration files location with example or template

The configuration files for the dCache service are located in:

• /opt/d-cache/share/defaults

and are:

• acl.properties
• ftp.properties
• ssh2Server.properties
• chimera.properties
• hello.properties
• webadmin.properties
• classpath.properties
• paths.properties
• webdav.properties
• dcache.properties
• pool.properties
• xrootd.properties

one additonal file can be found:

• ./config/c3p0.properties

Layout files that define a dCache server site's layout can be found in :

• /opt/d-cache/etc/layouts
  • head.conf
  • pool.conf
  • single.conf

Different templates can be found in:

• /opt/d-cache/etc/dcache.kpwd.template
• /opt/d-cache/etc/jgss_host.conf.template
• /opt/d-cache/etc/pool_path.template
• /opt/d-cache/etc/jgss.conf.template
• /opt/d-cache/etc/keystore.template
• /opt/d-cache/etc/glue-1.3.xml.template

Logfile locations (and management) and other useful audit information

The dCache log files can be found in general under

• /var/log/

there is always one logfile per domain that was defined in the layout file:

• <Domain Name>.log

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 in dCache book on "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 dCache book 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

• gPlazma:
  • Authentication
  • Authorization
  • Mapping (DN <--> UID/GID)
  • Blacklisting
• ACLs:
  • Authorization File-based operation (allow, deny and defer permission handler, NFSv4 ACL)

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

• dCache Book - emi-0
• dCache Book - emi-1

Location of reference documentation for administrators

• dCache Book - emi-0
• dCache Book - emi-1

-- ChristianBernardt - 09-Feb-2011