martes, 24 de enero de 2012

SPICE - Una introducción para entenderlo

(Artículo publicado en la revista Tuxinfo: http://www.tuxinfo.com.ar )



    Ya hemos hablado, en varias oportunidades, sobre formas de virtualizar servidores. También hemos abordado los temas relativos a la virtualización de escritorios. Alguna vez hablamos de computación en la nube, y nos maravillamos por la forma en la que este concepto evoluciona y se aplica, cada día, a más elementos que hasta ahora acostumbrábamos usar en forma local. Y es en este tópico en particular donde nace una nueva forma de exportar las interfaces gráficas de los escritorios para alimentar clientes delgados, o PCs que ya no tienen la potencia necesaria para funcionar por sí solas. SPICE, un acrónimo de “Simple Protocol for Independent Computing Environment”, será el invitado de honor de este artículo.

    Hoy nos pondremos a analizar SPICE, que está emergiendo como una tecnología alternativa, pero altamente mejorada, a los sistemas de escritorios exportados por la red, y que se perfila para ser, en un futuro cercano, el protocolo elegido cuando se deseen las mejores prestaciones en lo que a integración, velocidad y gestión de audio y video refiere.


Dos se vuelven uno


    SPICE fue originalmente desarrollado por la empresa Qumranet, quien en su época de independencia corporativa se dedicaba a desarrollar entornos de virtualización de escritorios basados en el uso de KVM (Kernel Virtual Machine). Suena bastante lógico que esta empresa haya trabajado sobre este protocolo si tenemos en cuenta que fueron ellos mismos los que crearon y mantuvieron el mismísimo hipervisor KVM, que hoy en día podemos ver en sistemas operativos GNU/Linux y hasta en OpenIndiana gracias a los aportes y el desarrollo de la empresa Joyent.

    Este producto resultó como un subconjunto de su idea original, Solid ICE, que en su momento parecía estar posicionándose como el producto de virtualización de escritorios por excelencia, dado que entregaba sus interfaces mediante el uso de una interfaz web, o un pequeño cliente delgado. Como todos nos podemos imaginar, ICE es parte del nombre SPICE, justamente por ser el acrónimo de “Independent Computing Environment”.



    Y como muchas veces pasa en el mundo corporativo, esta pequeña empresa israelí que armaba soluciones de código cerrado para GNU/Linux fue comprada en el año 2008 por Red Hat, quien un tiempo después integró su cartera de productos con los que Qumranet poseía. Por supuesto, abrió su código a las comunidades, permitiéndoles alimentarlo y acrecentarlo para llegar a ser lo que es ahora.


Lo que pensamos que es

    Así es que SPICE es una solución de computación remota que provee a sus clientes acceso a sus entornos gráficos y dispositivos (teclado, mouse, micrófono, parlantes, etc.). Logra una experiencia similar a la que se tiene cuando se interactúa con una máquina local gracias al uso de un sistema de análisis de potencia que dependiendo de lo que se posea del lado del cliente puede bien enviar comandos para generar (render) los gráficos del lado del cliente, si éste tiene suficiente potencia, o puede procesar y sólo enviar los elementos necesarios para dibujar pantallas del lado del cliente, si el cliente tiene poco poder de procesamiento.

    A diferencia de los protocolos de presentación remota de escritorios, tales como RDP, VNC o ICA, SPICE se presenta como una arquitectura basada en varias capas que interactúan para mejorar la experiencia del usuario. Estas capas son:

SPICE Driver: Es un componente que se encuentra en cada escritorio virtual. Un escritorio virtual es una de las máquinas virtuales que se podrá generar partiendo de un hipervisor como lo es, efectivamente, KVM.
SPICE Device: Es éste el componente existente en el entorno de virtualización en sí mismo, como ser un hipervisor.
SPICE Client: Este componente reside del otro lado de esta relación, es decir, en el cliente delgado, PC a punto de ser tirada a la basura por vieja, o el navegador. A través de esta capa se accede a cada escritorio virtual.

    Desde el punto de vista de la arquitectura, SPICE está compuesto por el protocolo SPICE, el servidor SPICE, y el cliente SPICE. Sus capas de “Driver” y “Device” serán entregadas por un dispositivo QLX y un driver QLX, respectivamente. El dispositivo QLX se encuentra en el paquete de virtulización “qemu”, y el driver QLX en el mismo sistema operativo que exporta su interfaz gráfica.



    Cuando un cliente se conecta a un servidor SPICE, lo hace a través de canales. Cada tipo de canal está dedicado a un tipo de datos en particular. Usa su propio socket, y puede estar encriptado utilizando SSL. Del lado del cliente cada canal será manejado por un hilo de procesamiento separado (thread), lo que nos permitirá definir valores que gestionen el nivel de rendimiento de nuestros escritorios. Si quisiéramos, podríamos aplicar QoS (Quality of Service) a cada thread, y entonces modificar su grado de precedencia dentro del sistema operativo.

    El canal principal se llama “RedClient” y es el responsable de controlar todos los demás. Parte de este control es la creación de canales, su conexión y desconexión, entre otros.

    Entre los demás canales encontramos:

Main: Este canal está implementado por RedClient.
DisplayChannel: Es el responsable de gestionar los comandos gráficos, así como las imágenes y los flujos de video.
InputsChannel: Es quien gestiona la entrada por teclado y mouse.
CursorChannel: Es el que maneja la posición y visibilidad del cursor.
PlaybackChannel: Para nuestra grata alegría, este canal maneja la forma en la cual el servidor envía audio y video al cliente de forma tal de permitir ver, por ejemplo, videos en forma remota con prácticamente ningún tipo de retardo.
RecordChannel: Es el encargado de capturar audio y video del lado del cliente, y enviarlo al servidor.

    A diferencia de otros protocolos que envían al cliente actualizaciones de frame-buffer, SPICE envía comandos de gráficos 2D, y hasta 3D, si bien este último aún no está listo. Media hora de horno, y lo podremos disfrutar.


Algo un poco divertido

    Veamos, entonces, la forma en la que se establece una conexión entre un cliente y un servidor de SPICE.

    El proceso de conexión de canales es iniciado por el cliente. Éste envía un mensaje (RedLinkMess) al servidor. Entonces, el servidor responde con otro mensaje (RedLinkReply). Cuando el cliente recibe el RedLinkReply examina su código de error, y actúa en consecuencia. En el caso de no haber un código de error (porque no han habido errores) encripta su contraseña utilizando la clave pública que le envió el servidor dentro del mensaje RedLinkreply y se lo envía al servidor. Entonces el servidor recibe la clave, y envía un mensaje más con el detalle del enlace que el cliente debe utilizar. El cliente examina el link, y si es adecuado (se verifica que su código de error coincida con el que el cliente posee) se establece una conexión válida. No es tan terrible, y ocurre en una fracción de segundo.

    Si alguna vez hemos viajado en un autobús (colectivo para mis paisanos) sabemos que de tanto en tanto hemos prestado nuestro boleto a un inspector que nos lo solicitaba para saber si habíamos pagado o no. Si habíamos pagado, todos felices. Si no habíamos pagado, bueno, nos bajaban del autobús, generalmente acompañados de algún vocablo o frase mundana que evocaba a un pariente cercano nuestro.
   
    SPICE también tiene una forma de controlar boletos (tickets) a través de su sistema de ticketing. Este sistema es la forma que tiene SPICE para asegurarse que el cliente que está sólicitando la conexión es una fuente confiable. El servidor logra esto generando un ticket que contiene una clave y un tiempo de expiración. Cuando el tiempo de la conexión supera este valor, el ticket completo expira.

    Este ticket se encontrará encriptado generando una clave RSA de 1024 bits cuya porción pública es enviada al cliente mediante el mensaje RedLinkInfo. El cliente utiliza esta clave para encriptar la contraseña y enviarla de vuelta al servidor a través del mensaje recién comentado, RedLinkMess. Entonces el servidor desencripta la contraseña, la compara con el ticket, y se asegura que se ha recibido dentro del período de tiempo establecido.

    Para hacer corta una historia larga, SPICE implementa una forma de comunicación muy parecida a la que tiene el mismísimo protocolo TCP/IP, con formatos propios de ping, por ejemplo.


Moverse

    Hasta ahora nos hemos focalizado en el caso de tener un servidor y un cliente. Pero ¿qué pasaría si un servidor se debe sacar de línea, o si sencillamente se cae, producto de un mal funcionamiento? Todo está pensado en el protocolo SPICE, y para casos como estos, tenemos a nuestra disposición un conjunto de mensajes que nos permitirán migrar la sesión desde un servidor a otro.

    Principalmente, se comenzará enviando mensajes para que se migran los canales de mensajes que el cliente se encuentra utilizando, y que por lo tanto están abiertos. El canal principal será el que utilizará para iniciar el proceso de migración de canales cuando el servidor envía un mensaje al cliente. Entonces éste examina sus componentes, y envía una respuesta al servidor.

    Entonces es que el cliente comienza a utilizar los canales de comunicación con el servidor de destino, desafectando de esta responsabilidad al servidor de origen. Así de sencillo es que una sesión pase de un servidor a otro.

    Si pensamos en un esquema de computación en la nube, donde no hay uno, sino cientos de servidores funcionando como si fueran uno solo, veremos que este mecanismo es extremadamente útil, ya que nos permite balancear la carga de las conexiones entre los diferentes servidores sabiendo que existe la posibilidad de mover sesiones desde un servidor a otro sin generar inconvenientes en el cliente, entregándole una sensación de continuidad muy buena.

    Y por supuesto, dado que uno de los usos del sistema de escritorios virtualizados es el de alimentar soluciones de recuperación ante desastres, encontramos en SPICE una excelente opción para entregar escritorios remotos aún cuando un centro de cómputos entero se destruya, pasando a otro centro de cómputos alternativo sin que el cliente note la diferencia.



Si te querés divertir

    Para finalizar este artículo sobre las bondades del sistema SPICE, abordaremos un tema que ha dejado con la boca abierta a muchas personas. Es la capacidad de manejar video y audio en forma remota prácticamente sin retardo entre el servidor y el cliente, inclusive sobre redes WAN como lo es internet.

    SPICE ofrece muchos mecanismos diferentes de compresión de imágenes que se pueden elegir en el momento de inicializar el servidor, y dinámicamente mientras éste está funcionando. Un método propietario de SPICE es el denominado Quic, basado en el algoritmo SFALIC.

    Como siempre, SFALIC es un acrónimo que significa “Simple Fast and Adaptive Lossless Image Compression”. Resulta que este algoritmo ha sido diseñado, desde su base, para entregar compresión a velocidades elevadísimas. Se basa en predicción lineal, y un método de modelado predictivo de control de errores. Por lo tanto, Quic tendrá un manejo predictivo para el envío de imágenes, permitiendo entonces entregar video por medio de redes WAN con un nivel increible de velocidad y exactitud.

    Otra opción de compresión es LZSS, o su pariente, el Global LZ (Lempel Ziv), o GLZ, que gestiona cambios en las imágenes para enviar comandos de renderización al cliente. Sin meternos en demasiados detalles, GLZ es un algoritmo que analiza las repeticiones de ocurrencias dentro de una cadena de audio, por ejemplo, y las parametriza para evitar el envío redundante de información.

    Imaginemos este último como si escucháramos una canción de discoteca, donde por media hora se escucha el mismo ritmo, las mismas meoldías y el mismo estribillo por períodos de un minuto y medio. No tendría sentido enviar por red media hora de sonidos, si se puede enviar sólo un minuto y medio, y luego un parámetro que especifique la cantidad de veces que se debe repetir. Lo mismo para el video, y así tenemos como resultado un sistema de audio y video bidireccional de alta velocidad.


Conclusión

    Hemos metido nuestra nariz en el protocolo SPICE, y nos hemos enterado que el mundo no termina donde VNC, RDP o ICA nos han dejado. Encontramos que este protocolo, que está en plena producción para entornos virtualizados de escritorios, está siendo mejorado para que se comporte y se maneje de la misma forma en la que hoy usamos VNC, por sólo citar un ejemplo de notable simplicidad.

    Esperemos ver en breve estas implementaciones funcionando en nuestros servidores. Como hacemos en estos casos, no podemos sino sacarnos el sombrero ante tan buen producto ;-) . ¡Nos vemos el mes que viene!


