Implementación de una solución VDI para escritorios Linux en la Universidade da Coruña

Transcripción

1 Facultad de Informática Trabajo fin de grado Grado en Ingeniería Informática Tecnologías de la Información y las Comunicaciones Implementación de una solución VDI para escritorios Linux en la Universidade da Coruña Autor: Director profesional: Director académico: Xacobe Macía da Silva Antonio Daniel López Rivas Francisco Javier Nóvoa de Manuel A Coruña, a 24 de septiembre de 2014

2

3 Copyright (C) 2014 XACOBE MACÍA DA SILVA. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

4

5 D. A. Daniel López Rivas Técnico de Sistemas Universidade da Coruña D. Fco J. Nóvoa de Manuel Profesor Ayudante Doctor Universidade da Coruña CERTIFICAN: Que la memoria titulada Implementación de una solución VDI para escritorios Linux en la Universidade da Coruña ha sido realizada por Xacobe Macía da Silva bajo nuestra dirección en la Universidade da Coruña y concluye el proyecto que presenta para optar al Grado en Ingeniería Informática. A Coruña, 24 de septiembre de 2014 D. A. Daniel López Rivas Director profesional D. Fco. J. Nóvoa de Manuel Director académico

6

7 A mis abuelos, a los que están y a los que no; por todas las historias que me habéis contado y por las que os quedan por contar.

8

9 Agradecimientos Mis primeras palabras de agradecimiento no pueden ser a otras personas que no sean mis tutores Daniel y Fran. Gracias por vuestro tiempo, paciencia e interés, por vuestra amabilidad y tranquilad, por vuestras enseñanzas, por permitirme realizar este proyecto y sobre todo, por darme la oportunidad de conoceros. Unas breves líneas no son ni serán nunca suficientes para agradecer a las dos personas más importantes en mi vida, mis padres. Padres buenos hay muchos, pero buenos padres sólo vosotros. Gracias. A una persona muy especial, por haber sido y seguir siendo mi compañera de viaje durante estos años, por animarme y comprenderme siempre. Gracias Judit. Por último y no menos importante, gracias a todas esas personas que conocí y compartieron conmigo todos estos años de facultad, hoy grandes amigos. Gracias haber compartido y seguir compartiendo una parte de vosotros conmigo. De verdad, gracias. Xacobe Macía da Silva A Coruña, a 24 de septiembre de 2014

10

11 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. Se trata de un modelo que ha funcionado correctamente durante décadas, pero con altos costes de mantenimiento, grandes ciclos de configuración y puesta en funcionamiento y vulnerabilidades en la seguridad. Todos estos factores impulsan a las organizaciones a considerar soluciones informáticas más sencillas, autónomas, eficientes y seguras. 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. Mediante el uso de Thin Clients, dispositivos móviles o equipos convencionales, los usuarios pueden acceder a sus escritorios desde cualquier lugar, tanto dentro como fuera del entorno corporativo, proporcionando así una gran flexibilidad y movilidad. Con el amparo de la experiencia previa de la Universidade da Coruña en el despliegue de una infraestructura Windows, 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 UDC, la realización del diseño, la implantación y despliegue de la infraestructura en el entorno corporativo real de la Universidad. Todo ello, desde la perspectiva de un proyecto piloto que permitirá, en un futuro cercano, cubrir y completar las necesidades de la comunidad universitaria.

12

13 Palabras clave Virtualización Escritorios Linux Universidade da Coruña VDI QVD Open Source

14

15 Índice general Página 1. Introducción Motivación Objetivos Estructura de la memoria Planificación Metodología de desarrollo Definición de tareas Estimacion de tareas Seguimiento del proyecto Problemas Estimación de costes Contextualización Virtualización i

16 ÍNDICE GENERAL ii Conceptos básicos Un poco de historia Tipos de virtualización Virtualización de plataforma Virtualización de recursos Virtualización de aplicaciones Virtualización de biblioteca (API) Virtualización de escritorios Virtualización de escritorios Conceptos básicos Ventajas e Inconvenientes Ventajas Inconvenientes Soluciones en el mercado actual VMware Horizon View Microsoft VDI Citrix XenDesktop Citrix VDI in a BOX Oracle VDI Ulteo QVD RedHat Enterprise Virtualization for Desktops

17 ÍNDICE GENERAL iii 4. Virtualización de escritorios en la UDC Situación de partida Usuarios y personal Situación actual Por qué VDI? Infraestructura VDI Por qué VDI Linux? Posibles alternativas Ulteo Descripción Características Comparativa de versiones Requisitos técnicos Soporte QVD Descripción Características Comparativa de versiones Requisitos técnicos Soporte Red Hat Enterprise Virtualization: Spice Descripción

18 ÍNDICE GENERAL iv Características Requisitos técnicos Soporte Comparativa de productos Comparativa de las versiones de pago Comparativa de las versiones gratuitas Solución a implantar Implantación Qué es QVD? Componentes principales Componentes secundarios Componentes internos L7R HKD Objetos Arquitectura Tecnologías de virtualización Virtualización KVM Virtualización LXC Diseño del sistema Selección de la tecnología Diseño de la arquitectura de QVD

19 ÍNDICE GENERAL v Diseño de la arquitectura de red Implementación del sistema Configuración de la base de datos Configuración del servidor de administración Configuración de los nodos QVD Operación del sistema Pruebas de funcionamiento Optimización del sitema Autenticación externa Auto provisión Almacenamiento compartido Balanceador de carga Configuración del balanceador de carga Configuración SSL Componentes hardware Politica de copia de seguridad Mejoras futuras Conclusiones Evaluación del trabajo realizado Difusión del trabajo Líneas de trabajo futuro Reflexión personal

20 ÍNDICE GENERAL vi A. Glosario de acrónimos 146 B. Glosario de términos 147 C. Análisis y prueba de Raspberry Pi como Thin Client 150 C.1. Pruebas básicas C.2. Mejoras de rendimiento C.3. Alternativas Bibliografía 154

21 Índice de figuras Figura Página 2.1. Metodología PPDIOO Estimación de las tareas Diagrama de Gant estimado Duración real de las tareas Diagrama de Gant real Diagrama máquina virtual de sistema Diagrama hipervisor tipo I Diagrama hipervisor tipo II Panel frontal IBM Sistema IBM System/ Mainframe IBM System 370/Advanced Function Esquema virtualización completa vs paravirtualización Esquema virtualización de escritorios Thin Client Dell Wyse vii

22 ÍNDICE DE FIGURAS viii 4.1. Distrubución de las máquinas en los armarios rack Esquema básica de QVD Esquema de QVD con componentes adicionales Arquitectura general de QVD Interacción cliente-servidor y L7R Esquema básico cliente-servidor de una infraestructura QVD Esquema básico administración-servidor de una infraestructura QVD Máquinas hardware para QVD Arquitectura de QVD en la UDC Arquitectura de red para QVD en la UDC Modelo relacional de la base de datos de QVD Administración de hosts a través de la interfaz web Administración de máquinas virtuales a través de la interfaz web Pantalla de login desde un cliente de escritorio Pantalla de login desde un cliente Android Prueba de QVD desde un cliente Windows Prueba de QVD desde un cliente Android Prueba de QVD desde un cliente Mac OS Prueba de QVD trabajando con LibreOffice Prueba de navegación con QVD Acceso a almacenamiento compartido Nuevas máquinas hardware para QVD

23 ÍNDICE DE FIGURAS ix C.1. Monitorización de la Raspberry Pi en estado original C.2. Monitorización de la Raspberry Pi con overclocking

24 Índice de cuadros Tabla Página 2.1. Costes del proyecto Resumen ventajas e inconvenientes VDI Comparativa de versiones de Ulteo Comparativa de versiones de QVD Comparativa de alternativas de pago: Clientes Comparativa de alternativas de pago: Administración Comparativa de alternativas de pago: Soporte Comparativa de alternativas de pago: Precio Comparativa de alternativas gratuitas: Clientes Comparativa de alternativas gratuitas: Administración Comparativa de alternativas gratuitas: Soporte Estados de una máquina virtual en QVD x

25 ÍNDICE DE CUADROS xi

26 Capítulo 1 Introducción Índice general 1.1. Motivación Objetivos Estructura de la memoria Motivació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. 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 así las plataformas de Virtualización de Escritorios (Virtual Desktop Infraestructure). La tecnología VDI se ajusta a la idea de sustituir el PC dedicado en las actividades cotidianas, especialmente en el mundo educativo donde cada usuario tiende a utilizar su propio dispositivo móvil para la conexión a las redes y servicios del campus. Por ello se hace necesario potenciar la presencia de esta tecnología en la Universidade da Coruña, 1

27 1. Introducción 2 en la que actualmente ya se cuenta con una plataforma de este tipo para escritorios Windows. Una de las filosofías de la Universidade da Coruña radica en trabajar a favor del fomento y la promoción del software libre y de los estándares abiertos, así como apostar por la tecnología española, de cara a conseguir unos modelos tecnológicamente más sostenibles y fácilmente administrables, y todo ello primado por el ahorro de costes. Así, con el objetivo de dar respuesta a las mencionadas necesidades de movilidad del alumnado y del personal de investigación, y buscando un alto rendimiento y la optimización de recursos, surge la idea de implantar una solución basada en escritorios virtuales Linux, que proporcione la seguridad imprescindible en un entorno universitario que en esencia tiende a ser vulnerable, y que además permita dar servicio a los innumerables dispositivos móviles de los que se dispone actualmente conectándose desde diferentes puntos de acceso. Con esta solución se aumenta la flexibilidad de los usuarios de la comunidad universitaria de una forma segura y a su vez se mejora la eficiencia de los equipos Linux ya distribuidos por los diferentes campus y facultades Objetivos El objeto de este proyecto es analizar y posteriormente implantar una infraestructura de virtualización de escritorios Linux, tratando también de explicar de forma breve y concisa el amplio panorama de la temática VDI en general. Consistirá básicamente en el diseño, configuración y despligue de una plataforma plenamente funcional, pero desde la perspectiva de un proyecto piloto, para labores de prueba y evaluación de la aceptación por parte de la comunidad universitaria. Además, se pretende cumplir los siguientes objetivos, complementarios a lo anterior: Ofrecer una perspectiva de la virtualización en general, desde sus orígenes hasta la actualidad, con sus ventajas e inconvenientes. Dar una visión lo suficientemente amplia para analizar y seleccionar entre varias plataformas de virtualización de escritorios existentes (tanto Open Source como privativas). Se escogerá aquella que mejor se adapte a los requisitos necesarios para la Universidade da Coruña.

28 1. Introducción 3 Relización del proyecto teniendo en cuenta siempre las posibles necesidades futuras de eficiencia, alta disponibilidad y escalabilidad Estructura de la memoria forma: La presente memoria del proyecto está estructurada en capítulos de la siguiente Introducción: Trata el marco sobre el que se desarrolla el proyecto, el problema a resolver y los objetivos a lograr. Planificación: Explica todos los detalles relacionados con el plan de proyecto, las tareas llevadas a cabo, la estimación de las mismas y la metodología empleada durante el proyecto. Contextualización: Ofrece una visión global del ámbito en el que se desarrolla el proyecto, la virtualización, abordado desde un punto de vista teórico. Virtualización en la UDC: Realiza una descripción breve y concisa del entorno y de la situación de partida en la Universidade da Coruña. Posibles alternativas: Muestra el análisis previo a todo el trabajo realizando una elaborada comparativa de las posibles soluciones VDI Linux disponibles en el mercado para decantarse por la ideal para el entorno de la UDC. Implantación: 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. Conclusiones: Proporciona una evaluación del trabajo realizado y las posibles líneas de explotación y mejora futura del proyecto en su puesta en producción. Apéndices: Formado por varios documentos: Glosario: Subdividido a su vez en dos: Un glosario de términos y un glosario de acrónimos. En el primero se definen todos los términos técnicos empleados en la memoria y en el segundo de ellos se muestra el significado de todos los acrónimos.

29 1. Introducción 4 Proceso de instalación: Documento puramente técnico que muestra los pasos necesarios para la instalación de la infraestructura QVD exclusivamente, sin entrar en instalaciones complementarias. Pruebas con clientes ligeros: Recoge una serie de pruebas realizadas para el uso de una Raspberry Pi como cliente de acceso ligero a los escritorios virtuales. Bibliografía: Listado de documentos, libros y material digital empleados para la realización del proyecto.

30 Capítulo 2 Planificación Índice general 2.1. Metodología de desarrollo Definición de tareas Estimacion de tareas Seguimiento del proyecto Problemas Estimación de costes Este capítulo está dedicado a la planificación del proyecto, identificando todas las actividades a llevar a cabo para alcanzar los objetivos descritos en la Sección 1.2, estimando todo el esfuerzo y la duración de cada una de ellas. De esta forma, se puede conocer en cualquier momento si el proyecto sufre alguna desviación del plan inicial previsto para poder aplicar las correciones oportunas. Como en cualquier proyecto real, realizar una buena planificación será vital para lograr un trabajo rápido, eficiente y organizado, además de evitar problemas inesperados que causen retrasos en la realización del proyecto. 5

31 2. Planificación Metodología de desarrollo El primero de los pasos antes de abordar la realización del proyecto es la decisión de la metodología a emplear, para posteriormente adecuar a dicha metodología las tareas a realizar. Esta selección debe ser estudiada y analizada previamente pues definirá el marco de trabajo y la guía para todo el proyecto. Para el desarrollo de este proyecto, la decisión de la metodología es relativamente sencilla, pues al tratarse de un proyecto de implantación de un sistema, existen múltiples metodologías completamente validadas y con resultados satisfactorios en la mayoría de los casos. Un ejemplo es la metodología PPDIOO 1 desarrollada por Cisco 2 para el despligue de redes corporativas. La metodología PPDIOO [7] permite formalizar el ciclo de vida (y despligue) de una red en seis fases: Preparación, Planificación, Diseño, Implementación, Operación y Optimización. Cada una de ellas cumple con su función específica y se relacionan con su antecesora y predecesora. En la Figura 2.1 se muestra el ciclo de vida de acuerdo con la metodología PPDIOO [7]. Figura 2.1: Metodología PPDIOO Aunque la metodología PPDIOO está diseñada inicialmente para el despligue de redes de comunicación corporativas, se adapta a la perfección a cualquier proyecto de 1 Preparación, Planificación, Diseño, Implementación, Operación y Prueba 2

32 2. Planificación 7 sistemas que impligue la implantación de una infraestructura, simplemente con unas pequeñas variaciones teóricas en la metodología. A continuación se muestra la descripción de cada una de las fases del ciclo PPDIOO [8] adaptado a este proyecto. Fase de preparación: Es la primera de las fases. En ella, fundamentalmente se definen los objetivos, las limitaciones, el personal requerido, la estrategia a seguir, el presupuesto y se analizan todos y cada uno de los condicionantes iniciales. Se establecen aquí las decisiones a cerca de en qué va consistir el proyecto, qué tecnologías se van a emplear y de que forma se realizará. Fase de planificación: Esta fase involucra el análisis de la infraestructura actual y la definición de los requerimientos de la organización. Es importante barajar aquí las ventajas e inconvenientes y realizar un buen plan de proyecto para administrar las tareas. Fase de diseño: En esta fase se realiza el diseño de la infraestructura en base a lo analizado y establecido en las fases anteriores. Incluye la realización de diagramas de red y lista de equipos, de tal forma que muestre de forma clara y concisa toda la información. Una vez aprobada esta fase, empieza la implementación. Fase de Implementación: Instalación y configuración de todo el equipamiento. Es la fase de aplicación del plan de proyecto. Cualquier cambio o variación del diseño en esta fase debe ser debidamente justificado y previamente analizado. Fase de Operación: Es la fase más larga de la metodología PPDIOO. Consiste en la monitorización, gestión, actualización y control de la infraestructura en su funcionamiento diario. Además deben identificarse y corregirse los errores detectados. Es la fase de prueba del diseño. Fase de Optimización: Abarca la administración pro-activa, es decir, identificar y resolver cuestiones que afecten a la infraestructura. Es común que se produzcan pequeñas variaciones en el diseño durante esta etapa, sobre todo a la hora de mejorar cuestiones relacionadas con el rendimiento y las funcionalidades.

33 2. Planificación Definición de tareas A continuación, se muestra el desglose de tareas de las que se compone el proyecto, agrupadas en las etapas de la metodología empleada descrita en la Sección 2.1. Fase de preparación Esbozo: Es la primera tarea del proyecto. Se compone de una serie de reuniones en la que se definen los objetivos del proyecto, la infraestructura disponible, el presupuesto y se acuerda un plan de trabajo y horario a seguir. Estudio previo: Tarea destinada al análisis de las alternativas de virtualización de escritorios disponibles en el mercado actual. Comparativa: Selección de varias soluciones candidatas y realización de una exahustiva comparativa de características de todos sus aspectos: funcionalidades, soporte, precio, etc. Prueba: Comprende la realización de pruebas prácticas con las versiones de evaluación de cada una de las candidatas para conseguir una visión más amplia antes de seleccionar la solución a implantar. Decisión: Esta tarea incluye la selección de la solución a implantar, tras la fase de pruebas. Una vez tomada la decisión, comenzará la ejecución del proyecto. Fase de planificación Realización del plan de proyecto: Engloba la realización de este sencillo plan de proyecto. Análisis de requisitos: Trata la lectura de la documentación relacionada con la solución VDI seleccionada para implantar, para conocer las necesidades técnicas de la misma. Fase de diseño Diseño de la infraestructura: En función de la documentación de la solución y de la infraestructura disponible, realizar un diseño previo.

34 2. Planificación 9 Diseño de la red: Al igual que en el caso anterior, basándose en la documentación, es necesario elaborar un diseño de la infraestructura de red necesaria. Fase de implementación Preparación de la infraestructura: Se centra en el montaje y configuración de los equipos físicos y/o virtuales necesarios para instalación de la solución. De igual forma, se tratan aquí la creación de la/s red/es de comunicaciones necesaria para la infraestructura VDI. Instalación: Es una de las tareas más largas. Se realiza aquí toda la implementación, instalación y configuración para el funcionamiento básico del conjunto. Fase de Operación Pruebas básicas: Tarea en la que se realizan todas las pruebas necesarias para comprobar el funcionamiento de la solución VDI. Se realizan aquí pruebas objetivas, a través de la monitorización de la misma. Pruebas de clientes: Comprobada la funcionalidad, se realizan pruebas de los clientes software de acceso a los escritorios virtuales. Otras pruebas: Se incluye aquí una tarea adicional para la realización de pruebas personales o de investigación, si así se desea. Fase de Optimización Instalaciones adicionales: Tarea que trata la instalación y configuración de funcionalidades adicionales de una solución VDI. Estrategía de backup: Destinada a la elaboración de una politica de backup. Aunque pueda considerarse adecuado incluir esta tarea en la etapa de diseño, se ubicó en esta etapa ya que tras la instalación de la infraestructuras se posee un mayor conocimiento de la misma y de esta forma el diseño de la política de backup será más completo. En las tareas comentadas anteriormente no se incluye en ningún punto la elaboración de esta memoria, por considerarse de forma implícita una tarea paralela a todas las anteriores. Si se tendrá en cuenta la existencia de una tarea final dedicada al repaso y revisión de toda la documentación una vez finalizada, en la que se aplicarán las correcciones y mejoras necesarias.

