PROYECTO FINAL DE CARRERA

Transcripción

1 ESCOLA POLITÈCNICA SUPERIOR UNIVERSITAT DE LES ILLES BALEARS PROYECTO FINAL DE CARRERA Estudios: Ingeniería Informática Título: Escalabilidad y alta disponibilidad en el servicio de educación virtual de la Universitat de les Illes Balears Directores: Dr. Ricardo Galli Granada Pr. Antoni Mas Mulet Alumno: Alejandro Sobrino Beltrán Fecha: 8 de febrero de 2012

2

3 El Dr. Ricardo Galli Granada y el Pr. Antoni Mas Mulet hacen constar que este proyecto, Escalabilidad y alta disponibilidad en el servicio de educación virtual de la Universitat de les Illes Balears, realizado por Alejandro Sobrino Beltrán, está nalizado bajo su dirección y puede pasar a la fase de evaluación. Palma, 8 de febrero de Firmas

4

5 Agradecimientos En primer lugar, deseo agradecer a mis directores de proyecto, Ricardo Galli y Antoni Mas, por brindarme la oportunidad de realizar este proyecto y aprender de él. A todos mis compañeros de trabajo y de carrera por todo lo que he aprendido junto a ellos, tanto a nivel profesional como personal. ½Gracias! Dedicado a mi madre María, a mi abuelo Juan y a Eugenia. Sin ellos, jamás habría sido posible.

6

7 Índice general 1. Introducción El problema Objetivos del proyecto Estructura del documento Estado del arte Escalabilidad y alta disponibilidad Escalabilidad y rendimiento Tolerancia a fallos y redundancia Medición de la disponibilidad Virtualización Introducción Paravirtualización Ventajas e inconvenientes Virtualización con Xen Virtualización con VMware Escalado y alta disponibilidad en servidores web Arquitectura cliente-servidor Introducción a los servidores web Escalabilidad Alta disponibilidad Herramientas de análisis de rendimiento web Balanceo de tráco Introducción Round Robin DNS Balanceadores de tráco Algoritmos de balanceo Sistemas de cheros Introducción Sistemas de cheros distribuidos Sistemas de cheros de disco compartido

8 8 ÍNDICE GENERAL Herramientas de análisis de rendimiento Escalado y alta disponibilidad en servidores de BBDD Introducción a las bases de datos Introducción a los sistemas gestores de bases de datos Escalabilidad Alta disponibilidad El servicio de educación virtual de la UIB Introducción a Moodle Apache PHP MySQL Evolución de la arquitectura Primeras pruebas con Moodle Migración a Moodle en la UIB Dos servidores, principios de redundancia Uso de la plataforma Análisis de la problemática Casos típicos Infraestructura tecnológica de virtualización Servicios web Servidores web virtualizados Introducción Escalabilidad y alta disponibilidad Proceso de migración Denición de los servidores virtuales Instalación y conguración del sistema operativo Instalación y conguración de OCFS Instalación y conguración del servidor Apache, PHP5 y eaccelerator Instalación y conguración del software Moodle de pruebas Conguración del balanceador Realización de pruebas de rendimiento Migración de datos reales Migración de los portales Balanceo de tráco Balanceador de tráco por software Balanceador de tráco por hardware Problemas encontrados

9 ÍNDICE GENERAL 9 5. Análisis de sistemas de cheros Análisis de la problemática Sincronización periódica Network File System (NFS) Pruebas de rendimiento Escalabilidad Alta disponibilidad Oracle's Cluster File System v.2 (OCFS2) Análisis de rendimiento de NFS y OCFS EXT NFS OCFS Conclusiones Escalabilidad y alta disponibilidad en MySQL Introducción a MySQL Escalabilidad en MySQL Replicación Sharding MySQL Cluster Alta disponibilidad en MySQL Replicación + Heartbeat MySQL Cluster Análisis y propuesta de arquitectura Administración de los servidores Análisis de la problemática Munin Monit Plan de contingencia Conclusiones y trabajo futuro Arquitectura nal Consecución de los objetivos Experiencia personal Trabajo futuro Índice de guras 159 Índice de cuadros 163 Bibliografía 165

10 10 ÍNDICE GENERAL Acrónimos 169 A. Glosario 171 B. Ldirectord. Instalación y conguración 177 B.1. Información previa B.2. Paquetes necesarios y conguración previa B.3. Conguración de heartbeat B.4. Conguración de ldirectord B.4.1. Comprobaciones B.5. Conguración de los servidores web C. OCFS2. Instalación y conguración 187 C.1. Información previa C.2. Paquetes necesarios C.3. Denición del clúster C.4. Formatear una partición C.5. Propagar la conguración C.6. Comprobar los servicios C.7. Montar la partición D. Funcionamiento de MySQL 195 D.1. Control de concurrencia D.1.1. Bloqueo de tablas D.1.2. Bloqueo de las D.2. Binary Log D.3. Transacciones D.3.1. Bloqueos mutuos D.4. Sistemas de almacenamiento

11 Capítulo 1 Introducción Cada día aumenta el número de servicios que dependen de sistemas informáticos. Esta importancia lleva a empresas, instituciones y a cualquier organización o persona que preste servicios a través de Internet, a implantar tecnologías que aseguren una escalabilidad y disponibilidad alta de sus servicios. Para ello, se ven obligados a aumentar continuamente el nivel de tolerancia a fallos de su infraestructura tecnológica. Hablar de un buen servicio a través de Internet implica: Un tiempo de respuesta razonablemente bajo. Tiempos de respuesta entre los 100 y 250 ms se consideran adecuados. Una velocidad de transferencia aceptable. Según el servicio, la velocidad de transferencia puede variar. Una disponibilidad del servicio muy elevada, mayor al 90 %. El servicio de educación virtual de la Universitat de les Illes Balears (UIB) no es una excepción. El principal objetivo de toda universidad es formar correctamente a sus alumnos. La plataforma de educación virtual es una herramienta que permite complementar las clases presenciales tradicionales y extender la formación ofrecida a más personas. A lo largo de este documento se explica el servicio de educación virtual de la UIB, el constante crecimiento que ha sufrido y cómo se pretende adaptar toda la infraestructura tecnológica para proporcionar escalabilidad y alta disponibilidad al servicio. A lo largo de este primer capítulo se realiza una breve descripción del problema que ha motivado la realización de este proyecto. A continuación, se describen los objetivos principales del proyecto y, para nalizar, la estructura de este documento. 11

12 El problema 1.1. El problema La UIB posee un servicio de educación virtual desde el curso académico Esta plataforma de educación ha ido sufriendo constantes cambios desde entonces. Durante el curso académido , se produce el primer cambio importante, con mejoras tanto a nivel de software como de hardware. Debido a la importancia, crecimiento y uso de la plataforma, a lo largo del año 2008 se produce el segundo cambio, dotando de más hardware al servicio. Desde el año 2008 la arquitectura se ha mantenido. Cada año, con el comienzo del curso académico y debido a su habitual evolución, se aumenta el número de asignaturas presentes en el campus de educación virtual. Este incremento es difícil de predecir, ya que no depende únicamente de las asignaturas que se incorporan, sino también del número de alumnos matriculados en cada una de las asignaturas presentes en el servicio. Además, con el proceso de reforma educativa realizado por la implantación del Plan de Bolonia[37] durante el curso , el uso del servicio se ha visto incrementado. Con esta reforma, se aumentan el número de horas de educación virtual y se establece una limitación en número de personas inscritas en cada grupo de cada asignatura. Estos aumentos han sido mucho mayores que años anteriores, dejando la antigua infraestructura del año 2008 obsoleta, además de hacer prácticamente imposible estimar el crecimiento que necesitaría la plataforma de educación virtual. Es por ello que se originó la petición del diseño e implantación de una nueva arquitectura para el servicio de educación virtual basado en Moodle[35]. Ésta debe maximizar los tiempos de disponibilidad y ofrecer la posibilidad de crecer fácilmente en función de las necesidades del servicio Objetivos del proyecto El principal objetivo del proyecto es diseñar e implantar una nueva arquitectura para el servicio de educación virtual de la UIB. Los objetivos de forma desglosada son: Diseñar e implantar una arquitectura de servidores web virtualizados. Diseñar e implantar una arquitectura de servidores de base de datos virtualizados. Estas dos arquitecturas deben ser escalables de forma sencilla. Es decir, se debe poder aumentar fácilmente su capacidad de atender clientes. Implantar técnicas de alta disponibilidad en el servicio.

13 1. Introducción Estructura del documento La documentación de este proyecto está estructurada en los siguientes capítulos: Capítulo 2. Estado del arte": en este capítulo se exponen una serie de tecnologías y conceptos que son necesarios conocer para poder realizar cada uno de los objetivos del proyecto. En concreto, se proporcionan conceptos y soluciones tecnológicas para: escalabilidad y alta disponibilidad, virtualización, escalado y alta disponibilidad en servidores web, balanceo de tráco, sistemas de cheros, y escalado y alta disponibilidad en servidores de Base de Datos (BBDD). Capítulo 3. El servicio de educación virtual de la UIB": donde se realiza una introducción a Moodle y una descripción de la evolución de la arquitectura de educación virtual. Para nalizar, se efectúa un breve análisis de la problemática de la arquitectura actual. Capítulo 4. Servicios web": en este capítulo se analiza la escalabilidad y alta disponibilidad en servidores web. Posteriormente, se describe la migración realizada así como las soluciones de balanceo de tráco utilizadas. Capítulo 5. Análisis de sistemas de cheros": se describen brevemente los tipos de sistemas de cheros, así como diversas pruebas de rendimiento efectuadas para poder compartir la misma información entre los servidores web. Capítulo 6. Escalabilidad y alta disponibilidad en MySQL": en este capítulo se realiza una breve introducción a MySQL, además de analizar las posibles soluciones para proporcionar un sistema de BBDD escalable y con una alta disponibilidad. Capítulo 7. Administración de los servidores": se describen las herramientas utilizadas para monitorizar y administrar los servidores. Capítulo 8. Conclusiones": donde se dan a conocer las conclusiones extraídas con la nalización del proyecto. Además, se han incluido una serie de apéndices que completan la información proporcionada en los capítulos descritos anteriormente. En concreto, éstos son: Apéndice A. Acrónimos y deniciones", Apéndice B. Ldirectord. Instalación y conguración", Apéndice C. OCFS2. Instalación y conguración" y Apéndice D. Funcionamiento de MySQL".

14

15 Capítulo 2 Estado del arte El proyecto consiste en desarrollar una nueva arquitectura escalable y de alta disponibilidad en el servicio de educación virtual de la UIB. Se encuentra estructurado en tres partes fundamentales, cada una de ellas puede implantarse utilizando diferentes tecnologías. A tal efecto, es necesario realizar un análisis del estado del arte que permita conocer las posibles soluciones antes de analizar especícamente la solución elegida. Todo el proyecto se realiza sobre un entorno de virtualización de servidores. Por ello, es fundamental hacer una introducción a la virtualización y analizar las diferentes alternativas de virtualización de servidores disponibles actualmente. A continuación, se describen brevemente las partes que lo componen: Alta disponibilidad en servidores web: se realiza mediante la redundancia de servidores y el balanceo del tráco entre ellos. Existen diversos algoritmos de balanceo y su elección determinará la carga que recibirá cada uno de los servidores. Previamente, y con el n de comprender las necesidades tecnológicas, es necesario conocer los términos escalabilidad, alta disponibilidad, redundancia y tolerancia a fallos. Sistemas de archivos: para compartir la información entre los distintos servidores web es necesario utilizar un sistema de cheros que lo permita. En concreto, el entorno de educación virtual es totalmente dinámico a nivel de cheros y por tanto será necesario medir el rendimiento de los diferentes sistemas de cheros, tanto distribuidos como de disco compartido. Para poder elaborar pruebas de rendimiento sobre los sistemas de cheros evaluados será necesario analizar previamente alguna de las herramientas disponibles para tal n. Alta disponibilidad en el Sistema Gestor de Base de Datos 15

16 Escalabilidad y alta disponibilidad (SGBD) MySQL: existen diferentes técnicas disponibles para MySQL que proporcionan escalabilidad y alta disponibilidad al servicio. Algunas de estas soluciones son propias de MySQL y otras están proporcionadas por terceros. Es importante que la solución elegida se adapte al entorno de educación virtual de la UIB Escalabilidad y alta disponibilidad La escalabilidad de un sistema informático indica su capacidad para crecer sin perder calidad en los servicios ofrecidos. Es decir, la suciencia de dicho sistema informático de variar su tamaño, características y capacidad de servicios para adaptarse a una nueva situación. Existen dos tipos de escalabilidad: Vertical: se añaden más recursos a un servidor del sistema en particular, representado en la Figura 2.1. Se consideran recursos los componentes del servidor, tales como memoria, disco duro, procesador, entre otros. Figura 2.1: Escalabilidad vertical. Fuente: propia. Horizontal: se añaden más servidores con la misma funcionalidad al sistema, redistribuyendo la carga entre todos ellos, tal y como se puede apreciar en la Figura 2.2. El principal problema de la escalabilidad es estimar cuanta carga deberá soportar el sistema. Proporcionar una cifra exacta es complicado y se deben

17 2. Estado del arte 17 Figura 2.2: Escalabilidad horizontal. Fuente: propia. realizar estimaciones. Si la cifra se sobreestima, se desperdiciarán recursos y si se subestima, el sistema no estará preparado para soportar el aumento de carga. Si se trata de un sistema cuya carga es muy elevada el principal problema de la escalabilidad vertical es el coste. Existe un catálogo de hardware que ofrece una buena relación entre rendimiento y precio. Fuera de ese rango, los servidores que ofrecen un mejor rendimiento tienen un coste mucho más elevado. Por último, existe un límite físico en la escalabilidad vertical que viene denido por el hardware. El concepto de alta disponibilidad de un sistema informático consiste en que el servicio ofrecido esté el mayor tiempo posible funcionando. Lo ideal

