tesis original 13 de Mayo - dspace.unitru.edu.pe

Escuela Académico-Profesional de Informática

Facultad de Ciencias Físicas y Matemáticas

Universidad Nacional de Trujillo

Diseño e Implementación de un Sistema de Clúster de alta disponibilidad para mejorar el desempeño de los

Servidores Web.

TESIS

PRESENTADO A LOS MIEMBROS DEL JURADO

POR:

LUIS RODOLFO VALDIVIEZO ESPINO

TAMARA MILAGROS BARRENECHA CASTILLO

ASESORADO POR: ING. EDWIN MENDOZA TORRES

AL CONFERÍRSELE EL TÍTULO DE

INGENIERO INFORMATICO

Trujillo, Enero del 2013

Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT

Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/

BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

I

Presentación Señores Miembros del Jurado: En cumplimiento a las normas vigentes del Reglamento de Grados y Títulos de la Facultad de Ciencias Físicas y Matemáticas, carrera de Informática de la Universidad Nacional de Trujillo tenemos a bien poner a vuestra consideración el presente trabajo de investigación intitulado: Diseño E Implementacion un Sistema de Clúster de alta disponibilidad para mejorar el desempeño de los servidores web. Con la culminación de este trabajo de investigación se espera cumplir las exigencias formuladas en toda investigación, agradeciéndoles por anticipado las sugerencias y apreciaciones que se hiciera al respecto. Trujillo, Enero del 2013 LUIS RODOLFO VALDIVIEZO ESPINO TAMARA MILAGROS BARRENECHEA CASTILLO



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

II

RESUMEN La información, se ha vuelto un punto crítico dentro de las empresas, la necesidad de que esté disponible de manera continua, que se mantenga bien estructurada y que ésta esté disponible ante cualquier eventualidad, ha hecho que el concepto de alta disponibilidad, pase de ser una concepción teórica, a ser una necesidad para cualquier tipo de empresas desde las pequeñas empresas locales, hasta las grandes compañías transnacionales. Los clúster, se han utilizado como alternativa a los grandes supercomputadores, a precios significativamente menores. Este tipo de tecnología tiene dos ramas de uso: crear supercomputadores o sistemas de alta disponibilidad. En el diseño de clúster se definen tres tipos primarios sobre los cuales es posible mezclar para ajustarlos a las necesidades de la empresa. Estos modelos típicos son: balanceo de carga, alta disponibilidad y alto rendimiento. Esta tecnología ha sido aplicada sobre diferentes arquitecturas de software, pero la parte del sistema operativo sobre el cual se ejecutan dependerá en alto grado de varios factores, como lo son, el costo de implementación, el tiempo, el nivel de conocimiento necesario para el personal que lo debe administrar, y como se ajusta a las necesidades de la empresa. Las principales soluciones clúster se presentan sobre Windows, Solaris o alguna de las distribuciones de Linux, es por eso que el estudio se enfoca hacia ellos, sin hacer mayor énfasis en cuanto a Hardware, sino en las ventajas que presentan para el manejo de los nodos y el acceso a la información.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

III

Índice general

Presentación ....................................................................................................................... I

Resumen ............................................................................................................................ II

CAPITULO I .....................................................................................................................1

Introducción ........................................................................................................................1

1.1. Generalidades .................................................................................................................... 1

1.1.1. Título ........................................................................................................................... 1

1.1.2. Autores ........................................................................................................................ 1

1.1.3. Asesor .......................................................................................................................... 1

1.1.4. Localidad ..................................................................................................................... 1

1.2. Realidad Problemática ....................................................................................................... 2

1.3. Antecedentes ..................................................................................................................... 3

1.4. Justificación del Proyecto ................................................................................................... 8

1.5. Formulación del Problema .................................................................................................11

1.6. Hipótesis.............................................................................................................................11

1.7. Variables ............................................................................................................................ 11

1.7.1. Dependiente............................................................................................................... 11

1.7.2. Independiente .............................................................................................................11

1.8. Objetivo General ............................................................................................................... 12

1.9. Objetivos Específicos ..........................................................................................................12

CAPITULO II ................................................................................................................... 13

Marco Teórico .................................................................................................................... 13

2.1. Servidor HTTP ................................................................................................................... 14

2.1.1. El protocolo HTTP ...................................................................................................... 14



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

2.1.2. Sesiones....................................................................................................................... 15 2.2. Clúster de servidores HTTP ............................................................................................ 17 2.2.1. Balance de carga ........................................................................................................ .17 2.3. Alta Disponibilidad….. ..................................................................................................... 28 2.3.1. Características............................................................................................................. 28 2.3.2. Modelos de Alta Disponibilidad.................................................................................. 29 2.3.3. Estrategias para Alta disponibilidad............................................................................ 29 2.4. Origen y Uso de la informacion....................................................................................... 30 2.4.1. Que es la Información………………….. ............................................................................ 30 2.4.2. Fuentes de Información……………………………….... ........................................................... 31 2.4.3. Tipología de las Fuentes de la información tradicional………………………….………….……..31 2.5. Importancia de la Información de una Empresa….......................................................... 33 2.6. Como se Almacena la Informacion............................................................................ .……33 2.6.1. Almacenamiento Interno……………................................................................................ 34 2.6.2. Almacenamiento Externo ............................................................................................ 35

CAPITULO III............................................................................................................. 36

Materiales y Métodos.................................................................................................... 36

3.1. Tipo de Investigación........................................................................................................36 3.2. Población y Muestra........................................................................................................ 36 3.2.1. Población ...................................................................................................................... 36 3.2.2. Muestra ........................................................................................................................ 37 3.3. Indicador ......................................................................................................................... 37 3.4. Técnicas y Procedimientos de Recolección de Datos....................................................... 37 3.5. Métodos de Análisis de Datos ......................................................................................... 38 3.6. Métodos y Procedimientos ............................................................................................. 39 3.6.1. Método para la gestión del proyecto ........................................................................... 39 3.6.1.1 Requerimientos Funcionales y No funcionales……………………………………………….…….. 40 3.6.2. Método para la implementación de la solución informática ........................................ 41

Capitulo IV ...........................................................................................................................44 3.7 DISEÑO E IMPLEMENTACION DEL CLUSTER……………………………………….…………......………44 3.7.1 Herramientas de configuración y Administración del clúster…………………………………….44 3.8. Materiales ........................................................................................................................45 3.8.1. Caracterización de los equipos existentes que utilizaremos. ...................................... 46 3.8.2. Elementos que forman parte del clúster y su Arquitectura………………………………………..55 3.8.3. Diseño de red lógico habitual de algunas empresas en el Perú Problema…………….…56 3.8.4. Solución al problema de la red lógica y física de las empresas en el Perú………………..57 3.9. Instalación del sistema operativo ................................................................................... 58 3.9.1. Actualizaciones del sistema operativo ......................................................................... 58 3.9.2. Red LAN de comunicación tcp/ip ................................................................................. 59 3.9.3 Instalación del sistema de archivos para clústeres ó del sistema de almacenamiento distribuido............................................................................................................................... 59 3.9.4. Sistema de archivos para clústeres. ............................................................................. 59 3.10. Sistema de almacenamiento distribuido. ...................................................................... 60 3.10.1 Instalación del administrador de membrecía y mensajería. ....................................... 61 3.10.2. Instalación del administrador de recursos. ................................................................ 61 4. Implementación del clúster................................................................................................. 62 4.1. Diseño del clúster con 2 nodos ........................................................................................ 62 4.2. Requerimientos de hardware .......................................................................................... 63 4.3. Requerimientos de software ........................................................................................... 63

IV



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

4.4. Instalación y configuración del sistema operativo centos ............................................... 64 4.5. Preparativos...................................................................................................................... 64 4.6. Configuraciones adicionales ............................................................................................ 65 4.7. Instalación del sistema de almacenamiento distribuido – drbd....................................... 65 4.7.1. Visión general de drbd .................................................................................................. 66 4.7.2. Roles............................................................................................................................... 67 4.7.3. Convenciones generales de drbd ................................................................................... 67 4.7.4. Instalación de drbd ........................................................................................................ 68 4.7.5. Configuración inicial de drbd ......................................................................................... 68

4.8. Instalación del administrador de membrecía y mensajería – corosync ............................ 68

4.8.1. Componentes principales de corosync .......................................................................... 70

4.8.1.1. Grupo de proceso cerrado - cpg ................................................................................. 70

4.8.1.2. Quórum ....................................................................................................................... 71

4.8.1.3. Sincronía virtual extendida - devs ............................................................................... 71

4.8.1.4. confdb ........................................................................................................................ 71

4.8.1.5. cfg ............................................................................................................................... 71

4.9. Instalación del administrador de recursos–pacemaker…………………………………………….…… 72

4.9.1. Visión general de pacemaker ......................................................................................... 73

4.9.1. Componentes internos de pacemaker ........................................................................... 73

4.9.2. Agentes ...........................................................................................................................75

4.9.3. Tipo de recursos ............................................................................................................. 76

4.9.4. Restricciones de los recursos .......................................................................................... 77

4.9.5. Puntuaciones e infinito ................................................................................................... 78

4.9.6. Nodos de recuperación ................................................................................................... 79

4.10. Instalación de los recursos ............................................................................................... 80

4.10.1. Instalación del servidor para resolución de nombres de dominio ................................ 80

4.10.2. Instalación del servidor de transferencia de archivos ................................................... 81

4.11. Agregar un tercer nodo al clúster actual .......................................................................... 82

4.11.1. Diseño del clúster con 3 nodos .....................…………………………………………………………..….82

4.11.2. Configuración del clúster con 3 nodos .......................................................................... 84

4.11.3. Instalación del servidor web ......................................................................................... 85

4.12. Estrategia para agregar nodos adicionales al clúster ha .................................................. 85

4.13. Comandos principales para la administración del clúster ................................................ 87

Capitulo V ................................................................................................................................ 88

5. Pruebas funcionales y resultados .......................................................................................... 88

5.1. Pruebas de replicación del clúster con 2 nodos ................................................................. 88

5.2. Pruebas de migración del clúster con 2 nodos ................................................................... 91

5.3. Pruebas funcionales del clúster con 3 nodos ......................................................................92

5.4. Pruebas de migración del clúster con 3 nodos.……………………….......................................... 93

6. conclusiones y recomendaciones .......................................................................................... 95

6.1. Conclusiones ....................................................................................................................... 95

6.2. Recomendaciones ............................................................................................................... 99

Referencias ........................................................................................................................... 103

VI



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

CAPITULO I

Introducción 1.1. Generalidades

1.1.1. Título

Diseño e Implementación de un Sistema de Clúster de alta disponibilidad para mejorar el desempeño de servidores web.

1.1.2. Autores

Luis Rodolfo Valdiviezo Espino

Tamara Milagros Barrenechea Castillo

1.1.3. Asesor

Ms. Ing. Edwin Raúl Mendoza Torres.

1.1.4. Localidad

Trujillo – La Libertad.

Institución: Universidad Nacional de Trujillo.

1



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

1.3 ANTECEDENTES

1.2. Realidad Problemática.

Los servicios de las empresas siempre han sido de un alto nivel, con altas

exigencias tanto para el ingreso de información, descargas, búsquedas y sobre

todo el acceso a la información como para lograr mantenerse actualizado. A

pesar de ello es evidente que algunas empresas son de recursos económicos

muy bajos, lo cual se ve reflejado claramente en el estado de los materiales

que se les proporciona a los trabajadores y en los servicios secundarios que

se les ofrece. Un ejemplo es el servicio de página web de una empresa, más

concretamente el servicio de almacenamiento que brinda a sus trabajadores, a

pesar de ser básico este servicio ofrece:

• Acceso a la información almacenada, descargas y búsqueda. • Convocatorias Online. • Inscripción Online. • Actualización de Datos.

El servicio web funciona normalmente en los días entre convocatorias de

trabajo.

El servicio se vuelve muy lento, las páginas web requieren de demasiado

tiempo para cargarse.

Se desactivan funcionalidades del servicio como por ejemplo para

inscribirse.

El servicio queda temporalmente inactivo impidiendo que a otros usuarios no

puedas ingresar o inscribirse a las páginas web.

Las causas de este problema que se han podido hallar son:

Sobrecarga de los servidores web de las empresas debido a la gran cantidad

de usuarios que requieren el servicio de inscripción para un trabajo para

afines de su conveniencia.

2



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

1.3 ANTECEDENTES

1.3. Antecedentes

En cuanto a estudios e investigaciones hechos sobre cómo mejorar la

disponibilidad de servidores web, se tienen los siguientes: TECNOLOGÍA CLÚSTER DE ALTA DISPONIBILIDAD PARA SISTEMAS DE INFORMACIÓN

• Autor o Rubén Alfredo Barrios Toc.

o Tesis tecnología clúster de alta disponibilidad para sistemas de información

De la universidad de San Carlos de Guatemala.

• Resumen

La información, se ha vuelto un punto crítico dentro de las empresas, la necesidad de que esté disponible de manera continua, que se mantenga bien estructurada y que ésta esté disponible ante cualquier eventualidad, ha hecho que el concepto de alta disponibilidad, pase de ser una concepción teórica, a ser una necesidad para cualquier tipo de empresas desde las pequeñas empresas locales, hasta las grandes compañías transnacionales.

Los clúster, se han utilizado como alternativa a los grandes supercomputadores, a precios significativamente menores. Este tipo de tecnología tiene dos ramas de uso: crear supercomputadores o sistemas de alta disponibilidad.

En el diseño de clúster se definen tres tipos primarios sobre los cuales es posible mezclar para ajustarlos a las necesidades de la empresa. Estos modelos típicos son: balanceo de carga, alta disponibilidad y alto rendimiento. Esta tecnología ha sido aplicada sobre diferentes arquitecturas de software, pero la parte del sistema operativo sobre el cual se ejecutan dependerá en alto grado de varios factores, como lo son, el costo de implementación, el tiempo, el nivel de conocimiento necesario para el personal que lo debe administrar, y como se ajusta a las necesidades de la empresa.

o Aporte El principal aporte de este trabajo hacia la presente tesis fue sobre la forma en que se distribuyó la carga de peticiones de usuarios en el clúster: para esto se hizo uso de nodos máster encargados de recibir las peticiones y despacharlos hacia los nodos de tráfico que son los que realmente procesan la petición. Este método da una idea sobre cómo distribuir la carga en el clúster del Centro de Cálculo de una manera eficiente y aprovechando su infraestructura.

3



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

1.3 ANTECEDENTES

TOLERANCIA A FALLOS, EN CLUSTERS DE COMPUTADORES GEOGRÁFICAMENTE DISTRIBUIDOS, BASADA EN REPLICACIÓN DE DATOS.

• Autor

o Josemar Rodrigues de Souza

o Tesis - Universitat Autònoma de Barcelona Escola Técnica Superior d'Enginyeria Departament d'Arquitectura de Computadors i Sistemes Operatius.

• RESUMEN

El crecimiento de los clúster de computadores, y en concreto de sistemas multicluster incrementa los potenciales puntos de fallos, exigiendo la utilización de esquemas de tolerancia a fallos que proporcionen la capacidad de terminar el procesamiento.

El objetivo general planteado a sistemas de tolerancia a fallos es que el trabajo total se ejecute correctamente, aun cuando falle algún elemento del sistema, perdiendo el mínimo trabajo realizado posible, teniendo en cuenta que las

prestaciones disminuyen debido al overheod necesario introducido para tolerar fallos y a la perdida de una parte del sistema.

Esta Tesis presenta un modelo de tolerancia a fallos en clústeres de computadores geográficamente distribuidos, utilizando Replicación de Datos

denominado FTDR (Fauit Tolerant Data Replicafton). Está basado en la replicación inicial de los procesos y una replicación de datos dinámica durante la ejecución, con el objetivo de preservar los resultados críticos. Está orientado a

aplicaciones con un modelo de ejecución MasterlWorker y ejecutado de forma transparente al usuario. El sistema de tolerancia a fallos diseñado, es configurable y cumple el requisito de escalabilidad.

Se ha diseñado un modelo funcional, e implementado un Middleware. Se propone una metodología para incorporarlo en el diseño de aplicaciones paralelas. El modelo está basado en detectar fallos en cualquiera de los elementos funcionales del sistema (nodos de cómputo y redes de interconexión) y tolerar estos fallos a partir de la replicación de programas y datos realizada, garantizando la finalización del trabajo, y preservando la mayor parte del cómputo realizado antes del fallo, para ello es necesario, cuando se produce un fallo, recuperar la consistencia del sistema y reconfigurar el multicluster de una forma transparente al usuario.

El Middleware desarrollado para la incorporación de la tolerancia a fallos en el entorno multicluster consigue un sistema más fiable, sin incorporar recursos hardware extra, de forma que partiendo de los elementos no fiables del clúster, permite proteger el cómputo realizado por la aplicación frente a fallos, de tal manera que si un ordenador falla otro se encarga de terminar su trabajo y el computo ya realizado está protegido por la Replicación de Datos.

