Virtualización VoIP: Del cobre hasta la nube

VIRTUALIZACIÓN VOIP

Virtualización de VoIP: Del
cobre hasta la nube


Conferencista:

Ing. Andrés Mauricio Mujica Zalamea
andres.mujica@seaq.com.co
RHCE/RHCSA/RHCVA/DCAP
GERENTE SEAQ SERVICIOS CIA LTDA


OBJETIVOS

■ Conocer algunas de las diferentes tecnologías
de virtualización disponibles

■ Identificar las limitaciones y posibilidades de
la virtualización de VoIP

■ Determinar las mejores prácticas para
virtualizar VoIP


PLAN DE TRABAJO

■ Historia de la virtualización

■ Historia de la telefonía

■ Por qué virtualizar VoIP?

■ Tipos de virtualización
- Emulation
- OS-Level Virtualization
- Para-Virtualization
- Full/Native Virtualization


PLAN DE TRABAJO

■ VIRTUALIZANDO VoIP
 Consideraciones

 Criterios de virtualización

 OpenVZ / Vmware / Hyper-V / Xen / KVM

 Análisis de desempeño

■ CONCLUSIONES

■ Demo Real en AWS / KVM (limitado a
disponibilidad de tiempo)

HISTORIA DE LA VIRTUALIZACIÓN

The Real Deal

■ Otoño de 1964

■ GE le gana a IBM el
contrato MULTICS

■ TSS: Time Sharing
System

■ CP-40 Project

Robert Creasy


The Real Deal

■ CP/40 : Definio la arquitectura VM

■ Proyecto CP-67 parte de CP/CMS para el
IBM/System360-67

■ CP-370-CMS base para el VM/370

■ CP/CMS era OPEN SOURCE !!!


The Real Deal

■ IBM System-370 > VM/370


S/360-67 – 1966

■ Virtual Memory

■ Microcode

■ Hardware asistido

■ Direccionamiento
24/32 bits

■ Full Virtualization
(oops)


VM/370 – 1972

■ Primer VM Platform
■ Soporta múltiples OS

 CMS
 DOS/VS
 OS/MFT/MVT/VS1
 SVS
 MVS Teddy Bear – 1983
 VM/370 Mascota Oficial IBM VMs
 Algunas versiones de IBM/AIX


CP/CMS

■ Control Program :
Implementación de VM simulando un S/360
(hypervisor)

■ Cambridge Monitor System :
Sistema operativo mono-usuario


CP/CMS

■ Aislamiento de usuarios entre sí. (reliabilidad
y seguridad)

■ Simulación de un computador completo
permitiendo correr cualquier SW S/360 en un
TSS. (sin rediseñar aplicaciones para TSS)

■ Un CMS ligero como interfaz principal permite
un buen desempeño para el usuario


■ Nació por accidente

■ Con el S360/CP-67 se
creo el VM/370

■ VM/370: Muchos
colores surgen de un
solo haz de luz


DARK AGES

■ La burocracia interna de IBM ignoró la VM
durante mas de un lustro ( '73 al '79)

■ La comunidad de usuarios e IBMers se
autosoporto y apoyo mutuamente

➔ VMSHARE
➔ VNET

■ Antecedentes del "Open Source”


DARK AGES

■ 1972: Lanzamiento del VM/370

■ 1974: Computerworld blast. IBM has no further
plans for VM
 IBM tenía una proyección de máximo 500

clientes para VM

■ 1976: 300 clientes de VM

■ 1978: 1000 clientes con VM


DARK AGES

■ 1980: IBM.. compromiso con VM

■ 1980: IBM VM/SP1 (buggy as hell)

■ 1981: IBM VM/SP1 (por fin estable!)

■ 1982: IBM declara la tecnología VM estratégica

■ 1983: IBM inicia política OCO (acabo con el
"open source")


DARK AGES

■ 1983: 10.000 instalaciones de VM

■ 1985: "We hope that IBM will decide not to kill the
goose that lays the golden eggs”

■ 1987: Usuarios, desarrolladores e IBMers
insatisfechos con la migración a OCO
➔ Lentitud en bugfixes

➔ Demora en nuevas funcionalidades

■ 1987: Merge/386 primera aproximación en x86


GOLDEN (?) AGES

■ 1987: SoftPC Primer emulador de software

■ 1989: IBM 20.000 instalaciones de VM (a pesar
de!?)

■ 1990: Lanzamiento de IBM System/390

