Estudio de una solución OpenStack integrada con SDN

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Estudio de una solución OpenStack integrada con SDN"

Transcripción

1 Estudio de una solución OpenStack integrada con SDN Trabajo de Fin de Grado Presentado en Escola Tècnica d'enginyeria de Telecomunicació de Barcelona Universitat Politècnica de Catalunya por Emilio Soca Herrera Grado en Ingeniería Telemática Tutor: José Luis Muñoz Tapia Barcelona, Octubre 2015

2 Abstract This project has the objective of studying the OpenStack Cloud technology and its integration with the paradigm SDN. The project has been divided into two phases: Study and deployment of OpenStack: OpenStack has a highly distributed architecture, composed of several modules or services that do some specific functionalities (storage, networking, computer, etc). Moreover, OpenStack uses others of the most advanced technologies on the IT sector, so the study of the plataform is a real challenge. OpenStack leading services, like technologies on which they are based, are detailed in the project. Subsequently, the complex deployment of OpenStack has been made on a personal machine using virtualization technologies (LXC and KVM) and OpenvSwitch switch to connect them. The deployment design decisions are detailed, like the steps and the errors found. SDN study and integration of OpenDaylight: In the second phase of the project, the architecture, protocols and components of SDN paradigm are studied. SDN OpenDaylight is chosen as the controller to be introduced into our deployment of OpenStack and the possibilities that offers are explained in this project. Finally, the OpenDaylight integration runs, explaining design decisions, steps and the errors found.

3 Resum El present projecte té com a objectiu realitzar un estudi de la tecnologia Cloud OpenStack i la seva integració amb el paradigma SDN. El projecte s'ha dividit en dues grans fases: Estudi i desplegament de OpenStack: OpenStack presenta una arquitectura altament distribuïda, composta de diversos mòduls o serveis que s'encarreguen d'una funcionalitat en concret (emmagatzematge, xarxes, còmput, etc.). D'altra banda, OpenStack es nodreix de les tecnologies més punteres de cada sector TIC provocant que l'estudi de la plataforma sigui un veritable repte. Els serveis principals de OpenStack, així com les tecnologies en què es basen, s'han detallat en el projecte. Posteriorment s'ha realitzat el complex desplegament d'openstack en una màquina personal amb l'ús de tecnologies de virtualització (lxc i KVM) i el switch OpenvSwitch per connectar-les. S'han detallat les decisions de disseny del desplegament, així com els passos i els errors trobats. Estudi de SDN i integració de OpenDaylight: A la segona fase del projecte s'estudien l'arquitectura, protocols i components del paradigma SDN. Es tria el controlador SDN OpenDaylight per ser integrat en el nostre desplegament de OpenStack i s'expliquen les possibilitats que ofereix. Finalment s'executa la integració de OpenDaylight explicant les decisions de disseny, els passos i els errors trobats.

4 Resumen El presente proyecto tiene como objetivo realizar un estudio de la tecnología Cloud OpenStack y su integración con el paradigma SDN. El proyecto se ha dividido en dos grandes fases: Estudio y despliegue de OpenStack: OpenStack presenta una arquitectura altamente distribuida, compuesta de diversos módulos o servicios que se encargan de una funcionalidad en concreto (almacenamiento, redes, cómputo, etc). Por otra parte, OpenStack se nutre de las tecnologías más punteras de cada sector IT provocando que el estudio de la plataforma sea un verdadero reto. Los servicios principales de OpenStack, así como las tecnologías en las que se basan, se han detallado en el proyecto. Posteriormente se ha realizado el complejo despliegue de OpenStack en una máquina personal con el uso de tecnologías de virtualización (LXC y KVM) y el switch OpenvSwitch para conectarlas. Se han detallado las decisiones de diseño del despliegue, así como los pasos y los errores encontrados. Estudio de SDN e integración de OpenDaylight: En la segunda fase del proyecto se estudian la arquitectura, protocolos y componentes del paradigma SDN. Se elige el controlador SDN OpenDaylight para ser integrado en nuestro despliegue de OpenStack y se explican las posibilidades que ofrece. Finalmente se ejecuta la integración de OpenDaylight explicando las decisiones de diseño, los pasos y los errores encontrados.

5 Agradecimientos Quiero agradecer a mi tutor José Luiz Muñoz Tapia por el soporte brindado en el transcurso del proyecto y su recomendación de OpenStack y SDN como temas del proyecto.

6 Revision history and approval record Revision Date Purpose 0 14/10/2015 Document creation 1 15/10/2015 Document revision DOCUMENT DISTRIBUTION LIST Name Emilio Soca Herrera José Luis Muñoz Tapia esoca123@gmail.com jose.munoz@entel.upc.edu Written by: Reviewed and approved by: Date 14/10/2015 Date 15/10/2015 Name Emilio Soca Herrera Name José Luis Muñoz Tapia Position Project Author Position Project Supervisor

7 Tabla de contenidos Abstract...1 Resum...2 Resumen...3 Agradecimientos...4 Revision history and approval record...5 Tabla de contenidos Introducción Objetivos del proyecto Requisitos y especificaciones Recursos de terceros Plan de trabajo (Work plan) Desviaciones del proyecto original Estado del arte: OpenStack OpenDayLight LXC OpenvSwitch Metodología Resultados Presupuesto Conclusiones y trabajos futuros Conclusiones Trabajos futuros...19 Bibliografía...20 Apéndices :...21

8

9 1. Introducción El objetivo de este documento es ofrecer un resumen ejecutivo del proyecto. La documentación detallada de las tecnologías estudiadas e implementadas se encuentran anexadas a esta memoria Objetivos del proyecto Los objetivos iniciales del proyecto no estaban definidos de forma rígida. La intención inicial comprendía estudiar OpenStack y OpenDayLight, para luego realizar una implementación conjunta. Además se valoró la posibilidad de desarrollar algún software que usara las APIs disponibles, pero solo si el tiempo lo permitía. Durante el transcurso del proyecto descubrimos la alta complejidad que presentan ambas plataformas, puesto que tienen una arquitectura modular que soporta las tecnologías más punteras de sus respectivos campos (Cloud y SDN). Por otra parte, OpenDaylight es demasiado reciente y la documentación oficial de operación no está a la altura de la disponible para OpenStack. El despliegue de OpenStack en nuestro ordenador personal resultó bastante costoso en tiempo, puesto que se aprendieron nuevas tecnologías (KVM, LXC y OpenvSwitch) y se resolvieron múltiples problemas de configuración. A partir de dicha experiencia se definieron los siguientes objetivos finales: Formación de un amplio conocimiento teórico y práctico de OpenStack. Formación de conocimientos básicos de SDN y OpenDaylight, y su relación con OpenStack. Realizar una documentación teórica y práctica para el soporte de nuevas asignaturas o proyectos relacionadas con el Cloud Computing y SDN, así como para el futuro profesional o de investigación de los lectores del proyecto. Los objetivos anteriores finalmente se cumplieron Requisitos y especificaciones Los requisitos del proyecto se pueden agrupar en dos categorías: requisitos teóricos y requisitos técnicos. Requisistos teóricos: - Redes (Routing, VPN, OpenFlow, SDN). - Almacenamiento (Objetos, bloques, ficheros).

10 - Software (Colas, API REST). - Virtualización (LXC, KVM, imágenes). - Cloud Computing (OpenStack). Requisitos técnicos - Uso de LXC, KVM y OpenvSwitch. - Diseño y creación de un laboratorio virtual. - Uso de Latex - Uso de Linux - Uso de SVN 1.3. Recursos de terceros El proyecto no es continuación de otra tarea o proyecto pero utiliza la documentación de LXC generada por otro estudiante en su proyecto final de grado.[1]

11 1.4. Plan de trabajo (Work plan) Work Packages: Project: Estudio de una solución OpenStack con SDN WP ref: WP1 Major constituent: Software Short description: Preparación del equipo e instalación del software necesario Planned start date: 01/03/2015 Planned end date: 15/03/2015 Start event: 01/03/2015 End event: 01/04/2015 Internal task T1: Preparación de los contenedores LXC Deliverables: Dates: Internal task T2: Preparación de las maquinas virtuales KVM para los nodos que no permitan una instalación con LXC (Por ejemplo devstack funciona mejor con KVM)

12 Project: WP ref: WP2 Major constituent: Lectura y aprendizaje Short description: Aprendizaje sobre OpenStack y OpenDaylight: Arquitecturas, componentes, buenas prácticas, etc. Documentación. Planned start date: 7/03/2015 Planned end date: 1/07/2015 Start event: 7/03/2015 End event: 28/09/2015 Internal task T1: Familiarizarse con las herramientas de red usadas para el proyecto como OvS, brctl y otras herramientas de Linux Deliverables: Dates: Internal task T2: Conocer con profundidad OpenStack Internal task T3: Conocer OpenDaylight Internal task T4: Documentación

13 Project: Estudio de una solución OpenStack con SDN WP ref: WP3 Major constituent: Software Short description: Implemtación del sistema OpenStack y pruebas. Planned start date: 15/03/2015 Planned end date: 1/05/2015 Start event: 15/03/2015 End event: 14/06/2015 Internal task T1: Montar todos los nodos de Openstack de forma virtual y configurarlos adecuadamente. Deliverables: Dates: Internal task T2: Levantar VM dentro de OpenStack, reservar almacenamiento. Project: Estudio de una solución OpenStack con SDN Major constituent: Software WP ref: WP4 Short description: Integración del sistema OpenDayLight dentro del sistema OpenStack. Planned start date: 21/04/2015 Planned end date: 21/05/2015 Start event: 28/05/2015 End event: 28/09/2015 Internal task T1: Integrar Controlador SDN. Deliverables: Dates: Internal task T2: Realizar pruebas donde el controlador SDN provea de redes a las instancias.

14 Time plan

15 1.5. Desviaciones del proyecto original En el proyecto inicialmente se pretendían usar contenedores LXC para todos los nodos de OpenStack, pero el el servicio nova-compute no funcionó correctamente. Al no encontrar pistas del error decidimos usar KVM para el nodo de Cómputo y funcionó correctamente.

16 2. Estado del arte: 2.1. OpenStack Openstack se define comercialmente como un sistema operativo en la nube que permite controlar recursos de computación, almacenamiento y redes a través de un dashboard o cuadro de mando y APIs estándares de programación. Su arquitectura es distribuida y utiliza diferentes tipos de nodos especializados en distintos servicios y conectados mediante redes de gestión y datos. [2] 2.2. OpenDayLight OpenDayLight es un Controlador SDN, Open Source, escrito en Java e implementado dentro de su propia máquina virtual (JVM). Ha recibido el soporte de la "Linux Fundation" y el de muchas empresas del sector como Cisco, HP, Red Hat, etc. En su hora de ruta se encuentra dar soporte completo a tecnologías novedosas como NFV, VTN y SFC. [3] 2.3. LXC LXC es una tecnología de virtualización, clasificada como virtualización a nivel de sistema operativo. El sistema host comparte el kernel con cada una de las instancias o contenedores de LXC, provocando que se consuman menos recursos a igual carga de trabajo. Usa las tecnologías de Namespaces y Cgroups desarrolladas en el Kernel de Linux OpenvSwitch OpenvSwitch (OVS) es un sofware Open Source que actúa como un switch virtual multicapa. Su objetivo es implementar una plataforma que soporte los protocolos de red estándares y permitir que las funciones de encaminamiento puedan ser programadas.

17 3. Metodología El análisis y resolución de incidencias producidas durante el despliegue de OpenStack y OpenDayLight estuvo basado en los siguientes pasos: - Enviar pings desde cada nodo o desde el sistema host para verificar conectividad. Muchas veces tan solo necesitábamos reiniciar el servicio openvswitch en el host para restablecer la comunicación. - Desde el nodo Controlador ejecutar el comando neutron agent-list para verificar cuales agentes de Neutron están funcionando correctamente. - Desde el nodo Controlador ejecutar el comando nova service-list para verficar cuales servicios de Nova están funcionando correctamente. - Reiniciar los subservicios que presenten problemas. Por ejemplo, si el subservicio nova-cert no funciona correctamente se debe ejecutar el comando service nova-cert restart desde el nodo Controlador. - Mirar los ficheros de logs de los agentes, plugins y servicios que presenten el problema. Reconfigurar los ficheros de configuración necesarios. - Buscar en foros de OpenStack y OpenDayLight sobre los errores presentados en la terminal o en los ficheros de logs. - Para problemas de conectividad en red de las instancias se recomienda el uso de tcpdump. Tcpdump es un analizador de redes que funciona vía consola. Como no necesita interfaz gráfica podemos ejecutarlo en los nodos y ponerlo a la escucha en una interfaz para investigar en que interfaz o nodo se pierde la conexión. - Para comprobar la conectividad con routers o instancias virtuales que se encuentren en otras net namespaces se recomienda el uso del comando ip netns exec <namespace> ping <ip>

18 4. Resultados Los resultados más relevantes del proyecto son los siguientes: - El despliegue de OpenStack y OpenDayLight se realizó satisfactoriamente. El sistema lanzaba instancias, creaba redes internas y externas, asignaba almacenamiento, IPs flotantes y consolas VNC a las instancias. Horizon reflejaba la topografía de los tenants y en ODL Dlux se veía la topología de los switches virtuales OpenvSwitch. El sistema funcionaba de forma estable y rápido teniendo en cuenta que todos los nodos corrían sobre un portatil i7 y 6GB de RAM. - El despliegue de OpenStack no es una tarea sencilla. Solo para hacer funcionar el sistema se necesitan configurar un gran número de servicios y subservicios que se encuentran en diferentes nodos físifcos. El problema se complica un poco más cuando los supuestos nodos físicos también están virtualizados. El uso de la metodología en el apartado 3 de este documento ha sido vital para lograr que OpenStack funcionase finalmente. - Aún si logramos que OpenStack funcione, tampoco es fácil lograr que lo haga forma óptima y con las tecnologías adecuadas. En el área de redes podemos usar cinco modos de conectar las instancias entre ellas y hacia las redes externas (GRE, VXLAN, Flat, VLAN, Local), así como usar varios drivers en el plugin ML2 (OpenDayLight, OpenvSwitch). Tenemos dos tipos de almacenamiento (bloques y objetos) con múltiples posibilidades de backends (Ceph, Gluster, LVM) y Nova puede usar varios hipervisores (KVM, XEN, LXC). Finalmente, la arquitectura de red también es variable al igual que el nodo donde debe correr un servicio determinado. - Hacer el despliegue manual de OpenStack es recomendable al menos una vez para entender los entresijos de las configuraciones. Para posteriores despliegues es más eficiente herramientas de automatización como Puppet, Ubuntu JUJU, etc. - La documentación oficial de OpenStack se encuentra muy organizada y con suficiente tiempo podemos conocer y desplegar todo el sistema Cloud. Sin embargo, no he encontrado la documentación de OpendayLight a la altura (al menos en lo que respecta a su integración con OpenStack). Cada nueva versión de OpenDayLight puede traer inconsistencias con la versión anterior, por ejemplo la nueva versión ODL Lithium no se comunica correctamente con Neutron por defecto y debemos realizar cambios en los ficheros de OpenStack. - La resolución de todos los problemas encontrados se encuentra en el documento anexo y espero sirva de ayuda para aquellas personas que intenten desplegar OpenStack Juno Y OpenDayLight Lithium en contenedores LXC y máquinas virtuales KVM.

19 5. Presupuesto Todos las tecnologías usadas en el proyecto (OpenStack, OpenDayLight, LXC, etc) están licenciadas bajo una licencia Open Source gratuitas (Apache, GPL, etc). Los sistemas operativos utilizados han sido Linux Mint 17 en el sistema host y Ubuntu Server en los nodos, sistemas que son de Código Abierto y gratuitos. Es decir, el software no añade ningún costo al proyecto. Las horas estimadas dedicadas al proyecto han sido 600h. Teniendo en cuenta el mercado laboral actual de España, me parece razonable tomar el coste (sueldo bruto más cotizaciones a la seguridad social por la empresa) de un ingeniero recién graduado de 13 /h. Finalmente el coste total de la tesis asciende a 7800.

20 6. Conclusiones y trabajos futuros 6.1. Conclusiones Al conocer y experimentar todas las opciones de OpenStack puedo decir que el Cloud Computing es vital para el desarrollo digital de un negocio. Luego de configurar el complejo engranaje el cliente puede consumir recursos de almacenamiento, redes y cómputo de forma flexible y barata. Poder guardar mis backups en Swift, las bases de datos en Cinder, tener varias redes virtuales para hacer pruebas y aumentar el número de instancias según la carga de trabajo son opciones muy valiosas que permiten lanzar negocios digitales a escala mundial. Con el desarrollo de nuevos servicios OpenStack ofrecerá aún más alternativas bajo demanda (DNS, Bare metal, Hadoop, etc). Por otro lado OpenDayLight debe seguir avanzando y mejorar su estabilidad. SDN aporta notables mejoras al diseño de redes y OpenDayLight debe liderar su desarrollo como principal Controlador Open Source. Integrar OpenDayLight en OpenStack tiene dos ventajas principales: El uso de servicios de red especiales como el Unified Secure Channe que cifra todas las comunicaciones y el soporte de varios protocolos de SouthBound como NETCONF y BGP ya soportados por OpenDayLight Trabajos futuros La posibilidad de trabajos futuros a partir de esta documentación es muy amplia. Este proyecto realiza un fotografía de alto nivel a un sistema OpenStack y explica las bases de SDN. A partir de aquí un estudiante podría seguir alguna de las siguientes directrices: - Enfocarse en un área concreta de OpenStack como el almacenamiento y explicar los backends Open Source como Ceph, Gluster, etc. O hacer una comparación detallada entre almacenamiento de objetos, de ficheros y de bloques. - Relacionado con redes, podría explicar detalladamente OpenDayLight o las redes superpusetas (GRE, VXLAN) - En el área de cómputo podría explicar el funcionamiento detallado de KVM, LXC o DOCKER. - Explicar otras tecnologías que compiten con el concepto Cloud como Kubernetes, CoreOs, Ubuntu Snappy Core, Proxmox, etc. - Estudiar un despliegue automático de OpenStack a partir de Puppet, Ubuntu JuJu, etc. - Estudiar el Cluster Hadoop, Spark o Apache Storm.

21 Bibliografía [1] Marcel Sánchez Toledano. ESTUDI I IMPLEMENTACIÓ D'UN SISTEMA DE VIRTUALITZACIÓ BASAT EN LINUX CONTAINERS sequence=4 [2] Comunidad OpenStack. [3] Comunidad OpenDayLight. [4] Canonical. Proyecto LXC. [5] Comunidad OpenvSwitch

22 Apéndices : El apéndice de este documento es la memoria principal del Proyecto.

23 Trabajo Final de Grado Emilio Soca Estudio de una solución Openstack integrada con SDN

24

25 Contents 1 Cloud Computing Qués es el Cloud Computing? Tipos de sistemas Cloud OpenStack Qué es OpenStack? Arquitectura básica de OpenStack Servicios principales de OpenStack Horizon Dashboard Nova Compute Keystone Identity Neutron Network Swift Object Storage Cinder Block Storage Glance Image Storage Ceilometer Telemetry Heat Orchestration Flujo de peticiones para levantar una instancia Otras tecnologías relacionadas con OpenStack Tecnologías de Cómputo Tecnologías de Redes Tecnologías de Almacenamiento Tecnologia de Colas de mensajes Servicios en desarrollo de OpenStack Despligue de OpenStack Entorno de desarrollo Despliegue de Infraestructura inicial Instalación y configuración de LXC para el nodo de Red y el nodo Controlador Instalación y configuración la máquina virtual KVM para el nodo de Cómputo Instalación y configuración de OpenvSwitch para conectar los nodos Despliegue de OpenStack Entorno básico Instalación y configuración de DNS y hostname Instalación y configuración de NTP Instalación de los paquetes de OpenStack Instalación y configuración de las bases de datos Instalación y configuración del servidor de colas Verificación Problemas encontrados

26 3.3.2 Instalación y configuración de KeyStone Configuración inicial Creación de clientes, usuarios y roles Creación de la entidad del servicio y API endpoints Verificación Problemas encontrados Scripts OpenRC Instalación y configuración de Glance Configuración Inicial Integración en KeyStone Instalación de componentes de Glance Verificación Problemas encontrados Instalación y configuración de Nova Configuración inicial Integración en KeyStone Instalación de componentes de Nova Verificación Problemas encontrados Instalación y configuración de Neutron Configuración inicial Integración en KeyStone Instalación de componentes de Neutron Creación de redes iniciales Verificación Problemas encontrados Instalación y configuración de Horizon Instalación de componentes de Horizon Verificación Problemas encontrados Levantar una Instancia y lograr acceso externo Generación de par de claves (key pair) Levantamiento de la instancia Acceso a través de la consola virtual Permitir acceso externo a la instancia Problemas encontrados SDN y OpenDayLight Qué es SDN? Arquitectura de SDN OpenFlow Switch OpenFlow Mensajes del Protocolo OpenFlow Controlador OpenDaylight OpenDaylight y OpenStack Integración de OpenDayLight Entorno de desarrollo Despliegue de Infraestructura inicial Instalación y configuración de LXC para el nodo OpenDayLight Configuración de OpenvSwitch para conectar el nodo opendaylight Instalación e integración de OpenDayLight

27 5.3.1 Cambios iniciales Instalación de OpenDayLight Eliminación de instancias, routers y puertos anteriormente creados Nueva configuración de OpenvSwitch Configuración del plugin ML Reinicio de la base de datos de Neutron Modificación de fichero Neutron Verificación Problemas encontrados

28 6

29 Chapter 1 Cloud Computing 1.1 Qués es el Cloud Computing? El término Cloud Computing se refiere a una nueva concepción tecnológica y modelo de negocio en el que se prestan servicios de almacenamiento, acceso y uso de recursos informáticos radicados en la red. Toda la gestión del hardware es realizada por el proveedor de Cloud Computing asegurando cierta disponibilidad y potencia bajo unos niveles de servicio determinados (SLAs). De esta forma el cliente o usuario puede desentenderse de los recursos físicos y enfocarse en la actividad central de su negocio (desarrollo web, red privada empresarial, etc). Por otra parte un usuario final no necesita un dispositivo de altas prestaciones puesto que las tareas de mayor desempeño pueden ser trasladadas a la computación en la nube. La figura 1.1 muestra la imagen que percibe el usuario ante este nuevo paradigma. Figure 1.1: Cloud Computing. Según el organismo NIST (National Institute of Standards and Technology) del departamento de comercio de los Estados Unidos para que un servicio pueda considerarse Cloud debe cumplir cinco características básicas [10]: Servicio bajo demanda: Un usuario debe poder provisionarse automáticamente de recursos Cloud, como almacenamiento o capacidad de cómputo, sin requerir la interacción humana del proveedor de servicio. 7

30 Acceso amplio desde la red: Todos los servicios deben ser accesibles a través de estándares y plataformas comunes(por ejemplo un servicio web para ordenadores, móviles, etc). Puesta en común de recursos: Los recursos Cloud deben ser puestos en común para servir a varios consumidores a través de un modelo multi-tenancy 1. De esta manera los recursos físicos y virtuales se asignarán o reasignarán dinámicamente para satisfacer la demanda de consumo. Rápida elasticidad: La capacidad de los recursos contratados debe ser elástica. Es decir, los recursos asignados deben crecer o decrecer bajo demanda de forma automática o con la mayor celeridad posible. Capacidad de medición del servicio: Los sistemas Clouds deben ser controlados y optimizados a través de métricas que permitan un nivel de abstracción apropiado al tipo de servicio. Los recursos deberán ser monitorizados y bien presentados para ofrecer transparencia al proveedor y al cliente. 1.2 Tipos de sistemas Cloud Una implementación de Cloud Computing puede clasificarse siguiendo dos criterios explicados a continuación: Según el modelo de despliegue tenemos 4 clasificaciones: Nube Pública: En las nubes públicas los servicios ofrecidos se encuentran en servidores externos al usuario o empresa que desea hacer uso de ellos. Normalmente el proveedor Cloud cobra según el tiempo y capacidad de los recursos. Tiene como ventaja un aumento de recursos sin la necesidad de instalar y mantener las máquinas en local. De esta manera se reduce la inversión inicial y permite gran escalabilidad a empresas que necesiten el uso de estos recursos digitales. Como inconvenientes encontramos la dependencia a terceras personas, donde habitualmente se produce el conocido "lock-in" por nuestro proveedor. Para evitar dicha cautividad es recomendable elegir plataformas Open Source que faciliten la migración de nuestro software o producto. Nube Privada: En la nube privada los servicios se encuentran dentro de las instalaciones del usuario o empresa que hará uso de ellos. Normalmente las nubes privadas se implementan para la obtención de infraestructura (IaaS) como máquinas virtuales, contenedores, almacenamiento, redes, etc. En este caso será más sencillo integrar los servicios Cloud con sistemas propietarios y la seguridad y carga de trabajo correrá a cargo de la empresa. El principal inconveniente se encuentra en la inversión inicial del hardware y de operarios capacitados para mantener la infraestructura física y lógica de la instalación. Es una vía poco escalable para los inicios de una organización. Nube Híbrida: La nube híbrida combina las características de los dos casos anteriores. Una empresa puede mantener el control de sus aplicaciones principales y aprovechar la flexibilidad de una nube pública para un tarea o momento determinado. Las nubes híbridas ofrecen la promesa de la escalabilidad provisionada externamente y a demanda, permitiendo cubrir momentos o tareas críticas del modelo de negocio (por ejemplo, un ecomerce con altas ventas en navidad). Este tipo de nube comienza a imponerse sobre las anteriores debido a su versatilidad. Nube Comunitaria: Son nubes implementadas para el uso exclusivo de una comunidad, normalmente organizaciones que comparten asuntos (por ejemplo, la red de policía, red de hospitales, etc). 1 En el contexto de Cloud Computing el término Tenant se entiende como un usuario o grupo de usuarios que comparten acceso común a una instancia con privilegios específicos. Todas las traducciones del término en español presentan pérdidas de significado, así que para el desarrollo del proyecto se mantendrá el término en inglés Tenant. 8

