Título: Balanceo de Carga de Aplicaciones Web con Apache Web Server. Facultad: Ingeniería. Programa: Ingeniería de Sistemas y Computación

Transcripción

1 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 1 de 43 Título: Balanceo de Carga de Aplicaciones Web con Apache Web Server Facultad: Ingeniería Programa: Ingeniería de Sistemas y Computación Grupo de Investigación: Grupo de Investigación en Redes, Información y Distribución GRID. Armenia-Quindío, febrero 24 de 2014

2 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 2 de 43 CONTENIDO 1. FICHA RESUMEN RESUMEN DIVULGATIVO DE RESULTADOS INFORME CIENTÍFICO RESULTADOS DIRECTOS RESULTADOS INDIRECTOS LIMITANTES EN LA EJECUCIÓN DEL PROYECTO... 38

3 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 3 de FICHA RESUMEN Título: Balanceo de Carga de Aplicaciones Web con Apache Web Server. Código: 547 Grupo de Investigación: Grupo de Investigación en Redes, Información y Distribución GRID. Programa de Investigación: Línea de Investigación: Minería de datos Nombre de la unidad ejecutora: Programa Ingeniería de Sistemas y Computación Facultad: Ingeniería Entidad Cofinanciadora: Número del Contrato: Tipo de vinculación al proyecto Personal del Proyecto Dedicación (en horas semanales) Nombre (s) Investigador Principal 10 Christian Andrés Candela Uribe, MSc Coinvestigador 10 Carlos Eduardo Gómez Montoya, MSc Coinvestigador 10 Luis Eduardo Sepúlveda Rodríguez, MSc Jóvenes Investigadores Auxiliar de Investigación 5 Andrés Felipe Abril Romero Auxiliar de Investigación 5 David Palacio Vargas Asesor Estudiantes Lugar de Ejecución del Proyecto (Ciudad): Armenia, Quindío Duración Prevista del Proyecto (en meses): 18 Duración real del Proyecto (en meses): 24 Tipo de Proyecto: Investigación aplicada

4 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 4 de 43 Título: Balanceo de Carga de Aplicaciones Web con Apache Web Server. Código: 547 Modalidad: Cuantía intermedia grupos activos inscritos en Colciencias no Visibles Valor Solicitado a la Universidad del Quindío: $ Valor cofinanciación: $0 Valor Ejecutado: $ Valor Total del Proyecto: $ Descriptores / Palabras Claves: Balanceo de Carga, Apache, Apache Web Server, Aplicaciones Web.

5 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 5 de RESUMEN DIVULGATIVO DE RESULTADOS En los últimos años se ha presentado una marcada tendencia hacia el desarrollo de aplicaciones Web. Los requisitos no funcionales de este tipo de aplicaciones, tales como desempeño, seguridad, concurrencia, disponibilidad y escalabilidad, entre otros, no son triviales y cada uno de ellos debe ser afrontado por los equipos de desarrollo una y otra vez. Una de las estrategias usadas para soportar concurrencia, disponibilidad y escalabilidad y mejorar el desempeño en las aplicaciones Web es la aplicación del balanceo de carga. Esta estrategia permite compartir el trabajo entre varios dispositivos de cómputo. El balanceo de carga se puede lograr de varias formas, a través de equipos hardware especializados, o por software. Apache Web Server es el servidor Web más frecuentemente usado a nivel mundial y gracias a esto cuenta con un alto grado de madurez, rendimiento y estabilidad. Apache tiene soporte para interoperar con un sinnúmero de aplicaciones y la constante evolución de este servidor Web es un desafío permanente. Este trabajo tiene como objetivo estudiar las principales características de Apache en materia de balanceo de carga y analizar las principales ventajas que ofrece para establecer buenas prácticas que puedan adaptarse para soportar estrategias de concurrencia, disponibilidad y escalabilidad para mejorar el rendimiento en aplicaciones Web.

