• Author / Uploaded
• ARNOLDKING44

Citation preview

Facultad de Ingeniería

CURSO: SISTEMAS DISTRIBUIDOS TEMA: DESARROLLO AUTOADMINISTRACIÓN Y EJEMPLOS INTEGRANTES: 2 3 4  Ramírez Carranza, Maycol Jefferson

LIMA– PERÚ 2018

Índice 1.

Introducción ......................................................................................................................... 3

2.

Autoadministración en Sistemas Distribuidos .................................................................. 3

3.

1.1

Auto-conocimiento ...................................................................................................... 4

1.2

Auto-configuración: ..................................................................................................... 5

1.3

Auto-recuperación ....................................................................................................... 5

1.4

Auto-optimización ....................................................................................................... 6

1.5

Auto-curación............................................................................................................... 7

1.6

Auto-protección ........................................................................................................... 7

Aplicaciones ......................................................................................................................... 8 3.1.

Autonomic Toolkit de IBM......................................................................................... 8

3.2.

ANTS (Enjambre de Nano Tecnología Autónomo) ................................................. 8

3.3.

Sistema de Distribución de Energía Eléctrica........................................................... 9

4.

El Modelo de Control de Retroalimentación ..................................................................... 9

5.

Ejemplos ............................................................................................................................. 11 5.1.

Ejemplo: monitoreo de sistemas con Astrolabe ............................................................ 11

5.2.

Ejemplo: cómo diferenciar estrategias de replicación en Globule .............................. 13

5.3.

Ejemplo: administración de la reparación automática de componentes en Jade ............. 14

6.

Conclusiones ....................................................................................................................... 16

7.

Bibliografía .......................................................................................................................... 15

1. Introducción 2. Sistemas Distribuidos Definición

Un sistema distribuido se define como: una colección de computadoras separadas físicamente y conectadas entre sí por una red de comunicaciones distribuida; cada máquina posee sus componentes de hardware y software que el usuario percibe como un solo sistema (no necesita saber qué cosas están en qué máquinas). El usuario accede a los recursos remotos (RPC) de la misma manera en que accede a recursos locales, o un grupo de computadores que usan un software para conseguir un objetivo en común. Los sistemas distribuidos deben ser muy confiables, ya que si un componente del sistema se descompone otro componente debe ser capaz de reemplazarlo, esto se denomina Tolerancia a Fallos. 1

3. Autoadministración en Sistemas Distribuidos Los administradores de sistemas distribuidos se ocupan de monitorear continuamente al sistema y se deben de asegurar de su disponibilidad. Para una buena administración, se debe de poder identificar las áreas que están teniendo problemas, así como de la rápida recuperación de fallas que se puedan presentar. La información que se obtiene mediante el monitoreo sirve a los administradores para anticipar situaciones críticas. La prevención de estas situaciones ayuda a que los problemas no crezcan para que no afecten a los usuarios del sistema.2 La administración de sistemas distribuidos incluye las actividades como: manejo de la versión y distribución del software, monitoreo de la utilización de los recursos y el mantenimiento del sistema de seguridad, entre otros. Es un conjunto de componentes que interactúan entre sí y se encuentran interrelacionados recibe el nombre de sistema. Administrativo, por su parte, es aquello vinculado a la administración (el acto de administrar: organizar o gestionar recursos). En la actualidad, la noción de sistema administrativo suele hacer referencia al programa informático que cuenta con diversas aplicaciones para administrar las facetas de una empresa. La intención de este tipo de software es centralizar las tareas administrativas en un mismo sistema informático que permita ahorrar tiempo e incrementar la eficiencia laboral. Los sistemas distribuidos y por supuesto su middleware asociado debe proporcionar soluciones generales encaminadas a lograr la protección contra características indeseables inherentes a las redes, de tal manera que puedan soportar tantas aplicaciones como sea posible.

1 2

https://mairita.webnode.es/nosotros/ http://sistemasoperativosdistribuidoss.blogspot.com/

