ESTABLECIMIENTO DE LA INTEGRACIÓN ENTRE...

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

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

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.



PÁGINA DE ACEPTACIÓN

__________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ <NOMBRE COMPLETO> JURADO __________________________________ <NOMBRE COMPLETO> JURADO __________________________________ <NOMBRE COMPLETO> JURADO

Pereira, 08 de noviembre de 2016



CONTENIDO

Pág.

1 ÁREA PROBLEMÁTICA ................................................................................. 16

2 OBJETIVOS .................................................................................................... 17

3 JUSTIFICACIÓN ............................................................................................. 18

4 MARCO TEÓRICO ......................................................................................... 19

4.1 CLOUD COMPUTING .............................................................................. 19

4.2 OPENSTACK ............................................................................................ 22

4.2.1 Componentes OpenStack. ..................................................................... 23

4.2.2 Servicios OpenStack. ............................................................................. 24

4.3 TECNOLOGÍAS Y VARIANTES EN LOS COMPONENTES BASE DE OPENSTACK ..................................................................................................... 39

4.3.1 Almacenamiento en el componente Storage. ..................................... 39

4.3.2 Interconexión en el componente Networking. .................................... 40

4.3.3 Hypervisores en el componente Compute. ........................................ 40

4.4 REDES DEFINIDAS POR SOFTWARE (SDN) ........................................ 41

4.4.1 Arquitectura SDN. .............................................................................. 41

4.4.2 Modelos SDN. .................................................................................... 43

4.4.3 Protocolo OpenFlow. .......................................................................... 46

4.5 CONTROLADORES SDN ......................................................................... 47

4.6 OPENDAYLIGHT CONTROLLER (ODL) .................................................. 48

4.7 OPENSTACK Y OPENDAYLIGHT ........................................................... 51

4.8 ANTECEDENTES ..................................................................................... 53

5 METODOLOGÍA ............................................................................................. 57

5.1 TIPO DE TRABAJO .................................................................................. 57

5.2 PROCEDIMIENTO ................................................................................... 57

5.2.1 Creación del ambiente mínimo y virtualizado para el desarrollo del proyecto. ......................................................................................................... 57

5.2.2 Instalación, configuración, listamiento y verificación del funcionamiento de los diferentes servicios en los nodos. .............................. 66

5.2.3 Creación de redes. ........................................................................... 100



5.2.4 Instalación interface web .................................................................. 103

5.2.5 Instalación controlador Opendaylight ............................................... 105

5.2.6 Integración de Opendaylight ............................................................ 107

5.2.7 Pruebas para verificar la integración entre OpenStack y OpenDaylight 113

6 RESULTADOS ............................................................................................. 114

6.1 DESCRIPCIÓN DE RESULTADOS ........................................................ 114

7 CONCLUSIONES ......................................................................................... 116

8 RECOMENDACIONES ................................................................................. 117

9 BIBLIOGRAFÍA ............................................................................................. 118



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



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



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.



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.



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.



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.



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.



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

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.

17 .

2 OBJETIVOS

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

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.

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.

4.1 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 https://upload.wikimedia.org/wikipedia/commons/thumb/b/b5/Cloud_computing.svg/220px-Cloud_computing.svg.png

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

https://upload.wikimedia.org/wikipedia/commons/thumb/b/b5/Cloud_computing.svg/220px-Cloud_computing.svg.png

https://upload.wikimedia.org/wikipedia/commons/thumb/b/b5/Cloud_computing.svg/220px-Cloud_computing.svg.png

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

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, Force.com, 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 http://4.bp.blogspot.com/-rodnWiBc_2c/T7gmNXEJMRI/AAAAAAAAAD4/A_IbteuDBlI/s1600/cloudbex-modelo-servicio.png 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

http://4.bp.blogspot.com/-rodnWiBc_2c/T7gmNXEJMRI/AAAAAAAAAD4/A_IbteuDBlI/s1600/cloudbex-modelo-servicio.png



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.

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

23 .

Fuente: relases.openstack.org. Fecha de consulta 17/05/2016. Disponible en http://releases.openstack.org/. El presente proyecto se desarrolla bajo el lanzamiento Juno de Openstack. 4.2.1 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).

http://releases.openstack.org/

24 .

Figura 3. Componentes base de OpenStack

Fuente: openstack.org. Fecha de consulta 17/05/2016. Disponible en http://www.openstack.org/software. 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. 4.2.2 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

http://www.openstack.org/software

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.

26 .

Fuente www.slideshare.net. Fecha de consulta 17/05/2016. Disponible en http://www.slideshare.net/openstack/intro-grizzlyarchv1-19109550. 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

