Falacias de los Sistemas Distribuidos

 Falacias  

Las falacias, también nombrado como trampas, son un conjunto de errores o falsas creencias que se cometen al diseñar y desarrollar un sistemas distribuidos.

Historia de las falacias
Peter Deutsch, mientras trabajaba en la empresa Sun Microsystem, en la década de los 90 propuso la lista de 7 falacias de la computación distribuida; posteriormente, en 1.994, James Gosling, fundador de Java, añadió una más para finalmente ser conocida como las ocho falacias de los sistemas distribuidos.

 

Falacias en Sistemas Distribuidos.

Las falacias son [1,2]:

1. La red es fiable. Los sistemas no son inmunes a fallas: los servidores pueden estar fuera de servicio, la energía eléctrica puede fallar. Las aplicaciones deben estar construidas para sortear estas fallas. 
2. La latencia es cero. La latencia en redes pequeñas pueden considerarse casi cero; pero en las redes Wan, con servidores remotos, y usuarios alrededor del mundo, la latencia puede ser significativa. En estos casos, las aplicaciones deben tener cuidado con las respuestas tardías. Contemplar mecanismos para desechar las solicitudes, hacer re-intentos de peticiones  idempotentes, como mecanismo de prevención de fallas. 
3. El ancho de banda es infinito. Así como el ancho de banda aumenta debido a las mejoras de la tecnología, el volumen de datos se incrementa. Por ello, podemos tener problemas con el ancho de banda lo cual influiría en la degradación del rendimiento de la aplicación. 
4. La red es segura. Es un error no prestar atención a la seguridad de la aplicación. Las aplicaciones están expuestas a software maliciosos que pueden alterar las funcionalidades del software. 
5. La topología no cambia. La red está en cambio constante: nuevas direcciones ip, servidores, dispositivos, servicios, clientes, entre otros. Los cambios en la topología influye sobre el ancho de banda y el rendimiento de las aplicaciones. 
6. Hay un solo administrador. Un solo administrador es posible en redes pequeñas, pero para grandes redes, distribuidas geográficamente y con distintos propietarios, esto no se cumple. 
7. El costo de transporte es cero. En la comunicación entre procesos distribuidos intervienen equipos, sistemas de balance de carga y ancho de banda; en cuanto a la comunicación entre las aplicaciones están involucrado el protocolo que se usa y como se serializa y deserializa. 
8. La red es homogénea. Una red homogénea es pequeña con equipos bajo la misma tecnología, configuración y características. Pero en grandes redes esto no es así: allí se soportan una gran variedad de protocolos y dispositivos, aplicaciones con distintas necesidades y sistemas heterogéneos.

1.Fallas de los Sistemas Distribuidos. Adaptado de [2]

En la Figura 1 se muestra un esquema con la síntesis de las ocho falacias de los sistemas distribuidos ya referidas. En resumen, diseñar una aplicación es una tarea que requiere considerar aspectos que están fuera del alcance del diseñador de la aplicación; por ello el proceso de diseño requiere que se haga un ejercicio de escenarios probables de funcionamiento para determinar si la aplicación puede seguir operando a pesar de las posibles escollos que encuentre.

Bibliografia

1. Ingrid Van Den Hoogen. “Deutsch’s Fallacies, 10 Years After”. In: (2004). Documento electrónico .
2. Alex Xu. “What are the most common misconceptions about distributed environments?, [@alexxubyte], Twitter”. In: (Dec. 2022). Twitter. Documento electrónico.

Manejo de Fallas en Sistemas Distribuidos

 Los sistemas informáticos a veces fallan. Cuando estas ocurren, ya sea en hardware o
software, los programas pueden producir resultados incorrectos o detenerse antes de que
hayan completado el cálculo. Las fallas en un sistema distribuido son parciales, es decir,
algunos componentes fallan mientras otros continúan funcionando. Por lo tanto, el manejo
de fallas es particularmente difícil.

Existen técnicas para lidiar con fallas: detección de la ocurrencia de fallas, enmascaramiento
de las fallas, tolerancia a las fallas, recuperación luego de la ocurrencia de
fallas y la redundancia de rutas, caminos o servidores para garantizar funcionamiento de
las aplicaciones, a pesar de la fallas.

En [1] destacan que las fallas en los sistemas distribuidos puede atribuirse a la
complejidad de la ingeniería de los mismos y se deben a los siguientes motivos:
Los ingenieros no pueden combinar las condiciones de error. En su lugar, deben
considerar muchas combinaciones de fallas. La mayoría de los errores pueden ocurrir
en cualquier momento, independientemente de cualquiera otra condición de error,
por lo que podrían combinarse entre ellos.

