UNIVERSIDAD DE GUAYAQUIL

Transcripción

1 UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES DISEÑO Y DESARROLLO DE UN PROTOTIPO DE UN CLUSTER EN LINUX DE ALTA DISPONIBILIDAD PARA SATISFACER LA DEMANDA DE ACCESO WEB EN LA CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES Y EL BALANCEO DE CARGA DE LOS SERVICIOS TESIS DE GRADO Previa a la obtención del Título de: INGENIERO EN SISTEMAS COMPUTACIONALES CARLOS POLIVIO ZUMBA VÁSQUEZ TUTOR: ING. DAVID BENAVIDES GUAYAQUIL ECUADOR 2011

2 i Guayaquil, 28 de Agosto del 2011 APROBACIÓN DEL TUTOR En mi calidad de Tutor del trabajo de investigación, DISEÑO Y DESARROLLO DE UN PROTOTIPO DE UN CLUSTER EN LINUX DE ALTA DISPONIBILIDAD PARA SATISFACER LA DEMANDA DE ACCESO WEB EN LA CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES Y EL BALANCEO DE CARGA DE LOS SERVICIOS, elaborado por el Sr. CARLOS POLIVIO ZUMBA VÁSQUEZ, egresado de la Carrera de Ingeniería en Sistemas Computacionales, Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil, previo a la obtención del Título de Ingeniero en Sistemas, me permito declarar que luego de haber orientado, estudiado y revisado, la Apruebo en todas sus partes. Atentamente ING. DAVID BENAVIDES TUTOR

3 ii AGRADECIMIENTO Agradezco a Dios por brindarme la sabiduría en cada paso que di para culminar cada etapa de este proyecto A mis padres, la Sra. Delia Leonor Vásquez Vásquez y el Sr. Ángel Polibio Zumba Sinchi, por haberme formado con excelentes valores y principios, brindándome su aliento y apoyo incondicional para retomar mis estudios, permitiéndome así culminar esta gran etapa de mi vida.

4 iii TRIBUNAL DE GRADO DECANO DE LA FACULTAD CIENCIAS MATEMATICAS Y FISICAS DIRECTOR TUTOR PROFESOR DEL ÁREA - TRIBUNAL PROFESOR DEL ÁREA - TRIBUNAL SECRETARIO

5 iv UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES DISEÑO Y DESARROLLO DE UN PROTOTIPO DE UN CLUSTER EN LINUX DE ALTA DISPONIBILIDAD PARA SATISFACER LA DEMANDA DE ACCESO WEB EN LA CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES Y EL BALANCEO DE CARGA DE LOS SERVICIOS Proyecto de trabajo de grado que se presenta como requisito para optar por el título de INGENIERO en SISTEMAS COMPUTACIONALES Autor: Carlos Polivio Zumba Vásquez C.I Tutor: Ing. David Benavides Guayaquil, Agosto de 2011

6 v CERTIFICADO DE ACEPTACIÓN DEL TUTOR En mi calidad de Tutor del Primer Curso de Fin de Carrera, nombrado por el Departamento de Graduación y la Dirección de la Carrera de Ingeniería en Sistemas Computacionales de la Universidad de Guayaquil, CERTIFICO: Que he analizado el Proyecto de Grado presentado por el egresado CARLOS POLIVIO ZUMBA VÁSQUEZ, como requisito previo para optar por el título de Ingeniero cuyo problema es: DISEÑO Y DESARROLLO DE UN PROTOTIPO DE UN CLUSTER EN LINUX DE ALTA DISPONIBILIDAD PARA SATISFACER LA DEMANDA DE ACCESO WEB EN LA CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES Y EL BALANCEO DE CARGA DE LOS SERVICIOS considero aprobado el trabajo en su totalidad. Presentado por: Zumba Vásquez Carlos Polivio Cédula de ciudadanía N Tutor: Ing. David Benavides Guayaquil, Agosto de 2011

7 vi ÍNDICE GENERAL APROBACIÓN DEL TUTOR i AGRADECIMIENTO ii TRIBUNAL DE GRADO iii CERTIFICADO DE ACEPTACIÓN DEL TUTOR v ÍNDICE GENERAL vi ÍNDICE DE TABLAS xi ÍNDICE DE GRÁFICOS xii RESUMEN xiii ABSTRACT xiv INTRODUCCIÓN 1 CAPÍTULO I 4 EL PROBLEMA 4 PLANTEAMIENTO DEL PROBLEMA 4 UBICACIÓN DEL PROBLEMA EN UN CONTEXTO 4 SITUACIÓN CONFLICTO NUDOS CRÍTICOS 5 CAUSAS Y CONSECUENCIAS DEL PROBLEMA 7 Causas 7 Consecuencias 7 DELIMITACIÓN DEL PROBLEMA 8 FORMULACIÓN DEL PROBLEMA 9 EVALUACIÓN DEL PROBLEMA 10 OBJETIVOS DE LA INVESTIGACIÓN 12 OBJETIVO GENERAL 12 OBJETIVOS ESPECÍFICOS 12 ALCANCE 13 JUSTIFICACIÓN E IMPORTANCIA 15 UTILIDAD PRÁCTICA DE LA INVESTIGACIÓN 16

8 vii CUÁLES SERÁN LOS BENEFICIARIOS 16 CAPÍTULO II 17 MARCO TEÓRICO 17 ANTECEDENTES DEL ESTUDIO 17 FUNDAMENTACIÓN TEÓRICA 20 TECNOLOGÍAS PARALELAS 20 CLASIFICACIÓN 21 SISD (Single Instruction stream, Single Data stream) 21 SIMD (Single Instruction Multiple Data) 22 MISD (Multiple Instruction Single Data) 23 MIMD (Multiple Instruction Multiple Data) 24 Single Program, Multiple Data (SPMD) 28 MultipleProgramMultiple Data (MPMD) 28 FUNDAMENTOS GENERALES DE LOS CLUSTERS 29 CONCEPTO 30 CARACTERISTICAS 30 ARQUITECTURA 32 COMPONENTES DE UN CLUSTER 32 Nodos 33 Sistemas Operativos 34 Conexiones de Red 35 Middleware 38 Entornos y herramientas de programación paralela 40 Aplicaciones 42 CLASIFICACIÓN 43 BALANCEO DE CARGA 43 ALTA DISPONIBILIDAD 44 ALTO RENDIMIENTO 46 ALTA CONFIABILIDAD 47 Cluster: Funcionamiento 47

9 viii Características y funcionamiento de alta disponibilidad 48 Sistemas de alta disponibilidad y sistemas tolerantes a fallos 48 SPOF (Single Point of Failure ó Punto Simple de Fallo) 49 Servicio de Datos 49 Dinámica de Alta Disponibilidad 50 Recursos de un Servicio de Datos 51 Balanceo de carga (Load balancing) 52 Balanceo de Carga por Sistema de Nombres de Dominio o DNS 52 Balanceo de Carga mediante un Nodo Director 53 Planificación del Balanceo de Carga 60 PLANIFICACIÓN Y ADMINISTRACIÓN DE CLUSTERS 63 ADMINISTRACIÓN 63 Registro de eventos (logging) 64 Falla y Recuperación de Hardware 64 Falla de Software 65 Falla y Recuperación del Sistema de archivos 65 Encolamiento (Queing) 66 Monitoreo (Monitoring) 67 Contabilidad (Accounting) 67 PLANIFICACIÓN DE TAREAS 68 HERRAMIENTAS PARA IMPLEMENTAR CLUSTERS DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA 69 HA OSCAR 69 Introducción a HA OSCAR 69 Arquitectura de HA-OSCAR 69 LVS (LINUX VIRTUAL SERVER) 73 Introducción a LVS 73 Mecanismos de Balanceo de Carga 74 Balanceo por NAT 74 Balanceo por Encapsulado IP 77

10 ix Balanceo por enrutamiento directo 80 Planificación del algoritmo de balanceo de carga 83 RoundRobin 83 Round Robin Ponderado 83 Servidor con menos conexiones activas 84 Servidor con menos conexiones activas (ponderado) 84 Menos conectado basado en servicio 85 Tablas hash por origen y destino 85 Conexiones persistentes 86 Alta Disponibilidad en LVS 86 Heartbeat 86 Ldirectord+Heartbeat 90 ldirectord (Linux Director Daemon) 91 Ipvsadm 93 Piranha 94 UltraMonkey 96 HERRAMIENTAS PARA LA ADMINISTRACIÓN DE CLUSTERS 98 GANGLIA 98 WEBMIN 101 CONGA 103 FUNDAMENTACIÓN LEGAL 106 DECRETO EJECUTIVO No HIPÓTESIS PREGUNTAS A CONTESTARSE 108 VARIABLES DE LA INVESTIGACIÓN 108 DEFINICIONES CONCEPTUALES 109 CAPÍTULO III 113 METODOLOGÍA 113 DISEÑO DE LA INVESTIGACIÓN 113 MODALIDAD DE LA INVESTIGACIÓN 113 PROYECTO FACTIBLE 113

11 x POBLACIÓN Y MUESTRA 115 INTRODUCCION 115 POBLACIÓN 115 MUESTRA 116 INTRODUCCIÓN 116 TECNICA DEL MUESTREO 116 TAMAÑO DE LA MUESTRA 119 OPERACIONALIZACIÓN DE VARIABLES 120 MATRIZ DE OPERACIONALIZACIÓN DE VARIABLES 121 INSTRUMENTOS DE RECOLECCIÓN DE DATOS 122 PROCESAMIENTO DE LA INVESTIGACIÓN 122 RECOLECCIÓN DE LA INFORMACIÓN 123 INSTRUMENTOS DE LA INVESTIGACIÓN 123 LA ENCUESTA Y EL CUESTIONARIO 124 CONTENIDO 125 PROCESAMIENTO Y ANÁLISIS 128 CRITERIOS PARA LA ELABORACIÓN DE LA PROPUESTA 136 CRITERIOS DE VALIDACIÓN DE LA PROPUESTA 137 CAPÍTULO IV 138 MARCO ADMINISTRATIVO 138 CRONOGRAMA 138 PRESUPUESTO 139 CAPÍTULO V 140 CONCLUSIONES Y RECOMENDACIONES 140 CONCLUSIONES 140 RECOMENDACIONES 143 REFERENCIAS BIBLIOGRÁFICAS 144 LIBROS 144 PUBLICACIONES 145 DIRECCIONES WEB 145

12 xi ÍNDICE DE TABLAS Tabla 1: Cuadro Poblacional 116 Tabla 2: Cuadro Muestreo Estratificado 120 Tabla 3: Cuadro Operacional de Variables 121 Tabla 4: Cuadro te Tabulaciones de la Encuesta 128

13 xii ÍNDICE DE GRÁFICOS Gráfico 1: Arquitectura SISD 22 Gráfico 2: Arquitectura SIMD 23 Gráfico 3: Arquitectura MISD 24 Gráfico 4: Arquitectura MIMD 25 Gráfico 5: Arquitectura SMP 27 Gráfico 6: Arquitectura MPP 27 Gráfico 7: Arquitectura del Cluster 32 Gráfico 8: Estructura Balanceo de Carga a través de un Nodo Director 54 Gráfico 9: Balanceo por NAT 56 Gráfico 10: Balanceo por Encapsulamiento IP 57 Gráfico 11: Balanceo por Enrutamiento Directo 59 Gráfico 12: Arquitectura HA OSCAR 70 Gráfico 13: Mecanismo de Balanceo por NAT 75 Gráfico 14: Mecanismo de Balanceo por Encapsulamiento IP 78 Gráfico 15: Mecanismo de Balanceo por Enrutamiento Directo 81 Gráfico 16: Alta Disponibilidad de mon+heartbeat+fake+coda 88 Gráfico 17: Alta disponibilidad con Ldirectord+Heartbeat 92 Gráfico 18: Pregunta Gráfico 19: Pregunta Gráfico 20: Pregunta Gráfico 21: Pregunta Gráfico 22: Pregunta Gráfico 23: Pregunta Gráfico 24: Pregunta Gráfico 25: Pregunta Gráfico 26: Pregunta Gráfico 27: Pregunta

14 xiii UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES DISEÑO Y DESARROLLO DE UN PROTOTIPO DE UN CLUSTER EN LINUX DE ALTA DISPONIBILIDAD PARA SATISFACER LA DEMANDA DE ACCESO WEB EN LA CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES Y EL BALANCEO DE CARGA DE LOS SERVICIOS Autor: Carlos Polivio Zumba Vásquez Tutor: Ing. David Benavides RESUMEN El presente proyecto propone una solución al incremento acelerado del internet, el mismo que se centra en la tecnología de los cluster. La cual permitirán brindar alta disponibilidad y balanceo de carga de los servicios que proporciona la carrera de Ingeniería en Sistemas Computacionales a sus usuarios, mediante el uso de aplicaciones Open Source lo cual representa un ahorro a la institución, es por eso que se implementará una solución viable que permita soportar la carga transaccional de peticiones. Dentro de este trabajo se podrá encontrar información relacionada con los distintos tipos de cluster, características y aplicaciones, seleccionando aquellas que cumplan los objetivos planteados. El contexto estructural del proyecto se define mediante un nodo director que gestione y redirija las peticiones hacia los servidores que tendrán alojados los servicios solicitados. La importancia de los cluster se fundamenta en la escalabilidad que brindan de poder agregar servidores reales según las necesidades lo ameriten, al mismo tiempo aumentado el poder de gestión que representan; además de la redundancia que existen que hacen que trabajen en paralelo; obteniendo tiempo de respuestas óptimas de rendimiento así como de puesta en marcha de algún servicio caído. para de esta manera asumir un posible fallo de uno de los nodos. Permitiendo al sistema funcionar en conjunto donde el usuario no perciba la caída de algún nodo. Un ejemplo palpable del uso de la tecnología en mención es google, el cual posee un conglomerado de servidores trabajando como uno solo, el mismo que atiende miles de peticiones al día; logrando soportar la demanda diaria de los usuarios. La alta disponibilidad permite agregar, y retirar servidores sin que comprometan los servidores que formen parte del cluster, además de no afectar el desempeño total del sistema.

15 xiv UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES DESIGN AND DEVELOPMENT OF A PROTOTYPE OF A LINUX CLUSTER IN HIGH AVAILABILITY TO MEET THE DEMAND FOR WEB ACCESS IN THE RACE FOR COMPUTER SYSTEMS ENGINEERING AND LOAD BALANCING SERVICES Autor: Carlos Polivio Zumba Vásquez Tutor: Ing. David Benavides ABSTRACT This project proposes a solution to the rapid increase of internet, the same that focuses on cluster technology. Which allow to provide high availability and load balancing services provided by the Engineering in Computer Systems to its users, through the use of Open Source applications which represents a savings to the institution, which is why a solution will be implemented viable to allow the burden transactional requests. In this work, you can find information related to cluster different types, characteristics and applications, selecting those that meet the objectives. The structural context of the project is defined by a node manager to manage and redirect the requests to the servers that have hosted the requested services. The importance of the cluster is based on providing the scalability you can add real servers as required warrant, while increasing the power of management accounting, in addition to the redundancy that exist that make working in parallel, obtaining time yield optimal responses as well as implementation of a service down. thus to assume a possible failure of one of the nodes. Allowing the system to work together where the user does not perceive the fall of some node. A concrete example of using technology in question is Google, which has a cluster of servers working as one, the same that handles thousands of requests a day, achieving withstand the daily needs of users. High availability can add and remove servers without compromise the servers that are part of the cluster, in addition to not affect overall system performance.

16 1 INTRODUCCIÓN El creciente mundo tecnológico va evolucionando a un ritmo vertiginoso, es por eso que cada vez son más las instituciones que simplifican sus procesos mediante la incorporación de equipos tecnológicos que permitan satisfacer las necesidades para las cuales fueron adquiridos los mismos. El internet también forma un factor determinante e importante en el auge informático, viéndose reflejado en las numerosas transacciones que viajan a través de esta gran red de redes. Las instituciones brindan datos al alcance de todos los usuarios, manejándose de acuerdo a los estándares y nivel de seguridad. Cada vez son mayores las peticiones de usuarios dispuestos a satisfacer sus necesidades, y como resultado mayores son los procesos que deben de atender los servidores, los cuales permiten satisfacer dicha demanda. Aquí se debe tomar en cuenta las características físicas con los que cuentan los servidores, si estos brindan disponibilidad del servicio que ofrecen, y que tan fiables son. A veces los altos costos que se requieren para tener una infraestructura que permita garantizar una alta disponibilidad son limitantes para las instituciones, sobre todo las educativas, ante la realidad en la cual su presupuesto depende de lo asignado por el régimen de gobierno actual. Por otra parte las instituciones privadas dependen de cuanto están dispuestos a invertir en equipo tecnológico,

17 2 El presente proyecto, busca solucionar el incremento acelerado del uso del internet, ya que consigo trae un problema que afecta el servicio que brinda una institución. Al existir mayor cantidad de usuarios, también aumentara el tráfico en la red, y con ello se tendrá una carga de trabajo mayor la cual será soportada por los servidores. Muchas instituciones solucionan este problema adquiriendo un servidor de altas prestaciones, pero no todas pueden acogerse a esta solución. Existe otra alternativa que se denomina tecnología de clusters, el mismo que permitirá balancear la carga que se da en los servidores que atienden las peticiones o requerimientos de los usuarios. La implementación de clusters permitirá mejorar el tiempo de acceso, además de evitar fallos inminentes que puedan sufrir en un momento determinado un servidor, que ante un colapso este no sufrirá una caída total del sistema. Los clusters ofrecerán una alta disponibilidad y fiabilidad en cada requerimiento atendido de los usuarios, ya que se tendrá un incremento en la velocidad de procesamiento, por lo que se procesara un mayor número de transacciones y en un tiempo de respuesta optimo. La utilización de clusters trae consigo muchos beneficios técnicos, sino también económicos ya que en los actuales momentos los supercomputadores son equipos excesivamente costosos que están fuera del alcance de las instituciones. Un cluster puede ofrecer rendimiento muy cercano a un Supercomputador en cuanto a poder de cómputo.

18 3 Otro punto beneficioso es pensar en el futuro trabajo de los servidores, es decir que tan escalable pueden ser, los clusters brindan esta escalabilidad a un equipo haciendo que tenga la capacidad para hacer frente a volúmenes de trabajo cada vez mayores como se lo menciono al inicio, sin dejar de brindar un nivel de rendimiento aceptable. Es una realidad que la tecnología tiene una evolución presurosa, pero en nuestro país la realidad actual, trae consigo un atraso tecnológico en comparación con los países desarrollados. Esto provoca dificultades en el sector educativo, puntualmente en la Universidad de Guayaquil, en la carrera de Ingeniería de Sistemas Computacionales, donde la demanda actual de acceso a los servicios que brinda la institución son altos, sobre todo en aquellos procesos que se consideran prioritarios, como inscripciones semestrales, consultas de notas, avisos, entre otros. Habiendo adecuarse con equipos tecnológicos de tipo computadores personales teniendo estos características limitadas, en los cuales se alojan los servicios requeridos por los usuarios, volviéndose así en ocasiones inestable los servicios que brindan estos equipos. Para eso se debe conocer si la institución está preparada para satisfacer la demanda web actual, ofreciendo un tiempo de respuesta óptimo en los procesos que realizan cada uno de sus servicios.

19 4 CAPÍTULO I EL PROBLEMA PLANTEAMIENTO DEL PROBLEMA UBICACIÓN DEL PROBLEMA EN UN CONTEXTO La Carrera de Ingeniería en Sistemas Computacionales, ha tenido un crecimiento sustancial de personas que quieren ostentar la educación que la institución ofrece, al existir este incremento desmesurado de estudiantes que pasan a formar parte de la institución, estos demandan servicios funcionando de manera optima y eficaz, motivo por el cual es trabajo de la institución ofrecer un buen desempeño, y a su vez garantizar la disponibilidad de los servicios que se ponen a disposición. En la actualidad el desarrollo tecnológico en el Ecuador despierta el interés por conocer los beneficios que brinda el mundo informático como las relaciones sociales, comunicación, etc., esto desde que entró en vigencia la nueva Constitución de la República del Ecuador publicada en el Registro Oficial No. 449, de 20 de octubre del 2008, que dice en su artículo 356, primer inciso, dispone que: La educación superior pública será gratuita hasta el tercer nivel y en el segundo inciso dispone que: El ingreso a las instituciones públicas de educación superior se regulará a través de un sistema de nivelación y admisión, definido en la Ley. La gratuidad se vinculará a la responsabilidad académica de las estudiantes y los estudiantes.

20 5 SITUACIÓN CONFLICTO NUDOS CRÍTICOS La educación gratuita implica una mayor afluencia de personas que optan por seguir una profesión lo que provoca mayor cantidad de usuarios dispuestos a poder satisfacer sus necesidades. Motivo de esta demanda latente de servicios existen serios inconvenientes en la institución al momento de emprender periódicamente los procesos considerados fuertes, como son el proceso de inscripción. La demanda de acceso a la información se incrementa de tal manera que satura en etapas circunstanciales los servidores especialmente el servidor web, muy utilizado en el proceso en mención, el cual es el encargado principalmente a atender en primera instancia los requerimientos de los usuarios. Por eso al existir mayor flujo de peticiones, provoca a su vez un mayor tráfico en la red. Estas numerosas peticiones, deberán soportar los servidores en los cuales al haber mayor número de transacciones a procesar, el tráfico de la red se satura y la carga de trabajo que deberán de atender será mayor lo que provoca actualmente la saturación de los mismos, teniendo como resultado la caída parcial o total del sistema y a su vez la paralización de los servicios que dependen del proceso en ejecución. Al analizar la disponibilidad del servicio y si este es el óptimo en la institución, se debe tomar en cuenta un factor primordial sobre este análisis el cual es la infraestructura tecnológica que actualmente la institución, la adecuación de servidores se dan a través de

21 6 equipos cuyas características son limitadas no poseen esa tecnología redúndate que si ofrecen los equipos destinados al servir de servidores, haciendo difícil responder a la progresión transaccional de parte de los estudiantes. Motivo por el cual origina un nivel bajo de disponibilidad de los servicios cuando la demanda limita el crecimiento de peticiones de los clientes. La Carrera de Ingeniería en Sistemas Computacionales en estos últimos años ha tenido un nivel mayor de alumnos que cada vez optan por seguir una carrera dentro de la institución en mención, por lo que el recurso tecnológico con los que se cuentan en los actuales momentos limitan el crecimiento de servicios que podría brindar la institución a su alumnado. Por mostrar un ejemplo de un servicio que en los momentos actuales la institución no brinda a sus alumnos, es el servicio de correo electrónico, el cual no se encuentra al alcance de poderse implementar debido a las limitaciones mencionadas anteriormente. Tan solo se encuentra disponible para el uso interno de las dependencias de la institución.

22 7 CAUSAS Y CONSECUENCIAS DEL PROBLEMA Causas Poca inversión para mejorar la infraestructura tecnológica de la institución. Infraestructura tecnológica actual no idónea utilizada como servidores como son los computadores de escritorio. Inestabilidad en la ejecución de servicios que se utilizan en la gestión académica de los docentes. Falta de segmentación del ancho de banda. Carga de servicios no compartida en cada uno de los servidores. Tasa de crecimiento de servicios disminuida. Progresión transaccional delimitada por los usuarios. Falta de organización en los procesos de inscripción a un nuevo ciclo. Poca estandarización de procesos informáticos. Falta de equipos redundantes dedicados hacia los servicios que brinda la institución. Consecuencias Recursos tecnológicos insuficientes, para la creciente demanda de usuarios. Limitaciones en crecimiento de poder de cálculo de los servidores. Insatisfacción e inconformidad en los usuarios (profesores y alumnos). Asignación no idónea del ancho de banda a cada una de las dependencias.

23 8 Saturación de procesos. Poca innovación en futuros servicios que beneficien a los usuarios. Baja disponibilidad de los servicios. Atrasos de procesos concurrentes. Desatención en las prioridades de cada proceso. Paralización de los servicios e inestabilidad en la calidad de servicio 24-7 DELIMITACIÓN DEL PROBLEMA El proceso informático que se efectúa en cada una de las dependencias de la institución no se realiza dentro de los tiempos previamente definidos, sufriendo a veces desfases en el inicio de procesos prioritarios como el de inscripción. El problema tiene su génesis cuando los turnos asignados a cada usuario sufren modificaciones de intervalos de tiempos, lo que provoca un desorden en los procesos de matriculación a un nuevo ciclo de clases. Al alterarse los procesos, debido a demoras en emisiones de horarios de cursos, así como el retraso en asentamiento de notas de parte de catedráticos, hace que el proceso se incremente de tal forma que afecta a los demás días, debiendo culminar dentro de la fechas límites definidas con anterioridad. Motivo por el cual no se altera el tiempo de finalización, el cual da paso al inicio de clases; sino que los días preliminares se atribuyen carga de trabajo extra debido a

24 9 problemas antes mencionados. Al existir un crecimiento sustancial, se obtendrá peticiones presurosas de los usuarios queriendo satisfacer la necesidad de inscripción aun nuevo ciclo. Así que el problema se extiende hacia los servidores y la disponibilidad de estos para atender las peticiones, en ocasiones el servicio web se satura, acrecentando mas el problema debido a las características de los mismos, así como la administración que se da a cada servicio en ellos alojados. Se debe especificar que a su vez la institución brinda servicios considerados internos para el desarrollo normal de clases dentro de un periodo lectivo, como es el servicio de base de datos a nivel educativo, el cual no se considera dentro del contexto del proyecto debido a que el mismo es orientado a la disponibilidad del servicio web y su correcta administración, y de cómo el internet influye cada vez más en procesos independientes de la institución hacia usuarios. FORMULACIÓN DEL PROBLEMA Actualmente nace la interrogante de que al existir un auge significativo en el uso del internet como medio de acceso a los servicios que presta la institución, podrá soportar las cargas transaccionales actuales. Además del proporcionar confiabilidad y acceso prudencial a los servicios en el momento actual, sin dejar de pensar en un crecimiento futuro.

25 10 Razón por la cual nace la idea, Sera posible brindar una eficiente y optima disponibilidad de los servicios que ofrece la carrera, también si se podrá tener una mínima tolerancia a fallos de los mismos? Es motivo del análisis de los resultados obtenidos a través de pruebas realizadas, proporcionar una solución viable al problema del desempeño y disponibilidad de servicios de la institución, ajena a la infraestructura tecnológica con que se cuente; sino a la eficiente gestión de tareas que se deberá brindar. EVALUACIÓN DEL PROBLEMA Delimitado: Se quiere implementar un prototipo de cluster que brinde alta disponibilidad al servicio web que ofrece la carrera de ingeniería de sistemas computacionales; en un plazo no mayor a 6 meses, con los recursos tecnológicos existentes en los actuales momentos. Claro: Permitir balancear la carga de trabajo y el tráfico de la red que gestionan los servidores, garantizando alta disponibilidad del servicio, así como el buen desempeño de los procesos que efectúan los equipos en mención. Evidente: La implementación del cluster brindará un servicio transparente, de forma que minimice la ocurrencia de fallos y que si estos ocurren el usuario no perciba la caída del servicio web y por consiguiente la no respuesta a sus peticiones.

26 11 Factible: La implementación de este prototipo se promedia en un tiempo de medio año, es factible debido a que este proyecto se basa en la infraestructura tecnológica con la que tiene a su haber, sino más bien como administrar los recursos que se procesan en estos equipos computacionales. Identifica los productos esperados: Obtención de un servicio oportuno y eficaz, así como brindar confianza a los usuarios de lo que se está proponiendo como institución. Además permitirá estar preparados a un futuro incremento de usuarios y procesos que estos demandaran cada vez más respuestas a sus peticiones; así como recursos que se utilizaran en cada uno de estos procesos. Variables: Variable Independiente La variable independiente se refiere al diseño y desarrollo de un prototipo de un cluster en Linux de alta disponibilidad, permitiendo balancear la carga de los servicios que se pone a disposición de los usuarios. Variable Dependiente La variable independiente corresponde la demanda de acceso web que atraviesa la carrera de ingeniería en sistemas computacionales.

27 12 OBJETIVOS DE LA INVESTIGACIÓN OBJETIVO GENERAL Configuración e implementación de un prototipo funcional de un cluster con balanceo de carga, mediante la utilización de software de código abierto para administrar la demanda web en la Carrera de Ingeniería en Sistemas Computacionales. OBJETIVOS ESPECÍFICOS Establecer un estudio de las herramientas necesarias para la implementación del cluster de alta disponibilidad y balanceo de carga de los servicios que permitan el correcto funcionamiento del mismo. Diseñar el cluster para que proporcione un correcto funcionamiento de todos sus servicios, y para evitarla caída del sistema en un momento determinado con una mínima ocurrencia de fallos en los servicios de la Carrera de Ingeniería en Sistemas Computacionales. Analizar la disponibilidad de los servicios alojados en el servidor, una vez implementado el prototipo del cluster para determinar que tan satisfactoria es la configuración del cluster, mediante pruebas generadoras de tráfico a través de un equipo cliente hacia los servidores.

28 13 Gestionar la ejecución de tareas en los servidores de forma eficiente, para evitar que ocurran errores en los procesos, por tiempo de ejecución y/o respuesta en las peticiones generadas a través del acceso web de parte de los usuarios de la Carrera de Ingeniería en Sistemas Computacionales. ALCANCE El tema del presente proyecto permitirá conocer una técnica que brinde una alta disponibilidad a través de la redundancia, esto se desarrollara a través de cuatro servidores instalados, que tengan la capacidad de poder trabajar en paralelo, y poder asumir el trabajo en el caso de fallo de algún servidor en particular. Adicional a esto se utilizara dos maquinas virtuales adicionales- 1. Para el desarrollo de este proyecto, necesitaremos de la utilización de máquinas virtuales y sistemas operativos Linux corriendo sobre dichas máquinas virtuales, a excepción de una maquina virtual que servirá de cliente, utilizando como sistema operativo Windows XP SP2. También se necesitara de software necesario para la implementación del cluster y balanceo de carga, además con software de generadores de tráficos que permitan el desarrollo de pruebas a nuestros servidores. 2. Análisis de las herramientas OpenSource disponibles en el mercado y selección de las que más se ajusten a los requerimientos o necesidades en cada uno de los puntos mencionados anteriormente, llegando así a determinar que software es el

29 14 más idóneo dentro de la realización del proyecto. Una vez obtenido los resultados de los estudios realizados, se obtendrá software necesario para el desarrollo del prototipo. 3. Para la creación de máquinas virtuales se utilizara el software de virtualización VMware Dentro del sistema operativo a utilizar se instalara el sistema operativo Linux distribución CentOs versión 5.5, sobre los cuales se levantaran los servicios que se detallan en los siguientes puntos. Instalación y Configuración del servicio Web. Instalación y Configuración del servicio de correo Postfix. Instalación y Configuración del servicio SysLog 5. Selección de herramientas para implementar clusters de alta disponibilidad y balanceo de carga: ldirectord+heartbeat. 6. Implementación de Linux Virtual Server para permitir balancear la carga de los servidores. 7. Implementación de Heartbeat, junto con LVS para proporcionar una alta disponibilidad. 8. Proporcionar un interfaz web de configuración del servicio ldirectord, desarrollado bajo PHP y Javascript, llamada Ipvsadmin.

