|
I'm not an expert but :
> 1) client not having to refresh their browser
Not really possible, if the real server has not been detected as down by
an agent (yet) then the director will keep forwarding.
Even commercial NAT balancers that detect connection failures on the way
back will wait for 8 or so failures before assuming the box is down...
My health checks are 5 seconds, and as people click every 3-8 secs I'm
not too worried about a page refresh...
Commercial agents running on the real servers might be quicker at
detecting failure but I doubt it.
> 2) client need not reauthenticate (for https connection)
Eh ? Do you mean re-negotiate keys (which is transparent i..e no refresh
required.)
Or do you mean password authentication which needs to be real server
independent for a cluster (i.e. persistent) no need for dist file system
just use the same DB for all real server authentication.
Regards,
Malcolm.
Leonard Soetedjo wrote:
On Wednesday 30 October 2002 09:58, Peter Mueller wrote:
I think my statement misled you to the problem of healthcheck. My problem
is, since the VIP is doing forwarding, then if the realserver is down but
the healthcheck think it hasn't go down (because the healthcheck checks,
let's say every 500ms), will the connection be lost (i.e. the client need
to refresh the browser)? I'm not an expert in this, so the answer might
be so obvious. Is there anyway (other than changing the healthcheck to
10ms or less, or having the client to refresh the browser) to make the
director forward it to another realserver?
10ms = 0.001s!
You can change the healthchecks to almost any time you want, but 10ms seems
an awfully small number to me. I foresee big problems if you use 10ms; for
example no real services in service...
What application in the world needs health checks of 10ms? Can you
describe your topology for us in detail so we can be helpful? For example,
maybe you use apache + tomcat with mysql backend and all your clients are
java applications over http.
Well, I'm really a beginner in LVS, so 10ms is probably blatantly wrong :)
I'm still evaluating LVS, and have no final topology yet. My current plan is
to have LVS-DR, with the realserver serving Apache with PHP, connected to
mysql backend. All PHP applications reside in a distributed filesystem,
probably coda or intermezzo.
My objective for a realserver outage is:
1) client not having to refresh their browser
2) client need not reauthenticate (for https connection)
What I mean by a realserver outage is (in steps):
1) healthcheck polls that realserver1 is up
2) then immediately after that realserver1 is down
3) director is forwarding new connection to realserver1
What will happen to that connection? Will it be lost (in which case my
objective 1 is not met)? Will it be forwarded to another realserver?
For objective (1), I can't find any other way but to decrease the healthcheck
polling time.
For objective (2), would putting PHP applications in a distributed filesystem
help?
Thank you.
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|
