Transações e Controle de Concorrência Replicação de Arquivos e Tolerância a Falhas Grupo 15

Transcrição

1 Transações e Controle de Concorrência Replicação de Arquivos e Tolerância a Falhas Grupo 15 Cláudia Macedo Amorim Tamer Albuquerque Pereira

2 Sumário: Parte I Transações e Controle de Concorrência 1. Introdução 2 - Revisão de Conceitos 2.1 Transações Atômicas Transações Distribuídas Propriedades das Transações Atomicidade Consistência Isolamento Durabilidade Protocolos de Efetivação 3 - Serviços de Transações 3.1 Serviços de Transações usando transações Distribuídas 4 Serialização 4.1 Equivalência Serial 5 Controle de Concorrência 5.1 Controle de Concorrência para transações que possuem operações endereçadas em um único servidor Protocolos de Bloqueio Protocolo de Concorrência Otimista Protocolo de Timestamp 2

3 5.2- Controle de Concorrência em Transações Distribuídas Protocolos de Bloqueio Protocolo de Concorrência Otimista Protocolo de Timestamp 6 Conclusão Parte II Replicação de Arquivos e Tolerância a Falhas 1 - Introdução 2 - Réplicas Motivação para aplicação de tolerância à falhas Algoritmos de Controle de Réplicas Algoritmos baseados em cópia primária Algoritmos baseados em cópias ativas Validação de técnicas de tolerância a falhas 2.4 Propagação de Atualizações por Gossip A Arquitetura Gossip Propagação de Atualizações 2.5 Algoritmo de Votação por Quorum 3 Conclusão eedsdfsdfgrtghrtthhhhhdfdddddddcvv fdvvvvbbbb 2.5 Algoritmo de Vot Conclusão3 Conclusão Propagação de Atualizações Pro222pagação de Atualizações Propagação de Atualizações Propagação de Atualizações Propagação de Atualizações Propagação de Atualizações2.4.2 Propagação de Atualizações 3

4 Parte I Transações e Controle de Concorrência 1 Introdução: Transações dão meios pelos quais clientes podem especificar seqüências de operações que são atômicas na presença de outras transações concorrentes e quedas de servidores. O primeiro aspecto de atomicidade é obtido pela execução de transações cujos efeitos são serialmente equivalentes. Os efeitos de transações efetivadas são armazenados em dispositivos de armazenamento permanentes, então tais efeitos podem ser recuperados após quedas de processo. Para garantir a atomicidade, são utilizados protocolos de efetivação dentre os quais o mais utilizado é o protocolo de duas fases. Conflitos entre operações formam a base para os protocolos de controle de concorrência. Protocolos não devem garantir apenas a serialização mas também permitem recuperação através de execuções estritas para evitar problemas associados com o aborto de transações. 2 - Revisão de Conceitos: 2.1 Transações Atômicas: Em um sistema operacional distribuído, certas ações devem ser realizadas sem interrupção. Estes tipos de ações denominam-se transações atômicas. Uma transação atômica é indivisível, isto é, ou ela é completamente realizada ou nenhuma de suas operações é efetivada Transações Distribuídas: Uma transação se torna distribuída quando requer operações em alguns diferentes servidores. 4

5 2.1.2 Propriedades das Transações: As propriedades fundamentais de uma transação são as propriedades de atomicidade, consistência, isolamento e durabilidade (ACID) Atomicidade: Garante a consistência de objetos replicados. Ou todas as transações são replicadas ou nenhuma delas o são Consistência: Mantém a consistência dos resultados. A execução de transações intercaladas é equivalente a execução de transação serial Isolamento: proporciona a consistência de percepção do estado do sistema. Os resultados parciais de transação incompleta não são visíveis a outras, antes que os participantes da transação entrem em acordo a seu respeito Durabilidade: Complementa a idéia de percepção do estado do sistema. O sistema garante que os resultados de uma transação se tornarão permanentes, mesmo ocorrendo falha depois da concordância das partes Protocolos de Efetivação: Se desejamos garantir a atomicidade, todos os servidores envolvidos na execução de uma transação T devem concordar com o término da transação. É preciso que T seja efetivada em todos os servidores ou então será abortada em todos eles. Para assegurar que isso ocorra, o coordenador da transação T precisa executar um protocolo de efetivação (commit protocol). 3.Serviços de Transações: Para manter a atomicidade e durabilidade, objetos devem ser recuperáveis; quando um processo no servidor cai inesperadamente por falha de hardware ou de software, o sistema deve possuir uma cópia de todas as mudanças que foram feitas nos objetos pelas transações. Cada transação é criada e gerenciada por um coordenador, que implementa a Coordinator interface (veja figura). O coordenador dá a cada transação um identificador, ou TID. O cliente invoca o método opentransaction do coordenador para introduzir uma nova transação o TID é então alocado e retornado. No final da transação, o cliente chama o método closetransaction para indicar que a transação terminou todos os objetos recuperáveis devem ser salvos. Se por algum motivo, o cliente quiser abortar a transação, ele chama o método aborttransaction e todos os efeitos da transação são removidos. 5

