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
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
3. 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
https://mairita.webnode.es/nosotros/
2
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, auto-
optimizació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

3
Sistemas Distribuidos y Basados en Conocimiento para el Monitoreo y Control en el Tratamiento de Aguas
Residuales
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
Redes locales y globales, Mecanismos de autoconfiguración
5 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
Sistemas Distribuidos tolerantes a fallas
7
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
10
Retroalimentación y sincronía en procesos
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-de-
redes/6-arquitectura-tcp-ip/7-nivel-de-red/8-direccionamiento-ipv6/4-
asignacion-de-direcciones-ipv6-a-equipos-y-encaminadores/1-
mecanismos-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-sistemas-
distribuidos.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.rwth-
aachen.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