Enhanced VMotion Compatibility

A lo largo de los ultimos años os habréis visto en la necesidad de ampliar vuestra infraestructura virtual con nuevos servidores y ver que al incluir una nueva generación de procesadores no podemos hacer VMotion con los antiguos. El problema de la compatibilidad con VMotion viene dado por la incorporación de nuevos juegos de instrucciones en cada generación de procesadores que hacen que una maquina virtual no deba ser migrada de un procesador a otro de una generación anterior para garantizar su estabilidad.

Por ejemplo, si una aplicación esta ejecutándose en un servidor con procesadores basados en arquitectura Penryn que soportan el juego de instrucciones SSE4.1 y permitimos migrarla a un servidor donde la arquitectura del procesador es Merom-SSSE3, la aplicación no se da cuenta de esta migración y al intentar hacer uso de alguna instrucción SSE4.1 para optimizar su ejecución generara una excepción y provocara que el sistema deje de funcionar.

Las mascaras para hacer compatibles procesadores de distinta generación Intel Prescott-SSE3, Merom-SSSE3, Penryn-SSE4.1 o Nehalem-SSE4.2 nunca han estado soportadas por VMware como indican en los KB1991(Intel) y KB1992(AMD)

Para remediar este problema los nuevos procesadores vienen con una funcionalidad que permite al VMM ocultar características del procesador, modificando las respuestas de la instrucción CPUID, para hacerlos compatibles con otros procesadores mas antiguos. Esta tecnología se conoce con el nombre de FlexMigration en Intel o Extended Migration en AMD.

La funcionalidad que utiliza esta tecnología en VI3 se encuentra disponible a partir de ESX3.5U2 y VC2.5U2 bajo el nombre de EVC o Enhanced VMotion Compatibility. Cuando habilitamos EVC en cluster de ESX lo que estamos haciendo es decir al VMM que muestre a las maquinas virtuales el conjunto de instrucciones mas bajo que soportan todos los procesadores del cluster, por defecto este juego de instrucciones es el de la arquitectura Merom-SSE3 en el caso de Intel, de esta forma todos los procesadores presentan las mismas características de este procesador base.

Los servidores con procesadores que no tengan las características del procesador base o no soporten FlexMigration no podrán ser agregados a un cluster de EVC.

Si al agregar un host a un cluster de EVC os da un aviso de que el servidor no puede ser agregado porque no está soportado por EVC debéis revisar lo siguiente:

• Los procesadores del servidor soportan Intel FlexMigration o AMD-V Extended Migration o son del tipo base definido.

• En la BIOS tenéis habilitadas las funcionalidades Intel VT Virtualization Technology y XD Execute Disable Bit o equivalentes en AMD-V.

• Las maquinas virtuales del servidor que queréis añadir están apagadas.

• Todos los servidores del cluster se encuentran en la versión ESX3.5 U2 o superior y están manejados por VC2.5 U2.

Esta tecnología no permite hacer compatibles procesadores de distintos fabricantes AMD/Intel. La compatibilidad de VMotion a nivel de fabricante queda de la siguiente manera:

• Intel Merom Xeon® 3200, Intel Xeon® 5300, Intel Xeon® 7300 o posteriores.

• AMD Second Generation Opteron (Rev-E/F), AMD Third Generation Opteron (Barcelona) o posteriores.

Guía de referencia de VMotion:
http://www.vmware.com/files/pdf/vmotion_info_guide.pdf

Lista de procesadores compatibles:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003212

Offline VDI

Desde hace tiempo se venia escuchando hablar de Offline VDI o lo que es lo mismo escritorios virtuales que se mueven con el usuario y con los que podemos trabajar aunque no tengamos conexión a la red. Mientras el usuario esta en la oficina o tiene conexión a la red puede conectarse a ellos tal como hacemos actualmente. Pero que ocurre si el usuario quiere trabajar con su escritorio virtual cuando esta de viaje o en un avión? Con esta tecnología el usuario antes de marcharse puede llevarse una copia local de su escritorio y cuando vuelva a la oficina o tener conectividad sincronizar los cambios y trabajar en remoto.

En el VMworl 2008, VMware demostró por primera vez el concepto de Offline VDI. De momento utilizan una versión reducida de VMWare Player para que el usuario pueda ejecutar su escritorio virtual en local. La primera vez que el usuario quiere llevarse el escritorio, VDM lo marca como no accesible y lo descarga completamante al ordenador del usuario donde se ejecutara mediante VMware Player. Utilizando la tecnología de snapshots y ficheros delta se reducen los tiempos de sincronización posteriores de manera que cada vez que el usuario quiera sincronizar su escritorio solo se transfieren estos ficheros delta.

En los próximos años supongo que empezaremos a ver ordenadores sin sistemas operativos instalados, únicamente con vClient integrado en BIOS o FlashCard y que nos permitirán conectarnos a escritorios virtuales remotos o ejecutar una copia local.

vClient

Es la iniciativa de VMware para llevar un hypervisor de Tipo 1 ( bare-metal ) a los ordenadores personales. Hasta ahora, para ejecutar distintas maquinas virtuales en nuestros ordenadores, utilizábamos productos como VMware Workstation. La idea es que nuestros ordenadores vengan con un pequeño hypervisor integrado en BIOS o FlashCard y el sistema operativo se ejecute en un entorno completamente virtualizado.