6 Instructor s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 2 (2nd impression) Addison-Wesley Publishers Figure 12.2 Transactional service operations. OpenTransaction Trans; starts a new transaction and delivers a unique TID Trans. This identifier will be used in the other operations in the transaction. CloseTransaction(Trans) (Commit, Abort) ends a transaction: a Commit returned value indicates that the transaction has committed; an Abort returned value indicates that it has aborted. AbortTransaction(Trans) aborts the transaction. Uma transação é concluída através da cooperação entre um programa cliente, alguns objetos recuperáveis e um coordenador. O cliente especifica a seqüência de requisições nos objetos recuperáveis necessários para concluir uma transação. Para a conclusão, o cliente manda com cada requisição o identificador de transação retornado pelo método opentransaction. 3.1-Serviços de Transações Usando Transações Distribuídas: Servidores que executam requisições como parte de uma transação distribuída necessitam estar aptos a comunicar-se uns com os outros para coordenar suas ações quando as transações são efetivadas. Como descrito anteriormente, um cliente começa uma transação através do envio de uma requisição opentransaction para um coordenador em qualquer servidor. O coordenador contatado aloca e retorna o TID (identificador da transação) para o cliente. Identificadores de transações para transações distribuídas devem ser únicos dentro de um sistema distribuído. O coordenador que abriu a transação se torna o coordenador para a transação distribuída e, até o final é responsável por efetiva-la ou aborta-la. Cada um dos servidores que administram um objeto acessado pela transação é chamado de participante. Cada participante é responsável pela manutenção da rota de todos os objetos recuperáveis no servidor envolvido na transação. Os participantes são responsáveis pela cooperação com o coordenador em prover o protocolo de efetivação. 6

7 Durante o progresso da transação, o coordenador armazena uma lista de referências dos participantes e os participantes armazenam uma referência do coordenador. O serviço de transações irá armazenar mais um método, o método join, que é usado quando um novo participante se unir à transação: join (Trans, reference to participant) Informa a um coordenador que um novo participante foi adicionado à transação Trans O coordenador armazena o novo participante à sua lista de participantes. O fato do coordenador conhecer todos os participantes e cada participante conhecer o coordenador torna-os capazes para coletar as informações que serão necessárias na hora da efetivação. Note que é possível para um participante chamar o método aborttransaction no coordenador se por alguma razão ele não for capaz de continuar com a transação. 4 - Serialização: A serialização assegura que se duas ou mais transações estiverem rodando ao mesmo tempo, para cada uma delas e para os outros processos, o resultado aparece como se todas elas rodassem seqüencialmente em alguma ordem pré-definida dependente do sistema. BEGIN_TRANSACTION BEGIN_TRANSACTION BEGIN_TRANSACTION X = 0; X = 0; X = 0; X = X+1; X = X+2; X = X+3; END_TRANSACTION END_TRANSACTION END_TRANSACTION (a) (b) (c) Tempo Escalonamento 1 X = 0; X = X+1; X = 0; X = X+2; X = 0; X = X+3; Legal Escalonamento 2 X = 0; X = 0; X = X+1; X = X+2; X = 0; X = X+3; Legal 7

8 Escalonamento 3 X = 0; X = 0; X = X+1; X = 0; ; X = X+2; X = X+3; Ilegal Na figura acima temos três transações que são executadas simultaneamente por três processos diferentes. Se elas rodassem seqüencialmente, o valor de x poderia ser 1, 2 ou 3, dependendo de qual delas vai rodar por último (x poderia ser uma variável compartilhada, um arquivo ou algum outro objeto). Na figura podemos observar a execução das transações em várias ordens distintas, chamadas escalonamentos. O escalonamento 1 é serializado, ou seja, as transações rodam numa ordem estritamente seqüencial, de maneira que elas atendem por definição ao requisito da serialização. O escalonamento 2 não é serializado, mas ele ainda é legal, pois resulta em valores para x idênticos aos que seriam obtidos pela execução estritamente seqüencial das transações. O terceiro escalonamento é ilegal pois faz com que x fique com valor 5, algo que a ordenação seqüencial das transações não pode obter de nenhuma forma. É de responsabilidade do sistema assegurar a correta intercalação das operações individuais. 4.1 Equivalência Serial: Se cada uma das várias transações soubesse o efeito correto quando é feita por conta própria, então podemos deduzir que se estas transações são feitas uma por vez em alguma ordem o efeito combinado também será correto. Uma intercalação de operações de transações nas quais o efeito combinado é o mesmo como se as transações tivessem sido efetuadas uma por vez em alguma ordem é uma intercalação equivalente serialização. Quando dizemos que duas transações diferentes tiveram o mesmo efeito de uma outra, nós queremos dizer que as operações de leitura retornam os mesmos valores e que as variáveis dos objetos possuem os mesmos valores até o final. 5 Controle de Concorrência: 8

