Академический Документы
Профессиональный Документы
Культура Документы
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
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.
1.1 Auto-conocimiento
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.
1.3 Auto-recuperación
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.
1.4 Auto-optimización
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.
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
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”.
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
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.3. IBM
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
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.
6. Ejemplos
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.
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
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
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:
7. Conclusiones
8. Bibliografía