Load Balancing
Submitted by rehmans on Mon, 01/14/2008 - 5:02am.
Hi All,
I wonder if anybody can offer me some assistance with this, I have a system with the following hardware,
-2 Processors 1.1 GHz each
-2 MB of RAM
-40 GB HDD
-Over 100 MB bandwidth
How do we actually guessticulate the number of simultanoeus calls a Trixbox system would support without a compromise on performance?
Do we have a specific harcoded formula for this ? OR are there any tools out there that help you determine that when you need to add more hardware for expansion?
This might be helpful:
Mon, 01/14/2008 - 7:11am
This might be helpful: http://www.agilevoice.com/f/calculator/voip.htm
It's working the opposite direction than you are, but you can feed it numbers and get a feel.
Also, you aren't going to get many calls with 2MB of memory. :)
there are people that have
Tue, 01/15/2008 - 1:21am
there are people that have quite a few calls with generic asterisk, but as trixbox adds features, it becomes a little bulky. there are several factors that affect that - will the calls be native codecs on each end (no transcoding between different codecs or ptsn>voip)? Are the sound files (MOH / prompts) all encoded in the same codec being used for voice? will there be much prompt / moh playback or queues (uses cpu more when you use it more)?
Its hard to say on your system - assuming you have 2gb ram, I would say that thing would do roughly 75-120 g711 calls with minimal moh and queues, but you wouldnt get that through your internet - so G729 or GSM, probably 60-90 on trixbox 2.4. I would not upgrade a box like that, since more modern servers are a dime a dozen. You can pickup a decent dual Xeon server off ebay for around $400.
voip-info.org has some good examples of native asterisk hardware scaling - keep in mind its "native" asterisk usually stripped down (no freepbx), and the new trixbox 2.4 is a bit 'bulkier' with the new centos and asterisk 1.4.
Thank you people ! I guess
Tue, 01/15/2008 - 4:45am
Thank you people ! I guess that is adequate information. What do I need to replace that would significantly increase the performance of my system along with the number of simultaneous calls ? I know all of them important but how would you prioritize the list of hardware to achieve an optimal quantity and quality ratio?
-Processors
-RAM
-HDD
-Bandwidth
Jahyde what would be your ideal system that would support 300 simultaneous calls assuming that the overheads factor is maximum (native codecs, transcoding, prompt and playback queues etc ) ?
I can definitely beef up my hardware and have a more sophisticated system than this provided I 'm given the right direction.
Looking forward,
Honestly, your most limiting
Tue, 01/15/2008 - 11:40am
Honestly, your most limiting factor on calls (after bandwidth) is going to be trixbox. Specifically freePBX. It doesn't scale very well. It might be just fine at 300 simultaneous calls, but I don't know that for sure, I've never come close to that kind of usage. If it doesn't, you're looking at creating a custom, streamlined dial plan.
One way around this is to have a streamlined box handle the main SIP trunk termination, then have multiple freePBX based boxes trunking to that -- if you really need the features that trixbox provides.
As far as bandwidth goes: if you use g.729 you can certainly get 300 calls out of a 100Mb connection, with some room to spare. But you're not going to be able to do that with ulaw -- it would take over double that bandwidth. Also, this assumes that the only thing that bandwidth is used for is VoIP, and it's all yours -- not shared.
Take everything I say here with a grain of salt, because I've never set up that many channels at once on any box, so I could be way off base.
Well thank you KodaK !
Tue, 01/15/2008 - 12:18pm
Well thank you KodaK ! Supposedly I make a test call that goes through one of my trunks and terminates through a provider to PSTN. How do I actually find out what codec was used between the two parties ?
In a nutshell, If I have to work on codec optimization to improve quality, how would I go about with it in Trixbox ? Any pointers ?
Also, cutting out the bandwidth factor, what hardware resources need to be beefed up to handle the load. From the many posts I see, it is the RAM and the processing speed ?
Ok, taking this one bit at a
Tue, 01/15/2008 - 12:50pm
Ok, taking this one bit at a time:
Quote:
How do I actually find out what codec was used between the two parties ?
The CLI command "sip show channels" will show the codec being used by in use channels. You can use the further commands "sip show channel (call id)" to see more detail for the call, (you can get the call id from the "sip show channels" summary.) This will show in-use codecs for both trunks and endpoints.
If you happen to use an IAX2 trunk instead of a SIP trunk you can use the command "iax2 show channels" instead.
Quote:
In a nutshell, If I have to work on codec optimization to improve quality, how would I go about with it in Trixbox ? Any pointers ?
Buy g.729 licences from Digium. They cost $10US per channel. For 300 channels they may have a bulk discount, I don't know -- you'll have to ask them. Once you have purchased them you can follow the instructions to install them for your version of Asterisk. If you want to do g.729 to the endpoint, and your endpoint supports it then you may not need the licenses. I think the licenses are for g.729 termination/transcoding only. I'm not exactly up to speed on that, though.
To actually use the codec, you can do it system wide or on a per extension basis. To do it system wide you use the sip.conf and iax.conf files, using the deny and allow directives.
For example, to allow g.729 only you would do:
deny=all
allow=g729
Or to just deny ulaw and allow everything else:
deny=ulaw
allow=all
(don't recommend that, though.)
If that's too cost prohibitive, you'll have to ask your provider what codecs they have available, then you can use one of the free low-bandwidth codecs that Asterisk supports. Speex, iLBC and gsm are three that are lower bandwidth. Using those codecs are similar to using g729, except you don't have to install a library or license file. You can see the codecs supported by your system by typing "show codecs" at the CLI.
Keeping transcoding to a minimum will help squeeze out as many calls as possible, so if your phones support g.729 and you can do g.729 from your provider then you won't have to do any transcoding. That will free up your CPU for other tasks.
Quote:
From the many posts I see, it is the RAM and the processing speed ?
Well, yeah, but not all systems are born equal. A good quality server motherboard will beat a desktop motherboard for most server tasks, even using the same CPU and RAM. But good, fast hard drives are important in a server too -- especially if you're going to be doing a lot of voice mail or IVR stuff that would be reading and writing to the HD.
Everyone here swears by supermicro motherboards, so that's a good starting point. As far as hard drives, I'm wondering how the new solid state hard drives would do in an Asterisk system, but leave that kind of experimenting to those of us who can take the pain -- not in a production system. :)
Solid State Drives, Storage, Memory, Network Latency
Tue, 01/15/2008 - 2:33pm
Yes, I would leave the bleeding edge items like solid state hard drives to the experts, as KodaK said. Most attempts at solid state have had issues with limited lifetime depending on numbers of writes. A system that uses voicemail or recording to any extent may wear out those drives very quickly.
I would also go with a drive that caches well. A larger internal cache on a hard drive can have very significan advantages, especially on a bursty write configuration like trixbox. I am personally a fan of SATA on a good controller, but others prefer SCSI. Either way, make sure it is a drive with a large cache.
Faster memory, to some degree, is more important than more memory. Dual Channel DDR2 memory is fairly cheap now. Install it in pairs.
For that many simultaneous calls, network design is a must. Separate your voice traffic physically from your other network traffic by using separate switches. Use a separate Internet connection if you are using VOIP calls from a provider.
Consider multiple servers, depending on how your calls are distributed. Often a few smaller servers (or virtual server instances) can do a better job depending on the installation. If your calls are all coming from one source (VOIP or PRI) it can be difficult. If you have separate sources going to distinct user groups, it can be very helpful.
Thank you KodaK and Greg !
Wed, 01/16/2008 - 8:28am
Thank you KodaK and Greg ! That was indeed great help.
Network design is actually what I am trying to implement. The only reason that I am preferring to have 1-2 powerful machines rather than a cluster of average ones is to avoid too much complexity. However, if the call quantity and call voice quality equilibrium is maintained ideally, then the complexity factor can be compromised on.
Also, the load at my side is pretty unpredictable. That is why I am investing more time into research and analysis. For your better comprehension, lets take a scenario,
We have 200 users and a Trixbox system that is capable of supporting 40-45 simultaneous calls considering all the odds and overheads.
Users = 200
TB System = 2 Processors 1.1 GHz each, 2 MB of RAM, 40 GB HDD, 100 MB Bandwidth
Simultaneous calls = 40
System overhead factor (SOF) = MAXIMUM
Now if I plan to provide my users with features like
• Follow ME (ringing all the phones at the same time on an incoming call)
• Conference Calling
where, every user can add upto 4 numbers (My Network[internal] + Other Network [external] ) for FOLLOW ME
AND
every user can have 4 people in a conference including himself. Adding some topping to the ice cream, I also provide them with controlled access to my box via a web interface with limited functionality so that they can play with all this.
It could be possible that 10 incoming calls to my users might actually simulate 30 -35 outgoing calls as the numbers added in the FOLLOW ME would be ringing too. Moreover, if someone plans to have a conference call during that time, he might have real problems doing so.
The real challenge is to cope with this uncertainty in the most efficient and cost effective manner.
Also, I am assuming that more features you provide on a system, less the number of users/concurrent calls it is going to support. Plausibly it would be doing many other things for them other than supporting voice traffic only. The relation that I see is that number of users a system can support is inversely proportional to number of features you provide them on that system.
Question Time :
Do we have any test utility that may help me determine how much load a TB system can cater by simulating 20-30 test calls, voicemails etc ? Any graphical tool would be great. I've seen munin but I guess that is a bit out of scope for me here.
Since I want to have more and more features other than voice. I was looking to have a dedicated TB server for each feature. For eg for recordings and voicemails, I can use a machine with 250 GB HDD. Similarly, I can have a separate server for Incoming and a separate one for outgoing. I was also thinking that if I can buy a set up with commercial support as long as the cause is served. I'd like to have your suggestions on this one ?
My 2 cents
Wed, 01/16/2008 - 12:54pm
In that configuration, I would be tempted to setup an n+1 scenario. For n departments, divisions, etc., you use that many machines plus one central machine. The central machine (box 0) routes calls in and out of the organization, but houses no extensions itself. This means its disk activity is mostly logging and reading config files.
The extensions are evenly distributed across the other boxes (as few as 2). These boxes are nearly identical except for the actual extensions they house (box a may house 21xx through 25xx, box b having 26xx through 29xx).
Box 0 routes calls to box a or b depending on extension (via internal trunk). Box a routest box b extensions to box b, etc. This may seem overkill, but solves the problem of VOIP trunks that need a single head-end box. Voicemail is effectively split across box a and b, along with follow-me rules.
To ease overhead, make sure that you do not have to transcode, ever. Find the one codec to rule them all and make sure it's the only one accepted on any of the servers.
I am sure there are better solutions, but getting that one up and running should be fairly trivial. You still have box 0 for external call data records, inbound and outbound. IVR should be easy to setup at box 0. The firewall ports will only have to point to box 0.
as noted above, 2-3
Thu, 01/17/2008 - 2:11pm
as noted above, 2-3 moderately powered machines would be better, something fairly well powered, but not overly expensive - As a reference, maybe:
Dual ~2.0ghz Xeon
4 GB DDR (any more is overkill and I have heard doesnt give performance gain on 32 bit kernels)
RAID1 - there are some new SATA drives with 32mb cache, or go for SAS/SCSI
--RAID5 is a complete waste as it overcomplicates, causes longer time to rebuild, and is slower on writes than raid1.--
If you can spec an OEM box like that from Dell or IBM, or if you are into building your own, Supermicro is great - just dont buy anything too cutting edge, there are sometimes driver problems. Check out our Supported Hardware wiki.
A system like that should easily handle 100-150 calls - but again, every system is different and as you scale, minor configuration changes can change how heavily resources are used. Just changing your Queue structure or voice file codec can have a lot of affect on a system with that many calls.
Member Since:
2007-06-24