9 5.1 Controle de Concorrência para transações que possuem operações endereçadas em um único servidor: Protocolos de Bloqueio: Transações devem ser escalonadas para que seu efeito em porções de dados seja serialmente equivalente. Um servidor pode obter equivalência serial de transações através da serialização de acesso aos objetos. Um exemplo simples de um mecanismo de serialização é o uso de bloqueio exclusivo. Neste tipo de bloqueio o servidor tenta bloquear qualquer objeto que esteja prestes a ser usado por alguma operação da transação do cliente. Se um cliente requisita acesso a um objeto que já esteja bloqueado devido a outra transação de cliente, a requisição é suspensa e o cliente deve esperar até que o objeto seja desbloqueado. Equivalência serial requer que todos os acessos de uma transação a um objeto particular sejam serializados em respeito a acessos por outras transações. Todos os pares de operações conflitantes das transações devem ser executados na mesma ordem em todos os objetos que ambos acessam. Para garantir isso, uma transação não permite quaisquer novos bloqueios depois que tenha liberado um bloqueio. A primeira fase de cada transação é uma fase de crescimento (growing phase), durante a qual novos bloqueios são adquiridos. Na segunda fase, os bloqueios são liberados fase de encolhimento (shrinking phase). Este método é chamado bloqueio em duas fases (two-phase locking). Devido a transações poderem ser abortadas, execuções estritas são necessárias para prevenir dirty reads e escritas prematuras. Sob um regime de execução estrita, uma transação que necessita ler ou escrever em um objeto deve ser adiada até que outras transações escreveram o mesmo objeto tenham sido efetivadas ou abortadas. Isto é chamado de bloqueio em duas fases estrito (strict two phase locking). A presença de bloqueios previne a leitura e escrita de objetos por outras transações. Quando uma transação é efetivada, para garantir a recuperação, bloqueios devem ser mantidos até que os objetos que foram atualizados sejam armazenados em memória permanente. Um servidor geralmente contém um grande número de objetos, e uma transação típica acessa somente uma pequena parte delas e é improvável haver conflito com outras transações correntes. A questão que trata do tamanho do item a ser bloqueado é denominada granularidade do bloqueio. Quanto mais fina a granularidade, mais preciso o bloqueio pode ser, e mais paralelismo pode ser obtido na implementação do esquema. Observe que com uma granularidade fina, não será necessário bloquear um processo que deseja acessar o final de um arquivo enquanto existe um mesmo processo acessando o início deste mesmo arquivo. Por outro lado quanto mais fina for a granularidade, maior será o número de bloqueios. Como conseqüência, o custo associado será maior, e a possibilidade de deadlocks também aumenta. 9

10 A descrição dos esquemas de controle de concorrência dados acima não aceitam qualquer granularidade particular. Nós discutimos protocolos de controle de concorrência que são aplicáveis a objetos o quais possuem operações que podem ser modeladas em termos de operações de leitura e escrita em objetos. Para os protocolos trabalharem corretamente, é essencial que cada operação de leitura e escrita seja atômica em seus efeitos nos objetos. Protocolos de concorrência são desenvolvidos para lidar com conflitos entre operações em diferentes transações no mesmo objeto. É preferível um esquema de bloqueio que controle o acesso a cada objeto, então poderá haver várias transações concorrentes lendo um objeto, ou uma única transação escrevendo um objeto, mas não ambas. Este esquema é denominado como um esquema alguns leitores / único escritor. Dois tipos de bloqueio são usados: bloqueio de leitura e bloqueio de escrita Protocolo de Concorrência Otimista: Este protocolo se baseia na observação de que, na maioria das aplicações, a probabilidade de duas transações de clientes acessarem o mesmo objeto é pequena. Transações são permitidas quando não há possibilidade de conflito com outras transações até que o cliente complete sua tarefa e emita um closetransaction. Quando um conflito acontece, alguma transação é geralmente abortada e necessitará ser recomeçada pelo cliente. Cada transação possui as seguintes fases: Fase de trabalho (working phase): Durante a fase de trabalho, cada transação faz uma tentativa da versão de cada objeto que foi atualizado. Esta é a cópia da versão mais recentemente efetivada do objeto. O uso desta tentativa permite que a transação aborte (sem qualquer efeito nos objetos), tanto na fase de trabalho quanto se a validação falha devido a outros conflitos de transações. Operações de leitura são efetuadas imediatamente se a versão de tentativa para aquela transação já existe, uma operação de leitura a acessa, caso contrário acessa o valor da versão mais recentemente efetivada do objeto. Operações de escrita armazenam os novos valores para os objetos com valores de tentativas (que não são visíveis para outras transações). Quando há várias transações concorrentes, vários valores de tentativa diferentes de um mesmo objeto podem coexistir. Além disso, dois registros são mantidos dos objetos acessados dentro de uma transação: um conjunto de leitura contendo os objetos lidos pela transação; e um conjunto de escrita contendo os objetos escritos pela transação. Note que todas as leituras são note que todas as operações de leitura são efetuadas com versões efetivadas dos objetos. Fase de Validação: Quando a requisição de closetransaction é recebida, a transação é validada para estabelecer se suas operações nos objetos estão em conflito com outras operações de outras transações nos mesmos objetos ou não. Se a validação é bem 10

