Memoria Telecuminicaciones

Proyecto Fin de Grado
Grado en Ingeniera de las Tecnologa de

Telecomunicacin
Despliegue de arquitectura cloud basada en

OpenStack y su integracin con Chef sobre CentOS
Autor: Antonio Cobos Domnguez

Tutor: Pablo Nebrera Herrera
Dep. Ingeniera Telemtica

Escuela Tcnica Superior de Ingeniera
Universidad de Sevilla
Sevilla, 2014
Proyecto Fin de Grado

Grado en Ingeniera de las Tecnologas de Telecomunicacin
Despliegue de arquitectura cloud basada en

OpenStack y su integracin con Chef sobre CentOS
Autor:
Antonio Cobos Domnguez
Tutor:
Pablo Nebrera Herrera
Profesor asociado
Dep. Ingeniera Telemtica

Escuela Tcnica Superior de Ingeniera
Universidad de Sevilla
Sevilla, 2014
Proyecto Fin de Carrera: Despliegue de arquitectura cloud basada en OpenStack y su integracin con Chef sobre
CentOS
Autor:
Antonio Cobos Domnguez
Tutor:
Pablo Nebrera Herrera
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificacin de:

Sevilla, 2014
El Secretario del Tribunal
A mi familia
A mis amigos
A mis maestros
Agradecimientos
Este es el nico rincn personal que hay en esta consecucin 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 cmo criar a un hijo no estara escribiendo estas lneas 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 educacin. Ellos son la gran motivacin de este proyecto. Quiero darles esa satisfacin 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 rias, su cario 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 Toi, mi tio Seba y mi tia Carlota , que siempre he tenido su apoyo, cario y sus
dineritos bajo cuerda que siempre me vienen bien.
Merecen una mencin 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 elaboracin 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 compaeros. Muchas Gracias.
Gracias a todos por estar conmigo y aparecer en mi vida desde que me embarque en este proyecto hace 4 aos,
que al principio pareca que este fin no iba a llegar.
GRACIAS
Resumen
El Cloud Computing tiene como objetivo la dotacin de flexibilidad, elasticidad y alta disponibilidad a los
servicios que se proporcionan a travs de la nube. OpenStack, un software de cdigo abierto, hace de la nube
una infraestructura para el despliegue de servicios distribuidos. Este estudio se centrar en la configuracin e
implantacin de este software al proyecto RedBorder Horama, as como la valoracin de las configuraciones,
distribuciones, y software para una mejor integracin.
Se ha realizado una amplia investigacin sobre Cloud Computing, un mundo inifnito con mltiples
posibilidades, centrado en el lanzamiento de instancias, el cual es el pilar fundamental de esta tecnologa. Gracias
a eso se podr acceder a mquinas remotas, con un pago por uso y con un aprovisionamiento dinamico. Se
implementa tambin el gestor de sistemas y automatizacin de insfraestructura de la nube, Chef, para
proporcionar una gestin ms potente de sta.
iii
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
Resumen
iii
Abstract
ndice
vi
ndice de Tablas
ix
ndice de Figuras
xi
Notacin
1
Introduccin
xiii
1
Escenario y Configuracin Inicial

2.1 Topologia
2.1.1
Caracteristias fsicas
2.1.2
Escenario
2.2 Configuracin inicial
5
5
5
6
7
Componentes Bsicos de OpenStack

3.1 Openstack Identity Service (Keystone)
3.2 Openstack Image Service (Glance)
3.3 OpenStack Compute (Nova)
3.4 OpenStack Object Storage (Swift)
3.5 OpenStack Block Storage (Cinder)
3.6 OpenStack Networking (Neutron)
3.7 OpenStack Dashboard (Horizon)
11
13
14
15
16
17
18
19
Lanzar una Instancia

4.1 Usuarios
4.1.1
Administrador
4.1.2
Usuarios normal
4.2 Componentes
4.2.1
Redes
4.2.2
Routers
4.2.3
Instancia
21
21
21
21
21
21
21
22
Componentes Adicionales de OpenStack

5.1 OpenStack Orchestration (Heat)
5.2 OpenStack Telemetry (Ceilometer)
5.3 DataBase OpenStack (Trove)
5.4 Hadoop Cluster OpenStack (Sahara)
5.5 Nota aclaratoria
29
29
30
31
33
34
Integracin con Chef

6.1 Qu es Chef?
6.2 Chef Server
6.3 Chef Client
35
35
35
36
6.3.1
Knife OpenStack
36
Presupuesto
39
Lineas de Mejora
41
Anexo A: Instalacin en Nodo Controlador
43
Anexo B: Instalacin en Nodo de Red
73
Anexo C: Instalacin en Nodo Compute
81
Anxo D: Instalacin y Casos de Uso de Chef
91
Anxo E: Scripts del Nodo Controlador
93
Anxo F: Scripts del Nodo de Red
105
Anxo G: Scripts del Nodo Compute
109
Anexo H: Pings
113
Referencias
117
ndice de Conceptos
119
vii
NDICE DE TABLAS
Tabla 1: Diferencias entre maquinas virtuales y fsicas
Tabla 2: Componentes
Tabla 3: Presupuesto
39
ix
NDICE DE FIGURAS
Figura 1.
Tipos de aaS
Figura 2.
Escenario de Red
Figura 3.
Mdulos e IP de los Nodos
Figura 4.
Componentes en controlador
Figura 5.
Componentes en red
Figura 6.
Componentes en compute
Figura 7.
Diagrama OpenStack
12
Figura 8.
Autenticacin 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.
Autenticacin en Dashboard
20
Figura 15.
Visin general de Dashboard
20
Figura 16.
Esquema general de redes
23
Figura 17.
Pestaa Instancias
23
Figura 18.
Modificacin de Sabores
24
Figura 19.
Creacin sabor RedBorder
24
Figura 20.
Lanzar Instancia
25
Figura 21.
Redes de la Instancia
26
Figura 22.
Estado de la Instancia
26
Figura 23.
Asociacin 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
xi
Notacin
DHCP
KVM
CPU
RAM
IPMI
PXE
S.O
API
DNS
LDAP
SMTP
BBDD
VM
HTTP
RPC
REST
JSON
DSL
Discover Host Configuration Protocol

Kernel-based Virtual Machine
Central Processing Unit
Random Access Memory
Intelligent Platform Management Interface
Preboot eXecution Environment
Sistema Operativo
Application Programming Interface
Domain Name System
Lightweight Directory Access Protocol
Simple Mail Transfer Protocol
Base de Datos
Virtual Machine
HyperText Transfer Protocol
Remote Procedure Call
REpresentational State Transfer
JavaScript Object Notation
Domain-Specific Language
xiii
1 INTRODUCCIN
Gran parte de las dificultades por las que atraviesa el mundo se deben a
que los ignorantes estn completamente seguros y los inteligentes llenos
de dudas.
Bertrand Russell
a Compuacion en la Nube (Cloud computing) es el desarrollo y la utilizacin de capacidad de

procesamiento computacional basado en Internet (la nube). Este concepto agrupa diversas
caractersticas el cual lo hacen ms atractivo e interesante para las empresas. Algunas de estas son:
Servicio disponible de forma automtica y a demanda.
Accesible a travs de la red.
Modelo que permite que solo una instanciai se ejecute en el servidor, pero sirviendo a multiples clientes
(modelo Multi-Tenancy).
Se comparten los recursos con otros usuarios.
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
caractersticas de cloud. Se definen tres capas o niveles de este modelo:
Software como Servicio (Software as a Service-SaaS): Aplicacin como servicio en la nube

