En el día de hoy, vamos a ver como configurar nuestros XenServer para poder enviar correos electrónicos desde ellos mismos utilizando un smarthost.

Es útil configurar un cliente de correo como mailx para poder enviarnos notificaciones de nuestros scripts como por ejemplo los scripts que se ejecuten de forma automática utilizando cron.

Citrix XenServer, tiene un corazón CentOS, por ello podemos instalar paquetes rpm compilados para CentOs 5. Desde un mirror cualquiera como:

http://mirror.ovh.net/ftp.centos.org/5/os/x86_64/CentOS/

Descargamos el paquete rpm que necesitamos:  mailx-8.1.1-44.2.2.x86_64.rpm

Una vez descargado, lo instalamos:

root@xenserver01# rpm –Uvh mailx*

warning: mailx-8.1.1-44.2.2.i386.rpm: Header V3 DSA signature: NOKEY, key ID e8562897

Preparing…                ########################################### [100%]

1:mailx                  ########################################### [100%]

Configuramos los parámetros siguientes del fichero: /etc/ssmtp/ssmtp.conf

mailhub=<tu servidor de correo>

rewriteDomain=<tu dominio>

Ahora ya puedes enviar mails desde tus XenServer a tu correo electrónico con mailx

root@xenserver01# cat fichero | mailx –s “test” tudireccion@correo.com

Espero que como siempre, te haya sido de utilidad. Saludos

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, hoy os presento Xen Cloud Plataform (XCP), ya desde la versión 1.0 la estoy utilizando y creo que ha llegado el momento de hablar un poco sobre este proyecto libre.  Para los que no lo conozcáis, deciros que es una solución open-source derivada de Citrix XenServer 5.6.FP1 totalmente funcional.

XCP es una versión empaquetada de GNU/Linux CentOS (kernel 2.6.32) con Xen 3.4.2 y XenAPI (XAPI).  Por lo tanto, los que ya estéis usando XenServer, vereis quela Xapi y sus comandos son los mismos y además  es compatible con XenCenter.

Hay mutiltud de herramientas de administración, tanto del uso tradicional del hipervisor como frontends de gestión de clouds, compatibles con XCP: http://wiki.xen.org/wiki/XenManagementTools

También nos ofrece, al igual que Citrix XenServer, soporte para HVM (si el servidor físico lo soporta),  paravirtualización de nuestros servidores GNU/Linux (PV) y soporte nativo de máquinas instaladas con Citrix XenServer.

Podéis ver una matriz de funcionalidades donde se compara Xen Cloud Plataform con las distintas versiones de licenciamento de Citrix XenServer:

http://wiki.xen.org/wiki/XCP/XenServer_Feature_Matrix

La instalación es idéntica a la que tenemos con Citrix XenServer, se basa en una imagen de cd .iso auto-arrancable que en unos pocos pasos permite tener el sistema completamente operativo.

Por supuesto trae consigo soporte para bootear sobre SAN, hbas, multipath, soporte para i-scsi y un largo etc. Que podeis ver en: http://xen.org/download/xcp/index.html

La última versión oficial disponible es la XCP 1.1 que recomiendo a todos los lectores, probarla, no deja indiferente

La página de descarga es: http://xen.org/download/xcp/index_1.1.0.html

Con esto, espero como siempre que os sea de utilidad. Saludos

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, hoy veremos como pasar una maquina virtual de un entorno VMware ESX a Citrix XenServer.

El procedimiento es muy sencillo, nos basamos en el formato OVF, soportando tanto por VMware como Citrix XenServer. OVF es un estándar abierto para empaquetar máquinas virtuales. El inconveniente es que no es en caliente, ya que necesitamos que la máquina virtual este apagada en el entorno VMware.

Accedemos a nuestro entrono VMware con vShpere Client, nos situamos sobre la máquina virtual que queremos exportar y vamos a File -> Export -> Export OVF Template. Lo exportamos a nuestro disco local y lo optimizamos para Web (OVF).

Una vez finalizado el tiempo de exportación, ya tendremos nuestra máquina virtual lista para ser importada a nuestro entorno Citrix XenServer.

Entramos a nuestro entorno XenServer con XenCenter. Sobre el pool donde queremos que esté nuestra máquina virtual vamos a File -> Import.

Añadimos como Filename el fichero OVF de la máquina virtual VMware.

Seleccionamos el SR donde colocar los discos de la máquina virtual y la red. Pasados unos minutos, ya tendremos la máquina virtual en nuestro entorno XenServer. No hay que olvidarse, una vez levantada la máquina virtual, de instalar las XenTools para que esté totalmente optimizada para Citrix XenServer.

Con este método ya podéis exportar vuestras máquinas virtuales ya sean VMware ESX/Workstation, VirtualBox, etc. A vuestro entorno Citrix XenServer. Como siempre, espero que os haya sido de utilidad. Un saludo!

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, después de unos días de vacaciones… hay que volver a la carga. En el último post sobre monitorización de XenServer con Nagios, faltaba ver la monitorización de storage y otros checkeos avanzados para tener bien controlada nuestra infraestructura.