31 La figura 1.2 muestra el esquema del traspaso de la carga de trabajo de aplicaciones en nubes federadas. Básicamente, resume el objetivo principal de una nube híbrida. Nube Híbrida Carga de App Carga de App Carga de App Management Cloud Os Nubes Federadas Management Cloud Os Nube Privada Figure 1.2: Nube híbrida. Nube Pública Según el modelo de servicio tenemos 3 clasificaciones 2. Software as a Service (SaaS): El Software como Servicio permite al cliente final usar una aplicación que corre sobre una infraestructura cloud. La aplicación debe ser fácilmente accesible ya sea a través de la web o a través de un cliente de escritorio. El usuario no puede controlar la infraestructura subyacente como los sistemas operativos, redes o almacenamiento. Ejemplos de SaaS son OwnCloud, WordPress, Gmail, Dropbox y Salesforce. Platform as a Service (PaaS): La Plataforma como Servicio permite a un desarrollador configurar su propio sistema de programación a través de lenguajes de programación, librerías, APIs, servicios y otras herramientas. El desarrollador no puede controlar la infraestructura subyacente como los sistemas operativos, redes o almacenamiento. Ejemplos de PaaS son OpenShift, CloudFoundry, IBM Bluemix y Google App Engine. Infrastructure as a Service (IaaS): La Infraestructura como Servicio permite a un operador de red gestionar el poder de cómputo, almacenamiento, conexionado de redes y otros recursos fundamentales para ofrecer un servicio a un cliente final. El operador no gestiona la infraestructura subyacente del Cloud, sino que gestiona la infraestructura virtual superpuesta (máquinas virtuales, contenedores, redes virtuales, etc). Por ejemplo, mientras el operador puede correr sus aplicaciones y sistemas operativos, el proveedor se encargará de la replicación y los backups del sistema en general. Ejemplos de IaaS son OpenStack, CloudStack, IBM SoftLayer y AWS. La figura 1.3 muestra un esquema de los tres tipos básicos de Cloud según el modelo de servicio. 2 En la actualidad se está desarrollando una nueva clasificación de Cloud Computing: Metal as a Service. El MaaS permite al usuario el control total de los servidores físicos incluyendo la BIOS y su conexión en red, pagando por el tiempo exacto de uso. De esta manera el operador podrá montar una red desde el nivel más bajo controlando la seguridad de todos los niveles de software. Existen clientes con actividades críticas que precisan de este nivel de control (Bancos, Gobiernos, etc). Ejemplos de MaaS son Ubuntu MaaS, BigStep y RackSpace OnMetal. 9

32 SaaS Usuarios finales Nivel de abstacción Flexibilidad PaaS Desarrolladores de aplicaciones IaaS Operadores de red y administradores de sistemas Figure 1.3: Tipos de Clouds. Para el proyecto se ha elegido la plataforma de Cloud Computing OpenStack por su formato Open Source y el gran apoyo recibido por el sector privado. 10

33 Chapter 2 OpenStack 2.1 Qué es OpenStack? Openstack se define comercialmente como un sistema operativo en la nube que permite controlar recursos de computación, almacenamiento y redes a través de un dashboard o cuadro de mando y APIs 1 estándares de programación [3]. Su arquitectura es distribuida y utiliza diferentes tipos de nodos especializados en distintos servicios y conectados mediante redes de gestión y datos. Usando la terminología Cloud OpenStack se considera una plataforma para IaaS. La figura 2.1 muestra un esquema con los principales tipos de nodos de la plataforma y su relación lógica. Aplicaciones externas APIs Nodo Controlador Nodo de Computo Nodo de Redes Nodo de Almacenamiento Servicios compartidos entre nodos de OpenStack Hardware estandar Figure 2.1: Relación lógica entre nodos principales de OpenStack. OpenStack está programado principalmente en python. Su diseño modular permite el desarrollo de plug-ins en otros lenguajes de programación siempre respetando las APIs REST 2. Para el proyecto se ha usado la versión Juno de OpenStack. 1 API se refiere a "Application Programming Interface" y es el conjunto de funciones o métodos que ofrece cierta biblioteca o servicio para ser utilizado por otro software independiente como una capa de abstracción. 2 REST quiere decir "Representational State Transfer" y orginalmente se refería a un conjunto de principios de arquitectura de software. En la actualidad se usa para describir una interfaz entre sistemas que utilice HTTP para obtener datos o ejecutar operaciones sobre datos usando los formatos XML y JSON. 11

34 2.2 Arquitectura básica de OpenStack Como se ha comentado OpenStack está dividido en diferentes tipos de nodos que trabajan en conjunto. La integración se logra a través de interfaces de programación de aplicaciones (APIs) que cada servicio ofrece y consume. De esta forma es posible que un servicio sea reemplazado por otro mejor si respeta la forma de comunicación (API usada). Por otra parte, OpenStack permite una implementación extensible, es decir un operador decide que nodos debe incluir inicialmente en el diseño de su Cloud y cuales añadirá en el futuro. La figura 2.2 muestra las relaciones entre los servicios y la función que cada uno de ellos realiza en una configuración estándar de OpenStack.[2] Heat Orquesta la nube Provee interfaz gráfica Horizon Provee interfaz gráfica Neutron Provee conectividad de red Provee volúmenes Instancia Provee imágenes Cinder Nova Controla ciclo de vida Glance Puede almacenar imágenes Swift Monitoriza Provee autentificación Monitoriza Ceilometer Provee autentificación Provee autentificación Keystone Provee interfaz gráfica Realiza Backups de volúmenes Figure 2.2: Servicios de OpenStack. 2.3 Servicios principales de OpenStack Un servicio OpenStack puede alojarse en un nodo independiente o compartir el alojamiento según el diseño del arquitecto Cloud. Cada servicio a su vez se divide en varios componentes o subservicios, por ejemplo el Nodo de Cómputo es el referente del servicio Nova Compute y aloja el subservicio nova-compute. El resto de subservicios como nova-api y nova-sheduler se alojan en el nodo Controlador. A medida que avanza el desarrollo de OpenStack los servicios se actualizan o se reemplazan totalmente, provocando el cambio de nombre en el servicio. Por ejemplo el servicio de red usado en la versión OpenStack Juno se llama Neutron. A continuación se explicarán los principales servicios de OpenStack mostrados en la figura 2.2 [20] [9]. 12

35 2.3.1 Horizon Dashboard Horizon provee una interfaz o cuadro de mando sobre el resto de servicios a los usuarios finales y al administrador. Estará incluido en este proyecto para visualizar la interfaz principal de OpenStack. La figura 2.3 muestra los componentes de Horizon y las relaciones con componentes del resto de servicios. Usuarios de OpenStack HTTP(S) cinder-api API de almacenamiento en bloque horizon Horizon Dashboard API de objetos swift-proxy neutron-server API de red API de identificación keystone nova-api API de cómputo Base de datos De horizon API de imágenes glance-api Figure 2.3: Componentes y relaciones del servicio Horizon. Características principales[4]: Es un aplicación web basada en Django 3. Se encuentra implementado a través de mod_wsgi 4 en Apache. Tiene una pequeña base de datos SQLite3, pero la mayoría de los datos son provistos por otros servicios. Utiliza las APIs estandares de OpenStack para comunicarse con el resto de servicios. Horizon es una implementación estándar del dashboard, pero es fácilmente adaptable para cambiar la visualización y funcionalidad del dashboard Nova Compute Nova Compute transforma bajo demanda los pedidos de usuarios en máquinas virtuales o contenedores. Es el servicio responsable del ciclo de vida de las instancias, es decir permite lanzar, reiniciar, suspender o parar instancias. Está diseñado para escalar de forma horizontal, es decir que podemos ir añadiendo más nodos de Cómputo si la carga de trabajo lo justifica. Constituye una parte fundamental y estará incluido en nuestra instalación de OpenStack. 3 Django es un framework escrito en python para desarrollar aplicaciones web. 4 mod_wsgi es un módulo de Apache que permite alojar una aplicación WSGI. WSGI significa "Web Server Gateway Interface" y es una especificación de como un servidor web se comunica con aplicaciones web. 13

36 La figura 2.4 muestra los componentes de Nova y las relaciones con componentes del resto de servicios. Usuarios de OpenStack AWS EC2 API API de cómputo VNC glance-api API de imágenes nova-api Nova Compute API de cómputo horizon neutron-server API de red API de almacenamiento en bloque API de imágenes nova-compute Libvirt, XenAPI, etc hypervisor nova-conductor Base de datos de nova AMQP AMQP AMQP AMQP cola AMQP AMQP AMQP Novanovncproxy nova-cert API de identificación keystone cinder-api nova-sheduler nova-consoleauth Características principales: Figure 2.4: Componentes y relaciones del servicio Nova. El cliente nova-api se encarga de aceptar y responder las peticiones del usuario final, ya sea a través del API de OpenStack Compute, del API de Amazon EC2 o de Horizon. A su vez, interacciona con KeyStone para lograr autenticación y puede hacer petición a glance-api para comprobar la disponibilidad de imágenes 5 para las instancias. Inicia la mayoría de actividades como el lanzamiento de una instancia. Existe otro subservicio asociado llamado nova-api-metadata que acepta peticiones de meta-datos de las instancias, pero normalmente se usa en despliegues con nova-network (sin Neutron) y que no usaremos en nuestro proyecto. El componente nova-compute es el encargado de administrar la virtualización, creando y finalizando las instancias de VMs 6 a través de la API del hipervisor 7 correspondiente. Por ejemplo, tenemos XenAPI para el hipervisor XenServer, libvirt para KVM o QEMU y VMwareAPI para VMware. Básicamente, nova-compute acepta acciones de la cola y ejecuta una serie de comandos como lanzar la instancia y actualizar su estado en la base de datos. También se comunica con neutron-server para conectar las instancias a las redes virtuales y con cinder-api para montar volúmenes en dichas instancias. Finalmente nova-compute gestiona el almacenamiento efímero de las instancias que representa el disco interno del Nodo de Cómputo. En los últimos años se ha avanzado considerablemente en el desarrollo de la virtualización basada en contenedores 8 (contenerización). Nova ya puede crear instancias de contenedores LXC o Docker a través de módulos especiales pero el soporte de funcionalidades es muy bajo en comparación con la virtualización estandar. No obstante, la contenerización permite mucha mayor eficiencia en el uso de los recursos de cómputo. Por defecto nova-compute utiliza el hipervisor KVM, siendo este el más estable y el que permite más funcionalidades [16] [17]. El componente nova-shedule toma pedidos de instancias desde la cola y determina en cual Nodo de Cómputo debería ejecutarse, actualizando el estado en la base de datos. Es decir, se encarga de la planificación de los recursos de cómputo. El componente nova-conductor media en las interacciones entre nova-compute y la base de datos. No se debe desplegar en el mismo nodo donde corra nova-compute por motivos de seguridad. 5 Una Imagen es un archivo informático donde se almacena una copia o imagen exacta de un sistema de archivos o ficheros. 6 VM se refiere a "Virtual machine" o máquina virtual 7 Hipervisor o monitor de máquina virtual es una plataforma de software que aplica diversas técnicas de control para utilizar, al mismo tiempo, diferente sistemas operativos en un mismo ordenador. 8 Un Contenedor es una instancia que utiliza el propio kernel del sistema operativo "host". 14

37 El componente nova-consoleauth autoriza tokens para usuarios que deseen acceder a proxis de consola. Como proxis de consola existen nova-novncproxy, nova-spicehtml5proxy y nova-xvpnvncproxy. En nuestro proyecto usaremos nova-novncproxy. El componente nova-novncproxy provee un proxy para acceder a instancias en ejecución a través de VNC 9. Soporta navegadores que funciones como clientes novnc. El componente nova-cert provee de certificados X509, usados principalmente para la API de EC2. La base de datos almacena los estados de instancias en ejecución (run-time) y disponibilidad para nuevas instancias (build-time): Instancias en uso, tipos de instancias disponibles, redes y proyectos disponibles, etc. La cola funciona como un eje central para el paso de mensajes entre los subservicios. Normalmente se implementa con RabbitMQ, pero se puede usar otra cola basada en el protocolo AMQP como Apache Qpid o Zero MQ. Un usuario al crear una instancia debe elegir un flavor o sabor que representa un tipo de configuración de recursos virtuales disponibles, por ejemplo el número de VCPUs (virtual CPUs) o el tamaño del almacenamiento efímero. Los componentes nova-volume y nova-network han sido reemplazados por los nuevos servicios Cinder y Neutron respectivamente. nova-network se encuentra funcionando en producción en muchos de los primeros sistemas Cloud desplegados, pero se aconseja su reemplazo por el servicio Neutron para nuevos despliegues Keystone Identity Keystone provee autenticación y autorización para los usuarios, tenants y para el resto de servicios de OpenStack. Además, provee de un catálogo de servicios disponibles y sus API end-points. Constituye una parte fundamental y estará incluido en nuestra instalación de OpenStack. La figura 2.5 muestra los componentes de Keystone y las relaciones con componentes del resto de servicios. Usuarios de OpenStack API de identificación cinder-api neutron-server nova-api API de identificación API de identificación API de identificación Backend de políticas (reglas,etc) Backend de Catálogos (kvs,sql, etc) Keystone Keystone Identity Backend de Tockens (kvs,memcache, etc) Backend de identidades (kvs,sql,ldap,etc) API de identificación API de identificación API de identificación horizon swift-proxy glance-api Figure 2.5: Componentes y relaciones del servicio Keystone. Los siguientes conceptos están intrínsecamente relacionados con KeyStone y su comprensión es fundamental para entender el servicio. Usuario: Representación digital de una persona o sistema que usa OpenStack. KeyStone valida las peticiones del usuario a través de confirmación de las credenciales. Se pueden asignar tokens a un usuario para acceder a un recurso determinado, por ejemplo para el acceso a la consola VNC. Un usuario puede ser asignado a un tenant en particular y restringirse por los permisos de dicho tenant. Credenciales: Datos que confirman la identidad del usuario. Por ejemplo: usuario y password, usuario y API key o un token de autenticación. 9 VNC significa "Virtual Network Computing" y permite tomar el control de un servidor remoto a través del entorno gráfico. 15

38 Token: Linea de caracteres alfanuméricos usados para acceder a los recursos y APIs de OpenStack. Un token puede ser revocado luego de un tiempo y es válido durante un tiempo limitado. Tenant: Usuario o grupo de usuarios que comparten acceso común a una instancia con privilegios específicos. En dependencia del operador del servicio, un tenant puede ser un cliente, proyecto, cuenta, organización o subscriptor. En el contexto interno de la arquitectura Cloud, existe el tenant "service" que identifica en KeyStone a todos los servicios de OpenStack. API end-point: Dirección accesible desde la red donde se encuentra el API del servicio, normalmente una dirección URL. Rol: Define los privilegios que tiene un usuario frente a un tenant asociado. Es decir, un usuario puede ser administrador de un tenant y usuario sin privilegios en otro tenant determinado. Es posible definir más roles pero no es usual, así que normalmente tenemos administrador y usuarios sin privilegios. Características principales de KeyStone: En la infraestructura Cloud KeyStone se encarga de autenticar el resto de servicios respondiendo a las peticiones que le llegan a su API. Cuando desplegamos un nuevo servicio este debe ser registrado en la base de datos de KeyStone. Provee de un catálogo de servicios disponibles a los usuarios y sus API end-points para consumo de otros servicios y de los usuarios. Gestiona usuarios, roles, tenants y a que proyectos pertenecen. Constituye un punto centralizado para integrar las políticas de OpenStack, cátalogos de servicios, tokens y la autenticación. Cada función de Keystone (politicas, catálogos de servicios, tokens, autenticación) tiene un backend vinculable con distintas posibilidades de usar el servicio. Keystone soporta backends estándares como LDAP, SQL o KVS(Key-Value Stores) Neutron Network Neutron se encarga de gestionar las redes virtuales entre las instancias y la comunicación con redes externas. Provee de "conectividad en red" como servicio para interfaces virtuales (vnics) creadas por NOVA. Su nombre inicial fue Quantum, pero debido a problemas de copyright tuvo que cambiar su nombre a Neutron. Constituye una parte fundamental y estará incluido en nuestra instalación de OpenStack. La figura 2.8 muestra los componentes de Neutron y las relaciones con componentes del resto de servicios. Neutron utiliza los siguientes conceptos: Plug-in: La implementación original de gestión de red en OpenStack se hacía a través del subservicio novanetwork de Nova y presentaba un modelo muy básico de aislamiento a través de VLAN e IPtables en Linux. Con el desarrollo de Neutron se introduce el concepto de plug-in: implementación "enchufable" de back-end del API de red de OpenStack. Un plug-in puede usar cualquier tecnología que le permita implementar la lógica del API de red. Por ejemplo, algunos plug-ins usan VLANs e IPtables de Linux, mientras que otros usan OpenFlow o túneles "L2-in-L3". Existen plug-ins propietarios que dan soporte a equipamientos físicos (Cisco, HP, etc) para que gestionen las redes virtuales. Por otra, parte algunos plug-ins tienen asociado un agente específico en diferentes nodos del sistema Cloud que le ayudan a cumplir su función, por ejemplo el plug-in OVS necesita un agente llamado "neutron-plugin-openvswitch-agent" instalado en el Nodo de Red y el Nodo de Cómputo. El plug-in ML2 (Modular Layer 2) requiere especial atención debido a la versatilidad que aporta gracias a su estructura modular. Dicho plugin se comporta como un framework para nuevos subplug-ins o drivers conocidos como "Mechanism Driver" del plug-in ML2. Es decir, un programador puede implementar funciones de capa 2 desarrollando un plug-in completo o escribiendo un driver para el plug-in ML2 que requiere menos código 16

39 Usuarios de OpenStack API de red keystone API de identificación neutron-server Neutron Network API de red horizon nova-compute API de red cola AMQP AMQP plugins de Neutron Base de datos de Neutron proveedor de red (Cisco, Hp, OVS,etc) AMQP agentes de Neutron Figure 2.6: Componentes y relaciones del servicio Neutron. y esfuerzo. Finalmente, el plug-in ML2 permite a Neutron el uso simultaneo de diferentes variedades de tecnologías de red de capa 2 que se encuentran en la mayoría de centros de datos (VLANs, Túneles GRE, Túneles VXLAN). El siguiente diagrama muestra la arquitectura modular del plug-in ML2 y el soporte de tecnologías L2 para OpenStack Juno. Neutron Core Plugin ML2 Type Manager Type Driver Mechanism manager Mechanism Driver GRE VLAN VXLAN Flat Local Open vswitch Linuxbridge Hyper-V OpenDaylight Tail-F NCS Arista Cisco Nexus L2 Population Figure 2.7: Arquitectura modular del plug-in ML2. Los "Mechanism Driver" pueden seguir 3 modelos: Basado en agentes como Open vswitch y Linuxbridge, basado en controlador como OpenDaylight y basado en Switches ToR como Arista y Cisco Nexus. Para nuestro proyecto usaremos el "Type Driver GRE" para redes virtuales internas y "Type Driver Flat" para la red virtual externa, primero con el "Mechanism Driver" Open vswitch y luego con el "Mechanism Driver OpenDaylight". Agente: Un agente normalmente se encuentra asociado a un plug-in para realizar una función de red concreta. Los agentes se pueden instalar en el mismo nodo del plug-in o en otro nodo, en dependencia de la arquitectura del sistema Cloud. Existen dos agentes comunes para todos los plug-ins. El "neutron-l3-agent" brinda enrutamiento L3 y servicio NAT para proveer de acceso externo a las instancias, mientras que el "neutron-dhcp-agent" provee de servicio DHCP para las redes internas. Red: Representa un dominio de colisión aislado de capa 2 y virtual. En el contexto Cloud muchas veces se visualiza una red como un switch virtual o lógico. Subred: Representa un bloque de direcciones IPv4 o IPv6 que podrán ser asignadas a las instancias en una red anteriormente creada. 17

40 Puerto: Representa un puerto del switch virtual o lógico de una red determinada. vnic: Representa una interfaz virtual de una instancia. Características principales de Neutron [8]: Neutron controla todo los aspectos de red de la infraestructura virtual de red (VNI "Virtual Network- ing Infrastructure") y solo el acceso a la infraestructura física de red (PNI Physical Networking Infrastruc- ture) en un sistema OpenStack. Los plug-ins y agentes de neutron son los que realmente ejecutan tareas de red específicas como el direccionamiento IP, conexión/desconexión de puertos y creación de redes y subredes. Otros plugins y agentes puede añadir funcionalidades avanzadas en las redes virtuales para ser consumidas por los clientes. Como ejemplo tenemos firewalls, balaceadores de carga y VPNs (Virtual private networks). Todas las instalaciones tienen al menos una red externa, que no es realmente virtual (aunque en nuestro proyecto si que es virtual y está en el namespace o espacio de nombres del "sistema host"). Dicha red externa representa un grupo de las direcciones IP disponibles en la red "física" externa. El resto de redes de Neutron son consideradas internas y están asociadas a un Tenant determinado. Se pueden asignar direcciones IP de redes externas a puertos en redes internas. En términos Cloud, si un dispositivo está conectado a una subred dicha conexión también se conoce como puerto. El componente neutron-server acepta peticiones a su API y las dirige al plug-in adecuado. Se comunica con KeyStone para lograr autenticación y con nova-compute para desplegar redes virtuales donde se conectan las instancias. El esquema siguiente muestra una conexión ya creada entre la vnic de la instancia y el puerto de la red virtual. Seguidamente, explicaremos los pasos asociados a dicha conexión. vnics Instancia A Puertos virtuales Instancia B Red-int /24 Red virtual L2 Subred virtual Figure 2.8: Redes virtuales e instancias. 1. Un tenant crea una red interna (Ejemplo: "Red-int-1"). 2. El tenant asocia una subred con dicha red (Ejemplo: " /24"). 3. El tenant levanta una instancia, especificando una vnic conectada a "Red-int-1" (Ejemplo: nova boot-image <image_name> -nic net-id=<id_of_red-int-1> <server_name>). 4. Nova contacta con Neutron para que cree un puerto en la red "Red-int-1". 5. Neutron crea el puerto y le asigna una IP. Normalmente en redes internas la asignación se hace a través del agente DCHP. Si el tenant decide eliminar la instancia 6. El tenant elimina la instancia. 18

41 7. Nova contacta con Neutron para que destruya el puerto anteriormente creado. Neutron destruye el puerto y devuelve su antigua IP al grupo de IPs disponibles para asignar. Neutron soporta "Grupos de seguridad" (Security Groups) que permiten al administrador definir reglas de firewall para dichos grupos. Una instancia puede pertenecer a uno o más "Grupos de seguridad". Las reglas más comunes son el bloqueo de puertos y bloque de determinados tipos de tráficos. Todas las instalaciones de Neutron usan un plug-in núcleo (core plug-in) y un plug-in que implementa los "Grupos de seguridad" (security group plug-in). Si no se necesitan los "Grupos de seguridad" se debe usar el "No-Op sercurity group plug-in". La cola funciona como un eje central para el paso de mensajes entre neutron-server, plug-ins y agentes. Implementaremos la cola con RabbitMQ. La pequeña base de datos sirve para almacenar el estado de la red y es necesaria para algunos plug-ins. Neutron soporta una arquitectura de red SDN, pero delega la implementación exacta a un plug-in determinado. En la segunda parte de nuestro proyecto configuraremos el plug-in del controlador SDN OpenDaylight Swift Object Storage Swift se encargar de almacenar y recuperar objetos de datos a través del "Sistema de almacenamiento de objetos". No estará incluido en nuestra instalación de OpenStack. La figura 2.9 muestra los componentes de Swift y las relaciones con componentes del resto de servicios. Usuarios de OpenStack HTTP(S) API de objetos Keystone API de identificación Swift Object Storage swift-proxy API de objetos horizon API de objetos account container object glance-api Base de datos de cuentas Base de datos de contenedores Almacen de objetos Figure 2.9: Componentes y relaciones del servicio Swift. Primeramente paso a explicar las características que definen a los objetos y a su sistema: La jerarquía del sistema de objetos es muy diferente a la jerarquía de un sistema de ficheros. En general, el sistema de objetos se divide en Cuenta, Contenedor y Objetos. Una Cuenta representa el máximo nivel de jerarquía y define un espacio de nombres para los contenedores. En OpenStack una cuenta es sinónimo de proyecto o cliente. Un Contenedor define un espacio de nombres para objetos. Un objeto con el mismo nombre en dos contenedores diferentes representa dos objetos. Un Objeto es una entidad que almacena información como un documento, imagen o fichero. Posee meta-datos extendidos asociados al datos que contiene y tienen un identificador único que permite su recuperación sin conocer su ubicación física. 19

42 Es posible comparar el almacenamiento de objetos con el estacionamiento de un hotel. El cliente intercambia las llaves de su auto por un recibo y no conoce donde se aparcará su coche o cuantas veces será movido de lugar. En este ejemplo, el identificador único de los objetos está representado por el recibo. Características principales de Swift: El componente swift-proxy acepta peticiones a través de la API de objetos de OpenStack y a través de una API REST genérica accesible para los clientes. Las peticiones pueden ser subidas de ficheros, modificación de meta-datos o creación de contenedores. Por otra parte, el swift-proxy puede servir ficheros y un listado de objetos al navegador del cliente. Swift-proxy se autentica a través de KeyStone y normalmente se comunica con glance-api ya que puede almacenar sus imágenes. Si proxy-server recibe muchas peticiones podemos añadir una caché opcional, normalmente implementada con memcache. El servidor de cuentas (account-server) maneja las cuentas relacionadas con el sistema de objetos. El servidor de contenedores (container-server) maneja los contenedores relacionados con el sistema de objetos. Los contenedores de objetos también son conocidos como carpetas. El servidor de objetos (object-server) maneja los objetos en los nodos de almacenamiento. Swift utiliza procesos internos como autorreplicación, autorreparación de datos y balanceo de carga para garantizar la consistencia y disponibilidad de datos en el cluster de almacenamiento. Los principales usos de Swift dentro de la infraestructura de OpenStack han sido albergar imágenes de Glance y los posibles backups de volúmenes Cinder. Por supuesto también es posible proveer un servicio de almacenamiento de objetos al cliente para guardar datos de carácter estático Cinder Block Storage Cinder provee de almacenamiento en bloque a las instancias alojadas en la nube. No estará incluido en nuestra instalación de OpenStack. La figura 2.10 muestra los componentes de Cinder y las relaciones con componentes del resto de servicios. Usuarios de OpenStack API de almacenamiento en bloque Keystone API de identificación cinder-api Cinder Block Storage API de almacenamiento en bloque horizon Cola AMQP cinder-volume Almacén de volúmenes (CEPH,GlusterFS LVM local, etc) AMQP cinder-sheduler Base de datos de Cinder Figure 2.10: Componentes y relaciones del servicio Cinder. Primeramente paso a explicar las características que definen al almacenamiento en bloque. El almacenamiento en bloques también se conoce como almacenamiento de volúmenes. Los usuarios interactúan con este tipo de almacenamiento vinculando volúmenes a las instancias en ejecución. 20

43 Los volúmenes son persistentes, es decir podemos desvincular un volumen de una instancia y vincularlo a otra y los datos se mantienen intactos. Usualmente se compara el almacenamiento en bloques con la funcionalidad de un pendrive o un disco duro externo. Los volúmenes se usan en escenarios de alto nivel de desempeño como bases de datos de aplicaciones. Características principales de Cinder: El API de almacenamiento en bloque de OpenStack permite la manipulación de volúmenes, elegir un tipo de volúmen disponible y hacer snapshots de ellos. El componente cinder-api acepta las peticiones del API y las enruta hacia el componente cinder-volume para ser procesadas. Es el responsable de la autenticación a través de KeyStone. El componente cinder-volume lee y escribe en la base de datos de Cinder para mantener el estado de los volúmenes. También interactúa con el componente cinder-sheduler a través de la cola de mensajes. Finalmente cinder-volume se comunica con el "driver" de backend utilizado en el almacén de objetos. El componente cinder-scheduler selecciona el proveedor óptimo de almacenamiento de bloques para crear un volumen determinado. Su función es similar a la realizada por nova-sheduler. La cola funciona como un eje central para el paso de mensajes entre cinder-volume y cinder-sheduler. La base de datos guarda el estado de los volúmenes. Cinder usa por defecto LVM de backend para proveer los volúmenes. Podemos cambiar el backend del almacén de volúmenes usando drivers de terceros como CEPH, Red Hat Storage (GlusterFS), IBM XIV, HP Leftland, 3Par, etc. En este caso cinder-volume usará el protocolo iscsi para comunicarse con el API del driver específico Glance Image Storage Glance provee de un catálogo y repositorio de imágenes para ser usadas por las instancias. Constituye una parte fundamental y estará incluido en nuestra instalación de OpenStack. La figura 2.11 muestra los componentes de Glance y las relaciones con componentes del resto de servicios. Usuarios de OpenStack API de identificación Keystone API de imágenes nova-api API de imágenes nova-compute Base de datos de Glance glance-api API de imágenes glance-registry Glance Image Storage Almacén de Imágenes (Fyle System, S3,Swift,rdb) API de imágenes API de objetos horizon swift-proxy Figure 2.11: Componentes y relaciones del servicio Glance. Primeramente paso a explicar las características de las imágenes. Una imagen es un archivo único que contiene los contenidos y la estructura completa de un medio de almacenamiento. Las imágenes son utilizadas como medio de distribución de sistemas operativos y de snapshots de los mismos. Podemos definir una instancia como un sistema operativo en ejecución y un snapchot como la captura congelada de una instancia. 21

