Manual de Arquitectura de QVD 4.2

El House Keeping Daemon es responsable de la gestión de estados de máquinas virtuales basándose en la información que se detecta dentro de la base de datos de QVD. El HKD periódicamente realiza encuestas a la base de datos para determinar el estado de cada máquina virtual. Si el estado ha sido cambiado por otro elemento tal como la herramienta de administración web o un usuario conectándose, el HKD es responsable de ejecutar los comandos apropiados para efectuar el cambio de estado.

Cuando QVD está configurado para la virtualización KVM, el HKD ejecuta una instancia KVM para cada máquina virtual que necesita ser iniciada, y ofrece opciones de inicio en base a la información obtenida de la base de datos.

Cuando QVD está configurado para LXC, el HKD revisará en primer lugar si el archivo de imagen se ha descomprimido en la carpeta basefs en el área de almacenamiento compartido, y descomprime el archivo de imagen, si es que aún no se ha hecho. El HKD a continuación, utiliza el módulo fuse-unionfs para llevar a cabo un montaje tipo bind de la imagen en la carpeta basefs con un sistema de archivos overlay que regenera de forma automática el sistema de archivos inicial. Este montaje se lleva a cabo dentro de la carpeta rootfs en el almacenamiento compartido. Por último, el HKD carga la imagen recién montada en una instancia LXC.

Cuando se inicia la instancia de máquina virtual, el HKD comprobará que arranque la imagen correctamente, que tiene conectividad de red y que el QVD-VMA se está ejecutando dentro de la máquina virtual. Si cualquiera de estas comprobaciones falla, el HKD bloqueará la máquina virtual dentro de la base de datos de QVD. Después de un corto período de tiempo, el HKD matará a la máquina virtual en ejecución.

Durante cada ejecución del bucle que el HKD realiza, va a comprobar el estado de todas las máquinas virtuales que se están ejecutando. Si en la base de datos hay cambios, los lleva a cabo de inmediato. Si no, actualiza la información de su estado en la base de datos.

De acuerdo con el diagrama de arriba, estos son ejemplos típicos de los diferentes estados de la máquina que el HKD volverá para una máquina virtual puesta en marcha mediante KVM.

En QVD, se reserva un rango de red (a elección del administrador) para las máquinas virtuales. Los nodos servidor deben estar conectados entre sí a través de este rango, es decir, deben tener una interfaz de red dedicada y conectada a él. Esta interfaz se utiliza para permitir al L7R encauzar conexiones de usuarios a las máquinas virtuales, y para permitir a las máquinas conectarse al mundo exterior (si se desea este comportamiento).

En general, es deseable que este rango se utilice en exclusiva para las máquinas virtuales. No obstante, el rango reservado para los nodos ( que es desde el principio del rango hasta donde configure el administrador ), puede dejar espacio para los servicios que el administrador considere necesarios en este rango.

Los nodos servidor, requieren de otra conexión a través de la cual se conectarán a la base de datos, y otros servicios, como el almacenamiento compartido o directorios ldap. QVD es totalmente independiente de la estructura de red en esta conexión, y queda supeditada a las necesidades del administrador.

Es posible también, utilizar técnicas más avanzadas como el vlan-tagging o virtual switching para utilizar un único puerto de red por nodo. Estas configuraciones son más complicadas, y quedan fuera de esta u otras guías que hemos publicado. Además, tampoco las recomendamos de cara a la estabilidad de la solución, ya que cruzar el tráfico de usuarios y base de datos podría dar lugar a problemas de conectividad y caídas de los nodos.

El Cliente QVD se conecta directamente al HKD. Este, hace un fork del proceso L7R, componente broker de QVD, que será el encargado de gestionar el resto de la comunicación con el cliente. El cliente inicia una conexión a través de HTTPS, en el que se solicita la presentación de credenciales HTTP de autenticación básica.

El L7R se conectará con la base de datos para determinar la forma de autenticación que debe tener lugar (es decir, a nivel local o usando un directorio LDAP externo) y tomar las medidas apropiadas para llevarlo a cabo. El L7R devolverá una respuesta HTTP OK si la autenticación se ha realizado correctamente, o devolverá un 401 no autorizado si falla la autenticación.

Una vez autenticado, el cliente solicita una lista de máquinas virtuales que están disponibles para el usuario. El servidor responde con una lista con formato JSON de identificadores de máquinas virtuales y su nombre correspondiente. El cliente selecciona una máquina virtual para conectarse y envía una solicitud GET con el identificador de la máquina virtual en una variable GET estándar. También pide una actualización del protocolo de QVD / 1.0 dentro de las cabeceras de petición HTTP.

