Virtualizar: ¿Qué, Cómo, Cuándo y Dónde?

Bueno, aparte del anónimo post sobre qué virtualizar y sobre qué, llevo una semana de disquisiciones filosóficas con compañeros y partners sobre este tema, así que voy a exponer mi opinión. (Por cierto, a los anónimos, dejad un correo o similar)

¿Qué virtualizar?
Creo que no es la pregunta adecuada: La virtualización no se aplica a productos, sino a entornos. Virtualizar un servidor web puede parecer una buena idea, pero si ese servidor es justo donde se ejecuta la aplicación .NET que no admite balanceo y tiene 2.500 usuarios, la idea deja de ser buena. Lo mismo aplicamos a Exchange, SQL server, Oracles, etc. Una vez monté un lab donde teníamos un Lotus Notes virtualizado en el que simulábamos una carga de trabajo de 250.000 mensajes por hora. Lo tuvimos en funcionamiento cinco días, lo que dá un total de treinta millones de mensajes procesados. ¿Pondría yo un servidor de producción con esa carga en VI3?... pues a lo mejor si, pero previo desdoblaje del mismo en dos o tres VM, y balanceando carga. Respecto a Exchange... digo lo mismo. Si en nuestra instalación tenemos un sólo exchange haciendo de client access y de store, puer si, virtualizo, pero desdoblando funciones. Quizá montaría un Exchange para OWA, un SMTP y quizá un par de stores. ¿Tendrá más rendimiento? No necesariamente. ¿Funcionará mejor? Vamos... yo creo que sí. Si al servidor de storage groups le quitas el proceso adicional de cargar con clientes, es obvio que debería ir mejor.

Respecto a los DC... he escuchado de todo... desde que las diferencias de reloj producidas por la virtualización (¿?) afectan al dominio, hasta que las VM no dan potencia suficiente para un DC (más ¿?). Conozco directorios activos completamente virtualizados, y no por ello son menos eficientes. No sé porqué, pero veo la mano oculta de Microsoft cuando no tenía producto con el que competir en la propagación de estos rumores. Y puestos a rumorear, hay quien dice y afirma que Microsoft utiliza VMware ESX en sus departamentos de desarrollo....

La conclusión es que la cuestión no gira alrededor de la virtualización, sino del balanceo de carga de funciones sobre una determinada infraestructura.

¿Dónde virtualizar?
Parece que está de moda usar blades para ESX. Y yo, para no variar, no estoy demasiado de acuerdo. No me parece demasiado lógico utilizar un hardware que comparte I/O entre múltiples servidores para un sistema operativo que necesita un control exhaustivo del hardware para ofrecérselo a las máquinas virtuales. Se me ocurren unas cuantas razones para no pensar en blades para soportar VI3.

Versatibilidad.
El hecho de que la ampliación de un sistema dependa hasta en el menor de los aspectos de un determinado fabricante me hace recordar otros tiempos, y me plantea escenarios donde ESX soporte determinado hardware que el fabricante aún no haya (o haya decidido) no implementar. En estos momentos, donde VI3 aún tiene que mejorar cosas como el soporte iSCSI, atarse a un fabricante de blades que puede o no implementar HBA iSCSI o adaptadores TOE con soporte iSCSI (véase Alacritech), decidirse por una arquitectura absolutamente propietaria (como cualquier host IBM o SUN) me parece arriesgado. Por otra parte, el hardware de conectividad de los blades sigue siendo algo especialito. De acuerdo, hay fabricantes que incorporan switches ethernet y fibre channel de fabricantes reconocidos, pero... ¿os habéis pasado por las páginas de descarga de Cisco o Brocade? Esas "versiones específicas" siempre son pelín distintas... y no dejan de preocuparme esas "pequeñas diferencias" cuando hablo de ESX...

Rendimiento.
Otro tema es el rendimiento. Aún espero que algún integrador comprometido con los blades (no nombraré a nadie) me demuestre que, a igual configuración hardware, el blade dá el mismo rendimiento y escalabilidad (aspectos fundamentales en ESX) que una máquina independiente.

Impactos en el servicio.
Otro aspecto que me preocupa son los impactos en el servicio. Imaginemos que, en un cajón, hemos de actualizar el firmware del chasis, o el del módulo de switch giga que nos dá conectividad: Hay que parar de un tirón catorce máquinas.... Creo que con los problemas que me dá el tener que parar la SAN cuando tengo que hacer lo mismo ya tengo bastante.

Costes.
Pues no, tampoco me parecen tan baratos. Si, efectivamente, el coste del blade es sensiblemente inferior a la máquina de 1 U.... hasta que empiezas a sumar las fuentes adicionales, el dobre switch blade ethernet (¿o no tienen nuestras pizzas de 1 U múltiples puertos ethernet que conectamos a donde queremos?) El doble switch Fiberchannel.... creo que al final no salen tan baratos.

Entonces... ¿Porqué nos los ofrecen?
Razones no faltan. Al fabricante le interesan porque sus costes de soporte son inferiores, al integrador le interesan porque los fabricantes incentivan al canal para que los venda, e indiscutiblemente, hay quien los compra porque efectivamente, hay escenarios donde ofrecen ventajas indiscutibles.

Conclusión.
He instalado blades a lo largo de mi vida profesional: Granjas de servidores web, Granjas Citrix, aplicaciones ASP y .NET... y efectivamente para estas cosas tienen su aquel, pero en lo reference a ESX, sigo prefiriendo servidores independientes, y os recomiendo lo mismo.

Un saludo.