Be virtual, My friend

Nota Técnica: VMware View Open Client

noreply@blogger.com (J. L. Medina) — Mon, 26 Oct 2009 11:43:00 +0000

Como supongo que sabéis, VMware ha "liberado" hace ya un tiempo el cliente View (o VDM) para Linux, lo que permite tanto a los forofos y/o usuarios de este sistema operativo como a los fabricantes de Thin Clients acceder a los entornos View desde este sistema operativo.

Entrecomillo "liberar" ya que el cliente en cuestión tiene ciertas peculiaridades, que destaco:

No soporta redirección USB. En la distribución estándar del cliente "faltan" los componentes de la redirección de dispositivos USB, que entiendo que requerirán de licencia OEM al efecto.
Es pelín exclusivo: No tenemos control sobre la ventana del desktop virtual, ya sea para cambiar el tamaño o alternarla con el deskop físico.
Presenta algunos "problemillas" con el teclado: Tiene como buena "costumbre" obligarnos a usar el teclado US en lugar del que tengamos configurado.

Dado que de último uso Ubuntu en mi flamante Sony Vaio VGN-P11z (el vista que trae de serie hace desesperadamente lento al cacharro en cuestión, y Windows 7 no mejoró mucho las expectativas de rendimiento me decidí a "Ubuntear" el portátil, ya que todo mi entorno de trabajo se encuentra en el desktop virtual) el uso del cliente View se volvió necesario, así que me decidí a intentar superar las limitaciones antes expuestas, al menos las concernientes al desktop.

El VMware View Open Client, al igual que su contrapartida en Windows, requiere de un cliente de terminal server previamente instalado en el equipo, en el caso de Linux, rdesktop, así que me dediqué a investigar cómo el cliente View interacciona con rdesktop. Para ello, procedí a realizar lo siguiente:

1. Renombré el binario de rdesktop, localizado en /usr/bin/rdesktop a /usr/bin/rdesktop.bin:

# mv /usr/bin/rdesktop /usr/bin/rdesktop.bin

2. Creé un archivo /usr/bin/rdesktop.wrapper con el siguiente contenido:

#!/bin/bash
echo $* > $HOME/rdesktop.parms
/usr/bin/rdesktop.bin $*

en $* el shell nos suministrará la línea de comandos que View Client le pasa a rdesktop

3. Hice un link simbólico entre el archivo rdesktop.wrapper y rdesktop:

# ln -s /usr/bin/rdesktop.wrapper /usr/bin/rdesktop

Tras lo cual, ejecuté el cliente de vmware view (vmware-view).

Tras conectarme, procedí a examinar el contenido del fichero $HOME/rdesktop.parms, encontrando lo siguiente:

-z -K -g 1280x1024 -X 65012445 -u jlmedina -d bato-its -p - -a 24 -r sound:local :3389 10.0.10.18

Si consultamos las opciones de rdesktop (via man rdesktop) observamos lo siguiente:

-z: Activar compresión RDP

-K: No anular las asignaciones de teclas del Window Manager. Por defecto (es decir, sin esta opción activada) rdesktop intercepta todas las pulsaciones. Esta opción es la que nos impide minimizar la ventana del virtual desktop mediante la pulsación de ctrl+alt+enter

-g: Resolución de la ventana de virtual desktop. Por defecto, VDM ocupa toda la pantalla disponible.

-X: Ejecuta rdesktop dentro de una ventana existente. El comportamiento por defecto de VDM es ejecutar la ventana de rdesktop sobre una ventana invisible que no es minimizable.

-u : Usuario con el que conectarse

-d: Dominio al que pertenece el usuario

-p: password suministrada al cliente VDM

-a: Profundidad de color. Por defecto, VDM utiliza el máximo soportado por VDM, que es 24 bits.

-r: Dispositivos redirigidos. Por defecto, sólo el sonido

el resto corresponde a la IP y puerto del desktop a conectarse.

Por lo pronto, las opciones que parecen "molestarnos", es decir, la de no poder salir de la ventana del Virtual Desktop, son las siguientes:

-K, es decir, la que nos desactiva el ctrl+alt+enter

-X, que ejecuta el rdesktop en una ventana no "resizable".

Si nos limitamos a eliminar estas dos opciones, nos encontraremos con los siguientes "problemillas":

El teclado seguirá estando en inglés EEUU
El virtual desktop se presentará por defecto en modo ventana

Para solucionarlo, deberíamos pasar a rdesktop los siguientes parámetros:

-f: Activa el modo full sreen
-k es: configura el teclado por defecto a español.

Ahora bien... ¿Cómo eliminar opciones y añadirlas a los parámetros que el cliente view pasa a rdesktop?

Como antes dijimos, la variable $* almacena los parámetros que vmware-view pasa a rdesktop, así que aprovecharemos esto para eliminar los parámetros que nos molestan y añadir los que nos faltan. Para ello, volvamos a mi fichero rdesktop.wrapper:

#!/bin/bash

echo $* > $HOME/rdesktop.parms

/usr/bin/rdesktop.bin $*

lo modificaremos para que quede como sigue:

#!/bin/sh

parms=`echo $* awk '{print $1,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17}'`

/usr/bin/rdesktop.bin -k es -f $parms

Básicamente lo que he hecho es, mediante el comando awk, eliminar de la línea de parámetros los que me molestan, y después añadir "a pelo" los que necesito. En este caso, eliminaría los que destaco en rojo:

-z -K -g 1280x1024 -X 65012445 -u -d -p - -a 24 -r sound:local:3389

De esta manera conseguiremos un cliente view funcionando en pantalla completa, que nos permite volver al desktop pulsando ctrl+alt+enter y con teclado en castellano(*)

Espero que os sea útil.

(*) Es posible pasar a rdesktop el código de teclado mediante variable de entorno, pero lamento reconocer que no lo conseguí.

VMworld 2009

noreply@blogger.com (J. L. Medina) — Fri, 28 Aug 2009 06:52:00 +0000

Como ya os adelanté, tenía previsto asistir al VMworld 2009 en San Francisco, aprovechando la invitación de TechTarget para formar parte del tribunal que juzgará los VMworld Awards 2009, pero circunstancias imprevistas de indole familiar me lo impiden. Otro año será.

Un saludo.

J. L. Medina.

Más sobre VDI

noreply@blogger.com (J. L. Medina) — Thu, 27 Aug 2009 13:19:00 +0000

Visto que esto de actualizar el blog siempre requiere un tiempo que no tengo, y como compensación, os dejo un "Whitepaper" que he realizado sobre el tema de los desktops virtuales titulado Virtual Desktop: El futuro de la informática de usuario corporativa, que es lo que me tiene ocupado de último. Espero que os resulte de interés.

Virtual Desktop: El futuro de la informática corporativa de usuario

View more documents from jlmedinan.

Un saludo.

Actualización: Licencia del documento.

Debido a varias consultas al respecto, he decidido ponerlo bajo licencia Creative Commons, según se detalla a continuación:

Virtual Desktop: El futuro de la informática de usuario corporativa by José Luis Medina is licensed under a Creative Commons Reconocimiento-Compartir bajo la misma licencia 3.0 Unported License.
Based on a work at bevirtual.blogspot.com.

View 3.10 y SUN Rays

noreply@blogger.com (J. L. Medina) — Fri, 07 Aug 2009 06:59:00 +0000

Reconozco que para los entornos VDI tengo debilidad por los clientes ligeros. De hecho, cuanto más ligeros (es decir, cuanta menos inteligencia tengan dentro) más atractivos me resultan.

El cliente más ligero que he encontrado hasta el momento son los de la serie SUN Ray de SUN Microsystems. Es lo más parecido a un terminal VT100 (seguro que alguno os acordáis) o a un terminal X que conozco. Los terminales SUN Ray no ejecutan más que un cliente ALP (Appliance Link Protocol) que les conecta al servidor de gestión de los mismos (normalmente un SO Solaris o Linux) que es donde ejecutaremos el entorno que queramos. Sun Ray nació como alternativa de alto rendimiento a X como protocolo de display remoto, pero ya sea por una equivocada comercialización, o por falta de aceptación del mercado, nunca triunfaron demasiado.

Pero es en el entorno VDI donde creo que pueden mostrar todo su poder, precisamente por la falta de inteligencia del elemento situado sobre la mesa del usuario.... no es más que una extensión del monitor, ratón teclado, puerto USB y/o serie del host al que se conecta. Empecemos describiendo la arquitectura de la solución:

- SUN RAY Terminal: Dispositivo de usuario al que conectamos pantalla, ratón y monitor.
- SUN Ray Server: Servidor central que suministra las sesiones y el acceso del SUN Ray Terminal
- VMware View Server: Borker de conexiones de VMware a los Virtual Desktop
- Virtual Center + ESX Server: Infraestructura virtual que soporta los virtual desktop.

¿Cómo funciona todo esto?

Bien. Tal y como hemos dicho, el terminal SUN Ray no dispone de más inteligencia que la que tiene un terminal "tonto" de los de antes. No dispone de Sistema Operativo, Cliente RDP o cualquier otra cosa que nos permita conectarnos a cualquier sistema. Los que conozcáis los terminales Wyse o HP sabréis que estos disponen de cliente RDP, ICA y demás. Estos no. Lo único que hacen al iniciarse es buscar un SUN Ray Server al que conectarse.

Una vez localizado, el SUN Ray server asigna (de manera más o menos oculta) una sesión del Solaris o Linux que tenga instalado.

En una instalación básica de SUN Ray Server, simplemente nos mostrará un Desktop. Aquí es donde empieza toda la adaptación.

Además del SUN ray Server, debemos tener instalados los siguientes componentes del software de SUN Ray:

- SUN ray Conector for Windows: No es más que una implementación del cliente RDP para este entorno:
- SUN Ray Conector for VMware VDM: Es la interface que permite acceder a la pantalla del Login de VMware View.

Es importante señalar que, por el momento, no es posible configurar el SUN Ray server para que se establezca la conexión con el desktop virtual a través del broker. De hecho, VMware View ha de configurarse en modo "Conexión Directa" para que todo este "invento" funcione.

Una vez instalado todo lo anterior, hemos de configurar el servidor SUN Ray en modo "Kiosk". Este modo evita que cuando conectemos la estación SUN Ray el solaris o el linux del servidor nos muestre la pantalla de login y password típica de Unix. Este modo "autologuea" a la SUN Ray y le permite ejecutar cualquier "plugin" o "conector" (vease los requerimientos) de manera transparente. En el caso que nos ocupa, configuraremos el modo kiosco para que utilice el conector VDM.

Como paso intermedio, es necesario instalar en el Solaris/Linux el certificado de VDM... sin él no conectaremos con el broker.

Tras esto, y si nada ha salido mal, deberíamos poder encender nuestra SUN ray y acceder a nuestros Virtual Desktop.

Esta solución es la que hemos elegido en Bató para los PC de la Oficina. Comparados con otros terminales de bajo/medio coste, la velocidad de presentación es sensiblemente superior (hasta un 20%) y nos ofrecen una serie de ventajas que nosotros consideramos fundamentales:

- Si cerramos la sesión en un terminal y nos vamos a otro, volvemos a estar donde estábamos.
- Instalarlos no requiere más que sacarlos de la caja y conectarlos.... y sin preocuparse por el nivel de firmware... tan pronto lo conectas, se actualiza.

- La velocidad de presentación del video en pantalla es lo suficientemente buena para que nuestro financiero no se queje de lo mal que va youtube!!!

Si alguien quiere probarlos y necesita una mano más técnica, que no dude en contactarme.

Un saludo

VMworld'09

noreply@blogger.com (J. L. Medina) — Wed, 29 Jul 2009 10:33:00 +0000

Hasta el momento, nunca había planeado asistir a un VMworld... básicamente por aquello de las veintitantas horas de avión... pero este año, la gente de Techtarget me ha invitado a formar parte del tribunal que otorga los VMworld Awards... y no supe/pude decir que no... así que el 30 de agosto estaré en San Francisco en el VMworld, actuando de juez, y, porqué no, disfrutando de unas cervezas con los vExpert del otro lado del charco.

Os iré contando.

vSphere 4.0: Mis razones para... (I)

noreply@blogger.com (J. L. Medina) — Tue, 19 May 2009 03:59:00 +0000

Con este post que tenía a medio hacer hace bastante tiempo comienzo una serie (que prometo terminar) sobre mi particular percepción respecto a vSphere 4.0. Como remarco en el título, lo aquí recogido es mi opinión personal (y por tanto profesional) sobre vSphere 4.0. Los lectores de este blog (si aún me queda alguno después de mi dejadez) son libres de estar o no de acuerdo, y espero que ejerzan esta libertad opinando al respecto. Empecemos:

... No implementar VMware FT en producción:

Sí, leeis bien. Todo un vExpert desaconsejando VMware FT en producción. Como muchos sabéis, Vmware FT permite la ejecución en simultáneo de dos máquinas virtuales haciendo exactamente lo mismo, es decir, una actúa como sombra de la otra en otro host distinto. A priori esto suena bien: si cae un host, la VM sobreviviente recoge la carga de la primera sin impacto para los usuarios. La pregunta es si merece asumir las limitaciones que impone FT para evitar 30 segundos de pérdida de servicio. Mi respuesta es que depende. FT no te va a proteger de una corrupción de datos, ni de la pérdida de los mismos. Si el servicio que nos interesa se cae en la VM primaria, también se caerá en la máquina "shadow". FT no garantiza más que la operación de una VM (ojo que digo VM, no servicio) en caso de caída del host que la aloja. No con esto quiero quitar méritos a FT: Como obra de ingeniería es impresionante. Como medida de continuidad del servicio no deja de ser un paso más. FT puede transmitir la falsa sensación de que se ha elevado el nivel de servicio, y quizá en algunos casos lo haga, haciendo que el responsable de sistemas baje la guardia. No creo que por el momento implemente FT en bases de datos críticas o servidores de correo: La penalización de una única CPU y el desaprovechamiento del nodo donde se ejecuta la VM "espejo" no compensan, al menos, por el momento. Nada como una buena replicación de log de transacciones en una base de datos, a ser posible diferido, como para garantizar la disponibilidad.

... Implementar los vNetwork Distributed switchs: Bonding, load balancing, MACs, etc... Demasiados términos que suenan propios de los chicos de networking. Los distributed switches (en especial el Nexus 1000v de Cisco) acercan a los responsables de networking a un área de la virtualización que, hasta ahora, consideraban extraña: los switches virtuales. Con los Distributed Switches el networking virtual es, por fin, networking, y puede caer en las manos de quien mejor lo controla: La gente de red. Para bien o para mal la virtualización ha caido en la parte de sistemas, olvidando que una parte fundamental del entorno virtual es la red. Ahora este aspecto del entorno virtual se vuelve amigable para los chicos de la red.

... Implementar DPM (si deja de ser experimental): En grandes proyectos de virtualización, el consumo eléctrico tiene su peso. Si a las ventajas inherentes a eliminar toneladas de hierro le añadimos que el hierro con el que virtualizamos también consume lo justo... miel sobre hojuelas.

Paro por el momento.

Un saludo.

Para Javier.

noreply@blogger.com (J. L. Medina) — Tue, 19 May 2009 02:17:00 +0000

No hace mucho, recibí este comentario en este blog al que, últimamente, he de reconocer que no presto la atención que debiera. Lo reproduzco porque creo que tiene valor para todos nosotros.

"Hola.He caído por aquí, como quien no quería la cosa, por un comentario de David Cervigón en su blog. Ya estás en mis favoritos.Lo que me impulsa a escribirte es que me has hecho reflexionar en mis pensamientos negativos que últimamente he tenido. Estoy en una empresa de tamaño pequeño (hablando de IT) de la automoción, y ya ves cómo está el patio últimamente en ese sector. Ahora estoy en un ERE, con lo que me toca "descansar" 2 días a la semana. Como consecuencia de eso, mi actitud está siendo la de "que les dén...", vamos, que me da igual lo que pase, que se caigan servidores, que haya problemas en la red, etc. He intentado "jugar" un poco con la virtualización (Hyper-V, vmWare ESXi, ...) pero en 3 días no saco mucho tiempo, sobre todo si hay que mantener el resto del negocio y de las tareas habituales, y si no hay presupuesto.Por eso lo de la reflexión. Me ha gustado tus comentarios, lo del no tener miedo, no preocuparse de los dineros, sino planear qué hace falta y meterse a ello. No es que me vaya a cambiar la vida, pero bueno, has conseguido al menos despertar algún pensamiento positivo en mi cabeza. Espero al próximo miércoles, cuando vuelvo al trabajo, para empezar a planificar y poner en marcha algunas de esas ideas / proyectos / pruebas que desde hace tiempo he querido hacer.Gracias,Javier."