11 sucedida então a transação pode ser efetivada. Se a validação falha, então alguma forma de resolução de conflito deve ser utilizada e ou a transação corrente, ou em alguns casos aquelas com as quais ela está em conflito, necesssita(m) ser abortada(s). Fase de Atualização: Se a transação é validada, todas as mudanças armazenadas em suas versões de tentativas são tornadas permanentes. Transações apenas de leitura podem ser imediatamente efetivadas após passarem pela validação. Transações de escrita já estão prontas para a efetivação uma vez que as versões de tentativa dos objetos tenham sido armazenadas em memória permanente Protocolo de Timestamp: No controle de concorrência baseado em timestamp, cada operação numa transação é validada quando se efetiva. Se a operação não pode ser validada, a transação é abortada imediatamente e pode ser reiniciada pelo cliente. Cada transação recebe um único timestamp (carimbo) quando começa. Seu carimbo define sua posição na seqüência de tempo das transações. A regra básica do timestamp é baseada no conflito de operações e é bem simples: Uma requisição de transação para escrever num objeto é válida somente se aquele objeto foi lido por último e escrito por transações anteriores. Uma requisição de leitura no objeto é válida somente se o objeto foi escrito por último por uma transação anterior Controle de Concorrência em Transações Distribuídas: Cada servidor gerencia um conjunto de objetos e é responsável por garantir que estes objetos permanecerão consistentes quando acessados por transações concorrentes. Portanto, cada servidor é responsável por aplicar controle de concorrência em seus próprios objetos. Os membros de uma coleção de servidores de transações distribuídas são, juntos, responsáveis por garantir que estas transações sejam efetuadas em maneira serialmente equivalente Protocolos de Bloqueio: Em transações distribuídas, os bloqueios em um objeto são mantidos localmente (no mesmo servidor). O gerenciador de bloqueio local pode decidir entre conceder um bloqueio ou fazer a requisição de transação esperar. De qualquer modo, o gerenciador não pode liberar bloqueios até saber que a transação tenha sido efetivada ou abortada em todos os servidores envolvidos nesta transação. Quando o bloqueio é usado para controle de concorrência, os objetos permanecem bloqueados e estão indisponíveis 11

12 para outras transações durante o protocolo de efetivação, apesar de uma transação abortada liberar seus bloqueios após a fase 1 do protocolo Protocolo de Concorrência Otimista: Como vimos anteriormente, no controle de concorrência otimista cada transação é validada antes de ser permitida a sua efetivação. Números de transações são atribuídos no início da validação e as transações são serializadas de acordo com a ordem dos números de transações. Uma transação distribuída é validada por uma coleção de servidores independentes, cada um dos quais valida transações que acessam seus próprios objetos Protocolo de Timestamp: Em uma simples transação de servidor, o coordenador emite um único timestamp (carimbo) para cada transação quando esta começa. A equivalência serial é forçada pela efetivação de versões de objetos na ordem em que os timestamps das transações os acessaram. Em transações distribuídas, é necessário que cada coordenador emita globalmente timestamps únicos. Um timestamp globalmente único de uma transação é emitido para o cliente pelo primeiro coordenador acessado por uma transação. O timestamp de transação é passado ao coordenador através de cada servidor que possui objetos que efetuam uma operação na transação. Os servidores de transações distribuídas são juntamente responsáveis pela garantia de que estas transações estão sendo efetuadas de uma maneira serialmente equivalente. Por exemplo, se a versão de um objeto acessado pela transação U faz uma efetuação depois da versão acessada por T em um servidor, então se T e U acessam o mesmo objeto como um outro objeto em outros servidores, eles devem efetuar estes objetos na mesma ordem. Para conseguir a mesma ordenação para todos os servidores, os coordenadores devem concordar em como ordenar seus timestamps. 6 Conclusão: 12

13 As operações que formam uma única unidade lógica de trabalho são chamadas de transações. Um sistema distribuído precisa garantir a execução apropriada das transações a despeito de falhas ou a transação é executada por completo ou nenhuma parte dela é executada. Todos os protocolos de controle de concorrência que foram discutidos nesta parte têm por base a propriedade da serialização (seriazability). Isto é, todos os esquemas que foram apresentados garantem que a ordenação de processamento é serializada. 13

14 Parte II - Redundância de Arquivos e Tolerância à Falhas: 1 Introdução: A replicação de objetos é um meio importante de obter serviços com bom desempenho, alta disponibilidade e tolerância a falhas em um sistema distribuído.vamos descrever arquiteturas para serviços nas quais gerenciadores de réplicas matem réplicas dos objetos, e nos quais front ends tornam esta replicação transparente. 2 - Replicação: Muitas vezes os sistemas de arquivos distribuídos oferecem a seus clientes o serviço de replicação de arquivos. Em outras palavras, podem ser mantidas várias cópias de arquivos selecionados, com cada uma das cópias armazenadas em servidores separados. São várias as razões para o oferecimento de tal serviço, dentre elas as seguintes: 1) O aumento da confiabilidade; 2) A queda de um servidor não pode derrubar um sistema; 3) A carga de trabalho é divida por vários servidores. Os dois primeiros pontos dizem respeito à melhora de confiabilidade e disponibilidade do sistema, enquanto que o terceiro ponto refere-se ao desempenho. O aumento da confiabilidade é obtido com a manutenção de diversos backups de cada arquivo. Se um servidor sair do ar, ou mesmo no caso de seu sistema de arquivos ser irremediavelmente perdido, não haverá perda de dados. Essa propriedade é desejada para inumeráveis aplicações. A alta disponibilidade se dá devido ao fato de que é possível acessar um arquivo mesmo no caso de um servidor com problema. O lema é: o espetáculo deve continuar. Assim, a queda de um servidor não pode derrubar o sistema. Os fatores relevantes que devem ser corrigidos para se obter uma alta disponibilidade são: falhas de servidor; particionamento da rede e operação desconectada. A respeito do primeiro fator, a replicação é uma técnica para a manutenção da disponibilidade de dados apesar de falhas de servidor. Se os dados são replicados em dois ou mais servidores então o software do cliente deve ser capaz de acessar os dados em um servidor alternativo se o servidor padrão falhar ou se tornar inacessível. Assim a porcentagem de tempo durante a qual o serviço está disponível pode ser aumentada pela replicação de dados nos servidores. 14