18 Escalabilidad y alta disponibilidad es que un servicio esté disponible 24 horas al día, 7 días a la semana, los 365 días del año, ofreciendo un 100 % de disponibilidad. Este caso ideal es prácticamente imposible de implantar, ya que se depende de un hardware y software que tienden a fallar tarde o temprano. Además, establecer una alta disponibilidad en un servicio conlleva unos costes elevados. Se deberá encontrar un equilibrio entre los costes asociados y la alta disponibilidad que se consigue Escalabilidad y rendimiento Entendemos como rendimiento informático la medida o cuanticación de la velocidad con que se realiza una tarea o se ejecuta un proceso determinado. Este rendimiento, bien sea del sistema o de alguno de sus componentes, se mide a través de la ejecución de un benchmark. Si bien los términos escalabilidad y rendimiento están relacionados, cabe señalar la diferencia existente entre ambos: según su denición, escalar un sistema informático hace que aumente su rendimiento global y sin embargo, puede provocar un descenso del rendimiento individual de uno de los nodos del sistema. Se debe intentar encontrar un equilibrio entre el aumento de rendimiento, su escalabilidad y el coste que ello representa. La escalabilidad vertical tiene unos costes elevados. El coste de un servidor S1 que presente el doble de rendimiento que otro servidor S2 es bastante más del doble. Por tanto, parece razonable pensar que añadir nuevos nodos o servidores al sistema es la solución ideal. Sin embargo, esto no siempre es así. La ley de Amdahl establece que: `La mejora obtenida en el rendimiento de un sistema debido a la alteración de uno de sus componentes está limitada por la fracción de tiempo que se utiliza dicho componente.' Fuente: Wikipedia. donde: A = 1 (1 F m ) + Fm A m A es la ganancia en velocidad conseguida en el sistema completo debido a la mejora de uno de sus componentes. A m es el factor de mejora del componente mejorado. F m es la fracción de tiempo que el sistema utiliza el componente mejorado.

19 2. Estado del arte 19 Por tanto, el incremento de rendimiento que sufrirá un sistema al mejorar un componente es proporcional al tiempo que se utilice dicho elemento. Ejemplo: Imaginemos un servicio proporcionado por una aplicación. Un 30 % de la aplicación se ejecuta de forma secuencial mientras que el 70 % restante está preparado para ejecutarse de forma paralela. Pretendemos disminuir el tiempo de ejecución de dicha aplicación y, por tanto, queremos aumentar el rendimiento del sistema añadiéndole más procesadores. Utilizando la Ley de Amdahl, obtenemos: A n = 1 (1 0,7) + 0,7 n Dónde n es el número de procesadores. La ganancia obtenida al añadir procesadores se puede observar en el Cuadro 2.1. n A n 1 1,54 1,87 2,11 2,27 2,4 2,5 2,58 2,65 2,70 Cuadro 2.1: Progreso del rendimiento del sistema con n procesadores. Como se puede apreciar en el Cuadro 2.1, utilizando cuatro procesadores la ganancia es de 2,11. Sin embargo, si paralelizamos la ejecución de la misma aplicación en ocho, obtenemos una ganancia de 2,58. Por tanto, doblando la cantidad de procesadores, de cuatro a ocho, duplicando también la inversión a realizar, tan sólo obtenemos una mejora en torno al 20 %. Una mejora del 20 %, según la situación, puede no ser despreciable. Sin embargo, el ratio entre inversión realizada y mejora obtenida sí es bastante bajo Tolerancia a fallos y redundancia Los sistemas redundantes son aquellos en los que se duplican algunos componentes de carácter crítico. El objetivo de repetir estos dispositivos críticos es que el sistema siga proporcionando servicio aunque se produzca un error en alguno de estos. Si se produce un fallo en alguno de los componentes, el sistema seguirá proporcionando servicio aunque, seguramente, con un rendimiento menor. Para proporcionar una tolerancia a fallos, el sistema debe cumplir una serie de características: No debe existir un único punto de fallo: la redundancia de componentes debe asegurar la continuidad del servicio ofrecido. Además, se debe proporcionar métodos para la reparación sin afectar al servicio.

20 Escalabilidad y alta disponibilidad Aislamiento del fallo: si se produce algún error, se debe identicar y aislar el componente que lo ha causado. Contingencia en la propagación del fallo: en caso de que se produzca un fallo en algún componente, éste no debe afectar a otros. Vuelta atrás: debe existir algún método para volver a una situación previa en la cual el sistema funcionase correctamente. Cuando hablamos de escalabilidad vertical no tiene porqué estar implícita una tolerancia a fallos del sistema. El hecho de que un sistema tenga dos procesadores o dos módulos de memoria no quiere decir que el sistema pueda seguir ofreciendo servicio si se produce un error en alguno de ellos. En cambio, la tolerancia a fallos viene implícita cuando se habla de escalabilidad horizontal. Se cuenta con un balanceador de tráco que es el encargado de monitorizar el estado de cada uno de los servidores y decidir si está operativo o no. En este caso, el balanceador de tráco se convierte en el único punto de fallo, ya que si este falla, todo el servicio fallará. Por tanto, es necesario aplicar redundancia añadiendo un segundo balanceador de tráco para poder ofrecer alta disponibilidad Medición de la disponibilidad Los servicios están ofrecidos por una serie de servidores, que están formados por diversos componentes, tanto hardware como software. Cada uno de estos puede presentar dos estados: en funcionamiento o en reparación. El primer estado indica que el funcionamiento del componente es el deseado, es decir, operativo. El segundo estado indica que ha fallado. Hasta que el componente que ha fallado no vuelva a un estado operativo, bien sea por una reparación o por una sustitución, será considerado en el estado de reparación. La disponibilidad de un sistema depende de dos factores: 1. Tiempo medio de aparición de un error o Medium Time To Fail (MTTF). 2. Tiempo medio de reparación o sustitución o Medium Time To Repair (MTTR). Teniendo en cuenta estos factores se puede denir la disponibilidad de un servicio como la relación entre el tiempo que el servicio está disponible y operativo, y el tiempo total del servicio, tanto operativo como en reparación: Disponibilidad = MTTF MTTF + MTTR

21 2. Estado del arte 21 Para lograr una alta disponibilidad se requieren soluciones que ofrezcan una redundancia. En el caso de servidores se debe ofrecer una rendundancia tanto a nivel de software como a nivel de hardware. Aplicar técnicas de alta disponibilidad a los servicios críticos permite disminuir el número de interrupciones del servicio ofrecido. Históricamente, en el servicio de educación virtual de la UIB, las interrupciones de servicio han sido provocadas por: Actualización del software que proporciona el servicio. Estas pueden ser del propio sistema operativo del servidor o bien de alguna de las aplicaciones críticas del servicio. Suelen estar motivadas por correción de errores de seguridad (bugs), nuevas funcionalidades o compatibilidad con otras aplicaciones. Fallos de hardware. A pesar de que se cuenta con hardware especíco para realizar las funciones de servidor y de que éstas máquinas cuenten con un MTTF bastante elevado, se producen pérdidas de servicio causadas por un fallo en algún componente hardware. Denegaciones de servicio. En ocasiones se producen unos picos muy elevados de demanda hacia un servidor determinado. El servidor es incapaz de procesar tantas peticiones y se deniega el servicio a nuevas peticiones. Estas situaciones se deben bien a momentos de pico puntuales o bien a ataques intencionados. En un entorno de alta disponibilidad donde se tienen los sistemas correctamente replicados y balanceados es relativamente sencillo superar estos problemas. Las actualizaciones de software se pueden ir realizando siguiendo un orden y aplicándolas en un único servidor a la vez de forma que sólo se interrumpa el servicio en uno de ellos. Los errores de hardware serán también solucionados mediante la redundancia del mismo. La existencia de varios servidores físicos proporciona una elevada tolerancia a fallos del sistema. Para provocar un corte en el servicio se debería producir un fallo en todos los servidores. Los ataques de denegación de servicio podrán ser más controlables gracias a la presencia de un mayor número de servidores. Por tanto, será necesario un mayor número de peticiones para provocar una denegación de servicio en los servidores Virtualización La virtualización es una técnica a través de la cual, a partir de un recurso físico, se pueden crear uno o varios recursos virtuales. Los usuarios pueden

22 Virtualización interactuar con estos recursos virtuales exactamente igual que si fuera un recurso físico. En el caso concreto de este proyecto, nos centraremos en la virtualización de servidores. Los servidores actuales tienen unas características hardware sucientemente potentes como para usar virtualización. A través del uso de esta técnica se pueden crear varias máquinas virtuales con menor capacidad de procesamiento sobre un único servidor físico. Estas máquinas virtuales ejecutan una instancia diferente de un sistema operativo. El uso de esta técnica presenta bastantes retos. En primer lugar, la ejecución de varias instancias de servidores virtuales deben estar aisladas entre ellas. Si una instancia sufre de una alta carga no debe afectar al rendimiento de otra. En segundo lugar es preciso ofrecer soporte para virtualizar el mayor número de sistemas operativos posibles. Por último, pero no por ello menos importante, se debe minimizar la sobrecarga o overhead introducida por la virtualización en sí Introducción En informática, el término virtualización hace referencia a la abstracción de los recursos de un ordenador. De esta forma, se crea una capa de abstracción entre el hardware de la máquina física (host) y el sistema operativo de la máquina virtual (guest). La capa de software encargada de realizar la abstracción se denomina Hypervisor o Virtual Machine Monitor. Esta capa es la encargada de gestionar los recursos del host entre las diferentes máquinas virtuales denidas en él. De esta forma, con un único servidor físico podemos tener varios servidores virtuales. Un servidor virtual es una instancia de un sistema operativo y su carga de trabajo, ejecutándose bajo el hypervisor. En lugar de tener acceso directo al hardware, el sistema operativo del servidor virtual debe acceder a él a través del hypervisor, que tiene la capacidad para compartir los recursos del servidor físico con otras instancias de sistemas operativos virtualizados. Existen dos tipos de hypervisor: 1. Denominado nativo, bare metal o unhosted. En este tipo, el software se ejecuta directamente sobre el hardware del servidor físico para poder controlar los recursos y monitorizar los sistemas operativos virtualizados. 2. Denominado hosted. El software de virtualización se ejecuta sobre un sistema operativo convencional.

23 2. Estado del arte 23 El rendimiento de los hypervisor hosted es menor que los nativos debido a que la virtualización está una capa más alejada del hardware real. Las capas que forman ambos tipos se pueden apreciar en la Figura 2.3. La única diferencia entre ambos radica en la capa de sistema operativo antrión del hypervisor hosted sobre la cual se ejecuta. Figura 2.3: Diferencias entre los dos tipos de Hypervisor: nativo y hosted. Fuente: propia. Procesadores virtuales Históricamente, la virtualización, y por tanto, la ejecución de un hypervisor sobre plataformas x86 representaba una gran sobrecarga. En los años 2005 y 2006, tanto Intel como AMD, principales fabricantes de procesadores x86, resolvieron este problema añadiendo un conjunto especíco de extensiones a la arquitectura x86. Estas modicaciones, realizadas independientemente entre ambas compañías, permiten que el hypervisor ejecute un sistema operativo sin modicaciones de forma que no se penalice gravemente el rendimiento. La tecnología que AMD creó para el mercado de virtualización se llama AMD Virtualization, o AMD-V, y está basada en procesadores con arquitectura x86 de 64 bits. Los primeros procesadores con esta tecnología fueron anunciados en mayo de 2006: Athlon 64, Athlon 64 X2 y Athlon 64 FX.

24 Virtualización Intel por su parte desarrolló una tecnología para virtualización sobre arquitectura x86 denominada Intel VT-x. Esta compañía tiene su mercado muy segmentado y a causa de ello, desde la aparición de esta tecnología, no todos sus procesadores la soportan. Los primeros procesadores de Intel con esta tecnología fueron los Pentium 4 662, Pentium y Pentium D 9x0 entre otros. Memoria virtual Para ejecutar diversas máquinas virtuales en un único sistema físico, es necesario un nivel de virtualización de memoria, es decir, virtualizar la Memory Management Unit (MMU) 1. Figura 2.4: Virtualización de la memoria. Fuente: TechArena Forums. El sistema operativo de la máquina virtual sigue controlando la traducción de direcciones virtuales a direcciones de memorias físicas virtualizadas. Sin embargo, no tiene acceso directo a la memoria de la máquina física. El Virtual Machine Monitor (VMM) es el componente responsable de realizar la traducción de direcciones de memoria física virtualizada a direcciones de memoria físicas reales. Dispositivos e Input/Output o Entrada/Salida (I/O) virtuales Un Input/Output Memory Management Unit (IOMMU) es una unidad de gestión de memoria que conecta un bus de I/O con soporte Direct Memory Access (DMA) a la memoria principal. Un MMU convencional traduce direcciones de memoria virtuales para la CPU a direcciones físicas en memoria. Un IOMMU convierte direcciones virtuales de dispositivos de I/O en direcciones físicas. 1 Un MMU convencional traduce direcciones de memoria virtualles para la CPU a direcciones físicas en memoria.

25 2. Estado del arte 25 Figura 2.5: Virtualización de dispositivos e I/O. Fuente: TechArena Forums. Tanto AMD como Intel han desarrollado IOMMU especícas para virtualización, de forma que las máquinas virtuales tengan acceso directo a dispositivos de I/O como tarjetas de red o discos duros entre otros. Las tecnologías de AMD e Intel se denominan AMD-Vi e Intel Virtualization Technology for Directed I/O, VT-d. El VMM es el encargado de realizar tareas de enrutamiento entre las distintas máquinas virtuales y los subsistemas de I/O. Además, ciertos dispositivos permiten una fácil virtualización, como pueden ser las tarjetas de red. La creación de dispositivos de red virtuales permite, por ejemplo, que la comunicación de red entre las máquinas virtuales de una misma red, que están ejecutándose sobre el mismo servidor físico, no generen ningún tipo de tráco sobre la tarjeta de red física Paravirtualización Paravirtualización es una técnica que consiste en que el sistema operativo del servidor virtual sea consciente de que está siendo virtualizado de forma que se establezca una colaboración entre el sistema operativo virtualizado y el hypervisor del servidor físico. A través de esta técnica se minimiza la pérdida de rendimiento por parte de los servidores virtualizados. Esta comunicación permite que ciertas operaciones se ejecuten en el sistema operativo del servidor físico en vez de en el sistema operativo del servidor

26 Virtualización Figura 2.6: Comparativa entre una operación realizada en una virtualización total y utilizando paravirtualización. Fuente: propia. virtual. La paravirtualización provee una Application Programming Interface (API) para permitir que los servidores virtuales puedan realizar operaciones en el servidor físico, que de otro modo serían ejecutadas en el servidor virtual, aumentando así el rendimiento global. Para que la comunicación sea posible, el sistema operativo virtual debe ser consciente de que está siendo virtualizado, por lo que es necesario ofrecerle una API de paravirtualización para establecer la comunicación entre ambos. Debido a que ciertas operaciones se realizan directamente en el servidor físico, el hypervisor es más sencillo y necesita menos memoria. El hypervisor se simplica debido a que ciertas tareas críticas se trasladan del entorno virtual al servidor físico. Además, como ya se ha comentado anteriormente, el rendimiento global de la máquina virtual podría verse mejorado Ventajas e inconvenientes La virtualización de servidores permite gestionar de forma centralizada los servidores virtualizados proporcionando las siguientes ventajas: Ampliación rápida de recursos para los servidores virtualizados.

27 2. Estado del arte 27 Reducción de los costes de espacio físico para los servidores. Aumento de la eciencia de los servidores físicos. Mayor exibilidad en el uso de recursos. Administración global y centralizada. Generación de plantillas para los servidores virtuales. Copia y clonación de máquinas virtuales. Migración en caliente de una máquina virtual de un servidor físico a otro, sin perder servicio, de forma que se realizan menos paradas planicadas por mantenimiento en los servidores físicos. Un fallo en una de las máquinas virtuales no afecta al resto alojadas en el mismo servidor físico. Generación de una copia de seguridad del estado de la máquina virtual para su posterior recuperación. Incluye el estado de los discos duros, memoria, procesos y demás parámetros en el instante en el cual se realiza la copia. Monitorización constante de la utilización de recursos de los servidores físicos. Las máquinas virtuales pueden ejecutarse dinámicamente en el servidor cuyos recursos libres sean más adecuados para ellas. Como principal inconveniente de la virtualización tenemos un único punto de fallo para todas las máquinas virtuales que se ejecuten en un único servidor físico. Para solucionarlo se deben utilizar servidores físicos con un alto nivel de redundancia de discos, memoria, red, fuente de alimentación, y demás componentes. Además, por los principios básicos de alta disponibilidad, conviene replicar los servidores físicos en una localización física diferente. Sin embargo, las plataformas de virtualización actuales permiten denir clústers de virtualización. A través de un clúster de virtualización, si un servidor físico cae, las máquinas virtuales que se ejecutaban sobre él son automáticamente arrancadas de nuevo en otro de los servidores físicos del clúster Virtualización con Xen Xen, el hypervisor Xen es un hypervisor liberado bajo licencia GNU GPL. Fue desarrollado como un proyecto más en la Universidad de Cambridge. Sus creadores,

28 Virtualización posteriormente, crearon XenSource, una empresa dedicada al desarrollo de software con Xen como su mayor carta de presentación. En agosto de 2007, Citrix[10] compró XenSource y con ella, Xen. El hypervisor sigue manteniendo su licencia GNU GPL pero Citrix ha desarrollado aplicaciones y mejoras a su alrededor para ofrecer plataformas de virtualización para servidores a gran escala. Este hypervisor permite que múltiples instancias de sistemas operativos se ejecuten en forma de máquinas virtuales en un único servidor con arquitectura x86. Está preparado para paravirtualización, por lo que requiere que se modique parte del sistema operativo para que se ejecute sobre Xen. Se trata de un hypervisor relativamente sencillo, lo que se traduce en una pequeña sobrecarga, o overload, sobre el rendimiento nativo de las máquinas virtuales. Reutiliza controladores de dispositivos de Linux para las máquinas virtuales cuyo sistema operativo sea Linux. Para el caso de máquinas virtuales con Windows, utiliza unos controladores de dispositivos de I/O y red paravirtualizados. Xen proporciona seguridad e independencia entre sí a las máquinas virtuales. Se realiza la asignación de recursos; procesador, memoria, disco duro y red; para cada máquina virtual y se monitorizan constantemente los controladores de acceso a cada uno de forma que no haya ni interrupciones ni denagaciones de servicio entre máquinas virtuales. XenServer XenServer es una plataforma de virtualización para servidores ofrecida por la compañía Citrix. Utiliza el hypervisor nativo Xen, que permite combinar múltiples servidores físicos en un único metaservidor que aúna todos los recursos, utilizando los estándares de la industria en sistemas de almacenamiento compartido y utilizando tecnologías de administración de clústers creadas por la misma empresa que lo desarrolló. De esta forma, se extiende la visión simple de un único servidor de virtualización a un amplio número de servidores que actúan como uno, cuyos componentes de almacenamiento, memoria, procesadores o red pueden ser dinámicamente controlados para ofrecer un buen rendimiento, incrementando también la tolerancia a fallos y la disponibilidad de los servicios ofrecidos por las máquinas virtuales. Los administradores de los servidores pueden administrar todos los servidores físicos y sus recursos desde un único punto, reduciendose así la complejidad y los costes asociados a la administración. XenServer permite asignar exiblemente hasta 16 servidores a un único meta-servidor que agrupa todos los recursos de los servidores individuales. Un meta-servidor no es más que un conjunto de servidores cuyos recursos

29 2. Estado del arte 29 son virtualizados para alojar un conjunto de máquinas virtuales. Los servidores físicos que formen parte monitorizan la conguración y el estado de sus antriones. El estado de sus máquinas virtuales antrionas se propaga a todos los servidores que forman parte del mismo meta-servidor. De esta forma, si ocurre un error con el servidor físico, éste puede ser rápidamente reemplazado ya que todos los demás conocen el estado de ejecución de sus máquinas virtuales. Múltiples meta-servidores se pueden administrar desde la misma consola de administración. Las máquinas virtuales asignadas a un meta-servidor son automáticamente asociadas a un conjunto de recursos físicos del conjunto global. Sin embargo, los administradores tienen control total sobre la repartición de los recursos, así como una visibilidad total sobre los recursos y las máquinas virtuales. Se pueden asignar manualmente máquinas virtuales a un determinado servidor físico, así como ver, dado un servidor físico, las máquinas virtuales y los recursos que se están utilizando de él. En el caso más sencillo, el responsable únicamente tiene que asociar una máquina virtual a un meta-servidor y XenServer se encargará de asignar los recursos físicos Virtualización con VMware VMware Infraestructure VMware Infraestructure es un conjunto de productos de virtualización que permite optimizar el uso de los recursos informáticos a través de virtualización. Está creado por la compañía VMware Inc[11]. A continuación se explica a fondo el funcionamiento de VMware Infraestructure. Esta solución de virtualización es la que se encuentra actualmente disponible en los servidores de la UIB y es, por tanto, sobre la cual se realiza este proyecto. El esquema de la arquitectura y la comunicación entre los distintos componentes que forman VMware Infraestructure se pueden ver en la Figura 2.7. A continuación se describiren las características y arquitectura interna de los diferentes componentes que forman parte de él. Topología física del Centro de Procesamiento de Datos (CPD) con VMware Infraestructure Una de las mayores ventajas de la virtualización es que no requiere de ningún tipo de hardware especíco. Utilizando el hardware disponible se crean CPD's virtuales que pueden ser administrados desde varias interfaces. Tal y como se puede observar en la Figura 2.8, un CPD de VMware Infraestructure consiste típicamente en un conjunto de servidores con arquitectura

30 Virtualización Figura 2.7: Arquitectura de VMware Infraestructure. Fuente: VMware. x86, redes de almacenamiento, redes IP, un servidor de administración centralizada y los clientes. A continuación se explican algunos de los componentes que forman parte de la topología física: Servidores físicos: Los servidores físicos son servidores estándar con arquitectura x86 que ejecutan VMware ESX, Sección Cada uno de ellos es considerado un antrión en el entorno de virtualización. Un conjunto de servidores x86 congurados de forma similar pueden ser agrupados con conexiones a la misma red y subsistemas de almacenamiento para proporcionar un conjunto de recursos al sistema de virtualización. A este conjunto se le denomina clúster. Red de almacenamiento: Cabinas de disco con interfaz SAN Fiber- Channel o iscsi y cabinas con interfaz NAS están totalmente soportadas por VMware Infraestructure. Este soporte permite una exibilidad enorme a la hora de crear los espacios de almacenamiento para las máquinas virtuales y su información asociada. Red IP: Cada servidor suele poseer múltiples tarjetas de red Gigabit

31 2. Estado del arte 31 Figura 2.8: Topología física típica en un CPD con VMware Infraestructure. Fuente: VMware. Ethernet para, en conjunto, ofrecer un elevado ancho de banda para las máquinas virtuales alojadas en él. Servidor de administración: El VirtualCenter Management Server proporciona un único punto de control del CPD. Este servidor físico proporciona acceso, monitorización de rendimiento y conguración de los servidores. En la Figura 2.9 puede observarse cómo monitoriza las máquinas virtuales asignadas a cada servidor físico, así como una monitorización constante, global y por máquina virtual, de los recursos de cada servidor físico.

32 Virtualización Figura 2.9: La asignación de máquinas virtuales a servidores físicos se administra de forma centralizada desde el VirtualCenter Management Server. Fuente: VMware. En caso de que un fallo provoque la inaccesibilidad del VirtualCenter Management Server, los servidores siguen funcionando perfectamente. La administración de los servidores físicos y de sus máquinas virtuales se puede realizar de forma individual accediendo a la consola de administración de cada uno de los servidores. Una vez se recupere, la administración y monitorización se puede realizar de nuevo de forma centralizada. Clientes: VMware Infraestructure proporciona un conjunto de herramientas para administrar y acceder a las máquinas virtuales. Por defecto, existen tres formas de acceder a las máquinas virtuales: a través de la aplicación VMware Infraestructure Client, de un navegador web y por medio de una consola propia del sistema operativo de la máquina

33 2. Estado del arte 33 virtual. Arquitectura del centro de datos virtual VMware Infraestructure virtualiza toda la arquitectura. Esta virtualización incluye no sólo a los servidores sino también al almacenamiento y a las redes. De esta forma, se realiza una abstracción de los servicios requeridos por los administradores y de la capa inferior, compuesta por el hardware y sus conexiones pertinentes. Figura 2.10: Arquitectura general del centro de datos virtual. Fuente: VMware. Tal y como se puede observar en la Figura 2.10, se presentan un conjunto básico de elementos que se utilizan para construir el centro de datos virtual: Servidores, clústers y meta-servidores. Almacenamiento de datos. Redes. Máquinas virtuales.

34 Virtualización Un servidor es la representación virtual del procesador y memoria de un servidor físico ejecutando el software de virtualización ESX Server. Cuando uno o más servidores físicos son agrupados para trabajar y ser administrados como uno sólo, el resultado es un clúster. Los recursos de procesador y memoria de los servidores y clústers pueden ser particionados en una jerarquía de meta-servidores. El almacenamiento de datos es la representación virtual de la combinación de sistemas físicos de almacenamiento de datos disponibles. Estos dispositivos pueden ser discos duros locales del propio servidor físico, un conjunto de discos Fiber-Channel presentados vía SAN, un conjunto de discos iscsi presentados vía SAN o un conjunto de discos presentado vía NAS. Las redes en el entorno virtual conectan máquinas virtuales entre sí o a la red física existente fuera del entorno virtual. Las máquinas virtuales están asignadas a un servidor físico, clúster o meta-servidor y almacenamiento concretos cuando son creadas. Una máquina virtual, al igual que una física, consume electricidad y, siempre que esté apagada o pausada, no consume recursos. Cuando la máquina virtual está encendida, consume recursos de forma dinámica, utilizando más si la carga aumenta y menos a medida que la demanda de recursos disminuya. El tiempo que se tarda en desplegar una máquina virtual nueva es mucho menor que el que se tarda en disponer de un servidor físico. Una vez que se han denido las características hardware de la máquina virtual, el sistema operativo y las aplicaciones pueden ser instaladas como si de un servidor físico se tratase. A través de plantillas creadas por los administradores, una máquina virtual puede crearse ya con el sistema operativo y sus aplicaciones instaladas y conguradas. Los recursos que se proporcionan a una máquina virtual están denidos por una política establecida por el administrador de sistemas. Estas pueden establecer una cota mínima garantizada de recursos para garantizar el rendimiento de la máquina virtual. Las políticas también pueden ser dinámicas. Así, la repartición de recursos se realiza priorizando y asignando partes de los recursos a cada máquina virtual. Una máquina virtual que está apagada o pausada no puede encenderse si esta operación causa la violación de estas políticas. Servidores, clústers y meta-servidores Un servidor representa la suma de los recursos de procesamiento y memoria de un servidor físico con arquitectura x86. Por ejemplo, si un servidor físico cuenta con dos procesadores de doble núcleo a 3,2 GHz y 8 GB de memoria, entonces el servidor antrión cuenta, a grandes rasgos, con 12,8 GHz

35 2. Estado del arte 35 de capacidad total de procesamiento y 8 GB de capacidad total de memoria para las máquinas virtuales alojadas en él. Un clúster representa la suma de capacidades de procesamiento y memoria de un conjunto de servidores físicos que comparten las mismas redes y los mismos sistemas de almacenamiento. Los administradores no necesitan conocer exactamente las características hardware (número de servidores, número de procesadores, características de los procesadores, entre otros) que existe en la capa inferior a la de virtualización para poder ofrecer el servicio de virtualización. Simplemente basta con establecer políticas que garanticen la disponibilidad de un recurso para una determinada máquina virtual. VMware Infraestructure, automáticamente, asigna los recursos de forma dinámica a las máquinas virtuales afectadas por dicha política. Figura 2.11: Servidores antriones, clústers y meta-servidores. Fuente: VMware. Los meta-servidores proporcionan una forma dinámica de dividir y organizar los recursos ofrecidos por un servidor antrión o un clúster. Cualquier meta-servidor puede ser particionado en pequeños meta-servidores de forma

36 Virtualización que se puedan asignar recursos a distintos grupos, según su propósito. VMware ESX Server VMware ESX es la capa de abstracción, hypervisor de tipo nativo, que se encuentra entre el hardware real y las máquinas virtuales. Se encarga de crear una capa de abstracción sobre el procesador, memoria, almacenamiento y dispositivos de redes entre el servidor físico y las máquinas virtuales. Una copia de VMware ESX Server se ejecuta en cada servidor físico. VMware ESX es básicamente una distribución Red Hat Enterprise Linux[12] modicado para incluir la ejecución del hypervisor y los componentes de virtualización necesarios. El núcleo de Linux se carga primero y es utilizado para cargar una serie de componentes de virtualización. Entre ellos el componente vmkernel. En este momento, el núcleo cargado anteriormente se convierte en la primera máquina virtual en ejecución sobre el servidor y sirve como consola de servicio. De esta forma, el vmkernel se ejecutará sobre el servidor físico y el núcleo, que proporciona una consola, sobre la primera máquina virtual. El vmkernel es un microkernel con tres interfaces de comunicación: Hardware: El vmkernel dirige la CPU y memoria directamente. El acceso a otro tipo de hardware se realiza a través de módulos. Algunos derivan directamente de los utilizados por el núcleo de Linux. Existe un módulo, denominado vmklinux, que actúa como interfaz para acceder a los módulos de Linux. Sistemas antriones: El vmkernel ofrece una interfaz a los sistemas antriones a través de la cual simula el hardware. Esta simulación se realiza de forma que el sistema operativo antrión puede ejecutarse, sin modicaciones, sobre el hypervisor. Sin embargo, esta solución consume recursos. VMware ofrece diversos controladores para cada tipo de sistema operativo que incrementan su rendimiento. Estos controladores son instalados en el sistema operativo antrión como parte de las VMware Tools que, además, incluyen herramientas de monitorización y comunicación con el vmkernel y la consola de servicio. Existe una versión especíca de VMware Tools para cada sistema operativo. Consola de servicio: la consola de servicio no es mas que una herramienta para poder arrancar el vmkernel. De forma secundaria, se puede utilizar también para tareas de administración del entorno de virtualización.

37 2. Estado del arte 37 VMware VMotion VMware VMotion permite la migración, sobre la marcha, de máquinas virtuales de un servidor físico a otro sin paradas de servicio. A través de VMotion se consigue obtener un CPD dinámico que permite mover máquinas virtuales entre distintos servidores físicos sin pararlas y sin dejar de dar servicio. Esto permite migrar las máquinas virtuales de un servidor con una alta carga a uno con carga menor. Además, permite realizar operaciones de mantenimiento de hardware sin planicar una parada de servicio o mover máquinas virtuales de servidores sobresaturados a otros con menor carga, de forma que se optimiza la utilización de sus recursos. Figura 2.12: VMware VMotion. Fuente: VMware. La migración en caliente de máquinas virtuales de un servidor físico a otro se realiza gracias a tres tecnologías: El estado global de la máquina virtual se encapsula en una serie de cheros guardados en un almacenamiento compartido entre los servidores físicos. La memoria y la precisa ejecución de la máquina virtual se transere rápidamente de forma que cambia su ejecución desde un servidor físico a otro de forma casi instantánea. Las redes utilizadas por las máquinas virtuales también son virtualizadas por el servidor físico que tienen en la capa inferior. De esta forma, se puede asegurar que la identidad y las conexiones de red son preservadas. VMotion también gestiona la MAC virtual como parte del proceso.

38 Virtualización Una vez que la máquina virtual de destino está activada, VMotion realiza un ping al router de la red para asegurarse de que está al corriente de la nueva localización de la MAC. Como se puede observar, el proceso de migración de máquinas virtuales mediante VMotion preserva el estado preciso de ejecución, el estado de la red y las conexiones activas. Como resultado, se obtiene una migración tremendamente rápida y sin pérdidas de servicio en comparación con la migración de servicios entre servidores tradicional. VMware DRS VMware DRS lleva VMotion un paso más allá, permitiendo al administrador crear políticas de asignación de recursos que VMware DRS utiliza para calcular y automáticamente administrar la asignación de recursos físicos. Para ello, dinámicamente se monitorizan todas las máquinas virtuales y la utilización de recursos de los servidores físicos en el clúster. A partir de los resultados y de la política asignada, en caso de haber una violación de rendimiento, utiliza VMotion y dinámicamente reasigna la máquina virtual a un servidor físico diferente, como se muestra en la Figura 2.13, para asegurar que las políticas y el reparto de recursos son correctos. Figura 2.13: VMware DRS. Fuente: VMware.

39 2. Estado del arte 39 Si se añade un nuevo servidor físico al entorno de virtualización, VMware DRS se encarga de redistribuir las máquinas virtuales para balancear la carga entre todos los servidores. Del mismo modo, si un servidor se debe desconectar por alguna razón del entorno de virtualización, VMware DRS redistribuye sus máquinas virtuales a los otros servidores de forma automática. Alta disponibilidad en VMware VMware posee un módulo, denominado VMware High Availability (VMware HA), que proporciona alta disponibilidad a las máquinas virtuales. En el caso de un fallo hardware del servidor físico, las máquinas virtuales afectadas serían arrancadas de nuevo en otro servidor físico capaz de albergarlas. En el caso de un fallo grave de software, típicamente producido por el sistema operativo, el módulo VMware HA reinicia la máquina virtual afectada de forma automática en el mismo servidor físico. Figura 2.14: VMware HA proporciona alta disponibilidad en casos de fallos de hardware en los servidores físicos. Fuente: VMware. De esta forma se minimiza el tiempo en que no se proporciona servicio. Otra gran ventaja de este sistema de alta disponibilidad es que es totalmen-

40 Virtualización Figura 2.15: VMware HA gestiona errores de sistema operativo en las máquinas virtuales. Fuente: VMware. te independiente del sistema operativo o de la aplicación que proporciona servicio. Así se obtiene una estructura de servidores con soluciones de alta disponibilidad de forma heterogénea y uniforme. Para proporcionar este servicio de alta disponibilidad, VMware HA debe monitorizar constantemente todos los servidores virtualizados y detectar fallos tanto en los servidores físicos como en los sistemas operativos. Para monitorizar los servidores físicos, un agente en cada servidor mantiene un heartbeat 2 con los otros servidores. Una pérdida de conexión implica el reinicio de todas las máquinas virtuales alojadas en el servidor caído en otros servidores físicos. La distribución de máquinas virtuales a lo largo de los servidores físicos disponibles se realiza teniendo en cuenta la utilización de los recursos de los mismos de forma que se utilicen por igual. Para monitorizar los fallos de sistema operativo, se monitoriza la información de un heartbeat que forma parte de un conjunto de herramientas instaladas en cada máquina virtual, denominadas VMware Tools Package. Por último, cabe destacar que VMware HA se asegura en todo momento de la disponibilidad de recursos sucientes para reiniciar las máquinas virtuales en diferentes servidores físicos en caso de fallo de hardware. 2 Heartbeat - técnica de comunicación entre dos o más ordenadores a través de la cual se realiza una monitorización mútua del estado de cada ordenador.

41 2. Estado del arte 41 Arquitectura de red Figura 2.16: Arquitectura de red. Fuente: VMware. La Figura 2.16 muestra la conexión entre las redes dentro y fuera del entorno de virtualización. Este entorno ofrece dispositivos de red similares a los reales. Se proporcionan interfaces de red virtuales (vnic ó virtual NIC), conmutadores virtuales (vswitch) y grupos de puertos. Exactamente como ocurre con servidores físicos, cada máquina virtual tiene su propia tarjeta de red virtual, vnic. El sistema operativo y las aplicaciones se comunican con la vnic a través de un controlador de dispositivo estándar o a través de un controlador de dispositivo propio de VMware, exactamente igual que si se tratase de una tarjeta de red real. Fuera del entorno de virtualización cada vnic es considerada como una tarjeta de red normal, ya que dispone de su propia dirección MAC y una o varias direcciones IP, respondiendo al protocolo estándar Ethernet exactamente igual que una tarjeta de red física. Un vswitch se comporta como un conmutador físico de capa 2. Cada servidor físico tiene uno propio. En un extremo del conmutador virtual están los grupos de puertos que conectan con las máquinas virtuales. En el otro

42 Virtualización extremo se encuentran las conexiones con los adaptadores de red del servidor físico donde se encuentra el vswitch. Las máquinas virtuales se conectan a la red externa a través de los dispositivos de red del servidor físico pasando a través de la conexión con el conmutador virtual. Un conmutador virtual puede conectar las máquinas virtuales a más de un dispositivo de red del servidor físico en caso de contar con ellos. De esta forma, se utilizan varios dispositivos físicos para las conexiones, aumentando el ancho de banda y la tolerancia a fallos en caso de una avería de hardware relacionada con sus adaptadores de red. En caso de avería en uno de ellos, el error sería totalmente transparente para las máquinas virtuales y su reconguración es innecesaria. El grupo de puertos, o Port Group como VMware denomina a esta tecnología, es un mecanismo para establecer políticas que establezcan mecanismos de control sobre la red a la cual se encuentra conectado. Un conmutador virtual puede tener múltiples grupos de puertos. En vez de conectar a un puerto particular del vswitch, una máquina virtual conecta su vnic a un grupo de puertos. Todas las máquinas virtuales que se conecten al mismo Port Group pertenecen a la misma red dentro del entorno de virtualización a pesar de estar en servidores físicos diferentes. Una de las condiciones para migrar en caliente una máquina virtual de un servidor físico a otro es que éste tenga el mismo vswitch con los mismos Port Groups congurados. De esta forma, la conexión a la red se mantiene después de realizar el proceso de migración ya que la máquina virtual se conecta automáticamente al mismo grupo de puertos del mismo conmutador virtual. El proceso de migración en caliente de una máquina virtual se denomina VMotion, detallado en la Sección Los Port Groups se pueden congurar para ofrecer políticas de seguridad, fragmentación de red, alta disponibilitat o calidad de servicio. Arquitectura de almacenamiento El objetivo principal de VMware Infraestructure es ofrecer rendimiento, funcionalidad y disponibilidad de almacenamiento sin añadir complejidad a las aplicaciones o sistemas operativos de las máquinas virtuales. Para ello, se crean unas capas de abstracción que ocultan y administran la complejidad y diferencias entre los subsistemas de almacenamiento físico y presentan elementos estándar y simples al entorno de virtualización. De esta forma, el almacenamiento es presentado simplemente como discos SCSI conectados a un bus lógico o adaptador SCSI para las aplicaciones y sistemas operativos. Los discos SCSI de las máquinas virtuales son proporcionados por almacenes de datos del CPD. Un almacén de datos es un conjunto de discos duros

43 2. Estado del arte 43 Figura 2.17: Arquitectura general de almacenamiento. Fuente: VMware. conectados entre sí y gestionados por un controlador que proporciona espacio de almacenamiento para discos virtuales dentro de las máquinas virtuales, así como su propio almacenamiento. Como se puede apreciar en la Figura 2.17, una máquina virtual está almacenada como un conjunto de cheros en su propio directorio en el almacén de datos. Un disco virtual dentro de cada máquina virtual también está representado como un chero dentro del directorio. El resultado es un disco duro virtual que puede ser fácilmente manipulable y ser tratado como un chero. Puede moverse, copiarse o eliminarse de forma sencilla. El almacén de datos proporciona un modelo simple de asignación de espacio de forma individual para las máquinas virtuales sin entrar en la complejidad y variedad de tecnologías de almacenamiento físico disponibles, como son Fiber-Channel SAN, iscsi SAN, almacenamiento directamente conectado o

44 Virtualización NAS. Un almacén de datos es un volumen de datos con el sistema de cheros VMFS o un directorio en un dispositivo NAS. Cada almacén de datos puede contener múltiples subsistemas de almacenamiento físicos. Como se puede observar en la Figura 2.17, un único volumen VMFS puede contener una o más LUNs de un disco conectado directamente al servidor físico, un disco Fiber-Channel SAN, o un conjunto de discos iscasi SAN. Nuevas LUNs agregadas a cualquiera de los subsistemas físicos de almacenamiento son automáticamente encontradas y pasan a estar totalmente disponibles. Pueden ser añadidas para aumentar un almacén de datos previamente creado sin apagar los servidores físicos o los subsistemas de almacenamiento. En el caso de que una LUN de un almacén de datos esté innaccesible, únicamente las máquinas virtuales almacenadas en ella se ven afectadas. VMFS es un sistema de cheros para clústers que aprovecha el almacenamiento compartido para permitir el acceso de lectura y escritura por parte de múltiples servidores físicos al mismo almacenamiento de forma simultánea. VMFS proporciona métodos de control para asegurar que la misma máquina virtual no esté en ejecución en varios servidores físicos a la vez. Si un servidor físico sufre un fallo, el bloqueo de cada máquina virtual puede ser liberado de forma que puedan ser reiniciadas en otros servidores físicos. También proporciona mecanismos de consistencia y recuperación de ante accidentes. VMFS soporta Raw Device Mapping (RDM). RDM proporciona un mecanismo para que una máquina virtual tenga acceso directo a una LUN en el subsistema de almacenamiento físico, saltándose alguna de las capas de abstracción. RDM puede ser interpretado como un enlace simbólico de un volumen VMFS a una LUN de forma directa. Este mapeo hace que las LUNS aparezcan como cheros en el volumen VMFS. El chero que mapea es el que debe ser referenciado desde la conguración de la máquina virtual como disco duro. Cuando una LUN se conecta, VMFS realiza el enlace del chero al dispositivo físico correcto y realiza las pruebas y el bloqueo pertinente. Una vez realizada esta operación, las escrituras y lecturas se realizan directamente a la LUN en vez de ir a través del chero que mapea. VMware Consolidated Backup A través de VMware Consolidated Backup se pueden realizar copias de seguridad de forma sencilla, centralizada y sin la necesidad de ningún agente instalado de las máquinas virtuales. En la Figura 2.19 se observa como se trabaja con un agente de backup externo en otro servidor pero no se requiere de ningún agente especíco en las máquinas virtuales. El agente externo es

45 2. Estado del arte 45 Figura 2.18: Esquema de Raw Device Mapping. Fuente: VMware. el que establece las políticas y calendario para las copias de seguridad. El agente informa a VMware Consolidated Backup cuando es el momento para realizar una copia de seguridad. Posteriormente, ejecuta una serie de scripts previos para realizar snapshots de todos los discos virtuales. Estos snapshots pasan a ser visibles para el servidor de backup. Es aquí cuando se realiza la copia de seguridad de estos cheros, de forma no intrusiva con las máquinas virtuales y sin afectar apenas a su rendimiento. Arquitectura del VirtualCenter Management Server El VirtualCenter Management Server (VCMS) es el encargado de centralizar la administración del entorno de virtualización. Se encarga de presentar el conjunto de recursos de múltiples servidores ESX de forma centralizada. La Figura 2.20 muestra los componentes clave del VirtualCenter Management Server. El User Access Control permite a los administradores de sistemas crear y administrar usuarios, deniendo niveles de acceso al Virtual- Center. Los Core Services son servicios de administración básicos, como el despliegue de nuevas máquinas virtuales, conguración de servidores antrio-

46 Virtualización Figura 2.19: Funcionamiento de VMware Consolidated Backup. Fuente: VMware. nes o máquinas virtuales, administración de recursos, estadísticas y registro de sucesos, alarmas y eventos, o planicación de tareas. Los Distributed Services como VMware HA, VMware DRS, VMware VMotion, entre otros, son soluciones añadidas a VMware Infraestructure. Distributed Services permite la conguración y administración de estos productos desde el propio Virtual- Center Management Server. El VirtualCenter Management Server tiene cuatro interfaces de comunicación: Administración servidor ESX: Se comunica con el agente para administrar cada uno de los servidores físicos del entorno de virtualización. API de VMware Infraestructure: Interfaz con la administración de los clientes y otras aplicaciones desarrolladas por terceros. Interfaz de base de datos: Conexión con Oracle o Microsoft SQL Server para almacenar información como conguración de las máquinas virtuales, conguración de los servidores antriones, recursos e inventarios de máquinas virtuales, estadísticas de rendimiento, eventos,

47 2. Estado del arte 47 Figura 2.20: Componentes del VirtualCenter Management Server. Fuente: VMware. alarmas y permisos de usuarios, entre otros. Interfaz de Active Directory: Conexión con Active Directory para obtener información de control de acceso de usuarios.

48 Virtualización Acceso al CPD virtual Los usuarios pueden administrar el entorno de virtualización VMware Infraestructure o acceder a la consola de cada máquina virtual por medio de tres alternativas: Virtual Infraestructure Client, un navegador web o mediante servicios de terminal. Figura 2.21: Acceso y control de VMware Infraestructure. Fuente: VMware. Tanto el VirtualCenter Management Server como los VMware ESX Server, de forma individual, pueden ser administrados a través del cliente Virtual Infraestructure Client. La administración de los servidores ESX se realiza de forma individual sólo en ocasiones especiales. Toda la conguración y admi-

49 2. Estado del arte 49 nistración de los servidores ESX se puede realizar mediante el cliente. Figura 2.22: Software de administración centralizada VMware Infraestructure Client. Fuente: propia. A través de Virtual Infraestructure Client, Figura 2.22, se pueden administrar tanto los recursos físicos como los virtuales. Una vez autenticado, el usuario tiene un resumen de los recursos y máquinas virtuales que le pertenecen. Antes de acceder directamente a la consola de una máquina virtual, el cliente primero obtiene la localización exacta de la máquina virtual del VirtualCenter Management Server. Posteriormente, se conecta al servidor ESX correspondiente y abre la consola seleccionada. A través de un navegador web los usuarios pueden administrar los recursos virtuales y acceder a las diferentes consolas. En la Figura 2.21 puede observarse como cualquier operación que se reali-

50 Escalado y alta disponibilidad en servidores web ce entre los clientes y el VirtualCenter Management Server pasa a través de una API denominada VI API. Algunas de las operaciones, como abrir la consola de una determinada máquina virtual, se realizan con una comunicación directa con el servidor ESX. Esta comunicación con el servidor ESX también pasa por la VI API antes de conectarse con la máquina virtual Escalado y alta disponibilidad en servidores web En esta sección se realiza una breve introducción a la arquitectura clienteservidor. A continuación se explica el funcionamiento básico de un servidor web. Posteriormente se analizan las soluciones de escalabilidad y alta disponibilidad. Para nalizar se realiza un estudio sobre las características y funcionamiento de herramientas de análisis de rendimiento de servidores web Arquitectura cliente-servidor El servicio web está basado en una arquitectura cliente-servidor. Esta arquitectura consiste en un servidor, ejecutando un software especíco, que está a la espera de que los clientes realicen peticiones para ser atendidas y debidamente tratadas. La separación entre cliente y servidor es de tipo lógica, donde el servidor no se ejecuta necesariamente sobre un único servidor físico ni es un único programa. Es común contar con sistemas multicapa en los que el servicio se descompone en diferentes programas que pueden ser ejecutados en diferentes servidores físicos. Las principales características de la arquitectura cliente-servidor son: El software del servidor se inicia y espera a que lleguen las solicitudes de los clientes, desempeñando un papel pasivo en la comunicación. El cliente es quien inicia las peticiones, desempeñando un papel activo. Una vez realizada la petición, el cliente pasa a la espera de una respuesta. Al recibirse una petición, el servidor la procesa y envía una respuesta al cliente. El servidor puede atender las peticiones de varios clientes a la vez.

51 2. Estado del arte Introducción a los servidores web En el caso concreto de los servidores web, no es más que un programa que esta diseñado para transferir páginas web, escritas en lenguaje HyperText Markup Language (HTML), textos enriquecidos que permiten la inserción de imágenes, formularios y demás objetos. Este programa implementa un protocolo propio, denominado HyperText Transfer Protocol (HTTP), perteneciente a la capa de aplicación del modelo OSI. El servidor web se mantiene a la espera de peticiones por parte de un cliente que, normalmente, realiza las peticiones a través de un navegador web. El servidor responde a estas peticiones adecuadamente mediante una página web que será visualizada por el cliente. En caso de que se produzca algún error, éste será también visualizado en el navegador. El navegador del cliente es el encargado de interpretar y representar el código HTML enviado por el servidor web. Además de la transferencia de código HTML, los servidores web también pueden funcionar con aplicaciones web. Estas aplicaciones se ejecutan cuando se realizan ciertas peticiones o se envían ciertas respuestas HTTP. Existen dos tipos de aplicaciones web, según dónde se ejecuten: Sesiones Aplicaciones en el lado del cliente: el cliente, a través del navegador, es el encargado de ejecutar este tipo de aplicaciones. Estas suelen ser applets de Java o código JavaScript. El servidor proporciona al cliente el código de las aplicaciones que debe ejecutar. Aplicaciones en el lado del servidor: estas aplicaciones son ejecutadas directamente en el servidor. Una vez ejecutada la aplicación, se genera un código HTML resultante que es enviado al cliente a través de HTTP para que el cliente visualice el resultado. Las aplicaciones de servidor hacen que las aplicaciones web sean totalmente independientes del cliente, ya que no añaden ninguna carga extra al navegador del cliente. Existen una gran cantidad de lenguajes de programación que permiten integrarse completamente en los entornos web. Algunos ejemplos son PHP o Perl. En algunas aplicaciones web es muy útil poder vincular información a un usuario en concreto durante el proceso de visita a una web. Este procedimiento se realiza mediante sesiones, que normalmente se utilizan para labores de autenticación y seguimiento de la actividad que realiza el usuario en las aplicaciones dónde se necesita un control de acceso.

52 Escalado y alta disponibilidad en servidores web El uso de sesiones facilita y unica las tareas de control de accesos. Sin embargo, representa un posible agujero de seguridad ya que puede dar al traste con la seguridad de toda la aplicación web Escalabilidad Si se tiene previsión de escalar de forma continuada el entorno web es mejor opción decantarse por un escalado de forma horizontal. Escalar verticalmente tendría unos costes mucho más elevados que escalar de forma horizontal debido a la especialización necesaria del hardware al necesitar servidores de altísimo rendimiento. Al escalar de forma horizontal, las páginas web que contienen la información deben ser replicadas a todos los servidores web. Para poder obtener mejoras después de añadir más servidores, las peticiones de los distintos clientes se deben repartir de forma equilibrada entre los servidores. Esta tarea de redirigir peticiones hace necesario utilizar un balanceador de tráco web que se encargue de redirigir el tráco hacia cada uno de los servidores. El funcionamiento de un balanceador de tráco y su interacción con los servidores web está explicado en la Sección El caso más sencillo es cúando se necesita escalar un entorno web estático. En este caso, los cheros que contienen las diferentes páginas HTML deben ser replicados a todos los servidores. El balanceador de tráco se encarga de redirigir las peticiones de cada cliente a los distintos servidores. En un entorno web escalado de forma horizontal se debe tener muy en cuenta el tratamiento y persistencia de las sesiones. Tener sesiones almacenadas de forma local en cada servidor es una mala práctica. La solución pasa por tener sesiones centralizadas o, incluso mejor, no tener sesiones en absoluto. Cómo se trabaja con sesiones en entornos web con múltiples servidores se explica en la Sección Alta disponibilidad Escalando de forma horizontal los servidores web mediante el uso de un balanceador de tráco se aumenta la disponibilidad del servicio ya que si un servidor falla, el servicio no se ve afectado. Sin embargo, se sigue contando con un único punto de fallo, el balanceador de tráco. Por tanto, si se requiere un servicio web de alta disponibilidad se deben utilizar dos balanceadores de tráco. La arquitectura más sencilla es utilizar dos balanceadores en conguración de maestro/esclavo. De esta forma, el esclavo únicamente trabajará si el servidor maestro tiene algún problema.

53 2. Estado del arte 53 Los balanceadores de tráco hardware suelen venir preparados para su uso conjunto. De hecho, están incluso pensados para trabajar de forma activa/activa entre ellos. De esta forma no se desaprovecha la inversión realizada en el segundo balanceador sin tenerlo trabajando Herramientas de análisis de rendimiento web Un servidor web básicamente se encarga de atender peticiones de páginas web y responder con su contenido. Estas dos acciones tan básicas en realidad están compuestas por otras acciones. Se debe analizar la petición para saber a qué chero se está haciendo referencia, leerlo, interpretar su contenido, elaborar un contenido de respuesta y enviárselo al cliente. Todo este proceso añade un tiempo de espera al cliente, además del propio retardo debido a la comunicación entre ambos. Por tanto, al realizar una consulta a un servidor tendremos un cierto tiempo de respuesta. Este tiempo de respuesta viene determinado por la latencia existente entre el cliente y el servidor web y por el tiempo empleado por el servidor web en procesar la petición del cliente y ofrecerle un resultado. T respuesta = (T latencia 2) + T procesado La mejor forma de evaluar el rendimiento de un servidor web es someterlo a una cierta carga. Para ello, se simulan las visitas de clientes y sus diferentes peticiones de páginas web. Existen una gran variedad de aplicaciones de benchmarking web que realizan una batería de peticiones a una determinada dirección web. Es común en todas ellas congurar tres parámetros para la simulación: Dirección web: hacia dónde se realizarán las peticiones. Algunos benchmarks admiten un listado de direcciones web para realizar las pruebas. Número de peticiones: número total de peticiones a realizar. Concurrencia: número de peticiones concurrentes a realizar. Para la realización de este proyecto, se han evaluado tres alternativas de herramientas de análisis de rendimiento de servidores web: JMeter[13], http_load[14] y ab[15].

54 Escalado y alta disponibilidad en servidores web ab - Apache Benchmark ab es una herramienta de análisis de rendimiento para el servidor HTTP Apache. El resultado principal que proporciona este benchmark es el número de peticiones por segundo que el servidor web es capaz de atender. http_load http_load realiza varias peticiones HTTP en paralelo para medir el rendimiento de un servidor web. También puede realizar peticiones HTTPS. Se le debe proporcionar un chero de texto con la lista de URLs que debe evaluar. Puede realizar un análisis de checksums de los cheros descargados para comprobar que la petición ha sido correcta. Los checksums son calculados y guardados con la primera petición de cada URL. Posteriormente, con cada petición, son recalculados y comparados con el de la primera. Se debe especicar cómo empezar la simulación. Se le puede indicar que inicie la simulación manteniendo un número jo de peticiones paralelas. Otra opción es indicarle un ratio incremental para cada segundo. Es decir, desde que se empieza el benchmark, cada segundo comenzarán un número de peticiones predeterminadas por el usuario. A través de un parámetro se puede variar hasta un 10 %, la aleatoriedad del número de peticiones nuevas a crear cada segundo. El análisis puede nalizar tras un tiempo, en segundos, determinado. También puede nalizar cuando se alcancen un número de peticiones totales realizadas. JMeter JMeter es un software escrito en lenguaje Java diseñado para simular un comportamiento de visitas de página web y posteriormente, ofrecer un resultado de rendimiento. Dispone de una interfaz gráca y tiene soporte para plugins. JMeter es ideal no sólo para realizar un análisis de rendimiento de un servidor web, sino para simular todo el comportamiento que tiene un usuario al visitar una página web. Permite denir variables internas, como nombres de usuario, identicadores, entre otros, para ser usados posteriormente. Permite gestionar cookies de sesión de forma bastante sencilla y además denir una lista de páginas que servirán de ruta para simular la navegación de un usuario.

55 2. Estado del arte Balanceo de tráco En esta sección se explica en qué consiste el balanceo de tráco así como las técnicas más utilizadas. Para nalizar, se verán los algoritmos más comunes de balanceo que existen Introducción El balanceo de tráco es una técnica para distribuir la carga de forma equitativa entre dos o más servidores de forma que se obtenga una utilización de los recursos óptima, maximice el rendimiento, minimice el tiempo de respuesta y se evite la sobrecarga. El servicio de balanceo de tráco se ofrece a través de un programa destinado a tal efecto o bien a través de hardware dedicado. Debido a que es un sistema crítico, se suelen utilizar múltiples balanceadores para ofrecer mayor abilidad a través de redundancia Round Robin DNS Se trata de un método de balanceo de tráco que no requiere ningún tipo de hardware ni software especíco. Esta técnica de balanceo consiste en de- nir múltiples direcciones IP asociadas a un único dominio. En esta ocasión, esta técnica no resulta transparente para el usuario ya que es explícito el conocimiento de múltiples servidores. Cuando un cliente realiza una petición de DNS se le devuelve una lista de direcciones IP que identican una serie de servidores que proporcionan el mismo servicio. El orden en el que se proporcionan las direcciones IP está basado en una distribución round robin. Con cada respuesta de DNS, la lista se permuta. Sin embargo, no existe ningún procedimiento estándar denido por el cual se decida qué IP de la lista devuelta en la consulta debe ser utilizada. Normalmente, los clientes intentan realizar la conexión con la primera dirección de la lista. Utilizando esta técnica, las peticiones de diferentes clientes se distribuyen sobre los distintos servidores. Sin embargo, cabe mencionar que esta técnica presenta graves inconvenientes. El principal problema es que no realiza una comprobación de los servicios. Si uno de los servidores está inoperativo, esta técnica seguirá dando su IP en la lista y por tanto, habrá clientes que seguirán intentandose conectar sin éxito. Además, se presentan problemas secundarios debido a las cachés de la jerarquía de DNS, la caché DNS de los clientes, entre otros. Ejemplo: En la Figura 2.23 se puede observar como un usuario solicita la dirección del servidor web correspondiente a la página web web.com. El usuario contacta con el DNS del dominio web.com y solicita la

56 Balanceo de tráco Figura 2.23: Funcionamiento de la técnica round robin DNS. Fuente: propia. dirección del servidor El DNS le contesta utilizando la técnica de round robin y le proporciona tres IPs diferentes. El cliente decide, por algún motivo, conectarse con la segunda IP, En ningún momento se ha realizado ningún tipo de comprobación del servidor que corresponde a la IP Por tanto, añadir más IPs a un dominio a través de la técnica de round robin no proporciona ningún tipo de garantía Balanceadores de tráco Un balanceador de tráco es el encargado de repartir, siguiendo una serie de reglas, el tráco hacia un conjunto de servidores. Para el usuario, el hecho de que la comunicación hasta el servidor pase por uno, debe ser totalmente transparente. Un balanceador de tráco añade alta disponibilidad y fácil

57 2. Estado del arte 57 escalabilidad al servicio ofrecido por los diferentes servidores. El esquema básico de funcionamiento de un balanceador de tráco se puede observar en la Figura Es básicamente un programa que escucha en un puerto determinado, al cúal se conectan los usuarios que quieren acceder al servicio proporcionado. Este reenvía la petición a uno de los servidores. El servidor procesa la petición y le responde. Por último, el balanceador reenvía al usuario la respuesta del servidor. Durante este proceso, la existencia del balanceador es totalmente transparente para el usuario. Figura 2.24: Esquema de la comunicación entre el cliente y el servidor, pasando por el balanceador de tráco Fuente: propia.. El hecho de tener el balanceador situado entre el usuario y los servidores añade mayor seguridad ya que en ningún momento los usuarios conectan directamente con los servidores y la estructura de red interna queda totalmente enmascarada por él. En el caso de que todos los servidores no estén operativos, algunos balanceadores pueden realizar una acción especíca. Como por ejemplo, la visualización de un mensaje de error. La decisión de a qué servidor debe reenviar la petición del usuario se realiza mediante un conjunto de algoritmos de planicación. La complejidad de estos algoritmos es muy variable. Algunos simplemente realizan una elección aleatoria o siguiendo una distribución round robin. Otros algoritmos más complejos tienen en cuenta, por ejemplo, la carga de los servidores, los tiempos de respuesta, el número de conexiones activas o incluso la situación geográca del cliente Algoritmos de balanceo Existen multitud de algoritmos de balanceo de tráco. El principal objetivo de un algoritmo de balanceo es decidir a qué servidor en concreto debe

58 Balanceo de tráco reenviar una petición. Esta decisión dependerá de una serie de factores determinados por el algoritmo de balanceo elegido. A continuación se realiza una breve descripción de los algoritmos de balanceo más populares: Round Robin: distribución equitativa entre los servidores disponibles. Weighted Round Robin: asigna las peticiones a los servidores web según un peso asignado previamente. Los servidores con mayor peso reciben nuevas peticiones antes y, por tanto, procesan más peticiones que los servidores con menor peso. A igualdad de peso, la distribución se realiza de forma equitativa. Least Connection: el balanceador envía las nuevas peticiones a los servidores con el menor número de peticiones activas. Weighted Least Connection: asigna más peticiones a los servidores con menores peticiones activas en función del peso especíco de dicho servidor: C i W i Donde C i es el número de peticiones activas y W i el peso especíco del servidor. Locality-Based Least-Connection : asigna las peticiones provenientes de la misma IP al mismo servidor siempre y cuando el servidor esté disponible y no esté sobrecargado. En caso contrario, asigna la petición al servidor cuya carga sea menor. Locality-Based Least-Connection with Replication : asigna las peticiones provenientes de la misma IP a un grupo de servidores. Si todos los servidores del grupo están sobre cargados, asigna otro servidor, con poca carga, al grupo. En caso de que el grupo de servidores no se haya modicado en un tiempo, el servidor de ese grupo con la máxima carga es eliminado del grupo. Destination Hashing: asigna las peticiones mirando una tabla de hash asignada estáticamente según la IP de destino. Source Hashing: asigna las peticiones mirando una tabla de hash asignada estáticamente según la IP de origen de la petición. Shortest Expected Delay (SED): las nuevas peticiones se asignan al servidor cuya respuesta esperada sea la más rápida. El tiempo que

59 2. Estado del arte 59 tarda un servidor en dar una respuesta se mide mediante la siguiente ecuación: C i + 1 W i Donde C i es el número de peticiones activas que está procesando el servidor i y W i es el peso especíco de dicho servidor. Never Queue: las nuevas peticiones se asignan a un servidor que no esté procesando ninguna, en vez de esperar por uno con un peso mayor. En caso de que ningún servidor esté ocioso se aplica la política SED. Persistencia de sesiones Un problema a la hora de trabajar con balanceadores de tráco es cómo manejar la información que se debe almacenar durante las múltiples peticiones que se llevan a cabo durante una sesión de un usuario. Si esta información se almacena en los servidores entonces el balanceador debería de ser capaz de reenviar las peticiones de ese usuario al mismo servidor cada vez. Si no se hiciese así, la información de sesión podría encontrarse en un servidor diferente al cual ha sido dirigido el cliente. Una posible solución a este problema es enviar todas las peticiones de un usuario a un mismo servidor. Esta solución es la que se conoce como persistencia, en inglés persistence o stickiness. Como inconveniente, si el servidor al que un usuario es redirigido se cae, la información de sesión se pierde. Se produce el mismo problema si se cuenta con dos o más balanceadores de respaldo y el principal se cae, la tabla que relaciona la sesión entre usuarios y servidores se perderá. Otra solución al problema de las sesiones de los usuarios es almacenar los datos en una base de datos. Esta solución, si bien elimina el problema de la disponibilidad de la información, introduce un aumento de carga signicativo en la base de datos. Además, para prevenir que el servidor se convierta en un punto único de falla (single point of failure), se debe replicar la información en uno o varios servidores más, y se deben utilizar, de nuevo, técnicas de balanceo para repartir la carga entre las diferentes réplicas de la de base de datos. Afortunadamente existe una solución mucho más sencilla aplicable a este proyecto. Debido a que los usuarios nales del sistema acceden a través de un navegador web, los datos de sesión se pueden almacenar en él. Existen dos técnicas a través de las cuales se puede conseguir almacenar los datos de la sesión en el navegador del cliente:

60 Sistemas de cheros 1. Cookies: una cookie no es más que información que se almacena en el ordenador del visitante de una página web. Esta información la guarda el navegador del usuario, a petición del servidor web y puede ser recuperada por el servidor en cualquier momento de la sesión o, inclusive, en futuras visitas. 2. URL Rewriting: consiste en ir modicando la URL introduciendo en ella los datos de la sesión. Es un método más able que usar cookies, ya que algunos navegadores web están congurados para rechazarlas. Sin embargo, desde el punto de vista del programador es un método de mayor complejidad y menor elegancia. Aplicando alguna de estas dos técnicas de persistencia de sesión, el balanceador es libre de redigirir a los clientes a cualquiera de los servidores según el algoritmo elegido, sin tener en cuenta ninguna excepción debido a la persistencia de sesiones Sistemas de cheros En esta sección se realiza una breve introducción al concepto de sistema de cheros. A continuación se explican los diferentes sistemas de cheros que permiten compartir su información entre varios ordenadores. Para nalizar, se realiza un breve estudio sobre las características y funcionamiento de herramientas de medición de rendimiento Introducción Un sistema de cheros es un sistema software que proporciona a los usuarios y aplicaciones unos servicios para organizar y mantener información en forma de cheros y directorios. La capa intermedia permite que los usuarios o programadores dejen de lado el desarrollo de software especíco para tratar los cheros en cada aplicación. Así, un sistema de cheros no es más que un método de organización, almacenamiento y manipulación de cheros. Los cheros son simplemente información almacenada en un dispositivo físico. Algunos permiten ir más allá y permiten el acceso a la información a través de algún tipo de protocolo de red. En general, los sistemas de cheros deben cumplir los siguientes objetivos: Cumplir con las necesidades de gestión de información y con los requisitos de usuario. Esto incluye el almacenamiento de datos y la capacidad de realizar las operaciones necesarias. Para un sistema de cheros de

61 2. Estado del arte 61 propósito general, éstas son las necesidades o requisitos mínimos que deben cumplirse para cada usuario que: Debe ser capaz de crear, borrar y modicar cheros. Puede tener acceso controlado a los cheros de otros usuarios. Puede controlar qué tipos de acceso están permitidos a sus cheros. Debe poder reestructurar sus archivos de manera adecuada, según sus necesidades. Debe ser capaz de mover datos entre los cheros. Debe ser capaz de guardar copias de seguridad y recuperar sus cheros en caso de que ocurran errores. Debe ser capaz de acceder a sus cheros mediante un nombre simbólico. Garantizar, en la medida de lo posible, que los datos de los archivos son válidos. Optimizar el rendimiento, tanto desde el punto de vista del sistema, en términos de productividad global, como desde el punto de vista del usuario, en términos de tiempo de respuesta. Ofrecer soporte de I/O para la variedad de tipos de dispositivos de almacenamiento. Minimizar o eliminar la posibilidad de pérdida de datos. Ofrecer un conjunto estándar de rutinas de interfaz de I/O. Proporcionar soporte de I/O para múltiples usuarios en el caso de sistemas multiusuario. Los sistemas de cheros utilizan un dispositivo de almacenamiento que tiene un número de sectores físicos determinados. Es el encargado de organizar estos sectores en cheros y directorios, sabiendo qué sectores pertenecen a un determinado chero o directorio y qué sectores están sin ser utilizados. La gran mayoría utilizan unidades mínimas de información denominadas bloques que están formados por un número jo de sectores, normalmente entre 1 y 64. Un bloque es la cantidad mínima de espacio en el dispositivo de almacenamiento que ocupa un chero.

62 Sistemas de cheros Sistemas de cheros distribuidos Los sistemas de cheros distribuidos permiten el acceso a los cheros desde múltiples ordenadores a través de una red informática. De esta forma, múltiples usuarios en múltiples ordenadores pueden compartir cheros y dispositivos de almacenamiento. En este tipo de sistemas los clientes no tienen acceso directo a los bloques del dispositivo físico que alberga los cheros, sino que interactúan con él a través de un protocolo de red especíco. Es por ello que se pueden establecer mecanismos de seguridad para controlar el acceso a la información. Una de las claves de los sistemas de cheros distribuidos es que deben ofrecer transparencia al usuario. Así, los cheros que se acceden a través de la red pueden ser tratados igual que si se acceden a través de discos locales. Es importante desarrollar una correcta gestión de concurrencia entre clientes para asegurar la consistencia de datos, ya que, desde varios ordenadores, se debe poder acceder y modicar un mismo chero a la vez. Otro de los aspectos a tener en cuenta es el rendimiento. Una medida típica de rendimiento para sistemas de cheros es el tiempo necesario en responder una petición por parte del usuario. En sistemas convencionales, este tiempo es básicamente el tiempo de acceso al disco y un pequeño tiempo de procesamiento en la CPU. Sin embargo, en un sistema de cheros distribuido, existe una sobrecarga, o overhead, causada por la estructura distribuida. Se debe tener en cuenta el tiempo necesario para realizar la petición al servidor, el tiempo para entregar la respuesta al cliente y, en cada sentido, un pequeño tiempo de procesamiento debido al software del protocolo de comunicación. Los sistemas de cheros distribuidos ofrecen soporte de caché de cheros. Existen tres comportamientos típicos en la caché: Write-through: todos los cambios hechos en los clientes son escritos de inmediato en el servidor. Write-back: los cambios realizados en el cliente están guardados en la caché durante un tiempo determinado antes de ser escritos en el servidor. Write-on-close: tipo especíco de write-back en que los cambios son escritos al cerrar el chero. La elección del tipo de caché repercute en el rendimiento del sistema y en el tiempo que tardan las modicaciones en ser visibles por todos los clientes. Muchos sistemas de cheros distribuidos aceptan varios tipos, delegando la elección al administrador del servidor. Otros, en cambio, tienen sistemas

63 2. Estado del arte 63 mixtos, donde utilizan un tipo de caché para los meta-datos de los cheros y otro para la información propia del chero Sistemas de cheros de disco compartido Los sistemas de chero de disco compartido son utilizados normalmente en infraestructuras de clúster. Se reeren a un sistema de cheros que es utilizado, a la vez, en varios servidores. Un sistema de cheros de disco compartido requiere el uso de una Storage Area Network (SAN) para proporcionar acceso directo al disco a nivel de bloques. La traducción de operaciones a nivel de cheros en operaciones a nivel de bloques, utilizada por la SAN, se realiza en el propio servidor. Figura 2.25: Comparativa entre sistemas de cheros distribuidos y de disco compartido. Fuente: propia. Típicamente poseen un mecanismo a través del cual se establece un control de concurrencia que los sistemas de chero convencionales no poseen. Estos suelen tener mecanismos de control sobre el comportamiento de los nodos. Si uno de los servidores tiene un comportamiento erróneo, se le puede excluir del clúster para que no causase problemas de I/O al resto de miembros. Los sistemas de cheros de disco compartido pueden ser asimétricos y simétricos. Los asimétricos permiten que todos los servidores lean y escriban datos directamente a la SAN pero redirigen todos los cambios de meta-datos a un único servidor. En cambio, los simétricos permiten que todos los servidores lean y escriban, tanto datos como meta-datos, directamente en la SAN. En la Figura 2.25 se puede apreciar la diferencia entre los sistemas de cheros distribuidos y los sistemas de cheros de disco compartido. En el

64 Sistemas de cheros primer caso, un servidor con conexión directa al disco se encarga de compartir la información que contiene mediante un protocolo de red. En el caso de los sistemas de cheros de disco compartido, todos los servidores tienen conexión independiente con el disco y es el propio sistema de cheros el que monitoriza la concurrencia de accesos a la información Herramientas de análisis de rendimiento A lo largo del Capítulo 5 se realizan una serie de análisis y evaluaciones de alternativas de sistemas de cheros. Por una parte se analizan las características del sistema de cheros en sí y sus posibles incompatibilidades con un sistema de alta disponibilidad y por otra, se debe tener en cuenta que el hecho de tener la información sincronizada entre distintos servidores implica una pérdida de rendimiento por parte del sistema de cheros en comparación con el utilizado hasta el momento. Esta pérdida es debido a tener que dedicar tiempo a la propia sincronización de datos o accesos a los mismos. En esta sección se introducen las herramientas de análisis de rendimiento. Las herramientas o programas de análisis de rendimiento se suelen denominar benchmarks. Un benchmark no es más que un conjunto de procedimientos que se ejecutan para evaluar el rendimiento y funcionamiento, en este caso, de un sistema de cheros. A partir de los resultados generados por las pruebas del benchmark se pueden realizar comparativas entre distintos sistemas de cheros, obteniendo así una escala de rendimiento. Para la realización del análisis de rendimiento de los distintos sistemas de cheros se evaluaron dos programas de benchmarking alternativos, IOZone[16] y Bonnie++[17]. IOZone Se trata de una utilidad que genera y mide una gran variedad de operaciones sobre cheros. IOZone realiza una batería de pruebas de rendimiento de I/O sobre cheros. En concreto, las siguientes operaciones de prueba de rendimiento se llevan a cabo: Escritura: evalúa las escrituras sobre un nuevo chero. Cuando se crea un nuevo chero, no sólo se escriben los propios datos que contiene el chero, sino que también se escribe más información propia del sistema de cheros para poder tener un mapa de dónde está almacenada la información dentro del dispositivo físico de almacenamiento, llamada metadatos.

65 2. Estado del arte 65 Re-escritura: mide el rendimiento de escritura sobre un chero que ya existe. De esta forma, no se debe escribir información extra, únicamente la información que contiene el chero. Por este motivo, el rendimiento de re-escritura suele ser superior al rendimiento de escritura. Lectura: evalúa la lectura de información contenida en un chero ya existente. Re-lectura: lectura de un chero que ha sido recientemente leido. El rendimiento de re-lectura suele ser superior al de lectura debido a que el sistema operativo mantiene una caché de los datos de cheros que han sido recientemente leídos. Lectura aleatoria: evalúa la lectura sobre cheros. Esta lectura se realiza sobre puntos aleatorios dentro del chero. El rendimiento de esta prueba se ve afectado por características ajenas al sistema de cheros, como por ejemplo: tamaño de la caché del sistema operativo y el tiempo de seek. Escritura aleatoria: escritura a un chero de forma aleatoria. De nuevo, esta prueba se ve afectada por algunas características ajenas al sistema de cheros. Mezcla aleatoria: mide el rendimiento de lecturas y escrituras sobre un chero. Estas lecturas y escrituras se realizan sobre un punto aleatorio dentro del chero. Al igual que en las dos pruebas anteriores, ésta se puede ver afectada por algunas características ajenas al sistema de cheros. IOZone para llevar a cabo esta prueba genera varios procesos o hilos, de forma que cada uno de ellos realice únicamente una prueba de escritura o lectura aleatoria. La distribución de las lecturas y escrituras se realiza mediante una distribución round robin. Lectura inversa: evalúa la lectura de un chero de forma inversa. Algunos programas leen la información de los cheros de forma inversa. Re-escritura de bloques de datos: mide el rendimiento de escritura y re-escritura de una zona particular de un chero. Dependiendo del tamaño de la zona del chero, se obtienen resultados muy diversos: 1. Si es lo sucientemente pequeño para ser almacenada en la propia caché de la CPU, el rendimiento es extremadamente elevado. 2. Si es mayor al tamaño de la caché de la CPU pero es lo sucientemente pequeño para ser almacenada en la TLB el rendimiento es elevado, pero siempre menor al caso anterior.

66 Sistemas de cheros 3. Si es mayor al tamaño de la TLB y, por tanto, mayor al tamaño de la caché de la CPU, pero menor al tamaño de la caché del sistema operativo, se obtiene un rendimiento inferior a los dos casos anteriores. 4. Si nalmente el tamaño de la zona es mayor al tamaño de la caché del sistema operativo se obtiene el menor rendimiento. Lectura strided: evalúa la lectura de un chero siguiendo un patrón determinado. Por ejemplo, se leen 4 KB a partir de una posición, después se leen otros 4 KB desplazándose 200 KB del punto anterior y así sucesivamente. Fwrite: evalúa la escritura a un chero mediante la función fwrite() 3. Las escrituras mediante la función fwrite() se realizan a través de un buer. De esta forma, en algunos casos, el rendimiento de escritura se puede ver incrementado mediante el uso de esta función. Esta prueba realiza las escrituras sobre cheros que se deben crear previamente, de forma que se incluye la escritura de los metadatos del chero. Frewrite: escritura a un chero mediante la función fwrite(). La diferencia con la prueba anterior radica en que en esta prueba se realiza la escritura sobre cheros ya creados, de forma que el rendimiento se ve aumentado. Fread: lectura a un chero mediante la función fread() 3. Las lecturas mediante la función fread() se realizan a través de un buer. En algunos casos, de lecturas de pequeño tamaño, se puede ver incrementado el rendimiento de lectura mediante el uso de esta función. Freread: evalúa la lectura a un chero mediante la función fread(). En este caso, y a diferencia de la prueba anterior, el chero ha sido previamente leido de forma reciente. Mmap: mide el rendimiento de I/O utilizando la función mmap() 4 que mapea en memoria un chero, o parte del mismo. Async I/O: mide el rendimiento del estándar POSIX en operaciones I/O asíncronas mediante las funciones aio_write(), aio_read(), 3 Las funciones fread() y fwrite() realizan operaciones de I/O de forma binaria. Forman parte de los estándares C89 y POSIX Se encuentran denidas en la librería de C stdio.h. 4 La función mmap() se encuentra denida en la librería de C sys/mman.h.

67 2. Estado del arte 67 aio_error() 5, entre otras. En este proyecto, IOZone se ha utilizado para comparar el análisis de rendimiento en detalle de tres sistemas de cheros. IOZone no sólo proporciona información detallada sino que además ofrece un alto nivel de conguración de parámetros para simular diversos entornos de carga. Bonnie++ Bonnie++ es un benchmark más sencillo que IOZone. Realiza una serie de pruebas simples de rendimiento sobre el sistema de cheros, simulando el comportamiento de aplicaciones. Bonnie++ está basado en Bonnie, otro benchmark, pero re-escrito en el lenguaje de programación C++. En comparación a Bonnie, Bonnie++ añade soporte para probar más de 2 GB de almacenamiento en máquinas de 32 bits y pruebas de cheros utilizando las funciones creat(), stat() 6 y unlink() 7. Además, el resultado del benchmark se puede presentar en formato Comma Separated Values (CSV). Bonnie++ proporciona un programa, denominado bon_cvs2html que genera tablas en formato HTML a partir del resultado en formato CSV. Las pruebas que Bonnie++ realiza son las siguientes: Escritura secuencial Por caracteres: se escribe sobre un chero utilizando la función putc() 8. Bloques: similar a la anterior, pero el chero se escribe y se crea mediante la función write() 9. 5 Las funciones aio_write(), aio_read() y aio_error() realizan operaciones de I/O asíncronas. Forman parte del estándar POSIX Se encuentran denidas en la librería de C aio.h. 6 La función creat() crea un nuevo chero. La función stat() da información sobre un chero (tamaño, permisos, propietario, entre otros). Ambas funciones forman parte del estándar POSIX Se encuentran denidas en la librería de C sys/stat.h. 7 La función unlink() elimina una entrada de directorio. Se encuentra denida en la librería de C unistd.h. 8 Las funciones putc() y getc() realizan operaciones de I/O a nivel de caracteres. Forman parte del estandar C89 y C99. Se encuentran denidas en la librería de C stdio.h. 9 Las funciones read() ywrite() realizan lecturas y escrituras, respectivamente, sobre cheros. La función lseek() se encarga de modicar el oset para las operaciones de lectura y escritura. Forman parte del estándar POSIX Se encuentran denidias en la libreria de C unistd.h.

68 Sistemas de cheros Re-escritura: una parte del chero es leída mediante la función read(), modicada y re-escrita mediante la función write() 9, prosiguiendo a la siguiente parte del chero, mediante la utilización de la función lseek() 9. Lectura secuencial Por caracteres: mide el rendimiento de lectura sobre un chero utilizando la función getc() 8. Bloques: a diferencia de la prueba anterior, en esta se utiliza la función read() para realizar las lecturas sobre el chero de prueba. Posicionamiento aleatorio de cabezales: en ella, se ejecutan varios procesos (por defecto 3) en paralelo, ejecutando la función lseek() un total de 8000 veces para reposicionar el cabezal del disco en diferentes zonas del chero de prueba. La zona hacia la cual se posiciona mediante lseek() se determina aleatoriamente mediante la función random() 10. Una vez posicionados correctamente, se lee el bloque mediante read(). En el 10 % de los casos, este bloque se modica y se re-escribe mediante la función write(). Tratamiento secuencial de cheros: se crean los cheros en orden numérico. Posteriormente, y en el orden indicado por la función readdir() 11, se obtienen datos sobre los cheros a través de la función stat(). El orden en que estén almacenados en el directorio, muy probablemente, sea el mismo en el cual fueron creados. Por último, se eliminan los cheros en el mismo orden. Tratamiento aleatorio de cheros: se crean los cheros en un orden aleatorio para el sistema de cheros pero no aleatorio para el benchmark. Se crean los cheros en el orden indicado por el último dígito del nombre del chero y el benchmark se realiza siempre en el orden númerico. Para medir el rendimiento, una vez creados, se ejecuta la función stat() en orden numérico sobre ellos y nalmente se eliminan todos los cheros en orden aleatorio. En este proyecto, se ha utilizado Bonnie++ para realizar una comparativa rápida entre el rendimiento de diversos sistemas de cheros. El uso sencillo de 10 La función random() genera un número aleatorio. Forma parte del estándar POSIX Se encuentra denida en la librería de C stdlib.h. 11 La función readdir() lee el contenido de un directorio. Forma parte del estándar POSIX Se encuentra denida en las librerías de C sys/types.h y dirent.h.

69 2. Estado del arte 69 la aplicación y la sencillez de los resultados proporcionan datos y resultados que rápidamente pueden ser comparados Escalado y alta disponibilidad en servidores de BBDD A lo largo de esta sección se realiza una introducción a las bases de datos así como a los SGBD. A continuación se analizarán las soluciones existentes para que un SGBD sea escalable y disponga de una disponibilidad elevada Introducción a las bases de datos Las bases de datos surgieron gracias a la necesidad de las grandes empresas de almacenar ingentes cantidades de información de forma rápida, sencilla y able. Esta información debe ser accesible y modicable en cualquier momento de forma remota. Las bases de datos se suelen clasicar según su modelo de datos. Este indica dónde y cómo se guarda la información, y los métodos para almacenar, modicar y recuperar la información. Algunos de los modelos más utilizados en bases de datos son: Bases de datos jerárquicas: almacenan su información en una estructura jerárquica. Los datos se organizan en forma de árbol, donde cada nodo puede tener varios hijos y un único padre. Un nodo sin padre se denomina raíz y un nodo sin hijos se denomina hoja. Su principal limitación es la incapacidad de representar ecientemente la redundancia de datos. Bases de datos transaccionales: su principal característica es el envío y recepción de datos a gran velocidad. La redundancia o duplicidad de datos no deben ser un problema si se quiere utilizar este tipo de bases de datos. Bases de datos relacionales: todos los datos son almacenados en relaciones y, a diferencia de otros modelos, el orden en el que estos datos se almacenen no tiene relevancia. Este modelo considera las bases de datos como un conjunto de relaciones. Una relación no es más que la representación de una tabla. Esta tabla tiene una serie de las, cada la con sus campos, o atributos, y cada campo contendrá un valor que tendrá una interpretación. Cada una de estas las contenida en la

70 Escalado y alta disponibilidad en servidores de BBDD relación se denomina `tupla'. Para manipular la información se utiliza un lenguaje relacional. El lenguaje más común para realizar consultas es Structured Query Language (SQL). A una consulta se la denomina query Introducción a los sistemas gestores de bases de datos El programa encargado de almacenar, acceder y modicar los datos de forma estructurada es el SGBD, de forma que actúa de interfaz entre la base de datos, el usuario y las aplicaciones que acceden. Deben cumplir una serie de objetivos: Abstracción de la información ahorrando detalles sobre la forma de almacenamiento físico de los datos, haciendose transparente para el usuario. Independencia de los datos, de forma que se pueda modicar el esquema, tanto físico como lógico, de la base de datos sin tener que realizar cambios en las aplicaciones que la utilizan. Consistencia: en los casos donde no se ha logrado eliminar la redundancia, es necesario vigilar que la información repetida se actualice de forma coherente. Seguridad: la información almacenada en una base de datos debe tener algún sistema de permisos para usuarios y grupos de usuarios, que le otorgan diversos privilegios. Manejo de transacciones: una transacción es un conjunto de operaciones que se ejecuta como si se tratara de una sola operación. Es decir, si se produce un fallo en alguna de las operaciones, el resultado debe ser el mismo que si no se hubiera ejecutado la transacción. Los SGBD deben proporcionar mecanismos para realizar transacciones de forma segura. Tiempo de respuesta: de forma lógica, se debe intentar optimizar el tiempo de respuesta. Los SGBD que cumplan estos objetivos proporcionan facilidades para la manipulación de grandes volúmenes de datos. Existen una gran cantidad de SGBD de todo tipo de licencias. Con licencias libres destacan MySQL[18], PostgreSQL[19] y SQLite[20]. En cuanto a licencias no libres, los más conocidos son Oracle[21], Microsoft SQL Server[22] y DB2[23].

