argemiro ejemplo

download argemiro ejemplo

of 33

Transcript of argemiro ejemplo

CLUSTER EMPRESARIALES

TABLA DE CONTENIDOINTRODUCCION..................................................................................................................2 1. OBJETIVOS......................................................................................................................3 1.1 Objetivo General...............................................................................................................3 1

1.2 Objetivos especficos........................................................................................................4 2. MARCO TEORICO............................................................................................................4 2.1 CLUSTER DE BALANCEO DE CARGA.....................................................................4 2.1.1 Clasificacin de los Cluster..................................................................................5 2.2 Cluster de alta disponibilidad............................................................................................6 Clculo de la Disponibilidad...................................................................................................6 2.4 Configuraciones de Alta Disponibilidad..........................................................................8 2.4.1 Configuracin Activo/Pasivo.........................................................................................8 2.4.2 Funcionamiento de un cluster de alta disponibilidad.....................................................9 2.5 SOLUCIONES ...............................................................................................................14 2.6 Configuracin de un clster de alta disponibilidad ..............................................18 2.6.1 Creacin del clster mediante Conga........................................................19 2.6.2 Configuracin de la proteccin mediante barrera con Conga...................20 2.6 SOLUCION GRUPAL....................................................................................................21 Administrador Contento............................................................................31 3. CONCLUSIONES............................................................................................................32 4. BIBLIOGRAFIA...............................................................................................................33

INTRODUCCION

2

Con el pasar del tiempo el hombre se ha tenido que enfrentar a mltiples problemas que no han sido fciles de resolver, por lo que es l quin se ha visto en la necesidad de usar herramientas que le ayudaran en la solucin. Inicialmente para solucionar sus problemas surgi algo que se llama supercomputadoras las cuales cuentan con arreglos de microprocesadores que trabajan en sincrona empleando procesamiento paralelo, dichas supercomputadoras se les conoce hoy en da como clster de computadores, concepto que esta oportunidad vamos a estudiar, los clster han ayudado al hombre con la solucin de problemas ms robustos. Los clster deben tener diversas caractersticas que posibilitan el manejo de grades cantidades de tareas. La disponibilidad y la fiabilidad, se encuentran bastante relacionados, aunque difieren ligeramente en algunos aspectos.La disponibilidad es la calidad de estar presente y listo para su uso, mientras que la fiabilidad es la probabilidad de un correcto funcionamiento. En la actualidad el problema del balanceo de carga ha sido bastante trabajado, debido al hecho de que las diferentes comunidades requieren disminuir al mximo el tiempo de ejecucin de las aplicaciones ejecutadas. Sin embargo, su solucin no es siempre trivial. Este es un problema bastante complejo, debido a la dificultad en ocasiones de lograr que las propuestas en las distribuciones de carga de trabajo sean fcilmente escalables, o que se pueda trabajar con equipos que no sean necesariamente similares en general se recurre a trabajar con clster homogneos (maquinas con software hardware semejantes) y no en heterogneos maquinas con software hardware diferentes).

1. OBJETIVOS

1.1 Objetivo General 3

Comprender el significado, la importancia y la aplicacin en la actualidad de los clster como herramienta bsica de trabajo.

1.2 Objetivos especficos.

1. Aprender el concepto de clster empresarial o de alta disponibilidad. 2. Conocer las herramientas bsicas para la implementacin de clster. 3. Conocer las diferentes soluciones de clster de alta disponibilidad. 4. Adquirir los conocimientos bsicos para la implementacin de clster en el siguiente semestre. 5. Demostrar la habilidad de comprender la importancia de los clster en el mundo empresarial como herramienta idnea de trabajo.

2. MARCO TEORICO

2.1 CLUSTER DE BALANCEO DE CARGA 4

Un clster de balanceo de carga o de cmputo adaptativo est compuesto por uno o ms ordenadores que actan como frontend del clster, y que se ocupan de repartir las peticiones de servicio que reciba el clster, a otros ordenadores del clster que forman el back-end de ste. Un tipo concreto de clster cuya funcin es repartir la carga de proceso entre los nodos en lugar de los servicios es el clster openMosix. Las caractersticas ms destacadas de este tipo de clster son: Se puede ampliar su capacidad fcilmente aadiendo ms ordenadores al clster. Robustez. Ante la cada de alguno de los ordenadores del clster el servicio se puede ver mermado, pero mientras haya ordenadores en funcionamiento, stos seguirn dando servicio. 2.1.1 Clasificacin de los Cluster Existen principalmente tres tipos de clster: clster de alto rendimiento, clster de alta disponibilidad y clster de alta confiabilidad, los cuales fueron creados para desempear funciones especificas, de acuerdo a los requerimientos y preferencias de quien o quienes los estn implementando. 1. Alto rendimiento : Los clster de alto rendimiento han sido creados para compartir el recurso ms valioso de un computador, el tiempo de proceso. Cualquier operacin que necesite altos tiempos de CPU puede ser utilizada en un clster de alto rendimiento, siempre que se encuentre un algoritmo que sea paralelizable

2. Alta disponibilidad: los clster de alta disponibilidad son bastante ortogonales en lo que se refieren a funcionalidad a un clster de alto rendimiento. Los clster de alta disponibilidad pretenden dar servicios 7/24 de cualquier tipo, son clster donde la principal funcionalidad es estar controlando y actuando para que un servicio o varios se encuentren activos durante el mximo periodo de tiempo posible. 5

3. Alta confiabilidad : Estos clster tratan de aportar la mxima confiabilidad en un entorno, en la cual se necesite saber que el sistema se va a comportar de una manera determinada. Puede tratarse por ejemplo de sistemas de respuesta a tiempo real. Este tipo de clster son los ms difciles de implementar. No se basan solamente en conceder servicios de alta disponibilidad, sino en ofrecer un entorno de sistema altamente confiable. Esto implica muchsima sobrecarga en el sistema. 2.2 Cluster de alta disponibilidad Un cluster de alta disponibilidad es un conjunto de dos o ms mquinas que se caracterizan por mantener una serie de servicios compartidos y por estar constantemente monitorizndose entre s. Podemos dividirlo en dos clases: Alta disponibilidad de infraestructura: Si se produce un fallo de hardware en alguna de las mquinas del cluster, el software de alta disponibilidad es capaz de arrancar automticamente los servicios en cualquiera de las otras mquinas del cluster (failover). Y cuando la mquina que ha fallado se recupera, los servicios son nuevamente migrados a la mquina original (failback). Esta capacidad de recuperacin automtica de servicios nos garantiza la alta disponibilidad de los servicios ofrecidos por el cluster, minimizando as la percepcin del fallo por parte de los usuarios. Alta disponibilidad de aplicacin: Si se produce un fallo del hardware o de las aplicaciones de alguna de las mquinas del cluster, el software de alta disponibilidad es capaz de arrancar automticamente los servicios que han fallado en cualquiera de las otras mquinas del cluster. Y cuando la mquina que ha fallado se recupera, los servicios son nuevamente migrados a la mquina original. Esta capacidad de recuperacin automtica de servicios nos garantiza la integridad de la informacin, ya que no hay prdida de datos, y adems evita molestias a los usuarios, que no tienen por qu notar que se ha producido un problema. No hay que confundir un cluster de alta disponibilidad con un cluster de alto rendimiento. El segundo es una configuracin de equipos diseado para proporcionar capacidades de clculo mucho mayores que la que proporcionan los equipos individuales, mientras que el primer tipo de cluster est diseado para garantizar el funcionamiento ininterrumpido de ciertas aplicaciones. Clculo de la Disponibilidad

2.3

En un sistema real, si falla uno de los componentes, es reparado o sustituido por un nuevo componente. Si este nuevo componente falla, es sustituido por otro, y 6

as sucesivamente. El componente fijo se considera en el mismo estado que un nuevo componente. Durante su vida til, uno de los componentes pueden ser considerado en uno de estos estados: Funcionando o en Reparacin. El estado funcionando indica que el componente est operacional y el en reparacin significa que ha fallado y todava no ha sido sustituido por un nuevo componente. En caso de defectos, el sistema va de funcionando en modo reparacin, y cuando se hace la sustitucin volver al estado funcionando. Por lo tanto, podemos decir que el sistema tiene durante su vida, una media de tiempo para presentar fallas (MTTF) y un tiempo medio de reparacin (MTTR). Su tiempo de la vida es una sucesin de MTTFs y MTTRs, a medida que este va fallando y siendo reparado. El tiempo de vida til del sistema es la suma de MTTFs en ciclos MTTF + MTTR ya vividos. En forma simplificada, se dice que la disponibilidad de un sistema es la relacin entre la duracin de la vida til de este sistema y de su tiempo total de vida. Esto puede ser representado por la frmula de abajo: Disponibilidad = MTTF / (MTTF + MTTR) En la evaluacin de una solucin de Alta Disponibilidad, es importante tener en cuenta si en la medicin de MTTF son vistos como fallas las posibles paradas planificadas. En general las razones para implementar un cluster de alta disponibilidad son: Aumentar la disponibilidad Mejorar el rendimiento Escalabilidad, Tolerancia a fallos Recuperacin ante fallos en tiempo aceptable Reducir costes Consolidar servidores Consolidar el almacenamiento 7

2.4 Configuraciones de Alta Disponibilidad Las configuraciones ms comunes en entornos de clusters de alta disponibilidad son la configuracin activo/activo y la configuracin activo/pasivo. Configuracin Activo/Activo En una configuracin activo/activo, todos los servidores del cluster pueden ejecutar los mismos recursos simultneamente. Es decir, los servidores poseen los mismos recursos y pueden acceder a estos independientemente de los otros servidores del cluster. Si un nodo del sistema falla y deja de estar disponible, sus recursos siguen estando accesibles a travs de los otros servidores del cluster. La ventaja principal de esta configuracin es que los servidores en el cluster son mas eficientes ya que pueden trabajar todos a la vez. Sin embargo, cuando uno de los servidores deja de estar accesible, su carga de trabajo pasa a los nodos restantes, lo que produce una degradacin del nivel global de servicio ofrecido a los usuarios. En la siguiente figura se muestra como ambos servidores estn activos, proporcionando un mismo servicio a los diferentes usuarios. Los clientes acceden al servicio o recursos deforma transparente y no tienen conocimiento de la existencia de varios servidores formando un cluster.

2.4.1 Configuracin Activo/Pasivo Un cluster de alta disponibilidad, en una configuracin activo/pasivo, consiste en un servidor que posee los recursos del cluster y otros servidores que son capaces de acceder a esos recursos, pero no los activan hasta que el el propietario de los recursos ya no este disponible. 8

Las ventajas de la configuracin activo/pasivo son que no hay degradacin de servicio y que los servicios solo se reinician cuando el servidor activo deja de responder. Sin embargo, una desventaja de esta configuracin es que los servidores pasivos no proporcionan ningn tipo de recurso mientras estn en espera, haciendo que la solucin sea menos eficiente que el cluster de tipo activo/activo. Otra desventaja es que los sistemas tardan un tiempo en migrar los recursos (failover) al nodo en espera. 2.4.2 Funcionamiento de un cluster de alta disponibilidad En un cluster de alta disponibilidad, el software de cluster realiza dos funciones fundamentales. Por un lado intercomunica entre s todos los nodos, monitorizando continuamente su estado y detectando fallos. Y por otro lado administra los servicios ofrecidos por el cluster, teniendo la capacidad de migrar dichos servicios entre diferentes servidores fsicos como respuesta a un fallo. A continuacin se describen los elementos y conceptos bsicos en el funcionamiento del cluster. Recurso y Grupos de Recursos Tradicionalmente se entiende como servicio a un conjunto de procesos que se ejecutan en un momento dado sobre un servidor y sistema operativo. Este ltimo provee a los procesos de los recursos necesarios para realizar su tarea: sistema de ficheros, interfaces de red, tiempo de cpu, memoria, etc En un cluster de alta disponibilidad, el software de cluster, abstrae e independiza a los servicios de un host concreto. Posibilitando que estos se desplacen entre diferentes servidores de forma trasparente para la aplicacin o los usuarios. El software de cluster permite definir grupos de recursos, que son todos aquellos recursos necesarios por el servicio. Estos recursos sern los scripts de arranque del servicio, un sistema de ficheros, una direccin IP, etc.

9

Intercomunicacin El software de cluster gestiona servicios y recursos en los nodos. Pero adems, tiene que mantener continuamente entre estos una visin global de la configuracin y estado del cluster. De esta forma, ante el fallo de un nodo, el resto conoce que servicios se deben restablecer. Ya que la comunicacin entre los nodos del cluster es crucial para el funcionamiento de este, es habitual utilizar un canal especifico como una red IP independiente o una conexin serie, que no se pueda ver afectada por problemas de seguridad o rendimiento. Heartbeat El software de cluster conoce en todo momento la disponibilidad de los equipos fsicos, gracias a la tcnica de heartbeat. El funcionamiento es sencillo, cada nodo informa peridicamente de su existencia enviando al resto una seal de vida. Escenario Split-Brain En un escenario split-brain, mas de un servidor o aplicacin pertenecientes a un mismo cluster intentan acceder a los mismos recursos, lo que puede causar daos a dichos recursos. Este escenario ocurre cuando cada servidor en el cluster cree 10

que los otros servidores han fallado e intenta activar y utilizar dichos recursos. Monitorizacin de Recursos (Resource Monitoring) Ciertas soluciones de clustering HA permiten no solo monitorizar si un host fsico esta disponible, tambin pueden realizar seguimientos a nivel de recursos o servicios y detectar el fallo de estos. El administrador puede configurar la periodicidad de estos monitores as como las acciones a llevar a cabo en caso de fallo. Reiniciar Recursos Cuando un recurso falla, la primera medida que toman las soluciones de cluster es intentar reiniciar dicho recurso en el mismo nodo. Lo que supone detener una aplicacin o liberar un recurso y posteriormente volverlo a activar. Algunas implementaciones no permiten reiniciar un nico recurso, y lo que realizan es un reinicio completo de todo un grupo de recursos (servicio). Esto puede llegar a demorar bastante para servicios como las bases de datos. - Migracin de Recursos (Failover) Cuando un nodo ya no esta disponible, o cuando un recurso fallido no se puede reiniciar satisfactoriamente en un nodo, el software de cluster reacciona migrando el recurso o grupo de recursos a otro nodo disponible en el cluster. De este modo el tiempo de inactividad por el posible fallo es mnimo, y el cluster seguir proporcionando el correspondiente servicio.

11

Dependencia entre recursos Habitualmente para que el cluster proporcione un servicio, son necesarios no solo un recurso si no varios (ip virtual, sistema de ficheros, proceso), lo que se conoce como grupo de recursos. Cuando se arranca o detiene un servicio, sus recursos tienen que activarse en el orden apropiado ya que unos dependen de otros. El software de cluster tiene que permitir definir estas dependencias entre recursos as como entre grupos. Preferencia de Nodos (Resource Stickiness) En configuraciones de cluster con mltiples nodos, es comn distribuir los servicios a proporcionar entre los diferentes servidores. Adems puede que los servidores tengan caractersticas hardware diferentes (cpu, memoria ram) y nos interese que, para un estado ideal del cluster, determinados servicios se ejecuten siempre en un determinado servidor. Este comportamiento se define mediante la preferencia de nodo en la definicin de cada recurso.

12

Comunicacin con otros sistemas El cluster tiene que monitorizar no solo que un servidor y sus servicios estn activos, tambin debe de comprobar que, de cara a los usuarios, dicho servidor no queda desconectado de la red por el fallo de un latiguillo, switch, etc. Por lo tanto el software de cluster debe comprobar que los nodos son alcanzables. Un mtodo simple para conseguirlo, es verificar que cada nodo tiene accesible el router o puerta de enlace de la red de usuarios. Fencing En los clusters HA existe una situacin donde un nodo deja de funcionar correctamente pero todava sigue levantado, accediendo a ciertos recursos y respondiendo peticiones. Para evitar que el nodo corrompa recursos o responda con peticiones, los clusters lo solucionan utilizando una tcnica llamada Fencing. La funcin principal del Fencing es hacerle saber a dicho nodo que esta funcionando en mal estado, retirarle sus recursos asignados para que los atiendan otros nodos, y dejarlo en un estado inactivo.

Quorum Para evitar que se produzca un escenario de Split-Brain, algunas implementaciones de cluster HA introducen un canal de comunicacin adicional que se emplea para determinar exactamente que nodos estn disponibles en el cluster y cuales no. Tradicionalmente se implementa utilizando los llamados quorum devices, que habitualmente son un volumen de almacenamiento compartido exclusivo (disk heart beating). Tambin existen implementaciones que utilizan una conexiones de red adicional o una conexin serie. Esta ltima tiene limitaciones de distancia y actualmente ha quedado en desuso.

13

2.5 SOLUCIONES Existen muchos proyectos dedicados a proporcionar soluciones para Clusters de Alta Disponibilidad. Hay que tener en cuenta tambin que actualmente las aplicaciones de clustering son bastante complejas por lo que suelen constar de varios componentes. Una solucin completa de clustering utiliza componentes de varios subproyectos. 1. Proyecto Linux-HA y Heartbeat El proyecto Linux-HA tiene como objetivo proporcionar una solucin de alta disponibilidad (clustering) para Linux que promueva la fiabilidad y disponibilidad de sistemas a travs de su comunidad de desarrolladores. Linux-HA se utiliza ampliamente y como una parte muy importante, en muchas soluciones de Alta Disponibilidad. Desde que comenz en el ao 1999 a la actualidad, sigue siendo una de las mejores soluciones de software HA para muchas plataformas. El componente principal de Linux-HA es Heartbeat, un demonio que proporciona los servicios de infraestructura del cluster (comunicacin y membresa). Este permite conocer, a otros procesos del cluster, la presencia o cada de un recurso o mquina y facilitar la comunicacin entre estos. Para formar una solucin cluster de utilidad, Heartbeat necesita combinarse con un Cluster Resource Manager (CRM), que realiza las tareas de iniciar o parar los recursos (direcciones IP, servicios, etc) a dotar de alta disponibilidad. En la primera versin de Linux-HA, se utiliza con Heartbeat un sencillo CRM que solo es capaz de administrador clusters de 2 nodos y solo detecta fallos a nivel de maquina. Con Linux-HA 2 se desarroll un nuevo CRM mas avanzado, que superaba dichas limitaciones. De este nuevo desarrollo surge el proyecto CRM Pacemaker.

14

2. Pacemaker CRM El proyecto Pacemaker surge en el ao 2007, a raz de la segunda generacin de Linux-HA. Los programadores del componente CRM de Linux-HA, deciden extraer el desarrollo y mantenimiento de este en un proyecto separado. Para que el nuevo CRM pueda utilizar como capa de comunicacin no solo Heartbeat si no tambin OpenAIS. Pacemaker es compatible totalmente con Heartbeat, as como con los scripts de recursos existentes para este, tambin se ha adaptado el administrador grfico Linux-HA para que funcione con Pacemaker. Pacemaker esta disponible en la mayora de las distribuciones Linux actuales, las cuales lo han adoptado como sucesor de Heartbeat. Tambin es la opcin elegida en Suse Linux Enterprise, una de las distribuciones comerciales mas importantes en el sector corporativo.

3. OpenAIS OpenAIS Cluster Framework es una implementacin open source de las Application Interface Specification (AIS). Un conjunto de especificaciones para estandarizar el desarrollo de servicios e interfaces para la alta disponibilidad, desarrolladas por el Service Availability Forum. Los principales beneficios de una solucin de Cluster HA basado en las normas AIS son la mejora en portabilidad e integracin, permite sistemas mas escalables, la reduccin de costes y reutilizacin de componentes. Esta estandarizacin puede ser muy beneficiosa no solo para los componentes principales del software o middleware de clustering, si no por el hecho de que el cluster sea capaz de monitorizar un mayor numero de servicios y recursos con un API unificada. El proyecto OpenAIS implementa actualmente los componentes de infraestructura y membresa. Y es utilizado en soluciones completas de clustering como Pacemaker o Red Hat Cluster.

15

4. Proyecto Red Hat Cluster RedHat-Cluster es un proyecto de desarrollo open source de diferentes componentes de clustering para Linux. Esta promovido principalmente por RedHat, ya que en dicho proyecto se basa casi en totalidad su producto Red Hat Cluster Suite para su distribucin comercial Linux RHLE. RedHat-Cluster es un conjunto de componentes que forman una solucin de clustering HA completa. Tiene varias versiones, conocidas como: Cluster1, Cluster2 (versin estable y utilizada en RHLE5), y la tercera generacin Cluster3. Todas ellas tienen en comn que utilizan un CRM propio llamado CMAN. La arquitectura de Cluster2 (segunda generacin de RedHat-Cluster), se basa en lineas generales en el uso de OpenAIS como componente de mensaje/membresa y CMAN como administrador de recursos (CRM). As como otros componentes que proporcionan fencing, balanceo de carga, o las propias herramientas de administracin del cluster. Destacar que podemos implantar RedHat-Cluster en cualquier distribucin Linux, por ejemplo Debian tiene todos los paquetes necesarios en sus repositorios oficiales. 5. Corosync Cluster Engine Corosync Cluster Engine es un proyecto open source bajo la licencia BSD, derivado del proyecto Open-AIS. El objetivo principal del proyecto es desarrollar una solucin de cluster completa, certificada por la OSI (Open Source Initiative), con soporte para Linux, Solaris, BSD y MacOSX. El proyecto se inicia en Julio de 2008, y la primera versin estable Corosync 1.0.0 se lanz en agosto de 2009. Hasta el momento solo la distribucin Fedora lo soporta oficialmente incluyendo los binarios de Corosyn en sus repositorios de paquetes.

16

6. Otros Existen otros muchos proyectos dedicados a facilitar la instalacin y configuracin de clusters de alta disponibilidad. Por ejemplo el proyecto UltraMonkey, que combina LVS + Heartbeat + Ldirector, para proporcionar una solucin de cluster HA y balanceo de carga. As como otros proyectos de clusters de alta disponibilidad completos que han quedado discontinuados con los aos, como el caso de Kimberlite o de OpenHA. Tambin hay varios proyectos muy interesantes para plataformas diferentes a Linux, como el caso del Open High Availability Cluster (OHAC) que es la versin OpenSource del Solaris Cluster de Sun Microsystems.

7. Soluciones comerciales Dentro del mbito empresarial, las compaas Red Hat y Novell, ofrecen soluciones completas de clusters de alta disponibilidad basadas en los proyectos libres mencionados anteriormente. Estos paquetes comerciales se venden como una solucin completa de software libre mas soporte anual, documentacin y actualizaciones de seguridad. En el caso de Novell, para su distribucin Suse Linux Enterpise Server 11, el producto de alta disponibilidad se conoce como High Availability Extension. Y esta basado totalmente en OpenAIS y Pacemaker. En el caso de Red Hat tenemos el Red Hat Cluster Suite que bsicamente es la comercializacin del proyecto Red Hat Cluster como cluster de alta disponibilidad y LVM como balanceador de carga.

17

2.6 Configuracin de un clster de alta disponibilidad Presentaremos las instrucciones bsicas para la configuracin de un cluster de alta disponibilidad mediante el uso de Conga Conga es un conjunto de aplicaciones de administracin y configuracin de nueva creacin basado en un modelo de servidor/agente. Puede acceder al servidor de administracin (luci) mediante un explorador web estndar desde cualquier parte de la red. Conga se comunica mediante el agente del cliente (ricci) en los nodos e instala todos los paquetes necesarios, sincroniza el archivo de configuracin y administra el clster de almacenamiento. Aunque existen varios mtodos posibles, incluida la interfaz de lnea de comandos, se recomienda utilizar Conga para configurar y supervisar el clster. Para preparar los nodos del clster: 1. Ejecute el comando siguiente en cada nodo del clster para instalar el agente del cliente ricci de Conga: a. Instale ricci. [root]# yum install ricci b. Configure ricci de modo que se ejecute al iniciarse el sistema. [root]# chkconfig ricci on c. Inicie el agente ricci. [root]# service ricci start 2. Ejecute el comando siguiente en el nodo de administracin para instalar el servidor luci de Conga. En el nodo de administracin: a. Instale el agente del servidor luci de Conga: [root]# yum install luci NOTA: Puede configurar el servidor luci en cualquier nodo, pero se recomienda instalar luci en un nodo de administracin dedicado. Si cuenta con un nodo de este tipo, ste deber tener acceso al grupo de clster. Tambin puede iniciar la sesin en RHN y descargar manualmente luci para instalarlo en el nodo de administracin.

18

b. Inicialice el agente del servidor luci: [root]# luci_admin init c. Configure el agente del servidor luci de modo que se ejecute al iniciarse el sistema: [root]# chkconfig luci on d. Inicie el agente del servidor luci: [root]# service luci start 2.6.1 Creacin del clster mediante Conga Conga instala automticamente el software necesario para la agrupacin en clster en todos los nodos del clster. Conctese al agente del servidor luci desde cualquier explorador en la misma red que el nodo de administracin. En el explorador web, escriba: https://{nombre de host del nodo de administracin o direccin IP}:8084 Donde {nombre de host del nodo de administracin o direccin IP} es el nombre de host o la direccin IP del nodo de administracin dedicado opcional o del nodo del clster que ejecuta el agente del servidor luci. 1. Introduzca su nombre de usuario y su contrasea para iniciar la sesin de forma segura en el agente del servidor luci. 2. Vaya a la ficha Cluster (Clster). 3. Haga clic en Create a New Cluster (Crear un nuevo clster). 4. Introduzca un nombre de clster de 15 caracteres como mximo. 5. Aada el nombre completo del host privado o la direccin IP y la contrasea root para cada nodo del clster. 6. Asegrese de que ha seleccionado la opcin Enable Shared Storage Support (Activar compatibilidad con almacenamiento compartido) y haga clic en Submit (Enviar). Conga descarga e instala todo el software de clster necesario, crea un archivo de configuracin y reinicia cada uno de los nodos del clster. Observe la ventana de estado de Conga para ver el progreso de cada nodo del clster. 19

2.6.2 Configuracin de la proteccin mediante barrera con Conga En el sistema PowerEdge Cluster SE600L, los distribuidores elctricos de red proporcionan el mtodo de proteccin mediante barrera ms fiable. Configure los distribuidores elctricos de red y las controladoras de acceso remoto como Dell Remote Access Controller (DRAC) o Intelligent Platform Management Interface (IPMI) en la misma red privada que los nodos del clster. Las controladoras de acceso remoto como DRAC o IPMI deberan utilizarse como mtodos secundarios, a menos que no haya distribuidores elctricos de red disponibles. En ese caso, configure un mtodo secundario como manual. Emplee una utilidad de vigilancia de registro de eventos para que le avise si su mtodo de proteccin mediante barrera principal tiene fallos. y la seccin "Fencing" (Proteccin mediante barrera) del documento "Cluster Suite Overview" (Informacin general sobre Cluster Suite) en la pgina web de Red Hat en www.redhat.com/docs/manuals/enterprise.

Para configurar la proteccin mediante barrera: 1. Vaya a Cluster Nodes (Clster Nodos). 2. Seleccione uno de los nodos del clster. 3. Bajo la seccin Main Fencing Method (Mtodo de proteccin mediante barrera principal), haga clic en Add (Aadir). 4. Configure la proteccin mediante barrera principal y la secundaria. NOTA: Si dispone de distribuidores elctricos de red opcionales, se configurarn como dispositivos compartidos.

20

2.6 SOLUCION GRUPAL

IMPLEMENTACION DE UN CLUSTER DE ALTA DISPONIBILIDAD Material necesario: 2 maquinas con Linux El paquete Heardbeat un Sistema de ficheros con Journaling Una Red Puerto serie

Qu es Heartbeat? Heartbeat es un paquete de software creado por LINUX-HA, funciona de forma similar al System V o init pero en vez de una sola mquina pasara a ejecutar los servicios en los nodos, basndose en que no le llegan respuestas estas se hacen por medio de ping y por pulsaciones del cable serie. Que es STONITH? STONITH son la Siglas de Shoot The Other Node In The Head ( Pgale un Tiro en la Cabeza al otro Nodo). Es una tcnica usada por Heartbeat que se asegura de que un servidor supuestamente muerto no interfiera con el funcionamiento del cluster, en caso de no implementarse bien esta tcnica, podra dar lugar a que el cluster no funcione. A grosso modo STONITH consiste en que el servidor secundario nota que el primario no funciona, y este le hara un DDOS al primario para asegurarse de que ha sido un falso positivo y tomara el nodo secundario el control.

21

Preparando el Hardware Existen 3 cosas especificas del cluster que hay que conectar, los discos, las NICs de interconexin, el cable serial de interconexin y los cables de control de los UPS Primero instalaremos los discos, pero no crearemos aun ningn sistema de ficheros. Instalaremos las NICs y las configuraremos con IPs privadas de la misma subred en los rangos 192.168.0.0/16 o el rango 10.0.0/8 A continuacin nos haremos con un cable Serial para la comunicacin PC a PC . Nosaseguraremos de que el cable incluya modems null y que incluya cables CTS Y RTS Conectamos cada ordenador a su UPS

Instalacin del Software Para nuestro cluster necesitaremos varios paquetes de software. Heartbeat-1.0.3, Heartbeat-pils-1.0.3, Heartbeat-stonith-1.0.3 los paquetes los instalaremos usando nuestro administrador de paquetes favoritos ya sea apt-get, yast,urpmi, emerge, etc. Por ultimo nos queda instalar el servicio que queramos dar ya sea samba,apache postfix, etc. Configurando DRBD. DRBD se configura en el fichero /etc/drbd.conf Cdigo: resource drbd0 { protocol=C fsckcmd=/bin/true 22

disk { disk-size=80418208 do-panic } net { sync-rate=8M # bytes/sec timeout=60 connect-int=10 ping-int=10 } on Zeus { # Zeus es el nombre del servidor principal device=/dev/nb0 disk=/dev/hda1 address=192.168.1.1 port=7789 } on SolarUX { #SolarUX es el nombre del servidor secundario device=/dev/nb0 disk=/dev/hda1 23

address=192.168.1.2 port=7789 } } Nota: Para calcular el tamao del disco usaremos blockdev-getsize y dividiremos el resultado por dos si ambas partes dan resultado diferente elegiremos el mas grande Creando el Sistema de Ficheros A continuacin crearemos el sistema de ficheros para Zeus ( Servidor Primario) es importante usar un sistema de ficheros con Journaling como Reiserfs, ext3, jfs, xfs. Crearemos dos particiones del mismo tamao en el dispositivo /dev/nb0 los dos servidores y con Reiserfs ya que se considera mas seguro. Instrucciones a ejecutar en Zeus Cdigo: Root@Zeus:~# /etc/init.d/drbd start Le respondemos yes para que nos ponga a Zeus como primario. ahora creamos el sistema de ficheros y lo montamos Cdigo: Root@Zeus:~# mkfs -t reiserfs /dev/nb0 datadisk /dev/nb0 start

24

por ltimo si usamos una conexin Ethernet de 1Gb para la sincronizacin, cambiaremos los parmetros los parmetros de esta para que nos funcione en modo fullduplex ver Activando Fullduplex en tarjetas ethernet en este mismo foro Configurando Heartbeat Heartbeat tiene tres ficheros de configuracin.

1. ha.cf Configura informacin bsica del cluster 2. haresources.cf Configura los grupos de recursos tipo init 3. authkeys Configura la Autenticacin de red Se pueden encontrar ejemplos de estos ficheros en /usr/share/doc/pakages/Heartbeat y se documentan en el fichero Getting Started de Heartbeat ha.cf le aporta a Heartbeat la informacin de la configuracin bsica. Configura los nodos,pulsaciones serial, la manera de registrar los logs intervalo de tiempo muerto y pulsaciones ejemplo de nuestro ha.cf Cdigo: logfacility local7 # servicio de syslog keepalive 1 #Intervalo pulsacin warntime 2 #Pulsacin Tarda deadtime 10 # Tiempo control Fallos nice_failback on node Zeus SolarUX

25

ping 10.10.10.254 # Direccin del Router bcast eth0 eth1 #Broadcast Interfaces Heartbeat serial /dev/ttyS0 #Enlace Serial Heartbeat respawn /usr/lib/Heartbeat/ipfail stonith_host Zeus apcsmart SolarUX /dev/ttyS1 stonith_host SolarUX apcsmart Zeus /dev/ttyS1 las pulsaciones se envan por eth0, eth1 y serial /dev/ttyS0 este fichero es idntico para todos los nodos Fichero /etc/ha.d/haresources Este fichero crea un grupo de recursos que en teora pertenecen a Zeus, asociados a una IP virtual 10.10.10.20 y los recursos a servir:

NFS (Network File System) Samba (compartir archivos Windows) Dhcp (asignacin dinmica de Ips) Postfix (Servidor de Correo electrnico) Cdigo: Zeus 10.10.10.20 datadisk::drbd0 nfslock nfsserver smb dhcpd postfix Para clarificar donde estn colocados los scripts dir que Ipaddr y datadisk estn en /etc/ha.d/resource.d y el resto de servicios tpicos en /etc/init.d/

26

Heartbeat se las apaa de maravilla administrando la mayora de servicios que vienen en los V System init comnmente llamados los scripts de arranque, sin embargo una de las condiciones para que Heartbeat administre correctamente los Scripts es que tienen de tener el mismo nombre en todos los Nodos, por lo tanto recomiendo usar una distribucin idntica en las dos maquinas as simplificaremos la configuracin y el mantenimiento. Fichero /etc/ha.d/authkeys authkeys es el fichero de configuracin mas sencillo de todos. Contiene el mtodo de autenticacin basado en (sha1) con la clave que se usara para firmar los paquetes . este fichero tiene que ser idntico en todos los servidores y no debe tener ningn usuario acceso de lectura a excepcin de root: Cdigo: auth 1 1 sha1 RandomPasswordfc970c94efb Configuracin de los Servicios Tenemos de deshabilitar los servicios para que no sean controlados por init si no por Heartbeat esto lo conseguiremos con el siguiente comando: Cdigo: Root@Zeus:~# chkconfig -del nfslock nfsserver smb dhcpd postfix Ntese que deberamos cambiar los servicios marcados en azul por los que tenemos configurados en /etc/ha.d/haresources para servir.

27

Configurando /etc/fstab Tenemos de tener especial cuidado en que la particin /home no se monte automticamente desde /etc/fstab si existe ya una entrada para /home en dicho fichero la eliminamos y creamos esta: Cdigo: /dev/nb0 /home reiserfs noauto 0 0 Nota: si home ya esta montado lo desmontamos con umount /home Configuracin del Fichero /etc/hosts Si no tenemos un servidor DNS corriendo en nuestra red tendremos de usar nuestro archivo /etc/hosts quedando de esta manera: Cdigo: 10.10.10.20 Cluster # IP virtual cluster 192.168.1.1 Zeus #Servidor Primario 192.168.1.2 SolarUX # Servidor Segundario (Nodo) Montando todo el Cotarro Ahora es el momento de configurar el servidor segundario para que monte /home desde NFS aadiendo lo siguiente en /etc/fstab Cdigo: Cluster:/home /home nfs defaults 0 0 Una vez la particin NFS montada creamos el directorio /home/HA.config y creamos la siguiente estructura de directorios: 28

Cdigo: /etc postfix/ samba/ exports dhcpd.conf /var lib/ dhcpd samba nfs spool/ postfix/ mail/ Despus de montar la estructura de directorios tendramos que crear enlaces simblicos por ejemplo Cdigo: ln -s /home/HA.config/etc/samba/smb.cf /etc/samba/smb.cf Ahora desmontamos /home de la siguiente forma:

29

Cdigo: Root@Zeus:~# datadisk /dev/nb0 stop Root@Zeus:~# /etc/init.d/drbd stop Tambin podemos configurar samba para que escuche en la interface del cluster modificando dentro de la directiva [ global ] de /etc/samba/smb.cf Cdigo: interfaces = 127.0.0.1/8 10.10.10.10.20/24 Comprobando si todo Funciona DRBD Arrancamos drbd tanto en Zeus como en SolarUX con: Cdigo: Root@Zeus:~# /etc/init.d/drbd start una vez iniciado comprobaremos en Zeus si ha arrancado con: Cdigo: Root@Zeus:~# cat /proc/drbd veramos algo as 0: cs:SyncingAll st:Primary/Secondary Esto nos indica que ha sido todo arrancado correctamente y que una Sincronizacin Completa est en marcha . Esta sincronizacin tarda un poco y se puede ver el progreso en /proc/drbd Heartbeat Cdigo: Root@Zeus:~# /etc/init.d/Heartbeat start Root@Zeus:~# ifconfig |grep 10.10.10.20 Root@Zeus:~# /etc/init.d/nfslock status

30

Root@Zeus:~# /etc/init.d/smb status Root@Zeus:~# /etc/init.d/dhcpd status Root@Zeus:~# /etc/init.d/postfix status /home tiene que estar montado en Cluster y todos los servicios tendran de estar corriendo Delegando Funciones Ahora Heartbeat tiene de ser capaz de retransmitir todos los trabajos a SolarUX lo haremos con: Cdigo: Root@Zeus:~# /usr/sbin/Heartbeat/hb_standby Ahora hacemos los pasos de arriba Heartbeat en SolarUX y comprobamos si todo funciona correctamente si es as delegamos funciones a Zeus Cdigo: Root@SolarUx:~# /usr/sbin/Heartbeat/hb_standby Comprobamos en Zeus y si es as ya casi est.

Administrador Contento Desconectamos el cable de red a Zeus y en estos momentos aproximadamente unos 10 Sec SolarUX tendra de responder a la ip Virtual 10.10.10.20 y darnos Servicio

31

3. CONCLUSIONES

Del anterior trabajo podemos concluir que:

1. Hemos comprendido los conceptos bsicos de clster y su aplicacin en el mbito empresarial. 2. Comprendimos las herramientas bsicas para la implementacin de clusters. 3. Aprendimos las diferentes soluciones de clster de alta disponibilidad. 4. Comprendimos la importancia de los clster de alta disponibilidad y su aplicacin. 5. Los cluster son la unin de varios computadores para ejecutar tareas de forma rpida y ordenada.

32

4. BIBLIOGRAFIA http://support.ap.dell.com/support/edocs/systems/clusters/se600l/sp/it/sectione.htm http://www.lintips.com/?q=node/120 http://translate.google.com/translate? hl=es&sl=en&u=http://www.centos.org/docs/5/html/Cluster_Administration/chconfig-conga-CA.html&ei=7DdTYa4OcnEgQeO4MjMCg&sa=X&oi=translate&ct=result&resnum=2&ved=0CC kQ7gEwAQ&prev=/search%3Fq%3Dcluster%2Bconga%26hl%3Des%26biw %3D1285%26bih%3D560%26prmd%3Divns http://www.lintips.com/?q=node/117 http://www.utpl.edu.ec/eccblog/wp-content/uploads/2007/04/articulo-tecnicocluster-de-balanceo-de-craga-y-alta-disponibilidad-para-servicios-web-y-mail.pdf http://www.lintips.com/?q=node/119

33