35 2. Planificación Estimacion de tareas La estimación de la duración del proyecto y de cada una de las tareas se realizó basándose en la metodología descrita en la 2.1 y el desglose de tareas realizado en la Sección 2.2. Para la realización del proyecto y la estimación de las tareas, se tomó como base una jornada laboral de 4h diarias de lunes a jueves, con la existencia de un pequeño descanso y un parón quincenal por la época de exámenes finales. Aunque normalmente este tipo de cuestiones no se tratan como tareas, en este caso se consideró oportuno el tenerlas en cuenta para así dar una visión más global y clara de la duración y la influencia de dichos parones en el proyecto. La utilización de herramientas automatizadas que existen en el mercado puede facilitar la estimación de un proyecto e incluso permiten contrastar dicha estimación con el seguimiento del mismo, es decir, comparar la situación en la que se encuentran con la prevista durante esta etapa. La herramienta seleccionada para la estimación y seguimiento de las tareas de este proyecto es GanttProyect 3, debido a su sencillez y compatibilidad con la filosofía software libre del proyecto. Las tareas, la fecha de inicio, duración y fecha de finalización prevista se muestra en la Figura 2.2. Además, a partir de ellas se generó el diagrama de Gant estimado, mostrado en la Figura

36 2. Planificación 11 Figura 2.2: Estimación de las tareas Figura 2.3: Diagrama de Gant de estimación 2.4. Seguimiento del proyecto La actividad de seguimiento de un proyecto, tiene como principal objetivo el control de todas las tareas de las que se compone, revisando todos los puntos clave: respon-

37 2. Planificación 12 sables, estado en el momento del seguimiento, evolución previsible y problemas que se están encontrando y se encontraron durante su ejecución. La lista de las tareas y la fecha de inicio, duración y fecha de finalización real se muestra en la Figura 2.4 extraída de la aplicación GantProyect. El diagrama de Gant de la duración real de las tareas se presenta en la Figura 2.4. Figura 2.4: Duración real de las tareas Figura 2.5: Diagrama de Gant real

38 2. Planificación Problemas A continuación se detallan las tareas que fueron objeto de problemas, así como también la explicación del problema y la resolución del mismo. Tarea prueba: Se produjo el retraso de un día por motivos de incompatibilidad Java en las pruebas realizadas con la solución de virtualización Ulteo. La solución consistió en la prueba de diferentes versiones del motor de ejecución Java y niveles de seguridad. Tarea análisis de requisitos: Retraso de un día debido al desconocimiento inicial. Documentación desconocida y complicada. Fue necesario realizar diversas consultas y revisar documentación adicional para la total comprensión de los conceptos. Tarea preparación de la infraestructura: Se generó un retraso de un día por imposibilidad de acceso al Centro de Datos donde se ubican los equipos hardware, por problemas ajenos al proyecto. Tarea instalación: Es una de las tareas más largas y en la que más retrasos se acumularon. Existieron aquí diversos tipos de problemas, algunos de gravedad y otros característicos de cualquier proyecto de sistemas. Los más importantes por retraso acumulado fueron: Configuración Apache: Una vez realizada la configuración del servidor Apache del servidor de administración, se detectó un error en el acceso a la interfaz web de administración. El problema residía en los permisos de lectura y escritura de los ficheros de configuración y log del Apache. Aunque a simple vista es un error típico y sencillo, debido al conjunto de configuraciones y a la poca experiencia en este tipo de proyectos, ocasionó un retraso significativo en la planificación del proyecto. Configuración de la red: Problema ocasionado por las características de la infraestructura. Fue necesario idear una configuración personalizada y adaptada a la red de la Universidad, completamente diferente a la mostrada en la documentación técnica de la solución. Desconocimiento: A pesar de ya contemplarse este problema en la planificación del proyecto, el desconocimiento inicial de muchas de las tecnologías

39 2. Planificación 14 a emplear en el proceso de instalación, provocó la necesidad de analizar documentación adicional, retrasando la tarea. Tarea instalaciones adicionales: Dentro de esta tarea existieron también muchos problemas menores y otros importantes como los citados a continuación: Conexión servidor LDAP: Problemas de conexión con el servidor LDAP desde la infraestructura. Se trata de un problema ajeno a este proyecto y dependiente del Departamento de Red. La coincidencia de este con un problema mayor que afectaba a la red de toda la infraestructura de la Universidade da Coruña provocó un retraso considerable. Espacio de almacenamiento: El agotamiento del espacio de almacenamiento del servidor de administración en la partición raíz ocasionó una serie de fallos de este que fue necesario solventar. Conexión entre nodos: Es probablemente el problema más grave (en lo que a retraso se refiere) ocurrido en el proyecto. Un error en el diseño de la red y la configuración de esta, provocó que fuese necesario realizar una nueva configuración, ya que la anterior no permitía la conexión entre los nodos de la infraestructura, derivando incluso a el mal funcionamiento del balanceador de carga interno y de las máquinas virtuales. Para dar con la solución fue necesario realizar una consulta al soporte técnico Estimación de costes Esta sección se dedicará a tratar de estimar lo mejor posible los costes del desarrollo de este proyecto, teniendo en cuenta que existen una serie de variables que dificulta dicha tarea. Para poder estimar el presupuesto teórico de la realización del proyecto, es necesario tener en cuenta varios aspectos: Se realizará un cálculo de únicamente el coste del proyecto sin tener en cuenta ninguna otra variable. El proyecto ha sido desarrollado por una sola persona cuyo nivel profesional podría corresponder al de un ingeniero júnior.

40 2. Planificación 15 Ha existido una colaboración exhaustiva e indispensable por parte de los tutores del proyecto que favorecieron el avance del mismo. El nivel profesional de los mismos se corresponde con el de ingenieros sénior. Se ha empleado hardware reciclado y en desuso para su realización, por lo que no se considerará coste alguno de estos servidores al estar ya completamente amortizados tras haber estado dando servicio durante años. Al realizar el proyecto en la infraestructura existente en la universidad es imposible realizar el cálculo de los costes de energía como la electricidad o la refrigueración, al igual que la conectividad a Internet, pues sólo se conocen los costes del conjunto de la infraestructura. Tras estos condicionantes iniciales, el desglose de gastos para este proyecto se compone únicamente de los recursos humanos utilizados en el proyecto. Dicho coste se ha calculado teniendo en cuenta una jornada laboral media de 20h semanales para el alumno y una duración de algo más de seis meses y medio (Ver seguimiento 2.4) Tomando como base las tablas salariales del convenio TIC , se establece un sueldo de ochocientos euros brutos mensuales a media jornada para un técnico de grado superior. Por lo tanto: Coste del alumno: Salario bruto + Seguridad Social. Coste del alumno: 800 euros durante 6.5 meses (+7 % SS) = 5564 euros brutos. Además, también es importante destacar el coste de las horas de asesoría y colaboración del tutor profesional y el tutor académico. Aproximadamente constan de tres semanales en caso del tutor profesional y una hora en el caso del tutor académico. Se toma como base el coste que supone a la universidad el trabajo de ambos tutores. En el caso del tutor profesional el coste bruto incluida la seguridad social (7 %) es de quince euros la hora, mientras que en el caso del tutor académico el coste es de algo más de doce euros. Es importante destacar que se trata del coste que supone para la organización la hora de trabajo, que como es evidente, sería superior en el caso de encontrarse en el mundo empresarial y ser realizado a través de contrataciones externas. Por lo tanto:

41 2. Planificación 16 Tutor profesional: 15 euros x 3 horas semanales x 26 semanas (6.5 meses) = 1170 euros brutos. Tutor académico: euros x 1 horas semanales x 26 semanas (6.5 meses) = euros brutos. A continuación, en la Tabla 2.1 se muestra un resumen de los costes teóricos del proyecto. Cantidad Coste 6.5 meses/20h semanales 5564 euros 6.5 meses/3h semanales 1170 euros 6.5 meses/1h semanal euros TOTAL: euros Cuadro 2.1: Costes del proyecto.

42 Capítulo 3 Contextualización Índice general 3.1. Virtualización Conceptos básicos Un poco de historia Tipos de virtualización Virtualización de plataforma Virtualización de recursos Virtualización de aplicaciones Virtualización de biblioteca (API) Virtualización de escritorios Virtualización de escritorios Conceptos básicos Ventajas e Inconvenientes Ventajas Inconvenientes Soluciones en el mercado actual VMware Horizon View Microsoft VDI Citrix XenDesktop

43 3. Contextualización Citrix VDI in a BOX Oracle VDI Ulteo QVD RedHat Enterprise Virtualization for Desktops Qué es la virtualización? Se puede definir formalmente la virtualización de infraestructuras como la abstracción o multiplexación lógica de una infraestructura física. Es decir, la creación de un sistema computacional lógicamente segmentado, que funciona en una base real. 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. El concepto de virtualización el que abre la posibilidad de construir y diseñar infraestructuras empresariales más potentes, autónomas, seguras y fiables Conceptos básicos Antes de introducirse por completo en el núcleo del trabajo, es muy importante tener claros una serie de conceptos del ámbito de la virtualización [11] que crearán una base y facilitarán al lector la total comprensión del proyecto 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

44 3. Contextualización 19 esencial de las máquinas virtuales es que los procesos que ejecutan están limitados por los recursos y abstracciones de la máquina física subyacente. En la actualidad es muy importante distinguir entre dos contextos en los que se ubica el concepto de máquina virtual. 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. Máquinas virtuales hardware o de sistema: Son aquellas que permiten a la máquina física subyacente multiplicarse en varias máquinas virtuales, es decir, abstraen el hardware de una máquina 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, que se describirá más adelante. La funcionalidad y aplicación de este tipo de máquinas virtuales es muy amplia, aunque alguna de sus características más destacadas son la posibilidad de coexistencia de varios S.O, la virtualización de servidores o la prueba y testeo de proyectos (software o hardware) en arquitecturas diferentes (permiten a un desarrollador, por ejemplo, probar el programa desarrollado en varias arquitecturas sin necesidad de instalar nativamente los operativos). En la Figura 3.1 se muestra un diagrama que representa un equipo o servidor sobre el que corren dos máquinas virtuales.

45 3. Contextualización 20 Figura 3.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 máquina al completo, si no más bien simulan un proceso sobre el sistema operativo, es decir, la máquina 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. Los ejemplos más representativos de este tipo son Java Virtual Machine o Common Language Runtime Hipervisor A grandes rasgos, se puede definir un hipervisor [9] 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). De esta forma, aunque aparentemente cada máquina virtual utiliza para sí misma los

46 3. Contextualización 21 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 [11]. Esto significa que lo primero que se instala en un servidor es el hipervisor, lo que tiene como ventaja que será el hipevisor el que se comunicará directamente con el hardware del servidor físico. Se instala en el servidor físico sin la necesidad de que exista un sistema operativo previo 1. Se agrupan como hipervisores de tipo I tecnologías como VMware vsphere, Microsoft Hyper-V o Citrix XenServer, algunas de las cuales serán descritas en sucesivos apartados. Figura 3.2: Esquema de representación de un hipervisor de tipo I 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. 1 la denominación bare-metal hace referencia a la instalación sobre el metal desnudo, es decir, instalación del software hipervisor directamente sobre el hardware como si de un sistema operativo se tratase

47 3. Contextualización 22 Figura 3.3: Esquema de representación de un hipervisor de tipo II 3.2. Un poco de historia En este apartado se profundizará sobre el concepto histórico de virtualización [11], haciendo un pequeño repaso de la tecnología, no tan reciente como se suele pensar. Viendo sus orígenes y entendiendo las causas que provocaron su evolución, se llegará al punto en el que hoy en día se encuentra: un amplio abanico de soluciones que encajan con las necesidades actuales de las organizaciones. Virtualizar ha sido considerado históricamente y de manera general como tomar algo en cierto estado y hacer parecer que se encuentra en otro estado diferente. A partir de esta idea, el concepto ha ido evolucionando hasta obtener las diferentes aproximaciones de virtualización existentes hoy en día. Tratando de encontrar los orígenes de esta tecnología, es necesario remontarse a la década de los 60, años en los cuales el concepto de virtualización se establecía a través de la creación de una máquina virtual empleando una combinación de hardware y software. Se asienta en este momento el término de máquina virtual, que vendrá dado

48 3. Contextualización 23 por la creación del sistema de paginación experimental IBM M44/44X basado en el conocido IBM 7044 (Figura 3.4). Figura 3.4: Parte frontal del IBM 7040 empleado como base para el primer sistema de virtualización Aparece poco tiempo después el sistema operativo CP-40 de también de IBM, considerado el primer sistema que usa técnicas de virtualización completa, entendiendo como tal un entorno de ejecución de máquinas virtuales que soportaba que otros operativos pudiesen ser instalados y empleados como si de una máquina física se tratase. Se puede añadir a modo de curiosidad que el sistema operativo CP-40 soportaba hasta 14 máquinas virtuales ejecutándose simultáneamente. El CP-40 pronto fue re-implementado como CP-67 para el nuevo sistema de IBM, el IBM System/ (Figura 3.5), una máquina fabricada en 1966 que incluía una tabla hardware con traducción de páginas para la memoria virtual además de otra serie de características que permitía la virtualización de todas las tareas y procesos del kernel, como la E/S o las interrupciones.

49 3. Contextualización 24 Figura 3.5: Computador IBM System/ de la Universidad de Michigan en 1969 Tras los sistemas operativos anteriormente descritos aparece el sistema CP/CMS como parte de un intento de IBM de construir sistemas robustos de tiempo compartido para sus sistemas mainframe. Al correr varios sistemas operativos al mismo tiempo, el hipervisor [ ] incrementaba la fiabilidad y estabilidad y incluso en el caso de fallo de un sistema operativo, por lo que los demás podrían continuar su ejecución sin interrupción de ningún tipo. Será en 1972 cuando Robert Goldberg asienta la base teórica de una arquitectura orientada a sistemas virtuales y en ese mismo año IBM introduce en el mercado el sistema operativo VM/370 (siendo una re-implementación del CP/CMS), empleado en el sistema mainframe IBM System 370/Advanced Function (En la Figura 3.6 se puede apreciar una imagen del sistema), diseñado, al igual que el CP/CMS, para ejecutar varios sistemas operativos al mismo tiempo, bajo la supervisión de un programa (hipervisor). Esta idea fue la predominante en el mercado durante años apareciendo diferentes mainframes que mejoraron a este modelo de referencia. Son estos últimos modelos y operativos los que gozaron de una pronta aceptación y desarrollo por parte de la comunidad empresarial, militar y universitaria.

50 3. Contextualización 25 Figura 3.6: Parte frontal del mainframe IBM 370/Advanced Function Poco tiempo más tarde se producirían una serie de enfrentamientos entre la virtualización y el procesamiento por lotes, provocadas por las necesidades de la época, saliendo completamente fortalecido este último. Esto trajo consigo una marcha atrás de las máquinas virtuales de igual manera que le ocurrió a los sistemas operativos durante años y no será hasta mediados de la década de los 90 hasta que empresas como VMware Inc. empiezan a interesarse de nuevo por la tecnología comenzando investigaciones y desarrollos en este campo. Es a finales de los 90 cuando aparece su primera versión comercial bajo el nombre de VMware Virtual Platform, basada en las investigaciones anteriores. Posteriormente en los primeros 2000, concretamente en 2003 aparece la primera versión de Xen (Open Source) y surge el interés de los principales dominantes del mercado de procesadores por la virtualización, comenzando la fabricación de sus primeros procesadores con soporte para virtualización en el 2005 (tecnologías Intel VT y AMD- V). En el presente, la virtualización ha llegado al escritorio, lo que ha echo que incremente exponencialmente su popularidad y esto provoque que sea una de las tecnologías más innovadoras del momento debido a las notables ventajas que supone su aplicación. Uno de los hechos que justifican esto es que prácticamente todas las grandes empresas dentro del mundo informático han desarrollado productos y soluciones de virtualización o han adquirido empresas que lo ofrecían.

51 3. Contextualización 26 Hoy en día, la virtualización es uno de los puntos calientes del sector informático a nivel mundial. Cada vez más las empresas virtualizan a prácticamente todos los niveles sus servicios y lo más sorprendente de todo es que se trata de una tecnología de hace casi medio siglo, no explotada hasta ahora en ninguno de sus ámbitos más consolidados en la actualidad: la virtualización de servidores y la virtualización de escritorios 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 paravirtualización y es por ello que se mostrará 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. 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) y es así como surgen los diferentes modelos de virtualización [11]. 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. 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) 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. 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

52 3. Contextualización 27 ve a las otras máquinas virtuales como máquinas 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. 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. [11] Emulación: Un emulador es la réplica una arquitectura hardware al completo que permite que se ejecute sobre él máquinas virtuales, es decir, es tratar de conseguir la apariencia de hardware real para el sistema operativo virtual o invitado. Emuladores conocidos actualmente pueden ser Boch, MAME o Qemu (En la mayoría de las ocasiones, las soluciones de virtualización hacen uso interno de emuladores). [11] Paravirtualización: La paravirtualización es una técnica de virtualización que 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 vídeo, discos duros, y RAM; para que los sistemas operativos virtualizados funcionen de manera transparente. Es decir, consiste en ejecutar sistemas operativos guests o invitados sobre otro sistema operativo que actúa como hipervisor (host). Los guests tienen que comunicarse con el hipervisor para lograr la virtualización. Las soluciones más conocidas dentro de la paravirtualización son Xen, Logical Domains, Oracle VM y Sun xvm Server. Las ventajas de este enfoque son un muy buen rendimiento y la posibilidad de ejecutar múltiples y distintos sistemas operativos. Su desventaja es que los sistemas operativos invitados deben ser modificados expresamente para esta arquitectura, al igual que las librerías y utilidades ejecutadas por las máquinas virtuales, que deben estar compiladas y preparadas para el hardware de la máquina física. [11] Virtualización completa: La virtualización completa es similar a la paravirtualización en la existencia de un hipervisor, pero no requiere que los sistemas

