PROCESAMIENTO DISTRIBUIDO, CLIENTE/SERVIDOR Y CLUSTERS

Grupo N11
INTEGRANTES: Aguirre, Roxana LU: 33075 Fernndez, Denis LU: 34881 Fiant, Hernn LU: 30373 Vern, Laura LU: 32830 Espindola Romina LU: 43686 Silva Juan M. LU: 44484

Procesamiento distribuido, cliente/servidor y clster Computacin Cliente/Servidor: El concepto de la computacin Cliente/Servidor y otros conceptos relacionados, estn teniendo cada vez ms importancia en los sistemas de tecnologa de la informacin. Qu es la computacin Cliente/Servidor? La computacin Cliente/Servidor tiene su propia jerga, algunos de los trminos ms comunes utilizados en productos y aplicaciones Clientes/Servidor son: Interfaz de programacin de aplicaciones (API): Conjunto de funciones y programas que permiten a los clientes y servidores intercomunicarse. Cliente: Un elemento de la red que solicita informacin, normalmente un PC o estacin de trabajo. Puede interrogar a una Base de Datos o solicitar informacin de un servidor. Middleware: Un conjunto de controladores, API, y software adicional que mejoran la conectividad entre una aplicacin cliente y un servidor. Base de datos relacional: Una Base de Datos en la que el acceso a la informacin esta restringido por la seleccin de filas que satisfacen todos los criterios de bsqueda. Servidor: Un computador, normalmente una estacin de trabajo de gran potencia, un minicomputador, o un mainframe, que almacena la informacin para los clientes de la red.

Lenguaje Estructurado de Consultas (SQL): Lenguaje desarrollado por IBM y estandarizado por ANSI que permite acceder, crear, actualizar e interrogar Bases de Datos relacionales.

Un entorno Cliente/Servidor est formado por clientes y servidores. Las maquinas cliente son normalmente simples PCs o estaciones de trabajo que proporcionan una interfaz de fcil manejo al usuario final. Las estaciones cliente suele utilizar una interfaz grafica que es ms cmoda para los usuarios, e incluyen el uso de ventanas y del ratn. Algunos ejemplos de estas interfaces son los sistemas operativos Microsoft Windows o Macintosh. Las aplicaciones basadas en el cliente estn diseadas para ser fciles de usar e incluyen aplicaciones tan familiares como la hoja de clculo. Cada Cliente en un entorno Cliente/Servidor proporciona un conjunto de servicios compartidos a los clientes. El tipo ms comn de servidor de base de datos, que normalmente controla una base de datos relacional. El servidor permite a los clientes compartir el acceso a una base de datos y permite el uso de sistemas de computacin de alto rendimiento para gestionar la base de datos. Adems de clientes y servidores, el tercer elemento esencial en un entorno Cliente/Servidor es la red. La computacin Cliente/Servidor normalmente es una computacin distribuida. Los usuarios, las aplicaciones y los recursos se distribuyen en respuesta a los requisitos de trabajo y se unen a travs de una LAN o WAN o internet

Figura Entorno Genrico Cliente/Servidor.

Existen una serie de caractersticas que juntas, diferencian a la filosofa Cliente/Servidor de otros tipos de procesamiento distribuido: Es imperativo que los usuarios tengan aplicaciones de fcil manejo en sus sistemas. Esto proporciona al usuario un gran control sobre el uso de su computadora y da a los gestores del departamento la capacidad de responder a las necesidades locales. A pesar de que las aplicaciones estn dispersas, se realiza un esfuerzo por centralizar las bases de datos corporativas, y muchas funciones de utilidad y de gestin de redes. Esto permite a los gestores de la empresa controlar el capital invertido en computacin y sistemas de informacin y permite interoperabilidad de forma que se unen todos los sistemas. Al mismo tiempo descarga a los departamentos y sucursales de la mayor parte del trabajo de mantener sofisticados sistemas y les permite decidir que interfaz o maquina utilizar para acceder a los sistemas. Existe un compromiso, por parte de las organizaciones de usuarios y vendedores, de mantener un sistema abierto y modular. Esto significa que el usuario tiene ms libertad para seleccionar los productos y que puede combinar equipos de diferentes vendedores. La red fundamental. De esta forma, la gestin y la seguridad de la red tiene prioridad muy alta en la organizacin y funcionamiento de los sistemas de informacin.

APLICACIONES CLIENTE /SERVIDOR: La caracterstica central de la arquitectura cliente / servidor es la ubicacin de las tareas del nivel de aplicacin entre clientes y servidores. La figura 2 ilustra el caso ms general. Tanto en el cliente como en el servidor el software bsico es un sistema operativo que se ejecuta en la plataforma del hardware. Las plataformas y los sistemas operativos del cliente y el servidor pueden ser diferentes. En tanto un cliente particular y un servidor compartan los mismos protocolos de comunicacin, y soporten las mismas aplicaciones. El software de comunicaciones es el que permite interactuar al cliente y servidor. El ejemplo principal es el TCP/IP. El objeto de todo este software de soporte (comunicaciones y sistema operativo) es proporcionar una base para las aplicaciones distribuidas. Las funciones reales de la aplicacin pueden repartirse entre cliente y servidor de forma que se optimen los recursos de la red y de la plataforma, as como la capacidad de los usuarios para realizar varias tareas y cooperar el uno con el otro en el uso de recursos compartidos. En algunos casos, estos requisitos dictan que el grueso del software de la aplicacin se ejecute en el servidor y, en otros casos, la mayor parte de la lgica de la aplicacin se ubica en el cliente.

Un factor esencial para el xito de un entorno cliente / servidor es la manera en que el usuario interacta con el sistema como un todo. De esta forma, el diseo de la interfaz de usuario de la mquina es vital. En la mayora de los sistemas cliente / servidor, se da prioridad en ofrecer una interfaz de usuario grfico que sea fcil de utilizar y de aprender, pero potente y flexible. As pues, se puede pensar en un mdulo de servicios de presentacin en el puesto de trabajo del cliente, responsable de ofrecer una interfaz fcil de usar a las aplicaciones distribuidas disponibles en el entorno. En la mayora de los sistemas cliente / servidor, se hace un gran hincapi en ofrecer una interfaz de usuario grafico (GUI, Grafica l User Interfaz).

Estacin de trabajo cliente

Servidor

Figura 2: Arquitectura genrica Cliente/Servidor Aplicaciones de base de datos: Como el ejemplo que ilustra el concepto de divisin de la lgica de una aplicacin entre cliente y servidor considrese la familia ms comn de aplicaciones cliente / servidor: aquellas que utilizan base de datos relacinales. La interaccin entre el cliente y el servidor se hace en forma de transacciones, donde el cliente realiza una peticin a la base de datos y recibe una respuesta de aquella. El servidor mantiene la base de datos mediante complejos sistemas gestores de base de datos.

En las maquinas clientes se pueden guardar una variedad de aplicaciones que hagan uso de la base de datos. El software que enlaza al cliente con el servidor es el que le permite al cliente realizar peticiones de acceso a la base de datos del servidor (Ej. SQL). Estacin de trabajo Cliente Servidor

