Desarrollo de interfaces de alto nivel para la interaccion con gestores de maquinas virtuales en infraestructuras tipo cloud

DESARROLLO DE INTERFACES DE ALTO NIVEL PARA LA INTERACCIÓN CON GESTORES DE MÁQUINAS VIRTUALES EN INFRAESTRUCTURAS DE TIPO CLOUD por Amanda Calatrava Arroyo Escuela Técnica Superior de Ingeniería Informática 2010 Director: Dr. D. Germán Moltó Martínez Fecha: Septiembre 2010 _____________________________________________________ 2 3 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA RESUMEN Desarrollo de Interfaces de Alto Nivel para la Interacción con Gestores de Máquinas Virtuales en Infraestructuras de tipo Cloud por Amanda Calatrava Arroyo En este Proyecto Final de Carrera se ha desarrollado una interfaz Java para la interacción con el Gestor de Máquinas Virtuales (GMVs) OpenNebula. Este API ofrece compatibilidad uno a uno con todas las operaciones ofrecidas por el GMVs. Para ello, internamente se realizan llamadas basadas en XML-RPC para la interacción con el servidor. Permite procesar las respuestas basadas en XML de OpenNebula y ofrecer métodos sencillos para acceder a esta información con el objetivo de facilitar la labor del programador. Además, incluye operaciones para el despliegue y gestión de clusters de máquinas virtuales, facilitando aún más la labor del programador que desarrolle aplicaciones que interactúen con el GMVs. Cabe destacar que este API ofrece mecanismos para detectar los problemas que surjan durante las invocaciones remotas. 4 5 AGRADECIMIENTOS Deseo expresar mi más sincero agradecimiento al profesor Germán Moltó, quien ha sido mi tutor durante estos meses, por la oportunidad ofrecida para la realización de este proyecto en el ámbito de investigación, por su colaboración en la preparación del mismo y por adentrarme en un campo de la informática que desconocía y que he podido comprobar lo extraordinario que puede llegar a ser. Además, manifiesto mi agradecimiento a los profesores que he tenido oportunidad de conocer durante la carrera, los cuales me han aportado numerosos conocimientos, y gracias a ellos he logrado alcanzar mis objetivos satisfactoriamente. Gracias también a mis familiares y amigos, y más concretamente a mis padres, por el apoyo recibido a lo largo de mi carrera y en especial en estos últimos meses, pues sin él hubiese sido más complicado alcanzar el nivel, tanto personal como profesional, en el que me encuentro actualmente. i Índice general 1. Introducción ............................................................................................................ 1 1.1. Motivación ......................................................................................................... 1 1.2. Objetivos ............................................................................................................ 3 1.3. Estructura de la memoria ................................................................................ 4 1.4. Conceptos iniciales ........................................................................................... 5 1.4.1. Cloud Computing ..................................................................................... 5 1.4.2. Gestores de máquinas virtuales .............................................................. 8 1.4.3. Hipervisores ............................................................................................... 9 2. Tecnologías Empleadas .................................................................................... 12 2.1. Java .................................................................................................................... 12 2.2. Eclipse Galileo (IDE) .................................................................................... 12 2.3. Subversion ...................................................................................................... 13 2.4. XML-RPC ........................................................................................................ 14 2.5. XPath ................................................................................................................ 15 2.6. Log4j ................................................................................................................. 17 2.7. OpenNebula .................................................................................................... 19 3. Desarrollo del API .............................................................................................. 22 3.1. Aspectos generales del API .......................................................................... 22 3.1.1. Esquema de clases................................................................................... 22 3.1.2. La excepción CloudException ............................................................. 26 3.1.3. La clase CloudOneResult ...................................................................... 24 3.1.4. El método extractResult ........................................................................... 30 3.2. Operaciones destinadas a la gestión de máquinas virtuales .................... 31 3.2.1. Operaciones disponibles en la clase OpenNebulaClient ...................... 32 3.2.2. El objeto de alto nivel VMInfoResult .................................................... 37 3.2.3. La clase ONEVMTemplate ..................................................................... 39 3.3. Operaciones destinadas a la gestión de Hosts ........................................... 41 3.3.1. Operaciones disponibles en la clase OpenNebulaClient ...................... 41 3.3.2. El objeto de alto nivel HostInfoResult ................................................... 43 3.4. Operaciones destinadas a la gestión de redes virtuales ............................ 45 3.4.1. Operaciones disponibles en la clase OpenNebulaClient ..................... 45 3.4.2. El objeto de alto nivel VNInfoResult .................................................... 48 3.5. Operaciones destinadas a la gestión usuarios ............................................ 48 3.5.1. Operaciones disponibles en la clase OpenNebulaClient ..................... 49 3.5.2. El objeto de alto nivel UserInfoResult .................................................... 50 3.6. Operaciones destinadas a la gestión de clusters de MVs ......................... 51 ii 3.6.1. Operaciones disponibles en la clase OpenNebulaClient ..................... 51 3.6.2. La clase OneVMCluster ........................................................................... 54 4. Conclusiones ........................................................................................................ 55 Anexos ......................................................................................................................... 58 A. Descripción de un Caso de Estudio ............................................................ 58 B. Instalación de Subversion en Eclipse Galileo .......................................... 61 C. Ejemplos de resultados XML devueltos por OpenNebula ................. 62 Bibliografía y referencias ...................................................................................... 65 iii LISTA DE TABLAS Número Página 3.1. Métodos destinados a la gestión de MVs ..........................................................32 3.2. Métodos disponibles en la clase VMInfoResult .................................................38 3.3. Atributos de un objeto ONEVMTemplate .........................................................40 3.4. Métodos destinados a la gestión de Hosts ........................................................43 3.5. Métodos disponibles en la clase HostInfoResult .................................................44 3.6. Métodos destinados a la gestión de VNs ..........................................................46 3.7. Métodos disponibles en la clase VNInfoResult ..................................................48 3.8. Métodos destinados a la gestión de usuarios ....................................................49 3.9. Métodos disponibles en la clase UserInfoResult ..................................................51 3.10. Métodos destinados a la gestión de clusters de MVs ....................................52 iv 5 1.4. CONCEPTOS INICIALES En este apartado de la memoria se analizan, sin profundizar en exceso, los conceptos que se han considerado más relevantes para poder situarse de forma correcta en el ámbito del proyecto. 1.4.1. CLOUD COMPUTING El término Cloud Computing (que en castellano significa “Computación en la nube”, donde “nube” es una metáfora del concepto de Internet) hace referencia a un nuevo paradigma informático que surge para ofrecer servicios de cómputo a los usuarios, ya sea de forma gratuita (Clouds públicos) o pagando (Clouds privados). Al ser un servicio, como lo es la electricidad, los usuarios pueden acceder a él sin la necesidad de tener conocimientos sobre la gestión de los recursos que usan y sin tener que preocuparse por el proveedor del servicio para disfrutar de él. Figura 1.2 – Esquema de funcionamiento de una nube 6 Una característica relevante de este tipo de computación es su elasticidad. Los entornos Cloud son escalables, es decir, capaces de ajustarse a la demanda de los usuarios. Ante un pico de elevados requisitos de cómputo, un usuario puede solicitar mayor capacidad de cálculo, que provocará el despliegue automático de nuevas MVs sobre la infraestructura física existente. Esta es una gran ventaja, puesto que uno de los problemas que existían hasta la aparición del Cloud Computing era la creación de una infraestructura propietaria preparada para soportar demandas no previsibles de cómputo, ya que esto suponía una elevada inversión y además no se podía asegurar que fuese capaz de responder correctamente a estos incrementos repentinos en la demanda de los recursos de cómputo. Además, las infraestructuras de tipo Cloud se apoyan en Internet para ofrecer su servicio, aprovechándose de las ventajas que ofrece esta red de redes. Los proveedores pueden ofrecer un gran número de servicios de forma rápida y eficiente, y los usuarios acceder a ellos de forma cómoda y segura. La arquitectura que presenta este paradigma de computación está dividida en tres capas fundamentales, como podemos apreciar en la Figura 1.3. Figura 1.3 – Arquitectura del Cloud Computing La capa superior, que se corresponde con el nombre de SaaS (Software as a Sservice, Software como un Servicio) es la que aloja a las aplicaciones que se ejecutan en la 7 nube y se ofrecen bajo demanda a modo de servicio a los usuarios. Estas aplicaciones son totalmente escalables y evitan a los usuarios tener que instalar y mantener el software, ya que pueden acceder a él a través de Internet. La empresa distribuidora aporta el servicio de mantenimiento y soporte del software solicitado por el cliente y sus beneficios se basan en el concepto de pago por el uso. Un ejemplo de ello pueden ser las variadas aplicaciones que ofrece la empresa Google, como GMail [7] o Google Sites [8], todas ellas reunidas en un conjunto de aplicaciones que recibe el nombre de Google Apps [9]. La capa intermedia, que recibe el nombre de PaaS (Platform as a Service, Plataforma como un Servicio) se encarga de proporcionar la infraestructura y el entorno de ejecución necesario a las aplicaciones de la capa superior como un servicio más. En otras palabras, esta capa permite el desarrollo de aplicaciones Cloud evitándole al usuario tener que preocuparse de la gestión y administración de la infraestructura. Suele estar virtualizada, para poder garantizar la escalabilidad. Un ejemplo práctico puede ser Google App Engine [10]. Por último se encuentra la capa IaaS (Infrastructure as a Service, Infraestructura como un Servicio) que se corresponde con la capa inferior de la arquitectura. En ella se ubican los recursos físicos, tales como servidores, bases de datos, o discos de almacenamiento que se ofrecen como un servicio al usuario. También suelen utilizar técnicas de virtualización para asegurar potencia de cálculo cuando es requerida y conseguir reducir costes gracias a la utilización más eficiente de los recursos. Una muestra de esta capa sería Amazon EC2 [11]. Para finalizar este apartado sobre el término “Cloud Computing” se ha considerado oportuno tratar, de forma resumida, un caso de uso de esta tecnología: los juegos sociales. Actualmente, los juegos sociales se han convertido en una nueva forma de jugar online en Internet. Este tipo de juegos busca crear grandes redes de usuarios que puedan interactuar entre ellos a través de la aplicación. En este sentido es importante 8 señalar que el número de usuarios activo suele ser muy inconstante. En consecuencia, la demanda de las infraestructuras que dan soporte a este tipo de aplicaciones es muy dinámica. Y es aquí donde la computación en la nube cobra protagonismo ya que, como se ha podido analizar anteriormente, ésta es capaz de acoplarse perfectamente a las demandas inconstantes de recursos de cómputo. Contar con infraestructuras propias que den soporte a este tipo de juegos supone un gran coste y puede ser muy arriesgado, puesto que nunca se puede asegurar que se podrá cubrir un pico de demanda de cómputo con éxito. Por todo ello, las infraestructuras de tipo Cloud se están posicionando actualmente como una buena solución para este tipo de aplicaciones y empresas importantes en el sector, como Zynga [12], ya han comenzado a hacer uso de ellas. 1.4.2. GESTORES DE MÁQUINAS VIRTUALES Los gestores de máquinas virtuales (Virtual Infrastructure Managers) son herramientas software que permiten crear y gestionar nubes, ya sean públicas, privadas o híbridas. Desacoplan la MV de la localización física disponible. Crean una capa de virtualización distribuida que se sitúa entre la infraestructura física existente y el servicio que se presta a los usuarios, como se puede apreciar en la Figura 1.4. Esta capa permite extender los beneficios de las plataformas de virtualización a múltiples recursos y permite gestionar de forma independiente los recursos físicos y los servicios. 9 Figura 1.4 – Esquema de localización del GMVs La utilización de un GMVs aporta ventajas tales como la gestión centralizada, el escalado y particionamiento de recursos dinámico y la provisión bajo demanda de MVs. Algunos de los GMVs más conocidos actualmente son OpenNebula (gestor elegido para la realización del proyecto y que se analizará en el siguiente capítulo), Eucalyptus [13] y Abicloud, de la empresa Abiquo [14]. Los tres comparten una característica común: ser de código abierto. 1.4.3. HIPERVISORES Los hipervisores o VMM (Virtual Machine Monitor, Monitor de Máquina Virtual) son herramientas software capaces de comunicarse con el sistema anfitrión, ya sea hardware o un SO (Operative System, sistema operativo), para interoperar entre un sistema de virtualización y el sistema físico. Conforma una pieza fundamental en la 10 tarea de ejecución de MVs. Su objetivo se basa en lograr la abstracción del hardware que requieren los SOs para permitir alojar una o más MVs en un mismo equipo. Esta plataforma de virtualización se encarga de gestionar los cuatro recursos principales de un computador (CPU (Central Processing Unit, Unidad Central de Procesamiento), memoria, red y discos de almacenamiento) repartiendo dinámicamente dichos recursos entre todas las MVs definidas en el computador anfitrión. Figura 1.5 – Arquitectura de trabajo de un Hipervisor Existen dos tipos fundamentales de hipervisores:  Hipervisores de tipo 1 o Bare-Metal : son capaces de ejecutarse directamente sobre el hardware real de la máquina sin necesidad de tener instalado ningún SO. Este tipo de Hipervisores son más eficientes que los de tipo 2, ya que consiguen dar un mayor rendimiento y escalabilidad, además de suponer menos sobrecarga para el computador. La desventaja es que no todo el hardware soporta este tipo de software. Ejemplos de este tipo de hipervisores son Xen [15], KVM [16] o VMware [17] ESXi. 11  Hipervisores de tipo 2 o Hosted: necesitan un SO anfitrión para poder ejecutarse. Permiten la creación de MVs dentro del mismo SO. Al ejecutarse sobre un SO y no directamente sobre el hardware, el rendimiento de este tipo de hipervisores es menor que los de tipo 1. Suelen utilizarse en entornos de escritorio y no en grandes infraestructuras virtualizadas. Algunos de ellos son VirtualBox [18], VMware Player o Virtual PC. Figura 1.6 – Diferentes tipos de Hipervisores 12 2. TECNOLOGÍAS EMPLEADAS En este apartado se analizan, una a una, las herramientas y tecnologías empleadas para la realización del proyecto. 2.1. JAVA Java [19] es un lenguaje de programación orientado a objetos, desarrollado por la empresa Sun Microsystems (recientemente adquirida por otra empresa del sector, Oracle). Es multiplataforma y está desarrollado bajo la licencia GNU GPL (General Public License, Licencia Pública General). Actualmente, este lenguaje de programación es uno de los más utilizados por su versatilidad, ya que Java se utiliza para crear todo tipo de aplicaciones, webs dinámicas, acceso a bases de datos, etc; por ser de código abierto y por ser independiente de la plataforma. Además, permite crear programas modulares y código reutilizable. Para el desarrollo del código que integra el API se ha utilizado la versión 1.6.0_02 del JDK (Java Development Kit, Kit de Desarrollo de Java). 2.2. ECLIPSE GALILEO Eclipse [20] es una plataforma de programación utilizada para crear entornos integrados de desarrollo (IDE, Integrated Development Environment). Este entorno de programación fue desarrollado originalmente por IBM (International Business Machines) como el sucesor de su familia de herramientas para VisualAge. Actualmente 13 es desarrollado por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta el código abierto. Eclipse Galileo [21] es una de las versiones más recientes de este IDE (la más reciente recibe el nombre de Eclipse Helios [22]), y es la que se escogió a la hora de realizar el proyecto puesto que, en el momento del comienzo del proyecto, era la última versión y daba soporte al plug-in para trabajar con el sistema de control de versiones Subversion [23] (SVN), necesario para poder comunicarse con el repositorio donde se alojaba el código fuente del proyecto. 2.3. SUBVERSION Subversion, también conocido como svn, es un controlador de versiones empleado en la administración de archivos utilizados en el desarrollo de software. Es una herramienta multiplataforma que ayuda a que los desarrolladores lleven un seguimiento de los cambios en los ficheros de código fuente de su proyecto. Esta herramienta permite, por ejemplo, obtener y comparar versiones anteriores de código o mantener una estructura de árbol, como se observa en la Figura 2.2, que le permite comportarse como un sistema de ficheros que evoluciona con cada conjunto de cambios. Subversion permite acceder al repositorio a través de la red, por lo que puede ser utilizado desde cualquier lugar. Algunas de las operaciones más comunes que se pueden realizar sobre el repositorio mediante esta herramienta son commit (permite incorporar una nueva versión de archivos modificados localmente al repositorio) y update (utilizado para sincronizar la copia local con la del repositorio). 14 Figura 2.1 – Estructura de árbol de Subversion Durante la realización del proyecto se ha utilizado esta herramienta para contar con una copia del código desarrollado para el API disponible en el repositorio. En el apéndice B se encuentra una guía de instalación de la herramienta Subversion en Eclipse Galileo. 2.4. XML-RPC XML-RPC [24] es un protocolo de llamada a procedimiento remoto que utiliza XML para codificar los datos y HTTP (Hypertext Transfer Protocol, Protocolo de Transferencia de Hipertexto) para transmitirlos a través de Internet. Es un protocolo muy simple pero que permite trabajar con estructuras de datos complejas que pueden transmitirse, procesarse y ser devueltas como respuesta. 21 Figura 2.5 – Ciclo de vida de una MV 22 3. DESARROLLO DEL API Este capítulo conforma el grueso de la memoria, ya que analiza detalladamente el API desarrollado para el proyecto. Está compuesto de 6 subcapítulos en los que se estudian aspectos como las operaciones destinadas a la gestión de MVs o los métodos destinados a gestionar las cuentas de usuario. 3.1. ASPECTOS GENERALES DEL API En este subcapítulo de la memoria se comienza a analizar el API desarrollado en el proyecto. Concretamente se estudian los aspectos comunes o generales de la interfaz, como son la excepción propia creada para el control de los problemas que puedan surgir durante la ejecución de las operaciones del API y la clase que integra la gestión, mediante el uso de XPath, necesaria para procesar correctamente las respuestas de OpenNebula. 3.1.1. ESQUEMA DE CLASES Antes de comenzar a analizar aspectos concretos del API, es necesario conocer la estructura de las clases que lo conforman. El proyecto está compuesto por un paquete, denominado opennebula, que incluye 4 clases:  OpenNebulaClient : es la clase principal del API, que incluye todas las operaciones que éste ofrece. 23  ONEVMTemplate : esta clase permite crear objetos de tipo ONEVMTemplate para construir las plantillas necesarias para crear MVs de forma más cómoda.  OneVMCluster : esta clase es la encargada de dar soporte a las operaciones con clusters de MVs.  CloudException : clase encargada de definir la excepción propia utilizada en el API. opennebula también incluye otros dos paquetes:  result : incluye las clases encargadas de tratar el XML resultante de las invocaciones a OpenNebula y de construir los objetos de alto nivel que facilitan la interacción con el gestor.  test : aquí se encuentran las clases utilizadas para probar el correcto funcionamiento del API. 24 Figura 3.1 – Estructura del paquete opennebula El paquete result está formado por 5 clases encargadas de procesar los XML resultantes de las invocaciones a las operaciones que ofrece OpenNebula:  CloudOneResult : clase que contiene los aspectos comunes en el procesamiento de los resultados en formato XML.  VMInfoResult : define los objetos que se obtienen como resultado de invocar las operaciones de información sobre MVs definidas en la clase OpenNebulaClient.  HostInfoResult : define los objetos que se obtienen como resultado de invocar las operaciones de información sobre hosts (máquinas) definidas en la clase OpenNebulaClient. 25  VNInfoResult : define los objetos que se obtienen como resultado de invocar las operaciones de información sobre redes virtuales definidas en la clase OpenNebulaClient.  UserInfoResult : define los objetos que se obtienen como resultado de invocar las operaciones de información sobre usuarios definidas en la clase OpenNebulaClient. Figura 3.2 – Estructura del paquete result Por último, el paquete test contiene las clases utilizadas para la realización de las pruebas del API. También incluye el caso de uso.  TestOpenNebulaClient : testea el comportamiento de la clase OpenNebulaClient. 26  CasoDeUsoOpenNebulaClient : contiene el caso de uso desarrollado para ver un ejemplo de funcionamiento del API. En el Apéndice A se encuentra expuesto. Figura 3.3 – Estructura del paquete test 3.1.2. LA EXCEPCIÓN CLOUDEXCEPTION Para poder gestionar correctamente los problemas imprevistos que puedan surgir durante la ejecución de las distintas operaciones de que dispone la interfaz de alto nivel que se está construyendo, se ha optado por definir una excepción propia que recibe el nombre de CloudException. 27 Mediante el uso de excepciones en Java se consigue crear aplicaciones capaces de responder y recuperarse, en la medida de lo posible, ante errores inesperados que pueden aparecer en cualquier momento durante la ejecución de las mismas. Las excepciones son objetos de tipo Exception, clase que hereda de Throwable, que a su vez hereda de Object, convirtiéndose en objetos que pueden ser lanzados por los métodos. El esquema de clases se puede observar en la Figura 3.4. La excepción CloudException es definida por el usuario, es decir, no pertenece al estándar de Java pero hereda de la clase Exception, permitiendo contar con una excepción propia creada exclusivamente para el API. Figura 3.4 – Esquema de las excepciones en Java Esta excepción la pueden lanzar todos los métodos de la clase OpenNebulaClient para avisar de que, o bien la invocación remota al servidor del gestor ha fallado por motivos asociados con la programación de entornos distribuidos (caída de servicios, fallos en la red, etc.), o bien el fallo viene provocado por los parámetros con los que se ha hecho la invocación (permisos insuficientes del usuario que la realiza, identificador de una máquina virtual (MV, Virtual Machine) inexistente, etc.). 28 Cualquier aplicación que realice llamadas al API puede capturar esta excepción y analizar el mensaje que contiene para conocer el motivo por el cual fue lanzada. También puede acceder a la excepción que provocó el error, ya que CloudException cuenta con dos constructores, uno de ellos recibe un mensaje y el otro, además del mensaje, la excepción que se recibió al producirse el error. Mediante el encadenamiento de excepciones es posible conocer con detalle el origen de una excepción, así como su camino dentro de la secuencia de invocaciones de métodos. 3.1.3. LA CLASE CLOUDONERESULT CloudOneResult es una clase que pertenece al paquete result, y que contiene los aspectos comunes para el tratamiento de los resultados obtenidos, en formato XML, tras invocar las operaciones que ofrece el GMVs OpenNebula. En esta clase se hace uso del lenguaje XPath para poder alcanzar su objetivo. Para ello se han definido dos atributos, factory y xpath, necesarios para crear un objeto de tipo XPath que permitirá evaluar expresiones XPath sobre el XML. Cabe señalar que para trabajar con objetos de este tipo es imprescindible importar la librería javax.xml.xpath. Otro atributo importante de esta clase es xmlResult, que contiene en forma de String el XML sobre el que hay que realizar la evaluación de las expresiones. La clase está formada por 6 métodos:  El constructor, CloudOneResult : recibe el String devuelto por OpenNebula y lo asigna a la variable destinada a ello. Además inicializa los atributos para trabajar con XPath.  evaluate : este método recibe la expresión a evaluar, en formato String, y devuelve el valor obtenido tras la evaluación, también en formato String. 29 Las expresiones deben tener la forma /”nombre_etiqueta”/”nombre etiqueta”. En la Figura 3.5 se puede observar un ejemplo. Los componentes de alto nivel que devuelve el API se crean a partir de las distintas invocaciones a este método, accediendo a todos los atributos disponibles en el XML. Figura 3.5 – Ejemplo de expresiones válidas para XPath  pool : este método es invocado por las operaciones situadas en la clase OpenNebulaClient que obtienen la información de un grupo de objetos (ya sean MVs, hosts, usuarios o redes virtuales (VNs)). Como resultado de su invocación se obtiene un vector de números enteros que se corresponden con los identificadores de los objetos de tipo elementName (parámetro de entrada de este método). Este vector será imprescindible para poder construir posteriormente un ArrayList con los objetos de alto nivel correspondientes con los identificadores obtenidos.  numberOfAttributes : este método devuelve un número entero con el total de atributos existentes con la misma etiqueta en el XML. Esta 30 etiqueta la recibe como un parámetro en formato String. Es útil para conocer, por ejemplo, el número de máquinas virtuales que hay desplegadas, o el número de usuarios registrados.  getTagValue : el método, al igual que los dos anteriores, se emplea en las operaciones de pool y es capaz de devolver un String con el valor de una etiqueta concreta, que recibe como parámetro de ese mismo tipo.  toSring : el método devuelve un String con el XML original recibido del GMVs. De esta forma siempre se puede acceder al resultado original. 3.1.4. El MÉTODO EXTRACTRESULT En la clase OpenNebulaClient podemos encontrar todas las operaciones que ofrece el API y además un método, extractResult, utilizado por todas estas operaciones para poder procesar correctamente los resultados obtenidos tras las invocaciones al gestor con el que se está trabajando. Analizando el API basado en XML-RPC que ofrece OpenNebula se puede apreciar que todos los resultados obtenidos tras la ejecución de los métodos que ofrece siguen un patrón común. Este resultado siempre está formado por:  Un parámetro de tipo booleano que toma el valor verdadero (true) cuando la operación se ha finalizado con éxito, y toma el valor falso (false) cuando el método no finalice como se espera.  Un parámetro de tipo String, que puede estar vacío o contener un mensaje. Este mensaje puede ser de error o puede contener la información solicitada en operaciones de tipo info. 37 administrador. De lo contrario la ejecución concluirá con el lanzamiento de la excepción CloudException. Al igual que el método anterior, se basa en una llamada a one.vmpool.info, pero con parámetros de entrada diferentes y retorna un ArrayList de objetos VMInfoResult. Cabe señalar que todas las operaciones explicadas anteriormente utilizan la herramienta Log4j para poder avisar del estado del API en cada momento. Además, tras recibir la respuesta de OpenNebula, invocan al método extractResult (analizado en el subcapítulo anterior) para analizar el resultado obtenido. También es importante destacar que la operación vmPoolInfo devuelve un ArrayList de objetos VMInfoResult donde todos los atributos de los objetos toman valor, pero si se analiza detenidamente el XML resultante tras la invocación a one.vmpool.info (en el Apéndice C se puede consultar un ejemplo) se puede observar que este XML no incluye el valor de muchos de los atributos disponibles. Es por ello que la estrategia seguida en este método es conseguir todos los identificadores de las MVs mediante el método pool de la clase CloudOneResult, y para cada una invocar al método getVMInfo que, como se ha mencionado anteriormente, realiza una llamada a one.vm.info cuyo XML resultante sí contiene la información de todos los atributos. 3.2.2. EL OBJETO DE ALTO NIVEL VMINFORESULT Para poder acceder a todos los atributos incluidos en el XML resultante de las invocaciones a los métodos one.vm.info y one.vmpool.info de forma sencilla, se ha considerado oportuno la creación de un objeto de alto nivel que facilite el acceso a estos atributos desde cualquier programa que necesite trabajar con el API. La clase VMInfoResult es la encargada de definir este objeto. También incluye las operaciones de acceso a todos los atributos. Hereda de la clase CloudOneResult, permitiéndole así hacer uso de todos sus métodos. 38 En la Tabla 3.2 se pueden observar los distintos métodos de que dispone la clase, además de su correspondencia con el resultado obtenido en formato XML. Nombre del método Tipo de parámetro de salida Correspondencia con el XML constructor VMInfoResult No procede getID int /VM/ID getUID int /VM/UID getName String /VM/NAME getLastPoll long /VM/LAST_POLL getStateNumber int /VM/STATE getState String /VM/STATE* getLCMStateNumber int /VM/LCM_STATE getLCMState String /VM/LCM_STATE* getStime long /VM/STIME getEtime long /VM/ETIME getDeployID String /VM/DEPLOY_ID getMemory long /VM/MEMORY getCPU long /VM/CPU getNetTX int /VM/NET_TX getNetRX int /VM/NET_RX getFiles String /VM/TEMPLATE/CONTEXT/FILES getContextTarget String /VM/TEMPLATE/CONTEXT/TARGET getTemplateCPU long /VM/TEMPLATE/CPU IsDiskReadonly boolean /VM/TEMPLATE/DISK/READONLY getDiskSource String /VM/TEMPLATE/DISK/SOURCE getDiskTarget String /VM/TEMPLATE/DISK/TARGET getGraphicsListenIP String /VM/TEMPLATE/GRAPHICS/LISTEN getGraphicsType String /VM/TEMPLATE/GRAPHICS/TYPE getTemplateMemory long /VM/TEMPLATE/MEMORY getBridge String /VM/TEMPLATE/NIC/BRIDGE getIP String /VM/TEMPLATE/NIC/IP getMAC String /VM/TEMPLATE/NIC/MAC getNetwork String /VM/TEMPLATE/NIC/NETWORK getVirtualNetworkID int /VM/TEMPLATE/NIC/VNID getOSBoot String /VM/TEMPLATE/OS/BOOT getOSRoot String /VM/TEMPLATE/OS/ROOT getRank String /VM/TEMPLATE/RANK getRequirements String /VM/TEMPLATE/REQUIREMENTS getSEQ long /VM/HISTORY/SEQ getHostName String /VM/HISTORY/HOSTNAME getHID int /VM/HISTORY/HID 39 getPStime long /VM/HISTORY/PSTIME getPEtime long /VM/HISTORY/PETIME getRStime long /VM/HISTORY/RSTIME getREtime long /VM/HISTORY/RETIME getEStime long /VM/HISTORY/ESTIME getEEtime long /VM/HISTORY/EETIME getReason int /VM/HISTORY/REASON *La correspondencia no es directa. Tabla 3.2 – Métodos disponibles en la clase VMInfoResult Todos los anteriores métodos menos, obviamente, el constructor, basan su funcionamiento en la invocación al método evaluate de la clase padre (CloudOneResult) con un String como parámetro de entrada que contiene la expresión XPath a evaluar (expresión que se corresponde con la columna “Correspondencia con el XML” de la Tabla 3.2). Como este método siempre devuelve un String y el principal objetivo de esta clase es facilitar la tarea al programador, cada método está encargado de realizar una conversión de tipo de datos si se considera oportuno. 3.2.3. LA CLASE ONEVMTEMPLATE Como se ha comentado anteriormente, la operación capaz de crear una nueva MV precisa de un parámetro de entrada de tipo String en el que se le indique la plantilla (template) de la máquina. Como se puede observar en la Figura 3.6, el String es bastante tedioso de construir. Por ello se ha considerado oportuno facilitar esta tarea al programador y ofrecerle la oportunidad de poder crear la plantilla de una forma más cómoda mediante la construcción de un objeto de alto nivel. 40 Figura 3.6 – Ejemplo de template válido para la creación de una MV La clase encargada de definir y dar soporte a este nuevo objeto es ONEVMTemplate. Está formada por métodos consultores y modificadores de los atributos que puede contener un template, y el método toString, capaz de transformar la información que contiene el objeto en un String válido para la creación de MVs en OpenNebula. Tras el análisis de distintas plantillas válidas de MVs se ha podido comprobar que existen atributos obligatorios y otros opcionales en la creación del template. Es por ello que la clase dispone de dos constructores válidos para crear el objeto de alto nivel:  El primero recibe como parámetros de entrada los atributos considerados obligatorios. El resto de atributos se inicializan con su valor por defecto para evitar problemas más adelante.  El segundo no precisa de ningún parámetro de entrada, inicializando todos los atributos del objeto con los valores por defecto. En la Tabla 3.3 se pueden observar todos los atributos que conforman el template así como si son de tipo obligatorio u opcional. También se muestra el tipo de dato de cada atributo. Nombre del atributo Tipo de dato Obligatorio/Opcional name String Obligatorio cpu double Obligatorio memory int Obligatorio disk String Obligatorio 41 disk2 String Opcional nick String Obligatorio os String Opcional graphics String Opcional requirements String Opcional context String Opcional rank String Opcional features String Opcional Tabla 3.3 – Atributos de un objeto ONEVMTemplate 3.3. OPERACIONES DESTINADAS A LA GESTIÓN DE HOSTS En este subcapítulo se analizan, de forma análoga al subcapítulo anterior, las operaciones disponibles en el API destinadas a la gestión de los Hosts que dan soporte a las MVs. También se define el componente de alto nivel creado expresamente para este tipo de operaciones, HostInfoResult. 3.3.1. OPERACIONES DISPONIBLES EN LA CLASE OPENNEBULACLIENT La clase OpenNebulaClient ofrece 5 métodos destinados a la gestión de los Hosts. Cada uno de ellos se corresponde directamente con su semejante en el API XML-RPC que OpenNebula ofrece. Todos informan de su estado a través de la herramienta Log4j y analizan los resultados de OpenNebula invocando al método extractResult. A continuación se analiza la funcionalidad de cada uno:  createHost : este método es capaz de crear un Host indicándole su nombre. También necesita recibir como parámetros de entrada el gestor de MVs, el gestor de información, el administrador y una variable booleana que indica si el Host pertenece al dominio administrativo o no. 42 Realiza una llamada remota a la operación one.host.allocate, perteneciente al API XML-RPC de OpenNebula. Con el identificador del nuevo Host recibido tras la invocación, se invoca al método getHostInfo para poder devolver un objeto de alto nivel de tipo HostInfoResult. Si durante la realización de la llamada ocurre algún problema o la respuesta recibida no es la esperada, el método aborta su ejecución y lanza la excepción CloudException.  getHostInfo : mediante la ejecución de esta operación se puede obtener un objeto de alto nivel, de tipo HostInfoResult, que permite acceder a toda la información del Host cuyo identificador se corresponde con el que el método recibe como parámetro. Internamente realiza una llamada al método one.host.info del cual, si todo trascurre correctamente, se recibe la información del Host en formato XML. Si el resultado no es el esperado o la invocación remota sufre algún contratiempo, el método finaliza lanzando una CloudExcepion.  deleteHost : para eliminar un Host de la infraestructura gestionada se debe invocar a este método. Para lograr su objetivo necesita recibir como parámetro de entrada el identificador del Host que se quiere borrar y con él, se invoca a la operación one.host.delete del API XML-RPC. Si surge algún problema durante su ejecución se lanza la excepción CloudException.  enableHost : esta operación permite habilitar o deshabilitar un Host, dependiendo de lo que se le indique en el parámetro booleano que recibe en su invocación. También necesita recibir el identificador del Host al que se desea aplicar la operación. Puede lanzar la excepción CloudException si se produce algún error durante su ejecución.  hostPoolInfo : este método permite obtener la información de todos los Hosts existentes. Devuelve un ArrayList de objetos HostInfoResult para poder acceder de forma sencilla a todos sus atributos. Para ello, en 43 primer lugar se realiza una invocación remota a la operación one.hostpool.info y, mediante el método pool de la clase CloudOneResult, se obtiene un vector con los identificadores de los Hosts. En segundo lugar se invoca al método getHostInfo para obtener los objetos HostInfoResult. Si durante su ejecución surge algún problema, el método aborta su ejecución lanzando la excepción CloudException que contendrá el motivo por el cual el método no ha alcanzado su objetivo. En la Tabla 3.4 aparece el perfil de cada método y la correspondencia con su semejante en el API XML-RPC de OpenNebula. Nombre del método Parámetros de entrada Parámetros de salida Correspondencia directa con las operaciones del API XML-RPC createHost nombre del Host, del gestor de MVs, del gestor de información, del administrador y booleano dominio administrativo Objeto HostInfoResult Sí (one.host.allocate) getHostInfo Id del Host Objeto HostInfoResult Sí (one.host.info) deleteHost Id del Host Vacío (void) Sí (one.host.delete) enableHost Id del Host y booleano habilitar/deshabilitar Vacío (void) Sí (one.host.enable) hostPoolInfo Vacío (void) ArrayList de objetos HostInfoResult Sí (one.hostpool.info) Tabla 3.4 – Métodos destinados a la gestión de Hosts 44 3.3.2. EL OBJETO DE ALTO NIVEL HOSTINFORESULT Los objetos de alto nivel definidos en la clase HostInfoResult permiten acceder de forma sencilla a todos los atributos disponibles en las respuestas, en formato XML, de los métodos one.host.info y one.hostpool.info (disponibles en el API XML-RPC que ofrece OpenNebula). Por ejemplo, se puede acceder al número de MVs que alberga realizando una llamada al método getNumberOfVMs sobre un objeto de tipo HostInfoResult; sin la necesidad de procesar el XML que puede resultar tedioso. La clase hereda de CloudOneResult, permitiéndole basar todos sus métodos consultores de los atributos en la llamada al método evaluate (disponible en la clase padre). En la Tabla 3.5 se pueden observar todos los métodos que se ofrecen para este tipo de componente, su salida y su correspondencia con el resultado recibido en formato XML. Nombre del método Tipo de parámetro de salida Correspondencia con el XML constructor HostInfoResult No procede getID int /HOST/ID getName String /HOST/NAME getState String /HOST/STATE* getStateNumber int /HOST/STATE getIM_MAD String /HOST/IM_MAD getVM_MAD String /HOST/VM_MAD getTM_MAD String /HOST/TM_MAD getLastMonTime long /HOST/LAST_MON_TIME getHID int /HOST/HOST_SHARE/HID getDiskUsage long /HOST/HOST_SHARE/DISK_USAGE getMemoryUsage long /HOST/HOST_SHARE/MEM_USAGE getCPUUsage long /HOST/HOST_SHARE/CPU_USAGE getMaxDisk long /HOST/HOST_SHARE/MAX_DISK getMaxMemory long /HOST/HOST_SHARE/MAX_MEM getMaxCPU long /HOST/HOST_SHARE/MAX_CPU getFreeDisk long /HOST/HOST_SHARE/FREE_DISK getFreeMemory long /HOST/HOST_SHARE/FREE_MEM getFreeCPU long /HOST/HOST_SHARE/FREE_CPU 45 getUsedDisk long /HOST/HOST_SHARE/USED_DISK getUsedMemory long /HOST/HOST_SHARE/USED_MEM getUsedCPU long /HOST/HOST_SHARE/USED_CPU getNumberOfVMs int /HOST/HOST_SHARE/RUNNING_VMS getArchitecture String /HOST/TEMPLATE/ARCH getCPUSpeed long /HOST/TEMPLATE/CPUSPEED getHypervisor String /HOST/TEMPLATE/HYPERVISOR getModelName String /HOST/TEMPLATE/MODELNAME getTotalCPU long /HOST/TEMPLATE/TOTALCPU getTotalMemory long /HOST/TEMPLATE/TOTALMEMORY getNetRX int /HOST/TEMPLATE/NETRX getNetTX int /HOST/TEMPLATE/NETTX *La correspondencia no es directa. Tabla 3.5 – Métodos disponibles en la clase HostInfoResult 3.4. OPERACIONES DESTINADAS A LA GESTIÓN DE REDES VIRTUALES Este subcapítulo trata sobre las operaciones disponibles en el API destinadas a la gestión de VNs. De manera análoga a los dos subcapítulos anteriores, también se profundiza en la funcionalidad y las operaciones que ofrece la clase VNInfoResult, capaz de crear los objetos de alto nivel que contienen los atributos de las redes virtuales. 3.4.1. OPERACIONES DISPONIBLES EN LA CLASE OPENNEBULACLIENT Como ya se ha mencionado en otros capítulos, la clase OpenNebulaClient incluye todas las operaciones que ofrece el API. Entre ellas se encuentran las que están destinadas a la gestión de VNs, que se analizan en este apartado. En concreto, el API dispone de 4 operaciones destinadas a la gestión de VNs. Cada una de ellas está directamente relacionada con su equivalente en el API XML- 46 RPC que ofrece OpenNebula, como puede observarse en la columna “Correspondencia directa con las operaciones del API XML-RPC” de la Tabla 3.6. Nombre del método Parámetros de entrada Parámetros de salida Correspondencia directa con las operaciones del API XML-RPC createVN plantilla de la nueva VN Objeto VNInfoResult Sí (one.vn.allocate) getVNInfo Id de la VN Objeto VNInfoResult Sí (one.vn.info) deleteVN Id de la VN Vacío (void) Sí (one.vn.delete) vnPoolInfo Vacío (void) ArrayList de objetosVNInfoResult Sí (one.vnpool.info) Tabla 3.6 – Métodos destinados a la gestión de VNs Seguidamente se analizan una a una las operaciones sobre VNs disponibles en el API. Cabe señalar que, al igual que el resto de operaciones que ofrece el API, utilizan Log4j para indicar su estado y, tras la invocación remota a la operación correspondiente del API XML-RPC, se realiza una llamada al método extractResult para analizar el resultado obtenido. Las operaciones disponibles son:  createVN : este método permite crear una nueva red virtual, pasándole como parámetro de entrada la plantilla de ésta. Realiza una invocación remota al método one.vn.allocate del API XML-RPC de OpenNebula. Puede ocurrir algún error durante su invocación, por ejemplo de conexión, o puede que la respuesta del método no sea la esperada; en estos casos, createVN es capaz de detectar el problema y finalizar su ejecución lanzando una CloudException informando del error.  getVNInfo : para obtener la información de una red virtual, se puede invocar a este método con el identificador de la VN de la que se desea información. El método se encarga de realizar una invocación remota a su semejante (one.vn.info) en el API XML-RPC con el identificador de la 53 necesario para llevar a cabo la operación, recibir una plantilla válida con la que serán creadas todas las MVs. Internamente se realizan tantas llamadas a la operación submitVM como MVs se deseen crear. El método devuelve un objeto de alto nivel OneVMCluster, al que se le pueden consultar el número de MVs que forman el cluster y los identificadores de todas ellas. Si durante su ejecución ocurre algún problema, se aborta la ejecución del método y se lanza la excepción CloudException.  decrementCluster : este método se encarga de decrementar la cantidad de MVs existente en el cluster. Requiere recibir como parámetros el objeto de alto nivel que contiene el cluster que se desea disminuir y el número de MVs a decrementar. Como todas las MVs son iguales, es decir, tienen todas el mismo template, no importa las que sean eliminadas, luego mediante la llamada al método finalizeVM se eliminan las MVs y se actualizan los valores del objeto OneVMCluster,que es devuelto por decrementCluster. La excepción CloudException puede ser lanzada si ocurre algún error durante su ejecución.  incrementCluster : para incrementar el número de MVs que forman el cluster, es necesario recibir como parámetros de entrada el objeto de alto nivel OneVMCluster, el número de MVs a incrementar y la plantilla de éstas. Mediante la invocación al método submitVM tantas veces como el número de MVs a incrementar indique, se crean las nuevas MVs. Seguidamente se actualizan los valores de los dos atributos del objeto OneVMCluster. Este objeto se devuelve como parámetro de salida. Si surge algún inconveniente durante su ejecución, se lanza una nueva CloudException con el motivo del error.  resto de operaciones: para realizar cualquier tipo de acción de las que se disponía en la gestión de MVs (reiniciar, parar, finalizar…) sobre un cluster, hay disponibles en el API 9 operaciones destinadas a ello. El 54 funcionamiento de todas ellas es común: realizan tantas llamadas a sus métodos afines disponibles para gestionar una sola MV como máquinas tenga el cluster. Por ejemplo, el método restartCluster invocará a restartVM varias veces, cada una de ellas con el identificador de una de las MVs que forman el cluster. Los identificadores se obtienen del atributo del objeto OneVMCluster encargado de contenerlos en forma de vector y que se recibe como parámetro en cada método. Todas las operaciones pueden lanzar una CloudException si ocurre algún problema durante su ejecución. 3.6.2. LA CLASE ONEVMCLUSTER La clase encargada de definir el objeto que permite gestionar un grupo de MVs a la vez recibe el nombre de OneVMCluster. Cuenta con dos atributos, el número de MVs que forman el cluster y un ArrayList con los identificadores de todas las MVs. Cuenta con dos métodos consultores y otros dos modificadores, uno por cada atributo con el que cuenta la clase. Éstos son utilizados por los métodos que ofrece el API para la gestión de clusters de MVs para alcanzar sus objetivos. Tambien contiene un método que devuelve la información del cluster: cuántas máquinas lo forman y cuáles son sus identificadores. El método recibe el nombre de toString. 55 4. CONCLUSIONES Para cerrar este documento, en este último capítulo se exponen las conclusiones que la autora extrae tras la realización del PFC. Los objetivos planteados al comienzo se han podido llevar a cabo de forma satisfactoria. Se ha construido un API en Java que facilita la tarea a los programadores encargados de realizar aplicaciones que requieran la intervención con el GMVs OpenNebula. Y, lo más importante, de forma sencilla. Mediante la creación de los objetos de alto nivel se consigue acceder de forma simple a todos los atributos de éstos, cosa imposible de llevar a cabo en el API en Java que OpenNebula ofrece a día de hoy. Además, tras analizar el uso que se le iba a dar al API en el ámbito científico, se optó por dotarlo de operaciones que soportaran la gestión de clusters de MVs ya que, en este ámbito, suele ser más usual lanzar varias máquinas virtuales con la misma plantilla para que desarrollen entre todas un objetivo común, que trabajar con MVs de forma aislada. Con ello se cumple otro de los objetivos planteados inicialmente. Pero para llegar al punto donde actualmente se encuentra el PFC, primeramente ha sido necesario un período de documentación sobre el paradigma de la computación en Cloud, concepto absolutamente desconocido en un principio y que a día de hoy resulta totalmente familiar. Se han dedicado semanas de investigación desechando mucha información contradictoria sobre este paradigma, ya que muchos son los que opinan sobre el tema pero pocos los que lo hacen con rigurosidad. También ha supuesto un pequeño esfuerzo el hecho de trabajar con un entorno de programación sobre el que no se había trabajado hasta el momento. Pero la experiencia sobre este tipo de IDE ha resultado satisfactoria, tanto que, en futuros 56 trabajos, se opte por la elección de este tipo de entornos más sofisticados para trabajar y no sobre otros más simples con los que se había trabajado hasta ahora. El hecho de usar la herramienta Subversión y de disponer de un repositorio donde almacenar el trabajo realizado, además de Internet, también ha facilitado la realización del trabajo desde casa, una ventaja analizando el contexto temporal sobre el que se ha llevado a cabo la realización del proyecto. Otro aspecto, en este caso puramente de desarrollo, ha sido la necesidad de analizar y hacer un correcto uso de un par de herramientas que se han empleado en el API y que se desconocían hasta ahora: Log4j y XPath, pero su uso no ha supuesto ningún problema remarcable. Desde el punto de vista personal de la autora, el proyecto se planteó como un desafío personal, ya que no quería realizar un trabajo cualquiera, sino que deseaba aprovechar esta oportunidad para colaborar en un proyecto más relevante en el ámbito de la investigación. Por ello se optó por la realización del trabajo que en este documento se expone, colaborando en el proyecto PAID-06-09-2810. Es reconfortante saber que los resultados obtenidos van a servir para un proyecto de mayor repercusión y que no se va a quedar simplemente almacenado. Además, los conocimientos aprendidos y la experiencia ganada durante el desarrollo del proyecto, han servido para tomar la decisión de continuar la formación académica por la rama de la Computación de Altas Prestaciones. 57 58 APÉNDICE A DESCRIPCIÓN DE UN CASO DE ESTUDIO En este apéndice de la memoria se muestra un caso de estudio realizado para observar el funcionamiento del API desarrollado. Seguidamente se muestra el código desarrollado para este caso de estudio: package org.grycap.cloud.opennebula.test; import org.apache.log4j.Logger; import org.apache.log4j.PropertyConfigurator; import org.grycap.cloud.opennebula.ONEVMTemplate; import org.grycap.cloud.opennebula.OneVMCluster; import org.grycap.cloud.opennebula.OpenNebulaClient; public class CasoDeUsoOpenNebulaClient { public static void main(String[] args) { PropertyConfigurator.configure("log4j.properties"); Logger log = Logger.getLogger(CasoDeUsoOpenNebulaClient.class); ONEVMTemplate template = new ONEVMTemplate(); template.setName("opaljeos"); template.setCPU(1); template.setMemory(512); template.setOS("[ boot = \"hd\", root = \"sda\" ]"); template.setDisk("[ source = \"/srv/cloud/images/jeos/kvm_jeos_opal" + "/disk0.qcow2\", " + "target = \"hda\", readonly =\"no\" ]"); template.setNic("[ NETWORK = \"Publica\"]"); template.setGraphics("[ type = \"vnc\", listen = \"127.0.0.1\" ]"); template.setRequirements("\"CPUSPEED > 1000\""); template.setContext("[ files = \"/srv/cloud/images/cntxtlzr/init.sh" + "/srv/cloud/images/cntxtlzr/cntxtlzr.tgz\", target = \"hdb\" ]"); 59 En este ejemplo de uso del API se ha creado un objeto ONEVMTemplate para la posterior creación de MVs. Se han modificado varios de sus atributos hasta crear la plantilla deseada. Seguidamente se ha construido un objeto OpenNebulaClient sobre el que se pueden invocar todas las operaciones que ofrece el API. Se ha optado por mostrar un ejemplo de las operaciones destinadas a la gestión de clusters por ser las más sofisticadas, ya que internamente también hacen uso de otras operaciones ofrecidas. Como se puede observar en el código, se crea un cluster con 2 MVs. Seguidamente se amplía a una más para luego decrementarla. Finalmente se apagan todas las MVs que forman el cluster. Para observar el estado del cluster tras cada operación, se invoca al método toString sobre el objeto OneVMCluster. A continuación se puede observar la salida producida por este pequeño programa: try{ OpenNebulaClient onc = new OpenNebulaClient("http://dellblade01.itaca.upv.es" + ":2633/RPC2","amcaar:318ccc3fef86513000492de450870fd433af76bd" ); OneVMCluster cluster = onc.createCluster(2, template.toString()); log.info(cluster.toString()); onc.incrementCluster(cluster, 1, template.toString()); log.info(cluster.toString()); onc.decrementCluster(cluster, 1); log.info(cluster.toString()); onc.finalizeCluster(cluster); log.info(cluster.toString()); onc.vmPoolInfo(); }catch(Exception ex){ log.fatal("An exception occurred: " + ex.getMessage()); } } } 60 Figura A – Salida obtenida tras la ejecución del caso de estudio 61 APÉNDICE B INSTALACIÓN DE SUBVERSION EN ECLIPSE GALILEO En este apartado se exponen los pasos a seguir para poder instalar Subversion en Eclipse Galileo: 1. Ir a Help/Install New Software... 2. Agregar 1. Galileo -> http://download.eclipse.org/releases/galileo 2. Subversive SVN Connectors -> http://community.polarion.com/projects/subversive/down load/eclipse/2.0/galileo-site/ 3. de Galileo agregar 1. Colaboration/Subversive SVN Team Provider (Incubation) 0.7.8.I20090506-1500 4. Instalar y reiniciar el IDE. 5. Repetir el proceso agregando de Subversive SVN Connectors: 1. Subversive SVN Connectors/Subversive SVN Connectors 2.2.0.I20090505-1500 2. Subversive SVN Connectors/Native JavaHL 1.5 Implementation (Optional) 2.2.0.I20090505-1500 3. Subversive SVN Connectors/ SVNKit 1.2.2 Implementation (Optional) 2.2.0.I20090505-1500 6. Reiniciar el IDE. 62 APÉNDICE C EJEMPLOS DE RESULTADOS XML DEVUELTOS POR OPENNEBULA En este apéndice se encuentran los ejemplos de los resultados obtenidos tras la invocación las operaciones información de MVs del API XML-RPC de OpenNebula en formato XML. Resultado obtenido tras la invocación al método one.vm.info: