Subsecciones

3.2 LA IMPORTANCIA DE LA RED

3.2.1 La importancia del sistema de comunicación

En los clusters la importancia del sistema de comunicación es grandísima. De hecho es el núcleo neurálgico por donde pasan todas comunicaciones. Si todas las comunicaciones fallan, el cluster dejará de ser un cluster y se convertirá en un conjunto de máquinas separadas que no trabajan de ninguna manera unidas. Por lo tanto es usual en sistemas cluster-HA disponer de una red alternativa por si la red principal fallara, poder seguir dando servicio. Una red es un elemento bastante fiable, es difícil que una red una vez instalada y probada un tiempo falle. En redes con topología de estrella puede haber fallos puntuales de algún cable que incomunique a un par de equipos pero fallos que hagan caer una red entera son prácticamente imposibles, significarían un fallo de hardware del hub o switch y suelen ocurrir una vez cada muchos años. Sobre las topologías y tecnologías de red que existen hablaremos en los próximos apartados.

Otro tema importante de la red es la eficiencia, de nada nos sirve una red si ésta está congestionada, por lo tanto se debe evitar la congestión como sea. Hay que tener en cuenta que todas las comunicaciones que necesitamos para que el cluster pueda operar pasan a través de la red, esto dependiendo de la cantidad de nodos que hayan en la red puede mermar mucho la eficacia del cluster. En sistemas con una red Ethernet con 10Mb/s teóricos el cluster nunca podrá mostrar toda su potencia. El cuadro 3.4 resume una rápida prueba generada para mostrar cómo las colisiones en la red disminuía considerablemente el rendimiento. Aquí solo se representa un breve resumen con las pérdidas de rendimiento ocasionadas por la carga de la red.

En este testeo casi todos los paquetes han colisionado almenos una vez (colisionaron unos 670.000 de los 750.000 totales) por lo que puede decirse que la red y estos resultados se pueden considerar válidos como valores que puedan ocurrir cuando no se ha diseñado una buena red. El cuadro pues compara los resultados obtenidos con carga y sin carga la red. El porcentaje que aparece es el porcentaje de tiempo que ha necesitado la red con carga en comparación con la red sin carga.

Tabla: La importancia de la red. Rendimiento según el sistema de ficheros
tamaño (Moctetos) MFS(%) MFS-DFSA(%) NFS(%) SMB(%)
5 139 87 173 287
10 143 162 143 215
15 140 136 166 241


Como vemos los resultados son bastante homogéneos y vemos como una sobrecarga en la red afecta a todos los servicios que la usen y no hay forma de librarse de ella. Especial de mención son los resultados de SMB que son especialmente malos porque al hacer browsing queda esperando respuestas de la red antes de acceder a los ficheros, por lo tanto sus latencias son bastante superiores a los demás. También es de notar que con la red cargada el caso de los 5megas MFS-DFSA haya tardado menos que el caso con la red sin carga. Cabe decir que la carga de la red provenía principalmente de la televisión que se estaba viendo a través de la red.

3.2.2 Topologías de red

Existen muchas topologías de red que se han impuesto en diversos entornos, cada una de estas topologías tienen sus propias ventajas e inconvenientes. Vamos a ver unas cuantas, tanto estáticas como dinámicas.

3.2.2.1 Redes estáticas

Las topologías estáticas como su propio nombre indica son topologías donde la red. una vez conectada, no cambia de forma sino que se mantiene estática hasta que se vuelva a cambiar de topología, los cambios de topología son traumáticos. Las redes dinámicas están construidas con elementos que pueden conectar entre varios caminos posibles, esto hace que si uno de esos está siendo usado se pueda usar otro camino permitiendo más paralelismo. Como veremos la topología de la red influye mucho en el grado de paralelismo que se pueda alcanzar.

Las redes estáticas fueron las primeras en aparecer. En estas redes podemos distinguir entre redes punto a punto y redes con acceso a medio compartido. vamos a ver los ejemplos más usados y significativos explicando las ventajas y los inconvenientes de cada una de ellas. Primero veremos redes punto a punto:

Figura: La importancia de la red. Topología de redes estáticas
Image topologia_redes_estaticas

3.2.2.2 Redes dinámicas