30 15 9. Análisis de la disponibilidad de los servicios una vez implementado el cluster, a través de pruebas con software de código abierto, usando como herramienta generadora de tráfico JMeter 2.4; para verificar el funcionamiento del cluster. 10. Pruebas con clientes Windows, generando un telnet a la interfaz virtual del cluster. 11. Análisis comparativo antes de y después de la implementación del cluster de servicios. JUSTIFICACIÓN E IMPORTANCIA La carrera de Ingeniería en Sistemas Computacionales está creciendo cada día más, es por eso que este crecimiento no solo depende de la estructuración que tenga sino de cómo estos se integran de manera oportuna y eficaz. Depende de la forma en que los procesos estén definidos, y si estos están correctamente planteados y administrados en cada dependencia. Un proceso importante dentro de la institución, es el acceso a la información que deben de tener cada una de las dependencias, así también los usuarios; cada uno de ellos accediendo a través de peticiones previamente procesadas, lo que conlleva a evaluar el tiempo implicado en el mismo.

31 16 UTILIDAD PRÁCTICA DE LA INVESTIGACIÓN Por eso que es necesario que la información este presente cada vez que los clientes necesiten de la misma, por lo que nace la idea de implementar clusters los cuales proporcionan alta disponibilidad de servicios que son requeridos por los usuarios, así como balancear la carga de trabajo que estos representan a los servidores, en los cuales se encuentra la información solicitada. Al proporcionar lo mencionado anteriormente se obtendrá un desempeño óptimo, lo que aumentara la productividad de los usuarios envueltos en estos procesos; permitiendo un flujo de procesos más rápido y eficiente, así se permitirá tener una disponibilidad eficaz en un momento eventual. Dada al auge creciente del internet es necesario estar preparados para este crecimiento y como poder soportarlo sin descuidar la respuesta rápida y oportuna de debemos de ofrecer a nuestros usuarios finales. CUÁLES SERÁN LOS BENEFICIARIOS Lo beneficiosos de este proyecto radica en soportar el crecimiento de usuarios propios de la institución, así como aquellos que considerados ajenos, los cuales tienen la misma necesidad de información. Adicionalmente mejoraría la presencia de la carrera a nivel institucional y de internet, debido a la existencia del portal web, y los futuros servicios adicionales que brindaría a sus clientes a través de la misma.

32 17 CAPÍTULO II MARCO TEÓRICO ANTECEDENTES DEL ESTUDIO La tecnología de clusters nace debido a la necesidad de mejorar el rendimiento y la disponibilidad de servicios específicos, junto a esta necesidad latente de ofrecer servicios rápidos y confiables; han evolucionado aplicaciones que permiten soportar estas situaciones críticas. Tales como carga creciente de trabajo en servidores web, el comercio electrónico, y no dejar de destacar las bases de datos de alto rendimiento, entre otros. Por razones expuestas anteriormente se requiere un sistema donde la infraestructura debe de ser construida para soportar estas aplicaciones sin dejar de mirar al futuro; lo representativo de esta tecnología es la incorporación de componentes de hardware comunes, de tal forma que trabajen como uno solo. Al referirnos al termino cluster y del uso de este tipo de tecnología es desconocido pero se puede considerar que comenzó a finales de los años 50 y principios de los años 60. Surgieron conceptos importantes como arquitectura, procesamiento y tecnologías en paralelo, los cuales se ampliaran más adelante. Todas estas bases de ingeniería informática se atribuye a Gene Amdahl de IBM, que en1967 publicó lo que ha llegado a ser considerado como el papel inicial de procesamiento paralelo: la Ley de Amdahl 1 que 1 Visitar Sitio Web:

33 18 describe matemáticamente lo que se puede esperar paralelizando cualquier otra serie de tareas realizadas en una arquitectura paralela. La historia de los primeros cluster de computadoras esta directamente ligado ala historia de principios de las redes, como una de las principales motivaciones para el desarrollo de una red para enlazar los recursos de computación, de hecho la creación de un cluster de computadoras. Las redes de conmutación de paquetes fueron conceptualmente inventados por la corporación RAND en Utilizando el concepto de una red de conmutación de paquetes, el proyecto ARPANET 2 logró crear en 1969 lo que fue posiblemente la primera red de computadoras básico basadas en el cluster de computadoras por cuatro tipos de centros informáticos (cada uno de los cuales fue algo similar a un "cluster"). En la actualidad este proyecto se conoce como internet, considerado como el génesis de la tecnología de clusters. El primer producto comercial de tipo cluster fue Datapoint pero no obtuvo un éxito comercial y los clusters no consiguieron tener éxito hasta que en 1984 VAXcluster produjeran el sistema operativo VAX/VMS. Estos sistemas operativos no sólo son productos que ofrecen la computación paralela, sino permiten compartir los sistemas de archivos y dispositivos periféricos. 2 Visitar Sitio Web:

34 19 A partir de estas implementaciones surgieron otras como Tandem Himalaya, las cuales ofrecían beneficios como la alta disponibilidad, así como beowulf cuyo objetivo específico es de ser un superordenador capaz de realizar cálculos paralelos Highperformance computing. Debido a la necesidad por brindar un servicio contante las grandes empresas han recurrido a implementar la tecnología de cluster. Una de las grandes compañías en el mundo del internet se acoge a este tipo de tecnología la misma que es GOOGLE 3 ; el cual tiene un promedio de visitas exuberantes, motivo por el cual va mas allá de un simple cluster, sino que implementan una granja de servidores configurados como uno solo ante la vista de sus usuarios. Así enfrentan el día a día de las transacciones que procesan, así también con este incremento acelerado que tiene el internet, instituciones educativas en el Ecuador no han sido esquivos al uso de esta tecnología mencionada anteriormente, en la Escuela Superior Politécnica del Litoral ha realizado estudios basados en evaluación, análisis y comparación de rendimiento de programas sobre plataformas de clusters, así como diseño de un Call Center usando cluster; además la Universidad Técnica Particular de Loja existen cluster que permiten brindar un mejor servicio web y mail al estudiantado. No dejar de un lado el proyecto que ofrece la Universidad Politécnica Nacional de un 3 Visitar Sitio Web:

35 20 cluster de alta disponibilidad y balanceo de carga para satisfacer el servicio web de su institución. Razón primordial para que la carrera de ingeniería en sistemas computacionales, empiece a usar este tipo de tecnología. Si bien es cierto no se dimensiona a lo que hace GOOGLE como empresa, pero lo que si tienen en común ambas es satisfacer la necesidad de peticiones que envían los usuarios como tal. Motivo por el cual es necesario estar prestos y dispuestos a avanzar con el auge tecnológico que se acrecienta con el pasar de los años. FUNDAMENTACIÓN TEÓRICA TECNOLOGÍAS PARALELAS Las tecnologías paralelas se relacionan a la arquitectura computacional en lo que ofrece un determinado equipo, a lo largo de la evolución tecnológica se ha querido determinar la clasificación de la arquitectura que puede existir en los distintos recursos tecnológicos, la más ampliamente utilizada es la propuesta de mecanismos de clasificación de computadoras presentada en 1966 por Michael Flynn 4. La taxonomía de Flynn considera dos factores: el número de instrucciones y el número de flujos de datos que maneja el procesador. Una máquina puede tener uno o múltiples, dando lugar a cuatro posibles combinaciones: 4 Michael J. Flynn (nacido el 20 de mayo de 1934 en Nueva York) es un profesor emérito de la Universidad Stanford estadounidense, con estudios en ingeniería electrónica y ciencias de la computación. Flynn confundópalynassociates junto a Max Paley y es el Presidente de Maxeler Technologies.

36 21 SISD (Single Instruction stream, Single Data stream). Máquinas que poseen un único procesador SIMD (Single Instruction stream, Multiple Data streams). Máquinas que poseen un punto de control único, ejecuta la misma instrucción de forma simultánea sobre múltiples valores de datos. Estas máquinas están clasificadas en arreglos de procesadores, procesadores vectoriales y arreglos sistólicos. MISD (Multiple Instruction streams, Single Data stream). Estas máquinas tienen múltiples flujos de instrucciones que operan sobre el mismo flujo de datos. MIMD (Multiple Instruction streams, Multiple Data streams). Estas máquinas emplean múltiples puntos de control los cuales poseen flujos de instrucciones y datos independientes. Se consideran MIMD a los sistemas multiprocesadores y paralelos. CLASIFICACIÓN SISD (Single Instruction stream, Single Data stream) Este es el modelo tradicional de computación secuencial donde una unidad de procesamiento recibe una sola secuencia de instrucciones que operan en una secuencia de datos. Ejemplos de arquitecturas SISD son los tradicionales computadores uniprocessador cómo PC o antiguos mainframes.

37 22 Gráfico 1: Arquitectura SISD Elaboración: Investigadora Fuente: SIMD (Single Instruction Multiple Data) A diferencia de SISD, en este caso se tienen múltiples procesadores que sincronizadamente ejecutan la misma secuencia de instrucciones, pero en diferentes datos. El tipo de memoria que estos sistemas utilizan es distribuida. Donde un computador explota flujos de datos múltiples contra un flujo simple de instrucciones para realizar operaciones que pueden ser paralelizables. Por ejemplo, La instrucción sumar dos números es ejecutada en los 4 procesadores y los 4 ejecutan las instrucciones simultáneamente. Esto toma un paso en comparación con cuatro pasos en una máquina secuencial, estos procesos son muy usados en computadores matriciales (procesador vectorial).

38 23 Gráfico 2: Arquitectura SIMD Elaboración: Investigadora Fuente: MISD (Multiple Instruction Single Data) En este modelo, secuencias de instrucciones pasan a través de múltiples procesadores. Diferentes operaciones son realizadas en diversos procesadores. N procesadores, cada uno con su propia unidad de control comparten una memoria común. Las instrucciones múltiples operan en un flujo de datos simple, es una arquitectura poco frecuente que se utiliza a menudo por la tolerancia a errores y en sistemas heterogéneos que operan con el mismo flujo de datos y tienen que estar de acuerdo con el resultado. Por ejemplo Múltiples algoritmos de criptografía actuando en un mensaje codificado, o Filtros de múltiple frecuencia operando en una única señal.

39 24 Gráfico 3: Arquitectura MISD Elaboración: Investigadora Fuente: MIMD (Multiple Instruction Multiple Data) Este tipo de computadora es paralela al igual que las SIMD, la diferencia con estos sistemas es que MIMD es asíncrono, no tiene un reloj central. Varios procesadores autónomos en un sistema MIMD ejecutan simultáneamente instrucciones diferentes sobre datos diferentes. Los sistemas distribuidos suelen clasificarse como arquitecturas MIMD; bien sea explotando un único espacio compartido de memoria, o uno distribuido. Esta característica es la más general y poderosa de esta clasificación. Ejemplos de este tipo son los supercomputadores actuales, redes de computadoras "grids", multiprocesadores SMP - incluyendo algunos tipos de PCs.

40 25 Gráfico 4: Arquitectura MIMD Elaboración: Investigadora Fuente: Los computadores SIMD son simples de diseñar comparados con las máquinas MIMD pero se consideran menos flexibles, debido a que todos los multiprocesadores SIMD deben ejecutar la misma instrucción de forma simultánea 5. La taxonomía de Flynn no es apropiada cuando asume que el paralelismo es homogéneo, debido a que los procesadores pueden ser homogéneos como heterogéneos. Además los sistemas MIMD clasifican los procesadores sin considerar su conexión o la distribución de la memoria. Actualmente los MIMD definen un alto rendimiento y una alta productividad. Dentro de este nacen los paradigmas de mayor importancia los cuales se muestra a continuación. 5 Visitar Sitio Web:

41 26 SMP (SymmetricMultiProcessors) MPP (MassiveParallelProcessors) Ambas se consideran arquitecturas MIMD, pero se diferencian en la forma en que utilizan la memoria. Las máquinas SMP comparten la memoria mientras las MPP no lo hacen. Las máquinas MPP típicamente albergan miles de CPUs en un gran contenedor conectados a cientos de GB de memoria. El término MPP describía el acoplamiento de multiprocesadores SIMD; actualmente este término es utilizado para arquitecturas paralelas que poseen nodos con memoria privada, cada uno de los cuales tiene la habilidad de comunicarse uno con otro a través de una red. La forma más sencilla de diferenciar un sistema MPP de un SMP es la siguiente 6 : MPP = varios procesadores + memoria distribuida + comunicación vía red. SMP = pocos procesadores + memoria compartida + comunicación vía memoria. 6 Visitar Sitio Web:

42 27 Gráfico 5: Arquitectura SMP Elaboración: Investigadora Fuente: Gráfico 6: Arquitectura MPP Elaboración: Investigadora Fuente:

43 28 Existen extensiones de esta taxonomía las cuales se mencionan a continuación: Single Program, Multiple Data (SPMD) Son múltiples procesadores autónomos que trabajan simultáneamente sobre el mismo conjunto de instrucciones (aunque en puntos independientes) sobre datos diferentes. También se le llama 'un proceso, múltiples datos' 7. MultipleProgramMultiple Data (MPMD) Procesadores múltiples autónomos que operan simultáneamente al menos con 2 programas independientes. Normalmente este tipo de sistemas seleccionan un nodo que es el anfitrión "huésped" o "manager", que ejecuta un programa que proporciona datos a los otros nodos que es ejecutando en un programa secundario. Los otros nodos, a continuación, envían sus resultados directamente al manager 8. Los clusters forman parte del tipo de tecnología MIMD. Donde cada cluster puede ser fácilmente un grupo de estaciones de trabajo, los mismos que agrupados y trabajando en paralelo se obtiene un mejor rendimiento en un proceso definido estando en ejecución; la ventaja es que se puede sacar un rendimiento optimo al conjunto de ciclos sin ejecución realizando tareas paralelas que no conciernen al proceso especifico del cluster como tal. 7 Léase: 8 Lease:

44 29 FUNDAMENTOS GENERALES DE LOS CLUSTERS En la actualidad el crecimiento de demanda se servicios de internet, el auge significativo del comercio electrónico y la transferencia de información que se efectúa a través de esta red de redes. Hacen que de parte de los proveedores de estos servicios garanticen el funcionamiento de su infraestructura tecnológica de forma ininterrumpida y sin fallos 24-7, brindando seguridad, confiabilidad, disponibilidad y calidad de servicios que ofertan. Dentro del mercado tecnológico existen empresas que fabrican servidores tipo cluster; son equipos de altas prestaciones, que brindan multiprocesamiento y redundancia. La desventaja de esto es el elevado costo de estos equipos el cual implica grandes inversiones y limitantes a futuro cuando uno de estos equipos quede obsoleto, lo que conlleva a reemplazarlo. Un cluster de servidores permite garantizar que los recursos y las aplicaciones de importancia inmersas en un determinado servicio, permanezcan disponibles para los usuarios. De ahí nace la importancia de la existencia de los cluster como solución de problemas mencionados anteriormente como gran capacidad computacional, velocidad de procesamiento, mayor número de transacciones las cuales garanticen confiabilidad en los procesos que se efectúen en un momento determinado.

45 30 CONCEPTO El término cluster se aplica a los conjuntos o conglomerados de computadoras construidos mediante la utilización de componentes de hardware comunes y que se comportan como si fuesen una única computadora 9. Un cluster es un sistema que posee una arquitectura distribuida, formada por un grupo de equipos independientes, que ejecutan acciones de manera conjunta y que aparecen como un único recurso computacional ante aplicaciones y clientes. Los cluster son empleados para mejorar el rendimiento y garantizar escalabilidad, confiabilidad y disponibilidad, debido a que esta tecnología permite integrar equipos de potencia media; los mismos que interconectados entre sí por redes de alta velocidad forman un arreglo de nodos redundantes. Permite reemplazar uno de los nodos si este falla, de manera que permita al sistema su correcto funcionamiento. CARACTERISTICAS Las características principales que se debe de considerar antes de implementar un cluster son las que se detallan a continuación: Un Cluster consta de 2 o más nodos. Un sólo computador, en ningún caso, puede ser considerado como un Cluster debido a la situación de aislamiento en que se 9 Visitar Sitio Web:

46 31 encuentra, puesto que no puede comunicarse y menos, ocupar los recursos de otra máquina 10. Los nodos de un cluster deben estar interconectados entre sí por al menos un canal de comunicación a través de redes de alta velocidad; esto excluye a los sistemas de multiprocesamiento simétrico o SMP y sistemas de procesadores masivamente paralelos o MPP. Los clusters necesitan software de control especializado. Para tener un funcionamiento correcto de un cluster, debe de estar determinado por un software de control especializado, el mismo que es delimitado por el tipo de cluster a implementar, tanto en la parte de hardware como de software que conforman el cluster. Software de control para gestión del cluster. Control que se refiere a la configuración del cluster, el cual depende del tipo de cluster y de la manera en que se conectan los nodos. El control puede ser de dos tipos: Control centralizado. El cual consta de un nodo maestro o director, con el que se puede configurar todo el sistema. Control descentralizado. Control en el que cada nodo se administra y gestiona individualmente. 10 Visitar Sitio Web:

47 32 ARQUITECTURA La arquitectura de un cluster está formada por varios componentes mostrados en el gráfico 7, los mismos que se detallan a continuación: Gráfico 7: Arquitectura del Cluster Elaboración: Investigadora Fuente: COMPONENTES DE UN CLUSTER Un cluster necesita de componentes de hardware y software para su correcto funcionamiento, entre los cuales tenemos:

48 33 Nodos Es la unidad básica de un cluster, los cuales pueden ser simples computadores personales, estaciones de trabajo (workstations) o SMPs (Simetric Multiprocessors), estos pueden estar interconectados a través de una red LAN 11 o estar agrupados por una red SAN 12. El cluster puede estar formado por nodos dedicados o no dedicados. Los dedicados son aquellos que no poseen dispositivos como el teclado, ratón ni monitor; cuya función exclusiva es la de realizar tareas especificas relacionadas con el cluster. Mientras que los no dedicados disponen de los periféricos mencionados anteriormente, y no se restringe a realizar tareas relacionadas con el cluster; sino que hace uso de los ciclos de reloj muertos que el computador no utilice en la ejecución de sus tareas. Anteriormente se menciono ciertos dispositivos de entrada y salida, que como tal forman parte del hardware del cluster; pero existen dispositivos que permiten su funcionamiento como tal, entre ellos tenemos: procesadores, memoria, caché, dispositivos y buses de comunicación. Es importante mencionar que al momento de diseñar un cluster, los nodos deben tener características similares, es decir, deben guardar cierta similitud de arquitectura y sistemas operativos, ya que si se conforma un cluster con nodos totalmente heterogéneos 11 Léase Definiciones Conceptuales - LAN (Local Area Network) 12 SAN (Storage o System Area Network)

49 34 (existe una diferencia grande entre capacidad de procesadores, memoria, disco duro) será ineficiente debido a que el middleware delegará o asignará todos los procesos al nodo de mayor capacidad de cómputo y solo distribuirá cuando este se encuentre saturado de procesos; por eso es recomendable construir un grupo de ordenadores lo más similares posible 13. Sistemas Operativos Un nodo del cluster posee su propio sistema operativo, el mismo que debe de ser multiproceso y multiusuario; debido a que permiten dividir el trabajo entre procesos asignándole recursos a cada uno de ellos, además deberán compartir recursos entre varios usuarios. Es importante al momento de definir el sistema operativo a utilizar, el cual debe de ofrecer al usuario que va a administrar el cluster, la facilidad de gestión de los recursos que se ejecuten, así como el fácil acceso de los recursos que estos requieren. Por eso es recomendable usar sistemas operativos modernos, los cuales hacen referencia a las últimas versiones de software y el soporte que estos brinden, los cuales deben adaptarse a nuestras necesidades y exigencias. Actualmente existen herramientas de instalación automática de cluster que permiten explotar las características de los sistemas operativos, entre los cuales se mencionan a Boewulf, OSCAR, Rocks, entre otros; los mismos que permiten gestionar la 13 Visitar Sitio Web:

50 35 administración de los recursos de los nodos que conforman el cluster y la comunicación que se dan entre ellos a través de la red de interconexión. Conexiones de Red Los nodos de un cluster pueden estar conectados a través de una simple red Ethernet, o usarse redes de alta velocidad como Fast Ethernet, Gigabit Ethernet, Myrinet, Infiniband, ATM, SCI, clan y QsNEt. Ethernet. Ethernet, Fast Ethernet y Gigabit Ethernet, son las tecnologías más utilizadas en la actualidad debido al relativo bajo costo que ostentan, Ethernet ofrece un ancho de banda de 10 Mbps, lo que limita el tamaño del paquete y limitar el rendimiento del cluster, debido a que no soporta gran demanda de acceso. Debido a eso aparecieron la tecnología Fast Ethernet y Gigabit Ethernet, que ofrece un ancho de banda de 100 Mbps, y 1 Gbps respectivamente. Myrinet. Myrinet es una red de interconexión de clusters de altas prestaciones. Sus productos han sido desarrollados por Myricom desde El ancho de banda que maneja cada adaptador de red y los switcha incrementado desde 640 Mbps hasta los 2.4 Gbps, teniendo tiempos de entrega de paquetes que fluctúan entre los 7 y 10 micro segundos. Cada nodo posee una tarjeta de red PCI-X con una o dos conexiones, las cuales pueden manejar velocidades de 2 Gbps o 10 Gbps 14 Lease:

51 36 bidireccionales, estas tarjetas se interconectan a través de un cable Myrinet (fibra óptica) a un switch Myrinet de hasta 128 puertos. Esta tecnología posee un software el cual detecta automáticamente a la red Myrinet sin necesidad de configurar el conmutador o switch. Infiniband. Infiniband es un bus de comunicaciones serie de alta velocidad, diseñado tanto para conexiones internas como externas. Sus especificaciones son desarrolladas y mantenidas por la Infiniband Trade Association (IBTA) 15. Para la comunicación utiliza un bus bidireccional con lo cual ofrece dos canales de transmisión independientes. El ancho de banda básico de un enlace simple (1x) es de 2.5 Gbits/s. Cada enlace simple puede tener 1, 4 ó 12 líneas de conexión, consiguiéndose unas velocidades de transferencia bidireccionales (permite una comunicación full dúplex entre dispositivos) de 5 Gbits/s (1x), 20 Gbits/s (4x) y 60 Gbits/s (12x), respectivamente 16. ATM.El Modo de Transferencia Asíncrona o Asynchronous Transfer Mode (ATM) es una tecnología de telecomunicación desarrollada para hacer frente a la gran demanda de capacidad de transmisión para servicios y aplicaciones. Tecnología de alta velocidad basada en la conmutación de celdas o paquetes. ATM es una tecnología utilizada en ámbitos LAN y WAN, de vital importancia para aplicaciones en tiempo real como voz y vídeo, las cuales requieren garantía en la entrega de 15 Lease: 16 Visitar Sitio Web:

52 37 información, es decir necesitan de un protocolo orientado a conexión. ATM es una de las redes de mayor ancho banda (soportada por Linux actualmente). La desventaja es el costo elevado de este tipo de tecnología, además de los problemas de compatibilidad que existen de parte de los proveedores. Interfaz Escalable Coherente (SCI ScalableCoherent Interface).Es un estándar original de IEEE, concebido para incrementar el ancho de banda de los buses en blackplane 17, superando los límites físicos encontrados en los mismos y, de esta forma, satisfacer las necesidades de las nuevas generaciones de chips; algunos de los cuales pueden saturar los buses más rápidos que existen actualmente 18. Su funcionamiento se basa en la existencia de un anillo que contiene varios nodos conectados entre sí por enlaces unidireccionales punto a punto. Cada nodo que pertenece al anillo está conectado por un enlace proveniente del nodo que le precede y por un enlace con destino al nodo siguiente. Este enfoque se lo puede aplicar hasta un cierto límite de nodos, para ello existen diferentes arreglos los cuales pueden soportar hasta nodos configurados en diferentes topologías como anillos simples o múltiples, dependiendo éstos de las necesidades. La desventaja de esta configuración radica en que si un nodo falla, este incapacita a todos los nodos que comparten el anillo, también es imposible agregar o retirar un nodo del sistema debido a que su topología lo impide. 17 Ver Glosario Capitulo 1 18 Visitar Sitio Web:

53 38 clan. Tecnología creada por Gigante (hoy adquirida por Emulex), ofrece un alto rendimiento para redes de alta velocidad, posee adaptadores PCI y switches de 8 y 30 puertos, ofreciendo velocidades de 1.25 Gbps por puerto (2.5 Gbps bidireccional). Es una tecnología muy utilizada en la interconexión de los diferentes dispositivos pertenecientes a un cluster. QsNET. Es una interconexión de alta velocidad diseñado por Quadrics utilizados en HPC clusters. Aunque puede ser utilizado con TCP / IP, como el SCI, Myrinet y Infiniband se utiliza generalmente con una comunicación de la API 19 como MPI 20 o shmem llamado desde un programa paralelo. QsNet está conformada de dos partes, la interfaz de red Elan y el switch Elite, el cual dispone de 16 a 128 puertos, este switch posee dos canales virtuales bidireccionales por enlace, es decir cada enlace posee dos puertos de entrada/salida con una tasa de transferencia teórica de 400 Mbyte/s en cada dirección. El switch provee también dos niveles de prioridad, los cuales son de gran ayuda en la entrega de paquetes de mayor importancia en el menor tiempo posible. Middleware El middleware es un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Funciona como una capa de abstracción de software distribuida, que se 19 Léase Definiciones Conceptuales - API 20 Léase Definiciones Conceptuales - MPI

54 39 sitúa entre las capas de aplicaciones y las capas inferiores (sistema operativo y red), con la finalidad de proveer al cluster lo siguiente. Una interfaz única de acceso al sistema, denominada SSI (Single SystemImage), la cual genera la sensación al usuario de que utiliza un único ordenador muy potente. Herramientas para la optimización y mantenimiento del sistema: migración de procesos, checkpoint-restart (congelar uno o varios procesos, mudarlos de servidor y continuar su funcionamiento en el nuevo host), balanceo de carga, tolerancia a fallos, etc. Escalabilidad: debe poder detectar automáticamente nuevos servidores conectados al cluster para proceder a su utilización. Existen diversos tipos de middleware, como por ejemplo: MOSIX, OpenMOSIX, Cóndor, OpenSSI, etc. El middleware recibe los trabajos entrantes al cluster y los redistribuye de manera que el proceso se ejecute más rápido y el sistema no sufra sobrecargas en un servidor. Esto se realiza mediante políticas definidas en el sistema (automáticamente o por un administrador) que le indican dónde y cómo debe distribuir los procesos, por un sistema de monitorización, el cual controla la carga de cada CPU y la cantidad de procesos en él Visitar Sitio Web:

55 40 Entornos y herramientas de programación paralela Hilos de Ejecución En sistemas operativos, un hilo de ejecución o subproceso es una característica que permite a una aplicación realizar varias tareas a la vez (concurrentemente). Los distintos hilos de ejecución comparten una serie de recursos tales como el espacio de memoria, los archivos abiertos, situación de autenticación, etc. Esta técnica permite simplificar el diseño de una aplicación que debe llevar a cabo distintas funciones simultáneamente. Un hilo es básicamente una tarea que puede ser ejecutada en paralelo con otra tarea. Los hilos de ejecución que comparten los mismos recursos, sumados a estos recursos, son en conjunto conocidos como un proceso. El hecho de que los hilos de ejecución de un mismo proceso compartan los recursos hace que cualquiera de estos hilos pueda modificar éstos. Cuando un hilo modifica un dato en la memoria, los otros hilos acceden a ese dato modificado inmediatamente. 22 Paso de Mensajes El paso de mensajes es imprescindible en sistemas distribuidos dado que en este caso no existen recursos directamente compartidos para intercambiar información entre los procesos. Sin embargo, también si se trabaja con un solo procesador pasar mensajes entre procesos es un buen método de sincronizar procesos o trabajos, 22 Visitar Sitio Web:

56 41 respectivamente. Existen muchas variantes de implementaciones de paso de mensajes 23. Existen diversos sistemas de paso de mensajes, entre los que más destacan son la Máquina Virtual Paralela (PVM Parallel Virtual Machine) y el Interfaz de Paso de Mensajes (MPI Message Passing Interface). Sistemas de Memoria Compartida Distribuida (DSM). La memoria compartida distribuida (DSM) es una abstracción utilizada de compartir datos entre computadores que no comparten memoria física. Los procesos acceden a DSM para leer y actualizar, dentro de sus espacios de direcciones, sobre lo que aparenta ser la memoria interna normal asignada a un proceso. Sin embargo, existe un sistema subyacente en tiempo de ejecución que asegura de forma transparente que procesos diferentes ejecutándose en computadores diferentes observen las actualizaciones realizadas entre ellas. Es como si los procesos accedieran a una única memoria compartida, pero de hecho la memoria física está distribuida. Su principal objetivo es el procesamiento paralelo y la compartición de datos 24. Depuradores Paralelos. Herramientas muy útiles que permiten desarrollar aplicaciones de alto rendimiento, correctas y eficientes. Un depurador paralelo ofrece las siguientes utilidades: Administrar múltiples procesos y threads dentro de un proceso. Mostrar código fuente. 23 Visitar Sitio Web: 24 Lease:

57 42 Permitir mostrar objetos, subrutinas y funciones. Utilizar puntos de parada en código fuente. Mostrar arreglos y sus elementos. Manipular variables y constantes. Herramientas de Análisis de Rendimiento. Herramientas que permiten medir el funcionamiento de una aplicación, para llegar así a encontrar y analizar puntos de fallo, teniendo un correcto control de su funcionamiento. Herramientas de Administración. La administración de un cluster es de vital importancia para mantener el correcto funcionamiento de éste, mediante estas herramientas se puede tener un monitoreo adecuado de sus componentes. Aplicaciones Las aplicaciones permiten automatizar ciertas tareas complicadas, o también para resolver un problema especifico, estas pueden ser paralelas o distribuidas y secuenciales. Aplicaciones Paralelas. Son aplicaciones que se distribuyen entre varias máquinas y plataformas para trabajar en forma integrada, distribuyendo el trabajo. Un ejemplo es la arquitectura cliente-servidor caracterizado por dividir la funcionalidad de la aplicación en ambas partes.

58 43 Aplicaciones Secuenciales. Es aquella en la que una tarea o instrucción se ejecuta de forma simultánea. Donde divide las tareas más grandes en pequeñas; para así procesarlas en forma concurrente. Las tareas se suceden de tal modo que la salida de una es la entrada de la siguiente y así sucesivamente hasta el fin del proceso. CLASIFICACIÓN Los clusters son utilizados para mejorar y ofrecer un alto rendimiento, balanceo de carga y alta disponibilidad de sus servicios. Debido a eso la clasificación más generalizada es la que se presenta a continuación: Balanceo de Carga (Load Balancing) Alta disponibilidad (HA, highavailability) Alto rendimiento (HP, high performance) Alta Confiabilidad (HR, highreliability) BALANCEO DE CARGA Es un cluster que permite que varios servidores compartan la carga de trabajo y de trafico que se origina de parte de los clientes Estos se encargan de distribuir las peticiones que reciba el cluster. Este proceso de dividir la carga de trabajo entre los servidores reales permite obtener un mejor tiempo de acceso a las aplicaciones y con ellos tener una mejor confiabilidad del sistema.

