despliegue de arquitectura cloud basada en openstack y su...

Proyecto Fin de Grado

Grado en Ingeniería de las Tecnología de

Telecomunicación

Despliegue de arquitectura cloud basada en

OpenStack y su integración con Chef sobre CentOS

Autor: Antonio Cobos Domínguez

Tutor: Pablo Nebrera Herrera

Dep. Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2014

Proyecto Fin de Grado

Grado en Ingeniería de las Tecnologías de Telecomunicación

Despliegue de arquitectura cloud basada en

OpenStack y su integración con Chef sobre CentOS

Autor:

Antonio Cobos Domínguez

Tutor:

Pablo Nebrera Herrera

Profesor asociado

Dep. Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2014

Proyecto Fin de Carrera: Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre

CentOS

Autor: Antonio Cobos Domínguez

Tutor: Pablo Nebrera Herrera

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2014

El Secretario del Tribunal

A mi familia

A mis amigos

A mis maestros

i

Agradecimientos

Este es el único rincón personal que hay en esta consecución de hojas llenas de pensamientos frios y

calculados.

Es el momento de agradecer con palabras los actos de empuje, ánimo y apoyo por parte de mis allegados.

Doy gracias a mis padres. A mi madre Rosario y a mi padre Antonio. Dos personas a las que admiro y tomo

como referente en la vida. Sin ellos y su idea de cómo criar a un hijo no estaría escribiendo estas líneas que

culminan una etapa de mi vida. Como dice mi madre, “la mejor herencia que se le puede dar a un hijo es una

buena educación”. Ellos son la gran motivación de este proyecto. Quiero darles esa satisfación que se que

sienten cuando yo alcanzo un objetivo en la vida. Ellos me guian y yo los sigo.Por ello expreso este

sentimiento de eterno agradecimiento hacia ellos. Por sus consejos, sus riñas, su cariño y su amor.

Os quiero.

No puedo olvidarme de mi Abuela Ana, mi Abuela Chica, mi titi Fali, mi tata Pili, mi tio Baldo, mi tia Nieves,

mi tio Carlos, mi tia Toñi, mi tio Seba y mi tia Carlota , que siempre he tenido su apoyo, cariño y sus

dineritos “bajo cuerda” que siempre me vienen bien.

Merecen una mención especial mis dos abuelos, que velan por mí desde el cielo y me aportan ese equilibrio

espiritual que todo el mundo, en ciertos momentos de su vida, necesita.

A mis amigos que paramos en San Diego, a mis amigos “los Pimientos”, a mis amigos de mi barrio de

Torreblanca y a mis amigos de la facultad que me han acogido en su piso durante la elaboración de este

documento. A todos ellos, Gracias.

A mi colega Carlos porque siempre le tengo algo especial, al igual que a mi Javi. Por los buenos momentos

que aun quedan por llegar compañeros. Muchas Gracias.

Gracias a todos por estar conmigo y aparecer en mi vida desde que me embarque en este proyecto hace 4 años,

que al principio parecía que este fin no iba a llegar.

GRACIAS

iii

Resumen

El Cloud Computing tiene como objetivo la dotación de flexibilidad, elasticidad y alta disponibilidad a los

servicios que se proporcionan a través de la nube. OpenStack, un software de código abierto, hace de la nube

una infraestructura para el despliegue de servicios distribuidos. Este estudio se centrará en la configuración e

implantación de este software al proyecto RedBorder Horama, así como la valoración de las configuraciones,

distribuciones, y software para una mejor integración.

Se ha realizado una amplia investigación sobre Cloud Computing, un mundo inifnito con múltiples

posibilidades, centrado en el lanzamiento de instancias, el cual es el pilar fundamental de esta tecnología. Gracias

a eso se podrá acceder a máquinas remotas, con un pago por uso y con un aprovisionamiento dinamico. Se

implementa también el gestor de sistemas y automatización de insfraestructura de la nube, Chef, para

proporcionar una gestión más potente de ésta.

v

Abstract

The aim of Cloud Computing is to give flexibility, elasticity and high availability to the services provided by the

network. Openstack, an open-source software, makes the cloud an infrastructure that allows the deployment of

distributed services. This research will be focus on the configuration and implementation of this software to the

RedBorder Horama Project, also the evaluation of the configurations, distributions and software to improve the

integration with it.

A research with a big scope about Cloud Computing has been done in this study, a whole world which has many

posibilities, centered on instances launching, which is the main funcionality of this tecnology. Due to this fact,

it will be posible to access to remote hosts, with a charge by demand and with dinamic provisioning. Chef has

been also implementing which is a system and automation framework cloud manager to provide a better

management of the services.

Índice

Agradecimientos i

Resumen iii

Abstract v

Índice vi

Índice de Tablas ix

Índice de Figuras xi

Notación xiii

1 Introducción 1

2 Escenario y Configuración Inicial 5 2.1 Topologia 5

2.1.1 Caracteristias físicas 5 2.1.2 Escenario 6

2.2 Configuración inicial 7

3 Componentes Básicos de OpenStack 11 3.1 Openstack Identity Service (Keystone) 13 3.2 Openstack Image Service (Glance) 14 3.3 OpenStack Compute (Nova) 15 3.4 OpenStack Object Storage (Swift) 16 3.5 OpenStack Block Storage (Cinder) 17 3.6 OpenStack Networking (Neutron) 18 3.7 OpenStack Dashboard (Horizon) 19

4 Lanzar una Instancia 21 4.1 Usuarios 21

4.1.1 Administrador 21 4.1.2 Usuarios normal 21

4.2 Componentes 21 4.2.1 Redes 21 4.2.2 Routers 21 4.2.3 Instancia 22

5 Componentes Adicionales de OpenStack 29 5.1 OpenStack Orchestration (Heat) 29 5.2 OpenStack Telemetry (Ceilometer) 30 5.3 DataBase OpenStack (Trove) 31 5.4 Hadoop Cluster OpenStack (Sahara) 33 5.5 Nota aclaratoria 34

6 Integración con Chef 35 6.1 ¿Qué es Chef? 35 6.2 Chef Server 35 6.3 Chef Client 36

vii

6.3.1 Knife OpenStack 36

7 Presupuesto 39

8 Lineas de Mejora 41

Anexo A: Instalación en Nodo Controlador 43

Anexo B: Instalación en Nodo de Red 73

Anexo C: Instalación en Nodo Compute 81

Anéxo D: Instalación y Casos de Uso de Chef 91

Anéxo E: Scripts del Nodo Controlador 93

Anéxo F: Scripts del Nodo de Red 105

Anéxo G: Scripts del Nodo Compute 109

Anexo H: Pings 113

Referencias 117

Índice de Conceptos 119

ix

ÍNDICE DE TABLAS

Tabla 1: Diferencias entre maquinas virtuales y físicas 3

Tabla 2: Componentes 4

Tabla 3: Presupuesto 39

xi

ÍNDICE DE FIGURAS

Figura 1. Tipos de aaS 2

Figura 2. Escenario de Red 6

Figura 3. Módulos e IP de los Nodos 7

Figura 4. Componentes en controlador 8

Figura 5. Componentes en red 9

Figura 6. Componentes en compute 9

Figura 7. Diagrama OpenStack 12

Figura 8. Autenticación en Keystone 14

Figura 9. Diagrama Glance 15

Figura 10. Diagrama Nova 16

Figura 11. Diagrama Swift 17

Figura 12. Diagrama Cinder 18

Figura 13. Diagrama Neutron 19

Figura 14. Autenticación en Dashboard 20

Figura 15. Visión general de Dashboard 20

Figura 16. Esquema general de redes 23

Figura 17. Pestaña Instancias 23

Figura 18. Modificación de Sabores 24

Figura 19. Creación sabor RedBorder 24

Figura 20. Lanzar Instancia 25

Figura 21. Redes de la Instancia 26

Figura 22. Estado de la Instancia 26

Figura 23. Asociación de IPs Flotantes 27

Figura 24. Estado de Instancia con IPs flotantes 27

Figura 25. Acceso a maquina RedBorder 28

Figura 26. Diagrama de Heat 30

Figura 27. Diagrama de Ceilometer 31

Figura 28. Diagrama de Trove 32

Figura 29. Diagrama de Sahara 33

Figura 30. Diagrama completo de OpenStack 34

Figura 31. Estructura de Chef 36

xiii

Notación

DHCP Discover Host Configuration Protocol

KVM Kernel-based Virtual Machine

CPU Central Processing Unit

RAM Random Access Memory

IPMI Intelligent Platform Management Interface

PXE Preboot eXecution Environment

S.O Sistema Operativo

API Application Programming Interface

DNS Domain Name System

LDAP Lightweight Directory Access Protocol

SMTP Simple Mail Transfer Protocol

BBDD Base de Datos

VM Virtual Machine

HTTP HyperText Transfer Protocol

RPC Remote Procedure Call

REST REpresentational State Transfer

JSON JavaScript Object Notation

DSL Domain-Specific Language

1

1 INTRODUCCIÓN

a Compuacion en la Nube (Cloud computing) es el desarrollo y la utilización de capacidad de

procesamiento computacional basado en Internet (la “nube”). Este concepto agrupa diversas

características el cual lo hacen más atractivo e interesante para las empresas. Algunas de estas son:

Servicio disponible de forma automática y a demanda.

Accesible a través de la red.

Modelo que permite que solo una instanciai se ejecute en el servidor, pero sirviendo a multiples clientes

(modelo Multi-Tenancy).

o Se comparten los recursos con otros usuarios.

o Aislamiento y seguridad entre ellos.

Los recursos (CPU, Disco Duro y RAM principalmente), cuyo origen pueden ser de un solo host o un

conjunto de ellos (cluster), se agrupanen particiones (pools) [2].

Elasticidad.Basado en el modelo EC2ii.

Pago por uso.

Modelo de negocio “…aaS” (as a Service) basado en la venta de licencias o hardware. Ofrece servicios con

características de cloud. Se definen tres capas o niveles de este modelo:

Software como Servicio (Software as a Service-SaaS): Aplicación como servicio en la nube

o El usuario utiliza una aplicación a través de la web en lugar de tenerla instlada en el propio

equipo. Por ejemplo los servicios de Google u Office365.

Plataforma como Servicio (Platform as a Service-PaaS): Plataforma de desarrollo web en la nube

o Se proporciona toda la plataforma de desarrollo y despliegue de una aplicación al desarrollador.

Por ejemplo Google App Engine (ofrece esa plataforma para que los usuarios desarrollen y

desplieguen aplicaciones en ella).

Infraestructura como Servicio (Infrastructure as a Service-IaaS): Infraestructura como servicio en

la nube

o Se proporciona principalmente capacidad de cómputo, redes ydiversos modos de

almacenamiento. Por ejemplo Amazon Web Services (AWS), OpenStack y Windows Azure.

L

Gran parte de las dificultades por las que atraviesa el mundo se deben a

que los ignorantes están completamente seguros y los inteligentes llenos

de dudas.

Bertrand Russell

Introducción

2

Dentro de los modelos de negocio se puede optar por diferentes tipos de despliegue.

Publico: Se necesita una IP pública para que los usuarios puedan acceder desde cualquier lugar.

Privado: No se necesitan IP’s publicas por tanto el área de uso queda restringida a la red local. Esta

opción es útil para configurar los recursos propios de una manera mas flexibes y con toda la carga en

los servidores.

Híbrido: Se utilizan recursos de la nube privada o de una o varias nubes públicas en función de las

características de cada caso o las necesidades puntuales que haya. Se suele utilizar una API común que

permita una buena integración.

Existen ciertas diferencias entre la estructura clásica de maquinas virtuales o físicas y la infraestructura

en nube. A continuación se presentan alguna de ellas:

Ges

tión P

ropia

Ges

tión P

ropia

Ges

tión P

ropia

Gestió

n p

or T

erceros

Gestió

n p

or T

erceros

Gestió

n p

or T

erceros

Datacenter

Virtualizado IaaS PaaS SaaS

Figura 1: Tipos de aaS

3 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS

Tabla 1: Diferencias entre maquinas virtuales y físicas

Antes de elegir una opción se ha de analizar el entorno donde vamos a desplegar el sowtware de computación

en la nube.

El entorno a desarrollar se situa en la empresa Eneo Tecnología, una empresa dedicada a la seguridad y

visibilidad en redes, cuyo producto principal, RedBorder, se encarga de llevar a cabo esas características

mediante el uso de sensores IPS y netflow en términos generales. Se pretende realizar una nube privada para

disponer de sus servicios de una forma más flexible y eficiente. Una vez realizado ese desarrollo se ampliará

hacia la nube pública para que los clientes puedan acceder a estos servicios desde cualquier lugar del mundo.

Se pretende, una vez finalizado el despliegue, instanciar una imagen de RedBorder al cliente deseado. Puesto

que se desea un control total sobre los recursos proporcionados y la escalabilidad, elasticidad y flexibilidad de

los servidores (la nube).

Maquinas físicas Maquinas virtuales

Ventajas

Aislamiento de servicios

Funcionalidad completa: IPMI,

PXEiii, DHCP…

Aislamiento de servicios

Recursos mejor aprovechados

Inconvenientes

Muchos recursos

desaprovechados

Se pierde cierta funcionalidad

Dependencia de varias maquinas

de un solo equipo físico

Introducción

4

Dentro de todos los IaaS posibles se encuentran varios de pago como son Amazon Web Service (AWS),

BlueLock, IBM Cloud, etc. Por tanto se optará por OpenStack, el cual ofrece la mayoría de las características

de los IaaS mencionados anteriormente. OpenStack se trata de un proyecto de plataforma de cloud computing

open source iniciada en el verano de 2010 por el proveedor IaaS RackSpace y NASA.

Tabla 2: Componentes.

Componente Detalles

Versión Icehouse

Sistema Operativo Base CentOS 6.5

Repositorio de paquetes de OpenStack Red Hat Distributed OpenStack (RDO)

Hypervisor KVM

BBDD MySQL

Cola de Mensajes Qpidiv

Servicio de red OpenStack Networking

Separacion de red tenant v VLAN

Servicio de Imagen (glance) backend GlusterFSvi

Servicio de Identidad (keystone) driver SQL

Servicio de Almacenamiento en Bloque (cinder)

backend GlusterFS

5

2 ESCENARIO Y CONFIGURACIÓN INICIAL

l escenario que se plantea es el disponible en la empresa donde se va a desarrollar OpenStack. Para ello se

va a proceder a explicar las maquinas (hosts) necesarias para montar el entorno de desarrollo. En primer

lugar se necesita un nodovii (controller node) el cual controla y provee a la nube de una funcionalidad

completa. En segundo lugar se creara un nodo de red (network node) que proporciona la mayor parte de los

servicios de red (DHCP, agente de capa 2, etc) y un tercer nodo (compute node, que mas adelante podrán ser

multiples nodos según demanda de recursos) que albergará las maquinas virtuales y gestionará la compatibilidad

de estas con los modos KVMviii o QEMUix.

2.1 Topologia

2.1.1 Caracteristias físicas

Controller Node

Este nodo será desplegado en una maquina virtual dentro de la empresa, con CentOS 6.5 como sistema

operativo base, la cual se le asginará:

o Interfaces de red: 1