Estas redes cambian su topología dinámicamente, cuando dos nodos necesitan conectarse la red puede cambiar de tal forma que se puedan conectar, así no se necesita parsar por todos los nodos o crear una complicada estructura de conexión, la red cambia según las necesidades de los nodos. En el caso anterior los nodos tenían que proveer de las capacidades que necesitaba la red (por ejemplo el nodo central de una red tipo estrella tenía que tener características especiales) . Este es el caso contrario donde la red es controlada por los nodos. La red está formada de cajas de conmutación, cambiando las cajas de conmutación cambiamos la red.

Hay dos tipos de redes dinámicas:

En las redes monoetapa si no se puede acceder desde cualquier elemento a otro cualquiera se necesita recircular la información. Dentro de este tipo de redes es de especial interés el caso de la red de barras cruzadas. En este caso se tienen los procesadores tanto formando una linea en horizontal como en vertical y unas líneas los conectan, cuando un procesador se quiere comunicar con otro, la posición (proc X, proc Y) se activa con lo que se hace una conexión. Esto permite que todos los procesadores puedan mantener conexiones independient es. Mientras que no haya dos procesadores que quieran comunicarse con un mismo procesador no habrá ningún problema. Este esquema es bastante caro y no merece la pena si no se hacen muchas conexiones simultáneas. En la figura 3.5 se ilustra una pequeña configuración de una red de barras cruzadas con tan solo 3 elementos.
Figura: La importancia de la red. Barras cruzadas
Image barras_cruzadas
Las redes multietapa son más complejas. Para comprenderlas primero tenemos que comprender las cajas de conmutación. Las cajas de conmutación tienen dos entradas y dos salidas. Las entradas las llamaremos e1 y e2 y a las salidas las llamaremos s1 y s2. Se pueden formar cuatro posibles configuraciones, según se relacionan las entradas con las salidas:

3.2.3 Tecnologías de red

Van a verse las tecnologías de red más usadas en el clustering. Estas tecnologías son las mismas que imperan en el mundo de las redes locales de medio y alto rendimiento. Estas tecnologías son: Por supuesto estas no son las únicas tecnologías existentes, pero si que son las más comunes, en todas nuestras pruebas y en todos los documentos que hemos leído sobre implementaciones que han realizado otras personas, siempre han usado uno de estos sistemas. Por tanto comunicaciones a través de Token Ring o sus derivados quedan fuera de este tema.

3.2.4 Protocolos utilizados a nivel de red (IP)

Otro tema importante aparte de las topologías o tecnologías de red utilizadas son los protocolos que se adaptan de mejor manera a nuestros sistemas clusters. Como vimos en el apartado anterior, generalmente la tecnología de cluster más utilizada suele ser ATM o Ethernet y dado el precio de los dispositivos ATM suele ser normalmente Ethernet el que se utiliza más en el diseño de clusters3.10.

En cualquier caso, el protocolo más extendido en el uso de las redes de cualquier tipo actualmente es IP, es por esto que en este apartado hablaremos básicamente sobre él. 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 o 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 (Internet Protocol o protocolo de interred) se encarga de cumplir los siguientes objetivos en una comunicación:

Es un protocolo ampliamente utilizado y con muchos años de uso. La práctica totalidad de los sistemas que se conectan a redes tienen alguna implementación IP ya sea completa o incompleta, lo que nos permite tener redes de equipos hetereogéneos. IP no es sólo un protocolo aislado, sino que trabaja en conjunto con otros protocolos pertenecientes al conjunto que se suele denominar TCP/IP para realizar transmisiones. Estos protocolos son ICMP e IGMP en el nivel de red3.11 y TCP UDP en el nivel de transporte.

El protocolo ICMP se encarga de mandar mensajes de control, errores en host, fallos de encaminamiento y mensajes similares, entre los host de la red, mientras que IGMP 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 mucho en el factor de diseño de nuestros clusters, además, en el caso de IP, nos permite reducir bastante el tamaño de los paquetes que queremos enviar o ampliarlos al máximo de lo que nos permita nuestra red. El esquema de direccionamiento tampoco es un problema para nuestros 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 configurables3.12.

Respecto al encaminamiento y la fragmentación de los datagramas, nos 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 teoria de redes. Lo básico para configurar la necesaria para interonectar nuestros nodos. Lo que sí que es necesario dar es una explicación de porqué utilizar IP en clusters.

