http://maps.google.com/help/maps/streetview/index.html

Puedes hacer un tour virtual por los sitios que tienen metidos (por el momento 3). Requiere tener instalado la ultima version del flash player.

Pues nada creamos un fichero .vmx con un contenido similar a este:

config.version = “8″
virtualHW.version = “4″
memsize = “192″
ide1:0.present = “TRUE”
ide1:0.fileName = “D:\Mis Documentos\knoppix.iso”
ide1:0.deviceType = “cdrom-image”
floppy0.fileName = “A:”
usb.present = “TRUE”
displayName = “Knoppix”
guestOS = “otherlinux”
priority.grabbed = “normal”
priority.ungrabbed = “normal”
powerType.powerOff = “soft”
powerType.powerOn = “hard”
powerType.suspend = “hard”
powerType.reset = “soft”

workingDir = “.”

Y lo arrancamos con VmPlayer. Los parametros son bastante explicativos de por sí. Los cruciales:
memsize = “memoria que reservará. Ojo que crea un fichero de dicho tamaño donde indique el parametro workingDir”
ide1:0.present = “TRUE”
ide1:0.fileName = “Ruta a la .iso”

Así ya tenemos una plantilla creada para ejecutar las distros que queramos y verles la cara.

Las que no sean ISOs de livecds también las cojerá pero no podrá instalar en el HD porque sencillamente no hay ninguno. Deberiamos poner un vmdk valido, etc…

Por el momento, todos los clusters que he visto nombrados en vmware son clusters de microsoft en maquinas vituales pero ninguno que corra sobre maquinas linux. Este estudio me servirá para determinar si es posible realizar esta solucion y si se puede llevar a produccion incluso para servidores tipo IMAP con millones de pequeños ficheros (situacion mas desafavorable para el filesystem).

De partida descarto Xen como tecnologia para virtualización en produccion. Yo esperaria un par de años antes de poner nada en produccion con paravirtualizacion. Tiene muy buena pinta pero si no quieres estar sufriendo una solucion recien nacida no os lo aconsejo.

La eleccion del sistema de ficheros GFS (o GFS2 si logro ponerlo) viene dado por los conocimientos que tengo (hemos echado a andar un cluster gfs para web(apache) y servidor de apps(tomcat) y funciona a las mil maravillas). Otras implementaciones como PolyServe están fuera de presupuesto.

Algunas ideas/pasos para ponerlo en marcha:

Instalacion de GFS en una maquina virtual.
En esto no creo que tengamos problemas, es identico a una maquina real. La instalación en un RedHat 4U4 la haré por rpms.

Clonacion.
Una vez tenemos una vm (nodo) del cluster bien configurado lo clonamos (con lo que tenga en eso momento, copiando discos vmdk y cambiando los vmx…). De esta forma tendrmos 3 nodos idénticos. Necesitariamos una vlan para señalización del gfs y otra vlan para los datos de aplicación.

Acceso Raw Device Mapping.
Las luns de datos estarán en una cabina DS4300, haremos un RDM de dichas luns.

Fencing.
Esta es una de las cosas que mas me preocupa. El fencing es la forma que tiene el gfs de impedir que un nodo corrompa el fs. Cuando un nodo ha perdido heartbeats (se envían por la red de señalización) los demas nodos que forman el cluster deciden que no tenga acceso a los datos. Esto se puede hacer de diversas formas: Por medio de un switch de corriente(apagando el nodo), Cortando el acceso a la lun de datos,etc.

Cuando los nodos son reales esto no supone ningun problema, pero ¿ Y con maquinas virtuales ? Buscando en google(herramienta de trabajo donde las haya) podemos ver que no hay mucho implementado a este respecto.

Podemos ver la solución que nos plantean aqui .
Se trata de un script de perl que manda un comanda com vmware-cmd al ESX remoto que alberga el nodo que ha perdido la comunicación.
Esta solución no es viable puesto que con ejecutar de forma local el comando vmware-cmd.pl ruta_a_la_vm.vmx off hard ya nos tardaría alrededor de 3,5″, tiempo inaceptable para un cluster en producción puesto que hasta que el nodo no es ‘fenceado’ el nodo que ‘fencea’ no tiene acceso al FS.

La solución más inmediata y elegante es realizar el fenceo via RPC. Matando la vm, averiguando su pid a través de su numbre (nombre.vmx).

Las pruebas que llevo hasta ahora me dan tiempos de 40ms en local y desde remoto unos 80ms, claro que depende de la latencia de la red. Por ello nos viene muy bien el hecho de que la señalización vaya por una vlan diferente.

Pruebas de carga.
Bueno , esto está por ver. Es posible que se hagan pruebas con IMAP.

Espero escribir un poco mas sobre el tema pronto.