4



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

1.3 ANTECEDENTES

Este Middleware se puede configurar para soportar más de un fallo simultáneo, seleccionar un esquema centralizado o distribuido, también se pueden configurar parámetros relativos a aspectos que influyen en el overhead introducido, frente a la pérdida de más o menos computo realizado.

Para validar el sistema se ha diseñado un sistema de inyección de fallos. Aunque añadir la funcionalidad ele tolerancia a fallos, implica una pérdida de prestaciones, se ha comprobado experimentalmente, que utilizando este sistema, el overhead introducido sin fallos, es inferior al 3% y en caso de fallo, después de un tiempo de ejecución, es mejor el tiempo de ejecución (runtime) tolerando el fallo que relanzar la aplicación.

CLÚSTER WEB DE ALTA DISPONIBILIDAD A TRAVÉS DE UNA RED DE ÁREA EXTENSA.

• Autores: o Alberto Moreno Ramírez.

o Trabajo de fin de Carrera. Escuela Universitaria de Informática en la

Universidad Politécnica de Madrid.

• Resumen: Este trabajo tuvo como objetivo implementar un clúster de alta disponibilidad con un balanceador de carga que reparta las peticiones sobre los diferentes servidores que a su vez actualizan información sobre bases de datos. Los servidores y base de datos forman un clúster a través de una red de área extensa (Internet).

La importancia de este trabajo está en que utilizó herramientas de software libre que están en el mercado y son de propósito general como LVS para gestionar balance de carga, demostrando que es perfectamente posible implementar un clúster de alta disponibilidad con el uso de estas herramientas. Además considera conceptos de clasificación de servidores como activo o pasivo con respecto a escrituras o lecturas en las bases de datos, pero por servicio que según estudios ven si predominan escrituras o lecturas.

• Aporte:

El principal aporte de este trabajo hacia la presente tesis es el uso de herramientas ya existentes en el mercado como el LVS (Linux virtual server) para la implementación de clústeres de alta disponibilidad. Se separó también las peticiones de los clientes en escrituras y lecturas ya que son manejadas de distinta manera. La forma como se presentó el trabajo nos dio directrices acerca de cómo implementar el modelo distribuido que se diseñó y las herramientas que se podían utilizar para implementar los algoritmos requeridos.

ESTRATEGIA DE IMPLEMENTACIÓN DE UN CLÚSTER DE ALTA DISPONIBILIDAD DE NODOS SOBRE LINUX USANDO SOFTWARE LIBRE.

5



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

1.3 ANTECEDENTES

• Autor: o Gerson Cáceres.

o Tesis de grado presentada como requisito para la obtención del título de

ingeniería de sistemas en la Universidad San Francisco de Quito.

• Resumen:

El objetivo de esta tesis es mostrar la implementación de un clúster de alta disponibilidad cuando se tienen n nodos. En teoría se puede trabajar con cualquier servicio del tipo cliente servidor, pero en este caso se trabajo con los servicios de web (HTTP), de datos (FTP) y de nombres (DNS). El trabajo se enfocó en como lograr la disponibilidad cuando algún nodo del clúster falla, para ello se implementó un protocolo de migración de servicios. Esta forma de migración requería que los servicios estén implementados en los nodos y que estos mantengan la información necesaria para funcionar por si solos en el caso de la falla del otro nodo. Es por eso que para mantener la misma información en todos los nodos se implemento Distributed Replicated Block Device (DRBD) que utilizó herramientas de sincronización como PeaceMaker para la detección y corrección de errores en el clúster y Corosync para administración de permisos y membrecías.

• Aporte:

El trabajo mostró la importancia de los datos compartidos en un clúster. Debido a que el protocolo que se implementó sirve para varios servicios, necesitan de un sistema robusto para la sincronización de los datos y para mantenerlos coherentes y sin fallas. En la presente tesis se trabajó solo con el servicio web y el servicio de base de datos, por lo que se implementó un protocolo básico de sincronización según los requerimientos que se debían tener sobre los datos.

CLÚSTER DE BALANCEO DE CARGA Y ALTA DISPONIBILIDAD PARA SERVICIOS WEB YMAIL.[42]

• Autores: o María Mercedes Sinisterra. o Tania Marcela Díaz Henao o Erik Giancarlo Ruiz López.

o Proyecto clúster de balance de carga en la Universidad Libre, Seccional

Cali.

• Resumen:

El objetivo de este proyecto fue mostrar las diversas tecnologías y soluciones que se pueden proponer frente al problema de la alta demanda de servicios por internet y la necesidad de que el sistema funcione las 24 horas del día. Se enfocó en la utilización de diversos tipos de clúster, entre ellos el diseño de un clúster con balance de carga NAT, que tiene un nodo central con salida al internet y con el cual el cliente se comunica por WAN. Este nodo estaba conectado mediante un switch a los nodos servidores web reales y hacia un servidor de datos el cual reparte la información de la página web a los servidores web. El trabajo se centró en las pautas para el diseño de este tipo de clúster y de cómo se debía representar y diagramar la interacción de sus componentes para mostrar el flujo de peticiones de un cliente y mostrar como el clúster podía mejorar la disponibilidad de un servicio web o mail.

6



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

1.3 ANTECEDENTES

• Aporte:

El principal aporte de este trabajo radica en el énfasis que le dio a la importancia de implementar un clúster con herramientas de software libre frente a una solución empresarial que podría costar mucho dinero. El trabajo explicó las ventajas de una implementación específica y que tenga en cuenta los requerimientos de la empresa. También proporcionó una estructura de cómo se debe diseñar lógicamente un clúster y como se debe mostrar el flujo de peticiones de un cliente en el clúster.

THE HAS ARCHITECTURE: A HIGHLY AVAILABLE AND SCALABLE CLÚSTER ARCHITECTURE FOR WEB SERVER [2].

o Autores:

- Ibrahim Haddad.

o Tesis en el Departamento de Ciencias de la Computación e Ingeniería

de Software. Presentado para cumplir los requerimientos del Grado de

Doctor en Filosofía en la Universidad de Concordia, Montreal.

o Resumen: El objetivo de este trabajo fue diseñar una arquitectura

de clúster de servidores web de alta disponibilidad, concentrándose en el

porcentaje de conexiones entrantes aceptadas por los servidores web,

como criterio de balance de carga, debiendo cumplir con ser escalable

con

respecto al número de procesadores a aumentar sin perder performance y

sin afectar la disponibilidad.

Lo importante de este trabajo es que ofrece un modelo de arquitectura de

clúster web la cual consiste en una red de nodos de servidores

conectados a través de redes de alta disponibilidad. Una interfaz IP virtual

que proporciona un único punto de entrada al clúster (transparente al

cliente). Se gestiona las peticiones entrantes de los clientes web a través

esquema de distribución que tiene en cuenta la capacidad del tráfico, el

cual es validado como método eficaz para distribuir el tráfico sin

perder performance.

o Aporte: El principal aporte de este trabajo hacia la presente tesis fue

sobre la forma en que se distribuyó la carga de peticiones de

usuarios en el clúster: para esto se hizo uso de nodos máster

encargados de recibir las peticiones y despacharlos hacia los nodos de

tráfico que son los que realmente procesan la petición. Este método

da una idea sobre como distribuir la carga en el clúster del Centro

de Cálculo de una manera eficiente y aprovechando su infraestructura.

7



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

1.4 JUSTIFICACION DEL PROYECTO E HIPOTESIS

1.4. Justificación del Proyecto Económica

El trabajo coordinado de varias máquinas mejora la velocidad y la fiabilidad que originalmente ofrece una sola máquina, sin caer en los altos costos de servidores de gama alta. El precio de uno de estos servidores de gama alta oscila entre los 30.000 y los 150.000 dólares; mientras que nuestro clúster, al ser un conjunto de máquinas convencionales, tiene un coste material de tan solo 15.000 dólares.

Operativa

Con el desarrollado de proyectos de este tipo, los resultados han sido muy beneficiosos para organizaciones como ejemplo tenemos a telefónica, los bancos, empresas de transportes , agrícolas , municipalidades , molinos , etc. Esta tecnología ha sido aplicada sobre diferentes arquitecturas de software, pero la parte del sistema operativo sobre el cual se ejecutan dependerá en alto grado de varios factores, como lo son, el costo de implementación, el tiempo, el nivel de conocimiento necesario para el personal que lo debe administrar, y como se ajusta a las necesidades de la empresa.

Justificación Académica

El aprendizaje, experiencia de desarrollo en redes y también para obtener el grado de Ingeniero informático.

Equidad en el acceso

Asegurando a todos los ciudadanos el acceso a la información o a los servicios provistos en forma electrónica por el sector, no importando de donde, quien y a qué hora lo requiere.

Cobertura nacional

Es decir que las transacciones puedan realizarse desde cualquier parte del país, por lo que los Clúster deben diseñarse teniendo presente esta consideración.

Novedoso El desarrollo de Sistema de Clústeres de Alta Disponibilidad es una ventaja competitiva para toda organización del estado, que se han desarrollado, siendo sus beneficios:

o Centralizar la información o Facilitar la búsqueda de datos o Disminución de costos

Importante

Las principales ventajas del manejo electrónico de la información son las siguientes: Actualización, ahorro, concentración, transportabilidad, confidencialidad, etc.; de la información. Entonces es innegable que toda entidad cuente hoy en día con un servidor de alta disponibilidad ya que el mismo es vital para realizar sus actividades de manera eficaz y eficiente.

8



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


Verificable

El desarrollo del presente proyecto posee horizontes de tiempo en los cuales se podrá verificar que las actividades que se lleven a cabo se plasmen dentro de la organización y se cumplan con los objetivos trazados; implantando al final de la investigación el Servidor de Alta Disponibilidad basado en http con todo el conjunto de herramientas que debe brindar.

Estudios

Durante mi carrera universitaria tuve la oportunidad de participar en varios proyectos para empresas de nuestro país, lo que me permitió conocer de primera mano la infraestructura tecnológica con la cuentan estas empresas. Con este antecedente puedo decir que una gran cantidad de esas empresas, sin importar su tamaño, esperan que los sistemas informáticos se conviertan en una herramienta de utilidad para los empleados, de tal manera que se mejoren y agilicen los procesos para que la empresa obtenga más beneficios. Así mismo he visto que comúnmente las empresas pequeñas y medianas de nuestro país tienden a seleccionar alguna distribución de Linux para sus servidores porque no están obligadas a pagar licencias de uso como sucede con los productos propietarios, además porque en la mayoría de casos lo único que se necesitan es que el servidor Linux provea los servicios básicos para el acceso de navegación a internet, envió y recepción de correo electrónico, transmisión de archivos, y protección en el acceso de red. En otras palabras, un servidor Linux estándar para estas empresas cumple con las funciones de Servidor Proxy, Servidor de Correo (SMTP), Servidor de transferencia de Archivos (FTP) y Servidor Firewall. Obviamente, existen casos en donde el servidor Linux va más allá de las funciones básicas, como por ejemplo: servidor de aplicaciones, servidor de bases de datos, servidor web, etc. Otra razón por la que las empresas de nuestro país tienden a seleccionar Linux como su Sistema Operativo es por su reputación de estabilidad y flexibilidad, es decir que un solo servidor es usado para cubrir una gran variedad de Sin lugar a dudas Linux posee características muy interesantes que han logrado atraer enormemente la atención de muchas empresas, no solo en nuestro país sino en todo el mundo. Sin embargo, son estas mismas características las que han creado un problema muy particular al que le he dado el nombre de “el servidor todo en uno”. Este problema consiste en que las empresas de nuestro país en su afán de reducir costos tienden a concentrar todos los servicios informáticos en un solo servidor, sin tomar en cuenta que cuando éste falle o necesite ser detenido por tareas de mantenimiento [preventivo-correctivo] la empresa prácticamente tendrá que paralizar las actividades que dependan directamente de los servicios que ofrece el servidor porque los usuarios no tendrán acceso a las herramientas de trabajo y eso ocasionará pérdidas económicas para la empresa. Con todos estos antecedentes podemos ver que si una empresa basa o confía sus operaciones en los servicios que provee un solo servidor automáticamente tiene un serio problema de redundancia y a la vez una importante necesidad de alta disponibilidad en los servicios y aplicaciones de internet e intranet, razón por lo cual propongo como parte de la solución a este tipo de problema --el servidor

9



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


todo en uno--una estrategia para la implementación de un Clúster de Alta Disponibilidad utilizando software libre GNU/Linux para ayudar a mitigar el problema de redundancia y cubrir la necesidad de alta disponibilidad de tal manera que los usuarios, empleados, ejecutivos, gerentes, accionistas, etc. de la empresa o empresas que decidan optar por esta solución tengan acceso continuo a los servicios de intranet y extranet cuando se presentan problemas con el servidor principal.

En la actualidad los servicios de computación relacionados con el Internet como el correo electrónico, la navegación Web y transferencia de archivos son una parte importante en el día a día de muchas empresas, por esta razón es necesario implementar mecanismos de redundancia que permitan que estos servicios estén disponibles la mayor cantidad de tiempo posible para los usuarios. Por esta razón se justifica la implementación de este proyecto en vista de la necesidad de mejorar la redundancia y la alta disponibilidad utilizando los servidores web de aquellas empresas que dependen de los servicios proporcionados por un solo servidor. Por otro lado es importante que las empresas de nuestro país utilicen tecnología de punta dentro de su infraestructura tecnológica para poder competir con otras empresas del país y del mundo.

ALCANCE

El alcance de este proyecto se limita al planteamiento de una estrategia para el Diseño e implementación de un Clúster de Alta Disponibilidad para mejorar los servidores web usando herramientas y aplicaciones de distribución libre para el Sistema Operativo Linux. La propuesta contenida en esta tesis proveerá los lineamientos básicos de configuración de un clúster de N nodos que luego pueden ser profundizados, perfeccionados y adaptados a las necesidades particulares de las empresas o instituciones que deseen implementarlo. Sin embargo, el número total de nodos del prototipo del Clúster desarrollado para demostrar la funcionalidad de la estrategia propuesta será de 3 nodos.

10



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


1.5. Formulación del Problema

¿Cómo es posible lograr alta disponibilidad en los servidores web en las diferentes empresas del Perú?

1.6. Hipótesis

Se mejorará la disponibilidad y la trasmisión de información de los servidores web en las diferentes empresas del Perú. Creando un Clúster de alta disponibilidad para mejorar el desempeño de los servidores web.

1.7. Variables 1.7.1. Dependiente.

Implementar y Diseñar Un Clúster de Alta Disponibilidad para mejorar el desempeño los servidores web en las diferentes empresas del Perú.

1.7.2. Independiente.

La Implementación y El diseño Con el Clúster existente Mejoraremos la conexiones de los servidores web y la información de las diferentes empresas en el Perú.

11



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

2.1 SERVIDOR HTTP 12

Tamara Barrenechea C. Luis Valdiviezo E.

1.8. Objetivo General

Comprender y Desarrollar la Implementación y un diseño lógico para mejorar la

disponibilidad y el acceso a la información de los servidores web de las diferentes

empresas del Perú.

1.9. Objetivos Específicos

� Comprender el por qué la alta disponibilidad se ha convertido en uno de los factores críticos para las empresas que manejan información. Partiendo desde el diseño hasta las diversas formas de conseguirla. Dando especial énfasis al acceso a la información por medio de la tecnología de clúster.

� Exponer los criterios necesarios para facilitar la toma de decisiones a la hora de

incorporar un sistema de alta disponibilidad a la infraestructura de la empresa.

� Presentar las opciones comerciales disponibles en el mercado actualmente, tomando como referencia a las principales distribuciones de sistemas operativos orientados a servidores.

� Presentar soluciones alternativas a las comerciales, presentando algunas

distribuciones y principales características.

� Exponer los criterios necesarios para selección de una solución de clúster a partir de su aplicación en un caso práctico.

� Plantear una estrategia para la implementación de un Clúster de Alta

disponibilidad.

� Implementar un prototipo de un Clúster de Alta Disponibilidad sobre la plataforma Linux CentOS.

� Configurar e Integrar dos nodos al Clúster de Alta Disponibilidad con 2 Servicios (FTP y HTTP).

� Configurar e Integrar un tercer nodo al Clúster de Alta Disponibilidad con 1 Servicio adicional (HTTP).

1.10. Resultados Esperados

� Tiempo de respuesta aceptable de los servidores de las empresas cuando se conectan a gran cantidad de usuarios.

� Servidores web tolerante a fallos en alguno de los componentes del clúster.

� Mejora del resguardo de la base de datos de los servidores web.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



CAPITULO II

Marco Teórico 2.1. Servidor HTTP

Un servidor web es una máquina que tiene un sitio web, utilizando el protocolo

HTTP el servidor web proporciona páginas a los clientes web (frecuentemente

navegadores), así como otros archivos de datos para aplicaciones basadas en web. El

servidor web incluye el hardware, sistema operativo, software de servidor web,

