Los requisitos de una arquitectura de videoconferencia que permita escalar los recursos de forma dinámica a la demanda son los siguientes:
• Control centralizado: es necesaria la existencia de un módulo de control que gestione los recursos disponibles en el sistema para poder asignar las nuevas conexiones a las MCUs pertinentes. Hay que tener en cuenta que en un modelo de MCUs centralizadas una sesión de videoconferencia debe estar siempre gestionada por una misma MCU. Por lo tanto no es factible un modelo en el que el control esté descentralizado.
• Balanceo de carga: en un escenario en el que existen varias MCUs disponibles es crucial la manera en que se programan los recursos en dichas MCUs. Cuando se requiere asignar
3.3. ESCALABILIDAD DINÁMICA A LA DEMANDA
una nueva conexión (un nuevo participante se ha unido a una sesión de videoconferencia), el sistema debe permitir tomar la decisión de en cuál de las MCUs disponibles hacerlo. Esta decisión debe poder tomarse en función del estado de cada MCU o de ciertas características prefijadas.
• Actuador de escalabilidad: en un sistema en el que queremos añadir y quitar recursos en función de las necesidades de cada momento es necesario automatizar dicha tarea. Debe existir un módulo que se encargue de arrancar y parar máquinas virtuales cuando sea necesario y para ello debe realizar llamadas a las APIs correspondientes de los proveedores IaaS.
• Monitorización de recursos disponibles: si escalamos el servicio añadiendo MCUs como unidad básica de recursos, el sistema debe ser consciente del estado de dichas MCUs en cada momento para tener la capacidad de actuar en consecuencia. Esto es necesario tanto para la asignación de recursos a las MCUs disponibles (balanceo de carga) como para la decisión de arranque o parada de nuevas MCUs (actuador de escalabilidad).
• Movilidad de flujos: cuando desciende la demanda de uso y tenemos disponibles más recursos de los necesarios es frecuente la necesidad de parar MCUs y retirarlas del conjunto de recursos disponibles. Sin embargo puede ocurrir que los recursos sobrantes no estén concentrados en las mismas MCUs sino repartidos entre varias de ellas. En ese caso tenemos que reagrupar las conexiones en un subconjunto de MCUs para liberar el resto y poder apagarlas. Esta reagrupación implica mover los flujos multimedia entre MCUs y esta movilidad debe realizarse de forma transparente para los usuarios y sin pérdidas en la transmisión de datos.
Teniendo en cuenta estos requisitos voy a tomar como punto de partida para el diseño de la arquitectura el modelo de videoconferencia como servicio de Marte 3.0, descrito en la Sección 2.1.4. Esta arquitectura es posible gracias a Nuve [Rodríguez 2009], un componente que permite proveer de forma segura salas de videoconferencia a terceros. El detalle de Marte 3.0 puede encontrarse en [Cerviño 2008] y el de su integración con Nuve en la tesis doctoral [Cerviño 2012], desarrollada también en el ámbito de mi grupo de investigación.
Nuve: salas de videoconferencia como servicio
Nuve define un interfaz para integrar un sistema de videoconferencia en otros servicios de tal forma que éstos puedan desentenderse de la gestión de los recursos de videoconferencia. Además provee un sistema de autorización llamadoMAuthque permite securizar el acceso al sistema de videoconfenrecia. Según sus autores, los objetivos que Nuve consigue son los siguientes:
• La gestión de los usuarios y su autorización la lleva a cabo la aplicación de terceros, no el núcleo de videoconferencia.
• Se centra en la gestión de salas de videoconferencia, siendo una sala de videoconferencia un espacio virtual donde los usuarios comparten sus flujos multimedia.
• La interacción entre las aplicaciones y el núcleo de videoconferencia se realiza de manera segura.
• Permite el despliegue del núcleo de videoconferencia de manera escalable en un entorno de computación en la nube. Esto permite asegurar un mínimo de calidad de servicio para las salas de videoconferencia aprovechando las capacidades de los proveedores de Cloud Computing.
Tabla 3.1 : Definición de los recursos en Nuve
Recurso Definición
Service Es una aplicación de terceros que tiene posibilidad de gestionar salas y pedir acceso a las mismas para sus usuarios.
User Representa a un usuario presente en el sistema de conferencia. Este usuario, a través de un servicio, accede a salas de videoconferencia.
Room Representa una sala de conferencia donde los usuarios provenientes de los servicios se conectan para publicar y suscribirse a flujos multimedia.
Token Es la ficha usada para delegar la autorización de los usuarios a los servicios.
En resumen, Nuve propone convertir el núcleo de videoconferencia en unproveedor de salas de comunicación en tiempo real. En la tabla 3.1 podemos ver una relación de los recursos que
3.3. ESCALABILIDAD DINÁMICA A LA DEMANDA
gestiona Nuve. El funcionamiento de un componente que implemente Nuve puede entenderse mejor con un ejemplo de flujo de interacción entre un servicio, un usuario, Nuve y el sistema de videoconferencia, una MCU.
Service Client Nuve MCU 2. Create token 6. Validate token 5. Connect to room (token) 3. Return token 1. Retrieve token 4. Return token 7. Validation result
Figura 3.4 : Flujo de interacción de Nuve
En primer lugar el servicio es registrado en Nuve, con lo que obtiene unas credenciales que le permiten gestionar recursos de videoconferencia de forma autenticada y nominal. A partir de ahora todos los recursos que cree este servicio pertenecerán únicamente a él mismo. El servicio puede entonces crear una sala de videoconferencia en Nuve haciendo uso de sus credenciales. Cuando un usuario o cliente quiere conectarse a dicha sala, comienza el proceso de conexión. En la Figura 3.4 podemos ver el detalle de la interacción entre los componentes durante este proceso: 1. El cliente necesita utilizar untokenpara conectarse a la sala. Por lo tanto le pedirá al servicio
en cuestión que le consiga uno.
2. El servicio pedirá a Nuve un token que autorice al usuario a conectarse a la sala. Para proceder a la creación de estetoken Nuve comprobará que el servicio tiene los permisos adecuados y la capacidad de conectar más usuarios a la sala. Además estetokenserá creado para un usuario en concreto, con determinados roles o permisos sobre la sesión y únicamente autorizado para conectarse a esa sala en concreto.
4. y el servicio al cliente.
5. El cliente que va a conectarse a una sala del sistema de videoconferencia deberá utilizar el
tokendurante el proceso de conexión por lo que lo incluirá en su petición de conexión a la MCU.
6. El sistema de videoconferencia (la MCU) comprobará entonces la validez del token. En primer lugar mediante una firma de seguridad y en segundo lugar preguntando a Nuve si es válido para acceder a la sala solicitada.
7. En caso afirmativo el sistema de videoconferencia dispondrá además de información sobre el usuario para el que eltokenha sido creado. Esta información incluye los roles asignados en su creación mediante los cuales el sistema de videoconferencia podrá determinar qué acciones puede o no puede realizar el usuario sobre la sala (por ejemplo publicar un flujo multimedia).
Como podemos ver, incluir Nuve en mi arquitectura hace que se cumpla una parte del primer requisito expuesto al principio, disponemos de un componente central que gestiona los recursos de videoconferencia. En concreto Nuve tiene constancia de las salas disponibles en el sistema por lo tanto parece que puede ser éste componente el encargado de gestionar la asignación de dichas salas a cada una de las MCUs. Tomaré esta idea como punto de partida para el diseño de la arquitectura.