Sistemas Distribuídos e Paralelos

Transcrição

1 Sistemas Distribuídos e Paralelos Tolerância a Falhas Ricardo Mendão Silva Universidade Autónoma de Lisboa r.m.silva@ieee.org January 14, 2015 Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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 Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. A causa de um erro denomina-se falta. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Chips queimados, bugs de software, cabeças de discos danificadas, etc... Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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 recepçã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 intervalo de tempo especificado. Falhas na resposta A resposta do servidor é incorrecta. Falha de valor O valor de resposta é errado. Falha na transição O servidor desvia-se do fluxo de controlo correcto. de estado Falhas arbitrárias Um servidor produz respostas arbitrárias em tempos (Bizantinas) arbitrários. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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 componentes. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

19 Resiliência de processos Mascarar falhas e replicação 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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

20 Resiliência de processos Mascarar falhas e replicação 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, / 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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

22 Resiliência de processos Acordo no sistema de faltas 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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

23 Resiliência de processos Acordo no sistema de faltas 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. A figura seguinte resume os casos em que é possível acordo: Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

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: Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29

29 Nem sempre só a organização e a metodologia levam ao sucesso Comunicação Trabalho em Equipa Creatividade Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos January 14, / 29