■ 1991: Aparece la primera versión del Linux
Kernel

■ 1997: Virtual PC de Connectix para Mac


GOLDEN (?) AGES

■ 1998: Vmware en modo stealth

■ 1998: Vmware patenta sus técnicas de
virtualization U.S. Patent 6,397,242

■ 1999: Vmware sale a la luz pública en la DEMO
Conference

■ 1999: IBM implementa hypervisores en
plataforma POWER


GOLDEN (?) AGES

■ 1999: Mark Spencer inicia el desarrollo de
Asterisk

■ 1999: Vmware lanza su producto Vmware
Workstation

■ 2000: IBM lanza Z/VM

■ 2000: Jim Dixon inicia el desarrollo de Open
Telephony Hardware (Zapata)


GOLDEN (?) AGES

■ 2001: Vmware lanza su primer producto para
servidores

■ 2003: Primer hypervisor Open Source Xen

■ 2003: Primer emulador Open Source QEMU

■ 2005: OpenVZ es liberado por Virtuozzo

■ 2006: Microsoft inicia el desarrollo de Hyper-V
basado en tecnología XEN


GOLDEN (?) AGES

■ 2007: Citrix compra XEN

■ 2007: KVM se incorpora al kernel de Linux

■ 2007: Innotek lanza VirtualBox

■ 2008: Red Hat compra Qumranet (KVM)

■ 2009: Oracle compra SUN (heredando 3
tecnologías de virtualización)


NOW THE FUTURE

■ 2009: Eastern Mngmnt Group: 2.9 millones de
“endpoints” vendidos en PBX Open Source,
equivalente al 18% del mercado en USA

➔ Crecimiento anual del 40%

■ 2009: Gartner: 18% de las workloads
corporativas sobre x86 corren virtualizadas.

➔ Para el 2012 se estima tener el 50% (58M)

HISTORIA DE LA TELEFONÍA

"Mr. Watson -- come here -- I want to see you."

-- Alexander Graham Bell


El teléfono fue inventado en 1876.

• Originalmente:
• Transmisión sobre un hilo de hierro/cobre
• Circuitos sin marcación (ring down).
• Comunicación punto a punto.


■ PSTN (Public Switched Telephone Network)

TIPOS DE VIRTUALIZACIÓN
■ Virtualización

 La posibilidad de correr múltiples
computadores dentro de un solo
computador físico

- Consumo de energía

- Espacio

- Subutilización de
recursos

- Administración

■ Para que usarla?

 Ambientes de pruebas y/o producción
 Reducción de costos
 Consolidación


■ Emulation

■ OS-Level virtualization

■ Para-virtualization

■ Full/Native virtualization


■ Aislamiento (Isolation)
➔ Mantener los guest y el host aislados entre sí

es muy importante pero afecta el desempeño

■ Desempeño

➔ Es el elemento más importante a considerar


Emulation

■ Simulación completa del hardware

■ Los guests no requieren modificación

■ Diferentes arquitecturas emuladas (desde arm
hasta s390)

■ Bajo desempeño


Full/Native Virtualization

■ Algunas instrucciones corren directo en el hw de
manera asistida (Intel VT o AMD V)
■ Parecido a la emulation
■ Sistemas operativos Guest corren sin modificación
■ Sistemas operativos Guest deben ser de la misma
arquitectura
■ Normalmente usada en vez de la
paravirtualización cuando el SO Guest se
distribuye en binario (Windows)
■ Mejor desempeño que la emulación
■ Se puede mezclar con la para-virtualización


Para-Virtualization

■ Las aplicaciones corren sin modificaciones
■ Pero el Sistema operativo invitado (Guest)
requiere modificación para acceder al hardware
real
■ Mejor desempeño que la Full/Native Virtualization
■ Sistemas operativos Guest deben ser de la misma
arquitectura
■ Utilizado por la Full/Native virtualization para I/O

OS-Level Virtualization (contextos)

■ Mismo kernel para todas las “VM”
■ Guest comparte recursos con el sistema host
■ Aislamiento débil
■ Desempeño del host supeditado al consumo de
los guest
■ Guest no son sistemas completos realmente
■ Mejor I/O existente


Hardware emulation
●
KQEMU

Full virtualization
●
binary translation
●
VirtualBox/VMware

Classic virtualization
● KVM

Para-virtualization
●
Xen

Linux-VServer
OS-level virtualization
●

(contextualization/
containers) OpenVZ


