lo que tenemos

Tipos de cluster segun sus componentes

HOMOGENEO:

Es te tipo de cluster es cuando se presentan en todos los computadores la misma configuración de hardware y sistema operativo (cluster homogéneo).

SEMI-HOMOGENEO:

Pued presentar diferente rendimiento pero con arquitecturas y sistemas operativos similares (cluster semi-homogéneo)


HETEREOGENEO:

Pueden tener o presentar diferente hardware y sistema operativo (cluster heterogéneo), lo que hace más fácil y económica su construcción.

progamas para cluster

1. Todo lo concerniente a Hardware en la temática de Clúster, además deberán realizar el levantamiento de la información sobre cuál es la disponibilidad de los equipos de computo del ambiente de telemática, tanto del aula polivalente como del taller. (Sebastián).
Aunque los clústeres de servidores Windows detectar correctamente las tarjetas de red en un equipo, Clúster Server no puede verlos. Los siguientes requisitos se deben alcanzar para que Clúster Server utilizar las tarjetas de red:
• La tarjeta de red debe estar enlazada a TCP/IP.
• La tarjeta de red debe ser de tipo Ethernet, token ring o FDDI.
• La tarjeta de red debe estar en una subred diferente de otras tarjetas de red en el equipo. Si dos tarjetas de red están en la misma subred, Clúster Server utilizará sólo uno de ellos.
Nota: Se recomienda encarecidamente que cualquier adicional instalada tarjeta en Microsoft Clúster Server ser de tipo PCI. Además, para que se apruebe la validación de hardware, las tarjetas de red es necesario ser de tipo PCI.
________________________________________
La información de este artículo se refiere a:
• Microsoft Windows 2000 Advanced Server
• Microsoft Windows 2000 Datacenter Server
• Microsoft Windows NT Server 4.0 Enterprise Edition


CLUSTER NBL
Network Load Balancing (NLB) ofrece una solución de alta disponibilidad para aplicaciones de servidor basadas en TCP/IP, capaz de ofrecer escalabilidad y alto rendimiento.
A continuación se muestran varias recomendaciones a la utilización de Clúster NLB.
• Es recomendable utilizar dos o más tarjetas de Red en cada Clúster HOST, cada una con su propia dirección IP. Este tipo de configuraciones aporta dos tipos de ventajas:
o Permitir la creación de múltiples Clúster NLB (ej.: una tarjeta de red para la gestión del servidor, y cada una de las tarjetas de red adicionales para la creación de un Clúster NLB adicional).
o Utilizar varias tarjetas en cada Nodo para manejar el tráfico del mismo Cluster NLB. Es decir, del mismo modo que es posible formar un Clister NLB con dos Nodos, utilizando una tarjeta de red de cada uno de los nodos, evaluar la posibilidad de utilizar dos o más tarjetas de red en cada Nodo (Host) para forma el Cluster NLB, y así poder ofrecer un mejor tiempo de respuesta
Si decidimos utilizar múltiples tarjetas de Red, es muy recomendable utilizar una tarjeta de red dedicada para la gestión del servidor (muy recomendable, pero NO es un requisito). Este adaptador de red será utilizado para la comunicación con los equipos Host del Cluster NLB, como por ejemplo, conexión por Terminal Server, administración del Cluster NLB a través de la herramienta administrativa Network Load Balancing Manager (NLBMgr.exe), etc. Así, podemos utilizar el resto de tarjetas de red para formar uno o varios Clúster NLB, cada uno con la configuración más apropiada para su fin.

ClusterVision actualmente ofrecen racimos y servidores con las plataformas de CPU siguientes: Intel Pentium III, Intel Pentium 4, Intel Xeon, Intel Itanium 2, el AMD Athlon XP Y EL AMD Athlon DIPUTADO.

