El wizard de la migración en caliente, VMware VMotion, valida los requerimientos del servidor origen y servidor destino así como los requerimientos de la maquina virtual que quieres migrar.

Una máquina virtual no puede ser migrada en caliente cuando:

• La MV tiene una conexión activa a un virtual switch de uso interno.
• La MV tiene una conexión activa a un CD o disquete.
• La MV tiene configurada una afinidad a una CPU.
• La MV forma parte de un clúster Microsoft.

El wizard de migración en caliente, VMware VMotion, produce un warning cuando:

• La MV tiene una conexión a un virtual switch de uso interno pero no está conectado.
• La MV tiene una conexión a un CD o disquete pero no está conectado.
• La MV tiene uno o más snapshots.
• El servidor VMware vSphere ESX/ESXi no ha recibido un guest OS heartbeat (probablemente las VMware tools no han sido instaladas o configuradas adecuadamente).

El wizard de migración en caliente, VMware VMotion, muestra un mensaje de error si la máquina virtual no puede ser migrada desde el servidor origen al servidor destino. Sin embargo, con un mensaje de error de tipo warning, la máquina virtual puede ser migrada con VMotion sin problemas.

Asimismo, los servidores involucrados en la migración, servidor origen y servidor destino, deben cumplir los siguientes requerimientos:

• Visibilidad de todas las LUNs (FC, iSCSI, NAS) usadas por la MV.
• Una red Gigabyte Ethernet dedicada al tráfico VMotion. (En una red 10/100 también funciona pero va muchoooo mas lento. No ostante, VMware solo soporta una red Gigabyte para el trafico VMotion.
• Acceso a la misma red Ethernet física.
• El nombre de los virtual switch debe ser igual en ambos Servidores ESX (incluyendo mayúsculas y minúsculas). En VMware vSphere ESX/ESXi versión 4 update1, si los virtual switches no son nombrados iguales, el wizard de migración en caliente VMotion produce un warning pero la migración puede continuar.
• CPUs compatibles o similares (misma familia CPU). VMotion también funciona, si el servidor origen tiene Hyperthreading activado pero no el servidor destino

Seguro que se me escapan algunos requerimientos de VMotion, con lo que si no ves aquí todos, o crees que falta alguno, por favor déjame tu comentario.

Me acaban de llegar a las manos las hojas técnicas de los nuevos servidores de Cisco.

Mucho hemos oído hablar de que Cisco quería entrar en el tema de Servidores de la mano de su coalición con VMware. Y aquí están.

Os presento al UCS C200 M1 High Density Rack-mount server. Servidor de 1U con 2 sockets y con 12 slots de memoria, llegando a poder instalar 96 Gb con alta densidad o bien llegar a tasas altas con precios asequibles.

Incorpora 2 Nics de 10 Gb y un nuevo chipset que es capaz de gestionar la memoria para ofrecer más memoria de la que realmente tiene (me han dicho un número de veces que quiero antes validar.)

A ver si me cae uno en demo y os cuento cosas bonitas sobre ellos….. también hemos de ver los precios.

Podéis ver una demo interactiva en este link

Hola amigos, si recordaís hace ya algunos post os comentaba que Citrix lanzó NetScaler VPX, appliance que podemos descargar desde la web de Citrix e importarla sobre nuestro XenServer y que es muy interesante según que entornos pero que viene limitada según los recursos hardware de nuestro hypervisor.

Os recuerdo alguna de sus características:

• Maximum HTTP throughput – 1Gbps
• Maximum compression – 750 Mbps
• Maximum Application Firewall – 500 Mbps
• Maximum SSL transactions/second – 500 Mbps
• Maximum SSL through put – 1Gbps

Hoy os explicaré las diferencias que tiene con la versión hardware y recomendaré cuando hay que usar uno u otro.

La principal diferencia entre ambos es el rendimiento. La versión virtual de NetScaler no incluye hardware especifico para la aceleración SSL. NetScaler VPX soporta etiquetado de tráfico pero este es limitado a lo que soporte nuestro hypervisor. En cambio NetScaler MPX tiene soporte nativo para 802.1q.

NetScaler VPX no soporta 802.3ad, es decir link aggregation, puesto que no es soportado por XenServer. NetScaler MPX sí que tiene soporte nativo para 802.3ad.

¿Cuando debemos usar uno u otro?

Utilizaremos la versión hardware cuando:

- Necesitemos grán ancho de banda y rendimiento.
- Necesitemos gran volumen de tráfico SSL
- Mas de 100 sesiones VPN concurrentes.
- Sea requerido FIPS

Utilizaremos la versión virtual cuando:

- Estemos en entornos de pruebas o de desarrollos.
- Datacenters virtualizados y con hypervisores con gran capacidad de proceso.

Nada mas, espero que si os veis en situación de elegir uno u otro os sirva de ayuda.

¿Hola que tal de nuevo?. Pido mis disculpas a José María y todos nuestros lectores por el retraso en mis POSTS ya que he tenido un ligero contratiempo a lo largo de este mes que me ha hecho ir más lento con vosotros de lo que yo quisiera.

Una vez explicado esto, quería haceros llegar algo que ya he probado y que me ha sorprendido por su funcionamiento con un programa de almacenamiento SAN como es Openfiler (Código Abierto). Como realizar un Cluster entre SAN con Openfiler para la redundancia de nuestras VMs?.

Mirando en varios Blogs y otros donde ponían como realizarlo (HOW to) os transmito paso a paso como realizarlo. Aunque cabe reseñar antes de empezar, que todo se basa en el protocolo DRDB, el cual es básicamente una replicación continua vía TCP/IP mediante nuestra red Ethernet.

Lo primero es descargar e instalar openfiler en las dos máquinas. Hay una imagen para x86 o para x86_64 según las máquinas de que dispongáis. Durante la instalación, haced las particiones idénticas en los dos servidores, y cuando reiniciéis, os tendréis que asegurar que no se montan las particiones que se van a replicar entre los dos servidores. En mi caso, hice el siguiente particionado:

• /dev/hda1 — /boot – 150MB
• /dev/hda2 — / — 10GB
• /dev/hda3 – swap – 1024MB
• /dev/hda5 – 512MB – Será donde guardemos los ficheros de config para el cluster.
• /dev/hda6 – 12,9 GB – Haremos un share SMB
• /dev/hda7 – 12,9 GB – La usaremos como target iSCSI para VMWare

Para que nos quede un poco mas claro, las particiones que replicaremos serán las de datos y la de configuración del cluster. Las de sistema no será necesario replicarlas ya que el sistema está instalado en ambos nodos. Aseguraos también de que los dos nodos resuelven correctamente el nombre del otro y opcionalmente, montad la autentificación por claves de ssh, para no tener que escribir el password cada vez que hagáis un scp.

DRBD

Montar drbd es bastante sencillo. Lo primero que tenéis que hacer es aseguraros de que las particiones estén vacías, ya que es muy probable que durante la instalación hayáis creado un sistema de ficheros sobre ellas. Si fuese así:

dd if=/dev/zero of=/dev/hdaX bs=1M count=1

Con esto borráis las particiones y las dejáis impolutas para que podáis empezar a replicar. Lo siguiente, editamos el fichero /etc/drbd.conf en el nodo 1. Ahí tendremos que especificar un par de opciones generales y los arrays que váis a crear:

Ejemplo del fichero de configuración.

Luego lo copiamos al nodo 2. Una vez tenemos el fichero de configuración podemos crear los arrays (esto hay que hacerlo en ambos nodos):

• drbdadm create-md cluster_metadata
• drbdadm create-md vg0drbd
• drbdadm create-md vg1drbd

Y arrancamos el servicio drbd en los dos nodos. Si miráis el fichero /proc/drbd, veréis que el estado de los discos es inconsistente y que ambos nodos estan como secundarios. Así que en el nodo 1 hacéis:

• drbdsetup /dev/drbd0 primary -o
• drbdsetup /dev/drbd1 primary -o
• drbdsetup /dev/drbd2 primary –o

Con esto hemos puesto al nodo 1 como primario en todas las particiones que gestiona drbd. Ahora si miráis el /proc/drbd, veréis como está replicando los datos. Ahora hay que añadir drbd al inicio del sistema y ya de paso, creamos el sistema de ficheros en la partición que nos guardará los ficheros de configuración del cluster.

• chkconfig –level 2345 drbd on (en ambos nodos)
• mkfs.ext3 /dev/drbd0 (en el nodo 1)

En este punto, con los arrays creados, nos referiremos siempre al los dispositivos drbd para I/O para cualquier operación con discos.
Siguiente, editamos el fichero /etc/lvm/lvm.conf y cambiamos el filtro de esto:

• filter = [ "a/.*/" ]

a esto:

• filter = [ "r|/dev/hda*|" ]

y procedemos a crear el physical volume sobre drbd1 (el otro sera sobre drbd2, ya que el 0 no será gestionado por lvm).

• pvcreate /dev/drbd1

En la siguiente parte, te contare la parte del heartbeat y de como terminar la configuración de drdb.

Hasta la próxima semana.

Irene Kalmykova, Sales Director de 5nine.com, se ha puesto en contacto con el blog de virtualizacion en Español para dar a conocer sus últimos productos P2V & V2V para Hyper-V y VMware vSphere.

5nine P2V Planner, crea migraciones P2V automatizadas y personalizadas para Microsoft Hyper-V y VMware vSphere. Este software P2V no solo realiza la conversión de físico a virtual con un gran porcentaje de éxito sino que además te proporciona una comparación tipo TCO/ROI sobre cuál es la solución mas adecuada, VMware vSphere o Microsoft Hyper-V.

Estoy deseando probar esta nueva funcionalidad en mis conversiones de físico a virtual.

Otra de sus soluciones, 5nine Virtual firewall para Hyper-V, monitoriza y controla el tráfico entre máquinas virtuales de Microsoft Hyper-V y la red externa (y viceversa).

La buena noticia es que la versión actual es gratuita y está disponible para su descarga en su web.

La mala noticia es que la próxima versión, que será lanzada a fines de enero, será un producto de pago, con lo que yo que tú me daría prisa en bajarme la versión gratuita para poder jugar con ella.

Update 1: Si vas a asistir al evento de Magirus OpenHouse y eres asidulo lector de este blog, por favor, mandame un email a mi direccion personal y te entregare una camiseta especial del Blog de Virtualización en Español durante el evento. Por favor, incluyeme en el email tu talla para no equivocarme

Un año más, Magirus OpenHouse’10, es el punto de encuentro anual en el que se darán cita fabricantes, partners y clientes finales.

Magirus OpenHouse’10 girará en torno a un tema protagonista: Cloud Computing. Magirus, en esta nueva edición, se ha propuesto demostrar cómo todas las tecnologías giran alrededor de “La Nube”.

El evento es gratuito y se celebrará en Madrid, el jueves 4 de febrero de 2010 y es dirigido a resellers, integradores, ISPs, consultores y clientes finales.

Pedro Llamas, monologuista de la Paramount Comedy, hará de maestro de ceremonias dando un toque de humor a las sesiones. Así mismo, contaremos con la inestimable presencia de César Pérez de Tudela, uno de los exploradores más influyentes y mentalizadores de la aventura y el alpinismo. Con él, tendremos una visión diferente de “La Nube”.

El evento dispondrá de espectáculo en directo, regalos para todos los asistentes, sorteos en cada ponencia, y muchas cosas más. Asimismo, mi presencia tambien esta confirmada con lo que tendre el placer de conocer a tantos lectores del blog como pueda y quizas si la logistica me lo permite podre repartir algunas copias de mi ultimo exito: 101 Secretos de VMware vSphere.

Recuerda que para incribirse al evento has de hacer clic en este enlace y que la direccion es la siguiente: Hotel Puerta América. Avenida de América, 41. 28002 Madrid

Nos vemos en el Magirus OpenHouser’10

VMware proporciona una utilidad llamada VMware CPU bootable Utility, la cual puedes descargar desde la propia web de VMware.

Una vez que arranques tu servidor ESX/ESXi desde CDROM con dicha utilidad, podrás comprobar si tu servidor VMware ESX/ESXI soporta las funcionalidades SSE, SSE2, NX/ED, Hyperthreading, Intel VT (Virtual Technology), AMD-V

VMware VMotion no tiene en cuenta la diferencia en la velocidad del reloj de la CPU de tus servidores ESX/ESXi, ni la diferencia en la memoria de la cache L1, L2, ni la diferencia en el numero de cores o sockets.

Asimismo VMware VMotion no tiene en cuenta las diferencias de memoria RAM entre los servidores ESX/ESXI involucrados en la migración en caliente.

La única pega que le veo a esta utilidad es que has de apagar tu servidor ESX/ESXi para comprobar que opciones y funcionalidades tiene soportado tu servidor VMware ESX/ESXi.

Hola que tal?

Parece que nos hemos puesto de acuerdo en hablar del tema “Backup”. Pues vamos a ello.

Veeam Backup usa la técnica de Backup sintético, permitiendo tras efectuar un backup completo, efectuar backup tan sólo de los cambios incrementalmente. La técnica habitual que usan los productos similares es crear un fichero “grande” con el “full backup” para posteriormente ir creando ficheros “delta” con los cambios incrementales una vez vamos ejecutando el job.

Una vez alguien dijo “El problema no es el Backup, es el Restore”. Cuanta razón tenía, recuerdo cuando trabajaba con Mainframes y teníamos que “tirar” de cinta (si, aquellos armarios increíbles con cintas más grandes que los magnetófonos) y oía al técnico de sistemas “no lee, no restaura”. Un sudor frío pasaba por nuestra espalda hasta que al fin el milagro se producía y restauraba.

La premisa es la siguiente. Si vas a restaurar, estadísticamente lo que vas a buscar en primera instancia para cubrir el RTO es la última copia que hemos hecho. Si ésta es completa en lugar de sintética, siempre nos dará más facilidades (rapidez, consistencia, etc.)

Es por ello que Veeam usa la particularidad de copia “reverse” o decremental, por la cual, el primer backup completo nos creará el fichero principal pero cuando ejecute la primera incremental nos encontraremos con que el fichero perteneciente a la primera ejecución tiene sólo las diferencias, mientras que el último que hemos efectuado está “completo”.

Como trabaja Veeam? Curiosamente de una forma muy parecida a como gestiona los snapshots Datacore.

Tras la generación del fichero .vbk en la primera ejecución, cuando se ejecuta la primera copia incremental, Veeam actualiza los cambios que han habido en el sistema en explotación en el fichero .vbk, guardando todos los datos antiguos que han sido actualizados en un fichero .vrb para esta ocasión.

El fichero .vbk tendra como nombre de fichero el que le hemos asignado al hacer el job, mientras que el .vrb, además del nombre llevará concatenado el “timestamp” del dia y la hora en que se inició el job.

De esta forma podremos identificar los ficheros que tenemos en nuestros directorios ya que tendremos un fichero copia.vbk y tantos .vrb como rollbacks hayamos parametrizado, que se denominarán copiayyyy-mm-ddThhmmss.vrb.

Mecanismo parecido pasa con las réplicas, pero con diferencias, ya que una réplica en el fondo es una vm preparada para ponerse en marcha asap, entonces el fichero .vbk es substituido por el .vmdk de la VM, trabajando los vrb de igual forma que el Backup. Podéis obtener un resumen y más información en www.veammeup.com, blog que mantienen los chicos de ingeniería de Veeam de San Petersburgo, desde aquí un saludo.

Especial cuidado si estáis corto de espacio en el espacio smb que contiene estos ficheros y los movéis. A partir de la versión 4.0, Veeam Backup cuando editas el job, y en la ejecución del mismo hace ciertas verificaciones de la existencia de los ficheros destino. Hablaremos otro día de este tema y de como cumplir con las normas de seguridad y auditoría haciendo servir discos intercambiables y jobs alternados de copia.

Como anécdota, en orden interno VBK ha quedado como una acepción de “Hacer un Veeam Backup”, de esta forma, en slang podemos oír “el cliente VBKs tres servidores”

La próxima semana hablaremos de como efectuar un fine tuning de nuestro sistema detectando cuellos de botella y dimensionamientos no adecuados.

Hola amigos,

En el siguiente post veremos como instalar el servidor de Hyperic sobre Centos x64, mi distribución linux favorita, donde tendremos a todos nuestros XenServer monitorizados:

En post anteriores os expliqué como instalar el cliente de hyperic sobre nuestro servidor XenServer de manera que este pueda conectarse con el servidor para poder tener los servicios de XenServer monitorizados.

Desde la consola descargamos el rpm para x64:

wget http://sourceforge.net/projects/hyperic-hq/files/Hyperic%20HQ%204.2/HQ%204.2.0/hyperic-hq-installer-4.2.0-1.x86_64.rpm/download

Instalamos los siguientes paquetes:

yum install libXp expect

Instalamos el rpm descargado:

rpm -UHv hyperic-hq-installer-4.2.0-1-x86_64.rpm

Arrancamos el servidor:

su hyperic
/opt/hyperic/server-4.2.0/bin/hq-server.sh start

Abrimos un navegador y ponemos lo siguiente en la barra de direcciones:

http://ipDelServidor:7080
usuario:hqadmin
pass:hqadmin

Cuando vayamos instalando los clientes en nuestros diferentes servidores y servicios a monitorizar, como por ejemplo el cliente de XenServer que os expliqué hace unas semanas, al conectarse con el servidor, gracias a la utilidad “Auto-Discovery” él mismo detectará los servicios configurados en esa máquina así como sus características y te propondrá que lo incluyas en el inventario de servidores monitorizados.

Igualmente podremos añadirlo manualmente desde Resources–>Tools Menu–>New Plaform

Como ya os dije, llevo unas semanas probando esta herramienta y la verdad es que me está sorprendiendo gratamente, os la aconsejo.

Nada mas amigos, espero que os sea de utilidad.

La semana pasada Microsoft y HP anunciaron un acuerdo de colaboración millonario – $250 millones de dólares – para ofrecer directamente en partnership, un nuevo modelo de infrastructure-to-application y soluciones avanzadas de cloud computing para reducir los costes y la complejidad de TI.

La virtualización es, por supuesto, el centro de atención del partnership entre Microsoft y HP. Las nuevas soluciones basadas en infraestructura HP y software de virtualización de Microsoft, Hyper-V, en teoría, permitirán a los clientes acelerar el tiempo de despliegue de las aplicaciones, reducir el tiempo de caída no planificada, y reducir los costes de infraestructura.

Este es, sin lugar a dudas, un gran compromiso por parte de ambas empresas. El acuerdo, establece tres componentes principales:

• Una hoja de ruta común de ingeniería para garantizar una integración sólida entre el hardware y software de las dos compañías, Microsoft y HP.
• Soluciones conjuntas para optimizar y simplificar el despliegue, gestión y “salud” del centro de datos.
• Una inversión inicial en el departamento de ventas, de servicios y para los programas del canal.

Puedes ver el comunicado de prensa en este enlace, y los videos ejecutivos y más información adicional en este otro enlace.

Habrá que ver, que clientes se decantan por utilizan HP + Microsoft Hyper-V en la nube y cuales se deciden por usar Hp + VMware vSphere …. y lo mas importante, cual es el factor de elección de una solución vs la otra por parte del cliente?. El tiempo nos dirá.