59 44 Además como es un conjunto de servidores el que atiende el trabajo, la falla de uno de ellos no ocasiona una falla total del sistema ya que las funciones de uno, las puede suplir el resto. ALTA DISPONIBILIDAD Cluster muy solicitado y de mucha importancia para empresas que brindan servicios 24-7 dónde su principal función es la de mejorar los servicios que dichas empresas ofrecen a los clientes en las redes a las que pertenecen, sean estas internas (intranet) o externas (Internet). El brindar alta disponibilidad no hace referencia a conseguir una gran capacidad de cálculo, si no lograr que una colección de máquinas funcione en conjunto y que todas realicen la misma función que se les encomendó. La característica principal de este cluster es que ante la existencia de algún problema o fallo de uno de los nodos, el resto asumen ese fallo y con ello las tareas del nodo con problemas. Estos mecanismos de alta disponibilidad lo brindan de forma transparente y rápida para el usuario. Los clusters de Alta Disponibilidad (HA) son usados cuando el costo de la posible falta de servicio del sistema, supera el costo de implementar un Sistema en Cluster, por ejemplo 25 : Sistemas de Facturación 25 Visitar Sitio Web:

60 45 Operaciones Bancarias Comercio Electrónico Operaciones Comerciales, etc. La flexibilidad y robustez que poseen este tipo de cluster los hacen necesario en sistemas cuya funcionalidad principal es el intercambio masivo de información y el almacenamiento de datos sensibles, dónde se requiere que el servicio esté presente sin interrupciones. El mantenimiento es otra de las ventajas que ofrece. El mantenimiento se puede realizar de manera individual a cada máquina que compone el conglomerado evitando comprometer los servicios que este brinda. Existen dos tipos de configuraciones aplicables a estos clusters: Configuración activo - pasivo: Esta configuración tiene dos actividades en los nodos que componen el cluster, los activos son aquellos que se encargan de ejecutar las aplicaciones encomendadas, mientras que los nodos restantes actúan como respaldos redundantes para los servicios ofrecidos. Configuración activo - activo: En este caso, todos los nodos actúan como servidores activos de una o más aplicaciones y potencialmente como respaldos para las aplicaciones que se ejecutan en otros nodos. Cuando un nodo falla las aplicaciones que se ejecutaba en él migran a uno de los nodos de respaldo.

61 46 ALTO RENDIMIENTO Este tipo de cluster lo que busca es suplir las necesidades de súper computación para resolver problemas de determinadas aplicaciones que requieren un alto procesamiento, esto se logra mediante la utilización de un grupo de máquinas individuales las cuales son interconectadas entre sí a través de redes de alta velocidad y de esta manera se obtiene un sistema de gran rendimiento que actúa como uno solo. La utilidad principal de este tipo de cluster es principalmente en aplicaciones en las que se requieren gran capacidad de procesamiento computacional, la cual soluciona problemas de alto procesamiento mediante la utilización de técnicas necesarias para la paralelización de la aplicación, distribución de los datos a los nodos, la obtención y presentación de resultados finales. Los clusters de Alto Rendimiento (HP) están diseñados para brindar altas prestaciones en cuanto a capacidad de procesamiento. Estos son típicos campos donde dichos sistemas son usados: Procesamiento de imágenes: Reconocimiento de Patrones. Investigación: Física, Ciencia de Bio-Información (estudio de cadenas de ADN por ejemplo), Bioquímica, Biofísica.

62 47 Industria: Estudios Geológicos (extracción de minerales), Simulación matemática, Simulación Militar, y muchos otros 26. ALTA CONFIABILIDAD Cluster caracterizado por ofrecer una alta confiabilidad al sistema. La idea es obtener respuestas eficientes del sistema a pesar de tener una sobrecarga de las capacidades de un servidor. Estos clusters se caracterizan por ejecutar un mayor número de tareas en el menor tiempo posible. Estos clusters tratan de aportar la máxima confiabilidad en un entorno. Puede tratarse por ejemplo de sistemas de respuesta a tiempo real, estos sistema se van a comportar de una manera determinada. Este tipo de clusters son los más difíciles de implementar. No se basan solamente en conceder servicios de alta disponibilidad, sino en ofrecer un entorno de sistema altamente confiable. Esto implica muchísima sobrecarga en el sistema. Cluster: Funcionamiento El funcionamiento de un cluster está basado en dos partes fundamentales: a nivel de software y a nivel de hardware. A nivel de Software. Mediante el uso de un sistema operativo que brinde las herramientas necesarias para la creación de un cluster, tal es el caso de un kernel Linux modificado, compiladores y aplicaciones especiales, los cuales 26 Visitar Sitio Web:

63 48 permitan que los programas que se ejecutan en el sistema exploten todas las ventajas del cluster. A nivel de Hardware. Mediante la interconexión entre máquinas (nodos) del cluster, las cuales se juntan utilizando redes dedicadas de alta velocidad como por ejemplo Gigabit Ethernet. Cuando se trata de brindar balanceo de carga mediante un cluster el hardware y software trabajan conjuntamente para distribuir la carga de tráfico a los nodos, para de esta manera poder atender eficientemente las subtareas encomendadas y con ello la tarea general asignada al cluster. Un servicio de alta disponibilidad en el cluster normalmente no distribuye la carga de tráfico a los nodos (balanceo de carga) ni comparte la carga de procesamiento (alto rendimiento) sino más bien su función es la de estar preparado para entrar inmediatamente en funcionamiento en caso de que falle algún otro servidor. Características y funcionamiento de alta disponibilidad Sistemas de alta disponibilidad y sistemas tolerantes a fallos Los sistemas tolerantes a fallos son aquellos sistemas que solucionan problemas de fallo del hardware de algún dispositivo, la tolerancia a fallos hace que un sistema pueda detectar y actuar instantáneamente para restablecer el servicio brindado. Los sistemas de alta disponibilidad como ya se vio en el apartado anterior, involucra el tener servidores que actúan entre ellos como respaldos vivos de la información que sirven. Este tipo de clusters se les conoce también como cluster de redundancia.

64 49 SPOF (Single Point of Failure ó Punto Simple de Fallo) SPOF hace referencia a la tenencia de un elemento no replicado que puede estar sujeto a fallos, logrando con esto la suspensión del servicio que se está brindando. Es por ello la importancia de evitar tener un SPOF en los subsistemas del sistema general, ya que con ello se pondría en peligro la prestación continua de servicios del sistema. En sistemas de alta disponibilidad a mas de tener redundancia en sus servidores, es importante tenerla en otros dispositivos que componen el cluster, tal es el caso de dispositivos de interconexión, red de comunicación de servidores; etc. Esto con la finalidad de evitar el tener un SPOF a nivel de subsistemas y sistemas como tal que conforman el cluster que se está implementando. Servicio de Datos El servicio de datos hace referencia al servicio y sus respectivos recursos que se esté brindando a un cliente. En entornos de alta disponibilidad al servicio brindado y al grupo de recursos se denominan logical host o software package. Los recursos que se estén utilizando deben tener mecanismos necesarios que permitan la suplantación y conmutación física entre los nodos cuando uno de estos falle, logrando de esta manera que el servicio de datos ofrecido falle en su funcionamiento. De esta manera la única afección que el sistema tendrá es en el tiempo de conmutación en la puesta en marcha del servicio de datos.

65 50 Dinámica de Alta Disponibilidad Dinámica que hace referencia a las reconfiguraciones que el cluster debe hacer para garantizar la máxima disponibilidad de un determinado sistema; va orientada a los nodos que conforman el cluster y la forma de cómo éste responde. Existen diferentes maneras de cómo el sistema responde ante la presencia de un fallo, entre las cuales se tiene: Tolerancia a fallos (failover). Se da cuando un nodo falla y otro debe asumir sus responsabilidades. Para ello el nodo entrante debe importar los recursos del nodo con fallo y habilitar los servicios de datos. Toma de control o tolerancia a fallos automático (takeover). Se produce cuando el servicio de datos falla y se detecta por un determinado nodo, a este nodo se lo considera nodo fallido y se ve forzado a ceder sus servicios y recursos. En este caso se requiere una monitorización continua del servicio de datos. Tolerancia a fallos manual (switch over o give away). Se caracteriza por ceder los recursos y servicios de datos de un nodo a otro. Se utiliza cuando se realizan tareas de mantenimiento y administración a un nodo. División de cerebros (Split brain). Mecanismo utilizado cuando el proceso de gestión de un cluster HA8 falla. Esta falla se da debido a problemas en la comunicación y verificación de los nodos existentes. Debido a que los nodos no conocen de la existencia de sus vecinos y asumen que son los únicos en el sistema, por tal motivo cada nodo intentará apropiarse de todos los recursos del

66 51 sistema incluyendo el servicio de datos y tener el control total del cluster. El Split brain es un caso especial del failover. Recursos de un Servicio de Datos Al trabajar con un cluster de alta disponibilidad se tienen diferentes tipos de recursos que son fundamentales para su funcionamiento y que se listan a continuación: Recursos Computacionales. Son aquellos que permiten alojar y ejecutar el servicio de datos brindado. Estos recursos se consideran a nivel de CPU y el cluster. En alta disponibilidad se tienen recursos a nivel de cluster dónde cada nodo que lo conforma debe tener una copia en memoria del programa de servicio de datos. Recursos de Comunicaciones. Recursos utilizados para brindar el acceso al servicio de datos mediante una red de comunicaciones. Recursos de Almacenamiento. Son los recursos más críticos en alta disponibilidad. Se debe garantizar la integridad y confiabilidad de los datos almacenados en los discos de los nodos o servidores. La falla de estos dispositivos hace que los datos se corrompan y con ello se tenga efectos irreversibles que afecten el rendimiento del sistema.

67 52 Balanceo de carga (Load balancing) Anteriormente se definió el balanceo de carga como la habilidad que tiene un servicio para distribuir el trabajo entre varias máquinas. Al grupo de servidores que prestan este servicio se los conoce como servidores virtuales. Al balancear la carga se mejora el tiempo de respuesta, acceso y confiabilidad. La caída de un servidor no influye en el funcionamiento de todo el cluster ya que las funciones de éste son asumidas por el resto de servidores virtuales. Cuando la carga de trabajo sea mayor se pueden añadir más servidores al cluster y escalar este sistema para garantizar el balanceo de carga. Existen diferentes métodos de distribución de carga que se detallan a continuación. Balanceo de Carga por Sistema de Nombres de Dominio o DNS Este proceso consiste en crear un dominio DNS al cual se le asigna diferentes direcciones IP pertenecientes a los servidores que están funcionando. A esta configuración no se le considera un cluster debido a que en la caché del explorador de Internet de los clientes se almacena la dirección IP del servidor que en ese momento lo atendió. Los clientes automáticamente redireccionan las peticiones refiriéndose a la dirección del servidor de la caché cuando un nuevo requerimiento se produce. El balanceo de carga no se realiza por completo ya que un servidor puede atender solicitudes de gran procesamiento, mientras otros servidores pueden atender solicitudes

68 53 más sencillas, esto se debe a que carecen de un dispositivo que controle y redireccione equitativamente el trabajo a los servidores, la falta de este dispositivo hace que la repartición de carga no sea equitativa y ello conlleva a tener un desigual funcionamiento de los servidores. Este sistema tiene varios inconvenientes: 1. El primero es que si un servidor cae el DNS 27 no será consciente de ello y el cliente que obtenga la IP 28 del servidor caído como respuesta a su solicitud encontrará que el servicio no está disponible. 2. El segundo inconveniente es que con las caches de DNS se cacheará permanente el nombre del dominio con una IP especifica, con lo cual todas las peticiones irán a esa IP y no habrá balanceo, pudiendo de esta forma estar uno o varios servidores sobrecargados y el resto muy ligeros. Balanceo de Carga mediante un Nodo Director Mecanismo basado en la utilización de un nodo director. El nodo director recibe todas las peticiones de los clientes, balancea la carga y redirecciona a los servidores del cluster. El nodo director redirecciona las peticiones a los nodos que posean menor carga para que atiendan el requerimiento solicitado, una vez procesada la petición los servidores virtuales devuelven el resultado al nodo director para que este entregue los resultados al 27 Léase Definiciones Conceptuales - Sistema de Nombres de Dominio o DNS 28 Léase Definiciones Conceptuales - Internet Protocol

69 54 cliente. Existen variaciones donde los nodos o servidores virtuales pueden entregar el resultado al cliente directamente 29. Gráfico 8: Estructura Balanceo de Carga a través de un Nodo Director Elaboración: Investigadora Fuente: 29 Visitar Sitio Web:

70 55 En el balanceo de carga, el reenvío de paquetes que realiza el nodo director se lo puede realizar de tres formas: Balanceo por NAT (Network Address Traslation).Mecanismo basado en trasladar las direcciones IP origen/destino de los paquetes que llegan al nodo director y los reenvía a uno de los servidores reales disponibles. Luego de que los servidores internos procesan el paquete recibido lo reenvían al nodo director. El único mecanismo para que todos los servidores del cluster puedan salir al Internet es a través del nodo director.

71 56 Gráfico 9: Balanceo por NAT Elaboración: Investigadora Fuente: Balanceo por encapsulado IP. Mecanismo basado en el encapsulamiento IP (IP tunneling). La unidad de datos TCP/IP que llega al nodo director es encapsulada dentro de otra unidad de datos manteniendo las direcciones origen/destino intactas. Esta nueva unidad de datos contiene los datos originales del cliente que

72 57 genera la petición, posee la dirección origen del nodo director y la destino del servidor disponible para atender el requerimiento. Gráfico 10: Balanceo por Encapsulamiento IP Elaboración: Investigadora Fuente: El servidor que atiende el requerimiento desencapsula la unidad de datos que le envió el nodo director. Los servidores virtuales tienen configurada en una de sus interfaces de red la misma dirección pública del nodo director con la finalidad de poder aceptar la unidad de datos original y servir la petición requerida.

73 58 Luego de procesar las peticiones se las reenvía al cliente directamente utilizando la dirección pública del cluster, y así evitar re-enrutar el resultado al nodo director para que este la entregue al cliente que originó la petición. Así se logra evitar un cuello de botella en el nodo director, haciendo más fácil el proceso de atención de peticiones. La distribución de los servidores internos del cluster se lo puede realizar a nivel de una red WAN sin necesidad de tenerlos en un solo segmento de red logrando con ello evitar tener un punto de fallo único en caso de que el segmento quede fuera. Balanceado por enrutamiento directo. Todos los servidores del cluster incluido el nodo director están en un mismo segmento de red físico; a su vez todos los nodos comparten la misma dirección IP pública. En este mecanismo se evita sobrecargar al nodo director con traslación de direcciones IP y evita el realizar encapsulamiento de la unidad de datos recibida. De este modo se evita tener un cuello de botella en el nodo director.

74 59 Gráfico 11: Balanceo por Enrutamiento Directo Elaboración: Investigadora Fuente: Las respuestas del servidor quien atendió el requerimiento se envían de forma directa a los clientes. La configuración de este sistema debe garantizar que los nodos no respondan a comandos ARP 30 para evitar conflictos con otros 30 Léase Definiciones Conceptuales - ARP (AddressResolutionProtocol)

75 60 protocolos, logrando con esto que todos los servidores respondan con la misma IP pero con diferentes direcciones MAC 31. Cuando llega una petición al nodo director decide a que servidor interno enviar dicha petición, este redireccionamiento se realiza a nivel de capa enlace utilizando la dirección MAC del servidor que va atender el requerimiento. Cuando el paquete llega a éste servidor se analiza hasta el nivel de red IP. Debido a que posee la dirección IP pública del cluster acepta el paquete y lo procesa, luego de esto reenvía el resultado al cliente. Planificación del Balanceo de Carga Existen algoritmos que permiten planificar la carga de trabajo que conlleva distribuir las peticiones entre los servidores, entre ellos tenemos: Round Robin. También llamado FIFO (First In FirstOut), proceso en el que el nodo director envía una petición a un determinado servidor del cluster, la siguiente petición se envía al siguiente servidor disponible y así sucesivamente hasta llegar al último servidor disponible, luego del cual se vuelve a enviar al primero. Round Robin ponderado. Su funcionamiento es igual al Round Robin, solo que a cada servidor se le da un indicativo de acuerdo a su capacidad de 31 Ver Glosario Capitulo 1 MAC (Medium Access Control)

76 61 procesamiento, es decir servidores con alta capacidad de procesamiento recibirán mayor carga que los que poseen una menor capacidad. Servidor con menos conexiones activas. Proceso caracterizado por tener un mecanismo continuo de consulta que permite verificar cuántas conexiones activas poseen los servidores que están atendiendo los requerimientos del cliente. Dependiendo del resultado de esta consulta el nodo director direcciona las peticiones a los servidores con menos carga. Este proceso es muy útil cuando todos los servidores poseen una capacidad de procesamiento similar (sistema homogéneo), logrando tener de esta manera un trabajo equilibrado. Servidor con menos conexiones activas ponderado. Este algoritmo consiste en asignar una mayor carga a los servidores con menos conexiones activas pero verificando la capacidad de procesamiento de éstos y dependiendo de esta capacidad asignar una mayor o menor carga a los servidores. Se pondera a los servidores por su capacidad de procesamiento y ese valor se utiliza para la asignación de carga. Menos conectado basado en servicio. Algoritmo caracterizado por dirigir todas las peticiones a un mismo servidor hasta lograr que se sobrecargue, es decir que tenga un gran número de conexiones activas que superen a su capacidad de procesamiento, luego de esto se ejecuta el algoritmo de menos conexiones activas

77 62 ponderadas sobre el resto de servidores del cluster y se pasan las peticiones al servidor con menos conexiones activas analizando el valor ponderado de este; el proceso continua hasta que se satura la capacidad de conexiones activas. Este mecanismo se mantiene de manera sucesiva hasta llegar al último servidor en servicio del cluster. Este algoritmo es muy utilizado cuando se ofrece varios servicios distintos y se quiere especializar a una determinada máquina en un servicio determinado. Todas las máquinas son capaces de reemplazar a cualquiera de los servidores activos cuando uno de estos falle. Tablas hash 32 por origen y destino. Proceso que se basa en la utilización de una tabla de asignaciones fijas la cual contiene las direcciones IP origen y destino, en base a estas se indica qué servidor deberá atender la petición. El nodo director o balanceador compara las direcciones de las tramas TCP/IP que reciba con estas tablas y actúa en consecuencia. Conexiones Persistentes. Mecanismo útil ya que a los algoritmos anteriormente analizados se les puede añadir la condición de que una vez que un cliente se ha conectado con un servidor, siempre las peticiones sele dirija al mismo servidor Ver Glosario Capitulo 1 Tablas Hash 33 Visitar Sitio Web:

78 63 PLANIFICACIÓN Y ADMINISTRACIÓN DE CLUSTERS ADMINISTRACIÓN La administración de clusters requiere de un manejo adecuado de los recursos asociados. Los recursos del cluster deben ser administrados adecuadamente para que el administrador invierta la menor cantidad de tiempo en detectar, investigar y recuperar fallos de hardware y software, y de este modo definir posibles medidas de contingencia y tratar que el sistema esté libre de errores. A su vez, estos pasos permiten la adaptabilidad a los requerimientos y cambios constantes que se presentan en la manipulación de tecnologías cluster, en cuanto se refiere al hardware, software y al uso de ciertos patrones de diseño 34.Dentro de la correcta administración del cluster, implica tomar medidas y planificar tareas, para lo cual se mencionan los siguientes aspectos: Registro de eventos (logging) Falla y Recuperación de Hardware Falla de Software Falla y Recuperación del Sistema de archivos Encolamiento (Queing) Planificación (Scheduling) Monitoreo (Monitoring) Contabilidad (Accounting) 34 Visitar Sitio Web:

79 64 A continuación se va analizar con más detalle las actividades que se deben llevar a cabo en un sistema de administración: Registro de eventos (logging) El registro de eventos es el proceso por el cual todos los aspectos relacionados al funcionamiento de una máquina y operación del cluster se guardan en un archivo de registro (logs) el cual puede ser usado para futuras consultas. El administrador de un sistema Linux tiene a su disposición un programa de generación de registros que monitoriza todos los eventos que se producen en el mismo. Syslog guarda, analiza y procesa todos los archivos de registro sin requerir apenas intervención por parte del administrador. La ubicación del directorio donde se almacenarán los registros depende del servicio instalado, por lo general el directorio donde se almacena es el /var/log 35. Falla y Recuperación de Hardware La administración del cluster implica solucionar problemas provocados por fallos de hardware y/o software. Los fallos causados por hardware pueden ocasionar que el cluster quede inutilizable. La recuperación ante fallos a nivel de hardware implica: 1. Aislar los componentes que fallaron para asegurar que no causen un considerable impacto en las actividades del cluster. 35 Visitar Sitio Web:

80 65 2. Manejar los componentes de respaldo (backup), para poder hacer reemplazos y minimizar los efectos del fallo 36. Falla de Software La falla ocasionada por el software al igual que los fallos a nivel de hardware son críticos debido a que pueden dejar inoperante al cluster, pero a la vez estas fallas involucran otros aspectos que deben ser tomados en cuenta. Las fallas de software muchas veces tienen arreglo, otras veces no, pero es de vital importancia detectarlas, para poder analizar las posibilidades de evitar que vuelvan a ocurrir, por lo general el Linux los errores se los evita con los denominados parches del sistema, los cuales vienen a suplir las fallas del sistema a nivel de software. Falla y Recuperación del Sistema de archivos La falla en un sistema de archivos es muy crítica, se podría decir que es la pérdida que mayor daño ocasionaría a un sistema, ya que se perdería toda la información almacenada por varios meses o años, en especial se perdería los datos de usuario y de las aplicaciones que hacen uso de éste. Por ello es de vital importancia tomar medidas preventivas que logren evitar tener un punto de fallo en el sistema de archivos, teniendo sistemas de archivos redundantes mediante el uso de técnicas como RAID, poseer un sistema de archivos con journaling el 36 Visitar Sitio Web:

81 66 cual permita recuperar rápidamente los datos en caso de existir alguna falla inesperada en el sistema, poseer un sistema de archivos paralelo, con lo cual la pérdida de un servidor de archivos no influya de manera total al funcionamiento general del sistema ya que la existencia de otros servidores de archivos podrían suplir su ausencia. Encolamiento (Queing) Un aspecto importante a tomar en cuenta en la administración de un cluster es el encolamiento (Queing) que consiste en el proceso de acumular los trabajos para que sean ejecutados por el conjunto de recursos disponibles. Las tareas y los trabajos que los usuarios desean realizar, son presentados por el sistema de administración como un conjunto llamado grupo de trabajo. Este grupo de trabajo para ser ejecutado necesita de dos aspectos fundamentales que el sistema debe proveer, en primer lugar proveer los recursos necesario (como la cantidad de memoria o CPU s necesitados), y en segundo lugar una descripción de las tareas a ser ejecutadas (archivo a ejecutar, datos requeridos para procesar cualquier petición; entro otros). El grupo de trabajo luego de presentado al sistema de administración, es colocado en una cola hasta que el sistema provea los recursos necesarios (por ejemplo: la cantidad correcta de memoria y CPU requerido) para procesar cualquier trabajo encomendado. El tiempo de espera para que los trabajos se ejecuten depende exclusivamente del tiempo de ocupación de los recursos.

82 67 Monitoreo (Monitoring) El monitoreo involucra el observar que el rendimiento y funcionamiento del cluster sea correcto. Una operación correcta implica tener a todos los recursos de hardware y software monitoreados y con ello constatar que el funcionamiento sea el esperado 37. Es decir, debe asegurarse que todos los componentes de hardware estén disponibles durante el arranque del sistema operativo (CPUs, memoria, discos, dispositivos de red y otros), y de igual forma, que todos los servicios de software, tales como: planificadores de tareas, administradores de recursos, y demonios de monitoreo se ejecuten correctamente en el cluster 38. Contabilidad (Accounting) Mecanismo utilizado para la recolección de datos de cada grupo de trabajo que se ejecuta en el cluster, el accounting es una herramienta muy importante que permite generar información útil para el proceso de planificación de tareas, esta herramienta puede ser utilizada para varios propósitos tales como: Elaboración semanal de reportes de utilización del sistema. Elaboración de reportes de utilización mensual de recursos por usuario. Elaboración de un cronograma de políticas de planeamiento. Prever requerimientos computacionales futuros. Determinar áreas que deben ser mejoradas dentro del sistema. 37 Visitar Sitio Web: 38 Visitar Sitio Web:

83 68 PLANIFICACIÓN DE TAREAS La planificación de tareas es una actividad de mucha utilidad en la administración de un cluster, ya que permite programar un conjunto de actividades que se ejecutarán de acuerdo al tiempo, necesidad y circunstancia que un determinado sistema así lo requiera. Al hablar de tarea se hace referencia a un programa ejecutable que realiza determinadas funciones. Un proceso consiste en un número de tareas con cierta independencia que se coordinan para cumplir funciones lógicas. Un planificador de tareas debe garantizar tres aspectos fundamentales: Rendimiento. Optimizar la ejecución del número de tareas y procesos. Tiempo de respuesta. Conseguir que el tiempo de ejecución de un determinado proceso sea mínimo. Optimización de CPU. Optimización constante de la carga de proceso de la CPU Visitar Sitio Web:

84 69 HERRAMIENTAS PARA IMPLEMENTAR CLUSTERS DE ALTA DISPONIBILIDAD Y BALANCEO DE CARGA HA OSCAR Introducción a HA OSCAR HA OSCAR es un proyecto de código abierto tiene como objetivo proporcionar una potencia conjunta de alta disponibilidad y rendimiento de la solución informática, tiene sus bases en el desarrollo de OSCAR (Open Source Cluster Application Resources) el cual es un software de paquetes que fue diseñado por el Grupo de Clusters Abiertos (OCG Open Cluster Group), grupo que con el apoyo de otros se ha dedicado a perfeccionar de mejor manera la utilidad de este paquete con la finalidad de aumentar su utilización. HA-OSCAR introduce varias ventajas y nuevas características a OSCAR, principalmente ofreciendo mecanismos de alta disponibilidad para evitar puntos de fallo, escalabilidad, y de seguridad, con lo cual brinda una gran ventaja a los ambientes clustering tales como los de alto rendimiento, balanceo de carga; entre otros. Arquitectura de HA-OSCAR La arquitectura de HA-OSCAR se puede resumir en el siguiente gráfico:

85 70 Gráfico 12: Arquitectura HA OSCAR Elaboración: Investigadora Fuente: Como se puede observar en el gráfico 12, HA-OSCAR posee algunos componentes que se detallan a continuación:

86 71 Servidor primario activo y redundante. Encargados de recibir y distribuir los requerimientos especificados por los clientes. Cada servidor posee tres interfaces de red, una de ellas es utilizada para conectarse a Internet por la cual los clientes saldrán al mundo exterior, las otras dos interfaces son utilizadas para conectarse a la red LAN privada, estas deben conectarse a cada uno de los switchs respectivamente, esto para brindar redundancia encaso de la falla de uno de los servidores primarios, con esta configuración se elimina un punto de falla a nivel de mencionados servidores, entre éstos se tiene configurado un enlace de heartbeat el cual es una técnica de monitorización entre dos o más nodos de un cluster, es decir mediante esta herramienta se puede conocer si un determinado equipo está en funcionamiento o no. Esta funcionalidad va ayudar a determinar si un servidor primario falla y por ende empezar a funcionar el redundante quien debe suplirlas funcionalidades del principal. Este servidor redundante es un servidor de imágenes el cual utiliza estas para construir y restaurar imágenes del servidor primario, así como para generar respaldos en caso de una falla inesperada. Esta arquitectura permite tres modos de configuración entre los servidores primario activo y redundante, a continuación se da una breve explicación de estos: Active-Active. Configuración donde los dos servidores se encuentran activos, con lo cual se puede lograr una mejor utilización de los recursos del cluster, si uno de

87 72 ellos llega a fallar el otro toma el control del sistema existiendo una pérdida de rendimiento y no de corte de servicio. Active-Hot Standby. Configuración donde existe un servidor principal y uno redundante, este es una fiel copia del principal y entra en funcionamiento el momento que detecta que el servidor principal tuvo una falla, el servidor redundante utiliza imágenes del sistema para construir y restaurar el sistema del servidor primario. Active-Cold Standby. Configuración similar a la Active-Hot Standby, con la diferencia que el servidor redundante al momento en el que detecta que el principal ha fallado, entra en funcionamiento sin ningún conocimiento del trabajo que estaba cumpliendo el principal. Clientes. Quienes generan peticiones y requerimientos de cómputo a los servidores primarios. Switches. Equipos de interconectividad encargados de comunicar a clientes y servidores, es importante que exista redundancia en estos equipos para garantizar una alta disponibilidad en todos los componentes que conforman el cluster y con ello evitar la existencia de puntos de fallo.

88 73 LVS (LINUX VIRTUAL SERVER) Introducción a LVS A continuación se enumeran los principales requerimientos que debe tener un sistema de alta disponibilidad para hacer frente a la inminente demanda de conexiones y servicios en Internet: Escalabilidad. Para cuando la demanda de un determinado servicio aumenta, el sistema debe ofrecer la capacidad de ampliarse con la finalidad de atender todas las solicitudes sin que los tiempos de respuesta sean alterados. Alta Disponibilidad. Capacidad del sistema de estar disponible en todo momento, tomando en cuenta de que debe ser un sistema altamente tolerante a fallos. Costos. Uno de los requerimientos fundamentales a la hora de hacer una inversión, los costos de montaje, mantenimiento y expansión del sistema deben ser accesibles en comparación a infraestructuras propietarias 40. Linux Virtual Server (LVS) es un servidor altamente escalable y de alta disponibilidad, construido en base a un cluster de servidores reales. La arquitectura es totalmente transparente para los usuarios finales y estos pueden interactuar con la granja de servidores como si solo existiera un solo servidor de alto rendimiento. Los servidores reales y el balanceador de carga (director) pueden estar conectados por una red LAN de alta velocidad o por una red WAN dispersa (VPN). El director, puede 40 Visitar Sitio Web:

89 74 despachar solicitudes de diferentes servidores y crear servicios paralelos dentro del cluster de manera que sean servicios virtuales asociados a una sola dirección IP, y la respuesta a las solicitudes pueden usar tecnologías de balance de carga anivel de IP o nivel de aplicación. La escalabilidad del sistema se alcanza agregando o removiendo nodos en el cluster. La alta disponibilidad es proporcionada detectando nodos o fallas de demonios y reconfigurando el sistema apropiadamente 41. Mecanismos de Balanceo de Carga Balanceo por NAT Balanceo de carga caracterizado por aprovechar la funcionalidad que presenta el kernel de Linux para hacer que el nodo director tenga un comportamiento de enrutador con NAT (Network Address Traslation); propiamente el nodo director utiliza una extensión del NAT conocida como Traducción de Direcciones de Red y Puerto o NAPT (Network Address Port Translación), esta se caracteriza por usar una sola dirección IP válida con la que los host se conectan desde la red interna hacia el Internet por diferentes puertos. NAPT se basa en el mapeo de direcciones de red y puertos TCP/UDP de los paquetes en otros puertos. NAPT es una técnica que permite que numerosos servicios se ejecuten en distintas direcciones de red y se escuchen en distintos puertos y, a su vez puedan ser trasladados a un único puerto en la dirección de red del servidor virtual para lograr la apariencia de un único 41

90 75 servicio.el funcionamiento de esta técnica de balanceo de carga se resume en el gráfico 13. Gráfico 13: Mecanismo de Balanceo por NAT Elaboración: Investigadora Fuente: El proceso de balanceo de carga se resume en los siguientes pasos:

91 76 1. El cliente genera un requerimiento al nodo director el cual posee una dirección IP pública y es el que da la cara al mundo exterior. 2. El nodo director establece a que servidor real enviar la petición requerida por el cliente utilizando NAPT y reescribe las cabeceras del paquete TCP/IP, modifica los campos de dirección IP y puertos de destino, los suplanta por los correspondientes al servidor real escogido. Cabe recalcar que los servidores reales y el nodo director se encuentran interconectados por una red de alta velocidad mediante un switch o hub. 3. El servidor real escogido recibe la petición, la procesa y envía la respuesta al cliente, pero como en esta configuración los servidores reales tienen como ruta de salida (default gateway) al balanceador de carga, la respuesta se envía a través de éste. 4. El nodo director suplanta nuevamente la dirección IP y puerto de origen de los paquetes TCP/IP con la correspondiente IP pública con la que se generó la petición, y de esta manera la respuesta llega al cliente final. La utilización de esta configuración no requiere de ninguna modificación especial del sistema operativo del cliente, lo cual facilita su uso. El número de servidores reales hasta el que el cluster pueda escalar dependerá del ancho de banda de las conexiones con el balanceador y, de su potencia de cálculo para reescribir los paquetes TCP/IP. De todas formas, un servidor actual no debería tener problemas para tratar con 20 o tal vez más servidores.

92 77 La principal desventaja del balanceo por NAT está en la sobrecarga que tendría el nodo director al tener que reescribir todos los paquetes de datos originados desde y hacia los servidores reales y clientes, problema que se hace notorio cuando el número de peticiones y respuestas es muy grande. Este problema puede disminuirse utilizando un equipo más potente como director. Otra solución a este problema consiste en que los servidores reales envíen los paquetes de datos de salida directamente hacia los clientes sin pasar por el nodo director mediante las técnicas que se describen a continuación. Balanceo por Encapsulado IP Técnica caracterizada por encapsular un datagrama IP dentro de otro, es decir el encapsulado IP consiste en enmascarar una trama TCP/IP, con sus direcciones IP de origen y destino, dentro de otra trama con direcciones distintas, una vez que la trama más externa llegue a su destino, desencapsular la trama original y reenrutarla desde allí. Como requisito principal esta técnica requiere que todos los dispositivos soporten el protocolo IP tunneling o IPSec. El funcionamiento de esta técnica de balanceo de carga se resume en el gráfico 14.

93 78 Gráfico 14: Mecanismo de Balanceo por Encapsulamiento IP Elaboración: Investigadora Fuente: Descripción del proceso: 1. El cliente envía sus requerimientos a la dirección IP pública o virtual VIP, la cual está configurada en el nodo director o balanceador. 2. El balanceador de carga o nodo director recibe las peticiones del cliente, y realiza el proceso de encapsulación, es decir toma los datagramas IP del cliente y los coloca

94 79 dentro de otros datagramas IP que son reenviados hacia los servidores reales, para el reenvío de los paquetes, el nodo director encapsula los datagramas provenientes del cliente los cuales poseen su dirección IP como origen y destino en la dirección IP del balanceador, este procede a encapsular este datagrama dentro de otro con su dirección IP como origen y la dirección IP del servidor real como destino. El trayecto de llegada de los paquetes a los servidores reales puede darse de manera directa cuando están en una misma área o por medio de dispositivos y redes IP intermedias cuando se encuentren en áreas diferentes. 3. Una vez que el paquete llega al servidor real, este debe proceder a desencapsularlo, para ello todos los servidores reales deben tener configurados en una de sus interfaces la IP pública para luego de procesar los requerimientos del cliente responderle de manera directa sin necesidad de hacerlo mediante el nodo director o balanceador, es decir los servidores reales utilizan la ip real como origen y la del cliente como destino. Con esta técnica se evita que el balanceador sea un cuello de botella haciendo que sólo los paquetes de entrada al cluster pasen a través de él, mientras que los de salida los enviará cada servidor real directamente a su destino. Este método de balanceo de carga posee problemas debido a que tanto el nodo director como los servidores reales poseen en una de sus interfaces la misma IP pública configurada. En configuraciones donde los servidores reales y el nodo director están en la misma red, existen inconvenientes en el momento en que llega una petición a la dirección

95 80 IP pública del sistema. Los servidores reales y el director responderían a requerimientos ARP (AddressResolutionProtocol), creando un conflicto interno y haciendo que los paquetes sean enviados tanto al director como a los servidores reales, difiriendo el propósito del mismo, el propósito de éste método se refiere a que al nodo director o balanceador le lleguen todas las peticiones y sea este quien responda a los requerimientos ARP y redireccionarlas a los servidores reales. Para ello se debe lograr que los servidores reales que se encuentran en la misma red del nodo director no respondan a requerimientos ARP y, procesar los paquetes destinados a la IP pública de manera local, ello se logra ocultando las interfaces donde se tiene configurada la IP pública, proceso que se detallará más adelante. La tecnología de balanceo de carga por IP tunneling posee una escalabilidad mayor que la que presenta el balanceo basado por NAT, éste permitirá escalar hasta un mayor número de servidores, 100 o más, con la condición de que todos soporten encapsulado IP (IP tunneling). Una de las ventajas de esta tecnología es que posibilita distribuir los servidores reales a lo largo de una red de área amplia en lugar de tenerlos todos en un mismo segmento de red local. Balanceo por enrutamiento directo Mecanismo de balanceo de carga, caracterizado por utilizar una red LAN con sus respectivos dispositivos de interconexión como un Switch/Hub para la interconexión entre el nodo director y los servidores reales, La característica de este método radica en que los servidores reales poseen configurado en el interfaz de red local, la dirección IP

96 81 real del nodo director, pero como en el caso de balanceo por encapsulamiento IP deben estar configuradas para que no respondan a mensajes del protocolo ARP. El funcionamiento de este método se resume en la gráfica 15. Gráfico 15: Mecanismo de Balanceo por Enrutamiento Directo Elaboración: Investigadora Fuente: Descripción de la figura:

97 82 1. Como se puede observar el nodo director es quien recibe las peticiones desde los clientes que están en el Internet hacia la dirección IP pública configurada en una de sus interfaces. 2. Todos los equipos tienen configurado en una de sus interfaces la IP pública del cluster y, tomando en cuenta que el balanceador siempre la usará para el acceso a Internet y, será el punto de entrada al cluster. El resto de equipos se conectan al balanceador en la misma red física y en el interfaz conectado a esta red tendrá configurada la IP pública del cluster, el cual no responde a comandos ARP (todos los equipos responderían por la misma IP con distintas MACs). Cuando llega una petición al balanceador éste decide a qué servidor enviársela, y redirige el paquete a nivel de capa enlace a la dirección MAC del servidor real elegido, en lugar de modificar o encapsular el paquete TCP/IP. 3. Una vez recibido el paquete TCP/IP enviado por el nodo director hacia el servidor real elegido, este lo analiza hasta el nivel de red, acepta el paquete y genera la respuesta que enviará directamente al cliente sin necesidad de reenviársela al nodo director, evitando la sobrecarga que se tenía en la técnica de encapsulado. Este método no es aplicable para todos los interfaces, esto se debe a que varios fabricantes de interfaces de red no proveen soporte para deshabilitar el protocolo ARP. Al realizar el reenrutamiento a nivel de capa enlace, se imposibilita tener el cluster

98 83 disperso en áreas geográficas extensas, y requiere que los componentes del cluster se encuentren el mismo segmento físico 42. Planificación del algoritmo de balanceo de carga Al momento de configurar el balanceo de carga, se puede escoger entre una serie de algoritmos que permitirá distribuir la carga de trabajo entre los servidores, además de la forma en que se enviara las peticiones a cada uno de ellos. RoundRobin También llamado FIFO (First Input First Output), proceso por el cual el nodo director envía una petición al primer servidor del cluster, la siguiente petición se envía al siguiente servidor disponible y así sucesivamente, hasta llegar al último servidor disponible, luego del cual se vuelve a enviar al primero. Este mecanismo es el más sencillo de todos pero no el más justo ya que se puede dar el caso en el que toda la carga pesada vaya a un determinado servidor, mientras que el resto recibe peticiones más sencillas. Round Robin Ponderado Algoritmo cuyo funcionamiento es igual al Round Robin, con la diferencia que a cada servidor se le da un indicativo de acuerdo a su potencia de cálculo; es decir servidores con alta potencia de cálculo recibirán mayor carga que los que poseen una potencia 42 Visitar Sitio Web:

99 84 menor. Pero este método también tiene la desventaja de que los servidores más capaces reciban más carga y con ello llegar a saturarlos. Servidor con menos conexiones activas Proceso caracterizado por tener un mecanismo continuo de consulta acerca de cuántas conexiones activas poseen los servidores que están atendiendo los requerimientos del cliente, dependiendo de esta consulta el nodo director direcciona las peticiones a los servidores con menos cargas. Pero este proceso es muy útil cuando todos los servidores poseen una potencia de cálculo similar, logrando tener de esta manera un trabajo equilibrado. El inconveniente surge cuando la potencia de los servidores no es la misma en todos, en este ámbito los servidores más rápidos recibirán un mayor número de conexiones activas, así como conexiones en espera, los servidores más lentos tendrán un número menor de conexiones activas y en espera, lo cual ocasiona que el nodo director envíe más carga a estos servidores por el hecho de tener pocas conexiones y con ello se logra que éstos lleguen a saturarse. Servidor con menos conexiones activas (ponderado) Algoritmo que basa su funcionamiento de acuerdo al menor número de conexiones activas y de un determinado indicativo que se le da a los servidores en base a su capacidad de cálculo. Este proceso consiste en asignar una mayor carga a los servidores

100 85 con menos conexiones activas pero verificando la capacidad de cálculo de éstos, y dependiendo de esta capacidad asignar una mayor o menor carga a los servidores. Menos conectado basado en servicio Algoritmo caracterizado por dirigir todas las peticiones a un mismo servidor hasta lograr que se sobrecargue, es decir que tenga un gran número de conexiones activas que superen a su potencia de cálculo, luego de esto se ejecuta el algoritmo de menos conexiones activas ponderadas sobre el resto de servidores del cluster, con ello se pasan las peticiones al servidor con menos conexiones activas analizando previamente la potencia de cálculo, el proceso continua hasta saturar la capacidad de conexiones activas. Este mecanismo se mantiene de manera sucesiva hasta llegar al último servidor en servicio del cluster. Este algoritmo es muy utilizado cuando se ofrece varios servicios distintos y se quiere especializar a una determinada máquina en un servicio determinado, cabe recalcar que todas las máquinas son capaces de reemplazar a cualquiera de los servidores activos cuando uno de estos falle. Tablas hash por origen y destino Métodos que dispone de una tabla de asignaciones fijas, en las que por medio de la dirección IP de origen o de destino, se indica qué servidor deberá atender la petición. El balanceador compara las direcciones de las tramas TCP/IP que reciba con estas tablas y actúa en consecuencia.

101 86 Conexiones persistentes Algoritmo muy útil, que basándose en los ya analizados se puede añadir que, una vez que un cliente se haya conectado a un determinado servidor siempre el nodo director le dirija al mismo, logrando con esto tener conexiones persistentes útiles cuando se requiere mantener conexiones activas a una determinada aplicación. Alta Disponibilidad en LVS Heartbeat Heartbeat es una herramienta Open Source para la gestión de clusters de alta disponibilidad sobre entorno LINUX 43. El software heartbeat trabaja enviando latidos (ping), los cuales verifican si el Server principal está activo o no, estos pings enviados por heartbeat requieren una respuesta por parte del Server principal o máster, si al cabo de un cierto tiempo el Server no responde dichos ping, heartbeat determina que ese Server se encuentra inactivo /caído, y automáticamente activa al Server secundario para que asuma el control de la red 44. Heartbeat tiene 2 modos principales a nivel de uso y configuración, el primero es compatible tanto para la versión 1 de Heartbeat como a la 2. Es un modo más sencillo y simple y su configuración está basada en archivos de texto, la cual es llamada versión 1 debido a que solo trabaja en este modo. 43 Visitar Sitio Web: 44 Visitar Sitio Web:

102 87 El otro modo al que llamaremos CRM solo es compatible con la versión 2 y es mucho más potente, contempla una configuración a través de ficheros XML más compleja, y con muchas más posibilidades 45. Esta herramienta ofrece alta disponibilidad y basa su funcionamiento de acuerdo a la combinación de varias herramientas agrupadas de la siguiente manera: mon+heartbeat+fake+coda. Alta disponibilidad producida por la combinación de varios productos basados en software, estos son: mon. Recurso útil para monitorizar los servicios del sistema tanto en los nodos directores principal y de respaldo, así como en los servidores reales, esto con la finalidad de brindar alta disponibilidad de los servicios todo el tiempo. Heartbeat. Técnica de monitorización entre dos o más nodos de un cluster, es decir mediante esta herramienta se puede conocer si un determinado equipo está en funcionamiento o no. Fake. Mecanismo de suplantación de identidad que se activa el momento que un equipo ha caído, es decir por medio de fake, se puede suplantar la identidad de otro tomando su dirección IP y evitar con esto poseer puntos de falla dentro de un sistema. Coda. Sistema de archivos distribuido redundante, tolerante a fallas. 45 Visitar Sitio Web:

103 88 La gráfica 16 mostrada a continuación, resume el proceso de alta disponibilidad que ofrece los mecanismos mon+heartbeat+fake+coda dentro del cluster: Gráfico 16: Alta Disponibilidad de mon+heartbeat+fake+coda Elaboración: Investigadora Fuente:

104 89 El proceso de estos mecanismos tiene tres etapas y se resume de la siguiente manera: Balanceador de Carga.- Como se vio en anteriores ocasiones, es quien da la cara al mundo exterior y quien recibe las peticiones del cliente, su funcionalidad es de vital importancia, ya que si queda inoperante, el cluster quedaría fuera de servicio, es por ello que para evitar tener un punto de fallo, este balanceador debe tener un respaldo, el cual debe tener la misma configuración del balanceador principal y con ello garantizar alta disponibilidad. Estos dos balanceadores (nodos directores) deben monitorizar su funcionamiento de manera dual mediante el uso de mon para ver el estado de los servicios y usan la herramienta heartbeat mediante mensajes UDP heartbeat para verificar el funcionamiento de ambos, en caso de que exista un fallo en el nodo principal se utilizará fake para suplantar su identidad, es decir toma el nodo de respaldo la dirección IP principal y con ello el control de todo el cluster. Servidores Reales.- La segunda etapa es la de los servidores reales, la alta disponibilidad se logra mediante el monitoreo que hace el nodo director o balanceador utilizando mon, este proceso se realiza a nivel de máquina utilizando el demonio fping.monitor y a nivel de servicio utilizando el demonio que depende del servicio que se esté monitoreando, como ejemplo http.monitor para ver el estado del servicio http, ftp.monitor, para ver el estado de el servicio ftp; y así con el resto de servicios que el balanceador o nodo director está monitoreando.

105 90 En caso de que los servicios de los servidores reales no den respuesta al censado que el nodo director realiza, se genera una alarma que está previamente programada y cuya función es notificar al nodo director de que un determinado servidor no está operando adecuadamente y con ello debe añadir una regla en las tablas de LVS indicando que mencionado servidor esta fuera de servicio y que no se debe redireccionar las peticiones del cliente hasta el momento en que se encuentre operativo nuevamente y sea reingresado al cluster. Servidores de Archivo.- La tercera etapa consiste en tener un sistema de ficheros distribuido CODA, el cual puede estar montado en varios servidores con la finalidad de tener alta disponibilidad ante cualquier fallo que pudiera ocurrir. Una consideración importante que hay que tener en cuenta, es que se debe proporcionar una alta disponibilidad en los equipos de interconectividad como routers y switch ya que si estos son un punto de fallo dejarían fuera todo el cluster y con ello la disponibilidad de este 46. Ldirectord+Heartbeat Alta disponibilidad similar al tema tratado anteriormente, se diferencia del mismo debido a que la monitorización se realiza a través de ldirectord y no por medio de mon, la función de este consiste en: 46 Visitar Sitio Web:

106 91 ldirectord (Linux Director Daemon) Escrito por Jacob Rief, es un demonio que controla los servicios de servidores reales, las funciones de ldirectord son similares a las que realiza mon, con la diferencia de que únicamente permite monitorear servicios http y https y no cualquier servicio como si lo permite mon. Es fácil de instalar y funciona con heartbeat. La última versión de ldirectord se puede encontrar en el repositorio CVS de heartbeat 47. El funcionamiento de ldirectord se caracteriza por que este demonio lee directamente los archivos de configuración de LVS, y por ende modificar las tablas de enrutamiento IPVS en caso de que exista algún problema, eliminando el servidor real que posea inconvenientes y evitar reenviar a éste peticiones del cliente. Ldirectord tiene un buen funcionamiento con heartbeat, ya que puede ser iniciado fácilmente cuando el caso amerite. En la gráfica17 mostrada a continuación se resume el funcionamiento de este método de alta disponibilidad. 47 Traducción de Sitio Web:

107 92 Gráfico 17: Alta disponibilidad con Ldirectord+Heartbeat Elaboración: Investigadora Fuente: Como se puede observar la diferencia con el otro mecanismo de alta disponibilidad radica en la monitorización de servicios, en este caso se realiza con ldirectord, el resto de

108 93 demonios como fake, heartbeat cumplen la misma función que se especifico en el apartado anterior, de igual manera se puede tener un sistema de archivos CODA distribuido tolerante a fallas para garantizar alta disponibilidad en los servidores de archivos. Ipvsadm Herramienta de mucha utilidad para realizar la configuración de servidores virtuales y nodo director, con ipvsadm se modifican los parámetros de funcionamiento del software ejecutado en el kernel de los servidores y que se lo realiza mediante el intérprete de comandos o utilizando un script en el que se detallan un conjunto de órdenes a ejecutarse. La herramienta ipvsadm permitirá especificar las siguientes actividades útiles para la configuración de servidores: Añadir servicios y servidores. Quitar servicios. Mecanismos de planificación Asignación de pesos a los servidores. Especificar servicios y servidores los cuales serán gestionados por el servidor. Para realizar la configuración del sistema, mediante la utilización de scripts permite realizarlo. Este script obtiene toda información necesaria para realizar la configuración del cluster, provee mecanismos para la inicialización de LVS, en el cual se configura las

109 94 IP de las máquinas que pasan por el nodo director, también incluye los programas y archivos de configuración necesarios para especificar parámetros de funcionamiento del cluster tales como mecanismos de balanceo de carga, técnicas de distribución de carga; entre otras. Este archivo sirve de mucha ayuda para no tener que realizar la configuración de manera manual. El utilizar el script configure va facilitar el proceso de configuración de los servidores virtuales para LVS, pero previamente se debe tener los módulos necesarios para poder ejecutarlo. Otra manera de realizar la configuración mediante ipvsadm es por medio de comandos, los cuales para poder ejecutarse requiere de un conjunto de parámetros y datos específicos. Piranha Paquete cuyo propietario es Red Hat. Inc, el cual incluye un conjunto de herramientas útiles para implementar un cluster de alta disponibilidad y balanceo de carga. Basa su funcionamiento en LVS y otros programas de propiedad de Red Hat. Piranha ofrece las siguientes herramientas: El parche IPVS para el kernel de Linux, herramienta de mucha utilidad para hacer el balanceo de carga. Cabe mencionar que para esto piranha tiene la capacidad de añadir

110 95 pesos a los servidores virtuales, los cuales se asignan basándose en la capacidad de cálculo de cada servidor real. El demonio lvs, quien controla las tablas IPVS, las cuales se las puede administrar bajo la herramienta ipvsadm, herramienta web que permite la administración remota de sistemas y servidores. El demonio nanny para monitorizar todos los servicios y servidores reales que pertenecen al cluster, este proceso de monitorización se debe realizar de la siguiente manera: primeramente se debe verificar si están operativas las tarjetas de red y del segmento de red, luego de ello el demonio trata de verificar conectividad con el servidor que está siendo monitoreado; luego de constatar la actividad del servidor real, se envía una petición sencilla al puerto del protocolo que se monitorea y este debe responder de manera correcta. En caso de que un servidor no responda o su respuesta no sea correcta durante varios censados, el demonio nanny lo elimina de las tablas de IPVS para así quitar al servidor caído del cluster y evitar enviarle requerimientos por parte del cliente. Este equipo con problemas continua censándose de manera periódica, de manera que el momento en que se encuentra completamente operativo vuelva a ser reinsertado al cluster de manera automática.

111 96 El demonio pulse encargado de verificar el estado de todos los demonios del cluster y la puesta en funcionamiento del nodo director o balanceador de carga de respaldo encaso de fallo del primario. Este proceso consiste en utilizar mensajes heartbeat de tipo UDP entre el nodo director y el nodo de respaldo, cabe recalcar que los dos deben mantener la misma configuración, si el nodo principal falla, el secundario suplanta su dirección IP y toma su lugar. En caso de restablecerse el nodo que ha fallado, este detecta que han tomado su lugar y adopta el comportamiento de nodo de respaldo hasta que el nodo principal que tomo su lugar falle, luego de esto vuelve a realizarse el mismo proceso. Otro componente de mucha importancia es la interfaz gráfica piranha la cual permite administrar el cluster. UltraMonkey Es una herramienta libre muy útil, rápida y fácil de instalar, muy utilizada para montar cluster de servidores web, es una herramienta completa ya que trae en su propio kernel los parches para mon, heartbeat, fake, parches que como se indicó en los puntos anteriores periten tener un sistema de alta disponibilidad en un cluster deservidores. También para garantizar el balanceo de carga utiliza la herramienta proveniente de LVS llamada Ipvsadm. Ultra Money permite configurar una alta disponibilidad para un cluster en diferentes niveles:

112 97 Alta Disponibilidad simple.- Sistema que carece de un nodo director o balanceador, la alta disponibilidad se da únicamente en base al monitoreo realizado por mon y heartbeat. Alta Disponibilidad simple con balanceo de carga.- La alta disponibilidad se la garantiza con ldirectord y heartbeat y el balanceo de carga se lo realiza basado en Ipvsadm añadiendo un nodo director o balanceador, el mismo que se presenta al usuario y redirecciona las peticiones a los servidores reales utilizando el método de servidores virtuales basados en NAT. Alta disponibilidad con balanceo de carga.- Funcionamiento similar al ítem anterior, con la novedad de que el nodo director o balanceador tiene un equipo de respaldo el cual entra en funcionamiento en caso de que el principal falle, este proceso lo realiza utilizando el demonio fake con lo cual puede suplantar su identidad. Balanceo de carga, alta disponibilidad y alta capacidad.- El balanceo de carga y la alta disponibilidad se garantizan con el ítem anterior, la alta capacidad se logra cuando los servidores reales reciben las peticiones del balanceador y las respuestas la envían directamente al cliente sin necesidad de hacerlo por medio del balanceador, esto conlleva a optimizar el ancho de banda y a evitar cuellos de botella en el nodo director o balanceador, esto se logra utilizando técnicas de servidores virtudes basados en tunneling o basados en enrutamiento directo.

113 98 Como se puede observar, esta herramienta es completa, ya que trae herramientas para garantizar balanceo de carga y alta disponibilidad, pero la única desventaja está en que no posee una herramienta gráfica para administrar y configurar el cluster. HERRAMIENTAS PARA LA ADMINISTRACIÓN DE CLUSTERS GANGLIA Ganglia es un software que permite realizar un monitoreo en tiempo real para clusters, y ha sido utilizado en ambientes universitarios, gubernamentales e implementaciones en áreas comerciales. El monitoreo realizado con Ganglia es el mismo cuando se trata de pocos nodos o cuando se tiene un número mayor de estos 48. Ganglia es un sistema distribuido escalable de seguimiento de los sistemas de computación de alto rendimiento como los clusters y Grids. Se basa en un diseño jerárquico dirigido a las federaciones de agrupaciones. Se aprovecha ampliamente utilizado tecnologías como XML para la representación de datos, XDR para el transporte compacto y portátil de datos, y RRDtool para almacenamiento de datos y visualización. Utiliza cuidadosamente diseñado estructuras de datos y algoritmos a un nivel muy bajo por nodo y de alta concurrencia. La aplicación es robusta, ha sido adaptada a un amplio conjunto de sistemas operativos y arquitecturas de procesadores, y está actualmente en uso en miles de grupos en todo el mundo. Se ha utilizado para conectar entre grupos en 48 Visitar Sitio Web:

114 99 los campus universitarios y en todo el mundo y puede escalarse para manejar grupos con 2000 nodos. Ganglios es una licencia BSD de código abierto del proyecto que surgió de la Universidad de California, Berkeley Proyecto del Milenio, que fue financiado inicialmente en gran parte por la Asociación Nacional de Infraestructura Computacional Avanzada (NPACI) y la Fundación Nacional de Ciencias de RI Premio EIA La última versión de Ganglia (Versión 2.5) publicada en Enero de 2002, se desarrolló bajo el modelo cliente-servidor y está compuesta de cuatro partes fundamentales, que a continuación se describen: En marzo del 2010, aparece la versión de ganglia; la misma que está basada en el modelo cliente-servidor y está compuesta por lo siguiente: gmond: Demonio multi-hilo37 utilizado para monitoreo, el cual se ejecuta en cada uno de los nodos del cluster que se quiere monitorear. gmetad: Demonio utilizado para la recolección de datos, es instalado en el nodo de administración, su función es la de recolectar la información vía XML que los nodos monitoreados le envían en intervalos regulares de tiempo, gmetad recoge toda la información y la guarda en una base de datos Round- Robin Visitar Sitio Web: 50 Léase Definiciones Conceptuales - Base de Datos Round Robin

115 100 Esta base de datos que no crece en el tiempo y permite crear gráficas para representar la información almacenada. Es importante mencionar que el demonio gmetad se encarga de concatenar los datos XML proporcionados por el cliente, esto con la finalidad de compartir esta información con el servidor Web u otro frontend que este ejecutando el demonio gmetad. PHP web frontend: Es el demonio encargado de mostrar la información en una página Web dinámica en tiempo real, la cual actualiza su información durante un intervalo de tiempo determinado. Ganglia se muestra como una interfaz html, pero se debe hacer notar que presenta información de tipo XML, este demonio presenta datos (CPU, memoria, velocidad de CPU s; entre otros) de los nodos del cluster en tiempo real y de manera gráfica. gmetric: Demonio que permite monitorear a un determinado equipo de acuerdo a métricas establecidas, ya sean estas número de procesadores, memoria de CPU; entre otras gstat: Provee un medio de comunicación para realizar consultas al demonio gmond, y permite crear reportes del estado del cluster. libganglia: Las bibliotecas compartidas Ganglia Shared Libraries, contiene bibliotecas comunes necesarias paragmond y para los paquetes gmetad. Otro demonio que es impotente es el croad, el cual permite especificar la realización de una determinada tarea a cierta hora y día que se determine.

116 101 El comando gmetric trabaja en conjunto con el demonio crond, permitiendo realizar un itinerario de tareas; es decir, realizar tareas a cierta hora en un día determinado. Ganglia provee un ambiente de ejecución único mediante la utilización del comando gexec, emplea el uso de 3 hilos de ejecución, uno para las entradas estándar (stdin), uno para las señales del sistema, y otro para las entradas y salidas de error (stderr). gexec permite ejecutar comandos en el cluster de manera transparente y redireccionar las salidas por medio de las entradas y salidas estándar (stdin, stdout y stderr). WEBMIN Webmin es un sistema utilizado para la configuración, administración y monitorización remota de sistemas y servidores. Es una herramienta web que presenta la información en formato HTML en cualquier navegador que se esté utilizando, esto es posible debido a que el propio webmin posee un servidor web pequeño el cual presenta al administrador un menú con una serie de configuradores y monitores para los diferentes programas y servicios que se estén ofreciendo en el sistema. Estos configuradores son representados en forma de un script CGI 51 el cual es un método para permitir la interacción de programas ejecutables entre el cliente y el servidor. Un script CGI es ejecutado en tiempo real, lo que permite manipular la información de forma dinámica. Por ejemplo, se quiere conectar bases de datos al World Wide Web para permitir que las personas de cualquier parte la manipulen. 51 Léase Definiciones Conceptuales - GCI (Common Gateway Interface)

117 102 La instalación de esta herramienta de monitoreo y configuración es sencilla, sus configuradores y su servidor Web están escritos en Perl 52, siendo el único requisito para su funcionamiento la utilidad de sus paquetes y librerías; por defecto webmin se comunica a través del puerto TCP 10000, y puede ser configurado para usar SSL 53 si OpenSSL 54 está instalado con módulos de Perl adicionales requeridos 55. Webmin es un software de mucha utilidad, permite monitorear servicios tales como el Web, SMTP, DNS; entre otros, los cuales se monitorean por defecto al momento de instalar Webmin, pero esta herramienta permite añadir nuevos configuradores para que sean monitoreados y configurados, como es el caso de un cluster LVS. Luego de la instalación completa de esta herramienta, se pueden administrar y monitorear las partes más comunes del sistema operativo, tales como: Crear borrar usuarios y grupos de ellos, ver qué procesos se están ejecutando, programar trabajos a un tiempo determinado, asignar cuotas de disco, reiniciar o apagar el equipo; entre otros. También se pude tener el control de servidores de DNS, Apache, SSH, Squid Proxy, Samba, MySQL; entre otros. La configuración de servicios de red es algo que también se puede controlar bajo esta herramienta, la administración de los servicios de red, la configuración de las interfaces, las direcciones IP; son algunas acciones que se pueden 52 Léase Definiciones Conceptuales - Perl 53 Léase Definiciones Conceptuales - SSL 54 Léase Definiciones Conceptuales - OpenSSL 55 Visitar Sitio Web:

118 103 realizar. Webmin también permite administrar el hardware del servidor, trae una opción para monitoreo y configuración de un cluster, para el cual se debe instalar los configuradores respectivos 56. CONGA Red HatCluster Suite proporciona una variedad de herramientas para configurar y administrar su cluster de Red Hat. Esta sección proporciona un resumen de las herramientas de administración disponibles con Red HatCluster Suite: Conga es un conjunto integrado de componentes de software que proporciona tareas de configuración y administración centralizada para los cluster y el almacenamiento de Red Hat. Conga ofrece las siguientes funcionalidades: Interfaz de web para administrar cluster y almacenaje Implementación automatizada de los datos del cluster y paquetes de soporte Integración fácil con los cluster existentes No hay necesidad de re-autenticación Integración de los registros y estado del cluster Control detallado sobre los permisos de usuarios Los componentes primarios de Conga son luci y ricci, los cuales pueden ser instalados por separado. 56 Visitar Sitio Web:

119 104 luci es un servidor que se ejecuta en un computador y se comunica con varios cluster y computadores a través de ricci. ricci es un agente que se ejecuta en cada computador (ya sea un miembro de un cluster o un computador independiente) administrado por Conga. Se puede acceder a luci a través de un navegador de Web. Este proporciona tres funcionalidades principales a las cuales se puede acceder a través de las siguientes pestañas: Homebase.- Proporciona herramientas para añadir y borrar computadores, añadir y borrar usuarios y configurar privilegios de usuarios. Sólo un administrador de sistema puede acceder a esta pestaña. Cluster.- Proporciona herramientas para crear y configurar los cluster. Cada instancia de luci lista los cluster que han sido establecidos con esa instancia de luci. Un administrador de sistema puede administrar todos los cluster listados en esta pestaña. Otros usuarios pueden administrar solo los cluster a los cuales tiene permiso de administrar (otorgados por el administrador). Storage.- proporciona herramientas para la administración remota del almacenamiento. Con las herramientas en esta pestaña, usted puede administrar el almacenaje en computadores (sin importar si estos pertenecen o no al cluster).

120 105 Para administrar un cluster o almacenaje, un administrador añade (o registra) un cluster o un computador a un servidor luci. Cuando un cluster o computador es registrado con luci, el nombre de host del nombre de dominio completamente calificado o la dirección IP de cada computador se almacena en la base de datos luci. Puede poblar la base de datos de una instancia de luci desde otra instancia de luci. Esta funcionalidad proporciona un medio de replicar a un servidor luci y proporciona una ruta de prueba y actualización eficiente. Cuando instala una instancia de luci, la base de datos está vacía. Sin embargo, usted puede importar parte o toda la base de datos luci de un servidor luci existente al implementar un nuevo servidor luci. Cada instancia de luci tiene un usuario durante la instalación inicial el cual es admin. Solo el usuario admin puede añadir sistemas al servidor luci. Asimismo, el usuario de administración puede crear cuentas de usuario adicionales y determinar cuáles usuarios pueden tener acceso a los cluster y servidores registrados en la base de datos de luci. Es posible importar varios usuarios, cluster y computadores en una sola operación en un nuevo servidor luci. Cuando un computador se añade al servidor luci para que este sea administrado, la autenticación se realiza una sola vez. No hay necesidad de realizar más autenticaciones (a menos que el certificado utilizado sea revocado por un CA). Después de esto, puede configurar y administrar cluster y almacenamiento de forma remota a través de la interfaz de usuario luci. luci y ricci se comunican usando XML.

121 106 FUNDAMENTACIÓN LEGAL Dentro del marco legal, se establecen leyes; que respaldan la viabilidad del tema propuesto. DECRETO EJECUTIVO No RAFAEL CORREA DELGADO EL PRESIDENTE DE LA REPÚBLICA CONSIDERANDO: Que en el apartado g) del numeral 6 de la Carta Iberoamericana de Gobierno Electrónico, aprobada por el IX Conferencia Iberoamericana de Ministros de Administración Pública y Reforma del Estado, realizada en Chile el 1 de Junio de 2007, se recomienda el uso de estándares abiertos y software libre, como herramientas informáticas; Que es el interés del Gobierno alcanzar soberanía y autonomía tecnológica, así como un significativo ahorro de recursos públicos y que el Software Libre es en muchas instancias un instrumento para alcanzar estos objetivos; Que el 18 de Julio del 2007 se creó e incorporó a la estructura orgánica de la Presidencia de la República la Subsecretaría de Informática, dependiente de la Secretaría General de la Administración, mediante Acuerdo No. 119 publicado en el Registro Oficial No. 139 de 1 de Agosto del 2007;

122 107 Que el numeral 1 del artículo 6 del Acuerdo No. 119, faculta a la Subsecretaría de Informática a elaborar y ejecutar planes, programas, proyectos, estrategias, políticas, proyectos de leyes y reglamentos para el uso de Software Libre en las dependencias del gobierno central; y, En ejercicio de la atribución que le confiere el numeral 9 del artículo 171 de la Constitución Política de la República; DECRETA: Articulo 2.- Se entiende por Software Libre, a los programas de computación que se pueden utilizar y distribuir sin restricción alguna, que permitan su acceso a los códigos fuentes y que sus aplicaciones puedan ser mejoradas. Estos programas de computación tienen las siguientes libertades: Utilización del programa con cualquier propósito de uso común. Distribución de copias sin restricción alguna. Estudio y modificación del programa (Requisito: código fuente disponible). Publicación del programa mejorado (Requisito: código fuente disponible).

123 108 HIPÓTESIS PREGUNTAS A CONTESTARSE Permitirá la infraestructura tecnológica existente en la Carrera de Ingeniería en Sistemas Computacionales, soportar los requerimientos del cluster. Existirá una solución que permita la implementación del prototipo del cluster de acuerdo a lo establecido en el contexto del proyecto. Permitirá ofrecer un nivel de confianza optimo, ante la falla de algún nodo que conforme el sistema. Gestionara la ejecución de peticiones una vez que sufra un colapso algún nodo en particular. Variable Dependiente VARIABLES DE LA INVESTIGACIÓN Demanda de acceso web que atraviesa la carrera de ingeniería en sistemas computacionales y el balanceo de carga de los servicios. La demanda web hace referencia al crecimiento de usuarios, que generan requerimientos para satisfacer una necesidad específica. Variable Independiente Diseño de un diseño y desarrollo de un prototipo de un cluster en Linux de alta disponibilidad, permitiendo balancear la carga de los servicios.

124 109 DEFINICIONES CONCEPTUALES Es una interfaz de programación de aplicaciones implementada por un API programa de software que le permite interactuar con otro software. Se facilita la interacción entre los diferentes programas de software de forma similar a la interfaz de usuario facilita la interacción entre humanos y computadoras. ARP Address Resolution Protocol. Protocolo de capa enlace del modelo ISO/OSI para determinar la dirección MAC. Es una placa de circuito (por lo general, una placa de circuito impreso) Backplane que conecta varios conectores en paralelo uno con otro, de tal modo que cada pin de un conector esté conectado al mismo pin relativo del resto de conectores, formando un bus de ordenador. Es una base de datos circular, la cual va a contener siempre la misma cantidad de datos, debido a que tiene almacenada toda la extensión de la base de datos, simplemente sobrescribe los datos antiguos. Una manera Base de Datos Round Robin más sencilla de entender este tipo de base de datos es tener un circulo en el que se van a ir colocando datos. Si se empieza por colocarlos en un determinado punto, cuando se haya dado una vuelta a todo el círculo, se llega al inicio del mismo, y es ahí cuando se empieza sobrescribir los datos recopilados al principio.

125 110 Common Gateway Interface. Interfaz de entrada común. Es una importante tecnología de la World Wide Web que permite a un cliente (navegador web) solicitar datos de un programa ejecutado en un CGI servidor web. CGI especifica un estándar para transferir datos entre el cliente y el programa. Siendo un mecanismo de comunicación entre el servidor web y una aplicación externa cuyo resultado final de la ejecución son objetos MIME. Las aplicaciones que se ejecutan en el servidor reciben el nombre de CGIs. FQDN Fully Qualified Domain Name. Nombre que incluye el nombre de la computadora y el nombre de dominio asociado a ese equipo. Internet Protocol. Protocolo de comunicaciones de la capa red de la IP arquitectura TCP/IP. Es un protocolo no orientado a conexión, no confiable; es decir no garantiza la comunicación entre los extremos. ISP SMP Internet ServiceProvide.. Proveedor de Servicios de Internet Symmetric Multi-Processing)-multiprocesosimétrico Se trata de un tipo de arquitectura de ordenadores en que dos o más procesadores comparten una única memoria central. MPI Biblioteca de comunicaciones en general que permite a los programas paralelos para ser escrito en C, Fortran, Python, OCaml, y muchos otros lenguajes de programación.

126 111 Medium Access Control. Subcapa de la capa de enlace del modelo MAC ISO/OSI perteneciente al estándar IEEE Permite establecer la comunicación a nivel físico entre interfaces a través de una dirección única de 48 bits. NIC Network Information Center. Autoridad que delega los nombres de dominio a quienes los solicitan OpenSSL es un proyecto de software desarrollado por los miembros de OpenSSL la comunidad Open Source para libre descarga. Consiste en un robusto paquete de herramientas de administración y librerías relacionadas con la criptografía, que suministran funciones criptográficas a otros paquetes como OpenSSH y navegadores web ( HTTPS). Es un lenguaje de programación muy utilizado para construir aplicaciones CGI para el web. Perl es un acrónimo de PracticalExtracting and ReportingLanguaje, que viene a indicar que se Perl trata de un lenguaje de programación muy práctico para extraer información de archivos de texto y generar informes a partir del contendido de los ficheros. Es un lenguaje libre de uso, eso quiere decir que es gratuito. Antes estaba muy asociado a la plataforma Unix, pero en la actualidad está disponible en otros sistemas operativos como Windows.

127 112 Sistema de Nombres de Dominio (DomainNameSystem).El sistema de nombres de dominio es un estándar de Internet. Este se describe en el DNS RFC (RequestForComments) 1034 y El propósito de DNS es crear un sistema que permita realizar búsquedas en una base de datos tipo árbol. Estas búsquedas se realizan para la obtención de la dirección IP o del nombre de host que pertenece a un nodo que se encuentra en el sistema de nombres de dominio. Secure Sockets Layer. Protocolo de Capa de Conexión Segura. Son protocolos criptográficos que proporcionan comunicaciones seguras por SSL una red, comúnmente Internet. El protocolo SSL permite la autenticación de servidores, la codificación de datos y la integridad de los mensajes. Tablas hash Una tabla hash es una estructura de datos que permite el acceso de forma directa a los elementos que almacena a partir de una clave generada como un resumen (hash) de parte de los propios datos.

128 113 CAPÍTULO III METODOLOGÍA DISEÑO DE LA INVESTIGACIÓN MODALIDAD DE LA INVESTIGACIÓN El presente proyecto planteado como solución a las necesidades actuales de la Carrera de Ingeniería en Sistemas Computacionales, permite determinarse como un proyecto factible, el mismo que está conformado en un 20% bibliográfico, 20% investigativo, y el 60% corresponde a la propuesta de un prototipo de un cluster en Linux que permita brindar alta disponibilidad y balancear la carga de los servicios soportados por la institución. PROYECTO FACTIBLE En el área educativa, la propuesta de un proyecto factible es un término comúnmente usado; el mismo que se fundamenta de acuerdo a los limites normativos que rigen la institución académica. Debido a que la propuesta de un proyecto factible, debe de tener un modelo viable, o una solución posible; el cual va dirigido a satisfacer a la necesidad específica o solucionar un problema determinado. Es importante conocer y entender cada uno de los términos que conforman un proyecto factible. A continuación se hace una breve descripción de cada uno de ellos.

129 114 Proyecto Etimológicamente el vocablo proyecto, proveniente del latín proiectum, se compone del prefijo pro, que significa hacia adelante o hacia el futuro, e iectum, que se traduce por lanzar o arrojar. (Cerda Gutiérrez, Hugo, 2003) Al referirnos al termino proyecto se interpreta como el pensamiento de ejecutar algo hacia delante, o pensando en un futuro. Factible Del latin. Factibĭlis, que significa Que se puede hacer. En distintas áreas del conocimiento coinciden en que el termino proyecto se relaciona cuando se desea alcanzar un fin determinado. Los proyectos factibles representan un conjunto de operaciones y acciones que forman parte de un modelo operativo viable, en donde se investigan y analizan una situación educativa en un contexto determinado, permitiendo modificarla para mejorar las condiciones en que la población interviene. Es por eso que un proyecto factible satisface una necesidad específica o un problema determinado. Para poder generar cambios y modificar la realidad en el presente proyecto la cual es de índole educativa, se debe de establecer el tipo de investigación; el cual va orientado hacia el tipo de investigación Proyectos Factibles, el cual se debe su origen al

130 115 planteamiento y formulación de problemas, en donde se establecieron relaciones entre situaciones deficientes y posibilidades de cambio a esas deficiencias. Es así que el proyecto factible consistirá en la investigación, elaboración y desarrollo de una propuesta basada en un modelo operativo viable para solucionar problemas, requerimientos o necesidades de organización o grupos sociales; puede referirse a la formulación de políticas, programas, tecnologías, métodos o procesos. POBLACIÓN Y MUESTRA INTRODUCCION POBLACIÓN Habiendo definido el problema a solucionar, los objetivos, las variables inmersas; es importante determinar los individuos (objetos, personas, eventos, situaciones, y demás) con quienes se van a llevar a cabo la investigación. Lo importante dentro de nuestra población es que deben de tener características comunes. La población dentro de una investigación constituye el objeto de la misma, motivo por el cual la población considerada para el análisis del tema propuesto, es la Carrera de Ingeniería en Sistemas Computacionales; dentro de esta población se considero a los siguientes ente que se detallan en el siguiente cuadro.

131 116 Elaboración: Investigadora Fuente: Cuadro Poblacional de la CISC Tabla 1: Cuadro Poblacional POBLACIÓN DE LA CISC N Estudiantes 2111 Profesores 195 TOTAL 2306 MUESTRA INTRODUCCIÓN La muestra es una parte representativa de la población, permitiendo relacionar las características o propiedades del total de la población. La muestra definida dentro del contexto de la población fue la de los profesores de la Carrera de Ingeniería en Sistemas Computacionales que forman parte de la institución. Debido a que estos son los que perciben más la problemática definida dentro del proyecto. Además esta muestra representa el comportamiento del fenómeno en caso de estudio, a través de las situaciones que se originan dentro de la población, así como el comportamiento que representa en cada uno de los individuos. TECNICA DEL MUESTREO El muestreo se refiere a la técnica empleada al momento de seleccionar la muestra representativa de nuestra población. Existen diversos tipos de muestreo los cuales se detallan explícitamente a continuación:

132 117 Muestreo Probabilístico: Donde cada muestra tiene la misma probabilidad de ser seleccionada. Dentro de este tipo de muestreo se derivan los siguientes: Muestreo Aleatorio Simple: Asigna un numero a cada individuo de la población, mediante un sistema aleatorio; en donde se escogen un número determinado de individuos, hasta completar el tamaño de la muestra requerido para el estudio. Muestreo Aleatorio Sistemático: Al igual que el anterior, numera los individuos de la población; se diferencia en que no extrae n números aleatorios, sino solo uno. El mismo que es empleado como punto de partida, lo que permite periodicidad en cada elemento extraído. Muestreo Aleatorio por Conglomerados: Selecciona directamente los individuos o elementos de la población de manera aleatoria, donde las unidades muéstrales son grupos de elementos de la población que forman una unidad, la cual toma el nombre de conglomerado. Por ejemplo los departamentos universitarios, las aéreas de una corporación. Muestreo Aleatorio Estratificado: Se utiliza cuando la población es homogénea, y consiste en dividir la población en sub-poblaciones o estratos, basados en criterios que puedan ser importantes dentro del estudio. Muestreo no Probabilístico: Este tipo de muestreo, los elementos de la muestra son seleccionados por procedimientos al azar ó con probabilidades conocidas de

133 118 selección. Por lo tanto es imposible determinar el grado de representatividad de la muestra. Siendo caso de estudio los tipos de muestreos y lo que representan cada uno de ellos como parte representativa de la población, se determino utilizar el muestreo aleatorio estratificado. Debido a que nuestra muestra posee una característica en común, la misma que se debe a los servicios web que utilizan cada uno de los individuos por satisfacer una necesidad especifica. Dentro de la muestra representativa, se tomo un total de nueve profesionales, conocedores de la realidad educativa que se desarrolla en los momentos actuales y del tema propuesto del presente proyecto. Un punto importante de resaltar es que los profesionales inmersos en este estudio, son docentes de la institución que imparten conocimiento en cada uno de los semestres de la carrera. Para determinar el tamaño del estrato de la muestra representativa de la población, se utilizo las siguientes formulas: PQ.. N n 2 ( N 1) E / K 2 PQ.

134 119 TAMAÑO DE LA MUESTRA P = Probabilidad de éxito (0.90) Q = Probabilidad de fracaso (0.10) N= Tamaño de la población (238) E= error de estimación (6%) K= # de desviac. Típicas Z (1: 68%,2: 95,5%,3: 99.7%) n = Tamaño de la muestra (2306) ( ) ( )( )

135 120 Cálculo de la fracción muestral: n f N 95, Tabla 2: Cuadro Muestreo Estratificado POBLACIÓN DE LA CISC POBLACIÓN MUESTRA Estudiantes ,77 Profesores 195 8,11 TOTAL ,88 Elaboración: Investigadora Fuente: Cuadro Estratificado de la CISC OPERACIONALIZACIÓN DE VARIABLES La variable independiente se refiere al diseño y desarrollo de un prototipo de un cluster en Linux de alta disponibilidad, permitiendo balancear la carga de los servicios que se pone a disposición de los usuarios, mientras que nuestra variable dependiente se enfoca a la demanda de acceso web que atraviesa la carrera de ingeniería en sistemas computacionales y el balanceo de carga de los servicios.

136 121 MATRIZ DE OPERACIONALIZACIÓN DE VARIABLES Tabla 3: Cuadro Operacional de Variables Variables Dimensiones Indicadores Dependiente. Evaluación general del uso de los servicios que brinda la Carrera de Ingeniería en Sistemas Computacionales. Evaluar la demanda de acceso web, antes y después de los Independiente. Diseño de un cluster en Linux para brindar alta disponibilidad de los servicios Permitir el balanceo de los servicios prioritarios de la institución. Evaluación: Área docentes Soportar demanda de servicios en periodos considerados como prioritarios para el flujo transaccional de los procesos. Diseño de un cluster con la tecnología existente en la entidad educativa. Balanceo de servicios primordiales para soportar la carga transaccional. Nivel de insatisfacción de docentes y estudiantes de la institución. Carga transaccional inoperante al momento de saturarse con requerimientos de usuarios con un alto índice de demanda. Disponibilidad del servicio Peticiones procesadas en tiempos de respuestas óptimos. Técnicas y/o Instrumentos Evaluación: Encuesta dirigida a docentes de la institución. Observación de los procesos educativos diarios, entrevistas a alumnos y docentes de la fiabilidad de los servicios. Bibliografía especializada en textos y en la web, consulta a profesionales. Exposición de herramientas Open Source implicadas en el estudio del cluster. Elaboración: Investigadora Fuente: Matriz Operacional de Variables Dependientes e Independientes

137 122 INSTRUMENTOS DE RECOLECCIÓN DE DATOS El presente proyecto se fundamenta en la metodología de una investigación de campo. Debido a que utiliza una indagación dentro del entorno del problema el mismo que es la Carrera de Ingeniería en Sistemas Computacionales. Mediante la utilización de recursos de material impreso (encuestas), y a través de la gama de información circulante y actualizada que se encuentra en el mundo del internet con respecto a las soluciones posibles del fenómeno. Al momento de identificar la situación actual del entorno en el que se desarrolla y convive la población como parte de nuestro estudio. Se debe de identificar las técnicas a utilizar al momento de hacer el levantamiento de información relevante, la cual describe el comportamiento del objeto estudiado. Entre las técnicas de campo a utilizar, se resalta la técnica de la encuesta, la cual nos permitirá obtener conocimiento del comportamiento del fenómeno que está sujeto a caso de estudio. Poniendo en evidencia las condiciones en las que se ve inmerso los individuos que forman parte de la población. PROCESAMIENTO DE LA INVESTIGACIÓN Para la obtención de la información dentro de una investigación, existen varias técnicas como la observación, entrevista, y cuestionario. Dentro de cada una de ellas existen

138 123 instrumentos que permiten garantizar la confiabilidad y fiabilidad de la información tomada por alguna técnica en particular. Debido a la problemática existente en la institución, la técnica de la encuesta es la más requerida en el estudio del problema planteado, debido a que la misma va dirigida a individuos conscientes e inmersos con la realidad institucional por la que atraviesa la entidad educativa. RECOLECCIÓN DE LA INFORMACIÓN La encuesta es una técnica destinada a la recolección de información a través de opiniones impersonales que permiten al investigador, la obtención de información de individuos relacionados con el problema que es caso de estudio. Al igual que la entrevista se lleva a cabo a través de un cuestionario que contienen preguntas escritas, diferenciándose que el cuestionario es entregado a los sujetos que forman parte de la muestra significativa de la población. INSTRUMENTOS DE LA INVESTIGACIÓN Anteriormente se menciono la técnica a utilizar dentro del contexto de la investigación. La encuesta es la que nos permitirá recolectar información valiosa para poder entender el problema del fenómeno que es caso de estudio, dentro de esta encuesta se establecieron temas puntuales, no cayendo en ambigüedades siendo preguntas simplificadas con respuestas concretas.

139 124 Para realizar este proceso de recolección de información, se procedió a encuestar a cada docente, permitiendo a estos responder de acuerdo a su criterio; y despejando cualquier duda relacionado con alguna pregunta en particular. Incluso ciertas encuestas se desarrollaron dentro de los laboratorios de la Carrera de Ingeniería en Sistemas Computacionales. LA ENCUESTA Y EL CUESTIONARIO Dentro de la encuesta se resaltan los siguientes puntos que permiten determinar la confiabilidad y validez de la encuesta realizada para poder demostrar la problemática existente en la institución. La encuesta está conformada por preguntas cerradas donde el encuestado se centrara en responder cualquiera de las opciones planteadas. El cuestionario está dirigido a encontrar el fenómeno situacional en la Carrera de Ingeniería en Sistemas Computacional, además de recolectar información que permita encontrar una solución viable al problema existente. Dentro de la muestra representativa se tomo en consideración los docentes de distintos semestres, y de los distintos turnos que tienen la institución. Lo más importante es que dentro de la encuesta se tomo en consideración a aquellos que tienen años de trayectoria como docentes dentro de la institución. Una vez definido los parámetros de la encuesta, a continuación se debe de establecer la encuesta, a través de la siguiente estructura.

140 125 CONTENIDO Identificación de la Institución: Universidad de Guayaquil Carrera de Ingeniería en Sistemas Computacionales Objetivo que persigue: El objetivo principal es conocer el pensamiento de los docentes frente a la situación actual y futura de la institución. Obteniendo información relevante respecto a si la Carrea de Ingeniería en Sistemas Computacionales se encuentra preparada para soportar la demanda web. Instrucciones de cómo debe contestar: Las preguntas planteadas son de tipo cerradas, proponiendo opciones puntuales y concretas referentes al tema planteado con anterioridad. Permitiendo obtener información personalizada de cada uno de los encuestados.

141 126 Cuestionario de la Encuesta: UNIVERSIDAD DE GUAYAQUIL Facultad de Matemáticas y Física Carrera de Ingeniería en Sistemas Computacionales ENCUESTA DISEÑO Y DESARROLLO DE UN PROTOTIPO DE UN CLÚSTER EN LINUX DE ALTA DISPONIBILIDAD PARA SATISFACER LA DEMANDA DE ACCESO WEB 1. Piensa Ud. que la institución, se encuentra preparada para el crecimiento del uso del internet y la carga de trabajo generada por el estudiantado? Si No 2. Evalúe el nivel de conformidad, que siente al utilizar los servicios de la institución? Muy Conforme Conforme Inconforme Muy Inconforme 3. Cómo califica el tiempo de respuesta de los servicios que ofrece la institución? Muy Insatisfactorio Insatisfactorio Regular Satisfactorio Muy Satisfactorio 4. El desempeño proporcionado por los servicios los considera? Muy Bueno Bueno Regular Malo Muy Malo 5. Con que frecuencia no se encuentran disponibles los servicios que brinda la institución? Una vez a la semana Una vez al día Varias horas al día

142 Cómo califica el tiempo de respuesta utilizado para restaurar los servicios que han sufrido un colapso? Muy Bueno Bueno Regular Malo Muy Malo 7. Qué tan beneficioso seria utilizar un clúster en Linux para ofrecer alta disponibilidad en los servicios que ofrece la institución? Poco Satisfactorio Medianamente satisfactorio Muy satisfactorio 8. Cuál distribución de Linux recomendaría que utilicen los servidores de la institución? RetHat CentOS Fedora Debian Otros 9. Qué tipo de clúster piensa Ud. se debiera implementar en la institución? Clúster de Balanceo de Carga Clúster de Alto rendimiento Clúster de Alta disponibilidad Clúster de Alta Confiabilidad 10. Ha usado algunas de las siguientes soluciones de clúster de las que se detallan a continuación? HAOSCAR Ultramonkey Heartbeat Hearbeat+Ldirectord Ipvsadm Piranha Ninguna de las anteriores Otras (Especifique) GRACIAS POR SU INFORMACIÓN PROPORCIONADA ES MUY IMPORTANTE PARA NOSOTROS

143 128 PROCESAMIENTO Y ANÁLISIS Luego de haber realizado la recolección de la información, la tabulación de estos datos es un factor importante que permitirá reflejar a través de porcentajes la situación actual del entorno en donde se desenvuelve nuestra población. La tabulación se desarrollo a través de un conteo manual de cada una de las preguntas contestadas por los docentes encuestados. Donde se obtuvo como resultado los datos y gráficos estadísticos que se detallan a continuación: Tabla 4: Cuadro de Tabulaciones de la Encuesta 1. Piensa Ud. que la institución, se encuentra preparada para el crecimiento del uso del internet y la carga de trabajo generada por el estudiantado? 2. Evalúe el nivel de conformidad, que siente al utilizar los servicios de la institución? Si % No % Muy Conforme Conforme 0 0% % Inconforme % Muy inconforme 0 0% Muy Insatisfactorio % 3. Cómo califica el tiempo de respuesta de los servicios que ofrece la institución? Insatisfactorio Regular Satisfactorio Muy Satisfactorio 0 0% % % 0 0%

144 El desempeño proporcionado por los servicios los considera? 5. Con que frecuencia no se encuentran disponibles los servicios que brinda la institución? 6. Cómo califica el tiempo de respuesta utilizado para restaurar los servicios que han sufrido un colapso? 7. Qué tan beneficioso seria utilizar un clúster en Linux para ofrecer alta disponibilidad en los servicios que ofrece la institución? Muy Bueno 0 0% Bueno % Regular % Malo Muy Malo Una vez a la semana Una vez al día Varias horas al día Muy Bueno Bueno Regular Malo Muy Malo Poco Satisfactorio % 0 0% % % 0 0% % % % 0 0% 0 0% % Medianamente satisfactorio % Muy satisfactorio % 8. Cuál distribución de Linux recomendaría que utilicen los servidores de la institución? RetHat CentOS Fedora Debian Otros (Especifique) % % % % 0 0%

145 130 Clúster debalanceo de Carga % 9. Qué tipo de clúster piensa Ud. se debiera implementar en la institución? Clúster dealto rendimiento 0 0% Clúster de Alta disponibilidad % Clúster de Alta Confiabilidad 0 0% 10. Ha usado algunas de las siguientes soluciones de clúster de las que se detallan a continuación? HAOSCAR Hearbeat+Ldirectord Piranha Ultramonkey Ipvsadm Heartbeat 0 0% % % 0 0% 0 0% % Ninguna de las anteriores % Otras % Elaboración: Cuadro Tabular de las Preguntas Fuente: Carlos Zumba Vásquez A continuación, se muestra en detalle los cuadros estadísticos obtenidos de cada una de las preguntas que se plantearon en el cuestionario.

146 131 Gráfico 18: Pregunta 1 1. Piensa Ud. que la institución, se encuentra preparada para el crecimiento del uso del internet y la carga de trabajo generada por el estudiantado? 22,22% Si No 77,78% Elaboración: Investigadora Fuente: Cuadro Estadístico 1 Análisis: La muestra representa que en los momentos actuales la Carrera de Ingeniería en Sistemas computacionales no se encuentra preparada para un crecimiento de usuarios. Gráfico 19: Pregunta 2 2. Evalúe el nivel de conformidad, que siente al utilizar los servicios de la institución? 0,00% 0,00% 55,56% 44,44% Muy Conforme Conforme Inconforme Muy inconforme Elaboración: Investigadora Fuente: Cuadro Estadístico 2

147 132 Análisis: Existe una nivel de inconformidad regular de los servicios proporcionados a los usuarios. Gráfico 20: Pregunta 3 3. Cómo califica el tiempo de respuesta de los servicios que ofrece la institución? 33,33% 0,00% 0,00% 11,11% 55,56% Muy Insatisfactorio Insatisfactorio Regular Satisfactorio Muy Satisfactorio Elaboración: Investigadora Fuente: Cuadro Estadístico 3 Análisis: Existe un tiempo de respuesta regular no optimo en los servicios de la institución. 60,00% Gráfico 21: Pregunta 4 4. El desempeño proporcionado por los servicios los 55,56% considera? 50,00% 40,00% 33,33% 30,00% 20,00% 10,00% 0,00% 11,11% 0,00% 0,00% Muy Bueno Bueno Regular Malo Muy Malo Elaboración: Investigadora Fuente: Cuadro Estadístico 4

148 133 Análisis: El desempeño proporcionado refleja un parámetro normal de acuerdo a cada uno de los servicios provistos a los estudiantes. Gráfico 22: Pregunta 5 5. Con que frecuencia no se encuentran disponibles los servicios que brinda la institución? 0,00% 33,33% Una vez a la semana Una vez al día 66,67% Varias horas al día Elaboración: Investigadora Fuente: Cuadro Estadístico 5 Análisis: El gráfico refleja un problema latente respecto a la disponibilidad de un servicio determinado. Gráfico 23: Pregunta 6 6. Cómo califica el tiempo de respuesta utilizado para restaurar los servicios que han sufrido un colapso? 0,00% 0,00% 44,44% 11,11% 44,44% Muy Bueno Bueno Regular Malo Muy Malo Elaboración: Investigadora Fuente: Cuadro Estadístico 6

149 134 Análisis: El tiempo de respuesta de puesta en marcha de un servicio qua ha sufrido un colapso demuestra la inconformidad de los usuarios. Gráfico 24: Pregunta 7 7. Qué tan beneficioso seria utilizar un clúster en Linux para ofrecer alta disponibilidad en los servicios que ofrece la institución? 77,78% 11,11% 11,11% Poco Satisfactorio Medianamente satisfactorio Muy satisfactorio Elaboración: Investigadora Fuente: Cuadro Estadístico 7 Análisis: La muestra representativa de nuestra población está de acuerdo en implementar la tecnología de cluster que soporte la demanda de requerimientos. Gráfico 25: Pregunta 8 35,00% 8. Cuál distribución de Linux recomendaría que utilicen los servidores de la institución? 33,33% 30,00% 25,00% 20,00% 15,00% 10,00% 22,22% 22,22% 22,22% 5,00% 0,00% 0,00% RetHat CentOS Fedora Debian Otros (Especifique) Elaboración: Investigadora Fuente: Cuadro Estadístico 8