44 Características principales de Glance: El componente glance-api acepta las llamadas a su API para descubrir, almacenar y ofrecer imágenes. El componente glance-registry almacena, procesa y recupera los meta-datos de las imágenes (tamaño, tipo, etc). La base de datos de Glance almacena los meta-datos de las imágenes. Glance utiliza un repositorio o almacén de imágenes. Dicho almacén usualmente es Swift en un sistema Open- Stack, pero Glance soporta además: sistemas de ficheros normales, Amazon S3, RADOS, etc Ceilometer Telemetry Ceilometer monitoriza y recopila métricas de los servicios de OpenStack con propositos de escalabilidad, facturación, benchmarking y estadísticos. No estará incluido en nuestra instalación de OpenStack. La función de monitorización consiste en asignar agentes que realicen un sondeo al resto de servicios de Open- Stack, las peticiones son del tipo: carga de cpu usada por el cliente, congestión en la red actual, almacenamiento libre, etc. A su vez un colector realizará otro sondeo a los agentes para recopilar los datos actualizados. Si ciertos datos superan un umbral determinado (carga de cpu muy elevada) se dispara una alarma hacia el agente que enrutará la alarma hacia un agente de alarmas. La función de recopilación de métricas se refiere al constante almacenamiento de datos con fines estadísticos. El componente polling-agent se encarga de realizar el sondeo hacia el resto de servicios OpenStack y construir métricas. El componente notificaton-agent se encarga de escuchar las notificaciones desde la cola de mensajes y convertirlas en eventos y muestras. El componente collector se encarga del sondeo hacia los polling-agent y notification-agent para almacenar los datos de forma más centralizada. El componente api permite a los clientes hacer peticiones al collector para visualizar los datos. El componente alarming evalúa y notifica las alarmas generadas por los polling-agent según las políticas de alarmas Heat Orchestration Heat permite la orquestación de stacks de aplicaciones en la nube. Dichos stacks pueden estar compuestas por servicios de distintos proveedores Cloud. No estará incluido en nuestra instalación de OpenStack. Sus características son: Los Stacks se describen con un lenguaje descriptivo de plantillas con formato nativo HOT o con formato AWS CloudFormation de Amazon. Las plantillas se usan a través de la API REST de orquestación de OpenStack o a través de una API compatible con AWS CloudFormation de Amazon. Incluye la orquestación de los diferentes recursos necesarios y sus dependencias. Permite el escalado automático de stacks basados en métricas configurables que recoge de la API de Ceilometer. 2.4 Flujo de peticiones para levantar una instancia Uno de los casos de uso más importante para entender el funcionamiento distribuido de OpenStack es el flujo de peticiones que se establece para levantar una instancia. La figura 2.12 muestra un esquema con las peticiones que se producen al lanzar una petición desde Horizon para levantar una instancia. 22

45 Horizon Keystone 4 5 DB Keystone Nova nova-api BD de Nova cola nova-sheduler nova-conductor 24 nova-compute hypervisor 25 glance-api Glance agentes de Neutron Neutron glance-registry BD de Glance neutron-server cola BD de Neutron Almacén de Imágenes plugins de Neutron cinder-api 26 Cola cinder-volume cinder-sheduler Cinder BD de Cinder Figure 2.12: Levantamiento de una instancia. 1. El usuario o tenant introduce sus credenciales en Horizon y este las envía a través del API REST de KeyStone para lograr la autenticación. 2. KeyStone autentica las credenciales y en la respuesta envía un token de autenticación que posteriormente podrá ser enviado en una petición a otros servicios. 3. El usuario ejecuta la opción "launch instance" y horizon envía una petición a la API REST de nova-api. 4. nova-api recibe la petición de Horizon y envía otra peticón a KeyStone para validar el token y conocer los permisos que tiene el usuario sobre los recursos de Nova. 5. KeyStone valida el token y envía un paquete con los roles y permisos que tiene el usuario. 6. nova-api interactúa con la base de datos de Nova. 7. La base de datos crea una nueva entrada para la instancia. 8. nova-api envía el mensaje "rpc-call" a nova-sheduler para obtener el "HOST ID" donde correrá la instancia y actualizar su entrada. 9. nova-sheduler recoge el mensaje desde la cola. 23

46 10. nova-sheduler interactúa con la base de datos de Nova para encontrar el mejor host disponible, luego de un proceso de filtrado y ponderación. 11. Luego de filtrar y ponderar los nodos de Cómputo disponibles nova-sheduler obtiene el "HOST ID" del mejor nodo disponible. 12. nova-sheduler envía el mensaje "rpc.cast" hacia nova-compute para lanzar la instancia en el host obtenido en el paso anterior. 13. nova-compute recoge el mensaje desde la cola. 14. nova-compute envía el mensaje "rpc.call" hacia nova-conductor para actualizar la información de la instancia: "HOST ID", y "flavor" (RAM, CPU, almacenamiento). 15. nova-conductor recoge el mensaje desde la cola. 16. nova-conductor interactúa con la base de datos de Nova. 17. nova-conductor recoge la información de la instancia actualizada de la base de datos. 18. nova-compute recoge la información de la instancia desde la cola. 19. nova-compute realiza una llamada a la API REST de glance-api pasando el token del usuario y el "Image ID" para obtener los meta-datos de la imagen como el URI donde se encuentra. 20. glance-api valida el token en KeyStone. 21. nova-compute recoge los meta-datos de la imagen (URI) y la descarga en su almacenamiento local. 22. nova-compute realiza una llamada a la API REST de neutron-server (quantum-server) pasando el token del usuario para configurar la red y la instancia pueda obtener una dirección IP. 23. neutron-server (quantum-server) valida el token en KeyStone. 24. nova-compute obtiene la información de red. 25. Si el servicio de Cinder está disponible nova-compute realiza una llamada a la API REST de cinder-api pasando el token del usuario y la tamaño de disco indicado en Horizon para vincular un volumen a la instancia. 26. cinder-api valida el token en KeyStone. 27. nova-compute obtiene la información del almacenamiento en bloques. 28. nova-compute genera una petición con todos los datos recopilados y la envía al Hipervisor para que levante la instancia (usando una API determinada, libvirt para KVM). 2.5 Otras tecnologías relacionadas con OpenStack En esta sección se explicarán algunas tecnologías de diversos campos que son vitales para comprender el complejo ecosistema Cloud. 24

47 2.5.1 Tecnologías de Cómputo La virtualización se refiere a la creación de máquinas virtuales que actúa como computadoras reales con un sistema operativo instalado. El software ejecutado en las máquinas virtuales debe estar aislado del software del sistema host. Actualmente existen tres grandes tipos de virtualización. 1. Virtualización completa: Está compuesta de tres capas principales: hardware, hipervisor e instancias del sistema operativo. El hipervisor interactúa con el hardware y mantiene cada servidor virtual aislado del resto servicios. El hipervisor consume bastantes recursos como RAM, CPU, etc. Cada instancia puede correr su propio sistema operativo y estos no necesitan ser modificados. KVM y XEN brindan soporte a este tipo de virtualización. La figura 2.13 muestra un esquema con las capas de la Virtualización completa. Figure 2.13: Virtualización completa. 25

48 2. Paravirtualización: La paravirtualización es similar a la virtualización completa, pero ahora los servidores virtuales "conocen" que están siendo virtualizados y trabajan junto a otros servidores virtuales. Por esta razón, la paravirtualización requiere cambios en el sistema operativo de las máquinas virtuales pero necesita menos recursos para la misma carga de trabajo. Es decir, la paravirtualización permite mayor escalabilidad a costa de algunos cambios en el sistema operativo Guest. En este caso el hipervisor se encuentra en la capa "Virtualization Software Layer". XEN brinda soporte a este tipo de virtualización. La figura 2.14 muestra un esquema con las capas de la Paravirtualización. Figure 2.14: Paravirtualización. 3. Virtualización a nivel de sistema operativo: Este tipo de virtualización no requiere ningún tipo de hipervisor ya que los mecanismos de virtualización forman parte del sistema operativo. Es el tipo de virtualización más escalable, ya que no necesita un hipervisor y las instancias son mucho más ligeras que los casos anteriores. Por otra parte, presenta la limitación de que el sistema operativo de la instancia debe ser igual al del Host. Los Contenedores LXC se enmarcan dentro de esta clasificación. La figura 2.15 muestra un esquema con las capas de la Virtualización a nivel de sistema operativo. Figure 2.15: Virtualización a nivel de sistema operativo. Nova Compute usa por defecto KVM como la tecnología de virtualización para levantar y mantener las instancias Cloud. KVM significa "Kernel Virtual Machine" y se vale de instrucciones integradas en el Kernel de Linux para ejecutar las tares de virtualización (el kernel actúa de hipervisor). El desarrollo de KVM es Open Source y ha día de hoy es la tecnología más idonea para desplegar OpenStack. Sin embargo, recientes estudios demuestran que el uso de Contenedores (como LXC o docker) en el Cloud aumentan la eficiencia permitiendo mayor número de instancias bajo el mismo número de nodos físicos de Cómputo. El problema es que los contenedores no están suficientemente testeados y aún no implementan algunos funciones importantes como la vinculación automática de volúmenes a una instancia [16] [17]. 26

49 2.5.2 Tecnologías de Redes Entre las tecnologías de redes se encuentran los túneles GRE y VXLAN usados en el plug-in ML2. Por otra parte se mencionaŕa OpenVswitch y los espacios de nombres de red (net namespaces). 1. Túneles GRE: GRE significa "Generic Routing Encapsulation" y define un protocolo para el establecimiento de túneles entre dos nodos no conectados directamente. El protocolo fue originalmente desarrollado por Cisco y permite transportar paquetes de una red concreta a través de otra red diferente. El ejemplo más común donde se usan los protocolos de túnel como GRE son para conectar oficinas de una misma empresa separadas geográficamente. En este caso el túnel IP viaja cifrado y se conoce como VPN. GRE tradicionalmente se ha usado para transportar una red IP interna sobre otra red IP externa sin cifrado. En el entorno de OpenStack los túneles Gre transportan red virtual IP sobre una red física IP, es decir conectan las instancias entre si y hacia los routers virtuales a través de diferentes hosts físicos. Por otra parte el campo "tunnel ID" de la cabecera GRE permite diferenciar entre redes de distintos tenants. 2. Túneles VXLAN: VXLAN significa "Virtual Extensible LAN" y define un protocolo para el establecimiento de túneles o redes superpuestas (overlay networks). VXLAN se desarrolló explícitamente en entornos de virtualización de redes en sistemas Cloud. Encapsula paquetes ethernet L2 dentro de paquetes UDP L4 a través de una técnica de etiquetado similar al VLAN. Básicamente, es usada para crear una red plana L2 para máquinas virtuales alojadas en diferentes hosts y redes físicas. VXLAN ejecuta la misma función que los túneles GRE, a través del plug-in ML2 conectar todas las instancias de un mismo tenant en una red virtual IP superpuesta a la red física IP. Los túneles VXLAN pueden escalar mejor que los GRE pero también son más complejos de configurar. 3. Veth: Veth significa "Virtual ethernet device" y es un dispositivo que emula un enlace ethernet virtual. Presenta dos extremos, normalmente uno en un sistema host y otro dentro de un espacio de nombres de red aislado. Todo los paquetes entran por un extremo salen automáticamente por el otro. 4. OpenVswitch: OpenVswitch (OVS) es sofware Open Source que funciona como uno switch virtual multicapa diseñado para comunicar las instancias virtuales en entornos de virtualización. Su principal uso ha sido reenviar el tráfico entre diferentes máquinas virtuales en el mismo host físico o de comunicar dichas máquinas virtuales con la red física. Entre las funcionalidades que soporta OpenVswitch podemos destacar: VLAN 802.1Q, puertos troncales y de acceso. NetFlow y sflow OpenFlow 1.0 y 1.3. STP. QoS Protocolos de tunel como GRE, VXLAN, IPsec. 5. Espacios de nombres de red (net namespaces): Un espacio de nombres (namespaces) es un contenedor abstracto que almacena nombres o identificadores únicos. El identificador definido en un espacio de nombres está asociado a dicho espacio de nombres. El mismo identificador puede ser definido en otros espacios de nombres pero identificará un objeto diferente. El kernel Linux da soporte para varios espacios de nombres como: PID namespaces (procesos), MNT namespaces (puntos de montaje) y NET namespaces (redes). De esta forma los espacios de nombres de red son un grupo determinado de direcciones IP, interfaces, tablas de rutas, reglas IPtables, etc que comparten todos los procesos dentro del espacio de nombres de red en cuestión. Por ejemplo, un contenedor LXC utiliza un espacio de nombres de red diferente a su sistema host y cada tenant tiene su propio espacio de nombres de red para sus redes privadas. 27

50 6. Flujo de red detallado en OpenStack El esquema de la figura 2.16 muestra el flujo de red que siguen los paquetes de una instancia en nuestra instalación OpenStack inicial, es decir con el plug-in ML2 OpenvSwitch y túneles GRE [7]. Figure 2.16: Flujo de red detallado. Nodo de Cómputo: Redes de las instancias (A,B,C): Desde la instancia sale un paquete por la interfaz virtual eth0, que está conectada a una interfaz TAP (tap0) en el nodo de Cómputo. tap0 está conectada a un switch linux (brctl) que actúa como firewall y por tanto es llamado "Switch firewall". nota: Idealmente, el tap0 debería conectarse directamente con el switch de integración (br-int) pero no se puede debido a la forma en que los grupos de seguridad de OpenStack están implementados. OpenStack usa reglas IPtables en los dispositivos TAP para implementar los grupos de seguridad y OpenvSwitch no es compatible con reglas IPtables que son aplicadas directamente en dispositivos TAP que están conectadas a un puerto de un switch OpenvSwitch, y por tanto necesitamos el switch firewall intermedio. Finalmente en el switch firewall hay conectada otra interfaz tap1 que también estará presenta en el br-int. Nodo de Cómputo: Switch de integración (D,E): El switch de integración "br-int" ejecuta un "VLAN tag" al tráfico que sale de las instancias y un "VLAN untag" al tráfico que se dirige a las instancias. Cada red interna Tenant creada con Neutron tiene su propia VLAN ID. br-int se conecta con br-tun a través de una interfaz especial de OpenvSwitch conocida como "patch-tun" (patch-tun es un concepto similar a un veth, pero no se visualiza con ifconfig). br-int se comporta como un switch normal que utiliza "MAC-learning". En caso de que la instancia "test0" envién un paquete con dirección MAC-destino a la instancia "test1" br-int la encaminará directamente si ya conocía dicha MAC-destino. Nodo de Cómputo: Switch tunel (F,G) El switch tunel (br-tun) traduce el tráfico etiquetado con VLANs que viene desde el br-int en tráfico GRE etiquetado con un "Tunel ID" específico. Cada VLAN ID tiene asociado solo un TUNNEL ID, por tanto 28

51 para cada red interna tenant tenemos un TUNNEL ID y un VLAN ID. También realiza la operación inversa, es decir, todo el tráfico que viene por el tunel GRE con el TUNNEL ID 1 se traduce en tráfico VLAN ID 1 enviado al br-int. La traducción es realizada por reglas OpenFlow instaladas en br-tun. En caso de que una instancia se levante en un nuevo nodo de Cómputo el switch br-tun de dicho nodo creará un nuevo tunel GRE entre su br-tun y cada br-tun existente anteriormente. En otras palabras, se formará una red completamente mallada de túneles GRE entre switches br-tun de todos los nodos de Cómputo y de Red. br-tun también se comporta como un switch normal que usa "MAC-learning". Con el añadido de mirar los VLAN ID y reenviar el paquete solo por los TUNNEL ID asociados. nota: Como tenemos reglas OpenFlow en el switch br-tun se puede decir que Neutron es una especie de "Pseudo-Controlador SDN", ya que a través del plug-in ML2 y el agente-openvswitch se ordena a un switch OpenvSwitch utilizar reglas OpenFlow para controlar el tráfico. Para mirar las tablas de flujo OpenFlow se puede ejecutar el comando "ovs-ofctl dump-flows br-tun" en los nodos de Red y de Cómputo. Nodo de Red: Switch tunel (H,I) El tráfico llega al nodo de Red a través del tunel GRE unido al switch br-tun. En este caso, el br-tun del nodo de Red tiene reglas OpenFlow similares al br-tun del nodo de Cómputo, pero en este caso las reglas separan el tráfico destinado al servidor dhcp (MAC_DST=DHCP_MAC) del tráfico destinado al router virtual (MAC_DST=DHCP_Router) ya que ambos componentes corren en espacios de red diferentes. Como en el caso anterior, br-tun se conecta a br-int a través de un "patch-tun". Nodo de Red: Switch de integración Este switch sirva para conectar las instancias a los servicios de red como los routers virtuales y servidores DHCP. Nodo de Red: Servidor DHCP (O,P) Cada red privada interna en la cual habilitamos DHCP tiene un servidor DHCP corriendo en el nodo de Red. El servidor DHCP es una instancia de dnsmasq corriendo dentro de un espacio de nombres de red. Se conecta al br-int a través de una interfaz TAP. Nodo de Red: Router (M,N) Un router virtual es un espacio de nombres de red con una tabla de rutas y reglas IPtables que garantizan el enrutamiento entre subredes. Dentro del router tenemos dos interfaces TAP, una se conecta al br-int y la otra se conecta al br-ex como gateway. Dentro de este espacio de nombres tenemos una tabla NAT netfilter responsable de asociar las IPs flotantes de las instancias con las IP privadas internas. Por defecto también tenemos una regla SNAT que permite a las instancias el acceso externo aún sin usar una IP flotante. Nodo de Red: Tráfico externo (K,L) El tráfico externo viaja hacia br-ex a través de una interfaz tap en el espacio de nombres del router virtual Tecnologías de Almacenamiento En este apartado mencionaremos los tipos de almacenamiento y los backends Open Source que tenemos disponibles para OpenStack. Como una primera clasificación tenemos: 1. Almacenamiento efímero: En un almacenamiento efímero los datos del usuario se pierden cuando la instancia se termina. Si solo desplegamos Nova el usuario solo tendrá el almacenamiento efímero. 2. Almacenamiento persistente: El almacenamiento persistente permite que los datos del usuario se guarden al terminar una instancia. OpenStack soporta dos tipos de almacenamiento persistente: (a) Almacenamiento de objetos: El objeto almacena una pieza de información con metadatos extendidos y está identificado por un ID único que permite su recuperación. Los meta-datos se definen a conveniencia como la confidencialidad, el objetivo, tipo, etc. Se usa principalmente para almacenar información estática como fotos, vídeos, backups de discos, imágenes iso, contenido web estático, etc. Es la tecnología de 29

52 almacenamiento más escalable y accesible (normalmente se accede mediante una API REST). Por otra parte el almacenamiento de objetos es "eventualmente consistente", es decir no garantiza que una petición de lectura devuelva la versión más actualizada, por lo que es idónea para un tipo de datos estáticos que no se modifican a menudo. Como ejemplo de uso podemos citar las imágenes subidas a Facebook y las canciones de Spotify. En Open- Stack swift controla el almacenamiento de objetos, implementado en un cluster o red de almacenamiento distribuido. La figura 2.17 muestra como el almacenamiento de objetos trata la información. Figure 2.17: Almacenamiento de objetos. (b) Almacenamiento de bloques: En el almacenamiento de bloques los ficheros se dividen en pequeños bloques de datos, cada uno con su propia dirección pero sin meta-datos asociados. A diferencia del caso anterior, el almacenamiento de bloques permite editar una parte de un fichero (un grupo de bloques determinados) sin tener que editar la parte restante. Puede ser accedido fácilmente por el sistema operativo como un volumen de disco montado. Se usa principalmente para información transaccional como sistemas de bases de datos. Se considera "fuertemente consistente", es decir garantiza que una petición de lectura devuelva la versión más actualizada. Como ejemplo de uso citamos las redes de almacenamiento internas de grandes corporaciones con arquitectura SAN. En OpenStack Cinder controla el almacenamiento de bloques. La figura 2.19 muestra como el almacenamiento de bloques trata la información. A continuación se muestra una tabla con los principales backends para el almacenamiento que soporta OpenStack [19]: La tecnología Ceph merece atención especial. Consiste en una plataforma que soporta bloques, archivos y objetos en un cluster distribuido. En una instalación de OpenStack podríamos centralizar el trabajo de replicación, consistencia y disponibilidad de todo tipo de almacenamiento en esta herramienta. La figura 2.20 muestra como Ceph se integra con OpenStack. 30

53 Figure 2.18: Almacenamiento de bloques. Figure 2.19: Almacenamiento de bloques Tecnologia de Colas de mensajes En los servicios Nova, Cinder y Neutron se utiliza AMQP como tecnología de mensajes. La cola de mensajes proporciona las siguientes ventajas a un sistema distribuido como son Nova, Cinder y Neutron dentro de OpenStack: Redundancia: Si se produce el fallo de un servicio mientras procesa una petición dicha petición no se perderá, ya que la cola almacena el mensaje hasta que el mismo sea procesado por completo. Naturaleza asíncrona: En muchas ocasiones los sistemas distribuidos necesitan que los mensajes se vayan acumulando para procesarlos en lotes, la cola irá manteniendo los mensajes hasta que el servicio decida su procesamiento de acuerdo a su programación. Garantía de entrega y ordenamiento: Se garantiza que el orden en el que llegan los mensajes será el orden en el que sean procesados a través del tipo de cola FIFO. Disponibilidad: Si parte de la arquitectura falla, los mensajes no se perderán ya que estos seguirán en la cola hasta que se les indique lo contrario, al mismo tiempo la cola podrá seguir recibiendo mensajes para el procesamiento posterior a la recuperación del sistema. 31

54 Figure 2.20: Ceph y OpenStack. Elasticidad: Si el sistema llega al tope de capacidad de recepción de peticiones y se vuelve incapaz de responder por un anormal flujo de mensajes, el hecho de tener una cola o buffer de peticiones permitirá balancear, filtrar y normalizar el flujo. Desacoplamiento: La cola actúa como una capa intermedia de comunicación entre los servicios brindando flexibilidad en la definición de los servicios. Cada servicio tan solo debe mantenerse alineado con los requerimientos de la interfaz de la cola de mensajes. Escalabilidad: Al agregar más unidades de procesamiento al sistema (más nodos para el mismo servicio) la cola de mensajes se encargará de balancear la carga entre todos los nodos. 2.6 Servicios en desarrollo de OpenStack Para terminar me gustaría mencionar los nuevos servicios que se están gestando en el desarrollo de OpenStack. Trove Database as a service : Tiene como objetivo proveer bajo demanda de bases de datos de forma escalable, tanto para base de datos relacionales como no relacionales. Sahara Data Processing as a service : Tiene como objetivo proveer bajo demanda de clusters para procesar grandes grupos de datos, usando Hadoop o Spark. Ironic Bare Metal as a service : Tiene como objetivo proveer bajo demanda de servidores físicos en vez de máquinas virtuales. (MaaS) Zaqar Messagin as a service : Tiene como objetivo proveer bajo demanda de colas de mensajes. Principalmente pensado para que desarrolladores puedan conectar sus aplicaciones móviles y SaaS. Designate DNS as a service : Tiene como objetivo proveer bajo demanda de servidores DNS. Manila Shared filesystem as a service : Tiene como objetivo proveer bajo demanda de sistemas de ficheros compartidos. 32

55 Chapter 3 Despligue de OpenStack 3.1 Entorno de desarrollo Para realizar un despliegue real de OpenStack se necesita una gran cantidad de servidores físicos que actúen como nodos. Cada nodo llevará un rol dentro de la infraestructura Cloud siendo los más usados: Nodo Controlador, Nodo de Red, Nodo de Cómputo, Nodo de Almacenamiento en Bloque y Nodo de Almacenamiento de Objetos. Como solo disponemos de un portátil para el proyecto se ha elegido la infraestructura virtual más básica que permite emular un sistema de OpenStack en producción. Dicha infraestructura virtual está compuesta por: 1 nodo controlador con hostname "controller". 1 nodo de red con hostname "network". 1 nodo de cómputo con hostname "compute". Por otra parte se ha intentado usar contenedores linux LXC para emular los nodos y disminuir aún más la carga sobre el sistema operativo del portátil. Sin embargo, el nodo de cómputo, cuya función es levantar máquinas virtuales KVM, no ha podido emularse correctamente a través de un contenedor LXC ya que esta tecnología aún no soporta la virtualización KVM anidada dentro de sus contenedores. Para el nodo de cómputo finalmente hemos optado por una virtualización KVM directa, ya que KVM si soporta virtualización anidada de otras máquinas virtuales KVM. Para conectar los 3 nodos en las distintas redes se ha utilizado la herramienta OpenvSwitch. La figura 3.1 muestra un esquema resumen del entorno de desarrollo. Nodo controller Nodo network Nodo compute Horizon Glance SQL MariaDB nova-sheduler Neutron-pluginopenvswitch-agent Neutron-pluginopenvswitch-agent Cola de Mensajes RabbitMQ NTP Keystone nova-api neutron-server Contenedor LXC neutronplugin-ml2 neutron-dhcpagent neutron-l3- agent Metadata-netagent neutronplugin-ml2 OpenvSwitch Contenedor LXC OpenvSwitch nova-compute OpenvSwitch Hypervisor KVM neutronplugin-ml2 Máquina virtual KVM Figure 3.1: Entorno de Desarrollo I. 33

