• Author / Uploaded
• xnsrt

• Categories
• Grupo de computadoras
• Comercio electrónico
• Internet
• Red mundial
• Tecnología

Citation preview

INACAP APOQUINDO I.P.

CLUSTER DE ALTA DISPONIBILIDAD Y BAJO COSTO

CLUSTER DE COMUNICACIONES SOBRE LINUX

MARCOS CANCINO D. JAIME MADRID AVILA RODRIGO OLIVERI

Tesis presentada a la carrera de Ingeniería en Gestión Informática, como uno de los requisitos para optar al Título de Ingeniero en Gestión Informática

Profesor Guía : Gérman Müller M. Profesor Informante : Mónica Ziede B.

Octubre/2002 Santiago, Chile

Dedicatoria

Dedicamos este documento a la pequeña y mediana empresa, como un modesto aporte en el área de las tecnologías de la información.

INACAP Apoquindo Ingeniería en Gestión Informática

Agradecimientos A través

de estas líneas quisiéramos expresar nuestros más sinceros

agradecimientos primeramente a los gestores originales de la idea de desarrollar un proyecto que trate el tema de clusters. Nos referimos a Leonardo Bolton y Robinson Maureira, los cuales ya varios meses atrás plantearon esta idea como un interesante desafío para nosotros, y más aún, realizaron las gestiones necesarias para poder contar con los materiales y el espacio para poder desarrollarlo. No conforme con ello, aportaron ideas y consejos en momentos claves, todo lo cual siempre a estado presente en nuestras consideraciones.

Agradecemos en forma especial a German Müller, que nos guió en el desarrollo de este seminario, por su permanente atención y sus continuos consejos. Y a todas aquellas personas que de una u otra forma, colaboraron o participaron en la realización de esta investigación, hacemos extensivo nuestros más sinceros agradecimientos. Marcos Dedico este seminario a mi madre, padre y hermano Juan que siempre me han alentado con mis estudios, y apoyado constantemente en cada etapa de mi vida. Rodrigo Dedico este seminario a mi esposa Valentina por su amor, apoyo y comprensión, a mis padres Cecilia y Agustín por el soporte permanente que me han brindado y a mi hermana Carla por su amistad y cariño. Jaime Dedico este seminario a mi familia, pues gracias a su ayuda he logrado superar los diferentes obstáculos y objetivos de mi vida.

2

INACAP Apoquindo Ingeniería en Gestión Informática

Resumen

Debido primordialmente a la competitividad y constante evolución de las tecnologías es que se hace necesario para las empresas el ir adaptándose y poder así lograr satisfacer las expectativas de sus clientes. Sin embargo no todas cuentan con el suficiente presupuesto para lograr financiar la integración de nuevas herramientas y tecnologías de información a su cadena operativa. De esta manera es que surge como un medio alternativo de bajo costo la tecnología LVS de cluster basadas en ambientes Linux; las que se caracterizan por tener bajos requerimientos de equipamiento de hardware, y bajos costos de licenciamiento de software, ofreciéndonos una plataforma estable par a responder a servicios de comunicaciones como Web, FTP y Mail entre otros. A lo largo del presente seminario se explicarán los fundamentos de la tecnología LVS, se expondrán distintas alternativas disponibles a la fecha y luego de desarrollará a nuestro parecer la más idónea teniendo siempre en mente que su integración esta orientada a PYMES.

3

INACAP Apoquindo Ingeniería en Gestión Informática

Indice

1.

INTRODUCCIÓN......................................................................................................... 1 1.1 1.2

2.

FORMULACIÓN Y DELIMI TACIÓN DEL PROBLEMA EN ESTUDIO................ 5 2.1 2.2

3.

Descripción del Entorno ...................................................................................... 5 Descripción del Problema...................................................................................6

OBJETIVOS.................................................................................................................. 8 3.1 3.2

4.

Antecedentes Generales ....................................................................................1 Justificación del Proyecto ...................................................................................3

Generales ..............................................................................................................8 Específicos ............................................................................................................8

MARCO TEÓRICO ......................................................................................................9 4.1 Tecnología de Clusters ....................................................................................... 9 4.1.1 Cluster............................................................................................................9 4.1.2 Tipos de cluster ............................................................................................9 4.1.2.1 Alta Disponibilidad (HA, High Availability)............................................9 4.1.2.2 Tolerante a Fallas (FT, Fault Tolerance)............................................10 4.1.2.3 Procesamiento paralelo masivo (MPP) ..............................................10 4.1.2.4 Cluster de multiproceso escalable (SMP) ..........................................10 4.1.2.5 NUMA, Acceso a memoria no unif orme.............................................11 4.2 Linux Virtual Server ...........................................................................................11 4.2.1 ¿Qué es un Linux Virtual Server? ...........................................................11 4.2.2 Componentes de un cluster LVS .............................................................13 4.2.3 ¿Cómo trabaja un servidor virtual?.........................................................14 4.2.4 servidor virtual vía NAT (VS -NAT) ..........................................................14 4.2.4.1 Traducción de direcciones de Red (NAT) .........................................14 4.2.4.2 Funcionamiento de servidor virtual Vía VS-NAT ..............................15 4.2.5 Servidor virtual vía túnel de IP (VS-TUN) ..............................................18 4.2.5.1 Túnel de IP o encapsulamiento de IP .................................................18 4.2.5.2 Funcionamiento del túnel de IP el VS-TUN.......................................19 4.2.6 Servidor virtual vía enrutamiento directo (VS-DR) ...............................20 4.2.7 Ventajas y desventajas de cada una de las técnicas ...........................21 4.2.8 Algoritmos de Balanceo de Carga...........................................................21 4.2.8.1 Round Robin (RR) .................................................................................21 4.2.8.2 Weighted Round Robin (WRR)............................................................22 4.2.8.3 Least Connection (LC) ..........................................................................22 4.2.8.4 Weighted Least Connection (WLC) .....................................................23 4.2.8.5 Locally Based Least Connection (LBLC) ...........................................24 4.2.8.6 Locally Based Least Connection Replication (LBLCR)....................24 4.2.8.7 Destination Hashing (DH) .....................................................................25 4.2.8.8 Source Hashing (SH) .............................................................................25

4

INACAP Apoquindo Ingeniería en Gestión Informática

4.3 Antecedentes de Desempeño..........................................................................25 4.3.1 Antecedentes Generales ..........................................................................25 4.3.2 Estimación de Tráfico................................................................................26 4.3.2.1 Antecedentes del Hardware de Red...................................................26 4.3.2.2 Limitaciones de tráfico debido al protocolo TCP/IP..........................26 4.3.2.3 Efecto del método de redireccionamiento sobre la red. ..................27 4.3.2.4 Determinado la capacidad necesaria para el Director. ....................28 4.3.3 Piranha.........................................................................................................28 4.3.3.1 Características del servidor de alta disponibilidad ...........................28 4.3.3.2 Características........................................................................................29 5.

METODOLOGÍA DE TRABAJO ..............................................................................30 5.1 Propuesta de solución.......................................................................................30 5.1.1 Alternativas .................................................................................................30 5.1.1.1 RedHat Linux Advanced Server. .........................................................30 5.1.1.2 Ultra Monkey ...........................................................................................31 5.1.1.3 Compaq Lifekeeper ...............................................................................32 5.1.1.4 LVS + Pulse + IPVS/IpvsAdmin + Nanny ...........................................33 5.1.2 Evaluación...................................................................................................33 5.1.2.1 Factibilidad técnica................................................................................33 5.1.2.1.1 RedHat Linux Advanced Server ..........................................................34 5.1.2.1.2 Ultra Monkey ...........................................................................................35 5.1.2.1.3 Compaq Lifekeeper ...............................................................................36 5.1.2.1.4 LVS + Pulse + IPVS/IpvsAdmin + Nanny ...........................................38 5.1.2.1.5 Manipulación del hardware...................................................................40 5.1.2.1.6 Entorno para alta disponibilidad ..........................................................40 5.1.2.1.6.1 Sistemas de computación.................................................................41 5.1.2.1.6.2 Sistemas de red .................................................................................41 5.1.2.1.6.3 Sistemas de apoyo de energía ........................................................41 5.1.2.1.6.4 Sistemas de almacenamiento..........................................................42 5.1.2.1.6.5 Sistemas de almacenamiento en disco..........................................43 5.1.2.1.6.5.1 Redundant Array of Independent Disks (RAI D) ..........................43 5.1.2.1.6.5.2 Logical Volume Management (LVM) ............................................43 5.1.2.1.6.5.3 Sistemas de archivos con bitácora (Journaling).........................44 5.1.2.2 Factibilidad económica..........................................................................44 5.1.2.2.1 Configuración mínima ...........................................................................46 5.1.2.2.2 Configuración recomendada................................................................47 5.1.2.3 Factibilidad Operacional .......................................................................49 5.1.3 Solución Propuesta....................................................................................55 5.2 Beneficios de la Solución..................................................................................56 5.2.1 Económicos:...............................................................................................56 5.2.2 Operacionales: ...........................................................................................56 5.2.3 Crecimiento horizontal: .............................................................................56 5.3 Desarrollo Técnico.............................................................................................57 5.3.1 Marco del Desarrollo. ................................................................................57 5.3.2 Plan de proyecto........................................................................................57 5.4 Análisis................................................................................................................60 5

INACAP Apoquindo Ingeniería en Gestión Informática

5.4.1 Modelo Conceptual....................................................................................60 5.4.2 Diagrama de Interacción...........................................................................62 5.4.3 Flujograma de paquetes de petición y respuesta.................................64 5.4.4 Especificación de Requerimientos..........................................................65 5.4.5 Especificación de Requisitos. ..................................................................65 5.4.5.1 Hardware.................................................................................................66 5.4.5.2 Software. .................................................................................................67 5.4.5.3 Competencia Técnica............................................................................70 5.4.6 Restricciones Técnicas y Funcionales. ..................................................70 5.5 Diseño. .................................................................................................................73 5.5.1 Diseño Red servidor virtual ......................................................................74 5.5.1.1 Red Pública.............................................................................................74 5.5.1.2 Red Privada ............................................................................................75 5.5.1.3 Direcciones IP asignadas en la red privada ......................................76 5.5.2 Servidor Director ........................................................................................77 Director ....................................................................................................................77 5.5.3 Servidor Director Respaldo ......................................................................77 Director ....................................................................................................................77 5.5.4 Servidor Real 1..........................................................................................78 real1 .........................................................................................................................78 TCP/IP .....................................................................................................................78 5.5.5 Servidor Real 2...........................................................................................78 real2 .........................................................................................................................78 5.5.6 Servidor Real 3...........................................................................................78 Real3........................................................................................................................78 5.5.7 Servidor virtual............................................................................................79 5.5.7.1 Configuración Parámetros Gl obales ...................................................79 5.5.7.2 Configuración servidor virtual ...............................................................80 5.5.7.3 Configuración por cada servidor real..................................................80 6.

INSTALACIÓN Y CONFIGURACIÓN SERVIDOR VIRTUAL.............................82 6.1 Servidor Director................................................................................................82 6.1.1 Sistema Operativo .....................................................................................82 6.1.2 Red Pública:................................................................................................82 6.1.3 Red Privada:...............................................................................................84 6.1.4 Configurar IP for warding e IP defragmenting........................................85 6.1.5 Configurar servicio SSH............................................................................85 6.2 Servidores Reales ..............................................................................................86 6.2.1 Sistema Operativo .....................................................................................86 6.2.2 Red Privada:...............................................................................................86 6.3 Servidor Director Respaldo ..............................................................................87 6.4 Servidor virtual....................................................................................................87

7.

PLAN DE PRUEBAS.................................................................................................89 7.1 Pruebas de Sistema. .........................................................................................89 7.1.1 Detalle de Pruebas....................................................................................90 7.1.1.1 Pruebas de Servicios. ...........................................................................90

6

INACAP Apoquindo Ingeniería en Gestión Informática

7.1.1.2 Pruebas de Conectividad......................................................................91 7.1.1.3 3. Pruebas de Alta Disponibilidad. ......................................................93 7.2 Pruebas de Aceptación. ....................................................................................99 7.2.1 Detalle de Pruebas ....................................................................................99 8.

ESCALABILIDAD DE NUESTRA SOLUCIÓN. ...................................................103

9.

PRESENTACIÓN DE DATOS Y ANÁLISIS DE RESULTADOS. ....................104 9.1 9.2

Antecedentes de las pruebas .........................................................................105 Resultados ........................................................................................................106

10.

CONCLUSIONE S ................................................................................................110

11.

GLOSARIO. ..........................................................................................................112

12.

BIBLIOGRAFÍA.....................................................................................................117

13.

ANEXOS................................................................................................................121

7

INACAP Apoquindo Ingeniería en Gestión Informática

Índice de Ecuaciones Ecuación 1: weighted least connection (WLC) ..............................................................23 Ecuación 2: weighted least connection (wlc) optimizada ............................................23 Ecuación 3: limitaciones de tráfico debido al protocolo TCP/IP .................................27 Ecuación 4: diferencia porcentual de rendimiento relativo. ......................................108 Indice de Ilustracioenes Ilustración 1: Linux virtual server .....................................................................................12 Ilustración 2: servidor virtual vía VS-NAT ......................................................................16 Ilustración 3: túnel de IP o encapsulamiento de IP ......................................................18 Ilustración 4: funcionamiento del túnel de IP el VS-TUN ............................................19 Ilustración 5: servidor virtual vía enrutamiento directo (VS-DR) ................................20 Ilustración 6: Compaq Lifekeeper, manejo de fallas en casc ada...............................37 Ilustración 7: Compaq Lifekeeper, escalabilidad de hardware...................................37 Ilustración 8: modelo conceptual .....................................................................................60 Ilustración 9: diagrama de interacción. ...........................................................................63 Ilustración 10: flujograma de paquetes de petición y respuesta ................................64 Ilustración11: diseño..........................................................................................................73 Ilustración 12: diseño red pública....................................................................................75 Ilustración 13: diseño red privada ...................................................................................76 Ilustración 14: gráfico respuestas por segundo. .........................................................107 Ilustración 15: rendimiento relativo de 2 servidores Web con y sin cluster ............109

8

INACAP Apoquindo Ingeniería en Gestión Informática

Índice de Tablas Tabla 1: servidor virtual vía VS-NAT (ejemplos) ...........................................................17 Tabla 2: ventajas y desventajas de cada una de las técnicas ....................................21 Tabla 3: ventajas y desventajas técnicas de las alternativas .....................................39 Tabla 4: precio promedio mercado nacional .................................................................46 Tabla 5: precios periféricos configuración recomendada............................................48 Tabla 6: precios software..................................................................................................48 Tabla 7: plan de proyecto .................................................................................................59 Tabla 8: requisitos de hardware ......................................................................................66 Tabla 9: características máquinas. .................................................................................67 Tabla 10: competencia técnica........................................................................................70 Tabla 11: parámetros de configuración red pública .....................................................74 Tabla 12: parámetros configuración red privada ..........................................................75 Tabla 13: direcciones IP red privada. .............................................................................76 Tabla 14: parámetros configuración red servidor director...........................................77 Tabla 15: parámetros configuración red servidor director respaldo ..........................77 Tabla 16: parámetros configuración red servidor real 1..............................................78 Tabla 17: parámetros configuración red servidor real 2..............................................78 Tabla 18: parámetros configuración red servidor real 4..............................................78 Tabla 19: configuración parámetros globales ...............................................................79 Tabla 20: configuración servidor virtual..........................................................................80 Tabla 21: configuración servidor real 1 ..........................................................................80 Tabla 22: configuración servidor real 2 ..........................................................................81 Tabla 23: configuración servidor real 3 ..........................................................................81 Tabla 24: pruebas de sistema..........................................................................................89 Tabla 25: pruebas servicio HTTP servidor virtual.........................................................90 Tabla 26: prueba de servicio FTP servidor virtual ........................................................90 Tabla 27: prueba de verificación ping.............................................................................91 Tabla 28: prueba de resolución de nombre (DNS).......................................................91 Tabla 29: prueba de servicio telnet.................................................................................92 Tabla 30: prueba de servicio ssh. ...................................................................................92 Tabla 31: prueba de servicio HTTP servidor real .........................................................92 Tabla 32: prueba de servicio FTP servidor real ............................................................93 Tabla 33: características servidor director para pruebas ..........................................104 Tabla 34: características servidor real para pruebas .................................................104 Tabla 35: características red pública y privada para pruebas ..................................105 Tabla 36: parámetros hammerhead..............................................................................105 Tabla 37: requerimientos por segundo.........................................................................106 Tabla 38: indicadores de rendimiento relativo de cada prueba................................108

9

INACAP Apoquindo Ingeniería en Gestión Informática

1. Introducción

1.1

Antecedentes Generales

La globalización de los mercados exige a las empresas un mayor grado de competitividad. Una de las for más de que más representa a este proceso de globalización es sin duda el comercio electrónico. Esta nueva forma de relacionarse de las empresas con otros mercados impone nuevos desafíos como disponer de los servicios de comercio electrónico continuamente, debido entre otras razones, a la transterritotialidad de los mercados. Las empresas utilizan diversas estrategias para lograr sus objetivos de negocios y una de las herramientas más usadas son las tecnologías de la información (TI), en donde se sustentan los principales procesos productivos, administración de ventas, clientes, proveedores, etc. Hemos visto que gracias a la utilización de las TI han surgido nuevos canales de venta, como es la venta a través de Internet, donde hoy podemos comprar en tiendas virtuales, pagar cuentas, hacer transacciones bancarias, solicitar prestamos, vender productos, etc., y todo esto puede realizarse todos los días del año y en cualquier horario, sin importar en que lugar del planeta nos encontremos, o del país que provenga la mercadería que deseemos adquirir.

¿Por qué las tecnologías de la información han alcanzado tal importancia?. De manera directa podríamos pensar que las razones fueron descritas en el párrafo anterior, sin embargo, a nuestro entender, hay una razón aún más poderosa, es que la información se ha transformado en el activo más importante o uno de los más importantes de una empresa y en algunos casos es el de mayor valor económico.

1

INACAP Apoquindo Ingeniería en Gestión Informática

Actualmente, las empresas que sustentan sus procesos basados en TI, utilizan una

compleja

infraestructura

compuesta

por

númerosos

componentes,

particularmente aquellas que usan Internet como canal de venta, canal de difusión de información, interacción con clientes, etc. Este tipo de actividades demandan gran cantidad de procesamiento de datos, almacenamiento y el uso extensivo de bases de datos. Todo esto esta sustentado por una compleja infraestructura tecnológica, compuesta tanto por tecnología propiamente tal como por profesionales calificados, capaces de manejar y administrar este tipo de plataformás . Dentro de la plataforma tecnológica, el mercado ofrece sofisticadas tecnologías basadas en hardware y software, que debido a su sofisticación, mercadeo y en muchos casos la dependencia que se establece entre el proveedor de la solución y quien la adquiere, entre otras razones, hacen que este tipo de soluciones tengan un elevado costo. En el caso del hardware, para dar un ejemplo, un servidor puede costar desde US$ 1.300 el más sencillo hasta unos US$ 2.000.000. El mundo de negocios en el que vivimos nos permite globalizarnos utilizando tecnologías de información (TI), haciendo uso del comercio electrónico y todas las herramientas que hoy disponemos a través de las redes de comunicación interconectadas, como Internet, pero también nos impone grandes exigencias para ser competitivos en este mundo global, exigencias como contar con nuestros servicios disponibles y durante las 24 horas. Este sencillo requerimiento nos impone demandas de TI costosa y mano de obra altamente especializada.

2

INACAP Apoquindo Ingeniería en Gestión Informática

Es lógico entonces preguntarse: ¿Cómo

pueden

las

PYMES

(Pequeñas

y

Medianas

Empresas)

ser

competitivas en el mercado global de hoy? ¿Cómo pueden las PYMES acceder a disponer de comercio electrónico con disponibilidad las 24 horas del día? ¿Es posible realizar esto a un costo sustentable para las PYMES?

¿Es posible crecer según la demanda?

1.2

Justificación del Proyecto

Motivados por las preguntas anteriormente planteadas, a través de este documento de estudio, intentaremos responder en algún grado estas preguntas.

Creemos además que las PYMES son un mercado ideal donde implementar nuestro proyecto, debido a muchas razones, tales como la escasez de recursos económicos de las PYMES para ser invertidos en tecnología, y limitaciones en la cantidad de recursos humanos en áreas de TI, que puedan ser destinados a investigar y desarrollar nuevas soluciones que le permitan enfrentar los nuevos desafíos, que muchas veces requieren de complejas tecnologías,

Para acotar el problema, de las preguntas, entenderemos lo siguiente: •

Ser competitivo: para efectos de este estudio será contar con una infraestructura tecnológica que permita el comercio electrónico a través de redes de comunicación como intranet. o Internet.

3

INACAP Apoquindo Ingeniería en Gestión Informática

•

Comercio electrónico: Cualquier servicio ofrecido, tanto en una Intranet como Internet, a través de servicios web, correo electrónico, transferencia de archivos (FTP) y bases de datos.

•

Disponibles las 24 horas del día: Servicios ininterrum pidos, 24 horas al día, 7 días a la semana, 365 días del año.

4

INACAP Apoquindo Ingeniería en Gestión Informática

2. Formulación y Delimitación del problema en Estudio 2.1

Descripción del Entorno

En la Pequeña y Mediana Empresa (PYMES), nos encontramos frecuentemente con problemas tales como falta de recursos económicos para adquirir TI adecuadas a las necesidades de demanda de la empresa y limitación en el número de profesionales de la información. Estos inconvenientes, hacen que este tipo de empresa deba buscar alternativas ingeniosas y lo más económicas posibles, teniendo como antecedente además, que dada la limitación en número de los recursos humanos informáticos y que no siempre se tiene el tiempo necesario para investigar alternativas y encontrar aquellas que sean las más adecuadas.

Si queremos montar un servicio de comercio electrónico en una empresa donde deseamos, por ejemplo, ofrecer productos o servicios a través del “Web” en Internet, necesitamos contar con a lo menos: •

Un servicio de conexión a Internet (enlace).

•

Un servidor con algún Sistema Operativo.

•

Aplicación de Servicio Web. (Servidor Web)

•

Haber desarrollado las paginas Web o aplicaciones Web que permitirán ofrecer los productos o servicios.

•

Un sistema de base de datos.

•

Un recurso humano que sea capaz de desarrollar, mantener el desarrollo, instalar el hardware y el software, configurar estos últimos, administrarlos, mantenerlos y dar el soporte necesario para dicha operación.

Sin embargo, ésta infraestructura mínima, dista mucho de ser una plataforma que nos permita ofrecer un servicio continuo durante 24Hrs. al día ya que, en algún

5

INACAP Apoquindo Ingeniería en Gestión Informática

momento será necesario interrumpir dichos servicios ya sea por mantención, actualizar las aplicaciones, instalar nuevos desarrollados o por fallas del sistema operativo, aplicaciones o hardware, por una interrupción en el sistema eléctrico o por alguna falla humana. Es decir, existe un sin número de razones por las cuales este sistema de comercio electrónico puede quedar fuera de servicio. Este problema se hace particularmente crítico si el servicio de comercio electrónico es un proceso importante en la empresa que aporta utilidades o información relevante, más aún si este es el medio principal de comercializar sus productos o servicios.

2.2

Descripción del Problema

El problema consiste en implementar un cluster1 con balanceo de carga, tolerante a fallas 2, soportar servicios como Web, correo, FTP, y bases de datos al menor costo posible. Otro de los problemas consiste en reutilizar el hardware dado de baja u obsoleto, para

las

necesidades

de

la

empresa,

estos

equipos

serán

utilizados

principalmente como servidores Web, correo, etc. La problemática de lograr tolerancia a fallas en un objetivo difícil de lograr, debido a que contamos con variables que no controlamos directamente, por lo tanto el problema consiste en minimizar el riego de ocurrencia de una falla. Sabemos que el hardware, sistemas operativos, enlaces de red, software pueden fallar y las personas pueden cometer errores, por lo tanto deberemos encontrar alguna manera de convivir con estos problemas , pero aún ante la ocurrencia de un incidente seguir prestando servicios.

1 2

Ver Sección 4.1 Ver definición en el Glosario para Cluster. 6

INACAP Apoquindo Ingeniería en Gestión Informática

La mayoría de los cluster actuales están limitados a trabajar con sistemas operativos únicos. Por ejemplo, si el cluster funciona sobre ambiente Microsoft, solo podrán ser soportados servicios que corran bajo ese sistema operativo. Esto se debe entre otras razones a la implementación que se hace en lenguajes de programación que no son portables a otros sistemas operativos, o que debido a que usan agentes (piezas de software que permiten integrar los nodos al cluster), que solo pueden ser ejecutados en un tipo de sistema operativo. Otra razón es que el diseño que se hace del cluster usa funcionalidades especificas de un sistema operativo, lo que tiene como consecuencia la dependencia de ese sistema operativo en particular, también existen diferencia en la implementación del protocolo TCP/IP en los diferentes Sistemas Operativos, lo que hace que algunas características del protocolo no estén presente en todos los sistemas operativos. La mayoría de los cluster soportan aplicaciones especificas, es decir que por ejemplo soporta solo IIS o Netscape como servidores Web pero no ambos; se debe instalar un agente en el servidor Web que permitirá interactuar con el cluster, esto finalmente se traduce en limitaciones de compatibilidad. La demanda sobre los servicios que deseamos prestar (Web, FTP, etc.) no es siempre constante y en ocasiones presenta bruscas alzas; por ejemplo en época navideña los sitios Web con servicios de venta por Internet o tiendas virtuales tendrán un número de transacciones significativamente mayor, esto significa que en la temporada de alta demanda el nivel de procesamiento puede alcanzar el 70% o 80% de utilización de el servidor Web y que el resto del año se mantiene cerca del 30 o 40% por ejemplo. Es decir que debido a la demanda que se produce durante un mes del año debemos costear un servidor que cubra esta demanda para mantenerlo subutilizado durante los 11 meses restantes. Por lo tanto, el problema es cómo lograr aumentar o disminuir la capacidad de procesamiento de manera sencilla, según la demanda.

7

INACAP Apoquindo Ingeniería en Gestión Informática

3. Objetivos 3.1

Generales

Desarrollar e integrar una solución de cluster de alta disponibilidad, confiabilidad3 y de bajo costo.

3.2

Específicos

A continuación enumeraremos los objetivos específicos de este proyecto. •

Proveer una implementación de cluster de comunicación de alta disponibilidad tolerante a fallas.

•

Que soporte múltiples plataformas.

•

Que soporte múltiples sistemas operativos.

•

Que soporte múltiples aplicaciones de servicios.

•

Permitir crecimiento y decrecimiento según la demanda de servicios.

•

Utilizar hardware de bajo costo.

•

Diseñar una solución orientada a las PYMES, que les permita implementar servicio de comercio electrónico o potenciar la instalación actual.

•

Establecer los requerimientos mínimos de Hardware para implementar esta solución.

•

Establecer los requerimientos mínimos de Software para implementar esta solución.

•

Construir un cluster de alta disponibilidad como modelo de prueba.

•

Establecer métricas y limitaciones de esta solución.

•

Implementar mejoras en las componentes actualmente disponibles.

•

Documentar la implementación de esta solución.

3

Ver definición en el Glosario para alta disponibilidad, confiabilidad. 8

INACAP Apoquindo Ingeniería en Gestión Informática

4. Marco Teórico 4.1

Tecnología de Clusters

4.1.1 Cluster Por definición, implica que dos o más computadores interactúen en estrecha conjunción con el otro para que trabajen como lo haría una sola máquina. De esta manera se puede incrementar el desempeño, confiabilidad de los sistemas o incremento de la distribución de cargas. 4.1.2 Tipos de cluster Existen cinco tipos esenciales de cluster: •

Alta Disponibilidad (HA, High Availability)

•

Tolerante a Fallas (FT, Fault Tolerance)

•

Procesamiento Paralelo Masivo (MPP, Massive Parallel Procesing)

•

Cluster de Multiproceso Escalable (SMP, Scalable Multi Processor )

•

De acceso a memoria no uniforme (NUMA, Non Uniform Access Memory)

Estas categorías no son consideradas clases mutuamente excluyentes. Un cluster puede ser construido usando un grupo de características de cualquiera de ellos.

4.1.2.1

Alta Disponibilidad (HA, High Availability)

Los cluster de alta disponibilidad (HA) se caracterizan principalmente por el uso de redundancia de los sistemas, basándose en el la utilización de software para alcanzar el objetivo de servicio continuo. Este tipo de software interviene en tres niveles, Kernel o núcleo del sistema operativo, en el área de usuario y sistemas de Archivos (file systems).

9

INACAP Apoquindo Ingeniería en Gestión Informática

4.1.2.2

Tolerante a Fallas (FT, Fault Tolerance)

Los cluster tolerantes a fallas, trabajan para alcanzar metas similares a la de la disponibilidad permanente, sin embargo la tolerancia a fallas es usualmente aplicada a tener implementada redundancia en el hardware más que en el software. Este tipo de cluster a veces no se considera como cluster ya que puede ser una sola máquina con sistemas internos redundantes 4, pero al combinarlo con un sistema operativo que tenga manejo de cluster, podría proveer disponibilidad continua.

4.1.2.3

Procesamiento paralelo masivo (MPP)

MPP ( Massive Parallel Procesing) es una clase de cluster donde muchos computadores individuales trabajan como uno solo. Este tipo de cluster está diseñado para proveer ambientes de alta escalabilidad para resolver problemas computacionales en donde sus componentes pueden ser procesadas en paralelo. Para que este tipo de cluster sea efectivo, requiere de software que realice un trabajo muy cuidadoso para asegurar el mayor nivel de paralelismo5 posible, así como también de mantenerlo coherente, como un solo problema.

4.1.2.4

Cluster de multiproceso escalable (SMP)

SMP (Scalable Multi Procesor) es un tipo de cluster relativamente nuevo; intenta combinar elementos de alta disponibilidad y tolerancia a fallas, en una arquitectura común. Pero existe un limite en la escalabilidad útil general de las máquinas multiprocesador para incrementar la potencia de computo. Sin embargo al correr múltiples instancias del Kernel en grupo de CPUs y en los subsistemas de I/O,

4 5

Ver definición en glosario para Sistemas Internos. Ver definición en glosario para Paralelismo. 10

INACAP Apoquindo Ingeniería en Gestión Informática

todo esto en la misma máquina, se crea un ambiente de cluster. Este diseño permite que el sistema operativo corra en una configuración más pequeña, (usualmente de 4 a 8 CPUs), un ejemplo de esto es el servidor SUN 10000 que con sus 64 CPUs puede tener hasta 8 dominios o máquinas virtuales Independientes, esto implica que cada dominio o máquina virtual usara 8 CPUs y que cada dominio funcionara como una máquina independiente.

4.1.2.5

NUMA, Acceso a memoria no uniforme

NUMA (Non Uniform Access Memory) y sus variaciones llevan largo tiempo. El esquema de diseño general de NUMA es combinar nodos de computadores en un gran cluster mediante el uso de buses de memoria interconectados. El efecto de este tipo de conexión es una gran cantidad de acceso a datos entre los nodos (todos los nodos pueden ser directamente direccionados a todos los segmentos de la memoria). Este modelo se considera generalmente altamente escalable, sin embargo tiende a tener problemas de “caching” 6 muy complejos

4.2

Linux Virtual Server

4.2.1 ¿Qué es un Linux Virtual Server? Un Linux Virtual Server (Servidor virtual de Linux), es un servidor altamente escalable, de alta disponibilidad, construido como un conjunto de servidores reales más el/los balanceadores de carga (Director) 7, bajo Linux como sistema operativo. Esta arquitectura de cluster es transparente para el usuario final, ya que el usuario final solo ve un único servidor virtual. Como se puede apreciar en la Ilustración 1, el usuario final solo “ve” el servidor virtual, representado por un circulo de línea punteada.

6 7

Ver definición en glosario para Director Ver capítulo 5.4.1 11

INACAP Apoquindo Ingeniería en Gestión Informática

Cliente Internet/ Intranet

Servidor Director

Servidor Real 1

LAN / WAN

Servidor Real 2

Servidor Real N

Servidor Virtual Ilustración 1: Linux virtual server Se debe considerar además, que los nodos o servidores reales pueden estar interconectados por una red local de alta velocidad, así como también distribuidos geográficamente a través de una WAN. La cara visible de los servidores reales es el Director o LVS (Linux Virtual Server), el cual está encargado de administrar los requerimientos hechos a los servidores reales y que se respondan paralelamente los servicios del cluster apareciendo este servicio virtual como una IP única. La escalabilidad está dada por la transparencia con que se puede agregar o eliminar un nodo del cluster, (real server). La alta disponibilidad es provista mediante la

12

INACAP Apoquindo Ingeniería en Gestión Informática

detección de una falla8 ya sea del nodo o del servicio que se está prestando y por la reconfiguración9 apropiada del sistema en forma automática.

4.2.2 Componentes de un cluster LVS •

IPVS Netfilter Kernel.

•

IPVSADMIN.

•

Un demonio que realice el traspaso por falla (fail over).

•

Un demonio que administre la tabla de enrutamiento de IPVS .

•

Un demonio que monitoree los servidores y sus servicios.

•

Un demonio que controle y administre unificadamente los otros demonios.

•

IPVS Netfilter Kernel. Esto es un parche que se debe aplicar al código fuente del Kernel de Linux, el que será necesario compilarlo e instalarlo en la máquina que será Director.

•

IPVSADMIN es una herramienta que administra las tablas de enrutamiento y la conversión de paquetes TCP desde la dirección IP virtual hacia los servidores reales y viceversa.

•

Un demonio que haga (fail over) entre directores para permitir la alta disponibilidad.

•

Un demonio que administre la tabla de enrutamiento de IPVS .

•

Un demonio que monitoree los servidores y sus servicios.

•

Un demonio que controle y administre unificadamente los otros demonios, para facilitar la administración.

8 9

Ver capítulos 5.4.2 y capítulo 5.4.6 definición de pulse y uptime Ver capítulo 5.4.2 definición de pulse 13

INACAP Apoquindo Ingeniería en Gestión Informática

4.2.3 ¿Cómo trabaja un servidor virtual? Un servidor virtual puede ser implementado de tres maneras, dado que este tipo de servidor virtual soporta tres técnicas de balanceo de carga (métodos de redireccionamiento de paquetes), coexistiendo en el Director.

Ellas son: •

Servidor virtual vía NAT (VS-NAT)

•

Servidor virtual vía Túnel de IP (VS-TUN)

•

Servidor virtual vía enrutamiento directo (VS-DR)

4.2.4

4.2.4.1

servidor virtual vía NAT (VS -NAT)

Traducción de direcciones de Red (NAT)

La traducción de direcciones de red, se origina debido a la escasez de direcciones IP y ocurre cuando una dirección IP es mapeada o traducida a otra. Existen diferentes mecanismos para la traducción de direcciones de red, las cuales se describen a continuación: N-a-N o NAT estático: N direcciones IP se traducen en N direcciones IP M-a-N o NAT dinámico: M direcciones IP se traducen en N direcciones IP, donde M>N N-a-1 o NAT: N direcciones IP y sus puntos TCP/UDP se traducen en una única dirección IP Este último caso es el utilizado por el enmascaramiento de IP practicado por Linux, siendo una de las piezas importantes de VS-NAT. Para más información, ver el rfc1631 10. 10

Ver bibliografía sobre documentos RFC 14

INACAP Apoquindo Ingeniería en Gestión Informática

4.2.4.2

Funcionamiento de servidor virtual Vía VS-NAT

Cuando un usuario accede a un servicio provisto por el cluster, el paquete destinado a la IP virtual (una IP externa del servidor director), llega al director , este examina la dirección de destino y el puerto del paquete. Si este último coincide con la tabla de servicios declarados en el director, se escoge uno de los servidores reales de acuerdo a un algoritmo de balanceo; se agrega la conexión recién establecida a la tabla que con tiene una lista indexada (hash) de las conexiones establecidas.

Luego este paquete es reescrito con la dirección IP y puerto del servidor real escogido, y el paquete se reenvía al mismo. Cuando el paquete de respuesta regresa al Director, este rescribe el paquete con la dirección y puerto de origen, con la IP virtual del Director. Una vez que la conexión termina o expira el registro de la conexión es eliminado de la lista indexada. (ver ilustración 2 y Diagrama de interacción en el c apítulo 5.4.3)

Una de las ventajas importantes de esta técnica es que puede ser instalada en cualquier Sistema Operativo que soporte el protocolo TCP/IP, los nodos puedes usar una red con IP’s privadas y se necesita tan solo una IP para el Director.

Tal vez la mayor desventaja de esta técnica es que la escalabilidad es limitada. El director puede llegar a convertirse en un cuello de botella de todo el sistema, cuando el número de nodos llega a 20 o más. Esto se debe a que ambos paquetes, tanto el de petición como el de respuesta, deben ser reescritos por el director.

15

INACAP Apoquindo Ingeniería en Gestión Informática

Cliente Internet/ Intranet

Servidor Director

Servidor Real 1

LAN / WAN

Servidor Real 2

Servidor Real N

Servidor Virtual

Ilustración 2: servidor virtual vía VS-NAT

Si suponemos que el largo promedio de un paquete TCP es de 536 bytes y que la demora promedio que se toma en escr ibir un paquete es de unos 60µs (en un procesador Pentium de 133 MHz, esto se puede reducir al usar CPU’s más rápidas), el flujo máximo de un director sería de 8,93 Mb/s, asumiendo que el flujo promedio de un nodo es de unos 400 Kb/s, el número máximo de nodos es de unos 22.

16

INACAP Apoquindo Ingeniería en Gestión Informática

Ejemplo: IP Director Cliente

puerto

202.100.1.2

3456

à

IP Virtual

puerto

202.103.106.5

80

Se re-escribe el paquete a IP servidor real Cliente

puerto

202.100.1.2

3456

à

IP Virtual

puerto

172.16.0.3

8000

La respuesta vuelve al director IP servidor real Cliente

puerto

172.16.0.3

8000

à

IP Virtual

puerto

202.100.1.2

3456

y el paquete es reescrito finalmente con la IP virtual IP servidor real Cliente

puerto

202.103.106.5

80

à

IP Virtual

puerto

202.100.1.2

3456

y el paquete es reescrito finalmente con la IP virtual Tabla 1: servidor virtual vía VS-NAT (ejemplos)

17

INACAP Apoquindo Ingeniería en Gestión Informática

4.2.5 Servidor virtual vía túnel de IP (VS-TUN)

4.2.5.1

Túnel de IP o encapsulamiento de IP

El encapsulamiento de IP es cuando el datagrama de una IP se envuelve dentro de otro datagrama IP como se muestra abajo. El encapsulamiento y desencapsulamiento consiste en rescribir el encabezado de los paquetes IP con la IP del servidor real.

Paquetes IP Encapsulando

desencapsulando

Ilustración 3: túnel de IP o encapsulamiento de IP

18

INACAP Apoquindo Ingeniería en Gestión Informática

4.2.5.2

Funcionamiento del túnel de IP el VS-TUN

El cliente envía un paquete al Director, este lo encapsula y lo envía al servidor real. El servidor real desencapsula el paquete y responde directamente al usuario, sin volver a pasar por el Director. Esta es una de las principales diferencias entre hacer túnel y NAT.

Cliente

Respuestas van director al cliente Internet/ Intranet

Peticiones

Procesamiento Peticiones

nel ip tu

Servidor Real 1

IP tunel

Servidor Director

IP T une l

Servidor Real 2

Servidor Real N

Servidor Virtual via Tunel

Ilustración 4: funcionamiento del túnel de IP el VS-TUN

19

INACAP Apoquindo Ingeniería en Gestión Informática

4.2.6 Servidor virtual vía enrutamiento directo (VS-DR) En esta técnica, cada servidor real tiene configurada en la interfase de red además de la IP real del servidor la IP Virtual. Entonces, lo que hace el director es dirigir el paquete a través de rutas directas al servidor real de acuerdo al algoritmo de balanceo que este tenga y es el servidor real el que responde al usuario de manera directa.

Cliente Respuestas van director al cliente Internet/ Intranet

Peticiones

Procesamiento Peticiones

Servidor Real 1

Intranet

Servidor Director

Debe ser un segmento fisico

Servidor Real 2

Servidor Real N

Servidor Virtual via enrutamiento directo

Ilustración 5: servidor virtual vía enrutamiento directo (VS-DR)

20

INACAP Apoquindo Ingeniería en Gestión Informática

4.2.7 Ventajas y desventajas de cada una de las técnicas VS-NAT

VS-TUN

VS-DR

Servidor

Cualquiera

Que pueda hacer túnel de IP Dispositivo no ARP

Red del servidor

Privada

LAN/WAN

Número de nodos

Bajo (10-20) Alto

Alto

Puerto de enlace del

Director

Enrutador de la red

Enrutador de la red pública

nodo

LAN

pública

Tabla 2: ventajas y desventajas de cada una de las técnicas 4.2.8 Algoritmos de Balanceo de Carga Los algoritmos de balanceo soportados por IPVS Netfilter son: •

Round Robin.

•

Weighted Round Robin.

•

Least Connection.

•

Weighted Least Connection.

•

Locally Based Least Connection.

•

Locally Based Least Connection Replication.

•

Destination Hashing.

•

Source Hashing.

4.2.8.1

Round Robin (RR)

Este algoritmo de balanceo es uno de los más antiguos y simples, fue diseñado para sistemas de tiempo compartido. En el contexto de LVS este algoritmo envía cada conexión al siguiente servidor en la lista formando un tipo de cola circular. Si tenemos tres servidores (A,B,C), un ciclo de 5 conexiones ocurriría como sigue: A,B,C,A,B. Todos los servidores reales son tratados como si fueran de igual rendimiento. 21

INACAP Apoquindo Ingeniería en Gestión Informática

4.2.8.2

Weighted Round Robin (WRR)

Este método se diseño para manejar de mejor forma a aquellos servidores que tienen capacidades de procesamiento distintas entre sí. A cada real server se debe asignar un valor de peso que indica la capacidad de proceso. Si tenemos 3 servidores reales (A;B;C) y los pesos asignados son 4, 3, 2, y en el ciclo de balanceo ocurrirá algo así: A, A, B, A, B, C, A, B, C.

4.2.8.3

Least Connection (LC)

El algoritmo de Least- Connection (menos-conexión) dirigirá las conexiones de red al servidor con el menor número de conexiones establecidas. Éste es uno de los algoritmos de programación dinámicos; porque necesita contar dinámicamente las conexiones activas para cada servidor. Para un servidor virtual que esté manejando un conjunto de servidores con similar funcionamiento, este método manejará bien la distribución cuando la carga de peticiones varía mucho. El servidor virtual dirigirá las peticiones al servidor real con menos conexiones activas. A primera vista puede parecer que este algoritmo pueda realizar bien su trabajo incluso cuando hay servidores de varias capacidades de procesamiento, porque el servidor más rápido conseguirá más conexiones. Sin embargo, la eficiencia de este algoritmo puede verse afectada debido a la configuración por defecto del protocolo TCP para el estado de es pera de la conexión (TIME_WAIT) que es generalmente de 2 minutos, lo que significa que durante este tiempo un sito Web muy ocupado, a menudo puede recibir miles de conexiones . Por ejemplo para un servidor A dos veces más grande que un servidor B; ambos recibirían la misma cantidad de conexiones; esto produciría que el servidor B respondiera mucho más lento que A y finalmente se podría atascar.

22

INACAP Apoquindo Ingeniería en Gestión Informática

4.2.8.4

Weighted Least Connection (WLC)

Este algoritmo de balanceo es un súper conjunto del método de Least Conection, en el cual se puede asignar un peso relativo a la capacidad de cada real server. Los servidores con un valor más alto de peso recibirán un porcentaje mayor de conexiones activas. Este algoritmo funciona como sigue: Suponiendo que hay n servidores reales, cada servidor i tiene un peso Wi (i=1.., n), y las conexiones activas Ci desde (i=1.., n),

La siguiente conexión será dirigida al servidor j, en el cual: n

Todas _ las _ Conexiones = ∑ C i i =1

    C j  Ci      n n   C       ∑ C i    ∑ i     i =1   i =1   = min    W j Wi          ( i = 1 .., n )  Ecuación 1: weighted least connection (WLC) Puesto que Todas_las_Conexiones es una constante en estas operaciones de búsqueda, no es necesario dividir Ci por Todas_las_Conexiones, puede ser optimizado como: C  = min  i  Wj Wi (i =1.., n ) Cj

Ecuación 2: weighted least connection (wlc) optimizada

23

INACAP Apoquindo Ingeniería en Gestión Informática

Es decir que la siguiente conexión la recibirá aquel servidor real que al dividir el número de sus conexiones activas por su peso relativo asignado sea el menor entre todos los servidores r eales desde i=1 hasta n. Este algoritmo requiere una división adicional que el método Least Connection. Tratando de reducir al mínimo los gastos indirectos de balanceo cuando los servidores tienen la misma capacidad de proceso, el peso asignado a cada servidor real variará dinámicamente en función de la carga que tenga en ese instante, de manera que se refleje la situación real actual que tiene cada servidor. Es decir que si un servidor recibe varias conexiones y su carga de trajo aumenta demás iado, su peso relativo disminuirá respecto del resto de los servidores.

4.2.8.5

Locally Based Least Connection (LBLC)

Este método está diseñado para balancear las conexiones en función de la IP de destino. Se utiliza generalmente en cluster de cache. Este algori tmo dirige generalmente el paquete destinado a una dirección IP al servidor si este último está activo y con baja carga. Si se sobrecarga el servidor (el número de conexiones activa es mayor que su peso) y hay un servidor con menos carga, entonces dirige la conexión a este servidor real.

4.2.8.6

Locally Based Least Connection Replication (LBLCR)

Este algoritmo es también para balancear de carga del IP de destino. Se utiliza generalmente en cluster de cache. A diferencia del método anterior (LBLC), este algoritmo funciona como sigue. El balanceador de carga mantiene mapeos de los posibles objetivos de un conjunto de nodos que pueden servir de blanco. Al llegar un requerimiento se asigna al nodo con menos conexiones en el conjunto del servidor blanco.

24

INACAP Apoquindo Ingeniería en Gestión Informática

Si el conjunto de servidor real no ha sido modificado por un tiempo, el servidor con mayor carga será eliminado de la lista de servidores, esto con el objeto de evitar un alto grado de replicación.

4.2.8.7

Destination Hashing (DH)

Este método de hashing asigna conexiones de red a los servidores buscando en una tabla de hash estáticamente asignada por sus IPs de destino.

4.2.8.8

Source Hashing (SH)

Este algoritmo de hashing asigna conexiones de red a los servidores buscando en una tabla de hash estáticamente asignada por sus IPs de origen.

4.3

Antecedentes de Desempeño

4.3.1 Antecedentes Generales La introducción de un Linux Virtual Server (LVS) en el sistema tendrá un impacto sobre el desempeño general de la red, estos estarán principalmente determinados por efectos de latencia y de tráfico de red o throughput. No se debemos olvidar que en los Linux Virtual Server, el servidor que actúa como Director desempeña dos roles principales, en uno deberá actuar como un enrutador de los servidores reales y en el otro deberá re-escribir los paquetes TCP, cambiando su dirección IP virtual a la real como se explico anteriormente en el capítulo 4.2.4.2. Si por algún motivo detecta mermas en el rendimiento de su red causadas por el Director del sistema LVS, debe descartar antes si el origen de la causa es debido

25

INACAP Apoquindo Ingeniería en Gestión Informática

a causas de Hardware, Sistema Operativo (OS) o por el software del LVS (IPVS). Es posible que el bus PCI o que su tarjeta de red no sea capaz de manejar el tráfico requerido. También debe verificar que su tarjeta esta efectivamente configurada y trabajando a la velocidad de tráfico deseada. (En el caso de este estudio deberá funcionar a 100Mbps en modo Full Duplex).

4.3.2 Estimación de Tráfico Para este análisis asumiremos que se ha realizado un adecuado ajuste de configuración de la granja de servidor es reales y que estos son capaces de entregar datos a los clientes en su rango de capacidad total en bits/seg o paquetes/seg. Al momento del diseño usted deberá considerar que su director deberá ser capaz de enrutar en número de requerimientos y sus respuestas a los clientes.

4.3.2.1

Antecedentes del Hardware de Red

Las redes de100 Mbps (Mega bits por segundo), no funcionan todo el tiempo a 100 Mbps., este flujo es alcanzado solo cuando se transportan continuamente paquetes de tamaño mtu (unidad de transferencia máxima, para redes de 100Mbps por defecto es 1500 bytes). A un paquete de 1 bit le tomará el mismo tiempo en ser transmitido que a un paquete mtu completo (1500 bytes). Si los paquetes son de una respuesta TCP o paquetes de 1 carácter de una sesión telnet, difícilmente alcanzara 1 Mbps en la misma configurada a 100Mbps.

4.3.2.2

Limitaciones de tráfico debido al protocolo TCP/IP.

El protocolo TCP/IP no puede usar los 100Mbps de un hardware de red de 100Mbps, debido a que la mayoría de los paquetes están pareados (, ; , ). Un enlace llevando paquetes mtu completos

26

INACAP Apoquindo Ingeniería en Gestión Informática

(1500 bytes cada uno) y sus respectivos , alcanzará presumiblemente 50 Mbps. Una mejor medida de la capacidad de tráfico de una red es la medición de flujo de paquetes, ya que para un paquete de 1 bit o de 1500 bytes tomará el mismo tiempo en ser transportado por la red. Una estimación de tráfico de paquetes se puede hacer de la capacidad de la red. 100 Mbps = 8333 paquetes / seg mtu (1500 bytes )

Ecuación 3: limitaciones de tráfico debido al protocolo TCP/IP Como aproximación de primer orden diremos que el tráfico de paquetes para una red TCP/IP es constante, esto nos ayudará de buna manera para poder predecir el rendimiento necesario para el director.

4.3.2.3

Efecto del método de redireccionamiento sobre la red.

El tráfico de paquetes se verá afectado por el método de redireccionamiento. Con el LVS-NAT todo el tráfico pasa a través del director en ambos sentidos. Además el director debe rescribir tanto los paquetes de entrada como los de respuesta, para cada uno de los s ervidores reales, (este es un proceso intensivo en computo, CPU). Considerando los antecedentes señalados en los capítulos 4.2.4, 4.2.5 y 4.2.6 el tráfico máximo (en paquetes) será el doble para LVS-TUN y LVS-DR, que para un LVS-NAT, además la carga promedio de CPU será mayor en un LVS -NAT, que en los otros dos métodos debido a que el director maneja el doble de paquetes.

27

INACAP Apoquindo Ingeniería en Gestión Informática

4.3.2.4

Determinado la capacidad necesaria para el Director.

La información necesaria para el diseño del director será sencillamente el número de paquetes/seg. que entregará la granja de servidores reales. El director no conoce el contenido de los paquetes (dado que se comporta como un switch de capa 411), y no le importa cuan grandes son.

4.3.3 Piranha

4.3.3.1

Características del servidor de alta disponibilidad

El servidor de alta disponibilidad RedHat es ideal tanto para las pequeñas empresas que quieren lanzar la fiabilidad de un sitio Web como para las grandes empresas y proveedores de servicios que requieren altos niveles de disponibilidad para sus clientes. Este servidor, de bajo costo, fácil de configurar se adapta perfectamente a medida que crecen sus exigencias. El servidor de alta disponibilidad de RedHat es una solución de clúster al alcance de la mano que ofrece un balance de carga dinámico, una tolerancia de errores mejorada y escalabilidad de las aplicaciones IP. Es ideal para los servidores web, los servidores FTP, las pasarelas VPN y las aplicaciones de interfaz de usuario donde se requiere servicio virtual ininterrumpido.

El servidor de alta disponibilidad de RedHat permite combinar servidores individuales en clúster obteniendo como resultado un acceso a los recursos de red más importantes como datos, aplicaciones y servicios de red. Si un servidor del cluster no funciona automáticamente otro lo sustituye.

11

Ver bibliografía sobre documentos de Switch capa 4. 28

INACAP Apoquindo Ingeniería en Gestión Informática

Este servidor se puede instalar en cualquier hardware que soporte Linux con lo que el ahorro en costos es bastante alto e incluso soporta entornos de red heterogéneos . Esto significa que los miembros de un clúster pueden ejecutar Linux o cualquier otro sistema operativo IP como Solaris o Windows.

Además, la tecnología Open Source (de Código Abierto) ofrece la posibilidad de acceder al código fuente que podrá modificar según crea necesario. Entonces se tiene el control de la situación. Además, la tecnología Open Source facilita la posibilidad de resolver inmediatamente los problemas de seguridad.

El servidor de alta disponibilidad de RedHat se puede configurar de dos maneras: En modo "Failover Services" (FOS) el sistema se puede configurar como un clúster con dos nodos fríos, lo que es ideal para las aplicaciones en las que se necesita redundancia como por ejemplo los firewalls, los servidores estáticos de Web, DNS, los servidores de correo y demás.

En modo "Linux Virtual Server" (LVS) el sistema se puede configurar como un clúster con n nodos el cual consiste en un balanceador de dos nodos conectado a un número indeterminado de servidores clúster. Este modo es ideal para las infraestructuras de Internet de grande volumen. El servidor de alta disponibilidad de RedHat incluye el soporte 24 horas al día semanales o cuando se necesite asistencia inmediata además del soporte para la instalación y configuración en horario estándar. El personal de RedHat da el soporte necesario siempre que sea necesario en casos de emergencia. 4.3.3.2

Características.

En general, Piranha es una solución sencilla de implementar visto que es una compilación de herramientas para el cluster Linux LVS, a las que se ha agregado una interfaz Web que facilita al usuario la instalación y configuración de esta aplicación.

29

INACAP Apoquindo Ingeniería en Gestión Informática

5. Metodología de Trabajo 5.1

Propuesta de solución

5.1.1 Alternativas Hoy en día existen variados tipos de soluciones de clustering de alta disponibilidad basados en Linux, de hecho el código abierto de este S.O. ha alentado a muchos grupos y personas a presentar distintas soluciones a situaciones en las cuales se requiere

que

ciertos

servicios

de

red

estén

siempre

disponibles

(alta

disponibilidad). Algunas de estas soluciones destacan por su elegancia y sencillez cuando se comparan con los costosos y normalmente complejos sistemas comerciales de tolerancia a fallas. A continuación veremos algunas de las soluciones de clustering de servicios más conocidas y utilizadas en la actualidad:

5.1.1.1

RedHat Linux Advanced Server.

Alternativa pr opuesta por RedHat, y cuyo origen esta basado en Piranha, la cual fue incluida también en la versión 6.2 de esta afamada distribución de Linux, la cual no es una herramienta única como tal, sino más bien es una colección de herramientas individuales, orientadas originalmente a prestar servicios de Web y FTP, basada en LVS. Las partes que manejan la alta disponibilidad dentro de Advanced Server constan principalmente de:

1. Kernel que soporta IPVS.

30

INACAP Apoquindo Ingeniería en Gestión Informática

2. Pulse: Demonio que supervisa a los demás, por otro lado maneja las fallas entre los ruteos de IPVS. 3. Nanny: Demonio monitor de los administradores y servicios en los servidores reales que forman parte del cluster. 4. LVS: Demonio administrador de las tablas de ruteo de IPVS a través de la herramienta de ipvsadmin. 5. Piranha: Herramienta gráfica, mediante la cual se administra y supervisa el entorno del cluster.

5.1.1.2

Ultra Monkey

Es una de las piezas claves del proyecto Vanesa (junto con Super Sparrow), creado por VA Linux para lograr la alta disponibilidad. Al igual que la alternativa de RedHat, Ultra Monkey (que nació oficialmente en mayo del año 2000) es también una colección de herramientas especializadas, luego de presentarse como una solución de bajo costo y código abierto para servicios de alta disponibilidad en la feria Linux World de ese mismo año. Su núcleo esta conformado por LVS y Hearbeat, destaca por ofrecer balanceo de carga. Ultra Monkey está formado por: •

Reescritura de cabeceras TCP/IP mediante LVS software.

•

Heartbeat: (latencia o latido de corazón) Demonio mediante el cual se desarrolla la alta disponibilidad en este sistema, enviando señales de status desde los servidores reales al computador Director .

•

Ldirectord: Demonio que espera el “feedback” de los servidores reales, y que corre sobre el computador director, actuando en conjunto con Heartbeat.

31

INACAP Apoquindo Ingeniería en Gestión Informática

5.1.1.3

Compaq Lifekeeper

Solución presentada por Compaq para lograr la alta disponibilidad basada en sistemas Linux. Está orientado a pequeños y medianos negocios que requieren de una plataforma tolerante a fallas para soportar aplicaciones de misión crítica. Su orientación de uso apunta por ejemplo: •

Servicios NFS de archivos.

•

Infraestructuras web.

•

Bases de datos críticas, incluyendo soporte para Oracle y aplicac iones IBM Data Center .

•

Aplicaciones para los sistemas de ventas a los clientes.

El software de esta solución es capaz de manejar desde 2 hasta 16 servidores reales sobre determinadas versiones de Linux, entre las que se destacan RedHat, SuSe, TurboLinux y Caldera.

Por supuesto, esta solución al ser desarrollada por una empresa fabricante de hardware, puede encontrarse entre sus especificaciones características físicas y dispositivos Compaq asociados a la utilización de este software. Es importante destacar que la tecnología Lifekeeper pertenece a Steeleye Tecnology Inc., por lo tanto es posible encontrar distintas implementaciones y configuraciones de esta aplicación en otros proveedores. Algunas alianzas que ha establecido Steeleye de importancia para distribuir su producto a parte de Compaq, que es la implementación analizada en este estudio son con: IBM, Dell, Hewlett-Packard Company, Intel y NCR entre otras.

32

INACAP Apoquindo Ingeniería en Gestión Informática

5.1.1.4

LVS + Pulse + IPVS/IpvsAdmin + Nanny

Es una novedosa alternativa que mezcla piezas con func iones especificas de distintos proyectos orientados a lograr la alta disponibilidad. Sus partes ya han sido mencionadas anteriormente dentro de sus proyectos originales. Lo original de esta colección de herramientas trabajando en conjunto es la flexibilidad de crecimiento que está sustentada en un Kernel con muy buen soporte. Por ejemplo, en el caso de Red-Hat 6.2 o superior, posee facilidad para agregar o quitar nodos en tiempo de operación, y mediante sencillos programás o cgi’s, se permite una adecuada monitorización ya sea por consola o por otros medios como podrían ser alarmás sonoras, envío automático de correos electrónicos, mensajes instantáneos (ICQ, SMS u otros ).

5.1.2 Evaluación A continuación mostraremos las características de cada solución desde el punto de vista técnico, económico y operacional, para luego establecer comparaciones que nos permitan determinar la solución más idónea a la problemática.

5.1.2.1

Factibilidad técnica

Todas las alternativas anteriormente mencionadas han sido desarrolladas hasta distintos puntos por personas particulares, grupos independientes, comunidades universitarias, privados y en algunos casos por empresas con fines de lucro, las cuales posteriormente han liberado el código fuente. Esto da una gama de tipos de instalaciones de sus partes, entre las cuales están: •

RPM’s (RedHat Package Manager, sistema de distribución y mantención de software).

•

Parches para Kernel (Para soportar IPVS).

•

Source RPM’s (que requieren compilación) .

33

INACAP Apoquindo Ingeniería en Gestión Informática

Por lo que se hace necesario para poder operar con la mayoría de estas soluciones tener los siguientes conocimientos técnicos como mínimo: •

Saber como parchar y recompilar un Kernel.

•

Conocim ientos de shell-scripting / PERL.

•

Conocer la lógica y funcionamiento de TPC/IP

•

Haber leído las documentaciones respectivas, según la alternativa escogida (man, documentación online, documentación anexa).

•

Conocimientos mínimos de administración de sistemas (como por ejemplo: ipchains, iptables, administración de demonios, compilación de módulos, syslog, etc.).

A continuación se verán aspectos técnicos específicos de las soluciones antes planteadas.

5.1.2.1.1 RedHat Linux Advanced Server Esta alternativa lleva a cabo mejoras del Kernel para aplicaciones de E/S (entrada/salida) y acceso de datos escalables a través de servidores múltiples. Soportado por RedHat Cluster Manager, proporciona un traspaso por falla (failover) avanzado y un balanceo de carga para lograr disponibilidad y fiabilidad razonables.

Entre otras características destacan: •

Failover NFS/CIFS. Acceso de datos fiable en un entorno heterogéneo.

•

Soporte de nodos escalable. Asegura

una

solución

clustering

escalable

para

atender

así

los

requerimientos de crecimiento de la empresa. •

Configuraciones de múltiples balanceos de cargas. 34

INACAP Apoquindo Ingeniería en Gestión Informática

Otorga múltiples opciones de configuración, lo que incrementan la flexibilidad y la personalización de configuraciones cluster. •

Failover de nodos 2. Con lo que se persigue un alto nivel de fiabilidad y disponibilidad a través de la protección ante fallas .

•

Dispositivos compartidos de almac enamiento. Participación progresiva para una comunicación constante con el cluster.

El nivel de asistencia y la abundante documentación dada por la compañía fabricante aseguran un apoyo óptimo al momento de instalar y posteriormente durante la explotación del sistema. Sin duda alguna, se requerirá de un técnico que sea capaz de manejar la información, atender los nuevos requerimientos y configuraciones a medida que las necesidades vayan cambiando.

5.1.2.1.2 Ultra Monkey Esta al ser una alternativa independiente re quiere específicamente de la capacidad del administrador para parchar el núcleo del S.O., además sería deseable que también el administrador pudiera hacer ajustes finos de algunas partes del mismo, como por ejemplo que las propiedades de red de los dispositivos de red (tarjetas de red) sean integradas y compiladas como parte del Kernel y no dejarlos como módulos externos. Otro detalle es que Ultra Monkey permite hacer balanceo de carga, por lo que se hace necesario un estudio previo de los distintos algoritmos balanceadores de carga y su correcta administración a la hora de implementar el servicio de clustering.

35

INACAP Apoquindo Ingeniería en Gestión Informática

5.1.2.1.3 Compaq Lifekeeper Aunque suene un poco contradictorio, esta es la más compleja, pero a su vez la más sencilla de las alternativas. Es compleja en el sentido de que es una pieza íntegramente desarrollada por Compaq como un producto comercial, por lo que muchas de sus partes se poden usar y administrar, pero no entender su funcionamiento integro pues es una “caja cerrada”; lo otro es que tiene detalles propios que hacen referencia por ejemplo a dispositivos de almacenamiento externos, que agregan más piezas y mayor complejidad. Por otro lado es una de las más sencillas en el hecho de que cuenta con el respaldo de una de las más grandes empresas de hardware en el mundo, y un excelente sistema de soporte 24 x 7 en la mayoría de los países occidentales. Incluso es posible contratar la instalación del cluster junto con la compra del equipamiento y las licencias involucradas. Aunque se de la posibilidad de que la instalación y puesta en funcionamiento del sistema estén consideradas en el contrato al momento de la compra, aún se necesitarán los servicios de un especialista que sea capaz de realizar las tareas administrativas de mantenimiento involucradas en el funcionamiento del sistema. Tecnológicamente hablando ésta es sin duda la solución más avanzada de las presentadas en este estudio. De hecho la compañía propietaria de esta tecnología nació por la compra del producto a la gigante NCR, en diciembre de 1999. Desde entonces hasta hoy Steeleye a introducido este producto a través de grandes asociados al mercado, como es este caso puntual, en el cual se analiza la versión para este producto presentada por Compaq. Entre otras características, presenta la capacidad de manejar fallas en cascada tal como se esquematiza en la ilustración 6, lo que permite mover los requerimientos de los clientes de un servidor a otro de manera transparente logrando con esto

36

INACAP Apoquindo Ingeniería en Gestión Informática

que el cliente jamás note errores en los servidores, solo tal vez un pequeño retardo en la respuesta de los servicios consultados.

Ilustración 6: Compaq Lifekeeper, manejo de fallas en cascada Por otro lado es capaz también de manejar escalabilidad de hardware y de aplicaciones, permitiendo añadir mayor poder de procesamiento a la configuración original tal como se muestra en la ilustración 7, y así soportar fallas en el software ejecutado dentro del cluster.

Ilustración 7: Compaq Lifekeeper, escalabilidad de hardware

37

INACAP Apoquindo Ingeniería en Gestión Informática

La instalación y puesta en marcha del sistema puede ser incluido durante la contratación del mismo, sin embargo el costo es muy elevado, por lo que sería más realista la contratación de un técnico o ingeniero que se encargue de dicha tarea, y se que preocupe de los detalles de diseño de la red, aspectos eléctricos y funcionales del mismo.

5.1.2.1.4 LVS + Pulse + IPVS/IpvsAdmin + Nanny Probablemente esta es la más flexible de las alternativas estudiadas, en lo que se refiere a servicios, crecimiento y necesidades de equipamiento. Sin embargo desde el punto de vista técnico es algo más compleja, ya que involucra tener un conocimiento cabal de sus partes para ser capaz de integrarlas y hacerlas funcionar en armonía. Por supuesto, como está basada en LVS, se hace necesario que el administrador sea capaz de recompilar un Kernel parchado (si se desea hacer ajustes para mejorar el desempeño de sus partes). También se deberá realizar un estudio previo del uso que se dará al cluster (servicios que este prestará) para poder determinar que tipo de algoritmo de balanceo de carga es el más adecuado para una respuesta satisfactoria.

38

INACAP Apoquindo Ingeniería en Gestión Informática

A continuación se presenta una tabla resumen que evidencia las ventajas y desventajas técnicas de las alternativas planteadas: RedHat Linux Advanced Server Nivel de apoyo de terceros en la instalación Atención post venta Nivel de conocimientos requerido por administrador Nivel de conocimientos de armado de equipos y redes requerido.

Ultra Monkey

Compaq Lifekeeper

LVS + Pulse + IPVS/IpvsAd min + Nanny

Óptimo

No disponible

Excelente

No disponible

Depende del contrato

No disponible

Excelente

No disponible

Medio

Avanzado

Medio

Avanzado

Medio

Alto

Bajo

Alto

Tabla 3: ventajas y desventajas técnicas de las alternativas

Pese a que técnicamente la solución propuesta por Compaq destaca entre las demás, frente al requerimiento inicial de utilizar hardware de bajo costo se ve en desmedro debido al precio de los equipos por la empresa, que superan con creces a los requeridos por las demás alternativas. (Para mayor detalle de esto referirse a factibilidad económica). Si bien es cierto que en este punto se analizan asuntos técnicos, no se puede dejar de lado los objetivos iniciales del proyecto, por lo que se debe inclinar a recomendar en primer lugar la solución Linux Advanced Server, principalmente por ser un paquete de solución propuesto por una empresa seria como RedHat, y por contar con un buen apoyo hacia sus clientes. En segundo lugar, la solución LVS + Pulse + IPVS/IpvsAdmin + Nanny, pues se presenta como una alternativa flexible y confiable, aunque algo más exigente con los requisitos exigidos al personal que estará a cargo de su instalación y administración

39

INACAP Apoquindo Ingeniería en Gestión Informática

5.1.2.1.5 Manipulación del hardware Por supuesto todo lo anterior esta referido explícitamente al manejo “lógico” de las soluciones planteadas, sin embargo no debemos olvidar nos del hardware y las tareas administrativas que involucran la implementación de estas soluciones.

Desde el punto de vista del equipamiento se requerirían los siguientes conocimientos técnicos básicos: •

El administrador debería tener conocimientos de armado y administración de equipos PC. (configuración de dispositivos, configuración del bios del equipo, interconexión de sus partes).

•

Conocimiento de la lógica y estructura de una red.

•

Conocimientos operacionales de equipos y piezas que involucran la alta disponibilidad. Con esto nos referimos puntualmente a: o La correcta manipulación y mantención de unidades UPS. o Administrar correctamente sistemas de Backup. o Ser capaz de monitorear adecuadamente el ambiente físico en el que opera el sistema. (evitando polvo, altas temperaturas o humedad excesiva).

5.1.2.1.6 Entorno para alta disponibilidad Linux como sistema operativo ofrece una serie de facilidades, para que los sistemas de alta disponibilidad puedan integrarse correctamente, tal y como se hace en otros entornos. Estas facilidades están relacionados directamente con el entorno de hardware y software para las aplicaciones de alta disponibilidad. En estas sección se comentaran los diversos subsistemas que ayudan a "virtualizar"

40

INACAP Apoquindo Ingeniería en Gestión Informática

recursos, así como subsistemas para evitar SPOF (Single Point Of Failure ó punto único de fallo).

5.1.2.1.6.1 Sistemas de computación Actualmente Linux es una plataforma de computación y superconmutación muy consolidada. Se puede afrontar la idea de eliminar SPOF en los sistemas, pero sólo a partir del nivel que Linux como sistema operativo pueda obrar. Es decir que si consideramos la computación al nivel de nodos y superiores no habrá problemas, pero si consideramos a nivel de procesadores y memorias, es más un problema muy cercano a una solución hardware tolerante a fallas.

5.1.2.1.6.2 Sistemas de red Linux puede presumir de tener una de las pilas TCP/IP más completas y estables que existen actualmente. La característica de IP Aliasing de Linux, permite asignar varias direcciones IP a una misma interfaz; esto permite poder levantar una dirección IP, exclusivamente, en un nodo del clúster. Si algún nodo perece con su IP, cualquier otro nodo del clúster puede pasar a realizar las tareas que el nodo con problemas debía atender.

También, Linux es capaz de actualizar sus tablas de rutas dinámicamente, gracias a demonios de enrutamiento tales como ospfd. Con estos servicios el clúster puede ser consciente de la topología de la red y reaccionar ante las caídas de líneas de comunicaciones o nodos.

5.1.2.1.6.3 Sistemas de apoyo de energía Otro de los puntos propensos a falla tiene que ver con la continuidad de la alimentación eléctrica a los equipos que intervienen en el sistema. Para esto es

41

INACAP Apoquindo Ingeniería en Gestión Informática

que se hace necesario considerar la utilización de equipos UPS12. Estos equipos son capaces de proveer energía eléctrica desde una batería por un cierto tiempo, el cual dependerá de las características técnicas de la misma. Con esto se logra tolerar cortes de energía por un rango de tiempo y mantener en operación el sistema, y en eventos prolongados de cortes, permitirá detener los servicios y apagar las equipos para evitar cortes de energía abruptos y por ende, posibles daños lógicos o físicos . Para mayor información y detalle de este punto, refiérase al anexo “Tipos y Configuraciones de Sistemas UPS”.

5.1.2.1.6.4 Sistemas de almacenamiento En los sistemas de almacenamiento existe una doble problemática: 1. SPOF en los elementos de almacenamiento. 2. Consistencia ante un crash o caída. El SPOF se soluciona con sistemas de discos capaces de hacer redundantes los datos, así como de sustituir un disco dañado por otro en reserva.

La consistencia ante un caída se consigue revisando la integridad de los datos; la consistencia debe ser verificada en el mínimo tiempo posible, ya que de ello depende el servicio. El período de tiempo dependerá de varios factores, entre ellos, la cantidad de datos que estén almacenados, si un disco, cinta u otro medio es dañado parcial o totalmente. Si el daño es parcial, el tiempo que demore dependerá de en que porcentaje el medio este afectado.

12

Ver definición en glosario para UPS. 42

INACAP Apoquindo Ingeniería en Gestión Informática

5.1.2.1.6.5 Sistemas de almacenamiento en disco

5.1.2.1.6.5.1 Redundant Array of Independent Disks (RAID) 13 Un subsistema RAID nos va a permitir eliminar SPOF de los recursos de almacenamiento. Actualmente el Kernel de Linux soporta RAID 0,1 y 5 con el manejador (driver) MD (Múltiples Dispositivos). Además de RAID por software también soporta gran número de controladoras SCSI y ATA100 que ofrecen volúmenes de RAID por hardware. Compaq e IBM han colaborado mucho en este aspecto, creando drivers para Linux de sus productos. También cabe mencionar los sistemas LAN- Mirror que son una opción barata para conseguir un medio compartido y eliminación de SPOF replicando por red. Esto funciona mediante la creación de espejos de datos a través de una red dedicada solo a estos efectos. Como ejemplos cabe destacar DRBD, NBD y ENBD y otros sistemas de escritura en bloques para medios de almacena miento orientados a alta disponibilidad.

5.1.2.1.6.5.2 Logical Volume Management (LVM) El software de gestión de volúmenes permite exportar los volúmenes de grupos de discos para que el servicio de datos pueda hacer uso de el. LVM fue inicialmente adoptado por IBM, luego por la OSF, que aun esta en desarrollo. No sólo es capaz de cambiar el tamaño de discos lógicos sino también de sistemas de archivos ext2.

13

Ver bibliografía sobre RAID . 43

INACAP Apoquindo Ingeniería en Gestión Informática

5.1.2.1.6.5.3 Sistemas de archivos con bitácora (Journaling). Journaling es una técnica que nació de las bases de datos y se ha ido incorporando a los sistemas de archivos. Cuando un sistema de archivos sufre una caída, dada a una falla del sistema, este se chequea completamente, corrigiendo las inconsistencias.

El método que utiliza esta técnica consiste en

llevar un registro de las modificaciones que ha ido ocurriendo en el sistema de archivos, posteriormente, ante la necesidad de una comprobación, este sistema sólo verificará las inconsistencias que puedan haber ocurrido en aquellos pocos archivos y directorios que hallan sido modificados.

El tiempo de puesta en consistencia de un sistema de archivos disminuye considerablemente en comparación a otros sistemas . Además se incorporan técnicas como árboles B y Hashes 14 para un acceso más rápido a archivos.

5.1.2.2

Factibilidad económica

La orientación a las PYMES del presente estudio presupone un escenario de presupuestos bajos, bajo perfil del departamento de datos de la empresa (considerando que en muchas ocasiones el departamento de datos de la PYME esta conformada por solo una sola persona) y el desafío de lograr la alta disponibilidad con los recursos actuales.

Es entonces que la palabra Linux comienza a “rimar” en este esquema, y abre una gama de posibilidades a bajísimos costos, y más aun hoy, donde es posible encontrar servicios de soporte en línea muy completos y en algunos casos soporte telefónico y/o mail, según sea la distribución escogida, detallados manuales impresos y electrónicos, además de un núcleo (Kernel) estable del sistema 14

Ver bibliografía sobre los hashes y árboles B. 44

INACAP Apoquindo Ingeniería en Gestión Informática

operativo sobre el cual funcionarán los servicios y se fundara el pilar del giro productivo y/o comercial de la empresa. Pero por sobre todas las cosas la idea más atractiva es el carácter de libre distribución del sistema operativo, lo que redunda en costo cero en el ítem de licencias de sistemas operativos y software en general. Por supuesto existen soluciones o al menos partes de ellas que si tienen un costo de licenciamiento asociados, y en algunos casos equipo “hardware” especifico que se hace necesario cuando deseamos aproximarnos a la idea de alta disponibilidad.

Para comenzar se hará referencia a un equipamiento básico común teniendo en mente que el requerimiento mínimo para la instalación del SO es apenas un equipo PC 386 (con esto nos referimos a equipos de escritorio muy antiguos, los cuales en la mayoría de las empresas se encuentran ya almacenados en bodegas y en otras ocasiones son rematados o regalados a empleados por el escaso uso que se les da). Sin embargo, siendo más realistas en nuestras recomendaciones, nos apegaremos a los requerimientos mínimos actuales para la instalación del SO y el software asociado, es así como por ejemplo RedHat pide para la actual versión en distribución (RedHat 7.3): 1. Procesador de la clase Pentium o superior. 2. Velocidad de procesamiento de 200 Mhz o superior. 3. Mínimo de 650 Mb en disco duro (considerando solo la instalación del SO), lo que aumenta a 4.3 Gb para una instalación completa. 4. Mínimo de 32 Mb en Ram, recomendando 96 Mb en caso de utilización de entornos gráficos.

45

INACAP Apoquindo Ingeniería en Gestión Informática

5.1.2.2.1 Configuración mínima Como base se utilizará el siguiente equipamiento mínimo y básico ( si es que aplica ) para realizar una comparación económica: •

4 Computadores Pentium con las siguientes características: o CPU 200 Mhz o Disco duro de 10 Gb. o 128 Mb de ram o Tarjeta gráfica PCI con 8 Mb de memoria o Tarjeta de red PCI 10/100 ethernet o (Se considerarán otras 2 tarjetas de red de características similares a las anteriormente mencionadas)

•

2 Hub 10 Mb con la cantidad de puertos necesarios para conectar los 4 equipos.

•

Cables utp 5 en cantidad y largos necesarios.

•

Un monitor, cd-rom, teclado y mouse.

Usando como referencia avisos clasificados en medios escritos nacionales podemos obtener precios promedio como los que se detallan a continuación:

Equipos 4 Computadores

Valor US$ 698

2 Hub

US$ 163

Monitor, cableado y periféricos menores

US$ 116

Total periféricos

US$ 977

(Todos los precios expresados en dólar observado al 1 de julio de 2002, $ 688) Tabla 4: precio promedio mercado nacional

46

INACAP Apoquindo Ingeniería en Gestión Informática

De modo anecdótico podemos agregar además que según el reglamento contable nacional vigente todo equipo PC se deprecia totalmente partiendo desde el valor que figura en la factura hasta alcanzar $1 (un peso) cumpliéndose su tercer año de uso. No esta demás mencionar que en la actualidad el equipo PC más vendido en Chile es del tipo Pentium IV, y que los equipos mencionados en la tabla anterior ya no se fabrican desde hace más de 2 años.

5.1.2.2.2 Configuración recomendada Por supuesto que la evolución en el desarrollo y comercialización del hardware avanza a pasos agigantados, y el equipamiento pc recomendado en la configuración mínima garantiza el funcionamiento del software en él, llegando estrechamente a un equilibrio óptimo entre los recursos que brinda el equipo versus las necesidades del software. A continuación se detallará una configuración actualizada del equipamiento necesario: •

4 Computadores Pentium IV con las siguientes características: o CPU 1.6 Ghz o Disco duro de 40 Gb. o 128 Mb de ram o Tarjeta gráfica PCI con 8 Mb de memoria o Tarjeta de red PCI 10/100 ethernet o (Se considerarán otras 2 tarjetas de red de características similares a las anteriormente mencionadas)

•

2 Hub 10/100 Mb con la cantidad de puertos necesarios para conectar los 4 equipos. Por supuesto si se proyecta un cierto nivel de crecimiento sería recomendable comprar Hubs con la cantidad de bocas necesarias para poder agregar más nodos en el futuro.

47

INACAP Apoquindo Ingeniería en Gestión Informática

•

( El resto del equipamiento mencionado en las especificaciones mínimás sigue siendo adecuado )

4 Computadores

Equipos

Valor US$ 2384

2 Hub

US$ 282

Monitor, cableado y periféricos menores

US$ 116

Total periféricos

US$ 2782

(Todos los precios expresados en dólar observado al 1 de julio de 2002, $ 688) Tabla 5: precios periféricos configuración recomendada. En cuanto al software, a la fecha actual tenemos los siguientes valores referenciales para las propuestas estudiadas: Software Solución RedHat Linux Advanced Server

Valor US$ 799

Solución Ultra Monkey + SO Linux15

US$ 0

Solución LVS + Pulse + IPVS/Ipvs Admin + Nanny + SO

US$ 0

RedHat Solución Compaq Lifekeeper + SO Linux 16

US$ 13.699

Tabla 6: precios software.

Como conclusión de esta sección podemos ver en las tablas comparativas que en efecto las soluciones más económicas son la de Ultramonkey y “LVS + Pulse + IPVS/IpvsAdmin + Nanny”, ya que estas no exigen costos de licenciamiento por concepto de software, y presentan los menores requerimientos de hardware para

15

En realidad depende de la distribución Linux escogida, ya que existen algunas que son pagadas como es el caso de Caldera. Pero en vista que estamos insertos en el entorno de una PYMES se obvia que se escogerá una distribución gratuita. 16 En el caso de la solución Compaq este precio incluye los servidores administradores del cluster y el software sin ningún nodo, los cuales se compran por separado del paquete mínimo. 48

INACAP Apoquindo Ingeniería en Gestión Informática

por lo menos lograr una configuración tal vez no ideal, pero en todo caso funcional. Le sigue la alternativa de RedHat, que presenta costos de licenciamiento más bien asociados al soporte prestado que al producto en si, ya que el software incluido es muy parecido a las versiones libres, sin embargo poseen algunas modific aciones y mejoras orientadas a asegurar el funcionamiento de máquinas servidoras.

En último lugar tenemos la alternativa de Compaq, que si bien es sin duda la más completa y sólida de las presentadas, es a su vez la más cara, sobrepasando con creces los precios en comparación a los demás sistemas presentados.

5.1.2.3

Factibilidad Operacional

Según la última encuesta MIPYMES del instituto nacional de estadísticas, en Chile existirían algo más de 61.300 empresas que caen en la categoría de PYMES, de las cuales poco más de 21.000 cuentan con conexión a Internet, la cual es utilizada para distintos propósitos (mail, publicidad y difusión, procedimientos operacionales, consulta a servicios informativos, etc.). En resumen, hoy en día aproximadamente solo un tercio de las PYMES contaría con acceso a Internet. Por otro lado es de común conocimiento el gran espacio ganado por el sistema operativo Windows en el mercado nacional, y en general en todo el mundo occidental, y por otro lado la ignorancia general que existe acerca de Linux entre los profesionales informáticos, la cual solo recientemente se esta “atacando” gracias a una mayor difusión por los medios, su inclusión en los planes de estudios de algunos institutos y universidades , y la facilidad de acceso a información de primera mano disponible en el Web. Lo que nos lleva a una segunda conclusión: En el medio profesional nacional existiría actualmente una limitada cantidad de profesionales informáticos que sean capaces de asumir la puesta en marcha de un sistema com plejo como el tratado en este proyecto.

49

INACAP Apoquindo Ingeniería en Gestión Informática

Resumiendo se tienen los siguientes puntos generales, es decir, concernientes a todas las alternativas antes expuestas, por resolver desde el punto de vista operativo: •

Baja cantidad de empresas con conexión a Internet en la actualidad : La fuente de esta información es una encuesta realizada por el INE durante el primer semestre del año 2001. Por todos es sabido que la actividad económica nacional, y en general en toda la región ha estado bastante deprimida, lo que nos ha llevado durante los últimos años a crecer con tasas bastante menores que las que podrían esperarse de una economía sana como la chilena. De esto podemos realizar algunas conjeturas, entre otras la gran reserva que existiría por incorporar nuevas tecnologías como parte del proceso productivo y/o comercial al interior de las PYMES, por considerar talvez como gastos superfluos el hecho de contar con acceso a Internet.

Sin embargo, las que si lo poseen y utilizan esta tecnología de algún u otro modo en su línea operacional y/o comercial están adquiriendo una ventaja sobre las que no la poseen, y más aun podría llegar a significar un eslabón importante en la empresa cuando se masifique el uso de la facturación electrónica, y se privilegie la cotización y compra electrónica por sobre el tradicional esquema manejado hasta hoy.

Por consiguiente, se ve que en el futuro cercano, y si la condición económica futura lo permite, esta tecnología debiera pasar a ser una parte habitual en el manejo de una empresa. Considerando a su vez que la baja presencia de Internet en las PYMES es más de causa coyuntural que de fondo. •

Relativa escasez de profesionales informáticos que maneje adecuadamente los conocimientos requeridos

50

INACAP Apoquindo Ingeniería en Gestión Informática

Como se mencionaba con anterioridad, es por todos sabido el amplio dominio que mantiene el entorno Windows en el mercado nacional, sobre todo cuando nos enfocamos en el entorno de los PC de escritorio. Esto debido principalmente a la alta difusión que se le da durante los estudios en los distintos lugares donde se enseña alguna carrera relacionada con la informática. Sin embargo la notoriedad que ha alcanzado el entorno Linux en el mercado ha influido en el hecho de que algunas universidades e institutos en Chile comiencen a incluirlos en los planes de estudios de sus carreras relacionadas con el área. Lo que esta dando un nuevo impulso a la difusión de la plataforma en el área educativa, y a través de él se estaría dando un impulso también a la presencia de Linux en la empresa chilena. No puede menospreciarse por otro lado el esfuerzo y acciones concretas que están tomando grandes empresas por abrir nuevos espacios de negocio con base en este S.O., entre las más destacadas esta la millonaria inversión que esta realizando hoy en día IBM, empresa que esta apostando a que Linux ganará mucho más espacio en el mercado de las pc de escritorio y servidores de la clase Pentium. Por consiguiente, si bien es cierto que en la actualidad existe un porcentaje limitado de profesionales capacitados en el tema, es de esperar que en breve comiencen a egresar más y más alumnos con conocimientos formales en el entorno Linux. Enfocándonos en el proyecto en si se pueden distinguir los siguientes aspectos operacionales por atender: •

Contar con un espacio físico adecuado para ubicar y operar el sistema

51

INACAP Apoquindo Ingeniería en Gestión Informática

Este podría parecer un tema menor en una primera instancia, pero en realidad es

necesario

cumplir

con

una

importante

cantidad

de

requisitos

y

características cuando queremos aproximarnos a la idea de alta disponibilidad. Por consiguiente debemos considerar a lo menos los siguientes puntos:

o Una ubicación física definitiva. La idea principal de este punto es que debemos evitar al máximo estar trasladando el equipo entre distintas ubicaciones, ya que ello implica sacar de línea los servicios, con lo cual la empresa esta perdiendo dinero de manera indirecta. Además durante los traslados se expone al hardware a accidentes involuntarios. o Un emplazamiento seguro.

Quizá para una persona común cualquier lugar dentro de un edificio cerrado es un lugar adecuado para un equipo computacional. Sin embargo existen sutiles observaciones que el administrador debe hacer al respecto, entre otras: §

Nunca ubicar el sistema en un subterráneo ni en un ultimo piso dentro de un edificio. Esto orientado principalmente a evitar el riesgo de inundación (algo más habitual de lo deseado en ciudades como Santiago). En cuanto a evitar los últimos pisos en edificios se debe más

bien a que

estadísticamente los pisos superiores se ven más afectados o al menos con mayor exposición a daños causados por terremotos, fatiga de materiales, accidentes aéreos, etc. §

Evitar

espacios

húmedos

o

polvorientos.

Esto

es

principalmente porque los equipos computacionales están compuestos por placas de circuitos y dispositivos que de

52

INACAP Apoquindo Ingeniería en Gestión Informática

seguro fallarán si llegasen a condensar agua en su superficie, o llegaran a acumular tanto polvo en ciertas zonas, que este podría provocar un corto circuito, con lo que el sistema podría llegar a detenerse si esto sucediese por ejemplo en los equipos director es. §

No colocar el equipamiento cerca de fuentes magnéticas o que vibren. Las vibraciones o campos magnéticos intensos podrían causar daños importantes en ciertas piezas delicadas del equipamiento como CPU’s, módulos de memoria y otros.

§ •

Evitar la exposición directa al sol o cercana a fuentes de calor.

Contar con un administrador capaz de operar y administrar el sistema

La persona que tomará la administración del cluster debiera ser un profesional informático que cuente por lo menos con un título de analista de sistemas , debido a que el perfil de esta carrera esta orientado a asuntos operativos desde el punto de vista informático en la empresa, no así por ejemplo la carrera de programador, la cual se orienta principalmente a conocer la lógica, desarrollo y funcionamiento del software.

En cuanto a las tareas específicas que deberá atender podemos encontrar entre otras: §

Configurar los servicios que prestará el cluster.

Esto significa que deberá estudiar y conocer las posibles combinaciones en la configuración del sistema con el que se este trabajando, por ejemplo si trabaja con una solución basada en LVS deberá estudiar y conocer los parámetros requeridos en lvs.conf, mediante el cual se establecen las características de comportamiento del sistema, así como también los servicios que se implementan.

53

INACAP Apoquindo Ingeniería en Gestión Informática

§

Estudiar los componentes, sus funciones y comportamiento. Esto se debe principalmente a que en general los sistemas de cluster están compuestos por varias piezas de software, que por supuesto son susceptibles a fallas de distinta naturaleza, por lo que el administrador debiera tener claro “que hace que” dentro del esquema general del cluster para poder tomar con rapidez las medidas necesarias para atacar el problema en caso que este se presente.

Debemos tener en mente siempre que un cluster esta orientado a ofrecer un soporte para algún servicio que requiere estar siempre en funciones, por lo que las fallas podrían causar perdidas de consideración a la empresa, dependiendo esto de la naturaleza del servicio ofrecido, por lo que es importante que la persona a cargo sepa desenvolverse con celeridad para poder solucionar el problema y recuperar la puesta en funcionamiento del conjunto. §

Conocer las virtudes y limitaciones de la solución en cuestión.

Es importante que el administrador este conciente de que es lo que puede esperar del sistema cuando este en operaciones y que cosas no podrá realizar con el. Esto le ayudará a realizar una planeación coherente de mantenciones, actualizaciones, implementación de nuevos servicios, entre otras posibles actividades. A modo de conclusión en este punto es posible señalar que a pesar que se reconoce existe un bajo nivel de acceso en general a nuevas tecnologías en las PYMES, y una baja preparación formal con respecto al entorno Linux de profesionales informáticos, se ve que son problemas

que en breve debieran

evolucionar de manera positiva. Esto fundado en que los servicios públicos y

54

INACAP Apoquindo Ingeniería en Gestión Informática

privados en Chile se están en general modernizando, y adaptando a estas nuevas tecnologías, por lo que en un tiempo razonable todas las empresas que pretendan mantenerse en funciones deberán ir incorporando nuevas herramientas a sus procesos, facilitando así funciones vitales como lo son el comercio, el proceso de facturación y otros. Además la másificación de la tecnología dará sin lugar a duda a precios más bajos y sustentables en el tiempo a empresas que no cuentan con muchos recursos para invertir en tecnología.

Por otro lado los profesionales informáticos están cada día mejor preparados en cuanto al entorno Linux. Debido principalmente a la atención que están prestando universidades e institutos por atender los siempre cambiantes requerimientos de las empresas del país. Además se especificaron algunos puntos generales que debieran atenderse en orden de garantizar una operación fluida de los sistemas, como lo son el contar con un lugar físico adecuado, y contar con un operador de sistemas capacitado en el tema. 5.1.3 Solución Propuesta Teniendo siempre presente los objetivos específicos planteados al principio de este estudio, y todas las demás variables mencionadas y analizadas es que recomendamos como solución a la problemática planteada la alternativa LVS + Pulse + IPVS/Ipvs Admin + Nanny. Las principales razones que justificarían esta recomendación son: •

Bajos costos de implementación.

•

Facilidad de crecimiento.

•

Relativa simplicidad de implementación y administración.

55

INACAP Apoquindo Ingeniería en Gestión Informática

5.2

Beneficios de la Solución

Los beneficios que presentaría esta alternativa de solución se pueden enfocar desde distintos aspectos, entre los que destacan:

5.2.1 Económicos: El mercado ofrece una variada gama de alternativas que podrían satisfacer los requerimientos técnicos y operativos de la problemática planteada, sin embargo, el hecho de que la situación en estudio se de en una PYME, impone una gran cota que deja por fuera a la inmensa mayoría de soluciones existentes.

Desde esta perspectiva es que la elección recomendada destaca principalmente debido a su costo cero por licenciamiento de software, y el bajo requerimiento en costos de equipamiento que requiere para una implementación básica del mismo.

5.2.2 Operacionales: La implementación y operatividad de la solución es relativamente sencilla, ya que esta por entero basada en código abierto, lo que permitiría entre ot ros examinar el diseño del mismo, comprender su orientación y funcionamiento e incluso mejorar el rendimiento de las aplicaciones en general. Por otro lado existe una buena cantidad de información en línea de muchas de sus partes, lo que facilitaría el estudio de las mismas.

5.2.3 Crecimiento horizontal: Uno de los principales beneficios, sobre todo cuando la empresa ya comienza a crecer, y junto con ello, a aumentar también sus requerimientos, es la facilidad con 56

INACAP Apoquindo Ingeniería en Gestión Informática

la que la “potencia” del sistema puede aumentar, como se mencionara en los siguientes capítulos el crecimiento se hace conectando más servidores reales ( computadoras de escritorio comunes y corrientes con su interfaz de red apropiadamente configurada ). 5.3

Desarrollo Técnico.

5.3.1 Marco del Desarrollo. Este proyecto tiene como marco fundamental proveer una plataforma de alta disponibilidad de servicios a un bajo costo para la pequeña y mediana empresa (PYMES), con el fin de explotar sus aplicaciones comerciales criticas en el contento actual de la globalización, a través de sistemas de redes (Internet, Intranet, Extranet, etc.). Para ello se utilizará el hardware ya existente en la empresa, que por sus características técnicas individuales no permite cumplir con las demandas de procesamiento y servicios requeridos en la actualidad, para a atender grandes volúmenes de trabajo. Además se empleará software de licenciamiento gratuito (GNU) disponible en mercado actual, el cual puede ser adaptado para cumplir los requerimientos inherentes a esta solución.

Otra de las características fundamentales de este proyecto es permitir la escalabilidad horizontal, es decir que frente a una mayor carga de trabajo el sistema pueda crecer sin generar un gran impacto al nivel de costos.

5.3.2 Plan de proyecto. Para llevar a cabo este proyecto hemos establecido la siguiente planificación: •

Instalación y configuración servidor director.

57

INACAP Apoquindo Ingeniería en Gestión Informática

•

Instalación y configuración servidor real .

•

Configuración y puesta en marcha servidor virtual.

•

Instalación y configuración servidor director de respaldo.

•

Clonación de servidor real.

•

Realizar plan de pruebas

Nº 0 1. 1.1. 1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.2. 1.2.1. 1.2.2. 1.2.3. 1.2.3.1. 1.2.3.2. 1.2.3.3. 1.2.3.4. 1.2.3.6. 1.2.3.7. 1.2.3.8. 2. 2.1 2.1.1. 2.1.2. 2.2. 2.2.1. 2.2.2. 2.3. 2.3.1. 2.3.2. 2.3.3. 2.3.4. 3. 3.1.

Tarea Adquisición o recolección de Hardware Instalación y configuración Servidor Director Obtención del software. Sistema operativo. Código fuente Kernel 2.4.x Código fuente patch ipvs. LVS (Nanny, Pulse) Instalación y configuración del hardware. Instalación y configuración de dispositivos . (disco duro, tarjeta de video, tarjeta red, monitor) Configuración BIOS. Instalación y configuración del software. Sistema operativo Linux RedHat v 7.1 Compilación e instalación Kernel. Instalación y configuración del cliente de red: pública y privada. Instalación, configuración y aplicación de software ipvs. Instalación y configuración LVS. Pulse. Nanny. Instalación y configuración servidor real. Obtención del software. Servidor Web Apache 1.3.19. Servidor FTP. Instalación y configuración del hardware. Instalación y configuración de dispositivos. (disco duro, tarjeta de video, tarjeta red, monitor) Configuración BIOS. Instalación y configuración del Software. Sistema operativo Linux RedHat v 7.1 Instalación y configuración del cliente de red privada. Instalación y configuración servidor web. Instalación y configuración servidor FTP. Configuración y puesta en marcha servidor virtual. Configuración de DNS P rivado.

Tiempo 1 semana 12 hrs 5 hrs, 30 min. 4 hrs. 30 min. 30 min. 30 min. 6 hrs, 30 min. 30 min. 30 min. 5 hrs, 30 min. 1 hr 1 hr 30 min. 1 hr 1 hr 30 min. 30 min. 4 hrs, 30 min. 1 hora 30 min. 30 min. 1 hr 30 min. 30 min. 2 hrs, 30 min. 1 hr 30 min. 30 min. 30 min. 30 min. 10 min.

58

INACAP Apoquindo Ingeniería en Gestión Informática

3.2. 3.3. 3.4 4. 4.1. 4.1.1. 4.1.2. 4.1.3. 4.1.3.1. 4.1.3.2. 4.1.3.3. 4.1.3.4. 4.1.3.6. 4.1.3.7. 4.1.3.8. 5. 5.1. 5.1.1. 5.1.2. 5.2. 5.2.1. 5.2.2. 5.2.3. 5.2.4. 6 6.1 6.1.1 6.1.2 6.1.3 6.2 6.2.1 6.2.1 6.2.1 6.2.1 6.2.1

Configuración de Puerta de Enlace Red Privada Configuración SSH. Uptime Instalación y configuración Servidor Director de Respaldo. Instalación y configuración del hardware. Instalación y configuración de dispositivos . (HD, tarjeta de video, tarjeta red, monitor) Configuración de la BIOS. Instalación y configuración del software. Sistema operativo Linux RedHat v 7.2 Compilación e instalación Kernel. Instalación y configuración red: pública y privada. Instalación, configuración y aplicación de software IPVS. Instalación y configuración LVS software. Pulse. Nanny. Clonación de servidor real. Instalación y configuración del hardware. Instalación y configuración de dispositivos. Configuración de la BIOS. Instalación y configuración del Software. Sistema operativo Linux RedHat v 7.1 Instalación y configuración del cliente de red privada. Instalación y configuración servidor web. Instalación y configuración servidor FTP. Realizar Plan de Pruebas Pruebas de Sistema Pruebas de Servicios. Pruebas de Conectividad. Pruebas de Alta Disponibilidad Pruebas de Aceptación Conectividad servidor virtual . Servicio ‘http’ servidor virtual. Servicio ‘FTP’ servidor virtual. Alta Disponibilidad. Crecimiento Horizontal.

10 min. 10 min. 5 min 12 hrs 6 hrs., 30 min. 30 min. 30 min. 5 hrs., 30 min. 1 hr 1 hr 30 min. 1 hr 1 hr 30 min. 30 min. 2 hrs., 30 min. 1 hr. 30 min. 30 min. 1 hr., 30 min. 1 hr 10 min. 10 min. 10 min. 6 hrs,29 min 3 hrs, 14 min 10 min 33 min 2 hrs.,31 min 185 min 10 min 10 min 10 min 5 min 2 hrs.,30 min

Tabla 7: plan de proyecto17

17 Ver Carta Gantt del Proyecto en el capítulo de anexos. 59

INACAP Apoquindo Ingeniería en Gestión Informática

5.4

Análisis.

5.4.1 Modelo Conceptual

Ilustración 8: modelo conceptual El servidor virtual es un cluster de servidores los cuales aparecen como un solo servidor frente a sus clientes. Los Servidores Reales (o nodos reales) están bajo el control del Servidor Director (nodo Director o balanceador de carga), el cual ejecuta un Kernel (Linux) modificado que incluye el código que implementa el cluster. El servidor Director de respaldo actúa como respaldo del nodo Director principal, frente a una falla de este.

60

INACAP Apoquindo Ingeniería en Gestión Informática

El servidor virtual presenta una dirección IP a los clientes, llamada VIP o IP virtual. Cuando un cliente se conecta a la VIP, el servidor Director redirecciona los paquetes recibidos desde el cliente a uno de los servidores reales para ser procesados. La conexión es manejada por el servidor director. Los nodos reales atienden los servicios (FTP, HTTP, DNS, TELNET, SSH, NNTP, SMTP, POP, etc.) configurados y disponibles. La VIP que es atendida desde el servidor director pasará al servidor director de respaldo si una falla es detectada. El director puede estar asociado a uno o más servicios, los cuales requieren balanceo de carga debido a su alta demanda. Cuando un usuario accede a los servicios provistos por el servidor virtual, este examina la dirección y puerto de destino del paquete de solicitud, si este calza con una regla establecida, un servidor real es elegido a través de un algoritmo de agenda para atender la petición, entonces la dirección y el puerto de destino son reescritos con la IP y el puerto del nodo real elegido. Cuando un paquete de respuesta viene de regreso desde el nodo real hacia el servidor director, se realiza la operación inversa a la antes descrita, es decir, se reescribe la dirección de origen por la del servidor Director.

El hardware al cual se hace mención correspondería a máquinas de características simples, que a menudo podemos encontrar en los inventarios de las PYMES, equipos tales como un Pentium 133 Mhz, 64 Mb de RAM, disco duro 5 Gb.

61

INACAP Apoquindo Ingeniería en Gestión Informática

5.4.2 Diagrama de Interacción. Cuando un usuario acceda los servicios brindados por el servidor virtual, el paquete de petición (request packet) con destino a la IP del servidor virtual ( la dirección pública), al arribar esta al servidor, examina la dirección y el número de puerto de destino. Si estos coinciden con uno de los servicios establecidos en la tabla de reglas del servidor Director, un servidor real es elegido desde el cluster por un algoritmo de gestión (scheduling). Entonces la dirección y puerto de destino del paquete de petición son sobrescritos y reenviados al servidor elegido para ser procesados.

Cuando un paquete de respuesta a una petición es recibido por el servidor Director desde un servidor real , este sobrescribe la dirección y número de puerto de origen con las del servidor virtual (VIP). Después de que las conexiones terminan o exceden el tiempo de espera, estas serán removidas del registro del servidor Director.

Además en el servidor Director y el servidor Director respaldo ejecutan continuamente un proceso (nanny) que envía mensajes a su homologo informando de su estado, a través de una conexión serial o mediante la red privada. En caso de que el servidor Director activo (que posee la dirección IP pública, VIP) sufra una falla, su semejante asume el rol de servidor director, es decir, toma como propia la dirección IP y la activa, permitiendo la continuidad y disponibilidad de los servicios provistos.

62

INACAP Apoquindo Ingeniería en Gestión Informática

Internet / Intranet origen: 192.168.0.5:3456 |

destino: 10.0.1.1

cliente

origen: 10.0.1.1:80 | destino: 192.168.0.5:3456

Flujo de Request y Respuesta = Request Cliente

Servidor Virtual

= Request Servidor Director = Respuesta Servidor Real VIP :10.0.1.1 DIP:192.168.1.1

Servidor Director

origen: 192.168.1.10:8000 |

= Respuesta Servidor Director

coneccion serial

Servidor Director Respaldo

destino: 192.168.1.1:80 Red Privada ethernet 10/100 Mbps 192.168.1.x origen: 192.168.1.1:80 | destino: 192.168.1.10:8000

Servidor Real 1 RIP:192.168.1.10

Nomenclatura Redes

Servidor Real 2 RIP:192.168.1.11

Servidor Real 3

Tolerancia a Fallas = Estado de Servidor Director = Consultas de Estado Servidor Director

VIP = IP Servidor Virtual (Red Publica) DIP = IP Servidor Director (Red Privada) RIP = IP Servidor Real (Red Privada)

Ilustración 9: diagrama de interacción.

63

INACAP Apoquindo Ingeniería en Gestión Informática

5.4.3 Flujograma de paquetes de petición y respuesta

Flujo grama de paquetes de peticion y respuesta Cliente

Servidor Director

Servidor Real

(CLI)

(SD)

(SR)

Inicio

Generar petición

examinar ip y puerto de destino del paquete de petición

elegir servidor real de destino

sobreescribir ip y puerto de destino con ip y puerto de servidor real elegido

reenviar solcitud modificada a SR

Procesar paquete de petición

Examinar paquete de respuesta recibido desde el servidor real

Enviar paquete de respuesta al servidor director

sobreescribir ip y puerto de destino del paquete de respuesta con su ip y puerto

Ilustración 10: flujograma de paquetes de petición y respuesta

64

INACAP Apoquindo Ingeniería en Gestión Informática

5.4.4 Especificación de Requerimientos. •

Proveer una implementación de cluster de comunicaciónes

de alta

disponibilidad tolerante a fallas. •

Que soporte múltiples plataformas .

•

Que soporte múltiples sistemas operativos.

•

Que soporte múltiples aplicaciones de servicios.

•

Permitir crecimiento y decrecimiento según la demanda de servicios

•

Utilizar hardware de bajo costo.

•

Diseñar una solución orientada a las PYMES, que les permita implementar servicio de comercio electrónico o potenciar la instalación actual.

•

Establecer los requerimientos mínimos de Hardware para implementar esta solución.

•

Establecer los requerimientos mínimos de Software para implementar esta solución.

•

Construir un cluster de alta disponibilidad, como modelo de prueba.

•

Establecer métricas y limitaciones de esta solución.

•

Implementar mejoras en las componentes actualmente disponibles.

•

Documentar la implementación de esta solución.

5.4.5 Especificación de Requisitos. Los requisitos para implementar este proyecto se dividen en tres grandes grupos: •

Hardware.

•

Software.

•

Competencia Técnica.

65

INACAP Apoquindo Ingeniería en Gestión Informática

5.4.5.1

Hardware.

El hardware mínimo requerido para la implementación de un cluster de alta disponibilidad, con la plataforma Linux, corresponde al necesario para el armado de cinco máquinas: •

1 Servidor Director,

•

1 Servidor Director de Respaldo y

•

3 Servidores Reales.

A continuación se detalla el hardware: Hardware Fuente de Poder 220 volts, 250W, 2 amperes. Genérica. Cable de Poder 220 volts. Tarjeta Madre, INTEL. Procesador Pentium 166 Mhz. , INTEL Memori a RAM 128 Megabytes, Genérica Memoria RAM 64 Megabytes, Genérica Tarjeta de Video 1 Megabyte, TRIDENT Disco Duro 2,5 Gigabytes ATA100 Disco Duro 5 Gigabytes ATA100 Tarjeta de Red 10/100 base T, PCI, 3com 3c509b Cable Red Ethernet UTP Categoría 5. SWITCH Ethernet 10/100 Base T, 16 bocas Unidad Lectora CDROM 24x. Monitor 14” SVGA. Teclado PS2 Genérico 102 Teclas Rack Aluminio 19” Adaptador 5 Enchufes

Cantidad 5 6 5 5 2 3 2 3 2 7 7 2 1 1 2 1 2

Tabla 8: requisitos de hardware

66

INACAP Apoquindo Ingeniería en Gestión Informática

Las partes y piezas antes mencionadas permiten la configuración física de las siguientes máquinas: Máquina

Características Cantidad Pentium 166 Mhz, 128 Megabytes RAM Tarjeta de Video 1 Megabyte RAM Servidor Director Disco Duro 5 Gigabytes. 2 - 2 Tarjetas de Red 10/100 Base T, PCI, 3com 3c509b Pentium 166 Mhz, 64 Megabytes RAM Tarjeta de Video 1 Megabyte RAM Servidor Real Disco Duro 2,5 Gigabytes. 3 - 1 Tarjeta de Red 10/100 Base T, PCI, 3com 3c509b Tabla 9: características máquinas.

5.4.5.2

Software.

El software utilizado en el proyecto es de licenciamiento gratuito, el cual puede ser obtenido en Internet. Sistema Operativo Linux, distribución REDHAT v.7.1., Esta versión esta disponible en la sección de descargas del sitio de RedHat Inc. (www.redhat.com).

Kernel 2.4.x La Versión más reciente de este Kernel esta disponible en el servidor FTP de Kernel.org (FTP.kernel.org).

67

INACAP Apoquindo Ingeniería en Gestión Informática

ipvs Es el código que parcha el Kernel de Linux, que permite que el Director se convierta en un enrutador con reglas modificables de enrutamiento. Existen 2 versiones de este parche, cada una dependiente de la versión del Kernel a utilizar, en este caso su utiliza la versión para el Kernel 2.4.x

disponible en :

http://www.linuxvirtualserver.org/software/kernel-2.4/ ipvsadm Es la herramienta que utiliza el servidor Director para actualizar las tablas de enrutamiento del Kernel. Disponible en: http://www.linuxvirtualserver.org/software/kernel-2.4/ lvs Demonio que se ejecuta en el servidor Director , que se encarga de mantener actualizada la tabla de enrutamiento de IPVS. Esta disponible en sección de software del proyecto Linux Virtual Server: http://www.linuxvirtualserver.org/software/ Nanny Demonio que se ejecuta en el servidor Director, a través del cual el balanceador determina el estado de cada servidor real y su carga de trabajo. Disponible en la sección de software del proyecto de Alta Disponibilidad de RedHat Inc.: FTP://ha.redhat.com/pub/ha/ lvs.cf Este es el archivo de configuración del servidor virtual. Indirecta o directamente todos los demonios consiguen su configuración desde este archivo. Se encuentra disponible en la sección de software del proyecto Linux Virtual Server: http://www.linuxvirtualserver.org/software/

68

INACAP Apoquindo Ingeniería en Gestión Informática

pulse Este es una aplicación que permite iniciar la ejecución de los otros demonios del servidor virtual, normalmente esta es ejecutada al iniciar el sistema operativo (/etc/rc.d/init.d/pulse), además implementa un hearbeat simple, que permite que el servidor Director inactivo (respaldo) determinar el estado del Director activo e iniciar el traspaso por falla (failover) en el momento indicado. Esta aplicación esta disponible en el área de descarga del proyecto Alta Disponibilidad de RedHat Inc.: FTP://ha.redhat.com/pub/ha/ SSH Aplicación que permite conectarse remotamente a otro máquina sobre la red, para ejecutar comandos, copiar y mover archivos desde una máquina a otra. Esta aplicación provee una excelente

autentificación

y

seguridad

en

la

comunicación sobre canales inseguros. Por razones legales debe utilizarse la versión gratuita llamada openssh, disponible en: http://www.openssh.com/portable.html uptime Aplicación que permite determinar la carga de trabajo de una máquina, esta se encuentra disponible en la distribución de RedHat 7.x. IP Forwarding Activar esta característica en la configuración del Kernel (núcleo). Esta permite el envío de paquetes tcp entre las interfaces de red de una misma máquina, permitiendo el enrutamiento de paquetes desde la red privada hacia la red pública y viceversa.

69

INACAP Apoquindo Ingeniería en Gestión Informática

IP Defragmenting

Activar esta característica en la configuración del Kernel. De esta forma los paquetes tcp serán agrupados para ser analizados y así determinar claramente el origen y destino de estos.

5.4.5.3

Competencia Técnica

Para la implementación de este proyecto es necesario contar con capacidad técnica en los siguientes tópicos: Tópico Ensamblado y configuración de computadoras. Instalación y configuración de sistema operativo Linux RedHat 7.1 Instalación y configuración de dispositivos de redes ethernet. Instalación y configuración de servicios (HTTP, FTP, DNS.) Teoría de redes de área local. Administración y mantención de sistema operativo. Tabla 10: competencia técnica.

5.4.6 •

Restricciones Técnicas y Funcionales.

Kernel 2.4.

Este Kernel permite obtener un mejor rendimiento al usar traducción de direcciones y puertos de red (NAT), debido a que fue optimizado para realizar esta función. Además esta versión incluye soporte para máquinas multiprocesadores (SMP) lo que aumenta las posibilidades de escalamiento del sistema, permitiendo soportar 2 veces el trafico que soporta una máquina con un Kernel 2.2.x, el cual no posee soporte para máquinas con más de 1 procesador.

70

INACAP Apoquindo Ingeniería en Gestión Informática

•

Servidor Director Real y Servidores Reales en Red Interna.

Por razones de seguridad es conveniente que el servidor Director y los servidores reales pertenezcan a una red privada, restringiendo así el acceso a estos desde Internet. Además permite maximizar el rendimiento de la red privada pues solo se limita al tráfico interno del servidor virtual. •

Número de Tarjetas de Red.

Si el servidor Director cuenta con 2 tarjetas de red, una para la red pública y otra para la privada, se incrementará el volumen de trafico, tan grande como lo permita la velocidad del procesador o del bus pci de la máquina. •

Máximo 22 servidores reales al usar NAT. La desventaja de usar traducción de direcciones y puertos de red (NAT) es que, esta limita la escalabilidad de servidor virtual a un máximo de 22 servidores reales. Debido a que se produce un cuello de botella en el balanceador (servidor Director) pues debe reescribir los paquetes de petición y respuesta de cada uno de los servidores reales. Suponiendo que el largo de un paquete TCP es de 536 bytes y la demora promedio en reescribir un paquete es de 60 microsegundos, el tráfico máximo de carga que puede soportar el balanceador es de 8.93 Megabytes/Segundo. Asumiendo que el promedio de tráfico de los servidores reales es de 400 Kilobytes/Segundo, el servidor Director puede gestionar un promedio de 22 servidores reales.

•

Mínimo 4 máquinas.

Para implementar con éxito un sistema de alta disponibilidad es necesario que existan dos máquinas de igual configuración de hardware y software para cumplir las funciones de Director y Director de Respaldo, los cuales frente a

71

INACAP Apoquindo Ingeniería en Gestión Informática

una falla o inestabilidad del sistema, en forma automáticamente intercambian roles para asegurar la continuidad y disponibilidad de los servicios prestados. Además para realizar balanceo de carga se requiere al menos 3 máquinas, una de ellas (Director o balanceador) encargada de distribuir el trabajo equitativamente

a las otras dos, las cuales atenderán las peticiones de

procesamiento y servicios solicitados, permitiendo aumentar la cantidad de usuarios concurrentes soportados por el sistema. •

Uso de SWITCH y Tarjetas de Red de 100 Megabytes.

Para disponer del máximo ancho de banda posible, es necesario implementar ambas redes usando SWITCH’s , debido a que estos dispositivos de red permiten que cada uno de los dispositivos conectados a este dispongan de un ancho de banda de 100 megabytes, por lo anterior también se requiere que las tarjetas de red soporten la misma capacidad.

72

INACAP Apoquindo Ingeniería en Gestión Informática

5.5

Diseño. Switch 10/100 Cable red

Cable red

Eth0:10.0.1.1 (VIP)

Eth0:10.0.1.1 (VIP) Cable serial

Switch monitor Eth1 :192.168.1.1 (DIP)

t.video

Eth1:192.168.1.1 (DIP)

t.video

Servidor Director

Servidor Director Respaldo

Cable red

Cable red

Cable switch monitor

Switch 10/100

Cable red

Eth0:192.168.1.10 (RIP) GW:192.168.1.1

Servidor Real 1

Cable red

Cable red

Eth0:192.168.1.11 (RIP) GW:192.168.1.1

Servidor Real 2

Eth0:192.168.1.12 (RIP) GW:192.168.1.1

Servidor Real 3

Ilustración11: diseño

73

INACAP Apoquindo Ingeniería en Gestión Informática

5.5.1 Diseño Red servidor virtual

5.5.1.1

Red Pública

La configuración de la red públic a corresponde a la red en la cual esta conectado el servidor virtual para ser accesado por sus clientes, pudiendo ser Intranet o Internet.

Protocolo de red privada Direcciones IP Red Privada Máscara de red privada (net másk) Dirección IP enrutador (router) Dirección de Difusión (broadcast) Topología de red Dispositivo de Red Tarjetas de Red

TCP/IP 10.0.1.0/24 255.255.255.0 10.0.1.5 10.0.1.255 Ethernet 100 Base T Switch 100 Base T 10/100 Base T, bus pci

Tabla 11: parámetros de configuración red pública Cabe mencionar que ambos servidores (Director y respaldo) se conectaran a la red publica a través de su interfase de red n° 1 (eth0) con la misma dirección IP, pero sólo uno de ellos levantara el servicio. Al momento de producirse una falla en el servidor Director,

el

monitor

de

fallas

(pulse)

bajará

este

servicio,

desconectándolo de la red publica, una vez producido esto, procederá a subir la interface de red del servidor Director de respaldo, el cual reemplazará en sus funciones al servidor en falla, además de recibir todas las conexiones que se encuentren activas.

74

INACAP Apoquindo Ingeniería en Gestión Informática

Red Pública Switch 10/100 Cable red

Cable red

Eth0:10.0.0.1 (VIP)

Eth0:10.0.0.1 (VIP)

Servidor

Servidor

Ilustración 12: diseño red pública 5.5.1.2

Red Privada

El servidor Director, servidor Director de respaldo y los servidores reales, se conectaran a través de la red privada. El Director y su respaldo se conectan a esta red a través de su interfase de red n° 2, los servidores reales a través de su interfase de red n° 1. Protocolo de red privada Direcciones IP Red Privada Máscara de red privada Puerta de enlace red privada Broadcast Topología de red Dispositivo de Red Tarjetas de Red

TCP/IP 192.168.1.1/24 255.255.255.0 192.168.1.1 192.168.1.255 Ethernet 100 Base T Switch 100 Base T 10/100 Base T, bus pci

Tabla 12: parámetros configuración red privada

75

INACAP Apoquindo Ingeniería en Gestión Informática

Red Privada

Eth1:192.168.1.1 (DIP)

Eth1:192.168.1.1 (DIP)

Servidor Director

Servidor Director Respaldo

Cable red

Cable red

Switch 10/100

Cable red

Eth0:192.168.1.10 (RIP) GW:192.168.1.1

Servidor Real 1

Cable red

Cable red

Eth0:192.168.1.11 (RIP) GW:192.168.1.1

Servidor Real 2

Eth0:192.168.1.12 (RIP) GW:192.168.1.1

Servidor Real 3

Ilustración 13: diseño red privada

5.5.1.3

Direcciones IP asignadas en la red privada Máquina Director Director respaldo real1 real2 real3

Dispositivo ( ethX ) eth1 eth1 eth0 eth0 eth0

Dirección IP 192.168.1.1 192.168.1.1 192.168.1.10 192.168.1.11 192.168.1.12

Tabla 13: direcciones IP red privada.

76

INACAP Apoquindo Ingeniería en Gestión Informática

5.5.2 Servidor Director Nombre Máquina Protocolo de red publica Dirección IP red pública, tarjeta Red # 1 (eth0) Máscara de red pública Puerta de enlace red pública Protocolo de red privada Dirección IP Red Privada, IP Tarjeta Red # 2 (eth1) Máscara de red privada Sistema Operativo Software

Director TCP/IP 10.0.1.1 255.255.255.0 10.0.1.5 TCP/IP 192.168.1.1 255.255.255.0 RedHat 7.1, Kernel 2.4.12 ipvs-2.7-2.4.2 ipvsadmin lvs pulse nanny

Tabla 14: parámetros configuración red servidor director 5.5.3 Servidor Director Respaldo Nombre Máquina Protocolo de red publica Dirección IP red pública, tarjeta Red # 1 (eth0) Máscara de red pública Puerta de enlace red pública Protocolo de red privada Dirección IP Red Privada, IP Tarjeta Red # 2 (eth1) Máscara de red privada Sistema Operativo Software

Director TCP/IP 192.168.0.1 255.255.255.0 TCP/IP 192.168.1.1 255.255.255.0 RedHat 7.1, Kernel 2.4.12 ipvs-2.7-2.4.2 ipvsadmin lvs pulse nanny

Tabla 15: parámetros configuración red servidor director respaldo

77

INACAP Apoquindo Ingeniería en Gestión Informática

5.5.4 Servidor Real 1 Nombre Máquina Protocolo de red privada Dirección IP Red Privada, IP Tarjeta Red # 1 (eth0) Máscara de red privada Puerta de enlace red privada Sistema Operativo Servidor web Servidor FTP

real1 TCP/IP 192.168.1.10 255.255.255.0 192.168.1.1 RedHat 7.1, Kernel 2.4.12 Apache 1.3.x W U-FTP

Tabla 16: parámetros configuración red servidor real 1 5.5.5 Servidor Real 2 Nombre Máquina Protocolo de red privada Dirección IP Red Privada, IP Tarjeta Red # 1 (eth0) Máscara de red privada Puerta de enlace red privada Sistema Operativo Servidor web Servidor FTP

real2 TCP/IP 192.168.1.11 255.255.255.0 192.168.1.1 RedHat 7.1, Kernel 2.4.12 Apache 1.3.x W U-FTP

Tabla 17: parámetros configuración red servidor real 2 5.5.6 Servidor Real 3 Nombre Máquina Protocolo de red privada Dirección IP Red Privada, IP Tarjeta Red # 1 (eth0) Máscara de red privada Puerta de enlace red privada Sistema Operativo Servidor web Servidor FTP

Real3 TCP/IP 192.168.1.12 255.255.255.0 192.168.1.1 RedHat 7.1, Kernel 2.4.12 Apache 1.3.x W U-FTP

Tabla 18: parámetros configuración red servidor real 4

78

INACAP Apoquindo Ingeniería en Gestión Informática

5.5.7 Servidor virtual La tabla siguiente detalla los parámetros requeridos para la configuración del servidor virtual. Estos parámetros deben ser incluidos en el archivo /etc/lvs.cf de cada máquina según corresponda: 5.5.7.1

Configuración Parámetros Globales

Parámetro

Valor

Descripción

Configuración Parámetros Globales primary = 10.0.1.1

Dirección IP Servidor Director.

backup =

10.0.1.2

Dirección IP Servidor Director de Respaldo

heartbeat_port =

1050

Puerto usado por el hearbeat en Director y respaldo.

keepalive =

2

Número de Segundo entre hearbeats.

deadtime =

10

Número de Segundos de espera, antes de iniciar el traspaso por falla (failover).

rsh_command = network =

ssh nat

nat_router =

192.168.1.254 eth1:1

el servidor

Comando para sincronizar los servidores directores Dirección IP flotante y dispositivo para NAT. Usada como ruta por defecto para que los servidores reales se comuniquen con el Director (o balanceador).

Tabla 19: configuración parámetros globales

79

INACAP Apoquindo Ingeniería en Gestión Informática

5.5.7.2

Configuración servidor virtual

Parámetro

Valor

Descripción

Name

servidorvirtual

Nombre único de servidor virtual

address =

10.0.1.5

Dirección IP pública servidor virtual (VIP)

active = [0|1]

1

Estado del servidor virtual: 1 (Activo) y 0 (inactivo)

load_monitor =

uptime

Aplicación usada para determinar la carga de trabajo de las máquina.

timeout =

10

reentry =

180

port = [http/80|FTP/21] scheduler =

Número de Seg. a esperar antes de sacar un servidor real de la tabla de enrutamiento del Kernel. 10 seg. por defecto Número de seg. que debe estar disponible un s. real antes de ser reincorporado a la tabla de enrutamiento del Kernel. 180 seg. por defecto. Puertos o servicios que esta escuchando el servidor virtual. Algoritmo de gestión de trabajos

[80|21] wlc

Tabla 20: configuración servidor virtual

5.5.7.3

Configuración por cada servidor real

Real 1 Parámetro name= address = active = [0|1] weight =

Valor real1

Descripción Nombre de la máquina.

192.168.1.1

Dirección IP del servidor real en la red privada

1

Estado del servidor real: 1 (Activo) y 0 (inactivo)

1000

Ponderador basado en la capacidad y en la carga de la máquina.

Tabla 21: configuración servidor real 1

80

INACAP Apoquindo Ingeniería en Gestión Informática

Real 2 Parám etro name= address = active = [0|1] weight =

Valor real2

Descripción Nombre de la máquina.

192.168.1.2

Dirección IP del servidor real en la red privada

1

Estado del servidor real: 1 (Activo) y 0 (inactivo)

1000

Ponderador basado en la capacidad y en la carga de la máquina.

Tabla 22: configuración servidor real 2 Real 3 Parámetro name= address = active = [0|1] weight =

Valor real3

Descripción Nombre de la máquina.

192.168.1.3

Dirección IP del servidor real en la red privada

1

Estado del servidor real: 1 (Activo) y 0 (inactivo) Ponderador basado en la capacidad y en la carga de la máquina.

1000

Tabla 23: configuración servidor real 3

81

INACAP Apoquindo Ingeniería en Gestión Informática

6. Instalación y Configuración servidor virtual.

6.1

Servidor Director.

6.1.1 Sistema Operativo Instalar el Sistema operativo Linux, distribución RedHat 7.1 con los siguientes paquetes: • • • • • • • • •

X Window System KDE o GNOME Networked Workstation IP Tables Anonymous FTP Development Kernel Development Utilities Piranha Cluster.

Para detalles acerca de la instalación, consultar la guía de instalación disponible en el sitio Web de RedHat, en la sección de documentación: http://www.redhat.com/support/resources/howto/rhl71. html

6.1.2 Red Pública: Para configurar la red Pública se debe contactar al administrador de la red y preguntar por la siguiente información: • • • • • •

Dirección IP asignada al servidor virtual. Dirección IP de la red (Red) Dirección IP de difusión (broadcast) Máscara de red (netmás k) Dirección IP de la puerta de enlace (gateway) Dirección IP del Servidor de Nombre de Dominio (DNS)

82

INACAP Apoquindo Ingeniería en Gestión Informática

Para Configurar la interfase: Editar el archivo de configuración de la Internase de red eth0: /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static BROADCAST= 18 IPADDR= NETMÁSK= NETWORK= ONBOOT=yes

2) Editar el archivo de configuración de la red. /etc/sysconfig/network NE TWORKING=yes HOSTNAME=Director GATEWAY=

3) Levantar el servicio de red Bash$ /etc/init.d/network start

4) Comprobar que la interface esté activa. Bash$ /sbin/ifconfig Eth0 Link encap:Ethernet Hwaddr 00:03:47:A5:ED:C4 inet addr:10.0.1.1 Bcast:10.0.1.255 Másk:255.255.255.0 .. .. = Ver parámetros en tabla 14

18 Importante: Los parámetros entre signos ‘’ deben ser reemplazados por los datos especificados según tablas indicadas.

83

INACAP Apoquindo Ingeniería en Gestión Informática

6.1.3 Red Privada: Para configurar la red privada debe realizarse la siguiente secuencia de comandos como súper usuario (root). Editar el archivo de configuración de la Interfaz de red ethX: /etc/sysconfig/network-scripts/ifcfg-ethX

DEVICE=ethX BOOTPROTO=static BROADCAST=192.168.1.255 IPADDR= NETMÁSK=255.255.255.0 NETWORK=192.168.1.0 ONBOOT=yes

2) Editar el archivo de configurac ión de la red. /etc/sysconfig/network

NETWORKING=yes HOSTNAME= GATEWAY= 192.168.1.1

3) Levantar el servicio de red Bash$ /etc/init.d/network start

4) Comprobar que la interfaz esté activa. Bash$ /sbin/ifconfig EthX Link encap:Ethernet Hwaddr 00:03:47:A5:ED:C4 .. .. = Ver parámetros en tabla 14

Además puede usar las herramientas ‘netconf’ y ‘linuxconf’ que están disponibles en la distribución de Linux RedHat 7.1, estas permiten configurar más de una

84

INACAP Apoquindo Ingeniería en Gestión Informática

interfaz a la vez. Para más referencias del uso de estas aplicaciones, consultar la Guía el Administrador de RedHat (http://www.redhat.com/docs/) o los manuales incluidos en cada distribución: ( man netconf o man Linuxconf ). 6.1.4 Configurar IP forwarding e IP defragmenting Habilitar IP forwarding e IP defragmenting , agregando la siguiente línea al archivo de configuración de red: /etc/sysconfig/network: FORWARD_IPV4=yes DEFRAG_IPV4=yes

Reiniciar el servicio de red: Bash$ /etc/init.d/network restart

6.1.5 Configurar servicio SSH Configurar autenticación basada en llaves RSA (RSA-based authentication) usando el archivo

/root/.ssh/authorized_keys y reiniciar el servicio. Esta

configuración debe ser realizada en cada una de las máquinas del cluster.

Para más detalles acerca de este método de autenticación consultar

la

documentación disponible: man ssh.

85

INACAP Apoquindo Ingeniería en Gestión Informática

6.2

Servidores Reales

6.2.1 Sistema Operativo Instalar el Sistema operativo Linux, distribución RedHat 7.1 con los siguientes paquetes: • • • • • • •

Networked Workstation Anonymous FTP Development Kernel Development Utilities Web Server Apache FTP Server WU-FTP

6.2.2 Red Privada: Para configurar la red privada debe realizarse la siguiente secuencia de comandos como súper usuario (root). Editar el archivo de configuración de la Interfaz de red ethX, donde X corresponde al número de interfaz de red que esta configurando, ejemplo: eth0, eth1, etc. /etc/sysconfig/network-scripts/ifcfg-ethX DEVICE=ethX BOOTPROTO=static BROADCAST=192.168.1.255 IPADDR= NETMÁSK=255.255.255.0 NETWORK=192.168.1.0 ONBOOT=yes

2) Editar el archivo de configuración de la red. /etc/sysconfig/network NETWORKING=yes HOSTNAME= GATEWAY= 192.168.1.1

86

INACAP Apoquindo Ingeniería en Gestión Informática

3) Levantar el servicio de red Bash$ /etc/init.d/network start

4) Comprobar que la interfaz esté activa. Bash$ /sbin/ifconfig EthX Link encap:Ethernet Hwaddr 00:03:47:A5:ED:C4 .. ..

= Ver parámetros en tabla 16,17 y 18

6.3

Servidor Director Respaldo

Debido a que este servidor actúa como respaldo del servidor Director, deben realizarse las mismas configuraciones que en este. Parámetros especificados en tabla 15.

6.4 Servidor virtual Una vez instalados los servidores directores y servidores reales, configurar el archivo /etc/lvs.cf. # Global section primary = 10.0.1.1 backup = 10.0.1.2 keepalive = 2 deadtime = 10 heartbeat_port = 1050 rsh_command = ssh network = nat nat_router = 192.168.1.254 eth1:1 # Seccion para servidor virtual virtual server servidorvirtual { address = 10.0.1.5 active = 1 load_monitor = uptime

87

INACAP Apoquindo Ingeniería en Gestión Informática timeout = 10 reentry = 180 port = 80,21 scheduler = wlc # Seccion para cada servidor real server real1 { address = 192.168.1.10 active = 1 weight = 2000 } server real2 { address = 192.168.1.11 active = 1 weight = 1000 } server real3 { address = 192.168.1.12 active = 1 weight = 1000 } }

Una vez realizada la instalación y configuración de cada uno de los componentes del servidor virtual, iniciarse el demonio pulse en cada servidor Director:

/etc/rc.d/init.d/pulse start

88

INACAP Apoquindo Ingeniería en Gestión Informática

7. Plan de Pruebas.

7.1

Pruebas de Sistema.

N°

Pruebas

Duración

Responsable

1. 1.1. 1.2.

Pruebas de Servicios. Petición de servicio ‘http’ servidor virtual. Petición de servicio ‘FTP’ servidor virtual.

10 minutos 5 minutos 5 minutos

Adm.Sistema Adm.Sistema Adm.Sistema

2. 2.1.

33 minutos 15 minutos

Adm.Sistema Adm.Sistema

10 minutos

Adm.Sistema

2.3. 2.4. 2.5. 2.6.

Pruebas de Conectividad. Verificación Ping a IP de máquinas del cluster. (VIP,SGW,DIP,RIP) Verificación de resolución de nombres de servidor virtual.(nslookup) Verificación conexión servicio ‘telnet’. Verificación conexión servicio ssh. Verificación de servicio ‘http’ servidores reales. Verificación de servicio ‘FTP’ servidores virtuales.

2 minutos 2 minutos 2 minutos 2 minutos

3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 3.10. 3.11.

Pruebas de Alta Disponibilidad. Desconexión de servidor Director Desconexión de servidor Director respaldo Desconexión de servidor real Apagado de servidor Director Apagado de servidor Director respaldo Apagado de servidor real Desconexión de suministro eléctrico servidor Director Desconexión de suministro eléctrico servidor Director respaldo Desconexión de suministro eléctrico servidor real Desconexión general de suministro eléctrico Pruebas de concurrencia

Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema Adm.Sistema

2.2.

151 minutos 5 minutos 5 minutos 3 minutos 10 minutos 10 minutos 8 minutos 25 minutos 25 minutos 15 minutos 45 minutos 30 minutos

Tabla 24: pruebas de sistema

89

INACAP Apoquindo Ingeniería en Gestión Informática

7.1.1 Detalle de Pruebas.

7.1.1.1

Pruebas de Servicios.

Petición de servicio ‘http’ servidor virtual.

Http Resultado

Posibles Errores

El usuario deberá escribir en el browser la siguiente dirección http://127.0.0.1, esto a su vez genera una solicitud de servicios Como resultado de esta prueba el servidor virtual desplegara la página que esta configurada en el servidor HTTP (Ejemplo:index.html, default.html, home.html) Servidor Web no responde frente a solicitud de requerimiento 400 Servidor no encontrado 404 Pagina no encontrada

Tabla 25: pruebas servicio HTTP servidor virtual Petición de servicio ‘FTP’ servidor virtual . FTP

El usuario deberá escribir el siguiente comando: FTP 192.168.0.1 21 FTP Nombre_Dominio 21

Resultado

El resultado de la prueba es que el servidor solicita al usuario una autentificación para poder accesar al servicio. Usuario Password

Posibles Errores

: test_FTP : ********

Servidor no se encuentra Login o password errónea Conexión rechazada Usuario no tiene permisos

Tabla 26: prueba de servicio FTP servidor virtual

90

INACAP Apoquindo Ingeniería en Gestión Informática

7.1.1.2

Pruebas de Conectividad.

Verificación Ping a IP de máquinas del cluster. (VIP,SGW,DIP,RIP) ping Resultado

El usuario deberá realizar un ping a cada una de las direcciones IP (VIP,RIP,DIP), Ejemplo: ping 192.168.0.1 Como resultado de esta prueba la conectividad será exitosa: bash$ ping 192.168.0.1 Haciendo ping a 192.168.0.1 con 32 bytes de datos: Respuesta desde 192.168.0.1: bytes=32 tiempo