Be virtual, My friend: VMware

Mostrando entradas con la etiqueta VMware. Mostrar todas las entradas

domingo, 31 de agosto de 2008

Opinión: Mis razones para preferir VMware.

Tras una buena temporada de ausencia de Be Virtual, debido no a las vacaciones, sino a una serie de cambios profesionales que me han traído de cabeza, me propongo a volver con renovados ánimos (si no, me temo que el maestro Ros se va a enfadar en serio), y empiezo con este post que he titulado "Mis razones para preferir VMware". Las razones aquí expuestas se dividen en dos grandes grupos: Técnicas y no técnicas. Las primeras, por supuesto, son fruto de mi visión del mercado (cuestionable o no) y las segundas, fruto de mi experiencia técnica y mi día a día. (Con esto quiero decir que quien las cuestione, por favor use el mismo tipo de argumentos).

Empecemos.

Madurez de producto: VMware ESX (En cualquiera de sus versiones) es, indiscutiblemente, el producto más maduro en lo que a hipervisores se refiere. A casi diez años de evolución deben prepuonérseles madurez, estabilidad y rendimiento. Creo que esta presunción es aplicable a todos los fabricantes de software en todas sus gamas de producto: Microsoft, con SQL Server o Windows Server, Oracle con su base de datos, etc.

Liderazgo del mercado: Con un 85% de cuota del mercado (la misma que Microsoft en el mercado de servers x86), VMware ha convencido a una inmensa mayoría de las empresas más importantes que han apostado por la virtualización de que usen su producto. El cómo lo haya hecho (Calidad técnica o marketing) no es algo que esté en mi mano evaluar (al igual que tampoco lo está el cómo lo ha conseguido, por ejemplo, Microsoft u Oracle). Simplemente uso el mismo parámetro que usan otros.

Amplio soporte de la comunidad: Al igual que el Cisco IOS, Microsoft Server y demás, Oracle y otros, la comunidad en el caso de VMware, resulta un gran apoyo en lo que a soporte se refiere, tanto en resolución de incidencias como en apoyo a la hora de configurar y gestionar.

Precio: Resulta que, además, ahora incorporar la tecnología insignia de VMware, Virtual Infrastructure, es gratis. Por 0 €/$, hoy podemos utilizar un hypervisor de última generación con características avanzadas, clustered filesystem (Sí, para los que tienen dudas o no han podido/no han querido leerse qué incluye 3i, VMFS también es gratis), y con la capacidad de escalar (eso sí, mediante pago) a las características completas de la suite: DRS, vMotion, HA, etc. Además, y siempre opcionalmente, es posible contratar el soporte completo por un precio realmente asequible (595 US$ en modalidad 24x7 para dos CPU), que resulta inferior que UNA sola consulta de soporte de otros fabricantes. Además, no debemos olvidar que ESX 3i no requiere el pago de una licencia de sistema operativo para funcionar. En determinados entornos (Linux y similares), esto supone un ahorro de unos 600€ (aproximadamente)

Política/naturaleza de compañía: Mientras VMware se esfuerza en que su producto sea cada vez más compatible con los sistemas operativos del mercado (no le queda otro remedio, ya que la propia VMware no fabrica ninguno) , colabora en todos los foros de otros fabricantes (Es miembro del Microsoft Server Virtualization Validation Program - SVVP), e incluso dona a la comunidad tecnologías como VMI (Virtual Machine Interface), o estrena iniciativas como vSafe (a la que ya se han adherido todos los fabricantes de productos de seguridad), otros fabricantes no hacen lo mismo. La impresión que se extrae es clara: VMware colabora (porque no le queda otra) mientras otros no lo hacen (porque el core de su facturación no está en el hypervisor). Así mismo, por la propia naturaleza de la compañía, y por el accionariado que tiene detrás (EMC, Cisco, Intel, etc) se puede inferir que mantendrán su producto a la última, ofreciendo siempre lo mejor que la tecnología pueda dar. En el caso de otras compañías más generalistas, no es la primera vez que vemos como un producto anunciado desaparece en medio de las políticas de empresa: WinFS, OracleFS, Oracle Mail, etc. No es desdeñable el hecho de que VMware no tiene "sardina" a la que arrimar su "ascua", lo que quiere decir que su desarrollo no beneficiará más o menos a cierto sistema operativo, o a cierta solución de seguridad, o a cierto motor de base de datos, por poner ejemplos.

Solución completa e integridad del producto: Mientras VMware ofrece virtualización "extremo a extremo" (al igual que otros fabricantes lo hacen en otros aspectos - Microsoft sin ir más lejos ofrece tanto el Sistema Operativo, como el motor de base de datos, así como las herramientas que los rodean), Hypervisor, clustered file system, HA, gestión de Disaster recovery, gestión de operaciones y ciclo de vida, Virtual Desktop, backup, etc, otras requieren de productos de terceros porque en su catálogo no incorporan las soluciones requeridas. Como ejemplo, el clustered file system. Mientras la necesidad de un clustered file system fué identificada por VMware como fundamental para la Live Migration o la futura Continuous Availability (HA sin disrupción de servicio) (recordemos que VMFS existe desde ESX 1.0 y ya va por su versión 3.2x), otras compañías confían en productos de terceros que no son precisamente baratos (MelioFS, de SANbolic es un claro ejemplo).

Vamos con los técnicos.

Virtualización completa de extremo a extremo: Sin entrar a discutir términos como los diferentes tipos de hypervisor (Tipo 1, Tipo 2... o Tipo 1 y dos cuartos, o Tipo 1.25), ESX es el único hypervisor que gestiona integramente todos los aspectos de la virtualización: Gestion de VM e I/O. Mientras Hyper-V y Xen escogen la opción de dejar el I/O en manos del sistema operativo que se ejecuta en el dominio raíz, ESX gestiona integramente el I/O, independizándose de un sistema operativo que no deja de ser una VM más. Es decir, todo el I/O (red y disco) de las VM virtualizadas depende de una máquina virtual más. No lo digo yo, cito a mi respetado David Cervigón:

"1.- Las arquitecturas de Hyper-V y ESX son diferentes (Xen e Hyper-V tienen la misma aproximación). En hyper-V el hypervisor es delgado, 800Kb, en microkernel. En ESX hablamos de un hypervisor monolítico, donde deben incluirse toda la funcionalidad de I/O a bajo nivel, en particular red y almacenamiento. ESX no necesita más, cierto, pero solamente tiene la funcionalidad limitada que "cabe" en esos aprox 32 MB. De ahi que se restrinja a una HCLlimitada. Hyper-V depende de Windows, cierto, pero en su arquitectura en su arquitectura la particion padre (que no deja de ser una VM) es la encargada de interaccionar con el sistema de red y de almacenamiento."

En un entorno Hyper-V o Xen, todo el I/O depende de un driver que puede o no estar optimizado para la virtualización, y que puede o no ser adecuado para un entorno de múltiples máquinas virtuales. VMware blinda sus drivers y los adapta para el uso por parte de un Hypervisor.

Por otra parte, TODAS las funciones de virtualizacíon están aisladas del resto de las funciones (como las que provee el COS - Console Operating System), lo que supone que el I/O NO es un punto de exposición del Hypervisor.

Virtualización independiente del hardware: ESX usa el método de traslación binaria (es decir, las instrucciones son traducidas por el Hypervisor), mientras Hyper-V y Xen delegan en el hardware (Intel/AMD VT) la gestión de las diferentes VM. Es decir: Sin VT no hay virtualización, lo que, evidentemente, hace que estos Hypervisores sean meros gestores de una capacidad hardware que puede o no variar con las diferentes versiones de las especificaciones de virtualización. Mi conclusión es clara: Virtualiza Intel o AMD, gestiona Xen o Hyper-V. para más info, un post anterior sobre la virtualización asistida por hardware. Así mismo, la traslación binaria permite soslayar muchas (no todas, gracias a Intel y a AMD) de las incompatibilidades entre distintas series de procesadores. El masking de registros nos permite incluir equipos con diferentes series de procesadores en un entorno vMotion. Por otro lado, Hyper-V y Xen recomiendan (lo que en la práctica se convierte en un requerimiento), que los procesadores sean IDENTICOS. Todos sabemos que, incluso para un mismo modelo de servidor, con unos meses de diferencia, es bastante posible encontrarse con diferentes generaciones de procesadores.

Live Migration: La capacidad de movimiento de VM entre un host ya no es una curiosidad técnica. En mi caso, si me privasen de ella, tendría que reorganizar prácticamente todos los procedimientos de explotación de plataforma virtual, e incrementaría drásticamente los downtimes. Evidentemente mi caso no es el de todos, pero estoy seguro que, en algún momento, todos echaríamos en falta esta característica. Hyper-V no la tiene (aunque está anunciada para su versión R2) y Xen presenta ciertos problemas de rendimiento y estabilidad que hacen de su implementación de Live Migration algo no apto para producción (cierto factor de indeterminismo bastante poco ponderable)

Virtualización de I/O: El soporte total de NPIV (N Port ID Virtualization), las capacidades anunciadas por Intel para la virtualización de I/O (VMDq) apoyan el precepto de que deben existir tecnologáis especificas para la virtualización, y que consecuentemente el hardware, los drivers y demás deben diseñarse especificamente para este propósito.

Memory Overcommit: Digan lo que digan, y hablando en plata, el Overcommit mola. Y si no que se lo cuenten al que compra un big node de 16 cores y "solo" 32 Gb de RAM.... Sin él, probablemente se quedará con la mitad de los cores sin usar. Evidentemente el overcommit no se aplica a todas las VM (Oracle bajo linux presenta inconvenientes), pero, como dice el anuncio, para todo lo demás....

Seguridad: ESX es monolítico, es verdad, y en eso consiste, para mí, su ventaja. No depende para nada del exterior, exceptuando los servicios de gestión que provee el COS (Console Operating System). Esta aproximación es similar a las de los Appliances, es decir, un SO personalizado, reforzado y especializado en una sola función... O al menos eso es lo que nos cuentan los fabricantes de appliaces... entre los que se incluye Microsoft con ISA Server o Windows Storage Server. Si vale para lo uno, vale para lo otro.

Herramientas, complementos de terceros: Sin duda, VI3 es la suite de virtualización más apoyada tanto por los fabricantes tradicionales como por nuevas startup: Veritas, Cisco, Intel son sólo un ejemplo de las primeras. VEEAM, vKernel, etc son ejemplo de las segundas.

Rendimiento y capacidad: Digan lo que digan quien lo diga, los ratios de virtualización con ESX son, como mínimo, un 30% superiores. Es decir, podemos ejecutar un 30% más de VM en ESX que sobre cualquier otra plataforma. Así mismo, el rendimiento, en especial en sistemas con múltiples VM, es, por término medio, mayor. Tampoco lo digo yo: Preguntad a San Google bendito.

Para terminar, analicemos ciertas afirmaciones que van corriendo por la blogosfera:

"Siendo Hyper-V de Microsoft, es razonable pensar que Windows funcionará mejor bajo Hyper-V". Bueno, Yo uso Windows Vista, y mi teclado es logitech, como mi ratón. Y no veo que los marca Microsoft vayan mejor. Puestos a seguir esa línea, Oracle no se vendería bajo Windows, desplazado por MS SQL, o Veritas se tendría que haber retirado del mercado, ahora que microsoft saca su producto de backup. Pero puestos a seguir, la realidad me va diciendo que esa afirmación no es del todo correcta: Veritas Cluster supera con mucho a Microsoft Cluster Service, o Forefront habría desplazado a McAfee... MelioFS parece que lo hace sobre NTFS, y así hasta el infinito. El producto estrella de Microsoft es Windows (en toda su familia) y es donde invierte. Es su negocio, y junto con Office, el "gordo" de su facturación. Si requerimos algo especial o con prestaciones adicionales.... recurrimos a software de terceros. ¿porqué con la virtualización debería ser distinto?

"El Hypervisor debe ser parte del sistema operativo": Vaya... es como si me dijesen que la BIOS debe ser parte del Sistema operativo.... o que el RAID5 debe hacerlo el OS... o que el routing de core de nuestra compañia debe ejecutarse en un servidor 2003/2008 con routing & remote Access....Cada uno que evalúe esta afirmación.