56 En el nodo Controlador instalaremos todos los subservicios cuya función es servir de proxi o referencia para el resto de servicios, por ejemplo nova-api y neutron-server. También se instalarán los servicios auxiliares NTP, RabbitMQ y la base de datos MariaDB. Por último instalaremos todos los servicios que no tengan que ver con la virtualización o las redes: Horizon, Glance y Keystone en nuestro caso. En el nodo de Red instalaremos los agentes "neutron-l3-agent", "neutron-dhcp-agent". Además se instalará el plugin ML2 y el driver y agente openvswitch. En el nodo de Cómputo instalaremos el plugin ML2, el driver y agente openvswitch para conectar las instancias, el subservicio nova-compute y el hipervisor KVM que levantará realmente las instancias. 3.2 Despliegue de Infraestructura inicial En este apartado se realizará el despliegue de la infraestructura inicial básica que comprende la configuración de los dos contenedores LXC y la máquina virtual KVM, así como la conexión de red entre ellos a través de OpenvSwitch en el espacio de nombres de red (net namespaces) de nuestro sistema "host". Para lograr la comunicación entre todos los nodos y hacia nuestro espacio de nombres de red se ha utilizado la siguiente configuración mostrada en la figura 3.2. Red de Gestión ( ) Red Tunel ( ) Red Externa ( ) Red LXC ( ) Red KVM ( ) Host net namespace wlan0 NAT(IPtable) Par veth Par veth eth0-control eth0-network vnet0 OpenvSwitch Switch br-man Par veth eth1-control vnet1 Par veth eth1-network eth0 eth1 eth0 eth1 eth1 eth0 Nodo controller Nodo network Nodo compute eth3 eth2 Switch br-tunnel eth eth2-network vnet Par veth Switch br-out Par veth eth3-network tap Figure 3.2: Infraestructura de Red I. La red de gestión ( ) transporta los paquetes de gestión de los nodos (meta-datos, configuraciones, etc). La red Tunel ( ) transporta el tráfico de red de las instancias creadas en el nodo de Cómputo. La red externa 34

57 ( ) otorga acceso externo a las instancias. Para nuestro proyecto conectamos la red externa a una interfaz virtual tap0 en nuestro espacio de nombres de red (net namespace) para poder hacer ping desde nuestro sistema "host" a las instancias. La red LXC y KVM son las que vienen por defecto y se han mantenido para proveer de acceso a internet a los nodos e instalar todos los paquetes necesarios. El direccionamiento de los nodos se realiza por defecto mediante DHCP a través de dnsmasq. Dichas redes hacen NAT con la interfaz inalámbrica wlan0 para acceder a la red local y posteriormente a internet. Los nodos basados en contenedores LXC (Controlador y de Red) se conectan con nuestro espacio de nombres de red a través de un par veth en cada interfaz. Finalmente, la conexión de cada nodo en las redes se realiza a través de un switch openvswitch en nuestra espacio de nombres, tal como muestra la figura anterior. Todos los comandos que se ejecutarán en los próximos apartados se realizarán con permisos de superusuario. El nombre del portatil es "host" y presenta un sistema operativo Linux Mint 17, compatible con Ubuntu Instalación y configuración de LXC para el nodo de Red y el nodo Controlador 1. Instalamos la herramienta LXC [23] [24]. root@host: apt-get install lxc Una vez terminada la instalación se crean ficheros de configuración en las siguientes rutas: Ruta del fichero /var/lib/lxc /etc/lxc/ /usr/share/lxc/templates/ /usr/share/lxc/selinux/ /var/log/lxc/ /etc/default/lxc-net /etc/init/lxc-net.conf Función Lugar de almacenamiento de contenedores Fichero de configuracion principal Lugar de almacenamiento de los templates Configuración de selinux Logs de lxc Configuración de red de los contenedores Script que se habilita con el fichero de configuración de red Table 3.1: Ficheros de configuración de LXC. 2. Creamos dos contenedores basados en ubuntu 14.04, con la plantilla "download" y arquitectura amd64. Uno llamado "network" y otro "controller". root@host: lxc-create -t download -n network -- --dist ubuntu --release trusty \ --arch amd64 root@host: lxc-create -t download -n controller -- --dist ubuntu --release trusty \ --arch amd64 3. Configuramos los parámetros de red según el esquema de la figura 3.2 para ambos nodos. El fichero se encuentra en la ruta /var/lib/lxc/<nodo>/config. # Path /var/lib/lxc/controller/config # Distribution configuration lxc.include = /usr/share/lxc/config/ubuntu.common.conf lxc.arch = x86_64 # Container specific configuration lxc.rootfs = /var/lib/lxc/controller/rootfs lxc.utsname = controller # Network configuration 35

58 lxc.network.type = veth lxc.network.flags = up lxc.network.link = lxcbr0 lxc.network.hwaddr = 00:16:3e:57:b5:ca lxc.network.veth.pair = eth0-control #OpenStack infrastructure lxc.network.type = veth lxc.network.flags = up lxc.network.veth.pair = eth1-control lxc.network.ipv4 = /24 # Path /var/lib/lxc/network/config # Distribution configuration lxc.include = /usr/share/lxc/config/ubuntu.common.conf lxc.arch = x86_64 # Container specific configuration lxc.rootfs = /var/lib/lxc/network/rootfs lxc.utsname = network # Network configuration lxc.network.type = veth lxc.network.flags = up lxc.network.link = lxcbr0 lxc.network.hwaddr = 00:16:3e:5e:06:09 lxc.rootfs = /var/lib/lxc/network/rootfs lxc.network.veth.pair = eth0-network #OpenStack infrastructure lxc.network.type = veth lxc.network.flags = up lxc.network.veth.pair = eth1-network lxc.network.ipv4 = /24 lxc.network.type = veth lxc.network.flags = up lxc.network.veth.pair = eth2-network lxc.network.ipv4 = /24 lxc.network.type = veth lxc.network.flags = up lxc.network.veth.pair = eth3-network #Disable AppArmor for LXC container lxc.mount.auto = cgroup lxc.aa_profile = unconfined Las dos últimas líneas en el fichero del contenedor del nodo de Red inhabilitan el uso de AppArmor (SeLinux de Ubuntu) para permitir a Neutron la creación de nuevos espacios de nombres de red. 4. Abrimos una consola nueva para cada nodo, iniciamos los contenedores en background y accedemos a su sistema para comprobar que se han iniciado correctamente. root@host: lxc-start -n network -d root@host: lxc-attach -n network root@host: lxc-start -n controller -d root@host: lxc-attach -n controller 5. Los contenedores se pueden parar apagando su sistema o ejecutando el siguiente comando desde el "host". 36

59 lxc-stop -n controller lxc-stop -n network 6. En la consola del "host" podemos listar los contenedores que hemos creado con el siguiente comando: lxc-ls 7. En la página x del apéndice podemos encontrar documentación detallada de la herramienta LXC Instalación y configuración la máquina virtual KVM para el nodo de Cómputo 1. Instalamos Ubuntu en una máquina virtual (en el proyecto se usó la herramienta virt-manager). 2. Con la herramienta virt-manager, en el apartado de interfaces de red, creamos dos interfaces nuevas (en total tendremos tres interfaces). 3. Entramos a la máquina virtual y configuramos su fichero /etc/network/interfaces de la siguiente forma: # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet dhcp #Compute node interfaces auto eth1 iface eth1 inet static address netmask auto eth2 iface eth2 inet static address netmask En el sistema "host" las 2 interfaces virtuales del nodo de Cómputo se ven como vnet1 y vnet2. Por defecto KVM las conecta a través del bridge virbr0 usando la herramienta "brctl". Como nuestro objetivo es usar OpenvSwitch para crear las redes de OpenStack debemos eliminar dichas interfaces del puerto virbr0. root@host: brctl delif virbr0 vnet1 root@host: brctl delif virbr0 vnet2 Cada vez que se reinicie la máquina virtual del nodo de Cómputo es necesario eliminar las interfaces del switch virbr0 con los comandos anteriores y reiniciar el servicio de OpenvSwitch con el siguiente comando. root@host: service openvswitch-switch restart 37

60 3.2.3 Instalación y configuración de OpenvSwitch para conectar los nodos 1. Instalamos la herramienta OpenvSwitch. root@host: apt-get install openvswitch-switch openvswitch-common 2. Con los trees nodos ya iniciados añadimos el bridge br-man y conectamos las interfaces según el esquema de red 3.2. root@host: ovs-vsctl add-br br-man root@host: ovs-vsctl add-port br-man eth1-network root@host: ovs-vsctl add-port br-man eth1-control root@host: ovs-vsctl add-port br-man vnet1 Añadimos el bridge br-tunnel y conectamos las interfaces según el esquema de red 3.2. root@host: ovs-vsctl add-br br-tunnel root@host: ovs-vsctl add-port br-tunnel eth2-network root@host: ovs-vsctl add-port br-tunnel vnet2 3. Creamos la interfaz tap0 y la conectamos con la interfaz eth3-network a través del switch virtual br-out. De esta forma podremos comprobar la configuración de la red externa de las instancias. root@host: ip tuntap add name tap0 mode tap root@host: ovs-vsctl add-br br-out root@host: ovs-vsctl add-port br-out tap0 root@host: ovs-vsctl add-port br-out eth3-network root@host: ifconfig tap0 promisc root@host: ifconfig eth3-network promisc root@host: ifconfig tap La interfaz tap0 y eth3-network se deben encontrar en modo promiscuo. 4. Los siguientes comandos sirven para comprobar la correcta configuración de OpenvSwitch Muestra la configuración de todos los switchs virtuales de OpenvSwitch. root@host: ovs-vsctl show Muestra las interfaces de un switch OpenvSwitch, en este caso br-man. root@host: ovs-vsctl list-ports br-man Reinica el servicio de OpenvSwitch root@host: service openvswitch-switch restart 5. Por defecto, en la distribución Linux Mint 17 la herramienta NetworkManager intenta reconfigurar las interfaces del sistema "host" provocando cambios en las configuraciones de red. Para evitar que NetworkManager modifique nuestras interfaces debemos mencionar todas las interfaces implicadas en el proyecto en el fichero /etc/network/interfaces. También se incluirá en el fichero la interfaz tap0 para que se levante automáticamente en el inicio de la máquina host. A continuación se presenta el fichero /etc/network/interfaces. 38

61 #auto eth0 #iface eth0 inet dhcp #Bridges from OVS auto br-man iface br-man inet static address netmask auto br-tunnel iface br-tunnel inet static address netmask #Avoid NetworkManager problem. iface vnet1 inet static iface eth1-control inet static iface eth1-network inet static iface vnet2 inet static iface eth2-network inet static iface eth3-network inet static iface eth0-control inet static iface eth0-network inet static #Testing the network for instances auto br-out iface br-out inet static address netmask auto tap0 iface tap0 inet static address netmask Llegados a este punto es recomendable pausar los contenedores y la máquina virtual, reiniciar el sistema "host" y arrancar nuevamente los nodos para comprobar que las configuraciones se han realizado correctamente. Una vez comprobados todos los parámetros se podrá continuar al siguiente apartado. 3.3 Despliegue de OpenStack El despliegue de OpenStack se entiende como la configuración de los nodos del sistema Cloud y se espera que el sistema "host" se encuentre ya correctamente configurado. El despliegue se ha basado en la guía oficial de OpenStack para nodos físicos [18]. Para facilitar el despliegue se recomienda tener un terminal abierto para cada nodo y otro para el sistema "host". La tabl?? muestra los usuarios y contraseñas usados en el despliegue de OpenStack Entorno básico Antes de instalar los servicios principales de OpenStack es necesario instalar y configurar los servicios mínimos mostrados en los siguientes apartados. 39

62 Password RABBIT_PASS KEYSTONE_DBPASS DEMO_PASS ADMIN_PASS GLANCE_DBPASS GLANCE_PASS NOVA_DBPASS NOVA_PASS DASH_DBPASS NOVA_DBPASS NEUTRON_DBPASS NEUTRON_PASS Descripción Password de RabbitMQ Password de la BD de KeyStone Password del usuario "demo" Password del usuario "admin" Password de la BD de Glance Password para autenticarse en KeyStone Password de la BD de Nova Password para autenticarse en KeyStone Password de la BD de Horizon Password de la BD de Nova Password de la BD de Neutron Password para autenticarse en KeyStone Table 3.2: Ficheros de configuración de LXC Instalación y configuración de DNS y hostname Para instalar todos los paquetes de OpenStack es necesario que cada nodo tenga configurado un servidor DNS donde pueda resolver los nombres de dominio. Por otra parte, asignaremos los hostnames según el esquema de la figura 3.2. Nodo Controlador 1. Asignamos al nodo controlador el hostname "controller". root@hostname: hostname controller 2. Añadimos en el fichero /etc/hosts las direcciones IP de gestión de los nodos. Se debe remover o comentar la linea que comienza con #controller controller #network network #compute compute 3. En el fichero /etc/resolvconf/resolv.conf.d/base debemos añadir la dirección IP de un servidor DNS. Para nuestro proyecto hemos elegido OpenDNS por ofrecer el servicio gratuito y abierto. nameserver nameserver Finalmente ejecutamos el siguiente comando para actualizar el sistema con los nuevos servidores DNS. root@controller: resolvconf -u 4. Reiniciamos el sistema LXC. Nodo de Red 1. Asignamos al nodo de red el hostname "network". root@hostname: hostname network 40

63 2. Añadimos en el fichero /etc/hosts las direcciones IP de gestión de los nodos. Se debe remover o comentar la linea que comienza con #controller controller #network network #compute compute 3. En el fichero /etc/resolvconf/resolv.conf.d/base debemos añadir la dirección IP de un servidor DNS. Para nuestro proyecto hemos elegido OpenDNS por ofrecer el servicio gratuito y abierto. nameserver nameserver Finalmente ejecutamos el siguiente comando para actualizar el sistema con los nuevos servidores DNS. root@network: resolvconf -u 4. Ponemos la interfaz eth3 del nodo de Red en modo promiscuo. root@network: ifconfig eth3 promisc 5. Reiniciamos el sistema LXC. Nodo de Cómputo 1. Asignamos al nodo de Cómputo el hostname "compute". root@hostname: hostname compute 2. Añadimos en el fichero /etc/hosts las direcciones IP de gestión de los nodos. Se debe remover o comentar la linea que comienza con #controller controller #network network #compute compute 3. En el fichero /etc/resolvconf/resolv.conf.d/base debemos añadir la dirección IP de un servidor DNS. Para nuestro proyecto hemos elegido OpenDNS por ofrecer el servicio gratuito y abierto. nameserver nameserver Finalmente ejecutamos el siguiente comando para actualizar el sistema con los nuevos servidores DNS. root@compute: resolvconf -u 4. A diferencia de los nodos basados en LXC, en el nodo KVM debemos configurar las interfaces manualmente editando el fichero /etc/network/interfaces: # The loopback network interface auto lo iface lo inet loopback 41

64 # The primary network interface auto eth0 iface eth0 inet dhcp #Compute node interfaces from OpenStack auto eth1 iface eth1 inet static address netmask auto eth2 iface eth2 inet static address netmask Reiniciamos el sistema KVM. Verificación de la conectividad En este punto se recomienda verificar la conectividad mediante ping desde cada nodo hacia internet y hacia el resto de los nodos, tanto por la red de gestión como por la red tunel Instalación y configuración de NTP Para sincronizar los servicios principales debemos instalar el servicio NTP en cada nodo. El nodo Controlador será el de referencia para el nodo de Red y el nodo de Cómputo. Nodo Controlador 1. Instalamos el servicio NTP. root@controller: apt-get install ntp 2. Editamos el fichero /etc/ntp.conf y añadimos o cambiamos las siguientes lineas: server NTP_SERVER iburst restrict -4 default kod notrap nomodify restrict -6 default kod notrap nomodify Debemos reemplazar NTP_SERVER con el hostname o dirección IP de un servidor NTP público de internet. 3. Si existe el fichero /var/lib/ntp/ntp.conf.dhcp debemos eliminarlo. root@controller: rm /var/lib/ntp/ntp.conf.dhcp 4. Reiniciamos el servicio NTP. root@controller: service ntp restart Nodo de Red 1. Instalamos el servicio NTP. root@network: apt-get install ntp 2. Editamos el fichero /etc/ntp.conf y añadimos o cambiamos la linea que identifica el servidor. server controller iburst 42

65 3. Si existe el fichero /var/lib/ntp/ntp.conf.dhcp debemos eliminarlo. rm /var/lib/ntp/ntp.conf.dhcp 4. Reiniciamos el servicio NTP. service ntp restart Nodo de Cómputo 1. Instalamos el servicio NTP. apt-get install ntp 2. Editamos el fichero /etc/ntp.conf y añadimos o cambiamos la linea que identifica el servidor. server controller iburst 3. Si existe el fichero /var/lib/ntp/ntp.conf.dhcp debemos eliminarlo. root@compute: rm /var/lib/ntp/ntp.conf.dhcp 4. Reiniciamos el servicio NTP. root@compute: service ntp restart Instalación de los paquetes de OpenStack La instalación de los paquetes de OpenStack, mostrada en los pasos siguientes, debe realizarse en todos los nodos. 1. Instalamos el paquete "ubuntu-cloud-keyring" y añadimos el repositorio "cloudarchive-juno" en cada nodo. root@hostname: apt-get install ubuntu-cloud-keyring root@hostname: echo "deb \ "trusty-updates/juno main > /etc/apt/sources.list.d/cloudarchive-juno.list 2. Actualizamos todos los paquetes del sistema. root@hostname: apt-get update && apt-get upgrade Instalación y configuración de las bases de datos El servidor de base de datos que usarán los servicios principales estará alojado en el nodo Controlador. Para nuestro proyecto usaremos MariaDB debido a su filosofía Open Source y compatibilidad con MySQL. 1. Instalamos MariaDB. root@controller: apt-get install mariadb-server python-mysqldb 2. Seleccionamos el password. En nuestra instalación hemos usado los passwords encontrados en la tabla x. 3. Editamos el fichero /etc/mysql/my.cnf con las siguientes lineas: 43

66 [mysqld]... #bind-address = Controller ip address bind-address = default-storage-engine = innodb innodb_file_per_table collation-server = utf8_general_ci init-connect = 'SET NAMES utf8' 4. Reiniciamos el servicio. root@controller: service mysql restart 5. Protegemos el servicio. root@controller: mysql_secure_installation Instalación y configuración del servidor de colas Para el proyecto se usará el servidor de mensajes RabbitMQ y se alojará en el nodo Controlador. 1. Instalamos RabbitMQ. root@controller: apt-get install rabbitmq-server 2. Por defecto RabbitMQ crea una cuenta cuyo usuario y contraseña es "guest". Para cambiar la contraseña podemos usar el comando siguiente. root@controller: rabbitmqctl change_password guest RABBIT_PASS Para nuestro proyecto hemos usado la contraseña RABBIT_PASS Verificación En este apartado solo necesitamos comprobar que el servicio NTP está correctamente configurado. Nodo Controlador En el nodo Controlador debemos ejecutar los siguientes comandos: root@controller: ntpq -c peers En la salida por terminal la columna de la izquierda "remote" debe mostrar un o más servidores NTP externos. root@controller: ntpq -c assoc En la salida por terminal la columna "last_event" debe mostrar "sys_peer" al menos para un servidor. Nodos restantes En los nodos de Red y Cómputo debemos ejecutar los siguientes comandos: root@controller: ntpq -c peers En la salida por terminal la columna de la izquierda "remote" debe mostrar el hostname del nodo Controlador. root@controller: ntpq -c assoc En la salida por terminal la columna "last_event" debe mostrar "sys_peer". 44

67 Problemas encontrados No se encontraron problemas Instalación y configuración de KeyStone Como muestra el esquema de la figura 3.1 el servicio KeyStone se alojará en el nodo Controlador Configuración inicial 1. Accedemos a la base de datos mediante el usuario root. root@controller: mysql -u root -p 2. Creamos la base de datos "Keystone". mysql>: CREATE DATABASE keystone; 3. Permitimos el acceso a la base de datos con el password "KEYSTONE_DBPASS". mysql>: GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY \ 'KEYSTONE_DBPASS'; mysql>: GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' IDENTIFIED BY \ 'KEYSTONE_DBPASS'; 4. Salimos de la sesión MariaDB/MySQL. mysql>: exit; 5. Generamos un valor aleatorio como token de administración durante la configuración inicial. root@controller: openssl rand -hex Instalamos los paquetes de KeyStone. root@controller: apt-get install keystone python-keystoneclient 7. Editamos el fichero /etc/keystone/keystone.conf y añadimos o reemplazamos las siguientes lineas: [DEFAULT]... admin_token = ADMIN_TOKEN [database]... connection = mysql://keystone:keystone_dbpass@controller/keystone [token]... provider = keystone.token.providers.uuid.provider driver = keystone.token.persistence.backends.sql.token [revoke]... driver = keystone.contrib.revoke.backends.sql.revoke Debemos reemplazar ADMIN_TOKEN por el token anteriormente creado y KEYSTONE_DBPASS por la contraseña determinada por el usuario. 8. Rellenamos la base de datos creada con los parámetros de KeyStone. 45

68 su -s /bin/sh -c "keystone-manage db\_sync" keystone 9. Reiniciamos el servicio KeyStone. service keystone restart 10. Por defecto el paquete de Ubuntu crea una base de datos SQLite. Como usaremos la base de datos MariaDB podemos eliminar la SQLite. rm -f /var/lib/keystone/keystone.db 11. Por defecto KeyStone almacena tokens ya expirados de forma indefinida. Es recomendable usar la herramienta "cron" para programar la eliminación de tokens expirados cada hora. (crontab -l -u keystone 2>&1 grep -q token_flush) \ echo '@hourly /usr/bin/keystone-manage token_flush \ >/var/log/keystone/keystone-tokenflush.log 2>&1' \ >> /var/spool/cron/crontabs/keystone Creación de clientes, usuarios y roles Usaremos el token de administración temporal creado en el apartado anterior para configurar manualmente la ubicación (endpoint) de KeyStone y poder usar sus comandos. 1. Configuramos el token de administración. root@controller: export OS_SERVICE_TOKEN=ADMIN_TOKEN 2. Configuramos la ubicación de KeyStone. root@controller: export OS_SERVICE_ENDPOINT= 3. Creamos el cliente (tenant) "admin". root@controller: keystone tenant-create --name admin --description "Admin Tenant" 4. Creamos el usuario "admin". Como password se ha elegido "ADMIN_PASS" y como dirección de correo " _ADDRESS". root@controller: keystone user-create --name admin --pass ADMIN_PASS -- _ADDRESS 5. Creamos el rol "admin" root@controller: keystone role-create --name admin 6. Añadimos el rol "admin" al cliente "admin" y al usuario "admin". root@controller: keystone user-role-add --user admin --tenant admin --role admin Cad rol que creemos debe estar relacionado con los roles especificados en el fichero policy.json de cada servicio OpenStack. La política por defecto de la mayoría de los servicios otorgan acceso de administración al rol "admin". 46

69 7. Creamos el tenant "demo". keystone tenant-create --name demo --description "Demo Tenant" 8. Creamos el usuario "demo" dentro del tenant "demo". Como password se ha elegido "DEMO_PASS" y como dirección de correo " _ADDRESS2". root@controller: keystone user-create --name demo --tenant demo --pass DEMO_PASS \ -- _ADDRESS2 9. Finalmente creamos el tenant "service". Cada servicio requiere la creación de un usuario con el rol "admin" dentro del tenant "service". root@controller: keystone tenant-create --name service --description "Service Tenant" Creación de la entidad del servicio y API endpoints Luego de crear los clientes, usuarios y roles debemos crear la entidad de servicio y los "API endpoints" para KeyStone. 1. Exportamos el token de administración si aún no lo está. root@controller: export OS_SERVICE_TOKEN=ADMIN_TOKEN 2. Exportamos la ubicación de KeyStone si aún no lo está. root@controller: export OS_SERVICE_ENDPOINT= 3. Creamos la entidad de servicio para KeyStone para poder almacenar un catálogo de servicios y "API endpoints" de cada servicio. De esta forma los servicios de OpenStack pueden localizar el resto de servicios dentro del sistema Cloud. root@controller: keystone service-create --name keystone --type identity \ --description "OpenStack Identity" 4. Creamos los "API endpoints" para KeyStone. OpenStack provee 3 variaciones de "API endpoints": "admin", "internal" y "public". En un entorno de producción real las variantes deben residir en redes separadas por razones de seguridad. OpenStack además puede soportar múltiples regiones para aumentar la escalabilidad. En nuestra configuración solo usaremos la red de gestión para todos los "API endpoints" y la región "regionone". keystone endpoint-create \ --service-id $(keystone service-list awk '/ identity / {print $2}') \ --publicurl \ --internalurl \ --adminurl --region regionone Podemos ver que el acceso "admin" se realiza por el puerto mientras que el acceso a las APIs públicas e internas se realiza a través del puerto

70 Verificación Para verificar la correcta configuración de KeyStone debemos ejecutar los siguientes comandos y analizar la respuesta en la terminal. 1. Quitamos las variables globales. root@controller: unset OS_SERVICE_TOKEN OS_SERVICE_ENDPOINT 2. Usando el tenant "admin "y usuario "admin" pedimos un token de autenticación. root@controller: keystone --os-tenant-name admin --os-username admin \ --os-password ADMIN_PASS --os-auth-url token-get 3. Usando el tenant "admin "y usuario "admin" verificamos los tenants que están registrados en Horizon. root@controller: keystone --os-tenant-name admin --os-username admin \ --os-password ADMIN_PASS -os-auth-url tenant-list 4. Usando el tenant "admin "y usuario "admin" verificamos los usuarios que están registrados en Horizon. root@controller: keystone --os-tenant-name admin --os-username admin \ --os-password ADMIN_PASS --os-auth-url user-list 5. Usando el tenant "admin "y usuario "admin" verificamos los roles que están registrados en Horizon. root@controller: keystone --os-tenant-name admin --os-username admin \ --os-password ADMIN_PASS --os-auth-url role-list 6. Usando el tenant "demo "y usuario "demo" pedimos un token de autenticación. root@controller: keystone --os-tenant-name demo --os-username \ --os-password DEMO_PASS --os-auth-url token-get 7. Usando el tenant "demo "y usuario "demo" verificamos los usuarios que están registrados en Horizon. root@controller: keystone --os-tenant-name demo --os-username demo \ --os-password DEMO_PASS --os-auth-url user-list En este caso KeyStone debe responder indicando que el usuario no está autorizado Problemas encontrados Mientras instalábamos KeyStone tuvimos que parar el contenedor del nodo de Cómputo. Resulta que al iniciar nuevamente el contenedor y ejecutar un comando tenemos un error con la variable de entorno "LOCALE". Para resolver el problema tan solo debemos ejecutar el siguiente comando: root@controller: export LC_ALL=C Este problema se ha reiterado durante todo el proyecto. 48

71 Scripts OpenRC Para disminuir los pasos en la interacción con el cliente KeyStone OpenStack soporta los scripts de variables de entorno conocidos como OpenRC. 1. Creamos un fichero admin-openrc.sh y añadimos: export OS_TENANT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=ADMIN_PASS export OS_AUTH_URL= 2. Creamos un fichero demo-openrc.sh y añadimos: export OS_TENANT_NAME=demo export OS_USERNAME=demo export OS_PASSWORD=DEMO_PASS export OS_AUTH_URL= 3. Para cargar el script openrc con las variables de "admin" debemos ir a la carpeta donde creamos los ficheros anteriores y ejecutar el siguiente comando: root@controller: source admin-openrc.sh Instalación y configuración de Glance En este proyecto no se instalará Swift, así que las imágenes de Glance se almacenarán en la ruta /var/lib/glance/images/ del sistema de ficheros local del nodo Controlador. Para almacenar las imágenes se necesita de abundante espacio en disco, en nuestro caso el nodo Controlador está representado por un contenedor LXC que tiene todo su sistema de ficheros en la ruta /var/lib/lxc del sistema "host". Dicha ruta se encuentra dentro de la partición root del sistema "host" y presenta más de 100 GB libres en la actualidad. Es muy importante comprobar la capacidad destinada a las imágenes para no tener problemas de almacenamiento. Todas las configuraciones se realizan en el nodo Controlador Configuración Inicial 1. Accedemos a la base de datos mediante el usuario root. root@controller: mysql -u root -p 2. Creamos la base de datos "glance". mysql>: CREATE DATABASE glance; 3. Permitimos el acceso a la base de datos con el password "GLANCE_DBPASS". mysql>: GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' \ IDENTIFIED BY 'GLANCE_DBPASS'; mysql>: GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' IDENTIFIED BY 'GLANCE_DBPASS'; 4. Salimos de la sesión MariaDB/MySQL. mysql>: exit; 49

