Descrição Detalhada do Método

Como os outros métodos de escalonamento estudados neste trabalho, o WQR recebe uma lista de nós ativos localizados pela DHT e atribui a cada nó uma tarefa do trabalho. Após a execução de n − m tarefas, onde n é o número de tarefas e m o número de máquinas, com n > m, o método WQR efetua a duplicação de uma tarefa em execução e envia essa cópia para outro nó disponível do sistema.

A quantidade de cópias é limitada, possuindo um valor limite de replicação de- finido de acordo com o tamanho do sistema e de acordo com a complexidade e o número das tarefas. A principal característica desse escalonamento é a troca do

overload de mensagens que deixam de transitar pela rede (para atualização de in-

formações utilizadas em escalonadores mais dinâmicos) pelo consumo de CPU [99]. Quando uma das cópias encerra normalmente a execução de sua tarefa, a execução das outras cópias é cancelada, concluindo a tarefa com êxito. A execução do método é descrita em seguida.

Método WQR

1: seleciona o trabalho

2: obtém a lista de tarefas do trabalho

3: executa algoritmo WQ

4: for i = 0 to i < tamanho da lista com tarefas originais e replicadas do

5: verifica se a tarefa pode ser replicada {a inclusão da réplica depende da quan-

tidade de tarefas que estão sendo executadas e da quantidade de falhas na tentativa de executá-las}

6: se afirmativo, replica a tarefa {a quantidade de tarefas em execução mais a

tarefa replicada não pode ultrapassar o limite de réplicas}

7: aloca a tarefa para o nó disponível

8: end for

Um dos principais argumentos defendido pelos autores do algoritmo é o seu bom desempenho com relação aos algoritmos que utilizam informações sobre o sistema. Apesar do gasto extra de ciclos de CPU, em decorrência da duplicação das tarefas, a compensação quando ao custo dispendido com a troca de informações entre os nós, ainda tem suas vantagens. O custo de troca de mensagens envolve várias in- terações entre os nós, mais o custo para a manutenção de um sistema gerenciador dos recursos. Outro problema, indicado pelos autores, refere-se ao monitoramento do sistema distribuído em decorrência de restrições de segurança implantadas pe- los administradores para acesso aos recursos, como, por exemplo, a existência de

firewalls.

Com a utilização da replicação, espera-se que as tarefas que estão atrasando a execução do trabalho em consequência de sua atribuição a um nó sobrecarregado ou com recursos limitados, sejam copiadas e atribuídas aos nós com maior probabi- lidade de encerrá-las antes do fim da execução da tarefa original. Nesse esquema, a alta heterogeneidade dos recursos e a baixa heterogeneidade das tarefas são im- portantes para o custo adicional de ciclos de CPU. O custo, dessa forma, não é muito relevante, pois a probabilidade de uma cópia da tarefa ser atribuída a um nó com baixa utilização de seus recursos, é maior, possibilitanto a execução mais rápida da tarefa.

No p2pBIOFOCO identificamos que as tarefas são muito semelhantes, pois referem-se à execução de uma ferramenta de Bioinformática que tem como entrada sequências biológicas de tamanhos entre 1K e 2K, com pouca variação, portanto, no tamanho. Quanto à complexidade da tarefa, cada sequência é comparada com todo o banco de dados biológicos, mantendo-se o tempo de execução das sequên- cias dentro de um intervalo proporcional ao tamanho das sequências, que não se diferenciam muito em seu tamanho. Caracterizadas as tarefas dessa maneira, se

houver baixa heterogeneidade dos recursos (máquinas de mesma configuração) e cargas semelhantes (decorrente da baixa heterogeneidade das tarefas), o consumo de CPU será alto. Como resultado, haverá pouco impacto no desempenho em de- corrência da baixa probabilidade de atribuição de uma cópia de uma tarefa a um nó não sobrecarregado e com grande capacidade de recursos.

Devemos observar a questão referente à tolerância a falhas. Importante para um sistema distribuído consistente, ela não foi incluída no método WQR. No en- tanto, encontramos em [103] a proposta de dois métodos - soft state e timeout - para tratamento do problema. Em decorrência da importância do assunto, detal- hamos a execução dos dois métodos com o objetivo de implementá-los futuramente no método WQR.

Na Seção 4.4, Tada et al [103] observaram que a implementação do método WQR apresentava uma deficiência com relação ao tratamento de falhas na execu- ção das tarefas e ao cancelamento explícito de tarefas em decorrência da existência de barreiras nas redes (NATs ou firewalls). Essa complicação deve-se ao fato da comunicação iniciar-se no nó que solicitou a execução da tarefa, com o envio da solicitação de cancelamento da tarefa. No entanto, em algumas situaçoes, não é permitido ao nó que executa o escalonador o envio da mensagem de cancelamento para os outros nós, submetidos a restrições de comunicação. Desse modo, decidi- ram incluir dois métodos para preenchimento dessa lacuna na definição do método WQR. O primeiro método é chamado de task timeout, enquanto o seguinte refere-se ao método soft state.

Com a instituição do task timeout, assume-se um valor de timeout no escalo- nador para execução da tarefa que ele submeteu. Se não houver resposta até o término do tempo determinado, a tarefa é copiada e escalonada para outro nó, ga- rantindo assim a execução de todas as tarefas. O problema surge quando se estabe- lece qual será o valor do timeout. Um valor subestimado resulta em replicação de tarefas que estão quase terminando sua execução, aumentando os custos de ciclos de CPU e de comunicação. Se o valor for superestimado, haverá problemas com a identificação de tarefas que falharam durante a sua execução. O cancelamento explícito da tarefa e de suas cópias é iniciado pelo nó do escalonador.

No segundo método, soft state, trabalha-se com a atualização das informações sobre a execução das tarefas e o envio de informações periódicas é iniciado pelo nó remoto, contornando o problema da reconfiguração da rede (inclusão de regras de

firewall, NATs). Ao submeter a tarefa, o escalonador inicia a contagem do timeout,

aguardando mensagens de atualização da execução da tarefa. Essas mensagens são enviadas pelo nó remoto ao escalonador para evitar que as reconfigurações da

rede atrasem o escalonador no envio de uma mensagem de cancelamento explícito da tarefa para outros nós, quando a tarefa é encerrada.

Se o escalonador não receber uma mensagem do nó para o qual foi submetida a tarefa até terminar o timeout de excução da tarefa, a tarefa é copiada e enviada para outro nó. Do mesmo modo, se o nó que recebeu a tarefa para execução não recebe uma mensagem do escalonador (a tarefa foi submetida a um nó que, durante o tempo de sua execução, foi submetido a restrições de acesso), informando que ainda está esperando pela execução da tarefa, a execução da tarefa é cancelada pelo nó remoto e uma mensagem de requisição de uma nova tarefa é enviada para o escalonador.