Esta nueva gama de servidores permite un aumento de escalabilidad en el crecimiento debido a las posibilidades de ampliación de memoria y desvinculando esta de los procesadores para aumentar el rendimiento de los sistemas y reducir el consumo energético.

Esta nueva arquitectura se suministrará en formatos:

• Servidor enrackable
• Sistemas Blade

de dos y cuatro procesadores INTEL Nehalem de 8 núcleos.

También se incluirán discos de estado sólido para mejorar el rendimiento I/O y consumo energético. Esto me parece más marketing que otra cosa. Es cierto que el rendimiento de los discos de estado sólido es mayor, tanto que no se suelen utilizar, de momento, en arquitecturas SAN.

Los discos de estado sólido dan más I/O de la que se puede utilizar con el HW de hoy en día, aunque se está trabajando para que su adopción en estos sistemas sea generalizada en lugar de utilizar discos de fibra, SAS o SATA y poder aprovechar todas las ventajas que ofrecen los de estado sólido (en los sistemas profesionales de almacenamiento).

Para mí es marketing ya que en la mayoría de las arquitecturas los discos locales, cuando los hay, se utilizan para el SO y los datos se almacenan en una red SAN/NAS (fibra, iSCSI, …) y por este motivo la reducción de costes y aumento de rendimiento hay que matizarla un poquito. También hay que señalar que la configuración típica de SO es dos discos en RAID 1 para tener redundancia, con lo cual sigue siendo necesario tener el doble de espacio.

VMware ya se ha certificado para poder aprovechar esta nueva arquitectura lo que hará que el ratio de consolidación con esta tecnología sea aún mayor generando un mayor ahorro en costes y simplicidad en los CPDs, únido al aumento de rendimiento.

Todo aquel acostumbrado a trabajar en entornos virtualizados sabe, o al menos debería, que el recurso más crítico es la memoria. El parámetro que te indica hasta donde puedes crecer y cuánto es la memoria, nunca la capacidad de procesamiento (salvo un pesimo diseño de arquitectura).

Hace una semana fue necesaria una intervención en un cliente en horas de producción debido a un upgrade. Debido a esto se balancean VMs de un servidor ESX a otro para proceder a actualizar el ESX libre. Como resultado de esto se tenía que al terminar de balancear las VMs había servidores ESX con 15,5 GB de memoria ocupada de los 16 GB disponibles. Al cabo de unos minutos el consumo de memoria se había reducido hasta los 13 GB llegando en algunos casos a 11 GB.

Esto es debido a que el ESX detecta el consumo excesivo de memoria y empieza a utilizar sus algoritmos para el manejo de memoria (I love these guys!!!):

• Transparent Page Sharing
• Ballooning

Estos algoritmos se encargan de reducir el consumo de memoria y “cortarle los vuelos” a las VMs para que no desperdicien la memoria.

VMware es sin duda el Rey en la virtualización en entornos x86 y el resto de aspirantes, ya que desde el punto de vista tecnológico no se les puede llamar competidores, estan a años luz todavía aunque se van acercando cada vez más pero en el tema de la gestión de memoria es donde VMware no admite, de momento, comparaciones.

Hoy, revisando unos logs en un cluster de VMware ESX Server me he encontrado con esto en el fichero /var/log/vmware.log:

Todos aquellos que hayan seguido la sitcom Frasier se acordarán de que todos los episodios terminaban con la frase Frasier has left the building.

La frase proviene de la época de Elvis. Cuándo Elvis terminaba un concierto para evitar que la gente se quedará para ver si el Rey se dignaba a volver al escenario se anunciaba al público que Elvis ya no se encontraba en el recinto con un:

Elvis has left the building

¿Será Frasier o quizá Elvis quien inspiró este huevo de pascua?

Estos procesos se llevan a cabo mediante software especializado como por ejemplo Converter (VMware) o Platespin.

Otra forma de afrontarlo es mediante la creación de una imagen de la máquina a virtualizar y restaurarla sobre una máquina virtual. Este método tiene el inconveniente de que el hardware sobre el que va a correr no es el mismo sobre el que la máquina física estaba ejecutándose y el software de restauración deberá soportar el cambio de los drivers de los dispositivos en la imagen restaurada en el entorno virtual.

Todos estos procesos son conocidos y existe software preparado para realizar virtualizaciones de sistemas Windows y Linux. Pero no es el caso de querer virtualizar una máquina Solaris.

Lo primero que hay que aclarar es que las máquinas a virtualizar serán Solaris 10 ejecutándose en servidores x86:

• Solaris 10 ya que es la versión de Solaris soportada por VMware
• Ejecutándose en arquitecturas x86 ya que al virtualizar una máquina los binarios de la física y la virtual serán los mismos. Un binario de SPARC no se ejecuta en x86
• El sistema utiliza UFS

El proceso de virtualización, visto de una forma simple, es el siguiente:

• Creación de la máquina virtual
• Copia de los ficheros de la máquina física a la virtual
• Reajustes en la máquina virtual debido a la infraestructura virtual sobre la que se va a ejecutar, los dispositivos pueden cambiar, se pueden requerir nuevos drivers, …
• Dejar la máquina arrancable

La virtualización la podremos realizar de dos formas:

• En frío, el servidor a virtualizar no estará arrancado
• En caliente, el servidor estará arrancado pudiendo o no estar dando servicio

Virtualización en frío

Para ello es necesario que la máquina no esté arrancada y sin embargo deberemos tener acceso a los discos donde reside la información.

Para ello arrancaremos la máquina física a virtualizar con un sistema Live basado en Linux o Solaris. La mejor opción es utilizar un sistema basado en Solaris.

Una vez arrancado deberemos:

• Configurar la red y tener comunicación con el entorno virtual
• Montamos todo el sistema a virtualizar respetando la jerarquía en un directorio

Al no estar ejecutándose la máquina con el sistema operativo a virtualizar nos aseguraremos de que la máquina virtual será consistente al no estar modificándose los archivos de la misma por ningún proceso.

Virtualización en caliente

La virtualización en caliente la realizaremos con el sistema levantado y corriendo. Dependiendo de los aplicativos que se esten ejecutando en el servidor quizá sea necesario pararlos. Un aplicativo que modifique datos constantemente, como una base de datos, sería conveniente pararlo ya que de lo contrario los datos no serían consistentes.

Creación y preparación de la máquina virtual

Deberemos crear una máquina virtual sobre la que virtualizaremos la máquina física y darle acceso por red a la máquina física. Acto seguido arrancaremos la máquina física con un sistema Live.

Crearemos el particionado, formatearemos las particiones.

Proceso de virtualización

Una vez creadas las particiones y los sistemas de ficheros transferiremos los datos:

• Montamos el sistema de ficheros root y transferimos los datos desde la máquina física
• Una vez transferido el sistema de ficheros root, montaremos uno a uno el resto de sistemas de ficheros e iremos transfiriendo los datos

La transferencia de datos la podemos hacer de varias formas, por scp, rsync o mediante ufsdump/ufsrestore.

Ahora ya tenemos los datos en la máquina virtual pero no arrancará.

A continuación deberemos reconstruir los dispositivos, el fichero /etc/path_to_inst y modificar el boot path de la máquina.

Tenemos que modificar el fichero /etc/vfstab para que los sistemas de ficheros que se montaban de forma automática en la máquina física se puedan seguir montando en la virtual. Esto aplica también a cualquier script o aplicativo que tengamos instalado y monte o utilice dispositivos de bloque.

Los dispositivos de red también habrán cambiando y ahora serán e1000g? con lo cual será necesario renombrar los antiguos ficheros /etc/hostname.???? a /etc/hostname.e1000g?

A continuación deberemos hacer arrancable el sistema reinstalando el gestor de arranque GRUB.

Ya casi hemos terminado. Deberemos desmontar todos los sistemas de ficheros de la máquina virtual y reiniciar en modo failsafe para configurar los nuevos dispositivos. Una vez hecho esto podremos arrancar la máquina y proceder a instalar las VMware Tools.

Tenemos la máquina lista.

Propósito de este artículo

El propósito de este artículo es mostrar como afrontar la virtualización de sistemas Solaris x86 en un entorno virtual.

Este procedimiento ha sido utizado con éxito virtualizando Solaris 10 sobre VMware ESX 3.5 Update 2.

¿Quiere decir esto que la virtualización de Solaris está resumida en este artículo? La respuesta es un rotundo NO.

Este artículo pretende servir de ilustración a como proceder a virtualizar un Solaris 10 sobre VMware. Cada máquina es un mundo y nos podemos encontrar situaciones que no hemos contemplado aquí:

• El sistema está instalado con ZFS
• Se está utilizando Veritas Volume Manager
• Se está utilizando Solaris Volume Manager (SVM) utilizando metadispositivos, replicas, …
• Se está utilizando IPMP
• …

En estos casos el proceso de virtualización se complica y será necesario realizar más tareas en la máquina virtual para adecuar la configuración de la máquina física a la virtual.

Autores

Este procedimiento ha sido realizado por José Angel de Bustos Pérez y José Luis Barquin Guerola.