CategoríaDocumentacion

Xen: Creación y configuración de una máquina virtual (pt2)

Si la instalación y configuración de Xen resultó ser fácil, lo que mostraré a continuación es mucho más sencillo. Para instalar una máquina nueva (con Debian) debemos ejecutar el siguiente comando:

xen-create-image --hostname=xen1 --size=5Gb --swap=256Mb --ide \
--ip=192.168.0.101 --netmask=255.255.255.0 --gateway=192.168.0.1 --force \
--dir=/vm --memory=128Mb --arch=i386 --kernel=/boot/vmlinuz-2.6.26-2-xen-686 \
--debootstrap --dist=lenny --mirror=https://ftp.cl.debian.org/debian/ --passwd

Si destripamos los parámetros nos damos cuenta que le estamos asignando (en orden) el hostname, tamaño de disco duro, cantidad de swap, tipo de disco, dirección ip, netmask, gateway, el directorio donde instalarla, ram, arquitectura, kernel para usar, metodo de instalación, distribución, mirror para descargar y por último, que nos pregunte la pass de root cuando termine de instalar. Estos parametros se pueden cambiar según los requerimientos.

El archivo de configuración de las máquinas virtuales es algo como:

kernel = '/boot/vmlinuz-2.6.26-2-xen-686'
ramdisk = '/boot/initrd.img-2.6.26-2-xen-686'
maxmem = '256'
memory = '64'
root = '/dev/hda2 ro'
disk = [
'file:/vm/domains/xen01/swap.img,hda1,w',
'file:/vm/domains/xen01/disk.img,hda2,w',
]
name = 'xen01'
# Red
vif = [ 'ip=192.168.20.202,mac=00:16:3E:6F:E3:3B' ]
# Comportamiento
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

Podemos modificar arbitrariamente las opciones segun lo que nosotros necesitemos, tambien existen más opciones que le podemos agregar, como la asignacion de X cpus, decirles que cpu usen, por ejemplo si tenemos 4 núcleos, asignarle el 1 y el 4.

vcpus = 2;
cpus = '0,3'

De esta forma le estamos asignando 2 núcleos virtuales y le estamos diciendo que use los nucleos 0 y 3.

Xen: Instalación y configuración (pt1)

Esta es la primera parte de una serie de artículos que escribiré sobre cómo configurar y usar Xen, crear y administrar máquinas virtuales, clonación y migración, asignación de procesadores, memoria y configuración de la red entre otras cosas.
Aunque soy usuario de Archlinux, los servidores que administro están bajo Debian, por lo que estos tutoriales los haré en base a esa distribución.

A continuación, una serie de instrucciones de cómo instalar y dejar corriendo Xen en la máquina servidor en sencillos pasos:

Debemos instalar el kernel correspondiente y las utilidades de xen. Lo hacemos todo con el siguiente comando:

apt-get install xm-utils-common xen-linux-system-2.6.26-2-xen-686 linux-image-2.6.26-2-xen-686

Se van a instalar automáticamente las dependencias y otras utilidades que se necesiten.
Reiniciamos y booteamos con el kernel correspondiente: Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-2-xen-686

Hay que fijarse que se instalaron dos: linux-image y xen-linux-system. El primero se usará para que las máquinas guest booteen y el segundo para el domU.

Cuando ya hayamos iniciado con xen-linux-system, debemos editar el fichero /etc/xen/xend-config.sxp. Vamos a la linea donde configuramos la red, debe aparecer algo como “(network-script network-dummy)” y debemos cambiarlo por “(network-script network-bridge)“. Cuando intentemos crear nuestra primera máquina virtual, xen nos enviará un mensaje advirtiendo que debemos configurar esa linea en el fichero de configuración.

Eso es todo.

Balancear la carga manualmente (definir mas de un gateway)

La idea de balancear la carga manualmente es poder definir más de un gateway para distintos destinos, especificados por nosotros mismos. De esta manera, podremos tener dos o más salidas a internet y definir salidas hacia distintos rangos de direcciones ip.

multi gateway

Esto sirve de gran utilidad cuando nos conectamos a una red wifi que –por casualidad– llega hasta nuestro lugar de trabajo o nuestras casas e inocentemente queremos usarla. Por ejemplo, si tenemos un lugar de descargas, podemos dejar una máquina con una ruta estática que haga que cuando conecte a una IP x.x.x.x su salida a internet sea por el gateway predefinido por nosotros.
Para esto vamos a usar el comando route.

Seguir leyendo

Saporm: Simple abstraccion de bases de datos

Hace un par de dias venia en el bus hacia mi casa y se me ocurrio una idea. Muchos pensara que ya existe esto que se me ocurrio, que existen frameworks, etc. Pero mi idea es hacer algo mas simple aun, se me ocurrio la idea de desarrollar un ORM (Object Relational Mapping) simple, que me permita de manera sencilla abstraer la base de datos para poder trabajarla como objeto. Mientras veina en el bus, pensaba el modelo logico para llevar acabo esta idea, luego de unos dias por fin he podido empezar a codificar lo que será desde ahora en adelante: Saporm. Como Hibernate para Java o Doctrine para PHP, la idea de este ORM es hacer las cosas aun mas faciles y mi idea, principalmente, es orientarla a proyectos pequeños y no a enterprise.

