Sistemas Distribuídos Aula 15

Transcrição

1 Sistemas Distribuídos Aula 15 Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação - UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação - UFJF

2 8. Tolerância a Falha Sistemas Distribuídos: Msc. Daniele C. Oliveira 2

3 Comunicação Confiável Cliente-Servidor Falhas não atingem somente processos, mas também a comunicação entre eles Um canal de comunicação pode exibir falhas por queda, omissão, temporização e arbitrárias Na prática, ao se construir canais de comunicação confiáveis, o foco está em mascarar falhas por queda e omissão Sistemas Distribuídos: Msc. Daniele C. Oliveira 3

4 Comunicação Confiável Cliente-Servidor Comunicação ponto-a-ponto Quando um middleware de comunicação não é usado, a comunicação confiável em um SD pode ser estabelecida com a utilização de um protocolo de transporte confiável ex. TCP TCP mascara falhas por omissão mensagens perdidas reconhecimentos e retransmissões Sistemas Distribuídos: Msc. Daniele C. Oliveira 4

5 Comunicação Confiável Cliente-Servidor Comunicação ponto-a-ponto Falhas por queda não são mascaradas: conexão TCP é interrompida abruptamente de modo que nenhuma msg possa ser transmitida pelo canal Um SD pode mascarar tal falha, tentando uma nova conexão, com o reenvio de uma requisição de conexão Sistemas Distribuídos: Msc. Daniele C. Oliveira 5

6 Comunicação Confiável Cliente-Servidor Utilizando Middleware de Comunicação: RPC Objetivo da RPC é ocultar comunicação fazendo chamadas de procedimentos remotos parecerem chamadas locais Quando erros ocorrem, é difícil mascarar a diferença entre chamadas locais e remotas Vamos considerar algumas categorias de erros e possíveis soluções Sistemas Distribuídos: Msc. Daniele C. Oliveira 6

7 Comunicação Confiável Cliente-Servidor Falhas em RPC 1. Cliente não consegue localizar o servidor 2. A mensagem de requisição do cliente para o servidor se perde 3. O servidor cai após receber uma requisição 4. A mensagem de resposta do servidor para o cliente se perde 5. O cliente cai após enviar uma requisição Sistemas Distribuídos: Msc. Daniele C. Oliveira 7

8 Comunicação Confiável Cliente-Servidor Cliente não consegue localizar o servidor Possíveis problemas: 1. Servidores podem ter caído 2. Cliente pode ter sido compilado usando uma versão de apêndice antiga Solução: Ativar uma exceção acarreta em perda da transparência Sistemas Distribuídos: Msc. Daniele C. Oliveira 8

9 Comunicação Confiável Cliente-Servidor Mensagens de requisição perdidas Solução: Temporizador de espera para a mensagem de resposta servidor deverá reconhecer a mensagem original da mensagem de retransmissão Sistemas Distribuídos: Msc. Daniele C. Oliveira 9

10 Comunicação Confiável Cliente-Servidor Quedas de servidor Sistemas Distribuídos: Msc. Daniele C. Oliveira 10

11 Comunicação Confiável Cliente-Servidor Sistemas Distribuídos: Msc. Daniele C. Oliveira 11

12 Comunicação Confiável Cliente-Servidor Mensagens de respostas perdidas Problema: cliente não sabe com certeza por que não houve reposta. Requisição ou reposta que se perdeu ou servidor está lento? No caso de requisição idempotente: operações que podem ser repetidas sem causar nenhum dano. e.x leitura de arquivos retransmissão pode ser feita sem problemas a consistência do SD Sistemas Distribuídos: Msc. Daniele C. Oliveira 12

13 Comunicação Confiável Cliente-Servidor Mensagens de respostas perdidas E no caso de requisições não idempotentes? 1. Estruturar todas as requisições como idempotentes 2. Abordagem TCP-like, onde o cliente designa um número de sequência a cada requisição servidor deve manter informações de cada cliente Sistemas Distribuídos: Msc. Daniele C. Oliveira 13

14 Comunicação Confiável de Grupo Comunicação Multicast: mensagens são entregues a um grupo de processos No entanto, a comunicação multicast é bem complicada! Sistemas Distribuídos: Msc. Daniele C. Oliveira 14

