Falhas Bizantinas. Filipe Palma, Jonathan Nau, Liliana Semedo e Luís Rodrigues RESUMO ABSTRACT II. LESLEI LAMPORT I. INTRODUÇÃO

Transcrição

1 1 Falhas Bizantinas Filipe Palma, Jonathan Nau, Liliana Semedo e Luís Rodrigues RESUMO Implementar serviços confiáveis num sistema distribuído, onde cada máquina pode entrar e sair da rede aleatoriamente é uma tarefa de grande responsabilidade. Neste contexto, um aspecto de extrema importância, é deveras a segurança. Os detectores de falhas bizantinas (ou arbitrárias) permitem resolver problemas de segurança, uma vez que separam o tratamento das falhas do protocolo distribuído que os utiliza. Leslei Lamport investigou e resolveu diversos problemas de computação de grande importância da actualidade, sendo um contributo considerável nesta área. Neste artigo estudamos as falhas bizantinas e os mecanismos associados na detecção de erros recorrendo a pesquisas feitas por Leslei Lamport. Palavras-chave: Leslei Lamport, falhas bizantinas, acordo bizantino, tolerância a falhas. ABSTRACT Implementing dependable services in a distributed system, where each machine can enter and leave the network randomly is a very responsible task. In this context, an aspect of great importance, is indeed security. The Byzantine fault detectors (or arbitrary) allow to solve security problems, since separate treatment of the distributed fault protocol that uses them. Leslei Lamport investigated and resolved many computing issues of great importance of today, being a considerable contribution in this area. We study the Byzantine failures and the mechanisms associated with the error detection using the research by Leslei Lamport. Keywords: Leslei Lamport, byzantine failure, byzantine agreement, fault tolerance. F I. INTRODUÇÃO ALHAS BIZANTINAS foi uma das investigações feitas por Leslei Lamport quando ele tratava de procurar solução para problemas comuns do dia-a-dia, como o problema da padaria entre outros. As suas pesquisas começaram por pequenas situações reais observadas por Leslei. Um sistema distribuído é constituído por vários computadores em rede que podem, a qualquer momento da execução do sistema, ficar indisponíveis. As características comuns de um sistema distribuído são: imprevisibilidade da latência na transmissão das mensagens, a rede não estar totalmente conectada, não existem elementos centralizados na rede, não ser possível prover aos processos uma visão global da topologia da rede, de maneira que cada computador tem um conhecimento parcial do sistema e, os postos podem alterar a sua posição quanto à topologia da rede. Um factor preocupante nos sistemas distribuídos é a segurança. O facto de estes sistemas serem compostos por vários postos em rede, comunicando entre si através da internet e das redes sem fios de forma dinâmica, estes são susceptíveis a intrusões maliciosas que podem comprometer todo o sistema. O modelo de falhas bizantinas lida com este tipo de problemas ao considerar a existência de processos corruptos, que podem agir de maneira arbitrária na tentativa de impedir que o sistema funcione dentro da normalidade. Um processo bizantino pode, por exemplo, tentar assumir a identidade de outro, enviar mensagens com valores incorrectos, duplicar mensagens ou simplesmente não enviar mensagens que o protocolo em execução especificar. O desenvolvimento de sistemas tolerantes a faltas bizantinas, isto é, que mantenham o seu funcionamento correcto apesar do comportamento maligno de alguns de seus processos, é portanto de especial interesse. Este artigo apresenta um estudo às falhas bizantinas, ao seu mecanismo e uma referência a Leslei Lamport pela dedicação no estudo destes problemas, que sem a sua contribuição não estaríamos neste ponto. II. LESLEI LAMPORT Leslie Lamport nascido em 1941, é um cientista computacional norte-americano. Formou-se em matemática pela Massachutsetts institute of technology em 1960, e completou o mestrado e doutorado pela Universidade Brandeis, concluídos respetivamente em 1963 e Ele começou a sua carreira como cientista computacional no Massachusetts Computer Associates, SRI Internacional, Digital e Compaq. Em 2001, ele