Figura Arquitectura Cliente/Servidor para aplicaciones de base de datos. Supongamos que contamos con un servidor que solo se debe ocupar de la gestin de la base de datos -una base de datos de 1 milln de archivos por ej.- y que toda la lgica de la aplicacin el software de tratamiento numrico u otras clases de anlisis de datos- resida en el cliente. Y el cliente realiza una serie de consultas, que da como resultados 1 solo archivo.

Figura Uso de una base de datos en un entorno Cliente/Servidor

Esta aplicacin se adapta bien a la arquitectura cliente / servidor por dos razones: 1. Contener la base de datos requiere de un disco grande o una serie de discos, una PC y una arquitectura de E/S de alta velocidad. Esta potencia y capacidad no es necesaria, y es demasiado cara, para una estacin de trabajo o PC de un usuario. 2. Mover todo el archivo de la base de datos al cliente para realizar la bsqueda introducir una carga de trfico demasiado grande en la red. Por lo tanto no es suficiente con que el servidor solo sea capaz de recuperar archivos en nombre del cliente, el servidor debe disponer de la lgica de la base de datos que permita realizar bsquedas de parte del cliente. Ahora consideremos que el cliente realiza una sola consulta que da como resultado la transmisin de 300.000 archivos por la red, esto es inaceptable. Una solucin al problema que conserva la arquitectura cliente / servidor es mover parte de la lgica de la aplicacin al servidor, que permita a este realizar anlisis de datos, as como recuperacin y anlisis de datos.

CLASES DE APLICACIONES CLIENTE / SERVIDOR: Dentro del entorno general cliente / servidor se dispone de una gama de posibles implementaciones que dividen el trabajo entre el cliente y el servidor de manera diferente. 1. Procesamiento basado en el host: el proceso basado en host(maquina central) es en el cual casi todo el tratamiento se realiza en el computador central. La interfaz de usuario consiste a menudo en un terminal tonto, incluso si el usuario emplea un microprocesador el puesto de usuario se limita en general al papel de emulador de terminales. 2. Proceso basado en servidor: es aquel en que el servidor es bsicamente responsable de ofrecer una interfaz de usuario grafica, mientras casi todo el tratamiento lo hace el servidor. La razn fundamental que subyace en dichas configuraciones es que los puestos de trabajo se adaptan mejor a una interfaz amigable y que las bases de datos y las aplicaciones pueden mantenerse fcilmente en sistemas centrales. Este tipo de configuraciones no se presta a ganancias significativas. 3. Proceso basado en el cliente: en el otro extremo, casi todo el proceso de la aplicacin puede hacerse en el cliente, con la excepcin de las rutinas de validacin de datos y otras funciones lgicas de la base de datos que se realizan mejor en

el servidor. Permite al usuario utilizar aplicaciones a la medida de sus necesidades locales. 4. Proceso cooperativo: el proceso de la aplicacin se lleva a cabo de forma optimizada, aprovechando la potencia de las maquinas cliente y servidora y la distribucin de los datos. Esta configuracin es ms compleja de instalar y mantener, pero a largo plazo, este tipo de configuracin puede ofrecer una mayor ganancia de productividad del usuario y una mayor eficacia de la red. Los modelos con las configuraciones en las que gran parte de la carga esta en el cliente son llamados cliente grueso, soportan entre 25 y 150 usuarios. El mayor beneficio de esta configuracin es que saca provecho del computador de escritorio, descargando a los servidores del procesamiento de aplicaciones, hacindolos ms eficientes y disminuyendo la posibilidad de que sean un cuello de botella. Si embargo existen barios inconvenientes pues la utilizacin de mas funciones sobrecarga rpidamente la capacidad de las maquinas de escritorio. Esta configuracin es difcil de mantener, actualizar o reemplazar aplicaciones distribuidas entre cintos de maquinas de escritorio. Los modelos con las configuraciones en las que la menor parte de la carga esta en el cliente son llamados cliente delgado, este enfoque casi imita al enfoque de host centralizado.

ARQUITECTURA CLIENTE / SERVIDOR DE TRES CAPAS: La arquitectura tradicional cliente / servidor implica dos niveles o capas: una capa cliente y un servidor. En la arquitectura de tres capas el software de aplicacin est distribuido en tres tipos de maquinas: una maquina de usuario, un servidor de capa intermedia y servidor final (Backend). La mquina de usuario es la mquina de cliente y el modelo de tres capas utiliza, generalmente, un cliente delgado. Las maquinas de capa intermedia son esencialmente pasarelas entre los clientes delgado y una variedad de servidores finales de base de datos, pueden convertir protocolos y traducir un tipo de consulta de base de datos a otro. Adems puede mezclar e integrar resultados de distintas fuentes de datos. Por ltimo puede servir como pasarela entre aplicaciones de computador de escritorio y antiguas aplicaciones finales actuando de mediadoras entre los dos mundos.

La interaccin entre el servidor de capa intermedia y el servidor final tambin sigue el modelo cliente / servidor. De esta forma el sistema de capa intermedia acta a la ves como cliente y como servidor.

CONSISTENCIA DE LA CACH DE ARCHIVOS Cuando se utiliza un servidor de archivos, el rendimiento de la E/S referente a los accesos locales a archivos puede degradarse por causa del retardo introducido por la red. Para reducir esta carga, los sistemas individuales pueden usar caches de archivos para almacenar los registros a los que se ha accedido hace poco. Cuando un proceso realiza un acceso a archivo, la peticin es cursada, en primer lugar, a la cach del puesto de trabajo del proceso. Si no satisface la peticin, se pasa al disco local o al servidor donde se almacena el archivo. Una vez en el servidor, se examina primero su cach y si se produce un fallo de acceso, se acceder al disco del servidor. Se suele utilizar un procedimiento de doble cach para reducir el trfico de comunicaciones (cach del cliente) y la E/S a disco (cach del servidor).

Figura Cache de ficheros distribuida en Sprite. MIDDLEWARE El desarrollo y utilizacin de los productos Cliente/Servidor ha sobrepasado con mucho los esfuerzos para estandarizar todos los aspectos de la computacin distribuida, desde la capa fsica hasta la capa de aplicacin. Esta falta de estndares hace difcil implementar una configuracin cliente/servidor integrada y multivendedor en toda la empresa. Este problema de interoperabilidad debe ser resuelta ya que gran parte del beneficio del enfoque cliente/servidor esta unido a su modularidad y la capacidad de combinar plataformas y aplicaciones para proporcionar una solucin de negocios. Entonces el Middleware es un conjunto de interfaces y protocolos estndares de comunicacin. Con interfaces estndares de programacin, es fcil de implementar una misma aplicacin en una variedad de tipos de servidores y de puestos de trabajo. Esta tiene un beneficio para los clientes puesto que estos compran aplicaciones no servidores, los clientes solo elegirn entre aquellos servidores donde se ejecuten las aplicaciones que ellos deseen. Se necesitarn protocolos estndares para enlazar las distintas interfaces de servidor con los clientes que necesiten acceder a ellos. Existe una gran variedad de paquetes middleware, simples o complejos. Todos tienen en comn la capacidad de ocultar las complejidades y diferencias de los diferentes protocolos de red y sistemas operativos.