72 Integración en KeyStone 1. Cargamos el fichero admin-openrc.sh. source admin-openrc.sh 2. Creamos el usuario "glance" con el password "GLANCE_PASS". keystone user-create --name glance --pass GLANCE_PASS 3. Añadimos el rol "admin" al usuario "glance". keystone user-role-add --user glance --tenant service --role admin 4. Creamos la entidad de servicios "glance". keystone service-create --name glance --type image \ --description "OpenStack Image Service" 5. Creamos los "API endpoints" del servicio Glance. root@controller: keystone endpoint-create \ --service-id $(keystone service-list awk '/ image / {print $2}') \ --publicurl \ --internalurl \ --adminurl \ --region regionone Instalación de componentes de Glance 1. Instalamos los paquetes. root@controller: apt-get install glance python-glanceclient 2. Editamos el fichero /etc/glance/glance-api.conf y añadimos o reemplazamos las siguientes lineas: [database]... connection = mysql://glance:glance_dbpass@controller/glance [keystone_authtoken]... auth_uri = identity_uri = admin_tenant_name = service admin_user = glance admin_password = GLANCE_PASS [paste_deploy]... flavor = keystone [glance_store]... default_store = file filesystem_store_datadir = /var/lib/glance/images/ [DEFAULT]... notification_driver = noop verbose = True 50

73 3. Editamos el fichero /etc/glance/glance-registry.conf y añadimos o reemplazamos las siguientes lineas: [database]... connection = mysql://glance:glance_dbpass@controller/glance [keystone_authtoken]... auth_uri = identity_uri = admin_tenant_name = service admin_user = glance admin_password = GLANCE_PASS [DEFAULT]... notification_driver = noop verbose = True Debemos comentar las lineas "auth_host" y "auth_protocol" si se encuentran en el fichero ya que "identity_uri" realiza la misma función. 4. Rellenamos la base de datos creada con los parámetros de Glance. root@controller: su -s /bin/sh -c "glance-manage db_sync" glance 5. Reiniciamos el servicio Glance. root@controller: service glance-registry restart root@controller: glance-api restart 6. Por defecto el paquete de Ubuntu crea una base de datos SQLite. Como usaremos la base de datos MariaDB podemos eliminar la SQLite. root@controller: rm -f /var/lib/glance/glance.sqlite Verificación 1. Creamos un directorio temporal. root@controller: mkdir /tmp/images 2. Descargamos una imagen hacia el directorio temporal. root@controller: wget -P /tmp/images \ 3. Subimos la imagen hacia Glance. root@controller: lance image-create --name "cirros x86_64" \ --file /tmp/images/cirros x86_64-disk.img --disk-format qcow2 \ --container-format bare --is-public True --progress 4. Confirmamos que se subió correctamente. root@controller: glance image-list 5. Eliminamos el directorio temporal. root@controller: rm -r /tmp/images 51

74 Problemas encontrados No se encontraron problemas Instalación y configuración de Nova Como muestra el esquema de la figura 3.1 algunos componentes (nova-api) del servicio Nova se encuentran en el nodo Controlador mientras que otros (nova-compute) se encuentran en el nodo de Cómputo Configuración inicial La configuración inicial se realiza en el nodo Controlador. 1. Accedemos a la base de datos mediante el usuario root. root@controller: mysql -u root -p 2. Creamos la base de datos "nova". mysql>: CREATE DATABASE nova; 3. Permitimos el acceso a la base de datos con el password "NOVA_DBPASS". mysql>: GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' \ IDENTIFIED BY 'NOVA_DBPASS'; mysql>: GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY 'NOVA_DBPASS'; 4. Salimos de la sesión MariaDB/MySQL. mysql>: exit; Integración en KeyStone La integración se realiza en el nodo Controlador. 1. Cargamos el fichero admin-openrc.sh. root@controller: source admin-openrc.sh 2. Creamos el usuario "nova" con el password "NOVA_PASS". root@controller: keystone user-create --name nova --pass NOVA_PASS 3. Añadimos el rol "admin" al usuario "nova". root@controller: keystone user-role-add --user nova --tenant service --role admin 4. Creamos la entidad de servicios "nova". root@controller: keystone service-create --name nova --type compute \ --description "OpenStack Compute" 5. Creamos los "API endpoints" del servicio Nova. 52

75 keystone endpoint-create \ --service-id $(keystone service-list awk '/ compute / {print $2}') \ --publicurl \ --internalurl \ --adminurl \ --region regionone Instalación de componentes de Nova Nodo Controlador 1. Instalamos los paquetes. root@controller: apt-get install nova-api nova-cert nova-conductor nova-consoleauth \ nova-novncproxy nova-scheduler python-novaclient 2. Editamos el fichero /etc/nova/nova.conf y añadimos o reemplazamos las siguientes lineas: [database]... connection = mysql://nova:nova_dbpass@controller/nova [glance]... host = controller [keystone_authtoken]... auth_uri = identity_uri = admin_tenant_name = service admin_user = nova admin_password = NOVA_PASS [DEFAULT]... rpc_backend = rabbit rabbit_host = controller rabbit_password = RABBIT_PASS auth_strategy = keystone my_ip = vncserver_listen = vncserver_proxyclient_address = verbose = True Debemos comentar las lineas "auth_host", "auth_port" y "auth_protocol" ya que la opción "identiti_uri" las reemplaza. En las opciones "my_ip", "vncserver_listen" y "vncserver_proxyclient_address" debemos poner la IP de gestión del nodo Controlador. Las contraseñas "NOVA_PASS" y "RABBIT_PASS" deben reemplazarse por las elegidas por el usuario. 3. Rellenamos la base de datos creada con los parámetros de nova. root@controller: su -s /bin/sh -c "nova-manage db sync" nova 4. Reiniciamos los componentes o subservicios asociados al servicio nova en el nodo Controlador. root@controller: service nova-api restart root@controller: service nova-cert restart root@controller: service nova-consoleauth restart root@controller: service nova-scheduler restart root@controller: service nova-conductor restart root@controller: service nova-novncproxy restart 53

76 5. Por defecto el paquete de Ubuntu crea una base de datos SQLite. Como usaremos la base de datos MariaDB podemos eliminar la SQLite. rm -f /var/lib/nova/nova.sqlite Nodo de Cómputo 1. Instalamos los paquetes. apt-get install nova-compute sysfsutils 2. Editamos el fichero /etc/nova/nova.conf y añadimos o reemplazamos las siguientes lineas: [glance]... host = controller [keystone_authtoken]... auth_uri = identity_uri = admin_tenant_name = service admin_user = nova admin_password = NOVA_PASS [DEFAULT]... rpc_backend = rabbit rabbit_host = controller rabbit_password = RABBIT_PASS auth_strategy = keystone my_ip = vnc_enabled = True vncserver_listen = vncserver_proxyclient_address = novncproxy_base_url = verbose = True Debemos comentar las lineas "auth_host", "auth_port" y "auth_protocol" ya que la opción "identiti_uri" las reemplaza. En las opciones "my_ip" y "vncserver_proxyclient_address" debemos poner la IP de gestión del nodo de Cómputo. Las contraseñas "NOVA_PASS" y "RABBIT_PASS" deben reemplazarse por las elegidas por el usuario. 3. Determinamos si el nodo de Cómputo soporta aceleración por hardware para máquinas virtuales a través del siguiente comando. root@compute: egrep -c '(vmx svm)' /proc/cpuinfo Si el comando anterior retorna un valor igual o superior a 1 entonces nuestro nodo soporta aceleración por hardware y la tiene habilitada. En nuestro proyecto hemos tenido que habilitar la aceleración primero en el "host" físico en la BIOS y posteriormente en la creación de la máquina virtual KVM. Si tenemos aceleración por hardware para máquinas virutales debemos editar el fichero /etc/nova/novacompute.conf para que libvirt use KVM. [libvirt]... virt_type = kvm En caso de que nuestro nodo de Cómputo no presenta aceleración debemos poner en la linea "qemu" en vez de "kvm". 54

77 4. Reiniciamos el servicio Nova en el nodo de Cómputo. service nova-compute restart 5. Por defecto el paquete de Ubuntu crea una base de datos SQLite. Como usaremos la base de datos MariaDB podemos eliminar la SQLite. rm -f /var/lib/nova/nova.sqlite Verificación 1. Cargamos el fichero admin-openrc.sh. source admin-openrc.sh 2. Listamos todos los servicios de Nova. nova service-list La salida en la terminal debe ser similar a la mostrada en la captura de la figura 3.3 Figure 3.3: Comprobación de Nova I. 3. Listamos las imágenes desde Nova para verificar la conectividad con KeyStone y con Glance. root@compute: nova image-list La salida en la terminal debe ser similar a la mostrada en la captura de la figura 3.4 Figure 3.4: Comprovación de Nova II Problemas encontrados En este apartado tuvimos un problema que nos hizo cambiar una decisión inicial. El subservicio nova-compute no arrancaba correctamente y luego de mirar logs sin encontrar alguna pista comencé a investigar sobre virtualización KVM anidada sobre Contenedores LXC. Resulta que existen muchos bugs cuando se mezclan ambas tecnologías y no encontré forma de arreglar el problema [21] [22]. Finalmente opté por usar virtualización KVM directa en el nodo de Cómputo ya que virtualización anidada KVM sobre KVM si tiene soporte. La otra opción era configurar Nova para que usara contenedores LXC en las instancias, de esta forma estaría explotando la virtualización anidada LXC sobre LXC, pero como dichos contenedores aún no soportan todas las características del Cloud se decidió usar KVM. 55

78 3.3.5 Instalación y configuración de Neutron Como muestra el esquema de la figura 3.1 algunos componetes (neutron-server) del servicio Neutron se encuentran en el nodo Controlador mientras que otros (Agente L3) se encuentran en el nodo de Red Configuración inicial La configuración inicial se realiza en el nodo Controlador. 1. Accedemos a la base de datos mediante el usuario root. root@controller: mysql -u root -p 2. Creamos la base de datos "nova". mysql>: CREATE DATABASE neutron; 3. Permitimos el acceso a la base de datos con el password "NEUTRON_DBPASS". mysql>: GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' \ IDENTIFIED BY 'NOVA_DBPASS'; mysql>: GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' IDENTIFIED BY 'NEUTRON_DBPASS'; 4. Salimos de la sesión MariaDB/MySQL. mysql>: exit; Integración en KeyStone La integración en KeyStone se realiza en el nodo Controller. 1. Cargamos el fichero admin-openrc.sh. root@controller: source admin-openrc.sh 2. Creamos el usuario "neutron" con el password "NEUTRON_PASS". root@controller: keystone user-create --name neutron --pass NEUTRON_PASS 3. Añadimos el rol "admin" al usuario "neutron". root@controller: keystone user-role-add --user neutron --tenant service --role admin 4. Creamos la entidad de servicios "neutron". root@controller: keystone service-create --name neutron --type network \ --description "OpenStack Networking" 5. Creamos los "API endpoints" del servicio Neutron. root@controller: keystone endpoint-create \ --service-id $(keystone service-list awk '/ network / {print $2}') \ --publicurl \ --adminurl \ --internalurl \ --region regionone 56

79 Instalación de componentes de Neutron Nodo Controlador 1. Instalamos los paquetes. install neutron-server neutron-plugin-ml2 python-neutronclient 2. Editamos el fichero /etc/neutron/neutron.conf y añadimos o reemplazamos las siguientes lineas: [database]... connection = mysql://neutron:neutron_dbpass@controller/neutron [keystone_authtoken]... auth_uri = identity_uri = admin_tenant_name = service admin_user = neutron admin_password = NEUTRON_PASS [DEFAULT]... rpc_backend = rabbit rabbit_host = controller rabbit_password = RABBIT_PASS auth_strategy = keystone core_plugin = ml2 service_plugins = router allow_overlapping_ips = True notify_nova_on_port_status_changes = True notify_nova_on_port_data_changes = True nova_url = nova_admin_auth_url = nova_region_name = regionone nova_admin_username = nova nova_admin_tenant_id = SERVICE_TENANT_ID nova_admin_password = NOVA_PASS verbose = True Debemos comentar las lineas "auth_host", "auth_port" y "auth_protocol" ya que la opción "identiti_uri" las reemplaza. En las opciones "my_ip", "vncserver_listen" y "vncserver_proxyclient_address" debemos poner la IP de gestión del nodo Controlador. Las contraseñas "NOVA_PASS", "RABBIT_PASS", "NEU- TRON_PASS" y "NEUTRON_DBPASS" deben reemplazarse por las elegidas por el usuario. Debemos reemplazar "SERVICE_TENANT_ID" con el identificador (ID) del tenant "service". Para obtener dicho ID podemos ejecutar el siguiente comando: root@controller: source admin-openrc.sh root@controller: keystone tenant-get service 3. El plug-in ML2 usa el mecanismo de OpenvSwitch (OVS) basado en agentes para construir el framework de redes virtuales para las instancias. No obstante, el nodo Controlador no necesita el OpenvSwitch porque no participa en la gestión de tráfico en red de las instancias. Finalmente, Editamos el fichero /etc/neutron/- plugins/ml2/ml2_conf.ini y añadimos o reemplazamos las siguientes lineas: [ml2_type_gre]... tunnel_id_ranges = 1:1000 [securitygroup]... 57

80 enable_security_group = True enable_ipset = True firewall_driver = neutron.agent.linux.iptables_firewall.ovshybridiptablesfirewalldriver 4. Por defecto el servicio Nova está configurado para usar el componente nova-network en la gestión de las redes. Debemos cambiar la configuración para que el servicio Neutron se encargue de la gestión de red. Editamos el fichero /etc/nova/nova.conf y añadimos o reemplazamos las siguientes lineas: [DEFAULT]... network_api_class = nova.network.neutronv2.api.api security_group_api = neutron linuxnet_interface_driver = nova.network.linux_net.linuxovsinterfacedriver firewall_driver = nova.virt.firewall.noopfirewalldriver [neutron]... url = auth_strategy = keystone admin_auth_url = admin_tenant_name = service admin_username = neutron admin_password = NEUTRON_PASS La contraseña "NEUTRON_PASS" deben reemplazarse por la elegida por el usuario. 5. Rellenamos la base de datos creada con los parámetros de neutron. root@controller: su -s /bin/sh -c "neutron-db-manage --config-file \ /etc/neutron/neutron.conf --config-file \ /etc/neutron/plugins/ml2/ml2_conf.ini upgrade juno" neutron 6. Reiniciamos los componentes o microservicios asociados a los servicios Nova y Neutron en el nodo Controlador. root@controller: service nova-api restart root@controller: service nova-scheduler restart root@controller: service nova-conductor restart root@controller: service neutron-server restart Nodo de Red En el nodo de Red principalmente se gestiona el enrutamiento interno y externo de las redes virtuales y el servicio DCHP. 1. Primero debemos permitir que el nodo enrute paquetes. Editamos el fichero /etc/sysctl.conf y añadimos o reemplazamos las siguientes lineas: net.ipv4.ip_forward=1 net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.default.rp_filter=0 Implementamos los cambios. sysctl -p 2. Instalamos los paquetes. root@network: apt-get install neutron-plugin-ml2 neutron-plugin-openvswitch-agent \ neutron-l3-agent neutron-dhcp-agent 58

81 3. Editamos el fichero /etc/neutron/neutron.conf y añadimos o reemplazamos las siguientes lineas: [keystone_authtoken]... auth_uri = identity_uri = admin_tenant_name = service admin_user = neutron admin_password = NEUTRON_PASS [DEFAULT]... rpc_backend = rabbit rabbit_host = controller rabbit_password = RABBIT_PASS auth_strategy = keystone core_plugin = ml2 service_plugins = router allow_overlapping_ips = True verbose = True Debemos comentar las lineas "auth_host", "auth_port" y "auth_protocol" ya que la opción "identiti_uri" las reemplaza. Las contraseñas "NEUTRON_PASS" y "RABBIT_PASS" deben reemplazarse por las elegidas por el usuario. 4. El plug-in ML2 usa el mecanismo de OpenvSwitch (OVS) basado en agentes para construir el framework de redes virtuales para las instancias. Editamos el fichero /etc/neutron/plugins/ml2/ml2_conf.ini y añadimos o reemplazamos las siguientes lineas: [ml2]... type_drivers = flat,gre tenant_network_types = gre mechanism_drivers = openvswitch [ml2_type_flat]... flat_networks = external [ml2_type_gre]... tunnel_id_ranges = 1:1000 [securitygroup]... enable_security_group = True enable_ipset = True firewall_driver = neutron.agent.linux.iptables_firewall.ovshybridiptablesfirewalldriver [ovs]... local_ip = enable_tunneling = True bridge_mappings = external:br-ex [agent]... tunnel_types = gre En la opción "local_ip" debemos poner la IP del nodo de Red en la red Tunel. 5. El agente de la capa 3 (agente-l3) provee servicios de enrutamiento para las redes virtuales. Debemos editar el fichero /etc/neutron/l3_agent.ini y añadir o reemplazar las siguientes lineas: 59

82 [DEFAULT]... interface_driver = neutron.agent.linux.interface.ovsinterfacedriver use_namespaces = True external_network_bridge = br-ex router_delete_namespaces = True verbose = True En la configuración hemos habilitado el uso de espacio de nombres de red(net namespaces) para cada red virtual asignada a un Tenant. De esta forma cada Tenant o cliente en su red interna puede usar el direccionamiento que desee sin que perjudique al resto de Tenants. 6. El agente DHCP provee servicios DHCP para las redes virtuales. Debemos editar el fichero etc/neutron/dhcp_agent.ini y añadir o reemplazar las siguientes lineas: [DEFAULT]... interface_driver = neutron.agent.linux.interface.ovsinterfacedriver dhcp_driver = neutron.agent.linux.dhcp.dnsmasq use_namespaces = True dhcp_delete_namespaces = True verbose = True 7. Debido al error explicado en el apartado debemos hacer que las instancias se levanten con una MTU=1454 por defecto. Para ello seguimos los siguientes pasos: (a) Editamos nuevamente el fichero etc/neutron/dhcp_agent.ini y añadimos la siguiente linea. [DEFAULT]... dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf (b) Creamos y editamos el fichero /etc/neutron/dnsmasq-neutron.conf con la siguiente linea. dhcp-option-force=26,1454 (c) Eliminamos algún proceso "dnsmasq" existente. root@network: pkill dnsmasq 8. El agente de meta-datos provee información de la configuración actual, como las credenciales que posee una instancia. Debemos editar el fichero /etc/neutron/metadata_agent.ini y añadir o reemplazar las siguientes lineas: [DEFAULT]... auth_url = auth_region = regionone admin_tenant_name = service admin_user = neutron admin_password = NEUTRON_PASS nova_metadata_ip = controller metadata_proxy_shared_secret = METADATA_SECRET verbose = True La contraseña "NEUTRON_PASS" debe reemplazarse por la elegida por el usuario. En la linea "META- DATA_SECRET" el usuario debe determinar un secreto compartido adecuado. Nodo Controlador 60

83 1. Regresamos al nodo Controlador y editamos el fichero /etc/nova/nova.conf para añadir o reemplazar las siguientes lineas: [neutron]... service_metadata_proxy = True metadata_proxy_shared_secret = METADATA_SECRET En la linea "METADATA_SECRET" el usuario debe determinar un secreto compartido adecuado. 2. Reiniciamos el componente o micoservicio nova-api en el nodo Controlador. root@controller: service nova-api restart Nodo de Red Continuamos los pasos de configuración en el nodo de Red. La herramienta OpenvSwitch, dentro de OpenStack, constituye un framework para la creación de redes virtuales para las instancias. El switch virtual "br-int" maneja el tráfico interno entre las instancias y el "br-ext" maneja el trafico hacia redes externas a las instancias. El switch "br-ext" requiere un puerto en la "interfaz física externa" del nodo de Red. En nuestro proyecto dicha interfaz también es virtual y constituye eth3 del nodo de Red. 1. Reiniciamos el servicio OpenvSwitch. root@network: service openvswitch-switch restart 2. Añadimos el switch virtual externo. root@network: ovs-vsctl add-br br-ex 3. Añadimos la interfaz eth3 del nodo de Red. root@network: ovs-vsctl add-port br-ex eth3 4. Reiniciamos todos los componentes o microservicios de Neutron en el nodo de Red. root@network: service neutron-plugin-openvswitch-agent restart root@network: service neutron-l3-agent restart root@network: service neutron-dhcp-agent restart root@network: service neutron-metadata-agent restart Nodo de Cómputo En el nodo de Cómputo se maneja la conectividad y los grupos de seguridad de las instancias. 1. Configuramos los parámetros de red editando el fichero /etc/sysctl.conf y añadiendo o modificando las siguientes lineas: net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.default.rp_filter=0 2. Implementamos los cambios. root@compute: sysctl -p 3. Instalamos los paquetes. root@compute: apt-get install neutron-plugin-ml2 neutron-plugin-openvswitch-agent 61

84 4. Editamos el fichero /etc/neutron/neutron.conf y añadimos o reemplazamos las siguientes lineas: [keystone_authtoken]... auth_uri = identity_uri = admin_tenant_name = service admin_user = neutron admin_password = NEUTRON_PASS [DEFAULT]... rpc_backend = rabbit rabbit_host = controller rabbit_password = RABBIT_PASS auth_strategy = keystone core_plugin = ml2 service_plugins = router allow_overlapping_ips = True verbose = True Debemos comentar las lineas "auth_host", "auth_port" y "auth_protocol" ya que la opción "identiti_uri" las reemplaza. Las contraseñas "NEUTRON_PASS" y "RABBIT_PASS" deben reemplazarse por las elegidas por el usuario. En la sección "[database]" debemos comentar todoas las opciones "connection" ya que el nodo de Cómputo no accede directamente a ninguna base de datos. 5. El plug-in ML2 usa el mecanismo de OpenvSwitch (OVS) basado en agentes para construir el framework de redes virtuales para las instancias. Editamos el fichero /etc/neutron/plugins/ml2/ml2_conf.ini y añadimos o reemplazamos las siguientes lineas: [ml2]... type_drivers = flat,gre tenant_network_types = gre mechanism_drivers = openvswitch [ml2_type_gre]... tunnel_id_ranges = 1:1000 [securitygroup]... enable_security_group = True enable_ipset = True firewall_driver = neutron.agent.linux.iptables_firewall.ovshybridiptablesfirewalldriver [ovs]... local_ip = enable_tunneling = True [agent]... tunnel_types = gre En la opción "local_ip" debemos poner la IP del nodo de Cómputo en la red Tunel. 6. Reiniciamos el servicio OpenvSwitch. root@compute: service openvswitch-switch restart 7. Por defecto el servicio Nova está configurado para usar el componente nova-network en la gestión de las redes. Debemos cambiar la configuración para que el servicio Neutron se encargue de la gestión de red. Editamos el fichero /etc/nova/nova.conf y añadimos o reemplazamos las siguientes lineas: 62

85 [DEFAULT]... network_api_class = nova.network.neutronv2.api.api security_group_api = neutron linuxnet_interface_driver = nova.network.linux_net.linuxovsinterfacedriver firewall_driver = nova.virt.firewall.noopfirewalldriver [neutron]... url = auth_strategy = keystone admin_auth_url = admin_tenant_name = service admin_username = neutron admin_password = NEUTRON_PASS La contraseña "NEUTRON_PASS" deben reemplazarse por la elegida por el usuario. 8. Reinicamos el componente nova-compute. root@compute: service nova-compute restart 9. Reinicamos el servicio OpenvSwitch. root@compute: service neutron-plugin-openvswitch-agent restart Antes de continuar es recomendable comprobar que la configuración de Neutron es correcta. Para ello debemos listar los servicios de Neutron desde el nodo Controlador. root@controller: source admin-openrc.sh root@controller: neutron agent-list La salida en la terminal debe ser similar a la mostrada en la captura de la figura 3.5 Figure 3.5: Agentes de Neutron Creación de redes iniciales Antes de levantar nuestra primera instancia debemos crear la infraestructura de red virtual a la cual se conectará dicha instancia. Todos los comandos se ejecutan en el nodo Controlador. Creación de la red externa a las instancias La red externa provee de acceso a internet a las instancias. Por defecto, las instancias solo acceden a internet a través de un NAT por razones de seguridad. Para obtener acceso a las instancias a través de internet debemos asignarles las llamadas IPs flotantes (Floating IPs) y editar los grupos de seguridad. El tenant "admin" es el propietario de esta red ya que provee de acceso externo a múltiples tenants. 63

86 1. Cargamos el fichero admin-openrc.sh. source admin-openrc.sh 2. Creamos la red externa: neutron net-create ext-net --router:external True \ --provider:physical_network external --provider:network_type flat La red externa tendrá una arquitectura plana, es decir todos las direcciones IP externas de las instancias se encontrarán en la misma red y conectadas al resto de dispositivos "físicos" existentes en dicha red. 3. Asignamos el direccionamiento y subred para la red externa. root@neutron subnet-create ext-net --name ext-subnet \ --allocation-pool start= ,end= \ --disable-dhcp --gateway /24 Como esta red externa generalmente ya tiene otros equipos en ella es recomendable deshabilitar el DHCP y asignar solo una parte de las direcciones disponibles en la red. Para nuestro proyecto usaremos aquellas IPs que van desde /24 hasta /24. Dicho conjunto de IPs son las conocidas como IPs flotantes (floating IPs). Creación de la red interna de un Tenant La red interna de un Tenant provee de conectividad interna a las instancias de ese Tenant en particular. La configuración de Neutron habilita los espacio de nombres de red(net namespaces) permitiendo que cada red de un Tenant se encuentre aislada del resto de Tenants.. Para nuestro ejemplo, el tenant "demo" es el propietario de la red interna que crearemos ya que solo provee acceso interno para sus instancias. 1. Cargamos el fichero demo-operc.sh. root@controller: source demo-openrc.sh 2. Creamos la red interna del tenant "demo". root@controller: neutron net-create demo-net Al no especificar nada, la red interna del tenant "demo" usará DHCP para asignar IPs a sus instancias. 3. Asignamos el direccionamiento y subred para la red interna del tenant "demo". root@controller: neutron subnet-create demo-net --name demo-subnet \ --gateway /24 Creación del router virtual. Un router virtual maneja el tráfico entre dos o más redes virtuales. En este caso crearemos un router virtual "demo-router" y le agregaremos la red externa y la interna del tenant "demo". 1. Creamos el router. root@controller: neutron router-create demo-router 2. Agregamos una interfaz de la red interna "demo-subnet" en el router "demo-router". root@controller: neutron router-interface-add demo-router demo-subnet 3. Agregamos una interfaz de la red externa "ext-net" en el router "demo-router". Pero en esta ocasión la interfaz será marcada como gateway. root@controller: neutron router-gateway-set demo-router ext-net 64

