 |
 |
Dear All, Sam may already have brought this up in the storage meeting, but if not it is perhaps something to check/discuss in the next one. Jeremy Begin forwarded message: Date: 27 May 2015 08:26:51 BST From: Oliver Keeble <[log in to unmask]<mailto:[log in to unmask]>> To: dpm-collaboration <[log in to unmask]<mailto:[log in to unmask]>> Subject: GridFTP redir 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]<mailto:[log in to unmask]>> To: Alessandra Forti <[log in to unmask]<mailto:[log in to unmask]>>, Fabrizio Furano <[log in to unmask]<mailto:[log in to unmask]>>, Andrea Sartirana <[log in to unmask]<mailto:[log in to unmask]>>, Alessandro Di Girolamo <[log in to unmask]<mailto:[log in to unmask]>>, Alessandro De Salvo <[log in to unmask]<mailto:[log in to unmask]>> CC: andrea manzi <[log in to unmask]<mailto:[log in to unmask]>>, Tomas Javurek <[log in to unmask]<mailto:[log in to unmask]>>, Oliver Keeble <[log in to unmask]<mailto:[log in to unmask]>>, Andrey Kirianov <[log in to unmask]<mailto:[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 --- --- --- --- --- --- --- --- --- --- ---