71 2. Estado del arte Escalabilidad Debido al funcionamiento propio de los sistemas gestores de bases de datos, donde se leen y escriben datos constantemente, la escalabilidad es compleja. La escalabilidad de forma vertical, que consiste en agregar más recursos o bien sustituirlos por unos más potentes, suele ser la solución más sencilla. También es la propuesta que mejor se adapta para escalar un sistema gestor de base de datos ya que no hace falta adaptar el software, ni modicar la estructura de la base de datos, ni reprogramar el código de las aplicaciones que trabajan con la base de datos. Sin embargo, tal y como se ha visto anteriormente en la Sección 2.1, la escalabilidad vertical tiene un límite. Llegados a un cierto punto, no existen servidores más potentes, por lo que seguir escalando de forma vertical es imposible. Por tanto, en caso de que fuese necesario seguir escalando, se convierte en imprescindible hacerlo de forma horizontal. Replicación de base de datos La replicación de base de datos permite que ciertos datos sean almacenados en más de un servidor de forma que se crea un sistema de bases de datos distribuido. La sincronización entre los servidores se realiza de forma periódica y con una jerarquía de maestro/esclavo. Es decir, las escrituras y modicaciones siempre se realizan en los servidores maestros y, posteriormente, de forma periódica, se propagan los cambios a los servidores esclavos. Sin embargo, las consultas, que representan la mayoría de las operaciones que se realizan en una base de datos, se pueden realizar a cualquier servidor, sea maestro o esclavo. Los benecios de aplicar esta técnica son múltiples: Se incrementa la disponibilidad de los datos ya que la información se encuentra replicada en múltiples servidores. En caso de fallo en alguno de los nodos, la recuperación de la información es sencilla, ya que los datos están disponibles en el resto de nodos. En el caso de las consultas, el rendimiento se ve aumentado ya que se dispone de más servidores independientes a los cuales consultar. El aumento del número de servidores hace que la carga individual producida por las operaciones de consulta se vea reducida.

72 Escalado y alta disponibilidad en servidores de BBDD Figura 2.26: Replicación de base de datos. Fuente: propia. De forma que el sistema sea escalable, deberemos contar con algún mecanismo para balancear las operaciones de consulta sobre los distintos servidores esclavos que se posean. En la Figura 2.26 se observa como las operaciones de escritura se dirigen al servidor maestro mientras que las operaciones de consulta se balancean entre los servidores esclavos. Los servidores esclavos se sincronizan periódicamente con el servidor maestro de forma que la información contenida en ellos sea la misma. Partición de base de datos Una partición es una división de una base de datos en varias partes. Normalmente, el objetivo es incrementar la disponibilidad, el rendimiento y el tratamiento de los datos almacenados. Esta técnica se utiliza a menudo en sistemas de administración de base de datos distribuidas. De esta forma, con particiones repartidas en múltiples nodos, los usuarios pueden realizar transacciones de forma local sobre la partición. Así se incrementa el rendimiento y la disponibilidad de los datos. Existen dos tipos de particionamiento, según se dividan los datos: División horizontal en particiones 12 : esta técnica también se conoce como sharding. Consiste en poner diferentes las en diferentes tablas. 12 Conocida comúnmente, en inglés, por horizontal partitioning o sharding.

73 2. Estado del arte 73 División vertical en particiones 13 : implica la creación de tablas con menos columnas y utilizar más tablas para almacenar las columnas restantes. El proceso de normalización también implica la división de las columnas entre varias tablas, pero el particionamiento vertical va más allá. Se pueden utilizar distintos dispositivos físicos de almacenamiento para guardar tablas con diferentes usos. Un uso común de particionamiento vertical es dividir el contenido dinámico del estático. La división en particiones se debe realizar siguiendo un criterio determinado. Algunos de los criterios más comunes son: División según el rango: se determina la partición determinando si la clave está dentro de un rango. División según una lista de valores: cada partición tiene asociada una lista de valores. Si la clave tiene alguno de esos valores, se selecciona dicha partición. Disivión por hash: se aplica una función de hash a la clave y el resultado determina la partición a la que pertenece. La consecuencia es una agrupación pseudo-aleatoria en grupos de un tamaño similar. Estos criterios también se pueden combinar entre ellos, aplicándolos de forma secuencial. Sharding Sharding es un método de división horizontal en particiones de una base de datos. En la división horizontal, se divide una base de datos según las, almacenándose de forma separada, en vez de columnas. Cada partición individual se denomina shard. Este tipo de división hace que el número total de las en cada tabla sea menor. Este decrecimiento hace que el tamaño de los índices sea mucho menor, mejorando los tiempos de búsquedas. Estas agrupaciones tienen que estar hechas de algún modo que tenga sentido y que permita un direccionamiento más rápido. Cada shard o agrupación está localizada en tablas de diferentes bases de datos y, posiblemente, hardware diferente. Por tanto, es posible tener shards repartidas entre varios servidores en localizaciones físicas diferentes. La técnica de sharding permite mejorar la escalabilidad y el rendimiento al agrupar menos datos en tablas más pequeñas; por lo que los accesos son 13 Conocida comúnmente, en inglés, por vertical partitioning.

74 Escalado y alta disponibilidad en servidores de BBDD mucho más rápidos. En caso de tener múltiples servidores en múltiples localizaciones, basar el sharding en la localización geográca puede ayudar a disminuir la latencia. Es necesario aplicar técnicas de sharding cuando el volumen de datos empieza a ser intolerable debido a su gran tamaño. A tablas más grandes, mayor es el tiempo de acceso. Además, conviene aplicar esta técnica cuando el volumen de escrituras es muy elevado. Es posible que el subsistema de I/O no sea capaz de realizar tantas escrituras simultáneas, o que los servidores de bases de datos esclavos no sean capaces de sincronizarse correctamente. Además, en un entorno de base de datos realizar muchas escrituras implica una serie de bloqueos que probablemente repercuta en un mayor tiempo de respuesta a los usuarios. Sin embargo, no siempre puede ser positivo aplicar esta técnica. Es importante tener en cuenta dos razones antes: 1. La persona encargada del desarrollo de la aplicación que ataca a la base de datos debe escribir código especíco para trabajar con sharding. Sin embargo, existen frameworks, como HiveDB[24], que facilitan esta tarea. 2. Las operaciones de administración de la base de datos se complican. Añadir nuevos índices o modicar el esquema de las tablas se puede convertir en un verdadero quebradero de cabeza. NoSQL Debido a los problemas de escalabilidad presentados por los sistemas gestores de bases de datos tradicionales basados en SQL, se ha creado el movimiento NoSQL. Este movimiento trata de impulsar alternativas muy distintas a las que hasta ahora han propuesto los productos basados en SQL. Históricamente las aplicaciones se han apoyado en sistemas de bases de datos relacionales, muy verticales y cuya escalabilidad ha empezado a verse comprometida. Estas situaciones han hecho que diversos desarrolladores hayan pensado en una forma diferente de almacenar los datos y de ahí surgió el movimiento NoSQL. Muchas empresas, ante los problemas de escalabilidad de las bases de datos tradicionales, decidieron desarrollar sus propias bases de datos. El primero fue Google con BigTable[25]. Posteriormente Amazon lanzó Dynamo[26] y Facebook hizo lo propio con Cassandra[27]. Todos estos proyectos se caracterizan por abandonar el modelo relacional de base de datos, en favor de un diseño de base de datos distribuida de alta escalabilidad.