La nuestra es una profesión ingrata. Nadie se acuerda del informático, sea técnico o director, salvo cuando las cosas fallan. Esta profesión requiere de cierta actitud personal para superar la desidia o indiferencia del resto de la compañía. Cuando todo funciona, somos los privilegiados, normalmente fuera de convenio, que ganamos más pasta que los demás. Cuando las cosas fallan, somos los mantas que no hacemos bien nuestro trabajo. Llevo ya unos cuantos años en esto y sé lo duro y difícil que resulta a veces este trabajo. Sé lo angustioso que resulta tener que tomar decisiones sabiendo que no tengo todos los conocimientos o la información necesaria para tomarlas (Todos hemos dudado ante un "Este proceso es irreversible. ¿Está Ud. seguro de continuar?"). Todos hemos dejado horas de sueño, y algún que otro impacto más o menos dañino en nuestra vida personal, por hacer que algo funcione. Todos hemos llorado, para dentro o para fuera, cuando no conseguíamos que algo funcionase tras horas o días de intentarlo.

Entiendo a Javier, igual que entiendo a otros compañeros que, tras partirse la espalda, se encuentran con un ERE, un traslado indeseado, una subida de sueldo que consideran inmerecida, o un ascenso a un tercero que creen merecer.

La vida es básicamente injusta. Es una frase que me gusta decir. Pero creedme que, cada vez que consigo que algo que falla funcione, cada vez que añado una funcionalidad nueva a un sistema, cada vez que cumplo una fecha estimada en un proyecto, me siento orgulloso de haber elegido una profesión ingrata como esta, independientemente de lo que cobre o no por hacerlo.

Esta es una profesión para ser humilde. Para aprender de todos. No de todos los que saben más que nosotros. De todos: desde el becario que llega, pasando por el usuario que se nos queja, siguiendo por nuestro jefe, y acabando por el externo al que han contratado para que nos ayude. Lo importante no es tener razón, sino que las cosas funcionen, gracias o a pesar de nosotros.

Quizá alguno piense que hablo desde una posición privilegiada. Hoy en día quizá ya no toco la tecla como antes, pero sigo siendo, y me sigo sintiendo técnico. Y me guardo mi pequeño hueco de pinchateclas resuelveincidencias. Porque es lo que he sido siempre, y espero no dejar de serlo. Porque me costó mucho llegar a serlo.

No, no somos héroes, pero quiero pensar que cada uno de nosotros se va a la cama cada noche pensando que ha hecho lo mejor que ha podido.

Alguien que conocí una vez, hace muchos años, me dijo: "J. o esto te gusta o estás jodido".

Por suerte, después de veinte años, me sigue gustando.

Un abrazo.