15 Comunicação Confiável de Grupo Camadas de Transporte oferecem comunicação ponto-a-ponto confiável (TCP) Raro oferecer comunicação confiável a um conjunto de processos Possível solução: Estabelecer comunicações ponto-a-ponto entre os processos Problema: Desperdício de largura de banda de rede Sistemas Distribuídos: Msc. Daniele C. Oliveira 15

16 Comunicação Confiável de Grupo O que é multicast confiável? Significa que uma mensagem enviada a um grupo de processos deve ser entregue a cada membro do grupo O que ocorre se durante a comunicação um processo se juntar ao grupo? O que ocorre se um processo sair deste grupo? Sistemas Distribuídos: Msc. Daniele C. Oliveira 16

17 Comunicação Confiável de Grupo Para apresentar soluções vamos considerar dois cenários: 1. Processos estão funcionando corretamente e o grupo é estático 2. Processos falham! Sistemas Distribuídos: Msc. Daniele C. Oliveira 17

18 Comunicação Confiável de Grupo Cenário 1 Processos não falham e não se juntam ao grupo nem saem dele enquanto a comunicação está em curso Multicast confiável Toda mensagem deve ser entregue a cada membro do grupo no momento em questão Sistemas Distribuídos: Msc. Daniele C. Oliveira 18

19 Comunicação Confiável de Grupo Suposições 1. Consideremos o caso em que um único remetente queira enviar uma mensagem multicast a vários receptores. E.x: Algoritmo de Berkeley para sincronizar os relógios 2. Rede de Comunicação não confiável: mensagem multicast pode se perder em algum ponto do caminho e ser entregue a alguns, mas não a todos os receptores Sistemas Distribuídos: Msc. Daniele C. Oliveira 19

20 Comunicação Confiável de Grupo Solução 1 Cenário 1 1. Processo remetente designa um número de sequência a cada mensagem multicast 2. Mensagens são recebidas na ordem 3. Cada mensagem multicast é armazenada no remetente, em um buffer 4. Mensagem é mantida até receptores confirmem o recebimento 5. Retransmissão Reconhecimento negativo ou Timeout Sistemas Distribuídos: Msc. Daniele C. Oliveira 20

21 Comunicação Confiável de Grupo Solução 1 Cenário 1 Sistemas Distribuídos: Msc. Daniele C. Oliveira 21

22 Comunicação Confiável de Grupo Solução 1 Cenário 1 Questões! 1. Como reduzir o número de mensagens retornadas ao remetente? 2. Como fazer a retransmissão? Ponto-a-ponto ou novamente multicast 3. E a escalabilidade? Caso com N receptores, o remetente deve estar preparado para aceitar no mínimo N reconhecimentos IMPLOSÃO DE RETORNO Sistemas Distribuídos: Msc. Daniele C. Oliveira 22

23 Comunicação Confiável de Grupo Solução 2 Cenário 1 1. Receptores enviam mensagem de retorno somente para informar ao remetente a FALTA de uma mensagem 2. Retornar somente reconhecimentos negativos melhora a escalabilidade [Towsley et al 1997], mas não garante que implosões de retorno nunca acontecerão 3. Problema: Remetente será forçado a manter uma mensagem em seu buffer de histórico para sempre timeout para retirada da msg pode levar ao caso onde uma requisição pode não ser efetivada! Sistemas Distribuídos: Msc. Daniele C. Oliveira 23

24 Comunicação Confiável de Grupo Solução 3 Cenário 1 [Floyd et al, 1997] 1. Objetivo principal: Reduzir mensagens de retorno (supressão de retorno) 2. Utiliza o protocolo de multicast confiável escalável (SRM) 3. Somente reconhecimentos negativos são devolvidos como realimentação. Aplicação decide como detectar a perda de uma mensagem 4. Ao reconhecer que está faltando uma mensagem, receptor envia o pedido da mensagem perdida, usando multicast, ao resto do grupo Sistemas Distribuídos: Msc. Daniele C. Oliveira 24

25 Comunicação Confiável de Grupo Solução 3 Cenário 1 [Floyd et al, 1997] 5. Utilizar realimentação multicast permite que um outro membro do grupo suprima seu reconhecimento (realimentação) Suponha que vários receptores tenham percebido a falta da msg m Cada um deles precisará retornar um reconhecimento negativo ao remetente S, para retransmissão de m Se considerarmos que as retransmissões são enviadas ao grupo, basta uma única mensagem de requisição para que o pedido de retransmissão chegue até S Sistemas Distribuídos: Msc. Daniele C. Oliveira 25

