[asterisk-users] Running Multiple Instances of Asterisk

[Brian Rogan]

On Mon, Sep 25, 2006 at 12:52:43PM -0600, Douglas Garstang wrote:
> > -----Original Message-----
> > From: Brian Rogan [mailto:brogan at syderial.com]
> > Sent: Monday, September 25, 2006 12:40 PM
> > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > Subject: Re: [asterisk-users] Running Multiple Instances of Asterisk
> > 
> > 
> > to use the realtime stuff, and build your own management tools, which
> > would allow you to do this (you could drastically cut the complexity
> > with the right tools).  Even if you could run them together, how
> > would you put everything on the appropriate ports?  How would you deal
> > with multiple instances accessing hardware?
> 
> Realtime is resource intensive, requiring many queries to perform simple lookups. 

Check out the static config option, which just loads everything to
memory at startup (just like the config file method).

http://www.voip-info.org/wiki-Asterisk+RealTime (Extconfig-Static
Configs section)

> > 
> > I'm not convinced that maintaining the config files, binaries 
> > and other
> > components of multiple asterisk's is easier than just building better
> > tools to configure one.
> 
> I am. I look at our configuration which is currently for one customer, and there's already several dozen contexts in order to cover a lot of complexity. Multiply that by a couple of hundred, and I won't want to be administering it!

That's one way to look at it.  The flip side, is you just need to
maintain the same complexity just a bunch of times.  Either way, I
wouldn't want to be administering it ;-), but with good configuration
utilities, you shouldn't have to deal with this complexity at all: you
should have utilities that maintain configuration for you, and if you're
going to do this, realtime is by far the best way to go.

I don't pretend to know what you want in your application, but It seems
clear that YOU NEED GOOD TOOLS to manage it.  If you build these though,
I still don't see what you could do with multiple instances that you
can't do with one.  If you abstract away the dial plan with your tools,
what does it matter that the underlying plan is a complicated mess.

In any case, take that for what its worth.

--Brian