o
El usuario utiliza una aplicacin a travs 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 aplicacin 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 cmputo, redes ydiversos modos de
almacenamiento. Por ejemplo Amazon Web Services (AWS), OpenStack y Windows Azure.
Introduccin
Datacenter
IaaS
Gestin Propia
Figura 1: Tipos de aaS
Dentro de los modelos de negocio se puede optar por diferentes tipos de despliegue.
Publico: Se necesita una IP pblica para que los usuarios puedan acceder desde cualquier lugar.
Privado: No se necesitan IPs publicas por tanto el rea de uso queda restringida a la red local. Esta
opcin es til para configurar los recursos propios de una manera mas flexibes y con toda la carga en
los servidores.
Hbrido: Se utilizan recursos de la nube privada o de una o varias nubes pblicas en funcin de las
caractersticas de cada caso o las necesidades puntuales que haya. Se suele utilizar una API comn que
permita una buena integracin.
Existen ciertas diferencias entre la estructura clsica de maquinas virtuales o fsicas y la infraestructura
en nube. A continuacin se presentan alguna de ellas:
Gestin por Terceros
Gestin por Terceros
Gestin Propia
SaaS
PaaS
Gestin por Terceros
Gestin Propia
Virtualizado
Despliegue de arquitectura cloud basada en OpenStack y su integracin con Chef sobre CentOS
Maquinas fsicas
Ventajas
Inconvenientes
Maquinas virtuales
Aislamiento de servicios
Aislamiento de servicios
Funcionalidad completa: IPMI,

PXEiii, DHCP
Recursos mejor aprovechados
Muchos recursos
desaprovechados
Se pierde cierta funcionalidad
Dependencia de varias maquinas

de un solo equipo fsico
Tabla 1: Diferencias entre maquinas virtuales y fsicas
Antes de elegir una opcin se ha de analizar el entorno donde vamos a desplegar el sowtware de computacin
en la nube.
El entorno a desarrollar se situa en la empresa Eneo Tecnologa, una empresa dedicada a la seguridad y
visibilidad en redes, cuyo producto principal, RedBorder, se encarga de llevar a cabo esas caractersticas
mediante el uso de sensores IPS y netflow en trminos generales. Se pretende realizar una nube privada para
disponer de sus servicios de una forma ms flexible y eficiente. Una vez realizado ese desarrollo se ampliar
hacia la nube pblica 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).
Introduccin
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 mayora de las caractersticas
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.
Componente
Detalles
Versin
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
Tabla 2: Componentes.
2 ESCENARIO Y CONFIGURACIN INICIAL
La arquitectura es arbitraria, pero una vez est hecha, se convierte en

necesaria.
Rafael Moneo
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 podrn ser
multiples nodos segn 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 fsicas
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:
Interfaces de red: 1
Memoria RAM:2GB
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
Memoria RAM:2GB
Disco Duro (GB):22
Compute Node
Este nodo ser desplegado en una maquina fsica (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 caractersticas:
o
2.1.2
Interfaces de red
Fsicas: 1
Virtuales: 2 (creadas en la nica fsica).(bond)x
Memoria RAM:48GB
Disco Duro (GB):45
Escenario
Figura 2: Escenario de Red
2.2 Configuracin inicial

A continuacin se explicar cmo se asignan las IPs a los nodos en relacin al escenario anterior. En primer
lugar se tiene que configurar una red de gestin (pintadas en rojo en la Fig. 3). Se aprovechar la red de la
empresa para asignar las IPs de gestin, las cuales pertenecern 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). Adems 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 conexin directa entre la interfaz del nodo de red y la interfaz del nodo
compute.Si se desea aadir mas computes solo habra que asignar una IP nueva dentro de la red de tunelado.
Ms adelante se explicar el proceso de instanciar, pero el concepto es que por cada conexin network-compute
se instancien tantas imagenes como VLANs se permitan.
Figura 3: Mdulos e IP de los Nodos
Controller Node (IP: 10.0.151.100/24)
El nodo controlador es el responsable de ejecutar el software de gestin 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.
Corre un nmero 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.
Aporta una infraestructura de servicios altamente disponible, como son MySQL y Qpid, que
sustentan a todos los servicios.
Proporciona lo que es llamado un almacenamiento persistente para los servicios que corren en
el host.
Figura 4: Componentes en controlador
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 pblicas o privadas y enlacen sus maquinas virtuales en la red externa:
o
Formar el unico punto de entrada y salida para las instanciasque estn corriendo en la cima de
de OpenStack.
Corre todos los servicios de red del entorno, con la excepcion de que la API del servicio de red
corre en el controlador.
Figura 5: Componentes en el nodo de red
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.
Usa almacenamiento local en el nodo para las maquinas virtuales, asi que no se contempla un
fallo en la migracin de maquinas virtuales o recuperacin de instancias.
Figura 6: Componentes en el compute
10
Tanto las configuraciones anteriores como la instalacin 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.
3 COMPONENTES BSICOS DE OPENSTACK
Si se puede imaginar, se puede programar.

Annimo
penStack se trata de un proyecto grande y modular. Los mdulos tienen muchas caractersticas comunes
para poder integrarse fcilmente. Todos estn 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 comunicacin entre componentes o externa (clientes), autenticacin
basada en tokensxii gestionada a travs del componente Keystone y tienen una base de datos propia e
independiente.
Antes de continuar leyendo esta seccin se recomienda ver el glosario de conceptos de la seccin 3 en el apartado
Conceptos (como usuarioxiii, credencialesxiv, autenticacinxv, servicioxvi, endpointxvii, rolxviii).
11
Figura 7: Diagrama OpenStack
12
13
3.1 Openstack Identity Service (Keystone)

Este componente se basa en un directorio centralizado que almacena informacin de:
Usuarios
Proyectos (tenants)
Roles
Servicios y sus endpoints
La informacin se almacena en un Sistema de Gestin de Base de Datos Relacional (MySQL) y adems este
componente (Keystone) debe ser el primero en ser instalado puesto que los dems componente lo usarn como
sistema de autenticacin para poder acceder a la informacin necesario del proyecto (cada uno en su mdulo).
Keystone se encarga tanto de manejar los pedidos de la API as como tambin provee un nico punto de
integracin para las polticas de OpenStack, catlogos de los servicios, token y autenticacin.
Proceso de autenticacin:
Usuario enva credneciales a travs de la API
Keystone le enva un token temporal y le enva un catlogo 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 enva credenciales con su correspondiente tenant.
Keystone enva 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 enva la peticin.
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 enva la informacin al usuario.
14
Figura 8: Autenticacin en Keystone
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 imgenes 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
ejecucin 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 bsqueda, obtencin y almacenamiento de imgenes.
El registro de almacenamiento glance-registry procesa y recupera los metadatos de las imgenes.
Posee una base de datos para los metadatos de las imgenes.
Tambin se corren servicios de replicacin, para proveer consistencia y disponibilidad a travs del
cluster, auditora y actualizacin.
15
Figura 9: Diagrama Glance
3.3 OpenStack Compute (Nova)

Este es el componente principal de OpenStack. Gestiona las instancias de imgenes, dnde deben ejecutarse y
el acceso mediante consola.
Soporta diferentes hipervisores: KVM/QEMU, Xen, Hyper-V, VMware ESXi, LXC, Docker.
Permite incluso el aprovisionamiento de mquinas fsicas mediante Baremetal/Ironic.
Funcionamiento:
El cliente nova-api acepta y responde a las llamadas del usuario final.
La virtualizacin es administrada por nova-compute. Crea/finaliza las instancias de VMs a travs

de la API del hipervisor utilizado.
La planificacin es realizada por nova-schedule. Toma los pedidos de VMs de la cola y determina
dnde debera ejecutarse.
La cola, es el nodo central para el pasaje de mensajes entre daemonsxix.
Tambin dispone de una base de datos que almacena la mayora de los datos de estado de
compilacin y ejecucin.
nova-consoleauth, nova-novncproxy, nova-console permiten a los usuarios acceder a las

