Вы находитесь на странице: 1из 8

MINISTRIO DA EDUCAO

UNIVERSIDADE TECNOLGICA FEDERAL DO


PARAN
CAMPUS CORNLIO PROCPIO
ENGENHARIA DE COMPUTAO
C81

ANDR LUS MARTINS BANDEIRA 1146556


GUILHERME CAMARGO 1205935

ASTROLABE

CORNLIO PROCPIO
2014

PR

UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN

1. INTRODUO
Atualmente com sistemas distribudos cada vez mais sofisticados, como por exemplo sistemas
pervasivos ou sistemas de grid computing, dinamismo e complexidade so caractersticas
intrnsecas de um sistema moderno [Liu et al. 2004].
Por vezes, esses novos modelos de sistemas possuem comportamentos no esperados, isso
ocorre em sistemas distribudos que devido sua estrutura so sujeitos a alteraes de
comportamento, essas alteraes podem ocorrer devido a falhas de recursos (que so considerveis
em sistemas de larga escada), heterogeneidade e concorrncia.
Segundo [Corra; Cerqueira, 2009], outro entrave considervel atualmente est na dificuldade
de monitoramento completo do comportamento do sistema do comportamento do sistema, isso
ocorre pois com unidades independentes, cada servio pode prover prticas de gerenciamento
especficas e consideravelmente diferentes entre si.
Com a unio dessas caractersticas, temos uma enorme dificuldade na administrao dos
sistemas distribudos atuais e futuros. Segundo Salehie and Tahvildari (2005), quase metade dos
recursos gastos em sistemas distribudos so para recuperaes de falhas, manutenes preventivas,
e determinao de problemas.
Como resultado desse quadro a IBM [Horn 2001] elaborou um manifesto que buscava alertar
que a principal dificuldade para futuras inovaes de TI seria a incapacidade humana de gerenciar
software complexos. O conceito de Computao Autnoma foi proposta por esse manifesto para
tratar tal problema, esse conceito definia sistemas capazes de realizar um autogerenciamento atravs
de um conjunto de objetivos definidos anteriormente.
Segundo Braga et al. (2006), apesar de haver alguns paradigmas j definidos para a construo
de qualquer sistema auto gerencivel, cada projeto dever possuir uma soluo especfica. Nesse
contexto, um software dever ter algumas propriedades para que possa ser considerado auto
gerencivel, conforme figura 1.

Figura 1: Propriedade Gerais para Computao Autonoma [Sterrit and Bustard 2003].

2. FUNCIONAMENTO
Um sistema distribudo auto gerencivel dever conter um objetivo e escolhas especficas que
podem depender de estados no conhecidos antecipadamente. Para atingir o objetivo necessrio
implementar um modelo de realimentao de controle; Esse modelo consiste em um ciclo bem
definido, desenvolvendo as atividades de Medio, Deciso e Controle, conforme figura 2.

Figura 2: Ciclo de Gerenciamento [Corra; Cerqueira, 2009]


A funo de Medio, utilizada para coletar e filtrar os dados do sistema distribudo utilizado.
Esses dados so comumente mtricas dos sistemas. Porm podem ser outros dados como eventos do
sistema. A deciso envolve examinar os dados coletados pela Medio e verificar se esses esto de
acordo com o objetivo pr-determinado. Se no esto determina que devem ser realizadas mudanas
sobre as polticas do sistema distribudo. Como essa deciso chamada a funo de Controle: que
controla a execuo das mudanas identificadas como necessrias pela funo de Deciso.
Na funo de Medio, uma importante ferramenta utilizada para a observao do
comportamento do sistema o Astrolabe, em outras palavras, o Astrolabe pode ser definido como
uma ferramenta para observao de sistemas distribudos e que contm resultados que podem ser
usados para alimentar um componente de anlise para possveis aes corretivas.
O Astrolabe organiza os hospedeiros do sistema distribudo em uma hierrquica de zonas. As
zonas de nvel mais baixo abrangem um nico hospedeiro, enquanto a zona de nvel mais alto
abrange todos os hospedeiros [Tanenbaum; Steen, 2007]. Cada hospedeiro possui um processo
Astrolabe, que colhe informao nas zonas onde o hospedeiro est contido. Essas informaes so
passavas para outros processos Astrolabe situados em outros hospedeiros, de forma a espalhar as
informaes pelo sistema.
Cada hospedeiro possui um conjunto de atributos que dever monitorar para coletar
informaes. Um hospedeiro s pode alterar valores de seus prprios atributos. Uma zona tambm