protocolos TCP/IP y el contenido del sitio (páginas web, imágenes y otros archivos).

El termino servidor web se refiere únicamente al software del servidor HTTP

(HyperText Transfer Protocol), que proporciona la funcionalidad al sitio web. HTTP es

el protocolo de la web y un servidor HTTP (llamado así porque utiliza el protocolo

HTTP para el intercambio de información con los clientes web [13]) es el software del

lado de servidor, tal como el servidor Apache, que se encarga de dar servicio a las

peticiones HTTP por parte del cliente web (frecuentemente navegadores), enviando

documentos HTML (paginas web) y archivo. Además ejecuta scripts que se

encuentran en el servidor (scripts CGI, JSP, ASP, etc.), que realizan funciones como

búsqueda en bases de datos. [11].

2.1.1. El protocolo HTTP

El Protocolo de Transferencia de Hipertexto (HTTP – “HyperText Transfer

Protocol”) es el lenguaje que clientes y servidores web usan para comunicarse entre

ellos. Es la columna vertebral de la Web [12].



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



HTTP es un protocolo de nivel de aplicación en la pila de protocolos TCP/IP, que

utiliza TCP (“Transmission Control Protocol”) como protocolo subyacente para la

transmisión de mensajes. Lo fundamental en el protocolo HTTP y la estructura de

los mensajes HTTP es [13]:

El protocolo HTTP usa el paradigma petición/respuesta, es decir que cuando un

programa cliente HTTP envía una petición HTTP a un servidor HTTP, este le

devuelve una respuesta HTTP [13].

Todas las transacciones HTTP siguen el mismo formato general. Cada petición de

cliente y respuesta de servidor tiene tres partes: Línea de petición o respuesta,

Sección de cabecera y la Entidad cuerpo del mensaje. Para informarse sobre

como el un cliente inicia una transacción HTTP puede acceder al material

bibliográfico en [12].

HTTP es un protocolo sin estado, es decir que no tiene explícitamente un soporte

para mantener cualquier tipo de información de una transacción a otra. Una

transacción es solo un simple intercambio petición/respuesta que consiste de una

petición del cliente al servidor seguido de la respuesta por parte del servidor al

cliente y no hay forma de mantener persistente la información acerca de una

sesión de pruebas sucesivas interacciones entre un cliente y un servidor [13].

A partir de HTTP 1.1, sin embargo, el servidor puede mantener la conexión

y permitir que el cliente haga peticiones adicionales. Dado que muchos documentos

tienen incluidos otros documentos como imágenes, frames, applets, etc., esto evita

la sobrecarga del cliente de tener que conectarse repetidamente al mismo

servidor. Por lo tanto, la transacción podría pasar de nuevo al principio, hasta que

el cliente o el servidor, cierre la conexión explícitamente [12].

2.1.1.1. El protocolo TCP

Transmission Control Protocol (Protocolo de Control de Transmisión) o TCP es el

protocolo que conecta a un host que envía y un host que recibe y opera en el nivel

de transporte de la pila de protocolos TCP/IP [13]. Las aplicaciones que requieren

el protocolo de transporte para proporcionar la entrega fiable de datos usan TCP

porque verifica que los datos que se entregan a través de la red estén sin errores y

en la secuencia apropiada. TCP es un protocolo fiable, orientado a la conexión

y byte- stream [14]:



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



TCP es fiable. Proporciona fiabilidad con un mecanismo llamado Reconocimiento

positivo con Re-transmisión (PAR, “Positive Acknowledgment with Re-

transmission”). Un sistema que utiliza PAR envía los datos de nuevo, a menos que

escuche del sistema remoto que los datos llegaron bien. La unidad de datos

intercambiados entre cooperantes módulos TCP se denomina segmento (véase la

Figura 2. Cada segmento contiene una „suma de comprobación‟ (checksum) que

utiliza el destinatario para verificar que los datos sean correctos). Si el segmento

de datos no es correcto el receptor lo descarta. Después de un periodo de tiempo

de espera, el módulo de envío de TCP retransmite cualquier segmento para el que

no se ha recibido un „positive acknowledgment‟.

Figura 1. Formato de Segmento TCP [14].

TCP es orientado a conexión. Se establece una conexión lógica de extremo a

extremo entre dos hosts que se comunican. La información de control „handshake‟

que se intercambia entre dos puntos extremos para establecer un diálogo antes de

transmitir los datos. El tipo de handshake utilizado por TCP se llama „negociación

de tres pasos‟ (three-way handshake) porque se intercambian tres segmentos. La

Figura 3 muestra la forma más simple del three-way handshake [14].

Figura 2. Negociación de tres pasos (Three-way handshake) [14].



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



Una vez establecida la conexión, los datos pueden ser transferidos. Cuando los

módulos cooperantes han concluido las transferencias de datos, van a

intercambiar un three-way handshake con segmentos que contienen el bit FIN

para cerrar la conexión. Es el intercambio de extremo a extremo de datos que

provee la conexión lógica entre los dos sistemas.

TCP es byte-stream. TCP ve los datos que envía como un flujo continuo de bytes,

no como paquetes independientes. Por lo tanto, el TCP se encarga de mantener la

secuencia en que los bytes se envían y se reciben. El Número de Secuencia (SYN)

y los campos de Número de Reconocimiento (ACK) de la cabecera del segmento

TCP permiten hacer seguimiento de los bytes.

TCP también es responsable de la entrega de los datos recibidos de IP a la

aplicación correcta. La aplicación, a la que los datos se dirigen, es identificada por un

número de 16-bits llamado número de puerto. El puerto de origen (Source Port) y

puerto de destino (Destination Port) se encuentran en la primera palabra de la

cabecera del segmento.

2.1.2. Sesiones

Muchas aplicaciones web interactúan con usuarios a través de una serie de

peticiones y como resultado nace la necesidad de recordar información de una petición

y otra siguiente. Al conjunto de peticiones relacionadas se le llama sesión. Las

sesiones son muy útiles para actividades como realizar operaciones de inicio de

sesión (login) y asociación de un usuario logueado con peticiones posteriores, etc.

HTTP desafortunadamente es un protocolo sin estado, lo cual significa que los

servidores web tratan cada petición independientemente de otras [15].

a. Características del Manejo de Sesiones.

Algunos métodos para el manejo de sesiones confían en la información

almacenada en el cliente. Una de las formas para implementar el almacenamiento

del lado del cliente es utilizando cookies [15]. Los cookies son usados para guardar

el estado de las aplicaciones en un navegador web y son enviados desde el

servidor web al cliente como parte de una respuesta HTTP. El navegador que

recibe la respuesta HTTP guarda el cookie y lo incluye en una siguiente petición

HTTP al mismo servidor. Los cookies tienen un límite en número y tamaño.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



También hay argumentos acerca de la privacidad y seguridad de las aplicaciones

que usan cookies, y los usuarios frecuentemente deshabilitan el soporte para

cookies en sus navegadores [16].

Una alternativa al almacenamiento de lado del cliente es mantener el estado de

una sesión de múltiples peticiones en el lado del servidor. En este enfoque, la

información acerca del cliente es almacenada en el servidor, ya sea en un archivo,

en memoria compartida o en una base de datos. La única información que el

cliente mantiene es un identificador único (ID) que el servidor genera y envía al

cliente cuando la sesión inicia. El cliente envía este valor al servidor en cada

petición posterior y el servidor puede asociarlo con la sesión apropiada. Técnicas

comunes para el seguimiento del ID de sesión son: almacenar el ID en un cookie o

agregarlo al URL de la petición (útil cuando las cookies son deshabilitadas).

Existen implementaciones de cookies en diferentes API‟s [15] y aunque las

implementaciones difieran, el manejo de sesiones envuelve típicamente un

conjunto común de tareas [16]:

Determinar si el cliente provee un ID de sesión. Si no, el cliente por primera vez

entra a la aplicación basada en sesiones entonces se genera un ID se sesión y

se crea un archivo de sesión en el servidor (ver Figura 4).

Cada sesión tiene almacenados en el archivo de sesión, los datos relacionados

a ella, para su uso posterior o para recuperar valores colocados en una sesión

en peticiones anteriores.

Termina la sesión, algunos manejadores de sesión proveen provisión para

expiraciones de sesión, es decir para terminar la sesión cuando no se necesita

durante cierto periodo de inactividad. Una sesión también puede terminar

cuando se le cierra explícitamente.

Figura 3. Interacción entre navegador y servidor cuando se hace peticiones iniciales a la aplicación basada en sesiones [16].



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


2.2 CLÚSTER DE SERVIDORES HTTP 17

2.2. Clúster de servidores HTTP

Un clúster web organiza un conjunto de servidores HTTP como un conjunto

lógico para mejorar la capacidad de almacenamiento y procesamiento y trabajan

colectivamente como si fuera un solo recurso web en la red. El clúster también

muestra una buena capacidad de expansión, cuya capacidad puede ser fácilmente

ajustada cambiando el número de servidores back-end, que están generalmente

conectados por una red de área local de alta velocidad. Peticiones de los clientes

HTTP son repartidas y enviadas de forma transparente a los servidores back-end. Los

servidores nodos trabajan simultáneamente y la capacidad de respuesta, así como la

fiabilidad de los sitios web se ven mejoradas. Para hacer uso pleno de los recursos de

procesamiento de cada servidor, es importante saber cómo organizar las peticiones de

acuerdo a la capacidad de cada nodo servidor.

La Figura 5 muestra la estructura de un clúster. El servidor front-end se llama

despachador (Dispatcher), que es la entrada del sistema clúster. Las peticiones HTTP

de los clientes llegan primero al despachador, luego se distribuyen a los servidores

back-end de acuerdo con la estrategia de balance de carga implementada y al criterio

que esta utilice [17].

Figura 4. Clúster de servidores HTTP y proceso de petición HTTP [19].

2.2.1. Balance de carga

Balance de carga es la forma de distribuir las unidades de carga (trabajos o

tareas) a través de un conjunto de procesadores que están conectados a una red que

puede estar distribuido en todo el mundo [18].

El balance de carga en servidores se define como un proceso y tecnología que

distribuye el tráfico entre varios servidores http utilizando un dispositivo basado en red.

Este dispositivo intercepta el tráfico destinado a un sitio y redirige el tráfico a varios

servidores. El proceso de balance de carga es completamente transparente para el



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



usuario final. A menudo hay docenas o incluso cientos de servidores que operan

detrás de una URL única. La Figura 6 muestra una representación simplificada del

balance de carga en servidores [19]:

Figura 5. Representación simplificada del balance de carga en servidores [19].

Load Balancer

Un balanceador de carga realiza las siguientes funciones: [19]:

Intercepta el trafico de la red (como trafico web) destinado a un sitio.

Divide el tráfico en las solicitudes individuales y decide qué servidores recibirán

dichas solicitudes.

Mantiene vigilancia sobre los servidores disponibles asegurándose que están

respondiendo al tráfico. Si no lo están, se les sacan de la lista de servidores

disponibles.

Proporciona redundancia.

Beneficios del balance de carga

Los beneficios que se pueden obtener del balance de carga son [18]:

El balance de carga mejora el rendimiento de cada nodo y por lo tanto el

rendimiento general del sistema.

El balance de carga reduce el tiempo de trabajo inactivo.

No hay problemas de inanición en procesos debido a la máxima utilización de

los recursos.

El tiempo de respuesta se acorta.

Rendimiento superior.

Mayor fiabilidad.

Extensibilidad y escalabilidad.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



2.2.1.1. Arquitecturas

Los sistemas de servidores web necesitan aparecer como un solo host al resto

del mundo, los usuarios no necesitan estar conscientes de los nombres o ubicaciones

de cada servidor. Por ello se clasifica a las arquitecturas de servidores web según la

entidad la cual distribuye las solicitudes entrantes y se identifica cuatro clases de

métodos: El primero requiere de modificación software del lado del cliente y los tres

restantes afectan uno o más componentes del clúster de servidores web [20].

Enfoque basado en el Cliente.

Enfoque basado en DNS.

Enfoque basado en el Despachador (en el nivel de red).

Enfoque basado en el Servidor.

Estos enfoques satisfacen el requerimiento de transparencia de la arquitectura.

a. Enfoque basado en el Cliente

El cliente es responsable de la selección el servidor para el procesamiento. La ruta

de réplica se realiza mediante el software de cliente (navegador) o servidores

proxy. Estos sistemas se pueden clasificar de la siguiente manera [21]:

Clientes Web

Proxy‟s del lado del cliente

La Figura 7 muestra la simplicidad de este enfoque. Una vez recibida la solicitud

del usuario (paso 1), el cliente web selecciona un nodo del clúster (paso 2) y una

vez resuelto el mapeo de la dirección (no es relevante para la selección del

servidor), envía la solicitud al nodo seleccionado (paso3). El servidor web es

responsable de responder al cliente (paso 4) solicitudes sucesivas por parte del

mismo cliente pueden alcanzar a otro servidor [20].

Figura 6. Enfoque basado en el cliente [20].



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



Clientes web.

Los clientes son conscientes de la existencia de réplicas de mismo recurso en

varios servidores y ellos mismos son los que eligen una de las réplicas. A

continuación se presentan dos ejemplos de este enfoque [21]:

Netscape. La forma de acceder al sitio de Netscape Communication a

través del navegador Netscape Navigator ha sido el primer ejemplo de

arquitectura distribuida de servidores web basada en el cliente. El reparto

de la carga es como sigue: Cuando un usuario i accede a la página de

inicio de Netscape (en el URL www.netscape.com), el navegador

selecciona un número aleatorio i entre 1 y el número de servidores y

direcciona la solicitud del cliente al nodo wwwi.netscape.com.

El enfoque de Netscape no es aplicable generalmente debido a que no

todos los sitios web tienen el privilegio de tener su propio navegador y de

distribuir la carga entre sus servidores. Este enfoque es limitado y la

selección aleatoria para repartir las solicitudes no garantiza la disponibilidad

de los servidores y el balance de carga entre los servidores [20].

Clientes Inteligentes. El ruteo de las solicitudes de los clientes es logrado

a través de un Java applet, ejecutado del lado del cliente; cada vez que un

usuario solicita un acceso al sistema de servidores web distribuido. El

applet conoce todas las direcciones IP de todos los nodos en el clúster de

servidores web, por ello envía mensajes a cada servidor para obtener

información de su estado: tiempo de respuesta y retardo en la red. Esta

información es analizada por el applet para seleccionar el servidor

apropiado. Las solicitudes del nodo cliente que ejecuta el applet son

enviadas al servidor seleccionado.

Este enfoque no requiere la modificación de software de cliente y

proporciona escalabilidad y disponibilidad pero incrementa el tráfico en la

red por los mensajes que se intercambian con los servidores, lo que causa

demoras en el tiempo de respuesta a las solicitudes del cliente [20].

Proxy’s de lado del cliente

El servidor proxy es otra importante entidad en Internet que puede despachar

las solicitudes de los clientes a servidores web. Se incluye este enfoque porque

desde el punto de vista del clúster web, los servidores proxy son bastante

similares a los clientes. Un ejemplo de esto es WLIS (Web Location and



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



Information Service) implementado en un proxy del lado del cliente que puede

hacer seguimiento de las direcciones URL replicadas y rutiar las solicitudes de

los clientes al servidor más apropiado [20].

b. Enfoque basado en DNS.

La responsabilidad de repartir las solicitudes entre los servidores es delegado al

„DNS clúster‟ que es el servidor DNS autorizado por el dominio de los nodos del

clúster. A través del proceso de traducir de URL a direcciones IP puede

seleccionar el servidor web apropiado, seleccionado mediante un conjunto de

políticas. Por otra parte, DNS tiene control limitado de las solicitudes que llegan al

clúster web. En efecto, entre el cliente y el „DNS clúster‟ hay muchos servidores

DNS intermedios que pueden almacenar en cache el nombre lógico o dirección IP

mapeada para reducir tráfico de red (almacenamiento en cache de direcciones a

nivel de red). Además los clientes web (navegadores) almacenan en cache

algunas direcciones resueltas (almacenamiento en cache a nivel de cliente). Por

ello el „DNS Clúster‟ especifica un periodo de validez, conocido como Time-To-Live

(TTL), para almacenar en cache la resolución de URL a dirección IP. Cuando

expira el TTL, una solicitud de mapeo de dirección puede ir al „DNS clúster‟. Estas

dos formas alternativas de resolución son mostradas en la Figura 8. Si un servidor

DNS intermedio mantiene un mapeo valido para el „DNS clúster‟, puede resolver la

solicitud de mapeo, sin enviarla a otro servidor DNS intermedio o a hacia el „DNS

clúster‟ (bucle 1, 3‟). De otra manera la solicitud de dirección llega al „DNS clúster‟

(paso 1,1‟), el cual selecciona la dirección IP de un servidor web y su TTL (paso 2).

El mapeo de URL a dirección IP y el valor TTL son enviados a todos los servidores

DNS intermedios dentro de la ruta (paso 3) y enviado al cliente (paso 3‟) [20].