Arquitectura Middleware Cliente/Servidor El papel que cumple el componente middleware depender del estilo del proceso distribuido que se utilice. Estacin de trabajo Cliente
Servicio de presentacin Lgica de aplicacin Middleware Software de aplicacin Sistema operativo cliente Plataforma hardware

Servidor
Middleware Software de comunicaciones Servicios de Aplicacin

Sistema operativo servidor Plataforma hardware

Figura -Papel del middleware en la arquitectura cliente/servidor En el middleware existen componentes de cliente y servidor. La funcin bsica del middleware es hacer que una aplicacin o usuario del cliente acceda a una serie de servicios del servidor sin preocuparse de las diferencias entre servidores. Considerando un rea especfica de aplicacin, se supone que el SQL brinda una forma estndar de acceso a una base de datos relacional tanto a usuarios o aplicaciones locales como remotos. As mismo, muchos fabricantes de base de datos relacionales, aunque tambin soportan SQL le han agregado sus propias ampliaciones, logrando de esta forma una diferenciacin de productos, pero a la vez posibles incompatibilidades. Cuando un usuario necesite acceder a determinados registros, no deber preocuparse del fabricante de la base de datos que contiene los registros que necesite. El middleware proporciona una capa software que permite un acceso uniforme a estos sistemas diferentes. Es interesante considerar el papel del middleware desde un punto de vista lgico ms que desde la implementacin. El middleware permite cumplir la promesa del proceso distribuido. El sistema distribuido entero puede verse como un conjunto de aplicaciones y recursos disponibles para los usuarios, debido a lo cual estos no necesitan preocuparse de la ubicacin de los datos ni de la ubicacin de las aplicaciones. Todas las aplicaciones operan sobre una interfaz uniforme de programacin de aplicaciones (API). El middleware, que atraviesa todas las plataformas clientes y servidoras, es el responsable de encaminar las peticiones de los

clientes al servidor API. Esta instalacin es un ejemplo de cmo se aplica el middleware para integrar productos dispares, en este caso, se usa el middleware para eludir las incompatibilidades de redes y sistemas operativos. Una red central conecta redes DECnet. Novell y TCP/IP. El middleware, que se ejecuta en cada componente de la red, asegura que todos los usuarios de la red disponen de un acceso transparente a las aplicaciones y los recursos de cualquiera de las tres redes. Aunque hay una amplia variedad de productos del middleware, estos se basan normalmente en uno de los mecanismos bsicos: el paso de mensajes o llamada a procedimiento remoto.
Aplicacin Aplicacin

API

Middleware (Servicios del Sistema Distribuido)

Interfaz con la plataforma

Plataforma * S.O * Hardware

Plataforma * S.O * Hardware

Figura Visin lgica del middleware PASO DISTRIBUIDO DE MENSAJES En los sistemas de procesos distribuidos reales se suele dar el caso de que los computadores no comparten una memoria principal: cada una es un sistema aislado. Por lo tanto, no es posible, emplear tcnicas de comunicacin entre procesadores basadas en memoria compartida, como son los semforos y el uso de un rea de memoria comn. En su lugar, se usa tcnicas basadas en el paso de mensajes. Entre los procedimientos ms usuales est la aplicacin directa de los mensajes, tal como se hace en un sistema nico. El segundo es una tcnica distinta que se basa en el paso de mensajes como funcin bsica: la llamada a procedimiento remoto. Paso distribuido de mensajes para implementar la funcionalidad cliente/servidor. Un proceso cliente solicita un servicio y enva, a un proceso servidor, un mensaje que contiene un peticin dl servicio. El proceso servidor satisface la peticin y enva un mensaje de respuesta. En su forma ms simple, slo se necesita 2 funciones: Send y Receive. La

funcin Send debe especificar un destino e incluir el contenido del mensaje. La funcin Receive dice de quien se desea recibir mensajes (incluyendo a todos) y proporciona un almacenamiento intermedio donde se guardar el mensaje. Los procesos hacen uso de los servicios de un mdulo de paso de mensajes. Las solicitudes de servicios pueden expresarse en forma de primitivas y parmetros. Una primitiva especifica la funcin a realizar y los parmetros se usan para pasar datos e informacin de control. El formato real de las primitivas depende del software de paso de mensajes. Pueden ser llamadas a procedimientos o mensajes a un proceso que forme parte del sistema operativo.

a) Middleware orientados a mensajes (con cola de mensajes)

b) Llamada a procedimiento remoto

Figura: Mecanismos middleware

Figura: Primitivas bsicas de paso de mensajes. La primitiva Send la utiliza el proceso que quiere enviar el mensaje. Sus parmetros son el identificador del proceso de destino y el contenido del mensaje. El mdulo de paso de mensajes construir una unidad de datos que incluya estos dos elementos. Esta unidad de datos se enva a la mquina que alberga el proceso de destino mediante algn tipo de servicio de comunicaciones, como TCP/IP. Cuando se recibe la unidad de datos en el sistema de destino, se encaminar, mediante el servicio de comunicaciones, hacia el mdulo de paso de mensajes. Este mdulo examina el campo IdProceso y almacena el mensaje en el buffer de dicho proceso. En este escenario, el proceso receptor debe anunciar su intencin de recibir mensajes, designando un rea de almacenamiento intermedio e informando al mdulo de paso de mensajes por medio de una primitiva Receive. Una solucin alternativa consiste en no exigir dicho anuncio. En su lugar, cuando el mdulo de paso de mensajes, avisar al proceso de destino con algn tipo de seal de recepcin y despus har que el mensaje recibido est disponible en un buffer compartido. FIABLE & NO FIABLE: Un servicio de paso de mensajes fiable que garantiza la entrega, si es posible. Dicho servicio deber hacer uso de un protocolo de transporte fiable o de alguna lgica similar y llevara a cabo control de errores, acuse de recibo, retransmisin y reordenacin de mensajes desordenados. Como la entrega est garantizada, no es necesario hacer que el proceso emisor