150 135 Análisis: La tendencia del sistema operativo va acorde con la utilizada hasta el momento en los servidores de la institución. Siendo Red Hat el segundo de mayor puntuación, el mismo que es utilizado a nivel de base de datos para la asignatura del mismo nombre. 70,00% 60,00% 50,00% Gráfico 26: Pregunta 9 9. Qué tipo de clúster piensa Ud. se debiera implementar en la institución? 66,67% 40,00% 30,00% 33,33% 20,00% 10,00% 0,00% Clúster de Balanceo de Carga 0,00% Clúster de Alto rendimiento Clúster de Alta disponibilidad 0,00% Clúster de Alta Confiabilidad Elaboración: Investigadora Fuente: Cuadro Estadístico 9 Análisis: Dentro de los resultados obtenidos, se pudo constatar de la tendencia hacia el cluster de alta disponibilidad propuesto dentro del contexto del proyecto. Además posee mejores beneficios en relación al segundo; el cual fue el de cluster de balanceo de carga. Debido a que solo se limitara a distribuir los requerimientos, pero no a redundar en caso de un fallo del nodo director.

151 136 Gráfico 27: Pregunta Ha usado algunas de las siguientes soluciones de clúster de las que se detallan a continuación? 0,00% 11,11% 11,11% 22,22% 33,33% 0,00% 22,22% 0,00% HAOSCAR Hearbeat+Ldirectord Piranha Ultramonkey Ipvsadm Heartbeat Ninguna de las anteriores Otras (Especifique) Elaboración: Investigadora Fuente: Cuadro Estadístico 10 Análisis: Dentro de las soluciones de cluster existe preferencia mayoritaria por ipvsadm, heartbeat y piranha. CRITERIOS PARA LA ELABORACIÓN DE LA PROPUESTA Dentro del contexto de la propuesta se establecieron criterios que permitieron llevar a cabo el desarrollo del prototipo mencionado anteriormente. Criterios que respaldan la viabilidad del tema, a través de un detalle general de los pasos a seguir para llevar a cabo el desarrollo del tema. Inicialmente se debe de tener en consideración los requerimientos necesarios para la construcción del prototipo de cluster. Motivo por el cual estos requerimientos deberán de

152 137 formalizarse a través de una selección adecuada de hardware y software para establecer la respectiva configuración e implementación de nuestro prototipo funcional. Dentro de la topología de red definida en el prototipo, se requieren varios servidores debido al concepto del cluster que encierra el proyecto, razón importante para aclarar que se está realizando a través de la herramienta de virtualización VMware. En cada equipo virtualizado se instalo el Sistema operativo CentOs 5.5. Otro punto destacable es que se trata de un cluster homogéneo, debido a que en la Carrera de Ingeniería en Sistemas Computacionales los servicios están instalados en servidores de características similares. Además el software y aplicaciones usadas en el desarrollo del cluster y los servicios que este proporcionara, son OpenSource; manteniendo la tendencia de la propuesta. CRITERIOS DE VALIDACIÓN DE LA PROPUESTA Una vez implementado el prototipo, se debe de verificar la validación y correcto funcionamiento del mismo. A través de pruebas de estrés, creando diferentes escenarios de sucesos o siniestros que pudieren darse en caso de pérdida de conectividad de un servidor que forme parte del cluster. Además se realizaran pruebas de conexión y funcionamiento a nivel de clientes, debido a que estos son los que de cierta forma categorizan los servicios que la institución proporciona. El nivel de satisfacción de los usuarios es el que permite reflejar la problemática del fenómeno que es caso de estudio.

153 138 CAPÍTULO IV MARCO ADMINISTRATIVO CRONOGRAMA Dentro de los pasos requeridos para la implementación de la propuesta del prototipo del cluster se estableció el siguiente cronograma que se detalla a continuación.

154 139 PRESUPUESTO Para el desarrollo del proyecto y el cumplimiento de los objetivos propuestos en la investigación se incurrieron en los siguientes costos detallados de la siguiente manera. Detalle de egresos del proyecto EGRESOS DÓLARES Suministros de oficina y computación $ Impresiones $ Encuadernado & Empastados $ Servicios de Internet $ Transporte $ TOTAL $

155 140 CAPÍTULO V CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES La tecnología de cluster resulta la solución más viable, al momento de soportar una carga transaccional incremental. Motivo de estudio de este proyecto, debido al crecimiento sustancial de usuarios que generan una acrecentada demanda web, servicio que debe de en constante disponibilidad para los usuarios. Además es destacable, que al momento de implementar un cluster. No es necesaria la existencia de servidores especializados para una tarea específica. Sino que es adaptable a la realidad tecnológica que posee como plataforma del hardware la Carrera de Ingeniería en Sistemas Computacionales. Lo que conlleva a reducción de costos por implementar la tecnología en mención. Además al implementar la solución del software a utilizar en el cluster, se noto que ciertas aplicaciones destinadas a esta tecnología, no permitieron compatibilidad con sistemas operativos. Entre ellas HA OSCAR no fue compatible con CentOs, y RedHat. Debido a que la última versión de esta software, fue probada en CentOs 4.3. Lo que conllevaría retroceder en la versión de sistema operativo, provocaría un retroceso tecnológico, y no una solución viable a la problemática; que es el objetivo de este proyecto.

156 141 Los cluster permiten tener una escalabilidad a futuro, lo cual dependiendo de las necesidades se podría agregar más servidores reales sin un límite establecido, lo que significa una gran ventaja frente a servidores que ofrecen soluciones siempre y cuando se acoplen a las características de estos. Se determino el kernel de las distribuciones de Linux existentes en la actualidad proveen de soporte Linux Virtual Server, a través del paquete Ipvsadm necesario para adaptarse a cualquier tipo de infraestructura sea este homogéneo o heterogéneo. Debido a que a partir de la versión del kernel 2.6 trae parchado esta utilidad. Se comprobó que la solución escogida para proporcionar alta disponibilidad la cual es heartbeat, trae consigo una interfaz de administración; permitiendo realizar un monitoreo del estado del cluster y de cada uno de sus nodos que lo conforman. Además de agregar demonios para que sean controlados por heartbeat. Siendo heartbeat base fundamental de aplicaciones como piranha que utilizan la funcionalidad de heartbeat a través de una interfaz desarrollada bajo RedHat. Existió un problema al momento de implementar el cluster, debido a que la interfaz virtual estaba configurada en cada uno de los nodos directores y reales. Donde ambos respondían a requerimientos ARP que venían de los clientes, lo que provocaba un conflicto interno al momento de responder las peticiones. Motivo

157 142 por el cual se deshabilito esta funcionalidad en los servidores reales, siendo solamente el nodo director quien redireccione las peticiones dirigidas hacia la interfaz virtual. Dentro de los distintos tipos de balanceo, se determino el balanceo por enrutamiento directo; debido a la realidad existente en la institución; donde equipos destinados al uso del usuario común hacen de servidores. Los cuales no soportarían las traslaciones de direcciones que generan los mecanismos de encapsulamiento IP y NAT. Debido a que deben de poseer una capacidad de cálculo grande. Se comprobó exitosamente la alta disponibilidad del cluster, generando la caída del servidor principal, levantándose automáticamente el servidor de respaldo, tomando así el control del sistema. Evitando un fallo inminente del mismo de los servicios configurados en el cluster.

158 143 RECOMENDACIONES Es recomendable tener alta disponibilidad a nivel de servidores, y a nivel de dispositivos de interconectividad como router y switch, así como a nivel de UPS. Debido a que estos podrían ser causa de un punto de fallo en un momento determinado. Es recomendable que las características del nodo director, así como el de respaldo posean características de hardware homogéneas, teniendo uniformidad de procesos.

159 144 REFERENCIAS BIBLIOGRÁFICAS LIBROS Tom Adelstein& Bill Lubanovic. (2007). Administración de Sistemas Linux. España: Madrid. Mark Mitchell, Jeffrey Oldham, and Alex Samuel (2001). Advanced Linux Programming. Indianapolis: Indiana Trevor Kay (2002). La Biblia de Linux (Linux + Certification Bible) Published by Hungry Minds, Inc. New York. Emilio José Plaza Nieto (2002). Cluster Heterogéneo De Computadoras. España. Karl Kooper (2005). Linux Enterprice Cluster Build a Highly Available Cluster With Commodity Hardware and Free Software. United States of America. San Francisco. Charles Bookman (2003). Linux Clustering Building and Maintaining Linux Clusters. USA. Indianapolis. Miguel Colobran Huguet, Josep Maria Arques Solvedilla Eduard Marco Galindo (2008). Administración de sistemas operativos en red España - Barcelona

160 145 PUBLICACIONES Universidad de San Carlos de Guatemala, Facultad de Ingeniería, Escuela de Ciencias y Sistemas (2002). Curso: Sistemas Operativos II, Plataforma: Linux OpenSuse. Historia de CLUSTER. Extraído el 11 de Julio del DIRECCIONES WEB CICESE (Febrero 2002). Arquitecturas de Computadoras. Extraído el 16 de Julio del 2010 desde Taxonomía de Flynn. (18 de junio del 2010). Diagrama de comparación de las clasificaciones. Extraído el 02 de Agosto del 2010 desde Implementación de Heartbeat DRBD. Extraído el 15 de Octubre del 2010 desde la página oficial: Configuring A High Availability Cluster (Heartbeat) On CentOS. Extraído el 13 de Octubre del 2010 desde

161 146 Cluster Mysql con CentOS, DRBD y Heartbeat. Extraído el 19 de Octubre desde Alta disponibilidad y balanceo de carga en Linux. Extraído el 2 de Noviembre del 2010 desde Linux cluster con Heartbeat para servidores http. Extraído el 10 de Noviembre del 2010 desde Página Oficial HAOSCAR. Extraído el 15 de Octubre del 2010 desde Cluster Definiciones. Extraído el 12 de Agosto del 2010 desde

162 UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES DISEÑO Y DESARROLLO DE UN PROTOTIPO DE UN CLUSTER EN LINUX DE ALTA DISPONIBILIDAD PARA SATISFACER LA DEMANDA DE ACCESO WEB EN LA CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES Y EL BALANCEO DE CARGA DE LOS SERVICIOS TESIS DE GRADO Previa a la obtención del Título de: INGENIERO EN SISTEMAS COMPUTACIONALES AUTOR: CARLOS POLIVIO ZUMBA VASQUEZ TUTOR: ING. DAVID BENAVIDES GUAYAQUIL ECUADOR 2011

163 MANUAL DE ADMINISTRADOR

164 ÍNDICE GENERAL ÍNDICE GENERAL... i ÍNDICE DE GRÁFICOS... v INDICE DE TABLAS... viii MANUAL DE ADMINISTRADOR... 1 ANÁLISIS DE REQUERIMIENTOS PARA CONFIGURACIÓN DE CLUSTERS... 1 Requerimientos de Hardware... 1 Requerimientos de Software... 4 DISEÑO Y CONFIGURACIÓN DEL CLUSTER... 5 CONSIDERACIONES PREVIAS A LA CONFIGURACIÓN E INSTALACIÓN Determinación del mecanismo de Balanceo de Carga... 6 Ventajas y desventajas de NAT... 6 Ventajas y desventajas de Encapsulamiento por IP... 7 Ventajas y desventajas de Enrutamiento directo Determinación del mecanismo de Balanceo de Carga Análisis del tipo de balanceo de carga en ambientes homogéneos Análisis del tipo de balanceo de carga en ambientes heterogéneos Determinación de la herramienta de instalación de LVS LVS INSTALACIÓN BALANCEO DE CARGA CON LDIRECTORD Y HEARTBEAT LDIRECTORD Configuración de los Servidores Reales Configuración del Servidor director (balanceador de carga) PRUEBAS REALIZADAS A LDIRECTORD... 19

165 Deshabilitar el Servicio de Ldirectord HEARTBEAT Principales Archivos de Configuración Verificación del Servicio PRUEBAS REALIZADAS A HEARTBEAT Comprobación LVS Comprobar Sincronización de Ldirectord CONFIGURACIÓN DE LA CONEXIÓN DE HB_GUI Recursos INSTALACION Y CONFIGURACIÓN DE POSTFIX EN CENTOS Instalación a través de yum Configuración de main.cf Creación de usuarios DOVECOT INSTALACION Y CONFIGURACION DE SQUIRRELMAIL Instalación Ejecutar lo siguiente desde el terminal Configuración JMETER Descarga e Instalación Inicio de JMeter Escenarios PRUEBAS TELNET A LA INTERFAZ VIRTUAL PRUEBAS CON JMETER Creación del Plan de pruebas Ejecución del Plan de pruebas... 55

166 INSTALACIÓN Y CONFIGURACIÓN DE RSYSLOG Configuraciones Previas Detener SysLog Configuración de MySQL Configuración de rsyslog.conf INSTALACIÓN Y CONFIGURACIÓN DE LOGANALYZER Configuraciones previas Configuración de httpd.conf Configuración de Loganalyzer Creación de la Cuenta Administrador del Syslog Inicio de sesión Configuracion de Syslogs en Nodos del Cluster ADMINISTRADOR IPVSADM Configuraciones Previas Configuración de MySQL Comprobación de la estructura de la base Configuración de apache Configuración de PHP Habilitar etiqueta corta Configuración SSH Generar claves RSA Replicación de claves RSA Pruebas SSH INSTALACIÓN Y CONFIGURACIÓN DE DRBD Instalaciones previas Configuraciones Previas... 86

167 Creación del Filesystem Configuración de drbd.conf Montar partición Virtual Pruebas DRBD Directorios a Sincronizar AGREGAR DRBD A HEARTBEAT Configuración a través de hb_gui Creación de recurso nativo drbddisk_mysql Creación del recurso nativo fs_mysql Creación del recurso nativo mysqld CONFIGURACIÓN IPVSADMIN

168 ÍNDICE DE GRÁFICOS Gráfico 1: Diseño del Cluster CISC... 5 Gráfico 2: Prueba Ldirectord con Ipvsadm Gráfico 3: Prueba Ldirectord a la IP Virtual Gráfico 4: Propagación de Archivos de Heartbeat Gráfico 5: Inicio de Heartbeat Gráfico 6: Sincronización del Nodo Director Gráfico 7: Sincronización del Nodo Backup Gráfico 8: Comprobación LVS en Nodo Director Gráfico 9: Comprobación LVS en Nodo Backup Gráfico 10: Comprobación de Ldirectord en Nodo Director Gráfico 11: Comprobación de Ldirectord en Nodo Backup Gráfico 12: Inicio de Interfaz Gráfica de Hearbeat Gráfico 13: Hb_gui - Agregar Nuevo Recurso Gráfico 14: Hb_gui - Creación de Tipo de Item Gráfico 15: Hb_gui - Creación del Grupo Load Balancer Gráfico 16: Hb_gui - Creación del recurso Vip Gráfico 17: Hb_gui - Creación del Parametro lvs_support Gráfico 18: Hb_gui - Guardar Recurso vip Gráfico 19: Hb_gui - Agregar Operaciones a un Recurso Gráfico 20: Hb_gui - Agregar Operación de Monitoreo a vip Gráfico 21: Hb_gui - Guardar Operación de Monitoreo a vip Gráfico 22: Hb_gui - Guardar Cambios Generales Gráfico 23: Hb_gui - Agregar Nuevo Item Nativo Gráfico 24: Hb_gui - Creación del recurso ldirector Gráfico 25: Hb_gui - Creación del Parametro configfile Gráfico 26: Hb_gui - Agregar Operación de Monitoreo a ldirector Gráfico 27: Hb_gui - Inicio del Recurso load_balancer... 36

169 Gráfico 28: Squirrelmail- Inicio Gráfico 29: Squirrelmail- Lenguaje de Preferencia Gráfico 30: Squirrelmail - Preferencias de la Organización Gráfico 31: Squirrelmail - Selección del Dominio & SMTP Gráfico 32: Squirrelmail - Opciones de Carpetas Gráfico 33: Squirrelmail - Selección de Plugins Gráfico 34: Squirrelmail - Inicio de Sesión Web Gráfico 35: Página Oficial de JMeter Gráfico 36: Descarga de JMeter Gráfico 37: Inicio de JMeter Gráfico 38: Interfaz Gráfica Gráfico 39: Prueba Telnet a la IPV Gráfico 40: JMeter - Creación Test Cluster CISC Gráfico 41: JMeter - Grupo de Hilos Gráfico 42: JMeter - Valores por Defecto para Peticion HTTP Gráfico 43: JMeter - Temporizador Constante Gráfico 44: JMeter - Petición HTTP Gráfico 45: JMeter - Aserción de Respuesta Gráfico 46: JMeter - Gráfico de Resultados Gráfico 47: JMeter - Árbol de Resultados Gráfico 48: JMeter - Ejecución del Plan de pruebas Gráfico 49: Comprobación de Funcionabilidad con Dos Nodos Reales Gráfico 50: JMeter - Resultados Obtenidos con Dos Nodos Reales Gráfico 51: Comprobación de Funcionabilidad con un Nodo Real Gráfico 52: Resultados Obtenidos con 1 Nodo Real Gráfico 53: JMeter - Árbol de Resultados del Plan de Pruebas Gráfico 54: Loganalyzer - Inicio de Instalación Gráfico 55: Loganalyzer - Prerequisitos Gráfico 56: Loganalyzer - Verificación de Permisos... 69

170 Gráfico 57: Loganalyzer - Configuración Basica Gráfico 58: Loganalyzer - Configuración de la Base de Datos Gráfico 59: Loganalyzer - Creación de Tablas Gráfico 60: Loganalyzer - Revisión de Resultados SQL Gráfico 61: Loganalyzer - Creación de la Cuenta Administrador Gráfico 62: Loganalyzer - Creación de Fuentes para los Mensajes del Syslog Gráfico 63: Loganalyzer - Finalización de Instalación Gráfico 64: Loganalyzer - Inicio de Sesión Gráfico 65: Loganalyzer - Error de Sesión Gráfico 66: Loganalyzer - Sources Gráfico 67: Loganalyzer - Parámetro SystemEvent Gráfico 68: Loganalyzer - Monitoreo de Logs Gráfico 69: Loganalyzer - Statistics Gráfico 70 : DRBD - Verificar Disco Gráfico 71 : DRBD - Particionar Disco Gráfico 72 : DRBD - Tabla de Particiones Gráfico 73 : DRBD - Comprobar Nueva Partición Gráfico 74 : DRBD - Formatear Partición Gráfico 75 : DRBD - Creación del Metadata Gráfico 76 : DRBD - Inicio del Servicio en Nodo Director Gráfico 77 : DRBD - Inicio del servicio en Nodo Backup Gráfico 78 : DRBD - Establecer Nodo primario Gráfico 79 : DRBD - Creación de Data de Prueba Gráfico 80 : DRBD - Prueba en Nodo Director Gráfico 81 : DRBD - Prueba en Nodo Backup Gráfico 82 : DRBD - Desmontar Nodo Backup Gráfico 83 : DRBD - Montar Nodo Director... 94

171 INDICE DE TABLAS Tabla 1: Infraestructura Tecnológica de los Servidores de la CISC... 2 Tabla 2: Infraestructura Técnologica de los Equipos de Comunicación de la CISC... 3 Tabla 3: Prioridades Syslog Tabla 4: Facilidades Syslog... 77

172 1 MANUAL DE ADMINISTRADOR ANÁLISIS DE REQUERIMIENTOS PARA CONFIGURACIÓN DE CLUSTERS Requerimientos de Hardware Antes de comenzar con la instalación y la configuración de las herramientas necesarias para el clúster; se deben de tener en consideración las siguientes características que se detallan a continuación: Un router, el que servirá de gateway del cluster. Un servidor director y un standby, donde se configurar la dirección IP virtual, además de la dirección IP real. Un switch de comunicaciones, el cual será el encargado de enlazar el nodo director con los servidores reales. Dos Servidores reales, cada uno con su respectiva dirección IP. Un equipo cliente, el cual accederá desde el internet o Intranet a los servicios que ofrece el cluster. Dentro del estudio se contemplo la plataforma tecnológica que posee actualmente la Carrera de Ingeniería en Sistemas Computacionales. A continuación se detalla las características de los recursos tecnológicos de la institución:

173 2 En primer lugar se detallan los equipos tecnológicos en los que están soportados los servicios de la institución. Para lograr determinar la factibilidad del presente proyecto de acuerdo a la plataforma con la que tiene actualmente. Tabla 1: Infraestructura Tecnológica de los Servidores de la CISC Marca Modelo Procesador Memoria Disco Duro Servicios MB (GB) IBM 6349 INTEL PENTIUM 4 3,0 GHz Firewall Principal IBM 8183 INTEL PENTIUM 4 3,,0 GHz 1024 Trixbox IBM 8183 INTEL PENTIUM 4 3,0 GHz 512 Envío de información IBM 6349 INTEL PENTIUM 4 Firewall Laboratorio ,0 GHz IBM 8183 INTEL PENTIUM 4 Firewall Laboratorio ,0 GHz 1-2 IBM 8183 INTEL PENTIUM 4 3,0 GHz Dominio LENOVO 9632 INTEL CORE 2 DUO 2,13 GHz 1024 Correo HP 5100 MT INTEL PENTIUM 4 3,0 GHz Web LENOVO 9632 INTEL CORE 2 DUO 2,13 GHz Oracle HP 5100 MT INTEL PENTIUM 4 3,0 GHz 2048 Evaluación Docente LENOVO 9632 INTEL CORE 2 DUO Base de Datos SQL ,13 GHz Server Elaboración: Carlos Zumba Fuente: Departamento Técnico CISC Área de Hardware

174 3 Dentro del estudio se estableció además el levantamiento de la información de los equipos de comunicación los cuales se detallan en el adjunto. Tabla 2: Infraestructura Técnologica de los Equipos de Comunicación de la CISC Descripción Marca Modelo Cantidad SWITCH D-LINK DKVM-8E 2 SWITCH 3COM SWITCH CYSCO SYSTEM SWITCH CYSCO SYSTEM ROUTER CISCO SYSTEM CISCO SB101 1 ROUTER CISCO SYSTEM CISCO851 1 PATCH_PANEL/LD24 LUCENT 1100 CAT5 PS 2 PATCH_PANEL/48 SIEMON MAX TM SERIES 1 PATCH_PANEL/48 ORTRONICS CAT5 1 PATCH_PANEL/ CAT5 PS 1 RACKS 2 Elaboración: Carlos Zumba Fuente: Departamento Técnico Área de Hardware Dentro del contexto del prototipo se considero la virtualización, debido a que la virtualización permite simular el escenario acorde al estudio previamente realizado. El mismo que en su génesis fue planteado como un prototipo que permita demostrar la funcionabilidad del tema propuesto.

175 4 Requerimientos de Software Se contemplo el Sistema Operativo Linux distribución CentOS versión 5.5. Instalándose en cada uno de los servidores a nivel de nodos directores como reales. Nodos directores se requiere la herramienta heartbeat para garantizar la alta disponibilidad, y ldirectord para el balanceo de carga, además se requiere instalar y configurar la interfaz grafica de heartbeat que permitirá administrar y configurar la alta disponibilidad del cluster. Debido a que Ldirectord gestiona el balanceo de carga, requiere de IPVS para efectuar este proceso; por lo que se requiere el paquete de ipvsadm, herramienta que permite la administración y configuración de LVS. Servidores Reales. Se requiere configurar en cada nodo apache y php, adicionalmente a esto se requiere instalar y configurar Postfix para proporcionar el servicio de correo electrónico. Clientes. En los clientes se requiere cualquier sistema operativo, ya sea Windows o Linux, se determino utilizar Windows XP. Sobre el cual se instalara la aplicación JMeter, para comprobar el rendimiento y comportamiento del cluster. Esta aplicación requiere tener instalado en el equipo cliente el intérprete de Java.

176 5 DISEÑO Y CONFIGURACIÓN DEL CLUSTER Establecer el diseño del cluster, es importante al momento de entender la funcionabilidad del mismo. A continuación se presenta el diseño del cluster al cual se lo denomino Cluster CISC. Gráfico 1: Diseño del Cluster CISC

177 6 CONSIDERACIONES PREVIAS A LA CONFIGURACIÓN E INSTALACIÓN. Determinación del mecanismo de Balanceo de Carga Para determinar el mecanismo de balanceo de carga a utilizar, se debe de realizar un análisis de las ventajas y desventajas para determinar el idóneo del proyecto. Ventajas Ventajas y desventajas de NAT Los servidores reales poseen una sola tarjeta de red configurada, mediante la cual se conectan entre sí y con el servidor director por medio del cual dirigen la respuesta del trabajo encomendado por el cliente. Esto representa omitir costos por instalar otra tarjeta de red. Es recomendado cuando se tiene un flujo de transacciones menores, que no Desventajas generen gran cantidad de tráfico. Sobrecarga al reescribir los paquetes originados desde y hacia los servidores reales y clientes, sobre todo cuando el número de transacciones y respuestas es grande, por lo que conllevaría a un costo mayor en un equipo que soporte este flujo transaccional. Debido a la carga de trabajo, el nodo director no permitirá tener muchas conexiones activas con los servidores reales

178 7 Ventajas y desventajas de Encapsulamiento por IP Ventajas Permite mayor escalabilidad que el NAT, llegando a un número de 100 servidores o más con la característica de que tengan soporte para encapsulamiento IP. El nodo director realiza el encapsulamiento IP, y lo reenvía a los servidores reales, los cuales se encargan de procesar el requerimiento y responderlo directamente al cliente, logrando evitar saturarlo e impedir que existan un cuello de botella sobre el nodo director. Este mecanismo de balanceo de carga permite distribuir los servidores en una red Desventajas local amplia, en lugar de estar en un mismo segmento de red, ventaja importante cuando la infraestructura tecnológica no se encuentra en un mismo lugar. La desventaja principal es que los nodos utilizados con este tipo de balanceo, deben soportar el protocolo IP tunneling o IPSec. Problemas de ARP cuando los nodos se encuentran en el mismo segmento de red, provocando conflicto interno de direcciones por respuestas a requerimientos ARP. Solamente el nodo director debe ser capaz de responder a estos requerimientos, y redireccionarlos a los reales. Para solucionar esto se debe de ocultar la interfaz de red de los servidores reales para que no respondan a estos requerimientos y procesar los paquetes destinados a la IP pública local del cluster.

179 8 Ventajas y desventajas de Enrutamiento directo. Ventajas La ventaja que mas representa este tipo de balanceo, es que no existe sobrecarga de trabajo debido a que los requerimientos son procesados en los servidores reales, y son estos los que responden directamente al cliente, sin necesidad de pasar por el nodo director, y sobrecargar este como si lo hacen los encapsulamiento IP y NAT. Desventajas Existe el mismo conflicto ARP que presenta el encapsulamiento IP, debido a que la configuración virtual esta en los servidores reales y director, por lo que se debe de ocultar la interfaz de los servidores reales. Debido a que el nodo director realiza el enrutamiento directo de las peticiones MAC, es imposible tener la infraestructura en áreas dispersas, debido a que este tipo de balanceo necesita que los nodos estén en un mismo lugar. Dentro del análisis se decidió utilizarse el mecanismo de balanceo por enrutamiento directos, debido que este es se ajusta a las necesidades del proyecto. Entre las razones que permitieron llegar a esta selección se detalla:

180 9 La infraestructura tecnológica de la institución se encuentra dentro de un mismo lugar. Motivo por el que el mecanismo de encapsulamiento IP no es posible. Además de evitar problemas de sobrecarga al momento de enmascarar y desenmascaras los datagramas IP. Los servidores poseen características limitadas, motivo por el cual no se opto por el mecanismo de balanceo NAT, debido a que estos tiene una sobrecarga de trabajo al reescribir los paquetes originados desde y hacia los servidores reales y clientes. Problema mayor cuando las transacciones son mayores y además estas deben ser soportadas por el servidor director. El mecanismo de enrutamiento directo implica que los servidores se encuentren en un mismo espacio físico y dentro de la misma red, además no existe problemas de poder de cálculo de los servidores; debido a que en este tipo de balanceo no se realiza ningún tipo de encapsulamiento o traslación y reenvío de resultados que son soportados por el nodo director. Debido a que este tipo de balanceo responde directamente a los requerimientos generados por el cliente. El inconveniente con el enrutamiento directo, radica en el hecho de tener configurada la IP virtual en todos los servidores, produciendo conflicto ARP al momento de responder a los requerimientos.

181 10 Determinación del mecanismo de Balanceo de Carga Existen varios algoritmos que permiten el balanceo de carga, los mismos que fueron explicados anteriormente en capítulos previos. Al igual que se efectúo el respectivo análisis de los tipos de mecanismo a utilizar el cual fue mecanismo de balanceo de carga por enrutamiento directo, se deberá seleccionar el tipo de algoritmo que cumpla con los requerimientos que más se acoplen al tema propuesto. Dependiendo del tipo de plataforma de hardware que se contemple en la implementación del cluster, se deberá seleccionar el tipo de algoritmo a usar en el mismo. Existen clusters conformados por ambientes homogéneos, cuyas características son similares; así como ambientes heterogéneos donde se diferencian uno del otro. En el desarrollo del proyecto se utiliza un cluster homogéneo, debido a dos razones importantes entre las cuales se destacan. El hardware sobre en el cual están soportados los servicios de la carrera de ingeniería en sistemas computacionales, son de características similares. La propuesta del prototipo de llevara mediante la herramienta VMware, la cual permite este tipo de ambientes, respaldando así el punto anterior prescrito. Análisis del tipo de balanceo de carga en ambientes homogéneos Dentro de este tipo de ambientes se establecen los siguientes tipos de algoritmos a utilizarse:

182 11 Round Robin. Balanceo llamado FIFO (First in First Out) donde el nodo director envía las peticiones al primer servidor activo, manteniendo así hasta llegar al último, luego del cual se regresa al primer servidor activo. Servidor con menos conexiones activas. Este posee un mecanismo de consultas continuo de los servidores reales, verificando el número de conexiones activas que tengan cada uno. Basados es esa consulta asigna un nuevo requerimiento del cliente a aquel servidor que tenga menos conexiones activas. Debido a la homogeneidad de los equipos servidores, el algoritmo robin round en el tipo más sencillo para realizar el balanceo de carga, obteniendo un mejor comportamiento. Aunque existe un riesgo de que toda la carga pesada vaya a un mismo servidor, mientras que el resto de servidores reciben carga más liviana, existiendo un desbalance en la carga transaccional. El algoritmo con menos conexiones activas es el más idóneo, debido a que permite repartir la carga equitativamente, a través de las conexiones que tiene un determinado servidor, logrando un adecuado funcionamiento entre los servidores, con un rendimiento similar. Debido a este procesamiento similar, el número de conexiones activas van a ser equilibradas razón importante del porque se determino utilizar este tipo de mecanismo de balanceo.

