Virtualization Performance Test: Asterisk in Xen vs KVM vs Bare Metal

Running Asterisk in virtualized
environments
Saúl Ibarra Corretgé <saul@irontec.com>
http://www.saghul.net
saghul
http://www.irontec.com
AMOOCON 2009 - Running Asterisk in virtualized environments
About me
● saghul
– VoIP enthusiast, playing around with Asterisk since 2k5
– Started testing virtualization solutions 3 years ago
– GNU/Linux lover :)
● Irontec
– Small company located at the north of Spain
– Web design, VoIP systems, ... everything under GNU/Linux
– Always trying to be at the bleeding edge of technology
2
About this presentation
● Presentation (ODP + PDF)

● Configuration examples
● Test results
http://www.irontec.com/~saul/amoocon2k9.tar.gz
3
Index
1. Introduction to virtualization
2. Virtualization types
3. Test-bench setup
4. Testing
1. Xen
2. KVM
3. No virtualization
5. Results analysis
6. Conclusions
4
Introduction to virtualization
Introduction to virtualization
● Virtualization
– The ability to use a single physical computer to run several
“simulated” computers
● Why would we use it?

– Testing / production environments
– Cost reduction
– Different testing scenarios
6
Virtualization types
Virtualization types
Performance is virtualization's Achilles Heel and depends

mainly in the type of virtualization used.
Isolation between host and guests its also very important,

usually: +isolation → -performance
● Emulation
● Full virtualization
● Paravirtualization
● OS level virtualization
8
Virtualization types (I)
Emulation
● Entire hardware is simulated (no access to real hardware)

● Guests are unmodified
● Different architectures can be virtualized
● Poor performance
9
Virtualization types (II)
Full virtualization
● Similar to emulation
● Some instructions are run on the raw hardware (Intel VT or
AMD V is needed)
● Host and guests have to be the same architecture
● Guest OS runs unmodified
● Often used instead of paravirtualization, when guest OS is
distributed in binary form (e.g. Windows)
● Better performance than emulation
10
Virtualization types (III)
Paravirtualization
● Guest OS is modified so that it communicates whith the

real hardware
● Applications run unmodified
● Host and guests have to be the same architecture
● Better performance than Full virtualization
11
Virtualization types (IV)
OS level virtualization
● Guests share resources with the host system