El L7R lleva a cabo las medidas necesarias para asegurarse de que la máquina virtual está en marcha y en espera de las conexiones que utilizan el protocolo NX. Si la máquina virtual no se está ejecutando en un nodo servidor, se determinará en qué nodo que debe iniciarse en forma automática y arrancará una máquina virtual para ese usuario. En cualquier otro caso, el L7R determinará en qué nodo se está ejecutando la máquina virtual y reenviará todas las solicitudes a esta máquina para toda comunicación posterior, incluyendo la comprobación para ver que una sesión de NX se puede configurar. Durante este proceso, el L7R devolverá una serie de respuestas HTTP 102 que van indicando el progreso del arranque y conexión con la máquina virtual. Si la máquina virtual está disponible, el L7R establece una conexión con el nxagent que se ejecuta en la máquina virtual y se convierte en un canal de comunicaciones tipo proxy transparente para la sesión de NX. Una vez que la sesión está configurada, el L7R emitirá una última HTTP 101 (Protocolos de conmutación) de respuesta para el cliente, y el protocolo para todas las futuras interacciones con el cliente se actualizarán a NX, asegurado mediante SSL. El L7R actualiza la base de datos de QVD para establecer el estado de la máquina virtual para indicar que un cliente está conectado.

Desde este punto en adelante, todas las comunicaciones entre el cliente y la máquina virtual se llevan a cabo a través del protocolo NX a través de la L7R. Cuando el cliente se desconecta, el L7R actualiza la base de datos de QVD para representar el cambio en el estado de desconexión del usuario respecto a la máquina virtual.

El flujo del proceso se indica en el siguiente diagrama:

Como ya se ha mencionado, los nodos servidor están diseñados para un entorno con balanceo de carga. Con el fin de atender a esto, el elemento L7R de cada HKD es capaz de redirigir el tráfico de una determinada máquina virtual a cualquier otro nodo servidor en el entorno.

La configuración habitual es tal que una máquina virtual puede iniciar en cualquiera de los nodos servidor. Cuando un usuario se autentica mediante cualquier L7R dentro de la granja, el L7R determina en qué nodo servidor se está ejecutando actualmente la máquina virtual a la que el usuario desea conectarse. Esto se logra mediante una consulta a la base de datos. Si se detecta que dicha máquina virtual se está ejecutando en el entorno, la L7R redireccionará todo el tráfico hacia el nodo servidor adecuado.

Si ninguna máquina virtual se está ejecutando actualmente para el usuario, el L7R hace uso de un algoritmo interno para determinar el nodo más adecuado para iniciar una nueva máquina virtual para el usuario. Este algoritmo se basa en la evaluación de qué nodo tiene la mayor cantidad de recursos libres, calculado como la suma ponderada de memoria RAM libre, CPU sin uso, y un número aleatorio para conseguir un poco de entropía en el resultado.

Cuando un nodo apropiado ha sido seleccionado, la base de datos se actualiza de modo que una máquina virtual será iniciada por el HKD en el host correcto. El L7R entonces redirigirá todo el tráfico para esa conexión al nodo servidor que se ha seleccionado para ejecutar la nueva máquina virtual.

La API es un componente estructural de QVD. Consiste únicamente de una interfaz REST conectada a la base de datos. Es necesaria para poder gestionar la solución ya que es la única vía de comunicación de las herramientas de administración. Se puede utilizar también para integrar la solución con otros sistemas que sean capaces de utilizar la interfaz REST.

La herramienta en línea de comandos permite acceder a las mismas funciones que el WAT, pero en línea de comandos linux. Al igual que el WAT, es un cliente de la API, y no puede funcionar sin ella. Su uso es, por supuesto, más complejo que del WAT, y por ello queda probablemente limitada a su uso por parte de un administrador de sistemas. Por otra parte, al igual que la API, permite la integración con otros sistemas, ya que se puede utilizar para ejecutar tareas de forma programática. Su uso en crontab está especialmente indicado para programar distintos comportamientos que pueden ser deseables, como por ejemplo apagar automáticamente máquinas virtuales que lleven si uso cierto tiempo, borrado de información obsoleta, chequeos de configuración u obtención de informes.

El WAT es el panel de administración Web de QVD. Una herramienta web con la que se pueden gestionar usuarios, máquinas virtuales, nodos, imágenes y parámetros de configuración de QVD.

Para ello, mostrará en pantalla listados con los elementos del sistema con información suficiente para poder configurarlos así como detectar problemas. Dispone de controles de filtrado y multitud de acciones posibles sobre los elementos de QVD así como crear, actualizar o eliminarlas; y otras más específicas como arrancar o parar una máquina virtual, bloquear un usuario por tareas de mantenimiento, etc.

