Chapter 2. Preparing a System for
Asterisk
Very early on, I knew
that someday in some "perfect"
future out there over the horizon, it would be
commonplace for computers to handle all of the
necessary processing functionality internally,
making the necessary external hardware to connect up
to telecom interfaces VERY inexpensive
and in some cases trivial.
Jim Dixon, "The History of Zapata Telephony
and
How It Relates to the Asterisk PBX"
By this point, you must be anxious to get your
Asterisk system up and running. If you are building a hobby system,
you can probably jump right to the next chapter and begin the
installation. For a mission-critical deployment, however, some
thought must be given to the environment in which the Asterisk
system will run. Make no mistake: Asterisk, being a very flexible
piece of software, will happily and successfully install on nearly
any Linux platform you can conceive of, and several non-Linux
platforms as well. However, to arm you with an
understanding of the type of operating environment Asterisk will
really thrive in, this chapter will discuss issues you need to be
aware of in order to deliver a reliable, well-designed system.
In terms of its resource requirements,
Asterisk's needs are similar to those of an embedded, real-time
application. This is due in large part to its need to have priority
access to the processor and system buses. It is therefore
imperative that any functions on the system not directly related to
the call-processing tasks of Asterisk be run at a low priority, if
at all. On smaller systems and hobby systems, this might not be as
much of an issue. However, on high-capacity systems, performance
shortcomings will manifest as audio quality problems for users,
often experienced as echo, static, and the like. The symptoms will
resemble those experienced on a cell phone when going out of range,
although the underlying causes will be different. As loads
increase, the system will have increasing difficulty maintaining
connections. For a PBX, such a situation is nothing short of
disastrous, so careful attention to performance requirements is a
critical consideration during the platform selection process.
Table 2-1 lists some very basic
guidelines that you'll want to keep in mind when planning your
system. The next section takes a close look at the various design
and implementation issues that will affect its performance.
Table 2-1. System requirement
guidelines
Purpose
|
Number of channels
|
Minimum recommended
|
Hobby system
|
No more than 5
|
400-MHz x86, 256 MB RAM
|
SOHOa system
|
5 to 10
|
1-GHz x86, 512 MB RAM
|
Small business system
|
Up to 15
|
3-GHz x86, 1 GB RAM
|
Medium to large system
|
More than 15
|
Dual CPUs, possibly also multiple servers in a
distributed architecture
|
With large Asterisk installations, it is common
to deploy functionality across several servers. One or more central
units will be dedicated to call processing; these will be
complemented by one or more ancillary servers handling peripherals
(such as a database, voicemail, conferencing, management, a web
interface, a firewall, and so on). As is true in most Linux
environments, Asterisk is well suited to growing with your needs: a
small system that used to be able to handle all your
call-processing and peripheral tasks can be distributed between
several servers when increased demands exceed its abilities.
Flexibility is a key reason why Asterisk is extremely
cost-effective for rapidly growing businessesthere is no effective
maximum or minimum size to consider when budgeting the initial
purchase. While some scalability is possible with most telephone
systems, we have yet to hear of one that can scale as inexpensively
as Asterisk. Having said that, distributed Asterisk systems are not
simple to designthis is not a task for someone new to
Asterisk.
|