Fuimos el primer partner al que se le dió formación sobre el producto cuando aún era una versión beta.

Vino un francés a darnos el curso y lo que ví me encantó. Por aquel momento llevaba ya como un año dando el coñazo en mi empresa con la virtualización en Linux. No por que la cosiderará lista para entornos en producción, de una forma generalista, si no por conocer el producto y posicionarse en el mercado y ser uno de los referentes o el referente para cuando estuviera lista para una adopción de forma generalizada.

Muchos hablarán maravillas de la virtualización en Linux que si el antiguo UML (User Mode Linux), Xen o KVM. La virtualización lleva funcionando en Linux mucho tiempo pero la tecnología no está lo sufucientemente madura como para ser considerada en serio de forma generalizada.

Me explico, hay clientes para los que a día de hoy los sistemas de virtualización basados en tecnologías OpenSource (no confundir con gratis) les pueden servir y les dan garantías para su negocio pero hay otros muchos en los que no.

Hoy por hoy y le pese a quien le pese (y yo soy uno de ellos) VMware es el Rey en virtualización (Intel y AMD) y está a años luz de cualquier competidor desde el punto de vista tecnológico.

El producto de Red Hat es, para mi, la segunda opción más fiable. Me han hablado maravillas del producto comercial de Xen pero como no lo he podido evaluar no voy a dar mi opinión sobre él basandome en leer PDFs como hacen los gurús de hoy en día.

El producto de Red Hat, RHEV, está lo suficientemente maduro como para encajar en los planes de muchas empresas que no necesitan toda la potencia que VMware te ofrece y obviamente pagas.

Las mayores pegas que le encuentro al sistema de Red Hat son:

• No hay posibilidad de hacer Snapshots en caliente. Esto es un gran inconveniente ya que a la hora de hacer actualizaciones nos permite una marcha atrás rápida, comoda y flexible. Sin tener que apagar la máquina.

• No hay posibilidad de añadir hardware virtual en caliente. A la hora de añadir discos en caliente para gestionar el crecimiento de nuestros servidores si tenemos que apagar la máquina deberemos pedir una ventana con el consiguiente impacto.

• Para montar discos en cluster solo se puede hacer por iSCSI. Esto saldrá subsanado en la versión 3.0, o quizá en la 2.3 (ahora estamos en la 2.2).

• Virtualización de Solaris x86. Desde mi punto de vista creo que Red Hat ha decidido no incluir esto debido a la gran campaña que tiene para migrar entornos Solaris a Red Hat. Creo que es un error ya que tengo algún cliente, GRAN CLIENTE, que no se decidió en su momento a considerar a Red Hat como una alternativa a VMware por este motivo decidiendose a favor de Oracle VM. Pero gracias a las políticas de Oracle y a una demo del que escribe estas líneas han vuelto a considerarlo.

• No es posible, de una forma sencilla, el instalar el manager en una VM dentro del entorno RHEV. Esto puede parecer una tontería pero en la vida real es una practica habitual, mientras que en VMware es una tontería en RHEV no es tan sencillo y es necesario montarla mediante libvirt.

Es cierto que estos temas se van a solucionar en las proximas versiones.

¿Cual es la política por la que se decide en que feature se trabaja para añadirla? Pues es muy sencillo y lógico, la demanda de sus clientes. Obviamente si hay más clientes que demandan la característica A en lugar de la B Red Hat va a poner más carne en el asador para implementar A.

Hay que darle tiempo a Red Hat para que se ponga a nivel en características y fiabilidad con VMware. Hay que reconocer que la velocidad que lleva Red Hat a la hora de mejorar su producto es espectacular y no sólo por añadir características rápido, si no por hacerlo con bastante madurez y robustez. Desde luego que hay bugs, uno me lo he comido, pero el trabajo que están haciendo es sensacional.

Voy a comentar los problemas que me he encontrado en esta migración:

1. Después de migrar una máquina, la primera tardó 7 horas en migrar … Me encuentro con un error al realizar la importación “No puede importar la máquina debido a que el tipo de discos no está soportado”. Bueno pues esto es un bug. La solución era modificar el fichero OVF (Open Virtualization Format) y cambiar los discos de tipo Sparse a Preallocated. No me funcionó.
2. Decido probar con una máquina windows más pequeña. Después de convertirla a kvm me dió un fallo debido a que no encontraba unos paquetes. Revisando la documentación me encontré que era necesario instalar unos paquetes adicionales. Esta información se encontraba en la documentación de RHEL 6 y no del hypervisor. Uno de esos paquetes no está disponible para RHEL 5 ¿adivinad que SO tenía la máquina que había montado para la migraciones? Con lo cual me tocó montar un RHEL6.
3. Realizando la conversión con una RHEL6 me encontré el mismo problema de la importación de discos. Salvo que ahora el “workaround” si funcionó.
4. La importación de los windows fue bien, salvo que no se conservó la configuración de red y tuve que replicarla a mano.
5. Con los linux fue todo bien, salvo que no se el motivo por el cual RHEV le asignó una MAC a la VM pero no la cambió en el SO y me toco hacerlo a mano.

