|
The problem with Squid (or other Reverse Proxy) is that the servers don't
see the real client.
In fact, the ReverseProxy can give the ip address of the real client
in the http fiels X-Forwarded-For,for example,
but it's not transparent for the server.
In that case, you have to configure the server (if you can) to log the ip
address
which is in the field but you could use a product in which you can't and
which needs the ip address.
A Reverse Proxy is not acceptable in this case.
Alain
-----Message d'origine-----
De: andreas.koenig@xxxxxxxx [mailto:andreas.koenig@xxxxxxxx]
Date: vendredi 24 mars 2000 16:40
À: Markus Bernhardt
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Objet: Re: Nice to have features
>>>>> On Fri, 24 Mar 2000 12:21:45 +0000, Markus Bernhardt
<mbernhardt@xxxxxxxxxx> said:
> 2. Load balancing based upon URL
>
> Think about the content of a big internet site. It has html, cgi,
gif,
> video-streams, mp3 ...
> Lets say you need 10 servers. Using normal load balancing means you
have
> to buy 10 quite big == expensive machines. Now it could be economical
> interresting to divide things up.
> Example:
> 2 big machines, which are holding the whole content
> 4 machines, which are holding streaming media. This machines
> don't need to be that powerfull (CPU). They only have to have a big
> I/O-system.
> 4 machines for cgi etc. They need much CPU and Memory, but only
> an small I/O-system.
Why aren't you doing the http related server balancing in a squid
farm? Squid is in most cases a very versatile redirector (and
accelerator), it's only drawback is that it's not as fast as LVS.
My suggestion would be to have 1 LVS, M Squids and N servers doing the
real work. The most important reason behind this is that we want to
avoid bloat on the LVS to make it as fast as possible so it never
becomes the bottleneck. Before adding features to it, one should
evaluate readily available solutions.
Actually, I'm planning to implement such a setup later this year.
Comments?
--
andreas
|
