La presentación define un escenario de aplicación de Asterisk sobre una plataforma Xen así como los trucos necesarios para hacer que funcione lo mejor posible.

Enjoy!

A continuación podéis ver/descargar la presentación del curso que hemos dado Zefe y yo sobre virtualización con Xen y KVM. La idea del curso es ofrecer una introducción a las distintas técnicas de virtualización existentes, y su uso con Xen y KVM. Asimismo, se contemplan algunos frontends como Enomalism o ConVirt, útiles a la hora de delegar tareas de administración, por ejemplo.

Hope you enjoy it!

PD: También he dejado la presentación en SlideShare.

Durante el Amoocon Kevin Fleming me comentó que en la nueva versión de DAHDI eso ya so sería necesario y acabo de comprobar que es cierto.

En DAHDI 2.2 se ha eliminado el RTC como fuente de tiempo para el subsistema DAHDI, ya que su funcionamiento era errático en ocasiones. En su lugar se utiliza el timming del propio kernel. Vamos a verlo:

Tras compilar y cargar dahdi_dummy 2.2 SIN modificar vemos que carga correctamente:

[2548770.332063] dahdi: Telephony Interface Registered on major 196
[2548770.332075] dahdi: Version: 2.2.0-rc5
[2548771.512873] dahdi: Registered tone zone 0 (United States / North America)


Comprobemos la fuente de tiempo:

ast16:/usr/src/asterisk/dahdi-tools-2.2.0-rc3# cat /proc/dahdi/1
Span 1: DAHDI_DUMMY/1 "DAHDI_DUMMY/1 (source: Linux26) 1" (MASTER)


Y un dahdi_test para ver que todo va bien:

ast16:/usr/src/asterisk/dahdi-tools-2.2.0-rc3# dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.996% 99.997% 99.998% 99.996% 99.999% 99.996% 100.000% 99.996%
99.999% 99.995% 99.999% 99.997% 99.997% 99.998% 99.999% 99.996%
100.000% 99.999% 99.995% 100.000% 99.614% 99.610% 99.614% 99.612%
99.616% 99.609% 99.614% 100.000% 99.997% 99.612% 99.613% 99.610%
99.614% 99.610% 99.614% 99.610% 99.614% 99.609% 100.000% 99.614%
99.610% 99.613% 99.611% 99.613% 99.610% 99.614% 99.609% 100.000%
99.614% 99.609% 99.614% 99.610% 99.614% 99.998% 99.610% 99.614%
99.611% 99.999% 99.614% 99.610% 99.614% 99.610% 99.613% 99.610%
99.613% 99.609% 99.614% 99.610% 100.000% 99.614% 99.610% ^C
--- Results after 71 passes ---
Best: 100.000 -- Worst: 99.609 -- Average: 99.758634, Difference: 99.998285


DAHDI 2.2 todavía está en estado de release candidate, pero pronto se espera una versión estable.

Podéis descargar dahdi-linux y dahdi-tools aquí.

PD: La foto se la tomo prestada a Elio.

Todos los materiales expuestos durante los 2 días estarán disponibles en la web del Amoocon con vídeos incluidos tras las pertinentes labores de post-producción, pero por si a alguno le interesa, ya he colgado todos los materiales de “Running Asterisk in virtualized environments” aquí.

En el fichero comprimido podéis encontrar lo siguiente:

• Presentación en ODP y PDF.
• Ficheros de configuración de Asterisk
• Configuración de Xen
• Configuración de KVM
• Escenarios de SIPp utilizados
• Resultados de las pruebas

Espero que os sirva!

Tal y como me esperaba, la instalación ha sido sencilla y no he necesitado ninguna configuración especial en el servidor Xen, aparte de la típica para una máquina virtual HVM (con Windows no podemos utilizar paravirtualización).

