Agilizando la infraestructura I: Provisioning

Estoy evaluando soluciones para poder modernizar la infraestructura que manejamos actualmente. La tendencia es ir a un modelo IaaS, pero tampoco se puede pasar de un modelo tradicional (de principio de siglo) a un IaaS completo en unos meses.

Lo primero que planteo es el tema del aprovisionamiento de servidores, ya sean físicos o virtuales. Hasta ahora veníamos utilizando herramientas de Oracle, puesto que la mayoría de los servidores que administrábamos eran Solaris. Pero últimamente empezamos a tener cada vez mas servidores linux y el uso de estas herramientas de Oracle es muy tedioso.

Entre las herramientas que he encontrado, la que mas me ha gustado y con la que he empezado a hacer pruebas es Foreman. Foreman se trata de una herramienta Open Source que utiliza puppet para gestionar el ciclo de vida de los servidores y ademas esta soportada por Red Hat, con lo que se garantiza que el proyecto tiene la suficiente calidad como para integrarlo en un entorno empresarial.

Instalación de Foreman
La instalación, como siempre que se utilizan repositorios, no puede ser mas sencilla. Se añaden los repositorios del proyecto (y el EPEL en caso de no tenerlo ya) y en este caso se instala el programa que se encargará de la configuración:

[root@foreman ~]# yum -y install http://yum.theforeman.org/releases/1.5/el6/x86_64/foreman-release.rpm
[root@foreman ~]# yum -y install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@foreman ~]# yum -y install foreman-installer

Como nota, en la web de Foreman recomiendan instalarlo en un servidor que disponga de la versión Open Source de puppet, puesto que al parecer es incompatible con la versión Enterprise.

El instalador se puede lanzar de varias formas, a mi me gusta el modo interactivo. Una de las cosas que hay que tocar el el tipo de Base de Datos. Por defecto es Postgres, pero si mas adelante se quiere integrar Foreman con Packstack será necesario pasar a una base de datos MySQL, con lo que yo lo cambio antes de empezar.

    [root@foreman ~]# foreman-installer -i
    Welcome to the Foreman installer!
    ———————————

    This wizard will gather all required information. You can change any parameter
    to your needs.

    Ready to start? (y/n)
    y
    Main Config Menu
    1. [✓] Configure foreman_plugin_templates
    2. [✓] Configure foreman_proxy
    3. [✓] Configure foreman_plugin_puppetdb
    4. [✓] Configure foreman_compute_openstack
    5. [✓] Configure foreman_plugin_discovery
    6. [✓] Configure foreman_plugin_default_hostgroup
    7. [✗] Configure foreman_plugin_chef
    8. [✓] Configure foreman_plugin_bootdisk
    9. [✗] Configure foreman_compute_rackspace
    10. [✗] Configure foreman_plugin_hooks
    11. [✓] Configure foreman #para cambiar el tipo de BBDD
    12. [✗] Configure foreman_compute_vmware
    13. [✓] Configure foreman_compute_ovirt
    14. [✓] Configure foreman_plugin_setup
    15. [✗] Configure foreman_compute_gce
    16. [✗] Configure foreman_compute_ec2
    17. [✓] Configure puppet
    18. [✓] Configure foreman_compute_libvirt
    19. Display current config
    20. Save and run
    21. Cancel run without Saving
    Choose an option from the menu… 20