6 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 6 de INFORME CIENTÍFICO RESUMEN Las aplicaciones Web son soluciones software que usan un navegador de Internet para su presentación al usuario, permitiendo el acceso desde dispositivos conectados a un Internet. En los últimos años se ha presentado una marcada tendencia hacia el desarrollo de este tipo de aplicaciones. Las aplicaciones Web, como cualquier tipo de solución software, tienen requisitos funcionales que especifican su comportamiento y las funciones específicas que deben cumplir. De igual manera, tienen requisitos no funcionales que especifican ciertos atributos de calidad o restricciones en la forma como se realiza su operación, los cuales son complejos y comunes a muchas aplicaciones. Los requisitos no funcionales de este tipo de aplicaciones, tales como desempeño, seguridad, concurrencia, disponibilidad y escalabilidad, entre otros, no son triviales y cada uno de ellos debe ser afrontado por los equipos de desarrollo una y otra vez. Una de las estrategias usadas para dar enfrentar los cuellos de botella ocasionados por la alta concurrencia en las aplicaciones Web es el balanceo de carga. Esta estrategia permite distribuir el trabajo entre varios equipos de cómputo para mitigar el impacto en el rendimiento servidor Web cuando su capacidad se puede ver comprometida por la cantidad de solicitudes realizadas al mismo tiempo por parte de los usuarios. El balanceo de carga se puede lograr de varias formas, a través de equipos hardware especializados, o por software. Apache Web Server es el servidor Web más frecuentemente usado a nivel mundial y gracias a esto cuenta con un alto grado de madurez, rendimiento y estabilidad. Apache tiene soporte para interoperar con un sinnúmero de aplicaciones y la constante evolución de este servidor Web es un desafío permanente. El objetivo general del proyecto de investigación es estudiar las características de balanceo de carga de Apache Web Server y especificar un conjunto de buenas prácticas adaptadas para soportar estrategias de concurrencia, disponibilidad y escalabilidad en aplicaciones Web. Con el fin de alcanzar el objetivo, y para garantizar un proceso adecuado se eligió una metodología basada la Metodología de la Investigación Tecnológica propuesta por (Ríos, 1998) para su aplicación en proyectos de Tecnología Informática. La metodología empleada incluye cinco etapas: Estudios previos, Análisis del problema, Diseño de la solución, Implementación y Pruebas. El informe se compone de cuatro secciones: Introducción, Metodología, Resultados y Discusión, y Conclusiones. ABSTRACT Web applications are software solutions using an Internet browser for presentation to the user, allowing access from devices connected to the Internet. In recent years there has been a marked trend towards the development of such applications. Web applications, such as any type of software

7 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 7 de 43 solution, have functional requirements that specify their behavior and the specific functions to be fulfilled. Similarly, are non-functional requirements that specify certain quality attributes or restrictions in the way it conducts its operations, which are complex and common to many applications. Non-functional requirements of such applications, such as performance, security, concurrency, availability and scalability, among others, are not trivial and each must be addressed by the development teams again and again. One of the strategies used to give face bottlenecks caused by the high turnout in Web applications is load balancing. This strategy can distribute the work among several computers to mitigate impacts on Web server performance when capacity can be compromised by the number of requests made at the same time by the users. Load balancing can be achieved in several ways, through specialized hardware devices or by software. Apache Web Server is the most frequently used Web server in the world and because of this has a high degree of maturity, performance and stability. Apache has support to interoperate with a high number of applications and the constant evolution of this web server is an ongoing challenge. The main objective of the research project is to study the load balancing features of Apache Web Server and specify a set of best practices adapted to support concurrency strategies, availability and scalability in web applications. In order to achieve the objective, and to ensure due process we were chosen a methodology based on Methodology of Technological Research proposed by (Rios, 1998) for use in Information Technology projects. The methodology includes five stages: Previous studies, Problem Analysis, Solution Design, Implementation and Testing. This report consists of four sections: Introduction, Methodology, Results and Discussion, and Conclusions. I. INTRODUCCIÓN El protocolo de transferencia de hipertexto - HTTP es el componente central de la Web. Este protocolo de la capa de aplicación del modelo TCP/IP define la forma como los servidores Web atienden las solicitudes realizadas por los clientes Web (Kurose & Ross, 2010). El protocolo HTTP está definido en los RFC 1945 (Berners-Lee, 1996) y 2616 (Fielding, 1999). HTTP es implementado por dos tipos de programas: un programa cliente y un programa servidor. Los usuarios de la Web hacen sus solicitudes a través de programas cliente HTTP, más comúnmente conocidos como navegadores de Internet tales como Mozilla Firefox (Mozilla, 2011) e Internet Explorer (Microsoft, 2011). Para dar respuesta a las peticiones de los navegadores de Internet se encuentran los servidores Web o servidores HTTP, entre los que se destacan Apache Web Server (Apache, 2011) e Internet Information Server (Microsoft, 2011). El programa cliente y el programa servidor típicamente son ejecutados en diferentes hosts y se comunican entre sí mediante el intercambio de mensajes HTTP. Un mensaje de solicitud es enviado por un navegador de Internet para indicarle al servidor que desea obtener un archivo determinado. Típicamente el servidor HTTP envía un mensaje de respuesta con el archivo solicitado al cliente. El protocolo HTTP define la