26 Comunicação Confiável de Grupo Solução 3 Cenário 1 [Floyd et al, 1997] 5. Utilizar realimentação multicast permite que um outro membro do grupo suprima seu reconhecimento (realimentação) Um receptor R que não recebeu a msg m escalona uma msg de realimentação com certo atraso aleatório A requisição para retransmissão não é enviada até passar algum tempo aleatório Se um requisição de m chegar a R, antes do timeout, R não enviará a msg de realimentação negativa Espera-se que somente uma msg de pedido de retransmissão de m chegue a S Sistemas Distribuídos: Msc. Daniele C. Oliveira 26

27 Comunicação Confiável de Grupo Solução 3 Cenário 1 [Floyd et al, 1997] Aprimoramento: Permitir que um receptor tenha o papel de transmitir uma mensagem m, mesmo antes de a requisição de retransmissão chegar ao remetente original Sistemas Distribuídos: Msc. Daniele C. Oliveira 27

28 Comunicação Confiável de Grupo Solução 3 Cenário 1 [Floyd et al, 1997] Problemas Garantir que somente uma requisição de retransmissão chegue ao remetente S temporizadores? Interrupção dos processos os quais a msg já foi entregue separar os processos que não receberam m em um grupo separado (Kasera et al 1997) gerenciamento dos grupos! Reunir os processos em grupos que tendem a perder mensagens (Lui et al 1998) Sistemas Distribuídos: Msc. Daniele C. Oliveira 28

29 Comunicação Confiável de Grupo Solução 4 Cenário 1 Controle de Realimentação Hierárquico Único remetente Grupo é dividido em sub-grupos, organizados em árvore Cada sub-grupo possui um coordenador que gerencia os pedidos de retransmissão O coordenador possui um buffer para armazenar as msgs para atender pedidos dos membros do seu sub-grupo Problema: Manutenção da árvore Sistemas Distribuídos: Msc. Daniele C. Oliveira 29

30 Comunicação Confiável de Grupo Sistemas Distribuídos: Msc. Daniele C. Oliveira 30

31 Multicast Atômico Cenário 2 Suposição: Processos podem falhar! Deve-se chegar a um acordo sobre a real composição do grupo! Objetivo: Uma msg será entregue a todos os processos ou a nenhum deles. Mensagens são entregues na mesma ordem a todos os processos Atomicidade! Sistemas Distribuídos: Msc. Daniele C. Oliveira 31

32 Multicast Atômico Exemplo: Banco de Dados replicado Banco de dados é construído como um grupo de processos, um processo para cada réplica Operações de atualização são enviadas em multicast a todas as réplicas (multicast confiável na entrega destas operações!) Suponha que durante a execução de uma das atualizações de uma sequência, uma réplica caia Sistemas Distribuídos: Msc. Daniele C. Oliveira 32

33 Multicast Atômico Exemplo: Banco de dados replicado Se o sistema NÃO suporta multicast atômico Problema!!!!!!!!!! Réplica se recupera: essencial que seja atualizada em relação as outras réplicas Quais operações estão faltando e em que ordem devem ser executadas???? Sistemas Distribuídos: Msc. Daniele C. Oliveira 33

34 Multicast Atômico Exemplo: Banco de dados replicado Se o sistema suporta multicast atômico A operação de atualização que foi enviada a todas as réplicas um pouco antes de uma delas cair ou é executada em todas as réplicas não faltosas ou em nenhuma A atualização é realizada se as réplicas restantes concordarem que a réplica que caiu não pertence mais ao grupo Após a recuperação, a réplica é validada como sendo do grupo e recebe as atualizações Sistemas Distribuídos: Msc. Daniele C. Oliveira 34

35 Multicast Atômico Exemplo: Banco de dados replicado Se o sistema suporta multicast atômico multicast atômico garante que processos não faltosos mantenham uma visão consistente do banco de dados e força a reconciliação quando uma réplica se recupera e se junta ao grupo novamente. Sistemas Distribuídos: Msc. Daniele C. Oliveira 35

36 Multicast Atômico Sincronia Virtual Como implementar? Sistema distribuído possui uma camada de comunicação, que gerencia o recebimento das mensagens em um buffer local, até que possa ser entregue à aplicação Sistemas Distribuídos: Msc. Daniele C. Oliveira 36