"Muchos GRANDES clientes están migrando a Hyper-V/Xen desde VMware": A ver. Migrar es dejar VMware y pasarse a Xen/Hyper-V. Yo que por mi actividad profesional, que incluye dar conferencias sobre temas de infraestructura, lidio con muchas de las grandes compañias de este pais, aún no conozco ningún caso donde se haya sustituído, en sistemas de producción, ESX por Hyper-V/Xen. Sí conozco casos donde los entornos de prueba, desarrollo y test se han virtualizado utilizando Hyper-V y por Xen (Y no siempre por motivos tecnológicos, y a veces por cierta presión). Recientemente un cliente (bastante importante en este país) me ha llamado para decirme que, con 3i gratuíto, iba a eliminar Hyper-V y Xen de sus entornos de desarrollo. Tampoco incluyo dentro de "migrar" la famosa actitud de los clientes de "Sí, hombre, móntalo por ahí y no me des más la barra".... actitud que yo sufrí allá por el 2000 a 2003 cuando empecé con esto de la virtualización.

Ultimo comentario para los que de último se dedican a decir que estoy vendido: Sí, estoy vendido. A la integridad de mis instalaciones, a la satisfacción de mis clientes, a los proyectos cerrados en fecha, a la fiabilidad y, por supuesto, a mi empleador... que no es VMware.

domingo, 7 de octubre de 2007

Opinión: ¿VMware - EMC o VMware + EMC?

No es un secreto que hay roces entre VMware y EMC.... y no sólo a nivel directivo. EMC reprocha a VMware que el éxito de la primera no redunde en incremento de ventas de la primera... o dicho en otras palabras, que el agnosticismo de VMware respecto a marcas de almacenamiento no esté ayudando a desplazar a la competencia de EMC... más específicamente a Network appliance. Por otro lado, EMC no puede negar que el éxito de VMware mantiene su cuenta de resultados en una envidiable posición.... sobre todo teniendo en cuenta los resultados de otras "aventuras" de EMC en el mundo del software. Ni siquiera EMC puede afirmar que poner a Legato y a Documentum bajo la marca madre haya sido una gran idea. Intentar forzar la entrada de EMC donde entra Legato o Documentum le ha costado algún disgusto a algún que otro director de división.

A mí, como cliente de VMware me molestaría bastante si mi Account Manager de VMware me viniese un día vendiéndome EMC... o NetApp, o IBM, o HP.... Por otro lado, VMware jamás me ha empujado hacia una marca, modelo o tecnología... cosa que le agradezco que no haga. De hecho, siempre han mantenido una postura de asepsia total. Como observador del mercado de la virtualización y consultor, creo que EMC debería aprender de errores pasados... abrir la gallina por conseguir más huevos de oro no es la solución.

jueves, 3 de mayo de 2007

Nuevo Link: Links a la documentación de VMware

lunes, 23 de abril de 2007

Nota Técnica: Usando Windows Server como servidor NFS para ESX

Me ha tocado implementar una nueva estructura VI3 en uno de nuestros clientes, y, dado que no disponemos por el momento de almacenamiento SAN, he decidido usar NFS para el despliegue de plantillas de máquinas virtuales, imágenes ISO y de repositorio central de parcheado de los tres ESX que conforman la infraestructura virtual.

He encontrado un how-to bastante simpático de como hacerlo, y dada mi natural vagancia, os lo dejo por aquí, eso sí, traducido.

Este how-to ha sido realizado por Jason Mattox, de Vizioncore.

Esta configuración en particular usa un servidor Windows como servidor NFS, mediante la instalación de los Windows Services for UNIX (WSFU). La siguiente url contiene información detallada de la autenticación NFS en el entorno de WSFU:http://www.microsoft.com/technet/interopmigration/unix/sfu/nfsauth.mspx

Nota importante: O bien habéis configurado la opción PermitRootLogin = yes en el /etc/ssh/sshd_config del VMware o tendréis que crear una cuenta en el ESX para acceder a estos por SSH.

Resumen del proceso:

Instalar Windows Services for Unix
Copiar el fichero de passwords y grupos de un servidor ESX al servidor NFS Windows
Configurar WSFU para que acepte las conexiones de los servidores ESX
Compartir la carpeta en el servidor Windows con soporte NFS
Configurar ESX para que monte los shares NFS de Windows como Datastores.

Instalar Windows Services for Unix
Primero, cómo no, nos lo descargamos de http://www.microsoft.com/windowsserversystem/sfu/downloads/default.mspx
Procedemos a instalarlo en el servidor Windows, configurando las siguientes opciones:

* NFS + Server for NFS
* Authentication tools for NFS + user name mapping

Tras la instalación, abriremos el panel de control de servicios, y cambiaremos el servicio llamado "User Name Mapping" para que arranque automáticamente. Tras esto, iniciaremos el servicio.
Copiar el fichero de passwords y grupos de un servidor ESX al servidor NFS Windows

Usaremos cualquier programa de copia SCP (Como el WinSCP) para copiar los siguientes ficheros al servidor NFS en Windows:
* /etc/password
* /etc/group
Debemos copiar estos ficheros en la carpeta donde hayamos instalado WSFU. podéis descargaros el WinSCP de http://winscp.net/eng/download.php#download2
Configurar WSFU para que acepte las conexiones de los servidores ESX

* Ir a Inicio, Programas, Windows Services for UNIX Administration
* Ir a User name mappings, seleccionar configuration

* Ir a password and group files. Aquí buscaremos los ficheros que hemos copiado antes medante el diálogo de busqueda de ficheros. Haremos lo propio tanto para el fichero de passwords como para el de grupos
* Aplicaremos los cambios.
* Seleccionar Maps e ir a show maps. Seleccionaremos List windows users and List Unix Users.
* Seleccionaremos un administrador local de la máquina Windows en la izquierda que será mapeado al usuario root en la derecha

* Aplicaremos los cambios (arriba a la derecha)

Como ejemplo utilizaremos el siguiente share: \\nfssrv.acme.com\NFS01
Compartir la carpeta en el servidor Windows con soporte NFS.

