DIMVisual: Um modelo de integração visual de dados
Lucas Mello Schnorr
∗, Philippe O. A. Navaux
Universidade Federal do Rio Grande do Sul
Instituto de Informática
Avenida Bento Gonçalves, 9500, Porto Alegre
{lmschnorr,navaux}@inf.ufrgs.br
Benhur de Oliveira Stein
Universidade Federal de Santa Maria
Curso de Ciência da Computação
Avenida Roraima, Camobi, Santa Maria
benhur@inf.ufsm.br
Resumo
A utilização de Cluster de computadores por administra-dores e desenvolveadministra-dores passa eventualmente pelo uso de diferentes ferramentas de monitoramento. Quando um de-senvolvedor está construindo sua aplicação, ele pode ne-cessitar da integração dos dados de rastreamento de sua aplicação com dados de monitoramento dos recursos do Cluster. No caso do administrador, podem existir situações em que mais de uma ferramenta de monitoramento de re-cursos seja necessária para uma melhor observação do comportamento do Cluster. Nessas duas situações, verifica-se a utilização de diferentes ferramentas de monitoramento. Na maioria das vezes, os dados coletados por essas ferra-mentas não são integrados e visualizados conjuntamente. Este trabalho descreve o modelo DIMVisual, que tem como objetivo integrar dados coletados por ferramentas de moni-toramento diferentes. Um protótipo e resultados são tam-bém apresentados.
1. Introdução
A utilização de Cluster de computadores tem aumen-tado ao longo das últimas décadas e representa hoje cerca de 60% das máquinas listadas entre as 500 mais rápidas do mundo [5]. Isso se justifica principalmente pela escalabili-dade deste tipo de arquitetura e o custo baixo de seus com-ponentes, normalmente computadores pessoais comuns.
O uso de Cluster para se atingir alto desempenho faz com que desenvolvedores de aplicações paralelas usem bi-bliotecas de passagem de mensagem e diferentes fluxos de execução. Nesse processo de desenvolvimento, os progra-madores utilizam bibliotecas de rastreamento para realiza-rem otimizações e a correção de seus programas. Mesmo que esses programadores consigam obter dados do compor-tamento de suas aplicações de forma coerente, as justifica-tivas para determinado comportamento podem não estar na aplicação em si, mas no ambiente onde essa aplicação é exe-cutada [6]. Esse ambiente normalmente é composto pela
ca-pacidade da rede de interconexão entre os diferentes nós de um Cluster, utilização de processamento em cada nó e tam-bém nas trocas de contexto de cada sistema operacional en-volvido, por exemplo. Nessas situações, programadores fa-zem uso de diferentes ferramentas de monitoramento de re-cursos para Cluster juntamente com as bibliotecas de ras-treamento de suas aplicações.
No caso do monitoramento do Cluster, administradores fazem uso das mesmas ferramentas de monitoramento utili-zadas por desenvolvedores de aplicações paralelas, mas sem ter a intenção de correlacionar esses dados com uma aplica-ção. Durante a utilização de uma ferramenta de monitora-mento, é possível que ela não consiga coletar todas as in-formações que o administrador precisa para realizar a aná-lise do monitoramento de um Cluster. Por exemplo, caso o administrador precise ter informações do sistema como um todo e também dados internos de cada sistema operaci-onal ele se verá obrigado a utilizar, por exemplo, o Ganglia [8] para ter a visão mais geral, e alguma instrumentação do sistema operacional para ter dados específicos dele. O pro-blema de utilizar essas abordagens é que a análise dos da-dos é feita de forma independente, fazendo com que seja mais complexo o relacionamento entre as informações co-letadas por cada uma das ferramentas utilizadas.
Tanto no desenvolvimento de aplicações parale-las quanto na administração de um Cluster, verifica-se que diferentes ferramentas de monitoramento e bibliote-cas de rastreamento podem ser utilizadas para realizar a coleta de dados. Considerando que a maioria dessas ferra-mentas utilizam formas de análise independente, ou através da apresentação gráfica dos dados ou textual, surge a ne-cessidade de se realizar uma visualização conjunta dessas informações.
Este texto apresenta o modelo DIMVisual, que tem como objetivo integrar dados coletados por diferentes fon-tes de informação, sendo que uma fonte de informação pode ser uma ferramenta de monitoramento de recursos ou uma biblioteca de rastreamento de aplicações paralelas. É apre-sentado também um protótipo baseado neste modelo, que
utiliza como fontes de informação o rastreamento de aplica-ções DECK [1] e MPI [12], ferramentas de monitoramento Ganglia [8] e Performance Co-Pilot [9] e uma instrumenta-ção do sistema operacional Linux. Pajé [11]é a ferramenta de visualização que será utilizada neste trabalho.
Este texto está organizado da seguinte forma. A seção 2 apresenta o modelo de integração visual de dados. A seção 3 apresenta o protótipo construído e na seção 4 os resulta-dos através da ferramenta de visualização Pajé são mostra-dos. No fim, são apresentadas as conclusões e sugestões de trabalhos futuros.
2. Modelo DIMVisual
O modelo de integração visual dos dados - DIMVisual - tem como objetivo realizar a integração de dados coleta-dos por diferentes fontes de informação. É importante dei-xar claro que o modelo não tenta integrar as ferramentas de coleta de dados, mas sim os dados que foram coletados por elas. Nesta seção serão apresentados os principais compo-nentes do modelo e também questões de intrusividade, es-pecialmente importantes para a depuração de aplicações pa-ralelas.
A figura 1 apresenta o modelo de integração visual de dados. Como pode ser observado, o modelo é dividido em duas fases: a fase da coleta, onde as informações de monito-ramento são obtidas por fontes de informação já existentes; e a fase de integração, onde as informações coletadas são integradas de forma que possam ser visualizadas conjunta-mente. A utilização deste modelo é muito parecida com sis-temas de depuração offline de aplicações paralelas, já que os dados só poderão ser analisados após o período de moni-toramento. Integração A Fonte de dados Fonte de dados B
Fase de Coleta Fase de Integração
Figura 1. Modelo de integração visual de da-dos dividido em duas fases: coleta e integra-ção
2.1. Fase de Coleta
A fase da coleta consiste no registro de um conjunto de informações durante o período de monitoramento. Diferen-tes fonDiferen-tes de dados podem ser utilizadas nesta fase, desde que o resultado dessas fontes de dados sejam arquivos onde estão registradas as informações monitoradas. Além disso, é importante que os dados desses arquivos estejam discreti-zados em eventos com tipo, ou seja, eventos que possam ser identificados individualmente e contenham dados exceden-tes de acordo com o tipo. Deve-se ter uma forma de ler as informações desses arquivos, de forma que na fase de inte-gração os dados registrados possam ser obtidos.
2.2. Fase de Integração
A segunda fase, de integração, tem como objetivo jun-tar os dados das diferentes fontes de informação de forma que seja obtido um único conjunto de dados que possa ser analisado visualmente através de alguma ferramenta de vi-sualização. A figura 2 mostra os componentes da segunda fase do modelo de integração de dados: sincronização, uni-ficação e padronização.
Sincronização Unificação Padronização
Integração dos dados
Figura 2. Componentes da segunda fase do modelo de integração visual de dados: sin-cronização, unificação e padronização
O componente de sincronização é de vital importância, pois através da sincronização dos dados poderá se manter a relação causal e temporal entre eventos registrados por di-ferentes fontes de informação. Adicionalmente, a sincroni-zação faz com que haja uma única referência temporal nos dados, já que podem existir ferramentas que trabalhem com uma escala de tempo diferente de outra ferramenta. Como no modelo pretende se utilizar ferramentas de monitora-mento já existentes, é interessante que a forma de sincroni-zação dos eventos seja tal que não altere as ferramentas. A técnica proposta por Maillet e Tron [4] aborda uma forma de sincronização que pode ser feita após a coleta dos da-dos. Esta técnica consiste em registrar antes e depois do pe-ríodo de monitoramento as diferenças de relógio entre uma máquina de referência e as máquinas onde foram gerados eventos que devem ser sincronizados. Com essas informa-ções, a técnica cria uma regressão linear e aplica a data de
cada evento nessa função linear. A técnica é usada para cor-rigir a defasagem dos relógios das máquinas de um Cluster e se aplica melhor para períodos de monitoramento peque-nos, já que a defasagem dos relógios pode ser em alguns ca-sos não linear.
O segundo componente é a unificação hierárquica das informações. Essa unificação deve ser levada em conta, pois é através dela que as informações poderão ser agrupadas, por exemplo, por nós do Cluster. Dessa forma, todos os dados que estiverem relacionados com um determinado nó serão analisados conjuntamente. Na unificação hierárquica tem-se a noção de objetos monitorados. Um objeto moni-torado pode ser um processo, um fluxo de execução, uma informação de utilização de CPU, rede ou memória e tam-bém um estado que pode estar um determinado processo em um determinado instante de tempo. Cada fonte de infor-mação utilizada normalmente tem atrelado a si uma hierar-quia de objetos monitorados. A unificação hierárquica con-siste inicialmente em identificar objetos monitorados seme-lhantes nas hierarquias das múltiplas fontes de informação e posteriormente realizar a unificação de identificadores. A fi-gura 3 mostra o processo de unificação hierárquica. Os ob-jetos Máquina e Cluster serão unificados, pois foram consi-derados semelhantes entre as duas hierarquias. O próximo passo é unificar os identificadores utilizados para esses ob-jetos monitorados. Isso pode ser feito através de uma con-versão de um tipo de identificador para outro.
1 n 1 n 1 n Cluster Cluster 1 n Fonte de Dados A Fonte de Dados B Máquina Máquina Métricas Processo Executando Bloqueado
Figura 3. Exemplo de unificação hierárquica feita para duas fontes de dados: objetos mo-nitorados Máquina e Cluster serão unifica-dos
O terceiro componente é a padronização das informa-ções. Esta etapa está relacionada com a ferramenta de vi-sualização escolhida para se visualizar as informações. A
etapa deve levar em conta quais foram os eventos registra-dos pelas diferentes fontes de informação, qual a capacidade da ferramenta de visualização escolhida e como as informa-ções devem ser visualizadas de forma conjunta. Para reali-zar este processo, pode-se realireali-zar um mapeamento dos ti-pos de eventos das diversas fontes de informação para even-tos que consigam descrever a visualização desejada na fer-ramenta de visualização.
Intrusividade
A questão da intrusão de sistemas de monitoramento é especialmente importante principalmente na depuração de aplicações paralelas. Qualquer sistema monitorador que é usado de uma forma ou de outra acaba alterando o compor-tamento normal da execução de uma aplicação. Nessas si-tuações, é importante que o sistema de monitoramento seja o menor intrusivo possível. No modelo de integração visual descrito neste texto, a realização da coleta de dados é feita por ferramentas de monitoramento e bibliotecas de rastrea-mento já existentes. A segunta etapa de integração dos da-dos não influencia a aplicação pois é feito após o fim de sua execução. Dessa forma, fica a cargo de quem utiliza as ferra-mentas de coleta escolher aquelas que causam menor intru-são. Em algumas situações, as informações externas à apli-cação são necessárias de forma que um nível maior de in-trusão seja até aceitável.
3. Implementação
Esta seção apresenta a implementação do modelo
DIM-Visual. A figura 4 mostra os principais componentes da
im-plementação realizada. Como fontes de informação foram utilizadas rastros das bibliotecas de comunicação DECK e MPI, dos sistemas de monitoramento para Cluster Ganglia e Performance Co-Pilot e rastros de uma instrumentação sis-tema operacional Linux. A segunda fase do modelo foi im-plementada através de um protótipo que resolve para essas fontes de informação as questões levantadas no modelo, que são sincronização, unificação e normalização. Embora so-mente estas fontes de informação tenham sido utilizadas, o protótipo pode facilmente ser estendido de forma a integrar outros tipos de dados coletados por outras fontes de infor-mação.
Fontes de Informação
O DECK é basicamente uma biblioteca de comunicações para aplicações paralelas. Foi feita uma instrumentação no código da biblioteca de forma que fosse possível o rastre-amento de aplicações DECK. Essa instrumentação regis-tra para cada processo um arquivo com os principais even-tos que acontecerão durante o período de monitoramento. No caso de aplicações MPI, já existe uma forma de rastrear através da utilização da biblioteca MPE [3]. Essa biblioteca gera um único arquivo com os eventos registrados em todos
os processos da aplicação. As fontes de informação Gan-glia e Performance Co-Pilot foram utilizadas para obter da-dos do Cluster como um todo. No caso do sistema operaci-onal, foi feita uma instrumentação que registre quando um processo entrará em execução e quando este é bloqueado.
Operacional Sistema Performance Co−Pilot Ganglia MPI DECK Protótipo Dados Finais
Fonte de dados Integração dos dados
Figura 4. Fontes de informação utilizadas e o protótipo de integração de dados baseado no modelo DIMVisual
Protótipo de Integração
O protótipo construído é dividido em três tipos de com-ponentes: fonte de dados, ordenador e integrador. Existe um componente do tipo fonte de dado para cada fonte de infor-mação utilizada na fase da coleta. Esses componentes sa-bem o formato específico do arquivo com os eventos e guar-dam dentro de si o mapeamento de eventos para a ferra-menta de visualização Pajé através de um conversor. Além disso, esses componentes realizam a sincronização de cada evento seguindo a técnica proposta por Maillet e Tron [4].
O outro componente do protótipo é o ordenador dos eventos de acordo com o tempo. Esse componente gerencia diversos componentes fontes de dados. Como cada fonte de dados tem a mesma interface, o ordenador de eventos nunca sabe a semântica dos eventos que deve ordenar.
O terceiro componente, integrador, interage dinamica-mente durante o processo de integração de dados com os diferentes componentes fonte de dados com o objetivo de realizar a unificação hierárquica e a geração de identifica-dores comuns para todas as fontes de dados. É ele quem registra os dados em arquivo para ser visualizado na ferra-menta Pajé.
A figura 5 mostra um esquema da visualização integrada que se deseja obter utilizando o protótipo. Esse esquema foi construído levando em conta a parte de normalização dos dados do modelo DIMVisual, onde o mapeamento de
eventos das fontes de dados para a ferramenta de visuali-zação deve levar em conta os eventos registrados, a capaci-dade da ferramenta de visualização e como se deseja visua-lizar as informações. Nó 0 Nó 1
Figura 5. Esquema da visualização integrada que se deseja obter com o protótipo
Ainda na figura 5, as informações coletadas em diferen-tes nós são agrupadas pelo nome do nó. Dados quantitati-vos são apresentados através de gráficos e informações de determinada aplicação são mostradas por dois retângulos: o de cima indica estados do nível da aplicação DECK e MPI e o de baixo indica estados coletados no sistema operacio-nal. As flechas indicam a comunicação entre dois proces-sos.
4. Resultados
Esta seção apresenta os resultados obtidos com o pro-tótipo de integração desenvolvido e criado a partir do mo-delo DIMVisual. As fontes de informação descritas na se-ção anterior foram utilizadas em um Cluster de 10 nós do Laboratório de Sistemas de Computação1. As figuras apre-sentadas nesta seção são telas da ferramenta de visualização Pajé mostrando dados que foram integrados através do pro-tótipo.
A figura 6 mostra o resultado no Pajé da integração de dados coletados pelas ferramentas de monitoramento Gan-glia e PCP com dados de uma aplicação DECK. As flechas entre os dois retângulos indicam a comunicação entre os processos e as diferentes cores de cada um dos retângulos
indicam estados diferentes de determinado processo. As in-formações
BYTES_IN
,BYTES_OUT
eCPU_USER
foram co-letadas pelo Ganglia, as demais pelo Performance Co-Pilot. Essa visualização pode permitir ao desenvolvedor realizar uma melhor análise do comportamento da aplicação, já que se tem informação do ambiente de execução.M a ch in e p a p le 0 2 DECKState BYTES_IN sockstat-tcp-inuse CPU_USER BYTES_OUT all-load-1minute p a p le 0 3 DECKState BYTES_IN sockstat-tcp-inuse CPU_USER BYTES_OUT all-load-1minute 1106148864 1106148864 1106148864
Figura 6. Visualização integrada com dados oriundos das ferramentas de monitoramento Ganglia e PCP com dados rastreados por uma aplicação DECK
A figura 7 mostra a visualização em Pajé de dados co-letados durante a execução de uma mesma aplicação
ping-pong em MPI por duas vezes com quantidades diferentes de
comunicações. Nesta figura, é apresentado adicionalmente o estado de cada processo no nível do sistema operacional, juntamente com dados das ferramentas Ganglia e PCP. A vi-sualização de diferentes execuções pode permitir uma com-paração visual através da observação dos tempos de comu-nicação de uma aplicação.
A figura 8 tem como objetivo mostrar a utilização do modelo DIMVisual no que tange a administração de
Clus-ter. Nesta figura, têm-se dados coletados pelo Ganglia
vi-sualizados de forma integrada com informações coletadas pelo Performance Co-Pilot e que não eram acessíveis atra-vés do Ganglia. Essa visualização mostra que o administra-dor pode utilizar mais de uma ferramenta de monitoramento de recursos e ainda assim obter uma análise conjunta e in-tegrada com os dados sincronizados, unificados e padroni-zados para a visualização. Isso é possível através da imple-mentação do modelo apresentado neste trabalho. Caso não fosse utilizada essa abordagem, o administrador teria que utilizar ferramentas de análise e visualização independen-tes, tendo que enfrentar as dificuldades que motivaram este trabalho.
Os resultados desta seção mostram que o modelo pro-posto neste texto pode ser analisado tanto na área de depu-ração de aplicações paralelas quanto na área de
monitora-M a ch in e p a p le 0 2 tcpconn-establishe d sockstat-tcp-inuse MPIState OSState MPIState OSState proc-nprocs CPU_USER p a p le 0 6 tcpconn-establishe d sockstat-tcp-inuse MPIState OSState MPIState OSState proc-nprocs CPU_USER 10 20 30 40 50 60 70 80 90 100 110
Figura 7. Visualização integrada com da-dos coletada-dos das ferramentas de monitora-mento Ganglia e PCP e o rastreamonitora-mento de uma aplicação MPI com dados do sistema operacional M a ch in e p a p le 0 2 all-load-15minute mem-freemem tcpconn-establishe d sockstat-tcp-inuse BYTES_OUT proc-nprocs CPU_USER BYTES_IN p a p le 0 6 all-load-15minute mem-freemem tcpconn-establishe d sockstat-tcp-inuse BYTES_OUT proc-nprocs CPU_USER BYTES_IN 0 50 100
Figura 8. Visualização integrada com dados complementares entre duas ferramentas de monitoramento: Ganglia e Performance Co-Pilot
mento de Cluster na área administrativa. Com este resul-tado, percebe-se que o diferencial do modelo está na inici-ativa de mostrar de forma integrada, simultânea e correlaci-ona dados coletados por um conjunto de ferramentas quais-quer, bastando que se atualize o protótipo baseado no mo-delo de forma a gerar a visualização integrada. Caso essa abordagem não fosse utilizada, o desenvolvedor ou admi-nistrador teriam que usar mais de uma ferramenta de visua-lização para analisar os dados, tornando em algumas situa-ções inviável o correlacionamento das informasitua-ções de dife-rentes ferramentas.
5. Trabalhos Relacionados
Existem alguns trabalhos relacionados com o modelo de integração visual proposto neste texto. Paraver [7] é uma ferramenta para depuração de aplicações paralelas. Ela foi desenvolvida na Universidade Técnica da Catalunha, na Es-panha, e está disponível apenas comercialmente. A dife-rença para o modelo deste trabalho é que ela utiliza mó-dulos específicos para coleta de informações e determina um formato de entrada específico para o módulo de integra-ção. Essa abordagem faz com que o desenvolvedor tenha que obrigatoriamente utilizar os módulos específicos cria-dos, além do fato de ter que lidar com mais um formato de arquivo para guardar as informações. Outra ferramenta, CoSMos [10] é um sistema integrado de monitoramento de aplicações paralelas. Foi desenvolvido na Universidade de Koblenz-Landau, na Alemanha. A diferença em relação ao modelo deste trabalho é que ele se limita a três fontes de in-formação, tendo uma aplicação aparentemente não exten-sível que integra os dados dessas fontes de dados. O pro-blema da abordagem nesse trabalho é que o desenvolvedor fica atrelado às ferramentas criadas, ou seja, à forma de ins-trumentação no nível da aplicação e à utilização do rastre-amento do nível de sistema operacional específico. Clane [2] é um ambiente de análise de desempenho desenvolvido no CPAD da Universidade Católica do Rio Grande do Sul. O Clane funciona através da centralização dos dados em um servidor de informação que realiza a integração dos da-dos. Aparentemente, nessa abordagem é necessária a alte-ração das ferramentas de coleta de dados já existentes, de forma que possam enviar dados de monitoramento ao servi-dor de informação.
6. Conclusão
Este trabalho apresentou o modelo DIMVIsual2 e um protótipo baseado neste modelo. A motivação principal deste trabalho é que em algumas situações desenvolvedo-res e administradodesenvolvedo-res precisam de mais de uma fonte de da-dos para analisar e identificar de forma mais direta os blemas. No caso do desenvolvimento de aplicações, o pro-gramador pode necessitar de dados externos a sua aplicação para entender melhor seu comportamento. Na parte admi-nistrativa, o administrador pode precisar analisar conjunta-mente dados coletados por diferentes ferramentas de moni-toramento.
O diferencial do modelo e protótipo apresentado neste texto é que eles não estão atrelados a um conjunto de fer-ramentas para realizar a integração dos dados. O protótipo construído pode ser facilmente estendido caso seja necessá-rio utilizar alguma outra ferramenta de monitoramento ou
2 http://www.inf.ufrgs.br/~lmschnorr/dimvisual/
formato de rastro de aplicação diferente. Foi visto através dos resultados que a visualização integrada traz os benefí-cios que resolvem os problemas apresentados na motivação do trabalho.
Referências
[1] M. Barreto, M. Riviere, and P. Navaux. Deck: a new mo-del for a distributed executive kernel integrating communi-cation and multithreading for support of distributed object oriented application with fault tolerance support. In
Traba-jos Seleccionados do Congreso Argentino de Ciencias de la Computacion, 4, volume 2, pages 623–637, Neuquém,
Ar-gentina, 1998.
[2] T. Ferreto and C. de Rose. Improving performance analysis using resource management information. In V. K. P. Timothy Mark Pinkston, editor, Proceedings of the International
Con-ference on High Performance Computing, pages 449–458,
Hyderabad, India, 2003. Heidelberg: Springer-Verlag. [3] W. Gropp, E. Lusk, N. Doss, and A. Skjellum.
High-performance, portable implementation of the MPI Message Passing Interface Standard. Parallel Computing, 22(6):789– 828, Sept. 1996.
[4] E. Maillet and C. Tron. On efficiently implementing global time for performance evaluation on multiprocessor systems.
Parallel Distributed Computing, 28(1):84–93, 1995.
[5] H. Meuer, E. Strohmaier, J. Dongarra, and H. D. Simon. Top500 supercomputer. Disponível em: <http://www.top500.org>. Acesso em: 25/01/2005, Nov. 2004. 24. ed. 2004.
[6] F.-G. Ottogalli, C. LabbÉ, V. Olive, B. Stein, J. C. de Ker-gommeaux, and J.-M. Vincent. Visualisation of distributed applications for performance debugging. In Proceedings of
the International Conference on Computational Science-Part II, ICCS, pages 831–840. [S.l.]: Springer-Verlag, 2001.
[7] V. Pillet, J. Labarta, T. Cortes, and S. Girona. PARAVER: A tool to visualise and analyze parallel code. In
Procee-dings of Transputer and occam Developments, WOTUG-18,
volume 44 of Transputer and Occam Engineering, pages 17– 31, Amsterdam, 1995. [S.l.]: IOS Press.
[8] F. D. Sacerdoti, M. L. Massie, and D. E. Culler. Wide area cluster monitoring with ganglia. In Proceedings of Cluster
Computing, pages 289–298, Hong Kong, December 2003.
[S.l.]: IEEE Press.
[9] SGI. Performance co-pilot users and administrators guide. [s.l.]. http://oss.sgi.com/projects/pcp/, 1999.
[10] C. Steigner and J. Wilke. Performance tuning of distributed applications with CoSMoS. In Proceedings of the 21st
In-ternational Conference on Distributed Computing Systems, ICDCS, pages 173–180, Los Alamitos, CA, 2001. Los
Ala-mitos: IEEE Computer Society.
[11] B. Stein, J. C. de Kergommeaux, and P.-E. Bernard. Pajé, an interactive visualization tool for tuning multi-threaded paral-lel applications. Paralparal-lel Computing, 26:1253–1274, 2000. [12] D. W. Walker and J. J. Dongarra. MPI: a standard Message
