despliegue de arquitectura cloud basada en openstack y su...
Post on 22-Apr-2020
13 Views
Preview:
TRANSCRIPT
Proyecto Fin de Grado
Grado en Ingeniería de las Tecnología de
Telecomunicación
Despliegue de arquitectura cloud basada en
OpenStack y su integración con Chef sobre CentOS
Autor: Antonio Cobos Domínguez
Tutor: Pablo Nebrera Herrera
Dep. Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2014
Proyecto Fin de Grado
Grado en Ingeniería de las Tecnologías de Telecomunicación
Despliegue de arquitectura cloud basada en
OpenStack y su integración con Chef sobre CentOS
Autor:
Antonio Cobos Domínguez
Tutor:
Pablo Nebrera Herrera
Profesor asociado
Dep. Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2014
Proyecto Fin de Carrera: Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre
CentOS
Autor: Antonio Cobos Domínguez
Tutor: Pablo Nebrera Herrera
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2014
El Secretario del Tribunal
A mi familia
A mis amigos
A mis maestros
i
Agradecimientos
Este es el único rincón personal que hay en esta consecución de hojas llenas de pensamientos frios y
calculados.
Es el momento de agradecer con palabras los actos de empuje, ánimo y apoyo por parte de mis allegados.
Doy gracias a mis padres. A mi madre Rosario y a mi padre Antonio. Dos personas a las que admiro y tomo
como referente en la vida. Sin ellos y su idea de cómo criar a un hijo no estaría escribiendo estas líneas que
culminan una etapa de mi vida. Como dice mi madre, “la mejor herencia que se le puede dar a un hijo es una
buena educación”. Ellos son la gran motivación de este proyecto. Quiero darles esa satisfación que se que
sienten cuando yo alcanzo un objetivo en la vida. Ellos me guian y yo los sigo.Por ello expreso este
sentimiento de eterno agradecimiento hacia ellos. Por sus consejos, sus riñas, su cariño y su amor.
Os quiero.
No puedo olvidarme de mi Abuela Ana, mi Abuela Chica, mi titi Fali, mi tata Pili, mi tio Baldo, mi tia Nieves,
mi tio Carlos, mi tia Toñi, mi tio Seba y mi tia Carlota , que siempre he tenido su apoyo, cariño y sus
dineritos “bajo cuerda” que siempre me vienen bien.
Merecen una mención especial mis dos abuelos, que velan por mí desde el cielo y me aportan ese equilibrio
espiritual que todo el mundo, en ciertos momentos de su vida, necesita.
A mis amigos que paramos en San Diego, a mis amigos “los Pimientos”, a mis amigos de mi barrio de
Torreblanca y a mis amigos de la facultad que me han acogido en su piso durante la elaboración de este
documento. A todos ellos, Gracias.
A mi colega Carlos porque siempre le tengo algo especial, al igual que a mi Javi. Por los buenos momentos
que aun quedan por llegar compañeros. Muchas Gracias.
Gracias a todos por estar conmigo y aparecer en mi vida desde que me embarque en este proyecto hace 4 años,
que al principio parecía que este fin no iba a llegar.
GRACIAS
iii
Resumen
El Cloud Computing tiene como objetivo la dotación de flexibilidad, elasticidad y alta disponibilidad a los
servicios que se proporcionan a través de la nube. OpenStack, un software de código abierto, hace de la nube
una infraestructura para el despliegue de servicios distribuidos. Este estudio se centrará en la configuración e
implantación de este software al proyecto RedBorder Horama, así como la valoración de las configuraciones,
distribuciones, y software para una mejor integración.
Se ha realizado una amplia investigación sobre Cloud Computing, un mundo inifnito con múltiples
posibilidades, centrado en el lanzamiento de instancias, el cual es el pilar fundamental de esta tecnología. Gracias
a eso se podrá acceder a máquinas remotas, con un pago por uso y con un aprovisionamiento dinamico. Se
implementa también el gestor de sistemas y automatización de insfraestructura de la nube, Chef, para
proporcionar una gestión más potente de ésta.
v
Abstract
The aim of Cloud Computing is to give flexibility, elasticity and high availability to the services provided by the
network. Openstack, an open-source software, makes the cloud an infrastructure that allows the deployment of
distributed services. This research will be focus on the configuration and implementation of this software to the
RedBorder Horama Project, also the evaluation of the configurations, distributions and software to improve the
integration with it.
A research with a big scope about Cloud Computing has been done in this study, a whole world which has many
posibilities, centered on instances launching, which is the main funcionality of this tecnology. Due to this fact,
it will be posible to access to remote hosts, with a charge by demand and with dinamic provisioning. Chef has
been also implementing which is a system and automation framework cloud manager to provide a better
management of the services.
Índice
Agradecimientos i
Resumen iii
Abstract v
Índice vi
Índice de Tablas ix
Índice de Figuras xi
Notación xiii
1 Introducción 1
2 Escenario y Configuración Inicial 5 2.1 Topologia 5
2.1.1 Caracteristias físicas 5 2.1.2 Escenario 6
2.2 Configuración inicial 7
3 Componentes Básicos de OpenStack 11 3.1 Openstack Identity Service (Keystone) 13 3.2 Openstack Image Service (Glance) 14 3.3 OpenStack Compute (Nova) 15 3.4 OpenStack Object Storage (Swift) 16 3.5 OpenStack Block Storage (Cinder) 17 3.6 OpenStack Networking (Neutron) 18 3.7 OpenStack Dashboard (Horizon) 19
4 Lanzar una Instancia 21 4.1 Usuarios 21
4.1.1 Administrador 21 4.1.2 Usuarios normal 21
4.2 Componentes 21 4.2.1 Redes 21 4.2.2 Routers 21 4.2.3 Instancia 22
5 Componentes Adicionales de OpenStack 29 5.1 OpenStack Orchestration (Heat) 29 5.2 OpenStack Telemetry (Ceilometer) 30 5.3 DataBase OpenStack (Trove) 31 5.4 Hadoop Cluster OpenStack (Sahara) 33 5.5 Nota aclaratoria 34
6 Integración con Chef 35 6.1 ¿Qué es Chef? 35 6.2 Chef Server 35 6.3 Chef Client 36
vii
6.3.1 Knife OpenStack 36
7 Presupuesto 39
8 Lineas de Mejora 41
Anexo A: Instalación en Nodo Controlador 43
Anexo B: Instalación en Nodo de Red 73
Anexo C: Instalación en Nodo Compute 81
Anéxo D: Instalación y Casos de Uso de Chef 91
Anéxo E: Scripts del Nodo Controlador 93
Anéxo F: Scripts del Nodo de Red 105
Anéxo G: Scripts del Nodo Compute 109
Anexo H: Pings 113
Referencias 117
Índice de Conceptos 119
ix
ÍNDICE DE TABLAS
Tabla 1: Diferencias entre maquinas virtuales y físicas 3
Tabla 2: Componentes 4
Tabla 3: Presupuesto 39
xi
ÍNDICE DE FIGURAS
Figura 1. Tipos de aaS 2
Figura 2. Escenario de Red 6
Figura 3. Módulos e IP de los Nodos 7
Figura 4. Componentes en controlador 8
Figura 5. Componentes en red 9
Figura 6. Componentes en compute 9
Figura 7. Diagrama OpenStack 12
Figura 8. Autenticación en Keystone 14
Figura 9. Diagrama Glance 15
Figura 10. Diagrama Nova 16
Figura 11. Diagrama Swift 17
Figura 12. Diagrama Cinder 18
Figura 13. Diagrama Neutron 19
Figura 14. Autenticación en Dashboard 20
Figura 15. Visión general de Dashboard 20
Figura 16. Esquema general de redes 23
Figura 17. Pestaña Instancias 23
Figura 18. Modificación de Sabores 24
Figura 19. Creación sabor RedBorder 24
Figura 20. Lanzar Instancia 25
Figura 21. Redes de la Instancia 26
Figura 22. Estado de la Instancia 26
Figura 23. Asociación de IPs Flotantes 27
Figura 24. Estado de Instancia con IPs flotantes 27
Figura 25. Acceso a maquina RedBorder 28
Figura 26. Diagrama de Heat 30
Figura 27. Diagrama de Ceilometer 31
Figura 28. Diagrama de Trove 32
Figura 29. Diagrama de Sahara 33
Figura 30. Diagrama completo de OpenStack 34
Figura 31. Estructura de Chef 36
xiii
Notación
DHCP Discover Host Configuration Protocol
KVM Kernel-based Virtual Machine
CPU Central Processing Unit
RAM Random Access Memory
IPMI Intelligent Platform Management Interface
PXE Preboot eXecution Environment
S.O Sistema Operativo
API Application Programming Interface
DNS Domain Name System
LDAP Lightweight Directory Access Protocol
SMTP Simple Mail Transfer Protocol
BBDD Base de Datos
VM Virtual Machine
HTTP HyperText Transfer Protocol
RPC Remote Procedure Call
REST REpresentational State Transfer
JSON JavaScript Object Notation
DSL Domain-Specific Language
1
1 INTRODUCCIÓN
a Compuacion en la Nube (Cloud computing) es el desarrollo y la utilización de capacidad de
procesamiento computacional basado en Internet (la “nube”). Este concepto agrupa diversas
características el cual lo hacen más atractivo e interesante para las empresas. Algunas de estas son:
Servicio disponible de forma automática y a demanda.
Accesible a través de la red.
Modelo que permite que solo una instanciai se ejecute en el servidor, pero sirviendo a multiples clientes
(modelo Multi-Tenancy).
o Se comparten los recursos con otros usuarios.
o Aislamiento y seguridad entre ellos.
Los recursos (CPU, Disco Duro y RAM principalmente), cuyo origen pueden ser de un solo host o un
conjunto de ellos (cluster), se agrupanen particiones (pools) [2].
Elasticidad.Basado en el modelo EC2ii.
Pago por uso.
Modelo de negocio “…aaS” (as a Service) basado en la venta de licencias o hardware. Ofrece servicios con
características de cloud. Se definen tres capas o niveles de este modelo:
Software como Servicio (Software as a Service-SaaS): Aplicación como servicio en la nube
o El usuario utiliza una aplicación a través de la web en lugar de tenerla instlada en el propio
equipo. Por ejemplo los servicios de Google u Office365.
Plataforma como Servicio (Platform as a Service-PaaS): Plataforma de desarrollo web en la nube
o Se proporciona toda la plataforma de desarrollo y despliegue de una aplicación al desarrollador.
Por ejemplo Google App Engine (ofrece esa plataforma para que los usuarios desarrollen y
desplieguen aplicaciones en ella).
Infraestructura como Servicio (Infrastructure as a Service-IaaS): Infraestructura como servicio en
la nube
o Se proporciona principalmente capacidad de cómputo, redes ydiversos modos de
almacenamiento. Por ejemplo Amazon Web Services (AWS), OpenStack y Windows Azure.
L
Gran parte de las dificultades por las que atraviesa el mundo se deben a
que los ignorantes están completamente seguros y los inteligentes llenos
de dudas.
Bertrand Russell
Introducción
2
Dentro de los modelos de negocio se puede optar por diferentes tipos de despliegue.
Publico: Se necesita una IP pública para que los usuarios puedan acceder desde cualquier lugar.
Privado: No se necesitan IP’s publicas por tanto el área de uso queda restringida a la red local. Esta
opción es útil para configurar los recursos propios de una manera mas flexibes y con toda la carga en
los servidores.
Híbrido: Se utilizan recursos de la nube privada o de una o varias nubes públicas en función de las
características de cada caso o las necesidades puntuales que haya. Se suele utilizar una API común que
permita una buena integración.
Existen ciertas diferencias entre la estructura clásica de maquinas virtuales o físicas y la infraestructura
en nube. A continuación se presentan alguna de ellas:
Ges
tión P
ropia
Ges
tión P
ropia
Ges
tión P
ropia
Gestió
n p
or T
erceros
Gestió
n p
or T
erceros
Gestió
n p
or T
erceros
Datacenter
Virtualizado IaaS PaaS SaaS
Figura 1: Tipos de aaS
3 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Tabla 1: Diferencias entre maquinas virtuales y físicas
Antes de elegir una opción se ha de analizar el entorno donde vamos a desplegar el sowtware de computación
en la nube.
El entorno a desarrollar se situa en la empresa Eneo Tecnología, una empresa dedicada a la seguridad y
visibilidad en redes, cuyo producto principal, RedBorder, se encarga de llevar a cabo esas características
mediante el uso de sensores IPS y netflow en términos generales. Se pretende realizar una nube privada para
disponer de sus servicios de una forma más flexible y eficiente. Una vez realizado ese desarrollo se ampliará
hacia la nube pública para que los clientes puedan acceder a estos servicios desde cualquier lugar del mundo.
Se pretende, una vez finalizado el despliegue, instanciar una imagen de RedBorder al cliente deseado. Puesto
que se desea un control total sobre los recursos proporcionados y la escalabilidad, elasticidad y flexibilidad de
los servidores (la nube).
Maquinas físicas Maquinas virtuales
Ventajas
Aislamiento de servicios
Funcionalidad completa: IPMI,
PXEiii, DHCP…
Aislamiento de servicios
Recursos mejor aprovechados
Inconvenientes
Muchos recursos
desaprovechados
Se pierde cierta funcionalidad
Dependencia de varias maquinas
de un solo equipo físico
Introducción
4
Dentro de todos los IaaS posibles se encuentran varios de pago como son Amazon Web Service (AWS),
BlueLock, IBM Cloud, etc. Por tanto se optará por OpenStack, el cual ofrece la mayoría de las características
de los IaaS mencionados anteriormente. OpenStack se trata de un proyecto de plataforma de cloud computing
open source iniciada en el verano de 2010 por el proveedor IaaS RackSpace y NASA.
Tabla 2: Componentes.
Componente Detalles
Versión Icehouse
Sistema Operativo Base CentOS 6.5
Repositorio de paquetes de OpenStack Red Hat Distributed OpenStack (RDO)
Hypervisor KVM
BBDD MySQL
Cola de Mensajes Qpidiv
Servicio de red OpenStack Networking
Separacion de red tenant v VLAN
Servicio de Imagen (glance) backend GlusterFSvi
Servicio de Identidad (keystone) driver SQL
Servicio de Almacenamiento en Bloque (cinder)
backend GlusterFS
5
2 ESCENARIO Y CONFIGURACIÓN INICIAL
l escenario que se plantea es el disponible en la empresa donde se va a desarrollar OpenStack. Para ello se
va a proceder a explicar las maquinas (hosts) necesarias para montar el entorno de desarrollo. En primer
lugar se necesita un nodovii (controller node) el cual controla y provee a la nube de una funcionalidad
completa. En segundo lugar se creara un nodo de red (network node) que proporciona la mayor parte de los
servicios de red (DHCP, agente de capa 2, etc) y un tercer nodo (compute node, que mas adelante podrán ser
multiples nodos según demanda de recursos) que albergará las maquinas virtuales y gestionará la compatibilidad
de estas con los modos KVMviii o QEMUix.
2.1 Topologia
2.1.1 Caracteristias físicas
Controller Node
Este nodo será desplegado en una maquina virtual dentro de la empresa, con CentOS 6.5 como sistema
operativo base, la cual se le asginará:
o Interfaces de red: 1
o Memoria RAM:2GB
o Disco Duro (GB):50
Network Node
Este nodo será desplegado en una maquina virtual dentro de la empresa, con CentOS 6.5 como sistema
operativo base, la cual se le asignará:
o Interfaces de red: 3
o Memoria RAM:2GB
o Disco Duro (GB):22
E
La arquitectura es arbitraria, pero una vez está hecha, se convierte en
necesaria.
Rafael Moneo
Escenario y Configuración Inicial
6
Compute Node
Este nodo será desplegado en una maquina física (maquina incrustada en rack) puesto que será esta la
que lleve todo el procesamiento computacional de las maquinas virtuales (hypervisor). Tendrá un
sistema operativo base CentOS 6.5. Esta maquina tiene las siguientes características:
o Interfaces de red
Físicas: 1
Virtuales: 2 (creadas en la única física).(bond)x
o Memoria RAM:48GB
o Disco Duro (GB):45
2.1.2 Escenario
Figura 2: Escenario de Red
7 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
2.2 Configuración inicial
A continuación se explicará cómo se asignan las IP´s a los nodos en relación al escenario anterior. En primer
lugar se tiene que configurar una red de gestión (pintadas en rojo en la Fig. 3). Se aprovechará la red de la
empresa para asignar las IP’s de gestión, las cuales pertenecerán a esta. La IP externa (pintada en azul) que se
configurará en el nodo controlador, no tendrá IP (en el Anexo A se explica como hacerlo). Además en el nodo
de red se asignará una IP nueva que pertenecerá a la llamada red de tunelado de instancias (pintada en verde).
Esta red se encargará de crear una conexión directa entre la interfaz del nodo de red y la interfaz del nodo
compute.Si se desea añadir mas compute’s solo habría que asignar una IP nueva dentro de la red de tunelado.
Más adelante se explicará el proceso de instanciar, pero el concepto es que por cada conexión network-compute
se instancien tantas imagenes como VLAN’s se permitan.
Controller Node (IP: 10.0.151.100/24)
El nodo controlador es el responsable de ejecutar el software de gestión de servicios necesario para que
funcione el entorno de OpenStack:
o Proporciona la puerta delantera que las personas usaran (API) para comunicarse con todos los
componentes del entorno.
o Corre un número de servicios a una alta disponibilidad, utilizando Pacemarker y HAProxy
para proveer un IP virtual y funciones de balanceado de carga para que todos los nodos sean
usados.
o Aporta una infraestructura de servicios altamente disponible, como son MySQL y Qpid, que
sustentan a todos los servicios.
Figura 3: Módulos e IP de los Nodos
Escenario y Configuración Inicial
8
o Proporciona lo que es llamado un almacenamiento persistente para los servicios que corren en
el host.
Network Node (IP1:10.0.151.101/24, IP2:10.0.152.101/24,IP3: external -> 10.0.150.0/24)
El nodo de red es el responsable de hacer todas las redes virtuales que se necesiten para que la gente
cree redes públicas o privadas y enlacen sus maquinas virtuales en la red externa:
o Formar el unico punto de entrada y salida para las instanciasque están corriendo en la cima de
de OpenStack.
o Corre todos los servicios de red del entorno, con la excepcion de que la API del servicio de red
corre en el controlador.
Figura 4: Componentes en controlador
9 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Compute Node (IP:10.0.151.102/24, IP2:10.0.152.102/24)
En el nodo compute corren las instancias de maquinas virtuales en OpenStack:
o Corre el minimo de servicios necesarios para facilitar esas intancias.
o Usa almacenamiento local en el nodo para las maquinas virtuales, asi que no se contempla un
fallo en la migración de maquinas virtuales o recuperación de instancias.
Figura 5: Componentes en el nodo de red
Figura 6: Componentes en el compute
Escenario y Configuración Inicial
10
Tanto las configuraciones anteriores como la instalación de todos los componentes
de OpenStack se encuentran anexos a esta memoria.
En primer lugar se ha de llevar a cabo lo expuesto en el Anexo A
En segundo lugar se llevará a cabo lo expuesto en el Anexo B
Y por último se realizará lo indicado en el Anexo C
Solo queda lanzar una intancia, lo cual viene indicado en el Capitulo 4 de esta
memoria “Lanzar una Instancia”.
11
3 COMPONENTES BÁSICOS DE OPENSTACK
penStack se trata de un proyecto grande y modular. Los módulos tienen muchas características comunes
para poder integrarse fácilmente. Todos están escritos en Python, algunos de ellos utilizan AMQP
(Advanced Message Queue Protocol) para el in tercambio de mensajes (en concreto se utilizará Apache
Qpid), incluyen una API RESTful xi para la comunicación entre componentes o externa (clientes), autenticación
basada en tokensxii gestionada a través del componente Keystone y tienen una base de datos propia e
independiente.
Antes de continuar leyendo esta sección se recomienda ver el glosario de conceptos de la sección 3 en el apartado
Conceptos (como usuarioxiii, credencialesxiv, autenticaciónxv, servicioxvi, endpointxvii, rolxviii).
O
Si se puede imaginar, se puede programar.
Anónimo
Componentes Básicos de OpenStack
12
Fig
ura
7:
Dia
gra
ma O
pen
Sta
ck
13 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
3.1 Openstack Identity Service (Keystone)
Este componente se basa en un directorio centralizado que almacena información de:
Usuarios
Proyectos (tenants)
Roles
Servicios y sus endpoints
La información se almacena en un Sistema de Gestión de Base de Datos Relacional (MySQL) y además este
componente (Keystone) debe ser el primero en ser instalado puesto que los demás componente lo usarán como
sistema de autenticación para poder acceder a la información necesario del proyecto (cada uno en su módulo).
Keystone se encarga tanto de manejar los pedidos de la API así como también provee un único punto de
integración para las políticas de OpenStack, catálogos de los servicios, token y autenticación.
Proceso de autenticación:
Usuario envía credneciales a través de la API
Keystone le envía un token temporal y le envía un catálogo de los servicios.
Usuario pregunta por los tenants a los que puede acceder.
Keystone le responde con la lista de tenants a los que puede acceder el usuario.
Usuario envía credenciales con su correspondiente tenant.
Keystone envía al usuario los servicios que tiene disponible dentro de ese tenant y el token de este.
El usuario determina el endpoint correcto para iniciar una instancia a la vez que se le provee a este del
token recibido anteriormente por Keystone.
El endpoint pregunta al modulo Keystone si es es correcto el token recibido y si se le permite usar el
servicio por el que envía la petición.
Keystone le dice al servicio que el usuario esta autorizado para solicitar ese servicio y que los tokens
coinciden.
El servicio crea una nueva instancia y le envía la información al usuario.
Componentes Básicos de OpenStack
14
3.2 Openstack Image Service (Glance)
Glance permite a los usuarios descubrir, registrar, y recuperar imagines de maquinas virtuales. Este servicio
(Glance) ofrece una REST API que permite preguntar los metadatos de la imagen de la maquina virtual y
recuperar una imagen actual. Se pueden guarder las imagenes de maquinas virtuales tanto en un fichero simple
como en el modulo de almacenamiento de objetos que veremos mas adelante.
Este componente gestiona las plantillas de imágenes de los sistemas. Ademas de ello, gestiena las instantaneas
de las instancias Puede soportar diversos formatos: raw, qcow2, vhd, ami, vdi y vmdk.
Una de las ventajas de este componente es su capacidad para crear, gestionar y asimilar snapshots (instancias en
ejecución que pueden ser obtenidas creando una nueva imagen basada en el estado actual del disco de una
instancia en particular).
Dentro de Glance encontraremos:
glance-api acepta los pedidos para la búsqueda, obtención y almacenamiento de imágenes.
El registro de almacenamiento glance-registry procesa y recupera los metadatos de las imágenes.
Posee una base de datos para los metadatos de las imágenes.
También se corren servicios de replicación, para proveer consistencia y disponibilidad a través del
cluster, auditoría y actualización.
Figura 8: Autenticación en Keystone
15 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Figura 9: Diagrama Glance
3.3 OpenStack Compute (Nova)
Este es el componente principal de OpenStack. Gestiona las instancias de imágenes, dónde deben ejecutarse y
el acceso mediante consola.
Soporta diferentes hipervisores: KVM/QEMU, Xen, Hyper-V, VMware ESXi, LXC, Docker.
Permite incluso el aprovisionamiento de máquinas físicas mediante Baremetal/Ironic.
Funcionamiento:
El cliente nova-api acepta y responde a las llamadas del usuario final.
La virtualización es administrada por nova-compute. Crea/finaliza las instancias de VMs a través
de la API del hipervisor utilizado.
La planificación es realizada por nova-schedule. Toma los pedidos de VMs de la cola y determina
dónde debería ejecutarse.
La cola, es el nodo central para el pasaje de mensajes entre daemonsxix.
También dispone de una base de datos que almacena la mayoría de los datos de estado de
compilación y ejecución.
nova-consoleauth, nova-novncproxy, nova-console permiten a los usuarios acceder a las
instancias virtuales a través de un proxy.
Al crear una instancia deberán seleccionar entre las opciones de configuraciones de recursos
virtuales disponibles, llamadas flavors. Luego, pueden agregarse recursos como volúmenes de
almacenamiento persistente y direcciones IP públicas.
Componentes Básicos de OpenStack
16
3.4 OpenStack Object Storage (Swift)
Componente importante de OpenStack, pero independiente del resto. Se trata de un sistema de almacenamiento
redundante y escalable (almacenador de objetos).
El almacenamiento de objetos permite el almacenamiento masivo de datos no estructurados de forma bastante
económica. Hoy en día se utiliza bastante por aplicaciones web. Ademas Swift incluye su propia API y otra
compatible con Amazon S3.
Normalmente es utilizado por Glance para almacenar imágenes. (Antes de continuar se recomienda leer la
sección Objetos del apartado Conceptos).
Tanto los archivos como los objetos tienen metadatosxx asociados a los datos que contienen, pero los objetos son
caracterizados por tener metadatos extendidos. Cada objeto tiene asignado un identificador único que permite a
un servidor o usuario final recupéralo sin necesidad de conocer la ubicación física de la información. Esto es
muy útil para automatizar y racionalizar almacenamiento de datos en entornos de cloud computing.
Se puede mencionar sobre Swift:
El servidor proxy se encarga de aceptar los pedidos entrantes, como archivos para subir, modificaciones a
los metadatos o creación de contenedores; también provee archivos y un listado de los contenedores.
El servidor de cuentas maneja las cuentas asociadas con el servicio.
El servidor de contenedores realiza un mapeo de los contenedores, carpetas, dentro del servicio.
El servidor de objectos administra los objectos, archivos.
También se corren servicios de replicación, para proveer consistencia y disponibilidad a través del cluster,
auditoría y actualización.
Figura 10: Diagrama Nova
17 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
3.5 OpenStack Block Storage (Cinder)
Los volúmenes son dispositivios de bloques que se crean de forma independiente de la instancia y pueden
asociarse y desasociarse de ella cuando se precise.
Cinder es equivalente al componente Amazon EBS. Los volúmenes se crean en el nodo de almacenamiento (por
defecto con LVM) y se conectan a la instancia que se desee mediante algún protocolo de redes de
almacenamiento (iSCSI es el mas utilizado y el que se utilizará en este proyecto).
Cinder incluye controladores para gran cantidad de dispositivos de almacenamiento del mercado. Cuando nova
termina una instancia borra todo el almacenamiento local asociado a ella, pero no los volúmenes, por lo que
estos reciben el nonmbre de almacenamiento permante.
Se puede pensar en los volúmenes como discos externos que se conectan o desconectan de las instancias,
aunque se trate de un mecanismo completamente diferente.
Sobre Cinder:
La API de Cinder permite la manipulación de volúmenes, tipos de volúmenes y snapshots. cinder-api acepta
los pedidos y los enruta a cinder-volume para ser procesados.
cinder-volume reacciona leyendo o escribiendo a la base de datos que mantiene el estado, interactúa con
otros procesos (como el cinder-scheduler) a través de la cola de mensajes y directamente actua sobre el
almacenamiento proveyendo hardware o software.
cinder-scheduler selecciona el nodo para el almacenamiento por bloques óptimo para la creación de un
volumen sobre el.
La cola de mensajes enruta información entre los procesos de Cinder.
Una base de datos almacena el estado de los volúmenes.
Figura 11: Diagrama Swift
Componentes Básicos de OpenStack
18
3.6 OpenStack Networking (Neutron)
Componente encargado de la configuración de redes virtuales, el cual, incluye un buen numero de complementos
(OpenvSwitch, Cisco, Niciria, etc).
Neutron gestiona múltiples redes de forma independiente gracias al uso de Linux network namespacesxxi que
permite que múltiples routers virtuales compartan un dispositivo de red físico.Neutron también se encarga de la
gestión de los grupos de seguridas y de las IPs flotantesxxii.
Neutron tiene como características:
Da a a los tenants de la nube una API para construir topologías de red muy completas, y configurar
políticas de red avanzadas en la nube.Por ejemplo crear una topología de aplicación web multi-tier.
Permite plugins innovadores (codigo abierto y no abierto) que introduce capacidades avanzadas de red.
Por ejemplo usar tunelado L2-in-L3 para evitar los limites de VLAN, proveer garantías de calidad de
servicio (QoS) end-to-end. Usa además protocolos de monitorización como NetFlow.
Permite cualquier topología avanzada de servicios de red que se instauren en las redes de los tenants de
Openstack. Por ejemplo: LB-aaS, VPN-aaS, firewall-aaS, IDS-aaS, data-center-interconnect-aaS.
Mediante la GUI que ofrece Horizon (modulo que veremos mas adelante):
o Neutron borra y crea redes y subredes nivel 2 y 3.
o Inicia maquinas virtuales en una red especifica de Neutron.
API Extensibility Framework, incluye extensiones para:
o “proveedor de red”, el cual mapea las redes L2 de Neutron a una VLAN específica en el centro
de datos físico.
Neutron-server es el principal proceso del servidor de red de OpenStack. Es un daemon en Python que pasa las
peticiones de los usuarios de la API de OPenStack al plug-in configurado. Neutron incluye tres agentes que
interactúan con el proceso principal a través de la cola de mensajes o la API de red estándar de OpenStack:
neutron-dhcp-agent proporciona servicios de DHCP a todas las redes tenant.
neutron-l3-agent proporciona L3/NAT para permitir el acceso a una red externa desde las maquinas
virtuales en las redes tenant.
Figura 12: Diagrama Cinder
19 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
3.7 OpenStack Dashboard (Horizon)
Este componente es el panel de control web de OpenStack desarrollado en Djangoxxiii.
No incluye toda la funcionalidad de la API de cada componente, pero si los métodos mas utilizados.
El panel de control de OpenStack (dashboard) proporciona al administrador y usuarios una interfaz gráfica para
acceder, provisionar y automatizar los recursos basado en la nube. Ademas es fácil incorporar y presentar
productos y servicios para terceros, como son la facturación, la monitorización y las herramientas de gestios
adicionales.
Capacidades de Horizon:
Permite cotrolar a los administradores y usarios su “nivel de computación”, almacenamiento, y
recursos de red.
Como administrador, el panel de control ofrece una vista global del tamaño y estado de la nube. Se
pueden crear usuarios y proyectos, asignar usuarios a proyectos y configurar limites en los recursos
de esos proyectos.
El panel de control proporciona a los usuarios un portal “self-service” para provisionar sus propios
recursos dentro de los limites establecidos por el administrador.
Figura 13: Diagrama Neutron
Componentes Básicos de OpenStack
20
Figura 14: Autenticación en Dashboard
Figura 15: Visión general de Dashboard
21
4 LANZAR UNA INSTANCIA
n este capítulo se describirán los diferentes componentes, y sus funciones, necesarios para el lanzamiento
de una instancia.
4.1 Usuarios
Una vez instalado el componente Keystone ya se pueden crear los diferentes usuarios (Ver Anexo A)
4.1.1 Administrador
Este usuario es el encargado de crear la red donde se alojarán las IP’s las cuales servirán para acceder a las
instancias de las maquinas virtuales. En este caso la red que se creará con este usuario será la perteneciente a la
red de la empresa (10.0.150.0/24). A esta red serán mapeadas las IP’s de la red interna creada por el usuario
normal demo que es donde se crearan las instancias de las imagenes de RedBorder.
4.1.2 Usuarios normal
Este usuario (demo) es el encargado de crear la red interna virtual donde se alojaran las IP’s de las instancias de
las maquinas virtuales (192.168.1.0/24).
4.2 Componentes
A continuación se presentarán los componentes básicos necesario para lanzar una instancia de la maquina virtual
de RedBorder.
4.2.1 Redes
En este caso se crearan 3 redes:
1. La red externa correspondiente a la de la empresa (10.0.150.0/24) creada por el usuario admin
2. La red de sincronismo necesaria para que el Sistema RedBorder se sincronice a la hora de montarlo en
cluster (192.168.4.0/24)
3. La red interna donde se crearan las IP de las interfaces de red de las instancias de RedBorder
(192.168.1.0/24).
4.2.2 Routers
A estos components se la llamarán routerspor comodidad, porque realmente no lo son fisicamente, pero si lo son
virtualmente. Estos se encargan de separar las diferentes redes creadas y de mapear las IP’s privadas a las
públicas (red de la empresa).
E
No importa. Inténtalo de nuevo. Fracasa otra vez.Fracasa mejor.
Samuel Beckett
Lanzar una Instancia
22
En este caso se creará un router con dos interfaces:
1. Una interfaz a la red pública (red de la empresa), 10.0.150.20, que a su vez será la encargada de
elegir la IP flotante que permitirá acceder a la instancia de la red interna desde la red exterior.
2. Una interfaz a la red privada, 192.168.1.1, que hará las veces de puerta de enlace de ésta red y otra
IP que será la 192.168.1.3 que será la encargadá de asignar por DHCP la IP que le corresponderá
a la instancia de la maquina virtual en la red interna.
4.2.3 Instancia
A continuación se mostrará un ejemplo básico de creación de red, routers y lanzamiento de instancia.
Estos pasos se han de realizar en el nodo controlador y se harán mediante la API de Neutron.
En primer lugar se han de exportar las variables de entorno asociadas al usuario administrador para crear la
red externa mediante el siguiente comando:
source admin-openrc.sh; El dfichero admin-openrc.sh se encuentra en el Anexo
A.
Ahora se creara la red externa y se llamará ext-net:
neutron net-create ext-net --shared --router:external=True;
Y se creará la subred asociada a la red. Esta subred se llamará ext-subnet con un rango de IPs flotantes que
va desde la .20 a la .26, desactivando el DHCP y asignándole una pasarela por defecto 10.0.150.1 y la red a
la que pertenece 10.0.150.0/24.
neutron subnet-create ext-net --name ext-subnet --allocation-pool
start=10.0.150.20,end=10.0.150.26 --disable-dhcp --gateway 10.0.150.1
10.0.150.0/24;
Se han de exportar las variables de entorno asociadas al usuario demo para crear la red externa mediante el
siguiente comando:
source demo-openrc.sh; encuentra en el Anexo A.
Ahora se creara la red interna y se llamará demo-net:
neutron net-create demo-net;
Y se creará la subred asociada a la red. Esta subred se llamará demo-subnet asignándole una pasarela por
defecto 192.168.1.1 y la red a la que pertenece 192.168.1.0/24.
neutron subnet-create demo-net --name demo-subnet --gateway 192.168.1.1
192.168.1.0/24;
Por último se creará el router:
neutron router-create demo-router;
Y se asignará una interfaz de este a la red interna:
neutron router-interface-add demo-router demo-subnet;
Y la otra interfaz será asignada a la red externa y se configurará como pasarela:
23 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
neutron router-gateway-set demo-router ext-net;
Una vez hecho esto se tendrá lo siguiente:
Los siguientes pasos que se han de realizar son necesarios para lanzar una instancia:
1. Ir a la pestaña del dashboard “Instancias” y pulsar “Lanzar Instancia”.
2. Posteriormente saldrá el cuadro de lanzado de instancia y se le dará el nombre que se desee, y se
seleccionará un sabor. En este caso se seleccionará un sabor personalizado, el cual se creó en el
dashboard del administrador de la siguiente manera. Seleccionando la pestaña Sabores y
dándole a crear sabor como aparece a continuación.
Figura 16: Esquema general de redes
Figura 17: Pestaña Instancias
Lanzar una Instancia
24
Y se le asignarán los recursos deseados para este sabor.
Figura 18: Modificación de Sabores
Figura 19: Creación sabor RedBorder
25 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Ahora ya se puede rellenar completamene el cuadro de lanzado de instancia como se adjunta a continuación
Figura 20: Lanzar Instancia
3. Ahora en el cuadro de lanzado de instancia se seleccionará la pestaña de “Redes” y se indicará en
que red se levantará la instancia de la maquina virtual de RedBorder.
Lanzar una Instancia
26
Figura 21: Redes de la Instancia
4. Se pulsa lanzar instancia y listo.
5. Una vez hecho esto se han de asignar las IP’s flotantes para poder acceder a esta instancia desde la red
externa. Para ello se selecciona la pestaña “Mas” y pulsamos sobre “Asociar IP flotante”.
Figura 22: Estado de la Instancia
27 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
6. Se selecciona el botón “+” y posteriormente se selecciona la red de donde se asignarán las IP’s
flotantes para por último pulsar “Asociar”.
7. Ya se podrá acceder mediante ssh a la instancia de RedBorder indicándole como IP la flotante
asociada dentro del rango indicado en la creación de la red externa.En este caso 10.0.150.21
Figura 23: Asociación de IPs Flotantes
Figura 24: Estado de Instancia con IPs flotantes
Lanzar una Instancia
28
Figura 25: Acceso a maquina RedBorder
29
5 COMPONENTES ADICIONALES DE OPENSTACK
5.1 OpenStack Orchestration (Heat)
El servicio de orquestaciónxxiv provee un servicio de orquestación basado en plantillas para describir una
aplicación en la nube mediante las llamadas de la API de OpenStack para ejecutar esas aplicaciones.
Las plantillas permiten crear la mayoría de los recursos de OpenStack, como instancias, IPs flotantes, volúmenes,
grupos de seguridad, usuarios, etc. Incluso, proporciona algunas funcionalidades mas avanzadas, como crear
instancias de alta disponibilidad, crear instancias auto-escalables, y clusters anidados.
Para proveer una alta integración con otros proyectos principales de OpenStack, todos los proyectos principales
de OpenStack podrán recibir una gran BBDD de usuarios.
Esto anterior permite a los desarrolladores una integración directa con el servicio de orquestación o a través de
plug-ins personalizados.
El servicio de Orquestación consta de los siguientes componentes:
Heat. Una línea de comandos que se comunica con la API (heat-api) para correr APIs tales como AWS
CloudFormation. Los desarrolladores finales podrían incluso usar directamente la API de Orquestacion
REST.
Heat-api. Proporciona una API REST nativa de OpenStack que procesa las peticiones enviándolas al
heat-engine sobre RPC.
Heat-api-cfn. Proporciona una API Query AWS que es compatible con AWS CloudFormation y
procesa las peticiones API enviándolas al heat-engine sobre RPC.
Heat-engine. Organiza el lanzamiento de plantillas y proporciona eventos a la API del consumidor.
No importa. Inténtalo de nuevo. Fracasa otra vez.Fracasa mejor.
Samuel Beckett
Componentes Adicionales de OpenStack
30
5.2 OpenStack Telemetry (Ceilometer)
Telemetry proporciona una infraestructura para la monitorización y la medición de la nube de OpenStack.
Tambien se conoce como proyecto Ceilometer.
El módulo Telemetry:
Recoge eficientemente las mediciones de datos cobre la CPU y los costs de red.
Recopila datos de notificaciones de monitorización enviadas por los servicios o sondeando la
infraestructura.
Configura los tipos de datos recopilados para satisfacer diversos requisites de funcionamiento.
Accediendo e insertanto los datos medidos a través de la API REST.
Expande la infraestructura para recopilar el uso de datos personalizados mediante plug-ins adicionales.
Genera mensages de mediciones firmados que no pueden ser rechazados.
El Sistema consiste en los siguientes components básicos:
Ceilometer-agent-compute. Corre en cada compute node y ademas hace recuenos para las estadisticas
de la utilización de recursos. Se plantea la posibilidad de que en un future pueda haber otro tipo de
agentes en adición a este.
Ceilometer-agent-central. Corre en un servidor central de gestión para hacer recuento de las estadisticas
de utilización de recursos para los recursos no vinculados a instancias o compute nodes.
Ceilometer-collector. Corre en uno o mas servicores centrales de gestión para monitorizar las colas de
mensajes (notificaciones y mediciones provenientes del agente). Los mensajes de notificación son
procesados y convertidos a mensajes de medición y enviados de vuelta en el canal de mensajes usando
el tema apropiado. Los mensajes del modulo de Telemetría estan escritos en el amacenamiento de datos
sin modificación alguna.
Ceilometer-alarm-notifier. Corre en uno o mas servidores centrales de gestión para permitir la
establecimiento de alarmas basadas en la evaluación de umbrales para una colección de muestras.
Una BBDD. Una base de datos capaz de manejar escritura concurrente (de una o mas recopilación de
Figura 26: Diagrama de Heat
31 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
instacias) y lectura (de la API del servidor).
Ceilometer-api. Corre en uno o mas servidores centrales de gestión para proporcionar acceso a los datos
desde la BBDD.
Estos servicios se comunican mediante Qpid (el canal de mensajeria AMQP que se ha instalado). Solo el
recopilador y la API del servidor tienen acceso a la BBDD.
5.3 DataBase OpenStack (Trove)
El servicio de BBDD proporciona una funcionalidad de provisionamiento en la nube escalable y segura tanto
para motores de BBDD relacionales como no relacionales. Los usuarios pueden utilizar rapida y facilmente las
caracteristicas de la BBDD sin la carga que supone el manejo de tareas administrativas complejas. Los usuarios
de la nube y administradores de la BBDD pueden provisionar y gestionar tantas instancias de BBDD como se
necesiten.
El servicio de BBDD proporciona recursos de aislamiento a un alto nivel de redimiento, y automatización de
tareas administrativas complejas como son el despliegue, configuración, aplicación de parches, copias de
seguridad, restauraciones y monitorización.
El servicio de BBDD incluye los siguientes components:
Python-troveclient. Una linea de comandos que se comunica con el component trove-api.
Trove-api. Proporciona una API RESTful nativa de OpenStack, que soporta JSON, para
provisionar y gestionar las instancias de Tove.
Trove-conductor. Corre en el host, y recibe mensajes de las instancias de los huéspedes que quieren
actualizar información en el host.
Figura 27: Diagrama de Ceilometer
Componentes Adicionales de OpenStack
32
Trove-taskmanager. Instrumentos del sistema complejo de flujos que ayuda al provisionamiento
de instancias, gestion y manejo del ciclo de vida de la sinstancias, y rendimiento de operaciones
sobre las instancias.
Trove-guestagent. Corre dentro del huesped de la instancia. Gestiona y realiza operaciones en la
misma BBDD.
A continuación se procederá a describir un proceso de flujo de alto nivel para el uso del servicio de BBDD:
1. El administrador prepara la infraestructura:
Instalacion del servicio de BBDD (Trove)
Este crea una imagen para cada tipo de BBDD que el administrador quiera tener (una
para MySQL, una para MongoDB, etc).
El administador de OpenStack actualiza el almacenador de datos para usar las nuevas
imágenes, usando el comando trove-manage.
2. El usuario final usa el servicio de BBDD:
Ahora, el usuario puede crear una instancia de Trove (BBDD) cada vez que quiera
usando el comando trove-create.
El usuario final obtiene la IP de la instancia Trove usando el comando trove list para
obtener el ID de la instancia, y entonces usar el comando trove show instanceID para
obtener la IP.
El usuario puede ya acceder a la instancia de Trove usando los comandos típico de
acceso a una BBDD. Por exemplo en MySQL:
$ mysql -u myuser -pmypass -h trove_ip_address mydb
Figura 28: Diagrama de Trove
33 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
5.4 Hadoop Cluster OpenStack (Sahara)
El objetivo de este proyecto es permitir a los usuarios provisionar y gestionar de una manera fácil clusters de
Hadoopxxv en OpenStack. Merece la pena mencionar que Amazon proporciona Hadoop durante varios años
como Amazon Elastic MapReduce (EMR) [4].
Sahara tiene como objetivo proporcionar usuarios con medios simples para provisionar clusters Hadoop
especificando varios parámetros como la versionde Hadoop, la topología del cluster, los detalles hardware de
los nodos y poco mas. Después el usuario rellena todos los parámetros y Sahara despliega el cluster en pocos
minutos. Sahara también proporciona medios para escalar clusters ya provisionados mediante la
adición/borrado de nodos de trabajo en función de lo demandado.
Las características claves son:
Está diseñado como un componente de OpenStack.
Gestionado a través de una API REST con interfaz de usuario disponible como parte del Dashboard.
Apoyo para las diferentes distribuciones de Hadoop:
1. Sistema conectable de motores de instalación Hadoop.
2. Integración con herramientas de gestión de proveedores específicos, como Apache Ambari o
consola de gestión de Cloudera.
Plantillas predefinidas de conficuraciones de Hadoop con la opción de modificar parámetros.
Sahara se comunica con los siguientes componentes de OpenStack:
Horizon: Proporciona interfaz gráfica de usuario con la capacidad de usarr todas las características de
Sahara.
Keystone: Autentica usuarios y proporciona token de seguridad, limitando por tanto las capacidades de
los usuarios en Sahara a sus privilegios en OpenStack.
Nova: Usado para proporcionar las maquinas virtuales para el cluster Hadoop.
Figura 29: Diagrama de Sahara
Componentes Adicionales de OpenStack
34
Glance: Las imágenes de las maqinas virtuales de Hadoop se guardan aquí, cada imagen contiene un
S.O. instalado y Hadoop; Hadoop pre-instalado debería dar una buena desventaja en el nodo de puesta
en marcha.
Swift: Puede ser uasdo como un almacenamiento para datos que serán procesados por las funciones de
Hadoop.
5.5 Nota aclaratoria
Los componentes explicados en el punto 6.3 y 6.4 son proyectos que no estan en la fase de desarrollo estable
pero tienen la mayoria de las funcionalidades en activo. Por tanto se han incluido en esta sección puesto que su
funcionalidad completa y estable es cuestion de meses pero no se han incluido en la instalación y configuracion
de OpenStack, aunque si se han previsto su incorporacion dejando recursos de sobra que estos modulos
necesitaran, tanto software como hardware.
Sin tener en cuenta estos dos módulos, la arquitectura sería la mostrada a continuación y esta será la que se
instalará de manera definitiva:
Figura 30: Diagrama completo de OpenStack
35
6 INTEGRACIÓN CON CHEF
Todo tiene un final, excepto la salchicha, que tiene dos.
Anónimo.
n esta sección se hablará del orquestador Chef y de su integración con OpenStack además de las
funcionalidades extras que aporta esta función y de las ventajas y flexibilidad, que con solo la integración
de este componente, con la que se puede dotar a la nube.
En primer lugar se realizará una introducción para aclarar conceptos, y posteriormente se ahondará en
funcionalidades cada vez más amplias y complejas.
6.1 ¿Qué es Chef?
Chef es un sistema de gestión de codio abierto (escrito en rubyxxvi y erlangxxvii) y un frameworkxxviii de
automatización de la infraestructura de la nube creado por Opscode [5].
Se puede usar Chef para desplegar y desarrollar servidores y aplicaciones locales y en la nube. Cookbooksxxix y
recipesxxx le “dicen” a Chef cómo cada nodo de la organización debería ser configurado. Las recipes (se usa
DSLxxxi para escribir los recipes) de Opscode describen el estado que tendría que tener un recurso en un
momento en concreto. Chef guarda esos ficheros en cookbooks junto a otros archivos de configuración
necesarios.
En este caso en particular se va a usar la versión open-source de Chef 11.0 que según una estimación de los
creadores podría ser usado para configurar más de 10.000 nodos con tan solo un cliente de este.
6.2 Chef Server
El servidor de Chef actúa como un aglutinador de datos de configuración. Este guarda los cookbooks, las
políticas que son aplicadas en los nodos, y los metadatos que describen cada nodo registrado que están siendo
gestionados por el cliente de Chef. Cada instancia del servidor de Chef debe estar configurado y gestionado
localmente, incluyendo migraciones de datos, aplicación de actualizaciones, y aseguramiento de que la
infraestructura local escala apropiadamente [6].
A continuación se presentará un diagrama sobre los componentes que forman parte del despliegue del servidor
de Chef y como ellos están relacionados.
Nginx: Es un servidor HTTP de código abierto y un proxy inverso utilizado como balanceador de
carga front-endxxxii para el servidor de Chef. Todas las peticiones a la API del servidor de Chef son
enrutadas a través de Nginx.
Bookshelf: Como su traducción en inglés indica, es como una estantería donde se guardan los
cookbooks (ficheros, plantillas, etc).
E
Integración con Chef
36
6.3 Chef Client
Realmente, el cliente de chef no es necesario para el fin que se trata en este proyecto. En este caso se utilizará
algo parecido que interactua de una forma similar con el servidor de Chef, el cual es llamado Knife, también
del paquete de Chef.
Knife es una herramienta de línea de comandos que proporciona una interfaz entre un repositiorio local de chef
y el servidor de Chef. Knife ayuda a los usuarios a gestionar:
Nodos, cookbooks y recipes, roles, datos JSON almacenados, entornos, recursos de la nuves
(incluyendo provisionamiento), la instalación del cliente Chef en las workstations de gestión y la
búsqueda de datos indexadosen el servidor de Chef.
Knife corre desde una workstation de gestión y se situa entre un servidor de Chef y la infraestructura de la
organización. Knife interactuca con un servidor de Chef usando la misma API REST que es usada por un cliente
de Chef.
6.3.1 Knife OpenStack
El subcomando knife openstack es usado para gestionar la API-driven de los servidores que estan alojados en la
nube por OpenStack.
Se trata de un plugin al commando Knife original que permite crear configuraciones automatizadas mediante
chef y ser aplicadas en OpenStack. Hace asi las veces de orquestador. Por tanto este nuevo nivel de gestión
aporta varias características.
Añade una capa extra de orquestacion, pudiendo así, realizar múltiples combinaciones mediante la
compenetración con Heat.
Figura 31: Estructura de Chef
37 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Mayor potencia de gestión de configuraciones puesto que Chef abarca un amplio panorama de recursos
y opciones a gestionar y manejar.
Plantillas guardadas y personalizadas para el entorno necesario pudiendo añadir mas caracteristicas a
estas o incluso crear nuevas, lo que implica un convergencia mucho menor con respecto a las
configuraciones.
La instalación y uso de este servicio se encuentra en el Anexo D.
Integración con Chef
38
39
7 PRESUPUESTO
n este apartado se elaborará un presupuesto aproximado en función de las horas trabajadas y del coste que
conllevaría comprar los equipos con los que se ha trabajado durante este proyecto. Se han excluido
ordenadores personales y desplazamientos al entorno de trabajo asi como otros gastos. Se tiene que un
programador Junior cobrará unos 40€ por hora trabajada y que el equipo de rack (asi como los equipos necesarios
para la virtualización) costará unos 6.000€. Por tanto se tiene el siguiente presupuesto:
Tabla 3: Presupuesto
E
Precio Total
Horas trabajadas (h) €/hora
360 40 14.400,00 €
Equipo necesario (€) Cantidad
6000 1 6.000,00 €
TOTAL 20.400,00 €
Presupuesto
40
41
8 LINEAS DE MEJORA
La única parte donde el ‘éxito’ aparece
antes que el ‘trabajo’ es en el diccionario
Vidal Sasoon.
ras realizar este proyecto, se han podido conseguir ciertas cosas, tales como la liberación de carga
computacional en equipos particulares dejando esta tareas a los equipos corporativos dando una ventaja
de movilidad,cobro por uso y distribución de servicios.
En este caso en particular se ha decidido por una topología virtual determinada mediante el uso de túneles de
nivel 2. Una mejora o cambio según demanda de esta topología como podria ser VXLAN, FLAT y casi un
numero infinito de posibilidades de combianicion de estos modelos.
Openstack se trata de un proyecto OpenSource, y por tanto siempre está en continuo desarrollo y mejora. Aunque
para este trabajo se escogió la ultima versión estable de OpenStack (4/2014) ya estaba saliendo a la luz una
nueva version, “Juno”, con integraciones muy interesantes como las vistas en apartados anteriores de esta
memoria (Cluster Hadoop, Provisionamiento en maquinas fisicas, despliegue de OpenStack sobre Openstack
para el facilitamiento de migraciones, etc).
Por tanto, y no como una mejora, sino como un desarrollo constante de este proyecto, se propone el continuo
mantenimiento de OpenStack para una integración cada vez mas acorde a las necesidades de empresas y
tecnologías venideras, ya que este se va reinventando para poder combinarse con multiples servicios, asi como
para la mejora de la seguridad y eficiencia de la nube.
Aunque se eligió la instalación sobre un sistema base CentOS, sería interesante instalarlo sobre Ubuntu, ya que
la nube de OpenStack trae integradas ciertas herramientas de orquestación, etc. que por motivos de
compatibilidad e integración de estas con las ya existentes en la empresa fue una opción que se descartó. Aun
así, daría una mayor facilidad de gestión e instalación debido a su potente interfaz gráfica.
T
Lineas de Mejora
42
43
ANEXO A: INSTALACIÓN EN NODO CONTROLADOR
Antes de todo se informa que para separar los comandos que se han de meter manualmente de los que se hacen mediante scripts se utilizará la notación FIN_DE_SCRIPT para indicar que el script utilizado termina ahí y el siguiente comando se introducirá manualmente en el terminal.
En primer lugar es necesario realizar unos pasos previos donde se activará iptables y se instalará NTP (network
time protocol, para sincronizar servicios a través de múltiples maquinas). Introducir estos comandos para
hacerlo:
service NetworkManager stop
service network start
chkconfig NetworkManager off
chkconfig network on
service iptables start
chkconfig iptables on
yum -y install ntp
service ntpd restart
chkconfig ntpd on;
Si se prefiere se puede ejecutar el script config_red.sh que aparece en el Anexo E.
A continuación se mostrará cómo están configuradas las interfaces de red en este equipo. Se configurará este
equipo en función de lo mostrado en el apartado 2 de la memoria principal “Escenario y configuración inicial”
Fichero /etc/sysconfig/network-scripts/ifcfg-eth1
Anexo A: Instalación en Nodo Controlador
44
Ahora se configurará la resolución de nombres:
Editar el archivo /etc/hosts añadiéndole las líneas siguientes:
Se reinicia servicio:
service network restart
Y se comprueba….
Verificamos conectividad: Mirar Anexo H.
Se comprabará con el siguiente comando que está sincronizado (la sincronización se indica con un asterisco):
ntpq –np
Y muestra lo siguiente:
Database
A continuación se instalarán los paquetes del cliente y servidor de MySQL, y la librería de Python:
yum -y install mysql mysql-server MySQL-python
Para poder trabajar con OpenStack, MySQL requiere que se le hagan ciertos cambios.
Para ello se debe editar el archivo /etc/my.conf y poner bajo [mysqld] la dirección ip de la interfaz de gestión
del nodo controlador para que otros nodos puedan acceder a la BBDD desde la red de gestión:
[mysqld]
...
bind-address = 10.0.151.100
45 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Además establecer ciertas claves para habilitar InnoDB y UTF-8 por defecto:
[mysqld]
...
default-storage-engine = innodb
innodb_file_per_table
collation-server = utf8_general_ci
init-connect = 'SET NAMES utf8'
character-set-server = utf8
El fichero configurado del todo debe tener más o menos este aspecto:
Ahora se inicia el servidor de la BBDD MySQL y se configura para que se arranque automáticamente cada vez
que se inicie el sistema:
service mysqld start
chkconfig mysqld on
Por último, es conveniente configurar una contraseña para root, así los programas de OpenStack que creen las
bases de datos y las tablas la solicitarán.
Se debe borrar el usuario anonymous que se crea cuando la BBDD se inicia por primera vez.
Para evitar posibles problemas de conexión con la BBDD hacer lo siguiente (introducir el siguiente comando):
Anexo A: Instalación en Nodo Controlador
46
mysql_secure_installation
Si el anterior comando falla, puede que se necesite introducir el siguiente comando:
mysql_install_db
Una vez hecho esto, se puede volver a introducir el comando….
mysql_secure_installation
Si es la primera vez que se inicia MySQL probablemente no tenga contraseña configurada para el usuario root,
por tanto si se le solicita una contraseña simplemente se presiona ENTER y se introduce la contraseña que se
quiera utilizar para el usuario root.
Una vez se configure la contraseña se presentaran ciertas opciones que harán mas segura la instalación de la
BBDD.
RESPONDER SI A TODAS LAS CUESTIONES SI SE QUIERE UNA CONFIGURACIÓN GENERICA.
OpenStack packages
A continuación se describirá la configuración que se debe completar después de configurar las máquinas para
instalar los paquetes de OpenStack más recientes.
Si se quiere recurrir a una instalación ya con una configuración predeterminada se puede ejecutar el script
packages.sh del Anexo E.
Si se desea realizar una configuración más avanzada y personalizada ejecute los comandos abajo indicados.
En este caso se usarán los paquetes OpenStack del repositorio de RDO. Estos paquetes funcionan para RHEL
6, la versión compatible de este en CentOS, y Fedora 20.
Instalar yum-plugin-priorities plug-in. Este paquete permite la asignación de prioridades relativas a los
repositorios del software configurado.
yum install yum-plugin-priorities
Para permitir los repositorios de RDO, descargar e instalar el paquete rdo-release-icehouse:
yum install http://repos.fedorapeople.org/repos/openstack/openstack- icehouse/rdo-release-
icehouse-3.noarch.rpm
El paquete EPEL incluye las claves GPG para la firma de paquetes e información de repositorio. Ahora se
instalará la versión más reciente del paquete epel (ver
http://download.fedoraproject.org/pub/epel/6/x86_64/repoview/epel-release.html)
Por ejemplo:
yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-
release-6-8.noarch.rpm
47 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
El paquete openstack-utils contiene programas útiles que hacen la configuración en instalación más fácil. Estos
programas se usarán a lo largo de la guía de instalación.
Instala openstack-utils. Esto verifica que puedas acceder a los repositorios RDO:
yum install openstack-utils
El paquete openstack-selinux incluye los archivos de políticas que son necesarios para configurar SELinux
durante la instalación de OpenStack.
Instala openstack-selinux:
yum install openstack-selinux
Ahora se actualizarán los paquetes del sistema:
yum upgrade
FIN_DE_SCRIPT
Por último, se reinicia si la actualización ha incluido un nuevo paquete del kernel (si no está seguro reinicie):
reboot
Messaging server
OpenStack usa un mediadior de mensajes para coordinar operaciones e información de estado de los servicios.
Este servicio de intermediación de mensajes normalmente se ejecuta en el nodo controller. OpenStack soporta
varios de estos (RabbitMQ, Qpid y ZeroMQ). EN este caso se usará Qpid por el hecho de que es el más
conveniente para CentOS y el que mejor viene documentado para integrar con OpenStack.
Para instalar el servicio de intermediación de mensajes (message broker):
yum install qpid-cpp-server
Para configurar el servicio de intermediación de mensajes (message broker):
Para simplificar la instalación en este entorno de prueba, se recomienda desactivar la autenticación. Para
ello se precisa modificar el fichero /etc/qpidd.conf y cambiar el valor del campo auth (que está sin
comentar) a no:
Anexo A: Instalación en Nodo Controlador
48
Nota
Para entornos de producción es recomendable activar la autenticación.Si se decide activarla se deberá
configurar un usuario y contraseña para qpidd en cada archivo de configuración de los servicios de
OpenStack que usen qpidd
Para finalizar la instalación
service qpidd start
chkconfig qpidd on
Ahora ya se puede proceder a la instalación de los servicios de OpenStack
Servicio de Identidad
Si se desea se puede utilizar el script keystone_1.sh, disponible en el Anexo E, para instalar de
una manera más rápida y cómoda este servicio.
Se creará con contraseña por defecto redborder. Si se prefier realizar una instalación
personalizada se han de seguir los pasos que vienen a continuación.
49 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Installar el Servicio de Identidad de OpenStack junto con Python-keystoneclient:
yum install openstack-keystone python-keystoneclient
El Servicio de Identidad usa una BBDD para guardar información. Especificar la localización
de la BBDD en el archivo de configuración. En este caso se usa uan BBDD MySQL con el
nombre de usuario keystone. Reemplazar KEYSTONE_DBPASS con una contraseña adecuada
para la BBDD del usuario:
openstack-config --set /etc/keystone/keystone.conf database connection
mysql://keystone:KEYSTONE_DBPASS@controller keystone
FIN_DE_SCRIPT
Usar la contraseña que se configuró en el paso donde se instala la BBDD MySQL para
identificarse como root.
Crear un usuario de BBDD llamado keystone:
mysql -u root –p
mysql> CREATE DATABASE keystone;
mysql>GRANT ALL PRIVILEGES ON keystone.* TO
'keystone'@'localhost'IDENTIFIED BY 'KEYSTONE_DBPASS';
mysql> GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%'
IDENTIFIED BY 'KEYSTONE_DBPASS';
mysql> exit
Si se desea, a partir de aquí se puede utilizar el script keystone_2.sh, disponible en el Anexo
E, que tendrá ADMIN_TOKEN=redborder por defecto. Por tanto, si se desea personalizar los
comandos se ha de seguir con los procedimientos indicados a continuación.
A continuación se crea la BBDD para el Servicio de Autenticación:
su -s /bin/sh -c "keystone-manage db_sync" keystone
Anexo A: Instalación en Nodo Controlador
50
Ahora se define un token de autorización para usarlo como “clave compartida” entre el
Servicio de Autenticación y otros servicios de OpenStack. Se usa openssl para generar un
token aleatorio y guardarlo en el fichero de configuración:
ADMIN_TOKEN=$(openssl rand -hex 10)
echo $ADMIN_TOKEN
openstack-config --set /etc/keystone/keystone.conf DEFAULT
admin_token $ADMIN_TOKEN
Por defecto, Keystone usa tokens PKI. Ahora se crearán claves firmadas y los certificados y
se restringirá el acceso a los datos generados:
keystone-manage pki_setup --keystone-user keystone –keystone group
keystone
chown -R keystone:keystone /etc/keystone/ssl
chmod -R o-rwx /etc/keystone/ssl
Arrancar el Servicio de Autenticación y activarlo para que se arranque al iniciar el sistema:
service openstack-keystone start
chkconfig openstack-keystone on
Por defecto, el Servicios de Autenticación guarda los tokens expirados en la BBDD
indefinidamente. Esto es útil para entornos de producción, pro sin embargo la acumulación
de estos tokens expirados aumentaran considerablemente el tamaño de la BBDD y puede
disminuir el rendimiento del servicio, particularmente en entornos de prueba con recursos
limitados. Se recomienda configurar una tarea periódica usando “cron” para eliminar los
tokens expirados cada hora:
(crontab -l -u keystone 2>&1 | grep -q token_flush) || echo '@hourly
/usr/bin/keystone-manage token_flush>/var/log/keystone/
keystone-tokenflush.log 2>&1' >> /var/spool/cron/keystone
51 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Definición de usuarios, inquilino, y roles
Despues de instalar el Servicio de Autenticación, se configurarn los usuarios, inquilinos, y roles
para ser autenticados. Estos son usados para tener acceso a los servicios y puntos finales
(endpoints) que ahora se presentan.
Normalmente, se indicaría un usuario y contraseña para autenticarse con el Servicios de
Autenticación. En este punto, sin embargo, aun no se han creado usuarios, asi que se tendrá que
utilizar el token de autorización creado en la sección anterior. No es necesario hacer eso con la
opción –os-token en los comandos de keystone , sin embargo, se hará de esa manera configurando
la variable de entorno OS_SERVICE_TOKEN. Además de esta última, se configurará
OS_SERVICE_ENDPOINT para especificar donde se está ejecutando el Servicio de
Autenticación:
export OS_SERVICE_TOKEN=$ADMIN_TOKEN
export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0
Crear un usuario administrador
A continuación se creará un susuario administrados para administrar Openstack.
Por defecto el Servicio de Autenticación crea un role especial member. El panel de control de
OpenStack automáticamente permite el acceso a usuarios con este rol. Por tanto, al usuario
administrador, se le deberá dar este rol además del rol de administrador.
NOTA
Cualquier rol que se cree debe ser mapeado a los rolos especificados en el archivo policy.json
incluido en cada servicio de OpenStack. Este fichero tiene por defecto permitir el acceso a los
usuarios que accedan con el rol de administrador.
En primer lugar se crea un usuario admin:
keystone user-create --name=admin --pass=ADMIN_PASS --
email=ADMIN_EMAIL
Anexo A: Instalación en Nodo Controlador
52
Reemplazar ADMIN_PASS con una contraseña segura y reemplazar ADMIN_EMAIL con
una dirección de correo electrónico que se quiera asociar a la cuenta.
Crear el rol admin:
keystone role-create --name=admin
Crear el inquilino admin:
keystone tenant-create --name=admin --description="Admin Tenant"
Ahora se deben unir el usuario el rol y el inquilino creados anteriormente usando la opción
user-role-add:
keystone user-role-add --user=admin --tenant=admin --role=admin
Por último unir el usuario admin , el rol member, y el inquilino admin:
keystone user-role-add --user=admin --role=_member_ --tenant=admin
53 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Crear un usuario normal
Ahora se creará un usuario e inquilino normales, y uniremos estos al rol especial member.
Esta cuenta será usada para la interacción no administrativa con la nube de OpenStack. Se
puede repetir este procedimiento para crear usuarios de la nube adicionales con diferentes
nombres de usuario y contraseñas. Omitir el paso de creación de inquilino cuando se creen
esos usuarios.
Crear usuario demo:
keystone user-create --name=demo --pass=DEMO_PASS --email=DEMO_EMAIL
Crear el inquilino demo:
keystone tenant-create --name=demo --description="Demo Tenant"
NOTA
No repetir este paso cuando se añadan usuarios adicionales.
Unir el usuario demo, el rol member, y el inquilino demo:
keystone user-role-add --user=demo --role=_member_ --tenant=demo
Crear un inquilino service
Los servicios de OpenStack también requieren de un nombre de usuario, inquilino y rol para
acceder a otros servicios de OpenStack. En una instalación básica, normalmente los servicios
de OpenStack comparten un inquilino simple llamado service.
Por tanto, se crearán nombres de usuario y roles bajo este inquilino cada vez que se instale o
configure un servicio.
Anexo A: Instalación en Nodo Controlador
54
Crear el inquilino service:
keystone tenant-create --name=service --description="Service Tenant"
Definición de servicios y API de puntos finales (endpoints)
El Servicio de Autenticación puede realizar un seguimiento de qué servicios están instalados y
donde están localizados en la red. Para ello, se debe registrar cada servicio en la instalación de
OpenStack. Para registrar un servicio…
NOTA
keystone service-create: Describe el servicio.
keystone endpoint-create: Asocia la API del punto final (endpoint) con el servicio.
Se debe primero registrar el Servicio de Autenticación. Use las variable de entorno
OS_SERVICE_TOKEN como se configuró previamente para la autenticación.
Crear una entrada de servicio para el Servicio de Identidad:
keystone service-create --name=keystone --type=identity --
description="OpenStack Identity"
El ID de servicio es generado aleatoriamente y será diferente del que se muestra en la imagen
anterior.
Especificar una API endpoint para el Servicio de Autenticación usando el ID de servicio devuelto
en el paso anterior. Cuando se especifica un endpoint, se está provisionando de una URL para la
API pública, API interna, y API de administrador. Se usa controller como URL. Observar que se
usa un puerto diferente para la API de administrador.
55 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
keystone endpoint-create --service-id=$(keystone service-list | awk '/
identity / {print $2}')
--publicurl=http://controller:5000/v2.0
--internalurl=http://controller:5000/v2.0
--adminurl=http://controller:35357/v2.0
Verificar la instalación del Servicio de Autenticación
Para verificar que el Servicio de Autenticación se ha instalado y configurado correctamente,
limpiamos los valores asignados a las variables de entornos OS_SERVICE_TOKEN y
OS_SERVICE_ENDPOINT :
unset OS_SERVICE_TOKEN OS_SERVICE_ENDPOINT
Estas variables, que usamos como origen de datos para la creación del usuario admin y para
registrar el Servicio de Autenticación no son necesarias.
Ahora se puede utilizar la autenticación basada en nombre de usuario.
Petición de un token de autenticación usando el usuario admin y la contraseña que se eligió para el:
keystone --os-username=admin --os-password=ADMIN_PASS --os-auth-
url=http://controller:35357/v2.0 token-get
Anexo A: Instalación en Nodo Controlador
56
En respuesta se recibirá un token asociado a tu ID de usuario (imagen siguiente). Esto verifica que
el Servicio de Autenticación está corriendo en el endpoint esperado y que la cuenta de usuario se ha
establecido con los credenciales esperados.
57 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Ahora se procederá a verificar que la autorización se comporta como se espera. Para hacer eso,
hacemos una petición de autorización en un inquilino
keystone --os-username=admin --os-password=ADMIN_PASS --os-tenant-
name=admin --os-auth-url=http://controller:35357/v2.0
token-get
En respuesta, se recibirá un token que incluye el ID del inquilino que se especificó. Esto verifica
que la cuenta de usuario tiene un rol explicito definido en el inquilino especificado y el inquilino
existe como se esperaba.
También se puede conigurar unas variables –os-* en el entorno para simplificar el uso de la línea
de comandos. Cree un archivo admin-openrc.sh con los credenciales de administrador y el
endpoint del administrador:
export OS_USERNAME=admin
export OS_PASSWORD=ADMIN_PASS
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://controller:35357/v2.0
Para obtener las variables de entorno de este archivo bastará hacer…
source admin-openrc.sh
Verifique que su archivo admin-openrc.sh está configurado correctamente. Ejecute el mismo
comando pero sin los argumentos –os-*:
keystone token-get
El comando devuelve un token y un ID del inquilino especificado. Esto verifica que se han
configurado correctamente las variables de entorno.
Anexo A: Instalación en Nodo Controlador
58
Para verificar que la cuanta de administrador tiene autorización para usar los comandos de
administración ejecute:
keystone user-list
Se mostrará por pantalla algo parecido a esto.
keystone user-role-list --user admin --tenant admin
FIN_DE_SCRIPT
Viendo que el ID en la salida del comando keystone user-list coincide con el ID de usuario en el
comando keystone user-role-list, y que el rol de administrador esta listado para ese usuario, para
el inquilino afín, esto verifica que la cuenta de usuario tiene el rol admin, el cual coincide con el
rol usado en el archivo policy.json del Servicio de Autenticación
Clientes Para instalar esta parte, se recomienda usar el script clients.sh, que se puede encontrar en el Anexo E,
ya que no requiere de configuración extra y solo se trata de instalar los clientes de los diversos módulos
de OpenStack mediante yum.
59 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Servicio de Imágenes
Este servicio actúa como un registro para discos de imágenes virtuales. Los usuarios pueden añadir
nuevas imágenes o tomar una instantánea de una imagen de un servidor para un almacenamiento
inmediato.
Se puede usar si se desea el script glance_1.sh, en el Anexo E, para simplificar las cosas (contraseña
por defecto redborder), si no, se puede hacer los siguientes pasos:
Instalación del módulo mediante yum:
yum install openstack-glance python-glanceclient
Configuración de la localización de la base de datos. El servicio de imagen proporciona los
servicios glance-api y glance-registry, cada uno con su propio fichero de configuración:
openstack-config --set /etc/glance/glance-api.conf database connection
mysql://glance:GLANCE_DBPASS@controller/glance
openstack-config --set /etc/glance/glance-registry.conf database
connection mysql://glance:GLANCE_DBPASS@controller/glance
FIN_DE_SCRIPT
Se crea una base de datos del usuario glance:
$ mysql -u root –p
mysql> CREATE DATABASE glance;
mysql> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost'
IDENTIFIED BY 'GLANCE_DBPASS';
mysql> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' IDENTIFIED BY
'GLANCE_DBPASS';
Los siguientes pasos desde aquí hasta el final de la instalación de este módulo se pueden hacer mediante
el script glance_2.sh, situado en el Anexo E, pero con las características por defecto que siempre se han
indicado. Si no se desea esto, pues se sigue con los pasos siguientes:
Creación de las tablas para la base de datos para el servicio de imagen:
su -s /bin/sh -c "glance-manage db_sync" glance
Anexo A: Instalación en Nodo Controlador
60
Creación de usuario glance y asignación de este al rol de administrador y al inquilino servicio:
keystone user-create --name=glance --pass=GLANCE_PASS --
email=glance@example.com
keystone user-role-add --user=glance --tenant=service --role=admin
Configuracion del servicio de imagen para usar el servicio de autenticación. Para ello se han de ejecutar los siguientes comandos:
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken
auth_uri http://controller:5000
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken
auth_host controller
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken
auth_port 35357
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken
auth_protocol http
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken
admin_tenant_name service
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken
admin_user glance
openstack-config --set /etc/glance/glance-api.conf keystone_authtoken
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
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken auth_host controller
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken auth_port 35357
61 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken auth_protocol http
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken admin_tenant_name service
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken admin_user glance
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken admin_password GLANCE_PASS
openstack-config --set /etc/glance/glance-registry.conf paste_deploy
flavor keystone
Registrar el servicio de imagen con el servicio de autenticación para que otros servicios de OpenStack
puedan localizarlos:
keystone service-create --name=glance --type=image --description="OpenStack
Image Service";
keystone endpoint-create --service-id=$(keystone service-list | awk '/ image /
{print $2}') --publicurl=http://controller:9292 --
internalurl=http://controller:9292 --adminurl=http://controller:9292;
Anexo A: Instalación en Nodo Controlador
62
Iniciar los servicios glance-api y glance-registry :
service openstack-glance-api start
service openstack-glance-registry start
chkconfig openstack-glance-api on
chkconfig openstack-glance-registry on
Los pasos para verificar que se ha instalado correctamente este módulo, son los siguientes:
mkdir /tmp/images;
cd /tmp/images/;
wget http://cdn.download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img; se
puede escoger una imagen cualquiera de cualquier web.
source /root/admin-openrc.sh;
glance image-create --name "cirros-0.3.2-x86_64" --disk-format qcow2 --container-
format bare --is-public True --progress < cirros-0.3.2-x86_64-disk.img; los
parámetros se pueden cambiar en función de las necesidades.
63 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
glance image-list;
rm -r /tmp/images;
FIN_DE_SCRIPT
Servicio de Computación Este servicio será el encargado de permitir el lanzamiento de instancias de máquinas virtuales. A
continuación se verá como instalar este servicio. Se puede comenzar mediante el script nova_1.sh,
situado en el Anexo E, para hacerlo más simplificado, aunque tendrá ciertos parámetros por defectos
como las contraseñas (todas redborder).
Para una instalación personalizada se han de seguir los siguientes pasos:
Instalación de los paquetes necesarios:
yum install openstack-nova-api openstack-nova-cert openstack-nova-
conductor openstack-nova-console openstack-nova-novncproxy openstack-nova-
scheduler python-novaclient;
La información de computación se guarda en una base de datos. A continuación se configurará
la localización y credenciales de esta:
openstack-config --set /etc/nova/nova.conf database connection
mysql://nova:NOVA_DBPASS@controller/nova
Ahora viene la configuración del servicio de mensajería Qpid:
openstack-config --set /etc/nova/nova.conf DEFAULT rpc_backend qpid
openstack-config --set /etc/nova/nova.conf DEFAULT qpid_hostname controller
Anexo A: Instalación en Nodo Controlador
64
Y la configuración de my_ip, vncserver_listen y vncserver_proxyclient_address
para gestionar la interfaz del nodo controlador:
openstack-config --set /etc/nova/nova.conf DEFAULT my_ip controller
openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen
controller
openstack-config --set /etc/nova/nova.conf DEFAULT
vncserver_proxyclient_address controller
FIN_DE_SCRIPT
Se crea la base de datos de nova:
$ mysql -u root -p
mysql> CREATE DATABASE nova;
mysql> GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY
'NOVA_DBPASS';
mysql> GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY
'NOVA_DBPASS';
mysql> exit;
A continuación se puede continuar toda la instalación mediante el script nova_2.sh, situado en
el Anexo E, con los parámetros por defecto de siempre. Si se desea una instalación
personalizada se han de seguir los pasos siguientes.
Creación de las tablas de la BBDD de nova:
su -s /bin/sh -c "nova-manage db sync" nova;
Ahora se creará un usuario nova que el módulo de computación use para autenticarse con
Keystone. Usa el inquilino servicio y se le dará el rol de admin:
keystone user-create --name=nova --pass=NOVA_PASS --email=nova@example.com
keystone user-role-add --user=nova --tenant=service --role=admin
65 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Configuración del módulo para usar esos credenciales con el servicio de identidad corriendo en el
nodo controlador:
openstack-config --set /etc/nova/nova.conf DEFAULT auth_strategy keystone;
openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_uri
http://controller:5000;
openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_host
controller;
openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_protocol
http;
openstack-config --set /etc/nova/nova.conf keystone_authtoken auth_port
35357;
openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_user
nova;
openstack-config --set /etc/nova/nova.conf keystone_authtoken
admin_tenant_name service;
openstack-config --set /etc/nova/nova.conf keystone_authtoken admin_password
NOVA_PASS;
Se ha de registrar el servicio de computación con el servicio de identidad para que otros
servicios de OpenStack puedan localizarlo. A continuación se registrará el servicio y un endpoint
específico:
keystone service-create --name=nova --type=compute --
description="OpenStack Compute";
Anexo A: Instalación en Nodo Controlador
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 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Para terminar y verificar la instalación, se listarán las imágenes disponibles y debe salir algo
parecido a lo siguiente:
FIN_DE_SCRIPT
Servicio de Red
Antes de nada se ha de crear la BBDD para este módulo:
$ mysql -u root –p
mysql> CREATE DATABASE neutron;
mysql> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' IDENTIFIED
BY 'NEUTRON_DBPASS';
mysql> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' IDENTIFIED BY
'NEUTRON_DBPASS';
A partir de este punto se puede usar el script neutron_1.sh, disponible en el Anexo E, para una
instalación más rápida y general. SI se desea una instalación más personalizada con contraseñas
propias, se han seguir las siguientes instrucciones.
Ahora se ha de crear el usuario neutron:
keystone user-create --name neutron --pass NEUTRON_PASS --email
neutron@example.com
Anexo A: Instalación en Nodo Controlador
68
Asociar el usuario neutron al inquilino servicio y al rol admin:
keystone user-role-add --user neutron --tenant service --role admin
Crear el servicio neutron:
keystone service-create --name neutron --type network –-description "OpenStack
Networking"
Creación del endpoint del servicio:
keystone endpoint-create --service-id $(keystone service-list | awk '/ network
/ {print $2}')
--publicurl http://controller:9696
--adminurl http://controller:9696
--internalurl http://controller:9696
Una vez creados los usuarios y demás, se procederá a instalar los componentes de red
yum install openstack-neutron openstack-neutron-ml2 python-neutronclient
A continuación se procederá a configurar los componentes del servidor de red.
En primer lugar, se debe configurar al servicio de red para usar la base de datos localizada en el
nodo controlador y con una contraseña especifica:
openstack-config --set /etc/neutron/neutron.conf database connection
mysql://neutron:NEUTRON_DBPASS@controller/neutron
69 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Configuración del servicio de red para usar el servicio de autenticación para autenticarse:
openstack-config --set /etc/neutron/neutron.conf DEFAULT auth_strategy
keystone
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken auth_uri
http://controller:5000
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
auth_host controller
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
auth_protocol http
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
auth_port 35357
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
admin_tenant_name service
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
admin_user neutron
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
admin_password NEUTRON_PASS
Ahora se configura el servicio de red para que utiliza el servicio de mensajería Qpid:
openstack-config --set /etc/neutron/neutron.conf DEFAULT rpc_backend
neutron.openstack.common.rpc.impl_qpid
openstack-config --set /etc/neutron/neutron.conf DEFAULT qpid_hostname
controller
Configurar el servicio de red para notificar al servicio de computación sobre los cambios en la
topología:
openstack-config --set /etc/neutron/neutron.conf DEFAULT
notify_nova_on_port_status_changes True
openstack-config --set /etc/neutron/neutron.conf DEFAULT
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
Anexo A: Instalación en Nodo Controlador
70
openstack-config --set /etc/neutron/neutron.conf DEFAULT
nova_admin_tenant_id $(keystone tenant-list | awk '/ service / { print $2
}')
openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_admin_password
NOVA_PASS
openstack-config --set /etc/neutron/neutron.conf DEFAULT nova_admin_auth_url
http://controller:35357/v2.0
A continuación se configurará el servicio de red para usar un plug-in de módulo de capada 2 y
asociarle servicios:
openstack-config --set /etc/neutron/neutron.conf DEFAULT core_plugin ml2
openstack-config --set /etc/neutron/neutron.conf DEFAULT service_plugins
router
Configuracion de plug-in de ML2 (Modular Layer 2). Este plug-in usa el mecanismo (agente)
Open vSwitch (OVS) para construir la estructura de las redes virtuales para las intancias. Sin
embargo, el nodo controlador no necesita el agente OVS porque no tiene que manejar el tráfico
de red de las instancias:
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
type_drivers gre
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
tenant_network_types gre
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
mechanism_drivers openvswitch
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
ml2_type_gre tunnel_id_ranges 1:1000
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup firewall_driver neutron.agent.linux.iptables_firewall.
OVSHybridIptablesFirewallDriver
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup enable_security_group True
Debido al modo de distribución usado (neutron-compute), se ha de reconfigurar el servicio de
computación para gestionar las redes a través del servicio de red.
openstack-config --set /etc/nova/nova.conf DEFAULT network_api_class
nova.network.neutronv2.api.API
71 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
openstack-config --set /etc/nova/nova.conf DEFAULT neutron_url
http://controller:9696
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
http://controller:35357/v2.0
openstack-config --set /etc/nova/nova.conf DEFAULT linuxnet_interface_driver
nova.network.linux_net.LinuxOVSInterfaceDriver
openstack-config --set /etc/nova/nova.conf DEFAULT firewall_driver
nova.virt.firewall.NoopFirewallDriver
openstack-config --set /etc/nova/nova.conf DEFAULT security_group_api neutron
Para finalizar la instalación, los scripts de iniciación del servicio de red esperan un enlace simbólico
/etc/neutron/plugin.ini apuntando al fichero de configuración asociado con el plug-in
elegido. Usando ML2, por ejemplo, el enlace simbólico debe apuntar a /etc/neutron/plugins/ml2/ml2_conf.ini.
ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
Reiniciar los servicios de computación:
service openstack-nova-api restart
service openstack-nova-scheduler restart
service openstack-nova-conductor restart
Iniciar el servicio de red y configurarlo para que empiece cuando el sistema inicia:
servi
ce neutron-server start
chkconfig neutron-server on
FIN_DE_SCRIPT
Anexo A: Instalación en Nodo Controlador
72
Servicio de Dashboard
Este servicio instalará el panel de control, es decir, la interfaz gráfica que ayudará a la gestión de
OpenStack
En primer lugar se instalarán los paquetes necesarios:
yum install memcached python-memcached mod_wsgi openstack-dashboard
Posteriormente se han de configurar algunos parámetros del fichero /etc/openstack-
dashboard/local_settings para permitir todos los hosts y poner el host de
OpenStack en el nodo controlador:
ALLOWED_HOSTS = [‘*’]
OPENSTACK_HOST = "controller"
También se modificará el valor de CACHES['default']['LOCATION']
en /etc/openstack-dashboard/local_settings para que coincida con lo mostrado en
/etc/sysconfig/memcached.
CACHES = {
'default': {
'BACKEND' : 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION' : '127.0.0.1:11211'
}
}
Ahora habrá que asegurarse que la política SELinux del sistema está configurada para permitir las
conexiones de red hacia el servidor HTTP:
setsebool -P httpd_can_network_connect on
Por ultimo se iniciará el servidor apache y el servicio de memcache:
service httpd start
service memcached start
chkconfig httpd on
chkconfig memcached on
Ya se podra accede al dashboard en http://10.0.150.100/dashboard
73
ANEXO B: INSTALACIÓN EN NODO DE RED
Antes de todo se informa que para separar los comandos que se han de meter manualmente de los que se hacen mediante scripts se utilizará la notación FIN_DE_SCRIPT para indicar que el script utilizado termina ahí y el siguiente comando se introducirá manualmente en el terminal.
En primer lugar es necesario realizar unos pasos previos donde se activará iptables y se instalará NTP (network
time protocol, para sincronizar servicios a través de múltiples maquinas). Introducir estos comandos para
hacerlo:
service NetworkManager stop
service network start
chkconfig NetworkManager off
chkconfig network on
service iptables start
chkconfig iptables on
yum -y install ntp
service ntpd restart
chkconfig ntpd on;
yum -y install MySQL-python;
Si se prefiere se puede ejecutar el script config_red_network.sh que aparece en el Anexo F.
A continuación se mostrará cómo están configuradas las interfaces de red en este equipo. Se configurará este
equipo en función de lo mostrado en el apartado 2 de la memoria principal “Escenario y configuración inicial”
Fichero /etc/sysconfig/network-scripts/ifcfg-eth0
Fichero /etc/sysconfig/network-scripts/ifcfg-eth1
Anexo B: Instalación en Nodo de Red
74
Fichero /etc/sysconfig/network-scripts/ifcfg-eth2
Ahora se configurará la resolución de nombres:
Editar el archivo /etc/hosts añadiéndole las líneas siguientes:
Se reinicia servicio:
service network restart
Y se comprueba….
Verificamos conectividad: Mirar Anexo H.
Se comprabará con el siguiente comando que está sincronizado (la sincronización se indica con un asterisco):
ntpq –np
Y muestra lo siguiente:
Database
La mayoría de servicios de OpenStack requieren una base de datos para guardar información.
Para ello se debe instalar la librería de MySQL Python en los nodos no controller. Ya realizado en el script.
OpenStack packages
A continuación se describirá la configuración que se debe completar después de configurar las máquinas para
instalar los paquetes de OpenStack más recientes.
75 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Si se quiere recurrir a una instalación ya con una configuración predeterminada se puede ejecutar el
script packages.sh del Anexo E.
Si se desea realizar una configuración más avanzada y personalizada ejecute los comandos abajo indicados.
En este caso se usarán los paquetes OpenStack del repositorio de RDO. Estos paquetes funcionan para RHEL
6, la versión compatible de este en CentOS, y Fedora 20.
Instalar yum-plugin-priorities plug-in. Este paquete permite la asignación de prioridades relativas a los
repositorios del software configurado.
yum install yum-plugin-priorities
Para permitir los repositorios de RDO, descargar e instalar el paquete rdo-release-icehouse:
yum install http://repos.fedorapeople.org/repos/openstack/openstack- icehouse/rdo-release-
icehouse-3.noarch.rpm
El paquete EPEL incluye las claves GPG para la firma de paquetes e información de repositorio. Ahora se
instalará la versión más reciente del paquete epel (ver
http://download.fedoraproject.org/pub/epel/6/x86_64/repoview/epel-release.html)
Por ejemplo:
yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-
release-6-8.noarch.rpm
El paquete openstack-utils contiene programas útiles que hacen la configuración en instalación más fácil. Estos
programas se usarán a lo largo de la guía de instalación.
Instala openstack-utils. Esto verifica que puedas acceder a los repositorios RDO:
yum install openstack-utils
El paquete openstack-selinux incluye los archivos de políticas que son necesarios para configurar SELinux
durante la instalación de OpenStack.
Instala openstack-selinux:
yum install openstack-selinux
Ahora se actualizarán los paquetes del sistema:
yum upgrade
FIN_DE_SCRIPT
Por último, se reinicia si la actualización ha incluido un nuevo paquete del kernel (si no está seguro reinicie):
reboot
Anexo B: Instalación en Nodo de Red
76
Ahora ya se puede proceder a la instalación de los servicios de OpenStack
En este equipo solo se instalará el módulo de red puesto que esa es su función
Servicio de Red
Antes de configurar este servicio es necesario habilitar ciertas funciones de red del kernel. Para ello se
ha de editar el fichero /etc/sysctl.conf para que contenga lo siguiente:
net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
Para implementar los cambios se ha de escribir en el terminal:
sysctl -p
A partir de este momento se puede ejecutar el script neutron_network.sh, disponible en el Anexo F,
aunque se hará con una configuración general donde las contraseñas serán redborder y la IP de túnel
será 10.0.152.101. Si se desea una instalación más compleja y personalizada, se ha seguir con los
pasos descritos a continuación.
A continuación se instalaran los componentes del servicio de red:
yum install openstack-neutron openstack-neutron-ml2 openstack-neutron-
openvswitch
Ahora se instalarán los componentes más comunes del servicio de red. La configuración de estos
componentes incluyen el mecanismo de autenticación, el servicio de mensajería y los plug-ins.
Para ello se han de escribir las siguientes líneas:
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_host controller
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
auth_protocol http
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
auth_port 35357
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
admin_tenant_name service
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
admin_user neutrón
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
admin_password NEUTRON_PASS
77 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
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
openstack-config --set /etc/neutron/neutron.conf DEFAULT core_plugin ml2
openstack-config --set /etc/neutron/neutron.conf DEFAULT service_plugins
router
Ahora se procederá a configurar el agente de capa 3 (L3). Este agente proporciona servicios de
encaminamiento para instanciar redes virtuales.
Se ejecutarán los siguientes comandos:
openstack-config --set /etc/neutron/l3_agent.ini DEFAULT interface_driver
neutron.agent.linux.interface.OVSInterfaceDriver
openstack-config --set /etc/neutron/l3_agent.ini DEFAULT use_namespaces True
Ahora se configurará el agente DHCP. Este agente proporciona servicios de DHCP para instanciar
redes virtuales:
openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT interface_driver
neutron.agent.linux.interface.OVSInterfaceDriver
openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT dhcp_driver
neutron.agent.linux.dhcp.Dnsmasq
openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT use_namespaces
True
A continuación se procederá a configurar el agente de metadatos, el cual proporciona información de
configuración como por ejemplo los credenciales para el acceso remoto a instancias.
En primer lugar se ha de ejecutar los siguientes comandos reemplazando las contraseñas por una que
se desee.
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT auth_url
http://controller:5000/v2.0
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT auth_region
regionOne
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
admin_tenant_name service
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT admin_user
neutrón
Anexo B: Instalación en Nodo de Red
78
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
admin_password NEUTRON_PASS
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
nova_metadata_ip controller
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
metadata_proxy_shared_secret METADATA_SECRET
LOS SIGUIENTES DOS PASOS SE HAN DE REALIZAR EN EL NODO CONTROLADOR
1. Configurar el servicio de computación para usar el servicio de metadatos
openstack-config --set /etc/nova/nova.conf DEFAULT
service_neutron_metadata_proxy true
openstack-config --set /etc/nova/nova.conf DEFAULT
neutron_metadata_proxy_shared_secret METADATA_SECRET
2. Reiniciar el la API del servicio de computación:
service openstack-nova-api restart
Ahora se configurará el plug-in de modulos de capa 2 (ML2). El plug-in ML2 usa el mecanismo OVS
para construir la estructura de encaminamiento virtual para las instancias.
Ejecutar los siguientes comandos:
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
type_drivers gre
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
tenant_network_types gre
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
mechanism_drivers openvswitch
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
ml2_type_gre tunnel_id_ranges 1:1000
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
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs
enable_tunneling True
79 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup firewall_driver neutron.agent.linux.iptables_firewall.
OVSHybridIptablesFirewallDriver
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup enable_security_group True
Configuración del servicio Open vSwitch (OVS). Este servicio proporciona la estructura de la capa
inferior del encaminamiento virtual para las instancias. El puente de integración br-int maneja el
tráfico de red interno a la instancia con OVS. El puente exterior br-ex maneja el tráfico de red externo
a la instancia con OVS. El puente exterior requiere un puerto en la interfaz física de la red externa
para proporcionar instancias con acceso a la red externa. En general, este puente une las redes externa
e internas en el entorno donde está instalado OpenStack
En primer lugar se ha de iniciar el servicio OVS y configurarlo para que se inicie al iniciar el sistema
operativo:
service openvswitch start
chkconfig openvswitch on
Se añade el puente de integración:
ovs-vsctl add-br br-int
Se añade el puerto externo:
ovs-vsctl add-br br-ex
Se añade un puerto al puente externos que conecta la interfaz física de la red externa. Sustituir
INTERFACE_NAME con el nombre actual de esta interfaz:
ovs-vsctl add-port br-ex INTERFACE_NAME
Para finalizar la instalación, los scripts de iniciación del servicio de red esperan un enlace simbólico
/etc/neutron/plugin.ini apuntando al fichero de configuración asociado con el plug-in
elegido. Usando ML2, por ejemplo, el enlace simbólico debe apuntar a /etc/neutron/plugins/ml2/ml2_conf.ini.
ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
Debido a un bug de empaquetado, el script de iniciación del agente de OVS busca explícitamente el
fichero de configuración del plug-in de OVS antes que un enlace simbólico
/etc/neutron/plugin.ini apuntando al fichero de configuración del plug-in de ML2. Se han
de ejecutar los siguientes comandos para resolver esto:
cp /etc/init.d/neutron-openvswitch-agent /etc/init.d/neutronopenvswitch-
agent.orig
Anexo B: Instalación en Nodo de Red
80
sed -i's,plugins/openvswitch/ovs_neutron_plugin.ini,plugin.ini,g'
/etc/init.d/neutron-openvswitch-agent
Por último, ser inician los servicios de red y se configuran para que empiecen al iniciar el
sistema.
service neutron-openvswitch-agent start;
service neutron-l3-agent start;
service neutron-dhcp-agent start;
service neutron-metadata-agent start;
chkconfig neutron-openvswitch-agent on;
chkconfig neutron-l3-agent on;
chkconfig neutron-dhcp-agent on;
chkconfig neutron-metadata-agent on;
FIN_DE_SCRIPT
81
ANEXO C: INSTALACIÓN EN NODO COMPUTE
Antes de todo se informa que para separar los comandos que se han de meter manualmente de los que se hacen mediante scripts se utilizará la notación FIN_DE_SCRIPT para indicar que el script utilizado termina ahí y el siguiente comando se introducirá manualmente en el terminal.
En primer lugar es necesario realizar unos pasos previos donde se activará iptables y se instalará NTP (network
time protocol, para sincronizar servicios a través de múltiples maquinas). Introducir estos comandos para
hacerlo:
service NetworkManager stop
service network start
chkconfig NetworkManager off
chkconfig network on
service iptables start
chkconfig iptables on
yum -y install ntp
service ntpd restart
chkconfig ntpd on;
yum -y install MySQL-python;
Si se prefiere se puede ejecutar el script config_red_network.sh que aparece en el Anexo F.
A continuación se mostrará cómo están configuradas las interfaces de red en este equipo. Se configurará este
equipo en función de lo mostrado en el apartado 2 de la memoria principal “Escenario y configuración inicial”
El hecho de que se numeren de esa forma os ficheros de configuración de las interfaces es, porque al ser el nodo
compute un equipo físico y tener solo una interfaz de red, se han virtualizando dos interfaces teniendo realmente
una física.
Fichero /etc/sysconfig/network-scripts/ifcfg-eth0.151
Anexo C: Instalación en Nodo Compute
82
Fichero /etc/sysconfig/network-scripts/ifcfg-eth0.152
Ahora se configurará la resolución de nombres:
Editar el archivo /etc/hosts añadiéndole las líneas siguientes:
Se reinicia servicio:
service network restart
Y se comprueba….
Verificamos conectividad: Mirar Anexo H.
Se comprabará con el siguiente comando que está sincronizado (la sincronización se indica con un asterisco):
ntpq –np
Y muestra lo siguiente:
Database
La mayoría de servicios de OpenStack requieren una base de datos para guardar información.
Para ello se debe instalar la librería de MySQL Python en los nodos no controller. Ya realizado en el script.
83 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
OpenStack packages
A continuación se describirá la configuración que se debe completar después de configurar las máquinas para
instalar los paquetes de OpenStack más recientes.
Si se quiere recurrir a una instalación ya con una configuración predeterminada se puede ejecutar el script
packages.sh del Anexo E.
Si se desea realizar una configuración más avanzada y personalizada ejecute los comandos abajo indicados.
En este caso se usarán los paquetes OpenStack del repositorio de RDO. Estos paquetes funcionan para RHEL
6, la versión compatible de este en CentOS, y Fedora 20.
Instalar yum-plugin-priorities plug-in. Este paquete permite la asignación de prioridades relativas a los
repositorios del software configurado.
yum install yum-plugin-priorities
Para permitir los repositorios de RDO, descargar e instalar el paquete rdo-release-icehouse:
yum install http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-
icehouse-3.noarch.rpm
El paquete EPEL incluye las claves GPG para la firma de paquetes e información de repositorio. Ahora se
instalará la versión más reciente del paquete epel (ver
http://download.fedoraproject.org/pub/epel/6/x86_64/repoview/epel-release.html)
Por ejemplo:
yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-
release-6-8.noarch.rpm
El paquete openstack-utils contiene programas útiles que hacen la configuración en instalación más fácil. Estos
programas se usarán a lo largo de la guía de instalación.
Instala openstack-utils. Esto verifica que puedas acceder a los repositorios RDO:
yum install openstack-utils
El paquete openstack-selinux incluye los archivos de políticas que son necesarios para configurar SELinux
durante la instalación de OpenStack.
Instala openstack-selinux:
yum install openstack-selinux
Ahora se actualizarán los paquetes del sistema:
yum upgrade
FIN_DE_SCRIPT
Por último, se reinicia si la actualización ha incluido un nuevo paquete del kernel (si no está seguro reinicie):
reboot
Anexo C: Instalación en Nodo Compute
84
Ahora ya se puede proceder a la instalación de los servicios de OpenStack
En este nodo solo se instalan el servicio de computación y el de red.
Servicio de Computación El servicio de computación delega en un hypervisor para correr instancias de máquinas virtuales.
OpenStack puede usar varios hypervisores, pero esta guía usa KVM. Se puede instalar mediante el
script nova_compute.sh, que se puede encontrar en el Anexo G, para hacerlo más simplificado, aunque
tendrá ciertos parámetros por defectos como las contraseñas (todas redborder).
Para una instalación personalizada se han de seguir los siguientes pasos.
En primer lugar se han de instalar los paquetes del servicio de computación:
yum install openstack-nova-compute
A continuación se editará el fichero de configuración /etc/nova/nova.conf:
openstack-config --set /etc/nova/nova.conf database connection
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
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
Configuración del servicio de computación para usar el servicio de mensajería Qpid a través de las
siguientes características de configuración:
openstack-config --set /etc/nova/nova.conf DEFAULT rpc_backend qpid
openstack-config --set /etc/nova/nova.conf DEFAULT qpid_hostname
controller
85 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Configuración del servicio de computación para proporcionar acceso remoto mediante consola a las
instancias.
openstack-config --set /etc/nova/nova.conf DEFAULT my_ip compute
openstack-config --set /etc/nova/nova.conf DEFAULT vnc_enabled True
openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen
0.0.0.0
openstack-config --set /etc/nova/nova.conf DEFAULT
vncserver_proxyclient_address compute
openstack-config --set /etc/nova/nova.conf DEFAULT
novncproxy_base_url http://controller:6080/vnc_auto.html
Ahora se especificará el equipo que ejecuta el servicio de imágenes:
openstack-config --set /etc/nova/nova.conf DEFAULT glance_host
controller
Si el resultado del siguiente comando
egrep -c '(vmx|svm)' /proc/cpuinfo
devuelve un valor mayor que uno, sáltese el paso siguiente
openstack-config --set /etc/nova/nova.conf libvirt virt_type qemu
Por último se han de reiniciar los servicios y configurarlos para que se inicien al iniciar el sistema:
service libvirtd start;
service messagebus start;
service openstack-nova-compute start;
chkconfig libvirtd on;
chkconfig messagebus on;
chkconfig openstack-nova-compute on;
FIN_DE_SCRIPT
Servicio de Red
Antes de configurar este servicio es necesario habilitar ciertas funciones de red del kernel. Para ello se
ha de editar el fichero /etc/sysctl.conf para que contenga lo siguiente:
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
Anexo C: Instalación en Nodo Compute
86
Para implementar los cambios se ha de escribir en el terminal:
sysctl -p
A partir de este momento se puede ejecutar el script neutron_compute.sh, disponible en el Anexo G,
aunque se hará con una configuración general donde las contraseñas serán redborder y la IP de túnel
será 10.0.152.102. Si se desea una instalación más compleja y personalizada, se ha seguir con los pasos
descritos a continuación.
A continuación se instalaran los componentes del servicio de red:
yum install openstack-neutron openstack-neutron-ml2 openstack-neutron-
openvswitch
Ahora se instalarán los componentes más comunes del servicio de red. La configuración de estos
componentes incluyen el mecanismo de autenticación, el servicio de mensajería y los plug-ins.
Para ello se han de escribir las siguientes líneas:
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_host controller
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
auth_protocol http
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
auth_port 35357
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
admin_tenant_name service
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
admin_user neutrón
openstack-config --set /etc/neutron/neutron.conf keystone_authtoken
admin_password NEUTRON_PASS
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
openstack-config --set /etc/neutron/neutron.conf DEFAULT core_plugin ml2
openstack-config --set /etc/neutron/neutron.conf DEFAULT service_plugins
router
87 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
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:
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
type_drivers gre
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
tenant_network_types gre
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
mechanism_drivers openvswitch
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
ml2_type_gre tunnel_id_ranges 1:1000
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
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs
enable_tunneling True
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup firewall_driver neutron.agent.linux.iptables_firewall.
OVSHybridIptablesFirewallDriver
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup enable_security_group True
Configuración del servicio Open vSwitch (OVS). Este servicio proporciona la estructura de la capa
inferior del encaminamiento virtual para las instancias. El puente de integración br-int maneja el
tráfico de red interno a la instancia con OVS. En primer lugar se ha de iniciar el servicio OVS y
configurarlo para que se inicie al iniciar el sistema operativo:
service openvswitch start
chkconfig openvswitch on
Se añade el puente de integración:
ovs-vsctl add-br br-int
Debido al modo de distribución usado (neutron-compute), se ha de reconfigurar el servicio de
computación para gestionar las redes a través del servicio de red.
openstack-config --set /etc/nova/nova.conf DEFAULT network_api_class
nova.network.neutronv2.api.API
Anexo C: Instalación en Nodo Compute
88
openstack-config --set /etc/nova/nova.conf DEFAULT neutron_url
http://controller:9696
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
http://controller:35357/v2.0
openstack-config --set /etc/nova/nova.conf DEFAULT linuxnet_interface_driver
nova.network.linux_net.LinuxOVSInterfaceDriver
openstack-config --set /etc/nova/nova.conf DEFAULT firewall_driver
nova.virt.firewall.NoopFirewallDriver
openstack-config --set /etc/nova/nova.conf DEFAULT security_group_api neutron
Para finalizar la instalación, los scripts de iniciación del servicio de red esperan un enlace simbólico
/etc/neutron/plugin.ini apuntando al fichero de configuración asociado con el plug-in
elegido. Usando ML2, por ejemplo, el enlace simbólico debe apuntar a /etc/neutron/plugins/ml2/ml2_conf.ini.
ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
Debido a un bug de empaquetado, el script de iniciación del agente de OVS busca explícitamente el
fichero de configuración del plug-in de OVS antes que un enlace simbólico
/etc/neutron/plugin.ini apuntando al fichero de configuración del plug-in de ML2. Se han
de ejecutar los siguientes comandos para resolver esto:
cp /etc/init.d/neutron-openvswitch-agent /etc/init.d/neutronopenvswitch-
agent.orig
sed -i's,plugins/openvswitch/ovs_neutron_plugin.ini,plugin.ini,g'
/etc/init.d/neutron-openvswitch-agent
Se reinicia el servicio de computación:
service openstack-nova-compute restart
89 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
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
Anexo C: Instalación en Nodo Compute
90
91
ANÉXO D: INSTALACIÓN Y CASOS DE USO DE CHEF
Este anexo explicará cómo instalar todos los componentes de Chef necesarios para poder integrarlo
de una manera funcionalmente completa con OpenStack.
Para ello se precisan ciertos prerrequisitos:
Tener configurado completamente un hostname.
Tener configurada una entrada en el DNS.
Tener ciertos paquetes instalados:
o yum install wget curl –y
Instalación de Chef Server
A continuación se procederá a la xplicacion de la instalación del servidor de Chef. Para ello se han
de realizar los siguientes pasos.
rpm -ivh https://opscode-omnibus-
packages.s3.amazonaws.com/el/6/x86_64/chef-server-11.1.4-
1.el6.x86_64.rpm
Una vez ya instalado el servidor de Chef, se ha de configurar ejecutando el siguiente comando:
chef-server-ctl reconfigure
El comando chef-server-ctl configurará los componentes requeridos, incluyendo Erchef, RabbitMQ,
PostgreSQL, y todos los cookbooks que serán usados por Chef para mantener el Servidor de Chef 11.x.
Por último verificar la instalación del servidor de Chef mediante el siguiente comando:
chef-server-ctl test
Instalacion de plug-in knife para openstack
Este plug-in da a knife la capacidad de gestionar y crear instancias en la nubesde OpenStack.
Para ello, primero se ha comprobar que se esta corriendo en el host la última versión de Chef, puesto que para
versiones anteriores a la 10, este plug-in no funciona.
gem install chef
Este plug-in es distribuido como una Gema de Ruby, por tanto para instalarlo hay que hacer lo siguiente:
gem install knife-openstack
Anéxo D: Instalación y Casos de Uso de Chef
92
Configuración
Para poder comunicarse con la API de OpenStack, se necesita decirle a Knife el endpoint de la API de
Autenticacion de OpenStack y los credenciales del dashboard. La manera mas fácil de hacerlo es creando la
siguiente entrada en el fichero knife.rb:
Ejemplo de Uso
Para lanzar una instancia mediante Knife se ha realizado una sentencia de ejemplo:
knife openstack server create -A 'demo' -K 'redborder' -T 'demo' --
openstack-api-endpoint 'http://controller:8774/v2/%(tenant_id)s' -f 1 –I
2cf8e04b-4a3b-4321-8cf6-ee7f6-ee711e81beec --network-ids dadc70d3-f8e1-
45f3-92b6-7fd7351c8324 -r 'role[_member_]';
Con la anterior línea se está instanciando con el usuario demo, contraseña redborder e inquilino demo la
imagen 2cf8e04b-4a3b-4321-8cf6-ee7f6-ee711e81beec con el sabor 1, en la red dadc70d3-f8e1-45f3-92b6-
7fd7351c8324 con el role member y un endponint de la API en 'http://controller:8774/v2/%(tenant_id)s'.
knife[:openstack_auth_url]= http://controller:5000/v2.0/tokens"
knife[:openstack_username] = "admin"
knife[:openstack_password] = "redborder"
knife[:openstack_tenant] = "admin”
93
ANÉXO E: SCRIPTS DEL NODO CONTROLADOR
config_red.sh
packages.sh
service NetworkManager stop;
service network restart;
chkconfig NetworkManager off;
chkconfig network on;
service iptables restart;
chkconfig iptables on;
yum -y install ntp;
service ntpd restart;
chkconfig ntpd on;
yum -y install yum-plugin-priorities;
yum -y install
http://repos.fedorapeople.org/repos/openstack/openstack-
icehouse/rdo-release-icehouse-3.noarch.rpm;
yum -y install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-
release-6-8.noarch.rpm;
yum -y install openstack-utils;
yum -y install openstack-utils;
yum -y upgrade;
Anéxo E: Scripts del Nodo Controlador
94
keystone_1.sh
keystone_2.sh
yum install -y openstack-keystone python-keystoneclient;
openstack-config --set /etc/keystone/keystone.conf database
connection mysql://keystone:redborder@controller/keystone;
su -s /bin/sh -c "keystone-manage db_sync" keystone;
ADMIN_TOKEN=redborder;
echo $ADMIN_TOKEN;
openstack-config --set /etc/keystone/keystone.conf DEFAULT
admin_token $ADMIN_TOKEN;
keystone-manage pki_setup --keystone-user keystone --keystone-
group keystone;
chown -R keystone:keystone /etc/keystone/ssl;
chmod -R o-rwx /etc/keystone/ssl;
service openstack-keystone start;
chkconfig openstack-keystone on;
export OS_SERVICE_TOKEN=$ADMIN_TOKEN;
export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0;
keystone user-create --name=admin --pass=redborder --
email=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;
95 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
keystone tenant-create --name=demo --description="Demo Tenant";
keystone user-role-add --user=demo --role=_member_ --tenant=demo;
keystone tenant-create --name=service --description="Service
Tenant";
keystone service-create --name=keystone --type=identity --
description="OpenStack Identity";
keystone endpoint-create --service-id=$(keystone service-list | awk
'/ identity / {print $2}') --publicurl=http://controller:5000/v2.0
--internalurl=http://controller:5000/v2.0 --
adminurl=http://controller:35357/v2.0;
unset OS_SERVICE_TOKEN OS_SERVICE_ENDPOINT;
keystone --os-username=admin --os-password=redborder --os-auth-
url=http://controller:35357/v2.0 token-get;
keystone --os-username=admin --os-password=redborder --os-tenant-
name=admin --os-auth-url=http://controller:35357/v2.0 token-get;
echo "export OS_USERNAME=admin" >> admin-openrc.sh;
echo "export OS_PASSWORD=redborder" >> admin-openrc.sh;
echo "export OS_TENANT_NAME=admin" >> admin-openrc.sh;
echo "export OS_AUTH_URL=http://controller:35357/v2.0" >> admin-
openrc.sh;
echo "export OS_USERNAME=demo" >> demo-openrc.sh;
echo "export OS_PASSWORD=redborder" >> demo-openrc.sh;
echo "export OS_TENANT_NAME=demo" >> demo-openrc.sh;
echo "export OS_AUTH_URL=http://controller:35357/v2.0" >> demo-
openrc.sh;
source admin-openrc.sh;
keystone token-get;
keystone user-list;
keystone user-role-list --user admin --tenant admin;
Anéxo E: Scripts del Nodo Controlador
96
clients.sh
glance_1.sh
yum -y install python-ceilometerclient;
yum -y install python-cinderclient;
yum -y install python-glanceclient;
yum -y install python-heatclient;
yum -y install python-keystoneclient;
yum -y install python-neutronclient;
yum -y install python-novaclient;
yum -y install python-swiftclient;
yum -y install python-troveclient;
yum install openstack-glance python-glanceclient;
openstack-config --set /etc/glance/glance-api.conf database
connection mysql://glance:redborder@controller/glance;
openstack-config --set /etc/glance/glance-registry.conf
database connection
mysql://glance:redborder@controller/glance;
openstack-config --set /etc/glance/glance-api.conf DEFAULT
rpc_backend qpid;
openstack-config --set /etc/glance/glance-api.conf DEFAULT
qpid_hostname controller;
97 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
glance_2.sh
su -s /bin/sh -c "glance-manage db_sync" glance;
keystone user-create --name=glance --pass=redborder --
email=antoniocobosdominguez@gmail.com;
keystone user-role-add --user=glance --tenant=service --
role=admin;
openstack-config --set /etc/glance/glance-api.conf
keystone_authtoken auth_uri http://controller:5000;
openstack-config --set /etc/glance/glance-api.conf
keystone_authtoken auth_host controller;
openstack-config --set /etc/glance/glance-api.conf
keystone_authtoken auth_port 35357;
openstack-config --set /etc/glance/glance-api.conf
keystone_authtoken auth_protocol http;
openstack-config --set /etc/glance/glance-api.conf
keystone_authtoken admin_tenant_name service;
openstack-config --set /etc/glance/glance-api.conf
keystone_authtoken admin_user glance;
openstack-config --set /etc/glance/glance-api.conf
keystone_authtoken admin_password redborder;
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;
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken auth_host controller;
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken auth_port 35357;
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken auth_protocol http;
Anéxo E: Scripts del Nodo Controlador
98
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken admin_tenant_name service;
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken admin_user glance;
openstack-config --set /etc/glance/glance-registry.conf
keystone_authtoken admin_password redborder;
openstack-config --set /etc/glance/glance-registry.conf
paste_deploy flavor keystone;
keystone service-create --name=glance --type=image --
description="OpenStack Image Service";
keystone endpoint-create --service-id=$(keystone service-
list | awk '/ image / {print $2}') --
publicurl=http://controller:9292 --
internalurl=http://controller:9292 --
adminurl=http://controller:9292;
service openstack-glance-api start;
service openstack-glance-registry start;
chkconfig openstack-glance-api on;
chkconfig openstack-glance-registry on;
mkdir /tmp/images;
cd /tmp/images/;
wget http://cdn.download.cirros-cloud.net/0.3.2/cirros-
0.3.2-x86_64-disk.img;
source /root/admin-openrc.sh;
glance image-create --name "cirros-0.3.2-x86_64" --disk-
format qcow2 --container-format bare --is-public True --
progress < cirros-0.3.2-x86_64-disk.img;
glance image-list;
rm -r /tmp/images;
99 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
nova_1.sh
nova_2.sh
yum -y install openstack-nova-api openstack-nova-cert
openstack-nova-conductor openstack-nova-console openstack-
nova-novncproxy openstack-nova-scheduler python-novaclient;
openstack-config --set /etc/nova/nova.conf database
connection mysql://nova:redborder@controller/nova;
openstack-config --set /etc/nova/nova.conf DEFAULT
rpc_backend qpid;
openstack-config --set /etc/nova/nova.conf DEFAULT
qpid_hostname controller;
openstack-config --set /etc/nova/nova.conf DEFAULT my_ip
controller;
openstack-config --set /etc/nova/nova.conf DEFAULT
vncserver_listen controller;
openstack-config --set /etc/nova/nova.conf DEFAULT
vncserver_proxyclient_address controller;
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;
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;
Anéxo E: Scripts del Nodo Controlador
100
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 redborder;
keystone service-create --name=nova --type=compute --
description="OpenStack Compute";
keystone endpoint-create --service-id=$(keystone service-
list | awk '/ compute / {print $2}') --
publicurl=http://controller:8774/v2/%\(tenant_id\)s --
internalurl=http://controller:8774/v2/%\(tenant_id\)s --
adminurl=http://controller:8774/v2/%\(tenant_id\)s;
service openstack-nova-api start;
service openstack-nova-cert start;
service openstack-nova-consoleauth start;
service openstack-nova-scheduler start;
service openstack-nova-conductor start;
service openstack-nova-novncproxy start;
chkconfig openstack-nova-api on;
chkconfig openstack-nova-cert on;
chkconfig openstack-nova-consoleauth on;
chkconfig openstack-nova-scheduler on;
chkconfig openstack-nova-conductor on;
chkconfig openstack-nova-novncproxy on;
nova image-list;
101 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
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 service-
list | awk '/ network / {print $2}') --publicurl
http://controller:9696 --adminurl http://controller:9696 --
internalurl http://controller:9696;
yum -y install openstack-neutron openstack-neutron-ml2
python-neutronclient;
openstack-config --set /etc/neutron/neutron.conf database
connection mysql://neutron:redborder@controller/neutron;
openstack-config --set /etc/neutron/neutron.conf 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_host controller;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken auth_protocol http;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken auth_port 35357;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken admin_tenant_name service;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken admin_user neutron;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken admin_password redborder;
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;
Anéxo E: Scripts del Nodo Controlador
102
openstack-config --set /etc/neutron/neutron.conf DEFAULT
notify_nova_on_port_status_changes True;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
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;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
nova_admin_tenant_id $(keystone tenant-list | awk '/ service
/ { print $2 }');
openstack-config --set /etc/neutron/neutron.conf DEFAULT
nova_admin_password redborder;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
nova_admin_auth_url http://controller:35357/v2.0;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
core_plugin ml2;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
service_plugins router;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
ml2 type_drivers gre;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
ml2 tenant_network_types gre;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
ml2 mechanism_drivers openvswitch
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
ml2_type_gre tunnel_id_ranges 1:1000;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup firewall_driver
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirew
allDriver;
103 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup enable_security_group True;
openstack-config --set /etc/nova/nova.conf DEFAULT
network_api_class nova.network.neutronv2.api.API;
openstack-config --set /etc/nova/nova.conf DEFAULT
neutron_url http://controller:9696;
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 redborder;
openstack-config --set /etc/nova/nova.conf DEFAULT
neutron_admin_auth_url http://controller:35357/v2.0;
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;
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;
Anéxo E: Scripts del Nodo Controlador
104
105
ANÉXO F: SCRIPTS DEL NODO DE RED
config_red_network.sh
neutron_network.sh
service NetworkManager stop;
service network restart;
chkconfig NetworkManager off;
chkconfig network on;
service iptables restart;
chkconfig iptables on;
yum -y install ntp;
service ntpd restart;
chkconfig ntpd on;
yum -y install MySQL-python;
yum -y install openstack-neutron openstack-neutron-ml2 openstack-
neutron-openvswitch;
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_host controller;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken auth_protocol http;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken auth_port 35357;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken admin_tenant_name service;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken admin_user neutron;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken admin_password redborder;
Anéxo F: Scripts del Nodo de Red
106
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;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
core_plugin ml2;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
service_plugins router;
openstack-config --set /etc/neutron/l3_agent.ini DEFAULT
interface_driver neutron.agent.linux.interface.OVSInterfaceDriver;
openstack-config --set /etc/neutron/l3_agent.ini DEFAULT
use_namespaces True;
openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT
interface_driver neutron.agent.linux.interface.OVSInterfaceDriver;
openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT
dhcp_driver neutron.agent.linux.dhcp.Dnsmasq;
openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT
use_namespaces True;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
auth_url http://controller:5000/v2.0;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
auth_region regionOne;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
admin_tenant_name service;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
admin_user neutron;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
admin_password redborder;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
nova_metadata_ip controller;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
metadata_proxy_shared_secret redborder;
107 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
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;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
core_plugin ml2;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
service_plugins router;
openstack-config --set /etc/neutron/l3_agent.ini DEFAULT
interface_driver neutron.agent.linux.interface.OVSInterfaceDriver;
openstack-config --set /etc/neutron/l3_agent.ini DEFAULT
use_namespaces True;
openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT
interface_driver neutron.agent.linux.interface.OVSInterfaceDriver;
openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT
dhcp_driver neutron.agent.linux.dhcp.Dnsmasq;
openstack-config --set /etc/neutron/dhcp_agent.ini DEFAULT
use_namespaces True;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
auth_url http://controller:5000/v2.0;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
auth_region regionOne;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
admin_tenant_name service;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
admin_user neutron;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
admin_password redborder;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
nova_metadata_ip controller;
openstack-config --set /etc/neutron/metadata_agent.ini DEFAULT
metadata_proxy_shared_secret redborder;
Anéxo F: Scripts del Nodo de Red
108
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
type_drivers gre;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
tenant_network_types gre;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
mechanism_drivers openvswitch;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
ml2_type_gre tunnel_id_ranges 1:1000;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs
local_ip 10.0.152.101;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs
tunnel_type gre;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs
enable_tunneling True;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup firewall_driver
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDri
ver;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup enable_security_group True;
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;
ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini;
cp /etc/init.d/neutron-openvswitch-agent /etc/init.d/neutron-
openvswitch-agent.orig;
sed -i 's,plugins/openvswitch/ovs_neutron_plugin.ini,plugin.ini,g'
/etc/init.d/neutron-openvswitch-agent;
service neutron-openvswitch-agent start;
service neutron-l3-agent start;
service neutron-dhcp-agent start;
service neutron-metadata-agent start;
chkconfig neutron-openvswitch-agent on;
chkconfig neutron-l3-agent on;
chkconfig neutron-dhcp-agent on;
chkconfig neutron-metadata-agent on;
109
ANÉXO G: SCRIPTS DEL NODO COMPUTE
neutron_compute.sh
yum -y install openstack-neutron-ml2 openstack-neutron-
openvswitch;
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_host controller;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken auth_protocol http;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken auth_port 35357;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken admin_tenant_name service;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken admin_user neutron;
openstack-config --set /etc/neutron/neutron.conf
keystone_authtoken admin_password redborder;
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;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
core_plugin ml2;
openstack-config --set /etc/neutron/neutron.conf DEFAULT
service_plugins router;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
type_drivers gre;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
tenant_network_types gre;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ml2
mechanism_drivers openvswitch;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
ml2_type_gre tunnel_id_ranges 1:1000;
Anéxo G: Scripts del Nodo Compute
110
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs
local_ip 10.0.152.102;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs
tunnel_type gre;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini ovs
enable_tunneling True;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup firewall_driver
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDri
ver;
openstack-config --set /etc/neutron/plugins/ml2/ml2_conf.ini
securitygroup enable_security_group True;
service openvswitch restart;
chkconfig openvswitch on;
ovs-vsctl add-br br-int;
openstack-config --set /etc/nova/nova.conf DEFAULT
network_api_class nova.network.neutronv2.api.API;
openstack-config --set /etc/nova/nova.conf DEFAULT neutron_url
http://controller:9696;
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 redborder;
openstack-config --set /etc/nova/nova.conf DEFAULT
neutron_admin_auth_url http://controller:35357/v2.0;
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;
111 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
nova_compute.sh
ln -s plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini;
cp /etc/init.d/neutron-openvswitch-agent /etc/init.d/neutron-
openvswitch-agent.orig;
sed -i 's,plugins/openvswitch/ovs_neutron_plugin.ini,plugin.ini,g'
/etc/init.d/neutron-openvswitch-agent;
service openstack-nova-compute start;
service neutron-openvswitch-agent restart;
chkconfig neutron-openvswitch-agent on;
yum -y install openstack-nova-compute;
openstack-config --set /etc/nova/nova.conf database connection
mysql://nova:redborder@controller/nova;
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 redborder;
openstack-config --set /etc/nova/nova.conf DEFAULT rpc_backend
qpid;
Anéxo G: Scripts del Nodo Compute
112
openstack-config --set /etc/nova/nova.conf DEFAULT qpid_hostname
controller;
openstack-config --set /etc/nova/nova.conf DEFAULT my_ip compute;
openstack-config --set /etc/nova/nova.conf DEFAULT vnc_enabled
True;
openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen
0.0.0.0;
openstack-config --set /etc/nova/nova.conf DEFAULT
vncserver_proxyclient_address compute;
openstack-config --set /etc/nova/nova.conf DEFAULT
novncproxy_base_url http://controller:6080/vnc_auto.html;
openstack-config --set /etc/nova/nova.conf DEFAULT glance_host
controller;
service libvirtd start;
service messagebus start;
service openstack-nova-compute start;
chkconfig libvirtd on;
chkconfig messagebus on;
chkconfig openstack-nova-compute on;
113
ANEXO H: PINGS
Ping desde el nodo controlador a internet:
Ping desde el nodo controlador a nodo de red (interfaz de gestión):
Ping desde el nodo controlador a nodo compute (interfaz de gestión):
Anexo H: Pings
114
Ping desde el nodo de red a internet:
Ping desde el nodo de red a nodo controlador (interfaz de gestión):
Ping desde el nodo de red a nodo compute (túnel de instancia):
Ping desde el nodo de compute a internet:
115 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
Ping desde el nodo de compute a nodo controlador (interfaz de gestión):
Ping desde el nodo de compute a nodo de red (túnel de instancia):
117
REFERENCIAS
[1] http://cloud-america.com/?page_id=257
[2] http://www.blogvmware.com/2013/12/pool-de-recursos.html
[3] http://cloud-america.com/?page_id=257
[4] http://docs.openstack.org/developer/sahara/overview.html
[5] http://searchaws.techtarget.com/definition/Opscode-Chef
[6] https://docs.getchef.com/chef_overview_server.html
119
ÍNDICE DE CONCEPTOS
i Instancia: Clon de una imagen que se crea a demanda del usuario
en uno de los nodos del cloud.
ii EC2 (Elastic Cloud Computing): Es un servicio web que proporciona capacidad informática con tamaño
modificable en la nube. Está diseñado para facilitar a los desarrolladores recursos informáticos escalables
basados en web.
iii PXE: Preboot eXecution Environment (Entorno de ejecución de prearranque), es un entorno para arrancar e
instalar el sistema operativo en ordenadores a través de una red, de manera independiente de los dispositivos de
almacenamiento de datos disponibles (como discos duros) o de los sistemas operativos instalados.
iv Qpid: Sistema de mensajería que implemente AMQP (Advanced Message Queiuing Protocol). Proporciona
gestión de transacciones, colas, distribuciones, seguridad, gestión y soporte de multiplataformas heterogéneas.
v Tenant: Contenedor usado para agrupar o aislar recursos y/o objetos de identidad. Dependiendo del operador
del servicio, un tenant (inquilino) puede asociarse a un consumidor, cuenta, organización o proyecto.
vi GlusterFS: Gluster File System o GlusterFS, es un multiescalable sistema de archivos para NAS. Este permite
agregar varios servidores de archivos sobre Ethernet o interconexiones Infiniband RDMA en un gran entorno
de archivos de red en paralelo.
vii Nodo: Punto de intersección, conexión o unión de varios elementos que confluyen en el mismo lugar.
viii KVM: Máquina virtual basada en el núcleo.Es una solución para implementar virtualización completa con
Linux.
ix QEMU: emulador de procesadores basado en la traducción dinámica de binarios (conversión del código
binario de la arquitectura fuente en código entendible por la arquitectura huésped). QEMU también tiene
capacidades de virtualización dentro de un sistema operativo, ya sea GNU/Linux, Windows, o cualquiera de los
admitidos.
x Bond: Bonding es una forma de obtener enlaces redundantes en bridges, tanto en aparatos de alta gama, como
en máquinas con software libre.
xi REST: REpresentational State Transfer, es un tipo de arquitectura de desarrollo web que se apoya totalmente
en el estándar HTTP. REST nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier
dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y convencional que otras
alternativas que se han usado en los últimos diez años como SOAP y XML-RPC.
xii Tokens: Un texto de bits arbitrarios que es usado para acceder a los recursos. Cada token dice q eu servicios
se pueden acceder.
Índice de Conceptos
120
xiii Usuario: Representación digital de una persona, sistema, oservicio que quiere usar los servicios de la nube de
OpenStack.
xiv Credenciales: Datos conocidos solo por el usuario que demuestra que es él.
xv Autenticación: Acto de confirmar la identificación de un usuario.
xvi Servicio: Proporciona uno o mas endpoint a través de los cuales, los usuarios pueden acceder a operaciones
de rendimieno y accesos de recursos.
xvii Endpoint: Dirección de red accesible, normalmente descrita por una URL, donde se pude tener acceso al
servicio.
xviii Rol: Personalidad que un usuario asume y que este sabe a que cosa especificas puede acceder con ese rol.
xix Daemons: Ttipo especial de proceso informático no interactivo, es decir, que se ejecuta en segundo plano en
vez de ser controlado directamente por el usuario. Este tipo de programas continua en el sistema, es decir, que
puede ser ejecutado en forma persistente o reiniciado si se intenta matar el proceso dependiendo de configuración
del demonio y políticas del sistema. La palabra daemon viene de las siglas en ingles D.A.E.MON (Disk And
Execution Monitor).
xx Metadatos: El concepto de metadatos es análogo al uso de índices para localizar objetos en vez de datos. Por
ejemplo, en una biblioteca se usan fichas que especifican autores, títulos, casas editoriales y lugares para buscar
libros. Así, los metadatos ayudan a ubicar datos.
xxi Linux network namespaces: Instalacion de linux que permite tener un conjnto de interfaces y entradas a la
tabla de enrutamiento simples.
xxii IPs flotantes: Dirección IP pública que puede asociarse a diferentes instancias con el fin de acceder a ellas
desde fuera.
xxiii Django: Framework de desarrollo web de código abierto, escrito en Python, que respeta el paradigma
conocido como Model Template View. Permite una creación de sitios web mas sencilla.
xxiv Orquestación: Gestión de sistemas y automatización de insfraestructura de la nube.
xxv Hadoop: Framework de software que soporta aplicaciones distribuidas bajo una licencia libre.1 Permite a las
aplicaciones trabajar con miles de nodos y petabytes de datos.
xxvi Ruby: Lenguaje de programación interpretado, reflexivo y orientado a objetos.
xxvii Erlang: Un lenguaje de programación concurrente (u orientado a la concurrencia) y un sistema de ejecución
que incluye una máquina virtual (BEAM) y bibliotecas (OTP).
121 Despliegue de arquitectura cloud basada en OpenStack y su integración con Chef sobre CentOS
xxviii Framewotk: Estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o
módulos de software concretos, que puede servir de base para la organización y desarrollo de software.
Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras
herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto.
xxix Cookbooks: Unidad fundamental de distribuvción de configuración y póliticas. Cada cookbook (libro de
recetas) define un escenario y contiene todo los componentes que se requieren para montar ese escenario.
xxx Recipes: Receta del Cookbook.
xxxi DSL: Lenguaje de computación especializado en una dominio de aplicación en particular.
xxxii Front-end: Parte del software que interactúa con el o los usuarios.
top related