Título: Virtualización de escritorios empleando

i

, junio del 2019

Departamento de Electrónica y Telecomunicaciones

Título: Virtualización de escritorios empleando herramientas de

software libre

Autor: Leandro Lemos Darias

Tutores: Ing. Ernesto Pérez Peláez

ii

Department of Electronics and Telecommunications

Title: Desktop virtualization using free software tools

Author: Leandro Lemos Darias

Thesis Director: Ing. Ernesto Pérez Peláez

, june 2019

iii

Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central

“Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad

de Ingeniería en Automática, autorizando a que el mismo sea utilizado por la Institución,

para los fines que estime conveniente, tanto de forma parcial como total y que además no

podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.

Firma del Autor

Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de

la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un

trabajo de esta envergadura referido a la temática señalada.

Firma del Tutor Firma del Jefe de Departamento

donde se defiende el trabajo

Firma del Responsable de

Información Científico-Técnica

iv

Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu” de

Las Villas, y se encuentra depositado en los fondos de la Biblioteca Universitaria

“Chiqui Gómez Lubian” subordinada a la Dirección de Información Científico Técnica

de la mencionada casa de altos estudios.

Se autoriza su utilización bajo la licencia siguiente:

Atribución- No Comercial- Compartir Igual

Para cualquier información contacte con:

Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de

Las Villas. Carretera a Camajuaní. Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54 830

Teléfonos.: +53 01 42281503-1419

v

PENSAMIENTO

“Si no trabajas por tus sueños, alguien te contratara para que trabajes por los suyos”

Steve Jobs.

vi

DEDICATORIA

Quiero dedicar este trabajo a mis padres y esposa; por su sacrificio y entrega.

Por haberme apoyado en los momentos más difíciles.

A mi hijo, esperando que un día te sientas orgulloso de mí.

A todos, gracias, los amo.

vii

AGRADECIMIENTOS

A todos eso buenos amigos de la manada con los que pase tantos momentos.

Pero en especial a Ernesto pues sin su apoyo no lo hubiera podido lograr.

En general a todas aquellas personas que de una forma u otra me brindaron su mano.

A todos muchas gracias, los quiero.

viii

TAREA TÉCNICA

1. Análisis de las soluciones de infraestructuras de virtualización de escritorios para

Linux disponibles en el mercado actual para entornos empresariales.

2. Descripción de los elementos y conceptos fundamentales relacionados con la

plataforma seleccionada para la virtualización de escritorios.

3. Realizar un diseño, implantación y despliegue de la infraestructura de virtualización

de escritorios en el entorno de la Universidad Central Marta Abreu de “Las Villas”.

4. Evaluación de los resultados de la infraestructura implementada en diferentes

escenarios de producción.

5. Elaboración del informe del trabajo de diploma.

Firma del Autor Firma del Tutor

ix

RESUMEN

Desde hace años, el entorno tradicional de las redes corporativas se ha desarrollado sobre

una infraestructura en la que cada usuario poseía su propio ordenador, totalmente dedicado

y conectado a la red. Todos los usuarios y dispositivos eran administrados por el personal

TI, necesario para gestionar las diferentes configuraciones, licencias y actualizaciones de

cada equipo. Es en este marco donde encajan a la perfección las infraestructuras de

escritorios virtuales (Virtual Desktop Infraestructure, VDI) que hace referencia al uso de

"equipos de escritorio virtualizados" alojados de forma centralizada en un servidor. De este

modo, el equipo de escritorio del usuario consiste en una imagen de pantalla en la estación

de trabajo, mientras que los archivos, datos y aplicaciones se almacenan y administran

desde un servidor central.

Con el amparo de la experiencia previa de la Universidad Central Marta Abreu de “Las

Vilas” (UCLV) en el despliegue de una infraestructura Linux, en este trabajo se aborda la

temática de la virtualización de escritorios, primero desde un punto plenamente teórico y

genérico para sentar unas bases mínimas, para posteriormente tratar una parte práctica

cuyos principales objetivos son: el análisis de las posibles soluciones VDI para escritorios

Linux disponibles en el mercado actual, la selección de aquella más adecuada al entorno de

la UCLV, la realización del diseño, la implantación y despliegue de la infraestructura en el

entorno corporativo real de la Universidad Central. Todo ello, desde la perspectiva de un

proyecto piloto que permitirá, en un futuro cercano, cubrir y completar las necesidades de

la comunidad universitaria.

Palabras clave: Virtualización, Escritorios, Linux, QVD, VDI.

x

TABLA DE CONTENIDOS

PENSAMIENTO ................................................................................................................... iv

DEDICATORIA .................................................................................................................... vi

AGRADECIMIENTOS ....................................................................................................... vii

TAREA TÉCNICA ............................................................................................................. viii

RESUMEN ............................................................................................................................ ix

TABLA DE CONTENIDOS .................................................................................................. x

INTRODUCCIÓN ............................................................................................................... xiv

CAPÍTULO 1. INFRAESTRUCTURA DE VIRTUALIZACION DE ESCRITORIOS. 17

1.1 Virtualización .............................................................................................................. 17

1.1.1 Conceptos básicos ........................................................................................... 17

1.2 Tipos de virtualización ................................................................................................ 20

1.2.1 Virtualización de plataforma .......................................................................... 20

1.2.2 Virtualización de recursos .............................................................................. 22

1.2.3 Virtualización de aplicaciones ........................................................................ 23

1.2.4 Virtualización de escritorios ........................................................................... 24

1.3 Virtualización de escritorios o VDI ............................................................................. 24

1.3.1 Conceptos básicos ........................................................................................... 26

1.4 Comparativa de productos ........................................................................................... 26

1.4.1 Comparativa de plataformas de escritorios virtuales ...................................... 27

1.5 Solución a implementar ............................................................................................... 30

1.6 Que es QVD ................................................................................................................ 32

1.6.1 Componentes principales ................................................................................ 34

xi

1.6.2 Componentes secundarios ............................................................................... 35

1.7 Conclusiones del capítulo ............................................................................................ 36

CAPÍTULO 2. METODOLOGÍA DE INSTALACIÓN Y ADMINISTRACIÓN DE

QVD. 37

2.1 QVD (Quality Virtual Destokp) ................................................................................. 37

2.1.1 Instalación y configuración de QVD ................................................................... 39

2.1.2 Hardware del Sistema .......................................................................................... 40

2.1.3 Interfaz de red ...................................................................................................... 41

2.2 Instalación y configuración de QVD DB .................................................................... 42

2.2.1 Instalacion de QVD DB ....................................................................................... 42

2.2.2 Creación de una cuenta de usuario ...................................................................... 43

2.2.3 Creación de la base de datos QVD ...................................................................... 43

2.2.4 Cambiar la configuración de PostgreSQL ........................................................... 43

2.2.5 Configuración básica ........................................................................................... 44

2.2.6 Instalación de las tablas de QVD ......................................................................... 45

2.3 Instalación y configuración del nodo .......................................................................... 46

2.3.1 Instalación de HKD y herramientas de administración ....................................... 46

2.4 Configuración básica e indispensable de administración de QVD ............................. 49

2.4.1 Requisitos de red .................................................................................................. 50

2.4.1.1 Establecer dnsmasq para ser controlado por QVD ................................. 50

2.4.1.2 Configurar el reenvío IP ............................................................................. 51

2.4.1.3 Configurar un puente de red ..................................................................... 51

2.4.1.4 Configurar QVD para su red ..................................................................... 52

CAPÍTULO 3. OPERACIÓN DEL SISTEMA ............................................................... 54

3.1 Pruebas de funcionamiento ......................................................................................... 54

xii

3.2 Optimización del sistema ............................................................................................ 57

3.2.1 Autenticación externa ..................................................................................... 57

3.2.1.1 Configuración LDAP ............................................................................. 58

3.2.2 Auto provisión ................................................................................................ 59

3.2.2.1 Configuración de auto provisión .......................................................... 59

3.2.3 Almacenamiento compartido .......................................................................... 59

3.2.3.1 Directorios afectados ............................................................................. 60

3.2.3.2 Selección de la tecnología ...................................................................... 61

3.2.3.3 Diseño e implementación del almacenamiento compartido ............... 61

3.2.3.4 Configuración del almacenamiento compartido: NFS ....................... 62

3.2.4 Balanceador de carga ...................................................................................... 63

3.2.4.1 Configuración del balanceador de carga ............................................. 64

3.2.5 Configuracion SSL ......................................................................................... 64

3.2.6 Componentes hardware ................................................................................... 66

3.2.7 Politica de copia de seguridad ........................................................................ 66

3.2.7.1 Backup de los servidores ....................................................................... 67

3.2.7.2 Backup de las configuraciones ............................................................. 67

3.2.7.3 Backup de las tablas de la base de datos ............................................. 69

3.2.7.4 Backup del almacenamiento compartido ............................................ 69

3.2.8 Mejoras futuras ............................................................................................... 69

3.3 Conclusiones del capítulo ............................................................................................ 70

CONCLUSIONES Y RECOMENDACIONES ................................................................... 71

Conclusiones ..................................................................................................................... 71

Recomendaciones ............................................................................................................. 71

xiii

REFERENCIAS BIBLIOGRÁFICAS ................................................................................. 73

ANEXOS .............................................................................................................................. 76

Anexo I Configuración del complemento Kafka en Thingsboard. ................................... 76

Anexo II Código del archivo built.sbt. .............................................................................. 76

Anexo III Código de la aplicación. .............................................................................. 79

GLOSARIO .......................................................................................................................... 81

xiv

INTRODUCCIÓN

Durante décadas, los entornos corporativos se han desarrollado sobre una infraestructura en

la que cada usuario hacía uso de su propio equipo dedicado, con aplicaciones propias y

datos almacenados localmente. Los usuarios, normalmente eran administrados desde un

servidor en red, siendo el personal de gestión TI el encargado de mantener todos estos

equipos; licencias, actualizaciones y configuraciones prácticamente de forma

independiente. La evolución virtual en la actualidad genera mayor grado de interés entre el

círculo empresarial, es así que cada día se vincula un mayor número de empresas a este

patrón global, incluyendo recursos en sus departamentos de Tecnología de la Información

(TI).

La incorporación de herramientas tecnológicas genera muchas ventajas ya que la tecnología

ofrece múltiples soluciones con reducción de procesos y optimización de recursos dentro de

las organizaciones empresariales, como por ejemplo el ahorro de energía, administración

centralizada de equipos, puestos de trabajo móviles, entre otros.

El continuo avance de las tecnologías y las necesidades cada vez mayores por parte de los

usuarios, impulsaron a las organizaciones a considerar opciones informáticas más

eficientes, más sencillas, autónomas y seguras. Nacen las plataformas de Virtualización de

Escritorios (Virtual Desktop Infraestructure).

Al implementar soluciones tecnológicas en las empresas, uno de los principales factores de

análisis es la inversión que debe afrontarse; sin embargo, con el desarrollo de escritorios

virtuales a bajo costo se brinda una oportunidad para que las pequeñas y medianas

empresas tengan la capacidad de mejorar sus procesos e incrementar la calidad de sus

servicios. La ejecución del presente estudio de evaluación se justifica en tal sentido ya que

se tiene como tarea el desarrollo de un servicio de nube para escritorios virtuales,

optimizando costos de software y entregando al usuario la garantía de contar con una

tecnología probada, estable, eficiente y portable.

En consecuencia, se aporta con opciones tecnológicas estables para la generación de

escritorios y aplicaciones virtuales con software libre, que permiten una conexión segura

desde cualquier dispositivo móvil o de escritorio, para comenzar, desde cualquier lugar

xv

dentro del campus universitario; además, para determinar la evaluación de uso de un

sistema de este tipo, es indispensable realizar un estudio para determinar las características

tecnológicas actuales sobre las cuales las pequeñas y medianas empresas tienen acceso,

para brindar una solución tecnológica que contribuya con una funcionalidad adaptable a la

prestación óptima de sus servicios.

Tomando en cuenta estos antecedentes, para el presente trabajo de diploma se define el

siguiente problema de investigación:

¿Cómo implementar una plataforma de virtualización de escritorios remotos en el

Centro de Datos de la UCLV?

Del problema anteriormente planteado surgieron las siguientes interrogantes científicas:

1. ¿Hacia dónde está dirigido el desarrollo de la virtualización de estaciones de trabajo

que requiere una inmediata implementación en el centro de datos de la UCLV para

el beneficio de los usuarios finales?

2. ¿Qué técnicas de virtualización de escritorio están disponibles para el uso del

software como demanda y cuál sería la más adecuada para el montaje real de la

plataforma?

3. ¿De qué forma se deben organizar y estructurar los escenarios de virtualización de

estaciones de trabajo para incrementar la productividad y cumplir con las

características principales de un puesto de usuario en diferentes entornos?

4. ¿Cómo proporcionar al departamento de las TI las herramientas necesarias para

gestionar y controlar la plataforma de una manera eficiente?

Objeto de la Investigación: Virtualización de Escritorios Linux.

Campo de Investigación: Infraestructura de virtualización de escritorios con QVD (Quality

Virtual Destokp).

En este trabajo de diploma se plantea como objetivo general, implementar una plataforma

de virtualización de escritorios utilizando herramientas de código abierto.

Para dar cumplimiento al anterior objetivo, el mismo se ha subdividido en los objetivos

específicos siguientes:

xvi

1. Caracterizar la información de los tipos de virtualización existentes vinculados a los

escritorios de trabajo.

2. Comparar las principales plataformas de virtualización de escritorios existentes.

3. Instalar y configurar una plataforma de virtualización de escritorios empleando

herramientas de código abierto.

4. Implementar diferentes escenarios de escritorios virtualizados utilizando diferentes

perfiles de usuarios.

5. Evaluar el desempeño operacional de la plataforma para constatar la propuesta de

virtualización de escritorios.

Organización del Informe

Este trabajo queda estructurado de la siguiente manera: introducción, capitulario,

conclusiones, referencias bibliográficas, bibliografía y anexos.

En la introducción queda definida la importancia, actualidad y necesidad del tema que se

aborda y se hace alusión a los elementos del diseño teórico.

El Capítulo 1 se dedica a la caracterización de los tipos de virtualización existentes

vinculados a los escritorios de trabajo y al estudio comparativo de las soluciones de

virtualización de escritorios que se usan en la actualidad.

El Capítulo 2 aborda el diseño y despliegue de una plataforma de escritorios virtualizados