75 2. Estado del arte Alta disponibilidad Los SGBD son los que proporcionan el acceso de información a múltiples aplicaciones. Por tanto, una alta disponibilidad en el servicio de base de datos es fundamental para poder asegurar la disponibilidad de los servicios que dependen de él. A grandes rasgos existen dos técnicas para proporcionar alta disponibilidad a un SGBD, replicación y clúster. Replicación de base de datos La replicación de base de datos, en su forma más simple, no ofrece una alta disponibilidad total. El servidor maestro se convierte en el único punto de fallo en el caso de las modicaciones y escrituras. Por tanto, es necesario contar con un servidor maestro secundario en caso de que el primario tenga algún problema. Para evitar tener ocioso el segundo servidor maestro, muchos de los SGBD soportan replicación de base de datos con múltiples maestros. Este método de replicación de base de datos permite que la información esté almacenada en un grupo de servidores, al igual que en la replicación maestro/esclavo. Sin embargo, la información puede ser actualizada en cualquiera de los servidores. El sistema de replicación de múltiples maestros se encarga de propagar las modicaciones realizadas por cada uno de los servidores y de resolver, en caso de que existan, conictos provenientes de cambios simultáneos entre diferentes servidores. Este sistema de replicación permite tener varios servidores maestros distribuidos en localizaciones físicas diferentes, aumentando así la disponibilidad del servicio de base de datos. Además, se cuenta con servidores esclavos que se sincronizan de forma periódica con los servidores maestros y que reciben todas las consultas a base de datos, aligerando así la carga de los servidores maestros. Las escrituras se deben seguir realizando sobre alguno de los servidores maestros. Al contar con más servidores maestros que deben sincronizarse entre sí recíprocamente se aumenta el tiempo de respuesta de algunas operaciones sobre la base de datos. Además, a medida que el número de servidores aumenta, también se incrementa el número de conictos a resolver, impactando así de forma negativa en el rendimiento del servicio. Clustering de base de datos Un clúster no es más que la comunicación entre varios servidores que trabajan como si de uno sólo se tratase. El conjunto es visto como un único servidor. Cada uno de los nodos que lo componen no tienen porque tener

76 Escalado y alta disponibilidad en servidores de BBDD las mismas características hardware ni estar en la misma localización física. Estas características proporcionan escalabilidad prácticamente innita al sistema, ya que tan sólo hay que añadir nuevos nodos. Además, proporciona alta disponibilidad, ya que si un nodo no está disponible, el clúster sigue funcionando. Una de las principales características de un clúster de base de datos es el denominado shared-nothing. Esta arquitectura dene que cada nodo del clúster debe ser independiente y autosuciente, sin la existencia de un único punto de fallo. En el Capítulo 6 se ve en profundidad el funcionamiento de un clúster de base de datos. En concreto se analizará el MySQL Cluster.

77 Capítulo 3 El servicio de educación virtual de la UIB En este capítulo se realiza una breve descripción de la arquitectura necesaria para la plataforma de educación virtual Moodle. Posteriormente, se realiza un repaso de la evolución de la infraestructura tecnológica de este servicio en la UIB en los últimos años. Para nalizar, se describe la infraestructura tecnológica del Centre de Tecnologies de la Informació (CTI) y se ve en detalle la parte dedicada a virtualización de servidores, sobre la cual se basa la nueva infraestructura de alta disponibilidad y escalabilidad del servicio de educación virtual Introducción a Moodle Moodle es un sistema de Learning Management System o sistema de gestión de aprendizaje (LMS) que permite crear cursos y comunidades de aprendizaje virtual, distribuido bajo la licencia GNU GPL. El nombre de Moodle viene del acrónimo Module Object-Oriented Dynamic Learning Environment. Actualmente es el sistema utilizado por la UIB para el servicio de educación virtual denominado Campus Extens. Contiene una serie de herramientas que facilitan el proceso de enseñanza y aprendizaje a través de Internet, además de complementar el aprendizaje clásico presencial. Existen una serie de características que le hacen un sistema de LMS muy robusto. Estas características se podrían englobar en cuatro grupos: 1. Características generales Promueve la pedagogía constructiva donde la colaboración, actividades y comentarios entre el profesor y sus alumnos es constante. 77

78 Introducción a Moodle Permite la realización de clases en línea, además de ayudar a complementar el aprendizaje presencial. La interfaz web es sencilla y ligera. 2. Administración del portal Administración general a través de la gura del usuario administrador. Soporte de módulos para ampliar las características ofrecidas por el software. Traducción a una gran cantidad de idiomas (35 actualmente). Entre ellos castellano y catalán. Fácil personalización de la página web a través del uso de "temas". 3. Administración de los usuarios Se pueden crear usuarios nuevos de varias formas: alta por correo electrónico, LDAP, base de datos, entre otros. Cada uno de los usuarios tiene un rol asignado; donde destacan administrador, profesor o alumno. Según el rol del usuario, se le asignan unos permisos de seguridad que le otorgan una serie de privilegios. Cada usuario puede denir una serie de conguraciones propias como son la zona horaria, el idioma de la interfaz, datos de perl entre otros. 4. Administración de los cursos El profesor tiene control total sobre la conguración de sus cursos. Cada curso puede contener foros, diarios, material didáctico, encuestas, exámenes y tareas. Se pueden calicar las actividades de cada alumno de forma centralizada. El profesor tiene acceso a informes de actividad de cada estudiante. Todas estas características hacen que Moodle tenga un importante número de usuarios en todo el mundo. De hecho, segun estadísticas ofrecidas por la propia web de Moodle[28] existen en julio de 2011 unos sitios registrados en 212 países. En ellos, más de usuarios y de profesores comparten educación en más de de cursos. Actualmente,

79 3. El servicio de educación virtual de la UIB 79 España es el segundo país del mundo en el uso de Moodle, únicamente por detrás de Estados Unidos. En el caso concreto de la UIB la plataforma de educación virtual está destinada a más de cursos, integrados por más de profesores y alumnos, según estadísticas de julio de En términos de arquitectura, esta plataforma de educación virtual es una aplicación web que se ejecuta sobre un servidor web que soporte PHP, el lenguaje con el que está programado. Además es necesario disponer de un SGBD para almacenar los datos. Ha sido desarrollado utilizando MySQL. Sin embargo, utiliza la librería ADOdb para proporcionar una capa de abstracción de la base de datos, de forma que se pueden utilizar diferentes SGBD. Por último, para proporcionar una interfaz al usuario hace falta un servidor web con soporte para PHP. En la documentación y foros ociales de Moodle existe una gran unanimidad en cuanto a la conguración de la arquitectura software con la que debe contar el sistema. GNU/Linux como sistema operativo, Apache como servido web, MySQL como SGBD. También se recomienda el uso de un acelerador de PHP para proporcionar al sistema de un sistema de caché Apache Apache es un servidor web de código abierto y está disponible para multitud de plataformas: PC Windows, Unix (BSD, GNU/Linux, entre otros) y Mac OS entre otras. Apache está desarrollado dentro del proyecto HTTP Server de la Apache Software Foundation[29]. Es el servidor HTTP más usado, alcanzando su mayor cuota de mercado en el año 2005, con aproximadamente el 70 % de páginas web del mundo[30]. En los últimos años, ha sufrido un descenso de cuota de mercado debido, principalmente, a dos motivos muy relacionados: 1. Cada vez el servidor web Apache es capaz de hacer más cosas a través del uso de módulos. Esta característica ha hecho que el proyecto Apache sea más grande cada vez, aumentando la posibilidad de fallos de seguridad, la curva de aprendizaje de administración y, a su vez, los recursos necesarios para ejecutarlo. 2. Debido a su crecimiento y a la gran cantidad de recursos que demanda, han surgido alternativas ligeras con una demanda de recursos mucho menor. Algunos ejemplos de estas alternativas son: lighttpd[31] o nginx[32], entre otros. Algunas de las principales características de este servidor web son:

80 Introducción a Moodle Tal y como se ha comentado anteriormente, es modular. Por tanto, ciertas funcionalidades se pueden habilitar/deshabilitar según las necesidades del usuario, por ejemplo: SSL: soporte para comunicaciones seguras vía TLS/SSL. Rewrite: posibilidad para reescribir las direcciones web. PHP: soporte para páginas dinámicas en lenguaje PHP. Es de código abierto. Es multiplataforma. Estándar de mercado. Amplia documentación y soporte PHP PHP es un lenguaje de programación interpretado diseñado para la creación de páginas web dinámicas, pudiendo ser empotrado en páginas HTML. Su interpretación se realiza del lado del servidor, donde se genera, de forma dinámica, una página web HTML a través de un intérprete de PHP. Esta página web HTML es la que se envía al cliente. Es decir, el proceso dinámico, para el cliente, es transparente. Una página web escrita en PHP es interpretada en el servidor web antes de ser mostrada. Este proceso se repite cada vez que una página es visitada por un usuario. Un acelerador de PHP se encarga de mejorar el rendimiento de los scripts. Utiliza una caché con la versión de los scripts ya interpretados. Debido a la gran cantidad de usuarios del sistema de educación virtual, se decidió utilizar un acelerador para disminuir, en la medida de lo posible, el tiempo de respuesta de los servidores web. Como acelerador PHP se decidió utilizar eaccelerator[33] que, además de cachear la versión interpretada de los scripts, también los optimiza, de forma similar a como optimiza código un compilador. Según los desarrolladores, se reduce la carga y se aumenta la velocidad de ejecución entre 1 y 10 veces. eaccelerator guarda los scripts interpretados en memoria compartida, de forma que se ejecuten directamente desde allí, reduciendo el tiempo de acceso al código. Si el tamaño es demasiado grande para almacenarse en memoria compartida, se almacena en disco. Tan sólo se producen bloqueos al buscar un script en la caché. De esta forma, es perfectamente posible ejecutar un único script simultáneamente por varios procesos.

81 3. El servicio de educación virtual de la UIB MySQL MySQL es el SGBD recomendado por los desarrolladores de Moodle, es un SGBD multihilo, multiusuario y multiplataforma. En el Capítulo 6 se realiza una introducción a MySQL, así como su funcionamiento. Es propiedad de Oracle Co. y posee una licencia dual. Por un lado, se ofrece bajo licencia GNU GPL y por el otro, para empresas que lo quieran incorporar en aplicaciones privativas, existe una licencia especíca. Se trata de uno de los SGBD más utilizados en aplicaciones web. De hecho, existe un estándar de mercardo para la web denominado LAMP: Linux + Apache + MySQL + PHP, sobre el que Moodle está basado. Como principales características de MySQL se pueden destacar: Multiplataforma. Cumple con el estándar ANSI SQL 99, añadiendo algunas extensiones. Escrito en lenguaje ANSI C / ANSI C++. Soporte para procedimientos almacenados, o stored procedures. Soporte para triggers. Posee varios sistemas de almacenamiento independientes. Más información disponible en la Sección D.4. Sistema de caché propio. Soporte para replicación. Posibilidad de conguración en clúster Evolución de la arquitectura En esta sección se explica brevemente la evolución que ha tenido el sistema de educación virtual en la UIB durante los últimos años hasta llegar al momento en que este proyecto se lleva a cabo Primeras pruebas con Moodle La UIB inició el proyecto de educación virtual durante el curso con la plataforma de software WebCT[34]. Debido a sus altos costes y a diversas carencias de WebCT, se decidió realizar un proyecto piloto de

82 Evolución de la arquitectura implantación de Moodle[35] durante el curso académico El objetivo era evaluar Moodle como nueva plataforma de educación virtual para la universidad. Este proyecto piloto se realizó sobre el mismo hardware y sistema operativo de la plataforma WebCT. En concreto, se instaló la versión de Moodle y se utilizó MySQL 4.0 como SGBD. El proyecto piloto fue todo un éxito y se decidió migrar de WebCT a Moodle para el curso académico siguiente Migración a Moodle en la UIB Durante el curso académico ya se había implantado Moodle como plataforma para el servicio de educación virtual en la UIB. En comparación con el proyecto piloto del año anterior, se actualizó de versión de Moodle, en concreto a la 1.5.4, y se mantuvo la versión de MySQL. Para este curso académico, el servicio ya contaba con hardware propio compuesto por un servidor Dell PowerEdge 2850, cuyas características se pueden observar en el Cuadro 3.1. En este servidor se ejecutaba el servidor web Apache, y el servidor de base de datos MySQL. Físicamente, este servidor se situó en el CPD del CTI. Procesador (modelo) Intel Xeon Procesador (GHz) 3.2 N o procesadores 2 N o núcleos 4 Mem. RAM (MB) 7862 N o tarj. Ethernet 4 Cuadro 3.1: Características hardware del servidor Dell PowerEdge 2850 de Moodle. Durante el curso académico se actualizó a la versión 1.8 y 4.1 de Moodle y MySQL, respectivamente. Además, se incorporó a la plataforma el acelerador de PHP eaccelerator, para mejorar el rendimiento global del sistema Dos servidores, principios de redundancia A lo largo del año 2008, se instala y congura un segundo servidor físico para la plataforma de Moodle. Este servidor es un Dell PowerEdge 2650,

83 3. El servicio de educación virtual de la UIB 83 de similares características hardware que el primero. Únicamente los procesadores son distintos, pasando a ser de 64 bits. En este servidor se instala exáctamente el mismo software. Físicamente, este segundo servidor se ubicó en el CPD del edicio Gaspar Melchor de Jovellanos. De esta forma, se encuentra un servidor en cada CPD. En un principio, este servidor se utiliza como una solución redundante del primero. Es decir, es un backup en caso de que ocurra algún error que impida dar servicio con el primer servidor. Estas soluciones de redundancia de datos consisten en realizar una sincronización periódica de datos entre ambos servidores, mediante el uso de una sincronización periódica de datos. A nivel de BBDD se realiza también una conguración que asegure una redundancia de datos y una cierta escalabilidad. En concreto, se activa la replicación en MySQL con una conguración de maestro/esclavo, utilizando ambos servidores. De esta forma, el contenido de las BBDD y sus operaciones son sincronizadas entre ambos servidores periódicamente de forma automática. Para más información sobre el funcionamiento de la replicación en MySQL se puede consultar la Sección Posteriormente, para compensar la carga entre ambos servidores, se dedica un servidor físico a proporcionar servicio web y como esclavo de MySQL. El otro servidor físico, proporciona el servicio de MySQL maestro y se mantiene como backup para proporcionar el servicio web. El esquema de situación de servidores y servicios se detalla en la Figura 3.1. El funcionamineto de la replicación maestro/esclavo se encuentra explicado en la Sección Finalmente, durante el año 2009 se actualiza MySQL a la versión 5.0. La arquitectura mostrada en la Figura 3.1 es la situación de partida de este proyecto Uso de la plataforma Tal y como se ha visto al principio de este capítulo, esta plataforma da servicio a más de docentes y alumnos. Estos dos grupos de personas representan la mayoría de usuarios de Moodle en la UIB. Sin embargo, no son los únicos ya que como se ha visto anteriormente también existe la gura del administrador. Esta gura no es única y está compuesta por los miembros de la ocina de Campus Extens[36] y personal del CTI. Los administradores se encargan del mantenimiento de la plataforma en sí, actualizaciones de software, gestión de usuarios y preparación de los cursos, entre otras tareas. Una vez que un curso se encuentra creado, es responsabilidad del profesor, y de los alumnos en menor medida, dotarlo de contenido. Para el servicio de educación virtual en la UIB se crearon diversos portales que separan a los alumnos y profesores en grupos, según los estudios que estén

84 Evolución de la arquitectura Figura 3.1: Arquitectura Moodle con dos servidores. Fuente: propia. cursando. La clasicación que existe para el curso es la siguiente: PAT: portal dedicado a tutorías de inicio de estudios así como de seguimiento. ESTUDIS: portal dedicado las asignaturas impartidas en la UIB. G9: portal dedicado a las asignaturas de la UIB impartidas en el G9 1. MG9: portal dedicado al primer máster totalmente online impartido entre las universidades que forman el G9. Cada uno de estos portales está replicado por cada año lectivo. Así, se puede diferenciar entre estudis1011 y estudis1112 por ejemplo. El contenido de la asignatura A1 en el curso lectivo y en el no tiene porque ser igual: el profesor puede haber añadido más documentación, haber variado el temario, entre otros. Además, el aporte de los alumnos es diferente dependiendo del curso. 1 Universidades G9: es un grupo formado por aquellas universidades que son únicas en su comunidad autónoma.

85 3. El servicio de educación virtual de la UIB 85 Por este motivo, los administradores replican cada portal según el curso lectivo. Esta replicación se realiza antes de empezar un nuevo curso y se realiza en función de los datos del curso anterior. A esta réplica se le eliminan los comentarios de los alumnos en los foros, los alumnos miembros, calendario o noticias entre otras cosas. Posteriormente se añaden los alumnos matriculados en ese nuevo curso. De esta forma al comenzar un nuevo curso académico, el profesor puede partir con el mismo material que disponía el curso pasado. El proceso de copias y restauraciones de cursos de Moodle así como la asignación de usuarios, es realizado por los administradores a través de la interfaz web Análisis de la problemática Cada año, con el comienzo del curso universitario, se incrementa el número de asignaturas presentes en el campus de educación virtual. Este crecimiento es difícil de predecir, ya que no sólo depende de las asignaturas que se incorporen, sino también del número de alumnos matriculados en cada una de las asignaturas presentes en el servicio. Además cabe añadir que con el proceso de reforma educativa realizado por la implantación del Plan de Bolonia[37] durante el curso , el uso de la herramienta de educación virtual Moodle se ha visto incrementado sensiblemente. Este aumento ha sido mucho mayor al de años anteriores, demostrando que la implantación de esta reforma educativa requiere una nueva arquitectura que permita el crecimiento de la anterior plataforma. El hecho de que se tratase de una reforma educativa tan importante, hacía prácticamente imposible estimar el crecimiento que necesitaría la plataforma de educación virtual. Estimar el aumento en número de asignaturas, usuarios, visitas o tráco que se producirán en cualquier sistema es una tarea complicada. Teniendo en cuenta la importancia de la reforma educativa del Plan de Bolonia, estimar el crecimiento que necesita la plataforma de educación virtual de la UIB era prácticamente imposible. Por ello, es muy importante diseñar una nueva arquitectura fácilmente escalable y que permita adaptarse rápidamente a las exigencias reales del servicio. Tal y como se ha comentado, año tras año, el servicio ha ido creciendo y ganando mayor importancia dentro de la universidad. El hecho de que este servicio sea cada vez más utilizado hace que su disponibilidad sea más necesaria ya que un corte en el servicio ocasiona problemas, tanto a profesores como a alumnos. Es por ello que se deben realizar cambios en la arquitectura para poder ofrecer un sistema con una elevada disponibilidad.

86 Análisis de la problemática Como se ha podido comprobar a lo largo de este capítulo, la arquitectura dedicada al servicio de educación virtual ha ido mejorándose de forma continua y llega a ofrecer una cierta redundancia al estar distribuida entre dos servidores físicos. Sin embargo, esta arquitectura requiere un nuevo diseño. Su escalabilidad es costosa, ya que añadir nuevos servidores físicos es caro además de ser un trámite lento al tratarse de una universidad pública. Aunque se añadieran nuevos servidores, la arquitectura no está pensada para ir escalando de forma horizontal. Escalar verticalmente sí sería más sencillo pero presenta una serie de desventajas: Por una parte, la mejoría de prestaciones por escalar verticalmente no sería muy grande y su coste también es elevado. Por otra parte, escalar verticalmente no soluciona los problemas de disponibilidad existentes con esta arquitectura. En caso de fallo en uno de los servidores el servicio se puede restablecer de forma rápida en un único servidor. Sin embargo este proceso siempre requiere una intervención manual, con su respectivo tiempo de mantenimiento sin servicio, por parte de los administradores de sistema Casos típicos A continuación se presentan las situaciones que históricamente han causado deciencias en el servicio de educación virtual de la UIB. Final de cuatrimestre Febrero y junio son los dos meses nales de los dos cuatrimestres del calendario lectivo. Durante los meses de enero, feberero, mayo y junio se realizan entregas de prácticas y exámenes nales en la mayoría de las asignaturas lo cual provoca una sobrecarga puntual sobre el servicio. El mes de septiembre también se realizan una gran cantidad de entregas de prácticas y exámenes, aunque en menor medida. Este aumento se ve reejado en el número de visitas y tráco que se realiza a los servidores, repercutiendo negativamente en el rendimiento de los servidores. Durante el curso , en el mes de abril de 2011 se realizaron visitas al servicio de educación virtual de la UIB donde se consultaron archivos. Un mes después, en mayo de 2011, se realizaron visitas y se consultaron archivos. Se puede observar que en un plazo de tiempo de un mes, el número de visitas se puede incrementar en un 52,1 % y el número de cheros consultados en un 38,1 %. La comparación de cifras se puede visualizar en la Figura 3.2.

87 3. El servicio de educación virtual de la UIB 87 Figura 3.2: Comparativa del número de visitas y archivos consultados en los meses de abril y mayo de Fuente: propia. Estas características hacen necesario una arquitectura escalable que pueda soportar picos puntuales de usuarios. También es necesario que la arquitectura ofrezca redundancia ante posibles fallos así como una elevada disponibilidad debido a la importancia del servicio. Preparación del siguiente curso A partir del mes de junio, los administradores del servicio se ponen a preparar el siguiente curso lectivo. Esta preparación consiste en una nueva instalación del software Moodle para el siguiente curso. Una vez instalado y congurado correctamente, se realizan las inserciones de usuarios, tanto profesores como alumnos. El proceso de inserción de alumnos se realiza de forma periódica, ya que las matriculaciones son prácticamente constantes durante los meses de verano. Posteriormente, para cada asignatura del curso actual, se realiza una copia de seguridad interna de Moodle que no es más que un chero comprimido con todo el material del curso. Este chero, posteriormente, se restaura en la instalación del siguiente curso. De esta forma, los profesores pueden iniciar el nuevo curso lectivo con la misma información y material del curso anterior. El objetivo de esta tarea es facilitar la labor del profesor y que éste no tenga que estar publicando la misma información con cada inicio de curso. Esta tarea se realiza de forma semiautomática a través de la ejecución de un script. Durante las semanas que estas tareas se llevan a cabo, los servidores sufren una carga extra considerable ya que se realizan multitud de operaciones de I/O a la vez que se está ofreciendo el servicio habitual.

88 Análisis de la problemática Analizando las asignaturas del curso se puede observar como una única asignatura puede llegar a ocupar unos 4,3 GB. En total, se cuenta con unos cursos con una ocupación media de 74 MB de material. El volumen de datos ocupados para el curso asciende a unos 250 GB. Comprimir, replicar y trabajar con semejante volumen de datos hace necesario contar con un rendimiento elevado a nivel de disco duro. El funcionamiento normal de los servidores no requiere un rendimiento especial en cuanto a lecturas, ya que el ratio entre lecturas y escrituras es elevado. En general, se produce una única lectura cuando un profesor o alumno sube un chero a la plataforma pero se producen múltiples lecturas del mismo. Este comportamiento hace pensar que la importancia del sistema de cheros esté basada únicamente en su rendimiento de lectura. Sin embargo, será necesario contar con un sistema de cheros que pueda proporcionar un buen rendimiento tanto en lecturas como en escrituras, ya que no sólo se producen múltiples lecturas sino que además, durante los meses de verano, se realizan múltiples trabajos de escrituras masivas de datos vía web. Históricamente este punto, la preparación del siguiente curso, siempre ha traído quejas de rendimiento al CTI desde la ocina de Campus Extens. Es por ello, que se plantea una arquitectura donde se presente un equilibrio entre presetaciones y rendimiento tanto de lecturas como de escrituras. Coincidencia en entregas de prácticas o exámenes En ocasiones se producen coincidencias entre asignaturas a la hora de establecer fechas límite de entregas de prácticas o realización de exámenes a través de la plataforma. Estos días producen un pico puntual de sobrecarga de peticiones que, en casos extremos, provoca que los tiempos de respuesta de los servidores sean elevados hasta el punto de darles error a los usuarios. Cuando se producen estos problemas, el usuario tiende a recargar continuamente la página web, incrementando así el número de solicitudes y sobrecargando aún más el servidor. Se entra así en un bucle de incapacidad de servicio por número de peticiones que, a su vez, se ven incrementadas por la reiteración de usuarios cuya petición no fue atendida. Fechas típicas para que se produzcan estas coincidencias son las vueltas de vacaciones o puentes. Después de las vacaciones de navidad, de pascua o tras el puente de la constitución suelen ser fechas señaladas por los profesores para la realización de entregas de prácticas o exámenes a través de Moodle. Por ejemplo, el día 9 de diciembre de 2010 coincidió con la vuelta al horario lectivo después de un puente de 5 días de vacaciones. En este día se produjeron visitas y se consultaron archivos. El día anterior el número de visitas fue tan solo y el número de archivos consultados

89 3. El servicio de educación virtual de la UIB En cuestión de 24 horas el número de visitas y de archivos consultados se incrementó en un 114,95 % y 49,14 % respectivamente. Tan sólo 48 horas después, el día 11 de diciembre, el volumen de peticiones volvía a seguir el comportamiento típico. Estos comportamientos inesperados hacen que el sistema deba ser fácilmente escalable. De esta forma, si se produce un aumento de tráco por motivos puntuales, se puede actuar e incrementar la capacidad del sistema Infraestructura tecnológica de virtualización En la Figura 3.3 se representa el esquema de la infraestructura tecnológica de virtualización actual del CTI. A nivel general, se trata de dos CPD situados en dos edicios diferentes dentro del campus. El primero está situado en el edicio del CTI, perteneciente al Anselm Turmeda y el segundo está situado en el edicio Gaspar Melchor de Jovellanos. El objetivo principal de contar con dos CPD es aumentar la tolerancia a fallos de los servicios de informática y telecomunicaciones que se ofrecen. A nivel de almacenamiento, el CTI cuenta con dos SAN de la empresa EMC 2 [38] conectadas entre sí directamente a través de una serie de enlaces de bra óptica. La principal ventaja de una SAN es que proporciona a los servidores acceso al espacio disponible mediante Logical Unit Number (LUN). Estos discos virtuales pueden estar formados por niveles de RAID que incrementan el rendimiento, integridad y redundancia de los datos. Además, estas SAN permiten replicar los datos entre ellas a nivel de operaciónes de I/O. De esta forma, se tiene exáctamente la misma información replicada en ambos CPD. Esta característica se denomina Mirror View. Los servidores físicos dedicados a virtualización es encuentran conectados a la SAN mediante ber channel, para los discos de mayor rendimiento, e iscsi para los discos de menor rendimiento. La SAN se encarga de la gestión del espacio, cómo se reparten las diferentes LUN entre los distintos discos duros físicos, creación de RAID, etc. En total, el CTI cuenta con catorce servidores físicos dedicados a virtualización. Los servidores se encuentran repartidos entre los dos CPD. Además, los servidores se encuentran agrupados de forma que, gracias a VMware HA, proporcionan alta disponibilidad a las máquinas virtuales en caso de fallo de hardware en los servidores físicos. Las características hardware varían según el servidor. En total, se cuenta con el hardware denido en el Cuadro 3.2. Si se observan los datos, se obtiene

90 Infraestructura tecnológica de virtualización Figura 3.3: Infraestructura tecnológica de virtualización en el CTI. Fuente: propia.

91 3. El servicio de educación virtual de la UIB 91 una media de 7,4 procesadores y 26,85 GB de memoria RAM por servidor. Procesador (modelo) Intel Xeon Procesador (GHz) 3.2 N o procesadores 104 Mem. RAM (GB) 376 Tarjetas de red Cuadro 3.2: Características hardware de todos los servidores de virtualización. En estos servidores se ejecutan actualmente 112 máquinas virtuales. Aproximadamente el 30 % de estas máquinas virtuales posee más de una CPU virtual y más de 2 GB de memoria RAM. Estos números pueden dar una idea aproximada de la optimización de recursos que la virtualización supone. Si en vez de virtualizar se hubiese optado por servidores físicos, la inversión a realizar sería mucho mayor ya que actualmente con 104 procesadores físicos se está dando servicio a 112 máquinas virtuales con, aproximadamente, 150 procesadores virtuales. En cada uno de los CPD se cuenta con una red interna de servidores. En esta red se encuentran conectados los balanceadores de tráco. Además de las funciones típicas de los balanceadores de tráco, también se encargan de tareas de enrutado entre la red interna de servidores y la externa. Los balanceadores pueden realizar pequeñas tareas de ltrado de tráco similares a las que realiza un rewall. Permiten congurar la red de origen, la de destino y los puertos que se quieren enrutar y balancear. De esta forma se consigue tener dos redes completamente separadas, aumentando así la seguridad. Cada uno de los CPD está conectado entre sí a través de switches de altas prestaciones. Estos conectan los servidores antiguos, que no se encuentran balanceados, los balanceadores de tráco y otros elementos de red que se encuentran en los CPD. Su función básica es la de interconectar ambos CPD de forma que se tengan dos CPD físicos pero un único CPD lógico. Los rewall son los elementos de red encargados de monitorizar y controlar el tráco de red que se produce. En ellos se encuentran denidas una serie de políticas de seguridad que especican concretamente qué tráco está permitido. Estas reglas suelen contener siempre la misma información: protocolo de red, IP o hostname de origen, puerto de origen, IP o host de destino, puerto de destino, entre otros. En total, se cuenta con dos rewall situados cada uno en un CPD. Estos elementos ofrecen una disponibilidad elevada ya que se encuentran congurados en modo maestro/esclavo. Es decir, si el principal falla, el esclavo asume el rol temporalmente. Para monitorizar su

92 Infraestructura tecnológica de virtualización estado, se comunican entre sí a través de heartbeat. Los rewall interconectan entre sí la red de servidores en ambos CPD, la red interna de la UIB (engloba administración y servicios, personal docente e investigador así como aulas de informática de alumnos y Wi-Fi) e Internet. El encargado de realizar la conexión de la UIB a Internet es un router proporcionado por RedIris.

93 Capítulo 4 Servicios web En este capítulo se describe la arquitectura implementada para ofrecer un entorno de alta disponibilidad de servidores web. En primer lugar, se explican los motivos por los que se opta por la virtualización de servidores. A continuación se explica el proceso de migración de los diferentes sitios web que se ofrecen en el servicio de educación virtual. Para nalizar se explica el uso de un balanceador de tráco que reparte la carga entre los distintos servidores web virtualizados Servidores web virtualizados En esta sección se describen los motivos por los cuales se decidió virtualizar los servidores web. Además se explica la conguración de la arquitectura para dotarla de alta escalabilidad y disponibilidad Introducción El motivo principal por el cual se elige una arquitectura de servidores web virtualizados es por la exibilidad que aporta. Tal y como se ha podido apreciar en la Sección 3.2, la arquitectura de educación virtual está sometida a cambios continuamente. Virtualizar los servidores web nos permite denir unas características hardware mínimas para un determinado curso. En caso de que fuera necesario, aumentar los recursos de un servidor virtual es una tarea que no resulta complicada y cuya realización apenas conlleva tiempo. En el caso de un servidor físico, implicaría un gasto económico extra, un pedido al distribuidor o fabricante, y, nalmente, un tiempo de instalación y conguración. 93

94 Servidores web virtualizados Así mismo, en casos extremos, donde la infraestructura destinada al servicio fuera insuciente, se puede clonar una máquina virtual, congurarla y que empiece a proporcionar servicio en un período de tiempo mucho menor que si se realizase con servidores físicos. Una vez denidas las características hardware de los servidores virtuales, trabajar con ellos es exáctamente igual que con servidores físicos. El software instalado sobre el hardware virtual es exáctamente el mismo y su conguración, mantenimiento y copia de seguridad se realizan siguiendo los mismos procedimientos que en los antiguos servidores físicos destinados a educación virtual. Aprovechando la infraestructura tecnológica de virtualización en el CTI, vista en la Sección 3.4, se crearon dos servidores virtuales destinados a proporcionar servicios web. Estos dos servidores están ubicados en los dos CPD para asegurar una mayor tolerancia a fallos. En un principio, swmdl1 está situado en el CPD del edicio Anselm Turmeda y swmdl2 en el CPD del edi- cio Jovellanos. Sin embargo, al tratarse de máquinas virtuales, la ubicación de cada uno de los servidores puede verse alterada de forma sencilla Escalabilidad y alta disponibilidad Tal y como se ha visto en la Sección 2.3, la forma más sencilla de escalar un servicio web y dotarlo de alta disponibilidad es hacerlo de forma horizontal, añadiendo más servidores, de forma que se pueda responder a una carga mayor y la disponibilidad del sistema sea elevada, debido a la alta redundancia entre los servidores. Es necesario conectar un balanceador de tráco entre los servidores y los clientes para que se encargue de distribuir la carga entre los diversos servidores web, así como para monitorizar su estado. Cabe destacar que si únicamente se conecta un único balanceador de tráco, éste se convierte en el punto único de fallo, limitando la alta disponibilidad del sistema. Es por ello que se necesita conectar dos balanceadores en conguración de maestro/esclavo, de forma que en todo momento sólo uno de los balanceadores se encarga de repartir el tráco. Si este balanceador falla, el esclavo realizará el balanceo de forma automática. En la Figura 4.1 se puede apreciar cómo se distribuyeron los dos servidores y los dos balanceadores entre los dos CPD. De esta forma, situando cada uno de los componentes en localizaciones físicas distintas, aumentamos la tolerancia a fallos del sistema ante problemas que afecten a todo el edicio como cortes de electricidad, inundaciones, entre otros. Como se puede ver, siempre que se encuentre al menos un balanceador de tráco y un servidor web activos, independientemente de su localización física, el servicio no se ve interrumpido. Además, al tratarse de servidores virtuales, se puede migrar

95 4. Servicios web 95 Figura 4.1: Distribución de los dos balanceadores y los dos servidores web. Fuente: propia. fácilmente la ejecución de un CPD a otro, sin tener que interrumpir el servicio. Esta característica facilita la planicación de reparaciones, cortes de electricidad o de red planicados en alguno de los dos CPD Proceso de migración El proceso de migración de los servidores web dedicados al servicio de educación virtual se ha llevado a cabo de forma paulatina siguiendo una

96 Proceso de migración serie de etapas. A continuación se realiza un breve resumen de las tareas realizadas en cada etapa del proceso de migración: Denición de los servidores virtuales La primera etapa del proceso consiste en denir los dos servidores virtuales, swmdl1 y swmdl2, con unas características hardware determinadas. Estas se han ido modicando a lo largo del proceso de migración para adecuarse a las necesidades del servicio, tal y como se explica en la Sección 4.4. En concreto, los dos servidores pasaron de tener 1 CPU y 1 GB de RAM a 2 CPU y 2 GB de memoria RAM. Éstos se denieron en servidores físicos diferentes, situados cada uno en los dos CPD. De esta forma, se mejora la redundancia y la tolerancia ante posibles fallos de hardware de los servidores físicos asi como ante posibles fallos eléctricos, caídas de red o desastres de mayor envergadura como incendios. En esta primera fase también se denió el almacenamiento de los servidores. Cada servidor cuenta con tres discos duros virtuales. El primer disco duro contiene el sistema operativo, cheros de conguración y las aplicaciones. El segundo disco duro está destinado a albergar los registros de acceso, errores y demás información relevante del servicio web. Por último, el tercer disco duro está compartido por ambos servidores ya que es el disco duro destinado a la información web de Moodle. Cada uno de estos tres discos duros virtuales están asociados a una LUN proporcionada por la SAN de su CPD en conguración de RAID 5. El caso del disco duro compartido es especial, ya que debe ser accesible por ambos servidores aunque ocurra algún imprevisto. En caso de que alguno de los servidores virtuales o físicos tenga un error, el otro debe ser capaz de tener acceso a los datos. Además, si ocurre un fallo en una de las cabinas de discos de un CPD, se debería poder acceder a los datos a través de la otra cabina en ambos servidores. Para solucionar este problema, se creó el disco duro compartido en la SAN del CTI y se dió visibilidad a ambos servidores virtuales. En la SAN del Jovellanos se creó una réplica con las mismas características del disco duro compartido situado en el CTI. Se conguró en ambas cabinas y para ambos discos la característica de Mirror View. De esta forma, ambos servidores tienen, en todo momento, la información replicada en cada una de las cabinas de disco de los CPD.

