Gerenciamento de redes em grades computacionais: uma ... · abordagem usando redes de sensores e...

Gerenciamento de redes em grades computacionais: umaabordagem usando redes de sensores e contexto no

monitoramento de redes

Douglas de Oliveira Balen1, Hans Alberto Franke1, Eduardo Andre Hartmann1,Carlos Becker Westphall1

1Departamento de Informatica e EstatısticaUniversidade Federal de Santa Catarina (UFSC)

Caixa Postal 476 – 88040-970 – Florianopolis – SC – Brazil

{douglasb,koiote,dudahart,westphal}@inf.ufsc.br

Abstract. Grid computing enables the aggregation and sharing of computingresources from multiple administrative domains. There has been an increas-ing adoption of the model where providers offer resources to Grids in returnfor some kind of compensation. Examples include multi-purpose Grid infras-tructures and the increasing interest in utility computing centres. These centreshave heterogeneous resources, requiring management tools that: can managevarying kinds of resources; are highly configurable, being able to self-adjust todifferent operating systems and hardware, or contexts; and provide the manage-ment information required to guide the resource provisioning and orchestrationprocesses. The objective of this work is proposing a self-adjust managementarchitecture, essential for providers, that it fills the gap found in current archi-tectures.

Resumo. Computacao em grade possibilita a agregacao e compartilhamentode recursos computacionais de diferentes domınios administrativos. Nas gradesatuais e crescente o numero de provedores que oferecem recursos mediante al-guma forma de compensacao. Como exemplos pode-se considerar o aumentode grades operando como infra-estruturas multi-proposito e o crescente inter-esse em centros de utility computing. Esses centros possuem recursos varia-dos e precisam de ferramentas de gerenciamento que: possam gerenciar variostipos de recursos; sejam altamente configuraveis, de forma que possam adaptar-se a diferentes sistemas operacionais e equipamentos, ou contextos; e possamprover as informacoes de gerenciamento necessarias para auxiliar os proces-sos de aprovisionamento e coordenacao. O objetivo desse trabalho e proporuma arquitetura de gerenciamento auto-adaptavel ao contexto, indispensavelaos provedores, que venha suprir as lacunas encontradas nas arquiteturas atu-ais.

1. Introducao

Tecnologias de computacao em grade possibilitam a agregacao de recursos computa-cionais pertencentes a multiplos domınios administrativos [Foster et al. 2001]. Gradessao geralmente utilizadas por aplicacoes que requerem um grande numero de recursos

13º Workshop de Gerência e Operação de Redes e Serviços 95

computacionais, acesso a grandes conjuntos de dados distribuıdos ou o compartilhamentode instrumentos cientıficos de custo elevado.

Os principais modelos organizacionais adotados por grades sao baseados no con-ceito de Organizacoes Virtuais (OVs) [Foster et al. 2001]. Neste cenario, um grupo deorganizacoes ou pessoas decide formar uma OV para compartilhar recursos e atingir umobjetivo comum. De modo geral, os membros de uma OV definem os recursos que saooferecidos a OV, sendo que esta possui polıticas que definem como o conjunto de recursose alocado aos seus membros. Essas OVs sao formadas com um espırito de colaboracaoentre seus membros, sendo que um participante que doa os seus recursos pode ser com-pensado com o acesso a recursos de outros.

Recentemente, percebe-se mudancas sutis na forma como recursos sao aloca-dos a OVs, com provedores esperando alguma forma de compensacao financeira. Aemergencia do modelo utility computing, por exemplo, no qual um usuario paga ape-nas pelos recursos que utiliza tem levado a criacao de provedores de chamados utilitydata centres. Um utility data centre possui um conjunto de recursos que sao alocadospara varios servicos ou aplicacoes. Desta forma, um utility data centre pode prover recur-sos a diferentes comunidades cientıficas ou OVs, permitindo o isolamento de ambientee desempenho. Da mesma forma, algumas infra-estruturas de grades tem operado comoplataformas multi-proposito, procurando atender as necessidades de varias comunidades[Catlett et al. 2006].

