De un tiempo a esta parte Virtualización es una palabra que esta en boca de todos. Se virtualiza todo, hasta el almacenamiento.

En este artículo pretendo mostrar como instalar Red Hat Linux para PowerPC en un cliente virtual en pSeries haciendo boot from SAN.

Dado que lo que voy a describir no es una configuración estándar que se vea todos los días, empezaremos con un poco de literatura.

Para los que lo desconozcan pSeries es la “gama media” de servidores de IBM considerando:

• Gama baja: servidores x86. (xSeries)
• Gama alta: mainframe. (zSeries)

Este hardware utiliza procesadores Power, antiguamente RS6000. El sistema operativo “nativo” para esta arquitectura es AIX (UNIX de IBM).

Existía una categoría intermedia denominada iSeries (AS/400 o S/390). Estos “servidores” eran mainframes “de juguete”. Hoy en día IBM ha incluido esta gama de servidores dentro de pSeries y en ellos también corre Linux.

En este hardware es posible hacer particiones y particionar el “hierro” repartiendo todos sus recursos entre las diferentes particiones lógicas o LPARes. En realidad este esquema se podría considerar como una especie de virtualización. En esta arquitectura los LPAR acceden directamente al hardware asignado.

IBM dió un paso de tuerca más y mediante Virtual I/O Server (VIO Server) permite crear clientes virtuales que acceden al hardware/recursos asignados por el VIO Server. En esta arquitectura los clientes virtuales acceden al hardware asignado a través del VIO Server.

El VIO Server es un servidor AIX al que se le asignan todos los recursos del pSeries que queramos asignar a los clientes virtuales y será el encargado de asignárselo a los clientes virtuales.

En un diseño típico instalaremos dos VIO Servers para evitar que el VIO Server sea un punto único de fallo y si cae nos tire todos los clientes virtuales.

A la hora de crear un cliente virtual deberemos crear la máquina virtual mediante el HMC (Hardware Management Console). EL HMC es un servidor xSeries con un Linux personalizado que gestiona los recursos del pSeries.

Le ofrecemos el disco de sistema operativo, a través de un VIO Server y realizamos la instalación.

Se recomienda hacer la instalación en un disco en la SAN en lugar de en los discos internos. El motivo es muy sencillo, la SAN nos ofrece un gran rendimiento y tolerancia a fallos. Si utilizamos discos internos deberemos, si queremos tener redundancia, crear un RAID 1.

Basándome en mi experiencia, podemos encontrarnos con problemas si se degrada el RAID:

• Caerse el cliente virtual.
• Caerse el VIO Server que le ofrece el disco.

Los problemas se manifiestan cuándo se intenta volver a sincronizar el RAID para tener redundancia.

Por este motivo es recomendable utilizar discos en la SAN.

Una vez realizada la instalación en un disco en la SAN deberemos ofrecerle el disco de sistema operativo por el otro VIO Server y configurar el multipath.

¿Pero qué es el multipath? Al ofrecerle el disco de sistema operativo, usualmente /dev/sda, por el otro VIO Server tendremos que escanear el bus SCSI y a partir de ese momento el sistema operativo verá “otro” disco, /dev/sdb. En realidad es el mismo disco visto por dos caminos, uno por VIO Server.

Si un VIO Server cae o hay algún problema con el acceso a ese disco por el camino que controla un VIO Server el cliente virtual dejará de ver el disco y si lo está utilizando por ese camino tendremos problemas.

La solución es configurar el multipathing para que el sistema operativo sea consciente de que /dev/sda y /dev/sdb son el mismo disco. Cuándo falle un camino lo detectará el sistema operativo y conmutará de forma transparente al otro camino.

Existen dos formas de configurar el multipathing en Linux, sin software de terceros:

• mdadm.
• device mapper.

Veremos como hacerlo con mdadm. Dejaremos device mapper para otro artículo.

Utilizando mdadm para configurar multipathing en un disco en la SAN será necesario que en la instalación del sistema operativo no utilicemos LVM. Sí lo utilizamos no nos dejará configurar el multipathing en el volume group  donde resida el sistema operativo al estar activo y siendo utilizado.

