Videre arbeid

Os dois principais módulos de gerenciamento do sistema de recuperação por retrocesso são o Geren- ciador de Execuções (EM) e o Gerenciador de Repositórios de Checkpoints (CRM). Estes módulos são instanciados no nó de gerenciamento do aglomerado.

Gerenciador de Execuções (EM)

O gerenciador de execuções (EM), implementado em Java, é responsável pelo gerenciamento de requisições de execução de aplicações, incluindo seu reinício em caso de falha de nós. O EM mantém uma tabela interna contendo informações sobre as aplicações escalonadas para execução pelo GRM, incluindo os nós responsáveis pela execução dos processos destas aplicações.

O GRM informa o EM sempre que realiza o escalonamento de uma aplicação, sem fornecer a identi- ficação dos LRMs escolhidos para a execução. Esta identificação é enviada posteriormente pelos próprios LRMs, antes do início da execução dos processos4_{. Quando um processo termina, o LRM informa o EM}

a respeito do término do processo, assim como o estado (status) de término. Deste modo, o EM sempre possui informações atualizadas sobre o estado dos processos das aplicações.

O estado de término de um processo é utilizado pelo EM para determinar se aquele processo deve ser reiniciado ou não. Nos casos em que o processo finaliza normalmente ou em que ocorreu um problema

4_{Caso o número de identificações recebidas pelo EM seja inferior ao número de processos da aplicação paralela, o EM} considera que houve falha em um dos LRMs e inicia o protocolo de reinicialização da execução da aplicação, descrito na Seção 3.3.3.

relacionado ao próprio processo, como uma falha de segmentação, o EM não reinicia o processo. Por outro lado, se o processo foi morto por um sinal do sistema operacional, como KILL ou TERM, isto é interpretado como um sinal para realizar a liberação de recursos da máquina. Neste caso, o processo é reiniciado em outro provedor de recursos.

Um outro cenário ocorre quando um LRM se torna inacessível. Isto pode ocorrer por diversos mo- tivos, como partição na rede, problemas na máquina onde o LRM estava executando ou uma falha no próprio LRM. Os LRMs de um aglomerado periodicamente enviam mensagens do tipo heartbeat para o GRM. Quando um GRM verifica que um LRM não envia mensagens por um período superior a um limiar, ele envia uma mensagem àquele LRM e, caso não obtenha resposta, marca-o como indisponível. O GRM notifica então o EM, que verifica quais processos estavam sendo executados no LRM que falhou e requisita ao GRM o escalonamento destes processos para execução em outros LRMs.

No caso de aplicações seqüenciais e paramétricas, como não existem dependências entre processos, a reinicialização da aplicação é simples, bastando o EM solicitar ao GRM o re-escalonamento do processo que falhou. No caso de processos que fazem parte de aplicações BSP, é preciso considerar também as dependências com os demais processos da aplicação, podendo também ser necessário reiniciar estes processos.

Definimos uma interface CORBA para o EM com métodos que realizam o gerenciamento das exe- cuções de aplicações. Os métodos presentes nesta interface são:

• reportExecutionScheduled: É utilizado pelo GRM para notificar que realizou o escalo- namento da execução dos processos de uma aplicação e enviou as requisições aos LRMs selecio- nados. O EM adiciona uma nova entrada à sua tabela de execuções com informações referentes à aplicação escalonada, como número de processos, parâmetros, nós de execução dos processos e arquivos de entrada e saída.

• reportExecutionStarted: É utilizado pelos LRMs para notificar o EM que a execução de um processo referente a uma aplicação foi iniciada. Ao receber esta mensagem, o EM adiciona o endereço do LRM às informações da aplicação correspondente àquele processo.

• reportExecutionFinished: É utilizado pelos LRMs para notificar que uma execução foi finalizada, enviando o estado de término da execução. O EM executa diferentes ações dependendo do estado de término enviado, como descrito na Seção 3.3.1.

• notifyLrmFailure: É utilizado pelo GRM para notificar que um LRM parou de responder. O EM verifica então os processos que estavam sendo executados naquele LRM e chama o método reportExecutionFinishedpara que estes processo sejam reinicializados.

• registerBspNode: É utilizado durante a inicialização de aplicações BSP de modo que seus processos possam obter referências ao processo zero da aplicação. Cada aplicação BSP possui

3.3 Implementação dos principais componentes 37 um único processo zero, que é responsável por coordenar a execução da aplicação, incluindo sua inicialização e sincronização.

A implementação dos métodos notifyLrmFailure, reportExecutionScheduled e reportExecutionStartedé direta, o único cuidado especial fica por conta da sincronização dos acessos à tabela de execuções. No método registerBspNode, para permitir que os processos de uma aplicação BSP possam chamá-lo em qualquer ordem, colocamos em espera quaisquer requisições feitas por processos diferentes do processo zero, utilizando uma variável condicional, até que este se registre. A implementação do método reportExecutionFinished é discutida na Seção 3.3.3.