● Weak isolation
● Host performance can be compromised by guests
● Guests are not really full-featured systems
12
Test-bench setup
Test-bench setup
Testing Equipment
● HP ProLiant ML310
● Dual Intel(R) Xeon(R) CPU 3075 @ 2.66GHz
● RAM: 2GiB DDR2 800MHz
● 2 x 80GB HDD – RAID0
● OS: Debian 5.0 (Lenny) 64-bit
● Cheap 3Com Gigabit switch
14
Test-bench setup (I)
15
Test-bench setup (II)
● Software used:
– Asterisk ;)
– SIPp (stress-testing)
– Tcpdump (sniffing RTP for use with SIPp)
– sar (CPU usage, HD, IO stats)
– sadf (extract sar's data)
● Limits:
– ulimit -s unlimited # stack size
– ulimit -n 65536 # open files
– ulimit -u unlimited # user process num.
16
Testing
Testing
Send 2.000 calls with SIPp (100s RTP bidirectional media). 400
simultaneous calls maximum.
./sipp -sf uac_pcap.xml 10.10.0.241 -m 2000

-s 1234 -l 400 -mi 10.10.0.207 -mp 11000 -i
10.10.0.207 -trace_stat
./sipp -sf saghul_uas.xml -mi 10.10.0.205 -

rtp_echo -mp 11000 -p 5070
18
Testing (II)
Analyze sar data and SIPp generated stats.
sar -c -n DEV -n SOCK -p -r -u -o

stress.sar 10 0
sadf -d stress.sar -- -p -r -u -c -n DEV -n

SOCK > stress.csv
19
Testing: Xen
● Total calls generated: 2000

● Successlful calls: ~950
● Max. Concurrent calls: 400
20
Testing: KVM

21
Testing: No virtualization

22
Call stats (Xen)
Call stats
2500
2000
1500
TotalCallCreated
SuccessfulCall(C)
FailedCall(C)
1000
500
0
2009-04-2722:37:30:372 1240864650.372034 2009-04-2722:43:30:383 1240865010.383449
2009-04-2722:34:30:367 1240864470.367186 2009-04-2722:40:30:377 1240864830.377034
23
Call stats (KVM)
Call stats
2500
2000
1500
TotalCallCreated
SuccessfulCall(C)
FailedCall(C)
1000
500
0
2009-04-2819:47:13:296 1240940833.296806 2009-04-2819:51:13:302 1240941073.302805
2009-04-2819:45:13:293 1240940713.293946 2009-04-2819:49:13:299 1240940953.299805 2009-04-2819:53:13:308 1240941193.308350
24
Call stats (No virtualization)
Call stats
2500
2000
1500
TotalCallCreated
SuccessfulCall(C)
FailedCall(C)
1000
500
0
2009-04-2722:59:26:051 1240865966.051527 2009-04-2723:05:26:506 1240866326.506768
2009-04-2722:56:26:043 1240865786.043268 2009-04-2723:02:26:055 1240866146.055127
25
Failed calls (UDP retrans.)
Failed calls (UDP retrans.)

1200
1000
800
KVM
600
Xen
No-virt
400
200
0
1 2 3 4 5 6 7 8 9 10
26
CPU usage (Xen)
CPU usage
80
70
60
50
%user
40 %system
%iowait
30
20
10
0
2009-04-27 20:35:57 UTC 2009-04-27 20:38:37 UTC 2009-04-27 20:41:17 UTC 2009-04-27 20:43:57 UTC 2009-04-27 20:46:37 UTC 2009-04-27 20:49:17 UTC
27
CPU usage (KVM)
CPU usage
90
80
70
60
%user
50
%system
40 %iowait
30
20
10
0
2009-04-28 17:46:29 UTC 2009-04-28 17:48:29 UTC 2009-04-28 17:50:29 UTC 2009-04-28 17:52:29 UTC
2009-04-28 17:45:29 UTC 2009-04-28 17:47:29 UTC 2009-04-28 17:49:29 UTC 2009-04-28 17:51:29 UTC 2009-04-28 17:53:29 UTC
28
CPU usage (No virtualization)

CPU usage
50
45
40
35
30
%user
25 %system
%iowait
20
15
10
0
29
Memory usage (Xen)

Memory usage
20
18
16
14
12
%memused
10
%swpused
0
30
Memory usage (KVM)
Memory usage
90
80
70
60
50
%memused
%swpused
40
30
20
10
0
31
Memory usage (No virtualization)
Memory usage
8
%memused
4
%swpused
0
32
Socket activity (Xen)

Socket activity
1800
1600
1400
1200
1000
totsck
800
600
400
200
0
2009-04-27 20:34:37 UTC 2009-04-27 20:36:57 UTC 2009-04-27 20:39:17 UTC 2009-04-27 20:41:37 UTC 2009-04-27 20:43:57 UTC 2009-04-27 20:46:17 UTC 2009-04-27 20:48:37 UTC
33
Socket activity (KVM)
Socket activity
2500
2000
1500
totsck
1000
500
0
34
Socket activity (No virtualization)
Socket activity
1800
1600
1400
1200
1000
totsck
800
600
400
200
0
35
Tweaking (Xen)
● Xen tweaking:
– DomU in an LVM volume
– 1GB of RAM for the DomU
– Ethernet checksum disabled for the domU adapter:
ethtool -K eth0 tx off
– System limits 'extended'
– Had to 'tweak' dahdi_dummy.c so that it corretly handles
timing source.
36
Tweaking (KVM)
● KVM tweaking:
– Guest in an LVM volume
– 1GB of RAM for the guest
– Paratirtualization drivers
● Virtio block device
● Virtio network device
– System limits 'extended'
37
Results analysis
Results analysis
● Only a few calls are dropped because of UDP

retransmissions
● 90% dropped calls exceeded response timeouts, etc of
the SIPp scenario
– It's a very strict scenario!
● Didn't see any “too many open files” log message ;)
● CPU usage is higher in virtualized environments
– We didn't push Asterisk too hard
– 100% CPU usage wasn't reached
● Networking tends to be slower when running virtual
39
Issues during testing period
● The server generating the traffic has to be really

powerful
– It can algo get 'stressed'!
● SIPp crashed many times

– Snapshot from 2009-01-21 seems to be most stable
● Network has to be 'isolated'

– We don't want results to be distorted
40
Conclusions
Conclusions
● Yes, we CAN use Asterisk in a virtualized environment

● Performance factors
– HDD
– Network
– CPU
● For 400-600 calls we can use virtualization
– Remember we are SHARING resources!
– For heavier loads a standalone server would be better
– We can even use cards (pci passthrough)
● Specially for testing purpouses virtualization is a really
good idea
42
Thanks!
BYE sip:amoocon@amoocon.de SIP/2.0

Via: SIP/2.0/UDP client.amoocon.de:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
From: saghul <sip:saghul@sipdoc.net>;tag=8321234356
To: Amoocon <sip:amoocon@amoocon.de>;tag=9fxced76sl
Call-ID: 3848276298220188511@amoocon.de
CSeq: 1 BYE
Content-Length: 0
Thanks for watching!

Thank you Olga and Manwe, for your continuous help
and support over long VoIP-hacking nights ;)
43
Any questions?
License
http://creativecommons.org/licenses/by-sa/3.0/
45

Virtualization Performance Test: Asterisk in Xen vs KVM vs Bare Metal

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Virtualization Performance Test: Asterisk in Xen vs KVM vs Bare Metal

Transféré par

Droits d'auteur :

Formats disponibles

Running Asterisk in virtualized

About this presentation

● Presentation (ODP + PDF)

● Why would we use it?

Performance is virtualization's Achilles Heel and depends

Isolation between host and guests its also very important,

Virtualization types (I)

● Entire hardware is simulated (no access to real hardware)

Virtualization types (II)

Virtualization types (III)

● Guest OS is modified so that it communicates whith the

Virtualization types (IV)

● Guests share resources with the host system

Test-bench setup (I)

Test-bench setup (II)

./sipp -sf uac_pcap.xml 10.10.0.241 -m 2000

./sipp -sf saghul_uas.xml -mi 10.10.0.205 -

Analyze sar data and SIPp generated stats.

sar -c -n DEV -n SOCK -p -r -u -o

sadf -d stress.sar -- -p -r -u -c -n DEV -n

● Total calls generated: 2000

● Total calls generated: 2000

● Total calls generated: 2000

Call stats (Xen)

Call stats (KVM)

Call stats (No virtualization)

Failed calls (UDP retrans.)

Failed calls (UDP retrans.)

CPU usage (Xen)

CPU usage (KVM)

CPU usage (No virtualization)

Memory usage (Xen)

Memory usage (KVM)

Memory usage (No virtualization)

Socket activity (Xen)

Socket activity (KVM)

Socket activity (No virtualization)

● Only a few calls are dropped because of UDP

Issues during testing period

● The server generating the traffic has to be really

● SIPp crashed many times

● Network has to be 'isolated'

● Yes, we CAN use Asterisk in a virtualized environment

BYE sip:amoocon@amoocon.de SIP/2.0

Thanks for watching!

Vous aimerez peut-être aussi