Una ventaja clara de llevar este tipo de virtualizacion a los ordenadores personales es que una misma plantilla de Windows XP podría ejecutarse sobre un portátil de HP o uno de IBM sin tener que mantener dos imágenes diferentes.

Otra ventaja clara y alineada con la iniciativa VDI de VMware, ahora englobada dentro de VMware View, es la posibilidad de ejecutar o conectarnos a escritorios virtuales sin necesidad de tener un sistema operativo instalado por debajo.

Virtual Datacenter OS

VMworld 2008 nos ha mostrado el camino que VMware va a seguir durante los próximos meses. Si VMWorld Europe 2008 se centro entorno a la seguridad con las iniciativas VMsafe y ESX 3i, ahora le ha tocado el turno a la idea del CPD totalmente virtualizado que VMware lleva persiguiendo desde hace tiempo.

Esta iniciativa esta basada en dos pilares fundamentales:

• VDC-OS
• vCloud

VDC-OS

No es un sistema operativo propiamente dicho sino la evolución de VMware Virtual Infraestructure, está formado por un conjunto de capas que interactúan entre si.

Si empezamos por el nivel mas bajo nos encontramos la propia infraestructura física de comunicaciones, servidores y almacenamiento. Esta infraestructura puede estar alojada en nuestro CPD ( On-Premise Cloud ) o bien en otros CPDs o ser alojada por proveedores de servicio ( Off-Premise Cloud ).

En el corazón de la infraestuctura se sitúa Vmware Virtual Infraestructure que provee los siguientes servicios al entorno:

• Aplication vServices, proporcionan disponibilidad, seguridad y escalabilidad a las aplicaciones mediante las tecnologias de VMotion, SVMotion, FT, HA, DRS, VMsafe y VCB.
  

• Infraestructure vServices, abstraen la infraestructura física de los servicios de aplicación, de manera que las aplicaciones puedan liberarse de los inconvenientes asociados al hardware.

• Managment vServices, manejan, monitorizan y detectan problemas en la infraestructua y las aplicaciones. Estos servicios serán utilizados por productos como vCenter o vCenter AppSpeed, que permitirá monitorizar, detecta y resolver problemas de rendimiento en nuestras aplicaciones.

• vCloud vServices, proporcionan la integracion necesaria entre las distintas vClouds tanto internas como externas.

En la última capa se encuentran las aplicaciones y GuestOS que utilizan los servicios ofrecidos por VDC-OS para ejecutarse en un entorno seguro, eficiente y tolerante a fallos.

Un entorno que:

• Se adapta a las necesidades de los servicios desplegando o moviendo maquinas para cumplir los SLAs y reducir el TCO.
  

• Se adapta a fallos de servidores (HA, FT), de comunicaciones ( NIC Teaming, Storage Multipathing) o a desastres (VMware SRM).
  

• Permite a productos de seguridad tener una visión al detalle del entorno. VMsafe proporciona visibilidad a nivel de hypervisor para detectar ataques, virus o cualquier código malicioso e impedir sus efectos antes de que lleguen a la aplicación. Recordemos que los principales fabricantes de productos de seguridad como Checkpoint, Symantec y McAfee han confirmado que en 2009 sus productos estarán completamente integrados con VMsafe.

vCloud

Es la iniciativa de Cloud Computing anunciada por VMware, la idea es crear infraestructuras que permitan mover y ejecutar servicios entre datacenters locales y externos. Más de 100 proveedores de servicio ya se han aliado con VMware para desplegar vClouds certificadas y solventar los problemas técnicos que requiere esta tecnología. Recordemos que VMotion y FT solo funcionan dentro del mismo datacenter y requieren almacenamiento compartido. Ya se oyen rumores de que en futuros VMworld oiremos hablar de GeoVMotion o Faul-Tolerance entre distintos datacenters.

Recordemos que Amazon ya lleva tiempo ofreciendo servicios de Cloud Computing. Este servicio se ofrece bajo el nombre de Amazon EC2 (Amazon Elastic Compute Cloud) y esta basado en el hypervisor Xen. Yo pienso que durante los proximos años va ser difícil convencer a las empresas de mover sus servicios hacia este tipo de "nubes" fuera del control de su CPD. Otro punto interesante de esta arquitectura es aprovechar el Cloud Computing para desplegar VDI, de esta forma nuestros escritorios se ejecuten sobre la vCloud o EC2 y tenemos acceso a ellos desde cualquier lugar con una simple conexión a Internet.

Gracias a vCenter Chargeback los proveedores podran monitorizar y cobrar a los clientes en función de los recursos que utilicen dentro de su infraestructura.

Por otro lado disponemos de mas de 1000 aplicaciones distribuidas como Virtual Appliances preparadas para ejecutarse y moverse entre estas vClouds. Cada vez más fabricantes de software apuestan por distribuir su software de esta manera.

Hay cierta presión para que VMware, Citrix y Microsoft utilicen un formato de Virtual Appliance compatible. Recordemos que una maquina virtual para Xen se puede ejecutar en Hyper-V y viceversa. De esta forma los fabricantes solo tendrían que liberar un Virtual Appliance de sus aplicaciones y este podría ejecutarse en una vCloud basada en Xen, Hyper-V o VMware.