Entretanto, esse cenario apresenta varios desafios. Um utility data cen-tre ou uma grade multi-proposito [Assuncao and Buyya 2006] prove recursos paravarias comunidades, oferecendo isolamento de ambientes e executando os servicos eaplicacoes necessarias nos ambientes de aplicacao [Wilkes et al. 2004]. O processo deinstrumentacao de recursos, tambem chamado de orquestracao, no qual os recursosnecessarios para esses ambientes sao definidos, necessita de informacao de gerencia-mento concisa que reflete o estado dos recursos. Da mesma forma, o aprovisionamentode recursos para esses ambientes depende de informacao de gerenciamento que reflitaas condicoes atuais dos recursos utilizados e dos servicos e aplicacoes sendo executa-dos. Seria importante se tais processos pudessem ser semi-autonomos, requerendo poucaintervencao humana. Portanto, esses cenarios devem confiar em ferramentas de gerenci-amento que possam ser configuraveis para gerenciar varios tipos de recursos, servicose aplicacoes. A informacao adquirida deve ser concisa a ponto de fornecer poucosparametros que representam uma visao dos sistemas ou dos ambientes de aplicacoes.As ferramentas de gerenciamento devem, desta forma, se auto-adaptar ao contexto ondeestao inseridas.

Atualmente, existem varias ferramentas que captam informacoes, mas nao sao ca-pazes de prover as funcionalidades descritas acima e nao sao sensıveis ao contexto em queestao inseridas. Essas necessidades nos motivam a investigar uma arquitetura de geren-ciamento e um gerenciador que possa ser sensıvel ao contexto, e traga a inferencia dosdados para perto de onde o dado foi coletado, reduzindo a necessidade de transmissaode informacoes desnecessarias e provendo informacao relevante aos processos de aprovi-sionamento e instrumentacao.

Este trabalho descreve uma arquitetura de gerenciamento capaz de analisar o am-

96 13º Workshop de Gerência e Operação de Redes e Serviços

biente em que esta inserido e realizar o monitoramento de acordo com este ambiente, semque para isso seja necessario instalar novos aplicativos. Este tipo de arquitetura permiteo gerenciamento de ambientes heterogeneos, formados por computadores pessoais, assis-tentes pessoais digitais, sensores, entre outros. O restante deste trabalho esta organizadoda seguinte forma: a Secao 2 apresenta as motivacoes, analise de requisitos e trabalhosrelacionados; na Secao 3 a proposta do Grid Manager e apresentada; a Secao 4 apresentaresultados da implementacao da arquitetura; a conclusao e trabalhos futuros sao apresen-tados na Secao 5.

2. Motivacao, Analise e Trabalhos Relacionados2.1. MotivacaoPor nao haver uma infra-estrutura homogenea, o monitoramento dos nos da grade torna-se uma tarefa difıcil de ser realizada, ja que cada dispositivo pode apresentar um contextodiferente, o qual deve ser tratado de modo especıfico. Portanto, a questao que se desejaresponder neste trabalho e: como propor uma arquitetura que seja capaz de analisar oambiente e coletar informacoes dos nos, de acordo com seu contexto? Alem disso, comocriar um ponto de acesso no qual processos interessados possam obter os dados coletadose como esses dados podem ser visualizados pelo gerente de rede?

No intuito de responder a essas perguntas, e proposta uma arquitetura de geren-ciamento distribuıda, que faz parte do projeto Grid-M [Franke et al. 2007]. Este trabalhoapresenta a integracao de temas atuais como gerencia de redes, computacao em grade,sensores e contexto.

