Universidade da Beira Interior

1. Universidade da Beira Interior Fiabilidade de Sistemas Informáticos Nuno Magarreiro n.º 14805

2. 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

3. 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áveiso sistema teria que ser reiniciado, o que não é aceitável em aplicações críticas.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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

19. 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.

20. 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.

21. 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.

22. 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.