Por otra parte, una total transparencia de distribución no es lo que la mayoría de las aplicaciones quiere, lo cual resulta en soluciones específicas para aplicaciones que también necesitan soporte. Hemos argumentado que, por esta razón, los sistemas distribuidos deben ser adaptativos, pero sólo cuando se trate de adaptar su comportamiento de ejecución y no los componentes de software que comprenden. Cuando es necesario realizar la adaptación de manera automática, vemos una fuerte interrelación entre arquitecturas de sistemas y arquitecturas de software. Por una parte, necesitamos organizar los componentes de un sistema distribuido en tal forma que sea posible realizar monitoreo y ajustes, mientras que, por otra parte, requerimos decidir en dónde ejecutar los procesos de tal modo que manejen la adaptación. En esta sección nos enfocamos explícitamente en la organización de sistemas distribuidos como sistemas de control de retroalimentación de alto nivel que permiten hacer adaptaciones automáticas a los cambios. Este fenómeno también se conoce como cómputo autonómico (Kephart, 2003) o sistemas self-star (Babaoglu y cols., 2005). El último nombre indica la variedad mediante la cual se capturan las adaptaciones automáticas: auto-administración, auto-reparación, auto-configuración, autooptimización, etc. Recurrimos a utilizar el nombre de sistemas de autoadministración para cubrir sus muchas variantes. 1.1

Auto-conocimiento Un sistema automático debe tener conocimiento detallado de todos los elementos de bajo nivel que lo componen, en cuanto a estado actual, capacidad final y todas las conexiones con otros sistemas, para auto-gobernarse. Un sistema basado en conocimiento es un sistema computacional programado para imitar la resolución de problemas del ser humano por medio de mecanismos de inteligencia artificial y haciendo referencia a bases de datos de conocimientos en un tema en particular. Esta definición permite pensar que un sistema basado en conocimiento puede ser el encargado del análisis los datos recibidos y la extracción de la información relevante, y basado en su propia inteligencia tomar las decisiones necesarias para regular su operación. Por otra parte, un sistema basado en conocimiento no podría tomar las decisiones adecuadas ni aprender basado en su propia experiencia, si no cuenta con la información acertada y en tiempo real, que solo puede proporcionar un sistema distribuido. Implementaciones de prototipos de sistemas distribuidos y basados en conocimiento para el control y monitoreo. 3

Sistemas Distribuidos y Basados en Conocimiento para el Monitoreo y Control en el Tratamiento de Aguas Residuales 3

1.2

Auto-configuración: Pretende lograr que los sistemas se configuran a sí mismos de acuerdo a políticas de alto nivel representando objetivos de nivel de negocio. Se aclara que este concepto permite solamente especificar lo que se desea y no cómo se va a hacer. Cuando se introduce un nuevo componente el resto del sistema se adapta a su presencia. Debe realizar en forma automática y dinámica para responder eficiencias a cambios en el ambiente. Esto representa a un gran reto debido a que pueden existir una gran posibilidad de opciones en configuración y se debe resolver en un tiempo óptimo. Autoconfiguración sin control de estado También conocida como autoconfiguración stateless o sin intervención. Este mecanismo permite a los equipos obtener una dirección a partir de información local (el identificador de interfaz) e información proporcionada por los routers (el prefijo de subred). Si no hay routers en la red, los equipos pueden generar sus propias direcciones locales de enlace que le permiten comunicarse con otros nodos del enlace. Esta forma de autoconfiguración se usa cuando no importa la dirección exacta que se asigna a un equipo, mientras ésta sea válidas y encaminable. Autoconfiguración con control de estado. Se le llama también autoconfiguración stateful o predeterminada. Mediante este mecanismo los equipos obtienen la dirección de la interfaz y/o la información y parámetros de configuración de un servidor. Este servidor mantiene control de qué direcciones han sido asignadas a cada equipo. Este tipo de autoconfiguración se usa, cuando se necesita saber qué equipo usa qué dirección. Ambos tipos de autoconfiguración se complementan. Un equipo puede usar autoconfiguración sin intervención (stateless) para generar su propia dirección, y obtener el resto de los parámetros mediante autoconfiguración predeterminada (stateful). Los administradores de red tendrán que especificar qué mecanismos (stateless, stateful, o ambos) deben ser usados.4

1.3