97 4. Servicios web Instalación y conguración del sistema operativo Como sistema operativo se utilizó Linux. En concreto, se instala la distribución SuSE Linux Enterprise Server 11 en ambos servidores web. Se ha instalado también el SuSE Linux Enterprise 11 Software Developement Kit debido a la necesidad de instalar algunos paquetes de desarrollo, así como Su- SE Linux High Availability Extension para disponer de los paquetes y soporte para las aplicaciones de alta disponibilidad. La elección de SuSE como distribución de Linux es debido a que la UIB ya disponía de un contrato de soporte con Novell[39], la empresa propietaria de SuSE. Además, todo el software necesario estaba disponible en los repositorios ociales Instalación y conguración de OCFS2 La instalación y conguración de OCFS2 está detallada en el Apéndice C. Las características y motivos por los que se eligió OCFS2 como sistema de cheros están detallados en el Capítulo Instalación y conguración del servidor Apache, PHP5 y eaccelerator Moodle necesita de un servidor web con soporte para PHP5. Para este proyecto se decidió utilizar Apache2 debido a su modularidad, amplia documentación y soporte. Se utiliza un módulo de multiprocesamiento de Apache2, denominado prefork. El funcionamiento de este módulo es sencillo ya que un único proceso de control se encarga de lanzar procesos hijo que están a la espera de conexiones y las responden cuando llegan. Apache2 siempre intenta tener varios procesos ociosos que estén listos, a la espera de nuevas peticiones. El motivo de tener siempre algunos servidores en espera de nuevos clientes es no aumentar el tiempo de espera de los clientes. Crear un nuevo proceso hijo con cada nueva petición causa una sobrecarga en el sistema y, además, hace que el tiempo de respuesta al cliente sea mayor. El comportamiento de Apache2 prefork viene determinado por el valor de cuatro variables de conguración: StartServers: número de procesos hijo que se crean al inicio. El valor establecido es 7. MinSpareServers: número mínimo de procesos hijo ociosos. Si existen menos procesos ociosos de lo que indica esta variable, el proceso de control creará un nuevo proceso hijo. El valor establecido es 12.

98 Proceso de migración MaxSpareServers: número máximo de procesos hijo ociosos. Si existen más procesos, entonces el proceso de control los eliminará. El valor establecido es 25. MaxClients: límite de conexiones simultáneas que pueden ser atendidas. Cualquier conexión que se realice por encima de este límite será encolada. En el caso de prefork, este número coincide con el número máximo de procesos hijo que existirán. El valor establecido es 180. MaxRequestsPerChild: número máximo de peticiones que un proceos hijo atenderá durante su existencia. Después de atender este número de peticiones, el proceso hijo será eliminado. El valor establecido es 0 (sin límite). KeepAlive: habilita las conexiones persistentes de forma que se envien más de una petición por conexión. El valor establecido es On. MaxKeepAliveRequests: número máximo de peticiones que se permiten durante una conexión persistente. El valor establecido es 500. KeepAliveTimeout: segundos a esperar para la siguiente petición del cliente sobre la misma conexión. El valor establecido es Instalación y conguración del software Moodle de pruebas Se realizó la instalación de un Moodle de forma temporal para realizar las pruebas de rendimiento y del balanceador. En cuanto a la conguración referente a la BBDD se utilizó temporalmente la vieja infraestructura Conguración del balanceador En este punto se probaron las diferentes políticas de balanceo así como la gestión de las sesiones y aceleración SSL (Secure Socket Layer). Las características del balanceador de tráco por hardware se encuentran descritas en la Sección Se decidió optar por un algoritmo de balanceo round robin. La información correspondiente a las sesiones de los clientes se almacena en base de datos y la identicación de dicha sesión se realiza mediante el uso de una cookie. Además, se optó por congurar los balanceadores para gestionar todo el tráco y certicados de cifrado SSL. De esta forma, el tráco desde el cliente hasta el balanceador (normalmente a través de Internet) está cifrado y el tráco entre el balanceador y los servidores, en una red separada y controlada, se realiza en claro, sin ningún tipo de cifrado.

99 4. Servicios web Realización de pruebas de rendimiento Se realizaron pruebas de rendimiento y estrés sobre los servidores web y el balanceador utilizando jmeter. Se utilizó JMeter debido a que es capaz de simular el comportamiento que tendría un usuario al visitar la web. Las características principales se pueden encontrar en la Sección Se crearon cuatro sencillas pruebas que, probablemente, representen la gran parte del comportamiento de los usuarios. Estas se realizaron en un orden de complejidad ascendente: 1. Un usuario accede y sale correctamente. 2. Un usuario accede, visita la web de una asignatura y sale. 3. Un usuario accede, visita la web de una asignatura, visita su foro y sale. 4. Un usuario accede, visita la web de una asignatura, visita su foro, lee y escribe un mensaje y posteriormente sale. El acceso de un usuario se considera al hecho de autenticarse correctamente, mediante usuario y contraseña, contra el sistema y posteriormente sale, concluyendo su sesión correctamente. Cada una de estas pruebas se realizó ejecutándose 200 peticiones simultáneas cada 10 segundos durante 30 minutos. De esta forma, se pudo comprobar que el sistema de balanceo, así como la gestión de las sesiones, funcionaba correctamente Migración de datos reales Mediante el uso de rsync se migraron los datos de los servidores antiguos a los nuevos. Para que no se perdiera ningún tipo de información durante la sincronización y el posterior proceso de migración, se planicó una parada temporal del servicio de educación virtual Migración de los portales Una vez migrados los datos reales a los nuevos servidores, únicamente hacía falta realizar las modicaciones oportunas en el servidor de DNS. De esta forma, los dominios que anteriormente apuntaban a los viejos servidores, ahora apuntan al balanceador de tráco. Éste, a su vez, balancea el tráco web entre los dos servidores nuevos.

100 Balanceo de tráco 4.3. Balanceo de tráco En esta sección se describen los dos tipos de balanceadores de tráco que se han utilizado a lo largo de este proyecto. En un principio, se utilizó una solución basada en software libre y redundante, en conguración de maestro/esclavo. Durante la evaluación del software, el CTI adquirió dos balanceadores de tráco por hardware. Debido a la inversión realizada, los responsables de área de este proyecto decidieron que se debían utilizar. Finalmente, las pruebas con el balanceador de tráco por software se descartaron y se utilizó el balanceador hardware Balanceador de tráco por software Un balanceador de tráco por software es un servicio más ejecutado en un servidor. El objetivo principal de esta aplicación es el de cualquier balanceador de tráco, distribuir la carga entre dos o más servidores que proporcionarán el mismo servicio. La aplicación de balanceo de tráco escucha el puerto a través del cual los clientes se conectan para acceder al servicio. Posteriormente, reenvía la petición a uno de los servidores balanceados siguiendo una determinada política. El servidor contesta al balanceador y este, a su vez, al cliente. Este comportamiento es común, tanto para balanceadores de tráco software como hardware, y se encuentra detallado en la Sección Existen multitud de balanceadores de tráco por software. Algunos de ellos, disponibles para GNU/Linux, son ldirectord[40], HAProxy[41], BalanceNG[42], entre otros. ldirectord Para las pruebas realizadas en este proyecto, se eligió ldirectord como balanceador. ldirectord tiene licencia GNU GPL. Se seleccionó debido a la buena reputación que tiene además de que parte del equipo técnico del CTI tenía experiencias positivas con dicho software. Así mismo, no se evaluaron las alternativas porque se tenía claro que la arquitectura nal estaría compuesta por balanceadores de tráco por hardware. Sin embargo, se realizaron pruebas con un balanceador de tráco por software por motivos de tiempo, ya que los balanceadores por hardware aún no estaban instalados. Ldirectord realiza comprobaciones periódicas para saber si los servicios en los servidores balanceados están funcionando correctamente. Para ello se le debe proporcionar un listado con los servidores que van a ser balanceados y qué servicios debe balancear hacia dichos servidores. Por ejemplo, en el caso

101 4. Servicios web 101 de balancear el tráco a varios servidores web, consulta una página web en concreto y comprueba que su contenido es el correcto. En este caso, balanceará el tráco web hacia ese servidor. En caso contrario, no reenviará ninguna petición hacia ese servidor hasta que se realice de nuevo una comprobación y su resultado sea positivo. Además, se puede congurar un servidor de respaldo al que se redirigirá todo el tráco en caso de que ninguno de los servidores a balancear esté disponible. En el servidor de respaldo se puede mostrar una página de mantenimiento, error o contacto. Para las pruebas se creó un archivo de texto en los servidores web que sería consultado por ldirectord. El software se encarga de solicitar periódicamente dicho chero y de comprobar que su contenido sea exáctamente el siguiente: <html> <head> <meta http e q u i v=" Content Type" content=" t e x t /html ; c h a r s e t=utf 8"> </head> <body> <p>web OK</p> </body> </html> El balanceador de tráco reenvía las peticiones a los servidores balanceados siguiendo una distribución concreta. El software elegido, ldirectord, soporta los métodos clásicos de balanceo de tráco vistos en la Sección En el caso de las pruebas realizadas, se usó únicamente round robin. Antes de realizar las pruebas, se realizó un montaje de alta disponibilidad utilizando dos servidores dedicados a balancear el traco por software. Se siguió el esquema de conexiones y conguraciones indicado en la Figura 4.1. Para realizar este montaje, se debió contar con dos tipos de direccionamiento de red para los balanceadores. El primero estaba destinado a la conexión con Internet y era una única IP pública. En todo momento, el balanceador que ocupe el rol de maestro tiene asociada dicha IP. De esta forma, los clientes se conectan siempre a esa IP pública y, por tanto, al balanceador maestro. El segundo tipo de direccionamiento es puramente interno, cuya nalidad es la de comunicación entre los dos balanceadores para determinar su estado. En el caso de que el balanceador maestro tenga un problema de conexión, el balanceador esclavo debe asumir el rol de maestro y, por tanto, auto-asignarse la IP pública. Esta comprobación periódica del estado de cada balanceador, así como la gestión del direccionamiento público, se hizo a través de la herramienta heartbeat. La conguración de la herramienta heartbeat, así como la de los

102 Balanceo de tráco balanceadores de tráco ldirectord se encuentran detalladas en el Apéndice B. Se realizaron dos tipos de pruebas con ldirectord: 1. La primera prueba se realizó con una galería de fotos web que se cargaba simultáneamente desde varios clientes. Al tratarse de una galería de fotos, se debían realizar peticiones de varios cheros. Gracias a esta sencilla prueba, se pudo comprobar que el tráco se balanceaba correctamente entre los dos servidores web al haber varios clientes realizando peticiones concurrentemente. Además, se pudieron realizar pruebas básicas de persistencia de sesiones entre los servidores y los clientes. Es decir, si un cliente era dirigido por el balanceador hacia un determinado servidor, éste sería el encargado de responder a sus próximas peticiones durante un tiempo de sesión determinado. 2. La segunda prueba se realizó con la instalación de pruebas de Moodle. Cabe destacar que estas pruebas se realizaron con conexiones web cifradas mediante SSL. El encargado del cifrado era el propio servidor web, Apache2 en este caso, debido a que el balanceador por software no soporta esta característica. El objetivo principal de esta prueba era comprobar la gestión de sesiones entre el cliente y los servidores, pasando por los balanceadores. Sin embargo, a lo largo de estas pruebas se instalaron los balanceadores de tráco por hardware y se detuvieron las pruebas con ldirectord para pasar a congurar directamente los balanceadores que nalmente se utilizarían. En denitiva, las pruebas con ldirectord sirvieron para adelantar y poner a prueba la nueva infraestructura de servidores web, independientemente de la llegada de los balanceadores hardware. No se llegó a profundizar en el funcionamiento y rendimiento de ldirectord debido a que se tomó la decisión, por imposición estratégica externa, de utilizar un balanceador por hardware Balanceador de tráco por hardware Un balanceador de tráco por hardware es básicamente un dispositivo físico con el software necesario para balancear tráco y con características hardware especícas que ayudan a realizar mejor su función, como puede ser la inclusión de varias tarjetas de red. La infraestructura de balanceadores de tráco por hardware del CTI está formada por tres tipos de equipos: Dispositivos balanceadores.

103 4. Servicios web 103 Dispositivos aceleradores y de cifrado. Dispositivos de gestión. Los dispositivos balanceadores son los encargados del balanceo de tráco en sí, recibiendo peticiones de los clientes y reenviándolas a uno de los servidores destinados a ese servicio. En concreto, se cuenta con dos dispositivos Radware AppDirector OnDemand Switch 2 [43]. Cada uno de los dos dispositivos se encuentra en un CPD diferente, aumentando así la alta disponibilidad y la tolerancia a fallos del sistema de balanceo. Ambos dispositivos están congurados como activo/pasivo de forma que sólo uno proporciona servicio a la vez. Los dispositivos aceleradores y de cifrado son los encargados de realizar el cifrado SSL entre el cliente y el servidor. Además, se encargan de realizar caché y compresión del contenido web. De esta forma, estos dispositivos realizan tareas, que de otra manera, se ejecutarían en los servidores web, reduciendo así la carga soportada por ellos. Balanceadores de tráco en la UIB Durante el año 2009 surge la necesidad por parte del CTI de implantar tecnologías de alta disponibilidad en los principales servicios. Esta alta disponibilidad implica redundancia en los servidores utilizados. La redundancia de servidores implica que algunos recursos podrían no ser explotados debido a su escasa utilización. Para solucionar este problema, se planteó la adquisición de un balanceador de tráco por hardware. El CTI cuenta con dos dispositivos Radware AppXcel 4000 [44]. Estos dos dispositivos también se encuentran situados en localizaciones diferentes. Sin embargo, a diferencia de los balanceadores de tráco, no se encuentran congurados en modo activo/pasivo, sino que se encuentran en modo activo/activo. De esta forma, ambos dispositivos trabajan para descargar a los servidores web. Los dispositivos de gestión ofrecen una interfaz para gestionar, monitorizar y congurar los dispositivos comentados anteriormente. Para realizar la gestión de la infraestructura de forma centralizada se utiliza la aplicación ApSolute Inside del dispositivo Radware Insite Manage Pro[45]. Los dispositivos también se pueden congurar individualmente accediendo a ellos a través de un navegador web o a través del protocolo SSH. Para el desarrollo de este proyecto se denió una nueva conguración que incluye el balanceo de tráco entre los dos servidores web. El balanceo a realizar entre ambos servidores sigue la distribución round robin. Además, se denieron los controles que debe realizar el balanceador para determinar si

104 Balanceo de tráco los servidores tienen algún problema. Por último, se generaron certicados SSL para almacenarlos y gestionarlos desde el propio balanceador. De esta forma, se ganaría rendimiento en los servidores web. Comprobación de estado de los servidores Una de las tareas críticas que realiza el balanceador de tráco es la comprobación del estado de los servidores. Si un servidor no se encuentra disponible, debe dejar de reenviarle tráco de forma inmediata. Para comprobar el estado, el balanceador debe realizar una serie de comprobaciones de forma periódica con los servidores. El balanceador ofrece, como opción, la posibilidad de mostrar un mensaje de error al usuario en caso de que ningún servidor se encuentre disponible para proporcionar servicio. En los servidores web de educación virtual se han denido cuatro pruebas básicas para determinar que el servicio funciona de forma correcta. Estas pruebas son las siguientes: Ping: el balanceador realiza un ping al servidor y espera la respuesta. Prueba de servidor web Apache: el balanceador accede, vía web, a una página situada en el servidor que desea comprobar. El resultado de dicha página debe ser exáctamente el siguiente código HTML que se encuentra en el servidor. Este código es: <html> <head> <meta http e q u i v=" Content Type" content=" t e x t /html ; c h a r s e t=utf 8"> </head> <body> <h1>html OK</h1> </body> </html> Prueba de PHP: el balanceador accede, también vía web, a una página con el siguiente código PHP: <?php echo '<html> <head> <meta http e q u i v="content Type" content="t e x t /html ; c h a r s e t=utf 8">

105 4. Servicios web 105 </head> <body> <h1>php OK</h1> </body> </html> ' ;?> El balanceador debe obtener la siguiente respuesta en código HTML para considerar que esta prueba es correcta: <html> <head> <meta http e q u i v=" Content Type" content=" t e x t /html ; c h a r s e t=utf 8"> </head> <body> <h1>php OK</h1> </body> </html> Prueba de conexión a BBDD: el balanceador accede a una página escrita en PHP que realiza un intento de conexión a la BBDD alojada en el servidor 'bbdd.mdl': <?php $ l i n k = mysql_connect ( ' bbdd. mdl ', ' user ', ' passwd ' ) ; i f (! $ l i n k ) { // Tratamiento de e r r o r } echo 'BBDD OK' ; mysql_close ( $ l i n k ) ;?> Si el balanceador obtiene como respuesta la cadena de texto BBDD OK considera que la prueba está superada. En caso contrario, existe algún problema de comunicación entre el servidor web y el servidor de BBDD. En el Cuadro 4.1 se puede observar un resumen de las pruebas que realiza el balanceador con cada servidor. En la primera columna (Comprobación) se indica el nombre de la prueba. La segunda columna (Inter) indica el tiempo en segundos de intervalo entre cada repetición de la prueba. La tercera (Reint)

106 Balanceo de tráco indica el tiempo de reintento en caso de que la prueba haya sido fallida. La cuarta columna (Timeout) indica el tiempo en segundos que el balanceador debe estar esperando respuesta. Si no se obtiene respuesta, pasado ese tiempo de timeout, se considera que la prueba es fallida. La última columna (Det) indica el tiempo máximo de detección de error en cada una de las pruebas. Comprobación Inter (seg) Reint (seg) Timeout (seg) Det (seg) PING APACHE PHP BBDD Cuadro 4.1: Resumen de los tests realizados a los servidores. Es decir, el peor escenario posible, es que ocurra un error con el servidor de BBDD y que los balanceadores no se percaten hasta pasados 45 segundos. Durante esos 45 segundos, los usuarios estarían intentando acceder al servicio de educación virtual y el software Moodle les respondería con un error de conexión a BBDD. Para minimizar este problema, se ha ideado un sistema escalable y de alta disponibilidad sobre MySQL. Más información en el Capítulo 6. El resto de posibles fallos en los tests están directamente vinculados a los servidores web. Siempre y cuando no ocurran errores en ambos servidores, el servicio no se ve interrumpido y estos errores pasan desapercibidos para los usuarios. Certicados SSL Los balanceadores de tráco hardware con los que cuenta el CTI tienen la posibilidad de gestionar ellos mismos la comunicación segura hasta el cliente. Esta comunicación segura se realiza a través del protocolo de seguridad SSL que utilizan los navegadores web, servidores web y, en este caso, también los balanceadores. Un certicado SSL contiene un par de claves, una clave pública y una privada, así como información vericada sobre la identicación. Cuando un cliente visita una página web protegida mediante este protocolo el servidor comparte su clave pública con el cliente y se establece un método de cifrado y una clave de sesión única. El cliente conrma que reconoce y confía en el emisor del certicado SSL y a partir de ahí, se inicia una sesión segura que proyege la privacidad e integridad del mensaje. Esta operación de cifrado se realiza mediante la aplicación de unos cálculos matemáticos que permiten codicar y decodicar la información. Estos

107 4. Servicios web 107 cálculos producen una carga extra en los servidores. Tal y como ya se ha comentado anteriormente, los balanceadores de tráco permiten realizar esta tarea de cálculo matemático en su hardware, descargando así a los servidores. De esta forma, la comunicación entre el usuario/cliente y el balanceador se realiza de forma segura a través del protocolo de seguridad SSL. Sin embargo, la comunicación entre los balanceadores y los servidores se realiza sin ningún tipo de cifrado. El esquema de comunicación se representa en la Figura 4.2. Figura 4.2: Esquema de comunicaciones HTTP/HTTPS entre los usuarios y los servidores. Fuente: propia. La red privada donde se encuentran conectados los servidores y el balanceador está congurada de forma totalmente cerrada. Únicamente se puede acceder a los servidores desde Internet a través de lo especícamente permitido en el balanceador. En el caso de este proyecto, únicamente se tiene acceso a través de web, tanto HTTP como HTTPS (HTTP con cifrado SSL/TLS). Este entorno totalmente aislado hace posible que los datos se transmitan sin cifrar sin correr un riesgo de seguridad elevado. Únicamente se tiene acceso

108 Problemas encontrados directo a los servidores a través de una serie de direcciones IP privilegiadas situadas en el CTI. De este modo, los usuarios tienen la seguridad de que sus datos viajan cifrados por Internet hasta la red privada de la UIB y, gracias al tratamiento SSL en los balanceadores, los servidores ven su carga disminuida al no tener que cifrar/descifrar todo el tráco Problemas encontrados Durante el curso académico se realizaron una serie de modicaciones tanto a nivel de hardware como de software para adaptar la arquitectura a las necesidades reales del servicio. En esta sección se introducen los problemas encontrados y las modicaciones realizadas para minizar o eliminar dichos problemas. El primer problema grave con la infraestructura diseñada se produjo a la vuelta de un puente de vacaciones. En esta fecha coincidieron un gran número de entregas de prácticas de múltiples asignaturas con la realización de un curso de formación de Moodle al profesorado. Los dos servidores que se habían creado no dieron abasto a la hora de responder a tantas peticiones simultáneas, resultando en errores de Tiempo de espera agotado en los usuarios. La reacción natural del usuario ante estos errores es intentar refrescar la página web, aumentando aún más el número de peticiones que el sistema recibía. Como primer intento de solución se modicaron una serie de parámetros que afectaban a los servidores web Apache. En concreto se modicaron los siguientes parámetros: MaxRequestsPerChild: se estableció un máximo de 500 peticiones que un único proceso puede atender. La principal motivación para establecer este valor es por el alto consumo de memoria que los procesos Apache llegaron a alcanzar. Al ir atendiendo peticiones, todas ellas a través de páginas PHP que debían ser procesadas, el uso de memoria iba en aumento. Estableciendo este parámetro, se asegura que cada cierto tiempo los procesos de Apache son renovados y la memoria ocupada, liberada. Tampoco se debe caer en el establecimiento de un valor pequeño, ya que la eliminación y creación de procesos también tiene un coste asociado en términos de recursos. El valor establecido es , el anterior 0 (sin límite). KeepAliveTimeout: se decidió decrementar el número de segundos a esperar para la siguiente petición. La disminución de este valor hizo que

109 4. Servicios web 109 las peticiones esporádicas se agilizaran bastante. El valor establecido es 3, el anterior 10. Además, se modicaron una serie de parámetros del kernel de Linux referentes a las conexiones TCP/IP. En concreto, estos parámetros se pueden establecer de inmediato a través de la modicación de unos cheros ubicados en /proc/sys/net/ipv4/. Los parámetros y los valores que se modicaron se presentan a continuación: /proc/sys/net/ipv4/tcp_n_timeout : es el tiempo que debe pasar antes de que el kernel pueda liberar una conexión cerrada y utilizar de nuevo los recursos asignados. Durante este periodo, la conexión se encuentra en un estado denominado TIME_WAIT y reabrirla cuesta menos que establecer una nueva. Reduciendo este parámetro se consigue que las conexiones se cierren más rápido, liberando recursos para asignarlos a nuevas. El valor establecido es 30s, 60s por defecto. /proc/sys/net/ipv4/tcp_keepalive_intvl : es el tiempo de espera entre las pruebas de isalive, encargado de monitorizar si la conexión sigue establecida. El valor establecido es 30s, 75s por defecto. /proc/sys/net/ipv4/tcp_keepalive_probes : es el número de intentos antes de que una conexión se considere en estado TIMEOUT. El valor establecido es 5s, 9s por defecto. /proc/sys/net/ipv4/tcp_tw_reuse : habilita la reutilización de los sockets que se encuentren en estado TIME_WAIT para atender nuevas conexiones. El valor establecido es 1 (habilitado), por defecto: 0 (deshabilitado). La modicación de estos parámetros hizo que se decrementasen el número de conexiones en los servidores en torno a un 25 %. Este decrecimiento viene provocado por el cierre de las conexiones, que ahora se realizan más rápido. El hecho de que se disminuyan las conexiones hace que se decrementen también los procesos del servidor web Apache2 y, por tanto, se aprovechan mejor los recursos. Posteriormente, se produjeron otras situaciones de sobrecarga durante el nal del primer cuatrimestre del curso , concretamente durante el mes de febrero. Se decidió aumentar el número de conexiones simultáneas que se atendían en cada servidor. Para ello, se debió modicar el siguiente parámetro de la conguración de los Apache:

110 Problemas encontrados MaxClients: ya que se alcanzó el límite de conexiones simultáneas que pueden ser atendidas, este parámetro se incrementó. Este valor no se puede incrementar indiscriminadamente, ya que su aumento implica el aumento de procesos de Apache para atender dichas peticiones. Esto genera un aumento en el uso de recursos y es posible que se sature el servidor. El valor establecido es 250 y el valor anterior 180. Un valor de 250 en los dos servidores implica que el sistema es capaz de atender 500 conexiones a la vez. Sin embargo, este número no equivale al número de clientes. Los navegadores web del cliente pueden abrir varias conexiones en paralelo contra los servidores para transferir datos de forma simultánea e intentar cargar más rápido la página web. Para poder ejecutar 250 procesos de Apache en cada uno de los servidores se tuvo que aumentar la memoria RAM de 1GB a 2GB. Durante esta situación de sobrecarga se observó que se producían un gran número de intercambios de contexto en los servidores. El intercambio de contexto se produce cuando se expulsa un programa en ejecución en la CPU para dar paso a otro. Para solucionar esta situación de sobrecarga, se decidió agregar una segunda CPU al sistema. Figura 4.3: Estadísticas de número de clientes y visitas. Fuente: propia. Una vez modicadas las características hardware de los servidores, no se ha presentado ningún problema relevante relacionado con el rendimiento y diseño de la arquitectura. De hecho, tal y como se puede observar en las estadísticas de Moodle de las Figuras 4.3 y 4.4, se han llegado a soportar cargas

111 4. Servicios web 111 más grandes que la de febrero y el sistema ha respondido satisfactoriamente. Figura 4.4: Estadísticas de número de accesos y de cheros consultados. Fuente: propia.

112

113 Capítulo 5 Análisis de sistemas de cheros A lo largo de este capítulo se describe el proceso de análisis y evaluación de alternativas seguido para tener exáctamente la misma información de los diferentes cheros, disponibles en el conjunto de servidores web virtualizados. Posteriormente, se analiza NFS, un sistema de cheros distribuido que comparte la información a través de una red. A continuación, se resumen las principales características de OCFS2, un sistema de cheros de disco compartido, y su elección como sistema de cheros para la arquitectura de alta disponibilidad del servicio de educación virtual Análisis de la problemática Como se ha visto, la plataforma de educación virtual de la UIB está basada en un conjunto de servidores, tanto web como de bases de datos, donde parte de la información generada de forma dinámica por los usuarios de la plataforma de educación virtual se almacena en los propios servidores web y no en los servidores de base de datos. Este funcionamiento implica que los distintos servidores web deben tener siempre disponible la misma información en los cheros. Es imprescindible encontrar una solución a este problema para que no se den casos como el siguiente: Alumno A se conecta al servicio de educación virtual de la universidad, Campus Extens. El balanceador le redirecciona al servidor web W1. Alumno A sube una práctica para la asignatura S y, por tanto, se almacena en el sistema de cheros del servidor web W1. El profesor P de la asignatura S se conecta a Moodle con el objetivo de comprobar qué alumnos han entregado las prácticas a tiempo. El balanceador le redirecciona al servidor web W2. 113

114 Sincronización periódica El profesor P únicamente ve las asignaturas cuyos alumnos hayan sido redireccionados por el balanceador hacia el servidor web W2. Por tanto, el profesor P no vería la práctica que el alumno A ha entregado a tiempo y correctamente. Para solventar esta problemática, se plantearon una serie de posibles soluciones que se detallan en las siguientes secciones de este capítulo Sincronización periódica La primera solución planteada consiste en la realización de una sincronización periódica entre los servidores, de forma que la información en los servidores se sincronice cada N minutos. Para ello, cada uno debe contar con su propio disco duro destinado al almacenamiento de los datos de usuario. Periódicamente se realizara una sincronización entre el contenido de los discos de los servidores mediante el uso de una aplicación. Como primera solución, se pensó en el uso de rsync[46]. La herramienta rsync utiliza una arquitectura de maestro/esclavo, de forma que siempre debe existir un servidor maestro, en el que se deben realizar las modicaciones/escrituras de cheros, y de un servidor esclavo, que es el que usa para sincronizarse con el servidor maestro. Debido a esta arquitectura, se descartó de inmediato el uso de rsync; ya que las escrituras únicamente se podrían realizar en un único servidor maestro, mientras que las lecturas se podrían realizar en cualquiera de los servidores. El hecho de que las escrituras únicamente se puedan realizar en un servidor hace que éste se convierta en el punto crítico de fallo, ya que las escrituras van únicamente dirigidas hacia él. Teniendo en cuenta este inconveniente, se observa como el servicio de educación virtual no contaría con alta disponibilidad. Existe un software que solventa el principal problema de rsync, denominado unison[47]. Unison es capaz de sincronizar varios discos en los cuales se hayan hecho modicaciones o creaciones de nuevos cheros a la vez. Sin embargo, a pesar de solucionar el principal problema de rsync, unison planteaba una serie de nuevos retos a resolver: 1. La escritura o modicación de un mismo chero en varios servidores web a la vez podría causar problemas a la hora de sincronizar. El balanceador de tráco podría redireccionar a dos usuarios a dos servidores web distintos y que cada uno de ellos modique el chero local del servidor a la vez. A la hora de sincronizarse entre ellos, se debería solucionar de alguna forma la modicación de ese chero.

115 5. Análisis de sistemas de cheros Por otra parte, existe el problema implícito en una sincronización periódica. Precisamente, en la periodicidad radica el problema. Cuando se implanta una sincronización periódica realizada cada N minutos, las modicaciones o creaciones de cheros no son visibles por todos los servidores al instante y es posible, en el peor de los casos, que los servidores no tengan visibilidad de los cambios hasta pasados N minutos. Unison soluciona el principal problema presentado por rsync. Sin embargo, es evidente que una sincronización periódica no es totalmente válida para un sistema de alta disponibilidad a causa del periodo de tiempo entre las sincronizaciones de datos. Ese es el tiempo máximo posible de falta de sincronización de la información en alguno de los servidores Network File System (NFS) Una vez descartada la opción de un sistema de cheros tradicional sincronizado periódicamente, se planteó la opción de elegir un sistema de cheros distribuido, accesible para lectura y escritura simultánea desde los diferentes servidores web. NFS es un sistema de cheros distribuido que está pensado, como su propio nombre indica, para un uso a través de red. La arquitectura que NFS plantea es relativamente sencilla. Se trata de un servidor que sirve a varios clientes el propio sistema de cheros. Para ello, el servidor simplemente exporta un directorio de su propio sistema de cheros tradicional y los clientes se conectan a él para acceder a los cheros. NFS aporta una serie de ventajas. Una de ellas es la sencillez del montaje ya que puede congurarse y empezar a usarse en cuestión de minutos. El soporte en las distintas distribuciones de GNU/Linux normalmente es nativo. Además se trata de un sistema de cheros que ha sido exhaustivamente probado durante muchos años por millones de usuarios en el mundo. Como se ha podido apreciar en la sección anterior, el caso especial a estudiar es la creación o modicación de cheros. En la creación o modicación de cheros es cuando se producen cambios en el sistema de cheros y, por tanto, deben ser propagados a los diferentes servidores. NFS permite realizar las escrituras de dos formas totalmente diferenciadas: 1. Escritura síncrona: este tipo de escritura es la utilizada por defecto en NFS. Mediante la escritura síncrona, el servidor maestro da la respuesta a las peticiones de modicación únicamente después de que los cambios hayan sido realizados en el dispositivo de almacenamiento físico.

116 Network File System (NFS) 2. Escritura asíncrona: en este caso, cuando un cliente realiza la petición de modicación al servidor, éste puede conrmar la modicación antes de que se realice en el dispositivo de almacenamiento físico. De esta forma, el servidor realiza la modicación en el dispositivo de almacenamiento físico cuando le sea posible pero no por ello deja en espera al cliente. En comparación con la escritura asíncrona, el hecho de activar la escritura síncrona penaliza gravemente la escritura. El motivo es que, desde el punto de vista del cliente, el tiempo de respuesta se ve incrementado al añadirse el tiempo de escritura en el dispositivo de almacenamiento físico. Resulta obvio que la escritura asíncrona presenta una gran ventaja en cuanto a rendimiento en comparación con la escritura síncrona. Sin embargo, se debe tener en cuenta que este aumento de rendimiento tiene asociado un riesgo de pérdida de datos, ya que podría darse el caso de que se produzca un error en el servidor entre el momento en que se conrma la escritura al cliente y el momento en que se realiza la escritura realmente en el dispositivo de almacenamiento físico Pruebas de rendimiento Se utilizó Bonnie++ para realizar una serie de pruebas para determinar el rendimiento del sistema de cheros distribuido NFS síncrono y asíncrono. Las pruebas realizadas son las siguientes: Lectura secuencial. Escritura secuencial. Posicionamiento aleatorio. Tratamiento secuencial de cheros. Tratamiento aletatorio de cheros. El funcionamiento concreto de cada prueba se encuentra detallado en la Sección Las tres primeras pruebas se realizaron sobre un chero de pruebas de 2GB de tamaño creado aleatoriamente por el propio benchmark. Las dos pruebas restantes, sobre tratamiento de cheros, se realizaron sobre un conjunto de 128 cheros creados también de forma aleatoria. En las pruebas de lectura secuencial, Cuadro 5.2, apenas se aprecian diferencias en el rendimiento de lectura. Sin embargo, tal y como se pueden

117 5. Análisis de sistemas de cheros 117 apreciar en los Cuadros 5.1 y 5.3; en el resto de pruebas sí se aprecia una gran diferencia de rendimiento entre la escritura asíncrona y síncrona. Per Char Block Rewrite Option K/sec % CPU K/sec % CPU K/sec % CPU sync async Cuadro 5.1: Escritura secuencial en NFS. Per Char Block Option K/sec % CPU K/sec % CPU sync async Cuadro 5.2: Lectura secuencial en NFS. Option pos/sec % CPU sync async Cuadro 5.3: Posicionamiento de cabezales aleatorio en NFS. En el tratamiento de cheros, tanto aleatorio como secuencial, es donde se aprecia la mayor diferencia de rendimiento entre la escritura síncrona y asíncrona en NFS. Tal y como se puede observar en los Cuadros 5.4 y 5.5, la creación y eliminación de cheros de forma síncrona es hasta un 716 % más rápido con la escritura asíncrona activada en el caso de eliminación de cheros de forma secuencial. De forma gráca, la diferencia de rendimiento entre escrituras síncronas y asíncronas sobre NFS se puede apreciar claramente en las Figuras 5.1 y 5.2. El motivo de esta diferencia radica en que la creación y eliminación de cheros implica escrituras en disco, de forma que la escritura síncrona hace que disminuya el rendimiento, al aumentarse el tiempo de conrmación al cliente. Si se observa la columna de lecturas, los rendimientos son muy parecidos, ya que lo único que varía es cúando el servidor da la conrmación de escritura al cliente. En este caso, no se realizan escrituras y, por tanto, el rendimiento no se ve afectado.

