TRABAJO FIN DE GRADO. Infraestructura virtual, automatizada y en alta disponibilidad de una plataforma integral para equipos de desarrollo

Transcripción

1 TRABAJO FIN DE GRADO Título Infraestructura virtual, automatizada y en alta disponibilidad de una plataforma integral para equipos de desarrollo Autor/es Francisco Sariego Rodríguez Director/es Francisco José García Izquierdo Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación Grado en Ingeniería Informática Departamento Curso Académico

2 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 (publicado por 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. El autor Universidad de La Rioja, Servicio de Publicaciones, 2013 publicaciones.unirioja.es publicaciones@unirioja.es

3 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 Rioja Facultad de Ciencias, Estudios Agroalimentarios e Informática Logroño, Junio de 2013

4

5 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 incidencias y una herramienta de Integración Continua. He cubierto estas necesidades, respectivamente, 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 virtuales con el sistema operativo Ubuntu Server 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 respetando siempre el principio de simplicidad. Para el almacenamiento compartido basado en ficheros he usado GlusterFS. También he creado un dispositivo de almacenamiento virtual asociado a las máquinas virtuales que he usado para el almacenamiento 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 forma he automatizado toda la configuración, consiguiendo que sea replicable a partir 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 creació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 resultado 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 pueden 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 ofrecidos. Palabras clave: automatización, alta disponibilidad, Vagrant, Puppet, Pacemaker, GlusterFS, Ubuntu Server. 3

6 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 system, 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 installed these services on virtual machines with the operating system Ubuntu Server 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 strategy 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 simplicity. 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 automated all settings, getting them replicable from a clean operating system installation. 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

7 Índice de contenido Objetivos...7 Análisis y Diseño...9 Sistema operativo...9 Servicios...10 OpenLDAP...10 Git...10 Redmine...11 Jenkins...12 Apache...12 Alta disponibilidad...12 Software de gestión del cluster...14 Diseño de alta disponibilidad del almacenamiento...15 Diseño de alta disponibilidad de MySQL...18 Diseño de alta disponibilidad de OpenLDAP...18 Diseño de alta disponibilidad de Git...19 Diseño de alta disponibilidad de Redmine...20 Diseño de alta disponibilidad de Jenkins...20 Automatización...21 Virtualización...22 Automatización en VirtualBox: Vagrant...22 Diseño de la infraestructura virtual...23 Construcción...25 Creación de la instalación base y la box de Vagrant...25 Empaquetado y distribución...26 Configuración de la plataforma virtual con Vagrant...27 Almacenamiento compartido...27 Definición de las máquinas virtuales...27 Provisión de configuraciones...29 Control de la plataforma virtual...30 Configuraciones generales con Puppet...31 Organización de las configuraciones...31 Distribución de ficheros...32 Configuración de la red...32 Configuración de rsyslog...35 Configuración de AppArmor...35 Configuración básica del almacenamiento LVM...35 Configuración inicial de Corosync y Pacemaker

8 Recursos y restricciones...38 Primera configuración de Pacemaker...39 Configuración de GlusterFS...40 Instalación de los paquetes y configuración del servicio...40 Reconocimiento de los peers de GlusterFS...41 Creación del volumen de réplica y montaje...42 Configuración de Pacemaker para GlusterFS...43 Configuración inicial de MySQL...44 Configuración de Pacemaker para MySQL...45 Configuración de AppArmor para MySQL...46 Configuración de Git...46 Configuración de Pacemaker para Git...48 Configuración inicial de Apache...48 Configuración de Pacemaker para Apache...49 Configuración de Redmine...49 Configuración de MySQL para Redmine...50 Configuración de Apache para Redmine...51 Configuración de Pacemaker para Redmine...52 Configuración de Tomcat...52 Configuración de Apache para Tomcat...53 Configuración de Jenkins...54 Configuración de Pacemaker para Jenkins...55 Configuración de OpenLDAP...55 Configuración TLS...56 Replicación multi-maestro...57 Configuración de Pacemaker para OpenLDAP...58 Pruebas...59 Conclusiones...61 Bibliografía...63 Anexo: Vagrantfile...65 Anexo: Configuración de Pacemaker...69 Anexo: Planificación...73 Objetivos...73 Análisis y diseño...73 Planificación...73 Construcción...73 Memoria...74 Defensa...74 Reuniones

9 Objetivos Objetivos El Trabajo Fin de Grado (en lo sucesivo, TFG) consistirá en el diseño y construcció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 disponibilidad. Deberá evitarse, en la medida de lo posible, la existencia de puntos únicos de fallo. Los usuarios tendrán la posibilidad de usar los servicios mediante protocolos seguros. La infraestructura estará construida sobre máquinas virtuales. En caso de ser necesario, será posible la incorporación de hardware ajeno a las máquinas virtuales 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 aplicadas 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 documentació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 tipografí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 libres. El TFG se ceñirá únicamente al diseño de la infraestructura y la administració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

10 8

11 Análisis y Diseño Análisis y Diseño En este capítulo explico las decisiones que he tomado para la consecución de los objetivos 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, servicios, alta disponibilidad, automatización y virtualización. A continuación desarrollo cada uno de estos puntos por separado. Sistema operativo El sistema operativo que he elegido para los servidores es Ubuntu Server bits. Este sistema operativo GNU/Linux está especialmente indicado para montar infraestructuras virtuales en entornos de producción ya que provee software actualizado pero lo suficientemente probado y estable. La versión proporciona soporte durante 5 años, prolongándose hasta Abril de 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, ). 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 innecesarios de microprocesador, memoria y almacenamiento. Esta política evita las actualizaciones 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 paradas de servicio. Otra característica interesante de LVM es la posibilidad de realizar instantáneas ( snapshots ) sobre los sistemas de almacenamiento que pueden ser aprovechadas, por ejemplo, para realizar copias de seguridad. Las características de la instalación serán estas: Idioma: Español ( Castellano ). 9