2 2 juntou-se à Microsoft Research em Mountain View na Califórnia. Suas pesquisas contribuíram com a fundação da teoria de sistemas distribuídos. Alguns dos seus mais notáveis papéis nesta área são os seguintes: "Time, Clocks, and Ordering of events in a Distributed System" "Distributed snapshots: determining global states of distributed systems" " The Byzantine Generals Problem" "The Part-time Parliament" Os seus artigos introduziram novos conceitos na ciência computacional e descrevem algoritmos para a resolução de muitos problemas fundamentais em sistemas distribuídos. Lamport também é conhecido por ter ajudado a desenvolver LaTeX, o software de composição e linguagem de marcação amplamente usado nas ciências. Lamport recebeu quatro títulos de Doutor 'Honoris Causa' por universidades europeias: Universidade de Rennes e Universidade Christian Albrechts de Kiel em 2003, EPFL em 2004, University of Lugano em Em 2004 ele também recebeu o IEEE Piore Award e em 2013 recebeu o prémio Turing [2]. Com a crescente mudança para sistemas cada vez maiores de escala distribuídos e computação em nuvem, o trabalho de Lamport assumiu um aumento significativo de impacto. Os seus resultados têm beneficiado muitas comunidades de pesquisa, incluindo aqueles em sistemas paralelos e de alto desempenho de computação, algoritmos simultâneos e confiabilidade do software. E além disso, o seu trabalho tem tido implicações não apenas na comunidade teórica, mas também com os engenheiros e programadores a projetar e implementar muitos tipos de sistemas. III. CONTRIBUIÇÕES Vencedor do prémio Turing ACM Award (Turing Association for Computing Machinery), Leslie Lamport deu o seu contributo para evolução da computação distribuída lançando muitos algoritmos, como por exemplo os seguintes: Time, Clocks, and Ordering of events in a Distributed systems, algoritmo que gere a ordenação de eventos em sistemas distribuídos; How to Make a Correct Multiprocess Program Execute Correctly on a Multiprocessor, um algoritmo que permite a computação simultânea de vários processos; Sequential Consistency algoritmo que dá a garantia que todos os nós de um sistema veem as operações de escrita na mesma ordem embora esta possa ser diferente da definida em tempo real; The Byzantine Generals Problem, algoritmo que permite identificar e ultrapassar informações falsas ou conflituosas num sistema distribuído com diferentes nós; Distributed Snapshots, este algoritmo permite que um processo determine o estado global de um sistema durante um cálculo. Leslie Lamport lançou outros algoritmos com base nos descritos acima, como o The Part-Time Parliament, the Paxos algorithm e o Bakery Algorithm. IV. TOLERÂNCIA A FALHAS Nos sistemas distribuídos a execução de processos e a comunicação de dados estão suscetíveis a falhas arbitrárias, também conhecida como falhas bizantinas. Esse tipo de falha é a mais séria que pode ser encontrada, pois num simples acesso a base de dados, ou numa chamada de processos, podem ocorrer falhas de comunicação ou hardware, mas também pode ocorrer falhas provenientes dos utilizadores, seja introduzindo dados incorretos voluntariamente ou intencionalmente. Devido aos grandes problemas que essas falhas podem causar, os sistemas em geral precisam utilizar algoritmos, métodos e técnicas que permitam prever, identificar e concertar as falhas do sistema, até que a ocorrência de falhas seja equivalente a zero ou que os sistemas consigam se recuperar ou continuar após a ocorrência das falhas. A tolerância a falhas é uma propriedade indispensável em sistemas onde se exige uma alta disponibilidade ou aplicações de caráter crítico, como por exemplo, sistemas e aplicações dedicados para a área da medicina. V. FALHAS BIZANTINAS As falhas bizantinas são essencialmente caracterizadas pela satisfação de dois requisitos: 1. os processos verdadeiros devem possuir uma visão coerente das mensagens enviadas por cada processo e; 2. os processos verdadeiros devem poder verificar se as mensagens enviadas pelos demais processos estão consistentes com os requisitos do algoritmo a ser executado, o que evidencia que a detecção de falhas bizantinas é definida em função de determinado algoritmo ou protocolo. O primeiro requisito pode ser atendido utilizando duas técnicas distintas: a redundância da informação e o uso de assinaturas digitais não alteráveis. O segundo, pela adição de informação às mensagens, na forma de certificados, que possam ser utilizados para validar o conteúdo a ser transmitido.