Gerenciador de Repositórios de Checkpoints (CRM)

O gerenciador de repositórios de checkpoints (CRM), implementado em Java, é responsável pelo gerenciamento de checkpoints de aplicações e de repositórios de checkpoints. O CRM possui duas tabelas principais, que contêm dados sobre: (1) repositórios de checkpoints registrados e (2) checkpoints de aplicações sendo executadas em seu aglomerado. A interação do CRM com os demais componentes do sistema se dá através de uma interface CORBA, que contém os seguintes métodos:

• getCheckpointRepositoryList: É utilizado pela biblioteca de checkpointing para obter uma lista de repositórios onde o checkpoint pode ser armazenado. Quando a lista de repositórios é solicitada, a biblioteca de checkpointing informa qual estratégia de armazenamento está utilizando, replicação ou codificação em múltiplos fragmentos, e os parâmetros desta estratégia, como número de réplicas e fragmentos. A versão atual do CRM escolhe os repositórios aleatoriamente, de modo que, em média, cada repositório armazenará a nesma quantidade de checkpoints.

• getLastCheckpointInfo: Fornece os dados do último checkpoint salvo por uma aplicação, incluindo seu identificador e os locais onde seus fragmentos (ou réplicas) estão localizados. • notifyCheckpointStored: Utilizado por repositórios de checkpoints para notificar que um

fragmento pertencente a um checkpoint foi armazenado. O CRM adiciona às suas tabelas a loca- lização do fragmento armazenado e determina se todos o fragmentos de um checkpoint já foram armazenados ou não.

• registerCheckpointRepository: É utilizado pelos repositórios de checkpoints para se registrar assim que são inicializados. O CRM adiciona os dados do novo repositório à sua lista de repositórios e retorna um identificador único para o repositório.

• setCheckpointStorageMode: Configura a estratégia de armazenamento utilizada por uma aplicação. A estratégia de armazenamento determina o número de repositórios fornecidos pelo método getCheckpointRepositoryList e o número de fragmentos necessários para de- terminar um checkpoint como armazenado.

• updateRepositoryStatus: É chamado periodicamente pelos repositórios para notificar que estão operantes e a quantidade de espaço em disco disponível. Permite ao CRM determinar quais repositórios estão ativos e a quantidade de recursos disponíveis nestes repositórios.

• getRemovalList: É chamado pelos repositórios de checkpoints e devolve uma lista de frag- mentos de checkpoints que podem ser removidos do repositório. Apenas os checkpoints mais recentes de aplicações ainda não terminadas são mantidos.

A escolha dos repositórios que armazenarão fragmentos de checkpoints é feita de forma aleatória. Deste modo, em média, cada repositório receberá uma quantidade similar de checkpoints. Além disso, antes de selecionar um repositório, o CRM verifica se este possui espaço em disco suficiente para arma- zenar o fragmento.

Os dados sobre os checkpoints gerados por uma aplicação são armazenados no EM, juntamente com os dados de execução da aplicação. Deste modo, o CRM e o EM interagem constantemente. À medida que fragmentos de checkpoints são armazenados nos repositórios, estes notificam o CRM. Quando to- dos os fragmentos de um checkpoint global forem armazenados, o CRM marca este checkpoint como armazenado.

Os repositórios devem periodicamente enviar ao CRM mensagens para notificar que estão operantes e a quantidade de espaço em disco disponível. Se um repositório passa mais que um determinado tempo, por exemplo, 1 minuto, sem enviar mensagens de notificação, o CRM deixa de selecioná-lo para a arma- zenagem de checkpoint. Se este tempo for maior que um segundo limiar, por exemplo, 1 hora, o CRM remove de suas tabelas todas as informações relativas àquele repositório.

O CRM mantém uma lista de remoção para cada repositório de checkpoints, contendo a lista de

checkpoints que devem ser removidos. Para determinar estes checkpoints, o CRM interage com o EM

de seu aglomerado. Sempre que uma aplicação finaliza sua execução, o EM notifica o CRM, que coloca todos os checkpoints daquela execução na lista de remoção. Além disso, o CRM permite manter um número máximo de checkpoints por execução, de modo que à medida que novos checkpoints são gerados, outros são removidos. Utilizando um protocolo de checkpointing coordenado, basta manter o último

checkpoint global gerado pela aplicação.

Mas podemos melhorar as propriedades de tolerância a falhas do mecanismo de armazenamento mantendo um número maior de checkpoints por aplicação. Durante o reinício de uma aplicação, caso não seja possível recuperar o último checkpoint global desta aplicação, por exemplo porque parte dos repositórios contendo fragmentos do checkpoint ficaram inacessíveis, pode-se utilizar um checkpoint anterior.

3.3 Implementação dos principais componentes 39