Sobre la originalidad y la reacción

Hace ya un buen tiempo tuve este debate con alguien. Ya ni recuerdo qué lo disparó, pero recuerdo haber hablado de esto. No sé si fue alguna medida internacional de esas que nos dejan boquiabiertos, o alguna otra cosa.
La cosa es que, con todo el tema de SOPA y PIPA, otra vez hablamos de estos temas.
Cuando menos nos lo esperábamos, nuevamente apareció la amenaza de tener un Internet censurado. Y no fue sólo una amenaza, ya que algunos sitios, como es el caso de Megaupload, fueron cerrados por el gobierno de un país diferente del mío. No quiero decir con esto que las decisiones de mi gobierno siempre representan mi pensaniento...
Como nota de color, cito un diario de mi tierra que decidió hablar de Anonymous y Sony, aún luego de haber declarado, el mismo Anonymous, que en ESE caso sí no tenía nada que ver. No hay nada que hacer. El que nació para clarinete no llega a saxofón. No tiene nada que ver, pero leyendo sobre SOPA y PIPA en ese diario me encontré con eso. Me hizo reir un rato.
La cuestión es que generalmente nos encontramos ante actitudes desmesuradas por parte de algunas entidades no representativas, o al menos no para nosotros, que apuntan a defender a quien le da de comer. Ante eso, tenemos dos posibilidades. Una es demostrar que podemos también darles de comer (no, no me gusta esa opción), y la otra es reaccionar en consecuencia.
Claro está, todo tipo de reacción es eso: una respuesta a la acción original de alguien o algo.
Entonces, mi idea es bien sencilla, y se basa justamente en la originalidad. Es decir basta a todo este juego de reacciones, y comenzar a tener acciones originales, que apunten al beneficio de la comunidad informática en general, y a la libertad de que gozamos.
Entonces, eso implicaría una nueva organización que esté completamente de espaldas al esquema de control por parte de entidades como aquellas de que hemos tenido tristes noticias últimamente, manejada por personas que sí se interesen en lo que esta tecnología (léase: ideología) tiene para ofrecer.
Hay un millón de cabos sueltos en este esquema de originalidad, así que agradeceré que los que lean esto le pongan y agreguen los pensamientos que se les crucen, ya que mi cabeza está explotando de repentinas ideas viejas, pero muy renovadas.
Salutte!

