\newpage
%===========================================================================
%       x.7 > La importancia de la red
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
      \includegraphics[bb = -200 200 0 0, scale=1]{./TuXes/tux-gisnet.png}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
      \includegraphics[-280,630][0,0]{./TuXes/tux-gisnet}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{LA IMPORTANCIA DE LA RED}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}

\hspace{1in}\textcolor{blue_omosix}{{\em Victory is the beautiful, bright
    coloured flower.}}

\hspace{1in}\textcolor{blue_omosix}{{\em  Transport is the stem without which
    it could never have blossomed.}}

\hspace{4in}\textcolor{blue_omosix}{{\em Winston Churchill}}
\vspace{0.5in}
\end{latexonly}
%===========================================================================
\subsection{La importancia del sistema de comunicaci\'on}
En los clusters la eficacia del sistema de comunicaci\'on es
 cr\'\i tica. 
 Si las comunicaciones fallan el cluster dejar\'a de ser un cluster
 y se convertir\'a en un conjunto de m\'aquinas que no cooperar\'an, algo lejos del objetivo.
 Por lo tanto es usual disponer en sistemas cluster de alta disponibilidad de una red alternativa
 por si la red principal fallara.
 Cabe decir que una red es un elemento bastante fiable a nivel f\'\i sico: es dif\'\i cil que una vez
 instalada y probada, falle.
 Sobre las {\bf topolog\'\i as} y {\bf tecnolog\'\i as} de red que existen se hablar\'a en las pr\'oximas secciones.

Otro tema importante de la red es la eficiencia: de nada sirve una red
 si est\'a congestionada.
 Hay que tener en cuenta que todas las comunicaciones entre nodos pasan a trav\'es de la red; dependiendo
 de la cantidad de nodos la red puede ser la culpable directa de mermar la eficacia computacional
 del cluster. Es por esta raz\'on que la inversi\'on en una red tecnol\'ogicamente moderna es habitual en estos sistemas.
%===========================================================================
\subsection{Topolog\'\i as de red}
Existen muchas topolog\'\i as de red que se han impuesto en diversos entornos,
 cada una de estas topolog\'\i as tienen sus propios puntos fuertes.

Las topolog\'\i as est\'aticas son topolog\'\i as donde
 una vez hechas las conexiones, \'estas no cambian. 
 Las redes din\'amicas est\'an construidas con elementos que se pueden conectar
 entre varios caminos, esto hace que si un camino est\'a siendo
 usado se pueda usar otro, permitiendo m\'as paralelismo.
La topolog\'\i a de la red influye mucho en el grado de paralelismo
 que se pueda alcanzar.
%---------------------------------------------------------------------------
\subsubsection{Redes est\'aticas}
Las redes est\'aticas fueron las primeras en aparecer.
 En estas redes se distingue entre redes punto a punto y redes con
 acceso a medio compartido.
 Van a verse los ejemplos m\'as usados, explicando las ventajas
 y los inconvenientes de cada una de ellos.
Entre las redes punto a punto destacan:
\begin{itemize}
  \item {\bf Lineal.}

Todos los nodos est\'an conectados de forma lineal; como la comunicaci\'on es
 de punto a punto el peor caso es cuando un nodo de una esquina quiera conectar
 con un nodo que est\'e en la otra esquina.
 En este caso se necesitan {\tt N-1} pasos para llegar hasta el destino, siendo
 {\tt N} el n\'umero de nodos en la red.

  \item {\bf Anillo.}

Es similar al caso de la red lineal pero los nodos de las esquinas est\'an
 unidos entre s\'\i\. Esto tiene la ventaja que a\~{n}adiendo un solo enlace m\'as
 se consigue que el di\'ametro de la red pase de {\tt N-1} a
 $\frac{N}{2}$ pues ahora los dos nodos m\'as alejados son los que est\'en en dos puntos extremos
 de un anillo con la mitad de los nodos en cada lado hasta llegar hasta
 ellos.

  \item {\bf Estrella.}

Hay un nodo central que se conecta con todos los dem\'as nodos.
 Todos los nodos s\'olo se conectan al nodo central.
 Esto tiene la ventaja de que en 2 pasos se llega desde cualquier nodo a
 cualquier otro (excepto el central que solo necesita uno).
 Pero la desventaja que el nodo central tiene que soportar mucha sobrecarga,
 pues tiene que llevar todas las comunicaciones que est\'an ocurriendo.
 Adem\'as si ese nodo central cayera, la red dejar\'\i a de funcionar.

  \item {\bf \'Arbol.}

Cada nodo puede tener unido a \'el varios nodos hijos y est\'a unido a un nodo
 padre, menos el nodo ra\'\i z y los nodos hoja.

 Una variante muy usada es el \'arbol binario en el que cada nodo tiene como
 m\'aximo 2 nodos hijos.
 Esto hace que se puedan hacer varios c\'alculos (recorridos, ...) de forma m\'as efectiva.

 Una mejora de este \'arbol es el \'arbol jer\'arquico que consta de m\'as enlaces
 seg\'un se sube en las ramas del \'arbol, esto es as\'\i\ porque los padres tienen
 que llevar a cabo todas las comunicaciones que quieran hacer sus hijos
 que no tengan como destinatarios a sus hermanos y como a cuanta m\'as altura
 m\'as hijos tiene cada padre (entendiendo por hijos: hijos, nietos, bisnietos,
 etc.) hay m\'as comunicaciones de las que el padre se tiene que hacer cargo por
 lo que se necesitan m\'as posibilidades de comunicaci\'on.
 Los pasos que tiene que seguir un dato de uno de los nodos para que llegar
 a su nodo m\'as lejano es $2*log(n+1)-2$ .

  \item {\bf Malla.}

Los nodos est\'an conectados en una red 2D. Cada uno se conecta
 con otros cuatro nodos excepto los nodos que est\'an en los bordes de la
 malla que se conectan a 2 o 3 nodos.
 El aspecto que tiene esta forma de conectar una red es como un tablero
 de ajedrez donde los puntos donde se cruzan las l\'\i neas son los nodos y
 las l\'\i neas son los medios de comunicaci\'on.
 Los pasos que se tienen que seguir para que un dato llegue de un nodo a
 su nodo m\'as alejado son $2*r-2$  siendo {\tt r} el n\'umero de nodos por lado que hay.
 Suele implementarse en circuitos para soportar multiprocesadores.

  \item {\bf Sist\'olica.}

Muy parecida a la malla 2D pero existen m\'as
 conexiones entre los elementos: 6 conexiones. Es una red m\'as cara de construir pero
 que necesita menos pasos para llegar los datos de un nodo a otro nodo.
 
  \item {\bf Totalmente conectada.}

Esta red es la m\'as cara de construir porque cada nodo
 est\'a conectado a todos los dem\'as. Esto permite que un dato
 llegue de un nodo a cualquier otro en 1 paso, minimiz\'andose al m\'aximo el
 tiempo gastado en el traspaso de informaci\'on.
 Esta configuraci\'on s\'olo es viable para un n\'umero de nodos peque\~{n}o.

  \item {\bf Hipercubo.}

Es una malla de {\tt N} dimensiones, este n\'umero de dimensiones es el grado del hipercubo.
 En esta malla cada nodo conecta con un n\'umero de nodos igual al grado del
 hipercubo, el n\'umero de nodos del que dispone el hipercubo es $2^{N}$.
 En esta configuraci\'on todos los nodos son iguales, conectan con el mismo
 n\'umero de nodos.

 Aunque es un poco dif\'\i cil de visualizar con grados mayor que el grado tres,
 es una configuraci\'on bastante usada (Intel hizo en su d\'\i a una red de este
 tipo con procesadores 286).
\end{itemize}
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -100 660 0 0, scale=.5]{./pics/topologia_redes_estaticas.png}
        \vspace{4.5in}
        \caption{La importancia de la red. Topolog\'\i a de redes est\'aticas}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/topologia_redes_estaticas}
        \caption{La importancia de la red. Topolog\'\i a de redes est\'aticas}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}
\subsubsection{Redes din\'amicas}
Estas redes cambian su topolog\'\i a din\'amicamente: cuando dos nodos necesitan
 conectarse la red puede cambiar de tal forma que se puedan conectar, as\'\i\ 
 no se necesita pasar por todos los nodos o crear una complicada estructura
 de conexi\'on.
 En el caso anterior los nodos ten\'\i an que proveer de las capacidades que
 necesitaba la red (por ejemplo el nodo central de una red tipo estrella
 ten\'\i a que tener caracter\'\i sticas especiales) .
 Este es el caso donde la red es controlada por los nodos.
 La red est\'a formada de cajas de conmutaci\'on: cambiando las cajas de conmutaci\'on
 se cambia la red.

Hay dos tipos de redes din\'amicas:
\begin{itemize}
  \item {\bf Redes monoetapa:} s\'olo necesitan un paso para conectar dos nodos diferentes
 (una sola etapa).

  \item {\bf Redes multietapa:} realizan las conexiones entre los nodos en m\'as de un paso.
\end{itemize}
En las redes monoetapa si no se puede acceder desde cualquier elemento a
 otro cualquiera se necesita recircular la informaci\'on.

 Dentro de este tipo de redes es de especial inter\'es el caso de la red de
 barras cruzadas: los procesadores tanto formando una linea en horizontal
 como en vertical y unas vias los conectan; cuando un procesador se quiere
 comunicar con otro, la posici\'on (proc X, proc Y) se activa con lo que se
 hace una conexi\'on.
 
 Esto permite que todos los procesadores puedan mantener conexiones independientes.
 Mientras que no haya dos procesadores que quieran comunicarse con un mismo
 procesador no habr\'a ning\'un problema.
 Este esquema es bastante caro y no merece la pena si no se hacen muchas
 conexiones simult\'aneas.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -250 240 0 0, scale=.5]{./pics/barras_cruzadas.png}
        \vspace{2in}
        \caption{La importancia de la red. Barras cruzadas}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/barras_cruzadas}
        \caption{La importancia de la red. Barras cruzadas}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}
Las redes multietapa son m\'as complejas.
 Para comprenderlas primero tenemos que comprender las cajas de conmutaci\'on.
 Las cajas de conmutaci\'on tienen dos entradas y dos salidas.
 Para un ejemplo las entradas se llamaran {\tt e1} y {\tt e2} y las salidas {\tt s1} y {\tt s2}.
 Se pueden formar cuatro posibles configuraciones, seg\'un se relacionan las
 entradas con las salidas:
\begin{itemize}
  \item Paso directo: las dos entradas pasan directamente a las 2 salidas.
 La entrada {\tt e1} sale por la salida {\tt s1} y la entrada {\tt e2} sale por la entrada
 {\tt s2}.

  \item Cruce: las salidas salen en sentido inverso a las entradas.
 La entrada {\tt e1} se conecta con la salida {\tt s2} y la entrada {\tt e2} se conecta con
 la salida {\tt s1}.

  \item Difusi\'on inferior: \'esta y la siguiente configuraci\'on se usan para hacer 
 broadcast. En esta configuraci\'on la entrada {\tt e1} se conecta a la salida {\tt s1} y {\tt s2} y la
 entrada {\tt e2} se deja sin conectar. Por lo tanto se asegura que
 por {\tt e2} no est\'a pasando una comunicaci\'on para realizar esta operaci\'on.

  \item Difusi\'on superior: similar al caso anterior, pero ahora es la entrada {\tt e2}
 la que se conecta a las salidas {\tt s1} y {\tt s2} y la entrada {\tt e1} la que no se conecta
 a nada.
\end{itemize}

 Se pueden dividir las redes multietapa en tres tipos:
\begin{itemize}
  \item Con bloqueo: en estas redes para llegar de un nodo a otro solo hay un camino,
 para ahorrar conexiones, gracias a las cajas de conmutaci\'on varios caminos
 van a una caja por lo que puede ocurrir que la conexi\'on simult\'anea de varios
 nodos produzca conflictos.
 Tras realizar una asociaci\'on entre dos nodos, intentar hacer otra asociaci\'on
 puede bloquear.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -200 230 0 0, scale=.7]{./pics/red_din_con_bloqueo.png}
        \vspace{2.5in}
        \caption{La importancia de la red. Red din\'amica con bloqueo}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/red_din_con_bloqueo}
        \caption{La importancia de la red. Red din\'amica con bloqueo}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}
En este ejemplo si los dos primeros nodos quieren conectar con el primer
 nodo, tendr\'an que esperar porque los dos necesitan el mismo enlace.

  \item Reordenables: existen varios caminos para llegar al mismo lugar, siempre
 se puede conectar otro camino, pero quiz\'as habr\'\i a que reordenar la situaci\'on.
 Estas redes son m\'as complejas pero aunque se necesite reordenaci\'on, podemos
 conectar simult\'aneamente los nodos.
 Adem\'as estas redes se pueden construir de un tama\~{n}o arbitrario usando el
 m\'etodo de red de benes, solo hay que unir redes de este tipo de potencia
 de 2 para conseguirlo.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -200 240 0 0, scale=.5]{./pics/red_din_reordenable.png}
        \vspace{2in}
        \caption{La importancia de la red. Red din\'amica reordenable}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/red_din_reordenable}
        \caption{La importancia de la red. Red din\'amica reordenable}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}

  \item Sin bloqueo: estas redes pueden manejar todas las conexiones posibles sin
 que se produzcan bloqueos, para conseguir esto, todas las cajas de conmutaci\'on
 de un nivel (una columna) se conectan a todas las cajas de conmutaci\'on
 de la siguiente columna.
\end{itemize}
%===========================================================================
\subsection{Tecnolog\'\i as de red}
Van a verse las tecnolog\'\i as de red m\'as usadas en el clustering.
 Estas tecnolog\'\i as son las mismas que imperan en el mundo de las redes locales
 de medio y alto rendimiento y son:
\begin{itemize}
  \item Serie 
  \item Ethernet
  \item Fast Ethernet
  \item Gigabit Ethernet
  \item ATM
\end{itemize}
Por supuesto estas no son las \'unicas tecnolog\'\i as existentes, pero si que
 son las m\'as comunes. Las comunicaciones a trav\'es de Token Ring o sus derivados quedan
 fuera de este tema.
\begin{itemize}
  \item Serie: puede ser un poco sorprendente ver este m\'etodo de comunicaci\'on aqu\'\i\,
 pero al menos una aplicaci\'on muy importante puede usarlo por lo
 que puede ser un buen m\'etodo de comunicaci\'on si se necesita una forma sencilla
 de comunicarse con otro nodo.
 
 La aplicaci\'on que usa este m\'etodo es Heartbeat del que se habla con m\'as
 detalle en el cap\'\i tulo de clusters HA.
 La comunicaci\'on serie es perfecta para esta aplicaci\'on pues sus peque\~{n}os pulsos no necesitan
 gran ancho de banda pero en un medio compartido como Ethernet pueden ocasionar
 colisiones que afecten en gran medida al rendimiento de otras comunicaciones
 que se lleven a cabo en el cluster.

  \item Ethernet:  la velocidad m\'axima te\'orica es de 10 Mb/segundo y aunque hace pocos a\~{n}os
 era un estandar y estaba muy extendido el uso de esta tecnolog\'\i a en redes
 locales, la ca\'\i da de los precios de los equipos de 100 Mb/segundo (Fast Ethernet) ha hecho
 que esta tecnolog\'\i a quede desfasada.
 
Ethernet est\'a especificado en el estandard IEEE 802.3, es {\em half
duplex}. Existe un medio compartido que f\'\i sicamente puede ser
topolog\'\i a tipo bus (por ejemplo de cable coaxial) o en topolog\'\i a
tipo estrella con un {\em hub} o un {\em switch} como elemento central.
 El acceso al medio compartido se gestiona con CSMA/CD ({\em Carrier
 Sense Medium Access/Colision Detection}) Esto quiere decir que la
 tarjeta de red antes de enviar la informaci\'on {\em escucha la
 linea} mirando el voltaje de la l\'\i nea sabe si hay datos o no en
 ella.

 Si no hay datos, env\'\i a sus datos y se pone a escuchar la l\'\i nea, si el voltaje
 es superior a un determinado umbral, m\'as de una tarjeta est\'a intentando
 enviar datos a la l\'\i nea a la vez.
 En este caso, se considera que los datos que se enviaron se enviaron con
 errores y se vuelve a intentar enviarlos tras un tiempo aleatorio ($
 2^{i} -1$, siendo $i$ el n\'umero de intento). Este m\'etodo de acceso
 al medio impone ciertas condiciones a las redes Ethernet. Por ejemplo
 tiene que haber un tama\~{n}o m\'\i nimo de paquete (46 bytes) y una longitud m\'axima de segmento.

Es de especial menci\'on la gran diferencia que existe entre usar un
{\em hub} y un {\em switch}. El {\em hub} simplemente conecta todos
los cables que le entran con todos, sirve pues para tener una topolog\'\i a
 f\'\i sica de estrella. A su vez pero se obtiene una topolog\'\i a l\'ogica de bus; esto
tiene la ventaja de que si se corta un cable s\'olo se incomunica un
 ordenador, no todos.
 El {\em switch} en cambio, a parte de tener la misma funci\'on que el
 {\em hub}, s\'olo conecta los cables de los ordenadores que se est\'an comunicando.
 
Hay 2 tipos de {\em switch}: 
\begin{itemize}
  \item {\em Cut-through} (al vuelo): en cuanto lee la direcci\'on de
 destino del paquete lo reenv\'\i a por el cable adecuado, as\'\i\
 varios ordenadores pueden estar comunic\'andose simult\'aneamente
 siempre que las parejas de ordenadores que se comunican sean distintas.

  \item Almacenamiento y reenv\'\i o: similar al anterior pero no env\'\i a un paquete hasta
 que lo tiene completo. Esto evita algunas colisiones y elimina los paquetes
 err\'oneos lo antes posible, adem\'as aporta mejora en la gesti\'on de la red,
 como conteo de paquetes, filtros y otras opciones que dependen de cada
 fabricante en cuesti\'on, el problema es que la latencia de la red aumenta.
\end{itemize}

  \item {\em Fast Ethernet}: Utiliza la misma t\'ecnica que Ethernet pero con velocidades de 100 Mb/segundo,
 puede usar el cableado existente por lo que los cambios se reducen a las
 tarjetas de red (hoy en d\'\i a las mismas tarjetas de 10 Mb/segundos tambi\'en
 tienen soporte para esta tecnolog\'\i a) y a los concentradores (en los que
 s\'\i\ que hay que hacer mayores inversiones pues son bastante m\'as caros).
 Existen concentradores con puertos 10/100 para facilitar la migraci\'on a
 esta tecnolog\'\i a.
 
 Como la trama m\'\i nima sigue del mismo tama\~{n}o, el tama\~{n}o m\'aximo de estas
 redes tiene que ser 10 veces inferior para poder detectar cualquier colisi\'on.
 Est\'a normalizado en el 802.3u.

  \item {\em Gigabit Ethernet}: esta es la tecnolog\'\i a Ethernet de
 m\'as reciente aparici\'on, que consigue velocidades de 1 Gbps o
 superiores y es compatible con las dos tecnolog\'\i as anteriores.
 Se disminuye la distancia para detectar colisiones.
 Se puede usar cables de categor\'\i a 5 pero para grandes distancias se recomienda
 el uso de fibra \'optica.
 Cuando lo que se necesita es una red LAN de alt\'\i simas prestaciones (como
 la que puede necesitar un cluster) y se dispone del dinero necesario, la
 elecci\'on est\'a entre esta tecnolog\'\i a y ATM.

  \item ATM: se basa en una tecnolog\'\i a de conmutaci\'on de celdas.
 Las celdas son de un tama\~{n}o fijo (53 bytes, 5B cabecera + 48B datos), esto
 simplifica en gran medida el procesamiento de las celdas, acelerando la
 conmutaci\'on y disminuyendo el retardo.
 Da muchos servicios de valor a\~{n}adido de los que no dispone Ethernet, por
 ejemplo permite que la velocidad de transferencia sea fijada din\'amicamente
 bajo demanda.
 
 No s\'olo eso, sino que puede garantizar otros factores, como el retardo,
 por lo que la gran ventaja es el QoS (calidad de servicio) que de forma inherente proporciona.
 Es una red orientada a conexi\'on y tiene
 un control del tr\'afico y de la congesti\'on muy eficiente.
 Los problemas que plantea frente a otras soluciones es que es una alternativa
 muy cara: la tecnolog\'\i a es compleja y a\'un no existen muchas aplicaciones
 desarrolladas.
 \end{itemize}
%===========================================================================
\subsection{Protocolos utilizados a nivel de red}
Otro tema importante aparte de las topolog\'\i as o tecnolog\'\i as de red utilizadas
 son los protocolos que se adaptan mejor a sistemas cluster.
Generalmente la tecnolog\'\i a de red de cluster
 m\'as utilizada suele ser ATM o Ethernet y dado el precio de los dispositivos
 ATM suele ser normalmente la segunda.

 En cualquier caso, el protocolo m\'as extendido en el uso de las redes de
 cualquier tipo actualmente es IP (Internet Protocol).
 IP permite trabajar sobre cualquier tecnolog\'\i a de red, ya que es independiente
 del medio de comunicaci\'on f\'\i sico.
 IP es un protocolo no orientado a conexi\'on y no fiable que se basa en t\'ecnicas
 de {\em el mejor esfuerzo} (best effort) para encaminar sus
 paquetes. Esto es en cierto modo una ventaja, en el caso de que se
 utilice sobre redes no conectivas como pueden ser Ethernet, o una
 desventaja en redes ATM. En cualquier caso la adaptabilidad del
 protocolo IP a cualquier red mediante capas que act\'uan de interfaz
 permite situar este protocolo por encima de ATM, Frame Relay, Ethernet o redes
 LAN en general e incluso sobre l\'\i neas serie o paralelo.
 
El protocolo IP se encarga de cumplir los siguientes objetivos en una comunicaci\'on:
\begin{itemize}
  \item Definir el formato de bloques de datos que ser\'a enviado, para evitar errores
 de cabecera o tipo de archivos.

  \item Esquema de direccionamiento.

  \item Movimiento de datos entre nivel de transporte y nivel de red, dependiente
 de cada implementaci\'on.

  \item Encaminamiento de los datagramas.

  \item Fragmentaci\'on y agrupaci\'on de los datagramas en el caso de que sea necesario
 al pasar el paquete por redes de MTU m\'as peque\~{n}a.
\end{itemize}
Es un protocolo ampliamente utilizado y con muchos a\~{n}os de uso.
 La pr\'actica totalidad de los sistemas que se conectan a redes tienen alguna
 implementaci\'on IP ya sea completa o incompleta, lo que nos permite tener
 redes de equipos hetereog\'eneos.
 IP no es s\'olo un protocolo aislado, sino que trabaja en conjunto con otros
 protocolos como TCP para realizar transmisiones.
 Estos protocolos son ICMP e IGMP en el nivel de red\footnote{Aunque
 estos esten en el nivel de red, son encapsulados en datagramas IP} y
 TCP y UDP en el nivel de transporte.

El protocolo ICMP (Internet Control Message Protocol) se encarga de
 mandar mensajes de control: errores en host, fallos de encaminamiento y
 mensajes similares, entre los host de la red. IGMP (Internet Group Message Protocol) se encarga
 de mantener actualizada la informaci\'on relativa a la creaci\'on de grupos
 para la multidifusi\'on, broadcast o multicast.
 El conjunto de estos protocolos dotan a la soluci\'on de una completa solidez
 en uso y funcionamiento.

El formato de bloques de IP no interviene en el factor de dise\~{n}o de
 clusters, adem\'as, en el caso de IP, permite reducir bastante
 el tama\~{n}o de los paquetes que hay que enviar o ampliarlos al m\'aximo de
 lo que nos permita la red.
 El esquema de direccionamiento tampoco es un problema para los clusters,
 aunque empieza a serlo a nivel mundial por la escasez de direcciones.
 Se espera que en poco tiempo la red vaya migrando a IPv6, en cualquier
 caso desde el punto de vista particular de los clusters el uso de IPv6
 o IPv4 no tiene por que ser dr\'astico e incluso puede favorecernos esta
 migraci\'on por hacer que los paquetes sean m\'as
 configurables.
 
Respecto al encaminamiento y la fragmentaci\'on de los datagramas, permiten
 tener clusters diseminados por una geograf\'\i a m\'as extensa.
 Generalmente los clusters suelen localizarse en un mismo aula, edificio
 o entorno, pero existen problemas para los que pueden ser necesarias redes
 de \'area extensa para los que IP ya esta ampliamente comprobado y utilizado,
 como por ejemplo organizaciones internacionales o empresas multinacionales.

Este documento no pretende ser muy duro en cuanto a la teor\'\i a de
 redes. Lo b\'asico para configurar la necesaria para interconectar
 nuestros nodos. Lo que s\'\i\ es necesario es dar una explicaci\'on de porqu\'e utilizar IP en
 clusters.
 \begin{itemize}
  \item Ampliamente utilizado, conocido y comprobado.
  \item Efectividad en la mayor\'\i a de las redes probadas.
  \item Perfecto para ambientes hetereog\'eneos.
\end{itemize}
El principal motivo para utilizar IP es que en la mayor\'\i a de los casos y
 a pesar de que pueda consumir en muchos casos demasiado ancho de banda
 o capacidad de proceso, es mejor utilizar un protocolo comprobado y v\'alido
 que uno a desarrollar para un sistema concreto. 

Existen otros protocolos de red que se han utilizado para entornos distribuidos
 como pueden ser IPX/SPX, Appletalk u otros; e incluso algunas soluciones se han basado
 directamente sobre capas de nivel de enlace para efectuar las comunicaciones
 entre los nodos. GNU/Linux soporta sin problemas todos estos protocolos.
 
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = 0 490 0 0, scale=1]{./pics/encapsulamiento_ip.png}
        \vspace{7in}
        \caption{La importancia de la red. Encapsulamiento IP}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/encapsulamiento_ip}
        \caption{La importancia de la red. Encapsulamiento IP}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}
%===========================================================================
\subsection{Protocolos utilizados a nivel de transporte (UDP/TCP)}
%---------------------------------------------------------------------------
\subsubsection{Protocolos de transporte}
Los protocolos de red est\'an divididos por capas. En la subsecci\'on anterior
 se ha visto la capa de red, ahora se dar\'a paso a las capas que existen a nivel
 de transporte: UDP y TCP.

La mayor\'\i a de los protocolos de transporte tienen elementos comunes.
 Los protocolos orientados a conexi\'on deben tener mecanismos para establecer
 y liberar conexiones.
Cuando hay m\'ultiples conexiones abiertas en una misma m\'aquina, las entidades
 de transporte tendr\'an que asignar un n\'umero a cada conexi\'on y ponerlo en
 el mensaje.
 
 En sistemas operativos UNIX y para la red ARPANET existen dos enfoques
 para saber a que puerto acceder a un servicio:
\begin{itemize}
  \item Un servidor de puertos escuchando en el UDP/TCP 111 atendiendo solicitudes,
 los servidores registran el nombre del servicio y el puerto en donde est\'a
 escuchando, permaneciendo dormidos hasta que les llega una solicitud.
  \item Los puertos los conocen los clientes que tienen el fichero {\em
 /etc/services}; hay un servidor ({\em inetd} o {\em xinetd}) que escucha en todos
 los puertos que se quieran mantener abiertos, cuando llega una
 solicitud crea un nuevo proceso que se encarga de atender la solicitud.
 Al cliente le da la impresi\'on de que el servicio est\'a siempre activo.
\end{itemize} 
Otras de las caracter\'\i sticas comunes de todos estos protocolos de nivel
 de red y que hacen este nivel tan \'util es el control de flujo.
 Si por debajo del protocolo de red hay una red fiable (X.21)
 o nuestro protocolo no a\~{n}ade fiabilidad a la red (UDP) entonces no ser\'a necesario
 usar el control de flujo de la capa de transporte.

 En otro caso el control de flujo es fundamental.
 El emisor tiene una copia local de cada mensaje que se env\'\i a por la red
 hasta el momento que es asentido, el receptor quiz\'as no desee enviar un
 ACK ({\em acknowledgement} o asentimiento) de ese mensaje, o no recibi\'o el mensaje correctamente; en esos casos
 el ordenador que est\'a enviando los mensajes tiene que reenviar el mensaje,
 por ello la necesidad de tener una copia local.
 
 Con este sistema el receptor puede limitar el tr\'afico que recibe simplemente
 tardando m\'as tiempo en asentir los datos recibidos.
 As\'\i\ cada uno de estos protocolos define unos temporizadores y unas reglas
 para no s\'olo controlar el flujo sino controlar que no se produzca congesti\'on
 en la red.

Otro punto en com\'un de todos los protocolos de transporte es que permiten
 la multiplexi\'on y demultiplexi\'on de las conexiones, para aumentar el ancho
 de banda y aprovechar mejor los recursos de los que se disponga.
%---------------------------------------------------------------------------
\subsubsection{UDP}
Es el protocolo de transporte no fiable est\'andar en Internet. Como protocolo
 de transporte que es solamente est\'a implementado en ordenadores finales, no en routers.
 Es un protocolo no orientado a conexi\'on (de ah\'\i  su nombre, se
 env\'\i an datagramas) y no es fiable. La cabecera que incluye al
 mensaje es la m\'\i nima para poder distinguir a que puerto se dirige
 y un peque\~{n}o {\em checksum} de la cabecera. Es usado por las
 aplicaciones de los servicios no conectivos, para
 enviar pocos datos (se consigue m\'as rendimiento puesto que no se
 necesita gastar tiempo en conectar y desconectar) y en
 multidifusi\'on. 
 
UDP al contrario de TCP no puede realizar fragmentaciones de los mensajes
 puesto que no tiene campos para ello.
 Por tanto es la aplicaci\'on quien debe dividir los mensajes como crea oportuno.
 Como la tecnolog\'\i a f\'\i sica de red tambi\'en impone una restricci\'on de tama\~{n}o
 m\'aximo de paquete, otra divisi\'on se realiza en el nivel IP; por tanto una
 aplicaci\'on que conociera la MTU evitar\'\i a esta segunda divisi\'on.
 Cuando uno de los fragmentos de un mensaje UDP se pierde se tendr\'\i a que
 retransmitir.
 
 En el caso de UDP ser\'a la aplicaci\'on la encargada, gracias a unos temporizadores,
 de retransmitirlo. En el caso de TCP es \'el mismo el que detecta
 y soluciona e problema.
 
 Como sabemos IP si no puede recomponer un datagrama, lo desecha, no tratando
 el problema y dejando la soluci\'on a capas superiores.

Algunos capas superiores que usan UDP son RPC y todos los aplicaciones que
 dependen de estos (DNS, NIS, etc.) y otras aplicaciones como pueden ser
 TFTP, BOOTP, DHCP.
%---------------------------------------------------------------------------
\subsubsection{TCP}
Este protocolo junto con UDP son los dos protocolos de transporte est\'andar
 en Internet, es el protocolo fiable de la familia.
 Es un protocolo orientado a conexi\'on.
 TCP recibe mensajes de cualquier tama\~{n}o y los divide en trozos de un m\'aximo
 de 64KB se env\'\i a cada uno de estos trozos como un mensaje TCP separado.
 Para evitar fragmentaciones extra, TCP conoce la MTU de la red, con lo
 que se evita que el nivel de red tenga que dividir a su vez para acoplarse
 al MTU de la red.

Tambi\'en es misi\'on de TCP ordenar todos los segmentos que hayan llegado separados
 y ensamblarlos para obtener el mensaje inicial.
 Tiene la ventaja de que las aplicaciones no tienen que preocuparse de tratar
 los errores de la comunicaci\'on puesto que para la aplicaci\'on el canal de
 comunicaci\'on es perfecto y siempre llega la informaci\'on integra.

El que sea un servicio orientado a conexi\'on quiere decir que hay 3 fases
 en la comunicaci\'on, que forman un m\'\i nimo de 7 mensajes sin contar los mensajes
 de datos:
\begin{itemize}
  \item Establecimiento de la conexi\'on: es la fase inicial, para conectarse los
 paquetes tienen un bit especial llamado SYN.
 Para conectarse se debe enviar un segmento con SYN activado y recibir una
 confirmaci\'on ACK.
 Se toman unos nuevos n\'umeros de secuencia para enviar y para recibir que
 empiezan siendo un n\'umero muy superior al \'ultimo n\'umero de secuencia recibido
 por si llegan segmentos de la conexi\'on anterior y se empieza la conexi\'on,
 esto son 3 mensajes.
  \item Traspaso de informaci\'on: t\'\i picamente aqu\'\i  se env\'\i an todos los datos que
 se quieren enviar, el nivel de aplicaci\'on ver\'a como todos los datos que
 env\'\i a, llegan correctamente (si es f\'\i sicamente posible) y en orden.
  \item Liberaci\'on de la conexi\'on: se realiza gracias a un bit que indica que se
 desea finalizar con la conexi\'on actual llamado FIN.
 Cuando un extremo activa su bit FIN, su interlocutor tiene que hacer un
 ACK y hasta que no lo desee puede posponer el cierre de la comunicaci\'on,
 cuando est\'e listo env\'\i a un paquete con el bit FIN activado y el primer
 ordenador realiza un ACK, liberando la conexi\'on.
\end{itemize}
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -200 350 0 0, scale=.6]{./pics/conexion_tcp.png}
        \vspace{3in}
        \caption{La importancia de la red. Conexi\'on TCP}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/conexion_tcp}
        \caption{La importancia de la red. Conexi\'on TCP}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}
TCP cada vez que env\'\i a un segmento inicia un temporizador. Si este temporizador
 cumple y no se ha recibido confirmaci\'on se vuelve a enviar el mismo segmento
 suponiendo que el anterior segmento enviado no lleg\'o o lleg\'o con errores.
 Como no se puede saber a ciencia cierta cu\'anto tardar\'a un segmento a llegar
 a su destino, pues dependiendo del paquete podr\'\i a pasar por una redes u
 otras, haber congestiones moment\'aneas, etc.
 se implementa un temporizador variable que ir\'a cambiando seg\'un lo que tardaron
 los ACK de los anteriores segmentos.

La peor situaci\'on que le puede ocurrir a una red f\'\i sicamente bien es que
 tenga congesti\'on, por eso esta situaci\'on se intenta evitar a toda costa,
 y los protocolos orientados a conexi\'on son mejores para evitarla, por eso
 TCP intenta hacer un control de congesti\'on en Internet.
 Quien m\'as r\'apidamente puede reaccionar ante la congesti\'on es el emisor,
 por tanto cuando seg\'un acabamos de ver se cumple el temporizador de
 retransmisi\'on hay error o hay congesti\'on, como las redes actuales
 son de muy buena calidad es muy dif\'\i cil que el error sea a causa del medio de transmisi\'on
 por lo tanto el emisor supone que existe congesti\'on con lo que env\'\i a los
 datos de forma m\'as lenta, siguiendo un algoritmo, con esto se intenta que
 se alivie la congesti\'on de la red.

Para controlar el flujo y la congesti\'on se usa la ventana deslizante que
 permite enviar varios paquetes antes de que se env\'\i e un ACK, enviar un
 ACK por cada paquete es realmente lento por lo tanto cuando se quiere disminuir
 la velocidad por el peligro de congesti\'on o porque el receptor no puede
 recibir tantos datos la ventana disminuye dejando enviar menos paquetes
 por ACK, pudiendo llegar a ser 0, lo que significa que el receptor no puede
 en esos momentos recibir nada m\'as.
 Cuando se quiere m\'as velocidad se deja enviar m\'as paquetes antes de parar
 para esperar un ACK.
%===========================================================================
\subsection{Dise\~{n}o de redes}
A la hora de poner en marcha un cluster ya sea a nivel de producci\'on como
 a nivel de investigaci\'on, hemos de tener en cuenta que uno de los factores
 cr\'\i ticos a la hora de configurar dicho sistema va a ser la red.
 
  Antes de comenzar a instalar el sistema propiamente dicho, se debe hacer
 un estudio de que servicios o programas debe correr, y tener en cuenta
 c\'omo \'estas van a afectar a la carga en la red.
 Este apartado es bastante importante en la instalaci\'on de redes por los
 siguientes motivos.
\begin{enumerate}
\item El coste de instalac\'\i on puede llegar a ser insignificante respecto al coste
 que puede llevar una ampliaci\'on en un sistema que ha sido mal dise\~{n}ado
 desde un principio, tanto a nivel f\'\i sico en la instalaci\'on (en la cual
 no entraremos) como a nivel de capacidad de la red.
\item La mayor\'\i a de los clusters est\'an montados sobre redes
 LAN, con protocolos UDP/IP o TCP/IP, generalmente no tienen ninguna manera
 de controlar la congesti\'on de la red, lo que implica que la red debe estar
 lo suficientemente bien dise\~{n}ada y montada como para que se produzca congesti\'on
 s\'olo en casos excepcionales.
\item Se debe tener en cuenta, que cuanto m\'as acoplado sea un sistema en su funcionamiento,
 m\'as cr\'\i tica se vuelve la comunicaci\'on, por tanto mejor dise\~{n}ada debe
 estar la red de comunicaci\'on.
\item El coste que se produce al escalar un cluster, tanto econ\'omicamente como
 en tiempo no debe estar muy ligado al coste de escalar la red.
 \end{enumerate}
Como se puede ver, a lo largo de todo el proceso el funcionamiento de la
 red es cr\'\i tico en cualquier sistema de tipo cluster, es m\'as, no s\'olo es
 necesario un entorno de red adecuado para el sistema, sino que este debe
 estar en cierta manera infrautilizado para poder asegurar que no se va
 a llegar a condiciones de congestionamiento.
%---------------------------------------------------------------------------
\subsubsection{Factores a tener en cuenta al dise\~{n}ar una red}
A la hora de dise\~{n}ar una red tenemos que tener claros ciertos conceptos
 acerca del sistema que queremos instalar, el funcionamiento que \'este debe
 tener, los servicios que debe tener y sobre todo, la funcionalidad que
 se le va a dar.
 
 Hay que conocer la funcionalidad del
 sistema:
\begin{itemize}
  \item Funcionalidad del sistema
  \begin{itemize}
  \item Funcionalidad general para la que el sistema debe funcionar.
  \item Servicios que deber\'a correr el sistema.
  \item Factores que externos que pueden afectar a nuestro sistema.
   \end{itemize}
\end{itemize}
Todos estos puntos quiz\'a entren en el \'ambito de la administraci\'on
 del sistema, pero son necesarios en el caso de partir de cero, con la primera
 instalaci\'on de un cluster.
 Lo que pretenden es que no haya problemas a la hora de tener claro que
 servicios o funcionalidades est\'an por encima de que otras.

No existe ning\'un sistema cluster de car\'acter general,
 la mayor\'\i a de ellos se compone de varias aplicaciones trabajando juntas.
 Si estas aplicaciones deben acceder a recursos compartidos, hay que
 tener claras dos cosas: cu\'ales tienen m\'as prioridad, y c\'omo obtener la
 prioridad.
 Por otro lado est\'an los factores t\'ecnicos que afectan a los servicios que
 utilizar\'a la red.
 Una vez que se sabe los servicios que poseer\'a el cluster es necesario describir
 el tipo de funcionamiento que tiene cada servicio y dem\'as caracter\'\i sticas.
\begin{itemize}
  \item Factores t\'ecnicos de cada servicio relativos a la red.
  \begin{itemize}
    \item Funcionalidad del servicio.
    \item Prioridad del servicio en el sistema.
    \item Rrioridad del servicio en la red.
    \item Factor de carga del sistema.
    \item Factor de carga de la red.
    \item Caracter\'\i sticas de la comunicaci\'on que realiza el servicio.
    \begin{itemize}
      \item Tiempos de latencia
      \item Tipo de protocolos UDP, TCP.
      \item Carga sobre la red a nivel general.
    \end{itemize}
  \end{itemize}
\end{itemize}
Todos los factores t\'ecnicos deben estar referidos a cada servicio particular.
 Para usuarios expertos puede ser obvio que programas o servicios acaparan
 m\'as la red o deben tener m\'as prioridad, para alguien profano a ese servicio,
 o parte del sistema deber\'a rellenar solamente los factores te\'oricos que
 el crea oportunos.

 A partir de este apartado, el dise\~{n}ador de la red debe conocer cada uno
 de los servicios que la red va a utilizar tanto con conocimiento te\'orico
 como pr\'actico para poder tener una visi\'on generalizada.
 Esta visi\'on debe ser tanto de como puede afectar este servicio a otros
 y al sistema en general como para tener los conocimientos necesarios para
 instalar el servicio sin que este provoque problemas de ning\'un tipo.
 Cuando un dise\~{n}ador inexperto no haya instalado un sistema o un servicio
 de este tipo, lo conveniente es hacer uso de un entorno de simulaci\'on reducido
 en el cual hacer las instalaciones pruebas y verificaciones para despu\'es
 proceder a realizar extrapolaciones a un sistema grande, se ha de recordar
 siempre que la depuraci\'on de un error en un sistema distribuido crece exponencialmente
  con el n\'umero de nodos que tiene el sistema, y en el caso de que
 \'este utilice varios servicios a la vez, el crecimiento de la complejidad
 crece m\'as a\'un a medida que escala el cluster.

 Cuando intervienen varios sistemas, todos ellos complejos y completos en
 un entorno distribuido, se debe tener el suficiente conocimiento de cada
 uno de los sistemas a montar como para asegurar que el conjunto de todos
 ellos no desestabilizara el funcionamiento de los otros.

El siguiente punto a tener en cuenta es hacer aproximaciones a las necesidades
 de red que se han extrapolado de cada servicio, y saber de que recursos
 se cuentan para satisfacer estas necesidades.
 En este punto, se debe exigir un equilibrio entre los recursos que se tienen
 y la efectividad de dicho funcionamiento.

 Por ejemplo, en un entorno de trabajo con openMosix, NFSROOT y XWindow en un
 laboratorio de investigaci\'on cient\'\i fica probablemente se d\'e m\'as importancia
 a la red openMosix que a el sistema de archivos NFS o XWindow.
 As\'\i\ que probablemente se separen dichas dos redes
 como redes aisladas de manera que NFSROOT o X Window no interfieran sobre
 openMosix y al mismo tiempo openMosix est\'e aislado: sus paquetes de informaci\'on
 de estado de cada nodo no interrumpir\'an las comunicaciones largas debido a colisiones
 cuando openMosix est\'a en un estado sin migraciones.
\begin{itemize}
  \item Localizar recursos de los que se dispone o saber con que
  medios se cuentan.
  \begin{itemize}
    \item equipos o nodos
    \item{\em switches/hubs}
    \item routers
    \item otros servicios como impresoras en red y dem\'as que puedan afectar la carga
 de la red
  \end{itemize}
  \item Estimar la carga de cada red que puede llegar cada servicio contando con
 los recursos que se poseen\footnote{A la hora de estimar dicha carga,
  es necesario que \'esta sea siempre estimada a la alza, de manera
  que en el momento de la puesta a punto del sistema, no sea necesario
  escalar \'este inmediatamente despu\'es de instalarlo, lo cual ser\'\i a s\'\i ntoma de haber dise\~{n}ado mal el sistema.}.
  \item Equilibrar la carga dependiendo de:
  \begin{itemize}
    \item prioridad
    \item servicio
    \item recurso
  \end{itemize}
\end{itemize}
En este caso no cuenta tanto el conocimiento del sistema, una vez que se
 conoce como puede llegar a cargar un servicio y de los recursos que se
 posee, el dise\~{n}ador, coloca cada servicio en redes aisladas o interconectadas,
 intentando que interfieran cuanto menos mejor los servicios entre s\'\i , en
 este apartado, se eval\'uan las tecnolog\'\i as de red aplicadas a cada servicio
 as\'\i  como de los medios de que se dispone para asegurar el funcionamiento
 y disponibilidad de los servicios.
 Por ejemplo, en el caso de Heartbeat, se suele utilizar como ya hemos visto
 un cable de serie de modem nulo, para asegurar que se produce una doble
 v\'\i a de comunicaci\'on entre los dos ordenadores que se desea
 replicar o controlar, e incluso el propio Heartbeat se encarga de
 comprobar la v\'\i a secundaria peri\'odicamente para asegurar que
 esta estar\'a disponible en el caso de que el sistema principal caiga.
%===========================================================================
\subsection{Conclusiones}
Como conclusiones de este tema hay que el sistema de comunicaci\'on
 es cr\'\i tico en cualquier sistema paralelo, ya que al tener varios elementos
 de proceso (enti\'endase por elementos de proceso a los procesadores, nodos,
 procesos, m\'odulos, etc. que componen el sistema paralelo o
 distribuido), es necesaria la comunicaci\'on entre los elementos de
 proceso para realizar un trabajo conjunto.
 
 En el caso de sistemas implementados en el kernel de un sistema operativo
 el fallo del sistema puede provocar el malfuncionamiento de una m\'aquina
 y por tanto se puede requerir del reseteo de la misma.
 
 Por \'ultimo se han dado los puntos necesarios para dise\~{n}ar una red correctamente,
 ya que generalmente cuesta m\'as escalar un sistema mal dise\~{n}ado con fallos
 respecto a los requerimientos iniciales que un sistema que sea bien dise\~{n}ado
 y quiz\'a sobredimensionado desde el principio.