183 12 Análisis del tipo de balanceo de carga en ambientes heterogéneos Para establecer el tipo de algoritmo a utilizar en este tipo e ambientes, donde el performance depende de las características de un determinado servidor, se debe de realizar un análisis de los siguientes: Round Robin ponderado. Similar al robin round, a diferencia que agrega un parámetro adicional a cada uno de los servidores el cual depende de su potencia de cálculo, donde él con mayor potencia de cálculo recibirán mayores conexiones que los que poseen menor capacidad. Servidor con menos conexiones activas ponderado. Técnica que basa su funcionamiento en el método de balanceo con menos conexiones activas, al igual que Round Robin ponderado asigna pesos a los servidores basándose en su potencia de cálculo, de esta manera se elimina el problema de saturar los servidores. Además de verificar las conexiones activas existentes en los servidores Menos conectado basado en servicio. Su funcionamiento se basa en enviar todas las peticiones a un mismo servidor real hasta sobrecargarlo, luego de esta saturación ejecuta la técnica menos conexiones activas ponderada asignándoles pesos a los servidores.

184 13 El tipo de mecanismo de balanceo Round Robin ponderado es el mecanismo más sencillo de distribución de carga existente para ambientes heterogéneos, pero no es fiable cuando existe gran demanda de acceso a los servicios, debido a que los servidores de mayor potencia de cálculo estarán más ocupados. El tipo de balanceo basado en menos conectado basado en servicio y servidor con menos conexiones activas ponderado básicamente tienen la misma función, la diferencia se da en que el tipo de balanceo menos conectado basado en servicio saturar a cada servidor con conexiones desde el nodo director y luego del cual aplica el método servidor con menos conexiones activas ponderado para determinar cuál es el siguiente servidor a redirigir las peticiones de los clientes. Ambos ofrecen ventajas al considerar en este tipo de ambientes heterogéneos. Determinación de la herramienta de instalación de LVS Anteriormente se detallo las herramientas que son caso de estudio para el presente proyecto, se debe aclarar que en el internet existen varias soluciones entre las cuales se escogió las más conocidas y usadas, brindando resultados beneficiosos. Ipvsadm. Herramienta utilizada para configurar los servidores virtuales utilizando LVS, este mecanismo de fundamenta en una serie de comandos que permiten desde añadir y quitar servicios y servidores, asignar pesos a servidores, añadir los distintos tipos y mecanismos de balanceo de carga; entre otros.

185 14 Piranha. Herramienta propietaria a RedHat.Inc, la cual incluye mecanismos para garantizar alta disponibilidad y balanceo de carga de un determinado sistema. A diferencia de ipvsadm ofrece una interfaz gráfica de configuración. Además ofrece el balanceo de carga con demonios administrados por Ipvsadm. Ultramonkey. Herramienta de uso libre, la cual permite configurar un cluster de alta disponibilidad y balanceo de carga, la desventaja es que no ofrece una interfaz grafica para los servicios que ofrece, se basa en los demonios mon, heartbeat y fake. Heartbeat. Esta herramienta ofrece alta disponibilidad y basa su funcionamiento de acuerdo a la combinación de mon+heartbeat+fake+coda. Al igual que Ultramonkey a diferencia de que permite administrar el cluster a través de una interfaz grafica que se presentara más adelante. Heartbeat+Ldirectord. La diferencia del anterior es que Ldirectord será quien realice la monitorización, en vez de realizarla el demonio mon; la diferencia de mon es que ldirectord únicamente permite monitorear servicios http y https. Una vez descrito las características de las soluciones planteadas, Piranha se descarta debido a que los demonios que posee son de uso propietario. Ipvsadm es la base de las demás soluciones planteadas, debido a que utilizan este paquete para ofrecer balanceo de carga y alta disponibilidad según el caso.

186 15 Ultramonkey es una solución completa, pero debido a que no permite una interacción amigable al usuario se la descarto. Quedando así heartbeat el cual ofrece las mismas características de funcionabilidad en relación a las demás; además actualmente existe una interfaz grafica que permite gestionar este servicio, siendo mon el encargado de monitorear los servicios funcionales del cluster previamente configurados con esta solución. Debido a que el presente proyecto busca solucionar la demanda web, se opto por heartbeat+ldirectord donde el segundo se encarga de monitorear solo aquellos servicios http y https los cuales son el objetivo de la propuesta. LVS INSTALACIÓN La arquitectura de cluster basa en enrutamiento directo, donde el algoritmo conexiones menos activas ha sido seleccionado, implica una serie de instalaciones y configuraciones las cuales se detallan a continuación. BALANCEO DE CARGA CON LDIRECTORD Y HEARTBEAT LDIRECTORD Configuración de los Servidores Reales 1. Los servidores deben de tener un servicio en común, y estos deben de encontrarse en ejecución al momento de que ldirectord verifique el correcto funcionamiento, para lo cual se ha creado un archivo index.html el cual es el sitio web dispuesto para el prototipo.

187 16 # service httpd status # echo foo > /var/www/html/test.html 2. Definimos la IP virtual en cada uno de los servidores Web, para esto se creara una segunda interfaz de red en cada servidor. # vi /etc/sysconfig/network-scripts/ifcfg-lo:0 DEVICE=lo:0 IPADDR= NETMASK= ONBOOT=yes NAME=loopback 3. Al tener los servidores Web la misma interfaz de red virtual existe un problema con el ARP al momento de resolver la dirección MAC contra la dirección IP. a. Una posible solución es implementar arptables_jf. Para esto se debe realizar lo siguiente. #yum install arptables_jf -y #chkconfig arptables_jf on #arptables -I IN -d j REJECT #arptables -A OUT -d j mangle --mangle-ip-s #arptables -A OUT -d j mangle --mangle-ip-s #service arptables_jf save && service arptables_jf restart

188 17 b. Otra posible solución consiste en desactivar ARP para la IP virtual en los servidores reales, mediante la configuración de los siguientes parámetros. #vi /etc/sysctl.conf net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.eth0.arp_announce = 2 # sysctl -p # ifup lo:0 Configuración del Servidor director (balanceador de carga) 1. Instalación de los paquetes necesarios para ldirectord y heartbeat. # yum -y install heartbeat heartbeat-ldirectord heartbeat-gui ipvsadm # chkconfig --add ldirectord # chkconfig --del heartbeat 2. Permitir en reenvío de IP, cambiando el parámetro net.ipv4_forward a 1. # cat /etc/sysctl.conf sed 's/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/g' > /etc/sysctl.tmp # mv -f /etc/sysctl.tmp /etc/sysctl.conf # grep 'ip_forward' /etc/sysctl.conf # sysctl -p

189 18 3. Configurar eth0 para la IP virtual en los servidores Web para permitir la salida al exterior de la red local. Este archivo deberá ser replicado tanto en el nodo director, como en el nodo de respaldo (backup). #cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfgeth0:0 #vi /etc/sysconfig/network-scripts/ifcfg-eth0:0 DEVICE=eth0:0 BOOTPROTO=none NETMASK= IPADDR= GATEWAY= TYPE=Ethernet ONPARENT=yes #service network restart 4. Creamos el archivo de configuración ldirectord.cf en el nodo director y de respaldo, el cual deberá contener lo siguiente: # vi /etc/ha.d/ldirectord.cf checktimeout=10 checkinterval=2 autoreload=yes logfile="/var/log/ldirectord.log" quiescent=no virtual= :80

190 19 real= :80 gate real= :80 gate service=http request="test.html" receive="foo" scheduler=lc protocol=tcp checktype=negotiate # service ldirectord start Al editar este archivo se debe de respetar las sangrías, debido a que si se omite las mismas dará error el momento de cargar el servicio de ldirectord. Además las configuraciones realizadas pasos atrás se debe de realizar a nivel del servidor que servirá de respaldo al director. PRUEBAS REALIZADAS A LDIRECTORD Realizada la correcta configuración, se procederá ver las estadísticas de ldirectord con ipvsadm, por eso se deben de configurar de manera correcta los servidores en el archivo ldirectord.cf mencionado anteriormente, al omitir los servidores tratara de leer el registro tcpdump en el director y los logs de apache dentro de los servidores reales. Para realizar pruebas dentro de nuestra red se deberá escribir lo que se detalla a continuación:

191 20 Gráfico 2: Prueba Ldirectord con Ipvsadm La siguiente prueba a realizar, consiste en navegar a través de la Ip virtual del clúster, a través de la dirección: esta navegación se deberá realizar fuera del sistema de los nodos que conforman en clúster, lo cual nos dará como salida nuestro servidor Web. Gráfico 3: Prueba Ldirectord a la IP Virtual

192 21 Deshabilitar el Servicio de Ldirectord De ahora en adelante heartbeat será el encargado de permitir el arranque de ldirectord, para lo cual debemos de detener el servicio del mismo, así como quitarlo desde el inicio del sistema, para ello se deberá hacer lo siguiente: /etc/init.d/ldirectord stop /sbin/chkconfig ldirectord off HEARTBEAT En la instalación de paquetes, que se realizo previamente en el paso 1 de la configuración del nodo director, se instalo los paquetes necesarios de heartbeat en ambos nodos; es decir el nodo director, el cual está activo y el nodo de backup que es el respaldo del nodo director. Como se menciono en el capítulo 2, heartbeat monitoriza y activa el nodo de respaldo en el caso de algún fallo, además de tener la responsabilidad de que el nodo director responda a la IP virtual a través del servicio de ldirectord. Principales Archivos de Configuración 1. Procederemos a la creación de archivo ha.cf, dentro de la ruta /etc/ha.d/ha.cf, e ingresar los siguiente parámetros de configuración.

193 22 crm on logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 30 initdead 120 bcast eth0 eth1 udpport 694 auto_failback on node director.cisc.ug.edu.ec node backup.cisc.ug.edu.ec 2. Creación del archivo /etc/ha.d/authkeys con los siguientes parámetros. auth 1 1 sha1 clustercisc Donde 1 es el número de claves asociadas a esta línea, sha1 es el método de clave de firma a usar, y por ultimo clustercisc que será la contraseña que se usará para la autenticación de los nodos que formaran parte del clúster. 3. Al definir el mecanismo de autenticación sha en el archivo authkeys, se deberá otorgarle permisos de lectura. # chmod 600 /etc/ha.d/authkeys

194 23 4. Creación del archivo /etc/heartbeat/haresources en ambos nodos directores con la siguiente configuración. #Servidor Director director.cisc.ug.edu.ec \ ldirectord::ldirectord.cf \ LVSSyncDaemonSwap::master \ IPaddr2:: /24/eth0/ #Servidor Backup backup.cisc.ug.edu.ec \ ldirectord::ldirectord.cf \ LVSSyncDaemonSwap::master \ IPaddr2:: /24/eth0:0/ A continuación se procederá a replicar los archivos creados anteriormente al nodo de respaldo, se puede realizar este proceso manualmente o digitando lo siguiente. Gráfico 4: Propagación de Archivos de Heartbeat

195 24 Una vez realizado el paso anterior en ambos nodos, se procede a iniciar el servicio en el nodo director, así como en el de respaldo. Gráfico 5: Inicio de Heartbeat Verificación del Servicio Realizada las configuraciones previas, se deberá verificar la correcta configuración y sincronización de los nodos mencionados anteriormente, para llevar a cabo este proceso se ejecutara lo siguiente; teniendo como salida la sincronización online en ambos nodos. Gráfico 6: Sincronización del Nodo Director

196 25 Gráfico 7: Sincronización del Nodo Backup PRUEBAS REALIZADAS A HEARTBEAT Para comprobar el funcionamiento de ldirectord y heartbeat; realizaremos una serie de pruebas, las cuales demuestran la correcta configuración del clúster. Anteriormente se comprobó el funcionamiento del servicio ldirectord; previo a las configuraciones de heartbeat, donde se detuvo el servicio de ldirectord, para brindar alta disponibilidad, a diferencia que la monitorización la realizara ldirectord y no por medio de mon. Comprobación LVS Se verificara que el balanceo de carga se encuentre en función; para esto se ejecutará el comando ipvsadm, el mismo que se hizo en la etapa de pruebas de ldirectord. Ambos nodos (director y backup), deberán de ejecutar este proceso. Teniendo como resultado solo la salida de los servidores reales en la consola del nodo director.

197 26 Gráfico 8: Comprobación LVS en Nodo Director Gráfico 9: Comprobación LVS en Nodo Backup Comprobar Sincronización de Ldirectord Se comprobará que se está ejecutando el servicio en mención, en el nodo director; no así en el nodo backup. Para esto no se ejecutará el comando service comúnmente usado para verificar el servicio, debido a que arrojara como resultado un falso positivo.

198 27 Gráfico 10: Comprobación de Ldirectord en Nodo Director Gráfico 11: Comprobación de Ldirectord en Nodo Backup CONFIGURACIÓN DE LA CONEXIÓN DE HB_GUI Anteriormente se instalo el paquete heartbeat-gui, el cual permite una interfaz grafica al recurso heartbeat, antes de iniciar el servicio en mención; se debe de cambiar la contraseña del usuario hacluster en ambos nodos (Director y Backup), para poder acceder a esta interfaz. Para configurar la contraseña del usuario hacluster, escribir lo siguiente: /usr/bin/passwd hacluster

199 28 Acceder a la interfaz grafica que ofrece heartbeat-gui, ejecutando el comando hb_gui, el cual dará como resultado la ventana de heartbeat, iniciar sesión en el menú Connection opción loggin. Ingresara la contraseña escrita en el paso anterior. Gráfico 12: Inicio de Interfaz Gráfica de Hearbeat Recursos Antes de comenzar a configurar, se resalta la importancia de agrupar recursos; debido a la facilidad que ofrecen al momento de imponer para su correcta administración. Esta organización garantiza que los recursos que gestiona heartbeat, al momento de su ejecución empiecen por un orden especifico.

200 29 Recurso IP Virtual 1. Crear un nuevo recurso, en el menú Resources; opción Add New Item. Gráfico 13: Hb_gui - Agregar Nuevo Recurso 2. Aparecerá una ventana donde se nombrara al tipo grupo llamado load_balancer, estableciendo los demás parámetros como true. Gráfico 14: Hb_gui - Creación de Tipo de Item

201 30 Gráfico 15: Hb_gui - Creación del Grupo Load Balancer 3. Agregar el nombre del recurso vip, en Name IPaddr2, y dentro de parámetros editar el contenido de value con la dirección ip virtual del clúster Gráfico 16: Hb_gui - Creación del recurso Vip 4. Sin cerrar la ventana anterior, agregamos un nuevo parámetro llamado lvs_support, con el valor de true. Finalmente guardar las configuraciones, dando click en añadir.

202 31 Gráfico 17: Hb_gui - Creación del Parametro lvs_support Gráfico 18: Hb_gui - Guardar Recurso vip

203 32 5. Al guardar cambios, ubicarse al nivel del recurso vip, escoger la pestaña Operations, y click en Add Operation. Gráfico 19: Hb_gui - Agregar Operaciones a un Recurso 6. Dentro de esta nueva ventana, escoger en Name la opción monitor, con un intervalo de 20, tiempo de espera 10, y retardo de arranque de 0; en la opción en caso de fallo seleccionar restart. Estos valores son por defecto en milisegundos, los cuales indican que verificaría el servicio VIP cada 20 milisegundos, donde si el monitor no recibe una respuesta dentro de 10 milisegundos, intenta reiniciar el servicio en este nodo.

204 33 Gráfico 20: Hb_gui - Agregar Operación de Monitoreo a vip 7. Al aceptar la adición de una nueva operación, mostrara la operación configurada. Gráfico 21: Hb_gui - Guardar Operación de Monitoreo a vip

205 34 8. Al momento de agregar un nuevo recurso, aparecerá una ventana que pedirá la confirmación de aplicar los cambios realizados, aceptar. Gráfico 22: Hb_gui - Guardar Cambios Generales 9. Crear un nuevo recurso tipo nativo. Gráfico 23: Hb_gui - Agregar Nuevo Item Nativo

206 Asignar nombre ldirector al nuevo recurso, y escoger el grupo load_balancer creado en pasos previos. Dentro del type escoger la opción ldirectord con la clase "OCF / heartbeath". Gráfico 24: Hb_gui - Creación del recurso ldirector 11. Dentro de la misma ventana agregar un nuevo parámetro con nombre configfile, y dentro de value se establecerá la ruta del archivo de configuración de ldirectord.cf. Gráfico 25: Hb_gui - Creación del Parametro configfile

207 Una vez finalizadas las configuraciones, se debe de añadir la operación "monitor", con las mismas opciones establecidas anteriormente en vip, pero a nivel de ldirector. Gráfico 26: Hb_gui - Agregar Operación de Monitoreo a ldirector 13. Finalmente iniciar el grupo de recursos load_balancer, dando click en el icono de play debajo de la barra de menú, el cual pondrá activo el recurso en cuestión. Gráfico 27: Hb_gui - Inicio del Recurso load_balancer

208 37 INSTALACION Y CONFIGURACIÓN DE POSTFIX EN CENTOS Instalación a través de yum Primeramente remover sendmail, que por defecto se instala en CentOS. Luego instalar el paquete de postfix. #yum remove sendmail #yum install postfix Configuración de main.cf Ubicar el archivo dentro de la ruta /etc/postfix/main.cf, y modificar las variables de configuración que se detallan a continuación. Considerar la variable myhostname, la misma que cambia de acuerdo al hostname del servidor real que se configure. myhostname= realserver01.cisc.ug.edu.ec mydomain = cisc.ug.edu.ec myorigin = $mydomain inet_interfaces = all mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain home_mailbox = Maildir/ Iniciar el servicio de postfix, además de agregarlo al arranque del sistema. #service postfix start #chkconfig postfix on

209 38 Creación de usuarios Para efectos de pruebas al servicio de correo se procederá a crear los usuarios mediante los siguientes pasos: #useradd nombre_usuario Por seguridad no permitir la conexión al usuario por medio de SSH, además de establecer la respectiva contraseña a cada usuario. Mediante lo siguiente. #usermod -s /bin/false nombre_usuario #passwd nombre_usuario DOVECOT Instalar el paquete de dovecot, luego ubicar el archivo dovecot.conf dentro de la ruta /etc/dovecot.conf. Ejecutando lo siguiente. #yum y install dovecot #vi /etc/dovecot.conf Dentro del archivo, buscar la siguiente línea de código. # protocols = pop3 pop3s imap imaps Editar los parámetros y descomentando la línea quedando de la siguiente manera. protocols = pop3 imap Iniciar Dovecot y agregarlo al inicio del sistema. #service dovecot start #chkconfig dovecot on

210 39 INSTALACION Y CONFIGURACION DE SQUIRRELMAIL Squirrelmail es una aplicación webmail que puede ser instalada en la mayoría de los servidores web que tengan soporte PHP y acceso a un servidor IMAP y a otro SMTP. Está diseñado para trabajar con plugins, además de ofrecer soporte MIME, libreta de direcciones y administración de carpetas. Ejecutar lo siguiente desde el terminal. Instalación #yum y install squirrelmail Configuración Ubicarse dentro de la ruta /usr/share/squirrelmail/config/ y ejecutar el archivo conf.pl #cd /usr/share/squirrelmail/config/ #./conf.pl Aparecerá una interfaz de texto, en la cual seleccionamos la opción C para visualiza las modificaciones que se realizaran.

211 40 Gráfico 28: Squirrelmail- Inicio Seleccionar el lenguaje de preferencia Gráfico 29: Squirrelmail- Lenguaje de Preferencia Seleccionar la opción 1 y modificar parámetros como el nombre de la organización, el logotipo y las dimensiones; el mensaje en la barra de título de la ventana del navegador, el idioma a utilizar, URL y el título de la página principal del servidor de red.

212 41 Gráfico 30: Squirrelmail - Preferencias de la Organización Definir el dominio a utilizar cuando el servidor de correo no esté en el mismo sistema que el servidor web. Seleccionar SMTP debido a que postfix es el servidor de correo. Gráfico 31: Squirrelmail - Selección del Dominio & SMTP

213 42 Cambiar las opciones de Trash, Send y Drafts por Papelera, Enviados, y Borradores respectivamente. Gráfico 32: Squirrelmail - Opciones de Carpetas Escoger las extensiones (plugins) que se consideren apropiadas. Gráfico 33: Squirrelmail - Selección de Plugins

214 43 Reiniciar apache. #/etc/init.d/httpd restart Acceder a la direccion Gráfico 34: Squirrelmail - Inicio de Sesión Web

215 44 JMETER Es una gran aplicación de escritorio realizada en Java de diseño escalable que forma parte del proyecto Jakarta, es una herramienta estable durante muchos años y con licencia Apache 2.0. Permite probar el rendimiento tanto en estática y dinámica de recursos tales como archivos estáticos, Java Servlets, scripts CGI, objetos de Java, bases de datos, servidores FTP, y demás. JMeter puede ser utilizado para simular una carga pesada en un servidor, red o un objeto para poner a prueba la resistencia o para analizar el rendimiento general en diferentes tipos de carga. Dispone de una interfaz gráfica en el que se puede dar de alta planes de pruebas, siendo cada uno de ellos un escenario de pruebas, y en cada uno de ellos, poder definir varios tipos de elementos como un servidor proxy (ejecutarlo y configurarlo), la cantidad de hilos de conexión al servidor, la frecuencia, temporizadores, controladores lógicos, peticiones http, ftp, y comprobaciones de que lo que ha realizado se ha realizado con éxito, etc. Descarga e Instalación Descargar la última versión de JMeter desde la página oficial.

216 45 Gráfico 35: Página Oficial de JMeter Descargar el archivo Zip Gráfico 36: Descarga de JMeter

217 46 Inicio de JMeter Ubicarse dentro del directorio donde se descomprimió JMeter, acceder a la carpeta bin. Posteriormente ejecutar el archivo jmeter.bat. Gráfico 37: Inicio de JMeter Después de unos segundos aparecerá la interfaz gráfica de JMeter. Gráfico 38: Interfaz Gráfica

218 47 En adelante se procederá a configurar el escenario de pruebas para el cluster. Escenarios Para comprobar el funcionamiento correcto del cluster, se establecerán dos escenarios los cuales se describen a continuación: El primer escenario consiste en realizar pruebas de funcionamiento, mediante la utilización de la herramienta telnet hacia la interfaz virtual del cluster, donde el resultado esperado debe de proceder de cualquiera de los servidores reales, el mismo que fue redirigido por el servidor director, mediante la aplicación del balanceo de carga seleccionado anteriormente. El segundo escenario consiste en verificar el funcionamiento del cluster, una vez configurado el balanceo de carga con ldirectord y la alta disponibilidad con heartbeat. Además de la disponibilidad del servicio de correo previamente configurado en los servidores reales. Esto se llevara a cabo a través de la herramienta JMeter, descrita previamente, mediante la generación de trafico http hacia la interfaz virtual del cluster.

219 48 PRUEBAS TELNET A LA INTERFAZ VIRTUAL Para efectuar esta prueba, se debe de ejecutar del lado del cliente; debido a que este es el que accede a los servicios alojados por el cluster. Donde cualquier servidor real debe poder responder al requerimiento solicitado. La figura siguiente muestra el proceso efectuado para verificar el correcto funcionamiento del cluster. Gráfico 39: Prueba Telnet a la IPV Obteniendo como resultado la opción de login hacia el servidor real que ha atendido al requerimiento solicitado.

220 49 PRUEBAS CON JMETER Primeramente se establecerá el plan de pruebas respectivo, que permite crear y administrar esta herramienta OpenSource. Existe un detalle explicito de cada elemento configurable de este entorno de Apache, el mismo que se encuentra disponible en el sitio oficial de JMeter. Creación del Plan de pruebas Primeramente seleccionar la opción Plan de pruebas que se observa en la interfaz de JMeter, sobre la cual se desplegara del lado izquierdo la ventana donde se describirá el nombre del Plan de pruebas, al que llamaremos Test Cluster CISC. Gráfico 40: JMeter - Creación Test Cluster CISC

221 50 Sobre el Test Cluster CISC, pulsar el botón derecho y seleccionar opción Add Threads(Users) Grupo de Hilos, donde se definirán el número de iteraciones a simular, aparecerá una ventana donde se definirá el nombre del grupo de hilos a generar la misma que se le asigno el nombre de grupo de Hilos Clúster, Dentro de esta ventana se configuro los parámetros de: Número de hilos que es el número de iteraciones a ejecutarse durante un periodo de 3 segundos, cuyo intervalo entre ciclos es de 1 segundo. Gráfico 41: JMeter - Grupo de Hilos Sobre el Grupo de Hilos Cluster, pulsar el botón derecho y seleccionar la opción Añadir Elemento de Configuración Valores por Defecto para Petciciones HTTP.

222 51 En la nueva ventana se establecerá la dirección IP virtual del cluster ( ), además de establecer el puerto de escucha del servicio el mismo que por defecto es el puerto 80. Existen más parámetros pero para efectos de demostración del tema propuesto estos dos parámetros son los más significativos. Gráfico 42: JMeter - Valores por Defecto para Peticion HTTP Añadir un temporizador de retardo de cada hilo, pulsar el botón derecho sobre el Grupo de Hilos Cluster y seleccionar Añadir Temporizador Temporizador Constante. Dentro del cual se establecerá un parámetro de 300 milisegundos, que indica el tiempo de retardo de un hilo en ejecución.

223 52 Gráfico 43: JMeter - Temporizador Constante Pulsar el botón derecho sobre el Grupo de Hilos Cluster, seleccionar Añadir Muestreador Petición HTT, agregar la dirección IP Virtual del Cluster, así como el puerto del servicio de escucha. Además se agregara un parámetro que será enviado en cada petición, con el correspondiente valor asignado a la misma. Además dentro de Petición HTTP se agregara un parámetro de aserción de respuesta. Lo descrito anteriormente se describe en las siguientes figuras.

224 53 Gráfico 44: JMeter - Petición HTTP Gráfico 45: JMeter - Aserción de Respuesta

225 54 Sobre el Grupo de Hilos Cluster, seleccionar Añadir Listener Gráfico de Resultados. En el cual mostrara los resultados de la ejecución de las iteraciones de los hilos. Además existe flexibilidad de visualización de parámetros de salida que pueden ser configurables. Gráfico 46: JMeter - Gráfico de Resultados Seleccionar dentro del grupo de Hilos, Añadir Listener Ver Árbol de resultados, donde se esquematiza los resultados obtenidos, así como las ejecuciones de cada hilo. Permite guardar logs de errores, además de configurar los parámetros específicos que se desea guardar como nombre de hosts, nombre del hilo, etiquetas, cabeceras de petición, cabeceras de respuestas, etc.

226 55 Gráfico 47: JMeter - Árbol de Resultados Para finalizar, se deberá guardar los cambios efectuados a lo largo de la configuración del Plan de Pruebas. Además se debe de recordar que en ciertos pasos se omitió el proceso de modificar el nombre de ciertos parámetros, debido a que se trabajo los que la interfaz proporcionaba por defecto. Ejecución del Plan de pruebas Presionar Lanzar y seleccionar arrancar, con esto se iniciara el Test Cluster CISC, el mismo que se identificara a través de la activación del proceso mediante el encendido de color verde de la cuadricula situada en la parte superior derecha, así mostrado en la siguiente figura.

227 56 Gráfico 48: JMeter - Ejecución del Plan de pruebas Iniciado el escenario de pruebas ubicarse en la consola del servidor director y ejecutar la consulta respectiva, donde se reflejara el correcto funcionamiento del cluster; debido a que permite un balanceo equitativo de cada petición enviada por JMeter. Lo que permite evitar los cuellos de botella y sobrecarga de trabajo en un solo servidor real. Repartiendo la carga transaccional de manera que el performance del sistema no se vea afectado. La figura siguiente demuestra el correcto funcionamiento del cluster, además, se refleja en las graficas del JMeter.

228 57 Gráfico 49: Comprobación de Funcionabilidad con Dos Nodos Reales Gráfico 50: JMeter - Resultados Obtenidos con Dos Nodos Reales

229 58 Las pruebas anteriores arrojaron como resultado un rendimiento del 77,796/minuto, donde se utilizaron los dos servidores reales. Las siguientes pruebas se llevaran a cabo a través de un solo servidor real, donde únicamente este soportaba todas las peticiones generadas por JMeter, que previamente eran receptadas por el nodo director. Donde se obtuvieron los siguientes resultados. Gráfico 51: Comprobación de Funcionabilidad con un Nodo Real Se puede observar en el grafico siguiente la ventana del árbol de resultados, la estructura de la petición HTTP enviada en cada ejecución del Grupo de Hilos.

230 59 Gráfico 52: Resultados Obtenidos con 1 Nodo Real Gráfico 53: JMeter - Árbol de Resultados del Plan de Pruebas

231 60 El resultado utilizando un solo servidor, dio un incremento del tiempo invertido en el rendimiento de 1817,081/minuto. Lo que demuestra la importancia de balancear la carga de trabajo en servidores homogéneos, debido al número de transacciones que se manejan en momentos determinados. Lo que permitirá soportar un mayor tráfico de transacciones, hacia los servidores reales. Además se desarrollo un ambiente adicional que consistió en simular la caída del nodo director, el cual es el que redirecciona las peticiones hacia los servidores reales. Siendo reemplazado automáticamente por el nodo backup; el cual asumió la responsabilidad de redirigir las peticiones de los clientes. Al restaurar el nodo director, el nodo backup dejo de tener el control del redireccionamiento y devolvió el mismo al director. Esto no afecto el balanceo de carga efectuado por el cluster. Lo que permitió ser demostrado en escenarios anteriores. La carrera de Ingeniería en Sistemas Computacionales, posee un servidor destinado a la carga transaccional del servicio web, siendo la tecnología de cluster una solución a la creciente demanda de los servicios. Es importante destacar que la solución se apega a la realidad existente de la población estudiantil; basándose en la plataforma tecnológica y la carencia de recursos a la que están sujetos. El cluster es la solución para los actuales momentos de la institución.

232 61 INSTALACIÓN Y CONFIGURACIÓN DE RSYSLOG La instalación del servidor rsyslog se implementara sobre un Linux, distribución CentOS 5.5, en donde se configurara como interfaz de red lo siguiente: Dirección Ip: Mascara de Red: Gateway: Configuraciones Previas El servidor debe de contener los siguientes paquetes que se detallan a continuación: rsyslog rsyslog-mysql mysql-server php php-gd php-mysql httpd Instalar los paquetes requeridos para el rsyslog a través de lo siguiente: # yum -y install rsyslog rsyslog-mysql mysql-server php php-gd php-mysql httpd Algunos paquetes mencionados anteriormente existen instalados por defecto en CentOS, debido a esto algunos de ellos se actualizaran automáticamente al instalar la línea anterior.

