Os ambientes de computação em grande escala, como é o caso das grelhas computacio- nais CERN LCG [Tea04], NorduGrid [EKS+03], TeraGrid [TTP] e Grid’5000 [CCD+05], entre outras, colocam à disposição centenas de recursos para a resolução de problemas de elevada complexidade/dimensão. Uma das principais vantagens das grelhas compu- tacionais é o facto de as redes envolvidas poderem ser distribuídas entre entidades ou empresas, que concordaram trabalhar no mesmo projecto ou problema. Na verdade, o que realmente distingue as grelhas computacionais dos sistemas de clusters mais tradi- cionais é que estas tendem a ser geograficamente mais dispersas. Uma das principais desvantagens é o facto dos resultados de todos os processos terem de ser enviados de um local para o outro e avaliados de forma colaborativa, para que o resultado final possa ser deduzido.
A heterogeneidade das grelhas computacionais, a existência de arquitecturas paralelas e a sua complexidade inerente, representam um desafio para os mecanismos de PCR. Esta heterogeneidade faz com que seja impossível a aplicação das tradicionais técnicas de armazenamento do estado, que utilizam estratégias não portáveis, requerendo, assim, ferramentas e representações de pontos de controlo portáveis. Os FPC deverão permitir o restauro da aplicação, em máquinas com arquitecturas diferentes daquelas onde foram criados. O mecanismo de PCR, para grelhas computacionais, deverá suportar aplicações paralelas com protocolos de comunicações independentes. A ferramenta de ponto de controlo não deverá fazer suposições em relação à interface ou à implementação que está a ser utilizada [RMG+10]. As grelhas computacionais incluem máquinas pertencentes a diferentes entidades que não podem ser obrigadas a fornecer determinadas versões da interface MPI. Uma vez que nas grelhas computacionais são executadas aplicações paralelas/distribuídas, deverá ser preservada a consistência global de uma aplicação após o seu restauro. Devemos ter em conta que em aplicações paralelas as dependências criadas por comunicações entre os processos devem ser preservadas durante a recuperação.
Nas grelhas computacionais existem elementos de armazenamento remotos, onde os dados são armazenados [SAR]. Os elementos de armazenamento podem ser utilizados para guardar o resultado de um trabalho, enquanto o utilizador e a máquina cliente estão desconectados da grelha. Quando comparados com os ambientes cluster tradicionais, os elementos de armazenamento aumentam a latência de gravação/leitura de dados, portanto, a optimização de dados torna-se mais fulcral nas grelhas do que nos clusters tradicionais.
A ampla distribuição geográfica das grelhas computacionais, a sua dimensão e as restri- ções colocadas pelos responsáveis dos recursos partilhados levantam problemas à disponi- bilidade dos recursos das grelhas [IJSE07], portanto, não é de estranhar, que os recursos disponibilizados para uma aplicação variem durante a execução. Esta variabilidade nos recursos das grelhas, pode ocorrer pelos seguintes motivos:
• Sobrecarga computacional nos nós;
• Indisponibilidade dos nós devido a falhas;
• Manutenção;
• Disponibilidade de novos recursos;
• Libertação dos recursos alocados para serem utilizados por trabalhos com uma maior prioridade.
Muitos dos recursos das grelhas estão agrupados em clusters, disponibilizados por períodos limitados de tempo, pelos seus responsáveis. Alguns destes recursos podem mesmo ser removidos do sistema pelos seus responsáveis, para serem utilizados noutras tarefas [IJSE07]. É, então, fundamental, que as aplicações em execução nas grelhas possuam um mecanismo de adaptação à variabilidade de recursos, de forma a obter uma melhor performance e a retirar um melhor partido dos recursos disponíveis em cada instante. O próprio mecanismo de tolerância a faltas pode ser utilizado para adaptação a novos recursos, sendo para tal necessário efectuar o ponto de controlo, terminar a execução da aplicação e reiniciá-la nos novos recursos disponíveis. No entanto, o ideal é um mecanismo de adaptação dinâmico (portável), que permita adaptar a aplicação aos recursos disponíveis, sem necessidade de reiniciar a aplicação.
Um problema importante em grelhas computacionais consiste na selecção de um con- junto de recursos iniciais que permita à aplicação obter boas performances. A determi- nação do conjunto de recursos óptimo para uma dada aplicação (o conjunto de recursos com o menor tempo de execução) é considerado um problema NP-completo [VD05]. Ou- tro problema também relevante é a adaptação dinâmica de recursos durante a execução aplicacional, que se refere à performance e disponibilidade dos recursos das grelhas ao longo da execução de uma aplicação. Sumariamente, o primeiro problema refere-se à escolha inicial dos recursos para uma dada aplicação, enquanto o segundo refere-se à adaptação dos recursos de uma dada aplicação durante a sua execução.
Algumas estratégias de selecção dos recursos iniciais, como as utilizadas em [AAB+05,
da aplicação para diferentes conjuntos de recursos. Na fase de selecção dos recursos inici- ais, o modelo selecciona, de um leque de recursos, o conjunto que possibilita o tempo de execução previsto mais baixo. Esta fase é novamente repetida se durante a execução da aplicação ocorrer degradação da sua performance. Na abordagem descrita em [WMB07] inicia-se a aplicação num conjunto qualquer de recursos e durante a execução ajustam-se os recursos computacionais (retirando ou adicionando nós/clusters), consoante estimati- vas baseadas na colecta periódica de dados da performance.
Actualmente, abordagens de adaptação dinâmica a recursos, como por exemplo CP3 [FPS06], AMPI [HLK03] e TMPI [TY01] baseiam-se em sobre-decomposição. A ideia da sobre-decomposição consiste na utilização de um número lógico de ’n’ processos, superior ao número de processadores físicos, sendo ’n’ (idealmente) o número de processadores a partir do qual a aplicação paralela não escala, repartindo assim os ’n’ processos pelos processadores físicos. No caso do CP3, os processos lógicos mapeados para um proces- sador físico, são aglomerados num único processo com múltiplas LE, em que cada linha corresponde a um processo lógico [FPS06]. O objectivo é providenciar uma implementa- ção de baixo custo com excesso de tarefas paralelas, em que se procede à redistribuição de trabalho pelos recursos alocados. À medida que os recursos alocados para a aplica- ção variam durante a sua execução, é efectuado um re-mapeamento dos processos pelos recursos actualmente disponíveis.