15 Oct
2008
15 Oct
'08
1 a.m.
Iñaki Baz Castillo wrote:
El Martes, 14 de Octubre de 2008, Martin Hoffmann
escribió:
Er, no. You have one load balancer (or, if one isn't enough, a cascade
of them) and a set of proxies which all use the same address. From an IP
perspective, the balancers are routers, ie., they don't change IP
addresses or ports in the packets. All they do is pick one of the
proxies and forward the packet there. The proxies are set up in such a
way that they believe to serve the common IP (an alias on loopback,
usually). Then they just do their usual processing.
Iñaki Baz Castillo wrote:
Thanks for your comment. Please let me understand what you mean:
" the trick is to give them all the same IP and have the balancers work one
layer below"
Do you mean having various LB proxies all of them with same IP? If it, them
all the proxies behind the LB's will always see the same source IP, and will
reply to that IP, so the responses will arrive, at least, to one LB, am I
wrong? 2008/10/13 Jiri Kuthan <jiri(a)iptel.org>rg>:
We do have garden variety proxies behind our load balancers and they are
not aware of the presence of those load balancers. The trick is to give
them all the same IP and have the balancers work one layer below. From
the IP perspective, they are all one. Or something. The thing here is that actually a load-balancer
vendor is free to build
stuff his way -- he is not compelled to build a proxy or B2BUA and go
to some certification authority, he is supposed to build something that
load-balances well. I'm intimately aware of some load-balancers that
are close to being a kind of "transparent proxy", which is just fine:
it doesn't put itself in signaling and it handles routing by state
table.
Well, but what I mean is that the vendor needs, not just a custom LB
which doesn't add "Via" header, but also devices behind the LB (other
proxies or gateways) being not SIP compliant in points 18.2.1 & 18.2.2
of RFC3261. Anyway, I don't understand the purpose and
advantages of this method. If I
understood correctly, it could occur the following:
---------------------------------------------------------------------
proxy1 proxy2 proxy3 proxy4 proxy5
LB1 LB2 LB3
UA
---------------------------------------------------------------------
(all LB's have the same IP (1.1.1.1) in their interface with the proxies
behind).
Forget about LB2 and LB3 for now. There is a setup where you can have
them, but then you need yet another, even dumber balancer in front.
The LB has 1.1.1.1, the proxies have 1.1.1.1 as aliases. So:
- UA sends an INVITE to LB1.
- LB1 forwards the INVITE to proxy1.
Note: It does not change the IP fragment; ie., IP header, UDP or TCP
header and SIP message remain untouched.
- proxy1 sees 1.1.1.1 as source IP so add
"received=1.1.1.1" to top Via (the
top Via can be Via added by LB1 or the Via added by UA if LB's don't add
Via).
- proxy1 sees UA's IP and adds that to the top Via which is UA's Via.
- proxy1 replies to 1.1.1.1.
- proxy1 replies to UA's IP. You can set this up that this either goes
through the LB or directly without the LB seeing the reply. Which of
these depends most likely on how smart your balancer is.
I suppose I didn't understant well since I see no
benefict in this scenario.
The benefit is that you can use regular proxies that are unaware of the
setup. To a certain degree at least -- they do have to share the
location service, of course.
This setup is the easiest to get a redundant and reliable setup if you
use NAT handling nathelper style. In that case, the proxies need to know
the UA's IP and port.
Additionally, you get failover for UDP behind NAT. If proxy1, which was
processing requests from UA1, fails, proxy2 can take over and still talk
to the box behind NAT.
The whole thing, obviously, doesn't work for TCP, but that is an
entirely different can of worms.
Regards,
Martin