53 3. Contextualización 28 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. Dentro de esta categoría se pueden encontrar algunas de las soluciones más importantes del mercado como VMware Server, Microsoft Hyper-V, Oracle VM, etc. En la Figura 3.7 se puede ver una comparativa de esta arquitectura con respecto a la paravirtualización. [11] Figura 3.7: 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. [11] 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. [11] 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

54 3. Contextualización 29 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. 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. [11] 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. [11] 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 ). [11] 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. [11] 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). [11] 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 3Leaf Systems. [11] 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. [11]

55 3. Contextualización 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. Los ejemplos destacados y conocidos en este grupo son Microsoft App-V, Citrix XenApp o VMware Thinapp. [11] Virtualización de biblioteca (API) La virtualización a nivel de biblioteca emula porciones de un sistema operativo implementando una API específica. En este caso, el entorno virtual se limita a la emulación de una determinada API, lo que permite ejecutar binarios compilados para un operativo en otro sistema operativo diferente. Ejemplos de este grupo son WineHQ (reimplementación de la API de programación de aplicaciones Windows que permte su ejecución en entornos UNIX), o Cedega (conocido anteriormente como WineX ), que es un fork no libre de Wine diseñado para ejecutar juegos de ordenador de Windows en entornos GNU/Linux (básicamente implementa la API de DirectX). [11] 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 máquina física, almacenado en un servidor central. Será mayormente el tipo de virtualización abordado en este trabajo, por consistir en la implantación de una infraestructura de este tipo en la Univesidade da Coruña y será tratado de forma más completa en sucesivos apartados. [11]

56 3. Contextualización 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 máquinas. 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. 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 máquina 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 harían como si se tratase de un equipo convencional. La idea básica de esta arquitectura se ejemplifica en la Figura 3.8.

57 3. Contextualización 32 Figura 3.8: 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. 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 2. 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. A priori, una vez explicado, puede suceder que el término de virtualización de escritorios resulte confuso o en la práctica, equivalente a la virtualización de servidores, pues igualmente se habla de máquinas virtuales a las que usuarios o administradores pueden acceder a través de algún protocolo. 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 2 Un data center o centro de procesamiento de datos (CPD) es una ubicación donde se concentran los recursos necesarios para el procesamiento de información de una organización.

58 3. Contextualización 33 máquianas virtuales. Por otra parte, la virtualización de escritorios o 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 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 aparecerán frecuentemente en el resto de las secciones, al igual que los ya mencionados en la sección de conceptos básicos de virtualización [3.1.1] 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ía 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 realizarán 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. 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

59 3. Contextualización 34 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. En la Figura 3.9 se puede apreciar la solución de la empresa Dell, la adoptada en la Universidade da Coruña para la infraestructura actual de escritorios Windows. Figura 3.9: Equipo thin client Dell Wyse, usados en la infraestructura actual de la UDC para la conexión con escritorios Windows 3.5. Ventajas e Inconvenientes Una vez realizado un recorrido completo por los conceptos básicos de la virtualización, su historia y sus diferentes tipos se pasa ya a centrar toda la atención en la materia que trata este trabajo: la virtualización de escritorios. Es por ello que en este apartado se buscará y revisará el porqué hoy en día la tecnología VDI ha cobrado tanta importancia dentro del sector empresarial hasta llegar a ser uno de los sectores punteros en cuanto a su uso y proyección. Para ello, es fundamental estudiar y analizar todas las razones y causas que han motivado este auge así como también los posibles problemas o desventajas que este tipo de infraestructuras pueden tener. Si bien es cierto, que aunque muchas de ellas serán aplicables a todos los ámbitos, es muy importante antes de la realización de cualquier proyecto barajar todas las ventajas y desventajas en particular, pues muchas veces lo que para un ámbito u organización puede ser favorable para otros puede ser un gran

60 3. Contextualización 35 problema Ventajas Como es lógico, serán mayoría, pues en caso contrario su implantación estaría carente de sentido. A continuación se enumeran algunas de sus características más importantes muchas de ellas comunes a cualquier otro tipo de infraestructura de virtualización y no exclusivamente propias de VDI Aprovechamiento de hardware Es muy habitual que muchos de los servidores ubicados en Data Centers de organizaciones estén utilizando una pequeña parte de su potencia total de computación (entre un 15 % y 20 % en muchos casos), lo que conduce a un desperdicio considerable del hardware disponible. Es aquí donde surge el rol de la virtualización, permitiendo que un sólo equipo servidor almacene a su vez diversos sistemas. Por lo tanto, el uso de virtualización en las organizaciones pueden elevar las tasas de utilización del hardware y hacer un uso más eficiente de los mismos, lo que se traducirá, a largo plazo en un aumento de la productividad y del capital empresarial. Esta característica se ve fortalecida por el gran incremento del potencia de cálculo de las máquinas actuales, las cuales son capaces de mover una gran cantidad de servicios virtualizados gracias al continuo crecimiento de la industria del chip, sobre todo en lo referente con las extensiones de virtualización VT-Intel y AMD-V. En resumen, se puede decir que trata de reducir el número de servidores hardware al mismo tiempo que aumenta el porcentaje de su utilización. Esta estrategia es conocida como consolidación de servidores. [11] Eficiencia energética Se trata de una ventaja derivada en gran parte de la anterior, pues realmente, una lleva a la otra. Hasta hace años, los recursos y costes energéticos eran totalmente asu-

61 3. Contextualización 36 mibles sin dificultad por cualquier organización, pero desde hace un tiempo, todas las empresas comenzaron a considerar la escasez y encarecimiento de la energía, surgiendo de este modo la necesidad de buscar alternativas para aumentar la eficiencia energética de sus infraestructuras. Es decir, tratar en la medida de lo posible de reducir la dependencia energética. Es en este punto donde la virtualización de escritorios entra en juego, ya que un estudio de 2008 realizado por The Climate Group 3 indica que la implantación de escritorios remotos y la virtualización de servidores en una organización puede disminuir el consumo energético hasta una tercera parte. Esto es debido, en gran medida a los altos costes de climatización, que se verán reducidos de forma muy significativa, pues el reducir el número de equipos hardware, reduce la potencia necesaria para el enfriamiento. [11] Ahorro de espacio Como consecuencia del imponente crecimiento de las tecnologías de la información, todas las empresas y organizaciones han sufrido un crecimiento masivo de sus infraestructuras, llegando a situaciones de agotamiento del espacio disponible para sus centros de datos. Ante esta situación, y con la posibilidad de aglutinar varios servicios dentro del mismo hardware, se evitan los costes de la ampliación de espacio del centro de datos. [11] Administración de sistemas simplificada Todo el mundo sabe que las tareas de administración de sistemas pueden llegar a ser intensas y laboriosas, además de que en una gran mayoría de los casos los administradores de sistemas deben estar ubicados junto a los servidores de los centros de datos, ya que en ocasiones es probable que se necesite acceso físico al hardware para realizar ciertas operaciones tanto de substitución de componentes, como de monitorización. El uso de la virtualización de escritorios ofrece una administración sencilla y cen- 3 Es una organización sin ánimo de lucro que trabaja internacionalmente con empresas y gobiernos para tratar de promover las energías limpias, así como también políticas de ahorro energético y emisiones contaminantes.

62 3. Contextualización 37 tralizada de todas sus actividades (lo que reducirá los costes de mantenimiento), como puede ser la provisión de máquinas virtuales de forma automática (gracias a técnicas de clonación de máquinas o las virtual appliances 4 ), el proceso de copia de seguridad o la restauración de las mismas. Desaparecen también muchas de las labores de administración que antes eran físicas, ya que los sistemas administrados pasan a ser instancias de máquinas virtuales. Es importante remarcar aquí (dada la importancia de este punto) que por norma general, el número de máquinas (virtuales o no) de las que es responsable un administrador en una organización siempre será el mismo, por lo que es fundamental de cara a su trabajo, mantener la infraestructura lo más independiente posible de los sistemas físicos, algo que se consigue con la virtualización de escritorios. [11] Alta disponibilidad y recuperación ante desastres Trata de reducir en la medida de lo posible los tiempos de parada de los servicios y los datos críticos de una organización, algo que se ve facilitado por la implantación de escritorios VDI al incluir mecanismos como la migración de máquinas. Si un sistema físico falla, los sistemas virtuales contenidos en él pueden ser migrados o redistribuidos en caliente o dinámicamente a otros sistemas. [11] Alto rendimiento y redundancia Se trata de una característica compatible con la anterior por la facilidad de mantener sistemas virtuales redundados en diferentes sistemas físicos, además de aumentar el rendimiento (P.ej: procesamiento en paralelo o balanceo de carga). Todo ello facilita la recuperación ante desastres. [11] Seguridad La virtualización de escritorios hace que todos los datos de los usuarios de los escritorios, y por lo tanto de las organizaciones, se almacenen de forma centralizada en los servidores y absolutamente nada a nivel local. De este modo, el único punto de fallo 4 Instancias de máquinas virtuales ya preconfiguradas

63 3. Contextualización 38 pasa a ser el servidor, mientras que en una arquitectura convencional se puede producir la pérdida o robo de datos o fallos de seguridad en cualquier ordenador. Otro de los ámbitos donde se ve mejorada la seguridad, es en las aplicaciones y los operativos, pues al ser aislados independientemente (cada máquina virtual es independiente entre sí), el acceso o ataque a un aplicativo afectará sólo y exclusivamente a él mismo. [11] Reducción de costes La aplicación de la técnicas de virtualización de escritorios supone un ahorro de costes en prácticamente todos los campos. Esto permite a organizaciones y empresas destinar los esfuerzos y recursos en otras tareas como innovación o desarrollo. Como ya se comentó anteriormente, también permite ahorrar costes en la adquisición de nuevo hardware (consolidación de servidores), reducir los costes en infraestructura de refrigeración (al necesitar menos hardware, menores serán los costes de enfriamiento) o el precio de cada puesto de trabajo (mediante el uso de thin clients[3.9]) Escalabilidad Una infraestructura virtual proporciona características de escalabilidad muy superiores a una física tradicional. Al tratarse de máquinas virtuales lógicas, un servidor puede gestionar un gran número de máquinas. De esa forma, si se necesita cualquier servicio o ante necesidades crecientes de la organización, únicamente se debe crear la máquina virtual correspondiente. En cambio, si la estructura fuese convencional, sería necesario adquirir un nuevo servidor o integrar el servicio en uno existente (En el mejor de los casos). [11] Compatibilidad hacia atrás Otra de las características indispensables de estas infraestructuras, es la posibilidad que ofrecen para el uso y mantenimiento de sistemas y aplicaciones heredados que no fueron adaptados a versiones actuales, y por lo tanto sin compatibilidad en sistemas de hoy en día. En una infraestructura VDI requiere únicamente crear una máquina virtual

64 3. Contextualización 39 con el sistema necesario, lo que la hace una solución ideal y simple para casos en los cuales es necesario continuar empleando software antiguo o heredado Clústers virtuales Posibilidad de creación de clústeres de servidores virtuales para unificar múltiples servidores en un único sistema. Presenta por tanto en este caso, todas las características propias de un clúster físico, a las cuales se añaden muchas de las citadas para infraestructuras VDI. El ejemplo más claro, sería la creación de un clúster totalmente personalizable, con opción de añadir recursos hardware en función de la demanda de los servicios ofrecidos por el mismo. [11] Personalización y flexibilidad Prácticamente cualquier elemento de una infraestructura VDI es personalizable y configurable, desde el hardware empleado por las máquinas virtuales hasta cualquier opción y configuración (sobre todo en muchas soluciones como Xen o QVD que son Open Source) Inconvenientes Antes de aplicar o implantar una infraestructura de escritorios virtuales es completamente indispensable tener claro las posibles desventajas que puedan surgir una vez realizada su puesta en marcha, ya que en determinadas organizaciones, algunas de ellas pueden provocar el derrumbe de un proyecto de virtualización Disminución del rendimiento Aunque todas las empresas que ofrecen soluciones VDI trabajan diariamente en tratar de aumentar el rendimiento, como es normal, la ejecución de una máquina virtual no ofrece (y es posiblemente nunca ofrecerá) un rendimiento igual o superior a la ejecución totalmente equivalente sobre la máquina física.

65 3. Contextualización 40 Estas pequeñas pérdidas de rendimiento son producidas por la introducción de capas intermedias, entre la capa física y la lógica, como son los hipervisores [ ], o bien otros factores como la propia aplicación o el tipo de virtualización empleado. [11] Punto único de fallo Es uno de los inconvenientes más importantes, sobre todo en organizaciones en las cuales un fallo puede suponer grandes pérdidas (P. ej: Actividades financieras). Un problema en el servidor provocará la caída de todas las máquinas virtuales corriendo en el mismo. Es muy importante tratar de realizar una correcta planificación de los proyectos de virtualización, para que cubran correctamente posibles problemas de este tipo mediante disponibilidad y recuperación ante fallos. Algunas de las soluciones más comunes son la redundancia de hardware (replicación de la infraestructura VDI al completo), redundancia de máquinas virtuales (en servidores distintos), haciendo uso del clustering y definiendo una correcta política de administración y monitorización. [11] Dependencia de la solución elegida y el operativo anfitrión Una parte importante de los proyectos VDI, recae en el análisis y la posterior selección de la solución a implantar, que será crucial en todos los aspectos. Dicha decisión estará claramente condicionada por el servicio a ofrecer, pues cada una de ellas ofrece características diferentes para entornos distintos. Por otro lado se encuentra la elección del sistema operativo anfitrión, algo muy importante también, pues de él colgará el control de una serie de máquinas virtuales (estabilidad y seguridad). [11] Hardware y vídeo Tal y como se comentó en secciones anteriores, en la mayoría de los casos no es posible utilizar hardware que no esté soportado por el hipervisor [ ], y es el propio software de virtualización el que establece la tecnología hardware a las máquinas

66 3. Contextualización 41 virtuales, lo que puede traer problemas derivados de la incompatibilidad por parte de ciertas aplicaciones. Aademás no es posible en casi ningún caso disponer de aceleración de vídeo por hardware, lo que provoca que muchas aplicaciones que necesitan vídeo 3D no funcionen correctamente sobre las máquinas virtuales. Bien es cierto, que existen algunos casos como VMware o Parallels que soportan OpenGL 5 y DirectX 6, pero ofrecen rendimientos muy inferiores al de una máquina física. [11] Otro de los problemas dentro de la temática hardware, es el efecto colateral de la disminución de ventas de hardware provocado por la continua implantación de infraestructuras de este tipo en las organizaciones. Bien es cierto, que aunque se produzca una disminución en las ventas, el hardware comprado debe ser de una potencia superior y es por ello que las grandes empresas como Intel o AMD han apostado por la virtualización Número de máquinas virtuales La existencia de máquinas virtuales innecesarias provoca un mayor consumo y una disminución general del rendimiento de los servidores, por lo que no es aconsejable la creación de máquinas sin control y por lo tanto, el uso de los recursos y número de máquinas virtuales debe ser acorde a las condiciones (más que un inconveniente innato de las infraestructuras VDI es un problema derivado de la mala administración) Complejidad añadida y nuevos problemas Aunque en la mayoría de los casos las actividades de administración se ven mejoradas, si es cierto que pueden existir casos (sobre todo durante la implantación) en los cuales el efecto sea el contrario. Dicha complejidad se verá agravada por ejemplo, por trabajar con varias soluciones de administración al mismo tiempo, o en el caso de la administración de la red, la cual se complica bastante (cada máquina virtual dispondrá ahora de una o varias interfaces de red propias, lo cual complicará también la 5 Se trata de una serie de librerías y especificaciones estándar que definen un API multiplataforma para el desarrollo de aplicaciones con gráficos 2D y 3D. 6 Son una serie de API s creadas y desarrolladas para facilitar tareas multimedia en entornos Windows.

67 3. Contextualización 42 Ventajas Inconvenientes Aprovechamiento de hardware Pérdida de rendimiento Eficiencia energética Punto único de fallo Administración simplificada Aceleración 3D Ahorro de espacio Dependencia de la solución Compatibilidad hacia atrás Dependencia del anfitrión Alta disponibilidad Hardware soportado Recuperación ante fallos Punto único de fallos Escalabilidad Incremento complejidad Consolidación de servidores Servidor compartido Reducción de costes Alto desembolso inicial Seguridad y aislamiento - Backups - Aprovisionamiento de máquinas - Reducción servidores físicos - Clonación de máquinas - Personalización y flexibilidad - Automatización simple - Cuadro 3.1: Tabla resumen de las ventajas e inconvenientes que proporciona una infraestructura de escritorios virtuales VDI configuración del firewall y otras actividades relacionadas). Además de la complejidad añadida, surgen en este ámbito nuevos problemas ocasionados por la introducción de nuevas tecnologías y componentes. Ejemplos de esto pueden ser el conocer qué máquinas se encuentran en cada servidor físico, qué máquinas se encuentran actualmente en funcionamiento, el balanceo de carga o el manejo de las licencias de software para cada una de las aplicaciones de cada una de las máquinas virtuales Soluciones en el mercado actual La tecnología de la virtualización de escritorios es un estándar que actualmente se ofrece bajo el amparo de los distintos fabricantes de soluciones de herramientas de virtualización. En esta sección se procederá a describir de forma breve algunas de las soluciones VDI más conocidas que se pueden encontrar actualmente en el mercado.

68 3. Contextualización VMware Horizon View Se trata de la solución comercial de escritorios virtuales proporcionada por la empresa VMware, Inc. Esta solución encuentra implantada y completamente funcional en la infraestructura de la Universidad, para la virtualización de escritorios Microsoft Windows. Sus primeras dos versiones (2.0.0 y 2.1.0) eran conocidas bajo el nombre de VMware VDM posteriormente renombradas a VMware View y no siendo hasta su última versión cuando se le da el nombre de VMware Horizon View. Se trata de una infraestructura que proporciona el uso y las características de la virtualización de escritorios, pero únicamente para los operativos de Microsoft. Dentro de VMware Horizon View se encuentran a su vez, una serie de productos y componentes característicos de VMware (vsphere, vcenter, Thinapp, vshield, etc), todos ellos necesarios para posibilitar la completa implantación de la infraestructura VDI. VMware Horizon View se comercializa a través de dos posibles licencias, Enterprise o Premier, siendo esta última la más cara por incluir mayor número de características. [16] Microsoft VDI Solución de escritorios virtuales de Microsoft, basada en este caso en la tecnología de Windows Server 2012 junto con los Servicios de Escritorio Remoto (RDS) y el hipervisor Hyper-V de Microsoft. [19] Citrix XenDesktop Citrix XenDesktop es la solución VDI ofrecida por Citrix para la virtualización de escritorios, orientada únicamente a la virtualización de escritorios Windows a través también de Windows Server [18]

