N+N pools can be used for many things in telecom, but not for all.

 

An IVR can as an example be a pool – rather than FS running the IVR server side you connect to a ESL resource and run heavy work client side, maybe through a pool manager. On this level you can even provide failover schemes and fall-back schemes. Speech servers are another excellent candidate for resource pools because speech requires a bit of CPU and it’s very nice to be able to scale up speech capacity by just throwing in more hardware.

 

The challenge comes when you want to do things like ACD on a N+N system. As you agent’s now might be connected to different FS boxes you need a centralised instance to manage – in which case you can use N2 or simply use a database that provide redundancy.

 

Jan

 

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steven Ayre
Sent: 26. mai 2010 12:39
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Questions on Building an application for FreeSWITCH

 

But if that ESL server fails, your entire system goes down. Having N ESL servers means one can fail and the other ESL server allows the cluster to continue running until the failed server is replaced/repaired.

-Steve

On 13 May 2010 21:16, Phillip Jones <pjintheusa@gmail.com> wrote:

What would the advantage of an N to N architecture be though? An ESL server controlling several FS instances has a view of everything that is going on. All calls/conferences etc. A real advantage. That is lost when two ESL servers are run in parallel. State information could be in a DB cluster - but why not have the in-process app access this directly, cutting out the middle man?

How does using ESL make it more scalable and more available with fewer components? I am sure you are correct - I just don't see it.

 

On Thu, May 13, 2010 at 3:15 PM, Kristian Kielhofner <kris@kriskinc.com> wrote:

ESL connecting to a socket actually proves to be more scalable and
more available with fewer components.  Why not have N servers running
your socket app with N servers running FreeSWITCH?

OpenSIPS introduces its own issues with failover and I've yet to see
DNS SRV be the reliability/scalability solution it's made out to be.


On Thu, May 13, 2010 at 3:01 PM, Phillip Jones <pjintheusa@gmail.com> wrote:
> And just a general thought of using ESL vs an in process solution like
> mod_managed, or LUA.
>
> My understanding is, that using a separate server/process does potentially
> give you another point of failure and, if you use a single ESL server
> application to control several FS boxes, potentially a single point of
> failure. It is fairly easy to build a scalable and reliable FS cluster and
> using DNS SRV and OpenSIPS in order to avoid any single points of failure.
> Having independent FS boxes that pull data, but can fail with little impact
> seems attractive to me,

--
Kristian Kielhofner
http://www.astlinux.org
http://blog.krisk.org
http://www.star2star.com
http://www.submityoursip.com
http://www.voalte.com

 


_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org