pode possuir um conjunto de atributos, porm esses atributos s podem ser calculados com base nos
atributos de uma zona de nvel mais baixo.
3. ASTROLABE
Astrolabe monitora o estado de alterao dinmica de uma coleo de recursos distribudos,
relatando resumos dessas informaes para seus usurios.
Como o DNS, o Astrolabe organiza os recursos em uma hierarquia de domnios, que chamamos
de zonas (para evitar confuso), e associados atributos com cada zona. Ao contrrio do DNS, zonas
no so vinculadas a servidores especficos, os atributos podem ser altamente dinmicos e
atualizaes propagam rapidamente; tipicamente, em dezenas de segundos.
O Astrolabe calcula continuamente resumos dos dados no sistema utilizando agregao
dinmica. O mecanismo de agregao controlada por consultas SQL, e pode ser entendido como
um tipo de capacidade de extrao de dados. Por exemplo, a agregao do Astrolabe pode ser usada
para monitorar o status de um conjunto de servidores espalhados dentro da rede, para localizar um
recurso desejado, com base nos seus valores de atributo, ou para calcular uma descrio sumria das
cargas sobre os componentes crticos da rede. Como essa informao muda, o Astrolabe
automaticamente e rapidamente recalcula os agregados associados e relata as mudanas para
aplicativos que tenham registrado o seu interesse.
Agregao entendido como um mecanismo de sumarizao. Por exemplo, um agregado podia
contar o nmero de ns que satisfazem alguma propriedade, mas no para concatenar seus nomes
em uma lista, uma vez que a lista poderia ser de tamanho ilimitado. (Teoricamente, um nmero
ilimitado cresce bem, mas, na prtica, um nmero fixo de bits utilizado para representar o
nmero). A abordagem destinada para limitar a taxa de fluxo de informao a cada n
participante, de modo que, mesmo sob condies de pior caso, vai ser independente do tamanho do
sistema. Para este fim, cada agregado restrito a algum escopo, dentro do qual calculado em
nome e visvel para todos os ns. Somente agregados com alto valor global dever ter escopo
global. O nmero de agregao de consultas ativo dentro de um determinado alcance assumido
como sendo razoavelmente pequena, e independente do tamanho do sistema. Para garantir que os
aplicativos no violem acidentalmente estas polticas, os ns que procuram introduzir uma nova
funo de agregao deve ter direitos administrativos no escopo onde ser computado.
A experincia inicial com os mecanismos de agregao Astrolabe demonstram que o sistema
extremamente potente, apesar dos seus limites. Administradores de um aplicativo podem usar a
tecnologia para monitorar e controlar uma aplicao distribuda utilizando agregados que resumem
o estado geral dentro da rede como um todo, e tambm dentro dos domnios (escopos) de que a

compem. Uma nova mquina no sistema poderia usar o Astrolabe para descobrir informaes
sobre os recursos disponveis nas proximidades: explorando os mecanismos de escopo da instalao
de agregao, os recursos apresentados do domnio sero os de maior valor parecido das aplicaes
dessa regio da rede. Aps uma falha, o Astrolabe pode ser usado tanto para a notificao e para
coordenar a reconfigurao. Mais amplamente, qualquer forma de aplicao de baixo acoplamento
poderia usar Astrolabe como uma plataforma para coordenar as tarefas distribudas. De fato,
Astrolabe usa as suas prprias capacidades de autogerenciamento.
Pode parecer que projetar um agregado que seja suficientemente conciso e ainda ter alto valor
para as aplicaes uma arte. No entanto, o problema pode ser relativamente simples e no muito
diferente do projeto de um banco de dados hierrquico. Um nmero relativamente pequeno de
mecanismos agregados seja suficiente para lidar com uma grande variedade de possveis
necessidades. De fato, a experincia apoia a hiptese de que as formas de informao necessrias
para a gesto em larga escala, configurao e controle so geralmente passveis de uma
representao compacta.
O Astrolabe mantm uma excelente capacidade de resposta at mesmo quando o sistema se
torna muito grande, e mesmo que tenha dinamismo significante. As cargas associadas com a
tecnologia so pequenas e limitadas, tanto ao nvel das taxas de mensagens visto por mquinas de
participantes e cargas impostas sobre os meios de comunicao. Astrolabe tambm tem uma
pequena "pegada" no sentido de despesas gerais de computao e armazenamento.
O sistema Astrolabe olha para um usurio como um banco de dados, embora seja um banco de
dados virtual que no reside em um servidor centralizado, e no suporta transaes atmicas. Esta
apresentao de dados se estende a vrios aspectos. Mais importante ainda, cada zona pode ser vista
como uma tabela relacional contendo os atributos de suas zonas filho, que por sua vez pode ser
consultado por meio de SQL. Alm disso, usando os mecanismos de integrao de banco de dados
como ODBC e JDBC, ferramentas de programao padro de banco de dados podem acessar e
manipular os dados disponveis atravs de Astrolabe.
O projeto de um Astrolabe reflete quatro princpios:
1.