Causas de las Fallas

• El resultado de cualquier operación de red puede ser DESCONOCIDO. En cuyo caso es posible que la solicitud haya fallado, se haya procesado correctamente o se haya recibido pero no procesado. 

• Los problemas distribuidos se producen en todos los niveles. No solo en los equipos físicos de nivel bajo, sin también, en los niveles lógicos del sistema distribuido. 

• Recursividad. Los problemas distribuidos empeoran en los niveles superiores del sistema, debido a la recursividad. 

•  Aparición del error. Los errores distribuidos suelen aparecer mucho después de su implementación en un sistema. 

• Propagación del error. Los errores distribuidos se pueden propagar en todo el sistema. 

•  Origen de la falla. Muchos de estos problemas provienen de las leyes físicas de las redes, que no se pueden cambiar.

Tipos de Fallas

Las fallas se caracterizan como [2]:

• Fallos por omisión. Los fallos clasificados como fallos por omisión se refieren a casos en los que un proceso o el canal de comunicación no realiza las acciones que se supone que debe realizar

• Fallos por omisión del proceso. El principal fallo por omisión de un proceso es que el proceso se bloquee. Un proceso se ha bloqueado cuando se ha detenido y no ejecutará ningún paso de su programa. 
• En los sistemas síncronos el método de detección de estas fallas se basa en el uso de tiempos de espera - es decir, un método en el que un proceso permite un período de tiempo fijo para que ocurra algo. En un sistema asincrónico, un tiempo de espera puede indicar solo que un proceso no responde: puede que se haya bloqueado o sea lento, o los mensajes pueden que no han llegado. 

• Fallos de omisión de comunicación. Considere las primitivas de comunicación que envían y reciben mensajes. Un proceso p realiza un envío insertando el mensaje m en su buffer de mensaje saliente. El canal de comunicación transporta m al búfer de mensajes entrantes de q. El proceso q realiza una recepción tomando m de su búfer de mensajes entrantes y lo entrega (ver Figura 1 ). 

Los búferes de mensajes entrantes y salientes son proporcionado por el sistema operativo. El canal de comunicación produce una falla por omisión si no transporta un mensaje del búfer de mensajes salientes de p al búfer de mensajes entrantes de q. Esto se debe a la falta de espacio en el búfer en el receptor o en una puerta de enlace intermedia, o por un error de transmisión de red, detectado por un control de suma (check sum) llevada con los datos del mensaje.

 

Fallas de omisión en sistemas
Por ejemplo, si los procesos p y q están programados para que q pueda responder a un mensaje de p, y si el proceso p no ha recibido respuesta del proceso q en un tiempo máximo medido en el reloj local de p, entonces el proceso p puede concluir que el proceso q ha fallado.

  

• Fallos arbitrarios. El término fallo arbitrario o bizantino se utiliza para describir lo peor falla de semántica posible, en la que puede ocurrir cualquier tipo de error. Por ejemplo, un proceso puede establecer valores incorrectos en sus elementos de datos, o puede devolver un valor incorrecto en respuesta a un invocación. Un fallo arbitrario de un proceso es aquel en el que omite arbitrariamente el pasos de procesamiento o toma pasos de procesamiento no deseados.

1. Procesos y Canales

Bibliografia

1. Jacob Gabrielson. “Los desafíos de los sistemas distribuidos”. In: Amazon Web Services, Inc. (2019). URL: https://aws.amazon.com/es/builders-library/challenges-with-distributed-systems/ 
2. George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA: Addison-Wesley Publishing Company, 2011. ISBN: 0132143011. 

Principios de Diseño de Sistemas Distribuidos

 Los principios de  diseño de Sistemas Distribuidos describe los objetivos que se deben tomar en cuenta cuando se diseña un sistema sistema distribuido. A continuación se describen.

•  Concurrencia. Tanto los servicios como las aplicaciones proporcionan recursos que los clientes pueden compartir en un sistema distribuido. Por tanto, existe la posibilidad de que varios clientes intenten acceder a un recurso compartido al mismo tiempo. La concurrencia se hace más compleja cuando existen  actividades paralelas que interactúan o comparten los mismos recursos. 

• Compartir Recursos.  Los recursos, como los  periféricos,  datos en bases de datos,  bibliotecas, así como los datos (variables/archivos),  no pueden replicar por completo en todos los sitios porque no resulta practico ni rentable. Estos recursos se distribuyen normalmente por todo el sistema, para que su acceso no se convierta en un potencial cuello de botella. 