utilizando herramientas de código abierto.

En el Capítulo 3 se realizan todas las pruebas necesarias para comprobar el funcionamiento

de la solución de virtualización de escritorio para un entorno de producción.

CAPÍTULO 2. METODOLOGÍA DE INSTALACIÓN Y ADMINISTRACIÓN DE QVD 17

CAPÍTULO 1. INFRAESTRUCTURA DE VIRTUALIZACION DE

ESCRITORIOS.

Múltiples usuarios de una red pueden mantener de forma independiente sus escritorios

individuales en un único servidor, habitualmente localizado en un Centro de Datos. Los

usuarios pueden conectarse a su escritorio mediante una red de área local (LAN), mediante

una red de área extensa (WAN) o a través de Internet. Una infraestructura de servicio de

virtualización de escritorios encarga de realizar esta función.

El presente capítulo se sintetiza la información referente a los tipos de virtualización

existentes vinculados a los escritorios de trabajo y se realiza un análisis comparativo de las

principales plataformas de virtualización de estaciones que existen.

1.1 Virtualización

Se puede definir virtualización de infraestructuras como la abstracción o multiplexación

lógica de una infraestructura física. Técnicamente, la virtualización permite ocultar los

recursos físicos reales de las aplicaciones, servicios o usuarios que los utilizan, a través de

la encapsulación, proporcionando un entorno lógico o virtual que elimina la dependencia

del sistema físico subyacente. La virtualización de infraestructuras, surge bajo el desafío

actual de la industria de las tecnologías de la información (TI), que persigue encontrar

soluciones de sistemas más simples, más rápidas y al mismo tiempo con una capacidad de

administración superior. A todo esto, se suma la búsqueda de una mayor seguridad y

flexibilidad [1].

1.1.1 Conceptos básicos

Máquina Virtual

A grandes rasgos, una máquina virtual es un software que simula una computadora y que

puede ejecutar programas como si fuese un ordenador real. Una característica esencial de

las máquinas virtuales es que los procesos que ejecutan están limitados por los recursos y

abstracciones de la maquina física subyacente [2]. Según las características y la


funcionalidad se puede hablar de máquinas virtuales hardware o de sistema o de máquinas

virtuales de proceso o de aplicación virtual.

Máquinas virtuales hardware o de sistema: Son aquellas que permiten a la maquina

física subyacente multiplicarse en varias máquinas virtuales, es decir, abstraen el hardware

de una maquina física y hacen uso de él. Cada una de estas máquinas pueden ejecutar su

propio sistema operativo y son controladas a través de un software denominado hipervisor

[3], que se describirá más adelante. En la figura 1.1 se muestra un diagrama que representa

un equipo o servidor sobre el que corren dos máquinas virtuales.

Fig.1.1: Esquema de representación de una máquina virtual de hardware o sistema.

Máquinas virtuales de proceso o aplicación: Este tipo de máquina virtual no representan

una maquina al completo, sino más bien simulan un proceso sobre el sistema operativo, es

decir, la maquina se inicia automáticamente cuando se lanza el proceso y se detiene cuando

este finaliza. Su objetivo fundamental es proporcionar un entorno de ejecución

independiente del hardware y del operativo para las aplicaciones que se ejecutan sobre ella

[4].

Hipervisor


A grandes rasgos, se puede definir un hipervisor como un programa software que permite

que diferentes sistemas operativos compartan recursos alojados bajo el mismo hardware, es

decir, es un gestor de máquinas virtuales (Virtual Machine Manager) [5]. De esta forma,

aunque aparentemente cada máquina virtual utiliza para sí misma los recursos del host

¨anfitrión¨, en realidad es el hipervisor el que controla dichos recursos y los distribuye entre

las máquinas virtuales según sus necesidades y sin que interfieran entre ellos. Se pueden

diferenciar dos tipos de hipervisores en función de su arquitectura:

Hipervisor tipo I: Este tipo de hipervisor se despliega como una instalación bare-metal o

native. Esto significa que lo primero que se instala en un servidor es el hipervisor, lo que

tiene como ventaja que sería el hipervisor el que se comunicaría directamente con el

hardware del servidor físico [6]. Se instala en el servidor físico sin la necesidad de que

exista un sistema operativo previo. Se agrupan como hipervisores de tipo I tecnologías

como VMware vSphere, Microsoft Hyper-V, Proxmox o Citrix XenServer.

Figura 1.2: Esquema de representación de un hipervisor tipo 1.

Hipervisor tipo II: Se conoce también como hipervisor alojado o ¨hosted¨. Este tipo de

hipervisores requieren ser instalados sobre un sistema operativo previo. Es la solución más

conocida a nivel usuario con programas como VirtualBox o VMware Workstation [7]. La

figura 1.3 muestra una representación de este caso.


Figura 1.3: Esquema de representación hipervisor tipo 2.

1.2 Tipos de virtualización

Actualmente el concepto de virtualización está tan ampliamente expandido que muchas

veces se emplea de manera errónea. No es correcto, por tanto, mezclar conceptos de

emulación, simulación, virtualización o para virtualización y es por ello que se muestra a

continuación una descripción detallada de los diferentes tipos de virtualización con el

objetivo de plantear todo el entramado de forma clara [8]. La virtualización separa de forma

lógica los servicios y los recursos (físicos), que realmente ofrecen y proporcionan ese

servicio. Dicho recurso puede ser individual (almacenamiento, red, etc) o una plataforma

completa (servidor). Para comprender en su totalidad los modelos de virtualización es

importante tener claro la diferencia entre dos conceptos clave: el recurso virtual abstraído y

el elemento que (virtualizado) dispone de ese recurso [9]. Es la combinación de estos

conceptos lo que provoca la aparición de los cuatro tipos principales de virtualización:

virtualización de plataforma, virtualización de recursos, virtualización de aplicaciones y la

que será objetivo de este proyecto, virtualización de escritorios (VDI).

1.2.1 Virtualización de plataforma

La virtualización de plataforma es aquella en la que el recurso que se abstrae o virtualiza es

el sistema completo, como es el caso de un servidor [10]. Consiste básicamente en


virtualizar todo el hardware subyacente de una plataforma de tal forma que múltiples

sistemas operativos puedan ejecutarse de forma independiente, y que los recursos

abstraídos se comporten de forma equivalente al sistema físico. Cada una de las máquinas

ve a las otras máquinas virtuales como maquinas independientes, es decir, desconoce que

comparte con ellas ciertos recursos.

Es el modelo aplicado en lo que se conoce como virtualización de servidores, que puede

verse como el particionado de un servidor físico en varios servidores virtuales ejecutando

de forma independiente su sistema operativo y los servicios que este ofrece [11].

A su vez, este sistema de virtualización se subdivide en diferentes paradigmas:

Sistemas operativos invitados: Es aquel sistema de virtualización que ocurre sobre una

aplicación para virtualización, que corre sobre un sistema operativo anfitrión y que permite

la ejecución de instancias virtuales. Las soluciones más conocidas de este tipo son

VirtualBox, VMware Workstation y Parallels [12].

Emulación: Un emulador es la réplica de una arquitectura de hardware al completo que

permite que se ejecuten sobre él diferentes máquinas virtuales. Emuladores conocidos

actualmente pueden ser Boch, MAME o Qemu.

Paravirtualización: La paravirtualización es una técnica de virtualización mediante un

sistema operativo o un hipervisor. Este operativo (o hipervisor) es el que interactúa y

gestiona los recursos del hardware, creando una capa de abstracción que emula

componentes físicos como tarjeta de red, de video, discos duros, y RAM; para que los

sistemas operativos virtualizados funcionen de manera transparente. Es necesario modificar

los sistemas operativos [12].

Virtualización completa: La misma es similar a la paravirtualización en la existencia de

un hipervisor, pero no requiere que los sistemas operativos invitados colaboren con él. Este

método tiene todas las ventajas de la paravirtualización, con el añadido de que no es

necesaria ninguna modificación en los sistemas operativos virtualizados. La única

restricción es que estos últimos deben soportar la arquitectura de hardware subyacente. En

la Figura 1.4 se puede ver una comparativa de esta arquitectura con respecto a la

paravirtualización.


Figura 1.4: Representación esquematizada de una arquitectura de virtualización completa y una arquitectura

de paravirtualización.

Virtualización a nivel de sistema operativo: Consiste en la virtualización de servidores

sobre el propio sistema operativo, sin introducir un hipervisor como capa intermedia.

Requiere cambios en el núcleo del sistema operativo, aunque esto se compensa con un

notable aumento del rendimiento, ofreciendo características similares a las del sistema sin

virtualizar. Las soluciones comerciales que emplean esta técnica no son mayoritarias,

destacando OpenVZ, Linux V-Server o Virtuozzo.

Virtualización a nivel de kernel: El hipervisor pasa a ser el núcleo del sistema operativo

(el kernel), lo que permite ejecutar varias máquinas virtuales en el espacio de usuario del

núcleo Linux anfitrión. Se agrupan aquí soluciones tan importantes como KVM o User-

mode Linux [13].

1.2.2 Virtualización de recursos

La virtualización de recursos consiste en la abstracción individual de un componente o

recurso de un ordenador, como puede ser la red, el almacenamiento o la entrada y salida.

Los ejemplos más representativos de este paradigma de virtualización son el uso de

memoria virtual, los sistemas RAID (Redundant Array of Independent Disks), LVM

(Logical Volume Manager) o la virtualización de red [14]. En función de la abstracción y la

tecnología se pueden clasificar a su vez en varios subtipos:

Encapsulación: Consiste en ocultar la complejidad y las características del recurso

abstrayendo el mismo y creando una interfaz simple.

Memoria virtual: Se trata de la técnica de gestión de memoria que permite que el sistema

operativo disponga de mayor cantidad de memoria de la que está disponible físicamente.


En este caso, el recurso abstraído es la memoria y el disco. La mejor representación de este

modelo es el conocido espacio para Swap, empleado en sistemas Unix.

Virtualización del almacenamiento: Virtualización del sistema de almacenamiento físico.

Consiste en abstraer completamente el hardware de almacenamiento en componentes

lógicos. Se incluyen en este grupo las mencionadas tecnologías RAID o LVM, así como

también SAN (Storage Area Network), NAS (Network-Attached Storage), NFS (Network

File System) o iSCSI (Internet SCSI).

Virtualización de red: Se fundamenta en la creación de direcciones de red virtuales dentro

de una red o entre subredes. El recurso abstraído es en este caso la propia red. Como

ejemplos destacados en este campo se encuentra la creación de VPN's a través de software

como OpenVPN o OpenSwarm o la virtualización de switches y routers [15].

Unión de interfaces de red: Puede englobarse dentro de la virtualización de red o tratarse

de forma independiente. Es también conocido como NIC Bonding o EtherChannel y

consiste en crear varios enlaces de red que son usados como un único enlace de mayor

ancho de banda. El recurso abstraído son los enlaces de red o interfaces de red. Soluciones

ejemplo son vHBA (Virtual Host Bus Adapter) y vNIC (Virtual Network Interfaces Card).

Virtualización de la E/S: En este tipo de modelo se produce la abstracción de los

protocolos de capas superiores de las conexiones físicas o del transporte físico. Ejemplos:

Xsigo Systems o Leaf Systems [15].

Virtualización de la memoria RAM: Trata de conseguir la unión de memorias RAM de

varios sistemas conectados en red para conseguir una memoria común de mayor capacidad.

1.2.3 Virtualización de aplicaciones

Consiste en la encapsulación y ejecución de las aplicaciones sobre un sistema operativo

(virtualizado o no). Es decir, permite ejecutar aplicaciones en sistemas operativos para los

cuales no fueron implementadas, proporcionando así portabilidad y compatibilidad.

Usualmente, la aplicación se descarga bajo demanda y se ejecuta en un entorno virtual

protegido sin que modifique el equipo local o interfiera con otras aplicaciones. Presentan

las ventajas de reducir el coste y el tiempo de mantenimiento, el disponer de la aplicación

en cualquier momento y lugar, la posibilidad de instalar más de una versión de una


aplicación y la no degradación del sistema operativo al ser instalada [16]. Los ejemplos

destacados y conocidos en este grupo son Microsoft App-V, Citrix XenApp o VMware

Thinapp.

1.2.4 Virtualización de escritorios

Consiste en la manipulación de forma remota del escritorio de usuario (aplicaciones,

archivos y datos), que se encuentra separado de la maquina física, almacenado en un

servidor central. Será el tipo de virtualización abordado en este trabajo, por consistir en la

implantación de una infraestructura de este tipo en la Universidad Central “Marta Abreu”

de las Villas y tratado de forma más completa en sucesivos apartados.

1.3 Virtualización de escritorios o VDI

Durante décadas, el entorno tradicional TIC se ha desarrollado en una infraestructura en la

que cada usuario tiene su propio PC con una CPU dedicada, un sistema operativo instalado

a nivel local y un disco duro que contiene todas las aplicaciones. En una organización,

todos estos usuarios de un sistema convencional se administran a través de un servidor de

red, que ocasionalmente, puede incluir espacio de almacenamiento adicional para discos de

red compartidos. Es el personal del departamento de TI el encargado de mantener todas las

configuraciones, licencias, actualizaciones y demás labores de administración comunes, de

forma independiente en cada una de las maquinas [18]. Este es un modelo que funcionó

correctamente durante décadas, pero ahora, son muchos los factores que están impulsando a

las organizaciones a considerar soluciones más eficientes y seguras.

La virtualización de escritorios o VDI (Virtual Desktop Infraestructure) consiste en la

configuración de varios equipos virtuales en un servidor físico para la optimización de los

recursos disponibles. Es, en esencia, la creación de un ordenador virtual que se almacena en

un servidor de virtualización de manera remota, en lugar de estar almacenado en el propio

computador [19]. Esta técnica, permite que múltiples máquinas virtuales, con sistemas

operativos heterogéneos entre sí, funcionen aisladamente unas de otras dentro de una

misma maquina física. Como es evidente, cada máquina virtual posee su propio hardware

virtual (memoria RAM, disco duro, procesador, CPU, tarjeta de red, etc.) sobre el cual se

ejecuta un sistema operativo con sus correspondientes aplicativos de la misma manera que


lo hace un equipo convencional. La idea básica de esta arquitectura se ejemplifica en la

Figura 1.5.

