Sistemas Distribuídos e Paralelos

(1)

Sistemas Distribuídos e Paralelos

Tolerância a Falhas

Ricardo Mendão Silva Universidade Autónoma de Lisboa

r.m.silva@ieee.org

(2)

Outline

1 _Introdução Conceitos Básicos Modelos de Falhas Mascarar falhas 2 Resiliência de processos Mascarar falhas e replicação Acordo no sistema de faltas

3 Detecção de falhas

(3)

Tolerância a Falhas

Introdução

Uma característica chave dos sistemas distribuídos é a introdução do conceito de falha parcial.

A falha num elemento do sistema distribuído afecta somente esse elemento, podendo ou não afectar o serviço.

Este ponto contrasta claramente com os sistemas não distribuídos, onde uma falha invalida todo o serviço.

Um dos objectivos dos SD é desenhar os sistemas de modo a que estes tenham a capacidade de recuperar automaticamente de falhas parciais.

Quando uma falha parcial ocorre, deve ser possível manter o serviço a funcionar devidamente, enquanto a falha é reparada, ou seja, o serviço deve ser tolerante a faltas.

(4)

Tolerância a Falhas

Introdução

Tolerância a faltas tem sido um tema maior de investigação em ciências da computação.

Neste capítulo vamos começar por abordar falhas de processos e modelos de falhas.

Vamos abordar também mecanismos de redundância, que são a técnica chave para lidar com falhas.

(5)

Tolerância a Falhas

Conceitos Básicos

Um sistema distribuído tolerante a faltas é um sistema fidedigno, cujo conceito de confiança abrange as seguintes características:

Disponibilidade Fiabilidade Segurança

Capacidade de manutenção

Uma falha ocorre sempre que um sistema não consegue cumprir com o que foi estipulado.

Um erro é uma parte do estado do sistema que pode levar a uma falha.

(6)

Tolerância a Falhas

Conceitos Básicos

Exemplo:

Quando se transmitem pacotes através da Internet, é comum que alguns pacotes cheguem danificados.

Danificados, significa que pelo menos ocorreu uma troca de bits (recebeu 0 em vez de 1).

Determinar o que causou o erro é deveras importante. Neste exemplo, a justificação do erro poderá facilmente estar relacionada com problemas no meio de transmissão, que com pouco esforço podem ser resolvidos.

Porém, o mesmo erro pode dever-se a questões meteorológicas e nesse caso já não há como controlar.

(7)

Tolerância a Falhas

Conceitos Básicos

Um sistema ser tolerante a faltas, significa que o sistemas pode tolerar faltas e continuar a operar.

As faltas são normalmente classificadas como:

Faltas transitórias - Faltas transitórias são faltas que ocorrem uma

vez e desaparecem. Mesmo que a operação se repita, a falta não volta a ocorrer.

Faltas intermitentes - Faltas intermitentes são faltas que ocorrem,

que desaparecem por si mesmas, que voltam a reaparecer, e assim sucessivamente.

Por exemplo, um mau contacto de um conector pode provocar faltas intermitentes.

Dada a natureza aleatória, estas faltas são extremamente difíceis de diagnosticar.

Faltas permanentes - Uma falta permanentes é uma falta que

continua a existir até o componente em questão ser substituído.

(8)

Tolerância a Falhas

Modelos de Falhas

Para melhor compreender o quão sério uma falha é, têm surgido diversas classificações, tais como:

Tipo de falha Descrição

Falha de crash Um servidor está a operar correctamente até parar. Falhas omissas Um servidor falha na reposta a pedidos.

Omissão na re-cepção

Um servidor falha na recepção de mensagens. Omissão no envio Um servidor falha no envio de mensagens.

Falhas temporais A resposta do servidor encontra-se fora do inter-valo de tempo especificado.

Falhas na resposta A resposta do servidor é incorrecta. Falha de valor O valor de resposta é errado. Falha na transição

de estado

O servidor desvia-se do fluxo de controlo correcto. Falhas arbitrárias

(Bizantinas)

Um servidor produz respostas arbitrárias em tem-pos arbitrários.

(9)

Tolerância a Falhas

Mascarar falhas

Se um sistema é tolerante a falhas, o melhor que pode fazer é esconder a ocorrência de falhas dos outros processos.

A técnica chave para mascarar faltas é o uso de redundância, baseada em três tipos:

Redundância da informação Redundância no tempo Redundância física

Com redundância de informação, adicionam-se, por exemplo, bits extra na transmissão que permitem recuperar informação em caso de erros (ex: código de Hamming).

