Universidade da Beira Interior

Universidade da Beira Interior

Fiabilidade de Sistemas Informáticos

Nuno Magarreiro n.º 14805

Processos Recuperáveis

Índice: Introdução

Resilient Remote Procedure Call (RPC recuperável) Primary Site Approach Invocação replicada Uma abordagem mista

Execução sem falhas Execução com falhas

Introdução

Numa aplicação distribuída, onde vários processos trabalham em conjunto para elaborar uma tarefa, se um nó falha, os processos que estão a executar nesse nó deixam de estar disponíveis.

Isto pode causar a falha de toda a computação distribuída.

O objectivo dos processos recuperáveis é assegurar que a computação distribuída continua a executar mesmo depois das falhas de alguns processos.

Sem processos recuperáveis o sistema teria que ser reiniciado, o que não é aceitável em aplicações críticas.

Introdução Vai-se assumir que os nós são fail stop e que os

processos são determinísticos.

Pode ser usado um método baseado em checkpoints para suportar processos recuperáveis. Neste método são criados checkpoints do sistema distribuído e estes são guardados em memória estável.

Assim, se algum nó falhar, todo o sistema volta atrás para o último checkpoint global.

Os métodos que vão ser considerados posteriormente não precisam de checkpoints globais e não obrigam todos os processos a voltar a um estado antigo quando ocorrem erros.

Introdução

Se o sistema consiste em processos que não comunicam uns com os outros, o problema é simples.

Para cada processo é criado um checkpoint periodicamente, e, se o processo falhar, este é restaurado para o estado em que se encontrava na altura do último checkpoint. Apenas o processo que falhou precisa de voltar a um estado antigo.

Esta abordagem simples para suportar processos recuperáveis é, claramente, insuficiente em sistemas onde os processos comunicam uns com os outros.

Resilient Remote Procedure Call (RPC recuperável)

Um processo que é executado num nó pode invocar um procedimento que é executado noutro nó.

Quando um procedimento “A” chama um procedimento “B”, o “A” é chamado de “direct caller” do “B”.

Tipicamente, o procedimento “A” fica suspenso até receber a informação de que pode continuar a executar.

Desde que dois processos estejam envolvidos na computação, pode ocorrer uma falha numa parte da computação devido á falha de um dos nós.

Resilient Remote Procedure Call (RPC recuperável)

Especificamente, é possível que o nó que está a executar o procedimento remoto falhe, o que manterá o procedimento que o chamou suspenso para sempre.

Similarmente, o direct caller pode falhar, ficando-se na situação em que o procedimento remoto fica sem ligação ao processo para o qual deveria devolver os resultados.

O objectivo dos esquemas aqui apresentados é tornar a computação baseada em RPC resistente a falhas de nós.

Primary Site Approach

Esta abordagem usa processos pares para suportar resiliência.

Um dos processos é o primário e o outro é o backup.

Quando um serviço é pedido, a mensagem primeiro é enviada para o processo primário. Se este processo não existir, a mensagem falha e o pedido é enviado para o segundo processo.

Quando o processo primário recebe o pedido para uma operação, ele actualiza o seu checkpoint enviando uma mensagem para o processo backup.

Primary Site Approach

Esta mensagem assegura que o backup tem toda a informação e que se o processo primário falhar, o backup consegue satisfazer o pedido.

Invocação replicada

Outro método para tornar uma invocação remota de procedimentos resistente a falhas de nós é replicar os procedimentos remotos em vários nós e, quando um procedimento remoto é chamado, todas as réplicas são executadas simultaneamente.

Neste método, um módulo é replicado em vários nós. O conjunto das réplicas dum módulo é chamado de troupe.

Sempre que uma invocação é feita a um módulo, todos os membros da troupe executam o pedido.

Invocação replicada

A troupe do módulo que faz a invocação dum procedimento remoto é chamada de client troupe, e a troupe do módulo para o qual a invocação é feita é chamada de server troupe.

Quando um módulo faz uma invocação para um módulo remoto, cada membro da client troupe faz uma invocação para todos os elementos do server troupe.

Assim, cada membro da server troupe obtém múltiplas cópias do pedido e envia a resposta ao pedido para todos os elementos da client troupe.

Invocação replicada

A semântica desejada é que, para cada membro do server troupe o pedido seja efectuado apenas uma vez, e cada membro da client troupe receba todos os resultados.

Estas semânticas são chamadas “exactly-once execution of all troupe members”.

