estudio de una solución openstack integrada con sdn ...€¦ · y el de muchas empresas del sector...

Estudio de una solución OpenStack integrada con SDN

Trabajo de Fin de Grado

Presentado en

Escola Tècnica d'Enginyeria de Telecomunicació deBarcelona

Universitat Politècnica de Catalunya

por

Emilio Soca Herrera

Grado en Ingeniería Telemática

Tutor: José Luis Muñoz Tapia

Barcelona, Octubre 2015

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, sothe 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 intoour 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.

Resum

El present projecte té com a objectiu realitzar un estudi de la tecnologia CloudOpenStack i la seva integració amb el paradigma SDN. El projecte s'ha dividit en duesgrans fases:

Estudi i desplegament de OpenStack:

OpenStack presenta una arquitectura altament distribuïda, composta de diversos mòdulso 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 decada sector TIC provocant que l'estudi de la plataforma sigui un veritable repte. Elsserveis principals de OpenStack, així com les tecnologies en què es basen, s'han detallaten el projecte.Posteriorment s'ha realitzat el complex desplegament d'OpenStack en una màquinapersonal amb l'ús de tecnologies de virtualització (lxc i KVM) i el switch OpenvSwitch perconnectar-les. S'han detallat les decisions de disseny del desplegament, així com elspassos i els errors trobats.

Estudi de SDN i integració de OpenDaylight:

A la segona fase del projecte s'estudien l'arquitectura, protocols i components delparadigma SDN. Es tria el controlador SDN OpenDaylight per ser integrat en el nostredesplegament de OpenStack i s'expliquen les possibilitats que ofereix.Finalment s'executa la integració de OpenDaylight explicant les decisions de disseny, elspassos i els errors trobats.

Resumen

El presente proyecto tiene como objetivo realizar un estudio de la tecnología CloudOpenStack y su integración con el paradigma SDN. El proyecto se ha dividido en dosgrandes fases:

Estudio y despliegue de OpenStack:

OpenStack presenta una arquitectura altamente distribuida, compuesta de diversosmódulos o servicios que se encargan de una funcionalidad en concreto(almacenamiento, redes, cómputo, etc). Por otra parte, OpenStack se nutre de lastecnologías más punteras de cada sector IT provocando que el estudio de la plataformasea un verdadero reto. Los servicios principales de OpenStack, así como las tecnologíasen las que se basan, se han detallado en el proyecto.

Posteriormente se ha realizado el complejo despliegue de OpenStack en una máquinapersonal con el uso de tecnologías de virtualización (LXC y KVM) y el switchOpenvSwitch para conectarlas. Se han detallado las decisiones de diseño deldespliegue, 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.

Agradecimientos

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

Revision history and approval record

Revision Date Purpose

0 14/10/2015 Document creation

1 15/10/2015 Document revision

DOCUMENT DISTRIBUTION LIST

Name e-mail

Emilio Soca Herrera [email protected]

José Luis Muñoz Tapia [email protected]

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

Tabla de contenidos

Abstract.............................................................................................................................1

Resum...............................................................................................................................2

Resumen...........................................................................................................................3

Agradecimientos................................................................................................................4

Revision history and approval record.................................................................................5

Tabla de contenidos...........................................................................................................6

1.Introducción....................................................................................................................8

1.1.Objetivos del proyecto..............................................................................................8

1.2.Requisitos y especificaciones...................................................................................8

1.3.Recursos de terceros...............................................................................................9

1.4.Plan de trabajo (Work plan)......................................................................................9

1.5.Desviaciones del proyecto original.........................................................................14

2.Estado del arte:.............................................................................................................15

2.1.OpenStack.............................................................................................................15

2.2.OpenDayLight........................................................................................................15

2.3.LXC........................................................................................................................15

2.4.OpenvSwitch..........................................................................................................15

3.Metodología..................................................................................................................16

4.Resultados....................................................................................................................17

5.Presupuesto.................................................................................................................18

6.Conclusiones y trabajos futuros....................................................................................19

6.1.Conclusiones.............................................................................................................19

6.2.Trabajos futuros.........................................................................................................19

Bibliografía.......................................................................................................................20

Apéndices :......................................................................................................................21

1. Introducción

El objetivo de este documento es ofrecer un resumen ejecutivo del proyecto. Ladocumentación detallada de las tecnologías estudiadas e implementadas se encuentrananexadas a esta memoria.

1.1. 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 laaltura 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.

1.2. Requisitos y especificaciones

Los requisitos del proyecto se pueden agrupar en dos categorías: requisitos teóricos yrequisitos técnicos.

Requisistos teóricos:

- Redes (Routing, VPN, OpenFlow, SDN).

- Almacenamiento (Objetos, bloques, ficheros).

- 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]

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

Internal task T2: Preparación de las maquinas virtuales KVMpara los nodos que no permitan una instalación con LXC (Porejemplo devStack funciona mejor con KVM)

Deliverables: Dates:

Project: WP ref: WP2

Major constituent: Lectura y aprendizaje

Short description:

Aprendizaje sobre OpenStack y OpenDaylight: Arquitecturas,componentes, buenas prácticas, etc. Documentación.




End event: 28/09/2015

Internal task T1: Familiarizarse con las herramientas de redusadas para el proyecto como OvS, brctl y otras herramientas deLinux

Internal task T2: Conocer con profundidad OpenStack

Internal task T3: Conocer OpenDaylight

Internal task T4: Documentación




Short description:

Implemtación del sistema OpenStack y pruebas.




End event: 14/06/2015

Internal task T1: Montar todos los nodos de Openstack de formavirtual y configurarlos adecuadamente.

Internal task T2: Levantar VM dentro de OpenStack, reservaralmacenamiento.




Short description:

Integración del sistema OpenDayLight dentro del sistemaOpenStack.




End event: 28/09/2015

Internal task T1: Integrar Controlador SDN.

Internal task T2: Realizar pruebas donde el controlador SDNprovea de redes a las instancias.


Time plan

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.

2. Estado del arte:

2.1. OpenStack

Openstack se define comercialmente como un sistema operativo en la nube que permitecontrolar recursos de computación, almacenamiento y redes a través de un dashboard ocuadro de mando y APIs estándares de programación. Su arquitectura es distribuida yutiliza diferentes tipos de nodos especializados en distintos servicios y conectadosmediante redes de gestión y datos. [2]

2.2. OpenDayLight

OpenDayLight es un Controlador SDN, Open Source, escrito en Java e implementadodentro 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 seencuentra 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 desistema operativo. El sistema host comparte el kernel con cada una de las instancias ocontenedores de LXC, provocando que se consuman menos recursos a igual carga detrabajo. Usa las tecnologías de Namespaces y Cgroups desarrolladas en el Kernel deLinux.

2.4. OpenvSwitch

OpenvSwitch (OVS) es un sofware Open Source que actúa como un switch virtualmulticapa. Su objetivo es implementar una plataforma que soporte los protocolos de redestándares y permitir que las funciones de encaminamiento puedan ser programadas.

3. Metodología

El análisis y resolución de incidencias producidas durante el despliegue de OpenStack yOpenDayLight 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 pararestablecer la comunicación.

- Desde el nodo Controlador ejecutar el comando neutron agent-list para verificarcuales agentes de Neutron están funcionando correctamente.

- Desde el nodo Controlador ejecutar el comando nova service-list para verficar cualesservicios de Nova están funcionando correctamente.

- Reiniciar los subservicios que presenten problemas. Por ejemplo, si el subservicionova-cert no funciona correctamente se debe ejecutar el comando service nova-certrestart 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 laterminal o en los ficheros de logs.

- Para problemas de conectividad en red de las instancias se recomienda el uso detcpdump. Tcpdump es un analizador de redes que funciona vía consola. Como nonecesita interfaz gráfica podemos ejecutarlo en los nodos y ponerlo a la escucha en unainterfaz para investigar en que interfaz o nodo se pierde la conexión.

- Para comprobar la conectividad con routers o instancias virtuales que se encuentren enotras net namespaces se recomienda el uso del comando ip netns exec <namespace>ping <ip>

4. Resultados

Los resultados más relevantes del proyecto son los siguientes:

- El despliegue de OpenStack y OpenDayLight se realizó satisfactoriamente. El sistemalanzaba instancias, creaba redes internas y externas, asignaba almacenamiento, IPsflotantes y consolas VNC a las instancias. Horizon reflejaba la topografía de los tenants yen ODL Dlux se veía la topología de los switches virtuales OpenvSwitch. El sistemafuncionaba de forma estable y rápido teniendo en cuenta que todos los nodos corríansobre un portatil i7 y 6GB de RAM.

- El despliegue de OpenStack no es una tarea sencilla. Solo para hacer funcionar elsistema se necesitan configurar un gran número de servicios y subservicios que seencuentran en diferentes nodos “físifcos”. El problema se complica un poco más cuandolos supuestos nodos “físicos” también están virtualizados. El uso de la metodología en elapartado 3 de este documento ha sido vital para lograr que OpenStack funcionasefinalmente.

- 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 modosde 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últiplesposibilidades 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 elnodo donde debe correr un servicio determinado.

- Hacer el despliegue manual de OpenStack es recomendable al menos una vez paraentender los entresijos de las configuraciones. Para posteriores despliegues es máseficiente herramientas de automatización como Puppet, Ubuntu JUJU, etc.

- La documentación oficial de OpenStack se encuentra muy organizada y con suficientetiempo podemos conocer y desplegar todo el sistema Cloud. Sin embargo, no heencontrado la documentación de OpendayLight a la altura (al menos en lo que respectaa su integración con OpenStack). Cada nueva versión de OpenDayLight puede traerinconsistencias con la versión anterior, por ejemplo la nueva versión ODL Lithium no secomunica correctamente con Neutron por defecto y debemos realizar cambios en losficheros de OpenStack.

- La resolución de todos los problemas encontrados se encuentra en el documentoanexo y espero sirva de ayuda para aquellas personas que intenten desplegarOpenStack Juno Y OpenDayLight Lithium en contenedores LXC y máquinas virtualesKVM.

5. Presupuesto

Todos las tecnologías usadas en el proyecto (OpenStack, OpenDayLight, LXC, etc) estánlicenciadas bajo una licencia Open Source gratuitas (Apache, GPL, etc). Los sistemasoperativos utilizados han sido Linux Mint 17 en el sistema host y Ubuntu Server 14.04 enlos nodos, sistemas que son de Código Abierto y gratuitos. Es decir, el software noañade ningún costo al proyecto.

Las horas estimadas dedicadas al proyecto han sido 600h. Teniendo en cuenta elmercado laboral actual de España, me parece razonable tomar el coste (sueldo brutomás cotizaciones a la seguridad social por la empresa) de un ingeniero recién graduadode 13 €/h. Finalmente el coste total de la tesis asciende a 7800€.

6. Conclusiones y trabajos futuros

6.1. Conclusiones

Al conocer y experimentar todas las opciones de OpenStack puedo decir que el CloudComputing es vital para el desarrollo digital de un negocio. Luego de configurar elcomplejo engranaje el cliente puede consumir recursos de almacenamiento, redes ycómputo de forma flexible y barata. Poder guardar mis backups en Swift, las bases dedatos en Cinder, tener varias redes virtuales para hacer pruebas y aumentar el númerode instancias según la carga de trabajo son opciones muy valiosas que permiten lanzarnegocios digitales a escala mundial. Con el desarrollo de nuevos servicios OpenStackofrecerá aún más alternativas bajo demanda (DNS, Bare metal, Hadoop, etc).

Por otro lado OpenDayLight debe seguir avanzando y mejorar su estabilidad. SDNaporta notables mejoras al diseño de redes y OpenDayLight debe liderar su desarrollocomo principal Controlador Open Source.

Integrar OpenDayLight en OpenStack tiene dos ventajas principales: El uso de serviciosde red especiales como el “Unified Secure Channe” que cifra todas las comunicaciones yel soporte de varios protocolos de SouthBound como NETCONF y BGP ya soportadospor OpenDayLight.

6.2. Trabajos futuros

La posibilidad de trabajos futuros a partir de esta documentación es muy amplia. Esteproyecto realiza un fotografía de alto nivel a un sistema OpenStack y explica las basesde 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 losbackends Open Source como Ceph, Gluster, etc. O hacer una comparación detalladaentre almacenamiento de objetos, de ficheros y de bloques.

- Relacionado con redes, podría explicar detalladamente OpenDayLight o las redessuperpusetas (GRE, VXLAN)

- En el área de cómputo podría explicar el funcionamiento detallado de KVM, LXC oDOCKER.

- 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.

Bibliografía

[1] Marcel Sánchez Toledano. ESTUDI I IMPLEMENTACIÓ D'UN SISTEMA DE VIRTUALITZACIÓBASAT EN LINUX CONTAINERS

http://upcommons.upc.edu/bitstream/handle/2099.1/23590/Marcel%20Sanchez%20-%20TFG.pdf?sequence=4

[2] Comunidad OpenStack.

https://www.openstack.org/

[3] Comunidad OpenDayLight.

https://www.opendaylight.org/

[4] Canonical. Proyecto LXC .

https://linuxcontainers.org/

[5] Comunidad OpenvSwitch

http://openvswitch.org

http://openvswitch.org/

https://linuxcontainers.org/

https://www.opendaylight.org/

https://www.openstack.org/



Apéndices :

El apéndice de este documento es la memoria principal del Proyecto.

Trabajo Final de Grado

Emilio Soca

Estudio de una solución Openstack integrada con SDN

Contents

