Hi,
Please consider helping out with this testing of Gridftp
redirection as part of your collaboration contributions.
This is a strategically important part of our plan to
simplify DPM and make storage management easier in the
long run.
Thanks,
Oliver.
-------- Forwarded Message --------
Subject: Re: Enabling GridFTP redir on pilot prod sites
(Was: Re: gsiftp service endpoints)
Date: Thu, 7 May 2015 10:04:31 +0200
From: Fabrizio Furano <
[log in to unmask]>
To: Alessandra Forti <
[log in to unmask]>,
Fabrizio Furano <
[log in to unmask]>,
Andrea Sartirana <
[log in to unmask]>,
Alessandro Di Girolamo <
[log in to unmask]>,
Alessandro De Salvo <
[log in to unmask]>
CC: andrea manzi <
[log in to unmask]>,
Tomas Javurek <
[log in to unmask]>,
Oliver Keeble <
[log in to unmask]>,
Andrey Kirianov <
[log in to unmask]>
Hi all,
I saw this morning that dpm-dsi-1.9.5-3 is finally
available
in epel-testing, so I think that we can technically start
the exercise
of enabling the gridftp redirection in a few pilot sites.
Thank you very much again for your availability for this,
and
apologies for the delay. This was due to the fact that we
found
a few issues with the previous version, which have been
fixed and retested.
Please let me know when you are available for starting the
setups.
Of course we will stay tuned and do our best to give
prompt support.
Thank you
Fabrizio
On 04/20/2015 09:33 PM, Alessandra Forti wrote:
Hi,
for the record I'm on holiday until the end of April and
will be unresponsive until then.
cheers
alessandra
On 21/04/2015 00:01, Fabrizio Furano wrote:
Hi Andrea, all,
thank you very much for getting into this.
From our point of view the latest release of dpm-dsi
appeared yesterday
in epel-testing, and we are testing it here today...
work is in progress.
We'll start testing FTS between today and tomorrow,
and if
everything is fine we'll ask you and Alessandra to
evaluate it.
Are you using the latest one from epel-testing ? Does
it seem to work fine with gfal2 ?
Cheers
Fabrizio
On 20/04/15 14:30, Andrea Sartirana wrote:
Hi,
I'm really sorry for the very late reply at this
mail. Here at GRIF_LLR
we were completely overwhelmed by other stuff.
One first feedback:
I've tested srm-less PhEDEx configuration on our
Test-bed site.
It is working somehow fine as you can see in [1]
but there are a couple
of things I would like to understand before adopting
the same conf in prod.
- FTS transfers from LLR storage are just fine but
for incoming
transfers all fail with "DESTINATION file size is 0"
. But then the file
IS on disk and with the good size, so PhEDEx manages
to validate the
transfer. See [2]. This is not very clean. I'd
prefer that the FTS
transfer end up correctly (and that FTS itself
checks the checksum and
size). What am I missing?
- I had to deactivate the PhEDEx checksum validation
for incoming
transfers as the only method I know for getting the
checksum of a DPM
file (w/o re-calculating it each time) was
lcg-get-checksum... but this
is SRM based. This is just my ignorance then. What
can I use to get the
checksum of a DPM file?
Regards,
a.
[1]
https://cmsweb.cern.ch/phedex/test/Activity::QualityPlots?graph=quality_all&entity=link&src_filter=GRIF&dest_filter=&no_mss=true&period=l72h&upto=
[2]
[phedex@llrphedex ~]$ glite-transfer-submit -s
https://lcgfts3.gridpp.rl.ac.uk:8443
srm://node12.datagrid.cea.fr:8446/srm/managerv2?SFN=/dpm/datagrid.cea.fr/home/cms/trivcat/store/PhEDEx_Debug/LoadTest07_GRIFDAPNIA/LoadTest07_GRIFDAPNIA_8F
gsiftp://llrpp01.in2p3.fr:2811//dpm/in2p3.fr/home/cms/trivcat/store/PhEDEx_LoadTest07/LoadTest07_Debug_T2_FR_GRIF_IRFU/T2_FR_GRIF_LLR/21/LoadTest07_GRIF_DAPNIA_8F_EGJ7yAeOIEb3b0lV_21.tmp.4
fc777684-c018-49dd-8ba7-e13eb17449b7
[phedex@llrphedex ~]$ glite-transfer-status -l -s
https://lcgfts3.gridpp.rl.ac.uk:8443
fc777684-c018-49dd-8ba7-e13eb17449b7
Failed
Source:
srm://node12.datagrid.cea.fr:8446/srm/managerv2?SFN=/dpm/datagrid.cea.fr/home/cms/trivcat/store/PhEDEx_Debug/LoadTest07_GRIFDAPNIA/LoadTest07_GRIFDAPNIA_8F
Destination:
gsiftp://llrpp01.in2p3.fr:2811//dpm/in2p3.fr/home/cms/trivcat/store/PhEDEx_LoadTest07/LoadTest07_Debug_T2_FR_GRIF_IRFU/T2_FR_GRIF_LLR/21/LoadTest07_GRIF_DAPNIA_8F_EGJ7yAeOIEb3b0lV_21.tmp.4
State: Failed
Retries: 0
Reason: DESTINATION file size is 0
Duration: 27
[phedex@llrphedex ~]$ rfdir
/dpm/in2p3.fr/home/cms/trivcat/store/PhEDEx_LoadTest07/LoadTest07_Debug_T2_FR_GRIF_IRFU/T2_FR_GRIF_LLR/21/LoadTest07_GRIF_DAPNIA_8F_EGJ7yAeOIEb3b0lV_21.tmp.4
-rw-r--r-- 1 102 106
2471769256 Apr 17 17:13
/dpm/in2p3.fr/home/cms/trivcat/store/PhEDEx_LoadTest07/LoadTest07_Debug_T2_FR_GRIF_IRFU/T2_FR_GRIF_LLR/21/LoadTest07_GRIF_DAPNIA_8F_EGJ7yAeOIEb3b0lV_21.tmp.4
[phedex@llrphedex ~]$
On 30/03/2015 16:37, Fabrizio Furano wrote:
Hi Alessandra,
yes, this was discussed, and there was agreement
on proceeding. The next
steps are:
- we push to epel-prod the last globus6-proof fix
of dpm-dsi
- we refurbish the tutorial to enable the gridftp
redir
that was written a few months ago
- apply it again to our testbed and test
- apply it to two prod sites and test
Andrey, the main responsible for dpm-dsi is here
at CERN for
one month, starting today, so this is the
timescale for the whole
exercise.
For the prod sites, I understood that you and
Andrea Sartirana (added
to CC)
are interested in contributing to these tests,
staying in close contact
with us. That will just be great, thank you very
much.
The reconfig should be easier if the users of the
gridftp service at
the site
can work in SRM-less mode, i.e. pure gridftp. I
understood that CMS can,
ATLAS I don't know. Alessandro(Di Salvo+Girolamo),
do you know if this is
possible for ATLAS ?
Thank you very much
Fabrizio
On 03/30/2015 11:27 AM, Alessandra Forti wrote:
Apologies Friday
I wasn't feeling well was any of this discussed?
thanks
cheers
alessandra
On 24/03/2015 17:47, Fabrizio Furano wrote:
Hi Alessandra,
yes, we have them and we are about to
refurbish them these days.
This discussion is a big coincidence because
the gridftp redir
is one of the main topics of Friday's meeting,
and Andrey is
soon coming for some time to CERN to work on
that.
See you on Friday then
Fabrizio
On 24/03/15 18:39, Alessandra Forti wrote:
Hi,
are there instructions to enable the gsiftp
redirection? Since I'm
working on DPM I might as well do that too.
cheers
alessandra
On 24/03/2015 16:06, Fabrizio Furano wrote:
Hi,
thank you Andrea for the detailed
description.
The bottom line is that:
- DPMs historically have the gsiftp
endpoint in the head node
- It will work if the site firewall allows
it
- The performance will be poor until the
site enables
the "GridFTP redirection", available
since last November
Cheers
Fabrizio
On 24/03/15 16:49, andrea manzi wrote:
Hi
Alessandro,
( i put Fabrizio in cc as well)
every DPM has a gsiftp endpoint together
with SRM
the endpoint is running both on the Head
Node ( which is managing
the
namespace operation ) and on the disk
nodes ( where data are stored)
At the moment in production if you
contact one of the DPM gsiftp
endpoint running on the headnode the
only way to get or write
data is
via RFIO tunnelling to the disk nodes,
which means very bad
performances..
but we have a new feature ( named
gridftp redirection) that noone is
using in production at the moment which
enables the redirection
from the
gsiftp endpoint running from the
headnode to the endpoints
running on
the disk nodes, without using RFIO
tunnelling.
We are discussing in these days to push
for the deployment of this
feature, Fabrizio can also add more
details.
Regarding the discovery of the endpoints
you can query the BDII,
i’m not
an expert but for instance with this
query you get all gsiftp
endpoints
published
ldapsearch -LLL -x -H
ldap://lcg-bdii.cern.ch:2170 -b o=grid
'(&(objectclass=GlueSEAccessProtocol)(GlueSEAccessProtocolType=gsiftp))'
| grep GlueSEAccessProtocolEndpoint
then the result should be filtered to
get only the DPM ones.
last thing, given that now every
operation on the headnode uses
SRM, it
could be that sites have the gsiftp
endpoint on the Headnode behind
firewall
cheers
Andrea
On 24
Mar 2015, at 15:58, Alessandro Di
Girolamo
<[log in to unmask]
<mailto:[log in to unmask]>>
wrote:
Ciao,
one of the steps we need to pursue in
moving on on the
"protocols" is
exploring the gsiftp service endpoints
instead of the SRM ones.
I think that not all the SRM have
behind a gsiftp service endpoint,
but some they do have. I may be wrong,
but DPM endpoints have also
gsiftp endpoints which we can use
"directly". Is this correct?
In case it is, how can we "discover"
these gsiftp endpoints?
Thanks
--- --- --- --- --- --- --- --- ---
--- ---
Alessandro Di Girolamo
CERN IT-SDC
+41764870532 (16-0532)
http://www.cern.ch/Diggi
--- --- --- --- --- --- --- --- ---
--- ---