[Freeswitch-users] Freeswitch Hardware

Wed Oct 16 05:36:22 MSD 2013

That depends :)

Some people choose to have just one box for their phone system, sat in a
small rack in an office somewhere. Others may have a whole rack inside a
single data center. And some might even have dual site redundancy too.

You need to ask yourself, what is your end goal? Can you handle
downtime/outages, if so how long? Do you have a budget in mind? Are you
going to be building this solution yourself? How many concurrent calls are
you expecting to have within the first 3 months? Do you have the
appropriate IP transit to handle that traffic?

For example, for just phone switch alone you could have two beefy machines
in HA but what happens is the power goes down? Do you have A/B power feeds?
How about if the rack power bar dies? How about if the switching gear for
both racks die because they are on the same aggregate? If the RAID dies,
how long would it take to re-build? If there was damage which caused perm
data loss on both servers, how would you get up and running again quickly?
How long would it take to restore block snapshots of the disk? Would that
backup storage be in the same data center? What if the entire data center
went down? If you have dual data centers, how do you handle IP fail over?
Multi homed BGP isn't going to be instant, DNS fail over sucks, and any
load balancer would introduce a single point of failure. How about if
something in FS HA caused both servers to crash, due to a bug, could you
handle that outage? How about if FS refused to start, would you have
appropriate resources? Does the system need to be running 24/7? Who will
handle the outage alarms at 3am? How will you monitor the system? The
server could be up, but not handling calls properly. This is just a small
subset of things you need to consider when building these solutions, in
reality there are literally hundreds. Where do you draw the line and say
"this is acceptable", this is only something you can decide based on the
product you are selling.

If you are serious about this and want a quick ROI, then you could perhaps
approach consulting at freeswitch.org and ask for architectural design advice,
you will then have a core developer from FS giving you recommendations
based on your requirements. If you are doing this for learning experience,
then you'll need about 1 year to train yourself into being able to support
FS in production (based on my own experience - results may differ).

Hope this helps - perhaps others might chime in with their thoughts as well.

Cal

On Wed, Oct 16, 2013 at 2:00 AM, Andre <andretodd at verizon.net> wrote:

> Do you have any suggestions for a quality way too? This will only be for a
> single bridge call and a LRN dip lookup with media bypass. No transcoding
> or voice mail.****
>
> Thanks****
>
> ** **
>
> ** **
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Cal Leeming
> [Simplicity Media Ltd]
> *Sent:* Tuesday, October 15, 2013 7:41 PM
> *To:* FreeSWITCH Users Help
> *Subject:* Re: [Freeswitch-users] Freeswitch Hardware****
>
> ** **
>
> DISCLAIMER: These suggestions are by no means acceptable if you are
> looking for quality/stability, but if you are looking for a cheap/cheerful
> way to get dialer traffic out the door, then the above should give you some
> ideas. I've written this response on the basis that quality/stability is
> not a goal.****
>
> ** **
>
> Throwing everything onto a single instance of FS is ultimately going to
> cause bottlenecks anyway (for example, the throughput for IVRs/voicemal
> would not be the same as the throughput for a simple user bridge) and no
> amount of hardware would fix that. ****
>
> ** **
>
> You could potentially run multiple FS instances on a beefy box then use
> resource separation with LXC (you're less likely to run into
> performance/quality/jitter issues in comparison with virutalization with
> ESXi)****
>
> ** **
>
> You'd also probably want to take a look at the Sangoma DSP cards such as;*
> ***
>
> http://www.sangoma.com/products/d100-30-400-sessions/****
>
> ** **
>
> For hardware, you'd want something like 2x or 4x SSDs in RAID 1 using a
> decent hardware RAID card (LSI Logic is good), and make sure it's a proper
> RAID card (e.g. PERC H800) and not these crappy soft cards (e.g. PERC
> S100). You could throw a dual quad core at it and put a single CPU in to
> begin with to save on some cost until the point where you need to expand.
> Maybe 32-64GB RAM, which is pretty cheap these days.****
>
>
> You could use consumer grade equipment and save on some cost. The RAM
> would be cheaper as it's non ECC/FB, and the majority of components would
> be cheaper also, but you'd most likely have to put it in a 4U ATX which
> could become costly if you plan on co-location. But be careful, this can
> result in corrupt data being written to disk if the memory goes bad.****
>
> ** **
>
> In terms of throughput, this has been heavily discussed already and there
> are many threads and examples of this on the wiki - use some google-fu and
> you'll find them.****
>
> ** **
>
> The only time you'd need to run multiple profiles in order to boost
> performance would be if you are processing thousands of calls per second
> (because sofia, the SIP parsing library, is single threaded), but as core
> devs have mentioned before you would have to be pushing some crazy numbers
> before this started to become a problem.****
>
> ** **
>
> You'd most likely run into problems when you start running applications
> such as IVR/TTS/Voicemail, and your throughput will depends on exactly what
> you are doing. For example, the throughput for 100% of calls going into a
> voicemail app would not be the same throughput as 100% of calls going
> through a simple user bridge.****
>
> ** **
>
> Hope this helps.****
>
> ** **
>
> Cal****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Oct 15, 2013 at 11:18 PM, Andre <andretodd at verizon.net> wrote:****
>
> Assuming Money is no object and you wanted to get the most CPS/ Ports out
> of one server and you didn’t care that it’s stupid to put all those
> customers on one box.  What type of hardware is recommended for running a
> carrier class traffic for media bypass for short duration dialer traffic?*
> ***
>
>  ****
>
> I’m assuming we want to max out the hardware.****
>
>  ****
>
> Processer, Hard drives, memory etc.?  This would only be for the
> freeswitch server not the database.****
>
>  ****
>
> Would you also have many instances of Freeswitch to use up the server or
> just more profiles or just one profile? Also, how many ports/cps do you
> think one massive beast of a server can handle? 10,000 CPS? More? Less?***
> *
>
>  ****
>
> I know this is a vague question but I’d like to hear what others think?***
> *
>
>  ****
>
>  ****
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org****
>
> ** **
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20131016/4b11e673/attachment-0001.html 