Figura 7. Enfoque basado en DNS [20].



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



El control DNS en el almacenamiento en cache de navegadores está limitado por

lo siguiente: El periodo TTL no funciona en almacenamiento en cache de

navegadores y DNS puede no ser capaz de reducir los valores TTL a valores

cercanos de cero por la presencia de servidores DNS no cooperativos, que

ignoran TTL muy pequeños. Por otra parte, el control limitado en las solicitudes de

los clientes impide al DNS de convertirse en un potencial cuello de botella [20].

Se pueden distinguir arquitecturas basadas en DNS a través de algoritmos de

planificación que el „DNS clúster‟ usa para repartir la carga entre los nodos

servidores web. Se consideran varias políticas de selección de servidor que toman

en cuenta información de estado del sistema, y luego asigna el mismo valor TTL a

todas las solicitudes de mapeo de direcciones (algoritmos de TTL constante). Otra

alternativa son algoritmos que adaptan los TTL en base a información dinámica de

los servidores y/o clientes (algoritmos de TTL dinámico) [21].

c. Enfoque basado en el Despachador (en el nivel de red).

Es un enfoque alternativo a las arquitecturas basadas en DNS que ayuda a lograr

completo control sobre las solicitudes de los clientes y enmascara la solicitud

ruteándola entre múltiples servidores. Para este propósito, extienden la

virtualización de dirección hecho por el enfoque basado en DNS a nivel de URL, al

nivel de IP. Este enfoque provee al clúster de servidores web de una sola dirección

IP virtual (IP-SVA). De hecho, este es la dirección IP del despachador (dispatcher)

que actúa como un planificador centralizado y, contrario al DNS, tiene completo

control del ruteo de las solicitudes de los clientes. Para distribuir la carga entre los

nodos servidores web, el despachador es capaz de identificar únicamente cada

servidor en el clúster a través de una dirección privada que puede estar en un nivel

de protocolo diferente dependiendo de la arquitectura propuesta. Se pueden

diferenciar las arquitecturas basadas en despachador a través del mecanismo que

usan para rutear las solicitudes que llegan al despachador hacia el „oculto‟ servidor

web seleccionado. Las dos principales clases de ruteo son a través del mecanismo

de re-escritura de paquetes (packet rewritting) o redirección HTTP (HTTP

redirection) [20].

Las arquitecturas basadas en despachador que existen típicamente utilizan

algoritmos simples para la selección de servidores web (por ejemplo: Round-

Robin) debido a que es el despachador quien maneja todo el flujo entrante y la

cantidad de procesamiento por casa solicitud tiene que mantenerse al mínimo [20].



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



Re-escritura de paquetes (packet rewritting)

Todos los paquetes llegan primero al despachador. Todos los servidores del

clúster web tienen diferentes direcciones privadas visibles dentro del clúster. El

despachador selecciona un servidor mediante algoritmos, y cambia la dirección

del destino de los paquetes entrantes con la dirección privada del servidor

seleccionado. También mantiene una lista de direcciones IP de origen para las

conexiones activas y envía los paquetes que recibe de cada conexión TCP al

mismo servidor nodo. Los nodos servidores del clúster necesitan reemplazar la

dirección de origen en los paquetes de respuesta con la dirección IP del

despachador.

Aunque esta solución mantiene la transparencia del usuario, requiere cambios

en el kernel de todos los servidores dado que la re-escritura de paquetes

ocurre en nivel TCP/IP [21].

Redirección HTTP (HTTP redirection)

En este enfoque centralizado despachador re-direcciona las solicitudes HTTP

entre los nodos del servidor web especificando el código apropiado de estado e

indicando la dirección IP del nodo seleccionado en su cabecera. El despacho

se puede basar en la carga en los servidores o en su ubicación.

Este enfoque es transparente para el usuario, sin embargo el usuario puede

percibir un poco de retardo en las respuestas a sus solicitudes. No es

necesario re-escribir paquetes en este enfoque, pero la información de estado

del servidor, la carga, es decir, el número de conexiones, etc. deben

comunicarse a despachador en este enfoque [21]. d. Enfoque basado en el Servidor

Las técnicas basadas en el servidor usan un mecanismo despachador de dos

niveles: solicitudes de clientes son inicialmente asignadas por el „DNS clúster‟ a los

servidores web; entonces, cada servidor puede reasignar la solicitud recibida a otro

servidor del clúster. Este enfoque permite que todos los servidores participen en el

balance de carga del clúster a través de las del mecanismo de re-asignación de

solicitudes. La propuesta este enfoque difiere en la forma en la que la decisión de

redirección es tomada e implementada.

Se considera dos clases de soluciones: los basados en el mecanismo de re-

escritura de paquetes, y los que toman las ventajas de la facilidad para redirección

que provee el protocolo HTTP [20].



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



Redirección HTTP por parte del servidor

Las solicitudes de los clientes, son inicialmente asignadas del DNS al servidor

web (paso 1, 1‟, 2, 3, 3‟), pueden re-asignarse a otro servidor del clúster a

través del mecanismo de redirección del protocolo de HTTP. La Figura 9

muestra el caso donde el servidor 1 recibe una solicitud de cliente (paso 4) y

decide re-direccionar la solicitud (paso 5, 6) al servidor 2 en lugar de atenderla.

La decisión de atender o re-direccionar se puede basar en varios criterios [20].

Figura 8. Redirección HTTP por parte del servidor [20].

Redirección de paquetes por parte del servidor

El servidor que alcanza la solicitud del cliente es capaz de re-dirigir la conexión

a otro servidor a través del mecanismo de re-escritura de paquetes como, al

igual que la redirección HTTP es transparente al cliente. La Figura 10 muestra

la distribución una solicitud que llega del DNS (paso 1, 1‟, 2, 3, 3‟) y el caso

donde el servidor 1 decide re-direccionar la solicitud recibida (paso 5, 6) al

servidor 2 sin afectar al cliente.

Dos algoritmos de balance de carga son propuestos para repartir las solicitudes

de los clientes, La primera política usa una función de ruteo estático (sin

estado), donde el servidor destino de cada paquete es determinado por una

función hash aplicada a ambos: la dirección IP del que envía y el número de

puerto. Sin embargo, esta política simple no es práctica porque la

fragmentación de los paquetes IP no proveen información de puerto en cada

fragmento. El segundo algoritmo (con estado) confía en las comunicaciones

periódicas entre los servidores acerca del su carga actual. Tendiendo a la



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



redirección de las solicitudes al servidor menos cargado. Sin embargo, la re-

escritura de paquetes y el mecanismo de redirección causan un retardo que

puede ser alto en una WAN de sistemas de servidores web distribuidos [20].

Figura 9. Re-escritura de paquetes por parte del servidor [20].

2.2.1.2. Criterios de balance de carga

Existen un gran número de criterios que se pueden usar para decidir cuál de

los nodos servidores atenderá una solicitud. Si bien la mayoría hacen básicamente lo

mismo: enviar al servidor con el fin de hacer el trabajo más rápido, hay algunas

diferencias importantes que pueden cambiar drásticamente la manera en que se

maneja la carga del servidor [22]. A continuación se describen algunos criterios o

políticas para la selección de un servidor del clúster:

Round-Robin

En Round-Robin, DNS resuelve la dirección del primer nodo servidor del clúster

para la primera consulta de DNS, el segundo nodo del clúster para la segunda

consulta y así sucesivamente. Para luego re-iniciar la resolución de la dirección al

primer nodo servidor. La política de selección Round-Robin es muy popular en

esquemas DNS. Se utiliza para distribuir por igual la carga entre servidores de la

misma capacidad, suponiendo que todos los clientes generan mismo número de

peticiones. En la práctica, muchos clientes generan una carga muy alta o muy baja

resultando en una carga sesgada [23].

Tiene como ventaja que es fácil de entender y funciona de manera efectiva. Su

desventaja es que no considera la carga del servidor, por lo que potencialmente un

servidor puede estar sobrecargado con un volumen alto de peticiones, mientras



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



que otro servidor de alta capacidad se encuentra inactivo. Se utiliza mejor cuando

se conoce que las peticiones son igualmente complejas [22].

Weighted Round-Robin

En Weighted Round-Robin, se asigna a cada servidor o un peso estático medido

fuera de línea (por ejemplo servidor 2 es dos veces tan potente como servidor 1 y

3) o un peso dinámico que informa acerca de la capacidad libre del servidor al

DNS. DNS devuelve la dirección IP de un servidor, en proporción a su peso o

capacidad libre según lo informado por clúster [23].

En general supone que los servidores con un peso mayor son capaces de manejar

mayor carga. La ventaja es que usa el mismo método que Round-Robin,

agregándole la habilidad de asignar carga en proporción al peso de cada servidor.

Su desventaja es que no toma en cuenta que las diferentes conexiones pueden

requerir diferentes cantidades de carga. Se utiliza mejor cuando se conoce que las

peticiones son igualmente complejas, y se conoce la capacidad de procesamiento

de solicitudes de cada servidor para que sus pesos puedan ser asignados de

manera tal que la carga de los servidores sea distribuida efectivamente [22].

Destination hashing

Se utiliza para enviar siempre solicitudes de la misma dirección IP al mismo

servidor en el clúster. Este método es bastante útil cuando los servidores dentro

del clúster son servidores proxy o con cache [24].

Least-Connection (LC)

Cuando una nueva solicitud llega al Despachador, este mira el número de

conexiones activas e inactivas para determinar cual nodo del clúster debe recibir la

solicitud [24]. Least-Connection cuenta el número de conexiones actuales de cada

servidor. Por ello solicitudes no se concentran en un servidor específico, incluso

con una alta carga de conexiones estas se distribuyen eficientemente. El servidor

más rápido puede procesar más conexiones de red. Incluso si los servidores

varían su capacidad de procesamiento trabajarían eficientemente. Sin embargo no

se logra producir un performance satisfactorio por el TIME_WAIT de TCP. El

TIME_WAIT es usualmente dos minutos pero un sitio web con una gran cantidad

de conexiones puede tener para procesar miles de conexiones dentro de dos

minutos. Por esta razón, Least-Connection puede ser ineficiente en la distribución

de carga con servidores de diferente capacidad de procesamiento [25].



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



Response Time

El Director regularmente consulta al servidor y hace un seguimiento de los

servidores que responden más rápido. Y envía una nueva solicitud al servidor con

el más rápido tiempo de respuesta [24].

Shortest Expected Delay (SED)

El valor de sobrecarga de cada nodo del clúster es calculado agregando 1 al

número de conexiones activas. Este valor es dividido por el peso que se le haya

asignado al nodo, obteniéndose un valor SED. Pero por ejemplo si se tiene dos

servidores, pero se asume que el nodo lento (menor peso) no tiene conexiones

activas, mientras el rápido (mayor peso) tiene una conexión activa, sin embargo al

calcular el valor SED de ambos nodos, da como resultado que el nodo más rápido

tiene un valor más bajo por lo tanto el otro recibirá la próxima solicitud, esto puede

ser un comportamiento no deseable en la distribución de solicitudes [24].

Manejo de sesiones

Sin sesiones, no importa cual nodo servidor procesa cada solicitud. En el momento

que las sesiones son introducidas, es importante que las solicitudes dentro de la

sesión, sean enviadas al servidor que mantiene la sesión [26]. Las “sticky

sessions” necesitan mantenerse en el balanceador de carga de tal manera que las

siguientes solicitudes, puedan ser despachadas al servidor que recibió la solicitud

inicial. “Sticky sessions” requieren más lógica y recursos del balanceador de carga.

La mayoría de balanceadores de carga de capa 4 soporta “sticky sessions”.

Frecuentemente se establece cookies en el cliente o haciendo hash a sus

solicitudes HTTP para crear una firma del cliente [27]. Sin embargo el redirigir a un

usuario al mismo nodo por cada solicitud durante la sesión es contraria al balance

de carga. Este método crea sobrecarga adicional que es innecesaria si se utiliza

una base de datos central para guardar los datos de sesión, al que cada nodo

tiene acceso. La técnica “sticky sessions” es menos confiable porque no utiliza un

único identificador para identificar a los clientes, confiando en métricas no

confiables como la dirección IP del cliente [28].

Otra técnica que puede ser utilizada es NFS, Network File System, el cual es un

protocolo que permite compartir sistemas de archivos en la red. Esto es, una

partición NFS compartida puede ser utilizada para guardar datos en común para

todos los nodos del clúster [28].



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


2.3 ALTA DISPONIBILIDAD Y LA INFORMACION.

2.3. Alta disponibilidad y la Informacion.

El término de Alta disponibilidad (High Availability) significa que la aplicación o el

servicio en cuestión está disponible todo el tiempo sin importar la hora del día, lugar

geográfico, y otros factores que pueden influir en la disponibilidad de esa aplicación.

Es poder brindar un servicio por bastante tiempo sin interrupciones [35]. Se explicará

las principales características de un sistema altamente disponible, los modelos y

estrategias de alta disponibilidad, métricas de medición y pruebas de disponibilidad.

2.3.1. Características

Las características de un sistema altamente disponible, a medida que se

aumenta la disponibilidad son:

1. Tolerancia a Fallas: Un componente del sistema está diseñado de tal forma que,

en el evento de una falla del mismo, un componente o procedimiento de respaldo

puede inmediatamente tomar su lugar sin interrumpir el servicio [35]. También

involucra el diseño del sistema para evitar potenciales fallos debido a diversos

factores externos.

Esta tolerancia a fallas puede ser implementada por software, embebido en el

hardware o una combinación de los dos.

28 Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT


BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


2.3 ALTA DISPONIBILIDAD Y LA INFORMACION.

2. Recuperación en Caso de Desastres: Es la habilidad de poder rehabilitar un

servicio después de ocurrido un desastre. En grados extremos también incluye la

reconstrucción del centro de datos. Antes de que el servicio pueda habilitarse

nuevamente, se re quiere un tiempo significativo para reactualizar los datos [35].

3. Tolerancia a Desastres: Es el prepararse para el desastre antes de que ocurra

para poder mantener el servicio habilitado cuando ocurre. Esta característica es

mucho más difícil de conseguir que la recuperación luego del desastre ya que

involucra diseñar sistemas que soporten los desastres y seguir habilitados [35].

2.3.2. Modelos de Alta Disponibilidad

Existen dos modelos distintivos para sistemas de alta disponibilidad en

arquitecturas cliente-servidor. Ellos son [36]:

Modelo de Servicios Replicados: Utiliza aplicaciones distribuidas y base de

datos distribuidas en varios servidores conectados por LAN/WAN, donde los datos

son replicados en algunos o todos los servidores. Esto garantiza la tolerancia a

fallos ya que cuando un servidor falla, los datos y las aplicaciones son accesibles

desde otro servidor, además al tener varios servidores activos al mismo tiempo se

garantiza también el buen funcionamiento del servicio.

Modelo Failover: Utiliza una configuración de servidores duplicados. Un servidor

tiene el rol de activo y es el único que está habilitado, los otros son servidores de

respaldo que monitorearán el estado del servidor activo. Cuando se detecta alguna

falla en el hardware o software del servidor activo, algún servidor de respaldo toma

el rol de activo para mantener al servicio disponible. 2.3.3. Estrategias para Alta disponibilidad

Existen varias soluciones para proveer alta disponibilidad. Utilizar un clúster de

servidores es la solución más común para construir un servicio altamente

disponible y además escalable. Generalmente existe un nivel básico de

disponibilidad al utilizar RAID de discos y SAN‟s (Storage Area Network). En base a

una arquitectura de este tipo existen tres estrategias de alta disponibilidad [35]:

No Failover: Si se produce un fallo en el sistema, la aplicación y su base de datos

no es afectada. Esto se logra con discos de respaldo y redundancia. Con esta

29



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3.3 INDICADOR

estrategia las fallas en el sistema pueden resultar en un tiempo significativo en

donde el servicio no está activo. Dependiendo de la causa del fallo y la habilidad

para aislarla y resolverla. Por ejemplo si un CPU falla, se le necesita reemplazar y

reiniciar la aplicación mientras tanto los usuarios deben esperar a que el sistema

vuelva a estar disponible

Cold Failover: Esta estrategia se basa en mantener servidores de respaldo en

espera de fallos para luego asumir el rol del servidor activo. Una configuración

típica tiene 2 computadores idénticos que comparten el acceso a un mismo disco.

Los sistemas de respaldo van monitoreando el estado del servidor activo (lo más

común es utilizando algún mensaje corto como ICMP), y al detectar la falla asumen

el rol del servidor, esto implica una reconexión por parte de los clientes.

Hot Failover: Esta estrategia puede ser complicada y cara, pero es la que más se

acerca a la disponibilidad en un 100%. Requiere lo mismo que para el Cold

Failover pero también requiere que el estado del proceso iniciado sea preservado

para luego poder resumir su ejecución en el servidor de respaldo. Estos sistemas

son capaces de balance de carga.

2.4. ORIGEN Y USO DE LA INFORMACIÓN