118 Network File System (NFS) Create Read Delete Option ch/sec % CPU ch/sec % CPU ch/sec % CPU sync async Cuadro 5.4: Tratamiento secuencial de cheros en NFS. Create Read Delete Option ch/sec % CPU ch/sec % CPU ch/sec % CPU sync async Cuadro 5.5: Tratamiento aleatorio de cheros en NFS Escalabilidad NFS es un sistema de cheros fácilmente escalable de forma horizontal. Añadir nuevos clientes que tengan acceso a los cheros compartidos por el servidor es una tarea sencilla que se realiza en cuestión de minutos. Sin embargo, se debe tener en cuenta que no se puede escalar horizontalmente de forma innita. Añadir más clientes, con sus correspondientes operaciones de lectura y escritura, añade un mayor tiempo de respuesta al encontrarse el servidor más saturado. Por ello, es importante ajustar los componentes del sistema que más afectan al rendimiento del servidor. Los aspectos más importante a tener en cuenta a la hora de desarrollar un subsistema de I/O son las necesidades y los patrones de acceso de las aplicaciones que utiliza el subsistema. Algunas características de las aplicaciones a tener en cuenta son la frecuencia de operaciones de lectura y escritura, el tamaño medio de chero, si las lecturas y escrituras se realizan de forma secuencial o aleatoria, o si los cheros se acceden a través de pequeños o grandes bloques. Estas características pueden determinar el sistema de cheros local del servidor. Otro aspecto que puede aumentar el rendimiento de NFS es la distribución de los datos. Siempre que sea posible para el administrador, se deben evitar las escrituras paralelas. Minimizando las escrituras paralelas se permite al servidor NFS hacer un uso más eciente de los sistemas de caché que dispone. Las escrituras realizadas de forma no paralela realizan un uso más ecaz de la caché del sistema de cheros. En un estudio de Dell[9], se comparó la velocidad en la escritura de cheros por parte de 32 clientes de forma paralela

119 5. Análisis de sistemas de cheros 119 Figura 5.1: Comparativa de rendimiento de NFS síncrono/asíncrono medido en KB/s. Fuente: propia. y secuencial. En los resultados, se observa como la escritura secuencial es 2,5 veces más rápida que la escritura en paralelo. El servidor de NFS es una aplicación software con soporte para múltiples hilos de ejecución. El número de hilos que se ejecutan afectará a la escalabilidad del servidor NFS. A medida que crece el número de clientes, conviene ir aumentando el número de hilos de ejecución. Del lado de los clientes se pueden congurar dos parámetros importantes que afectan al rendimiento de las operaciones de I/O. Estos parámetros son el rsize y wsize que denen el tamaño de los bloques de datos que son leidos y escritos, respectivamente, en cada petición Alta disponibilidad El principal inconveniente de NFS para un sistema de alta disponibilidad radica en su sencilla arquitectura, ya que se dispone de un único punto de error (single point of failure), el servidor. Si ocurre algún error que impida la conexión entre el servidor y los clientes, éstos últimos no tendrán acceso a la información contenida en el sistema de cheros. La solución para congurar un entorno de alta disponibilidad para NFS

120 OCFS2 Figura 5.2: Comparativa de rendimiento de NFS síncrono/asíncrono medido en cheros/s. Fuente: propia. consiste en disponer de un servidor secundario que únicamente sería utilizado en caso de que el principal estuviera inaccesible. Esta solución no aprovecha el hardware disponible, ya que el servidor secundario no es necesario ni útil a menos que el primario falle OCFS2 OCFS2 es un sistema de cheros de disco compartido desarrollado por Oracle Corporation y publicado bajo licencia GNU GPL[48]. Cumple con el estándar POSIX. Permite compartir un dispositivo de almacenamiento físico entre diversos servidores Linux. Fue integrado en la versión del kernel de Linux. Sin embargo, hasta la versión del kernel no dejó de considerársele como versión experimental. Algunas de las características destacables de OCFS2 son: Tamaño de bloque variable entre 512 bytes y 4 KB. Journaling. Arquitecturas x86 y x86_64 entre otras.

121 5. Análisis de sistemas de cheros 121 ACLs (Access Control List). Quotas. OCFS2 es un sistema de cheros de disco compartido, permite la lectura y escritura simultánea de varios servidores a la vez. El único requisito es que todos los servidores deben tener visibilidad del dispositivo físico o partición que contiene el sistema de cheros. Es la segunda alternativa que se planteó para solucionar la compartición de información entre los distintos servidores web. La principal motivación para realizar pruebas con un sistema de cheros nuevo es el pobre rendimiento ofrecido en escrituras síncronas por NFS. Además del bajo rendimiento en escrituras, la existencia de un único punto de error en NFS, el servidor, requería soluciones más complejas a las que requiere OCFS2. Figura 5.3: Conexiones de discos y sistemas de cheros para un único servidor. Fuente: propia. Cada servidor virtual tiene asociado varios dispositivos de almacenamiento; en concreto, tres. El primero de ellos va destinado a albergar el sistema operativo y las aplicaciones. El segundo contiene los cheros de registro, logs, de los servidores web. Estos dos discos tienen un sistema de cheros convencional, EXT3. El último disco contiene la información compartida entre todos los servidores mediante el sistema de cheros OCFS2. El esquema simplicado de montaje se presenta en la Figura 5.3. Ya que el disco con OCFS2 está compartido por más de un servidor virtual, las conexiones entre servidores y dispositivos de almacenamiento es la representada en la Figura 5.4. Se trata del mismo montaje representado en la Figura 5.3, pero conectando los servidores web al mismo disco con OCFS2.

122 OCFS2 Figura 5.4: Conexiones de discos y sistemas de cheros para dos servidores. Fuente: propia. Como se ha descrito anteriormente, se han distribuido los servidores web entre ambos CPD. En el caso del disco duro con OCFS2 se realiza una copia exacta, realizada en tiempo real, entre discos de ambos CPD gracias a la característica de Mirror View de las cabinas de discos. Este esquema de conexiones se puede observar en la Figura 5.5. A diferencia de NFS, en OCFS2 no existe ningún servidor que tenga el rol de servidor ni de cliente; todos son exáctamente iguales y tienen la misma relevancia. Los servidores se comunican entre sí para comprobar su estado de disponibilidad y comunicarse entre ellos las operaciones de I/O que estén realizando. OCFS2 está formado por el sistema de cheros en sí y por una serie de servicios o daemons que se ejecutan en todos y cada uno de los servidores. Dichos demonios son los encargados de sincronizar todas las operaciones de lectura y escritura de cheros así como de comprobar el estado de accesibilidad de cada uno de los servidores. La comprobación de que los servidores son accesibles por red entre sí se realiza a través de heartbeat[53], un servicio que se ejecuta en todos los servidores virtuales que forman parte de un clúster virtual. Entendemos por clúster, en este caso, una serie de servidores, físicos o virtuales, que proporcionan exáctamente el mismo servicio y que comparten una serie de recursos. En este caso, el recurso compartido es el disco duro. Heartbeat proporciona a los miembros del clúster: Monitorización de la disponibilidad de los servidores que forman el clúster.

123 5. Análisis de sistemas de cheros 123 Figura 5.5: Esquema de conexiones entre los servidores virtuales y los discos, situados en ambos CPD. Fuente: propia. Gestión del servicio según la disponibilidad de los recursos de los cuales depende. Esto le hace capaz de, por ejemplo, parar el servicio de OCFS2 en un servidor si el dispositivo de almacenamiento no se encuentra disponible para él y sin embargo, seguir funcionando en otro servidor si el dispositivo se encuentra disponible para él. Monitorización de los recursos del servicio del clúster para garantizar su correcto funcionamiento. Por ejemplo, dependencia de la conexión de red. Si la conexión a la red se pierde, se detiene el servicio. OCFS2 presenta claras ventajas sobre NFS. La principal ventaja es que no depende de la disponibilidad de ningún servidor maestro para funcionar. Además, como se puede observar en la Sección 5.5 el rendimiento de escritura de OCFS2 es muy superior al de NFS con la opción de escritura síncrona (sync) activada. Comparándolo con un sistema de cheros tradicional, como EXT3, OCFS2 presenta un rendimiento inferior. Esta inferioridad viene determinada por el hecho de que OCFS2 debe enviar información de sincronización entre los distintos servidores que acceden al sistema de cheros.

124 Análisis de rendimiento de NFS y OCFS2 Dicha información de sincronización tiene un cierto retardo y, por tanto, una penalización sobre los tiempos de lectura y escritura. La instalación y conguración de OCFS2 se encuentra detallada en el Apéndice C Análisis de rendimiento de NFS y OCFS2 En esta sección se presentan los resultados de las pruebas de rendimiento realizadas a los sistemas de cheros NFS y OCFS2. Ya que el objetivo era comparar en profundidad el rendimiento entre ambos sistemas de cheros se optó por IOZone como herramienta de benchmarking. Las características principales de IOZone, así como las pruebas que realiza, se han visto en la Sección El mismo conjunto de pruebas se le practicó a un sistema de cheros convencional como EXT3. El objetivo de esta prueba es tomar los resultados de EXT3 como base comparativa entre los otros sistemas de cheros. De esta forma, se puede medir la pérdida de rendimiento asociada a un sistema de cheros distribuido y a uno de disco compartido respecto a un sistema de cheros tradicional. Las pruebas se realizaron sobre dos servidores virtuales con idéntico hardware y software. Se conguraron diversos parámetros para poder ajustar la simulación a un comportamiento real. En primer lugar, se realizaron las pruebas de cada sistema de cheros en dos escenarios diferentes: dos procesos trabajando con dos cheros de 1 GB cada uno, y tres procesos trabajando con tres cheros de 500 MB cada uno. Los procesos realizan las pruebas de forma aleatoria sobre el conjunto de cheros proporcionado. Para cada una de las pruebas se realizó un total de cinco repeticiones bajo las mismas circunstancias y se calculó la media aritmética de los resultados para posteriormente ser representados en esta sección. Se han seleccionado estas pruebas debido a que la escritura concurrente de varios procesos sobre el mismo chero es la más penalizada ya que se debe asegurar la exclusión mútua entre los procesos. Además, en el caso de los sistemas de cheros distribuidos y de disco compartido, las modicaciones realizadas se deben noticar al resto de servidores para que sean conscientes de los cambios. Por ello, las pruebas de rendimiento sobre NFS se realizaron siempre sobre el cliente y nunca sobre el servidor. En el caso de OCFS2, es irrelevante dónde se realicen las pruebas ya que la comunicación entre todos los miembros del clúster es constante. Cabe destacar que este no es el comportamiento típico que se espera encontrar en los servidores de este proyecto. En general, son los profesores los

125 5. Análisis de sistemas de cheros 125 encargados de crear nuevos cheros en el servidor web (apuntes, prácticas, exámenes, entre otros). Las escrituras concurrentes sobre un mismo chero no se producen ya que cada profesor tiene su asignatura en un espacio reservado para la misma, de forma que nadie más puede realizar escrituras en su directorio. El comportamiento típico en Moodle sería que se produzca una única escritura por parte de un profesor y múltiples lecturas por parte de los alumnos. Sin embargo, se consideró oportuno realizar las pruebas con escrituras concurrentes por dos motivos principales: Las pruebas de rendimiento siguen siendo válidas. Se trata del peor escenario posible para estos sistemas de cheros. Por tanto, es un indicador signicativo del rendimiento que son capaces de proporcionar. Los resultados de estas pruebas pueden servir para otros proyectos que se realicen en el CTI donde quizás sí se puedan producir escrituras concurrentes sobre un mismo chero. Además, tal y como se vió anteriormente en la Sección 3.3, la preparación del siguiente curso por parte de la ocina de Campus Extens provoca una gran cantidad de operaciones de I/O que requieren de un sistema de cheros capaz de ofrecer un buen rendimiento, tanto en lecturas como en escrituras EXT3 La primera prueba realizada fue la prueba de EXT3, sistema de cheros convencional, que serviría como base de comparación para el resto de pruebas de rendimiento. Los resultados obtenidos se pueden observar en los Cuadros 5.6 y 5.7. Write Re-Write Read Re-Read Rand.Read Rand.Write EXT Cuadro 5.6: Resultados en Kbytes/seg de la prueba de rendimiento de EXT3. Tres procesos, tres cheros de 500 MB NFS Las pruebas de rendimiento descritas en la Sección 5.5 también se realizaron al sistema de cheros NFS. En el caso concreto de NFS, tal y cómo se explicó anteriormente, tan sólo interesa realizar las pruebas con la opción de

126 Análisis de rendimiento de NFS y OCFS2 Write Re-Write Read Re-Read Rand.Read Rand.Write EXT Cuadro 5.7: Resultados en Kbytes/seg de la prueba de rendimiento de EXT3. Dos procesos, dos cheros de 1GB. escritura síncrona. Los resultados de las pruebas se pueden observar en los Cuadros 5.10 y Cabe destacar que las pruebas de rendimiento sobre NFS se realizaron siempre en el cliente. De esta forma, toda operación de I/O que se haya realizado durante la prueba lleva implícita una comunicación de red con el servidor maestro. Write Re-Write Read Re-Read Rand.Read Rand.Write NFSa , EXT Cuadro 5.8: Resultados en Kbytes/seg de la prueba de rendimiento de NFS asíncrono. Tres procesos, tres cheros de 500 MB. Write Re-Write Read Re-Read Rand.Read Rand.Write NFSa EXT Cuadro 5.9: Resultados en Kbytes/seg de la prueba de rendimiento de NFS asíncrono. Dos procesos, dos cheros de 1 GB. Write Re-Write Read Re-Read Rand.Read Rand.Write NFSs NFSa EXT Cuadro 5.10: Resultados en Kbytes/seg de la prueba de rendimiento de NFS síncrono. Tres procesos, tres cheros de 500 MB.

127 5. Análisis de sistemas de cheros 127 Write Re-Write Read Re-Read Rand.Read Rand.Write NFSs NFSa EXT Cuadro 5.11: Resultados en Kbytes/seg de la prueba de rendimiento de NFS síncrono. Dos procesos, dos cheros de 1 GB. En los resultados se puede observar el pobre rendimiento presentado por NFS síncrono a la hora de realizar escrituras. En comparación al rendimiento ofrecido por EXT3, en el caso de escrituras, NFS síncrono no llega al 10 % en ninguna de las pruebas. En el caso de lectura, NFS presenta un rendimiento en torno al 20 % del ofrecido por un sistema de cheros convencional (EXT3). Los malos resultados de la prueba en modo síncrono, en parte, se pueden achacar al hecho de haber realizado el benchmark en el cliente y no en el servidor maestro. Esto hace que en todas las pruebas se obtenga un peor resultado que con un sistema de cheros convencional, simplemente por el hecho de tener que realizar las operaciones a través de red. Sin embargo, el objetivo principal de estas pruebas es analizar, en la medida de lo posible, la peor situación posible para la arquitectura. En el caso de una infraestructura web dependiente de un sistema de cheros NFS, el peor rendimiento se ofrece siempre en los servidores que actuen como clientes, ya que siempre existe un overhead mínimo debido a las comunicaciones de red con el servidor maestro. Cabe destacar y explicar el resultado de la prueba de escritura en modo asíncrono, en el cual se puede apreciar un aumento de rendimiento, es decir, un menor tiempo, con respecto a EXT3. El motivo por el cual se da este resultado es porque en el sistema de cheros NFS en modo asíncrono, una vez enviada la petición de escritura al servidor maestro, éste conrma la escritura sin haberla realizado aún al disco físico. Si la latencia introducida por la red es pequeña, este proceso tarda menos que EXT3 en escribir físicamente en el disco. De ahí la diferencia de rendimiento a favor de NFS asíncrono OCFS2 A continuación se visualizan los resultados obtenidos por OCFS2 realizando exáctamente las mismas pruebas de rendimiento sobre el mismo hardware. Para facilitar la comparación de rendimiento, tanto con NFS como con EXT3, se incluyen en las tablas el porcentaje de rendimiento que OCFS2 representa

128 Conclusiones en comparación con estos. Write Re-Write Read Re-Read Rand.Read Rand.Write OCFS NFSs NFSa EXT Cuadro 5.12: Resultados en Kbytes/seg de la prueba de rendimiento de OCFS2. Tres procesos, tres cheros de 500 MB. Write Re-Write Read Re-Read Rand.Read Rand.Write OCFS NFSs NFSa EXT Cuadro 5.13: Resultados en Kbytes/seg de la prueba de rendimiento de OCFS2. Dos procesos, dos cheros de 1 GB. Como se puede observar en los resultados obtenidos en los Cuadros 5.12 y 5.13, OCFS2 presenta un rendimiento inferior al de un sistema de cheros convencional como EXT3. Este resultado es consecuencia del funcionamiento de un sistema de cheros de disco compartido, ya que se debe asegurar la exclusión mútua entre los servidores a la hora de acceder a los datos Conclusiones Para facilitar la visión de los resultados, éstos se han agrupado en las grácas representadas por las Figuras 5.6 y 5.7, que corresponden a los resultados de las pruebas de rendimiento con tres procesos y tres cheros de 500 MB, y dos procesos y dos cheros de 1 GB, respectivamente. Al observar los resultados de las diferentes pruebas se puede observar como EXT3 es claramente el sistema de cheros con mejor resultado. A pesar de ello, al ser un sistema de cheros tradicional no sirve para la nalidad del proyecto, debido a que ambos servidores web deben tener acceso a la misma información en todo momento. Por tanto, las pruebas de EXT3 sirven únicamente

129 5. Análisis de sistemas de cheros 129 como punto de referencia para medir el rendimiento del resto de sistemas de cheros analizados. Figura 5.6: Resultado de las pruebas de rendimiento sobre los distintos sistemas de cheros con tres procesos y tres cheros de 500 MB. Fuente: propia. NFS asíncrono, por su parte, presenta un excelente resultado, incluso superando las tasas de escritura de EXT3. El motivo de estos resultados tan buenos están explicados en la Sección En resumen, se debe a que el modo asíncrono no espera a que los datos se hayan escrito físicamente en el disco. Una vez entregada la orden de escritura al subsistema maestro de NFS, ésta se da por realizada. Al modicar esta característica de NFS y forzar el modo síncrono, se aprecia claramente una disminución del rendimiento en escrituras. En este caso, observando los resultados, se observa como el rendimiento de NFS síncrono es aproximadamente un 3 % del que tiene EXT3. Estos resultados motivan la búsqueda de una solución mucho más equilibrada para sustituir a un sistema de cheros tradicional. Los resultados de OCFS2 son bastante más equilibrados. En cuanto a las escrituras, al igual que ocurre con NFS síncrono, ofrece un rendimiento peor si lo comparamos con EXT3. Sin embargo, es mucho mejor que el presentado por la otra alternativa, NFS. Si comparamos el rendimiento de NFS síncrono

130 Conclusiones Figura 5.7: Resultado de las pruebas de rendimiento sobre los distintos sistemas de cheros con dos procesos y dos cheros de 1 GB. Fuente: propia. con OCFS2 obtenemos que este último es hasta 55 veces más rápido en escrituras de cheros de 1 GB. Se debe tener en cuenta que la prueba se ejecuta únicamente sobre uno de los servidores web y que, por tanto, el resultado de la prueba de rendimiento no se ve en ningún momento afectado por posibles interrupciones hechas por el otro servidor. En la arquitectura nal, ambos servidores trabajan con los mismos datos sobre el mismo sistema de cheros y, por tanto, estas interrupciones se producirán. El cómo se solucionarán estos casos de exclusión mútua entre servidores, depende de la propia implementación de los sistemas de cheros. Si suponemos que ambos sistemas de cheros utilicen un algoritmo de rendimiento y solución similar, podemos suponer que los resultados obtenidos en esta prueba son representativos del comportamiento que ofrece el sistema nal. Finalmente, se decide utilizar OCFS2 como sistema de cheros para solucionar los problemas expuestos en la Sección 5.1. Debido al funcionamiento de Moodle, era necesario encontrar un sistema de cheros que permita compartir la información entre varios servidores web. Esta característica garantiza poder escalar horizontalmente y, además, ofrecer alta disponibilidad en el servicio web sobre Moodle. OCFS2, en comparación con NFS síncrono, ofrece un gran rendimiento, mostrándose mucho más estable en las pruebas, tanto

131 5. Análisis de sistemas de cheros 131 de lecturas como de escrituras. El problema de NFS síncrono radica en su pobre rendimiento en escrituras. Además, ofrecer alta disponibilidad sobre NFS y, tal y como se ha visto en la Sección 5.3.3, requiere un servidor maestro secundario. En OCFS2 estos problemas no existen, y la escalabilidad y alta disponibilidad vienen proporcionadas por el propio sistema de cheros.

132

133 Capítulo 6 Escalabilidad y alta disponibilidad en MySQL En este capítulo se realiza una introducción al SGBD MySQL. Se describen brevemente las características generales y el funcionamiento, así como las particularidades que le diferencian de otros SGBD. Para nalizar, se analiza la escalabilidad y las diferentes soluciones que ofrecen alta disponibilidad con MySQL Introducción a MySQL MySQL es un SGBD de tipo relacional. En las bases de datos relacionales, tal y como se ha visto en la Sección 2.6.1, la información se organiza mediante relaciones representadas a través de tablas. Cada tabla tiene una serie de las que contienen los atributos. Proporciona soporte multiusuario a una gran variedad de sistemas operativos, con soporte para procedimientos almacenados (también conocidos como stored procedures), triggers, caché de operaciones, soporte para transacciones, integridad referencial, entre otros. Como característica diferenciadora de otros SGBD, MySQL implementa diversos sistemas de almacenamiento para las tablas. El Administrador de Base de Datos (DBA) puede elegir el que sea más adecuado para cada tabla en función de las características de cada sistema. En la sección D.4 se explican los sistemas de almacenamientos. La arquitectura lógica de MySQL se puede observar en la Figura 6.1, donde se pueden apreciar tres capas que interactúan entre sí. La primera capa corresponde al tratamiento con los servicios externos a MySQL, típicamente relacionados con una conexión cliente/servidor. Por tanto, proporciona métodos de gestión de conexiones, autenticación y seguridad, entre otros. 133

134 Escalabilidad en MySQL Figura 6.1: Arquitectura de MySQL. Fuente: High Performance MySQL. La segunda capa de la arquitectura es la correspondiente al parser, o analizador. Aquí es donde se analizan, inspeccionan y optimizan todas las funciones del SGBD. En esta capa también se gestiona la caché de las sentencias realizadas anteriormente. Cualquier operación a nivel de sistema de almacenamiento se proporciona en este nivel: stored procedures, triggers y vistas, entre otros. La tercera y última capa se encarga de los sistemas de almacenamiento. Esta capa es la responsable de cómo tratar con la información almacenada en la base de datos. Su funcionamiento es similar al de un sistema de cheros de un sistema operativo. MySQL proporciona diversos sistemas de almacenamiento, cada uno con sus características propias. La comunicación entre la capa anterior y esta se realiza mediante una API de forma que el sistema de almacenamiento elegido sea totalmente transparente para las capas superiores. El funcionamiento de MySQL se encuentra explicado en mayor profundidad en el Apéndice D Escalabilidad en MySQL Exáctamente igual que pasa en el caso del escalado de servidores web, la mayor complicación a la hora de planicar la escalabilidad de MySQL es estimar la carga que debe soportar. Si se sobredimensiona el sistema, se

135 6. Escalabilidad y alta disponibilidad en MySQL 135 desaprovechan recursos, y si se infradimensiona, no se soporta correctamente la carga. Escalar de forma vertical, sustituyendo servidores por otros más potentes, es una solución a corto plazo y que, si la carga generada por la aplicación sigue aumentando, tarde o temprano dejará de funcionar. Además, los costes económicos generados por tanto cambio de hardware se disparan. Dejando de lado el hardware, el propio software de MySQL no escala bien verticalmente, ya que no usa todas las CPUs y discos de forma eciente. El escalado horizontal es la forma más simple y común de escalar un sistema MySQL, distribuyendo los datos entre varios servidores a través de una replicación asíncrona y utilizando los servidores esclavos para las queries de lectura. Esta solución es perfecta para entornos cuya alta carga esté generada por lecturas Replicación La replicación de base de datos permite congurar uno o más servidores esclavos, también denominados réplicas, de otro servidor maestro. Es decir, la replicación se basa en mantener los datos sincronizados entre los distintos servidores. Es exible, ya que se pueden congurar maestros y esclavos en diferentes topologías. Soporta dos tipos de replicación: lógica y basada en las. Ambos métodos se basan en almacenar los cambios en el binary log del servidor maestro, replicándolo en el esclavo de forma asíncrona. Debido a la replicación asincrona, en los esclavos no se puede asegurar que todos los datos estén actualizados. Además, el tiempo de latencia de los esclavos no se puede determinar, ya que depende del número y complejidad de las modicaciones que se estén realizando en el servidor maestro. En cuanto a rendimiento, la replicación añade carga extra al servidor maestro. Primero, el registro binario de por sí añade carga al servidor y empeora su rendimiento. Además, existe un overhead debido a operaciones de I/O a través de red, debido a las comunicaciones con los servidores esclavos. En sistemas con altas cargas debido a numerosas lecturas, la replicación es una perfecta solución de escalabilidad en MySQL, ya que basta con añadir nuevos servidores esclavos para poder distribuir la carga de las lecturas entre más servidores. Sin embargo, en sistemas con elevadas escrituras, aumentar el número de esclavos únicamente empeora el rendimiento, ya que causará más I/O de red en el servidor maestro y el sistema se dedicará a replicar las numerosas escrituras en todos los servidores esclavos. Debido a que ese gran número de operaciones de escritura se deben realizar en todos los servidores, el cuello de botella del sistema será el servidor que peor rendimiento tenga. La replicación en MySQL aporta una serie de ventajas destacables:

136 Escalabilidad en MySQL Balanceo de carga: las operaciones de lectura/consulta se pueden distribuir entre todos los servidores esclavos, distribuyendo la carga entre los servidores. El método de balanceo de carga puede ser cualquiera, desde Round Robin DNS al uso de balanceadores de tráco. En la Sección 2.4 se puede encontrar más información sobre el balanceo de tráco. Distribución de los datos: los requisitos de esta técnica, en términos de ancho de banda, no son muy elevados, por lo que es posible tener los datos replicados en diferentes localizaciones geográcas. Copia de seguridad: este punto es derivado del anterior, ya que resulta sencillo tener réplicas de una base de datos en otros servidores. Es importante recordar que la replicación se realiza de forma asíncrona, por lo que los datos existentes en los esclavos pueden no estar actualizados. Sin embargo, las tareas de copias de seguridad, en casos donde la carga es elevada, se realizan en los servidores esclavos para no sobrecargar al servidor maestro. Tolerancia a fallos: al disponer de más de un servidor, la tolerancia a fallos del servicio de base de datos se ve aumentada. Funcionamiento A continuación se explica el funcionamiento de la replicación en MySQL a partir de la versión 4.0, ya que previamente funcionaba de forma distinta. El funcionamiento de la replicación en MySQL es un proceso que se divide en tres etapas: 1. El servidor maestro almacena en su registro binario los cambios realizados en los datos. A estos cambios se le llaman eventos. 2. El servidor esclavo copia los eventos del registro binario del servidor maestro a su registro de réplica, relay log. 3. El esclavo ejecuta los eventos del relay log, aplicando los cambios sobre sus propios datos. Este proceso de tres estapas se puede ver representado grácamente en la Figura 6.2. En la primera etapa del proceso, justo antes de que se actualice un dato en el servidor maestro, éste guarda los cambios en su registro binario. Una vez que se han almacenado los eventos en el registro binario, el servidor indica

137 6. Escalabilidad y alta disponibilidad en MySQL 137 Figura 6.2: Esquema de funcionamiento de la replicación en MySQL. Fuente: High Performance MySQL. a los sistemas de almaccenamiento que pueden nalizar la transacción, es decir, modicar el dato. La siguiente etapa consiste en copiar el registro binario del servidor maestro al servidor esclavo, en concreto, a su relay log. Para ello, el servidor esclavo lanza el I/O thread, que no es más que una conexión al servidor maestro como si de un cliente más se tratara. Una vez realizada la conexión, se inicia un proceso de volcado donde se leen los eventos del registro binario del servidor maestro. El I/O thread va replicando todos estos eventos hacia el relay log del servidor esclavo. Una vez nalizado, se queda en un estado de espera hasta que el servidor maestro le indique que hay nuevos eventos. Por último, es el servidor esclavo el encargado de nalizar el proceso de réplica a través del SQL Thread. Básicamente se debe encargar de ir leyendo y ejecutando los eventos de su relay log para actualizar sus datos. En general, el relay log se puede mantenar en la caché de memoria del sistema operativo y proporciona muy poca sobrecarga. Como se puede observar en la Figura 6.2, los procesos encargados de copiar los eventos del registro binario -I/O thread- y el encargado de replicarlos en el esclavo -SQL thread- pueden funcionar perfectamente por separado de forma asíncrona. Cabe destacar que el relay log del servidor esclavo contiene todos los eventos realizados en el servidor maestro de forma secuencial. En el servidor

138 Escalabilidad en MySQL maestro se pueden haber ejecutado varias sentencias de modicación de datos en paralelo y en el servidor esclavo se ejecutarán de forma secuencial. Esta característica de la replicación en MySQL puede provocar cuellos de botella en la replicación Sharding Tal y como se ha visto en la Sección 2.6.3, la técnica de sharding debe ser utilizada únicamente como último recurso, ya que tiene grandes inconvenientes, entre ellos, la costosa administración. En general, se recomienda escalar el sistema mediante replicación y, posteriormente, utilizar sharding como un método de mejora de rendimiento, únicamente en caso necesario. En el caso concreto de este proyecto, no tiene sentido aplicar esta técnica, ya que habría que modicar ampliamente el código fuente de Moodle. Estas modicaciones se deberían ir arrastrando y adaptando a las nuevas versiones de Moodle que se publiquen, ya que éstas podrían incluir cambios en la estructura de la base de datos que puede hacer que este método de partición ya no sea válido. Es decir, únicamente se podría plantear el uso de sharding como una mejora de rendimiento del subsistema de base de datos MySQL Cluster MySQL Cluster es una base de datos que funciona sobre un conjunto de servidores. Esta arquitectura proporciona alta disponibilidad, escalabilidad, gestión propia de errores (failover) y redundancia. Esta base de datos utiliza el sistema de almacenamiento NDB Cluster. Existen una serie de componentes que deben estar presentes en la arquitectura para proporcionar estas características: Manager: servicio encargado de iniciar el clúster, gestionar la conexión de los servidores y realizar la administración general del clúster. Una vez el clúster está iniciado, este componente no es indispensable para el correcto funcionamiento del mismo. Nodos de datos: encargados del almacenamiento de los datos. De cara a proporcionar alta disponibilidad y redundancia es imprescindible contar con dos servidores como mínimo. Los índices de las tablas se almacenan en memoria para proporcionar un acceso más rápido a los datos, que pueden estar en memoria o en disco. Es recomendable que

139 6. Escalabilidad y alta disponibilidad en MySQL 139 todos los nodos de datos del clúster tengan unas características hardware similares, para que ninguno de ellos se convierta en el cuello de botella. Nodos de API: encargados de proporcionar acceso al clúster mediante una API. Por regla general se utiliza el servicio propio de MySQL, denominado mysqld. Estos nodos reciben las sentencias a realizar en el clúster a través del lenguaje SQL y realizan las operaciones pertinentes sobre los nodos de datos. Escalar el sistema de BBDD, de forma horizontal, con MySQL Cluster implica añadir nuevos nodos; bien sean de datos, de API o ambos. El nodo Manager únicamente es necesario para iniciar el clúster y, por tanto, es prescindible una vez iniciado. Sin embargo, si ocurre una parada total del sistema este nodo es imprescindible. Conviene, por tanto, tener un nodo Manager secundario en caso de que el primario tenga algún fallo grave que no permita su uso. Este sistema también puede ser fácilmente escalado de forma vertical, mediante la ampliación de componentes hardware de los servidores. Sin embargo, tiene más sentido aplicar el escalado horizontal para aumentar la disponibilidad del servicio, tal y como se ve en el siguiente apartado. En la Sección se explica con mayor detalle el funcionamiento de MySQL Cluster Alta disponibilidad en MySQL A lo largo de esta sección se presentan las características y funcionamiento de MySQL Cluster, la solución que proporciona MySQL para entornos de alta disponibilidad. Adicionalmente, se comenta una posible solución basada en replicación. Si bien esta solución no proporciona una disponibilidad total, sí que proporciona un elevado índice de disponibilidad que podría ser suciente según las necesidades Replicación + Heartbeat Esta solución consiste en aplicar la técnica de replicación vista en la Sección con un servidor maestro y varios esclavos y utilizar heartbeat para realizar una monitorización entre ellos. Un fallo en uno de los servidores esclavos no interrumpe el servicio y por tanto, no se considera crítico. Sin embargo, un fallo en el servidor maestro provoca que los clientes no puedan

140 Alta disponibilidad en MySQL realizar escrituras sobre la base de datos. El servicio de base de datos estaría parcialmente disponible, debido a que las lecturas sí se podrían realizar correctamente. En caso de que se produjese un error en el servidor maestro, los servidores esclavos lo detectarán gracias al heartbeat, ya que el servidor maestro habría dejado de responder a sus chequeos. Se puede congurar uno de los servidores esclavos para que, en caso de fallo en el maestro, pase a sustituirlo. Este proceso de sustitución del servidor maestro se denomina failover. De esta forma, el servicio se vería restablecido en su totalidad, al poderse realizar de nuevo escrituras sobre la base de datos. Sin embargo, cabe destacar que el sistema de replicación es un proceso asíncrono. Por tanto, el servidor esclavo que asuma el rol de maestro, no tiene porqué tener toda la información actualizada, pudiendo dar lugar a información corrupta. El failback, proceso en el cual se restablece el servidor maestro original y se devuelve al servidor esclavo a su estado original, es un proceso delicado y que se debe realizar de forma manual, a través de la intervención del administrador de sistemas. Este proceso implica sincronizar de nuevo los datos modicados entre el servidor esclavo (que actuó de maestro temporalmente) y el servidor maestro (que no tendrá la información actualizada al haber tenido problemas). Para este proceso, es conveniente denegar el servicio a los clientes, para asegurarse que no se produzcan modicaciones de datos a la vez que se realiza la sincronización. Una vez se haya sincronizado la información entre ambos servidores, se deben restablecer los roles en cada uno de ellos. Finalizado este proceso, se restablece la distribución inicial del servicio MySQL Cluster Tal y como se ha visto en la Sección 6.2.3, MySQL Cluster funciona sobre un conjunto de servidores que reparten sus funciones entre nodos de administración, de datos o de API. El número de nodos se puede incrementar de forma sencilla, aumentando así su escalabilidad, tolerancia a fallos y disponibilidad. Un entorno de BBDD con dos nodos de datos, dos nodos de API y dos nodos de administración cumple con los requisitos para proporcionar una alta disponibilidad, ya que dos nodos del mismo tipo deberían de tener algún fallo importante para interrumpir el servicio. Conviene aclarar que el concepto de nodo en MySQL Cluster hace referencia a los procesos que se ejecutan y no a los servidores donde se ejecutan. De esta forma, se pueden tener dos nodos de datos sobre un único servidor. Sin embargo, por razones obvias de redundancia y alta disponibilidad, se recomienda tener una relación uno a uno entre servidores y nodos.