15 Partições de redes e operação desconectada são o segundo fator que atuam contra uma alta disponibilidade. Usuários móveis deliberadamente desconectam seus computadores ou podem se tornar não intencionalmente desconectados de uma rede wireless (sem fio) quando se movem. Por exemplo, um usuário em um trem com um laptop pode não ter acesso à rede (esta pode ser interrompida ou não possuir grande capacidade). Para ser capaz de trabalhar nessas circunstâncias (chamadas trabalho desconectado ou operação desconectada) o usuário freqüentemente se prepara através da cópia de dados muito utilizados, como os conteúdos de uma parte diária de seu ambiente usual para o laptop. Assim, trabalhar desconectado é possível somente se o usuário (ou a aplicação no lado do usuário) puder se virar com os dados antigos e puder mais tarde resolver quaisquer conflitos que surjam. Alta confiabilidade e disponibilidade são requisitos essenciais para sistemas críticos. Esses sistemas são utilizados em situações em que falhas podem pôr em risco vidas humanas (como em centrais nucleares, transporte aéreo, controle de indústrias químicas, instrumentação médica) ou provocar grandes danos financeiros por perdas de informação (como em base de transações bancárias e de bolsas de valores atualizadas e acessadas on line). Os sistemas computacionais usados para essas aplicações são geralmente de alto custo e baixo desempenho, garantindo confiabilidade e disponibilidade pela duplicação de elementos de hardware (para mascaramento de falhas e/ou reposição de componentes defeituosos), redundância de dados (codificação, códigos de detecção e correção, CRC) e software robusto (blocos de recuperação, processos backup, comunicação confiável entre processos, recuperação de processos) À medida que o sistema cresce, o fato de ele ter todos os arquivos em um único servidor vai-se transformar seguramente em um gargalo para o desempenho. A possibilidade de haver arquivos replicados em dois ou mais servidores faz com que possamos usar o menos carregado. Devido às razões já descritas, pode-se dizer que a replicação é a chave para a eficácia em sistemas distribuídos no que pode prover alto desempenho, alta disponibilidade e tolerância à falhas. Um aspecto-chave na questão da replicação é a transparência. Assim, clientes normalmente não devem estar cientes de que existem múltiplas cópias físicas dos dados. Dados são organizados como objetos (lógicos e individuais) e eles identificam apenas um item em cada caso quando solicitam uma operação para ser realizada. Além disso, clientes esperam que operações retornem apenas um conjunto de valores, não importando a eles o fato que operações devem ser realizadas através de mais de uma cópia física em acordo. Outro requisito para dados replicados que pode variar de intensidade entre as aplicações é a consistência. A consistência se refere a operações que realizadas sobre uma coleção de objetos replicados produzem resultados que condizem com a especificação de exatidão para estes objetos. Até pouco tempo atrás, usuários de sistemas de computação executando tarefas não críticas estavam tão satisfeitos em poder contar com a automação de seus serviços, que não se preocupavam demasiado com as sucessivas falhas, retardos e colapsos de seus 15

16 computadores. As poucas técnicas utilizadas para garantir um mínimo de confiabilidade pareciam satisfatórias pois não comprometiam de forma visível o desempenho do sistema. Ultimamente, entretanto, a situação mudou drasticamente. A grande proliferação de redes de computadores lançou os usuários em um universo de recursos computacionais distribuídos. A falha de um nodo isolado (que antes provocava danos para apenas um reduzido número de tarefas) pode comprometer todo o serviço provido por uma rede. Uma falha isolada em um nodo pode provocar total parada do serviço ou fornecer um serviço incorreto (respostas erradas ou fora de prazo). Tais cenários são inviáveis em aplicações de tempo-real, principalmente naquelas que envolvem situações catastróficas Motivação para aplicação de tolerância à falhas : Sistemas distribuídos e redes locais de computadores são arquiteturas de larga aplicação tanto para aplicações convencionais de alto desempenho ou alta disponibilidade como para aplicações de tempo-real de alta confiabilidade. Não só a aplicação precisa ser preservada quanto à falhas de hardware, software e operação, mas o sistema distribuído deve prover operação continuada com apenas pequena queda de desempenho mesmo na presença de qualquer tipo de falha. Apesar de se conhecer um bom conjunto de técnicas de tolerância à falhas, sua aplicação a sistemas distribuídos, principalmente os de tempo-real, ainda é muito recente e seus resultados são muitas vezes insatisfatórios. Sistemas distribuídos de tempo-real diferem dos sistemas convencionais por apresentarem restrições de tempo e tratarem, em muitos casos, com situações críticas. Isto implica que qualquer tipo de falha, inclusive falha temporal, pode causar conseqüências irreparáveis. A Tolerância à falhas nesses sistemas é uma exigência óbvia e consolidada. São suportadas regularmente pelo hardware do sistema. Com a complexidade aumentada por um número maior de componentes de software e sofisticadas interações, novas soluções para sistemas distribuídos passíveis de implementação em vários níveis de software e hardware precisam ser desenvolvidas e validadas quanto a correção e temporização. Existe um mercado mundial para tolerância à falhas que envolve grande soma de recursos financeiros. Esse mercado engloba não apenas operações críticas de tempo real (como transportes, aviação, controle de processos, comunicações), mas também operações comerciais (como os suportados por sistemas de transações). Empresas que dominavam o mercado mundial para aplicações comerciais até a década de 80, Tandem e Stratus, produziam mainframes de altíssimo custo. Recentemente essas empresas, e também a SUN, Digital, HP, IBM, Novell e Compaq (que adquiriu a Tandem) além de várias outras, começaram a lançar soluções para servidores de rede e clusters tolerantes a falhas, a maior parte das soluções de alto custo (como por exemplo o SUN Enterprise). Uma família de microprocessadores muito popular, Intel 80x86, incorpora desde o 486 uma gama de recursos para tolerância à falhas, que, se bem utilizados, poderiam aumentar consideravelmente a confiabilidade dos sistemas produzidos com esses microprocessadores. Infelizmente, por razões associadas a custos e também principalmente 16