37 Multicast Atômico Sincronia Virtual Como implementar? Uma mensagem m está associada com uma lista de processos aos quais deve ser entregue Lista de entrega corresponde a uma visão do grupo (conjunto de processos no grupo) Todos os processos possuem a mesma visão, concordando que m deve ser entregue a cada um deles e a nenhum outro processo Sistemas Distribuídos: Msc. Daniele C. Oliveira 37

38 Multicast Atômico Sincronia Virtual Suponha que a mensagem m seja enviada em multicast no instante que seu remetente tem visão de grupo G Se um processo entra ou sai do grupo, ocorre uma mudança de visão Duas mensagens: m e a de entrada/saída do novo processo (vc) Garantir que todos os processos em G recebam m antes de vc, evitando inconsistência Sistemas Distribuídos: Msc. Daniele C. Oliveira 38

39 Multicast Atômico Sincronia Virtual Multicast confiável garante que uma mensagem enviada em multicast para a visão de grupo G seja entregue a cada processo não faltoso em G Se o remetente cair durante o multicast, a mensagem pode ou ser entregue a todos os processos restantes ou ser ignorada por cada um deles multicast virtualmente síncrono (Birman e Joseph, 1987) Mensagens multicast ocorrem entre mudanças de visão Uma mudança de visão é considerada uma barreira pela qual nenhum multicast pode passar! Sistemas Distribuídos: Msc. Daniele C. Oliveira 39

40 Multicast Atômico Sincronia Virtual Sistemas Distribuídos: Msc. Daniele C. Oliveira 40

41 Multicast Atômico Ordenação de mensagens Tipos de ordenação das mensagens Multicasts não ordenados Multicasts ordenados em Fifo Multicasts ordenados por causalidade Multicasts totalmente ordenados Sistemas Distribuídos: Msc. Daniele C. Oliveira 41

42 Multicast Atômico Ordenação de mensagens Multicast confiável não ordenado Não são dadas garantias quanto à ordem na qual as mensagens recebidas são entregues aos diferentes processos Sistemas Distribuídos: Msc. Daniele C. Oliveira 42

43 Multicast Atômico Ordenação de mensagens Multicast confiável ordenado em Fifo Camada de comunicação é forçada a entregar as mensagens que chegam do mesmo processo na mesma ordem em que elas foram enviadas Sistemas Distribuídos: Msc. Daniele C. Oliveira 43

44 Multicast Atômico Ordenação de mensagens Multicast confiável ordenado por causalidade Entrega de mensagens de modo que a potencial causalidade entre mensagens diferentes seja preservada Se m 1 precede uma outra mensagem m 2 por causalidade, independentemente de terem sido enviadas por processos diferentes, camada de aplicação sempre entregará m 2 após ter recebido e entregado m 1 Utilização de relógios vetoriais Sistemas Distribuídos: Msc. Daniele C. Oliveira 44

45 Multicast Atômico Ordenação de mensagens Multicast confiável com entrega totalmente ordenada Significa que as mensagens devem ser entregues na mesma ordem a todos os membros do grupo Entregas podem ser dos tipos não ordenada, ordenada em Fifo ou ordenada por causalidade Sistemas Distribuídos: Msc. Daniele C. Oliveira 45

46 Multicast Atômico Ordenação de mensagens Sistemas Distribuídos: Msc. Daniele C. Oliveira 46

47 Recuperação Essência: Quando ocorre uma falha no sistema, é necessário levar o sistema para um estado livre de erro Recuperação de um erro é fundamental em tolerância a falhas Sistemas Distribuídos: Msc. Daniele C. Oliveira 47

48 Estratégias para Recuperação Duas formas principais: Recuperação retroativa: Retorna o sistema a algum estado que antes estava correto, continuando a execução após a recuperação. Mecanismo de ponto de verificação (estado presente do sistema é registrado) Recuperação para frente: Tentativa de levar o sistema para um próximo estado correto. Sistemas Distribuídos: Msc. Daniele C. Oliveira 48

49 Estratégias para Recuperação 1. Recuperação retroativa: Comunicação multicast confiável retransmissão de pacote 2. Recuperação para frente: recuperação de pacotes a partir de outros pacotes (FEC) Sistemas Distribuídos: Msc. Daniele C. Oliveira 49

50 Estratégias para Recuperação Desvantagem da recuperação para frente: É preciso saber de antemão quais erros podem ocorrer. Tendo conhecimento de todos os erros e como levar o sistema para um estado correto, é possível recuperar totalmente o sistema. Sistemas Distribuídos: Msc. Daniele C. Oliveira 50