87 Verificación Antes de continuar y levantar finalmente nuestra primera instancia debemos comprobar que la configuración de las redes virtuales de las instancias son correctas. En nuestro ejemplo la interfaz gateway del "demo-router" en la red externa debe tener la IP debido a que es la más baja del rango indicado. A partir del esquema de la figura 3.2 deberíamos poder hacer ping desde una terminal del host hacia dicha IP. En caso de que eliminemos el router virtual y volvamos a crearlo la IP nueva asignada puede variar. Es importante que las interfaces eth3 del nodo de Red y tap0 y eth3-network del sistema "host"estén configuradas en modo "promiscuo" como se anuncia en los apartados y La siguiente captura muestra que hay conectividad entre la red "externa" (nuestro sistema "host" en el proyecto)y el "demo-router" que se encuentra en la IP en ese momento. Figure 3.6: Comprobación de la configuración de Neutron Problemas encontrados 1. El primer problema de este apartado fue que Neutron no estaba creando los routers virtuales ni los servidores DHCP virtuales. Para comprobar que Neutron crea correctamente los equipos virtuales anteriores debemos ejecutar el siguiente comando. root@neutron: sudo ip netns list El comando anterior lista los espacios de nombres de red que existen en Neutron. En este momento deberíamos tener al menos dos espacios de nombres de red (router virtual y servidor DHCP junto a la red demo-tenant). Nuestro problema consistía en que el comando no mostraba nada en la terminal, es decir Neutron no estaba creando nuevos espacios de nombres de red (net namespaces). Luego de buscar en foros de OpenStack encontré que AppArmor (SELinux de Ubuntu) no funcionaba correctamente con LXC anidados (Nested LXC), particularmente con el hecho de usar "net namespaces" dentro de "net namespaces". Así que la idea fue deshabilitar AppArmor para el Contenedor Neutron como ya se indicó en la creación del Contenedor y finalmente se levantaron correctamente los routers y servidores DHCP virtuales. 2. Otro error sufrido fue de concepto. Como aún no tenía claro el concepto de espacios de nombres de red intentaba hacer ping hacia el router creado ( ) directamente desde el nodo de Red. Analizando bien la documentación de Neutron descubrí que dicho router se encuentra en otro espacio de nombres y que para llegar a él tendría que hacerlo desde la red extena "ext-net". Para ello añadí una nueva interfaz virtual "tap0" al sistema "host" y la conecté a la interfaz eth3 del node de Red a través de un nuevo switch virtual. Finalmente, desde el sistema "host" pude hacer ping al nuevo router virtual Instalación y configuración de Horizon En estos momentos es posible levantar una instancia desde la linea de comandos en el nodo Controlador puesto que todos los sistemas fundamentales del sistema Cloud ya se están configurados. No obstante, primero instalaremos el 65

88 servicio Dashboard Horizon que hace de FrontEnd para todo el sistema OpenStack. Todos los comandos se ejecutan en el nodo Controlador Instalación de componentes de Horizon 1. Instalamos los paquetes. apt-get install openstack-dashboard apache2 libapache2-mod-wsgi \ memcached python-memcache 2. Editamos el fichero /etc/openstack-dashboard/local_settings.py y añadimos o reemplazamos las siguientes lineas: OPENSTACK_HOST = "controller" ALLOWED_HOSTS = ['*'] CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.memcachedcache', 'LOCATION': ' :11211', } } la opción "*" en la linea "ALLOWED_HOSTS" permite a todos los usuarios acceder al servicio Horizon. La opción "CACHES" se refiere al servicio que almacenará la gestión en Horizon, en este caso Memcached. Cualquier otra linea con la opción "CACHES" debe ser comentada. 3. Reiniciamos los servicios memcached y apache2. root@controller: service apache2 restart root@controller: service memcached restart Verificación Para verificar la instalación de Horizon accederemos a su interfaz web y navegaremos por las distintas opciones. 1. En el sistema "host" editamos el fichero /etc/hosts y añadimos o reemplazamos las siguientes lineas: controller network compute 2. Desde el sistema "host" en un navegador accedemos a Horizon con la URL Las credenciales son las del usuario "admin" o el usuario "demo". 3. En las siguiente captura vemos como Horizon muestra un esquema con las redes virtuales creadas Problemas encontrados No se encontraron problemas Levantar una Instancia y lograr acceso externo Iniciaremos una instancia usando la imagen CirrOS y verificaremos su correcta configuración de red enviado un ping a través de la interfaz tap0 a su dirección IP en la red interna. Todos los comandos se ejecutan en el nodo Controlador. 66

89 Figure 3.7: Interfaz de Horizon Generación de par de claves (key pair) Para usar una imagen determinada debemos autenticarnos a través de nova con el método "public key authentication" en vez del "user/name" convencional. 1. Cargamos el fichero demo-operc.sh. root@controller: source demo-openrc.sh 2. Generamos el par de claves: root@controller: ssh-keygen 3. Añadimos el par de claves a través de Nova. root@controller: nova keypair-add --pub-key ~/.ssh/id_rsa.pub demo-key 4. Verificamos que el par de claves se haya añadido correctamente. root@controller: nova keypair-list Levantamiento de la instancia Para levantar la instancia debemos especificar el "flavor", nombre de la imagen, red, grupo de seguridad, clave y nombre de la instancia. 1. Listamos los "flavors". Recordemos que un "flavor" especifica un perfil de recursos que incluye procesador, memoria RAM y almacenamiento. root@controller: nova flavor-list 2. Listamos las imágenes disponibles. 67

90 nova image-list 3. Listamos las redes disponibles: neutron net-list Nuestra instancia usará la red "demo-net". 4. Listamos los grupos de seguridad disponibles. secgroup-list Nuestra instancia usará el grupo de seguridad "default". Por defecto dicho grupo implementa un firewall que bloquea el acceso remoto a las instancias. 5. Levantamos la instancia. root@controller: nova boot --flavor m1.tiny --image cirros x86_64 \ --nic net-id=demo_net_id --security-group default --key-name demo-key demo-instance1 Reemplazamos "DEMO_NET_ID" con el ID real de la red "demo-net". 6. Comprobamos el estado de la instancia. root@controller: nova list Cuando la instancia finalice su proceso de construcción el estado pasará de "BUILD" a "ACTIVE". En nuestro caso la instancia toma la IP interna Acceso a través de la consola virtual Por el momento no podemos hacer ping a la instancia desde el sistema "host" debido al firewall del grupo de seguridad "default". Para acceder a la instancia desplegaremos una terminal remota virtual VNC. 1. Obtenemos una URL de sesión de la terminal virtual VNC. root@controller: nova get-vnc-console demo-instance1 novnc 2. Pegamos la URL anterior en el navegador del sistema "host" para acceder al terminal. El nombre de usuario y contraseña aparece en la interfaz VNC de la página web. 3. Una vez en el terminal debemos comprobar que la red de la instancia está correctamente configurada. Para ello enviamos un ping hacia el gateway de la red interna "demo-net" ( ), otro hacia el gateway de la red externa "ext-net" ( ) y otro hacia la interfaz "tap0" ( ). La siguiente captura muestra la comprobación de una red correctamente configurada Permitir acceso externo a la instancia En este apartado permitiremos el acceso externo a la instancia para paquetes ICMP (ping) y el protocolo ssh. 1. Añadimos la regla al grupo de seguridad "default" que permite paquetes ICMP (ping). root@controller: nova secgroup-add-rule default icmp /0 68

91 Figure 3.8: Terminal VNC. 2. Añadimos la regla al grupo de seguridad "default" que permite paquetes ssh, exactamente permitimos la entrada de paquetes tcp por el puerto 22. nova secgroup-add-rule default tcp /0 3. Creamos una IP flotante (floating IP) en la red externa "ext-net". neutron floatingip-create ext-net 4. Asociamos la IP flotante con la instancia creada. nova floating-ip-associate demo-instance Comprobamos el estado de la nueva IP flotante asignada anteriormente. nova list 6. Verificamos la conectividad mediante ping desde el "host" hacia la instancia. ping Accedemos a la instancia mediante ssh. El nombre de usuario y contraseña son los mismos que en el caso de la consola VNC. root@host: ssh cirros@ La siguiente captura muestra el ping y el acceso ssh deste el sistema "host" Problemas encontrados En este apartado tuvimos un problema a la hora de acceder mediante ssh a la instancia. El "host" enviaba la petición pero no recibía respuesta. Por otra parte el ping si funcionaba correctamente. Investigando en foros de OpenStack ([1]) encontré que el problema estaba en la MTU que trae por defecto una instancia en OpenStack (MTU=1500). Para resolver el problema debemos cambiar la MTU a un valor de 1454 en la instancia CirrOS. root@host: sudo ip link set eth0 mtu

92 Figure 3.9: Ping y acceso ssh desde el "host". En la documentación oficial de OpenStack existe un paso opcional donde se configuran las instancias para que arranquen con MTU=1454 por defecto. Sin embargo, explican que dicha configuración solo mejora el desempeño por lo que no me pareció relevante. Una vez encontrado y solucionado este problema he añadido la configuración en el nodo de Red (Fichero /etc/neutron/dhcp_agent.ini, apartado Neutron). El protocolo GRE incluye cabeceras adicionales que incrementan el "overhead" y provoca que los paquetes IPs que salen de los nodos "físicos" tengan que ser constantemente fragmentados. En instalaciones totalmente virtuales como las nuestras esta fragmentación puede provocar problemas de conexión. Para prevenir las complicaciones se recomienda disminuir el MTU de las instancias a 1454 para tener en cuenta el overhead introducido por GRE. Según la documentación este valor debe funcionar en la mayoría de los casos, en caso de que no funcionara se debería seguir disminuyendo un poco más el valor del MTU de las instancias. 70

93 Chapter 4 SDN y OpenDayLight 4.1 Qué es SDN? SDN significa "Software Defined Networking" o en español Redes definidas por Software. Constituye un nuevo paradigma en la gestión de redes donde se intenta "programar" la red según el contexto específico. El objetivo principal de SDN es separar el plano de control (software) del plano de datos (hardware). En otras palabras SDN busca desacoplar la infraestructura de red (hardware) de las funciones o inteligencia (software) que la red tiene que realizar. Plano de Control Plano de Control Controlador SDN Plano de Datos Desacoplo Programa Dispositivo de red actual (router Cisco, swich HP, etc) Plano de Datos Switch OpenFlow Figure 4.1: Objetivo principal de SDN. En la actualidad todos los equipos de red (switches, routers, firewalls) poseen el plano de control fuertemente acoplado al plano de datos, de forma que realizar un cambio en la lógica de red implica cambiar la configuración de todos los dispositivos, siempre que el firmware lo soporte. Esta forma de "cambiar la lógica en la red" es muy lenta para el ritmo de innovación actual y no es escalable en absoluto. La opción de usar un servidor con software de red Open Source instalado no es viable debido a su "lenta" CPU. Los equipos de red precisan de un hardware basado en ASICs que son muy eficientes en hacer una y sola una tarea (en este caso, leer tablas y encaminar paquetes). El número de dispositivos y personas que se conectan a internet aumenta rápidamente con la llegada del "Internet de las cosas" y la entrada a la era de la información de muchos países del tercer mundo. Por otra parte, el aumento del ancho de banda (fibra óptica) también tiende a aumentar debido al auge de nuevos servicios como IPTV, VoD y Videollamadas. Bajo estas condiciones es necesario un cambio de paradigma que permita redes más flexibles, escalables y eficientes. SDN pretende ser la respuesta al cambio de paradigma y su desarrollo se encuentra ampliamente apoyado por la comunidad Open Source y por las compañías más grandes del sector. 71

94 4.2 Arquitectura de SDN Primero me gustaría mencionar la arquitectura de las redes actuales desplegadas. Una red tradicional (No SDN) consiste en un conjunto de elementos de conmutación que unen diversos medios de transmisión (fibra óptica, par de cobre, aire, etc). Estas se gestionan de forma distribuida, es decir cada nodo de la red incorpora un firmware que toma las decisiones en función del tipo de paquete y la información que este almacena dentro. En contraste, la red SDN también tiene un conjunto de elementos de conmutación (hardware) que unen los medios de transmisión, pero encima presenta una capa de control (software) compuesta por un Controlador y aplicaciones de programación. De forma que la gestión de la red pasa a ser centralizada en el Controlador SDN y la "inteligencia" de la red se programa en las aplicaciones que corren sobre dicho controlador. Estas tres capas (infraestructura, control y aplicación) se representan en el esquema 4.2 siguiente: Figure 4.2: Arquitectura SDN. Los dispositivos de la capa de Infraestructura (switches OpenFlow) se comunican con la capa de Control mediante las llamadas SouthBound APIs, cuya implementación principal es OpenFlow. La capa de Control compuesta por el Controlador SDN tiene una visión global de toda la red física y programa las tablas de flujo de los switches mediante OpenFlow. La capa de Aplicación se comuncia con la capa de Control mediante las llamadas NorthBound APIs, normalmente APIs REST. En la figura anterior podemos ver a OpenStack como ejemplo de capa de aplicación, exactamente el servicio Neutron puede delegar la implementación exacta de ciertas tareas de red a un Controlador SDN. Resumiendo, las aplicaciones definen la "inteligencia" de la red y lo comunican al Controlador SDN mediante una NorthBound API (API REST por ejemplo). El controlador procesa la información y finalmente lo comunica a los dispositivos de red mediante la SouthBound API (OpenFlow por ejemplo). 4.3 OpenFlow El protocolo OpenFlow representa el protocolo principal de comunicación en la SouthBound API. Permite al Controlador modificar las tablas de flujos (Flow-Tables) de los switches físicos de forma dinámica para implementar servicios como Firewalls, NAT, QoS o algún nuevo protocolo. Un flujo del switch puede estar definido por muchos criterios entre los que encontramos: puerto donde se recibe el paquete, etiqueta VLAN, MAC origen o destino, protocolo, etc. Si un paquete no encuentra ninguna coincidencia en las tablas 1 debe ser enviado al Controlador SDN. Dicho controlador definirá un nuevo flujo para el paquete y enviará al switch una o más entradas para las tablas de flujo existente. Para la próxima ocasión los paquetes que coincidan con 1 En OpenFlow 1.0 solo se puede definir una tabla con múltiples entradas de flujos. Sin embargo, a partir de la especificación OpenFlow 1.3 es posible definir múltiples tablas con varias entradas de flujo [5]. 72

95 este nuevo flujo no tendrán que esperar la respuesta del Controlador, sino que serán encaminados a velocidad de linea por el switch OpenFlow Switch OpenFlow Un Switch OpenFlow presenta se compone de tres características fundamentales [6]: 1. Tablas de flujos: Indican como debe ser procesado un flujo determinado de paquetes. 2. Canal hacia el Controlador: El canal de comunicación entre el Switch y el Controlador debe ser muy seguro ya que el Controlador gestiona toda la red de forma centralizada. En este caso se usa el protocolo OpenFlow. 3. Controlador SDN: El switch debe tener en el otro extremo del canal seguro un Controlador SDN que actualiza las tablas de flujos ante la llegada de nuevos paquetes. Figure 4.3: Switch OpenFlow. Un paquete al llegar a un switch OpenFlow deberá ser rápidamente procesado para encontrar coincidencias en las entradas de una o varias tablas de flujo. En OpenFlow v1.4 cada entrada consta de los siguientes componentes: 1. Campos coincidentes (matchs fields): Campos que definen un flujo determinado. 2. Prioridad (priority): Nivel de prioridad que tendrá la entrada frente a otras entradas que también coincidan con un paquete determinado. 3. Contadores (counters): Se actualiza cuando se encuentran paquetes que coinciden con la entrada. 4. Instrucciones (instructions): Modifica el "Action-Set"(Variable que representa el conjunto de acciones a ejecutar a un paquete determinado). 5. Timeouts: Máximo tiempo que la entrada estará en la tabla de flujos. 6. Cookie: Dato que envía el controlador por motivos estadísticos. No se usa para el procesado de paquetes. 73

96 Un paquete entra al switch OpenFlow y pasa a la primera tabla de flujos en el switch. Si el switch encuentra coincidencias en una entrada, se fijará en el campo "Instrucciones" y modificará la variable "Action-Set". Seguidamente el paquete irá pasando por las tablas de flujos restantes y modificará constantemente el valor de "Action-Set". Finalmente, el switch ejecutará el contenido definido en "Action-Set" de forma ordenada. Como ya sabemos, si el switch no encuentra una entrada compatible deberá informar al Controlador SDN para que este pueda definir una entrada y flujo nuevos. El procesado del paquete puede visualizarse en la figura 4.4 siguiente: Figure 4.4: Procesado en Switch OpenFlow. Todo Switch OpenFlow debe ser capaz de de ejecutar las siguientes acciones básicas: 1. Reenvío de paquetes a uno o varios puertos determinados: La acción consiste en encaminar el paquete a otros puertos a velocidad de linea. 2. Encapsulación y reenvío del paquete al Controlador: Se usa para el primer paquete de un nuevo flujo. El paquete viajará por un canal seguro hacia el Controlador que tomará la decisión de que hacer con él. 3. Descartar el paquete: Por motivos de seguridad el Switch OpenFlow debe ser capaz de bloquear paquetes sospechosos, actuar como firewall, etc Mensajes del Protocolo OpenFlow Los mensajes de OpenFlow v1.4 pueden clasificarse en tres tipos: 1. Controlador a switch: Iniciados por el Controlador para actuar y conocer el estado del switch. A su vez, presenta varios subtipos: Features: El Controlador puede solicitar la identidad y las capacidades básicas del switch enviando un paquete "Features". Seguidamente el switch debe responder especificando sus características. Configuration: El Controlador puede pedir o fijar parámetros de configuración en el switch. Modify-State: El Controlador puede manejar el estado de las tablas de flujos en el switch. Read-State: Usado por el Controlador para recoger información estadística. Packet-out: Usado por el Controlador para designar el puerto del switch por donde se encaminará el paquete, normalmente se trata de la respuesta a un "Packet-in". Barrier: Enviado por el Controlador para informar que determinadas operaciones se han completado. Role-Request: Usado principalmente si un switch se conecta a varios Controladores. El mensaje se usa para fijar el rol del Controlador. 2. Mensajes asíncronos: Iniciados por el switch para avisar al Controlador sobre eventos en la red y cambios en el estado del switch. 74

97 Packet-in: Transfiere el control sobre el paquete al Controlador SDN. Normalmente porque no encuentra un flujo asociado al paquete, pero también puede ser una acción expresa de una entrada. La respuesta del Controlador es una paquete "Packet-out". Flow-Removed: Informa al Controlador la eliminación de una entrada en una tabla de flujo. Port-status: Informa al Controlador de un cambio en un puerto. 3. Mensajes simétricos: Iniciados por el switch o por el Controlador y no necesita autorización previa. Hello: Mensajes "Hello" son intercambiados entre el Controlador y el siwtch al principio de una conexión OpenFlow. Echo: Un "Echo request" puede ser enviado por cualquiera de los dispositivos y el otro extremo de la conexión deberá enviar un "Echo reply". Error: Mensajes de error notificados al otro extremo de la conexión. Normalmente, usado por el switch para indicar el fallo de una petición iniciada por el Controlador. Experimenter: Mensajes de experimentación para proveer funcionalidades adicionales de forma estándar. 4.4 Controlador OpenDaylight OpenDayLight es un Controlador SDN, Open Source, escrito en Java que se ejecuta dentro de su propia máquina virtual (JVM). Ha recibido el soporte de la "Linux Fundation" y el de muchas empresas del sector como Cisco, HP, Red Hat, etc. A medida que avanza su desarrollo su campo de actuación se expande y en su hoja de ruta se encuentra dar soporte a múltiples tecnologías novedosas relacionadas con SDN como NFV, VTN y SFC [15]. Es decir, al igual que OpenStack se ha impuesto en el campo de Cloud Computing es razonable esperar que OpenDayLight se imponga en el campo de SDN ya que comparten las mismas características (Open Source y soporte de la industria). Por esta razón para el proyecto se ha elegido este "Super Controlador SDN" para ser integrado en el servicio Neutron de OpenStack. La arquitectura de OpenDaylight es totalmente modular. La interfaz de bajo nivel (SouthBound API) soporta múltiples protocolos (plug-ins de OpenDayLight) como OpenFlow 1.0, OpenFlow 1.3, NETCONF, OVSDB, etc. Los plug-ins se conectan dinámicamente a la SAL (Service Abstraction Layer) que funciona como una capa de abstracción para los módulos de redes superiores. Es decir, la SAL permite que OpenDayLight ejecute la tarea solicitada independientemente del protocolo usado para conectarse con los equipos físicos. La figura 4.5 muestra toda la arquitectura OpenDayLight Lithium. 75

98 Figure 4.5: OpenDayLight Lithium OpenDaylight y OpenStack El desarrollo de la última versión de OpenDayLight (Lithium) estuvo orientada a mejorar la compatibilidad con Open- Stack. Un caso de uso común de OpenDayLight es servir de backend para Neutron y proveer de servicios de red al sistema OpenStack. Desde OpenStack, Neutron utiliza el driver OpenDayLight como "mechanism driver" del plug-in ML2 y traspasa todas las llamadas a la API de Neutron hacia OpenDayLight. El controlador SDN contiene una API REST a la escucha "Neutron API service" que recepciona las llamadas de Neutron y las ofrece al resto de servicios SDN. La figura 4.6 muestra un esquema de la comunicación entre OpenDayLight y Neutron. Figure 4.6: Comunicación entre OpenDayLight y OpenStack. OpnDayLight expone el "Neutron API service" para ser implementado de cinco formas diferentes en dependencia de la tecnología elegida en OpenDayLight. La figura 4.7 muestra un esquema de la arquitectura del "Neutron API service" 76

99 Figure 4.7: Neutron API service. Como vemos en la captura anterior el "Neutron API service" de OpenDayLight se compone de 3 capas principales: 1. "Neutron Northbound API": Recibe las peticiones REST y devuelve las respuestas finales hacia Neutron. 2. "Neutron SouthBound providers interfaces" (SPI): Enlaza el "Neutron Northbound API" con la implementación elegida. 3. "Implementación": Implementa los servicios de redes de Neutron. En la versión OpenDayLight Lithium tenemos las siguientes cinco opciones: (a) OVSDB: Utiliza como protocolo de SouthBound OVSDB para configurar los switches OpenvSwitch en los nodos de Red y Cómputo. OVSDB es el protocolo de configuración remota de los switches OpenvSwitch; es decir mientras OpenFlow se usa para gestionar las tablas de flujos, OVSDB configura datos estáticos en OpenvSwitch [12]. Es la opción implementada en nuestro proyecto. La figura 4.8 ilustra esta opción. Figure 4.8: OVSDB y OpenDayLight. 77

100 (b) VTN Manager: VTN significa "Virtual Tenant Network" y es una opción de virtualización de red disponible en OpenDayLight implementada como un "bundle" OSGi de controladores usando la AD-SAL. También gestiona switches OpenFlow. (c) Open DOVE: Open DOVE es otra opción de virtualización de red en OpenDayLight basada en tecnologías SDN de IBM. No parece que se mantenga su soporte a OpenStack. (d) OpenContrail (plugin2oc): Propone la integración entre OpenDayLight y la plataforma OpenContrail. (e) LISP Flow Mapping: Opción de virtualización de red a través del protocolo LISP. OpenDayLight puede añadir al sistema Cloud servicios especiales de aplicaciones SDN. Por ejemplo, un usuario desea implementar seguridad adicional y puede añadir el servicio "Unified Secure Channel" para cifrar las comunicaciones. Otro valor añadido de OpenDayLight es su soporte a diversos protocolos SouthBound como NETCONF, BGP, OpenFlow que permite controlar mayor cantidad de dispositivos físicos o virtuales [13]. La figura 4.9 muestra un esquema de los servicios especiales que OpenDayLight puede añadir al sistema Cloud. Figure 4.9: OpenDayLight y OpenStack. El controlador SDN puede configurarse de dos formas según la función que tenga en la gestión de red: 1. Control de Switches OpenvSwitch: De esta forma OpenDayLight solo deberá gestionar los switches OpenvSwitch, aplicando las reglas OpenFlow, levantando los túneles GRE, etc. Los agentes de Neutron "neutronl3-agent" y "neutron-dhcp-agent" se encargarán de gestionar las tareas L3 y el servicio DHCP respectivamente. Esta opción ha sido la implementada en nuestro proyecto. 2. Control de Switches OpenvSwitch y otras funcionalidades de red: De esta forma, además de controlar los switches OpenvSwitch, el controlador SDN controla otras funciones como las tareas L3, el balanceo de carga o funciones de firewall. Como se comentó anteriormente nuestra integración de OpenDayLight se realizará a través de OVSDB. La principal diferencia con la configuración inicial de Neutron es que no se usan los switches "br-tun" en ningún nodo, sino que los switches "br-int" se encargan de levantar el tunel GRE además de cumplir sus funciones anteriores. 78

101 Chapter 5 Integración de OpenDayLight La Integración de OpenDayLight parte del trabajo realizado en el capítulo 3 "Despligue de OpenStack". 5.1 Entorno de desarrollo El controlador SDN OpenDayLight será un nuevo nodo y estará instalado en un contenedor LXC. Es decir, nuestra infraestructura virtual en este caso estará compuesta por: 1 nodo Controlador con hostname "controller". 1 nodo de Red con hostname "network". 1 nodo de Cómputo con hostname "compute". 1 nodo OpenDayLight con hostname "opendaylight". La figura 5.1 muestra un esquema resumen del entorno de desarrollo utilizado para integrar OpenDayLight en nuestra infraestructura OpenStack Nodo opendaylight Nodo controller Nodo network Nodo compute Horizon Glance Contenedor LXC SQL MariaDB Cola de Mensajes RabbitMQ NTP Keystone nova-api Contenedor LXC Novasheduler Neutronserver neutronplugin-ml2 Neutrondhcp-agent neutron-l3- agent neutronplugin-ml2 Metadatanet-agent OpenvSwitch OpenvSwitch Contenedor LXC Hypervisor KVM neutronplugin-ml2 Novacompute Máquina virtual KVM Figure 5.1: Entorno de Desarrollo II. En esta ocasión no hace falta el uso de "Neutron-plugin-openvswitch-agent" que se utilizaba como plug-in ML2 en Neutron. Dicha función ahora la realizará OpenDayLight desde su propio nodo. 79

102 5.2 Despliegue de Infraestructura inicial La figura 5.2 muestra la actualización del esquema de red. En este caso hemos añadido el nodo "opendaylight" en la red de gestión y mantenido la configuración por defecto de la interfaz eth0 para instalar los paquetes necesarios desde internet. Red de Gestión ( ) Red Tunel ( ) Red Externa ( ) Red LXC ( ) Red KVM ( ) Host net namespace wlan0 NAT(IPtable) Par veth Par veth Par veth eth0-odl eth0-control eth0-network vnet0 eth0 eth1 Nodo opendaylight Par veth eth0 eth1 Par veth eth0 eth1 Par veth OpenvSwitch Switch br-man eth1-control eth1-network Nodo controller Nodo network Nodo compute eth3 eth2 Switch br-tunnel Par veth Par veth eth1-odl eth2-network vnet1 vnet2 Switch br-out eth3-network tap eth eth2 eth Figure 5.2: Infraestructura de Red II. Todos los comandos que se ejecutarán en los próximos apartados se realizarán con permisos de superusuario. El nombre del portátil es "host" y presenta un sistema operativo Linux Mint 17, compatible con Ubuntu Instalación y configuración de LXC para el nodo OpenDayLight 1. Creamos un contenedor basados en ubuntu 14.04, con la plantilla "download", arquitectura amd64 y con nombre "opendaylight". root@host: lxc-create -t download -n opendaylight -- --dist ubuntu --release trusty \ --arch amd64 2. Configuramos los parámetros de red según el esquema de la figura 5.2 El fichero se encuentra en la ruta /var/lib/lxc/opendaylight/config. 80