12 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. Servicios A continuación describo el software necesario a instalar y configurar en los servidores para poder ofrecer los servicios básicos enumerados en los objetivos. OpenLDAP El 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 necesarios los certificados de una CA (Certificate Authority). Git Como 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 licencia 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 repositorios locales. Git no es en sí un servicio que deba ejecutarse en un servidor para dar acceso a sus clientes, sino que se basa en una estructura de directorios que es servida mediante servicios externos. En el servidor debe existir un repositorio remoto que es generalmente 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

13 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 rendimiento, 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 configurar 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. Redmine Redmine es una aplicación web que sirve para la gestión de proyectos, el seguimiento 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 diferentes 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 necesaria 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 paquetes 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 distribuye con la licencia libre MIT License. 11

14 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. Jenkins Jenkins es una aplicación web que sirve como herramienta de integración continua. 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 contenedores 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. Apache El 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 disponibilidad Uno 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

15 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 tanto, 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 propensos 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 posibilidad 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 recursos. 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 configurar 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 cluster, 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

16 Análisis y Diseño nodo01: con la dirección /24. nodo02: con la dirección /24. nodo03: con la dirección /24. Software de gestión del cluster En un cluster es necesario que exista un coordinador entre los nodos que tome las decisiones, 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 Pacemaker 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 implementació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 aislada 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: /24. Dirección del nodo01: Dirección del nodo02: Dirección del nodo03: Pacemaker es el gestor de los recursos del cluster. Es el encargado de determinar en qué nodos se ejecutarán los servicios y según qué configuración y políticas. También se encarga de la monitorización tanto de los nodos como de los recursos para determinar 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

17 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 ejecute en rol Esclavo y que sólo permita lecturas. En el TFG sólo usaré las dos primeras. Diseño de alta disponibilidad del almacenamiento Aunque 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 ficheros Para definir la estrategia del almacenamiento compartido basado en ficheros he decidido usar GlusterFS. Es un sistema de archivos distribuido basado en la arquitectura cliente/servidor. Los servidores se agrupan en bricks y cada uno ejecuta un servicio glusterfs-server exportando un sistema de ficheros local como un volumen. Los clientes ejecutan un servicio glusterfs que se conecta a los servidores 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 replicados, segmentados ( striping ), o tolerantes a fallos ( fail-over ). 15

18 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 dependencias 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 servicios. Con estos requisitos, el diseño propuesto para el almacenamiento es el siguiente: Todos los nodos ejecutarán el servicio glusterfs-server. Todos los pasos siguientes deben realizarse en todos los nodos. Existirá un dispositivo de almacenamiento en bloques dedicado al almacenamiento 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 partició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 bloque El 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

19 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 nodos 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 arquitecturas 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 bloques compartido entre los nodos. Esta decisión introduce una dependencia externa 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 sistemas de ficheros son complejos de instalar y administrar. Teniendo en cuenta que el único servicio que hará uso del almacenamiento compartido 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 almacenamiento 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 partición se creará un volume group llamado VGCompartidoBloques y un logical volume llamado LVCompartidoBloques que ocupen todo su espacio. 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

20 Análisis y Diseño La ruta de montaje será /mnt/compartidobloques. Diseño de alta disponibilidad de MySQL MySQL tampoco es uno de los servicios identificados como objetivo, aunque merece la pena realizar un diseño pensando exclusivamente en él. MySQL ofrece dos soluciones 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í mayor 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 realizados en uno de los nodos, considerado como maestro, al resto de nodos, llamados esclavos. Esta configuración se puede gestionar con Pacemaker, que es capaz de conmutar los roles maestro y esclavo en caso de caídas. Sin embargo, mi experiencia anterior 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 detalles 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 compartido 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 en la interfaz 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 OpenLDAP El diseño de alta disponibilidad de OpenLDAP lo he basado en una arquitectura híbrida. El servicio sólo estará disponible a través de un único nodo median 18