Auto-recuperación Se basa en la capacidad de detectar componentes de software y hardware que estén fallando, eliminarlos o reemplazarlos con otros componentes sin interrumpir la operación del sistema. Incluye también predecir problemas y predecir fallas. Una vez que fue detectado un fallo y que se ha decidido arreglarlo, hay que encontrar la mejor manera de hacerlo, y además, de recuperar el estado del sistema antes de que ocurriera el fallo; esto requiere del software adecuado para poder reconstruir o bien retractar los cambios que no fueron completados al momento en que fue interrumpido el sistema, un ejemplo de esto lo podemos ver en los sistemas manejadores de bases de datos, que se sirven de una bitácora de las transacciones que se realizan y de acuerdo a esta bitácora se decide reconstruir o retractar las transacciones hechas sobre la base de datos antes de que se interrumpiera el funcionamiento de la misma.5

4 5

Redes locales y globales, Mecanismos de autoconfiguración Sistemas Distribuidos. Ing. Einar TURPO AROQUIPA

Recuperación de errores hacia adelante: en esta técnica, a naturaleza de los errores y daños causados por las fallas puede ser continuada y accesada en un grado de seguridad mayor, de manera que sea posible restablecer cualquier operación del sistema para seguir operando. Requiere de una gran cantidad de operaciones que le permitan evaluar y seguir con la ejecución del sistema. Utiliza un método de algoritmos complejos que procuran abarcar las causas más comunes de fallas, si no se tiene el algoritmo apropiado para llevar a cabo la recuperación, esta no se lleva a cabo. Recuperación de errores hacia atrás: En esta técnica no es posible detectar o predecir la naturaleza de las fallas que pueden ocurrir y llevar a cabo un proceso de remover esos errores. El sistema utiliza un método de almacenamiento de los estados que son considerados estables a través de un Log de operaciones (Bitácora) para proceder a la ejecución de ese estado y proseguir con él funcionamiento del sistema.6 1.4

Auto-optimización Los sistemas autonómicos continuamente buscan como mejorar su operación, identificando oportunidades para hacerse a sí mismos más eficientes. Se define como proactivamente ellos tienden a actualizar su función encontrando, verificando y aplicando las últimas actualizaciones. Dichas decisiones de mejora deben recoger y agregar información de la experiencia de los administradores humanos como consejeros. Con el tiempo lo que se pretende hacer es llegar a un punto de toma de decisiones a bajo nivel. El sistema debe supervisar sus elementos y afinar sus tareas para alcanzar los objetivos predefinidos. Esta cualidad es muy importante porque responde a las necesidades de múltiples aplicaciones demandadas por sus usuarios y los cambios que se pueden dar en el tiempo en dichas necesidades. Se han optimizado los métodos existentes para la planificación y análisis de sistemas distribuidos de tiempo real mediante un algoritmo heurístico para la asignación de prioridades, y la aplicación del algoritmo de servidor esporádico a la planificación de redes de comunicación de tiempo real. También se ha ampliado el campo de aplicación del análisis a sistemas más complejos en los que existe sincronización por intercambio de eventos o paso de mensajes. Se ha demostrado que la metodología propuesta se puede implementar en sistemas de tiempo real prácticos, a través de su aplicación a sistemas distribuidos programados en lenguaje Ada.7

6 7

Sistemas Distribuidos tolerantes a fallas Planificación, análisis y optimización de sistemas distribuidos de tiempo real estricto

1.5

Auto-curación El sistema debe tener la capacidad de recuperarse ante un mal funcionamiento de alguna de sus partes en este sentido, el sistema debe descubrir problemas o problemas potenciales y determinar formas alternativas, en cuanto al uso del recursos o configuración, para regresar “suavemente” a una operación normal.

1.6

Auto-protección Es la propiedad que hace que el sistema se defina como un todo a gran escala, relacionando problemas que surgen de ataques o fallas no corregidas por las medidas de auto-recuperación, anticipa problemas basados en los reportes y toma pasos para prevenir o mitigar esto. El sistema debe detectar, identificar y protegerse el mismo contra varios tipos de ataques, para mantenerse seguro e íntegro. En un ambiente de computo distribuido, los sistemas están más expuestos a ataques y su protección es más complicada. En este sentido, el sistema debe estar alerta, anticiparse a amenazas y tomar las acciones necesarias. Las respuestas deben direccionarse en dos sentidos: ataques de virus o intrusión de “hackers”. La seguridad de la información es todo lo que concierne a asegurar que no ocurrirán cosas malas con los mensajes que envían los clientes para solicitar información a un servidor, y por supuesto, con la información que estos reciben como respuesta a sus peticiones. No basta con asegurar que estos mensajes serán transmitidos de forma oculta, sino que también hay que asegurar que la información sea entregada únicamente a quien debe de ser entregada y que esto se hará siempre de forma correcta y en el momento en que se requiere. La seguridad es relativa a la amenaza que cada sistema afronta, afecta a todos los puntos del sistema y debe de ser fácil de obtener. La seguridad debe ofrecer los siguientes servicios: 