141 6. Escalabilidad y alta disponibilidad en MySQL 141 Funcionamiento Todos los datos son replicados internamente por el clúster de forma síncrona y automática gracias al sistema de almacenamiento NDB. Esto ofrece redundancia, ya que la información de la base de datos se encuentra replicada en todos los nodos de datos. Si un nodo cae, el resto contienen la misma información. Además el clúster puede particionar automáticamente los datos entre un conjunto de nodos. De esta forma, podemos escalar fácilmente el servicio de forma horizontal, simplemente agregando nuevos servidores. Cabe destacar que la replicación realizada en MySQL Cluster es síncrona a diferencia de la replicación típica de MySQL que es asíncrona. Gracias a esta característica del clúster, la replicación síncrona nos proporciona una consistencia de la información almacenada en todos los nodos. Para realizar la replicación síncrona, el clúster no devuelve el control al usuario hasta que los datos no han sido replicados en los nodos seleccionados. El particionado es también totalmente automático. El cluster se encarga de dividir las tablas en distintas particiones y dividir los datos entre los distintos nodos de datos. El administrador siempre puede denir su propio esquema de particionado. A la hora de congurar la replicación del clúster se debe decidir el número de réplicas de nuestros que se deben realizar. Este número no puede ser aleatorio, sino que debe seguir una regla sencilla: el número de nodos debe ser divisible por el número de réplicas. Es decir, por ejemplo, si tenemos cuatro servidores, podemos tener una, dos o cuatro réplicas. Es recomendable tener más de una única réplica ya que, en caso contrario, no se proporciona ningún tipo de alta disponibilidad. Si el servidor contiene la única réplica de los datos se cae, los datos dejarán de estar accesibles. MySQL Cluster agrupa automáticamente los nodos de datos en grupos. El administrador no tiene ningún tipo de control sobre cómo se establecen estas agrupaciones. Además hay que tener en cuenta que el número de particiones que se realizan debe ser igual al número de nodos de datos. Limitaciones El principal inconvenientes que presenta MySQL Cluster radica en el sistema de almacenamiento NDB Cluster. Este sistema no soporta claves foráneas (foreign keys). Esta característica limita mucho su uso si el software no está especícamente diseñado teniendo en cuenta esta limitación. Además, dentro del clúster, los nodos de datos almacenan en memoria todos los datos de las tablas, incluyendo los índices. Los desarrolladores de MySQL han proporcionado una fórmula que da un valor aproximado de la

142 Análisis y propuesta de arquitectura. cantidad de memoria RAM que se necesita para cada nodo de datos en el clúster. Esta fórmula establece que la cantidad de memoria RAM necesaria por cada nodo de datos es directamente proporcional al tamaño de la base de datos y al número de réplicas, e inversamente proporcional al número de nodos de datos que componen el clúster. RAMNodoDatos = T ambasedatos NumReplicas 1,1 N umn odosdatos Otra de las grandes limitaciones de MySQL Cluster hace referencia a su rendimiento, debido a que tiene un rendimiento pobre al ejecutar sentencias complejas, incluso algunas fundamentales como joins. Cualquier sentencia que no afecte únicamente a los índices de una única tabla requiere comunicación entre los nodos y, por tanto, ofrece un peor rendimiento. Para nalizar, una de las principales limitaciones de MySQL Cluster radica en la seguridad de las comunicaciones de los nodos de datos, al no ir cifradas. En general, se recomienda el uso de MySQL Cluster únicamente en redes de área local, ya que en caso contrario, los datos se transmiten en claro. Sin embargo, en la arquitectura propuesta para este proyecto, este inconveniente no representa una amenaza ya que los servidores se encuentran en una red totalmente distinta a la de los clientes. Para que las comunicaciones entre los nodos de datos se vieran comprometidas, un atacante tendría que tener acceso a dicha red Análisis y propuesta de arquitectura. Después de analizar las diferentes soluciones disponibles para escalar y dotar de una elevada disponibilidad el sistema de BBDD, se cuenta básicamente con tres posibilidades: 1. Replicación: sistema de sincronización asíncrona en tiempo real entre un servidor maestro y uno o varios esclavos. En el servidor maestro se realizan todas las escrituras y éstas se replican en los esclavos. Las lecturas se pueden realizar en cualquiera de los servidores. El servidor es el punto principal de fallo ya que su caída implica un deterioro en el servicio. 2. Replicación + Heartbeat: sistema de replicación con una monitorización del servidor maestro por parte de los servidores esclavos. En caso de que ocurra un fallo con el servidor maestro, uno de los servidores esclavos asume su rol (failover). En cuanto se vuelva a disponer del servidor maestro, se procede al proceso de failback de forma manual.

143 6. Escalabilidad y alta disponibilidad en MySQL MySQL Cluster: el sistema es un clúster formado por una serie de nodos: nodo de administración, nodos de datos y nodos API. Según las características presentadas en las secciones anteriores, MySQL Cluster es la única solución fácilmente escalable y que, además, proporcione una elevada disponibilidad debido a la redundancia, balanceo y distribución de sus componentes. En el Cuadro 6.1 se comparan las principales características de las tres alternativas anteriores. Replicación Replic. + Heartbeat MySQL Cluster Failover Sí Sí Sí Failover automático No Sí Sí Failback automático No No Sí Replicación sincrona No No Sí Resincronización de datos automática No No Sí Balanceo de carga Lecturas Lecturas Sí Cuadro 6.1: Comparación de características de las soluciones presentadas basadas en MySQL. Sin embargo, el rendimiento de MySQL Cluster con consultas complejas es pobre. Analizando el código de Moodle, nos podemos encontrar con consultas que afectan a más de siete tablas, afectando seriamente al rendimiento del sistema. Además, el hecho de que los nodos de datos almacenen en memoria los datos hace que su implantación sea difícil. En junio de 2011, el tamaño de la base de datos era de aproximadamente 26 GB. Aplicando la Fórmula 6.3.2, vista anteriormente, obtenemos el Cuadro 6.2 que compara el número de nodos de datos y la cantidad de memoria RAM necesaria para poder montar el clúster según las necesidades del servicio actual. Para simplicar los cálculos se ha optado por jar el número de réplicas a 2, ya que un mayor número de réplicas implicaría una mayor cantidad de memoria requerida. La cantidad total de memoria necesaria, según la fórmula proporcionada por MySQL, es de 57,2 GB. Únicamente al sobrepasar los 15 nodos de datos

144 Análisis y propuesta de arquitectura. Número de nodos Memoria RAM (GB) 2 28,6 3 19, ,3 5 11, , ,81 Cuadro 6.2: Cantidad de memoria RAM necesaria para cada nodo de datos del clúster. Calculado con 26 GB de base de datos y dos réplicas. obtenemos menos de 4 GB de memoria RAM necesaria por cada servidor. Esta arquitectura es prácticamente imposible de implantar debido a sus elevados requisitos en hardware y, por tanto, una solución basada en MySQL Cluster debe ser descartada. Es evidente, por tanto, que la arquitectura propuesta debe estar basada en la técnica de replicación. Como se ha visto anteriormente, esta solución permite escalar fácilmente de forma horizontal añadiendo nuevos nodos esclavos. Sin embargo, el hecho de que haya un único punto de fallo, el servidor maestro, hace que la tolerancia a fallos y la disponibilidad del sistema se puedan ver comprometidos. Por eso, se ha optado por proponer una arquitectura basada en dos servidores, uno maestro y otro esclavo, con una monitorización de sus estados basada en heartbeat. En caso de que el servidor maestro tenga algún problema, el servidor esclavo asume su rol. Tal y como se explicó anteriormente, a este proceso se le denomina failover y se produce de forma totalmente automática por el sistema. Sin embargo, restaurar la situación inicial (proceso de failback) requiere intervención manual por parte de los administradores de sistemas, ya que se debe sincronizar de nuevo la información y reestablecer los roles. En la Figura 6.3 se puede apreciar el esquema de la solución propuesta. En ella, se puede apreciar un servidor maestro y un servidor esclavo, de forma similar que la arquitectura anterior del servicio. La diferencia radica en la introducción de la monitorización del estado del servidor maestro a través de heartbeat. En ella se pueden apreciar dos servidores virtualizados, sbdmdl1 y sbdmdl2. En condiciones normales, funcionan bajo una replicación típica maestro/esclavo. En caso de que el esclavo tenga un fallo, el servidor maestro sigue ofreciendo servicio de forma normal y cuando sbdmdl2 vuelva a estar operativo se realiza automáticamente una sincronización entre los datos de ambos

145 6. Escalabilidad y alta disponibilidad en MySQL 145 Figura 6.3: Propuesta de arquitectura de MySQL para el servicio de educación virtual. Fuente: propia. servidores. El tercer caso, cuando falla el servidor maestro, hace que sbdmdl2 asuma el rol de sbdmdl1. Para ello, además de modicarse una serie de parámetros en MySQL, se congura la IP del servidor maestro para poder atender las peticiones de los clientes de forma normal. Cuando el servidor sbdmdl1 vuelva a estar disponible, se requiere la intervención de los administradores, ya que se deben recongurar direcciones IP así como los roles dentro de MySQL. Otra posibilidad es dejar sbdmdl2 como el nuevo servidor maestro y recongurar manualmente sbdmdl1 como servidor esclavo, así como la monitorización de heartbeat. Es decir, invertir la conguración inicial después de que

146 Análisis y propuesta de arquitectura. ocurra un fallo en el servidor maestro. Esta última solución podría parecer óptima, ya que en ningún momento se interrumpe el servicio y se recupera la disponibilidad que ofrece esta arquitectura. Sin embargo, cabe destacar que la replicación de datos entre el servidor maestro y el esclavo se realiza de forma asíncrona. Podría ocurrir que, en caso de fallo del servidor maestro, en el esclavo no se encuentren los datos actualizados. Esta situación no se puede identicar hasta que se ha recuperado el servidor maestro original y se pueden comparar los registros entre ambos. La solución a este conicto de datos recae sobre el administrador de sistemas que debe determinar qué información es la correcta. Por último, también se propone el estudio de otras posibles soluciones basadas en SGBD alternativos a MySQL. Tal y como ya se ha explicado en la Sección 3.1, Moodle posee una capa de abstracción de BBDD que permite utilizar una gran variedad de SGBD. Alternativas como PostgreSQL están totalmente soportadas por Moodle. Incluso en la propia web de Moodle aportan una serie de características a favor de PostgreSQL[49].

147 Capítulo 7 Administración de los servidores En este capítulo se estudian los problemas derivados de administrar un conjunto elevado de servidores destinados a un único servicio. Además, se presenta una herramienta de monitorización, Munin, que ayuda a representar grácamente el estado de cada uno de los servidores y a generar alarmas en caso de que algo vaya mal. Posteriormente, se estudia brevemente Monit, un monitor de procesos que se encarga de mantener los procesos críticos en marcha. En caso de un error grave, los sistemas de monitorización alertarán de los errores, pero es necesario contar con un plan de contingencia para solucionarlos. Para nalizar, se mencionan las políticas de copias de seguridad utilizadas Análisis de la problemática Proporcionar escalabilidad y alta disponibilidad en el servicio de educación virtual son los principales objetivos de este proyecto. Estas características se llevan a cabo, sobretodo, mediante redundancia de servidores. Esta redundancia eleva el número de servidores a administrar mientras que se mantiene el número de servicios que aportan de cara al usuario. Para el administrador de sistemas del entorno de educación virtual, se ha pasado de una arquitectura basada en dos servidores físicos a dos servidores virtualizados dedicados a web y dos dedicados a BBDD. Por tanto, se produce un incremento del 100 % en el número de servidores que se deben administrar. Entre las tareas que se deben realizar periódicamente en los servidores destacan: 1. Mantenimiento del software instalado y de sus conguraciones. 147

148 Munin 2. Actualizaciones del software instalado. Ya sean debidas a la necesidad de nuevas funcionalidades o por motivos de seguridad. 3. Realización y restauración de copias de seguridad. 4. Análisis de rendimiento de los servidores para detectar ataques, picos de carga en determinadas épocas, fallos de conguración o posibles fallos de hardware. 5. Generación de estadísticas de forma periódica para comprobar el crecimiento de usuarios, de forma que se pueda ir escalando el sistema adecuadamente. 6. Detección de problemas. 7. Generación de alarmas ante problemas graves. Realizar todas estas tareas de administración en todos los servidores de educación virtual es una tarea costosa si no se automatizan algunas de ellas Munin Munin[50] es una herramienta de monitorización de servidores que analiza y memoriza estados o datos de diversos parámetros. Su principal característica es su función plug&play, gracias a la cual, simplemente con una instalación básica ya se obtienen una gran cantidad de grácas de estado del sistema. A través de Munin se puede monitorizar el rendimiento de los servidores, red, SANs, aplicaciones, etc. Gracias a que representa los datos grácamente es bastante sencillo determinar cambios drásticos en el rendimiendo de un sistema. Para recoger los datos, Munin utiliza RRDTool[51] y unos scripts escritos en Perl. Ha sido programado de forma que sea ampliable a través de la instalación de plugins que pueden ser desarrollados en cualquier lenguaje de programación. Su arquitectura es sencilla. Posee un servidor maestro que se conecta a los distintos nodos esclavos de forma periódica y les solicita la información. Posteriormente, el servidor maestro almacena los datos en cheros, utilizando RRDTool, y, en caso necesario, actualiza las grácas. Estas grácas son mostradas por el servidor maestro a través de una interfaz web sencilla. Para la monitorización de los servidores del servicio de educación virtual de la UIB se desarrollaron varios plugins a medida. Sus funciones eran las siguientes:

149 7. Administración de los servidores 149 Figura 7.1: Gráca de ejemplo de Munin. Fuente: propia. Estimación del número de clientes web conectados a un servidor web. Para ello, el plugin comprueba las conexiones únicas establecidas al puerto 80. Tiempo de respuesta en la ejecución de dos sentencias SQL de tipo SELECT y UPDATE ejecutadas desde los servidores web hacia los servidores MySQL. Se eligieron como sentencias SQL unas que se ejecutan habitualmente en el software de Moodle, referente al control de sesiones de usuarios, de forma que su tiempo de respuesta fuera representativo del comportamiento global del servicio. Número de sesiones de usuario activas en BBDD. Básicamente comprueba el número de entradas en la tabla correspondiente. Además de estos plugins a medida, Munin monitoriza, entre otros, los siguientes parámetros en los servidores del servicio de educación virtual:

150 Monit Sistema operativo: utilización de discos duros y de inodos, estadísticas de I/O, tráco de red, número y estado de conexiones de red, utilización de CPU, intercambios de contexto y carga. Apache: monitoriza el número de accesos por segundo, procesos y bytes transmitidos por segundo. MySQL: rendimiento (throughput) del sistema, número y tipo de sentencias por segundo Monit Monit[52] es una herramienta para administrar y monitorizar procesos y sistemas de cheros sobre sistemas operativos UNIX. Este monitor trabaja de forma local sobre cada uno de los servidores donde se instale. En el caso de la administración y monitorización de procesos, Monit es capaz de iniciar un proceso si éste no está ejecutándose, reiniciar un proceso si no responde o pararlo en caso de que esté consumiendo muchos recursos. En cuanto a los sistemas de cheros, puede monitorizar cambios en el sistema de cheros (checksums, tamaños, fechas de modicación, entre otros). Se congura a través de un intuitivo chero de conguración donde se le indican los tests a realizar, el número de fallos que toleramos y las acciones a realizar en el caso de que se superen el número de errores. A continuación se presenta el apartado de la conguración de Monit referente al servidor web: check p r o c e s s apache with p i d f i l e / var /run/ httpd2. pid s t a r t program = "/ e t c / i n i t. d/ apache2 s t a r t " stop program = "/ e t c / i n i t. d/ apache2 stop " i f f a i l e d host ce. uib. es port 80 p r o t o c o l http and r e q u e s t "/ e s t u d i s / l o g i n / index. php" with timeout 30 seconds then r e s t a r t i f 3 r e s t a r t s within 5 c y c l e s then timeout En caso de que Monit realice alguna accción, se informa al administrador a través de alertas. En la arquitectura de este proyecto, las alertas se realizan a través de correo electrónico. También dispone de un registro donde almacena todas las comprobaciones y acciones realizadas. Para chequear el estado de la monitorización existen dos posibilidades: bien a través de la línea de comandos o bien a través de una interfaz web sencilla. En la Figura 7.2 se puede apreciar una captura de pantalla de la interfaz de Monit.

151 7. Administración de los servidores 151 Figura 7.2: Captura de pantalla de Monit, monitorización de MySQL. Fuente: propia Plan de contingencia El plan de contingencia contiene las acciones a realizar en caso de que ocurra algún error en los servidores o, incluso, en todos ellos. Este plan es totalmente dependiente de la arquitectura planteada. En cuanto al servicio de educación virtual de la UIB cabe destacar: Todos los servidores se encuentran virtualizados sobre clústers de VMware ESX. Todos tienen el módulo VMware HA habilitado descrito en la Sección Los dos servidores web y los dos servidores de base de datos están virtualizados sobre servidores físicos situados en localizaciones diferentes, uno en cada CPD de los edicios Anselm Turmeda y Jovellanos. En cuanto a los dispositivos de almacenamiento, se cuenta con dos

152 Plan de contingencia cabinas EMC 2 que sincronizan a nivel de hardware el contenido de los discos de los servidores web. Cada CPD cuenta con dos líneas eléctricas independientes entre sí. Los servidores físicos disponen de fuentes de alimentación redundantes con, mínimo, dos conexiones a la red eléctrica. Cada una de ellas se conecta a una de las líneas eléctricas. Se dispone de elementos SAI (Sistemas de Alimentación Interrumpida) con unas baterías que prorporcionan aproximadamente 30 minutos de corriente a los servidores y elementos de red. Se cuenta con generadores de gasoil que entran automáticamente en funcionamiento en caso de una caida general de la red eléctrica. Estos generadores pueden proporcionar la potencia necesaria a todos los elementos de los CPD mientras se les suministre combustible. En cada CPD se cuenta con sensores de temperatura, de humedad, de humo, cámaras de seguridad, acceso por tarjeta y demás sistemas de seguridad de acceso físico. Como se puede apreciar, si un CPD entero se queda sin ofrecer servicio debido a algún problema inesperado, el servicio de educación virtual de la UIB seguiría en funcionamiento. Además, si se trata de una situación prevista, ya sea por una reparación o por una parada eléctrica programada, se pueden migrar las máquinas virtuales de un CPD al otro, mediante el uso de VMotion visto en la Sección Con lo señalado anteriormente simplemente se comprueba que, en caso de error, el servicio puede seguir funcionando siempre que un CPD esté operativo. Sin embargo, esto no explica cómo se deben arreglar los posibles problemas que surjan. A continuación se explican algunas de las medidas adoptadas para, en caso de desastre, volver a la situación normal lo antes posible. Se hacen backups o copias de seguridad de todos los servidores virtuales de forma periódica. En concreto, se realiza una copia completa el último n de semana de cada mes. Esta copia de seguridad se almacena en cintas durante un año en armarios ignífugos situados en localizaciones físicas diferentes a la de los CPD. Además, se realiza una copia de seguridad completa de forma semanal, con una duración mensual. Por último, diariamente se realizan copias de seguridad incrementales sobre la copia semanal anterior. Esta política permite restaurar la información

153 7. Administración de los servidores 153 con un margen de un día si se quiere recuperar la información de la última semana. Si se quiere restaurar información más antigua que una semana, se puede realizar según las copias semanales o mensuales. Nunca se podrá restaurar información más antigua a un año. A nivel de máquina virtual también se realizan copias de seguridad. Para ello, mensualmente se realiza una copia de seguridad de las máquinas virtuales a través de VMware Consolidated Backup, ver Sección Estos snapshots de las máquinas virtuales son almacenados en cintas con una duración anual. En caso de un desastre con una máquina virtual o con el servidor ESX que la ejecuta, se podrá restaurar a partir de la copia de seguridad del último mes. Este proceso tiene un tiempo de ejecución de, aproximadamente, 2 horas. Este tiempo incluye la búsqueda de las cintas, su lectura y la recuperación de información en un servidor de virtualización ESX que funcione correctamente. En el peor de los casos, habrá que congurar, a nivel de máquina virtual, las tarjetas de red o los dispositivos de almacenamiento. Esta operación no debería de añadir más de 30 minutos al tiempo de recuperación. En caso de un desastre a nivel de sistema de cheros, habrá que restaurar de la copia de seguridad más reciente. El peor caso, en cuanto a tiempo de recuperación, es que ocurra un fallo en el sistema de cheros OCFS2 de los servidores web, ya que es el que contiene más información. En ese caso, el tiempo de recuperación es de aproximadamente 8 horas. Este tiempo incluye realizar todo el montaje de OCFS2 desde cero y recuperar todos los GB de información. Para la recuperación de la información, se deberá recuperar primero la copia de seguridad completa semanal y, posteriormente, recuperar la última copia diaria incremental disponible. Cabe destacar que estos tiempos son aproximados y que, dependiendo de varios factores, se pueden ver alterados.

154

155 Capítulo 8 Conclusiones y trabajo futuro En este último capítulo se recogen las impresiones, experiencias personales y conclusiones obtenidas tras el desarrollo de este proyecto; así como el trabajo a realizar para completar y mejorar la calidad del servicio Arquitectura nal El principal objetivo de este proyecto era diseñar una nueva arquitectura para el servicio de educación virtual de la UIB. Ésta, tras realizar las pruebas oportunas, se ha ido planteando y elaborando a lo largo de los capítulos que componen este documento. Cabe recordar que todos los servidores están virtualizados, ya que esta técnica presenta un gran número de ventajas: aprovechamiento de recursos, técnicas de escalabilidad y alta disponibilidad, monitorización, snapshots, entre otros. Además, al contar con dos CPD y repartir la localización física de los servidores entre ellos, se aumenta la tolerancia a fallos como pueden ser los cortes eléctricos, inundaciones o demás interrupciones generales del edicio. Todos los elementos que forman parte de la arquitectura diseñada están replicados en ambos CPD, de forma que su funcionamiento no depende de ningún elemento crítico. Tal y como se ha podido observar, la arquitectura nal está diseñada partiendo de la base de la disposición de los dos edicios. Es por ello que se cuenta con dos balanceadores de tráco, encargados de repartir la carga entre los dos servidores web y de realizar todo el proceso de certicados SSL. Los dos servidores web comparten toda la información dinámica de la web del servicio a través del sistema de cheros OCFS2, un sistema de disco compartido. Al contar con dos cabinas de disco con Mirror View, se obtiene una replicación automática de los datos entre las cabinas de disco. De esta 155

156 Consecución de los objetivos forma, también se cuenta con la información replicada entre ambos CPD. El cuanto al subsistema de BBDD, se ha optado por una solución basada en replicación maestro/esclavo con una monitorización a través de heartbeat para poder dotar de mayor disponibilidad al sistema en caso de un error en el servidor maestro Consecución de los objetivos En relación a los objetivos que se establecieron en la etapa inicial del proyecto, se tiene la convicción de haberlos alcanzado de forma clara. Se ha diseñado e implantado una arquitectura de servidores web virtualizados. La incorporación de balanceadores de tráco, encargados de repartir la carga entre los servidores así como de monitorizar su estado, ha dotado de escalabilidad y alta disponibilidad a la arquitectura web. La arquitectura es escalable verticalmente gracias a la virtualización, ya que añadir más recursos a una máquina virtual es sencillo. Escalar horizontalmente los servidores web es trivial, ya que bastará con clonar una de las máquinas virtuales, modicar los parámetros oportunos de su conguración y añadirla al balanceador de tráco para que empiece a dar servicio. La alta disponibilidad viene proporcionada por la redundancia establecida en todos los miembros de esta arquitectura, tanto servidores como balanceadores. Además, cabe recordar que el propio VMware proporciona ciertas características que proporcionan alta disponibilidad, como VMware HA o VMotion. Cabe destacar la realización de un breve análisis y pruebas de rendimiento sobre distintos sistemas de cheros para compartir la información entre los servidores web. Finalmente, se decidió utilizar OCFS2, un sistema de cheros de disco compartido. Las principales características que motivaron la elección de OCFS2 son el hecho de no depender de un servidor y que haya obtenido un rendimiento digno en comparación con un sistema de cheros tradicional. También se ha diseñado una arquitectura de servidores de BBDD nueva. Esta arquitectura está basada en la técnica de replicación con un servidor maestro y un servidor esclavo. La solución propuesta es fácilmente escalable. Al tratarse de servidores virtualizados, escalar verticalmente los servidores es sencillo. Sin embargo, cabe destacar que existe un límite impuesto por el servidor físico antrión. Actualmente, cada una de las máquinas virtuales dedicadas a BBDD tienen asignados, como recursos virtuales, aproximadamente un 20 % de los recursos físicos disponibles. El sistema también es capaz de escalar horizontalmente añadiendo nuevos servidores esclavos. Como se ha podido ver anteriormente, esta técnica por sí sola, no proporciona una elevada disponibilidad, ya que tiene un único

157 8. Conclusiones y trabajo futuro 157 punto de fallo: el servidor maestro. Es por ello que se ha optado por añadir una monitorización mediante heartbeat entre los servidores. Si en un momento dado se encuentra un error en el servidor maestro que impida que proporcione servicio, el servidor esclavo asumirá el rol de servidor maestro. A este proceso se le denomina failover. Posteriormente, una vez solucionado el problema con el servidor, se debe restaurar la situación inicial mediante el proceso de failback. La arquitectura de BBDD diseñada y propuesta, aún no ha sido implantada. Se espera que el cambio de arquitectura de BBDD se produzca para el curso académico 2012/2013, a la vez que se actualice la versión de Moodle Experiencia personal En primer lugar ha sido necesario comprender el funcionamiento de Moodle. Al tratarse de una aplicación web se ha tenido que estudiar su funcionamiento y las peculariedades propias de ella. Al estar escrito en lenguaje PHP, también se ha tenido que investigar sobre los aceleradores, con el n de disminuir la carga sobre los servidores. En segundo lugar se ha tenido que estudiar el comportamiento típico de los servidores web: modelo cliente/servidor, certicados SSL y gestión de sesiones, entre otros. Una vez familiarizado con el comportamiento de un servidor web, era necesario incorporar balanceadores de tráco. Para ello, fue necesario entender su funcionamiento, la gestión de las sesiones y los algoritmos disponibles para repartir la carga. En tercer lugar, analizar las soluciones para compartir la información entre los servidores web ha sido una tarea complicada. Es difícil simular las peticiones que se realizan en los servidores, así que se optó por hacer pruebas de carga y comparar el rendimiento máximo en las operaciones típicas de un sistema de cheros. Cabe destacar la gran cantidad de opciones y personalización que ofrecen los diferentes benchmarks de sistemas de cheros, teniendo que acotar bastante el número de pruebas a realizar. En cuarto lugar, el estudio de BBDD ha sido muy útil, ya que ha servido para aanzar los conocimientos generales sobre bases de datos. En el caso del SGBD propuesto, MySQL, se ha explicado su funcionamiento interno así como las soluciones que ofrece para sistemas escalables y de alta disponibilidad. Por último, para implementar esta nueva arquitectura ha sido necesario familiarizarse con el entorno de virtualización de VMware. A nivel personal, y sin estar implícito en los objetivos, este proyecto me ha permitido poner en práctica y aanzar conocimientos adquiridos a lo largo

158 Trabajo futuro de las carreras de Ingeniería Técnica en Informática de Sistemas e Ingeniería en Informática, así como otros conocimientos adquiridos de forma independiente. En concreto, y debido a la temática, he podido comprender mejor ciertos conceptos de administración de sistemas operativos para, posteriormente, ponerlos en práctica Trabajo futuro Dentro de las líneas de trabajo futuro, podemos destacar dos tareas importantes: Implantación de la arquitectura de BBDD. Predicción de carga. En cuanto al primer punto, se debe implantar la arquitectura de BBDD propuesta para dotar al servicio de una elevada disponibilidad. Actualmente únicamente se cuenta con un subsistema de BBDD con replicación maestro/servidor, donde el servidor maestro se convierte en el punto único de fallo. Este objetivo no se ha podido realizar debido a la decisión, ajena a este proyecto, de esperar a la actualización de Moodle a una nueva versión. Estimar la carga que un servidor deberá soportar puede ayudar a predecir las situaciones de alta carga que se puedan presentar. Sin embargo, realizar esta estimación es uno de los principales problemas a la hora de diseñar o adaptar una arquitectura. La solución propuesta es facilmente escalable, tanto de forma vertical como de forma horizontal y, por tanto, puede adaptarse a nuevos crecimientos. Sin embargo, conviene estudiar algún sistema para poder predecir este crecimiento. Una posible solución es realizar un estudio al principio de cada curso académico del número de alumnos, profesores y cursos que van a estar presentes en el sistema. A partir de estas estadísticas, se podría predecir mínimamente el aumento de carga que la arquitectura deberá soportar.

159 Índice de guras 2.1. Escalabilidad vertical. Fuente: propia Escalabilidad horizontal. Fuente: propia Diferencias entre los dos tipos de Hypervisor: nativo y hosted. Fuente: propia Virtualización de la memoria. Fuente: TechArena Forums Virtualización de dispositivos e I/O. Fuente: TechArena Forums Comparativa entre una operación realizada en una virtualización total y utilizando paravirtualización. Fuente: propia Arquitectura de VMware Infraestructure. Fuente: VMware Topología física típica en un CPD con VMware Infraestructure. Fuente: VMware La asignación de máquinas virtuales a servidores físicos se administra de forma centralizada desde el VirtualCenter Management Server. Fuente: VMware Arquitectura general del centro de datos virtual. Fuente: VMware Servidores antriones, clústers y meta-servidores. Fuente: VMware VMware VMotion. Fuente: VMware VMware DRS. Fuente: VMware VMware HA proporciona alta disponibilidad en casos de fallos de hardware en los servidores físicos. Fuente: VMware VMware HA gestiona errores de sistema operativo en las máquinas virtuales. Fuente: VMware Arquitectura de red. Fuente: VMware Arquitectura general de almacenamiento. Fuente: VMware Esquema de Raw Device Mapping. Fuente: VMware Funcionamiento de VMware Consolidated Backup. Fuente: VMware Componentes del VirtualCenter Management Server. Fuente: VMware

160 160 ÍNDICE DE FIGURAS Acceso y control de VMware Infraestructure. Fuente: VMware Software de administración centralizada VMware Infraestructure Client. Fuente: propia Funcionamiento de la técnica round robin DNS. Fuente: propia Esquema de la comunicación entre el cliente y el servidor, pasando por el balanceador de tráco Fuente: propia Comparativa entre sistemas de cheros distribuidos y de disco compartido. Fuente: propia Replicación de base de datos. Fuente: propia Arquitectura Moodle con dos servidores. Fuente: propia Comparativa del número de visitas y archivos consultados en los meses de abril y mayo de Fuente: propia Infraestructura tecnológica de virtualización en el CTI. Fuente: propia Distribución de los dos balanceadores y los dos servidores web. Fuente: propia Esquema de comunicaciones HTTP/HTTPS entre los usuarios y los servidores. Fuente: propia Estadísticas de número de clientes y visitas. Fuente: propia Estadísticas de número de accesos y de cheros consultados. Fuente: propia Comparativa de rendimiento de NFS síncrono/asíncrono medido en KB/s. Fuente: propia Comparativa de rendimiento de NFS síncrono/asíncrono medido en cheros/s. Fuente: propia Conexiones de discos y sistemas de cheros para un único servidor. Fuente: propia Conexiones de discos y sistemas de cheros para dos servidores. Fuente: propia Esquema de conexiones entre los servidores virtuales y los discos, situados en ambos CPD. Fuente: propia Resultado de las pruebas de rendimiento sobre los distintos sistemas de cheros con tres procesos y tres cheros de 500 MB. Fuente: propia Resultado de las pruebas de rendimiento sobre los distintos sistemas de cheros con dos procesos y dos cheros de 1 GB. Fuente: propia Arquitectura de MySQL. Fuente: High Performance MySQL.. 134

161 ÍNDICE DE FIGURAS Esquema de funcionamiento de la replicación en MySQL. Fuente: High Performance MySQL Propuesta de arquitectura de MySQL para el servicio de educación virtual. Fuente: propia Gráca de ejemplo de Munin. Fuente: propia Captura de pantalla de Monit, monitorización de MySQL. Fuente: propia C.1. Captura de pantalla de la conguración de los nodos de ocfs2console. Fuente: propia C.2. Captura de pantalla de ocfs2console una vez formateada y montada la partición. Fuente: propia D.1. Bloqueo mutuo o deadlock. Fuente: propia

162

163 Índice de cuadros 2.1. Progreso del rendimiento del sistema con n procesadores Características hardware del servidor Dell PowerEdge 2850 de Moodle Características hardware de todos los servidores de virtualización Resumen de los tests realizados a los servidores Escritura secuencial en NFS Lectura secuencial en NFS Posicionamiento de cabezales aleatorio en NFS Tratamiento secuencial de cheros en NFS Tratamiento aleatorio de cheros en NFS Resultados en Kbytes/seg de la prueba de rendimiento de EXT3. Tres procesos, tres cheros de 500 MB Resultados en Kbytes/seg de la prueba de rendimiento de EXT3. Dos procesos, dos cheros de 1GB Resultados en Kbytes/seg de la prueba de rendimiento de NFS asíncrono. Tres procesos, tres cheros de 500 MB Resultados en Kbytes/seg de la prueba de rendimiento de NFS asíncrono. Dos procesos, dos cheros de 1 GB Resultados en Kbytes/seg de la prueba de rendimiento de NFS síncrono. Tres procesos, tres cheros de 500 MB Resultados en Kbytes/seg de la prueba de rendimiento de NFS síncrono. Dos procesos, dos cheros de 1 GB Resultados en Kbytes/seg de la prueba de rendimiento de OCFS2. Tres procesos, tres cheros de 500 MB Resultados en Kbytes/seg de la prueba de rendimiento de OCFS2. Dos procesos, dos cheros de 1 GB

164 164 ÍNDICE DE CUADROS 6.1. Comparación de características de las soluciones presentadas basadas en MySQL Cantidad de memoria RAM necesaria para cada nodo de datos del clúster. Calculado con 26 GB de base de datos y dos réplicas.144

165 Bibliografía [1] Scott Lowe. Mastering VMware vsphere 4. Sybex, [2] Ryan Troy, Matthew Helmke. VMware Cookbook. O'Reilly, [3] Remo Suppi Boldrito, Josep Jorba Esteve. GNU/Linux Advanced Administration. Eureca Media SL, [4] Evi Nemeth, Garth Snyder, Scott Seebass, Trent Hein. UNIX System Administration Handbook. Prentice Hall, [5] Evi Nemeth, Garth Snyder, Trent Hein, Ben Whaley. UNIX and Linux System Administration Handbook. Prentice Hall, [6] Rich Bowen, Ken Coar. Apache Cookbook. O'Reilly, [7] John Allspaw, Jesse Robbins. Web Operations. O'Reilly, [8] Baron Schwartz, Peter Zaitsev, Vadim Tkachenko, Jeremy D. Zawodny, Arjen Lentz, Derek J. Balling. High Performance MySQL. O'Reilly, [9] Andrew Bachler, Jenwei Hsieh. Maximizing NFS Scalability, pdf. [10] Citrix Systems, [11] VMware Virtualization Software, [12] RedHat Enterprise Linux, [13] Apache JMeter, [14] http_load, 165