PD. He de reconocer que este post no es sólo para Javier. Hoy nuestra gente ha terminado de montar nuestra infraestructura de test y pruebas en nuestras nuevas oficinas. Son seis servidores Dell T605 donde ejecutamos las nuevas versiones de los hipervisores y nuevas configuraciones y productos que hay en el mercado, en parte como autoformación, y en parte como evaluación para alguno de nuestros clientes. El "CPD" de desarrollo y evaluación de nuestra compañía está en un cuarto de baño reconvertido, donde nuestra gente ha conseguido meter estás máquinas (y su electrónica de red, SAI's y demás aditamentos) después de un impecable trabajo de evaluación de infraestructuras (espacio físico, disipación de calor, etc, etc). Nuestros sistemas de producción están hospedados fuera de la oficina (con producción me refiero a los internos, entornos demo para clientes y alguna que otra cosilla que ya os contaré). Han trabajado duro para conseguirlo. Han metido horas que nadie les va a pagar. Pero hoy, cuando han terminado (y creedme que han empleado soluciones realmente creativas), sonreian satisfechos. Vaya por ellos también. Me siento orgulloso de este equipo de profesionales.

¿Oracle buenos días?

noreply@blogger.com (J. L. Medina) — Mon, 20 Apr 2009 17:04:00 +0000

Así me respondía esta mañana uno de mis contactos en SUN... evidentemente el anuncio por sorpresa de hoy da pié a este tipo de bromas. Contra todo pronóstico (al menos de los gurús del sector), una empresa de Software como Oracle adquiere un fabricante de Hardware como SUN. No hace mucho comentaba con otro de mis contactos en SUN que lo de que les comprara IBM no tenía buena pinta. No puedo imaginar otro interés en SUN por parte de IBM que los clientes de la primera. Resultaba trágico pensar que SUN Microsystems, con su peculiar (correcta o no) manera de hacer las cosas terminara fagocitada por el Gigante Azul.... y mira como son las cosas, el mismo gigante que empezó vendiendo hierro y ahora también tiene software, se encuentra con su némesis inversa: Un tradicional fabricante de software que termina metiéndose a vender hardware. Evidentemente a IBM poca gracia le debe hacer esto: Ni su hardware (y de paso las ventas del mismo) son lo que eran, ni su software ha sabido salir del nicho hardware de la compañía.

Parece que Oracle ha acertado: Unido a su imponente motor de base de datos, toma el control de Java, se deshace de MySQL (que empezaba a cosquillearle por los bajos), y se posiciona en el mercado del hardware con una tecnología avanzada (tanto en el mundo SPARC como en el x64).. y voilá!!... ¿Sólo esto? No. VMware debería poner sus barbas a remojo: Tanto SUN como Oracle demuestran interés en el mercado de la virtualización. SUN con VirtualBox, un hypervisor de tipo 2, y un (ya muy retrasado) xVM, clon de Xen que promete.... junto con una plataforma de gestión completa. Por otro lado, Oracle también hizo sus pinitos (Gracias al gato del CEO de Oracle, que escribe hypervisores cosa mala) con un repintado Xen y una incipiente plataforma de Gestión. Ahora las dos grandes preguntas son:

¿Estaremos ante el tercer gran player en esto de lo virtual?
¿Cuánto se va a pagar por Citrix?

Un saludo.

¡¡Cómo anda el patio!!

noreply@blogger.com (J. L. Medina) — Thu, 16 Apr 2009 05:22:00 +0000

Cisco comienza a vender servidores (ya os contaré que tal), IBM, HP y alguno más deja de vender equipamiento Cisco en la línea Blade. IBM amenaza con comprar SUN y resulta que queda en nada.

Cisco decide meterse en el fregado de servidores con la excusa de que no encuentra un "fabric server" adaptado a sus necesidades..... y de paso se quita el estigma de salir al mercado de servers y almacenamiento de mano de un tercero ( Algunos ya sabéis que si queréis comprar un conmutador Fiber channel para vuestra fastuosa SAN debéis pedírselo al fabricante de la misma, no a Cisco).

A este revuelo se añada vSphere 4.0. Para muchos quizá sólo sea una nueva versión: Para otros resulta ser toda una incursión de VMware en el mundo de las infraestructuras. Partiendo de la base de que el Nexus 1000V de Cisco puede comportarse como una tarjeta más del Nexus 5000 de Core, la cosa va cambiando. El VMware Fault Tolerance (VMware FT) supondrá un enorme cambio en la concepción de el alta disponibilidad: Básicamente compite con los clusters de Microsoft y de Symantec/Veritas. De último llueven las estadísticas sobre rendimiento, certificando que, en la inmensa mayoría de los casos, la penalización del hypervisor no supone un inconveniente para los entornos de producción... o dicho de otra manera, esto de lo virtual resulta que mola.

Y aún habrá más. Este año será crítico en cuanto a las tecnologías de dentro del CPD. Más competidores (no deéis de poner el ojo en Windows Server 2008 R2 o en las siguientes versiones de XenServer).

Añadid a lo que os cuento la presíon presupuestaria que vivimos: Nos aprietan desde arriba para reducir los costes. Y no sólo a los que trabajáis en cliente final, también a nosotros los que os vendemos cosas. Este año, y probablemente el que viene, serán los de la creatividad y la revisión de lo que hemos hecho hasta ahora.

Dejo estas opiniones a vuestra reflexión.

Un saludo.

IT en tiempos de crisis

noreply@blogger.com (J. L. Medina) — Tue, 03 Mar 2009 11:15:00 +0000

Aunque este post se salga un poco de lo habitual en este blog, una conversación que tuve en la sobremesa de ayer me ha hecho reflexionar sobre la oportunidad de escribirlo.

Todos sabemos que estos tiempos son tiempos de recortes. El que más y el que menos habrá recibido indicaciones, más o menos directas, sobre la conveniencia de contener y recortar los presupuestos, tanto de gasto como de inversión (OPEX y CAPEX que dicen los anglosajones), de su departamento de IT. Tampoco es un secreto que, a bote pronto, hay dos grandes partidas donde la tijera amenaza con ejercer: Personal y proyectos.

La partida de personal suele verse afectada (y ya lo está siendo en algunas grandes empresas) por la parte de subcontratación. Todos sabemos que, en la mayor parte de las grandes empresas (motor de la inversión IT por otra parte) la práctica totalidad del personal técnico (y con esto me refiero a los que administran y operan los servidores) son externos. En algunas, las partidas en este concepto han ido creciendo en estos años de bonanza económica como respuesta al incremento en complejidad y número de sistemas y aplicaciones que el negocio ha demandado.

En lo referente a proyectos ocurre más o menos lo mismo. Las inversiones propuestas el año pasado (renovación de parque, ampliaciones, actualizaciones) se consideran, de pronto, prescindibles en un entorno empresarial preocupado por la caja.

Básicamente, al requerimiento de "Más (o al menos lo mismo) por menos" se tiende a recortar en estos aspectos.

En estos tiempos, el peor enemigo del presupuesto IT es el miedo al cambio. El no implementar tecnologías por el miedo infundado al impacto en el entorno IT. Como dijo alguien a quien respeto enormemente, nos pagan para asumir riesgos. Y forma parte de nuestro trabajo el evaluar los riesgos tanto técnicamente como económicamente, y decidir si son asumibles. Y mi experiencia a ambos lados de la mesa (como cliente final y como consultor) me dice que si como profesionales nos dejamos llevar por el "si funciona no lo toques", uno, tarde o temprano dejará de funcionar, y dos, alguien vendrá a exigirnos cuentas de nuestras decisiones no tomadas. Como ejemplo, miremos los downgrades de entorno Host a entorno Wintel: Muchas compañías no lo hicieron por miedo infundado a que un servidor Wintel no pudiese ser tan buen servidor web como un AIX o un Solaris. Otras investigaron, evaluaron y migraron. El tiempo ha demostrado que las segundas, apostando por la evolución del mercado, han conseguido mantener unos presupuestos IT más acordes a los tiempos.

Dicho esto, mi conclusión: Invertir en tecnologías que suponen reducción de costes a corto y medio plazo (de 1 a 2 años) es la mejor manera de, por un lado, hacer más por menos, y por otro, mantener el nivel de servicio e integridad de nuestras estructuras.

¿En qué reducir costes?, evidentemente la pregunta no tiene una respuesta genérica, pero dejadme apuntar algunas respuestas:

Infraestructuras: Espacio en el CPD que tenemos alquilado. Reducción de consumo eléctrico en nuestro CPD. Reducción o paralización de las ampliaciones de aire acondicionado. Reducción de los requerimientos de remote hands en los servidores del datacenter.
Red: reducción o eliminación de los planes de ampliación de los puntos de red. Decomisión de electrónica de red sin uso o potencialmente descartable y eliminación de los contratos de mantenimiento.
Mantenimiento: Eliminación de servidores fuera de garantía, eliminación de excesos en máquinas y electrónica fuera de garantía.
Almacenamiento: Selección de nuevas tecnologías, uso de deduplicación, eliminación de SAN fuera de garantía, reducción de la infraestructura Fiber channel.
Copia de seguridad: Búsqueda de alternativa a la cinta. ¿externalización?, reevaluación de las políticas de copia de seguridad (¿podemos sobrevivir sin un full diario?)
Política de compras: Evaluación de nuevos proveedores (tanto de servicios como de hardware), modificación de los estándares de compra. Racionalización de las compras.
Informática de usuario: Limitación de nuevas adquisiciones de PC's, soluciones de informática centralizada.
Racionalización de las inversiones y renovaciones en seguridad y gestión de sistemas: No eliminarlos... racionalizarlos.
Organización departamental: Gestión del equipo humano, gestión efectiva del conocimiento. Reasignación de funciones.
Análisis en profundidad de la relación entre IT y el Negocio: Idoneidad de las soluciones aportadas. Análisis del ratio coste/beneficio en las mismas.
Creatividad: ¿Qué puede aportar IT al Negocio (y no hablo de migrar a Windows Vista, a la última versión del antivirus o a poner un logo de la compañía en el explorer)?
Plan de choche de mejoras inmediatas: Diseñar un plan de choque que mejore la percepción de IT y/o aporte medidas claras de contención de coste a negocio.

Supongo que a ninguno de vosotros os toma esto de sorpresa. Ahora sólo falta ir a por ello. Dejemos el miedo a lo desconocido a un lado y empecemos a pensar por nuestra cuenta, usando nuestros conocimientos y capacidad. Cuidado con los informes de costes de Gartner y demás: La contabilidad americana no es la española, ni los costes e inversiones se manejan de la misma manera. El "lo bueno viene de fuera" quizá tenga sentido respecto a algunas tecnologías, pero este país tiene memorables casos de reducción de costes que merece la pena estudiar.

PD. ¿Os habéis dado cuenta de que no he nombrado la virtualización ni una sola vez?

Un saludo.

¿Qué significa para mí ser VMware vExpert?

noreply@blogger.com (J. L. Medina) — Sat, 28 Feb 2009 10:00:00 +0000

Como anunció VMware, el hecho de ser nominado vExpert no implica que el nominado sepa más que nadie, o que simplemente los nominadores piensen que sabe más o es mejor que nadie. No ha sido la intención de VMware (y que conste que no hablo en su nombre) discriminar a nadie.

Para algunos, el vExpert es el merecido reconocimiento de VMware a una labor de "evangelización" y/o comunicación en todo lo referente al mundo de la virtualización, eso sí, centrado en sus productos.

En mi caso particular, lo considero un reconocimiento a casi diez años de pelea contínua intentando demostrar que esto de convertir PCs o Servidores en programas tiene sentido. Aún recuerdo cuando recibí el correo de VMware, allá por 1.999 en el que me anunciaban que me dejaban ser betatester de VMware Workstation. Aún recuerdo como me impresionó ver abrirse un Windows 95 en una ventana de mi RedHat 4/5. En ese momento supe que esto de la virtualización (Los PCeros, en aquel momento no sabíamos ni cómo se escribía la palabra en cuestión) me iba a gustar. Como buen teki (Técnico para el resto de los humanos) me dejé arrastrar por lo que atraía mi atención.

Pasó el tiempo, y por aquel 2001 cayó en mis manos el VMware GSX. Aquello ya era más serio: No se montaba como aplicación, sino ya como servicio. Me duró un mes, hasta que empecé a tocar ESX 1.0. Creo que la primera instalación en semi-pre-producción en este país la hice yo (admito divergencias sobre este punto)... Y mis ojos volvieron a brillar cuando conseguí que un IBM xSeries 440 arrancara el ESX y levantara máquinas virtuales. Seguía teniendo la misma mirada incrédula que allá por el 99.

Quien me conoce desde hace años sabe como empecé: Programando Cobol y ensamblador en un Phillips 3500. De ahí pasé a sistemas (Lo siento, el desarrollo siempre me aburrió mucho), y de sistemas, a Comms... Chico Cisco. Por estas cosas de la vida (y de la empresa donde trabajaba) tuve que implementar un directorio activo para un gran cliente, así que tocó estudiar. Y durante un tiempo me dediqué a proyectos Microsoft.... hasta que un día encontré mi hueco y me centré en la virtualización de lleno. Durante todo el tiempo previo siempre usé máquinas virtuales, hasta el punto de hacérseme incómodo el trabajar con máquinas físicas. Costó mucho convencerme a mí mismo de que aquello era apto para producción (para bien o para mal conozco ambos lados de la tecnología: El lado del que la vende y el lado del que la explota). Costó muchas pruebas y mucho tiempo: Sólo en el 2003 me atreví a "meterle" ESX en producción a un cliente. Eso sí, fué un Oracle 8, con 2000 usuarios conectados..... porque el cluster físico se había caído. Y cuando el ESX pudo con ello, volví a sonreir incrédulo.

¿Y sabéis una cosa? Hoy, después de unos cuantos ESX montados, después de todos los proyectos en los que he tenido la suerte de participar... después de evangelizar, tanto fuera como desde este blog.. aún me sorprende ver un Windows 2003 arrancar dentro de un ESX.

¿A qué viene este rollo que os suelto? A que, en cierta manera, la nominación (el "award" que dicen los americanos) es una recompensa (yo lo considero así) a todo ese tiempo, a todo ese esfuerzo.

No diré que no me considero merecedor del "Award". Totalmente al contrario. Y de todas las medallas, chapas y/o certificaciones que pueda tener, esta es de las más preciadas.

Un saludo.

Congratulations! You have received a VMware vExpert Award!

noreply@blogger.com (J. L. Medina) — Wed, 25 Feb 2009 12:28:00 +0000

Vaya con el correo que se me coló en la carpeta del Spam:

"Congratulations! On behalf of VMware, we would like to thank you for all the work you’ve done giving back to the virtualization community and sharing your expertise with others. We are pleased to present you with the VMware vExpert Award for 2009. VMware is giving this award to individuals who have contributed significantly to the community of VMware users over the past year.

VMware vExpert award winners will receive:

* An award certificate and gift

* Access to a private vExpert community

* vExpert logo to display on website or email signature

* Free subscription to conference session materials on VMworld.com

* Access to exclusive online events and other opportunities to participate in activities

* Inclusion in public vExpert directory

The vExpert award duration is one year (through February, 2010)."

He de reconocer que encontrarme en la misma lista que monstruos de esto de lo virtual como Scott Herold, Eric Siebert o Eric Sloof, entre otros, le infla a uno el ego (si no lo tenía ya suficientemente inflado)

Por último, agradeceros a los que me habéis nominado el haberlo hecho.

Un abrazo.

El que faltaba...

noreply@blogger.com (J. L. Medina) — Mon, 23 Feb 2009 22:56:00 +0000

Parece que ya estamos todos. Citrix ofrece "gratis" Xenserver Enterprise. Evidentemente, la jugada tiene sentido: El que se mueve no sale en la foto. Tras una inversión millonaria (500.000.000 US$) por un producto que les ha dado bastante menos del 30% de esa inversión, con Microsoft jugando por su cuenta (lo que quiere decir normalmente en contra del resto) y tras descubrir que tanto Oracle como SUN también sacaban su Xen particular, Citrix se ve obligada a liberar Xen Enterprise.

Parece que Citrix sólo hace negocio con XenServer en entornos VDI... básicamente por su inigualable ICA... y su (supongo) negativa a dejar que su protocolo de presentación se integre con otros brokers.

Eso sí, algunos, lo suficientemente curiosos como para investigar, han descubierto lo siguiente:

La edición "free" de Xen Enterprise no incluye:

HA: Parece que la clusterización ha desaparecido del XenServer Enterprise y ha aparecido con Essentials, que sí es de pago. (entre 1.500 y 6.000 US$ por server).
Workflow Studio: También desaparece de la versión enterprise y "aparece" en Essentials
StorageLink: Los modulos de integración con el almacenamiento también saltan a Essentials.
Workload Balancing: Otra "transmutación".

Otra de las cosas anunciadas (y que curiosamente suena bastante menos), es la presentación de Citrix Essentials for Hyper-V. Supongo que no le hará demasiada gracia a Microsoft.

Como comenté en un post anterior... ¿Cuánto aguantarán los presupuestos de desarrollo de empresas como Citrix el mantener un Hypervisor gratis... especialmente con la que está cayendo?

Como postdata, una curiosidad:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1  xe_license sku_type="XE Enterprise" version="5.0.0" productcode="5f49-fbcc-054f-f13a-7b80-c22f" serialnumber="289fc986-3338-6768-80cf-7b29b00f7197" sockets="64" expiry="1240527600.000000" human_readable_expiry="2009-04-23" name="XenServer Free Virtualization" address1="" address2="" city="" state="" postalcode="" country="" company="" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)  iD8DBQFJlX+1or8EvHqMeKcRAnNUAJ4nqJXkN2yH18A+d1ayYCD6HgNtCwCffscj YK1tVghW0HB7p81IoKyLMOU= =3zXt -----END PGP SIGNATURE-----