Confidencialidad, es decir, el manejo privado de la información: proteger la información de ser accedida por usuarios no autorizados.



Autentificación, o capacidad de asegurar la identidad de un usuario. o Integridad, que asegura que la información que empleamos no ha sido manipulada, alterada o corrompida desde el origen.



No repudio, de una operación de emisión y recepción de información por parte de los agentes.



Control de acceso a la información y/o recursos administrados por un sistema.



Disponibilidad de los recursos necesarios de un sistema cuando estos sean requeridos, lo que protege la información contra interferencia con los procedimientos de acceso a los recursos.



El alto valor de que tiene la información es la razón principal por la que esta se puede ver amenazada de muchas formas, entre las principales podemos encontrar:

Si bien no podemos asegurar que un sistema distribuido sea cien por ciento seguro, es importante contar con un esquema de seguridad lo más robusto posible, que, a pesar de no ser inmune a todo tipo de ataques, si será capaz de frenar la gran mayoría de dichos ataques. Algunas recomendaciones muy útiles para los desarrolladores, administradores e implementados de un sistema distribuido.8 4. Aplicaciones 4.1. Autonomic Toolkit de IBM. Arora, Vinze y Brittenham (2006) muestran una aplicación realizada con el Autonomic Toolkit de IBM. Su aporte en la investigación consiste en abstraer los conceptos de autoconfiguración y auto-optimización para definir cadenas de aprovisionamiento de información en las que cada entidad de la cadena adiciona valor a la misma proporcionándole la información correcta a la entidad correcta en el tiempo correcto en una forma segura. El valor del artículo es el intento de aplicar este concepto en ciencias de la salud, realizando un sistema colaborativo en el que se pueda reaccionar a situaciones como epidemias para redistribuir los recursos de salud necesarios de la mejor forma entre entidades a nivel regional. Este problema posee una alta complejidad si se agregan variables como personal, vehículos necesarios o dificultades del terreno 4.2. ANTS (Enjambre de Nano Tecnología Autónomo) Truszkowski, Rouff, C. y Hinchey, M (2004) muestra una iniciativa de la NASA para realizar exploración en cinturones de asteroides en un prospecto llamado ANTS (Enjambre de Nano Tecnología Autónomo). El sistema propuesto tiene trabajadores especializados en distintos roles para obtener información sobre asteroides un agente central que da una meta global y unos mensajeros que envían señales entre los agentes y la estación espacial. Éste proyecto hace parte de un plan de la NASA donde muestra la aplicación de computación autonómica en la planeación de futuras misiones espaciales, muestra dos prototipos: ACT y Logos que despliegan propiedades autonómicas y son definidos arquitecturas que implementan de forma flexible un amplio grado de agentes autónomos e inteligentes. Éstas arquitecturas manejan conceptos como el de especialización en el que un agente es diseñado para realizar un trabajo específico y puede redefinir su tarea, adaptarse al entorno y aprender de su trabajo o ser reemplazado fácilmente por otro si presenta fallas de alto nivel. Los proyectos planteados muestran la importancia del estudio del paradigma de la computación autonómica. 4.3. IBM IBM ha instalado sistemas de servidores e-server que incorporan tecnologias de CA que permiten la autorrecuperacion, autocon-guracion, autoproteccion y autooptimizacion. Esto brinda dos ventajas: reduce los gastos generales de gestión controlando costos de soporte, e incrementa la con4abilidad de un entorno heterogéneo de IT. El resultado brindará infraestructuras más Texibles que requieran menor gestión, mientras se 8

Sistemas Distribuidos. Ing. Einar TURPO AROQUIPA