1 Cloud Computing 71.1 ¿Qués es el Cloud Computing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Tipos de sistemas Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 OpenStack 112.1 ¿Qué es OpenStack? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Arquitectura básica de OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Servicios principales de OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Horizon Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 Nova Compute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.3 Keystone Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.4 Neutron Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.5 Swift Object Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.6 Cinder Block Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.7 Glance Image Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.8 Ceilometer Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.9 Heat Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Flujo de peticiones para levantar una instancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5 Otras tecnologías relacionadas con OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5.1 Tecnologías de Cómputo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.5.2 Tecnologías de Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.5.3 Tecnologías de Almacenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.5.4 Tecnologia de Colas de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.6 Servicios en desarrollo de OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Despligue de OpenStack 333.1 Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 Despliegue de Infraestructura inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.1 Instalación y configuración de LXC para el nodo de Red y el nodo Controlador . . . . . . . . 353.2.2 Instalación y configuración la máquina virtual KVM para el nodo de Cómputo . . . . . . . . 373.2.3 Instalación y configuración de OpenvSwitch para conectar los nodos . . . . . . . . . . . . . . 38

3.3 Despliegue de OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.1 Entorno básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3.1.1 Instalación y configuración de DNS y hostname . . . . . . . . . . . . . . . . . . . 403.3.1.2 Instalación y configuración de NTP . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.1.3 Instalación de los paquetes de OpenStack . . . . . . . . . . . . . . . . . . . . . . . 433.3.1.4 Instalación y configuración de las bases de datos . . . . . . . . . . . . . . . . . . . 433.3.1.5 Instalación y configuración del servidor de colas . . . . . . . . . . . . . . . . . . . 443.3.1.6 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.3.1.7 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.3.2 Instalación y configuración de KeyStone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.2.1 Configuración inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.2.2 Creación de clientes, usuarios y roles . . . . . . . . . . . . . . . . . . . . . . . . . 463.3.2.3 Creación de la entidad del servicio y API endpoints . . . . . . . . . . . . . . . . . 473.3.2.4 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3.2.5 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3.2.6 Scripts OpenRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3.3 Instalación y configuración de Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.3.3.1 Configuración Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.3.3.2 Integración en KeyStone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.3.3 Instalación de componentes de Glance . . . . . . . . . . . . . . . . . . . . . . . . 503.3.3.4 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.3.3.5 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.3.4 Instalación y configuración de Nova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.4.1 Configuración inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.4.2 Integración en KeyStone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.4.3 Instalación de componentes de Nova . . . . . . . . . . . . . . . . . . . . . . . . . 533.3.4.4 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.3.4.5 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.3.5 Instalación y configuración de Neutron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3.5.1 Configuración inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3.5.2 Integración en KeyStone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3.5.3 Instalación de componentes de Neutron . . . . . . . . . . . . . . . . . . . . . . . . 573.3.5.4 Creación de redes iniciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.3.5.5 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.3.5.6 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.3.6 Instalación y configuración de Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.3.6.1 Instalación de componentes de Horizon . . . . . . . . . . . . . . . . . . . . . . . . 663.3.6.2 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.3.6.3 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.3.7 Levantar una Instancia y lograr acceso externo . . . . . . . . . . . . . . . . . . . . . . . . . 663.3.7.1 Generación de par de claves (key pair) . . . . . . . . . . . . . . . . . . . . . . . . 673.3.7.2 Levantamiento de la instancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.3.7.3 Acceso a través de la consola virtual . . . . . . . . . . . . . . . . . . . . . . . . . 683.3.7.4 Permitir acceso externo a la instancia . . . . . . . . . . . . . . . . . . . . . . . . . 683.3.7.5 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4 SDN y OpenDayLight 714.1 ¿Qué es SDN? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.2 Arquitectura de SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.3.1 Switch OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.3.2 Mensajes del Protocolo OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.4 Controlador OpenDaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.4.1 OpenDaylight y OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5 Integración de OpenDayLight 795.1 Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2 Despliegue de Infraestructura inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.2.1 Instalación y configuración de LXC para el nodo OpenDayLight . . . . . . . . . . . . . . . . 805.2.2 Configuración de OpenvSwitch para conectar el nodo opendaylight . . . . . . . . . . . . . . 81

5.3 Instalación e integración de OpenDayLight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.3.1 Cambios iniciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.3.2 Instalación de OpenDayLight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.3.3 Eliminación de instancias, routers y puertos anteriormente creados . . . . . . . . . . . . . . . 855.3.4 Nueva configuración de OpenvSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.5 Configuración del plugin ML2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.3.6 Reinicio de la base de datos de Neutron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.3.7 Modificación de fichero Neutron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.3.8 Verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.3.9 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5

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 prestanservicios de almacenamiento, acceso y uso de recursos informáticos radicados en la red. Toda la gestión del hardwarees realizada por el proveedor de Cloud Computing asegurando cierta disponibilidad y potencia bajo unos niveles deservicio determinados (SLAs).

De esta forma el cliente o usuario puede desentenderse de los recursos físicos y enfocarse en la actividad centralde su negocio (desarrollo web, red privada empresarial, etc). Por otra parte un usuario final no necesita un dispositivode 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 losEstados 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 al-macenamiento o capacidad de cómputo, sin requerir la interacción humana del proveedor de servicio.

7

