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.

Opinión: La última de Gartner: Windows se colapsa.

Describiendo su situación como "inmantenible" y describiendo a Windows como "a punto de colapsarse", un par de analistas de Gartner, Michael Silver y Neil MacDonald, le dicen a Microsoft que, o cambian radicalmente su sistema operativo, o se arriesgan a un rechazo por parte de sus clientes. Indican que Microsoft no está respondiendo a las expectativas del mercado, atada como etá a dos décadas de código "legacy" y de decisiones obsoletas, y que se encuentra con una fuerte competencia y oposición en un gran número de frentes, haciendo que el concepto actual de su sistema operativo sea debatible y cuestionable. Como resultado, resaltan ambos consultores, Microsoft es incapaz de crear nuevas versiones con cambios significativos en tiempos razonables. Según ellos, Vista es claro ejemplo de este problema, ya que tras cinco años de desarrollo, decidió usar el código, mucho más estable, de Windows 2003 como base de Vista. Esto justificaría, siempre según la opinión de Silver y MacDonald, que vista sólo ofrezca mejoras incrementales respecto a versiones anteriores, y que por esto el entorno corporativo no vea la necesidad de migrar. De hecho, otros analistas, entre los que se cuenta Forrester han hecho incapié que, al finales de 2007, sólo el 6.3% de los 50.000 ordenadores corporativos auditados estén trabajando en vista, lo que parece indicar que el usuario corporativo no ve una razón cara para migrar.

Dejando aparte el impacto o no en las cuentas de resultados, la lectura de este artículo me recordó una conferencia de Mendel Rosenblum, de VMware, donde se hacía la siguiente pregunta: ¿No serán los sistemas operativos demasiado complicados para lo que se les pide?. Yo, de último, también me hago esa reflexión: ¿Porqué tantas capas para ejecutar una base de datos? ¿O un servicio de correo?... ¿tantas capas y funcionalidades no hacen nuestros servidores más débiles?. Si esto lo uno a una conversación que tuve no hace mucho con un compañero, donde hablábamos de Infoblox, un vendedor de appliances DNS, el me decía "Si por mí fuera, montaba cuatro bind sobre un linux y listo" y yo le preguntaba "¿Porqué no lo haces?" Y el me respondió "Porque mi problema es el DNS, no el linux de abajo".

Ciertamente todos los sistemas operativos se han complicado. Incluso Linux se ha hecho cada vez más complejo, y consecuentemente su desarrollo se resiente (¿Cuánto tiempo llevamos con la 2.6? ¿Cuánto estuvimos con la 2.4? ¿Y con la 2.2?). También su mantenimiento, parcheos, alertas.... Si comparo el mantenimiento de un File Server bajo Windows y un Netapp, me doy cuenta que el parcheo de ese Windows es múltiple, incluyendo drivers y demás... y el de Network appliance tarda 10 minutos. Y entonces surge la pregunta, tonta aparentemente, de... ¿Y necesito tanto lío para una base de datos?... Pues parece que no. Hay múltiples vendors ofreciendo sus productos en modo Appliance virtual, donde te dan el soporte extremo a extremo... y parece ue venden.

¿Es tan descabellado pensar en appliances de Exchange? ¿o de SQL Server? ¿o incluso de Active Directory? ¿Máquinas que SOLO hagan una cosa pero que la hagan bien? ¿Máquinas que no dependan de tres departamentos y tres proveedores?

Os invito a esta reflexión.

Un saludo.

Opinión: VI 3.5... ¿Le falta un hervor?

No es un secreto que, tras casi cuatro meses de andadura, VI 3.5 se ha convertido en tema habitual de conversación en la blogosfera de la virtualización los "problemas" con los que nos hemos enfrentado todos aquellos que hemos migrado de la vieja y estable 3.x a la nueva versión 3.5. Un montón de pequeños pero irritantes fallos en las nuevas características, pero también en las viejas, nos hacen pensar a algunos que en la salida a mercado de VI 3.5 ha tenido más que ver el marketing (Hyper-V, Citrix & Oracle), que la excelencia técnica. Son conocidos los problemas del RCLI (Remote Command Line Interface), que casi parece un paso atrás respecto a 3.0, la ausencia de GUI para Storage vMotion y los fallos sin aparente razón del mismo. Virtual Center 2.5 ciertamente parece una beta: casi el 30% de las labores que se realizan terminan en algún momento un error, que no vuelve a aparecer si repetimos la acción. A vMotion, de vez en cuando, le da por comerse la CPU... por no hablar de los problemas con el servidor de licencias.... Incluso algún pajarito me ha contado que hasta el soporte de VMware se ha resentido, supongo que por el creciente número de consultas.

Los que me leéis habitualmente sabéis que no escondo que soy un defensor a ultranza de ESX y Virtual Infrastucture (hay quien me acusa de talibán), pero creo que hoy he, al menos, de callarme si alguien vuelve a recordarme el precio de VI3, y no podré decir lo que digo habitualmente: Pagas por calidad. Una vez tuve un service manager que me dijo algo que no olvidaré nunca "¿100% de disponibilida? ¡¡¡ Terrible...a partir de ahora no nos permitiréis ni un fallo !!!". El problema de poner el listón muy alto es que hay que manterlo así siempre.

