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!
No hay comentarios:
Publicar un comentario