17 pela carência de uma cultura em confiabilidade, os recursos desses microprocessadores não são plenamente aproveitados. Os recursos físicos usados para armazenar arquivos são por sua própria natureza suscetíveis à falhas. Uma ampla gama de falhas pode atingir os meios de armazenamento, quer sejam falhas no próprio meio, nos dispositivos de controle, nos computadores que gerenciam estes dispositivos, e, no caso de redes, nos links de comunicação. O uso de grandes redes institucionais e servidores corporativos, com dezenas ou centenas de usuários, tende a agravar este problema. Em redes aumenta o número de pessoas ou atividades que dependem dos mesmos discos e servidores de arquivos, criando condições para que aconteçam perdas simultâneas ou em cascata relacionadas à falhas em algum dos servidores. As conseqüências de falhas podem ser muito graves e até catastróficas. Devido a necessidade de confiabilidade em armazenamento, diversas técnicas específicas têm sido desenvolvidas para tornar este recurso mais seguro, sem que uma solução ao mesmo tempo robusta e administrativamente conveniente tenha sido assumida como definitiva. O recurso principal continua a ser o backup em fita, que possui o grave inconveniente de ser um método off-line, e de guardar sempre dados algo atrasados, além de implicar em um longo tempo de recuperação. O aumento de velocidade das redes modernas e sua popularização permitem a adoção de técnicas de replicação de arquivos e a distribuição de réplicas por vários servidores. O algoritmo de replicação é o centro de todo sistema de replicação de dados distribuído e determina as decisões a serem tomadas no tratamento de falhas e na recuperação. Um algoritmo de replicação de arquivos deve resolver principalmente o problema da manutenção da consistência das cópias sob escritas concorrentes. Em um sistema multitarefa, diversos processos executam simultaneamente, e podem compartilhar o acesso aos arquivos, inclusive para escrita. Este recurso permite que arquivos sejam usados para troca dinâmica de informações entre programas e usuários. Ainda que leituras concorrentes não gerem nenhum problema, escritas concorrentes podem gerar inconsistências. A questão fundamental está em garantir que todas as alterações geradas sejam aplicadas em todas as cópias na mesma ordem, além da necessidade de que tenham a mesma efetividade. Não importa garantir que esta ordem seja a mesma ordem física em que as requisições foram geradas, nem que as imagens que cada cliente tenha do arquivo sejam as mesmas a qualquer instante, apenas que todas as cópias executem a mesma seqüência de alterações. Esta ordenação, denominada na literatura como serialização, como cópia única, não pode ser garantida de forma simples. Os algoritmos desenvolvidos para isto, denominados algoritmos de controle de réplicas, devem também ser capazes de operar quando da ocorrência de falhas, quando o número de nodos se reduz, ou sob outras condições, como particionamentos da rede, em função do modelo de falhas adotado. Os algoritmos de controle de réplicas podem ser divididos em três grandes grupos: algoritmos baseados em votação; algoritmos baseados em cópia primária; algoritmos 17

18 baseados em cópias ativas. Os dois últimos podem ser mais facilmente implementados usando multicast confiável e atômico Algoritmos de Controle de Réplicas: Algoritmos baseados em cópia primária: É um modelo em que existe apenas um gerenciador de réplica primária e um ou mais gerenciadores de réplicas secundárias - backups ou slaves. O front end se comunica apenas com o gerenciador de réplicas primário para obter os serviços. O gerenciador de réplicas primário executa as operações e envia as cópias dos dados atualizados para os backups. Se o primário falha, um dos backups é promovido para atuar como primário. A seqüência dos eventos quando um cliente solicita uma operação é descrita abaixo: 1) Solicitação: O Front End envia o pedido, contendo um único identificador, para o gerenciador de cópias primárias; 2) Coordenação: O primário pega cada pedido de forma atômica, na ordem que recebeu. Checa a identificação, em caso de já ter executado o pedido simplesmente reenvia a resposta; 3) Execução: O primário executa o pedido guarda a resposta; 4) Acordo: Se o pedido é uma atualização então o primário envia o estado atualizado, a resposta e a o identificador único para todos os backups. Os backups enviam o reconhecimento; 5) Resposta: O primário responde para o Front End, que envia de a resposta ao cliente. Este modelo pode ser usado onde o gerenciador de réplicas primário se comporta em um meio não determinístico, por exemplo numa operação multi-threaded. O modelo de replicação baseada em cópias primárias tem a desvantagem de fornecer enormes overheads. Para o sincronismo das comunicações são requisitadas várias voltas de comunicações por multicast, e se o primário falha então uma maior latência é causada enquanto o sistema de comunicação do grupo sincroniza com o novo gerenciador. Esse modelo é usado para garantir alta disponibilidade e um bom desempenho, ao passo que, uma fraca consistência. Um exemplo de quem usa esse modelo é o NIS (Network File Service). 18