8 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 8 de 43 estructura de esos mensajes y la forma son intercambiados por el cliente y el servidor (Kurose & Ross, 2010). La Figura 1 muestra la forma como pueden interactuar el cliente y el servidor Web. Figura 1. Interacción entre cliente y servidor http Una página Web típicamente se compone de un archivo de texto escrito con marcas HTML en el cual se pueden encontrar referencias a otros archivos, tales como imágenes JPEG, applets de Java, o clips de video, entre otros. Cada archivo referenciado dentro de una página Web puede ser alcanzado mediante un URL (Kurose & Ross, 2010). Un URL (Uniform Resourse Locator Localizar Uniforme de Recursos) describe la ubicación específica de un archivo en un servidor Web particular, indicando de manera precisa y sin ambigüedad el nombre de host, el número de puerto y la ruta completa del archivo en ese servidor (Gourley, 2002). Por ejemplo, al observar el URL: se pueden destacar el nombre de host: grid.uniquindio.edu.co y la ruta del objeto en ese host /proyecto/informe.pdf (Gómez y Sepúlveda, 2010). Por su parte, un sitio Web es un conjunto de páginas Web que guardan algún tipo de relación y pueden ser accedidas a través de un punto de acceso común. Apache Web Server es el servidor HTTP con mayor participación en el mercado mundial según (Netcraft, 2013). Apache se caracteriza por ser estable, modular, tener código abierto y ser gratuito. Además es altamente configurable de acuerdo a las necesidades de la organización que lo utilice. Apache registra en archivos log toda la operación con el fin de hacer más fácil la tarea del administrador suministrando información útil para la toma de decisiones, por ejemplo, el ajuste en una directiva de configuración. Por otra parte, Apache ofrece módulos especializados en distintas actividades, por ejemplo integración con lenguajes de programación en el lado del cliente, módulos de seguridad y módulos de redirección. El uso de estos módulos puede ser aprovechado para dar un mejor servicio a sus usuarios sin comprometer a la organización que expone sus contenidos en una red pública como Internet para ser recuperados a través de solicitudes HTTP realizadas por un navegador. Apache se caracteriza también por ser multiplataforma, lo que permite su ejecución en la mayoría de sistemas operativos, tales como Unix, GNU/Linux y Windows (Soyinka, 2009).

9 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 9 de 43 Poner en operación adecuadamente un Servidor Web Apache para una organización requiere tener conocimiento y experiencia. Configurar Apache es una tarea relativamente trivial la cual consiste en editar un archivo de texto plano llamado httpd.conf. En este archivo se especifican las instrucciones que determinan su funcionamiento. Sin embargo, configuraciones avanzadas del servidor Apache puede llegar a ser un procedimiento bastante complejo (Gómez, Candela, Sepúlveda y Vila, 2012). Las aplicaciones Web son soluciones software que usan un navegador de Internet para su presentación al usuario, permitiendo el acceso desde dispositivos conectados a un Internet. Las aplicaciones Web son aplicaciones cliente servidor donde el programa cliente es el navegador de Internet a través del cual el usuario realiza sus solicitudes; mientras que el programa servidor corresponde a un servidor del protocolo HTTP que se encarga de atender las solicitudes, gestionar las transacciones y entregar las respuestas correspondientes a cada solicitud. Dado que el acceso a las aplicaciones Web se realiza a través de un navegador de Internet, es posible atender un número considerable de usuarios al mismo tiempo. Este tipo de aplicaciones no necesita de la presencia de algún programa cliente adicional, aunque en ocasiones hace falta instalar algunos complementos, por ejemplo el ambiente de ejecución de Java (Java, 2013), o el reproductor de animaciones Flash (Adobe, 2013). Esta característica de las aplicaciones Web permite la actualización y el mantenimiento de las aplicaciones evitando la distribución de las nuevas versiones a los usuarios, dando la sensación de tener siempre disponible la última versión. Las aplicaciones Web, como cualquier tipo de solución software, tienen requisitos funcionales que especifican su comportamiento y las funciones específicas que deben cumplir. De igual manera, tienen requisitos no funcionales que especifican ciertos atributos de calidad o restricciones en la forma como se realiza su operación, los cuales son complejos y comunes a muchas aplicaciones. Algunos de los requisitos no funcionales que deben ser tenidos en cuenta en el proceso de desarrollo de aplicaciones Web son la escalabilidad, la concurrencia, el desempeño, y la seguridad (Wiegers, 2003). La facilidad de acceso a este tipo de aplicaciones ha traído como consecuencia un aumento significativo en su popularidad, llevando a las aplicaciones Web a un uso extendido y ampliamente aceptado. El acceso concurrente de un número significativo de usuarios a una aplicación Web genera una gran carga operativa sobre el servidor. Esto ocasiona un rendimiento deficiente de la aplicación, llegando incluso a una denegación del servicio afectando la continuidad del negocio.