51 Estratégias para Recuperação Desvantagens da recuperação retroativa: 1. Pontos de validação podem ser caros para serem implementados 2. Não existem garantias que o erro não acontecerá novamente 3. Em alguns casos não é possível retroagir a um estado sem erros (ex. comando rm -rf *!!) Sistemas Distribuídos: Msc. Daniele C. Oliveira 51

52 Recuperação Retroativa e Registro de mensagens Ideia principal: Combinar pontos de verificação com o registro da sequência de mensagens recebidas 1. O processo receptor registra uma mensagem antes de entregá-la a aplicação (ou então, o emissor registra as msgs antes de enviá-las) 2. Quando um processo cai, o sistema é restaurado para o estado correspondente ao ponto de verificação mais recente e, a partir deste ponto, reproduz as mensagens recebidas Sistemas Distribuídos: Msc. Daniele C. Oliveira 52

53 Recuperação Retroativa e Registro de mensagens Qual a diferença entre utilizar apenas pontos de verificação e pontos de verificação + registro de mensagens? 1. No caso do uso isolado de pontos de verificação, os processos são restaurados para o ponto antes da falha e o comportamento pode ser diferente após a recuperação (ex. msgs podem ser entregues em ordenação diferente) 2. No caso do registro de mensagens, o comportamento é reproduzido do mesmo modo entre o ponto de recuperação e o ponto em que ocorreu a falha Sistemas Distribuídos: Msc. Daniele C. Oliveira 53

54 Pontos de Verificação A recuperação retroativa de erros requer que o sistema salve periodicamente seu estado em armazenamento estável Fotografia Distribuída: Registro de um estado global consistente Em uma fotografia distribuída, se um processo P tiver registrado o recebimento de uma mensagem, então também deve existir um processo Q que registrou o envio dessa mensagem Sistemas Distribuídos: Msc. Daniele C. Oliveira 54

55 Pontos de Verificação Em linhas gerais... Cada processo salva seu estado periodicamente em um armazenamento estável disponível localmente. A recuperação após uma falha de processo ou de sistema requer a construção de um estado global consistente com base nesses estados locais Melhor alternativa é recuperar a fotografia mais recente, denominada linha de recuperação mais recente conjunto consistente de pontos de verificação Sistemas Distribuídos: Msc. Daniele C. Oliveira 55

56 Pontos de Verificação Independentes Descobrir uma linha de recuperação requer que cada processo seja revertido a seu estado salvo mais recente Se, em conjunto, os estados locais não formam uma fotografia distribuída, é preciso reverter ainda mais para trás. O processo de reversão em cascata pode resultar no efeito dominó Sistemas Distribuídos: Msc. Daniele C. Oliveira 56

57 Pontos de Verificação Independentes Sistemas Distribuídos: Msc. Daniele C. Oliveira 57

58 Pontos de Verificação Coordenados Todos os processos sincronizam para escrever, em conjunto, seu estado para armazenamento local O estado salvo é globalmente consistente, evitando as reversões em cascata que levam ao efeito dominó Sistemas Distribuídos: Msc. Daniele C. Oliveira 58

59 Pontos de Verificação Coordenados Solução Simples: Usar protocolo de bloqueio de duas fases 1. Coordenador envia uma msg multicast CHECKPOINT_REQUEST a todos os processos 2. Quando o processo recebe esta mensagem, estabelece um ponto de verificação local e enfileira qualquer msg e envia uma mensagem de reconhecimento ao coordenador indicando que estabeleceu o ponto de verificação 3. Após receber todos os acks, coordenador envia msg multicast CHECKPOINT_DONE para desbloquear os processos Sistemas Distribuídos: Msc. Daniele C. Oliveira 59

60 Pontos de Verificação Coordenados Estado globalmente consistente: Não existirão mensagens que ultrapassem as linhas de recuperação, ou seja, a mensagens são tratadas entre os pontos de verificação Qualquer mensagem que vier após uma requisição para estabelecer um ponto de verificação não é considerada como parte do ponto de verificação local. Ao mesmo tempo, mensagens que estão saindo são enfileiradas no local até a mensagem CHECKPOINT_DONE ser recebida Sistemas Distribuídos: Msc. Daniele C. Oliveira 60

61 Fim da Aula 15. Sistemas Distribuídos: Msc. Daniele C. Oliveira 61