El principal motivo para utilizar IP es que en la mayoría de los casos y a pesar de que IP pueda consumir en muchos casos demasiado ancho de banda o capacidad de proceso, es mejor utilizar un protocolo comprobado y válido que uno a desarrollar para un sistema concreto, por otro lado, y después de haber hecho un repaso sobre el proyecto completo, lo normal es que caiga en la cuenta de que el principal y verdadero motivo, es que no existe ningún sistema completo de tipo cluster o distribuido de carácter general, sino que existen muchas soluciones particulares aisladas, IP es el protocolo más ampliamente utilizado y permite un entorno de red donde todas estas soluciones puedan comunicarse de una manera estándar.

Existen otros protocolos de red que se han utilizado para entornos distribuidos como pueden ser IPX/SPX u otros, e incluso algunas soluciones se han basado directamente sobre capas de nivel de enlace para efectuar las comunicaciones entre los nodos. Todas estas soluciones, no han dejado de ser soluciones propias de un sistema especifico no portable o compatible.

Figura: La importancia de la red. Encapsulamiento IP
Image encapsulamiento_ip

3.2.5 Protocolos utilizados a nivel de transporte (UDP/TCP)

3.2.5.1 Protocolos de transporte

Los protocolos de red están divididos por capas, en la sección anterior hemos visto una capa de red y ahora veremos las capas que existen a nivel de transporte. Nos estamos basando en la división de capas característica de las redes TCP/IP y aunque este tema pretende ser lo más general posible, hablaremos principalmente de UDP y TCP.

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:

Otras de las características comunes de todos estos protocolos de nivel de red y que hacen este nivel tan útil es el control de flujo. Si tenemos por debajo de nuestro protocolo de red una red fiable (X.21) o nuestro protocolo no añade fiabilidad a la red (UDP) entonces no necesitaremo s usar el control de flujo de nuestra capa de transporte.

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 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.

3.2.5.2 UDP

Es el protocolo de transporte no fiable estándar en Internet, como protocolo de transporte que es, solamente está implementado en ordenadores finales. Es un protocolo no orientado a conexión (de ahísu nombre, se envían datagramas) y no es fiable. La cabecera que incluye al mensaje es la mínima para poder distinguir a que puerto se dirige y un pequeño checksum de la cabecera. Es usado para las típicas aplicaciones de los servicios no conectivos, se usan para enviar pocos datos (se consigue más rendimiento puesto que no se necesita gastar tiempo en conectar y desconectar) y en multidifusión. 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 temporizadore s de retransmitirlo, en el caso de TCP es este protocolo el que detecta y soluciona e problema. Como sabemos IP si no puede recomponer un datagrama, lo tira, 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, SNMP.

3.2.5.3 TCP

Este protocolo junto con UDP son los dos protocolos de transporte estándar en Internet, es el protocolo fiable de la familia. Es un protocolo orientado a conexión. TCP recibe mensajes de cualquier tamaño y los divide en trozos de un máximo de 64Kb se enví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é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:

Figura: La importancia de la red. Conexión TCP
Image conexion_tcp
TCP cada vez que envía un segmento inicia un temporizador, si este temporizador cumple y no se ha recibido confirmación se vuelve a enviar el mismo segmento suponiendo que el anterior segmento enviado no llegó o llegó con errores. Como no se puede saber a ciencia cierta cuánto tardará un segmento a llegar a su destino, pues dependiendo del paquete podría pasar por una redes u otras, haber congestiones momentáneas, etc. se implementa un temporizador variable que irá cambiando según lo que tardaron los ACK de los anteriores segmentos.

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.

3.2.6 Diseño de redes

A la hora de poner en marcha un cluster ya sea a nivel de producción como a nivel de investigación, hemos de tener en cuenta que uno de los factores críticos a la hora de configurar dicho sistema va a ser la red, independienteme nte de el tipo de sistema cluster que se vaya a instalar. 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, como ya hemos visto sobre redes LAN, con protocolos IP/UDP o TCP, 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 funcionami ento, 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.(salvo en las ocasiones en las que sean necesarios equipos caros como switches o routers dedicados especiales o estemos hablando de tecnologías de red caras como pueden ser ATM con fibra óptica).
Como se puede ver, a lo largo de todo el proceso el funcionamiento de la red es crítico en cualquier sistema de tipo cluster, es más, no sólo 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. El problema del congestionamiento en clusters es realmente preocupante en redes Ethernet.