10 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 10 de 43 Una de las estrategias usadas para dar enfrentar los cuellos de botella ocasionados por la alta concurrencia en las aplicaciones Web es el balanceo de carga. Esta estrategia permite distribuir el trabajo entre varios equipos de cómputo para mitigar el impacto en el rendimiento servidor Web cuando su capacidad se puede ver comprometida por la cantidad de solicitudes realizadas al mismo tiempo por parte de los usuarios. Por ejemplo, si se tienen 1000 solicitudes que deben ser atendidas por un único servidor Web, al balancear la carga en cuatro servidores Web, cada uno tendría que atender 250 únicamente, reduciendo la carga en cada servidor y disminuyendo significativamente la probabilidad de una suspensión del servicio gracias al aumento en la disponibilidad. El balanceo de carga puede ser implementado tanto en hardware como en software. Una solución de balanceo de carga en hardware necesita de dispositivos especializados altamente costosos. Una solución de balanceo de carga también puede ser aplicada a sitios Web tradicionales que no necesariamente ofrezcan contenido dinámico a los usuarios, pero que se pueden ver afectados por la alta concurrencia si se trata de un sitio muy visitado. El objetivo general del proyecto de investigación es estudiar las características de balanceo de carga de Apache Web Server y especificar un conjunto de buenas prácticas adaptadas para soportar estrategias de concurrencia, disponibilidad y escalabilidad en aplicaciones Web. Los objetivos específicos son: identificar y analizar los componentes de balanceo de carga que ofrece Apache Web Server reconociendo los parámetros de configuración relevantes en materia de balanceo de carga; diseñar un escenario virtual para estudiar y analizar el comportamiento de Apache al realizar balanceo de carga; establecer un mecanismo de medición que permita comparar diferentes configuraciones de balanceo de carga sobre Apache; diseñar y ejecutar casos de prueba pertinentes para el objeto de estudio; y analizar los resultados para determinar las mejores configuraciones obtenidas a partir de las pruebas realizadas. Con el fin de alcanzar estos objetivos, y para garantizar un proceso adecuado se eligió una metodología basada la Metodología de la Investigación Tecnológica propuesta por (Ríos, 1998) para su aplicación en proyectos de Tecnología Informática. La metodología consiste en las siguientes cinco etapas: Estudios previos, Análisis del problema, Diseño de la solución, Implementación y Pruebas. El desarrollo del proyecto inició con los estudios previos, etapa en la que se identificó el problema objeto de estudio para dar continuidad a dos proyectos de investigación Análisis de configuraciones de servidores proxy caché y Seguridad en la configuración del servidor Web Apache, los cuales fueron realizados por el GRID en los años 2010 y 2012 respectivamente. Esta

11 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 11 de 43 etapa finalizó con la formulación el proyecto. Para el análisis del problema se identificaron y analizaron los servicios o componentes que brinda el servidor Apache en materia de balanceo de carga para su aplicación en escenarios sometidos a una cantidad significativa de solicitudes la cual puede poner en riesgo la continuidad en la operación de un servidor Web. El diseño de la solución fue realizado a partir de la adaptación de un modelo abstracto por capas especificado por el Grupo de Investigación en Redes, Información y Distribución de la Universidad del Quindío, en adelante GRID, que busca reducir la complejidad, ocultar detalles internos e independizar funciones y responsabilidades en cada capa. El modelo abstracto por capas ha sido aplicado en los proyectos de investigación ya mencionados, así como en cuatro trabajos de grado: Integración de sedes remotas de la Universidad del Quindío; Virtualización empresarial aplicada a la infraestructura de tecnología informática del GRID; Clúster de procesamiento para el GRID; y CloudGRID: Infraestructura como servicio para el GRID. Para validar el trabajo realizado se diseñó un escenario de aplicación concreto cuya arquitectura consiste en ofrecer los servicios de Moodle replicado en tres servidores de aplicación, un servidor Apache como balanceador de las solicitudes que pueden hacer los clientes. El diseño fue implementado en un entorno virtual controlado sobre un sistema de virtualización empresarial sobre Citrix Xen Server. En la etapa de pruebas se utilizó un marco de referencia estandarizado para su aplicación en desarrollo de software, adaptándolo para validar el trabajo realizado en el proyecto de investigación y obtener conclusiones. El resto del informe está organizado de la siguiente manera: la sección 2 describe la metodología utilizada para el desarrollo del proyecto de investigación; la sección 3 presenta la aplicación de la metodología y los resultados del trabajo; y el informe finaliza con las conclusiones en la sección 4. II. METODOLOGÍA La metodología empleada en el desarrollo del proyecto corresponde a una adaptación de la Metodología de la Investigación Tecnológica propuesta por (Ríos, 1998) para su aplicación en proyectos de Infraestructura de Tecnología Informática. Según (Ríos, 1998), la investigación tecnológica es el proceso que permite resolver un problema o satisfacer una necesidad a partir del diseño. Producto de la adaptación de esta metodología, se identificaron cinco etapas: Estudios previos, Análisis del problema, Diseño de la solución, Implementación y Pruebas. El proyecto inicia con los estudios previos. En esta etapa se identificó el problema objeto de estudio para dar continuidad a dos proyectos de investigación Análisis de configuraciones de servidores proxy caché y Seguridad en la configuración del servidor Web Apache, los cuales fueron realizados por el GRID en los años 2010 y 2012 respectivamente. Este tipo de proyectos enfocados en la adopción de la tecnología permiten adquirir conocimiento para impactar positivamente las