instancias virtuales a travs de un proxy.
Al crear una instancia debern seleccionar entre las opciones de configuraciones de recursos
virtuales disponibles, llamadas flavors. Luego, pueden agregarse recursos como volmenes de
almacenamiento persistente y direcciones IP pblicas.
16
Figura 10: Diagrama Nova
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
econmica. Hoy en da 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 imgenes. (Antes de continuar se recomienda leer la
seccin 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 recupralo sin necesidad de conocer la ubicacin fsica de la informacin. 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 creacin de contenedores; tambin 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.
Tambin se corren servicios de replicacin, para proveer consistencia y disponibilidad a travs del cluster,
auditora y actualizacin.
17
Figura 11: Diagrama Swift
3.5 OpenStack Block Storage (Cinder)

Los volmenes 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 volmenes se crean en el nodo de almacenamiento (por
defecto con LVM) y se conectan a la instancia que se desee mediante algn 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 volmenes, por lo que
estos reciben el nonmbre de almacenamiento permante.
Se puede pensar en los volmenes 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 manipulacin de volmenes, tipos de volmenes 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, interacta con
otros procesos (como el cinder-scheduler) a travs 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 creacin de un
volumen sobre el.
La cola de mensajes enruta informacin entre los procesos de Cinder.
Una base de datos almacena el estado de los volmenes.
18
Figura 12: Diagrama Cinder
3.6 OpenStack Networking (Neutron)

Componente encargado de la configuracin de redes virtuales, el cual, incluye un buen numero de complementos
(OpenvSwitch, Cisco, Niciria, etc).
Neutron gestiona mltiples redes de forma independiente gracias al uso de Linux network namespacesxxi que
permite que mltiples routers virtuales compartan un dispositivo de red fsico.Neutron tambin se encarga de la
gestin de los grupos de seguridas y de las IPs flotantesxxii.
Neutron tiene como caractersticas:
Da a a los tenants de la nube una API para construir topologas de red muy completas, y configurar
polticas de red avanzadas en la nube.Por ejemplo crear una topologa de aplicacin 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 garantas de calidad de
servicio (QoS) end-to-end. Usa adems protocolos de monitorizacin como NetFlow.
Permite cualquier topologa 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 especfica en el centro
de datos fsico.
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
interactan con el proceso principal a travs de la cola de mensajes o la API de red estndar 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.
19
Figura 13: Diagrama Neutron
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 mtodos mas utilizados.
El panel de control de OpenStack (dashboard) proporciona al administrador y usuarios una interfaz grfica para
acceder, provisionar y automatizar los recursos basado en la nube. Ademas es fcil incorporar y presentar
productos y servicios para terceros, como son la facturacin, la monitorizacin y las herramientas de gestios
adicionales.
Capacidades de Horizon:
Permite cotrolar a los administradores y usarios su nivel de computacin, almacenamiento, y

recursos de red.
Como administrador, el panel de control ofrece una vista global del tamao 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.
20
Figura 14: Autenticacin en Dashboard
Figura 15: Visin general de Dashboard
4 LANZAR UNA INSTANCIA
No importa. Intntalo de nuevo. Fracasa otra vez.Fracasa mejor.

Samuel Beckett
n este captulo se describirn 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 alojarn las IPs las cuales servirn 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 sern mapeadas las IPs 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 IPs de las instancias de
las maquinas virtuales (192.168.1.0/24).
4.2 Componentes
A continuacin se presentarn los componentes bsicos 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 llamarn 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 IPs privadas a las
pblicas (red de la empresa).
21
22
En este caso se crear un router con dos interfaces:

1. Una interfaz a la red pblica (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 continuacin se mostrar un ejemplo bsico de creacin de red, routers y lanzamiento de instancia.

Estos pasos se han de realizar en el nodo controlador y se harn 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 asignndole 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
start=10.0.150.20,end=10.0.150.26
10.0.150.0/24;
--name
ext-subnet
--allocation-pool
--disable-dhcp
--gateway
10.0.150.1
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 asignndole 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:
23
neutron router-gateway-set demo-router ext-net;
Una vez hecho esto se tendr lo siguiente:
Figura 16: Esquema general de redes
Los siguientes pasos que se han de realizar son necesarios para lanzar una instancia:
1. Ir a la pestaa del dashboard Instancias y pulsar Lanzar Instancia.
Figura 17: Pestaa Instancias
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 pestaa Sabores y
dndole a crear sabor como aparece a continuacin.
24
Figura 18: Modificacin de Sabores
Y se le asignarn los recursos deseados para este sabor.
Figura 19: Creacin sabor RedBorder
25
Ahora ya se puede rellenar completamene el cuadro de lanzado de instancia como se adjunta a continuacin
Figura 20: Lanzar Instancia
3. Ahora en el cuadro de lanzado de instancia se seleccionar la pestaa 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.
Figura 22: Estado de la Instancia
5. Una vez hecho esto se han de asignar las IPs flotantes para poder acceder a esta instancia desde la red
externa. Para ello se selecciona la pestaa Mas y pulsamos sobre Asociar IP flotante.
27
Figura 23: Asociacin de IPs Flotantes
6. Se selecciona el botn + y posteriormente se selecciona la red de donde se asignarn las IPs

flotantes para por ltimo pulsar Asociar.
Figura 24: Estado de Instancia con IPs flotantes
7. Ya se podr acceder mediante ssh a la instancia de RedBorder indicndole como IP la flotante

asociada dentro del rango indicado en la creacin de la red externa.En este caso 10.0.150.21
28
Figura 25: Acceso a maquina RedBorder
5 COMPONENTES ADICIONALES DE OPENSTACK
No importa. Intntalo de nuevo. Fracasa otra vez.Fracasa mejor.

Samuel Beckett
5.1 OpenStack Orchestration (Heat)

El servicio de orquestacinxxiv provee un servicio de orquestacin basado en plantillas para describir una
aplicacin en la nube mediante las llamadas de la API de OpenStack para ejecutar esas aplicaciones.
Las plantillas permiten crear la mayora de los recursos de OpenStack, como instancias, IPs flotantes, volmenes,
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 integracin con otros proyectos principales de OpenStack, todos los proyectos principales
de OpenStack podrn recibir una gran BBDD de usuarios.
Esto anterior permite a los desarrolladores una integracin directa con el servicio de orquestacin o a travs de
plug-ins personalizados.
El servicio de Orquestacin consta de los siguientes componentes:
Heat. Una lnea de comandos que se comunica con la API (heat-api) para correr APIs tales como AWS
CloudFormation. Los desarrolladores finales podran incluso usar directamente la API de Orquestacion
REST.
Heat-api. Proporciona una API REST nativa de OpenStack que procesa las peticiones envindolas al
heat-engine sobre RPC.
Heat-api-cfn. Proporciona una API Query AWS que es compatible con AWS CloudFormation y
procesa las peticiones API envindolas al heat-engine sobre RPC.
Heat-engine. Organiza el lanzamiento de plantillas y proporciona eventos a la API del consumidor.
29
30
Figura 26: Diagrama de Heat
5.2 OpenStack Telemetry (Ceilometer)

Telemetry proporciona una infraestructura para la monitorizacin y la medicin de la nube de OpenStack.
Tambien se conoce como proyecto Ceilometer.
El mdulo Telemetry:
Recoge eficientemente las mediciones de datos cobre la CPU y los costs de red.
Recopila datos de notificaciones de monitorizacin 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 travs 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 bsicos:
Ceilometer-agent-compute. Corre en cada compute node y ademas hace recuenos para las estadisticas
de la utilizacin de recursos. Se plantea la posibilidad de que en un future pueda haber otro tipo de
agentes en adicin a este.
Ceilometer-agent-central. Corre en un servidor central de gestin para hacer recuento de las estadisticas
de utilizacin de recursos para los recursos no vinculados a instancias o compute nodes.
Ceilometer-collector. Corre en uno o mas servicores centrales de gestin para monitorizar las colas de
mensajes (notificaciones y mediciones provenientes del agente). Los mensajes de notificacin son
procesados y convertidos a mensajes de medicin y enviados de vuelta en el canal de mensajes usando
el tema apropiado. Los mensajes del modulo de Telemetra estan escritos en el amacenamiento de datos
sin modificacin alguna.
Ceilometer-alarm-notifier. Corre en uno o mas servidores centrales de gestin para permitir la

establecimiento de alarmas basadas en la evaluacin de umbrales para una coleccin de muestras.
Una BBDD. Una base de datos capaz de manejar escritura concurrente (de una o mas recopilacin de
31
instacias) y lectura (de la API del servidor).
Ceilometer-api. Corre en uno o mas servidores centrales de gestin 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.
Figura 27: Diagrama de Ceilometer
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 automatizacin de
tareas administrativas complejas como son el despliegue, configuracin, aplicacin de parches, copias de
seguridad, restauraciones y monitorizacin.
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 huspedes que quieren
actualizar informacin en el host.
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.
Figura 28: Diagrama de Trove
A continuacin 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

imgenes, 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 tpico de

acceso a una BBDD. Por exemplo en MySQL:
$ mysql -u myuser -pmypass -h trove_ip_address mydb
33
5.4 Hadoop Cluster OpenStack (Sahara)

El objetivo de este proyecto es permitir a los usuarios provisionar y gestionar de una manera fcil clusters de
Hadoopxxv en OpenStack. Merece la pena mencionar que Amazon proporciona Hadoop durante varios aos
como Amazon Elastic MapReduce (EMR) [4].
Sahara tiene como objetivo proporcionar usuarios con medios simples para provisionar clusters Hadoop
especificando varios parmetros como la versionde Hadoop, la topologa del cluster, los detalles hardware de
los nodos y poco mas. Despus el usuario rellena todos los parmetros y Sahara despliega el cluster en pocos
minutos. Sahara tambin proporciona medios para escalar clusters ya provisionados mediante la
adicin/borrado de nodos de trabajo en funcin de lo demandado.
Las caractersticas claves son:
Est diseado como un componente de OpenStack.
Gestionado a travs 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 instalacin Hadoop.
2. Integracin con herramientas de gestin de proveedores especficos, como Apache Ambari o
consola de gestin de Cloudera.
Plantillas predefinidas de conficuraciones de Hadoop con la opcin de modificar parmetros.
Figura 29: Diagrama de Sahara
Sahara se comunica con los siguientes componentes de OpenStack:
Horizon: Proporciona interfaz grfica de usuario con la capacidad de usarr todas las caractersticas 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.
34
Glance: Las imgenes de las maqinas virtuales de Hadoop se guardan aqu, cada imagen contiene un
S.O. instalado y Hadoop; Hadoop pre-instalado debera dar una buena desventaja en el nodo de puesta
en marcha.
Swift: Puede ser uasdo como un almacenamiento para datos que sern 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 seccin puesto que su
funcionalidad completa y estable es cuestion de meses pero no se han incluido en la instalacin 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 mdulos, la arquitectura sera la mostrada a continuacin y esta ser la que se
instalar de manera definitiva:
Figura 30: Diagrama completo de OpenStack
6 INTEGRACIN CON CHEF

Todo tiene un final, excepto la salchicha, que tiene dos.
Annimo.
n esta seccin se hablar del orquestador Chef y de su integracin con OpenStack adems de las
funcionalidades extras que aporta esta funcin y de las ventajas y flexibilidad, que con solo la integracin
de este componente, con la que se puede dotar a la nube.
En primer lugar se realizar una introduccin para aclarar conceptos, y posteriormente se ahondar en
funcionalidades cada vez ms amplias y complejas.
6.1 Qu es Chef?
Chef es un sistema de gestin de codio abierto (escrito en rubyxxvi y erlangxxvii) y un frameworkxxviii de
automatizacin 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 cmo cada nodo de la organizacin debera ser configurado. Las recipes (se usa
DSLxxxi para escribir los recipes) de Opscode describen el estado que tendra que tener un recurso en un
momento en concreto. Chef guarda esos ficheros en cookbooks junto a otros archivos de configuracin
necesarios.
En este caso en particular se va a usar la versin open-source de Chef 11.0 que segn una estimacin de los
creadores podra ser usado para configurar ms de 10.000 nodos con tan solo un cliente de este.
6.2 Chef Server

El servidor de Chef acta como un aglutinador de datos de configuracin. Este guarda los cookbooks, las
polticas que son aplicadas en los nodos, y los metadatos que describen cada nodo registrado que estn siendo
gestionados por el cliente de Chef. Cada instancia del servidor de Chef debe estar configurado y gestionado
localmente, incluyendo migraciones de datos, aplicacin de actualizaciones, y aseguramiento de que la
infraestructura local escala apropiadamente [6].
A continuacin se presentar un diagrama sobre los componentes que forman parte del despliegue del servidor
de Chef y como ellos estn relacionados.
Nginx: Es un servidor HTTP de cdigo 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 travs de Nginx.
Bookshelf: Como su traduccin en ingls indica, es como una estantera donde se guardan los
cookbooks (ficheros, plantillas, etc).
35
Integracin con Chef
36
Figura 31: Estructura de Chef
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, tambin
del paquete de Chef.
Knife es una herramienta de lnea 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 instalacin del cliente Chef en las workstations de gestin y la
bsqueda de datos indexadosen el servidor de Chef.
Knife corre desde una workstation de gestin y se situa entre un servidor de Chef y la infraestructura de la
organizacin. 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 gestin
aporta varias caractersticas.
Aade una capa extra de orquestacion, pudiendo as, realizar mltiples combinaciones mediante la
compenetracin con Heat.
37
Mayor potencia de gestin 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 aadir mas caracteristicas a
estas o incluso crear nuevas, lo que implica un convergencia mucho menor con respecto a las
configuraciones.
La instalacin y uso de este servicio se encuentra en el Anexo D.
38
Integracin con Chef
7 PRESUPUESTO
n este apartado se elaborar un presupuesto aproximado en funcin de las horas trabajadas y del coste que
conllevara 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 virtualizacin) costar unos 6.000. Por tanto se tiene el siguiente presupuesto:
Precio
Total
Horas trabajadas (h)

360
/hora
40
14.400,00
Equipo necesario ()
6000
Cantidad
1
6.000,00
TOTAL
20.400,00
Tabla 3: Presupuesto
39
40
Presupuesto
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 liberacin de carga
computacional en equipos particulares dejando esta tareas a los equipos corporativos dando una ventaja
de movilidad,cobro por uso y distribucin de servicios.
En este caso en particular se ha decidido por una topologa virtual determinada mediante el uso de tneles de
nivel 2. Una mejora o cambio segn demanda de esta topologa 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 versin 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 integracin cada vez mas acorde a las necesidades de empresas y
tecnologas 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 instalacin sobre un sistema base CentOS, sera interesante instalarlo sobre Ubuntu, ya que
la nube de OpenStack trae integradas ciertas herramientas de orquestacin, etc. que por motivos de
compatibilidad e integracin de estas con las ya existentes en la empresa fue una opcin que se descart. Aun
as, dara una mayor facilidad de gestin e instalacin debido a su potente interfaz grfica.
41
42
Lineas de Mejora
ANEXO A: INSTALACIN 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 notacin 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 travs de mltiples 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 continuacin se mostrar cmo estn configuradas las interfaces de red en este equipo. Se configurar este
equipo en funcin de lo mostrado en el apartado 2 de la memoria principal Escenario y configuracin inicial
Fichero /etc/sysconfig/network-scripts/ifcfg-eth1
43
44
Ahora se configurar la resolucin de nombres:

Editar el archivo /etc/hosts aadindole las lneas 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 sincronizacin se indica con un asterisco):
ntpq np
Y muestra lo siguiente:
Database
A continuacin se instalarn los paquetes del cliente y servidor de MySQL, y la librera 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 direccin ip de la interfaz de gestin
del nodo controlador para que otros nodos puedan acceder a la BBDD desde la red de gestin:
[mysqld]
...
bind-address = 10.0.151.100
45
Adems 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 ms o menos este aspecto:
Ahora se inicia el servidor de la BBDD MySQL y se configura para que se arranque automticamente cada vez
que se inicie el sistema:
service mysqld start
chkconfig mysqld on
Por ltimo, es conveniente configurar una contrasea para root, as los programas de OpenStack que creen las
bases de datos y las tablas la solicitarn.
Se debe borrar el usuario anonymous que se crea cuando la BBDD se inicia por primera vez.
Para evitar posibles problemas de conexin 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 contrasea configurada para el usuario root,
por tanto si se le solicita una contrasea simplemente se presiona ENTER y se introduce la contrasea que se
quiera utilizar para el usuario root.
Una vez se configure la contrasea se presentaran ciertas opciones que harn mas segura la instalacin de la
BBDD.
RESPONDER SI A TODAS LAS CUESTIONES SI SE QUIERE UNA CONFIGURACIN GENERICA.
OpenStack packages
A continuacin se describir la configuracin que se debe completar despus de configurar las mquinas para
instalar los paquetes de OpenStack ms recientes.
Si se quiere recurrir a una instalacin ya con una configuracin predeterminada se puede ejecutar el script
packages.sh del Anexo E.
Si se desea realizar una configuracin ms avanzada y personalizada ejecute los comandos abajo indicados.
En este caso se usarn los paquetes OpenStack del repositorio de RDO. Estos paquetes funcionan para RHEL
6, la versin compatible de este en CentOS, y Fedora 20.
Instalar yum-plugin-priorities plug-in. Este paquete permite la asignacin 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/openstackicehouse/rdo-releaseicehouse-3.noarch.rpm
El paquete EPEL incluye las claves GPG para la firma de paquetes e informacin de repositorio. Ahora se
instalar la versin ms 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/epelrelease-6-8.noarch.rpm
47
El paquete openstack-utils contiene programas tiles que hacen la configuracin en instalacin ms fcil. Estos
programas se usarn a lo largo de la gua de instalacin.
Instala openstack-utils. Esto verifica que puedas acceder a los repositorios RDO:
yum install openstack-utils
El paquete openstack-selinux incluye los archivos de polticas que son necesarios para configurar SELinux
durante la instalacin de OpenStack.
Instala openstack-selinux:
yum install openstack-selinux
Ahora se actualizarn los paquetes del sistema:
yum upgrade
FIN_DE_SCRIPT
Por ltimo, se reinicia si la actualizacin 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 informacin de estado de los servicios.
Este servicio de intermediacin 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 ms
conveniente para CentOS y el que mejor viene documentado para integrar con OpenStack.
Para instalar el servicio de intermediacin de mensajes (message broker):
yum install qpid-cpp-server
Para configurar el servicio de intermediacin de mensajes (message broker):
Para simplificar la instalacin en este entorno de prueba, se recomienda desactivar la autenticacin. 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 produccin es recomendable activar la autenticacin.Si se decide activarla se deber
configurar un usuario y contrasea para qpidd en cada archivo de configuracin de los servicios de
OpenStack que usen qpidd
Para finalizar la instalacin
service qpidd start
chkconfig qpidd on
Ahora ya se puede proceder a la instalacin 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 ms rpida y cmoda este servicio.
Se crear con contrasea por defecto redborder. Si se prefier realizar una instalacin
personalizada se han de seguir los pasos que vienen a continuacin.
49
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 informacin. Especificar la localizacin
de la BBDD en el archivo de configuracin. En este caso se usa uan BBDD MySQL con el
nombre de usuario keystone. Reemplazar KEYSTONE_DBPASS con una contrasea adecuada
para la BBDD del usuario:
openstack-config
--set
/etc/keystone/keystone.conf
database
mysql://keystone:KEYSTONE_DBPASS@controller keystone
connection
FIN_DE_SCRIPT
Usar la contrasea 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 continuacin.
A continuacin se crea la BBDD para el Servicio de Autenticacin:
su -s /bin/sh -c "keystone-manage db_sync" keystone
50