o Memoria RAM:2GB

o Disco Duro (GB):50

Network Node

Este nodo será desplegado en una maquina virtual dentro de la empresa, con CentOS 6.5 como sistema

operativo base, la cual se le asignará:

o Interfaces de red: 3

o Memoria RAM:2GB


E

La arquitectura es arbitraria, pero una vez está hecha, se convierte en

necesaria.

Rafael Moneo

Escenario y Configuración Inicial

6

Compute Node

Este nodo será desplegado en una maquina física (maquina incrustada en rack) puesto que será esta la

que lleve todo el procesamiento computacional de las maquinas virtuales (hypervisor). Tendrá un

sistema operativo base CentOS 6.5. Esta maquina tiene las siguientes características:

o Interfaces de red

Físicas: 1

Virtuales: 2 (creadas en la única física).(bond)x

o Memoria RAM:48GB


2.1.2 Escenario

Figura 2: Escenario de Red


2.2 Configuración inicial

A continuación se explicará cómo se asignan las IP´s a los nodos en relación al escenario anterior. En primer

lugar se tiene que configurar una red de gestión (pintadas en rojo en la Fig. 3). Se aprovechará la red de la

empresa para asignar las IP’s de gestión, las cuales pertenecerán a esta. La IP externa (pintada en azul) que se

configurará en el nodo controlador, no tendrá IP (en el Anexo A se explica como hacerlo). Además en el nodo

de red se asignará una IP nueva que pertenecerá a la llamada red de tunelado de instancias (pintada en verde).

Esta red se encargará de crear una conexión directa entre la interfaz del nodo de red y la interfaz del nodo

compute.Si se desea añadir mas compute’s solo habría que asignar una IP nueva dentro de la red de tunelado.

Más adelante se explicará el proceso de instanciar, pero el concepto es que por cada conexión network-compute

se instancien tantas imagenes como VLAN’s se permitan.

Controller Node (IP: 10.0.151.100/24)

El nodo controlador es el responsable de ejecutar el software de gestión de servicios necesario para que

funcione el entorno de OpenStack:

o Proporciona la puerta delantera que las personas usaran (API) para comunicarse con todos los

componentes del entorno.

o Corre un número de servicios a una alta disponibilidad, utilizando Pacemarker y HAProxy

para proveer un IP virtual y funciones de balanceado de carga para que todos los nodos sean

usados.

o Aporta una infraestructura de servicios altamente disponible, como son MySQL y Qpid, que

sustentan a todos los servicios.

Figura 3: Módulos e IP de los Nodos


8

o Proporciona lo que es llamado un almacenamiento persistente para los servicios que corren en

el host.

Network Node (IP1:10.0.151.101/24, IP2:10.0.152.101/24,IP3: external -> 10.0.150.0/24)

El nodo de red es el responsable de hacer todas las redes virtuales que se necesiten para que la gente

cree redes públicas o privadas y enlacen sus maquinas virtuales en la red externa:

o Formar el unico punto de entrada y salida para las instanciasque están corriendo en la cima de

de OpenStack.

o Corre todos los servicios de red del entorno, con la excepcion de que la API del servicio de red

corre en el controlador.

Figura 4: Componentes en controlador


Compute Node (IP:10.0.151.102/24, IP2:10.0.152.102/24)

En el nodo compute corren las instancias de maquinas virtuales en OpenStack:

o Corre el minimo de servicios necesarios para facilitar esas intancias.

o Usa almacenamiento local en el nodo para las maquinas virtuales, asi que no se contempla un

fallo en la migración de maquinas virtuales o recuperación de instancias.

Figura 5: Componentes en el nodo de red

Figura 6: Componentes en el compute


10

Tanto las configuraciones anteriores como la instalación de todos los componentes

de OpenStack se encuentran anexos a esta memoria.

En primer lugar se ha de llevar a cabo lo expuesto en el Anexo A

En segundo lugar se llevará a cabo lo expuesto en el Anexo B

Y por último se realizará lo indicado en el Anexo C

Solo queda lanzar una intancia, lo cual viene indicado en el Capitulo 4 de esta

memoria “Lanzar una Instancia”.

11

3 COMPONENTES BÁSICOS DE OPENSTACK

penStack se trata de un proyecto grande y modular. Los módulos tienen muchas características comunes

para poder integrarse fácilmente. Todos están escritos en Python, algunos de ellos utilizan AMQP

(Advanced Message Queue Protocol) para el in tercambio de mensajes (en concreto se utilizará Apache

Qpid), incluyen una API RESTful xi para la comunicación entre componentes o externa (clientes), autenticación

basada en tokensxii gestionada a través del componente Keystone y tienen una base de datos propia e

independiente.

Antes de continuar leyendo esta sección se recomienda ver el glosario de conceptos de la sección 3 en el apartado

Conceptos (como usuarioxiii, credencialesxiv, autenticaciónxv, servicioxvi, endpointxvii, rolxviii).

O

Si se puede imaginar, se puede programar.

Anónimo

Componentes Básicos de OpenStack

12

Fig

ura

7:

Dia

gra

ma O

pen

Sta

ck


3.1 Openstack Identity Service (Keystone)

Este componente se basa en un directorio centralizado que almacena información de:

Usuarios

Proyectos (tenants)

Roles

Servicios y sus endpoints

La información se almacena en un Sistema de Gestión de Base de Datos Relacional (MySQL) y además este

componente (Keystone) debe ser el primero en ser instalado puesto que los demás componente lo usarán como

sistema de autenticación para poder acceder a la información necesario del proyecto (cada uno en su módulo).

Keystone se encarga tanto de manejar los pedidos de la API así como también provee un único punto de

integración para las políticas de OpenStack, catálogos de los servicios, token y autenticación.

Proceso de autenticación:

Usuario envía credneciales a través de la API

Keystone le envía un token temporal y le envía un catálogo de los servicios.

Usuario pregunta por los tenants a los que puede acceder.

Keystone le responde con la lista de tenants a los que puede acceder el usuario.

Usuario envía credenciales con su correspondiente tenant.

Keystone envía al usuario los servicios que tiene disponible dentro de ese tenant y el token de este.

El usuario determina el endpoint correcto para iniciar una instancia a la vez que se le provee a este del

token recibido anteriormente por Keystone.

El endpoint pregunta al modulo Keystone si es es correcto el token recibido y si se le permite usar el

servicio por el que envía la petición.

Keystone le dice al servicio que el usuario esta autorizado para solicitar ese servicio y que los tokens

coinciden.

El servicio crea una nueva instancia y le envía la información al usuario.


14

3.2 Openstack Image Service (Glance)

Glance permite a los usuarios descubrir, registrar, y recuperar imagines de maquinas virtuales. Este servicio

(Glance) ofrece una REST API que permite preguntar los metadatos de la imagen de la maquina virtual y

recuperar una imagen actual. Se pueden guarder las imagenes de maquinas virtuales tanto en un fichero simple

como en el modulo de almacenamiento de objetos que veremos mas adelante.

Este componente gestiona las plantillas de imágenes de los sistemas. Ademas de ello, gestiena las instantaneas

de las instancias Puede soportar diversos formatos: raw, qcow2, vhd, ami, vdi y vmdk.

Una de las ventajas de este componente es su capacidad para crear, gestionar y asimilar snapshots (instancias en

ejecución que pueden ser obtenidas creando una nueva imagen basada en el estado actual del disco de una

instancia en particular).

Dentro de Glance encontraremos:

glance-api acepta los pedidos para la búsqueda, obtención y almacenamiento de imágenes.

El registro de almacenamiento glance-registry procesa y recupera los metadatos de las imágenes.

Posee una base de datos para los metadatos de las imágenes.

También se corren servicios de replicación, para proveer consistencia y disponibilidad a través del

cluster, auditoría y actualización.

Figura 8: Autenticación en Keystone


Figura 9: Diagrama Glance

3.3 OpenStack Compute (Nova)

Este es el componente principal de OpenStack. Gestiona las instancias de imágenes, dónde deben ejecutarse y

el acceso mediante consola.

Soporta diferentes hipervisores: KVM/QEMU, Xen, Hyper-V, VMware ESXi, LXC, Docker.

Permite incluso el aprovisionamiento de máquinas físicas mediante Baremetal/Ironic.

Funcionamiento:

El cliente nova-api acepta y responde a las llamadas del usuario final.

La virtualización es administrada por nova-compute. Crea/finaliza las instancias de VMs a través

de la API del hipervisor utilizado.

La planificación es realizada por nova-schedule. Toma los pedidos de VMs de la cola y determina

dónde debería ejecutarse.

La cola, es el nodo central para el pasaje de mensajes entre daemonsxix.

También dispone de una base de datos que almacena la mayoría de los datos de estado de

compilación y ejecución.

nova-consoleauth, nova-novncproxy, nova-console permiten a los usuarios acceder a las

instancias virtuales a través de un proxy.

Al crear una instancia deberán seleccionar entre las opciones de configuraciones de recursos

virtuales disponibles, llamadas flavors. Luego, pueden agregarse recursos como volúmenes de

almacenamiento persistente y direcciones IP públicas.


16

3.4 OpenStack Object Storage (Swift)

Componente importante de OpenStack, pero independiente del resto. Se trata de un sistema de almacenamiento

redundante y escalable (almacenador de objetos).

El almacenamiento de objetos permite el almacenamiento masivo de datos no estructurados de forma bastante

económica. Hoy en día se utiliza bastante por aplicaciones web. Ademas Swift incluye su propia API y otra

compatible con Amazon S3.

Normalmente es utilizado por Glance para almacenar imágenes. (Antes de continuar se recomienda leer la

sección Objetos del apartado Conceptos).

Tanto los archivos como los objetos tienen metadatosxx asociados a los datos que contienen, pero los objetos son

caracterizados por tener metadatos extendidos. Cada objeto tiene asignado un identificador único que permite a

un servidor o usuario final recupéralo sin necesidad de conocer la ubicación física de la información. Esto es

muy útil para automatizar y racionalizar almacenamiento de datos en entornos de cloud computing.

Se puede mencionar sobre Swift:

El servidor proxy se encarga de aceptar los pedidos entrantes, como archivos para subir, modificaciones a

los metadatos o creación de contenedores; también provee archivos y un listado de los contenedores.

El servidor de cuentas maneja las cuentas asociadas con el servicio.

El servidor de contenedores realiza un mapeo de los contenedores, carpetas, dentro del servicio.

El servidor de objectos administra los objectos, archivos.

También se corren servicios de replicación, para proveer consistencia y disponibilidad a través del cluster,

auditoría y actualización.

Figura 10: Diagrama Nova


3.5 OpenStack Block Storage (Cinder)

Los volúmenes son dispositivios de bloques que se crean de forma independiente de la instancia y pueden

asociarse y desasociarse de ella cuando se precise.

Cinder es equivalente al componente Amazon EBS. Los volúmenes se crean en el nodo de almacenamiento (por

defecto con LVM) y se conectan a la instancia que se desee mediante algún protocolo de redes de

almacenamiento (iSCSI es el mas utilizado y el que se utilizará en este proyecto).

Cinder incluye controladores para gran cantidad de dispositivos de almacenamiento del mercado. Cuando nova

termina una instancia borra todo el almacenamiento local asociado a ella, pero no los volúmenes, por lo que

estos reciben el nonmbre de almacenamiento permante.

Se puede pensar en los volúmenes como discos externos que se conectan o desconectan de las instancias,

aunque se trate de un mecanismo completamente diferente.

Sobre Cinder:

La API de Cinder permite la manipulación de volúmenes, tipos de volúmenes y snapshots. cinder-api acepta

los pedidos y los enruta a cinder-volume para ser procesados.

cinder-volume reacciona leyendo o escribiendo a la base de datos que mantiene el estado, interactúa con

otros procesos (como el cinder-scheduler) a través de la cola de mensajes y directamente actua sobre el

almacenamiento proveyendo hardware o software.

cinder-scheduler selecciona el nodo para el almacenamiento por bloques óptimo para la creación de un

volumen sobre el.

La cola de mensajes enruta información entre los procesos de Cinder.

Una base de datos almacena el estado de los volúmenes.

Figura 11: Diagrama Swift


18

3.6 OpenStack Networking (Neutron)

Componente encargado de la configuración de redes virtuales, el cual, incluye un buen numero de complementos

(OpenvSwitch, Cisco, Niciria, etc).

Neutron gestiona múltiples redes de forma independiente gracias al uso de Linux network namespacesxxi que

permite que múltiples routers virtuales compartan un dispositivo de red físico.Neutron también se encarga de la

gestión de los grupos de seguridas y de las IPs flotantesxxii.

Neutron tiene como características:

Da a a los tenants de la nube una API para construir topologías de red muy completas, y configurar

políticas de red avanzadas en la nube.Por ejemplo crear una topología de aplicación web multi-tier.

Permite plugins innovadores (codigo abierto y no abierto) que introduce capacidades avanzadas de red.

Por ejemplo usar tunelado L2-in-L3 para evitar los limites de VLAN, proveer garantías de calidad de

servicio (QoS) end-to-end. Usa además protocolos de monitorización como NetFlow.

Permite cualquier topología avanzada de servicios de red que se instauren en las redes de los tenants de

Openstack. Por ejemplo: LB-aaS, VPN-aaS, firewall-aaS, IDS-aaS, data-center-interconnect-aaS.

Mediante la GUI que ofrece Horizon (modulo que veremos mas adelante):

o Neutron borra y crea redes y subredes nivel 2 y 3.

o Inicia maquinas virtuales en una red especifica de Neutron.

API Extensibility Framework, incluye extensiones para:

o “proveedor de red”, el cual mapea las redes L2 de Neutron a una VLAN específica en el centro

de datos físico.

Neutron-server es el principal proceso del servidor de red de OpenStack. Es un daemon en Python que pasa las

peticiones de los usuarios de la API de OPenStack al plug-in configurado. Neutron incluye tres agentes que

interactúan con el proceso principal a través de la cola de mensajes o la API de red estándar de OpenStack:

neutron-dhcp-agent proporciona servicios de DHCP a todas las redes tenant.

neutron-l3-agent proporciona L3/NAT para permitir el acceso a una red externa desde las maquinas

virtuales en las redes tenant.

Figura 12: Diagrama Cinder


3.7 OpenStack Dashboard (Horizon)

Este componente es el panel de control web de OpenStack desarrollado en Djangoxxiii.

No incluye toda la funcionalidad de la API de cada componente, pero si los métodos mas utilizados.

El panel de control de OpenStack (dashboard) proporciona al administrador y usuarios una interfaz gráfica para

acceder, provisionar y automatizar los recursos basado en la nube. Ademas es fácil incorporar y presentar

productos y servicios para terceros, como son la facturación, la monitorización y las herramientas de gestios

adicionales.

Capacidades de Horizon:

Permite cotrolar a los administradores y usarios su “nivel de computación”, almacenamiento, y

recursos de red.

Como administrador, el panel de control ofrece una vista global del tamaño y estado de la nube. Se

pueden crear usuarios y proyectos, asignar usuarios a proyectos y configurar limites en los recursos

de esos proyectos.

El panel de control proporciona a los usuarios un portal “self-service” para provisionar sus propios

