Thanks for the info. It got me digging deeper. I definitely don't want
to screw this one up, but I've got to pinch pennies to get this done, so
don't want to buy anything that would just be nice to have. ...but if I
have to get it, that's what I'll do.
Have any of you seen this?
ftp://download.intel.com/design/intarch/PAPERS/318862.pdf
It's a whitepaper from Intel where they load tested Asterisk on various
Intel Processors. They were trying to show the benefit of compiling
Asterisk using their compiler vs. gcc. It's from January 2008. They used
Astertest as the test base. With a dual Xeon 5335 @ 2GHz (dual quad
cores), and using a gcc compiled Asterisk, they were able to process 673
concurrent calls with GSM to iLBC transcoding and 552 calls with GSM to
Speex transcoding.
Looking at http://cpubenchmark.net, I see a dual Xeon 5335 @ 2GHz has a
Passmark score of 5,095. A more modern single E5-2630 processor has more
than double the score at 10,401.
...and those results were with whatever version of Asterisk was out and
about in January 2008. Would it be 1.4? From what I read here
http://www.voip-info.org/wiki/view/Asterisk+dimensioning, Asterisk 1.6
is 3-4 times better in performance than 1.4, and 1.10 is 2-3 times
faster than 1.8.
Also, keeping in mind while yes I have 800 SIP phones, only 200 will be
active concurrently at peak times based on current call traffic data,
and I'm adding 50% to cover myself and looking to build to support 300
concurrent calls. Finally, throw in the fact the main Asterisk Server
will not be doing any transcoding. The only transcoding will be in the
PRI Gateway server, and with 3 PRI's, I only need the power to transcode
69 concurrent calls from G.711 to G.722.
The next concern is the raw number of actively registered phones. I
guess this is something I don't understand what the repercussions are,
and I know the unknown is always what bites you. What happens? I
wouldn't think that's a lot of open port traffic to worry about?
Thanks Again?
On 5/6/2012 3:19 PM, Mitul Limbani wrote:
For 100% High Availibility and Hot Failover, I would recommend one of
those Red-fone Fonebridges.
Also getting 800 Phones all register on single server is crazy, add a
SIP proxy to distribute load evenly between 2 Ast boxes.
For Wireless you might consider using DECT phones from Snom instead of
std 802.11 based wifi phones. Giving QoS on wifi is a big pain.
Hope that helps,
Regards,
Mitul Limbani
Enterux Solutions
On May 6, 2012 11:34 PM, "Nunya Biznatch" <aster...@ihearbanjos.com
<mailto:aster...@ihearbanjos.com>> wrote:
I'm about to receive approval to design and deploy an
Asterisk-based phone system for my company. I will immediately
have to start writing specifications. I'm working on the hardware
design and the architecture right now. I'd like a second, third,
fourth, 1,000th opinion.
800 SIP phones. All will be G.722. I expect 200 concurrent calls,
with 20% leaving to the outside world. There will be another 200
analog lines that will for the time being remain on the TDM PBX
switch they reside on, and will be whittled down and converted to
SIP as time and attrition allows. These are primarily fax machines
and conference "spider" phones. Those are included in my 200
concurrent calls number. I'm looking to get as close to 5-9's
reliability as I can, with 4-9's mandatory. Proper power filtering
and backup is already available.
Here's what I'm thinking for the architecture:
Server 1: PRI Gateway 1 - Support 2 outside PRI trunks for local
and long distance, plus a third PRI connecting to the existing TDM
PBX.
Server 2: PRI Gateway 2 - Support 1 PRI trunk for local and long
distance with room for another, plus a second PRI connecting to
the existing TDM PBX.
Reason for two PRI Gateways is for redundancy and fail-over, but
processor capabilities is a concern. I expect in about two years
I'll be ready to decommission the TDM PBX, but will be left with
about 80 Analog lines across the multiple buildings on my campus.
I expect I'll end up purchasing channel banks to support the
remaining analog lines, and distribute across the campus using
existing copper plant.
Server 3: Asterisk Master Server
Server 4: Asterisk Slave Server
I'm considering a clustered environment, but I believe a fail-over
solution would be easier to implement in the short term. This
means each system needs to handle all traffic by itself. These
servers will be used for Asterisk and Voice-mail. Conferencing
will be enabled, but I'm not considering it in the build. If I see
conferencing becoming a factor, I will build another server and
offload that service.
Server 5: Boot Server - DHCP, RADIUS, SNTP, DNS, LDAP, FTP, HTTPS,
SNMP, etc...
This service will provide the phone network all the basic
services. This is a stand-alone phone network primarily because it
would be too costly to upgrade the entire data network to support
both voice and data. The phone network will not initially have
Internet Access. This server will be the server all the phones
talk to for pulling their configs.
I'm considering a second Boot Server for redundancy, but since the
phones should store their configs, I'm not seeing this as horribly
critical. Am I smoking something?
Finally, I'll have a Windows-based workstation that will be used
to remote into all the services, for administration, etc...
I need to plan to use FreePBX on all Asterisk Servers, but I don't
intend to install it until I'm in regular MAC maintenance mode.
I have no plans at this time to build out any databases. I just
plan to use whatever Asterisk has. If it ever comes to that, I
would make those separate servers as well.
My goal is to build Asterisk Servers and PRI Gateways capable of
supporting 150% of what I anticipate, which would come out to 300
concurrent calls. Again, all phones will use G.722. The PRI
Gateway servers will do the heavy lifting of converting G.711
traffic from the PRIs to G722, and connect to the Asterisk Servers
via IAX2 trunk.
It's my intention to build each server myself with high-quality
off the shelf components. I'd like all servers to be as close to
identical as possible, as I intend to keep spares on hand to
facilitate quick repair and minimize downtime. I'm considering
RAID 1 + 0 (mirrored and stripped drives) for all servers. I am
considering dual redundant power supplies.
For a processor, I'm currently looking at the i7-3770K @ 3.5GHz or
very similar. Its Passmark compares to the Xeon E5-2630 @ 2.3GHz,
but is half the price.
I have no idea what amount of memory to consider, so I am thinking
8GB per machine.
PCI-E is what I plan for all the cards.
Debian is the Linux flavor
A new network will be deployed using PoE layer-2 managed switches.
Battery backup capable of providing 8 hours will be installed as
required. There will be multiple VLANs in the network as I have
multiple dissimilar offices I need to keep separated from each
other. We will also have 802.11 SIP phones, and will be deploying
a campus-wide WiFi network used only by the phone system. Yes, I
crunched the numbers. This will be significantly cheaper than
upgrading the entire existing data network to support the new
phone system. ...and to be quite honest, I don't trust our network
folks, and know adding that layer of bureaucracy will only
negatively impact the customer experience. I was a network
engineer for a top-three telecom company for many years, so I do
have a point of reference to make those statements.
...yes, I am one guy looking to do all this, with an estimated
completion date of the end of 2013. I'll be building all this out
in addition to my normal "phone guy" job. I've built servers
(hardware and software) for 20+ years, but my Linux Kung Fu is
weak. I'll be learning by doing and know there'll be a lot of
extra hours. The boss is good about training, so I hope I can get
into a good Linux Admin class in addition to dCAP.
So tear it up! What do you think? Does the CPU have the oomph?
What am I missing? What am I overkilling? What would Brian Boitano do?
I appreciate any feedback, and thanks in advance.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
