------------=_1343126840-12474-19
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.420 (Entity 5.420)
Content-Description: Edinburgh University charitable status
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
------------=_1343126840-12474-19--
=========================================================================
Date: Tue, 24 Jul 2012 17:50:25 +0100
Reply-To: Jens Jensen <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Jens Jensen <[log in to unmask]>
Subject: Agenda for tomorrow
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
1. DPM collaboration discussion
See the mail Wahid sent to the list earlier today.
2. RFIO - what next...? Do we need to look at xroot, too?
3. "Federation" workshop at IN2P3 - who is going?
4. Targets for the next few months - quick discussion.
5. Technology review - suggestions?
6. AOB
... nice and simple!
Cheers
--jens
--
Scanned by iCritical.
=========================================================================
Date: Wed, 25 Jul 2012 08:44:20 +0100
Reply-To: "Christopher J. Walker" <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: "Christopher J. Walker" <[log in to unmask]>
Subject: https access to StoRM
Comments: To: Jens Jensen <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
On 24/07/12 17:50, Jens Jensen wrote:
> 1. DPM collaboration discussion
>
> See the mail Wahid sent to the list earlier today.
>
> 2. RFIO - what next...? Do we need to look at xroot, too?
>
Which reminds me:
I've finally got https access working on our test StoRM SE,
se01.esc.qmul.ac.uk
walker@heppc300:~$ lcg-ls -l srm://se01.esc.qmul.ac.uk/dteam/testfilescs10M
-rw-rw-rw- 1 2 2 10485760 ONLINE
/dteam/testfilescs10M
* Checksum: 70105ddd (ADLER32)
walker@heppc300:~$ lcg-gt
srm://se01.esc.qmul.ac.uk/dteam/testfilescs10M
httpshttps://se01.esc.qmul.ac.uk:8443/storageArea/dteam/testfilescs10M
6734020b-f498-4b10-8073-766e228e08b2
walker@heppc300:~$ curl -k --cert $X509_USER_PROXY
https://se01.esc.qmul.ac.uk:8443/storageArea/dteam/testfilescs10M
>/tmp/httpsfile
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 10.0M 100 10.0M 0 0 2692k 0 0:00:03 0:00:03 --:--:--
3591k
I'm not sure if you can download the file with any certificate, or
whether it has remembered the voms attributes I had.
Chris
=========================================================================
Date: Wed, 25 Jul 2012 08:56:10 +0100
Reply-To: Wahid Bhimji <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Wahid Bhimji <[log in to unmask]>
Subject: Re: https access to StoRM
Comments: To: "Christopher J. Walker" <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID: <[log in to unmask]>
Hi=20
> I've finally got https access working on our test StoRM SE, se01.esc.qmul=
.ac.uk
great.=20
> walker@heppc300:~$ lcg-ls -l srm://se01.esc.qmul.ac.uk/dteam/testfilescs1=
0M
> -rw-rw-rw- 1 2 2 10485760 ONLINE /dteam/testfiles=
cs10M
> * Checksum: 70105ddd (ADLER32)
> walker@heppc300:~$ lcg-gt srm://se01.esc.qmul.ac.uk/dteam/testfilescs10M =
httpshttps://se01.esc.qmul.ac.uk:8443/storageArea/dteam/testfilescs10M
> 6734020b-f498-4b10-8073-766e228e08b2
> walker@heppc300:~$ curl -k --cert $X509_USER_PROXY https://se01.esc.qmul=
.ac.uk:8443/storageArea/dteam/testfilescs10M >/tmp/httpsfile
> % Total % Received % Xferd Average Speed Time Time Time Cu=
rrent
> Dload Upload Total Spent Left Sp=
eed
> 100 10.0M 100 10.0M 0 0 2692k 0 0:00:03 0:00:03 --:--:-- =
3591k
>=20
>=20
> I'm not sure if you can download the file with any certificate, or whethe=
r it has remembered the voms attributes I had.
I can download it with an atlas proxy btw
[jura] ~ > voms-proxy-init -voms atlas
Enter GRID pass phrase:
Your identity: /C=3DUK/O=3DeScience/OU=3DEdinburgh/L=3DNeSC/CN=3Dwahid bhim=
ji
Creating temporary proxy ................................................. =
Done
Contacting vo.racf.bnl.gov:15003 [/DC=3Dorg/DC=3Ddoegrids/OU=3DServices/CN=
=3Dvo.racf.bnl.gov] "atlas" Done
Creating proxy ............................................................=
..................... Done
Your proxy is valid until Wed Jul 25 20:47:07 2012
[jura] ~ > curl -k --cert $X509_USER_PROXY https://se01.esc.qmul.ac.uk:844=
3/storageArea/dteam/testfilescs10M > /tmp/httpsfile
% Total % Received % Xferd Average Speed Time Time Time Cur=
rent
Dload Upload Total Spent Left Spe=
ed
100 10.0M 100 10.0M 0 0 3621k 0 0:00:02 0:00:02 --:--:-- 62=
59k
> Chris
>=20
--=20
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
=========================================================================
Date: Wed, 25 Jul 2012 09:11:26 +0100
Reply-To: "Christopher J. Walker" <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: "Christopher J. Walker" <[log in to unmask]>
Subject: Re: https access to StoRM
Comments: To: Wahid Bhimji <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
On 25/07/12 08:56, Wahid Bhimji wrote:
> Hi
>> I've finally got https access working on our test StoRM SE, se01.esc.qmul.ac.uk
>
> great.
Indeed.
>> I'm not sure if you can download the file with any certificate, or whether it has remembered the voms attributes I had.
>
> I can download it with an atlas proxy btw
Not so great though. I'll ask the StoRM mailing list about this though.
I should add that:
https://se01.esc.qmul.ac.uk:8443/storageArea/dteam/testdir/
is worth a look too ( I had to turn on "listings" here and it only seems
to work for new directories).
Chris
=========================================================================
Date: Wed, 25 Jul 2012 09:20:07 +0100
Reply-To: Jens Jensen <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Jens Jensen <[log in to unmask]>
Subject: Re: https access to StoRM
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
I can open the directory with a browser and view the contents - neat!
Works with a browser that presents a certificate, not with one that doesn't.
I can also read the file with my plain ol' cert which has no attributes
or anything.
-j
On 25/07/2012 09:11, Christopher J. Walker wrote:
> On 25/07/12 08:56, Wahid Bhimji wrote:
>> Hi
>>> I've finally got https access working on our test StoRM SE,
>>> se01.esc.qmul.ac.uk
>>
>> great.
>
> Indeed.
>
>>> I'm not sure if you can download the file with any certificate, or
>>> whether it has remembered the voms attributes I had.
>>
>> I can download it with an atlas proxy btw
>
> Not so great though. I'll ask the StoRM mailing list about this though.
>
> I should add that:
>
> https://se01.esc.qmul.ac.uk:8443/storageArea/dteam/testdir/
>
> is worth a look too ( I had to turn on "listings" here and it only seems
> to work for new directories).
>
> Chris
--
Scanned by iCritical.
=========================================================================
Date: Wed, 25 Jul 2012 09:26:13 +0100
Reply-To: Sam Skipsey <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Sam Skipsey <[log in to unmask]>
Subject: Re: https access to StoRM
Comments: To: Jens Jensen <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Message-ID: <[log in to unmask]>
On 25 July 2012 09:20, Jens Jensen <[log in to unmask]> wrote:
> I can open the directory with a browser and view the contents - neat!
> Works with a browser that presents a certificate, not with one that doesn't.
>
> I can also read the file with my plain ol' cert which has no attributes
> or anything.
>
I'd expect this, if the functionality is anything like the DPM WebDAV
implementation - VOMS is a bit alien to basic https authentication, so
I suspect the "default" StoRM https auth just looks at the certificate
itself.
Sam
> -j
>
> On 25/07/2012 09:11, Christopher J. Walker wrote:
>> On 25/07/12 08:56, Wahid Bhimji wrote:
>>> Hi
>>>> I've finally got https access working on our test StoRM SE,
>>>> se01.esc.qmul.ac.uk
>>>
>>> great.
>>
>> Indeed.
>>
>>>> I'm not sure if you can download the file with any certificate, or
>>>> whether it has remembered the voms attributes I had.
>>>
>>> I can download it with an atlas proxy btw
>>
>> Not so great though. I'll ask the StoRM mailing list about this though.
>>
>> I should add that:
>>
>> https://se01.esc.qmul.ac.uk:8443/storageArea/dteam/testdir/
>>
>> is worth a look too ( I had to turn on "listings" here and it only seems
>> to work for new directories).
>>
>> Chris
>
> --
> Scanned by iCritical.
=========================================================================
Date: Wed, 25 Jul 2012 09:59:55 +0100
Reply-To: Jens Jensen <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Jens Jensen <[log in to unmask]>
Subject: Re: https access to StoRM
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
On 25/07/2012 09:26, Sam Skipsey wrote:
> On 25 July 2012 09:20, Jens Jensen <[log in to unmask]> wrote:
>> I can open the directory with a browser and view the contents - neat!
>> Works with a browser that presents a certificate, not with one that doesn't.
>>
>> I can also read the file with my plain ol' cert which has no attributes
>> or anything.
>>
>
> I'd expect this, if the functionality is anything like the DPM WebDAV
> implementation - VOMS is a bit alien to basic https authentication, so
> I suspect the "default" StoRM https auth just looks at the certificate
> itself.
Actually this makes sense - sort of - doesn't StoRM depend on the
underlying filesystems for most of its security anyway? I seem to
remember some of the early discussions of GPFS.
OTOH you may actually want to protect the file from being read by joe
random certificate user. We may need to figure this out before the VOs
will be keen on us providing https interfaces?
Cheers
-j
--
Scanned by iCritical.
=========================================================================
Date: Wed, 25 Jul 2012 10:54:52 +0100
Reply-To: J Coles <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: J Coles <[log in to unmask]>
Subject: Fwd: Federated storage
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v1244.3)
Message-ID: <[log in to unmask]>
>=20
>=20
> Dear All
>=20
> At the end of the meeting today the federated storage meeting in Lyon =
was mentioned. I can not find any agenda or the specific dates, perhaps =
someone who knows can circulate details.
>=20
> The overall topic came up at the June GDB: =
https://indico.cern.ch/materialDisplay.py?contribId=3D10&materialId=3Dslid=
es&confId=3D155070. There is a WLCG twiki: =
https://twiki.cern.ch/twiki/bin/view/LCG/WLCGStorageFederationsWG.
>=20
> Jeremy
=========================================================================
Date: Wed, 25 Jul 2012 09:56:49 +0000
Reply-To: [log in to unmask]
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Shaun De Witt <[log in to unmask]>
Subject: Re: Federated storage
Comments: To: [log in to unmask]
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
I am attending this already...
-----Original Message-----
From: GRIDPP2: Deployment and support of SRM and local storage management [=
mailto:[log in to unmask]] On Behalf Of J Coles
Sent: 25 July 2012 10:55
To: [log in to unmask]
Subject: Fwd: Federated storage
>=20
>=20
> Dear All
>=20
> At the end of the meeting today the federated storage meeting in Lyon was=
mentioned. I can not find any agenda or the specific dates, perhaps someon=
e who knows can circulate details.
>=20
> The overall topic came up at the June GDB: https://indico.cern.ch/materia=
lDisplay.py?contribId=3D10&materialId=3Dslides&confId=3D155070. There is a =
WLCG twiki: https://twiki.cern.ch/twiki/bin/view/LCG/WLCGStorageFederations=
WG.
>=20
> Jeremy
--
Scanned by iCritical.
=========================================================================
Date: Wed, 25 Jul 2012 11:14:11 +0000
Reply-To: Ewan MacMahon <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Ewan MacMahon <[log in to unmask]>
Subject: Re: https access to StoRM
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
> -----Original Message-----
> From: GRIDPP2: Deployment and support of SRM and local storage management
> [mailto:[log in to unmask]] On Behalf Of Jens Jensen
> Sent: 25 July 2012 10:00
>=20
> OTOH you may actually want to protect the file from being read by joe
> random certificate user. We may need to figure this out before the VOs
> will be keen on us providing https interfaces?
>=20
Would the apache gridsite plugin help here? Doesn't it have some=20
ability to do VO membership based stuff?
Ewan
=========================================================================
Date: Wed, 25 Jul 2012 14:41:38 +0100
Reply-To: Sam Skipsey <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Sam Skipsey <[log in to unmask]>
Subject: Re: https access to StoRM
Comments: To: Ewan MacMahon <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Message-ID: <[log in to unmask]>
On 25 July 2012 12:14, Ewan MacMahon <[log in to unmask]> wrote:
>> -----Original Message-----
>> From: GRIDPP2: Deployment and support of SRM and local storage management
>> [mailto:[log in to unmask]] On Behalf Of Jens Jensen
>> Sent: 25 July 2012 10:00
>>
>> OTOH you may actually want to protect the file from being read by joe
>> random certificate user. We may need to figure this out before the VOs
>> will be keen on us providing https interfaces?
>>
> Would the apache gridsite plugin help here? Doesn't it have some
> ability to do VO membership based stuff?
>
Indeed. DPM's WebDAV implementation uses the gridsite plugin to do
precisely this at present. (My reference to the DPM implementation was
unclear - I was referring to the state of the old http implementation,
not the new WebDAV one).
Sam
> Ewan
=========================================================================
Date: Thu, 26 Jul 2012 08:56:00 +0100
Reply-To: J Coles <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: J Coles <[log in to unmask]>
Subject: Fwd: Rejected posting to [log in to unmask]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v1244.3)
Message-ID: <[log in to unmask]>
> Dear All
>=20
> During the storage meeting yesterday a meeting this afternoon was =
mentioned - one aimed at following up on the DPM community support =
discussion/proposal. A few people outside of those with formal storage =
roles indicated an interest in joining the meeting. For those people, =
please note that we have had to change the time to Friday 27th at 09:00. =
(http://indico.cern.ch/conferenceDisplay.py?confId=3D201768). Sorry for =
any inconvenience.=20
>=20
> regards,
> Jeremy
>=20
>=20
>=20
=========================================================================
Date: Thu, 26 Jul 2012 11:56:33 +0100
Reply-To: J Nebrensky <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: J Nebrensky <[log in to unmask]>
Subject: Re: https access to StoRM
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
Hi,
>> From: GRIDPP2: Deployment and support of SRM and local storage managemen=
t
>> [mailto:[log in to unmask]] On Behalf Of Jens Jensen
>> Sent: 25 July 2012 10:00
>>
>> OTOH you may actually want to protect the file from being read by joe
>> random certificate user. We may need to figure this out before the VOs
>> will be keen on us providing https interfaces?
Of course with the move to making data public, some VOs may be happy to hav=
e anyone (even literally) able to download the data...
Possibly this is my own flawed impression, but there does seem to be some i=
nconsistency between different bits of middleware as to how individuals, VO=
MS roles, VOMS groups, arbitrary VO members, and the world in general are m=
apped on to the user-group-any scheme that underlies the access control. =
=20
Thanks
Henry
--=20
Dr. Henry Nebrensky [log in to unmask]
http://people.brunel.ac.uk/~eesrjjn
"The opossum is a very sophisticated animal.
It doesn't even get up until 5 or 6 p.m."
=========================================================================
Date: Thu, 26 Jul 2012 12:10:35 +0100
Reply-To: Sam Skipsey <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Sam Skipsey <[log in to unmask]>
Subject: Re: https access to StoRM
Comments: To: J Nebrensky <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <[log in to unmask]>
On 26 July 2012 11:56, J Nebrensky <[log in to unmask]> wrote:
> Hi,
>
>>> From: GRIDPP2: Deployment and support of SRM and local storage manageme=
nt
>>> [mailto:[log in to unmask]] On Behalf Of Jens Jensen
>>> Sent: 25 July 2012 10:00
>>>
>>> OTOH you may actually want to protect the file from being read by joe
>>> random certificate user. We may need to figure this out before the VOs
>>> will be keen on us providing https interfaces?
>
> Of course with the move to making data public, some VOs may be happy to h=
ave anyone (even literally) able to download the data...
>
> Possibly this is my own flawed impression, but there does seem to be some=
inconsistency between different bits of middleware as to how individuals, =
VOMS roles, VOMS groups, arbitrary VO members, and the world in general are=
mapped on to the user-group-any scheme that underlies the access control.
>
Yes, this is the case. In particular: things that actually use the
"globus+extended VOMS" mapping approach via LCAS+LCMAPS map users +
roles by either VOMS role or user DN in a site configurable way
(generally, YAIM configures them to map via VOMS role first into a
pool account with a group determined by the VOMS role, and then to
fail down to mapping by DN to whatever the gridmapfile contains).
Things that don't use LCMAPs do their own thing (DPM, for example,
doesn't care about mapping people to unix groups or roles, because
internally it records the actual DN as the username and the VOMS role
as the "group" in the DPM namespace; gridftp, on the other hand, does
do role mapping the LCMAPS way, so there's glue to join these together
when gridftp is used).
Sam
> Thanks
>
> Henry
>
> --
> Dr. Henry Nebrensky [log in to unmask]
> http://people.brunel.ac.uk/~eesrjjn
> "The opossum is a very sophisticated animal.
> It doesn't even get up until 5 or 6 p.m."
=========================================================================
Date: Thu, 26 Jul 2012 12:20:49 +0100
Reply-To: Adam Huffman <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Adam Huffman <[log in to unmask]>
Subject: Benchmarks
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Message-ID: <[log in to unmask]>
Don't think I've posted to the list before, so I should introduce
myself. I've been working with the Imperial HEP group since April,
alongside Simon Fayer.
We're looking at buying some storage, and I wondered whether other
sites had settled on some (more or less) meaningful benchmarks when
evaluating storage hardware? Having looked in the list archives, the
subject seems to have come up several times, without a definitive
answer beyond the usual suspects (fio, bonnie++, iozone etc.).
It may well be that there isn't a definitive answer, but I thought I'd
ask anyway.
Best Wishes,
Adam Huffman
=========================================================================
Date: Thu, 26 Jul 2012 14:04:24 +0100
Reply-To: Wahid Bhimji <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Wahid Bhimji <[log in to unmask]>
Subject: Re: Benchmarks
Comments: To: Adam Huffman <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID: <[log in to unmask]>
Hello=20
Not exactly what you asked but you may want to look at this whitepaper we w=
rote with Dell.
http://www2.ph.ed.ac.uk/~wbhimji/GridStorage/Dell-DPM-LancsEd-Whitepaper201=
2.pdf
It covers DPM - but some of the tests used would work with any storage.=20
In particular in the appendix there are the iozone options we used and also=
the full code of a ROOT script to open files (so a more HEP style analysis=
).
(and you could easily replace the rfcp examples with dccp ones I guess)
We ran it on ATLAS files but in principle it should run on any ROOT files (=
flat "ntuples" trivially and complex CMS objects somehow).=20
If there is something you are unsure on that part I would be happy to (try =
and help) .=20
_Not_ definitive (or necessarily recommended). There is a WLCG working gro=
up of which I think I am supposed to be a member I think that is supposed t=
o come up with a more coherent storage benchmarking approach. We haven't ha=
d any meetings yet though... but the chair (Dirk) did have some useful scri=
pts used at CERN that I will ask him for and forward on (if he sends me the=
m).=20
Cheers for now
Wahid
On 26 Jul 2012, at 12:20, Adam Huffman wrote:
> Don't think I've posted to the list before, so I should introduce
> myself. I've been working with the Imperial HEP group since April,
> alongside Simon Fayer.
>=20
> We're looking at buying some storage, and I wondered whether other
> sites had settled on some (more or less) meaningful benchmarks when
> evaluating storage hardware? Having looked in the list archives, the
> subject seems to have come up several times, without a definitive
> answer beyond the usual suspects (fio, bonnie++, iozone etc.).
>=20
> It may well be that there isn't a definitive answer, but I thought I'd
> ask anyway.
>=20
>=20
> Best Wishes,
> Adam Huffman
>=20
--=20
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
=========================================================================
Date: Thu, 26 Jul 2012 21:52:19 +0100
Reply-To: "Christopher J. Walker" <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: "Christopher J. Walker" <[log in to unmask]>
Subject: Re: https access to StoRM
Comments: To: Sam Skipsey <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
On 25/07/12 14:41, Sam Skipsey wrote:
> On 25 July 2012 12:14, Ewan MacMahon<[log in to unmask]> wrote:
>>> -----Original Message-----
>>> From: GRIDPP2: Deployment and support of SRM and local storage management
>>> [mailto:[log in to unmask]] On Behalf Of Jens Jensen
>>> Sent: 25 July 2012 10:00
>>>
>>> OTOH you may actually want to protect the file from being read by joe
>>> random certificate user. We may need to figure this out before the VOs
>>> will be keen on us providing https interfaces?
>>>
>> Would the apache gridsite plugin help here? Doesn't it have some
>> ability to do VO membership based stuff?
>>
>
> Indeed. DPM's WebDAV implementation uses the gridsite plugin to do
> precisely this at present.
What StoRM does is that the storm user owns files, but gives extended
posix acls to them.
So, for example:
[root@se01 dteam]# pwd
/mnt/lustre_0/storm/dteam
[root@se01 dteam]# getfacl testfilescs10M
# file: testfilescs10M
# owner: storm
# group: storm
user::rw-
group::---
group:tomcat:r--
group:dteam:rw-
mask::rwx
other::---
Which means that users in group dteam can read (and write) the file (and
we probably ought to squash the latter, but that's another problem).
Ignoring StoRM's https support for the moment, could GridSite be used to
give https/webdav read access to files?
Chris
=========================================================================
Date: Fri, 27 Jul 2012 08:20:25 +0100
Reply-To: Sam Skipsey <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Sam Skipsey <[log in to unmask]>
Subject: Re: https access to StoRM
Comments: To: "Christopher J. Walker" <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Message-ID: <[log in to unmask]>
Hi Chris
On 26 July 2012 21:52, Christopher J. Walker <[log in to unmask]> wrote:
> On 25/07/12 14:41, Sam Skipsey wrote:
>>
>> On 25 July 2012 12:14, Ewan MacMahon<[log in to unmask]> wrote:
>>>>
>>>> -----Original Message-----
>>>> From: GRIDPP2: Deployment and support of SRM and local storage
>>>> management
>>>> [mailto:[log in to unmask]] On Behalf Of Jens Jensen
>>>> Sent: 25 July 2012 10:00
>>>>
>>>> OTOH you may actually want to protect the file from being read by joe
>>>> random certificate user. We may need to figure this out before the VOs
>>>> will be keen on us providing https interfaces?
>>>>
>>> Would the apache gridsite plugin help here? Doesn't it have some
>>> ability to do VO membership based stuff?
>>>
>>
>> Indeed. DPM's WebDAV implementation uses the gridsite plugin to do
>> precisely this at present.
>
>
>
> What StoRM does is that the storm user owns files, but gives extended posix
> acls to them.
>
> So, for example:
> [root@se01 dteam]# pwd
> /mnt/lustre_0/storm/dteam
>
> [root@se01 dteam]# getfacl testfilescs10M
> # file: testfilescs10M
> # owner: storm
> # group: storm
> user::rw-
> group::---
> group:tomcat:r--
> group:dteam:rw-
> mask::rwx
> other::---
>
> Which means that users in group dteam can read (and write) the file (and we
> probably ought to squash the latter, but that's another problem).
>
> Ignoring StoRM's https support for the moment, could GridSite be used to
> give https/webdav read access to files?
Assuming you mean "can I just run an apache server that exposed the
lustre filesystem, and use gridsite to handle the authentication", I
don't see why not. I've not thought about this for more than 10
seconds, though.
Sam
>
> Chris
=========================================================================
Date: Fri, 27 Jul 2012 07:36:55 +0000
Reply-To: Andrew Mcnab <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Andrew Mcnab <[log in to unmask]>
Subject: Re: https access to StoRM
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
>> Ignoring StoRM's https support for the moment, could GridSite be used to
>> give https/webdav read access to files?
>=20
>=20
> Assuming you mean "can I just run an apache server that exposed the
> lustre filesystem, and use gridsite to handle the authentication", I
> don't see why not. I've not thought about this for more than 10
> seconds, though.
Yes, it should just work if it looks like a normal filesystem and the
web server user has read access to the files. It will look for .gacl
files in the directory (and then the parents until it finds one) and=20
enforce access control on that basis. The .gacl files can include
references to FQANs.
It's also possible to hard code specific GACLs for areas of the=20
URL space using Apache's LocationMatch directive.
Cheers,
Andrew
--
Dr Andrew McNab - HEP Group - University of Manchester
=========================================================================
Date: Fri, 27 Jul 2012 12:15:30 +0100
Reply-To: Sam Skipsey <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Sam Skipsey <[log in to unmask]>
Subject: DPM Source
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Message-ID: <[log in to unmask]>
As requested, the DPM source can be browsed at the lcgdm trac instance
on the web here:
https://svnweb.cern.ch/trac/lcgdm/browser
and checked out via SVN like so:
svn co http://svn.cern.ch/guest/lcgdm/lcg-dm
(this is the URI for anonymous checkout - this actually gets you all
the lcgdm stuff, not just dpm)
Sam
=========================================================================
Date: Fri, 27 Jul 2012 12:50:38 +0100
Reply-To: Adam Huffman <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Adam Huffman <[log in to unmask]>
Subject: Re: Benchmarks
Comments: To: Wahid Bhimji <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <[log in to unmask]>
Wahid,
Many thanks for this, which is indeed useful. The scripts you mention
would also be helpful, if/when they appear.
If I do have further questions I'll get back to you, if I may.
Cheers,
Adam
On Thu, Jul 26, 2012 at 2:04 PM, Wahid Bhimji
<[log in to unmask]> wrote:
>
> Hello
>
> Not exactly what you asked but you may want to look at this whitepaper we=
wrote with Dell.
>
> http://www2.ph.ed.ac.uk/~wbhimji/GridStorage/Dell-DPM-LancsEd-Whitepaper2=
012.pdf
>
> It covers DPM - but some of the tests used would work with any storage.
> In particular in the appendix there are the iozone options we used and al=
so the full code of a ROOT script to open files (so a more HEP style analys=
is).
>
> (and you could easily replace the rfcp examples with dccp ones I guess)
>
> We ran it on ATLAS files but in principle it should run on any ROOT files=
(flat "ntuples" trivially and complex CMS objects somehow).
> If there is something you are unsure on that part I would be happy to (tr=
y and help) .
>
> _Not_ definitive (or necessarily recommended). There is a WLCG working g=
roup of which I think I am supposed to be a member I think that is supposed=
to come up with a more coherent storage benchmarking approach. We haven't =
had any meetings yet though... but the chair (Dirk) did have some useful sc=
ripts used at CERN that I will ask him for and forward on (if he sends me t=
hem).
>
> Cheers for now
>
> Wahid
>
> On 26 Jul 2012, at 12:20, Adam Huffman wrote:
>
>> Don't think I've posted to the list before, so I should introduce
>> myself. I've been working with the Imperial HEP group since April,
>> alongside Simon Fayer.
>>
>> We're looking at buying some storage, and I wondered whether other
>> sites had settled on some (more or less) meaningful benchmarks when
>> evaluating storage hardware? Having looked in the list archives, the
>> subject seems to have come up several times, without a definitive
>> answer beyond the usual suspects (fio, bonnie++, iozone etc.).
>>
>> It may well be that there isn't a definitive answer, but I thought I'd
>> ask anyway.
>>
>>
>> Best Wishes,
>> Adam Huffman
>>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
=========================================================================
Date: Fri, 27 Jul 2012 17:11:15 +0100
Reply-To: "Christopher J.Walker" <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: "Christopher J.Walker" <[log in to unmask]>
Subject: Re: Benchmarks
Comments: To: Adam Huffman <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
On 27/07/12 12:50, Adam Huffman wrote:
> Wahid,
>
> Many thanks for this, which is indeed useful. The scripts you mention
> would also be helpful, if/when they appear.
>
> If I do have further questions I'll get back to you, if I may.
>
I'll send you a copy of what I wrote about Lustre for CHEP.
It is indeed frustrating that we don't have good benchmarks. I'm not
sure what monitoring other sites do, but I don't think we monitor things
as well as we could to get usage patterns either.
Some thoughts:
From what I've heard, Nearline SAS has much better error correction than
SATA, as well as slightly better performance. It's only marginally more
expensive, so I'd choose that.
How you partition your drives makes a difference. The Lustre manual
recommends RAID6, then suggests that best performance can be obtained by
having 8+2 disks to ensure Lustre writes match the underlying hardware.
You also need to make sure that the partitioning is aligned with the
underlying sector size of the disk.
http://build.whamcloud.com/job/lustre-manual/lastSuccessfulBuild/artifact/lustre_manual.html#configuringstorage
At QMUL, we bought Dell R510s with 12*2TB SATA disks a year and a half
ago, and 3TB NL SAS disks in our last purchase a few months ago. All
with 2 internal disks. Whilst this doesn't give the most efficient
Lustre writes, the logic was that we wanted the capacity and buying 10%
more servers gave us 10% more throughput _and_ 10% more capacity, rather
than spending 10% more on a server (if you see what I mean).
Compared with the solution Wahid outlines in his paper, we can't have
failover, but as the price of an R510 server with 12 disks was roughly
the price of an MD1200 disk array with 12 disks, (and you need to buy a
server as well), we got more storage.
One vendor (Dell probably) suggested that as a rule of thumb, you get
about 50MB/s per disk. That's roughly 600MB/s from our 12 disk server -
which we can get in iozone benchmarks. Ideally, one would probably match
that to the network bandwidth, so a server with a few more disks might
give you a better bang per buck.
The other nice thing about the 12 drive servers is that we think we are
further from the limits of the hardware than one is with the supermicro
36 bay servers - though the latter give more flexibility in how you
carve up the RAID arrays.
Some RAID cards have the ability to cache data with ssd. If we believe
that we are doing large block reads, then we don't expect this will add
much - and that for smaller reads, they should be cached in RAM. It
would however be interesting to know.
Chris
> Cheers,
> Adam
>
> On Thu, Jul 26, 2012 at 2:04 PM, Wahid Bhimji
> <[log in to unmask]> wrote:
>>
>> Hello
>>
>> Not exactly what you asked but you may want to look at this whitepaper we wrote with Dell.
>>
>> http://www2.ph.ed.ac.uk/~wbhimji/GridStorage/Dell-DPM-LancsEd-Whitepaper2012.pdf
>>
>> It covers DPM - but some of the tests used would work with any storage.
>> In particular in the appendix there are the iozone options we used and also the full code of a ROOT script to open files (so a more HEP style analysis).
>>
>> (and you could easily replace the rfcp examples with dccp ones I guess)
>>
>> We ran it on ATLAS files but in principle it should run on any ROOT files (flat "ntuples" trivially and complex CMS objects somehow).
>> If there is something you are unsure on that part I would be happy to (try and help) .
>>
>> _Not_ definitive (or necessarily recommended). There is a WLCG working group of which I think I am supposed to be a member I think that is supposed to come up with a more coherent storage benchmarking approach. We haven't had any meetings yet though... but the chair (Dirk) did have some useful scripts used at CERN that I will ask him for and forward on (if he sends me them).
>>
>> Cheers for now
>>
>> Wahid
>>
>> On 26 Jul 2012, at 12:20, Adam Huffman wrote:
>>
>>> Don't think I've posted to the list before, so I should introduce
>>> myself. I've been working with the Imperial HEP group since April,
>>> alongside Simon Fayer.
>>>
>>> We're looking at buying some storage, and I wondered whether other
>>> sites had settled on some (more or less) meaningful benchmarks when
>>> evaluating storage hardware? Having looked in the list archives, the
>>> subject seems to have come up several times, without a definitive
>>> answer beyond the usual suspects (fio, bonnie++, iozone etc.).
>>>
>>> It may well be that there isn't a definitive answer, but I thought I'd
>>> ask anyway.
>>>
>>>
>>> Best Wishes,
>>> Adam Huffman
>>>
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
=========================================================================
Date: Tue, 31 Jul 2012 18:17:28 +0100
Reply-To: Jens Jensen <[log in to unmask]>
Sender: "GRIDPP2: Deployment and support of SRM and local storage
management" <[log in to unmask]>
From: Jens Jensen <[log in to unmask]>
Subject: Agenda for tomorrow
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
1. snoplus revisited - recommendations for Grid Storage
2. DPM support plans revisited & summarised?
3. Storage benchmarks work - RFIO stress testing, disk stress
testing/performance recommendations.
4. KeyDocs - a number of storage documents look reddish
http://www.gridpp.ac.uk/php/KeyDocs.php
I need to finish on time(ish) because I am interviewing tomorrow from
11. I still haven't read the CVs yet :-(
Thanks!
--jens
--
Scanned by iCritical.