12 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 12 de 43 actividades misionales en el entorno universitario como son la docencia, la investigación y la proyección social. Posteriormente se realizó un levantamiento de información a partir de la revisión bibliográfica para obtener un contexto teórico, y un estado general del tema. Esta etapa finalizó con la formulación del proyecto. El análisis del problema consiste en entender la situación objeto de estudio. El análisis inició con la identificación de los elementos, componentes o servicios que ofrece Apache en materia de balanceo de carga para obtener las directivas o parámetros de configuración a usar en una arquitectura con balanceo de carga con el servidor Apache. Además, en esta etapa se determinaron las métricas a utilizar para comparar configuraciones de balanceo de carga sobre el servidor Apache. El diseño de la solución se refiere al planteamiento de alternativas que conduzcan a resolver el problema objeto de estudio. En esta ocasión se aplicó el modelo abstracto definido por el GRID, en forma descendente, para diseñar un ambiente virtual controlado y sobre él diseñar escenarios y casos de prueba. La implementación consiste en materializar el diseño realizado. Esta implementación se realizó teniendo en cuenta el modelo por capas aplicando virtualización empresarial, dado que dentro de la infraestructura tecnológica del GRID se encuentra disponible un servidor compatible con virtualización en hardware, también conocida como virtualización empresarial, modalidad de virtualización que ofrece un rendimiento muy positivo para la gestión de máquinas virtuales, especialmente servidores. La etapa de pruebas permite validar el trabajo realizado mediante la ejecución de los escenarios de prueba diseñados. En este proyecto se utilizó un marco de referencia estandarizado como metodología de trabajo, el cual consiste en la identificación de funciones ofrecidas por el servidor Apache en materia de balanceo de carga, el diseño de los casos de prueba, la ejecución de los casos de prueba y el análisis de resultados. Las pruebas fueron realizadas al prototipo desarrollado. A. MODELO ABSTRACTO El esquema de trabajo consiste en aplicar un modelo abstracto por capas especificado por el GRID para su aplicación en proyectos de infraestructura de tecnología informática adaptándolo a escenarios particulares. Este modelo, ilustrado en la Figura 2, busca reducir la complejidad, ocultar detalles internos e independizar funciones y responsabilidades en cada capa. El modelo abstracto por capas ha sido aplicado exitosamente en los proyectos de investigación y en los trabajos de grado ya mencionados.

13 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 13 de 43 Figura 2. Modelo abstracto por capas Este modelo es un referente conceptual en el cual se identifican las siguientes capas, de abajo hacia arriba: Capa de hardware; Capa de virtualización; Capa de máquinas y dispositivos virtuales; Capa de redes; y Capa de servicios. La capa de hardware comprende los elementos de infraestructura física que proporciona el hardware a las capas superiores. Está representado por uno o más equipos físicos, típicamente servidores con compatibilidad para la ejecución de virtualización en hardware, incluyendo sus especificaciones como son los procesadores, discos duros, unidades ópticas de almacenamiento, memoria RAM e interfaces de red. La capa de hardware se refiere también al equipo o equipos de cómputo utilizados para instalar el software de gestión de la infraestructura virtualizada. La capa de virtualización corresponde al hipervisor que se pone en ejecución sobre el servidor o servidores que se tienen dispuestos en la capa de hardware. El hipervisor es un sistema operativo liviano que permite exponer los recursos hardware disponibles en los equipos para que sean considerados un conjunto agregado de recursos para ser consumidos por máquinas virtuales en la capa de máquinas y dispositivos virtuales. Esta capa tiene un componente adicional que se encarga de la gestión del hipervisor. La capa de máquinas y dispositivos virtuales se encarga de ofrecer el entorno de trabajo necesario en forma de máquinas virtuales con sus respectivos sistemas operativos, además de switches virtuales que podrán ser utilizados para conformar la topología de red necesaria en un escenario de aplicación específico. Estos switches virtuales permitirán la comunicación entre las máquinas virtuales, así como conectividad hacia y desde redes externas según sea la necesidad de cada caso. La capa de redes se encarga de realizar la conexión física y lógica del entorno de trabajo conformando la topología de la red que conectará las máquinas y dispositivos virtuales definidos en la capa anterior para su aplicación en proyectos de infraestructura de tecnología informática.