103 # Path /var/lib/lxc/opendaylight/config # Template used to create this container: /usr/share/lxc/templates/lxc-download # Parameters passed to the template: --dist ubuntu --release trusty --arch amd64 # For additional config options, please look at lxc.container.conf(5) # Distribution configuration lxc.include = /usr/share/lxc/config/ubuntu.common.conf lxc.arch = x86_64 # Container specific configuration lxc.rootfs = /var/lib/lxc/opendaylight/rootfs lxc.utsname = opendaylight # Network configuration lxc.network.type = veth lxc.network.flags = up lxc.network.link = lxcbr0 lxc.network.hwaddr = 00:16:3e:8e:73:e6 lxc.network.veth.pair = eth0-odl #Manual configuration for opendaylight node in OpenStack lxc.network.type = veth lxc.network.flags = up lxc.network.veth.pair = eth1-odl lxc.network.ipv4 = /24 lxc.mount.auto = cgroup lxc.aa_profile = unconfined Las dos últimas líneas en el fichero del contenedor opendaylight inhabilitan el uso de AppArmor (SeLinux de Ubuntu) para permitir a opendaylight la creación de nuevos espacios de nombres de red. 3. Abrimos una consola nueva para el nuevo nodo, iniciamos el contenedor en background y accedemos a su sistema para comprobar que se han iniciado correctamente. root@host: lxc-start -n opendaylight -d root@host: lxc-attach -n opendaylight 4. El contenedor se puede parar apagando su sistema o ejecuando el siguiente comando desde el "host". root@host: lxc-stop -n opendaylight 5. En la consola del "host" podemos listar los contenedores que hemos creado con el siguiente comando: root@host: lxc-ls 6. En la página x del apéndice podemos encontrar documentación detallada de la herramienta LXC Configuración de OpenvSwitch para conectar el nodo opendaylight 1. Conectamos la interfaz "eth1-odl" al switch "br-man", según el esquema de red 5.2. root@host: ovs-vsctl add-port br-man eth1-odl 2. Los siguientes comandos sirven para comprobar la correcta configuración de OpenvSwitch Muestra la configuración de todos los switchs virtuales de OpenvSwitch. root@host: ovs-vsctl show 81

104 Muestra las interfaces de un switch OpenvSwitch, en este caso br-man. ovs-vsctl list-ports br-man Reinica el servicio de OpenvSwitch service openvswitch-switch restart 3. Por defecto, en la distribución Linux Mint 17 la herramienta NetworkManager intenta reconfigurar las interfaces del sistema "host" provocando cambios en las configuraciones de red. Para evitar que NetworkManager modique nuestras interfaces debemos mencionar todas las interfaces implicadas en el proyecto en el fichero /etc/network/interfaces. A continuación se presenta el fichero /etc/network/interfaces modificado. #auto eth0 #iface eth0 inet dhcp #Bridges from OVS auto br-man iface br-man inet static address netmask auto br-tunnel iface br-tunnel inet static address netmask #Avoid NetworkManager problem. iface vnet1 inet static iface eth1-control inet static iface eth1-network inet static iface vnet2 inet static iface eth2-network inet static iface eth3-network inet static iface eth0-control inet static iface eth0-network inet static #Testing the network for instances auto br-out iface br-out inet static address netmask auto tap0 iface tap0 inet static address netmask iface eth0-odl inet static iface eth1-odl inet static 4. Llegados a este punto es recomendable pausar los contenedores y la máquina virtual, reiniciar el sistema "host" y arrancar nuevamente los nodos para comprobar que las configuraciones se han realizado correctamente. Una vez comprobados todos los parámetros se podrá continuar al siguiente apartado. 82

105 5.3 Instalación e integración de OpenDayLight Para instalar y configurar OpenDayLight debemos descargar todos los paquetes necesarios y configurar tanto el nodo opendaylight como el resto de los nodos para que se comuniquen con él. Para facilitar el despliegue se recomienda tener un terminal abierto para cada nodo y otro para el sistema "host" Cambios iniciales Antes de instalar nada debemos realizar los siguientes cambios iniciales. Nodo OpenDayLight 1. Asignamos al nodo OpenDayLight el hostname "opendaylight". root@hostname: hostname opendaylight 2. Añadimos en el fichero /etc/hosts las direcciones IP de gestión de los nodos. Se debe remover o comentar la linea que comienza con #controller controller #network network #compute compute #opendaylight opendaylight 3. Actualizamos el sistema Linux. root@opendaylight: sudo apt-get update && apt-get upgrade 4. Reiniciamos el sistema LXC. Nodos Restantes 1. Añadimos en el fichero /etc/hosts el nodo OpenDayLight. Finalmente el fichero debe quedar de la siguiente manera: #controller controller #network network #compute compute #opendaylight opendaylight 2. Reiniciamos el sistema LXC o KVM según el nodo Instalación de OpenDayLight 1. Descargamos la última versión de OpenDayLight desde la web oficial: Para nuestro proyecto utilizamos la versión Lithium SR1, exactamente el fichero "distribution-karaf Lithium-SR1". 2. Pasamos el fichero descargado al nodo opendaylight, por ejemplo mediante scp. (Si decidimos usar scp debemos asignar un password al usuario por defecto "ubuntu" del contenedor LXC). 83

106 3. En el nodo OpenDayLight instalamos java (necesaria para OpenDayLight Lithium). sudo apt-get install openjdk-7-jdk nota: Para la próxima versión OpenDayLight Beryllium se necesitará java Nos dirigimos al direcctorio donde está el fichero ".tar" y descomprimimos. root@opendaylight: tar xvfz distribution-karaf lithium-sr1.tar.gz 5. Entramos al nuevo directorio. root@opendaylight: cd distribution-karaf lithium-sr1 6. Editamos el fichero "etc/org.apache.karaf.management.cfg" y reemplazamos las siguientes lineas: #rmiregistryhost = rmiregistryhost = #rmiserverhost = rmiserverhost = Este cambio se debe a un error en el fichero de configuración en la versión Lithium-SR1 de OpenDayLight (Más información en el apartado 5.3.9). 7. Iniciamos el karaf root@opendaylight:./bin/start 8. Entramos a la consola de karaf con el usuario "karaf". root@opendaylight:./bin/client -u karaf 9. Instalamos el "feature" odl-ovsdb-openstack que permite la comunicación con OpenStack y el odl-dlux-core que instala el Dlux, la interfaz web de OpenDayLight. opendaylight-user@root>feature:install odl-ovsdb-openstack odl-dlux-core 10. Con control-d salimos de la consola de karaf. 11. Desde el sistema "host" podemos comprobar la interfaz web de odl a través del enlace El usuario y password es "admin". La siguiente captura muestra dicha interfaz. Otra opción para verificar la instalación de OpenDaylight es hacer una petición a la API REST de OpenDaylight con el el siguiente comando: root@opendaylight: curl -u admin:admin / Para monitorizar los parámetros de OpenDaylight tenemos el siguiente fichero de logs. root@opendaylight: tail -f data/log/karaf.log 84

107 Figure 5.3: Dlux inicial Eliminación de instancias, routers y puertos anteriormente creados Para configurar correctamente OpenDayLight debemos eliminar toda configuración de red anterior realizada por Neutron con el driver OpenvSwitch del plug-in ML2. Todas las operaciones de este apartado se realizarán desde el nodo Controlador. 1. Cargamos el fichero admin-openrc.sh root@controller: source admin-openrc.sh 2. Listamos las instancias, router, puertos y redes y las eliminamos. root@controller: nova list root@controller: nova delete <INSTANCE ID> root@controller: neutron router-list root@controller: neutron router-gateway-clear <ROUTER ID> root@controller: neutron router-delete <ROUTER ID> root@controller: neutron port-list root@controller: neutron port-delete <PORT ID> root@controller: neutron net-list root@controller: neutron net-delete <NEWORK ID> 3. Cargamos el fichero demo-openrc.sh root@controller: source demo-openrc.sh 4. Listamos las instancias, router, puertos y redes y las eliminamos. root@controller: nova list root@controller: nova delete <INSTANCE ID> root@controller: neutron router-list root@controller: neutron router-gateway-clear <ROUTER ID> root@controller: neutron router-delete <ROUTER ID> root@controller: neutron port-list root@controller: neutron port-delete <PORT ID> root@controller: neutron net-list root@controller: neutron net-delete <NEWORK ID> 5. Paramos el subservicio neutron-server. 85