Intel Pentium 4 and Xeon
El último Pentium 4 está basado en el corazón Northwood, que usa una tecnología de 0.13 micras y actualmente corre en una velocidad de reloj máxima de 3.2 GHz. Aparte de SSE Y DPL, el P4 apoya SSE2, que permite a las dos unidades de punto flotante del P4 funcionar cuatro simple precisión o cuatro FRACASOS de doble precisión por ciclo de reloj. Llaman la versión de multiprocesador del P4 el Xeon y actualmente corre en una velocidad de reloj máxima de 3.2 GHz
NODOS DE PROCESADOR DUALES O SOLOS
La mayor parte de racimos son diseñados con nodos de esclavo de procesador duales. Los motivos principales para esto son el espacio y la rentabilidad, tanto en el boxes-on-shelves el alojamiento de la solución como en el rackmount el alojamiento de la solución. Nodos de esclavo de procesador duales son sobre todo más rentables cuando costoso de alta velocidad interconecta son usado, como el número de interconecta por procesador es la mitad él del número requirió usando nodos de esclavo de procesador solos
Aunque el diseño de procesador dual pueda incurrir en una pequeña pena de funcionamiento ya que las amplitudes de banda tanto del los interconectar como el autobús de memoria son compartidas por los dos procesadores, esto es por lo general la mejor solución para el precio/funcionamiento.
PLACA MADRE CHIPSETS
Diseñando un racimo es importante seleccionar una combinación processor/memory/chipset que da el mejor funcionamiento para usted el tipo particular de uso. La opción incorrecta de esta combinación seriamente puede afectar el funcionamiento de usted el racimo. Por ejemplo, algún chipsets actualmente disponible tiene una amplitud de banda limitada PCI y por lo tanto limita la amplitud de banda máxima del de alta velocidad interconectan
TECNOLOGÍA DE MEMORIA
DDR la SDRAM (la Doble SDRAM de Tarifa de Datos) DDR dobla la tarifa de datos entre la memoria y el procesador por doblando la velocidad de autobús, por ejemplo de 133 a 266 MHz Esto causa un doblamiento de las amplitudes de banda de memoria comparadas a la SDRAM. DDR la memoria por lo general etiquetan como, por ejemplo, " DDR266 PC2100 ", que quiere decir certificado para las velocidades de autobús de 266 MHz para dar una amplitud de banda de 2.1 GIGAOCTETOS/S

DDR SDRAM module


RDRAM (Rambus Dirigen la RAM) RDRAM usa una tecnología bastante diferente de la SDRAM y la RAM DDR. RDRAM usa muchos bancos de memoria más que permiten a más páginas de memoria para ser abiertas simultáneamente. Además, esto permite a la memoria para ser dividida en los canales de superposición diferentes que pueden ser tenidos acceso simulateneously. RDRAM usa una anchura de autobús de sólo 16 o 32 añicos, pero permite a velocidades mucho más altas de autobús, causando las amplitudes de banda de hasta 4.2 GIGAOCTETOS/S

RDRAM module

RED INTERCONECTA
Nuestros racimos siempre vienen con una 100 red de Ethernet Mbit/s como el estándar. La red de Ethernet es usada para la administración y la supervisión de tareas y para el sistema de fichas de red (NFS). Si ninguna red adicional de alta velocidad es usada, la red de Ethernet también es usada para el mensaje que pasa en empleos paralelos.
Además de la red de Ethernet, ofrecemos tres redes diferentes opcionales de alta velocidad: SCI de Dolphin/Scali, Myrinet de Myricom, y QsNET de Quadrics.
Todos los tres interconectan tienen sus propias bibliotecas dedicadas multiroscadas MPI para el intranodo y la comunicación de canuto, que directamente el interfaz al hardware de nivel bajo y OS funciona. Todos los tres también tienen un procesador de entrada - salida dedicado y la memoria de a bordo, que descarga el protocolo que se maneja de la CPU principal y asegura que toda la amplitud de banda disponible PCI es dedicada a la comunicación de datos. Todos los tres interconectan el apoyo el Acceso de Memoria Directo (DMA) y el empleo 64 bit PCI o el autobús PCI-X