1. Para monitorizar los SR de nuestro pool, primeramente hay que extraer la información que nos da la Xapi:

/usr/bin/xe sr-param-get uuid=<UUID-SR> param-name=physical-size

/usr/bin/xe sr-param-get uuid=<UUID-SR> param-name=physical-utilisation

Mediante estos datos, podemos establecer la lógica que queramos para que nos informe del estado del disco:

#/bin/bash

let total_alloc=`sudo /usr/bin/xe sr-param-get uuid=84ca4fbd-f150-1f62-c9e4-ee4a656558d5 param-name=physical-utilisation`

let total_bytes=`sudo /usr/bin/xe sr-param-get uuid=84ca4fbd-f150-1f62-c9e4-ee4a656558d5 param-name=physical-size`

let factor=1073741824

total_alloc_Gb=`expr $total_alloc \/ $factor`

total_bytes_Gb=`expr $total_bytes \/ $factor`

let free_space=`expr $total_bytes_Gb – $total_alloc_Gb`

total_percentage=`expr 100 \* $total_alloc_Gb \/ $total_bytes_Gb`

#echo $free_space

#echo $total_percentage

if [ $total_percentage -ge "90" ] ; then

echo “CRITICAL: Disc al $total_percentage%”

EXIT=2

else

if [ $total_percentage -ge "80" ] ; then

echo “WARNING: Disc al $total_percentage”

EXIT=1

else

echo “OK: Disc al $total_percentage%”

EXIT=0

fi

fi

exit $EXIT

 

2. Otro checkeo importante que nos puede ser muy útil es comprobar el estado de la XAPI en cada servidor:

#!/bin/bash

#Check que comprueba el estado de la XAPI

#contamos los procesos que hay de xapi

procs=`ps -elf | grep xapi | grep -v grep | wc -l`

#Verificamos que haya algun proc xapi y si no lo hay, critical

if [ -z "$procs" ] ; then

echo “Critical: No hay procesos de Xapi”

exit=1

else #Hay procesos, pues lanzamos una peticion para ver si respnde ok

#Vemos si es capaz de conectar con la Xapi y extramos el número de hosts del pool

test_xapi=`sudo xe host-list | grep name-label | wc -l`

#test_xapi=”1″ #Fuerza a warning

if [ $test_xapi -gt 0 ]; then

ok_test=$(sudo xe host-list name-label=`hostname` params=name-label –minimal)

echo “OK: XAPI respondiendo en $ok_test “

exit=0

else

new_test=$(sudo xe host-list name-label=`hostname` params=name-label –minimal)

echo “Warning: Hay procs de XAPI pero algo falla $new_test”

exit=1

fi

fi

#Salida con el codigo de error para Nagios

exit $exit

A grandes rasgos el checkeo comprueba primeramente que hay procesos de Xapi en la “GNU/Linux LAND” y si existen, ejecuta un xe-host-list. Si este falla retornará código de error ya que aunque haya procesos, la XAPI no responde.

3. Estado de los caminos del Multipath

Es importante tener bien monitorizados los caminos si usáis multipath para los que utilicéis una cabina de discos. Una forma de comprobar que están todos OK es filtrar por faulty en la salida de multipath –ll

#!/bin/bash

fault=`sudo /sbin/multipath -ll | grep faulty | wc -l`

if [ $fault -gt 0 ]; then

echo “Algun camino caído”

exit 1

else

echo “Todos los caminos: OK”

exit 0

fi

Con esto, espero haberos dado herramientas para que os programéis vuestros propios monitores, ya sea medianteXAPI o mediante comandos gnu/Linux y si me permitís, me encantaría saber que monitorizáis de vuestros XenServers. Un saludo.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes. Llega fin de año y es momento de hacer un resumen, esta semana le toca a las tecnologías de virtualización de servidores, hablaremos de lideres, zombis, despistados y otra hierbas.

Para tener un criterio único he cogido el Cuadrante Mágico de Gartner del 2010 y del 2011 y los he comparado, las conclusiones con interesantes:

Si observamos a VMware, no ha cambiado mucho pero hay datos interesantes:

1. Oracle ha madurado su porfolio de soluciones y en el 2012 pasará examen, veremos si su apuesta basada en la pila de soluciones Oracle juega a su favor o en contra. El mercado tendrá la última palabra.

2. Microsoft ha hecho los deberes este año, Live Migration, Gestión dinámica de memoria y Azure le han llevado al cuadrante de lideres.

3. Citrix tiene un crecimiento fuerte basado en la calidad de XenDesktop y su apuesta clara hacia el cloud computing.

4. La adquisición de Novell por Attachmate Group ha diluido su presencia en el mundo de la virtualización ¿Es el principio del fin para Novell?

¿Que pasará en el 2012? Veremos una doble batalla, tanto en el terreno de la virtualización como en cloud computing.