Com redundância no tempo, uma acção pode ser executada uma vez e executada novamente mais tarde.

Com redundância física, adiciona-se hardware e/ou processos extra de modo a que o sistema fique realmente tolerante à falha de

(10)

Outline

(11)

Resiliência de processos

Grupos de processos

Um ponto de chave na tolerância de processos faltosos é a organização de processos idênticos em grupos.

Sempre que se envia uma mensagem para o grupo, todos os membros do grupo recebem essa mensagem.

Assim, se um processo num grupo falha, outros processos desse grupo podem tomar o controlo da acção.

(12)

Resiliência de processos

Grupos de processos

O agrupamento de processos pode ser dinâmico, ou seja, novos grupos podem ser criados enquanto grupos antigos destruídos. Do mesmo modo, um processo pode-se juntar ou deixar um grupo durante uma operação.

Um processo pode ser membro de mais do que um grupo ao mesmo tempo.

Assim, são necessários mecanismos para gerir grupos e filiações.

(13)

Resiliência de processos

Grupos de processos

A razão para introduzir grupos é a de permitir os processos de lidarem com colecções de processos de modo abstracto.

Assim, um processo pode enviar uma mensagem para um grupo de servidores sem ter de saber quem são, quantos são e onde estão.

(14)

Resiliência de processos

Flat vs Hierárquico

Uma distinção importante prende-se com a estrutura interna dos grupos.

Há grupos onde todos os processos são iguais, e todas as decisões são tomadas colectivamente.

Por sua vez, outros grupos apresentam uma estrutura hierárquica, com, por exemplo, um processo coordenador e os restantes trabalhadores.

(15)

Resiliência de processos

Flat vs Hierárquico

Cada uma dessas estruturas tem vantagens e desvantagens:

Os grupos flat são simétricos e não têm um único ponto de falha. Caso um processo falhe, o grupo simplesmente fica mais pequeno, mas continua a operar.

Porém, os grupos flat apresentam a desvantagem de que a tomada de decisão é mais complicada. Por exemplo, para qualquer decisão, é necessário uma votação, o que introduz um atraso na resposta.

Por sua vez, os grupos hierárquicos são o oposto.

A perda do nó coordenador levam à perda de todo o grupo.

No entanto, enquanto estiver operacional, as tomadas de decisão são mais rápidas, sem necessitar de incomodar outros processos.

(16)

Resiliência de processos

Filiação em grupos

Quando existe comunicação em grupo, são necessários mecanismos para criação e remoção de grupos, bem como para adição e remoção de processos desses grupos.

Uma abordagem possível é ter um servidor de grupos para onde todos os pedidos podem ser enviados.

O servidor de grupo é assim capaz de manter uma base de dados completa de todos os grupos e as filiações exactas.

Esse método é rápido e fácil de implementar, no entanto um servidor único representa um ponto de falha critico.

(17)

Resiliência de processos

Filiação em grupos

Uma outra abordagem é gerir as filiações em grupos de modo distribuído.

Deste modo, torna-se necessário enviar uma mensagem join, para juntar ao grupoe uma mensagem leave para deixar o grupo,a todos os membros do grupo .

Este método no entanto, pode apresentar problemas de concorrência, de modo a que um nó que se acabou de juntar ao grupo ainda não está a receber mensagens de aplicação, enquanto que um nó que já pediu para sair, continua a receber mensagens destinadas ao grupo, ao qual já não pertence.

(18)

Resiliência de processos

Mascarar falhas e replicação

Grupos de processos são parte da solução para construir um sistema tolerante a falhas.

Termos um grupo de processos idênticos permite mascarar um ou mais processos faltosos nesse grupo.

Por outras palavras, podemos replicar processos e organiza-los em grupo, substituindo uma única instância por um grupo constituído por n-instâncias.

(19)

Resiliência de processos

Existem duas abordagens para efectuar a replicação de processos, nomeadamente:

protocolos primários - um grupo de processos é organizado de modo

hierárquico, com um processo primário a coordenar todas as operações de escrita.Neste caso, existem processos backup do processo primário, que assumem a coordenação, caso o primário crashe.

protocolos de escrita replicada - um grupo de processos é

organizado numa estrutura flat, com a vantagem de não apresentar qualquer ponto de fraqueza.

(20)

Resiliência de processos

Um ponto bastante importante no uso de grupos de processos na tolerância a faltas assenta em saber a quantidade de replicação necessária.

Um sistema é dito de ser k tolerante a faltas se conseguir sobreviver a faltas em k componentes e continue a suportar as especificações. Se tivermos k+1 processos num grupo flat e k processos parem, ainda resta um processo para garantir o serviço.

