\newpage
%===========================================================================
%       x.8 > Nociones generales
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
%      \includegraphics[bb = -250 220 0 0, scale=1]{./TuXes/tux-net.jpg}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
%      \includegraphics[-275,650][0,0]{./TuXes/tux-net}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{CLUSTERS. NOCIONES GENERALES}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em It is a capital mistake to theorize}}

\hspace{1in}\textcolor{blue_omosix}{{\em before one has data.}}

\hspace{4in}\textcolor{blue_omosix}{{\em Sir Arthur Conan Doyle}}
\vspace{0.5in}

\end{latexonly}
%===========================================================================
\subsection{El concepto de cluster}
Aunque parezca sencillo de responder no lo es en absoluto.
 Podr\'\i a incluirse alguna definici\'on de alg\'un libro, pero el
 problema es que ni los expertos en clusters ni la gente que los implementa
 se ponen de acuerdo en qu\'e es aquello en lo que trabajan.

Un cluster podemos entenderlo como:

\vspace{.2in}
{\bf Un conjunto de m\'aquinas unidas por una red de comunicaci\'on trabajando por
 un servicio conjunto.
 Seg\'un el servicio puede ser dar alta disponibilidad, alto rendimiento, etc...}

\vspace{.2in} 
Por supuesto esta definici\'on no es estricta, de hecho uno de los problemas
 que tiene es que es demasiado vaga porque por ejemplo dos
 consolas de videojuegos conectadas para jugar en red ?`se considera cluster? Pero si en vez
 de estar jugando se est\'a usando el kit de GNU/Linux haciendo procesamiento
 paralelo ?`entonces se podr\'\i a considerar cluster?

Realmente el cambio de ambiente es m\'\i nimo, desde luego a nadie se le ocurrir\'\i a
 definir cluster en base al contenido de los programas que se ejecuten y
 de hecho es posible que los juegos tengan m\'as capacidades de procesamiento
 distribuido que los propios programas, entonces ?`qu\'e es un cluster? 

Hay definiciones que distinguen entre cluster de m\'aquinas SMP
 y clusters formados por nodos monoprocesadores.
Hay arquitecturas clusters que se denominan {\em constelaciones}\footnote{Aqu\'\i\
 hemos dado con el origen del logotipo de openMosix.} y se caracterizan por
 que cada nodo contiene m\'as procesadores que el n\'umero de nodos.
 A pesar de todo, las constelaciones siguen siendo clusters de componentes
 o nodos aventajados y caros.
De hecho entre las m\'aquinas que aparecen en el top500 existen
 unos pocos clusters que pertenecen a organizaciones que no son gigantes
 de la inform\'atica, lo cual indica el precio que pueden llegar a tener estos sistemas.

Por poner unos ejemplos de la disparidad de opiniones que existen, se adjuntan
 las definiciones que dan ciertas autoridades de esta materia: 

\vspace{.2in}
{\em Un cluster consiste en un conjunto de m\'aquinas y un servidor de cluster
 dedicado, para realizar los relativamente infrecuentes accesos a los recursos
 de otros procesos, se accede al servidor de cluster de cada grupo}
 del libro {\em Operating System Concepts} de Silberschatz Galvin.

\vspace{.2in}
{\em Un cluster es la variaci\'on de bajo precio de un multiprocesador masivamente
 paralelo (miles de procesadores, memoria distribuida, red de baja latencia),
 con las siguientes diferencias: cada nodo es una m\'aquina quiz\'as sin algo
 del hardware (monitor, teclado, mouse, etc.), el nodo podr\'\i a ser SMP.
 Los nodos se conectan por una red de bajo precio como Ethernet o ATM aunque
 en clusters comerciales se pueden usar tecnolog\'\i as de red propias.
 El interfaz de red no est\'a muy acoplado al bus I/O.
 Todos los nodos tienen disco local.\\
 Cada nodo tiene un sistema operativo UNIX con una capa de software
 para soportar todas las caracter\'\i sticas del cluster} del libro
 {\em  Scalable Parallel Computing} de Kai Hwang y Khiwei Xu.

\vspace{.2in}
{\em Es una clase de arquitectura de computador paralelo que se basa en unir
 m\'aquinas independientes cooperativas integradas por medio de redes de interconexi\'on
 para proveer un sistema coordinado, capaz de procesar una
 carga} del autor Dr. Thomas Sterling.
%===========================================================================
\subsection{Caracter\'\i sticas de un cluster}
Si no hay acuerdo sobre lo que es un cluster poco podr\'a acertarse en sus caracter\'\i sticas.
En este apartado se explican los requisitos que
 deben cumplir un conjunto de computadoras para ser consideradas
 cluster, tal y como se conocen hasta el momento.

Para crear un cluster se necesitan al menos dos nodos. Una de las
 caracter\'\i sticas principales de estas arquitecturas es que exista
 un medio de comunicaci\'on (red) donde los procesos puedan migrar
 para computarse en diferentes estaciones paralelamente. Un solo nodo no cumple este
 requerimiento por su condici\'on de aislamiento para poder compartir
 informaci\'on. Las arqutecturas con varios procesadores en placa tampoco son
 consideradas clusters, bien sean m\'aquinas SMP o mainframes, debido a
 que el bus de comunicaci\'on no suele ser de red, sino interno.

Por esta raz\'on se deduce la primera caracter\'\i stica de un cluster: 

\vspace{.2in}
{\bf {\em i.-} Un cluster consta de 2 o m\'as nodos.}

\vspace{.2in}
Los nodos necesitan estar conectados para llevar a cabo
 su misi\'on. Por tanto:

\vspace{.2in}
{\bf {\em ii.-} Los nodos de un cluster est\'an conectados entre s\'\i\ por al menos un canal de comunicaci\'on.}

\vspace{.2in}
Por ahora se ha referenciado a las caracter\'\i sticas f\'\i sicas de un cluster, que
 son las caracter\'\i sticas sobre las que m\'as consenso hay.
 Pero existen m\'as problemas sobre las caracter\'\i sticas del programario de control que
 se ejecuta, pues es el software el que finalmente 
 dotar\'a al conjunto de m\'aquinas de capacidad para migrar procesos,
 balancear la carga en cada nodo, etc.

\vspace{.2in}
{\bf {\em y iii.-} Los clusters necesitan software de control especializado.}

\vspace{.2in}
El problema tambi\'en se plantea por los distintos tipos de clusters, cada
 uno de ellos requiere un modelado y dise\~{n}o del software distinto.

 Como es obvio las caracter\'\i sticas del cluster son completamente
 dependientes del software, por lo que no se tratar\'an las funcionalidades
 del software sino el modelo general de software que compone
 un cluster.

Para empezar, parte de este software se debe dedicar a la comunicaci\'on entre
 los nodos.
 Existen varios tipos de software que pueden conformar un cluster: 
\begin{itemize}
\item \underline{Software a nivel de aplicaci\'on}.

Este tipo de software se sit\'ua a nivel de aplicacion, se utilizan generalmente
 bibliotecas de car\'acter general que permiten la abstracci\'on de un nodo
 a un sistema conjunto, permitiendo crear aplicaciones en un entorno distribuido
 de manera lo m\'as abstracta posible.
 Este tipo de software suele generar elementos de proceso del tipo rutinas,
 procesos o tareas, que se ejecutan en cada nodo del cluster y se comunican
 entre s\'\i\  a trav\'es de la red.

\item  \underline{Software a nivel de sistema.}
 
  Este tipo de software se sit\'ua a nivel de sistema, suele estar implementado
 como parte del sistema operativo de cada nodo, o ser la totalidad de \'este.
 
 Es m\'as cr\'\i tico y complejo, por otro lado suele resolver problemas de car\'acter
 m\'as general que los anteriores y su eficiencia, por norma general, es mayor.
\end{itemize}
A pesar de esta divisi\'on existen casos en los cuales
 se hace uso de un conjunto de piezas de software de cada tipo para conformar
 un sistema cluster completo. Son implementaciones h\'\i bridas donde
 un cluster puede tener implementado a nivel de kernel parte del
 sistema y otra parte estar preparada a nivel de usuario.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -180 500 0 0, scale=.6]{./pics/clusters.png}
        \vspace{4.5in}
        \caption{Clusters. Cluster a nivel de sistema y nivel de aplicaci\'on}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/clusters}
        \caption{Clusters. Cluster a nivel de sistema y nivel de aplicaci\'on}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}
%===========================================================================
\subsubsection{Acoplamiento de un cluster}
Dependiendo del tipo de software, el sistema puede estar m\'as o
 menos acoplado.

Se  entiende por acoplamiento del software a la {\em integraci\'on que
 tengan todos los elementos software que existan en cada nodo}. Gran
 parte de la integraci\'on del sistema la produce la comunicaci\'on
 entre los nodos, y es por esta raz\'on por la que se define el acoplamiento; otra
 parte es la que implica c\'omo de cr\'\i tico es el software y su capacidad de
 recuperaci\'on ante fallos.
 
 Aqu\'\i\  hay que hacer un peque\~{n}o inciso para destacar que todo esto depende de
 si el sistema es centralizado o distribuido.
 En cualquier caso, el acoplamiento del software es una medida subjetiva
 basada en la integraci\'on de un sistema cluster a nivel general.

Se distingue entre 3 tipos de acoplamiento: 
\begin{itemize}
 \item Acoplamiento fuerte
 \item Acoplamiento medio
 \item Acoplamiento d\'ebil 
\end{itemize}
Tras algunos ejemplos explicativos de estos tipos de acoplamiento
 quedar\'a m\'as clara la idea.
 
\vspace{.2in}
{\bf Acoplamiento fuerte.}

El software que entra en este grupo es software cuyos elementos se
 interrelacionan mucho unos con otros y posibilitan la mayor\'\i a de las
 funcionalidades del cluster de manera altamente cooperativa.
 El caso de acoplamiento m\'as fuerte que se puede dar es que solamente haya una
 imagen del kernel del sistema operativo, distribuida entre un
 conjunto de nodos que la compartir\'an. Por supuesto algo
 fundamental es poder acceder a todas las partes de este sistema
 operativo, estrechamente relacionadas entre s\'\i\ y distribuidas entre los nodos.

Este caso es el que se considera como m\'as acoplado, de hecho no
 est\'a catalogado como cluster, sino como sistema operativo distribuido.

Otro ejemplo son los cluster SSI, en estos clusters
 todos los nodos ven una misma imagen del sistema, pero todos los nodos
 tienen su propio sistema operativo, aunque estos sistemas est\'an estrechamente
 relacionados para dar la sensaci\'on a las aplicaciones que todos los nodos
 son id\'enticos y se acceda de una manera homog\'enea a los recursos del sistema
 total.
 
 Si arranca o ejecuta una aplicaci\'on, \'esta ver\'a un sistema homog\'eneo, por
 lo tanto los kernels tienen que conocer los recursos de otros nodos para
 presentarle al sistema local los recursos que encontrar\'\i a si estuviera
 en otro nodo.
 Por supuesto se necesita un sistema de nombres \'unico, manejado de sistema
 distribuida o centralizada y un mapeo de los recursos f\'\i sicos a este sistema
 de nombres.
  
\vspace{.2in}
{\bf Acoplamiento medio.}

A este grupo pertenece un software que no necesita un conocimiento tan
 exhaustivo de todos los recursos de otros nodos, pero que sigue
 usando el software  de otros nodos para aplicaciones de muy bajo
 nivel. Como ejemplos hay openMosix y Linux-HA.

Un cluster openMosix necesita que todos los kernels sean de la misma versi\'on.
 Por otro lado no est\'a tan acoplado como el caso anterior: no necesita un
 sistema de nombres com\'un en todos los nodos, y su capacidad de dividir
 los procesos en una parte local y otra remota consigue que por un lado
 se necesite el software del otro nodo donde est\'a la parte del fichero que
 falta en el nodo local y por otro que no se necesite un SSI para hacer
 otras tareas.
 
\vspace{.2in}
{\bf Acoplamiento d\'ebil.}

 Generalmente se basan en aplicaciones construidas por bibliotecas preparadas
 para aplicaciones distribuidas.
 Es el caso de por ejemplo PVM, MPI o CORBA. \'Estos por s\'\i\  mismos no funcionan en modo
 alguno con las caracter\'\i sticas que antes se han descrito (como
 Beowulf) y hay que dotarles de una estructura superior que
 utilice las capacidades del cluster para que \'este funcione.
%---------------------------------------------------------------------------
\subsubsection*{Esquema y otras caracter\'\i sticas}
Las caracter\'\i sticas b\'asicas de un cluster de car\'acter general
podr\'\i an resumirse en el siguiente esquema:
\begin{enumerate}
  \item Un cluster consta de 2 o m\'as nodos conectados entre s\'\i  por un canal de comunicaci\'on funcional.
 
  \item En cada nodo es imprescindible un elemento de proceso, memoria y un interfaz
 para comunicarse con la red del cluster.
 
  \item Los clusteres necesitan software especializado. Este software
  y las m\'aquinas conforman el cluster. El software puede ser:
    \begin{enumerate}
      \item aplicaci\'on
      \item sistema
    \end{enumerate}

  \item Se define acoplamiento de un cluster como nivel de colaboraci\'on que une
 los elementos del cluster.
 De este modo se categorizan en:
    \begin{enumerate}
      \item Acoplamiento fuerte
      \item Acoplamiento medio o moderado
      \item Acoplamiento d\'ebil
    \end{enumerate}

  \item Todos los elementos del cluster trabajan para cumplir una funcionalidad
 conjunta, sea esta la que sea.
 Es la funcionalidad la que caracteriza el sistema.
\end{enumerate}
Muchos libros dan otra serie de caracter\'\i sticas necesarias, por ejemplo
 el {\em Scalable Parallel Computing} de Kai Hwang y Zhiwei Xu incluye entre estas
 caracter\'\i sticas las siguientes:
\begin{itemize}
  \item Mejora sobre la disponibilidad
  \item Mejora del rendimiento
\end{itemize}

En general la catalogaci\'on de los clusters se hace en base a cuatro factores de dise\~{n}o
 bastante ortogonales entre s\'\i\ :
\begin{itemize}
  \item Acoplamiento
  \item Control
  \item Homogeneidad
  \item Seguridad
\end{itemize}
 De estos factores en este tema ya se ha visto el que quiz\'as es
m\'as importante, el de acoplamiento. 

Por otro lado est\'a el factor de control del cluster.
 El par\'ametro de control implica el modelo de gesti\'on que propone el cluster.
 Este modelo de gesti\'on hace referencia a la manera de configurar el cluster
 y es dependiente del modelo de conexionado o colaboraci\'on que surgen entre
 los nodos.
 Puede ser de dos tipos:
\begin{itemize}
  \item {\bf Control centralizado:} se hace uso de un nodo
 maestro desde el cual se puede configurar el comportamiento de todo el
 sistema. Este nodo es un punto cr\'\i tico del sistema aunque es una ventaja para una mejor
 gesti\'on del cluster.

  \item {\bf Control descentralizado:} en un modelo distribuido donde cada nodo debe administrarse y
 gestionarse. Tambi\'en pueden ser gestionados
 mediante aplicaciones de m\'as alto nivel de manera centralizada, pero la
 mayor\'\i a de la gesti\'on que hace el nodo local es leer archivos de configuraci\'on
 de su propio nodo.
 
 Es propio de sistemas distribuidos, como ventaja tiene que presenta m\'as
 tolerancia a fallos como sistema global, y como desventajas que la gesti\'on
 y administraci\'on de los equipos requiere m\'as tiempo.
\end{itemize}
En lo que se refiere a homogeneidad de un cluster cabe decir
 que Tanenbaum no llevaba raz\'on, a pesar de que sus conclusiones despu\'es
 de haber creado el sistema Amoeba. Se ha demostrado que es posible crear
 sistemas de una sola imagen o hetereog\'eneos con una implementaci\'on pr\'actica.
 En cualquier caso, hay que entender por homogeneidad del cluster a la homogeneidad
 de los equipos y recursos que conforman a \'este. Los clusters hetereog\'eneos
 son m\'as dif\'\i ciles de conseguir ya que se necesitan notaciones abstractas
 de transferencias e interfaces especiales entre los nodos para que \'estas
 se entiendan, por otro lado los clusters homog\'eneos obtienen m\'as beneficios
 de estos sistemas y pueden ser implementados directamente a nivel de sistema.

\vspace{.2in}
 {\bf Homogeneidad de un cluster}
\begin{itemize}
  \item {\bf Homog\'eneos:} formados por equipos de la misma arquitectura.
 Todos los nodos tienen una arquitectura y recursos similares, de manera
 que no existen muchas diferencias entre cada nodo.
 
  \item {\bf Hetereog\'eneos:} formados por nodos con distinciones que pueden estar en los
 siguientes puntos.
    \begin{itemize}
      \item Tiempos de acceso distintos
      \item Arquitectura distinta
      \item Sistema operativo distinto
      \item Rendimiento de los procesadores o recursos sobre una misma arquitectura
 distintos
    \end{itemize}
El uso de arquitecturas distintas, o distintos sistemas operativos,
 impone que exista una biblioteca que haga de interfaz, e incluso una sintaxis
 de notaci\'on abstracta del tipo ASN.1 o XDR en la capa de presentaci\'on que
 utilice la interfaz de comunicaci\'on de nuestro sistema distribuido o cluster.
 Esto hace que este tipo de clusters se consideren implementados a nivel
 de aplicaci\'on.
\end{itemize}
Existen otros muchos factores de dise\~{n}o que limitan el comportamiento y
 modelado de un cluster.
La imposibilidad de llegar a clusters que paralelicen cualquier proceso se basa en que la mayor\'\i a de las
 aplicaciones hacen uso, en mayor o menor medida, de algoritmos secuenciales no paralelizables.
 %===========================================================================
\subsection{Clasificaci\'on seg\'un el servicio prioritario}
 Generalmente el dise\~{n}o de un cluster se realiza para solucionar problemas
 de tipo:
\begin{itemize}
  \item Mejora de rendimiento
  \item Abaratamiento del coste
  \item Distribuci\'on de factores de riesgo del sistema
  \item Escalabilidad
\end{itemize}
El punto inicial ha sido explicado anteriormente:
 el coste para doblar las prestaciones de un equipo no suele ser
 habitualmente a costa de pagar el doble, sino unas
 cuantas veces m\'as.
 El modelo de los clusters permite que la mejora de rendimiento sea evidente
 respecto a grandes mainframes a un precio realmente asequible.
 Lo que explica a su vez el segundo punto, acerca del coste de los clusters,
 que permite relaciones rendimiento precio que se acercan a un margen lineal
 dependiendo del cluster implementado.

Por otro lado esta la distribuci\'on de riesgos.
 La mayor\'\i a de los usuarios tienen sus servicios, aplicaciones,
 bases de datos o recursos en un solo ordenador, o dependientes de un solo
 ordenador.
 Otro paso m\'as adelante es colocar las bases de
 datos replicadas sobre sistemas de archivos distribuidos de manera
 que estos no se pierdan por que los datos son un recurso importante.
 Actualmente el mercado de la inform\'atica exige no solo que los datos sean
 cr\'\i ticos sino que los servicios est\'en activos constantemente.
 Esto exige medios y t\'ecnicas que
 permitan que el tiempo en el que una m\'aquina est\'e inactiva sea
 el menor posible. La distribuci\'on
 de factores de riesgo a lo largo de un cluster (o la distribuci\'on de
 funcionalidades en casos m\'as generales)
 permite de una forma \'unica obtener la funcionalidad de una manera m\'as
 confiable: si una m\'aquina cae otras podr\'an dar el servicio.

Por \'ultimo est\'a el factor de escalabilidad, del cual se habl\'o en el tema
 de introducci\'on.
 Cuanto m\'as escalable es un sistema menos costar\'a mejorar el rendimiento,
 lo cual abarata el coste, y en el caso de que el cluster lo implemente
 distribuye m\'as el riesgo de ca\'\i da de un sistema.

En cualquier caso, todas estas caracter\'\i sticas dan pie a los tipos de clusters
 que se van a ver.

\vspace{.2in}
{\bf Alto rendimiento (HP, high performance)}

Los clusters de alto rendimiento han sido creados para compartir el recurso
 m\'as valioso de un ordenador, es decir, el tiempo de proceso. 
 Cualquier operaci\'on que necesite altos tiempos de CPU
 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 aplicacion.
 A nivel de sistema tenemos openMosix, mientras que a nivel de aplicaci\'on 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\'aquinas.

\vspace{.2in}
{\bf Alta disponibilidad (HA, high availability)}

Los clusters de {\bf alta disponibilidad} son bastante ortogonales en lo que
 se refieren a funcionalidad a un cluster de alto rendimiento.
 Los clusters de alta disponibilidad pretenden dar servicios 7/24 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\'aximo periodo de tiempo posible.
 En estos casos se puede comprobar como la monitorizaci\'on de otros es parte
 de la colaboraci\'on entre los nodos del cluster.

\vspace{.2in}
 {\bf Alta confiabilidad (HR, high reliability)}
 
Por ultimo, est\'an los clusters de alta confiabilidad.
 Estos clusters tratan de aportar la m\'axima 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 respeusta a tiempo real.
 
\vspace{.2in}
Pueden existir otras catalogaciones en lo que se refiere a tipos de clusters,
 en nuestro caso, solamente hemos considerado las tres que m\'as clusters
 implementados engloban, si bien existe alguno de ellos que puede ser considerar
o como cluster de varios tipos a la vez.
%===========================================================================
\subsection{Clusters HP: alto rendimiento}
 Se har\'an distinciones entre los que se implementan a nivel de sistema operativo
 y los que se implementan a nivel de librer\'\i as, y se explicar\'an qu\'e tipo
 de problemas resuelven ambos.
%---------------------------------------------------------------------------
\subsubsection{La misi\'on}
La misi\'on o el objetivo de este tipo de clusters es, como su propio nombre
 indica mejorar el rendimiento en la obtenci\'on de la soluci\'on de un problema, en t\'erminos bien del
 tiempo de respuesta bien de su precisi\'on.

Dentro de esta definici\'on no se engloba ning\'un tipo de problema en concreto.
 Esto supone que cualquier cluster que haga que el rendimiento del sistema
 aumente respecto al de uno de los nodos individuales puede ser
 considerado cluster HP.
%---------------------------------------------------------------------------
\subsubsection{Problemas que solucionan}
Generalmente estos problemas de computo suelen estar ligados a:
\begin{itemize}
  \item C\'alculos matem\'aticos
  \item Renderizaciones de gr\'aficos
  \item Compilaci\'on de programas
  \item Compresi\'on de datos
  \item Descifrado de c\'odigos
  \item Rendimiento del sistema operativo, (incluyendo en \'el, el rendimiento de
 los recursos de cada nodo)
\end{itemize}
Existen otros muchos problemas m\'as que se pueden solucionar con clusters
 HP, donde cada uno aplica de una manera u otra las t\'ecnicas
 necesarias para habilitar la paralelizaci\'on del problema, su distribuci\'on
 entre los nodos y obtenci\'on del resultado.
%---------------------------------------------------------------------------
\subsubsection{T\'ecnicas que utilizan}
Las t\'ecnicas utilizadas dependen de a qu\'e nivel trabaje el cluster.
 
 Los clusters implementados a nivel de aplicacion no suelen implementar
 balanceo de carga. Suelen basar todo su funcionamiento en una pol\'\i tica
 de localizaci\'on que sit\'ua las tareas en los diferentes nodos del cluster,
 y las comunica mediante las librer\'\i as abstractas.
 Resuelven problemas de cualquier tipo de los que se han visto en el apartado
 anterior, pero se deben dise\~{n}ar y codificar aplicaciones propias para
 cada tipo para poderlas utilizar en estos clusters.

Por otro lado est\'an los sistemas de alto rendimiento implementados a nivel
 de sistema. Estos clusters basan todo su funcionamiento en comunicaci\'on
 y colaboraci\'on de los nodos a nivel de sistema operativo, lo que implica
 generalmente que son clusters de nodos de la misma arquitectura, con ventajas
 en lo que se refiere al factor de acoplamiento, y que basan su funcionamiento
 en compartici\'on de recursos a cualquier nivel, balanceo de la carga de
 manera din\'amica, funciones de planificaci\'on especiales y otros tantos factores
 que componen el sistema.
 Se intentan acercar a sistemas SSI, el problema est\'a en que para obtener
 un sistema SSI hay que ceder en el apartado de compatibilidad con los sistemas
 actuales, por lo cual se suele llegar a un factor de compromiso.

Entre las limitaciones que existen actualmente
 est\'a la incapacidad de balancear la carga din\'amica de las librer\'\i as PVM
 o la incapacidad de openMosix de migrar procesos que hacen uso
 de memoria compartida.
 Una t\'ecnica que obtiene mayor ventaja es cruzar ambos sistemas: PVM + openMosix.
 Se obtiene un sistema con un factor de acoplamiento elevado que presta
 las ventajas de uno y otro, con una peque\~{n}a limitaci\'on por desventajas
 de cada uno.
%===========================================================================
\subsection{Clusters HA: alta disponibilidad}
Son otro tipo de clusters completamente distintos a los anteriores.
 Son los m\'as solicitados por las empresas ya que est\'an destinados a mejorar
 los servicios que \'estas ofrecen cara a los clientes en las redes a las
 que pertenecen, tanto en redes locales como en redes como Internet.
 En este apartado se dar\'an las claves que explican tanto el dise\~{n}o de estos
 clusters as\'\i  como alg\'un factor de implementaci\'on.
%---------------------------------------------------------------------------
\subsubsection{La misi\'on}
Los clusters de alta disponibilidad han sido dise\~{n}ados para la m\'axima disponibilidad sobre los servicios que presenta el cluster.
 Este tipo de clusters son la competencia que abarata los sistemas redundantes,
 de manera que ofrecen una serie de servicios durante el mayor tiempo posible.
 Para poder dar estos servicios los clusters de este tipo se implementan
 en base a tres factores.
\begin{itemize}
  \item Fiabilidad
  \item Disponibilidad
  \item Dotaci\'on de servicio
\end{itemize}
Mediante estos tres tipos de actuaciones y los mecanismos que lo implementan
 se asegura que un servicio est\'e el m\'aximo tiempo disponible y que \'este
 funcione de una manera fiable.
 Respecto al tercer punto, se refiere a la dotaci\'on de uno de estos clusters
 de un servicio que provea a cliente externos.
%---------------------------------------------------------------------------
\subsubsection{Problemas que solucionan}
La mayor\'\i a de estos problema est\'an ligados a la necesidad de dar servicio
 continuado de cualquier tipo a una serie de clientes de manera ininterrumpida.
En una construcci\'on real se suelen producir fallos inesperados en las m\'aquinas, estos fallos provocan
 la aparici\'on de dos eventos en el tiempo: el tiempo en el que el
 servicio est\'a inactivo y el tiempo de reparaci\'on del problema.

Entre los problemas que solucionan se encuentran:
\begin{itemize}
  \item Sistemas de informaci\'on redundante
  \item Sistemas tolerantes a fallos
  \item Balanceo de carga entre varios servidores
  \item Balanceo de conexiones entre varios servidores
\end{itemize}
En general todos estos problemas se ligan en dos fuentes de necesidad de
 las empresas u organizaciones.
\begin{itemize}
  \item Tener un servicio disponible
  \item Ahorrar econ\'omicamente todo lo que sea posible
\end{itemize}
El servicio puede ser diverso.
 Desde un sistema de ficheros distribuidos de car\'acter muy barato, hasta
 grandes clusters de balanceo de carga y conexiones para los grandes portales
 de Internet.
 Cualquier funcionalidad requerida en un entorno de red puede ser colocada
 en un cluster y implementar mecanismos para hacer que esta obtenga la mayor
 disponibilidad posible.
%---------------------------------------------------------------------------
\subsubsection{T\'ecnicas que utilizan}
Como se ha visto en el apartado anterior los servicios
 y el funcionamiento de los mismos suelen ser de car\'acter bastante distinto,
 en cualquier caso, se suelen proponer sistemas desde SSI que plantean serias
 dudas en lo que se refiere a localizaci\'on de un servidor, hasta balanceo
 de carga o de conexiones. Tambi\'en suelen contener secciones de c\'odigo que
 realizan monitorizaci\'on de carga o monitorizaci\'on de servicios para activar
 las acciones necesarias para cuando estos caigan.

Se basan en principios muy simples que pueden ser desarrollados hasta crear
 sistemas complejos especializados para cada entorno particular.
 En cualquier caso, las t\'ecnicas de estos sistemas suelen basarse en excluir
 del sistema aquellos puntos cr\'\i ticos que pueden producir un fallo y por
 tanto la p\'erdida de disponibilidad de un servicio. Para esto se suelen
 implementar desde enlaces de red redundantes hasta disponer de {\tt N} m\'aquinas
 para hacer una misma tarea de manera que si caen {\tt N-1} m\'aquinas el servicio
 permanece activo sin p\'erdida de rendimiento.

La explicaci\'on de estas t\'ecnicas ha sido muy somera, se dar\'an con m\'as detalle
 en el ca\'\i tulo perteneciente a clusters HA.
%===========================================================================
\subsection{Clusters HR: alta confiabilidad}
Este tipo de clusters son los m\'as dif\'\i ciles
 de implementar. No se basan solamente en conceder servicios
 de alta disponibilidad, sino en ofrecer un entorno de sistema altamente
 confiable.
 Esto implica much\'\i sima sobrecarga en el sistema, son tambi\'en
 clusters muy acoplados.

Dar a un cluster SSI capacidad de alta confiabilidad implica gastar recursos
 necesarios para evitar que aplicaciones caigan.
 Aqu\'\i\  hay que hacer de nuevo un inciso.

En los clusters de alta disponibilidad generalmente una vez que el servicio
 ha ca\'\i do \'este se relanza, y no existe manera de conservar el estado del
 servidor anterior, m\'as que mediante puntos de parada o {\em
 checkpoints}, pero que en conexiones en tiempo real no suelen ser
 suficientes. Por otro lado, los clusters confiables tratan de mantener el estado de
 las aplicaciones, no simplemente de utilizar el ultimo checkpoint del sistema
 y relanzar el servicio.

Generalmente este tipo de clusters suele ser utilizado para entornos de
 tipo empresarial y esta funcionalidad solamente puede ser efectuada por
 hardware especializado.
 Por elmomento no existe ninguno de estos clusters implementados como software.
 Esto se debe a limitaciones de la latencia de la red, as\'\i\ como a la complejidad
 de mantener los estados.
 
 Se hacen necesarias caracter\'\i sticas de cluster SSI, tener un \'unico reloj de sistema
 conjunto y otras m\'as.
 Dada la naturaleza as\'\i ncrona actual en el campo de los clusters, este tipo
 de clusters a\'un ser\'a dif\'\i cil de implementar hasta que no se abaraten las
 t\'ecnicas de comunicaci\'on.