Modelo de Mobile Cloud Computing para la deslocalización de la prestación de Servicios Educativos

Transcripción

1 Mesa de investigadores IDIC Presentación de Informes Finales de Proyectos , 11 y 25 de abril de 2014 Modelo de Mobile Cloud Computing para la deslocalización de la prestación de Servicios Educativos Ing. Carlos Torres Paredes Ing. George Romero Velazco

2 Situación Problemática - A fin de lograr un proceso educativo integral las instituciones educativas de nivel superior complementan las sesiones formativas conceptuales con actividades prácticas tales como experiencias de laboratorio y talleres, para lo cual implementan laboratorios equipados con tecnologías y aditamentos cada vez mas especializados y costosos. - Estos ambientes de laboratorio tienen una capacidad finita en cuanto a la cantidad de alumnos que pueden recibir en una sesión presencial y se sabe que en cada sesión se hace énfasis en el uso de ciertos recursos ligados al avance curricular del curso. El resto de recursos, usualmente la mayor parte, no es empleado. - Sería deseable contar con un procedimiento que permita que alumnos ubicados fuera del laboratorio accedan a los recursos del laboratorio disponibles (sin uso en la sesión presencial de clase) y pudieran aprovecharlos para realizar sus propias actividades prácticas.

3 Objetivo principal Proponer un modelo de Mobile Cloud Computing (MCC) que permita la realización de actividades de laboratorio, fuera del ambiente físico, a través del empleo de dispositivos móviles (DM) Objetivos específicos Identificar las limitaciones de los Dispositivos Móviles para soportar aplicaciones demandantes en capacidad de cómputo y almacenamiento Revisar los modelos de aplicación de Cloud Computing (CC) a DM y adaptar el más adecuado para la prestación de servicios educativos Realizar una prueba de concepto del modelo propuesto de MCC bajo la forma de la realización de una sesión modelo de laboratorio

4 Metodología 1. Revisión del estado del arte (CC-->DM, MCC, ML) 2. Evaluación de limitaciones de los DM 3. Evaluación comparativa de modelos de App-->DM, CC-->DM 4. Selección de actividades de laboratorio «referenciales» 5. Implementación de la plataforma Modelo_de_MCC 6. Prueba de concepto del Modelo_de_MCC 7. Análisis de resultados y comportamientos observados 8. Documentación

5 Resultados Características Limitantes de los DM Baja-moderada capacidad de procesamiento (tendencia a 4 y 8 núcleos en gama alta) Baja capacidad de memoria (tendencia a 1 ó 2 GB de RAM en gama alta) Baja-moderada autonomía de operación (dependiente del patrón de uso y en menor medida de la batería, rangos de 4 a 8 horas de uso activo) Baja-moderada conectividad a través del servicio de datos (2G--> 1Mbps, 3G--> 42.2 Mbps, 4G--> 100 Mbps). La alternativa es emplear el servicio WiFi (g-->54 Mbps, n--> 600 Mbps, ac--> 1000 Mbps +) Pantalla de tamaño pequeño-medio (Smartphones Tabletas. Área visual aceptable en las tabletas de 7, 8 y 10.1 pulgadas)

6 Resultados Modelos de desarrollo de Aplicaciones (App) para DM Modelo «Nativo», orientada a un segmento de DM basados en un Sistema Operativo (SO) particular (Android, IOS, Windows Phone) Limitado al segmento de DM que soporta el SO (-) Aprovecha al máximo las funcionalidades del DM (+) Modelo «Web», desarrollo a nivel de lenguajes web Se codifica en lenguaje soportado por los navegadores (multi-plataforma) (+) Posibilidad de ejecutar código parcial en el dispositivo Posibilidad de recibir «vistas» en el navegador del dispositivo No tiene acceso a las funcionalidades avanzadas del DM (-) Modelo «Híbrido», componentes de desarrollo «Nativo» y «Web» «Web», facilita el desarrollo (lado Servidor) y el consumo (DM) (+) «Nativo», App ligera que permite acceso a las funcionalidades del DM (+)