http://www.slideshare.net/

http://www.slideshare.net/openstack/intro-grizzlyarchv1-19109550

27 .

Fuente www.slideshare.net. Fecha de consulta 17/05/2016. Disponible en http://www.slideshare.net/openstack/intro-grizzlyarchv1-19109550. 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.



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.

29 .

Fuente http://www.ochobitshacenunbyte.com/2015/03/27/openstack/. Fecha de consulta 17/05/2016. Disponible en http://www.ochobitshacenunbyte.com/wp-content/uploads/2015/03/Openstack-conceptual-arch-folsom.jpg 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 http://www.slideshare.net. Fecha de consulta 17/05/2016. Disponible en http://www.slideshare.net/openstack/intro-grizzlyarchv1-19109550 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.

http://www.ochobitshacenunbyte.com/2015/03/27/openstack/

http://www.ochobitshacenunbyte.com/wp-content/uploads/2015/03/Openstack-conceptual-arch-folsom.jpg

http://www.ochobitshacenunbyte.com/wp-content/uploads/2015/03/Openstack-conceptual-arch-folsom.jpg



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

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 (run-time) 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.

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-dhcp-agent, 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).

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,

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.

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:

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 Service-create y el Keystone Endpoint-create para registrar servicios en sus instalaciones de OpenStack.

Figura 10. Diagrama de flujo de Identity Service.

37 .

Fuente docs.openstack.org. Fecha de consulta 18/05/2016. Disponible en http://docs.openstack.org/juno/install-guide/install/apt/content/keystone-concepts.html. 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.

http://docs.openstack.org/juno/install-guide/install/apt/content/keystone-concepts.html

http://docs.openstack.org/juno/install-guide/install/apt/content/keystone-concepts.html

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/trove.conf.

Figura 11.Arquitectura conceptual de Openstack versión Juno

Fuente docs.openstack.org. Fecha de consulta 18/05/2016. Disponible en http://docs.openstack.org/juno/install-guide/install/apt/content/ch_overview.html#.

http://docs.openstack.org/juno/install-guide/install/apt/content/ch_overview.html

http://docs.openstack.org/juno/install-guide/install/apt/content/ch_overview.html

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 X.509 (*).

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.

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

4.3.1 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 X.509 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.

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.

4.3.2 Interconexión en el componente Networking. En este componente se utilizan varias tecnologías, varias de ellas usadas en el plug-in 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).

4.3.3 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

41 .

Baremetal driver

4.4 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. blogs.salleurl.edu. Fecha de consulta 21/05/2016. Disponible en http://blogs.salleurl.edu/networking-and-internet-technologies/foro-tecnologico-aslan-avanzando-hacia-la-sdn/ 4.4.1 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.

http://blogs.salleurl.edu/networking-and-internet-technologies/foro-tecnologico-aslan-avanzando-hacia-la-sdn/

http://blogs.salleurl.edu/networking-and-internet-technologies/foro-tecnologico-aslan-avanzando-hacia-la-sdn/

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.

43 .

Fuente. http://h17007.www1.hp.com/. Fecha de consulta 21/05/2016. Disponible en http://h17007.www1.hp.com/images/solutions/technology/openflow/sdn-architecture-es.png. 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. 4.4.2 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.

http://h17007.www1.hp.com/

http://h17007.www1.hp.com/images/solutions/technology/openflow/sdn-architecture-es.png

http://h17007.www1.hp.com/images/solutions/technology/openflow/sdn-architecture-es.png

44 .

Figura 14. Modelo SDN centralizado.

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.

Administración central

Controlador SDN

Elemento de red Elemento de red Elemento de red

45 .

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.

Fuente. Propia. El presente proyecto es gestionado por un modelo centralizado.


Controlador SDN

Elemento de red Elemento de red Elemento de red

Agente de red

Agente de red

Agente de red


Controlador SDN

Elemento de red Elemento de red Elemento de redElemento de red Elemento de red Elemento de red

Controlador SDN Controlador SDN

46 .

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

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.

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

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.

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

4.6 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

OpenDaylight RYU NOX POX Beacon Floodlight

Soporta OpenStack SI SI NO NO NO SI

Soporte OpenFlow 1.0, 1.3 1.0, 1.2, 1.3 1.0 1.0 1.0 1.0

Lenguaje Java Python C++ Python Java Java

Interfaz web SI SI NO SI SI SI

OpenSource SI SI SI SI SI SI

Sistema OperativoLinux, Mac,

WindowsLinux Linux