• Transparencia.    El objetivo de la  transparencia es hacer que ciertos aspectos de la distribución sean invisibles para el programador de aplicaciones. Por ejemplo, no necesitan preocuparse por la ubicación o los detalles de cómo otros componentes acceden a sus operaciones, o si serán replicados o migrados. Incluso se pueden presentar fallas en la redes y procesos  en forma de excepciones, pero estas deben poder manejarse.  En el cuadro Tipos de transparencias, adaptado de [4],  se detallan los niveles de transparencia que se deben tomar en cuenta acompañado de su descripción.

                                Tipos de Transparencia.

Conceptos	Descripción
Acceso	Permitir el acceso con las mismas operaciones   de los recursos locales y remotos.
Ubicación	Que los recursos sean alcanzados  sin   conocer su ubicación física o de red.
Red	Combina ambas transparencias: en el acceso  y en  la ubicación.
Concurrencia	Permite que varios procesos operen  simultáneamente usando recursos compartidos  sin interferencia entre ellos.
Replicación	Permite que múltiples instancia de recursos  sean usados para aumentar  la confiabilidad  y    rendimiento sin que el usuario  de aplicaciones conozca de ellas.
Fallas	Ocultamiento de fallas, permitiendo que    usuarios y aplicaciones culminen sus tareas   sin percatarse de ellas.
Movilidad	Permite el movimiento de recursos y clientes  dentro del sistema  sin afectar la operación   de usuarios o programas..
Rendimiento	Permite que el sistema sea reconfigurado  para    mejorar el rendimiento cuando su carga varía.
Escalamiento	Permite que el sistema y la aplicación se    incremente sin cambios   en la estructura   del    sistema o en los algoritmos de aplicación.

•  Sistemas Abiertos.  Los  sistemas abiertos  son aquellos que  puede ampliarse e implementarse de varias formas. La apertura  está determinado principalmente por el grado en que los nuevos servicios de intercambio de recursos puede agregarse y estar disponible para su uso por una variedad de programas de cliente. Se caracterizan por el hecho de que sus interfaces son públicas; en otras palabras, las aplicaciones proveen un mecanismo de comunicación uniforme e interfaces  publicadas para el acceso a recursos compartidos. 

• Simplicidad.  Es importante que un diseño sea lo más simple posible y al mismo tiempo pueda satisfacer las necesidades del servicio ya que los sistemas crecen y se vuelven más complejos con el tiempo. Esto facilita su mantenimiento.

• Acoplamiento.  El grado de  acoplamiento  entre un conjunto de módulos, ya sea hardware o software, se mide en términos de la interdependencia y vinculación y/o homogeneidad entre los módulos. 

• Cuando el grado de acoplamiento es alto, se dice que los módulos están acoplados de manera ajustada o fuerte; por el contrario cuando el grado de acoplamiento es bajo, los módulos están acoplados de manera floja o débil.

• Un sistema  débilmente acoplado  facilita la sustitución o adicción de componentes  mientras  está en funcionamiento. Por el contrario, en  los sistemas   fuertemente acoplado  es necesario que se compartan recursos comunes, como la memoria central, almacenamiento secundario (disco) y entrada/salida a través de un bus común. 

El concepto de acoplamiento fue presentado por Edward Yourdon en  Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Yourdon, 1979. En Geeksforgeeks pueden ampliar las diferencias entre acoplamiento débil y fuerte

• Escalable. Un sistema se describe como escalable  si permanece efectivo cuando hay un aumento significativo en el número de recursos y el número de usuarios. El diseño de sistemas distribuidos escalable presenta los siguientes retos: 
• Controlar el costo de los recursos físicos.  Es posible ampliar un sistemas, a un costo razonable, a medida que crece la demanda de un recurso. 
• Controlar la pérdida de rendimiento. La gestión de un conjunto de datos cuyo tamaño debe ser proporcional al número de usuarios o recursos en el sistema, para evitar el congestionamiento en el acceso a los recursos y afectación del rendimiento. 
• Evitar cuellos de botella.  En general, los algoritmos deben estar descentralizados para evitar cuellos de botella.  
• Un ejemplo de un problema  con cuello de botella es el  predecesor del sistema de dominio de nombres  DNS , en el que la tabla de nombres se mantenía en un archivo maestro único que se podía descargar a cualquier computador. Esto estuvo bien cuando solo había unos pocos cientos de computadoras en internet. Luego  se eliminó este cuello de botella al dividir la tabla de nombres entre servidores ubicado en Internet y administrado localmente.  