Un saludo.

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.

Opinión: El hardware y VMware

Como os adelanté en un post anterior ando algo mosqueado con mis amigos de VMware y con los no tan amigos de SUN a cuenta del hardware de la serie M2 de mi amado SUN Fire X4100. Parece ser que los chicos de SUN han decidido que dos de sus cuatro tarjetas en placa sean de nVidia y por lo que he leído, ese chipset promete. Pero claro, no hay driver para VMware ESX. Eso no sería un problema si aquí un servidor no hubiera estado mirando los x4100 M2 para un megaproyecto en el que me tienen liado en el trabajo. Esta máquina ofrece en 1U todo lo que necesito en esta instalación (8 puertos GbitE y FiberChannel) a un precio de risa. Y de hecho, esa capacidad fué decisiva para descartar a otros fabricantes, como el caso de IBM o HP, que, en 1U, me ofrecían un máximo de 6 GbitE y dos FC. Consulto a VMware (a uno de mis infiltrados en tal excelsa empresa), y tras torturarle a base de múltiples y variadas copas, justo antes de caer en el delirium tremens, me confiesa que si, que no veas que p****a, y que lo soportarían antes de finales de año.... ¡¡¡ Finales de año para un driver !!!. Le preguntas a SUN, que tan comprometida dice estar con la virtualización y VMware, y te sueltan que sí, que vale, que mira que cosas, y que porqué no uso Solaris. Imagináos la cara que se me quedó.

Señores de VMware.... ¿tanto cuesta sacar un driver en modo "experimental"?
Señores de SUN... ¿Tanta diferencia de coste había en poner una Intel o una Broadcom?

Seguiré rumiando mi cabreo a solas....

Este problema de VMware se extiende a otros fabricantes y productos, como son las excelentes aceleradoras iSCSI de Alacritech, como la SES 2100 que supondría una gran mejora en el rendimiento de iSCSI de ESX.

A ponerse las pilas todos, que Viridian está cerca.

Saludos.

PD: Si alguien me dice que esto no me pasa con Virtual Server, le respondo que no sólo eso no me pasa con Virtual Server, sino además, las migraciones en caliente, DRS, HA de verdad, acceso concurrente a las luns, mapeo raw de dispositivos ni tampoco ratios de consolidación de 64:1.

Opinión: De dimes y diretes, de powerpoints y de comparar a dios con un gitano.

De último nuestra galaxia se vé convulsa por la guerra en ciernes, de la cual ya sufrimos alguna escaramuza, sobre quien virtualiza mejor, más rápido, y de paso quien la tiene más larga.

Por un lado, Microsoft con su Virtual Server 2005 R2 y su invisible Hypervisor sobre Longhorn (o como quieran llamarlo). Por otro, VMware con su VI3, por otro XenSource 3.x Enterprise... y tras estos, toda una corte de pretendientes buscando su pedazo de tarta en el suculento mercado de la Virtualización... (Virtuozzo, Paralells, VirtualBox, VirtualIron, etc)

Para darte cuenta de que la virtualización es el futuro del utility computing no hace falta trabajar en Gartner ni tener los números directos de los presidentes de las respectivas compañias. No pasará mucho tiempo antes de que los servidores virtuales sobrepasen a los físicos en número, y si no, tiempo al tiempo.

Como armas en estas batallas se emplean términos la mar de originales y especialmente sonoros: Hypervisor, Paravirtualización, Virtualización por Hardware, Hosted virtualization, baremetal.... etc... todo un conjunto de palabros que nadie tiene demasiado claro qué significan.

También, y si no preguntadle a San Google Bendito, patrón de los PowerPoint Users, la red se ha inundado de comparativas, tablas, blogs, comments, sobre qué tecnología es mejor, más rápida o tiene más futuro.

Y encima, a un seguro servidor de Uds., le han liado en esta guerra, por aquello de que uno tiene experiencia, en una especie de "MacroComité de expertos para el análisis y evaluación de soluciones de virtualización corporativa a gran escala", nombre chulo que no implica aumento de sueldo. Desde ese momento, ha habido bombardeo de comparativas, powerpoints, referencias y demás en mi correo.

Definido el escenario, vaya aquí mi opinión. VMware VI3 sería mi elección para los próximos dos años... y ahora os doy mis razones.

La primera es que si VMware me anunciase mañana un sistema operativo de 64 bits para, por ejemplo, motores de base de datos, respondería lo mismo. Mi elección hoy es Microsoft SQL server al menos para los próximos dos años. Sería arriesgado cambiar una opción con más de cinco años en bases de datos por otra que, por mucho que venga de una empresa solvente, está por salir.

