2.1. Server Hardware Selection
The selection of a server is both simple and
complicated: simple because, really, any x86-based platform will
suffice; but complicated because the reliable performance of your
system will depend on the care that is put into the platform
design. When selecting your hardware, you must carefully consider
the overall design of your system and what functionality you need
to support. This will help you determine your requirements for the
CPU, motherboard, and power supply. If you are simply setting up
your first Asterisk system for the purpose of learning, you can
safely ignore the information in this section. If, however, you are
building a mission-critical system suitable for deployment, these
are issues that require some thought.
2.1.1. Performance Issues
Among other considerations, when selecting the
hardware for an Asterisk installation you must bear in mind this
critical question: how powerful must the system be? This is not an
easy question to answer, because the manner in which the system is
to be used will play a big role in the resources it will consume.
There is no such thing as an Asterisk performance-engineering
matrix, so you will need to understand how Asterisk uses the system
in order to make intelligent decisions about what kinds of
resources will be required. You will need to consider several
factors, including:
The maximum
number of concurrent connections the system will be expected to
support
-
Each connection will increase the workload on
the system.
The percentage
of traffic that will require processor-intensive Digital Signal
Processing (DSP) of compressed codecs (such as G.729 and
GSM)
-
The DSP work that Asterisk performs in software
can have a staggering impact on the number of concurrent calls it
will support. A system that can happily handle 50 concurrent G.711
calls can be brought to its knees by a request to conference
together 10 G.729 compressed channels.
Whether
conferencing will be provided, and what level of conferencing
activity is expected
-
Will the system be used heavily? Conferencing
requires the system to transcode and mix each individual incoming
audio stream into multiple outgoing streams. Mixing multiple audio
streams in near-real-time can place an enormous load on the
CPU.
Echo
cancellation
-
Echo cancellation may be required on any calls
where a Public Switched Telephone Network (PSTN) interface is
involved. Since echo cancellation
is a mathematical functionthe more of
it the system has to perform, the higher the load on the CPU will
be.
Dialplan
scripting logic
-
-
Whenever Asterisk has to pass call control to an
external program, there is a performance penalty. As much logic as
possible should be built into the dialplan. If external scripts are
used, they should be designed with performance and efficiency as
important goals.
As for the exact performance impact of these
factors, the jury's still out. The effect of each is known in
general terms, but an accurate performance calculator has not yet
been successfully defined. This is partly because the effect of
each component of the system is dependent on numerous variables,
such as CPU power, motherboard chipset and overall quality, total
traffic load on the system, Linux kernel optimizations, network
traffic, number and type of PSTN interfaces, and PSTN trafficnot to
mention any non-Asterisk services the system is performing
concurrently. Let's take a look at the effects of several key
factors:
Codecs and
transcoding
-
Simply put, a codec (short for coder/decoder or
compression/decompression) is a set of mathematical rules that
define how an analog waveform will be digitized. The differences
between the various codecs are due in
large part to the levels of compression and quality that they
offer. Generally speaking, the more compression that's required,
the more work the DSP must do to code or decode the signal.
Uncompressed codecs, therefore, put far less strain on the CPU (but
require more network bandwidth). Codec selection must strike a
balance between bandwidth and processor usage.
Central
Processing Unit (and Floating Point Unit)
-
A CPU is comprised of several components, one of
which is the Floating Point Unit (FPU). The speed of the CPU,
coupled with the efficiency of its FPU, will play a significant
role in the number of users a system can effectively support. The
next section, "Choosing a Processor," offers
guidelines for choosing a CPU that will meet the needs of your
system.
Other processes
running concurrently on the system
-
Being Unix-like, Linux is designed to be able to
multitask several different processes. A problem arises when one of
those processes (such as Asterisk) demands a very high level of
responsiveness from the system. By default, Linux will equally
distribute resources amongst every application that requests them.
If you install a system with many different server applications,
those applications will each be allowed their fair use of the CPU.
Since Asterisk requires frequent high-priority access to the CPU,
it does not get along well with other applications, and if Asterisk
must coexist with other apps, the system may require special
optimizations. This primarily involves the assignment of priorities
to various applications in the system, and, during installation,
careful attention to which applications are installed as
services.
Kernel
optimizations
-
A kernel optimized for the performance of one
specific application is something that very few Linux distributions
offer by default, and thus it requires some thought. At the very
minimumwhichever distribution you choosea fresh copy of the Linux
kernel (available from http://www.kernel.org) should be
downloaded and compiled on your platform. You may also be able to
acquire patches that will yield performance improvements, but these
are considered hacks to the officially supported kernel.
IRQ
latency
-
-
Interrupt request (IRQ) latency is basically the
delay between the moment a peripheral card (such as a telephone
interface card) requests that the CPU stop what it's doing and the
moment when the CPU actually responds and is ready to handle the
task. Asterisk's peripherals (especially the Zaptel cards) are
extremely intolerant of IRQ latency.
|
Linux has historically had problems with its
ability to service IRQs quickly; this problem has caused enough
trouble for audio developers that several patches have been created
to address this shortcoming. So far, there has been some mild
controversy over how to incorporate these patches into the Linux
kernel.
|
|
Because the Digium cards require so much, it is
generally recommended that only one Digium card be run in a system.
If you require more connectivity than a single card can provide,
either replace your existing card with one of higher density, or
add another server to your environment.
Kernel
version
-
Asterisk is officially supported on Linux
Version 2.6.
Linux
distribution
-
Linux distributions are many and varied. In the
next chapter, we will discuss the challenge of selecting a Linux
distribution, and how to obtain and install both Linux and
Asterisk.
2.1.2. Choosing a Processor
Since the performance demands of Asterisk will
generally involve a large number of math calculations, it is
essential that you select a processor with a powerful FPU. The
signal processing that Asterisk performs can quickly demand a
staggering quantity of complex mathematical computations from the
CPU. The efficiency with which these tasks are carried out will be
determined by the power of the FPU within that processor.
To actually name a best processor for Asterisk
would fly in the face of the rapid advances in the computer
industry. Even in the time between the authoring and publishing of
this book, processor speeds will undergo rapid improvements, as
will Asterisk's support for various architectures. Obviously, this
is a good thing, but it also makes the giving of advice on the
topic a thankless task. Naturally, the more powerful the FPU is,
the more concurrent DSP tasks Asterisk will be able to handle, so
that is the ultimate consideration. When you are selecting a
processor, the raw clock speed is only part of the equation. How
well it handles floating-point operations will be a key
differentiator, as DSP operations in Asterisk will place a large
demand on it.
Both Intel and AMD CPUs have powerful
FPUs . As of this writing, the Intel
chips are commonly preferred for 32-bit systems, while AMD gets the
nod if you're going to 64-bit. When you read this book, that may no
longer be true.
The obvious conclusion is that you should get
the most powerful CPU your budget will allow. However, don't be too
quick to buy the most expensive CPU out there. You'll need to keep
the requirements of your system in mindafter all, a Formula 1
Ferrari is ill-suited to the rigors of rush-hour traffic.
In order to attempt to provide a frame of
reference from which we can contemplate our platform decision, we
have chosen to define three sizes of Asterisk systems: small,
medium, and large.
2.1.2.1. Small systems
Small systems (up to 10 phones) are not immune
to the performance requirements of Asterisk, but the typical load
that will be placed on a smaller system will generally fall within
the capabilities of a modern processor.
If you are building a small system from older
components you have lying around, be aware that the resulting
system cannot be expected to perform at the same level as a more
powerful machine, and will run into performance degradation under a
much lighter load. Hobby systems can be run successfully on very
low-powered hardware, although this is by no means recommended for
anyone who is not a whiz at Linux performance tuning.
If you are setting up an Asterisk system for the
purposes of learning, you will be able to build a fully featured
platform using a relatively low-powered CPU. The authors run
several Asterisk lab systems with 433-MHz to 700-MHz Celeron
processors; the workload of these systems is typically minimal.
2.1.2.2. Medium systems
Medium-sized systems (from 10 to 50 phones) are
where performance considerations will be the most challenging to
resolve. Generally, these systems will be deployed on one or two
servers only, and thus each machine will be required to handle more
than one specific task. As loads increase, the limits of the
platform will become increasingly stressed. Users may begin to
perceive quality problems without realizing that the system is not
faulty in any way, but simply exceeding its capacity. These
problems will get progressively worse as more and more load is
placed on the system, with the user experience degrading
accordingly. It is critical that performance problems be identified
and addressed before they are noticed by users.
Monitoring performance on these systems and
quickly acting on any developing trends is a key to ensuring that a
quality telephony platform is provided.
2.1.2.3. Large systems
Large systems (over 50 users) can be distributed
across multiple cores, and thus performance concerns can be managed
through the addition of machines. Very large Asterisk systemsfrom
500 to over 1,000 usershave been created in this way. Building a
large system requires an advanced level of knowledge in many
different disciplines. We will not discuss it in detail in this
book, other than to say that the issues you'll encounter will be
similar to those encountered during any deployment of multiple
servers handling a single, distributed task.
2.1.3. Choosing a Motherboard
Just to get any anticipation out of the way, we
also cannot recommend specific motherboards in this book. With new
motherboards coming out on a weekly basis, any recommendations we
made would be rendered moot by obsolescence before the published
copy hit the shelves. Not only that, but motherboards are like
automobiles: while they are all very similar in principle, the
difference is in the details. And as Asterisk is a performance
application, the details matter.
What we will do, therefore, is give you some
idea of the kinds of motherboards that can be expected to work well
with Asterisk, and the features that will make for a good
motherboard. The key is to have both stability and high
performance. Here are some guidelines to follow:
-
The various system buses must provide the
minimum possible latency. If you are planning a PSTN connection
using analog or PRI interfaces (discussed later in this chapter),
the Digium Zaptel cards will generate 1,000 interrupt requests per
second. Having devices on the bus that interfere with this process
will result in degradation of call quality. Chipsets from Intel
(for Intel CPUs) and nVidia nForce (for AMD CPUs) seem to score the
best marks in this area. Review the specific chipset of any
motherboard you are evaluating to ensure that it does not have
known problems with IRQ latency.
-
If you are running Zaptel cards in your system,
you will want to ensure that your BIOS allows you maximum control
over IRQ assignment . As a rule,
high-end motherboards will offer far greater flexibility with
respect to BIOS tweaking; value-priced boards will generally offer
very little control. This may be a moot point, however, as
APIC-enabled motherboards turn IRQ control over to the operating
system.
-
Server-class motherboards generally implement a
different PCI standard than workstation-class motherboards . While there are many differences, the most
obvious and well known is that the two versions have different
voltages. Depending on which cards you purchase, you will need to
know if you require 3.3V or 5V PCI slots. Figure 2-1 shows the difference between
3.3V and 5V slots. Most server motherboards will have both types,
but workstations will typically have only the 5V version.
-
Consider using multiple processors. This will
provide an improvement in the system's ability to handle multiple
tasks. For Asterisk, this will be of special benefit in the area of
floating-point operations.
|
|
It should be noted that evidence now suggests
that connecting together two completely separate, single-CPU
systems may provide far more benefits than simply using two
processors in the same machine. You not only double your CPU power,
but you also achieve a much better level of redundancy at a similar
cost to a single-chassis, dual-CPU machine. Keep in mind, though,
that a dual-server Asterisk solution will be more complex to design
than a single-machine solution.
|
|
-
Avoid motherboards that include built-in audio
and video components. If you want a sound card, install one. As for
a video card, you may not need one at allcertainly Asterisk does
not require one. It has traditionally been the more value-priced
motherboards that have had these components on-board, and these
board designs often make compromises to keep down the costs.
-
If possible, install an external modem. If you
must have an internal modem, you will need to ensure that it is not
a so-called "Win-modem"it must be a completely self-sufficient unit
(note that these are very difficult, if not impossible, to
find).
-
Consider that with built-in networking, if you
have a network component failure, the entire motherboard will need
to be replaced. On the other hand, if you install a peripheral
Network Interface Card (NIC) , there
may be an increased chance of failure due to the extra mechanical
connections involved. Some value can probably be gained from having
both primary and backup cards installed in the system.
-
The stability and quality of your Asterisk
system will be dependent on the components you select for its
architecture. Asterisk is a beast, and it expects to be fed the
best. As with just about anything, high cost is not always
synonymous with quality, but you will want to become a connoisseur
of computer components.
Having said all that, we need to get back to the
original point: Asterisk can and will happily install on pretty
nearly any PC platform. The lab systems used to write this book,
for example, included everything from a 433-MHz Pentium III on an
Intel chipset to an Athlon XP 2000 on a VIA-based motherboard. We
have not experienced any performance or stability problems running
less than five concurrent telephone connections. For the purposes
of learning, do not be afraid to install Asterisk on whatever
system you can scrounge up. When you are ready to put your system
into production, however, you will need to understand the
ramifications of the choices you make with respect to your
hardware.
2.1.4. Power Supply Requirements
One often-overlooked component in a PC is the
power supply (and the supply of power). For a telecommunications
system, these components can play a significant role in the quality
of the user experience.
2.1.4.1. Computer power supplies
The power supply you select for your system will
play a vital role in the stability of the entire platform. Asterisk
is not a particularly power-hungry application, but anything
relating to multimedia (whether it be telephony, professional
audio, video, or the like) is generally sensitive to power
quality.
This oft-neglected component can turn an
otherwise top-quality system into a poor performer. By the same
token, a top-notch power supply might enable an otherwise cheap PC
to perform like a champ.
The power supplied to a system must provide not
only the energy the system needs to perform its tasks, but also
stable, clean signal lines for all of the voltages your system
expects from it.
2.1.4.2. Redundant power supplies
In a carrier-grade or high-availability
environment, it is common to deploy servers that use a
redundant power supply. Essentially,
this involves two completely independent power supplies, either one
of which is capable of supplying the power requirements of the
system.
If this is important to you, keep in mind that
best practices suggest that to be properly redundant, these power
supplies should be connected to completely independent
Uninterruptible Power Supplies (UPSs) that are in turn fed by
totally isolated electrical circuits. |
]