El primer enfrentamiento será entre vSphere 5 y Windows 8 Server Hyper-V. Donde VMware ha de hacer tanto esfuerzo en mantener la distancia como Microsoft en convencer a los clientes de la madurez de su tecnología.

En el terreno de cloud computing no se olviden de Citrix, que con la reciente adquisición de cloud.com puede haber encontrado un atajo frente a sus competidores. Será interesante ver el desarrollo de su modelo cloud.

Será un año apasionante, pero mantengo una duda desde hace años … ¿Por qué es Mágico este Cuadrante? ¿Lo hace Gandalf?

Aprovecho para desearos Felices Fiestas, agradeceros el seguirnos en el blog continuamente y confiar en que tengáis un feliz entorno virtual y familiar

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigos, hoy voy a repasar el Webinar de Citrix de la semana pasada, “XenServer 6.0 Technical Master Class” con Lee Bushen y Steve Benton ya que fue muy constructivo y creo que puede ser de vuestro interés.

Podéis descargarlos el material desde:

https://citrix.sharefile.com/d/sa724d4cc19543f8b

En el primer cuarto de hora se pudo ver el funcionamiento interno de XenServer, donde se mostró de una forma muy gráfica [PAG 8 del pdf], los dos “pueblos” que componen este sistema. Por un lado “Xenville” donde vemos “xe”, la XAPI y la “XenServer Pool DB (state.db) y por otro lado la parte “Linux Land”, donde al final, todo lo que interpreta la XAPI, se transforma en ficheros de configuración GNU/LINUX.

Posteriormente se explicó algo que ya hemos hablado en este blog, como XenServer organiza el Storage con sus diferencias y modalidades. SR’s, PBD’s, VBD’s. Una parte muy interesante de esta sección fue cuando explicaron cómo se organizan internamente los snapshots, en función del tipo de almacenamiento que podemos utilizar, NFS y Storage Local, LVMD, iSCSI y FC.

Podemos complementar el PDF con la documentación oficial de Citrix sobre los snapshots: http://support.citrix.com/article/CTX122978

Del mismo modo que el storage, en parte de comunicaciones, se explicó desde el hardware hasta llegar a los dispositivos de red virtuales, el funcionamiento de los bridges y como XenServer utiliza el bonding.

Os dejo también una lista de comandos útiles de Linux y XenServer: https://citrix.sharefile.com/d/s53888bbff9b44949

Y la Network Throughput Guide: http://wiki.xen.org/wiki/Network_Throughput_Guide

En general el Webinar estuvo muy bien. Aplaudo la iniciativa de Citrix y de otras compañías que ofrecen este tipo de seminarios gratuitos para los fans de sus plataformas.

Con esto amigos, nos vemos la semana que viene con la monitorización del storage con Nagios. Aprovecho también para desearos unas felices fiestas a todos.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, hoy os traigo la continuación del post de la semana pasada sobre la monitorización de servidores Citrix XenServer con Nagios.

En el post anterior vimos como configurar Nagios para utilizar sus plugins sin necesidad de instalar nrpe y nos quedamos en la configuración de estos checkeos para monitorizar nuestros Hosts.

Empezamos con la monitorización básica del host.

1. Las CPU’s estén trabajando sin rebasar el 80% de su capacidad.
2. Que la memoria RAM no sobrepase el 80% de espacio ocupado.
3. Que la partición / no se quede sin espacio.
4. Que el Load Average no sobrepase la carga máxima por Cores.
5. Que el/los SR’s no se queden sin espacio.

1.- Para monitorizar la CPU. Recomiendo usar un checkeo personalizado ya que los valores que extraen los plugins originales de Nagios, no extaen la información del hipervisor. Por ejemplo podemos hacer un script como este:

2.- Para la memoria:

3.- Para el disco local /, vamos a utilizar el plugin de nagios. Simplemente definimos el comando en el servidor Nagios como:

Definimos el servicio

4.- Del mismo modo configuraremos el checkeo para el “load average”

Ya tenemos monitorizado nuestro Host. Como habrás visto, la programación de checkeos para Nagios es muy sencilla y lo puedes hacer con el lenguaje de programación que te sea más cómodo.

Esto es todo por hoy. La semana que viene veremos como monitorizar el storage,  nuestro pool y otros checkeos más avanzados. Espero como siempre que te haya parecido interesante. Saludos!!

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Ferran Serafini y hoy vengo con un tema sencillo y a la vez muy potente. Seguramente habrás visto en XenCenter que los interfaces de red te permiten configurar QoS. Vamos a ver hoy, como implementarlo en nuestro entorno de virtualización con XenServer.

El QoS (Quality of Service) nos puede ser muy útil en entornos donde tenemos grandes tráficos de red y a su vez estos, sean limitados, hayamos detectado problemas, o bien necesitamos restringir el ancho de banda sin dejar de dar servicio a ciertas máquinas virtuales, etc.

Mediante QoS, XenServer permite establecer a nivel de red qué máquinas virtuales van a estar restringidas y cuáles no.