Dolphin/Scali SCI el Delfín el Interfaz Escalable Coherente (SCI) interconecta
Es lo menos costoso de alta velocidad interconectan disponible y es lo más conveniente para más pequeños clusters. SCI tiene una amplitud de banda máxima mono direccional de 200 MB/S y una latencia mínima de 4 usec. SCI usa 2D o un 3D torus la topología de red en la cual un máximo de 5 nodos directamente es unido (conectado) a un toque (anillo) de red. Cada uno de los cinco nodos sobre un toque(anillo) puede ser la parte de otro toque(anillo) con un máximo de 5 nodos, limitando los nodos totales a 5x5 nodos sobre una 2D SCI la red y 5x5x5 sobre un 3D SCI la red. Esto distribuido interconecta la arquitectura elimina la necesidad de un interruptor centralizado. SCI usa el ScaMPI MPI bibliotecas de Scali.

Dolphin SCI PCI card


Myricom Myrinet
El Myricon Myrinet la red es nuestra red más popular de alta velocidad y consiste en tarjetas de interfaz e interruptores. Esto tiene una amplitud de banda máxima bidireccional de más de 400 Mbits/s y una latencia mínima de 6 usec. La balanza (las escalas) de red de Myrinet a hasta 8,192 nodos. Myrinet usa la versión GM DEL MPICH MPI bibliotecas...




Myrinet PCI card


Quadrics QsNet el Quadrics QsNet
La red es lo más costoso de alta velocidad interconectan. Esto tiene una amplitud de banda máxima bidireccional de 360 MB/S y una latencia mínima de 5 usec.
Las tarjetas de interfaz se unen por los interruptores Quadrics graduales de hasta 128 puertos, que usan una topología de árbol gorda. Los interruptores tienen una muy alta amplitud de banda bisectional, cual balanza (escalas) directamente la red cultiva en el tamaño. Las redes de hasta 1024 puertos pueden ser construidas usando interruptores supuestos federados.
Quadrics usa sus propias bibliotecas MPI así como la biblioteca de comunicaciones Shmem y el sistema de fichas ElanFS remoto protocal, optimizado para
Infortrend IDE RAID

pasos para montar un cluster

1. Introducción
La finalidad de este documento es explicar de forma breve cómo montar dos tipos de clusters: aquellos destinados a la alta disponibilidad y los destinados al alto rendimiento. El primer tipo utilizará las tecnologías: Ultra Monkey: (HeartBeat, LVS, Ldirectord, MON) y NTP, entre otras; y el segundo: OpenMosix.

Este documento está basado en la rama de desarrollo de la distribución Debian GNU/Linux, más conocida como Sid. Aunque los pasos que aquí se detallan son fácilmente adaptables a otras distribuciones de GNU/Linux.

También se destaca que para leer este documento se han de poseer unos conocimientos avanzados en administración de sistemas GNU/Linux, ya sean para configurar aspectos como la red, el núcleo Linux o distintas partes del sistema. Aspectos que no entran dentro de este artículo y de los cuales existe una documentación muy extensa, como la que se lista en el apartado: Documentación general sobre GNU/Linux de la Bibliografía.

1.1. Tipos de clusters: conceptos básicos
Normalmente, al diseñar un cluster se piensa en solucionar alguno de los siguientes problemas:

Mejora de rendimiento

Abaratamiento del coste

Distribución de factores de riesgo del sistema

Escalabilidad

Para solucionar este tipo de problemas, se han implementado distintas soluciones. Aquí veremos dos de ellas: cluster de alta disponibilidad y de alto rendimiento.


Nota
Los clusters de alta disponibilidad son bastante ortogonales a los clusters de alto rendimiento, en lo relativo a funcionalidad. Los clusters de alta disponibilidad pretenden dar servicios 24*7, de cualquier tipo, son clusters donde la principal funcionalidad es estar controlando y actuando para que un servicio, o varios, se encuentren activos durante el máximo período de tiempo posible.


Nota
Los clusters de alto rendimiento han sido creados para compartir el recurso más valioso de un ordenador: el tiempo de proceso. Generalmente se utilizan en ambientes científicos o en grandes empresas, donde se utilizan para la compilación o renderización. Cualquier operación que necesite altos tiempos de CPU y millones de operaciones, puede ser utilizada en un cluster de alto rendimiento, siempre que se encuentre un algoritmo que sea paralelizable. Existen clusters que pueden ser denominados de alto rendimiento tanto a nivel de sistema como a nivel de aplicación. A nivel de sistema tenemos openMosix (el que trataremos en esta documentación), mientras que a nivel de aplicación se encuentran otros como MPI, PVM, Beowulf y otros muchos. En cualquier caso, estos clusters hacen uso de la capacidad de procesamiento que pueden tener varias máquinas.