Por outro lado, se as falhas forem Bizantinas, continuando os processos em execução mesmo que a enviar dados erróneos e

aleatórios, são necessários pelo menos 2k+1 processos para alcançar k tolerância a faltas.

Apesar de toda esta teoria, nada garante que k+1 processos também não falham, o que eleva a definição de k para o domínio da estatística. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, 2015 20 / 29

(21)

Resiliência de processos

Acordo no sistema de faltas

Organizar processos replicados em grupos, ajuda a aumentar a tolerância a faltas.

No entanto, tem de haver garantias de que os processos estão a dar respostas fidedignas e que não actuam em equipa, produzindo escritas erróneas e combinadas.

De modo geral, é requerido que um grupo de processos chegue a acordo acerca de uma resposta, utilizando, por exemplo, a eleição de um coordenador, decidindo se é feito o commit de uma transacção, dividindo tarefas entre processos e sincronização, entre outras possibilidades.

Quando a comunicação e os processos estão em perfeitas condições, alcançar tais acordos é fácil. No entanto, quando a comunicação e/ou os processos têm falhas, o mesmo é extremamente complicado.

(22)

Resiliência de processos

Neste âmbito, surgem os algoritmos de acordo distribuído, cujo objectivo é que todos os processos sem-faltas alcancem consenso em determinados assuntos.

Este problema torna-se complexo, porque diferentes suposições acerca dos sistemas subjacentes requerem diferentes soluções, destacando os seguintes casos:

1 _{Sistemas síncronos vs assíncronos - um sistema é dito síncrono} desde que opere em lock-step, ou seja, se o processo dá 1 passo, todos os outros darão um passo.

2 Comunicação limitada - a comunicação é limitada se as mensagens tiverem um tempo máximo de entrega predefinido.

3 _{Entrega das mensagens em ordem - se as mensagens enviadas por} um transmissor são entregues pela mesma ordem de envio (nos casos do protocolo não dar tais garantias).

4 _{Multicast vs Unicast - se a transmissão de mensagens é realizada via} multicast ou unicast.

(23)

Resiliência de processos

Regra geral, a maioria dos sistemas distribuídos assume que os processos são assíncronos, as mensagens transmitidas em unicast e que a comunicação não é limitada. Como consequência torna-se necessário utilizar protocolos, como o TCP, que garantam a ordem das mensagens.

(24)

Outline

(25)

Detecção de falhas

Para mascarar uma falha, é necessário que a mesma seja primeiramente detectada.

A detecção de falhas é um dos pontos críticos da tolerância a falhas nos sistemas distribuídos.

Para um grupo de processos, membros sem-faltas devem ser capazes de decidir quem continua a ser membro e quem já não o é, ou seja, devem conseguir detectar os membros que falharam.

Na prática existem apenas dois métodos para detectar que os processos falham:

1 _{cada processo envia periodicamente mensagens de KEEP_ALIVE.} 2 _{cada processo espera passivamente por mensagens de outros processos.}

(26)

Detecção de falhas

Têm existido inúmeros trabalhos publicados que abordam a detecção de falhas, na sua maioria apresentando mecanismos de verificação de falhas baseados em timeouts.

Este método tem um problema, pois apesar de não se obter resposta atempada a um ping, pode não significar que o processo parou. Podemos simplesmente estar perante um problema de rede. Outras soluções têm surgido, baseadas nos periódicos

KEEP_ALIVES, na troca periódica de informação entre processos vizinhos ou ainda na disseminação gradual de informação.

(27)

Detecção de falhas

Outro ponto fundamental que os sistemas de detecção de falhas devem suportar, é a distinção entre falhas da rede e falhas dos nós. Uma forma de lidar com esta questão é não permitir que um simples nó decida se o seu vizinhou parou ou não.

Idealmente, quando o nó A detecta um timeout num ping ao nó B, deve questionar se os nós vizinhos notaram o mesmo comportamento. Caso a maioria dos nós vizinhos tenha obtido também um timeout em relação ao nó B, é então acordado que este falhou.

Removido o nó B, outros nós sem-faltas, não envolvidos, devem ser notificados. E ai temos um novo problema.

(28)

Sistemas de Ficheiros Distribuídos

Capítulo 8: Tanenbaum, A.S., Van Steen, M., (2006) Distributed Systems: Principles and Paradigms (2nd Edition), Prentice Hall, ISBN-13: 978-0132392273

rmsilva@ual.pt

(29)

Sistemas Distribuídos e Paralelos