sepa que se entreg el mensaje. Sin embargo, puede ser til proporcionar un acuse de recibo al proceso emisor de manera que se entere que ya se ha entregado. En cualquier caso, si el servicio falla al completar la entrega, se notificar de esta falla al proceso emisor. En el otro extremo, el servicio de paso de mensajes puede enviar simplemente el mensaje a la red de comunicaciones sin informar de su xito o de su fracaso. Esta alternativa reduce enormemente la complejidad y la sobrecarga de proceso y de comunicaciones en el servicio de paso de mensajes. Las aplicaciones que necesiten confirmacin de que se han enviado un mensaje pueden usar mensajes de repeticin y respuesta para cumplir con tal requisito. BLOQUEANTE FRENTE A NO BLOQUEANTE: Con primitivas no bloqueantes, o asncronas, un proceso no queda suspendido como resultado de un Send o un Receive. De esta forma, cuando un proceso emita una primitiva Send, el sistema operativo le devolver el control tan pronto como el mensaje se haya puesto en cola para su transmisin o se haya hecho una copia. Si no se hace copia, cualquier cambio que realice el emisor en el mensaje antes de la transmisin, o durante la misma, se har bajo la responsabilidad del mismo. Cuando el mensaje se haya trasmitido o se haya copiado a un lugar seguro para su posterior trasmisin, se interrumpe al proceso emisor para informarle de que el buffer del mensaje puede reciclarse. De forma similar Receive no bloqueante lo emite un proceso para despus seguir ejecutndose. Cuando llega un mensaje se informa al proceso mediante interrupcin o bien este puede comprobar peridicamente su estado. Las primitivas no bloqueantes ofrecen un empleo eficiente y flexible del servicio de paso de mensajes. Las desventajas de este enfoque es que los programas que emplean esta primitivas son difciles de probar y depurar. Las secuencias irreproducibles dependientes del tiempo pueden originar problemas sutiles y complicados. La otra alternativa es emplear primitivas bloqueantes, o sncronas. Un Send bloqueante no devuelve el control al proceso emisor hasta que el mensaje se haya trasmitido (servicio no fiable) o hasta que el mensaje se haya enviado y obtenido un acuse de recibo (servicio fiable).Un Receive bloqueante no devuelve el control hasta ubicado en el buffer asignado. LLAMADAS A PROCEDIMIENTO REMOTO Una variante del modelo bsico de paso de menaje es la llamada a procedimiento remoto (RPC).

Es un mtodo comn muy aceptado actualmente para encapsular la comunicacin en un sistema distribuido. Lo fundamental de la tcnica es permitir que programas de mquinas diferentes interacten mediante la semntica de llamadas retorno a simples procedimientos, como si los dos programas estuvieran en la misma mquina. Es decir, se va a usar la llamada a procedimiento para acceder a servicios remotos. La popularidad de este enfoque se debe a las siguientes ventajas. La llamada a procedimiento es una abstraccin muy usada, aceptada y bien comprendida. El empleo de llamadas a procedimientos remoto permite que las interfaces remotas se especifiquen como un conjunto de operaciones con nombre y de un tipo determinado. De este modo, la interfaz puede documentarse de forma clara y los problemas distribuidos pueden comprobarse estadsticamente para detectar errores tipo. Como la interfaz es estndar y est definida de forma precisa, el cdigo de comunicaciones de una aplicacin puede generarse automticamente. Como la interfaz es estndar y est definida de forma precisa, los desarrolladores de software pueden escribir mdulos clientes y servidores que pueden trasladarse ente computadores y sistemas operativos con pocas modificaciones.

El mecanismo de las llamadas a procedimiento remoto puede considerarse como un refinamiento del paso de mensajes fiables y bloqueantes. El programa llamador realiza una llamada normal a un procedimiento con los parmetros situados en su mquina. Por ejemplo: CALL P(X,Y) Donde: P = nombre del procedimiento. X = argumentos pasados. Y = valores devueltos.

El hecho de que se intente ejecutar un procedimiento remoto de otra mquina puede resultar o no trasparente al usuario. El espacio de direcciones del llamador debe incluir un procedimiento P de presentacin, o debe enlazarse dinmicamente en el momento de la llamada. Este procedimiento crea un mensaje que identifica al procedimiento llamado, e incorpora los parmetros. Luego enva el mensaje y queda en espera de una respuesta. Una vez recibida la respuesta, el procedimiento de

presentacin retorna al programa llamador, proporcionando los valores devueltos. En la mquina remota, se asocia al procedimiento invocado otro procedimiento de presentacin. Cuando llega un mensaje se examina y se genera una llamada local CALL P(X,Y). Se llama a este procedimiento de forma local y los supuestos sobre dnde encontrar los parmetros, el estado de pila y otros, son idnticos al caso de una llamada local. PASO DE PARMETROS: La mayora de los lenguajes de programacin permiten pasar parmetros como valores (llamada por valor) o como un puntero a la ubicacin que contiene el valor (llamada por referencia). La llamada por valor es sencilla para una llamada a procedimiento remoto: los parmetros simplemente se copian en el mensaje y se envan al sistema remoto. Las llamadas por referencia son ms difciles de implementar. Hace falta un nico puntero para cada objeto, vlido en todo el sistema. El costo de este servicio puede ser muy alto y no valer la pena. REPRESENTACION DE LOS PARAMETROS: Otra cuestin es cmo representar los parmetros y los resultados en los mensajes. Si el programa llamador y el llamado estn escritos en el mismo lenguaje de programacin tienen el mismo tipo de mquina y el mismo sistema operativo, los requisitos de representacin no representan un problema. Pero si existen diferencias en estos aspectos, habr diferencias en la manera en que se representan los datos numricos e incluso los textos. Si se emplea una arquitectura de comunicaciones, este problema ser resuelto por el nivel de presentacin. Pero el costo de estas arquitecturas, ha llevado al diseo de servicios de llamada a procedimiento remoto que ofrecen servicios de comunicaciones bsicos. En este caso la conversin la realiza el servicio de llamada a procedimiento remoto. La mejor solucin para este problema es ofrecer un formato estndar para los objetos comunes, como los enteros, nmeros en coma flotante, caracteres y cadenas de caracteres. As los parmetros propios de cualquier mquina pueden convertirse a la representacin estndar.

ENLACE CLIENTE / SERVIDOR: Especifica la forma en que se establecer la relacin entre un procedimiento remoto y el programa llamador. Un enlace se forma cuando dos aplicaciones establecen una conexin lgica y estn preparadas para intercambiar rdenes y datos.

Los enlaces no permanentes: suponen que la conexin lgica se establece entre dos procesos en el momento de la llamada remota y que la conexin desaparece ni bien se devuelvan los valores. Como una conexin requiere mantener informacin de estado en los dos extremos, consume recursos. El estilo no persistente se utiliza para conservar esos recursos. Por otro lado el costo de establecer las conexiones hace que los enlaces no persistentes no sean adecuados para procedimientos remotos que se invocan con frecuencia. Con enlaces persistentes, una conexin establecida para una llamada a procedimiento remoto, se mantiene despus que el procedimiento termina. Esta conexin podr ser utilizada para futuras llamadas a procedimientos remotos; pero esta finalizar si transcurre un determinado perodo de tiempo y no es utilizada para aplicaciones que realizan llamadas a procedimientos repetidamente, el enlace persistente, mantiene la conexin lgica y permite que una secuencia de llamadas y retornos utilice la misma conexin.

SINCRONOS & ASINCRONOS: Las llamadas a procedimiento remoto tradicionales son sncronas, lo que requiere que el proceso llamador espere hasta que el proceso llamado devuelva un valor (RPC sncrona). La RPC sncrona no es capaz de explotar por completo el paralelismo inherente a las aplicaciones distribuidas; esto limita el tipo de interaccin que las aplicaciones distribuidas pueden realizar y as obtienen un rendimiento menor. Para ofrecer una mayor flexibilidad se implementaron varios servicios de RPC asncrona que consiguen un grado mayor de paralelismo. Las RPC asncronas no bloquean al llamador, permitiendo que la ejecucin de los clientes contine localmente y en paralelo con la llamada al servidor. Una aplicacin de las RPC asncronas es hacer que un cliente invoque repetidamente a un servidor, generando una serie de peticiones a la vez. La sincronizacin del cliente y el servidor puede conseguirse de dos formas: 1. una aplicacin de nivel superior en el cliente y en el servidor puede iniciar el intercambio y comprobar al final que se han llevado a cabo todas las acciones solicitadas.

