sábado, 10 de marzo de 2007

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.

7 comentarios:

Bebbop dijo...

Es decir, que no hay nada en concreto todo va relacionado con la carga del servicio que quieras virtualizar. Supongo que hay servicios que no se pueden virtualizar dependiendo de ciertos parametros, acceso a disco, transacciones, usuarios concurrentes, etc. Aunque el ejemplo del Notes ya dice mucho de por si.

La verdad es que he visto de todos los colores y tipos... he visto Dc's en produccion y virtualizado en VMWare Server y claro... de funcionar pues funcionan correctamente ¿porque no deberia funcionar?

Hace unos 3 o 4 años Microsoft tenia las maquinas virtuales de desarrollo en VMWare, eso es cierto, ahora supongo que las debera tener en su producto de virtualizacion.

Soy el anonimo del otro post :P

J. L. Medina dijo...

Un DC es una máquina delicada. Yo no me arriesgaría a virtualizar toda mi estructura AD en VMware Server. Otra cosa es ESX. ¿Porqué? Básicamente porque en ESX puedo asignar recursos para garantizar que el/los DC funcionarán como deben.

Un saludo.

kurrin dijo...

Buenos dias, lo primero de todo gracias por este blog. Esta muy bien.
Ya que hablais de ADs etc, me estoy planteando virtualizar un servicio (LDAP: Openldap con syncrepl) que necesita una precision en su reloj muy alta entre varias maquinas virtuales linux. Por el momento no encuentro la forma de que no se me desfasen(estoy hablando de minutos, no ya de milisegundos). ¿Cómo puedo configurar dos VM en dos ESX (una en cada uno) y que no este desfasadas? Los ESX se sirven de un servidor de tiempos (como los demas servidores) y las VMs estan configuradas en las vmwaretools para que se sincronicen con el ESX, pero ni con esas.
¿Existe algun remedio para este problema? jonblazquez arroba gmail punto com

J. L. Medina dijo...

Vaya... time sync issues... dame algún dato más: Qué linux corren los guest, qué versión de ESX, que hardware tienen los ESX, etc. Si, hay algunos problemillas con el time en las VM. Espero tu respuesta.

Anónimo dijo...

Pues he empazado a leer este articulo, pero me he desinflado un poco con lo del servidor web de .net que no se podia balancear :-?.

Hay gente que virtualiza los DC otros que no, para mi gusto nunca virtualizaria los DC claves pero prefiero virtualizar otros DCs, sobre todo antes que verlos con otros usos como IIS, SQL, Etc.

Anónimo dijo...

Buenos días, concreto un poco mas mi comentario del tiempo en VM y de su reloj de goma(a mi me recuerda a la teoria de la relatividad): Los guest son todos Linux RedHat Advced Server 4 (Update 2 ó 4) y los ESX son los 3.0.1. El Hw de los ESX es diverso pero ocurre en todos: Tenemos desde blades HS20(IBM) para el centro de respaldo(sí yo tampoco lo veo mucho para vmware, usar vmxnet_console para VMotion?ummmm, de hecho ahora para produccion me lo estoy pensando muy mucho pero no sé...) y los de produccion son IBMs 346 biprocesadores(no dualcore). Los guests tienen instalada las vmwaretools. La verdad es que intente lo que intente se me desfasan... gracias por la ayuda!

Tomas Garijo dijo...

Hola a todos,
En cuestion de software de sistemas...
Yo tengo VM con linux, windows 2008 y window 2003, sobre XenSever.

El hardware es HP, con conbinas san sobre fibra.

Os puedo decir que con referencia a lo que tenia (tenia todos los servicios en servidores diferetes, Exchange, sqlServer, AD, apache, tomcat, apache server, mysql, etc, etc) no tenemos caidas, hay servidores que tienen 340 dias sin rebotarse, a excepcion de cuando hay que bajar los sistemas por aplicacion de parches. El rendimiento es mayor y max eficiente, y el consumo energetico se ha reducido en un 60%. En nuestro caso todo han sido ventajas.

Saludos