http://www.parallels.com/es/products/server/baremetal/sp/whatsnew/

Pero sigamos con el principal objetivo de este post. Vamos a ello.

0. Con la distribución 5.0 de PSBM, vienen instaladas ya las utilidades para conectar contra ISCSI. No hay que instalar nada más.

1. Formatear PSBM: en la instalación tenemos la opción de configurar las redes. Si podemos será bueno tener desde principio la conectividad a Internet y de paso, obligatorio, añadir la licencia del producto para poder instalar de esta forma PVA, agente, de forma fácil. Sino, lo podemos hacer luego vía shell. Instalamos /, swap y /vz (disco local).

2. Una vez acabados los preparativos inciales, nos logueamos en la shell de PSBM.

3. Si lo hemos hecho de forma básica, tendremos montado /vz contra un disco local con la configuración que hayamos dispuesto. El manual del clúster dispone que no hay que instalar /vz al principio, sin embargo, yo lo he hecho así.

4. Con la red configurada, actualizamos el servidor:

5. Si procede rebotamos.

6. Configuramos el servicio iscsi para que inicie automáticamente y lo arranque. Si hemos dispuesto usuarios y passwords para el volúmen ISCSI, debermos editar previamente el archivo /etc/iscsi/iscsi.conf según se necesite (en este ejemplo, no hace falta):

7. Buscamos discos ISCSI contra nuestra SAN:

donde 10.0.0.10 es la dirección IP del dispositivo de almacenamiento ISCSI. Una vez el comando se ha ejecutado, nos mostrará los targets disponibles contra este dispositivo. Si hay más de uno disponible, deberemos elegir cual conectar o en el caso de que soporte múltiples conexiones, de todas formas, se deberá rebotar el servicio iscsi

8. Reiniciamos servicio iscsi y chequeamos que accedemos al disco (debe estar listado en /proc/partitions)

mirando en dmesg, veremos como se van descubriendo los dispositivos ISCSI. Lo deberemos ver listado, en el siguiente archivo

También aparecerá si ejecutamos fdisk

Podemos también vía iscsiadm, ver que targets hemos descubierto

Y ver las sesiones activas

9. En este punto, tenemos el disco ISCSI accesible. Vamos a formatearlo.

Podemos probar de montarlo en una carpeta, como prueba extra para ver que es totalmente accesible.

10. Ahora queda montar /vz en nuestro volúmen ISCSI. Es probable que tengamos problemas para cambiar /vz a una carpeta temporal. Describimos un proceso en el que con toda seguridad podemos hacer el cambio.

Editamos fstaba y comentamos la línea del montaje actual de /vz. Rebotamos

Una vez devueltos al sistema, comprobaremos que /vz no se ha montado. Es hora de editar fstab para que monte automáticamente /vz con nuestro volúmen ISCSI. Para ello, debemos tener en cuenta que cada vez que asignamos, descubrimos, un volúmen ISCSI en linux, le otorga un nombre de partición-disco diferente, para ello los LABELS etiquetas son muy útiles. Tomo prestado un buen consejo al respecto:

“Si el iniciador iSCSI solo se va a conectar a un target con una única partición podemos utilizar los LABELs sin problemas, en cambio, si nos conectamos a un target que está exportando varios volumenes, puede ocurrir que algunos tengan el mismo LABEL. En la medida de lo posible, se recomienda el uso del parámetro UUID para evitar montar una partición equivocada con el mismo LABEL.”

Ejectuamos blkid , para ver que UUID tiene nuestro disco ISCSI

Con esta información editamos nuestro fstab y añadimos la siguiente línea:

“Añadir el parámetro _netdev a las opciones de montaje del dispositivo, de este modo durante el arranque de la máquina el script rc.sysinit no lo montará. Posteriormente el script netfs se encargará de montar todos aquellos puntos de montajes marcados con esta opción, una vez inicializada la red y tras conectar a los targets iSCSI. Si no utilizamos el parámetro _netdev será imposible montar la partición, ya que Linux tratará de montar el punto de montaje antes de tener habilitado el soporte de red.”

Sólo quedará hacer un último reinicio del sistema para comprobar que, el montaje de /vz sobre el disco ISCSI al inicio del sistema es correcto.

Links
http://download.parallels.com/doc/psbm/v5/rtm/Deploying_Clusters_in_Parallels-Based_Systems.pdf
http://wiki.woop.es/Configuracion_iniciador_iSCSI_CentOS

Información sobre licencia

Información general

Instalar licencia