14 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 14 de 43 La capa de servicios establece las aplicaciones de red que prestarán los servicios de acuerdo con el escenario específico que se desea poner en funcionamiento. Estos servicios se incluyen como parte del sistema operativo en ejecución en las distintas máquinas virtuales, dando lugar al prototipo del entorno informático para su funcionamiento y realización de pruebas necesarias en el proyecto de investigación. B. METODOLOGÍA PARA LAS PRUEBAS La etapa de pruebas de este proyecto fue realizada siguiendo una adaptación del estándar IEEE 829 (Aristegui, 2010). Este estándar define una metodología para la realización de casos de prueba en el desarrollo de software, aunque en este caso, ha sido adaptada para su aplicación en el área de infraestructura de TI. El plan de pruebas se realizó en cuatro fases: identificación de las funciones ofrecidas por Apache en materia de balanceo de carga; diseño de los casos de prueba; ejecución de los casos de prueba; y análisis de resultados. En la fase uno, se identificaron los módulos y directivas de configuración, las métricas a utilizar. En la fase dos, se diseñaron los casos de prueba considerando para cada uno de ellos: propósito o descripción de la prueba; método o conjunto de actividades a realizar; y resultado esperado luego de la aplicación del método. En la fase tres, se ejecutaron los casos de prueba diseñados; y en la fase cuatro, se realizó análisis comparativo de los resultados obtenidos con respecto a los resultados esperados. III. RESULTADOS Y DISCUSIÓN Después de realizar los estudios previos que condujeron a la formulación del proyecto y de acuerdo con la metodología utilizada, se procedió a la ejecución de las cuatro etapas restantes: Análisis del problema, Diseño de la solución, Implementación y Pruebas. A. Análisis del problema Balanceo de carga en Apache Como ya se ha mencionado, Apache es un servidor Web potente y flexible que fundamenta su flexibilidad en la posibilidad de ser ajustado de acuerdo con las necesidades del entorno donde va a ser puesto en servicio, lo que lo hace también muy eficiente (Apache, 2013). Apache se puede adaptar mediante su diseño modular, permitiendo al administrador del sistema elegir las

15 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 15 de 43 funcionalidades que serán incluidas en el servidor especificando los módulos que se desea utilizar cuando el servidor esté funcionando. Incluir únicamente los módulos estrictamente necesarios hará de Apache un sistema más liviano y menos expuesto a problemas de seguridad que puedan afectar el funcionamiento de Apache Web Server (Gómez, Candela, Sepúlveda y Vila 2012). Un servidor proxy es una herramienta de software ubicada cerca de los usuarios que actúa como intermediario a través del cual las solicitudes HTTP. Una aplicación ampliamente conocida de un servidor proxy es la aceleración del acceso a Internet en redes corporativas almacenando en caché archivos que hayan sido solicitados previamente. De este modo, un porcentaje de las solicitudes realizadas puede ser atendido en forma local evitando la salida a redes externas dando como resultado menores tiempos promedios de respuesta (Gómez y Sepúlveda, 2010). Un proxy inverso es ubicado en el lado del servidor para recibir de manera transparente las peticiones enviadas por los usuarios. Un proxy inverso puede ser utilizado para hacer controles de seguridad o para repartir las solicitudes de los usuarios entre varios servidores, balanceando la carga para mejorar las condiciones de disponibilidad y desempeño de un servicio basado en Web. En el proceso de configuración de un proxy inverso se utilizan distintos módulos que permiten configuraciones básicas y avanzadas. De acuerdo con (Abele, 2009) y (Apache 2013), Apache Web Server permite ofrecer soluciones de balanceo de carga con base en los módulos que se pueden apreciar en la Tabla 1. Tabla 1. Módulos de Apache para implementar Balanceo de Carga Módulo Función mod_proxy Módulo que implementa un intermediario para Apache. Las características de proxy de Apache se dividen en otros módulos relacionados como mod_proxy_http, mod_proxy_balancer. mod_proxy_http Es un módulo que proporciona las características necesarias para que Apache pueda atender solicitudes HTTP y HTTPS. Este módulo es un complemento de mod_proxy. mod_proxy_balancer Este módulo da soporte al balanceo de carga para el protocolo HTTP. Requiere el servicio de mod_proxy. mod_rewrite Módulo que ofrece un motor de reescritura de URLs al vuelo con base en un conjunto de reglas. mod_headers Es un módulo que proporciona directivas para controlar y modificar los encabezados de mensajes de solicitud y respuesta HTTP.