Decidirte por una plataforma de virtualización no es fácil. Es un área de contienda relativamente nueva, donde sólo hay una opción establecida: VMware. El resto acaban de llegar... o están llegando (leáse Hypervisor de Microsoft). Lo de ser Beta User en algo de lo que depende la estabilidad de múltiples servidores dista mucho de ser divertido. Aún recuerdo las "travesuras" de VMware ESX 1.0. En su momento, no tuve alternativa (no había otra plataforma de virtualización) y pasaron 4 años hasta que, por fin, puse algo en producción dentro de un ESX. La verdad es que no veo necesidad ninguna de experimentar en producción con Longhorn, Xen, Virtuozzo, etc, cuando tengo ya una plataforma que a mi me parece fiable, potente y estable. Si, probaré en labs, y si algo me gusta de lo que veo, primero lo apuntaré en mi WishList para ESX x.x y le iré dando a lo nuevo algo de vidilla.

Quien pretende utilizar los benchmark como argumento le propongo el siguiente desafío: Poned vuestra base de datos crítica en un P4 overclockeado a 7,8 Ghz (lo han conseguido unos italianos)... ¿a que no se levantan muchas manos? Pues esa es mi postura ante los pretendidos benchmark de que tal tecnología es mejor que tal otra. Mis pruebas me dicen que las VM de ESX son más rápidas que las de la competencia, pero no es algo que me preocupe en demasía: Prefiero los uptime de meses en mis VM, que un winbench (por ejemplo). Yo es que no tengo ningún winbench en producción. Sólo SQLs, file servers, servidores web, etc.

Por el momento, mis comparativas se reducen a Xen contra ESX.... comparar Virtual Server con ESX es francamente injusto para Microsoft. Esperaré a Longhorn para hacerlas.

Cuidado con ser betatester... en producción. Conozco a algún betatester de SQL Server que tuvo que sufrir constantes problemas hasta SQL 2000 SP2. En especial si la virtualización es una necesidad para nosotros. No nos dejemos impresionar por acuerdos como el de Microsoft y Xen (vaya, que recuerdos me trae de otros acuerdos como el de IBM y Microsoft para OS/2), porque no son más que movimientos estratégicos de Microsoft contra su competencia.

Los murmullos no virtualizan. Powerpoint tampoco. Y prometer futuros Service Pack no hace más estable lo que tenemos.

Dos o tres años no son demasiado tiempo en términos de inversión. Podemos estar esos tres años observando al mercado para ver por donde respira. Pero "sufrir" durante tres años un producto nuevo no me parece una experiencia agradable.

Realidades. Con eso trabajamos.

Un saludo.

Opinión: ¿Sueñan las aplicaciones con servidores virtuales?

Sobre el comentario de Sauron a "Virtualizar: ¿Qué, Cómo, Cuándo y Dónde?". Siempre hay algo que no se puede virtualizar, al igual que siempre hay algo que requiere 4 procesadores y no funciona con dos. En un mundo perfecto, las aplicaciones .NET están bien diseñadas y los query SQL perfectamente estructurados, lo que nos permitiría - en ese mundo perfecto - virtualizar prácticamente todo. Pero el mundo en que vivimos está lleno de código .NET ineficiente, de querys SQL que hacen que nuestras 230 tablas de esa base de datos de 8 Gb se muevan todas al unísono en el mejor estilo lambada. En este mundo, muchas veces el código está como está, y no se puede cambiar (problemas insalvables de coste, tiempos o de simple ego del jefe del proyecto del desarrollo). En esos casos, virtualizar, como mínimo, sólo nos servirá para darle una excusa más al desarrollador para tachar nuestros sistemas de poco potentes. Recordad que, salvo honrosas excepciones, el dogma de muchos desarrolladores dice algo así como que la capacidad de proceso es infinita y la memoria también. Tened en cuenta que si algo vá lento en un flamante servidor físico, irá igual (o peor) en uno virtual. Si el servidor que aloja vuestro exchange tiene una cola de peticiones a disco de aquí a finisterre, virtualizarno tal cual está no va a arreglarlo. Si vuestro pontetísimo servidor de dos vías las tiene ambas al 100%, así seguirán cuando lo hayáis virtualizado. Si vuestro SQL server se come los 4 Gb de RAM del servidor donde se encuentra ahora, se los seguirá comiendo. Virtualizar reduce costes y mantenimiento... los milagros, para la wish list de ESX 10.0

Yo he visto cosas que vosotros no creeríais. Aplicaciones multiusuario con bases de datos multigiga puestas en Access más allá de Orión. He visto a desarrolladores .NET afirmar que un doble opteron con 8 GB de RAM es poca máquina para una base de datos SQL de más de 4 Gb cerca de la puerta de Tannhäuser. Todos esos momentos se perderán en el tiempo, como lágrimas en la lluvia. Hay que pensarse tranquilamente lo de virtualizar. Nada como una buena evaluación de rendimiento de las aplicaciones a virtualizar antes de virtualizarlas. Herramientas no faltan: Analizadores de queries para SQL, profilers .NET, optimizadores para Exchange, etc.

Un saludo.