La información se ha convertido en uno de los recursos más importantes dentro de las organizaciones, debido a que ella representa en gran medida el estado actual, y cómo se ha comportado anteriormente.

2.4.1 ¿Qué es la información?

Se conoce como información a un conjunto de datos que son generados por algún medio. La información son datos que han sido procesados en forma inteligible. La información se añade a una representación y dice al receptor algo que no le era conocido antes. Lo que es información para una persona podrá no serlo para otra. La información debe ser oportuna, exacta y completa.

La información es un conjunto de datos que se presentan de forma que es inteligible al receptor. Tiene un valor real percibido para el usuario y es agregado al conocimiento que se tenía respecto a un tema o suceso en un área de interés. La información transmite al receptor algo que no conocía con anterioridad o que no podía ser pronosticado.

30



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3.3 INDICADOR

2.4.2 Fuentes de información

Se considera fuentes de información a los materiales o productos, originales o elaborados, que aportan información o testimonios a través de los cuales se accede al conocimiento.

Por lo tanto, todo aquello que suministre una noticia, una información o un dato, que en definitiva, pueda transmitir conocimiento, se considera una fuente de información. En este punto también incluye los servicios, como las bases de datos, instituciones y personas.

2.4.3 Tipología de las fuentes de información tradicionales

Para clasificar las fuentes de información es necesario determinar un conjunto de características que permitan establecer su orden topológico, es decir, los criterios que nos servirán para clasificar la información como se detalla a continuación.

a) El soporte o medio en que se transmite la información

b) La facilidad de acceso al contenido

c) El nivel de información que proporcionan d) La posibilidad de acceso a las fuentes propiamente dichas e) Según el área de conocimiento que cubren

2.4.3.1. El soporte o medio en que se transmite la información

La información puede encontrarse en una gran diversidad de soportes. La escritura, ha sido históricamente, el testimonio si no único, sí fundamental sobre el que se ha levantado nuestro conocimiento del pasado. Actualmente los soportes se han multiplicado y junto con textos manuscritos o impresos encontramos también microfilms, microfichas, cintas de audio y de video, soportes magnéticos, etc.

En función de su soporte se pueden dividir las fuentes de información en:

Impresas: su soporte es el papel.

Audiovisuales: transmiten la información en forma de imagen o sonido (cassettes, discos, cintas de vídeos, películas). Necesitan aparatos para su lectura (magnetoscopios, aparatos de video, proyectores, tocadiscos, compact disc, etc.).

Mecanizadas: se presentan en forma de microformas (microficha, microfilm), soporte magnético (disquetes), o soportes ópticos (CD-ROM), o soporte electrónico. Las fuentes en soporte óptico o magnético contienen la información en forma electrónica, es decir, información digital accesible por medio de equipos informáticos.

31



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3.3 INDICADOR

2.4.3.2 La facilidad de acceso al contenido

Información inmediata: se puede obtener de la fuente misma, sin tener que recurrir a otros medios. Es información puntual y precisa. La proporcionan los manuales, enciclopedias, diccionarios, publicaciones periódicas, etc.

Información mediata o diferida: dirigida a aquellos documentos que contienen la información existente sobre una materia o campo de conocimiento. Está contenida en bibliografías, boletines de sumarios, índices, resúmenes, catálogos de bibliotecas.

2.4.3.3 El nivel de información que proporcionan

Fuentes primarias: contienen información nueva u original. Son la información resultante de forma inmediata de la investigación a la práctica profesional.

Son fuentes primarias: patentes, normas, tesis, actas de congresos, proyectos de investigación, publicaciones oficiales, publicaciones periódicas, monografías.

Fuentes secundarias: son el resultado del análisis de las fuentes primarias. Son la información resultante del proceso analítico-sintético de la información contenida en los documentos primarios. Contienen datos e información organizada según esquemas determinados. Cumplen dos funciones esenciales:

1. Como repertorios que facilitan la búsqueda y recuperación retrospectiva de la información.

2. Como difusión selectiva de la información.

Ejemplos de documentos secundarios:bibliografías, boletines de sumarios, resúmenes, boletinesde índices, catálogos de bibliotecas, bases de datos bibliográficos referenciales.

Fuentes terciarias: proceden del tratamiento de la información secundaria y a veces primaria. Sería el caso de las bibliografías de bibliografías.

Obras de referencia y consulta: el término referencia es un anglicismo y su equivalencia en castellano es consulta. Se entiende por referencia como "documento que proporciona acceso rápido a la información o fuentes de información sobre una materia determinada". Se consideran obras de referencia o consulta a aquellas que proporcionan información suficiente y autónoma para el usuario, tanto si es un texto, una lámina o una fórmula. La información que se obtiene de estas obras es inmediata y puntual, aunque no se pueden considerar originales porque resumen o recopilan los conocimientos expresados en otras publicaciones o formas de edición.

32



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3.3 INDICADOR

No están concebidas para la lectura continua, sino para la consulta puntual. Su elaboración es compleja dado el número de información que concentran en una sola obra. Son obras de referencia los diccionarios de todo tipo, enciclopedias, anuarios, guías, atlas.

2.4.3.4 La posibilidad de acceso a las fuentes propiamente dichas

Publicadas: están editadas y a disposición de los usuarios en los circuitos normales de comercialización, incluidas las suscripciones.

Inéditas: no están publicadas. Su acceso es difícil porque no aparecen en los canales de comercialización habituales. Tesis, actas de congresos.

Reservadas: tiene el acceso restringido al uso de determinados usuarios, condicionado al paso de un período de tiempo, como puede ocurrir con informes de la administración del Estado o documentos de carácter personal de determinados personajes.

2.4.3.5. Según el área del conocimiento o el campo científico que cubren pueden ser:

Multidisciplinares: agrupan varias disciplinas. Índices de citas, boletines de resúmenes, bibliografías.

2.5 Importancia de la información en una empresa

La información que fluye dentro de una empresa se ha convertido en la actualidad en uno de los activos más valorados, debido a que ésta le permite obtener una ventaja competitiva en el mercado en que se encuentran.

La información es uno de los activos más importantes de las entidades, y de modo especial en algunos sectores de actividad. La información en la actualidad se ha convertido en un punto central para la mayoría de las organizaciones, dejando atrás aquel tiempo en el cual permanecía empolvada en una esquina de la oficina. Actualmente, gracias al avance tecnológico, se puede lograr un mayor aprovechamiento de la información.

Es indudable que cada día las entidades dependen en mayor medida de la información y de la tecnología, y que los sistemas de información están más apoyados por la tecnología, frente a la realidad de hace pocas décadas.

El big-bang de la información, es el crecimiento acelerado de ella que se ha dado en los últimos años. Este crecimiento abrió las puertas de la investigación al comercio competitivo y generó el término de globalización. En la actualidad, la información puede ser accedida desde cualquier lugar del mundo y manipulada increíblemente.

33



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3.3 INDICADOR

La preocupación por proteger la información, caracterizada por ser compleja y esencial para el desarrollo económico y para el funcionamiento de la sociedad moderna, ha dado lugar a que la certificación de la seguridad de la tecnología de la información se convierta en una de las medidas más eficaces para sentar bases firmes sobre las que fundar la protección de la misma.

La seguridad de la información significa garantizar la disponibilidad de las infraestructuras, la integridad y la confidencialidad, su autenticidad y la identidad de las partes que la manejan.

Al hablar de seguridad hay tres aspectos principales, como distintas vertientes de la seguridad:

Confidencialidad: se cumple cuando sólo las personas autorizadas pueden conocer los datos o la información correspondiente.

Integridad: consiste en que sólo las personas autorizadas puedan variar (modificar o borrar) los datos. Además deben quedar pistas para control posterior y para auditoría.

Disponibilidad: se cumple si las personas autorizadas pueden acceder a tiempo a la información. El disponer de la información después del momento necesario puede equivaler a la no disponibilidad. Otro tema es disponer de la información a tiempo, pero que ésta no sea correcta, e incluso que no se sepa, lo que puede originar la toma de decisiones erróneas.

Otro caso grave es la no disponibilidad absoluta, por haberse producido algún desastre. En ese caso a medida que pasa el tiempo el impacto será mayor, hasta llegar a suponer la no continuidad de la entidad.

Al ser la información uno de los activos más importantes para las organizaciones, es de vital importancia que ésta se conserve a través del tiempo para sustentar las diferentes decisiones que se han tomado y como medida para prevenir o solucionar problemas que se pudieran enfrentar a lo largo de la existencia de una organización. La forma de preservar los datos en general y la información importante deben ser evaluadas cuidadosamente en una empresa.

2.6 Cómo se almacena la información

2.6.1Almacenamiento interno

En este caso el almacenamiento se realiza dentro de cada uno de los equipos, es decir, cada uno almacena su información. Y ésta, por lo regular, es guardada en medios magnéticos como discos rígidos que se encuentran ubicados físicamente dentro del chasís de la computadora de cada usuario.

34



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3.3 INDICADOR

2.6.2 Almacenamiento externo

Se llama así, porque los medios físicos donde la información se encuentra almacenada, se encuentran fuera del chasís de las máquinas, el más sobresaliente de estos tipos son los arreglos de discos externos, los cuales son accedidos por los servidores por medio de tarjetas especiales.

2.7. Métodos de Implementación de Cluster.

35



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3.3 INDICADOR

CAPITULO III

3 .Materiales y Métodos 3.1. Tipo de Investigación

El tipo de investigación es aplicada pues pone énfasis en la búsqueda de la

utilización y aplicación de los conocimientos que adquiridos.

3.2. Población y Muestra 3.2.1. Población

Conformada por todas las conexiones que hay a diario en los servidores web

posibles que pueden realizar la gran cantidad de usuarios en un sistema web.

Se consideró como Sistema Web de Convocatorias de las diferentes empresas del

Perú del área de convocatorias alojado en los servidores de empresas del estado o

privadas como por ejemplo INEI, INDECOPI, PODER JUDICIAL, JNE, BANCOS, ETC,

que cuenta con funcionalidades básicas:

• Obtener Información sobre un Tema Específico.

• Descargar esa Información.

• Inscripción de Datos para un bien satisfactorio ya sea un trabajo o un evento.

• Actualizar sus datos de preferencia laboral.

• En resumen la población es todo aquel que se conecta a los sitios web de

manera simultánea y esto genera conflicto de red, algunos no se pueden

conectar, etc.

36



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3.3 INDICADOR

3.2.2. Muestra Teniendo en cuentas las funciones que hace las mayoría de personas en los

sitios web nosotros diseñaremos un clúster para así poder que todas las conexiones

sean aceptadas y actualizadas utilizando un clúster en los servidores web para tener

acceso a todas las conexiones simultaneas a diario.

Ejemplo

Si en Un Sitio web solo acepta 1000 conexiones simultáneas al servidor web con ayuda

del clúster podremos mejorar a unas 3500 conexiones a mas conexiones a diario.

3.3. Indicador

Los indicadores se utilizan para realizar mediciones que permiten determinar la

validez de una hipótesis. El indicador que se utilizó para esta investigación, en la

medición y comparación de la variable dependiente fue:

1. Porcentaje de error en transacciones sintéticas.

El tiempo de respuesta es el tiempo que el servidor web se demora en retornar la

respuesta a una petición de página. Se establece un valor umbral aceptable para

el tiempo de respuesta que esta expresado en segundos, el valor de este umbral

depende del tipo de transacción sintética. Una transacción como ya se ha

mencionado esta formado por un conjunto de operaciones que se traducen en un

conjunto de peticiones web. El umbral permite distinguir entre peticiones

degradadas o realizadas satisfactoriamente ante una carga importante de

usuarios. El indicador quedó establecido por el porcentaje de peticiones

degradadas en una transacción sintética.

3.4. Técnicas y Procedimientos de Recolección de Datos

Las técnicas que se utilizaran para la recolección de los datos son:

Recopilación documental: Esta técnica se apoya en la recopilación de

antecedentes a través de documentos, papers, libros y gráficos [9]. Para este

proyecto las fuentes son de tipo bibliográficas, que son la base tanto de

fundamentos como de complemento para la investigación.

Recopilación a través de la observación: Consiste en el estudio de

características y comportamiento de un fenómeno, dentro del medio en donde se

desenvuelve. Esta técnica se utilizó para estudiar el estado actual de las diferentes

empresas del Perú y de los servidores web en cuanto a configuración y red, que

permitió obtener un informe de estudio de campo que sirvió para un análisis

posterior.

37



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


3.3 INDICADOR

Recopilación de datos experimentales: Se basa en la experimentación que

consiste en la observación dedicada y constante que se hace a un fenómeno, al

que se le van modificando sistemáticamente sus variables conforme a un plan

determinado [10]. Esta técnica permitió recolectar datos de la experimentación

sobre el diseño de la solución propuesta y de su implementación, que luego sirvió

para contrastar y analizar resultados con respecto a la hipótesis del proyecto.

3.5. Métodos de Análisis de Datos

Las técnicas que se utilizaron para el análisis de los datos son:

Análisis documental: La base del planteamiento de la solución viene del análisis

documental sobre la información de documentos, papers, libros, etc. que se

obtengan sobre el tema [8]. Luego de recolectar los datos necesarios se procedió

a realizar una lectura comprensiva y resumen de lo importante, contrastándolo

con la realidad de las empresas, obteniendo el diseño más apropiado.

Técnicas de estadística descriptiva: Para el análisis de los datos cuantitativos

recogidos del experimento se utilizó estadísticos simples como el promedio y la

media de cada grupo de medidas tomadas. Para realizar la comparación entre 2

grupos de datos al alterar la variable independiente, se utilizaron tablas y gráficos.

La herramienta a utilizar será Microsoft Excel que permite tabular los datos en

tablas y realizar sus gráficos respectivos.

38



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

3.5 MÉTODOS, PROCEDIMIENTOS Y MATERIALES


3.6. Métodos y Procedimientos 3.6.1. Método para la gestión del proyecto

Para esta Tesis se ha utilizado el método del Project Management Institute (PMI)

explicado en su guía PMBOK [1], simplificando sus etapas debido a la

naturaleza del proyecto cuya parte principal se centrará en la ejecución de lo

planteado en este documento.

PMBOK es un estándar en la Administración de proyectos. La misma comprende

dos grandes secciones, la primera sobre los procesos y contextos de un

proyecto; la segunda sobre las áreas de conocimiento específico para la

gestión de un proyecto.

Los procesos que se ejecutaran se dividen en las siguientes partes [1]:

Entradas: La bibliografía sobre el tema de tesis e ideas que el asesor e

investigadores planteen.

Herramientas y Técnicas: Herramientas de software que se utilizaran para

implementar la solución planteada.

Salidas: Corresponde a las salidas de cada fase del proyecto. La salida final

será el informe final de la tesis donde se detalla la implementación de la

solución.

Las fases que se utilizaran para el proyecto son [1]:

1. Iniciación: Comprende desde la búsqueda bibliográfica hasta la elección del

tema y aprobación por parte del asesor.

2. Metodología, Métodos y Procedimientos: Comprende la elaboración de

plan del proyecto de tesis y su aprobación por el jurado respectivo.

La Metodología Aplicada es PMBOK.

3. Diseño: Se Diseñara el Clúster dando a solución a la variedad de empresas

con los problemas existentes de ahora en día.

4. Implementación: Comprende la implementación del clúster y sus

componentes para el buen funcionamiento del proyecto.

5. Cierre: Culminara con la presentación del informe final que contendrá los

resultados obtenidos.

39



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



Requerimientos Funcionales y no funcionales

� La infraestructura del clúster debe garantizar una disponibilidad del 99% en los

servidores web de las empresas.

� El clúster debe de ofrecer un servicio igual al que ofrece el sistema actuar, es

decir debe ser capaz de procesar los trabajos de los usuarios y debe disponer de

un espacio de disco para albergar sus datos y programas.

� El middleware elegido debe ser personalizable a nivel de gestión de colas,

proyectos, usuarios.

� El sistema clúster debe reducir las horas fuera de línea del servicio web de las

empresas

� El clúster debe ser monitoreable, es decir, el administrador debe tener las

herramientas necesarios para controlar el estado de sus componentes y

percatase de cualquier fallo.

� Además debe de contar con un software que permita instalar y modificar

fácilmente el sistema en los nodos que lo componen, de forma que la instalación

y posterior mantenimiento de los nodos sea fácil.

Requerimientos No Funcionales

� La infraestructura hardware del nuevo cluster debe hacer uso del hardware

existente (nodos, red y discos).

� Debe soportar una carga de trabajo superior a la actual, dada la tendencia

creciente en cuanto a número de usuarios y, por tanto, de volumen de trabajo.

� Debe ser tolerable a fallos. El fallo de una parte del sistema no puede

comprometer el funcionamiento del conjunto del cluster.

� Debe ser escalable, tanto a nivel de software como a nivel de infraestructura

hardware.

40



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



A. Características de la solución

� Sencillo:

La tecnología que hace funcionar a un clúster se basa en la unión de elementos