La batalla ahora mismo no se encuentra en tener un producto de virtualización, de hecho pocas novedades van a haber que sean revolucionarias en este campo. La batalla está en todos los productos que hay alrededor del software de virtualización. Desde hace tiempo VMware tiene una suite de productos que complementan su principal producto, vSphere, como:

• Site Recovery Manager, un software que realiza un BRS de un CPD a otro. Ahora mismo estoy trabajando en un proyecto para implementar esto con dos CPDs a 12.000 km.
• Capacity Planner, te realiza un estudio de tu infraestructura física y te determina el número de servidores y características que necesitas para consolidarlo.
• Charge Back, te permite conocer los costes de tu entorno para poder facturar a departamentos, … Ahora con el Cloud Computing esto es esencial.
• Capacity IQ, te permite tener estimaciones de cuando te vas a quedar sin recursos.

Además de esto VMware está trabajando en otra serie de productos entorno a entornos de virtualización que como no estoy seguro de si puedo mentarlos (confidencialidad) no voy a hacerlo. Es en este campo donde ahora mismo está la batalla y no tenemos alternativas Open Source. No se si Red Hat u alguna otra compañia está trabajando en este área. De no ser así volveremos a perder la batalla, que no la guerra. Pero siendo positivo tendremos que decir que sólo tendremos a un paso de distancia a las alternativas no Open Source.

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.

En la virtualización de escritorio o VDI los PCs de usuario o escritorios son máquinas virtualizadas y hay que acceder a ellas mediante un cliente de VDI. Este cliente se comunica con el escritorio, máquina virtual, mediante un protocolo. Existen varios protocolos:

• RDP (Terminal Services, Microsoft).
• ICA (Citrix)
• SPICE (Red Hat, Qumranet)
• PCoIP (VMware).

para este propósito.

En la página de Brian Madden se puede ver una comparativa sobre el uso de diferentes protocolos utilizados en la virtualización de escritorio para comprobar el rendimiento de SPICE con RPD (Windows) o ICA (Citrix). También hay disponibles videos en los cuales se puede ver en acción.

La solución de VDI de Red Hat estará disponible a lo largo de 2010.

Red Hat siguiendo con su modelo de negocio abre y libera las tecnologías que compra y en contra del pensamiento de la turba tecnológica amplia negocio y con ello beneficios.

Ya había hablado sobre él pero no de una forma muy extensa.

Hoy he estado haciendo unas pruebas con una de las últimas betas y me sigo reafirmando de la calidad del producto a pesar de ser la primera versión.

Hablando en valores absolutos sobre el producto todavía le falta mucho para alcanzar al rey indiscutible de la virtualización en plataformas x86, VMware ESX Server. VMware tiene una extensísima experiencia y una amplia variedad de productos en torno a su producto estrella que te facilitan la gestión de los entornos virtuales y recuperaciones en caso de desastre, dimensionamientos, …

Como todo producto recién lanzado al mercado hay que ser cauteloso ya que todo software es susceptible de tener fallos y ser mejorado. Sobre todo las primeras versiones. Aún así las perspectivas son muy buenas.

Aunque no puede competir con VMware tecnológicamente debido a la gran ventaja que VMware posee, derivada de ser el fabricante que más tiempo lleva en el mercado de la virtualización en x86, RHEV ofrece unas grandes posibilidades y tiene un target bien definido:

• Aquellos que pueden sacar beneficio de la virtualización de sus servidores y no necesitan toda la potencia de VMware.
• Empresas con un alto número de servidores Red Hat.

No he tenido tiempo de revisar minuciosamente toda la documentación y puede que ponga alguna inexactitud.

El producto se licencia por procesador físico (socket) de los servidores que van a ejecutar el hipervisor. Con esta licencia se obtiene el siguiente software:

• RHEVM (Red Hat Enterprise Virtualization Manager) que es la consola centralizada de administración.
• RHEV Hypervisor.

Al contrario que VMware al pagar la licencia Red Hat te licencia el producto con todas sus características. Con VMware dependiendo de las funcionalidades que requieras pagarás más o menos. Cuantas más funcionalidades mayor coste.

