Manual de Supervivencia XenServer y Multipath + iscsi

El Storage como parte fundamental de la mayoría de entornos, hay que tenerlo muy controlado. Para ello la siguiente guía:

Para los que utilizamos multipath en XenServer, hay que tener en cuenta algunos trucos para realizar tareas sobre este daemon.

Como ver los caminos que tenemos configurados:

[root@xenserv ~]# multipath -ll

[size=1.5T][features=1 queue_if_no_path][hwhandler=1 emc][rw]

\_ round-robin 0 [prio=2][active]

 \_ 1:0:0:1 sdc 8:32  [active][ready]

 \_ 3:0:0:1 sdh 8:112 [active][ready]

\_ round-robin 0 [prio=0][enabled]

 \_ 2:0:0:1 sde 8:64  [active][ready]

 \_ 4:0:0:1 sdi 8:128 [active][ready]

3600601601a4024006a4f2b3c2635e111 dm-3 DGC,VRAID

[size=500G][features=1 queue_if_no_path][hwhandler=1 emc][rw]

\_ round-robin 0 [prio=1][active]

 \_ 2:0:0:2 sdj 8:144 [active][ready]

Si queremos ver con más detalle el estado actual de multipath:

[root@xenserv ~]# multipath -v3

Hay que tener en cuenta que multipath trabaja con los caminos que le sirve open-iscsi, por lo tanto, un reinicio de open-iscsi, afecta al servicio multipath. 

Si queremos logearnos a nuestra cabina de discos por solo un camino:

[root@xenserv ~]# iscsiadm -m node -l
Por ejemplo:
iscsiadm --mode node --targetname iqn.cabina... --portal 192.168.1.15 --login

Si por el contrario queremos logearnos en todos los caminos:
[root@xenserv ~]# iscsiadm -m node -L all

Si queremos eliminar caminos de multipath e iscsi, hemos de buscar en el directorio /etc/iscsi/nodes
iqn....com.emc:cx.ckm00103200040.a4
iqn....com.emc:cx.ckm00103200040.b4
iqn....com.emc:cx.ckm00103200040.b5

[root@xenserv ~]# rm -fr iqn....emc:cx.ckm00103200040.b5

Volvemos a logearnos a la cabina:
[root@xenserv ~]# iscsiadm -m node -l

Reinciar open-iscsi
[root@xenserv ~]#/etc/init.d/open-iscsi restart

 Reiniciar multipath
[root@xenserv ~]# /etc/init.d/multipath restart

Si solo queremos probar de quitar un camino unicamente "flush", por ejemplo del multipath sin que sea permanente como en el caso anterior, podemos hacerlo mediante:
[root@xenserv ~]# multipath -f sdm

Si queremos hacer este flush para todos los caminos (OJO que se los pule todos!)
[root@xenserv ~]# multipath -F

XenServer - iscsi allocated

Es posible que algún día, veas que tus SR I-SCSI crece el espacio allocated desmesuradamente. Antes de temblar y buscar en google como arreglarlo, es mejor que leas las siguientes líneas ;)

Por ejemplo ponemos que tenemos una LUN de 1TB presentada como el SR principal de nuestro POOL,  de este espacio tienes ya ocupado 500GB en varias máquinas virtuales y ves que tienes "allocated(500GB)". Hasta aquí lo vemos bien, no hay problema. Pero, que pasa si un día ves que tu allocated está en 3TB...

La verdad es que nada :) Lo más seguro es que tengas un sistema de backup que realiza snapshots y la XAPI no se entera que se borran cuando finaliza el proceso de copia.


Tan sencillo como hacer un "rescan" en el SR para que los valores de allocated vuelvan a la normalidad. 


Saludos!

Cómo cambiar el sistema encriptación por defecto Ubuntu Linux

Si planteamos el escenario, en que tenemos un servidor antiguo, con por ejemplo una Ubuntu 7.10 y queremos llevarnos todas las cuentas de usuarios en /etc/shadow a otro servidor Ubuntu, con una versión superior como la 10.4, o en general, a cualquier sistema que utilice un nuevo algoritmo de encriptación como puede ser sha512, tenemos que tener en cuenta:

El fichero de pam básico de password /etc/pam.d/common-password

password    [success=1 default=ignore]    pam_unix.so obscure sha512 

En este caso está configurado para utilice sha512, cambiando sha512 por md5, pasaríamos a utilizar el algoritmo antiguo:

password       [success=1 default=ignore]      pam_unix.so obscure md5

El fichero de configuración del login /etc/login.defs

Por defecto tendremos: ENCRYPT_METHOD SHA512

Para utilizar MD5 cambiamos a: ENCRYPT_METHOD MD5

Con esto, el servidor utilizará MD5 para el fichero /etc/shadow y la autentificación de tus usuarios.