Figura 1.5: Representación básica de una arquitectura VDI

Esta infraestructura, permite a los usuarios acceder remotamente a sus escritorios desde

cualquier dispositivo (PC, portátil, smartphone, etc) y desde cualquier lugar, poniendo a

disposición del usuario o empleado su entorno de trabajo [20].

Las infraestructuras VDI permiten que múltiples usuarios de la red mantengan de forma

independiente sus escritorios individuales en un único servidor, habitualmente localizado

en un Data Center. Los usuarios pueden conectarse a su escritorio mediante una red de área

local (LAN), mediante una red de área extensa (WAN) o a través de Internet.

La diferencia radica en la infraestructura en su conjunto, es decir, la virtualización de

servidores hace referencia al particionamiento de un servidor físico en varios servidores

virtuales, con el objetivo de aprovechar el hardware. En este caso el software de

virtualización es empleado para dividir el servidor físico y administrar todas esas máquinas

virtuales [21].

Por otra parte, la virtualización de escritorios hace referencia a la ¨virtualización del cliente¨

(mayor orientación hacia los usuarios), esto es, es la que permite realizar una separación

física entre el escritorio y el ordenador físico. Se trata básicamente de un modelo de

virtualización cliente-servidor, de tal forma que, aunque haga uso de máquinas virtuales

(igual que la virtualización de servidores), una infraestructura VDI permite a mayores

tareas de monitorización y administración de usuarios y aplicaciones, así como un control

centralizado y controlado de todos los escritorios de los usuarios [22].


1.3.1 Conceptos básicos

Dentro del ámbito de la virtualización de escritorios existen una serie de conceptos propios

de la temática que deben ser definidos y aclarados previamente, ya que aparecen en las

diferentes secciones, al igual que los ya mencionados anteriormente.

Thin client

La definición de thin client o cliente ligero engloba tanto un software como un equipo

hardware real y, de forma básica, se podrá definir como la tecnología hardware o software

que permite el acceso a una máquina virtual o escritorio virtual remoto, siendo en el

servidor donde se realizaran las tareas de computación. Es decir, su única labor residirá en

transportar la entrada y la salida entre el usuario y su escritorio virtual [23]. Existen dos

tipos diferenciados:

Thin client software: En términos de software, un cliente ligero es un programa

que es en gran parte una interfaz simple. El usuario del software de cliente ligero ve

los datos, herramientas y características como lo haría en sistema operativo normal,

pero realmente, es otro programa que se ejecuta en un servidor remoto y que realiza

el trabajo. Puede ser tanto un software cliente instalado sobre S.O o bien puede

como un pequeño sistema operativo en sí mismo que únicamente permita el acceso

a un escritorio virtual almacenado en un servidor remoto.

Thin client hardware: Básicamente, se trata de un pequeño equipo (similar a un ordenador

de sobremesa, pero de muy pequeño tamaño), carente en la mayoría de los casos de disco

duro, pues su tarea reside únicamente en realizar la conexión con el servidor externo y

proporcionar al usuario su escritorio virtual, manejando los datos de entrada y salida del

mismo. La práctica totalidad de fabricantes de hardware presentan en el mercado algún

dispositivo de este tipo [24].

1.4 Comparativa de productos

Una vez caracterizado el marco teórico de las tecnologías que se va a utilizar es necesario

realizar una exhaustiva comparativa de las mismas poniendo especial atención en aquellas

características indispensables, por ser necesarias en el entorno en el que se realiza la


implantación de la infraestructura. Por otra parte, como es evidente, se omite en la

comparativa aquellas características innatas de los sistemas analizados o aquellas que

pueden darse por supuestas (Ejemplo: Compatibilidad con escritorios Linux es una

característica evidente y alta disponibilidad, alta densidad y balanceo de carga son

características que todas las soluciones poseen).

Dadas las características de la Universidad de “Las Villas” y el entorno en el que se

realizará la instalación del sistema, la solución ideal sería la implantación de cualquiera de

las soluciones de código abierto de virtualización de escritorio en sus versiones "enterprise"

destinadas a ser implantadas por organizaciones con grandes infraestructuras informáticas y

que precisan de un soporte de calidad. Por ser este un proyecto piloto y carente de

presupuesto, la implantación del sistema de virtualización deberá ser realizado con alguna

de las versiones gratuitas de las soluciones anteriores. Teniendo en mente una posible

ampliación del proyecto de cara a un futuro cercano, se realizará tanto la comparativa de las

versiones más completas de software libre. De este modo, se puede tomar una decisión

final objetiva y siempre considerando la posibilidad de que en un futuro el sistema sea

migrado hacia una versión más completa, en caso de que se requiera.

1.4.1 Comparativa de plataformas de escritorios virtuales

En este proyecto, se pone especial atención en las versiones que no son de pago en el

campo de la virtualización de escritorios, pues una de estas será la solución a implantar. Se

realiza por tanto una comparativa de las posibles soluciones gratuitas Ulteo y QVD. La

Tabla 1.1, 1.2 y 1.3 [27], [29], [32], [31] muestran los resultados comparativos entre las

principales plataformas de software libre que existen en la virtualización de escritorios.

Característica Descripción Ulteo QVD

Cliente Windows Acceso al escritorio

virtual a través de un

software nativo

desde

S.O Windows.

No Si


Cliente Linux Acceso al escritorio


software nativo

desde

S.O Linux.

No Si

Cliente OS X Acceso al escritorio


software nativo

desde

S.O MAC OS X.

No Si

Cliente Android Acceso al escritorio

virtual con un

dispositivo Android

No Si

Cliente iOS Acceso al escritorio

virtual con un

dispositivo iOS

(iPhone & iPad).

No Si

Cliente Web Acceso al escritorio


navegador web

Si Si

Software de cliente

ligero

Mini S.O que ejerce

las funciones

de Thin Client.

No No

Tabla 1.1: Comparativa de los clientes de acceso al escritorio.



Administración web Administración a

través de una

completa interfaz web.

Si Si

Administración

delegada

La consola de

administración permite

establecer varios

niveles de

delegación de los

administradores,

es decir, permite

establecer niveles en

los derechos de

administración.

Si Si

Control de acceso Permite configurar o

establecer dominios

para el control de

acceso.

La autenticación de

usuarios puede ser

facilitada por distintos

sistemas como LDAP

o "Active Directory".

Si Si

Compatibilidad

CIFS o NFS

Ofrece compatibilidad

con el sistema de

ficheros CIFS o NFS

Si Si

Compatibilidad con Ofrece compatibilidad Si Si


VMware/Proxmox con infraestructuras

VMware

Tabla 1.2: Comparativa de características relacionadas con la administración y monitorización


Soporte Plan de soporte Comunidad Comunidad

Soporte por e-mail Resolución de

problemas a través

de correo electrónico

con respuesta rápida.

No Si

Soporte online Resolución de

problemas simples a

través de una

aplicación web.

No Si

Tabla 1.3: Comparativa de características relacionadas el soporte ofrecido.

1.5 Solución a implementar

Tras realizar el estudio teórico comparativo anterior y descartar la solución de Red Hat por

no disponer de alternativas gratuita, se realizó un estudio práctico de las dos soluciones

candidatas: Ulteo y QVD.

La prueba práctica consistió únicamente en la realización de distintas pruebas con las

máquinas virtuales o appliances preconfiguradas que ambas soluciones proporcionan para

dicho fin. Las pruebas y análisis realizados sobre los productos fueron las siguientes:

Prueba y análisis de la interfaz de administración Web: El estudio realizado en

este apartado consiste en analizar y estudiar las diferentes opciones y herramientas

de administración que incluye la interfaz web. Dentro de este campo, las

características más importantes que se tuvieron en cuenta fueron: sencillez,


completitud, usabilidad y diseño. Tras una comparación a la par entre Ulteo y QVD,

se consideró más adecuada para este punto la interfaz proporcionada por Ulteo,

siendo mejor en todas las características analizadas.

Prueba y análisis de los diferentes clientes software: Para el análisis de los

clientes software de conexión con el escritorio remoto fue necesaria la instalación y

configuración de los clientes (que cada solución proporciona en sus versiones

gratuitas) para cada una de las plataformas:

o Ulteo: Tal y como se muestra en la Tabla 1.1 de la sección anterior, la

solución Ulteo en su versión gratuita (Community Edition) solo ofrece

clientes de acceso al escritorio remoto a través del navegador, bien a través

del motor Java del navegador, como recientemente a través de HTML5. Los

clientes nativos para las plataformas móviles y de escritorio solo están

disponibles en su versión de pago (Premium Edition).

o QVD: A diferencia de Ulteo, en este caso resulta mucho más completa la

solución de QVD, pues permite la descarga y el uso de todos los clientes

disponibles. Es importante destacar que, aunque el cliente Android se

encuentre en fase beta, es completamente funcional.

Prueba de rendimiento de los escritorios en los diferentes clientes software: En

relación al rendimiento de los escritorios se trata de una prueba de difícil

justificación inicial. Es decir, con el uso de las máquinas virtuales servidor que las

soluciones ofrecen para pruebas, ambas soluciones ofrecen un rendimiento similar.

El problema reside en la imposibilidad de realizar una prueba de ambas soluciones

en un entorno real y con una carga de trabajo real (con varias decenas o centenas de

usuarios). Es por ello, que, según las pruebas realizadas sobre las máquinas

virtuales, se podría decir que ambas soluciones ofrecen un rendimiento equivalente.

Análisis general de las características gratuitas: En el resto de características de

las versiones gratuitas prácticamente no se aprecian diferencias significativas, pues

ambas soluciones cubren completamente el campo de elementos necesarios para una

solución VDI básica: balanceador de carga, herramientas o elementos para permitir

el control de acceso o autenticación a través de Active Directory o LDAP,


mecanismos de auto provisión de escritorios, aislamiento de máquinas virtuales, etc.

Una vez más, ambas soluciones son totalmente completas y funcionales [33].

Una vez analizados en detalle todos los puntos anteriores, llego el momento en el que se

debe tomar una decisión sobre la solución a implementar en este proyecto, siempre

teniendo en cuenta las perspectivas de ampliación del mismo en un futuro.

Aunque Ulteo fuese desde un primer momento una alternativa de muy posible

implantación, la carencia de clientes de acceso en sus versiones gratuitas hace que no sea

tan adecuada como QVD para el uso en la Universidad, pues esta última permite y

flexibiliza a los alumnos y personal el uso de los escritorios virtuales desde cualquier

