Heurística de Mapeamento Proposta

A heurística de escalonamento proposta neste trabalho é dinâmica, realizando o escalonamento e reescalonamento das aplicações de acordo com a disponibilidade dos recursos e do poder de processamento disponível. A heurística proposta é também uma heurística do tipo on-line, podendo mapear mais de uma tarefa para execução em um dado nó da grade. O mapeamento de tarefas da classe soft- deadline, ilustrado na Figura 4.1, é realizado levando-se em consideração o intervalo médio entre falhas (MTBF) dos nós e a sua capacidade de processamento. Escalona-se uma tarefa da classe soft-deadline para nós identificados como estáveis (que apresentem maior MTBF) e cuja capacidade permita concluir a execução da tarefa dentro do prazo estipulado pelo usuário ao submeter a aplicação para execução na grade. Devido ao custo imposto pelo uso da abordagem de checkpointing e a eventual carga de trabalho local do nó, considera-se aptos para realizar a tarefa os nós cuja capacidade de processamento estimada pelo algoritmo de predição adotado permita a execução da tarefa acrescida de uma margem de 10%. Caso a carga local de trabalho exceda esta estimativa inicial, o mecanismo de acompanhamento do progresso da execução das tarefas é responsável por identificar a incapacidade do nó em cumprir o prazo estipulado e re-submeter a tarefa para um novo escalonamento.

A abordagem proposta integra um mecanismo de reserva antecipada de recursos que funciona da seguinte forma: ao se realizar o mapeamento de uma tarefa, caso não haja nós disponíveis que atendam aos critérios anteriormente descritos, busca-se nós que já estejam executando tarefas e que atendam aos seguintes critérios: (a) se a tarefa for da classe nice, ela será interrompida para dar lugar a tarefa soft- deadline, reservando-se o recurso para que posteriormente possa dar continuidade à execução da tarefa nice interrompida, o que será realizado a partir do seu último checkpoint salvo (linhas 4 a 7 e linhas 28 a 31); (b) caso a tarefa seja da classe soft-deadline, verifica-se se o tempo restante para sua execução acrescido do tempo necessário para executar a tarefa sendo escalonada é suficiente para atender ao prazo definido para a execução desta última. Caso seja, o recurso é reservado para a tarefa em questão (linhas 9 a 12 e linhas 33 a 36). Finalmente, caso não seja encontrado um recurso que atenda o prazo estipulado para a execução da tarefa conforme os critérios descritos, o usuário terá sua aplicação recusada (linhas 13 a 16 e linhas 37 a 40).

4.1 Arquitetura da Abordagem Proposta 66

Figura 4.1:Mapeamento SOFT

