On Tue, 2003-07-22 at 11:51, James Sparenberg wrote: ... > > > What does cookie persistance do that LVS persistance doesn't? > > > > LVS == map persistence by the SIP:SP > DIP:DP quad. So 10.1.1.1:30800 > > > 10.2.2.2:80 goes to A, but 10.1.1.2:1024 > 10.2.2.2:80 goes to B. If > > 10.1.1.1 is a squid proxy hiding 2500 users and 10.1.1.2 is a single > > workstation, one of two things will happen. One server will get hammered > > with the squid while the other sits idle, or the squid will get balanced > > using SP's and persistence will eventually break, unless the > > intelligence layer is handling it in some other fashion. > > > > cookie == use the above to send the first session, then set a cookie on > > the browser. The SLB then watches for the cookie and directs to web > > servers based on its contents. This means that you're balancing by the > > browser rather than the SIP:SP, so it's much more even. Granted, one > > uesr may be doing more work than the other, but it's more likely to even > > out. > > I can see the cookies working in an environment where users come in take > a reasonably sane amount of time and leave. But what of the user who > does what most do.. browses .... leaves to do something else and comes > back later. Take this scene. > > Box A and B both with a max of 10 users (low numbers make for easier > pictures *grin*) now 20 people come in. 10 are given A cookies 10 are > given B cookies. So far so good. 15 leave and don't come back. 5 with > cookies for A leave their browser open and do something else. Now 12 > more come in new 6 go to A 6 to B and at the same time the 5 people with > A cookies decide to go to the next window. So here A has 11 and B 6 > with A overloaded. The solution I guess would be to give the cookies a > short TTL so that the original remaining 5 get new cookies when they > restart. In this case you've moved the session management from the load > balancer to the cookie manager. I'd also be curious as to what happens > when the five with cookies for A come back and the box A has died. > Maybe I'm slow... (I don't get much sleep of late could be the problem.) > but it doesn't look right somehow. IF however it's working... no > problem. >
That's the idea -- as in all other things IT, it's a matter of trade-offs. > The only other thing I'm curious on is load levels. I was talking with > some hardware oriented people last night one of the points was load > levels of CPU's and hardware. One of them pointed out that he was doing > some research on underloaded servers and how it affects performance. > Meaning too many servers and each one not having enough work to stay > within it's "power curve". His point being that with a number of energy > saving features that are built into hardware these days if you drop the > load too low then the box is constantly having to "re-awaken" various > hardware components and it actually increases the time to respond (TTR) > to various events. When most people see an increase in TTR then the > reaction is.. "We need more servers". Which actually is counter > productive. What he is advocating is a situation where if say you have > 3 servers, 2 are active and 1 is in hot standby. As long as load on the > first two is below 90% 3 stays inactive. If the combined load on the > first 2 is below 90% of capacity of 1 box then you have 2 in hot standby > and 1 in active use. The concept is to maintain the boxes either in a > state where hardware never tries to go to sleep, or totally asleep. > Should be intresting. > > James > Now that is an interesting thread -- I see a lot of servers poking along at very low utilization, particularly web servers, while the servers they depend on are being hammered because the required upgrades are too expensive. -- Jack Coates Monkeynoodle: A Scientific Venture...
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
