Simple Locality-Aware Co- allocation in Peer-to-Peer Supercomputing Felipe Jung Vilanova Rodrigo Gheller Luque.

Apresentação em tema: "Simple Locality-Aware Co- allocation in Peer-to-Peer Supercomputing Felipe Jung Vilanova Rodrigo Gheller Luque."— Transcrição da apresentação:

1 Simple Locality-Aware Co- allocation in Peer-to-Peer Supercomputing Felipe Jung Vilanova Rodrigo Gheller Luque

2 Problema  Supercomputing Não é high throughput computing Tarefas não são independentes Há comunicação entre as tarefas

3 Supercomputing  Co-allocation Escalonar tarefas em vários sites  Setup complicado  Manutenção cara  Componentes centralizados Falta de tolerância a falhas Falta de escalabilidade (gargalo)

4 Proposta  P2P Supercomputing Inexistência de componente centralizado Presença de tolerância a falha Presença de escalabilidade Escalonador considera distância entra máquinas (locality aware) Resistente a mudanças no ambiente

5 Objetivo  Zorilla Protótipo de middleware Flooding  Selective broadcast  Radius Menor custo que grid Mais confiável a ambientes dinâmicos

6 Revisão  Global Computing Master-Worker Ciclos ociosos Exemplos  SETI@home  XtremeWeb  distributed.net  Poucos suportam Supercomputing XtremeWeb  Escalonador centralizado

7 Revisão  Globus e Unicore Escalonador local para sites (normalmente clusters) Meta escalonador centralizado  Escalonadores atuais com co-alocação tem algum ponto de centralização

8 Revisão  Centralizadores facilitam Contabilização Segurança Descoberta  Como fazer isso numa rede sem centralizador?

9 Zorilla  Implementado em JAVA Portável Apenas precisa JVM instalado  Suporta programas nativos Virtualização para resolver segurança  VMWare  VirtualBox

10 Zorilla  Todos os nodos podem Executar tarefas Escalonar tarefas Submeter tarefas Armazenar arquivos

11 Zorilla  P2P overlay network Virtual network Nodos próximos fisicamente tendem a ser vizinhos  Suporta tarefas paralelas  Tolerância a falhas requirida a nível de aplicação Quando nodo cai, tarefa paralela reagenda para outro nó, mas aplicação deve tratar

12 Zorilla  Objeto tarefa distribuída Estado Arquivos associados  Nodo Worker proporcial a # processadores

13 Zorilla 1.Tarefa é submetida

14 Zorilla Job 1.Tarefa é submetida 2.Anúncio por Flooding

15 Zorilla Job 1.Tarefa é submetida 2.Anúncio por Flooding

16 Zorilla Job 1.Tarefa é submetida 2.Anúncio por Flooding

17 Zorilla Job 1.Tarefa é submetida 2.Anúncio por Flooding 3.Workers são instanciados w w ww

18 Zorilla Job w w ww 1.Tarefa é submetida 2.Anúncio por Flooding 3.Workers são instanciados 4.Resultados são coletados

19 Escalonamento  Distribuído Nós verificam requerimento e estado  Localidade Latência entre nodos  Tolerância a falhas a nível de middleware Aplicação é notificada de falha num nodo Tratamento da falha pela aplicação Não implementa sistema de checkpoints

20 Eslonamento  Heurístico Raio baseado em log 10 Vizinhança média 10 Incrementa raio até atingir requerimentos  Otimizações FIFO para anúncios  Lazzy feedback Timeout incremental Early computation

21 Implementação Interface WEB Jobs Pendentes Interface com Cliente Camada de Abstração de Rede TCPBamboo Broadcast UDP Jobs Ativos... Máquina Virtual Java (JVM)

22 Implementação Interface WEB Jobs Pendentes Interface com Cliente Camada de Abstração de Rede Bamboo Broadcast UDP Jobs Ativos... Máquina Virtual Java (JVM)  Conexão direta entre os nodos  Conexão externa TCP

23 Implementação Interface WEB Jobs Pendentes Interface com Cliente Camada de Abstração de Rede TCP Broadcast UDP Jobs Ativos... Máquina Virtual Java (JVM)  Comunicação interna entre os nodos  Entrada de novos nodos  Detecção de falhas e ajuste da rede  Locality Aware Bamboo