2.2. Analise de RequisitosComo mencionado anteriormente, gerenciamento e fundamental em um ambiente degrades de computadores. Porem, a principal duvida refere-se a quais modelos devem serutilizados e implementados para possibilitar o gerenciamento de grades de computadores.Intuitivamente, pode-se pensar em duas abordagens:

• (i) um modelo de gerenciamento centralizado, como o baseado em Simple Net-work Management Protocol (SNMP), no qual um elemento gerenciado envia da-dos de gerenciamento mediante uma solicitacao de uma central. Essa, por sua vez,analisa a situacao do elemento gerenciado e comanda mudancas;

• (ii) distribuıdo, no qual o elemento gerenciado tem condicao de gerenciar aspectosdo seu padrao de execucao.

As tabelas 1 e 2 apresentam as vantagens e desvantagens de cada abordagem.

Devido a heterogeneidade e dinamica do ambiente, de acordo com (i), serianecessario configurar diferentes servicos de gerenciamento para diferentes elementos dagrade. Por outro lado, seguindo a abordagem (ii), seria possıvel estabelecer um conjuntopadrao de parametros de gerenciamento comuns entre todos os elementos, podendo-se,assim, estabelecer um unico sistema de gerenciamento para todos os elementos da grade.Para que isso seja possıvel, basta que cada dispositivo implemente uma interface de geren-ciamento do middleware.

Um elemento da grade tem tres caracterısticas comuns a todos os dispositivos,independentemente do tipo:


Tabela 1. Vantagens e desvantagens da abordagem centralizadaVantagens DesvantagensCompatibilidade: Agentes SNMPestao disponıveis para diversos dis-positivos de rede, como computa-dores, pontes, modens e impressoras.

Por afastar a decisao do local onde a execucaoesta ocorrendo, pode acarretar situacoes deexcesso de trafego de gerenciamento, atraso,falta de dados, etc.

Homogeneizacao: Pode ser uti-lizado em varios tipos de dispositivos,porque e simples. Concentra a maiorparte do processamento na estacao degerenciamento, mantendo um agentesimples nos elementos gerenciados.

Exige que uma unica estacao de gerencia-mento de rede tenha que analisar todas asinformacoes de gerenciamento. Os elementosgerenciados possuem agentes responsaveispor abastecer bases de informacoes de geren-ciamento localizadas nos elementos cominformacoes coletadas por sensores e outrosdispositivos.

Em virtude de seguir um projetosimples, o protocolo e bases deinformacao de gerenciamento po-dem ser atualizados com facilidadede acordo com as necessidades deusuarios.

As atividades de gerenciamento consomemlargura de banda com transmissao de da-dos e recursos da estacao de gerenciamentopara processamento e analise. Em uma redecomplexa de largas proporcoes, o numero denos gerenciados e grande. O gerenciamentocentralizado pode requerer uma estacao degerenciamento com alta capacidade de pro-cessamento.

• Um ambiente computacional cujos elementos (CPU, memoria, sistema opera-cional, disco, etc) dificilmente mudarao . Os dados do contexto do ambientepodem ser coletados e usados como referencia.

• Um modelo de execucao de servicos, no qual cada elemento da grade e um prove-dor de servicos, que contem parametros como carga, tempo de execucao, tipos deservicos sendo executados, entre outros.

• Uma estrutura de comunicacao que tem parametros como volume de dados trans-mitidos, tempo de transmissao, etc.

Pode-se realizar a inferencia e analise dos dados coletados e aplicar polıticas bemdefinidas, que formariam as regras de gerenciamento. Ao observar que alguma regra napolıtica foi violada, poderia-se disparar uma notificacao na forma de alerta. Exemplo:uma regra na polıtica diz que todos os nos devem manter no mınimo 5 MB de memorialivre. Se essa regra for violada, um alerta de falta de memoria e disparado.