PD: a petición de Manel de Eanet , aclaro que los RPM a los que me refiero están dentro del DVD de instalación de Parallels Bare Metal, en la carpeta Packages.

Hay cosas que convendría aclarar, pero de momento lo dejo aquí anotado, luego leeré más profundamente la documentación a ver si soy yo el que no lo entiende o es la propia documentación que es liosa.

Tenemos un hypervisor con un virtual disk de 10 GB. Si queremos ampliarlo o reducirlo, podemos hacerlo (en teoría) vía PVA o PMC. Pero todas las fuentes indican que no son de fiar, del todo. Así que vamos a lo seguro entramos por consola y a ver que pasa. En un primer momento pensé que podría redimensionar el espacio así:

Pero no me dió resultado. El disco siempre aparecía con 10 GB, y puse en el –size, varios valores, sin éxito.

Entonces vi la herramienta prl_disk_tool y probé y en principio funcionó pero bueno, lo dejo todo entre comillas. Con el siguiente parámetro vemos info sobre el virtual disk del hypervisor en cuestión, debemos variar la ruta en función de la mv.

Para cambiar el espacio asignado lo hice así:

Links

http://download.parallels.com/doc/psbm/en/Parallels_Server_Bare_Metal_Users_Guide/30367.htm

Hay algunas cosas que todavía faltan por pulir en el PVA (Parallels Virtual Automation) y en el propio programa de Win32,Parallels Management Console. Suerte que podemos hacerlo vía comandos…

Para cambiar la prioridad de disco de las MV o hipervisores

Hay una manera rápida y sencilla de crear MV (hypervisores).

1. Creando un MV y actualizándolo hasta un punto X

2,3. Parando el MV. Clonando el MV a template:

# pctl clone My_VM –name template1 –template

4. Listamos los templates creados

# pctl list -t

{4ad11c28-9f0e-4086-84ea-9c0487644026} win-2003 template1

5. Creamos una MV nueva a partir del template

# pctl create Converted_VM –ostemplate template1

Se ha hecho esperar pero por fin conseguimos el visto bueno de David Toribio para implementar Bare Metal en la infraestructura de ITnet.

Parallels utiliza la tecnología de virtualización de Intel Core, que permite a la máquina virtual acceso directo al procesador del anfitrión. Bare Metal es otro producto de Parallels, ideado para seguir ofreciendo soluciones de virtualización. El mismo fin que Parallels Virtuozzo pero de otra forma. Virtuozzo es a la práctica una virtualización del sistema operativo, lo que Parallels llama “Containers”. Sin embargo, Bare Metal es otra filosofía, ya que utiliza “Hypervisores”.

El producto se ha concebido basándose en la tecnología de hipervisor de Parallels a nivel de servidor, proporcionando una arquitectura escalable que soporta hasta 12 vCPUs, 64GB vRAM, 2TB vHDDs y 16 vNICs por máquina virtual para aplicaciones intensivas. Asimismo, Parallels ha implementado numerosas capacidades específicas para procesadores Intel, como Intel® Virtualization Technology para Directed I/O, FlexPriority, Extended Page Tables y Virtual Processor Identification, para así mejorar el rendimiento.

La diferencia como vemos es sustancial. Con un sistema basado en containers, el sistema operativo utiliza un kernel compartido. En el sistema de hypervisores, cada kernel de hypervisor es independiente. Las modificaciones del kernel del hypervisor sólo le afectan a si mismo. Esto a la práctica nos ofrece soluciones y ventajas a la par que algún que otro inconveniente. Lo que ocurre es que al ponerlo en la balanza, las ventajas superan ampliamente los inconvenientes, como puede ser que, al menos teoricamente, el overhead en los contenedores es más bajo que en los hypervisor.

Otra ventaja de Bare Metal es que es capaz de tener a la vez containers y hypervisores en el mismo hardware node. Para contenedores, puedes tener sólo Linux y para máquinas virtuales, puedes tener tanto Linux como la mayoría de sistemas operativos Windows. Como contraste, Virtuozzo puede tener sólo containers del mismo tipo que el sistema operativo que gestiona el anfitrión (kernel compartido).

Ahora estamos en un punto intermedio, porque ya hemos aplicado unas pequeñas mejoras a nivel de hardware(“pequeñas” quizá no sería la palabra) y nos han funcionado, eliminando un cuello de botella que teníamos desde hace tiempo. La línea es seguir con BMetal y mejorar el hardware por la vía que no está dando buenos resultados.