minimizan los gastos administrativos. Teniendo en cuenta que administrar un servidor suele ser más costoso que el mismo servidor 9 4.4. Sistema de Distribución de Energía Eléctrica AL-Zawi et al.; (2007) se presenta la implementación de un sistema integrado de supervisión externa aplicado a un sistema de distribución de energía eléctrica, para identificar y recuperar de fallos por sobre-corriente en relevadores(relés), utilizando redes neuronales para medir y predecir la presencia de protección en subestaciones, para mejorar su disponibilidad, lo cual es una operación de auto-cura para el sistema. 5. El Modelo de Control de Retroalimentación El término retroalimentación se refiere, en forma general, a una situación en donde dos o más sistemas dinámicos se comunican, de tal manera que cada sistema influye en el otro y, por lo tanto, sus dinámicas están acopladas. En el contexto de un modelo recursivo, la retroalimentación está siempre presente, dado que una acción o variable en una recursión depende de otras pasadas y, asimismo, las siguientes dependerán de las actuales. Un sistema retroalimentado toma en cuenta la información de acciones pasadas y, con base en ellas, decide las acciones subsecuentes; se crea así una estructura causal circular en donde el tiempo es la variable independiente. Una forma de visualizar el principio de la retroalimentación es considerando un sistema con dos elementos, D1 y D2, interconectados en ciclo, de tal manera que D1 influye en D2 y éste, a su vez, influye en D1. En consecuencia, el comportamiento del sistema está siempre gobernado por las reacciones y los tiempos de respuesta de ambos elementos.10 Existen muchas opiniones diferentes acerca de los sistemas de autoadministración, pero lo que más tienen en común (explícita o implícitamente) es la suposición de que las adaptaciones se llevan a cabo mediante uno o más ciclos de control de retroalimentación. Así, los sistemas organizados por medio de tales ciclos se conocen como sistemas de control de retroalimentación. El control de retroalimentación se ha aplicado desde hace mucho tiempo en diversos campos de la ingeniería, y sus bases matemáticas poco a poco encuentran también su camino en los sistemas de cómputo (Hellerstein y cols., 2004; y Diao y cols., 2005). Para sistemas de autoadministración, las cuestiones arquitectónicas son, de inicio, las más interesantes.

9

https://es.slideshare.net/JessikLerma/computacion-autonomica Retroalimentación y sincronía en procesos

10

La parte central de un sistema de control de retroalimentación se forma con los componentes que necesitan administrarse. Se supone que estos componentes se manejan mediante parámetros de entrada controlables, pero su comportamiento puede verse influenciado por todo tipo de entrada no controlable, lo cual se conoce también como entrada de alteraciones o ruido. Aunque las alteraciones con frecuencia provienen del ambiente donde se ejecuta el sistema distribuido, bien puede darse el caso de que una interacción no anticipada de componentes ocasione un comportamiento inesperado. Existen tres elementos básicos que conforman el ciclo de control de retroalimentación. Primero, el sistema mismo necesita ser monitoreado, ello requiere que varios aspectos del sistema sean medidos. En muchos casos, para medir el comportamiento es más fácil decirlo que hacerlo. Por ejemplo, en internet, los retrasos de un ciclo (envío-recepción) pueden variar mucho, y también dependen de qué tan exacta sea la medición. En tales circunstancias, estimar de modo preciso un retraso puede resultar muy difícil. Las cosas se complican aún más cuando un nodo A necesita estimar la latencia presente entre otros dos nodos, B y C, completamente diferentes sin interferir con ninguno. Por razones como éstas, un ciclo de control de retroalimentación generalmente contiene un componente lógico de estimación métrica.

Otra parte del ciclo de control de retroalimentación analiza las mediciones, y las compara con valores de referencia. Este componente de análisis de retroalimentación forma el núcleo del ciclo de control, ya que contendrá los algoritmos que deciden las posibles adaptaciones. El último grupo de componentes consiste en diversos mecanismos empleados para influenciar directamente el comportamiento del sistema. Pueden existir muchos mecanismos diferentes: colocar réplicas, modificar prioridades de planificación, servicios de intercambio, mover datos por razones de disponibilidad, redirigir peticiones a diferentes servidores, etc. El componente de análisis necesita estar consciente de estos mecanismos y de sus efectos (esperados) sobre el comportamiento del sistema. Por tanto, disparará uno o varios mecanismos para, posteriormente, observar el efecto. Una observación interesante es que el ciclo de control de retroalimentación también encaja con la administración manual de sistemas. La principal diferencia es que el

