Asterisk on a Virtual Server

[Euphorian]

In my experience Asterisk on a virtual server has been a bad thing. (We tried this once but had timing issues.)

I'm wondering if anyone has had any experience with Asterisk on a virtual hardware environment? Is the timing still an issue, or has this all be resolved over the past few years.

I'm considering creating a private cloud my production Asterisk servers - for ease of management.

If this is possible, what vm software should i consider? and is there a particular Xeon CPU that i need to use?

[danielyk]

I have already had good experience with virtualized asterisk servers. I have used as hypervisor Hyper-V and ESXi, without any problems. I used a rack server with Intel Xeon processor and 16GB memory.

Asterisk was respectively installed on a conventional Ubuntu server.

[Euphorian]

Excellent news, thanks for the feedback.

How many simultaneous calls?

[danielyk]

Only our conference system has regular carried out 10-20 concurrent users in different conference rooms, the server was in idle. I think the hardware data are somewhat oversized, less sufficient.

[ambiorixg12]

Related to timing, In the past, if internal timing were desired for an Asterisk system, then the only source acceptable was from DAHDI. Beginning with Asterisk 1.6.1, a new timing API was introduced which allows for various timing modules to be used.
Asterisk includes the following timing modules:
res_timing_pthread.so
res_timing_dahdi.so
res_timing_timerfd.so – as of Asterisk 1.6.2
res_timing_kqueue.so – as of Asterisk 11

https://wiki.asterisk.org/wiki/display/ ... Interfaces

[david55]

Note that Asterisk makes no concessions to VMs. If they work well, it is either that the VM host is more suited to real time guests, or that it is sufficiently lightly loaded and/or enough resources have been given to the asterisk VM, that it gets scheduled often enough not to introduce excessive jitter.

[Euphorian]

As i mentioned - i really cant remember what the actual problem was - something timing related, but i also know that the DAHDI played some role in all this and we generally DO now install asterisk with DAHDI. If i remember correctly the old MeetMe conferencing system used it, and i think (if memory serves) this was the heart of our issue.

At peak times we process 400 simultaneous calls per box (700-800 channels). So ill probably have to scale each VM down to about 100 calls each. To me that would be the best option -take a server that normally processed 400 calls and split it into 4 VM servers (2 cores, 4 gigs ram each) so that the same hardware is handling the same amount of calls in total.

I know you may be thinking im not getting any gain here - but, if this works, management and scaling is going to be a dream... copy paste boot-up, copy paste boot-up... snapshot recover... easy easy easy!

Will let you all know how things go.

[Lexus45]

On KVM. Though I'm not a person in charge of hypervisor administration.

Code: Select all

siprouter ~ # asterisk -rx 'sip show peers' | tail -n1
117 sip peers [Monitored: 78 online, 22 offline Unmonitored: 17 online, 0 offline]

siprouter ~ # asterisk -rx 'sip show registry' | tail -n1
374 SIP registrations.

siprouter ~ # asterisk -rx 'core show calls' | tail -n2
114 active calls
2151603 calls processed

siprouter ~ # asterisk -rx 'core show uptime'
System uptime: 2 weeks, 2 days, 7 hours, 25 minutes, 30 seconds
Last reload: 2 weeks, 2 days, 7 hours, 25 minutes, 30 seconds

We've also noticed that not virtualized Asterisk nodes have better MOS value than those which are virtual.

[david55]

We've also noticed that not virtualized Asterisk nodes have better MOS value than those which are virtual.

MOS is a property of the codecs used, so cannot vary just because of virtualisation.

The only way of getting an MOS measurement that included the affects of virtualisation would be to assemble a panel of listeners and get them to score the audio quality.

[Euphorian]

MOS is a property of the codecs used, so cannot vary just because of virtualisation.

I'm not sure if that's a fair statement... if a visualized NIC is overwhelmed, and starts dropping or queuing packets, then for sure, it will effect the MOS. If the opinion "O" is that call quality is less when processed on a virtual box, (when compared bare metal under the same network conditions) then i would say its an interesting observation, and well worth keeping in eye out for.

[david55]

I don't believe the person who introduced MOS actually measured an MOS, as doing so is expensive. Where PABXes report MOS, I think it is purely based on the codecs used, as there is no way of algorithmically including other factors. You have to assemble a panel, get their opinions, and average them.