Otros cuentan: Blades y Virtualización - O lo uno o lo otro.

Mis amigos de Virtualization.info nos hablan de un estudio de Gartner sobre esa manía que parece invadirnos de usar Blades como plataforma hardware para virtualizar. Por lo visto no soy el único que no está de acuerdo. El artículo completo aquí. Os recomiendo su lectura.

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.

Noticias: Evaluación de Virtual Iron - va a ser que no

Bueno... después de arreglar mi "morralla server", cogerme el manual de Virtual Iron y empezar a leerlo, descubro que:

- Es un Xen modificado
- sólo funciona (o eso dice) con procesadores que soporten virtualizanción (las extensiones de virtualización de Intel o AMD)
- No consigo que el sistema operativo que arranca en cada "Managed Node" (El ESX, para que nos entendamos) en VMware Workstation.
- Tampoco mi morralla server arranca el sistema operativo de virtualización.

Bueno... cuando me sobre un Opteron ultima generación o un Xeon top fashion igual vuelvo a probarlo.

Virtualización - Más ventajas

Hay un aspecto de toda tecnología que, como técnicos, tendemos a olvidar, y que, mal que nos pese, debemos tener en cuenta... el aspecto económico del tema, o dicho de otra manera, la cara que nos pone el señor que se sienta en un despacho que pone "director financiero" en la puerta. Creo que todos sabemos lo que cuesta conseguir el presupuesto para adquirir lo que consideramos necesario para nuestras instalaciones. Y también sabemos lo pronto que cambian los requerimientos del negocio con el tiempo: Donde dijimos diez servidores, seis meses más tarde nos faltan cinco, y ahí es donde empiezan las maravillas tecnológicas para conseguir meter las nuevas tropecientas funciones o servicios nuevos en los diez servidores existentes... y ahí empiezan los problemas de coexistencia de aplicaciones y/o servicios, dificultad de administración, etc.

Valga de ejemplo mi última adquisición: Decidí ampliar nuestra infraestructura virtual, así que adquirí un nuevo y flamante SUN x4100, con 16 Gb de RAM, 2 Opteron 285 dual core, dos discos SAS en mirror, seis interfaces de red, fuente de alimentación redundante, contrato de soporte "hardware only" junto con su correspondiente licencia de VI3 (Virtual Infrastructure 3) Edición Enterprise. El coste aproximado rondó los 14.000 euros. Teniendo en cuenta que la capacidad teórica de este servidor es de 32 máquinas virtuales (ocho por procesador), el coste por servidor virtual es inferior a los 450 €.... más o menos como el coste del contrato de soporte de 3 años para el x4100 antes nombrado. Incluso considerando extremo el límite teórico, y utilizando un máximo de 16 máquinas virtuales, el coste se aproxíma a los 900 €... por comparación, el servidor más económico basado en Opteron que comercializa SUN ronda los 1700€.

Evidentemente es posible pensar que un servidor real ofrece mayor rendimiento que uno virtual... pero yo me hago la siguiente pregunta... ¿Es necesaria la potencia de un procesador dedicado, medio giga de memoria y un RAID? Por supuesto que hay aplicaciones y servicios que lo requieran, pero... ¿Un servidor WSUS (Windows System Update Services) lo necesita? ¿y un servidor DHCP? ¿o el web server de monitorización? ¿Y el de distribución de antivirus? ¿O el SQL server de WSUS, Veritas, etc, etc? Creo que todos nos hemos visto ante esa duda existencial de decirnos "¿Porqué no puedo sacar memoria del servidor A y ponérsela al B?" sabiendo claramente la respuesta: Modelos incompatibles, fabricantes distintos, rotura de garantía... etc.

Otra de sus ventajas es, precisamente, la virtualidad del hardware virtual. Si al servidor ESX decidimos ampliarle, por ejemplo, el número de procesadores, las máquinas virtuales no necesitarán ser reconfiguradas. Incluso el cambio de procesador (de una versión a otra, por ejemplo), sólo requiere, salvo excepciones, pequeñas modificaciones en los archivos de configuración, modificaciones que la mayoría de las veces nos recomendará el propio VMware ESX.... Incluso, si disponemos de múltiples servidores ESX utilizando VMotion (ya hablaremos de VMotion), podemos mover las máquinas virtuales de un servidor a otro, parar el primero, actualizar, volver a encenderlo y mover de nuevo las máquinas virtuales a este. Queda claro que el hardware que utilicemos para ejecutar VMware tiene una vida útil mucho más larga, superando incluso la amortización de las máquinas (a cuatro años, normalmente). Incluso si compramos el Hardware por renting todo lo descrito permite la actualización del hardware de una manera más... suave y consecuentemente, sin impacto.

Teniendo en cuenta la bajada constante del precio del Hardware, VMware nos permite mantener los presupuestos de hardware equilibrados, ya que por el mismo dinero, año tras año, tendremos más prestaciones con las mismas máquinas, sin aumentar su número.

Con todos estos datos, nuestro financiero estará más contento, y nos pondrá algo menos difícil el obtener los anelados fondos.

Hasta la próxima.

J.