1: case 𝑆𝑂𝐹 𝑇 2: do 3: if 𝑓 𝑟𝑒𝑒𝐿𝑅𝑀 𝑠.𝑠𝑖𝑧𝑒()== 0 then 4: 𝑙𝑟𝑚𝑁 𝑖𝑐𝑒= 𝑠𝑒𝑎𝑟𝑐ℎ𝑁 𝑖𝑐𝑒𝐿𝑅𝑀 (𝑙𝑟𝑚𝐿𝑖𝑠𝑡, 𝑡𝑎𝑠𝑘, 𝑑𝑒𝑎𝑑𝑙𝑖𝑛𝑒); 5: if 𝑙𝑟𝑚𝑁 𝑖𝑐𝑒!= null then 6: 𝑚𝑎𝑝𝑠(𝑡𝑎𝑠𝑘, 𝑙𝑟𝑚𝑁 𝑖𝑐𝑒); 7: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 8: else 9: 𝑙𝑟𝑚𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑= 𝑟𝑒𝑠𝑒𝑟𝑣𝑒𝑆𝑜𝑓 𝑡𝐿𝑅𝑀 (𝑙𝑟𝑚𝐿𝑖𝑠𝑡, 𝑡𝑎𝑠𝑘, 𝑑𝑒𝑎𝑑𝑙𝑖𝑛𝑒); 10: if 𝑙𝑟𝑚𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑!= null then 11: 𝑚𝑎𝑝𝑠(𝑡𝑎𝑠𝑘, 𝑙𝑟𝑚𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑); 12: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 13: else 14: 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑅𝑒𝑓 𝑢𝑠𝑒𝑑(𝑡𝑎𝑠𝑘); 15: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 16: end if 17: end if 18: else 19: for 𝑖= 0; 𝑖 < 𝑓 𝑟𝑒𝑒𝐿𝑅𝑀 𝑠.𝑠𝑖𝑧𝑒(); 𝑖++ do 20: 𝑙𝑟𝑚= 𝑓 𝑟𝑒𝑒𝐿𝑅𝑀 𝑠.𝑔𝑒𝑡(𝑖); 21: 𝑖𝑠𝑀 𝑎𝑝𝑝𝑒𝑑= 𝑐𝑎𝑛𝐴𝑐ℎ𝑖𝑒𝑣𝑒𝐷𝑒𝑎𝑑𝑙𝑖𝑛𝑒(𝑙𝑟𝑚, 𝑡𝑎𝑠𝑘, 𝑑𝑒𝑎𝑑𝑙𝑖𝑛𝑒); 22: if 𝑖𝑠𝑀 𝑎𝑝𝑝𝑒𝑑 then 23: 𝑚𝑎𝑝𝑠(𝑡𝑎𝑠𝑘, 𝑙𝑟𝑚); 24: 𝑓 𝑟𝑒𝑒𝐿𝑅𝑀 𝑠.𝑟𝑒𝑚𝑜𝑣𝑒(𝑙𝑟𝑚); 25: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 26: else 27: if 𝑖== 𝑓 𝑟𝑒𝑒𝐿𝑅𝑀 𝑠.𝑠𝑖𝑧𝑒() - 1 then 28: 𝑙𝑟𝑚𝑁 𝑖𝑐𝑒= 𝑠𝑒𝑎𝑟𝑐ℎ𝑁 𝑖𝑐𝑒𝐿𝑅𝑀 (𝑙𝑟𝑚𝐿𝑖𝑠𝑡, 𝑡𝑎𝑠𝑘, 𝑑𝑒𝑎𝑑𝑙𝑖𝑛𝑒); 29: if 𝑙𝑟𝑚𝑁 𝑖𝑐𝑒!= null then 30: 𝑚𝑎𝑝𝑠(𝑡𝑎𝑠𝑘, 𝑙𝑟𝑚𝑁 𝑖𝑐𝑒); 31: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 32: else 33: 𝑙𝑟𝑚𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑= 𝑟𝑒𝑠𝑒𝑟𝑣𝑒𝑆𝑜𝑓 𝑡𝐿𝑅𝑀 (𝑙𝑟𝑚𝐿𝑖𝑠𝑡, 𝑡𝑎𝑠𝑘, 𝑑𝑒𝑎𝑑𝑙𝑖𝑛𝑒); 34: if 𝑙𝑟𝑚𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑!= null then 35: 𝑚𝑎𝑝𝑠(𝑡𝑎𝑠𝑘, 𝑙𝑟𝑚𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑); 36: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 37: else 38: 𝑠𝑢𝑏𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑅𝑒𝑓 𝑢𝑠𝑒𝑑(𝑡𝑎𝑠𝑘); 39: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 40: end if 41: end if 42: end if 43: end if 44: end for 45: end if 46: end case

A Figura 4.2 ilustra o algoritmo utilizado para o mapeamento de tarefas da classe nice. O mapeamento destas tarefas também é realizado levando-se em consideração o MTBF dos nós. No entanto, ao contrário do que é feito com tarefas da classe soft-deadline, escalona-se tarefas da classe nice para nós identificados como instáveis (que apresentem menor MTBF). Para tanto, gera-se a lista de nós disponíveis

4.1 Arquitetura da Abordagem Proposta 67 ordenando-a pelo MTBF em ordem decrescente, mapeando a tarefa nice para o último recurso da lista (linhas 3 a 6). Caso não haja nós disponíveis, busca-se aqueles que já estejam executando tarefas da classe nice, escolhendo o primeiro para a execução da tarefa, realizando-se uma reserva antecipada deste recurso (linhas 7 a 11). Finalmente, caso não seja encontrado um recurso disponível ou que esteja executando uma tarefa da classe nice, o algoritmo irá mapear a tarefa para um recurso aleatório (linhas 13 a 16), colocando-a no final de sua fila de execução.

Figura 4.2:Mapeamento NICE