En algoritmo de XenServer para  QoS de red, se asocia a cada dispositivo VIF (Virtual Interface), por lo tanto se aplica a cada interface de red de cada máquina virtual. De este modo es posible tener una máquina con un interfaz limitado a 300 KB/s y otro a 1000KB/s. El valor que podemos establecer es la tasa máxima de transferencia.

Desde la CLI podemos configurarlo mediante:

xe vif-param-set uuid=<uuid_vif> qos_algorithm_type=ratelimit

xe vif-param-set uuid=<uuid_vif> qos_algorithm_params:kbps=300

Esto es todo por hoy, espero como siempre, haberte aportado algo nuevo e interesante. ¿Utilizas QoS en tu entorno, si es así que política establesces, criticidad de la máquina, segmento de red, etc?

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

Hola amigos, hoy vengo con una serie de buenas prácticas para mantener nuestros entornos XenServer lo más seguros posibles.

No soy ningún experto en seguridad, pero creo que lo podemos diferenciar en 3 niveles.

• Acceso a la administración
• Acceso a disco remoto
• Acceso a la red externa

Acceso a la administración (XAPI, SSH)

La XenAPI escucha por HTTP, puerto 80 es decir, texto plano y por HTTPS, puerto 443, cifrado por SSL. La interconexión entre XenCenter y XenAPI siempre se realiza por HTTPS con lo cual, nuestro acceso desde XenCenter siempre va a ser cifrado. El problema lo podemos tener en “plugins” de terceros que no implementen SSL para las peticiones hacia nuestros servidores.

Una buena práctica seria bloquear, en nuestros firewalls perimetrales, el acceso a nuestros servidores por el puerto 80 desde cualquier red y solo permitir HTTPS.

Es necesario también el acceso mediante SSH a nuestros servidores, pero solo desde la red administrativa/management. Un acceso por SSH por una contraseña insegura, expone a todo el entorno a un ataque.

Acceso a disco remoto (NFS, i-SCSI)

En el caso que estés utilizando un acceso a disco remoto vía ISCSI o NFS, es muy importante el aislamiento mediante interfaces dedicadas al propio storage. De este modo nunca expondremos el tráfico de disco (texto plano) a ninguna red de acceso.

Si usas NFS, los ficheros VHD de tu repositorio, están en texto plano así que sobretodo es importante que solo tengan acceso a estos recursos los servidores XenServer y administradores.

En el caso ISCSI, si tu cabina soporta CHAP para autentificar el “target” remoto, es la mejor opción. En ese caso solo van a tener acceso a esta LUN los servidores autentificados y asignados.

Acceso a la red externa

A menos que sea necesario, una máquina virtual no tiene por qué tener acceso a la red de administración del entorno XenServer.

Es una buena práctica establecer una interface física aislada para la administración y otra para hacerle llegar las demás redes (servicio) con el tráfico “taggeado” a nivel de switch. De este modo para la red de servicio, podemos crear un bridge por cada una de las vlans, aislando así cada uno de los entornos.

Eso es todo por hoy. Espero como siempre haberte aportado un nuevo granito de arena del mundo de la virtualización ¿Cómo securizas tu entorno XenServer?

Hola amigos, soy Ferran Serafini y hoy os enseñaré a instalar un Ubuntu 10.04 LTS paravirtualizado partiendo de una instalación HVM para nuestro entorno XenServer.

XenServer ya viene preparado para instalar Ubuntu. El método que voy a usar en este post quizá no es el más sencillo y rápido pero podremos ver muchos puntos interesantes y sobretodo la diferencia entre HVM y PV.

Lanzamos “New VM” usando el template “Other Install Media”. La llamaremos Ubuntu-HVM

La seleccionamos de nuestro repositorio de Isos donde previamente hemos descargado la ISO.

De CPU/Memoria se  puede poner lo que uno quiera, por ejemplo 2 CPUs i 512 MB de Ram. Posteriormente creamos su disco duro virtual

Finalizamos la configuración de la máquina virtual y arrancamos la máquina virtual siguiendo el asistente de instalación de una Ubuntu normal.

A modo de consejo personal, prefiero poner la swap en la primera partición del disco, de modo que el sistema este instalado en la ultima partición, así, en el momento que haga falta extender el disco de la maquina virtual por falta de espacio, simplemente haciendo un resize2fs redimensionariamos la partición.

Otro dato muy importante es que pygrub no soporta ahun EXT4, por lo tanto la particion /boot tiene que ser EXT3.

Ya tenemos nuestra Ubuntu 10.04 HVM. Ahora vamos a paravirtualizarla. Para ello, entramos como root y nos “guardamos” algunos datos que necesitaremos para la parametrización siguiente.

Las nuevas versiones de Ubuntu vienen ya con el nuevo grub-pc, accedemos al fichero /boot/grub/grub.cfg y localizamos las siguientes líneas ya que este no es “leíble” para pygrub:

### BEGIN /etc/grub.d/10_linux ###