Ahora se define un token de autorizacin para usarlo como clave compartida entre el
Servicio de Autenticacin y otros servicios de OpenStack. Se usa openssl para generar un
token aleatorio y guardarlo en el fichero de configuracin:
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 crearn 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 Autenticacin y activarlo para que se arranque al iniciar el sistema:

service openstack-keystone start
chkconfig openstack-keystone on
Por defecto, el Servicios de Autenticacin guarda los tokens expirados en la BBDD

indefinidamente. Esto es til para entornos de produccin, pro sin embargo la acumulacin
de estos tokens expirados aumentaran considerablemente el tamao de la BBDD y puede
disminuir el rendimiento del servicio, particularmente en entornos de prueba con recursos
limitados. Se recomienda configurar una tarea peridica 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
51
Definicin de usuarios, inquilino, y roles

Despues de instalar el Servicio de Autenticacin, 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 indicara un usuario y contrasea para autenticarse con el Servicios de
Autenticacin. En este punto, sin embargo, aun no se han creado usuarios, asi que se tendr que
utilizar el token de autorizacin creado en la seccin anterior. No es necesario hacer eso con la
opcin os-token en los comandos de keystone , sin embargo, se har de esa manera configurando
la variable de entorno OS_SERVICE_TOKEN. Adems de esta ltima, se configurar
OS_SERVICE_ENDPOINT para especificar donde se est ejecutando el Servicio de
Autenticacin:
export OS_SERVICE_TOKEN=$ADMIN_TOKEN
export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0
Crear un usuario administrador
A continuacin se crear un susuario administrados para administrar Openstack.