Este es el archivo de licencia que acompaña al download "gratuito". Fijaos en la fecha de expiración....

un saludo.

Containerización

noreply@blogger.com (J. L. Medina) — Mon, 26 Jan 2009 01:02:00 +0000

Aprovechando un excelente post de David Cervigón, titulado "Los cimientos de la nube", aprovecho para hablaros un poco sobre este concepto que, cada día, va dejando de ser ciencia ficción y se va convirtiendo en la única alternativa viable a los desbordantes costes de infraestructura que supone un datacenter.

Hay una triste realidad que empieza a aparecerse claramente a los responsables de infraestructuras del datacenter: Lo más barato son los servidores. Mientras con 200k llenamos unos cuantos racks con máquinas (ya sean blades o no), la inversión necesaria para refrigerar un datacenter supone fácilmente muchas veces esa cantidad. No es extraño que el coste de la refrigeración (sumando el coste del equipo y el de la electricidad que consume tanto el equipo como ) supere con creces el coste del servidor.

Si además tenemos en cuenta el coste de provisionamiento de los mismos, la cosa se disparata: Compra el servidor, busca sitio en el CPD para instalarlo, solicita cableados (fibras y red), tensión eléctrica... Estos inconvenientes no sólo aplican a los servidores, sino al almacenamiento, infraestructura de red, etc.

El coste del cableado no es precisamente desdeñable. Conozco casos donde el coste oscila desde unos 200 € la conexión a más de 1000 €. No digo que el cable cueste esto: Digo que ponerlo en marcha se acerca a estos costes.

La instalación de un servidor en determinado rack también puede resultar una odisea: Si tenéis la suerte (o la pasta) de mantener unos racks prístinos y limpios de cables cruzados, no tenéis latiguillos en modo gordiano (de los que sólo puedes deshacerte con un hacha) y además resulta que tienes las U bien asignadas, no sigas leyendo: Para todos los demás, la pesadilla de "¿Cómo meto un servidor sin llevarme por delante el resto?" es una realidad palpable.

Mi compañía esta actualmente trabajando en un proyecto para uno de los CPD más grandes de este país donde toda esta tormenta es una realidad. Hay partes de ese datacenter donde es virtualmente imposible colocar una máquina más sin una parada de servicio que, por supuesto, la compañía no puede permitirse.

Así mismo, los tiempos de provisionamiento de nueva infraestructura son dispares: Desde que se adquiere un nuevo pool de servidores, almacenamiento y red hasta que este se provisiona, puede pasar cerca de un mes: Los servidores pueden estar en una semana, el almacenamiento se instalará después de los servidores, por aquello de saber a qué troncal de fibra deben conectarse, y la red Dios dirá. Y negocio no espera.

Estamos trabajando en la idea de racks consolidados para los servidores y el almacenamiento. La idea es que el proveedor no suministre servidores, sino racks completamente equipados con un número determinado de máquinas preenrracadas, su electrónica de red y su red SAN. El punto de contacto con el resto del CPD se limita a dos conexiones 10G para la red, 4 tomas de 16 amperios y 4 puertos FC de 4 Gbit/sec.

En el caso del almacenamiento, las conexiones se limitan a dos puertos Gbit (para la gestión de cabinas si fuese necesario), 4 puertos FC de 4 Gb y otras cuatro tomas de 16 Amperios.

En el rack de servidores estamos evaluando la posibilidad de usar Infiniband. Mediante dos tarjetas por equipo, conseguimos un ancho de banda acumulado de hasta 40 Gbit/Sec con latencia despreciable, conectados a un router Infiniband que nos ofece 4 10Gb Ethernet de salida y 4 FC de 4 Gb. La simplificación de cableado dentro del propio rack mejora su climatización y su mantenimiento, así como la reducción de conexiones al exterior (12, contra las 60-96 de configuraciones anteriores). Por otro lado, Cisco Systems nos ofrece Datacenter Ethernet (Ethernet sin pérdidas), pero lo de FCoE (Fiber Channel over Ethernet) no termina de convencerme.

En este caso, el proveedor de hardware, Sun Microsystems, suministra los racks así diseñados con P/N propio, lo que simplifica, además, el proceso de compra.