componente de análisis se reemplaza con administradores humanos. Sin embargo, para administrar adecuadamente cualquier sistema distribuido, estos administradores necesitarán un equipo de monitoreo apropiado, así como mecanismos eficientes para controlar el comportamiento del sistema. Debe quedar claro que analizar adecuadamente los datos medidos y disparar las acciones correctas vuelve muy difícil el desarrollo de sistemas de autoadministración. La organización lógica de un sistema de autoadministración, y como tal corresponde a lo que hemos visto cuando explicamos las arquitecturas de software. Sin embargo, la organización física puede ser muy diferente. Por ejemplo, el componente de análisis puede estar completamente distribuido a través del sistema. De igual manera, las mediciones de rendimiento normalmente se hacen en cada una de las máquinas que forman parte del sistema distribuido. Ahora veamos algunos ejemplos concretos sobre cómo monitorear, analizar, y corregir de manera automática sistemas distribuidos. Estos ejemplos también ilustran la diferencia que hay entre la organización lógica y la física. 6. Ejemplos 6.1. Ejemplo: monitoreo de sistemas con Astrolabe Como primer ejemplo, consideramos Astrolabe (Van Renesse y cols., 2003), un sistema que puede soportar el monitoreo general de sistemas distribuidos muy grandes. En el contexto de sistemas de autoadministración, Astrolabe se posicionará como una herramienta general para observar el comportamiento de sistemas. Su salida puede utilizarse para alimentar un componente de análisis que decidirá sobre acciones correctivas. Astrolabe organiza una gran colección de servidores en cierta jerarquía por zonas. Las zonas de menor nivel constan de un solo servidor, las cuales posteriormente se agrupan en zonas de mayor tamaño. La zona de mayor nivel comprende todos los servidores. Cada servidor ejecuta un proceso Astrolabe, llamado agente, que colecciona información sobre las zonas en las que se encuentra ese servidor. El agente se comunica también con otros agentes con la intención de esparcir información de la zona a través de todo el sistema. Cada servidor mantiene un conjunto de atributos para recopilar información local. Por ejemplo, un servidor puede rastrear archivos específicos que almacena, utilizar recursos, etc. Sólo aquellos atributos mantenidos directamente por un servidor, es decir, al nivel más bajo de la jerarquía, pueden escribirse. Cada zona puede tener una colección de atributos, pero los valores de éstos se calculan a partir de los valores de las zonas de más bajo nivel. Considere el sencillo ejemplo que muestra la figura 2-17 con tres servidores, A, B y C, agrupados en una zona. Cada máquina rastrea su dirección IP, la carga de la CPU, la memoria libre disponible, y el número de procesos activos. Cada uno de estos atributos puede escribirse directamente utilizando información local de cada servidor. A nivel de zona, sólo puede recopilarse información agregada, tal como el promedio de carga de la CPU o el número promedio de procesos activos.

La figura muestra la manera en que puede verse la información reunida en cada máquina como un registro en una base de datos, y que estos registros juntos forman una relación (tabla). Esta representación se hace a propósito: es la forma en que Astrolabe ve todos los datos recopilados. Sin embargo, la información por zona sólo puede calcularse a partir de registros básicos que mantienen los servidores. La información agregada se obtiene mediante funciones de agregación programables, las cuales son muy parecidas a las funciones disponibles del lenguaje de bases de datos relacionales SQL. Por ejemplo, suponiendo que la información del servidor de la figura 2-17 se mantiene en una tabla local llamada hostinfo, podríamos recopilar el número promedio de procesos para la zona que contiene las máquinas A, B y C mediante la sencilla consulta SQL. SELECT AVG(procs) AS procs_prom FROM hostinfo Combinada con algunas mejoras a SQL, no es difícil suponer que puedan formularse más consultas informativas. Consultas como éstas son evaluadas continuamente por cada agente que se ejecuta en cada servidor. Desde luego, esto es posible sólo si la información de la zona se propaga a todos los nodos que conforman Astrolabe. Con este fin, un agente que se ejecuta en un anfitrión es responsable de calcular algunas partes de las tablas de sus zonas asociadas. De manera ocasional se le envían registros, para los que no existe responsabilidad de cálculo, a través de un sencillo pero efectivo procedimiento de intercambio conocido como gossiping. En el capítulo 4 explicaremos con detalle los protocolos del gossiping. De igual manera, un agente pasará también resultados calculados a otros agentes. El resultado de este intercambio de información es que, en algún momento, todos los agentes que necesiten apoyar la obtención de cierta información agregada verán el mismo resultado (porque mientras tanto no hay cambios).