Por defecto el Servicio de Autenticacin crea un role especial member. El panel de control de
OpenStack automticamente permite el acceso a usuarios con este rol. Por tanto, al usuario
administrador, se le deber dar este rol adems 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 contrasea segura y reemplazar ADMIN_EMAIL con

una direccin de correo electrnico 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 opcin
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
53
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 interaccin 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 contraseas. Omitir el paso de creacin 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 aadan 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 tambin requieren de un nombre de usuario, inquilino y rol para
acceder a otros servicios de OpenStack. En una instalacin bsica, normalmente los servicios
de OpenStack comparten un inquilino simple llamado service.
Por tanto, se crearn 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"
Definicin de servicios y API de puntos finales (endpoints)

El Servicio de Autenticacin puede realizar un seguimiento de qu servicios estn instalados y
donde estn localizados en la red. Para ello, se debe registrar cada servicio en la instalacin 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 Autenticacin. Use las variable de entorno

OS_SERVICE_TOKEN como se configur previamente para la autenticacin.
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 Autenticacin usando el ID de servicio devuelto
en el paso anterior. Cuando se especifica un endpoint, se est provisionando de una URL para la
API pblica, API interna, y API de administrador. Se usa controller como URL. Observar que se
usa un puerto diferente para la API de administrador.
55
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 instalacin del Servicio de Autenticacin

Para verificar que el Servicio de Autenticacin 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 creacin del usuario admin y para
registrar el Servicio de Autenticacin no son necesarias.
Ahora se puede utilizar la autenticacin basada en nombre de usuario.
Peticin de un token de autenticacin usando el usuario admin y la contrasea que se eligi para el:
keystone --os-username=admin --os-password=ADMIN_PASS --os-authurl=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 Autenticacin est corriendo en el endpoint esperado y que la cuenta de usuario se ha
establecido con los credenciales esperados.
57
Ahora se proceder a verificar que la autorizacin se comporta como se espera. Para hacer eso,
hacemos una peticin de autorizacin en un inquilino
keystone --os-username=admin --os-password=ADMIN_PASS --os-tenantname=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.
Tambin se puede conigurar unas variables os-* en el entorno para simplificar el uso de la lnea
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 autorizacin para usar los comandos de
administracin 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 afn, 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 Autenticacin
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 configuracin extra y solo se trata de instalar los clientes de los diversos mdulos
de OpenStack mediante yum.
59
Servicio de Imgenes
Este servicio acta como un registro para discos de imgenes virtuales. Los usuarios pueden aadir
nuevas imgenes o tomar una instantnea 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 (contrasea
por defecto redborder), si no, se puede hacer los siguientes pasos:
Instalacin del mdulo mediante yum:
yum install openstack-glance python-glanceclient
Configuracin de la localizacin de la base de datos. El servicio de imagen proporciona los

servicios glance-api y glance-registry, cada uno con su propio fichero de configuracin:
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 instalacin de este mdulo se pueden hacer mediante
el script glance_2.sh, situado en el Anexo E, pero con las caractersticas por defecto que siempre se han
indicado. Si no se desea esto, pues se sigue con los pasos siguientes:
Creacin de las tablas para la base de datos para el servicio de imagen:
su -s /bin/sh -c "glance-manage db_sync" glance
60

Creacin de usuario glance y asignacin de este al rol de administrador y al inquilino servicio:
keystone user-create --name=glance --pass=GLANCE_PASS -email=glance@example.com
keystone user-role-add --user=glance --tenant=service --role=admin
Configuracion del servicio de imagen para usar el servicio de autenticacin. 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
61

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 autenticacin para que otros servicios de OpenStack
puedan localizarlos:
keystone service-create --name=glance --type=image
Image Service";
--description="OpenStack
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 mdulo, 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 --containerformat bare --is-public True --progress < cirros-0.3.2-x86_64-disk.img; los
parmetros se pueden cambiar en funcin de las necesidades.
63
glance image-list;
rm -r /tmp/images;
FIN_DE_SCRIPT
Servicio de Computacin
Este servicio ser el encargado de permitir el lanzamiento de instancias de mquinas virtuales. A
continuacin se ver como instalar este servicio. Se puede comenzar mediante el script nova_1.sh,
situado en el Anexo E, para hacerlo ms simplificado, aunque tendr ciertos parmetros por defectos
como las contraseas (todas redborder).
Para una instalacin personalizada se han de seguir los siguientes pasos:
Instalacin de los paquetes necesarios:
yum install openstack-nova-api openstack-nova-cert openstack-novaconductor openstack-nova-console openstack-nova-novncproxy openstack-novascheduler python-novaclient;
La informacin de computacin se guarda en una base de datos. A continuacin se configurar