2. un cliente puede emitir una cadena de RPC asncronas, seguidas de una ltima RPC sncrona. El servidor responder a la RPC sncrona despus de terminar todo el trabajo solicitado por las RPC asncronas. En algunos esquemas las RPC asncronas no exigen una respuesta al servidor, otros requieren o permiten una respuesta, pero el llamador no queda a la espera de la misma.

MECANISMOS DE ORIENTACIN A OBJETOS: La tecnologa de orientacin a objetos se hace importante en el diseo de los sistemas distribuidos, lo diseadores cliente/servidor han empezado a abarcar este enfoque. Con este enfoque los clientes y servidores envan mensajes y reciben respuestas de objetos. Un cliente que necesita un servicio enva una peticin a un agente de servicio de objetos, este acta como un directorio que contiene todos los servicios remotos disponibles en la red. El agente llama al objeto apropiado y le pasa los datos. Entonces el objeto remoto atiende la peticin y responde al agente, el que devuelve la respuesta al cliente. El xito del enfoque de orientacin a objetos depende de la estandarizacin del mecanismo de objetos. Pero existen varios rivales en esta rea: uno es COM (Modelo Comn de Objetos) de Microsoft. Otro es el CORBA (Arquitectura Comn Intermedia de Peticin de Objetos), respaldada por IBM, Aplple, Sun y otros fabricantes. CLUSTERS Los Clsters son una alternativa al Multiproceso Simtrico (SMP) como un mtodo de proporcionar un alto rendimiento y alta disponibilidad y son particularmente atractivas para aplicaciones de servidor. Podemos definir un Clster como un grupo de computadoras completos interconectadas que trabajan juntos como un recurso de proceso unificado que puede crear la ilusin de ser una mquina. El trmino computadoras completos se refiere a un sistema que puede ejecutarse por s mismo, independiente de la agrupacin; a cada uno de los computadores de un clster se la llama, normalmente, nodo. Las cuatro ventajas, tambin consideradas objetivos o requisitos de diseo, son: Escalabilidad Absoluta: Es posible crear clster que supere la gran potencia de incluso la mayor de las mquinas. Un clster puede

tener decenas o incluso centenas de maquinas, cada una de ellas un multiprocesador. Escalabilidad incremental: Un clster se configura de tal forma que es posible aadir sistemas nuevos al clster en pequeos incrementos. As pues, un usuario puede empezar con un sistema modesto y ampliarlo a medida que las necesidades crezcan, sin tener que pasar por una actualizacin importante en la que se sustituya el sistema pequeo existente por un sistema mayor. Alta disponibilidad: puesto que cada uno de los nodos del clster es un computador autnomo, el fallo de un nodo no implica la prdida de servicio. En muchos productos, el software gestiona automticamente la tolerancia a los fallos. Relacin precio/ prestaciones: A travs del uso de bloques de construccin es posible hacer un clster con igual o mayor poder computacional que una nica maquina, con mucho menor coste.

CONFIGURACIN DE AGRUPACIONES: Los clster se clasifican de varias y muy diferentes formas. Quizs la clasificacin ms simple se basa en si los computadores del clster comparten el acceso a los mismos discos. La figura 1 (Servidor en espera sin disco compartido) muestra un clster de dos nodos en donde la nica interconexin se realiza por medio de un enlace de alta velocidad que se puede utilizar para el intercambio de mensajes y para coordinar la actividad del clster. El enlace puede ser una LAN compartida con otros computadores externos a la agrupacin, o puede ser un servicio de interconexin dedicado, donde un computador o ms del clster tendrn un enlace LAN o WAN de manera que exista una conexin entre el servidor del clster y los sistemas clientes remotos. Cada uno de los computadores ha sido representado como un multiprocesador, debido a que mejora el rendimiento y la disponibilidad. En la figura 2 (Disco compartido), la otra alternativa es un clster con discos compartidos. En este caso, generalmente existe un enlace de mensajes entre nodos. Adems, hay un subsistema de disco directamente enlazado a varias computadoras del clster. En esta figura, el subsistema de disco comn es un sistema RAID. La utilizacin de esta tecnologa de discos es comn en las agrupaciones para que la alta disponibilidad lograda por la presencia de varios computadores no se vea comprometida por un disco compartido, que es nico punto de fallo.

Figura 1: Servidor en espera sin disco compartido

Figura 2: Disco compartido Un mtodo habitual, ms antiguo, es el de espera pasiva consiste simplemente en hacer que u computador gestione toda la carga de proceso mientras que otro computador permanece inactivo, esperando para hacerse cargo en caso de fallo de la primaria. Para coordinar las mquinas, el sistema activo o primario enva peridicamente un mensaje de latido a la mquina en espera. Si estos mensajes dejan de llegar, el computador en espera supone que el servidor primario ha fallado y se pone a funcionar. Este mtodo aumenta la disponibilidad, pero no mejora el rendimiento. Es ms, si la nica informacin que se intercambian los dos sistemas es un mensaje de latido, y si los dos sistemas no comparten discos comunes, el computador en espera ofrece una funcionalidad de respaldo pero no tiene acceso a las bases de datos gestionadas por las primarias. El pasivo en espera no se conoce normalmente como clster. El trmino clster se reserva para mltiples computadores interconectados que realizan todo proceso activo mientras mantienen la imagen externa de un solo sistema. Para hacer referencia este tipo de configuracin generalmente se utiliza el trmino secundaria activa. Se pueden identificar tres mtodos de agrupaciones:

Servidores separados: cada computador es un servidor separado, con sus propios discos y sin compartimientos de discos entre los sistemas (Figura 1). Este esquema proporciona un alto rendimiento as como una alta disponibilidad. En este caso, se necesita algn tipo de gestin o software de planificacin para asignar las solicitudes entrantes de los clientes a los servidores para que as la carga est equilibrada y se logre una alta utilizacin. Sera deseable disponer de una capacidad de tolerancia a los fallos, lo que significa que si un computador falla cuando est ejecutando una aplicacin, otro computador de la agrupacin puede hacerse cargo de la misma y terminarlo. Para que esto ocurra los datos deben copiarse constantemente entre los sistemas, de forma que cada uno tenga acceso a los datos actuales de los otros. La sobrecarga de este intercambio de datos asegura una alta disponibilidad a costa de penalizar el rendimiento.

Compartir nada: los discos comunes se dividen en volmenes y cada volumen pertenece a un nico computador. Si ese computador falla, la agrupacin se debe reconfigurar para asociar los volmenes del computador que ha fallado a otros computadores.

Compartir discos: mltiples computadores comparten los mismos discos al mismo tiempo, para que cada computador tenga acceso a todos los volmenes de todos los discos. Este enfoque necesita del uso de algn tipo de funcin de bloqueo para garantizar que slo puede acceder a los datos un solo computador cada vez.

