Desafios da nuvem: agendamento
- 7 minutos
A eficácia de um programa distribuído depende da maneira como as tarefas que o constituem são agendadas em computadores distribuídos. Esse agendamento normalmente é categorizado em duas classes principais, uma para tarefas e outra para trabalhos. As tarefas são a menor unidade da granularidade de execução e um trabalho pode conter uma ou várias tarefas. Vários usuários podem enviar vários trabalhos simultaneamente para execução em um cluster. Os agendadores de trabalhos determinam qual deles enviar em seguida. O Hadoop MapReduce, por exemplo, utiliza um agendador de trabalhos PEPS (primeiro a entrar, primeiro a sair), em que os trabalhos são executados em ordem de recebimento e um trabalho agendado ocupará o cluster inteiro até que não tenha mais tarefas para agendar. O Hadoop MapReduce também emprega outros agendadores de trabalhos, como o Agendador de Capacidade e o Agendador Justo. Depois que um trabalho é concedido ao cluster, a decisão de agendamento se transforma em como agendar as tarefas que compõem o trabalho. As tarefas podem ser agendadas próximo dos dados que processarão ou em qualquer lugar. Quando as tarefas são agendadas próximo de seus dados, considera-se que a localidade é explorada. Por exemplo, o Hadoop MapReduce incorpora dois tipos de tarefas, de mapeamento e redução. As tarefas de mapeamento são agendadas na proximidade de seus blocos HDFS de entrada uniformes, enquanto as de redução são agendadas em qualquer nó do cluster (em qualquer lugar), independentemente da localização de seus dados de entrada. O Pregel e o GraphLab, por outro lado, não exploram nenhuma localidade ao agendar tarefas.
Para evitar uma degradação significativa do desempenho, os agendadores de tarefas também precisam considerar a heterogeneidade no sistema de nuvem subjacente. Tarefas semelhantes que pertencem ao mesmo trabalho, por exemplo, podem ser agendadas em uma nuvem heterogênea em nós com velocidades diferentes. Esse procedimento, no entanto, pode introduzir desequilíbrio de carga e fazer os trabalhos progredirem no ritmo de suas tarefas mais lentas. Estratégias como a execução especulativa do Hadoop MapReduce podem atenuar esses problemas.
Além disso, os agendadores de tarefas devem buscar aprimorar a utilização do sistema e o paralelismo das tarefas. O objetivo aqui é distribuir as tarefas de maneira uniforme entre os computadores do cluster a fim de utilizar os recursos disponíveis de maneira justa e aumentar a paralelismo com eficiência, mas essa meta apresenta algumas prioridades contraditórias. Para começar, com a distribuição uniforme das tarefas entre os computadores do cluster, a localidade pode ser afetada. Os computadores em um cluster Hadoop, por exemplo, podem conter números diferentes de blocos HDFS. Se um computador tiver um número significativamente maior de blocos em comparação com os outros, a localidade implicaria no agendamento de todas as tarefas de mapeamento nesse computador. Essa disposição pode fazer com que outros computadores sejam menos carregados e utilizados. Além disso, essa estratégia pode reduzir o paralelismo das tarefas por acumular muitas tarefas no mesmo computador.
Se a localidade fosse relaxada de alguma forma, a utilização poderia ser aprimorada, as cargas entre computadores poderia ser equilibrada e o paralelismo das tarefas poderia ser aumentado. No entanto, para relaxar a localidade seria necessário mover os dados na direção das tarefas. Se isso for feito de maneira pouco criteriosa, o relaxamento poderá gerar sobrecargas de comunicação, impedindo assim a escalabilidade e potencialmente degradando o desempenho. De fato, com os datacenters hospedando milhares de computadores, mover dados com frequência para tarefas distantes pode vir a ser um grande gargalo. Para aprimorar o desempenho e reduzir custos, um agendador de tarefas ideal deve chegar a um equilíbrio entre a utilização do sistema, o balanceamento de carga, o paralelismo de tarefas, as sobrecargas de comunicação e a escalabilidade. Entretanto, na prática, esse ideal é difícil de atingir e a maioria dos agendadores de tarefas tenta otimizar um objetivo e ignora os outros.
Outro grande desafio ao agendar trabalhos e tarefas é atender aos chamados SLOs (objetivos de nível de serviço), que refletem as expectativas de desempenho dos usuários finais. Os provedores de nuvem identificaram violações do SLO como uma grande causa de insatisfação do usuário.1 Um SLO pode ser expresso, por exemplo, como uma latência máxima aceitável para alocar os recursos desejados a um trabalho, um prazo fixo/flexível para concluir um trabalho ou preferências de GPU para determinadas tarefas. Em clusters heterogêneos multilocatários, os SLOs são difíceis de atingir, especialmente quando novos trabalhos chegam enquanto outros estão sendo executados. Essa situação pode exigir suspender as tarefas em execução e permitir que as novas tarefas continuem, a fim de atingir seus SLOs especificados. A capacidade de suspender e retomar tarefas é chamada de elasticidade de tarefas. Entretanto, a maioria dos mecanismos de análise distribuída – incluindo o Hadoop MapReduce, o Pregel e o GraphLab – ainda não têm suporte para a elasticidade de tarefas. Habilitar a elasticidade é algo bastante desafiador e exige identificar pontos seguros nos quais uma tarefa pode ser suspensa sem afetar sua correção e de maneira que o trabalho confirmado não precise ser repetido ao retomá-la. Claramente, essa funcionalidade é semelhante à alternância de contexto em sistemas operacionais modernos.
Referências
- J. Hamilton (2009). O custo da latência