la localizacin y credenciales de esta:
openstack-config --set /etc/nova/nova.conf database connection
mysql://nova:NOVA_DBPASS@controller/nova
Ahora viene la configuracin del servicio de mensajera 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 configuracin 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
controller
--set
/etc/nova/nova.conf
DEFAULT
vncserver_listen
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

'NOVA_DBPASS';
PRIVILEGES
ON
nova.*
TO
'nova'@'%'
IDENTIFIED
BY
mysql> exit;
A continuacin se puede continuar toda la instalacin mediante el script nova_2.sh, situado en

el Anexo E, con los parmetros por defecto de siempre. Si se desea una instalacin
personalizada se han de seguir los pasos siguientes.
Creacin 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 mdulo de computacin 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=nova@example.com
keystone user-role-add --user=nova --tenant=service --role=admin
65
Configuracin del mdulo 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 computacin con el servicio de identidad para que otros

servicios de OpenStack puedan localizarlo. A continuacin se registrar el servicio y un endpoint
especfico:
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;
67
Para terminar y verificar la instalacin, se listarn las imgenes 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 mdulo:
$ 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
instalacin ms rpida y general. SI se desea una instalacin ms personalizada con contraseas
propias, se han seguir las siguientes instrucciones.
Ahora se ha de crear el usuario neutron:
keystone user-create --name neutron --pass NEUTRON_PASS --email
neutron@example.com
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"
Creacin 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 dems, se proceder a instalar los componentes de red
yum install openstack-neutron openstack-neutron-ml2 python-neutronclient
A continuacin 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 contrasea especifica:
openstack-config
--set
/etc/neutron/neutron.conf
mysql://neutron:NEUTRON_DBPASS@controller/neutron
database
connection
69
Configuracin del servicio de red para usar el servicio de autenticacin 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 mensajera 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 computacin sobre los cambios en la
topologa:
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 continuacin se configurar el servicio de red para usar un plug-in de mdulo 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 trfico
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 distribucin usado (neutron-compute), se ha de reconfigurar el servicio de

computacin para gestionar las redes a travs del servicio de red.
openstack-config --set /etc/nova/nova.conf DEFAULT network_api_class
nova.network.neutronv2.api.API
71
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 instalacin, los scripts de iniciacin del servicio de red esperan un enlace simblico
/etc/neutron/plugin.ini apuntando al fichero de configuracin asociado con el plug-in
elegido. Usando ML2, por ejemplo, el enlace simblico 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 computacin:

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 grfica que ayudar a la gestin de
OpenStack
En primer lugar se instalarn los paquetes necesarios:
yum install memcached python-memcached mod_wsgi openstack-dashboard
Posteriormente se han de configurar algunos parmetros del fichero /etc/openstackdashboard/local_settings para permitir todos los hosts y poner el host de
OpenStack en el nodo controlador:
ALLOWED_HOSTS = [*]
OPENSTACK_HOST = "controller"
Tambin 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 poltica 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
ANEXO B: INSTALACIN 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.
73
74


Y se comprueba.
ntpq np
Database
La mayora de servicios de OpenStack requieren una base de datos para guardar informacin.
Para ello se debe instalar la librera de MySQL Python en los nodos no controller. Ya realizado en el script.
OpenStack packages
Si se quiere recurrir a una instalacin ya con una configuracin predeterminada se puede ejecutar el
script packages.sh del Anexo E.
75
yum install http://repos.fedorapeople.org/repos/openstack/openstackicehouse-3.noarch.rpm
icehouse/rdo-release-
Por ejemplo:
yum upgrade
FIN_DE_SCRIPT
reboot
76

En este equipo solo se instalar el mdulo de red puesto que esa es su funcin
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 configuracin general donde las contraseas sern redborder y la IP de tnel
ser 10.0.152.101. Si se desea una instalacin ms compleja y personalizada, se ha seguir con los
pasos descritos a continuacin.
A continuacin se instalaran los componentes del servicio de red:
yum install openstack-neutron openstack-neutron-ml2 openstack-neutronopenvswitch
Ahora se instalarn los componentes ms comunes del servicio de red. La configuracin de estos
componentes incluyen el mecanismo de autenticacin, el servicio de mensajera y los plug-ins.
Para ello se han de escribir las siguientes lneas:
keystone



auth_protocol http

auth_port 35357


admin_user neutrn
77


controller

router
Ahora se proceder a configurar el agente de capa 3 (L3). Este agente proporciona servicios de
encaminamiento para instanciar redes virtuales.
Se ejecutarn los siguientes comandos:
openstack-config --set /etc/neutron/l3_agent.ini
neutron.agent.linux.interface.OVSInterfaceDriver
DEFAULT
interface_driver
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

neutron.agent.linux.dhcp.Dnsmasq
openstack-config
True
--set
/etc/neutron/dhcp_agent.ini
DEFAULT
DEFAULT
dhcp_driver
use_namespaces
A continuacin se proceder a configurar el agente de metadatos, el cual proporciona informacin de

configuracin como por ejemplo los credenciales para el acceso remoto a instancias.
En primer lugar se ha de ejecutar los siguientes comandos reemplazando las contraseas 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

neutrn
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 computacin 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 computacin:

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
79


Configuracin del servicio Open vSwitch (OVS). Este servicio proporciona la estructura de la capa
inferior del encaminamiento virtual para las instancias. El puente de integracin br-int maneja el
trfico de red interno a la instancia con OVS. El puente exterior br-ex maneja el trfico de red externo
a la instancia con OVS. El puente exterior requiere un puerto en la interfaz fsica 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 aade el puente de integracin:

ovs-vsctl add-br br-int
Se aade el puerto externo:

ovs-vsctl add-br br-ex
Se aade un puerto al puente externos que conecta la interfaz fsica 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 iniciacin del agente de OVS busca explcitamente el
fichero de configuracin del plug-in de OVS antes que un enlace simblico
/etc/neutron/plugin.ini apuntando al fichero de configuracin 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/neutronopenvswitchagent.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
ANEXO C: INSTALACIN 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 configuracin de las interfaces es, porque al ser el nodo
compute un equipo fsico y tener solo una interfaz de red, se han virtualizando dos interfaces teniendo realmente
una fsica.
Fichero /etc/sysconfig/network-scripts/ifcfg-eth0.151
81
82
Fichero /etc/sysconfig/network-scripts/ifcfg-eth0.152

Y se comprueba.
ntpq np
Database
La mayora de servicios de OpenStack requieren una base de datos para guardar informacin.
Para ello se debe instalar la librera de MySQL Python en los nodos no controller. Ya realizado en el script.
83
OpenStack packages
Si se quiere recurrir a una instalacin ya con una configuracin predeterminada se puede ejecutar el script
packages.sh del Anexo E.
yum install http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-releaseicehouse-3.noarch.rpm
Por ejemplo:
yum upgrade
FIN_DE_SCRIPT
reboot
84

En este nodo solo se instalan el servicio de computacin y el de red.
Servicio de Computacin
El servicio de computacin delega en un hypervisor para correr instancias de mquinas virtuales.
OpenStack puede usar varios hypervisores, pero esta gua usa KVM. Se puede instalar mediante el
script nova_compute.sh, que se puede encontrar en el Anexo G, para hacerlo ms simplificado, aunque
tendr ciertos parmetros por defectos como las contraseas (todas redborder).
Para una instalacin personalizada se han de seguir los siguientes pasos.
En primer lugar se han de instalar los paquetes del servicio de computacin:
yum install openstack-nova-compute
A continuacin se editar el fichero de configuracin /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
Configuracin del servicio de computacin para usar el servicio de mensajera Qpid a travs de las
siguientes caractersticas de configuracin:
openstack-config --set /etc/nova/nova.conf DEFAULT rpc_backend qpid
openstack-config --set /etc/nova/nova.conf DEFAULT qpid_hostname