Mtodo de agrupaci Descripcin n Un servidor secundario se hace cargo si falla el servidor primario.

Ventajas

Limitaciones

Espera pasiva

Secundari a activa

El servidor secundario tambin se utiliza para tareas de proceso.

Servidores separados

Servidores conectado s a discos

Servidores compartie ndo discos

Los servidores separados tienen sus propios discos. Los datos se copian continuamente del servidor primario al secundario. Los servidores estn conectados a Reduce la Generalmente los mismos discos, sobrecarga en el necesita pero cada servidor servidor y el uso tecnologa RAID tiene su propio de la red debido o de discos disco. Si un servidor a la eliminacin espejos para falla, sus discos de las compensar el pasan a estar a operaciones de riesgo de un cargo de otro copia. fallo de disco. servidor. Requiere Baja la software de sobrecarga en Mltiples servidores gestin de el servidor y uso comparten acceso bloqueos. de la red. simultneo a los Normalmente se Reduce el riesgo discos. utiliza con de cada por un tecnologa RAID fallo de disco. o discos espejos.

Alto costo porque el servidor Sencillo de secundario no implementar. est disponible para otras tareas de proceso. El costo es reducido porque los servidores Incremento de la secundarios se complejidad. pueden utilizar para el proceso. Incrementa la sobrecarga en el servidor y el uso Alta de la red debido disponibilidad. a las operaciones de copia.

ASPECTOS DISEO DE LOS SISTEMAS OPERATIVOS: Para una completa exploracin de la configuracin del hardware de una agrupacin se necesitan algunas mejoras de un sistema operativo nico. GESTION DE FALLOS: La forma en que se gestionan los fallos depende del mtodo de clster utilizado. (Tabla superior). En general, para tratar los fallos se pueden seguir dos enfoques: agrupaciones de alta disponibilidad y clster tolerantes a los fallos. Un clster de alta disponibilidad ofrece una alta probabilidad de que todos los recursos estn siendo utilizados. Si se produce un fallo, como una cada del sistema o la prdida de un volumen de disco, se pierden las consultas en progreso. Cualquier consulta perdida, si se retoma, ser atendida por un computador diferente del clster Sin embargo, el sistema operativo del clster no garantiza el estado de las transacciones parcialmente ejecutadas. Debera ser gestionada en el nivel de aplicacin. Un clster tolerante a fallos garantiza que los recursos siempre van a estar disponibles. Esto se logra mediante el uso de discos compartidos redundantes y de mecanismos de respaldo para transacciones sin confirmar y transacciones completadas y confirmadas. La funcin de intercambiar una aplicacin y los datos de un sistema fallido por un sistema alternativo del clster se denomina resistencia a fallos (failover). La restauracin de aplicaciones y de datos al sistema original una vez que se ha reparado, se denomina restauracin de fallos (fail back). La restauracin de fallos puede ser automtica, pero es deseable slo si se ha solucionado realmente el problema y es improbable que vuelva a ocurrir. Si no fuera as, una restauracin de fallos automtica puede originar fallos posteriores en los recursos al ir y volver entre computadores, dando lugar a problemas en el rendimiento y en la recuperacin. EQUILIBRO DE CARGA Un clster requiere una capacidad eficaz para balancear la carga entre los computadores disponibles. Esto incluye el requisito de que un clster sea incrementalmente escalable. Cuando se aade un nuevo computador al clster, la funcin de equilibrio de carga debera incluir automticamente este computador en la planificacin de aplicaciones. Los mecanismos

middleware necesitan reconocer qu servicios pueden aparecer en los diferentes miembros del clster y pueden migrar de un miembro a otro. PROCESO PARALELO En algunos casos, el uso eficiente de los clster necesita ejecutar software desde una sola aplicacin en paralelo. Para este problema se proporcionan tres enfoques generales: Compilador paralelo: un compilador paralelo determina, en tiempo de compilacin, qu partes de la aplicacin se pueden ejecutar en paralelo. Estas se dividen para asignarlas a distintos computadores del clster. El rendimiento depende de la naturaleza del problema y de lo bueno que sea el diseo del compilador. Aplicaciones paralelas: el programador disea la aplicacin desde el principio para ejecutar en una agrupacin y utiliza el paso de mensajes para mover datos, cuando sea necesario, entre los nodos del clster. Esto aumenta la carga sobre el programador pero puede ser la mejor aproximacin para explotar las agrupaciones en algunas aplicaciones. Computacin paramtrica: este enfoque slo se puede utilizar si el centro de la aplicacin es un algoritmo o programa que debe ejecutarse muchas veces, cada vez con un conjunto diferente de condiciones y parmetros. Para que este enfoque sea efectivo, se necesitan herramientas de procesamiento paramtrico para organizar, ejecutar y gestionar los trabajos en el orden adecuado.

ARQUITECTURA DE UN CLUSTER Una tpica arquitectura del clster (Figura Arquitectura de computacin Clster ) es aquella en la cual cada computador est conectado mediante una LAN de alta velocidad o hardware de interconexin. Cada una es capaz de funcionar independientemente. Adems, en cada computador hay instalada una capa de middleware para permitir el funcionamiento de la agrupacin. El middleware de la agrupacin ofrece una imagen unificada del sistema al usuario, conocida como imagen de sistema nico. El middleware es tambin responsable de ofrecer una alta disponibilidad, mediante el balanceo de carga y respondiendo a los fallos en los componentes individuales. Los siguientes servicios y funciones son deseables en un clster: nico punto de entrada: un usuario se identifica en el clster y no en una determinada computadora nica jerarqua de archivos: el usuario ve una nica jerarqua de directorios bajo el mismo directorio raz.

 nico punto de control: existe una estacin de trabajo por defecto utilizada para la gestin y controlar el clster. nica gestin de red virtual: cualquier nodo puede acceder a cualquier punto del clster, incluso si la configuracin del clster tiene mltiples redes interconectadas. Se opera sobre una nica red virtual. nico espacio de memoria: la memoria compartida distribuida permite que los programas compartan variables. nico sistema de gestin de trabajos: con un planificador de trabajos en el clster, un usuario puede enviar un trabajo sin especificar al computador que lo va a ejecutar. nica interfaz de usuario: una interfaz grfica comn da soporte a todos los usuarios, independientemente de la estacin de trabajo que utilicen. nico espacio de E/S: cualquier nodo puede acceder de forma remota a cualquier dispositivo de disco o dispositivo perifrico sin conocer su ubicacin fsica. Puntos de comprobacin: esta funcin guarda peridicamente el estado del proceso y los resultados intermedios del procesamiento, para permitir la recuperacin despus de un fallo. Migracin de procesos: esta funcin permite el equilibrio de la carga. Los cuatro ltimos elementos de la lista anterior aumentan la disponibilidad de la agrupacin. Los puntos restantes tienen relacin con ofrecer una imagen de sistema nico. Adems, una agrupacin puede incluir herramientas software para permitir la ejecucin eficiente de programas capaces de ejecutarse en paralelo. La siguiente figura es un claro ejemplo de ello.

Figura Arquitectura de computacin Clster