recursos dentro de los limites establecidos por el administrador.

Figura 13: Diagrama Neutron


20

Figura 14: Autenticación en Dashboard

Figura 15: Visión general de Dashboard

21

4 LANZAR UNA INSTANCIA

n este capítulo se describirán los diferentes componentes, y sus funciones, necesarios para el lanzamiento

de una instancia.

4.1 Usuarios

Una vez instalado el componente Keystone ya se pueden crear los diferentes usuarios (Ver Anexo A)

4.1.1 Administrador

Este usuario es el encargado de crear la red donde se alojarán las IP’s las cuales servirán para acceder a las

instancias de las maquinas virtuales. En este caso la red que se creará con este usuario será la perteneciente a la

red de la empresa (10.0.150.0/24). A esta red serán mapeadas las IP’s de la red interna creada por el usuario

normal demo que es donde se crearan las instancias de las imagenes de RedBorder.

4.1.2 Usuarios normal

Este usuario (demo) es el encargado de crear la red interna virtual donde se alojaran las IP’s de las instancias de

las maquinas virtuales (192.168.1.0/24).

4.2 Componentes

A continuación se presentarán los componentes básicos necesario para lanzar una instancia de la maquina virtual

de RedBorder.

4.2.1 Redes

En este caso se crearan 3 redes:

1. La red externa correspondiente a la de la empresa (10.0.150.0/24) creada por el usuario admin

2. La red de sincronismo necesaria para que el Sistema RedBorder se sincronice a la hora de montarlo en

cluster (192.168.4.0/24)

3. La red interna donde se crearan las IP de las interfaces de red de las instancias de RedBorder

(192.168.1.0/24).

4.2.2 Routers

A estos components se la llamarán routerspor comodidad, porque realmente no lo son fisicamente, pero si lo son

virtualmente. Estos se encargan de separar las diferentes redes creadas y de mapear las IP’s privadas a las

públicas (red de la empresa).

E

No importa. Inténtalo de nuevo. Fracasa otra vez.Fracasa mejor.

Samuel Beckett

Lanzar una Instancia

22

En este caso se creará un router con dos interfaces:

1. Una interfaz a la red pública (red de la empresa), 10.0.150.20, que a su vez será la encargada de

elegir la IP flotante que permitirá acceder a la instancia de la red interna desde la red exterior.

2. Una interfaz a la red privada, 192.168.1.1, que hará las veces de puerta de enlace de ésta red y otra

IP que será la 192.168.1.3 que será la encargadá de asignar por DHCP la IP que le corresponderá

a la instancia de la maquina virtual en la red interna.

4.2.3 Instancia

A continuación se mostrará un ejemplo básico de creación de red, routers y lanzamiento de instancia.

Estos pasos se han de realizar en el nodo controlador y se harán mediante la API de Neutron.

En primer lugar se han de exportar las variables de entorno asociadas al usuario administrador para crear la

red externa mediante el siguiente comando:

source admin-openrc.sh; El dfichero admin-openrc.sh se encuentra en el Anexo

A.

Ahora se creara la red externa y se llamará ext-net:

neutron net-create ext-net --shared --router:external=True;

Y se creará la subred asociada a la red. Esta subred se llamará ext-subnet con un rango de IPs flotantes que

va desde la .20 a la .26, desactivando el DHCP y asignándole una pasarela por defecto 10.0.150.1 y la red a

la que pertenece 10.0.150.0/24.

neutron subnet-create ext-net --name ext-subnet --allocation-pool

start=10.0.150.20,end=10.0.150.26 --disable-dhcp --gateway 10.0.150.1

10.0.150.0/24;

Se han de exportar las variables de entorno asociadas al usuario demo para crear la red externa mediante el

siguiente comando:

source demo-openrc.sh; encuentra en el Anexo A.

Ahora se creara la red interna y se llamará demo-net:

neutron net-create demo-net;

Y se creará la subred asociada a la red. Esta subred se llamará demo-subnet asignándole una pasarela por

defecto 192.168.1.1 y la red a la que pertenece 192.168.1.0/24.

neutron subnet-create demo-net --name demo-subnet --gateway 192.168.1.1

192.168.1.0/24;

Por último se creará el router:

neutron router-create demo-router;

Y se asignará una interfaz de este a la red interna:

neutron router-interface-add demo-router demo-subnet;

Y la otra interfaz será asignada a la red externa y se configurará como pasarela:


neutron router-gateway-set demo-router ext-net;

Una vez hecho esto se tendrá lo siguiente:

Los siguientes pasos que se han de realizar son necesarios para lanzar una instancia:

1. Ir a la pestaña del dashboard “Instancias” y pulsar “Lanzar Instancia”.

2. Posteriormente saldrá el cuadro de lanzado de instancia y se le dará el nombre que se desee, y se

seleccionará un sabor. En este caso se seleccionará un sabor personalizado, el cual se creó en el

dashboard del administrador de la siguiente manera. Seleccionando la pestaña Sabores y

dándole a crear sabor como aparece a continuación.

Figura 16: Esquema general de redes

Figura 17: Pestaña Instancias


24

Y se le asignarán los recursos deseados para este sabor.

Figura 18: Modificación de Sabores

Figura 19: Creación sabor RedBorder


Ahora ya se puede rellenar completamene el cuadro de lanzado de instancia como se adjunta a continuación

Figura 20: Lanzar Instancia

3. Ahora en el cuadro de lanzado de instancia se seleccionará la pestaña de “Redes” y se indicará en

que red se levantará la instancia de la maquina virtual de RedBorder.


26

Figura 21: Redes de la Instancia

4. Se pulsa lanzar instancia y listo.

5. Una vez hecho esto se han de asignar las IP’s flotantes para poder acceder a esta instancia desde la red

externa. Para ello se selecciona la pestaña “Mas” y pulsamos sobre “Asociar IP flotante”.

Figura 22: Estado de la Instancia


6. Se selecciona el botón “+” y posteriormente se selecciona la red de donde se asignarán las IP’s

flotantes para por último pulsar “Asociar”.

7. Ya se podrá acceder mediante ssh a la instancia de RedBorder indicándole como IP la flotante

asociada dentro del rango indicado en la creación de la red externa.En este caso 10.0.150.21

Figura 23: Asociación de IPs Flotantes

Figura 24: Estado de Instancia con IPs flotantes


28

Figura 25: Acceso a maquina RedBorder

29

5 COMPONENTES ADICIONALES DE OPENSTACK

5.1 OpenStack Orchestration (Heat)

El servicio de orquestaciónxxiv provee un servicio de orquestación basado en plantillas para describir una

aplicación en la nube mediante las llamadas de la API de OpenStack para ejecutar esas aplicaciones.

Las plantillas permiten crear la mayoría de los recursos de OpenStack, como instancias, IPs flotantes, volúmenes,

grupos de seguridad, usuarios, etc. Incluso, proporciona algunas funcionalidades mas avanzadas, como crear

instancias de alta disponibilidad, crear instancias auto-escalables, y clusters anidados.

Para proveer una alta integración con otros proyectos principales de OpenStack, todos los proyectos principales

de OpenStack podrán recibir una gran BBDD de usuarios.

Esto anterior permite a los desarrolladores una integración directa con el servicio de orquestación o a través de

plug-ins personalizados.

El servicio de Orquestación consta de los siguientes componentes:

Heat. Una línea de comandos que se comunica con la API (heat-api) para correr APIs tales como AWS

CloudFormation. Los desarrolladores finales podrían incluso usar directamente la API de Orquestacion

REST.

Heat-api. Proporciona una API REST nativa de OpenStack que procesa las peticiones enviándolas al

heat-engine sobre RPC.

Heat-api-cfn. Proporciona una API Query AWS que es compatible con AWS CloudFormation y

procesa las peticiones API enviándolas al heat-engine sobre RPC.

Heat-engine. Organiza el lanzamiento de plantillas y proporciona eventos a la API del consumidor.

No importa. Inténtalo de nuevo. Fracasa otra vez.Fracasa mejor.

Samuel Beckett

Componentes Adicionales de OpenStack

30

5.2 OpenStack Telemetry (Ceilometer)

Telemetry proporciona una infraestructura para la monitorización y la medición de la nube de OpenStack.

Tambien se conoce como proyecto Ceilometer.

El módulo Telemetry:

Recoge eficientemente las mediciones de datos cobre la CPU y los costs de red.

Recopila datos de notificaciones de monitorización enviadas por los servicios o sondeando la

infraestructura.

Configura los tipos de datos recopilados para satisfacer diversos requisites de funcionamiento.

Accediendo e insertanto los datos medidos a través de la API REST.

Expande la infraestructura para recopilar el uso de datos personalizados mediante plug-ins adicionales.

Genera mensages de mediciones firmados que no pueden ser rechazados.

El Sistema consiste en los siguientes components básicos:

Ceilometer-agent-compute. Corre en cada compute node y ademas hace recuenos para las estadisticas

de la utilización de recursos. Se plantea la posibilidad de que en un future pueda haber otro tipo de

agentes en adición a este.

Ceilometer-agent-central. Corre en un servidor central de gestión para hacer recuento de las estadisticas

de utilización de recursos para los recursos no vinculados a instancias o compute nodes.

Ceilometer-collector. Corre en uno o mas servicores centrales de gestión para monitorizar las colas de

mensajes (notificaciones y mediciones provenientes del agente). Los mensajes de notificación son

procesados y convertidos a mensajes de medición y enviados de vuelta en el canal de mensajes usando

el tema apropiado. Los mensajes del modulo de Telemetría estan escritos en el amacenamiento de datos

sin modificación alguna.

Ceilometer-alarm-notifier. Corre en uno o mas servidores centrales de gestión para permitir la

establecimiento de alarmas basadas en la evaluación de umbrales para una colección de muestras.

Una BBDD. Una base de datos capaz de manejar escritura concurrente (de una o mas recopilación de

Figura 26: Diagrama de Heat


instacias) y lectura (de la API del servidor).

Ceilometer-api. Corre en uno o mas servidores centrales de gestión para proporcionar acceso a los datos

desde la BBDD.

Estos servicios se comunican mediante Qpid (el canal de mensajeria AMQP que se ha instalado). Solo el

recopilador y la API del servidor tienen acceso a la BBDD.

5.3 DataBase OpenStack (Trove)

El servicio de BBDD proporciona una funcionalidad de provisionamiento en la nube escalable y segura tanto

para motores de BBDD relacionales como no relacionales. Los usuarios pueden utilizar rapida y facilmente las

caracteristicas de la BBDD sin la carga que supone el manejo de tareas administrativas complejas. Los usuarios

de la nube y administradores de la BBDD pueden provisionar y gestionar tantas instancias de BBDD como se

necesiten.

El servicio de BBDD proporciona recursos de aislamiento a un alto nivel de redimiento, y automatización de

tareas administrativas complejas como son el despliegue, configuración, aplicación de parches, copias de

seguridad, restauraciones y monitorización.

El servicio de BBDD incluye los siguientes components:

Python-troveclient. Una linea de comandos que se comunica con el component trove-api.

Trove-api. Proporciona una API RESTful nativa de OpenStack, que soporta JSON, para

provisionar y gestionar las instancias de Tove.

Trove-conductor. Corre en el host, y recibe mensajes de las instancias de los huéspedes que quieren

actualizar información en el host.

Figura 27: Diagrama de Ceilometer


32

Trove-taskmanager. Instrumentos del sistema complejo de flujos que ayuda al provisionamiento

de instancias, gestion y manejo del ciclo de vida de la sinstancias, y rendimiento de operaciones

sobre las instancias.

Trove-guestagent. Corre dentro del huesped de la instancia. Gestiona y realiza operaciones en la

misma BBDD.

A continuación se procederá a describir un proceso de flujo de alto nivel para el uso del servicio de BBDD:

1. El administrador prepara la infraestructura:

Instalacion del servicio de BBDD (Trove)

Este crea una imagen para cada tipo de BBDD que el administrador quiera tener (una

para MySQL, una para MongoDB, etc).

El administador de OpenStack actualiza el almacenador de datos para usar las nuevas

imágenes, usando el comando trove-manage.

2. El usuario final usa el servicio de BBDD:

Ahora, el usuario puede crear una instancia de Trove (BBDD) cada vez que quiera

usando el comando trove-create.

El usuario final obtiene la IP de la instancia Trove usando el comando trove list para

obtener el ID de la instancia, y entonces usar el comando trove show instanceID para

obtener la IP.

El usuario puede ya acceder a la instancia de Trove usando los comandos típico de

acceso a una BBDD. Por exemplo en MySQL:

$ mysql -u myuser -pmypass -h trove_ip_address mydb

Figura 28: Diagrama de Trove


5.4 Hadoop Cluster OpenStack (Sahara)

El objetivo de este proyecto es permitir a los usuarios provisionar y gestionar de una manera fácil clusters de

Hadoopxxv en OpenStack. Merece la pena mencionar que Amazon proporciona Hadoop durante varios años

como Amazon Elastic MapReduce (EMR) [4].

Sahara tiene como objetivo proporcionar usuarios con medios simples para provisionar clusters Hadoop

especificando varios parámetros como la versionde Hadoop, la topología del cluster, los detalles hardware de

los nodos y poco mas. Después el usuario rellena todos los parámetros y Sahara despliega el cluster en pocos

minutos. Sahara también proporciona medios para escalar clusters ya provisionados mediante la

adición/borrado de nodos de trabajo en función de lo demandado.

Las características claves son:

Está diseñado como un componente de OpenStack.

Gestionado a través de una API REST con interfaz de usuario disponible como parte del Dashboard.

Apoyo para las diferentes distribuciones de Hadoop:

1. Sistema conectable de motores de instalación Hadoop.

2. Integración con herramientas de gestión de proveedores específicos, como Apache Ambari o

consola de gestión de Cloudera.

Plantillas predefinidas de conficuraciones de Hadoop con la opción de modificar parámetros.

Sahara se comunica con los siguientes componentes de OpenStack:

Horizon: Proporciona interfaz gráfica de usuario con la capacidad de usarr todas las características de

Sahara.

Keystone: Autentica usuarios y proporciona token de seguridad, limitando por tanto las capacidades de

los usuarios en Sahara a sus privilegios en OpenStack.

Nova: Usado para proporcionar las maquinas virtuales para el cluster Hadoop.

Figura 29: Diagrama de Sahara


34

Glance: Las imágenes de las maqinas virtuales de Hadoop se guardan aquí, cada imagen contiene un

S.O. instalado y Hadoop; Hadoop pre-instalado debería dar una buena desventaja en el nodo de puesta

en marcha.

Swift: Puede ser uasdo como un almacenamiento para datos que serán procesados por las funciones de

Hadoop.

5.5 Nota aclaratoria

Los componentes explicados en el punto 6.3 y 6.4 son proyectos que no estan en la fase de desarrollo estable

pero tienen la mayoria de las funcionalidades en activo. Por tanto se han incluido en esta sección puesto que su

funcionalidad completa y estable es cuestion de meses pero no se han incluido en la instalación y configuracion

de OpenStack, aunque si se han previsto su incorporacion dejando recursos de sobra que estos modulos

necesitaran, tanto software como hardware.