233 62 Detener SysLog Antes de iniciar la configuración de rsyslog, se debe de desactivar el servicio syslog; a través de los siguientes pasos donde se detallan. # service syslog stop Desactivando el generador de logs del kernel: [ OK ] Desactivando el generador de logs del sistema: [ OK ] # chkconfig --list grep syslog syslog 0:desactivado 1:desactivado 2:activo 3:activo 4:activo 5:activo 6:desactivado # chkconfig syslog off # chkconfig --list grep syslog syslog 0:desactivado 1:desactivado 2:desactivado 3:desactivado 4:desactivado 5:desactivado 6:desactivado Configuración de MySQL Al igual que se realizo la configuración para permitir ejecutar la interfaz web Ipvsadmin. Crear la base de datos que guardar los permisos de los usuarios. Esto debe realizarse antes de iniciar el servicio en cuestión. # mysql_install_db # /sbin/service mysqld start # chkconfig mysqld on Cuando se realiza la instalación de mysql en CentOS no ofrece la configuración del usuario root, debido a esto se ejecuta el siguiente comando para poder asignar un password seguro a este usuario.

234 63 # mysqladmin u root password password ; En pasos previos se instalo los paquetes necesarios para instalar el servidor rsyslog, los mismos que serán necesarios una vez instalada la base de datos. Primeramente se deberá comprobar si el demonio rsyslog está instalado e iniciado, así mismo se deberá agregar al inicio del sistema. # rpm q rsyslog rsyslog-mysql # chkconfig rsyslog on Se deberá crear la estructura de la base de datos que utilizara rsyslog, se deberá exportar una plantilla de la base de datos que proporciona rsyslog la cual se encuentra dentro del directorio /usr/share/doc/rsyslog-mysql /createdb.sql # mysql -u root -p < /usr/share/doc/rsyslog-mysql /createdb.sql # mysql -D ipvsadm -u root -p Enter password: Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 Server version: Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use rsyslog; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed

235 64 Configuración de rsyslog.conf Editar el archivo rsyslog.conf, ubicado en la ruta /etc/rsyslog.conf, agregando las siguientes configuraciones que permitan a rsyslog escribir en la base de datos. $ModLoad ommysql.so *.* :ommysql: ,rsyslog,root,root; La estructura de la segunda línea y los parámetros que estos implican se detalla de la siguiente forma: *.* :ommysql:<ip_servidormysql>,<nombre_base_datos>,<username>,<password> El servidor de syslog puede ser configurado para funcionar en la capa de transporte sobre TCP o UDP, agregando según sea el caso TCP o UDP por el puerto por defecto 514 las siguientes líneas. $ModLoad imtcp.so $InputTCPServerRun 514 $ModLoad imudp.so $UDPServerRun 514 Modificar el archivo /etc/sysconfig/rsyslog, cambiando la directiva SYSLOGD_OPTIONS= -r -m 0 para permitir clientes de syslog remotos. Luego reiniciar el servicio de rsyslog, y verificar el si el puerto especificado está siendo utilizado por este servicio.

236 65 # service rsyslog restart Desactivando el generador de logs del sistema: [ OK ] Iniciando logger del sistema: [ OK ] # netstat -uan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State udp : :* udp : :* udp : :* udp : :* udp : :* udp : :* udp : :* udp 0 0 :::514 :::* udp 0 0 :::48329 :::* udp 0 0 :::5353 :::* RECOMENDACIÓN: Habilitar en el firewall la regla que permita establecer la comunicación hacía el servicio de rsyslog, ejecutando lo siguiente: # iptables -A INPUT -p udp -m udp --dport 514 -j ACCEPT # service iptables save && service iptables restart El servidor rsyslog se encuentra funcional, pero este servicio no ofrece una interfaz de administración agradable; debido a eso se implementará una administración opensource llamada LogAnalizer, que permite gestionar los logs de los clientes a través de un conjunto de aplicaciones LAMP y GD (para reportes gráficos).

237 66 INSTALACIÓN Y CONFIGURACIÓN DE LOGANALYZER Configuraciones previas Comprobar los paquetes necesarios, instalados en pasos previos, mediante la ejecución del siguiente comando. # rpm -q httpd php php-mysql gd php-gd Descargar el paquete de instalación desde y proceder a descomprimirlo. # tar -xvf loganalyzer tar.gz Mover el directorio resultante del paso anterior a /var/www/html, con un nuevo nombre, y asignar permisos de acceso a la carpeta. # mv tar -xvf loganalyzer /var/www/html/loganalyzer Configuración de httpd.conf Ubicar el archivo de configuración de apache ubicado en /etc/httpd/conf/httpd.conf y editar los siguientes parámetros. En el parámetro: Listen 80 cambiar por Listen :80 En la línea: Options Indexes FollowSymLinks que se encuentra dentro de la directiva <Directory "/var/www/html"> quitar la palabra Indexes Para indicar que en el momento

238 67 que no encuentre un archivo index no deje de listar el contenido de la carpeta html, ni sus subdirectorios. En la directiva <Directory "/var/www/error"> modificar Allow from all por Allow from Descomentar la directiva: #NameVirtualHost *:80 por NameVirtualHost :80 Modificar la directiva <Virtualhost *.80>, junto con los parámetros contenidos dentro de la misma. <Virtualhost :80> DocumentRoot /var/www/html/loganalyzer/src ServerName syslog.cisc.ug.edu.ec ErrorLog logs/ syslog.cisc.ug.edu.ec-error_log CustomLog logs/ syslog.cisc.ug.edu.ec-access_log common </Virtualhost> Reiniciar el servicio de apache # service httpd restart

239 68 Configuración de Loganalyzer Para iniciar la configuración ingresar desde un navegador web la dirección donde se llevara a cabo el siguiente proceso detallado a continuación: Gráfico 54: Loganalyzer - Inicio de Instalación Aparecerá una ventana que será el asistente de configuración, dar click en here. Gráfico 55: Loganalyzer - Prerequisitos Consecuentemente verificara los permisos necesarios para proceder con el proceso de configuración, antes de dar click en Next se necesitan otorgar los permisos de escritura a config.php a través de lo siguiente.

240 69 # cd /var/www/html/loganalyzer/ # chgrp apache src R # chmod apache src -R Gráfico 56: Loganalyzer - Verificación de Permisos En la siguiente dejar la primera sección por default, y proceder a habilitar la opción Enable user Database, donde se especifica una nueva base de datos, la cual contendrá toda la estructura de la aplicación loganalyzer. Gráfico 57: Loganalyzer - Configuración Basica

241 70 Crear la base de datos loganalyzer, cuya estructura será generada por el asistente de configuración de loganalyzer. Además permitir al usuario loganalyzer acceso a la base de datos, a través de lo siguiente. # mysql -D ipvsadm -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 Server version: Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> create database loganalyzer; Query OK, 1 row affected (0.00 sec) mysql> grant all privileges on loganalyzer.* to loganalyzer@localhost identified by loganalyzer ; Query OK, 0 rows affected (0.00 sec) Gráfico 58: Loganalyzer - Configuración de la Base de Datos

242 71 Es importante seleccionar la opción yes en el parámetro require user to be loggedin, para solicitar un usuario para poder iniciar la sesión. Proceder a dar click en Next, pare generar la estructura de la base de datos mencionada anteriormente. Gráfico 59: Loganalyzer - Creación de Tablas A continuación se indica en la ventana siguiente los resultados del proceso de creación de la estructura en la base de datos. Gráfico 60: Loganalyzer - Revisión de Resultados SQL Creación de la Cuenta Administrador del Syslog Establecer el username y password de la cuenta principal del administrador de la aplicación loganalyzer.

243 72 Gráfico 61: Loganalyzer - Creación de la Cuenta Administrador Seleccionar el tipo de origen MYSQL Native, y especificar el nombre de la base de datos rsyslog, el usuario rsyslog y password creados al inicio de la configuración del servicio mysql. Gráfico 62: Loganalyzer - Creación de Fuentes para los Mensajes del Syslog Efectuado el paso anterior, mostrara a continuación la siguiente ventana que finaliza la instalación de loganalyzer. Procediendo a iniciar la sesión en la aplicación instalada y configurada.

244 73 Gráfico 63: Loganalyzer - Finalización de Instalación Inicio de sesión Acceder al loganalyzer a través de la dirección: Gráfico 64: Loganalyzer - Inicio de Sesión Al iniciar sesión aparecerá el error que se muestra, debido a la configuración de la tabla SystemEvents. Debido a que anteriormente era necesario configurar este parámetro en minúsculas. Por lo que se procede a realizar el cambio a través del menú Admin Center Sources Edit Source

245 74 Gráfico 65: Loganalyzer - Error de Sesión Gráfico 66: Loganalyzer - Sources Aparecerá la ventana de configuración Source Option, cambiando el parámetro Database Tablename por SystemEvent. Gráfico 67: Loganalyzer - Parámetro SystemEvent

246 75 Cerrar la sesión e iniciar nuevamente, para poder visualizar los eventos guardalados en cada uno de los logs de los nodos del cluster a través de la interfaz que ofrece loganalyzer. Gráfico 68: Loganalyzer - Monitoreo de Logs Además se podrá visualizar las estadísticas de los eventos por cada nodo a través de la opción Statistics. En donde se visualizan cuadros estadísticos de cada evento suscitado en un nodo específico.

247 76 Gráfico 69: Loganalyzer - Statistics Configuracion de Syslogs en Nodos del Cluster Editar el archivo /etc/syslog.conf, y agregar el siguiente parámetro. Los *.* definen todo tipo de log generado por los nodos, si se configuro el servidor con TCP se debe utilizar el y si se especifica otro puerto que no sea el puerto por default debería detallarse de la siguiente Algunos de los tipos de logs que son configurables mediante el parámetro *.* son:

248 77 Tabla 3: Prioridades Syslog Numerical Code Keyword Facility 0 kern Kernel 1 user Regular user processes 2 mail Mail system 3 daemon System daemons 4 auth Security (authentication and authorisation) related comands 5 syslog Syslog internal messages 6 lpr Line printers system 7 news NNTP subsystem 8 uucp UUCP subsystem 10 authpriv Private authorisation messages local 0-7 Site specific use Tabla 4: Facilidades Syslog Numerical Code Keyword Facility 0 emerg Emergency: system is unusable 1 alert Alert: action must be taken inmediately 2 crit Critical: critical conditions 3 err Error: Error conditions 4 warning Warning: warning conditions 5 notice Notice: normal but significant conditions 6 info Informational: informational messages 7 debug Debug: debug level messages

249 78 ADMINISTRADOR IPVSADM Ipvsadmin es una interfaz web basada en php, que permite la configuración y administración de servicio ldirectord. Permitiendo gestionar el balanceo de carga de los servicios que utiliza el ldirectord. Configuraciones Previas Antes de empezar a configurar el balanceo de carga a través de la interfaz web creada para dicho propósito; se debe de verificar que se encuentre instalados los siguientes paquetes que se detallan a continuación: httpd mysql mysql-server php php-gd php-mysql openssh Para verificar si los paquetes mencionados anteriormente se encuentran instalados, se ejecuta lo siguiente: #rpm q nombre_del_paquete Caso contrario, se deberá instalar los paquetes, ya sea a través de rpm o yum #yum -y install mysql mysql-server php php-gd php-mysql openssh

250 79 Configuración de MySQL Antes de iniciar el servicio de base de datos, se procederá a crear la base de datos que guardara los permisos de los usuarios. # mysql_install_db #/sbin/service mysqld start Una vez realizado el paso anterior, cargar el script de la base de datos ipvsadm correspondiente a la estructura de las tablas de la base en mención. Posteriormente verificar si la base se cargo exitosamente. # mysql -u root -p < /var/www/html/ipvsadmin/ipvsadmin.sql # mysql -D ipvsadm -u root -p Enter password: Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 Server version: Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql>show databases; Database information_schema ipvsadm mysql test rows in set (0.00 sec) + +

251 80 Comprobación de la estructura de la base Verificar la estructura de la base de datos a través de lo siguiente. mysql>show tables; Tables_in_ipvsadm evento_directivas_globales evento_real evento_virtual global_settings nodo_director opciones_balanceo opciones_redireccionamiento plantilla_servicio puerto usuarios rows in set (0.00 sec) + + Configuración de apache Para permitir que la interfaz web sea accesible desde equipos externos, realizar la respectiva configuración del archivo httpd.conf. # vi /etc/httpd/conf/httpd.conf Dentro del archivo httpd.conf, ubicar el parámetro DirectoryIndex y agregar index.php en la siguiente línea. DirectoryIndexindex.php index.html index.html.var

252 81 Copiar la carpeta ipvsadm dentro de la ruta var/ww/html, y otorgarle permisos de acceso. #chmod 700 /var/www/html/ipvsadmin Configuración de PHP Comprobar la versión de php a través de lo siguiente: #php v PHP (cli) (built: Nov :47:37) Copyright (c) The PHP Group Zend Engine v2.1.0, Copyright (c) Zend Technologies La versión de php en CentOS 5.5 que viene por defecto es Actualizar la versión a la 5.3, mediante lo siguiente. # rpm -ivh -i`/webtatic-release-5-1.noarch.rpm Recuperando advertencia:/var/tmp/rpm-xfer.tdkjp0: CabeceraV3 DSA signature: NOKEY, key ID cf4c4ff9 Preparando... ########################################### [100%] 1:webtatic-release ########################################### [100%] # yum --enablerepo=webtatic update -y php Habilitar etiqueta corta Cambiar el siguiente parametro short_open_tag = On para que permita los tags cortos como <? Código_php?>.

253 82 Configuración SSH La interfaz web está centrada puntualmente hacia dos aspectos. El primero de ellos en proporcionar el archivo de configuración de ldirectord.cf que es utilizado por el servicio con el mismo nombre. El segundo aspecto y el más importante es configurar las interfaces virtuales en los nodos directores y en los nodos subyacentes (nodos reales). Para poder ejecutar este proceso, es necesario configurar a todos y cada uno de los nodos que conforman el cluster (servidores directores y reales) una llave criptográfica publica que permita ejecutar comandos entre los nodos. Dentro del contexto del proyecto se estableció utilizar cuatro nodos (2 directores y 2 reales), realizando la siguiente configuración encada uno de ellos. Generar claves RSA Ejecutar ssh-keygen -t rsa en todos los nodos para generar las claves RSA. Al ejecutar este comando preguntara la ubicación donde se guardara esta clave, además de pedirnos un password y su confirmación. Por defecto solo presionar enter. Al final se obtendrá un archivo llamado id_rsa.pub. # ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again:

254 83 Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 5c:dd:2a:ef:7e:c5:2d:50:0f:9b:b2:ae:97:53:3c:1d Replicación de claves RSA Replicar cada una de las claves id_rsa.pub a los nodos del cluster (incluso a sí mismo), a través de la ejecución de los siguientes comandos. Replicando clave desde Nodo Director # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_director.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_director.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_director.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_director.pub Replicando clave desde Nodo Backup # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_backup.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_backup.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_backup.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_backup.pub Replicando clave desde Nodo Real 1 # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_server_real01.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_server_real01.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh id_rsa_server_real01.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_server_real01.pub

255 84 Replicando clave desde Nodo Real 2 # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_server_real02.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_server_real02.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_server_real02.pub # scp ~/.ssh/id_rsa.pub root@ :~/.ssh/id_rsa_server_real02.pub Crear archivo para guardar cada una de las claves públicas, a través de lo siguiente. # touch ~/.ssh/authorized_keys # chmod 700 ~/.ssh # chmod 600 ~/.ssh/authorized_keys Escribir claves publicas en todos los nodos al archivo authorized_keys. # cat ~/.ssh/id_rsa_director.pub >> ~/.ssh/authorized_keys # cat ~/.ssh/id_rsa_backup.pub >> ~/.ssh/authorized_keys # cat ~/.ssh/id_rsa_server_real01.pub >> ~/.ssh/authorized_keys # cat ~/.ssh/id_rsa_server_real02.pub >> ~/.ssh/authorized_keys Pruebas SSH Al ejecutar el siguiente comando a través de cualquier nodo hacia otro deberá ejecutarse normalmente sin necesidad de escribir el password. # ssh root@ ifconfig # ssh root@ ifconfig # ssh root@ ifconfig # ssh root@ ifconfig

256 85 INSTALACIÓN Y CONFIGURACIÓN DE DRBD Se debe permitir a la interfaz web Ipvsadmin funcionar en ambos nodos directores, a través de un arreglo se software parecido a un RAID 1 pero a través de un dispositivo de bloque asignado a través de la red. Sincronizando las dos particiones de los dos servers directores, permitiendo que la información esté disponible al momento de existir un colapso del primero. DRDB crea un dispositivo de bloques drbd0 accesible desde ambos nodos. El servidor director primario es el que tiene acceso de Lectura y Escritura (RW) al dispositivo drbd0, cuando se escribe información sobre el dispositivo drbd0, se escribe en la partición física, y esos mismos datos se envían por TCP/IP al servidor director secundario (que sólo tiene acceso de lectura - RO) consiguiendo que ambas particiones físicas estén sincronizadas, exactamente igual que un RAID-1. Instalaciones previas Se debe de tener en consideración los siguientes paquetes antes de iniciar las configuraciones del servicio DRBD en ambos nodos directores. # yum y install drbd83 kmod-drbd83

257 86 Configuraciones Previas Para utilizar DRBD se debe de asignar un espacio libre sin particionar en cada uno de los nodos. El disco seleccionado para asignar a cada nodo director será /dev/sdb, debido a que no contiene una tabla de particiones valida, como se muestra a continuación: Gráfico 70 : DRBD - Verificar Disco Crear la partición al disco /dev/sdb a través del comando fdisk /dev/sdb. En donde se seleccionara el tamaño total del mismo para asignar como recurso a DRBD. Gráfico 71 : DRBD - Particionar Disco

258 87 Con lo anterior primero se indica una nueva partición (n), después se indicó el tipo de partición que es la primaria (p), el número de particiones y el tamaño de la única partición que se ha asignado. Indicar el tipo de sistemas de archivos que tendrá la partición (para Linux es la 83) con el comando t. Finalmente guardar los cambios (w). Gráfico 72 : DRBD - Tabla de Particiones Realizado el paso anterior, proceder a reiniciar los servers y verificar las partición /dev/sdb1 a través del comando fdisk -l. Gráfico 73 : DRBD - Comprobar Nueva Partición

259 88 Creación del Filesystem Crear el filesystem usando el comando mkfs, el mismo que permite el formateo de la unidad creada previamente, este proceso se puede observar en la siguiente imagen que se detalla. Gráfico 74 : DRBD - Formatear Partición Es importante recordar que la configuración de las particiones se debe de hacer en ambos nodos directores, debido a que en ambos la información será replicado según el caso lo amerite.

260 89 Configuración de drbd.conf Modificar el archivo /etc/drbd.conf, de acuerdo a los siguientes parámetros: # vi /etc/drbd.conf # # please have a a look at the example configuration file in # /usr/share/doc/drbd82/drbd.conf # resource r0 { protocol C; disk { on-io-error pass_on; startup { wfc-timeout 5; degr-wfc-timeout 3; syncer { rate 100M; #net { allow-two-primaries; on director.cisc.ug.edu.ec { device /dev/drbd0; disk /dev/sdb1; address :7789; meta-disk internal; on backup.cisc.ug.edu.ec { device /dev/drbd0; disk /dev/sdb1; address :7789; meta-disk internal;

261 90 Replique el archivo de configuración (/etc/drbd.conf) al segundo nodo director. # scp /etc/drbd.conf root@ :/etc/ drbd.conf 100% KB/s 00:00 Iniciar el meta-data en el disco, creando el recurso configurado anteriormente al cual se denomino r0, ejecutando lo siguiente en ambos nodos. Gráfico 75 : DRBD - Creación del Metadata Iniciar el servicio DRBD en ambos nodos directores, y verificar el inicio del servicio en ambos nodos, de tal manera que ambos nodos estén iniciados por defectos como secundarios. Gráfico 76 : DRBD - Inicio del Servicio en Nodo Director

262 91 Gráfico 77 : DRBD - Inicio del servicio en Nodo Backup Especificamos en el nodo principal del cluster (director) la configuración de Primary para iniciar la sincronización completa entre los dos nodos, ejecutando lo siguiente solo en el nodo principal. Gráfico 78 : DRBD - Establecer Nodo primario Verificar los roles de los servers que se están ejecutando actualmente, además de establecer la carpeta que contendrá la información sincronizada en ambos nodos. Proceder a crear en ambos servers una carpeta llamada replica. *** NODO DIRECTOR # mkdir /replica # drbdadm state r0 Primary/Secondary

263 92 *** NODO BACKUP # mkdir /replica # drbdadm state r0 Secondary/Primary Montar partición Virtual Solo en el servidor primario (director) montar la partición virtual /dev/drbd0 con el tipo de sistemas de archivos ext3 en el directorio /replica. # mount -t ext3 /dev/drbd0 /replica Pruebas DRBD Antes de iniciar las pruebas del servicio drbd, crear datos en el nodo director primario parar verificar la réplica hacia el nodo director secundario, mediante lo siguiente: Gráfico 79 : DRBD - Creación de Data de Prueba

264 93 El paso anterior genera cinco archivos de 100 MB cada uno, los cuales se verifican posteriormente para proceder a replicarlos al nodo director secundario. Proceder a desmontar la unidad en el primer nodo y montar el directorio replica en el segundo nodo. Proceso que se detalla a continuación. Gráfico 80 : DRBD - Prueba en Nodo Director Gráfico 81 : DRBD - Prueba en Nodo Backup Se puede observar que los archivos creados en el nodo director primario se han replicado exitosamente al nodo director secundario. Cualquier archivo agregado o eliminado en el momento que se encuentre montado en el nodo secundario, será replicado

265 94 automáticamente al momento de restablecer el montaje en el nodo primario. Posterior a esto proceder a restablecer las configuraciones al nodo principal. Gráfico 82 : DRBD - Desmontar Nodo Backup Gráfico 83 : DRBD - Montar Nodo Director Directorios a Sincronizar Específicamente sólo en el servidor principal proceder a copiar los directorios que se sincronizaran entre los dos servidores a través de la nueva partición (/dev/sdb1/). Posterior eliminar los directorios originales y crear enlaces simbólicos hacia el directorio /replica para sustituirlos. Los directorios de interés son:

266 95 /var/www /var/lib/mysql Ubicar el directorio /replica y proceder a comprimir la información de los directorios descritos anteriormente, para extraerlos dentro del directorio /replica. Consecuentemente proceder a eliminar los directorios descritos. # cd /replica # tar -zcvf var- /var/www/ # tar -zcvf var-lib-mysql.tgz /var/lib/mysql/ # tar -zxvf var- # tar -zxvf var-lib-mysql.tgz # rm -rf /var/lib/mysql/ # rm -rf /var/www/ Crear el enlace simbolico de los directorios www y mysql hacia la nueva ruta del directorio /replica. # ln -s /replica/var/www /var/www # ln -s /replica/var/lib/mysql/ /var/lib/mysql Posteriormente, editar el archivo /etc/my.cnf en ambos nodos y cambiar la variable datadir para coincidir como se muestra a continuación: [mysqld] datadir=/replica/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql

267 96 # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 # Disabling symbolic-links is recommended to prevent assorted security risks; # to do so, uncomment this line: # symbolic-links=0 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid Reiniciar los servicios de apache y mysql para que inicie de acuerdo a los cambios efectuados. # service httpd restart # service mysqld restart En el servidor director secundario remover los links simbólicos y redireccionarlos hacia la carpeta replica. # rm -rf /var/lib/mysql/ # rm -rf /var/www/ # ln -s /replica/var/www /var/www # ln -s /replica/var/lib/mysql/ /var/lib/mysql

268 97 AGREGAR DRBD A HEARTBEAT Detener los servicios que serán contralados a partir de ahora por heartbeat en ambos servidores. # chkconfig mysqld off # chkconfig httpd off Agregar los servicios configurados en el servicio DRBD al archivo de configuración /etc/ha.d/haresources, definiendo los siguientes parámetros. #Servidor Director director.cisc.ug.edu.ec \ ldirectord::ldirectord.cf \ LVSSyncDaemonSwap::master \ IPaddr2:: /24/eth0:0/ \ drbddisk::r0 Filesystem::/dev/drbd0::/replica::ext3 mysqld httpd #Servidor Backup backup.cisc.ug.edu.ec \ ldirectord::ldirectord.cf \ LVSSyncDaemonSwap::master \ IPaddr2:: /24/eth0:0/ \ drbddisk::r0 Filesystem::/dev/drbd0::/replica::ext3 mysqld httpd Configuración a través de hb_gui Dentro de los recursos nativos que se deben crear los parámetros que se muestran a continuación:

269 98 Creación de recurso nativo drbddisk_mysql Gráfico 84 : drbddisk_mysql - Atributos Gráfico 85 : drbddisk_mysql - Parámetros

270 99 Gráfico 86 : drbddisk_mysql - Operaciones Creación del recurso nativo fs_mysql Gráfico 87 : fs_mysql - Atributos

271 100 Gráfico 88 : fs_mysql - Parámetros Gráfico 89 : fs_mysql - Operaciones

272 101 Creación del recurso nativo mysqld Gráfico 90 : mysql - Atributos Gráfico 91 : mysql - Parámetros

273 102 Gráfico 92 : mysql - Operaciones Iniciar los recursos y verificar el inicio de cada uno de ellos como se muestra en el siguiente gráfico. Gráfico 93: mysql - Monitoreo Recursos

274 103 CONFIGURACIÓN IPVSADMIN Iniciar sesión en la aplicación web Ipvsadmin. Gráfico 94: Ipvsadmin - Inicio de sesión Configurar los Nodos directores (Director y Backup). Gráfico 95 Ipvsadmin - Configuración de Nodos Directores

275 104 Configurar interfaz virtual Gráfico 96 Ipvsadmin - Configuración de Interfaz Virtual Configurar interfaz virtual para el servicio httpd Gráfico 97 Ipvsadmin - Configuración del Servicio httpd

276 105 Gráfico 98 Ipvsadmin - Configuración de Parámetros httpd Configurar interfaz virtual para el servicio mysqld Gráfico 99 Ipvsadmin - Configuración del Servicio mysql

277 106 Configurar parámetros del servicio mysqld Gráfico 100 Ipvsadmin - Configuración de Parámetros mysql Configurar interfaces reales Gráfico 101 Ipvsadmin - Configuración Interfaz real http

278 107 Gráfico 102 Ipvsadmin - Configuración Interfaz Real mysql Configurar parámetros generales Gráfico 103 Ipvsadmin - Configuración de Parámetros Generales

279 108 Aplicar configuraciones una vez configuradas las distintas opciones mencionadas anteriormente. Gráfico 104 Ipvsadmin - Aplicar Congifuraciones Monitorear el balanceo de carga del cluster una vez aplicadas las configuraciones. Donde se puede observar el balanceo acorde a las configuraciones aplicadas. Gráfico 105 Ipvsadmin - Monitorear Balanceo

280 MANUAL TÉCNICO

281 ÍNDICE GENERAL APLICACIÓN IPVSADMIN... 1 Requerimientos de Software... 1 Diagrama Entidad Relación... 2 INTERFAZ INICIAL... 3 MODELO DE PROCESOS GENERAL... 3 INTERFAZ PRINCIPAL... 4 DIAGRAMA DE CASOS DE USO... 5 CÓDIGO FUENTE DE LA INTERFAZ PRINCIPAL... 6 CLASES PHP... 6 conexion.class.php... 6 configuraciones.class.php... 8 usuario.class.php... 8 puerto.class.php global_settings.class.php nodo_director.class.php directiva_global.class.php opciones_balanceo.class.php opciones_redireccionamiento.class.php parametros_virtuales.class.php evento_virtual.class.php evento_real.class.php plantilla_servicio.class.php ARCHIVOS JAVA SCRIPT nododirectorscript.js globalsettings.js... 51

282 directivaglobalscript.js virtualscript.js realscript.js monitoreo.js ARCHIVOS CSS PAGINA DE INICIO index.php login.php control.php PAGINA PRINCIPAL frames.php menupage.php logopage.php INTERFAZ NODO DIRECTOR MODELO DE PROCESO NODO DIRECTOR CODIGO FUENTE DE INTERFAZ NODO DIRECTOR ARCHIVOS PHP nododirectorindex.php nododirectorform.php nododirectorcontrol.php INTERFAZ DEVICE VIRTUAL MODELO DE PROCESO DEVICE VIRTUAL CODIGO FUENTE DE DEVICE VIRTUAL ARCHIVOS PHP globalsettingsindex.php globalsettingsform.php... 78

283 globalsettingscontrol.php INTERFAZ VIRTUAL MODELO DE PROCESO INTERFAZ VIRTUAL CODIGO FUENTE DE INTERFAZ VIRTUAL ARCHIVOS PHP eventovirtualindex.php eventovirtualform.php eventovirtualcontrol.php INTERFAZ REAL MODELO DE PROCESO INTERFAZ REAL CODIGO FUENTE DE INTERFAZ REAL ARCHIVOS PHP eventorealindex.php eventorealform.php eventorealcontrol.php INTERFAZ PARAMETROS GENERALES MODELO DE PROCESO PARAMETROS GENERALES CODIGO FUENTE DE PARAMETROS GENERALES ARCHIVOS PHP eventodirectivaglobalindex.php eventodirectivaglobalform.php eventodirectivaglobalcontrol.php INTERFAZ MONITOREO DEL CLUSTER MODELO DE PROCESO MONITOREO DEL CLUSTER CODIGO FUENTE DE MONITOREO DEL CLUSTER

284 ARCHIVOS PHP eventomonitoreoindex.php eventomonitoreoform.php INTERFAZ APLICAR CONFIGURACIONES MODELO DE PROCESO APLICAR CONFIGURACIONES CODIGO FUENTE DE APLICAR CONFIGURACIONES ARCHIVOS PHP guardarconfiguracionesindex.php guardarconfiguracionesform.php LIBRERÍAS ADICIONALES Prototype Tableorderer Bubble Tooltips SCRIPT DE LA BASE DE DATOS

285 1 APLICACIÓN IPVSADMIN Requerimientos de Software Ajax Técnica de desarrollo web que permite crear aplicaciones interactivas, que se ejecutan en el cliente mientras mantiene la comunicación asíncrona con el servidor en segundo plano. Permitiendo realizar cambios sobre las páginas sin necesidad de recargarlas, aumentando la interactividad, velocidad y usabilidad en las aplicaciones. JavaScript Lenguaje de programación utilizado para la construcción del sitio web interactuando con el código HTML a través de pequeños programas que son insertados en las páginas web, y en aquellos que son orientados a objetos. No posee licencia dado que es opensource e independiente de la plataforma en que se ejecute (Linux, Windows, Apple), permite utilizar contenido dinámico, siendo más fácil responder a las peticiones de los usuarios. PHP Es un lenguaje de programación multiplataforma del lado del servidor gratuito e independiente de plataforma, es fácil de ser interpretado, posee una gran cantidad de librerías que facilitan el desarrollo de las aplicaciones. Se integra con apache, brindando soporte de base de datos (InterBase, msql, MySQL, Oracle, Informix, PosgreSQL, entre otras), y permite la creación de paginas dinámicas junto con HTML.

286 Diagrama Entidad Relación 2

287 3 INTERFAZ INICIAL MODELO DE PROCESOS GENERAL