VoiceGuide IVR Software Main Page
Jump to content

Vg7 + Load Balancing Phone Line Resources

Recommended Posts

Hi team,

I am evaluating a setup that provides me with an easy scalability path when the demand arises. In essence I would have a:

 

  1. SQL server (separate box)
  2. A load balancing box (I need your expertise to define what is this component)
  3. Servers with Dialogic cards and VoiceGuide v7 licenses

The goal behind this setup would be that if I need more phone lines, I would like to simply add another server with the dialogic cards and the matching VG v7 licenses. Once the server is powered on and connected to the load balancing box (item #2) then calls will be routed to all available phone lines (which are located in separate servers) see attachement.

 

The question is:

  • What component could be used to distribute an outbound job to phone lines located in separate boxes?

Regards,

Raf

post-2074-128277401933_thumb.gif

Share this post


Link to post

One approach is to have a separate database for each server and just load the call into the database of the system which you want to use the make that call. This gives you good control about how many calls each system is making and is simpler to set that up then outbound call database sharing and load balancing.

Share this post


Link to post

That is a good suggestion, thank you!

 

Considering the downsides (please correct me here) if I follow your thinking I will need to either:

a. Get boxes that are beefier than I originally planned in order to run separate dbs in the same machines where the dialogic and VGv7 licenses are installed

-or-

b. if I stick to my original plan to use a simple (& cost effective) hardware configuration to install the dialogic and VGv7 licenses, I will need to get then separate (& more powerful) machines to host the db for each telephony server.

 

It seems that with either of the above schemes, I will still need a centralized DB machine to Marshall the distribution from a master (central) db to the dbs located at each machine. Thus, my costs increases significantly with the additional machines.

 

Perhaps I am bit masochist..:rolleyes:, but, I would like to explore over the steps to create my initial suggested topology, that is, to set up one machine to oversee and manage all of the VG v7 phone lines available at separate machines I own. My voip equipment supplier, as well as, as my broad band provider both are clueless by my request, and suggested to contact the telephony layer provider (VoiceGuide), please any advice along these lines will be most welcomed.

 

Regards,

-r

Share this post


Link to post

You can have one machine hosting the outbound calls database, but have it host a separate database for each of the VoiceGuide machines.

(and the 'marshalling' database as well if you would use one instead of loading calls directly into specific systems' databases).

 

Configurations where multiple VoiceGuide system retrieve calls from one central database are not a common design and are not tested for.

 

In our experience call retrieval from database is not that CPU intensive.

Having SQL Server Express instances on same machine where VG is running would not add that much to the machine's spec requirements. Especially if you have one central marshalling DB server feeding the new call entries on an almost 'as needed' basis, so the number of calls queued in local DBs is low.

Share this post


Link to post

What you are suggesting is definitely doable, but... when I think about the implementation of having a main db (Marshaling db), first query each SQL Express (child db) to see which one is not too busy in order to delegate an outbound job, then distribute an X number of jobs to each child db instance in order to perform the outbound campaigns, to then insert the results to the callque table and the cdrout table of the child instance, which will need TSQL triggers in place in order to dually insert the results of the campaign into the callque and cdrout table at the Marshaling db (which is the central location from which I will generate progress reports)... just sounds a bit hairy, adds a layer of complexity that I did not planned for, and certainly will delay my project quite a bit (with development and test cycles).

 

I was hoping for a simpler solution, along the lines of an abstract telephony layer (ATL) where I could register all of the telephony servers with VG licenses I own, point the ATL to a central db location (at a separate machine) where the callque, cdrout, cdrin, (etc..) tables are found in order to drive the outbound campaigns, I think this would be an awesome project for the Katalina team, thus making VG a highly scalable product... a humble suggestion from someone who admires and likes a lot VoiceGuide (great product!).

 

I am certain that Katalina Technologies have customers with a couple of servers, each server with a few dozen VG licenses. That said, before I embark into the distributed db solution discussed earlier on this threat, figure I ask, do you know how do they manage the distribution of outbound campaigns through their servers?

 

I would love to hear the solutions from other VG forum users who encountered a similar challenge.

 

-r

Share this post


Link to post

The usual architecture for multiple systems is as was described. Calls are usually loaded in larger batches evenly divided between servers and CDR logs etc are moved to central DB when the bath of calls completed, but there is nothing wrong with setting up a system that does this on a call by call basis - but this, as you mention, would require more work to set up.

 

 

Pointing all systems to one central DB is in theory possible right now (just specify the same DB server in Config.xml of all VG systems), but as was mentioned we do not test such setups, and this may not work reliably on some databases. If you want us to look into confirming whether a particular DB is suitable for use as a one central DB then please contact sales@voiceguide.com with your requirements.

Share this post


Link to post

Your suggestion with regards to pointing the config.xml found on the VG systems to a single DB, escaped my mind.. that is an excellent suggestion!

Before contacting the sales team, I am going to see if I can create such scenario with 3 machines (1 Db and 2 VG systems), if that works then we are golden...:)

 

As always thank you for superb support!

 

Regards,

-r

Share this post


Link to post

Before I forget, in order to try the above experiment, if I have four dialogic lines on each machine (total of 8 lines between my two test machines). Am I inferring correctly that in the config.xml, the lines on the second machine will need to be named in sequence, for example the first machine will be dxxxB1C1 to dxxxB1C4, the second machine the lines would be from dxxxB1C5 to dxxxB1C8, correct?

 

regards,

-r

Share this post


Link to post
for example the first machine will be dxxxB1C1 to dxxxB1C4, the second machine the lines would be from dxxxB1C5 to dxxxB1C8, correct?

No.

 

The machines function independently and no machine affects the device naming used on other machines. Dialogic drivers decide what device names are used on each machine and Dialogic drivers on separate machines function independently of each other.

Share this post


Link to post

Please contact sales@voiceguide.com with your requirements. As per previously posted statement:

 

Pointing all systems to one central DB is in theory possible right now (just specify the same DB server in Config.xml of all VG systems), but as was mentioned we do not test such setups, and this may not work reliably on some databases. If you want us to look into confirming whether a particular DB is suitable for use as a one central DB then please contact sales@voiceguide.com with your requirements.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×