16 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 16 de 43 Las directivas de configuración que se pueden usar en la configuración de Apache dependen de los módulos que se han instalado y se han definido para que sean cargados al iniciar el servicio. Una directiva establece un parámetro de configuración con un valor asignado en el archivo de configuración de Apache. Una forma de configuración de proxy inverso consiste en indicar explícitamente cómo se debe redirigir una solicitud de manera transparente al usuario. De este modo, lo que puede verse como un directorio dentro del directorio raíz del servidor Web, en realidad puede ser un directorio de otro servidor Web, interno dentro de la arquitectura de un entorno específico. La directiva ProxyPass se utiliza para especificar la forma como se realiza la redirección. Este tipo de solución puede ser utilizado para realizar controles de seguridad en un equipo que esté de frente a Internet, evitando que solicitudes no autorizadas o sospechosas lleguen a los servidores que en realidad prestan un servicio particular. Para configurar el balanceo de carga en un proxy inverso, se debe especificar un conjunto de servidores dentro de un contenedor <Proxy> especificando valores adecuados para el atributo balancer y la directiva BalancerMember especificando en cada línea la dirección IP o el nombre, y el número de puerto de cada máquina que será utilizada para atender solicitudes. El parámetro lbmethod especifica el método utilizado para determinar la forma de redirigir las solicitudes, que puede ser por solicitudes (byrequests) o por tráfico (bytraffic). Algunas configuraciones avanzadas permiten a Apache redirigir solicitudes si un servidor particular se encuentra fuera de servicio, lo que contribuye notablemente en materia de disponibilidad. También se puede realizar una configuración que soporte sesiones abiertas mediante el parámetro stickysession, para dar manejo a peticiones que son continuación de otras para que sean enviadas al mismo servidor. En este caso, se puede afectar el balanceo de carga, pero se puede garantizar que un mismo servidor pueda realizar toda la atención a un cliente hasta terminar la sesión. Métricas Según (RAE, 2002), la definición de métrica se asocia al arte que trata de la medida o estructura de los versos, de sus clases y de las distintas combinaciones que con ellos pueden formarse ; sin embargo, esta palabra ha tomado otro significado en el ámbito tecnológico especialmente en la Ingeniería de Software, donde ha logrado redefinirse en un concepto de mayor alcance tal como lo expresa (AEMES, 2012) en su sitio Web, donde asegura lo siguiente: una métrica es cualquier medida o conjunto de medidas destinadas a conocer o estimar las características de un software o

17 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 17 de 43 sistema de información. Finalmente, y siguiendo esta línea conceptual, (Van Bon, 2010) considera que existen métricas de tecnología las cuales miden el rendimiento y la disponibilidad de componentes y aplicaciones. Basado en todo o anterior, el presente proyecto hace referencia a los conceptos de rendimiento, conexiones concurrentes y disponibilidad como las métricas a considerarse. Métricas de rendimiento (Bourke, 2001) asegura que existen muchos aspectos relacionados con el rendimiento donde se involucran diversos dispositivos que conforman los sistemas de balanceo de carga; por lo tanto, hay maneras diferentes de medir el rendimiento de estos los dispositivos, y cada indicador tiene un nivel diferente de importancia en función de las necesidades específicas de un sitio Web u otro. Algunos de los indicadores comúnmente utilizados son el tiempo de respuesta relacionado con la conexiones aceptadas por segundo y la productividad (throughput en inglés). El tiempo de respuesta es considerado en sistemas operativos como el tiempo transcurrido entre el comienzo y finalización de una tarea. También llamado tiempo de ejecución. Por otro lado, la productividad es considerada como la cantidad total de trabajo realizado en un tiempo determinado, siendo de gran importancia desde el punto de vista del sistema y no desde el punto de vista del usuario (Silberschatz, Galvin, & Gagne, 2012). Conexiones por segundo: Con relación al rendimiento puro, asegura (Bourke, 2001) las conexiones por segundo son probablemente el parámetro más importante, sobre todo con el protocolo HTTP. Este parámetro se relaciona con el número de conexiones entrantes que un sistema de balanceo de carga acepta en un segundo dado. Esto se refiere a las transacciones por segundo o sesiones por segundo, siendo este por lo general el factor limitante en cualquier sistema de balanceo de carga. Productividad: En el ámbito informático la productividad es típicamente medida en bits por segundo (bps) y según Bourke (2001) es también considerado como la velocidad a la que un sistema de balanceo de carga es capaz de pasar el tráfico a través de su infraestructura interna. Medición de la disponibilidad El concepto de disponibilidad en informática está relacionado con frase alta disponibilidad (High availability en inglés), el cual según UptimeInstitute (2010) consiste en el diseño de un sistema y su