3.2.6.1 Factores a tener en cuenta al diseñar una red

A la hora de diseñar una red tenemos que tener claros ciertos conceptos acerca del sistema que queremos instalar, el funcionamiento que éste debe tener, los servicios que debe tener y sobre todo, la funcionalidad que se le va a dar. En nuestro caso, la funcionalidad estaba clara y los medios eran bastante escasos, pero, en el caso de empresas que quieran poner clusters de alto rendimiento en el cual el tiempo o coste de migración de los procesos sea realmente pequeño, no queda más remedio que pagar. Tememos por tanto como punto inicial, que conocer la funcionalidad del sistema: Todos estos puntos quizá entren en el ámbito de la administración del sistema, pero son necesarios en el caso de partir de cero, con la primera instalación de un cluster. Lo que pretenden es que no haya problemas a la hora de tener claro que servicios o funcionalidades están por encima de que otras. Como ya hemos dicho, 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, tenemos 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. Todos los factores técnicos deben estar referidos a cada servicio particular. Para usuarios expertos puede ser obvio que programas o servicios acaparan más la red o deben tener más prioridad, para alguien profano a ese servicio, o parte del sistema deberá rellenar solamente los factores teóricos que el crea oportunos.

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 exponenci almente 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.

Este apartado, es quizá el apartado más técnico e importante, en el sentido de que, no depende de un administrador de sistemas o de un programador. 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. Cuando algún instalador experto de sistemas corrientes o diseñador de redes, lea este párrafo probablemente piense que es algo trivial y que el sentido común es suficiente, lo cual, nos pareció también lógico a nosotros cuando instalamos, LVS, openMosix, DHCP, Heartbeat, MON, NFSROOT, MFS, NFS, SMB, X Window, y cualquier otra aplicacion o servicio en red que se quiera instalar en el sistema como podrían ser servidores FTP, TELNET, APACHE, etc. para poder instalar todo ello junto sin que se produzcan congestiones en la red es necesario conocer el funcionamiento teórico de cada sistema, y luego saber si realmente se comporta como se explica teóricamente. Por ejemplo, los sistemas MFS, NFS y SMB se comportan de manera muy distinta cuando la red no está cargada o cuando está cargada.

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, un entorno de trabajo con openMosix, NFSROOT y X Window en un laboratorio de investigación científica, de probablemente más importancia a la red openMosix que a el sistema de archivos NFS o X Window cuidando de que estos no fallen tampoco, asíque probablemente separen dichas dos redes como redes aisladas de manera que NFSROOT o X Window no interfieran sobre openMosix y al mismo tiempo openMosix este aislado y sus paquetes de información de estado de cada nodo no interrumpan comunicaciones largas debido a colisiones cuando openMosix esta en un estado estable (sin migraciones).

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ñador, coloca cada servicio en redes aisladas o interconectadas, intentando que interfieran cuanto menos mejor los servicios entre sí, en este apartado, se evalúan las tecnologías de red aplicadas a cada servicio así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ía de comunicación entre los dos ordenadores que se desea replicar o controlar, e incluso el propio Heartbeat se encarga de comprobar la vía secundaria periódicamente para asegurar que esta estará disponible en el caso de que el sistema principal caiga.

3.2.7 Conclusiones

Como conclusiones de este tema hay que quedarse con que el sistema de comunicación es crítico en cualquier sistema paralelo, ya que al tener varios elementos de proceso (entiéndase por elementos de proceso a los procesadores, nodos, procesos, módulos, etc. que componen el sistema paralelo o distribuido), es necesaria la comunicación entre los elementos de proceso para realizar un trabajo conjunto. También hemos obtenido que cuanto más acoplado está un sistema paralelo, más crítico es el sistema de comunicación. Un ejemplo de esto está en aquellos sistemas distribuidos implementados a nivel de aplicación, que por lo general3.14, al tener un acoplamiento bastante débil, si la aplicación que forma el sistema falla, las máquinas seguirán funcionando y sólo hará falta relanzar o reconfigurar la aplicación. 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 hemos 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.
miKeL a.k.a.mc2 2003-09-28