El manual para el clustering con openMosix - La importancia de la red (II)

Protocolos utilizados a nivel de red

En cualquier caso, el protocolo más extendido en el uso de las redes de cualquier tipo actualmente es IP (Internet Protocol). IP permite trabajar sobre cualquier tecnología de red, ya que es independiente del medio de comunicación físico. IP es un protocolo no orientado a conexión y no fiable que se basa en técnicas de 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úan de interfaz permite situar este protocolo por encima de ATM, Frame Relay, Ethernet o redes LAN en general e incluso sobre líneas serie o paralelo.

El protocolo IP se encarga de cumplir los siguientes objetivos en una comunicación:

• Definir el formato de bloques de datos que será enviado, para evitar errores de cabecera o tipo de archivos.

• Esquema de direccionamiento.

• Movimiento de datos entre nivel de transporte y nivel de red, dependiente de cada implementación.

• Encaminamiento de los datagramas.

• Fragmentación y agrupación de los datagramas en el caso de que sea necesario al pasar el paquete por redes de MTU más pequeña.

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ón relativa a la creación de grupos para la multidifusión, broadcast o multicast. El conjunto de estos protocolos dotan a la solución de una completa solidez en uso y funcionamiento.

El formato de bloques de IP no interviene en el factor de diseño de clusters, además, en el caso de IP, permite reducir bastante el tamaño de los paquetes que hay que enviar o ampliarlos al máximo 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ástico e incluso puede favorecernos esta migración por hacer que los paquetes sean más configurables.

Respecto al encaminamiento y la fragmentación de los datagramas, permiten tener clusters diseminados por una geografía más extensa. Generalmente los clusters suelen localizarse en un mismo aula, edificio o entorno, pero existen problemas para los que pueden ser necesarias redes de área 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ía de redes. Lo básico para configurar la necesaria para interconectar nuestros nodos. Lo que sí es necesario es dar una explicación de porqué utilizar IP en clusters.

• Ampliamente utilizado, conocido y comprobado.
• Efectividad en la mayoría de las redes probadas.
• Perfecto para ambientes hetereogéneos.

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.

Figura: La importancia de la red. Encapsulamiento IP

Protocolos utilizados a nivel de transporte (UDP/TCP)

Protocolos de transporte

La mayoría de los protocolos de transporte tienen elementos comunes. Los protocolos orientados a conexión deben tener mecanismos para establecer y liberar conexiones. Cuando hay múltiples conexiones abiertas en una misma máquina, las entidades de transporte tendrán que asignar un número a cada conexión 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:

• 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á escuchando, permaneciendo dormidos hasta que les llega una solicitud.
• Los puertos los conocen los clientes que tienen el fichero /etc/services; hay un servidor (inetd o 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ón de que el servicio está siempre activo.

En otro caso el control de flujo es fundamental. El emisor tiene una copia local de cada mensaje que se envía por la red hasta el momento que es asentido, el receptor quizás no desee enviar un ACK (acknowledgement o asentimiento) de ese mensaje, o no recibió el mensaje correctamente; en esos casos el ordenador que está 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áfico que recibe simplemente tardando más tiempo en asentir los datos recibidos. Así cada uno de estos protocolos define unos temporizadores y unas reglas para no sólo controlar el flujo sino controlar que no se produzca congestión en la red.

Otro punto en común de todos los protocolos de transporte es que permiten la multiplexión y demultiplexión de las conexiones, para aumentar el ancho de banda y aprovechar mejor los recursos de los que se disponga.

UDP

UDP al contrario de TCP no puede realizar fragmentaciones de los mensajes puesto que no tiene campos para ello. Por tanto es la aplicación quien debe dividir los mensajes como crea oportuno. Como la tecnología física de red también impone una restricción de tamaño máximo de paquete, otra división se realiza en el nivel IP; por tanto una aplicación que conociera la MTU evitaría esta segunda división. Cuando uno de los fragmentos de un mensaje UDP se pierde se tendría que retransmitir.

En el caso de UDP será la aplicación la encargada, gracias a unos temporizadores, de retransmitirlo. En el caso de TCP es él 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ón 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.

TCP

También es misión 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ón puesto que para la aplicación el canal de comunicación es perfecto y siempre llega la información integra.

El que sea un servicio orientado a conexión quiere decir que hay 3 fases en la comunicación, que forman un mínimo de 7 mensajes sin contar los mensajes de datos:

• Establecimiento de la conexión: 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ón ACK. Se toman unos nuevos números de secuencia para enviar y para recibir que empiezan siendo un número muy superior al último número de secuencia recibido por si llegan segmentos de la conexión anterior y se empieza la conexión, esto son 3 mensajes.
• Traspaso de información: típicamente aquíse envían todos los datos que se quieren enviar, el nivel de aplicación verá como todos los datos que envía, llegan correctamente (si es físicamente posible) y en orden.
• Liberación de la conexión: se realiza gracias a un bit que indica que se desea finalizar con la conexión 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ón, cuando esté listo envía un paquete con el bit FIN activado y el primer ordenador realiza un ACK, liberando la conexión.

Figura: La importancia de la red. Conexión TCP

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

Para controlar el flujo y la congestión se usa la ventana deslizante que permite enviar varios paquetes antes de que se enví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ón 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ás. Cuando se quiere más velocidad se deja enviar más paquetes antes de parar para esperar un ACK.

Diseño de redes

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ómo éstas van a afectar a la carga en la red. Este apartado es bastante importante en la instalación de redes por los siguientes motivos.

1. El coste de instalacíon puede llegar a ser insignificante respecto al coste que puede llevar una ampliación en un sistema que ha sido mal diseñado desde un principio, tanto a nivel físico en la instalación (en la cual no entraremos) como a nivel de capacidad de la red.
2. La mayoría de los clusters están montados sobre redes LAN, con protocolos UDP/IP o TCP/IP, generalmente no tienen ninguna manera de controlar la congestión de la red, lo que implica que la red debe estar lo suficientemente bien diseñada y montada como para que se produzca congestión sólo en casos excepcionales.
3. Se debe tener en cuenta, que cuanto más acoplado sea un sistema en su funcionamiento, más crítica se vuelve la comunicación, por tanto mejor diseñada debe estar la red de comunicación.
4. El coste que se produce al escalar un cluster, tanto económicamente como en tiempo no debe estar muy ligado al coste de escalar la red.

Factores a tener en cuenta al diseñar una red

Hay que conocer la funcionalidad del sistema:

• Funcionalidad del sistema
  • Funcionalidad general para la que el sistema debe funcionar.
  • Servicios que deberá correr el sistema.
  • Factores que externos que pueden afectar a nuestro sistema.

No existe ningún sistema cluster de carácter general, la mayorí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áles tienen más prioridad, y cómo obtener la prioridad. Por otro lado están los factores técnicos que afectan a los servicios que utilizará la red. Una vez que se sabe los servicios que poseerá el cluster es necesario describir el tipo de funcionamiento que tiene cada servicio y demás características.

• Factores técnicos de cada servicio relativos a la red.
  • Funcionalidad del servicio.
  • Prioridad del servicio en el sistema.
  • Rrioridad del servicio en la red.
  • Factor de carga del sistema.
  • Factor de carga de la red.
  • Características de la comunicación que realiza el servicio.
    • Tiempos de latencia
    • Tipo de protocolos UDP, TCP.
    • Carga sobre la red a nivel general.

A partir de este apartado, el diseñador de la red debe conocer cada uno de los servicios que la red va a utilizar tanto con conocimiento teórico como práctico para poder tener una visión generalizada. Esta visión 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ún tipo. Cuando un diseñador inexperto no haya instalado un sistema o un servicio de este tipo, lo conveniente es hacer uso de un entorno de simulación reducido en el cual hacer las instalaciones pruebas y verificaciones para después proceder a realizar extrapolaciones a un sistema grande, se ha de recordar siempre que la depuración de un error en un sistema distribuido crece exponencialmente con el número de nodos que tiene el sistema, y en el caso de que éste utilice varios servicios a la vez, el crecimiento de la complejidad crece más aún 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ón científica probablemente se dé más importancia a la red openMosix que a el sistema de archivos NFS o XWindow. Así 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é aislado: sus paquetes de información de estado de cada nodo no interrumpirán las comunicaciones largas debido a colisiones cuando openMosix está en un estado sin migraciones.

• Localizar recursos de los que se dispone o saber con que medios se cuentan.
  • equipos o nodos
  • switches/hubs
  • routers
  • otros servicios como impresoras en red y demás que puedan afectar la carga de la red
• Estimar la carga de cada red que puede llegar cada servicio contando con los recursos que se poseen^3.10.
• Equilibrar la carga dependiendo de:
  • prioridad
  • servicio
  • recurso

Conclusiones

En el caso de sistemas implementados en el kernel de un sistema operativo el fallo del sistema puede provocar el malfuncionamiento de una máquina y por tanto se puede requerir del reseteo de la misma.

Por último se han dado los puntos necesarios para diseñar una red correctamente, ya que generalmente cuesta más escalar un sistema mal diseñado con fallos respecto a los requerimientos iniciales que un sistema que sea bien diseñado y quizá sobredimensionado desde el principio.