108 service neutron-server stop Nueva configuración de OpenvSwitch Nodo de Cómputo 1. El driver de OpenvSwitch para el plug-in ML2 (Neutron-plugin-openvswitch-agent) debe ser pausado ya que solo OpenDaylight debe controlar los switches OpenvSwitch. service neutron-plugin-openvswitch-agent stop echo manual sudo tee /etc/init/neutron-plugin-openvswitch-agent.override nota: El segundo comando inhabilita el inicio de un servicio Linux al reiniciar un sistema basado en Ubuntu Eliminamos la base de datos interna de OpenvSwitch y reiniciamos su servicio. root@compute: rm -rf /var/log/openvswitch/* root@compute: rm -rf /etc/openvswitch/conf.db root@compute: service openvswitch-switch stop root@compute: service openvswitch-switch start root@compute: ovs-vsctl show El último comando debe mostrar un OpenvSwitch vacío. Además veremos el ID de OpenvSwitch. 3. Configuramos el extremo (end-point) del tunel GRE con el "OPENVSWITCH ID". root@compute: ovs-vsctl set Open_vSwitch <OPENVSWITCH ID> \ other_config={'local_ip'=' '} Por ejemplo el comando que realmente introducimos fue: root@compute: ovs-vsctl set Open_vSwitch 39aa6b66-da3c-4d10-8b92-254c6e \ other_config={'local_ip'=' '} Para verficar la configuración podemos ejecutar el comando: root@compute: ovs-vsctl list Open_vSwitch 4. Conectamos el OpenvSwitch del nodo de Cómputo con OpenDaylight. root@compute: ovs-vsctl set-manager tcp: :6640 Nodo de Red 5. El driver de OpenvSwitch para el plug-in ML2 (Neutron-plugin-openvswitch-agent) debe ser pausado ya que solo OpenDaylight debe controlar los switches OpenvSwitch. root@network: service neutron-plugin-openvswitch-agent stop root@network: echo manual sudo tee /etc/init/neutron-plugin-openvswitch-agent.override nota: El segundo comando inhabilita el inicio de un servicio Linux al reiniciar un sistema basado en Ubuntu Eliminamos la base de datos interna de OpenvSwitch y reiniciamos su servicio. 86

109 rm -rf /var/log/openvswitch/* rm -rf /etc/openvswitch/conf.db service openvswitch-switch stop service openvswitch-switch start ovs-vsctl show El último comando debe mostrar un OpenvSwitch vacío. Además veremos el ID de OpenvSwitch. 7. Configuramos el extremo (end-point) del tunel GRE con el "OPENVSWITCH ID". ovs-vsctl set Open_vSwitch <OPENVSWITCH ID> \ other_config={'local_ip'=' '} Por ejemplo el comando que realmente introducimos fue: root@network: ovs-vsctl set Open_vSwitch 6815b8e c4a-ba8b-08f7636f8bc5 \ other_config={'local_ip'=' '} Para verificar la configuración podemos ejecutar el comando: root@network: ovs-vsctl list Open_vSwitch 8. Creamos el switch virtual "br-ex" que se usará para la red externa de OpenStack y le conectamos la interfaz eth3 del nodo de Red. root@network: ovs-vsctl add-br br-ex root@network: ovs-vsctl add-port br-ex eth3 9. Conectamos el OpenvSwitch del nodo de Cómputo con OpenDaylight. root@network: ovs-vsctl set-manager tcp: : Configuración del plugin ML2 En los nodos Controlador, de Red y de Cómputo debemos editar el fichero /etc/neutron/plugins/ml2/ml2_conf.ini y añadir o reemplazar las siguientes lineas. [ml2]... #mechanism_drivers = openvswitch mechanism_drivers = opendaylight [ml2_odl] password = admin username = admin url = En la linea de "mechanism_drivers" hemos comentado la opción de "openvswitch" y añadido la de "opendaylight" ya que este es el nuevo driver ML2 que usaremos para conectarnos con los switches virtuales OpenvSwitch Reinicio de la base de datos de Neutron En el nodo Controlador debemos reiniciar la base de datos de neutron para que tome de referencia a OpenDayLight. 1. Accedemos a la base de datos mediante el usuario root: root@controller: mysql -u root -p 87

110 2. Eliminamos la base de datos "neutron". mysql>: DROP DATABASE keystone; 3. Creamos la base de datos "neutron". mysql>: CREATE DATABASE neutron; 4. Permitimos el acceso a la base de datos con el password "NEUTRON_DBPASS". mysql>: GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' \ IDENTIFIED BY 'NOVA_DBPASS'; mysql>: GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' IDENTIFIED BY 'NEUTRON_DBPASS'; 5. Salimos de la sesión MariaDB/MySQL. mysql>: exit; 6. Rellenamos la base de datos creada con los parámetros de neutron. root@controller: su -s /bin/sh -c "neutron-db-manage --config-file \ /etc/neutron/neutron.conf --config-file \ /etc/neutron/plugins/ml2/ml2_conf.ini upgrade juno" neutron 7. Finalmente iniciamos nuevamente el subservicio neutron-server. root@controller: service neutron-server start Modificación de fichero Neutron 1. Debido a un error encontrado en apartados siguientes debemos editar el fichero "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/mechanism_odl.py" en el nodo de Red, Cómputo, y Controlador y cambiar las siguientes lineas: #self.auth = JsessionId(self.url, self.username, self.password) self.auth = (self.username, self.password) 2. Se recomienda reiniciar los switches OpenvSwitch del nodo de Red y de Cómputo, así como el subservicio neutron-server del nodo Controlador. root@controller: service neutron-server restart root@network: service openvswitch-switch restart root@compute: service openvswitch-switch restart Para más información se puede consultar el apartado

111 5.3.8 Verificación 1. Para verficar la correcta configuración de OpenDayLight podemos ejecutar los mismos pasos del apartado "Creación de redes iniciales" del sub-capítulo "Instalación y configuración de Neutron". 2. Si las redes se crean satisfactoriamente podemos pasar al apartado "Levantar una Instancia y lograr acceso externo". 3. Por otra parte, los dos switches OpenvSwitch y el enlace GRE entre ellos aparece en la interfaz web DLUX de OpenDayLight. Recordamos que el enlace es " y el usuario y password es "admin". La siguiente captura muestra dicho estado: Figure 5.4: Dlux final Problemas encontrados En general el Controlador SDN OpenDaylight se ha mostrado más inestable que el sistema OpenStack. La documentación también es más pobre y no existe una guía clara de como integrar OpenDayLight en OpenStack teniendo en cuenta todos las arquitecturas posibles del sistema Cloud. No obstante, la documentación y estabilidad de OpenDay- Light debe aumentar bastante en los próximos años ya que OpenDayLight Lithium SR1 aún se considera en estado beta. Siguiendo la documentación oficial no pudimos hacer funcionar el sistema OpenStack Kilo bajo OpenDayLight Lithium SR1, así que indagando en foros y blogs encontramos aquellas modificaciones que hacía falta, tanto en la configuración de OpenvSwitch como la instalación inicial de OpenDayLight [14] [11]. 1. En primera instancia, según la documentación oficial de OpenDayLight, instalamos muchos features que realmente no eran necesarios. En los foros explican que para la versión Lithium SR1 tan solo se necesitan "odlovsdb-openstack" y "odl-dlux-core". Es decir, la documentación está obsoleta y no es fiable. 2. A la hora de configurar el extremo del túnel GRE necesitamos el ID del switch OpenvSwitch, requerimiento que no aparece en la documentación oficial. 3. Una vez instalado OpenDaylight necesitamos cambiar el archivo de configuración "distribution-karaf Lithium-SR1/etc/org.apache.karaf.management.cfg" y reemplazar las siguientes lineas: #rmiregistryhost = rmiregistryhost =

toda la potencia de un Dedicado con la flexibilidad del Cloud

toda la potencia de un Dedicado con la flexibilidad del Cloud Cloud Dedicado: toda la potencia de un Dedicado con la flexibilidad del Cloud Cardenal Gardoki, 1 48008 BILBAO (Vizcaya) Teléfono: 902 012 199 www.hostalia.com Qué es un Cloud Privado Virtual? El término

Más detalles

Seminario. Cloud Computing. Granada, 20 al 22 de febrero de 2013

Seminario. Cloud Computing. Granada, 20 al 22 de febrero de 2013 Seminario Cloud Computing Granada, 20 al 22 de febrero de 2013 1 Plataformas Open Source para Cloud Computing Sergio Alonso (zerjioi@ugr.es) Universidad de Granada Seminario Cloud Computing Contenidos

Más detalles

Una solución de Infraestructura como Servicio: OpenStack

Una solución de Infraestructura como Servicio: OpenStack Una solución de Infraestructura como Servicio: OpenStack Prosecretaría de Informática UNC Ing. Juan Pavlik Salles jpavlik@psi.unc.edu.ar http://ar.linkedin.com/in/juanjosep/ Índice Situación inicial: Infraestructura

Más detalles

Administración de infraestructura IT

Administración de infraestructura IT Administración de infraestructura IT MANAGED IT INFRASTRUCTURE Administración de infraestructura IT No importa cuál sea el tamaño su negocio, la infraestructura IT juega un papel crítico en el mantenimiento

Más detalles

EXIN Foundation Certificate in OpenStack Software

EXIN Foundation Certificate in OpenStack Software Examen de Muestra EXIN Foundation Certificate in OpenStack Software Edición Abril 2015 Copyright 2015 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored

Más detalles

Sistema de Mensajería Empresarial para generación Masiva de DTE

Sistema de Mensajería Empresarial para generación Masiva de DTE Sistema de Mensajería Empresarial para generación Masiva de DTE TIPO DE DOCUMENTO: OFERTA TÉCNICA Y COMERCIAL VERSIÓN 1.0, 7 de Mayo de 2008 CONTENIDO 1 INTRODUCCIÓN 4 2 DESCRIPCIÓN DE ARQUITECTURA DE

Más detalles

Introducción a OpenStack

Introducción a OpenStack Introducción a OpenStack Proyecto de Innovación. Implantación y puesta a punto de la infraestructura de un cloud computing privado para el despliegue de servicios en la nube IES Gonzalo Nazareno Dos Hermanas

Más detalles

Alumno: Jorge Sordo Balbín Profesor: Luis Joyanes Aguilar Nº Expediente: 126013 Correo Electrónico: jorge_sordo@hotmail.com

Alumno: Jorge Sordo Balbín Profesor: Luis Joyanes Aguilar Nº Expediente: 126013 Correo Electrónico: jorge_sordo@hotmail.com UNIVERSIDAD PONTIFICIA DE SALAMANCA CAMPUS MADRID INGENIERÍA DE ORGANIZACIÓN INDUSTRIAL TRABAJO ACADÉMICO I Modelos de despliegue y Modelos de servicio Noviembre 2012 Alumno: Jorge Sordo Balbín Profesor:

Más detalles

Cloud Security Alliance. Recomendaciones de Seguridad para Usuarios

Cloud Security Alliance. Recomendaciones de Seguridad para Usuarios Cloud Security Alliance Recomendaciones de Seguridad Contenido Qué es el Cloud Computing?... 2 Modelos de Servicios... 2 Modelos de Implementación... 3 Recomendaciones a los Usuarios para la adopción del

Más detalles

Instalación de XEN... 2 1 Información de XEN... 2 1.1 Qué es XEN?... 2 1.2 Componentes de XEN:... 2

Instalación de XEN... 2 1 Información de XEN... 2 1.1 Qué es XEN?... 2 1.2 Componentes de XEN:... 2 Guía Instalación de XEN en opensuse Contenido de la guía Instalación de XEN... 2 1 Información de XEN... 2 1.1 Qué es XEN?... 2 1.2 Componentes de XEN:... 2 2 Instalación del kernel de XEN para Opensuse

Más detalles

Artículo Infraestructura integrada UCS de Cisco para OpenStack de Red Hat

Artículo Infraestructura integrada UCS de Cisco para OpenStack de Red Hat 1 Artículo Infraestructura integrada UCS de Cisco para OpenStack de Red Hat 2 Una implementación más fácil de Enterprise OpenStack Clouds Gracias a la alianza estratégica con Red Hat, el líder en código

Más detalles

GLOSARIO DE TÉRMINOS

GLOSARIO DE TÉRMINOS MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN Y FORMACIÓN PROFESIONAL DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES GLOSARIO DE TÉRMINOS

Más detalles

CAPÍTULO I. Sistemas de Control Distribuido (SCD).

CAPÍTULO I. Sistemas de Control Distribuido (SCD). 1.1 Sistemas de Control. Un sistema es un ente cuya función es la de recibir acciones externas llamadas variables de entrada que a su vez provocan una o varias reacciones como respuesta llamadas variables

Más detalles

Windows Server 2012: Identidad y Acceso. Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services.

Windows Server 2012: Identidad y Acceso. Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services. Windows Server 2012: Identidad y Acceso Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services. Manual del Módulo Autor: Andrew J Warren, Content Master Publicado: Septiembre 10 de

Más detalles

Alcatel-Lucent VitalQIP Appliance Manager

Alcatel-Lucent VitalQIP Appliance Manager Alcatel-Lucent Appliance Manager Solución integral de gestión de direcciones IP y basada en dispositivos con amplia funcionalidad Racionalice la gestión y reduzca los costes administrativos con Alcatel-Lucent

Más detalles

NORMATIVA DE HOSTING VIRTUAL DE LA UNIVERSIDAD DE SEVILLA (SIC - JUNIO 2014)

NORMATIVA DE HOSTING VIRTUAL DE LA UNIVERSIDAD DE SEVILLA (SIC - JUNIO 2014) NORMATIVA DE HOSTING VIRTUAL DE LA UNIVERSIDAD DE SEVILLA (SIC - JUNIO 2014) Características generales.- La Universidad de Sevilla (US), a través del Servicio de Informática y Comunicaciones (SIC), pone

Más detalles

La publicación. Pere Barnola Augé P08/93133/01510

La publicación. Pere Barnola Augé P08/93133/01510 La publicación Pere Barnola Augé P08/93133/01510 FUOC P08/93133/01510 La publicación Índice Introducción... 5 1. El dominio... 7 2. Alojamiento web... 9 3. FTP... 11 3.1. Cliente FTP... 11 3.1.1. Cómo

Más detalles

Conceptos de redes. LAN (Local Area Network) WAN (Wide Area Network)

Conceptos de redes. LAN (Local Area Network) WAN (Wide Area Network) Conceptos de redes. Una red de ordenadores permite conectar a los mismos con la finalidad de compartir recursos e información. Hablando en términos de networking, lo importante es que todos los dispositivos

Más detalles

INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS

INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS AUTORÍA JOSEFA PÉREZ DOMÍNGUEZ TEMÁTICA NUEVAS TECNOLOGIAS ETAPA CICLOS FORMATIVOS DE GRADO SUPERIOR DE INFORMÁTICA Resumen En esta publicación se

Más detalles

Infraestructura Convergente (CI)

Infraestructura Convergente (CI) Infraestructura Convergente (CI) Autor: Norberto Figuerola La globalización y la creciente presión de la competencia han acelerado el ritmo de los negocios, lo que obligó a los empresarios a recurrir a

Más detalles

Windows Server 2012: Infraestructura de Escritorio Virtual

Windows Server 2012: Infraestructura de Escritorio Virtual Windows Server 2012: Infraestructura de Escritorio Virtual Módulo 1: Application Virtualization Módulo del Manual Autores: James Hamilton-Adams, Content Master Publicado: 5 de Octubre 2012 La información

Más detalles

Curso: FT433 - Introducción a la virtualización con VirtualBox

Curso: FT433 - Introducción a la virtualización con VirtualBox forumtecnico.com Curso: FT433 - Introducción a la virtualización con VirtualBox Configuración de red Uno de los aspectos de la virtualización con más número de opciones es la configuración de red. Recordemos

Más detalles

INTRODUCCIÓN A LAS REDES INFORMÁTICAS

INTRODUCCIÓN A LAS REDES INFORMÁTICAS Instituto Tecnológico Argentino Técnico en Redes Informáticas Plan TRI2A03B Reservados los Derechos de Propiedad Intelectual Tema: Introducción a las redes Archivo: CAP2A03BTRI0102.doc informáticas Clase

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

Virtualización en Servidores. Conceptos básicos

Virtualización en Servidores. Conceptos básicos Virtualización en Servidores Conceptos básicos Cuestionamientos Cuando hablamos de virtualización? Por que virtualizar? Alta disponibilidad Tipos de virtualización Cuándo hablamos de virtualización? En

Más detalles

Escritorios virtuales

Escritorios virtuales Escritorios virtuales Italo E. Ayesteran R. Con la adopción de la tecnología de Computación en la nube (Cloud Computing), las soluciones de escritorio virtual representan una de las herramientas más poderosas

Más detalles

Acceso al Disco Compartido y Dispositivos USB y DVD

Acceso al Disco Compartido y Dispositivos USB y DVD Acceso al Disco Compartido y Dispositivos USB y DVD Los Técnicos Académicos de las carreras de Matemáticas y Actuaría del Departamento de Matemáticas en el Tlahuizcalpan, ponen a su disposición este mini-manual,

Más detalles

MANUAL TÉCNICO DE IMPLEMENTACIÓN PROYECTO SOCIAL COMPUESCUELA. Elaborado por: Julián A. Hernández M.

MANUAL TÉCNICO DE IMPLEMENTACIÓN PROYECTO SOCIAL COMPUESCUELA. Elaborado por: Julián A. Hernández M. MANUAL TÉCNICO DE IMPLEMENTACIÓN PROYECTO SOCIAL COMPUESCUELA Elaborado por: Julián A. Hernández M. PONTIFICIA UNIVERSIDAD JAVERIANA CALI SANTIAGO DE CALI 2011 CONTENIDO Pág. INTRODUCCIÓN...3 1. ANÁLISIS

Más detalles

INSTALACIÓ N A3ERP. Informática para empresas INTRODUCCIÓN CONSIDERACIONES GENERALES DE LA INSTALACIÓN PAQUETES DE INSTALACIÓN PREDEFINIDOS

INSTALACIÓ N A3ERP. Informática para empresas INTRODUCCIÓN CONSIDERACIONES GENERALES DE LA INSTALACIÓN PAQUETES DE INSTALACIÓN PREDEFINIDOS Página 1 de 20 INSTALACIÓ N A3ERP INTRODUCCIÓN La instalación de a3erp v9 ha sufrido una trasformación importante respecto a sus versiones anteriores. Cualquier instalación exige la existencia de un pc

Más detalles

Análisis de Requisitos integración FORMIGA-CLOUD / DIRAC (Prototipo II)

Análisis de Requisitos integración FORMIGA-CLOUD / DIRAC (Prototipo II) 1 Universidad de Santiago de Compostela Análisis de Requisitos integración FORMIGA-CLOUD / DIRAC (Prototipo II) PROYECTO FORMIGACLOUD INTEGRACIÓN CON DIRAC V.2 (Infraestructura distribuida con control

Más detalles

Se muestra la pantalla inicial de plataforma Cloud Computing cuando se accede por primera vez, visualizando el componente Horizon de OpenStack.

Se muestra la pantalla inicial de plataforma Cloud Computing cuando se accede por primera vez, visualizando el componente Horizon de OpenStack. Vista interfaz de acceso Se muestra la pantalla inicial de plataforma Cloud Computing cuando se accede por primera vez, visualizando el componente Horizon de OpenStack. El ingreso se realiza por medio

Más detalles

Beneficios económicos de la Estrategia de la nube de Cisco

Beneficios económicos de la Estrategia de la nube de Cisco Beneficios económicos de la Estrategia de la nube de Cisco Principales conclusiones Resumen ejecutivo La computación en la nube permite suministrar TI como un servicio cuando y donde se necesite, desde

Más detalles

Guía de inicio de Symantec Protection Center. Versión 2.0

Guía de inicio de Symantec Protection Center. Versión 2.0 Guía de inicio de Symantec Protection Center Versión 2.0 Guía de inicio de Symantec Protection Center El software descrito en el presente manual está sujeto a un acuerdo de licencia y solamente podrá utilizarse

Más detalles

Administrador de Proyectos Seis Sigma

Administrador de Proyectos Seis Sigma Administrador de Proyectos Seis Sigma Bizagi Suite Seis Sigma 1 Table of Contents Administrador de Proyectos Seis Sigma... 3 Elementos del proceso...10 Cuadro del Proyecto...10 El Proyecto es Válido?...13

Más detalles

Computación en la nube. Plataformas de servicios en la nube y Servicios en la nube

Computación en la nube. Plataformas de servicios en la nube y Servicios en la nube Plataformas de servicios en la nube y Servicios en la nube PLATAFORMAS DE SERVICIOS EN LA NUBE Computación en la nube Google Apps Google Apps Google Apps: Es uno de los servicios que Google ofrece. Como

Más detalles

MANUAL DE USUARIO DE OFICINA CONECTADA

MANUAL DE USUARIO DE OFICINA CONECTADA MANUAL DE USUARIO DE OFICINA CONECTADA 1 OFICINA CONECTADA INDICE 1 INTRODUCCIÓN...3 2 USO DEL SERVICIO...4 2.1 CONFIGURACIÓN EQUIPO CLIENTE...4 2.2 ADMINISTRACIÓN AVANZADA...5 2.2.1 Gestión de usuarios...7

Más detalles

SIGAN 1.0 SISTEMA DE INFORMACIÓN DE GESTIÓN ADMINISTRATIVA DE NÓMINA

SIGAN 1.0 SISTEMA DE INFORMACIÓN DE GESTIÓN ADMINISTRATIVA DE NÓMINA RIF: V-16233325-5 SIGAN 1.0 SISTEMA DE INFORMACIÓN DE GESTIÓN ADMINISTRATIVA DE NÓMINA Sistema desarrollado bajo software libre, con orientación al manejo de base de datos a través de una interfaz gráfica

Más detalles

Desarrollo de Aplicaciones Web Por César Bustamante Gutiérrez. Módulo I: Conceptos Básicos Tema 1: Concepto iniciales. www.librosdigitales.

Desarrollo de Aplicaciones Web Por César Bustamante Gutiérrez. Módulo I: Conceptos Básicos Tema 1: Concepto iniciales. www.librosdigitales. 1 Arquitectura de una Aplicación Android Para empezar con el desarrollo de aplicaciones en Android es importante conocer cómo está estructurado este sistema operativo. A esto le llamamos arquitectura y

Más detalles

Preguntas Frec uentes Ia a S

Preguntas Frec uentes Ia a S Qué es IaaS Telmex? Infraestructura como Servicio (IaaS) de Telmex, es una solución basada en las nuevas tecnologías de virtualización bajo demanda, orientado a empresas que requieran de un servicio de

Más detalles

INSTALACIÓN A3ERP INTRODUCCIÓN CONSIDERACIONES GENERALES DE LA INSTALACIÓN PAQUETES DE INSTALACIÓN PREDEFINIDOS

INSTALACIÓN A3ERP INTRODUCCIÓN CONSIDERACIONES GENERALES DE LA INSTALACIÓN PAQUETES DE INSTALACIÓN PREDEFINIDOS INSTALACIÓN A3ERP INTRODUCCIÓN La instalación de a3erp v9 ha sufrido una trasformación importante respecto a sus versiones anteriores. Cualquier instalación exige la existencia de un pc al que le asignaremos

Más detalles

Medellín, martes 27 de octubre del 2015

Medellín, martes 27 de octubre del 2015 Medellín, martes 27 de octubre del 2015 José Flavio Guerra Gerente de Innovación OasisCom Introducción Administre con eficiencia sus recursos Servicios En la nube? ERP? Nada? Contenido ERP Definición Características

Más detalles

ESCUELA POLITÉCNICA NACIONAL 28 DE OCTUBRE, 2015 ORTIZ JÁCOME LEONARDO JOSÉ

ESCUELA POLITÉCNICA NACIONAL 28 DE OCTUBRE, 2015 ORTIZ JÁCOME LEONARDO JOSÉ ESCUELA POLITÉCNICA NACIONAL INGENIERIA DE SISTEMAS INFORME 1 APLICACIONES WEB SERVICIOS SOBRE INTERNET 28 DE OCTUBRE, 2015 ORTIZ JÁCOME LEONARDO JOSÉ 1. INTRODUCCIÓN Internet es un conjunto descentralizado

Más detalles

Workflows? Sí, cuántos quiere?

Workflows? Sí, cuántos quiere? Workflows? Sí, cuántos quiere? 12.11.2006 Servicios Profesionales Danysoft Son notables los beneficios que una organización puede obtener gracias al soporte de procesos de negocios que requieran la intervención

Más detalles

Para ingresar al mismo debes hacer click en el ícono correspondiente en el panel de control.

Para ingresar al mismo debes hacer click en el ícono correspondiente en el panel de control. Aplicable a Hosting Linux Cpanel 11.25.0-C40255 Principales funciones del Administrador de Archivos... El administrador de archivos del panel te permite trabajar con todos los archivos que has subido al

Más detalles

MS_10974 Deploying Windows Server

MS_10974 Deploying Windows Server Gold Learning Gold Business Intelligence Silver Data Plataform www.ked.com.mx Por favor no imprimas este documento si no es necesario. Introducción. En este curso usted aprenderá cómo planear e implementar

Más detalles

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos. Apéndice C. Glosario A Actividades de coordinación entre grupos. Son dinámicas y canales de comunicación cuyo objetivo es facilitar el trabajo entre los distintos equipos del proyecto. Actividades integradas

Más detalles

Informática en la nube. Susi Rodríguez

Informática en la nube. Susi Rodríguez Informática en la nube Susi Rodríguez DE QUE VAMOS A HABLAR? Analizar como utilizamos las TICs en nuestro trabajo Qué es eso de la nube? Ventajas, riesgos y los retos legales la nube Herramientas y servicios

Más detalles

CENTRO DE INVESTIGACIÓN CIENTÍFICA Y DE EDUCACIÓN SUPERIOR DE ENSENADA, BAJA CALIFORNIA Departamento de Cómputo / Dirección de Telemática ÍNDICE

CENTRO DE INVESTIGACIÓN CIENTÍFICA Y DE EDUCACIÓN SUPERIOR DE ENSENADA, BAJA CALIFORNIA Departamento de Cómputo / Dirección de Telemática ÍNDICE HOJA 1 DE 17 ÍNDICE 1 Interfaz Web... 2 1.1 Acceso a la nube CICESE utilizando la interfaz Web.... 2 1.2 Pantalla principal de la interfaz Web.... 3 2 Administrar archivos desde la interfaz Web... 5 2.1

Más detalles

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)

Más detalles

Guía de uso del Cloud Datacenter de acens

Guía de uso del Cloud Datacenter de acens guíasdeuso Guía de uso del Cloud Datacenter de Calle San Rafael, 14 28108 Alcobendas (Madrid) 902 90 10 20 www..com Introducción Un Data Center o centro de datos físico es un espacio utilizado para alojar

Más detalles

Cloud Computing: Soluciones y Seguridad

Cloud Computing: Soluciones y Seguridad MAD-004 Cloud Computing: Soluciones y Seguridad El sistema Cloud nace de la necesidad del usuario de disponer de toda su información en tiempo real desde cualquier ubicación y con cualquier dispositivo.

Más detalles

GlusterFS. Una visión rápida a uno de los más innovadores sistema de archivos distribuido

GlusterFS. Una visión rápida a uno de los más innovadores sistema de archivos distribuido GlusterFS Una visión rápida a uno de los más innovadores sistema de archivos distribuido Qué es GlusterFS? Es un sistema de archivos de alta disponibilidad y escalabilidad que puede brindar almacenamiento

Más detalles

Manual de Procedimientos

Manual de Procedimientos 1 de 13 Elaborado por: Oficina de Planeación y Desarrollo Institucional -Área de Calidad y Mejoramiento- Revisado por: Aprobado por: Coordinador Área de Jefe de la Oficina de Informática y Telecomunicaciones

Más detalles

Figure 16-1: Phase H: Architecture Change Management

Figure 16-1: Phase H: Architecture Change Management Fase H Administración del cambio en la Arquitectura Figure 16-1: Phase H: Architecture Change Management Objetivos Los objetivos de la Fase H son: Asegurarse de que el ciclo de vida de arquitectura se

Más detalles

Guía de Instalación para clientes de WebAdmin

Guía de Instalación para clientes de WebAdmin Panda Managed Office Protection Guía de Instalación para clientes de WebAdmin Tabla de contenidos 1. Introducción... 4 2. Instalación de Panda Managed Office Protection a partir de una instalación de Panda

Más detalles

Guía de Uso. Administración de Tokens

Guía de Uso. Administración de Tokens Guía de Uso Administración de Tokens Índice Guía de Uso Safesign Identity Client... 3 OBJETIVO... 3 ALCANCE... 3 RESPONSABLES... 3 GLOSARIO... 3 INTRODUCCIÓN... 4 efirma y los Certificados Digitales...

Más detalles

Portafolio de servicios

Portafolio de servicios Portafolio de servicios Calle 613 No. 175 Oficina J, Col. Aragón 4ª y 5ª Sección, México, D.F. Teléfonos: 63.85.75.55 y 63.83.06.37 www.aztecsoluciones.com Aztec Soluciones Tecnológicas, S.A. de C.V. es

Más detalles

Introducción a las redes de computadores

Introducción a las redes de computadores Introducción a las redes de computadores Contenido Descripción general 1 Beneficios de las redes 2 Papel de los equipos en una red 3 Tipos de redes 5 Sistemas operativos de red 7 Introducción a las redes

Más detalles

Hacia la evolución de las necesidades del centro de datos

Hacia la evolución de las necesidades del centro de datos 1 Resumen de la solución Solución de Cisco e IBM Logicalis + VersaStack Hacia la evolución de las necesidades del centro de datos 2 Hacia la evolución de las necesidades del centro de datos Puntos destacados:

Más detalles

Preguntas Frecuentes. Plataforma ScienTI. Aplicativos CvLAC y GrupLAC

Preguntas Frecuentes. Plataforma ScienTI. Aplicativos CvLAC y GrupLAC Preguntas Frecuentes Plataforma ScienTI Aplicativos CvLAC y GrupLAC Departamento Administrativo de Ciencia, Tecnología e Innovación - Colciencias Dirección de Fomento a la Investigación Bogotá D.C., 10

Más detalles

LLEVE SU NEGOCIO al SIGUIENTE NIVEL. digitalice todos sus documentos y procesos.

LLEVE SU NEGOCIO al SIGUIENTE NIVEL. digitalice todos sus documentos y procesos. LLEVE SU NEGOCIO al SIGUIENTE NIVEL. digitalice todos sus documentos y procesos. Qué es mydocument enterprise? MyDOCument Enterprise es una solución de gestión documental diseñada para que las empresas

Más detalles

RESUMEN. HERRAMIENTA DE MONITORIZACIÓN DE SERVIDORES Y EQUIPOS DE RED i2basquenms RESUMEN TRABAJO FIN DE GRADO

RESUMEN. HERRAMIENTA DE MONITORIZACIÓN DE SERVIDORES Y EQUIPOS DE RED i2basquenms RESUMEN TRABAJO FIN DE GRADO eman ta zabal zazu Escuela Universitaria De Ingeniería Técnica Industrial de Bilbao Grado en Ingeniería Informática De Gestión Y Sistemas De Información Trabajo Fin de Grado 2014 / 2015 RESUMEN HERRAMIENTA

Más detalles

INSTALACIÓN DE ORACLE 8i (8.1.7) SOBRE NT

INSTALACIÓN DE ORACLE 8i (8.1.7) SOBRE NT INSTALACIÓN DE ORACLE 8i (8.1.7) SOBRE NT Versión 1. Mayo de 2001 Luis Vinuesa Martínez. Departamento de Informática Universidad de Oviedo vinuesa@correo.uniovi.es www.di.uniovi.es/~vinuesa ÍNDICE. Introducción...

Más detalles

LEY QUE NORMA EL USO, ADQUISICIÓN Y ADECUACIÓN DEL SOFTWARE EN LA ADMINISTRACIÓN PUBLICA

LEY QUE NORMA EL USO, ADQUISICIÓN Y ADECUACIÓN DEL SOFTWARE EN LA ADMINISTRACIÓN PUBLICA ADQUISICIÓN DE SOFTWARE DE CORREO 1. Nombre del Área :. Responsable de la Evaluación : Aldo Quispe Santa María. Cargo : Director (e) de Tecnología de la Información y Sistemas 4. Fecha : de Julio de 007

Más detalles

Architecting a Citrix Virtualization Solution

Architecting a Citrix Virtualization Solution Código: W35 Duración: 30 horas Este curso enseña a los arquitectos CITRIX a analizar y diseñar una completa solución de virtualización de Citrix. Basado en la metodología de servicios de consultoría de

Más detalles

COMO CONFIGURAR UNA MAQUINA VIRTUAL EN VIRTUALBOX PARA ELASTIX

COMO CONFIGURAR UNA MAQUINA VIRTUAL EN VIRTUALBOX PARA ELASTIX COMO CONFIGURAR UNA MAQUINA VIRTUAL EN VIRTUALBOX PARA ELASTIX En este manual se presenta el proceso de configuración de una Maquina Virtual en VirtualBox, que será utilizada para instalar un Servidor

Más detalles

Eficacia operativa en el sector público. 10 recomendaciones para reducir costes

Eficacia operativa en el sector público. 10 recomendaciones para reducir costes Eficacia operativa en el sector público 10 recomendaciones para reducir costes 2 de 8 Introducción Con unos amplios recortes de presupuesto y una presión constante que va en aumento, hoy en día el sector

Más detalles

Cloud Computing. Rodrigo Moreno Rosales DN-11

Cloud Computing. Rodrigo Moreno Rosales DN-11 Cloud Computing Rodrigo Moreno Rosales DN-11 Cloud Computing La computación en la nube,conocido también como servicios en la nube, informática en la nube, nube de cómputo o nube de conceptos, es un paradigma

Más detalles

Curso: Arquitectura Empresarial basado en TOGAF

Curso: Arquitectura Empresarial basado en TOGAF Metodología para desarrollo de Arquitecturas (ADM) El ADM TOGAF es el resultado de las contribuciones continuas de un gran número de practicantes de arquitectura. Este describe un método para el desarrollo

Más detalles

Arquitectura de sistema de alta disponibilidad

Arquitectura de sistema de alta disponibilidad Mysql Introducción MySQL Cluster esta diseñado para tener una arquitectura distribuida de nodos sin punto único de fallo. MySQL Cluster consiste en 3 tipos de nodos: 1. Nodos de almacenamiento, son los

Más detalles

BASES DE DATOS TEMA 3 MODELO ENTIDAD - RELACIÓN

BASES DE DATOS TEMA 3 MODELO ENTIDAD - RELACIÓN BASES DE DATOS TEMA 3 MODELO ENTIDAD - RELACIÓN 3.3 Aplicaciones Definición de Aplicación (Application). Programa informático que permite a un usuario utilizar una computadora con un fin específico. Las

Más detalles

4. Base de datos XML nativa: Marklogic

4. Base de datos XML nativa: Marklogic 4. Base de datos XML nativa: Marklogic XML ha ganado con el paso de los años protagonismo a la hora de trabajar con la información. Su lenguaje fuertemente tipado permite la comunicación entre distintas

Más detalles

Transición de su infraestructura de Windows Server 2003 a una solución moderna de Cisco y Microsoft

Transición de su infraestructura de Windows Server 2003 a una solución moderna de Cisco y Microsoft Descripción general de la solución Transición de su infraestructura de Windows Server 2003 a una solución moderna de Cisco y Microsoft El soporte de Microsoft para todas las versiones de Windows Server

Más detalles

PROCEDIMIENTO OPERATIVO DESARROLLAR SISTEMAS INFORMÁTICOS PDO-COCTI-DTIN-04

PROCEDIMIENTO OPERATIVO DESARROLLAR SISTEMAS INFORMÁTICOS PDO-COCTI-DTIN-04 Autorización Este documento entra en vigor a partir del 2 de agosto del 2005, a través de su autorización por parte del Dr. Francisco Javier Rojas Monroy, Coordinador de Operaciones, Calidad y Teclogía

Más detalles

Infraestructura Tecnológica. Sesión 8: Configurar y administrar almacenamiento virtual

Infraestructura Tecnológica. Sesión 8: Configurar y administrar almacenamiento virtual Infraestructura Tecnológica Sesión 8: Configurar y administrar almacenamiento virtual Contextualización Como sabemos, actualmente los servicios y medios de almacenamiento de información son muy variados,

Más detalles

Manual de usuario Versión: 1.3 Edición: 05/02/2015 1

Manual de usuario Versión: 1.3 Edición: 05/02/2015 1 Manual de usuario Versión: 1.3 Edición: 05/02/2015 1 Índice Formula Integration Manual de Usuario... 3 1. Introducción... 3 1.1. Funcionalidades... 3 2. Instalación... 3 2.1. Requisitos mínimos... 3 2.2.

Más detalles

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los

Más detalles

Instituto Tecnológico de Costa Rica

Instituto Tecnológico de Costa Rica Instituto Tecnológico de Costa Rica Escuela de Ingeniería en Computación Proyecto Programado: Revisión de Utilización Médica: Aplicación Web para el control de pacientes en hospitales de Puerto Rico Práctica

Más detalles

EMC Soporte remoto seguro para VNXe Requisitos y configuración Número de referencia 302-000-196 Rev. 01 Mayo de 2014

EMC Soporte remoto seguro para VNXe Requisitos y configuración Número de referencia 302-000-196 Rev. 01 Mayo de 2014 EMC Soporte remoto seguro para VNXe Requisitos y configuración Número de referencia 302-000-196 Rev. 01 Mayo de 2014 Este documento proporciona información sobre la función de soporte remoto seguro de

Más detalles

UT04 01 Máquinas virtuales (introducción)

UT04 01 Máquinas virtuales (introducción) UT04 01 Máquinas virtuales (introducción) n) Módulo: Sistemas Informáticos Virtualización Qué es una máquina m virtual? Terminología Características, ventajas e inconvenientes de las MVs Productos: VMWare,

Más detalles

Programa de soporte técnico ampliado MSA Start

Programa de soporte técnico ampliado MSA Start 1 1. TÉRMINOS Y CONDICIONES GENERALES En este documento se incluye una lista de casos de soporte técnico, en relación con los que Kaspersky Lab proporcionará asistencia al propietario de este Certificado

Más detalles

Instructivo Asesoría Básica Comunidad Virtual SharePoint 2010

Instructivo Asesoría Básica Comunidad Virtual SharePoint 2010 Instructivo Asesoría Básica Comunidad Virtual SharePoint 2010 CONTENIDO 1. Qué es? 2. Cómo crear y acceder a la Comunidad Virtual en Microsoft SharePoint 2010? Ejemplo. 3. Qué tengo en la página de inicio

Más detalles

GUÍA BÁSICA DE USO DEL SISTEMA RED

GUÍA BÁSICA DE USO DEL SISTEMA RED SUBDIRECCIÓN GENERAL DE INSCRIPCIÓN, AFILIACION Y RECAUDACIÓN EN PERIODO VOLUNTARIO GUÍA BÁSICA DE USO DEL SISTEMA RED Marzo 2005 MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES TESORERÍA GENERAL DE LA SEGURIDAD

Más detalles

La gestión de contenidos en el nuevo Portal del Ministerio de Hacienda

La gestión de contenidos en el nuevo Portal del Ministerio de Hacienda La gestión de contenidos en el nuevo Portal del Ministerio de Hacienda Raquel Poncela González Introducción La aparición de los gestores de contenidos para la gestión de portales ha sido una verdadera

Más detalles

1 Guión de Contenidos... 1. 2 Criterios de evaluación... 2. 3 Momentos de la evaluación... 6. 3.1 Instrumentos o pruebas de evaluación...

1 Guión de Contenidos... 1. 2 Criterios de evaluación... 2. 3 Momentos de la evaluación... 6. 3.1 Instrumentos o pruebas de evaluación... 1 Guión de Contenidos... 1 2 Criterios de evaluación... 2 3 Momentos de la evaluación... 6 3.1 Instrumentos o pruebas de evaluación... 7 3.2 Calificación... 7 1 Guión de Contenidos U.T. 1 - Sistemas de

Más detalles

ANEXO XII. Denominación: Administración y programación en sistemas de planificación de recursos empresariales y de gestión de relaciones con clientes.

ANEXO XII. Denominación: Administración y programación en sistemas de planificación de recursos empresariales y de gestión de relaciones con clientes. ANEXO XII I. IDENTIFICACIÓN DEL CERTIFICADO DE PROFESIONALIDAD Denominación: Administración y programación en sistemas de planificación de recursos empresariales y de gestión de relaciones con clientes.

Más detalles

ORIENTACIONES SIMCE TIC

ORIENTACIONES SIMCE TIC ORIENTACIONES SIMCE TIC Sistema Nacional de Medición de Competencias TIC en Estudiantes ORIENTACIONES SIMCE TIC Sistema Nacional de Medición de Competencias TIC en Estudiantes INDICE Introducción 7 Prueba

Más detalles

Direccionamiento IPv4

Direccionamiento IPv4 Direccionamiento IPV4 Página 1 de 15 www.monografias.com Direccionamiento IPv4 1. Direccionamiento IP 2. Componentes de una dirección IP 3. Determinación de la clase de dirección 4. Determinación de los

Más detalles

CAPITULO 3 MOVILIDAD EN LA NAVEGACIÓN Y ALMACENAMIENTO EN BASES DE DATOS

CAPITULO 3 MOVILIDAD EN LA NAVEGACIÓN Y ALMACENAMIENTO EN BASES DE DATOS CAPITULO 3 MOVILIDAD EN LA NAVEGACIÓN Y ALMACENAMIENTO EN BASES DE DATOS La introducción de las redes locales marca una nueva etapa en la evolución de las computadoras personales al permitir ligar varias

Más detalles

Redes de Nueva Generación Área de Ingeniería Telemática. Virtualización

Redes de Nueva Generación Área de Ingeniería Telemática. Virtualización Virtualización Virtualización: Ejemplos Virtualización? La idea básica de virtualización del host es bastante conocida Una capa software intermedia hace creer a un sistema operativo que tiene hardware

Más detalles

DIPLOMADO EN SEGURIDAD INFORMATICA

DIPLOMADO EN SEGURIDAD INFORMATICA DIPLOMADO EN SEGURIDAD INFORMATICA Modulo 9: Soporte Computacional Clase 9_3:Protocolos de comunicación y conectividad de arquitecturas multiplataforma. Director Programa: César Torres A Profesor : Claudio

Más detalles

Servinómina. Servicio de Visualización de Nóminas. (Servinómina) Agosto de 2013. Página 1 de 8 MINISTERIO DE HACIENDA Y ADMINISTRACIONES PÚBLICAS

Servinómina. Servicio de Visualización de Nóminas. (Servinómina) Agosto de 2013. Página 1 de 8 MINISTERIO DE HACIENDA Y ADMINISTRACIONES PÚBLICAS Servinómina Agosto de 2013 Página 1 de 8 ÍNDICE 1 INTRODUCCIÓN... 3 2 SERVINÓMINA... 3 3 OBSERVACIONES... 3 4 CARACTERÍSTICAS Y FUNCIONAMIENTO... 3 4.1 SEGURIDAD... 4 4.2 SERVIDORES COMPARTIDOS... 4 4.3

Más detalles

Q-expeditive Publicación vía Internet

Q-expeditive Publicación vía Internet How to Q-expeditive Publicación vía Internet Versión: 2.0 Fecha de publicación 11-04-2011 Aplica a: Q-expeditive 3 Índice Introducción... 3 Publicación de servicios... 3 Ciudadanos... 3 Terminales de auto

Más detalles

Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT

Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT Proyecto de Fin de Carrera Universidad Politécnica de Valencia Escuela Técnica Superior de Informática Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT Realizado por: Dirigido

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Emprendiendo negocios juntos

Emprendiendo negocios juntos Emprendiendo negocios juntos Definiendo Cloud Computing Un modelo que permite de manera muy sencilla el acceso a una red de recursos informáticos, los cuales con poco esfuerzo son configurables por el

Más detalles

Productos y Servicios Portafolio

Productos y Servicios Portafolio Productos y Servicios Portafolio Información general: Itevolution S.A. de C.V. 2014-1- Quiénes Somos? Itevolution es una presa mexicana enfocada a la asesoría licenciamiento Microsoft y servicios de consultoría

Más detalles

Servicio de publicación de información web (HTTP)

Servicio de publicación de información web (HTTP) Servicio de publicación de información web (HTTP) La Web es uno de los servicios más comunes en Internet, tanto que se ha convertido en su cara visible para la mayoría de los usuarios. Una página Web empezó

Más detalles

METODOLOGÍA E IMPLEMENTACIÓN DEL SIGGA (SISTEMA DE INFORMACION GEOGRAFICA: GOBERNANZA DEL AGUA)

METODOLOGÍA E IMPLEMENTACIÓN DEL SIGGA (SISTEMA DE INFORMACION GEOGRAFICA: GOBERNANZA DEL AGUA) METODOLOGÍA E IMPLEMENTACIÓN DEL SIGGA (SISTEMA DE INFORMACION GEOGRAFICA: GOBERNANZA DEL AGUA) I.1 Definición de SIG Es un sistema compuesto por hardware, software y procedimientos para capturar, manejar,

Más detalles

Google Calendar. Google Calendar

Google Calendar. Google Calendar Google Calendar Tabla de contenido Tabla de contenido... 2 Introducción... 3 Qué es Google Calendar?... 3 Acceder y crear una cuenta de Google Calendar... 4 Creación de eventos... 11 Envío de invitaciones...

Más detalles