6.2. Ejemplo: cómo diferenciar estrategias de replicación en Globule Ahora demos un vistazo a Globule, una red colaboradora de distribución de contenido (Pierre y Van Steen, 2006). Globule se basa en servidores de usuario final colocados en internet, los cuales colaboran para optimizar el rendimiento a través de la replicación de páginas web. Para lograr esto, cada servidor de origen (es decir, el servidor utilizado para manejar las actualizaciones de un sitio web específico) rastrea patrones de acceso por página. Los patrones de acceso se expresan como operaciones de lectura y escritura para una página, y el servidor de origen para esa página registra cada operación y la marca con un tiempo. En su forma más sencilla, Globule asume que internet puede verse como un sistema servidor puente, como ya explicamos. En particular, asume que las solicitudes siempre pueden pasar a través de un servidor puente adecuado, según muestra la figura 2-18. Este sencillo modelo permite a un servidor de origen ver qué ocurriría si colocara una réplica en un servidor puente específico. Por una parte, colocar una réplica cerca de los clientes mejoraría la espera percibida por ellos, pero induciría tráfico entre el servidor de origen y el servidor puente para mantener una réplica consistente con la página original.

Cuando un servidor de origen recibe una petición para una página, éste registra la dirección IP desde donde se originó la petición y busca al ISP o a la red empresarial asociada con la petición utilizando el servicio de internet WHOIS (Deutsch y cols., 1995). El servidor de origen busca después al servidor de réplicas más cercano, que podría actuar como servidor puente para ese cliente, y posteriormente calcula la espera para ese servidor junto con el ancho de banda máximo. En su configuración más simple, Globule supone que la espera entre el servidor de réplicas y la máquina del usuario solicitante es insignificante, y de igual manera asume que el ancho de banda entre los dos es enorme. Una vez reunidas suficientes peticiones para una página, el servidor de origen realiza un sencillo “análisis qué sucede si”. Tal análisis se reduce a evaluar varias políticas de replicación, donde una política describe en dónde replicar una página y cómo mantenerla consistente. Cada política de replicación tiene un costo que puede expresarse como una función lineal simple:

costo (w1 m1) (w2 m2) … (wn mn) donde mn denota una métrica de rendimiento y wn es una ponderación para indicar qué tan importante es dicha métrica. Las métricas de rendimiento típicas se agregan a los retrasos entre un servidor cliente y un servidor de réplicas cuando devuelven copias de las páginas web, el ancho de banda total consumido entre el servidor de origen y el de réplicas para mantener consistente a una réplica, y el número de copias devueltas a un cliente (Pierre y cols., 2002). 6.3. Ejemplo: administración de la reparación automática de componentes en Jade Cuando se da mantenimiento a clusters de computadoras, cada una compuesta por sofisticados servidores, resulta importante mitigar los problemas de administración. Un método que puede aplicarse a servidores construidos bajo métodos basados en componentes es detectar las fallas latentes en ellos y reemplazarlos automáticamente. El sistema Jade sigue este enfoque (Bouchenak y cols., 2005). En esta sección lo describimos brevemente. Jade está construido sobre el modelo de componentes Fractal, una implementación de Java de un Framework que permite agregar y eliminar componentes al tiempo de ejecución (Bruneton y cols., 2004). Un componente en Fractal puede tener dos tipos de interfaces. Una interfaz de servidor utilizada para llamar métodos que se implementan mediante ese componente; y una interfaz de cliente que utiliza un componente para llamar a otros componentes. Los componentes se conectan uno con otro mediante interfaces de vinculación. Por ejemplo, una interfaz de cliente del componente C1 puede vincularse con la interfaz de servidor del componente C2. Una primitiva de vinculación significa que una llamada a una interfaz de cliente resulta directamente en llamar a la interfaz de servidor vinculada. En el caso de vinculación compuesta, la llamada puede proceder a través de uno o más componentes, por ejemplo, debido a que la interfaz de cliente y la interfaz de servidor no coincidieron y es necesario entonces implementar algún tipo de conversión. Otra razón puede ser que los componentes conectados se encuentren en máquinas diferentes. Jade utiliza la idea de un dominio de administración de reparaciones. Tal dominio consiste en cierto número de nodos, donde cada nodo representa un servidor junto con los componentes que éste ejecuta. Aparte existe un nodo administrador responsable de agregar y eliminar nodos del dominio. El nodo administrador puede replicarse para garantizar una alta disponibilidad. Cada nodo está equipado con detectores de fallas, los cuales monitorean el bienestar de un nodo o de uno de sus componentes e informan sobre cualquier falla al nodo administrador. En general, estos detectores consideran cambios excepcionales en el estado de los componentes, el manejo de recursos, y la falla real de un componente. Observe que lo último puede significar, en realidad, que una máquina se ha estropeado. Cuando una falla es detectada, se inicia un procedimiento de reparación. Tal procedimiento es dirigido por una política de reparación parcialmente ejecutada por el nodo administrador. Las políticas se establecen explícitamente y se llevan a cabo de