Cabe recordar que es mucho más recomendable utilizar SHA512 que MD5 ya que de este último hay demostrados problemas de colisiones de hash (wikipedia: situación que se produce cuando dos entradas distintas a una función de hash producen la misma salida.)


Saludos!

XenServer y Ubuntu Server - Problemas con los Kernel de los DomU

Hola amig@os, en diferentes entornos XenServer he visto que la configuración de los domU Ubuntu 10.04 o 8.04 paravirtualizados, tienen problemas de kernel. Estos problemas se manifiestan cuando por ejemplo hacemos una XenMotion, en algunos casos el domU queda totalmente colgado, o bien, parece que esta ok, pero tiene un problema de clocking que deja de dar servicios. Voy  a intentar resumir como arreglarlos.

En Ubuntu Server 8.04 LTS

• Asegúrate de como mínimo tener un kernel 2.6.24-24-xen

• Comprueba tu clocksource:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Si este te retorna xen, significa que esta utilizando el reloj de su Dom0 y en algunos casos, da problemas con las XenMotions. Recomiendo el uso de jiffies, un reloj local para el DomU y configurar NTP.

Para cambiar el  clocksource hay que editar el fichero grub y añadir el flag clocksource=jiffies. Por ejemplo:

title        Ubuntu 8.04.3 LTS, kernel 2.6.24-24-xen
root        (hd0,0)
kernel        /boot/vmlinuz-2.6.24-24-xen root=UUID=f0b969d7-9d41-46b5-8662-5f62a7f1ae25 ro quiet splash clocksource=jiffies
initrd        /boot/initrd.img-2.6.24-24-xen

Despues de reiniciar el domU, el reloj estara bien configurado. Ahora ya puedes usar tu NTP para sincronizar la hora con tus domU.

En Ubuntu Server 10.04 LTS

• Actualizamos el kernel al backport-natty de este modo:

apt-get install linux-headers-generic-lts-backport-natty  linux-image-generic-lts-backport-natty 

• Añadimos el modulo xen_blkfront al initramfs 

 echo xen_blkfront >> /etc/initramfs-tools/modules

• Actualizamos initramfs

update-initramfs -c -k all

• Reniciamos con el nuevo kernel.

Ayudame a ayudarte con la virtualización de sistemas

Me ha parecido genial la iniciativa de José María Gonzalez para la ayuda contra la meningitis. El dinero ganado por publicidad de su site http://virtualizacion.tv/ será donado a una organización sin animo de lucro que lucha contra la meningitis en todo el mundo. 

Desde aquí, un saludo!

Aumenta la velocidad de tu ADSL

Hola amigos,

JAZZTEL permite activar el AnexoM de los contratos de 20 Mb con ADSL2+. Este cambio permite ampliar el ancho de banda de subida de 1024 a 1600 Kbps a costa de una reducción de ancho de banda de bajada.

Más que recomendable si tienes uploads en tu máquina ;)

El procedimiento es muy sencillo, consta de dos pasos

1. Configuración el router
2. Configuración en el ISP

Para configurar el router, si tienes un comtrend tienes que entrar en la configuración del DSL en Advanced Setup -> DSL. Alli tienes que desactivar AnnexM DISABLED, guardar y reniciar el router.

Para configurar JAZZTEL, tienes que abrir una cuenta de cliente y acceder a Servicios Autogestionados -> "Turbo Velocidad" y activar Turbo Up (AnexoM). Se volverá a reiniciar tu router y tendrás tu ADSL un poco menos asimétrica.

Pudes ver más info en: http://www.ofertasadsljazztel.com/soporte/anexom-jazztel.html

http://www.anexom.es/tecnologia/adsl/que-es-anexo-m/

Monitorizar PfSense con Nagios

Si has instalado el paquete nrpe v.2 mediante la GUI de PfSense, quizas te hayas encontrado con el mismo problema que yo. Las definciones de los checkeos están incompletas. Lo puedes ver en /usr/local/etc/nrpe.conf

Mediante la solución encontrada en este post: http://minestron.com.ar/blog/monitorear-un-pfsense-con-nagios se solunciona fácilmente.


Basta con comentar la línea que empieza por: command[{$cmd['name']}. Y substituirla por:

$cmds[] = "command[{$cmd['name']}]={$nagios_check_path}/{$cmd['warning']} -c {$cmd['critical']} {$cmd['extra']}\n";

Monitorizar XAPI XenServer Nagios

Hola! hoy traigo un nuevo script para comprobar que la XAPI de vuestros XenServer están funcionando correctamente. Totalmente probado :) Lo puedes descargar desde github aquí.

A grandes rasgos el script chequea que la XAPI esta operativa tanto a nivel de procesos como a nivel de consultas

#!/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=2

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

 #Vemos si es capaz de conectar con la Xapi y extramos el numero 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