19 Algoritmos baseados em cópias ativas: Neste modelo de replicação, os gerenciadores de réplicas são máquinas de estado que têm funções equivalentes e são organizadas como um grupo. Front Ends transmitem simultaneamente seus pedidos, para o grupo de gerenciadores e todos os gerenciadores processam os pedidos independentemente e identicamente e respondem. Se ocorre crash em algum gerenciador, então há um impacto no desempenho do serviço. Podemos ver que esse modelo pode tolerar falhas bizantinas, porque o Front End pode coletar e comparar as respostas recebidas. A seqüência de eventos deste modelo é descrita a seguir: 1) Pedido: O Front End junta um único identificador para o pedido e transmite simultaneamente para o grupo de gerenciadores de réplicas, usando uma totalmente ordenada, confiável transmissão simultânea primitiva. 2) Coordenação: O sistema de comunicação do grupo entrega o pedido para todos os gerenciadores de réplicas corretos na mesma ordem. 3) Execução: Todo gerenciador de réplicas executa o pedido. Desde que eles sejam maquinas de estado e desde que os pedidos sejam entregues na mesma ordem, os gerenciadores processarão de forma correta e idêntica. A resposta contém a única identificação do pedido do cliente. 4) Acordo: não necessita de fase de acordo, por causa do envio simultâneo. 5) Resposta: cada gerenciador de réplicas envia a resposta para o Front End. O numero de respostas que o Front End coleta depende das hipóteses de falhas e do algoritmo de envio simultâneo. Este sistema garante consistência seqüencial, porém não garante linearização. Isto ocorre porque a ordem com que os gerenciadores de réplicas processam não é necessariamente a mesma ordem do tempo real em que os clientes fizeram seus pedidos, ou seja, os timestamps não são perfeitamente exatos, apesar de aproximados. Terminando, Front Ends podem enviar pedidos de leitura apenas para um gerenciador de réplica individual. 19

20 2.3 - Validação de técnicas de tolerância a falhas: Um grande problema na área de tolerância à falhas é saber se a técnica implementada resulta realmente em aumento de confiabilidade. Como na maior parte dos sistemas as taxas de falhas são baixas e as falhas acontecem de forma aleatória e incontrolável, o problema se resume em avaliar se a técnica empregada está realmente tolerando as falhas para as quais foi planejada, sem necessidade de esperar meses ou anos para que as falhas realmente aconteçam (por exemplo em aviação, que é um sistema crítico, a taxa de taxas esperada é uma em cada um pouco mais de milhão de anos). Uma solução para esse problema é a injeção de falhas. Injeção de falhas é relativamente popular em sistemas isolados. É recente, entretanto, o desenvolvimento de ferramentas de injeção de falhas para sistemas distribuídos, e pouca experiência foi acumulada no tema. Uma breve introdução a essa técnica é particularmente útil ao desenvolvedores de técnicas de tolerância à falhas em ambiente distribuído. O principal objetivo da injeção de falhas é a validação. A injeção de falhas pode ser vista como um procedimento para o teste da eficácia de técnicas de tolerância à falhas. Através da introdução controlada de falhas, o comportamento da técnica, sob falhas, pode ser avaliado (ou seja, pode ser determinado se a técnica permite ao sistema tolerar ou não as falhas injetadas e qual o custo relacionado à cobertura de falhas alcançada). A injeção de falhas tem uma importância vital em sistemas críticos de tempo real, sujeitos a graves perdas e danos caso técnicas de tolerância à falhas não consigam garantir a confiabilidade especificada. Também em sistemas de transações, onde falhas podem provocar inconsistências (como em operações bancárias) não é permitido esperar que falhas reais durante a operação normal do sistema venham a determinar que as técnicas empregadas não foram bem concebidas ou implementadas. Outros exemplos são em sistemas distribuídos e sistemas paralelos. Nesses sistemas, a complexidade dos subsistemas de conexão e comunicação facilitam a propagação de falhas e dificultam sua detecção. Sem controle sobre o tipo e origem das falhas torna-se extremamente difícil validar a implementação de tolerância à falhas nesses sistemas. Injeção de falhas pode ser aplicada a sistemas simulados ou a sistemas físicos operando em seu ambiente natural. Por exemplo: injeção de falhas a nível de pinos e através de distúrbios externos. As técnicas de injeção de falhas a nível de pinos e através de distúrbios externos tem a vantagem de injetar falhas diretamente no hardware, mas podem danificar o componente sob teste e requerem o uso de hardware especial dedicado. Adicionalmente as ferramentas de injeção são específicas a um determinado sistema. Ferramentas de injeção de falhas implementadas por software não requerem hardware especial para serem aplicadas. Possuem ainda como vantagens baixo custo, baixa complexidade e baixo esforço de desenvolvimento. São facilmente adaptáveis a novas classes de falhas, e não apresentam nenhum problema com interferências físicas. Contudo, a injeção de falhas implementada por software apresenta alguns problemas. A capacidade para modelar certos tipos de falhas, tais como aquelas afetando as unidades de controle de um processador, ainda não foram totalmente desenvolvidas. Além disso, a execução do software responsável pela injeção de falhas afeta as características de temporização do sistema, o que prejudica a execução de funções críticas no tempo. 20