¿Qué es virtualizar? - Introducción

Virtualizar básicamente es eliminar el hierro (hardware) de una máquina o servidor y substituirlo por un software que lo emule, de forma que un sistema operativo pueda "hablar" con este hierro simulado o emulado como habla con el hierro real. La idea no debería resultarnos extraña, ya que, de hecho, hoy los sistemas operativos hablan con los drivers, que a su vez hablan con los firmware de los dispositivos que son los que realmente mueven el hard. Así que esto de software hablando con hardware a través de otro software no debería sonarnos a nuevo. El paso adelante dado por las estrategias de virtualización ha sido abstraer totalmente al driver del hardware, creando una capa de traducción entre lo que vé nuestro sistema operativo y el hardware que realmente hay debajo.

Pero un servidor no sólo es memoria, tarjeta gráfica o controladora SCSI: Un servidor también es fuente de alimentación, una caja metálica de una a varias unidades de rack, teclado, pantalla... y en otro orden de cosas, también es consumo eléctrico, conexiones de red, almacenamiento compartido, mantenimiento de drivers, instalación de sistema operativo, administración... y cómo no... costes.

Una de las cosas que yo siempre me he preguntado es, por ejemplo, cuánto ancho de banda puede manejar cómodamente un servidor Windows. El día que descubrí que a duras penas podía manejar picos de 400 Mb/sec, miré inmediatamente la última factura que representaba el coste de la última tarjeta de 10/100/1000 que le instalé al flamante Cisco Catalyst 6500 que tenía a mi espalda... dividí el coste por el número de puertos y descubrí que el hecho de que ese famante servidor que movía picos de 400 Mb segundo se conectase a Gigabit me estaba costando.... ¡¡¡ casi como el propio servidor !!!.... Cuando me dió por aplicar la misma fórmula al Fibre Channel, al coste de las baterías de la UPS, al precio de la unidad de rack que ocupaba y a la cuota de mantenimiento anual.... descubrí que el hecho de que un servidor hable con el mundo es casi tres veces más caro que el propio servidor.

También, y es interesante pensar en ello, Ni todo el disco, ni toda la memoria, ni todo el uso de procesador de un servidor están siendo usados constantemente... Y ni siquiera se justifican. Hoy te dá por poner un servidor DHCP en tu red, por ejemplo, y el juguete más pequeño que puedes comprar es un Pentium 4 a 2.8 Ghz con 1 Gb de RAM y 250Gb de disco duro... todo eso mientras miras a tu venerable servidor de base de datos, comprado hace tres años y que con su Xeon 3 a 900 Mhz aún sigue dando guerra.

Fué entonces cuando recibí la epifanía mística que terminó de convencerme sobre las bondades de la virtualización: las inversiones en hardware en servidor donde ejecutas el software de virtualización, se reparten equitativamente entre todas las máquinas virtuales. Por poner un ejemplo, dispongo de un servidor con cuatro vías, fuente redundante, 4 conexiones a gigabit, mirror para disco de arranque y almacenamiento SAN donde se ejecutan.... veinticuatro servidores, todos automáticamente equipados con las bondades en lo que a tolerancia de fallos se refiere, y un uso conjunto de red no superior a los 1.5Gb por segundo.


Aquí podéis ver de qué os hablo.

En lo que a rendimiento se refiere, es más que aceptable respecto a nuestras necesidades.

Este servidor es el último de los cuatro que tengo dedicados a virtualizar, donde ejecuto todo un entorno de desarrollo, un par de clusters (si, clusters) de base de datos (SQL 2000 y 2005), el servidor de distribución de antiviros, monitorización, aplicativo de helpdesk, entorno Microsoft Sharepoint, etc...

Bueno... seguiremos hablando.

J.

Empezamos, ¿no?

En primer lugar, presentarme y explicar mis motivos. Mi nombre es Jose y soy de esos viejos dinosaurios en esto de la tecnología, casi veinte años peleándome con un teclado. No os voy a aburrir con mi C.V., pero desde 1.999 (siglo pasado, impresiona, ¿eh?) soy usuario y fanático apóstol de la virtualización, especialmente con los productos de VMware. A principios del 2001, instalé de los primeros VMware ESX que se montaron en este nuestro país, en sitios de bastante importancia. Desde entonces, y a través de todas las empresas donde he trabajado, he aplicado, recomendado, implementado y explotado entornos VMware con total éxito. A estas alturas de siglo, me sigue sorprendiendo la poca penetración que la tecnología de VMware (y de otros, claro) tiene en los entornos de producción de España, y por otro lado, la ausencia casi total de información y casos de estudio de esta tecnología en castellano. Hoy, aunque desarrollo mi labor profesional en un cliente final (donde por supuesto he virtualizado hasta el infinito), sigo asesorando y realizando consultoría para antiguos clientes (y algunos nuevos) sobre múltiples aspectos de la tecnología, incluyendo la virtualización.

Espero que este intento de "españolizar" VMware sirva de ayuda a los lectores de este blog, y os anímo a participar con vuestras experiencias o consultas. Seguro que aprenderemos todos.

Un saludo.

J.