18 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 18 de 43 implementación asegurando cierto grado de continuidad operacional durante un tiempo determinado. La disponibilidad se expresa como un porcentaje que relaciona la continuidad operacional durante un año. También se le conoce en inglés como Uptime y suele expresarse con un número determinado de nueves como lo muestra la Tabla 2. Tabla 2. Niveles de disponibilidad según UptimeInstitute Número de nueves Disponibilidad (uptime) Máximo tiempo de caída al año Seis nueves % 31.5 segundos Cinco nueves % 5 minutos 35 segundos Cuatro nueves % 52 minutos 33 segundos Tres nueves 99.9 % 8 horas 46 minutos Dos nueves 99.0 % 87 horas 36 minutos Un nueve 90.0 % 36 días 12 horas Actualmente, para valorar el nivel de disponibilidad de los centros de procesamiento de datos (Data Center en inglés), la norma más aceptada según lo expresa (López-Vázquez, 2012) es la ANSI-TIA- EIA 942 de En dicha norma se establecen cuatro niveles (Tier en inglés) iniciando en el nivel 1 (Tier I) siendo este el más sencillo, hasta el nivel 4 (Tier IV). La Tabla 3 presenta la relación de disponibilidad de acuerdo a los niveles establecidos en la norma ANSI-TIA-EIA 942 de 2005 (W. Pitt Turner IV, 2008) Tabla 3. Niveles de disponibilidad según ANSI-TIA-EIA 942 Nivel % Disponibilidad % parada Tiempo de parada al año (Tier) (Uptime) (Downtime) Tier I 99,671 % 0,329 % 28,82 horas Tier II 99,741 % 0,251 % 22,68 horas Tier III 99,982 % 0,018 % 1,57 horas Tier IV 99,995 % 0,005 % 52,56 minutos

19 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 19 de 43 Tabla 4. Características de los niveles de disponibilidad en centros de datos según ANSI-TIA-EIA 942 Nivel (Tier) Tier I Tier II Tier III Tier IV Características Nivel: Básico Disponibilidad máxima 99,671 % 28,82 horas de parada como máximo al año Admite interrupciones planeadas y no planeadas Nivel: Redundante Disponibilidad máxima 99,741 % 22,68 horas de parada como máximo al año Su diseño corresponde a N+1, lo que significa que contiene componentes redundantes de infraestructura siendo menos susceptible a interrupciones. Nivel: Concurrente Disponibilidad máxima 99,982 % 1,57 horas de parada como máximo al año Permiten realizar cualquier actividad planeada sobre cualquier componente de la infraestructura sin interrupciones en la operación, tales como: mantenimiento preventivo, reparaciones o reemplazo de componentes, realizar pruebas de sistemas o subsistemas, entre otros. Nivel: Tolerancia a fallos Disponibilidad máxima 99,995 % 52,56 minutos de parada como máximo al año Provee capacidad para realizar cualquier actividad planeada sin interrupciones en el servicio, pero además la funcionalidad tolerante a fallos le permite a la infraestructura continuar operando aún ante un evento crítico no planeado. Requiere dos líneas de distribución simultáneamente activas, típico en una configuración System+System. Cada System con un nivel de redundancia N+1. B. Diseño de la solución El diseño de la solución es un proceso que consiste en aplicar el modelo por capas mencionado en la metodología (sección II), para lo cual se inició por la capa de servicios, con el fin de obtener un prototipo para poner en funcionamiento el balanceo de carga sobre Apache Web Server. En este caso, el prototipo consiste en la implementación de una LSM (Learning System Manager) basado en Moodle (Moodle, 2013), el cual será tomado como aplicación Web a ser balanceada.

20 Código: M.IN F.02 Versión: 01 Fecha: 2010/08/18 Página 20 de 43 Moodle es una herramienta gratuita que los educadores pueden usar para crear un sitio de aprendizaje en línea (Moodle, 2013). Está desarrollado en lenguaje PHP y para usarla se requiere el montaje de un servidor Web, bien sea en un equipo propietario o en un servidor que ofrece el servicio de hosting. Dado que Moodle es una plataforma para de apoyo para la enseñanza a través de Internet, puede ser utilizado por un número significativo de usuarios lo que implica un flujo constante y elevado de solicitudes, fue diseñada para soportar el escalamiento. Moodle es ampliamente conocida a nivel mundial, según su página oficial, actualmente cuanta con más de 70 millones de usuarios, servidores independientes registrados oficialmente en 236 paises, de los cuales servidores están en Colombia (Moodle, 2013). Gracias a su diseño e incluso su amplio uso, Moodle se convirtió en un candidato para la realización de las pruebas de balanceo en este proyecto. Lo anterior teniendo en cuenta que el balanceo de carga de una aplicación Web no solo radica en la adecuada configuración del balanceador, también es indispensable que la aplicación haya sido diseñada para soportar el balanceo de carga. Por otro lado, Moodle es una aplicación Web robusta y probada en entornos de producción, lo que permite dar confianza en que los resultados de las pruebas no se verán afectados por problemas inherentes a la aplicación, además de tener la posibilidad de impactar la comunidad de usuarios de una herramienta tan ampliamente difundida. Para diseñar la arquitectura se aplicó el modelo abstracto por capas, en forma descendente, iniciando por la capa de servicios. La Figura 3 muestra la arquitectura del prototipo utilizado para el proyecto. Figura 3. Arquitectura del prototipo. A continuación se describe la funcionalidad considerada en cada una de las capas del modelo abstracto.