 |
 |
On Jun 2, 2011, at 1:23 AM, Andrew Hanushevsky wrote: > > > On Wed, 1 Jun 2011, Brian Bockelman wrote: > >> Hi Andy, >> >> Actually, the more I look at it, there's two pieces: >> 1) I don't really understand why it's doing the selections it does now. For example, Nebraska and FNAL are both represented by one manager, yet I see FNAL getting more requests. This makes me think that I'm missing something. >> - So, maybe some more debug statements that I can turn on? > You already have all the debugging that's needed. What you are seeing is fast-dispatch in action. FNAL is quicker on the draw than Nebraska so it's getting more requests. You should see that in the log. FNAL will respond before Nebraska does most of the time. That's a tough one to get around because what is essentially being asked that we ignore latency as a selection parameter. There is one possible way and that is to force the request to wait for a full q-hold period before dispatching so as to maximize the selection list. I will take a look on how easy it would be. We should be able to test this by adjusting upward the cms.delay hold parameter, right? Or does it go to the first server that appears within the hold period? >> 2) I wasn't thinking about an algorithm per-se: more a mechanism to hand-weigh. > The cms already has this mechanism but we never externalized this because we could need a reason to do so. Global federations, of course, change the picture. The built-in mechanism is "share". So, for instance, a site could specify say a number from 1 to 10 that represents the share of requests it wants to receive. 10 would be 100% while 1 is 10% (it's more convenient to do this in increments of 10%). So, all things being equal, dispatches would be altered to favor sites with a large share and demote ones with a smaller share. Now, since this is all relative, if all sites say 10% then that's equivalent to everyone being at 100%. We would only apply this in the meta-manager as it doesn't make sense elsewhere. Would that work for you? > This would work for me. My biggest concern would be the range available; if I want a small T3 site to get 10x less requests than my T2, I can't make the T1 get more requests than my T2. Brian > Andy > > P.S. The share representation is arbitrary so if you have a different idea please let me know. > > > Brian >> >> On Jun 1, 2011, at 2:15 PM, Andrew Hanushevsky wrote: >> >>> Hi Brian, >>> >>> It would be possile (though not until it's implemented). Care to suggest an algorithm that can generally used? >>> >>> Andy >>> >>> On Wed, 1 Jun 2011, Brian Bockelman wrote: >>> >>>> Hi, >>>> >>>> Is it possible to somehow weight servers in the cmsd? For example, we have two sites, UCSD and Nebraska in our redirector. UCSD has two Xrootd servers, directly attached to the regional redirector. Nebraska has 12 xrootd servers and a site manager which in turn is attached to the regional redirector. >>>> >>>> If you round-robin in this setup, UCSD will end up with twice as many redirects as Nebraska. >>>> >>>> Brian >>>> >> >>