controller
85
Configuracin del servicio de computacin 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
openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen

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

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, sltese 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
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 configuracin general donde las contraseas sern redborder y la IP de tnel
ser 10.0.152.102. Si se desea una instalacin ms compleja y personalizada, se ha seguir con los pasos
descritos a continuacin.
A continuacin se instalaran los componentes del servicio de red:
yum install openstack-neutron openstack-neutron-ml2 openstack-neutronopenvswitch
Ahora se instalarn los componentes ms comunes del servicio de red. La configuracin de estos
componentes incluyen el mecanismo de autenticacin, el servicio de mensajera y los plug-ins.
Para ello se han de escribir las siguientes lneas:
keystone



auth_protocol http

auth_port 35357


admin_user neutrn



controller

router
87
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
openstack-config
--set
enable_tunneling True
/etc/neutron/plugins/ml2/ml2_conf.ini
ovs


Configuracin del servicio Open vSwitch (OVS). Este servicio proporciona la estructura de la capa
inferior del encaminamiento virtual para las instancias. El puente de integracin br-int maneja el
trfico 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 aade el puente de integracin:

ovs-vsctl add-br br-int
Debido al modo de distribucin usado (neutron-compute), se ha de reconfigurar el servicio de

computacin para gestionar las redes a travs 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 iniciacin del agente de OVS busca explcitamente el
fichero de configuracin del plug-in de OVS antes que un enlace simblico
/etc/neutron/plugin.ini apuntando al fichero de configuracin 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/neutronopenvswitchagent.orig
sed -i's,plugins/openvswitch/ovs_neutron_plugin.ini,plugin.ini,g'
/etc/init.d/neutron-openvswitch-agent
Se reinicia el servicio de computacin:

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
89
90
ANXO D: INSTALACIN Y CASOS DE USO DE CHEF

Este anexo explicar cmo 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
Instalacin de Chef Server

A continuacin se proceder a la xplicacion de la instalacin del servidor de Chef. Para ello se han
de realizar los siguientes pasos.
rpm -ivh https://opscode-omnibuspackages.s3.amazonaws.com/el/6/x86_64/chef-server-11.1.41.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 sern usados por Chef para mantener el Servidor de Chef 11.x.
Por ltimo verificar la instalacin 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 versin 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
91
92
Anxo D: Instalacin y Casos de Uso de Chef
Configuracin
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 fcil de hacerlo es creando la
siguiente entrada en el fichero knife.rb:
knife[:openstack_auth_url]= http://controller:5000/v2.0/tokens"
knife[:openstack_username] = "admin"
knife[:openstack_password] = "redborder"
knife[:openstack_tenant] = "admin
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-f8e145f3-92b6-7fd7351c8324 -r 'role[_member_]';
Con la anterior lnea se est instanciando con el usuario demo, contrasea redborder e inquilino demo la
imagen 2cf8e04b-4a3b-4321-8cf6-ee7f6-ee711e81beec con el sabor 1, en la red dadc70d3-f8e1-45f3-92b67fd7351c8324 con el role member y un endponint de la API en 'http://controller:8774/v2/%(tenant_id)s'.
ANXO E: SCRIPTS DEL NODO CONTROLADOR

config_red.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;
packages.sh
yum -y install yum-plugin-priorities;
yum -y install
http://repos.fedorapeople.org/repos/openstack/openstackicehouse/rdo-release-icehouse-3.noarch.rpm;
yum -y install http://dl.fedoraproject.org/pub/epel/6/x86_64/epelrelease-6-8.noarch.rpm;
yum -y install openstack-utils;
yum -y install openstack-utils;
yum -y upgrade;
93
94
keystone_1.sh
yum install -y openstack-keystone python-keystoneclient;
openstack-config
--set
/etc/keystone/keystone.conf
database
connection mysql://keystone:redborder@controller/keystone;
keystone_2.sh
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 --keystonegroup 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=antoniocobosdominguez@gmail.com
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=antoniocobosdominguez@gmail.com;
keystone tenant-create --name=demo --description="Demo Tenant";

keystone user-role-add --user=demo --role=_member_ --tenant=demo;
keystone
Tenant";
tenant-create
--name=service
keystone
service-create
--name=keystone
description="OpenStack Identity";
--description="Service
--type=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
url=http://controller:35357/v2.0 token-get;
--os-auth-
keystone --os-username=admin --os-password=redborder --os-tenantname=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" >> adminopenrc.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
openrc.sh;
OS_AUTH_URL=http://controller:35357/v2.0"
source admin-openrc.sh;
keystone token-get;
keystone user-list;
keystone user-role-list --user admin --tenant admin;
>>
demo-
95
96
clients.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;
glance_1.sh
yum install openstack-glance python-glanceclient;
openstack-config --set /etc/glance/glance-api.conf database
connection mysql://glance:redborder@controller/glance;
openstack-config
--set
/etc/glance/glance-registry.conf
database
connection
mysql://glance:redborder@controller/glance;
openstack-config --set
rpc_backend qpid;
/etc/glance/glance-api.conf
DEFAULT
openstack-config --set /etc/glance/glance-api.conf

qpid_hostname controller;
DEFAULT
glance_2.sh
su -s /bin/sh -c "glance-manage db_sync" glance;
keystone user-create
--name=glance
email=antoniocobosdominguez@gmail.com;
--pass=redborder
--
keystone user-role-add
role=admin;
--tenant=service
--
--user=glance
openstack-config
--set
keystone_authtoken auth_uri http://controller:5000;
openstack-config
--set
keystone_authtoken auth_host controller;
openstack-config
--set
keystone_authtoken auth_port 35357;
openstack-config
--set
keystone_authtoken auth_protocol http;
openstack-config
--set
keystone_authtoken admin_tenant_name service;
openstack-config
--set
keystone_authtoken admin_user glance;
openstack-config
--set
keystone_authtoken admin_password redborder;
openstack-config
--set
paste_deploy flavor keystone;
openstack-config
--set
openstack-config
--set
openstack-config
--set
openstack-config
--set
97
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 servicelist | 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/cirros0.3.2-x86_64-disk.img;
source /root/admin-openrc.sh;
glance image-create --name "cirros-0.3.2-x86_64" --diskformat 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
yum -y install openstack-nova-api openstack-nova-cert
openstack-nova-conductor openstack-nova-console openstacknova-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;
nova_2.sh
su -s /bin/sh -c "nova-manage db sync" nova;
keystone user-create --name=nova --pass=redborder -email=antoniocobosdominguez@gmail.com;
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;
99
100