El cliente obtendrá un entorno más ordenado a un precio más asequible, (las ventas del proveedor suben en importe puntual aunque se distancien en el tiempo), una enorme reducción de coste de infraestructura. (no necesita ampliar su electrónica de red de core a trompicones, sino de manera ordenada), requiere menos suelo (racks llenos de potencia y no de U's vacías), y menos cooling (los racks vienen preacondicionados para un cooling óptimo).

Fig.1. Rack Tradicional

Fig. 2. Container

En este ejemplo, el container sólo consolida el I/O, y aún así, supone un considerable ahorro. Si evolucionamos la idea del container hacia la de isla (lo que supone romper con el esquema tradicional de pasillo caliente, pasillo frío) obtenemos soluciones como las de APC, que a continuación ilustro:

Fig. 3. Islas de APC. (Dibujan mejor que yo)

En este esquema, además de consolidar el I/O, es posible consolidar la extracción de calor, y en vez de tener que refrigerar a 19 grados todo un CPD, es posible centrar el frío en "islas" de calor. En este ejemplo, la containerización incluye otro de los aspectos problemáticos del datacenter: El cooling. He visitado fuera de España algunos CPD organizados de esta manera, y creedme que se agradecer no ponerse el polar para entrar.

Fig 3. CPD organizado en islas

Fig. 4. Islas de APC en el Datacenter.

Como podéis observar, el CPD se convierte en una caja de cemento que alberga islas semi-autosuficientes donde se concentran el "hierro" y la electricidad. El datacenter se convierte únicamente en proveedor de protección contra el entorno, electricidad y extracción de calor.

¿Y si damos un paso más?. Mirad por ejemplo el proyecto BlackBox de SUN. Básicamente se trata de un container (esta vez literalmente) que alberga todos los elementos necesarios: Las máquinas, la UPS, el cooling (por agua), la disipación de calor y la protección medioambiental.

Fig. 5. Imágenes del SUN Blackbox

Bajo este concepto, el datacenter como edificio deja de tener sentido. Imaginad una explanada, con una pequeña caseta que alberge las tomas eléctricas para los containers y la conexión de red. Quizá suene fantástico, pero con CPDs a un coste de 170 Millones por 2000m2 útiles, y corriendo los tiempos que corren, quizá no sea del todo un disparate.

Pronto SUN me dará la oportunidad de "curiosear" por uno de sus containers... os daré más detalles.

Una cosa más. La virtualización nos dá la posibilidad de realizar este tipo de agrupamientos sin demasiado impacto. Y como siempre digo, pensad en global y actuad en local.

Un saludo.

Virtualization Industry Survey 2008: The results - Part 1

noreply@blogger.com (J. L. Medina) — Tue, 20 Jan 2009 08:39:00 +0000

Desde virtualization.info, el blog de mi respetado Alessandro Perilli, nos llega el resultado de una encuesta sobre el impacto de la virtualización en los entornos corporativos. Alessandro ha recopilado 1050 respuestas y ha publicado el informe estadístico sobre las mismas. El informe completo lo podéis consultar aquí

Las conclusiones que yo extraigo del informe, reforzadas por mi propia experiencia, son las siguientes:

Q1 - La virtualización resulta económicamente interesante para compañías de tamaño medio alto.

Evidentemente, los evangelistas, técnicos, integradores no hemos encontrado la manera de entrar en la PYME. La pregunta es si la virtualización es apta para este segmento de empresa.

Q2 - En EEUU y en Europa virtualizamos más que en el resto del mundo. Dejando aparte las diferencias económicas, es posible extraer la conclusión de que en los entornos donde el parámetro "coste" es más importante, la virtualización más o menos masiva encaja en un esquema de contención (e incluso reducción) de costes

Q4 - Los impulsores de la virtualización siguen siendo los Técnicos, o al menos, los perfiles con un conocimiento técnico más amplio. Los CIO, reponsables entre otras cosas del presupuesto de IT y los SLA no apuestan por la virtualización como una tecnología que pueda a) reducir costes, b) garantizar los SLA. Esta tendencia, según cuentan los analistas, cambiará a lo largo del 2009.

Q3 - Evidentemente, otra vez, los evangelistas, técnicos, expertos y demás no conseguimos hablar el idioma del negocio para configurar la virtualización como una ventaja presupuestaria y una ganratía adicional de disponibilidad.

Q4 - La virtualización se impone en producción. Se percibe que se han quedado atrás los tiempos en que las máquinas virtuales eran vistas como una fuente de problemas y de deconfianza. Cada vez, y ahí aporto mi experiencia, explotación se siente más cómoda con las máquinas virtuales.

Q5 - La virtualización parece que se extiende de manera masiva por los entornos corporativos.

Q6 - Respecto al hypervisor seleccionado, parece que los ganadores son VMware ESX y Microsoft Hyper-V. Sin entrar en los números de los dos más resaltables, queda claro que el resto de los hypervisores ocupan un pequeño nicho. Los "players" son VMware y Microsoft.

Q7: Resulta impresionante el rango de VM que se indica en la estadística. 50 máquinas virtuales ya resulta un buen porcentaje de los servidores de una compañía... que decir de mil. Resulta curioso el salto del gráfico entre la barra de 500-1000 y la de más de 1000. ¿Interpretaciones? Las grandes corporaciones apuestan claramente por la virtualización.

Q8: Nada sorprendente: La virtualización se aplica en consolidación de servidores y entornos de demo y formación. Aún nos cuesta a los que sabemos de esto convencer a desarrollo.... Por otro lado, confirma que VDI aún necesita desarrollarse, y que la virtualización da una respuesta acertada al mantenimiento de aplicaciones legacy.

Q9: Vaya... el mayor dolor de cabeza parece ser la proliferación de VMs, la planificación de capacidad de la infraestructura virtual y la elección del hypervisor. Lo dicho: Nuevas tecnologías, nuevos problemas.

Q10: Costes, siempre costes. Estoy seguro de que ese 25% son clientes de VMware...

Evidentemente estos números están sujetos a interpretación (por ejemplo, cuantos Hyper-V hay en los entornos de 1 a 50 VM y cuantos ESX hay en los entornos de 500 a más de 1000 VM), pero sin entrar en detalles, este estupendo informe debería hacernos reflexionar... y avanzar.

Un saludo.

¿Cómo se licencia Windows Server en entornos virtuales?

noreply@blogger.com (J. L. Medina) — Tue, 23 Dec 2008 21:14:00 +0000

Sigue habiendo polémica con el licenciamiento. Ya sea por desconocimiento o intencionadamente, se sigue diciendo que ESX es más caro que Hyper-V porque Microsoft permite que si instalas un standard uses otra licencia en virtual sobre esa máquina, o que si usas Enterprise puedes ejecutar hasta 4 instancias sobre esa máquina... o si licencias datacenter tienes buffet libre... Nada como recurrir a las fuentes:

Windows Server 2008: Microsoft Licensing FAQ for Windows Server 2008:

Q. Do the virtualization licensing rights of Windows Server 2008 apply when used with non-Microsoft software virtualization technologies?
 A: Yes. The use rights apply regardless of the virtualization product being used.

Windows Server 2003: Página 7 del documento “Licensing Microsoft Windows Server 2003 R2 to Run with Virtualization Technologies”

"If you have assigned a single license of Windows Server Standard Edition to the server running ESX, then you may run one instance at a time of Windows Server Standard Edition. If you have assigned a single license of Windows Server Enterprise Edition to the server running ESX, then you may run up to four instances at a time of Windows Server. You may not run a fifth instance under the same Enterprise Edition license because that right requires that the fifth instance be running hardware virtualization software and software managing and servicing the OSEs on the server. However, Datacenter Edition permits unlimited running of instances in virtual OSEs."

Conclusión:

Cualquier modo de licenciamiento que afecte a los productos Microsoft afecta a cualquier otro software de virtualización.

Actualización: Como respuesta a mi duda sobre la simultaneidad de uso:

Lo que no tengo yo tan claro es que si usas un 2008 con Hyper-V y creas una VM, puedas usar SIMULTANEAMENTE los servicios de ambas máquinas: la del contenedor y la del contenido; es decir, si puedes usar un IIS en el Windows 2008 con un sitio web a la vez que lo usas en la VM.

Tampoco se aclaran si también las CAL (File server, print server, etc) también se multiplican por 2, por 4 o infinitamente.

El Gran David Cervigón nos aclara:

"Hola

Si, puedes usar simultáneamente los servicios de todas las instancias, sean físicas o virtualesLo de las Client Access CALs depende del modo elegido:

Link de referencia 1 Licenciamiento de Windows 2008
Link de referencia 2 CALs

Saludos"

Un abrazo para David y nuestro agradecimiento por la clarificación.

Para lo que nos interesa:

1 VM Windows Server cuesta lo mismo con Hyper-V que con ESX 3i: Una licencia de Windows Server Standard
4 VM Windows Server cuestan lo mismo con Hyper-V que con ESX 3i: Una licencia de Windows Enterprise
Barralibre de Windows Server cuesta lo mismo con Hyper-V que con ESX 3i: LAs CPU del host licenciadas con Windows Server Datacenter.

Nota técnica: Conversión de Domain Controllers

noreply@blogger.com (J. L. Medina) — Sun, 21 Dec 2008 10:00:00 +0000