Si utilizamos el hipervisor para virtualizar tendremos que disponer de la correspondiente licencia para los sistemas operativos virtualizados. Sin embargo si disponemos de licencias de Red Hat Enterprise Linux Advanced Platform podemos instalar el hipervisor en ellos y todas las máquinas virtuales estarían licenciadas automáticamente.

Esto significa que si disponemos de un cluster con cuatro nodos y cuatro procesadores físicos por nodo necesitaremos:

• Licencias para 16 procesadores para RHEVM.
• 4 Licencias para Red Hat Enterprise Linux Advanced Platform.

En este entorno tendremos automáticamente licenciadas todas las máquinas virtuales que podamos ejecutar en el entorno virtual. Lo cual supone un ahorro considerable en licencias.

Si por el contrario no queremos adquirir licencias de Red Hat Enterprise Linux Advanced Platform podemos virtualizar ya que al adquirir las licencias de RHEVM se nos licencia el hipervisor. En este caso sí deseáramos virtualizar máquinas Red Hat tendríamos que adquirir las correspondientes licencias.

Además será necesario disponer de una máquina Windows, con su correspondiente licencia, que será donde se ejecutará RHEVM. Por el momento la consola de administración sólo funciona en Windows ya que fue desarrollada de tal forma por la empresa Qumranet.

En cuánto a las características técnicas podemos destacar que RHEV proporciona movimiento en caliente entre diferentes host ejecutando el hipervisor y proporciona memory commitment.

Actualmente, y si no me equivoco, sólo hay dos soluciones que lo proporcionan:

• VMware que lo denomina transparent page sharing.
• Red Hat en RHEV.

Para los que no lo sepan estas técnicas permiten que las páginas de memoria que sean comunes a las máquinas virtuales sólo se tenga una copia en memoria en total y no una por cada máquina virtual. Hoy en día es la técnica de optimización de memoria, en estos entornos, con un mayor rendimiento y que permite un ratio de consolidación de servidores francamente impresionante.

Como aspectos negativos podemos destacar que todavía no se soportan:

• Snapshot en caliente.
• Ampliación de hardware en las máquinas virtuales en caliente.
• Sistemas operativos que no se soportan, como Solaris.

Las nuevas versiones de Red Hat ya incluyen los drivers paravirtualizados que nos permitirán un mayor rendimiento en las máquinas virtuales (Red Hat 5 Update 4 y Red Hat 4 Update 8).

Con esta adquisición Red Hat pretende reafirmarse como una opción competitiva y fiable para el mercado de la virtualización, no sólo en la virtualización de servidores si no que también en VDI.

VDI es un acrónimo para Virtual Desktop Infraestructure, es decir la virtualización de sistemas de escritorio. Aunque se podría afrontar desde la misma perspectiva que la virtualización de servidores debido a las diferencias entre los entornos de escritorio y servidores este tipo de virtualización tiene sus propias características.

Volviendo al tema central de este artículo la nueva estrategia de Red Hat en virtualización consta de los siguientes componentes:

• Red Hat Enterprise Virtualization Manager for Servers (RHEV-S) que no es ni más ni menos que una consola centralizada para gestionar host y clusters de máquinas Red Hat ejecutando máquinas virtuales. Es el equivalente al Virtual Center de VMware (vCenter Server).
• Red Hat Enterprise Manager for Desktops (RHEV-S) sistema de gestión para VDI basado SolidICE y SPICE para sistemas Windows y Linux.
• Red Hat Enterprise Virtualization Hypervisor (RHEV-H) un hipervisor que se instala con un sistema mínimo.

Toda esta infraestructura recibe el nombre de RHEV.

Este semana he podido degustar el nuevo producto de Red Hat y las impresiones no pueden ser otra cosa que positivas. Muy positivas.

La versión que he probado es una versión en desarrollo. Esta versión ira evolucionando hasta dar lugar a la versión final.

En la página de Brian Madden se puede ver una comparativa sobre el uso de diferentes protocolos utilizados en la virtualización de escritorio para comprobar el rendimiento de SPICE con RPD (Windows) o ICA (Citrix). También hay disponibles videos en los cuales se puede ver en acción.

Red Hat puede presumir de un producto competitivo de virtualización. VMware y Microsoft tendrán que tener muy en cuenta la solución de Red Hat que, ahora sí, promete ser un digno rival.

Podría entrar más en detalle sobre el producto pero dado que he tenido acceso al mismo a través del programa de partnering prefiero esperar a que se lance oficialmente y tener acceso a la versión final del mismo.