7 Resultados Modelos de Despliegue App-->DM Local, descarga un App, lo instala y lo ejecuta en el DM Dependiente de las capacidades del DM (-) Alto impacto en la autonomía energética y velocidad de ejecución (-) Remoto, Servidores dedicados, el DM consume las vistas generadas a través del uso de un navegador web estándar Servidor Dedicado Recurso limitados, permanentemente asignados, no escalable (-) Nube Pública Latencia de acceso, añade complejidad (Nube -> Lab) (-) Nube Privada Implementada «In-house», consume recursos bajo demanda, baja latencia (+) Se recomienda que sea un «Cloudlet» (+)

8 Resultados Modelos de Acceso remoto DM--> Lab Terminal de red (Telnet) Inseguro, aún en entornos locales Túneles (SSH, VPN) Requiere cabeceras terminales de conexión pre-existentes, no escalable Escritorio remoto (RDP, VNC, etc.) Requiere cabeceras terminales de conexión pre-existentes, no escalable Escritorio virtual (VDI) La MV instanciada «evoluciona» según la interacción, no deseable Escritorio «estandarizado» bajo demanda Aprovisionamiento bajo modelo Nube (CC) de MV estándares que contengan lo necesario para la realización de un Taller/Lab Optimiza el uso concurrente de recursos (bajo demanda, automático)

9 Resultados Validación Prueba de concepto Infraestructura particular (facilidad de acceso) Servidores tipo Quad Core (Q9650, 8 GB RAM), i7 (720QM, 32 GB RAM) Tabletas Android (Gama media: Toshiba Thrive, Gama alta: Asus T701) Celulares SmartPhone (Gama baja: LG P500h, Gama alta: Samsung S4) Suite de Cloud Computing VMware Cloud Suite 5.1 (vcloud Director, vshield, Vsphere (ESXi, vcenter)) Prueba de campo Infraestructura del Laboratorio de Data Center, S-170 Servidores tipo IBM Blade HS-22 (Xeon E-5607, 64 GB RAM) Tabletas Android (Gama alta: Samsung) Celulares SmartPhone (Gama media-alta: Samsung S3) Suite de Cloud Computing VMware Cloud Suite 4.1 (vcloud Director, vshield, Vsphere (ESXi, vcenter))

10 Resultados Esquema simplificado de pruebas

11 Conclusiones (I) Los DM poseen capacidades limitadas en cuanto a procesamiento, conectividad, almacenamiento y autonomía se refiere. Al ser sometidas a uso intensivo, aún en periodos cortos, las capacidades de los DM se agotan notablemente y de forma rápida. El modelo de desarrollo de aplicaciones móviles recomendable para los fines del proyecto es el tipo web, ya que no impone a los docentes el aprendizaje y dominio de lenguajes «nativos» a los DM y posibilita que un contenido sea consumido en varias plataformas.

12 Conclusiones (II) Para los fines del proyecto no es crítico el acceso a las funcionalidades especiales de cada DM ya que lo que se busca es que el alumno acceda a las funcionalidades del laboratorio. Los recursos disponibles en el laboratorio son finitos, por lo que su consumo debe darse con un modelo optimizado de aprovisionamiento bajo demanda (Modelo CC). Es posible aprovisionar escritorios estandarizados (imágenes, MVs) que contengan solo lo necesario para llevar a cabo un determinado taller (Optimizar el uso de los recursos) o que empaqueten las herramientas necesarias en un curso (Optimizar la experiencia y aprendizaje).

13 Conclusiones (III) Bajo el modelo propuesto, es posible preparar «entornos virtualizados» de laboratorio sin tener que llevar a cabo modificaciones mayores a los «entornos físicos» con los que se trabaja actualmente. La entrega de estos «entornos virtualizados» de laboratorio constituyen un servicio, (Laboratory as a Service, LaaS), que se podría brindar a cualquier asignatura que emplee recursos de cómputo en sus actividades.