virtualization != emulation
QEMU is an emulator

efficiency = performance + scalability


Virtualization technologies

partial emulation no emulation

IO
BT

KQEMU
VirtualBox KVM OpenVZ Xen (Linux) Linux-VServer

VMware

Tipos de hypervisor

 Hypervisors type I: KVM, Xen, Vmware
 Hypervisors type II: VirtualBox, KQEMU,

Vmware Workstation


PLAN DE TRABAJO

 Consideraciones

 Criterios de diseño


■ CONCLUSIONES


VIRTUALIZANDO VoIP

Virtualizando VoIP

■ Se deben tener en cuenta factores como

 Protocolos afectados
 Arquitectura de asterisk
 Problemas normales de VoIP
 Pruebas de carga

PROTOCOLOS AFECTADOS

VoIP

■ SIP


VoIP

■ IAX2


RTP Timestamp

ARQUITECTURA ASTERISK
Timing
Source

ARQUITECTURA ASTERISK
Timing
Dependant

CPU
Intensive I/O
Intensive

HW
Access

PROBLEMAS NORMALES DE VoIP

Problemas que no existían o estaban
solucionados con la telefonía tradicional y que
afectan la calidad del servicio (QoS).

● Requerimiento de ancho de banda.
● Latencia o retardo (>300 ms es impracticable).

● Jitter: variación de latencia.

Principal problema:

No hay dedicación exclusiva para la
transmisión de la Voz

PROBLEMAS NORMALES DE VoIP

● Las redes IP generalmente no permiten
garantizar un tiempo mínimo para atravesarlas.

● Las redes IP están diseñadas para descartar
paquetes en caso de congestión y
retransmitirlos en caso de error. Esto no es
adecuado para la voz.

● Los retardos de cientos de ms, comunes en
redes de datos, son inaceptables en una
conversación telefónica.

RETO AL VIRTUALIZAR

● Todos los problemas anteriores existentes, con
un nuevo ingrediente:

Otros Guest luchando por los
recursos de hardware de la máquina
- CPU
- I/O
- TIME DRIFT


PLAN DE TRABAJO

 Consideraciones


 OpenVZ / Vmware / Hyper-V / Xen / KVM

 Algunas pruebas

■ CONCLUSIONES


CRITERIOS DE VIRTUALIZACION

■ Numero máximo de conexiones concurrentes

■ Porcentaje de trafico que requiere DSP (G.729,
GSM, G.711, etc.)

■ ¿Conferencias soportadas?, ¿Que tan activas?

■ ¿Cancelación de eco por software/hardware?
(PSTN)

■ ¿Scripts externos invocados por Asterisk?


■ Grabación de llamadas

■ Troncales análogas/digitales o IP

■ IVR transaccional

■ Plataforma de virtualización

■ Necesidad de consolidación o flexibilidad


■ Codecs comprimidos/descomprimidos

■ Network
- ¿Trafico de otras aplicaciones?
- ¿Aislar el trafico de voz?
- QoS

■ CPU
- Codecs
- IRQ
- TransCoding (CLI> show translation)


■ Transcoding

■ ¿Codecs comprimidos/descomprimidos?
(CPU/Network)

■ ¿Otros guest en la misma maquina física?

■ ¿Compilar el núcleo de Linux?

■ Latencia de IRQ (dispositivos innecesarios)


REQUERIMIENTOS DE HW


NYQUIST

■ La frecuencia de muestreo debe ser mayor que
el doble del ancho de banda de la señal de
entrada, para poderla reconstruir desde la
muestra.

■ La red telefonica transporta frecuencias entre los
300 Hz. y los 4000 Hz

■ 8000 muestras/segundo son suficientes para
reconstruir. (8000 Hz.)


■ 1 kbit/s = 1 kbps

■ 8 kbit/s – Calidad de telefono

■ 32 kbit/s – Calidad MW

■ 96 kbit/s – Calidad FM

■ 192 kbit/s – Sonido MP3

■ 1,411 kbit/s – CD de audio (muestras de 16 bit ×
44.1 kHz × 2 canales)


Calls vs CPU


LINEAMIENTOS PARA DIMENSIONAMIENTO DE
SERVIDOR FÍSICO

– 100 Simultaneous calls per GHz of CPU capacity

– GHz capacity = Number of CPU * Clock Speed

– p.e., Quad Core 2.4 GHz CPU tiene 4 cores * 2.4
GHz = 9.6 GHz capacity
Total máx de llamadas: 960


PLAN DE TRABAJO

 Consideraciones



■ CONCLUSIONES


PRUEBAS DESEMPEÑO

Resultados de algunas pruebas de desempeño:

■ RevolutionLinux 2008 comparando tecnologías de
virtualización Open Source

■ Vmware vs XEN by Vmware (2007)
 Pruebas XEN vs Vmware by XENSOURCE

(hoy Citrix) (2007)

■ SPECVirt 2010 pruebas neutrales de la industria
(2007)

■ Análisis de virtualización VoIP por Saúl Ibarra

PRUEBAS DESEMPEÑO
Compilation of the Linux kernel

1

0,9

Linux-VServer
Xen
0,8 OpenVZ
KVM
VirtualBox (-hwvirtex off)
KQEMU
0,7 VirtualBox (-hwvirtex on)
QEMU

0,6

0,5
Nomalized time
(kernel vanilla)

0,4

0,3

0,2

0,1

0

Análisis realizado por
RevolutionLinux
http://www.revolutionlinux.com

PRUEBAS DESEMPEÑO
Bzip2

1,00

0,90

0,80 Xen
Linux-VServer
VirtualBox (-hwvirtex on)
VirtualBox (-hwvirtex off)
0,70 KVM
KQEMU
OpenVZ
QEMU

0,60

0,50
Normalized time
(kernel vanilla)

0,40

0,30

0,20

0,10

0,00

Análisis realizado por
RevolutionLinux

PRUEBAS DESEMPEÑO
dd (60G /dev/zero --> /dev/null)

1

0,9

0,8

0,7
Linux-VServer
KVM
OpenVZ
0,6 Xen

0,5
Normalized throughput
(kernel vanilla)

0,4

0,3

0,2

0,1

0

* no results for KQEMU nor VirtualBox Análisis realizado por
RevolutionLinux

PRUEBAS DESEMPEÑO

Estudio realizado por
XenSource

PRUEBAS DESEMPEÑO

Vmware

PRUEBAS DESEMPEÑO

SPECvirt

PRUEBAS DE CARGA

PACKET CREATION & FLOODING

■ Algunas desarrolladas por HP

➔ SIPNess: SIP testing tool que prueba
aplicaciones SIP

➔ SIPp: generador de tráfico y pruebass para
SIP (muy utilizada)

➔ SIPsak: SIP swiss army knife

HERRAMIENTAS UTILIZADAS


■ SIPp

HERRAMIENTAS UTILIZADAS


■ SIPp

Run sipp with embedded server (uas)
scenario:
./sipp -sn uas

On the same host, run sipp with embedded
client (uac) scenario:
./sipp -sn uac 127.0.0.1

PRUEBAS DE CARGA
■ 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.

PRUEBAS DE CARGA

Call stats
2500

2000

ConcurrentCalls
1500

TotalCallCreated
SuccessfulCall(C)
FailedCall(C)

1000

400 Llamadas
concurrentes
500

Análisis realizado
por Saúl Ibarra
http://www.saghul.net
0
2009-04-27 22:37:30:372 1240864650.372034 2009-04-27 22:43:30:383 1240865010.383449
2009-04-27 22:34:30:367 1240864470.367186 2009-04-27 22:40:30:377 1240864830.377034

PRUEBAS DE CARGA

Call stats
2500

2000

1500
ConcurrentCalls
TotalCallCreated
SuccessfulCall(C)
FailedCall(C)

1000

400 Llamadas
500
concurrentes
Análisis realizado
por Saúl Ibarra
0
2009-04-28 19:48:13:298 1240940893.298463 2009-04-28 19:54:05:895 1240941245.895646
2009-04-28 19:45:13:293 1240940713.293946 2009-04-28 19:51:13:302 1240941073.302805

PRUEBAS DE CARGA

Call stats
2500

2000

1500 ConcurrentCalls
TotalCallCreated
SuccessfulCall(C)
FailedCall(C)
1000

400 Llamadas
concurrentes
500

Análisis realizado
por Saúl Ibarra
0
2009-04-27 22:59:26:051 1240865966.051527 2009-04-27 23:05:26:506 1240866326.506768
2009-04-27 22:56:26:043 1240865786.043268 2009-04-27 23:02:26:055 1240866146.055127


PLAN DE TRABAJO

 Consideraciones



 Recomendaciones

■ CONCLUSIONES


