[Asterisk-Users] Re: load balancing 20 asterisk servers

Adam Goryachev mailinglists at websitemanagers.com.au
Wed Feb 2 21:12:26 MST 2005


On Wed, 2005-02-02 at 21:20 -0600, Matthew Boehm wrote:
> I'm trying to stay away from a software based load balancer cause what
> happens if that server fails?
> Its far less likely for a piece of dedicated hardware to fail than an actual
> computer.

There are many ways to accomplish this, and there are many things to be
considered. Here are just a few of my observations/comments on the
various things that have been said to date. Not that I really know much
about any of this, so take what I say with a grain of salt.

You can use DNS to load balance/failover, however, there is a delay.
Some of the delay you can control with various DNS timeout values,
unfortunately, one specific OS (MS Windows) will ignore the timeout, and
cache the value for ever (until reboot, which isn't so long, and I
suppose is the first thing people try when there is a problem). However,
there are probably a number of other configurations/OS's which will also
hold onto the old value for longer than they should, and you can't
control this. This is especially bad if it is an ISP's DNS server or
company wide, or similar. Also, when looking at devices (phones/ATA's)
they are more likely to cut corners, and I would suspect that they are
more likely to keep the old value for too long also.

Depending on how badly this would affect *your* customers is for you to
decide. Also, you could just "blame the customer and say it is their
fault they are offline"...

Having said all that, DNS balancing DOES have it's place in these
things. eg, when you have multiple data centre's (east/west coast for
eg) and one is taken out by meteor strike, then it isn't going to be
back within the next 4 - 24 hours, so you could remove it from DNS, and
people might be offline for some period, but would be back online
eventually. (although they are more likely to want to use the phone
during that first 4 hours :)

Then we have LVS (Linux Virtual Server) and other similar devices (I
think some cisco routers, and probably *BSD/etc) which can do 'smarter'
load balancing based on the various server loads (perhaps bandwidth
loads, or even call quality records for recent calls), and could balance
based on source IP rather than source IP:port. This would solve (I
think) all the discussion about register verses RTP data.

IMHO, I think a really serious deployment (multi-site) would use some
form of both of these options.

As far as reliability:

DNS is designed to be reliable, you just throw lots of tiny boxes in as
many places as possible, and you have reliability. 

LVS is a single point of failure, but probably so is your router/switch.
Consider the case where the LVS *is* the router, use good quality
components for the PC (we should all know about this part on this list),
and you have something that can perform reliably for many years. The
complexity of LVS is much lower than asterisk, so from that respect, it
is going to be much more reliable than not using LVS....

So, you can take things as far as you want, and try to remove all your
SPOF's, but what you think you gain in reliability, you may lose due to
the added complexity. ie, when something goes wrong, nobody has any idea
where to start looking for the problem or how to fix it.

Oh, there is also the money factor... it can quickly get significantly
more expensive for a very small gain. eg, to move from 99.5% uptime to
99.9% is a lot of extra work. It is even worse getting from 99.9% to
99.99%, and much much worse the more 9's you add! (worse == more money,
and much harder).

Regards,
Adam

-- 
 -- 
Adam Goryachev
Website Managers
Ph:  +61 2 8304 0000                        adam at websitemanagers.com.au
Fax: +61 2 9345 4396                        www.websitemanagers.com.au
-- 
 -- 
Adam Goryachev
Website Managers
Ph:  +61 2 8304 0000                        adam at websitemanagers.com.au
Fax: +61 2 9345 4396                        www.websitemanagers.com.au




More information about the asterisk-users mailing list