CLUSTER FRENTE A SMP Tanto los clster como los multiprocesadores simtricos ofrecen una configuracin de mltiples procesadores para dar soporte a aplicaciones de alta demanda. La ventaja principal del enfoque SMP es que ms que fcil de gestionar y de configurar que un clster. SMP es ms cercano al modelo original del procesador nico para el que estn escritas casi todas las aplicaciones. El cambio principal que se requiere para pasar de un monoprocesador a un SMP es la funcin de planificacin. Otra ventaja del SMP es que, generalmente, ocupa menos espacio fsico y necesita menos potencia que una agrupacin de las mismas caractersticas. Una ltima ventaja importante es que los productos SMP estn ms establecidos y son ms estables. Sin embargo, los clster son superiores en trminos de disponibilidad, puesto que todos los componentes del sistema pueden hacerse muy redundantes. SERVIDOR CLUSTER DE WINDOWS 2000 El Servidor de clster de Windows 2000 (W2K) es un clster que sigue el esquema compartir nada, en el que cada volumen de disco y otros recursos pertenecen a un solo sistema al mismo tiempo. El diseo del Servidor de clster e W2K utiliza los siguientes conceptos: Servicio de clster coleccin el conjunto de software de cada nodo que gestiona toda actividad especfica de la agrupacin. Recurso: un elemento gestionado por el servicio de agrupacin. Todos los recursos son objetos que representan los recursos reales del sistema, incluyendo dispositivos de hardware fsicos tales como unidades de disco y tarjetas de red, adems de elementos lgicos tales como volmenes lgicos de disco, direcciones TCP/IP, aplicaciones completas y bases de datos. En lnea: se dice que un recurso est en lnea en un nodo cuando est ofreciendo servicio en ese nodo concreto. Grupo: una coleccin de recursos gestionados como una unidad. Normalmente, un grupo contiene todos los elementos necesarios para ejecutar una aplicacin especfica y para que los sistemas cliente se conecten al servicio ofrecido por esa aplicacin.

Este ltimo concepto es particularmente importante. Un grupo combina recursos en unidades ms grandes que son fciles de gestionar, tanto para la resistencia a fallos como para el equilibrio de carga. Las operaciones realizadas sobre un grupo, como transferir el grupo a otro nodo, afectan automticamente a todos los recursos de ese grupo. Los recursos se implementan como Bibliotecas de Enlace Dinmico (DLL, Dynamically Linked Libraries) y estn gestionados mediante un monitor de recursos. El monitor de recursos interacta con el servicio de agrupacin mediante llamadas a procedimiento remoto y responde a las rdenes del servicio de agrupacin para configurar y mover los grupos de recursos. La Figura Diagrama de bloques del Windows Clster Server representa los componentes del Servidor de Agrupaciones de W2K y sus relaciones con un sistema individual de una agrupacin. El gestor de nodos es el responsable de mantener este miembro del nodo en la agrupacin. Peridicamente, enva mensajes de latido a los gestores de nodos en otros nodos de la agrupacin. En el caso de que un gestor de nodos detecte la prdida de mensajes de latido de otro nodo de la agrupacin, difunde un mensaje a toda la agrupacin provocando que todos los miembros intercambien mensajes para verificar su visin de los miembros actuales de la agrupacin. Si un gestor de nodo no responde, se extrae de la agrupacin y sus grupos activos se transfieren a uno o ms nodos activos de la agrupacin. El gestor de la base de datos de configuracin mantiene la base de datos de configuracin de la agrupacin. La base de datos contiene informacin sobre recursos, grupos y nodos propietarios de grupos. Los gestores de la base de datos de cada uno de los nodos de la agrupacin cooperan para mantener una imagen consistente de informacin de configuracin. El software de transacciones tolerante a fallos se utiliza para garantizar que los cambios en la configuracin global de la agrupacin se llevan a cabo consistente y correctamente. El gestor de recursos/ gestor de resistencia a fallos toma todas las decisiones relacionadas con los grupos de recursos e inicia las acciones apropiadas, tales como iniciar, reiniciar y la resistencia a fallos. Cuando es necesaria la resistencia a fallos, los gestores de resistencia a fallos del nodo activo cooperan para negociar una distribucin de los grupos de recursos desde el sistema fallido hasta el resto de sistemas activos. Cuando un sistema se recupera despus de un fallo, el gestor de resistencia a fallos puede decidir devolver algunos grupos a este sistema. En particular, cualquier grupo puede estar configurado con un propietario preferido. Si ese propietario falla y, despus, se recupera, el grupo se devuelve al nodo en una operacin de retorno. El procesador de sucesos conecta todos los componentes del servicio de agrupacin, gestiona las operaciones comunes y controla la iniciacin del servicio de agrupacin. El gestor de comunicaciones gestiona el

intercambio de mensajes con los otros nodos de la agrupacin. El gestor de actualizacin global proporciona un servicio que utilizan los otros componentes del servicio de agrupacin.

Figura Diagrama de bloques del Windows Clster Server SUN CLUSTER Son un sistema operativo distribuido construido como un conjunto de extensiones sobre la base del sistema UNIX Solaris. Este sistema ofrece agrupaciones con una imagen de sistema nico: Es decir la agrupacin aparece ante los ojos del usuario y de las aplicaciones como un nico computador ejecutando el sistema operativo Solaris. Estructura de una agrupacin SUN:

Figura Estructura de Sun Clster Los componentes principales son:

Soporte de comunicaciones y objetos. Gestin de procesos. Gestin de redes. Sistemas de archivos globales distribuidos.

SOPORTE DE COMUNICACIONES Y OBJETOS: La implementacin de la agrupacin Sun est orientada a objetos. El modelo de objetos CORBA se utiliza para definir los objetos y los mecanismos de llamada a procedimiento remoto (RPC) implementados en una agrupacin Sun . El lenguaje de definicin de interfaces (IDL) de CORBA se utiliza para especificar las interfaces entre los componentes MC de diferentes nodos. Los elementos de MC estn implementados en el lenguaje orientado a objetos C++. Esto junto con IDL proporciona un mecanismo para la comunicacin entre procesos, entre nodos y dentro de cada nodo. Todo est construido sobre el ncleo de Solaris, sin que prcticamente se necesiten cambios.

GESTIN DE PROCESOS: La gestin de procesos global abarca todas las operaciones sobre procesos por lo que la ubicacin de un proceso es transparente al usuario. La agrupacin Sun mantiene una visin global de los procesos por lo que existe un identificador nico para cada proceso de la agrupacin y por lo que cada nodo puede saber la ubicacin y el estado de cada proceso. Es posible realizar migracin de procesos: un proceso puede desplazarse de