menuentry ‘Ubuntu, with Linux 2.6.32-33-server’ –class ubuntu –class gnu-linux –class gnu –class os {

recordfail

insmod ext2

set root=’(hd0,1)’

search –no-floppy –fs-uuid –set 115a8cea-b9ac-4ecc-bc2e-3f172630cdc8

linux    /boot/vmlinuz-2.6.32-33-server root=UUID=115a8cea-b9ac-4ecc-bc2e-3f172630cdc8 ro   quiet

initrd   /boot/initrd.img-2.6.32-33-server

Ejecutamos la siguiente línea para especificar que la consola virtual de la maquina sera hvc0 y no tty1 para que podamos usar la consola de la maquina virtual de XenCenter.

sed -e “s/tty1/hvc0/ig” /etc/init/tty1.conf | sudo bash -c ‘cat > /etc/init/hvc0.conf’

Apagamos la máquina virtual.

El siguiente, totalmente opcional, consiste clonar la máquina virtual. Para no confundirnos, la renombramos el clon a Ubuntu-PV.

En el domain0 ejecutamos lo siguiente:

# xe vm-list name-label=Ubuntu-PV

uuid ( RO)           : fce7a414-4475-4875-0af0-632b4a8d6d03

Localizando así el uuid nuestra máquina virtual

# xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 HVM-boot-policy=”"

# xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 HVM-boot-params:”"

Con esto habremos eliminado los parámetros que interpreta XenServer para arrancar la máquina virtual como HVM.

Añadimos ahora los parámetros que vimos en el grub para arrancar  de forma paravirtualizada:

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-args=”root= UUID=115a8cea-b9ac-4ecc-bc2e-3f172630cdc8 ro quiet console=hvc0 xencons=hvc0″

Utilizaremos pygrub para arrancar la máquina virtual:

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-bootloader=pygrub

Como pygrub no es compatible con las nuevas versiones de grub, especificamos el kernel y el ramdisk directamente.

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-bootloader-args=”–kernel=/boot/vmlinuz-2.6.32-33-server –ramdisk=/boot/initrd.img-2.6.32-33-server”

Esta configuración del PV-bootloader-args hay que modificarla cada vez que se cambie/actualice el Kernel de la máquina virtual.

Con esto, arrancamos nuestra máquina virtual y ya la tenemos totalmente paravirtualizada. Vera un incremento de rendimiento muy interesante y estarás aprovechando toda la potencia de Xen. Ahora solo falta instalar las XenTools y convertir como template.

Eso es todo por hoy, espero como siempre, haberte enseñado algo útil para hacerte tu día a día con XenServer más sencillo y eficaz.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigo, hoy vamos a ver un repaso de las posibilidades disponibles de almacenamiento que tenemos para Citrix XenServer.

Veremos sus pros y sus contras para determinar cual puede ser nuestra mejor opción.

Las opciones que tenemos para un SR son:

Veamos las propiedades de cada una de estas tecnologías.

Local Storage: Por defecto XenServer utiliza los discos locales para poder almacenar máquinas virtuales. Utiliza LVM implementando el formato VHD para los VDIs. VHD permite que los discos sean sparse y que el espacio se vaya reservando en función del crecimiento de los discos de las máquinas virtuales. En las versiones 5.6  y 6.0 se implementa también thin provisioning, para el uso de escritorios vdi con XenDesktop. Fundamentalmente la ventaja principal es que según el Host físico y el tipo de disco, ofrecen un rendimiento superior, sobretodo si se usa discos en estado sólido. El problema es que no pueden ser compartidos como recurso de cluster y las máquinas virtuales instaladas en un disco de un host en local, no serán accesibles por los otros hosts del Pool.

Rápido y optimización de espacio. Pero no puede ser compartido por otros hosts.

NFS: XenServer soporta NFS3 por TCP/IP y permite crear SRs implementando VHD por lo tanto también son óptimos en cuanto a la optimización de espacio. A diferencia del disco local NFS es montado como recurso compartido del Pool y cualquier host puede acceder los VDIs almacenados en este tipo de recurso. Lo bueno también del NFS es lo estándar que es en el mundo UNIX/Linux, que por lo tanto hay multitud de appliances que permiten su gestión simplificada y no hace falta obligatoriamente disponer de una cabina de discos para trabajar en un entorno cluster.

Optimiza el espacio de disco “sparse”, gestión simplificada. Hay que vigilar que no sobrepase el espacio que hemos asignado, pues las VM crecen.

iSCSI: La utilización de iSCSI en XenServer permite  una implementación de los discos compartidos muy eficiente a nivel de red a bajo coste. Para ello hemos de configurar nuestra cabina de disco para presentar las LUNs que posteriormente se utilizaran como SRs. Una vez configurado se presenta al sistema como LVM donde los diferentes VIDs tendran un volumen lógico asociado. Los VDIs no pueden ser “sparse” y siempre ocuparan el espacio que hayamos definido en la creación del disco. Parecido a los discos tick de VMware.

Muy óptimo a nivel de red y por lo tanto muy buen rendimiento de disco para las máquinas virtuales. Se desaprovecha espacio al no ser discos dinámicos y a su vez ofrece mejor control del disco usado/libre.

Fibre Channel: Funciona en XenServer de forma parecida que iSCSI y disco local,  los discos son VHD corriendo sobre volúmenes lógicos LVM. Hay que disponer de HBAs compatibles con XenServer como Qlogic, Emulex, etc.

Alto rendimiento y optimización de espacio. Hay que tener HBAs compatibles con XenServer.

StorageLink: Sin duda la mejor opción si dispones de un licenciamiento Enterprise o Premium y tu cabina es Citrix Ready o si usas NexentaStor como appliance. StorageLink se define como la capa de interoperabilidad nativa entre XenServer y nuestra cabina de discos. Por lo tanto nos permite realizar clones súper rápidos, snapshots, thin provisioning en la propia cabina desde XenCenter.

Pensado como la solución más avanzada, es la mejor opción si necesitas un entorno de muchas máquinas y funcionalidades extra más allá del alojamiento de VDIs

Conclusiones: Principalmente, en mi modesta opinión, depende del presupuesto destinado y a la dimensión del entorno. Si estas usando una infraestructura de 4-6 nodos con unas 40 VM, un storage iSCSI contra una cabina de discos, funciona perfectamente. Si tienes de 2-3 servidores y no tienes cabina de discos, con una buena maquina sirviendo NFS funcionaría perfectamente. Y si tienes de 50 a 100 Hosts, con XenDesktop, muchos templates y una buena cabina, sin duda StorageLink.

¿Qué tecnología de almacenamiento utilizas en tus entornos?

Eso es todo por hoy amigo, espero como siempre que haya podido aportarte un granito de arena a tus conocimientos sobre la virtualización de servidores con XenServer.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola, amigos soy Ferran Serafini y hoy vamos a montar un entorno Citrix XenServer con almacenamiento compartido con FreeNAS.

Como sabéis aparte de FreeNAS hay muchos appliances destinados a ofrecer almacenamiento compartido de forma fácil, pero por su robustez y fácil configuración, he elegido FreeNAS, es muy útil para montar entornos de desarrollo o bien por si no podemos optar a una cabina de discos por presupuesto, en tiempo récord.

También permite la exportación a través de NFS o CIFS, pero en este caso vamos a presentar los discos mediante el protocolo ISCSI.

Primero de todo, nos descargamos la iso de FreeNAS en aquí. La arrancamos en modo (live) y la instalamos. Es muy sencillo. Podemos ver los pasos de la instalación aquí

Ahora es el momento de acceder a su página de administración

Vamos a configurar una LUN para ser servida a través de ISCSI para luego añadirla a nuestros servidores XenServer en 7 pasos.

1. Configuración Base
2. Extender Dispositivo (“LUN”)
3. Configurar Iniciador
4. Configurar Portal
5. Configurar Destinos
6. Destino / Disco
7. Iniciar ISCSI

Configuración Base

Primeramente configuramos el Nombre Base en la parte global de la configuración de ISCSI.

Nombre Base -> iqn.2011-03.fsmlab.org.istgt

Extender Dispositivo (“LUN”)

Configuramos el disco que vamos a servir como LUN en Extender Dispositivo

Configurar Iniciador

Ahora configuramos el inciador, vamos a permitir acceso para todos.

Configurar Portal

Para permitir el acceso a una IP o bien a cualquier IP del servidor FreeNAS hay que definir como mínimo un portal. Por defecto:

Portal -> 0.0.0.0:3260

Configurar Destinos

Para poder servir esta LUN, tenemos que definir que destinos vamos a presentar dicha LUN. Configuramos el destino con el/los IQN de nuestros XenServer:

Para ver el IQN de un servidor hacemos:

cat /etc/iscsi/initiatorname.iscsi

Disco/Destino

Tenemos que establecer la relación entre el destino y el disco (Extensión).

Iniciar ISCSI

Ahora ya solo falta arrancar el servicio desde Servicios-> Control de Servicios -> ISCSI = ON

Ya tenemos la parte de disco compartido finalizada, solamente hay que añadir esta LUN a nuestro Pool.

Pues esto es todo por hoy, espero como siempre que te haya parecido interesante y haberte podido ayudar en tus pasos por el mundo de la virtualización. Un saludo

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

Hola amigos, esta semana veremos en nuestra sección de Citrix XenServer como actuar en caso de caída de uno de nuestros hosts físicos y recuperar el estado normal de nuestras máquinas virtuales.

El entorno al que se puede aplicar este procedimiento es un pool clásico de dos o más hosts donde tenemos corriendo nuestras máquinas virtuales sobre un almacenamiento compartido y con un licenciamiento gratuito.

Como todo fallo, antes de actuar hemos de detectar la fuente del problema y el  alcance/impacto para poder tomar las medidas necesarias para solucionarlo. Podemos evaluar la situación de un entorno XenServer caído mediante el siguiente esquema, similar al que nos plantea Citrix:

El master del pool está caído

Es  la situación más grave, veréis que se pierde totalmente el control del Pool. No se pueden listar ni realizar operaciones sobre las máquinas virtuales, se desconecta el XenCenter…  De todos modos, las máquinas virtuales siguen corriendo con normalidad en todos los Hosts, excepto las del servidor/es afectado/s.

El host con el rol de master es el que gestiona la base de datos del pool. En el momento que el master no es accesible, todos los demás hosts pierden el acceso a dicha información y asumen que están corriendo en modo de emergencia.

Desgraciadamente, no siempre cambia a ese modo automáticamente y cuando haces una consulta a la XAPI, se queda esperando si hacer nada, sin dar el error de que se encuentra en estado de emergencia.

“En mi laboratorio de pruebas, no se ha cambiado a modo de emergencia ningún host al dar botonazo al host master”. De todos modos, tanto si el siguiente comando nos devuelve “true” como “false”, procederemos igual.

#xe host-is-in-emergency-mode

Si el Host que teníamos como Master no es posible que vuelva a funcionar de nuevo, por ejemplo por un fallo de hardware, hay que transferir el rol de master a otro miembro del pool. Para ello ejecutamos el siguiente comando en un host que esté funcionando correctamente.

[root@xsrv03]# xe pool-emergency-transition-to-master

Host agent will restart and transition to master in 10 seconds…

Ahora si ejecutamos por ejemplo:

[root@xsrv03]# xe host-list

Ya veremos que la XAPI nos devuelve los hosts del pool. Ya tenemos control sobre el pool. Verificamos que el host que le hemos traspasado el rol de master, lo ha asumido correctamente:

[root@xsrv03]# xe pool-list

uuid ( RO)                : f9e97ade-85db-0191-403a-b56b93d364c7

name-label ( RW): PRODXEN

name-description ( RW): .: Production Cluster :.

master ( RO): cede8d8c-c750-4067-a6b9-eb55744e44fc

default-SR ( RW): e6532b42-d048-2ef4-9b6c-688632108e34

[root@xsrv03]#  xe host-list uuid=cede8d8c-c750-4067-a6b9-eb55744e44fc

name-label ( RW): xsrv03

Una vez recuperado el control del pool, tenemos que forzar al nuevo master a restablecer las conexiones con el resto de hosts. Este comando nos devolverá el listado de UUIDs de los hosts slaves que contiene el pool.

[root@r xsrv03]# xe pool-recover-slaves

e212ac38-c349-490a-9902-06b9355700cd

Ahora el pool puede volver a trabajar con normalidad, si disponemos de N+1, solamente  tendremos que levantar las VMs caídas en del host “master” en los otros hosts disponibles. Si las máquinas virtuales no se dejan volver arrancar porqué según la XAPI están corriendo sobre el host caído, sigue leyendo

A partir de aquí el resto de situaciones de caídas de Host, son menos aparatosas. Si detectamos un host caído y no podemos volver a levantar las máquinas virtuales en otro Host, tenemos el comando:

#xe vm-reset-powerstate vm=<NameLabel de la VM> force=true

Este comando avanzado forzará el estado de apagado la máquina virtual que especifiquemos. Pero ojo, solo ejecútalo si estas 100% seguro que esta máquina virtual no está corriendo en ningún otro host ya que este, libera el bloqueo que establece XenServer a nivel de base de datos, para que no se pueda levantar la VM en cualquier otro host del pool por duplicado. En ese caso, tendríamos corrupción de discos en la máquina virtual. Como es un comando “peligroso” hay que ejecutarlo siempre con el flag force=true o –force

Tenemos también la opción para un host en concreto:

#xe vm-reset-powerstate resident-on=<UUID Host caido> force=true

Hasta aquí por hoy, espero que como siempre, haya podido enseñarte algo útil para administrar tu entorno XenServer.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigos, hoy veremos en nuestra sección de Citrix XenServer, como funcionan los Pools y como gestionarlos mediante CLI.

Un Pool se define como dos o más maquinas Citrix XenServer que componen una misma entidad, de modo que pueden compartir recursos como máquinas virtuales, almacenamiento, etc. de forma centralizada.

Cuando se usa un Pool con almacenamiento compartido las máquinas virtuales se pueden mover en caliente (XenMotions) entre los hosts que componen el Pool, compartir templates, repositorios de ISOS, SR’s… Aporta también una agregación de recursos ya que si un Host ya no puede asumir más carga de maquinas virtuales, la  siguiente máquina virtual, será levantada en otro Host.

Esta Entidad es capaz de gestionar todas las máquinas virtuales en  conjunto indepen-dientemente de donde estén corriendo, es decir que en caso de caída de un host físico, las maquinas virtuales se pueden volver arrancar en otro host, siempre que tengamos almacena-miento compartido.

Veremos más adelante que si el Host caído es el denominado Master del pool, tendremos un problema un poco más serio.

Requisitos para crear un pool

1. Los hosts tienen que ser homogéneos, no se pueden mezclar CPUs AMD con CPUs INTEL.
2. Las CPUs tienen que ser del mismo modelo y soportar los mismos flags. Hay trucos para romper esta regla, pero no es recomendable de ningún modo, excepto en el caso que sea el flag “stepping”.
3. Tener una IP estática.
4. No ser miembro de otro pool, ni tener almacenamiento compartido.
5. Relojes sincronizados por NTP.

Integrando un Host a nuestro Pool por CLI

Entramos en la máquina que queremos añadir al Pool y ejecutamos:

#xe pool-join master-address=IP_Servidor_master master-username=root master-password=password.

Si ejecutamos xe pool-list veremos las propiedades básicas de nuestro pool:

# xe pool-list

• uuid ( RO) :  UUID del Pool
• name-label ( RW): nombre del Pool
• name-description ( RW):  Descripción (si hemos puesto alguna)
• master ( RO): UUID del host que esta designado como Master
• default-SR ( RW): El SR por defecto del Pool

Ahora ya podemos migrar nuestras maquinas entre hosts mediante xe vm-migrate:

#xe vm-migrate vm=Nombre de la VM host=Nombre del Host live=true

Quitando un Host de nuestro Pool

Tal vez nos interese quitar un Host del Pool, para ello podemos utilizar el siguiente comando:

# xe pool-eject host-uuid=UUID del host

Con esto me despido hasta la semana que viene, donde veremos cómo solucionar problemas relacionados con los pools ante caídas de hosts, cómo mover los roles de master y otras opciones para que cada día te sientas mejor usando Citrix XenServer.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

Esta semana, en nuestra sección de Citrix XenServer, veremos más trucos sobre la gestión de discos que ya empezamos la semana pasada. Espero que, como siempre, te resulte interesante.

VBDs a fondo

Vimos que Citrix XenServer es capaz de abstaer el sistema físico de almacenamiento ya sea, SAN, I-SCSI, Storage Link, NFS, etc. De manera que las máquinas virtuales siempre tendrán asociados VBDs y estos hacen de “enlace” con nuestros discos virtuales VDIs.

Eso es muy importante ya que por ejemplo el core de Citrix XenServer utiliza aplicaciones como Pygrub, un grub hecho en python para arrancar los domU (máquinas virtuales) con su propio Kernel. Este, necesita parametros para saber que disco tiene que utilizar para arrancar el sistema. Este parámetro en cuestión es el parámetro “bootable”.

Es común el error: “No bootable device.” Cuando por ejemplo borramos un snapshot que tenia ese parámetro puesto automáticamente.

Sabiendo cual de los VBD->VDI contiene el Kernel de nuestra máquina virtual, simplemente tendríamos que establecer dicho VDB como “bootable” para que el domU arrancara sin problemas:

#xe vbd-param-set uuid=<UUID VBD> bootable=true

Tambien el VDB establece que tipo de disco se presenta (CDRom/Disk), modo (lectura/escritura), dispositivo de la maquina virtual (xvda/ hda) y un largo etc. Os invito a que veais los diferentes parametros en una máquina virtual vuestra con:

# xe vbd-list vm-name-label=<Nombre VM> params=all

Los VBDs tienen tambien comandos extra de gestión como:

• vbd-eject/vbd-insert: Expulsa/inserta un VDI
• vbd-plug/vbd-unplug: Conecta/desconecta un VBD
• xe vbd-create: Como parametro los siguientes flags -> bootable=     device=       mode=         type=         unpluggable=  vdi-uuid=     vm-uuid=
• vbd-destroy: Elimina un VBD por UUID

No olvidemos que el principal objetivo del VBD es el enlace con el VDI. Así que ya podemos saber que VDIs tiene una máquina virtual mediante:

# xe vbd-list vm-name-label=<Nombre VM> params=vdi-name-label

VDIs a fondo

Existen tres típos en función del típo de SR (Storage Repository) que tengamos montado:

• File based VHD: Utiliza thin provisioning y no soporta almacenamiento compartido, solamente es posible usar este típo en SRs de discos locales EXT  o como recurso SR por NFS.

• LVM: La opcón predeterminada de Xenserver. Puede ser por SAN, I-SCSI o SAS. Básicamente los VDIs son representados como volumenes LVM.

• LUN por VDI: Mapeo directo de Luns contra una máquina virtual. Para eso es necesario usar pluguins especificos (NetApp, EqualLogic o StorageLink)

Podemos ver todos los parametros del VDI con:

#xe vdi-list uuid=<UUID-VDI> params=all

También tienen un montón de opciones, espacio virtual, utilización física, sr donde está alojado el vdi, y un largo etc.

Algunos comandos extra para las gestión de VDIs

• vdi-clone: Clona el VDI y lo almacena con un nuevo UUID, nuevo nombre, etc. En el mismo SR
• vdi-copy: Copia el VDI en otro SR
• vdi-import: Importa un VDI desde un fichero exportado con vm-export
• vdi-resize: Reasigna el espacio virtual del disco

Con esto, me despido por hoy, espero que haya podido enseñarte algo nuevo sobre la gestión de discos y como funcionan en XenServer y animarte a que lo veas con tus propias máquinas virtuales.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.