dispositivo sin coste alguno, permitiendo seguir la filosofía BYOD ("Bring Your Own

Device").

Bien es cierto, que QVD ofrece una interfaz web de administración con muchas menos

funcionalidades (muy básica), pero que se complementa a la perfección con una serie de

scripts de administración de fácil uso.

En definitiva, se podrá considerar que la solución QVD fue la seleccionada para favorecer

desde un inicio a los usuarios de los escritorios remotos en detrimento de una

administración un poco más complicada de los escritorios. Por tanto, una vez seleccionada

la tecnología de virtualización de escritorios, se procede a su descripción en la sección

siguiente.

1.6 Que es QVD

QVD es la solución de escritorios virtuales ofrecida por la empresa Qindel Group, una

compañía internacional de consultoría especializada en proyectos y entornos Linux, y en el

ámbito de las tecnologías de la información en general, con sedes en España, México y

Colombia [24].

El software, está diseñado íntegramente para ofrecer virtualización de escritorios Linux.

Los clientes se conectan a un servidor central que es el responsable de cargar el entorno y

las aplicaciones propias del usuario. De esta forma, cuando los usuarios trabajan desde su

máquina local (puede ser cualquier dispositivo: desde un ordenador convencional hasta un


teléfono móvil) todos los programas, aplicaciones, procesos y datos son almacenados y

ejecutados en un servidor, lo que trae consigo una serie de ventajas:

Los usuarios pueden cambiar de ordenador dentro de la red y continuar trabajando

exactamente en su escritorio sin apreciar diferencias. Permite a los trabajadores total

libertad en lo que se refiere al puesto de trabajo [25].

Los administradores tienen control total sobre las aplicaciones y datos que están

instaladas en los escritorios de los usuarios, facilitando de este modo las tareas de

backups, mejora continua de la seguridad o permitir cierto control sobre los

empleados.

Total, flexibilidad en la autoprovisión de nuevos escritorios e instalación de

aplicaciones en los mismos [26].

Características propias de los sistemas virtualizados, es decir, QVD ofrece

cualquiera de las características básicas de la virtualización, descritas en la sección

anterior.

En lo referente a las tecnologías empleadas por QVD, destaca por ser una de las únicas

soluciones VDI para Linux que ofrece la posibilidad de seleccionar la tecnología de

virtualización a bajo nivel deseada: KVM o LXC permitiendo implementar cualquiera de

las dos opciones, en función de las necesidades de la organización o la preferencia deseada

por los administradores [27].

Por otra parte, permite servir diferentes sistemas operativos que son cargados a través de

imágenes de disco independientes, en los nodos de la infraestructura de QVD, creando así

un entorno totalmente personalizado para un usuario o un grupo de usuarios. Ofrece una

flexibilidad total y bajo el control de los administradores, permitiendo servir, por ejemplo,

un Linux diferente (diferentes distribuciones y con paquetería o características propias) a

los distintos departamentos de una organización [28].

Los usuarios acceden a su escritorio virtual a través de un cliente de acceso bajo previa

autenticación y mediante el uso del protocolo NX, a su vez QVD añade una seguridad

adicional en el resto del proceso, enviando el tráfico cifrado mediante SSL y permitiendo

así acceder de forma segura desde cualquier localización y desde cualquier dispositivo [29].


Aunque se verá con detalle en el siguiente apartado, la estructura y diseño de QVD permite

a cada usuario disponer de un entorno totalmente aislado, de tal forma que el mal

funcionamiento o cualquier tipo de problema en el entorno de un usuario no afecte a los

otros usuarios.

1.6.1 Componentes principales

Para construir una solución completa de escritorios virtuales mediante QVD es necesaria la

presencia de una serie de componentes que son indispensables para el correcto y completo

funcionamiento de la plataforma, tal y como se puede ver en la Figura 1.6. Dichos

componentes [30] pueden estar presentes de forma conjunta en un solo nodo servidor

(pequeñas instalaciones o destinadas a pruebas) o bien distribuirse en diferentes nodos para

entornos de producción.

Figura 1.6: Esquema básica de QVD.

Los componentes principales de cualquier instalación QVD son básicamente cuatro:

Servidor o servidores QVD (1): Se trata del nodo/s de procesamiento en los que se

ejecutaran las maquinas o escritorios virtuales. Habitualmente (en instalaciones


reales) serán una serie de servidores formando una arquitectura clúster. Es decir,

varios nodos funcionando y configurados para dar servicio de forma conjunta.

Servidor de administración (2): Sera el encargado de ejecutar la interfaz de

administración que emplean los administradores de QVD para realizar todas las

tareas de gestión de los escritorios.

Servidor base de datos (3): Básicamente se trata de un servidor con un SGBD, que

en el caso de QVD el SGBD es PosgreSQL. Este contiene una base de datos incluye

toda la información acerca de los usuarios, maquinas, servidores, sistemas

operativos y configuraciones del entorno.

Clientes de acceso QVD (4): Se trata del conjunto de programas software disponibles para

las diferentes plataformas y que permiten el acceso al escritorio virtual.

1.6.2 Componentes secundarios

Los componentes anteriormente mencionados son indispensables para el funcionamiento

básico de una infraestructura QVD, sin posibilidad de excluir ninguno de ellos.

Además de esos componentes existen otros que pese no ser completamente necesarios,

están igualmente presentes en la práctica totalidad de las infraestructuras en funcionamiento

con un mínimo de usuarios [32]. Dichos componentes se muestran en un diagrama de

ejemplo en la Figura 1.7.

Balanceador de carga (1): Necesario para cualquier entorno en producción con más de un

nodo QVD y que ejecutan múltiples máquinas virtuales para dar servicio a varios usuarios.

Dicho balanceador será el encargado de redistribuir equitativamente las máquinas virtuales

en ejecución entre los nodos de QVD. Además, QVD permite la inclusión a la

infraestructura de un balanceador hardware, que será explicado en detalle en apartados

posteriores.

Almacenamiento compartido (2): En una infraestructura en la que exista más de un nodo

QVD, todos los componentes de QVD deben tener acceso a un almacenamiento compartido

(normalmente NFS) en el que se almacenan las imágenes de los sistemas operativos para

cargar las distintas máquinas virtuales y los datos propios del entorno de cada uno de los

usuarios (P. eje: directorio home).


Figura 1.7: Esquema de QVD con componentes adicionales

QVD Virtual Machine Agent: Es el responsable de aceptar las conexiones desde el cliente

a la VM a través de un nodo QVD. Es un demonio o programa software que se instala en

las máquinas virtuales para facilitar el acceso por parte de los clientes y es el elemento

responsable que la infraestructura QVD tiene ejecutándose dentro de cada máquina virtual

[27]. Al encontrarse dentro de las máquinas virtuales no puede mostrarse en la Figura 1.7.

1.7 Conclusiones del capítulo

Para el despliegue se tuvo en cuenta en la selección del software que sea de código abierto,

con estándares abiertos y de gran aceptación. Se tuvo en cuenta que la estructura es la de

menor complejidad que aportara los requerimientos de los servicios a brindar.

Aunque Ulteo es desde un primer momento una alternativa de muy posible

implementación, la carencia de clientes de acceso en sus versiones gratuitas hace que no

sea tan adecuada como QVD para el uso en la Universidad, pues esta última permite y

flexibiliza a los alumnos y personal el uso de los escritorios virtuales desde cualquier

dispositivo de forma gratuita.


CAPÍTULO 2. METODOLOGÍA DE INSTALACIÓN Y ADMINISTRACIÓN

DE QVD.

Todo proceso de migración requiere del análisis de los elementos implicados y de una

metodología que sea capaz de responder a los requerimientos de la institución en que se va

aplicar. Se debe elegir cuidadosamente los programas libres que remplazarán a los

existentes sin afectar el funcionamiento de los servicios de red, además debe ser

transparente para los usuarios.

En el presente capítulo se realiza un recuento sobre la versión 4 de QVD, así como los

requerimientos para la instalación. Se aborda también el entorno de trabajo en el que se

desarrolla la implementación. Además, se expone la metodología a seguir en la instalación

de QVD y los posibles escenarios de desarrollo. Finalmente se presentan las herramientas

más comunes para la administración de esta plataforma en esta nueva versión.

2.1 QVD (Quality Virtual Destokp)

QVD (Quality Virtual Desktop) es una solución VDI enfocada en Linux. El software está

diseñado para virtualizar por completo el escritorio de Linux, por lo que los sistemas cliente

son capaces de conectarse a un servidor central para cargar su entorno de escritorio y

aplicaciones. Esto significa que cuando los usuarios trabajan desde su máquina local, todos

los programas, aplicaciones, procesos y datos utilizados se mantienen en el servidor y se

ejecutan de forma centralizada [21]. La virtualización ofrece una serie de características y

ventajas [27]:

Los usuarios pueden cambiar entre ordenadores en una red y seguir trabajando

como si aún estuvieran en el mismo escritorio, con pleno acceso a todas sus

aplicaciones y datos.

Los administradores tienen un mayor control sobre las aplicaciones que están

instaladas en los sistemas de los usuarios, y son capaces de gestionar los datos de

los usuarios con mayor facilidad para realizar copias de seguridad y análisis de

virus, etc.


Es más fácil para los administradores aprovisionar nuevos equipos de sobremesa y

desplegar aplicaciones para los nuevos usuarios.

Hay menor tiempo de inactividad en el caso de fallos de hardware.

Los usuarios pueden hacer uso de una variedad de diferentes dispositivos para

acceder a su escritorio y aplicaciones, incluyendo ordenadores portátiles,

ordenadores personales y teléfonos inteligentes.

Los usuarios pueden trabajar con seguridad con el mismo escritorio y aplicaciones

desde una ubicación remota sin necesidad de una VPN.

La mejora general del sistema y seguridad de datos.

Reducción de costes de hardware, mantenimiento y administración [2].

El servidor QVD virtualiza cada escritorio Linux. Esto se puede lograr mediante el uso de

una de las dos tecnologías de virtualización disponibles en el producto. Una posibilidad es

KVM (Kernel-based Virtual Machine), que se utiliza como un hipervisor tipo 1. La otra

posibilidad, mucho más interesante, es LXC (Linux Containers). Esta virtualización ayuda

a mantener el entorno de cada usuario como su propia entidad discreta, para mejorar la

seguridad y la estabilidad [29].

La virtualización permite servir múltiples sistemas operativos o entornos a los usuarios, en

función de sus necesidades. Estos se cargan como imágenes independientes en el servidor

de QVD. Estas imágenes proporcionan la base del sistema operativo y el entorno de

trabajo, que se replican para cada máquina virtual. Cuando un usuario se conecta al

servidor, haciendo uso de la aplicación cliente, una máquina virtual se inicia únicamente

para ese usuario. Esto proporciona una “jaula” que impide que cualquier comportamiento

inapropiado pueda afectar a otros usuarios. Cuando el usuario se desconecta, la máquina

virtual se puede detener. Al detenerse, el entorno vuelve a su estado original, salvo la

información propia del usuario. Esto significa que, si el entorno del usuario de alguna

manera se ha convertido en un problema, una simple desconexión puede revertir el sistema

a su estado original. Esto proporciona un mejor nivel de seguridad que si un usuario estaba

trabajando en una estación de trabajo independiente.


Con el fin de mantener los datos del usuario, tales como la configuración del escritorio,

documentos y otra información específica del usuario, hay dos opciones. El primer, y más

común método, es almacenar esta información en un recurso compartido NFS. De esta

manera, los datos se pueden almacenar en un dispositivo NAS o dentro de un SAN, donde

se pueda controlar fácilmente. Una segunda opción es cargar una segunda imagen en la

máquina virtual. Esta imagen es persistente, ya que puede ser actualizada por el usuario, y

los cambios se almacenan para cada vez que se vuelve a cargar la imagen. Ambos enfoques

son igualmente válidos. Al mantener los datos de usuario independientes de la imagen del

sistema operativo, se comprueba que una imagen de sistema está dañada o en caso de fallo

de la misma, los administradores son capaces de reducir al mínimo el tiempo necesario para

la recuperación de desastres.

El escritorio se accede desde cada estación de trabajo, haciendo uso de un cliente que

utiliza el protocolo NX para comunicarse con el servidor. El protocolo NX se utiliza para

manejar las conexiones X-Windows remotas y proporciona un nivel de compresión elevado

que permite un alto rendimiento incluso cuando se accede al escritorio a través de una

conexión con poco ancho de banda. Por otra parte, QVD es capaz de encapsular el

protocolo NX con SSL para cifrar la conexión, de manera que los usuarios pueden trabajar

de una manera segura incluso si se accede desde una localización remota. QVD

proporciona software de cliente para funcionar en una variedad de sistemas operativos y

dispositivos de base, desde Linux a Windows [32].

2.1.1 Instalación y configuración de QVD

Los componentes QVD requieren el sistema operativo GNU / Linux de Ubuntu 16.04. En

primer lugar, agregue la clave pública de los paquetes QVD a sus claves de confianza

(como root):

# wget -qO - https://www.theqvd.com/packages/key/public.key | sudo apt-

key add -

Luego que la clave publica esta añadida, se agrega el repositorio y se actualizan los

paquetes de Ubuntu:

# echo "deb http://theqvd.com/packages/ubuntu-xenial QVD-4.1.0 main" > \

/etc/apt/sources.list.d/qvd.list

# apt-get update


Al actualizar el repositorio, se observa que QVD proporciona los siguientes paquetes:

perl-qvd-client: software de cliente de QVD GUI.

perl-qvd-hkd: demonio de mantenimiento.

perl-qvd-admin4: herramientas de línea de comandos para administrar usuarios,

máquinas virtuales, sistema operativo.

perl-qvd-db: base de datos central para la plataforma.

Cada uno de estos paquetes tendrá varias dependencias que pueden ser satisfechas por otros

paquetes provistos por los repositorios usuales de Ubuntu [32]. A continuación, se muestra

un resumen de otros componentes de código abierto requeridos por QVD:

El RSGBD de PostgreSQL.

KVM: Hipervisor.

LXC: Contenedores Linux basados en las herramientas de espacio de usuario de

los Kernels recientes.

libvirt0: una biblioteca para la interfaz con diferentes sistemas de virtualización.

NX: protocolo que maneja las conexiones de escritorio remoto.

Ebtables: una utilidad de cortafuegos basada en IP para puentes ethernet.

2.1.2 Hardware del Sistema

Los componentes del nodo HKD normalmente se deben ejecutar en sistemas

independientes para garantizar que cuentan con recursos adecuados para ejecutarse y los

requisitos de hardware variarán en función del número de usuarios que desee servicio, el

número de imágenes de disco del sistema operativo que se desee y varios factores más.

Por lo que respecta en esta tesis, que está implementando QVD, sólo se instala tres

imágenes y se configuraran, al menos, 16 usuarios como máximo, se recomiendan los

siguientes requisitos de hardware del sistema como guía:

Procesador del sistema: Procesador de 64 bits, preferiblemente multi-core. Puede

soportar alrededor de 8 usuarios por núcleo. Los paquetes de 32 bits están disponibles


para pruebas, pero la limitación de 4 GB de RAM para los modos no PAE de los

procesadores x86 significa que sólo una cantidad limitada de clientes será posible, y

ciertamente no es viable para un entorno de producción.

Memoria del sistema: Al menos 2 GB de RAM. Esto debe ser suficiente para un

máximo de 4 usuarios.

Espacio en disco: Al menos 4 GB de espacio en disco deben estar disponibles para

contener la imagen del sistema operativo, etc. Muy probablemente, se debe tratar de

duplicar esto para trabajar cómodamente con las herramientas implicadas en la

importación de una imagen.

Interfaz de red: Se necesita al menos una interfaz de red disponible. Un NIC Ethernet

10/100 debe ser suficiente.

Puede utilizar cualquier sistema cliente soportado para ejecutar el software QVD Client.

Actualmente soporta Linux, Microsoft Windows y OSX. También clientes beta para

Android y iOS [27].

2.1.3 Interfaz de red

Los nodos HKD utilizan interfaces de puente de red y de red virtual para facilitar la

interconexión en red de cada una de las máquinas virtuales que se ejecutan en el nodo. Con

el fin de proporcionar automáticamente direcciones IP a las máquinas virtuales, QVD

también ejecuta un servidor DHCP que asigna direcciones IP dentro del rango de la red

virtual a los hosts virtuales a medida que se inician. Por lo tanto, es muy importante elegir

un rango de red que sea poco probable que entre en conflicto con cualquier otra de su

infraestructura existente.

Los pasos de conexión en red se tratan con más detalle en el desarrollo de esta tesis, sin

embargo, lo más importante a tener en cuenta en este momento es que debe asegurarse un

rango de IP de red dedicado que se pueda utilizar para las máquinas virtuales que se

ejecutan dentro de QVD.

Además, en una instalación mononodo, como la que se está describiendo aquí, se necesita

configurar algún tipo de NAT para que las máquinas virtuales tengan acceso a la red. Esto


se logra generalmente configurando reglas iptables en el host [29]. En este documento se

proporcionan ejemplos para este tipo de configuración utilizando una configuración NAT.

2.2 Instalación y configuración de QVD DB

Dado que uno de los componentes más fundamentales de la solución QVD es la base de

datos, se sugiere que se instale este componente primero. La base de datos se utiliza para

vincular todos los demás componentes y para permitirles interactuar entre sí. El software

QVD tiene una base de datos PostgreSQL en su núcleo. Toda la información de

configuración y tiempo de ejecución se almacena en la base de datos y si falla, la

plataforma al completo deja de funcionar.

En los sistemas de producción, se recomienda encarecidamente que la base de datos se

instale en una configuración de alta disponibilidad, de modo que no se convierta en un

posible punto de fallo para su solución VDI. En general, los requisitos reales de hardware

son muy modestos, cualquier servidor moderno con sólo dos núcleos de CPU y 2 GB de

RAM será capaz de soportar la carga de la base de datos [29].

2.2.1 Instalacion de QVD DB

La forma recomendada de instalar la base de datos central es con el paquete perl-qvd-db

[29]. Para instalar ejecutar como root:

root@qvd:~# apt-get install perl-qvd-db

Después de instalar perl-qvd-db, se tienen que realizar varios pasos manuales. Son

1. Crear una cuenta de usuario,

2. Crear una base de datos,

3. Cambiar la configuración de la base de datos y

4. Desplegar el esquema de la base de datos de QVD.

Debido a que QVD está diseñado para ejecutarse desde uno o más nodos servidor, el

paquete perl-qvd-db no requiere el servidor postgresql como dependencia. Sin embargo,

para los propósitos de esta de esta instalación, se necesita el servidor instalado en la


máquina local. Por supuesto, se puede utilizar un servidor en otra máquina y adaptar su

configuración en consecuencia.

Se instala lo siguiente para Ubuntu:

# apt-get install postgresql

Ahora, se inicia el servidor postgresql:

# service postgresql start

Se necesita crear una cuenta de usuario y una base de datos en postgres, así que es

necesario hacerse la cuenta de postgres (use sudo si no es root):

# su - postgres

2.2.2 Creación de una cuenta de usuario

Si se desea utilizar una cuenta de usuario existente, se puede saltar este paso. Una vez que

se tenga acceso a la base de datos, se puede crear cuentas de usuario con el comando

“createuser”. Se le pide una contraseña para el nuevo usuario y algunos detalles sobre la

cuenta de usuario. Se puede responder n a todo.

Por ejemplo, para crear el usuario llamado qvd, se utiliza el siguiente comando.

postgres@qvd:~$ createuser -SDRP qvd

Enter password for new role: passw0rd

Enter it again: passw0rd

El nuevo usuario ahora puede ser asignado como propietario de una base de datos. Primero

se tiene que crear la base de datos QVD.

2.2.3 Creación de la base de datos QVD

Se utilice el comando createdb para crear una base de datos para QVD. Se utiliza el

modificador -O para establecer el propietario de la base de datos a la cuenta que desea

utilizar. En este caso, se establece el propietario en el nuevo usuario que se crea en el punto

anterior.

postgres@qvd:~$ createdb -O qvd qvddb

postgres@qvd:~$ exit

2.2.4 Cambiar la configuración de PostgreSQL

En un entorno en producción en el que múltiples sistemas interactúan con la base de datos

QVD, QVD utiliza transacciones de forma extensiva y requiere un nivel de aislamiento de


transacciones superior al configurado por defecto. Además, por lo general, se necesita que

PostgreSQL sea accesible por otros hosts de su red. Si bien este paso es opcional en la

solución independiente que se está creando, quizás se desee realizar esta configuración para

asegurarse de que el sistema esté preparado para gestionar nodos HKD adicionales. Para

ello debe editar el archivo de configuración PostgreSQL postgresql.conf. Se asume que se

está utilizando PostgreSQL 9.3, aunque puede que se necesite ajustar algunas rutas según

sea necesario [29].

En Ubuntu los archivos de configuración se encuentran en /etc/postgresql/9.3/main.

El nivel de aislamiento de la transacción se controla con la configuración

default_transaction_isolation. Para habilitar el acceso de red a PostgreSQL en general, se

cambia la configuración listen_addresses de localhost a *.

Para Ubuntu:

root@qvd:~# cd /etc/postgresql/9.3/main

root@qvd:/etc/postgresql/9.3/main# vi postgresql.conf

listen_addresses = ’*’

default_transaction_isolation = ’serializable’

Para habilitar el acceso de red para el usuario qvd, busque el archivo pg_hba.conf. Para

Ubuntu esto será en /etc/postgresql/9.3/main. Se editar este archivo y se agrega al principio

la línea siguiente: host qvddb qvd 10.12.53.0/24 md5

Se reinicia PostgreSQL para que los cambios surtan efecto.

root@qvd:~# service postgresql restart

2.2.5 Configuración básica

Cada nodo QVD utiliza un archivo de configuración /etc/qvd/node.conf desde donde se

obtiene, entre otros ajustes que se cubrirán más adelante, las credenciales de la base de

datos y el nombre del host. Una vez que haya terminado de configurar postgresql, se

necesita crear este archivo de configuración de nodo. Se debe tener perl-qvd-config-core

instalado en este punto como una dependencia [21]. Contiene un archivo de muestra

node.conf. Se cree la carpeta qvd en /etc, y se copia esta configuración de plantilla allí:

root@qvd:~# cp -v /usr/lib/qvd/config/sample-node.conf /etc/qvd/node.conf

Obviamente, los permisos en este archivo deben ser tan restrictivos como sea posible.

root@qvdr:~# chown root:root /etc/qvd/node.conf


Ahora, se hace el archivo ilegible por cualquier persona fuera del propietario y del grupo:

root@qvd:~# chmod 0640 /etc/qvd/node.conf

Ahora se necesita editar el archivo /etc/qvd/node.conf para incluir los detalles necesarios

para acceder a la base de datos. El archivo de configuración debería tener este aspecto:

# QVD Node Configuration

# Name of this node in QVD. Usually the machine’s hostname.

nodename = qvd.uclv.cu

# Database connection information.

# database.host: where the QVD database is found

database.host=qvd.uclv.cu

# database.name: the name of the QVD database

database.name=qvddb

# database.user: the user account needed to connect

database.user=qvd

# database.password: the password needed to connect

database.password=passw0rd

# Log level. One of ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF

log.level = ALL

log.filename = /var/log/qvd/qvd.log

En primer lugar, la entrada “nodename” y la entrada “database.host” deben coincidir con el

nombre de la máquina, por lo que en el ejemplo anterior se necesitará algún tipo de edición,

para este caso en la red de la UCLV se toma como nombre de dominio del host:

qvd.uclv.cu

El host de base de datos también debe coincidir con el nombre de host o la dirección IP del

sistema en el que se encuentra su base de datos. De forma predeterminada, el nombre de la

base de datos se establece normalmente en qvddb, pero para instalaciones personalizadas,

esto puede ser diferente. También se debe establecer el nombre de usuario y la contraseña

de la base de datos que se configuró al crear la base de datos [25]. Finalmente, se puede

también agregar un nivel de logging para propósitos de depuración de problemas.

2.2.6 Instalación de las tablas de QVD

Ahora es el momento de poblar la base de datos con las tablas que se utilizarán para

almacenar datos para QVD. Antes de poder usar cualquiera de las herramientas de QVD, se

tiene que configurar la base de datos, el nombre de usuario y la contraseña en los archivos

de configuración de QVD.

Una vez hecho, se ejecuta qvd-deploy-db.pl. Esto crea la estructura de tabla que QVD

necesita.


# /usr/lib/qvd/bin/qvd-deploy-db.pl

El Anexo I, muestra el modelo de base de datos relacional de PostgreSQL para QVD.

Prueba de acceso

Para iniciar sesión en postgresql se introduce el siguiente comando para enumerar las tablas

utilizadas por QVD:

# psql -U qvd -W -h localhost -d qvddb

Password for user qvd:

psql (9.3.0)

qvd=> \d<return>

2.3 Instalación y configuración del nodo

2.3.1 Instalación de HKD y herramientas de administración

Ahora es el momento de instalar el HKD. Para ello, hay que asegúrese de tener privilegios

de root:

root@qvd:~# apt-get install perl-qvd-hkd

Esto instalará el HKD, así como todas las dependencias necesarias para ejecutar un nodo

HKD.

La herramienta de administración API es un prerrequisito para los dos siguientes

componentes, por lo que debe ser lo primero que instale. Se puede hacer mediante el

siguiente comando:

root@qvd:~# apt-get install perl-qvd-api

Al instalar la API, se necesita configurarla. Para ello, se debe crear el fichero

/etc/qvd/api.conf y se añaden las siguientes líneas:

# Database connection information.

# database.host: where the QVD database is found

database.host=qvd.uclv.cu

# database.name: the name of the QVD database

database.name=qvddb

# database.user: the user account needed to connect

database.user=qvd

# database.password: the password needed to connect

database.password=passw0rd

api.user = root

api.group = root

path.api.ssl=/etc/qvd/certs


Se observa que se han repetido aquí los datos de configuración de la base de datos, ya que

la API requiere este acceso. Además, se han añadido las dos líneas que marcan el usuario

con el que se ejecutará la API (root en este caso siguiendo con el ejemplo anterior), y una

línea más con la ruta donde están los certificados que la API necesita para arrancar. Si

Para ejecutar tanto el CLI como el WAT se debe arrancar la API.

# service qvd-api start

La utilidad de administración en línea de comandos (CLI) de QVD se incluye en el

paquete perl-qvd-admin.

root@qvd:~# apt-get install perl-qvd-admin4

Esta útil herramienta permite realizar en línea de comandos todas las operaciones que se

pueden realizar usando la herramienta de administración web del paquete qvd-wat. Se

puede instalar en cualquier host que desee utilizar para administrar su instalación de QVD.

Por ejemplo, es posible que desee integrar QVD con una herramienta de supervisión

externa como Nagios, por lo que la instalación de la utilidad QVD CLI Administration en

este host haría esto posible [25].

La utilidad de Administración de QVD requiere un archivo de configuración que le diga

dónde está instalada la API QVD. Se va a configurar esto en el siguiente paso, pero vale la

pena tener en cuenta que, si desea instalar esta utilidad en cualquier otro host, el acceso a la

API sigue siendo necesario para su funcionamiento.

La utilidad de administración en línea de comandos (CLI) de QVD se incluye en el paquete

perl-qvd-admin.

root@qvd:~# apt-get install perl-qvd-admin4

Esta útil herramienta permite realizar en línea de comandos todas las operaciones que se

pueden realizar usando la herramienta de administración web del paquete qvd-wat. Se

puede instalar en cualquier host que desee utilizar para administrar su instalación de QVD.

Por ejemplo, es posible que desee integrar QVD con una herramienta de supervisión

externa como Nagios, por lo que la instalación de la utilidad QVD CLI Administration en

este host haría esto posible.

La utilidad de Administración de QVD requiere un archivo de configuración que le diga

dónde está instalada la API QVD. Se va a configurar esto en el siguiente paso, pero vale la


pena tener en cuenta que, si desea instalar esta utilidad en cualquier otro host, el acceso a la

API sigue siendo necesario para su funcionamiento.

Cree el fichero /etc/qvd/qa.conf:

qa.url = https://qvd.uclv.cu:443/

qa.tenant = *

qa.login = superadmin

qa.password = superadmin

qa.format = TABLE

qa.insecure = 1

En este ejemplo se ha asumido que la API ha sido configurada para escuchar en el FQDN

qvd.uclv.cu en el puerto 443. También se asume la contraseña del usuario superadmin e

incluso que la configuración SSL ya se ha llevado a cabo. Además, se ha configurado

qa.tenant =*, por lo que vemos todos los tenants de la plataforma en caso de que estuviese

configurada como multitenant. El parámetro qa.insecure debe ser sustituido por el

parámetro qa.ca con la ruta de su Autoridad de certificación.

La Herramienta de Administración de Web de QVD (QVD-WAT) es una interfaz

sencilla que facilita la administración de los nodos HKD y el monitoreo de sesiones activas

de clientes dentro de su infraestructura. También ofrece la posibilidad de administrar nodos

HKD desde ubicaciones remotas.

Aunque no es estrictamente necesario para ejecutar QVD, sin duda le ayudará a empezar

con el producto, por lo que lo instalaremos y configuraremos en nuestro nodo servidor.

El paquete referido a WAT se instala de la siguiente forma:

# apt-get install qvd-wat

El WAT se instala en /usr/lib/qvd/lib/wat/. Dentro de esta localización se encuentra su

fichero de configuración: config.json, que se muestra a continuación:

{

"apiUrl": "https://qvd.uclv.cu:443"

}

Para el ejemplo mononodo que se está preparando, no es necesario cambiar este fichero.

Tan solo se debe asegurar de que está ahí.

Ejecutando el WAT


El WAT es independiente de la API en cuanto a instalación. Se pueden instalar en

máquinas distintas y funcionar sin problemas, siempre que el WAT tenga en su

configuración la dirección de la API. No obstante, y puesto que también se pueden instalar

juntos, como es el caso en mononodo, la API sirve por defecto el WAT, no siendo

necesario configurar ningún servidor apache o nginx que lo sirva. Para arrancar el WAT en

este trabajo solo es necesario tener la API en funcionamiento. Se prueba la conexión en el

navegador, visitando https://qvd.uclv.cu:443.

Para iniciar sesión, puede usar el nombre de usuario y la contraseña predeterminados

siguiente:

user: superadmin@*

password: superadmin

Se puede cambiar esta contraseña desde el propio WAT. La figura 2.1 muestra la interfaz

WAT de QVD.

En el ANEXO III, se observan las principales configuraciones pertenecientes a WAT de

QVD.

2.4 Configuración básica e indispensable de administración de QVD

Una vez instaladas todas las herramientas administrativas (CLI, WAT y API), se procede a

utilizarlas para la configuración del nodo donde se implementa QVD.

Si bien es posible agregar otros parámetros de configuración al archivo de configuración de

nodo QVD que se ha editado anteriormente, este archivo simplemente se utiliza para

arrancar el servidor y posteriormente el servidor se referirá a la base de datos para encontrar

cualquier otra entrada de configuración, por lo que es mejor práctica establecer los

parámetros de configuración QVD dentro de la base de datos.

Hay algunos parámetros que deben definirse para informar a QVD acerca de su entorno

(por ejemplo, el rango de direcciones IP disponibles para las máquinas virtuales o su puerta

de enlace predeterminada). Estos parámetros son obligatorios y los demonios QVD se

niegan a iniciarse a menos que estén definidos. Son los siguientes:

vm.network.ip.start: Primera IP del rango reservado para máquinas virtuales


vm.network.netmask: Máscara de red del rango

vm.network.gateway: IP del router que permite acceder al exterior. Es transmitido

por DHCP a las máquinas virtuales

vm.network.bridge: Nombre de la interfaz puente reservada para QVD

Estas entradas se pueden establecer en la base de datos utilizando el comando qa disponible

en el paquete perl-qvd-admin de la siguiente manera:

# qa4 config set tenant_id=-1,key=vm.network.ip.start,value=10.12.113.100

# qa4 config set tenant_id=-1,key=vm.network.netmask,value=24

# qa4 config set tenant_id=-1,key=vm.network.gateway,value=10.12.113.200

# qa4 config set tenant_id=-1,key=vm.network.bridge,value=qvdnet0

2.4.1 Requisitos de red

Los nodos servidor QVD hacen uso de un puente de red y de interfaces de red virtuales

para facilitar interfaces de red a cada una de las máquinas virtuales que se ejecutan en el

nodo. Con el fin de proporcionar direcciones IP a máquinas virtuales, QVD también ejecuta

un servidor DHCP que asignará las direcciones IP dentro del rango de la red virtual a los

hosts virtuales a medida que se inician. Por lo tanto, es muy importante que se elija un

rango de red que sea poco probable que entre en conflicto con cualquiera de sus otras

infraestructuras existentes para este fin. Hay una serie de pasos de configuración que puede

ser necesario realizar manualmente para configurar correctamente la red para un nodo

servidor QVD. A menudo hay otras maneras de lograr una configuración de red apropiada,

por lo que se proporcionan sólo como directrices.

2.4.1.1 Establecer dnsmasq para ser controlado por QVD

QVD utiliza dnsmasq como servidor DHCP y DNS para las máquinas virtuales que se

ejecutan en un nodo. Para funcionar correctamente, dnsmasq necesita ser ejecutado por el

proceso HKD.

En primer lugar, se comprueba que dnsmasq está instalado. En Ubuntu, se ejecutan los

siguientes comandos y se comprueba el estado:

# dpkg -s dnsmasq

Si no está instalado, se realiza utilizando el gestor de paquetes, apt-get install dnsmasq.


De forma predeterminada, el paquete Ubuntu inicia el proceso que se ejecuta como un

demonio en segundo plano, así que se debe evitar que comience automáticamente. Esto se

hace con los siguientes comandos en Ubuntu:

# service dnsmasq stop

# sed -i s/ENABLED=1/ENABLED=0/ /etc/default/dnsmasq

Este paso es esencial para que QVD funcione utilizando la virtualización KVM. Para LXC

es posible especificar si se debe o no hacer uso de DHCP para configurar la red dentro de

sus máquinas virtuales [27].

2.4.1.2 Configurar el reenvío IP

La redirección IP (IP Forwarding) es necesaria para encaminar a los clientes a la ubicación

correcta. Puede habilitarla rápidamente ejecutando el siguiente comando.

# echo 1 > /proc/sys/net/ipv4/ip_forward

Desafortunadamente, al reiniciar el sistema host, este cambio se perderá. Para que sea

permanente, se puede editar /etc/sysctl.conf y descomentar la línea:

net.ipv4.ip_forward=1

Puede obligar a sysctl a recargar su configuración después de haber editado este archivo

ejecutando:

# sysctl -p

2.4.1.3 Configurar un puente de red

Hay varias formas de configurar el puente de red y el enrutamiento apropiado para

asegurarse de que un cliente QVD se enruta a la máquina virtual correcta. El método más

fácil es configurar una interfaz de red estática y un conjunto de reglas de enrutamiento

iptables para realizar el NAT necesario para traducir las direcciones IP entre su red real y

virtual. Para configurar su red en Ubuntu, edite el archivo /etc/network/interfaces y agregue

las líneas siguientes:

auto qvdnet0

iface qvdnet0 inet static

pre-up brctl addbr qvdnet0

pre-up iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source

192.168.0.2

pre-up iptables -t nat -A PREROUTING -d 10.12.113.13 -p tcp --dport 8443

-j DNAT --to-destination 10.3.15.1

post-down brctl delbr qvdnet0

address 10.3.15.1


netmask 255.255.255.0

Es importante señalar que en el ejemplo anterior se necesita cambiar la dirección IP

10.12.113.13 a la dirección IP de la interfaz de red a la que desea que los clientes se

conecten. En el ejemplo de arriba se usa el rango 10.12.113.0/24 para la red virtual

utilizada por QVD. Este rango debe ser único dentro de su infraestructura y debe dedicarse

al uso de QVD, de modo que los servicios que arranquen en QVD no interfieran en otros

sistemas dentro de su red.

Si bien hay otros enfoques más limpios para configurar su red, estos a veces tienen

problemas con interfaces de red particulares tales como WIFI. El enfoque mencionado

anteriormente debería funcionar para la mayoría de los sistemas. Una vez que se haya

escrito la configuración de red en el archivo de configuración, se debe levantar la interfaz

de puente de red.

# ifup qvdnet0

2.4.1.4 Configurar QVD para su red

Para que QVD administre correctamente la configuración de la máquina virtual y el

enrutamiento subsiguiente, se necesita cambiar algunos ajustes de configuración dentro de

QVD-DB. Se recomienda que se utilice la Utilidad de Administración CLI antes

mencionada de QVD para hacer esto. También se puede utilizar el WAT si ya lo ha

configurado.

Estos ajustes se utilizan para proporcionar un entorno de red dedicado para las Máquinas

virtuales. Se deben utilizar direcciones IP y rangos de red que no entren en conflicto con su

infraestructura de red existente. En el ejemplo a continuación se utiliza el rango

10.3.15.0/24 para la red virtual utilizada por QVD.

# qa4 config set tenant_id=-1,key=vm.network.ip.start,value=10.3.15.50

# qa4 config set tenant_id=-1,key=vm.network.netmask,value=24

# qa4 config set tenant_id=-1,key=vm.network.gateway,value=10.3.15.1

# qa4 config set tenant_id=-1,key=vm.network.dns_server,value=10.3.15.254

# qa4 config set tenant_id=-1,key=vm.network.bridge,value=qvdnet0

Si se está ejecutando AppArmor en la máquina host, se podrá comprobar que evita que las

máquinas host accedan a Internet. QVD tiene un perfil de AppArmor para QVD que está

disponible en los paquetes. En cualquier caso, también es posible deshabilitar AppArmor

con /etc/init.d/apparmor teardown. Esto detendrá AppArmor y permite ejecutar


normalmente QVD. Si esto es inaceptable en el entorno en producción, utilice el perfil

referido y pida ayuda al equipo de soporte QVD si es necesario.

En el Anexo II, se muestran las interfaces gráficas de acceso tanto para los usuarios y

clientes como para el administrador de QVD, demostrando así la eficiente instalación.

CAPÍTULO 3. OPERACIÓN DEL SISTEMA 54

CAPÍTULO 3. OPERACIÓN DEL SISTEMA

Todas las organizaciones gastan un tiempo considerable en la fase de operación y

representaran por tanto una parte importante del proyecto. A través de la fase de operación,

se comprueba el funcionamiento del sistema, monitorizando y administrando la

infraestructura para maximizar su rendimiento, capacidad, disponibilidad, con habilidad y

seguridad. Es en esta fase también, es donde se deben resolver problemas o realizar los

cambios necesarios.

Para este proyecto, es necesario modificar levemente el contenido de esta fase, de tal forma

que se realice en este momento una pequeña prueba de funcionamiento general y relegar a

la última fase, las pruebas en profundidad de la infraestructura, tras la fase de optimización.

Esta decisión es debida a que, aunque el sistema funcione correctamente, muchas de las

tareas de la fase de optimización son imprescindibles en un entorno de este tipo. Es decir,

realizar ahora unas pruebas de operación en profundidad no tendrá sentido sin antes incluir

todas aquellas funcionalidades que van a estar presentes en la infraestructura una vez puesta

en producción.

3.1 Pruebas de funcionamiento

Las pruebas básicas de funcionamiento realizadas en esta fase consisten básicamente en la

creación de un usuario y una máquina virtual a partir de una imagen de disco por defecto

que QVD proporciona en su página web para labores de prueba, a la que se accede desde

los distintos clientes disponibles en QVD (Windows, Linux, MAC OS y Android).

El único objetivo es comprobar que la instalación realizada hasta el momento y los clientes,

funcionan de forma correcta. De esta forma se puede continuar la instalación y

configuración de nuevas funcionalidades. Concretamente se probaron los escritorios

virtuales realizando tareas características de un usuario común de la disciplina “Sistemas de

Telecomunicaciones” en la carrera “Ing. Telecomunicaciones y Electrónica”. Estas tareas

consistieron en simulación y emulación de redes básicas utilizando, edición de textos (o

imágenes) y programas como Packet Tracer, GNS3, OMNET++ y LibreOffice.


En las Figuras 3.1a y 3.1b se muestra la pantalla de login que se ofrece a los usuarios

(desde un cliente de escritorio y desde un cliente Android respectivamente) y en las

sucesivas Figuras 3.2a y 3.2b se muestran las pruebas llevadas a cabo ya comentadas.

Figura 3.1a: Pantalla de login desde un

cliente de escritorio.

Figura 3.1b: Pantalla de login desde un

cliente móvil Android.

La figura 3.1a y b, muestran las interfaces de los usuarios, tanto para Windows como para

Android. Donde se definen parámetros como usuario, contraseña, servidor QVD y el tipo

de conexión.

Figura 3.2a: Prueba de QVD desde un cliente Windows.


El tipo de conexión se refiere al entorno de trabajo en el que se encuentra el usuario, debido

a que en base al tipo de conexión es el modo de operación del tráfico de red entre el cliente

y el servidor QVD.

Figura 3.2b: Prueba de QVD desde un cliente Android.

Las figuras 3.2a y b, muestran el espacio de trabajo por defecto luego de haberse realizado

la primera conexión. Se puede observar en este escritorio virtual los iconos referentes a la

suite LibreOffice entre otros. Como el objetivo de esta plataforma es hacer uso de

herramientas de redes basadas en software libre o libre de costo se procede a la instalación

de Packet Tracer y GNS3. Las figuras 3.3a y b, muestran el funcionamiento de estas

herramientas.


Figura 3.3a: Prueba de QVD trabajando con Packet Tracer.

Figura 3.3b: Prueba de QVD trabajando con GNS3.

3.2 Optimización del sistema

3.2.1 Autenticación externa

El primero y más necesario de los puntos de mejora de la infraestructura, es el realizar la

autenticación al sistema a través de un mecanismo como LDAP. Aunque QVD proporciona

su propio framework de autenticación (que almacena los usuarios dentro de la base de datos

de QVD), el uso de un mecanismo externo de autenticación en grandes organizaciones es

algo común.

En el servicio LDAP de la Universidad de “Las Villas” es el lugar donde se mantienen

centralizados una serie de datos de los miembros de la comunidad. De esta forma, una vez

configurado el mecanismo en el sistema QVD, cualquier usuario de la Universidad podrá

autenticarse en la infraestructura.

Para la realización de esta configuración, de nuevo fue necesaria la colaboración del

Departamento de Red de la UCLV, para permitir el acceso desde los servidores de la

infraestructura QVD al servicio LDAP. Los pasos técnicos de esta configuración se

muestran en el siguiente apartado.


3.2.1.1 Configuración LDAP

Los datos de LDAP mostrados a continuación, al igual que las direcciones IP anteriores son

reales y totalmente válidos para la explicación.

Dirección servidor LDAP: 10.12.1.50

Usuario: cn=ldap-squid,cn=users,dc=uclv,dc=edu,dc=cu

Una vez concedido el acceso (por parte del Departamento de Red) desde la red de las

maquinas QVD a la máquina del servicio LDAP, se prueba la conexión con siguiente

comando:

$ ldapsearch -xLLL -H ldap://10.12.1.50 \cn=ldap-

squid,cn=users,dc=uclv,dc=edu,dc=cu" -W -b \OU=Ingenieria en

Telecomunicaciones y

Electronica,OU=FAC_INGENIERIA_ELECTRICA,OU=SIGENU,OU=_Usuarios,DC=uclv,DC

=edu,DC=cu" \(objectClass=sAMAccountName)"

Como se observa en el comando anterior, la búsqueda de usuario solo se realiza en la

unidad organización referente a la carrera de Ing. Telecomunicaciones y Electrónica. Esto

significa que, por ahora, solo los estudiantes de dicha carrera tendrán accesos a estos

servicios de virtualización de escritorio. Comprobada la conexión, el acceso de lectura al

servidor LDAP es posible y se puede pasar por tanto al proceso de configuración.

Se instala el plugin siguiente en el nodo QVD.

$ apt install perl-qvd-l7r-authenticator-plugin-ldap

Se configura el LDAP mediante los scripts de administración instalados.

$ qa config set l7r.auth.mode=ldap (1)

$ qa config set auth.ldap.host=ldap://10.12.1.50:389 (2)

$ qa config set auth.ldap.base=OU=Ingenieria en Telecomunicaciones y

Electronica,OU=FAC_INGENIERIA_ELECTRICA,OU=SIGENU,OU=_Usuarios,DC=uclv,DC

=edu,DC=cu (3)

$ qa config set auth.ldap.binddn=cn=ldap-

squid,cn=users,dc=uclv,dc=edu,dc=cu (4)

$ qa config set auth.ldap.filter=(sAMAccountName=%{%{Stripped-User-

Name}:-%{User-Name}}) (5)

$ qa config set auth.ldap.scope=no (6)

El primero de los comandos simplemente dice al sistema que la autenticación se realizara a

través de LDAP. El segundo especifica la dirección y el puerto de escucha del servicio

LDAP. El siguiente, especifica el directorio de información del árbol. El cuarto sirve para

filtrar los resultados obtenidos de la consulta al LDAP y, por último, el alcance que permite

descender en el árbol.


Aplicadas las configuraciones, se reinicia el servicio L7R en los nodos QVD y el sistema

está preparado para realizar autenticación a través de LDAP.

$ service qvd-l7r restart

3.2.2 Auto provisión

Aunque el mecanismo de autenticación externa es muy útil, por sí solo no facilita la

administración de los sistemas, ya que, aunque no sea necesario crear todos los usuarios

manualmente, si debe crear una máquina virtual y realizar la asignación de esta a cada

usuario. Es por este motivo que la autenticación externa debe ser complementada con otro

tipo de métodos [27].

La auto provisión consiste en la creación y asignación automática de máquinas virtuales a

usuarios. Es decir, cuando un usuario es autenticado por primera vez, si este no dispone de

una VM, el sistema de auto provisión genera una nueva máquina y se la asigna a este de

forma totalmente transparente, tanto para los usuarios como para los administradores.

3.2.2.1 Configuración de auto provisión

La configuración del aprovisionamiento automático de máquinas virtuales es muy sencilla

y consta de los siguientes pasos:

1. Instalar el plugin de auto provisión en los nodos QVD de la infraestructura.

$ perl-qvd-l7r-authenticator-plugin-auto

2. Configurar los parámetros de la base de datos adecuados.

$ qa config set l7r.auth.plugins='auto,ldap' (1)

$ qa config set auth.auto.osfid=1 (2)

El primer parámetro indica a la infraestructura que debe emplear auto provisión

conjuntamente con LDAP y el segundo sirve para establecer la OSF (imagen de disco

parametrizada que se emplea como base para las máquinas).

3.2.3 Almacenamiento compartido

En el momento en el que una infraestructura, ya sea de arquitectura mononodo (como es el

caso) o multinodo, se hace indispensable la incorporación de un almacenamiento

compartido, de tal forma que sea accesible por todos los sistemas que componen la

infraestructura QVD. En la Figura 3.4 se observa un diagrama sencillo del acceso de los


hosts al almacenamiento. Para la creación de un sistema de almacenamiento en red, existen

diversas tecnologías. QVD ofrece compatibilidad con GFS, OCFS (sobre algún servidor

SAN) o bien con NFS.

Figura 3.4: La WAT y los nodos de QVD acceden a almacenamiento compartido.

3.2.3.1 Directorios afectados

Los ficheros que son objetivo de ser compartidos se albergan bajo el directorio

/var/lib/qvd/storage de los nodos. En este directorio, en función de la tecnología de

virtualización seleccionada existe unos subdirectorios u otros, pero en este caso se

describen aquellos que afectan a la virtualización KVM, por ser la empleada para este

proyecto.

staging: Se trata de un directorio de almacenamiento temporal para las imágenes de

disco que estarán disponibles a través de la interfaz web de administración para

poder ser manipuladas. Las imágenes de disco incluidas aquí están disponibles

mediante la opción “Add Image” de la WAT. Una vez añadida a través de la

interfaz, la imagen es copiada al directorio images. Es por tanto necesario el acceso

del nodo de administración (el nodo que contiene la WAT) a este subdirectorio.


images: Lugar de almacenamiento de las imágenes de disco que serán cargadas por

los nodos para cada una de las máquinas virtuales que sean lanzadas. Como es

lógico, debe estar accesible para todos los nodos de la infraestructura.

homes: Es el subdirectorio en el que se almacenan los datos del directorio home de

los usuarios. Existirá un fichero en formato .qcow para cada usuario. También

necesita ser accedido por los nodos.

overlays: Se emplea para almacenar datos que constantemente se escriben en los sistemas

operativos de las maquinas en ejecución. Almacenamiento de archivos temporales.

3.2.3.2 Selección de la tecnología

Tras conocer los directorios y subdirectorios susceptibles de ser compartidos, es necesario

escoger la tecnología a emplear para el servicio de almacenamiento compartido. La

disponibilidad de documentación por parte de QVD, la conocida estabilidad y seguridad, la

imposibilidad económica de disponer de una cabina SAN y el ya conocimiento de la

tecnología por parte de los administradores fueron condiciones clave para el uso de NFS

(Network File Storage) como protocolo de compartición de almacenamiento.

3.2.3.3 Diseño e implementación del almacenamiento compartido

Decidida la balanza a favor de NFS, es el momento de determinar donde se ubica el nuevo

servidor NFS: en un nuevo servidor dedicado (virtual) o como servicio en alguna de las

máquinas de la infraestructura. Dado el poco uso del hardware del servidor de

administración (maquina WAT y QVD) y el ahorro que supone el no emplear un servidor

adicional, es el sitio idóneo para ubicar el servidor NFS.

Para ello, únicamente es necesario conectar a este servidor un dispositivo de

almacenamiento adicional y convertir este en el espacio de almacenamiento compartido. Al

ser un servidor virtualizado a través de Proxmox VE, la tarea de añadir un dispositivo es

sencilla y aunque inicialmente es de unos pocos GB, es posible aumentar el tamaño cuando

sea necesario de forma fácil y rápida.

Un detalle importante en cualquier instalación NFS es la seguridad de los archivos, ya que

este no fue diseñado pensando en la seguridad. Aunque la seguridad es muy importante,

para este proyecto no es necesario tomar medidas adicionales, pues todo el sistema NFS y


los nodos se encuentran en una red Intranet completamente segura, donde solo acceden los

administradores de sistemas.

La implementación consiste en formatear y preparar ese nuevo dispositivo, mover los

archivos existentes en directorio /var/lib/qvd/storage del nodo al nuevo disco y realizar la

configuración del servicio NFS en la máquina tal y como se detalla a continuación.

3.2.3.4 Configuración del almacenamiento compartido: NFS

La configuración del servidor NFS se realiza en el servidor de administración (maquina

WAT y QVD). Se supone ya añadido un disco duro de 100GB (/dev/sdb).

1. Crear una única partición en el disco.

$ sudo fdisk /dev/sdb (opciones n para crear y w para guardar)

2. Formatear el disco en formato ext4.

$ sudo mkfs.ext4 /dev/sdb

3. Crear la carpeta que contendrá toda la información (imágenes de disco, datos de los

usuarios, directorios home, etc).

$ sudo mkdir /qvdstorage

4. Copiar la estructura de directorios de uno del nodo QVD al directorio anterior, ubicado

en el nuevo disco. (No fue necesario copiar la información, pues solo existen máquinas

virtuales de las pruebas realizadas).

$ scp -r [email protected]:/var/lib/qvd/storage/*/qvdstorage

5. Montar el directorio en el dispositivo /dev/sdb.

$ sudo mount /dev/sdb/qvdstorage

Nota: El comando anterior no es persistente. Al reiniciar el servidor se perderá la

configuración (el montaje). Es necesario realizar una configuración persistente.

6. Editar el fichero /etc/fstab y añadir:

/dev/sdb/qvdstorage ext4 defaults 01

7. Instalar los paquetes necesarios para el servidor NFS.

$ sudo apt-get install nfs-kernel-server

8. Realizar la configuración del servidor NFS. Editar el fichero /etc/exports.

/qvdstorage *(rw,sync,no subtree check,no rootsquash)


9. Reiniciar el servicio NFS.

$ /etc/init.d/nfs-kernel-server restart

10. Instalar el cliente NFS en el nodo de la infraestructura QVD (en el caso multimodo solo

en los nodos QVD y en el nodo de administración propiamente, ya que el nodo base de

datos no necesita acceso al almacenamiento compartido).

$ sudo apt-get installnfs-common

11. Configurar el cliente. Editar en el nodo cliente el fichero /etc/fstab para indicar donde

está el servidor NFS y que carpeta comparte.

10.12.113.13:/qvdstorage/var/lib/qvd/storage nfs rw

,soft,intr,rsize=8192,wsize=8192

12. Montar el directorio en el cliente.

$ mount /var/lib/qvd/storage

3.2.4 Balanceador de carga

QVD es una solución de escritorios completamente diseñada para funcionar en entornos de

balanceo de carga. Cualquier entorno en producción se requiere tanto la inclusión de un

balanceador hardware externo como la correcta configuración del balanceador de carga

integrado con L7R.

Balanceador hardware externo: Se sitúa antes de los nodos, de tal forma que se encargue de

aceptar las peticiones de los clientes. Su funcionamiento básico consiste en enviar la

petición del cliente a aquel nodo con menos carga. Para conocer el estado de carga de los

nodos se vale de un mecanismo conocido como "health checking", que consiste en el envío

de mensajes periódicos a través de HTTP a los que los nodos responden de la misma forma.

Una vez aceptada la petición del cliente y redirigida esta al nodo con menor carga, este

debe ser el encargado de levantar la máquina virtual del cliente si no está encendida o bien

redirigir de nuevo al cliente al nodo en el que ya se encuentra operativa su máquina virtual.

Balanceador interno: Se incluye dentro del demonio L7R. Es el encargado de redirigir las

peticiones entre un nodo y otro en función del lugar donde se encuentre levantada la

máquina virtual de un usuario. (Por ejemplo, si una maquina A corre sobre un nodo A y un

usuario se conecta al nodo B, este nodo B debe ser capaz de redirigir la petición del usuario

al nodo A). Consta de varios algoritmos de balanceo de carga de tal forma que permite


configuraciones diferentes en función de la característica a primar a la hora de iniciar una

VM en un nodo u otro: menor uso de CPU, menor ocupación de memoria, asignación de

nodo aleatoria, etc.

Para un entorno piloto de pruebas de dos nodos, como es el caso de este proyecto, es

suficiente la configuración del balanceador interno, que se detalla en el siguiente apartado,

quedando relegada la inclusión de un balanceador hardware a una mejora futura.

3.2.4.1 Configuración del balanceador de carga

Gracias al desarrollo del personal de QVD, la configuración del balanceador de carga es

trivial y básicamente consiste en la asignación de pesos a las prioridades en el reparto de la

carga. El algoritmo de balanceo de carga que incorpora L7R calcula la carga instantánea de

cada uno de los nodos del sistema, comprobando la RAM y la CPU libre de cada uno de

ellos.

QVD presenta tres posibles características a las que asignar pesos para el balanceo: la

RAM, la CPU o introduciendo un componente de aleatoriedad.

Si se incrementa el peso de la variable RAM en el algoritmo, el balanceador asigna

preferencia al nodo con más RAM disponible.

Si se incrementa el peso de la variable CPU, el balanceador asignara la preferencia

al nodo con más CPU disponible.

Si se incrementa el peso de la componente de aleatoriedad, el algoritmo de balanceo

asignara la preferencia aleatoriamente entre los nodos.

Todas estas características son configurables a través de parámetros de configuración

disponibles en la Base de Datos de la infraestructura y pueden ser variadas a través de los

scripts de configuración, tal y como se muestra a continuación:

$ qa config set l7r.loadbalancer.plugin.default.weight.cpu=3

$ qa config set l7r.loadbalancer.plugin.default.weight.ram=2

$ qa config set l7r.loadbalancer.plugin.default.weight.random=1

3.2.5 Configuracion SSL

Para aumentar la seguridad de sus conexiones, QVD puede hacer uso de HTTPS con un

certificado x509 y clave privada. En un entorno de producción real esto es altamente


recomendable, sobre todo el hacer uso de un certificado de una autoridad certificadora de

confianza como Let's Encrypt, Cacert o cualquier otro tipo de entidad certificada.

En este proyecto piloto, al estar presente en una red interna, se crea y configura el uso de

SSL a través de un certificado auto firmado, completamente valido y funcional.

1. Instalación de la paquetería de Open SSL.

$ apt-get install openssl

2. Se crea un subdirectorio dentro del directorio /etc/qvd para trabajar con los certificados

creados propiamente para la infraestructura.

$ mkdir /etc/qvd/certs

3. Dentro del directorio creado, se genera primeramente la clave privada del servidor, con

entropía 1024.

$ openssl gen rsa 1024 > qvd-server-private-key.pem

4. Con la clave privada creada, ya se puede crear un certificado auto firmado. Se crea un

certificado normal, con una validez de 180 días.

$ openssl req -new -x509 -nodes -sha1 -days 180 - key qvd-server-private-

key.pem > qvd-certificate.pem

Nota: Tras el comando anterior, durante la generación del certificado es necesario

introducir información del mismo en diferentes campos.

5. Configurar la infraestructura QVD para hacer uso del certificado haciendo uso de uno de

los scripts de administración.

$ qa configssl key=/etc/qvd/certs/qvd-server-private-key.pem

cert=/etc/qvd/certs/qvd-certificate.pem

6. Para que un certificado sea válido, es necesario añadirlo al directorio del sistema donde

se encuentran alojados todos los certificados de los que hace uso. Dicho directorio es

/usr/lib/ssl, en derivados de Debian, como es el caso.

Para que el protocolo SSL reconozca el certificado, por tanto, debemos copiarlo en el

directorio anterior o bien crear links simbólicos al mismo, que es lo que se realizara. A su

vez, se renombran también los certificados.

$ trusted_ssl_path=/usr/lib/ssl/certs

$ cert_path=/etc/qvd/certs/server-certificate.pem

$ cert_name=`openssl x509 -noout -hash -in $cert_path`.0

$ cp $cert_path $trusted_ssl_path/QVD-L7R-cert.pem


$ ln -s $trusted_ssl_path/QVD-L7R-cert.pem $trusted_ssl_path$cert_name

3.2.6 Componentes hardware

Desde el inicio del proyecto, se trabaja la posibilidad de ampliación de las máquinas

hardware hacia otras más potentes, una vez probado el entorno y finalizada su

configuración se procede a realizar una migración a otros nodos más potentes (no se detalla

los pasos seguidos para su configuración por ser idénticos a los ya mostrados en secciones

anteriores. Las nuevas máquinas físicas que alojan los posibles servidores de QVD son:

Servidores Dell PowerEdge 1955/1855 Blade Servers 2x2.2GHz Quad-Core AMD

Processor 8354 64-bit. Memoria: 16GB RAM. En la Figura 3.5 se muestra la maquina

descrita.

Con estos 5 servidores físicos, además de mejorar enormemente la potencia de la

infraestructura y la capacidad de dar servicio a un mayor número de usuarios, se mejora

también la disponibilidad del entorno, al convertir de esta forma al servicio VDI Linux en

un servicio de alta disponibilidad. Esto se produce por la localización física de ambos

servidores: Centro de datos de la UCLV.

Figura 3.5: Nuevas máquinas hardware para QVD.

3.2.7 Politica de copia de seguridad

Habilitar a una organización para continuar con sus operaciones principales en caso de

algún tipo de interrupción y darle la posibilidad de sobrevivir a un desastre que afecte a los

sistemas de información, son hoy en día unas de las principales tareas de todos los grupos

de seguridad informática.


Ataques informáticos y problemas como atentados o desastres naturales, incendios o en

algunos casos la maldad de ciertas personas, hacen necesario contar con un plan de

contingencia, aplicado a los sistemas y tecnologías de la información, capaz de devolver la

infraestructura a su estado natural.

Por otra parte, es importante resaltar el enfoque de este apartado, pues se deja de lado toda

la temática relacionada con los planes de contingencia, los tipos de copias de seguridad y

ciertos conceptos técnicos que serían objeto de trabajos completos por sí solos. Además, en

un proyecto de este tipo no resulta de especial importancia tratar en profundidad la política

de seguridad pues al tratarse de un proyecto destinado a pruebas no va a tratar con

información de usuarios ni ningún tipo de información importante.

La única labor de la política de seguridad que se aplica será la de salvaguardar todas

aquellas configuraciones ya realizadas para en caso de error o problema en la

infraestructura poder recuperarla a un estado consistente, sin necesidad de comenzar la

instalación desde el principio.

3.2.7.1 Backup de los servidores

El primero de los pasos en la copia de seguridad viene dado implícitamente gracias a la

infraestructura de la UCLV. Periódicamente se realiza una copia completa de cada uno de

los servidores y una copia incremental diaria, tanto de los servidores físicos como los

virtuales. Para una infraestructura de pruebas como la de este proyecto, esta política sería

más que suficiente, pero con el objetivo de una más rápida recuperación en caso de caídas o

problemas específicos se tomaron una serie de medidas adicionales que se describen en los

siguientes apartados.

3.2.7.2 Backup de las configuraciones

El primero de los planes de copia de seguridad de la solución QVD, es el resguardo de

todos y cada uno de los ficheros de configuración implicados hasta el momento. En la

infraestructura de la Universidad de “Las Villas”, existe un moderno y completo sistema de

respaldo que será el encargado de llevar a cabo esta labor, pasando diariamente por cada

una de las maquinas indicadas para realizar la copia de seguridad de los ficheros o

directorios indicados. Basta con una copia diaria, o incluso con una copia semanal, pues los

ficheros de configuración no sufren variaciones una vez realizados.


A continuación, se muestran los ficheros afectados en cada una de las máquinas.

- Servidor base de datos

/etc/qvd/node.conf: Es el fichero que almacena la información básica del nodo,

el lugar y las credenciales de la base de datos.

/etc/posgresql/9.3/main/pg-hba.conf y /etc/posgresql/9.3/main/posgresql.conf:

Son ficheros de configuración de la base de datos.

/etc/network/interfaces: Fichero de configuración de la red del servidor base de

datos.

- Servidor de administración

/etc/qvd/node.conf: Fichero de información del nodo de administración. Incluye

también el lugar y las credenciales del servidor base de datos y SGDB.

/etc/default/qvd-wat: Almacena el puerto de la interfaz de administración web.

/etc/apache2/sites-enabled/qvd-wat.conf: Fichero de configuración del servidor

Apache que ejecuta la aplicación web de administración.

/etc/fstab y /etc/exports: Contienen las configuraciones relacionadas con el

servidor NFS para el almacenamiento compartido. Recordar que el servidor de

administración realiza las tareas también de servidor NFS.

/etc/network/interfaces: Fichero de configuración de la red del nodo de

administración.

- Servidores QVD

/etc/qvd/node.conf: Fichero de información del nodo. Como los nodos QVD

también deben poder acceder a la base de datos, este también almacena las

credenciales de la misma.

/etc/fstab: Configuración del cliente NFS. Necesaria para poder montar el

almacenamiento compartido en cada uno de los nodos.

/etc/network/intefaces: Fichero de configuración de la red de los nodos de QVD.


3.2.7.3 Backup de las tablas de la base de datos

Para la copia de las tablas de la base de datos se optó por una sencilla solución: la

realización de un script que se ejecuta diariamente a las 5:00am y que copia todas las tablas

a una determinada localización en el servidor. Sera después el sistema de respaldo el

encargado de obtener la copia de las tablas, también de forma diaria.

Al igual que en todos los casos anteriores, es lógico que este tipo de política no sería para

nada adecuado para un futuro entorno en producción, pero suficiente para el entorno actual.

3.2.7.4 Backup del almacenamiento compartido

Tal y como se describe en secciones anteriores, la zona de almacenamiento compartido se

encuentra en un disco adicional conectado al servidor de administración y montado bajo el

directorio /qvdstorage. Es aquí donde se encuentran todos los datos de las máquinas

virtuales e imágenes de disco empleadas en las pruebas por lo que diariamente el sistema de

respaldo también copiara los datos de este directorio.

3.2.8 Mejoras futuras

Aunque desde un inicio no fue posible barajar la posibilidad de mejorar ciertos aspectos,

bien por desconocimiento pleno de la característica como por la imposibilidad de disponer

de equipos nuevos. Es por ello que se dedicara un pequeño apartado a tratar dos

características todavía en proceso de realización. Dichas actividades consisten en la

inclusión de un balanceador hardware (comentado en secciones anteriores) y la migración

de los equipos actuales a otros más actuales y potentes.

Balanceador hardware

La solución QVD ofrece una gran compatibilidad con el uso de balanceadores hardware y

ofrece mecanismos para facilitar su uso e inclusión en las infraestructuras. Otra de las

mejoras posibles y que se lleva a cabo en un futuro es la inclusión de un balanceador de

este tipo. Así, los clientes se conecta a la infraestructura a través del balanceador hardware

y es este el que envíe la petición del cliente al nodo con menos carga de trabajo en ese

momento. De esta forma, se complementa a la perfección con el balanceador interno con el

que cuenta la infraestructura.

Mejora de la seguridad


Aunque es uno de los apartados más a tener en cuenta en una infraestructura de futuro uso

público como esta, por motivos de falta de tiempo y necesidad de realizar análisis,

auditorías y estudios de seguridad, se incorpora a este apartado de trabajos pendientes a

corto plazo.

3.3 Conclusiones del capítulo

Este capítulo abarca la descripción y análisis de la solución seleccionada y la explicación de

todo el proceso de implantación de la infraestructura para su puesta en producción. El

proyecto sobre el que trata esta tesis es una solución de virtualización de escritorios Linux

orientada a completar y dar servicio a los diferentes equipos Linux distribuidos por los

diferentes años de la carrera de Ing. Telecomunicaciones y Electrónica de la Universidad

Central Marta Abreu de “Las Villas”, una vez en producción.

De todos los requisitos y objetivos iniciales a cumplir por parte de este proyecto destinado a

complementar la enseñanza de las asignaturas de Redes en la Disciplina de

Telecomunicaciones, la infraestructura configurada proporciona, todos ellos e incluso se

complementa con algunos otros adicionales. De este modo se consiguió obtener un

proyecto sólido y con características muy similares a las de cualquier entorno en

producción: capacidad, rendimiento, estabilidad y alta disponibilidad, todo ello en un

entorno real.

CONCLUSIONES Y RECOMENDACIONES 71

CONCLUSIONES Y RECOMENDACIONES

Conclusiones

Con la realización de este trabajo se obtuvieron los siguientes resultados:

1. Se caracteriza la información de los tipos de virtualización existentes vinculados a

los escritorios de trabajo lo cual permito implementar una plataforma VDI de

manera eficiente.

2. Se compararon las principales plataformas de virtualización de escritorios existentes

en el mercado lo cual permitió la selección de QVD como la más adecuada.

3. Se instaló y configuró la herramienta de código abierto QVD para la virtualización

de escritorios Linux.

4. Se implementaron diferentes escenarios de escritorios virtualizados utilizando

diferentes perfiles de usuarios.

5. Los resultados obtenidos, a partir de la evaluación del desempeño operacional de la

plataforma, pudieron constatar la propuesta de virtualización de escritorios para un

entorno de producción.

Recomendaciones

Tras la finalización de este proyecto, se abren una serie de líneas de continuidad que

permiten establecer nuevos objetivos a largo plazo, es por tanto que surge la necesidad de

cuantificar el estudio y direccionarlo hacia una línea de trabajo futuro:

Mejora hardware: Destinar una partida presupuestaria a la compra de hardware

potente y actual, para dar cabida a la totalidad de posibles usuarios de los escritorios

Linux.

Automatizacion de tareas: Creacion de programas o scripts que permitan realizar

de forma automática tareas de administracion características de un entorno

universitario.

Creación de Imagenes de disco: Creación de imagenes de disco personalizadas

para cada uno de los grupos de usuarios o incluso imagenes propias para la

imparticion de asignaturas determinadas. Por ejemplo, crear una imagen de disco de

CONCLUSIONES Y RECOMENDACIONES 72

una distribución Linux orientada a Seguridad, con software característico para

facilitar la docencia de una determinada asignatura.

Otras mejoras: En una infraestructura de este tipo siempre queda abierta a líneas

futuras por su naturaleza cambiante, en la que se deben introducir continuas mejoras

a medida que las necesidades de los usuarios son mas exigentes.

REFERENCIAS BIBLIOGRÁFICAS 73

REFERENCIAS BIBLIOGRÁFICAS

1. Petrović, T. and K. Fertalj. Demystifying desktop virtualization. in Proceedings of

the 9th WSEAS international conference on Applied computer science. 2010.

World Scientific and Engineering Academy and Society (WSEAS).

2. Hwang, J. and T. Wood. Adaptive dynamic priority scheduling for virtual desktop

infrastructures. in Proceedings of the 2012 IEEE 20th International Workshop on

Quality of Service. 2012. IEEE Press.

3. Meza, A.C., M.L. Trujillo, and L.J. Aguilar, COMPETENCIAS PROFESIONALES

Y ORGANIZACIONALES EN EL PROCESO DE DESARROLLO DE

SOFTWARE.

4. Chávez, S., et al. Metodología AGIL para el desarrollo SaaS. in XIV Workshop de

Investigadores en Ciencias de la Computación. 2012.

5. Toledo Valera, R., Servicios de gestión empresarial para PYMEs: un caso práctico

de SaaS (Software as a Service). 2010.

6. Merlino, H., Inclusión de servicios en aplicaciones basados en patrones de

usabilidad. 2014, Facultad de Informática.

7. Turner, M., D. Budgen, and P. Brereton, Turning software into a service.

Computer., 2003. 36(10): p. 38-44.

8. Buxmann, P., T. Hess, and D.-W.-I.S. Lehmann, Software as a Service.

Wirtschaftsinformatik, 2008. 50(6): p. 500-503.

9. SHAHZAD, S. and S.A. ALI, UCloud: The Concept and Design. Sindh University

Research Journal (Science Series), 2013. 45(3).

10. Murazzo, M.A., et al. Desarrollo de aplicaciones para Cloud Computing. in XVI

Congreso Argentino de Ciencias de la Computación. 2010.

11. PORRAS, R.P., SIMULADOR DE SISTEMAS EMPOTRADOS BASADO EN

UNA INTERFAZ WEB. 2010.

12. Rodríguez, N., et al. Interoperabilidad en cloud computing. in XIII Workshop de

Investigadores en Ciencias de la Computación. 2011.


13. Zalazar, A.S., S. Gonnet, and H. Leone, Selection of Cloud Computing Services

Using Reinforcement Learning.

14. Duque Velásquez, C., Software como servicio en aplicaciones de misión crítica:

ERP y CRM en la mediana empresa. 2008.

15. Casallas, P. and R. Pineda, Plan de negocios creación de una empresa de desarrollo

de software en modalidad outsourcing. 2014.

16. Barrios Castillo, D.E. and J.P. Barrientos Matute, Los sistemas distribuidos, bajo el

enfoque de cloud computing y sus aplicaciones. INGENIATOR, 2011. 2(2).

17. Ding, J.-H., et al., A framework of cloud-based virtual phones for secure intelligent

information management. International Journal of Information Management, 2014.

34(3): p. 329-335.

18. KESRAOUI, M., Conception et développement d’un bureau Virtuel «WebTop».

2013, Université Virtuelle de Tunis.

19. Cordeiro, M.S., VIRTUALIZAÇÃO DE ESTAÇÕES DE TRABALHO.

20. Cáceres Mangas, H.d., Tecnología cloud para el hogar digital. 2013.

21. Felicísimo, Á.M. and A. García-Villanueva, Uso de escritorios remotos en la

enseñanza: una experiencia con aplicaciones de código abierto. Ciencia, Docencia y

Tecnología, 2015. 26(50): p. 207-223.

22. O'Donovan, M., Qlik Sense For Beginners. 2014: TechStuffy Books.

23. Group, Q., QVD Installtion Guide. 2018.

24. Martín, D., et al., Virtualización, una solución para la eficiencia, seguridad y

administración de intranets. El profesional de la información, 2011. 20(3): p. 18-04.

25. Group, Q., QVD (Quality Virtual Desktop). 2017.

26. Nicolas Arenas, D.S., Salvador Fandiño, Nito Martinez, QVD Administration

Manual. 2014.

27. Group, Q., QVD Docs Team. 2018.

28. Umpiérrez Rodríguez, M.J., Gestor web de recursos geoespaciales con tecnología

Openlayers. 2014.

29. DOCUMENTATION, Q., QVD Installtion Guide. 2018.

30. Zadeh, M.H.K., SECURE INTELLIGENT INFORMATION MANAGEMENT BY

USING A FRAMEWORK OF VIRTUAL PHONES BASED ON CLOUD


COMPUTATION. Kuwait Chapter of the Arabian Journal of Business and

Management Review, 2014. 3(11A): p. 173.

31. Ochoa Polo, J.C., Metodología y procedimientos para el uso de software de diseño

asistido por computador y su conexión a sistemas de información geográfica en el

GAD Municipal del Cantón Cuenca. 2015.

32. QVD Disk Image Creation (Ubuntu 16.04). 2018.

33. Brown, S.A., Getting Started with Citrix VDI-in-a-Box. 2013: Packt Publishing Ltd.

ANEXOS Y GLOSARIO

ANEXOS

Anexo I Modelo de base de datos relacional de PostgreSQL para QVD.

AI.1: Modelo de base de datos relacional de PostgreSQL para QVD.

ANEXOS 77

Anexo II Interfaz Web de QVD

AII.1: Interfaz de login para un Usuario. Cliente HTML5.

AII.2: Interfaz de login QVD para un Administrador. Cliente HTML5.

ANEXOS 78

AII.3: Web GUI para un usuario.

AII.4 Web GUI para un administrador

ANEXOS 79

AII.5 Minimal Client QVD Appliance VDI

Anexo III Gestión de QVD a través de WAT.

AIII.1 WAT “Default Command”.

ANEXOS 80

AIII.1 WAT “Config Host”.

ANEXOS Y GLOSARIO

GLOSARIO

CPD Centro de procesamiento de datos

GFS Global File System

OCFS Oracle Cluster File System

OCFS2 Oracle Cluster File System Version 2

HA High Availability

KVM Kernel-based Virtual Machine

LDAP Lightweight Directory Access Protocol

LXC Linux Containers

NFS Network File System

SAN System Area Network

SCSI Small Computer System Interface

SGBD Sistema de Gestión de Bases de Datos

SPICE Simple Protocol for Independent Computing Environments

SPOF Single Point of Failure

VDI Virtual Desktop Infraestructure

VM Virtual Machine

VMM Virtual Machine Monitor

Documents

Título: Virtualización de escritorios empleando