sencillos (que pueden ser incluso computadores normales). Y esta sencillez es más

beneficiosa cuando hablamos de disponibilidad de piezas de recambio o de un

downtime reducido (no hay tiempo para un técnico enviado por la marca del equipo).

� Disponibilidad:

La interconexión de dos o más computadoras trabajando conjuntamente en la

solución de un problema, permite incrementar la disponibilidad de servicio puesto

que se divide aproximadamente los números de puntos críticos de servicio entre el

número de nodos del clúster.

� Escalable:

Si el SO del clúster lo permite, solo hace falta conectar más equipos a la red del

clúster, configurando correctamente y ya tenemos un clúster ampliado y mejorado.

Incluso mejorando alguno de los elementos que forman parte de cada nodo

(memoria RAM o disco por ejemplo), se obtiene una mejora del rendimiento o la

disponibilidad.

� Rendimiento:

El incremento de recursos asignados con el fin de resolver la misma carga de trabajo

permite aumentar el rendimiento del sistema como conjunto.

� Balance de Carga:

La tecnología de clúster de servidores por balanceo de carga mejora la respuesta a

las peticiones conmutando estas entre los diversos nodos del clúster.

3.6.2. Método para la implementación de la solución informática

ASPECTOS METODOLOGICOS

Internet es la fuente más grande e importante para la distribución del software libre, es por eso que este proyecto se basa en gran parte en la información publicada en libros electrónicos, foros de discusión, blogs, documentos, revistas digitales y páginas web encontradas en Internet.

41



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



Para poder implementar la estrategia planteada en este proyecto se llevarán a cabo las siguientes actividades:

Identificación y Localización del Software

Evaluación y Selección del Software

Obtención del Software y su Documentación.

Instalación y Configuración del Software

Pruebas

IDENTIFICACIÓN Y LOCALIZACIÓN DEL SOFTWARE La Identificación del software y su posterior localización son dos de los puntos más importantes para este tipo de proyectos ya que de manera general existe una cantidad importante de herramientas y aplicaciones de distribución libre prácticamente desconocidas. Estas actividades se realizan principalmente con la ayuda de referencias obtenidas en motores de búsqueda, páginas Web, foros de discusión, revistas, etc. EVALUACIÓN Y SELECCIÓN DEL SOFTWARE Por evaluación se entiende a la obtención de información acerca del software, esta actividad permite tener referencias de los programas posteriormente seleccionados. En estas actividades se consideran varios aspectos tales como: usabilidad, utilidad, características, soporte, costo de implementación, referencias comparativas realizadas por otras personas, etc. OBTENCIÓN DEL SOFTWARE Y SU DOCUMENTACIÓN La forma más sencilla de obtener software libre y su respectiva documentación (si existe) es a través del Internet aunque también es posible hacerlo a través de medios físicos como una memoria flash, un CD o un DVD ya sean adquiridos o copiados (¡el software libre lo permite!). Cabe mencionar que si bien la mayoría de estos programas incluyen breves manuales de instalación, en la mayoría de casos es necesaria la ayuda de documentación adicional INSTALACIÓN Y CONFIGURACIÓN DEL SOFTWARE Sin lugar a dudas estos son los dos puntos más importantes dentro de la elaboración de este tipo de proyectos por ello es recomendable leer y entender la documentación incluida con el software para que la instalación y la configuración seleccionada sea la más adecuada. También es importante cumplir los requerimientos individuales de cada programa para evitar problemas de incompatibilidad.

42



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



REQUERIMIENTOS BÁSICOS 3 Computadores con tarjetas de red Ethernet y disco duro. (Pueden ser máquinas virtuales).

1 Red Ethernet.

Acceso a Internet.

RENUNCIA DE RESPONSABILIDAD TODA LA INFORMACIÓN CONTENIDA EN ESTA TESIS ES PROVISTA POR PARTE DEL AUTOR COMO ESTÁ, SIN NINGUNA GARANTÍA EXPRESA O IMPLÍCITA. EN NINGÚN CASO EL AUTOR DE ESTA TESIS SERÁ RESPONSABLE POR DAÑOS DIRECTOS, INDIRECTOS O CUALESQUIERA QUE ESTOS FUEREN Y QUE RESULTEN, SIN RESTRICCIONES, EN PÉRDIDA DE USO, DATOS, VENTAS, GANANCIAS, INTERRUPCIÓN DEL NEGOCIO, PÉRDIDA DE PROGRAMAS U OTROS DATOS SOBRE CUALQUIER SISTEMA DE MANEJO DE LA INFORMACIÓN O BAJO OTRAS CIRCUNSTANCIAS, SEAN EN UN CONTRATO, NEGLIGENCIA U OTRA ACCIÓN INCORRECTA, YA SEA A CAUSA DEL ACCESO A, AL USO O EN CONECCIÓN CON EL USO DE, INHABILIDAD DE USAR, EXACTITUD O FACTIBILIDAD DE USO DE ESTA INFORMACIÓN O DE LOS PROGRAMAS Y CUALQUIER REFERENCIA BIBLIOGRÁFICA, INCLUYENDO, LA PÉRDIDA DE EMPLEO Ó TRABAJO, INCLUSO SI EL AUTOR ES NOTIFICADO EXPRESAMENTE DE LA POSIBILIDAD DE TALES DAÑOS.

43



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



CAPITULO IV 3.7 Diseño e Implementación del clúster de alta disponibilidad

Para mejorar los Servidores Web.

3.7.1 Herramientas de configuración y Administración del clúster.

44



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



3.8. Materiales Los materiales que se utilizaron son los siguientes: Páginas Web de Prueba: Para medir la disponibilidad de los servidores web de las diferentes empresas en el Peru. Linux CentOS como Sistema Operativo. Pacemaker como Administrador de Recursos. Corosync como Administrador de Mensajería y Membrecía. DRBD como Administrador de Sincronización de datos. BIND y vsFTP como Recursos o Servicios.

45



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



3.8.1 Equipos que utilizaremos para la implementación del

Clúster.

Switch Cisco Catalyst 3750 Ethernet 10/100/1000

Switch Cisco 24 Puertos

Switch Cisco 48 Puertos

Switch Cisco 3Com 10/100/1000

Puertos 24 y 48

Tipo de dispositivo Conmutador - 24 o 48 puertos - Gestionado

Tipo incluido Sobre Mesa - 1U

Puertos 24 y 48 x 10/100/1000 + 4 x SFP

Rendimiento Capacidad de conmutación: 32 Gbps | rendimiento de

reenvío: 38,7 Mpps

Tipo de dispositivo Conmutador - 24 o 48 puertos - L3 - Gestionado -

apilable

Tipo incluido Montaje en bastidor - 1U

Puertos 24 x 10/100/1000 + 4 x SFP

Rendimiento Capacidad de conmutación: 32 Gbps | rendimiento de

reenvío: 38,7 Mpps

46



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



WorkStation Hp 6000 Pro

Hp 600 pro

Tarjeta de Red:

Velocidad 10/100/1000 Mbps detección Automática

Conector Rj 45

Soporta IEEE802.1q VLAN / IEEE802.1p / IEEE802.3x

Soporta Funcion de Inicio remoto

Procesador core 2 quad

Memoria RAM 4 Gb

Disco Duro 250 Gb

47



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


IMPLEMENTACION, DISEÑO, CONCLUSIONES Y REFERENCIAS 55

3.8.2 Elementos que forman parte de un clúster y su Arquitectura. Los elementos con los que cuenta un clúster son. • Un nodo activo, donde corren los servicios • Un nodo pasivo que funciona como respaldo (Backup). • Servidores reales. • Software de administración. • Protocolos de comunicación y servicios. • Conexiones de red. • Ambientes de programación paralela. Middleware. Es un programa intermediario entre dos programas independientes. Se encarga de Monitorear administrar, distribuir comportamiento general del clúster.

Figura 1: Arquitectura del Clúster



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS


INSTALACION, HERRAMIENTAS Y MATERIALES PARA LA IMPLEMENTACION Y DISEÑO DEL CLUSTER

56

3.8.3. Diseño de red lógico habitual de algunas empresas en el Perú. Problema en general. Figura 2: Problema de las Empresas



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



57

De manera general esta representación gráfica puede resumirse de la siguiente manera: Existe un servidor principal que aloja uno o más servicios informáticos, el cual no tiene ningún tipo de redundancia, por lo tanto cada vez que éste presenta un mal funcionamiento o no está trabajando afecta significativamente a las actividades que dependen de ese servidor. Una vez entendido el problema también es necesario entender la solución que se va implementar. De manera general la solución del problema puede resumirse de la siguiente manera: Implementar un Clúster de Alta Disponibilidad de 2 nodos con el objetivo de proveer redundancia al servidor principal, de tal manera que un servidor secundario sea capaz de reemplazar al servidor principal cuando este presenta problemas. Con esta información es posible realizar una representación gráfica del diseño del clúster que será implementado, como se muestra en la Figura 3.

3.8.4. Solución al Problema de la red lógica de las Empresas en General del Perú.

Figura 3. Representación gráfica de un escenario solución.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



58

Dos servidores, uno principal y otro secundario con todos los servicios.

Y Agregando más Nodos para cumplir con todas las peticiones de los clientes ya mencionado si el servidor está dispuesto para 1500 Peticiones lo mejoraremos con 5000 Peticiones de acuerdo la cantidad de nodos.

3.9. Instalación del sistema operativo. La segunda actividad consiste en instalar una distribución GNU/Linux. Dentro del clúster, el sistema operativo es el encargado de proveer la plataforma sobre la que se ejecutan las aplicaciones, los servicios, los administradores de mensajería, membrecía y sincronización; por esta razón es recomendable instalar una distribución Linux que sea estable, segura, robusta y ampliamente configurable, es decir que esté orientada a profesionales o ambientes empresariales. Algunas distribuciones que podrían cumplir estas características son: Red Hat Enterprise Linux, SUSE Linux Enterprise Server, CentOS, Oracle Linux ó Ubuntu Server. 3.9.1 Actualizaciones del sistema operativo Ignorar las notificaciones de actualización y mantener los sistemas Linux desactualizados es un error común entre los administradores de sistemas, ya que argumentan que las distribuciones Linux no las necesitan porque supuestamente no son vulnerables a virus y lo único que hacen es ralentizar el sistema. Lo que estos administradores no toman en cuenta es que las actualizaciones del sistema no solo corrigen problemas de seguridad o de programación que pueden ser aprovechados por software malintencionado o virus, sino que también dan soporte a nuevas tecnologías cuyo objetivo principal es mantener el sistema más estable. Una vez mencionados algunos aspectos importantes de las actualizaciones en un sistema Linux también es importante mencionar algunas consideraciones y recomendaciones, a tomar en cuenta, con respecto a las actualizaciones: las siguientes recomendaciones:

Instalar las actualizaciones como parte del proceso de instalación del sistema operativo.

Planificar la actualización del sistema de manera periódica.

Revisar y probar las actualizaciones en ambientes de prueba antes de ser aplicadas en ambientes de producción.

Evitar las actualizaciones desatendidas pues esto puede ocasionar desde cortes de

servicio inesperados hasta el reinicio total del sistema. Desactivar los procesos automáticos de actualización pero nunca omitir las notificaciones de actualizaciones disponibles.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



59

3.9.2. Red LAN de comunicación tcp/ip. Un clúster simplemente no puede existir si sus nodos no pueden comunicarse entre sí. En Linux el soporte de los protocolos TCP/IP está prácticamente asegurado dado que la mayoría de las redes TCP/IP usan Ethernet y Linux tiene soporte para una larga lista de adaptadores de red de distintos fabricantes.

3.9.3 Instalación del sistema de archivos para clústeres ó del sistema de almacenamiento distribuido. La tercera actividad de la estrategia consiste en instalar un sistema de archivos para clústeres o un sistema de almacenamiento distribuido. La instalación de un sistema de archivos para clústeres o de un sistema de almacenamiento distribuido depende directamente del diseño de clúster. Por ejemplo, el sistema de archivos para clústeres es un componente indispensable en la estrategia de implementación de un clúster si se usa almacenamiento compartido; no obstante, es un componente opcional si cada nodo en el clúster posee su propio medio de almacenamiento.

3.9.4. Sistema de archivos para clústeres. De manera general, la configuración de un sistema de almacenamiento que permita a múltiples computadores acceder a un mismo dispositivo de bloques lógico es relativamente fácil, sin embargo, si el sistema no es configurado correctamente existe un riesgo muy grande de destruir la información almacenada, especialmente en el caso que dos o más computadores intenten usar el dispositivo al mismo tiempo; es por esta razón que un sistema de archivos para clústeres en medios de almacenamiento compartidos es prácticamente obligatorio. En la figura 4 se muestra un ejemplo de una configuración con disco compartido. Algunos de los sistemas de archivos para clústeres más utilizados son: GFPS de IBM, CFS de HP, OCFS2 de Oracle o GFS de Red Hat.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



60

3.10. Sistema de almacenamiento distribuido. También es posible configurar el clúster de tal manera que cada nodo posea su propio dispositivo de almacenamiento. Este tipo de configuración provee redundancia de datos al mantener múltiples copias en diferentes nodos; pero a su vez, requiere obligatoriamente de un sistema de almacenamiento distribuido que actúe como administrador de sincronización para que notifique a los otros nodos cuando hay cambios en el servidor principal. En la figura 5 se muestra un ejemplo de una configuración que usa un sistema de archivos distribuido. Algunos de los sistemas de almacenamiento distribuido más utilizados son: NBD, DRBD, GlusterFS, ExaFS ó MogileFS.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



61

3.10.1. Instalación del administrador de membrecía y mensajería. La cuarta actividad consiste en instalar un administrador de membresía y un administrador de mensajería. El administrador DiscoLocalServidor PrincipalServidor SecundarioSistema de Archivos DistribuidoDiscoLocalSincronización de membresía es el encargado de coordinar toda la información relacionada con los nodos del clúster, de tal manera que sea posible determinar los nodos activos y los que están fuera de servicio. Para poder alcanzar esta coordinación el administrador de membresía monitorea los mensajes enviados por los nodos y actualiza constantemente el estado de los servicios y las aplicaciones de cada nodo. Cuando la membresía del clúster cambia, el administrador de membresía notifica a todos los otros componentes de la infraestructura para que tomar la acción correspondiente. En la figura 6 se muestra los componentes principales del administrador de Membresía y mensajería. El administrador de mensajería es el encargado de proveer la capa de comunicación entre los nodos del clúster. Entre otras cosas este administrador provee el soporte de encriptación3 y autenticación para una comunicación segura entre los miembros del clúster; por otro lado, el administrador de mensajería está optimizado para minimizar la cantidad de información necesaria para mantener actualizado el estado del sistema facilitando así el trabajo del administrador de membrecía, ya que en lugar de enviar llamadas a funciones se envían mensajes que ayudan en la toma de decisiones. 3.10.2 Instalación del administrador de recursos. La quinta actividad consiste en instalar un administrador de recursos. El Administrador de recursos es el encargado de monitorear los recursos activos en el clúster de tal manera que estos puedan ser recuperados o transferidos automáticamente de un nodo a otro si se presenta un fallo. Por otro lado, este administrador se encarga de replicar automáticamente la configuración de ordenamiento y colocación de los nodos en el clúster.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



62

4. Implementación del clúster En este prototipo de ejemplo se va a implementar un clúster de alta disponibilidad de 3 nodos, sin embargo, para demostrar que la estrategia planteada en el capítulo III puede ser aplicada para un clúster de alta disponibilidad de N nodos el diseño inicial del un clúster tendrá únicamente 2 nodos con los servicios de WEB - PHP para luego agregar un tercer nodo al clúster con el servicio de HTTP. 4.1. Diseño del clúster con 2 nodos La figura 7 muestra el diseño inicial del clúster, con los nodos A y B.

Cualquier nodo puede proveer los recursos de DNS y FTP. Los recursos de DNS y FTP siempre deben estar en el mismo nodo.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



63

4.2. Requerimientos de hardware Tomando como punto de partida el escenario de ejemplo, el hardware mínimo necesario para implementar un clúster de nodos dos nodos es:

2 Computadores. Una conexión de red para comunicación TCP/IP. 2 unidades de almacenamiento para cada computador. Acceso a Internet.

4.3. Requerimientos de software La figura 8 muestra el software que vamos a instalar: Figura 8. – Componentes de Software. El software necesario para implementar el clúster es:

Linux CentOS como Sistema Operativo.

Pacemaker como Administrador de Recursos.

Corosync como Administrador de Mensajería y Membrecía.

DRBD como Administrador de Sincronización de datos.

BIND y vsFTP como Recursos o Servicios.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



64