24 Implementação Interface WEB Jobs Pendentes Interface com Cliente Camada de Abstração de Rede TCPBamboo Jobs Ativos... Máquina Virtual Java (JVM)  Para novos nodos encontrarem os outros nodos da rede e vice -versa  Broadcast periódico Broadcast UDP

25 Implementação Interface WEB Jobs Pendentes Interface com Cliente TCPBamboo Broadcast UDP Jobs Ativos... Máquina Virtual Java (JVM)  Abstração da implementação de rede para a camada de cima  Sistema de troca de mensagem simples Camada de Abstração de Rede

26 Implementação Camada de Abstração de Rede TCPBamboo Broadcast UDP Máquina Virtual Java (JVM)  Funcionalidade do nodo Jobs Pendentes Interface com Cliente Jobs Ativos... Interface WEB

27 Implementação Interface WEB Jobs Pendentes Camada de Abstração de Rede TCPBamboo Broadcast UDP Jobs Ativos... Máquina Virtual Java (JVM)  Submissão de tarefas  Requisições via conexão TCP (criar ou cancelar tarefas, consultar estado ) Interface com Cliente

28 Implementação Jobs Pendentes Interface com Cliente Camada de Abstração de Rede TCPBamboo Broadcast UDP Jobs Ativos... Máquina Virtual Java (JVM)  Web Browser  Monitoração de estado de nodos e tarefas Interface WEB

29 Implementação Interface WEB Jobs Pendentes Interface com Cliente Camada de Abstração de Rede TCPBamboo Broadcast UDP Jobs Ativos Máquina Virtual Java (JVM)  Tarefas recebidas mas ainda não executadas  Tarefas sendo executadas armazena os arquivos, o estado e todos “workers” de uma tarefa...

30 Implementação  Estado original da tarefa mantido no nodo que a submeteu Execuções que não modificam o estado de uma tarefa: local Execuções que modificam o estado de uma tarefa: Encaminhadas ao responsável  Arquivos Saídas e logs: enviados ao responsável Entradas: lidas de um nodo qualquer

31 Experimentos  Teste no Grid5000 Milhares de processadores distribuídos em 8 localidades na França Latência entre 5 e 20 milisegundos  Testes de usabilidade e escalabilidade com e sem Zorilla Resolver N-Queens puzzle de maneira distribuída

32 Experimentos  Sistema Satin Modelo paralelo de computação “dividir para conquistar”  Ibis Software em Java para Grid

33 Experimentos – Sem Zorilla  Implantação Copiar programa e arquivos de entrada em todos clusters e configurá-los Determinar mecanismo de escalonamento local de tarefas e escrever os scripts  Execução Determinar disponibilidade de nodos Iniciar o servidor de nomes do Ibis Monitorar o progresso da aplicação

34 Experimentos – Sem Zorilla  Limpeza Coletar arquivos de saída e logs Cancelar reservas pendentes Remover arquivos de saída e logs dos clusters

35 Experimentos – Com Zorilla  Copiar Zorilla em todos os clusters (338 máquinas com 2 processadores)  Determinar a configuração da rede local  Iniciar a execução utilizando o escalonador local

36 Experimentos – Com Zorilla  Com apenas um comando Zorilla foi implantado e iniciado automaticamente em todos os 671 processadores em 90s, sem nenhuma outra intervenção humana  Resolveu o problema N-Queens 22 em 35 minutos  Após o término copiou todos os arquivos de saída e logs para o nodo que submeteu a tarefa

37 Teste do algoritmo de escalonamento  430 máquinas em 6 diferentes sites do Grid5000  Número de workers em cada cluster variou de 18 em Grenoble a 356 em Orsay

38 Teste do algoritmo de escalonamento

39 Conclusões  Zorilla é fácil de implantar, portável e pode automatizar os passos necessários para rodar aplicações distribuídas de super-computação  Zorilla é escalável e tolerante a falhas

40 Conclusões do Grupo  Considera Grid como coleção de Clusters Testes não utilizaram sistemas P2P reais Sistema dinâmico?  Tolerância a falhas? Implementação de checkpoints?

41 Conclusões do Grupo  Escalonamento Vizinhança média? Raio progressivo? Submissão tendenciosa Locality-Aware?  Pseudo-vizinhança  Timeout incremental?

42 Conclusões do Grupo  Teste de submissão única?  Teste de submissão centralizada? Concorrência?  Overlay Network - Bamboo Particionamento por latência