La idea es que este ORM/Framework haga todas las tareas de consultas y accesos a la base de datos de manera mas simple, por ejemplo, en Saporm, para que el framework sea capaz de abstraer la base de datos solo hay que crear una clase con los atributos correspondientes, segun los campos que tenga la tabla de la base de datos.
Por ejemplo, tenemos dentro del directorio “model” la siguiente clase:
(Usuarios.class.php)

  1. < ?php
  2. class Usuarios extends Core{
  3.    /* Variables necesarias por el ORM, es necesario que se declaren */
  4.    public $table_name;
  5.    public $socket;
  6.  
  7.    /* Variables del usuario */
  8.    public $id;
  9.    public $username;
  10.    public $password;
  11. }
  12. ?>

Saporm se encargará, automaticamente, de mapear la tabla “Usuarios” con sus atributos “id, username y password” y nos permitirá trabajarla como si de un objeto se tratara. La herramienta nos creara un objeto con el nombre Usuarios que contará con varios métodos y atributos, como por ejemplo:

$usuarios->search();
$usuarios->loadData();
$usuarios->select();
$usuarios->query();
$usuarios->insert();
$usuarios->update();

Seguir leyendo

Sistemas de ficheros: ext3 o XFS?

El escenario era el siguiente:
Servidor Intel Xeon con cuatro núcleos de 2Ghz cada uno, 8Gb de ram y un arreglo de discos SCSI en Raid5 (300Gb). La funcionalidad del servidor es ser un host de máquinas virtuales. El diléma era qué filesystem usar, estába entre ext3 y XFS entonces me puse a googlear y encontre varios benchmarks y comentarios interesante al respecto, donde se comparaban esos dos o más sistemas de ficheros. Mis necesidades eran encontrar un sistema de ficheros que sea rápido y que trabaje bien con ficheros de gran tamaño (>=1Gb).
Navegando y navegando, me encontré con un benchmark en el sitio debian-administrator que me ayudó en parte a decidir lo que debía hacer.
En dicho benchmark se analizaron los siguientes puntos:

* Operations on a large file (ISO image, 700MB) Copy ISO from a second disk to the test disk
* Recopy ISO in another location on the test disk
* Remove both copies of ISO

* Operations on a file tree (7500 files, 900 directories, 1.9GB) Copy file tree from a second disk to the test disk
* Recopy file tree in another location on the test disk
* Remove both copies of file tree

* Operations into the file tree List recursively all contents of the file tree and save it on the test disk
* Find files matching a specific wildcard into the file tree

* Operations on the file system Creation of the filesystem (mkfs) (all FS were created with default values)
* Mount filesystem
* Umount filesystem

Según ese artículo, el fs que mejor trabaja con ficheros de gran tamaño es xfs. Se hicieron dos tipos de pruebas, comparando jfs, xfs, ext3 y reiserfs. En la primera ganó xfs y ext3, en la segunda xfs y jfs.

The initial copy of the large file took longer on Ext3 (38.2 secs) and ReiserFS (41.8) when compared to JFS and XFS (35.1 and 34.8). The recopy on the same disk advantaged the XFS (33.1 secs), when compared to other FS (Ext3 = 37.3, JFS = 39.4, ReiserFS = 43.9). The ISO removal was about 100 times faster on JFS and XFS (0.02 sec for both), compared to 1.5 sec for ReiserFS and 2.5 sec for Ext3! All FS took comparable amounts of CPU to copy (between 46 and 51%) and to recopy ISO (between 38% to 50%). The ReiserFS used 49% of CPU to remove ISO, when other FS used about 10%. There was a clear trend of JFS to use less CPU than any other FS (about 5 to 10% less). The number of minor page faults was quite similar between FS (ranging from 600 – XFS to 661 – ReiserFS).
Conclusion : For quick operations on large files, choose JFS or XFS. If you need to minimize CPU usage, prefer JFS.
Operations on a file tree (7500 files, 900 directories, 1.9GB)
[…]
Conclusion : For quick operations on large file tree, choose Ext3 or XFS. Benchmarks from other authors have supported the use of ReiserFS for operations on large number of small files. However, the present results on a tree comprising thousands of files of various size (10KB to 5MB) suggest than Ext3 or XFS may be more appropriate for real-world file server operations. Even if JFS minimize CPU usage, it should be noted that this FS comes with significantly higher latency for large file tree operations.

Todo indicaba que debia usar XFS, pero la realidad era otra.
Seguir leyendo

DomainKeys (DK) y DomainKeys Identified Mail (DKIM)

DomainKeys (DK) y DomainKeys Identified Mail (DKIM) son métodos de valicación de correo electrónico que permiten validar y firmar, mediante firma digital (clave pública y clave privada), los correos entrantes y salientes de nuestro servidor de correos. Esto permite que un dominio sea responsable por los correos que se envien a través de el para asegurarse que lleguen al inbox o que, de lo contrario, lleguen directo al junk.
Para validar la autenticidad de un remitente existen varias formas a nivel de dominio (dns) como es el SPF, Sender-ID, DK y DKIM.

Este último tiempo he estado trabajando con postfix validando los correos salientes para llegar al inbox de los servidores de correo más populares como Gmail, Yahoo! y Hotmail (msn, live, etc).
Estuve analizando las especificaciones RFC de cada protocolo (RFC4870 – DK; RFC4871 – DKIM), probandolas e implementandolas, llegando a distintas conclusiones. Básicamente, el diagrama de funcionalidad es el siguiente:

dk_graph

Seguir leyendo