un nodo a otro durante su ejecucin para obtener un equilibrio de la carga o resistencia a fallos. Sin embargo todos los hilos de un mismo proceso deben estar en el mismo nodo. GESTIN DE REDES: Se tuvieron en cuenta tres mtodos para la gestin del trfico de la red: 1Realizar todo el procesamiento del protocolo de la red en un nico nodo. En particular para una aplicacin basada en TCP/IP, el trafico entrante (y saliente) debe atravesar un nodo de conexin a la red que, para el trafico entrante, debe analizar las cabeceras TCP e IP y encaminar los datos encapsulados hacia el nodo adecuado y, para el trafico saliente, debe encapsular los daos de otros nodos con cabeceras TCP/IP. No es escalable para un gran nmero de nodos por lo que fue rechazado. Asignar una direccin IP nica a cada nodo y ejecutar los protocolos de la red sobre la red externa directamente en cada nodo. El problema es que la configuracin de la agrupacin ya no es transparente y la dificultad de la resistencia a los fallos cuando una aplicacin se desplaza a otro nodo con direccin de red subyacente distinta. Utilizar un filtro de paquetes para encaminar paquetes al nodo adecuado y realizar el procesamiento de protocolo en ese nodo. La agrupacin aparece como nico servidor con direccin IP nica. Las solicitudes del cliente estn equilibradas entre los nodos disponibles. Es el mtodo adoptado por la agrupacin Sun.

1-

2-

Subsistemas de red de Sun Clster tiene tres elementos principales:

Los paquetes entrantes los recibe en primer lugar el nodo que tiene el adaptador de red fsicamente conectado a la red. El nodo receptor filtra el paquete y lo entrega al nodo de destino correcto a travs de la interconexin de la agrupacin. Todos los paquetes salientes se encaminan a travs de la interconexin de la agrupacin al nodo que tiene conexin con una red externa. El procesamiento del protocolo de los paquetes salientes se realiza en el nodo en donde se originan. Se mantiene una base de datos de la configuracin de la red global para hacer un seguimiento del trfico de la red en cada nodo.

6.4 SISTEMA DE ARCHIVOS GLOBAL:

El elemento ms importante de la agrupacin Sun es el sistema de archivos global:

Figura Extensiones del sistema de ficheros de Sun Clster Compara la gestin de archivos MC con el esquema de Solaris Bsico. Los dos se construyen mediante el uso de conceptos de sistemas de archivos virtual y vnodos. En solaris la estructura del nodo virtual se utiliza para proporcionar una interfaz de propsito general y potente para todos los tipos de sistemas de archivos. Un nodo-v se utiliza para traducir pginas de memoria al espacio de direcciones de un proceso y para permitir el acceso a un sistema de archivos. Mientras que un nodo traduce procesos a archivos UNIX , un nodo-v puede traducir un proceso a un objeto de cualquier tipo de sistema de archivos. De esta manera, una llamada al sistema no necesita saber el objeto que realmente est utilizando, solo como hacer la llamada orientada a objetos apropiada mediante la interfaz nodo-v. La interfaz nodo acepta rdenes de manipulacin de archivos de propsito general, tales como leer y escribir, y las convierte en las acciones apropiadas para el sistema de archivos de destino. Del mismo modo que los nodos-v se utilizan para describir objetos individuales de un sistema de archivos, las estructuras del sistema de archivos virtual (vfs) se utilizan para describir sistemas de archivos completos. La interfaz vfs acepta rdenes de propsito general que operan sobre archivos completos, y las traduce en las acciones apropiadas para el sistema de archivos de destino.

En la agrupacin Sun, el sistema de archivos global ofrece una interfaz uniforme a los archivos distribuidos a lo largo de la agrupacin. Un proceso puede abrir un archivo situado en cualquier lugar de la agrupacin y los procesos de todos los nodos utilizan la misma ruta de acceso para localizar el archivo. Para implementar el acceso a archivos globales, MC incluye un sistema de archivos proxy construido sobre el sistema de archivos Solaris ya existente y la interfaz de nodo-v. Un nivel proxy convierte las operaciones sobre nodo-v/vfs en llamadas a objetos: El objeto involucrado puede residir en cualquier nodo del sistema y realiza una operacin Nodos-v/vfs en el sistema de archivos subyacente. Para dar soporte a este entorno de archivos global no se tiene que modificar ni el ncleo ni los sistemas de archivos existentes. Para reducir el nmero de llamadas a objeto remoto, se utiliza una memoria cach. La agrupacin sun puede almacenar en cache el contenido de los archivos, la informacin de los directorios y los atributos de los archivos. CLUSTER LINUX Y BEOWULF En 1994, el proyecto Beowulf se inici bajo el patrocinio del proyecto de alto rendimiento en procesamiento y comunicaciones (HPCC, High performance Computing and Communications) de la NASA. Su objetivo era investigar el potencial de las agrupaciones de PC para llevar a cabo tareas de procesamiento importantes que van ms all de las capacidades de las estaciones de trabajo contemporneas con un mnimo coste. Hoy en da el mtodo Beowulf est ampliamente implementado y es quiz la tecnologa ms importante disponible para agrupaciones. CARACTERSTICAS DE BEOWULF:

Los componentes son elementos del mercado masivo. Procesadores dedicados. Una red privada dedicada (LAN o WAN o combinacin). No tiene componentes de propietario. Fcil repeticin para muchos fabricantes. E/S escalable. Una base de software disponible libremente. Uso de herramientas de ejecucin distribuida libremente disponibles con mnimos cambios. Retorno del diseo y de las mejoras a la comunidad.

La opcin ms evidente como base es Linux, se utiliza una agrupacin de estaciones de trabajo Linux y PC Linux.

Esta es una configuracin representativa:

Figura configuracin genrica de Beowulf

Configuracin beowulf genrica, Se compone de varias estaciones de trabajo, todas ejecutando Linux El almacenamiento secundario de c/u puede utilizarse para acceso distribuido, las cajas Linux (nodos), estn interconectados a una red comercial (Etherner) e cual puede tener una nica o varias lneas conmutadas interconectadas. Para transferencias de 10Mbps, 100 Mbps, 1 Gbps se utilizan protocolos Ethernet comerciales. SOFTWARE BEOWULF: Es un aadido a las distribuciones comerciales gratuitas con base Linux, el cdigo fuente del software Beowulf es el sitio www.beowulf.org otras organizaciones ofrecen herramientas Beowulf gratuitas. Cada nodo Beowulf ejecuta su propia copia de ncleo Linux (puede funcionar como autnomo).

Ejemplos de software del sistema Beowulf :

Espacio de Proceso distribuido Beowulf (BPROC): Paquete que permite que el espacio identificador de un proceso abarque varios nodos en un entorno de agrupacin proporciona mecanismos para iniciar procesos en otros nodos. Proporciona elementos claves para una imagen de sistema nico en Beowulf, inicia procesos en nodos remotos sin entrar nunca en otro nodo. Vinculacin de canales Ethernet de Beowulf: Une mltiples redes de bajo coste en una red lgica con un ancho de banda mayor, distribuye paquetes por las colas de transmisin de dispositivos disponibles lo cual equilibra la carga a travs de varias Ethernet conectadas a estaciones Linux. Pvmsync: Entrono de programacin que proporciona mecanismos de sincronizacin y objetos de daos compartidos para los procesos en Beowlf . EnFunzion: Conjunto de herramientas para realizar procesamiento paramtrico (superpone la ejecucin de un programa como un gran grupo de trabajo cada uno con parmetros de inicio diferentes). Emula un conjunto de usuarios Robot en una nica mquina de nodo raz, cada uno entra en una de las maquinas de cliente que forma una agrupacin.