Sin tener en cuenta estos dos módulos, la arquitectura sería la mostrada a continuación y esta será la que se

instalará de manera definitiva:

Figura 30: Diagrama completo de OpenStack

35

6 INTEGRACIÓN CON CHEF

Todo tiene un final, excepto la salchicha, que tiene dos.

Anónimo.

n esta sección se hablará del orquestador Chef y de su integración con OpenStack además de las

funcionalidades extras que aporta esta función y de las ventajas y flexibilidad, que con solo la integración

de este componente, con la que se puede dotar a la nube.

En primer lugar se realizará una introducción para aclarar conceptos, y posteriormente se ahondará en

funcionalidades cada vez más amplias y complejas.

6.1 ¿Qué es Chef?

Chef es un sistema de gestión de codio abierto (escrito en rubyxxvi y erlangxxvii) y un frameworkxxviii de

automatización de la infraestructura de la nube creado por Opscode [5].

Se puede usar Chef para desplegar y desarrollar servidores y aplicaciones locales y en la nube. Cookbooksxxix y

recipesxxx le “dicen” a Chef cómo cada nodo de la organización debería ser configurado. Las recipes (se usa

DSLxxxi para escribir los recipes) de Opscode describen el estado que tendría que tener un recurso en un

momento en concreto. Chef guarda esos ficheros en cookbooks junto a otros archivos de configuración

necesarios.

En este caso en particular se va a usar la versión open-source de Chef 11.0 que según una estimación de los

creadores podría ser usado para configurar más de 10.000 nodos con tan solo un cliente de este.

6.2 Chef Server

El servidor de Chef actúa como un aglutinador de datos de configuración. Este guarda los cookbooks, las

políticas que son aplicadas en los nodos, y los metadatos que describen cada nodo registrado que están siendo

gestionados por el cliente de Chef. Cada instancia del servidor de Chef debe estar configurado y gestionado

localmente, incluyendo migraciones de datos, aplicación de actualizaciones, y aseguramiento de que la

infraestructura local escala apropiadamente [6].

A continuación se presentará un diagrama sobre los componentes que forman parte del despliegue del servidor

de Chef y como ellos están relacionados.

Nginx: Es un servidor HTTP de código abierto y un proxy inverso utilizado como balanceador de

carga front-endxxxii para el servidor de Chef. Todas las peticiones a la API del servidor de Chef son

enrutadas a través de Nginx.

Bookshelf: Como su traducción en inglés indica, es como una estantería donde se guardan los

cookbooks (ficheros, plantillas, etc).

E

Integración con Chef

36

6.3 Chef Client

Realmente, el cliente de chef no es necesario para el fin que se trata en este proyecto. En este caso se utilizará

algo parecido que interactua de una forma similar con el servidor de Chef, el cual es llamado Knife, también

del paquete de Chef.

Knife es una herramienta de línea de comandos que proporciona una interfaz entre un repositiorio local de chef

y el servidor de Chef. Knife ayuda a los usuarios a gestionar:

Nodos, cookbooks y recipes, roles, datos JSON almacenados, entornos, recursos de la nuves

(incluyendo provisionamiento), la instalación del cliente Chef en las workstations de gestión y la

búsqueda de datos indexadosen el servidor de Chef.

Knife corre desde una workstation de gestión y se situa entre un servidor de Chef y la infraestructura de la

organización. Knife interactuca con un servidor de Chef usando la misma API REST que es usada por un cliente

de Chef.

6.3.1 Knife OpenStack

El subcomando knife openstack es usado para gestionar la API-driven de los servidores que estan alojados en la

nube por OpenStack.

Se trata de un plugin al commando Knife original que permite crear configuraciones automatizadas mediante

chef y ser aplicadas en OpenStack. Hace asi las veces de orquestador. Por tanto este nuevo nivel de gestión

aporta varias características.

Añade una capa extra de orquestacion, pudiendo así, realizar múltiples combinaciones mediante la

compenetración con Heat.

Figura 31: Estructura de Chef


Mayor potencia de gestión de configuraciones puesto que Chef abarca un amplio panorama de recursos

y opciones a gestionar y manejar.

Plantillas guardadas y personalizadas para el entorno necesario pudiendo añadir mas caracteristicas a

estas o incluso crear nuevas, lo que implica un convergencia mucho menor con respecto a las

configuraciones.

La instalación y uso de este servicio se encuentra en el Anexo D.

Integración con Chef

38

39

7 PRESUPUESTO

n este apartado se elaborará un presupuesto aproximado en función de las horas trabajadas y del coste que

conllevaría comprar los equipos con los que se ha trabajado durante este proyecto. Se han excluido

ordenadores personales y desplazamientos al entorno de trabajo asi como otros gastos. Se tiene que un

programador Junior cobrará unos 40€ por hora trabajada y que el equipo de rack (asi como los equipos necesarios

para la virtualización) costará unos 6.000€. Por tanto se tiene el siguiente presupuesto:

Tabla 3: Presupuesto

E

Precio Total

Horas trabajadas (h) €/hora

360 40 14.400,00 €

Equipo necesario (€) Cantidad

6000 1 6.000,00 €

TOTAL 20.400,00 €

Presupuesto

40

41

8 LINEAS DE MEJORA

La única parte donde el ‘éxito’ aparece

antes que el ‘trabajo’ es en el diccionario

Vidal Sasoon.

ras realizar este proyecto, se han podido conseguir ciertas cosas, tales como la liberación de carga

computacional en equipos particulares dejando esta tareas a los equipos corporativos dando una ventaja

de movilidad,cobro por uso y distribución de servicios.

En este caso en particular se ha decidido por una topología virtual determinada mediante el uso de túneles de

nivel 2. Una mejora o cambio según demanda de esta topología como podria ser VXLAN, FLAT y casi un

numero infinito de posibilidades de combianicion de estos modelos.

Openstack se trata de un proyecto OpenSource, y por tanto siempre está en continuo desarrollo y mejora. Aunque

para este trabajo se escogió la ultima versión estable de OpenStack (4/2014) ya estaba saliendo a la luz una

nueva version, “Juno”, con integraciones muy interesantes como las vistas en apartados anteriores de esta

memoria (Cluster Hadoop, Provisionamiento en maquinas fisicas, despliegue de OpenStack sobre Openstack

para el facilitamiento de migraciones, etc).

Por tanto, y no como una mejora, sino como un desarrollo constante de este proyecto, se propone el continuo

mantenimiento de OpenStack para una integración cada vez mas acorde a las necesidades de empresas y

tecnologías venideras, ya que este se va reinventando para poder combinarse con multiples servicios, asi como

para la mejora de la seguridad y eficiencia de la nube.

Aunque se eligió la instalación sobre un sistema base CentOS, sería interesante instalarlo sobre Ubuntu, ya que

la nube de OpenStack trae integradas ciertas herramientas de orquestación, etc. que por motivos de

compatibilidad e integración de estas con las ya existentes en la empresa fue una opción que se descartó. Aun

así, daría una mayor facilidad de gestión e instalación debido a su potente interfaz gráfica.

T

Lineas de Mejora

42

43

ANEXO A: INSTALACIÓN EN NODO CONTROLADOR

Antes de todo se informa que para separar los comandos que se han de meter manualmente de los que se hacen mediante scripts se utilizará la notación FIN_DE_SCRIPT para indicar que el script utilizado termina ahí y el siguiente comando se introducirá manualmente en el terminal.

En primer lugar es necesario realizar unos pasos previos donde se activará iptables y se instalará NTP (network

time protocol, para sincronizar servicios a través de múltiples maquinas). Introducir estos comandos para

hacerlo:

service NetworkManager stop

service network start

chkconfig NetworkManager off

chkconfig network on

service iptables start

chkconfig iptables on

yum -y install ntp

service ntpd restart

chkconfig ntpd on;

Si se prefiere se puede ejecutar el script config_red.sh que aparece en el Anexo E.

A continuación se mostrará cómo están configuradas las interfaces de red en este equipo. Se configurará este

equipo en función de lo mostrado en el apartado 2 de la memoria principal “Escenario y configuración inicial”

Fichero /etc/sysconfig/network-scripts/ifcfg-eth1

Anexo A: Instalación en Nodo Controlador

44

Ahora se configurará la resolución de nombres:

Editar el archivo /etc/hosts añadiéndole las líneas siguientes:

Se reinicia servicio:

service network restart

Y se comprueba….

Verificamos conectividad: Mirar Anexo H.

Se comprabará con el siguiente comando que está sincronizado (la sincronización se indica con un asterisco):

ntpq –np

Y muestra lo siguiente:

Database

A continuación se instalarán los paquetes del cliente y servidor de MySQL, y la librería de Python:

yum -y install mysql mysql-server MySQL-python

Para poder trabajar con OpenStack, MySQL requiere que se le hagan ciertos cambios.

Para ello se debe editar el archivo /etc/my.conf y poner bajo [mysqld] la dirección ip de la interfaz de gestión

del nodo controlador para que otros nodos puedan acceder a la BBDD desde la red de gestión:

[mysqld]

...

bind-address = 10.0.151.100


Además establecer ciertas claves para habilitar InnoDB y UTF-8 por defecto:

[mysqld]

...

default-storage-engine = innodb

innodb_file_per_table

collation-server = utf8_general_ci

init-connect = 'SET NAMES utf8'

character-set-server = utf8

El fichero configurado del todo debe tener más o menos este aspecto:

Ahora se inicia el servidor de la BBDD MySQL y se configura para que se arranque automáticamente cada vez

que se inicie el sistema:

service mysqld start

chkconfig mysqld on

Por último, es conveniente configurar una contraseña para root, así los programas de OpenStack que creen las

bases de datos y las tablas la solicitarán.

Se debe borrar el usuario anonymous que se crea cuando la BBDD se inicia por primera vez.

Para evitar posibles problemas de conexión con la BBDD hacer lo siguiente (introducir el siguiente comando):


46

mysql_secure_installation

Si el anterior comando falla, puede que se necesite introducir el siguiente comando:

mysql_install_db

Una vez hecho esto, se puede volver a introducir el comando….

mysql_secure_installation

Si es la primera vez que se inicia MySQL probablemente no tenga contraseña configurada para el usuario root,

por tanto si se le solicita una contraseña simplemente se presiona ENTER y se introduce la contraseña que se

quiera utilizar para el usuario root.

Una vez se configure la contraseña se presentaran ciertas opciones que harán mas segura la instalación de la

BBDD.

RESPONDER SI A TODAS LAS CUESTIONES SI SE QUIERE UNA CONFIGURACIÓN GENERICA.

OpenStack packages

A continuación se describirá la configuración que se debe completar después de configurar las máquinas para

instalar los paquetes de OpenStack más recientes.

Si se quiere recurrir a una instalación ya con una configuración predeterminada se puede ejecutar el script

packages.sh del Anexo E.

Si se desea realizar una configuración más avanzada y personalizada ejecute los comandos abajo indicados.

En este caso se usarán los paquetes OpenStack del repositorio de RDO. Estos paquetes funcionan para RHEL

6, la versión compatible de este en CentOS, y Fedora 20.

Instalar yum-plugin-priorities plug-in. Este paquete permite la asignación de prioridades relativas a los

repositorios del software configurado.

yum install yum-plugin-priorities

Para permitir los repositorios de RDO, descargar e instalar el paquete rdo-release-icehouse:

yum install http://repos.fedorapeople.org/repos/openstack/openstack- icehouse/rdo-release-

icehouse-3.noarch.rpm

El paquete EPEL incluye las claves GPG para la firma de paquetes e información de repositorio. Ahora se