Un esquema de particionado típico en esta arquitectura es:

• /dev/sda1 (/deb/sdb1) PPC PReP boot partition donde se instala el cargador de arranque YABOOT. En iSeries se incluye el kernel para el arranque en esta partición.
• /dev/sda2 (/dev/sdb2) partición /boot donde residirá el kernel para el arranque en pSeries. En iSeries no será necesaria.
• /dev/sda3 (/dev/sdb3) swap.
• /dev/sda5 (/dev/sdb5) partición /. Por simplificar instalaremos todo en /.

Editamos el fichero /etc/modprobe.con y añadimos la línea:

alias multipath multipath

De esta forma nos aseguramos de cargar el módulo de multipath en el arranque. Posteriormente tendremos que regenerar el initrd del sistema.

Ahora tendremos que crear los dispositivos multipath:

mdadm -C /dev/md0 -n 2 -l mp /dev/sdb2 /dev/sdc2
mdadm -C /dev/md1 -n 2 -l mp /dev/sdb3 /dev/sdc3
mdadm -C /dev/md2 -n 2 -l mp /dev/sdb5 /dev/sdc5

Una vez generados los dispositvos de multipath tendremos que modificar el fichero /etc/fstab para utilizar los dispositivos /dev/md? en lugar de los /dev/sda?.

En los sistemas Power, pSeries, el cargador de arranque no es ni GRUB ni LiLO, es YABOOT. El fichero de configuración del cargador de arranque se encuentra en  /etc/yaboot.conf y será algo similar a esto:

# yaboot.conf generated by anaconda

boot=/dev/sda1
init-message=Welcome to Red Hat Enterprise Linux AS!\nHit <TAB> for boot options

partition=2
timeout=20
install=/usr/lib/yaboot/yaboot
delay=5
nonvram

image=/vmlinuz-2.6.9-34.EL
label=linux
read-only
initrd=/initrd-2.6.9-34.EL.img
append=”console=hvc0 rhgb quiet root=LABEL=/”

Tendremos que realizar los siguientes cambios:

• Añadir el multipath para la partición PPC PReP boot. Ello lo haremos incluyendo /dev/sdb1 en el apartado boot del fichero anterior. No confundir con la partición /boot.
• Es recomendable el regenerar el initrd con otro nombre para tener la configuración original y poder arrancar la máquina en caso de problemas “just in case“.
• Por defecto Red Hat monta las particiones por etiqueta para evitar que si cambia de nombre un dispositivo se pueda seguir montando sin problemas. Dado que hemos creado un multipathing tendremos tres dispositivos, que en realidad son el mismo, con la misma etiqueta: /dev/sda5, /dev/sdb5 y /dev/md2. Si seguimos utilizando el montaje por etiquetas es posible que no se utilice /dev/md2 que es el dispositivo que proporciona multipath. Por lo tanto en la claúsula append quitaremos el parámetro root=LABEL=/ y habrá que indicarle a YABOOT la partición root del sistema.

El fichero /etc/yaboot.conf quedaría:

# yaboot.conf generated by anaconda

boot=/dev/sda1 /dev/sdb1
init-message=Welcome to Red Hat Enterprise Linux AS!\nHit <TAB> for boot options

partition=2
timeout=20
install=/usr/lib/yaboot/yaboot
delay=5
nonvram
image=/vmlinuz-2.6.9-34.EL
label=linux
read-only
root=/dev/md2
initrd=/initrd-2.6.9-34.EL-mp.img
append=”console=hvc0 rhgb quiet”

Una vez realizado todo esto deberemos regenerar el initrd:

mkinitrd /boot/initrd-2.6.9-34.EL-mp.img 2.6.9-34.EL

Dependiendo de la versión de linux que estemos instalando, kernel, quizá necesitemos utilizar mkinitramfs para regenerar el initrd.

Después de esto podremos reiniciar el sistema utilizando multipathing y haciendo boot desde la SAN.