* Pulsaremos boton derecho sobre la carpeta que deseamos compartir por NFS.
* Seleccionaremos NFS Sharing. Asignaremos el nombre de la carpeta, en nuestro ejemplo, NFS01
* Eliminaremos la opción "allow anonymoys access"
* Iremos a "Permissions"
* Cambiaremos los permisos a "Read+Write"
* Activaremos "Allow root Access"

Configurar ESX para que monte los shares NFS de Windows como Datastores.

Abriremos el cliente de Virtual Center y seleccionaremos el host que va a acceder al servidor NFS.
* En la pestaña de configuración, seleccionaremos Networking, Add Networking y seleccionaremos un vSwitch que pueda acceder al servidor NFS. Añadiremos una conexión VMkernel con una IP que le permita acceder al servidor NFS.

* Seleccionaremos Storage, Add storage, Network File System

* en el campo destinado al servidor, pondremos el nombre o la IP del servidor NFS, p.e. nfssrv.acme.com
* en el campo "Folder", pondremos el nombre del share que hemos configurado antes, p.e. /NFS01

Aqui podéis ver el artículo original.

Espero que os sirva de ayuda.

Un saludo.

miércoles, 11 de abril de 2007

Nota técnica: Virtualización asistida por hardware.

Mucho se habla (y más se hablará) sobre las ventajas e inconvenientes de la Virtualización asistida por Hardware. Los dos contendientes en la Chip Wars, AMD e Intel incorporan en sus chips nuevos juegos de instrucciones que facilitan la virtualización. Por un lado, AMD con Su codename Pacifica, y por otro, Intel con Vanderpool.

Pero antes de hablar sobre estas tecnologías, veamos los tres grandes tipos de virtualización: Emulación, Paravirtualización y traducción binaria.

El método de virtualización con el que creo todos estamos más familiarizados es la emulación. Todos hemos ejecutado el emulador de nintendo, o el de pocket PC, por poner ejemplos. Y todos sabemos cual es su principal problema: La lentitud. El overhead de simular byte a byte un hardware por software hace trabajar a las CPU de manera considerable. El desarrollo de emuladores es una tarea ardua y propensa a errores.

En el otro extremo está la Paravirtualización. La paravirtualización (PV) parte de la base de que el sistema operativo huesped "sabe" perfectamente que está siendo ejecutado en un entorno virtual, y modifica su comportamiento de acuerdo con esto. Los sistemas operativos necesitan ser modificados para adaptarse a un entorno "hardware" virtual, lo que implica que hay una relación directa entre cómo se escribe el kernel del sistema operativo y cómo virtualiza la capa de virtualización. Realmente la Paravirtualización no es virtualización pura, sino más bien una colaboración entre la capa de virtualización y el sistema operativo virtualizado. Esto funciona bastante bien en entornos abiertos, donde el kernel del sistema operativo (como linux o BSD) puede ser modificado para tener en cuenta que "debajo" hay una capa de virtualización, pero en el caso de otros OS'es (como es el caso de Windows), la cosa no está tan clara. En este caso, hablar de rendimiento nativo es realmente relativo, ya que un OS's virtualizado no ejecuta exactamente el mismo código ni opera igual que si corriera en hardware real.

En el medio de estas dos opciones encontramos la, que hasta el momento, parece ser la mejor opción: La traducción binaria. La traducción binaria. La traducción binaria parte de la base de la existencia de un monitor de máquinas virtuales (VMM) que monitoriza a cada segundo las instrucciones que el sistema operativo huesped envía al procesador. Si el VMM detecta una instrucción problemática (que puede afectar al entorno de virtualización, otras VMM o a la estabilidad del hardware hospedador - host), rápidamente la reescribe (muchas veces convirtiendo una sola instrucción en docenas de ellas), y devuelve el resultado al huesped, que interpreta que esa instrucción original ha sido ejecutada. El resto de instrucciones no problemáticas son pasadas directamente al procesador.

Es evidente que reescribir instrucciones no es la manera más rápida de virtualizar, pero sí nos garantiza la ejecución de cualquier OS soportado SIN necesidad de reescribir el kernel del mismo. También abre la puerta a la virtualización de OS's que corren en hardware distinto al de nuestra plataforma base (en este caso, x86, x64, i64)... imaginad AIX corriendo en una VM... o incluso el Cisco IOS... porqué no?

¿porqué es necesario hacer todo esto?... pues básicamente porque la arquitectura x86 no es virtualizable. Entendamos un poco cómo funciona nuestro PC.

Existen, al menos, 4 niveles de privilegio de acceso al procesador, llamados anillos y numerados del 0 al 3, cuya prioridad es inversa a su numeración, aunque en la práctica, sólo se usan el 0 y el 3 (el de mayor y menor prioridad, respectivamente). Los sistemas operativos usan típicamente el anillo 0, mientras que los programas usan, también típicamente, el anillo 3. De hecho, las extensiones de 64 bits de los procesadores x64 sacrifican, en muchos casos, los anilos 1 y 2... No hay demasiada gente que se haya preocupado por ello (¿vosotros lo notáis?)... salvo aquellos que trabajan desarrollando capas de virtualización.

Es evidente que las capas de virtualización (VMware ESX, por ejemplo) se ejecutan en el anillo 0, y para poder mantener constantemente el control del sistema, han de mantener al OS huésped fuera de él. La solución más obvia es, entonces, ejecutarlo en el anillo 1 (por ejemplo). Esto sería una solución gloriosa si no fuera por esa manía de los sistemas operativos de ejecutarse en el anillo 0. En entornos de paravirtualización no hay problema: como el huésped colabora con la capa de virtualización, este puede decidir ejecutarse en anillo 1, por ejemplo, si la capa de virtualización así se lo indica. En la traducción binaria, hay que "obligar" o "engañar" al huesped para que se ejecute en el anillo 1. Esto tampoco parece complicado, salvo porque hay determinadas instrucciones no funcionan o lo hacen de modo extraño si no se ejecutan en el anillo 0 del procesador. La traducción binaria hace eso exactamente: Mentirle al sistema operativo huesped.