instalará la versión más reciente del paquete epel (ver

http://download.fedoraproject.org/pub/epel/6/x86_64/repoview/epel-release.html)

Por ejemplo:

yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-

release-6-8.noarch.rpm

http://repos.fedorapeople.org/repos/openstack/openstack-

http://dl.fe/

http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm



El paquete openstack-utils contiene programas útiles que hacen la configuración en instalación más fácil. Estos

programas se usarán a lo largo de la guía de instalación.

Instala openstack-utils. Esto verifica que puedas acceder a los repositorios RDO:

yum install openstack-utils

El paquete openstack-selinux incluye los archivos de políticas que son necesarios para configurar SELinux

durante la instalación de OpenStack.

Instala openstack-selinux:

yum install openstack-selinux

Ahora se actualizarán los paquetes del sistema:

yum upgrade

FIN_DE_SCRIPT

Por último, se reinicia si la actualización ha incluido un nuevo paquete del kernel (si no está seguro reinicie):

reboot

Messaging server

OpenStack usa un mediadior de mensajes para coordinar operaciones e información de estado de los servicios.

Este servicio de intermediación de mensajes normalmente se ejecuta en el nodo controller. OpenStack soporta

varios de estos (RabbitMQ, Qpid y ZeroMQ). EN este caso se usará Qpid por el hecho de que es el más

conveniente para CentOS y el que mejor viene documentado para integrar con OpenStack.

Para instalar el servicio de intermediación de mensajes (message broker):

yum install qpid-cpp-server

Para configurar el servicio de intermediación de mensajes (message broker):

Para simplificar la instalación en este entorno de prueba, se recomienda desactivar la autenticación. Para

ello se precisa modificar el fichero /etc/qpidd.conf y cambiar el valor del campo auth (que está sin

comentar) a no:


48

Nota

Para entornos de producción es recomendable activar la autenticación.Si se decide activarla se deberá

configurar un usuario y contraseña para qpidd en cada archivo de configuración de los servicios de

OpenStack que usen qpidd

Para finalizar la instalación

service qpidd start

chkconfig qpidd on

Ahora ya se puede proceder a la instalación de los servicios de OpenStack

Servicio de Identidad

Si se desea se puede utilizar el script keystone_1.sh, disponible en el Anexo E, para instalar de

una manera más rápida y cómoda este servicio.

Se creará con contraseña por defecto redborder. Si se prefier realizar una instalación

personalizada se han de seguir los pasos que vienen a continuación.


Installar el Servicio de Identidad de OpenStack junto con Python-keystoneclient:

yum install openstack-keystone python-keystoneclient

El Servicio de Identidad usa una BBDD para guardar información. Especificar la localización

de la BBDD en el archivo de configuración. En este caso se usa uan BBDD MySQL con el

nombre de usuario keystone. Reemplazar KEYSTONE_DBPASS con una contraseña adecuada

para la BBDD del usuario:

openstack-config --set /etc/keystone/keystone.conf database connection

mysql://keystone:KEYSTONE_DBPASS@controller keystone

FIN_DE_SCRIPT

Usar la contraseña que se configuró en el paso donde se instala la BBDD MySQL para

identificarse como root.

Crear un usuario de BBDD llamado keystone:

mysql -u root –p

mysql> CREATE DATABASE keystone;

mysql>GRANT ALL PRIVILEGES ON keystone.* TO

'keystone'@'localhost'IDENTIFIED BY 'KEYSTONE_DBPASS';

mysql> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%'

IDENTIFIED BY 'KEYSTONE_DBPASS';

mysql> exit

Si se desea, a partir de aquí se puede utilizar el script keystone_2.sh, disponible en el Anexo

E, que tendrá ADMIN_TOKEN=redborder por defecto. Por tanto, si se desea personalizar los

comandos se ha de seguir con los procedimientos indicados a continuación.

A continuación se crea la BBDD para el Servicio de Autenticación:

su -s /bin/sh -c "keystone-manage db_sync" keystone


50

Ahora se define un token de autorización para usarlo como “clave compartida” entre el

Servicio de Autenticación y otros servicios de OpenStack. Se usa openssl para generar un

token aleatorio y guardarlo en el fichero de configuración:

ADMIN_TOKEN=$(openssl rand -hex 10)

echo $ADMIN_TOKEN

openstack-config --set /etc/keystone/keystone.conf DEFAULT

admin_token $ADMIN_TOKEN

Por defecto, Keystone usa tokens PKI. Ahora se crearán claves firmadas y los certificados y

se restringirá el acceso a los datos generados:

keystone-manage pki_setup --keystone-user keystone –keystone group

keystone

chown -R keystone:keystone /etc/keystone/ssl

chmod -R o-rwx /etc/keystone/ssl

Arrancar el Servicio de Autenticación y activarlo para que se arranque al iniciar el sistema:

service openstack-keystone start

chkconfig openstack-keystone on

Por defecto, el Servicios de Autenticación guarda los tokens expirados en la BBDD

indefinidamente. Esto es útil para entornos de producción, pro sin embargo la acumulación

de estos tokens expirados aumentaran considerablemente el tamaño de la BBDD y puede

disminuir el rendimiento del servicio, particularmente en entornos de prueba con recursos

limitados. Se recomienda configurar una tarea periódica usando “cron” para eliminar los

tokens expirados cada hora:

(crontab -l -u keystone 2>&1 | grep -q token_flush) || echo '@hourly

/usr/bin/keystone-manage token_flush>/var/log/keystone/

keystone-tokenflush.log 2>&1' >> /var/spool/cron/keystone


Definición de usuarios, inquilino, y roles

Despues de instalar el Servicio de Autenticación, se configurarn los usuarios, inquilinos, y roles

para ser autenticados. Estos son usados para tener acceso a los servicios y puntos finales

(endpoints) que ahora se presentan.

Normalmente, se indicaría un usuario y contraseña para autenticarse con el Servicios de

Autenticación. En este punto, sin embargo, aun no se han creado usuarios, asi que se tendrá que

utilizar el token de autorización creado en la sección anterior. No es necesario hacer eso con la

opción –os-token en los comandos de keystone , sin embargo, se hará de esa manera configurando

la variable de entorno OS_SERVICE_TOKEN. Además de esta última, se configurará

OS_SERVICE_ENDPOINT para especificar donde se está ejecutando el Servicio de

Autenticación:

export OS_SERVICE_TOKEN=$ADMIN_TOKEN

export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0

Crear un usuario administrador

A continuación se creará un susuario administrados para administrar Openstack.

Por defecto el Servicio de Autenticación crea un role especial member. El panel de control de

OpenStack automáticamente permite el acceso a usuarios con este rol. Por tanto, al usuario

administrador, se le deberá dar este rol además del rol de administrador.

NOTA

Cualquier rol que se cree debe ser mapeado a los rolos especificados en el archivo policy.json

incluido en cada servicio de OpenStack. Este fichero tiene por defecto permitir el acceso a los

usuarios que accedan con el rol de administrador.

En primer lugar se crea un usuario admin:

keystone user-create --name=admin --pass=ADMIN_PASS --

email=ADMIN_EMAIL


52

Reemplazar ADMIN_PASS con una contraseña segura y reemplazar ADMIN_EMAIL con

una dirección de correo electrónico que se quiera asociar a la cuenta.

Crear el rol admin:

keystone role-create --name=admin

Crear el inquilino admin:

keystone tenant-create --name=admin --description="Admin Tenant"

Ahora se deben unir el usuario el rol y el inquilino creados anteriormente usando la opción

user-role-add:

keystone user-role-add --user=admin --tenant=admin --role=admin

Por último unir el usuario admin , el rol member, y el inquilino admin:

keystone user-role-add --user=admin --role=_member_ --tenant=admin


Crear un usuario normal

Ahora se creará un usuario e inquilino normales, y uniremos estos al rol especial member.

Esta cuenta será usada para la interacción no administrativa con la nube de OpenStack. Se

puede repetir este procedimiento para crear usuarios de la nube adicionales con diferentes

nombres de usuario y contraseñas. Omitir el paso de creación de inquilino cuando se creen

esos usuarios.

Crear usuario demo:

keystone user-create --name=demo --pass=DEMO_PASS --email=DEMO_EMAIL

Crear el inquilino demo:

keystone tenant-create --name=demo --description="Demo Tenant"

NOTA

No repetir este paso cuando se añadan usuarios adicionales.

Unir el usuario demo, el rol member, y el inquilino demo:

keystone user-role-add --user=demo --role=_member_ --tenant=demo

Crear un inquilino service

Los servicios de OpenStack también requieren de un nombre de usuario, inquilino y rol para

acceder a otros servicios de OpenStack. En una instalación básica, normalmente los servicios

de OpenStack comparten un inquilino simple llamado service.

Por tanto, se crearán nombres de usuario y roles bajo este inquilino cada vez que se instale o

configure un servicio.


54

Crear el inquilino service:

keystone tenant-create --name=service --description="Service Tenant"

Definición de servicios y API de puntos finales (endpoints)

El Servicio de Autenticación puede realizar un seguimiento de qué servicios están instalados y

donde están localizados en la red. Para ello, se debe registrar cada servicio en la instalación de

OpenStack. Para registrar un servicio…

NOTA

keystone service-create: Describe el servicio.

keystone endpoint-create: Asocia la API del punto final (endpoint) con el servicio.

Se debe primero registrar el Servicio de Autenticación. Use las variable de entorno

OS_SERVICE_TOKEN como se configuró previamente para la autenticación.

Crear una entrada de servicio para el Servicio de Identidad:

keystone service-create --name=keystone --type=identity --

description="OpenStack Identity"

El ID de servicio es generado aleatoriamente y será diferente del que se muestra en la imagen

anterior.

Especificar una API endpoint para el Servicio de Autenticación usando el ID de servicio devuelto

en el paso anterior. Cuando se especifica un endpoint, se está provisionando de una URL para la

API pública, API interna, y API de administrador. Se usa controller como URL. Observar que se

usa un puerto diferente para la API de administrador.


keystone endpoint-create --service-id=$(keystone service-list | awk '/

identity / {print $2}')

--publicurl=http://controller:5000/v2.0

--internalurl=http://controller:5000/v2.0

--adminurl=http://controller:35357/v2.0

Verificar la instalación del Servicio de Autenticación

Para verificar que el Servicio de Autenticación se ha instalado y configurado correctamente,

limpiamos los valores asignados a las variables de entornos OS_SERVICE_TOKEN y

OS_SERVICE_ENDPOINT :

unset OS_SERVICE_TOKEN OS_SERVICE_ENDPOINT

Estas variables, que usamos como origen de datos para la creación del usuario admin y para

registrar el Servicio de Autenticación no son necesarias.

Ahora se puede utilizar la autenticación basada en nombre de usuario.

Petición de un token de autenticación usando el usuario admin y la contraseña que se eligió para el:

keystone --os-username=admin --os-password=ADMIN_PASS --os-auth-

url=http://controller:35357/v2.0 token-get


56

En respuesta se recibirá un token asociado a tu ID de usuario (imagen siguiente). Esto verifica que

el Servicio de Autenticación está corriendo en el endpoint esperado y que la cuenta de usuario se ha

establecido con los credenciales esperados.


Ahora se procederá a verificar que la autorización se comporta como se espera. Para hacer eso,

hacemos una petición de autorización en un inquilino

keystone --os-username=admin --os-password=ADMIN_PASS --os-tenant-

name=admin --os-auth-url=http://controller:35357/v2.0

token-get

En respuesta, se recibirá un token que incluye el ID del inquilino que se especificó. Esto verifica

que la cuenta de usuario tiene un rol explicito definido en el inquilino especificado y el inquilino

existe como se esperaba.

También se puede conigurar unas variables –os-* en el entorno para simplificar el uso de la línea

de comandos. Cree un archivo admin-openrc.sh con los credenciales de administrador y el

endpoint del administrador:

export OS_USERNAME=admin

export OS_PASSWORD=ADMIN_PASS

export OS_TENANT_NAME=admin

export OS_AUTH_URL=http://controller:35357/v2.0

Para obtener las variables de entorno de este archivo bastará hacer…

source admin-openrc.sh

Verifique que su archivo admin-openrc.sh está configurado correctamente. Ejecute el mismo

comando pero sin los argumentos –os-*:

keystone token-get

El comando devuelve un token y un ID del inquilino especificado. Esto verifica que se han

configurado correctamente las variables de entorno.


58

Para verificar que la cuanta de administrador tiene autorización para usar los comandos de

administración ejecute:

keystone user-list

Se mostrará por pantalla algo parecido a esto.

keystone user-role-list --user admin --tenant admin

FIN_DE_SCRIPT

Viendo que el ID en la salida del comando keystone user-list coincide con el ID de usuario en el

comando keystone user-role-list, y que el rol de administrador esta listado para ese usuario, para

el inquilino afín, esto verifica que la cuenta de usuario tiene el rol admin, el cual coincide con el

rol usado en el archivo policy.json del Servicio de Autenticación

Clientes Para instalar esta parte, se recomienda usar el script clients.sh, que se puede encontrar en el Anexo E,

ya que no requiere de configuración extra y solo se trata de instalar los clientes de los diversos módulos

de OpenStack mediante yum.


Servicio de Imágenes

Este servicio actúa como un registro para discos de imágenes virtuales. Los usuarios pueden añadir

nuevas imágenes o tomar una instantánea de una imagen de un servidor para un almacenamiento

inmediato.

Se puede usar si se desea el script glance_1.sh, en el Anexo E, para simplificar las cosas (contraseña

por defecto redborder), si no, se puede hacer los siguientes pasos:

Instalación del módulo mediante yum:

yum install openstack-glance python-glanceclient

Configuración de la localización de la base de datos. El servicio de imagen proporciona los

servicios glance-api y glance-registry, cada uno con su propio fichero de configuración:

openstack-config --set /etc/glance/glance-api.conf database connection

mysql://glance:GLANCE_DBPASS@controller/glance

openstack-config --set /etc/glance/glance-registry.conf database

connection mysql://glance:GLANCE_DBPASS@controller/glance

FIN_DE_SCRIPT

Se crea una base de datos del usuario glance:

$ mysql -u root –p

mysql> CREATE DATABASE glance;

mysql> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost'

IDENTIFIED BY 'GLANCE_DBPASS';

mysql> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' IDENTIFIED BY

'GLANCE_DBPASS';

Los siguientes pasos desde aquí hasta el final de la instalación de este módulo se pueden hacer mediante

el script glance_2.sh, situado en el Anexo E, pero con las características por defecto que siempre se han

indicado. Si no se desea esto, pues se sigue con los pasos siguientes:

Creación de las tablas para la base de datos para el servicio de imagen:

su -s /bin/sh -c "glance-manage db_sync" glance


60

Creación de usuario glance y asignación de este al rol de administrador y al inquilino servicio:

keystone user-create --name=glance --pass=GLANCE_PASS --

[email protected]

keystone user-role-add --user=glance --tenant=service --role=admin

Configuracion del servicio de imagen para usar el servicio de autenticación. Para ello se han de ejecutar los siguientes comandos:

openstack-config --set /etc/glance/glance-api.conf keystone_authtoken

auth_uri http://controller:5000


auth_host controller


auth_port 35357


auth_protocol http


admin_tenant_name service


admin_user glance


admin_password GLANCE_PASS

openstack-config --set /etc/glance/glance-api.conf paste_deploy flavor

keystone

openstack-config --set /etc/glance/glance-registry.conf

keystone_authtoken auth_uri http://controller:5000


keystone_authtoken auth_host controller


keystone_authtoken auth_port 35357

mailto:--%20%20%[email protected]

mailto:--%20%20%[email protected]

http://controller:5000/




keystone_authtoken auth_protocol http


keystone_authtoken admin_tenant_name service


keystone_authtoken admin_user glance


keystone_authtoken admin_password GLANCE_PASS

openstack-config --set /etc/glance/glance-registry.conf paste_deploy

flavor keystone

Registrar el servicio de imagen con el servicio de autenticación para que otros servicios de OpenStack

puedan localizarlos:

keystone service-create --name=glance --type=image --description="OpenStack

Image Service";

keystone endpoint-create --service-id=$(keystone service-list | awk '/ image /

{print $2}') --publicurl=http://controller:9292 --

internalurl=http://controller:9292 --adminurl=http://controller:9292;


62

Iniciar los servicios glance-api y glance-registry :

service openstack-glance-api start

service openstack-glance-registry start

chkconfig openstack-glance-api on

chkconfig openstack-glance-registry on

Los pasos para verificar que se ha instalado correctamente este módulo, son los siguientes:

mkdir /tmp/images;

cd /tmp/images/;

wget http://cdn.download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img; se

puede escoger una imagen cualquiera de cualquier web.

source /root/admin-openrc.sh;

glance image-create --name "cirros-0.3.2-x86_64" --disk-format qcow2 --container-

format bare --is-public True --progress < cirros-0.3.2-x86_64-disk.img; los

parámetros se pueden cambiar en función de las necesidades.


glance image-list;

rm -r /tmp/images;

FIN_DE_SCRIPT

Servicio de Computación Este servicio será el encargado de permitir el lanzamiento de instancias de máquinas virtuales. A

continuación se verá como instalar este servicio. Se puede comenzar mediante el script nova_1.sh,

situado en el Anexo E, para hacerlo más simplificado, aunque tendrá ciertos parámetros por defectos

como las contraseñas (todas redborder).

Para una instalación personalizada se han de seguir los siguientes pasos:

Instalación de los paquetes necesarios:

yum install openstack-nova-api openstack-nova-cert openstack-nova-

conductor openstack-nova-console openstack-nova-novncproxy openstack-nova-

scheduler python-novaclient;

La información de computación se guarda en una base de datos. A continuación se configurará

la localización y credenciales de esta:

openstack-config --set /etc/nova/nova.conf database connection

mysql://nova:NOVA_DBPASS@controller/nova

Ahora viene la configuración del servicio de mensajería Qpid:

openstack-config --set /etc/nova/nova.conf DEFAULT rpc_backend qpid

openstack-config --set /etc/nova/nova.conf DEFAULT qpid_hostname controller


64

Y la configuración de my_ip, vncserver_listen y vncserver_proxyclient_address

para gestionar la interfaz del nodo controlador:

openstack-config --set /etc/nova/nova.conf DEFAULT my_ip controller

openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen

controller

openstack-config --set /etc/nova/nova.conf DEFAULT

vncserver_proxyclient_address controller

FIN_DE_SCRIPT

Se crea la base de datos de nova:

$ mysql -u root -p

mysql> CREATE DATABASE nova;

mysql> GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY

'NOVA_DBPASS';

mysql> GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY

'NOVA_DBPASS';

mysql> exit;

A continuación se puede continuar toda la instalación mediante el script nova_2.sh, situado en

el Anexo E, con los parámetros por defecto de siempre. Si se desea una instalación

personalizada se han de seguir los pasos siguientes.

Creación de las tablas de la BBDD de nova:

su -s /bin/sh -c "nova-manage db sync" nova;

Ahora se creará un usuario nova que el módulo de computación use para autenticarse con

Keystone. Usa el inquilino servicio y se le dará el rol de admin:

keystone user-create --name=nova --pass=NOVA_PASS [email protected]

keystone user-role-add --user=nova --tenant=service --role=admin

mailto:[email protected]


Configuración del módulo para usar esos credenciales con el servicio de identidad corriendo en el

nodo controlador:

openstack-config --set /etc/nova/nova.conf DEFAULT auth_strategy keystone;

openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_uri

http://controller:5000;

openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_host

controller;

openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_protocol

http;

openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_port

35357;

openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_user

nova;

openstack-config --set /etc/nova/nova.conf keystone_authtoken

admin_tenant_name service;

openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_password

NOVA_PASS;

Se ha de registrar el servicio de computación con el servicio de identidad para que otros

servicios de OpenStack puedan localizarlo. A continuación se registrará el servicio y un endpoint

específico:

keystone service-create --name=nova --type=compute --

description="OpenStack Compute";


66

keystone endpoint-create --service-id=$(keystone service-list | awk '/

compute / {print $2}') --

publicurl=http://controller:8774/v2/%$tenant_id$s

--internalurl=http://controller:8774/v2/%$tenant_id$s

--adminurl=http://controller:8774/v2/%$tenant_id$s;

Por último se inician todos los servicios necesarios y se configuran para que arranquen al iniciar

el sistema:

service openstack-nova-api start;

service openstack-nova-cert start;

service openstack-nova-consoleauth start;

service openstack-nova-scheduler start;

service openstack-nova-conductor start;

service openstack-nova-novncproxy start;

chkconfig openstack-nova-api on;

chkconfig openstack-nova-cert on;

chkconfig openstack-nova-consoleauth on;

chkconfig openstack-nova-scheduler on;

chkconfig openstack-nova-conductor on;

chkconfig openstack-nova-novncproxy on;


Para terminar y verificar la instalación, se listarán las imágenes disponibles y debe salir algo

parecido a lo siguiente:

FIN_DE_SCRIPT

Servicio de Red

Antes de nada se ha de crear la BBDD para este módulo:

$ mysql -u root –p

mysql> CREATE DATABASE neutron;

mysql> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' IDENTIFIED

BY 'NEUTRON_DBPASS';

mysql> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' IDENTIFIED BY

'NEUTRON_DBPASS';

A partir de este punto se puede usar el script neutron_1.sh, disponible en el Anexo E, para una

instalación más rápida y general. SI se desea una instalación más personalizada con contraseñas

propias, se han seguir las siguientes instrucciones.

Ahora se ha de crear el usuario neutron:

keystone user-create --name neutron --pass NEUTRON_PASS --email

[email protected]

mailto:[email protected]


68

Asociar el usuario neutron al inquilino servicio y al rol admin:

keystone user-role-add --user neutron --tenant service --role admin

Crear el servicio neutron:

keystone service-create --name neutron --type network –-description "OpenStack

Networking"

Creación del endpoint del servicio:

keystone endpoint-create --service-id $(keystone service-list | awk '/ network

/ {print $2}')

--publicurl http://controller:9696

--adminurl http://controller:9696

--internalurl http://controller:9696

Una vez creados los usuarios y demás, se procederá a instalar los componentes de red

yum install openstack-neutron openstack-neutron-ml2 python-neutronclient

A continuación se procederá a configurar los componentes del servidor de red.

En primer lugar, se debe configurar al servicio de red para usar la base de datos localizada en el

nodo controlador y con una contraseña especifica:

openstack-config --set /etc/neutron/neutron.conf database connection

mysql://neutron:NEUTRON_DBPASS@controller/neutron




Configuración del servicio de red para usar el servicio de autenticación para autenticarse:

openstack-config --set /etc/neutron/neutron.conf DEFAULT auth_strategy

keystone

openstack-config --set /etc/neutron/neutron.conf keystone_authtoken auth_uri

http://controller:5000

openstack-config --set /etc/neutron/neutron.conf keystone_authtoken



auth_protocol http


auth_port 35357




admin_user neutron


admin_password NEUTRON_PASS

Ahora se configura el servicio de red para que utiliza el servicio de mensajería Qpid:

openstack-config --set /etc/neutron/neutron.conf DEFAULT rpc_backend

neutron.openstack.common.rpc.impl_qpid

openstack-config --set /etc/neutron/neutron.conf DEFAULT qpid_hostname

controller

Configurar el servicio de red para notificar al servicio de computación sobre los cambios en la

topología:

openstack-config --set /etc/neutron/neutron.conf DEFAULT

notify_nova_on_port_status_changes True


notify_nova_on_port_data_changes True

openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_url

http://controller:8774/v2

openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_admin_username

nova



70


nova_admin_tenant_id $(keystone tenant-list | awk '/ service / { print $2

}')

openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_admin_password

NOVA_PASS

openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_admin_auth_url

http://controller:35357/v2.0

A continuación se configurará el servicio de red para usar un plug-in de módulo de capada 2 y

asociarle servicios:

openstack-config --set /etc/neutron/neutron.conf DEFAULT core_plugin ml2

openstack-config --set /etc/neutron/neutron.conf DEFAULT service_plugins

router

Configuracion de plug-in de ML2 (Modular Layer 2). Este plug-in usa el mecanismo (agente)

Open vSwitch (OVS) para construir la estructura de las redes virtuales para las intancias. Sin

embargo, el nodo controlador no necesita el agente OVS porque no tiene que manejar el tráfico

de red de las instancias:

openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2

type_drivers gre


tenant_network_types gre


mechanism_drivers openvswitch

openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini

ml2_type_gre tunnel_id_ranges 1:1000


securitygroup firewall_driver neutron.agent.linux.iptables_firewall.

OVSHybridIptablesFirewallDriver


securitygroup enable_security_group True

Debido al modo de distribución usado (neutron-compute), se ha de reconfigurar el servicio de

computación para gestionar las redes a través del servicio de red.

openstack-config --set /etc/nova/nova.conf DEFAULT network_api_class

nova.network.neutronv2.api.API


openstack-config --set /etc/nova/nova.conf DEFAULT neutron_url


openstack-config --set /etc/nova/nova.conf DEFAULT neutron_auth_strategy

keystone

openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_tenant_name

service

openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_username

neutron

openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_password

NEUTRON_PASS

openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_auth_url


openstack-config --set /etc/nova/nova.conf DEFAULT linuxnet_interface_driver

nova.network.linux_net.LinuxOVSInterfaceDriver

openstack-config --set /etc/nova/nova.conf DEFAULT firewall_driver

nova.virt.firewall.NoopFirewallDriver

openstack-config --set /etc/nova/nova.conf DEFAULT security_group_api neutron

Para finalizar la instalación, los scripts de iniciación del servicio de red esperan un enlace simbólico

/etc/neutron/plugin.ini apuntando al fichero de configuración asociado con el plug-in

elegido. Usando ML2, por ejemplo, el enlace simbólico debe apuntar a /etc/neutron/plugins/ml2/ml2_conf.ini.

ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini

Reiniciar los servicios de computación:

service openstack-nova-api restart

service openstack-nova-scheduler restart

service openstack-nova-conductor restart

Iniciar el servicio de red y configurarlo para que empiece cuando el sistema inicia:

servi

ce neutron-server start

chkconfig neutron-server on

FIN_DE_SCRIPT




72

Servicio de Dashboard

Este servicio instalará el panel de control, es decir, la interfaz gráfica que ayudará a la gestión de

OpenStack

En primer lugar se instalarán los paquetes necesarios:

yum install memcached python-memcached mod_wsgi openstack-dashboard

Posteriormente se han de configurar algunos parámetros del fichero /etc/openstack-

dashboard/local_settings para permitir todos los hosts y poner el host de

OpenStack en el nodo controlador:

ALLOWED_HOSTS = [‘*’]

OPENSTACK_HOST = "controller"

También se modificará el valor de CACHES['default']['LOCATION']

en /etc/openstack-dashboard/local_settings para que coincida con lo mostrado en

/etc/sysconfig/memcached.

CACHES = {

'default': {

'BACKEND' : 'django.core.cache.backends.memcached.MemcachedCache',

'LOCATION' : '127.0.0.1:11211'

}

}

Ahora habrá que asegurarse que la política SELinux del sistema está configurada para permitir las

conexiones de red hacia el servidor HTTP:

setsebool -P httpd_can_network_connect on

Por ultimo se iniciará el servidor apache y el servicio de memcache:

service httpd start

service memcached start

chkconfig httpd on

chkconfig memcached on

Ya se podra accede al dashboard en http://10.0.150.100/dashboard

73

ANEXO B: INSTALACIÓN EN NODO DE RED




hacerlo:







yum -y install ntp


chkconfig ntpd on;

yum -y install MySQL-python;

Si se prefiere se puede ejecutar el script config_red_network.sh que aparece en el Anexo F.





Anexo B: Instalación en Nodo de Red

74






Y se comprueba….



ntpq –np


Database

La mayoría de servicios de OpenStack requieren una base de datos para guardar información.

Para ello se debe instalar la librería de MySQL Python en los nodos no controller. Ya realizado en el script.

OpenStack packages




Si se quiere recurrir a una instalación ya con una configuración predeterminada se puede ejecutar el

script packages.sh del Anexo E.








yum install http://repos.fedorapeople.org/repos/openstack/openstack- icehouse/rdo-release-





Por ejemplo:












yum upgrade

FIN_DE_SCRIPT


reboot


http://dl.fe/




76


En este equipo solo se instalará el módulo de red puesto que esa es su función

Servicio de Red

Antes de configurar este servicio es necesario habilitar ciertas funciones de red del kernel. Para ello se

ha de editar el fichero /etc/sysctl.conf para que contenga lo siguiente:

net.ipv4.ip_forward=1

net.ipv4.conf.all.rp_filter=0

net.ipv4.conf.default.rp_filter=0

Para implementar los cambios se ha de escribir en el terminal:

sysctl -p

A partir de este momento se puede ejecutar el script neutron_network.sh, disponible en el Anexo F,

aunque se hará con una configuración general donde las contraseñas serán redborder y la IP de túnel

será 10.0.152.101. Si se desea una instalación más compleja y personalizada, se ha seguir con los

pasos descritos a continuación.

A continuación se instalaran los componentes del servicio de red:

yum install openstack-neutron openstack-neutron-ml2 openstack-neutron-

openvswitch

Ahora se instalarán los componentes más comunes del servicio de red. La configuración de estos

componentes incluyen el mecanismo de autenticación, el servicio de mensajería y los plug-ins.

Para ello se han de escribir las siguientes líneas:


keystone






auth_protocol http


auth_port 35357




admin_user neutrón








controller



router

Ahora se procederá a configurar el agente de capa 3 (L3). Este agente proporciona servicios de

encaminamiento para instanciar redes virtuales.

Se ejecutarán los siguientes comandos:

openstack-config --set /etc/neutron/l3_agent.ini DEFAULT interface_driver

neutron.agent.linux.interface.OVSInterfaceDriver

openstack-config --set /etc/neutron/l3_agent.ini DEFAULT use_namespaces True

Ahora se configurará el agente DHCP. Este agente proporciona servicios de DHCP para instanciar

redes virtuales:

openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT interface_driver

neutron.agent.linux.interface.OVSInterfaceDriver

openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT dhcp_driver

neutron.agent.linux.dhcp.Dnsmasq

openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT use_namespaces

True

A continuación se procederá a configurar el agente de metadatos, el cual proporciona información de

configuración como por ejemplo los credenciales para el acceso remoto a instancias.

En primer lugar se ha de ejecutar los siguientes comandos reemplazando las contraseñas por una que

se desee.

openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT auth_url


openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT auth_region

regionOne

openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT


openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT admin_user

neutrón



78




nova_metadata_ip controller


metadata_proxy_shared_secret METADATA_SECRET

LOS SIGUIENTES DOS PASOS SE HAN DE REALIZAR EN EL NODO CONTROLADOR

1. Configurar el servicio de computación para usar el servicio de metadatos


service_neutron_metadata_proxy true


neutron_metadata_proxy_shared_secret METADATA_SECRET

2. Reiniciar el la API del servicio de computación:

service openstack-nova-api restart

Ahora se configurará el plug-in de modulos de capa 2 (ML2). El plug-in ML2 usa el mecanismo OVS

para construir la estructura de encaminamiento virtual para las instancias.

Ejecutar los siguientes comandos:


type_drivers gre







openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs local_ip

INSTANCE_TUNNELS_INTERFACE_IP_ADDRESS

openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs

tunnel_type gre


enable_tunneling True







Configuración del servicio Open vSwitch (OVS). Este servicio proporciona la estructura de la capa

inferior del encaminamiento virtual para las instancias. El puente de integración br-int maneja el

tráfico de red interno a la instancia con OVS. El puente exterior br-ex maneja el tráfico de red externo

a la instancia con OVS. El puente exterior requiere un puerto en la interfaz física de la red externa

para proporcionar instancias con acceso a la red externa. En general, este puente une las redes externa

e internas en el entorno donde está instalado OpenStack

En primer lugar se ha de iniciar el servicio OVS y configurarlo para que se inicie al iniciar el sistema

operativo:

service openvswitch start

chkconfig openvswitch on

Se añade el puente de integración:

ovs-vsctl add-br br-int

Se añade el puerto externo:

ovs-vsctl add-br br-ex

Se añade un puerto al puente externos que conecta la interfaz física de la red externa. Sustituir

INTERFACE_NAME con el nombre actual de esta interfaz:

ovs-vsctl add-port br-ex INTERFACE_NAME





Debido a un bug de empaquetado, el script de iniciación del agente de OVS busca explícitamente el

fichero de configuración del plug-in de OVS antes que un enlace simbólico

/etc/neutron/plugin.ini apuntando al fichero de configuración del plug-in de ML2. Se han

de ejecutar los siguientes comandos para resolver esto:

cp /etc/init.d/neutron-openvswitch-agent /etc/init.d/neutronopenvswitch-

agent.orig


80

sed -i's,plugins/openvswitch/ovs_neutron_plugin.ini,plugin.ini,g'

/etc/init.d/neutron-openvswitch-agent

Por último, ser inician los servicios de red y se configuran para que empiecen al iniciar el

sistema.

service neutron-openvswitch-agent start;

service neutron-l3-agent start;

service neutron-dhcp-agent start;

service neutron-metadata-agent start;

chkconfig neutron-openvswitch-agent on;

chkconfig neutron-l3-agent on;

chkconfig neutron-dhcp-agent on;

chkconfig neutron-metadata-agent on;

FIN_DE_SCRIPT

81

ANEXO C: INSTALACIÓN EN NODO COMPUTE




hacerlo:







yum -y install ntp


chkconfig ntpd on;


Si se prefiere se puede ejecutar el script config_red_network.sh que aparece en el Anexo F.



El hecho de que se numeren de esa forma os ficheros de configuración de las interfaces es, porque al ser el nodo

compute un equipo físico y tener solo una interfaz de red, se han virtualizando dos interfaces teniendo realmente

una física.

Fichero /etc/sysconfig/network-scripts/ifcfg-eth0.151

Anexo C: Instalación en Nodo Compute

82

Fichero /etc/sysconfig/network-scripts/ifcfg-eth0.152





Y se comprueba….



ntpq –np


Database

La mayoría de servicios de OpenStack requieren una base de datos para guardar información.

Para ello se debe instalar la librería de MySQL Python en los nodos no controller. Ya realizado en el script.


OpenStack packages



Si se quiere recurrir a una instalación ya con una configuración predeterminada se puede ejecutar el script

packages.sh del Anexo E.








yum install http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-





Por ejemplo:












yum upgrade

FIN_DE_SCRIPT


reboot

http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-

http://dl.fe/




84


En este nodo solo se instalan el servicio de computación y el de red.

Servicio de Computación El servicio de computación delega en un hypervisor para correr instancias de máquinas virtuales.

OpenStack puede usar varios hypervisores, pero esta guía usa KVM. Se puede instalar mediante el

script nova_compute.sh, que se puede encontrar en el Anexo G, para hacerlo más simplificado, aunque

tendrá ciertos parámetros por defectos como las contraseñas (todas redborder).

Para una instalación personalizada se han de seguir los siguientes pasos.

En primer lugar se han de instalar los paquetes del servicio de computación:

yum install openstack-nova-compute

A continuación se editará el fichero de configuración /etc/nova/nova.conf:


mysql://nova:NOVA_DBPASS@controller/nova

openstack-config --set /etc/nova/nova.conf DEFAULT auth_strategy

keystone

openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_uri





auth_protocol http


auth_port 35357


admin_user nova




admin_password NOVA_PASS

Configuración del servicio de computación para usar el servicio de mensajería Qpid a través de las

siguientes características de configuración:

openstack-config --set /etc/nova/nova.conf DEFAULT rpc_backend qpid

openstack-config --set /etc/nova/nova.conf DEFAULT qpid_hostname

controller



Configuración del servicio de computación para proporcionar acceso remoto mediante consola a las

instancias.

openstack-config --set /etc/nova/nova.conf DEFAULT my_ip compute

openstack-config --set /etc/nova/nova.conf DEFAULT vnc_enabled True


0.0.0.0


vncserver_proxyclient_address compute


novncproxy_base_url http://controller:6080/vnc_auto.html

Ahora se especificará el equipo que ejecuta el servicio de imágenes:

openstack-config --set /etc/nova/nova.conf DEFAULT glance_host

controller

Si el resultado del siguiente comando

egrep -c '(vmx|svm)' /proc/cpuinfo

devuelve un valor mayor que uno, sáltese el paso siguiente

openstack-config --set /etc/nova/nova.conf libvirt virt_type qemu

Por último se han de reiniciar los servicios y configurarlos para que se inicien al iniciar el sistema:

service libvirtd start;

service messagebus start;

service openstack-nova-compute start;

chkconfig libvirtd on;

chkconfig messagebus on;

chkconfig openstack-nova-compute on;

FIN_DE_SCRIPT

Servicio de Red

Antes de configurar este servicio es necesario habilitar ciertas funciones de red del kernel. Para ello se

ha de editar el fichero /etc/sysctl.conf para que contenga lo siguiente:

net.ipv4.conf.all.rp_filter=0

net.ipv4.conf.default.rp_filter=0

http://controller:6080/vnc_auto.html


86

Para implementar los cambios se ha de escribir en el terminal:

sysctl -p

A partir de este momento se puede ejecutar el script neutron_compute.sh, disponible en el Anexo G,

aunque se hará con una configuración general donde las contraseñas serán redborder y la IP de túnel

será 10.0.152.102. Si se desea una instalación más compleja y personalizada, se ha seguir con los pasos

descritos a continuación.

A continuación se instalaran los componentes del servicio de red:

yum install openstack-neutron openstack-neutron-ml2 openstack-neutron-

openvswitch

Ahora se instalarán los componentes más comunes del servicio de red. La configuración de estos

componentes incluyen el mecanismo de autenticación, el servicio de mensajería y los plug-ins.

Para ello se han de escribir las siguientes líneas:


keystone






auth_protocol http


auth_port 35357




admin_user neutrón






controller



router



Ahora se configurará el plug-in de modulos de capa 2 (ML2). El plug-in ML2 usa el mecanismo OVS

para construir la estructura de encaminamiento virtual para las instancias.

Ejecutar los siguientes comandos:


type_drivers gre







openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs local_ip

INSTANCE_TUNNELS_INTERFACE_IP_ADDRESS


tunnel_type gre


enable_tunneling True






Configuración del servicio Open vSwitch (OVS). Este servicio proporciona la estructura de la capa

inferior del encaminamiento virtual para las instancias. El puente de integración br-int maneja el

tráfico de red interno a la instancia con OVS. En primer lugar se ha de iniciar el servicio OVS y

configurarlo para que se inicie al iniciar el sistema operativo:

service openvswitch start

chkconfig openvswitch on

Se añade el puente de integración:

ovs-vsctl add-br br-int

Debido al modo de distribución usado (neutron-compute), se ha de reconfigurar el servicio de

computación para gestionar las redes a través del servicio de red.

openstack-config --set /etc/nova/nova.conf DEFAULT network_api_class

nova.network.neutronv2.api.API


88



openstack-config --set /etc/nova/nova.conf DEFAULT neutron_auth_strategy

keystone

openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_tenant_name

service

openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_username

neutron

openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_password

NEUTRON_PASS

openstack-config --set /etc/nova/nova.conf DEFAULT neutron_admin_auth_url


openstack-config --set /etc/nova/nova.conf DEFAULT linuxnet_interface_driver

nova.network.linux_net.LinuxOVSInterfaceDriver


nova.virt.firewall.NoopFirewallDriver

openstack-config --set /etc/nova/nova.conf DEFAULT security_group_api neutron





Debido a un bug de empaquetado, el script de iniciación del agente de OVS busca explícitamente el

fichero de configuración del plug-in de OVS antes que un enlace simbólico

/etc/neutron/plugin.ini apuntando al fichero de configuración del plug-in de ML2. Se han

de ejecutar los siguientes comandos para resolver esto:

cp /etc/init.d/neutron-openvswitch-agent /etc/init.d/neutronopenvswitch-

agent.orig

sed -i's,plugins/openvswitch/ovs_neutron_plugin.ini,plugin.ini,g'

/etc/init.d/neutron-openvswitch-agent

Se reinicia el servicio de computación:

service openstack-nova-compute restart




Se inicia el agente de OVS y se configura para que este se inicie cuando inicie el sistema:

service neutron-openvswitch-agent start chkconfig neutron-openvswitch-agent on

FIN_DE_SCRIPT


90

91

ANÉXO D: INSTALACIÓN Y CASOS DE USO DE CHEF

Este anexo explicará cómo instalar todos los componentes de Chef necesarios para poder integrarlo

de una manera funcionalmente completa con OpenStack.

Para ello se precisan ciertos prerrequisitos:

Tener configurado completamente un hostname.

Tener configurada una entrada en el DNS.

Tener ciertos paquetes instalados:

o yum install wget curl –y

Instalación de Chef Server

A continuación se procederá a la xplicacion de la instalación del servidor de Chef. Para ello se han

de realizar los siguientes pasos.

rpm -ivh https://opscode-omnibus-

packages.s3.amazonaws.com/el/6/x86_64/chef-server-11.1.4-

1.el6.x86_64.rpm

Una vez ya instalado el servidor de Chef, se ha de configurar ejecutando el siguiente comando:

chef-server-ctl reconfigure

El comando chef-server-ctl configurará los componentes requeridos, incluyendo Erchef, RabbitMQ,

PostgreSQL, y todos los cookbooks que serán usados por Chef para mantener el Servidor de Chef 11.x.

Por último verificar la instalación del servidor de Chef mediante el siguiente comando:

chef-server-ctl test

Instalacion de plug-in knife para openstack

Este plug-in da a knife la capacidad de gestionar y crear instancias en la nubesde OpenStack.

Para ello, primero se ha comprobar que se esta corriendo en el host la última versión de Chef, puesto que para

versiones anteriores a la 10, este plug-in no funciona.

gem install chef

Este plug-in es distribuido como una Gema de Ruby, por tanto para instalarlo hay que hacer lo siguiente:

gem install knife-openstack

https://opscode-omnibus-packages.s3.amazonaws.com/el/6/x86_64/chef-

https://opscode-omnibus-packages.s3.amazonaws.com/el/6/x86_64/chef-

Anéxo D: Instalación y Casos de Uso de Chef

92

Configuración

Para poder comunicarse con la API de OpenStack, se necesita decirle a Knife el endpoint de la API de

Autenticacion de OpenStack y los credenciales del dashboard. La manera mas fácil de hacerlo es creando la

siguiente entrada en el fichero knife.rb:

Ejemplo de Uso

Para lanzar una instancia mediante Knife se ha realizado una sentencia de ejemplo:

knife openstack server create -A 'demo' -K 'redborder' -T 'demo' --

openstack-api-endpoint 'http://controller:8774/v2/%(tenant_id)s' -f 1 –I

2cf8e04b-4a3b-4321-8cf6-ee7f6-ee711e81beec --network-ids dadc70d3-f8e1-

45f3-92b6-7fd7351c8324 -r 'role[_member_]';

Con la anterior línea se está instanciando con el usuario demo, contraseña redborder e inquilino demo la

imagen 2cf8e04b-4a3b-4321-8cf6-ee7f6-ee711e81beec con el sabor 1, en la red dadc70d3-f8e1-45f3-92b6-

7fd7351c8324 con el role member y un endponint de la API en 'http://controller:8774/v2/%(tenant_id)s'.

knife[:openstack_auth_url]= http://controller:5000/v2.0/tokens"

knife[:openstack_username] = "admin"

knife[:openstack_password] = "redborder"

knife[:openstack_tenant] = "admin”

93

ANÉXO E: SCRIPTS DEL NODO CONTROLADOR

config_red.sh

packages.sh

service NetworkManager stop;

service network restart;

chkconfig NetworkManager off;

chkconfig network on;

service iptables restart;

chkconfig iptables on;

yum -y install ntp;

service ntpd restart;

chkconfig ntpd on;

yum -y install yum-plugin-priorities;

yum -y install


icehouse/rdo-release-icehouse-3.noarch.rpm;

yum -y install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-

release-6-8.noarch.rpm;

yum -y install openstack-utils;

yum -y install openstack-utils;

yum -y upgrade;

Anéxo E: Scripts del Nodo Controlador

94

keystone_1.sh

keystone_2.sh

yum install -y openstack-keystone python-keystoneclient;

openstack-config --set /etc/keystone/keystone.conf database

connection mysql://keystone:redborder@controller/keystone;

su -s /bin/sh -c "keystone-manage db_sync" keystone;

ADMIN_TOKEN=redborder;

echo $ADMIN_TOKEN;

openstack-config --set /etc/keystone/keystone.conf DEFAULT

admin_token $ADMIN_TOKEN;

keystone-manage pki_setup --keystone-user keystone --keystone-

group keystone;

chown -R keystone:keystone /etc/keystone/ssl;

chmod -R o-rwx /etc/keystone/ssl;

service openstack-keystone start;

chkconfig openstack-keystone on;

export OS_SERVICE_TOKEN=$ADMIN_TOKEN;

export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0;

keystone user-create --name=admin --pass=redborder --

[email protected]

keystone role-create --name=admin;

keystone tenant-create --name=admin --description="Admin Tenant";

keystone user-role-add --user=admin --tenant=admin --role=admin;

keystone user-role-add --user=admin --role=_member_ --

tenant=admin;

keystone user-create --name=demo --pass=redborder --

[email protected];


keystone tenant-create --name=demo --description="Demo Tenant";

keystone user-role-add --user=demo --role=_member_ --tenant=demo;

keystone tenant-create --name=service --description="Service

Tenant";

keystone service-create --name=keystone --type=identity --

description="OpenStack Identity";

keystone endpoint-create --service-id=$(keystone service-list | awk

'/ identity / {print $2}') --publicurl=http://controller:5000/v2.0

--internalurl=http://controller:5000/v2.0 --

adminurl=http://controller:35357/v2.0;

unset OS_SERVICE_TOKEN OS_SERVICE_ENDPOINT;

keystone --os-username=admin --os-password=redborder --os-auth-

url=http://controller:35357/v2.0 token-get;

keystone --os-username=admin --os-password=redborder --os-tenant-

name=admin --os-auth-url=http://controller:35357/v2.0 token-get;

echo "export OS_USERNAME=admin" >> admin-openrc.sh;

echo "export OS_PASSWORD=redborder" >> admin-openrc.sh;

echo "export OS_TENANT_NAME=admin" >> admin-openrc.sh;

echo "export OS_AUTH_URL=http://controller:35357/v2.0" >> admin-

openrc.sh;

echo "export OS_USERNAME=demo" >> demo-openrc.sh;

echo "export OS_PASSWORD=redborder" >> demo-openrc.sh;

echo "export OS_TENANT_NAME=demo" >> demo-openrc.sh;

echo "export OS_AUTH_URL=http://controller:35357/v2.0" >> demo-

openrc.sh;

source admin-openrc.sh;

keystone token-get;

keystone user-list;

keystone user-role-list --user admin --tenant admin;


96

clients.sh

glance_1.sh

yum -y install python-ceilometerclient;

yum -y install python-cinderclient;

yum -y install python-glanceclient;

yum -y install python-heatclient;

yum -y install python-keystoneclient;

yum -y install python-neutronclient;

yum -y install python-novaclient;

yum -y install python-swiftclient;

yum -y install python-troveclient;

yum install openstack-glance python-glanceclient;

openstack-config --set /etc/glance/glance-api.conf database

connection mysql://glance:redborder@controller/glance;


database connection

mysql://glance:redborder@controller/glance;

openstack-config --set /etc/glance/glance-api.conf DEFAULT

rpc_backend qpid;

openstack-config --set /etc/glance/glance-api.conf DEFAULT

qpid_hostname controller;


glance_2.sh

su -s /bin/sh -c "glance-manage db_sync" glance;

keystone user-create --name=glance --pass=redborder --

[email protected];

keystone user-role-add --user=glance --tenant=service --

role=admin;

openstack-config --set /etc/glance/glance-api.conf

keystone_authtoken auth_uri http://controller:5000;


keystone_authtoken auth_host controller;


keystone_authtoken auth_port 35357;


keystone_authtoken auth_protocol http;


keystone_authtoken admin_tenant_name service;


keystone_authtoken admin_user glance;


keystone_authtoken admin_password redborder;


paste_deploy flavor keystone;










98




keystone_authtoken admin_user glance;




paste_deploy flavor keystone;

keystone service-create --name=glance --type=image --

description="OpenStack Image Service";

keystone endpoint-create --service-id=$(keystone service-

list | awk '/ image / {print $2}') --

publicurl=http://controller:9292 --

internalurl=http://controller:9292 --

adminurl=http://controller:9292;

service openstack-glance-api start;

service openstack-glance-registry start;

chkconfig openstack-glance-api on;

chkconfig openstack-glance-registry on;

mkdir /tmp/images;

cd /tmp/images/;

wget http://cdn.download.cirros-cloud.net/0.3.2/cirros-

0.3.2-x86_64-disk.img;

source /root/admin-openrc.sh;

glance image-create --name "cirros-0.3.2-x86_64" --disk-

format qcow2 --container-format bare --is-public True --

progress < cirros-0.3.2-x86_64-disk.img;

glance image-list;

rm -r /tmp/images;


nova_1.sh

nova_2.sh

yum -y install openstack-nova-api openstack-nova-cert

openstack-nova-conductor openstack-nova-console openstack-

nova-novncproxy openstack-nova-scheduler python-novaclient;

openstack-config --set /etc/nova/nova.conf database

connection mysql://nova:redborder@controller/nova;


rpc_backend qpid;



openstack-config --set /etc/nova/nova.conf DEFAULT my_ip

controller;


vncserver_listen controller;


vncserver_proxyclient_address controller;

su -s /bin/sh -c "nova-manage db sync" nova;

keystone user-create --name=nova --pass=redborder --

[email protected];

keystone user-role-add --user=nova --tenant=service --

role=admin;


auth_strategy keystone;

openstack-config --set /etc/nova/nova.conf









keystone_authtoken admin_user nova;




100


auth_port 35357;


admin_user nova;





keystone service-create --name=nova --type=compute --

description="OpenStack Compute";

keystone endpoint-create --service-id=$(keystone service-

list | awk '/ compute / {print $2}') --

publicurl=http://controller:8774/v2/%$tenant_id$s --

internalurl=http://controller:8774/v2/%$tenant_id$s --

adminurl=http://controller:8774/v2/%$tenant_id$s;

service openstack-nova-api start;

service openstack-nova-cert start;

service openstack-nova-consoleauth start;

service openstack-nova-scheduler start;

service openstack-nova-conductor start;

service openstack-nova-novncproxy start;

chkconfig openstack-nova-api on;

chkconfig openstack-nova-cert on;

chkconfig openstack-nova-consoleauth on;

chkconfig openstack-nova-scheduler on;

chkconfig openstack-nova-conductor on;

chkconfig openstack-nova-novncproxy on;

nova image-list;


neutron_1.sh

keystone user-create --name neutron --pass redborder --email

[email protected];

keystone user-role-add --user neutron --tenant service --

role admin;

keystone service-create --name neutron --type network --

description "OpenStack Networking";

keystone endpoint-create --service-id $(keystone service-

list | awk '/ network / {print $2}') --publicurl

http://controller:9696 --adminurl http://controller:9696 --

internalurl http://controller:9696;

yum -y install openstack-neutron openstack-neutron-ml2

python-neutronclient;

openstack-config --set /etc/neutron/neutron.conf database

connection mysql://neutron:redborder@controller/neutron;



openstack-config --set /etc/neutron/neutron.conf











keystone_authtoken admin_user neutron;




rpc_backend neutron.openstack.common.rpc.impl_qpid;






102


notify_nova_on_port_status_changes True;


notify_nova_on_port_data_changes True;


nova_url http://controller:8774/v2;


nova_admin_username nova;


nova_admin_tenant_id $(keystone tenant-list | awk '/ service

/ { print $2 }');


nova_admin_password redborder;


nova_admin_auth_url http://controller:35357/v2.0;


core_plugin ml2;


service_plugins router;


ml2 type_drivers gre;


ml2 tenant_network_types gre;


ml2 mechanism_drivers openvswitch


ml2_type_gre tunnel_id_ranges 1:1000;


securitygroup firewall_driver

neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirew

allDriver;



securitygroup enable_security_group True;


network_api_class nova.network.neutronv2.api.API;


neutron_url http://controller:9696;


neutron_auth_strategy keystone;


neutron_admin_tenant_name service;


neutron_admin_username neutron;


neutron_admin_password redborder;


neutron_admin_auth_url http://controller:35357/v2.0;


linuxnet_interface_driver

nova.network.linux_net.LinuxOVSInterfaceDriver;


firewall_driver nova.virt.firewall.NoopFirewallDriver;


security_group_api neutron;

ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini;

service openstack-nova-api restart;

service openstack-nova-scheduler restart;

service openstack-nova-conductor restart;

service neutron-server start;

chkconfig neutron-server on;


104

105

ANÉXO F: SCRIPTS DEL NODO DE RED

config_red_network.sh

neutron_network.sh

service NetworkManager stop;

service network restart;

chkconfig NetworkManager off;

chkconfig network on;

service iptables restart;

chkconfig iptables on;

yum -y install ntp;

service ntpd restart;

chkconfig ntpd on;


yum -y install openstack-neutron openstack-neutron-ml2 openstack-

neutron-openvswitch;

















Anéxo F: Scripts del Nodo de Red

106






core_plugin ml2;



openstack-config --set /etc/neutron/l3_agent.ini DEFAULT

interface_driver neutron.agent.linux.interface.OVSInterfaceDriver;


use_namespaces True;

openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT



dhcp_driver neutron.agent.linux.dhcp.Dnsmasq;




auth_url http://controller:5000/v2.0;


auth_region regionOne;




admin_user neutron;


admin_password redborder;


nova_metadata_ip controller;


metadata_proxy_shared_secret redborder;







core_plugin ml2;










dhcp_driver neutron.agent.linux.dhcp.Dnsmasq;




auth_url http://controller:5000/v2.0;


auth_region regionOne;




admin_user neutron;




nova_metadata_ip controller;


metadata_proxy_shared_secret redborder;

Anéxo F: Scripts del Nodo de Red

108


type_drivers gre;


tenant_network_types gre;


mechanism_drivers openvswitch;




local_ip 10.0.152.101;


tunnel_type gre;


enable_tunneling True;



neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDri

ver;



service openvswitch start;

chkconfig openvswitch on;

ovs-vsctl add-br br-int;

ovs-vsctl add-br br-ex;

ovs-vsctl add-port br-ex eth2;


cp /etc/init.d/neutron-openvswitch-agent /etc/init.d/neutron-

openvswitch-agent.orig;

sed -i 's,plugins/openvswitch/ovs_neutron_plugin.ini,plugin.ini,g'

/etc/init.d/neutron-openvswitch-agent;

service neutron-openvswitch-agent start;

service neutron-l3-agent start;

service neutron-dhcp-agent start;

service neutron-metadata-agent start;


chkconfig neutron-l3-agent on;

chkconfig neutron-dhcp-agent on;

chkconfig neutron-metadata-agent on;

109

ANÉXO G: SCRIPTS DEL NODO COMPUTE

neutron_compute.sh

yum -y install openstack-neutron-ml2 openstack-neutron-

openvswitch;






















core_plugin ml2;




type_drivers gre;


tenant_network_types gre;


mechanism_drivers openvswitch;



Anéxo G: Scripts del Nodo Compute

110


local_ip 10.0.152.102;


tunnel_type gre;


enable_tunneling True;



neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDri

ver;



service openvswitch restart;

chkconfig openvswitch on;

ovs-vsctl add-br br-int;


network_api_class nova.network.neutronv2.api.API;


http://controller:9696;


neutron_auth_strategy keystone;


neutron_admin_tenant_name service;


neutron_admin_username neutron;


neutron_admin_password redborder;


neutron_admin_auth_url http://controller:35357/v2.0;


linuxnet_interface_driver

nova.network.linux_net.LinuxOVSInterfaceDriver;


nova.virt.firewall.NoopFirewallDriver;


security_group_api neutron;


nova_compute.sh


cp /etc/init.d/neutron-openvswitch-agent /etc/init.d/neutron-

openvswitch-agent.orig;

sed -i 's,plugins/openvswitch/ovs_neutron_plugin.ini,plugin.ini,g'

/etc/init.d/neutron-openvswitch-agent;


service neutron-openvswitch-agent restart;


yum -y install openstack-nova-compute;


mysql://nova:redborder@controller/nova;

openstack-config --set /etc/nova/nova.conf DEFAULT auth_strategy

keystone;


auth_uri http://controller:5000;


auth_host controller;


auth_protocol http;


auth_port 35357;


admin_user nova;





openstack-config --set /etc/nova/nova.conf DEFAULT rpc_backend

qpid;

Anéxo G: Scripts del Nodo Compute

112

openstack-config --set /etc/nova/nova.conf DEFAULT qpid_hostname

controller;

openstack-config --set /etc/nova/nova.conf DEFAULT my_ip compute;

openstack-config --set /etc/nova/nova.conf DEFAULT vnc_enabled

True;


0.0.0.0;


vncserver_proxyclient_address compute;


novncproxy_base_url http://controller:6080/vnc_auto.html;

openstack-config --set /etc/nova/nova.conf DEFAULT glance_host

controller;

service libvirtd start;

service messagebus start;


chkconfig libvirtd on;

chkconfig messagebus on;

chkconfig openstack-nova-compute on;

113

ANEXO H: PINGS

Ping desde el nodo controlador a internet:

Ping desde el nodo controlador a nodo de red (interfaz de gestión):

Ping desde el nodo controlador a nodo compute (interfaz de gestión):

Anexo H: Pings

114

Ping desde el nodo de red a internet:

Ping desde el nodo de red a nodo controlador (interfaz de gestión):

Ping desde el nodo de red a nodo compute (túnel de instancia):

Ping desde el nodo de compute a internet:


Ping desde el nodo de compute a nodo controlador (interfaz de gestión):

Ping desde el nodo de compute a nodo de red (túnel de instancia):

117

REFERENCIAS

[1] http://cloud-america.com/?page_id=257

[2] http://www.blogvmware.com/2013/12/pool-de-recursos.html

[3] http://cloud-america.com/?page_id=257

[4] http://docs.openstack.org/developer/sahara/overview.html

[5] http://searchaws.techtarget.com/definition/Opscode-Chef

[6] https://docs.getchef.com/chef_overview_server.html

119

ÍNDICE DE CONCEPTOS

i Instancia: Clon de una imagen que se crea a demanda del usuario

en uno de los nodos del cloud.

ii EC2 (Elastic Cloud Computing): Es un servicio web que proporciona capacidad informática con tamaño

modificable en la nube. Está diseñado para facilitar a los desarrolladores recursos informáticos escalables

basados en web.

iii PXE: Preboot eXecution Environment (Entorno de ejecución de prearranque), es un entorno para arrancar e

instalar el sistema operativo en ordenadores a través de una red, de manera independiente de los dispositivos de

almacenamiento de datos disponibles (como discos duros) o de los sistemas operativos instalados.

iv Qpid: Sistema de mensajería que implemente AMQP (Advanced Message Queiuing Protocol). Proporciona

gestión de transacciones, colas, distribuciones, seguridad, gestión y soporte de multiplataformas heterogéneas.

v Tenant: Contenedor usado para agrupar o aislar recursos y/o objetos de identidad. Dependiendo del operador

del servicio, un tenant (inquilino) puede asociarse a un consumidor, cuenta, organización o proyecto.

vi GlusterFS: Gluster File System o GlusterFS, es un multiescalable sistema de archivos para NAS. Este permite

agregar varios servidores de archivos sobre Ethernet o interconexiones Infiniband RDMA en un gran entorno

de archivos de red en paralelo.

vii Nodo: Punto de intersección, conexión o unión de varios elementos que confluyen en el mismo lugar.

viii KVM: Máquina virtual basada en el núcleo.Es una solución para implementar virtualización completa con

Linux.

ix QEMU: emulador de procesadores basado en la traducción dinámica de binarios (conversión del código

binario de la arquitectura fuente en código entendible por la arquitectura huésped). QEMU también tiene

capacidades de virtualización dentro de un sistema operativo, ya sea GNU/Linux, Windows, o cualquiera de los

admitidos.

x Bond: Bonding es una forma de obtener enlaces redundantes en bridges, tanto en aparatos de alta gama, como

en máquinas con software libre.

xi REST: REpresentational State Transfer, es un tipo de arquitectura de desarrollo web que se apoya totalmente

en el estándar HTTP. REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier

dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y convencional que otras

alternativas que se han usado en los últimos diez años como SOAP y XML-RPC.

xii Tokens: Un texto de bits arbitrarios que es usado para acceder a los recursos. Cada token dice q eu servicios

se pueden acceder.

Índice de Conceptos

120

xiii Usuario: Representación digital de una persona, sistema, oservicio que quiere usar los servicios de la nube de

OpenStack.

xiv Credenciales: Datos conocidos solo por el usuario que demuestra que es él.

xv Autenticación: Acto de confirmar la identificación de un usuario.

xvi Servicio: Proporciona uno o mas endpoint a través de los cuales, los usuarios pueden acceder a operaciones

de rendimieno y accesos de recursos.

xvii Endpoint: Dirección de red accesible, normalmente descrita por una URL, donde se pude tener acceso al

servicio.

xviii Rol: Personalidad que un usuario asume y que este sabe a que cosa especificas puede acceder con ese rol.

xix Daemons: Ttipo especial de proceso informático no interactivo, es decir, que se ejecuta en segundo plano en

vez de ser controlado directamente por el usuario. Este tipo de programas continua en el sistema, es decir, que

puede ser ejecutado en forma persistente o reiniciado si se intenta matar el proceso dependiendo de configuración

del demonio y políticas del sistema. La palabra daemon viene de las siglas en ingles D.A.E.MON (Disk And

Execution Monitor).

xx Metadatos: El concepto de metadatos es análogo al uso de índices para localizar objetos en vez de datos. Por

ejemplo, en una biblioteca se usan fichas que especifican autores, títulos, casas editoriales y lugares para buscar

libros. Así, los metadatos ayudan a ubicar datos.

xxi Linux network namespaces: Instalacion de linux que permite tener un conjnto de interfaces y entradas a la

tabla de enrutamiento simples.

xxii IPs flotantes: Dirección IP pública que puede asociarse a diferentes instancias con el fin de acceder a ellas

desde fuera.

xxiii Django: Framework de desarrollo web de código abierto, escrito en Python, que respeta el paradigma

conocido como Model Template View. Permite una creación de sitios web mas sencilla.

xxiv Orquestación: Gestión de sistemas y automatización de insfraestructura de la nube.

xxv Hadoop: Framework de software que soporta aplicaciones distribuidas bajo una licencia libre.1 Permite a las

aplicaciones trabajar con miles de nodos y petabytes de datos.

xxvi Ruby: Lenguaje de programación interpretado, reflexivo y orientado a objetos.

xxvii Erlang: Un lenguaje de programación concurrente (u orientado a la concurrencia) y un sistema de ejecución

que incluye una máquina virtual (BEAM) y bibliotecas (OTP).


xxviii Framewotk: Estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o

módulos de software concretos, que puede servir de base para la organización y desarrollo de software.

Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras

herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto.

xxix Cookbooks: Unidad fundamental de distribuvción de configuración y póliticas. Cada cookbook (libro de

recetas) define un escenario y contiene todo los componentes que se requieren para montar ese escenario.

xxx Recipes: Receta del Cookbook.

xxxi DSL: Lenguaje de computación especializado en una dominio de aplicación en particular.

xxxii Front-end: Parte del software que interactúa con el o los usuarios.

despliegue de arquitectura cloud basada en openstack y su...

Documents