3 3 Entretanto, as suspeitas são identificadas de maneira assíncrona, sem recorrer ao uso de temporizadores (mecanismos de timeout) para detectar falhas de omissão. Além disso, a detecção segue um padrão de troca de mensagens local, ou seja, entre os nós que se encontram na vizinhança. Figura 1 Categorização de falhas bizantinas A Figura 1 ilustra as classes de falhas bizantinas descritas por Kihlstrom et al., distinguindo-se duas superclasses: detectáveis, quando comportamento externo do processo falso fornece evidências de que o mesmo falhou e não-detectáveis, caso contrário. Falhas não-detectáveis podem ser subdivididas em nãoobserváveis, quando os demais processos não podem notar a ocorrência da falha (por exemplo, um processo falso informa um parâmetro fornecido pelo utilizador incorrectamente) e não-diagnosticáveis, quando não é possível identificar o processo que gerou a falha (por exemplo, os processos recebem uma mensagem não assinada). As falhas detectáveis são classificadas em falhas de progresso (ou falhas por omissão) e falhas de segurança (ou falhas por comissão). Falhas de progresso atrapalham a terminação da computação, uma vez que o processo faltoso não envia mensagens requeridas por sua especificação ou as envia a apenas parte dos processos do sistema. Falhas de segurança violam propriedades invariantes às quais os processos devem atender, podendo ser definidas como o não-cumprimento de uma das seguintes restrições: 1. um processo deve enviar as mesmas mensagens para todos os outros (um processo falso poderia, portanto, enviar a mesma mensagem com valores distintos para processos distintos); 2. as mensagens enviadas devem estar de acordo com o algoritmo a ser executado. a. Modelo de troca de mensagens: Grande parte dos protocolos de detecção de falhas por colapso baseiam-se num mecanismo de troca de mensagens do tipo eu estou vivo (I m alive). Entretanto, no modelo bizantino, devido à ocorrência de processos maliciosos, tal mecanismo não é mais suficiente. Um processo falso pode responder corretamente às mensagens do detector de falhas sem no entanto garantir o progresso e a segurança do algoritmo sendo executado. Em consequência, a detecção das falhas deve se basear no padrão das mensagens enviadas na execução do algoritmo A que utiliza o detector de falhas. Assim sendo, de forma similar ao feito por Kihlstrom et al., as suspeitas são levantadas em função das mensagens requeridas por A. b. Suspeitas e equívocos: Cada suspeita sobre um processo p i está associada a uma mensagem m requerida por A. Requer-se, portanto, que as mensagens recebam identificadores únicos. As suspeitas são propagadas na rede e um processo correto adotará uma suspeita não gerada por ele próprio se e apenas se receber pelo menos f + 1 ocorrências devidamente autenticadas provenientes de processos distintos, sendo f a cobertura bizantina. O requisito de pelo menos f + 1 ocorrências impede que processos maliciosos imponham suspeitas sobre processos corretos. Figura 2 Geração de suspeitas no protocolo proposto (f=1) A Figura 2 ilustra esse mecanismo, os vizinhos de um processo p 1, falso por omissão, perceberão que p 1 não está enviando as mensagens que deveria. Numa rede com f-cobertura bizantina, pelo menos dois (f + 1) dos processos vizinhos a p 1, neste caso p 2 e p 3, serão corretos e divulgarão uma suspeita de falha S para os seus respectivos vizinhos. Qualquer processo correto da rede, por exemplo, p 10, terá pelo menos um caminho para p 2 (p 10p 9 p 5p 2) e p 3 (p 10p 3) formado apenas por processos corretos, recebendo pelo menos duas (f +1) ocorrências de S, adotando portanto a suspeita. Seja p i um processo suspeito de não ter enviado uma mensagem m. Se em algum momento um processo correto p j receber m de p i, p j declarará um equívoco (mistake) sobre a suspeita e difundirá a mensagem m aos demais, a fim de que façam o mesmo. Na Figura 3, um processo lento p 1, sobre o qual foi levantada uma suspeita, envia a mensagem requerida m (representada pelo envelope) a um processo correto p 2. Numa rede com f cobertura bizantina, haverá pelo menos um