Isto acontece porque os módulos são determinísticos.

Isto garante que cada membro da server troupe vai executar a instrução e também que será necessário o uso de números de sequência.

Invocação replicada

Um membro da client troupe tem de esperar por todas as respostas antes de continuar a sua execução. Claro que, se esse membro for informado da falha dum nó da server troupe, ele não esperará mais tempo pela mensagem desse nó.

A client troupe espera por todas as mensagens de volta. Isto proporciona aos membros da client troupe um método para detectar erros e consegui-los corrigir, desde que cada membro possa “votar” nos resultados.

Por outro lado, isto implica que a resposta vai ser tão lenta quanto o membro mais lento da server troupe.

Invocação replicada

Se a detecção e correcção de erros não forem desejadas deve ser usada a abordagem first-come em que cada membro da client troupe continua a executar assim que recebe a primeira mensagem.

Mais uma vez, isto requer o uso de números de sequência para que as mensagens de novas invocações possam ser distinguidas das mensagens de invocações anteriores.

É claro que com este método de replicação é fácil esconder falhas de nós, desde que não falhem todos os elementos da troupe.

Invocação replicada

Este método é um pouco caro em termos de número de mensagens.

Se a client troupe possui m membros e a serve troupe contém n membros, então o número total de mensagens necessárias é O(m*n).

Por outro lado, se a rede suportar multicasting, em que, no envio de uma mensagem esta pode ser enviada para vários destinos, então serão necessárias apenas O(m+n) mensagens.

Uma abordagem mista

Agora vai-se descrever um método que utiliza uma combinação entre a Replicated call e a Primary site approach.

No esquema proposto, a tolerância a falhas é fornecida através da existência de cópias dos procedimentos em vários nós.

Cópias de procedimentos juntas são chamadas de clusters.

As cópias estão organizadas numa cadeia linear. Para a i-ésima cópia, a cópia (i+1) é o seu backup.

Uma abordagem mista

O pedido é feito para a primeira cópia, que é a primeira cópia que não falhou de toda a cadeia.

A primeira cópia envia a invocação para o seu backup, que também envia a invocação para o seu backup. Desta maneira todas as cópias são invocadas.

O resultado da cópia é enviado para o cliente através da cópia primária. Se a primeira falhar, o seu backup assume o papel da primária e responde para o cliente.

Uma abordagem mista

Apenas a cópia primária irá realmente fazer a invocação; as outras cópias que fazem invocações apenas esperam pelo resultado.

O resultado recebido pela primeira é propagado para todas as cópias que fazem invocações. Se a cópia primária falhar no reconhecimento do resultado, outra cópia do resultado deve ser enviada para a sua cópia backup.

Existem quatro tipos de mensagens para o esquema proposto:

Call message, result message, done message e ack message

Uma abordagem mista

Se não se receber a mensagem de reconhecimento num intervalo de tempo definido, o processo que está a enviar a mensagem verifica o estado do processo que está a recebê-la.

Se este falhar, a mesma mensagem será enviada para o backup deste receptor.

Estas simples operações ajudam a assegurar que todas as cópias no cluster receberão a mesma mensagem no caso da ocorrência de erros.

Uma abordagem mista

Execução sem falhas

Neste esquema as cópias secundárias têm um papel activo.

Todas as cópias no cluster que é chamado executam a invocação, e todas as cópias no cluster que faz a invocação recebem a cópia do resultado.

Mesmo assim, desde que a primeira cópia que recebe a invocação não falhe, a cópia que fez a invocação faz uma invocação simples e apenas uma cópia do resultado é enviada para o cluster que efectuou a invocação.

Todas as comunicações entre os clusters são suportadas pelas suas cópias primárias.

Uma abordagem mista

Execução com falhas

Depois de enviar uma invocação RPC para o receptor primário, a cópia que efectuou o pedido espera pela ack message.

Se, o tempo limite para mensagem ser recebida for atingido, a cópia que fez a invocação envia a mesma mensagem para o backup.

Se o backup já tiver recebido uma mensagem igual da antiga cópia primária, ele reconhece a mensagem mas ignora-a.

Uma abordagem mista

Execução com falhas

Se a cópia primária que recebeu a invocação falhar depois de ter enviado os resultados mas antes de enviar a done message para a cópia secundária, a cópia que efectuou a invocação poderá receber mais do que uma mensagem com os mesmos resultados. A cópia primária que efectuou o pedido reconhece a mensagem duplicada mas ignora-a.