Submitted by furano on

The figure below summarizes the different components of the DPM and their basic interactions.
As described above, there are two node types on the server side, both interacting with the client.

Head Node

The entry point for clients, hosting the nameserver and the protocol frontend that has to redirect clients towards disk nodes. The components of the head node contain the logic that drive the decisions about authorizing clients, where to write new files, presenting the content, and many others. It may also host the database backend that gives persistency to metadata.
These daemons can be deployed on a single machine or on multiple machines, depending on the expected load.

APACHE

The well-known HTTP server, using our LCGDM-DAV plugin to speak to the rest of the DMLite framework

DPNS

The DPM nameserver daemon: handles all file and directory related metadata operations for the legacy protocols (SRM, RFIO)

DPM

The DPM daemon: handles file access requests (asynchronous queue management and interaction with the data access daemons)

SRM

Exposes an implementation of the Storage Resource Manager (SRM) interface to clients. In the current DPM there are actually three SRM daemons, each supporting a different version of the SRM specifications (1, 2, 2.2)

XROOTD

A daemon exposing POSIX like high performance file access primitives, according to the xrootd protocol.

 

 

 

Disk Node

Nodes hosting actual data, providing remote access. Each of these nodes will run all data access daemons (rfio, xrootd, gridftp, httpd).

GRIDFTP

A daemon exposing secure FTP file access

RFIO

A daemon exposing POSIX like file access according to the rfio protocol. RFIO is used by the DPM daemon to locate files on the disk servers.

HTTP

Based on apache, provides file access on the disk node via the HTTP protocol. In the disk node it will only accept requests that have been signed by the head node (unless plain http access is desired)

XROOTD

A daemon exposing POSIX like high performance file access primitives, according to the xrootd protocol. In the disk node it will only accept requests that have been signed by the head node.

 

 

Tags