Escalabilidade atravs da hierarquia: Um sistema escalvel aquele que mantm constante

(ou lentamente degradante) o desempenho medida que seu tamanho aumenta. Astrolabe alcana
escalabilidade atravs de sua zona hierrquica. As informaes nas zonas so sumarizadas antes de
ser trocadas entre as zonas, mantendo os requisitos de armazenamento e de comunicao de longa
distncia em um nvel administrvel. Dado limites sobre o tamanho de informao numa zona, os
custos computacionais e de comunicao do Astrolabe se mostram crescer lentamente, com o
nmero de participantes.
2.

Flexibilidade atravs de cdigo mvel: aplicaes diferentes monitoraram dados diferentes,

e uma nica aplicao pode precisar de dados diferentes em momentos diferentes. A forma restrita
de cdigo mvel, na forma de consultas de agregao SQL, permite aos usurios personalizar o
Astrolabe instalando novas funes de agregao dinamicamente.
3.

Robustez atravs de um protocolo peer-to-peer randomizado: sistemas baseados em


servidores centralizados so vulnerveis falhas, ataques e m gerenciamento. Em vez disso, o
Astrolabe usa uma abordagem peer-to-peer executando um processo em cada Host. Esses processos
se comunicam atravs de um protocolo de epidmico. Esses protocolos so altamente tolerantes a
muitos cenrios de falhas, fcil de implementar e eficiente. Eles se comunicam usando troca
randomizado ponto-a-ponto de mensagem, uma abordagem que faz o Astrolabe robusto, mesmo em
momentos de sobrecargas localizadas, que podem brevemente desligar regies da internet.

4.

Segurana atravs de certificados: Astrolabe utiliza assinaturas digitais para identificar e


rejeitar dados potencialmente corrompidos e para controlar o acesso s operaes potencialmente
custosas. Informaes da zona, mensagens de atualizao, configurao e credenciais do cliente,
todos so encapsulados em certificados assinados. A prpria rvore da zona constitui a
infraestrutura de chave pblica.
4. EXEMPLO
Para exemplificar, temos a uma zona com trs mquinas agrupadas nela, conforme figura 3.

Figura 3: Exemplo de zona com trs hospedeiros [Autoria Prpria]


Cada hospedeiro armazena os seguintes atributos: Endereo de IP, carga de CPU, memria livre
disponvel e a quantidade de processos ativos. A zona X pode agrupar os atributos dos hospedeiros,
como carga mdia da CPU, memria livre disponvel media e quantidade mdia de processos
ativos.
A figura 4 contm os atributos armazenados pelos hospedeiros, onde cara linha da tabela
representa um hospedeiro, este o tipo de representao usada pelo Astrolabe. A figura 4 tambm
contm os dados dos hospedeiros da zona X j agrupadas e calculados a mdia.

Figura 4: Coleta de dados e agregao de informaes Astrolabe [Tanenbaum; Steen, 2007].

REFERNCIAS
LIU, H., PARASHAR, M., HARIRI, S. A Component Based Programming Framework for
Autonomic Applications. In Proceedings of The International Conference on Autonomic Computing
(ICAC04), p. 1017, Los Alamitos, CA, USA. IEEE Computer Society, 2004.
CORRA, S., CERQUEIRA R. Computao Autnoma: Conceitos, Infra-estruturas e Solues em
Sistemas Distribudos. 27 Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos,
p. 152-198, Recife, Brasil, 2009.
SALEHIE, M., TAHVILDARI, L. Autonomic Computing: emerging trends and open problems.
Sigsoft Softw. Eng. Notes, 30(4):17, 2005.
HORN, P. Autonomic Computing: IBM Perspective on the State of Information Technology, IBM
T.J. Watson Labs, NY, 15th October 2001. Presented at AGENDA 2001, Scotsdale, AR. Disponvel
em http://www.research.ibm.com/autonomic/.
BRAGA, T. R. M., SILVA, F. A., RUIZ, L. B., ASSUNO, H. P. Redes Autonmicas. 24
Simpsio Brasileiro de Redes de Computadores, Curitiba, Brasil, 2006.
STERRITT, R. and BUSTARD, D. (2003). Autonomic Computing: A Means of Achieving
Dependability? In Proceedings of IEEE International Conference on the Engineering of Computer
Based Systems (ECBS03), p. 247251, Los Alamitos, CA, USA. IEEE Computer Society.
TANENBAUM, A S., STEEN, M. T.. Sistemas Distribudos: princpios e paradigmas. So Paulo:
Pearson Prentice Hall, 2007. 402 p.

Вам также может понравиться