166 166 BIBLIOGRAFÍA [15] Apache HTTP server benchmarking tool, docs/2.0/programs/ab.html [16] IOZone Filesystem Benchmark, [17] Bonnie++, [18] MySQL Database, [19] PostgreSQL Database, [20] SQLite, [21] Oracle Database, [22] Microsoft SQL Server, [23] DB2 Database, [24] HiveDB, [25] BigTable: A distributed Storage System for Structured Data, labs.google.com/papers/bigtable.html. [26] Amazon's Dynamo, 10/amazons_dynamo.html. [27] The Apache Cassandra Project, [28] Estadísticas de Moodle, [29] Apache Software Foundation, [30] May 2011 Web Server Survey, /05/02/may-2011-web-server-survey.html. [31] Lighttpd webserver, [32] nginx webserver, [33] eaccelerator, [34] WebCT, [35] Moodle: Open-source community-based tools for learning, moodle.org/. [36] Campus Extens,

167 BIBLIOGRAFÍA 167 [37] Proceso de Bolonia, queesbolonia/proceso-en-marcha/grupo-seguimiento-bolonia/ comision-europea-aval-del-proceso-de-bolonia.html. [38] EMC 2, [39] Novell, [40] ldirectord, [41] HAProxy The reliable, High Performance TCP/HTTP Load Balancer, [42] BalanceNG The Software Load Balancer, balanceng/. [43] Radware AppDirector OnDemand Switch 2, Products/ApplicationDelivery/AppDirector/default_TechSpec. aspx. [44] Radware AppXcel 4000, ApplicationDelivery/AppXcel/default_TechSpec.aspx. [45] Radware Insite Manage Pro, Management/InsiteManagePro.aspx. [46] rsync, [47] Unison File Synchronizer, unison/. [48] Licencia Pública General de GNU (GPL), licenses/licenses.es.html#gpl. [49] Arguments in favour of PostgreSQL, Arguments_in_favour_of_PostgreSQL. [50] Munin, [51] RRDtool, [52] Monit: monitor processes, les, devices and remote systems, mmonit.com/monit/. [53] Heartbeat,

168 168 BIBLIOGRAFÍA [54] SuSE Linux Enterprise Server, server/. [55] SuSE Linux Enterprise High Availability Extension, novell.com/es-es/products/highavailability/. [56] MVCC, concurrency_control.

169 Acrónimos MTTF Medium Time To Fail MTTR Medium Time To Repair CPD Centro de Procesamiento de Datos UIB Universitat de les Illes Balears CTI Centre de Tecnologies de la Informació SAN Storage Area Network I/O Input/Output o Entrada/Salida CSV Comma Separated Values o Valores Separados por Comas SGBD Sistema Gestor de Base de Datos BD base de datos LMS Learning Management System o sistema de gestión de aprendizaje API Application Programming Interface IOMMU Input/Output Memory Management Unit DMA Direct Memory Access MMU Memory Management Unit CSV Comma Separated Values VMM Virtual Machine Monitor HTML HyperText Markup Language HTTP HyperText Transfer Protocol 169

170 170 BIBLIOGRAFÍA SQL Structured Query Language BBDD Base de Datos TCP Transmission Control Protocol o protocolo de control de transmisión IP Internet Protocol o protocolo de internet WWW World Wide Web DNS Domain Name System o sistema de nombre de dominios LUN Logical Unit Number DBA Administrador de Base de Datos OCFS2 Oracle's Cluster File System v.2 YaST2 Yet Another Setup Tool v.2 MVCC Multiversion Concurrency Control

171 Apéndice A Glosario API: Application Programming Interface o interfaz de programación de aplicaciones. Es un conjunto de funciones y procedimientos que ofrece una o varias bibliotecas para ser utilizado por otro software como una capa de abstracción. Fuente: Wikipedia. Bases de datos distribuidas: colección de bases de datos interrelacionadas entre sí y distribuidas a través de una red de computadores. Un software especíco se encarga de que la distribución de la base de datos sea totalmente transparente para el usuario. CPD: Centro de Procesamiento de Datos o también conocido como Centro de Cálculo. Es aquella ubicación donde se concentran los recursos necesarios para el procesamiento de la información en una organización. Generalmente un CPD es un edicio o sala de gran tamaño utilizada para procesar y almacenar información y los equipos informáticos y telemáticos necesarios. Dirección IP: conjunto de números que, de forma lógica, identica una interfaz dentro de una red que utilice el protocolo IP. Distribución round robin: es un método para elegir todos los elementos en un grupo de forma equitativa y siguiendo un orden racional. Normalmente se comienza por el primer elemento de la lista hasta llegar al último y, posteriormente, empezando de nuevo por el primer elemento. Heartbeat: técnica de comunicación entre dos o más ordenadores a través de la cual se realiza una monitorización mútua del estado de cada ordenador. Permite ejecutar ciertas acciones en los servidores al detectar un cambio en el estado de los mismos. Estas acciones pueden 171

172 172 ser iniciar o parar un determinado servicio, conectar un dispositivo de red con una conguración determinada o incluso, apagar el servidor, entre otras. HTML: es un lenguaje de marcas utilizado para la elaboración de páginas web. A través de este lenguaje se dene la estructura y el contenido mediante el uso de etiquetas, identicadas entre corchetes angulares (<, >). HTTP: es el protocolo utilizado para realizar comunicación web. HTTP dene una sintaxis y una semántica que utilizan tanto clientes (navegador web) como servidores para comunicarse. Es un protocolo que está orientado a transacciones y sigue un comportamiento de petición/respuesta entre el cliente y el servidor. Es un protocolo sin estado ya que no se guarda ningún tipo de información sobre las conexiones anteriores. A menudo, las aplicaciones web necesitan mantener el estado. Para ello se introdujeron las cookies, que permiten a las aplicaciones web guardar datos sobre la sesión en el navegador del cliente. Internet: es un conjunto descentralizado de redes de comunicación que utilizan la familia de protocolos TCP/IP para su interconexión. De esta forma, diferentes redes físicas están conectadas entre sí formando una única red lógica de alcance mundial. La web, o World Wide Web (WWW), es el servicio más extendido a través de Internet. En Internet los usuarios se identican mediante una dirección IP, que a menudo se asocian a nombres, facilitando así su memorización para los usuarios. La conversión entre dirección IP y nombre la realiza un servicio denominado Domain Name System o sistema de nombre de dominios (DNS). iscsi: también denominado Internet SCSI, es una tecnología que permite el uso del protocolo SCSI sobre redes TCP/IP. LDAP: o Lightweight Directory Access Protocol, es un protocolo que permite el acceso a un servicio de directorio ordenado. A través de él se pueden realizar búsquedas de información a través de la red. Un directorio es un conjunto de objetos que tienen una serie de atributos asignados y organizados de forma lógica y jerárquica. LUN: una LUN es un disco duro virtual proporcionado por una SAN. Una LUN presentada a un servidor, actuará exáctamente igual que un disco duro convencional conectado al mismo. Este disco virtual puede ser particionado y formateado de forma convencional.

173 A. Glosario 173 MAC Address: o dirección MAC. Es un identicador de 48 bits que corresponde de forma única a una tarjeta ethernet de red. Microkernel: núcleo del sistema operativo que proporciona un conjunto de primitivas o llamadas al sistema mínimas para implementar servicios básicos; como espacios de direcciones, comunicación entre procesos y planicación de tareas básicas. Todos los otros servicios; como gestión de memoria, sistema de cheros, operaciones de I/O, entre otros; que en general son provistos por el núcleo, se ejecutan como procesos servidores. Si el hardware proporciona diversos niveles de privilegios de ejecución, el microkernel es el único software que se ejecuta en el nivel más privilegiado. Fuente: Wikipedia. Multiversion Concurrency Control (MVCC): sistema de optimización de bloqueo de las, no exclusivo a MySQL, que reduce la sobrecarga sobre el sistema y además ofrece mayor concurrencia[56]. Niveles de RAID: a continuación se explicarán brevemente los niveles de RAID más comunes: RAID 0: los datos se distribuyen equitativamente entre dos o más discos duros sin añadir ningún tipo de datos de paridad. Por tanto, este sistema no es redundante y simplemente aporta una mejora de rendimiento. El tamaño del disco virtual resultante de un RAID 0 es: size_raid0 = N min(size_disk a, size_disk b,..., size_disk n ) RAID 1: se crea una copia exacta, espejo, de los datos almacenados en dos o más discos duros. El hecho de que los datos estén replicados aumenta la disponibilidad y la tolerancia a fallos del sistema de almacenamiento. Además, al estar los datos replicados en varios discos, el rendimiento de lectura se ve incrementado. El tamaño del disco duro virtual resultante de un RAID 1 es el del más pequeño de sus discos. RAID 5: en este nivel se dividen los datos a nivel de bloques distribuyendo la información de paridad entre todos los discos del conjunto. Es necesario un soporte hardware para el cálculo de la paridad. Como mínimo, se necesitan tres discos duros. De esta forma, puede fallar un disco y la información se podría reconstruir a partir de los datos restantes y la información de paridad.

174 174 PHP: PHP es un lenguaje de programación interpretado, diseñado para la creación de páginas web dinámicas, manteniendo la compatibilidad con el estándar HTML. El proceso de interpretación de PHP es el siguiente: 1. El cliente realiza una petición al servidor para que le envíe una página web. 2. El servidor ejecuta el intérprete de PHP, procesando la página solicitada que generará el contenido de forma dinámica. 3. El resultado es enviado por el intérprete al servidor, y éste, a su vez, envía la respuesta al cliente. Tiene una serie de ventajas asociadas que han hecho que su uso sea muy extendido: es un lenguaje multiplataforma, orientado a la web, posee la capacidad de conexión con SGBD, soporte para módulos, gran documentación y una licencia de distribución libre. Ping: utilidad que diagnostica el estado de una conexión entre dos dispositivos conectados a una red. Mediante esta herramienta se puede examinar el estado, la velocidad y la calidad de una red. RAID: el acrónimo RAID hace referencia a Redundant Array of Inexpensive Disks. Es básicamente un sistema de almacenamiento que utiliza varios discos duros para distribuir o replicar los datos. Existen diferentes conguraciones de RAID, que se denominan niveles. Según el nivel elegido se conseguirá un aumento de rendimiento, mayor integridad, mayor capacidad o mayor redundancia. SAN: una Storage Area Network o red de área de almacenamiento es una red diseñada para conectar servidores, matrices de discos duros y librerías que ofrecerán soporte. Las tecnologías que hacen posible esta red es bre channel e iscsi. Se distingue de otros métodos de almacenamiento en red (como podria ser un sistema de cheros distribuido) por el modo de acceso a bajo nivel, muy similar al de discos duros (S)ATA/SCSI, basado en bloques. En una SAN no se accede a discos duros concretos, sino que se accede a LUNs. TCP/IP: Internet está basado en un conjunto de protocolos de red. Los dos protocolos más importantes son el Transmission Control Protocol o protocolo de control de transmisión (TCP) y el Internet Protocol o protocolo de internet (IP). El procolo TCP asegura que los datos serán

175 A. Glosario 175 entregados a su destino sin errores y en el mismo orden en que fueron transmitidos. También introduce el concepto de 'puerto', utilizado para poder distinguir las comunicaciones de distintas aplicaciones. El protocolo IP proporciona un servicio de transmisión de datos no able. La información se envía en bloques denominados 'paquetes'. En estos paquetes aparecen las direcciones IP de cada una de las máquinas, origen y destino, de forma que los dispositivos de red sepan encaminar la información correctamente. Tiempo de seek: es el tiempo que tarda el disco duro en posicionar el cabezal en el cilindro correspondiente. Los fabricantes suelen proporcionar el tiempo medio de seek como una característica de rendimiento del disco duro. TLB: es una memoria caché que contiene partes de la tabla de paginación del sistema operativo. Es decir, contiene las relaciones entre direcciones de memoria virtuales y reales. Cuando se busca una dirección de memoria, primero se busca en la TLB y, si no se encuentra, se busca en la tabla de paginación del sistema operativo. URL: Uniform Resource Locator. Es una secuencia de caracteres, de acuerdo a un formato estándar, que se usa para nombrar recursos, como documentos o imágenes, en Internet para su localización. El formato general de una URL es: esquema://servidor/directorio/fichero. Fuente: Wikipedia.

176

177 Apéndice B Ldirectord. Instalación y conguración En este apéndice se explicará, de forma introductoria, cómo congurar un servidor para que se encargue, mediante el uso de software, de balancear el tráco web entre varios nodos. El objetivo es balancear el tráco, repartiendo la carga que recibe cada uno de los servidores web. Tal y como se ha comentado en los capítulos anteriores, mediante esta técnica podemos obtener un mejor tiempo de respuesta, una menor carga sobre los servidores y una redundancia del servicio web. Sin embargo, existe un único punto de fallo, el balanceador de tráco en sí. Si este, por algún motivo cae, el servicio web deja de ser accesible, por muchos nodos web redundantes que se posean. Por este motivo se optó por dedicar dos servidores a balanceo de tráco. Uno de ellos realizará las funciones de maestro mientras que el otro, esclavo, se quedará inactivo a menos de que exista algún problema con el principal. B.1. Información previa Para la realización de este apéndice se cuenta con cuatro servidores con sistema operativo Debian GNU/Linux instalado y congurado. Dos de estos servidores estarán dedicados a balancear el tráco hacia los otros dos servidores web. Los dos servidores que realizarán funciones de balanceo de tráco se denominan slb1 y slb2, con IPs y Los otros dos servidores dedicados a servicios web se denominan swmdl1 y swmdl2. A estos servidores les corresponden, respectivamente, las IPs y Además, hará falta una quinta IP, , que compartirán los dos balanceadores de tráco. 177

178 178 B.2. Paquetes necesarios y conguración previa Esta quinta IP, , será la IP pública de nuestro servicio, a través de la cual los clientes realizarán peticiones. Estas serán atendidas por el balanceador maestro y serán redirigidas, de forma balanceada, hacia los dos servidores web. B.2. Paquetes necesarios y conguración previa El primer caso es instalar los paquetes necesarios en los dos servidores que se dedicarán a balancear el tráco hacia los dos servidores web. Los paquetes que se deben instalar son los siguientes: heartbeat ldirectord ipvsadm Al tratarse de servidores con la distribución Debian de GNU/Linux, la instalación se realizó de forma muy sencilla, mediante la ejecución, en slb1 y slb2, del siguiente comando: # apt get i n s t a l l ipvsadm l d i r e c t o r d heartbeat En ambos servidores se deben cargar una serie de módulos. Para cargar dichos módulos y congurar el servidor de forma que se carguen automáticamente al arrancar, se creó y ejecutó el siguiente script: #!/ bin / bash echo ip_vs_dh >> / e t c / modules echo ip_vs_ftp >> / e t c / modules echo ip_vs >> / e t c / modules echo ip_vs_lblc >> / e t c / modules echo ip_vs_lblcr >> / e t c / modules echo ip_vs_lc >> / e t c / modules echo ip_vs_nq >> / e t c / modules echo ip_vs_rr >> / e t c / modules echo ip_vs_sed >> / e t c / modules echo ip_vs_sh >> / e t c / modules echo ip_vs_wlc >> / e t c / modules echo ip_vs_wrr >> / e t c / modules

179 B. Ldirectord. Instalación y conguración 179 modprobe ip_vs_dh modprobe ip_ vs_ ftp modprobe ip_vs modprobe ip_vs_lblc modprobe ip_vs_lblcr modprobe ip_ vs_ lc modprobe ip_vs_nq modprobe ip_vs_rr modprobe ip_vs_sed modprobe ip_vs_sh modprobe ip_vs_wlc modprobe ip_vs_wrr Como los servidores encargados del balanceo de tráco deben redireccionar el tráco, se debe habilitar el packet forwarding del sistema operativo. Para ello, se debe editar el chero /etc/sysctl.conf : net. ipv4. ip_forward = 1 Y posteriormente, para aplicar los cambios, se debe ejecutar: # s y s c t l p B.3. Conguración de heartbeat El siguiente paso es congurar heartbeat. La conguración está dividida en tres cheros. Estos cheros, en caso de no existir tras la instalación, se deben crear. Los cheros de conguración son: /etc/ha.d/ha.cf : este es el chero principal de conguración de heartbeat. En él se denen los nodos que se deben monitorizar o a través de qué interfaz de red debe realizar las comprobaciones, entre otros. /etc/ha.d/haresources: en este chero se indican las acciones que se deben llevar a cabo si se detecta que el otro servidor monitorizado por heartbeat está caído. En este caso, se debe congurar la IP pública, , y se debe iniciar el software, ldirectord, encargado del balanceo de tráco.

180 180 B.3. Conguración de heartbeat /etc/ha.d/authkeys: este chero garantiza que se estén monitorizando los servidores correctos. El contenido de este chero es una ristra de caracteres codicados en MD5 de forma que deba ser exáctamente igual en slb1 y slb2. El contenido del primer chero de conguración, /etc/ha.d/ha.cf, para el servidor slb1 es: l o g f a c i l i t y l o c a l 0 l o g f i l e / var / l o g /ha l o g auto_failback o f f a u t o j o i n none deadping 10 deadtime 10 debug 1 d e b u g f i l e / var / l o g /ha debug node s l b 1 s l b 2 respawn h a c l u s t e r / usr / l i b / heartbeat / i p f a i l ucast eth apiauth i p f a i l gid=h a c l i e n t uid=h a c l u s t e r Como se puede observar, en él se declaran los nodos que se monitorizan entre sí, slb1 y slb2, y la IP del otro nodo a monitorizar, en este caso Este chero de conguración en el servidor slb2 es exáctamente igual, modicando la linea de la dirección IP del otro servidor: ucast eth El segundo chero de conguración, /etc/ha.d/haresources, es común a ambos servidores dedicados a balancear tráco. Su contenido es el siguiente: s l b 1 \ l d i r e c t o r d : : l d i r e c t o r d. c f \ IPaddr2 : : / 2 3 / eth0 / La primera linea hace referencia a cual es el servidor maestro por defecto. En la segunda linea se dene el servicio de balanceo de tráco que se debe iniciar cada vez que el servidor sea considerado como maestro. La tercera linea realiza un cambio de IP sobre la interfaz de red eth0 y la congura con la IP , con una máscara de red de 23 bits y una dirección de broadcast De esta forma, si el servidor maestro slb1 cae, el servidor secundario slb2 se cambiaría la IP e iniciará el servicio ldirectord,

181 B. Ldirectord. Instalación y conguración 181 leyendo la conguración del chero ldirectod.cf, el cual se comentará más adelante. El chero /etc/ha.d/authkeys tan sólo contiene un hash md5 generado aleatoriamente. Para la generación del hash md5 se utilizó un chero cualquiera, como /proc/cpuinfo: # md5sum / proc / c p u i n f o e354641ea20a362dcebdc63 / proc / c p u i n f o El contenido para ambos servidores del chero /etc/ha.d/authkeys será el siguiente: auth 3 3 md e354641ea20a362dcebdc63 Por último, se debe comprobar que el servicio heartbeat será arrancado automáticamente al iniciarse el servidor: # update rc. d heartbeat s t a r t stop B.4. Conguración de ldirectord La conguración de ldirectord se dene en el chero /etc/ha.d/ldirectord.cf. Esta conguración será exáctamente igual en los dos servidores dedicados a balanceo de tráco, slb1 y slb2. El contenido de este chero es el siguiente: checktimeout=10 c h e c k i n t e r v a l=2 a u t o r e l o a d=no l o g f i l e =" l o c a l 0 " q u i e s c e n t=yes v i r t u a l = : 8 0 r e a l = : 8 0 r e a l = : 8 0 gate gate gate f a l l b a c k = : 8 0 s e r v i c e=http r e q u e s t="sbl check. html" r e c e i v e ="SBL CHECK OK" s c h e d u l e r=r r p r o t o c o l=tcp checktype=n e g o t i a t e

182 182 B.4. Conguración de ldirectord Como se puede observar, se le indica al balanceador qué dos servidores, y , debe balancear y en qué puertos. También se indica desde qué IP recibirá las conexiones que debe balancear, en este caso, Por último, en caso de que las conexiones al puerto 80 de swmdl1 y swmdl2 fallen, mostrará una página web alojada en el propio servidor, El balanceador comprobará el estado de los servidores web, swmdl1 y swmdl2, conectándose a ellos al puerto 80 y obteniendo el chero sbl-check.html por HTTP. Si el contenido de dicho chero es la cadena de caracteres SBL CHECK OK el servidor se considera como activo. En este caso, se ha congurado el balanceo siguiendo una distribución round robin. ldirectord soporta distintos métodos de planicación para balancear el tráco: Round Robin (rr): distribución equitativa entre los servidores disponibles. Weighted Round Robin (wrr): asigna las peticiones a los servidores web según un peso asignado previamente. Los servidores con mayor peso reciben nuevas peticiones antes y, por tanto, procesan más peticiones que los servidores con menor peso. A igualdad de peso, la distribución se realiza de forma equitativa. Least Connection (lc): el balanceador envía las nuevas peticiones a los servidores con el menor número de peticiones activas. Weighted Least Connection (wlc): asigna más peticiones a los servidores con menores peticiones activas en función del peso especíco de dicho servidor (Ci/Wi). Locality-Based Least-Connection (lblc): asigna las peticiones provenientes de la misma IP al mismo servidor siempre y cuando el servidor esté disponible y no esté sobre cargado. En caso contrario, asigna la petición al servidor cuya carga sea menor. Locality-Based Least-Connection with Replication (lblcr): asigna las peticiones provenientes de la misma IP a un grupo de servidores. Si todos los servidores del grupo están sobre cargados, asigna otro servidor, con poca carga, al grupo. En caso de que el grupo de servidores no se haya modicado en un tiempo, el servidor de ese grupo con la máxima carga es eliminado del grupo.

183 B. Ldirectord. Instalación y conguración 183 Destination Hashing (dh): asigna las peticiones mirando una tabla de hash asignada estáticamente según la IP de destino. Source Hashing (sh): asigna las peticiones mirando una tabla de hash asignada estáticamente según la IP de origen de la petición. Shortest Expected Delay (sed): las nuevas peticiones se asignan al servidor cuya respuesta sea la más rápida esperada. El tiempo que tardará un servidor en dar una respuesta se mide mediante la siguiente ecuación: C i + 1 U i C i es el número de peticiones activas que está procesando el servidor i y U i es el peso especíco de dicho servidor. Never Queue (nq): las nuevas peticiones se asignan a un servidor que no esté procesando ninguna petición, en vez de esperar por uno con un peso mayor. En caso de que ningún servidor esté ocioso se aplica la política sed. Una vez congurado ldirectord, se debe comprobar que no se ejecute al iniciarse el servidor, ya que el arranque y parada del servicio lo realizará heartbeat. Por tanto: # update rc. d f l d i r e c t o r d remove B.4.1. Comprobaciones De los dos servidores encargados de balancear tráco entre los servidores web, siempre uno de los dos tendrá dos IPs conguradas, la suya propia y la del servicio. En un principio, ese balanceador debe ser slb1. Si ocurre algún problema con slb1, entonces será slb2 el que congure la segunda IP y pase a balancear el tráco hacia los servidores web. Se puede comprobar que en los servidores encargados del balanceo de tráco están bien conguradas las IPs: s l b 1# ip add sh eth0 2 : eth0 : <BROADCAST,MULTICAST,UP,10000 > mtu 1500 q d i s c p f i f o _ f a s t qlen 1000 l i n k / e t h e r 0 0 : 0 6 : 2 9 : 3 9 : b5 : 3 e brd f f : f f : f f : f f : f f : f f i n e t / 2 3 brd scope g l o b a l eth0

184 184 B.4. Conguración de ldirectord i n e t / 2 3 brd scope g l o b a l secondary eth0 i n e t 6 f e 8 0 : : : 2 9 f f : f e 3 9 : b53e /64 scope l i n k v a l i d _ l f t f o r e v e r p r e f e r r e d _ l f t f o r e v e r s l b 2# ip add sh eth0 2 : eth0 : <BROADCAST,MULTICAST,UP,10000 > mtu 1500 q d i s c p f i f o _ f a s t qlen 1000 l i n k / e t h e r 0 0 : 0 6 : 2 9 : 3 9 : a9 : 4 7 brd f f : f f : f f : f f : f f : f f i n e t / 2 3 brd scope g l o b a l eth0 i n e t 6 f e 8 0 : : : 2 9 f f : f e 3 9 : a947 /64 scope l i n k v a l i d _ l f t f o r e v e r p r e f e r r e d _ l f t f o r e v e r Tal y como se ha congurado heartbeat, sólo debería estar activo ldirectord en el balanceador de tráco maestro. s l b 1# / e t c /ha. d/ r e s o u r c e. d/lvssyncdaemonswap master master running ( ipvs_syncmaster pid : 2640) s l b 2# / e t c /ha. d/ r e s o u r c e. d/lvssyncdaemonswap master master stopped s t a t u s s t a t u s Tal y como se puede apreciar, el maestro es el servidor slb1. Se puede comprobar que en dicho servidor se está ejecutando ldirectord: s l b 1# l d i r e c t o r d l d i r e c t o r d. c f s t a t u s l d i r e c t o r d f o r / e t c /ha. d/ l d i r e c t o r d. c f i s running with pid : 2501 s l b 2# l d i r e c t o r d l d i r e c t o r d. c f s t a t u s l d i r e c t o r d i s stopped f o r / e t c /ha. d/ l d i r e c t o r d. c f Además, se puede comprobar el balanceo de tráco que se está realizando: hacia qué IPs, puertos, política de balanceo, entre otros. s l b 1# ipvsadm L n IP V i r t u a l Server v e r s i o n ( s i z e =4096) Prot LocalAddress : Port Scheduler Flags > RemoteAddress : Port Forward Weight ActiveConn InActConn TCP : 8 0 r r > : 8 0 Route > : 8 0 Route s l b 2# ipvsadm L n

185 B. Ldirectord. Instalación y conguración 185 IP V i r t u a l Server v e r s i o n ( s i z e =4096) Prot LocalAddress : Port Scheduler Flags > RemoteAddress : Port Forward Weight ActiveConn InActConn B.5. Conguración de los servidores web El primer paso es instalar el paquete iproute en ambos servidores web, swmdl1 y swmdl2 : # apt get i n s t a l l i p r o u t e Además, se deben modicar ciertos parámetros del sistema operativo para evitar comportamientos indeseados con las tablas ARP entre los balanceadores de tráco y los servidores web. Para ello, es necesario editar el chero /etc/sysctl.conf en ambos servidores web y añadir las siguientes lineas: net. ipv4. conf. a l l. arp_ignore = 1 net. ipv4. conf. eth0. arp_ignore = 1 net. ipv4. conf. a l l. arp_announce = 2 net. ipv4. conf. eth0. arp_announce = 2 Para aplicar la nueva conguración, se debe ejecutar: # s y s c t l p El comportamiento indeseado con las tablas ARP viene provocado por la necesidad de añadir un alias a la interfaz de loopback. Este alias es la dirección IP virtual que se comparte entre los balanceadores de carga. Para añadir el alias debemos editar el chero /etc/network/interfaces y añadir: auto l o : 0 i f a c e l o : 0 i n e t s t a t i c address netmask pre up s y s c t l p > /dev/ n u l l

186 186 B.5. Conguración de los servidores web Posteriormente, se debe activar el alias de la interfaz: # i f u p l o : 0 El último punto a congurar es la creación del chero sbl-check.html para que los balanceadores de tráco puedan comprobar el estado de los servidores web. Tal y como se detalló en la Sección A.4 el contenido debe ser el siguiente: SBL CHECK OK

187 Apéndice C OCFS2. Instalación y conguración En este apéndice se detallará el proceso de instalación y conguración de OCFS2, un sistema de cheros de disco compartido. C.1. Información previa Para la realización de este apéndice se cuenta inicialmente con dos nodos con GNU/Linux instalado y congurado. Además, los nodos tendrán visible el mismo disco duro, /dev/sdc, a través de la SAN. Los nodos se denominan swmdl1 y swmdl2. Les corresponden, respectivamente, las IPs y C.2. Paquetes necesarios El primer paso es instalar los paquetes necesarios. Este paso depende totalmente de la distribución GNU/Linux que se utilice. En el entorno de este proyecto se trata de una SuSE Linux Enterprise Server[54] versión 11. Los paquetes que se deben instalar son los siguientes: ocfs2-tools ocfs2-tools-o2cb ocfs2console Para la instalación de estos paquetes fue necesario instalar la extensión SuSE Linux Enterprise High Availability Extension[55]. La instalación de 187

188 188 C.3. Denición del clúster los paquetes se realizó a través del módulo de gestión de paquetes de Yet Another Setup Tool v.2 (YaST2). Al realizar la instalación a través de YaST2 se instalan automáticamente todas las depencias necesarias. Es posible, dependiendo de la distribución, que se deba actualizar el kernel o núcleo para poder tener soporte de OCFS2. A partir de la versión del núcleo de Linux se integra OCFS2. C.3. Denición del clúster Una vez instalado lo necesario para OCFS2 se debe pasar a la conguración del clúster. Para ello, se ejecuta en cada uno de los nodos que formen parte del clúster: # / e t c / i n i t. d/ o2cb c o n f i g u r e Para la conguración, un asistente irá solicitando información. # / e t c / i n i t. d/ o2cb c o n f i g u r e Load O2CV d r i v e r on boot ( y/n ) [ y ] : y C l u s t e r stack backing O2CB [ o2cb ] : o2cb C l u s t e r to s t a r t on boot ( Enter "none" to c l e a r ) [ o c f s 2 ] : o c f s 2 S p e c i f y heartbeat dead t h r e s h o l d (>=7) [ 3 1 ] : S p e c i f y network i d l e timeout in ms (>=5000) [ ] : S p e c i f y network k e e p a l i v e delay in ms (>=1000) [ ] : S p e c i f y network reconnect delay in ms (>=2000) [ ] : Writing O2CB c o n f i g u r a t i o n : OK # / e t c / i n i t. d/ o2cb enable Debido a que aún no se ha denido el clúster identicado por ocfs2, dará una alerta. Por ello, se deben congurar los miembros del clúster ocfs2. De momento, estos pasos de conguración del clúster sólo se realizan en uno de los servidores. Posteriormente, se propaga la conguración a los otros nodos. Para congurar el clúster, existen dos opciones. La primera de ellas, si se cuenta con intercie gráca, es ejecutar: # o c f s 2 c o n s o l e Este comando lanza una aplicación gráca a través de la cual se pueden congurar los nodos del clúster. Para ello, se debe acceder al menú Cluster y seguidamente seleccionar Congure Nodes... Aparecerá una ventana con

189 C. OCFS2. Instalación y conguración 189 el listado de nodos congurados (inicialmente ninguno) y las opciones para añadir uno nuevo. Seleccionando la opción de Add se solicitan una serie de datos. El primero es el nombre del nodo, a través del cual se le identica. El segundo dato es la dirección IP. Por último se selecciona el puerto a través del cual se comunican los distintos nodos, por defecto Como de momento sólo se realiza la conguración en un único nodo, se proporciona la información necesaria únicamente para dicho nodo: Name : swmdl1 IP Address : Port : 7777 También se puede optar por congurar manualmente el clúster editando el chero de conguración /etc/ocfs2/cluster.conf. Siguiendo con la información proporcionada anteriormente, el contenido del chero debe ser el siguiente: node : ip_ port = 7777 ip_address = number = 0 name = swmdl1 c l u s t e r = o c f s 2 c l u s t e r : node_count = 1 name = o c f s 2 Como se puede observar, en este chero de conguración se indica el nombre del clúster (ocfs2 ), el número de nodos que forman parte del clúster (1) y los datos del nodo. Para comprobar que el clúster está activo, se ejecuta: # / e t c / i n i t. d/ o2cb enable C l u s t e r o c f s 2 a l r e a d y o n l i n e C.4. Formatear una partición Para formatear una partición se utiliza el comando mkfs.ocfs2 o bien, grácamente, mediante ocfs2console. Existen una serie de parámetros a con-

190 190 C.5. Propagar la conguración gurar a la hora de formatear una partición con OCFS2. Estos parámetros se pueden congurar tanto si se usa mkfs.ocfs2 como ocfs2console. Los parámetros son: Block size: se puede establecer el tamaño de bloque a 512, 1K, 2K o 4K bytes por bloque. En nuestro caso, hemos seleccionado un tamaño de bloque de 4K. Cluster size: se debe elegir entre 4K, 8K, 16K, 32K, 64K, 128K, 256K, 512K y 1M. Se eligió 32K como tamaño de los clúster. Label: es la etiqueta de la partición. Únicamente será usada si se quiere montar el sistema de cheros a través de ella. El valor que se le ha dado es de moodledata. Node slots: Es el número máximo de nodos que pueden, concurrentemente, montar la partición. El valor debe estar comprendido entre 1 y 255, por defecto son 8. En este proyecto contamos con dos servidores web, por lo que se ha denido su valor a 2. El número máximo de nodos se puede congurar de nuevo, bien incrementandolo, bien decremendandolo, mediante la aplicación tunefs.ocfs2. Teniendo en cuenta estos datos se puede formatear la partición /dev/sdc1 con mkfs.ocfs2 ejecutando el siguiente comando: # mkfs. o c f s 2 b 4K C 32K L moodledata N 2 /dev/ sdc1 C.5. Propagar la conguración En este apartado conguran los nodos restantes. En este caso, tan sólo se debe congurar un nodo más, swmdl2. En este punto, el nodo swmdl2 tiene los paquetes necesarios instalados y el O2DB congurado y habilitado. Para añadir este nodo al clúster, en swmdl1 se ejecuta de nuevo ocfs2console para añadir mediante el menú Congure Nodes... el segundo nodo con la información correspondiente: Name : swmdl2 IP Address : Port : 7777

191 C. OCFS2. Instalación y conguración 191 Figura C.1: Captura de pantalla de la conguración de los nodos de ocfs2console. Fuente: propia. Posteriormente en el menú Cluster se puede seleccionar Propagate Con- guration... para propagar la información al nodo swmdl2. Se solicitara la clave del usuario root para poder realizar la propagación. Si se realiza la conguración editando el chero /etc/ocfs2/cluster.conf, ambos nodos deben tener el mismo contenido: node : ip_ port = 7777 ip_address = number = 0 name = swmdl1 c l u s t e r = o c f s 2 node : ip_ port = 7777 ip_address = number = 1 name = swmdl2 c l u s t e r = o c f s 2 c l u s t e r : node_count = 2 name = o c f s 2

192 192 C.6. Comprobar los servicios C.6. Comprobar los servicios Para poder utilizar la partición en OCFS2 son necesarios dos servicios funcionando en el sistema, o2cb y ocfs2. Se deben congurar de forma que se inicien automáticamente cuando se inicie el sistema operativo. # c h k c o n f i g o2cb on # c h k c o n f i g o c f s 2 on C.7. Estos comandos se deben ejecutar en ambos nodos, swmdl1 y swmdl2. Montar la partición En este punto, se cuenta con ambos nodos congurados y la partición formateada con OCFS2 como sistema de cheros. Lo único que falta es montar la partición para empezar a utilizarla. Para montar la partición en cada uno de los nodos se debe utilizar el comando mount: # mount /dev/ sdc1 /home/moodle/ dades t o c f s 2 También se puede montar la partición a través de entorno gráco utilizando la aplicación ocfs2console. Si se quiere montar la partición automáticamente durante el arranque del sistema operativo se debe editar el chero /etc/fstab y añadir la siguiente linea: /dev/ sdc1 /home/moodle/ dades o c f s 2 c o n s o l e rw, _netdev 0 0

193 C. OCFS2. Instalación y conguración 193 Figura C.2: Captura de pantalla de ocfs2console una vez formateada y montada la partición. Fuente: propia.