2. Cluster de alta disponibilidad, Ultra Monkey
Actualmente existen muchos proyectos destinados a proveer de alta disponibilidad a un sistema, uno de ellos es Ultra Monkey (es el que se ha utilizado como base para esta documentación). Ultra Monkey es un proyecto que integra distintas herramientas de Software Libre para conseguir balanceo de carga y alta disponibilidad en redes de área local. Estas herramientas son: LVS, HearBeat, Ldirectord y MON, que se definirán en los siguientes apartados.
2.1. Componentes de Ultra Monkey
2.1.1. LVS (Linux Virtual Server)
LVS se implementa como un conjunto de parches al kernel Linux y un programa de espacio de usuario denominado ipvsadm. El sistema que tiene instalado LVS es denominado director o balanceador de carga, cuya función no es otra que balancear las peticiones de red que recibe entre un conjunto de servidores reales que se encuentran detrás de él.

LVS funciona a nivel TCP/IP, lo que se conoce como un conmutador de nivel 4. Lo que ve LVS son direcciones y puertos de origen y destino, y toma decisiones para balancear la carga con esta información. LVS toma las decisiones cuando se abre una conexión (SYN), manteniendo una tabla de conexiones, para saber a que servidor real[1] enviar un paquete perteneciente a una conexión ya establecida. Por lo tanto, el balanceo de carga que realiza LVS tiene, en principio, granularidad[2] a nivel de conexión.

LVS permite balancear muchos protocolos distintos, en principio puede balancear cualquier protocolo que trabaje en un solo puerto, y puede trabajar con protocolos que usen varios puertos, mediante persistencia o marcas de firewall.

Cuando se usan servicios persistentes, cada entrada en la tabla de LVS ya no corresponde a una conexión TCP (direcciones y puertos de origen y destino), sino que sólo usa las direcciones para identificar una conexión (se pierde granularidad).

Se puede usar iptables o ipchains para marcar los paquetes pertenecientes a un servicio virtual (con una marca de firewall) y usar esa marca para que LVS identifique los paquetes pertenecientes al servicio virtual.

LVS se ha usado con HTTP, HTTPS, Telnet, FTP, Squid, servidores de streaming QT, Real y Windows Media, incluso se ha empezado a añadirle soporte para IPSec (FreeSWAN).

LVS realiza balanceo de carga y facilita la alta disponibilidad entre los servidores reales (si alguno deja de funcionar, se elimina del cluster mediante ipvsadm; cuando vuelva a estar operativo, se añade de nuevo con ipvsadm). Sin embargo, el balanceador de carga pasa a ser un SPOF[3], si se quiere alta disponibilidad se tiene que añadir un balanceador de respaldo y usar software de alta disponibilidad que le permita tomar el papel del balanceador de carga principal, esto lo conseguimos con HearBeat.

2.1.2. HearBeat
Esta tecnología implementa heartbeats, cuya traducción directa sería: «latidos de corazón». Funciona enviando periódicamente un paquete, que si no llegara, indicaría que un servidor no está disponible, por lo tanto se sabe que el servidor ha caído y se toman las medidas necesarias.
Dichos latidos se pueden enviar por una linea serie, por UDP o por PPP/UDP. De hecho los desarrolladores de HeartBeat recomiendan el uso de puertos serie por varias razones, entre las que destacan que están aislados de las tarjetas de red.
También incluye toma de una dirección IP y un modelo de recursos, incluyendo grupos de recursos. Soporta múltiples direcciones IP y un modelo servidor primario/secundario. Se ha probado satisfactoriamente en varias aplicaciones, como son: servidores DNS, servidores proxy de caché, servidores web y servidores directores de LVS. El proyecto LVS recomienda HeartBeat para aumentar la disponibilidad de su solución, pero no es parte de LVS.
En Linux-HA Heartbeat es un servicio de bajo nivel. Cuando un ordenador se une al cluster, se considera que el ordenador se ha unido al canal de comunicaciones, por lo tanto «late»; cuando sale, implica que ha dejado el canal de comunicaciones.
Cuando un ordenador deja de «latir» y se considera muerto, se hace una transición en el cluster. La mayoría de los mensajes de manejo del cluster que no son heartbeats se realizan durante estas transiciones.
Los mensajes de Heartbeat se envían por todas las lineas de comunicación a la vez, de esta manera, si una linea de apoyo cae, se avisará de ese problema antes de que la linea principal caiga y no haya una línea secundaria para continuar el servicio.
Heartbeat también se preocupa por la seguridad, permitiendo firmar los paquetes con CRC de 32 bits, MD5 y SHA1. Esto puede evitar el desastre que podría provocarse si un nodo no miembro se enmascarase como nodo miembro del cluster. El problema es que el entorno donde se ejecuta Heartbeat no debe parar nunca y con suerte ese entorno se mantendrá comunicado y funcionando durante años.