Linux, Mac,

Windows

Linux, Mac,

Windows,

Android

Linux, Mac,

Windows

CONTROLADOR

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.

50 .

Fuente. www.opendaylight.org. Fecha de consulta 23/05/2016. Disponible en https://www.opendaylight.org/opendaylight-features-list.

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 1.0, OpenFlow 1.3, NETCONF, OVSDB, etc. Los plug-ins se conectan dinámicamente a la SAL (Service Abstraction Layer) que funciona como una capa de abstracción para los módulos de redes superiores. Es decir, la SAL permite que OpenDaylight ejecute la tarea solicitada independientemente del protocolo usado para conectarse con los equipos físicos. La siguiente figura ilustra la arquitectura de OpenDaylight relase Lithium. Figura 17. Arquitectura OpenDaylight Lithium.

http://www.opendaylight.org/

https://www.opendaylight.org/opendaylight-features-list

51 .

Fuente. www.opendaylight.org. Fecha de consulta 23/05/206. Disponible en https://www.opendaylight.org/lithium.

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

http://www.opendaylight.org/

https://www.opendaylight.org/lithium

52 .

Figura 18. Arquitectura de implementación de la Neutron API

Fuente. http://thenewstack.io/. Fecha de consulta 23/05/2016. Disponible en http://thenewstack.io/opendaylight-is-one-of-the-best-controllers-for-openstack-heres-how-to-implement-it/. 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.

http://thenewstack.io/

http://thenewstack.io/opendaylight-is-one-of-the-best-controllers-for-openstack-heres-how-to-implement-it/

http://thenewstack.io/opendaylight-is-one-of-the-best-controllers-for-openstack-heres-how-to-implement-it/

53 .

Figura 19. Implementación de OVSDB.

Fuente. https://wiki.opendaylight.org/view/Presentations. Fecha de consulta 24/05/2016. Disponible en http://www.1-4-5.net/~dmm/talks/openstack_and_odl_atlanta.pdf.

4.8 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

https://wiki.opendaylight.org/view/Presentations

http://www.1-4-5.net/~dmm/talks/openstack_and_odl_atlanta.pdf

http://www.1-4-5.net/~dmm/talks/openstack_and_odl_atlanta.pdf

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

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

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.

57 .

5 METODOLOGÍA

5.1 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 plugin-openvswitch 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.

5.2 PROCEDIMIENTO 5.2.1 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.

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

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.

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.

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:

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.

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

64 .

2. Seguidamente editamos el archivo ntp.conf 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 http://ubuntu-cloud.archive.canonical.com/ubuntu" \ "trusty-updates/juno main" > /etc/apt/sources.list.d/cloudarchive-juno.list

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

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

5.2.2 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

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 keystone.conf, 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:

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.

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.

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

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-openrc.sh, al cual se añaden las siguientes líneas.

72 .

Posteriormente se crea un archivo llamado demo-openrc.sh, 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

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

6. Se crea el usuario glance.

7. Se agrega el rol administrativo al usuario glance

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-api.conf 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:

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 registry.conf ubicado en la ruta /etc/glance/glance-registry.conf 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:

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.

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.

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.

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.

80 .

11. Se edita el archivo /etc/nova/nova.conf, 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.

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/nova.conf en las líneas siguientes:

En el apartado [DEFAULT] editar las líneas:

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-compute.conf en la siguiente línea:

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.

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.

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.

86 .

10. Configuración de los componentes del servicio neutron. En este punto se deben configurar los archivos /etc/neutron/neutron.conf y /etc/neutron/plugins/ml2/ml2_conf.ini de la siguiente manera: Se inicia con la configuración del archivo /etc/neutron/neutron.conf, 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:

87 .

Después de configurar el archivo antes mencionado procedemos con el archivo /etc/neutron/plugins/ml2/ml2_conf.ini 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:

88 .

11. Configuración del compute para utilizar el servicio neutron. Para este proceso es necesario configurar el archivo /etc/nova/nova.conf 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

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

90 .

Instalación del servicio neutron sobre el nodo Network Para el correcto funcionamiento de este servicio se debe editar el archivo /etc/sysctl.conf en las líneas

Se implementan los cambios con el siguiente comando

1. Instalación de paquetes y componentes del servicio

91 .

2. Se edita el archivo /etc/neutron/neutron.conf 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_conf.ini, 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

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

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_agent.ini 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_agent.ini completando las siguientes acciones Sobre la sección [DEFAULT] editar las líneas

94 .