69 3. Contextualización Citrix VDI in a BOX Es las solución ofrecida por Citrix para la pequeña y mediana empresa. La idea original, fue desarrollada por la empresa Kaviza, pero en Mayo de 2011 es adquirida por Citrix Systems Inc, la cual se hace cargo del proyecto. Citrix VDI-in-a-Box es una solución todo en uno y arquitectura monoservidor de fácil implantación y alcance para cualquier empresa. En comparación con la anterior solución (Citrix XenDesktop), está es una solución más simple, tanto en configuración como administración, más ligera (en requisitos hardware) y más barata. Aunque VDI-in-a-Box ofrece una gran escalabilidad que permitiría ser implantada en una gran empresa, Citrix recomienda en dicho caso optar por la solución anterior, por ofrecer características más avanzadas y ser más adaptable a los diferentes entornos existentes en grandes organizaciones. [17] Oracle VDI Es el producto de virtualización de escritorios ofrecido por Oracle, nacida a partir de varios proyectos ya iniciados por la antigua Sun Microsystems. Se trata de una solución para escritorios Windows equivalente a las anteriores y compatible con los productos de virtualización más conocidos: VMware vsphere, Microsoft Hyper-V, etc. [20] Ulteo Ulteo Open Virtual Desktop nace en el 2007 como una solución de virtualización de escritorios y aplicaciones siguiendo los principios del código abierto. Se trata de una solución flexible por soportar tanto Windows como Linux, característica que la hará ideal para ser analizada de cara a una posible implantación en la Universidade da Coruña. [12]

70 3. Contextualización QVD Es otro de los productos de virtualización susceptibles de ser analizados en este trabajo. Se trata de una solución de VDI de código abierto, altamente escalable y basada completamente en Linux. Será analizada en detalle en su momento. [2] RedHat Enterprise Virtualization for Desktops Por último, otro de las soluciones que serán analizadas en detalle en este proyecto como una posible alternativa. Red Hat Enterprise Virtualization for Desktops es la solución VDI que ofrece la conocida empresa Red Hat. Destaca por ofrecer un hipervisor KVM (al igual que QVD) y emplear un procolo de comunicación con el escritorio propio, Spice 7. Como es lógico por parte de Red Hat, ofrece sólo virtualización para escritorios Linux. Será analizada en detalle en posteriores apartados. [14] 7 the Simple Protocol for Independent Computing Environments, es un sistema de comunicación de pantalla remota para sistemas de virtualización.

71 Capítulo 4 Virtualización de escritorios en la UDC Índice general 4.1. Situación de partida Usuarios y personal Situación actual Por qué VDI? Infraestructura VDI Por qué VDI Linux? La Universidade de Coruña es una institución pública que tiene como principal objetivo la generación, la gestión y la difusión de cultura y del conocimiento científico, tecnológico y profesional a través de la investigación y la docencia. Es por todo esto que el soporte de las tecnologías de la información desempeña un papel fundamental e indispensable, ya que constituye una de las áreas de especial relevancia dentro de la formación e investigación de nuestra universidad. Por ello, este capítulo será dedicado a tratar de forma breve y específica las tecnologías actuales en la UDCasí como también realizar una explicación de la situación de partida y de las necesidades actuales, dentro de las cuales se encuentra la virtualización de escritorios Linux. 46

72 4. Virtualización de escritorios en la UDC Situación de partida La Universidade da Coruña se caracteriza en gran parte por el equipamiento y la infraestructura informática de la que dispone, encontrándose en un puesto claramente aventajado en este ámbito dentro de la comunidad autónoma. Cuenta actualmente con un amplio abanico de servicios disponibles para toda la comunidad, los cuales se entregan gracias al conjunto de sistemas de sus dos Centros de Procesado de Datos, ubicados en el Edificio de Servicios Centrales de Investigación y en el edificio del Rectorado. Además, todo esto, se complementa con el resto de equipos, servidores, impresoras y demás infraestructura repartida a lo largo de las veinticuatro facultades y escuelas, cuarenta y tres departamentos y otros edificios de administración. Básicamente, la microinformática de la que dispone la universidad y a la que da servicio es la siguiente: Puestos de acceso a la información, tanto interna como de la comunidad científica y estudiantes. Puestos de prácticas y formación para estudiantes y profesores. Puestos de trabajo técnico y administrativo para el personal de administración y servicios. Puestos de trabajo, docencia e investigación, para el personal docente e investigador. Acceso a impresión desde cualquier dispositivo. Elementos móviles del personal Usuarios y personal Aunque a primera vista pueda parecer que el número de usuarios a los que se da servicio en la universidad no sea tan elevado, lo cierto es que los números en su conjunto son significativos y claramente superiores incluso al de grandes empresas del sector TIC:

73 4. Virtualización de escritorios en la UDC 48 Cuenta con un estudiantado medio anual de veinticinco mil alumnos, con diferentes exigencias y necesidades. El personal docente roza las mil quinientas personas, que incluye tanto al profesorado como al personal investigador (PDI). La administración y los servicios cuentan con casi ochocientos trabajadores. Para dar soporte, cobertura y mantenimiento a todo este personal y realizar la gestión de todos los sistemas de la universidad, ésta cuenta con un reducido número de personal en comparación con el número de usuarios, lo que trae consigo que la búsqueda de soluciones eficientes y fácilmente administrables sea una de las prioridades. Básicamente, el personal técnico con el que cuenta la universidad son cincuenta y nueve personas agrupadas en ocho departamentos, de los cuales, involucrados en la administración de los sistemas y concretamente en VDI se encuentran fundamentalmente los departamentos: Centro de atención al usuario (CAU): Consta de dieciocho personas. Se encargan de inventariar todos los puestos de trabajo, ofrecer todo tipo de ayuda a los usuarios, gestionar software y realizar pruebas de aplicaciones. Red de comunicaciones y datos: Formado por seis trabajadores. Encargado de administrar, gestionar y monitorizar toda la red de comunicaciones de la universidad que interconectan todos los centros. Sistemas de Internet e Intranet: Consituido por siete técnicos. Encargado de la administración tanto de los sistemas y servicios informáticos Situación actual Hasta hace menos de un año, la situación actual de la universidad era la de cualquier organización hasta la aparición de la virtualización: Elevado número de equipos hardware anticuados y arquitectura x86.

74 4. Virtualización de escritorios en la UDC 49 Uso de equipos Microsoft Windows XP en un elevado porcentaje y Windows 7 de forma reducida. Uso de roaming profiles 1 y redirección de carpetas para la centralización de los datos del usuario en servidores de ficheros. Uso de técnicas de VPN y acceso remoto para accesos a los equipos de los usuarios desde el exterior. Sistemas de gestión centralizadas basadas en técnicas de clonación para las AulaNet con software como FOG 2 o Rembo Por qué VDI? Además de los innumerables ventajas de un entorno VDI descritas en la sección 3.5, el entorno de la UDC buscaba una serie de objetivos difícilmente alcanzables sin la puesta en marcha de una infraestructura de este tipo: dar servicio a través de los dispositivos móviles, conseguir una migración rápida de Windows XP a Windows7, y sobre todo, reducir el trabajo de operación y mantenimiento. Por otro lado, existen una serie de condicionantes básicos y característicos que marcan el por qué de la necesitad de la existencia de una infrastructura VDI en la UDC: Facilitar al estudiante y personal investigador acceder a su escritorio, sus datos y sus aplicaciones desde cualquier lugar. Reducir el tiempo de puesta en funcionamiento de nuevos equipos, aplicaciones o servicios, algo que mejora notablemente el rendimiento en un entorno docente. Mejora de la seguridad y la pérdida de datos, al centralizar el almacenamiento en un servidor central amparado por una estricta política de copia de seguridad. Homegeneizando los sistemas operativos y aplicaciones. Reutilización de hardware. Aumento de la vida útil de equipos con varios años y reducción del consumo de energía. De esta forma se favorece el ahorro de costes 1 Es un concepto de la familia de sistemas de Microsoft conocido como perfiles móviles de usuario, que consiste en proporcionar movilidad al usuario. Es decir, en almacenar los datos de los usuarios de forma centralizada y que estos se carguen tras un proceso de login en su puesto de trabajo

75 4. Virtualización de escritorios en la UDC 50 que repercutirá positivamente en la calidad de la enseñanza pública, al poder destinar los fondos hacia otros campos como la investigación. La mejora en la administración permite destinar al personal TIC a otras tareas de mejora en soporte, como puede ser la Docencia. La decisión final del uso de VMware como solución de virtualización de escritorios Windows está amparada por una gran cantidad de análisis de soluciones y proyectos pilotos llevados a cabo por el personal técnico de la universidad desde el año 2009 hasta el 2012, donde la balanza se decanta por Horizon, por su rendimiento y adaptabilidad al entorno Infraestructura VDI La infraestructura VDI para Windows de la universidad cuenta con una serie de elementos software y hardware que hacen posible dar servicio a casi mil usuarios de forma simultanea. A continuación se enumeran los equipos hardware y el software necesario para todo el servicio. Es importante hacer notar que todos los equipos se encuentran replicados en ambos CPD (Edificio de Servicios Centrales de Investigación y Rectorado) para dotar así de replicación y alta disponibilidad al sistema. En la Figura 4.1 se muestra un esquema de la distribución de los equipos dentro de los armarios rack. Infraescructura Hardware Para escritorios virtuales: 10 Servidores HP SL230s Gen8. 16 x 2.2GHz Quad-Core Intel Xeon E bit. Memoria: 128GB RAM. 37,8 TB Brutos de almacenamiento SAN. 22 TB Netos Network RAID 10. Conectividad 10GbE.

76 4. Virtualización de escritorios en la UDC 51 Figura 4.1: Distribución de las máquinas en los armarios rack Para administración: 2 Servidores HP DL360 Gen8. 12 x 2.3GHz Intel Xeon E GB de memoria. Infraescructura Software VMware Horizon View 5.2 VMware Thinapp VMware Horizon Workspace 5.2 vsphere 5.1 vcenter Server Por qué VDI Linux? Aunque el orden de prioridades establecen que la infraestructura Windows debía ser la primera, son muchos los factores y condicionantes que hacen que sea necesaria la presencia de una infraestructura de virtualización de escritorios Linux en la Universidade da Coruña.

77 4. Virtualización de escritorios en la UDC 52 Necesidades técnicas del alumnado: Existen ciertos grupos de alumnos de enseñanzas técnicas que requieren el uso de distribuciones Linux para la elaboración de sus prácticas. El ejemplo más claro es el alumnado de la Facultad de Informática. Necesidades del personal investigador: Departamentos o grupos de investigación que hacen uso de herramientas y características propias de los sistemas Linux. Necesidad de entornos aislados: Creación de entornos aislados entre sí que permitan un rápido despligue y una fácil configuración y gestión de las máquinas virtuales. Un ejemplo claro son ciertas asignaturas de la Facultad de Informática, en la que es necesario disponer de una máquina virtual por alumno, que permita la total manipulación de la misma sin problemas de corrupción de datos o fallos de seguridad. Flexibilidad: Sirve como perfecto complemento a la infraestructura Windows, de tal forma que permita al usuario flexibilizar la decisión de emplear un sistema operativo u otro. Posibilidad de arranque dual de escritorio virtual Linux o Windows. Fomento, promoción y difusión del software libre y los estándares abiertos: Como disciplina fundamental de la UDC, el uso del software libre se ve profundamente reflejado al disponer e una infraestructura de este tipo.

78 Capítulo 5 Alternativas Índice general 5.1. Ulteo Descripción Características Comparativa de versiones Requisitos técnicos Soporte QVD Descripción Características Comparativa de versiones Requisitos técnicos Soporte Red Hat Enterprise Virtualization: Spice Descripción Características Requisitos técnicos Soporte Comparativa de productos