El instalador empieza a ejecutar varios módulos de puppet e instala y configura todo lo necesario. En unos minutos tenemos nuestro servidor de foreman preparado:

    Installing — /etc/httpd/conf/httpd.confhed2014-03-20 11:17:58 [38%] [……………………….. Installing — /etc/sysconfig/foremanig/fore2014-06-18 11:00:08.000 [99%] [………………………………………………………………Installing Done [100%] […………………………………………………………………]
    Success!
    * Foreman is running at https://foreman.globalia.com
    Default credentials are ‘admin:changeme’
    * Foreman Proxy is running at https://foreman.globalia.com:8443
    * Puppetmaster is running at port 8140
    The full log is at /var/log/foreman-installer/foreman-installer.log

Configuración del provisioning

Para configurar el provisoning existe un wizard donde se especifican el origen del software y la configuración básica de red. Se accede a través del menú Infrastructure/Provisioning setup:

En el primer paso indicamos sobre que segmento de red se va a hacer el autoprovisioning:

A continuación varios datos sobre la red:

​En el paso 3 nos indicará que ejecutemos de nuevo el instalador de Foreman adaptado a nuestra configuración. Nos dará dos opciones, si queremos utilizar DHCP o no:

​En el cuarto paso se selecciona el origen de los medios de instalación. Se pueden utilizar los repositorios públicos, pero es recomendable utilizar un repositorio local para acelerar el proceso de instalación:

​En el último paso ya podemos lanzar la creación de nuevos servidores, pero antes es necesario configurar algunas cosas mas.

Creación del repositorio:
Lo mas sencillo para crear un repositorio local es utilizar los DVD de instalación, en este caso de CentOS 6.5. Se copian los rpm a la carpeta que contendrá nuestro repositorio:

[root@foreman ~]# cd /opt/jgp/
[root@foreman jgp]# mkdir -p repo/centos/6.5/x86_64/repodata
[root@foreman jgp]# cp -a /media/DVD/dvd1/Packages/*.rpm repo/centos/6.5/x86_64/
[root@foreman jgp]# cp -a /media/DVD/dvd2/Packages/*.rpm repo/centos/6.5/x86_64/

Se copian las imágenes de inicio y el xml también al repositorio:

[root@foreman jgp]# cd repo/centos/6.5/x86_64/
[root@foreman x86_64]# cp -r /media/DVD/dvd1/images .
[root@foreman x86_64]# cp /media/DVD/dvd1/repodata/*comps*.xml repodata/comps.xml

A continuación se instala el paquete createrepo y se genera de nuevo el xml:

[root@foreman centos6.5]# yum install createrepo
[root@foreman centos6.5]# createrepo -g repodata/comps.xml .
Spawning worker 0 with 6367 pkgs
Workers Finished
Gathering worker results

Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

Lo ultimo que debemos hacer es habilitar el acceso, en este caso habilito el acceso anónimo por ftp. Instalaré el servidor vsftpd y configuraré el directorio donde he ubicado el repositorio como público:

[root@foreman centos6.5]# yum install vsftpd
[root@foreman pub]# service vsftpd start
Starting vsftpd for vsftpd: [ OK ]
[root@foreman ~]# vi /etc/vsftpd/vsftpd.conf
anon_root=/opt/jgp/repo #public directory
[root@foreman bin]# service vsftpd start
Starting vsftpd for vsftpd: [ OK ]
[root@foreman bin]# chkconfig vsftpd on

Plantilla del Sistema Operativo

Se deberá crear una plantilla para el despliegue de los sistemas. Será necesario especificar una tabla de partición. En principio se puede  utilizar la que viene por defecto, pero también podemos crear una y adaptarla a nuestras necesidades. Yo voy a instalar los servidores físicos que disponen de mas de un disco de la siguiente forma:

  1. Mirror de la partición 1 de cada disco de un tamaño de 25 gigas para /.
  2. Mirror de la partición 2 de cada disco de un tamaño de 2 gigas para swap.
  3. Stripe con LVM de lo que queda de disco y se utilizará para datos.

En Foreman accederemos a partition tables y crearemos la nuestra según estos criterios:

El contenido del layout será el siguiente:

zerombr

clearpart –all –initlabel –drives=sda,sdb

part raid.008001 –asprimary –ondrive=sda –size=25000
part raid.008002 –asprimary –ondrive=sda –size=2048
part pv.008003 –asprimary –ondrive=sda –grow –size=25000

part raid.008011 –asprimary –ondrive=sdb –size=25000
part raid.008012 –asprimary –ondrive=sdb –size=2048
part pv.008013 –asprimary –ondrive=sdb –grow –size=25000

raid / –fstype=ext4 –level=1 –device=md0 raid.008001 raid.008011
raid swap –level=1 –device=md1 raid.008002 raid.008012
volgroup vg_data –pesize=4096 pv.008003 pv.008013
logvol /opt/jgp –fstype=xfs –name=jgp –vgname=vg_data –grow –size=100

Una vez configurado el particionado que utilizarán nuestros sistemas pasamos a configurar el origen del software para nuestra instalación, que apuntará al repositorio que hemos creado anteriormente. En installation media crearemos una plantilla nueva:

​Ya por último crearemos la plantilla del sistema operativo que queremos desplegar. Para ello iremos a operating systems y allí crearemos uno nuevo, o modificaremos el que viene por defecto. En la primera pestaña únicamente hay que darle un nombre y seleccionar la arquitectura sobre la que se puede aplicar esta plantilla:

En la siguiente pestaña se selecciona la tabla de partición que hemos creado anteriormente.

En installation media seleccionamos el mirror que también hemos creado antes:

En los templates en principio no hace falta modificar nada, aunque se podrían haber modificado para especificar configuraciones concretas, como el software que se debe instalar en cada servidor o configurar el proxy para las actualizaciones a través de YUM.

La última pestaña es la de parámetros. En mi caso añado la zona horaria que deberán tener mis servidores, aunque también se podría especificar en el provisioning template.

Una vez hemos terminado con esta plantilla ya estamos en disposición de empezar a desplegar sistemas automáticamente con solo unos clicks. En los próximos posts añadiré algunos ejemplos.

Anuncios

Openstack: Prueba de concepto – Parte 2

En relación a la entrada anterior, he querido mostrar una demostración en un vídeo en YouTube. El vídeo esta grabado sobre la prueba de concepto que monté. En el siguiente gráfico se puede ver la arquitectura:


Existen cuatro nodos de computación, y uno de ellos además, lleva el resto de elementos de Openstack. Todo está funcionando sobre Ubuntu 12.04 y montado con servidores con una única interfaz física.

Para las instancias he descargado las imágenes UEC que ya tiene preparadas Canonical.

El vídeo se podría dividir en dos partes. En la primera parte se muestran los principales comandos para trabajar con imagenes, “flavors”, arrancar instancias y terminarlas.

A continuación se hace un repaso por la Dashboard viendo como es sumamente sencillo la creación y despliegue de nuevas instancias. También he aprovechado para trabajar con volúmenes y demostrando que se pueden mover de una instancia a otra manteniendo la información que contienen.

Aquí se puede ver el vídeo:

OpenStack: Prueba de concepto – Parte 1

Estos días he tenido la opción de montar una pequeña prueba de concepto sobre Openstack. La idea es ver como funciona y analizar si en un futuro se podría implementar en un entorno productivo.

Me he basado en la documentación de Cloud – IES Gonzalo Nazareno concretamente en el documento bk-admin-openstack.pdf. También he seguido el libro de “recetas”: OpenStack Cloud Computing Cookbook.

Lo que he montado es básicamente una arquitectura de cuatro nodos. Uno de ellos es el Cloud Controller, donde estará todo el software necesario de Openstack: nova-compute, nova-network, nova-volume, glance y keystone. En los otros tres nodos únicamente se ha instalado el modulo de computación, nova-compute.

El hipervisor elegido para las pruebas ha sido KVM, con la idea de poder tener imagenes de otros sistemas operativos, además de imágenes de distribuciones GNU/Linux.

El esquema lógico sería el siguiente:

Por ciertas limitaciones únicamente he podido disponer de una interfaz de red cableada, por ello he apostado por el diseño mas sencillo con FlatDHCP. Aún así, las instancias son capaces de verse entre si a pesar de correr en diferentes hosts.

Ficheros de configuración:
Tal y como se explica en la documentación, el único fichero que hay que ir tocando es el /etc/nova/nova.conf. Yo copié el que indica en el documento  bk-admin-openstack.pdf y lo adapté a mi entorno. Básicamente hay que cambiar la IP que aparece por cada servicio por la del nodo que yo utilizaba como controlador. El apartado que me dió mas problemas fue el de red. Hay que tener mucho cuidado con los segmentos que se definen para las redes privadas, ya que es posible que se den problemas de routing. El apartado de configuración de red quedó de la siguiente manera:

# NETWORK
network_manager=nova.network.manager.FlatDHCPManager
force_dhcp_release=True
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver
my_ip=X.X.3.91
public_interface=eth0
flat_network_bridge=br100
flat_interface=eth1
fixed_range=192.168.221.0/27
floating_range=192.168.221.32/27
routing_source_ip=X.X.3.91
start_guests_on_host_boot=true
resume_guests_state_on_host_boot=true
network_size=10
flat_network_dhcp_start=192.168.221.10
flat_injected=False
force_dhcp_release=True
root_helper=sudo nova-rootwrap

El fichero nova.conf será el mismo en todos los nodos, lo único que habrá que cambiar es la variable my_ip. También hay que tener en cuenta la configuración de la consola vnc para poder acceder desde la interfaz web:

# VNC
novnc_enabled=true
vnc_keymap=es
novncproxy_base_url=http://10.150.3.91:6080/vnc_auto.html
vncserver_proxyclient_address=10.150.3.92
vncserver_listen=10.150.3.92
vnc_console_proxy_url=http://10.150.3.91:6080

Aquí habrá que modificar las IPs en las variables vncserver_proxyclient_address y vncserver_listen. En las otras dos variables se dejará la IP del nodo donde se instala la Dashboard.

Como punto importante, ya en la configuración de Keystone, es necesario configurar las variables de entorno del usuario que vamos a autilizar para manejar los servicios de Nova. Para ello, en el fichero .bahsrc hay que introducir las siguientes líneas (en mi caso en el de root):

export SERVICE_ENDPOINT=”http://X.X.3.91:35357/v2.0″
export SERVICE_TOKEN=PASSWORD
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=PASSWORD
export OS_AUTH_URL=”http://X.X.3.91:5000/v2.0/”

Una vez con esto configurado ya podemos empezar a hacer pruebas con Openstack.

Problemas encontrados:
Hasta encontrar la configuración que funciona he tenido que ir jugando con los diferentes flags de los ficheros de configuración. Alguna vez, después de arrancar instancias, se han quedado en un estado inconsistente, siendo imposible el borrado de de las instancias de forma convencional. Para ello hay que conectarse a la base de datos y borrar los datos que hacen referencia a las instancias. Para hacerlo mas sencillo me monté un pequeño script en python que saca un listado de las instancias y permite borrar una o el borrado de todas. El script es el siguiente:

#!/usr/bin/python
#coding: iso-8859-15
import MySQLdb
import sys

db = MySQLdb.connect(host=’HOST’,user=’nova’, passwd=’PASSWORD’, db=’nova’)
cursor = db.cursor()
consulta = ‘select id, uuid from instances’
cursor.execute(consulta)
instances = cursor.fetchall()

for inst in instances:
    print “Instancia: %s UUID: %s” % (str(inst[0]), str(inst[1]))



if “–all” in sys.argv:
    print ‘Limpiando todas las instancias’
    cont = raw_input(‘¿Continuar? (s/n): ‘)
    if cont == ‘s’ or cont == ‘S’:
        for inst in instances:
            id=str(inst[0])
            print ‘Borrando instancia %s’ % id
            consulta = ‘delete from instance_info_caches where id=%s’ % id
            cursor.execute(consulta)
                        consulta = ‘delete from security_group_instance_association where id=%s’ % id
                        cursor.execute(consulta)
                        consulta = ‘delete from instances where id=%s’ % id
                        cursor.execute(consulta)
            db.commit()
        print ‘Todas las instancias borradas’
else:
    id = raw_input(‘Selecciona la instancia a borrar: ‘)
   
    for inst in instances:
        if str(inst[0]) == id:
            print “Se va a borrar la instancia %s con UUID %s” % (str(id), str(inst[1]))
            cont = raw_input(‘¿Continuar? (s/n): ‘)
            if cont == ‘s’ or cont == ‘S’:
                print ‘Borrando instancia %s’ % id
                consulta = ‘delete from instance_info_caches where id=%s’ % id
                cursor.execute(consulta)
                consulta = ‘delete from security_group_instance_association where id=%s’ % id
                cursor.execute(consulta)
                consulta = ‘delete from instances where id=%s’ % id
                cursor.execute(consulta)
                print ‘Ejecute “nova list | grep %s” para confirmar que se ha borrado la instancia’ % str(inst[1])
                db.commit()

En una ocasión no pude borrar la instancia con el script y era porque a la instancia le había asignado un volumen. Al borrar daba un error de clave referenciada en una tabla, con lo que tuve que borrar dicha entrada en la tabla que indicaba el error. Una vez limpiado se pudo borrar con el script.

Es importante, en caso de tener algún problema, revisar los logs. Allí encontraremos muchas pistas de que puede estar fallando y es muy probable que a alguien le haya pasado antes. Los logs de nova se encuentran en /var/logs/nova y los de KVM, no menos importantes, están en /var/logs/libvirt.

OpenStack: esto si es cloud!

Hace unos días me preguntaron si con Linux se puede virtualizar! LOL

Básicamente lo que querían era algo tipo vSphere pero barato (gratis) y con un buen performance. En GNU/Linux básicamente tenemos dos hipervisores a elegir: KVM y XEN. EL primero parece ser el elegido por Canonical o Red Hat entre otros por la integración con el Kernel de Linux. XEN por su lado esta mas ampliamente implementado en grandes infraestructuras como las de Amazon o Rackspace. Además, existe otra opción, la del uso de contenedores de Linux (LXC). No se trata de un modelo que haga uso de un hipervisor, sino que se comparte el Kernel y los recursos entre la máquina anfitriona y los huéspedes.

Viendo todas las posibilidades que existían me puse a investigar algo mas sobre algún tipo de software que permitiera una gestión mas amigable y sin la necesidad de andar todo el tiempo desde linea de comandos. Encontré varias opciones para montar clouds privadas, pero la que mas me llamó la atención fue Openstack.

Openstack es una suite de herramientas que permiten la creación de clouds privadas, públicas e híbridas. Empezó su desarrollo como un proyecto Open Source patrocinado por Rackspace y la NASA. Al tiempo la NASA abandona su desarrollo para centrarse mas en el uso como cliente, pero Rackspace continua con él y poco a poco empieza a recibir colaboraciones de muchas empresas (algunas de ellas algo conocidas: AMD, Intel, Caonical, Suse Linux, Red Hat, Cisco, Dell, HP, IBM, NEC, Yahoo!, etc hasta mas de 150).

Como principales ventajas del uso de Openstack frente a otras soluciones creo que se podrían destacar las siguientes:

  1. Se trata de un sistema abierto, un proyecto Open Source con licencia Apache 2.0. Quizás sea uno de los proyectos Open Source con un mayor crecimiento e implicación por parte de las grandes corporaciones
  2. Cuenta con una gran comunidad. Actualmente cerca de 6700 colaboradores de 87 paises. 
  3. Existe mucha información, principalmente en la Wiki del proyecto Openstack
  4. Elimina el “Vendor Locking”. El uso de Openstack no esta ligado a ningún fabricante ni proveedor de software. Se puede utilizar con diferentes hipervisores como KVM, XEN, HyperV o vSphere.
  5. Permite la federación de nubes, algo que puede ser interesante si se quiere tener una infraestructura híbrida.
  6. Como la mayoria de los desarrollos Open Source, tiene un compromiso hacia los estándares. 
  7. Existe gente que dice que es el “Linux of the cloud”, haciendo una analogía entre lo que es actualmente Linux y lo que quiere llegar a ser Openstack.

La arquitectura de Openstack es modular, pudiendo instalar todos ellos en un único host o por separado. Esto dependerá del tamaño y el objetivo de la cloud. Para entornos de pruebas lo normal es instalarlo todo en un único nodo.

Los componentes que forman la arquitectura son:

  1. Openstack Compute: Nova. Es el cerebro de la arquitectura y la que permite el control de la nube. Se debe instalar en cada nodo que vaya a formar parte del cloud.
  2. Openstack Object Storage: Swift. Es un sistema de almacenamiento escalable y altamente redundante.
  3. Openstack Image Service: Glance. Repositorio de imagenes y snapshots. Las imagenes sirven como plantillas para la generación de nuevos servidores
  4. Openstack Identity: Keystone. Proporciona un directorio central de usuarios y actua como principal sistema de autenticación.
  5. Openstack Dashboard: Horizon. Proporciona una interfaz gráfica a los usuarios.
  6. Openstack Networking: Quantum (aka nova-network). Se encarga de la gestión de las redes y las direcciones IP que se le asignarán a las instancias.
  7. Openstack Block Storage: Cinder (aka nova-volume). Proporciona un almacenamiento a nivel de bloque persistente. Además se encarga de la creación y el agregado de dichos volúmenes a las instancias.

 En el siguiente gráfico se puede ver la relación entre ellos:

Para hacer pruebas se puede seguir la guia que han desarrollado entre varios institutos: Cloud – IES Gonzalo Nazareno o utilizar una ISO con todo instalado. Tendremos dos opciones:

  1. StackOps Community Edition : CD instalable basado en Ubuntu de la empresa española StackOps para la preparación de entornos de test.        
  2. Ubuntu Cloud Live : Imagen Live con todo ya instalado. En el desktop puedes encontrar las instrucciones para arrancar.

Se puede encontrar mucha información en internet sobre el proyecto, aunque en español escasea. Existen 2 grupos de google, uno español y otro argentino, y recientemente he creado una comunidad en Google+ (espero que empiece a tener algo de vida!):

spain-openstack-user-group@googlegroups.com
openstack-argentina@googlegroups.com
 Comunidad OpenStack en Español

En próximas entradas iré comentando mis experiencias y las configuraciones que he ido probando.

Links de interes:
Página oficial del proyecto: http://www.openstack.org/
Cuenta de twitter oficial: https://twitter.com/OpenStack
Entrada en wikipedia: http://en.wikipedia.org/wiki/OpenStack
Ubuntu cloud: http://www.ubuntu.com/cloud/private-cloud/openstack
Rackspace: http://www.rackspace.com/cloud/openstack/
Proyecto cloud en educación: http://www.gonzalonazareno.org/cloud/