• Heterogeneidad. Los sistemas distribuidos son heterogéneos, ya que se pueden construirse a partir de una variedad de redes, sistemas operativos, hardware informático y lenguajes de programación. Contemplar, por ejemplo, codigo movil o maquina virtual. El middleware se usa para ocultar estar diferencias y permitir la comunicación y administración de datos entre aplicaciones distribuidas. 

Bibliografia:

1. George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA: Addison-Wesley Publishing Company, 2011. ISBN: 0132143011
2. Paulo Veríssimo and Luís Rodrigues. Distributed Systems for System Architects. Advances in Distributed Computing and Middleware Ser. 1. Springer, 2012. ISBN: 9781461356660. 
3. Christina J. Hogan Thomas A. Limoncelli Strata R. Chalup. The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems. Volume 2. Addison Wesley, 2014. ISBN: 032194318X 
4. M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice Hall. Third. distributed-systems.net, 2017

Sistemas Centralizados vs Sistemas Distribuidos

 Los sistemas distribuidos contrasta con los sistemas de computación tradicionales,  donde una sola computadora ejecuta el software que proporciona un  servicio, o la computación  cliente-servidor, donde varias maquinas acceden de manera remota a un servicio centralizado.

En los sistemas distribuidos hay miles o millones de maquinas trabajando juntas para proporcionar un gran servicio.

Algunas de las diferencias entre los sistemas centralizado y distribuido  se resumen en el siguiente cuadro adaptado de [1]. 

Sistemas Centralizados	Sistemas Distribuidos
Accesible	Ámbito geográfico
Homogéneos	Heterogéneos
Administrable	Modular
Consistente	Degradación elegante
Seguridad	Seguridad a costo bajo

 

Accesible vs Ámbito Geográfico.

Los sistemas centralizados son  homogéneos  en cuanto a tecnologías y procedimientos; hay un acceso  natural a los recursos porque están constituidos por  sistemas locales.  

Por su parte, los sistemas distribuidos  tienen un alcance geográfico potencialmente más amplio, debido a que se puede operar y acceder de manera remota.  

 Homogéneos vs Heterogéneos. 

En cuanto a  tecnologías y procedimientos, los sistemas centralizados son homogéneos ya que sus arquitecturas, protocolos, lenguajes son propios de un tipo de arquitectura; hay un acceso  natural a los  recursos porque están constituidos por sistemas locales. 

En cambio, los sistemas distribuidos son heterogéneos ya que poseen diferentes arquitecturas, protocolos y  sistemas operativos. 

 Administrable vs Modular

Los sistemas centralizados son administrables porque están compuestos por estructuras centralizadas, y debido a ese tipo de estructura logran ser consistentes y seguros. Por su parte, los sistemas distribuidos,  debido a su modularidad,  resultan ser más expansibles y  escalable en cuanto a número de sitios y extensión geográfica.   

 Consistente vs Degradación elegante.

Es más fácil mantener un sistema coherente en  sistemas centralizados debido a que  su administración es sobre tecnologías y procedimientos homogéneos, y  recursos  constituidos por sistemas locales.  

Los sistemas distribuidos expresan un comportamiento llamado   degradación elegante . Esta característica  potencia que los sistemas distribuidos puedan  lograr confiabilidad y disponibilidad. Y, conjuntamente con la modularidad de los componentes, la separación geográfica,  la redundancia y las técnicas de reconfiguración, logran que los sistemas distribuidos tenga una alta tolerancia a fallos.  

Degradación Elegante  es el concepto que describe a sistemas informáticos y de red que pueden operar de manera progresivamente degradada, en la medida que fallan sus componentes, pero sin la ocurrencia de un colapso en el sistema como consecuencia de esas fallas. Presentado en Emerging resilience techniques for embedded devices, Demara et al, 2017.

 

Seguridad vs Seguridad a bajo costo.

La  seguridad en los sistemas centralizados  se logra mediante el control de acceso físico y aislamiento.

En cuanto a los sistemas distribuidos, se  puede alcanzar un alto nivel de seguridad con un costo más bajo,  siempre que sea logrado más a costa de reducir el efecto de las intrusiones, que el de las amenazas; esto es debido a lo difícil y costoso que resulta reducir amenazas en sistemas abiertos y públicos. 

Bibliografia:

1. Paulo Veríssimo and Luís Rodrigues. Distributed Systems for System Architects. Advances in Distributed Computing and Middleware Ser. 1. Springer, 2012.