4 4 caminho formado apenas por processos corretos de cada processo correto até p 2. Por exemplo, para p 10, temos o caminho p 2p 5 p 9p 10. Logo p 10 (e qualquer outro processo correto) receberá m e poderá retirar sua suspeita correspondente. `argumento hexágono". Este algoritmo é utilizado para várias situações sempre que existe um nó que envia mensagens defeituosas para diferentes partes do sistema, em que parece indistinguível de uma situação simétrica na qual os papéis corretos e defeituosos são invertidos. O problema Acordo bizantino e suas soluções tornaramse a marca registrada dos sistemas tolerantes a falhas. A maioria dos sistemas construídos com redundância fazem uso dele internamente para replicação e para a coordenação de processos. VII. STATE MACHINE REPLICATION Figura 3 Geração de equívoco no protocolo proposto (f=1) VI. ACORDO BIZANTINO Supõe-se frequentemente que quando um componente falha ele irá comportar-se de uma maneira bem definida, apesar deste comportamento ser diferente do comportamento normal esperado. Entretanto, normalmente quando um componente falha ele se comporta de maneira totalmente arbitrária. O problema de alcançar um entendimento entre os componentes de um sistema distribuído, onde eles podem falhar de maneira arbitrária, é chamado de Problemas Gerais Bizantinos. Os protocolos usados para se atingir este entendimento são chamados de Protocolos de Acordo Bizantino. Falhas bizantinas analisam as faltas que podem acontecer num sistema. Mas como evitar essas faltas? Uma formulação abstrata do problema é utilizar a coordenação entre processos para despistar as falhas bizantinas; isto é conhecido como o problema do "Acordo bizantino". Esta formulação consiste em estabelecer o controlo na coordenação dos processos de maneira a estabelecer um acordo para um bit individual, começando com entradas potencialmente diferentes bits para cada componente. Depois de ter um acordo sobre um único bit, é possível utilizá-lo várias vezes, a fim de manter todo um sistema complexo coordenado. Para formar um acordo sobre um único bit para lidar com uma avaria são necessários quatro computadores. Três não são suficientes, porque com três unidades, uma unidade defeituosa pode enviar valores em conflito para as outras duas unidades, e formam uma maioria diferente com cada um. Geralmente, 3F + 1 unidades são necessárias a fim de superar F simultaneamente componentes defeituosos. Para provar isso, usa-se um argumento de simetria que ficou conhecido como o Esta foi talvez a mais significativa de muitas contribuições de Lamport para os sistemas distribuídos, foi introduzido no famoso papel no tempo, relógios, e a ordenação de eventos em um sistema distribuído, e desenvolvido logo depois. Lamport percebeu que as tarefas difíceis de replicar um serviço durante vários computadores podem ser feitas notavelmente simples se você apresentar a mesma sequência de comandos de entrada para todas as réplicas e eles passam através de uma sucessão de estados idênticos. O SMR (state machine replication) é um método geral para a implementação de um serviço tolerante a falhas, replicando servidores e coordenando as interações dos clientes com réplicas do servidor. Muitos serviços atuais têm disponibilidade e os requisitos de desempenho muito rigoroso. Essa alta disponibilidade implica na tolerância de falhas em componentes e é normalmente realizado com replicação. Para muitos serviços, alta performance significa, essencialmente, a capacidade de servir uma carga muito grande, algo que pode ser alcançado se o serviço pode escalar rendimento com o número de réplicas. O SMR é uma técnica bem conhecida para fornecer tolerância a falhas sem sacrificar a consistência. SMR regulamenta a forma como os comandos dos clientes são propagadas e executado pelas réplicas, cada réplica que não é defeituoso deve receber e executar todos os comandos na mesma ordem.

5 5 VIII. CONCLUSÃO Um sistema distribuído é constituído por processos que cooperam de forma a atingirem um objectivo comum. O facto de um sistema distribuído, deste tipo, ser constituído por diferentes processos, normalmente ligados em rede, leva a que possam acontecer erros em vários pontos e por diferentes motivos, provocando respostas igualmente diferentes. A segurança nas comunicações entre sistemas é um ponto muito importante em qualquer sistema ligado em rede. Desta forma é importante saber em que pontos desse sistema podem acontecer esses erros e ter estratégias para os combater e os evitar. As falhas bizantinas são difíceis de detectar por serem arbitrários. São das que podem ter consequências piores por ser difícil de prever que parte do sistema podem atingir e quando. A tolerância a falhas permite aumentar a qualidade de um sistema computacional. Apesar da tolerância a falhas não garantir comportamento correto na presença de todo e qualquer tipo de falha e apesar das técnicas empregadas envolverem algum grau de redundância e, portanto, tornarem os sistemas maiores e mais caros, ela permite alcançar a confiabilidade para os sistemas computacionais. REFERÊNCIAS 1. Lesley Lamport, My Writings, em 2. Dahlia Malkhi, Leslei Lamport em 3. Byzantine Agreement em