Slide 1

MAG
Mobile Agents for Grid
Computing Environments
Arquitetura Geral
Rafael Fernandes Lopes
[email protected]
Bysmarck Barros
[email protected]
Objetivos
• Desenvolver uma infra-estrutura de software
baseada na tecnologia de agentes móveis que
permita o desenvolvimento e execução de
aplicações computacionalmente intensivas em
uma grade de computadores
• Reaproveitar recursos ociosos presentes em
instituições de qualquer natureza
Introdução
• Arquitetura em Camadas
Aplicações
MAG
DataGrid
JADE
InteGrade
CORBA
Sistema Operacional
Execução de Aplicações
• Aplicações são executadas como threads
dos agentes
• MAG agora permite a execução de
aplicações paramétricas (Bag-of-Tasks)
Execução de Aplicações
= processo InteGrade
= agente MAG
GRM
Repositório
de Aplicações
2
9
10
6
3
7
1
LRM
LRM
ASCT
4
AH
LRM
5
LRM
AH
AH 4
Solaris
Windows
AH
8
Linux
Solaris
Linux
Liberação de nós da grade
• Nós são liberados quando o usuário
requisita o uso exclusivo da máquina
– Hoje isto é feito através de uma pequena
janela com um botão no canto superior
esquerdo
• O registro do LRM é primeiramente
removido do GRM, e só então os agentes
são migrados com suas aplicações para
outros nós
Liberação de nós da grade
= processo InteGrade
= agente MAG
GRM
2
1
4
LRM
3
LRM
5
AH
6
AH
SO
SO
Gerenciamento da Execução de
Aplicações
• Utiliza-se um banco de dados XML
(Xindice) para guardar informações a
respeito das aplicações submetidas para
execução na grade
Gerenciamento da Execução de
Aplicações
<application source="grid">
<!-- grid / web / mobile -->
<appExecutionId>10000</appExecutionId>
<applicationInfo>
<appReposId>10000</appReposId>
<binaryName>Fibonacci</binaryName>
<platformType>Java</platformType> <!-- Linux_i686 / Linux_x86_64 /
Macintosh / Java -->
</applicationInfo>
.
.
.
Gerenciamento da Execução de
Aplicações
<executionInfo>
<executionType>regular</executionType>
<!– regular / bsp / parametric -->
<userName>rafaelf</userName>
<executingHost>gauguin</executingHost>
<appArgs>50</appArgs>
<appMainRequestId>1</appMainRequestId>
<appNodeRequestId>0</appNodeRequestId>
<appConstraints>osName == 'Linux'</appConstraints>
<appPreferences>max(freeRAM)</appPreferences>
<executionState>running</executionState>
<!-- running / finished -->
<outputFiles>
<file>stdout</file>
<file>stderr</file>
<file>out.dat</file>
</outputFiles>
<inputFiles>
<file>in.dat</file>
</inputFiles>
<startTimestamp>99999999</startTimestamp>
<endTimestamp>99999999</endTimestamp>
</executionInfo>
</application>
CAV Cluster Application
Viewer
• Através do ClusterView é possível visualizar
informações sobre a disponibilidade de recursos
nos nós pertencentes à grade
• Entretanto, sentiu-se a necessidade de permitir
que administradores da grade pudessem
visualizar também as aplicações neles
executam
• Através do CAV (Cluster Application Viewer) é
possível recuperar várias informações
adicionais a respeito dos nós da grade e das
aplicações que nele executam
CAV Cluster Application
Viewer
Avaliação de Desempenho
Objetivos
•
•
Avaliar o desempenho do MAG em relação
a outras plataformas de grade (OurGrid,
Globus, etc.)
Medir a eficácia do MAG na execução de
aplicações regulares e paramétricas
Avaliação de Desempenho
Testes Previstos
1. Medição do tempo de execução de aplicações regulares
– Será medido o overhead gerado pela execução de aplicações
regulares através do MAG e outras plataformas de grades como
o Globus, OurGrid, etc.
2. Medição do tempo de execução de aplicações
paramétricas
– Será avaliado o tempo total de computação de aplicações
paramétricas à medida que aumentamos a quantidade de nós
da grade envolvidos com a computação
3. Medição do impacto dos mecanismos ligados à
tolerância a falhas e à migração forte para aplicações
regulares e paramétricas
– Neste teste é comparado o tempo de execução total de
aplicações regulares e paramétricas não instrumentadas,
instrumentadas (porém sem a captura periódica do checkpoint)
e com a captura periódica do checkpoint das aplicações
Avaliação de Desempenho
Testes Previstos
4. Medição do tempo total de captura e
recuperação do estado de aplicações
•
•
Serão medidos os tempos de captura e recuperação
do estado de execução de aplicações
instrumentadas com o MAG/Brakes
Estes resultados serão comparados com os de
outros frameworks de salva de estado (BrakesSerial, Brakes-paralelo, JavaGo, etc.)
5. Medição do tempo gasto por uma aplicação
para efetuar o processo de migração completo
•
Será medido que uma aplicação leva desde a
solicitação de migração, até a sua completa
restauração
Avaliação de Desempenho
• Além dos testes que estão sendo
realizados no MAG, foi feita a avaliação
do impacto da presença do AgentHandler
nos nós da grade
• Para tanto foi utilizada uma metodologia
semelhante à utilizada na dissertação de
mestrado de Jeferson Roberto Marques
Avaliação de Desempenho
• O experimento consistiu na submissão de
800 solicitações de execução, capturando
o percentual de uso do processador pelo
AgentHandler a cada 10 segundos
• Isto gerou uma amostra de algo em torno
de 2500 observações
• O algoritmo utilizado no teste foi um
algoritmo de Fibonacci sem recursividade
com entrada 45
Avaliação de Desempenho
Trabalhos Futuros
• Personalização da plataforma JADE
• Instanciação dos componentes do MAG
sob-demanda
• Mecanismo de balanceamento de carga
para melhor aproveitar o mecanismo de
migração
• Suporte a aplicações paralelas MPI
Migração Forte
Rafael Fernandes Lopes
[email protected]
Objetivo
• Permitir que o estado de execução de
uma aplicação possa ser salvo, permitindo
o seu posterior reinício a partir de um
dado ponto de sua execução
(possivelmente em uma outra localidade)
Migração Forte
• Migração forte das aplicações no MAG,
baseia-se em uma versão modificada do
framework Brakes, chamada MAG/Brakes
• O MAG/Brakes fundamenta-se na
instrumentação do bytecode de aplicações
Java
Migração Forte
• O MAG/Brakes permite a salva do estado de execução de threads
Java. Isto é aproveitado pelo mecanismo de tolerância a falhas do
MAG para recuperar aplicações (checkpoint)
• Hoje o MAG/Brakes conta com duas formas de instrumentação:
– Automática: os blocos de código responsáveis por salvar o estado de
execução da aplicação são automaticamente inseridos após cada
invocação de método
• Além disso, o usuário pode especificar posições de código adicionais onde
ele queira permitir que o estado seja salvo. Isto é feito através do método
mayCheckpoint();
– Manual: O estado de execução da aplicação SOMENTE pode ser salvo
nas posições de código indicadas pelo usuário através do método
mayCheckpoint();
Avaliação de Desempenho
• Foi avaliado o impacto da instrumentação no
tempo total de execução de aplicações Java
• Para o teste foi utilizada uma máquina AMD
Sempron 2200+, com overclock para 1.8 GHz,
com 256 MB de memória RAM e rodando Linux
2.6.10
• O experimento foi feito utilizando-se a API Java
do Borland OptimizeIt para capturar o tempo de
duração da execução da aplicação
• O algoritmo utilizado no teste foi um algoritmo
de Fibonacci recursivo com entradas 20, 25, 30
e 35 por este ser considerado um “pior caso”
Avaliação de Desempenho
Trabalhos Futuros
• Avaliação de desempenho do mecanismo de migração
utilizando-se mais aplicações de referência
• Avaliação de desempenho comparativa com outros
frameworks de migração:
– overhead de execução
– tempo de restauração e de captura do estado de aplicações
• Migração de aplicações multi-threading
• Migração de recursos
– Ao migrar, manter o ambiente de execução das aplicações
• Migração Inter-clusters
– O uso de padrões Web para isto (transmissão HTTP)
• O estado de execução das aplicações passará a ser representado
em um formato XML
Tolerância a falhas
Rafael Fernandes Lopes
[email protected]
Stanley Araújo
[email protected]
Objetivos
• Nós da grade são instáveis, pois não se
encontram em um ambiente controlado, a
exemplo dos clusters de computadores e
máquinas paralelas
• Deve-se evitar a perda de tempo computacional
• Falhas devem ser transparentes aos usuários
– No MAG a abordagem de checkpointing é adotada
Tolerância a Falhas
= processo InteGrade
= agente MAG
GRM
7
AR
6
5
Nó B
3
LRM
AH
8
10
SO
9
Mapeador de
Agentes
1
Armazém
Estável
2
Repositório
de Aplicações
4
LRM
AH
Nó A
SO
Trabalhos Futuros
• Implementação de um componente que efetue o
gerenciamento completo (e individual) de
aplicações que executam na grade
– Este componente deve poder identificar a presença
de falhas e a causa das falhas
• Abordagens adaptativas
– Adaptação do número de réplicas de checkpoints,
estratégia de atualização destas réplicas, algoritmo
de detecção de falhas e etc.