La virtualización asistida por hardware entra precisamente en este punto mediante el nuevo modo VMX. Por resumirlo de una manera sencilla (aunque no totalmente exacta), tanto Vanderpool como Pacifica permiten a la capa de virtualización ejecutarse en un "anillo -1", es decir, con mayor prioridad que el 0, de forma que ya no es necesario engañar al sistema operativo. El Virtual Machine Monitor se ejecuta en modo VMX root, mientras las VM se ejecutan en modo VMX. El procesador alterna entre universos mediante los procesos "VM entry" y "VM exit."

Las tecnologías VT permiten movernos (mediante VM entry y VM exit) entre el modo VMX y el VMX root, aislando a nivel de procesador, los universos del Virtual Machine Monitor (VMM) y de la máquina virtual (VM).

¿Maravilloso, No? Pues no... El trabajo de recordar que estaban haciendo el VMM y todas las VM no está implementado a nivel de procesador. El procesador provee mecanismos simples que facilitan al VMM la conservación de estados, pero el trabajo sucio sigue siendo del VMM.

Para quien le interese enterarse en profundidad de qué va todo esto, le recomiendo el siguiente link de donde, y si mi inglés no me ha abandonado, he sacado parte de la información que ofrece este post.

Ahora bien... ¿Vanderpool o Pacífica? Aunque el mecanismo es el mismo, las instrucciones, e incluso el modo de operación, varía. Pacifica parece ser un superset de Vanderpool, ofreciendo más mecanismos en el chip para facilitar la vida de los VMM. Estos comandos extras se agrupan en tres tecnologías propias de AMD, Nested Table Pages, Device Exclusion Vector y el Tagged TLB. Este documento os cuenta más extensamente que hacen estas tecnologías.

Que conste que Pacífica aún no tiene implementadas del todo estas tecnologías, por lo que lo que obtendréis al pagar un AMD con Pacífica es poco más que lo que os dá Vanderpool.

Como resumen, parece ser que Pacífica le pondrá más fácil las cosas a los VMM, mientras que Vanderpool sacrifica funciones en favor de la velocidad.

¿porqué tanto ruido con la virtualización asistida por hardware? Respuesta fácil: es la única manera en que un entorno Paravirtualizado (como Xen o Viridian) pueda ejecutar un sistema operativo sin modificar el kernel. Básicamente el procesador permite a un OS sin modificar instalarse en el anillo 0, dejando el -1 para el VMM. Evidentemente, esto a VMware le hace bastante poca gracia, dado que, en teoría, la traducción binaria ya no haría falta. Digo en teoría porque se me ocurren un par de cositas que la traducción binaria puede solucionar y que me dá a mi que tal y como se llevan Intel y AMD la virtualización asistida no:

Diferencia entre procesadores: el uso masivo de VT generará una mayor dificultad para el movimiento de VM entre diferentes modelos de procesador. Actualmente VMware "soporta" ligeros cambios de serie (Especialmente en Opterones y Xeones, donde los cambios en los micros suelen estar relacionados con el anillo 0, que se gestiona por Traducción Binaria y no por VT).
Compatibilidad: La traducción binaria extiende el campo de la virtualización a prácticamente cualquier micro x86 de 32 bits. VT la limita a la incorporación de esta tecnología.
VT es una tecnología emergente, aún saliendo del horno. Intel ya habla de VT v2, VT v3 y VT v4.... ¿Será la compatibilidad descendente una rémora de rendimiento tal y como lo fueron los 16 bits?
VT está siendo desarrollada por fabricantes de hardware, no por fabricantes de VMM... y teniendo en cuenta pasadas colaboraciones.... no sé yo que pensar.
VT limita la virtualización a plataformas x86.... La traducción binaria puede abrir nuevas puertas para la virtualización de otras plataformas.

¿Intereses creados? Todos. A favor: Microsoft el primero, porque si no se olvida de competir con VMware. Xen Enterprise, los segundos porque así pueden ejecutar Windows. Intel y AMD, los terceros, ya que la virtualización les quita "negocio", al menos algo recuperarán con lo que está por venir. En contra: VMware, que ve a la competencia meterse en su nicho privado, que era hasta ahora la ejecución de Windows en una VM.

Mi opinión: Que sobrevivan las dos. Hasta VMware puede sacar partido de VT.

¿Pero es tan realmente importante eso? Yo, personalmente, creo que no. No pienso que lo más importante en un entorno virtualizado sea en qué anillo se ejecute el OS, o la velocidad de ejecución de las máquinas virtuales. Creo que hay cosas más importantes que valorar: Estabilidad, snapshots, movilidad entre hosts, opciones de HA.... se me ocurren mil cosas que pedir antes de mayor o menor velocidad.

¿a vosotros no?

PD. Gura, espero que esto fuera lo que querías, camarada.

martes, 27 de marzo de 2007

Nota técnica: Problemas con el reloj bajo VMware

Uno de los incidentes más habituales y que trae de cabeza a más de uno viene dado por el reloj de las máquinas virtuales. Alguno de vosotros ya habréis observado que el reloj de cualquier sistema operativo que virtualicéis bajo VMware Server y/o ESX (a mí en Workstation no me ha pasado aún) es que el reloj de la VM parece ir más lento ( o más rápido). Este problema es especialmente acuciante en VM's bajo Linux.

En el entorno Windows, incluso en VM's dentro de un dominio (donde el DC hace de servidor de tiempo), podemos sorprendernos encontrando un desfase de horas entre nuestras VM y las máquinas físicas. El Knowlegde Base de VMware (accesible desde la página principal de VMware) ofrece distintas soluciones, aunque he de reconocer que la presentación es bastante confusa.

Como norma general, vengan las siguientes recomendaciones:

Utilizar una sola fuente de reloj: Es decir, si usáis ntp, desactivar el "Time sync" en las VMware Tools y viceversa.
No uséis al host VMware como time server: El COS (Console Operating System) no está pensado para esto, y la ejecución del algún proceso en él puede afectar al reloj.
En el caso de Linux, Los escenarios varían:

Si vuestro reloj se ralentiza bajo VI3, mirad este Link
Para el resto de los casos (reloj acelerado, otras plataformas), usad este otro

¿Quién dijo que sólo Microsoft tiene "particularidades" tontas?

Un saludo.

domingo, 11 de marzo de 2007

Certificaciones VMware.

Anay preguntó: "¿podrias poner aqui informacion clara (no como la de la web oficial) sobre titulaciones de vmware o virtualizacion en general y tu opion sobre ellas? Un saludo me encanta tu blog. "

