ESTABLECIMIENTO DE LA INTEGRACIÓN ENTRE OPENSTACK Y LAS REDES DEFINIDAS POR SOFTWARE MIGUEL ANTONIO GAITÁN GALLEGO

Transcripción

1 ESTABLECIMIENTO DE LA INTEGRACIÓN ENTRE OPENSTACK Y LAS REDES DEFINIDAS POR SOFTWARE MIGUEL ANTONIO GAITÁN GALLEGO UNIVERSIDAD DE CATÓLICA DE PERERIA FACULTAD DE CIENCIAS BÁSICA E INGENIERÍA INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PERERIA 2016

2 ESTABLECIMIENTO DE LA INTEGRACIÓN ENTRE OPENSTACK Y LAS REDES DEFINIDAS POR SOFTWARE MIGUEL ANTONIO GAITÁN GALLEGO Trabajo de Grado presentado como opción parcial para optar Al título de Ingeniero de sistemas y telecomunicaciones Director NESTOR ALZATE MEJÍA Ingeniero de sistemas UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA PROGRAMA INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PEREIRA 2016

3 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones AGRADECIMIENTOS Quiero agradecer a mis padres, a mi esposa por todo el apoyo y confianza que me han brindado; al Ingeniero de sistemas Néstor Alzate Mejía director de este proyecto y al señor Mauricio Beain de Net Trainers Chile quienes se encargaron de ayudarme con el desarrollo del presente documento

4 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones PÁGINA DE ACEPTACIÓN <NOMBRE COMPLETO> JURADO <NOMBRE COMPLETO> JURADO <NOMBRE COMPLETO> JURADO Pereira, 08 de noviembre de 2016

5 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones CONTENIDO Pág 1 ÁREA PROBLEMÁTICA 16 2 OBJETIVOS 17 3 JUSTIFICACIÓN 18 4 MARCO TEÓRICO CLOUD COMPUTING OPENSTACK Componentes OpenStack Servicios OpenStack TECNOLOGÍAS Y VARIANTES EN LOS COMPONENTES BASE DE OPENSTACK Almacenamiento en el componente Storage Interconexión en el componente Networking Hypervisores en el componente Compute REDES DEFINIDAS POR SOFTWARE (SDN) Arquitectura SDN Modelos SDN Protocolo OpenFlow CONTROLADORES SDN OPENDAYLIGHT CONTROLLER (ODL) OPENSTACK Y OPENDAYLIGHT ANTECEDENTES 53 5 METODOLOGÍA TIPO DE TRABAJO PROCEDIMIENTO Creación del ambiente mínimo y virtualizado para el desarrollo del proyecto Instalación, configuración, listamiento y verificación del funcionamiento de los diferentes servicios en los nodos Creación de redes 100

6 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones 524 Instalación interface web Instalación controlador Opendaylight Integración de Opendaylight Pruebas para verificar la integración entre OpenStack y OpenDaylight RESULTADOS DESCRIPCIÓN DE RESULTADOS CONCLUSIONES RECOMENDACIONES BIBLIOGRAFÍA 118

7 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones LISTA DE FIGURAS Pág Figura 1 Cloud Computing 19 Figura 2 Esquema de los modelos de servicios 21 Figura 3 Componentes base de OpenStack 23 Figura 4 Componentes del servicio Object Storage 25 Figura 5 Componentes del servicio Block Storage 26 Figura 6 Componentes y relaciones de Horizon 28 Figura 7 Componentes y procesos del servicio Compute (Nova) 29 Figura 8 Componentes y procesos del servicio Networking (Neutron) 32 Figura 9 Componentes y procesos de Image Service 34 Figura 10 Diagrama de flujo de Identity Service 36 Figura 11Arquitectura conceptual de Openstack versión Juno 38 Figura 12 Concepto SDN 41 Figura 13 Arquitectura SDN 42 Figura 14 Modelo SDN centralizado 44 Figura 15 Modelo SDN distribuido 44 Figura 16 Modelo SDN híbrido 45 Figura 17 Arquitectura OpenDaylight Lithium 50 Figura 18 Arquitectura de implementación de la Neutron API 52 Figura 19 Implementación de OVSDB 53

8 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones LISTA DE TABLAS Pág Tabla 1 Lanzamientos de OpenStack 22 Tabla 2 Controladores SDN 48 Tabla 3 Servicios, APPs y protocolos de ODL 49

9 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones GLOSARIO AMQP: protocolo de estándar abierto en la capa de aplicaciones de un sistema de comunicación APIS REST: servicio que provee de funciones, los cuales dan la capacidad de hacer uso de un servicio web que no es nuestro, dentro de una aplicación propia, de manera segura BGP: protocolo mediante el cual se intercambia información de encaminamiento o ruteo entre sistemas autónomos CAPWAP: protocolo que permite a un controlador de acceso (AC) gestionar una colección de puntos de terminación inalámbricas CLI: interfaz de línea de comandos CLOUD COMPUTING: modelo que permite el acceso conveniente a la red bajo demanda para compartir un conjunto de recursos de cómputo configurables DATA CENTER: aquella ubicación donde se concentran los recursos necesarios para el procesamiento de la información de una organización DHCP: protocolo de configuración dinámica de host DITG: es una plataforma capaz de producir el tráfico a nivel de paquetes replicar con precisión los procesos estocásticos adecuados DOCKER: plataforma abierta para aplicaciones distribuidas para los desarrolladores y administradores de sistemas EDO: ecuación diferencial es una ecuación matemática que relaciona una función con sus derivadas FLAVOR: asignación del tamaño de memoria RAM, CPU, tamaño de disco que luego son asignados a los usuarios FPGA: dispositivo programable que contiene bloques de lógica cuya interconexión y funcionalidad puede ser configurada GRE: protocolo para el establecimiento de túneles a través de Internet HTTP: protocolo de comunicación que permite las transferencias de información en la World Wide Web

10 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones IAAS: componente del denominado Cloud Computing INSTANCIA: máquina virtual iniciada y terminada por el servicio Compute (Nova) JSON: acrónimo de JavaScript Object Notation, es un formato de texto ligero para el intercambio de datos KUBERNETES: sistema de código abierto para la automatización de la implementación, operaciones, y la escala de las aplicaciones en contenedores KVM: iniciales de Kernel-Based Virtual Machine, es una solución virtual para Linux en hardware x86, que contiene extensiones de virtualización LIBVIRT: juego de herramientas para interactuar con las capacidades de virtualización de versiones recientes de Linux (y otros sistemas operativos) LXC: tecnología de virtualización en el nivel de sistema operativo (SO) para Linux MOD_WSGI: servidor HTTP Apache MULTI-TENANT: concepto de arquitectura el cual permite que múltiples clientes puedan acceder al mismo recurso con seguridad, confiabilidad y rendimiento consistente MYSQL: sistema de gestión de bases de datos relacional NAT: mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que asignan mutuamente direcciones incompatibles NETCONF: protocolo de configuración de red NETFPGA: el proyecto cuyo esfuerzo es desarrollar el hardware de código abierto NFV: virtualización de las Funciones de la Red NODO: punto de intersección, conexión o unión de varios elementos que confluyen en el mismo lugar NOX: controlador de las redes definidas por software OPEN SOURCE: software distribuido y desarrollado libremente OPENDAYLIGHT: controlador de las redes definidas por software

11 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones OPENFLOW: protocolo emergente y abierto de comunicaciones que permite a un servidor de software determinar el camino de reenvío de paquetes OPENPIPES: plataforma para la construcción de sistemas de hardware distribuidos OPENSTACK: sistema operativo en la nube OPENVSWITCH: software de código abierto, diseñado para ser utilizado como un switch virtual en entornos de servidores virtualizados PLUG-IN: aplicación o programa informático que se relaciona con otra para agregarle una función nueva y generalmente muy específica PROTOCOLO: sistema de reglas que permiten que dos o más entidades de un sistema de comunicación se comuniquen entre ellas para transmitir información PROXY: es un servidor programa o dispositivo que hace de intermediario en las peticiones de recursos que realiza un cliente PYTHON: lenguaje de programación interpretado cuya filosofía hace hincapié en una sintaxis que favorezca un código legible QOS: conjunto de tecnologías que garantiza la transmisión de cierta cantidad de información en un tiempo determinado a uno o varios dispositivos QUEMU: emulador de procesadores basado en la traducción dinámica de binarios RABBITMQ: software de negociación de mensajes de código abierto, y entra dentro de la categoría de middleware de mensajería SDN: redes definidas por software SPI: estándar de comunicaciones, usado principalmente para la transferencia de información entre circuitos integrados en equipos electrónicos SPICE: programa de simulación con énfasis en circuitos integrados SQLITE: sistema de gestión de bases de datos relacional compatible con ACID TCP: protocolo de Control de Transmisión TOKEN: cadena de caracteres que tiene un significado coherente en cierto lenguaje de programación

12 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones TTP: un modelo de Switch abstracto que describe el comportamiento de envío, un controlador OpenFlow puede programarlo a través del protocolo OpenFlow-Switch UDP: protocolo del nivel de transporte basado en el intercambio de datagramas VLAN: método para crear redes lógicas independientes dentro de una misma red física VM: software que simula a una computadora y puede ejecutar programas como si fuese una computadora real VNC: programa de software libre basado en una estructura cliente-servidor el cual permite tomar el control del ordenador servidor remotamente a través de un ordenador cliente WLAN: red de área local inalámbrica XENSERVER: plataforma para administración de hipervisor y virtualización de servidores YAML: formato de serialización de datos legible por humanos inspirado en lenguajes como XML, C, Python, Perl

13 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones RESUMEN El presente documento pretende mostrar cómo se integra la plataforma de OpenStack y las SDN, ya que la primera carece de flexibilidad, despliegue y gestión de las redes; mediante este trabajo se expone el controlador ODL como una solución a dicho problema En la primera sección del documento se toman los referentes teóricos de dichas herramientas y los antecedentes del presente trabajo, una segunda parte de carácter metodológico donde se muestra cómo se implementa y se configura un ambiente básico de la plataforma OpenStack; para este proceso se realiza la instalación y configuración de tres máquinas virtuales corriendo bajo virtualbox, se añaden interfaces de red para la gestión, para los túneles y para la conexión hacia afuera de la misma, se instalan los diferentes servicios, subservicios en cada máquina configurándose ciertos parámetros y edición de algunos archivos para el funcionamiento del ambiente; posteriormente se instala el controlador SDN sobre el nodo controller, donde este se integra con OpenStack por medio del ML2 plug-in del servicio neutron de OpenStack y OVSDB de ODL; por último una tercera parte de pruebas en la cual se crean redes sobre la plataforma de OpenStack y dos switches virtuales que serán gestionados por el controlador ODL Esta integración permite una mayor gestión y despliegue, brindando la agregación de nuevos servicios, cargas de trabajo con mucha más agilidad y flexibilidad, reduciendo la complejidad en la implementación de las redes, donde el controlador gestiona los cambios dinámicos automáticamente; esta integración puede implementarse sobre nubes de tipo pública, privada, comunitaria e hibrida PALABRAS CLAVES: OpenStack, OpenDaylight, SDN, integración, virtualización

14 Universidad Católica de Pereira Facultad de Ciencias Básicas e Ingeniería Ingeniería de Sistemas y Telecomunicaciones ABSTRACT This document aims to show how the OpenStack platform and the SDNs are integrated, since the first one lacks flexibility, deployment and management of the networks; This work presents the ODL driver as a solution to this problem In the first section of the document are taken the theorists references of these tools and the background of the present work, a second part of a methodological character that shows how to implement and configure a basic environment of the OpenStack platform; For this process the installation and configuration of three virtual machines running under virtualbox is done, network interfaces are added for the management, for the tunnels and for the connection out of the same one, the different services are installed, subservicios in each machine being configured Certain parameters and editing of some files for environment operation; Later the SDN controller is installed on the controller node, where it is integrated with OpenStack through the ML2 plugin of the Neutron service of OpenStack and OVSDB of ODL; Finally a third part of tests in which networks are created on the OpenStack platform and two virtual switches that will be managed by the ODL driver This integration allows greater management and deployment, providing the aggregation of new services, workloads with much more agility and flexibility, reducing the complexity in the implementation of networks, where the controller manages the dynamic changes automatically; This integration can be implemented over public, private, community, and hybrid clouds KEY WORDS: OpenStack, OpenDaylight, SDN, integration, virtualization

15 INTRODUCCIÓN Dentro del cloud computing y en especial sobre OpenStack donde la implementación, despliegue y gestión de las redes es compleja, se presenta la integración con el controlador OpenDaylight como una solución a dicho problema en los data center cloud, en muchas partes la tecnología pasada funciona aún, pero esta se presenta obsoleta por muchos motivos como son la rigidez de las redes, el alto costo de sistemas operativos, servidores de red alojados en máquinas de alto precio, hardware de múltiples fabricantes donde se implementan diferentes protocolos que a su vez se convierten en problemas; como parte de la solución a estos y muchos más problemas se presenta una tendencia de flexibilizar y de programar los sistemas donde aparecen una serie de hitos que nos muestra el camino a seguir, en este aparecen las iniciativas del Software libre y Open Source, se desarrollan lenguajes de programación los cuales pueden ser ejecutados en diferentes sistemas sin la necesidad de sobrescribirlos, se implanta el Cloud Computing como alojamiento de aplicaciones, funciones de red y datos de forma remota donde no hay preocupación por su disponibilidad y almacenamiento, surge la virtualización en la que se pueden implementar varios y diferentes servidores en un mismo hardware aprovechando todos los recursos físicos disponibles, las redes son flexibilizadas en busca de aumentar su gestión con aplicaciones que permitan su control y programación de forma centralizada, eliminando errores y disminuyendo tiempos en su configuración Este proyecto busca mostrar cómo se puede crear un ambiente básico de OpenStack y luego ser integrado con el controlador ODL para permitir la flexibilización, el escalamiento y la gestión de las redes de forma programable Por último se pretende que este trabajo anime nos solo a los demás estudiantes, sino también a las diferentes universidades, semilleros de investigación, empresas de la región y del país a profundizar e implementar esta tecnología 15

16 1 ÁREA PROBLEMÁTICA Con el crecimiento exponencial de las nuevas tecnologías manejadas en los data center y los diferentes prestadores de servicios IaaS, se presenta el problema con la complejidad, el manejo, la administración y la configuración de las redes, las cuales deberían crecer al mismo ritmo, esta desigualdad afecta de una u otra forma la prestación del servicio; dichas redes presentan rigidez, poca escalabilidad y falta de automatización, lo cual complica su administración y manejo provocando una serie de problemas como pueden ser retrasos, cuellos de botella, caídas y perdida de fiabilidad en el servicio prestado Por estos y muchos más motivos se hace necesario crear o implementar herramientas que ofrezcan una gestión sobre las redes de manera centralizada, flexible, escalable, automática y configurable 16

17 2 OBJETIVOS 21 OBJETIVO GENERAL Establecer la integración entre OpenStack release Juno y las Redes Definidas por Software para permitir la gestión de las redes de una forma centralizada, flexible, automática y escalable 22 OBJETIVOS ESPECÍFICOS Implementar un ambiente básico de Openstack release Juno Integrar el ambiente básico de OpenStack con el controlador SDN seleccionado Realizar pruebas necesarias para verificar su funcionamiento 17

18 3 JUSTIFICACIÓN La integración entre OpenStack y Opendaylight ofrece soluciones a la nube ya sea privada, pública, comunitaria o hibrida, permitiendo flexibilizar sus recursos de red, habilitando un aprovisionamiento rápido de sus servicios, brindando herramientas que le permita gestionar de forma segura las redes virtuales Para los proveedores de servicios entre ellos los data center cloud, les ofrece mayor escalabilidad y automatización, simplificando la activación de nuevos servicios a la medida y bajo demanda, al igual que un autoservicio para los clientes; así mismo el concepto de alojamiento multi-tenant el cual será soportando de una manera más óptima 18

19 4 MARCO TEÓRICO El presente apartado tiene como finalidad realizar una descripción y presentar una visión más amplia sobre los conceptos de OpenStack, las SDN y el controlador Opendaylight, con el propósito de crear un contexto, posteriormente mostrar cómo podría ser el proceso de integración de los mismos 41 CLOUD COMPUTING Es un nuevo concepto tecnológico aplicado a los diferentes servicios que se pueden prestar ubicados en la nube, reúne diversas ideas como el almacenamiento de información, la provisión de servicios, infraestructura de red entre otros Figura 1 Cloud Computing Fecha de consulta 16/05/2016 disponible en /220px-Cloud_computingsvgpng Según la National Institutte of Technology and Standards (NIST) define el cloud computing como un modelo que permite el acceso conveniente a la red bajo demanda para compartir un conjunto de recursos de cómputo configurables por 19

20 ejemplo: redes, servidores, almacenamiento, aplicaciones y servicios; estos pueden ser rápidamente provisionados y liberados con el mínimo esfuerzo de administración o interacción servicio proveedor (Citado en Mell y Grance, 2011) Este modelo de nube está compuesto de cinco características esenciales, tres modelos de servicio y cuatro modelos de despliegue Características esenciales Servicio bajo demanda: el cliente o usuario puede proveerse de los recursos en forma automática, como el de almacenamiento y los servicios de red, sin que haya alguna intervención de tipo humano Acceso amplio a la red: los servicios deben estar disponibles y se pueden acceder a ellos a través de mecanismos estándar y plataformas comunes Puesta en común de recursos: Los recursos del proveedor son combinados para servir a múltiples consumidores, mediante un modelo de multi-tenant ( * ), estos son asignados y reasignados de manera dinámica según la demanda, no se tiene conocimiento sobre la ubicación exacta de los recursos proporcionados Rápida elasticidad: los recursos puestos a disposición deben crecer o disminuir en forma a su demanda y cambiantes con la mayor rapidez posible de una manera automática Medición del servicio: los sistemas cloud controlan y optimizan automáticamente los recursos mediante la capacidad de medición apropiada para cada tipo de servicio, todos los recursos pueden ser monitoreados, controlados e informados proporcionando transparencia para el usuario y el proveedor del mismo Modelos de servicio ( ** ) Software como Servicio (SaaS): permite al usuario final usar las aplicaciones que corren sobre una infraestructura cloud, dichas aplicaciones deben ser fáciles de acceder desde una interfaz de cliente ligero como es un navegador web por ejemplo: Gmail, Dropbox Plataforma como un Servicio (PaaS): esta plataforma permite a los desarrolladores crear sus propias aplicaciones utilizando lenguajes de * Multi-tenant es un concepto de arquitectura el cual permite que múltiples clientes puedan acceder al mismo recurso con seguridad, confiabilidad y rendimiento consistente ** En la actualidad aparece en la nueva clasificación de los modelos de servicio Metal as a Service (MaaS), que permite tratar los servidores físicos como máquinas virtuales en la nube 20

21 programación, APIs ( * ), servicios y demás herramientas, el programador no posee control sobre la infraestructura adyacente como son las redes, el almacenamiento, sistemas operativos, servidores, pero si sobre las aplicaciones desplegadas; entre algunos ejemplos de SaaS tenemos Windows Azure, Forcecom, Google App Engine, entre otros Infraestructura como un Servicio (IaaS): permite al usuario provisionarse de almacenamiento, redes, procesamiento y demás recursos fundamentales, en este se pueden desplegar y ejecutar software de manera arbitraria; el consumidor no puede acceder a la infraestructura adyacente pero si posee control sobre los sistemas operativos, almacenamiento y aplicaciones desplegadas, el control posiblemente limitado a ciertos componentes de red como pueden ser: OpenStack, IBM SoftLayer, AWS, entre otros Figura 2 Esquema de los modelos de servicios Fecha de consulta 16/05/2016 disponible en rodnwibc_2c/t7gmnxejmri/aaaaaaaaad4/a_ibteudbli/s1600/cloudbexmodelo-serviciopng Modelos de implementación Nube privada: su infraestructura está preparada para el uso exclusivo de una organización, comprende varios consumidores por ejemplo unidades de negocio, normalmente se implementan para el uso de las IaaS * API (Application Programming Interface) es un formato de mensajes utilizado para comunicar una aplicación con el sistema operativo u otro programa de control 21

22 Nube comunitaria: son nubes implementadas para el uso exclusivo de una comunidad que comparten asuntos, puede ser operada, administrada por una o más organizaciones de la comunidad como por ejemplo: la red de clínicas, la red del ejército, entre otros Nube pública: está preparada para el uso del público en general, puede ser operada por una empresa, la academia, una organización gubernamental, o alguna combinación entre ellas, en estas normalmente se cobran por los servicios prestados según el tiempo y la capacidad de los recursos, permiten gran escalabilidad Nube Híbrida: su infraestructura se basa en la composición de dos o más modelos de implementación, las nubes híbridas ofrecen la promesa de ser escalables provisionada externamente y a demanda, permitiendo cubrir tareas criticas cuando sea necesario 42 OPENSTACK Es un sistema operativo en la nube, que controla grandes superficies de computo, almacenamiento, y recursos de red a través de un centro de datos, todo ello es gestionado por un panel de control mientras los usuarios se aprovisionan de recursos por medio de una interfaz web Según Pepple (2011) el proyecto OpenStack tiene como objetivo crear una plataforma de computación de código abierto para nubes públicas y privadas, dirigidas a la escalabilidad sin complejos, inicialmente se centran en el ofrecimiento de infraestructura como un servicio (IaaS) El proyecto OpenStack comenzó a través del trabajo de dos organizaciones Rackspace Hosting liberando el código de sus servicios Cloud files y Cloud servers, la NASA con el código de la plataforma Nébula, decidieron unir sus fuerzas, ambos forman el núcleo inicial de OpenStack que está programado en Python, su diseño modular permite el desarrollo de Plug-ins ( * ) en otros lenguajes, pero siempre respetando las APIs REST ( ** ) OpenStack desde el 2010 ha desarrollado varias versiones, estas son presentadas en ciclos de 6 meses desde la versión inicial, en la siguiente tabla observamos la lista de lanzamientos Tabla 1 Lanzamientos de OpenStack * Plug-ins aplicación o programa informático que se relaciona con otra para agregarle una función nueva y generalmente muy específica ** APIs REST es un servicio que nos provee de funciones que nos dan la capacidad de hacer uso de un servicio web que no es nuestro, dentro de una aplicación propia, de manera segura 22

23 Fuente: relasesopenstackorg Fecha de consulta 17/05/2016 Disponible en El presente proyecto se desarrolla bajo el lanzamiento Juno de Openstack 421 Componentes OpenStack OpenStack está compuesto por tres componentes base: cómputo, almacenamiento y red, son administrados mediante una interfaz web, el conjunto de estos componentes crean y administran los servicios en una nube de equipos computacionales como son los permisos de acceso, manejo de la red y ejecución de instancias ( * ); los tres componentes básicos de OpenStack son presentados en la siguiente imagen Figura 3 Componentes base de OpenStack * Se entiende por instancia a la máquina virtual iniciada y terminada por el servicio Compute (Nova) 23

24 Figura 3 Componentes base de OpenStack Fuente: openstackorg Fecha de consulta 17/05/2016 Disponible en Componente de Computo (Compute): encargado de controlar la nube, administrar la ejecución de instancias, tiene como función configurar los recursos asignados a los usuarios que son accedidos a través de las APIs, está diseñado para crecer de forma horizontal sobre hardware estándar, es manejado bajo los servicios Nova y Glance Componente de Red (Networking): su función es permitir la conectividad entre servicios, componentes, redes externas, proporciona una API para definir las redes, su arquitectura conectable soporta varios proveedores de redes y tecnologías, es administrado bajo el servicio Neutron Componente de almacenamiento (Storage): proporciona un sistema de alta capacidad de depósito, altamente escalable, incluye un sistema de alta redundancia, almacena y recupera los objetos a través del sistema de almacenamiento de objetos, provee al alojamiento en bloque, este componente es manejado por los servicios Cinder y Swift 422 Servicios OpenStack Los servicios de OpenStack suelen tener una independencia a la hora de la instalación, es decir, cada servicio puede tener su nodo o compartirlo con otros servicios, cada uno de estos posee subservicios que a su vez pueden ser separados de los suyos y ser instalados en nodos distintos, esto se debe al diseño que el arquitecto Cloud defina para cada nube creada Seguidamente se explican los diferentes servicios de OpenStack 24

25 Object Storage (Swift): Su función está basada en el almacenamiento y recuperación de objetos no estructurados a través de un API REST, basado en HTTP ( * ); es altamente tolerante a fallos debido a su replicación de datos, de escalabilidad horizontal, completamente distribuido permitiendo que hayan múltiples copias de un mismo objeto, dándole a la nube alta fiabilidad y disponibilidad; según Pepple (2011) este es probablemente el proyecto madre dentro de OpenStack, esta es la tecnología subyacente que alimento el servicio de CloudFiles de Rackspace, este solo interactuaba tangencialmente con Nova Dentro de las principales características del servicio Swift podemos encontrar las siguientes: Alberga imágenes del servicio Glance y los posibles Backups de volúmenes del servicio Cinder Almacena y recupera los archivos de los contenedores creados Administra las versiones de los objetos Ofrece acceso a los diferentes objetos mediante el protocolo HTTP Posee el componente Swift-proxy que acepta las peticiones a través de la API de objetos de OpenStack, por medio de la API REST genera el acceso a los clientes Utiliza balanceo de carga para garantizar la consistencia y disponibilidad de los datos en el clúster de almacenamiento Figura 4 Componentes del servicio Object Storage * HTTP protocolo de comunicación que permite las transferencias de información en la World Wide Web 25

26 Fuente wwwslidesharenet Fecha de consulta 17/05/2016 Disponible en Descripción de los componentes del servicio Object Storage Swift-proxy Administra las solicitudes enviadas a través del API mediante el protocolo HTTP, carga los archivos recibidos, modifica los metadatos y contenedores, utiliza una memoria de tipo cache (memcache) Acount Define el nombre para los contenedores, en OpenStack una cuenta es sinónimo de cliente Container Representa un espacio de nombre para los objetos, administra el mapeo de los contenedores o carpetas dentro del servicio dentro del almacenamiento de objetos Object Entidad que almacena información como un documento, imagen o fichero, posee metadatos extendidos y asociados al dato que contiene, tiene un identificador único que permite la recuperación sin conocer su ubicación física Block Storage (Cinder) Es el encargado de proporcionar almacenamiento persistente, bloquea las instancias que se encuentran en ejecución, ayuda y facilita la creación, la gestión del almacenamiento en bloque, en donde los usuarios interactúan con este tipo de almacenamiento vinculado a las instancias en ejecución Sus principales características: Sus volúmenes son persistentes, es decir, se pueden desvincular de una instancia y vincularlo a otra sus datos mantienen intactos Su API de almacenamiento en bloque permite la manipulación de bloques Realiza respaldo de los volúmenes, incluyendo los que están siendo utilizados Consulta el estado de los bloques y de sus metadatos Utiliza por defecto LVM ( * ) de backend para proveer los volúmenes Usa una cola de mensajes para el traspaso de ellos entre Cinder-volume y Cinder-scheduler Figura 5 Componentes del servicio Block Storage * LVM es una implementación de un administrador de volúmenes lógicos para el kernel Linux Se escribió originalmente en 1998 por Heinz Mauelshagen 26

27 Fuente wwwslidesharenet Fecha de consulta 17/05/2016 Disponible en Descripción de los componentes del servicio Block Storage Cinder-API acepta las consultas y son direccionadas hacia Cinder-volume para seguir con la petición Cinder-volume actuando según la petición mediante la lectura y escritura de la base de datos propia de Cinder, determinando el estado de la petición e interactuando con otros procesos como Cinder-scheduler; a través de la cola de mensajes y directamente con el hardware y software de almacenamiento Cinder-volume puede interactuar con un variado número de proveedores de almacenamiento mediante su arquitectura de controladores genéricos y propios de cada proveedor, entre estos podemos encontrar los de IBM, SolidFire, NetAPP, Windows Server 2012 iscsi, entre otros Cinder data base guarda el estado de los volúmenes Cinder-scheduler es el subservicio encargado de seleccionar un bloque de almacenamiento adecuado para crear el volumen sobre él Dashboard (Horizon) Utiliza un portal de autoservicio basado en la web para interactuar con los servicios de OpenStack subyacentes, como el lanzamiento de una instancia, la asignación de direcciones IP y las configuraciones de controles de acceso; evitando el uso de las APIs de cada proyecto 27

28 Entre sus principales características podemos encontrar: Aplicación web basado en Django( * ) Posee una base de datos SQLite Utiliza APIs estándares para comunicarse con los demás servicios Se implementa a través de mod_wsgi en Apache Administración de discos lógicos; creación, eliminación Acceso a las imágenes y su gestión Uso de seguridad relacionada a los usuarios e instancias que han creado Definición de flavors ( ** ) para los usuarios Acceso a los detalles relacionados con los servicios en ejecución Detalle de la topología de red Migración de instancias hacia otros nodos En la siguiente figura se ilustra los componentes y relaciones de Horizon con los demás servicios de OpenStack Figura 6 Componentes y relaciones de Horizon * Django es un framework escrito en Python para desarrollar aplicaciones web ** Flavors se entiende por la asignación del tamaño de memoria RAM, CPU, tamaño de disco que luego son asignados a los usuarios 28

29 Fuente Fecha de consulta 17/05/2016 Disponible en Compute (Nova) Gestiona el ciclo de vida de las instancias, es decir, lanzar, reiniciar, suspender o parar las máquinas virtuales, es responsable de la programación, administra de forma central todos los demás nodos mediante el envío de mensajes en cola, gestiona los recursos de infraestructura que son asignadas a las instancias, por su diseño escala de forma horizontal, opera con múltiples hipervisores, sin embargo en su mayoría se utiliza KVM ( * ) y XenServer ( ** ); su módulo principal está programado en Python, forma parte fundamental de OpenStack Es el componente con mayor ejecución de procesos, uno de ellos es el acceso programable vía RESTful API de consulta, el cual es enviado por el usuario a las máquinas virtuales en funcionamiento, interactúa con el Identity Service (Keystone), con Image Service (Glance), con Dashboard (Horizon) Figura 7 Componentes y procesos del servicio Compute (Nova) Fuente Fecha de consulta 17/05/2016 Disponible en Descripción de los componentes Compute (Nova) * KVM son las iniciales de Kernel-Based Virtual Machine, es una solución virtual para Linux en hardware x86, que contiene extensiones de virtualización ** XenServer Una plataforma para administración de hipervisor y virtualización de servidores 29

30 Nova-api Acepta y da respuesta a las peticiones del usuario final, ya sea a través de los API de OpenStack Compute, Amazon EC2 o de Horizon, trabaja en conjunto con el servicio Keystone para obtener la autenticación, se encarga de hacer la petición a glance-api para comprobar si hay imágenes disponibles para las instancias Dentro de sus actividades está el lanzamiento de máquinas virtuales, se asocia con otro subservicio llamado nova-api-metadata el cual acepta peticiones de metadatos de las instancias Nova-compute Su función es la de administrar la virtualización, crear y terminar las máquinas virtuales a través de la API del hipervisor correspondiente, XenServer lo hace con el XenAPI, KVM o QUEMU con libvirt ( * ), se comunica con neutrón-server para conectar las instancias a las redes virtuales y con cinder-api para montar volúmenes en dichas instancias Nova-schedule Organiza el estado de las solicitudes de instancias en cola de mensajes y luego determina que equipo lo alojará y ejecutará la misma, este proceso se logra actualizando la base de datos, realiza la planificación de los recursos Nova-conductor Actualiza el estado, los cambios de las bases de datos generados por otros procesos, se encuentra en el medio de novacompute y la base de datos, por seguridad se instala en otro nodo donde no se encuentre nova-compute Nova-consoleauth Autoriza los tokens para usuarios que deseen acceder a los proxies de la consola, utiliza nova-novncproxy y Nova-xvpvncproxy, se debe usar alguno y debe estar en ejecución para que el usuario actué con sus instancias vía consola CLI ( * ) a través de un proxy Nova-novncproxy Este provee un proxy el cual accede a las instancias en ejecución a través de VNC ( ** ), este es soportado por navegadores que trabajan como clientes novnc Nova-spicehtml5proxy Proporciona un proxy para acceder a las instancias en ejecución a través de una conexión de SPICE Soporta navegadores basados en HTML5 Nova-xvpvncproxy Proporciona un proxy para acceder a las instancias en ejecución a través de una conexión VNC Soporta un cliente Java- OpenStack específica Nova-cert Proporciona los certificados X509, que son usados principalmente para la API EC2 de Amazon Nova client Permite a los usuarios enviar comandos como cliente administrador o cliente final * Libvirt Es un juego de herramientas para interactuar con las capacidades de virtualización de versiones recientes de Linux y otros sistemas operativos * Consola CLI o la interfaz de línea de comandos ** VNC son las siglas en inglés de Virtual Network Computing (Computación Virtual en Red) es un programa de software libre basado en una estructura cliente-servidor el cual permite tomar el control del ordenador servidor remotamente a través de un ordenador cliente 30

31 Cola de mensajes Centraliza el envío de mensajes entre los diferentes subservicios de OpenStack, esta es implementada con RabbitMQ ( *** ), aunque se puede usar AMQP ( **** ) SQL database Almacena los estados de instancias en ejecución (runtime) y disponibilidad para nuevas instancias (build-time) Instancias en uso, tipos de instancias disponibles, redes y proyectos disponibles En teoría, OpenStack Compute puede soportar cualquier base de datos, las bases de datos comunes son SQLite3 para pruebas y para desarrollo de trabajo, MySQL, MariaDB, y PostgreSQL Networking (Neutron) Proporciona un API que permite definir la conectividad de la red y el direccionamiento en la nube como un servicio para interfaces virtuales (vnics) creadas por Nova Permite crear y adjuntar dispositivos de interfaz que gestionan otros servicios a las redes Los Plug-in pueden ser implementados para dar cabida a diferentes equipos de red y software, proporcionando flexibilidad a la arquitectura OpenStack y despliegue a la misma Gestiona todas las facetas de redes para la infraestructura de red virtual (VNI) y los aspectos de la capa de acceso de la infraestructura de red física (PNI) en el entorno de OpenStack en red, que permite a los usuarios crear topologías de red virtuales avanzadas, incluyendo servicios tales como firewalls, balanceadores de carga y redes privadas virtuales (VPN) Su nombre inicial fue Quantum, pero debido a problemas de copyright tuvo que cambiar su nombre a Neutron, en este servicio se manejan varios conceptos como son: Plug-in Inicialmente la gestión de la red se hacía a través del subservicio nova-network de Nova, luego de la versión Grizzly pasó a un desarrollo de forma autónoma, donde despertó el interés de los programadores de la comunidad OpenStack y de compañías privadas como Cisco y Juniper, viendo la oportunidad de desarrollar controladores de red virtuales que brindarían mayor capacidad de procesamiento y protección a fallos; en sus inicios presentaba un modelo básico de aislamiento por medio de VLANs e IPtables en Linux, con la introducción de este servicio aparece el concepto de plug-in, este se define como una implementación enchufable de back-end del API de red de OpenStack El mencionado puede usar cualquier tecnología que le permita la lógica de la API, algunos plug-in usan las VLANs, otros usan el protocolo OpenFlow o túneles L2 in L3, dentro de los plug-in existen los llamados propietarios que dan soporte a equipamientos físicos de marcas en especial como son *** RabbitMQ es un software de negociación de mensajes de código abierto, y entra dentro de la categoría de middleware de mensajería **** AMQP (Advanced Message Queuing Protocol) es un protocolo de estándar abierto en la capa de aplicaciones de un sistema de comunicación 31

32 (HP, Cisco, entre otros) para el manejo de las redes virtuales Por otro lado, algunos plug-in se asocian con agentes en especial que se encuentran en los diferentes nodos del sistema Cloud, los cuales ayudan al cumplimiento de sus funciones, uno de estos es el plug-in OVS, este se asocia con el agente neutron-plugin-openvswitch-agent Neutron ML2 (Modular Layer 2) Este plug-in se maneja como un framework, el cual le permite aprovechar la variedad de tecnologías de capa de red 2 encontrados en los centros de datos complejos a nivel mundial como son: (Túneles GRE, túneles XVLAN, VLANs), está destinado a sustituir los demás plug-in monolíticos asociados a esta capa, actualmente trabaja con los agentes openvswitch, linuxbrigde y Hyperv L2, tiene por objeto simplificar el apoyo de la nuevas tecnologías de red de dicha capa Agente Se vincula con un plug-in para el cumplimiento de su tarea de red en concreto, el neutron-l3-agent brinda enrutamiento de capa 3 y NAT que provee acceso externo a las instancias, por otro lado esta neutron-dhcpagent, el cual provee servicio DHCP para las redes internas Características del servicio Networking (Neutron) Los usuarios pueden crear sus propias redes y adicionar sus máquinas virtuales a ellas Su arquitectura basada en plug-in permite que los usuarios utilicen los equipos de red de tipo propietario y no propietario Se pueden añadir funcionalidades avanzadas a la red para ser consumidas como son los Firewalls, balanceadores de carga, VPNs entre otros Permite la asignación de IP de redes externas a puertos de redes internas Soporta grupos de seguridad, el cual permite definir reglas para grupos en especial Posee soporte para las SDN mediante un plug-in determinado Figura 8 Componentes y procesos del servicio Networking (Neutron) 32

33 Fuente Propia Descripción de los procesos del servicio Networking (Neutron) Neutron-server acepta las solicitudes vía API y las direcciona al complemente adecuado a través de la cola de solicitudes Neutron plug-in y neutron-agents se encargan de crear conexiones de red, asignación de subredes y direcciones IP a las máquinas virtuales El envío de mensajes se realiza mediante la cola Image Service (Glance) Es uno de los ejes centrales en la infraestructura de las IaaS, acepta solicitudes de la API de disco o del servidor de imágenes, incluye el almacenamiento de objetos de OpenStack, hace el uso de una instancia durante el aprovisionamiento Un número de procesos son ejecutados sobre el servicio de imágenes para soportar el almacenamiento en caché, los servicios de replicación que garantizan la coherencia y la disponibilidad a través del clúster El servicio Image incluye los siguientes componentes: Glance-api Acepta las llamadas de la API para el descubrimiento, almacenamiento y recuperación de las imágenes Glance-registry Almacena, procesa y recupera los metadatos de las imágenes, estos incluyen elementos como el tamaño y el tipo; este registro es un servicio privado interno de Glance Database Almacena las imágenes de los metadatos, la mayoría de las implementaciones están basadas en MySQL o SQLite Según Pepple (2011), esta base de datos solo posee dos tablas (imagen y propiedades de imagen), en la primera representa la imagen en el almacenamiento de datos (formato del disco, formato del contenedor, 33

34 tamaño, entre otros), mientras que la segunda tabla contiene los metadatos de la imagen personalizada Storage repository for image files Utiliza un repositorio o almacén de imágenes, este usualmente es el servicio Object Storage (Swift), pero Glance soporta sistemas de ficheros normales, Amazon S3, RADOS, entre otros Características de Image Service (Glance) Almacenamiento de imágenes públicas y privadas que el usuario puede usar para levantar una instancia Los usuarios pueden listar las imágenes disponibles a través del API de conexión Pone a disposición las imágenes al servicio Compute (Nova) para que se ejecute la instancia solicitada por el usuario Genera imágenes de las instancias en ejecución a modo de respaldo en caso de fallos Figura 9 Componentes y procesos de Image Service Fuente extraída de Pepple (2011) Fecha de consulta 18/05/206 Descripción de los procesos de Image Service (Glance) Glance-api Acepta las llamadas relacionados a la búsqueda, almacenamiento y recuperación de imágenes Glance-registry Rescata, procesa y almacena la información de las imágenes relacionadas con el tamaño, tipo, entre otros Glance database Aloja la información suministrada por glance-registry, glance-api 34

35 Image store Almacena las imágenes que estarán disponibles a los usuarios Telemetry (Ceilometer) Monitorea y realiza la medición de los servicios de OpenStack para su facturación, la evalúa y realiza una comparativa y muestra la escalabilidad para realizar estadísticas El módulo Telemetry realiza las siguientes funciones Centraliza eficientemente los datos relacionados con los servicios de OpenStack Recoge la medida de los datos y los eventos mediante el control de las notificaciones enviadas desde los servicios Publica los datos recogidos sobre varios puntos incluyendo los almacenes de datos y las colas de mensajes Crea alarmas cuando los datos recolectados se rompen definiendo reglas Los componentes que hacen parte del módulo en mención son Ceilometer-agent-compute Entra en ejecución con en el servicio Compute, realiza las estadísticas de utilización de los recursos Ceilometer-agent-central Es ejecutado en servidor de administración central, realiza las estadísticas de los recursos que no están vinculados con el servicio Compute Ceilometer-agent-notification Funciona en un servidor de gestión central, consume los mensajes de cola para construir los datos de eventos y de medición Ceilometer-collector Corre en los servidores de administración central, envía los datos de medición a un almacén de datos o a un consumidor externo sin modificación Ceilometer-alarm-evaluator Se ejecuta en un servidor central para determinar el cruce del umbral Ceilometer-alarm-notifier Permite que se establezcan alarmas en función de la evaluación de los umbrales para una colección de muestras Ceilometer-api Proporciona acceso a los datos del almacén de los mismos, se ejecuta en servidores de administración central Los anteriores componentes se comunican mediante la mensajería de bus, solo el colector y el servidor API tienen acceso al almacén de datos Identity Service (Keystone) Proporciona autenticación y autorización para los demás servicios, usuarios, tenants; ofrece un catálogo de criterios y servicios disponibles El servicio Keystone realiza las siguientes funciones: 35

36 Seguimiento de los usuarios y sus permisos Proporcionar un catálogo de servicios disponibles con sus API end-points Los siguientes conceptos se relacionan con el Identity Service y son fundamentales para entender el funcionamiento de Keystone User Representación digital de una persona, sistema o servicio que usa la nube, Keystone valida las peticiones hechas por medio de la confirmación, Los usuarios tienen un inicio de sesión y se les pueden asignar tokens para acceder a los recursos Credenciales Son datos que conforman la identidad de los usuarios, por ejemplo: nombre de usuario y contraseña, nombre de usuario y una clave de API, o un token de autenticación proporcionado por el servicio Keystone Autenticación Es el proceso de confirmación de identidad de un usuario, el servicio Keystone confirma una solicitud entrante mediante la validación de un conjunto de credenciales suministradas por el usuario Token Es una cadena alfanumérica de texto utilizada para acceder a la API y los recursos de OpenStack, un token puede ser revocado en cualquier momento y tiene una duración finita Tenant Usuario o grupo de ellos que comparten el acceso a una instancia, un tenant puede ser un cliente, proyecto, cuenta, organización o subscriptor Endpoint Es una dirección de red, a la cual se accede a un servicio, usualmente es un dirección URL Rol Son los privilegios que un usuario posee sobre frente a un tenant que le es asignado, se pueden definir varios roles a un usuario pero no es común Keystone client Es una línea de comandos para la API de Keystone, por ejemplo un usuario puede ejecutar los comandos Keystone Servicecreate y el Keystone Endpoint-create para registrar servicios en sus instalaciones de OpenStack Figura 10 Diagrama de flujo de Identity Service 36

37 Fuente docsopenstackorg Fecha de consulta 18/05/2016 Disponible en Orchestration (Heat) Es un motor que ofrece la posibilidad de lanzar múltiples aplicaciones en la nube, basados en plantillas en forma de texto que pueden ser entendidos como un código; un formato nativo llamado Heat Orchestration Template (HOT) está escrita en YAML ( * ), esta es una notación concisa que sigue una convención estructural (dos puntos, retornos, identación), que son similares a Python o Ruby, pero también proporciona compatibilidad con la plantilla de AWS CloudFormation de Amazon que están en formato JSON ( ** ), por lo que muchas de están pueden ser lanzadas en OpenStack Permite el escalado automático de stacks basados en métricas configurables que recoge de la API de Ceilometer Database Service (Trove) Proporciona la funcionalidad de aprovisionamiento de nube escalable y fiable para los motores de bases de datos relacionales y no relacionales, los usuarios pueden usar rápida y fácilmente las características administrativas de la base de datos, los usuarios de la nube y los gestores de la * YAML formato de serialización de datos legible por humanos inspirado en lenguajes como XML, C, Python, Perl ** JSON acrónimo de JavaScript Object Notation, es un formato de texto ligero para el intercambio de datos 37

38 misma pueden provisionar y administrar múltiples instancias de la base de datos como sea necesario El Database Service proporciona el aislamiento de recursos a nivel de alto rendimiento, y automatiza las tareas administrativas complejas, como la implementación, configuración, parches, copias de seguridad, restauraciones, y el seguimiento Se pueden modificar diversas características del clúster mediante la edición del archivo /etc/trove/troveconf Figura 11Arquitectura conceptual de Openstack versión Juno Fuente docsopenstackorg Fecha de consulta 18/05/2016 Disponible en 38

39 Seguidamente se mencionan servicios adicionales que han sido implementados en lanzamientos posteriores a la que se está trabajando en el presente documento Sahara (Elastic Map Reduce) Tiene como objetivo proporcionar a los usuarios bajo demanda medios sencillos en la provisión de clúster tipo Hadoop especificando varios parámetros como la versión, topología de clúster, detalles del hardware de los nodos entre otros Ironic (Bare-Metal Proviosioning) Provee servidores físicos bajo demanda en lugar de máquinas virtuales Zaqar (Messaging Service) Es un servicio de mensajería en la nube para múltiples usuarios y desarrolladores de aplicaciones móviles Manila (Shared Filesystems) Tiene como objetivo principal proveer un sistema de ficheros compartidos bajo demanda Designate (DNS Service) Provee servicios DNS a OpenStack Barbican (Key Management) Es una API REST diseñada para brindar almacenamiento seguro y gestión de contraseñas, claves cifradas y certificados X509 ( * ) Magnum (Containers) Es un servicio API desarrollado para fabricar motores contenedores para la orquestación tales como Docker ( ** ) y Kubernetes ( *** ) disponibles como recursos de primera clase en OpenStack Murano (Application Catalog) Presenta un catálogo de aplicaciones de OpenStack, permitiendo a los desarrolladores y administradores de la nube publicarlas en un catálogo categorizado y navegable Congress (Governance) Proporciona políticas como un servicio a través de cualquier colección de ellos, con fin de ofrecer gobernabilidad y cumplimiento de las infraestructuras dinámicas 43 TECNOLOGÍAS Y VARIANTES EN LOS COMPONENTES BASE DE OPENSTACK Dentro del marco de los componentes base de OpenStack se utilizan diferentes variantes y tecnologías para el desarrollo de cada función a lo que refiere su componente 431 Almacenamiento en el componente Storage Este componente maneja varios tipos de almacenamiento los cuales son fundamentales para el alojamiento de toda la información * Certificados X509 formatos estándar para certificados de claves públicas y un algoritmo de validación de la ruta de certificación ** Docker Una plataforma abierta para aplicaciones distribuidas para los desarrolladores y administradores de sistemas *** Kubernetes es un sistema de código abierto para la automatización de la implementación, operaciones, y la escala de las aplicaciones en contenedores 39

40 Almacenamiento efímero En este los datos de los usuarios se pierden cuando la instancia termina Almacenamiento persistente Este tipo de almacenamiento posibilita que los datos del usuario sean guardados al momento de terminar una instancia, este tipo soporta variaciones del mismo Almacenamiento de objetos Almacenamiento en bloque Almacenamiento de sistema de archivos 432 Interconexión en el componente Networking En este componente se utilizan varias tecnologías, varias de ellas usadas en el plugin L2 para realizar la interconexión entre los diferentes actores internos y externos Túneles GRE (Generic Routing Encapsulation) Protocolo para el establecimiento de túneles entre dos nodos no conectados directamente Originalmente desarrollado por Cisco, permite transportar paquetes de una red a través de otra red Túneles XVLAN (Virtual Extensible LAN) Protocolo que establece túneles o redes superpuestas (overlay networks), desarrollado en entornos virtualizados de sistemas Cloud Encapsula paquetes Ethernet L2 dentro de paquetes UDP L4 a través de una técnica de etiquetado similar al VLAN, es empleada para crear una red plana L2 en máquinas virtuales alojadas en diferentes hosts y redes Open Vswitch (OVS) Según Pfaff y Davie (2013), es un programa de código abierto diseñado para ser utilizado como un switch virtual en entornos de servidores virtualizados El switch virtual reenvía el tráfico entre diferentes máquinas virtuales (VM) sobre mismo host físico y también reenvía el tráfico entre máquinas virtuales y la red física Open vswitch está abierto a la programación y el control usando OpenFlow y la OVSDB (Open Database vswitch) 433 Hypervisores en el componente Compute Es una plataforma que permite la creación de máquinas virtuales, las cuales actúan como si fueran reales con diferentes sistemas operativos OpenStack soporta varios Hypervisores KVM QEMU Xen, XAPI, XenServer LXC (Linux containers) VMware vsphere Hyper-V virtualization platform 40

41 Baremetal driver 44 REDES DEFINIDAS POR SOFTWARE (SDN) Las redes definidas por software es uno de los nuevos paradigmas en el mundo de las redes, donde son separados el plano de control (software) del plano de datos (hardware), según la Open Networking Foundation (2016), lo describe como un nuevo enfoque en la creación de redes, donde el control y el envío de datos son desacoplados proporcionando programación directa, cuyo resultado es una arquitectura extremadamente dinámica, rentable, adaptable, y manejable que proporciona a los administradores una programación sin precedentes, les brinda autonomía y control sobre la red La implementación de las SDN a través de un estándar abierto permite agilidad, mientras reduce el desarrollo de servicios y costos operativos Seguidamente se ilustra la idea del concepto SDN Figura 12 Concepto SDN Fuente blogssalleurledu Fecha de consulta 21/05/2016 Disponible en Arquitectura SDN Como se dijo anteriormente, la arquitectura SDN es dinámica, manejable, rentable, adaptable, ideal para el manejo de gran ancho de banda, dentro de esta arquitectura el protocolo OpenFlow es un elemento fundamental para la construcción de soluciones SDN, podemos decir entonces que la arquitectura SDN es: Directamente programable El control de la red está directamente desacoplada de las funciones de envío 41

42 Ágil con la abstracción administrativa del control de envío se ajusta dinámicamente el flujo de tráfico de toda la red para satisfacer las cambiantes necesidades De gestión centralizada La inteligencia de la red es lógicamente centralizada basada en los controladores SDN, que mantienen una visión global de la red, aparecen las aplicaciones y los motores de políticas en un solo Switch lógico De configuración programada Permite a los administradores de red configurar, administrar, proteger y optimizar los recursos de red rápidamente, a través de programas SDN dinámicos, automatizados, los cuales pueden agregar sus propios recursos, ya que los programas no dependen de un propietario Basada en estándares abiertos y proveedor neutral Cuando las SDN son implementadas bajo estos estándares se simplifica el diseño de la red, ya que las instrucciones son proporcionadas por los controladores en lugar de múltiples dispositivos, proveedores específicos y protocolos La arquitectura de las Redes Definidas por Software está compuesta por las capas de infraestructura, la capa de control y la capa de aplicaciones cada una de ellas interconectadas por protocolos y APIs, permitiendo la programación y el control de la red en forma centralizada maximizando su administración Capa de infraestructura Se encuentran todos los dispositivos de red (switches OpenFlow), estos gestionan los datos y los procesan de acuerdo a las reglas que se establecen en las tablas de flujo, en esta se manipula directamente el tráfico, se implementan los medios para la virtualización Se comunica con la capa de control por medio de las llamadas SouthBound APIs donde su protocolo principal es OpenFlow Capa de control En esta se ubica el controlador SDN que permite la administración de la red de forma centralizada, este tiene una visión global de la red física, dentro de los controladores SDN más conocidos se encuentran OpenDaylight, NOX, POX, RYU, HP VAN SDN Controller, Beacon, Floodligth, entre otros Capa de aplicación Permiten especificar recursos y comportamientos de la red, en esta capa la arquitectura SDN se comunica mediante la NorthBound APIs, normalmente APIs REST El controlador OpenDaylight mediante Neutron API REST se comunica con ML2 Plug-in de OpenStack Figura 13 Arquitectura SDN 42

43 Fuente Fecha de consulta 21/05/2016 Disponible en La innovación de las Redes Definidas por Software se encuentra la capacidad de gestión sobre los siguientes aspectos: Administración de fallos Gestión e la configuración Administración contable Administración de rendimiento Gestión de la seguridad Todas las anteriores pueden ser llevadas a diferentes campos como son la virtualización de las redes (FlowVisor), prototipos de hardware (OpenPipes), Balanceo de carga (PlugNServe), ahorro de energía (ElasticTree), movilidad (MobileVMs), Ingeniería de tráfico (Aggregation), video inalámbrico (OpenRoads), entre otros 442 Modelos SDN Dentro de los modelos SDN podemos encontrar las siguientes: Modelo centralizado En este modelo se encuentra un gestor o administrador, este maneja el canje de la información del plano de datos a través de las definiciones de rutas y flujos, el enfoque centralizado simplifica su administración de flujos complejos que están relacionados con aplicaciones específicas, permiten que las colas de prioridad se ajusten alrededor de un solo tipo de información; posee como desventaja su escalabilidad en el momento que se presenta un crecimiento exponencial de la red, especialmente en entornos basados en la web o en la nube donde el control requiere sistemas y recursos potentes, mayor capacidad de almacenamiento 43

44 Figura 14 Modelo SDN centralizado Administración central Controlador SDN Elemento de red Elemento de red Elemento de red Fuente Propia Modelo distribuido En este modelo cada elemento de red posee un pequeño controlador llamado agente que cumple una serie de tareas bajando la carga centralizada, en dicho modelo el procesamiento y el manejo de solicitudes se realizan de forma rápida puesto que se evita que esta sea desde el controlador central; esta técnica también es usada en las redes inalámbricas, donde el Access point responde a los paquetes que requieran de una respuesta de forma ágil y los que necesitan mayor procesamiento como los de autenticación son enviados al control central de la WLAN para su respectiva gestión Este modelo posee como desventaja la baja flexibilidad, ya que las características y funcionalidades del agente varían dependiendo del fabricante Figura 15 Modelo SDN distribuido 44

45 Administración central Controlador SDN Agente de red Agente de red Agente de red Elemento de red Elemento de red Elemento de red Fuente Propia Modelo híbrido En este modelo se presenta un gestor centralizado con varios controladores, cada uno de ellos gestiona varios elementos de la red aprovechando el control sobre los flujos de datos heredado del modelo centralizado y la flexibilidad del modelo distribuido Figura 16 Modelo SDN híbrido Administración central Controlador SDN Controlador SDN Controlador SDN Elementode red Elementode red Elementode red Elemento de red Elemento de red Elementode red Fuente Propia El presente proyecto es gestionado por un modelo centralizado 45

46 443 Protocolo OpenFlow Es el principal protocolo en las Redes Definidas por Software, tiene como función ser la interfaz entre la capa de infraestructura y la capa de control, permite controlar las tablas de flujo de los switches en forma dinámica para poder implementar servicios como Firewalls, NAT ( * ), QoS ( ** ), entre otros, según la ONF (2016), es la primera interfaz de comunicaciones estándar definido entre los dispositivos de red y el controlador de la arquitectura SDN, permitiendo el acceso directo a la manipulación del plano de enrutamiento (capa de infraestructura) en los conmutadores físicos y virtuales basados en un hypervisor OpenFlow permite definir cómo debe fluir el tráfico a través de los dispositivos de red basados en distintos parámetros como patrones de uso, aplicaciones y recursos en la nube, proporciona un control específico que permite que la red responda a los cambios en tiempo real a nivel de aplicación El protocolo consiste en un conjunto de mensajes los cuales son enviados desde el controlador al conmutador y viceversa, estos mensajes permiten que el controlador programe el conmutador y así tener control sobre la conmutación del tráfico, los mensajes del protocolo OpenFlow se dividen en: mensajes del controlador al Switch, mensajes asíncronos y mensajes asimétricos El protocolo OpenFlow es un factor clave para las redes definidas por software, en la actualidad es el único protocolo estandarizado en las SDN que permite directa manipulación del plano de reenvío en dispositivos de red; aunque en un principio aplicada a las redes basadas en Ethernet, la conmutación de OpenFlow se puede extender a un conjunto muchos más amplio de casos de uso Los beneficios que se pueden adquirir a través de una arquitectura SDN basada en el protocolo OpenFlow son: Control central en entornos de múltiples proveedores El software de control SDN puede gestionar cualquier dispositivo de red OpenFlow habilitado en cualquier proveedor, incluye conmutadores, enrutadores y conmutadores virtuales Reducción de la complejidad mediante la automatización Las SDN basadas en OpenFlow ofrecen una red flexible, autónoma y gestionable, lo cual hace posible el desarrollo de herramientas que agilizan las tareas Alta tasa innovadora La adopción de la tecnología SDN y el protocolo OpenFlow acelera la innovación, permite programar la red en tiempo real y satisfacer las necesidades específicas de un negocio * NAT (Network Address Translation) es un mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que asignan mutuamente direcciones incompatibles ** QoS Quality of Service (Calidad de servicio) se puede definir como el conjunto de tecnologías que garantiza la transmisión de cierta cantidad de información en un tiempo determinado a uno o varios dispositivos 46

47 Aumento de la fiabilidad de la red y la seguridad SDN hace posible definir políticas de configuración y declaraciones de alto nivel, que luego se traduce a la infraestructura a través de OpenFlow Mayor control granular de la red El modelo de control basado en el flujo de OpenFlow permite a las TI aplicar políticas a un nivel muy detallado, incluyendo la sesión, el usuario, el dispositivo y niveles de aplicación, de una manera muy abstracta y automatizada Mejor experiencia de usuario Por el control de la red centralizada y que la información de la misma esté disponible en aplicaciones de más alto nivel, la infraestructura SDN puede adaptarse mejor a las necesidades dinámicas del usuario 45 CONTROLADORES SDN Es la figura primordial de la arquitectura SDN, se encarga de tomar las decisiones, de la implementación de reglas, la ejecución de instrucciones que provienen de las diferentes aplicaciones y son distribuidas a los dispositivos de red, determina la gestión de los paquetes que no encajan en las entradas de flujo añadiéndolas o eliminándolas a través de un canal seguro a los dispositivos Los controladores para poder gestionar la red deben tener una visión global de la misma Un controlador SDN puede ser descrito como un sistema o una colección del mismo y debe ofrecer: Gestión del estado de la red Implica tener una base de datos que sirva como repositorio de la información de los elementos de red gestionados, incluye el estado de la red, información de la configuración temporal e información de la topología de la red Modelo de datos de alto nivel Captura las relaciones entre los recursos gestionados, políticas y demás servicios prestados por el controlador Mecanismo de descubrimiento Debe tener la capacidad de descubrir los dispositivos, topologías, servicios, cálculo de rutas, servicios de información centrados en la red o en los recursos Sesión de control Asegurar el control sobre el protocolo TCP entre el controlador y sus agentes en los elementos de red Protocolo basado en estándares (OpenFlow) Obtiene el estado de la red impulsado por las aplicaciones de los elementos de red APIs Que a menudo son de tipo RESTful, exponen los servicios del controlador a las aplicaciones de gestión facilitando la interacción entre los mismos Entorno de desarrollo robusto Permiten la expansión de las capacidades básicas del núcleo y la publicación de las APIs para nuevos módulos 47

48 Dentro del mercado existe gran variedad de controladores en la siguiente tabla se muestran los más conocidos y sus características principales Tabla 2 Controladores SDN OpenDaylight RYU NOX POX Beacon Floodlight Soporta OpenStack SI SI NO NO NO SI Soporte OpenFlow 10, 13 10, 12, Lenguaje Java Python C++ Python Java Java Interfaz web SI SI NO SI SI SI OpenSource SI SI SI SI SI SI Sistema Operativo Fuente Propia Linux, Mac, Windows CONTROLADOR Linux Linux Linux, Mac, Windows Linux, Mac, Windows, Android Linux, Mac, Windows Dentro de los elementos para seleccionar un controlador se deben tener en cuenta las siguientes características: Soporte sobre el protocolo OpenFlow Virtualización de red Funcionalidad de la red Escalabilidad Rendimiento Programación de red Confiabilidad Seguridad de la red Monitorización centralizada y visualización Fabricante del controlador Soporte de plataformas Procesamiento 46 OPENDAYLIGHT CONTROLLER (ODL) Se escoge este controlador para la integración con OpenStack basado en los criterios y características mencionadas en el apartado anterior, además el controlador ODL es de forma modular y de tipo Open Source, adaptable a redes de cualquier tamaño y escala ODL permite servicios de red a través de un espectro de hardware en entornos de múltiples proveedores, su arquitectura de microservicios permite a sus usuarios controlar aplicaciones, protocolos, plug-ins; debido a que OpenDaylight no es solo una plataforma 48

49 para las SDN, esta se puede configurar en diversas formas para resolver los retos que ofrecen las redes, ODL integra el código, los estándares, las APIs para ofrecer una mejor gestión sobre las redes convirtiéndolas en más programables, inteligentes y adaptables OpenDaylight ha obtenido el soporte de la "Linux Fundation", y de otras empresas como: HP, Red Hat, Cisco entre otras; a medida que escala en el desarrollo su campo de actuación se propaga, en su hoja de ruta se encuentra dar soporte a múltiples tecnologías novedosas relacionadas con SDN como NFV, VTN y SFC Dentro de las principales propiedades de OpenDaylight podemos encontrar las siguientes Arquitectura de microservicios Soporte multiprotocolo Seguridad, escalabilidad, estabilidad y desempeño (S3P) La plataforma ODL soporta el protocolo OpenFlow y extensiones del mismo como las TTP ( * ), protocolos tradicionales como NETCONF, BGP/PCEP ( ** ) y CAPWAP ( *** ), además ofrece interfaces con OpenStack y OpenvSwitch a través del proyecto de integración OVSDB La siguiente tabla muestra la lista de servicios, APPs y protocolos soportados en ODL Tabla 3 Servicios, APPs y protocolos de ODL * TTP es un modelo de Switch abstracto que describe el comportamiento de envío, un controlador OpenFlow puede programarlo a través del protocolo OpenFlow-Switch ** BGP/PCEP protocolo mediante el cual se intercambia información de encaminamiento o ruteo entre sistemas autónomos y que calculan la ruta de red basada en un gráfico de la misma y aplican restricciones computacionales *** CAPWAP es un protocolo que permite a un controlador de acceso (AC) gestionar una colección de puntos de terminación inalámbricas CAPWAP se define en el RFC 5415 de la IETF 49

50 Fuente wwwopendaylightorg Fecha de consulta 23/05/2016 Disponible en La arquitectura de ODL por su estructura modular ofrece un conjunto de servicios que permiten una variedad de aplicaciones y casos de uso, La interfaz de bajo nivel (SouthBound API) soporta múltiples protocolos (plug-ins de Opendaylight) como OpenFlow 10, OpenFlow 13, NETCONF, OVSDB, etc Los plug-ins se conectan dinámicamente a la SAL (Service Abstraction Layer) que funciona como una capa de abstracción para los módulos de redes superiores Es decir, la SAL permite que OpenDaylight ejecute la tarea solicitada independientemente del protocolo usado para conectarse con los equipos físicos La siguiente figura ilustra la arquitectura de OpenDaylight relase Lithium Figura 17 Arquitectura OpenDaylight Lithium 50

51 Fuente wwwopendaylightorg Fecha de consulta 23/05/206 Disponible en 47 OPENSTACK Y OPENDAYLIGHT La relase Lithium de OpenDaylight tuvo la orientación de mejorar la compatibilidad con OpenStack, donde ODL sirve de Backend para el componente Neutron y así provisionar de servicios de red a OpenStack Desde OpenStack, Neutron utiliza el ML2 plug-in ODL mechanism driver y traspasa todas las llamadas a la Neutron API de OpenDaylight El controlador SDN contiene una API REST que escucha al Neutron API service que recepciona las llamadas de Neutron y las ofrece al resto de servicios SDN OpenDaylight muestra el servicio Neutron API hacia OpenStack para su integración La siguiente figura ilustra la arquitectura de Neutron API en OpenDaylight; en ella existen principalmente tres paquetes diferentes que constituyen el servicio Neutron API, uno denominado Neutron Northbound API, otro llamado Neutron Southbound providers Interface (SPI) y una colección de implementaciones de OpenDaylight 51

52 Figura 18 Arquitectura de implementación de la Neutron API Fuente Fecha de consulta 23/05/2016 Disponible en Para el presente proyecto la implementación elegida es OVSDB, el cual utiliza el protocolo de Southbound OVSDB para configurar los switches OpenvSwitch en los nodos de red y cómputo, mientras que OpenFlow gestiona las tablas de flujo; en la siguiente figura se ilustra este concepto 52

53 Figura 19 Implementación de OVSDB Fuente Fecha de consulta 24/05/2016 Disponible en 5net/~dmm/talks/openstack_and_odl_atlantapdf 48 ANTECEDENTES En el marco internacional se han encontrado varios trabajos relacionados con el tema expuesto en el presente documento Un primer trabajo corresponde a Herrera (2015), quien realizó Estudio de una solución OpenStack integrada con SDN En este documento se expone el estudio de una tecnología Cloud y su integración con el paradigma SDN el cual fue dividido en dos fases, en la primera se realizó el estudio y despliegue de OpenStack, para este se utilizó una máquina virtual y como tecnología de virtualización LXC y KVM, en la segunda fase se estudió las SDN y la integración de ODL, eligió como controlador OpenDaylight, donde finalmente explica las decisiones de diseño, los pasos y errores encontrados Un segundo trabajo corresponde a Jarrín (2015), titulado Implementación de un prototipo para la generación automática de infraestructura de red SDN a través de una nube (IaaS), donde se realiza la conceptualización de la computación en la nube, se implementa un ambiente virtualizado multi nodo por las características presentadas, posteriormente se documentan las configuraciones necesarias y los 53

54 requerimientos de dicho ambiente, se comprueba el funcionamiento y el levantamiento de una instancia, la creación de la infraestructura SDN que fue separa en dos fases, la primera presenta la creación del frontend y en la segunda el backend, finalmente se presentan las conclusiones obtenidas Un tercer documento que corresponde a Avilés y Chávez (2015), llamado Diseño y simulación de una red de datacenters basada en topología Fat-Tree en un ambiente de redes definidas por software, este trabajo se basó en el diseño de una red de datacenter basada en la topología Fat-Tree sobre un ambiente SDN, en este se genera un escenario fiable y de comportamiento cercano a la realidad, el cual contribuiría al estudio de las problemáticas presentadas en los datacenter, que será utilizado por investigadores y/o estudiantes que no cuenten con la facilidad de acceso a un datacenter real; como herramientas se usó Mininet para la creación de la topología de red, OpenDaylight como controlador SDN y para la generación del tráfico estadístico DITG Un cuarto documento correspondiente a Tkachova y Salim (2015), titulado An analysis of SDN-OpenStack integration, donde se expone la arquitectura del componente Networking de OpenStack, el servicio Neutron y el plug-in para la comunicación con los diferentes controladores SDN, se creó un modelo experimental de SDN-OpenStack, el documento se mostró como solución al retraso, la cantidad máxima de paquetes UDP y TCP y los flujos obtenidos en el experimento Un quinto documento que corresponde a Singh y Manickam (2015) llamado Design and deployment of OpenStack-SDN based test-bed for EDoS, en este se destaca el controlador OpenDaylight, el cual es integrado a OpenStack para proporcionar una poderosa solución de red basada en SDN a las IaaS, dicha integración brinda aplicación práctica de los futuros estándares de red que aprovechan la tecnología de las Redes Definidas por Software En el documento se discute sobre los elementos importantes del diseño y la implementación de un banco de pruebas OpenStack-SDN para redes virtuales que integran capacidades adicionales en comparación con los bancos de prueba SDN existentes, también se ofrece una visión general de la configuración de dicho banco de pruebas con el hardware y componentes necesarios para su construcción Un sexto trabajo cuyos autores son Ting y Yuan (2015), titulado Using SDN Technology to Mitigate Congestion in the OpenStack Data Center Network, donde se implementa la tecnología SDN sobre la plataforma OpenStack sin el nodo de red y utilizando el hipervisor XenServer, este trabajo expone que al no tener dicho nodo se liberan los recursos consumidos, por lo tanto la escalabilidad de la red libera una gran cantidad de recursos utilizando este enfoque, por otro lado proponen un módulo para la gestión del tráfico de la red y el QoS El alto tráfico de las máquinas virtuales están limitados o son migrados a otros servidores que no se encuentran 54

55 ocupados, la limitación del ancho de bando de las VMs es propuesto en este documento y la migración de las mismas se presentarán en trabajos futuros En el contexto colombiano y regional se encontraron los siguientes trabajos y documentos: A nivel nacional un primer documento de Castrillón (2016), llamado Modelamiento Formal de una Arquitectura Básica SDN basada en CPN Jerárquicas, en el documento se expone un modelo básico de red SDN para el análisis de los diferentes estados del procesamiento de un flujo de datos, su arquitectura, modelo del controlador y del Switch OpenFlow, protocolo OpenFlow, entre otros A nivel regional un primer documento del autor Blandón (2013), titulado OpenFlow El protocolo de futuro, describe que con la aparición de las SDN se abren nuevos proyectos que busquen la optimización y el control del tráfico sobre las redes de comunicaciones, donde OpenFlow es puesto como uno de los proyectos que brindarían dicha solución, referencia a NOX como controlador SDN, brinda una revisión a la tecnología de hardware libre FPGA y el proyecto NetFPGA que plantea la posibilidad de integrar el protocolo OpenFlow sobre tarjetas configurables En el contexto regional un segundo documento del autor Ruíz (2014), llamado Estado del arte Redes Definidas por Software, expone el concepto del paradigma de las SDN, muestra una perspectiva histórica de las redes programables desde sus inicios, presenta la arquitectura SDN y se menciona el protocolo OpenFlow, realiza una discusión sobre las alternativas actuales para la implementación de las Redes Definidas por Software las cuales son basadas en protocolos y servicios, por ultimo realiza algunas líneas de investigación prometedoras frente a las SDN A nivel regional un tercer trabajo de los autores Montoya y Avendaño (2016), llamado emulación del proceso de conmutación/apilamiento de etiquetas en redes MPLS, mediante una herramienta de simulación para redes definidas por software, dan a conocer el procedimiento de emulación del protocolo MPLS en una SDN mediante la herramienta Mininet, donde se describe el funcionamiento de cada una de las tecnologías presentes y las herramientas para la creación de dicha emulación; en dicho trabajo se usó el protocolo OpenFlow 13 y el controlador Floodligth, indicando la forma de cómo se configura el etiquetamiento en MPLS y la forma de cómo se activa el controlador y los diferentes protocolos; por ultimo suministran información en teoría y en resultados para investigaciones futuras En el contexto regional un cuarto trabajo del autor Martínez (2015), llamado Estudio del funcionamiento de la herramienta Mininet, en el cual menciona el propósito principal de Mininet como herramienta para relacionar las SDN, ya sea en un entorno grafico o de líneas de comando, introduce al lector a la arquitectura de las 55

56 SDN y al protocolo OpenFlow, se explora de forma general el funcionamiento de la herramienta Mininet El presente documento se diferencia a los otros existentes en la forma que se abordó la aplicación de las SDN; en este se presenta la integración con el cloud computing para dar una posible solución en la implementación, flexibilización, escalamiento, automatización y despliegue de redes sobre virtuales en la plataforma de OpenStack release juno 56

57 5 METODOLOGÍA 51 TIPO DE TRABAJO Según la naturaleza de los objetivos, este proyecto fue tratado de forma explicativa, el cual mostró cómo se implementaba un ambiente básico de la plataforma OpenStack sobre virtualbox y luego se integró con el controlador OpenDaylight, primero se crearon y configuraron varias interfaces de red que fueron la base en la comunicación de las máquinas virtuales, luego se instalaron y se configuraron las diferentes bases de datos, servidores de colas, servicios, subservicios y agentes en los nodos correspondientes, posteriormente se realizó el envío de pings, levantamiento, inicio, reinicio de servicios, subservicios, agentes, creación de redes, subredes, routers, puertos, interfaces y el lanzamiento de instancias para asegurar su interconectividad y funcionamiento, se procedió con la instalación y configuración de la interfaz web para brindar una mejor gestión de la plataforma OpenStack, luego se instaló el controlador OpenDaylight y las features necesarias para la integración con OpenStack, seguidamente se borraron las redes, subredes, routers, puertos, interfaces e instancias creadas anteriormente para evitar conflictos entre OpenStack y el controlador ODL, seguidamente se detuvo el agente del servicio neutron pluginopenvswitch y se inhabilitó en los nodos compute y network, ya que OpenDaylight gestionaría los switchs virtuales; posteriormente se eliminó la base de datos de OpenvSwitch para luego crear un puente entre los nuevos switchs virtuales donde se les asignó como gestor a ODL; por último se crearon nuevas redes, subredes, routers, puertos y switches para ver que la integración tuvo éxito 52 PROCEDIMIENTO 521 Creación del ambiente mínimo y virtualizado para el desarrollo del proyecto El siguiente procedimiento tiene como objetivo crear un ambiente mínimo de OpenStack en el cual se desea desarrollar el presente proyecto Dentro de este procedimiento se debe agregar y configurar las diferentes interfaces de red que serán indispensables en la intercomunicación de los diferentes nodos; la instalación de servicios de soporte del protocolo NTP que permitirá la sincronía de los relojes de los sistemas a través del enrutamiento de paquetes; la instalación del repositorio de OpenStack, un gestor de bases de datos donde se alojaran los servicios creados, y la instalación y configuración del servidor de colas que manejará el paso de información entre los nodos Configuración de las interfaces de red en Virtual Box Para este proceso debemos configurar tres interfaces de red en el apartado redes solo anfitrión 57

58 El adaptador de red #1 queda configurado de la siguiente forma El adaptador de red #2 posee la siguiente configuración El adaptador #3 tiene la siguiente configuración En esta fase se instalarán los nodos mínimamente necesarios para el despliegue de OpenStack, donde se crean tres máquinas virtuales con sistema operativo Linux Ubuntu 1404 LTS corriendo en Virtual Box, en dichas máquinas se despliegan el nodo controlador, el nodo de red y el nodo de computo, los nodos mencionados estarán interconectados bajo la herramienta OpenvSwitch; esta tarea se elabora sobre un computador portátil Core i5 y 4 Gb de RAM Configuración del nodo controlador En el nodo controlador se definen los nombres de los host, dos interfaces de red una será usada para gestionar la red, y la segunda para para la red externa 58

59 1 En el nodo controlador se deben configurar los adaptadores de red quedando de la siguiente manera 2 En la terminal se configura el nombre del host de la siguiente manera Seguidamente nombramos nuestro host con el nombre controller 3 Se agrega el direccionamiento IP y el nombre de cada nodo al archivo hosts 4 Configuración de las interfaces de red 59

60 Configuración del nodo de red Este nodo posee tres interfaces de red, una es usada para la administración, otra para la conexión entre las máquinas virtuales y la última es utilizada para la conexión externa 1 En este nodo se deben configurar los adaptadores de red los cuales quedan de la siguiente manera 2 Se añade el hostname al nodo de red Se nombra este nodo como network 60

61 3 Se agrega el direccionamiento IP y el nombre de cada nodo al archivo hosts 4 Configuración de las interfaces de red Configuración del nodo computo 1 Se configuran los adaptadores de red en este nodo quedando de la siguiente manera: 61

62 2 Se agrega el nombre al host de la siguiente forma: Se agrega el nombre compute al host 3 Se añade el direccionamiento IP y el nombre de cada nodo al archivo hosts 4 Se configuran las interfaces de red en el nodo cómputo 62

63 Verificación de la conectividad Para este paso se recomienda reiniciar todos los nodos para que todos los cambios realizados surjan efecto Instalación de servicios de soporte NTP en el nodo controller 1 Con el siguiente comando instalamos el servicio NTP apt-get install y ntp 63

64 2 Seguidamente editamos el archivo ntpconf quedando de la siguiente forma Se reinicia el servicio de esta forma Verificación de la sincronización de dicho servicio de la siguiente manera Habilitación del repositorio de OpenStack 1 Mediante los siguientes comandos instalamos y habilitamos dicho repositorio apt-get install ubuntu-cloud-keyring echo "deb \ "trusty-updates/juno main" > /etc/apt/sourceslistd/cloudarchive-junolist 64

65 2 Actualizamos los paquetes del sistema apt-get update && apt-get dist-upgrade Instalación del gestor de Bases de Datos 1 Con el siguiente comando se instala el gestor de Bases de Datos, para nuestro caso instalamos mariadb como gestor apt-get install mariadb-server python-mysqldb 2 Después de instalado nuestro gestor procedemos a modificar el siguiente archivo y modificando las líneas que se muestran a continuación quedando de la siguiente forma: 3 Se reinicia el servicio: 4 Procedemos a proteger el servicio 65

66 Instalación y configuración de RabbitMQ (servidor de colas) 1 Se instala el servidor de colas 2 Se cambia el password al usuario guest 522 Instalación, configuración, listamiento y verificación del funcionamiento de los diferentes servicios en los nodos En esta fase se centra el procedimiento de instalación, listamiento y verificación del funcionamiento de los diferentes servicios que hacen parte del ambiente mínimo de OpenStack; esta parte es de suma importancia ya que es donde se crean los servicios mediante el gestor de base de datos escogido; se configuran los diferentes servicios por medio de edición y agregación de líneas en los diferentes archivos, se asignan sus claves de acceso, sus drivers, y agentes Instalación del servicio Keystone 1 Se ingresa al gestor de bases de datos MariaDB para crear el servicio, cabe anotar que se utilizó como password del gestor MariaDB la palabra proyecto 2 Se crea la base de datos llamada keystone 66

67 3 Se genera acceso a la base de datos con el password proyecto 4 Se da salida a la sesión del gestor MariaDB 5 Se instalan los paquetes del servicio Keystone Configuración del servicio Keystone Se edita el archivo keystoneconf, la siguiente imagen ilustra las líneas que deben ser editadas En la sección [DEFAULT] se editan las siguientes líneas: En la sección [database] se editan las siguientes líneas: En la sección [token] editar las líneas a continuación: 67

68 En la sección [revoke] editar la siguiente línea: 6 Agregamos a la base de datos los datos de Keystone 7 Se reinicia el servicio keystone 8 Se elimina la base de datos SQLite que Ubuntu crea por defecto Creación de clientes y usuarios para el servicio Keystone 1 Se exporta el token administrativo 2 Se exporta la ubicación del servicio Keystone 68

69 3 Creación del usuario administrativo 4 Se crea el rol admin 5 Se crea el servicio de tipo identidad el cual almacenará el catálogo de servicios y las API endpoint de cada uno de estos, los servicios usan este catálogo para determinar cómo comunicarse con los demás servicios en el entorno OpenStack 6 Creación del servicio API endpoint, el cual está compuesto por tres variaciones de cada servicio, uno administrativo, otro interno y el último público, para nuestro caso dichas variaciones residen en una misma red, pero deben estar separadas por cuestiones de seguridad en un ambiente real 69

70 Verificación y listamiento del servicio Keystone En este apartado se realiza la verificación y estado del servicio identity, para proceder con esta tarea se debe deshabilitar los servicios de token y el servicio endpoint temporalmente ya que el tenant admin y el usuario requieren una autenticación mediante token 1 La siguiente imagen ilustra cómo se deshabilita temporalmente los servicios antes mencionados 2 Obtención del token 3 Se lista los tenant, user, role del admin, para verificar que estos se encuentren contenidos en el servicio Identity y puedan ser usados por el servicio Horizon posteriormente Listamiento del tenant admin 70

71 Listamiento del user admin Listamiento del role admin Para una mejor gestión del servicio Identity se crean unos scripts para el Keystone client el cual disminuye las operaciones e incrementa la eficiencia del client, estos script son unos archivos de tipo OpenRC Se crea un archivo llamado admin-openrcsh, al cual se añaden las siguientes líneas 71

72 Posteriormente se crea un archivo llamado demo-openrcsh, el cual tiene el siguiente contenido Los scripts creados anteriormente se ejecutan de la siguiente forma: Instalación del servicio Glance 1 Se ingresa al gestor de bases de datos MariaDB para crear el servicio, cabe anotar que se utilizó como password del gestor MariaDB la palabra proyecto 2 Se crea la base de datos llamada glance 72

73 3 Se asignan los permisos a la base de datos, para nuestro caso se utilizó el password GLANCE_DBPASS 4 Salida del gestor de base de datos 5 Se ejecuta el script admin-openrcsh 6 Se crea el usuario glance 7 Se agrega el rol administrativo al usuario glance 73

74 8 Creación del servicio Identity a glance 9 Se crea la imagen del servicio API endpoint 10 Se instalan los paquetes para el servicio glance Configuración del servicio glance Para el correcto funcionamiento del servicio ya mencionado debemos editar el archivo llamado glance-apiconf ubicado en la ruta /etc/glance, editar en los siguientes apartados las siguientes líneas: 1 En la sección [DEFAULT] cambiar las líneas: 2 En la sección [database] editar las siguientes líneas: 3 Sobre la sección [keystone_authtoken] editar las líneas: 74

75 4 En la sección [paste_deploy] edita la línea: 5 Sobre la sección [glance_store] configurar las líneas: Seguidamente se debe configurar el archivo llamado registryconf ubicado en la ruta /etc/glance/glance-registryconf y realizar los siguientes cambios: 6 En la sección [DEFAULT] configurar las líneas 7 En el apartado [database] configurar las líneas: 8 En la sección [keystone_authtoken] editar las siguientes líneas quedando de la siguiente forma: 75

76 9 En la sección [paste_deploy] editar la línea: 10 Se agregan datos a la base de datos glance 11 Se reinician los servicios glance-registry y glance-api 12 Eliminar la base de datos SQLite genera por defecto Verificación y listamiento del servicio Glance Para realizar este procedimiento se instala una imagen temporal de Linux, la cual nos ayudará a verificar que el servicio Glance funciona correctamente; este proceso se realiza de la siguiente forma: 1 Creación del directorio temporal donde va a ser descargada la imagen de Linux antes mencionada 76

77 2 Se descarga la imagen de Linux antes mencionada en el directorio creado 3 Se ejecuta el script creado con anterioridad 4 Se sube la imagen descargada al servicio Glance 5 Listamiento de la imagen descargada con sus atributos 77

78 6 Se elimina el directorio temporalmente creado Instalación del servicio de compute (Nova) El presente servicio debe ser instalado en los nodos Controller y el nodo computo Inicialmente se instalan los componentes del servicio compute (Nova) sobre el nodo Controller de la siguiente manera: 1 Se ingresa al gestor de bases de datos MariaDB para crear la base de datos el servicio 2 Seguidamente se crea la base de datos llamada nova 3 Se conceden todos los permisos a la base de datos creada 4 Se da salida del gestor de Base de Datos 78

79 5 Se ejecuta el script antes creado para permitir el acceso 6 Creación del user nova 7 Se agrega el rol de admin al user previamente creado 8 Se crea el servicio Identity al user nova 9 Para el servicio nova se crea el API-endpoint 10 Se procede a instalar y a configurar los paquetes del componente del servicio 79

80 11 Se edita el archivo /etc/nova/novaconf, en las líneas mencionadas a continuación En el apartado [DEFAULT] configurar las siguientes líneas: En la sección [database] editar la línea siguiente: Sobre la sección [glance] configurar la línea: En el apartado [Keystone_authtoken] editar las siguientes líneas 12 Se adicionan los parámetros del servicio a la base de datos 80

81 13 Reiniciar los servicios de Nova 14 Borrado de la base SQLite creada por defecto en el sistema operativo anfitrión Instalación y configuración del servicio Nova en el nodo computo 1 Se instalan los paquetes del servicio compute 2 Para configurar el servicio Nova se debe editar el archivo /etc/nova/novaconf en las líneas siguientes: En el apartado [DEFAULT] editar las líneas: 81

82 Sobre la sección [glance] configurar las líneas: En el apartado [Keystone_authtoken] editar las líneas: 3 Se determina si el nodo cómputo soporta aceleración del hardware para máquinas virtuales con el siguiente comando: Si después de ejecutar el comando este devuelve un valor de 0, indica que el nodo no soporta la aceleración del hardware y se debe configurar el archivo /etc/nova/nova-computeconf en la siguiente línea: 82

83 4 Se reinicia el servicio nova-compute 5 Suprimir la base de datos SQLite creada por defecto en el sistema operativo de la siguiente manera: Verificación y listamiento del servicio Nova Este proceso se debe realizar en el nodo Controller de la siguiente forma: 1 Se ejecuta el script creado anteriormente 2 Se ejecuta el comando para listar los servicios y verificar su estado, es necesario tener el nodo compute encendido para que todos los servicios suban 83

84 3 Se lista el catálogo de servicios de imagen para verificar que se encuentra activa la conectividad con el servicio Identity y con Glance Instalación del servicio Neutron (Networking) El presente servicio debe instalarse en los nodos controller, el nodo network y el nodo computo, ya que este es el servicio que se encargará de comunicar las diferentes máquinas virtuales Inicialmente se instala y se configura el servicio sobre el nodo controller de la siguiente forma: 1 Se accede al gestor de base de datos MariaDB y luego se crea la base de datos llamada neutron, se le asigna una contraseña para nuestro caso se utilizó NEUTRON_DBPASS 2 Se asignan todos los privilegios de acceso sobre la base de datos creada 84

85 3 Después de asignar los privilegios salimos del gestor 4 Se carga el script creado para el servicio Keystone 5 Se crea el user neutron con su respectiva contraseña, para nuestro caso utilizamos service_pass 6 Se agrega un rol admin al user antes creado 7 Se añade la entidad al servicio neutron 8 Se crea el API endpoint al servicio neutron 9 Se procede a instalar los componentes del servicio neutron 85

86 10 Configuración de los componentes del servicio neutron En este punto se deben configurar los archivos /etc/neutron/neutronconf y /etc/neutron/plugins/ml2/ml2_confini de la siguiente manera: Se inicia con la configuración del archivo /etc/neutron/neutronconf, en el apartado [DEFAULT] editar las líneas: Para obtener el id tenant se realiza el siguiente proceso: Se ejecuta el script del servicio keystone Se ejecuta el siguiente comando: keystone tenant-get service En la sección [database] configurar las líneas: En el apartado [keystone_authtoken] realizar los siguientes cambios: 86

87 Después de configurar el archivo antes mencionado procedemos con el archivo /etc/neutron/plugins/ml2/ml2_confini enunciado anteriormente Sobre la sección [ml2] ajustar las líneas: En el apartado [ml2_type_gre] configurar la línea: Sobre la sección [securitygroup] editar las líneas: 87

88 11 Configuración del compute para utilizar el servicio neutron Para este proceso es necesario configurar el archivo /etc/nova/novaconf y realizar los siguientes cambios En la sección [DEFAULT] editar las líneas Sobre la sección [neutron] modificar Ingresamos los datos del servicio neutron a la base de datos Se reinician los servicios de compute y de Networking 88

89 Se remueve la base de datos SQLite que el SO crea por defecto Verificación y listamiento del servicio neutron en el nodo controller Para la verificación es necesario ejecutar el script creado anteriormente Se lista y se verifica que el servicio queda instalado satisfactoriamente 89

90 Instalación del servicio neutron sobre el nodo Network Para el correcto funcionamiento de este servicio se debe editar el archivo /etc/sysctlconf en las líneas Se implementan los cambios con el siguiente comando 1 Instalación de paquetes y componentes del servicio 90

91 2 Se edita el archivo /etc/neutron/neutronconf completando los siguientes cambios Sobre la sección [DEFAULT] editar las líneas En la sección [keystone_authtoken] cambiar las líneas Se edita el archivo /etc/neutron/plugins/ml2/ml2_confini, el cual contiene la configuración modular de capa 2 (ML2) plug-in, este usa el mecanismo Open vswitch (OVS) para la creación de redes virtuales para las instancias de la siguiente forma Sobre la sección [ml2] editar las líneas 91

92 En el apartado [ml2_type_flat] se edita la línea En la sección [ml2_type_gre] se edita la línea Sobre la sección [securitygroup] configurar las líneas En el apartado [ovs] cambiar las siguientes líneas Sobre la sección [agent] editar la siguiente línea 92

93 Configuración del agente de capa 3 (L3) que provee servicios de enrutamiento para las redes virtuales, se debe editar el archivo /etc/neutron/l3_agentini realizando los siguientes cambios Sobre la sección [DEFAULT] se cambia las líneas Configuración del agente DHCP el cual provee servicio DHCP para las redes virtuales, se debe editar el archivo /etc/neutron/dhcp_agentini completando las siguientes acciones Sobre la sección [DEFAULT] editar las líneas 93

94 Configuración del agente de metadatos, este provee información de las instancias, se debe editar el archivo llamado /etc/neutron/metadata_agentini en las siguientes líneas y sección En la sección [DEFAULT] editar las líneas En el nodo controller se edita el archivo /etc/nova/novaconf completando las siguientes acciones En la sección [neutron] editar las líneas Se reinicia el servicio nova-api en el nodo controller Configuración del servicio Open vswitch (OVS) en el nodo network, este servicio provee un framework de redes virtuales para las instancias, conecta las redes virtuales con las redes físicas 94

95 Se reinicia el servicio OVS en el nodo de red Se agrega el Switch virtual externo Se añade el puerto al Switch virtual creado anteriormente que conectará con la red externa Reinicio de servicios Networking Verificación y listamiento del servicio neutron Esta tarea se realiza sobre el nodo controller, donde se ejecuta el script creado, es necesario que el nodo de red este encendido 95

96 Se lista los agentes con el comando neutron agent-list y se verifica el estado sobre el nodo controller Instalación del servicio network sobre el nodo compute Sobre dicho nodo es manejada la seguridad de grupos y la conectividad de las instancias, se inicia con la configuración del archivo /etc/sysctlconf, realizando los siguientes cambios Se agregan los cambios con el comando Instalación de los componentes de la red Configuración de los componentes previamente instalados, se inicia con la edición del archivo /etc/neutron/neutronconf en las siguientes secciones y líneas de las mismas En la sección [DEFAULT] editar las líneas 96

97 Sobre la sección [keystone_authtoken] configurar las líneas Configuración del módulo de capa 2 (ML2) plug-in, este usa el mecanismo OpenvSwitch (OVS) en la construcción de frameworks de redes virtuales para las instancias, se edita el archivo /etc/neutron/plugins/ml2/ml2_confini en las líneas siguientes En la sección [ML2] configurar las líneas Sobre el apartado [ml2_type_gre] editar las líneas 97

98 En la sección [securitygroup] se configuran las siguientes líneas En la sección [ovs] editar las líneas Sobre la sección [agent] se configura la línea Reinicio del servicio OpenvSwitch (OVS) el cual proporciona un esencial framework de redes virtuales para las instancias 98

99 Configuración del nodo para usar la red, en este procedimiento se edita el archivo /etc/nova/novaconf completando las siguientes acciones Sobre la sección [DEFAULT] editar las siguientes líneas En la sección [neutron] configurar las líneas Se reinicia el servicio de compute Se reinicia el agente de OpenvSwitch (OVS) Verificación y listamiento del servicio Esta tarea se realiza sobre el nodo controller, donde se ejecuta el script creado, es necesario que el nodo compute este encendido 99

100 Se lista los agentes con el comando neutron agent-list y se verifica el estado sobre el nodo controller 523 Creación de redes En este proceso se crean las redes iniciales las cuales permitirán obtener acceso a las instancias desde el exterior, se agregan subredes, router y una interfaz que permitirá la comunicación entre las redes creadas; se realiza el envío de pings para verificar la comunicación Red externa Estas redes proveen el acceso a internet desde las instancias usando el mecanismo NAT, pero se puede individualizar usando IP flotantes y reglas de seguridad Para la creación de la misma se deben seguir los siguientes pasos en el nodo controller Se ejecuta el script creado Se crea la red con el comando 100

101 Se crea la subnet para le red creada anteriormente Red tenant La red tenant proporciona una red interna para acceder a las instancias, su arquitectura pone en aislamiento esta red para los demás tenants, en la creación de la misma se siguen estos pasos Se ejecuta el script creado 101

102 Se crea la red, en este caso se crea una red demo Creación de la subnet para la red creada anteriormente Se crea un router virtual el cual comunica la red tenant con la red externa y las demás redes tenant; para este caso se crea un router demo 102

103 Se agrega una interfaz entre el router virtual y la subred tenant Se asigna al router de la red externa configuración de Gateway Se verifica la conectividad, para este proceso deben estar encendidos todos los nodos 524 Instalación interface web En este proceso se instala la interfaz web de OpenStack la cual permitirá la gestión más práctica de los diferentes servicios agregados al ambiente 103

104 Para la instalación de la interface web (Horizon) se deben seguir los siguientes pasos sobre el nodo controller 1 Instalación de los paquetes de Horizon con el siguiente comando: 2 Configuración de la Dashboard, para realizar esta tarea se debe editar el archivo /etc/openstack-dashboard/local_settingspy, configurando las líneas siguientes: 3 Reinicio de servicios 4 Verificación Sobre el navegador de internet accedemos a la dashboard con la siguiente dirección e ingresamos el usuario y su password para nuestro caso es usuario admin y password admin_pass 104

105 525 Instalación controlador Opendaylight En esta apartado se instala el controlador OpenDaylight el cual será integrado más adelante al ambiente de OpenStack; para el correcto funcionamiento y despliegue del controlador en mención es necesario la instalación de varias features que permitirán dicha integración y visualización sobre una interfaz web ; para nuestro caso se trabajó con el release Lithium SR3 de ODL, este fichero se descarga en 105

106 formato ZIP y se descomprime, se va a la ruta desde la terminal del SO de la siguiente manera: Seguidamente se ejecuta el archivo karaf alojado en la carpeta bin de la siguiente forma: Se instalan las features necesarias así: 106

107 Sobre el navegador web se ingresa la dirección localhost:8181/indexhtml para acceder a la interfaz web del controlador ODL, se usa el usuario admin y el password admin: 526 Integración de Opendaylight En este proceso se procede a realizar la integración de Opendaylight con OpenStack donde inicialmente deben ser borradas las redes, subredes, routers y puertos creados anteriormente en el apartado 523 creación de redes para evitar problemas en la integración; seguidamente se detiene el agente del servicio neutron plugin-openvswitch y se inhabilitan en los nodos compute y network, ya que OpenDaylight va a gestionar los switchs virtuales; posteriormente se elimina la base de datos de OpenvSwitch para luego crear un puente entre los nuevos switchs virtuales donde se les asignará como gestor a ODL Adicionalmente la base de datos del servicio neutron será eliminado y creado nuevamente para que retome los 107

108 cambios y OpenDaylight asuma el control Seguidamente se enuncia este proceso con más detalle 1 Se ejecuta el script source admin-openrcsh 2 Se listan las diferentes instancias, subredes, redes, routers, puertos que se crearon en OpenStack y se eliminan 108

109 3 Se ejecuta el script source demo-openrcsh 4 Se listan las instancias, subredes, redes, routers, puertos creados anteriormente en OpenStack y deben ser eliminadas tal como se hizo en el punto número 2 5 Se detiene el neutron-server 6 En los nodos compute y network se detiene los agentes del servicio neutron y se deshabilitan 7 Se realiza la eliminación de la base de datos de OpenvSwitch en los nodos compute y network, se para y se reinicia dicho servicio 109

110 8 Se conecta OVS con ODL Nodo compute Nodo network 9 Se establece como administrador de todos los nodos a Opendaylight Nodo compute 110

111 Nodo network 10 Sobre el nodo network se crea un switch virtual el cual será la red externa de OpenStack Nodo network 11 Configuración del plugin ML2 Esta operación se debe realizar sobre todos los nodos donde se debe editar el archivo /etc/neutron/plugins/ml2/ml2_confini Sobre los apartados [ml2] y [ml2_odl] se editan las siguientes líneas: Nodo controller 111

112 Nodo compute Nodo network 12 Se debe reiniciar la base de datos neutron en el nodo controller 13 Se reinicia el subservicio neutron-server 112

113 527 Pruebas para verificar la integración entre OpenStack y OpenDaylight En este procedimiento se realizan las pruebas pertinentes para verificar que la integración entre OpenStack y OpenDaylight se realizó correctamente; inicialmente se crea una red como en el apartado 523 creación de redes; sobre la interfaz web del controlador ODL debe observarse los dos switchs virtuales Para verificar la integración entre OpenStack y OpenDaylight se ejecutan los siguientes pasos: Se crea una red con los mismos pasos ejecutados anteriormente en el apartado 523 creación de redes En la interfaz web del controlador OpenDaylight aparecen los switches virtuales creados 113

114 6 RESULTADOS 61 DESCRIPCIÓN DE RESULTADOS En el transcurso del presente proyecto se ha alcanzo un nivel de conocimiento más amplio sobre la plataforma OpenStack y las SDN, sus arquitecturas, servicios, formas de implementación y funcionalidades que pueden ser aplicadas en el campo del cloud computing La integración entre OpenStack y OpenDaylight ofrece sobre la infraestructura de red el despliegue automático, la flexibilidad, el rendimiento, la estabilidad, la seguridad, la escalabilidad, el balanceo de carga necesarios en los data center cloud; OpenDaylight toma el control sobre los switches virtuales y las necesidades de la virtualización de las redes dirigidas directamente desde OpenStack, brindando una visión más amplia de las mismas; a su vez reduce la complejidad, y aumenta la gestión; que son puntos claves cuando se prestan servicios de red OpenvSwitch mediante OVSBD y OpenFlow se convierte en una pieza fundamental en la integración entre OpenStack y ODL exponiéndose como un servicio hacia el Northbound mediante el servicio neutron y las APIs REST de OpenDaylight, mientas el ML2 Plug-in lo hace desde OpenStack 114

115 La implementación del ambiente de OpenStack no fue fácil, ya que se requiere instalar un gestor de base de datos, un servidor de colas, un buen número de servicios, subservicios, agentes en los distintos nodos y luego estos deben ser configurados, editados para que funcionen y se integren a la plataforma correctamente 115