acuerdo con la falla detectada. Por ejemplo, supongamos que se detectó la falla de un nodo. En ese caso, la política de reparación puede indicar que se realicen los siguientes pasos: 1. Finalizar toda vinculación entre un componente en un nodo sin problemas y un componente en el nodo que ha fallado. 2. Solicitar al nodo administrador que inicie y agregue un nuevo nodo al dominio. 3. Configurar el nuevo nodo exactamente con los mismos componentes que se encontraban en el nodo que falló. 4. Restablecer todos los vínculos que finalizaron anteriormente. En este ejemplo, la política de reparación es sencilla y sólo funcionará cuando no se hayan perdido datos cruciales (se dice que los componentes arruinados son desplazados). El método seguido por Jade es un ejemplo de autoadministración: conforme se detecta una falla, se ejecuta automáticamente una política de reparación para llevar al sistema como un todo al estado en el que se encontraba antes del problema. Al ser un sistema basado en componentes, esta reparación automática requiere de un soporte específico para permitir que se agreguen y eliminen componentes al tiempo de ejecución. En general, no es posible cambiar aplicaciones preexistentes en sistemas de autoadministración. 7. Conclusiones

8. Bibliografía 

MARTINEZ, Alfonso (abril-2012) Anteproyecto de Investigación: Sistemas de Computo Centrado en Atención a la Salud.



POZA LUJÁN, José (noviembre de 2009) Revisión de los Sistemas de Comunicaciones más empleados en Control Distribuido https://www.researchgate.net/publication/50838676_Revision_de_los_S istemas_de_Comunicaciones_mas_empleados_en_Control_Distribuido



PESADO Patricia, PABLO, Thomas (abril-2013) Métodos y Procesos para Sistemas Distribuidos. Experiencias. http://sedici.unlp.edu.ar/bitstream/handle/10915/27250/Documento_c ompleto.pdf?sequence=1



ANDREW S.TANENBAUM, Maarten (2008). Sistemas Distribuidos Principios y Paradigmas. http://www.academia.edu/21420808/SISTEMAS_DISTRIBUIDOS_SIS TEMAS_DISTRIBUIDOS_Principios_y_Paradigmas



Redes locales y globales, Mecanismos de autoconfiguración https://sites.google.com/site/redeslocalesyglobales/6-arquitecturas-deredes/6-arquitectura-tcp-ip/7-nivel-de-red/8-direccionamiento-ipv6/4asignacion-de-direcciones-ipv6-a-equipos-y-encaminadores/1mecanismos-de-autoconfiguracion

 TURPO, Einar Sistemas Distribuidos http://www.unap.edu.pe/cidiomas/licing/pdf/sd.pdf



Sistemas Distribuidos tolerantes a fallas http://fallasensistemasdistribuidos.blogspot.com/2006/08/unidad-1-sistemasdistribuidos.html



UNIVERSIDAD DE CANTABRIA Planificación, análisis y optimización de sistemas distribuidos de tiempo real estricto https://repositorio.unican.es/xmlui/handle/10902/1546



Sistemas Distribuidos y Basados en Conocimiento para el Monitoreo y Control en el Tratamiento de Aguas Residuales http://www.metallurgie.rwthaachen.de/new/images/pages/publikationen/sistemaes_distr_id_3544.pdf



VERDE, Cristina (marzo 2016) Retroalimentación y sincronía en procesos https://www.revistaciencia.amc.edu.mx/images/revista/67_1/PDF/Retroalim entacion.pdf