O principal objetivo deste trabalho e apresentar uma arquitetura de gerencia-mento altamente configuravel, capaz de adaptar-se a diferentes sistemas operacionaise equipamentos, ou contextos, e que possam prover as informacoes de gerenciamentonecessarias para auxiliar os processos interessados nos dados gerenciados. Alem deste,outros tambem sao importantes:

• Interface funcional visualizada pelo navegador, fazendo com que todos os elemen-tos da grade sejam monitorados.


Tabela 2. Vantagens e desvantagens da abordagem distribuıdaVantagens DesvantagensReduz o trafego na rede, por trazera deliberacao para proximo de ondeos dados sao coletados. Assim, pode-se realizar a analise localmente, bemcomo a tomada de decisao.

Complexidade na coordenacao das atividadesde gerenciamento.

Em conjunto com tecnologias ade-quadas, como agentes, pode facilitaro gerenciamento autonomo de redes.

• Os dados coletados podem ser utilizados por servicos que devem garantir Quali-dade de Servico (QoS).

• Ser ”leve”, para que possa ser instalado em dispositivos de pequeno poder deprocessamento e armazenamento.

2.3. Trabalhos Relacionados

Este trabalho propoe a implementacao de uma ferramenta que engloba temas das areasde gerencia e monitoramento de recursos. Varias arquiteturas tem sido propostas, nosultimos anos, para prover gerencia distribuıda no ambiente de grades computacionais.Mas essas arquiteturas nao implementam alguns requisitos levantados na Secao 2.2. Den-tre os trabalhos relacionados nesta area, destacam-se:

• NetLogger [Gunter et al. 2000]: permite realizar o monitoramento dos recursosdisponıveis no ambiente de grade atraves da instalacao e execucao de sensoresnas maquinas a serem observadas. Esses sensores fazem uso do protocolo LDAPpara permitir o registro e publicacao de informacoes, que sao posteriormente ar-mazenadas em um banco de dados.

• MonALISA [Newman et al. 2003]: e um framework usado para coletar e agre-gar informacoes de monitoramento. Alem de prover completo monitoramento,permite tambem controlar e otimizar os servicos globalmente para sistemas com-plexos. Esse sistema e baseado no modelo publish/subscribe e em um banco dedados relacional backend, requerendo que os dados das estacoes monitoradas se-jam enviadas a um repositorio central, sendo exibidos em uma interface interativa.Mas essa interface nao informa explicitamente as estatıstica referentes a cada re-curso, dificultando um pouco o entendimento do ambiente.

• RUS (Resource Usage Service) [RUS 2005]: prove estatısticas relacionadas dadosreferentes a execucao de aplicacoes em execucao e recursos na grade. Mas o RUSnao define como os dados devem ser coletados, processados e apresentados aoadministrador.

• Ganglia [Team 2006], que e um sistema escalonavel de monitoramento distribuıdopara sistemas de computacao de alta-performance como os clusters e grids. Oproblema esta no fato do sistema apresentar uma arquitetura hierarquica, que naosatisfaz as necessidades da proposta da sessao 3. Porem, usa a mesma tecnologiapara a representacao dos dados, o XML.


• Job Monitoring Service [Ali et al. 2004]: fornece um sistema que monitora re-motamente os processos em execucao no ambiente de grades computacionais. Oobjetivo do sistema e saber se o processo foi realizado com exito ou para detectarproblemas que tenham ocorrido durante a execucao. A limitacao do Job Moni-toring Service esta no fato de monitorar apenas os processos, nao se preocupandocom o monitoramento dos recursos.

• Ludwig et al. [Ludwig et al. 2006] propoe uma arquitetura baseada em Web Ser-vices Distributed Management que fornece uma visao global e uniforme do usode infra-estruturas com middlewares heterogeneos, permitindo a especificacao depolıticas para coletar informacoes e a geracao de estatısticas sobre as aplicacoesque estao executando na grade. Este trabalho e o que mais assemelha-se a propostaapresentada, mas e direcionado a interligacao dos dados coletados dos diferentesmiddlewares.