ALGUNAS RECOMENDACIONES

Teniendo en cuenta todo lo anterior, podemos
plantear una serie de recomendaciones puntuales
de acuerdo al hypervisor seleccionado

Vmware se apalanca en binary
translation para virtualizar, esto
genera overhead para cierto tipo
de aplicaciones

VMWARE ESXi
- overhead
- time drift
- I/O

VMWARE ESX


XEN maneja
paravirtualización por medio
de su hypervisor, sin
embargo esto implica
implementar dos veces todos
los features a nivel de kernel
y para soporte de hardware


KVM maneja full
virtualization e incluye
paravirtualización para el
I/O.

La ventaja es que aprovecha
todas las funcionalidades del
kernel de linux sin
intermediación


Al no virtualizar realmente,
sino usar el mismo hardware
no tiene limitaciones en red.

 Parametros kernel

 RED HAT 5.3 hacia abajo
 clocksource=acpi_pm

 divider=10

 RED HAT 4.9 hacia abajo / SLES 10
 clock=pmtmr

 hpet=disable

 RED HAT 5.3 / 4.9 x86_64
 notsc

 nohpet

 clock=pit

 elevator=deadline

 Módulo ztxen

 Parametros ntp

 tinker panic 0
 server 127.127.1.0
 fudge 127.127.1.0 stratum 10

 USB passthrough (para USB timer)

 PCI passthrough (para presentar HW)

 ethtool -K eth0 tx off

 Kernel config CONFIG_HZ = 1000

 Conferencias con funcionalidad limitada o usar
app_conference

 No Grabar

 No transcoding

 SIP Puro

 Desagregación de la DB (independizar I/O)

 Ojo con Colas

 Mover la media aparte de la plataforma virtual
(en escenarios con carga pesada)


■ La selección entre OpenVZ/ Xen / VMware o
KVM depende del perfil de uso que vaya a
tener el sistema.

■ APLIQUE LAS MEJORES PRÁCTICAS DE
IMPLEMENTACIÓN DE VoIP

CONCLUSIONES
■ SI se puede usar asterisk virtualizado (y 3CX)

■ Tener en cuenta desempeño
 Disco

 Red

 Procesador

■ Técnicamente soporta 400-600 llamadas
simultaneas

 Analizar el tipo de carga para decidir

■ Solución de failover

CONCLUSIONES

“We have reduced our
number of data centers
from 155 to 7”

IBM, Aug 2007

CONCLUSIONES

Tiempo total:
50 horas
“En Febrero del 2009, para las elecciones en
Israel se usaron 34 instancias de asterisk sobre
Costo total por
AWS como dialers, llegando a 3500 llamadas
simultáneas y 350 intentos de llamada en horario
infraestructura: pico.”

Amocon 2009 USD 900
Greenfield Tech, Israel

CONCLUSIONES

“En Febrero del 2009, para las elecciones en
Israel se usaron 34 instancias de asterisk sobre
AWS como dialers, llegando a 3500 llamadas
simultáneas y 350 intentos de llamada en horario
pico.”

Greenfield Tech, Israel
Amocon 2009

OTRAS CONFERENCIAS

1.- Virtualización de Escritorios, de vuelta al
mainframe. Pero mejor!!!

2.- Implementando Cloud Privados. De la
propaganda a la acción.

3.- Por qué el Open Source es la alternativa
ideal para el desarrollo tecnológico de
Colombia y Latinoamerica

4.- Hacking y asegurando Asterisk

INFORMACION DE CONTACTO
MUCHAS GRACIAS POR SU ATENCIÓN.

Información de Contacto
Dirección: Carrera 15 # 79 – 37 Oficina 201A
Bogotá, Colombia
Teléfono: +57 – 1 655 98 00
USA Tel: +1 – 937 697 1769
Fax: +57 – 1 655 98 02
Internet: www.seaq.com.co
Contacto: ventas@seaq.com.co

HACKING Y ASEGURAMIENTO *

Tome el control de la
Información en su
Empresa

http://www.seaq.com.co

Virtualización VoIP: Del cobre hasta la nube

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Virtualización VoIP: Del cobre hasta la nube

Similaire à Virtualización VoIP: Del cobre hasta la nube (20)

Plus de Andres Mauricio Mujica Zalamea

Plus de Andres Mauricio Mujica Zalamea (7)

Dernier

Dernier (20)

Virtualización VoIP: Del cobre hasta la nube