sábado, 7 de enero de 2012

Otra vez VirtualBox

Como lo hago siempre luego de instalar un nuevo sistema operativo en mi máquina, me decidí a agregar el repositorio para que me funcione el YUM de mi Fedora 16 con VirtualBox, y así poder revivir mis máquinas virtuales.
Luego de la instalación del repo y de VirtualBox, en lo que no voy a ahondar porque no tendría sentido considerando que está más que claro en el mismo sitio virtualbox.org, me dispuse a instalar el tan querido Extension Pack de VirtualBox para tener RDP, USB, y algún que otro beneficio en las máquinas virtuales.
Pero la sorpresa no fue muy agradable cuando me encontré con el mensaje "Failed to install the Extension Pack The installer failed with exit code 127: The value for the SHELL variable was not found the /etc/shells file".
Más abajo menciona algo sobre que el incidente ya ha sido reportado.
Así que hurgando por la red me encontré con que en un sistema recientemente implementado se debe instalar, primero, todo el kit de compilación de kernel, y el dkms.
Allá vamos, ejecuté, como root:


# yum install dkms binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel

No fue tan terrible, sólo 28 MB de binarios debieron bajar a mi máquina. Entonces nuevamente fui a la carga haciendo doble click en el ícono correspondiente al Extension Pack. Pero nada, el mismo error de antes.
Mirando un poco el comando VBoxManage me encontré con un hermoso parámetro, justamente el "extpack". Efectivamente, era lo que estaba buscando.
No tuve más que ejecutar:

$ VBoxManage extpack install --replace /home/hecsa/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack 
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (3.1.6-1.fc16.x86_64) or it failed to
         load. Please recompile the kernel module and install it by

           sudo /etc/init.d/vboxdrv setup

         You will not be able to start VMs until this problem is fixed.
0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to install "/home/hecsa/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack": The installer failed with exit code 127: The value for the SHELL variable was not found the /etc/shells file

VBoxManage: error: This incident has been reported.

Bueno, otra vez lo mismo, pero esta vez en modo texto.
Lo hice sencillo, confié en la lógica de los mensajes, y por ende de los programadores de este excelente producto, y me decidí a rebootear el sistema para poder tener el módulo compilado. Pero antes, me dije a mí mismo "no será que algún programador, quizá, no es tan brillante como mi cerebro opina, y se olvidó de verificar si quien lo ejecuta es root?", e hice lo mismo como ese usuario, y no como el mío, hecsa.
El resultado fue interesante:

# VBoxManage extpack install --replace /home/hecsa/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (3.1.6-1.fc16.x86_64) or it failed to
         load. Please recompile the kernel module and install it by

           sudo /etc/init.d/vboxdrv setup

         You will not be able to start VMs until this problem is fixed.
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Successfully installed "Oracle VM VirtualBox Extension Pack".

Si bien me dispuse a rebootear mi maquinilla, me puse a pensar que los programadores se equivocaron en varias cosas:
- Se olvidaron de verificar si el usuario que ejecuta esto tiene permisos de root o no.
- Dicen que no se podrá levantar ninguna VM, pero no es así, dado que sí levantan, pero sin el Extension Pack, al menos hasta que rebootee. Pero luego del reboot, la gran sorpresa: las máquinas virtuales aún no levantaban el USB.
Bien, seguí las instrucciones de ejecutar:

# /etc/init.d/vboxdrv setup

...y luego volví a probar suerte...pero sin suerte. Los USB aún no se ven, y probaré volver a bootear para ver si ahora sí los levanta.
Luego del reboot, ejecuté de nuevo:


# VBoxManage extpack install --replace /home/hecsa/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Successfully installed "Oracle VM VirtualBox Extension Pack".

Wow! Sin erorres! Pero nada es tan bello, el sistema sigue sin reconocer el subsistema USB.
La frustración no tiene límites...qué quieren que les diga...esto con Sun no pasaba...

[ACTUALIZACIÓN - GRACIAS SALVA!!!]
No olviden agregar Vuestro usuario al grupo vboxusers, de esa forma al reloguearse todo vuelve a estar en su lugar, y el error desaparece.