On Thu, Jun 16, 2005 at 06:41:16PM +0100 or thereabouts, owen maroney wrote:
> Hi,
>
> Jamie Kelvin Ferguson wrote:
>
> >Hi Owen,
> >
> >Thanks for that - thats what I'm looking for. I assume all sites
> >with an srm will have an the term 'srm' in there SE type?
>
> I'm afraid not! The GlueSEType field doesn't seem to be used and isn't
> actually defined for most SRMs (in fact, to get the SRM at IC to publish
> properly I had to drop the field completely, so I guess it's deprecated
> even...).
This is correct , the only way around this is run and publish two
SRM end points. We now have dcache.gridpp.rl.ac.uk and I think
dcache-tape.gridpp.rl.ac.uk. Each of them has a different storage
root and published parameters, or rather it should but we have not
got around to that yet.
Steve
>
> The GlueSEName is the reliable field as the LCG replica manage reads
> what follows the ":" to decide which type the SE is ("disk" or "srm_v1"
> seem the only options...).
>
> >Is there a way to tell which type of storage (permanent, durable
> >volitile) sites are offering. I.e. how does a site advertise this
> >information?
>
> There is a field advertising this separately for *each* separate storage
> area (GlueSARoot) GlueSAPolicyFileLifeTime, eg:
>
> ldapsearch -LLL -H ldap://gfe02.hep.ph.ic.ac.uk:2135 -x \
> -b 'GlueSEUniqueID=gfe02.hep.ph.ic.ac.uk,mds-vo-name=local,o=grid' \
> GlueSARoot, GlueSAPolicyFileLifeTime
>
> >Also, Phil might have mentioned something abou this, If a site
> >advertises permanent space and it can be seen from the info. system
> >that it has a capacity of say 5TB. Can it be assumed that all 5TB of
> >storage there is permanent, or is it possible for a site to divide up
> >its type of storage and only a fraction of that 5TB will be permanent
> >space.
>
> I wish I knew the answer to this! How do storage spaces map to SARoot
> map to VOs?
>
> The GlueSARoot advertises only a single storage type. Possible you
> could define different SARoots, with different storage types.
>
> Also, at the moment, the GlueSARoot *seems* to be one-per-VO (and vice
> versa), but there is also a GlueSAAccessControlBaseRule. This would
> indicate that an SARoot might support more than one VO, though I can't
> imagine the use case for it...
>
> cheers,
> Owen M
>
> >On Thu, 16 Jun 2005, owen maroney wrote:
> >
> >
> >>There's also GlueSEType but it isn't really reliable (or even
> >>defined...)
> >>
> >>SRM:
> >>
> >>>[maroney@gfe03 RB]$ ldapsearch -LLL -H
> >>>ldap://lcgbdii02.gridpp.rl.ac.uk:2170 -x -b
> >>>'mds-vo-name=local,o=grid' '(GlueSEName=*:srm*)' | grep
> >>>GlueSEName | wc 14 28 438 [maroney@gfe03 RB]$ ldapsearch
> >>>-LLL -H ldap://lcgbdii02.gridpp.rl.ac.uk:2170 -x -b
> >>>'mds-vo-name=local,o=grid' '(GlueSEName=*:srm*)' | grep
> >>>GlueSEPort | sort | uniq -c 14 GlueSEPort: 8443 [maroney@gfe03
> >>>RB]$ ldapsearch -LLL -H ldap://lcgbdii02.gridpp.rl.ac.uk:2170 -x
> >>>-b 'mds-vo-name=local,o=grid' '(GlueSEName=*:srm*)' | grep
> >>>GlueSEType | sort | uniq -c 2 GlueSEType: srm 2 GlueSEType:
> >>>srm_v1
> >>
> >>Classic SE:
> >>
> >>>[maroney@gfe03 RB]$ ldapsearch -LLL -H
> >>>ldap://lcgbdii02.gridpp.rl.ac.uk:2170 -x -b
> >>>'mds-vo-name=local,o=grid' '(GlueSEName=*:disk)' | grep
> >>>GlueSEName | wc 147 294 4170 [maroney@gfe03 RB]$
> >>>ldapsearch -LLL -H ldap://lcgbdii02.gridpp.rl.ac.uk:2170 -x -b
> >>>'mds-vo-name=local,o=grid' '(GlueSEName=*:disk)' | grep
> >>>GlueSEPort | sort | uniq -c 27 GlueSEPort: 2811 120 GlueSEPort:
> >>>8443 [maroney@gfe03 RB]$ ldapsearch -LLL -H
> >>>ldap://lcgbdii02.gridpp.rl.ac.uk:2170 -x -b
> >>>'mds-vo-name=local,o=grid' '(GlueSEName=*:disk)' | grep
> >>>GlueSEType | sort | uniq -c 117 GlueSEType: disk 1 GlueSEType:
> >>>gsiftp 5 GlueSEType: srm
> >>
> >>
> >>
> >>owen maroney wrote:
> >>
> >>
> >>>owen maroney wrote:
> >>>
> >>>
> >>>>>You seen to have a pretty comprehensive knowledge of srm's.
> >>>>>Do you know of any way, either by querying the info system or
> >>>>>otherwise, to automatically detect if a site is srm or
> >>>>>classic SE?
> >>>>
> >>>>
> >>>>
> >>>>This might help:
> >>>>
> >>>>ldapsearch -H ldap://lcgbdii02.gridpp.rl.ac.uk:2170 -x \ -b
> >>>>'mds-vo-name=local,o=grid' '(GlueSEName=*:srm*)'
> >>>>
> >>>>vs.
> >>>>
> >>>>ldapsearch -H ldap://lcgbdii02.gridpp.rl.ac.uk:2170 -x \ -b
> >>>>'mds-vo-name=local,o=grid' '(GlueSEName=*:disk)'
> >>>
> >>>
> >>>Though this search:
> >>>
> >>>ldapsearch -H ldap://lcgbdii02.gridpp.rl.ac.uk:2170 -x \ -b
> >>>'mds-vo-name=local,o=grid' '(GlueSEName=*:disk) &
> >>>(GlueSEPort=8443)'
> >>>
> >>>does raise the question as to whether GlueSEPort is actually
> >>>used!
> >>>
> >>>? In principle, you ought to be able to run a gsiftp server on
> >>>8443 and an srm on 2811, I'd imagine, *as long as* you advertised
> >>>it correctly. But from the fact that perfectly functional Classic
> >>>SEs are advertising 8443 while actually running their gsiftp
> >>>server on 2811 (I checked a few) seems to show that the
> >>>GlueSEPort isn't being picked up by the lcg replica management
> >>>software. I suspect a yaim default here...
> >>>
> >>
> >>
>
> --
> =======================================================
> Dr O J E Maroney # London Tier 2 Technical Co-ordinator
>
> Tel. (+44)20 759 47802
>
> Imperial College London
> High Energy Physics Department
> The Blackett Laboratory
> Prince Consort Road, London, SW7 2BW
> ====================================
> begin:vcard
> fn:Owen Maroney
> n:Maroney;Owen
> org:Imperial College London;High Energy Physics Department
> adr:Prince Consort Road;;The Blackett Laboratory;London;;SW7 2BW;United Kingdom
> email;internet:[log in to unmask]
> title:London Tier 2 Technical Co-ordinator
> tel;work:(+44)2075947802
> x-mozilla-html:FALSE
> version:2.1
> end:vcard
>
--
Steve Traylen
[log in to unmask]
http://www.gridpp.ac.uk/
|