|
Hello,
On Sun, 29 Oct 2000, Mark wrote:
> > No, existing TCP sesssions can't be redirected but the 2nd and
> > next connections can be scheduled to the new place.
> >
> > client -> real server1 SYN
> > real server1 -> client SYN+ACK
> > client -> real server1 ACK
> > client <-> real server1 DATA (the real server selects
> > new real server)
> > real server1 <-> director inform the director's daemon to
> > update the client's template to
> > the new RS2
> > real server1 <-> client We don't care what happens with
> > the first session, i.e. can remain
> > established. We can't move this
> > session!
> > client -> real server2 SYN
>
> what would be REALLY kewl is if the TCP layer could transfer its session
> state mid session to another real server in co-ordination with the director.
> But thats only in fairy land :)
Not possible with TCP :)
> > content can be found only in one proxy server in the ideal case. Is your
> > case with transparent proxy server or it is not?
>
> My server isnt a proxy server, its a server in its own right.
> heres a brief outline of how the data is organised:
Oh, my mistake, I followed the word "cached" :)
> Server 1->n-> Site 1->n-> Client
> basically 1 server holds many "sites". each "site" can be updated by
> multiple clients. For each site there is a node (real server) which has
> authority on the write locks (mutexes and such).
>
> When a client connects to a real server that dosn't have authority for the
> site the client belongs to, the real server has to talk to the other real
> server that is the authority to get the write locks.
> If the client is directly connected to the real server that has authority on
> the site, all the locks are in process, much faster/lower overhead.
Hm, this is too far from the classic model with the virtual
server where all real servers provide similar functions and we try to
share the load on all servers.
> > In any case, it seems you are trying to provide equal load
> > balancing for the proxy servers. The users voting for the consistent
> > hashing cliam that the equal load will be achieved implicitly and one
> > content will not be loaded <n> times. Of course, the load generated
> > from other processes in the real servers is ignored and if the crond
> > starts the updatedb or another admin from the team uses
> > "tar xf big_file.tar" we only hope this load will not hurt the
> > service.
> >
> I dont require consistant hashing because my server isnt a proxy server, but
> i can see the logic an it makes total sence to me. With an API for the real
> servers to update their load weighting on the director it would become even
> better.
What about the "write locks"? If the load is equal do you need
redirects? Or the redirects are needed from the application level?
> Mark
Regards
--
Julian Anastasov <ja@xxxxxx>
|