La única certificación que conozco es la de VCP (VMware Certified Professional) y la obtienes pagando un impuesto revolucionario de 2.500€ más 200 de postre por el examen. ¿Utilidad? Si, en el C.V. queda muy bien. Y le permite a tu empresa (si es un integrador de tecnología), optar a ser VIP Enterprise Partner.. (básicamente mayor nivel de descuento con VMware y soporte técnico y comercial por parte de VMware).

Yo me la saqué en el 2005, cuando todavía VMware no comercializaba VI3. Mi certificación actual es sólo válida para ESX 2.5.x e inferiores. Este año debería actualizarme a VI3, lo que creo que me supondrá un curso de adaptación (que no pienso pagar de mi bolsillo) y el consecuente examen (más de lo mismo).

Espero haberte sido de ayuda.

Un saludo.

sábado, 13 de enero de 2007

Caso Práctico: Virtualización de entorno de Producción - Infraestructura Virtual

Pasadas las fiestas, turrones, pavos y similares, y el consecuente bebercio, parece que ya salgo de la resaca, así que al tajo.

Vamos a retomar el caso práctico que nos planteábamos en el post anterior, donde pretendíamos virtualizar parte de un entorno de producción. Tras la definición del ámbito del proyecto, pasemos a definir la infraestructura virtual necesaria.

Servidores físicos.

en el ejemplo que nos ocupa, se pretende virtualizar un total de 31 servidores. Hemos de tener en cuenta que todas estas máquinas dependerán de la integridad de los servidores ESX, con lo cual la tolerancia a fallos ha de ser una premisa del diseño de la instalación.

En el caso que nos ocupa, el planteamiento inicial implica la instalación de dos servidores ESX. Ese es un escenario económico y altamente rentable, que sacrifica rendimiento y tolerancia a fallos en pro de la economía. Intentaremos dibujar otros dos posibles escenarios, que balanceen mejor las prestaciones, la tolerancia a fallos y los costes.

Dos servidores, si... ¿Pero con qué configuración?

nº de procesadores.

VMware (y yo, basándome en la experiencia) recomienda no superar las 8 máquinas virtuales por procesador. Esto ha de tomarse como una norma general con múltiples excepciones: No es lo mismo 8 servidores SQL en cluster que 8 servidores web... de hecho, yo mismo he virtualizado hasta 13 servidores por CPU con rendimientos aceptables. También es importante definir los requerimientos de los entornos virtualizados: No tenemos porqué tener el mismo rendimiento en Desarrollo que en los sistemas de producción... y un RADIUS no requiere lo mismo que un SQL server.

En este caso, yo me inclinaría por servidores biprocesador con dual core, más que por sistemas tetraprocesador. VI3 es uno de los pocos entornos donde las ventajas del crecimiento horizontal son realmente palpables. Recordemos que VI3 nos permite hacer crecer nuestra infraestructura virtual añadiendo nuevas máquinas. Una instalación como la que nos ocupa puede comenzar con dos máquinas y crecer sin que por ello la inversión realizada inicialmente quede obsoleta.

Evidentemente, han de distribuirse los recursos de toda la infraestructura virtual de acuerdo con los requerimientos de cada servidor: Balancear entre distintas CPUs las máquinas con más carga (o requerimientos), un buen diseño de los pools de recursos, y un diseño adecuado de la infraestructura de almacenamiento.

Partiendo de esta base, las máquinas que nos ocupan deberían ir equipadas con dos procesadores dual core, lo que nos daría un total de 8 cores.

En el ejemplo que nos ocupa, nuestra infraestructura virtual soporta (teóricamente) hasta 64 máquinas virtuales (8 por core)... una estimación más realista, teniendo en cuenta que en caso de pérdida de servicio de uno de los servidores ESX (ya sea por incidencia o por trabajos planificados de mantenimiento), nos debería permitir mantener en funcionamiento, al menos, el cincuenta por ciento de los servidores virtuales. Una buena fórmula de cálculo deberia ser la siguiente: Nº de VM/8+(12) CPUs (El OR dependerá de la pasta que tengamos)

Memoria.

La respuesta es fácil: La máxima posible. ESX es, por definición, un gran consumidor de memoria. Apurar al máximo las capacidades de ahorro de memoria del VMware no es una buena idea en entornos de producción. Hemos de tener en cuenta que ESX, por muy maravilloso producto que sea, no es capaz de predecir las necesidades de memoria que una VM tendrá dentro de un segundo. Una buena fórmula de cálculo de la memoria total requerida para nuestra infraestructura virtual es asumir entre 768Mb y 1 Gb por máquina virtual.... lo que no quiere decir que definamos todas nuestras VM con 768Mb o 1 Gb de RAM. Hay un consumo "extra" de memoria por parte de la capa de virtualización... Calculemos aproximadamente entre 512 y 1Gb de consumo de RAM para el ESX.

Red.

La red es otro elemento fundamental en VI3. VI3 ha de suministrar conectividad de red a las máquinas virtuales que aloja, por lo que deberíamos garantizar tanto el ancho de banda como la tolerancia a fallos de la misma. LA red, tradicionalmente, suele ser una gran olvidada en los entornos de proceso de datos: Se compra, se instala y punto. Al ser uno de los sistemas más robustos de toda la infraestructura IT, suele relegarse a esa categoría de sistemas que "nunca fallan", asi que, consecuentemente, nunca se tocan.

VI3 requiere de electrónica de red eficiente, y una configuración adecuada. Mi personal consejo es tirar de electrónica de rendimiento contrastado y con potentes opciones de configuración. En mi caso, utilizo una pareja de Cisco Catalyst 3750.

En este ejemplo hemos de tener en cuenta las siguientes conexiones de red:

Red de VM

Dedicaremos, al menos, dos enlaces Gigabit por servidor ESX para el tráfico de las máquinas virtuales. Esta duplicidad no viene dada tanto por el ancho de banda como por tolerancia. Recordemos que, con 31 VMs en dos máquinas, cada tarjeta de red da servicio a 15 VMs.

Almacenamiento

