The modern call center has benefited greatly from improvements in virtualization technology, and the widespread acceptance of the cloud contact center as a wise choice has accelerated improvements in that field. Asterisk runs well on both actual and virtual commodity servers and has done for several years now.
As with any technology, however, virtualization is no panacea. When deploying your call center software on virtual servers, care must be taken, as in all technology decisions. The flexibility, ease of deployment, and quick ability to alter the server all come at a cost. Some forget that a virtual server is not actually the full equivalent of a hardware server.
Here are a few things we have found, so you don’t have to:
More virtual cores don’t give you more actual performance by themselves. This is not something that would normally be encountered in a cloud environment, but can be caused by somebody who is a little overeager with the virtualization settings. If, for example, you configure two 4-core virtual servers and have them running simultaneously, you will not get 8 cores worth of performance if they are running on a 4-core host. This may be fine if each server is using only a fraction of the allocated resources, or if peak loads on each system do not coincide. It is not fine if you are actually going to require that sort of performance on each of the servers on a regular basis.
Virtual servers can starve one another of resources. Normally a little thought beforehand is all that is necessary to prevent these issues. A disk-heavy application may not be a good candidate to be paired with another disk-heavy VM. One example we have seen in the Cloud is network usage. While moving recordings from a set of Asterisk servers, the overall usage was enough to saturate the network controller on the shared hardware. This caused significant call quality issues, even though it appeared each server should have enough bandwidth. Once the issue was spotted it was easy to move the servers to separate hardware.
The virtualization technology itself may have a constraint or bug. It’s occasionally the case that the virtual environment doesn’t match up with the way hardware would due to a bug or design constraint. For instance, one major technology has had an issue with being unable to spread interrupts for the ethernet controller over multiple cores. In situations where there is a significant amount of network traffic, this can place a high amount of work on a single core, causing performance constraints. Other virtualization technologies may have design constraints due to issues with presenting hardware features that may not exist on all supported platforms. This forces the software to perform tasks that may have been more optimally performed in the hardware.
The virtualization technology may not be completely transparent to the system. This is somewhat related to the last item, but in some cases attributes of the virtualization technology are not completely transparent to the guest OS. One example we have seen a few times is the compiler not using the correct CPU type, resulting in “Illegal Instruction” errors when running Asterisk. This can usually be resolved by passing a flag during the configure step. Here are two we have seen used (separately) successfully:
- ./configure CC=”gcc -O3″ CFLAGS=-O3
- ./configure CFLAGS=mtune=native
With a small amount of planning these issues can be easily avoided or overcome, allowing for a successful use of your call center software in the cloud.