CAPÍTULO 6 PROPUESTA PARA DESPLEGAR ESCENARIOS VIRTUALES DE RED EN
6.5 DISCUSIÓN
EDIV proporciona una solución al problema de la gestión de escenarios virtuales distribuidos (desplegados en un conjunto de servidores interconectados localmente) en los que luego puedan realizarse pruebas y experimentos, de forma integrada y transparente para el usuario. Sin embargo,
en el contexto de PASITO, donde los servidores de despliegue no se encuentran interconectados localmente sino a través de un troncal de red de RedIRIS, serían necesarias adaptaciones. En concreto, pasar de utilizar redes 802.1q al uso de túneles IP para la interconexión de MVs en distintos servidores. Otra de las limitaciones de EDIV (heredada de VNUML) es que la fuerte orientación a escenarios restringe las posibilidades de realizar operaciones de gestión sobre MVs individualmente (ej., añadir una nueva máquina virtual a una de las redes del escenario sin tener que re-desplegarlo entero). Finalmente, la interfaz controlador-servidor está basada en comandos, lo que, si bien es una aproximación directa y sencilla, implica poco formalismo desde el punto de vista de la gestión.
En el modelo de servicios Web sin estado, la interacción de los procesos sigue un patrón de petición–respuesta. Funciona bien para desplegar los escenarios virtuales desde el proceso cliente a varios servidores. Su fortaleza reside en la definición de su interfaz WSDL, que permite que cualquier cliente Web pueda invocarlo sin tener que conocer nada acerca de los detalles de la implementación del servicio, o sobre que plataforma está funcionando. Sin embargo, tiene la restricción de que en cada invocación no se mantiene el estado o las propiedades de los recursos, con lo cual se dificulta el control, planificación y dimensionado de los recursos. Otro problema no resuelto es el tema de seguridad de acceso a los recursos.
En el modelo de servicio Web basado en Grid, se han agregado las especificaciones WSRF a la definición WSDL, con lo cual se puede interactuar con los WS-Resources con las mismas ventajas de interoperabilidad de un servicio Web definido en WSDL. Otra ventaja es permitir que todos los recursos puedan comunicarse con independencia de su localización. Este modelo utiliza la Factoría de Servicios del Grid, de forma que en lugar de tener un único servicio compartido por todos los clientes se tiene una Factoría que crea instancias de WS-Resource individuales. Cuando el cliente invoca a una operación se accede a la Instancia de Servicios y no a la Factoría, con lo cual se puede crear un WS-Resource por cliente, o varios por cliente o uno para varios clientes, lo cual es una gran ventaja comparado con los dos modelos anteriores. Resuelve además cuestiones de planificación de recursos y seguridad de acceso. Por contra, existe mayor complejidad en su diseño, es muy laborioso en su implementación y requiere un mayor número de componentes de hardware y software. La Tabla 6-1 resume el cumplimiento de los requisitos establecidos en el apartado 6.3:
Tabla 6-1. Cumplimiento de los requisitos
Requisito EDIV Web Service Grid+WSRF
1 SI SI SI
2 NO NO SI
6.6
Trabajos relacionados
Es necesario mencionar la existencia de otras herramientas de gestión de infraestructura virtualizada además de VNUML. Herramientas como VirtualCenter [VMwareVC] o Enomalism
[Enomalism] son bastante avanzadas en muchos aspectos (consolidación, balanceo de carga en los hosts, etc.) pero carecen de flexibilidad para la creación de topologías arbitrarias. Más parecidas a VNUML son NetKit [Pizzonia08] y MLN [Begnum06], también orientadas a gestión de escenarios, pero sin considerar despliegues multi-hosts como en el caso de EDIV.
En cuanto a la integración de Grid y virtualización, VIOLIN [Ruth05] es un prototipo sobre PlanetLab para ejecutar aplicaciones distribuidas. IN-VIGO [Matsunaga05] es un middleware para recuperación automática de fallos. En [Zhao06] se describe un middleware para gestión de servicios de VMs. Estos trabajos son diferentes al descrito en el presente capitulo, al no incorporar las especificaciones WSRF.
A continuación se mencionan los enfoques que consideran la aplicación de WSRF. En
[Keahey05] se introducen los conceptos de espacio de trabajo virtual (virtual workspace) para desplegar automáticamente VMs en la arquitectura Grid, usando Xen y VMware Workstation. Una extensión de este trabajo se describe en [Kecskemeti08], donde se define una solución de despliegue de servicio automático de dispositivos (appliances) virtuales para servicios Grid. Nuestra investigación se diferencia de estas propuestas, ya que distribuye los escenarios virtuales utilizando VNUML, que utiliza un lenguaje de especificación de alto nivel. Por otra parte, ellos no determinan en tiempo real si la distribución y despliegue del escenario virtual será en el mismo servidor o en diferentes servidores.
Respecto a trabajos con enfoques similares, en [Zhao05] y [Zhao06] se analiza la creación y gestión de sesiones de sistemas de archivos con VMs VMware basadas en sistemas Grid y WSRF. Nuestra investigación se diferencia de estos esfuerzos, pues distribuimos escenarios virtuales con instanciación de VMs mediante un lenguaje de descripción de escenarios, manipulando el estado de los recursos vía WSRF.
En cuanto a la distribución de tareas, en [Rubio07] se presenta el despliegue de VMs en un Grid GT4. Su aplicación consiste en el encapsulado del espacio virtual (virtual workspace) en una tarea (job) Grid, incorporando GridWay, que gestiona la interacción con los Servicios GRAM y GridFtp e interactúa con VMs implementadas con Xen [Barham03]. En este trabajo no se han utilizado los beneficios de las especificaciones WSRF pero su concepción ha sido útil en nuestra investigación. En [Turjanski05] se configura un laboratorio Grid basado en VMs utilizando GT4 y una implementación WSRF. No modelan el ciclo de vida del “EVR”. Finalmente, en [Libvirt] se describe la creación de entornos de ejecución desplegados dinámicamente utilizando VMs con WSRF. Lo que en esencia hace es arrancar VMs para que en ellas se ejecute un job del Grid. En
nuestro caso, la tarea (job) a entregar al Grid es el despliegue de un escenario virtual.
Todos estos enfoques plantean soluciones parciales al problema de distribuir escenarios virtuales previamente configurados. No le asignan al Grid la tarea de desplegar escenarios virtuales y no han modelado el ciclo de vida de un escenario virtual con WSRF.
6.7
Conclusiones
En este trabajo se han presentado soluciones para distribuir escenarios virtuales, como entornos de experimentación para la plataforma PASITO. Partiendo de EDIV se han ampliado sus soluciones recubriendo VNUML con un conjunto de capas para proporcionar un servicio estándar, seguro e inter-operable de virtualización distribuida, incorporando un nivel de abstracción de tecnologías de virtualización entre el Grid y WSRF. Como apoyo conceptual, se ha adoptado RM- ODP como modelo de referencia para establecer transparencia de localización, acceso y prestaciones. Se ha modelado el procedimiento y la infraestructura para el despliegue y distribución de escenarios virtuales de red mediante servicios Web y después mediante servicios Grid, utilizando VNUML como lenguaje de especificación de dichos escenarios. La discusión realizada ha descrito las ventajas y desventajas de cada solución propuesta, que han sido orientadas para mejorar el control, uso eficiente de los recursos y la seguridad de acceso de redes virtuales ejecutadas en entornos distribuidos.
Tal como se muestra en este capítulo, cada una de estas propuestas no resuelve los principales problemas definidos en el apartado 6.2. Sin embargo al intentar definir una de las propuestas, se ha establecido como una arquitectura base el diseño lógico y físico de un nodo de PASITO similar al que se ilustró en la Fig. 6-4, del apartado 6.4.2, a fin de desplegar un EVR independientemente de la plataforma de virtualización subyacente. Estas propuestas han sido publicadas en [Fuertes08b] y
[Galán09].
El siguiente capítulo parte de esta infraestructura base y ha sido enfocado en caracterizar un EVR mediante un modelo que permita normalizar su despliegue automático, independiente de la plataforma de virualizacion a fin de resolver el problema de la interoperabilidad y del despliegue automático.