1: case 𝑁 𝐼𝐶𝐸 2: do 3: if 𝑓 𝑟𝑒𝑒𝐿𝑅𝑀 𝑠.𝑠𝑖𝑧𝑒()> 0 then 4: 𝑙𝑟𝑚= 𝑓 𝑟𝑒𝑒𝐿𝑅𝑀 𝑠.𝑟𝑒𝑚𝑜𝑣𝑒𝐿𝑎𝑠𝑡(); 5: 𝑚𝑎𝑝𝑠(𝑡𝑎𝑠𝑘, 𝑙𝑟𝑚); 6: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 7: else 8: 𝑙𝑟𝑚𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑= 𝑟𝑒𝑠𝑒𝑟𝑣𝑒𝑁 𝑖𝑐𝑒𝐿𝑅𝑀 (𝑟𝑒𝑠𝐿𝑖𝑠𝑡); 9: if 𝑙𝑟𝑚𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑!= null then 10: 𝑚𝑎𝑝𝑠(𝑡𝑎𝑠𝑘, 𝑙𝑟𝑚𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝑑); 11: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 12: else 13: 𝑖𝑛𝑑𝑒𝑥𝐿𝑅𝑀= 𝑟𝑎𝑛𝑑𝑜𝑚.𝑛𝑒𝑥𝑡𝐼𝑛𝑡(𝑙𝑟𝑚𝐿𝑖𝑠𝑡.𝑠𝑖𝑧𝑒()); 14: 𝑙𝑟𝑚= 𝑙𝑟𝑚𝐿𝑖𝑠𝑡.𝑔𝑒𝑡(𝑖𝑛𝑑𝑒𝑥𝐿𝑅𝑀 ); 15: 𝑚𝑎𝑝𝑠(𝑡𝑎𝑠𝑘, 𝑙𝑟𝑚); 16: return 𝑚𝑎𝑝𝑝𝑖𝑛𝑔𝑅𝑒𝑠𝑢𝑙𝑡; 17: end if 18: end if 19: end case

4.2 Conclusões 68

4.2

Conclusões

Este capítulo apresentou a abordagem proposta neste trabalho de mestrado para o gerenciamento de aplicações com restrições de tempo de execução desenvolvido para ambientes de grades oportunistas e sua arquitetura. A abordagem proposta considera duas classes de aplicações: (a) soft-deadline e (b) nice. As aplicações da classe soft-deadline, possuem como meta a conclusão das aplicações dentro deste prazo, já para as aplicações da classe nice a meta é apenas a conclusão da aplicação com sucesso. Neste trabalho, foi visto que a arquitetura do mecanismo de gerenciamento de aplicações é composta por cinco mecanismos: um mecanismo de predição do tempo de execução das aplicações, uma heurística de escalonamento, um mecanismo que monitora o progresso da execução das tarefas com restrição de tempo em cada nó da grade, um mecanismo que monitora o tempo médio entre falhas de cada recurso e um mecanismo de tolerância a falhas na execução de aplicações baseado em checkpointing. Dentre estes mecanismo temos como componente principal a heurística de escalonamento implementada no simulador AGST [18, 19].

69

5 Avaliação da Abordagem Proposta

Este capítulo descreve a avaliação realizada da abordagem proposta nesta dissertação de mestrado. Esta avaliação foi realizada utilizando-se uma ferramenta de simulação especificamente desenvolvida para ambientes de grades de computadores, o Autonomic Grid Simulator Tool (AGST). O uso da abordagem de simulação deve- se às inúmeras dificuldades para se obter um ambiente adequado para realizar experimentos que tenham por objetivo testar e avaliar a abordagem desenvolvida, tais como: a dificuldade em se ter acesso a um ambiente de grade com recursos em grande escala; a dificuldade em se explorar cenários com aplicações típicas de computação em grade, que podem executar durante várias horas e até mesmo dias, tornando inviável executar diversos testes considerando restrições de tempo; a dificuldade de se explorar cenários com recursos e aplicações envolvendo diversos usuários de forma repetitiva e controlada, devido à natureza dinâmica dos ambientes de grade e a dificuldade de coordenar os usuários. Neste capítulo foram apresentados uma breve descrição da ferramenta de simulação utilizada, o desenvolvimento do modelo de simulação que implementa a abordagem proposta e foram discutidos os resultados obtidos a partir das diversas simulações realizadas, que levaram em consideração diversos cenários típicos de ambientes de grades computacionais oportunistas.