Consulta Técnica: View y Thin Clients

Nos pasan la siguiente consulta:

"Hola JL,

Estoy leyendo tu blog con mucho interés y tengo unas dudas sobre VDI.

Estoy viendo la posibilidad de implantar thin clients en mi empresa y me surge la siguiente duda:

Si pongo thin clients con windows embedded con el view client de vmware, necesitaré un antivirus para proteger los thin clients, ya que no dejan de ser unos mini-pcs con windows?

También he pensado en poner thin clients con linux, que suponemos que tienen el vmware-view-open-client, pero he visto que no soportan la redirección de USB, lo cual es un problema. Sabes si esto es así en estos clientes?

También he pensado en reutilizar los pcs actuales, quitandoles el HD y arrancando por PXE y ejecutando el cliente vmware-view-open-client desde una sesión de LTSP. ( https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall http://www.jaimebalmes.org/php/mod/resource/view.php?id=409 )

Por otra parte, qué platafoma de gestión nos recomiendas para gestionar los thin clients sena linux o windows?


Muchas gracias por tu tiempo.

Saludos."

Efectivamente. Si utilizas Thin clients basados en Windows XP (sea o no embedded) sigue siendo un Windows XP, eso sí, con menos "superficie" de exposición a virus y demás, lo que no implica que debamos prescindir del Antivirus, ya que en un entorno mixto, como dice el maestro Ros, la podemos liar parda. Por otro lado, un entorno de thin clients Linux nos obligará a prescindir de la redirección USB de View, olbligándonos a ir a productos de terceros, salvo que el fabricante disponga de licencia de VMware para la redirección de USB.

Mi recomendación sobre la plataforma de gestión de los Thin Clients es clara: Ninguna. Nunca he terminado de entender eso de migrar a Virtual Desktop para sustituir SMS o System Center por un Thin client management. El uso de clientes basados en linux o Windows obliga, en mayor o menor medida, a disponer de una plataforma de gestión de los mismos, y mi recomendación es que la gestión tire a inexistente. Es un hecho que la plataforma del Thin Client variará substancialmente su precio dependiendo de si el cliente corre o no Windows (Normalmente la gestión de clientes basados en Windows suele ser más cara e implica mayor nivel de gestión).

Tanto en un caso como en otro, el Thin Client puede convertirse en un punto de fallo dentro de la infraestructura View, ya que su propia "inteligencia" lo hace - eso sí, bastante menos - susceptible a fallos en los procesos de actualización y configuración.

Respecto a la opción de convertir PC's en Thin Clients, además de la que comentas (LSTP), dispones de Thin Station, una minidistribución altamente configurable, que incluso dispone de configuradores Web donde "montarte" tu cliente ligero desde ella (los TS-O-MATIC). En el mirror de Dinamarca (DK) incluso te permite integrar el cliente View de VMware. Estos ts-o-matic te permiten crear desde imágenes ISO a imágenes PXE para el arranque. Recomiendo fervientemente esta distribución como iniciación de bajo o nulo coste al mundo del Virtual Desktop.

Si lo que buscas es una solución robusta, sin intervención en el thin client del usuario, que permita redirección USB, compatibilidad con VMware View, en la que despreocuparte ABSOLUTAMENTE del dispositivo y a un coste unitario realmente interesante, te recomiendo los SUN Ray de SUN Microsystems. En mi compañía (y en varios clientes) tenemos la solución funcionando en menos de dos horas. Es realmente elegante y ciertamente potente. Las características incorporadas en la versión 5 (aceleración multimedia, aceleración flash, USB Mapping) junto con las ventajas de siempre (hot desking, multiple monitors - hasta 8, creo recordar) hacen de SUN Ray, al menos para mí, la solución Thin client perfecta. Por no necesitar, no necesitan IP del entorno corporativo. El terminal SUN Ray (DTU para los amigos) es simplemente eso: Un terminal del servidor SUN Ray. Las conexiones con los virtual desktop se realizan desde este, y no desde el terminal, es decir, el SUN Ray client no es más que una pantalla y un teclado extra del servidor SUN Ray (que puede correr tanto en Solaris como en Linux). Te invito a verlo cuando quieras.

Un cordial saludo.

Nota Técnica: VMware View Open Client

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

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

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

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

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)

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.