En la administración de QVD, el WAT corresponde a la parte de cliente, nutriéndose del servidor vía HTTP. De este modo extrae y gestiona la información de QVD a través de llamadas autenticadas a la API del servidor. Esta API también sirve a la aplicación de administración en línea de comandos (QVD CLI).

Para poder administrar correctamente una solución QVD, es importante conocer estos objetos de la base de datos y la relación entre ellos:

La DI, como su nombre indica, es una imagen de disco de un sistema operativo. El único requisito que tienen, es tener instalado y configurado el VMA y un escritorio linux estándar y compatible con la solución. Aparte de esto, los requisitos propios del tipo de imagen que sea ( KVM o LXC ).

El OSF es un conjunto de recursos que el administrador define para utilizar con un conjunto de imágenes (límites de memoria, disco y otras configuraciones). Cuando se da de alta una nueva DI, se le debe asignar un OSF al que pertenece. También se le pueden añadir tags personalizados, y si no la solución la etiquetará automáticamente. En breve veremos para qué sirve esto.

Al crear una máquina virtual para un usuario, también se le asigna un OSF. De esta manera, cuando se pone en marcha la máquina virtual, se carga dicho OSF y todos los parámetros de configuración asociados. Además del OSF, las máquinas virtuales también tienen tags asociados. Es mediante estos tags, que se decide cual de las DI asociadas al OSF se va a utilizar como imagen base de la máquina virtual.

La capacidad de etiquetar es importante, ya que permite cambiar fácilmente las versiones de imagen de disco para múltiples máquinas virtuales. Si se va a realizar un cambio en una imagen de disco que utiliza un gran número de usuarios, se puede gestionar el problema mediante etiquetas. El caso clásico es asignar una etiqueta temporal a la nueva imagen, que también tiene asignada en exclusiva una máquina virtual del administrador. Dicho administrador, puede de esta manera arrancar su máquina y comprobar que todo va en la nueva imagen como él espera. Si es así, el paso a producción es tan simple como cambiar la etiqueta de dicha DI a la que están utilizando las máquinas de los usuarios en producción. Si finalmente algo va mal, la reversión es tan simple como volver a cambiar la etiqueta a la anterior DI.

La etiqueta de la DI solo se comprueba en el momento del arranque de la máquina virtual. Esto quiere decir que las máquinas virtuales en ejecución no se van a ver afectadas por los cambios hasta que el usuario se desconecte. Para estos asuntos, las imágenes cuentan con tiempos de expiración soft y hard. La combinación de ambos se puede utilizar para notificar al usuario que su imagen ha sido actualizada y que debe desconectarse cuando pueda, y/o directamente obligarle a desconectarse apagando su máquina virtual.

Las ACLs son una nueva característica de QVD. En esta versión se ha programado un sistema de estricto control de acceso a los recursos de la solución. Para cada instalación se puede definir un listado de roles con una serie de permisos asignados, y relacionar los administradores con estos roles, de manera que puedan o no ejecutar cierto tipo de acciones. Este sistema de permisos tiene una gran granularidad y permite escalar la solución a un gran número de usuarios con permisos de administración.

Los roles son también una nueva característica de QVD. Permiten definir conjuntos de ACLs predefinidos, que se pueden asignar a los usuarios para facilitar la gestión de los permisos descritos en el apartado anterior.

Cada persona que vaya a acceder a la solución, necesita una cuenta de usuario. Estas cuentas se registran en la base de datos, con id, nombre de usuario y contraseña. Como el resto de objetos de la base de datos, se pueden etiquetar para tareas administrativas y scripts que automaticen tareas. Como nota, destacar que la contraseña guardada en la base de datos no tienen por qué estar en uso, si se está utilizando un plugin de autenticación ajeno a la solución (como sería la autenticación LDAP, por ejemplo).

A cada usuario, le corresponde una colección propia de máquinas virtuales. Para conectar, se le debe definir al menos una. Las máquinas virtuales, pertenecen a su vez a un único tipo de OSF, y también tienen como comentábamos antes una etiqueta. Cuando se pide a la solución que encienda la máquina virtual, se busca la imagen que corresponde a la etiqueta y OSF que están registradas para esa máquina virtual en la base de datos, y se utiliza para arrancarla.

Los nodos servidor QVD son a su vez un objeto en la base de datos. Se guarda de ellos su dirección ip y nombre (que debe corresponder al hostname definido en el fichero de configuración de cada uno de ellos). Al estar disponibles como objeto de configuración permiten gestionar su disponibilidad.