Hay varias operaciones de mantenimiento de seguridad que necesitan ser efectuadas en ese tiempo, como pueden ser cambio de claves y de protocolos de autentificación. Heartbeat está preparado para esos cambios disponiendo de ficheros para la configuración.

Heartbeat tiene el problema, si no se dispone de una línea dedicada, aunque ésta sea una línea serie, al tener un tráfico que aunque pequeño es constante, suele dar muchas colisiones con otros tráficos que puedan ir por la misma red. Por ejemplo, openMosix y Heartbeat en una misma red que no tenga gran ancho de banda no funcionan bien, sobre todo si hay bastantes nodos, pues los heartbeats se envían de cualquier nodo a cualquier nodo, por lo que podrían llegar a ser un tráfico voluminoso.
2.1.3. Ldirectord
Pensado especialmente para ser usado junto con LVS, utiliza Heartbeat. Monitoriza que los servidores reales sigan funcionando periódicamente, enviando una petición a una url conocida y comprobando que la respuesta contenga una cadena concreta. Si un servidor real falla, entonces el servidor es quitado del conjunto de servidores reales y será reinsertado cuando vuelva a funcionar correctamente. Si todos los servidores fallan, se insertará un servidor de fallos, que será quitado una vez que los servidores vuelvan a funcionar. Típicamente, este servidor de fallos es el propio host desde el que se realiza el monitoraje.

2.1.4. MON (Service Monitoring Daemon)
Mon es un software para la monitorización del sistema. Mon permite definir una serie de alarmas y acciones a ejecutar cuando un servicio deja de funcionar.
Mon se utiliza ampliamente como componente de monitorización de recursos para Heartbeat.
Mon se compone de dos partes:
Monitores: Son programas (escritos normalmente en Perl) que se ejecutan periódicamente para comprobar el estado de un servicio. Devuelven éxito o fallo. Hay muchos monitores escritos, y para una gran variedad de servicios, y también se pueden escribir monitores nuevos.

El demonio mon: Lee un fichero de configuración, que especifica los nodos/servicios que hay que monitorizar y con que frecuencia. También especifica las acciones (alertas en la terminología de mon) a realizar cuando un nodo/servicio deja de responder o se recupera. Estas alertas también suelen ser scripts en Perl.

2.2. Consideraciones previas, el problema de los datos
En un cluster que ofrezca algún servicio en red se supone que cada servidor debe poseer los mismos datos, por ejemplo, una granja de servidores web debería compartir las mismas páginas web, un cluster de servidores POP debería compartir los mismos mensajes de correo, etc.
Esto crea un problema ¿Cómo se hace que los nodos compartan los mismos datos, sin dar lugar a conflictos?
Como en todo, para este problema van a existir diversas soluciones. La mejor solución dependerá de cuál sea el problema concreto. Por ejemplo, si tenemos un sitio web con un contenido que no cambia a menudo, puede ser suficiente hacer mirroring cada cierto tiempo, si tenemos varios sitios web que cambian continuamente de contenido, esta solución puede no ser tan buena.
De todas formas, para el ejemplo que aquí mostraremos, vamos a suponer que cada servidor