Francisco Sariego Rodríguez

Infraestructura virtual, automatizada y en alta disponibilidad de una plataforma integral para equipos de

desarrollo

Francisco José García Izquierdo

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2012-2013

Título

Autor/es

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013

publicaciones.unirioja.esE-mail: publicaciones@unirioja.es

Infraestructura virtual, automatizada y en alta disponibilidad de una plataforma integral para equipos de desarrollo, trabajo fin de grado

de Francisco Sariego Rodríguez, dirigido por Francisco José García Izquierdo (publicadopor la Universidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

TRABAJO FIN DE GRADO

Infraestructura virtual, automatizada y en alta

disponibilidad de una plataforma integral para equipos de desarrollo

Francisco Sariego Rodríguez

Tutor: Francisco José García Izquierdo

Universidad de La RiojaFacultad de Ciencias, Estudios Agroalimentarios e Informática

Logroño, Junio de 2013

Resumen

En este Trabajo Fin de Grado presento el análisis, diseño y construcción de una infraestructura de servicios destinada a usarse por un equipo de desarrollo de software. Para ello, he usado en exclusiva Software Libre.

He decidido que la infraestructura debe ofrecer a los usuarios un sistema de control de versiones, una herramienta de documentación, gestión de proyectos y seguimiento de in­cidencias y una herramienta de Integración Continua. He cubierto estas necesidades, res­pectivamente, con Git, Redmine y Jenkins. Asimismo, he añadido OpenLDAP para la gestión de usuarios y autenticación. He instalado estos servicios sobre máquinas vir­tuales con el sistema operativo Ubuntu Server 12.04 LTS y para soportarlos he tenido que instalar y configurar Apache, Tomcat y MySQL.

Para asegurar que los servicios estén disponibles, he diseñado una estrategia de alta disponibilidad para cada uno usando un cluster gestionado mediante Corosync y Pacemaker. En cada uno de los diseños he propuesto alternativas respe­tando siempre el principio de simplicidad. Para el almacenamiento compartido basado en ficheros he usado GlusterFS. También he creado un dispositivo de al­macenamiento virtual asociado a las máquinas virtuales que he usado para el al­macenamiento por compartido basado en bloque.

He gestionado las configuraciones de las máquinas y los servicios mediante Puppet, usando Geppeto como entorno de desarrollo sobre un repositorio Git. De esta for­ma he automatizado toda la configuración, consiguiendo que sea replicable a par­tir de una instalación limpia del sistema operativo.

Como plataforma de virtualización, he elegido VirtualBox gestionada mediante Vagrant. La combinación de ambas tecnologías me ha permitido automatizar la crea­ción y borrado de las máquinas virtuales. He creado una plantilla con la instalación bá­sica del sistema operativo para tal fin. La integración de Vagrant con Puppet me ha re­sultado muy importante para construir de forma iterativa la configuración de toda la infraestructura.

Tanto el análisis y diseño como el resultado de la fase de construcción pue­den servir a un equipo de administración de sistemas que tenga que proveer una infraestructura similar para desarrolladores software. Una vez desplegada, el equipo de desarrollo será el encargado de adaptar a sus necesidades los servicios ofreci­dos.

Palabras clave: automatización, alta disponibilidad, Vagrant, Puppet, Pacemaker, GlusterFS, Ubuntu Server.

3

Abstract

In this Final Degree Project I present the analysis, design and construction of a service infrastructure intended to be used by a software development team. To this aim, I have used Free Software exclusively.

I have decided that the infrastructure must provide users with a version control sys­tem, a tool for documentation, project management and issue tracking and continuous integration tool. I have covered these needs, respectively, with Git, Redmine and Jenkins. I have also added OpenLDAP for user management and authentication. I in­stalled these services on virtual machines with the operating system Ubuntu Server 12.04 LTS and, to run them, I have installed and configured Apache, Tomcat and MySQL.

To ensure that services are available, I have designed a high availability strate­gy for each of them using a cluster managed by Corosync and Pacemaker. In each of the designs I have proposed alternatives respecting the principle of simplici­ty. For shared storage based on files I have used GlusterFS. I have also created a virtual storage device associated with the virtual machines that I used for shared storage based on block.

I have managed the configurations of machines and services through Puppet, using Geppeto as a development environment on a Git repository. In this way, I have au­tomated all settings, getting them replicable from a clean operating system installa­tion.

As a virtualization platform, I have chosen VirtualBox managed by Vagrant. The combination of both technologies has allowed me to automate the creation and deletion of virtual machines. I have created a template with the basic installation of the operating system for this purpose. The Vagrant with Puppet integration has been very important to build iteratively the configuration of the entire infrastructure.

Both the analysis and design as the result of the construction phase can serve a systems management team who has to provide a similar infrastructure for software developers. Once deployed, the development team will be responsible for adapting the services offered to their needs.

Keywords: automation, high availability, Vagrant, Puppet, Pacemaker, GlusterFS, Ubuntu Server.

A quienes defienden y luchan para que, en beneficio de todos, el conocimiento sea Libre.

4

Índice de contenidoObjetivos..........................................................................................................7Análisis y Diseño.............................................................................................9

Sistema operativo...........................................................................................................9Servicios.......................................................................................................................10

OpenLDAP..............................................................................................................10Git............................................................................................................................10Redmine...................................................................................................................11Jenkins.....................................................................................................................12Apache.....................................................................................................................12

Alta disponibilidad.......................................................................................................12Software de gestión del cluster................................................................................14Diseño de alta disponibilidad del almacenamiento..................................................15Diseño de alta disponibilidad de MySQL................................................................18Diseño de alta disponibilidad de OpenLDAP..........................................................18Diseño de alta disponibilidad de Git.......................................................................19Diseño de alta disponibilidad de Redmine...............................................................20Diseño de alta disponibilidad de Jenkins.................................................................20

Automatización............................................................................................................21Virtualización...............................................................................................................22

Automatización en VirtualBox: Vagrant.................................................................22Diseño de la infraestructura virtual.........................................................................23

Construcción..................................................................................................25Creación de la instalación base y la box de Vagrant...................................................25

Empaquetado y distribución ...................................................................................26Configuración de la plataforma virtual con Vagrant...................................................27

Almacenamiento compartido...................................................................................27Definición de las máquinas virtuales........................................................................27Provisión de configuraciones....................................................................................29Control de la plataforma virtual..............................................................................30

Configuraciones generales con Puppet.........................................................................31Organización de las configuraciones.........................................................................31Distribución de ficheros...........................................................................................32Configuración de la red............................................................................................32Configuración de rsyslog..........................................................................................35Configuración de AppArmor....................................................................................35

Configuración básica del almacenamiento LVM..........................................................35Configuración inicial de Corosync y Pacemaker..........................................................37

5

Recursos y restricciones...........................................................................................38Primera configuración de Pacemaker.......................................................................39

Configuración de GlusterFS.........................................................................................40Instalación de los paquetes y configuración del servicio..........................................40Reconocimiento de los peers de GlusterFS..............................................................41Creación del volumen de réplica y montaje.............................................................42Configuración de Pacemaker para GlusterFS..........................................................43

Configuración inicial de MySQL..................................................................................44Configuración de Pacemaker para MySQL..............................................................45Configuración de AppArmor para MySQL..............................................................46

Configuración de Git....................................................................................................46Configuración de Pacemaker para Git.....................................................................48

Configuración inicial de Apache...................................................................................48Configuración de Pacemaker para Apache..............................................................49

Configuración de Redmine...........................................................................................49Configuración de MySQL para Redmine.................................................................50Configuración de Apache para Redmine..................................................................51Configuración de Pacemaker para Redmine............................................................52

Configuración de Tomcat.............................................................................................52Configuración de Apache para Tomcat...................................................................53

Configuración de Jenkins.............................................................................................54Configuración de Pacemaker para Jenkins..............................................................55

Configuración de OpenLDAP......................................................................................55Configuración TLS...................................................................................................56Replicación multi-maestro.......................................................................................57Configuración de Pacemaker para OpenLDAP.......................................................58

Pruebas..........................................................................................................59Conclusiones..................................................................................................61Bibliografía.....................................................................................................63Anexo: Vagrantfile.........................................................................................65Anexo: Configuración de Pacemaker.............................................................69Anexo: Planificación......................................................................................73

Objetivos......................................................................................................................73Análisis y diseño...........................................................................................................73Planificación.................................................................................................................73Construcción................................................................................................................73Memoria.......................................................................................................................74Defensa.........................................................................................................................74Reuniones.....................................................................................................................75

6

Objetivos

ObjetivosEl Trabajo Fin de Grado (en lo sucesivo, TFG) consistirá en el diseño y construc­

ción de una infraestructura de servicios que sirva como plataforma integral para un equipo de desarrollo de software.

Los servicios básicos que debe ofrecer una plataforma de este tipo son:

– Un servicio para la gestión de usuarios, roles y autenticación.

– Un sistema de control de versiones.

– Un servicio de gestión de proyectos.

– Un servicio de gestión de incidencias y errores.

– Un servicio simple de documentación.

– Una herramienta de Integración Continua.

Todos los servicios ofrecidos por la infraestructura deberán estar en alta dispo­nibilidad. Deberá evitarse, en la medida de lo posible, la existencia de puntos úni­cos de fallo. Los usuarios tendrán la posibilidad de usar los servicios mediante protoco­los seguros.

La infraestructura estará construida sobre máquinas virtuales. En caso de ser ne­cesario, será posible la incorporación de hardware ajeno a las máquinas virtua­les como, por ejemplo, el almacenamiento compartido.

Todas las configuraciones e instalaciones de software estarán bajo un sistema de gestión de configuraciones y automatización. De este modo podrán ser aplica­das a máquinas con una instalación básica y “limpia”. Las configuraciones estarán bajo un sistema de control de versiones y servirán por sí mismas como documenta­ción.

Se emplearán en exclusiva “recursos libres”. Esto implica usar únicamente Software Libre tanto para la propia infraestructura y sus servicios, como para realizar la documentación y el resto de labores asociadas al TFG. También serán libres las tipo­grafías y cualquier otro tipo de recurso, como, por ejemplo, los gráficos. Todos los formatos de archivo usados serán estándares internacionales reconocidos y li­bres.

El TFG se ceñirá únicamente al diseño de la infraestructura y la adminis­tración de sistemas, quedando fuera del alcance la creación de ejemplos complejos de proyectos software que puedan ser susceptibles del aprovechamiento de la plataforma.

7

8

Análisis y Diseño

Análisis y DiseñoEn este capítulo explico las decisiones que he tomado para la consecución de los obje­

tivos planteados.

Los objetivos implican la creación de una infraestructura de servidores dentro de un mismo dominio. He elegido “tfg.org” como nombre de dominio en el que desplegar los servicios y máquinas.

He identificado 5 puntos clave de análisis y diseño: sistema operativo, servi­cios, alta disponibilidad, automatización y virtualización.

A continuación desarrollo cada uno de estos puntos por separado.

Sistema operativoEl sistema operativo que he elegido para los servidores es Ubuntu Server 12.04 64

bits. Este sistema operativo GNU/Linux está especialmente indicado para montar in­fraestructuras virtuales en entornos de producción ya que provee software actualizado pero lo suficientemente probado y estable.

La versión 12.04 proporciona soporte durante 5 años, prolongándose hasta Abril de 2017. Este soporte no sólo se reduce a las actualizaciones de seguridad que el equipo de Canonical lance, sino que también dará la posibilidad de actualizar los núcleos Linux según sean empaquetados en las siguientes versiones de Ubuntu (12.10, 13.04, 13.10...). Esto permite añadir en un futuro componentes que sólo estén soportados por nuevas versiones de Linux.

La instalación inicial será la mínima posible, evitando el consumo de recursos inne­cesarios de microprocesador, memoria y almacenamiento. Esta política evita las actuali­zaciones de paquetes no necesarios y disminuye los posibles riesgos de vulnerabilidades de seguridad.

Los sistemas de almacenamiento usarán LVM (Logical Volume Manager). Este sistema permite, entre otras cosas, añadir dispositivos físicos de almacenamiento para añadir más capacidad sobre las particiones existentes sin necesidad de desmontaje o pa­radas de servicio. Otra característica interesante de LVM es la posibilidad de realizar instantáneas (“snapshots”) sobre los sistemas de almacenamiento que pueden ser aprove­chadas, por ejemplo, para realizar copias de seguridad.

Las características de la instalación serán estas:

• Idioma: Español (“Castellano”).

9

Análisis y Diseño

• Configuración de teclado: Español

• Localización: España.

• Zona horaria: Europe/Madrid.

• Método de particionado: “Guiado – utilizar el disco completo y configurar LVM” utilizando todo el volumen para el particionado guiado.

• Instalaciones adicionales: servidor OpenSSH.

• Proxy para el gestor de paquetes: ninguno.

• Actualizaciones automáticas: no.

ServiciosA continuación describo el software necesario a instalar y configurar en los servidores

para poder ofrecer los servicios básicos enumerados en los objetivos.

OpenLDAPEl servicio para la gestión de usuarios, roles y autenticación que he elegido es

OpenLDAP que es una implementación del protocolo LDAP (Lightweight Directory Access Protocol). Se distribuye con la licencia libre OpenLDAP Public License.

En Ubuntu Server, el servidor OpenLDAP tiene el nombre slapd. Es capaz de ofrecer acceso mediante el protocolo TLS (Transport Layer Security), para lo que son necesa­rios los certificados de una CA (Certificate Authority).

GitComo sistema para el control de versiones he elegido Git. En la actualidad es el

sistema de control de versiones distribuido con más usuarios. Git se distribuye con la li­cencia libre GNU General Public License version 2.

Debido a que Git es un sistema distribuido, cada desarrollador mantiene una copia de todo el repositorio y el servidor le sirve como método para la comunicación de los cambios tanto propios como ajenos que previamente han sido consolidados en los re­positorios locales.

Git no es en sí un servicio que deba ejecutarse en un servidor para dar acce­so a sus clientes, sino que se basa en una estructura de directorios que es servida me­diante servicios externos. En el servidor debe existir un repositorio remoto que es gene­ralmente llamado “bare”. Esto quiere decir que no tiene un directorio de trabajo y que se usa sólo como punto de colaboración entre los desarrolladores.

10

Análisis y Diseño

Para el acceso remoto existen 3 protocolos definidos: protocolo Git, SSH (Secure Shell) y HTTP (Hypertext Transfer Protocol). El protocolo Git es el más rápido pero carece de autenticación, por lo que no es viable en este caso. SSH ofrece un buen rendi­miento, pero carece de la posibilidad de ofrecer acceso anónimo. HTTP es el sistema más simple de los tres para el acceso de sólo lectura, pero es complejo si se quiere confi­gurar para soportar modificaciones además de ser el que peor rendimiento ofrece.

He decidido que el protocolo que mejor se adapta a la consecución de los objetivos es el SSH. Para ello es necesario tener un servidor SSH, que es uno de los servicios más comunes y robustos en el mundo GNU/Linux. El método de autenticación para los usuarios será en este caso mediante el intercambio de claves pública y privada usando el usuario git dado de alta en las máquinas locales de forma que quede restringido al má­ximo sus privilegios.

RedmineRedmine es una aplicación web que sirve para la gestión de proyectos, el segui­

miento de incidencias y el de errores. También puede usarse como un sistema de documentación simple ya que incluye un editor wiki.

Otra de sus características fundamentales es la posibilidad de la integración con di­ferentes sistemas de control de versiones, como por ejemplo Git. También es posible configurar la autenticación mediante LDAP. Es una aplicación extensible que tiene multitud de aplicaciones añadidas (“plugins”).

Está desarrollada en Ruby y usa el framework Ruby on Rails, por lo que es necesa­ria la instalación de los paquetes correspondientes a sus librerías de ejecución. También es necesaria la instalación del componente RubyGems, que es un gestor de pa­quetes de software desarrollado en Ruby.

Básicamente existen dos maneras de ejecutar Redmine: con WebBrick y con Phusion Passenger. WebBrick es un servidor HTTP simple desarrollado en Ruby. Suele usarse en entornos con poca carga de trabajo. Por el contrario, Phusion Passenger es un módulo que puede instalarse en Apache HTTP Server (en lo sucesivo Apache) y que es el modo recomendado para el despliegue de aplicaciones programadas en Ruby on Rails.

He elegido Phusion Passenger debido a que es el método recomendado por los propios desarrolladores de Ruby on Rails. De este modo añado el servicio Apache a la infraestructura como encargado de servir la aplicación Redmine. Más adelante explico más en detalle en qué consistirá el servicio dado por Apache. Phusion Passenger se dis­tribuye con la licencia libre MIT License.

11

Análisis y Diseño

Por último, Redmine necesita un sistema gestor de bases de datos relacional. De entre los disponibles he elegido MySQL debido a mi anterior experiencia con él. MySQL se distribuye con la licencia libre GNU General Public License version 2.

JenkinsJenkins es una aplicación web que sirve como herramienta de integración conti­

nua.

Al igual que Redmine, puede integrarse con Git y configurar la autenticación mediante LDAP. También dispone de multitud de aplicaciones añadidas.

Jenkins está desarrollado en Java, por lo que puede desplegarse en varios contene­dores web como Jetty, GlassFish, JBoss Application Server o Apache Tomcat. A pesar de que estos contenedores son capaces de servir HTTP, suele ser mejor idea utilizar un servidor web específico como Apache al frente de los mismos.

En este caso he elegido el contenedor Apache Tomcat (en lo sucesivo Tomcat) debido a mis conocimientos previos de este contenedor de aplicaciones. Tomcat se distribuye con la licencia libre Apache License 2.0.

Jenkins guarda sus configuraciones en un directorio comúnmente conocido como JENKINS_HOME, por lo que no es necesario la instalación de ningún sistema gestor de bases de datos adicional.

ApacheEl servicio Apache sirve como puerta de entrada al usuario a las aplicaciones Redmine

y Jenkins. Además es capaz de descargar a los servidores de aplicaciones de tareas como, por ejemplo, la gestión de la conexión SSL/TLS y la compresión de las respuestas HTTP.

En el caso de Redmine, se configurará un virtual host con el nombre redmine.tfg.org y con el módulo Phusion Passenger que ejecute la aplicación.

Para Jenkins, Apache actuará como proxy inverso mediante el módulo mod_jk y se comunicará con Tomcat mediante el protocolo AJP. Tendrá configurado un virtual host con el nombre jenkins.tfg.org. Esta configuración permite un nivel adicional de seguridad al aislar el servidor de aplicaciones del usuario.

Alta disponibilidadUno de los objetivos principales es dotar a todos los servicios de la infraestructura

de alta disponibilidad evitando los puntos únicos de fallo. Para ello he pensado

12

Análisis y Diseño

en el diseño de un cluster simétrico de 3 nodos (servidores).

Que el cluster sea simétrico implica que los servidores son iguales y que, por tan­to, todos ellos pueden ejecutar cualquiera de los servicios y recursos. Este diseño permite una mejor consolidación frente a otros cluster no simétricos que son más pro­pensos al crecimiento del número de servidores para ser capaces de proporcionar la alta disponibilidad de todos sus servicios.

Para entender la elección del número de 3 nodos, hay que tener en cuenta que un cluster se divide en uno o más “subcluster”, también llamados particiones. Cada nodo tiene una visión a nivel partición y sólo reconoce a los miembros de la misma. El estado deseable es que sólo exista una partición dentro del cluster, aunque, por ejemplo, fallos en las comunicaciones, pueden hacer que existan varias particiones que no son conscientes de la existencia del resto.

Una condición así puede ser muy perjudicial para los sistemas, ya que existe la posi­bilidad de que se produzcan fallos irrecuperables derivados de la ejecución simultánea de servicios en diferentes particiones del cluster. Esta situación también es conocida como “split-brain” y es un problema de especial relevancia en arquitecturas con almacenamiento compartido así como en la asignación de direcciones IP como recur­sos.

Una técnica común para evitar estas situaciones, es el establecimiento del “quó­rum” o “acuerdo”. Una partición de un cluster tiene quórum si el número de nodos miembros de la partición es más de la mitad de los nodos del cluster. Se puede configu­rar una restricción que haga que en caso de no existir quórum en la partición, ninguno de los recursos del cluster sea ejecutado en sus nodos.

Para poder aplicar esta política es necesario un número mínimo de 3 nodos en el clus­ter, ya que con 2 nodos, cualquier partición que no fuera el cluster completo, no tendría quórum. En el caso de 3 nodos estas serían las posibles particiones:

• 1 partición de 3 nodos: quórum completo. Todos los nodos serían susceptibles de ejecutar recursos del cluster.

• 2 particiones, una de 2 nodos y una de 1 nodo: existiría quórum en la de 2 nodos y no en la de 1 nodo. Sólo se podrían ejecutar recursos del cluster en la partición de 2 nodos.

• 3 particiones de un nodo cada una: no existiría quórum en ninguna de las particiones. Todos los recursos del cluster estarían detenidos.

Los nodos del cluster tendrán los siguientes nombres y direcciones de red en eth1 :

13

Análisis y Diseño

• nodo01: con la dirección 192.168.2.11/24.

• nodo02: con la dirección 192.168.2.12/24.

• nodo03: con la dirección 192.168.2.13/24.

Software de gestión del clusterEn un cluster es necesario que exista un coordinador entre los nodos que tome las de­

cisiones, mantenga la disponibilidad marcada en la configuración y sea el encargado de la monitorización de las máquinas y servicios. He decidido utilizar Corosync y Pace­maker para esta labor. A este software también se le suele llamar “pila del cluster”.

Corosync es un software de comunicación por red entre grupos para la imple­mentación de estrategias de alta disponibilidad. Entre otras cosas, provee de una base de datos en memoria y un sistema de control de quórum. La comunicación entre nodos puede realizarse mediante multicast y cifrar el tráfico con AES256/SHA-1 con una clave previamente compartida.

Para la comunicación entre los nodos de un cluster, es común utilizar una red ais­lada del resto de redes de la organización y en la que sólo se encuentran los servidores del mismo. Este diseño permite el aislamiento de los múltiples mensajes que los nodos necesitan para coordinarse, liberando al resto de la red de este tráfico. También permite mayor seguridad ya que es posible que servicios que no sea necesario ofrecer fuera del cluster, se ofrezcan únicamente en esta red.

La red interna que he diseñado tiene las siguientes características:

• Estará conectada a las interfaces eth2 de cada nodo.

• Dirección de la red: 192.168.250.0/24.

• Dirección del nodo01: 192.168.250.11.

• Dirección del nodo02: 192.168.250.12.

• Dirección del nodo03: 192.168.250.13.

Pacemaker es el gestor de los recursos del cluster. Es el encargado de determi­nar en qué nodos se ejecutarán los servicios y según qué configuración y políticas. Tam­bién se encarga de la monitorización tanto de los nodos como de los recursos para deter­minar qué están siendo ejecutados de forma correcta y asegurar su disponibilidad.

Pacemaker es capaz de considerar recursos de un cluster a distintos tipos de entidades. Son susceptibles de ser recursos de un cluster, por ejemplo, un servicio de la máquina, la definición de una IP en una interfaz de red, el montaje de un grupo de volú­menes LVM, el montaje de una partición en una ruta indicada...

14

Análisis y Diseño

También brinda la posibilidad de crear relaciones entre los recursos y los nodos permitiendo, entre otras cosas, la agrupación de recursos en un mismo nodo, marcar el orden de arranque y parada o la dependencia entre recursos.

Existen tres arquitecturas básicas de ejecutar recursos con Pacemaker:

• Activo/Pasivo: el recurso sólo puede ejecutarse de manera simultánea en uno de los nodos del cluster. En caso de caída del nodo en el que se está ejecutando el recurso, pasa a ejecutarse en otro nodo.

• Activo/Activo: el recurso puede ejecutarse de manera simultánea en más de un nodo del cluster. Generalmente será en todos.

• Maestro/Esclavo: el recurso puede ejecutarse de manera simultánea en más de un nodo del cluster, aunque el rol con el que se ejecuta es distinto. Por ejemplo, puede definirse un recurso para la base de datos que en un nodo se ejecute con rol Maestro y sobre el que se puedan hacer escrituras y lecturas y en otros se eje­cute en rol Esclavo y que sólo permita lecturas.

En el TFG sólo usaré las dos primeras.

Diseño de alta disponibilidad del almacenamientoAunque el almacenamiento no es en sí un servicio marcado como objetivo del TFG, es

necesario considerarlo aparte, ya que es la base de la mayoría de sus servicios. También porque es especialmente complejo y sensible a los problemas inherentes a los cluster.

En este cluster he identificado dos tipos de almacenamiento compartido: el basado en ficheros y el basado en bloques.

Almacenamiento compartido basado en ficherosPara definir la estrategia del almacenamiento compartido basado en ficheros he

decidido usar GlusterFS. Es un sistema de archivos distribuido basado en la ar­quitectura cliente/servidor. Los servidores se agrupan en “bricks” y cada uno ejecu­ta un servicio glusterfs-server exportando un sistema de ficheros local como un volumen. Los clientes ejecutan un servicio glusterfs que se conecta a los servido­res mediante un protocolo propio y a través del cual son capaces de montar los volú­menes de los servidores a través de FUSE (Filesystem in Userspace).

Esta arquitectura permite crear volúmenes que a nivel de servidor pueden estar repli­cados, segmentados (“striping”), o tolerantes a fallos (“fail-over”).

15

Análisis y Diseño

GlusterFS dispone de herramientas propias para la configuración de sus pará­metros y no se realiza mediante Corosync y Pacemaker. Sin embargo el arranque de los servicios, el montaje de las particiones a nivel usuario, el orden de arranque y las depen­dencias sí que pueden gestionarse a través de la pila del cluster.

En este caso he identificado que los servicios Git y Jenkins tienen la necesidad de almacenamiento en sistemas de ficheros y que, al ser un cluster simétrico, estos sistemas de ficheros deben estar disponibles en caso de ejecución de alguno de esos servi­cios.

Con estos requisitos, el diseño propuesto para el almacenamiento es el siguiente:

• Todos los nodos ejecutarán el servicio glusterfs-server . Todos los pa­sos siguientes deben realizarse en todos los nodos.

• Existirá un dispositivo de almacenamiento en bloques dedicado al almace­namiento compartido basado en ficheros. Este dispositivo estará alojado en /dev/sdb.

• El dispositivo de bloques tendrá una única partición LVM que ocupe el total de su capacidad y sobre la que se creará el “physical volume”. Sobre esa parti­ción se creará un “volume group” llamado VGGlusterFS y un “logical volume” llamado LVGlusterFS que ocupen todo su espacio.

• LVGlusterFS estará formateado en XFS con sus valores por defecto. XFS es el sistema de ficheros recomendado sobre el que crear volúmenes de GlusterFS.

• El montaje de la partición XFS se realizará en la ruta /export/glusterfs con sus valores por defecto.

• Se creará un volumen en GlusterFS llamado VolumeGlusterFS en modo ré­plica entre los 3 nodos.

• VolumeGlusterFS se montará simultáneamente en todos los nodos con el sistema de archivos glusterfs. Arquitectura Activo/Activo. Cada nodo usará el servidor local de GlusterFS.

• La ruta de montaje será /mnt/GlusterFS .

Almacenamiento compartido basado en bloqueEl almacenamiento compartido basado en ficheros no es siempre una opción viable.

Por ejemplo, en el ámbito de las bases de datos relacionales, no es práctico ni eficiente. Debido al uso especial que hacen del almacenamiento los sistemas gestores de bases de datos, un escenario de replicación con GlusterFS podría llevar a un consumo excesivo de recursos o a una pérdida considerable de rendimiento. Por ello es necesario buscar una

16

Análisis y Diseño

estrategia distinta a más bajo nivel que el sistema de ficheros: el dispositivo de bloques.

Existen varios proyectos que serían apropiados para estos fines como Ceph Block Storage o DRBD (Distributed Replicated Block Device), que se encargan de presentar dispositivos de almacenamiento por bloques a partir de almacenamiento local de los no­dos del cluster. Estos nuevos dispositivos “virtuales” estarían compartidos y replicados a partir de los recursos locales de los nodos.

Inicialmente pensé en utilizar Ceph Block Storage, pero quedó descartado debido a que requiere una infraestructura mayor que la propuesta. Por otro lado, DRBD es una solución óptima para cluster de 2 nodos, pero no se adecúa como solución para arquitec­turas simétricas de 3 nodos. La versión 9 de DRBD, que ahora mismo se encuentra en fase Beta, sí que permitirá un despliegue homogéneo en más de dos nodos y será la solución ideal en este escenario.

Finalmente, he optado por utilizar un dispositivo de almacenamiento por blo­ques compartido entre los nodos. Esta decisión introduce una dependencia exter­na a las máquinas virtuales, ya que es la plataforma de virtualización la que se tiene que encargar de asociar de forma explícita el dispositivo a los servidores.

Sobre este dispositivo se pueden montar sistemas de ficheros de cluster, como por ejemplo OCFS2 (Oracle Cluster File System), de forma que todos los nodos tuvieran la capacidad de leer y escribir al mismo tiempo sobre el mismo. Por el contrario, estos sis­temas de ficheros son complejos de instalar y administrar.

Teniendo en cuenta que el único servicio que hará uso del almacenamiento comparti­do por bloques será el sistema gestor de bases de datos MySQL, siguiendo el principio de simplicidad, la solución propuesta es la siguiente:

• Existirá un dispositivo de almacenamiento en bloques para el almacena­miento compartido basado en bloques asociado a todos los nodos. Este dispositivo estará alojado en /dev/sdc.

• El dispositivo de bloques tendrá una única partición LVM que ocupe el total de su capacidad y sobre la que se creará el “physical volume”. Sobre esa parti­ción se creará un “volume group” llamado VGCompartidoBloques y un “logical volume” llamado LVCompartidoBloques que ocupen todo su espa­cio.

• LVCompartidoBloques estará formateado en EXT4 (fourth extended filesystem) con sus valores por defecto.

• LVCompartidoBloques no podrá montarse simultáneamente en más de un nodo. Arquitectura Activo/Pasivo.

17

Análisis y Diseño

• La ruta de montaje será /mnt/compartidobloques .

Diseño de alta disponibilidad de MySQLMySQL tampoco es uno de los servicios identificados como objetivo, aunque merece la

pena realizar un diseño pensando exclusivamente en él. MySQL ofrece dos solucio­nes enfocadas a la alta disponibilidad: MySQL Cluster y replicación.

MySQL Cluster es la solución que mejores resultados ofrece, pero también es la más compleja y costosa de cara a la administración y los recursos. Al igual que en el caso de Ceph Block Storage, la implantación de una solución MySQL Cluster es en sí ma­yor que toda la solución propuesta, y por tanto no es viable.

La solución basada en la replicación se basa en la propagación de los cambios reali­zados en uno de los nodos, considerado como “maestro”, al resto de nodos, llamados “es­clavos”. Esta configuración se puede gestionar con Pacemaker, que es capaz de conmu­tar los roles maestro y esclavo en caso de caídas. Sin embargo, mi experiencia ante­rior con este escenario nunca ha sido buena debido a la incapacidad de hacerlo funcionar de manera estable. Por eso he decidido descartar esta opción.

Finalmente he decidido realizar una solución en arquitectura Activo/Pasivo que esté alineada con los recursos del almacenamiento compartido en bloques. El servicio se ofrecerá mediante una IP virtual asociada a la red interna del cluster. Los de­talles de la solución son los siguientes:

• El servicio mysql se ejecutará sólo en uno de los nodos de forma simultá­nea. Arquitectura Activo/Pasivo.

• Todos los recursos necesarios para el montaje del almacenamiento compar­tido en bloque del el montaje en /mnt/compartido correrán en la misma má­quina que el servicio mysql .

• Los ficheros de datos de MySQL estarán alojados en /mnt/compartido/mysql .

• MySQL ofrecerá el servicio a través de la IP virtual 192.168.250.140 en la in­terfaz de red de intracluster eth2.

• El orden de arranque será: recursos del almacenamiento compartido, IP virtual y servicio mysql.

Diseño de alta disponibilidad de OpenLDAPEl diseño de alta disponibilidad de OpenLDAP lo he basado en una arquitectu­

ra híbrida. El servicio sólo estará disponible a través de un único nodo median­

18

Análisis y Diseño

te una IP virtual, que será la que usen los clientes. Desde este punto de vista el dise­ño es Activo/Pasivo. Sin embargo, el servicio slapd estará corriendo en todos los nodos a la vez con una configuración que replicará los cambios realizados al resto de nodos. Este tipo de arquitectura es Activo/Activo. La mezcla de ambos aspectos es lo que confiere una arquitectura híbrida.

La configuración de replicación de cambios es una característica específica de OpenLDAP y en este caso he decidido hacerla en modo “multi-maestro” (“multi-master”), de forma que cualquiera de los nodos puede ser susceptible de lecturas y modificaciones. Esta decisión hace innecesario el uso de almacenamiento compartido para guardar el árbol LDAP y permite que sólo con mover IP virtual asignada a OpenLDAP el servicio pase a ofrecerse en otro nodo.

Los detalles del diseño son los siguientes:

• El servicio slapd se ejecutará en todos los nodos de forma simultánea en una configuración multi-maestro.

• slapd ofrecerá el servicio a través de la IP virtual 192.168.2.150 en la interfaz de red eth1.

• El orden de arranque será: slapd e IP virtual.

Diseño de alta disponibilidad de GitEl diseño de alta disponibilidad de Git está basado en la alta disponibilidad de

GlusterFS.

El servicio SSH presenta el servicio a los clientes y la partición montada sobre GlusterFS guarda el directorio con el repositorio de Git. El servicio SSH no esta­rá definido como un recurso del cluster, ya que es un servicio básico de las máquinas GNU/Linux y tiene que estar ejecutándose independientemente del estado del mismo.

La arquitectura de almacenamiento compartido por fichero es Activo/Activo, por lo que el repositorio remoto de Git estará disponible de forma local en los 3 nodos. Sin em­bargo, he decidido usar una arquitectura Activo/Pasivo de cara al cliente definiendo una IP virtual que será la que usen los usuarios para acceder al repositorio. La IP vir­tual independizará el servicio Git del nodo en el que esta corriendo desde fuera del cluster.

Éstos son los detalles del diseño:

• La IP virtual estará definida sólo en uno de los nodos de forma simultá­nea. Arquitectura Activo/Pasivo.

• La IP virtual será la 192.168.2.110 en la interfaz de red eth1.

19

Análisis y Diseño

• Todos los recursos del almacenamiento compartido mediante fichero de­berán estar corriendo en la misma máquina que la IP virtual.

• El directorio con el repositorio bare estará alojado en /mnt/repositorio-remoto .

• El orden de arranque será: recursos del almacenamiento compartido e IP virtual.

Diseño de alta disponibilidad de RedmineEl diseño de alta disponibilidad de Redmine está basado en los servicios MySQL

y Apache. Ambos servicios están diseñados para ejecutarse con una arquitectura Ac­tivo/Pasivo y por tanto Redmine también tendrá esa arquitectura.

No existe la necesidad de que MySQL esté ejecutándose en el mismo nodo que Apache ya que al estar asociado con una IP de la red intracluster, todas las aplicaciones la usa­rán como punto de acceso a la base de datos.

Éstos son los detalles del diseño:

• El servicio Apache se ejecutará sólo en uno de los nodos de forma simultá­nea. Arquitectura Activo/Pasivo.

• El servicio mysql se ejecutará sólo en uno de los nodos de forma simultá­nea. Arquitectura Activo/Pasivo.

• El orden de arranque será: MySQL y Apache.

Diseño de alta disponibilidad de JenkinsEl diseño de alta disponibilidad de Jenkins lo he basado en una arquitectura Acti­

vo/Pasivo de forma que el servicio Tomcat en el que se ejecuta Jenkins se ejecute sólo en uno de los nodos.

Debido a que es indiferente en cual de los servidores se esté ejecutando, hay que dar una visión homogénea del servicio añadiendo una IP virtual definida en el mismo nodo. El alojamiento del directorio JENKINS_HOME se realizará dentro de la parti­ción habilitada para el alojamiento compartido mediante ficheros por la misma razón.

Apache actuará como proxy inverso al frente de Tomcat para ofrecer el acceso me­diante protocolo seguro.

En concreto, éstos son los detalles del diseño:

20

Análisis y Diseño

• El servicio tomcat se ejecutará sólo en uno de los nodos de forma simultá­nea. Arquitectura Activo/Pasivo.

• Todos los recursos del almacenamiento compartido mediante fichero de­berán estar corriendo en la misma máquina que el servicio tomcat .

• El directorio JENKINS_HOME estará alojado en /mnt/GlusterFS/jenkins_home .

• Tomcat prestará sus servicios a través de la IP virtual 192.168.250.120 en la interfaz de red eth2.

• El orden de arranque será: recursos del almacenamiento compartido, IP virtual y servicio tomcat .

AutomatizaciónPara la automatización de las configuraciones de los servidores he decidido usar Pup­

pet. Esta herramienta está diseñada para gestionar la configuración de forma de­clarativa convirtiendo las arquitecturas de servidores al concepto “código como infraes­tructura” (“infrastructure as code” o “IaC”). IaC es una de las características clave dentro del movimiento DevOps, que intenta unir la colaboración e integración entre los equipos de desarrollo de software y los administradores de sistemas.

Puppet está desarrollado en Ruby, por lo que es multiplataforma. Se distribuye con la licencia libre Apache License 2.0.

Con Puppet el administrador describe, mediante una capa de abstracción, los recursos del sistema y su estado usando un lenguaje propio. Es capaz, entre otras cosas, de instalar paquetes, crear carpetas, copiar archivos, gestionar sus permisos, arrancar y parar servicios, ejecutar comandos y gestionar usuarios. Puppet asegura que el sistema está en el estado descrito. Esta capa de abstracción se define mediante un len­guaje declarativo propio.

Puppet puede desplegarse mediante una arquitectura cliente-servidor o directamente sobre cliente. En este caso he elegido aplicar directamente las configuraciones sobre el cliente debido a la agilidad que proporciona para crear una nueva infraestruc­tura. Para ello, sólo es necesario que las configuraciones estén accesibles en la máquina y ejecutar un comando para que Puppet se encargue de aplicarlas. Esto contrasta con la idea de tener un servidor dedicado con las configuraciones, un repositorio Git y la confi­guración de los clientes, haciéndola muchísimo más simple. La arquitectura cliente-servidor está más enfocada al mantenimiento de infraestructuras en produc­ción y con varios administradores.

21

Análisis y Diseño

Las configuraciones estarán en un repositorio Git local gestionadas me­diante Geppeto. Geppeto es un entorno de desarrollo diseñado específicamente para la creación de configuraciones de Puppet. Es una modificación de Eclipse, por lo que se aprovecha de muchas de sus funcionalidades entre ellas EGit que es el cliente de Eclipse para Git. Geppeto se distribuye con la licencia libre Apache License 2.0.

VirtualizaciónToda la infraestructura de servidores estará virtualizada tal y como se especifica en

los objetivos. Para este fin he decidido usar VirtualBox Open Source Edition 4.2. (en adelante VirtualBox) Esta versión se distribuye con la licencia GNU General Version License 2.

VirtualBox dispone de todas las características necesarias descritas hasta el momento como la virtualización sobre 64 bits, la posibilidad de compartir un dispositivo de alma­cenamiento por bloques entre máquinas virtuales, la creación de una red dedicada con el anfitrión o la creación de redes aisladas para determinadas máquinas.

Automatización en VirtualBox: VagrantLa creación de una infraestructura como la propuesta no es algo que se consigue a la

primera. En la administración de sistemas, la instalación de una librería incorrecta o un fichero de configuración que haya quedado olvidado, puede decidir si toda la infraestruc­tura funciona o no. Por ello es necesario ser capaz de poder volver al estado ini­cial de las máquinas virtuales para aplicar de nuevo todas las configuracio­nes.

Si Puppet es el encargado de gestionar las configuraciones de los servidores, Vagrant se encarga de configurar y automatizar una infraestructura a nivel de máqui­nas virtuales a partir de plantillas.

Vagrant actúa como una capa de abstracción sobre VirtualBox permitiendo de una forma declarativa generar infraestructuras virtuales a partir de sencillas plantillas o box. Es capaz de invocar comandos VBoxManage, poniendo a disposición del usuario toda la funcionalidad de VirtualBox mediante una interfaz de comandos. Por tanto es capaz, entre otras cosas, de crear máquinas virtuales, apagarlas, encenderlas, añadirles discos, crearlos, borrarlos, gestionar sus redes, asignarles recursos...

Vagrant está desarrollado en Ruby y se distribuye con la licencia libre MIT.

Las box son máquinas virtuales con un sistema operativo instalado que han sido adap­tadas para poder ser gestionadas mediante Vagrant. El objetivo es que estas plantillas

22

Análisis y Diseño

sean lo más reducidas y genéricas posibles y que las configuraciones específicas de hardware virtual, redes y recursos se añadan al levantarlas con Vagrant. Una vez levan­tadas, aparecerán en VirtualBox como una máquina virtual normal.

A pesar de existir disponibles muchas box ya configuradas y optimizadas, he decidi­do crear una propia para asegurar que el sistema base tiene única y exactamente lo que necesito, además de tener el software totalmente actualizado.

En caso de querer borrar las máquinas virtuales, Vagrant también es el encargado, eli­minando todos los archivos asociados con ellas. De esta manera es más fácil tener una infraestructura limpia y también aplicar cambios globales a todas las máquinas.

Vagrant no sólo se limita a la gestión de VirtualBox, sino que es capaz de aplicar configuraciones de Puppet. Esta funcionalidad la realiza mediante la compartición de las carpetas con las configuraciones de Puppet de la máquina anfitrión a las máqui­nas virtuales mediante VirtualBox. Esta funcionalidad incrementa la agilidad a la hora de aplicar nuevos cambios en las configuraciones de la infraestructura, ya que con sólo un comando los cambios realizados se aplicarán en todas las máquinas.

Diseño de la infraestructura virtual

RedEn VirtualBox se creará una red de “sólo anfitrión” para que el ordenador anfi­

trión esté en la misma red que las máquinas virtuales. Las características de esta red se­rán las siguientes:

• Dirección IPv4: 192.168.2.0.

• Máscara de red IPv4: 255.255.255.0.

• Servidor DHCP: inhabilitado.

Almacenamiento compartidoSe creará un disco duro que se usará como medio para el almacenamiento compar­

tido por bloque. Las características de este disco duro serán las siguientes:

• Tamaño: 2 GB con almacenamiento de tipo fijo.

• Nombre: “compartido.vdi”.

• Tipo: compartible.

23

Análisis y Diseño

Máquinas virtualesUna vez arrancadas desde Vagrant, las tres máquinas virtuales que forman parte del

cluster tendrán estas características y recursos asignados:

• Nombres: “Nodo01”, “Nodo02” y “Nodo03”.

• Sistema operativo: GNU/Linux Ubuntu (64 bit).

• Memoria base: 2048 MB.

• Procesadores: 2 con aceleración VT-x/AMD-V y paginación anidada.

• Vídeo: 64 MB de memoria con aceleración 3D.

• Controlador de almacenamiento: SATA tipo AHCI con 8 puertos.

• Puerto SATA 0: disco duro de nombre “sistema.vdi” con tamaño virtual 8 GB en formato VDI y almacenamiento reservado dinámicamente.

• Puerto SATA 1: disco duro de nombre “gluster.vdi” con tamaño virtual 2 GB en formato VDI y almacenamiento reservado dinámicamente.

• Puerto SATA 2: disco duro de nombre “compartido.vdi” con tamaño virtual 2 GB en formato VDI y almacenamiento reservado dinámicamente.

• Puerto SATA 3: unidad CD/DVD.

• Adaptador 1 de Red: Intel PRO/1000 MT Server conectada a NAT.

• Adaptador 2 de Red: Intel PRO/1000 MT Server conectada a la red de sólo anfitrión “vboxnet0”.

• Adaptador 3 de Red: Intel PRO/1000 MT Server conectada la red interna de nombre “intracluster”.

• Servidor de escritorio remoto: inhabilitado.

• Puertos serie: inhabilitado.

• Audio: inhabilitado.

24

Construcción

ConstrucciónEn este capítulo explico qué pasos he seguido para conseguir los objetivos siguiendo

las pautas marcadas en el capítulo de análisis y diseño. También describo los problemas que he encontrado a lo largo del proceso de construcción así como las decisiones y solu­ciones que he tomado para solventarlos.

Creación de la instalación base y la box de VagrantLa creación de la box que sirva como plantilla para las máquinas virtuales de la plata­

forma se compone de dos aspectos: la configuración de una máquina virtual y la instalación de una distribución GNU/Linux.

He creado la máquina virtual, según las indicaciones descritas en el análisis y diseño, con el nombre “vagrant-precise”. La primera versión de VirtualBox que he utilizado es la 4.2.8. A lo largo del TFG, he actualizado a las versiones 4.2.10 y 4.2.12, lo que ha incrementado la estabilidad de la infraestructura.

Para la creación de la instalación base, he utilizado la versión 12.04.2 64 bit de Ubuntu Server que corresponde con la más actualizada de la serie 12.04 LTS.

He realizado la instalación por defecto usando LVM y añadiendo el servidor OpenSSH tal y como se indica en el análisis y diseño.

Una vez que ha terminado la instalación, he procedido con la actualización de los paquetes a través de los repositorios de Ubuntu. Esto asegura que la box creada tenga todos los los últimos paquetes, ya que las actualizaciones son continuas.

La creación de la box a partir de una máquina virtual instalada necesita de una serie de pasos. Las box creadas pueden distribuirse públicamente, por lo que se suelen seguir los mismos pasos para crear un criterio de “convención sobre configuración”. En mi caso he seguido los siguientes pasos:

1. He cambiado el nombre de host a vagrant .

2. He cambiado la contraseña del usuario root a vagrant .

3. He añadido el usuario vagrant con la contraseña vagrant .

4. He añadido el grupo de usuarios admin y he añadido el usuario vagrant al mismo.

5. He permitido que los usuarios que estén en el grupo admin puedan ejecutar cualquier comando como usuario root sin que le pida la contraseña. Ejecu­

25

Construcción

tado el comando visudo y he añadido la línea “%admin ALL=NOPASSWD: ALL“.

6. He modificado la variable env_keep con visudo poniéndole el valor “SSH_AUTH_SOCK”.

7. He instalado las VirtualBox Guest Additions. Para ello, he instalado el pa­quete linux-headers correspondientes con el kernel que esté instalado en el equi­po y el grupo de paquetes build-essential que tiene las utilidades necesarias para compilación. La instalación se realiza indicando en el menú de la máquina virtual “Dispositivos / Instalar 'Guest Additions'”. Esto carga en el dispositivo lector de CD-ROM una imagen virtual con las Guest Additions. Una vez monta­do el CD-ROM, he ejecutado el programa VboxLinuxAdditions.run que se en­cuentra dentro del mismo y que realiza la instalación.

8. He instalado Puppet. Para tener versión más actualizada, he instalado el repo­sitorio oficial de Puppet Labs para Ubuntu 12.04. La forma más sencilla es insta­lar el paquete “.deb” que añade el repositorio. Una vez actualizadas las fuentes del gestor de paquetes, he instalado el paquete puppet. Este paquete añade como dependencia, entre otros, las librerías de ejecución de Ruby.

9. He configurado autenticación SSH con una clave pública. Para ello me he descargado la clave pública de http://github.com/mitchellh/vagrant/raw/master/keys/vagrant.pub y la he movido a /home/vagrant/.ssh/authorized_keys. Esta clave permitirá el ac­ceso con el usuario vagrant desde cualquier instalación de Vagrant.

Empaquetado y distribución La versión que he utilizado de Vagrant es la 1.0.5. En el momento de la instalación

la versión más actualizada era la 1.0.6 pero al intentar instalarla no funcionaba debido a un problema de dependencias con la distribución de Ruby embebida con Vagrant. El error que mostraba era que necesitaba al menos la versión 2.14 de glibc mientras que Ubuntu 10.10, que es el sistema operativo de mi equipo de escrito­rio, dispone de la versión 2.12.1. Este error fue reportado en los foros de Vagrant y está marcado como resuelto, sin embargo he decidido no actualizar a nuevas versiones ya que considero la versión 1.0.5 estable y no necesito ninguna de sus nuevas funcionali­dades.

Para empaquetar y distribuir la box, hay que utilizar las utilidades de Vagrant en línea de comandos. Una vez apagada la máquina virtual, he ejecutado en mi má­quina de escritorio la siguiente instrucción:

vagrant package –base vagrant-precise

26

Construcción

Este comando genera un fichero llamado package.box que contiene la máqui­na virtual instalada con todas sus configuraciones.

El último paso es añadir este fichero empaquetado a la lista de box gestionadas por Vagrant mediante el comando:

vagrant box add vagrant-precise package.box

Una vez ejecutada esta instrucción, la box está preparada para poder usarse dentro del entorno Vagrant.

Configuración de la plataforma virtual con VagrantLa configuración con Vagrant de una plataforma virtual se realiza a través de un fi­

chero con sintaxis Ruby llamado Vagrantfile.

En mi caso existen tres aspectos fundamentales en el Vagrantfile: el almacena­miento compartido, la definición de las máquinas virtuales y la provisión de configuraciones.

Almacenamiento compartidoAl inicio del Vagrantfile, he configurado el disco duro de soporte al almacenamiento

compartido con la siguiente configuración:

config.vm.customize ["createhd", "--filename", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/compartido.vdi", "--size", "1024", "--format", "VDI", "--variant", "Fixed"] config.vm.customize ["modifyhd", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/compartido.vdi", "--type", "shareable"]

La primera línea se encarga de la creación de un disco duro en la ruta “/media/Hitachi Datos/twenty/GII/TFG/vagrant/compartido.vdi” de mi equipo de escritorio, dándole 1 GB de tamaño y el formato VDI. Por último, he indicado que sea almacenamiento de tamaño fijo estableciendo el valor fixed en el parámetro variant. Esto es importante ya que sólo los discos en este modo pueden ser compartidos entre va­rias máquinas virtuales.

La segunda línea modifica el disco duro para que sea de tipo compartible. Más adelante explico cómo he conectado este disco a cada una de las máquinas.

Definición de las máquinas virtualesPara cada una de las tres máquinas he hecho una configuración en la que se especifi­

can todas sus características. Ésta es la configuración para la máquina Nodo01:

27

Construcción

config.vm.define :Nodo01 do |nodo01| nodo01.vm.box = "vagrant-precise64" nodo01.vm.host_name = "nodo01.tfg.org" nodo01.vm.boot_mode = :gui nodo01.vm.customize ["modifyvm", :id, "--name", "Nodo01"] nodo01.vm.customize ["modifyvm", :id, "--ioapic", "on"] nodo01.vm.customize ["modifyvm", :id, "--cpus", 2] nodo01.vm.customize ["modifyvm", :id, "--memory", 2048] nodo01.vm.customize ["modifyvm", :id, "--nic1", "nat"] nodo01.vm.customize ["modifyvm", :id, "--nictype1", "82545EM"] nodo01.vm.customize ["modifyvm", :id, "--nic2", "hostonly"] nodo01.vm.customize ["modifyvm", :id, "--macaddress2", "08002758b131"] nodo01.vm.customize ["modifyvm", :id, "--nictype2","82545EM"] nodo01.vm.network :hostonly, "192.168.2.11", :netmask => "255.255.255.0", :adapter => 2 nodo01.vm.customize ["modifyvm", :id, "--nic3", "intnet"] nodo01.vm.customize ["modifyvm", :id, "--macaddress3", "08002725f8ea"] nodo01.vm.customize ["modifyvm", :id, "--nictype3", "82545EM"] nodo01.vm.customize ["modifyvm", :id, "--audio", "none"] nodo01.vm.customize ["modifyvm", :id, "--usb", "off"] nodo01.vm.customize ["modifyvm", :id, "--usbehci", "off"] # Disco para GlusterFS nodo01.vm.customize ["createhd", "--filename", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/Nodo01/gluster.vdi", "--size", "2048", "--format", "VDI", "--variant", "Standard"] nodo01.vm.customize ["storageattach", :id, "--storagectl", "SATA", "--port", "1", "--device", "0", "--type", "hdd", "--medium", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/Nodo01/gluster.vdi"] # Disco compartido config.vm.customize ["storageattach", :id, "--storagectl", "SATA", "--port", "2", "--device", "0", "--type", "hdd", "--medium", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/compartido.vdi"] end

La primera parte define que box usa, en este caso vagrant-precise, el nombre de host y el nombre de la máquina virtual dentro del entorno de VirtualBox.

He establecido el valor “:gui” para el parámetro boot_mode para que cada vez que se arranque la máquina virtual, VirtualBox abra una ventana con la consola. Esta configuración no suele ser habitual entre la comunidad Vagrant, ya que por defecto no se trabaja con la consola.

28

Construcción

En las siguientes líneas he configurado las características hardware que he decidido en el análisis y diseño.

He puesto explícitamente las direcciones MAC de las tarjetas de red para po­der identificar qué tarjeta corresponde con cada interfaz a nivel de sistema ope­rativo. He escogido estas direcciones MAC de entre las que ofrece aleatoriamente VirtualBox. En el caso de la interfaz NAT, no he necesitado cambiarla ya que VirtualBox considera a esta interfaz de un modo especial, y aunque tenga la misma di­rección MAC e IP que otras máquinas en la misma instancia de VirtualBox, no se pro­ducirá una colisión.

Vagrant permite asignar la dirección IP y la red a nivel de sistema opera­tivo de las interfaces hostonly . No ocurre lo mismo con las redes del tipo interna, por lo que más adelante muestro cómo he tenido que configurarlas usando Puppet.

En las siguientes líneas, he definido el disco duro que se usará como volumen exportado de GlusterFS. El nuevo disco duro se guarda la ruta “/media/Hitachi Datos/twenty/GII/TFG/vagrant/Nodo01/gluster.vdi”. A continuación conecto el dis­co duro al puerto 1 de la controladora SATA de la máquina usando storageattach.

Por último, hago lo mismo con el disco duro destinado al almacenamiento com­partido por bloque, conectándolo al puerto 2 de la controladora SATA.

La configuración para Nodo02 y Nodo03 es similar, cambiando sólo los valores que se muestran en cursiva.

Provisión de configuracionesLas configuraciones en Puppet, a un nivel muy básico, están divididas en dos concep­

tos: los manifiestos y los módulos.

Los manifiestos son los ficheros que describen las configuraciones. En una configuración con Puppet, lo normal es que exista un fichero llamado site.pp, que es el manifiesto general en el que se describen las configuraciones. Desde este manifiesto se puede hacer referencia a otros manifiestos, instanciar clases, usar definiciones o incluir módulos.

Los módulos están formados por manifiestos y por una estructura de direc­torios con ficheros. Estos ficheros generalmente son distribuidos o son plantillas de fi­cheros que son rellenadas y distribuidas. Es habitual que en un módulo exista el fichero init.pp, que es el manifiesto general. Los módulos están pensados para ser reutilizados en diferentes plataformas y proyectos. También es posible crear dependencias entre mó­dulos formando una configuración intermodular.

29

Construcción

La configuración de la provisión que he usado es la siguiente:

config.vm.provision :puppet, :module_path => "/media/Hitachi Datos/twenty/GII/TFG/workspace/configuraciones/modules", :options => "--verbose" do |puppet| puppet.manifests_path = "/media/Hitachi Datos/twenty/GII/TFG/workspace/configuraciones/manifests" puppet.manifest_file = "site.pp”end

En primer lugar, he establecido a Puppet como software para la provisión de configuraciones y puesto la ruta en la que se encuentran los módulos. Median­te la opción --verbose hago que Puppet muestre los detalles de la configuración que esté aplicando. En la siguiente línea establezco la ruta en la que se encuentran los manifiestos y en la última el nombre del manifiesto principal.

En el directorio “/media/Hitachi Datos/twenty/GII/TFG/workspace/configuraciones/” de mi equipo de escritorio he creado el repositorio de Git en donde están todos los ficheros correspondientes a las con­figuraciones. Para gestionarlo he creado un proyecto Puppet gestionado con Geppeto.

Por simplicidad, he trabajado siempre en la misma rama de Git a pesar de que lo más común es trabajar en distintas ramas. Cuando una configuración o una correc­ción estaba comprobada, he consolidado los cambios mediante un commit en el reposito­rio.

Control de la plataforma virtualEl control de la plataforma virtual se realiza mediante comandos vagrant. Para ello

hay que navegar con una terminal al directorio en el que se encuentra el Vagrantfile. És­tos son los comandos que he usado:

• vagrant up : arranca las tres máquinas virtuales en el orden que definido (Nodo01, Nodo02 y Nodo03) y crea los discos duros configurados si estos no exis­ten. En el caso de querer levantar alguna máquina en concreto hay que especifi­car su nombre. Por ejemplo: “vagrant up Nodo01”. Este comando, además, apli­ca las configuraciones de Puppet tras el arranque de la máquina virtual a no ser que se especifique el parámetro –-no-provision.

• vagrant provision : aplica las configuraciones de Puppet. Lo hace en el or­den que se han definido las máquinas y es posible hacerlo sobre una máquina en concreto indicando su nombre.

30

Construcción

• vagrant ssh <nombre_de_máquina> : se conecta por SSH a la máquina especificada con el usuario vagrant. Una vez abierta la sesión para cambiar al usuario root se puede usar el comando “sudo -i”.

• vagrant halt : apaga las tres máquinas virtuales en el orden inverso al defini­do. También es posible parar máquinas en concreto especificando su nombre.

• vagrant destroy : borra las tres máquinas virtuales y sus discos asociados en el orden inverso al definido. De igual modo, se puede borrar alguna máquina en concreto, en cuyo caso no borra el disco de almacenamiento compartido mientras exista alguna máquina que lo tenga conectado. La práctica habitual ha sido aña­dir el parámetro -f en la ejecución del comando para que no pida confirmación.

Todas las operaciones que se realizan con esta versión de Vagrant son secuenciales.

Configuraciones generales con Puppet

Organización de las configuracionesPor simplicidad he decidido usar un sólo fichero site.pp en el que he reali­

zado todas las configuraciones con excepción de las que he realizado en los módulos.

Debido a que la mayoría de configuraciones son comunes a los tres nodos, he creado un nodo llamado cluster que aglutina todas las configuraciones comunes. Mediante la herencia entre nodos, he hecho que cada uno de los nodos herede del nodo cluster . De esta forma, combino las configuraciones concretas de cada uno de los nodos y la reutilización de configuraciones.

También he definido los stage pre y post . Un stage se usa para organizar el orden en el que se ejecutan los recursos de tipo class. Por defecto existe un stage lla­mado main que es donde se ejecutan todas la configuraciones. En mi caso, he decidido que el stage pre se ejecute antes que main y el stage post, después. Ésta es una forma bastante limitada de organizar el orden de configuraciones, ya que dentro de un mismo stage no existe un orden a no ser que se defina mediante otros medios. Sin embargo es muy útil en caso de necesitar configurar ciertas acciones de las que dependen el resto de configuraciones, sin tener que crear explícitamente la dependencia entre los recursos.

En cuanto a los módulos, he intentado usar módulos ya existentes y publica­dos en el Puppet Forge. El Puppet Forge es una iniciativa de los creadores de Puppetlabs en la que la comunidad de usuarios de Puppet ponen a disposición módulos

31

Construcción

para la administración de tareas concretas. Según vaya describiendo la configuración de la plataforma indicaré si he usado un módulo disponible o si he usado uno pro­pio.

Distribución de ficherosLa distribución de ficheros es una de las partes más importantes de la gestión de con­

figuraciones. Esto se debe a que gran parte de la configuración del sistema operativo y los servicios se puede realizar mediante la modificación de ficheros.

Puppet es capaz de copiar ficheros en las máquinas virtuales a través del recurso file. Además de copiar ficheros, este recurso puede, entre otras cosas, crear directorios, crear enlaces simbólicos y establecer los permisos y propietarios.

He creado un módulo files, que tiene todos los ficheros distribuidos en las configuraciones del site.pp . Este módulo no contiene un manifiesto init.pp ya que no provee por sí mismo ninguna funcionalidad. En su directorio files, tiene un di­rectorio llamado comun y bajo el mismo una estructura de directorios que coincide con las rutas destino en las que son distribuidos los ficheros.

Configuración de la redUno de los mayores problemas con los que me he encontrado en cada creación de las

máquinas virtuales a partir de la box, es que la configuración de las tarjetas de red no era consistente.

Es decir, que a pesar de que he definido en el Vagrantfile que la nic1 es la interfaz para NAT, la nic2 es la interfaz para la red sólo anfitrión y la nic3 es la interfaz para la red interna, no siempre se correspondían con la eth0, eth1 y eth3 respectivamente.

Gran parte de las configuraciones asumen esa correspondencia entre el hardware vir­tual y los dispositivos del sistema operativo. Por ejemplo, en la configuración de las IP virtuales por parte de Pacemaker es necesario establecer en qué dispositivo ethernet va a ser creada cada IP.

Linux causa esta situación debido a la forma en que reconoce las interfaces de red y genera las nuevas reglas en las que asocia los dispositivos físicos y lógicos. El com­ponente del kernel udev genera las reglas que, en el caso de las interfaces de red, guar­da en el fichero /etc/udev/rules.d/70-persistent-net.rules.

He probado a forzar la dirección MAC de las tarjetas de red en el Vagrantfile sin nin­gún éxito. Desde mi experiencia, no existe ninguna razón que haga que udev genere las reglas de una forma determinista.

32

Construcción

Para tener siempre configuradas del mismo modo las tarjetas de red he dejado que udev genere unas reglas que he tenido que cambiar después.

Este cambio resulta bastante problemático, ya que forzar que el sistema operati­vo refresque los dispositivos una vez cambiadas las reglas sin realizar un reinicio no es una tarea trivial. Tirar y levantar las interfaces de red mediante los comandos ifdown e ifup no ha tenido ningún efecto y tampoco el reinicio del servicio de red networking.

Solamente lo he conseguido quitando en caliente el módulo del kernel de las tarjetas de red y volviéndolo a poner. En este caso, como las tarjetas de red son el mo­delo virtual “Intel PRO/1000 MT Server”, identificadas por VirtualBox como 82545EM, el módulo es el e1000.

Toda la configuración y comandos para realizar estas acciones la he empaquetado en un módulo de Puppet que he llamado persistent_net_rules . Este módulo consta de una clase definida en su manifiesto init.pp que recoge 4 parámetros: 3 direc­ciones MAC y el nombre del driver (o módulo) que corresponden las tarjetas de red. Ésta es la cabecera de la clase:

class persistent_net_rules ($mac1 = 'UNSET', $mac2 = 'UNSET', $mac3 = 'UNSET', $driver = 'UNSET')

Para el nodo nodo01.tfg.org he instanciado la clase de la siguiente forma:

class { 'persistent_net_rules': mac1 => '08:00:27:89:e2:2f', mac2 => '08:00:27:a1:77:25', mac3 => '08:00:27:70:aa:53', driver => 'e1000', stage => first,}

Establezco las 3 MAC que corresponden con las definidas en el Vagrantfile y “e1000” como módulo del kernel. Mediante el parámetro stage indico que se evalúe en el stage first ya que esta configuración es necesaria realizarla lo antes posible para que el resto puedan llevarse a cabo.

Las 3 variables con las MAC se utilizan en una plantilla que genera un nuevo fi­chero 70-persistent-net.rules asignándole secuencialmente las interfaces eth1, eth2 y eth3. El contenido de la plantilla es el siguiente:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="<%= @mac1 %>", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="<%= @mac2

33

Construcción

%>", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="<%= @mac3 %>", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

Para que Puppet la distribuya interpretada a cada una de las máquinas virtuales he añadido un recurso de tipo file en init.pp tal y como sigue:

file { '/etc/udev/rules.d/70-persistent-net.rules': ensure => 'file', owner => 'root', group => 'root', mode => '0644', content => template("persistent_net_rules/etc/udev/rules.d/70-persistent-net.rules.erb"),}

Una vez que Puppet evalúe este recurso, sobreescribirá con la plantilla interpretada el fichero que se encuentra en /etc/udev/rules.d/70-persistent-net.rules.

Por último, es necesario quitar y poner el módulo e1000 del kernel. Para ello, he ejecutado el comando “modprobe -r e1000 && modprobe e1000”, que realiza en una línea ambas acciones. La ejecución de comandos en Puppet se consigue mediante el recurso exec. Ésta es la definición del exec que he creado:

exec { "modprobe -r $driver && modprobe $driver": path => ['/sbin'], subscribe => File['/etc/udev/rules.d/70-persistent-net.rules'], refreshonly => true,}

La variable $driver guarda el nombre del módulo del kernel que va a ser “refrescado”. Este comando se ejecutará únicamente si Puppet ha distribuido en la mis­ma provisión de configuraciones el fichero 70-persistent-net.rules, ya que he inclui­do el parámetro subscribe haciendo referencia al recurso file que lo gestiona y tam­bién el parámetro refreshonly con el valor true.

Para que la configuración de red esté completa, es necesario configurar la interfaz eth2, ya que Vagrant, en esta versión, no es capaz de configurar las interfaces de red que son del tipo interna.

Para lograrlo, he usado el módulo ajjahn/puppet-network disponible en el Puppet Forge. Este módulo provee un recurso define llamado interface para configu­rar una interfaz. Esta es la configuración para el nodo01.tfg.org:

network::interface { $InterfazRedIntracluster: method => 'static',

34

Construcción

address => $IPInternaNodo03, network => $RedIntracluster, broadcast => $BroadcastRedIntracluster, before => Class['corosync'],}

De esta manera, define su dirección IP, red y dirección broadcast de forma estática. Mediante el parámetro before he configurado que este recurso debe evaluarse antes que la clase corosync.

Configuración de rsyslogrsyslog es el servicio encargado de las anotaciones de diario (“logs”) del sistema.

He creado una configuración a través con un recurso service para asegurar que esté siempre corriendo. Esto permite que en otras partes de la configuración sea reiniciado mediante una notificación.

La configuración del recurso service para rsyslog es la siguiente:

service { 'rsyslog': ensure => 'running', }

Configuración de AppArmorAppArmor permite asociar a cada programa un perfil de seguridad que

restringe sus capacidades. Proporciona “Control de Acceso Obligatorio” (DAC) com­plementando el acceso discrecional (DAC) de Linux.

He necesitado configurar un recurso service para poder reiniciarlo, ya que he tenido que reconfigurarlo para que MySQL funcione. Más adelante explico cómo he noti­ficado a AppArmor para que aplique su nueva configuración.

La configuración del recurso service para AppArmor es la siguiente:

service { 'apparmor': ensure => 'running', }

Configuración básica del almacenamiento LVMDurante la instalación del sistema operativo he realizado la configuración LVM para

el dispositivo en el que lo he instalado. Asimismo, he creado y asociado con Vagrant dos discos más a cada una de las máquinas que deben ser configurados mediante LVM.

Para realizar esta tarea he usado el módulo puppetlabs/lvm disponible en el Puppet Forge. Este módulo permite a través del recurso volume la creación de un volu­men físico y de un grupo de volúmenes con su tamaño y formato.

35

Construcción

La configuración LVM para el almacenamiento dedicado a GlusterFS es la si­guiente:

lvm::volume { 'LVGlusterFS': ensure => 'present', pv => '/dev/sdb', vg => 'VGGlusterFS', size => '2044M', fstype => 'xfs', require => Package['xfsprogs'], before => [Class['glusterfs::server'], Exec['/export/glusterfs']]}

No he podido establecer el tamaño a 2 GB tal y como he indicado en el análisis y diseño debido a un error desconocido presente en el módulo. He decidido bajar el ta­maño a 2044 MB que es el máximo que he observado que me permitía definir mediante este método.

Como el dispositivo generado lo he usado como soporte para el volumen de GlusterFS, he indicado que esta definición debe evaluarse antes que la instalación de GlusterFS que he realizado con la clase glusterfs::server y del montaje de la partición creada me­diante el exec /export/glusterfs.

Debido a que la partición del sistema de ficheros resultante está en el formato XFS, he incluido la dependencia del paquete xfsprogs , que he definido de la siguiente forma:

package { 'xfsprogs': ensure => 'present', notify => Service['rsyslog'],}

Los recursos package gestionan los paquetes del sistema. En este caso, he hecho que el paquete xfsprogs se encuentre presente, lo que equivale a instalado. También notifi­co al servicio rsyslog para que al instalar el paquete lo reinicie y así aparezca el nuevo nombre del host en los logs.

La configuración LVM para el almacenamiento compartido por bloques es la si­guiente:

lvm::volume { 'LVCompartidoBloques': ensure => 'present', pv => '/dev/sdc', vg => 'VGCompartidoBloques', size => '1000M',

36

Construcción

fstype => 'ext4', before => Exec['/mnt/compartidobloquesro'],}

Al igual que en el anterior caso, he tenido que poner un tamaño menor a 1 GB, por lo que he elegido 1000 MB. He establecido que esta definición se evalúe antes que el exec /mnt/compartidobloquesro que es el que se encarga de montar la partición en EXT4 sobre el grupo de volúmenes creado.

Configuración inicial de Corosync y PacemakerLa configuración tanto de Corosync y de Pacemaker la he realizado mediante el mó­

dulo puppetlabs/corosync disponible en el Puppet Forge.

En este apartado sólo voy a mostrar la configuración inicial que instala el soft­ware incluyendo los paquetes corosync y pacemaker , sus dependencias y la con­figuración básica para que el servicio arranque en el inicio. La configuración de los recur­sos del cluster la explicaré en los apartados de cada servicio.

La configuración que he hecho con la clase corosync es la siguiente:

class { 'corosync': bind_address => $RedIntracluster, multicast_address => $IPMulticastCorosync, enable_secauth => true, authkey => 'puppet:///modules/files/comun/etc/corosync/authkey',}

He establecido la red que usa para la comunicación entre los nodos que corresponde con el valor de la variable $RedIntracluster. He hecho lo mismo con la dirección multicast que usa para enviar los mensajes guardada en la variable $IPMulticastCorosync.

Las dos siguientes propiedades están relacionadas con la configuración de la seguridad de los mensajes que se comunican con Corosync. Para ello he establecido la propiedad enable_secauth al valor true y he indicado el fichero que contiene la clave simétrica. Este fichero contiene el valor de una clave generada previamente mediante el comando corosync-keygen.

Ésta es la primera vez que muestro la distribución de un fichero almacenado en el módulo files . En concreto éste se encuentra dentro del directorio comun, ya que es un fichero común a todos los nodos, y en la ruta /etc/corosync/authkey que se corres­ponde con el destino en el que se copiará el fichero en las máquinas.

37

Construcción

He establecido la versión del servicio pacemaker de la siguiente forma:

corosync::service { 'pacemaker': version => '0', }

El resto de propiedades del cluster que he definido son: el número de nodos del cluster, la acción a realizar en caso pérdida de quórum que corresponde con la parada de los nodos y la desactivación de STONITH (Shoot The Other Node In The Head) por no existir ningún mecanismo de STONITH soportado por VirtualBox 4.2.

cs_property { 'expected-quorum-votes': value => '3', }cs_property { 'no-quorum-policy': value => 'stop', }cs_property { 'stonith-enabled': value => 'false', }

Recursos y restriccionesLa parte más importante de la configuración de un cluster con Pacemaker son los re­

cursos y las restricciones.

El módulo puppetlabs/corosync proporciona recursos de Puppet que generan la con­figuración de Pacemaker. De esta forma, mediante sintaxis de Puppet he podido definir parte de las configuraciones de Pacemaker.

Los recursos de un cluster, también llamados primitivas, se designan con la palabra primitive . He realizado la configuración en Puppet mediante el recurso cs_primitive, con el que he configurado tres tipos básicos de recursos:

• Los que gestionan montajes de dispositivos de bloques en directorios.

• Los que gestionan servicios.

• Los que gestionan IP virtuales en una interfaz de red.

En cada caso concretos explicaré cómo los he configurado.

Por otro lado, las restricciones establecen la forma en la que los recursos se relacionan entre ellos y con los nodos. He utilizado las siguiente restricciones:

• order : establece el orden en el que deben arrancar y parar los recursos.

• colocation : establece que dos recursos deben correr en el mismo nodo. Está disponible en el módulo puppetlabs/corosync, pero su implementación tiene un error que define la dependencia de los recursos basado en el orden alfabético en vez de la establecida en la configuración.

• group : establece que un conjunto de recursos debe correr en el mismo nodo y su orden de arranque y parada. No está disponible en el módulo puppetlabs/corosync.

38

Construcción

• clone : establece que un recurso o grupo de recursos deben correr en más de un nodo. En mi caso lo he usado para que corra en todos los nodos. No está disponi­ble en el módulo puppetlabs/corosync.

Para poder configurar las restricciones no soportadas por el módulo, he decidido escri­bir recursos exec que ejecuten los comandos que habría que realizar a mano para su creación.

En este documento no hago referencia a los recursos cs_primitive, ni a la configura­ción mediante recursos exec, sino que he escrito toda la configuración del cluster confor­me a la sintaxis del “crm shell”. Éste es un shell interactivo en modo comandos para la configuración simplificada de los recursos de Pacemaker.

Primera configuración de PacemakerPacemaker arranca por defecto los recursos inmediatamente después de crearlos. Esto

supone un problema, ya que muchos de los recursos tienen dependencias con otros en colocación, orden y agrupación.

Para solucionar este problema, he decidido que la primera vez que Puppet configura Pacemaker, ponga los nodos en modo standby. Este modo impide que los nodos levanten cualquiera de los recursos. Para conseguirlo he configurado el siguien­te recurso exec:

exec { 'NodosStandby': path => ['/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin'], command => "crm node standby $NombreNodo01; crm node standby $NombreNodo02; crm node standby $NombreNodo03", unless => 'crm configure show | grep primitive', require => [Cs_property['expected-quorum-votes'], Cs_property['no-quorum-policy'], Cs_property['stonith-enabled']],}

He hecho que el resto de configuraciones de recursos de Pacemaker dependan de la evaluación de este exec de forma que se garantiza que todos los nodos es­tán en standby. Mediante el parámetro unless he comprobado que no exista ninguna primitiva definida en el cluster.

Para poner los nodos online de nuevo y que todos los recursos comiencen a arrancar, he definido un exec similar que ejecuta el comando “crm node online“ de los tres no­dos y que depende, mediante el parámetro require, de que todos los recursos y restric­ciones del cluster hayan sido previamente provisionadas.

39

Construcción

Configuración de GlusterFSLa configuración de GlusterFS se divide en 3 pasos:

1. Instalación de los paquetes y configuración del servicio glusterfs-server.

2. Reconocimiento de los compañeros (“peers”) de cluster a nivel de GlusterFS.

3. Creación del volumen de réplica y montaje de los volúmenes a nivel local.

Esto modifica en gran parte la forma de trabajo a la hora de crear las má­quinas con Vagrant. Los pasos 2 y 3 requieren que todas las máquinas tengan ya con­figuradas el servicio glusterfs-server. El paso 3 además requiere que el paso 2 haya tenido éxito. Debido a que Vagrant arranca las máquinas secuencialmente, en una úni­ca provisión tras la creación de las mismas no es posible completar la confi­guración de GlusterFS.

He necesitado realizar 2 provisiones de configuraciones además de la implí­cita en la creación de las máquinas. Para ello, he creado un script llamado “arranque.sh” que realiza un comando “vagrant up” seguido de 2 comandos “vagrant provision”. También he tenido, en los manifiestos de Puppet, que controlar en qué paso de la configuración se encuentra, ya que muchos servicios dependen de que GlusterFS esté completamente configurado.

A continuación describo en detalle la configuración de cada paso.

Instalación de los paquetes y configuración del servicioLa instalación y configuración la he realizado mediante una adaptación del módulo

thias/glusterfs disponible en el Puppet Forge. He necesitado adaptar este módulo ya que está pensado para distribuciones Red Hat Enterprise Linux. Esto supone cambiar los nombres de los paquetes a instalar para adaptarlos a Ubuntu.

He cambiado asimismo la parte correspondiente al service que indicaba que el servi­cio debe arrancarse al iniciar la máquina ya que debe ser Pacemaker quien gestione su estado. La definición que he creado para instalar GlusterFS es la siguiente:

class { 'glusterfs::server': }

Esta configuración instala todos los paquetes necesarios, incluyendo tanto los de clien­te como los de servidor. Para usar la última versión de GlusterFS, he instalado el PPA (“Personal Package Archives”) ppa:semiosis/ubuntu-glusterfs-3.3 a través del módulo puppetlabs/apt. En este repositorio personal se encuentra compilada actualmente la versión 3.3.1, mientras que en los repositorios oficiales de Ubuntu se en­cuentra la 3.2.5.

40

Construcción

En este punto de la configuración, todos los recursos que dependan del funcionamien­to GlusterFS no deben realizarse ya que faltan por completarse los pasos 2 y 3. Para controlar este requisito, he creado un facter que determine si la configuración ha llegado a este punto.

De forma resumida, un facter es una variable evaluable en un manifiesto de Puppet que toma el valor de la ejecución de un fichero programado en Ruby. Estos ficheros se encuentran en el directorio /usr/lib/ruby/vendor_ruby/facter/.

En mi caso, este fichero es muy simple y sólo devuelve el valor “Configurado”. De esta forma soy capaz de controlar mediante una instrucción if si he llegado a este punto de la configuración, dejando la parte dependiente dentro del if.

Reconocimiento de los peers de GlusterFSEl reconocimiento de los compañeros del cluster de GlusterFS se realiza a través

del comando “gluster peer <IP_del_compañero>”. No es necesario realizar todos los pares posibles para reconocer a los compañeros de cluster, sino que una vez ejecutado el comando “gluster peer” para reconocer una IP, la pareja queda reconoci­da. A pesar de esto, en el manifiesto he configurado que todos los pares intenten recono­cerse entre ellos si es que no lo han hecho antes.

Esta acción sólo es necesaria realizarla una vez. Del mismo modo que en el caso ante­rior, he creado un facter llamado “glusterpeers” para controlar si esta acción ha sido realizada.

Ésta es la configuración para el nodo nodo01.tfg.org:

if $::sistemabase == 'Configurado' { if $::glusterpeers != 'Configurado' { exec { 'gluster-peer-Nodo01-Nodo02': path => ['/usr/sbin', '/bin'], command => "gluster peer probe $IPInternaNodo02", unless => "gluster peer status | egrep '^Hostname: $IPInternaNodo02$'", require => Class['glusterfs::server'], } exec { 'gluster-peer-Nodo01-Nodo03': path => ['/usr/sbin', '/bin'], command => "gluster peer probe $IPInternaNodo03", unless => "gluster peer status | egrep '^Hostname: $IPInternaNodo03$'", require => Class['glusterfs::server'],

41

Construcción

}

Lo primero que hago es controlar en qué punto de la evaluación del catálogo de confi­guraciones se encuentra mediante los facter $::sistemabase y $::glusterpeers. Sólo se realizarán los dos exec en caso de que $::sistemabase esté configurado y $::glusterpeers no lo esté. He impedido reconocer a compañeros previamente identifi­cados configurando parámetro unless.

Creación del volumen de réplica y montajeEl primer paso para crear el volumen de réplica es montar en el directorio

/export/glusterfs el grupo de volúmenes LVM creado anteriormente. Para mon­tarlo he configurado el siguiente recurso exec:

exec { '/export/glusterfs': path => ['/bin'], command => 'mount -t xfs /dev/VGGlusterFS/LVGlusterFS /export/glusterfs', unless => 'mount | grep /export/glusterfs', require => File['/export/glusterfs'],}

He decidido utilizar un exec en vez del recurso mount debido a que este último confi­gura de forma obligatoria el montaje en el arranque de la máquina. Debido a que este montaje es un recurso del que se ocupa Pacemaker, es mejor que no esté definido en el arranque.

La creación del volumen la he realizado a través de un define del módulo thias/glusterfs .

if $::glusterpeers == 'Configurado' { glusterfs::volume { 'VolumeGlusterFS': create_options => "replica 3 $IPInternaNodo01:/export/glusterfs $IPInternaNodo02:/export/glusterfs $IPInternaNodo03:/export/glusterfs", require => Exec['/export/glusterfs'], before => [Cs_primitive['GlusterFSExport'],Cs_primitive['GlusterFSVolume'], Exec['/mnt/GlusterFS']], } (...)

Mediante la definición glusterfs::volume he creado un volumen de réplica en 3 no­dos llamado VolumeGlusterFS. A continuación, pongo los peer del cluster indicando su IP y el directorio que exporta. Mediante el parámetro before controlo que esta defini­ción se evalúe antes que otros recursos que necesitan esta acción.

He hecho el montaje local del volumen con el siguiente exec:

42

Construcción

exec { '/mnt/GlusterFS': path => ['/bin'], command => 'sleep 5 && mount -t glusterfs localhost:/VolumeGlusterFS /mnt/GlusterFS && sleep 5', unless => 'mount | grep /mnt/GlusterFS', require => File['/mnt/GlusterFS'],}

He añadido una parada de 5 segundos mediante el comando sleep antes del montaje para que haya tiempo suficiente entre la creación del volumen y el montaje. He observado que en algunos de los arranques de las máquinas virtuales fallaba el montaje si no existía tiempo suficiente después de la creación del volumen. Lo mismo ocurría cuando intentaba escribir en el directorio /mnt/GlusterFS inmediatamente después del montaje, por lo que he añadido otra parada de 5 segundos después. Otro aspecto intere­sante del montaje es que se realiza con el tipo especial glusterfs y sólo sobre el servicio GlusterFS que está corriendo en local, ya que indico localhost como dirección del brick.

Configuración de Pacemaker para GlusterFSEl primer recurso es el montaje del dispositivo

/dev/VGGlusterFS/LVGlusterFS en /export/glusterfs. Para ello, he creado la primitiva GlusterFSExport del tipo ocf:heartbeat:Filesystem:

primitive GlusterFSExport ocf:heartbeat:Filesystem \ op start interval="0s" timeout="60s" \ op stop interval="0s" timeout="60s" \ op monitor interval="10s" timeout="60s" \ params fstype="xfs" directory="/export/glusterfs"device="/dev/VGGlusterFS/LVGlusterFS"

El segundo recurso es el servicio glusterfs-server que Ubuntu gestiona me­diante upstart. Por tanto, esta primitiva es del tipo upstart:glusterfs-server. A continuación muestro la configuración de la primitiva GlusterFSServer:

primitive GlusterFSServer upstart:glusterfs-server \ op start interval="0" timeout="30s" start-delay="1s" \ op monitor interval="10s" timeout="30s"

El tercer y último recurso, es el montaje del volumen exportado en /mnt/GlusterFS. Ésta es la primitiva GlusterFSVolume que he creado:

primitive GlusterFSVolume ocf:heartbeat:Filesystem \ op start interval="0" timeout="60s" start-delay="5s" \ op stop interval="0" timeout="60s" \

43

Construcción

op monitor interval="20s" timeout="60s" \ params fstype="glusterfs" directory="/mnt/GlusterFS" device="localhost:/VolumeGlusterFS"

Uno de los problemas que me he encontrado al realizar esta configuración es que el sistema de ficheros glusterfs , indicado mediante el parámetro fstype, no está soportado por esta versión de Pacemaker. Para solucionar este problema, he baja­do el script que gestiona los recursos ocf:heartbeat:Filesystem del repositorio Git de Pacemaker con la última versión. He distribuido este fichero mediante un recurso file a la ruta /usr/lib/ocf/resource.d/heartbeat/Filesystem que es donde se encuentran los agentes de Pacemaker.

Con estas 3 primitivas he creado el grupo GlusterFS , que asegura que los tres recursos están presentes en el mismo nodo, que se arrancan en el orden que han sido de­clarados y que se paran en el orden inverso. Ésta es la configuración del grupo:

group GlusterFS GlusterFSExport GlusterFSServer GlusterFSVolume

El orden en el arranque ha hecho necesario que añada los parámetros start-delay en GlusterFSVolume y GlusterFSServer . Tras varios arranques en los que no funcionaban los montajes de las particiones, he observado que estos valo­res son suficientes.

Por último, y como este grupo de recursos tienen que correr en todos los nodos del cluster, he creado un clone del grupo GlusterFS, llamado CloneGlusterFS .

clone CloneGlusterFS GlusterFS

El clonado me ha creado un problema adicional, ya que el agente del recurso Filesystem rechaza crear un clone para sistemas de ficheros de tipo XFS. Esto se debe a que XFS no es un sistema de ficheros en cluster y el agente usa esta com­probación como una protección en caso de malas configuraciones. En mi caso, a pesar de que GlusterFSExport corre en todos los nodos y sobre dispositivos que coinciden en nombre, los dispositivos de almacenamiento son distintos por lo que no es necesario apli­car esta protección.

Para solucionar este problema, he modificado el script del agente, incluyendo XFS como un tipo de los considerados como seguros de montaje en cluster y por tanto admisibles en un clone.

Configuración inicial de MySQLLa instalación de MySQL la he realizado mediante el módulo puppetlabs/mysql

disponible en el Puppet Forge. Ésta es la definición que he incluido en el site.pp:

44

Construcción

class { 'mysql::server': manage_service => false,}

Esta configuración establece que el servicio mysql no lo gestionen las provisiones con Puppet. Debido a que el servicio está gestionado mediante Pacemaker, he creado un recurso exec que lo pare siempre que no esté definido el recurso que lo gestiona:

exec { 'service mysql stop': path => ['/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin'], command => 'service mysql stop', unless => 'crm configure show | grep "primitive MySQLServer"', returns => ['0', '1'], require => [Class['mysql::server'], Class['corosync']],}

De igual manera, he definido el siguiente recurso service para que no arranque en el inicio de la máquina:

service { 'mysql': enable => false, provider => 'upstart', require => Class['mysql::server'],}

Configuración de Pacemaker para MySQLEl primer recurso es el montaje del dispositivo para el almacenamiento com­

partido por bloques. Para ello he creado la primitiva CompartidoBloques, del tipo ocf:heartbeat:Filesystem con la siguiente configuración:

primitive CompartidoBloques ocf:heartbeat:Filesystem \ op start interval="0" timeout="60s" \ op stop interval="0" timeout="60s" \ op monitor interval="10s" timeout="60s" \ params fstype="ext4" device="/dev/VGCompartidoBloques/LVCompartidoBloques" directory="/mnt/compartidobloques"

El segundo recurso es el servicio mysql que he configurado con la primitiva MySQLServer del tipo ocf:heartbeat:mysql:

primitive MySQLServer ocf:heartbeat:mysql \ op start interval="0" timeout="120s" \

45

Construcción

op stop interval="0" timeout="120s" \ op monitor interval="10s" timeout="30s" \ params datadir="/mnt/compartidobloques/mysql" binary="/usr/sbin/mysqld" additional_parameters="--bind-address=192.168.250.140"

Esta primitiva gestiona el servicio y además es capaz de definir algunos de sus pará­metros de configuración. En mi caso, he establecido que el directorio de datos es /mnt/compartidobloques/mysql que está bajo el montaje de la anterior primitiva.

He configurado que el servicio sólo escuche en la IP 192.168.250.140, que es una IP de la red intracluster y por tanto no está expuesta al exterior. Esta IP la he configurado mediante la primitiva IPMySQL de la siguiente forma:

primitive IPMySQL ocf:heartbeat:IPaddr2 \ op monitor interval="30s" \ params nic="eth2" cidr_netmask="24" ip="192.168.250.140"

Por último, he creado el grupo MySQL con las 3 primitivas anteriores para esta­blecer su orden de arranque y parada así como asegurarme de que los 3 recursos corran en el mismo nodo:

group MySQL IPMySQL CompartidoBloques MySQLServer

Configuración de AppArmor para MySQLMySQL está fuertemente protegido por AppArmor. Tanto es así, que la configura­

ción de los parámetros binary, datadir y –-bind-address mediante Pacemaker hace que el servicio no arranque.

Para conseguir que mysql arranque he tenido que añadir las siguientes líneas den­tro del bloque /usr/sbin/mysqld del fichero /etc/apparmor.d/usr.sbin.mysqld :

/var/lib/mysqld/mysqld.pid w, /var/lib/mysqld/mysqld.sock w, /mnt/compartidobloques/mysql/ r, /mnt/compartidobloques/mysql/** rwk,

Este fichero lo he distribuido mediante un recurso file que notifica al servicio apparmor que se reinicie.

Configuración de GitLa configuración de Git se basa en la instalación del paquete git . Para ello he

creado en el manifiesto init.pp un recurso de tipo package que instale el

46

Construcción

paquete git .

Uno de los requisitos descritos en el análisis y diseño, es que el acceso a los reposito­rios Git sea a través del usuario git acotando sus permisos. La creación del usuario git la he hecho mediante un recurso user tal y como sigue:

user { 'git': ensure => 'present', uid => '2000', shell => '/usr/bin/git-shell', require => Package['git'],}

Este recurso, además de crear el usuario git, establece su identificador de usuario y shell. git usa una shell especial llamada git-shell que restringe los comandos que pue­de ejecutar permitiendo sólo con Git.

La creación del repositorio bare la he realizado mediante la ejecución del comando “git init –bare”. Para ello he configurado el siguiente exec:

exec { 'git init –bare': path => ['/bin', '/usr/bin'], cwd => '/mnt/GlusterFS/repositorio-remoto', user => 'git', group => 'git', unless => 'ls /mnt/GlusterFS/repositorio-remoto | grep config', require => File['/mnt/GlusterFS/repositorio-remoto'],}

Con el parámetro unless controlo no generar más de una vez el repositorio compro­bando la existencia del archivo config en la ruta destino.

Por último, y debido a que no he establecido una contraseña para el usuario, he cre­ado una par de claves SSH, usando el comando ssh-keygen , que sirven como autenticación del usuario git. Para ello he configurado el siguiente recurso del tipo ssh_authorized_key:

ssh_authorized_key { 'git': ensure => 'present', user => 'git', type => 'ssh-rsa', key => '<contenido de la clave pública>'}

La clave privada la tendrán los clientes del repositorio Git que puedan acceder con el usuario git.

47

Construcción

Configuración de Pacemaker para GitGit sólo necesita una IP en alta disponibilidad para dar servicio a sus clientes a

través del servicio SSH. He configurado la primitiva IPGit del tipo ocf:heartbeat:IPaddr2 de la siguiente forma:

primitive IPGit ocf:heartbeat:IPaddr2 \ op monitor interval="30s" \ params ip="192.168.2.130" nic="eth2" cidr_netmask="24"

Por otro lado, sí que es necesario que IPGit esté en un nodo que tenga mon­tado el volumen de GlusterFS. Para asegurar que esto suceda, he añadido un colocation de la primitiva Git junto a CloneGlusterFS de la siguiente manera:

colocation GitCloneGlusterFSColocation inf: Git CloneGlusterFS

Por último, es necesario que GlusterFS arranque antes de que la IP esté defini­da, por lo que también he creado la siguiente restricción de orden:

order GitOrder inf: CloneGlusterFS Git

Configuración inicial de ApacheHe configurado Apache a través de un módulo propio que he llamado apache.

Aunque he probado el módulo puppetlabs/apache disponible en el Puppet Forge, he decidido no usarlo debido a la rigidez tanto de las configuraciones genera­das para Apache como de la configuración del servicio.

El módulo apache es muy simple y sólo se encarga de asegurarse de que el paquete apache2 esté instalado y que el servicio apache2 no arranque en el inicio de las máquinas virtuales. Al igual que el resto de servicios, es Pacemaker el que se encarga de gestionar su arranque.

El resto de configuraciones están en el fichero site.pp . Debido a que la ins­talación arranca el servicio apache2, he configurado un recurso de tipo exec que lo de­tenga ejecutando el comando “service apache2 stop”.

El certificado y clave privada que he usado para la configuración SSL son los ge­nerados por defecto en la instalación de Ubuntu. En un arranque de las máqui­nas he copiado los ficheros /etc/ssl/certs/ssl-cert-snakeoil.pem y /etc/ssl/private/ssl-cert-snakeoil.key; asimismo he configurado dos recursos de tipo file para distribuirlos en los posteriores arranques en las máquinas.

La configuración de Apache está ampliada en los apartados referidos a Redmine y Tomcat.

48

Construcción

Configuración de Pacemaker para ApacheHe configurado una primitiva llamada ApacheServer del tipo

ocf:heartbeat:apache:

primitive ApacheServer ocf:heartbeat:apache \ op monitor interval="30s" timeout="30s" \ op start interval="0" timeout="40s" \ op stop interval="0" timeout="60s" \ params configfile="/etc/apache2/apache2.conf"httpd="/usr/sbin/apache2" statusurl="http://127.0.0.1/server-status"

Esta primitiva gestiona el servicio apache2 e indica la URL para monitorizarlo.

Igualmente he configurado una primitiva IP con el nombre IPApache y la direc­ción 192.168.2.110 en la interfaz eth1. Ambos recursos los he agrupado mediante el grupo Apache, que tiene la siguiente configuración:

group Apache IPApache ApacheServer

Configuración de RedmineLa configuración de Redmine se basa en la instalación de los paquetes redmine

y redmine-mysql . Al igual que con GlusterFS, la versión de Redmine disponible es bastante antigua, por lo que lo he instalado a partir del PPA ppa:ondrej/redmine . La versión en este PPA es la 2.3.0 mientras que en los reposi­torios oficiales de Ubuntu se encuentra la versión 1.3.2.

El uso de este PPA ha supuesto diversos problemas, ya que en ocasiones, paquetes dependientes para la instalación, no se encontraban disponibles debido a fallos de compilación, haciendo que la configuración de las máquinas virtuales no se completa­ra.

La instalación del paquete redmine es interactiva, ya que el asistente dbconfig-common configura la base de datos de Redmine. Este asistente pide la contraseña de ad­ministrador de MySQL y de Redmine.

No es posible realizar estas acciones interactivas usando un recurso package de Puppet. Para solventar este problema, he realizado la instalación en una máquina virtual de forma manual y he copiado la configuración y base de datos gene­rada. Todos estos recursos los he distribuido mediante Puppet en los posteriores arran­ques de las máquinas del cluster.

Los ficheros de configuraciones generados son los siguientes:

49

Construcción

• /etc/redmine/default/database.yml : configuración de la base de datos de Redmine.

• /etc/redmine/default/session.yml : configuración de las sesiones de Redmine.

• /etc/dbconfig-common/redmine/instances : configuración de dbconfig-common de la instancia por defecto de Redmine.

Por último, a través de un recurso file, he creado el enlace /var/www/redmine apun­tando a /usr/share/redmine/public. Esto se consigue estableciendo los atributos ensure al valor link y target a la ruta de destino del enlace.

Configuración de MySQL para RedminePara que las máquinas tengan la base de datos limpia que se obtiene de la instalación

de Redmine, he decidido hacer una copia de los ficheros de datos de MySQL. Para ello, he parado el servicio MySQL y he hecho un fichero “tar.gz” del directorio /var/lib/mysql.

Éste es el fichero que en la creación de las máquinas virtuales tengo que desplegar en la ruta /mnt/compartidobloquesro/mysql .

Para conseguirlo, he montado el dispositivo /dev/VGCompartidoBloques/LVCompartidoBloques en la ruta /mnt/compartidobloquesro con un recurso exec. Este montaje sólo debe usarse con el fin de copiar este directorio, ya que al estar formateado en EXT4 y montado en todas las máquinas virtuales al mismo tiempo, podrían existir conflictos si se modifica concurrentemente.

He realizado la extracción del fichero mediante el siguiente recurso exec:

exec { 'CopiaFicherosMySQL': path => ['/bin'], cwd => '/root', command => 'mkdir -p /mnt/compartidobloquesro/mysql && chown mysql:mysql /mnt/compartidobloquesro/mysql && chmod 700 /mnt/compartidobloquesro/mysql && tar -C /mnt/compartidobloquesro/mysql -xvf /root/base_mysql.tar.gz && sync', unless => 'ls /mnt/compartidobloquesro/mysql/ | grep debian-5.5.flag', require => [File['/root/base_mysql.tar.gz'], Exec['/mnt/compartidobloquesro']],}

50

Construcción

El comando se divide en cinco partes. Primero crea el directorio /mnt/compartidobloquesro/mysql, hace propietario del mismo al usuario mysql y es­tablece sus permisos. Después extrae el fichero que ha sido previamente copiado a /root/base_mysql.tar.gz. Por último sincroniza los sistemas de archivos. Con el pará­metro unless controlo que este comando sólo se ejecuta si no existe el fichero /mnt/compartidobloquesro/mysql/debian-5.5.flag, que es uno de los incluidos den­tro del fichero “tar.gz” y que uso como monitor.

Configuración de Apache para RedmineHe instalado el paquete libapache2-mod-passenger y modificado el fichero de

configuración /etc/apache2/mods-available/passenger.conf añadiendo la directiva “PassengerDefaultUser www-data”. De esta forma, indico el usuario con el que debe ejecutarse Passenger que es con el que se ejecuta Apache.

El siguiente paso consiste en activar el módulo Passenger. Para ello es necesario ejecutar el comando “a2enmod passenger”. La ejecución del comando la he hecho me­diante el siguiente exec:

exec { 'a2enmod passenger': path => ['/usr/sbin', '/bin', '/usr/bin'], command => 'a2enmod passenger', unless => 'ls /etc/apache2/mods-enabled/ | grep passenger.load', require => [Package['libapache2-mod-passenger'], File['/etc/apache2/mods-available/passenger.conf']],}

Esta configuración ejecutará el comando sólo si detecta que no existe en /etc/apache2/mods-enabled/ el fichero passenger.load. Si se encuentra este fichero, significa que el módulo ya está cargado.

El último paso es la configuración del virtual host para Redmine. He distribui­do su configuración mediante un recurso file que copia el fichero /etc/apache2/sites-available/redmine.conf. Éste fichero es una copia del fichero de ejemplo para configuración de virtual host con SSL que se encuentra en /etc/apache2/sites-available/default-ssl. Las modificaciones que he hecho son:

• Declarar el virtual host con la directiva “<VirtualHost 192.168.2.110:443>”.

• Declarar su nombre con la directiva “ServerName redmine.tfg.org”.

• Declarar el directorio raíz de documentos con la directiva “DocumentRoot /var/www/redmine”. Éste enlace apunta a la instalación de

51

Construcción

Redmine.

• Establecer las opciones de Rails y Passenger con el siguiente bloque Directory:

<Directory /var/www/redmine> RailsBaseURI /redmine PassengerResolveSymlinksInDocumentRoot on </Directory>

Al igual que con el módulo Passenger, he tenido que activar la configuración del virtual host. Para activarlo, he configurado el siguiente recurso exec que ejecute el co­mando “a2ensite redmine”:

exec { 'a2ensite redmine': path => ['/usr/sbin', '/bin', '/usr/bin'], command => 'a2ensite redmine', unless => 'ls /etc/apache2/sites-enabled | grep redmine', require => [Package['libapache2-mod-jk'], Exec['a2enmod jk'], Exec['a2enmod ssl'], File['/etc/apache2/sites-available/redmine']]}

a2ensite crea un enlace en el directorio /etc/apache2/sites-enabled/redmine, que he comprobado si existe para no activarlo innecesariamente.

Configuración de Pacemaker para RedmineRedmine necesita que Apache y MySQL estén corriendo para funcionar.

En este caso no es necesario que ambos servicios se encuentren en el mismo nodo, pero sí es importante el orden de arranque y parada.

Para asegurar que MySQL arranca antes que Apache he configurado el siguiente order:

order ApacheOrder inf: MySQL Apache

El orden de parada de los servicios es el inverso.

Configuración de TomcatTomcat necesita las librerías de ejecución de Java, por lo que he instalado el Java

Runtime Environment de OpenJDK 7. Para ello he configurado un recurso package que instala el paquete openjdk-7-jre.

La configuración de Tomcat la he realizado mediante un módulo que he creado, llamado tomcat, y recursos en el site.pp . He probado varios módulos disponibles

52

Construcción

en el Puppet Forge pero ninguno me ofrecía la flexibilidad necesaria o era capaz de ges­tionar las últimas versiones de Tomcat.

Las configuraciones que he hecho en el módulo tomcat son las siguientes:

• Instalación del paquete tomcat7 . He decidido usar la versión 7 a pesar de es­tar también disponible en los repositorios la versión 6.

• Instalación del paquete libtcnative-1 . Esta es una librería JNI (Java Native Interface) que permite a algunas de las funcionalidades de Tomcat ejecu­tarse de forma nativa en vez de a través del bytecode de Java. Suele utilizarse en entornos de producción de alto rendimiento.

• Instalación de la aplicación psi-probe. Esta aplicación permite la monitori­zación y administración de Tomcat. Para ello he configurado un recurso file que copie el fichero probe.war a la ruta /var/lib/tomcat7/webapps/ que es donde se despliegan las aplicaciones WAR (Web Archive).

Las configuraciones que he incluido en el site.pp son las siguientes:

• Copia del fichero de configuración server.xml a /etc/tomcat7. Éste es el fichero de configuraciones generales de Tomcat. En él he definido un conector AJP en el puerto 8009 que es el encargado de servir las peticiones que Apache hace. He configurado este puerto para que sólo escuche en la IP 192.168.250.120.

• Copia del fichero de configuración tomcat-users.xml a /etc/tomcat7. Éste es el fichero en el que se definen los usuarios de Tomcat, sus roles y contra­señas. Es importante configurarlo para restringir de forma correcta el acceso a la aplicación psi-probe.

• Copia del fichero setenv.sh a /usr/share/tomcat7/bin. Éste es el fichero que establece variables de entorno en el arranque de Tomcat. También permite definir cualquier parámetro configurable de la JVM (Java Virtual Machine) como los espacios de memoria o el ajuste del recolector de basura. En mi caso he confi­gurado un límite del heap a 512 MB.

También he parado el servicio tomcat7 para que lo gestione Pacemaker mediante un recurso exec que invoca el comando “service tomcat7 stop”.

Configuración de Apache para TomcatPara que Apache sea capaz de realizar peticiones a Tomcat actuando como un proxy

es necesario instalar el módulo mod_jk mediante el paquete libapache2-mod-jk. La activación del módulo le ha realizado mediante un exec que ejecute el comando “a2enmod jk”.

53

Construcción

En el fichero /etc/libapache2-mod-jk/workers.properties se establecen los Tomcat a los que Apache envía las peticiones. Este fichero lo he distribuido median­te un recurso de tipo file y en él he configurado las siguientes directivas:

worker.list=tomcatworker.tomcat.port=8009worker.tomcat.host=192.168.250.120worker.tomcat.type=ajp13

Con esta configuración creo un worker llamado tomcat . Un worker es un agente capaz de resolver peticiones AJP que escucha en una dirección IP y un puerto. Mediante worker.list añado el worker creado a la lista de worker configurados a los que enviar peticiones.

Configuración de JenkinsJenkins es una aplicación WAR, así que es necesario copiarla al directorio de

aplicaciones de Tomcat. Para ello, he configurado un recurso file que copia el fiche­ro jenkins.war a /var/lib/tomcat7/webapps.

Tal y como he decidido en el capítulo de análisis y diseño, el directorio JENKINS_HOME se encontrará en /mnt/GlusterFS/jenkins_home . Para crear­lo, he configurado el siguiente recurso file:

file { '/mnt/GlusterFS/jenkins_home': ensure => 'directory', owner => 'tomcat7', group => 'tomcat7', mode => '0755', require => [Exec['/mnt/GlusterFS'], Class['tomcat']],}

Con este recurso, creo el directorio y establezco el propietario y grupo como tomcat7, que es el usuario con el que se ejecuta Tomcat, y por tanto Jenkins. También establezco los permisos con el atributo mode.

Mediante el atributo require establezco que la clase tomcat haya sido anteriormente evaluada, ya que si no, no será posible establecer el propietario y grupo. También que haya sido evaluado el exec /mnt/GlusterFS ya que es imprescindible que GlusterFS esté siendo ejecutado en la máquina y haya sido montado su volumen. La ejecución en cualquiera de los nodos tendrá efecto en todos debido a la replicación me­diante GlusterFS.

54

Construcción

Por último, he configurado el virtual host para Jenkins. La configuración le he rea­lizado en el fichero /etc/apache2/sites-available/jenkins.conf. Al igual que para Redmine, es una copia del fichero de ejemplo de configuración para SSL en el que he he­cho las siguientes modificaciones:

• Declarar el virtual host con la directiva “<VirtualHost 192.168.2.110:443>”.

• Declarar su nombre con la directiva “ServerName jenkins.tfg.org”.

• Añadir la directiva “JkMount /* tomcat”. De esta forma todas las peticio­nes que le lleguen a este virtual host las enviará a través del worker llamado tomcat.

He activado el virtual host con un exec que ejecuta el comando “a2ensite jenkins”.

Configuración de Pacemaker para JenkinsJenkins se ejecuta en Tomcat, así que he creado la primitiva TomcatServer

del tipo lsb:tomcat7 que gestiona el servicio tomcat7 de la siguiente forma:

primitive TomcatServer lsb:tomcat7 \ op monitor interval="10s" timeout="30s" \ op start interval="0" timeout="15s" \ op stop interval="0" timeout="15s"

También he creado la primitiva IPTomcat para poder hacerle peticiones por IP in­dependientemente del nodo en el que se esté ejecutando. Ambas primitivas las he agrupado en el grupo Tomcat .

Es imprescindible que GlusterFS esté corriendo en el mismo nodo que Tomcat, para que Jenkins tenga acceso al directorio JENKINS_HOME. He creado el si­guiente colocation para asegurarlo:

colocation TomcatCloneGlusterFSColocation inf: Tomcat CloneGlusterFS

Por último, he creado un order para que arranque antes GlusterFS que Tomcat:

order TomcatOrder inf: CloneGlusterFS Tomcat

Configuración de OpenLDAPHe hecho la instalación de OpenLDAP mediante dos recursos package que aseguren

la presencia de los paquetes slapd y ldap-utils . Al igual que con el resto de servi­cios he configurado que el servicio slapd no arranque en el inicio mediante un recurso

55

Construcción

service.

La versión incluida con Ubuntu Server de slapd mantiene la configuración en un DIT (Directory Information Tree) propio identificado como cn=config . Esto sig­nifica que no puede configurarse mediante ficheros y debe usarse en su lugar la utilidad ldapmodify y la sintaxis LDIF (LDAP Interchange Format).

Una vez instalado, he cambiado la contraseña de root de slapd copiando el fichero /root/rootpassword.ldif mediante un recurso file y ejecutando posteriormente el si­guiente exec:

exec { 'PasswordLDAP': path => ['/usr/bin/'], cwd => '/root', command => 'ldapmodify -Y EXTERNAL -H ldapi:/// -f rootpassword.ldif', refreshonly => true, subscribe => File['/root/rootpassword.ldif'], notify => Service['slapd'],}

Éste exec ejecuta el comando ldapmodify realizando las acciones descritas en rootpassword.ldif. Éste es el contenido del fichero:

dn: olcDatabase={1}hdb,cn=config replace: olcRootPW olcRootPW: {SSHA}Bt/4TYcVaUfnyH7WzbOg5wXErRFTy3Rg

He obtenido el valor de olcRootPW de la ejecución del comando “slappasswd -h {SSHA} -s <password>”

La instalación también crea un DIT en el que se almacenan los datos para los usuarios. En mi caso este DIT se llama dc=tfg,dc=org . He añadido contenido si­guiendo la misma técnica anterior con la información contenida en el fichero /root/content.ldif que también he distribuido con un recurso file.

Configuración TLSPara la configuración TLS he creado certificados autofirmados con la herra­

mienta certtool . Una vez creados, he distribuido mediante recursos file, los si­guientes ficheros:

• /etc/ssl/certs/nodo01_slapd_cert.pem: certificado.

• /etc/ssl/private/nodo01_slapd_key.pem: clave privada del certificado.

56

Construcción

• /etc/ssl/certs/cacert.pem: certificado de la CA con la que he firmado los cer­tificados.

sladp se ejecuta con el usuario openldap. Para que tenga acceso a la clave privada del certificado, he añadido el usuario openldap al grupo ssl-cert , con el si­guiente recurso user:

user { 'openldap': ensure => 'present', groups => ['ssl-cert'], require => [Package['slapd'], Package['ssl-cert']],}

Por último, he creado y distribuido el fichero /root/certinfo.ldif con el siguiente contenido:

dn: cn=configadd: olcTLSCACertificateFileolcTLSCACertificateFile: /etc/ssl/certs/cacert.pem- add: olcTLSCertificateFileolcTLSCertificateFile: /etc/ssl/certs/nodo01_slapd_cert.pem- add: olcTLSCertificateKeyFileolcTLSCertificateKeyFile: /etc/ssl/private/nodo01_slapd_key.pem

He introducido este contenido mediante un exec que ejecuta el comando ldapmodify y que activa la posibilidad de acceso mediante TLS.

Replicación multi-maestroLa replicación multi-maestro de slapd consiste en la configuración de varios pa­

rámetros del DIT cn=config . He configurado la replicación para que replique tanto la configuración como los datos contenidos en dc=tfg,dc=org.

Para ello, he creado varios recursos exec que ejecutan comandos ldapmodify si­guiendo estos pasos:

1. Añadir la propiedad olcServerID a cn=config con un identificador numéri­co distinto para cada servidor.

2. Cargar el módulo syncprov .

3. Cambiar la contraseña de root para la replicación.

57

Construcción

4. Establecer los identificadores del resto de servidores mediante olcServerID en cn=config.

5. Añadir la capa de replicación olcOverlay=syncprov para la base de datos de configuraciones olcDatabase={0}config,cn=config.

6. Añadir el atributo olcSyncRepl de la base de datos de configuraciones de­finiendo los parámetros para conectarse a los servicios LDAP de los otros servido­res.

7. Añadir el atributo olcSyncRepl de la base de datos olcDatabase={1}hdbconfig,cn=config definiendo los parámetros para co­nectarse a los servicios LDAP de los otros servidores.

8. Añadir a olcOverlay=syncprov,olcDatabase={1}hdb,cn=config los atributos “objectClass: olcOverlayConfig”, “objectClass: olcSyncProvConfig” y “olcOverlay: syncprov”.

Configuración de Pacemaker para OpenLDAPHe creado la primitiva Slapd del tipo lsb:slapd que gestiona el servicio. Ésta

es su configuración:

primitive Slapd lsb:slapd \ op start interval="0" timeout="30s" start-delay="1s" \ op monitor interval="10s" timeout="30s"

Como el servicio slapd tiene que ejecutarse en todos los nodos, he creado el si­guiente clone :

clone CloneSlapd Slapd

Para que exista una referencia que usen los clientes, he creado la primitiva IPLDAP que gestiona la IP asociada a slapd . También he creado el grupo LDAP que sólo tiene éste recurso IP.

Por último, he configurado la colocación LDAPCloneSlapd para que la IP de LDAP esté siempre en un nodo en el que se encuentre activa la primitiva CloneSlapd.

colocation LDAPCloneSlapd inf: LDAP CloneSlapd

58

Pruebas

PruebasNo he destinado un periodo de tiempo exclusivo a las pruebas, sino que las he realiza­

do a lo largo de la fase de construcción.

Para comprobar que la configuración realizada con Vagrant y Puppet es la correcta he realizado despliegues completos de la infraestructura casi a diario. Esto ha supuesto más de 50 arranques completos, tras los que he comprobado que los servicios están correctamente configurados y el cluster los mantiene levantados.

He realizado la monitorización del cluster con el comando crm_mon que está in­cluido en la instalación de Pacemaker. También he usado LCMC (Linux Cluster Management Console) que es una aplicación escrita en Java para el control de clusters de forma remota.

Para probar el acceso a las aplicaciones web Redmine y Jenkins, y debido a que están configuradas mediante dos virtual host, he añadido en el fichero /etc/hosts de mi equi­po de escritorio las entradas que corresponden con la IP asignada a Apache con los nom­bres jenkins.tfg.org y redmine.tfg.org. Las aplicaciones están disponibles en https://redmine.tfg.org/ y https://jenkins.tfg.org/jenkins/.

En cuanto a Git, he añadido la clave privada generada al fichero ~/.ssh/id_rsa para poderme autenticar mediante el intercambio de claves. He creado un nuevo proyecto va­cío con Git a través de Geppeto configurado a través de la IP asignada a Git y he com­probado que funciona correctamente.

Para probar OpenLDAP me he conectado a través de la IP asignada con el programa Apache Directory Studio que permite la edición de árboles LDAP. He comprobado que todo funciona correctamente ante lecturas y modificaciones.

Para cada servicio he forzado estas situaciones probando que se mantenía la dis­ponibilidad y las modificaciones realizadas:

• Parar el servicio mediante el comando kill.

• Apagar y/o reiniciar el nodo en el que corre el servicio.

• Mover el recurso de nodo mediante el comando “crm resource migrate <nombre_de_recurso>”.

• Mover recursos dependientes del servicio a otro nodo.

• Poner el nodo en el que corre el servicio en standby mediante el comando “crm node standby <nombre_de_nodo>”.

59

60

Conclusiones

ConclusionesLa primera y más importante de las conclusiones es que he conseguido alcanzar

todos los objetivos propuestos. Tanto las decisiones tecnológicas como de diseño han sido adecuadas de cara a la consecución de los mismos.

Ubuntu Server me ha parecido un sistema eficiente, rápido, robusto y ac­tualizado. Sobre todo comparado con otras alternativas como, por ejemplo, CentOS. La instalación de software desde PPA ha supuesto un valor añadido ya que, me ha per­mitido instalar las versiones más actuales de GlusterFS y de Redmine.

El uso de VirtualBox mediante Vagrant junto con Puppet, ha confirmado que es una plataforma excelente para construir nuevas infraestructuras virtualizadas previo al paso a producción. Usar la provisión de configuraciones directamente mediante Vagrant ha supuesto un gran ahorro de tiempo si se compara con el uso de un servidor dedicado a la gestión de configuraciones. Geppeto ha sido extremadamente útil, simplifi­cando el uso de Puppet y Git.

Los módulos de Puppet Forge han sido uno de los puntos negativos. A pesar de existir módulos para muchos de los servicios, he descartado la mayoría por no cubrir la funcionalidad necesaria, ser incompatibles, estar desactualizados o contener errores. Los que he usado, los he aprovechado mínimamente.

A nivel técnico me he encontrado con bastantes problemas que he tenido que solucionar. Ha sido muy importante el uso de Software Libre, ya que me ha per­mitido estudiar y modificar algunos componentes para adaptarlos y corregir fa­llos, acorde con la Libertad 1 de la definición del Software Libre. La buena calidad de la documentación existente también ha sido un punto a favor.

Una de las configuraciones que más me ha costado es la de GlusterFS, que además ha condicionado la forma en la que he tenido que hacer las provisiones con Vagrant. La instalación de Redmine y la copia de los ficheros de base de datos, tam­bién han supuesto una dificultad añadida. Por último, la configuración de OpenL­DAP también me ha resultado difícil debido a mi inexperiencia en este servicio y la complejidad en la configuración del mismo.

En resumen, creo que este trabajo ha servido para conocer más sobre Puppet y configurar de forma automatizada un cluster, algo para lo que se disponen de po­cas referencias hasta la fecha, y ninguna que gestione tantos recursos.

61

62

Bibliografía

BibliografíaWALKERNEWS.NET. How To Create Linux LVM In 3 Minutes [En línea]. 2007. Disponible en World Wide Web: <http://www.walkernews.net/2007/07/02/how-to-create-linux-lvm-in-3-minutes/>.

CHACON, Scott. Pro Git [En línea]. 2009. Disponible en World Wide Web: <https://git-scm.com/book>.

LOUTILITIES. Setting up GIT with Apache Smart HTTP/S and LDAP [En línea]. 2011. Disponible en World Wide Web: <http://loutilities.wordpress.com/2011/08/12/setting-up-git-with-apache-smart-https-and-ldap/>.

GLUSTER, INC. Gluster Documentation [En línea]. 2013. Disponible en World Wide Web: <http://www.gluster.org/community/documentation/index.php/Main_Page>.

HAFERKAMP, Ralf. OpenLDAP in High Availability Environments [En línea]. 2011. Disponible en World Wide Web: <http://ldapcon.org/downloads/Haferkamp-paper.pdf>.

UBUNTU DOCUMENTATION TEAM. Ubuntu Server Guide [En línea]. 2012. Disponible en World Wide Web: <https://help.ubuntu.com/12.04/serverguide/index.html>.

O'DONOVAN, Barry. Multi-Master LDAP Replication [En línea]. 2013. Disponible en World Wide Web: <http://www.opensolutions.ie/blog/2013/01/multi-master-ldap-replication/>.

UBUNTU DOCUMENTATION TEAM. User Documentation [En línea]. 2013. Disponible en World Wide Web: <https://help.ubuntu.com/community>.

PUPPET LABS. Puppet Labs Documentation [En línea]. 2013. Disponible en World Wide Web: <https://docs.puppetlabs.com/>.

VARIOS AUTORES. HowTo Install Redmine in Ubuntu [En línea]. 2013. Disponible en World Wide Web: <http://www.redmine.org/projects/redmine/wiki/HowTo_Install_Redmine_in_Ubuntu>.

VARIOS AUTORES. HowTo Install Redmine on Ubuntu step by step [En línea]. 2013. Disponible en World Wide Web: <http://www.redmine.org/projects/redmine/wiki/HowTo_Install_Redmine_on_Ubuntu_step_by_step>.

63

Bibliografía

HASHIMOTO, Mitchell. Vagrant Documentation [En línea]. 2013. Disponible en World Wide Web: <http://docs-v1.vagrantup.com/v1/docs/index.html>.

ORACLE CORPORATION. Oracle VM VirtualBox User Manual [En línea]. 2013. Disponible en World Wide Web: <https://www.virtualbox.org/manual/>.

ESPINOZA, Felipe. Creating a vagrant base box for Ubuntu 12.04 32bit server [En línea]. 2013. Disponible en World Wide Web: <https://github.com/fespinoza/checklist_and_guides/wiki/Creating-a-vagrant-base-box-for-ubuntu-12.04-32bit-server>.

LIBVIRT.ORG. Libvirt: Documentation [En línea]. 2013. Disponible en World Wide Web: <http://libvirt.org/docs.html>.

BEEKHOF, Andrew. Clusters from Scratch [En línea]. 2012. Disponible en World Wide Web: <http://clusterlabs.org/doc/en-US/Pacemaker/1.1-crmsh/html-single/Clusters_from_Scratch/index.html>.

CLUSTERLABS.ORG. ClusterLabs Documentation [En línea]. 2013. Disponible en World Wide Web: <http://clusterlabs.org/wiki/Documentation>.

HELLMAN, Brian; HAAS, Florian; REISNER, Philipp; ELLENBERG, Lars. The DRBD User's Guide [En línea]. 2012. Disponible en World Wide Web: <https://www.drbd.org/users-guide-8.4/>.

INKTANK STORAGE, INC. Ceph Documentation [En línea]. 2013. Disponible en World Wide Web: <https://ceph.com/docs/master/>.

ROONEY, Mike. Best Practices for a Mission-Critical Jenkins [En línea]. 2012. Disponible en World Wide Web: <http://www.slideshare.net/mrooney7828/best-practices-for-missioncritical-jenkins>.

THE APACHE SOFTWARE FOUNDATION. Versión 2.2 de la documentación del Servidor de HTTP Apache [En línea]. 2013. Disponible en World Wide Web: <https://httpd.apache.org/docs/2.2/>.

THE APACHE SOFTWARE FOUNDATION. Apache Tomcat 7 Documentation [En línea]. 2013. Disponible en World Wide Web: <https://httpd.apache.org/docs/2.2/>.

THE APACHE SOFTWARE FOUNDATION. The Apache Tomcat Connector Documentation [En línea]. 2013. Disponible en World Wide Web: <https://tomcat.apache.org/connectors-doc/>.

JENKINS-CI.ORG. Use Jenkins [En línea]. 2013. Disponible en World Wide Web: <https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins>.

64

Anexo: Vagrantfile

Anexo: Vagrantfile# -*- mode: ruby -*- # vi: set ft=ruby : Vagrant::Config.run do |config|

# Disco compartido config.vm.customize ["createhd", "--filename", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/compartido.vdi", "--size", "1024", "--format", "VDI", "--variant", "Fixed"] config.vm.customize ["modifyhd", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/compartido.vdi", "--type", "shareable"]

# Nodos del cluster config.vm.define :Nodo01 do |nodo01| nodo01.vm.box = "vagrant-precise64" nodo01.vm.host_name = "nodo01.tfg.org" nodo01.vm.boot_mode = :gui nodo01.vm.customize ["modifyvm", :id, "--name", "Nodo01"] nodo01.vm.customize ["modifyvm", :id, "--ioapic", "on"] nodo01.vm.customize ["modifyvm", :id, "--cpus", 2] nodo01.vm.customize ["modifyvm", :id, "--memory", 2048] nodo01.vm.customize ["modifyvm", :id, "--nic1", "nat"] nodo01.vm.customize ["modifyvm", :id, "--nictype1", "82545EM"] nodo01.vm.customize ["modifyvm", :id, "--nic2", "hostonly"] nodo01.vm.customize ["modifyvm", :id, "--macaddress2", "08002758b131"]

nodo01.vm.customize ["modifyvm", :id, "--nictype2", "82545EM"] nodo01.vm.network :hostonly, "192.168.2.11", :netmask => "255.255.255.0", :adapter => 2 nodo01.vm.customize ["modifyvm", :id, "--nic3", "intnet"] nodo01.vm.customize ["modifyvm", :id, "--macaddress3", "08002725f8ea"]

nodo01.vm.customize ["modifyvm", :id, "--nictype3", "82545EM"] nodo01.vm.customize ["modifyvm", :id, "--audio", "none"] nodo01.vm.customize ["modifyvm", :id, "--usb", "off"] nodo01.vm.customize ["modifyvm", :id, "--usbehci", "off"]

# Disco para GlusterFS nodo01.vm.customize ["createhd", "--filename", "/media/Hitachi

65

Anexo: Vagrantfile

Datos/twenty/GII/TFG/vagrant/Nodo01/gluster.vdi", "--size", "2048", "--format", "VDI", "--variant", "Standard"] nodo01.vm.customize ["storageattach", :id, "--storagectl", "SATA", "--port", "1", "--device", "0", "--type", "hdd", "--medium", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/Nodo01/gluster.vdi"]

# Disco compartido config.vm.customize ["storageattach", :id, "--storagectl", "SATA", "--port", "2", "--device", "0", "--type", "hdd", "--medium", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/compartido.vdi"] end

config.vm.define :Nodo02 do |nodo02| nodo02.vm.box = "vagrant-precise64" nodo02.vm.host_name = "nodo02.tfg.org" nodo02.vm.boot_mode = :gui nodo02.vm.customize ["modifyvm", :id, "--name", "Nodo02"] nodo02.vm.customize ["modifyvm", :id, "--ioapic", "on"] nodo02.vm.customize ["modifyvm", :id, "--cpus", 2] nodo02.vm.customize ["modifyvm", :id, "--memory", 2048] nodo02.vm.customize ["modifyvm", :id, "--nic1", "nat"] nodo02.vm.customize ["modifyvm", :id, "--nictype1", "82545EM"] nodo02.vm.customize ["modifyvm", :id, "--nic2", "hostonly"] nodo02.vm.customize ["modifyvm", :id, "--macaddress2", "0800273c6547"]

nodo02.vm.customize ["modifyvm", :id, "--nictype2", "82545EM"] nodo02.vm.network :hostonly, "192.168.2.12", :netmask => "255.255.255.0", :adapter => 2 nodo02.vm.customize ["modifyvm", :id, "--nic3", "intnet"] nodo02.vm.customize ["modifyvm", :id, "--macaddress3", "080027aade79"]

nodo02.vm.customize ["modifyvm", :id, "--nictype3", "82545EM"] nodo02.vm.customize ["modifyvm", :id, "--audio", "none"] nodo02.vm.customize ["modifyvm", :id, "--usb", "off"] nodo02.vm.customize ["modifyvm", :id, "--usbehci", "off"]

# Disco para GlusterFS nodo02.vm.customize ["createhd", "--filename", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/Nodo02/gluster.vdi", "--size", "2048", "--format", "VDI", "--variant", "Standard"] nodo02.vm.customize ["storageattach", :id, "--storagectl", "SATA", "--

66

Anexo: Vagrantfile

port", "1", "--device", "0", "--type", "hdd", "--medium", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/Nodo02/gluster.vdi"]

# Disco compartido nodo02.vm.customize ["storageattach", :id, "--storagectl", "SATA", "--port", "2", "--device", "0", "--type", "hdd", "--medium", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/compartido.vdi"] end

config.vm.define :Nodo03 do |nodo03| nodo03.vm.box = "vagrant-precise64" nodo03.vm.host_name = "nodo03.tfg.org" nodo03.vm.boot_mode = :gui nodo03.vm.customize ["modifyvm", :id, "--name", "Nodo03"] nodo03.vm.customize ["modifyvm", :id, "--ioapic", "on"] nodo03.vm.customize ["modifyvm", :id, "--cpus", 2] nodo03.vm.customize ["modifyvm", :id, "--memory", 2048] nodo03.vm.customize ["modifyvm", :id, "--nic1", "nat"] nodo03.vm.customize ["modifyvm", :id, "--nictype1", "82545EM"] nodo03.vm.customize ["modifyvm", :id, "--nic2", "hostonly"] nodo03.vm.customize ["modifyvm", :id, "--macaddress2", "080027a17725"]

nodo03.vm.customize ["modifyvm", :id, "--nictype2", "82545EM"] nodo03.vm.network :hostonly, "192.168.2.13", :netmask => "255.255.255.0", :adapter => 2 nodo03.vm.customize ["modifyvm", :id, "--nic3", "intnet"] nodo03.vm.customize ["modifyvm", :id, "--macaddress3", "08002770aa53"]

nodo03.vm.customize ["modifyvm", :id, "--nictype3", "82545EM"] nodo03.vm.customize ["modifyvm", :id, "--audio", "none"] nodo03.vm.customize ["modifyvm", :id, "--usb", "off"] nodo03.vm.customize ["modifyvm", :id, "--usbehci", "off"]

# Disco para GlusterFS nodo03.vm.customize ["createhd", "--filename", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/Nodo03/gluster.vdi", "--size", "2048", "--format", "VDI", "--variant", "Standard"] nodo03.vm.customize ["storageattach", :id, "--storagectl", "SATA", "--port", "1", "--device", "0", "--type", "hdd", "--medium", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/Nodo03/gluster.vdi"]

67

Anexo: Vagrantfile

# Disco compartido nodo03.vm.customize ["storageattach", :id, "--storagectl", "SATA", "--port", "2", "--device", "0", "--type", "hdd", "--medium", "/media/Hitachi Datos/twenty/GII/TFG/vagrant/compartido.vdi"] end

# Provisión de configuraciones con Puppet config.vm.provision :puppet, :module_path => "/media/Hitachi Datos/twenty/GII/TFG/workspace/configuraciones/modules", :options => "--verbose" do |puppet| puppet.manifests_path = "/media/Hitachi Datos/twenty/GII/TFG/workspace/configuraciones/manifests" puppet.manifest_file = "site.pp" endend

68

Anexo: Configuración de Pacemaker

Anexo: Configuración de Pacemakernode nodo01.tfg.org \ attributes standby="off" node nodo02.tfg.org \ attributes standby="off" node nodo03.tfg.org \ attributes standby="off" primitive ApacheServer ocf:heartbeat:apache \ op stop interval="0" timeout="60s" \ op start interval="0" timeout="40s" \ op monitor interval="30s" timeout="30s" \ params configfile="/etc/apache2/apache2.conf" httpd="/usr/sbin/apache2" statusurl="http://127.0.0.1/server-status" primitive CompartidoBloques ocf:heartbeat:Filesystem \ op stop interval="0" timeout="60s" \ op start interval="0" timeout="60s" \ op monitor interval="10s" timeout="60s" \ params fstype="ext4" directory="/mnt/compartidobloques" device="/dev/VGCompartidoBloques/LVCompartidoBloques" primitive GlusterFSExport ocf:heartbeat:Filesystem \ op stop interval="0" timeout="60s" \ op monitor interval="10s" timeout="60s" \ op start interval="0" timeout="60s" \ params fstype="xfs" directory="/export/glusterfs" device="/dev/VGGlusterFS/LVGlusterFS" primitive GlusterFSServer upstart:glusterfs-server \ op monitor interval="10s" timeout="30s" \ op start interval="0" timeout="30s" start-delay="1s" primitive GlusterFSVolume ocf:heartbeat:Filesystem \ op stop interval="0" timeout="60s" \ op start interval="0" timeout="60s" start-delay="5s" \ op monitor interval="20s" timeout="60s" \ params fstype="glusterfs" directory="/mnt/GlusterFS" device="localhost:/VolumeGlusterFS" primitive IPApache ocf:heartbeat:IPaddr2 \ op monitor interval="30s" \ params cidr_netmask="24" ip="192.168.2.110" nic="eth1" primitive IPGit ocf:heartbeat:IPaddr2 \ op monitor interval="30s" \

69

Anexo: Configuración de Pacemaker

params cidr_netmask="24" ip="192.168.2.130" nic="eth2" primitive IPLDAP ocf:heartbeat:IPaddr2 \ op monitor interval="30s" \ params cidr_netmask="24" ip="192.168.2.150" nic="eth1" primitive IPMySQL ocf:heartbeat:IPaddr2 \ op monitor interval="30s" \ params cidr_netmask="24" ip="192.168.250.140" nic="eth2" primitive IPTomcat ocf:heartbeat:IPaddr2 \ op monitor interval="30s" \ params cidr_netmask="24" ip="192.168.250.120" nic="eth2" primitive MySQLServer ocf:heartbeat:mysql \ op stop interval="0" timeout="120s" \ op monitor interval="10s" timeout="30s" \ op start interval="0" timeout="120s" \ params datadir="/mnt/compartidobloques/mysql" additional_parameters="--bind-address=192.168.250.140" binary="/usr/sbin/mysqld" primitive Slapd lsb:slapd \ op monitor interval="10s" timeout="30s" \ op start interval="0" timeout="30s" start-delay="1s" primitive TomcatServer lsb:tomcat7 \ op stop interval="0" timeout="15s" \ op start interval="0" timeout="15s" \ op monitor interval="10s" timeout="30s" group Apache IPApache ApacheServer group Git IPGit group GlusterFS GlusterFSExport GlusterFSServer GlusterFSVolume group LDAP IPLDAP group MySQL IPMySQL CompartidoBloques MySQLServer group Tomcat IPTomcat TomcatServer clone CloneGlusterFS GlusterFS clone CloneSlapd Slapd colocation ApacheCloneGlusterFSColocation inf: Apache CloneGlusterFS colocation GitCloneGlusterFSColocation inf: Git CloneGlusterFS colocation LDAPCloneSlapd inf: LDAP CloneSlapd colocation TomcatCloneGlusterFSColocation inf: Tomcat CloneGlusterFS order ApacheOrder inf: MySQL Apache order GitOrder inf: CloneGlusterFS Git order LDAPOrder inf: CloneSlapd LDAP order TomcatOrder inf: CloneGlusterFS Tomcat property $id="cib-bootstrap-options" \ dc-version="1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c" \

70

Anexo: Configuración de Pacemaker

cluster-infrastructure="openais" \ expected-quorum-votes="3" \ no-quorum-policy="stop" \ stonith-enabled="false"

71

72

Anexo: Planificación

Anexo: PlanificaciónEn este anexo describo las tareas, les asigno un tiempo estimado y planteo las fechas

de los hitos más destacados.

El TFG tiene una duración de 300 horas de trabajo. A continuación detallo las horas de las tareas.

ObjetivosConsiste en la redacción de los objetivos del TFG. Los hitos de esta tarea son:

• Inicio: 2013-01-28

• Fin: 2013-02-01

La duración estimada es de 4 horas.

Análisis y diseñoConsiste en la creación del análisis y diseño para conseguir los objetivos marcados.

Los hitos de esta tarea son:

• Inicio: 2013-02-02

• Fin: 2013-02-15

La duración estimada es de 18 horas.

PlanificaciónConsiste en la creación de la planificación estableciendo las tareas, los hitos y las esti­

maciones de tiempo. Los hitos de esta tarea son:

• Inicio: 2013-02-11

• Fin: 2013-02-15

La duración estimada es de 4 horas.

ConstrucciónConsiste en la creación de la infraestructura siguiendo las pautas marcadas en el aná­

lisis y diseño. Los hitos de esta tarea son:

73

Anexo: Planificación

• Inicio: 2013-02-16

• Fin: 2013-05-03

La construcción se divide en las siguientes subtareas y sus tiempos estimados:

• Creación de la instalación base y la box para Vagrant: 12 horas.

• Configuración de la plataforma virtual con Vagrant: 16 horas.

• Configuración inicial de Corosync y Pacemaker: 6 horas.

• Configuración de GlusterFS: 14 horas.

• Configuración de OpenLDAP: 24 horas.

• Configuración de MySQL: 14 horas.

• Configuración de Git: 6 horas.

• Configuración de Apache: 10 horas.

• Configuración de Redmine: 12 horas.

• Configuración de Tomcat: 8 horas.

• Configuración de Jenkins: 8 horas.

La duración total estimada es de 130 horas.

MemoriaConsiste en la redacción, maquetación y formato de la memoria, incluyendo sus revi­

siones y el proceso de depósito. El proceso de redacción transcurre en paralelo con el res­to de tareas. Los hitos de esta tarea son:

• Inicio: 2013-01-28

• Entrega al director: 2013-05-23. Este hito supone entregar la primera versión final de la memoria. A partir de este momento se revisará pudiendo incluir modi­ficaciones.

• Fin: 2013-06-06

• Depósito: 2013-06-07 – 2013-06-14

La duración estimada es de 90 horas.

DefensaConsiste en la preparación de la defensa y los ensayos. Los hitos de esta tarea son:

74

Anexo: Planificación

• Inicio: 2013-05-24

• Fin: 2013-06-17 – 2013-06-28

La duración estimada es de 42 horas.

ReunionesConsiste en la preparación, las entrevistas con el director de proyecto y la redacción

de actas. Los hitos de esta tarea son:

• Primera reunión: 2013-02-22

• Segunda reunión: 2013-02-26

• Tercera reunión: 2013-03-26

• Cuarta reunión: 2013-04-30

• Quinta reunión: 2013-05-28

La duración estimada es de 12 horas.

75