Configuración del agente de metadatos, este provee información de las instancias, se debe editar el archivo llamado /etc/neutron/metadata_agent.ini 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/nova.conf 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

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

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/sysctl.conf, 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/neutron.conf en las siguientes secciones y líneas de las mismas. En la sección [DEFAULT] editar las líneas

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_conf.ini en las líneas siguientes En la sección [ML2] configurar las líneas

Sobre el apartado [ml2_type_gre] editar las líneas

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

99 .

Configuración del nodo para usar la red, en este procedimiento se edita el archivo /etc/nova/nova.conf 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

100 .

Se lista los agentes con el comando neutron agent-list y se verifica el estado sobre el nodo controller

5.2.3 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

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

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

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.

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

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_settings.py, 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 http://controller/horizon e ingresamos el usuario y su password para nuestro caso es usuario admin y password admin_pass

http://controller/horizon

105 .

5.2.5 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

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í:

107 .

Sobre el navegador web se ingresa la dirección localhost:8181/index.html para acceder a la interfaz web del controlador ODL, se usa el usuario admin y el password admin:

5.2.6 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 5.2.3 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

108 .

cambios y OpenDaylight asuma el control. Seguidamente se enuncia este proceso con más detalle.

1. Se ejecuta el script source admin-openrc.sh

2. Se listan las diferentes instancias, subredes, redes, routers, puertos que se crearon en OpenStack y se eliminan

109 .

3. Se ejecuta el script source demo-openrc.sh

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.

110 .

8. Se conecta OVS con ODL Nodo compute

Nodo network

9. Se establece como administrador de todos los nodos a Opendaylight Nodo compute

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_conf.ini Sobre los apartados [ml2] y [ml2_odl] se editan las siguientes líneas: Nodo controller

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

113 .

5.2.7 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 5.2.3 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 5.2.3 creación de redes.

En la interfaz web del controlador OpenDaylight aparecen los switches virtuales creados.

114 .

6 RESULTADOS

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

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.

116 .

7 CONCLUSIONES

OpenDaylight surge como una de las soluciones a la falta de despliegue, flexibilidad, escalabilidad, gestión, seguridad en las redes que pueden tener los data center cloud, el controlador ODL se encarga de realizar dichas tareas de forma automática, centralizada o descentralizada según las necesidades, dando una visión más amplia y configurable sobre las redes; tomando el control sobre los switches y la virtualización de la infraestructura de red, permitiendo el aprovisionamiento y despliegue más rápido de los servicios Ondemand.

A la hora de tratar de correr todos los nodos en simultáneo, se encontró la dificultad de que el computador portátil sobre el cual se estaba realizando el proyecto se bloqueaba constantemente debido al gran consumo de recursos que estos demandaban; fue necesario exportar las máquinas virtuales en formato OVA e instalarlas sobre un computador con mayores recursos para seguir con el despliegue de la plataforma de OpenStack, el controlador ODL y su integración.

OpenStack y OpenDaylight presentan una gran ventaja debido a su modularidad, esta permitió una instalación más cómoda y por fases, donde cada servicio, subservicio y agentes fueron añadidos, configurados y puestos a prueba en el proyecto mientras se aprendía cada día sobre el funcionamiento y configuración de estas herramientas.

Este documento generó aportes valiosos en la forma de cómo implementar un ambiente básico de OpenStack y posteriormente integrarse con las SDN que puede ser de gran utilidad para el desarrollo de futuros trabajos, investigaciones e implementación de dichas herramientas sobre un entorno de pruebas o real y funcional.

117 .

8 RECOMENDACIONES

Es importante crear copia de las diferentes máquinas virtuales creadas y su configuración; esto nos ayudará a tener una contingencia en el momento de que se presente algún fallo sobre los diferentes nodos que pueden ser sensibles ya que se encuentran sobre un entorno virtualizado; con esta práctica se evita la pérdida de tiempo y trabajo realizado; puesto que la implementación y puesta en marcha de la plataforma OpenStack, OpenDaylight y su integración requirió de mucho tiempo, esfuerzo y dedicación.

Realizar una tabla que contenga de forma organizada los nombres de las diferentes bases de datos que se generaron para los servicios instalados con sus respectivas claves de acceso; con el fin de poder ingresar a ellas en caso de requerir algún cambio; evitando generar una nueva perdiendo datos, tiempo y esfuerzo.

Es recomendable realizar instantáneas (snapshots) de las máquinas virtuales antes de realizar algún cambio significativo sobre ellas como pueden ser actualizaciones, instalación de servicios, subservicios, configuración y/o edición de los mismos; en caso de presentarse alguna falla, inconveniente, mala actualización, instalación o configuración de servicios, subservicios esta instantánea nos ayudará a regresar nuevamente al estado anterior el nodo sobre el cual se realizaron los diferentes cambios.

