Nuba plataforma de_cloud_federada_para_servicios_de_infraestructura
1. NUBA: Plataforma de Cloud Federada para Servicios de Infraestructura Telefónica I+D
2.
3.
4.
5. Objetivos científicos y tecnológicos del proyecto Arquitectura de Referencia Gestión de “Cloud” local Entornos virtuales completos infraestructuras heterogéneas Gestión escalable a gran escala Política avanzada Gestión de federaciones de Clouds Agregador de Cloud Interconexión Clouds Heterogéneos Representación Abstracta Rentabilidad Recursos Auto-gestión del servicio sobre Cloud Federada Despliegue y Gestión Enfoque de Negocio Gestión Ciclo de Vida Autoconfiguración despliegue Gestión de parámetros de Negocio Gestión Optimización en Tiempo Real Reglas de Negocio Monitorización Supervisión Niveles de Servicio
6.
7.
8. Arquitectura General Proveedor Cloud Portal de Usuario Agregador Cloud Sistema de monitorización (prov) Gestión de Servicio Gestión de Negocio Gestión de Negocio Gestión de Cloud Federada Servicio Gestor Virt (cluster 1) Provisión dinámica de recursos (DRP) … Gestor Virt (cluster N) Gestión de Negocio Gestor D&O (GS) Sistema de monitorización (GS) Rep. descriptores de usuario Gestor Ciclo de Vida Config. Applicaciones Rep. Software Rep. imágenes finales Rep. Info Proveedores Sistema de monitorización (GCF) Gestor D&O (GCF) Orquestador Cloud Federada Inter- operabilidad Conversor de recursos CMDB
9. Despliegue Despliegue Cluster1 Traducción Recursos para Cloud Externo Selección Recursos Óptimos Procesado OVF Buscar Despliegue Procesado y refinado OVF Configurar Aplicación Generar Imagen Despliegue Cloud Federada Evalúa la secuencia correcta de despliegue y puesta en marcha de las MVs Despliegue Cloud 1 (NUBA) Ok Ok Despliegue en Cloud Externo O Ok Ok Ok Proveedor Agregador Proveedor Gestor Cloud Federado Gestor Neg. (GCF) Gestor Cloud Federada Gestor Servici Gestor Neg. (GS) Gestor de Servicio
10. Optimización Se dispara una regla de optimización de este nivel … Consultas de los KPIs monitorizados Se calculan los redespliegues o cambios necesarios Redespliegue Redespliegue Procesado OVF Refinado Imágenes Redespliegue en Cloud Federada Ok Ok El Redespliegue continuaría en la Capa de Cloud Federada siguiendo pasos similares a los incluidos en la slide anterior
NUBA [13] es un proyecto de I+D+i cuyo principal objetivo es el desarrollo de una plataforma Cloud federada IaaS [14] que simplifica el despliegue de servicios empresariales en Internet de forma sencilla y automática, permitiendo el escalado d inámico en base a criterios de rendimiento y objetivos de negocio.
Los ejes principales del proyecto y por tanto de la Arquitectura NUBA se basan principalmente en: Facilitar la interacción con los proveedores de servicios, permitiéndoles el despliegue sencillo de servicios bajo un modelo de IaaS, controlando los aspectos de negocio como los modelos de pago por uso y calidad de servicio y minimizando los costes. Posibilitar la federación de Clouds, permitiendo la agregación de distintas ofertas de proveedores de infraestructuras junto a infraestructuras locales, operando de forma unificada sobre ellas según criterios de eficiencia energética, económica y tecnológica. Permitir la provisión de infraestructuras de DataCenter (Clusters) locales de forma a utomatizada, reduciendo costes de administración e inversión en hardware al compartir r ecursos entre distintos servicios utilizando distintas tecnologías de virtualización de r ecursos de red y computación. Posibilitar la gestión de recursos en base a criterios de negocio en todos los niveles de la cadena de valor en la provisión de servicios. En este sentido, aspectos como la toma de medidas, optimización, decisión de despliegue o cuadro de mandos puedan ser aplicados bajo los distintos contextos de administración de los proveedores de servicios, C louds federados y Clouds locales.
Describir los distintos roles en base a sus intereses: Proveedor de Servicios: utiliza la infraestructura cloud para desplegar sus servicios, ya sea para consumo propio o de sus clientes. Proveedor de Cloud: es el dueño de la infraestructura física de la cloud (datacenters), cuyo uso cede en un modo pago por uso. Agregador Cloud: se sitúa entre el Proveedor de Servicio y el Proveedor Cloud, actuando como mediador, de forma que al primero le proporciona un servicio cloud con ciertas capacidades avanzadas (veremos más en la siguiente transparencia) haciendo uso de la infrastructura de los segundos. Es la capa clave en NUBA, la verdadera novedad con respecto a la situación preexistente . Las flechas rojas al final tienen como objetivo mostrar que el Agregador Cloud es el “broker” de relaciones entre el PS y los PC (destacar que no hay flechas directas PS-PC)
Así, NUBA pretende abordar uno de los principales retos del mercado, creando las t ecnologías que permitan gestionar en tiempo real las Clouds de computación bajo criterios de negocio, donde la asignación de recursos de infraestructura se realice garantizando los niveles de servicio (SLA) requeridos y donde se consiga minimizar los costes de los entornos de c omputación y su consumo energético. NUBA está desarrollando tecnologías para la gestión de máquinas virtuales, extendiendo los modelos cerrados que sólo consideran máquinas virtuales aisladas y que soportan únicamente un tipo determinado de tecnología de virtualización. De esta forma NUBA (i) utiliza el entorno v irtual, entendido como un conjunto de máquinas virtuales interconectadas que implementan un s ervicio, como entidad básica de gestión; (ii) integra diversas arquitecturas de red, almacenamiento y tecnologías de virtualización en el gestor; (iii) permite el despliegue avanzado de servicios multi-capa mediante métodos de contextualización flexibles; (iv) permite definir diferentes políticas de asignación de recursos para optimizar la infraestructura física (ej. reducir el consumo energético, maximizar la utilización...). Por otro lado, NUBA mejora la gestión de los Clouds locales proporcionando soluciones no-propietarias, y permite el uso coordinado de cada uno de los Clouds locales. Así pues, se pueden desplegar maquinas virtuales de un servicio en diferentes proveedores, garantizando disponibilidad, escalabilidad, etc. Para evitar la adaptación a Cloud concretos, NUBA proporciona herramientas que permitan a los proveedores de servicios aprovisionar y gestionar sus servicios de manera abstracta a las diferentes Clouds. Un ejemplo de esto es la utilización de una especificación de descriptores de despliegue común. Finalmente, NUBA proporciona modelos de aprovisionami ento basados en objetivos de negocio, para garantizar los niveles de servicio requeridos (SLAs) a la vez que se minimizan los costes y los consumos energéticos.
La idea de la animación es la siguiente: Primero se ve la arquitectura a grandes bloques, que son los mismos vistos en la introducción, con lo que hay una transición suave desde ahí. Primer click : se aclara que la estructura interna del Agregador Cloud se divide en dos grandes capas funcionales: el Gestor de Servicio y el Gestor de Clooud Federada. Explicar someramente las funciones de cada una de ellas. Nuevo click : existe una tercera capa funcional, el Gestor de Negocio. Explicar someramente que funciones realiza. Explicar por qué hay dos instancias de este componente (porque cada una está asociada a una de las capas funcionales del Agregador Cloud) Nuevo click : existe este mismo componente también asociado al Proveedor Cloud Nuevo click : cada una de las capas está compuesta a su vez por una estructura de componentes. No se trata de explicarlas aquí, tan solo dar una idea de la complejidad y enjundia del proyecto.
Durante el proceso de despliegue, el descriptor será evaluado y podrá sufrir una serie de modificaciones para adaptarlo a los condicionantes de negocio propios de cada nivel de la arquitectura. La capa de Gestión del Servicio se encargará de hacer un primer refinado del descriptor (mediante el Gestor D&O) y de generar la imagen final del servicio a desplegar (Configurador de Aplicaciones), como muestra la Figura 3. Una vez que el gestor del ciclo de vida hace la petición de despliegue al orquestador de Cloud Federado, se eligen los recursos que albergarán las máquinas virtuales que conforman el servicio. Para ello, el Gestor D&O (GCF) selecciona los recursos más convenientes y se lo devuelve al orquestador. Por último, en primer lugar, el DRP realiza el último refinado del descriptor en función de la información de negocio disponible a este nivel. Después, el DRP se encargará de enviar los descriptores a los clusters en los que se desplegará el servicio. Además, la Plataforma NUBA permite la interacción con Cloud externos (p.e. Amazon EC2,) cuando no existen recursos suficientes que cubran las necesidades del servicio. En este caso, es necesario realizar un mapeo entre los recursos solicitados y los tipos de recursos disponibles en el Cloud externo. Los bloques Conversor de Recursos e Interoperabilidad llevan a cabo este paso intermedio hacia el Cloud externo.
Tanto los Proveedores de Servicio como el Agregador Cloud pueden definir un conjunto de KPIs a monitorizar para conocer en todo momento el estado de la infraestructura, de los servicios desplegados o el nivel de cumplimiento de los SLAs. Además, para cada KPI pueden definirse márgenes de funcionamiento o umbrales que, una vez superados, disparen procesos de optimización o ajuste en función de las reglas de elasticidad del servicio. Cada una de las capas de la Arquitectura NUBA dispondrá de KPIs y reglas de optimización propias, adaptadas a la información manejada en cada nivel. La Figura 4 ilustra el escenario de Optimización. Cuando se supera un cierto umbral de un KPI (valor provisto por los Sistemas de Monitorización), en el Gestor D&O se desencadena una acción (por ejemplo un escalado horizontal). Esta acción, normalmente, es ejecutada por el Gestor del Ciclo de Vida del Servicio que se encarga de interactuar con el resto de componentes de las capas inferiores de NUBA.
Describir los distintos roles en base a sus intereses: Proveedor de Servicios: utiliza la infraestructura cloud para desplegar sus servicios, ya sea para consumo propio o de sus clientes. Proveedor de Cloud: es el dueño de la infraestructura física de la cloud (datacenters), cuyo uso cede en un modo pago por uso. Agregador Cloud: se sitúa entre el Proveedor de Servicio y el Proveedor Cloud, actuando como mediador, de forma que al primero le proporciona un servicio cloud con ciertas capacidades avanzadas (veremos más en la siguiente transparencia) haciendo uso de la infrastructura de los segundos. Es la capa clave en NUBA, la verdadera novedad con respecto a la situación preexistente . Las flechas rojas al final tienen como objetivo mostrar que el Agregador Cloud es el “broker” de relaciones entre el PS y los PC (destacar que no hay flechas directas PS-PC)
La arquitectura planteada ha sido alineado y realimentada con procesos de experimentación y validación basados en diferentes casos de usos de negocio, con diferentes necesidades y enfoques. Estos casos de uso contemplan diferentes tipologías de servicios, diferentes tipos de empresas ( Grandes Empresas y PYMEs) y diferentes perfiles (gestores de infraestructura y proveedores d e servicio). Todos ellos, plantean escenarios donde la adopción del paradigma “Cloud” proporcionaría sustanciales beneficios competitivos e incluso nuevas oportunidades de negocio para el mercado español.
Se trata de un proyecto subvencionado por el programa Avanza I+D por el Ministerio de industria. Comenzó el año pasado (en Julio del 2009), por lo que llevamos casi un año. Tiene una duración de 2 años En el consorcio existen socios con expertise en áreas de Grid, Cloud y Supercomputación. Como grandes empresas tenemos a TID /y el coordinador y Atos. Como universidades está UCM Como centros de investigación tenemos a BSC (y centro de supercomputación) y a CESGA Y finalmente pymes están Caton Xeridia y eyeOS