Parece que está de moda convertir los domain controller. A pesar de que es una práctica no recomendada, se incrementan las "quejas" de mucha gente que intenta hacerlo. Partiendo de la base de que, en mi opinión, se tarda menos en promover un nuevo DC que en convertirlo, os dejo el link a un KB de VMware para los que aún se atrevan (o no les quede otro remedio) que convertirlo. Sólo un recordatorio: Converter sólo virtualiza un domain controller, no arregla un dominio con problemas. Para lo que sí sirve una conversión de un domain controller es para hacer aflorar o agravar los posibles "problemas" ocultos de un directorio, así que toca revisión exhaustiva el Dominio antes de la conversión (link, otro link, más una enormidad en google). Para los que os tropezáis con uno de esos Domain controller-navaja suiza (es decir, un DC que además tiene trescientas cosas más montadas encima), mi consejo es: Nueva VM, dcpromo para promoverla a DC, migración de roles (os dejo un link por aquí) y un dcpromo en la vieja para despromoverla como DC.

Un saludo.

VMware vSphere: Supuesto nombre para VI 4.0

noreply@blogger.com (J. L. Medina) — Sat, 20 Dec 2008 08:03:00 +0000

Parece que el rumor vBlogosférico parece confirmarse: VMware VI 4.0 se llamará VMware vSphere. Aunque parece que el nombre no triunfa entre otros evangelistas de esto de lo virtual (vease la opinión de Scott Lowe al respecto), debo reconocer que me parece ciertamente adecuado. Teniendo en cuenta que la batalla ya no debería centrarse en el hypervisor (la infraestructura), sino en todo lo que la rodea. Bajo esta premisa, el nombre Sphere (teniendo en cuenta no sólo ESX, sino el resto de productos, vCenter, vCenter Stage Manager, vCenter Lifecycle Manager, vCenter AppSpeed y demás) aspiran a "cerrar el círculo" (o la esfera) alrededor de los servidores me parece ciertamente adecuado. Por otro lado, lo mío no es el marketing, así que puedo estar perfectamente equivocado.

Un saludo.

¿Jumbo frames en iSCSI?

noreply@blogger.com (J. L. Medina) — Thu, 18 Dec 2008 15:25:00 +0000

Bien es sabido y cacareado por la blogosfera que VMware no da soporte a configuraciones iSCSI o NFS en ESX con jumbo frames (frames ethernet de 9000 bytes) (por otra parte, tampoco encuentro la negativa explícita de VMware al respecto). Hoy, curioseando por la web, me encuentro en este documento titulado VMware VDI Storage Considerations la siguiente frase:

"iSCSI solutions can use either the built-in iSCSI software initiator or a hardware iSCSI HBA. The use of software initiators increases the CPU load on the VMware ESX, while HBAs offload this processing time to a dedicated card (as FC HBAs do). To increase the throughput of the TCP/IP transmissions, iSCSI should use jumbo frames. A frame size of 9000 bytes is recommended."

No hace falta que describa la cara que se me ha quedado....

Licenciamiento de sistemas operativos Microsoft en entornos VDI

noreply@blogger.com (J. L. Medina) — Thu, 18 Dec 2008 06:37:00 +0000

El maestro David Cervigón ha publicado un post sin desperdicio sobre cómo licenciar sistemas operativos Windows en entornos VDI. Muchos de vosotros me habéis preguntado cómo se licencia Windows en entornos de desktop virtualizado. Y nada mejor que la respuesta de un experto para aclararos las dudas.

Un abrazo.

Nuevo Link: Under C.P.D.

noreply@blogger.com (J. L. Medina) — Thu, 18 Dec 2008 06:31:00 +0000

Os dejo el enlace al Blog de Miguel H, un excelente profesional al que tuve el placer de conocer en una charla en la que ejercí de ponente por invitación de los amigos de Sistel por esas tierras del levante. Un blog, sin duda, de obligada lectura.

Un abrazo.

Moderación de comentarios.

noreply@blogger.com (J. L. Medina) — Tue, 09 Dec 2008 22:13:00 +0000

Ayer me he encontrado el siguiente comentario a un post sobre Virtual Desktop:

"WEBINAR GRATIS: El Futuro de Desktops Virtuales

Jueves, 11 de diciembre de 2008
Hora: 11:00 a.m. hora del este
www.citrixlac.com/xendesktopwebinar
La virtualización de desktops representa la nueva frontera para TI.
Inscríbase ahora para discutir con el Senior Manager de Producto de Citrix sobre:
•Escenarios de VDI y optimización de escritorios
•Soluciones para escritorios físicos y virtuales
•Entrega de escritorios y aplicaciones on-demand a través de administración y aprovisionamiento dinámicos
www.citrixlac.com/xendesktopwebinar"

He de suponer que este comportamiento, el de usar un blog de terceros para publicitar sin permiso un producto o compañía, no es sino fruto de la iniciativa individual de la individua (Para más señas se llama Carol Mallia y he de suponer relacionada en algún modo con Citrix) que firma el post, y no de una compañía como Citrix, que dudo ampare estos procederes. Por supuesto, procederé a informar a Citrix del comportamiento, a mi humilde parecer, poco ético, de dicha señorita.

Para evitar futuros incidentes similares, he decidido moderar el blog.

Lamento las molestias que os pueda ocasionar. Que nadie malinterprete los retrasos en la publicación de comentarios, sino que los achaque a mi ya habitual falta de tiempo para todo.

Un saludo.

Nuevo Link: El Blog de Javier Martinez aka jamarmu

noreply@blogger.com (J. L. Medina) — Mon, 24 Nov 2008 12:13:00 +0000

Mi buen amigo y respetado profesional, Javier Martinez, Director Técnico de NetApp en España, se ha decidido al fín a abrir un blog. Mi relación con Javier viene de lejos, y es uno de los profesionales de referencia en el mundo del almacenamiento en España. Personalmente es uno de mis pilares de "sabiduría" en lo que a almacenamiento se refiere. Os aconsejo fervientemente que visitéis su blog. No tendrá desperdicio.

E pur si muove......

noreply@blogger.com (J. L. Medina) — Sun, 23 Nov 2008 19:57:00 +0000

La migración de máquinas virtuales entre host siempre ha sido un tema controvertido. Entre los defensores a ultranza de Live Migration (movimiento sin parada/suspensión) hasta los que aseguran que Quick Migration (movimiento previa suspensión y con periodo corto de pérdida de servicio) es más que suficiente, hay opiniones para todos los gustos.

La mía, como siempre, es "depende". Quiero decir que, aparte del aspecto tecnológico que no puedo negar que resulta impresionante, existen otros tipos de consideraciones. Teniéndolas en cuenta todas, mi opinión es, sin duda, Live Migration gratis. Como por desgracia eso por el momento no es posible, me veo obligado a detallar más mi postura.

Yo me acuso de usar vMotion (Live Migration según VMware) en producción. Y he mantenido entornos de producción con una o dos migraciones diarias hasta el otro extremo de 19 (sí, digo bien, diecinueve y hay testigos) por minuto en entornos DRS (Distributed Resource Scheduler). Y duela a quien le duela, funciona. En las pocas ocasiones en que la he visto fallar en algún que otro cliente, siempre ha sido un problema asociado a la configuración de red, a la del almacenamiento o a la del ESX. Nadie está libre de que su tecnología falle por razones del entorno.

Sin embargo hay razones que desacosenjan y hasta impiden la implementación de vMotion. Entre las técnicas, las compatibilidades entre procesadores, que no siempre son subsanables mediante masking de registros (véase el caso de SSE4) o EVC (Enhanced vMotion Compatibility -no sé si existe algo similar en el mercado para el resto de los hipervisores), y por otro lado, la sempiterna economía: vMotion implica un coste, tanto del producto como del soporte posterior.

En un entorno de producción, la existencia o no de Live Migration puede ser la diferencia entre tener que hacer una solicitud de cambio (change request), pasar un comité de probación y planificar una parada en el caso de no disponer de ella, a no tener que pasar por ese necesario calvario, ya que, en realidad, el servicio no se interrumpe. Y conozco muchas políticas de cambio donde un vMotion no implica una solicitud/aprobación ya que el servicio no se interrumpe. Evidentemente, en un entorno de desarrollo o preproducción, la necesidad de Live Migration se ve claramente disminuida, en especial si acarrea coste. Incluso algunos servicios de producción pueden "evitar" el uso de Live Migration simplemente duplicando servidores y asegurándonos que no se ejecutan todos en la misma máquina... hablo de Domain controllers, granjas web, etc.

Sin embargo, para servicios de producción como Bases de datos, servidores de correo, que no son fácil o económicamente redundables, Live Migration se convierte, en datacenters altamente virtualizados, en un requerimiento fundamental para evitar paradas de mantenimiento de los hosts o el almacenamiento, o de factores infraestructurales como el suministro eléctrico, obras o modificaciones del datacenter, etc. Los downtimes más o menos programados... o los temidos Zeros (apagado eléctrico del datacenter), pasan de ser situaciones que requieren de una cuidadosa programación a una serie de operaciones absolutamente normales.... o dicho de otra manera, de una frenética carrera de apagado del site principal y encendido del de respaldo en unas cuantas horas, a unas cuantas operaciones programadas con semanas de antelación (podemos ir moviendo las máquinas con dias o semanas sin necesidad de esperar al día del apagado) sin impacto apreciable en la operación.

A muchos de los que estáis leyendo este post, su contenido no debe suponer una sorpresa: Ya estáis más que hartos de hacer vMotion (aka VMware Live Migration) sin un sólo problema. A los que no, os animo a "vivir" la experiencia de vMotion. A los que siguen diciendo que vMotion sólo funciona en los vídeos, deciros lo mismo que se atribuye a Galileo Galilei...

... Y sin embargo, se mueven!!!

La seguridad del dato en el desktop y la productividad del usuario.

noreply@blogger.com (J. L. Medina) — Tue, 11 Nov 2008 11:54:00 +0000

A todos nos queda claro que el dato debe asegurarse. La información con la que trabaja nuestra compañía está protegida por RAIDs, backups y réplica… ¿toda nuestra información lo está?

Hay determinados entornos donde, ya sea por las políticas de IT respecto a cuotas de disco o correo, bien por seguridad o por operativa de negocio, el dato de negocio “desborda” de los servidores de la compañía al desktop del usuario. Todos conocemos más de un caso donde una política de cuotas de correo más o menos estricta obliga al usuario a crear un archivado local del correo. O una política más o menos acertada de almacenamiento en red obliga al usuario a, inicialmente, copiar en su desktop (ya sea portátil o no), archivos que, en una segunda fase, son modificados localmente y en una tercera, almacenados periódicamente en el servidor de ficheros. Todo esto funciona hasta que el desktop falla (un fallo hardware o software) o se pierde o destruye (portátiles, por ejemplo). Según Murphy, esto pasa siempre el día antes en que el usuario tenía previsto actualizar el servidor. Todos sabemos que cualquier actividad informática genera un campo de Murphy de intensidad variable, pero directamente relacionada con la importancia del dato almacenado.

Por otro lado, hay datos que sin ser directamente corporativos, sí lo son para el trabajo diario del usuario: Documentos de referencia, favoritos, shortcuts en el escritorio, preferencias de impresión. No es cuantificable a priorí el impacto que la pérdida de estos datos supone para la productividad del usuario.

Aparte, claro, de la pérdida del dato, la reconstrucción de ese desktop también obliga al departamento de soporte a intervenir de inmediato, ya que al usuario un PC instalado con un Windows XP estándar no suele servirle de demasiado: Configuración de correo, configuraciones específicas de navegador, unidades de red, impresoras, etc, por no hablar de las aplicaciones corporativas…. Sin contar con que el usuario del PC a reconstruir no sea un VIP dentro de la compañía. Este factor suele elevar la tensión e importancia de la recuperación a niveles auténticamente estresantes.

¿Soluciones? Unas cuantas a lo largo del tiempo. Veamos algunas.

El perfil itinerante (roaming profile)

Evidentemente existen soluciones para minimizar el impacto de la pérdida de las configuraciones personales. Todos conocemos las capacidades de perfiles almacenados en un servidor que nos ofrece directorio activo, o la redirección de carpetas más o menos críticas (desde “Mis Documentos” a “Escritorio”) hacia un servidor de ficheros. Directorio Activo permite que el perfil de un usuario determinado “acompañe” al mismo cuando cambia de PC. También sabemos que hay aplicaciones a las que les sienta mejor o peor esta tecnología. Por otro lado, incorpora un factor de riesgo de fallo de esta sincronización, y no es precisamente ideal para usuarios con acceso de red por debajo de las 100Kb por segundo. En el caso de usuarios móviles, las dificultades se acentúan: La resolución de conflictos entre versiones on-line (almacenadas en el servidor) y las off-line (almacenadas en el portátil del usuario) suele traer más de un quebradero de cabeza.

También en el caso de usuarios con alta rotabilidad (es decir, que cambian de puesto de trabajo o PC’s en modo kiosko) esto suele obligar a una gestión del almacenamiento local de cada PC, ya que el contenido del perfil del usuario se copia en cada login al disco duro del PC. Además del inconveniente del limpiado del disco duro, aparece el componente de seguridad: En cada PC se almacena una copia de las preferencias del usuario que lo usa, incluyendo usuarios, contraseñas y certificados.

El PC en el datacenter (Blade PC).
Otra aproximación es la de “encerrar” el PC en un centro de datos. Evidentemente esto ofrece protección contra caídas eléctricas, robos, manipulaciones más o menos accidentales y demás factores medioambientales que afectan al PC. Pero desde luego mantienen la dependencia del ordenador físico (blade o no, esté o no en el CPD sigue siendo un PC), y por lo tanto, susceptible a fallos. La tecnología blade PC no hace más que trasladar los problemas hardware al datacenter.

Terminal Services.
La opción de usar terminal services (o sus equivalentes, como Citrix y demás) ha sido, durante mucho tiempo, la opción más razonable (según algunos, un mal necesario) para servir el entorno de desktop corporativo a los usuarios a través de cualquier dispositivo. Permite esquivar los problemas de las técnicas antes mencionadas: Los perfiles itinerantes funcionan (el servidor está en el datacenter y no se desconecta de la red, y la red de datos entre el servidor de terminales y el servidor de ficheros es de alta velocidad y calidad), no requieren de múltiples copias de los perfiles y garantiza la seguridad de los datos de usuario, pero también presenta otros serios inconvenientes.

En un entorno heterogéneo de aplicaciones de usuario, donde todos los usuarios usan la misma versión de todo (desde Internet Explorer hasta las aplicaciones corporativas), Terminal services ofrece claras ventajas. El problema viene cuando, sobre la misma granja de servidores hemos de mantener varias versiones de Explorer, de Office o de la aplicación corporativa, que utilizan distintas versiones de DLL’s o que, simplemente, son incompatibles. La administración de este tipo de granjas suele requerir de personal altamente cualificado, tiempo, entornos de desarrollo y, sobre todo, de mucho tiempo de evaluación de nuevas aplicaciones. Además, no debemos olvidar que terminal services no es más que un “ordenador” usado por múltiples usuarios, lo que, a priori, puede permitir, y de hecho suele convertirse en un quebradero de cabeza, que un problema en una sesión de usuario afecte a los restantes: Un “cuelgue” de Explorer, un “crash” de la aplicación de turno puede afectar al resto de los usuarios que usan la aplicación.

¿Qué ofrece virtual desktop?
Virtual desktop ofrece las ventajas de todos estos entornos: Por un lado el PC se ejecuta en el CPD (Donde las posibilidades de impacto medioambiental son menores), por otro, no se ejecuta en hardware de PC (más barato, sí, pero más propenso a fallos de hardware), y por último, cada virtual desktop es un entorno aislado: Un fallo de la aplicación, un solo usuario afectado.

Los modernos hypervisores ofrecen, en mayor o menor medida, sistemas de recuperación ante fallos del hardware o paradas programadas (vMotion, HA en VMware, Quick Migration en Hyper-V o XenMotion/HA en Xen), lo que garantiza un downtime mínimo (en caso de caída del host físico o contenedor) o desde el no impacto (en caso de vMotion o Xenmotion) hasta un downtime de entre 20-60 segundos (para Hyper-V) en el caso de tener que realizar una parada programada del hardware subyacente.

Otra ventaja del virtual desktop respecto a terminal services es que no requiere especialización para la administración del desktop: Un desktop virtual es, básicamente, un PC, con lo cual el conocimiento existente en gestión de desktops se reaprovecha, requiriendo sólo añadir la gestión del parque (provisionamiento, ciclo de vida, etc).

Por otro lado, Virtual desktop tiene la desventaja del coste inicial elevado de la implantación. En una visión superficial, el coste del desktop virtual puede parecer superior (y bastante) a cualquier otra solución, pero una visión detenida de aspectos como el de la seguridad del dato y la productividad asociada al desktop puede desvelar ahorros tanto económicos como en tiempo y productividad.