auth_port 35357;
admin_user nova;
keystone service-create --name=nova --type=compute
description="OpenStack Compute";
--
keystone endpoint-create --service-id=$(keystone servicelist | 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
antoniocobosdominguez@gmail.com;
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 servicelist | 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;
101
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;
103

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
ANXO F: SCRIPTS DEL NODO DE RED

config_red_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;
neutron_network.sh
yum -y install openstack-neutron openstack-neutron-ml2 openstackneutron-openvswitch;
105
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;
107
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/neutronopenvswitch-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;
ANXO G: SCRIPTS DEL NODO COMPUTE

neutron_compute.sh
yum -y install openstack-neutron-ml2 openstack-neutronopenvswitch;
core_plugin ml2;
type_drivers gre;
tenant_network_types gre;
mechanism_drivers openvswitch;
109
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;
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;
service neutron-openvswitch-agent restart;
nova_compute.sh
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;
111
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
True;
--set
/etc/nova/nova.conf
DEFAULT
vnc_enabled
openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen

0.0.0.0;
openstack-config
--set
/etc/nova/nova.conf
vncserver_proxyclient_address compute;
DEFAULT
openstack-config
--set
/etc/nova/nova.conf
novncproxy_base_url http://controller:6080/vnc_auto.html;
DEFAULT
openstack-config
controller;
--set
/etc/nova/nova.conf
service libvirtd start;

service messagebus start;
chkconfig libvirtd on;
chkconfig messagebus on;
chkconfig openstack-nova-compute on;
DEFAULT
glance_host
ANEXO H: PINGS
Ping desde el nodo controlador a internet:
Ping desde el nodo controlador a nodo de red (interfaz de gestin):
Ping desde el nodo controlador a nodo compute (interfaz de gestin):
113
114
Ping desde el nodo de red a internet:
Ping desde el nodo de red a nodo controlador (interfaz de gestin):
Ping desde el nodo de red a nodo compute (tnel de instancia):
Ping desde el nodo de compute a internet:
Anexo H: Pings
Ping desde el nodo de compute a nodo controlador (interfaz de gestin):
Ping desde el nodo de compute a nodo de red (tnel de instancia):
115
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
117
NDICE DE CONCEPTOS
Instancia: Clon de una imagen que se crea a demanda del usuario
en uno de los nodos del cloud.
i
EC2 (Elastic Cloud Computing): Es un servicio web que proporciona capacidad informtica con tamao
modificable en la nube. Est diseado para facilitar a los desarrolladores recursos informticos escalables
basados en web.
ii
PXE: Preboot eXecution Environment (Entorno de ejecucin de prearranque), es un entorno para arrancar e
instalar el sistema operativo en ordenadores a travs de una red, de manera independiente de los dispositivos de
almacenamiento de datos disponibles (como discos duros) o de los sistemas operativos instalados.
iii
Qpid: Sistema de mensajera que implemente AMQP (Advanced Message Queiuing Protocol). Proporciona
gestin de transacciones, colas, distribuciones, seguridad, gestin y soporte de multiplataformas heterogneas.
iv
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, organizacin o proyecto.
v
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.
vi
vii
Nodo: Punto de interseccin, conexin o unin de varios elementos que confluyen en el mismo lugar.
KVM: Mquina virtual basada en el ncleo.Es una solucin para implementar virtualizacin completa con
Linux.
viii
QEMU: emulador de procesadores basado en la traduccin dinmica de binarios (conversin del cdigo
binario de la arquitectura fuente en cdigo entendible por la arquitectura husped). QEMU tambin tiene
capacidades de virtualizacin dentro de un sistema operativo, ya sea GNU/Linux, Windows, o cualquiera de los
admitidos.
ix
Bond: Bonding es una forma de obtener enlaces redundantes en bridges, tanto en aparatos de alta gama, como
en mquinas con software libre.
x
REST: REpresentational State Transfer, es un tipo de arquitectura de desarrollo web que se apoya totalmente
en el estndar HTTP. REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier
dispositivo o cliente que entienda HTTP, por lo que es increblemente ms simple y convencional que otras
alternativas que se han usado en los ltimos diez aos como SOAP y XML-RPC.
xi
Tokens: Un texto de bits arbitrarios que es usado para acceder a los recursos. Cada token dice q eu servicios
se pueden acceder.
xii
119
120
ndice de Conceptos
Usuario: Representacin digital de una persona, sistema, oservicio que quiere usar los servicios de la nube de
OpenStack.
xiii
xiv
Credenciales: Datos conocidos solo por el usuario que demuestra que es l.
xv
Autenticacin: Acto de confirmar la identificacin de un usuario.
Servicio: Proporciona uno o mas endpoint a travs de los cuales, los usuarios pueden acceder a operaciones
de rendimieno y accesos de recursos.
xvi
Endpoint: Direccin de red accesible, normalmente descrita por una URL, donde se pude tener acceso al
servicio.
xvii
xviii
Rol: Personalidad que un usuario asume y que este sabe a que cosa especificas puede acceder con ese rol.
Daemons: Ttipo especial de proceso informtico 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 configuracin
del demonio y polticas del sistema. La palabra daemon viene de las siglas en ingles D.A.E.MON (Disk And
Execution Monitor).
xix
Metadatos: El concepto de metadatos es anlogo al uso de ndices para localizar objetos en vez de datos. Por
ejemplo, en una biblioteca se usan fichas que especifican autores, ttulos, casas editoriales y lugares para buscar
libros. As, los metadatos ayudan a ubicar datos.
xx
Linux network namespaces: Instalacion de linux que permite tener un conjnto de interfaces y entradas a la
tabla de enrutamiento simples.
xxi
IPs flotantes: Direccin IP pblica que puede asociarse a diferentes instancias con el fin de acceder a ellas
desde fuera.
xxii
Django: Framework de desarrollo web de cdigo abierto, escrito en Python, que respeta el paradigma
conocido como Model Template View. Permite una creacin de sitios web mas sencilla.
xxiii
xxiv
Orquestacin: Gestin de sistemas y automatizacin de insfraestructura de la nube.
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.
xxv
xxvi
Ruby: Lenguaje de programacin interpretado, reflexivo y orientado a objetos.
Erlang: Un lenguaje de programacin concurrente (u orientado a la concurrencia) y un sistema de ejecucin

que incluye una mquina virtual (BEAM) y bibliotecas (OTP).
xxvii
121
Framewotk: Estructura conceptual y tecnolgica de soporte definido, normalmente con artefactos o

mdulos de software concretos, que puede servir de base para la organizacin y desarrollo de software.
Tpicamente, 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.
xxviii
Cookbooks: Unidad fundamental de distribuvcin de configuracin y pliticas. Cada cookbook (libro de

recetas) define un escenario y contiene todo los componentes que se requieren para montar ese escenario.
xxix
xxx
Recipes: Receta del Cookbook.
xxxi
DSL: Lenguaje de computacin especializado en una dominio de aplicacin en particular.
xxxii
Front-end: Parte del software que interacta con el o los usuarios.

Memoria Telecuminicaciones

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Memoria Telecuminicaciones

Загружено:

Авторское право:

Доступные форматы

Proyecto Fin de Grado

Grado en Ingeniera de las Tecnologa de

Despliegue de arquitectura cloud basada en

Autor: Antonio Cobos Domnguez

Dep. Ingeniera Telemtica

Proyecto Fin de Grado

Despliegue de arquitectura cloud basada en

Dep. Ingeniera Telemtica

Antonio Cobos Domnguez

Pablo Nebrera Herrera

Acuerdan otorgarle la calificacin de:

El Secretario del Tribunal

Escenario y Configuracin Inicial

Componentes Bsicos de OpenStack

Lanzar una Instancia

Componentes Adicionales de OpenStack

Integracin con Chef

Anexo A: Instalacin en Nodo Controlador

Anexo B: Instalacin en Nodo de Red

Anexo C: Instalacin en Nodo Compute

Anxo D: Instalacin y Casos de Uso de Chef

Anxo E: Scripts del Nodo Controlador

Anxo F: Scripts del Nodo de Red

Anxo G: Scripts del Nodo Compute

Mdulos e IP de los Nodos

Visin general de Dashboard

Esquema general de redes

Creacin sabor RedBorder

Asociacin de IPs Flotantes

Estado de Instancia con IPs flotantes

Acceso a maquina RedBorder

Diagrama completo de OpenStack

Discover Host Configuration Protocol

a Compuacion en la Nube (Cloud computing) es el desarrollo y la utilizacin de capacidad de

Servicio disponible de forma automtica y a demanda.

Accesible a travs de la red.

Se comparten los recursos con otros usuarios.

Aislamiento y seguridad entre ellos.

Software como Servicio (Software as a Service-SaaS): Aplicacin como servicio en la nube

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

Se proporciona toda la plataforma de desarrollo y despliegue de una aplicacin al desarrollador.

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

Gestin por Terceros

Gestin por Terceros

Gestin por Terceros

Funcionalidad completa: IPMI,

Recursos mejor aprovechados

Se pierde cierta funcionalidad

Dependencia de varias maquinas

Tabla 1: Diferencias entre maquinas virtuales y fsicas

Sistema Operativo Base

Repositorio de paquetes de OpenStack

Red Hat Distributed OpenStack (RDO)

Separacion de red tenant v

Servicio de Imagen (glance) backend

Servicio de Identidad (keystone) driver

Servicio de Almacenamiento en Bloque (cinder)

2 ESCENARIO Y CONFIGURACIN INICIAL

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

Disco Duro (GB):50

Disco Duro (GB):22

Escenario y Configuracin Inicial

Virtuales: 2 (creadas en la nica fsica).(bond)x