Skip to Content.
Sympa Menu

eic-bnl-comp-l - [Eic-bnl-comp-l] EIC storage, status ...

eic-bnl-comp-l AT lists.bnl.gov

Subject: EIC/BNL Computing discussion

List archive

Chronological Thread  
  • From: Jerome LAURET <jeromel AT bnl.gov>
  • To: Jerome LAURET via Eic-bnl-comp-l <eic-bnl-comp-l AT lists.bnl.gov>
  • Subject: [Eic-bnl-comp-l] EIC storage, status ...
  • Date: Thu, 15 Apr 2021 12:45:43 -0400


Greetings,

As you know, several detector proto-collaboration are starting
and without saying anything on who can/should use what, a discussion
was carried with a few parties as per providing a Pbytes of storage
for incoming work. Xrootd was noted as desired by some but in all,
there are a few logistic issues at BNL I would like to summarize
here.

A reminder - there is 1 PBytes of storage accessible through an
S3 protocol and interface (lustre storage below). "S3" is the
equivalent the Amazon S3 storage ; it allows access read and write
to a global (world accessible) storage using a thin client interface
(and no further requirements). But you need to imagine this as
a "put and get" (good for large dataset upload / downloads or
move data there once not needed on "live" direct access storage).
This is a SINGLE JBOD [just a bunch of disks] and a single server
so there are limitations here ... Xrootd has a documented CEPH
object storage interface but no plugin we can find for S3 alone
(if someone knows of one, please LUK). CEPH works best with
a bunch of servers (not a single one ; emulating many servers
with VMs would cut the performance by 1/3rd). S3 is happy
with a single decent server and would provide the current
JBOD/Luster performance (ideal 3-4 GB/sec).

We discussed the options moving forward with Kolja (and others)

- XrootD does not seem to be a realistically fast solution
(because it would need CEPH for immediate availability,
CEPH would work if multiple servers are available but we
do not have the infrastructure for it)

- Lustre FS (POSIX) would feel like what we have now on gpfs02
for the EIC work

- S3 takes a bit of extra work to learn the interface from a
end-user perspective but has the advantage of allowing seamless
sharing between labs and other places (external and international
collaborators with NO oher work needed)


Through our iterative discussions of use-cases and scope, we came
to the conclusions that the best is for now to either:
- Leave S3, continue to try Xrootd on top [even if development
is needed continue the effort but no ETA]

- Remount the storage Lustre onl,. no S3


The two paths depends on whether we would have remote contributors or not. Feedback from IP6 tend to indicate remote users (i.e. people
from other institutions providing simulation support on external
CPU resources ... they could upload the results securely to S3
from remote and everyone could download).

Further comments welcomed.


--
,,,,,
( o o )
--m---U---m--
Jerome
<he-him-his>




Archive powered by MHonArc 2.6.24.

Top of Page