4.4. Instalación y configuración del sistema operativo centos El Sistema Operativo seleccionado para esta implementación es Linux CentOS debido a que es un SO para servidores y prácticamente un clon de la distribución Red Hat Linux Enterprise ó RHLE, compilado a partir del código fuente liberado públicamente por Red Hat el cual no necesita de suscripción alguna para ser descargado desde el Internet. Aunque CentOS no es mantenido ni asistido de ninguna manera por Red Hat, su similitud con RHLE hace que muchas empresas alrededor del mundo opten por esta distribución, por otro lado CentOS posee una comunidad muy grande de desarrolladores voluntarios que colaboran con el soporte y actualización del software a través de foros, canales de chat IRC, listas de correo, FAQ y manuales en línea. Algunas de las características que hacen de CentOS un SO muy popular son:

Fácil mantenimiento. Desarrollo activo. Idóneo para entornos de producción a largo plazo. Infraestructura comunitaria. Modelo de gestión abierto. Soporte Comercial – ofrecido por un Socio Proveedor.

El DVD de Instalación de Linux CentOS puede ser descargado libremente desde alguno de los servidores listados en la siguiente página web: http://www.centos.org/modules/tinycontent/index.php?id=30 Todos los pasos necesarios para instalar y configurar CentOS se encuentran detallados en el Anexo 1.

4.5. Preparativos Durante el proceso de instalación es necesario definir, entre otras cosas, la estructura de particiones del disco y los parámetros de configuración red.

4.5.1.1. Estructura de las particiones. Para este prototipo vamos a dividir el disco en 4 particiones primarias.

La primera partición será usada para el directorio /boot que contiene el núcleo del sistema.

La segunda partición será usada para la asignación de la memoria virtual o swap. La tercera partición será usada para el directorio raíz que contendrá el directorio del

administrador o /root , el directorio /home de los usuarios, el directorio /etc , entre otros. La cuarta y última partición será usada para el directorio /var que contiene entre otras

cosas los archivos variables de registro o log, los archivos temporales de correo, etc.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



65

4.5.1.2. Configuración de red. Para que todos los nodos dentro del clúster puedan comunicarse entre sí es necesario que todos pertenezcan a la misma red TCP/IP.

4.6. Configuraciones adicionales 4.6.1.1. Instalación de las actualizaciones del sistema operativo La instalación de todas las actualizaciones del sistema disponibles se las puede realizar usando yum.

4.6.1.2. Configuración del archivo hosts Un requerimiento importante para que el clúster funcione correctamente es que todos los nodos deben ser capaces de comunicarse entre sí por el nombre de host, para ello es necesario editar el archivo hosts y añadir la siguiente información. 4.6.1.3. Configuración del repositorio de red hat La manera más sencilla de instalar el software para el clúster es a través de archivos ejecutables rpm, para ello es necesario agregar el repositorio público y oficial de Red Hat. 4.7. Instalación del sistema de almacenamiento distribuido – drbd El sistema de almacenamiento distribuido seleccionado para este prototipo es DRBD (Distributed Replicated Block Device) porque ha sido diseñado para construir clústeres de alta disponibilidad y permite réplicas de múltiples dispositivos a través de una conexión de red. Algunas de las características principales de DRBD son:

Sincronización en tiempo real. Soporta discos de hasta 1 Petabyte (1015 bytes). Detección automática de bloques desactualizados. Re sincronización eficiente, sólo los

bloques que fueron modificados son re sincronizados. Soporta TCP/IP sobre Ethernet. Permite los modos de operación síncrono y asíncrono. DRBD soporta prácticamente cualquier dispositivo soportado por el kernel de Linux. Un disco completo. Una partición. Un administrador de volumen lógico. Un sistema de administración de volumen corporativo.

Todos los pasos necesarios para instalar y configurar DRBD se encuentran detallados en el Anexo 2.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



66

4.7.1. Visión general de drbd. DRBD es un software de replicación de datos que trabaja con la filosofía de “no compartir nada”. El objetivo de DRBD consiste en replicar los datos desde el servidor principal al servidor secundario de tal manera que los 2 servidores tengan la misma información. Esta replica se realiza continuamente y puede ser vista como un RAID1 pero a través de la infraestructura de red. Por defecto, DBRD usa el puerto TCP 7788 para la comunicación con otros nodos por lo tanto es necesario asegurarse que este puerto no esté bloqueado por ningún firewall. Por otro lado, DRBD reserva y oculta 128MB para los metadatos, es decir que si un dispositivo tiene 1GB de almacenamiento sólo estarán disponibles 896MB para los datos de las aplicaciones o recursos. 4.7.1.1. Componentes importantes de drbd. La figura 9 muestra los componentes más importantes de la definición de un recurso DRBD.

4.7.1.2. Recurso. Es el término empleado para referirse a un conjunto determinado de datos replicados.

4.7.1.3. Dispositivo drbd. Es un dispositivo virtual de bloques administrado por DRBD. A cada dispositivo DRBD usualmente llamado drbdX, donde X representa un número, le corresponde un volumen en un recurso. DRBD también permite nombres personalizados pero estos deben iniciar con drbd.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



67

4.7.1.4. Volumen. Es lo que contiene los datos replicados y los metadatos de DRBD.

4.7.1.5. Conexión. Es un enlace de comunicación entre 2 equipos que comparten un conjunto de datos replicados.

4.7.2. Roles. A diferencia del concepto de activo y pasivo usado para las aplicaciones, el de concepto de primario y secundario se usa para almacenamiento. Cada recurso puede tener un rol primario o secundario, cuando el estado del rol cambia de secundario a primario se conoce como promoción y cuando cambia de primario a secundario se conoce como degradación. Un dispositivo BDRB en rol primario puede realizar tareas de lectura y escritura sin restricciones, sin embargo cuando el dispositivo tiene un rol secundario no puede ser usado en las tareas de lectura y escritura por las aplicaciones pues está restringido a recibir únicamente las actualizaciones desde el dispositivo en rol primario.

4.7.3. Convenciones generales de drbd.

El nombre de un recurso no puede contener espacios en blanco ni caracteres especiales.

Los volúmenes se enumeran desde 0 hasta 65535. Los nombres de los dispositivos DRBD deben iniciar con la palabra drbd.

Los pasos para instalar y configurar DRBD son:

1. Instalar DBRD.

2. Editar el archivo /etc/drdb.conf.

3. Editar el archivo de configuración global.

4.7.4. Instalación de drbd Para instalar el sistema de almacenamiento distribuido desde el repositorio de Red Hat vamos a usar yum.

4.7.5. Configuración inicial de drbd La configuración inicial de drbd consiste en definir la ubicación de los archivos de configuración global y la de los recursos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



68

4.8. Instalación del administrador de membrecía y mensajería – corosync. El administrador de membrecía y mensajería seleccionada es Corosync, dado que es una versión derivada de OpenAIS y está respaldado tanto por Red Hat como por Novell/Suse. Por otro lado contiene todos protocolos de red necesarios para la intercomunicación de los procesos y para la implementación general del clúster HA sin que tenga dependencia con alguna distribución específica de Linux.

Algunas de las características principales de Corosync son:

La tecnología usada por Corosync se basa en más de 20 años de investigación en computación distribuida.

Soporte para encriptación y autenticación para una comunicación segura. Soportado por la mayoría de distribuciones Linux. Diseño compacto con menos de 60 mil líneas de código. Diseñado optimizado para minimizar las copias a memoria y los intercambios de

contexto. Alto rendimiento en redes Ethernet y 10G InfiniBand. Disponible para Linux, Solaris, BSD, Darwin.

Corosync aborda la alta disponibilidad asegurando que cada servidor redundante en el sistema mantiene una copia redundante de información que se usa para tomar decisiones acerca de las aplicaciones

4.8.1. Componentes principales de corosync. La figura 10 muestra los componentes principales de Corosync.

4.8.1.1. Grupo de proceso cerrado – Cpg.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



69

Provee membrecía dentro de las aplicaciones. Cuando una aplicación se une a un proceso de grupo, todas las aplicaciones envían un mensaje indicando un cambio de membrecía que incluye el ID del proceso de la aplicación y el ID del nodo. Cuando una aplicación es parte de un grupo, esta puede enviar y recibir mensajes a todos los miembros del grupo.

4.8.1.2. Quorum. Provee información útil para determinar si el clúster tiene quórum en el caso que la mayoría de nodos del clúster está presente.

4.8.1.3. Sincronía virtual extendida – devs. Es la interfaz extendida virtual de mensajería para sincronización entre nodos.

4.8.1.4. Confdb. Provee acceso a la configuración y estadísticas.

4.8.1.5. Cfg. Es la API de configuración que provee los mecanismos para el control del estado de operación de Corosync.

4.9. Instalación del administrador de recursos –Pacemaker. El administrador de recursos seleccionado es Pacemaker, pues no es dependiente de ninguna distribución en especial y se integra perfectamente con Corosync. Algunas de las características principales de Pacemaker son:

Detección y recuperación nodos y errores a nivel de servicio. Independiente del tipo de almacenamiento agnóstico, es decir que no requiere

almacenamiento compartido. Independiente de los Recursos, es decir que cualquier cosa que pueda ser puesta en

un archivo de secuencia de comandos puede ser parte del clúster. Soporta Clústeres grandes o pequeños. Prácticamente soporta cualquier configuración de redundancia. La configuración puede ser actualizada en cualquier nodo y es automáticamente

replicada a todos los nodos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



70

4.9.1. COMPONENTES INTERNOS DE PACEMAKER La figura 11 muestra los componentes internos de Pacemaker.

4.9.1.1. Base de información del clúster. Contiene todas las definiciones de las opciones de configuración del clúster, los nodos, los recursos y las relaciones entre nodos con sus respectivos estados.

4.9.1.2. Motor de políticas. Es el encargado de calcular el próximo estado del clúster basado en el estado y laconfiguración actual.

4.9.1.3. Stonith Es un mecanismo de aislamiento para los nodos con problemas con la finalidad de prevenir corrupción de datos. Estos componentes se integran de la siguiente manera: La Base de Información de Clúster (CIB) utiliza lenguaje XML para representar la configuración y el estado actual de todos los recursos del clúster. El contenido del CIB se mantiene automáticamente sincronizado en todo el clúster y es usado por el Motor de Políticas (PE) para calcular el estado ideal del clúster y cómo debe ser alcanzado.

4.9.2. Agentes



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



71

Los agentes son las interfaces encargadas de abstraer los recursos dentro del clúster, es decir cada agente se encarga de reaccionar adecuadamente cuando hay que iniciar o detener un recurso a través de archivos de secuencia de comandos. Pacemaker soporta los siguientes tipos de agentes:

Agentes heredados de Hearbeat 1 Archivos de secuencia de comandos basados en estándares de Linux. (LSB) Agentes basados en Framework de Clúster Abierto(OCF)

4.9.3. Tipo de recursos

4.9.3.1. Primitivo Es el tipo de recurso más básico dentro del clúster, pues no depende de otros recursos para ser iniciado.

4.9.3.2. Grupo Es un conjunto de recursos que dependen de otros recursos y necesitan iniciarse en un orden específico dentro de un mismo nodo.

4.9.3.3. Clon Es aquel tipo de recurso que puede estar activo en múltiples nodos al mismo tiempo.

4.9.3.4. Máster Es un tipo especial de clon que permite dos modos de operación: máster y esclavo.

4.9.4. Restricciones de los recursos Existen tres diferentes tipos de restricciones disponibles en Pacemaker:

4.9.4.1. Ubicación Las restricciones de ubicación definen los nodos en que un recurso puede ser ejecutado, no puede ser ejecutado o es preferible que sea ejecutado.

4.9.4.2. Co-ubicación Las restricciones de co-ubicación definen los recursos que se pueden ejecutar y que no se pueden ejecutar en un mismo nodo.

4.9.4.3. Orden Las restricciones de orden definen la secuencia de ejecución de las acciones sobre los recursos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



72

4.9.5. Puntuaciones e infinito Para poder definir las restricciones correctamente es necesario definir las puntuaciones, pues cada restricción debe ir acompañada de una puntuación. En términos generales las puntuaciones son muy importantes porque ayudan a decidir cuando un recurso debe ser detenido o migrado. Hay que tomar en cuenta que todas las puntuaciones son calculadas por recurso y las restricciones con puntuación más alta se aplican primero, cuando un recurso necesita ser migrado el clúster escoge el nodo con la puntuación más alta como nuevo anfitrión, sin embargo, ningún nodo con una puntuación negativa puede ser anfitrión de ese recurso. El valor de infinito se define como 1,000.000; cualquier operación de suma o resta del infinito debe seguir las siguientes reglas:

X + INFINITO = INFINITO X - INFINITO = -INFINITO INFINITO - INFINITO = -INFINITO

4.9.6. Nodos de recuperación Un recurso migrado puede ser restaurado a su nodo original cuando ha superado el problema que originó la migración. Para prevenir este comportamiento o definir un nuevo nodo anfitrión es necesario cambiar el valor de la adherencia5 del recurso. Hay que tomar en cuenta las siguientes implicaciones al momento de cambiar el valor de adherencia:

IGUAL A 0 : El recurso migrará al nodo original automáticamente a menos que se haya movido a un nodo distinto al original.

MAYOR A 0 : El recurso permanecerá en el nodo actual pero puede ser migrado si otro nodo más apropiado está disponible.

MENOR A 0: El recurso será migrado de su ubicación actual cuando otro nodo más apropiado esté disponible.

INFINITO: El recurso siempre permanecerá en la ubicación actual mientras el nodo esté disponible. Esta opción prácticamente deshabilita la recuperación automática.

-INFINITO: El recurso siempre se moverá de la ubicación actual.

4.10. Instalación de los recursos

4.10.1. Instalación del servidor para resolución de nombres de dominio El servidor seleccionado para este proyecto es BIND, que será el encargado de traducir los nombres de dominio a direcciones IP dentro del Clúster. Todos los pasos necesarios para instalar y configurar el servidor DNS se encuentran detallados en el Anexo 6.

4.10.1.1. Servidor maestro Atiende las peticiones de resolución de nombres directamente dentro de la red local y puede reenviar las peticiones a servidores externos en caso de ser necesario.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



73

4.10.1.2. Zona maestra Traduce los nombres de dominio a direcciones IP.

4.10.1.3. Zona inversa Traduce las direcciones IP a nombres de dominio.

4.11. Agregar un tercer nodo al clúster actual Para agregar el tercer nodo a la arquitectura actual del clúster es necesario repetir las mismas actividades realizadas para los dos primeros nodos, empezando por el diseño del nuevo clúster hasta llegar a las pruebas funcionales.

4.11.1. Diseño del clúster con 3 nodos El diseño del clúster con 3 nodos debe ajustarse a las siguientes características.

. El nodo A , B Y C puede ofrecer los servicios de HTTP, WEB ,PHP Y DATOS.

.

Tomando en cuenta las nuevas características del clúster, el diseño final del clúster con tres nodos se puede ver en la figura 12.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



74

4.11.2. Configuración del clúster con 3 nodos Para que la configuración de clúster se adapte al nuevo diseño es necesario realizar las actividades que se muestran en la figura 13.

El detalle de los cambios de configuración se encuentra detallado en el Anexo 9. Para terminar la configuración del tercer nodo, es necesario agregar un recurso adicional al clúster de tal manera que se ajuste al diseño definido en la figura 12.

4.11.3. Instalación del servidor web El servidor Web seleccionado para este proyecto es Apache, que será el encargado de recibir y responder a las peticiones Web que se realicen dentro del Clúster. Todos los pasos necesarios para instalar y configurar el servidor HTTP se encuentran detallados en el Anexo 11.

4.11.3.1. Página web Es el nombre con el que se conoce a los documentos adaptados para ser visualizados en un navegador Web. 4.12. Estrategia para agregar nodos adicionales al clúster Para agregar un nuevo nodo al clúster, es necesario realizar las actividades que se muestran en la figura 14.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



75



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



76

4.13. Comandos principales para la administración del clúster

Para ver una lista de los comandos más útiles de administración del clúster con una breve explicación de los mismos, véase el anexo 11.

RELACION ENTRE MI CLUSTER Y LOS SERVICION WEB.

Un clúster de servidores usa varios servidores dedicados para hacer varios trabajos diferentes, o para compartir la carga de una tarea importante. Agregue tantos servidores como necesite para mantener su nivel preferido de desempeño.

Una configuración muy común de cluster de servidores es un cluster de servidores web (o Cluster Web), que distribuye el tráfico de internet sobre varios servidores web usando balance de carga. Esto crea un servidor de alta disponibilidad con capacidad incrementada y conmutación por errores.

Cluster que estoy creando puede diseñar un cluster web a la medida para sus requerimientos exactos, o usted puede rápidamente obtener un servidor web de alta disponibilidad con el paquete básico de Cluster Web delineado abajo.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



77

CAPITULO V 5. PRUEBAS FUNCIONALES Y RESULTADOS A diferencia de las pruebas individuales realizadas durante la fase de configuración de los componentes del clúster, las pruebas funcionales consisten en verificar que todos los componentes dentro del clúster funcionen correctamente, tanto en las tareas de migración como de replicación.