21 Mesmo considerando essas desvantagens, injeção de falhas implementada por software tem despertado o maior interesse de pesquisadores e desenvolvedores. A maioria das ferramentas de injeção de falhas mais recentes enfocam sistemas distribuídos, relacionados com falhas de processador, memória e comunicação. Estas ferramentas (como por exemplo FIAT, SFI, DOCTOR, FINE, PFI) injetam falhas por software. 2.4 Propagação de Atualizações por Gossip: A Arquitetura Gossip: A arquitetura gossip foi desenvolvida como um framework para implementar serviços de alta disponibilidade. O nome vem do fato de que os gerenciadores de réplicas exportam mensagens gossip periodicamente em ordem para transferir as atualizações que cada um recebe dos clientes. O serviço gossip provê dois tipos básicos de operações: queries são operações apenas de leitura e updates modificam mas não lêem o estado. Os Front Ends enviam queries e updates para qualquer gerenciador de réplicas que quiserem qualquer um que esteja disponível e possa dar tempos de resposta razoáveis. Como um serviço gossip processa operações de queries e update: 1) Pedido: O Front End normalmente manda pedidos somente para um único gerenciador de réplicas por vez; 2) Resposta ao update: Se o pedido é uma atualização, então o gerenciador de réplicas responde assim que tiver recebido a atualização; 3) Coordenação: O gerenciador de réplicas que recebeu um pedido não pode processá-lo até que possa aplicar este pedido de acordo com a necessidade de ordenação. Isto deve envolver o recebimento de updates de outros gerenciadores de réplicas, em mensagens gossip. Nenhum outro coordenador entre gerenciadores de réplicas é envolvido; 4) Execução: O gerenciador de réplicas executa o pedido; 5) Resposta à query: se o pedido é uma query então o gerenciador de réplicas responde neste ponto; 6) Acordo: O gerenciador de réplicas atualiza mais um através da exportação de mensagens gossip, que contém as atualizações mais recentes que tenha recebido. 21

22 2.4.2 Propagação de Atualizações: A arquitetura gossip não especifica quando o gerenciador de réplicas trocam mensagens gossip, ou como o gerenciador seleciona outro gerenciador para enviar mensagens gossip também. Uma estratégia de atualizações de propagação robusta é necessária se todos os gerenciadores de réplicas quiserem receber todas as atualizações em um tempo aceitável. O tempo de demora para que todos os gerenciadores de réplicas recebam uma dada atualização depende de três fatores: A freqüência e duração das partições de rede; A freqüência com a qual os servidores de réplicas enviam mensagens gossip; A política de escolha de um parceiro com o qual serão trocadas mensagens gossip. 2.5 Algoritmo de Votação por Quorum: Um meio de prevenir que transações em partições diferentes produzam resultados inconsistentes é fazer uma regra onde operações possam ser realizadas somente dentro de uma partição. Como os gerenciadores de réplicas em partições diferentes não podem se comunicar com outros, os subgrupos dos gerenciadores de réplicas dentro de cada partição devem estar aptos a decidir, independentemente, se estão autorizados a realizar operações. Um quorum é um subgrupo de gerenciadores de réplicas onde a decisão entre realizar ou não as operações é dada pelo tamanho do subgrupo. Por exemplo, se possuir a maioria é o critério, um subgrupo que tem a maioria dos membros de um grupo irá formar um quorum. Num esquema de replicação de acordo de quorum uma operação de atualização deve ser completada com sucesso por um subgrupo de seu subgrupo de gerenciadores de réplicas. Os outros membros do grupo terão, por essa razão, cópias desatualizadas do objeto. Números de versão ou timestamps devem ser usadas para determinar se as cópias estão atualizadas. Um esquema de replicação de arquivos foi desenvolvido onde o número de votos é atribuído a cada cópia física de um único arquivo lógico em um gerenciador de réplicas.um voto pode ser considerado como um peso a mais no desejo do uso de uma cópia particular. Cada operação de leitura deve obter primeiro uma leitura do quorum de R votos antes de poder efetivar a leitura de qualquer cópia atualizada, e cada operação de escrita deve obter 22

23 um quorum de W votos antes de poder efetivar uma operação de atualização. R e W são conjuntos de um grupo de gerenciadores de réplicas da seguinte forma: W metade do total de votos R + W número total de votos do grupo Isto garante que quaisquer pares, consistindo de quorum de leitura e escrita ou dois quora de escrita, devem conter cópias comuns. Portanto, se há uma partição, não é possível realizar operações conflitantes na mesma cópia mas em partições diferentes. 3 Conclusão: Um sistema distribuído pode sofrer os mesmos tipos de falhas que afligem um sistema centralizado. Há, entretanto, tipos de falhas adicionais que que precisam ser tratadas como o particionamento de rede. Há diversas metas envolvendo o armazenamento em um sistema distribuído, dentre elas está a replicação. É essencial que o sistema minimize o grau de conhecimento que o cliente tem de como o armazenamento é realizado. 23

24 Bibliografia: [1] George Coulouris, Jean Dollimore and Tim Kindberg, Distributed Systems Concepts and Design, third edition, Addison Wesley, 2001; [2] Andrew S. Tanenbaum, Sistemas Operacionais Modernos, LTC Livros Técnicos e Científicos Editora; [3] Abraham Silberschatz, Henry F. Korth, S. Sudarshan, Sistema de Banco de Dados, terceira edição, Makron Books;