• Acceso amplio desde la red: Todos los servicios deben ser accesibles a través de estándares y plataformascomunes(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 consum-idores a través de un modelo multi-tenancy1. De esta manera los recursos físicos y virtuales se asignarán oreasignará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 asignadosdeben 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 demétricas que permitan un nivel de abstracción apropiado al tipo de servicio. Los recursos deberán ser monitor-izados 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 alusuario o empresa que desea hacer uso de ellos. Normalmente el proveedor Cloud cobra según el tiempoy capacidad de los recursos. Tiene como ventaja un aumento de recursos sin la necesidad de instalar ymantener las máquinas en local. De esta manera se reduce la inversión inicial y permite gran escalabilidada empresas que necesiten el uso de estos recursos digitales. Como inconvenientes encontramos la depen-dencia 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 denuestro software o producto.

– Nube Privada: En la nube privada los servicios se encuentran dentro de las instalaciones del usuario oempresa que hará uso de ellos. Normalmente las nubes privadas se implementan para la obtención deinfraestructura (IaaS) como máquinas virtuales, contenedores, almacenamiento, redes, etc. En este casoserá más sencillo integrar los servicios Cloud con sistemas propietarios y la seguridad y carga de trabajocorrerá a cargo de la empresa. El principal inconveniente se encuentra en la inversión inicial del hardwarey de operarios capacitados para mantener la infraestructura física y lógica de la instalación. Es una víapoco 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 empresapuede mantener el control de sus aplicaciones principales y aprovechar la flexibilidad de una nube públicapara un tarea o momento determinado. Las nubes híbridas ofrecen la promesa de la escalabilidad provi-sionada 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 sobrelas anteriores debido a su versatilidad.

– Nube Comunitaria: Son nubes implementadas para el uso exclusivo de una comunidad, normalmenteorganizaciones que comparten asuntos (por ejemplo, la red de policía, red de hospitales, etc).

1En el contexto de Cloud Computing el término Tenant se entiende como un usuario o grupo de usuarios que comparten acceso común a unainstancia con privilegios específicos. Todas las traducciones del término en español presentan pérdidas de significado, así que para el desarrollo delproyecto se mantendrá el término en inglés Tenant.

8

La figura 1.2 muestra el esquema del traspaso de la carga de trabajo de aplicaciones en nubes federadas. Bási-camente, resume el objetivo principal de una nube híbrida.

Nube Privada Nube Pública

Nube Híbrida

Management

Cloud Os

Management

Cloud Os

Carga deApp

Carga deApp

Carga deApp

Nubes Federadas

Figure 1.2: Nube híbrida.

• Según el modelo de servicio tenemos 3 clasificaciones2.

– Software as a Service (SaaS): El Software como Servicio permite al cliente final usar una aplicación quecorre sobre una infraestructura cloud. La aplicación debe ser fácilmente accesible ya sea a través de la webo a través de un cliente de escritorio. El usuario no puede controlar la infraestructura subyacente comolos 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 supropio sistema de programación a través de lenguajes de programación, librerías, APIs, servicios y otrasherramientas. El desarrollador no puede controlar la infraestructura subyacente como los sistemas opera-tivos, redes o almacenamiento. Ejemplos de PaaS son OpenShift, CloudFoundry, IBM Bluemix y GoogleApp Engine.

– Infrastructure as a Service (IaaS): La Infraestructura como Servicio permite a un operador de red ges-tionar el poder de cómputo, almacenamiento, conexionado de redes y otros recursos fundamentales paraofrecer 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 proveedorse 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.

2En la actualidad se está desarrollando una nueva clasificación de Cloud Computing: Metal as a Service. El MaaS permite al usuario el controltotal 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 queprecisan de este nivel de control (Bancos, Gobiernos, etc). Ejemplos de MaaS son Ubuntu MaaS, BigStep y RackSpace OnMetal.

9

SaaS

PaaS

IaaS

Usuariosfinales

Desarrolladores de aplicaciones

Operadores de red yadministradores de sistemas

Niv

el d

e ab

stac

ción

Fle

xibi

lidad

Figure 1.3: Tipos de Clouds.

Para el proyecto se ha elegido la plataforma de Cloud Computing OpenStack por su formato Open Source y elgran apoyo recibido por el sector privado.

10

Chapter 2

OpenStack

2.1 ¿Qué es OpenStack?

Openstack se define comercialmente como un sistema operativo en la nube que permite controlar recursos de com-putación, almacenamiento y redes a través de un dashboard o cuadro de mando y APIs1 estándares de programación[3]. Su arquitectura es distribuida y utiliza diferentes tipos de nodos especializados en distintos servicios y conectadosmediante 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.

Nodo deRedes

Nodo deAlmacena-

miento

Nodo deComputo

Servicios compartidos entrenodos de OpenStack

Hardware estandar

Aplicaciones externas

APIs

NodoControlador

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 enotros lenguajes de programación siempre respetando las APIs REST2. Para el proyecto se ha usado la versión Juno deOpenStack.

1API se refiere a "Application Programming Interface" y es el conjunto de funciones o métodos que ofrece cierta biblioteca o servicio para serutilizado por otro software independiente como una capa de abstracción.

2REST quiere decir "Representational State Transfer" y orginalmente se refería a un conjunto de principios de arquitectura de software. Enla actualidad se usa para describir una interfaz entre sistemas que utilice HTTP para obtener datos o ejecutar operaciones sobre datos usando losformatos XML y JSON.

11

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ónse logra a través de interfaces de programación de aplicaciones (APIs) que cada servicio ofrece y consume. De estaforma 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 incluirinicialmente 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 configu-ración estándar de OpenStack.[2]

Heat

Horizon

Neutron

Cinder Nova

Ceilometer

Glance Swift

Keystone

Instancia

Orquesta la nube

Provee interfazgráfica


Provee conectividadde red

Monitoriza

Monitoriza


Provee imágenesProveevolúmenes

Provee autentificación



Realiza Backups de volúmenes

Puede almacenarimágenesControla ciclo

de vida

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 arqui-tecto Cloud. Cada servicio a su vez se divide en varios componentes o subservicios, por ejemplo el Nodo de Cómputoes el referente del servicio Nova Compute y aloja el subservicio nova-compute. El resto de subservicios como nova-apiy nova-sheduler se alojan en el nodo Controlador. A medida que avanza el desarrollo de OpenStack los servicios seactualizan o se reemplazan totalmente, provocando el cambio de nombre en el servicio. Por ejemplo el servicio de redusado 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

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.

horizon

Base de datosDe horizon

Horizon Dashboard

swift-proxy

glance-apinova-api

cinder-api

neutron-server keystone

Usuarios de OpenStack

HTTP(S)

API de almacenamiento en bloque

API de red

API de cómputo

API de imágenes

API de identificación

API de objetos

Figure 2.3: Componentes y relaciones del servicio Horizon.

Características principales[4]:

• Es un aplicación web basada en Django3.

• Se encuentra implementado a través de mod_wsgi4 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 visualiza-ción y funcionalidad del dashboard.

2.3.2 Nova Compute

Nova Compute transforma bajo demanda los pedidos de usuarios en máquinas virtuales o contenedores. Es el servicioresponsable 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 detrabajo lo justifica. Constituye una parte fundamental y estará incluido en nuestra instalación de OpenStack.

3Django es un framework escrito en python para desarrollar aplicaciones web.4mod_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

La figura 2.4 muestra los componentes de Nova y las relaciones con componentes del resto de servicios.

nova-api

Base de datos de nova

Nova Compute

glance-api

neutron-server

keystone


API de cómputo

API de red


nova-compute

hypervisor

nova-consoleauthnova-sheduler

cola

Nova-novncproxy

AWS EC2 API VNC

Libvirt,XenAPI,etc

API de imágenes

API de imágenes

AMQP

horizonAPI de cómputo

nova-conductor

AMQPAMQP

AMQP AMQP

AMQP

cinder-api

API de almacenamientoen bloque

nova-cert

AMQP

Figure 2.4: Componentes y relaciones del servicio Nova.

Características principales:

• El cliente nova-api se encarga de aceptar y responder las peticiones del usuario final, ya sea a través del APIde OpenStack Compute, del API de Amazon EC2 o de Horizon. A su vez, interacciona con KeyStone paralograr autenticación y puede hacer petición a glance-api para comprobar la disponibilidad de imágenes5 paralas instancias. Inicia la mayoría de actividades como el lanzamiento de una instancia. Existe otro subservicioasociado llamado nova-api-metadata que acepta peticiones de meta-datos de las instancias, pero normalmentese 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 ins-tancias de VMs6 a través de la API del hipervisor7 correspondiente. Por ejemplo, tenemos XenAPI para elhipervisor XenServer, libvirt para KVM o QEMU y VMwareAPI para VMware. Básicamente, nova-computeacepta acciones de la cola y ejecuta una serie de comandos como lanzar la instancia y actualizar su estado en labase de datos. También se comunica con neutron-server para conectar las instancias a las redes virtuales y concinder-api para montar volúmenes en dichas instancias. Finalmente nova-compute gestiona el almacenamientoefí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 contene-dores8 (contenerización). Nova ya puede crear instancias de contenedores LXC o Docker a través de módulosespeciales pero el soporte de funcionalidades es muy bajo en comparación con la virtualización estandar. Noobstante, la contenerización permite mucha mayor eficiencia en el uso de los recursos de cómputo. Por defectonova-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ómputodebería ejecutarse, actualizando el estado en la base de datos. Es decir, se encarga de la planificación de losrecursos de cómputo.

• El componente nova-conductor media en las interacciones entre nova-compute y la base de datos. No se debedesplegar en el mismo nodo donde corra nova-compute por motivos de seguridad.

5Una Imagen es un archivo informático donde se almacena una copia o imagen exacta de un sistema de archivos o ficheros.6VM se refiere a "Virtual machine" o máquina virtual7Hipervisor 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.8Un Contenedor es una instancia que utiliza el propio kernel del sistema operativo "host".

14

• El componente nova-consoleauth autoriza tokens para usuarios que deseen acceder a proxis de consola. Comoproxis de consola existen nova-novncproxy, nova-spicehtml5proxy y nova-xvpnvncproxy. En nuestro proyectousaremos nova-novncproxy.

• El componente nova-novncproxy provee un proxy para acceder a instancias en ejecución a través de VNC9.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 instan-cias (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 imple-menta con RabbitMQ, pero se puede usar otra cola basada en el protocolo AMQP como Apache Qpid o ZeroMQ.

• Un usuario al crear una instancia debe elegir un flavor o sabor que representa un tipo de configuración de recursosvirtuales 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 Neu-tron respectivamente. nova-network se encuentra funcionando en producción en muchos de los primeros sis-temas Cloud desplegados, pero se aconseja su reemplazo por el servicio Neutron para nuevos despliegues.

2.3.3 Keystone IdentityKeystone 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 yestará 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.

Keystone

Keystone Identity

swift-proxy

glance-apinova-api

cinder-api

neutron-server



Backend de identidades(kvs,sql,ldap,etc)

Backend de políticas(reglas,etc)

Backend de Tockens (kvs,memcache, etc)

Backend de Catálogos (kvs,sql, etc)




horizonAPI de identificación



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 paraentender el servicio.

• Usuario: Representación digital de una persona o sistema que usa OpenStack. KeyStone valida las peticionesdel usuario a través de confirmación de las credenciales. Se pueden asignar tokens a un usuario para accedera un recurso determinado, por ejemplo para el acceso a la consola VNC. Un usuario puede ser asignado a untenant 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 APIkey o un token de autenticación.

9VNC significa "Virtual Network Computing" y permite tomar el control de un servidor remoto a través del entorno gráfico.

15

• Token: Linea de caracteres alfanuméricos usados para acceder a los recursos y APIs de OpenStack. Un tokenpuede 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 osubscriptor. En el contexto interno de la arquitectura Cloud, existe el tenant "service" que identifica en KeyStonea todos los servicios de OpenStack.

• API end-point: Dirección accesible desde la red donde se encuentra el API del servicio, normalmente unadirección URL.

• Rol: Define los privilegios que tiene un usuario frente a un tenant asociado. Es decir, un usuario puede seradministrador de un tenant y usuario sin privilegios en otro tenant determinado. Es posible definir más rolespero 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 peticionesque le llegan a su API. Cuando desplegamos un nuevo servicio este debe ser registrado en la base de datos deKeyStone.

• Provee de un catálogo de servicios disponibles a los usuarios y sus API end-points para consumo de otrosservicios 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 laautenticación.

• Cada función de Keystone (politicas, catálogos de servicios, tokens, autenticación) tiene un backend vinculablecon distintas posibilidades de usar el servicio. Keystone soporta backends estándares como LDAP, SQL oKVS(Key-Value Stores).

2.3.4 Neutron NetworkNeutron 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 Quan-tum, pero debido a problemas de copyright tuvo que cambiar su nombre a Neutron. Constituye una parte fundamentaly 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 nova-network 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 delAPI de red de OpenStack. Un plug-in puede usar cualquier tecnología que le permita implementar la lógica delAPI de red. Por ejemplo, algunos plug-ins usan VLANs e IPtables de Linux, mientras que otros usan OpenFlowo 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 endiferentes nodos del sistema Cloud que le ayudan a cumplir su función, por ejemplo el plug-in OVS necesita unagente 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 suestructura modular. Dicho plugin se comporta como un framework para nuevos subplug-ins o drivers conocidoscomo "Mechanism Driver" del plug-in ML2. Es decir, un programador puede implementar funciones de capa2 desarrollando un plug-in completo o escribiendo un driver para el plug-in ML2 que requiere menos código

16

neutron-serverNeutron Network


API de red

Base de datosde Neutron

API de red

API de identificación horizon

API de red

cola

agentes de Neutron

plugins de Neutron

proveedor de red

(Cisco, Hp,OVS,etc)

keystone

nova-computeAMQP

AMQP

AMQP

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 tec-nologías de red de capa 2 que se encuentran en la mayoría de centros de datos (VLANs, Túneles GRE, TúnelesVXLAN).

El siguiente diagrama muestra la arquitectura modular del plug-in ML2 y el soporte de tecnologías L2 paraOpenStack Juno.

Type Manager Mechanism manager

Arista

Cisco NexusHyper-V

L2 Population

Linuxbridge

Open vSwitch Tail-F NCS

Core Plugin ML2

Neutron

OpenDaylight

GRE

VLAN

VXLAN

Flat

Local

Type Driver Mechanism Driver

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" parala red virtual externa, primero con el "Mechanism Driver" Open vSwitch y luego con el "Mechanism DriverOpenDaylight".

• 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 arquitecturadel sistema Cloud.

Existen dos agentes comunes para todos los plug-ins. El "neutron-l3-agent" brinda enrutamiento L3 y servicioNAT para proveer de acceso externo a las instancias, mientras que el "neutron-dhcp-agent" provee de servicioDHCP para las redes internas.

• Red: Representa un dominio de colisión aislado de capa 2 y virtual. En el contexto Cloud muchas veces sevisualiza 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 redanteriormente creada.

17

• 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 In-frastructure") y solo el acceso a la infraestructura física de red (PNI Physical Networking Infrastruc- ture) en unsistema OpenStack.

• Los plug-ins y agentes de neutron son los que realmente ejecutan tareas de red específicas como el direc-cionamiento 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 porlos 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 proyectosi que es virtual y está en el namespace o espacio de nombres del "sistema host"). Dicha red externa representa ungrupo de las direcciones IP disponibles en la red "física" externa. El resto de redes de Neutron son consideradasinternas 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 undispositivo 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 conKeyStone para lograr autenticación y con nova-compute para desplegar redes virtuales donde se conectan lasinstancias.

• 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.

Red-int-1

Red virtual L2192.168.1.0/24

Subred virtual

Puertos virtuales

vNICs

Instancia B192.168.1.3

Instancia A192.168.1.2

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: "192.168.1.0/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 delagente DCHP.——————————————————————–Si el tenant decide eliminar la instancia

6. El tenant elimina la instancia.

18

7. Nova contacta con Neutron para que destruya el puerto anteriormente creado. Neutron destruye el puertoy 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 fire-wall para dichos grupos. Una instancia puede pertenecer a uno o más "Grupos de seguridad". Las reglas máscomunes 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. Imple-mentaremos 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.

2.3.5 Swift Object StorageSwift se encargar de almacenar y recuperar objetos de datos a través del "Sistema de almacenamiento de objetos". Noestará 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.

swift-proxy

Swift Object Storage

glance-api


API de objetos

Base de datosde cuentas

Base de datosde contenedores

Almacen deobjetos


horizon

account container object

HTTP(S)

API de objetosKeystone

API 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, elsistema 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. EnOpenStack 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 contenedoresdiferentes representa dos objetos.

• Un Objeto es una entidad que almacena información como un documento, imagen o fichero. Posee meta-datosextendidos asociados al datos que contiene y tienen un identificador único que permite su recuperación sinconocer su ubicación física.

19

• Es posible comparar el almacenamiento de objetos con el estacionamiento de un hotel. El cliente intercambialas 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 unaAPI REST genérica accesible para los clientes. Las peticiones pueden ser subidas de ficheros, modificaciónde meta-datos o creación de contenedores. Por otra parte, el swift-proxy puede servir ficheros y un listado deobjetos al navegador del cliente. Swift-proxy se autentica a través de KeyStone y normalmente se comunica conglance-api ya que puede almacenar sus imágenes.

Si proxy-server recibe muchas peticiones podemos añadir una caché opcional, normalmente implementada conmemcache.

• 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 garan-tizar 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 Glancey los posibles backups de volúmenes Cinder. Por supuesto también es posible proveer un servicio de almace-namiento de objetos al cliente para guardar datos de carácter estático.

2.3.6 Cinder Block StorageCinder provee de almacenamiento en bloque a las instancias alojadas en la nube. No estará incluido en nuestrainstalación de OpenStack.

La figura 2.10 muestra los componentes de Cinder y las relaciones con componentes del resto de servicios.

cinder-api

Cinder Block Storage


Base de datosde Cinder


horizon

cinder-sheduler

cinder-volume

API de almacenamientoen bloqueKeystone

ColaAlmacén de volúmenes

(CEPH,GlusterFSLVM local, etc)

AMQP

AMQP

API de almacenamientoen bloque

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 interac-túan con este tipo de almacenamiento vinculando volúmenes a las instancias en ejecución.

20

• Los volúmenes son persistentes, es decir podemos desvincular un volumen de una instancia y vincularlo a otray los datos se mantienen intactos. Usualmente se compara el almacenamiento en bloques con la funcionalidadde 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 devolú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 serprocesadas. 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 losvolúmenes. También interactúa con el componente cinder-sheduler a través de la cola de mensajes. Finalmentecinder-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 unvolumen 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 HatStorage (GlusterFS), IBM XIV, HP Leftland, 3Par, etc. En este caso cinder-volume usará el protocolo iscsi paracomunicarse con el API del driver específico.

2.3.7 Glance Image StorageGlance provee de un catálogo y repositorio de imágenes para ser usadas por las instancias. Constituye una partefundamental 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.

glance-api

Glance Image Storage


Base de datosde Glance


horizon

glance-registry

Keystone

API de imágenes

API de imágenes

nova-api

nova-compute

API de imágenes

API de imágenesswift-proxy

API de objetos

Almacén de Imágenes(Fyle System,S3,Swift,rdb)

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 almace-namiento.

• 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 congeladade una instancia.

21

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.

2.3.8 Ceilometer TelemetryCeilometer 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, almacenamientolibre, etc. A su vez un colector realizará otro sondeo a los agentes para recopilar los datos actualizados. Siciertos datos superan un umbral determinado (carga de cpu muy elevada) se dispara una alarma hacia el agenteque 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 construirmétricas.

• El componente notificaton-agent se encarga de escuchar las notificaciones desde la cola de mensajes y conver-tirlas en eventos y muestras.

• El componente collector se encarga del sondeo hacia los polling-agent y notification-agent para almacenar losdatos 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 dealarmas.

2.3.9 Heat OrchestrationHeat permite la orquestación de stacks de aplicaciones en la nube. Dichos stacks pueden estar compuestas por serviciosde 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 AWSCloudFormation de Amazon. Las plantillas se usan a través de la API REST de orquestación de OpenStack o atravé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 instanciaUno de los casos de uso más importante para entender el funcionamiento distribuido de OpenStack es el flujo depeticiones 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 paralevantar una instancia.

22

nova-api

BD de Nova

nova-conductor

cola

nova-compute

nova-sheduler

hypervisor

glance-api

Almacén de ImágenesBD de Glance

glance-registry

Glance

DBKeystone

Keystone

neutron-server

cola

BD de Neutron

plugins de Neutron

agentes de Neutron

Neutron

Cola

cinder-api

BD de Cinder

cinder-volume cinder-sheduler

Cinder

1

2

3

4

5

67

8

91011

12

13 14

15

18

17 16 21

20

19

23

26

24

22

25

27

28

Horizon

Nova

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 KeyStonepara 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 lospermisos 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 yactualizar su entrada.

9. nova-sheduler recoge el mensaje desde la cola.

23

10. nova-sheduler interactúa con la base de datos de Nova para encontrar el mejor host disponible, luego de unproceso de filtrado y ponderación.

11. Luego de filtrar y ponderar los nodos de Cómputo disponibles nova-sheduler obtiene el "HOST ID" del mejornodo disponible.

12. nova-sheduler envía el mensaje "rpc.cast" hacia nova-compute para lanzar la instancia en el host obtenido en elpaso 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 delusuario 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 pasandoel 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 lainstancia (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 complejoecosistema Cloud.

24

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 sistemaoperativo 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 sistemaoperativo. 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 sistemaoperativo 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

2. Paravirtualización: La paravirtualización es similar a la virtualización completa, pero ahora los servidores vir-tuales "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 menosrecursos para la misma carga de trabajo. Es decir, la paravirtualización permite mayor escalabilidad a costa dealgunos cambios en el sistema operativo Guest. En este caso el hipervisor se encuentra en la capa "VirtualizationSoftware 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 hipervisorya que los mecanismos de virtualización forman parte del sistema operativo. Es el tipo de virtualización másescalable, ya que no necesita un hipervisor y las instancias son mucho más ligeras que los casos anteriores. Porotra parte, presenta la limitación de que el sistema operativo de la instancia debe ser igual al del Host. LosContenedores 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 instanciasCloud. KVM significa "Kernel Virtual Machine" y se vale de instrucciones integradas en el Kernel de Linux paraejecutar las tares de virtualización (el kernel actúa de hipervisor). El desarrollo de KVM es Open Source y ha día dehoy es la tecnología más idonea para desplegar OpenStack. Sin embargo, recientes estudios demuestran que el usode Contenedores (como LXC o docker) en el Cloud aumentan la eficiencia permitiendo mayor número de instanciasbajo el mismo número de nodos físicos de Cómputo. El problema es que los contenedores no están suficientementetesteados y aún no implementan algunos funciones importantes como la vinculación automática de volúmenes a unainstancia [16] [17].

26

2.5.2 Tecnologías de RedesEntre las tecnologías de redes se encuentran los túneles GRE y VXLAN usados en el plug-in ML2. Por otra parte semencionara 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 establecimientode túneles entre dos nodos no conectados directamente. El protocolo fue originalmente desarrollado por Ciscoy 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 unamisma empresa separadas geográficamente. En este caso el túnel IP viaja cifrado y se conoce como VPN. GREtradicionalmente 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 conectanlas 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 establecimientode túneles o redes superpuestas (overlay networks). VXLAN se desarrolló explícitamente en entornos de virtu-alización de redes en sistemas Cloud. Encapsula paquetes ethernet L2 dentro de paquetes UDP L4 a través deuna técnica de etiquetado similar al VLAN. Básicamente, es usada para crear una red plana L2 para máquinasvirtuales 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 instanciasde un mismo tenant en una red virtual IP superpuesta a la red física IP. Los túneles VXLAN pueden escalarmejor 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. Presentados extremos, normalmente uno en un sistema host y otro dentro de un espacio de nombres de red aislado. Todolos 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 paracomunicar las instancias virtuales en entornos de virtualización. Su principal uso ha sido reenviar el tráfico entrediferentes 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 úni-cos. El identificador definido en un espacio de nombres está asociado a dicho espacio de nombres. El mismoidentificador puede ser definido en otros espacios de nombres pero identificará un objeto diferente. El kernelLinux da soporte para varios espacios de nombres como: PID namespaces (procesos), MNT namespaces (puntosde montaje) y NET namespaces (redes).

De esta forma los espacios de nombres de red son un grupo determinado de direcciones IP, interfaces, tablas derutas, 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 tenanttiene su propio espacio de nombres de red para sus redes privadas.

27

6. Flujo de red detallado en OpenStackEl esquema de la figura 2.16 muestra el flujo de red que siguen los paquetes de una instancia en nuestra insta-lació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 tantoes llamado "Switch firewall".nota: Idealmente, el tap0 debería conectarse directamente con el switch de integración (br-int) pero no sepuede debido a la forma en que los grupos de seguridad de OpenStack están implementados. OpenStackusa reglas IPtables en los dispositivos TAP para implementar los grupos de seguridad y OpenvSwitch no escompatible con reglas IPtables que son aplicadas directamente en dispositivos TAP que están conectadasa 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 "VLANuntag" al tráfico que se dirige a las instancias. Cada red interna Tenant creada con Neutron tiene su propiaVLAN 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 siya 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 GREetiquetado con un "Tunel ID" específico. Cada VLAN ID tiene asociado solo un TUNNEL ID, por tanto

28

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 ID1 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 yde Red.br-tun también se comporta como un switch normal que usa "MAC-learning". Con el añadido de mirar losVLAN 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 especiede "Pseudo-Controlador SDN", ya que a través del plug-in ML2 y el agente-OpenVswitch se ordena aun switch OpenvSwitch utilizar reglas OpenFlow para controlar el tráfico. Para mirar las tablas de flujoOpenFlow 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 delnodo de Red tiene reglas OpenFlow similares al br-tun del nodo de Cómputo, pero en este caso las reglasseparan el tráfico destinado al servidor dhcp (MAC_DST=DHCP_MAC) del tráfico destinado al routervirtual (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ónEste switch sirva para conectar las instancias a los servicios de red como los routers virtuales y servidoresDHCP.

• Nodo de Red: Servidor DHCP (O,P)Cada red privada interna en la cual habilitamos DHCP tiene un servidor DHCP corriendo en el nodo deRed. 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 garantizanel enrutamiento entre subredes. Dentro del router tenemos dos interfaces TAP, una se conecta al br-int y laotra se conecta al br-ex como gateway. Dentro de este espacio de nombres tenemos una tabla NAT netfilterresponsable de asociar las IPs flotantes de las instancias con las IP privadas internas. Por defecto tambiéntenemos 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.

2.5.3 Tecnologías de AlmacenamientoEn este apartado mencionaremos los tipos de almacenamiento y los backends Open Source que tenemos disponiblespara OpenStack. Como una primera clasificación tenemos:

1. Almacenamiento efímero: En un almacenamiento efímero los datos del usuario se pierden cuando la instanciase 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 alterminar una instancia. OpenStack soporta dos tipos de almacenamiento persistente:

(a) Almacenamiento de objetos: El objeto almacena una pieza de información con metadatos extendidos yestá identificado por un ID único que permite su recuperación. Los meta-datos se definen a convenienciacomo la confidencialidad, el objetivo, tipo, etc. Se usa principalmente para almacenar información estáticacomo fotos, vídeos, backups de discos, imágenes iso, contenido web estático, etc. Es la tecnología de

29

almacenamiento más escalable y accesible (normalmente se accede mediante una API REST). Por otraparte el almacenamiento de objetos es "eventualmente consistente", es decir no garantiza que una peticiónde lectura devuelva la versión más actualizada, por lo que es idónea para un tipo de datos estáticos que nose 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 almacenamientodistribuido.

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 blo-ques de datos, cada uno con su propia dirección pero sin meta-datos asociados. A diferencia del casoanterior, el almacenamiento de bloques permite editar una parte de un fichero (un grupo de bloques de-terminados) sin tener que editar la parte restante. Puede ser accedido fácilmente por el sistema operativocomo un volumen de disco montado. Se usa principalmente para información transaccional como sistemasde bases de datos. Se considera "fuertemente consistente", es decir garantiza que una petición de lecturadevuelva la versión más actualizada.

Como ejemplo de uso citamos las redes de almacenamiento internas de grandes corporaciones con arqui-tectura 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 objetosen un cluster distribuido. En una instalación de OpenStack podríamos centralizar el trabajo de replicación, consistenciay disponibilidad de todo tipo de almacenamiento en esta herramienta.

La figura 2.20 muestra como Ceph se integra con OpenStack.

30

Figure 2.18: Almacenamiento de bloques.

Figure 2.19: Almacenamiento de bloques.

2.5.4 Tecnologia de Colas de mensajesEn 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 Neutrondentro 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 vayanacumulando para procesarlos en lotes, la cola irá manteniendo los mensajes hasta que el servicio decida suprocesamiento 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 enel 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 lacola hasta que se les indique lo contrario, al mismo tiempo la cola podrá seguir recibiendo mensajes para elprocesamiento posterior a la recuperación del sistema.

31

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 responderpor un anormal flujo de mensajes, el hecho de tener una cola o buffer de peticiones permitirá balancear, filtrar ynormalizar el flujo.

• Desacoplamiento: La cola actúa como una capa intermedia de comunicación entre los servicios brindando flexi-bilidad en la definición de los servicios. Cada servicio tan solo debe mantenerse alineado con los requerimientosde la interfaz de la cola de mensajes.

• Escalabilidad: Al agregar más unidades de procesamiento al sistema (más nodos para el mismo servicio) lacola de mensajes se encargará de balancear la carga entre todos los nodos.

2.6 Servicios en desarrollo de OpenStackPara 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 procesargrandes 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 demáquinas virtuales. (MaaS)

• Zaqar Messagin as a service : Tiene como objetivo proveer bajo demanda de colas de mensajes. Principalmentepensado 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 ficheroscompartidos.

32

Chapter 3

Despligue de OpenStack

3.1 Entorno de desarrolloPara realizar un despliegue real de OpenStack se necesita una gran cantidad de servidores físicos que actúen comonodos. Cada nodo llevará un rol dentro de la infraestructura Cloud siendo los más usados: Nodo Controlador, Nodode Red, Nodo de Cómputo, Nodo de Almacenamiento en Bloque y Nodo de Almacenamiento de Objetos. Como solodisponemos de un portátil para el proyecto se ha elegido la infraestructura virtual más básica que permite emular unsistema 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 cargasobre el sistema operativo del portátil. Sin embargo, el nodo de cómputo, cuya función es levantar máquinas virtualesKVM, no ha podido emularse correctamente a través de un contenedor LXC ya que esta tecnología aún no soporta lavirtualización KVM anidada dentro de sus contenedores. Para el nodo de cómputo finalmente hemos optado por unavirtualización KVM directa, ya que KVM si soporta virtualización anidada de otras máquinas virtuales KVM. Paraconectar 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.

OpenvSwitch

Contenedor LXC

Nodo “controller”

SQL MariaDB

Cola de MensajesRabbitMQ

NTP

Keystone

nova-sheduler

nova-api

neutron-server

neutron-plugin-ml2

Horizon Glance

Contenedor LXC

Nodo “network”

neutron-dhcp-agent

neutron-l3-agent

neutron-plugin-ml2

OpenvSwitch

Neutron-plugin-openvswitch-agent

Máquina virtual KVM

Nodo “compute”

Hypervisor KVMnova-compute

neutron-plugin-ml2

OpenvSwitch

Neutron-plugin-openvswitch-agent

Metadata-net-agent

Figure 3.1: Entorno de Desarrollo I.

33

En el nodo Controlador instalaremos todos los subservicios cuya función es servir de proxi o referencia para el restode servicios, por ejemplo nova-api y neutron-server. También se instalarán los servicios auxiliares NTP, RabbitMQ yla base de datos MariaDB. Por último instalaremos todos los servicios que no tengan que ver con la virtualización olas 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á elplugin 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 inicialEn este apartado se realizará el despliegue de la infraestructura inicial básica que comprende la configuración de losdos contenedores LXC y la máquina virtual KVM, así como la conexión de red entre ellos a través de OpenvSwitchen 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 lasiguiente configuración mostrada en la figura 3.2.

Nodo “controller” Nodo “network” Nodo “compute”

Red de Gestión (11.0.0.0)Red Tunel (11.0.1.0)Red Externa (203.0.113.0)

11.0.0.2

OpenvSwitch

Switch “br-man”

Switch “br-tunnel”

eth1

eth1-control

eth1-network

vnet1

eth2-network vnet2

eth1

11.0.0.3

eth1

eth2 eth2

11.0.1.3 11.0.1.4

11.0.0.4

eth3

Switch “br-out”

eth3-network tap0

Par veth

Par veth

Par veth

Par veth

eth0-control

eth0-networkvnet0

eth0

Red LXC (10.0.3.0)Red KVM (192.168.122.0)

eth0eth0

Par veth

Par veth

Host net namespace

203.0.113.100

wlan0

NAT(IPtable)

Figure 3.2: Infraestructura de Red I.

La red de gestión (11.0.0.0) transporta los paquetes de gestión de los nodos (meta-datos, configuraciones, etc).La red Tunel (11.0.1.0) transporta el tráfico de red de las instancias creadas en el nodo de Cómputo. La red externa

34

(203.0.113.100) otorga acceso externo a las instancias. Para nuestro proyecto conectamos la red externa a una interfazvirtual 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 losnodos e instalar todos los paquetes necesarios. El direccionamiento de los nodos se realiza por defecto medianteDHCP a través de dnsmasq. Dichas redes hacen NAT con la interfaz inalámbrica wlan0 para acceder a la red local yposteriormente a internet.

Los nodos basados en contenedores LXC (Controlador y de Red) se conectan con nuestro espacio de nombres dered 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 deun 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. Elnombre del portatil es "host" y presenta un sistema operativo Linux Mint 17, compatible con Ubuntu 14.04.

3.2.1 Instalación y configuración de LXC para el nodo de Red y el nodo Controlador1. 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 Función/var/lib/lxc Lugar de almacenamiento de contenedores/etc/lxc/ Fichero de configuracion principal/usr/share/lxc/templates/ Lugar de almacenamiento de los templates/usr/share/lxc/selinux/ Configuración de selinux/var/log/lxc/ Logs de lxc/etc/default/lxc-net Configuración de red de los contenedores/etc/init/lxc-net.conf 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. Unollamado "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 encuentraen la ruta /var/lib/lxc/<nodo>/config.

# Path /var/lib/lxc/controller/config# Distribution configurationlxc.include = /usr/share/lxc/config/ubuntu.common.conflxc.arch = x86_64

# Container specific configurationlxc.rootfs = /var/lib/lxc/controller/rootfslxc.utsname = controller

# Network configuration

35

lxc.network.type = vethlxc.network.flags = uplxc.network.link = lxcbr0lxc.network.hwaddr = 00:16:3e:57:b5:calxc.network.veth.pair = eth0-control

#OpenStack infrastructurelxc.network.type = vethlxc.network.flags = uplxc.network.veth.pair = eth1-controllxc.network.ipv4 = 11.0.0.2/24

# Path /var/lib/lxc/network/config# Distribution configurationlxc.include = /usr/share/lxc/config/ubuntu.common.conflxc.arch = x86_64

# Container specific configurationlxc.rootfs = /var/lib/lxc/network/rootfslxc.utsname = network

# Network configurationlxc.network.type = vethlxc.network.flags = uplxc.network.link = lxcbr0lxc.network.hwaddr = 00:16:3e:5e:06:09lxc.rootfs = /var/lib/lxc/network/rootfslxc.network.veth.pair = eth0-network

#OpenStack infrastructurelxc.network.type = vethlxc.network.flags = uplxc.network.veth.pair = eth1-networklxc.network.ipv4 = 11.0.0.3/24

lxc.network.type = vethlxc.network.flags = uplxc.network.veth.pair = eth2-networklxc.network.ipv4 = 11.0.1.3/24

lxc.network.type = vethlxc.network.flags = uplxc.network.veth.pair = eth3-network

#Disable AppArmor for LXC containerlxc.mount.auto = cgrouplxc.aa_profile = unconfined

Las dos últimas líneas en el fichero del contenedor del nodo de Red inhabilitan el uso de AppArmor (SeLinuxde 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 sistemapara comprobar que se han iniciado correctamente.

root@host: lxc-start -n network -droot@host: lxc-attach -n network

root@host: lxc-start -n controller -droot@host: lxc-attach -n controller

5. Los contenedores se pueden parar apagando su sistema o ejecutando el siguiente comando desde el "host".

36

root@host: lxc-stop -n controller

root@host: lxc-stop -n network

6. En la consola del "host" podemos listar los contenedores que hemos creado con el siguiente comando:

root@host: lxc-ls

7. En la página x del apéndice podemos encontrar documentación detallada de la herramienta LXC.

3.2.2 Instalación y configuración la máquina virtual KVM para el nodo de Cómputo

1. Instalamos Ubuntu 14.04 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 totaltendremos tres interfaces).

3. Entramos a la máquina virtual y configuramos su fichero /etc/network/interfaces de la siguiente forma:

# The loopback network interfaceauto loiface lo inet loopback

# The primary network interfaceauto eth0iface eth0 inet dhcp

#Compute node interfacesauto eth1iface eth1 inet static

address 11.0.0.4netmask 255.255.255.0

auto eth2iface eth2 inet static

address 11.0.1.4netmask 255.255.255.0

4. En el sistema "host" las 2 interfaces virtuales del nodo de Cómputo se ven como vnet1 y vnet2. Por defecto KVMlas conecta a través del bridge virbr0 usando la herramienta "brctl". Como nuestro objetivo es usar OpenvSwitchpara crear las redes de OpenStack debemos eliminar dichas interfaces del puerto virbr0.

root@host: brctl delif virbr0 vnet1root@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 switchvirbr0 con los comandos anteriores y reiniciar el servicio de OpenvSwitch con el siguiente comando.

root@host: service openvswitch-switch restart

37

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 dered 3.2.

root@host: ovs-vsctl add-br br-manroot@host: ovs-vsctl add-port br-man eth1-networkroot@host: ovs-vsctl add-port br-man eth1-controlroot@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-tunnelroot@host: ovs-vsctl add-port br-tunnel eth2-networkroot@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 estaforma podremos comprobar la configuración de la red externa de las instancias.

root@host: ip tuntap add name tap0 mode taproot@host: ovs-vsctl add-br br-outroot@host: ovs-vsctl add-port br-out tap0root@host: ovs-vsctl add-port br-out eth3-networkroot@host: ifconfig tap0 promiscroot@host: ifconfig eth3-network promiscroot@host: ifconfig tap0 203.0.113.100

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


5. Por defecto, en la distribución Linux Mint 17 la herramienta NetworkManager intenta reconfigurar las inter-faces del sistema "host" provocando cambios en las configuraciones de red. Para evitar que NetworkManagermodifique 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áquinahost.

A continuación se presenta el fichero /etc/network/interfaces.

38

#auto eth0#iface eth0 inet dhcp

#Bridges from OVSauto br-maniface br-man inet static

address 11.0.0.1netmask 255.255.255.0

auto br-tunneliface br-tunnel inet static

address 11.0.1.1netmask 255.255.255.0

#Avoid NetworkManager problem.iface vnet1 inet staticiface eth1-control inet staticiface eth1-network inet static

iface vnet2 inet staticiface eth2-network inet static

iface eth3-network inet static

iface eth0-control inet staticiface eth0-network inet static

#Testing the network for instancesauto br-outiface br-out inet static

address 203.0.113.2netmask 255.255.255.0

auto tap0iface tap0 inet static

address 203.0.113.100netmask 255.255.255.0

6. 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. Unavez 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 elsistema "host" se encuentre ya correctamente configurado. El despliegue se ha basado en la guía oficial de OpenStackpara 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.

3.3.1 Entorno básico

Antes de instalar los servicios principales de OpenStack es necesario instalar y configurar los servicios mínimosmostrados en los siguientes apartados.

39

Password DescripciónRABBIT_PASS Password de RabbitMQKEYSTONE_DBPASS Password de la BD de KeyStoneDEMO_PASS Password del usuario "demo"ADMIN_PASS Password del usuario "admin"GLANCE_DBPASS Password de la BD de GlanceGLANCE_PASS Password para autenticarse en KeyStoneNOVA_DBPASS Password de la BD de NovaNOVA_PASS Password para autenticarse en KeyStoneDASH_DBPASS Password de la BD de HorizonNOVA_DBPASS Password de la BD de NovaNEUTRON_DBPASS Password de la BD de NeutronNEUTRON_PASS Password para autenticarse en KeyStone

Table 3.2: Ficheros de configuración de LXC.

3.3.1.1 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 dondepueda 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 comentarla linea que comienza con 127.0.1.1.

#controller11.0.0.2 controller#network11.0.0.3 network#compute11.0.0.4 compute

3. En el fichero /etc/resolvconf/resolv.conf.d/base debemos añadir la dirección IP de un servidor DNS. Paranuestro proyecto hemos elegido OpenDNS por ofrecer el servicio gratuito y abierto.

nameserver 208.67.222.222nameserver 208.67.220.220

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






root@network: resolvconf -u

4. Ponemos la interfaz eth3 del nodo de Red en modo promiscuo.

root@network: ifconfig eth3 promisc


• Nodo de Cómputo

1. Asignamos al nodo de Cómputo el hostname "compute".

root@hostname: hostname compute






root@compute: resolvconf -u

4. A diferencia de los nodos basados en LXC, en el nodo KVM debemos configurar las interfaces manual-mente editando el fichero /etc/network/interfaces:

# The loopback network interfaceauto loiface lo inet loopback

41

# The primary network interfaceauto eth0iface eth0 inet dhcp

#Compute node interfaces from OpenStackauto eth1iface eth1 inet static

address 11.0.0.4netmask 255.255.255.0

auto eth2iface eth2 inet static

address 11.0.1.4netmask 255.255.255.0

5. Reiniciamos el sistema KVM.

• Verificación de la conectividadEn este punto se recomienda verificar la conectividad mediante ping desde cada nodo hacia internet y hacia elresto de los nodos, tanto por la red de gestión como por la red tunel.

3.3.1.2 Instalación y configuración de NTP

Para sincronizar los servicios principales debemos instalar el servicio NTP en cada nodo. El nodo Controlador será elde referencia para el nodo de Red y el nodo de Cómputo.


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 iburstrestrict -4 default kod notrap nomodifyrestrict -6 default kod notrap nomodify

Debemos reemplazar NTP_SERVER con el hostname o dirección IP de un servidor NTP público de inter-net.

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


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


root@network: rm /var/lib/ntp/ntp.conf.dhcp


root@network: service ntp restart



root@compute: 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


root@compute: rm /var/lib/ntp/ntp.conf.dhcp


root@compute: service ntp restart

3.3.1.3 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-keyringroot@hostname: echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu" \"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

3.3.1.4 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 nuestroproyecto 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

[mysqld]...#bind-address = Controller ip addressbind-address = 11.0.0.2default-storage-engine = innodbinnodb_file_per_tablecollation-server = utf8_general_ciinit-connect = 'SET NAMES utf8'

4. Reiniciamos el servicio.

root@controller: service mysql restart

5. Protegemos el servicio.

root@controller: mysql_secure_installation

3.3.1.5 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 pode-mos usar el comando siguiente.

root@controller: rabbitmqctl change_password guest RABBIT_PASS

Para nuestro proyecto hemos usado la contraseña RABBIT_PASS.

3.3.1.6 Verificación

En este apartado solo necesitamos comprobar que el servicio NTP está correctamente configurado.Nodo ControladorEn 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 restantesEn 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

3.3.1.7 Problemas encontrados

No se encontraron problemas.

3.3.2 Instalación y configuración de KeyStoneComo muestra el esquema de la figura 3.1 el servicio KeyStone se alojará en el nodo Controlador.

3.3.2.1 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 10

6. 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.Providerdriver = 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 con-traseña determinada por el usuario.

8. Rellenamos la base de datos creada con los parámetros de KeyStone.

45

root@controller: su -s /bin/sh -c "keystone-manage db\_sync" keystone

9. Reiniciamos el servicio KeyStone.

root@controller: service keystone restart

10. Por defecto el paquete de Ubuntu crea una base de datos SQLite. Como usaremos la base de datos MariaDBpodemos eliminar la SQLite.

root@controller: 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.

root@controller: (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

3.3.2.2 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=http://controller:35357/v2.0

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"EMAIL_ADDRESS".

root@controller: keystone user-create --name admin --pass ADMIN_PASS --email EMAIL_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 servicioOpenStack. La política por defecto de la mayoría de los servicios otorgan acceso de administración al rol"admin".

46

7. Creamos el tenant "demo".

root@controller: 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 comodirección de correo "EMAIL_ADDRESS2".

root@controller: keystone user-create --name demo --tenant demo --pass DEMO_PASS \--email EMAIL_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"

3.3.2.3 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=http://controller:35357/v2.0

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 delsistema 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 razonesde seguridad. OpenStack además puede soportar múltiples regiones para aumentar la escalabilidad. En nuestraconfiguració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 http://controller:5000/v2.0 \--internalurl http://controller:5000/v2.0 \--adminurl http://controller:35357/v2.0 --region regionOne

Podemos ver que el acceso "admin" se realiza por el puerto 35357 mientras que el acceso a las APIs públicas einternas se realiza a través del puerto 5000.

47


Para verificar la correcta configuración de KeyStone debemos ejecutar los siguientes comandos y analizar la respuestaen 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 http://controller:35357/v2.0 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 http://controller:35357/v2.0 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 http://controller:35357/v2.0 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 http://controller:35357/v2.0 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 http://controller:35357/v2.0 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 http://controller:35357/v2.0 user-list

En este caso KeyStone debe responder indicando que el usuario no está autorizado.


Mientras instalábamos KeyStone tuvimos que parar el contenedor del nodo de Cómputo. Resulta que al iniciar nueva-mente el contenedor y ejecutar un comando tenemos un error con la variable de entorno "LOCALE". Para resolver elproblema tan solo debemos ejecutar el siguiente comando:

root@controller: export LC_ALL=C

Este problema se ha reiterado durante todo el proyecto.

48

3.3.2.6 Scripts OpenRC

Para disminuir los pasos en la interacción con el cliente KeyStone OpenStack soporta los scripts de variables deentorno conocidos como OpenRC.

1. Creamos un fichero admin-openrc.sh y añadimos:

export OS_TENANT_NAME=adminexport OS_USERNAME=adminexport OS_PASSWORD=ADMIN_PASSexport OS_AUTH_URL=http://controller:35357/v2.0

2. Creamos un fichero demo-openrc.sh y añadimos:

export OS_TENANT_NAME=demoexport OS_USERNAME=demoexport OS_PASSWORD=DEMO_PASSexport OS_AUTH_URL=http://controller:5000/v2.0

3. Para cargar el script openRC con las variables de "admin" debemos ir a la carpeta donde creamos los ficherosanteriores y ejecutar el siguiente comando:

root@controller: source admin-openrc.sh

3.3.3 Instalación y configuración de GlanceEn 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 endisco, en nuestro caso el nodo Controlador está representado por un contenedor LXC que tiene todo su sistema deficheros 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ágenespara no tener problemas de almacenamiento.

Todas las configuraciones se realizan en el nodo Controlador.

3.3.3.1 Configuración Inicial



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';


mysql>: exit;

49

3.3.3.2 Integración en KeyStone

1. Cargamos el fichero admin-openrc.sh.


2. Creamos el usuario "glance" con el password "GLANCE_PASS".

root@controller: keystone user-create --name glance --pass GLANCE_PASS

3. Añadimos el rol "admin" al usuario "glance".

root@controller: keystone user-role-add --user glance --tenant service --role admin

4. Creamos la entidad de servicios "glance".

root@controller: 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 http://controller:9292 \--internalurl http://controller:9292 \--adminurl http://controller:9292 \--region regionOne

3.3.3.3 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 = http://controller:5000/v2.0identity_uri = http://controller:35357admin_tenant_name = serviceadmin_user = glanceadmin_password = GLANCE_PASS

[paste_deploy]...flavor = keystone

[glance_store]...default_store = filefilesystem_store_datadir = /var/lib/glance/images/

[DEFAULT]...notification_driver = noopverbose = True

50

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 = http://controller:5000/v2.0identity_uri = http://controller:35357admin_tenant_name = serviceadmin_user = glanceadmin_password = GLANCE_PASS

[DEFAULT]...notification_driver = noopverbose = 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 restartroot@controller: glance-api restart

6. Por defecto el paquete de Ubuntu crea una base de datos SQLite. Como usaremos la base de datos MariaDBpodemos eliminar la SQLite.root@controller: rm -f /var/lib/glance/glance.sqlite


1. Creamos un directorio temporal.root@controller: mkdir /tmp/images

2. Descargamos una imagen hacia el directorio temporal.root@controller: wget -P /tmp/images \http://cdn.download.cirros-cloud.net/0.3.3/cirros-0.3.3-x86_64-disk.img

3. Subimos la imagen hacia Glance.root@controller: lance image-create --name "cirros-0.3.3-x86_64" \--file /tmp/images/cirros-0.3.3-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



3.3.4 Instalación y configuración de NovaComo muestra el esquema de la figura 3.1 algunos componentes (nova-api) del servicio Nova se encuentran en el nodoControlador mientras que otros (nova-compute) se encuentran en el nodo de Cómputo.


La configuración inicial se realiza en el nodo Controlador.



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';


mysql>: exit;


La integración se realiza en el nodo Controlador.



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

root@controller: keystone endpoint-create \--service-id $(keystone service-list | awk '/ compute / {print $2}') \--publicurl http://controller:8774/v2/%$tenant_id$s \--internalurl http://controller:8774/v2/%$tenant_id$s \--adminurl http://controller:8774/v2/%$tenant_id$s \--region regionOne

3.3.4.3 Instalación de componentes de Nova



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 = http://controller:5000/v2.0identity_uri = http://controller:35357admin_tenant_name = serviceadmin_user = novaadmin_password = NOVA_PASS

[DEFAULT]...rpc_backend = rabbitrabbit_host = controllerrabbit_password = RABBIT_PASSauth_strategy = keystonemy_ip = 11.0.0.2vncserver_listen = 11.0.0.2vncserver_proxyclient_address = 11.0.0.2verbose = 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" debemosponer la IP de gestión del nodo Controlador. Las contraseñas "NOVA_PASS" y "RABBIT_PASS" debenreemplazarse 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 restartroot@controller: service nova-cert restartroot@controller: service nova-consoleauth restartroot@controller: service nova-scheduler restartroot@controller: service nova-conductor restartroot@controller: service nova-novncproxy restart

53


root@controller: rm -f /var/lib/nova/nova.sqlite



root@compute: 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 = http://controller:5000/v2.0identity_uri = http://controller:35357admin_tenant_name = serviceadmin_user = novaadmin_password = NOVA_PASS

[DEFAULT]...rpc_backend = rabbitrabbit_host = controllerrabbit_password = RABBIT_PASSauth_strategy = keystonemy_ip = 11.0.0.4vnc_enabled = Truevncserver_listen = 0.0.0.0vncserver_proxyclient_address = 11.0.0.4novncproxy_base_url = http://controller:6080/vnc_auto.htmlverbose = True

Debemos comentar las lineas "auth_host", "auth_port" y "auth_protocol" ya que la opción "identiti_uri" lasreemplaza. En las opciones "my_ip" y "vncserver_proxyclient_address" debemos poner la IP de gestióndel nodo de Cómputo. Las contraseñas "NOVA_PASS" y "RABBIT_PASS" deben reemplazarse por laselegidas por el usuario.

3. Determinamos si el nodo de Cómputo soporta aceleración por hardware para máquinas virtuales a travésdel 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 porhardware y la tiene habilitada. En nuestro proyecto hemos tenido que habilitar la aceleración primero enel "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/nova-compute.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" envez de "kvm".

54

4. Reiniciamos el servicio Nova en el nodo de Cómputo.

root@compute: service nova-compute restart


root@compute: rm -f /var/lib/nova/nova.sqlite



root@compute: source admin-openrc.sh

2. Listamos todos los servicios de Nova.

root@compute: 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


Figure 3.4: Comprovación de Nova II.


En este apartado tuvimos un problema que nos hizo cambiar una decisión inicial. El subservicio nova-compute noarrancaba correctamente y luego de mirar logs sin encontrar alguna pista comencé a investigar sobre virtualizaciónKVM anidada sobre Contenedores LXC. Resulta que existen muchos bugs cuando se mezclan ambas tecnologías y noencontré forma de arreglar el problema [21] [22]. Finalmente opté por usar virtualización KVM directa en el nodo deCó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íaexplotando la virtualización anidada LXC sobre LXC, pero como dichos contenedores aún no soportan todas lascaracterísticas del Cloud se decidió usar KVM.

55

3.3.5 Instalación y configuración de NeutronComo muestra el esquema de la figura 3.1 algunos componetes (neutron-server) del servicio Neutron se encuentran enel nodo Controlador mientras que otros (Agente L3) se encuentran en el nodo de Red.


La configuración inicial se realiza en el nodo Controlador.



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';


mysql>: exit;


La integración en KeyStone se realiza en el nodo Controller.



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 http://controller:9696 \--adminurl http://controller:9696 \--internalurl http://controller:9696 \--region regionOne

56

3.3.5.3 Instalación de componentes de Neutron



root@controller:apt-get 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 = http://controller:5000/v2.0identity_uri = http://controller:35357admin_tenant_name = serviceadmin_user = neutronadmin_password = NEUTRON_PASS

[DEFAULT]...rpc_backend = rabbitrabbit_host = controllerrabbit_password = RABBIT_PASSauth_strategy = keystonecore_plugin = ml2service_plugins = routerallow_overlapping_ips = Truenotify_nova_on_port_status_changes = Truenotify_nova_on_port_data_changes = Truenova_url = http://controller:8774/v2nova_admin_auth_url = http://controller:35357/v2.0nova_region_name = regionOnenova_admin_username = novanova_admin_tenant_id = SERVICE_TENANT_IDnova_admin_password = NOVA_PASSverbose = 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" debemosponer 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 obtenerdicho ID podemos ejecutar el siguiente comando:

root@controller: source admin-openrc.shroot@controller: keystone tenant-get service

3. El plug-in ML2 usa el mecanismo de OpenvSwitch (OVS) basado en agentes para construir el frameworkde redes virtuales para las instancias. No obstante, el nodo Controlador no necesita el OpenvSwitch porqueno 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

enable_security_group = Trueenable_ipset = Truefirewall_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 lasredes. 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.APIsecurity_group_api = neutronlinuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriverfirewall_driver = nova.virt.firewall.NoopFirewallDriver

[neutron]...url = http://controller:9696auth_strategy = keystoneadmin_auth_url = http://controller:35357/v2.0admin_tenant_name = serviceadmin_username = neutronadmin_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 Con-trolador.

root@controller: service nova-api restartroot@controller: service nova-scheduler restartroot@controller: service nova-conductor restartroot@controller: service neutron-server restart

• Nodo de RedEn el nodo de Red principalmente se gestiona el enrutamiento interno y externo de las redes virtuales y elservicio DCHP.

1. Primero debemos permitir que el nodo enrute paquetes. Editamos el fichero /etc/sysctl.conf y añadimos oreemplazamos las siguientes lineas:

net.ipv4.ip_forward=1net.ipv4.conf.all.rp_filter=0net.ipv4.conf.default.rp_filter=0

Implementamos los cambios.

sysctl -p


root@network: apt-get install neutron-plugin-ml2 neutron-plugin-openvswitch-agent \neutron-l3-agent neutron-dhcp-agent

58



[DEFAULT]...rpc_backend = rabbitrabbit_host = controllerrabbit_password = RABBIT_PASSauth_strategy = keystonecore_plugin = ml2service_plugins = routerallow_overlapping_ips = Trueverbose = True

Debemos comentar las lineas "auth_host", "auth_port" y "auth_protocol" ya que la opción "identiti_uri" lasreemplaza. Las contraseñas "NEUTRON_PASS" y "RABBIT_PASS" deben reemplazarse por las elegidaspor el usuario.

4. El plug-in ML2 usa el mecanismo de OpenvSwitch (OVS) basado en agentes para construir el frame-work de redes virtuales para las instancias. Editamos el fichero /etc/neutron/plugins/ml2/ml2_conf.ini yañadimos o reemplazamos las siguientes lineas:

[ml2]...type_drivers = flat,gretenant_network_types = gremechanism_drivers = openvswitch

[ml2_type_flat]...flat_networks = external


[securitygroup]...enable_security_group = Trueenable_ipset = Truefirewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

[ovs]...local_ip = 11.0.1.3enable_tunneling = Truebridge_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. Debemoseditar el fichero /etc/neutron/l3_agent.ini y añadir o reemplazar las siguientes lineas:

59

[DEFAULT]...interface_driver = neutron.agent.linux.interface.OVSInterfaceDriveruse_namespaces = Trueexternal_network_bridge = br-exrouter_delete_namespaces = Trueverbose = True

En la configuración hemos habilitado el uso de espacio de nombres de red(net namespaces) para cadared virtual asignada a un Tenant. De esta forma cada Tenant o cliente en su red interna puede usar eldireccionamiento 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/d-hcp_agent.ini y añadir o reemplazar las siguientes lineas:

[DEFAULT]...interface_driver = neutron.agent.linux.interface.OVSInterfaceDriverdhcp_driver = neutron.agent.linux.dhcp.Dnsmasquse_namespaces = Truedhcp_delete_namespaces = Trueverbose = True

7. Debido al error explicado en el apartado 3.3.7.5 debemos hacer que las instancias se levanten con unaMTU=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 poseeuna instancia. Debemos editar el fichero /etc/neutron/metadata_agent.ini y añadir o reemplazar las sigu-ientes lineas:

[DEFAULT]...auth_url = http://controller:5000/v2.0auth_region = regionOneadmin_tenant_name = serviceadmin_user = neutronadmin_password = NEUTRON_PASSnova_metadata_ip = controllermetadata_proxy_shared_secret = METADATA_SECRETverbose = 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.


60

1. Regresamos al nodo Controlador y editamos el fichero /etc/nova/nova.conf para añadir o reemplazar lassiguientes lineas:

[neutron]...service_metadata_proxy = Truemetadata_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 RedContinuamos 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 virtualespara las instancias. El switch virtual "br-int" maneja el tráfico interno entre las instancias y el "br-ext" maneja eltrafico 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 restartroot@network: service neutron-l3-agent restartroot@network: service neutron-dhcp-agent restartroot@network: service neutron-metadata-agent restart

• Nodo de CómputoEn 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 lassiguientes lineas:

net.ipv4.conf.all.rp_filter=0net.ipv4.conf.default.rp_filter=0

2. Implementamos los cambios.

root@compute: sysctl -p


root@compute: apt-get install neutron-plugin-ml2 neutron-plugin-openvswitch-agent

61



[DEFAULT]...rpc_backend = rabbitrabbit_host = controllerrabbit_password = RABBIT_PASSauth_strategy = keystonecore_plugin = ml2service_plugins = routerallow_overlapping_ips = Trueverbose = True

Debemos comentar las lineas "auth_host", "auth_port" y "auth_protocol" ya que la opción "identiti_uri" lasreemplaza. Las contraseñas "NEUTRON_PASS" y "RABBIT_PASS" deben reemplazarse por las elegidaspor el usuario. En la sección "[database]" debemos comentar todoas las opciones "connection" ya que elnodo 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 frame-work de redes virtuales para las instancias. Editamos el fichero /etc/neutron/plugins/ml2/ml2_conf.ini yañadimos o reemplazamos las siguientes lineas:

[ml2]...type_drivers = flat,gretenant_network_types = gremechanism_drivers = openvswitch


[securitygroup]...enable_security_group = Trueenable_ipset = Truefirewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

[ovs]...local_ip = 11.0.1.4enable_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 lasredes. 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

[DEFAULT]...network_api_class = nova.network.neutronv2.api.APIsecurity_group_api = neutronlinuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriverfirewall_driver = nova.virt.firewall.NoopFirewallDriver

[neutron]...url = http://controller:9696auth_strategy = keystoneadmin_auth_url = http://controller:35357/v2.0admin_tenant_name = serviceadmin_username = neutronadmin_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 debemoslistar los servicios de Neutron desde el nodo Controlador.

root@controller: source admin-openrc.shroot@controller: neutron agent-list


Figure 3.5: Agentes de Neutron.

3.3.5.4 Creación de redes iniciales

Antes de levantar nuestra primera instancia debemos crear la infraestructura de red virtual a la cual se conectará dichainstancia.

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 através de un NAT por razones de seguridad. Para obtener acceso a las instancias a través de internet debemosasignarles 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



2. Creamos la red externa:

root@controller: 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 seencontrará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=203.0.113.101,end=203.0.113.200 \--disable-dhcp --gateway 203.0.113.1 203.0.113.0/24

Como esta red externa generalmente ya tiene otros equipos en ella es recomendable deshabilitar el DHCPy asignar solo una parte de las direcciones disponibles en la red. Para nuestro proyecto usaremos aquellasIPs que van desde 203.0.113.101/24 hasta 203.0.113.200/24. Dicho conjunto de IPs son las conocidascomo IPs flotantes (floating IPs).

• Creación de la red interna de un TenantLa red interna de un Tenant provee de conectividad interna a las instancias de ese Tenant en particular. Laconfiguración de Neutron habilita los espacio de nombres de red(net namespaces) permitiendo que cada red deun 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 proveeacceso 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 192.168.10.1 192.168.10.0/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 lainterfaz será marcada como gateway.

root@controller: neutron router-gateway-set demo-router ext-net

64


Antes de continuar y levantar finalmente nuestra primera instancia debemos comprobar que la configuración de lasredes virtuales de las instancias son correctas. En nuestro ejemplo la interfaz gateway del "demo-router" en la redexterna debe tener la IP 203.0.113.101 debido a que es la más baja del rango indicado. A partir del esquema de lafigura 3.2 deberíamos poder hacer ping desde una terminal del host hacia dicha IP. En caso de que eliminemos el routervirtual 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 configuradasen modo "promiscuo" como se anuncia en los apartados 5.2.2 y 3.3.1.1

La siguiente captura muestra que hay conectividad entre la red "externa" (nuestro sistema "host" en el proyecto)yel "demo-router" que se encuentra en la IP 203.0.113.103 en ese momento.

Figure 3.6: Comprobación de la configuración de Neutron.


1. El primer problema de este apartado fue que Neutron no estaba creando los routers virtuales ni los servidoresDHCP virtuales. Para comprobar que Neutron crea correctamente los equipos virtuales anteriores debemosejecutar 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íamostener 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 estabacreando nuevos espacios de nombres de red (net namespaces). Luego de buscar en foros de OpenStack en-contré 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 desha-bilitar AppArmor para el Contenedor Neutron como ya se indicó en la creación del Contenedor y finalmente selevantaron 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 intentabahacer ping hacia el router creado (203.0.113.101) directamente desde el nodo de Red. Analizando bien ladocumentación de Neutron descubrí que dicho router se encuentra en otro espacio de nombres y que para llegara é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 elsistema "host" pude hacer ping al nuevo router virtual.

3.3.6 Instalación y configuración de HorizonEn estos momentos es posible levantar una instancia desde la linea de comandos en el nodo Controlador puesto quetodos los sistemas fundamentales del sistema Cloud ya se están configurados. No obstante, primero instalaremos el

65

servicio Dashboard Horizon que hace de FrontEnd para todo el sistema OpenStack.Todos los comandos se ejecutan en el nodo Controlador.

3.3.6.1 Instalación de componentes de Horizon


root@controller: 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 lin-eas:

OPENSTACK_HOST = "controller"

ALLOWED_HOSTS = ['*']

CACHES = {'default': {'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache','LOCATION': '127.0.0.1:11211',

}}

la opción "*" en la linea "ALLOWED_HOSTS" permite a todos los usuarios acceder al servicio Horizon. La op-ción "CACHES" se refiere al servicio que almacenará la gestión en Horizon, en este caso Memcached. Cualquierotra linea con la opción "CACHES" debe ser comentada.

3. Reiniciamos los servicios memcached y apache2.

root@controller: service apache2 restartroot@controller: service memcached restart


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:

11.0.0.2 controller11.0.0.3 network11.0.0.4 compute

2. Desde el sistema "host" en un navegador accedemos a Horizon con la URL http://controller/horizon. Las cre-denciales 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.



3.3.7 Levantar una Instancia y lograr acceso externoIniciaremos una instancia usando la imagen CirrOS y verificaremos su correcta configuración de red enviado un pinga 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

Figure 3.7: Interfaz de Horizon.

3.3.7.1 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.


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

3.3.7.2 Levantamiento de la instancia

Para levantar la instancia debemos especificar el "flavor", nombre de la imagen, red, grupo de seguridad, clave ynombre 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

root@controller: nova image-list

3. Listamos las redes disponibles:

root@controller: neutron net-list

Nuestra instancia usará la red "demo-net".

4. Listamos los grupos de seguridad disponibles.

root@controller: secgroup-list

Nuestra instancia usará el grupo de seguridad "default". Por defecto dicho grupo implementa un firewall quebloquea el acceso remoto a las instancias.

5. Levantamos la instancia.

root@controller: nova boot --flavor m1.tiny --image cirros-0.3.3-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 nuestrocaso la instancia toma la IP interna 192.168.1.2.

3.3.7.3 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 ycontraseñ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 elloenviamos un ping hacia el gateway de la red interna "demo-net" (192.168.1.1), otro hacia el gateway de la redexterna "ext-net" (203.0.113.100) y otro hacia la interfaz "tap0" (203.0.113.101). La siguiente captura muestrala comprobación de una red correctamente configurada.

3.3.7.4 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 -1 -1 0.0.0.0/0

68

Figure 3.8: Terminal VNC.

2. Añadimos la regla al grupo de seguridad "default" que permite paquetes ssh, exactamente permitimos la entradade paquetes tcp por el puerto 22.

root@controller: nova secgroup-add-rule default tcp 22 22 0.0.0.0/0

3. Creamos una IP flotante (floating IP) en la red externa "ext-net".

root@controller: neutron floatingip-create ext-net

4. Asociamos la IP flotante con la instancia creada.

root@controller: nova floating-ip-associate demo-instance1 203.0.113.102

5. Comprobamos el estado de la nueva IP flotante asignada anteriormente.

root@controller: nova list

6. Verificamos la conectividad mediante ping desde el "host" hacia la instancia.

root@host: ping 203.0.113.102

7. Accedemos a la instancia mediante ssh. El nombre de usuario y contraseña son los mismos que en el caso de laconsola VNC.

root@host: ssh [email protected]

8. La siguiente captura muestra el ping y el acceso ssh deste el sistema "host".


En este apartado tuvimos un problema a la hora de acceder mediante ssh a la instancia. El "host" enviaba la peticiónpero 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 1454

69

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 quearranquen con MTU=1454 por defecto. Sin embargo, explican que dicha configuración solo mejora el desempeño porlo que no me pareció relevante. Una vez encontrado y solucionado este problema he añadido la configuración en elnodo 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 IPsque salen de los nodos "físicos" tengan que ser constantemente fragmentados. En instalaciones totalmente virtualescomo las nuestras esta fragmentación puede provocar problemas de conexión. Para prevenir las complicaciones serecomienda disminuir el MTU de las instancias a 1454 para tener en cuenta el overhead introducido por GRE. Segúnla documentación este valor debe funcionar en la mayoría de los casos, en caso de que no funcionara se debería seguirdisminuyendo un poco más el valor del MTU de las instancias.

70

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 nuevoparadigma en la gestión de redes donde se intenta "programar" la red según el contexto específico. El objetivo prin-cipal de SDN es separar el plano de control (software) del plano de datos (hardware). En otras palabras SDN buscadesacoplar la infraestructura de red (hardware) de las funciones o inteligencia (software) que la red tiene que realizar.

Plano de Control

Plano de Datos

Dispositivo de red actual (router Cisco, swich HP, etc)

Plano de Control

Plano de Datos

Desacoplo

Controlador SDN

Switch OpenFlow

Programa

Figure 4.1: Objetivo principal de SDN.

En la actualidad todos los equipos de red (switches, routers, firewalls) poseen el plano de control fuertementeacoplado al plano de datos, de forma que realizar un cambio en la lógica de red implica cambiar la configuración detodos los dispositivos, siempre que el firmware lo soporte. Esta forma de "cambiar la lógica en la red" es muy lentapara el ritmo de innovación actual y no es escalable en absoluto. La opción de usar un servidor con software de redOpen Source instalado no es viable debido a su "lenta" CPU. Los equipos de red precisan de un hardware basado enASICs 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 "Internetde las cosas" y la entrada a la era de la información de muchos países del tercer mundo. Por otra parte, el aumento delancho de banda (fibra óptica) también tiende a aumentar debido al auge de nuevos servicios como IPTV, VoD y Vide-ollamadas. Bajo estas condiciones es necesario un cambio de paradigma que permita redes más flexibles, escalables yeficientes. SDN pretende ser la respuesta al cambio de paradigma y su desarrollo se encuentra ampliamente apoyadopor la comunidad Open Source y por las compañías más grandes del sector.

71

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 decobre, aire, etc). Estas se gestionan de forma distribuida, es decir cada nodo de la red incorpora un firmware que tomalas 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 mediosde transmisión, pero encima presenta una capa de control (software) compuesta por un Controlador y aplicaciones deprogramación. De forma que la gestión de la red pasa a ser centralizada en el Controlador SDN y la "inteligencia" dela 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 medi-ante las llamadas SouthBound APIs, cuya implementación principal es OpenFlow. La capa de Control compuestapor el Controlador SDN tiene una visión global de toda la red física y programa las tablas de flujo de los switchesmediante OpenFlow. La capa de Aplicación se comuncia con la capa de Control mediante las llamadas NorthBoundAPIs, 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 ControladorSDN.

Resumiendo, las aplicaciones definen la "inteligencia" de la red y lo comunican al Controlador SDN mediante unaNorthBound API (API REST por ejemplo). El controlador procesa la información y finalmente lo comunica a losdispositivos 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 Contro-lador modificar las tablas de flujos (Flow-Tables) de los switches físicos de forma dinámica para implementar servicioscomo 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 elpaquete, etiqueta VLAN, MAC origen o destino, protocolo, etc. Si un paquete no encuentra ninguna coincidencia enlas tablas 1debe 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

1En 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 esposible definir múltiples tablas con varias entradas de flujo [5].

72

este nuevo flujo no tendrán que esperar la respuesta del Controlador, sino que serán encaminados a velocidad de lineapor el switch OpenFlow.

4.3.1 Switch OpenFlowUn 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 seguroya 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 actualizalas 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 lasentradas 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 conun 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 eje-cutar 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

Un paquete entra al switch OpenFlow y pasa a la primera tabla de flujos en el switch. Si el switch encuentra co-incidencias en una entrada, se fijará en el campo "Instrucciones" y modificará la variable "Action-Set". Seguidamenteel paquete irá pasando por las tablas de flujos restantes y modificará constantemente el valor de "Action-Set". Final-mente, el switch ejecutará el contenido definido en "Action-Set" de forma ordenada. Como ya sabemos, si el switchno encuentra una entrada compatible deberá informar al Controlador SDN para que este pueda definir una entrada yflujo 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 aotros 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. Elpaquete 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 paquetessospechosos, actuar como firewall, etc.

4.3.2 Mensajes del Protocolo OpenFlowLos 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 unpaquete "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á elpaquete, 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 usapara fijar el rol del Controlador.

2. Mensajes asíncronos: Iniciados por el switch para avisar al Controlador sobre eventos en la red y cambios enel estado del switch.

74

• Packet-in: Transfiere el control sobre el paquete al Controlador SDN. Normalmente porque no encuentraun flujo asociado al paquete, pero también puede ser una acción expresa de una entrada. La respuesta delControlador 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ónOpenFlow.

• Echo: Un "Echo request" puede ser enviado por cualquiera de los dispositivos y el otro extremo de laconexión deberá enviar un "Echo reply".

• Error: Mensajes de error notificados al otro extremo de la conexión. Normalmente, usado por el switchpara 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áquinavirtual (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 encuentradar 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 queOpenDayLight se imponga en el campo de SDN ya que comparten las mismas características (Open Source y soportede la industria). Por esta razón para el proyecto se ha elegido este "Super Controlador SDN" para ser integrado en elservicio Neutron de OpenStack.

La arquitectura de OpenDaylight es totalmente modular. La interfaz de bajo nivel (SouthBound API) soportamúltiples protocolos (plug-ins de OpenDayLight) como OpenFlow 1.0, OpenFlow 1.3, NETCONF, OVSDB, etc. Losplug-ins se conectan dinámicamente a la SAL (Service Abstraction Layer) que funciona como una capa de abstrac-ción para los módulos de redes superiores. Es decir, la SAL permite que OpenDayLight ejecute la tarea solicitadaindependientemente del protocolo usado para conectarse con los equipos físicos.

La figura 4.5 muestra toda la arquitectura OpenDayLight Lithium.

75

Figure 4.5: OpenDayLight Lithium.

4.4.1 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 alsistema OpenStack.

Desde OpenStack, Neutron utiliza el driver OpenDayLight como "mechanism driver" del plug-in ML2 y traspasatodas 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 dependenciade la tecnología elegida en OpenDayLight. La figura 4.7 muestra un esquema de la arquitectura del "Neutron APIservice"

76

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ónelegida.

3. "Implementación": Implementa los servicios de redes de Neutron. En la versión OpenDayLight Lithium ten-emos las siguientes cinco opciones:

(a) OVSDB: Utiliza como protocolo de SouthBound OVSDB para configurar los switches OpenvSwitch en losnodos 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 enOpenvSwitch [12]. Es la opción implementada en nuestro proyecto. La figura 4.8 ilustra esta opción.

Figure 4.8: OVSDB y OpenDayLight.

77

(b) VTN Manager: VTN significa "Virtual Tenant Network" y es una opción de virtualización de red disponibleen OpenDayLight implementada como un "bundle" OSGi de controladores usando la AD-SAL. Tambiéngestiona switches OpenFlow.

(c) Open DOVE: Open DOVE es otra opción de virtualización de red en OpenDayLight basada en tecnologíasSDN 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 usuariodesea implementar seguridad adicional y puede añadir el servicio "Unified Secure Channel" para cifrar las comunica-ciones. 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 Open-vSwitch, aplicando las reglas OpenFlow, levantando los túneles GRE, etc. Los agentes de Neutron "neutron-l3-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 losswitches OpenvSwitch, el controlador SDN controla otras funciones como las tareas L3, el balanceo de carga ofunciones de firewall.

Como se comentó anteriormente nuestra integración de OpenDayLight se realizará a través de OVSDB. La prin-cipal diferencia con la configuración inicial de Neutron es que no se usan los switches "br-tun" en ningún nodo, sinoque los switches "br-int" se encargan de levantar el tunel GRE además de cumplir sus funciones anteriores.

78

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 desarrolloEl controlador SDN OpenDayLight será un nuevo nodo y estará instalado en un contenedor LXC. Es decir, nuestrainfraestructura 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 ennuestra infraestructura OpenStack

OpenvSwitch

Contenedor LXC

Nodo “controller”

SQL MariaDB

Cola de MensajesRabbitMQ

NTP

Keystone

Nova-sheduler

nova-api

Neutron-server

neutron-plugin-ml2

Horizon Glance

Contenedor LXC

Nodo “network”

Neutron-dhcp-agent

neutron-l3-agent

neutron-plugin-ml2

OpenvSwitch

Máquina virtual KVM

Nodo “compute”

Hypervisor KVM

Nova-compute

neutron-plugin-ml2

Metadata-net-agent

Nodo “opendaylight”

Contenedor LXC

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 ML2en Neutron. Dicha función ahora la realizará OpenDayLight desde su propio nodo.

79

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 lared de gestión y mantenido la configuración por defecto de la interfaz eth0 para instalar los paquetes necesarios desdeinternet.

Nodo “controller” Nodo “network” Nodo “compute”

Red de Gestión (11.0.0.0)Red Tunel (11.0.1.0)Red Externa (203.0.113.0)

11.0.0.2

OpenvSwitch

Switch “br-man”

Switch “br-tunnel”

eth1

eth1-control

eth1-network

vnet1

eth2-network vnet2

eth1

11.0.0.3

eth1

eth2 eth2

11.0.1.3 11.0.1.4

11.0.0.4

eth3

Switch “br-out”

eth3-network tap0

Par vethPar veth

Par veth

Par veth

eth0-controleth0-network

vnet0

eth0

Red LXC (10.0.3.0)Red KVM (192.168.122.0)

eth0eth0

Par veth

Par veth

Host net namespace

203.0.113.100

wlan0

NAT(IPtable)

Nodo “opendaylight”

eth0 eth1

11.0.0.5

eth0-odl

Par veth

eth1-odlPar veth

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. Elnombre del portátil es "host" y presenta un sistema operativo Linux Mint 17, compatible con Ubuntu 14.04.

5.2.1 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

# 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 configurationlxc.include = /usr/share/lxc/config/ubuntu.common.conflxc.arch = x86_64

# Container specific configurationlxc.rootfs = /var/lib/lxc/opendaylight/rootfslxc.utsname = opendaylight

# Network configurationlxc.network.type = vethlxc.network.flags = uplxc.network.link = lxcbr0lxc.network.hwaddr = 00:16:3e:8e:73:e6lxc.network.veth.pair = eth0-odl

#Manual configuration for opendaylight node in OpenStacklxc.network.type = vethlxc.network.flags = uplxc.network.veth.pair = eth1-odllxc.network.ipv4 = 11.0.0.5/24

lxc.mount.auto = cgrouplxc.aa_profile = unconfined

Las dos últimas líneas en el fichero del contenedor opendaylight inhabilitan el uso de AppArmor (SeLinux deUbuntu) 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 susistema para comprobar que se han iniciado correctamente.

root@host: lxc-start -n opendaylight -droot@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.

5.2.2 Configuración de OpenvSwitch para conectar el nodo opendaylight1. 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

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


3. Por defecto, en la distribución Linux Mint 17 la herramienta NetworkManager intenta reconfigurar las inter-faces del sistema "host" provocando cambios en las configuraciones de red. Para evitar que NetworkManagermodique 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 OVSauto br-maniface br-man inet static

address 11.0.0.1netmask 255.255.255.0

auto br-tunneliface br-tunnel inet static

address 11.0.1.1netmask 255.255.255.0

#Avoid NetworkManager problem.iface vnet1 inet staticiface eth1-control inet staticiface eth1-network inet static

iface vnet2 inet staticiface eth2-network inet static

iface eth3-network inet static

iface eth0-control inet staticiface eth0-network inet static

#Testing the network for instancesauto br-outiface br-out inet static

address 203.0.113.2netmask 255.255.255.0

auto tap0iface tap0 inet static

address 203.0.113.100netmask 255.255.255.0

iface eth0-odl inet staticiface 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. Unavez comprobados todos los parámetros se podrá continuar al siguiente apartado.

82

5.3 Instalación e integración de OpenDayLightPara instalar y configurar OpenDayLight debemos descargar todos los paquetes necesarios y configurar tanto el nodoopendaylight 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".

5.3.1 Cambios inicialesAntes de instalar nada debemos realizar los siguientes cambios iniciales.

• Nodo OpenDayLight

1. Asignamos al nodo OpenDayLight el hostname "opendaylight".

root@hostname: hostname opendaylight


#controller11.0.0.2 controller#network11.0.0.3 network#compute11.0.0.4 compute#opendaylight11.0.0.5 opendaylight

3. Actualizamos el sistema Linux.

root@opendaylight: sudo apt-get update && apt-get upgrade


• Nodos Restantes

1. Añadimos en el fichero /etc/hosts el nodo OpenDayLight. Finalmente el fichero debe quedar de la siguientemanera:

#controller11.0.0.2 controller#network11.0.0.3 network#compute11.0.0.4 compute#opendaylight11.0.0.5 opendaylight

2. Reiniciamos el sistema LXC o KVM según el nodo.

5.3.2 Instalación de OpenDayLight1. Descargamos la última versión de OpenDayLight desde la web oficial: https://www.opendaylight.org/downloads.

Para nuestro proyecto utilizamos la versión Lithium SR1, exactamente el fichero "distribution-karaf-0.3.1-Lithium-SR1".

2. Pasamos el fichero descargado al nodo opendaylight, por ejemplo mediante scp. (Si decidimos usar scp debemosasignar un password al usuario por defecto "ubuntu" del contenedor LXC).

83

3. En el nodo OpenDayLight instalamos java 1.7.0 (necesaria para OpenDayLight Lithium).

root@opendaylight: sudo apt-get install openjdk-7-jdk

nota: Para la próxima versión OpenDayLight Beryllium se necesitará java 1.8.0.

4. Nos dirigimos al direcctorio donde está el fichero ".tar" y descomprimimos.

root@opendaylight: tar xvfz distribution-karaf-0.3.1-Lithium-SR1.tar.gz

5. Entramos al nuevo directorio.

root@opendaylight: cd distribution-karaf-0.3.1-Lithium-SR1

6. Editamos el fichero "etc/org.apache.karaf.management.cfg" y reemplazamos las siguientes lineas:

#rmiRegistryHost = 0.0.0.0rmiRegistryHost = 127.0.0.1#rmiServerHost = 0.0.0.0rmiServerHost = 127.0.0.1

Este cambio se debe a un error en el fichero de configuración en la versión Lithium-SR1 de OpenDayLight (Másinformació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 queinstala 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 http://odl:8181/index.html.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 OpenDaylightcon el el siguiente comando:

root@opendaylight: curl -u admin:admin /http://opendaylight:8080/controller/nb/v2/neutron/networks

12. Para monitorizar los parámetros de OpenDaylight tenemos el siguiente fichero de logs.

root@opendaylight: tail -f data/log/karaf.log

84

Figure 5.3: Dlux inicial.

5.3.3 Eliminación de instancias, routers y puertos anteriormente creadosPara configurar correctamente OpenDayLight debemos eliminar toda configuración de red anterior realizada por Neu-tron con el driver OpenvSwitch del plug-in ML2. Todas las operaciones de este apartado se realizarán desde el nodoControlador.

1. Cargamos el fichero admin-openrc.sh


2. Listamos las instancias, router, puertos y redes y las eliminamos.

root@controller: nova listroot@controller: nova delete <INSTANCE ID>root@controller: neutron router-listroot@controller: neutron router-gateway-clear <ROUTER ID>root@controller: neutron router-delete <ROUTER ID>root@controller: neutron port-listroot@controller: neutron port-delete <PORT ID>root@controller: neutron net-listroot@controller: neutron net-delete <NEWORK ID>

3. Cargamos el fichero demo-openrc.sh


4. Listamos las instancias, router, puertos y redes y las eliminamos.

root@controller: nova listroot@controller: nova delete <INSTANCE ID>root@controller: neutron router-listroot@controller: neutron router-gateway-clear <ROUTER ID>root@controller: neutron router-delete <ROUTER ID>root@controller: neutron port-listroot@controller: neutron port-delete <PORT ID>root@controller: neutron net-listroot@controller: neutron net-delete <NEWORK ID>

5. Paramos el subservicio neutron-server.

85

root@controller: service neutron-server stop

5.3.4 Nueva configuración de OpenvSwitchNodo de Cómputo

1. El driver de OpenvSwitch para el plug-in ML2 (Neutron-plugin-openvswitch-agent) debe ser pausado ya quesolo OpenDaylight debe controlar los switches OpenvSwitch.

root@compute: service neutron-plugin-openvswitch-agent stoproot@compute: 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 Ubuntu14.04.

2. 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.dbroot@compute: service openvswitch-switch stoproot@compute: service openvswitch-switch startroot@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'='11.0.1.4'}

Por ejemplo el comando que realmente introducimos fue:

root@compute: ovs-vsctl set Open_vSwitch 39aa6b66-da3c-4d10-8b92-254c6e497853 \other_config={'local_ip'='11.0.1.4'}

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:11.0.0.5:6640

Nodo de Red

5. El driver de OpenvSwitch para el plug-in ML2 (Neutron-plugin-openvswitch-agent) debe ser pausado ya quesolo OpenDaylight debe controlar los switches OpenvSwitch.

root@network: service neutron-plugin-openvswitch-agent stoproot@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 Ubuntu14.04.

6. Eliminamos la base de datos interna de OpenvSwitch y reiniciamos su servicio.

86

root@network: rm -rf /var/log/openvswitch/*root@network: rm -rf /etc/openvswitch/conf.dbroot@network: service openvswitch-switch stoproot@network: service openvswitch-switch startroot@network: 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".

root@network: ovs-vsctl set Open_vSwitch <OPENVSWITCH ID> \other_config={'local_ip'='11.0.1.3'}

Por ejemplo el comando que realmente introducimos fue:

root@network: ovs-vsctl set Open_vSwitch 6815b8e4-9842-4c4a-ba8b-08f7636f8bc5 \other_config={'local_ip'='11.0.1.3'}

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 eth3del nodo de Red.

root@network: ovs-vsctl add-br br-exroot@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:11.0.0.5:6640

5.3.5 Configuración del plugin ML2En los nodos Controlador, de Red y de Cómputo debemos editar el fichero /etc/neutron/plugins/ml2/ml2_conf.ini yañadir o reemplazar las siguientes lineas.

[ml2]...#mechanism_drivers = openvswitchmechanism_drivers = opendaylight

[ml2_odl]password = adminusername = adminurl = http://11.0.0.5:8080/controller/nb/v2/neutron

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.

5.3.6 Reinicio de la base de datos de NeutronEn 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:


87

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';


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

5.3.7 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 subservicioneutron-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 5.3.9.

88

5.3.8 Verificación1. 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 accesoexterno".

3. Por otra parte, los dos switches OpenvSwitch y el enlace GRE entre ellos aparece en la interfaz web DLUX deOpenDayLight. Recordamos que el enlace es "http://odl:8181/index.html" y el usuario y password es "admin".

La siguiente captura muestra dicho estado:

Figure 5.4: Dlux final.

5.3.9 Problemas encontradosEn general el Controlador SDN OpenDaylight se ha mostrado más inestable que el sistema OpenStack. La docu-mentación también es más pobre y no existe una guía clara de como integrar OpenDayLight en OpenStack teniendo encuenta 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 estadobeta.

Siguiendo la documentación oficial no pudimos hacer funcionar el sistema OpenStack Kilo bajo OpenDayLightLithium SR1, así que indagando en foros y blogs encontramos aquellas modificaciones que hacía falta, tanto en laconfiguració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 real-mente no eran necesarios. En los foros explican que para la versión Lithium SR1 tan solo se necesitan "odl-ovsdb-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 queno aparece en la documentación oficial.

3. Una vez instalado OpenDaylight necesitamos cambiar el archivo de configuración "distribution-karaf-0.3.1-Lithium-SR1/etc/org.apache.karaf.management.cfg" y reemplazar las siguientes lineas:

#rmiRegistryHost = 0.0.0.0rmiRegistryHost = 127.0.0.1

89

#rmiServerHost = 0.0.0.0rmiServerHost = 127.0.0.1

4. Debido a cambios recientes de la versión Lithium de OpenDayLight (uso de jetty para autenticarse) no se lograla autenticación entre Neutron y OpenDayLight. Cuando lanzamos un comando desde el nodo Controlador alservicio Neutron recibimos como respuesta "error 500". Este error recibido en el nodo Controlador es realmenteun mapeo de un "error 401" (Usuario no autorizado) que recibe el nodo de Red al intentar autenticarse enOpenDaylight.

Para solucionar el error 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)

5. Si se presentan más errores se recomienda analizar el fichero de log de Karaf "distribution-karaf-0.3.1-Lithium-SR1/data/log/karaf.log", así como la monitorización de las interfaces virtuales con la herramienta tcpdump.

90

Bibliography

[1] Usuario Snowball de la comunidad OpenStack. Can ping vm instancebut can’t ssh. https://ask.openstack.org/en/question/30502/can-ping-vm-instance-but-cant-ssh-ssh-command-halts-with-no-output. On-line 16-10-2015.

[2] Comunidad de OpenStack. Arquitectura de openstack juno. http://docs.openstack.org/juno/install-guide/install/apt/content/ch_overview.html#architecture_conceptual-architecture. Online 16-10-2015.

[3] Comunidad de OpenStack. Web oficial de openstack. https://www.openstack.org/. Online 16-10-2015.

[4] Comunidad Django. modwsgi en dejango. https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/modwsgi. Online 16-10-2015.

[5] Open Networking Fundation. The benefits of multiple flow tables and ttps. https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_Multiple_Flow_Tables_and_TTPs.pdf. Online 16-10-2015.

[6] Open Networking Fundation. Openflow switch specification. https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.1.pdf. Online 16-10-2015.

[7] Red Hat. Networking in too much detail. https://www.rdoproject.org/Networking_in_too_much_detail. Online 16-10-2015.

[8] Comunidad ilearnstack. Networking in openstack : Panoramic view. http://ilearnstack.com/2013/10/07/networking-in-openstack-panoramic-view. Online 16-10-2015.

[9] Alfredo Moralejo. Construyendo una nube con openstack. http://es.slideshare.net/LibreCon/alfredo-moralejo-red-hat-def-con-l-ogos. Online 16-10-2015.

[10] National Institute of Standards and Technology. The nist definition of cloud computing. http://faculty.winthrop.edu/domanm/csci411/Handouts/NIST.pdf. Online 16-10-2015.

[11] Comunidad OpenDayLight. Integración de kilo. https://ask.opendaylight.org/question/4280/lithium-integration-with-openstack-kilo/. Online 16-10-2015.

[12] Comunidad OpenDayLight. Opendaylight ovsdb integration. https://wiki.opendaylight.org/view/OVSDB_Integration:Design. Online 16-10-2015.

[13] Comunidad OpenDayLight. Opendaylight use case. https://www.opendaylight.org/example-use-cases. Online 16-10-2015.

[14] Comunidad OpenDayLight. Opnfv needs odl lithium setup help. https://lists.opendaylight.org/pipermail/integration-dev/2015-August/004265.html. Online 16-10-2015.

91

[15] Comunidad OpenDayLight. Web oficial de opendaylight. https://www.opendaylight.org/. Online16-10-2015.

[16] Comunidad OpenStack. Hypervisor feature support matrix juno. https://wiki.openstack.org/wiki/HypervisorSupportMatrix/Juno. Online 16-10-2015.

[17] Comunidad OpenStack. Hypervisor feature support matrix kilo. http://docs.openstack.org/developer/nova/support-matrix.html. Online 16-10-2015.

[18] Comunidad OpenStack. Install guide juno. http://docs.openstack.org/juno/install-guide/install/apt/content. Online 16-10-2015.

[19] Comunidad OpenStack. Storage decisions. http://docs.openstack.org/openstack-ops/content/storage_decision.html. Online 16-10-2015.

[20] Ken Pepple. Deployin openstack havana. http://ken.pepple.info. Online 16-10-2015.

[21] Adam Stokes. Bug 1315216. https://lists.ubuntu.com/archives/ubuntu-server-bugs/2014-May/112878.html. Online 16-10-2015.

[22] Adam Stokes. nested lxc’s within a kvm machine are not accessible. https://bugs.launchpad.net/juju-core/+bug/1304530. Online 16-10-2015.

[23] Marcel Sánchez Toledano. Estudi i implementaciÓ d’un sistema de virtualitzaciÓ basat enlinux containers. http://upcommons.upc.edu/bitstream/handle/2099.1/23590/Marcel%20Sanchez%20-%20TFG.pdf?sequence=4. Online 16-10-2015.

[24] Ubuntu. Lxc installation. https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-installation. Online 16-10-2015.

92

estudio de una solución openstack integrada con sdn ...€¦ · y el de muchas empresas del sector...

Documents