Tanto si usamos iSCSI como FC, el enlace ha de estar redundado. Si existe algún componente crítico, este es el acceso al almacenamiento. Añadiremos otras dos conexiones para el almacenamiento. es importante que NO COMBINEMOS iSCSI y NFS sobre la misma red. Si pensamos en utilizar iSCSI y NFS a la vez, debemos utilizar interfaces distintas.

VMotion/HA

Aquí, dependiendo de si usamos VMotion, o VMotion y HA, podremos dedicar una o dos tarjetas por máquina. Si sólo utilizamos VMotion para el movimiento de VMs entre servidores, una tarjeta debería ser suficiente, pero si implementamos HA, este enlace se hace crítico.

Consola.

La conexión de consola es la que nos permitirá acceder a los servidores ESX tanto directamente como a través de VirtualCenter, con lo cual, su criticidad es relativa. Me explico. Si un ESX deja de ser gestionado por VC, no se para, lo que significa que no supone un impacto en la operatividad del sistema. En otras palabras, si cae la consola, tendremos tiempo de maldecir, ponernos la chaqueta, salir a por un cigarrillo y hasta tomar un café antes de ir al CPD porque las VM no se han parado. Yo no suelo dedicar una tarjeta específica para la consola, así que suelo añadir una VLAN, ya sea en VMotion o en las VM, para la consola, pero una interface de 100 Mbit/sec no parece a priori un desembolso excesivo, salvo que no tengamos splot PCI libres.

Como resumen, no escapamos con menos de 6 conexiones de red por servidor.... aunque 8 tampoco es un mal número.

Miscelánea.

Cosas interesantes que debería tener nuestro servidor ESX perfecto:

Consola remota: Si, lo de tener que ir al CPD es pelín incómodo, y además, podemos resfriarnos.
Remote Power On/Off: Más de lo mismo.
Disco de arranque en Mirror: Vaya que si nos gastamos una pasta en almacenamiento para VMFS y después los ESX no arrancan porque se nos ha cascado un disco nos va a lucir el pelo.

Almacenamiento.

Siempre he apostado por el uso de SAN para VMware. El uso de un almacenamiento compartido nos abre inmensas posibilidades bajo VI3: La capacidad de movimiento de máquinas virtuales entre ESX's, mayor racionalidad en el uso de almacenamiento, y el coste cada vez más bajo de este tipo de soluciones me parecen razones más que suficientes.

Pero no debemos olvidar la opción NFS que nos brinda ESX. NFS no nos va a dar, ni de lejos, el rendimiento de una SAN FC o iSCSI, pero se plantea como una solución económica para el almacenamiento de Templates, imágenes ISO, etc... y para eso podemos utilizar el espacio de nuestro servidor de ficheros Windows mediante productos gratuítos como el Windows Service for Unix, que nos permite compartir una carpeta de nuestro servidor de ficheros como un share NFS. Creedme... por muy grande que hayamos diseñado nuestra LUN para VMware, siempre, siempre, se nos quedará corta.

En mi caso particular, siempre he preferido iSCSI a FC, tanto por razones de coste como de sencillez y simplicidad de configuración. Una instalación FC requiere, además de las HBA FC (a un buen pico cada una, casi 2000€), hemos de tener en cuenta los switches (los minihubs que incorporan algunos fabricantes no son demasiada buena idea), el multipathing o capacidad para que un host vea una LUN por dos controladores FC y no las gestione como dos LUNS, o el trunking (agrupar dos o más canales FC para que actúen como uno solo) suelen tener un coste adicional. (de hecho, siempre he recomendado a los fabricantes de equipamiento FC que incorporen ya el lector de Visa en sus equipos, dado que para hacer casi cualquier cosa hace falta una licencia). También FC es más lioso de gestionar y configurar, y el conocimiento suele ser específico para cada equipo.

iSCSI ofrece menor rendimiento (unos 800-850 Mb/sec teóricos en enlace de un GbE frente a los 900-950 Mbit/sec de un enlace FC), consumen más recursos de la máquina en el caso de iniciadores software (es la CPU del host la que ha de pelearse con el TCP/IP y los comandos SCSI3), pero en una instalación pequeña (llamo pequeña hasta 6 - 10 servidores conectados a un target iSCSI) el diferencial de rendimiento no suele apreciarse.

Yo he realizado comparativas entre mis unidades FC (Una SUN StorEgde 3511, una MSA1000 de HP y una NetApp 3020) y la misma NetApp 3020 sirviendo iSCSI y las diferencias son inapreciables. No soy capaz de diferenciar rendimientos. Dado el coste de un NetApp, os recomiento una cosita que encontré el otro día: Openfiler una implementación Opensource del concepto de todo en uno: CIFS, NFS e iSCSI. Cualquier P4 con algo de memoria y bastante disco os permitirá implementar iSCSI en un entorno de preproducción, test o prueba de concepto. Sin embargo, para un despliege serio, os recomiendo que miréis las NetApp serie 200 (o la 3000 si os da) antes que amarraros a una solución FC pura. Yo tengo montada una 3020 que me dá almacenamiento iSCSI para VMware, servidor de Ficheros y un par de LUNs FC para SQL Server.... en la misma instalación... de hecho, la próxima inversión que haga en ella será ampliarla con disco SATA de alta capacidad para usarla también como backup a disco.

Por contra, el uso de Ethernet como medio de acceso al almacenamiento nos ofrece múltiples ventajas: Trunking de hasta 8 canales gigabit Ethernet, cifrado IPsec estándar, autenticación en base a usuario/password, VLAN's (frente a las zones FC, que son un infierno), y todos los mecanismos ya implementados sobre Ethernet: redundancia, autenticación en conexión (802.1x), y opciones avanzadas de monitorización como el sniffing.

Desde el punto de vista de costes y versatilidad, iSCSI también nos ofrece ventajas, al convertir cualquier puerto de red en un punto de acceso al almacenamiento en potencia. Además, el coste de un puerto ethernet de 1 Gbit/sec, incluso en equipos de gama alta, no llega a la mitad del coste final de un puerto FC.

Backup.

Algo que se suele tender a olvidar en los entornos VMware es que hay que sacar copias de las VM. Aquí tenemos dos posibles aproximaciones: Copia individual de cada máquina virtual, o copia total de la infraestructura virtual.