En concreto he utilizado esta configuración:

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 512
name = "Win7"
vif = [ 'type=ioemu, bridge=eth0' ]
acpi = "1"
# Install
#disk = [ 'phy:/dev/xenvol/win7,ioemu:hda,w', 'file:/root/ISOs/windows7_build7000.iso,hdc:cdrom,r' ]
# Run
disk = [ 'phy:/dev/xenvol/win7,ioemu:hda,w' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
device_model = '/usr/lib/xen/bin/qemu-dm'
boot="dc"
vnc=0
vnclisten="0.0.0.0"
vncpasswd=''
#serial='pty'
keymap = 'es'
usb=1
usbdevice='tablet'

Tras una instalación no demasiado larga he estado un rato enredando y la verdad es que me ha gustado más que Vista, ysegún se esta comenando por todo Internet Windows 7 sí que parece ser el sucesor de Windows XP. Os dejo unas capturillas de pantalla en las que se puede ver que primero se ha accedido por VNC (para la instalación y configuración inicial) y posteriormente por RDesktop, que funciona mucho mejor que VNC al menos en entornos Windows sobre Xen.

En Xen hay varios factores que pueden determinar el rendimiento tanto de las máquinas virtuales como del sistema completo:

El Kernel
Oficialmente solo se mantiene una versión parcheada del kernel 2.6.18.8 para su uso como dom0. Algunas distros han ido portando hacia adelante estos parches de Xen y por ejemplo Debian Lenny dispone del kernel 2.6.26 para su uso como dom0. Aunque se pueden utilizar los Kernels empaquetados por las distintas distros, algunos usuarios han reportado problemas. Para obtener el mejor rendimiento posible y minimizar los problemas se recomienda utilizar el Kernel oficial (2.6.18.8) siempre que sea posible, al menos hasta que los parches de Xen para el dom0 sean incluidos en el mainline del Kernel (se espera que para la versión 2.6.29).

Red
El rendimiento del sistema de red es otro de los factores que más preocupan a los usuarios de sistemas virtualizados. A la hora de determinar un posible fallo de rendimiento en el rendimiento de red hay varios elementos que pueden estar involucrados: la tarjeta de red, el switch y el driver de la tarjeta de red.

Supongamos un sistema con 10 máquinas virtuales. Esto supone que (si utilizamos bridging en las interfaces de red) que habrá 10 equipos transmitiendo datos y que el switch al que este conectado el servidor tendrá 10 MACs en una de sus bocas.Algunos switches y tarjetas de red pueden no resultar adecuados para soportar una carga tan elevda de tráfico, por lo que no vale usar cualquier switch (no al menos ese Linksys de 8 puertos ).

La velocidad de transferencia es otro de los mayores problemas de la virtualización. Esto se puede solucionar (si el entorno virtualizado es GNU/Linux) deshabilitando el checksum de los paquetes en transferencia. Al no existir como tal un medio ya que la comunicación es a nivel de Kernel, es seguro deshabilitar esta opción. Para ello ejecutaremos lo siguiente en los domU:

# ethtool -K eth0 tx off

Y en el dom0:

# ethtool -K eth0 tx on

Disco Duro
Supongamos de nuevo que tenemos ese servidor con 10 máquinas virtuales. Utilizar particiones independientes para cada máquina virtual ofrece mayor rendimiento que utilizar ficheros individuales. Utilizar LVM y una partición independiente para cada máquina virtual suele ser lo más adecuado.

Además del esquema de particionado, el hecho de tener 10 máquinas virtuales encendidas supone demasiadas escrituras concurrentes en disco por lo que conviene utilizar un sistema RAID (0 o 5 por ejemplo) para que estos procesos de lectura/escritura  no comprometan el rendimiento del sistema virtualizado.

En el servidor que tengo en casa (procesador QuadCore, 4GB de RAM y 2 discos duros en RAID 0) con 14 máquinas virtuales arrancadas el rendimiento es muy bueno

El problema que tenemos a la hora de compilar ztdummy o dahdi_dummy en Xen es la fuente de timming. En las versiones actuales de Zaptel y DAHDI el timming (cuando no tenemos tarjetas) se puede obtener de tres fuentes:

1. El HPET.
2. El RTC.
3. El tick del sistema (opción CONFIG_HZ)

En Xen (si usamos el kernel oficial 2.6.18 parcheado) no tenemos disponibles ni la primera ni la segunda opción, pero Zaptel se cree que SÍ que tenemos acceso al RTC, y por tanto falla.

Para solucionarlo tenemos que editar el fichero ztdumy.c o dahdi_dumy.c y localizar la siguiente sección:

/*
* NOTE: (only applies to kernel 2.6)
* If using an i386 architecture without a PC real-time clock,
* the #define USE_RTC should be commented out.
*/
#if defined(__i386__) || defined(__x86_64__)
#if LINUX_VERSION_CODE >= VERSION_CODE(2,6,15)
/* The symbol hrtimer_forward is only exported as of 2.6.22: */
#if defined(CONFIG_HIGH_RES_TIMERS) && LINUX_VERSION_CODE >= VERSION_CODE(2,6,22)
#define USE_HIGHRESTIMER
#else
#define USE_RTC
#endif
#else
#if 0
#define USE_RTC
#endif
#endif
#endif

Si os fijáis el comentario ya nos indica lo que tenemos que hacer: comentar las líneas correspondientes para que no se defina el flag USE_RTC. Para ello modificamos el código anterior dejándolo así:

/*
* NOTE: (only applies to kernel 2.6)
* If using an i386 architecture without a PC real-time clock,
* the #define USE_RTC should be commented out.
*/
#if defined(__i386__) || defined(__x86_64__)
#if LINUX_VERSION_CODE >= VERSION_CODE(2,6,15)
/* The symbol hrtimer_forward is only exported as of 2.6.22: */
#if defined(CONFIG_HIGH_RES_TIMERS) && LINUX_VERSION_CODE >= VERSION_CODE(2,6,22)
#define USE_HIGHRESTIMER
#else
//#define USE_RTC
#endif
#else
#if 0
//#define USE_RTC
#endif
#endif
#endif

De esta manera, Zaptel o DAHDI compilarán sin problemas en un entorno Xen y podremos utilizar el dummy driver necesario para MeetMe o el IAX trunking.

En casa tengo un servidor con Xen y el kernel oficial, un 2.6.18 parcheado. Esta versión no tiene soporte para HPET, por lo que se usaría el RTC, pero como en Xen tampoco funciona eso es necesario comentar las líneas en las que pone:

#define USE_RTC

al principio del fichero dahdi_dummy.c.

Tras hacer lo propio, me encuentro con el siguiente problema al compilar DAHDI:

CC [M]  /usr/src/asterisk/dahdi-linux-2.1.0/drivers/dahdi/dahdi_dummy.o
/usr/src/asterisk/dahdi-linux-2.1.0/drivers/dahdi/dahdi_dummy.c: In function ‘dahdi_dummy_timer’:
/usr/src/asterisk/dahdi-linux-2.1.0/drivers/dahdi/dahdi_dummy.c:223: warning: implicit declaration of function ‘hrtimer_set_expires’

Mirando el código de dahdi_dummy, me encuentro lo siguiente:

/* use kernel system tick timer if PC architecture RTC is not available */
static void dahdi_dummy_timer(unsigned long param)
{
hrtimer_set_expires(timer, jiffies + 1);
add_timer(&timer);
...

Al parecer el error viene porque se está utilizando una función del HPET cuando realmente debería usarse el system tick. Rápidamente me he dirigido al visor del repositorio de Subversion, para ver qué había cambiado desde DAHDI 2.0.0, ya que esa versión me funcionaba correctamente. Al acceder al visor me he encontrado con que había un nuevo tag: DAHDI 2.1.0.1! :-O Al mirar el ChangeLog veo que han solucionado justo el bug que había encontrado!

Por lo tanto, si estás tratando de instalar DAHDI 2.1.0 en Xen mejor que utilices DAHDI 2.1.0.1, ya que sino se producirán errores de timming. De momento no hay paquetes comprimidos de esta última versión, por lo que es necesario obtenerla del repositorio de Subversion:

svn co http://svn.digium.com/svn/dahdi/linux/tags/2.1.0.1 dahdi-linux-2.1.0.1
svn co http://svn.digium.com/svn/dahdi/tools/tags/2.1.0.1 dahdi-tools-2.1.0.1

Enjoy!

Uno de los cursos en los que me infiltrado es en el de Introducción a la Virtualización, en la que se ven OpenVZ y Xen. Zigor Egiguren (Cosmos) se ha encargado de la parte de OpenVZ y yo de la de Xen.

Por si alguno lo encuentra de interés, aquí os dejo la documentación que voy a utilizar el día de hoy, la tenéis descargable en http://www.slideshare.net/saghul

Hoy día 26 de marzo se celebraba el primer Document Freedom Day, así que pensé que sería un buen día para publicar este documento que redacté hace poco.

En él se detalla la instalación de un sistema de virtualización Xen, compilándolo desde los fuentes, y utilizando kernels personalizados. También se detalla como montar domUs con soporte para Full Virtualization (HVM) o Paravirtualización (PV).

Espero que os sirvan

Podéis descargarlo de aquí en ODT y aquí en PDF. (También están en la sección de Documentos)