[Asterisk-Users] Asterisk, enterprise edition (New subject)

[Steven Critchfield]

On Sun, 2004-01-04 at 12:53, Nick Bachmann wrote:
> > WipeOut wrote:
> >
> >>>
> >> Asterisk would need some kind of clustering/load balancing ability
> >> (Single IP system image for the IP phones across multiple servers) to
> >> be  truely "Enterprise Class" in terms of both reliability and
> >> scaleability..  Obviously that would not be as relevent for the analog
> >>  hard wired phones unless the channelbanks and T1/E1 lines could be
> >> automatically switched to another server..
> 
> Switching a T1 automagically seems like it would be an easy hack, but it
> wouldn't be needed for customers who had more than one T1 (like, say, most
> Enterprises :-).  The exception to this is people who are muxing their
> internal phones, of course.

Switching a T1 has been discussed, it needs a special adapter. 

> > Anyone that have peeked into Vovidas heartbeat/cluster architecture?
> 
> Yes, I've played with it a bit.  It's pretty simplistic... the clustering
> just keeps several servers in sync with each other.  I suppose that would
> be easy to do with Asterisk, especially if configuration data was stored
> in a RDBMS that could do replication.  Even now, setting up a copy/reload
> routine isn't difficult.

A database doesn't make this easier. I would suggest you look into a
revision control system and the ability to register applications/scripts
to be run on check in of changes. Your benefit here is a quick roll out
on hardware failure, plus roll back. You probably have seen people doing
mailings based on CVS check ins, you could have those trigger a script
on the clients that pulled fresh copies and did a reload. Fairly simple
over all.

> It also seems that if you had a load balancer set up in front of your *
> servers to balance the call requests, you'd have enough clustering to keep
> one failure from taking down the whole system. Since the load balancer
> keeps an affinity table (and monitors to make sure the servers aren't
> going down) all VoIP connections could end up at the same * box once they
> had been allocated, unless a server goes down, in which case the call
> probably gets dropped. Any planned downtime could be made without any
> disruptions, since you could stop the load balancer from allocating any
> more connections to the * box and use 'stop when convenient' to wait for
> all current calls to end.

The problem here is that you do have a single point of failure, the load
balancer. It would be better to have multiple machines that you
selectively placed as primary and backup in your VoIP phones. It isn't
true load balancing, but it does allow you only loose a specific amount
of calls in progress at any time if a machine fails. Calls could then be
picked up and restarted via the other machine. This would give fault
tolerance, and would give the impression of having 5 9's as long as the
failures are sufficiently spaced out. 
-- 
Steven Critchfield <critch at basesys.com>