3. Arquitetura PropostaApresentada a motivacao e analise dos requisitos necessarios para implementacao dogerenciador, surge a questao: como propor uma arquitetura que gerencie varios tiposde recursos (varios contextos) em um ambiente de grade computacional com redes desensores, dispositivos moveis e computadores convencionais?

3.1. Arquitetura

Um dos requisitos da arquitetura e ser ”leve”, tornando possıvel a instalacao do aplicativocliente em diversos dispositivos com limitacoes de hardware, como um sensor ou PDA,por exemplo. Visando alcancar este objetivo, o projeto apresenta quatro servicos distintos:

• Servico Coletor: utilizado por um elemento interessado em ser monitorado.• Servico Gerenciador: servico responsavel por gerenciar e gerar os alertas sobre

alguma alteracao na grade.• Servico Armazenador: responsavel por executar o servico de armazenamento. Os

dados enviados para ele por outros elementos devem ser armazenados em seubanco de dados.

• Servico Visualizador: este e o servico responsavel por gerar os relatorios ao ad-ministrador.

A arquitetura proposta na Figura 1 mostra a interacao dos servicos mencionados.Apesar da arquitetura mostrar um servico dentro de cada elemento, deve-se ressaltar quenada impede um elemento executar varios servicos ao mesmo tempo.

Para facilitar o entendimento da arquitetura proposta, as interacoes entre osservicos sao ilustradas atraves de setas enumeradas, cada uma formando passos distin-tos. Cada passo sera discutido abaixo:

1. Coleta dos Dados: neste passo, os nos da grade executam funcoes internas, querevelarao o estado do seu contexto de execucao. Apos cada execucao de metodo,os dados retornados sao repassados ao seu respectivo parser (cada comando temo seu parser especıfico).

2. Parsers: tem a funcao de filtrar os dados relevantes. Ao executar um comando,por exemplo, sao retornados dados relevantes e irrelevantes. Cabe ao parser filtrar


Elemento da Grade Elemento da Grade

Elemento da Grade Elemento da Grade

Usuário

Serviço Coletor Serviço Gerenciador

Serviço Armazenador

Serviço Visualizador

Serviços Diversos

Navegador

Coleta de Dados Políticas

Repositório

Applicação Web

Parser Criação de Alerta

Criação de XML

1 5

2

3

3

4

7

6

8

Figura 1. Arquitetura proposta

isso. Apos realizada a filtragem, os dados sao repassados ao modulo responsavelpela formatacao dos dados. Mais detalhes sobre a execucao dos comandos utiliza-dos para a coleta das informacoes serao dados em 3.2.

3. Formatacao dos dados em XML, e envio aos servicos Armazenador e Gerenci-ador: para que os dados tenham um formato padrao, os dados relevantes oriundosde todos os parsers de cada comando executado serao formatados em XML. Issofacilita tanto a compreensao dos dados, como tambem, a facil manipulacao no mo-mento do armazenamento ou na comparacao dos dados coletados com as polıticaspre-definidas.

4. Armazenamento pelo servico Armazenador: ocorre concomitantemente como proximo passo. Os arquivos XML, oriundos dos elementos da grade, sao ar-mazenadas no servico Armazenador de algum elemento que disponibilize esteservico. Esses dados, que chegam em intervalos periodicos, sao a base para aconstrucao do gerenciador, ja que estao disponıveis os dados dos no em variosperıodos de tempo.

5. Aplicacao das polıticas: Ao mesmo tempo, em que ocorre o armazenamento dos


dados em algum no que execute o servico armazenador, os dados no formato XMLoriundos dos nos da grade sao comparados com as regras do banco de polıticas.Se alguma regra, por algum motivo, e violada, e gerado um alerta.

6. Solicitacao do relatorio: O administrador interessado em observar o andamentoda grade, faz uma requisicao atraves do seu navegador ao servico Visualizador.Esse servico executa uma aplicacao no servidor Web, que e responsavel por gerargraficos e relatorios.

