Print

Print


Hi all,

I think you're all right at some point. I guess it's all about size.

The fact in our site is that we don't know how big our Proof farm will be. 
There's not even money for that!! I've read numbers like "25 cores per 
physicist" but that seems too much to us.
One of our pools can handle two of our eight-core-worker machines 
(theoretically, I don't have the hardware to try it). If we find the money to 
buy two workers per phy, and having 5 people, that would be 10 workers. With 
dCache pools it's not a big deal to spread the data among 5 pools instead of 
2 (with the same reserved space).
About the network connection, 10 workers (8 cores each) and 5 pools add up to 
5 Gbit/s which is far away from the 32 Gbit limit of our Cisco switch.
At the end of times, when we have 6 times that schema, we will reach the 
maximum in networking, and still 30 pools serving data is reasonable.

At that point we will have to start thinking of local storage instead of 
remote. I'm not saying that it's not worth the time to think what's beyond, I 
only say that it's *probably* not for a small Tier2 with some physicists that 
want to analyze data.

Thanks to all for you thoughts, I think this is all very interesting.

Best regards,
Pablo


On Wednesday 20 February 2008 23:54, Andrew Hanushevsky wrote:
> Hi Pablo,
>
> Actually, we (as well as other sites) do exactly what you say -- run
> hundreds of terabytes with multiple access methods (xroot prefered because
> it scales the best). We'e been doing that for years. So, I don't understand
> why you think that it's not about that.
>
> Andy
>
> ----- Original Message -----
> From: "Pablo Fernandez" <[log in to unmask]>
> To: "Fabrizio Furano" <[log in to unmask]>
> Cc: <[log in to unmask]>
> Sent: Wednesday, February 20, 2008 7:05 AM
> Subject: Re: Proof performance with different storage schemas
>
> > Hi Fabrizio,
> >
> > I think (and I won't be wrong) you can have better performance with
> > native xrootd (since you forget about other elements slowing down the
> > system). Maybe
> > for some Tier3 that would be the case (those far away from it's Tier2),
> > but
> > at least for us it's not realistic. We're speaking of hundreds of
> > Terabytes
> > and many access methods (srm, gsiftp...) and I don't think a native
> > xrootd cluster is about that.
> >
> > Regards,
> > Pablo
> >
> > On Wednesday 20 February 2008 13:27, Fabrizio Furano wrote:
> >> Hi Pablo,
> >>
> >>   I see your point. I was mentioning the orthodox xrootd anyway, not the
> >> xrootd door, which from my point of view is just an emulation. After
> >> all, this is the xrootd mailing list :-D
> >>
> >>   For lustre I am not an expert, from a pure functional standpoint you
> >> can put an xrootd server exporting the lustre mountpoints I guess. In
> >> that case you will not go beyond the lustre performance of course.
> >>
> >>   Fabrizio
> >>
> >> Pablo Fernandez ha scritto:
> >> > Thanks!
> >> >
> >> > Unfortunately the xrootd protocol does not work as expected in dcache.
> >> > The idea was to use a conventional SE to store all the data for Tier2
> >> > and
> >> > also serve files to the Tier3... I don't know if Lustre implements an
> >> > xrootd door as well, maybe in a few months I'll try that.
> >> >
> >> > BR/Pablo
> >> >
> >> > On Wednesday 20 February 2008 11:40, Fabrizio Furano wrote:
> >> >> Hi Pablo,
> >> >>
> >> >>   that's very interesting, and I agree completely with your
> >> >> conclusion,
> >> >> i.e. in most cases the lan data access is more efficient and scales
> >> >> better with respect to local disk access. Many times this is not very
> >> >> well understood by people, always striving to keep local files at any
> >> >> cost.
> >> >>
> >> >>   It would be very interesting to have a comparison between the
> >> >> performance in proof between a dcache storage and an analogous xrootd
> >> >> storage, which is the default solution for that. With the same pool
> >> >> of workers of course.
> >> >>
> >> >>   From what I've understood, dcache uses a read ahead mechanism (at
> >> >> the
> >> >> client side), while xrootd uses a scheme which is mixed with informed
> >> >> async prefetching.
> >> >>
> >> >>   Fabrizio
> >> >>
> >> >> Pablo Fernandez ha scritto:
> >> >>> Hi all,
> >> >>>
> >> >>> I would like to share with you some information about my testings of
> >> >>> performance in Proof with different storage schemas.
> >> >>>
> >> >>> http://root.cern.ch/phpBB2/viewtopic.php?t=6236
> >> >>>
> >> >>> I have translated this topic to the Proof Forum since seems to me
> >> >>> more
> >> >>> Proof-related than just xrootd, I hope you don't mind.
> >> >>>
> >> >>> BR/Pablo
> >
> > --
> > =========================================================================
> >===== Pablo Fernandez Fernandez             e-mail:
> > [log in to unmask]
> > Dpto Fisica Teorica. C-XI.
> > Facultad de Ciencias
> > Universidad Autonoma de Madrid.                          Phone: 34 91 497
> > 3976
> > Cantoblanco, 28049 Madrid, Spain.                          Fax: 34 91 497
> > 4086
> > =========================================================================
> >=====

--