De presentarse el caso de tener que exportar las máquinas virtuales por diferentes motivos, es recomendable hacerlo bajo la extensión OVA; al momento de hacer la importación de las mismas es muy importante hacerlo sin reinicializar las tarjetas de red, ya que se perdería la configuración de sus interfaces ocasionando perdida de la comunicación en las redes de gestión, red túnel y acceso hacia la red externa.

Para futuros trabajos, desarrollos, o implementaciones ya sea sobre un ambiente de pruebas o uno real y funcional; sería de gran importancia tratar de hacerlo instalando más complementos a la plataforma OpenStack y mas features al controlador ODL, esto permitirá tener una exploración más profunda sobre estas herramientas, ampliar los conocimientos sobre las mismas, adquirir mayores y mejores resultados al momento de ser aplicados al cloud computing y comprender la importancia que estas tienen sobre el desarrollo de las nuevas tecnologías y su aplicación.

118 .

9 BIBLIOGRAFÍA Chang , H.-T., & Wang, S.-Y. (2015). Using SDN Technology to Mitigate

Congestion in. En IEEE International Conference on Communications (ICC). IEEE.

Davie, & Pfaff. (2013). The Open vSwitch Database Management Protocol. Pfaff & Davie.

Foundation, O. (08 de 12 de 2015). http://docs.openstack.org/. Obtenido de http://docs.openstack.org/juno/install-guide/install/apt/content/ch_overview.html#

Foundation, O. (2016). OpenStack Operations Guide. FOUNDATION, O. N. (2016). OPEN NETWORK FOUNDATION. Obtenido de

https://www.opennetworking.org Foundation, O. N. (2016). www.opennetworking.org. Obtenido de

https://www.opennetworking.org/index.php Göransson, P., & Black, C. (2014). Software Defined Networks A Comprehensive

Approach. Massachusetts: Kaitlin Herbert. Jha, A., D, J., Murari, K., Raju, M., Cherian, V., & Girikumar, Y. (2012). OpenStack

Beginner's Guide (for Ubuntu - Precise). Ken, P. (2011). Deploying OpenStack. California, Sebastopol, EEUU: O’Reilly

Media. Martínez Copete, J. E. (2015). http://ribuc.ucp.edu.co/. Obtenido de

http://ribuc.ucp.edu.co:8080/jspui/bitstream/handle/10785/3665/CDMIST115.pdf

Mell, & Grance. (2011). Recomendations of the National Institute of Standars and Technology. NTSI, Gaithersburg.

Montoya Alzate, Y. L., & Aendaño Ocampo, J. M. (2016). http://ribuc.ucp.edu.co/. Obtenido de http://ribuc.ucp.edu.co:8080/jspui/bitstream/handle/10785/3674/CDMIST127.pdf

Nikbazm , R., Dashtbani, M., & Ahmadi, M. (2015). Enabling SDN on a Special Deployment of OpenStack. En Computer and Knowledge Engineering (ICCKE). IEEE.

Nikbazm , R., Dashtbani, M., & Ahmadi, M. (2015). Enabling SDN on a Special Deployment of OpenStack. En Computer and Knowledge Engineering (ICCKE). IEEE.

Opendaylight.org. (2016). opendaylight.org. Obtenido de https://www.opendaylight.org/

Project, O. (2016). wiki.opendaylight.org. Obtenido de https://wiki.opendaylight.org/view/Main_Page

Ruiz, A. F. (2014). http://ribuc.ucp.edu.co/. Obtenido de http://ribuc.ucp.edu.co:8080/jspui/bitstream/handle/10785/2788/CDMIST97.pdf

119 .

SHIN, Y., KANG, S., KWAK, J., & YANG, S. (2015). iNaaS : OpenStack and SDN/OpenFlow based. En International Conference on Advanced Communication Technology (ICACT). IEEE.

Singh, P., & Manickam, S. (2015). Design and Deployment of OpenStack-SDN. En Reliability, Infocom Technologies and Optimization (ICRITO) (Trends and Future Directions). IEEE.

Tkachova, O., & Salim, M. J. (2015). An Analysis of SDN-OpenStack Integration. En Problems of Infocommunications Science and Technology (PIC S&T). IEEE.

ESTABLECIMIENTO DE LA INTEGRACIÓN ENTRE...

Documents

Transcript of ESTABLECIMIENTO DE LA INTEGRACIÓN ENTRE...