7. Requisicao do servico Visualizador e retorno dos dados do servico Ar-mazenador: Para que o sistema possa gerar relatorios, os dados armazenados noservico Armazenador devem ser recuperados e enviados ao servico Visualizador,para que os relatorios sejam gerados.

8. Geracao e envio do relatorio: Com os dados necessarios para a geracao dosgraficos e relatorios, o servico Visualizador gera um arquivo HTML, que e envi-ado ao usuario. O HTML gerado sera visualizado atraves do browser do admin-istrador.

3.2. Metodos de Coleta dos Dados

Os sensores irao utilizar basicamente dois metodos de coleta: os scripts escritos em Vir-tual Basic Script para ambientes Windows e a execucao de linhas de comandos para todosos ambientes.

3.2.1. Execucao de Linhas de Comando

Os coletores de linha de comando extraem as informacoes de gerenciamento atraves daexecucao de utilitarios de linha de comando disponıveis nos diversos sistemas opera-cionais onde podem ser executados.

No ambiente UNIX, os utilitarios de linha de comando podem consistir de co-mandos como netstat, top, df, free, ifconfig, dentre outros. A execucao desses comandosretorna um resultado do qual as informacoes relevantes devem ser extraıdas. A execucaode comandos retorna um fluxo de bytes do qual sao extraıdos os dados relevantes, atravesdos parsers.

Esses coletores fornecem as funcionalidades necessarias para a construcao deagentes de coleta com a flexibilidade e as caracterısticas requeridas por uma aplicacaode gerenciamento de sistemas [Assuncao 2004].

3.2.2. Coletores WMI

Os coletores Windows Management Instrumentation (WMI) sao extensoes dos agentescoletores de linha de comando. Estes coletores extraem dados necessarios as atividades degerenciamento usando o pacote de instrumentacao WMI proporcionado pela plataformaMicrosoft Windows [MICROSOFT 2003].

Para isso estes coletores executam scripts, desenvolvidos em Visual Basic Script,que sao responsaveis por interagir com o gerenciador de objetos do WMI e por recuperarestes dados. Quando passados como parametros de utilitarios existentes para a execucao


destes scripts, eles apresentam o resultado na console do sistema operacional, como sefosse executado um comando do sistema [Assuncao 2004].

Esses resultados sao usados pelos sensores que realizam o mesmo processo queum coletor de linha de comando para extrair estas informacoes. Em seguida o coletorefetua a extracao das informacoes relevantes do resultado da mesma forma que e feitocom os agentes de linha de comando.

As regras para funcionamento dos coletores WMI sao semelhantes as usadas peloscoletores de linha de comando. Neste trabalho foram desenvolvidos scripts para a coletade informacoes de configuracao e desempenho a respeito de processadores, memoria,perifericos e outros.

3.3. Monitoramento do ContextoContexto e uma das palavras chaves deste trabalho. A grade de computadores e vista demaneira homogenea, porem nao e homogeneo o modo de coletar os dados dos dispositivosque compoem a grade. Cada dispositivo apresenta maneiras diferentes de acesso aos seusdados de gerenciamento.

Para que ocorra o gerenciamento da grade e fundamental que o elemento tenhaum sensor acoplado na sua interface, para que ele possa saber com que periodicidade equais dados devem ser coletados. Esse sensor e oferecido pelo middleware sobre o qual ogerenciador executa. Se esse sensor coletar os mesmos dados tanto de um middleware Acomo de um B e eles forem formatados em um padrao como o XML, entao subentende-se que a arquitetura proposta neste trabalho pode gerenciar sistemas heterogeneos, atequando, eles possuem middleware diferentes.

