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?
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.
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.
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
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.
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!
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.
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.
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.