5.1. PRUEBAS DE REPLICACIÓN DEL CLÚSTER CON 2 NODOS De acuerdo a la figura 7, la replicación en el clúster debe hacerse entre los datos de los recursos del Nodo A y del nodo B, por lo tanto vamos a verificar que los cambios realizados en los archivos ó carpetas de los recursos de un nodo se repliquen al otro nodo En la tabla 1 se muestran los escenarios de prueba para el proceso de replicación con sus resultados. Como se puede observar, todas las pruebas se realizaron correctamente y los resultados fueron positivos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



78



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



79

Tomando en cuenta los resultados de estas pruebas se puede ver que la estrategia de implementación propuesta para el proceso de replicación funciona correctamente y DRBD está correctamente integrado dentro del clúster con 2 nodos.

5.2. Pruebas de migración del clúster con 2 nodos De acuerdo a la figura 7, la migración de recursos debe hacerse entre los recursos del Nodo A y del nodo B, por lo tanto es necesario verificar que los recursos de un nodo se transfieran al otro. Los escenarios de migración evaluados en el clúster con 2 nodos se encuentran detallados en la siguiente tabla.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



80

Tomando en cuenta los resultados de estas pruebas se puede ver que la estrategia de implementación propuesta para el proceso de migración funciona correctamente, por lo tanto Corosync y Pacemaker están correctamente integrados dentro del clúster con 2 nodos.

5.3. Pruebas funcionales del clúster con 3 nodos Las pruebas funcionales del clúster con 3 nodos son similares a las realizadas en el clúster con 2 nodos. De acuerdo a la figura 12, la replicación en el clúster debe hacerse entre los datos de los recursos del Nodo A y del nodo B, así como los datos de los recursos del Nodo A y del nodo C. Los escenarios de migración evaluados en el clúster con 3 nodos se encuentran detallados en la tabla 4.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



81

5.4. Pruebas de migración del clúster con 3 nodos De acuerdo a la figura 12, la migración de recursos WEB - PHP debe hacerse entre los nodos A y B. Así mismo, la migración del recurso HTTP debe hacerse entre los nodos A y C. Los escenarios de migración evaluados en el clúster con 3 nodos se encuentran detallados en la siguiente tabla.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



82

De acuerdo a los resultados obtenidos, se puede ver que la estrategia de implementación propuesta para los procesos de replicación y migración también funciona para el clúster con 3 nodos, por lo tanto los componentes principales del clúster como DRBD, Corosync, Pacemaker, así como los recursos de WEB – PHP están correctamente integrados dentro del clúster.

6. Conclusiones y Recomendaciones

6.1. Conclusiones 1. Durante el desarrollo del presente trabajo se realizó un estudio de campo de las empresas del Perú, que fue analizado y documentado en el presente informe. A partir de este análisis obtuvo conocimientos necesarios para entender las causas del problema de disponibilidad así como para proponer alternativas de solución. En base al análisis se propuso cambios principalmente en los diseños de red de las Empresas en general del Peru.. Estos cambios tenían como objetivo mejorar la velocidad de las conexiones y presentar un mejor ordenamiento de sus componentes. Esto se logró al simplificar tanto el diseño lógico como son las configuraciones de red de los equipos.

Con la realización de este trabajo se definió una estrategia para la implementación de un clúster de alta disponibilidad para mejorar los servidores Web de N nodos usando software libre, que puede ser usada para proveer redundancia a las aplicaciones críticas de una empresa. A través de este trabajo, también fue posible proveer un sistema de tolerancia a fallas a servidores Linux usando un clúster de Alta Disponibilidad, cumpliendo de esta manera una de las metas planteadas al inicio del proyecto. En el desarrollo teórico del proyecto se definieron los componentes básicos para la implementación de un clúster HA y se explicaron los aspectos más importantes de cada uno, además se mencionó la función que tiene cada componente y como se integran dentro del clúster de Alta Disponibilidad. Con la finalidad de demostrar que la estrategia planteada si funciona, primero se diseñó e implementó un clúster de alta disponibilidad con 2 nodos para ofrecer los servicios de WEB. Luego se añadió un nodo adicional para ofrecer el servicio de HTTP y se modificó el diseño original de tal manera que los recursos sean distribuidos a nodos específicos dentro del clúster y que los servicios de WEB – PHP estén siempre juntos en un mismo nodo; logrando así un ejemplo de implementación para un escenario avanzado. Durante la implementación del prototipo del proyecto también se indicó paso a paso cómo instalar, configurar, integrar y probar el software necesario para formar un clúster de alta disponibilidad. Así mismo se mostró cómo modificar la configuración del clúster para agregar un nodo adicional y se dio una breve explicación de los comandos más útiles para la administración del clúster.

En este último capítulo se presentan las conclusiones a las que se ha llegado después de realizado el presente trabajo, así como recomendaciones si se desea realizar futuras investigaciones siguiendo la misma línea de estudio ya sea para mejorar aspectos del mismo tema o para aplicar la metodología seguida en otros entornos



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



83

Es importante mencionar que pese a que los problemas encontrados durante la instalación de los componentes para formar el clúster fueron solucionados probando diferentes versiones del software, los problemas encontrados durante la configuración e integración de cada componente demandaron más lectura e investigación que la esperada, sobre todo por problemas de incompatibilidad y errores de configuración ya que la información encontrada en los documentos oficiales, libros y artículos en Internet está desactualizada e incompleta, incluso fue necesario leer el código fuente de algunas aplicaciones

Con los resultados obtenidos durante la realización de este trabajo puedo afirmar que Linux y el software de distribución libre son una alternativa real para la implementación de un clúster de alta disponibilidad. Una empresa podría usar la propuesta planteada en este trabajo y en lugar de pagar regalías por usar software propietario podría pagar la capacitación del personal técnico en el Sistema Operativo Linux obteniendo así un valor agregado a la implementación del proyecto. Aunque los aspectos relacionados con la seguridad, escalabilidad, optimización o rendimiento del clúster están fuera del alcance de este proyecto, por no ser temas triviales, estos deben ser considerados para una implementación en un ambiente real. Tomando en cuenta lo dicho anteriormente, este trabajo puede servir como punto de partida para realizar profundizar esos temas en trabajos posteriores. Como experiencia personal puedo decir que con este trabajo he podido enriquecer mi conocimiento acerca de los sistemas Linux y el software de libre distribución. Así mismo, he comprendido que para poder usar software libre en proyectos como este, es necesario estar dispuesto a enfrentarse a problemas poco conocidos y en algunas ocasiones totalmente desconocidos, que para solucionarlos requieren de paciencia, dedicación y sobre todo el deseo de aprender a través de la investigación y autoeducación. Como conclusión final y quizá las más importante a la que he podido llegar, es que la estrategia de implementación propuesta y el software sugerido en este trabajo permiten la implementación de clústeres de alta disponibilidad de N nodos con diseños complejos, como el presentado en la implementación del prototipo con 3 nodos y 3 servicios

6.2. Recomendaciones A continuación se listan algunas de las recomendaciones más importantes para la implementación de un clúster HA:

Verificar que el hardware que se va a usar esté soportado o certificado por el Sistema Operativo.

Nunca usar versiones beta de software en un clúster HA en un ambiente de producción. Usar hardware del mismo proveedor en los nodos del clúster, especialmente las tarjetas

de red y los medios de almacenamiento. Nunca actualizar el software de los componentes del clúster en un ambiente de

producción sin haber realizado las pruebas respectivas. Revisar periódicamente los archivos de logs de los nodos del clúster. Revisar regularmente los anuncios oficiales del software que se esté usando, es posible

que existan actualizaciones para mejorar el software, solución de errores o parches de seguridad.

Crear planes para realizar tareas de mantenimiento de hardware en los nodos. Documentar el diseño y la configuración del clúster. Familiarizarse con la administración de clúster antes de ponerlo en producción.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



84

Por otro lado, para poder implementar satisfactoriamente un clúster HA es recomendable leer la documentación oficial del software que se va a utilizar, además es necesario entender los conceptos y definiciones básicas de los mismos. También hay que tomar en cuenta que aunque la implementación de un clúster HA puede ser una buena solución para los problemas de falta de redundancia en las aplicaciones críticas de una empresa, también puede crear otros problemas y convertirse en un dolor de cabeza para los administradores de sistemas, especialmente si el hardware que soporta las aplicaciones no es fiable. Se recomienda seleccionar sabiamente el hardware que se va a usar en un clúster de alta disponibilidad. En la actualidad, la alta disponibilidad de las aplicaciones es muy importante no solo para el desempeño de una empresa sino para su imagen corporativa, es por eso que la tolerancia a fallas es un tema que debe ser considerando muy seriamente por toda empresa que quiera ser o llegar a ser competitiva. También es importante mencionar que siempre se debe pensar en la escalabilidad que tendrá un proyecto relacionado con un clúster de alta disponibilidad, de tal manera que el desempeño del clúster no se vea degradado en el futuro por temas relacionados con la falta de recursos por la poca capacidad de los equipos. El presente trabajo se enfocó en la mejora de la disponibilidad de servidores web utilizando clustering de servidores y se trató principalmente temas de balance de carga y replicación de datos. Estos temas son muy amplios y solo se abarcó parte de ellos dejando de lado otros aspectos importantes al tratar con sistemas distribuidos, en seguida se presentan algunas recomendaciones y posibles trabajos futuros para quienes deseen seguir esta línea de estudio: 1. Debido a problemas administrativos y técnicos no se pudo implementar el modelo distribuido propuesto en las empresas del Perú. Un posible trabajo futuro seria tomar el modelo propuesto e implementarlo en el ambiente real realizando pruebas reales de disponibilidad y comparando los resultados obtenidos con los de esta tesis. En base a eso se plantearía un proyecto a la Universidad mostrando las mejoras que supondría la implementación del modelo en la disponibilidad de sus servicios web y en el bienestar de los alumnos profesores y administrativos. 2. En el presente trabajo no se ha consideró la posible extensión del diseño para soportar más servidores, sería interesante proponer un diseño más genérico del mismo abarcando aspectos de manejo eficiente de la concurrencia de procesos y de recursos a medida que se van aumentando nodos al sistema. 3. En el desarrollo del diseño propuesto no se tomó en cuenta la reorganización de la red de servidores de las empresas del Perú la mayoría, para maximizar la mejora de la disponibilidad y mejor acoplamiento con el diseño que se propuso. Un trabajo futuro seria la investigación de un diseño de red propuesto para las empresas en general del peru que maximice la mejora de la disponibilidad usando clúster de servidores. 4. El criterio de balance de carga se seleccionó en base a lo que analíticamente se pensó que sería una forma efectiva de repartir la carga de peticiones a páginas web, pero no se estudió con detalle todos los criterios posibles para este tipo de peticiones. Un trabajo futuro seria la investigación de distintos criterios de balance de carga para servidores web probándolos en los posibles escenarios y concluyendo los mejores para cada uno de ellos.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



85

Un clúster de Alta disponibilidad, así como cualquier otro equipo que esté conectado a una red de computadores, puede ser objeto de ataques por personas malintencionadas; por lo tanto deben implementarse las medidas de seguridad necesarias para proteger a los componentes del clúster, como por ejemplo: control de acceso físico a los servidores, implementación de un firewall para el sistema operativo y los servicios del clúster, etc. Para finalizar, quiero mencionar que nunca se debe confundir la palabra libre con gratis, ni tampoco se debe asumir que, por implementar un proyecto usando software libre el proyecto no va a tener ningún coste; en la práctica, sólo el software es el que se distribuye libre y gratuitamente, mas la instalación, configuración, mantenimiento y soporte del software libre en algunas casos, por no decir en su gran mayoría, sí tendrá un coste.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



86

Referencias. [1] Project Management Institute (2008). A Guide to the Project Management Body of Knowledge (PMBOK® Guide).Fourth Edition. USA: Project Management Institute. [2] Haddad, I. (2006). The HAS architecture: highly available and scalable cluster architecture for web servers. Canada. [3] Magnos, M., Mohamed, K., y Karama, K. Modeling service availability in web clusters architectures. Francia. [4] Moreno, A.(2010). Clúster web de alta disponibilidad a través de una WAN. España. [5] EUKHOST LTD. Linux Load Balancing and High Availability Servers. [En línea]. [Fecha de consulta: 31 de Agosto 2012]. Disponible en: http://www.eukhost.com/linux-load-balancing.php [6] Michael Sparks. HUNT, Bobby. Load balancing the UK National JANET Web Cache service using Linux Virtual Servers. [En línea]. [Fecha de consulta: 31 de Agosto 2012]. Disponible en: http://www.linuxvirtualserver.org/docs/PilotService.html [7] MICROSOFT. Achieve high availability and scalability using ARR and NLB. [En línea]. [Fecha de consulta: 31 de Agosto 2012]. Disponible en: http://technet.microsoft.com/en-us/library/ee683895%28v=ws.10%29.aspx [8] Rubio, M. (2005). El análisis documental: indización y resumen en bases de datos especializadas. Madrid, España: Consejo Superior de Investigaciones Científicas (CSIC), Centro de Información y Documentación Científica (CINDOC). [9] Ander, E. (1982). Técnicas de investigación social. Argentina: Humanitas. 10] Blaxter, L., Hughes, C. (2002). Cómo se hace una investigación. España: Gedisa. [11] The Computer Language Company Inc. (2001). Computer desktop encyclopedia. USA: Osborne/McGraw-Hill. [12] Spainhour, S., y Quercia, V. (1996). WebMaster in a nutshell. USA: O'Reilly & Associates. [13] Shklar, L., Rosen, R. (2003). Web Application Architecture: Principles, protocols and practices. England: John Wiley & Sons Ltd. [14] Hunt, C. (1997). TCP/IP network administration. USA: O'Reilly & Associates. [15] DuBois, P. (2003). MySQL cookbook. USA: O'Reilly & Associates. [16] Hugh, E., Lane, D., y Lane, W. (2002). Web database applications with PHP & MySQL. USA: O'Reilly & Associates.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



87

[17] Gao, A., Pan, Q., y Hu, Y. (2006). The research of differentiated service and load balancing in web cluster. Romania: IJCCC, Agora University. [18] Ali, F., y Zaman, R. (2012). The study on load balancing strategies in distributed computing system. India: IJCSES, Department of Computer Science, Aligarh Muslim University. [19] Bourke, T. (2001). Server load balancing. USA: O'Reilly & Associates. [20] Cardellini, V., Colajanni, M., y Yu, P. (1999). Dynamic load balancing on web server systems. USA: IEEE Computer Society. [21] Sanghi, D. Mechanisms for request distribution. India. [En línea]. [Fecha de consulta: 16 de Octubre 2012]. Disponible en: http://www.cse.iitk.ac.in/users/dheeraj/mtech/puneet-agarwal/node7.html [22] Membrey, P., Plugge, E., y Hows, D. (2012). Practical load balancing: Ride the performance tiger. New York, USA: Apress. 23] Sanghi, D. Architectures emulated on test bed. India. [En línea]. [Fecha de consulta: 19 de Octubre 2012]. Disponible en: http://www.cse.iitk.ac.in/users/dheeraj/mtech/puneet-agarwal/node34.html [24] Kopper, K. (2005). The Linux enterprise cluster: Build a highly available cluster with commodity hardware and free software. USA: William Pollock. [25] International Conference Glasgow. (2006). Computational science and its applications _ ICCSA 2006. UK: Marina Gavrilova et al. [26] Leroux, M. (2007). Learning WCF. USA: O'Reilly Media, Inc. [27] Henderson, C. (2006). Building scalable web sites. USA: O'Reilly Media, Inc. [28] Shiflett, C. (2003). HTTP developer_s handbook. USA. [29] Monge, R. (2005). Base de datos distribuidas: Replicación. Valparaíso, Chile: Universidad Técnica Federico Santa María. [30] Gray. J., Helland, P., O'Neil, P., y Shasha, D. (1996). The dangers of replication and a solution. Microsoft Research, Microsoft Corporation. [31] Timothy, G. Data modeling and databases. ETH Zürich, Suiza: Systems Group Department of Computer Science. [32] Wiesmann, M., Pedone, F., Schiper, A., y Kemme, B. (2000). Understanding replication in databases and distributed systems. Swiss Federal Institute of Technology. Operation Systems Laboratory, Institute of Information Systems. [33] Kuz, I. Replication and consistency - COMP9243 _ Week 3a (12s1). School of Computer Science & Engineering. The University of New South Wales.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS



88

[34] Saito, Y., y Shapiro, M. (2005). Optimistic replication. Hewlett-Packard Laboratories, Palo Alto, CA, USA and Microsoft Research Ltd., Cambridge, UK. [35] Gopalakrishnan, K. (2006). Oracle database 10g real application clusters handbook: Part 1: High availability architecture and clusters. Oracle.



BIBLI

OTECA DE C

IENCIA

S FÍS

ICAS

Y MATEMÁTIC

AS

tesis original 13 de Mayo - dspace.unitru.edu.pe

Documents

Transcript of tesis original 13 de Mayo - dspace.unitru.edu.pe