Para coletar os dados, o sistema trabalha com regras de operacao, que executamsob o ambiente realizando atos basicos, tais como coleta de dados atraves de linhas decomando, execucao de scripts, etc. Os dados obtidos sao representados em uma estruturapadrao, o XML, que facilita a manipulacao dos dados.

4. Resultados Obtidos

4.1. Ambiente de Teste

A ferramenta de gerenciamento foi implementada usando o Grid-M [Franke et al. 2007]do LRG (Laboratorio de Redes e Gerencia). Grid-M e um middleware para grades com-putacionais compostas de dispositivos moveis. Esse middleware tem sido aplicado comsucesso em aplicacoes voltadas a telemedicina. O Grid-M trabalha como uma bibliotecaintegrada em uma aplicacao Java e prove uma Application Programming Interface (API)para criacao dos elementos da grade.

Na fase em que encontra-se o projeto, todos os servicos estao implementados: oservico Armanezador esta salvando os dados dos nos em diferentes momentos; o servicoVisualizador mostra os varios nos da grade atraves de uma interface amigavel; o servicoGerenciador gera alertas (traps), quando ocorre alguma violacao das regras de gerencia-mento pre-definidas; o servico Coletor coleta dados referentes aos (i) dados de hardwarecomo CPU, memoria, sistema operacional e disco, (ii) dados dos servicos em execucaocomo carga e tempo de execucao, e (iii) dados de comunicacao como volume de dadostransmitidos e tempo de transmissao.


A fim de tornar o ambiente de teste o mais heterogeneo possıvel, procurou-secolocar maquinas de diferentes sistemas operacionais e arquiteturas. A maquina Laptopexecuta Windows Vista, enquanto a Blue tem como sistema operacional Microsoft Win-dows XP. A Sirius roda Kurumin Linux 6.0, enquanto a Thor, uma Spark Sun, executaSolaris 10.

4.2. Interface do Gerenciador

Figura 2. Lista dos nodos registrados

Com a lista de todos os elementos registrados (figura 2), ou seja, tanto os que estaoonline como os offline, o usuario pode escolher qual elemento detalhar.

Serao mostrados varias informacoes do no Laptop, como descricao do computador(figura 3), detalhes da CPU (figura 4), memoria (figura 5), particoes (figura 6) , e quanti-dade de dados transmitidos e recebidos pela rede (figura 7). Outros exemplos, sao a figura8, que mostra o monitoramento de um servico oferecido pela grade e a figura 9 mostrao disparo de uma notificacao de alerta, que e exibida tanto na tela do no administradorcomo na tela do no detentor do servico.

5. Conclusao e Trabalhos Futuros

Neste trabalho foi proposta uma arquitetura para gerenciamento de grades computacionaiscapaz de adaptar-se ao contexto em que esta inserida. Os resultados obtidos demonstramo funcionamento da arquitetura proposta. As aplicacoes que necessitam dos dados cole-tados pelo Grid Manager para tomar decisoes, podem, se desejarem, utiliza-los.

Com esta arquitetura, consegue-se suprir as necessidades dos utility data centre ougrades multi-proposito, que oferecem isolamento de ambientes, e executam os servicose aplicacoes necessarias nos ambientes de aplicacao. As grades multi-propositos neces-sitam de informacoes de gerenciamento concisas, com pouca intervencao humana, quereflitam o estado dos recursos, pois os clientes pagam pelos recursos e aplicativos utiliza-dos. Assim, esses cenarios devem confiar em ferramentas de gerenciamento que possamser configuraveis para gerenciar varios tipos de recursos, servicos e aplicacoes. O GridManager foi projetado, exatamente, para garantir estas caracterısticas.


Figura 3. Descricao do elemento Laptop.

Figura 4. Descricao do processador do elemento Laptop.

Figura 5. Quantidade de memoria livre do elemento Laptop.

Figura 6. Tamanhos totais das particoes do elemento Laptop.


Figura 7. Quantidade de dados enviados e recebidos pelo elemento Laptop.