Evidentemente la segunda opción, el sacar una copia del VMfs donde tengamos almacenadas las VM puede parecer la mejor opción: Pocas LUN que copiar y un agente por servidor ESX, pero hay que tener en cuenta otro aspecto ciertamente importante.

Veritas, Legato y demás permiten la realización de copias diferenciales o incrementales, es decir, sólo copian los ficheros que han cambiado desde el último backup total o desde el último incremental realizado. Esto nos permite disminuir las ventanas de backup y ahorrar en disco. Si aplicamos esta filosofía a VMware nos encontraremos con la lindeza de que cada backup diario es, en realidad, un full backup. ¿Porqué? porque los discos virtuales, los vmdk son un fichero.... que cambia cada vez que el SO virtualizado está encendido. Así que el backup de, digamos, 600Gb de VMfs (no, no os asustéis, se llega con facilidad), nos obliga a disponer de .. 4.2Tb de espacio de backup.... por semana.

El uso de snapshots ("fotos" del disco que se pueden mantener a intervalos programables y que pueden ser revertidas), también puede parecer una hermosa solución... si no fuera por un par de detalles. En primer lugar, ningún sistema operativo trabaja directamente con el disco, así que si en un momento dado "congelamos" el disco, es probable que la mitad de los datos estén en la memoria del sistema operativo virtualizado y no en el disco. Esto es lo que se llama un punto de consistencia. Lo ideal sería poder decirle al SO que hiciese un flush antes de que nosotros ordenemos un snapshot del VMfs... es teóricamente posible (un buen sync bajo linux y alguna chapuza bajo windows).... pero ¿Y las aplicaciones?. Oracle o SQL server van por su lado. Un flush del sistema operativo no tiene porqué obligar a SQL, Oracle o Exchange (por poner ejemplos) a volcar todas las transacciones pendientes. Un snapshot en estas condiciones no vaticina nada bueno. Esto es lo que los gurús del backup llaman "Punto de consistencia", es decir, el estado de un servidor (aplicación incluída) en el que el backup es realmente una imagen consistente del sistema.

Para más INRI, algunas tecnologías de snapshot a nivel de LUN hacen cosas realmente graciosas: NetApp, por ejemplo, te "sugiere" reservar X * 2 espacio para el primer snapshot... siendo X el tamaño estimado de la LUN...

Cuando trabajaba con ESX 1.x y 2.x y se me apareción este problemilla, la única solución que se me ocurrió fué hacer un script que suspendiera una VM, sacara backup del disco y del fichero de suspensión (importante, de ahí la negrita), y volviese a hacer un power on.

Con VI3, VMware introduce el VMware Consolidated Backup. VCB permite el backup de las máquinas virtuales sin parada, de manera incremental y a nivel de fichero individual contenido en una VM. Se basa en la existencia de un Backup Proxy, un servidor Windows que accede a las LUNs de VMfs y es capaz de hacer un snapshot consistente de nuestras VM, que extraeremos con nuestro software de copias de seguridad preferido, es decir, sobre este servidor montaremos nuestro agente de Veritas, Legato o lo que tengamos, y VCB se encargará del resto. Esto es lo bonito. Lo feo es que requiere de unas configuraciones la mar de entretenidas, sólo funciona con FC y hay que hacer alguna pirindola para que se hable con el agente de backup. Por el momento estoy en fase de prueba del mismo, así que poco os puedo decir aún. Si antes de que termine con este caso práctico acabo la evaluación, incluiré la configuración... si no, ya tengo tema para otros post.

Licencias de VI3.

Tema importantillo... ¿qué licencia adquirir?. Veamos qué nos ofrece VMware.

Dejando aparte, oh cielos, opciones como el Consolidated Backup, nadie que conozca que haya probado vMotion es capaz de vivir sin él. Conozco casos de quién ha licenciado un VI3 standard, y a la hora de licenciar vMotion y demás, se ha llevado la grata sorpresa del latigazo consecuente que VMware ha tenido a bien darle. Para un entorno como el descrito, os recomiendo encarecidamente licenciar enterprise. VMware licencia por CPU física, lo que quiere decir que en nuestro caso, sólo hemos de licenciar 4 procesadores... para nuestra flamante instalación de 8... o de 16, con los quad de Intel en puertas.

Resumen de la instalación.

Servidores.

Dos máquinas dual core bi-procesador con 8 tarjetas de red, disco RAID, doble fuente de alimentación y 16 Gb de RAM.

Equipo Ejemplo.

Servidores: SUN X4100

Tarjeta de red: Intel® PRO/1000 GT Quad Port Server Adapter, Broadcom NetXtreme® Gigabit Ethernet Controller for Servers

iSCSI HBA's: Qlogic QLA4052

Nota: Ojito. El soporte para iSCSI HBA está todavía en fase experimental.

Almacenamiento.

Deberíamos disponer de, al menos, 600 Gb NETOS para nuestra instalación... mi consejo es que compréis algo que escale, al menos, hasta 3 veces esa cantidad.

iSCSI: NetApp FAS270c, NetApp FAS3000, para pruebas y/o preproducción o pequeños entornos, Openfiler, FalconSTOR IPStor, como prueba de concepto, StarWind iSCSI Target.

FC: Las anteriores junto con cualquier solución soportada por VMware.

NFS: NetApp, obviamente, o cualquier producto que sirva NFS... Microsoft Windows Services for Unix

Electrónica de red.

De los 48 puertos no deberíamos bajar, por aquello de no quedarnos cortos y no tener que empezar a "empalmar" switches con uplinks a giga. Si sois de los afortunados que ya tenéis un chasis mediano o grande (un Catalyst 4500, 6000 o un Nortel Passport o similar), provisionad puertos suficientes... si debéis adquirir electrónica, os recomiendo os vayáis a un chasis pequeño, o en su defecto a cualquier switch modular que soporte stacks de alta velocidad. Eso sí, procurad que tenga la opción de la fuente de alimentación rendundante.

Cisco Catalyst 3750-40 TS o superior... un backplane de, al menos 32 Gbit/sec.

Licencias VMware.

Licencia VI3 Enterprise para 4 Procesadores.

Seguiremos hablando.

J. L. Medina