79 5. Posibles alternativas Comparativa de las versiones de pago Comparativa de las versiones gratuitas Solución a implantar Son muchas las soluciones existentes en el mercado para llevar a cabo la implantación de un sistema de virtualización de escritorios Linux. Es en este momento donde se presenta la difícil tarea de seleccionar y decidir cuál será la adecuada de cara a la Universidade da Coruña. Actualmente, ya existe una infraestructura de virtualización para escritorios Windows montada sobre Vmware. Es por esto, que será necesario tratar de acercarse lo máximo posible a esta solución, debido a su fácil adaptación al entorno, facilidad de mantenimiento y el ya conocimiento por parte de los administradores. Tras un estudio previo de las posibles alternativas realizado por el Servicio de Informática de la Universidad, se pueden considerar tres de cara a la implantación VDI: Ulteo, QVD o Red Hat. En sucesivos apartados se realizará un análisis de cada una de ellas y una exhaustiva comparativa de las mismas para finalmente decidirse por la más adecuada Ulteo Descripción Ulteo Open Virtual Desktop (OVD) es un proyecto que nace en el año 2007 bajo la entidad comercial de Ulteo SAS. Se trata de una aplicación o plataforma de virtualización de escritorios basada en GNU/Linux que nace con el objetivo de proporcionar un sistema no propietario, de código abierto, seguro y escalable para la implatación de escritorios virtuales. OVD está preparada para soportar tanto la virtualización de escritorios Windows como escritorios Linux o aplicaciones SaaS 1. Básicamente, permite a las organizaciones o empresas integrar y proporcionar escritorios virtuales con un acceso seguro por parte 1 Software as a service, es un modelo de distribución de software donde el soporte lógico y los datos que maneja se alojan en servidores de una compañía TIC (Tecnologías de la información y comunicación. Dichos servicios son accedidos desde un navegador web de un cliente.

80 5. Posibles alternativas 55 de los clientes. [13] Características Se exponen a continuación las características fundamentales del proyecto OVD de Ulteo, realizando una clasificación temática en función del rango de aplicación de la característica. [12] Características de la plataforma Escalable: Ofrece una correcta manipulación y control de la carga dando un posible soporte de hasta usuarios (Evidentemente, en muchos casos la limitación de usuarios vendrá impuesta por la infraestructura). Hi-Def: Buena definición de pantalla para ofrecer una correcta visualización del escritorio para acercarse lo máximo posible a una experiencia de usuario similar a la de un escritorio nativo. Seguridad: Permite el acceso a los escritorios remotos tanto desde LAN s 2 como WAN s 3 y es completamente compatible con SSL o VPN s 4. Servidores de ficheros: Ofrece un entorno de persistencia para almacenar los datos personales y de configuración (P.ej: El perfil de un usuario Linux). Compatibilidad con Vmware: Es una característica que lo hace ideal para organizaciones que disponen ya de infraestructuras Vmware. Permite complementarla, añadiendo a esta una el soporte para escritorios Linux. Además Ulteo incorpora herramientas o métodos que facilitan dicha integración. Características entregables 2 Local Area Network o red de área local es una red que se emplea para interconectar equipos de una misma compañía u organización. 3 Una Wide Area Network es una red que abarca varias ubicaciones físicas, proveyendo servicio a una zona, un país o incluso a varios continentes. Se trata básicamente de una red encargada de unir varias redes de área local. 4 Una VPN o Virtual Private Network es una tecnología de red que permite una extensión segura de una red local sobre una red pública insegura o no controlada. Permite enviar información por una red pública con todas las funcionalidades de una red privada

81 5. Posibles alternativas 56 Compatibilidad: La infraestructura Ulteo destaca por su compatibilidad con la virtualización de escritorios Linux y Windows, permitiendo así a las organizaciones seleccionar el sistema operativo que más se adapte a sus necesidades. Es por tanto también compatible con cualquier aplicación destinada a operar en cualquiera de estos dos sistemas. Modo Portal : Permite iniciar aplicaciones desde el Navegador o nativamente desde el host anfitrión dentro de la intranet de la organización, es decir, presenta la oportunidad de ejecutar aplicaciones directamente sin necesidad de acceder al escritorio virtual. Integración: Integración del escritorio dinámica de tal forma que la experiencia de usuario sea similar a ejecutar la aplicación o el escritorio localmente. Modo Kiosk : Es un modo que permite restringir a los usuarios las aplicaciones que estos pueden ejecutar. Otras características: Soporte de sonido, control de impresoras locales y compartición de portapapeles entre el escritorio virtual y el escritorio virtual ( Copy & Paste ). Carecterísticas de mantenimiento Gestión centralizada: Proporciona una consola web que permite la configuración, el mantenimiento, la gestión y monitorización centralizada de servidores, usuarios y aplicaciones. Asistente: Incorpora una completa guía para facilitar las labores de configuración y mantenimiento. Integración de la consola: Proporciona una consola que puede ser integrada en otros frameworks de administración. Integración de dominios: Permite establecer control de acceso a través de dominios ya existentes, es decir, permite facilitar la autenticación a los escritorios virtuales a través de sistemas como el Microsoft Active Directory, LDAP o Novell edirectory [Apéndice B. Sistema de alertas por Presenta un sistema de monitorización que permite el envío de correos electrónicos a los administradores para informar del estado del sistema.

82 5. Posibles alternativas 57 Balanceo de carga: Proporciona la posibilidad de balancear automáticamente la carga de los servidores en función de los escritorios virtuales en activo Comparativa de versiones Ulteo presenta dos posibles soluciones o versiones: Ulteo OVD Community Edition o Ulteo OVD Premium Edition, enfocadas hacia entornos diferentes. [12] Ulteo OVD Community Edition: Se trata de la versión base de la plataforma Ulteo. Es la opción gratuíta y proporciona las funcionalidades pertenecientes al núcleo de la aplicación, es decir, las funcionalidades más básicas. Sería la versión adecuada para uso particular o de pequeña empresa. Ulteo OVD Premium Edition: Es la versión adecuada para importantes infraestructuras de virtualización de empresas medianas o grandes. Ofrece mejores capacidades que la anterior. Es necesario un contrato de suscripción de Ulteo (SA). En la Tabla 5.1 se ofrece una comparativa de versiones. Dicha tabla está compuesta por una serie de características, una descripción de las mismas y la indicación de en qué versiones está disponible dicha característica Requisitos técnicos Los requisitos técnicos de la infraestructura Ulteo, se dividen por componentes. Se muestran a continuación, por tanto, los requisitos mínimos para cada uno de los componentes necesarios en la implantación de una infraestructura Ulteo [12] Servidores de aplicación OVD: CPU dual o quad-core. RAM 1GB o más para 15 usuarios concurrentes. Sistemas operativos mínimos soportados: Ubuntu 10.04, RHEL 5.2 o 5.3, CentOS 5.2+, Fedora 10, OpenSuSE 11.2, o superiores. 5 Se trata de un mecanismo de autenticación basado en tokens, que pueden ser generados por herramientas hardware o software. Dicho token se emplea para generar posteriormente un código de autenticación.

83 5. Posibles alternativas 58 Característica Descripción Community Premium Hosting de aplicaciones Las aplicaciones están instaladas en un data center y están disponibles remotamente a los usuarios a través del escritorio virtual. Uso de las mismas de forma análoga a las aplicaciones de escritorios nativos. S.O Compatibles Compatibilidad con sistemas operativos Windows y Linux. Integración de las aplicaciones Integración de las aplicaciones virtualizadas en el escritorio local, es decir, ejecución de aplicaciones remotas desde el escritorio local como si se tratase de una aplicación instalada de forma nativa. Modo portal Modo que proporciona un gestor de archivos y la posible ejecución de aplicaciones desde un navegador web. Modo kiosk Modo que permite restringir a ciertos usuarios ciertas aplicaciones, es decir, permite seleccionar las aplicaciones que un usuario puede ejecutar. Cliente web Conexión al escritorio remoto a través de un navegador web compatible con Java. Acceso al escritorio virtual a Cliente nativo Windows través de un software nativo desde S.O Windows. Acceso al escritorio virtual a Cliente nativo Linux través de un software nativo desde S.O Linux. Acceso al escritorio virtual a Cliente ios través de un cliente para iphone e ipad. Acceso al escritorio virtual a Cliente Android través de un cliente para dispositivos Android. Balanceo de carga Cuando existe más de un servidor de escritorios virtuales Ulteo proporciona un balanceo de carga entre ellos para alcanzar el máximo rendimiento. Recuperación de sesiones Mecanismo de reconexión o recuperación de una sesión establecida en caso de interrupción del servicio. Monitorización y reporte Sistema de monitorización, logging y reporte de incidencias.

84 5. Posibles alternativas 59 Característica Descripción Community Premium Sistema de envío de correos Alertas por correo electrónicos a los administradores en caso de incidencias. 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. 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. SSL VPN Acceso al los escritorios virtuales haciendo uso de VPN mediante el protocolo SSL. Soporte para autenticación a RSA SecureID través de RSA SecureID ((Two factor authentication support) 5. Cuadro 5.1: Comparativa de versiones de Ulteo

85 5. Posibles alternativas 60 Servidores administradores de sesión OVD: Cualquier CPU Pentium x86 con 1GB o más RAM. Soporta los mismos sistemas operativos que el anterior. Servicios de directorio: LDAP, e-directory, ZENwork y Active Directory. Servidores de ficheros: CIFS o cualquier servidor WebDAV embebido Soporte El soporte de Ulteo es uno de sus puntos fuertes, destacando fundamentalmente por ofrecer un soporte de nivel tres en sus versiones de suscripción [12]. Un soporte de nivel tres es el nivel de mayor capacidad para resolver problemas. Es conocido también como soporte de alto nivel. Un soporte de este nivel estipula que cualquier problema será atendido por profesionales expertos en el campo, así como también personal de investigación y desarrollo para crear soluciones a problemas nuevos y desconocidos. Es de suponer también que se trata de un soporte a disponibilidad completa, es decir, que en caso de incidencia habrá un servicio técnico disponible las veinticuatro horas del día, los siete días de la semana y durante todo el año (24x7x365 ). Básicamente, se puede considerar el soporte ofrecido por Ulteo un soporte completo para cualquiera de sus versiones de suscripción.

86 5. Posibles alternativas QVD Descripción QVD es un proyecto open-source (código abierto) del grupo Quindel Group y que proporciona una infraestructura para la implantación de escritorios virtuales Linux en una organización. Se trata de una alternativa a un precio asequible, altamente escalable, fácil de gestionar y que permite tanto la virtualización de escritorios como la disponer de aplicaciones en la nube (Saas). Es una solución flexible que permite soluciones escalables y de bajo costo para una gran cantidad de usuarios. La filosofía de la empresa QVD es presentar independencia tecnológica y ahorro. Es por ello que se centra principalmente en ofrecer escritorios Linux a los usuarios, con el objetivo de reducir los costes de licencias y fomentar la adopción de la tecnología de código abierto [1] Características QVD presenta una serie de características básicas completamente equivalentes a las de cualquier otro software de virtualización disponible en el mercado. [2] Alta densidad: Ofrece la posibilidad de ejecutar múltiples máquinas virtuales a partir de una o más imágenes en un solo nodo de la red. Permite por tanto, reutilizar una imagen de sistema base para varias máquinas virtuales. Al ejecutar varias imágenes por nodo permite dar servicio a un elevado número de usuarios. Balanceo de carga: Dispone de un sistema de balanceo de carga automático que lo hace adecuado para ser implantado en clústers de un servidor. Dispone de una serie de servicios para asegurarse de que el cliente que se conecte a cualquier nodo del servidor se redirige al nodo correcto. Alta disponibilidad: Presenta la posibilidad de determinar automáticamente que nodo servidor del clúster tiene la mayor parte de recursos disponibles, lo que ayuda a asegurar una alta disponibilidad de los entornos de escritorio.

87 5. Posibles alternativas 62 Autoprovisión: En QVD cada usuario es identificado de forma independiente a través de un nombre y una contraseña, de tal forma que se puede asignar una imagen de escritorio por usuario. QVD permite establecer su propio nombre de usuario y contraseña o integrar dicho sistema con sistemas de autenticación externos como LDAP o Active Directory. Clientes: QVD presenta clientes software para Linux y Windows, al igual que un cliente Android que actualmente se encuentra en desarollo. Simplemente ejecutando alguno de estos clientes, el usuario puede tener acceso a su propio escritorio virtual. Administración web: Proporciona herramientas de línea de comandos, lo que permite ejecución de scripts o trabajar a través de SSH 6. Además, QVD tiene un completo entorno de administración web, lo que facilita la tarea del administrador. Seguridad: Alto nivel de seguridad. Proporciona un entorno aislado a nivel de máquina, de tal forma que cualquier compromiso a nivel de máquina virtual sólo afectará al escritorio en ejecución. El mal comportamiento de una máquina no afecta a las máquinas de los demás usuarios. Por otra parte, la conexión con los escritorios virtuales se realizará a través de SSL/TLS de tal forma que todas las comunicaciones entre un cliente y el servidor están securizadas. Acceso remoto: QVD hace uso de una versión modificada de NX 7, lo que permite reducir la carga de ancho de banda. Ofrece distintos algoritmos de compresión en función de la configuración del usuario (usuarios con alto o bajo ancho de banda). Cliente ligero QVD: La solución QVD proporciona un cliente ligero que permite que los usuarios experimenten una relación más transparente con los escritorios virtuales. Es decir, el cliente ligero software de QVD, hace las funciones de sistema operativo anfitrión, de tal forma que le presenta únicamente al usuario una ventana de login tan pronto como inicia el ordenador. 6 SSH o Secure Shell es un protocolo para acceder remotamente a una máquina a través de la red. Permite manejar remotamente una máquina a través del intérprete de comandos. 7 Software que realiza conexiones remotas X11 muy rápidas, lo que permite a los usuarios acceder a escritorios remotos Linux o Unix bajo conexiones lentas. Es un protocolo que proporciona una alta eficiencia en la conexión gracias a una correcta compresión.

88 5. Posibles alternativas 63 Soporte de migración: Muchas empresas frecuentemente disponen ya de una serie de sistemas o infraestructuras de escritorios y bases de datos de usuarios. QVD proporciona asistentes de migración de infraestructuras anteriores a la nueva infraestructura. Imagenes preconfiguradas: QVD ofrece ayuda para la construcción de imágenes de sistemas operativos. Ofrecen la posibilidad de enviar una serie de requerimientos, a partir de los cuales generan una imagen de un sistema operativo adaptada a las necesidades de cada organización. Integración de dominios: Permite establecer control de acceso a través de dominios ya existentes, es decir, permite facilitar la autenticación a los escritorios virtuales a través de sistemas como el Microsoft Active Directory o LDAP Comparativa de versiones La solución o infraestructura de escritorios virtuales QVD ofrece tres versiones distintas, enfocadas cada una de ellas hacía un público diferente. [2] QVD Community Edition: Versión gratuita destinada fundamentalmente para desarrolladores, testers o para uso particular sencillo. Está fundamentalmente orientada hacia instalaciones de un único servidor de pruebas y poco crítico. QVD Online Suscription: Es la versión intermedia con el objetivo principal de ser asentada en pequeñas y medianas empresas que poseen administradores de sistemas propios. QVD Enterprise Edition: Versión más completa y como es lógico, más cara. Está destinada a organizaciones relativamente grandes o con infraestructuras críticas que requieren unas necesidades altamente funcionales y con un soporte completo. Al igual que para Ulteo, se realizó una comparativa de versiones en la de aquellas características más importantes de QVD. Dicha comparativa se expone en la Tabla En fase beta. 9 En fase beta.

89 5. Posibles alternativas 64 Característica Descripción Community Online Suscription Enterprise QVD Core Consiste en el núcleo de funcionalidades de QVD, es decir, aquellas funcionalidades más básicas (Se incluyen aquí las características de Alta disponibilidad, balan- ceo de carga, autoprovisión, etc, vistas en la Sección 5.2.2). Acceso al escritorio virtual a Cliente Windows través de un software nativo desde S.O Windows. Acceso al escritorio virtual a Cliente Linux través de un software nativo desde S.O Linux. Acceso al escritorio virtual a Cliente OS X través de un software nativo desde 8 S.O MAC OS X. Cliente Android Posiblidad de conectarse al escritorio virtual con un dispositivo 9 Android Cliente ios Posiblidad de conectarse al escritorio virtual con un dispositivo ios (iphone & ipad). Herramienta de administración web Incluye una herramienta de gestión, monitorización y control a través de una sencilla interfaz web. Soporte prioritario Existencia de algún plan de soporte (Se comentarán en la Sección 5.2.5). Soporte por y online Solución de problemas en linea y personalizado a través de correo electrónico Actualizaciones prioritarias Correción de bugs y acceso a los repositorios internos de QVD con actualizaciones. Imágenes personalizadas Opción de que QVD proporcione imágenes de S.O personalizadas bajo unos requisitos. Software de cliente ligero Mini S.O que ejerce las funciones de Thin Client. Certificación de las instalaciones QVD ofrece la posibilidad de certificar las instalaciones software y hardware bien por ellos mismos o por un partner autorizado. Cuadro 5.2: Comparativa de versiones de QVD

90 5. Posibles alternativas Requisitos técnicos Las especificaciones técnicas o requisitos mínimos de un sistema QVD es una de sus ventajas, pues al tratarse en su base de un sistema operativo Linux, bajo condiciones teóricas, los requisitos mínimos de los equipos servidores podrían ser los mismos que para una instalación de un operativo Linux en un ordenador convencional. Aunque no existen unos requisitos mínimos de instalación, es evidente de que serán necesarios mejores equipos en la infraestructura cuanto mayor sea el servicio que se desea ofrecer a los usuarios (Por ejemplo, un usuario medio que emplee su escritorio virtual para navegación e ofimática puede emplear alrededor de 200 o 300 megabytes de memoria RAM y otros 200 megabytes de espacio en disco). Esto quiere decir, que los requisitos mínimos de instalación vendrán dados por el propio diseño y el futuro uso de la infraestructura. [2] Soporte QVD ofrece un soporte prioritario para los clientes suscritos a alguna de sus versiones de pago. Aunque acepta envíos de error y peticiones de mejora por parte de los usuarios de las versiones gratuitas, la solución QVD ofrece a sus usuarios suscritos una gran preferencia en el caso de errores, de tal forma que los desarrolladores e ingenieros se ocupan directamente de cualquier problema. QVD ofrece dos sistemas de soporte distintos en en función del plan contratado. Uno de ellos es el sistema Siguiente-Día-Laborable (8x5), es decir, ofrecido en la versión de Online Suscription que proporciona una respuesta rápida pero dentro de los cinco días laborables de una semana. El otro de los sistemas de soporte es el 24x7x365 (ofrecido en la versión Enterprise Edition ), en el cual se ofrece solución a incidencias a cualquier hora del día durante los siete días de la semana. En lo referente al soporte, dispone también de una amplia base de datos de problemas y soluciones, que incluye una gran cantidad de problemas frecuentes, con sus respectivas guías de solución y gran variedad de scripts. Además, ofrece la posibilidad de configuración de soporte remoto, opción ideal para organizaciones en las que el equipo informático sea reducido. El personal de soporte de

91 5. Posibles alternativas 66 QVD puede colaborar remotamente en las labores de administración, haciendo uso de protocolos como SSH. [2]

92 5. Posibles alternativas Red Hat Enterprise Virtualization: Spice Descripción SPICE o Simple Protocol for Independent Computing Enviroments es la solución de escritorios virtuales presentada por la empresa Red Hat. Se trata de un protocolo de rendering remoto, adaptativo y de código abierto (open-source) que emplea se emplea en la infraestructura Red Hat Enterprise Virtualization for Desktops para conectar los usuarios con sus escritorios virtuales. Está basada en el Red Hat Enterprise Virtualization Hypervisor 10, una máquina virtual KVM [Apéndice B] y el proyecto de virtualización abierta ovirt 11. La empresa Red Hat se diferencia de las dos anteriores, por tanto, en que además de aportar una solución a la infraestructura de escritorios, esta utiliza su propio protocolo (SPICE). [14] Características Al igual que se realizó con sus dos competidores anteriores, se muestran aquí las características fundamentales de la solución de Red Hat. Es importante remarcar que Red Hat Enterprise Virtualization comprende todos los productos y características, es decir, no existen diferentes versiones, por lo que para esta solución no tiene sentido la realización de la tabla comparativa de versiones. [14] Rendimiento: La empresa Red Hat ofrece como una de sus principales características un gran rendimiento y una gran robustez de sus sistemas. Ofrece un alto rendimiento en operaciones E/S 12, lo que la hace adecuada para entornos de grandes cargas de trabajo (P.ej: Entornos con grandes bases de datos como 10 Un hipervisor o monitor de máquina virtual es una plataforma que permite aplicar diversas técnicas de control de virtualización para utilizar, al mismo tiempo, diferentes sistemas operativos, en un mismo ordenador. 11 Se trata de una plataforma libre de gestión y mantenimiento vía aplicación web de infraestructuras de virtualización. 12 Operaciones de entrada-salida.

93 5. Posibles alternativas 68 Oracle). Certifica su alto rendimiento en las pruebas SPECvirt 13 en las cuales se demuestra un alto rendimiento incluso con un número elevado de máquinas virtuales en un mismo nodo servidor. Flexibilidad: Al igual que sus dos competidores, otra de sus características fundamentales es su flexibilidad propiciada fundamentalmente por ser código abierto, lo que permite una amplia personalización. Además la solución Red Hat posibilita la virtualización tanto de escritorios Linux como Windows y está preparada para trabajar también con aplicaciones empresariales como Oracle, SAP y SAS. Por último, también ofrece una gran flexibilidad en cuanto a integración con servicios externos, ya que proporciona una serie de plug-ins que permiten una integración perfecta con herramientas de terceros. Gestión centralizada: Sistema de gestión centralizada a través de una interfaz gráfica pensada para controlar, gestionar y monitorizar grandes cantidades de equipos. Es decir, ofrece un portal de administración que proporciona todo tipo de información. Gestión empresarial: Permite la migración de aplicaciones y datos en vivo, alta disponibilidad de los mismos y equilibrio de la carga de trabajo basado en políticas (balanceo de carga). Aprovisiona de herramientas que permiten la generación de informes e históricos para poder ofrecer una íntegra información del sistema. Seguridad: Proporciona un nivel de seguridad a nivel de kernel y asegura la solución de vulnerabilidades críticas en el máximo de 24h. Desarrollo: La solución Red Hat proporciona una API Restful, que permite la programación propia de utilidades o aplicaciones para la infraestructura. Es también completamente integrable con OpenStack 14. Portal de usuario autoservicio: Sercicio de administración propio para los usuarios. Permite a los usuarios finales aprovisionarse de máquinas virtuales por sí mismos, al igual que definir plantillas y administrar su máquina/s virtuales Es un proyecto de computación en la nube para proporcionar una infraestructura como servicio (IaaS), bajo la filosofía del software libre y código abierto distribuido. Básicamente, se trata de un proyecto para el desarrollo de plataformas cloud.

94 5. Posibles alternativas 69 Almacenamiento flexible: Admite cualquier tipo de almacenamiento y sistemas de ficheros: iscasi, Fibre Channel, NFS, almacenamiento local, almacenamiento Red Hat y cualquier otros sistemas compatibles con el estándar POSIX Requisitos técnicos El entorno Red Hat Enterprise Virtualization presenta una serie de requerimientos de sistema mínimos para cada uno de sus componentes. Son los siguientes [14]: Red Hat Enterprise Virtualization Manager: Recomendado 1-2 quad core x86 64 processors, 16GB de RAM, 50GB de disco y una conexión ethernet gigabit. Red Hat Enterprise Virtualization Hypervisor: Recomendaciones mínimas de 1 CPU Intel 64 o AMD64 con las extensiones hardware para virtualización AMD-VTM o Intel VT. Memoria RAM mínima 2GB de RAM y 10GB de almacemiento local. Conexión ethernet gigabit Soporte Red Hat presenta dos tipos de soporte en función del plan contratado: Bussinesshour y 24x7x365. Como es evidente, el primero de ellos es un soporte en horas laborables, es decir, durante 8 horas diarias los días de semana, mientras que la segunda de las opciones ofrece un soporte completo durante todo el año. Por otra parte, es importante destacar que para implantar una infraestructura de virtualización Red Hat, es necesaria también una suscripción de Linux Red Hat (Red Hat Enterprise Linux) en cada servidor de la infraestructura y cada una de estas licencias es vendida de forma separada a la licencia de la infraestructura (Red Hat Enterprise Virtualization), lo que incrementa los costes en caso de no disponer ya de licencias o servidores Red Hat en el data center. [14]

95 5. Posibles alternativas Comparativa de productos Una vez realizado el análisis pormenorizado de cada una de las posibles alternativas 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 realizará la implantación de la infraestructura. Por otra parte, como es evidente, se omitirán en la comparativa aquellas características innatas de los sistemas analizados o aquellas que pueden darse por supuestas (P.ej: 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 Universidade da Coruña 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 anteriores en sus versiones enterprise destinadas a ser implantadas 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 realizada 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, como de las versiones gratuitas. De este modo, se podrá 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 Comparativa de las versiones de pago A continuación se muestra en una serie de tablas la comparativa de Ulteo, QVD y Red Hat en sus versiones más completas. La división es la siguiente: Tabla 5.3: En la primera de las tablas se ofrece una comparativa de los distintos clientes de acceso al escritorio virtual. Se trata de una característica que ofrece movilidad y flexibilidad al usuario y es por ello que debe ser considerada. Tabla 5.4: Se muestra la comparación de las características relacionadas con la instalación, configuración y administración del sistema, centrándose en aque-

96 5. Posibles alternativas 71 llas consideradas fundamentales para la organización en la cual el sistema será implantado. Tabla 5.5: La tercera de las tablas ofrece la comparación entre los distintos tipos de soporte, así como sus características. Tabla 5.6: Comparativa de precios. Aunque para la realización de este proyecto se empleará alguna de las versiones gratuitas, es importante mostrar una comparativa de los precios de las versiones más avanzadas de cara a un posible cambio hacia las versiones de pago en un futuro. Característica Descripción Ulteo QVD SPICE Acceso al escritorio virtual a Cliente Windows través de un software nativo desde S.O Windows. Acceso al escritorio virtual a Cliente Linux través de un software nativo desde S.O Linux. Acceso al escritorio virtual a Cliente OS X través de un software nativo desde S.O MAC OS X. 15 Cliente Android Cliente ios Cliente Web Software de cliente ligero Acceso al escritorio virtual con un dispositivo Android Acceso al escritorio virtual con un dispositivo ios (iphone & ipad). Acceso al escritorio virtual a través de un navegador web Mini S.O que ejerce las funciones de Thin Client. Cuadro 5.3: Comparativa de los clientes de acceso al escritorio de las alternativas 16 En fase beta. 17 No dispone de aplicación oficial, aunque si hay una aplicación compatible con el protocolo SPICE: aspice.

97 5. Posibles alternativas 72 Característica Descripción Ulteo QVD SPICE Administración web Administración delegada Control de acceso Compatibilidad CIFS o NFS Imágenes personalizadas Compatibilidad con Vmware Administración a través de una completa interfaz web. 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. 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. Ofrece compatibilidad con el sistema de ficheros CIFS o NFS Proporcionar imágenes de S.O personalizadas bajo unos requisitos. Permitir la integración y complementación de una infraestructura Vmware existente. Cuadro 5.4: Comparativa de características relacionadas con la administración y monitorización Característica Descripción Ulteo QVD SPICE Soporte Plan de soporte 24x7x365 8x5 o 24x7x365 8x5 o 24x7x365 Soporte por Resolución de problemas a través de correo electrónico con respuesta rápida. Soporte online Resolución de problemas simples a través de una aplicación web. Cuadro 5.5: Comparativa de características relacionadas el soporte ofrecido

98 5. Posibles alternativas 73 Característica Descripción Ulteo QVD SPICE Precio Planes de precios de las versiones más completas y avanzadas. ND 18 Desde 90 euros 19 Desde 999 dólares 20 Cuadro 5.6: Comparativa de precios de los servicios Comparativa de las versiones gratuitas Aunque la comparativa anterior es imprescindible, de cara a este proyecto, se debe poner especial atención en las versiones que no son de pago, pues una de estas será la solución a implantar. Se realizará por tanto una comparativa de las posibles soluciones gratuitas, descartando en este punto la opción de Red Hat, por no disponer de una alternativa de este tipo (únicamente dispone de una versión de prueba de 30 o 60 días). Los puntos comparativos serán análogos a los del punto anterior, por ser los más importantes. Se muestran en las Tablas 5.7, 5.8 y No disponible. 19 Precio por usuario y para la contratación de más de 5000 usuarios. Entre 2500 y 5000 usuarios el precio es 96 euros. Entre 1000 y 2500 el precio es 102 euros. Entre 500 y 1000 usuarios el precio es 108 euros y para menos de 500 usuarios 120 euros. Precios anuales y durante el primer año. Se reducen significativamente en años posteriores. 20 Precio con soporte básico 8x5. El precio con el soporte 24x7x365 es de dólares. Estos precios son anuales y por cada Hypervisor Socket Pair contratado.

99 5. Posibles alternativas 74 Característica Descripción Ulteo QVD Cliente Windows Cliente Linux Cliente OS X Cliente Android Cliente ios Cliente Web Software de cliente ligero Acceso al escritorio virtual a través de un software nativo desde S.O Windows. Acceso al escritorio virtual a través de un software nativo desde S.O Linux. Acceso al escritorio virtual a través de un software nativo desde S.O MAC OS X. Acceso al escritorio virtual con un dispositivo Android Acceso al escritorio virtual con un dispositivo ios (iphone & ipad). Acceso al escritorio virtual a través de un navegador web Mini S.O que ejerce las funciones de Thin Client Cuadro 5.7: Comparativa de los clientes de acceso al escritorio 21 En fase beta. 22 En fase beta. 23 En proyecto.

100 5. Posibles alternativas 75 Característica Descripción Ulteo QVD Administración web Administración delegada Control de acceso Compatibilidad CIFS o NFS Compatibilidad con VMware Administración a través de una completa interfaz web. 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. 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. Ofrece compatibilidad con el sistema de ficheros CIFS o NFS Ofrece compatibilidad con infraestructuras VMware Cuadro 5.8: Comparativa de características relacionadas con la administración y monitorización Característica Descripción Ulteo QVD Soporte Plan de soporte Comunidad Comunidad 24 Soporte por Resolución de problemas a través de correo electrónico con respuesta rápida. Soporte online Resolución de problemas simples a través de una aplicación web. Cuadro 5.9: Comparativa de características relacionadas el soporte ofrecido

101 5. Posibles alternativas Solución a implantar 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 consistió 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, intuitividad 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: Ulteo: Tal y cómo se muestra en la tabla comparativa 5.3 de la sección anterior, la solución Ulteo en su versión gratuita (Community Edition) sólo 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 sólo están disponibles en su versión de pago (Premium Edition). 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. Del mismo modo, el 24 Hace referencia a un soporte proporcionado por la comunidad mediante el uso de foros propios y externos, así como también fuentes de información alternativas. La empresa se despreocupa de cualquier mal funcionamiento o fallo, siendo labor del administrador de sistemas su resolución.

102 5. Posibles alternativas 77 cliente ios se encuentra en desarrollo y será posible también emplearlo con la alternativa gratuita. 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 autoprovisión de escritorios, aislamiento de máquinas virtuales, etc. Una vez más, ambas soluciones son totalmente completas y funcionales Una vez analizados en detalle todos los puntos anteriores, llegó el momento decisivo de tomar una decisión sobre la solución que se implantará en este proyecto piloto, 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ía considerar que la solución QVD fue la seleccionada para

103 5. Posibles alternativas 78 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.

104 Capítulo 6 Implantación Índice general 6.1. Qué es QVD? Componentes principales Componentes secundarios Componentes internos L7R HKD Objetos Arquitectura Tecnologías de virtualización Virtualización KVM Virtualización LXC Diseño del sistema Selección de la tecnología Diseño de la arquitectura de QVD Diseño de la arquitectura de red Implementación del sistema Configuración de la base de datos Configuración del servidor de administración

105 6. Implantación Configuración de los nodos QVD Operación del sistema Pruebas de funcionamiento Optimización del sitema Autenticación externa Auto provisión Almacenamiento compartido Balanceador de carga Configuración del balanceador de carga Configuración SSL Componentes hardware Politica de copia de seguridad Mejoras futuras En este capítulo se tratará el núcleo del proyecto: la implantación de la solución de escritorios virtuales QVD, por ser esta la solución más adecuada para la Universidade da Coruña, tal y cómo dictamina el análisis realizado en la Sección 5.5. Para ello, se realizará un recorrido previo por la solución comercial QVD: descripción, arquitectura y componentes para posteriormente dar paso a su instalación y adaptación en la infraestructura de la UDC Qué 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 [1], con sedes en España, México y Colombia. 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

106 6. Implantación 81 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 [2]: 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. 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 1 de nuevos escritorios e instalación de aplicaciones en los mismos. Características propias de los sistemas virtualizados, es decir, QVD ofrece cualquiera de las características básicas de la virtualización, descritas en en el Capítulo 3. 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[Apéndice B] permitiendo implementar cualquiera de las dos opciones, en función de las necesidades de la organización o la preferencia deseada por los administradores. 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. 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[Apéndice B], a su vez QVD 1 Consiste en la posibilidad de asignar de forma automatica escritorios a un usuario o un grupo de usuarios

107 6. Implantación 82 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. 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 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 [3], tal y cómo se puede ver en la Figura 6.1. Dichos componentes pueden estar presentes de forma conjunta en un sólo nodo servidor (pequeñas instalaciones o destinadas a pruebas) o bien distribuirse en diferentes nodos para entornos de producción.

108 6. Implantación 83 Figura 6.1: Esquema básica de QVD Los componentes principales de cualquier instalación QVD son básicamente tres: Servidor o servidores QVD (1): Se trata del nodo/s de procesamiento en los que se ejecutarán las máquinas 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): Será el encargado de ejecutar la interfaz de administración que emplearán 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. Éste contiene una base de datos incluye toda la información acerca de los usuarios, máquinas, servidores, sistemas operativos y configuraciones del entorno. Clientes de acceso QVD (4): Se trata del conjunto de programas software

109 6. Implantación 84 disponibles para las diferentes plataformas y que permiten el acceso al escritorio virtual Componentes secundarios Todos y cada uno de 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 [3] 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. Dichos componentes se muestran en un diagrama de ejemplo en la Figura 6.2. Figura 6.2: Esquema de QVD con componentes adicionales 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

110 6. Implantación 85 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. ej: directorio home). 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. Al encontrarse dentro de las máquinas virtuales no puede mostrarse en la Figura Componentes internos Profundizando en la arquitectura de QVD, es el momento de tratar los componentes que lo forman a bajo nivel [3], los realmente encargados de llevar a cabo las tareas principales de la infraestructura para que todo funcione de forma correcta. Los core components de QVD son: L7R: Conocido como Layer-7 Router o Router de capa 7. Es el encargado de ejercer las tareas de broker 2, característico de este tipo de entornos. Es decir, será el responsable de realizar dentro de los nodos QVD, todas las tareas para establecer las sesiones que abren los usuarios contra sus máquinas virtuales. Gestiona los usuarios. HKD: Es el otro de los daemons encargados del funcionamiento interno de QVD. El House Keeping Daemon es el encargado de gestionar el estado de las máquinas 2 Es el encargado de determinar qué escritorio virtual será asignado a qué usuario, siendo éste el que establece la conexión.

111 6. Implantación 86 virtuales (arranques, paradas, etc). Gestiona y monitoriza cada una de las VM s, siendo también el responsable de actualizar la información sobre el estado de las máquinas en la base de datos. Gestiona las máquinas virtuales. En la Figura 6.6 se muestra un diagrama completo en el que se introducen los dos nuevos componentes descritos y las relaciones de estos con los componentes descritos en las secciones anteriores. Figura 6.3: Arquitectura general de QVD L7R La conexión de un cliente a su escritorio virtual, se realiza a través de una conexión HTTPS contra uno de los servidores de QVD (previa autenticación). Es en éste proceso donde el Layer-7 Router cobra mayor importancia. El L7R, una vez recibe una petición de autenticación, debe comprobar la base de datos de la infraestructura para determinar el modo de autenticación configurado. Si la autenticación es a través de un mecanismo externo (como LDAP), deberá realizar los pasos apropiados para autenticar al usuario, mientras que si la autenticación se realiza

112 6. Implantación 87 propiamente en el sistema, simplemente será necesario comprobar las credenciales en la tabla de usuarios de la base de datos de QVD. En cualquiera de los casos, si la autenticación es satisfactoria devolverá un mensaje HTTP OK y 401 Unautorized en otro caso. Una vez finalizado el proceso de autenticación, el L7R tiene que comprobar la lista de máquinas virtuales o escritorios de los que dispone el usuario autenticado y responder con dicha lista al cliente. El usuario deberá seleccionar la máquina virtual a la que se desea conectar (si hay más de una). Es labor del L7R el asegurarse de que las máquinas virtuales están disponibles y si la máquina solicitada no se encuentra en ejecución en ninguno de los nodos, éste debe iniciarla automáticamente en el nodo más apropiado (en función de la configuración del balanceador de carga será más apropiado un nodo u otro). Una vez se encuentre disponible la VM 3 del usuario, el L7R establecerá la comunicación entre el usuario y su máquina virtual a través del protocolo NX. Por último, una vez el usuario está vinculado a su máquina, deberá actualizarse el estado en la base de datos para indicar que un cliente está conectado, labor también del demonio L7R. Por otra parte, en entornos reales de balanceo de carga, el Layer-7 Router presenta la capacidad de redirigir a un usuario al nodo en el que se encuentra en ejecución su máquina virtual. Imaginando un entorno con un nodo A y otro nodo B, si un usuario se conecta al nodo B, pero su VM se encuentra ya en ejecución en el nodo A, el L7R redirigirá la conexión del usuario al nodo A. En el caso de no existir previamente la VM en ejecución, se hace uso de un algoritmo de balanceo para determinar el nodo más apropiado para iniciar la máquina virtual. En la Figura 6.4 se muestra el diagrama de interacción cliente-servidor, en el que se puede apreciar las labores del demonio L7R comentadas durante esta sección. 3 Virtual machine o máquina virtual

113 6. Implantación 88 Figura 6.4: Interacción cliente-servidor y demonio L7R HKD El House Keeping Daemon es el daemon o demonio que se ejecuta en cada uno de los nodos de QVD y es el responsable de realizar la total gestión de las máquinas virtuales en ejecución sobre los nodos. Realiza las actualizaciones de estado mediante polls o actualizaciones periódicas en la base de datos PosgreSQL. Como es lógico el HKD, además de tratar los cambios de estado, será también el encargado de ejecutarlos mediante el envío de comandos a la máquina virtual. Ejemplificando, si se envía una señal de apagado a una máquina virtual, el demonio debe enviar la señal de terminación a la máquina virtual y una vez confirmado el cambio de estado deberá enviar la actualización a la base de datos para que dicho cambio pueda se reflejado en todo el sistema. El funcionamiento HKD es dependiente de la tecnología de virtualización empleada (KVM o LXC) y existen ligeras diferencias en la actividad a bajo nivel: Cuando la virtualización es KVM, el demonio de HKD ejecuta una instancia de

114 6. Implantación 89 Estado Stopped Starting 1 Starting 2 Running Stopping 1 Stopping 2 Zombie 1 Zombie 2 Descripción Máquina virtual parada. No se está ejecutando en ningún nodo servidor. Señal de arranque recibida. HKD espera a tener los recursos disponibles en los nodos servidor para proceder a su arranque. La máquina virtual se está iniciando, pero el proceso de arranque no ha finalizado. Máquina virtual en ejecución. Todos los servicios están levantados. Señal de parada recibida. HKD espera a la respuesta de parada por parte de la máquina virtual. La máquina virtual respondió al proceso de parada y se está llevando a cabo el apagado. La máquina virtual no responde. Se envía una señal de terminación (TERM). La máquina virtual no responde. Se envía una señal de forzar terminación (KILL). Cuadro 6.1: Tabla resumen de los posibles estados de una máquina virtual en una infraestructura QVD KVM para cada máquina virtual que es lanzada y carga la configuración de la misma desde la base de datos y los datos del usuario. Cuando la tecnología de virtualización es LXC, el trabajo de HKD se complica, siendo necesario que HKD seleccione la imagen del sistema operativo a cargar y la descomprima. Hecho esto, deberá vincular o unir dicha imagen con el sistema de ficheros del usuario de la máquina virtual (los datos propios del usuario), creando una nueva imagen que será lanzada en una instancia LXC. A mayores de las tareas descritas, el House Keep Daemon debe comprobar todo el proceso de inicialización de la máquina virtual: arranque, conexión y configuración de red y que el QVD Virtual Machine Agent[6.3] se encuentra en ejecución. Si existe cualquier problema, HKD cambiará el estado de la máquina virtual a blocked y tras un período de tiempo enviará una señal de terminación a la máquina. Los estados posibles de una máquina virtual y su descripción se pueden encontrar en la Tabla 6.1.

115 6. Implantación Objetos Es importante diferenciar antes de profundizar en la instalación de QVD, los diferentes objetos [3] de los que se compone a alto nivel una infraestructura. Son aquellos elementos manipulables por el equipo de administración. Usuarios: Serán los beneficiarios del uso de los escritorios virtuales. Normalmente un usuario tendrá asignadas una o más máquinas virtuales (escritorios). Hosts: Equipo o grupo de equipos hardware sobre los que se ejecutan las máquinas virtuales. Máquinas virtuales: Son las encargadas de correr los escritorios virtuales. Cada máquina virtual tendrá asignada una OSF. Operating System Flavours (OSF): Básicamente se compone de dos elementos: una imagen de disco y varios parámetros de ejecución, es decir, contiene la información sobre el sistema operativo que se ejecuta en una máquina virtual (memoria RAM a utilizar, cantidad de espacio de usuario, etc), pero no contienen el sistema operativo en sí mismo (sistema de ficheros). Una OSF puede ser asignada a varias imágenes de disco y es realmente la OSF la que se asigna a un usuario. Es decir, cuando se habla de que un usuario posee una o más máquinas virtuales, detrás de cada máquina virtual habrá una OSF, que es el conjunto de la imagen de disco del sistema operativo y los parámetros de ejecución. Imágenes de disco (DI): Contienen el sistema operativo, es decir, todo el sistema de ficheros y los datos necesarios del operativo. Es necesario vincular siempre una imagen de disco a una OSF, de tal forma que la imagen proporcione el contenido del sistema operativo y la OSF el resto de parámetros Arquitectura Tomando como base el esquema de la Figura 6.5 y 6.6, en esta sección se procederá a explicar la arquitectura típica de una infraestructura QVD y cómo interactúan los componentes descritos en las Secciones 6.2 y 6.3. Es importante destacar que se trata de

116 6. Implantación 91 una explicación a alto nivel y por lo tanto no abarcará muchos de los procesos internos involucrados, que serán tratados más adelante con mayor detalle. Con el objetivo de no saturar las imágenes, se dividió el proceso de interacción en dos partes: una primera parte en la que se describirá las relaciones de todos los componentes sin incluir el servidor de administración (tomando como base la Figura 6.5) y otra en la que se tratan las interacciones del servidor de administración con el resto de componentes (Figura 6.6). Figura 6.5: Interacción básica entre los clientes y servidores QVD. 1. El software cliente puede realizar la conexión a la infraestructura (hacia un nodo servidor) desde la propia LAN corporativa o a través de Internet, empleando para ello el protocolo HTTPS y mediante autenticación (bien mediante el mecanismo de autenticación propio de QVD o haciendo uso de un mecanismo externo como LDAP o Active Directory). 2. El nodo servidor contra el que se realizó la conexión anterior se conecta ahora con la base de datos PosgreSQL para autenticar el usuario y cargar las configuraciones propias del mismo (es obvio que si la autenticación es a través de un mecanismo externo como LDAP, la autenticación será primeramente contra éste y una vez autenticado se comprobará con la base de datos para obtener únicamente las configuraciones del usuario). La base de datos proporcionará también

117 6. Implantación 92 la información sobre la/s máquina/s virtuales de las que dispone el usuario. Por último, el nodo servidor actualizará la información de la sesión activa, la máquina virtual ejecutada y el usuario para que la información de monitorización esté actualizada. 3. Una vez autenticado el usuario y conocidos los datos necesarios sobre la máquina virtual, se negocian los parámetros para establecer una conexión segura a través del protocolo NX. Cuando los datos sean confirmados el cliente estará preparado para conectarse al escritorio virtual del usuario. 4. Antes de realizar la conexión desde el cliente, el nodo servidor debe cargar la imagen del sistema operativo desde el almacenamiento compartido (de ahí la importancia de que todos los nodos tengan acceso al almacenamiento compartido). Para cada máquina virtual iniciada por un usuario se crea una imagen en formato.qcow que contendrá la información del directorio home de ese usuario y que se almacenará también en el almacenamiento compartido posibilitando así, por tanto, que un usuario tenga acceso a su escritorio independientemente del nodo QVD al que realice la conexión. Figura 6.6: Interacción básica entre el servidor de administración y los servidores QVD. Tras describir los pasos en la comunicación entre los clientes y los servidores QVD,

118 6. Implantación 93 es ahora el turno de tratar los mensajes que se realizan entre el servidor o interfaz de administración y el resto de componentes de la arquitectura de QVD. 1. Representa la conexión al servidor de administración, bien una conexión a través de un navegador a la interfaz de administración web, como a través de SSH para la administración a través de línea de comandos. La conexión contra la interfaz web puede ser a través de HTTP o HTTPS y es necesario una autenticación específica para la misma. 2. Representa cualquier conexión entre la interfaz de administración y la base de datos, para almacenar cualquier tipo de configuración realizada a través de la interfaz web o la línea de comandos. Por otra parte, la información que se visualiza en la interfaz web es extraída automáticamente y en tiempo real de la base de datos (usuarios conectados, máquinas virtuales en ejecución, etc). 3. El servidor de administración hace uso del almacenamiento compartido para poder manipular las imágenes de los sistemas operativos, o poder crear las OSF[6.5]. 4. Cada uno de los servidores QVD, periódicamente envían información a la bases de datos PosgreSQL, de tal forma que le notifica todos y cada uno de los cambios de estado de las máquinas virtuales, o el estado de los usuarios. La base de datos actuará como un intermediario entre los servidores de QVD y la información mostrada por el servidor de administración Tecnologías de virtualización La solución de QVD ofrece la posibilidad de instalar y configurar la infraestructura seleccionando la tecnología de virtualización deseada a bajo nivel para la ejecución de las máquinas virtuales de los escritorios. Aunque ya se comentó esta posibilidad de selección en puntos anteriores, no se trataron en detalle las ventajas e inconvenientes que cada una de ellas ofrece para cada caso en particular. Tras comentar los detalles de cada tecnología se dedicará un apartado a la explicación y justificación de la selección tomada para la elaboración de este proyecto.

119 6. Implantación Virtualización KVM La tecnología de virtualización Kernel Virtual Machine es una solución de virtualización completa sobre GNU/Linux que está formada por un módulo para el kernel (kvm.ko) y herramientas en el espacio de usuario. Permite ejecutar máquinas virtuales empleando imágenes de disco que contienen sistemas operativos sin modificar. Cada máquina virtual contiene su propio hardware virtualizado, algo que es posible gracias a emplear una versión modificada de QEMU 4. Se trata, básicamente de un hipervisor que se ejecuta dentro del kernel (no es necesario modificar el kernel, ya que se trata simplemente de un módulo) de la máquina Linux anfitriona [5]. De esta forma el KVM actúa como intermediario entre el anfitrión y la máquina virtual asegurando una total independencia entre ambos. Hospeda las máquinas virtuales como procesos, por lo que cada máquina virtual podrá beneficiarse de todas las características del kernel de Linux 5, heredando los drivers y el amplio soporte hardware de este con el único requisito de necesitar las extensiones para virtualización Intel VT-x 6 o AMD-V 7. Aunque existe un gran debate alrededor de la clasificación de KVM dentro de la virtualización, actualmente se considera en su mayoría, un hipervisor tipo I o baremetal [ ]. [5] Las ventajas más destacables de este tipo de virtualización en un entorno QVD son, en resumen: Diseñado para entornos de virtualización total. No es necesaria la modificación del kernel del host anfitrión. Compatibilidad e integración total para entornos Linux. Es Open Source Independencia entre máquinas virtuales y host anfitrión. 4 Emulador hardware 5 Aunque KVM está fuertemente ligado a Linux, soporta los sistemas de Microsoft como invitados, es decir, en las máquinas virtuales. De echo, el soporte Windows está en las mismas raíces del proyecto KVM, pensado inicialmente para la virtualización de escritorios Windows. 6 Intel Virtualization Technology. Soporte para virtualización de Intel. 7 AMD Virtualization. Soporte para virtualización de AMD

120 6. Implantación 95 Facilidad de instalación, configuración y gestión. Es un hipervisor ligero, de gran rendimiento y software libre Virtualización LXC Linux Containers es una tecnología de virtualización basada en contenedores, que permite crear jaulas aisladas [6]. Una jaula conenedora es un sistema GNU/Linux autocontenido dentro de otro, al que se le pueden aplicar cuotas de disco, CPU, memoria, una o varias interfaces de red, algunos otros límites y capacidades e iniciarlo como si de un equipo independiente se tratase. En resumen, crear equipos o máquinas virtuales. LXC es construido dentro de una jaula (chroot) y proporciona un sistema virtual completo, con mecanismos de aislamiento y individualización (isolation) que son completamente nativos al kernel Linux. A diferencia de una virtualización al estilo KVM, una virtualización basada en contenedores sólo permite emplear máquinas virtuales con el sistema operativo del host anfitrión, en este caso, diferentes versiones o distribuciones de GNU/Linux. [6] Destaca por no necesitar una gran cantidad de recursos para levantar un contenedor LXC, ya que consumen menos recursos que una máquina KVM. Además de su ventaja principal, existen otras importantes: Recursos, servicios y aplicaciones ofrecen un rendimiento práticamente igual al nativo. No es necesario un hardware especial. Es Open Source. No necesita ningún módulo en el kernel.

121 6. Implantación Diseño del sistema Una vez conocida la arquitectura y componentes de la solución QVD, es momento de llevar a cabo la toma de otras decisiones que condicionarán la instalación y el funcionamiento de la infraestructura. Es necesario tomar en este punto varias decisiones: el entorno y la arquitectura de QVD para la Universidad, el sistema operativo seleccionado para los nodos QVD y seleccionar la tecnología de virtualización a emplear Selección de la tecnología Una vez analizada toda la documentación de la solución QVD, el primero de los pasos que se presentan previos a la instalación y configuración del producto, es decidir la tecnología de virtualización a emplear: KVM o LXC. Es uno de los pasos más importantes en el proceso de implantación de QVD y guiará la instalación y el tratamiento de las imágenes de disco por uno u otro camino. Para el proyecto piloto desarrollado, se barajaron desde un inicio ambas posibilidades, teniendo en cuenta una serie de puntos clave para la toma de decisión: Manual técnico de QVD [3] más completo para una instalación de KVM y mayor comunidad detrás de la tecnología KVM. Administración de máquinas virtuales más sencilla mediante KVM. Los sistemas operativos virtualizados sobre LXC deben ser compatibles con el kernel del host anfitrión, pues es compartido con este. Mayor independencia en las imágenes de los sistemas operativos a favor de KVM. Permiten ejecutar en ambos casos un gran número de instancias, aunque LXC ofrece en todas ellas un rendimiento igual al nativo. La desventaja que presenta LXC en lo referente a la compatibilidad de las instancias con el kernel del host anfitrión y a la menor información existente sobre esta tecnología fueron los puntos que declinaron claramente la balanza hacia KVM como tecnología de virtualización para la infraestructura QVD a instalar en este proyecto.

122 6. Implantación 97 La selección de KVM como tecnología de virtualización, por otra parte trae consigo una pequeña pérdida de rendimiento con respecto a LXC, pero que puede ser fácilmente suplida gracias a la potencia hardware de los equipos actuales Diseño de la arquitectura de QVD Existen varios condicionantes que marcan el camino a seguir en el diseño de la arquitectura inicial de la infraestructura: el presupuesto, la disponibilidad de equipos hardware y la posibilidad de una ampliación futura. Por una parte, al ser este proyecto carente de presupuesto, no existe la posibilidad de compra de unos equipos nuevos y completamente dedicados para QVD, siendo necesario reutilizar y emplear para la instalación inicial equipos físicos en desuso y servidores virtuales. Los equipos disponibles y sus características se listan a continuación: Dos servidores físicos: HP ProLiant DL140 G x Intel(R) Xeon(R) CPU GHz 64-bit. Memoria: 3GB RAM. Las máquinas descritas se pueden ver en la Figura 6.7. Figura 6.7: Máquinas hardware para QVD Dos servidores virtuales: VMware ESXi Virtual Servers. Memoria: 1GB RAM. El diseño de la arquitectura de QVD consistió básicamente en la asignación de los componentes principales de la solución vistos en la Sección 6.2 a cada uno de los servidores mencionados, en función de los requisitos hardware. Un servidor virtual para el servidor base de datos: Aunque la base de datos mantiene información vital para el funcionamiento de la infraestructura,

123 6. Implantación 98 la carga de trabajo no es excesivamente elevada (simplemente ciertas consultas en el proceso de conexión y actualizaciones periódicas de estado), por lo que un servidor virtual con unos requisitos moderados es más que suficiente para el proyecto. Evidentemente en un entorno de producción con cientos o miles de usuarios la carga de trabajo de la base de datos se incrementa considerablemente, pero el aumento de potencia hardware en un servidor virtual es trivial y altamente escalable (la recomendación de QVD para entornos en producción es de dos núcleos de procesador y 2GB de memoria RAM). Un servidor virtual para el servidor de administración: Suficiente para la ejecución de un servidor Apache para la aplicación web de administración. Debe ser capaz de soportar un número reducido de conexiones a la aplicación web y SSH que realizarán los administradores para el mantenimiento y/o monitorización de la infraestructura. Al tratarse de un servidor virtual, es altamente escalable aumentando la capacidad hardware, aunque en este caso será raramente necesario pues aunque el número de usuarios de los escritorios sea elevado, la administración será centralizada y llevada a cabo por un reducido número de personas, que este servidor soportará holgadamente. Dos servidores físicos para los nodos QVD: Los servidores físicos de mayor potencia hardware serán los que alojarán los servidores de cómputo de QVD, sobre los que se ejecutarán las máquinas virtuales y los demonios L7R y HKD descritos en la Sección 6.4. La capacidad de escalabilidad de la infraestructura se ve penalizada en este punto por falta de recursos a corto plazo, aunque nada impide a largo plazo aumentar el número de nodos o realizar una simple migración de estos nodos hacia unos nodos físicos con mayor capacidad. En la Figura 6.8 se muestra un diagrama del diseño inicial implementado para este proyecto piloto, con las relaciones entre nodos.

124 6. Implantación 99 Servidor virtual QVD Database Servidor virtual QVD WAT Servidor físico QVD Node Servidor físico QVD Node WAN/LAN Figura 6.8: Arquitectura de QVD diseñada para el proyecto Diseño de la arquitectura de red Tras el diseño de los sistemas, es el momento crear el sistema de comunicación entre los nodos de la infraestructura en el que la única labor radica en el diseño conceptual y requisitos necesarios, ya que la propia tarea de creación y administración de las comunicaciones corresponde al Departamento de Red y Comunicaciones de la Universidade da Coruña. La primera necesidad es una red o subred nueva (o hacer uso de una existente en la

125 6. Implantación 100 corporación) en la que se deben alojar todas las máquinas de la infraestructura QVD. Es válido también que se encuentren en redes distintas, pero con conexión entre ellas. Aunque el dedicar una red no es condición indispensable para QVD, si será altamente recomendable para mejorar rendimientos y latencias, algo que favorecerá siempre a la experiencia de usuario en los escritorios virtuales. Además, los nodos de cómputo de QVD, hacen uso de un bridge 8 o puente de red e interfaces virtuales para la conexión entre cada una de las máquinas virtuales que corren en cada nodo, por lo que será necesaria otra red para alojar a las máquinas virtuales en ejecución. En definitiva, serán necesarias dos redes diferentes: Red de administración: En ella se alojarán las máquinas que conforman la infraestructura: la base de datos, el servidor de administración y los dos nodos QVD. Para este proyecto, se hace uso de una red existente y proporcionada por el Departamento de Red en la que se encuentran varios servicios de la Universidad. Dicha red presenta espacio de direcciones suficiente y escalable para albergar a las cuatro máquinas iniciales y muchas otras en el caso de una ampliación de la infraestructura. La red es la siguiente 9 : Red: Gateway: Netmask: Red de las máquinas virtuales: Alojará a todas las máquinas virtuales en ejecución de la infraestructura. Estará vinculada a la red de administración a través del bridge y la interfaz de red virtual de los nodos. Es importante remarcar aquí que la red de las máquinas virtuales debe disponer de direcciones IP suficientes para dar cobertura a la totalidad de usuarios de los escritorios virtuales (de ahí la utilización de una red con máscara /22), pues la única forma de dividir u ordenar los usuarios es la asignación de rangos de IP diferentes a cada uno de los grupos. Para el caso de este proyecto y a modo de ejemplo, si se desea clasificar 8 Dispositivo de conexión de redes que opera en la capa 2 (nivel de enlace) del modelo OSI. Interconecta o divide una red en segmentos haciendo la transferencia de datos de una red a otra con base en la dirección física de destino de cada paquete. 9 Por motivos evidentes de seguridad, las direcciones IP mostradas en el diagrama no son las reales, pero totalmente válidas para la comprensión y explicación del diseño.

126 6. Implantación 101 los usuarios en función de las facultades o la titulación, es necesario asignar un rango de IP dentro de esa red para los usuarios de cada facultad 10. Red: Gateway: Netmask: En la Figura 6.9 se ofrece un diagrama de red completo y a alto nivel de la infraestructura. 10 Otra opción para la clasificación para la creación de grupos de usuarios, sería la implantación de una infraestructura QVD completa para cada grupo, algo mucho más costoso y más difícil de administrar.

127 6. Implantación 102 WAN /24 DB WAT QVD1 QVD2... VM VM VM VM VM /22 WAN Figura 6.9: Arquitectura de QVD diseñada para el proyecto 6.9. Implementación del sistema Tras las etapas de decisión, planificación y diseño es el momento de llevar a cabo la tarea puramente técnica: la instalación y configuración de la infraestructura. Para ello, fue clave la ayuda del manual técnico proporcionado por QVD, en el cual se tratan en detalle la instalación de cada uno de los componentes principales [6.2] y componentes secundarios [6.3], así como el orden de configuración adecuado. Todo el proceso de instalación se abordará en la siguientes secciones.

128 6. Implantación Configuración de la base de datos La base de datos de la infraestructura QVD es el componente que establece el vínculo entre todas las partes del sistema y permite a todas trabajar conjuntamente. El gestor seleccionado por QVD es PosgreSQL [4]. Toda la información en tiempo real de las máquinas virtuales, usuarios y configuraciones se encuentra almacenada en la base de datos y por tanto, esta constituye un SPOF 11 o punto único de fallo. Por esta razón es muy recomendable que la base de datos se encuentre instalada y configurada en un entorno altamente disponible (HA), pero debido a las restricciones de tiempo y presupuesto (es necesario un servidor adicional) quedará como una posible mejora futura. A continuación se muestra en la Figura 6.10 el diagrama relacional de la base de datos de la solución QVD, para dar una visión global del tipo y cantidad de datos manejados en la infraestructura. 11 Single Point Of Failure.

129 6. Implantación 104 Figura 6.10: Modelo relacional de la base de datos de QVD Los pasos técnicos principales de instalación del servidor base de datos [3] se muestran en sucesivos apartados.

130 6. Implantación Preparación y configuración básica del entorno 1. Instalación del sistema operativo Ubuntu Server y configuración básica de usuarios, grupos, cuentas y acceso SSH. 2. Configuración de la red. Configurar una IP estática para el servidor base de datos dentro de la red de administración descrita en la Sección La configuración empleada es: i f a c e l o i n e t loopback auto l o auto eth0 i f a c e eth0 i n e t s t a t i c address netmask up route add d e f a u l t gw dns nameservers Instalación del software y paquetería 1. Añadir la clave pública de los paquetes de QVD al fichero de claves (como root). $ wget qo http : / / theqvd. com/ packages /key/ p u b l i c. key sudo apt key add 2. Seguidamente, añadir los repositorios al apt sources y actualizarlos. $ echo deb http : / / theqvd. com/ packages /ubuntu QVD main > / e t c / apt / s o u r c e s. l i s t. d/qvd 34. l i s t $ apt g e t update 3. Instalación de la paquetería de QVD necesaria para la base de datos. Dentro de dicho paquete se encuentra, a su vez, la paquería del gestor PosgreSQL, que en el momento de la instalación se corresponde con la versión 9.1. $ apt get i n s t a l l perl qvd db

131 6. Implantación Creación de usuarios y base de datos 1. El primer paso es cambiar de usuario y realizar login con el usuario posgres creado automáticamente durante la instalación del gestor, con este usuario ya se disponen de los permisos suficiente para las tareas de gestión y configuración del gestor PosgreSQL. $ sudo su p o s t g r e s 2. Haciendo uso de los comandos de administración 12 de PosgreSQL, se crea un usuario dentro del gestor para acceder a la base de datos y a las tablas de QVD. $ c r e a t e u s e r SDRP qvd Enter password new r o l e : pass Enter i t again : pass 3. Creado un nuevo usuario Posgres, este ya puede ser asignado como propietario de una base de datos. Es momento por tanto, de crear la base de datos de QVD y asignar al usuario anteriormente creado (qvd) como propietario de la misma. $ createdb O qvd qvddb 4. Todos y cada uno de los nodos de la infraestructura, deben tener un fichero de configuración (node.conf ) que les indique en qué lugar se encuentra la base de datos, así como los datos de acceso a la misma. Aunque la creación de este fichero es uno de los primeros pasos, en este caso al tratarse propiamente el nodo BD, no se disponía de la información necesaria para la configuración de sus parámetros hasta este punto. Dicho fichero debe ser alojado en la ruta /etc/qvd y no es necesario crearlo manualmente, ya que QVD proporciona una plantilla. Una vez creado, se establecen los parámetros de la base de datos correctamente. $ cp R / usr / share /qvd/ c o n f i g / e t c /qvd $ v i / e t c /qvd/node. conf # # QVD Node C onfiguration # 12 Más información en: html

132 6. Implantación 107 # Name o f t h i s node in QVD. Usually the machine s hostname. nodename=vdilinux p o s t g r e s q l # Database connection information. # database. h o s t : where the QVD database i s found # database. name : the name o f the QVD database # database. user : the user account needed to connect # database. password : the password needed to connect database. host = database. name = qvddb database. user = qvd database. password = pass path. run = / var /run/qvd path. l o g = / var / l o g /qvd path. tmp = / var /tmp/qvd l o g. f i l e n a m e = / var / l o g /qvd/qvd. l o g l o g. l e v e l=info Configuración de PosgreSQL La base de datos está sometida a accesos concurrentes por parte de los nodos que conforman la infraestructura y por ello será necesario aplicar ciertas configuraciones adicionales. Es un paso muy importante y si por cualquier motivo el estado de la base de datos fuese inconsistente, provocaría un mal funcionamiento de la totalidad de la infraestructura. 1. El acceso concurrente a la base de datos está controlado por el parámetro default transaction isolation del fichero posgresql.conf. Se establece, por tanto, del valor read commited a serializable. $ v i / e t c / p o s g r e s q l /9.1/ main/ p o s g r e s q l. conf

133 6. Implantación d e f a u l t t r a n s a c t i o n i s o l a t i o n = s e r i a l i z a b l e Hecho esto, en el mismo fichero de configuración anterior, se cambia el parámetro listen addresses de localhost a *, para permitir el acceso por red a PosgreSQL. $ v i / e t c / p o s g r e s q l /9.1/ main/ p o s g r e s q l. conf... l i s t e n a d d r e s s e s = Además de permitir el acceso a PosgreSQL, se debe activar también el acceso a la propia base de datos. Se edita el fichero pg hba.conf y se añade una línea por cada una de las IP de las máquinas que forman parte de la infraestructura (aunque en este punto todavía no están configuradas todas las máquinas, las direcciones IP son conocidas, por estar reservadas de antemano). $ v i / e t c / p o s g r e s q l /9.1/ main/ pg hba. conf... host qvddb qvd / 3 2 md5 host qvddb qvd / 3 2 md5 host qvddb qvd / 3 2 md5 host qvddb qvd / 3 2 md Se reinicia el servicio para aplicar las configuraciones anteriores. $ s e r v i c e p o s g r e s q l r e s t a r t Creación de las tablas La paquetería instalada de QVD, incluye un script en perl (se encuentra en la ruta /usr/lib/qvd/bin), que ayuda a la creación de todas las tablas de la base de datos QVD. Una vez ejecutado el script, la base de datos está lista para su funcionamiento. $ cd / usr / l i b /qvd/ bin $. / qvd deploy. pl

134 6. Implantación Configuración del servidor de administración El servidor de administración es el punto desde el cual se realizaran todas la tareas administrativas de la infraestructura QVD por parte del personal de TI. Se trata básicamente de un servidor Apache con una aplicación web, que permite realizar las tareas de más comunes de forma local o remota: crear/eliminar usuarios, crear/eliminar máquinas virtuales, crear/eliminar imágenes de disco y monitorizar el estado de varios de los componentes de la solución. Además de la interfaz web, también se instalan una serie de scripts que permiten la realización de las mismas tareas a través de la consola de comandos. Esto puede resultar muy útil para la elaboración de scripts personalizados o en caso de fallo del servidor web. La instalación y configuración [3] se muestra a continuación Preparación y configuración básica del entorno 1. Instalación del sistema operativo Ubuntu Server y configuración básica de usuarios, grupos, cuentas y acceso SSH. 2. Configuración de la red. Configurar una IP estática para el servidor de administración dentro de la red principal comentada en la Sección La configuración de red es: i f a c e l o i n e t loopback auto l o auto eth0 i f a c e eth0 i n e t s t a t i c address netmask up route add d e f a u l t gw dns nameservers Creación del fichero de configuración base de QVD que debe poseer cada uno de los nodos. Es importante recordar que dicho fichero sirve para proporcionar al nodo la información de acceso a la base de datos. Tanto el servidor de administración como posteriormente el resto de nodos, deben incluir en este fichero un campo nodename que debe coincidir con el nombre asignado a la máquina.

135 6. Implantación 110 Este campo será utilizado por la base de datos para ofrecer información sobre las máquinas de la infraestructura. $ mkdir / e t c /qvd $ v i / e t c /qvd/node. conf # # QVD Node C onfiguration # # Name o f t h i s node in QVD. Usually the machine s hostname. nodename=vdilinux wat # Database connection information. # database. h o s t : where the QVD database i s found # database. name : the name o f the QVD database # database. user : the user account needed to connect # database. password : the password needed to connect database. host = database. name = qvddb database. user = qvd database. password = pass path. run = / var /run/qvd path. l o g = / var / l o g /qvd path. tmp = / var /tmp/qvd l o g. f i l e n a m e = / var / l o g /qvd/qvd. l o g l o g. l e v e l=info Instalación del software y paquetería 1. Añadir la clave pública de los paquetes de QVD al fichero de claves.

136 6. Implantación 111 $ wget qo http : / / theqvd. com/ packages /key/ p u b l i c. key sudo apt key add 2. Seguidamente, añadir los repositorios al apt sources y actualizarlos. $ echo deb http : / / theqvd. com/ packages /ubuntu QVD main > / e t c / apt / s o u r c e s. l i s t. d/qvd 34. l i s t $ apt g e t update 3. Instalación de la paquetería de QVD necesaria para el servidor web Apache y los scripts de administración. $ apt get i n s t a l l perl qvd admin web (WAT) $ apt get i n s t a l l perl qvd admin ( S c r i p t s ) Configuración del puerto de la WAT La aplicación web, evidentemente, escucha en un puerto determinado, que por defecto es el puerto 3000 para las peticiones HTTP. Si en la infraestructura existe algún conflicto con ese puerto (puede estar usado), puede cambiarse editando el fichero /etc/default/qvd-wat. $ echo PORT=6000 > / e t c / d e f a u l t /qvd wat Autenticación en la WAT El último de los pasos en la configuración de la aplicación web de administración es establecer el usuario y contraseña de la misma, haciendo uso de los scripts anteriormente instalados. $ qa c o n f i g set wat. admin. l o g i n=l o g i n $ qa c o n f i g set wat. admin. password=pass Básicamente, estos dos comandos anteriores sirven para modificar los campos de la base de datos y por ello es muy importante seguir el orden de instalación de QVD.

137 6. Implantación 112 Una vez instalada la consola de administración ya se puede acceder a ella sin mayores problemas. A continuación, en la Figura 6.11 se muestra la pantalla de administración de los nodos a través de la interfaz web y en la Figura 6.12 la administración de las máquinas virtuales. Figura 6.11: Administración de hosts a través de la WAT

138 6. Implantación 113 Figura 6.12: Administración de VM s a través de la WAT Problemas Una vez aplicada toda la configuración era imposible acceder a la máquina a través del navegador, es decir, el servidor Apache no respondía correctamente, lanzando un Internal Server Error. Para identificar error, fue necesario cambiar en la configuración del Apache(/etc/apache2/sitesenabled/qvd-wat.conf ) el LogLevel (tipo o nivel de detalle de los log) a modo Debug, de esta forma, el log de error del Apache es maś descriptivo (/var/log/apache2/error.log), dando así con el problema. El error residía en un problema de escritura del Apache en los ficheros de log de qvd (/var/log/qvd-wat.log). El Apache no tenía permisos para escribir en los ficheros de log, por lo tanto, la solución fue cambiar el propietario del fichero qvd-wat.log al usuario Apache (www-data) y cambiar los permisos del mismo, haciendo uso de las herramientas propias de Linux para dicho fin (chmod y chown).

139 6. Implantación Configuración de los nodos QVD Realizadas las configuraciones de la base de datos y el servidor de administración, es el momento de instalar el nodo o nodos de cómputo sobre el que se ejecutarán las máquinas virtuales. Los nodos QVD son los encargados de gestionar y controlar los demonios L7R y HKD, explicados en la Sección 6.4. Normalmente, son instalados más de un nodo formando arquitecturas clúster, y para este proyecto, serán inicialmente dos, lo que significa que el proceso de instalación será repetido en cada uno de los nodos. La diferencia en el proceso de uno a otro nodo será únicamente las direcciones IP (de la red de administración y de la red de las VM) del mismo. Para este caso concreto se instalaron dos nodos. Es indispensable en este punto observar el diagrama básico de red 6.9 mostrado en la Sección para comprender el por qué los nodos hacen uso de un bridge y una interfaz de red virtual para conectarse con las máquinas virtuales que están en ejecución en un nodo. Además, debe configurarse un servidor DHCP para proporcionar dinámicamente direcciones IP dentro de un rango a las VM. En el proceso de instalación de los nodos fue indispensable la colaboración externa del Departamento de Red de la Universidade da Coruña, que fue el encargado de la creación de una vlan y una subred propia para las máquinas virtuales. Todo el proceso de instalación e información técnica [3] se detalla a continuación Preparación y configuración básica del entorno 1. Instalación del sistema operativo Ubuntu Server y configuración básica de usuarios, grupos, cuentas y acceso SSH. 2. Configuración de la red. Configurar una IP estática para cada uno de los nodos QVD. Es importante comentar aquí que esta es una configuración de red inicial de los nodos con el único objetivo de poder acceder remotamente vía SSH. En apartados posteriores del proceso de instalación se realizará la configuración de red definitiva de los mismos. i f a c e l o i n e t loopback auto l o auto eth0

140 6. Implantación 115 i f a c e eth0 i n e t s t a t i c address netmask up route add d e f a u l t gw dns nameservers *Nota: La dirección IP del segundo nodo es Creación del fichero de configuración base de QVD que debe poseer cada uno de los nodos. Recordar que dicho fichero sirve para proporcionar al nodo la información de acceso a la base de datos. $ mkdir / e t c /qvd $ v i / e t c /qvd/node. conf # # QVD Node C onfiguration # # Name o f t h i s node in QVD. Usually the machine s hostname. nodename=vdilinux qvd1 # Database connection information. # database. h o s t : where the QVD database i s found # database. name : the name o f the QVD database # database. user : the user account needed to connect # database. password : the password needed to connect database. host = database. name = qvddb database. user = qvd database. password = pass path. run = / var /run/qvd path. l o g = / var / l o g /qvd path. tmp = / var /tmp/qvd

141 6. Implantación 116 l o g. f i l e n a m e = / var / l o g /qvd/qvd. l o g l o g. l e v e l=info Instalación del software y paquetería 1. Añadir la clave pública de los paquetes de QVD al fichero de claves. $ wget qo http : / / theqvd. com/ packages /key/ p u b l i c. key sudo apt key add 2. Seguidamente, añadir los repositorios al apt sources y actualizarlos. $ echo deb http : / / theqvd. com/ packages /ubuntu QVD main > / e t c / apt / s o u r c e s. l i s t. d/qvd 34. l i s t $ apt g e t update 3. Instalación de la paquetería de QVD necesaria para el/los nodo/s. $ apt get i n s t a l l perl qvd node 4. El comando anterior instalará sólo los componentes necesarios para el nodo, aunque también es altamente recomendable instalar los scripts de administración en todas y cada una de las máquinas de la infraestructura para facilitar y acelerar en ocasiones las labores de administración. $ apt get i n s t a l l perl qvd admin Configuración de red de los nodos Los nodos de QVD, hacen uso de un bridge y una interfaz de red virtual para conectarse con las máquinas virtuales que están en ejecución en un nodo. Además, debe configurarse un servidor DHCP para proporcionar dinámicamente direcciones IP dentro de un rango a las VM. Es indispensable en este punto recordar el diagrama básico de red 6.9 mostrado en la Sección para comprender los pasos que se mostrarán a continuación.

142 6. Implantación Instalar o configurar un servidor DHCP. QVD hace uso de dnsmasq (el cual también puede actuar como servidor DNS). Para ello, es necesario comprobar si dnsmasq se encuentra instalado y si no instalarlo. $ dpkg s dnsmasq O bien, instalarlo: $ apt get i n s t a l l dnsmasq 2. Por defecto, Ubuntu inicia el proceso dnsmasq como un demonio en background. Es muy importante que el demonio dnsmasq se ejecute bajo el control del proceso qvd-node, por lo tanto se debe desactivar el inicio automático de dnsmasq. $ s e r v i c e dnsmasq stop $ sed i s /ENABLED=1/ENABLED=0/ / e t c / d e f a u l t / dnsmasq 3. Configurar IP forwarding. Es necesario para enrutar los clientes a la localización correcta, es decir, cuando un cliente se conecta a un nodo, si su máquina virtual no está ejecutándose en ese nodo, este sea capaz de enrutarlo al nodo correcto. Para ello, es necesario cambiar el valor del parámetro net.ipv4.ip forward en el fichero /etc/sysctl.conf. $ v i / e t c / s y s c t l. conf... net. ipv4. i p f o r w a r d= Configuración del bridge y la interfaz virtual. Existen múltiples caminos de configuración, muy dependientes todos ellos de las características del entorno, red y disposición de las máquinas. Básicamente, la configuración reside en la creación de una nueva red para alojar a los clientes (VM s), así como a los propios nodos de QVD, a través del bridge y la interfaz virtual. En resumen, bastaría con decir que los nodos QVD tienen una interfaz física conectada a la red de administración y una interfaz virtual conectada a esta nueva red de las máquinas virtuales. La configuración de red de este proyecto se elaboró de forma personalizada para el entorno, con colaboración externa [6.9.3]. $ cat / e t c / network / i n t e r f a c e s

143 6. Implantación 118 auto l o i f a c e l o i n e t loopback auto eth0 eth1 qvdnet0 vlan200 i f a c e eth0 i n e t s t a t i c address netmask network gateway i f a c e eth1 i n e t manual i f a c e vlan200 i n e t manual vlan raw d e v i c e eth1 up ip l i n k set up dev vlan200 i f a c e qvdnet0 i n e t s t a t i c address netmask b r i d g e p o r t s vlan200 b r i d g e s t p on dns nameservers *Nota: La dirección del segundo nodo es: **Nota: La dirección del segundo nodo es: Es fácil ver que el nodo configurado presenta la IP dentro de la red de administración a través de la interfaz física eth0 y la IP dentro de la red de las máquinas virtuales a través de la interfaz virtual qvdnet0. 5. Para que la configuración anterior sea posible y tenga efecto, es necesario la instalación del paquete vlan. $ apt get i n s t a l l vlan 6. Una vez editado el fichero de configuración de la red e instalado el paquete vlan, hay que reiniciar el servicio para aplicar la nueva configuración. $ / e t c / i n i t. d/ networking r e s t a r t

144 6. Implantación Parámetros de QVD Cuando se finaliza la instalación de los nodos, es necesario dar a conocer todos los datos de la nueva red en la base de datos de QVD. Este paso es realizado únicamente una vez, al ser independiente del número de nodos de los que se componga la infraestructura. Antes de ajustar los parámetros se explicará brevemente para qué se usa cada uno de ellos: vm.network.ip.start: Indica la IP de inicio a partir de la cual el servidor DHCP asignará ordenadamente a las máquinas virtuales. vm.network.netmask: Parámetro para conocer la máscara de red de la red de las VM s. vm.network.gateway: Como su propio nombre indica, este parámetro contiene la dirección IP del router de la red. vm.network.dns server: Debe contener la dirección IP del nodo QVD que se desea emplear como servidor DHCP y DNS (Recordar el paso de instalación del paquete dnsmasq). vm.network.bridge: Indica la interfaz virtual de los nodos que se emplea como bridge entre la red de administración y la red de las máquinas virtuales. Conocida la utilidad de los parámetros, se deben establecer (haciendo uso de los scripts de administración) a los valores propios del entorno, que en este caso serán: # qa c o n f i g s e t vm. network. i p. s t a r t = # qa c o n f i g s e t vm. network. netmask=22 # qa c o n f i g s e t vm. network. gateway = # qa c o n f i g s e t vm. network. d n s s e r v e r = # qa c o n f i g s e t vm. network. b r i d g e=qvdnet0 *Nota: Como se realizó la instalación del servidor DHCP y DNS en ambos nodos, es válido el uso de cualquiera de ellos para realizar dicha labor.

145 6. Implantación Operación del sistema Todas las organizaciones gastan un tiempo considerable en la fase de operación y representarán 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 maximizar su rendimiento, capacidad, disponibilidad, confiabilidad y seguridad. Es en esta fase también, dónde 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ía sentido sin antes incluir todas aquellas funcionalidades que van a estar presentes en la infraestructura una vez puesta en producción 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 13, a la que se accederá 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 consistieron en probar los escritorios virtuales realizando tareas características de un usuario común, como la edición de textos (o imágenes) o la navegación por Internet con programas como Libreoffice o Gimp. En la Figuras 6.13 y 6.14 se muestra la pantalla de login que se ofrece a los usuarios 13

146 6. Implantación 121 (desde un cliente de escritorio y desde un cliente Android respectivamente) y en las sucesivas Figuras se muestran las pruebas llevadas a cabo ya comentadas. Figura 6.13: Pantalla de login desde un cliente de escritorio

147 6. Implantación 122 Figura 6.14: Pantalla de login desde un cliente móvil Android Figura 6.15: Prueba de QVD desde un cliente Windows

148 6. Implantación 123 Figura 6.16: Prueba de QVD desde un cliente Android