Figura 8. Monitoramento de um servico oferecido pelo Grid-M.

Figura 9. Alerta de falta de memoria no elemento Laptop exibida tanto no nodetentor do servico como na tela do administrador.


Como trabalho futuro, visa-se o aprimoramento do Grid Manager, a fimde torna-lo a base de um gerenciador com caracterısticas auto-gerenciaveis. Se-gundo [Kephart and Chess 2003], a computacao autonoma melhora o gerenciamentodos complexos sistemas de TI introduzindo o paradigma do auto-gerenciamento (self-management) para a configuracao, otimizacao, protecao e recuperacao. Acreditamosque com algumas alteracoes, o gerenciador proposto possa ser a base de um novo pro-jeto, a modelagem de uma arquitetura autonoma para gerenciamento de ambientes decomputacao em grades.

Referencias

Ali, A., Anjum, A., Bunn, J., Cavanaugh, R., van Lingen, F., McClatchey, R., Newman,H., ur Rehman, W., Steenberg, C., Thomas, M., and Willers, I. (2004). Job monitoringin an interactive grid analysis environment. Computing in High Energy Physics 2004.

Assuncao, M. D. (2004). Implementacao e analise de uma arquitetura de grids de agentespara a gerencia de redes e sistemas. Master’s thesis, Universidade Federal de SantaCatarina.

Assuncao, M. D. D. and Buyya, R. (2006). Intergrid: A case for internetworking ofislands of grids. Technical report.

Catlett, C., Beckman, P., Skow, D., and Foster, I. (2006). Creating and operating national-scale cyberinfrastructure services. CTWatch Quarterly, 2(2):2–10.

Foster, I., Kesselman, C., and Tuecke, S. (2001). The anatomy of the Grid: Enablingscalable virtual organizations. Lecture Notes in Computer Science, 2150.

Franke, H. A., Rolim, C., Westphall, C. B., Koch, F., and Balen, D. O. (2007). Grid-m: Middleware to integrate mobile devices, sensors and grid computing. The ThirdInternational Conference on Wireless and Mobile Comunications - ICWMC.

Gunter, D., Tierney, B., Crowley, B., Holding, M., and Lee, J. (2000). Netlogger: A toolkitfor distributed system performance analysis. Eighth IEEE International Symposiumon Modeling, Analysis, and Simulation of Computer and Telecommunications Systems(MASCOTS’00), page 267.

Kephart, J. O. and Chess, D. M. (2003). The vision of autonomic computing. Computer,36(1):41–50.

Ludwig, G. A., Gaspary, L. P., Cavalheiro, G. G. H., and Cirne, W. (2006). A wsdm-based architecture for global usage characterization of grid computing infrastructures.In DSOM, pages 124–135.

MICROSOFT (2003). Introduction to windows management instrumentation. Disponıvelem: http://www.microsoft.com/whdc/hwdev/driver/WMI/WMIintro.mspx. Acessado em24 de abril de 2008.

Newman, H. B., Legrand, I. C., Galvez, P., Voicu, R., and Cirstoiu, C. (2003). Monalisa :A distributed monitoring service architecture. CoRR, cs.DC/0306096.

RUS (2005). Resource Usage Service Working Group. Disponıvel em:http://www.doc.ic.ac.uk/sjn5/GGF/rus-wg.html. Acessado em 24 de abril de 2008.


Team, T. G. D. (2006). What is gaglia? Disponıvel em: http://ganglia.info/. Acessado em24 de abril de 2008.

Wilkes, J., Mogul, J., and Suermondt, J. (2004). Utilification. In 11th workshop on ACMSIGOPS European workshop, page 13, Leuven, Belgium. ACM Press.


Gerenciamento de redes em grades computacionais: uma ... · abordagem usando redes de sensores e...

Documents

Transcript of Gerenciamento de redes em grades computacionais: uma ... · abordagem usando redes de sensores e...