MonarcFramework para

SimulaçõesDisciplina:

Programação Distribuída e ParalelaAlunos:

Anderson Bestteti e Rafael Zancan FrantzProfessor:

Cláudio Fernando Resin Geyer

Porto Alegre, outubro de 2006

Conteúdo da apresentação

O tema do artigo Motivação para uso do MONARC Objetivos do Framework Solução Protótipo Resultados Conclusões

O tema

MONARC = MOdels of Networked Analysis at Regional Center Definições:

“Framework para montar simulações complexas de Modelos de Computacionais”

“Ferramenta de otimização para sistemas computacionais distribuídos em larga escala”

Motivação (1/3)

Realizar testes em “Grids” extremamente grandes, com programas altamente complexos, com um imenso volume de dados e largamente distribuídos, é extremamente caro!

Oferecer um framework para fazer simulações realistas de sistemas de computação largamente distribuídos

Oferecer um ambiente flexível e dinâmico para avaliar a performance de um conjunto de possíveis arquiteturas para processamento de dados

Motivação (2/3)

MONARC tem um “Simulation Engine” baseado em “Threaded Objects / Active Objects” Objetos oferecem grande flexibilidade para simular o complexo

comportamento dos programas de processamento de dados distribuídos.

Mecanismo de scheduling com suporte a interrupções Boa abordagem para descrever programas que são

dependentes de dados, que competem por recursos compartilhados e possuem grande transferência de dados concorrentemente

Motivação (3/3)

O Framework oferece um conjunto completo de componentes básicos para montar as simulações: Nós com processamento, servidores de dados,

componentes de rede, módulos de replicação de dados, scheduling

Provê mecanismos para: Descrever tráfego concorrente de rede Avaliar diferentes estratégias para:

Replicação de dados Job scheduling

Funcionalidades especiais disponíveis para uso com HEP (High Energy Physics)

O framework MONARC (1/4)

Implementado com Java devido: Suporte nativo a multithread Orientada a objetos Portabilidade

Arquitetura em Camadas: facilmente extensível

MonALISA

O framework MONARC (2/4)

Simulation Engine: projetado para ser genérico e ser capaz de descrever qualquer

sistema distribuído fornece um mecanismo de scheduling dedicado baseado em

semáforos para os “Active Objects” Active Objects:

simulam aplicações complexas, dependentes de dados e que compartilham recursos

possuem thread de execução, program counter, stack e um mecanismo de exclusão

Possuem métodos síncronos e assíncronos Podem ser interrompidos, suspensos e reiniciados Representam: jobs em execução, servidores de arquivos e

servidores de dados Classe Task descreve um Active Object

O framework MONARC (3/4)

Basic Components: Podem ser estendidos e criados alguns

componentes específicos com o intuito de atender necessidades específicas de alguns sistemas, como o HEP Grid

Componentes específicos para o HEP Grid Metadata catalog Analysis jobs Distributed job scheduler

O framework MONARC (4/4)

Metadata catalog Armazena dados de eventos processados na simulação.

Possui métodos para armazenar com ou sem replicas, localizar o database com os dados de um evento, entre outros.

Analysis jobs Utilizam o catálogo de metadados para obter os dados

necessários e então gastam um certo tempo com uso intensivo da CPU.

Distributed job scheduler Cada scheduler local decide onde é melhor executar o job. A

busca por um “regional center” será feita com base na disponibilidade de CPU.

Realizar uma simulação de transferência e replicação de arquivos numa WAN, que interconecta o CERN (European Organization for Nuclear Research) com outros laboratórios na Europa e EUA.

Simular transferência eficiente de dados numa WAN, usando Agentes.

Simular as seguintes atividades: Replicação de dados brutos; Produção e distribuição de DST; Re-produção e nova distribuição de DST, e; Detector Analysis.

Objetivos (1/2)

LHC

Objetivos (2/2)

Executar uma simulação das quatro atividades em paralelo.

Comparar a produção e a distribuição de DST, feita com e sem o agente de transferência de dados.

Solução – Estudo da Simulação (1/3) Escrita de um conjunto de exemplo de simulações

para simular o comportamento do Proof Cluster. O Proof é uma funcionalidade do framework Root,

para o processamento de dados distribuídos, desenvolvido pelo CERN. A sua configuração é formada por diversos clusters. Os

computadores de um cluster executam processos mestres e escravos.

Solução – Estudo da Simulação (2/3) Fases de processamento de dados do Proof:

Cliente solicita ao mestre um conjunto de dados a ser processado;

O mestre identifica o arquivos que contém os dados e determina a sua localização;

Cada escravo solicita ao mestre um conjunto de tarefas, que especifica o número de eventos a ser processado. Ao terminar o processamento, o escravo devolve o resultado ao mestre;

O mestre atribui tarefas aos escravos, a localização dos arquivos e a performance relativa dos outros escravos.

Solução – Estudo da Simulação (3/3)

Há três possibilidades para que os escravos obtenham os dados que lhes são atribuídos: Do disco local; De um servidor ou outra estação escrava; Com o auxílio do daemon rootd, que permite

acesso aos arquivos do banco de dados principal.

Protótipo/Demostração Com base na estrutura apresentada, os autores executaram testes em

um cluster, contendo: 20 Mestres; 500 estações escravas, e; Diferentes valores para servidores de dados.

Cada mestre recebeu uma requisição de um escravo. Cada escravo precisa processar um conjunto de dados de análise para um certo número de eventos.

Ao solicitar uma tarefa ao mestre, um arquivo é atribuído ao escravo, onde é assumido que este está armazenado localmente com certa probabilidade. Se não está disponível localmente, é feita uma requisição ao servidor de dados.

O comportamento do sistema foi estudado, variando alguns parâmetros como: A quantidade de processos escravos criados pelo mestre; A probabilidade do dado estar no disco local do escravo; A largura de banda da LAN.

Resultados (1/2)

Em diversos casos de teste foram obtidos uma melhora substancial do throughput no sistema simulado, quando: Incrementada a largura de banda: 100Mbps, 500Mbps e 1Gpbs; Redução do tempo de processamento no servidor de dados; Introdução de servidores de dados, contendo dados replicados.

Há vantagens com a execução de muitos processos escravos em uma máquina, pois enquanto alguns escravos estão esperando por dados da rede, outros podem executar operações CPU bound. Desvantagem fica por conta de eventuais gargalos gerados pelo

tráfego de rede, fila de espera nos servidores de dados e mestres.

Simulações de criação de 25, 50 e 100 processos escravos por cada mestre, mostraram que o número ótimo de escravos fica abaixo de 25, quando servidores de dados são single threaded.

Resultados (2/2)

Também foram simuladas situações na qual os escravos mandam muitas requisições aos mestres, onde foi observado que: Uma requisição média leva em torno de 2 à 3h

para ser processada em uma única CPU; O tempo de resposta diminui para alguns poucos

minutos quando processado por um cluster; Com um intervalo médio de 5min entre

requisições, e tendo um número maior de processos escravos, resulta em um melhor throughput do cluster;

Conclusões

MONARC é um framework que permite a um baixo custo fazer simulações de aplicações complexas em Grid

MONARC é facilmente extensível o que faz dele um framework ideal para simulações de aplicações específicas como o HEP e ao mesmo tempo genérico para outras simulações

Referências

CERN http://public.web.cern.ch/Public/Welcome.html , acesso em 05/10/2006.

Apresentação: The Grid: The Future of High Energy Physics Computing? http://www.wlap.org/umich/phys/seminars/hep-astro/2002/mckee/SeminarJan72002.ppt, acesso em 07/10/2006.